敏捷排版
2006 年 10 月 2 日
根據敏捷聯盟現任董事會的說法，敏捷方法 「已經跨越鴻溝」，我想這表示它們正變得更加廣泛。雖然這有其優點，但也帶來問題。當一種方法論或設計方法變得流行時，我們會看到許多人使用它或教授它，而這些人專注於流行，而不是真正的細節。這可能會導致以敏捷的名義做出的事情的報告，而這些事情與運動創始人的原則完全相反。
在網路上瀏覽時，我聽過一些評論，說敏捷方法是由高層管理人員強加給開發團隊的。對團隊強加一個流程完全違反敏捷軟體的原則，而且自其成立以來一直如此。
對我來說，敏捷方法的一個關鍵特徵是它們 以人為本。它們認識到人及其合作方式是軟體開發中的主要因素，而流程是次要因素。這反映在 敏捷宣言 的第一個價值觀中「個體和互動高於流程和工具」，並由宣言的兩個 原則 加強
- 以有動機的個人為中心建立專案。給予他們所需的環境和支援，並相信他們能完成工作。
- 最佳的架構、需求和設計來自於自組織團隊。
這些價值觀和原則的一個重要後果是，團隊應該選擇自己的流程，一個適合他們工作的人員和環境的流程。從外部強加一個敏捷流程會剝奪團隊敏捷思維核心的自決權。
此觀念更進一步，與宣言中的另一項原則相符：「團隊定期反省如何提升成效，並據此調整行為。」團隊不僅應該選擇自己的流程，還應掌控流程的演進方式。
此觀念，即流程應符合團隊（而非相反），是敏捷方法的必要條件，但顯然並非充分條件。團隊可能會選擇完全瀑布式、非敏捷的流程。在這種情況下，流程顯然不會比蘋果嚐起來像草莓更敏捷。但敏捷方法並非適用於所有情況，而我個人寧願團隊以自己選擇的非敏捷方式工作，也不願將我最喜歡的敏捷實務強加於他們。
因此，我希望我已清楚說明，強加敏捷方法是一個非常危險的訊號。然而，當我聽聞此事時，通常並未獲得完整的故事。有些情況從外部看來可能類似，但實際上並非如此。
一種情況是學習。導入敏捷方法通常涉及一次學習許多新事物，其中許多事物與直覺相悖。這在極端程式設計中尤其明顯。在這種情況下，在使用一段時間之前，很難調整流程（我在數年前撰寫了這篇文章，探討極端程式設計）。此時，團隊處於守破離的守階段，因此需要非常死板地遵循實務，直到他們了解其運作方式為止。在這種情況下，教條主義和僵化是一種（暫時的）學習工具。
我們在 Thoughtworks 通常會遇到的另一種情況是，我們與客戶團隊共同外包專案。在這些情況下，我們大多負責軟體交付，但我們需要與客戶人員合作，以提供良好的交接，並讓客戶人員了解我們的運作方式。在這種情況下，我們會獲得報酬，因此我們會使用對我們有用的流程。這並不表示我們不會根據客戶環境調整流程，這始終是必要的，但在合理的調整和放棄讓我們成功的實務之間，存在一條微妙的界線。
這些情況顯示，強加並不像聽起來那麼明確，但基本觀點仍然存在 - 強加敏捷方法會與敏捷方法的價值觀和原則產生衝突。
這種問題是無法避免的。我清楚記得有一段時間，面向物件很流行，而且所有稀奇古怪的事情都以物件的名義完成。這都是正常採用程序的一部分。無法阻止將敏捷名稱套用在非常不敏捷的行為上，因為沒有敏捷警察強制執行RigorousAgile。我們唯一能做的，就是對於那些關心的人持續嘗試解釋敏捷的真正意涵。而我比較喜歡解釋，而不是說服。