項目管理藍圖第 1 部分：敏捷、Scrum、看板和精益的綜合比較

概述

今天在軟件開發中使用了許多方法。 您可能聽說過諸如瀑布、敏捷、Scrum、看板、精益、極限編程等流行語。

在本文中，我將定義這些術語，討論它們之間的關係以及它們之間的區別。 前面提到的許多流行語都是基於精益製造的概念，精益製造最初是基於豐田製造系統（TPS），所以我們將首先討論這個。

精益方法論

精益和精益製造的起源

“精益”一詞起源於製造業，它是用來描述基於豐田生產系統 (TPS) 的製造模型，該模型最初由豐田佐吉、豐田喜一郎和大野耐一開發，他們最初是受到亨利福特的啟發。 TPS 專注於“徹底消除所有浪費”的理念，並在 1950 年代至 1970 年代徹底改變了製造業。 1990 年，當“改變世界的機器”出版時，TPS 被稱為“精益製造”。

TPS 確定了豐田的三大類廢物：

• Muda：翻譯為“廢物”。 豐田確定了七種類型的木達，後來又增加了八種。 這些是：
  • 缺陷：發現和修復缺陷所涉及的努力
  • 生產過剩：生產超過需求
  • 等待：等待下一個生產步驟、中斷等。
  • 未使用的人才：能力未充分利用、培訓不足等
  • 運輸：加工過程中不需要的移動部件或產品
  • 庫存：已完成的庫存和在製品
  • 運動：移動或行走超出處理所需的範圍

  • 過度加工：來自不良工具或產品設計

• Muri：翻譯為“覆蓋層”。 Muri 通常由 mura 產生，但也可以由 muda 產生。 Muri 表現為故障、曠工、安全問題等。
• Mura：翻譯為“不均勻”。 Mura 可以在客戶需求的波動、每個產品的處理時間或不同操作員的周期時間的變化中找到。 當 mura 不減少時，會增加 muri 的可能性，因此會增加 muda。 可以通過在供應鏈中創建開放性、更改產品設計以及為所有操作員創建標準工作來減少 Mura。

TPS 通過應用以下兩個核心概念來消除浪費：

• Jidoka：鬆散地翻譯為“帶有人情味的自動化”，規定“質量必須在製造過程中建立！” 這意味著當出現問題時，設備會立即停止，從而防止產生不良產品。
• 準時制：只生產“需要的東西、需要的時間和需要的數量”。

隨著 TPS 的發展，這些核心支柱和價值觀建立在 Jidoka 和 JIT 的概念之上並變得根深蒂固：

• 連續的提高：
  • 挑戰：形成長遠的願景，以勇氣和創造力迎接挑戰，實現夢想
  • Kaizen：持續改進業務運營，始終推動創新和進化，一次消除一個muda
  • 源地現佛：實踐現地現佛，追根溯源，尋找事實做出正確決策，凝聚共識，以最快速度實現目標
• 尊重人：
  • 尊重：尊重他人，努力理解對方，承擔責任，盡最大努力建立互信
  • 團隊合作：激發個人和職業成長，分享發展機會，最大化個人和團隊績效
• Andon：狀態或故障的視覺指示器
• Heijunka：表示調平或生產調平
• Hansei：意味著自我反省。 為了提高效率，工人應該挑戰當前流程背後的假設，以找到更好的假設。
• 看板：用作控制生產的視覺工具的招牌
• Poka-yoke：也稱為防錯或防錯
• 拉動系統：材料在需要時被拉入工作站
• Seiri：是反映浪費的原則。 Seiri 指示應該刪除不必要的內容。 這包括所有最初的七種 TPS 浪費
• 標準化：圍繞人體運動組織所有工作，並創建一個沒有muda的高效生產序列。 這有助於提高質量、保持穩定的步伐，並允許持續改進。

下圖顯示了核心概念和核心價值觀如何相互關聯。

精益管理

豐田產品系統和精益製造隨著時間的推移而發展，並應用於包括管理在內的許多領域。

精益管理應用持續改進和尊重人的核心價值觀，並將其提煉成一套五項規範的精益原則，這些原則將被重複多次以持續改進和消除浪費：

