最近在看 David J Anderson 所寫的 Kanban, Successful Evolutionary Change for your Technology Business. 裡面描述到了, 當初 David 為什麼會想提出新的做法, 最主要是他遭遇到了兩個問題
1. 如何維持可持續的步調
在敏捷宣言中的原則, 提到了希望可以維持可持續的步調, 在 XP 中的意思, 就是要維持 40 工時. 我想這件事情, 對很多軟體工程師來說, 是很遙不可及. 大家常常要工作的很晚, 無法兼顧家庭與工作. David 希望能有方法, 讓成員不要這麼辛苦.
2. 如何進行變革管理
David 的工作, 主要是專案管理, 或是企業中的軟體開發顧問, 因此會需要在企業中推廣敏捷開發的做法. 可是他發現到這件事情十分不容易, 不是大家都有意願想要嘗試新的東西. 此外, 每個公司有不同的環境, 不同的成員, 新的開發方法不可能不做修改, 就能適用到所有地方.
在有了這兩個主要問題後, David 初步的想法, 看看是否能夠從這兩個角度去解決問題
1. 找出瓶頸解決問題
最好的進行變革的方式, 是根據痛點來改進, 並且一次只進行一小步驟. 因此他想利用 flow, 把目前工作流程以視覺化方式表示, 當有工作 流經這個 flow 時, 觀察其狀態變化, 識別出瓶頸在哪裡, 然後加以改進.
不是一開始就加入新的東西, 而是由原先的做法出發, 不斷消除一個又一個的瓶頸, 逐漸演進到敏捷開發想要的做法. 這個方法其實就是限制理論 (TheoryofConstraints)的想法
2. 利用 WIP 限制同時進行的事情
因為有了 flow 和 TOC 的思考, 所以 David 打算可以在瓶頸的地方, 限制同時能夠進行的工作數量. 每當瓶頸的地方, 已經達到最高的量時, 其他人便會有 slack time 出現, 因為他無法再拿工作來進行. 這時候他可以選擇, 去幫助處理瓶頸地方所遭遇的問題, 也可以利用這個時間休息, 或是加強自己的技能.
這時候管理階層, 需要去思考如何讓瓶頸消失, 只要讓瓶頸能夠不見, 或是瓶頸能處理的量變大, 自然整個團隊的速度就會變快. 但是方法絕對不是, 讓其他剩下的人, 繼續去接更多”新"的工作, 也就是提高傳統所謂的利用率, 哪只會讓團隊很累, 但是不會比較快.
經過這樣的介紹, 大家有對 Kanban 的做法, 有簡單的了解了嗎?
留言列表
