敏捷、Scrum 和看板：這些詞到底是什麼意思？

當軟件開發人員聽到有關“新 JavaScript 框架”或“新 IDE”的消息時，他不需要問更多問題來澄清它的含義。 但是如果他聽說了一個“新的敏捷框架”，他可能會像荷馬辛普森式的點頭，假裝他知道它是關於什麼的，但他會有一個，而且只有一個問題： “敏捷框架”到底是做什麼的意思是？

在現代軟件開發環境中，我們越來越多地聽到諸如“敏捷”、“Scrum”和“看板”之類的詞，而且它們經常被不當使用。 在本文中，我將嘗試解釋和澄清其中一些術語。

敏捷

如果你想成為人群中的聰明人，當你談論工作過程時，你應該在每隔一個句子中使用“敏捷”這個詞。 它的範圍很廣，並不要求你對你所談論的主題了解很多，而且它是一個非常好的形容詞或副詞：“思考敏捷”、“敏捷方法”、“根據敏捷原則”。 但“敏捷”的真正含義是什麼？

“敏捷”是指“敏捷軟件開發”，即遵循敏捷原則的開發方法。 但到底什麼是“敏捷原則”？ 看看敏捷宣言和敏捷的 12 條原則，它們為敏捷開發奠定了基礎。 從宣言：

敏捷原則鼓勵功能軟件的持續交付、團隊之間的密切溝通以及對不斷變化的需求的高度適應性。 如果您在工作中遵循這些價值觀和原則，則可以說您是在敏捷環境中工作。 因此，敏捷軟件開發不是一種方法論，它只是一組遵循相同原則的不同方法論、框架和技術。 可以說，“敏捷”是一個思考和決策的框架。

但為什麼在我們的工作中遵循這些原則如此重要？

宣言和原則是尋找數十年來為應對軟件開發挑戰而發展的最佳解決方案的結果。 在整個 70 年代、80 年代和 90 年代，世界各地的不同開發人員和團隊一直在試驗工作方法和解決問題的方法，發明不同的框架和技術（例如 Scrum 和極限編程），甚至達到相同的目標並行的想法。 最後，在 2001 年 2 月，17 位開發人員聚在一起，為所有這些不同的想法和經驗找到了共同點。 這就是宣言的創建方式。

Scrum

如果你在不知道“敏捷”方法的含義的情況下談論“敏捷”方法，那麼你可能會在知道該主題的對話者面前說出一些會讓你發現的話：“Scrum 和其他敏捷方法論”。

Scrum 不是一種方法論，儘管我們都聽說過它比《權力的遊戲》中的殺戮次數還要多。 Scrum 不會對每一個問題都給出答案，也不會為你提供準確的程序來應對你面臨的每一種情況。 並且可能由於這種不正確的解釋，大多數 Scrum 實現也是錯誤的：團隊沒有獲得價值。 這可能導致關於 scrum 的最愚蠢的陳述：“Scrum 不起作用。”

什麼是 Scrum？ Scrum 指南將 Scrum 定義為：

所以它是一個框架，就像任何其他框架一樣，它可以並且經常被錯誤地使用。 有效地使用 scrum 不僅需要採用 scrum 設定的結構，還需要對整個團隊的敏捷原則有深刻的理解和欣賞。

Scrum 由以下角色組成：產品負責人、Scrum Master、開發團隊。

還有四種 Scrum 儀式：Planning Meeting、Daily Scrum、Sprint Review、Sprint Retrospective

以及三個工件：Product Backlog、Sprint Backlog、Product Increment。

Scrum 項目被組織成固定的時間框架，我們稱之為衝刺。 它們通常持續兩週。

產品負責人負責指導項目的方向。 隨著新任務和功能的確定，產品所有者將它們添加到產品待辦列表中。 衝刺從計劃會議開始，開發團隊在會議上從待辦事項中選擇要處理的任務併計劃如何實施。 接下來是開發，在此期間，開發團隊使用積壓工作來跟踪進度並召開每日會議，以便在需要時同步活動並調整計劃。 開發的結果應該是產品增量，可以應用到產品上並立即發布的東西。 在 sprint 結束時，產品增量會在 sprint 評審時提交給產品負責人，如果需要進一步的更改，產品積壓工作會增加。 之後，整個團隊參加 sprint 回顧會，他們討論工作流程以及如何改進它。

Scrum 很容易學習和理解，但很難採用。 這個框架可能適合也可能不適合項目的原因有很多。 它通常需要很多變化，不僅在日常發展方面，而且在文化方面。 Scrum 最適合複雜產品的開發，這些產品可以持續很長時間並且包括不同類型的專家。

為什麼 Scrum 如此受歡迎，為什麼它比傳統的瀑布模型有優勢？ 簡而言之，因為它為產品和客戶提供了更多價值。 使用瀑布等“重量級”方法，恐怖故事比比皆是，幾個月來沒有人看到該項目的任何內容。 使用 scrum，這是不可能的。

Scrum 是關於交付給最終用戶的價值。 如果你真的使用 scrum，你需要在每個 sprint 中交付一些有價值的東西。 價值可以衡量，團隊也被迫檢查障礙並適應，目標是在下一次迭代中交付更多價值。

