嚴謹敏捷

我常遇到一個抱怨，說敏捷方法沒有嚴謹的定義。抱怨者可能會說，這表示你無法判斷一個特定的團隊是否在使用敏捷方法。他們也可能會說，這使得很難教導人們如何執行敏捷方法，課程是什麼？

在某種程度上，我確實感受到這個抱怨的痛苦，但我接受這個抱怨沒有解藥。這種不嚴謹是敏捷方法定義本質的一部分，也是其核心哲學的一部分。

一般來說，思考過程的基本問題之一，特別是軟體開發，就是設定的性質非常多樣化。不同類型的系統有不同類型的壓力和力量，這使得很難提出一個嚴謹的陳述，說明要如何做才能涵蓋它們。軟體開發是一種以人為導向的活動，而人天生就不一致且變化很大，這會加劇這種影響。敏捷主義者從中得出的結論是，試圖將軟體開發綁定到一個嚴謹的過程中是沒有效果的，因為這忽視了執行該過程的主要（人類）組件的基本性質。

（這可能是因為我們的職業是與電腦一起工作，這導致我們想要像編寫電腦程式一樣編寫人類系統，儘管它們如此不同。）

這一切的結果是，敏捷方法從根本上期望團隊決定要遵循什麼流程，而且期望團隊積極且定期地變更他們的流程。任何嘗試定義一個可測試是否符合規範的嚴謹流程，都與這種哲學背道而馳。

我無法否認這令人沮喪。當你無法明確定義 Scrum 為何時，你如何進行一項調查，探討敏捷方法是否比其他方法更有效，或極限程式設計是否比 Scrum 更有效？如果客戶想要使用極限程式設計來建構系統，他們如何得知這是否真的有做到？有一種「我看到時就知道」的感覺，但需要有經驗的從業人員才有這種感覺，即使如此，這些從業人員之間仍有很大的分歧空間。

我沒有答案可以解決這個難題。事實上，我不認為有答案。這是活動本身不幸的後果，就像游泳時會弄濕一樣，這是無法避免的後果。

於 2012 年 7 月 26 日重新發布