軟件工程到敏捷開發的一點小感想

    

      經過查閱資料和在暑期實習的經歷，我瞭解到敏捷開發中有些實踐方式是很好的，值得吸取。例如在敏捷開發的聖經「敏捷軟件開發-原則、模式於實現」一書中，不少設計原則，如「單一職責」、「開放封閉」、「依賴到轉」等，它們只是通常、通用的設計原則，應該應用在任何的開發方法中，這些原則並也不是隻有敏捷開發方法才能用，在任何的開發方法中均可以、應該使用。

       簡單介紹一下：敏捷軟件開發又稱敏捷開發，是一種從1990年代開始逐漸引發普遍關注的一些新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。雖然在國外已經獲得了普遍應用，在中國國內，敏捷開發用的還不算不少，而在咱們的教科書裏，更沒有介紹了。可是隨着Agile敏捷開發的流行，愈來愈多的公司採用敏捷開發用於軟件產品和應用的開發。

       然而敏捷開發做爲一種軟件開發方法，像是一種軟件工程開始出現以前的一種存在。如同幾個好友，在一個不大的小屋中開發軟件。表如今這些特色：

       幾我的組成一個小組，這個小組中的人共同完成軟件的需求、設計、開發和測試。小組中有簡單的分工側重，但其實每一個人都會參與每一個階段。用敏捷的話講，這就是產品人員、軟件工程師和測試工程師緊密配合的一個小組。工程師須要參與需求分析、測試工程師須要參與產品的設計、產品人員要不斷的經過當前已有的「原型」來挖掘、更改需求，固然，這是由於「產品人員不可能在一開始就看到全部的需求」。

在這個小組中，文檔只是用來輔助交流的，人們更多的使用口頭交流來明確一些細節問題或者是存在歧義的問題。文檔不準要作到「面面具到」。固然，這也是敏捷所推崇的。須要快速的接收並響應需求的變化，由於需求是一直在變的。
       咱們能夠看到，這也是「敏捷開發」的主要特色。敏捷開發是一種以人爲核心、迭代、按部就班的開發方法，相對於傳統軟件開發方法的「非敏捷」，更強調程序員團隊與業務專家之間的緊密協做、面對面的溝通（認爲比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、可以很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的做用。
       如今咱們來講說軟件工程作一下對比。軟件工程獲得人們的重視是在IBM OS360開發以後。人們認識到，軟件系統已經愈來愈複雜，愈來愈龐大。上面提到的這種開發方法暴露出愈來愈多的問題：對程序員要求太高、軟件質量難以保證、軟件開發完成後的維護成本巨大等。爲了解決軟件開發的這些問題，人們借鑑了傳統的工程項目的實施。建造一個大廈、建造一輛汽車等，這些工程不比軟件開發簡單，可是這些工程卻能被可控地實施並獲得質量良好的結果。由此，人們提出了「軟件工程」，它的首要目標，也是最根本的目標就是「將軟件開發工程化」。剩下的問題是，怎麼才能「工程化」？咱們仍然能夠從建築業和製造業借鑑他們成功的方法。咱們下面就來看看工程化的最重要的兩個方面。
       嚴格的過程控制。先作什麼，後作什麼，很是明確。好比先作需求分析、再作設計、再作結構施工、再作牆壁於管道等。而且，過程當中的每一步都要有肯定的產出，並經過驗收。這個產出的負責人和驗收負責人都要在驗收報告中籤字。若是這個產出在同一個工程中必須發生變化，那麼，這就是一次工程事故，根據事故的大小，責任人須要負「被開除」到「刑事犯罪」等不一的責任。例如，咱們要建造一個20層高的大廈，當主設計師完成結構設計後，他會對這份設計文檔簽字負責，驗收者會在驗收報告簽字。大廈的主結構就會按照這份文檔中的結構進行建造。若是到項目的中期，正在進行管道、線纜的部署時，發現，主結構是有問題的，中央主樑沒法承受足夠的扭矩。此時，設計師和驗收者的一句「咱們沒法在一開始就看到這個，在下一次迭代中會修復」是絕對不會被接受的。他們要負責任。一樣，若是此時產品人員過來講，客戶的需求變了，是25層而不是20層。而要達到這個要求的代價是：主設計師就須要將主樑的直徑增長20%、部分建築材料須要被替換。我想，對於這種產品人員而言，只能告訴他，你已經在需求文檔中籤字了，你須要負責賠償包括返工、材料、工期等方面的一切損失，你該辭職辭職，該坐牢坐牢。問題是：爲何軟件不能這樣呢？是由於軟件修改的成本低嗎？事實已經證實了，軟件修改的成本不低。
       嚴格的規格說明。規格說明文檔應該作到詳細、嚴格。舉個例子，在機械製造中，經常用到螺絲。在一個機械的設計文檔中，會詳細指定每一個螺絲在標準環境下（好比0攝氏度、5%的溼度、一個大氣壓）的直徑、螺紋間距、螺紋高度、以及熱膨脹係數等參數，負責製造螺絲的部門，拿到份文檔，甚至都不用見設計師本人，就能夠製造出合格的螺絲。這裏面，文檔纔是關鍵的東西。哪怕設計師換了、原來的螺絲部門的工人走了，只要有這份文檔和合格的工人，就必定能造出與原來同樣的螺絲。在硬件領域，bug之因此會少，很大一部分緣由是他們在用文檔設計。拿到文檔，一個懂verilog語言的人均可以編碼出合格的產品。只有設計文檔才能保證在本來設計、實現一個系統的人走後，後續的人可以很容易的繼續維護、擴展這個系統。

　　敏捷開發是一個過程，不是一個事件。在敏捷開發的各個過程當中可能集合了不少種傳統軟件開發方法，好比迭代、增量開發，甚至有瀑布、快速原型法的影子，也許還有更多。敏捷開發可理解爲在原有軟件開發方法基礎上的整合——取其精華，去其糟粕。所以敏捷開發繼承了很多原有方法的優點。這也是爲何如今敏捷開發爲不少工程師所推薦的方法。那個更好不能馬上下決定，對於不一樣的項目必定有他更適合的方法。敏捷開發，融合軟件工程的優勢。也能夠軟件工程融合一些敏捷開發的優勢來適應實際的項目。現在的快節奏，快餐化的軟件更傾向於敏捷開發。但重大項目簡單的敏捷開發是絕對不合適的。