除了前面所提到的 Sprint 衝刺法外，另外有種 Kanban 法，也是一種幫助團隊開發的工具。

看板法（Kanban Method）。

看板以「可視化現有工作流程」為起點，先不要求團隊做出巨大的改變，以減少採用新方法的抗拒。接著，依據團隊的現有人力，設定每一個工作階段的WIP（同時施工項目的數量），以協助團隊成員聚焦於「把工作完成」，而非不斷地製造「賣不出去的半成品」。

在知名部落客 Henrik Kniberg 的 Kanban vs. Scrum文章中，提到Scrum有9條規則，而Kanban只有3條。

「規則」規定，團隊使用如下：

1. Scrum主管（Scrum Master）
   2.產品負責人 （Product Owner）
2. 開發團隊（Team）
3. 計畫會 Sprint Planning Meeting
4. 每日立會（Daily Scrum）
   6.衝刺評審（Sprint review）
5. 產品訂單（Product Backlog）
6. 衝刺訂單（Sprint Backlog）
7. 衝刺燃盡圖（Burndown Chart）

Kanban只要求下面的幾點：

1視覺化工作流
2.限制以流程為工作中心
3.權衡和優化工作流

追蹤流程使用的測量不同

在Scrum中，團隊使用反覆運算方法，它是指「定時」或在特定的時間內做增量，稱作衝刺，通常情況下是2-4周。在每一個反覆運算的開始都會有一個衝刺計畫會議，會議上從產品訂單中選擇出案例，選擇出案例在下一次反覆運算中開發。

為了確定出在每一次反覆運算中的工作量，團隊的執行將會通過「燃盡圖」進行跟蹤，此圖中X軸代表需要完成的工作預估，Y軸是反覆運算時間表。燃盡圖衡量著團隊的「周轉率」，此「周轉率」是一個測量，展示出團隊在反覆運算中的生產效率如何。

評估每一個安全的任務，通常是用「安全點數」表示是有必要的，從而可以正確地分割工作，分割成他們可以在一次反覆運算中完成的大小。

在Kanban中，使用不同的衡量方法來確定專案是否要被跟蹤。佇列用來表示工作流。例如，一個佇列在清單中包含了所有專案，一個佇列給開發，一個佇列給測試，還有一個佇列給部署。通常會使用一個Kanban面板，把案例卡片隨著進程在面板上移動。

不是定時一個案例，要求在一次反覆運算中此案例必須完成，Kanban限制了WIP或以流程為中心的工作。團隊必須給每一次活動確定WIP限制，但是一旦滿足了WIP的限制，團隊成員必須一起工作，清除所有的阻礙區域。整個生命週期時間就是完成此案例的時間。隨著時間對此進行測量，團隊交會瞭解多長時間他們會完成所有案例。Kanban支援者相信使用週期時間最終會允許團隊在他們需要時做出準確的估計。

角色和會議不同

Scrum定義了非常具體的角色和必須舉行的會議。必須有一個Scrum主管、一個產品負責人和一個開發人員團隊編碼和測試案例。Scrum主管推動會議並説明所有阻礙團隊進程的障礙。產品負責人代表業務人員或使用者，説明闡明案例並區分先後次序。

Scrum規定要有一個衝刺會議來確定哪一個案例要進行衝刺。有一個日常Scrum會議，有稱為站立會議，它是一個簡短的會議，讓團隊明白瞭解前一天每一個成員都做了什麼、他們今天的計畫和所有的阻礙。在衝刺的最後，有一個衝刺審查會議來演示所做和的軟體，並進行回顧，檢查什麼進行良好，及什麼需要改進。

Kanban不要求有像Scrum定義的角色和會議；然而，許多從Scrum方法轉型的團隊維持了在他們Scrum團隊中使用的角色和會議。Kanban沒有規定衡量和優化流，因此團隊沒有看到專案的測量和工作方向的持續改進。

轉變不同

比Kanban更規範的Scrum通常對軟體發展團隊來說更難以轉變。有一個特定的必須遵循的框架，而且如是團隊現在正在使用轉型的軟體發展方法，那麼對於團隊來說將是一個很大的轉變，全新的工作方式和新角色。

Kanban設計為開始于你正在使用的流程，而且工作方面持續改進。團隊鼓勵去映射他們目前的工作流流程和確定瓶頸。該流程是為了進化到一個獨特的和優化的工作流程的團隊的一種手段。

Scrum和Kanban是互補的嗎？

正如我們所看到的，Kanban並不意味著左右你的方法，而是通過優化改進流程流。Kanban可以和Scrum一起使用，儘管在案例或任務分配和衡量的方式上存在不同。無論是Scrum還是Kanban的實踐都可能使用視為「敏捷」的技術，如測試驅動開發或持續集成。在這兩種情況中，團隊的工作方向是衡量和改進。

Cite by :

Scrum vs. Kanban：软件开发新方法大比拼

泰迪軟體

回到 軟體工程の學校專題怎麼做-Leason(3)團隊合作