1. 識別價值：從最終客戶的角度按產品系列指定一個價值。
2. 映射價值流：確定每個產品系列的價值流中的所有步驟，盡可能消除那些不創造價值的步驟。
3. 創造流程：讓創造價值的步驟緊密地發生，這樣產品才能順利地流向客戶。
4. 建立拉動：隨著流程的引入，讓客戶從下一個上游活動中拉取價值。
5. 尋求完美：當價值被指定時，價值流被識別，浪費的步驟被移除，流動和拉動被引入，重新開始這個過程並繼續它，直到達到完美的狀態，在這種狀態下創造完美的價值，沒有浪費。

這些原則和精益管理的其他方面在 Womack & Jones 於 1996 年出版了“精益思維”時被正式確定。

精益軟件開發

此後，精益已應用於管理、軟件開發和其他領域。

在 1980 年代和 1990 年代，軟件開發行業正面臨危機，因為使用傳統瀑布方法執行的項目花費的時間越來越長。 這通常導致在確定業務需求和交付軟件解決方案之間存在巨大的滯後。 有時，在某些具有特定要求的行業（例如航空航天業）中，這種滯後以數年甚至數十年的時間來衡量。

在這些多年的時間框架內，需求、系統甚至整個業務都發生了變化。 通常，項目會在中途被取消，或者他們將完成其範圍，只是發現他們交付的內容不再滿足項目開始時確定的業務需求。

瀑布方法獎勵利益相關者在被迫編寫合同時考慮所有事情，即使他們可能不確定自己需要什麼。 瀑布方法迫使在需求或設計階段做出決定，而這些決定很難在不改變合同和增加項目成本的情況下改變。 很大比例的軟件項目完全失敗，或者交付延遲和超出預算，或者未能交付所需的東西。

這種普遍的挫敗感導致各種思想領袖試圖改進瀑布。 早期的例子包括快速應用程序開發 (RAD)，它專注於通過快速開發原型並與業務合作進一步開發需求來縮短需求和設計階段，從而減少浪費。 還朝著迭代開發的方向發展，其中完成了一個小項目並在持續迭代中添加了功能。 雖然這些方法有所幫助，但它們並沒有解決與瀑布相關的核心問題。

在 1990 年代和 2000 年代初期，幾位作者出版了關於將精益原則應用於軟件開發的書籍。 Robert Charette 博士於 1993 年發表了《精益軟件開發》，並於 2003 年發表了《精益軟件開發的 12 條原則》。

Tom 和 Mary Poppendieck 於 2003 年出版了“精益軟件開發：敏捷工具包”。這本書詳細介紹了精益開發的七項原則，這些原則與精益製造中的七種浪費形式直接相關。 下圖列出了兩種不同的精益出版物和敏捷（在下一節中討論）之間的異同。

精益與敏捷的區別

根據 Charette 博士的說法，精益和敏捷之間的主要區別之一是敏捷是自下而上的，而精益是自上而下的。

敏捷框架

敏捷的起源和敏捷宣言

大約在 Charette 和 Poppendiecks 出版他們的書的同時，創建了敏捷框架來幫助解決同樣的問題。 2001 年 2 月，一群敏捷先驅在猶他州雪鳥市臭名昭著的雪鳥會議上相遇，試圖提出解決方案。

結果就是敏捷宣言，它為一種方法論制定了一套價值觀和原則，該方法論試圖適應不斷變化的需求和客戶需求，減少浪費，並使用增量迭代方法更快地交付收益。

敏捷宣言的內容如下：

“我們正在通過開發軟件並幫助他人開發更好的方法。 通過這項工作，我們開始重視：

• 個人和交互超過流程和工具
• 工作軟件優於綜合文檔
• 合同談判中的客戶協作
• 響應變化而不是遵循計劃

也就是說，雖然右邊的物品有價值，但我們更看重左邊的物品。”

與宣言中的價值觀一致的是敏捷宣言背後的 12 條原則：

“我們遵循以下原則：

1. 我們的首要任務是通過早期和持續交付有價值的軟件來滿足客戶。
2. 歡迎不斷變化的需求，即使是在開發的後期。 敏捷流程利用變化來獲得客戶的競爭優勢。
3. 頻繁地交付工作軟件，從幾周到幾個月不等，優先考慮更短的時間範圍。
4. 業務人員和開發人員必須在整個項目中每天一起工作。
5. 圍繞有動力的個人建立項目。 為他們提供所需的環境和支持，並相信他們能夠完成工作。
6. 向開發團隊和在開發團隊內部傳達信息的最有效和最有效的方法是面對面交談。
7. 工作軟件是進度的主要衡量標準。 敏捷流程促進可持續發展。
8. 贊助商、開發人員和用戶應該能夠無限期地保持恆定的步伐。
9. 對卓越技術和良好設計的持續關注提高了敏捷性。
10. 簡單——最大化未完成工作量的藝術——是必不可少的。
11. 最好的架構、需求和設計來自自組織團隊。
12. 團隊會定期反思如何提高效率，然後相應地調整和調整其行為。”

