敏捷質疑: 反覆式開發法

　

迭代在於我們明確的承認資訊和知識的不完備性, 不可完備性. 而項目的成功, 需要某種程度的完備性.

這種認知的局限與成功的條件之間的矛盾, 促成了人們解決這類問題的通用方法: 漸進的試錯法

　

試錯法參考一: http://en.wikipedia.org/wiki/Trial_and_error.

試錯法參考二: http://zh.wikipedia.org/wiki/%E8%AF%95%E9%94%99%E6%B3%95: 是解決問題、獲得知識常用的方法，即根據已有經驗，採取系統或隨機的方式，去嘗試各種可能的答案。當問題相對來說比較簡單或範圍比較有限時，試錯的方法有一定效果。在試錯的時候，可以選擇一個可能的答案應用在待解問題上，如果沒有效就選擇另外一個可能的答案接著嘗試。整個過程在出現一個合適的可能性時結束

試錯法參考三: http://zh.wikipedia.org/wiki/%E5%8D%A1%E5%B0%94%C2%B7%E6%B3%A2%E6%99%AE%E5%B0%94#.E8.AF.81.E4.BC.AA.E5.8E.9F.E5.88.99: 證偽主義應採用試錯法。這是指人們應該大膽地提出假說和猜測，然後去尋找和這一假說不符合的案例。根據案例對假說進行修正，不斷重複這一過程，乃至將最初的假說全盤否定。試錯法對理論的修改和完善是沒有止境的，試錯法的結果只能是一個較好的假說，但不是最好的假說。最好的假說是終極真理的代名詞，和科學精神相悖

　

試錯法廣泛的應用於自然科學領域. 反覆式開發法就是試錯法在軟體開發過程方面的應用

　

不完備的資訊和知識, 至少包括以下幾個方面:

1. 客戶真正的意圖

2. 客戶業務真正的規則

3. 客戶項目所面臨的約束

4. 所採用解決方案的合理性

5. 所採用技術架構的合理性

6. 所採用技術的缺陷

7. 不可預知的變化, 包括商務規則的變化, 以及外界環境的變化, 等等

我們只能針對當前對以上問題的理解, 給出一個初步的解決方案, 然後所有人, 包括客戶和開發人員, 根據這個方案的運行情況, 對方案進行批評, 提出其無法滿足的約束或需求, 而回頭重新修正這個方案. 如此迴圈往複, 直到某個可接受的錯誤水平. (對於上面最後一條, 迭代採用的是短周期來減少變化帶來的浪費.)

　

迭代的核心就暫且止於此.

　

其它的一些問題, 都是目前的迭代實踐所規定的一些額外性質造成的, 比如"固定的迭代周期", 引起的問題是: 時間盒迭代刪減任務會不會導致完不成原定開發計劃?

這個問題是從太極敏捷派的FAQ中摘錄的. 對於這個問題, 太極敏捷的解釋並沒有觸及如下迭代的本質:

1. 迭代的開發方式中, "原定的開發計劃"並不是不變的. 隨著資訊和知識的逐漸完備, 我們會相應的調整"原定的開發計劃". (太極的解釋提及了計劃的不確定性: "計劃，與計劃的實際執行情況，是兩個不同的概念。決心不同於現實。所以，我們說，跟蹤、確保計劃的執行比制定完美的計劃更重要", 其後續的思路還在確保原定計劃的實現, 而絲毫沒有考率調整原定計劃)

2. 一如試錯法的結果, 迭代的最終結果不必滿足"原定的開發計劃", 只要經的起客戶的批判即可, 而敏捷開發有其它的手段來儘可能的保證這一點, 比如按照客戶認可的規則安排開發的優先順序, 這樣即使最後沒有完成全部特性, 但對客戶來說優先順序高的那些特性早就開始運行, 留下一些優先順序低的特性甚至可以拋棄了. 太極敏捷居然連這一點都沒有提及, 反映出其對敏捷/反覆式開發法的孤立理解.

　

另外的一些說法:

1. 試錯, 是為了獲得反饋. 迭代過程中, 要不要做某事, 其中一個依據是需不需要那方面的反饋

2. 迭代也為"回顧"提供了自然而然的機會. 試錯過程中獲得的資訊需要總結整理歸納抽象, 學而時習之, 溫故而知新

　

當然, 以上的論述建立在試錯法之上. 如果這一理論並不適合軟體開發, 那麼上面的論述都是沒有意義的. 那麼我們就用試錯法本身來檢驗一下其是否適合軟體開發:

假定其適合, 理由是可以協助解決以上提到的問題, 如漸進的搞清楚"客戶真正的意圖, 客戶業務真正的規則, 客戶項目所面臨的約束, 所採用解決方案的合理性, 所採用技術架構的合理性, 所採用技術的缺陷"等, 那麼請幫忙指出其不適用的地方, 或其本身帶來的問題, 如果可能的話提出更好的解決方案.