【看板方法】課後心得 之一

圖片來源：www.freepik.com

當初上完課，很激勵地寫下當時的心得，現在回頭看，不太符合現在閱讀的習慣，所以重新整理成較適合閱讀的系列作，這回將主要分享看板方法的精神與原理，後續會陸續更新，第二回則是視覺化的作法，第三回是 WIP Limit 的使用，最後是落實與其他感想。

雖然看過 Ruddy 老師的《精實開發與看板方法》，也整理了不少重點 (參閱：書摘《精實開發與看板方法》)，但總覺得少了點什麼？碰巧趨勢科技的柯大哥在資策會有開課 (現在沒了，因為變成講師的我，很懶 XD)，加上又有公司全額補助，就決定跑去上課了，兩天的課程收穫很多，除了從看板遊戲體會到不少東西外，一些觀念也更加清楚，也發現到自己有西東西並沒有很清楚，只是上完課到實際回到團隊中使用，還是有很多小東西要注意。

什麼是看板方法？

首先看板方法不是軟體開發方法，也不是框架，原先是豐田為了達到零庫存，用來優化生產線使其能用最少的資源，在顧客下訂單後開始生產，以最快的速度交付給客戶，一種優化生產線的方法 (用抽象的角度來看，像是從生產線的末端，向前拉動生產線的生產，以減少庫存，不是從前端不斷地生產來推動下游，因此是一種拉動系統)，後來衍生到軟體開發上，但本質還是一樣，看板方法是優化流程的方法，把看板方法與其他開發方法搞混了，就會常常撞牆鑽不出來。

精實精神

看板方法受到蠻多精實軟體開發的精神影響，所以在了解看板前先知道精神軟體開發的核心精神(或稱原則)：

• 消除浪費，軟體開發常見的浪費：
• • 半成品 (work in progress)
  • 額外過程，像是寫非必要的文件
  • 多餘功能，當時間緊迫時，能被捨棄或切割掉的通常就是多餘的 (假設產品負責人不是亂捨棄與切割)
  • 任務轉換，基本上就是避免 context switch 過多
  • 等待，這應該沒什麼好說的
  • 缺陷，如果沒 bug 就不用修，多好...現實中不可能啊~
• 增強學習，軟體開發本身就是一種學習的過程
• 盡量延遲決策，到資訊充足或是不做決策的成本要比做決策的成本高時才做決策
• 盡快交付，我想應該沒有客戶喜歡等待...
• 授權團隊，這點很有趣，幾乎所有的書都說，能自我管理的團隊會是最有效率的團隊，但在台灣通常還是有無形的手在後面...
• 著眼整體，局部最佳化不等於整體最佳化，甚至會傷害整體最佳化

原則與實務

看板方法本身還是有些核心原則：

• 從既有的流程開始，因為看板本身不是開發方法，也不是框架，所以要從團隊本身既有的流程開始優化
• 同意持續增量漸進的變化，越是大幅度的變化，越容易引起團隊反彈，而且最好從痛點改起
• 尊重當前的流程、角色、職責和頭銜，基本上優化不是搞革命，就這麼單純
• 鼓勵各層級的領導行為，如果要層層上報才能做決定，那優化根本不會成功

上述是原則，但實際上執行可透過六個實務來優化流程：

• 視覺化，將流程視覺化，協助找出問題在哪裡
• 限制半成品 (WIP) 數量，凸顯瓶頸，並促使團隊成員解決瓶頸
• 管理流程，基本上就是優化流程
• 制定明確方針，越是簡單的方針，團隊成員越容易遵守
• 落實回饋，鼓勵團隊提出建議，並讓建議成真
• 協同改進，實驗性演進，分析問題時善用數據

前三項完成就有看板的雛型，後三項是強化優化的效果。

精實與 Agile 的差別

精實開發的精神與 Agile 在蠻多地方其實有點接近，事實上也不相違背，但個人覺得最主要的不同是，Agile 重在快速因應變化的能力，所以像 Scrum，以 sprint 衝刺的方式，讓 PO 與客戶在每個 sprint 結束後下個 sprint 開始前都有調整產品方向 (透過調整 story 的優先度)，避免過度設計，透過每個 sprint 少量的時間進行 refinement，讓設計因變化所受到的衝擊減到最小。而精實重在持續快速交付價值，所以看板方法強調在優化流程，排除浪費，消除瓶頸，都是為了能快速交付。但並不是說 Agile 就不是快速交付，而是在因應改變與快速交付中取得平衡，所以 Scrum 也是有自省會議，讓團隊能更加進步。

小結

這篇先簡單說明什麼是「看板方法」，內容看起來也許會有點抽象，但下一回，就會實際開始使用看板方法，首先便是視覺化，讓團隊可以「看到」工作實際的樣子。