上述價值觀和原則是 Jidoka、JIT、Genchi Genbutsu、Kaizen、Hansei、Heijunka 和減少浪費等精益原則的應用。

應用於軟件開發的敏捷原則

敏捷是一個傘式框架，適用於任何應用敏捷價值觀和原則的過程。

一些例子是：

• 極限編程
• Scrum
• 看板

Scrum

人渣簡史

Scrum 是一個應用由多個人分別發明的敏捷原則的框架，其中一些人簽署了敏捷宣言：

• Hirotaka Takeuchi 和 Ikujiro Nonaka 在他們的白皮書“新產品開發遊戲”中最初在製造環境中引入了“scrum”一詞。 1986 年發表在《哈佛商業評論》上。
• Jeff Sutherland、John Scumniotales 和 Jeff McKenna 於 1993 年在 Easel Corporation 實施了 Scrum。
• Ken Schwaber 在他的公司使用了後來成為 Scrum 的東西，即 1990 年代的高級開發方法。

Schwaber 和 Sutherland 在整個 1990 年代合作開發和改進軟件開發環境中的框架，並在各種會議上發表演講。 Schwaber 與 Mike Beedle 在 2001 年的《Agile Software Development with Scrum》一書中描述了這種方法。

Schwaber 繼續創建了兩個主要的 Scrum 認證機構：

• Scrum 聯盟：創建於 2001 年。設立Certified Scrum認證系列。
• Scrum.org：在 Schwaber 離開 Scrum 聯盟後於 2009 年創建。 設置平行的Professional Scrum認證系列。

隨著時間的推移，創建了幾個框架/認證機構，以解決將 Scrum 框架擴展到更大的團隊和項目的問題，因為 Scrum 最初是為小型團隊（7 正或負 2 名成員）設計的：

• SAFe：規模化敏捷框架
• LeSS：大規模 Scrum
• Scrum@scale：由 Jeff Sutherland 創建的大規模 Scrum

Scrum 價值觀

根據 Scrum 聯盟：

Scrum 是一套簡單但非常強大的原則和實踐，可幫助團隊在較短的周期內交付產品，實現快速反饋、持續改進和快速適應變化。

Scrum 是一個規範的、增量的和迭代的框架，用於開發應用敏捷原則的軟件。 Scrum 價值觀和原則在下面的圖表中進行了概述，並且與精益和敏捷的價值觀和原則有很大的一致性。

Scrum 概述

工作被劃分為稱為衝刺的短期迭代，通常為 1-3 週。 這與瀑布的深度規劃形成鮮明對比。 為當前 sprint 計劃的工作是從稱為 Product Backlog（Pull System，Heijunka）的工作項優先級積壓的頂部選擇的，並且在 sprint 開始後就固定下來。 目標是在每個 sprint 結束時擁有工作軟件，從而實現快速反饋。

在 sprint 結束時，團隊開會審查已完成的工作、sprint 的進展情況，併計劃下一個 sprint。 衝刺長度以及沖刺儀式和節奏對於每個衝刺都是固定的。

衝刺由包含完成衝刺工作所需的所有技能的跨職能團隊執行。 日常計劃和進度跟踪是使用 Scrum 板和 sprint 燃盡圖等視覺工件完成的。

衝刺中的工作是從優先級積壓中提取的。 遵循這些方法允許隨著時間的推移不斷變化的需求，並鼓勵來自最終用戶的不斷反饋。

下面的思維導圖概述了 Scum 的一些主要概念，這些概念將在接下來的部分中討論。

Scrum 角色

Scrum 具有三個角色：

