推廣漸進主義

時不時有人質疑某個特定專業領域是否能以漸進的方式進行：「你不能在敏捷專案中進行（安全性 | 使用者介面設計 | 資料庫 | 國際化 | * ）的作業，因為這些面向必須事先完成。」

當有人這樣問我時，我立刻陷入兩難，因為我不太了解那個專業領域。應用程式設計是我認為自己可以談論的，但安全性（例如）則不然，而且詢問我的人很可能是該領域備受推崇的領導者。

儘管我承認自己在該領域的限制，但我不會說你只能在那個領域使用規劃設計。我能說的是，我們並不知道你是否能在那個領域進行漸進式設計。我見過很多案例，人們說「你不能對 x 使用漸進式設計」，結果發現你還是可以。應用程式設計是一個，資料庫設計是另一個。因此，在人們認真嘗試漸進式設計之前，我非常不願意排除它。

評估這個問題的難處之一，在於以不良的方式進行漸進式設計太容易了。如果你以不受控的方式進行漸進式設計，你最有可能得到一個一團糟的設計，要讓漸進式設計發揮作用，你需要一些東西讓設計趨於一致。在 設計已死 中，我將這些稱為啟用實務。對於軟體設計，我將測試、持續整合和重構標記為讓軟體設計趨於一致並避免軟體熵的關鍵啟用實務。當我們談論其他事情，例如 UI 設計時，問題在於找出這些啟用實務是什麼。它們可能與軟體設計中的實務類似或受到啟發，也可能是不同的東西。例如，在資料庫設計中，漸進式資料遷移是一個關鍵的啟用實務。在你找到一套好的啟用實務之前，漸進式設計都是薄冰。

儘管如此，我確實認為漸進式方法非常值得，值得嘗試找出正確的方法。分階段的前置設計方法失敗的頻率太高了，此外，它們在應對不穩定的需求時做得並不好，而我認為這是不可避免的因素，至少在企業軟體開發中是如此。

然而，我偏好漸進式開發的最大原因是最古老的一個 - 風險管理。在未嘗試你的設計之前，你太容易受到事情不按照你所想的方式運作的影響，也容易受到開發後期進度延誤的影響。這些風險足以成為在軟體開發的更多面向中尋求導入漸進式開發方法的原因。