測試經理必知必會-Kanban和Scrum區別

2020-09-03 安然—Testfan

前面兩篇文章，老司機給各位測試經理介紹了敏捷開發的兩種模式：Scrum和Kanban。

那麼兩者有什麼區別？且看下文一一拆解：

1、理念

Kanban和Scrum都圍繞著敏捷開發的理念展開。在敏捷開發實踐中，負責人都需要使用迭代方法和用戶故事。基本上，這種策略使用裡程碑和自組織團隊，而不是對每個項目採用全局性的方法。由於這種快速、靈活的方法論，敏捷開發人員具有競爭優勢，能夠在短時間內完成長項目。

當考慮Kanban和Scrum時，考慮目標是很重要的。

Kanban就是限制正在進行的工作的數量和可視化團隊的工作。通過減少完成用戶故事所需的時間，團隊可以最大化工作流。

而使用Scrum，一個軟體項目被劃分為一組稱為sprint的時間間隔。每個間隔都像一個學習循環，幫助團隊學習和吸收反饋。

Scrum和Kanban的區別在於項目是如何執行的，以及項目對於突然變化的靈活性。

2、團隊

Scrum和Kanban的一個明顯區別是團隊本身。

當用戶使用Kanban時，沒有關鍵的角色需求，因為結構非常靈活。相反，Kanban方法論只建議團隊需要有一個項目經理。

Scrum恰恰相反。創建項目工作流時，必須分配關鍵角色。這些角色是針對Dev Team、ScrumMaster和Product Owner的。Dev Team負責完成每日待命中列出的任務。雖然Dev Team必須實現日常和總體目標，但Product Owner是設定這些目標的人。然後，ScrumMaster負責管理時間線。

如果負責人試圖在Kanban團隊和Scrum團隊之間進行選擇，那麼角色需求是一個重要的考慮因素。Kanban是在Scrum不適用於團隊的情況下使用的，您需要一個更靈活的選項。無論你選擇哪一種方案，這兩個方案仍然需要某種團隊合作來實現目標。

3、進度

由於Kanban和Scrum都是管理工作流程的廣泛系統，所以它們的截止日期、優先級和節奏之間的差異是比較這兩個敏捷開發模式的關鍵。Kanban將重點放在優先順序上，因為項目預計會隨著時間的推移而發展和變化。相比之下，Scrum希望用戶在sprint中清楚地描述項目的目標，因此不論誰都不應該在進行過程中更改計劃。

Kanban允許用戶為項目創建項目截止日期、流程、角色和限制。隨著項目需求的變化，這些變量可以很容易地處理和更改。

與Kanban不同，Scrum對時間表有嚴格的關注。團隊應該遵守紀律，並保持在預先設定的時間表和優先事項的重點之內。Scrum Team決定他們想要的點數分配，然後他們堅持下去。

如果團隊使用Scrum，則必須對團隊的能力和目標有很強的理解。每個sprint都需要一個可交付結果，如果想完成可交付結果，那麼必須準確地預測項目的範圍。在Scrum中，也不鼓勵超過最後期限，因為大家應該在sprint期間完成目標。

4、節奏

節奏是Scrum和Kanban的另一個重要區別。

Scrum通常運行得更快，因為sprint的長度大約為2到4周。每個sprint都有一個明確的開始和結束日期。

因為Scrum的時間框架很短，所以它更容易處理複雜的任務。這些任務被分成小組可以快速處理的小故事。每個sprint包括sprint計劃、sprint回顧、每日Scrum會議和回顧會議。

反之，Kanban就會有一個連續的流程。工作項在Kanban上的卡片上。每一張卡片都順利地進入工作流的另一個階段。在Toggl計劃中，您可以快速地將任務從一種狀態拖放到另一種狀態，並添加顏色編碼的標記以可視化每種類型的任務。

使用Kanban時，可以創建自定義列。比如常見的項目管理工具，如：JIRA、禪道等，都可以用不同的列來標識哪些任務正在進行、哪些正在等待批准、哪些已經完成。標籤用於區分不同類型的設計（列印、社交、網絡等）。使用這些板可以幫助團隊發現流程中的瓶頸，這樣團隊可以改進。

5、任務板

在每個系統中，如何設置任務板也會有所不同。同樣，這些功能乍看起來也很相似，但是在列和其他功能的工作方式上有一些關鍵的區別。

當用戶查看Scrum板時，大家都會注意到列。這些列具有顯示sprint backlog的開始和項目結束之前的所有步驟的標籤。sprint中的用戶故事應該在最後一列中結束，否則sprint無法成功實現其目標。

使用Kanban，列被標記以反映工作流中的不同位置。它們還顯示了在任意給定時間點可以放入列中的最大故事數。因為團隊成員可以不斷添加新的故事，所以工作流板可以在項目展開時保持流動，而不是處理諸如sprint length之類的限制。

6、過程中的變革