• Scrum Master ：Scrum Master 是 Scrum 團隊的僕人領袖。 他們是團隊的教練，幫助促進協作、消除障礙、實施和保護 Scrum 流程並保護團隊。 這通常意味著他們組織和促進 sprint 儀式，確保產品負責人有適當的優先級和整理的積壓工作，確保團隊不會被迫過度致力於 sprint，確保範圍不會被添加到sprint，確保遵守完成的定義。 他們不向團隊成員分配任務（Genchi Genbutsu），也不負責項目的交付
• 產品負責人：產品負責人是負責交付產品的“唯一可擰脖子”。 產品負責人定義他們想要構建的願景，並將該願景傳達給團隊和組織。 產品負責人擁有業務和市場需求，並通過創建和管理產品待辦事項來確定所有需要完成的工作的優先級。 他們決定何時發布哪些功能。 他們與團隊和其他利益相關者合作，以確保每個人都了解產品待辦事項中的項目。 他們在 sprint 演示中接受或拒絕在 sprint 中完成的工作。
• 團隊成員：Scrum 團隊是一個自組織的跨職能團隊，通常由五到七名成員組成。 項目中的每個人都一起工作並互相幫助，而不必局限於不同的角色，如架構師、程序員、設計師或測試員。 每個人一起完成這組工作。 Scrum 團隊計劃他們可以完成每個 sprint 的工作量並擁有該計劃（Genchi Genbutsu）。

Scrum 流程、活動和儀式

如上所述，Scrum 有一個明確的流程和一組儀式和活動。 衝刺的流程如下。

衝刺計劃：

在 sprint 開始之前，Scrum Master 與 Scrum 團隊和產品負責人召開會議，稱為 sprint 計劃會議，產品負責人確定即將到來的 sprint 的目標，然後團隊根據目標計劃他們的工作。

這通常通過以下活動完成：

• Sprint容量：團隊確定sprint的容量，考慮天數、團隊成員數、節假日等。
• 衝刺目標：產品負責人確定衝刺的目標。 根據目標對產品待辦事項進行優先排序（即相關故事位於頂部）並進行梳理，這一點至關重要。
• 工作選擇：故事或任務從積壓的頂部拉到衝刺中，直到達到估計的容量。 隨著故事的引入，產品負責人將解釋故事並回答團隊提出的問題，根據需要更新故事，直到產品負責人和 Scrum 團隊對故事有良好、共同的理解。 一旦這個活動完成，團隊就有了一個提議的初始衝刺範圍。
• 任務分解： Scrum 團隊詳細討論每個故事，重點是規劃他們將如何完成故事並解決所有驗收標準和國防部。 他們將生成完成故事所需的子任務列表。 完成子任務列表後，如有必要，將對故事的估計進行審查和更新。
• Sprint 承諾：一旦所有的故事都被分解並更新了估計，就會審查提議的初始 sprint 範圍。 故事可能會從 sprint 中刪除並放回待辦事項列表中和/或可能會添加其他故事。 一旦完成，只有 Scrum 團隊（而不是 Scrum Master 或產品負責人）承諾完成衝刺中的工作，然後衝刺開始。

為 sprint 承諾的工作總量或範圍以故事點來衡量。

衝刺執行

在 sprint 期間，團隊成員從 sprint 待辦事項列表的頂部提取工作項（用戶故事、任務等）以進行工作。 不同的團隊成員將處理不同的工作項或其子任務。 他們將在適當的時候通過將項目從 Scrum 板上的一列移動到下一列（通常是待辦事項 > 進行中 > 測試 > 已完成或其一些變體）來更新項目的狀態，直到完成。

使用燃盡圖跟踪進度，該圖表顯示已完成的工作量和以故事點衡量的剩餘工作量。 剩餘故事點顯示在 Y 軸上，剩餘時間顯示在 X 軸上。 故事完成後，燃盡圖會更新。

Scrum Master 每天都專注於：

• 促進每日站立會議以計劃一天並審查進度（見下文）
• 確保團隊有當天的計劃
• 消除障礙
• 保護衝刺範圍和團隊免受干擾
• 幫助團隊維護他們的燃盡圖和其他 Scrum 統計數據

每日站立

在 sprint 的每一天開始時，Scrum Master 會與 Scrum 團隊和產品負責人進行一次 15 分鐘的簡短會議，以計劃一天並審查 sprint 進度。 這是一個簡短的會議，每個人都站在 Scrum Board 前，會議中的每個人在 2 分鐘或更短的時間內回答以下問題，參考 sprint board 上的特定項目：

• 你昨天做了什麼？
• 你今天打算做什麼？
• 有沒有阻礙你完成工作的障礙？

這使每個人都可以看到每個人都在做什麼，看到正在取得或沒有取得什麼進展，並確定障礙和/或需要的幫助。

衝刺完成

