Scrum 和看板：解釋了兩種強大的敏捷方法

所以你要管理一個複雜的項目？ 有一大堆工作需要完成，但不要驚慌！ 作為項目經理，您將負責計劃、監控、管理預算、執行、驗證質量並按時發布最終項目。 值得慶幸的是，有許多項目管理方法可以使您（以及您的團隊）的工作更輕鬆、更高效！

在本文中，我想集中討論兩種最流行的敏捷方法——Scrum 和看板——它們近年來席捲了軟件開發世界。 如今，您幾乎找不到不採用這兩個框架進行項目管理的軟件公司。 它們都是關於什麼的？ 繼續閱讀並了解您需要了解的有關 Scrum 和看板的所有信息！

項目管理中的敏捷方法究竟是什麼？

如今，公司不再只在開發過程的所有階段都對其進行測試的情況下開展單個項目。 它只是沒有回報！ 為什麼不？

試想一下：你的整個團隊工作了幾個月，比如說，開發一個移動應用程序，你只有在後端和前端開發人員、設計師和文案的全部工作已經完成後，才能在最後測試和評估。 如果只有到那時您才意識到您的產品不再響應市場需求和用戶需求怎麼辦？ 然後，您需要引入整個項目的後續迭代，這會消耗大量時間、金錢和精力。

因此，敏捷方法是一個很好的解決方案，可以顯著改善工作流程並在每個階段輕鬆實施更改。 敏捷背後的關鍵原則是將一個“大”而復雜的項目分解為幾個較小的項目（或功能），然後一個接一個地發布。 在這裡，開發和測試都是兩個並發的活動，這使得持續驗證項目和引入所有必要的改進變得更加容易。

有趣的是，儘管多年來敏捷在 IT 和軟件開發公司中盛行，但這種方法被證明非常有效，以至於現在它被用於許多其他領域，如營銷、銷售、人力資源或運營。 根據 Verison One 編寫的敏捷狀態報告，2020 年 95% 的科技公司和軟件公司正在實踐各種敏捷方法。

Scrum 框架：為什麼這麼棒？

許多人傾向於混淆兩個概念，儘管它們看起來很相似，但並不是同義詞——它們是敏捷和 Scrum。 簡而言之，敏捷是一個概括性術語，表示敏捷宣言中指定的所有方法和方法，而 Scrum 實際上是其中一種方法。 就這麼簡單！

什麼是 Scrum，什麼時候可以使用？

Scrum 是一個項目管理框架，主要用於構建開發過程至少需要幾個月的複雜產品。 它首先依賴於透明度、所有團隊成員之間的持續溝通和集體責任。 該策略有助於交付滿足目標受眾需求並響應當前市場需求的項目最終版本。

儘管 Scrum 已經成為一個領先的框架，尤其是在最近幾年，但它實際上並不是什麼新鮮事。 讓我們回到 1986 年，當時《哈佛商業評論》發表了《新產品開發遊戲》一文。 在那裡，作者描述了本田或佳能等公司採用的一種管理方法，這種方法導致了他們的成功。 然後，在 1993 年，這些概念啟發了 Jeff Sutherland 和 Easel Corporation 團隊建立了一個名為 Scrum 的基於團隊的流程。

Scrum 團隊中的角色和職責

在 Scrum 團隊中，所有角色從一開始就明確定義，並且通常不會在整個項目中改變。 通常，該框架具有 3 個基本角色：產品負責人、Scrum Master 和開發團隊。

Scrum 大師

Scrum Master 是一種（但不完全是）團隊領導者，他確保一切都以正確的方式完成並且開發過程順利進行。 Scrum Master 的主要職責是：

• 指導團隊成員，使每個人都能更有效地工作以提供數字產品的新功能
• 計劃下一個 sprint 的所有任務（下面，我會告訴你更多關於 Scrum 中的 sprint）和維護產品 backlog
• 教育利益相關者和所有團隊成員了解 Scrum 原則對項目管理的重要性
• 評估所有任務是否按計劃執行
• 試圖消除阻礙在給定 sprint 中實現任務的所有障礙。

