如何理解敏捷開發？

沒有參與過敏捷開發專案的人可能覺得敏捷開發抽象難懂。舉個例子，敏捷開發像是在衝浪，一直處於動態、不斷變化的環境中。在專案研發過程中出現的需求變化和挑戰就是你在衝浪時要應對的海浪。他們從不停止而且永遠在變化，這種情況下意味著需要快速地適應變化。

首先，敏捷開發是一種過程控制方法，通俗的說，就是一種做事情的方法。

1. 它主要適用於軟體，在運維、服務等領域也有廣泛應用，但在硬體領域還沒有成熟的方法，因為硬體一般不允許需求變更。
2. 它適用於客戶不知道自己要做什麼的情況，其實，這樣的客戶佔絕大多數。因為客戶不知道要啥，所以你需要不斷幫客戶弄明白他到底想要啥。換句話說，你需要和客戶溝通，合作，傾聽反饋，持續改進。
3.

它適用於競爭激烈的市場，這樣的情況下，趕在競爭對手前交付一個不完美但至少能用的產品非常重要。
4. 它適用於快速變化的市場，你在埋頭造一輛汽車的時候，客戶已經想開飛機滿天飛了，這就需要你能一步步的把汽車改成飛機，還能按時交付。
5. 它適用於小團隊，一般5-9個人。這樣能使敏捷中主要的溝通方式“Face to Face” 是可行的。

其次，敏捷開發是一套工具集，裡面有形形色色的工具，你也可以將各種最佳實踐提煉成敏捷實踐。你可以不搞敏捷，但可以用其中幾個來提高工作效率。

比如：

1. 站會：三個問題，簡潔有效的小團隊溝通方式
2. 看板：直觀反映工作進度，反映流程遵守情況，反映流程缺陷
3.

演示，計劃，反思會：適合於小團隊的協作和優化反饋方式
4. 使用者故事：站在使用者的角度講需求
5. 持續整合：隨時高質量交付的基礎，有利於應對變化劇烈的市場

最後，敏捷開發也是一種企業管理方式

1. Team可以是架構師，開發工程師，測試工程師，發揮了他的主觀能動性，有利於創新和效率
2. 敏捷不專注于敏捷團隊中個人的績效考核，而更多的側重於整個團隊的績效，更好的避免了KPI驅動模式。
3. 把大專案拆分成小專案去做（每個Sprint都是一個迭代，需要輸出一個高質量的版本，相當於完成一個小專案），把bug的生存期控制在一個迭代以內，降低了風險，也減少了後期改bug的工作量。
4. 把數十人的大team

分成幾個敏捷團隊，這幾個敏捷團隊的SM/PO再組成一個更高一級的敏捷團隊，利用站會，回顧會，看板等等敏捷元素，可以避免數十份郵件也不能解決一個小問題，大家互相踢皮球，溝通不暢的大企業病。
5. 老闆可以是最大的PO，他給下面的高管講idea(UserStory)，定期檢查Demo，把控產品使用者體驗，負責和外界的溝通合作。

綜合各方觀點，敏捷開發是：在高度協作的環境中，持續不斷地快速輸出可交付產品，通過反饋進行自我調整和完善的方法。