在計劃下一個 sprint 之前，Scrum Master 會促成兩個儀式以結束 sprint。

衝刺演示

在 sprint 結束時，Scrum Master 組織了一個 sprint 演示會議，每個完成的故事都在工作軟件上向產品所有者和團隊的其他成員展示。 如果滿足所有接受標準，產品所有者將接受該故事，或者他們將拒絕該故事。 如果一個故事被拒絕，則會發現不足之處，並將故事按優先順序放回產品待辦事項列表中，以便稍後完成或根本不完成。 通常，產品負責人不接受的故事部分會被分解成一個或多個單獨的故事，並且原始故事被關閉。

計算每個衝刺完成的故事點總數（速度）並結束衝刺。 速度用於跟踪團隊的輸出水平，並用於估計功能或發布何時完成。

衝刺回顧

在 sprint 演示之後但在下一次 sprint 計劃會議之前，Scrum Master 促進了一次 sprint 回顧，團隊在此回顧剛剛完成的 sprint，並討論什麼進展順利，什麼進展不順利，以便他們可以持續和漸進地改進流程和質量隨時間變化（Kaizen、Hansei）。 有大量的回顧形式或練習可用於幫助團隊進行討論。

生成改進行動項目列表，有時它們會導致項目被添加到產品待辦事項中，對 DoD 或團隊章程的更改等。

產品積壓管理

產品待辦事項創建

在計劃或執行沖刺之前，產品負責人需要創建產品積壓工作。 積壓工作通常從產品所有者編寫的稱為故事的功能開發項目開始，隨著時間的推移，還會填充開發或 QA 任務、峰值和缺陷等，可能由團隊的任何成員創建。 積壓中的所有項目都按優先順序排列。

積壓梳理

一旦創建了初始產品待辦事項並確定了優先級，正在進行的待辦事項整理流程就會接管。 目標是始終至少對待辦事項中的最重要項目進行梳理和估計，以便在衝刺計劃會議期間準備好將它們拉入衝刺。 這通常是通過與產品經理和由 Scrum Master 協助的團隊定期舉行的積壓梳理會議來完成的。

在會議開始之前，會向團隊發送一份故事列表，以便他們審查和準備培訓會議。 在梳理會議上，從驗收標準、複雜性、風險、規模、實施策略等方面討論每個項目。對驗收標準和故事的其他細節進行審查和修改，直到團隊、產品負責人和 Scrum Master對故事有共同的理解。 在這一點上，故事是使用稱為計劃撲克的技術以故事點估計的。

故事點估計

故事點是一個使用相對大小的工作單位，將故事與以前的、已知的、易於理解的作品進行比較。 你總是在問“這個故事是更大、更小還是與其他作品大致相同”的問題。

斐波那契量表（1、2、3、5、8、13、21……）是最常用的量表，其中每個增量大約是前一個增量的兩倍（即，一個五點故事或多或少是前一個增量的兩倍）大如三點故事）。 有時會使用其他尺寸，如 T 卹尺寸（XS、S、M、L、XL）甚至魚（小魚、金魚、鱒魚、金槍魚、鯨魚等）。 任何允許您比較某物相對於另一物大小的比例都可以。

故事點代表團隊實施故事的全部努力，包括開發、測試、設計和完成定義所需的其他雜項任務。 該估算考慮了工作量、複雜性和風險。 一旦確定了故事的相對大小，就會分配比例尺上的大小作為估計值。

團隊準備故事點估計過程，首先通過選擇一個整個團隊都理解為參考故事的“最中等”大小的故事來建立估計基線。 還選擇了一些更大或更小的附加參考故事。

故事點估計是在梳理會議期間完成的，有時在使用 Planning Poker 進行 sprint 計劃期間完成：

1. 每個團隊成員/評估員都有一組卡片。
2. 如上所述，一次討論一個積壓項目。
3. 一旦項目被充分討論，每個估計者私下選擇一張卡片來代表他們的估計。
4. 當所有的估價師都做出估價後，他們同時亮出他們的牌。
   • 如果所有估計都匹配，估計者選擇另一個積壓項目並重複相同的過程。
   • 當估計不同時，估計者討論該問題以達成共識。

故事點估計的優點是：