Scrum Master 始終與產品負責人密切合作非常重要。 他們一起計劃後續衝刺，評估已完成任務的質量，為團隊設定方向並確定項目是否需要引入變更。 簡而言之，Scrum Master 盡最大努力幫助開發團隊取得成功並按時交付所有功能。

產品擁有者

產品負責人負責交付可以產生實際業務利潤的產品的最終版本。 因此，在整個 Scrum 團隊中，設定優先級和起決定性作用的是 Product Owner。 這裡重要的是產品積壓由產品負責人管理，產品負責人決定哪些產品功能應該優先開發，因為它們具有最大的商業價值。

這些是產品負責人的主要職責：

• 管理產品積壓
• 聯繫利益相關者
• 定義每個 sprint 的主要目標
• 計劃發布新功能
• 評估開發團隊的工作並在必要時取消衝刺

開發團隊

如果沒有開發團隊，Scrum 將無法實現，因為他們會完成實際工作並完成為特定 sprint 安排的所有任務。

通常，開發團隊由具有特定領域專業知識的人員組成，例如 iOS、機器學習、後端或前端開發。 他們都聯手提供數字產品的高質量功能。 但是，您應該記住，儘管“開發團隊”一詞通常指的是工程師，但這並不總是準確的。 營銷人員、設計師、分析師、測試人員、文案或銷售專家也可能帶來一些價值並成為 Scrum 團隊的一員。

建立開發團隊時要考慮的一件事是其成員的數量。 即使在這裡，Scrum 也指定了一些基本規則！ 據說這樣的團隊必須由 3 到 9 人組成，並且他們應該具備交付所有功能所需的技能。 當然，這一切都取決於項目的複雜程度和客戶的需求； 有時 4 或 5 個開發人員完全足以構建一個數字產品。

但是，開發團隊在 Scrum 中的角色到底是什麼？ 基本上，它應該：

• 根據產品負責人的說明構建所有產品功能
• 確定在給定的 sprint 中要構建多少項目
• 有效管理工作量，以便在 sprint 結束時完成所有任務
• 共同做出所有相關決定
• 有“我們”的態度——團隊做出所有決定，一起解決問題，每個人都對其他同事負責

簡而言之，Scrum 開發過程

您已經知道 Scrum 是什麼以及誰組成了 Scrum 團隊，所以現在是時候了解這種方法論中的開發過程是什麼樣的以及如何正確地完成它。

在 Scrum 過程中，每一步都很重要，並為您的團隊帶來真正的價值。 以下是您不應該跳過的主要階段：

1. 產品待辦事項：需要在以下衝刺中構建的所有項目的列表。 它由產品負責人和 Scrum Master 一起管理，他們確切地知道每個功能或項目應該何時發布。
2. Sprint 計劃會議：本次會議的主要目的是定義開發團隊的每個成員在下一個 sprint 中將做什麼。 它總是在 sprint 開始之前進行組織，以便每個人都可以評估他們是否可以在截止日期之前完成所有任務。 確保每個團隊成員都完全掌握 sprint 的主要目標。
3. Sprint Backlog ：這些是團隊選擇在給定 Sprint 中執行的產品 Backlog 中的選定任務。
4. Sprint ：這是所有魔法發生的地方。 Sprint 週期很短，通常需要 1-4 週的時間，開發團隊完成春季計劃會議期間分配的所有任務。
5. Daily Scrums （也稱為 Standup）：每天同時舉行的超短會議，期間每個人用 1-2 句話報告他們的工作進度：他們談論已經完成的工作以及還需要完成的工作。
6. Sprint Review ：當 sprint 結束時，每個人都有機會向其他經常參加 Sprint Review 的隊友甚至利益相關者展示他們完成的工作。
7. Sprint 回顧：現在是結束整個 Sprint 週期的最後一次會議的時候了。 如果任何團隊成員對下一個 sprint 可以改進的地方有一些建議或想法，他們可以在 Sprint 回顧會議期間提出。

對於 Scrum 流程，確保每個 Scrum 週期具有相同的結構至關重要：它從 Sprint 計劃會議開始，然後每個人都開始工作並完成為 sprint 設定的任務，最後每個團隊成員都展示他們所取得的成就。