有了Kanban，團隊可以隨時進行更改。無論何時，團隊都可以將新的工作項添加到項目的backlog中。然後，團隊可以移除現有卡並根據需要調整WIP限制。

當團隊使用Scrum時，不應該在sprint中做任何改變。相反，團隊會得到反饋，為下一次衝刺做準備。在每次迭代結束時，團隊才有機會在sprint回顧中討論將來的更改。

以上是Kanban和Scrum在敏捷開發具體實踐中的六點不同，各位測試經理、負責人，大家可以在實踐中慢慢體會。

上一篇：測試經理必知必會：敏捷開發3355原則

上一篇：測試經理必知必會：敏捷模型之Kanban

作　　者： Testfan Arthur

出　　處：微信公眾號：自動化軟體測試平臺

版權說明：歡迎轉載，但必須註明出處，並在文章頁面明顯位置給出文章連結

相關焦點

  • 測試經理必知必會：Kanban和Scrum怎麼選擇？
    前面三篇文章，老司機給各位科普了一下kanban和Scrum的區別和聯繫。一旦小夥伴們了解了Kanban和Scrum的更多信息，下一步就是確定團隊中使用哪一個了。具體到每個團隊，應該選擇哪個？Kanban或者Scrum可用於小型和大型團隊。每個系統都有其優缺點。
  • 測試經理必知必會：敏捷XP
    不是福報，不是編程累到極限的意思…敏捷XP是對測試小夥伴、QA團隊最有利，最友好的一個方（tao）法（lu），沒有之一！敏捷XP是Kent Beck等大牛在20世紀90年代發明的一種軟體工程方法，是一種強調團隊工作的工作方式。之前文章說的Scrum是一種工作方式的框架，從組織到團隊的設計，而XP關注的是具體的工程技術實踐。
  • 測試經理必知必會：敏捷模型之Kanban
    以我們的開發流程為例：如果測試人員每周只能測試5個功能，而開發人員和分析人員每周有能力生成10個功能，那麼整個管道的吞吐量將僅為每周5個特性，因為測試人員是一個瓶頸。如果分析人員和開發人員沒有意識到測試人員是瓶頸，那麼積壓的工作將開始堆積在測試人員面前。如此一來，不可避免地，質量會受到影響。為了跟上步伐，處於瓶頸部分的人員開始偷工減料。
  • 本周精選：SQL必知必會、高性能MySQL、MySQL必知.
    1、《SQL必知必會》很經典的一本SQL入門書。也是知乎上很多大神推薦的SQL必讀書籍，如果你是一名開發人員或者任何需要快速學習使用SQL的人，那麼這本書很適合你。這本書內容相當系統，分為22課，涵蓋了從基本的SELECT、UPDATE語句到更高級的主題(如存儲過程和事務處理)。
  • 乳化液泵齒輪箱司機必知必會
    乳化液泵齒輪箱司機必知必會   無錫一煤煤礦機械有限公司專業生產乳化液泵齒輪箱，型號齊全，低損耗，使用壽命長，耐腐蝕，歡迎來電諮詢！    乳化液泵齒輪箱過濾器下面的排汙螺塞和上面的反洗閥要先擰開進水只能通過右邊的過濾器進入泵內—採煤機配件製造商採煤機配件太原採煤機附件矩形花鍵軸有什麼特點是太原採煤機的一種配件……以下機械設備將向您解釋－    如有上述現象應將其拆卸並重新組裝
  • 產品負責人必看:如何確定Scrum團隊的最佳規模?
    敏捷提倡小團隊，但也同樣提倡個體和互動高於流程和工具，擁有兩個或以上的團隊必可避免的要創建更多流程以便能夠同步工作。專家怎麼說？亞馬遜創始人貝索斯曾將兩個披薩原則用在會議和團隊中，那就意味著無論是會議還是團隊應該只有兩個披薩可以餵飽午餐的人數。
  • 精解【物流Kanban System 看板系統】第三期
    零售要解決的根本不是前端的問題，零售要解決的真正是供應鏈和貨品質量的問題，無人貨架在未來的某個時間會以另外一種方式回歸。即使現在，也在硬體上不斷迭代降低成本。因為購物越來越「服務化」，無人就符合服務體驗。        蛤蟆集團認為無人貨架這個模式無任何機會可言。
  • 測試經理必知必會：敏捷中的精益是神馬？
    出去人家問你會不會自動化時，也只能心虛的說我會元素定位基礎的。出去人家問你會不會自動化時，也只能心虛的說我會元素定位基礎的。本文主要簡單介紹下自動化結構設計，封裝啟動APP和關閉APP兩個功能代碼，以便其他測試用例直接重複調用，減少代碼的冗餘。
  • JavaScript小白必知必會要點-類型篇
    在JavaScript中，類型分兩組：基本類型和對象。不屬於基本類型的值都是對象。基本類型包括數字、字符串、布爾值、null和undefined；其他的值都是對象。undefined意味著變量（屬性或數組元素）還未初始化。null表示「無對象」。
  • 4大Scrum會議如何才能有意義?
    以Scrum為例，理解Scrum是什麼，和瀑布開發有什麼區別，有一個很好的框架概括——角色Roles儀式/會議Ceremonies產物Artefacts（圖片來源：https://www.visual-paradigm.com/scrum/what-are-scrum-ceremonies/）其中，衝刺會議(Scrum Ceremonies)就是通過４種不同的交流方式
  • Scrum團隊如何選擇Scrum看板工具?
    Scrum 是一個用於開發和維護複雜產品的框架 ，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是2到4周(網際網路產品研發可以使用1周的Sprint)。
  • LVDS — 低壓差分信號必知必會
    由於信道的非理想特性，信號從Tx通過FR4 PCB板傳輸到Rx，這中間會有信號插損、回損、近/遠端串擾，再繼續提高頻率，信號會嚴重失真，這就需要採用均衡和數據時鐘相位檢測等技術，這也就是SerDes所採用的技術。
  • 產品經理必會:項目管理流程
    編輯導語：項目管理流程是產品經理必會的一項技能，一個項目往往包含很多複雜的流程和具體的細節，那麼產品經理應該如何做好項目管理呢？本文作者拆解了項目流程，具體的分析了產品經理在每個階段應該做什麼事，希望能夠幫助到各位對此依舊迷茫的產品經理們。作為一個合格的產品經理最重要的能力之一，就是是項目管理。
  • 「商業分析師內訓」Scrum敏捷定製內訓精彩分享
    此次定製敏捷培訓,從3月初我們就開始和客戶展開培訓調研,在得知團隊90%的人都接觸過敏捷理論知識體系,並希望從實戰角度切入,而培訓時常僅有一天,這對老師的要求是及其高的。打破尋常路，先一個敏捷經典視頻來開場，在視頻播放中，有針對的介紹敏捷的主題內容,突出國內與國外,傳統與敏捷之間的區別,並強調敏捷中的三駕馬車,三種角色的作用與區別。而重頭戲在客戶訪談中的「用戶故事」主題，敏捷教練WANG用冰山模型來分解用戶故事，通過使用４Ｗ１Ｈ構建用戶故事地圖，並分解具體的user story。
  • 阿里P8分享Java開發的未來主流，必知必會的服務微化量絕招
    未來主流、必知必會、服務微化量絕招：RPC、Spring Boot、Spring Cloud、Docker、Kubemetes、Service Mesh、微服務設計的學與思。Spring Cloud第1章 基礎知識什麼是微服務架構與單體系統的區別
  • 框架比較:Scrum vs Kanban vs Lean vs XP
    通常的格式是：作為[用戶角色]，希望[系統做這個和那個]，以便[交付這樣和這樣的商業價值]。它必須有一個「完成的定義」，用來確定故事是否已經正確執行。　　2. Task。它可以與用戶故事相關或不相關。例如，設置新的開發環境或研究CPU內存問題是與用戶故事無關的任務。　　3. Backlog。用戶故事和未來Sprint任務的列表。　　4.
  • Scrum實踐指南:一個可運行的 Scrum是怎樣的
    也曾聽說有些公司要開發一個新功能，因為實施了scrum，於是要求項目團隊加班加點，將2周甚至3周以上的開發任務在一周內就發布上線。故事點評估相對精確的評估工作一般都是在衝刺計劃會上進行，並由負責實際開發及測試工作的團隊對產品待辦事項做出評估。在實踐過程中為了讓衝刺計劃會更高效，在衝刺計劃會之前PO與Scrum Master會作出一個粗略的評估。看看衝刺計劃是否切實可行？要完成這些事項，現有的信息是否足夠？用戶故事拆分是否合理？
  • Android程式設計師必知必會的網絡通信傳輸層協議——UDP和TCP
    對於Android程式設計師來說，如果您覺得本文內容稍顯枯燥，可以看看即時通訊網之前整理過的一篇類似文章《邁向高階：優秀Android程式設計師必知必會的網絡基礎》，該文內容更偏向於知識點的概括。《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什麼？》《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》《腦殘式網絡編程入門(四)：快速理解HTTP/2的伺服器推送(Server Push)》《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什麼？》
  • Wekan 2.55 發布,支持中文的 JavaScript kanban
    Wekan 2.55 發布了，Wekan 是模仿 Trello 且與它最接近的開源 kanban，它的前後端都是使用 JavaScript 編寫，基於 Meteor 框架。
  • 「項目管理英文」敏捷項目管理法之一-Scrum
    採用的是有時間限制的周期-Sprint周期，是scrum的重要組成部分，其設立了所有其他活動的框架。團隊成員，預計會是跨職能，並能儘可能做到彼此互換。產品負責人—代表業務，產品負責人管理產品的待辦事項列表，或者需要完成的工作的列表，設立開發的優先級，並確保團隊和股東之間的透明度。