今天聊聊敏捷軟件過程。

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

與大家通常的認知是相反的，敏捷過程并不是一個非常容易實踐或者實施的過程規范。

通常來講，沒有天上掉餡餅的事兒，所以使用敏捷軟件過程帶來靈活性收益的同時，一定是要付出相應的代價的。

例如：

如果需要實行結對編程，那么在選擇團隊成員的時候就需要考慮人員的性格特質，或者增加相應的培訓和團建活動；

如果需要實行測試驅動開發，則要求團隊成員對于自動化測試的技術掌握更加熟練和深入；

如果需要進行快速設計，則會對開發人員的設計經驗有一定的要求，并同時未來一定要有進行重構的時間安排才可以；

等等其它

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

敏捷過程實施起來其實還是有一些難度的。有一些團隊準備實施循序漸進的策略：針對敏捷過程所要求的一些最佳實踐，先上一些比較容易實施的，然后在陸續加入其他。

令人失望的是，這樣的做法也會引發一些問題。就拿非常流行的極限編程來講，極限編程所要求的最佳實踐實際上是相互循環依賴的！所以僅僅選擇某幾項最佳實踐來進行實施的話，最終會導致整個系統的崩潰！比如：

極限編程講究的是快速設計，但是其最終的設計合理性和最優性是由CRC討論會和后續的重構動作來保證的；

極限編程省略了冗長的需求分析文檔，代之以即用即拋的“用戶故事”；但是為了保證功能的正確性，他會有一個更加嚴峻的要求：現場客戶；

極限編程沒有專門的測試階段，那么如何保證產品的質量呢？輔助以三個最佳實踐：結對、測試先行和持續集成；

重構動作保證了架構的最優化，但是誰來保證重構不會對系統帶來負面影響呢？測試先行和持續集成；

類似的等等

于是，有不少團隊在實行了敏捷軟件過程之后，仍然停留在(或者說倒退回了)游擊隊式的野生軟件開發過程。

那么如何才能夠正確的實施敏捷開發過程呢？我理解，至少需要具備如下的前提，才能夠比較順利的實施敏捷過程：

團隊成員對面向對象的開發和設計有相當程度的理解和經驗(最起碼有想要提高或者學習的需求)；

團隊成員能夠熟練的使用自動化測試的框架，并編寫自動化測試腳本；

團隊成員能夠熟練的使用持續集成的框架或者產品；

團隊成員平均溝通能力中上，沒有表達能力低下者；

至少有一個渠道能和客戶(或者有足夠話語權的客戶代表)進行頻繁并流暢的溝通；

管理者(包括甲方客戶)和開發團隊之間有相對比較平等的話語權；

管理者(包括甲方客戶)能夠理解(或者信任)開發團隊所提出的一些隱性的工作量(例如重構、編寫文檔、測試腳本等)所帶來的時間成本；

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

總結

以上是生活随笔為你收集整理的如何 给给软件开发 添加 代理_敏捷开发是如何被跑偏的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。