一、為什么要敏捷開發

要敏捷開發是因為敏捷的特點是團隊能夠更加擁抱變化，這句話對應的受益者是誰? 我能想到最大的受益者就是業務方了。只要你不是在沖刺內部變更，你的需求其實可以一定程度上一直處于靈活調整的live狀態。(當然靈活的代價就是這些需求的反復帶來的團隊效力折損也是最終會由業務方承擔的，加錢或者加時間), 然而換來的是最終成品的滿意度和確定性，那么一定程度上也是。

敏捷的迭代周期性使得項目的方向能夠不斷被業務方Review，這與傳統瀑布式的最終驗收，一驗定成敗相比是一個更為科學且人性化的舉措。

我們知道傳統瀑布基本屬于階段性封閉式開發過程，一方面需求會被定格在項目早期，而在初期項目組掌握信息量較少情況下，對需求產生誤解是常有的事；另一方面后續開發過程客戶參與度較小，即使中途發現方向偏差，往往也木已成舟，改動代價很大， 有時甚至最后驗收時才被發現，項目被迫宣布失敗也是時有發生。

所以對于業務方來說，敏捷提供的周期性報告+反饋機制幫了業務方大忙。 “沖刺時低頭走路，沖刺完抬頭看路” 使得項目的成功率大大提高了。

延伸閱讀：

二、Scrum的特點

它獨特的短周期性沖刺確實一定程度上緩解了瀑布的原罪。

首先，”短”: 它把一個大項目拆成很多”故事”，把一次性評估整個大項目, 變成多次評估這些小”故事”，每次只評估有限的一小部分”故事”。這種方式有效地把評估精度提高，并把工作復雜度降低到了周級別，團隊精力集中在了刀刃上。試想: 如果讓你做未來一周和未來一年的日程計劃，你對哪一個更有把握? 去執行哪一項計劃時你感覺心中目標感更強烈?

其次，”周期性”: 使得工作可以進行平行迭代，什么意思? 首先不管瀑布還是敏捷，一個完整的功能多多少少還是會由需求->開發->測試 這么一個大致的順序開展的。 但不同的是敏捷的周期性賦予這些工序依然可以以固定時間差(周期) 不斷首尾相連， 重復滾動的機會, 這就使得敏捷模式下的工序可以平行開展。比如Sprint1的開發正在進行的同時， Sprint2的需求的收集和調研已經可以同時平行開展了。 從整個項目的高度來看， 這種每一道工序不斷迭代， 工序間又互相平行的做法極大程度縮短了項目時間， 加快了項目的進度，即我們所謂的敏捷的”快”。