• 快速：估計是相對於已經完成的產品積壓項目。
• 足夠準確：足夠準確，可以概述範圍、計劃未來工作、確定優先級並管理期望。
• 擁抱不確定性：故事點指定了一個未知的時間範圍。 從特定的斐波那契式故事點序列中進行選擇可以捕捉不確定性。
• 團隊運動：涉及每個人（開發人員、設計師、QA、產品經理）。 使用多個視角來確定工作的規模，但只有從事工作的團隊成員才能估計
• 衡量團隊速度：衡量團隊在衝刺中所做的工作量與花費在工作上的時間量。 隨著團隊的改進，他們將更快地完成相同大小的故事，從而隨著時間的推移提高故事點速度。

發布估計和跟踪

故事點估計也使用以下技術在發布計劃上下文中使用：

1. 列出所有要調整大小的故事
2. 將它們按從小到大的順序排列
   • 以第一個和第二個用戶故事為例。
   • 決定哪個更大，把更大的放在下面
   • 然後拿下一個並決定它相對於其他兩個適合的位置
   • 重複該過程，直到所有故事現在都在列表中（按從小到大的順序）
3. 調整故事的大小

一個版本中所有故事的故事估計與團隊的速度相結合，將允許您估計發布何時完成並跟踪其進度。 這通常顯示在發布燃盡圖中。

Scrum 工件和術語

• 產品待辦事項：給定產品的所有工作項的待辦事項列表，其中可以包括功能（故事）、技術任務、峰值和缺陷
• 發布燃盡圖：用於顯示發布級別的進度並使用 Sprint Velocity 預測發布何時完成的圖形圖表。 完成的故事點顯示在 Y 軸上，衝刺顯示在 X 軸上。
• Sprint Backlog：在給定的 sprint 中要完成的所有工作項的 backlog 列表。 sprint backlog 的內容在 sprint 計劃會議上達成一致。
• Scrum Board：一個表格樣式的板，用於跟踪為 sprint 承諾的工作進度。 狀態顯示在頂部的垂直列中，工作項在每個狀態之間移動，直到完成。 Scrum 板在 sprint 計劃會議期間填充，並在 sprint 結束時重置。
• Sprint Burndown：一個圖形圖表，顯示在 sprint 長度內以故事點衡量的已完成工作量和剩餘工作量。 剩餘故事點顯示在 Y 軸上，剩餘時間顯示在 X 軸上。
• 衝刺速度： Scrum 團隊在衝刺中完成的故事點數。
• 障礙積壓： Scrum Master 需要解決的障礙列表，以便團隊可以繼續工作。 當團隊成員被阻止時，他們會將一個項目添加到障礙積壓中，以向團隊和 Scrum Master 提供可見性。
• 史詩：史詩是由多個相關用戶故事組成的大量工作。
• 用戶故事：用戶故事是從最終用戶的角度對軟件功能的描述。 用戶故事描述了用戶的類型、他們想要什麼以及為什麼。 用戶故事有助於創建對需求的簡化描述，並包括驗收標準。 用戶故事由產品所有者創建和維護。
• 任務：任務是由 Scrum Master 或團隊成員輸入的一項工作，可能與用戶故事直接或間接相關。 它們通常是技術性的，將包括驗收標準。
• 尖峰：尖峰是一種特殊類型的任務，當您需要研究、原型和/或架構師時，您可以決定如何實施或估計用戶故事。
• 子任務：子任務是作為完成用戶故事或任務的實施步驟輸入的任務。 它們通常由團隊在 sprint 計劃會議期間輸入。
• 故事點估計：基於斐波那契尺度（1、2、3、5、8、13、21……）的相對規模估計尺度
• 驗收標準：包含在每個故事中的特定故事、可測試項目的列表，在產品所有者接受故事完成之前必須完成這些項目。
• 完成的定義 (DoD)：在任何故事被認為完成之前必須完成的常見步驟或標準的列表。 團隊同意這一點並將其記錄下來，這樣就不必在每個故事中都列出它。

Scrum 的優缺點

Scrum 的主要優勢是應用敏捷價值觀和原則以及精益概念，例如 Seiri、Jidoka、Just-in-Time、Kaizen、Genchi Genbutsu、Heijunka、Pull System 和 Iterations。 應用這些原則可以讓項目團隊獲得持續的反饋，快速適應不斷變化的需求和不確定性，減少浪費，提高可見性和透明度，並爭取持續改進。 通過始終關注產品待辦事項中最重要的項目，並且只在始終產生工作軟件的短迭代中工作，Scrum 更加以客戶為中心，並允許客戶查看他們喜歡（和不喜歡）的內容並根據需要進行更改。 The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

看板

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.