Scrum vs Kanban,如何選擇?

揭祕一分快三大小單雙技巧扣38896483發表於2020-04-10

兩大方法

雖然敏捷誕生只有20年的時間,但卻幫助了很多企業取得了成功,在這期間也出現了各種敏捷方法論和思想體系,這篇文章,我們試圖去討論一個問題:對於準備實施敏捷的團隊,在Scrum和Kanban兩種方法之間如何選擇?(特別說明:有人會說Kanban其實是一套思想體系,不是方法論,這裡我們不想陷入概念之爭,只想解釋他們適用的場景,所以下文中都會稱呼他們為方法,而不會刻意加以區分)。

Scrum和Kanban兩者都作為符合精益思想和敏捷的思考結果,他們之間必然會有一些相似點:

  • 兩者都限制開發中工作數目

  • 兩者都是通過透明度來驅動過程改進

  • 兩者都提倡提及時且穩定的交付價值

  • 兩者都基於自組織型團隊

  • 兩者都要求把工作細分

  • 兩者都是基於經驗資料持續優化

再來看看兩者之間的一些區別:

[Terry] 貼上上傳 -2020-04-08 18_14 03.png

下面結合例項來演示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天,用於迭代規劃。

image.png

圖1 Worktile Agile中需求管理

在每個迭代開始時會召開計劃會議,全員都會參加,這個會議最重要的事情就是確定Sprint Backlog,由Product Owner按照優先順序介紹Product Backlog,然後團隊決定是否把某一個條目放入當前迭代。

image.png

圖2 Worktile Agile中迭代規劃

迭代進行的時間內,每天都會有10-15分鐘的站立會議,團隊中每個成員基於Worktile中的迭代任務板介紹前一個工作日所做的事情,以及遇到的問題。

image.png

圖3 Worktile Agile中的迭代任務板

迭代結束時召開評審會議,在評審會議上每個人基於產品演示自己在這個迭代中所完成的成果,團隊成員可以針對完成的事項提一些建議。在評審會議結束後,團隊成員會一起召開迭代回顧會,回顧會是Scrum迭代實踐中的最後一環,也是最重要的一環,迭代回顧會將整個迭代形成了閉環。回顧會上大家提出的問題通過迭代回顧皮膚記錄。

image.png

圖4 Worktile Agile中的迭代回顧皮膚

在Scrum實踐中,大部分團隊都會忽視版本管理,迭代是針對Scrum團隊的活動行為,而版本管理是針對產品的,它定義的是一個批量的概念,用於版本進度管理和交付風險管理,明確在一個版本中的最終交付物,Worktile Agile中你可以建立版本並把它與迭代關聯,或者只是單純的設定某個使用者故事/缺陷屬於某個版本

image.png

圖5 Worktile Agile中的版本管理

Kanban

對於一個團隊採用Kanban方法來管理是否能夠成功,取決於使用Kanban後能否為你的團隊帶來以下幾點改進:

  • 幫助團隊視覺化整個鏈條的價值流動

  • 幫助團隊識別價值流動中的風險點

  • 幫助團隊度量價值流動中的各種浪費,並加以消除

基於這些考慮,在Worktile Agile中的Kanban專案型別,目前支援以下的能力:

  • 能夠清晰定義在製品WIP

  • 能夠清晰定義在製品限制WIP Limit

  • 明確定義DoD

  • 支援多泳道分割

image.png

圖6 Worktile Agile中的Kanban專案

在Worktile Agile中的同一個專案中,支援同時建立多個看板,便於你根據業務場景的不同,或者團隊角色的不同定義多個看板,並且可以針對每個看板的需要進行個性化的配置。

image.png

圖7 根據團隊的需要個性化你的看板

因地制宜

講完了Scrum和Kanban的基礎知識,以及在Worktile Agile中對於Scrum和Kanban的支援,我們來看看在實際團隊落地時,如何結合實際情況在二者之間選擇。

  1. 如果你的團隊是產品導向型的,推薦使用Scrum;如果是研究導向型的,比如效能優化、編碼優化等不確定性非常大的,推薦使用Kanban。
  2. 團隊規模適中,5-9人左右,並且有跨功能團隊成員,推薦使用Scrum;相反如果你的團隊規模比較小,只有2-5人左右,推薦使用Kanban,相對效率較高。
  3. 產品或者專案交付是按照一定的週期來計算,比如每2周或每個月要求有一個新的版本,推薦使用Scrum;如果產品或者專案的交付不是按週期來計算,而是按照某個特定的事件為標誌,比如效能提升了10%釋出一個新版,推薦使用Kanban。 當然這些只不過是一點經驗之談,具體還要看團隊的實際情況,因地制宜,來推動敏捷在團隊的真正落地,而不是流於形式。
本作品採用《CC 協議》,轉載必須註明作者和本文連結

玩快三輸了幾十萬怎麼快速回本,最佳最穩定的回血上岸辦法扣大神交流81488956

相關文章