敏捷與速度

　我開始對敏捷的狂熱感到驚訝。敏捷看起來成了快速的代名詞，就像他們說的：“我們每個月發布一次，我們變得敏捷起來了?！钡悄悴⒉皇且驗楦於艚?，你是因為敏捷而更快。事實上，如果你什么也不做，僅僅是縮短了發布周期，而其他什么都一樣的話，你會比以前完成更少的工作。

　　明白敏捷開發如何讓你更快速 – 而不是相反的 – 是讓敏捷工作的關鍵。

減少摩擦

　　敏捷開發與傳統方法的核心區別在于讓變更變得更友好。這不意味著你需要笑著迎接變更；它意味著期待變更，并且讓變更帶來的影響最小化。換句話說，你通過減少摩擦來贏得速度。這可解釋為更少的程式和相關的管理。 

　　在瀑布模型你從業務需求分析開始，然后開發功能需求。隨后是功能需求被用于描述用例，用例由測試用例驗證和為最終用戶文檔化。軟件圍繞著高層設計來組織，然后由低層設計來細化和解析并轉換成代碼。這種階梯式的行進方式實際上是在避免變更：我們設想通過系統的、全面的方法可以完全防止變更發生的必要性。

　　敏捷方法在腦海中始終保持這種邏輯思維：斷言變更就是標準。軟件反映的就是用戶的需求，而用戶是在一個動態改變的組織中，處于一個充滿競爭的市場。因此，你永遠也不可能真正預知什么是需要的 – 你只能適應它。為了避免對相同功能的多個表達方式的變更，需求被歸納成為索引卡；功能需求和用例被分解成測試用例；而代碼則表達了設計的思想。

　　因此，通過減少大量的輸出，我們可以減少變更所需要的工作量。

提高速率

　　敏捷模型的另外一個響應變更的方法是通過更小的迭代。不僅僅是更短，而是更小。與其收集所有可能的需求然后分配到一系列的迭代周期中，我們專注于目前的迭代。規劃的周期越長，你就會越傾向于抵制變更：細化一個迭代周期只會帶來下一個迭代周期的代價，讓你脫離進度。

　　這個思想的背后是：用戶在直到看到真正的產品之前是不可能真正知道他們自己需要的是什么。需求文檔就像散文一樣可以用不同的方式解釋，但是代碼操作只有一種方式。我們往往發現：當軟件產品最終暴露在用戶面前時，才發現需求文檔充滿了錯漏和誤解。

　　因此，用戶能越快見到軟件，與軟件交互，你就越快知道軟件是否滿足他們的需求，即使不滿足需求，你需要改動的東西也會比較少。

擴大不確定性

　　對敏捷方法抵制，不管是公開的抨擊還是悄悄的害怕，都是由于敏捷論引入了不確定性。你不能預見下一個迭代，更不用說真正的發布，因為每一個迭代周期都可能包括新的功能或者對已有特性的調整。而如果你不能預見迭代的話，如何能計劃發布呢？

　

原文轉自：http://www.kjueaiud.com