敏捷軟體開發最近幾年越來越火。跟傳統軟體開發相比有什麼優點呢。今天我們就來聊一聊。

首先我們來看下什麼叫做敏捷。

敏捷軟體開發過程

軟體開發過程是指設計軟體開發過程中涉及的一系列活動，指導開發組一步一步的進行軟體開發。

包括傳統的瀑布過程、螺旋過程、原型過程、敏捷過程等。

敏捷則是一類過程的統稱。之所以把他們都稱之為敏捷，是因為它們有共同的特點。

敏捷過程講究快速迭代快速試錯，將一個大的專案分解成一個一個獨立的小專案，每個專案實現一定的功能，每個專案的成果物

都是可以執行的軟體。經過多次迭代之後完成整個專案。

這裡有兩個關鍵點：

1.獨立的小專案

2.每次交付可以執行的軟體。

與瀑布開發方法的對比：

1.粒度更小，更容易施加控制，降低複雜度。

2.更好的適應需求的變化。傳統瀑布方法需要經歷需求獲取、需求分析、設計、開發、測試、交付、運維等。上下步存在嚴格的依賴關係。一旦中間有任何一步出現問題則會導致難以估量的錯誤，越到後期修改的成本越大。而敏捷方法及時的引用開發和測試以及客戶參與，可以及時調整偏差。及時出現問題也只需要付出很小的代價。因此更靈活。

3.人的認知過程是循序漸進的，敏捷方法推崇增量式需求獲取。符合人類的認知習慣。經過多次迭代對需求認識越來越清晰，可以及時糾正原有的認知錯誤。而瀑布方法妄圖在開始時一次性花費巨大的代價獲取所有需求。而且獲取的需求也不一定是準確和完整的。

4.瀑布方法上下步是序列的，具有嚴格的次序關係。因此在執行前面的步驟時負責後面任務的人員都處於閒置狀態。人員利用率不足。

敏捷宣言

1.個體和互動勝過流程和工具

面對面溝通是最有效率的方式，人才是最重要的。勝過繁瑣的流程和工具。

2.可以執行的軟體勝過面面俱到的文件

文件只是工具不是結果。不能為了文件而文件。而應該將主要精力放在如何構建正常執行的軟體上。

3.客戶參與勝過合同談判

多和客戶溝通，讓客戶參與到專案中來，有助於交付滿足客戶期待的軟體。

4.響應變化勝過遵循計劃

擁抱變化，面對變更應及時調整策略

敏捷方法是一系列過程的統稱，都包括哪些過程呢？

XP(極限程式設計)、RUP(統一軟體過程)、Scrum等。

其中scrum在近些年越來越流行。因此我們專門介紹下。

Scrum英文意思是橄欖球，這裡用橄欖球運動來代表這種開發方法激烈、刺激。

Scrum是敏捷的一種，因此符合敏捷過程的所有特點。但是敏捷中的每種方法在具體實施時還是有一些不小的差異。

這裡我們著重介紹Scrum。

Scrum講究以人為本，採用迭代方法、循序漸進的開發軟體。

具有三種角色：

Product Ower：產品owner，類似於產品經理。負責收集需求，定義優先順序，確定需求實現程度

Scrum Master: Scrum教練，負責專案按照scrum流程執行，處理在專案執行中遇到的各種困難和阻力，把控質量、跟蹤進度。類似於傳統PM的角色但又有比較大的差異。

Scrum Team:Scrum開發組，在scrum的框架下執行專案開發工作。

Sprint

英文是衝刺的意思，代表一次迭代過程。每次迭代２－４周。

幾種活動：

Sprint plan meeting：衝刺計劃會議，在每次衝刺前進行。由scrum master product ower、scrum team和高層參加，時間一般為

4-8小時。Product owner將product backlog中的任務劃分優先順序，同時進行需求澄清。scurm團隊成員對本次sprint要完成的user story進行分解成task，挑選感興趣的任務並接進行工期估算。

Sprint daily meeting: 每日站會，兩個主題：昨天做了什麼，今天計劃做什麼。進度如何。

Sprint review :sprint 評審，每次衝刺結束時由Scrum team將本次衝刺完成的任務進行展示，檢驗執行情況和質量。長度控制在兩個小時左右，不需要ppt。與會人員根據sprint計劃會議的目標來評審目標的完成情況。

Sprint 回顧會議：回顧整個衝刺，總結和反思，促進團隊持續成長。

燃盡圖：橫軸表示sprint花費的時間，縱軸表示sprint中所有的任務。燃盡圖可以體現sprint的進度。

User Story:sprint backlog中的每一項都使用一個User Story來描述。一個User Story就是站在使用者的角度對系統的每一項功能的一項簡短描述。User Story粒度不要太大，一般需要在一個sprint內完成。Scrum team會將User Story拆分成一個或多個task。

scrum開發流程。

Product Owner在專案開始時將任務放進Product backlog，由於需求是增量式獲取的，因此這個過程也是增量式的向Product backlog中新增任務。

在每次sprint開始時，進行sprint plan meeting，會議上由product owner確定product backloug中任務的優先順序，scrum團隊決定本次sprint要完成的任務，將任務分解成工作項並進行工期估算，同時將任務從product backlog轉移到sprint backlog。衝刺階段每日進行sprint daily meeting，每次在15分鐘左右。兩個主題：昨天完成了什麼，今天計劃做什麼。有困難提出但會後和相關干係人討論，不佔用會上時間。衝刺結束時進行衝刺評審，對本次衝刺完成的任務進行演示。檢查完成情況。衝刺評審之後進行衝刺回顧，回顧過去的衝刺存在的問題，提出改進方案。重複以上過程，直到完成所有任務。

Scrum與加班的關係

敏捷不提倡加班。敏捷的開發不是一直以衝刺的力量奔跑，而是要求團隊成員密切配合步調一致，使整個專案有序的向前推進。

加班從長遠來看對整個團隊的士氣和戰鬥力是不利的。

加班的源頭，一是因為計劃不充分、不準確，中途有不可預料的變化。scrum的流程、每日sprint會議、sprint計劃會議等都是為了克服傳統軟體開發的弱點。這些弱點包括：流程無序、管理困難、難以變更、難以擁抱變化。另一個原因是文化氛圍或者觀念，認為只有

加班才能體現對工作的熱情，這是很幼稚的。對一個人來說，長時間的工作和生活的不平衡都會導致一些問題。敏捷開發講究以人為本，對於團隊來說如果人出了問題專案失敗的可能性就可能達達增加。

幾種中國式的敏捷：

極限程式設計：每天只工作8小時，還沒有達到極限，工作不飽和。來來來多給你分配點任務。

擁抱變化：產品、需求頻繁變更，朝令夕改，昨天說好的今天又變卦。

迭代式開發：做完了趕緊上線，出了問題再修復一版更新上去。

持續整合：每天提交幾百行程式碼，不用編譯不用自測不用測試用例。

測試驅動：點了兩下沒發現問題就可以釋出了。

迭代回顧：新版本剛上線肯定有很多問題，這兩天辛苦一下。24小時待命。

sprint衝刺：明天版本上線，大家辛苦通宵衝刺一下。

結對程式設計：開玩笑，一個人的任務兩個人輪流幹，每人只領一半工資行不行。