基於JIRA的精益Kanban開發一次有效的嘗試n--某產品團隊精益轉型實戰案例

一、 團隊改進前概況

屬於技術平台產品團隊，產品屬於公司核心產品部件。團隊成員包括產品經理1人，開發8人，異地測試3人，運營1人。

團隊工作特點：

1. 並行多個產品的版本在開發；

2. 需要與其他產品組有較多的技術協同工作；

3. 有大量的緊急外部用戶反饋需要響應；

4. 有內部緊急需求需要及時實現；

5. 存在異地團隊（開發在北京、測試在西安）。

團隊轉型之前面臨的問題：

1. 迭代計劃外臨時任務插入較多，且優先順序很高，影響迭代計劃不能按時完成。

2. 任務完成標準不是很清晰（開發和測試任務分開）

3. 迭代過程中，雖然站會也會暴露進展風險，但是計劃調整的很少

4. 開發、測試、需求很多時候兩兩達成了一致，三方信息的同步不及時

5. 任務估點不太準確，過程中無調整

6. 臨時發版較多，對現有迭代計劃造成衝擊

7. 產品版本規劃不清晰，不了解具體的版本內容

團隊轉型之前的研發現狀：

1. 團隊在走2周的迭代，迭代計劃完成率低下；

2. 產品新特性開發和用戶反饋處理工作交織進行，團隊手忙腳亂；

3. 團隊成員不停加班。

二、 團隊改進後效果

團隊改進歷程

精益敏捷轉型歷時8個月後，團隊完成精益Kanban開發、用戶故事、版本規劃、產品Backlog梳理的導入和實踐，團隊的精益研發規則能夠獨立運轉。

團隊階段改進成效

1. 產品版本由改進前1個月臨時發1次版提升到平均1個月有規劃發2次版；

2. 產品版本BUG解決率由80%提升到100%，BUG總遺留率由18%降到2%；

3. 團隊交付速率由4點/工天提升到8點/工天，提升1倍；

4. 特性用戶故事平均交付周期由16天降至8天，提升1倍。

三、 改進啟發

當產品已經正式上線運營了較長時間，已經存在大量的外部用戶，研發團隊同時需要並行解決大量緊急的用戶反饋和計劃中的產品新特性的實現的時候，對於這種軟體產品處於運營與新特性開發並存的階段，精益Kanban方法和SCRUM相比，可能Kanban方法會更適合於這種應用場景。

Kanban方法實施中，很多團隊使用的都是物理看板。但是在產品生命周期較長，有遠程異地團隊，需要自動強大的度量功能作為改進助力的團隊而言，電子看板的支撐就顯得尤為重要。

本案例就是針對處於運營與新特性開發並存階段的研發團隊，通過使用JIRA工具系統化完成精益Kanban開發核心實踐的實現，進而形成團隊較成熟研發規則，並獲得一定改進成效的實例。

本案例成功的意義主要有兩點：一是系統化使用JIRA電子看板在公司一線的產品團隊驗證了精益Kanban開發方法的可行性；二是對產品已經上市，新特性開發和反饋處理工作並存的團隊如何更加精益管理研發過程提供了解決方案。

JIRA工具系統化支持了Kanban五大核心實踐的實現，具體如下：

1. 可視化價值流。JIRA實現了團隊從需求創建到產品版本發布的全價值流；定義了3大類工作項類型，並針對不同類工作項設計了不同的工作流；多角度定義了看板的泳道。

2. 顯式化規則。團隊定義了看板列標準，實現了4類服務等級協議的設置。顯式化了系列團隊規則。

3. WIP限制。看板列定義了WIP數量的約束，並在工作流中有效調整。

4. 管理流動。基於PDCA理念，產品驅動開發，團隊定義了發布規劃會議、計劃會議、Kanban每日站會、總結回顧會完整的管理反饋環。

5. 建立反饋、持續改進。通過管理反饋、看板反饋等各種反饋的建立，團隊能夠快速發現存在的問題；團隊採用過程分析定性獲得問題產生原因，度量統計能夠更精準定位團隊的問題，並支撐問題分析；通過有依據的改進行動指導持續提升團隊。JIRA在度量統計方面提供了強大的功能，強力支撐了團隊的持續改進工作。

本案例的團隊在改進前進行敏捷迭代開發，改進後採用Kanban流式開發。在這裡我們不禁有一個疑問： 這個團隊在使用Kanban後有明顯的改進成效，能夠說明流式開發更優於迭代開發（SCRUM）嗎？

對於兩種模式的適用場景，一般認為，迭代開發較適用於新產品的特性開發；流式Kanban開發適用於交付周期不固定、技術探索性較多、研發和運維相互交織等研發場景較複雜的項目。那麼除此之外，這兩種模式在哪些方面會對團隊有不同的影響呢？

從團隊認知角度來看，SCRUM具有更清晰的框架；從團隊接受角度來看，Kanban因為其漸進性更容易被接受、被消化，團隊轉型成本也較低；對於SCRUM中時間盒的使用，無論從計划上還是從適應性的調整上，都需要團隊有較高的能力；Kanban雖然沒有明確的時間盒限制，但是Kanban的持續改進對團隊的自驅力要求更高。個人認為，條條大路通羅馬。不管是SCRUM還是Kanban，都能應對團隊的精益敏捷轉型。從教練角度，Kanban因為其靈活性實施推廣會較複雜一些。

團隊的精益敏捷轉型是個複雜的工作，SCRUM或者Kanban只是提供了框架，具體採用哪些實踐，還需要根據團隊面臨的問題，來系統化選取實施。作為教練，應該跨越方法論的壁壘，按需選取實踐，持續優化工作流，做到產品研發全周期轉型的覆蓋。