巧用Scrum與Kanban

Scrum · 發表 2018-09-19 09:01:20

摘要：本文來自網易雲社群文\屈鵬飛在網際網路行業的專案管理實踐中，敏捷和精益一直是大家所提倡的思想，其中Scrum和Kanban方法作為即敏捷又精益的典型代表，許多PM都在研究，筆者近期也在學習和實施Scrum和Kanban方法，有些感觸拿出來與大家一同分享。 Kanban方法最初起...

本文來自網易雲社群

文\屈鵬飛

在網際網路行業的專案管理實踐中，敏捷和精益一直是大家所提倡的思想，其中Scrum和Kanban方法作為即敏捷又精益的典型代表，許多PM都在研究，筆者近期也在學習和實施Scrum和Kanban方法，有些感觸拿出來與大家一同分享。

Kanban方法最初起源於豐田的JIT（Just In Time），之後作為一種高效管理軟體開發流程的技術和思想應用於網際網路行業。Kanban方法以價值流動為核心，不斷髮現團隊中的瓶頸工序，進行改進，使價值流動更加順暢和快速。

Scrum源自於橄欖球的一種爭球方式。現在作為一種迭代式增量軟體開發過程，通常應用於敏捷軟體開發。Scrum將工作分解成較小的功能單元，並在週期性固定的時間段內持續的交付。

在團隊的專案管理實踐中，我們往往將二者的優勢結合起來綜合的使用，以便幫助團隊更好的完成目標，而不是為了使用方法而使用方法。本文簡單的比較一下二者的不同，希望能幫助大家在實施過程中找到最合適的方法。

區別一：實施過程中關注核心的區別

Scrum實施的核心可以概括為“化繁為簡”，從幾個維度解釋下：

團隊角色的定義，將團隊人員定義為三個角色，Scrum Master（主要負責消除障礙，帶領團隊運作）、Product Owner（主要負責描繪產品遠景，定義優先順序）、Scrum Team（主要負責實現產品）
工作任務的拆分，將產品需求拆分成小的使用者故事，並評估優先順序
時間的拆分，將專案週期拆分成固定時長的迭代週期，每個迭代交付一部分可驗收的功能，通常迭代長度為1到4周

Kanban方法在實施的過程中更多關注的是視覺化的價值流動，從幾個維度解釋下：

拉動式生產，下游工作完成後，主動拉動上游的任務移動
限制WIP（work in progress），明確設定限制每個狀態下，同一時間內有多少工作量，減少同一狀態同一時間內，任務和價值的堆積
視覺化的價值流動通常是端到端的流動，直觀的反映使用者的價值（通常是可交付的使用者需求），並且反映出在價值流動過程中的瓶頸和問題，不斷為團隊改善提供依據

區別二：限制WIP數量的方式不同

Scrum與Kanban方法都會限制在製品數量，不過限制方式有所不同，Kanban方法限制的更加直接，同一狀態同一時間內的工作任務有最大限制；Scrum是間接性的通過迭代（sprint）來限制。限制WIP的核心目的是加速交付使用者需求的價值流動。

區別三：對任務變更管理的不同

在Kanban方法的中，下游任務完成後，即可拉動上游任務下移，同時，只要生產力允許，即可新增需求。

在Scrum方法下，當每個迭代的sprint Backlog確認後，當前迭代是不允許新增需求的，新增加的需求可以體現在下個迭代的sprint backlog中。

區別四：改進依據的不同

Scrum是以生產率作為計劃和改進的依據，以迭代（sprint）資料作為依據，分析迭代的相關資料（包括生產率、完成率等）；Kanban方法是使用生產週期作為計劃和過程改進的依據。

Scrum和Kanban方法作為即敏捷又精益的典型代表，除了上述不同外，還存在很多相同點：

二者都和敏捷與精益相對應。敏捷中的持續改進思想在Scrum和Kanban都有所體現，而且是很核心的一個內容；精益中的拉動式生產在Scrum和Kanban中也都分別覆蓋，Kanban方法體現的更加直接，下游直接拉動上游的工作任務。
二者都關注儘早的交付價值，儘可能頻繁的釋出可使用的軟體。Scrum將整個專案週期拆分成多個迭代，每個迭代釋出可驗收的軟體；Kanban方法在每個功能開發測試完成後就可以進行部署和釋出。
團隊狀態都直觀的反應在Scrum board和Kanban Board上，方便找到問題和瓶頸，並進行改善。

比較了Scrum與Kanban方法之後，如何結合二者在團隊中進行專案管理實踐呢？筆者結合自己的經驗從迭代、版本、變更、改進四個方面給大家進行一個簡單的介紹。

迭代：在Kanban方法中，並未規定明確的迭代，而在Scrum中是規定了固定的迭代週期。在我們的團隊中，迭代週期從一月一迭代，逐步變為一月兩迭代，到現在的兩個自然週一個迭代，完全固化了迭代週期的概念。

將複雜開發週期很長的開發任務，分解成多個迭代週期，每個迭代週期交付一些可驗收的軟體或者功能。有利於減少風險，並更好的適應變化，及時的根據反饋調整工作目標。

版本：在迭代中，我們以排入版本計劃的功能點（story）作為工作重點，排入版本的story為互動已經完成的功能點（story），這些功能點可以直接進入開發和測試環節。這些story便是我們當前迭代可以交付的功能或者軟體。與此同時，產品、互動和視覺同學會繼續拉取需求池中的功能點，開始進行設計，準備下個迭代版本中的內容。使整個價值流動更加順暢。

變更：對待變更，我們同樣有自己的一套流程規範，既沒有像Kanban方法一樣，只要生產力允許，便可以新增需求；也沒有像Scrum一樣，版本內容確定，當前迭代基本不允許變更。在實際過程中，當存在緊急需求，由產品經理髮起，和各個角色進行評估風險和對現有版本的影響，並採取相應措施降低由於需求變更對整個系統產生的影響，最後由專案經理髮出變更通知的郵件。