敏捷開發是如何被跑偏的

今天聊聊敏捷軟件過程。

先說結論：據我觀察，至少有60%的團隊誤用了敏捷軟件過程，或者說至少60%的團隊在進行僞敏捷開發。

與你們一般的認知是相反的，敏捷過程並非一個很是容易實踐或者實施的過程規範。

一般來說，沒有天上掉餡餅的事兒，因此使用敏捷軟件過程帶來靈活性收益的同時，必定是要付出相應的代價的。

例如：

1. 若是須要實行結對編程，那麼在選擇團隊成員的時候就須要考慮人員的性格特質，或者增長相應的培訓和團建活動；
2. 若是須要實行測試驅動開發，則要求團隊成員對於自動化測試的技術掌握更加熟練和深刻；
3. 若是須要進行快速設計，則會對開發人員的設計經驗有必定的要求，並同時將來必定要有進行重構的時間安排才能夠；
4. 等等其它

最終，你會發現：若是一個團隊沒有能力實施傳統的軟件開發過程的話，則他們多半也沒法很好的實施敏捷軟件過程……

敏捷過程實施起來其實仍是有一些難度的。有一些團隊準備實施按部就班的策略：針對敏捷過程所要求的一些最佳實踐，先上一些比較容易實施的，而後在陸續加入其餘。

使人失望的是，這樣的作法也會引起一些問題。就拿很是流行的極限編程來說，極限編程所要求的最佳實踐其實是相互循環依賴的！因此僅僅選擇某幾項最佳實踐來進行實施的話，最終會致使整個系統的崩潰！好比：

1. 極限編程講究的是快速設計，可是其最終的設計合理性和最優性是由CRC討論會和後續的重構動做來保證的；
2. 極限編程省略了冗長的需求分析文檔，代之以即用即拋的「用戶故事」；可是爲了保證功能的正確性，他會有一個更加嚴峻的要求：現場客戶；
3. 極限編程沒有專門的測試階段，那麼如何保證產品的質量呢？輔助以三個最佳實踐：結對、測試先行和持續集成；
4. 重構動做保證了架構的最優化，可是誰來保證重構不會對系統帶來負面影響呢？測試先行和持續集成；
5. 相似的等等

因而，有很多團隊在實行了敏捷軟件過程以後，仍然停留在（或者說倒退回了）游擊隊式的野生軟件開發過程。

那麼如何纔可以正確的實施敏捷開發過程呢？我理解，至少須要具有以下的前提，纔可以比較順利的實施敏捷過程：

1. 團隊成員對面向對象的開發和設計有至關程度的理解和經驗（最起碼有想要提升或者學習的需求）；
2. 團隊成員可以熟練的使用自動化測試的框架，並編寫自動化測試腳本；
3. 團隊成員可以熟練的使用持續集成的框架或者產品；
4. 團隊成員平均溝通能力中上，沒有表達能力低下者；
5. 至少有一個渠道能和客戶（或者有足夠話語權的客戶表明）進行頻繁並流暢的溝通；
6. 管理者（包括甲方客戶）和開發團隊之間有相對比較平等的話語權；
7. 管理者（包括甲方客戶）可以理解（或者信任）開發團隊所提出的一些隱性的工做量（例如重構、編寫文檔、測試腳本等）所帶來的時間成本；

上述看似並不過高的門檻，卻擋住了60%的軟件開發工程師……