敏捷開發--經驗交流

淺談敏捷開發模式

　　最近在軟件行業逐漸興起的一種開發模式--敏捷軟件開發。對於一個沒有什麼經驗的菜鳥在這談論開發模式，有點不切合實際。可是經過看了相關的一些資料，對這種開發模式仍是有點潛在的我的觀點。

　　敏捷開發並非人們所認爲的沒有文檔的開發。這個是確定的，從我參加的一個項目中來講一點。以前和一個同窗給一個老師作的一個 普通話成績分析系統，原本打算給老師幫幫忙，畢竟本身的時間也很寶貴，當時說是1000塊錢。我先說一下咱們這個項目的作法（固然是很失敗的）：第一次和老師交流後，瞭解到了大概的意思，這時候真的感受和用戶交流的困難，老是想用專業的知識給老師解釋，可是老師都不懂，這很天然。由於用戶原本如此。  談了一個多小時，挖掘出一些東西。對於這個項目，第一步就失敗的是就是沒有弄一個文檔，以致於在後來總感受很簡單的東西，殊不知該作什麼了。　　和本身的團隊也沒有太多的交流，不過是每一個人負責一個模塊，而後再把代碼湊在一塊兒。拖拖拉拉的好久了。雖然最後大部分功能都實現了，但這個項目給個人感受是失敗的。

　　仍是那個句話，談開發模式，應該是具備豐富的開發經驗的牛人會有更深入的體會，個人觀點也僅僅是個人一些理解。 

　　在敏捷開發中，軟件項目的構建被切分紅多個子項目，各個子項目的成果都通過測試，具有集成和可運行的特徵。簡言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。 這裏總的歸納一下，敏捷開發由幾種輕量級的軟件開發方法組成：

極限編程（XP），Scrum，精益開發（Lean Development），動態系統開發方法（DSDM），特徵驅動開發（Feature Driver Development），水晶開發（Cristal Clear）等等。

 

　　·極限編程(XP)

　　就是天天獲得用戶的需求，可以第一時間得到用戶的要求；採用的是結對編程的方式。咱們所說的沒有文檔，其實在極限編程裏面，團隊之間的交流不是經過文檔，文檔不是必須的。團隊成員之間經過平常溝通，簡單設計，測試，系統隱喻以及代碼自己來溝通產品需求和系統設計。還有就是經過反饋，團隊之間，用戶和團隊之間都有反饋。在極限編程的團隊中，每一個人不得將未經過單元測試的代碼集成到系統中。所以，每一個人的代碼質量必須過關。

一些核心的作法：

　　·小規模，頻繁的版本發佈，短迭代週期。

　　·測試驅動開發（Test-driven development）。

　　·結對編程（Pair programming）。

　　·持續集成（Continuous integration）。

　　·每日站立會議（Daily stand-up meeting）。

　　·共同擁有代碼Collative code ownership.

　　·系統隱喻（System metaphor）。

　　我以爲每日站立會議是一個很不錯的作法，一個團隊中，天天都經過這個15分鐘的會議，來討論項目的狀況，交流，完善，對項目的成功頗有幫助。我那個項目最遺憾的就是，每一個人分一部分功能，而後就沒有了交流（項目上的），弄完了以後在組合，到時候出現了各類各樣的問題，不光會出現問題，並且我以爲沒有交流很容易疲勞。

　　其餘的部分即便說，彷佛菜鳥們總感受《軟件工程》沒什麼用途。。。

　　說說敏捷開發和瀑布模型式的一個對比吧。瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果做爲衡量進度的方法，例如需求規格，設計文檔，測試規劃和代碼審閱等等。 微軟就是在開發軟件的時候每個階段，都要通過嚴格的步驟，它的嚴格分級致使的自由度下降，項目早期即做出承諾致使對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明而且在項目進行過程當中可能變化的狀況下基本是不可行的。

　　而敏捷方法則在幾周或者幾個月的時間內完成相對較小的功能，強調的是能將盡早將盡可能小的可用的功能交付使用，並在整個項目週期中持續改善和加強。 

　　雖然閱讀了一些資料，可是由於沒有經驗支撐，因此讀起來比較抽象。潛在的看法，與你們分享一下。