Scrum&Kanban在移動Team Dev的實踐 （二）

標籤：

Scrum&Kanban在移動Team Dev的實踐系列：

Scrum&Kanban在移動Team Dev的實踐 （一）

Scrum&Kanban在移動Team Dev的實踐 （二）

 

在第一篇分享文章中介紹了下Scrum的開發模式，介紹了Scrum中團員的角色、開發階段、每個階段中需要做的事情。在這篇分享我會介紹Kanban模式，相對於Scrum，Kanban比較輕量級。

首先分享些乾貨：

Kanban和Scrum對比的Mini書：Kanban and Scrum - making the most of both  中文

 

下面是一個非常經典的Kanban圖

看板強調幾點：

1. 流程可視化
2. 限制WIP （Work in Progress）
3. 度量生產周期

流程的可視化 

想所示，Kanban強調的可視化流程，通常團隊可以把需求分解成小任務，一個小卡片寫一件任務，把卡片放到牆上。其實現在有很多敏捷開發工具都可以支援可視化管理，不過我還是建議貼在牆上這種“原始”做法。這樣可以“強制”所有的成員非常容易的看到整個Kanban，有什麼問題、更新都能一目瞭然。

• 每個任務都會有不同的狀態，所以在牆上每列需要定義狀態。我們的做法是分成Next、Analysis、Development、QA四個階段，每個階段都有Ongoing和Done兩個子階段。
• 每個階段都有Ongoing和Done的狀態，每個階段的"Definition of Done"需要精確定義，保證所有團隊成員對完工定義達成一致。以下是一些定義的例子：
  • Analysis - Definition of Done: Backlog建立好了，提供需求描述，提供MockUI
  • Development - Definition of Done: 功能實現，程式員自己進行過測試，通過Unit Test，進行過Code Review，代碼合并到Develop分支
  • QA - Definition of Done: 完成功能測試，修複所有高優先順序的bug
• 每個任務盡量細化，保證不超過一個星期的工作量。
• 每個任務都是分配給特定的一個人。如果是多個平台一起合作，比如iOS/Android/Server，可以把任務拷貝幾份分配給不同的人，這樣可以保證開發人員對這個任務具有Ownership。

下面是我們團隊實踐的Kanban牆：

• 四個階段（列）:Next, Analysis, Development, QA。每個階段都有Onging和Done。
• 四個小團隊（行）：Android, iOS, Web, Server

看到字條在最終狀態越積越多還是很有成就感的！

 

限制WIP（Work in Progress） 

在看板裡面一個核心的概念就是限制WIP，簡單的說就是每個狀態下面的Ongoing的任務數目是有上限的。這樣做可以帶來不少好處

• 可以讓團隊成員更加專註
• 一旦發生任務阻塞，團隊會第一時間知道，並且很容易發現問題，這時團隊可以集中精力解決阻塞的問題
• 每次計劃任務的時候都會考慮首先做最重要的事情，避免後期隨便加塞任務

下面的漫畫很好的描述了WIP的作用，大家可以領會領會：

 

 

WIP的模式看起來很美，但實踐起來並不容易，需要大家非常遵守WIP的限制嚴格執行。很多時候團隊會迫於外部的壓力，不斷增加工作，於是kanban上面的小字條越來越多，這樣其實是非常影響效率的。所以Kanban模式也是需要一個類似Scrum Master的角色來保護這些原則。

WIP的設定數量應該是多少呢？其實這個因團隊而異，可以不斷調整至到大家都覺得比較舒適的狀態。一開始可以建議簡單粗暴的設定，比如開發人員有多少人，就設定Development WIP的數量是多少。

 

度量生產周期 

Kanban的模式並沒有固定的開發週期，也沒有特定的計劃、開發、發布的階段，所有的事情都是想流水線性一直持續下去。那麼Kanban模式如何來評估生產的效率和周期呢？

一般會參考 - Cumulative flow diagram (堆積圖？)

這個圖統計了每一天，在每個狀態中累計的任務數量。縱向可以表明WIP的作用，橫向可以表明每個任務完成所需大概時間。

我一般會重點查看每個狀態的趨勢線的斜率情況，斜率越大說明任務開發所需的時間越少，團隊效率越高。同時也要保證各個狀態趨勢線的平滑性，斜率要大體保持一致，這樣說明任務沒有在某個狀態下積累太多而影響整體交付效率。

 

Kanban相對於Scrum的模式並沒有太過於繁瑣的條條框框，就只強調三件事：

• 可視化的流程
• 限制WIP
• 度量組建循環

Kanban是個非常高效的管理工具，但因為缺少了很多Scrum的規範，實際操作起來並不容易，在現實世界Kanban往往和Scrum一起使用，相互吸取經驗融合使用。

 

Scrum&Kanban在移動Team Dev的實踐 （二）