敏捷開發爲何敏捷

以往的開發都是模擬通常的傳統工業進行的。人們把軟件當作一個產品，一個流水線上的產品。因此就出現了先搞可行性分析（其實真正開發的時候沒人去搞這玩意兒，既然都要開發了還分析個什麼勁~），而後是需求分析，遇到負責的開發團隊偶爾會畫畫圖，要是遇到奇葩的開發團隊頗有可能一個需求闖天下了。整個軟件的開發週期中只有一個需求文檔其餘的什麼都沒有的開發團隊隨處可見，由於沒有文檔因此作不了升級因此只能推倒重來，因而開發人員感受文檔更加沒用，如此一來噁心循環。（這個關於文檔的內容不屬於本篇博客討論的話題）下面就帶着讀者來看一下敏捷開發是如何從傳統的開發模式演變而來，或者說軟件開發是如何一步一步的走向「成熟」（成熟是永遠達不到的，只是一個不斷追求的目標而已）。

第一層次

通常開發團隊中的搞需求的只負責與客戶交流而後傳遞信息，開發人員只負責編碼，測試人員（若是有的話）只負責測試。這樣以來就致使同一個時間只能有一撥人在幹活其餘人都須要等待。若是某一個階段有問題那麼只能回滾到上一個階段，在這期間的效率就大大下降了。

第二層次

後來人們將軟件分模塊，這樣一來開發人員能夠不用等待需求人員把整個需求搞清楚再去着手開發，而測試人員也能夠儘早的介入，及時發現問題。這大大的提升了效率，使得軟件開發更像是流水線上的產品，只不過這時把軟件拆分以達到提升效率的目的。須要注意的是這一切一切的前提是模塊的合理劃分（Maven就源於此）。

（在敏捷開發中每次迭代都被成爲一個sprint，中文意爲「衝刺」，可見其速度與效率）

第三層次

模塊化提升了開發效率，可是人們是永遠不知足的，還但願讓軟件開發更加高效。因而人們發如今上一個層次中浪費時間的階段就是交接階段。因此然們就在想若是讓一個開發人員從需求到開發到測試一鼓作氣豈不是再次的提升效率，因而scrum的雛形出現了。每一個成員負責一個模塊的所有，從需求分析到編碼實現，到測試。（衆多scrum工具就源於此）。

第四層次

分模塊，一人獨攬的確提升了開發的效率可是就像運動會的標語「更快，更高，更強」開發還能夠更加高效！在整個的開發過程當中人們發現雖然每一個模塊消耗的時間或者說人員成本基本相同，可是每一個模塊兒自身的價值是不同的。因而人們在上一個層次的基礎之上加入了優先級的概念，如此一來一樣的時間解決最有價值的問題大大提升了公司的效益。（在開發的後期客戶會本身根據投入產出比選擇是否繼續升級或者添加新的功能）

縱觀敏捷開發的發展，是一個實事求是的過程，是一個永不知足的過程。在敏捷開發中最重要的幾個方面：具備全局觀的組長，具備多種技能的成員（多面手），具備愛心的團隊。只有這樣敏捷才能敏捷，不然只會是一個形式，一切活動歸根結底都是人的活動，若是人的能動性沒有了，工具再先進，思想再超前也是白搭。