我還想讓你記住一件事：Scrum 有一個非常嚴格的變革理念。 這在實踐中意味著什麼？ Scrum 團隊成員不應在 sprint 期間更改任務或主要目標。 如果他們未能交付計劃的結果，那麼應該為未來更好地估計完成項目所需的時間提供一個教訓。

關於看板的幾句話

現在您已經了解了 Scrum 是什麼以及如何使用它構建數字產品，是時候更加關注第二種敏捷方法論了。 我相信你已經熟悉它了——即使你還沒有意識到！

什麼是看板，什麼時候可以應用？

看板一詞來自日語，可以簡單地翻譯為“視覺信號”。 這基本上就是這種方法的全部內容。 在看板中，每個元素都有其可視化表示——團隊成員放在白板上並更改其狀態（例如“待辦”、“正在做”或“完成”）的卡片。

這種方法可以很容易地應用於任何行業，但最常被參與復雜且耗時的項目的軟件開發團隊選擇。 並且有充分的理由 – 看板促進了實時通信並使所有隊友的工作完全透明。

有趣的是，看板實際上是一種比 Scrum 更古老的方法。 它的起源可以追溯到 1940 年代，當時豐田在其工廠的白板上引入了一種單獨的卡片系統，工人可以隨時切換。 結果，這種策略使他們的工作更加順暢，並加快了團隊之間的溝通。

誰是看板團隊中的誰？

在討論 Scrum 時，我描述了每個團隊成員（Scrum Master、產品負責人和開發人員）的確切角色、職責和能力。 在這裡，情況大不相同。 看板並沒有定義誰擁有更多的權力或責任，因為實際上所有的團隊成員都是平等的，他們共同加入了力量和技能組合。

此外，看板並沒有具體說明一個項目可以有多少人一起工作，所以任何團隊結構都是可以接受的。 但是，如果您想改進工作流程，您可能需要考慮建立一個交叉開發團隊。 借助此解決方案，具有不同專業領域的團隊成員可以在產品開發的每個階段分享他們的知識並提供反饋。 這樣一來，就完全不需要諮詢其他團隊了！

什麼是看板以及如何創建它？

看板是這種方法的核心和靈魂。 它是一個項目管理工具，旨在實時可視化每個任務的進度。 如果您想知道您的隊友是否已經開始著手開發一項重要功能，或者他們是否已經完成了它，只需查看圖板，現在您就知道了！

這個例子準確地展示了看板是什麼以及它是如何工作的：

所以看板背後的一般概念非常簡單：你有幾個標記的列，並在每個列上放置視覺卡。 這些可以是便籤或門票。 在每張卡片上，您寫下您當前參與的項目的名稱或您正在構建的特定工作項。 然後，您需要做的就是將特定卡片分配到特定列，以便團隊的其他成員得到更新並確切知道您現在正在做什麼。

您可以在上面看到的示例顯示了典型的列類別，它們是：

• '去做'
• '進行中'
• “測試”
• '完畢'

但是請注意，您可以更廣泛地描述您的工作流程並添加其他列——他們的選擇將取決於您管理的項目。

如果您希望您的團隊取得成功，您還需要注意一件事——您應該為您的團隊可以同時處理的項目定義限制。 這就是看板另外建議設置工作進行中 (WIT) 限制的原因。 如何付諸實踐？ 您需要指定一列中可以同時保留多少張卡片（例如“進行中”）。 如果您的團隊達到此限制，他們根本無法添加更多卡片。 設置這些界限始終是處理工作超負荷的一個很好的解決方案。

Scrum 與看板：哪個框架贏得了這場戰鬥？

嗯，這個問題的答案其實沒那麼簡單。 這兩種敏捷策略有一些相似的原則，但它們採用的實踐是完全不同的兩件事。 雖然看板更加流暢，有利於持續變化和定期反饋，但 Scrum 更加嚴格和有組織。

準備好下一個軟件項目了嗎？

我們一起工作吧

以下是這兩個項目管理框架之間的主要區別：

那麼，您將選擇哪些敏捷框架來管理您的項目？ 還是您希望專家為您做這件事？ 請隨時與我們聯繫——通過引入各種敏捷方法，我們已經交付了 150 多種即用型成功產品！