看板並不是軟體開發方法, 他是變革管理的方法, 當客戶所提出的需求, 和團隊的能力不匹配時, 它能即時展現這樣的狀況, 讓你能得到警告. 當你實施改進做法, 你也可以從看板上看出, 這個方法是否有效.
那當客戶需求和團隊能力不匹配時, 我們會怎麼做呢? Kanban 的想法是這樣的, 當進來和出去的不能匹配, 會導致每個項目處理的時間變長, 所以要解決的問題是如何讓處理的時間變短, 讓客戶能儘快拿到有價值的商品, 也就是 cycle time 越小越好.
根據 Little’s Law 的公式,
cycle time = WIP (Work in Progress, 同時在進行的工作) / throughput (產能)
這個公式是什麼意思呢? 舉例來說, 你平均 1 分鐘可以處理 3 個工作, 那當你要處理 12 個工作, 大約平均每個工作是 4 分鐘完成
所以如果要 cycle time 越小時, 代表最好產能越高越好, 然後同時在進行的工作越少越好.
那如何根據這個公式來思考解決方案呢? 通常會有兩類做法:
1. 增加能力
這是一般傳統管理人員採用的招式, 透過教育訓練, 或者 On Job Training, 來提升你的能力. 殘忍一點的就是叫你加班, 這樣產能也會在短時間增加一點.
2. 管理需求
這是敏捷開發社群會採用的方法. 大概有兩類
(1). 降低變異性
- 利用拉式系統, 有需求才做, 依自己能力控制處理需求的量, 避免工作量忽大忽小
- 組成 feature team, 相同的人馬去處理不同的功能, 避免因為合作的人不同, 老是花時間在溝通和適應
- 將功能的大小拆解至接近, 可以促進專案評估的準確度, 並且也讓團隊進行的節奏穩定
- 像 scrum 說 iteration 內做的功能不能改變, 也是一種降低變異性的方式
(2). 將大拆小
- 將開發時程拆解成數個 iteration, 讓進度可以被管理, 需求可以調整和及早看到
- 將每個大的功能拆成小的 user story, 期待在每個 iteration 完成數個 story
原來這個公式這麼神, 把 agile 做法的原理都囊括了.... 最好是啦
留言列表