在大多數軟件開發中，我們並不是在建造摩天大樓；而是在建造摩天大樓。 我們不需要在開始之前就準備好整個計劃，並堅持到最後。 我們在開發軟件，我們有能力適應不同的情況，在開發過程中改變產品需求。 一直以來，很多開發者都將其視為第八大罪，但從產品的角度來看，這對於優化可預測性和控制風險來說是一個巨大的好處。 Scrum 是圍繞這種能力開發的，它的實現提供了一種可靠且有效的方式來處理必要的更改。

許多技術與 scrum 結合使用：規劃撲克、結對編程、測試驅動開發 (TDD)、行為驅動開發 (BDD) 等。 它們實際上並不是 scrum 的一部分，而是兼容的技術。 與 Scrum 同時經常提到的一種方法是看板，關於這兩個東西在相互關係中的含義存在很多混淆。

看板

當您談論 Scrum 和看板時，人群中的一個常見問題是：“Scrum 和看板哪個更好？” 你不知道該回答什麼，因為這就像比較蘋果和橙子，或者問：“煎餅和啤酒哪個更好？” 兩者都更好。

看板是一種簡單的方法，旨在及時交付，同時不會讓團隊成員超負荷。 它與 scrum 類似，目標是最終交付最大價值，但它比 scrum 靈活得多。

看板不是由軟件開發社區發明的。 事實上，它起源於豐田的製造工藝，在其他領域也有廣泛的用途。 沒有您應該遵循的嚴格程序，也沒有您應該實施和使用看板的嚴格方式； 相反，它是一組原則和實踐，您可以從這些實踐中進行選擇以滿足您的需求。 但是在軟件開發中有一種最常用的看板實現，包括使用看板，由代表工作階段和任務的列組成。

列代表開發過程中任務的狀態。 最簡單的示例由三列組成：“To Do”、“In Progress”和“Done”。 因此，任務被添加到“待辦事項”中，在開發開始時移動到“進行中”，並在移動到最後一列時被視為“完成”。 但當然，它可能更複雜：

待辦事項→定義規範→準備開發→開發→代碼審查→測試→部署（→沒有人真正使用它→完全刪除）。

每列都可以有子列； 例如，“開發”可以分為“規劃”和“編碼”； “測試”可以分為“單元測試”和“集成測試”等。 如果合適，專欄可能會專門針對專家。 團隊根據需要定義列和階段。 根據“拉動”理念，任務只應在立即有需求時才進入工作流程。

該板的目的是可視化工作流，這是看板中的第一個關鍵實踐。 事實上，看板可以在沒有板的情況下完成！ 它可以是 Google 工作表中的簡單任務列表，用不同的背景顏色指示任務的狀態，也可以是甘特圖、圖表、表格……甚至可以是辦公室中的一組桶，每個桶代表任務的狀態，以及將球用作任務的位置。 只需可視化工作流程並為整個過程提供透明度。

另一個重要原則是減少您的工作量。 簡而言之，這意味著避免多任務處理。 這可能意味著減少您同時處理的任務量。 如果團隊中有 3 名設計師，則團隊可能會將“設計”列中的最大任務數設置為 3。

與 scrum 一樣，看板也將團隊視為流程中最重要的人物。 但它並不像 scrum 那樣建議角色，您可以保留現有角色以避免對現有流程進行更改。 這同樣代表持續改進：看板通常鼓勵您不斷學習和改進，但不會像 scrum 的 Sprint Retrospective 那樣僅針對該過程規定特定事件。

我應該使用哪個？

Scrum 和看板並不相互排斥，也沒有真正的可比性。 在 scrum 中，有明確的角色，而看闆說，“什麼鬼，保持你當前的角色和職責。” Scrum 會迫使你改變工作方式； 看板讓您從現有流程開始。 在 scrum 中，框架規定了明確的事件時間表； 在看板中，您沒有事件。 然而，它們有很多相似之處：兩者都以價值為中心，團隊成員被尊為系統的“老闆”，本質上，它們有著相同的使命：不斷消除浪費和消除障礙。

但問題是，“我應該在我的特定項目和我的特定團隊中使用什麼？” 更有意義。 看板不需要太多的流程和文化改變，而且在大多數情況下，它比 scrum 更容易採用。 另一方面，Scrum 提供了更多的結構來指導流程，只要每個人都在同一頁面上，就可以消除大量開銷。

但兩者的美妙之處在於，兩者都不是一套嚴格的規則。 沒有什麼能阻止您為自己挑選最好的 Scrum 元素，例如每日會議或回顧。 沒有理由不能將看板合併到 Scrum 中。

當整個團隊都很好地理解 Scrum 時，它已被證明是一個非常有效的框架。 但是，根據我的經驗，我發現很難與一些客戶一起在 scrum 中工作。 正確實施 Scrum 所需的流程和文化變化可能太多（尤其是在與認為自己正在創建新 Google 的人打交道時！）。 另一方面，看板更靈活，不會強迫人們改變。 一些作者還說看板是實現敏捷性的好途徑，並且更容易實現 scrum。 其他人說，使用 scrum 應該最終導致看板。

事實是，每個項目都是不同的，沒有一刀切的解決方案。 作為項目經理，由您決定什麼最適合您的團隊。