4hr讀《精實開發與看板方法》一書心得

作者: 李智樺; 書的類型: 技術；主觀推薦閱讀星星數/5: ⭐️⭐️⭐️ ；購買與否: 參考, 絕版

Summary: 若想了解軟體敏捷開發(Agile Develoment)中精實開發與看板方法，這是一本很棒的入門概念書，但讀起來滿教科書的=有點硬但會有收穫

想瞭解什麼是敏捷開發，在網路上搜尋時，發現在天瓏書局單元分類中的敏捷開發有這樣一段介紹

非常清楚的讓人了解什麼是敏捷開發，於是抽空借了這段引言作者的這本書來看看。

掃過這本書一遍後，因為前面的概念性敘述非常多，所以我是先從較實作面的章節，也就是第五章-製作你的第一個個人看板開始閱讀。

第五章提供了一套非常清楚的SOP看板製作流程，讓你在跟著它一步一步操作後，可以好好的整理現在手上各種不同進度的事，清楚明瞭呈現出每件事情的狀態。這邊建議搭配notion筆記軟體或便利貼使用。

個人看板管理示意圖

從上面這個看板或說狀態儀表板，我們可以比較視覺化的看出並回答以下這些問題：

• 你想做或需要做什麼
• 你做了什麼、哪些事還沒完成
• 你怎麼做到的、跟誰一起完成、有沒有遇到什麼困難
• 你做事情的速度如何?

使用看板的兩大重點

• 視覺化工作流程
• 設定看板欄位的WIP(Work In Process)數: 限制每個欄位最多可以同時存在幾件事，要有所取捨

了解事情/任務的範圍

在設定待進行工作時，我們其實要了解工作項目或說任務的範圍。這邊借scrum的概念來敘述該怎麼去設定一件事情或一項任務，書裡寫了三點但我主要記兩點

• 產品待辦(product backlog) =product owner要了解事情的全貌與順序
• 短衝待辦(sprint backlog)= 一輪開發循環就是一個sprint，每輪完成自己設定的目標或任務，如新增一定的功能等，有最小可行性產品(Minimum Viable Product)開發的感覺。

關於設定任務目標，我想到了SMART原則，明確(Specific)、可量化(Measurable)、可達成(Achievable)、與組織或自己總體目標有相關的(Relevant)、有時間限制要在什麼時間之前完成的(Time-based)。

個人看板跟專案看板的差別

了解個人看板形式後，那跟一般專案管理看板差在哪呢?

如果從開發價值流程角度來設計，也就是 需求→估算→文件製作與分析→開發→測試→展示與回饋 的話，一般專案管理看板的呈現形式會如下:

書裡有寫到專案的透明度常常會決定客戶對我們的信賴程度，這點滿有趣的，應該是進度直觀、時間可預測吧。

個人看板的其他形式

個人看板的形式不只一種，也可以是創意及執行結果看板

回來講精實開發跟看板原則

在精實軟體開發中沒有最好的開發方法及步驟，而是一堆原則。這本書提到了精實軟體開發的七大原則及看板這個方法的四大原則及六大實務。

精實開發(Lean Development)的七大原則

1. 消除浪費 Eliminate waste – 盡量避免各種bug，譬如說流程或時間運用上的bug。
   • 避免時間浪費，可使用番茄鐘這種方法來短時間集中精神，提高工作效率
2. 增強學習 Amplify learning – 有效率學習、善用工具、即時測試並得到客戶回饋進行修改。
3. 盡量延持決策 Decide as late as possible – 別在資訊不夠的情況下做決策，把事情優缺狀態都評估好再決定，也就是所謂的想清楚。
4. 盡快交付 Deliver as fast as possible – 客戶需要。
5. 授權團隊 Empower the team – 利用簡單規則管理團隊，並相信大家的能力等。
6. 崁入完整性 Build integrity in – 先求有，再求好=再來重購(Refactoring)。
7. 著眼整體 See the whole – 避免過度注意細節，目的是解決客戶的問題。

詳細可以看一下別人摘錄的 精實開發與看板方法簡介(一)

看板四大原則(Foundational principles)

1. 從既有流程開始優化(Starting with existing process)
2. 同意持續增量、漸進的變化(Agree to pursue incremental, evolutionary change): 最小阻力的改變
3. 尊重當前的流程、角色、職責跟頭銜(Respect the current process, roles, responsibilities and titles): 並常溝通
4. 鼓勵各層級的領導行為(Leadership at all levels): 尊重專業

看板的六大實務原則

1. 將工作視覺化(Visualize)
2. 限制工作量(Limit Work In Progress)
   • 以麥當勞Drive Through取餐行為做了利特爾法則的說明
   • 多工或單工的考量
   • 設計緩衝區(Buffer)
3. 管理工作流(Manage Flow)
4. 明確化規則(Make Policy Explicit)
5. 建立回饋迴路(Establish Feedback Loops)
6. 協同改進，試驗性發展(Improve collaboratively, Evolve experimentally)
   • Dening cycle = PDCA, plan-do-check-action

其他

這本書有講到跟客戶對話時，user story的INVEST原則:

• 獨立(Independent) - 任務內容獨立，讓人可以拆解成若干小任務。

• 可談判(Negotiable) - user story裡的細節不用太詳細，因為這是用來開始對話的。

• 有價值(Valuable) - 了解這項任務對客戶的價值(why)。

• 可估計(Estimable) - user story應該要有辦法讓開發團隊估計需要的開發時間

• 合理的尺寸(Size-right) - 應該要讓團隊在一個sprint(兩週)完成。

  ps. 在網路上有搜尋到S是small，以及一個user story在一個2 week sprint中應該只佔三到四天，這樣才有足夠時間測試及修改。

• 可測試(Testable) - 結果可測試

→ 注意user story的角色、目標、需求活動，再將這些拆解成任務。譬如說使用者(角色)到登入頁面簽到(目標)，可能會有新舊等不同使用者(需求活動)，所以任務有檢查使用者角色等。

結語

本來想用一小時速讀這本書即可，到後來還是總共花了約4小時好好看完並做了這樣一篇筆記…這本書裡面還有提到一些很有趣的思考點，譬如說主管想說專案來不及時增加人手就可以解決了，但其實這可能不是好的做法，因為新人需要學習才能上手，而學習需要有人教，把現有的人力資源拿出來教學，可能會讓開發的作業時辰更慢而已。

這本書確實讓我對精實開發中的看板方法有了一定的了解，及改善了部分我現在的工作流程，但讀起來滿教科書的…滿硬的我覺得。若想了解軟體敏捷開發(Agile Develoment)中精實開發與看板方法，這是一本很棒的入門概念書，推薦給有需要的人。

• ← Previous Post
• Next Post →