SCRUM 中常見的反面模式，分享經驗與建議

- Christopher Alexander, A Pattern Language

什麼是反面模式?

當我們覺得為問題提出的解決方案是正確並是最容易實施的，但最後卻成為問題或導致的問題多於解決的問題時，就會出現反模式。反模式隱藏在最佳實踐中，並且似乎是系統的一部分。

SCRUM 中的反面模式

根據我的經驗，在團隊和組織常出現的反面模式有：

使用 SCRUM 等於敏捷

我常常發現有些組織運用 SCRUM 好幾年，他們便因此認為自己所處於敏捷組織（在此處查看更多關於我們敏捷項目管理和敏捷教練方法的信息）。然而，經過仔細觀察便會發現，他們其實仍然在堅持傳統的管理方法。

為了實現真正的變革，強化敏捷思維便顯得尤為重要。回到我們最初的主題，敏捷軟體開發宣言。牢記它的四個價值觀和十二條原則。

它有助於將敏捷可視化、規範化，並成為我們遵守其實踐和框架的指引。如果我們只花大量時間精力關注各種各樣的實際操作，而不明白其原因和價值所在，最終就會發現自己處於“假敏捷”境地。

產品負責人將工作分配給開發人員

在規劃階段，產品負責人告訴開發人員該如何工作是很常見的，但這是違背了 SCRUM 框架中的角色分配，破壞團隊的自組織和承諾原則。針對該現象，我建議邀請經驗豐富的 Scrum Master 協助產品負責人，提高對角色分工的理解，這將有助於最大化開發人員的能力和表現。

評審會議變成了產品負責人對“開發團隊”工作的審核

SCRUM 中包括三個角色：Scrum Master、產品負責人和開發人員。這些角色都是獨立團隊的一部分，沒有誰附屬於誰之說。但我也發現有些 SCRUM 團隊中缺乏產品負責人。一些產品負責人只參加規劃和評審會議，但衝刺期間（sprint）卻不在場，或者有時只參加日常會議作為跟進。

在這種情況下，我的建議是確保產品負責人接受過專業的職責培訓，並且確保他們有足夠的時間來擔任這個角色， 這點至關重要。

將回顧會議（retrospective）變成一個冗長的會議

當會議的目標和議程不清晰時，它便失去了出席的價值，團隊甚至感覺這些會議在浪費他們的時間。

在這種情況下，Scrum Master 可以幫助團隊深入了解這些會議的目的。這很多時候都依靠經驗。所以有一位資深的Scrum Master 或者敏捷教練 （Agile Coach）的協助將會非常有幫助。

產品負責人擔當“團隊負責人”的角色

產品負責人同時又擔當“團隊負責人”的現像很常見。這不僅意味著額外的工作量，而且還使團隊內部增加了不必要的階級結構。團隊響應其“老闆”的命令，將減少了開發人員的自主權。

為了從根源上避免這個現象，在團隊中加強敏捷思維是必不可少的。通過培訓和輔導來提高產品負責人對角色的認識和理解。

對衝刺（sprint）的誤解

當組織向敏捷的工作方式過度時，他們通常會把衝刺階段的產品規劃理解為新的甘特圖，從而創造一種敵對的、壓抑的、為滿足最後期限而不惜一切代價的環境。 SCRUM 不是用來管理項目的，而是用於在不確定環境中構建產品，而其他工作方式在這個環境下只能創相對造較少的價值。

同樣，我還是建議在團隊中加強敏捷思維。可以循序漸進的開始，比如先由一個項目做試點，然後從這個項目中學習經驗，以適應新的文化。

認為運用 SCRUM 可以提早完成項目/推出產品

許多公司認為通過運用 SCRUM 可以讓我們提早完成工作？但事實是，SCRUM 能幫助我們儘早面對失敗，以便盡快再次評估，棄用不適合的方案，及時改變路線，從而再次創造價值。更重要的是，新的方案將通過我們客戶的評審和測試，這才是創造新價值的意義所在。

SCRUM Master 變成了新的項目經理

SCRUM Master 是一個常常會被誤解的角色。團隊認為他們如神一般的存在，好像不需要做什麼工作，只是說說要讓大家在團隊中感受到快樂和幸福。

實際上，這個角色的設定目的是幫助團隊創造價值。為此他們必須掌握一系列的技術、能力和知識。 SCRUM Master 需要幫助產品負責人找到管理產品需求列表的最佳方式，幫助團隊消除障礙，並在適當的情況下取消不必要的活動。他們必須主持不同的敏捷儀式（Agile rituals），並幫助組織從基層改變思維方式。另外 SCRUM Master 不是對人員、產品、時間表或待處理工作的分配做決定的人。

“時間太緊，把衝刺延長2天”

當處於傳統行政管理制度環境中時，SCRUM 團隊可能會被迫延長衝刺時間。這意味著在交付或審查的環節無法達成統一的節奏。

保持一貫的節奏非常重要，進行審查，並對不能交付的情況做出匯報，引起注意。

“在這個衝刺中，先做前端，再做後端，最後做測試”

當我們沒有明確拆分用戶故事（User Stories），最終構建的可能會是“敏捷瀑布產品 (Agile waterfall products）”。拆分用戶故事的目的之一是能夠構建產品增量（product increments）。做一個沒有完整功能的界面是沒意義的，因為它不能幫助用戶確認流程體驗。而用戶無法交互，也會阻礙技術方面的模塊構建。簡單來說，如果用戶不能給出反饋，你就不能指望任何相應的改進。

改善這一點的最好方法是確保創建完整的小功能，以循序漸進和增量的方式構建和改進。如果沒有用戶反饋作為支柱，我們最有經驗的軟件開發和 UX/UI 設計團隊將無法充分發揮他們的才能。

總結

我希望以上的經驗和建議能夠為正在運用 SCRUM 的團隊提供一些參考。同時我也相信一些讀者對敏捷工作方式有自己的貼士、建議和軼事。

點擊這裡與我們分享您的想法。我和我們的團隊期待與您有更深入探討交流，期待一起在技術、創新和敏捷領域創造出更好的實踐。