很久沒有用 Trello 了，因為最近的專案一直找不太到適合的軟體來統整各方面的需求，於是就想說回頭用看看 Trello 來進行整理，基本的 Todo、In Process、Done 這幾個欄位也大概知道要怎麼用，但隨著進行的項目越來越多，Todo、In Process 越拖越長，卻不見 Done 的增加，開始懷疑是不是自己能力不足所以工作都消化不完 Orz…
直到上拜天去圖書館尋寶，找到這本 Ruddy 大大的大作「精實開發與看板方法」，才驚覺自己完全根本不知道什麼叫「看板」，還以為 Trello 就是看板，還以為只要會拖動卡片就是看板，真是搞笑了啊啊啊～
本書分為八個章節，從基本介紹到看板設計，再到團隊與個人如何運用看板方法，最後還提到如何以系統思考來預測專案很難預知的各種變數，最有感覺的地方是看板一日遊的解說，非常契合自己以往在團隊中的開發經驗，以下就書中精華進行重點式摘要：
精實軟體開發七大原則
1、消除浪費 Eliminate waste
製造浪費的最大兇手是 Bug，只要保持程式碼的簡單可以避免 Bug，但現在軟體開發的環境越來越複雜，保持簡單不是一件容易的事，所以要可以真正的去了解程式碼，一知半解最容易造成 Bug。時程的預估都只是瞎猜，只有當專案開始時才能慢慢的掌握開發時間。 如何判斷浪費發生：
一、半成品 Work In Process (WIP) 太多，控制在越小越好。
二、額外過程：對專案不會產生價值的業務， 像是過多的行政文件整理。
三、多餘功能：減少非必要的程式撰寫，新功能意味著新 bug 的可能。
四、任務調換：多工 is evil，思路被打斷要重新進入很浪費時間。
五、等待：等客戶的回應是必然的等待。OS: 這種等待真的是非常討厭，最近非常有感，一個問卷的評分方式請客戶提供結果等上了兩個禮拜，重點是還跟初期的規劃邏輯完全不同，一來一往就消耗超多時間。
六、移動：簡單說就是卡關了要花多少時間去解。OS: 平常要做好給自己看的文件，尤其是開發環境的配置，卡在環境配置真的滿累人的。
七、缺陷：就是 Bug，能越早找到越好。OS: 要開始練習寫測試案例了，不然都只是自己盲目的瞎測，給夥伴測試時也才有測試方向。
2、增強學習 Amplify learning
卡關時能學到的東西最多，別一知半解的找到答案後貼上就沒事了，多了解一下是怎麼解決的，然後整理成文件，另外在有盈餘時間時進行重構是最高效的學習方式。
測試是最好的回饋，回饋要及時，寫完一段後就要進行測試，透過寫單元測試來核對程式碼的邏輯，最重要的是可以及早給客戶展示收集回饋，進而調整接下來的開發方向。
3、盡量延遲決策 Decide as late as possible
狀況還沒搞清楚的情況下就做決策，容易白做工而造成浪費，所以決策能拖就拖，拖到不做決策的成本高於做決策時， 就該做出決策了。
4、盡快交付 Deliver as fast as possible
別等到全部做完才給驗收，會讓驗收時間不夠， 進而影響到修改時間，及早交付以才能分清楚接下來工作項目的輕重緩急，看是要先修改客戶在意的項目，還是繼續開發其他功能。
5、授權團隊 Empower the team
在適當的規範下，讓團隊自己做出決策。
6、嵌入完整性 Build integrity in
接受需求變更是常態，透過持續的客戶回饋設計出理想中的系統，並保持架構的靈活。
7、著眼整體 See the whole
設定團隊開發目標避免拘泥於細節。
什麼是看板方法？
看板方法是半成品的約束系統，白話說就是要限制目前手頭正在做的工作數量，要等手上做的東西完成後，才能去拿新的工作來做，透過限制半成品的數量來找到最有效率的開發準則。
看板方法的實行步驟：
整理現行工作流程 > 把流程視覺化放進看板 > 限制每個流程的半成品數量 > 管理工作流程 > 讓規則明確 > 落實回饋循環 > 由協助改善經實驗演進
設計看板牆的三個基本元素
- 範圍(整個工作的流程)
- 工作項目粒度(大工作還是小工作)
- 工作項目狀態(已完成 or 未完成)
看板核心要素：
- 要有 WIP 限制
- 採用拉動系統，東西處理完後才能做新東西
- 有設定緩衝區
- 完成的項目先別刪，可以留著檢討完後再一次刪除
- 專案還沒開始時被要求估算時間，回答請再多給我一點時間進行評估
如何使用個人看板？
先把手邊的工作進行視覺化，依照待進行工作、準備中、今日工作、等待中、正在進行的工作、完成的這幾個項目來進行分類，個人專案看板的部分包含：衝刺工作項目、預備(分析及文件製作)、開發進行中、開發已完成、測試、發佈。
原本我使用 Trello 來進行設計，但發現他沒有辦法跨看板來進行統整。書中提到要可以有總覽的檢視介面來查看所有專案的狀態，試了幾套線上的服務，發現到 Ora 這套服務功能比較齊全，且介面是我比較過最美的，但可惜的是他沒支援 WIP 的設定，看在他介面這麼優的前提下，只好自己想辦法弄了～
上圖是我自己的個人看板，主要紀錄專案以外的事，中間上方可以快速切換看板，看板欄位的標題顏色都可以自己設定，會設成黑黃純粹是個人喜好XD。 第二欄準備中後面有個括弧 2，指的就是我給自己設定的 WIP，也就是說在準備中的工作事項不能超過兩個，有空位的時候才能從待進行工作拉入新的工作事項。
同理，正在進行的工作的 WIP 也是設為 1，我的個人事務在一個衝刺時間內只做一項。 Ora 特別的地方在於說他的 List 有分為四種狀態：分別是 Frozen、Open、Review、Closed/Compledte，前兩者主要是控制這個 List 內的工作事項在 My Tasks 中是否可見，切換成 My Tasks 可以看到已被拉入 Open 的工作事項。
我在 MyLife 中把「看板方法讀書心得」拉入了準備中的這個 List，而這 List 的狀態是 Open，所以「看板方法讀書心得」的工作事項就會出現在 My Tasks 的 Inbox 裡面，最後我再從 Inbox 移動到要哪一天進行，這樣就能分配我今天、明天甚至是後天要做什麼。
專案的部分概念相同，理論上會有一個產品待辦項目，來紀錄這個專案需要開發的所有功能，把產品待辦項目拆解後就會進入衝刺工作項目，也就是在設定好的一個工作週期要來進行的任務，當中專案負責人會依據客戶需求來決定衝刺工作項目的開發順序。
同樣的，在預備跟開發-進行中的 List 後面也都有 (2) 的提示，代表這兩個階段只能接兩個工作事項，到了開發完成後後面還有一個 List 是測試，測試的內容就是要根據預備階段時整理好的測試案例來進行功能測試，沒問題後就可以 Demo 給客戶驗收。
驗收的結果有可能是需要修改，這時候就專案經理就要詢問客戶的意見，看是要先修改這個剛完成的項目還是繼續開發其他功能，藉此來決定接下來是哪個工作事項要進入預備階段。 Ora 還有許多功能，像是有開啟計時的話就會有上圖的報告：
可惜的是，Ora 沒有提供 WIP 的設定，所以也就沒有書中提到最重要的「累積流程圖 CFD」，這圖可以看出專案有沒有失控，尤其是接了太多根本做不完的需求，或是從中發現 WIP 的設定是否恰當，但以個人的專案來說，這套工具算是還夠用。
在預備階段的文件製作，作者提到需要製作系統文件以及測試案例的資料，看了很久一直不知道到底該怎麼撰寫，結果在書末的附錄就有完整的示範，然後又在 Google 的時候直接發現作者 Ruddy 大大的這篇文章，裡面提到一個工具叫做 FeatureMap 可以非常容易的做出 User Story Mapping 的展開圖，實在是非常方便，這次的專案就打算用它來練習撰寫測試案例。
個人心得
看完這本書之後，告訴自己希望可以做到以下這些事：
- 找到答案複製貼上，不明白為何這樣寫，也許會造成其他問題也不知道， 還是要搞懂，然後把不需要的 code 拿掉
- 每個功能的流程要搞清楚，梳理出文件來確保沒有遺漏的狀態
- 常用的功能流程就差不多，沒做過的功能要特別注意
- 要學會寫文件交接給自己
- 從新檢視自己寫的東西進行重構，才能學到越多
- 做完一個工作事項再拉一個進來，就能看到目前累積的工作量
- 需要做決策時用七大原則來檢視目前的狀況
- 從既有流程進行小規模改善
- 功能一寫完就進行測試，別等到全部做完後再回來修改， 這樣可以提升交付程式的品質
- 工作事項要完成的前提是要經過測試
感謝 Ruddy 大大的這本好書，接下來就是要進攻自動化測試喔喔喔～ 附上老師的部落格，裡面超有料—>https://ruddyblog.wordpress.com
