敏捷工作法百百種，哪一個適合我？專家：３大類別必須了解

● 工作量（WIP）限制

攤開流程後，下一步就根據工作狀態差異，限制團隊成員負擔。具體來說，是減少「半成品」，也就是未完成工作的數量。

另方面，待辦事項也不能無限制增加，甚至隨意被加入優先處理項目。產品經理或是主管應該配合總量管制。否則最終只會造成看板上的混亂，違反流程優化的初衷，減損效益。

● 管理工作流程

藉由工作透明化，可了解每項任務在不同流程間花費的時間，包括前置時間（lead time，從流程開始到結束的時間）以及循環時間（cycle time，不同階段所需時間），並且以此作為後續檢討基礎。

專家建議：柯仁傑分析，看板的本質在於「變革管理」，特別之處是，一開始不會改變既有流程，而是將工作流程透明化，讓成員看到問題所在，再從這些問題開始修正，進而提高變革意願。

此外，目前也有不少如“Trello”這種流程管理App，可以協助推動看板系統。

Attention：這些方法可能讓組織不敏捷

1. 瀑布式開發（waterfall）

敏捷式開發工具陸續問世後，瀑布式開發被視為較為傳統的開發模式。大體而言，就是將開發流程劃分為不同階段，並且以線性方式串連，就像瀑布流水一般。

瀑布式開發的優點，在於建立標準流程，以及清楚分工與責任歸屬；但由於是線性開發，往往得到流程末端才能看到成果，增加風險。

此外，如果需求改變，開發成本就會大幅增加，因此面對變化愈來愈快速的環境，敏捷開發成為優於瀑布開發的模式。

2. 隕石開發法

「隕石開發法」並非業界存在的開發模式，而是源自日本網路社群，用以嘲諷業界現象而產生的名詞。

簡而言之，就是不論設計任何模式，只要「神的旨意」一下，就像流星雨一樣，不論時間表或是任務分工，都會全部崩壞，而身為平民的開發者只能事後努力重建機制。即使是最重要的使用者回饋，也無法被「神」接收。

雖然充滿「惡搞」意味，但不可否認，這是許多上班族與開發者的心聲。力圖導入敏捷開發的公司與團隊，都可能因為無法突破既有的科層體制或成見，而形成徒具形式的「假敏捷」。