兩大方法
雖然敏捷誕生只有20年的時間,但卻幫助了很多企業取得了成功,在這期間也出現了各種敏捷方法論和思想體系,這篇文章,我們試圖去討論一個問題:對於準備實施敏捷的團隊,在Scrum和Kanban兩種方法之間如何選擇?(特別說明:有人會說Kanban其實是一套思想體系,不是方法論,這裡我們不想陷入概念之爭,只想解釋他們適用的場景,所以下文中都會稱呼他們為方法,而不會刻意加以區分)。
Scrum和Kanban兩者都作為符合精益思想和敏捷的思考結果,他們之間必然會有一些相似點:
兩者都限制開發中工作數目
兩者都是通過透明度來驅動過程改進
兩者都提倡提及時且穩定的交付價值
兩者都基於自組織型團隊
兩者都要求把工作細分
兩者都是基於經驗資料持續優化
再來看看兩者之間的一些區別:
下面結合例項來演示Scrum和Kanban這兩種方法如何在Worktile Agile中體現。
Scrum
在標準的Scrum流程定義中,有兩個關鍵的產物:Product Backlog和Sprint Backlog,以及四個關鍵的會議:計劃會議、每日立會、評審會議和回顧會議。 在Worktile Agile產品中,我們把Product Backlog分為需求和缺陷,其中需求部分使用Epic-Feature-User Story三級體系來表示。
Epic:史詩,表示比較大的特性,開發週期一般是1-3月,用於產品路線圖的規劃
Feature:特性,表示相對小一些的特性,開發週期一般是1-3周,用於產品版本的規劃
User Story:使用者故事,表示最小的使用者場景,開發週期一般是1-3天,用於迭代規劃。
圖1 Worktile Agile中需求管理
在每個迭代開始時會召開計劃會議,全員都會參加,這個會議最重要的事情就是確定Sprint Backlog,由Product Owner按照優先順序介紹Product Backlog,然後團隊決定是否把某一個條目放入當前迭代。
圖2 Worktile Agile中迭代規劃
迭代進行的時間內,每天都會有10-15分鐘的站立會議,團隊中每個成員基於Worktile中的迭代任務板介紹前一個工作日所做的事情,以及遇到的問題。
圖3 Worktile Agile中的迭代任務板
迭代結束時召開評審會議,在評審會議上每個人基於產品演示自己在這個迭代中所完成的成果,團隊成員可以針對完成的事項提一些建議。在評審會議結束後,團隊成員會一起召開迭代回顧會,回顧會是Scrum迭代實踐中的最後一環,也是最重要的一環,迭代回顧會將整個迭代形成了閉環。回顧會上大家提出的問題通過迭代回顧皮膚記錄。
圖4 Worktile Agile中的迭代回顧皮膚
在Scrum實踐中,大部分團隊都會忽視版本管理,迭代是針對Scrum團隊的活動行為,而版本管理是針對產品的,它定義的是一個批量的概念,用於版本進度管理和交付風險管理,明確在一個版本中的最終交付物,Worktile Agile中你可以建立版本並把它與迭代關聯,或者只是單純的設定某個使用者故事/缺陷屬於某個版本
圖5 Worktile Agile中的版本管理
Kanban
對於一個團隊採用Kanban方法來管理是否能夠成功,取決於使用Kanban後能否為你的團隊帶來以下幾點改進:
幫助團隊視覺化整個鏈條的價值流動
幫助團隊識別價值流動中的風險點
幫助團隊度量價值流動中的各種浪費,並加以消除
基於這些考慮,在Worktile Agile中的Kanban專案型別,目前支援以下的能力:
能夠清晰定義在製品WIP
能夠清晰定義在製品限制WIP Limit
明確定義DoD
支援多泳道分割
圖6 Worktile Agile中的Kanban專案
在Worktile Agile中的同一個專案中,支援同時建立多個看板,便於你根據業務場景的不同,或者團隊角色的不同定義多個看板,並且可以針對每個看板的需要進行個性化的配置。
圖7 根據團隊的需要個性化你的看板
因地制宜
講完了Scrum和Kanban的基礎知識,以及在Worktile Agile中對於Scrum和Kanban的支援,我們來看看在實際團隊落地時,如何結合實際情況在二者之間選擇。
- 如果你的團隊是產品導向型的,推薦使用Scrum;如果是研究導向型的,比如效能優化、編碼優化等不確定性非常大的,推薦使用Kanban。
- 團隊規模適中,5-9人左右,並且有跨功能團隊成員,推薦使用Scrum;相反如果你的團隊規模比較小,只有2-5人左右,推薦使用Kanban,相對效率較高。
- 產品或者專案交付是按照一定的週期來計算,比如每2周或每個月要求有一個新的版本,推薦使用Scrum;如果產品或者專案的交付不是按週期來計算,而是按照某個特定的事件為標誌,比如效能提升了10%釋出一個新版,推薦使用Kanban。 當然這些只不過是一點經驗之談,具體還要看團隊的實際情況,因地制宜,來推動敏捷在團隊的真正落地,而不是流於形式。
本作品採用《CC 協議》,轉載必須註明作者和本文連結