鬆散的 Scrum

最近我聽說許多專案都一團糟。情況如下

• 他們想要使用敏捷流程，並選擇 Scrum
• 他們採用 Scrum 實務，甚至可能是原則
• 過了一段時間，進度緩慢，因為程式碼庫一團糟

發生了什麼事？就是他們沒有對軟體的內部品質給予足夠的重視。如果你犯了這個錯誤，你很快就會發現你的生產力下降，因為新增新功能比你想像的困難許多。你承擔了會讓你癱瘓的技術負債，而你的 scrum 已經變得軟弱無力。（如果你曾經參與過真正的 scrum，你就會知道這是一件壞事。）

我之所以提到 Scrum，是因為當我們看到這個問題時，Scrum 似乎是團隊遵循的特定流程中特別常見的。對許多人來說，這個情況會因為 Scrum 而惡化，因為 Scrum 是以專案管理技術為中心的流程，並刻意省略任何技術實務，這與（例如）極限編程不同。

為 Scrum 辯護，有必要指出，儘管 Scrum 的範疇中不包含技術活動，但這不應該讓任何人得出結論，認為 Scrum 認為技術活動不重要。每當我聆聽傑出的 Scrum 倡導者時，他們總是強調，你必須具備良好的技術實務，才能讓 Scrum 專案成功。他們沒有強制規定這些技術實務應該是什麼，但你確實需要它們。畢竟，專案總是會因為內部品質不佳而陷入困境，許多專案在 Scrum 的旗幟下出現問題，可能是因為 Scrum 目前非常流行，而不是 Scrum 本身的任何特定因素。流行和語意擴散往往是相輔相成的。

那麼該怎麼辦呢？

Scrum 社群需要加倍努力，以確保人們了解強大技術實務的重要性。任何類型的專案檢討當然都應包括檢視有哪些技術實務。如果你參與或與此類專案有關，如果技術層面遭到忽視，請大聲疾呼。

如果你想導入 Scrum，請務必密切注意技術實務。我們傾向於應用許多極限程式設計的實務，而且它們非常合適。XPer 經常開玩笑，有些道理，Scrum 只是沒有讓它發揮作用的技術實務的 XP。撇開挖苦不談，XP 實務是一個良好的起點，而且肯定比什麼都不做要好得多。

我總是喜歡指出，成功或失敗的不是方法論，而是團隊。採用流程可以幫助團隊提升表現，但最終重要的是團隊，並且承擔讓對他們有用的做法付諸實行的責任。我確信許多正在執行的軟弱 Scrum 專案將會損害 Scrum 的聲譽，而且可能也損害更廣泛的敏捷聲譽。但由於我將語意擴散視為必然，所以我不會過度驚慌。失敗的團隊可能會失敗於他們錯誤應用的任何方法論，成功的團隊將根據好點子建立他們的實務，而 Scrum 社群的角色是廣泛傳播這些好點子。

許多人將精實視為下一個敏捷大趨勢。但精實越流行，它就會遇到與 Scrum 目前面臨的相同問題。這並不會讓精實（或 Scrum）變得一文不值，它只是提醒我們，個人和互動比流程和工具更有價值。