要敏捷开发是因为敏捷的特点是团队能够更加拥抱变化，这句话对应的受益者是谁? 我能想到最大的受益者就是业务方了。只要你不是在冲刺内部变更, 你的需求其实可以一定程度上一直处于灵活调整的live状态。
一、为什么要敏捷开发
要敏捷开发是因为敏捷的特点是团队能够更加拥抱变化，这句话对应的受益者是谁? 我能想到最大的受益者就是业务方了。只要你不是在冲刺内部变更，你的需求其实可以一定程度上一直处于灵活调整的live状态。(当然灵活的代价就是这些需求的反复带来的团队效力折损也是最终会由业务方承担的，加钱或者加时间), 然而换来的是最终成品的满意度和确定性，那么一定程度上也是。
敏捷的迭代周期性使得项目的方向能够不断被业务方Review，这与传统瀑布式的最终验收，一验定成败相比是一个更为科学且人性化的举措。
我们知道传统瀑布基本属于阶段性封闭式开发过程，一方面需求会被定格在项目早期，而在初期项目组掌握信息量较少情况下，对需求产生误解是常有的事；另一方面后续开发过程客户参与度较小，即使中途发现方向偏差，往往也木已成舟，改动代价很大， 有时甚至最后验收时才被发现，项目被迫宣布失败也是时有发生。
所以对于业务方来说，敏捷提供的周期性报告+反馈机制帮了业务方大忙。 “冲刺时低头走路，冲刺完抬头看路” 使得项目的成功率大大提高了。
延伸阅读：
二、Scrum的特点
它独特的短周期性冲刺确实一定程度上缓解了瀑布的原罪。
首先，”短”: 它把一个大项目拆成很多”故事”，把一次性评估整个大项目, 变成多次评估这些小”故事”，每次只评估有限的一小部分”故事”。这种方式有效地把评估精度提高，并把工作复杂度降低到了周级别，团队精力集中在了刀刃上。试想: 如果让你做未来一周和未来一年的日程计划，你对哪一个更有把握? 去执行哪一项计划时你感觉心中目标感更强烈?
其次，”周期性”: 使得工作可以进行平行迭代，什么意思? 首先不管瀑布还是敏捷，一个完整的功能多多少少还是会由需求->开发->测试 这么一个大致的顺序开展的。 但不同的是敏捷的周期性赋予这些工序依然可以以固定时间差(周期) 不断首尾相连， 重复滚动的机会, 这就使得敏捷模式下的工序可以平行开展。比如Sprint1的开发正在进行的同时， Sprint2的需求的收集和调研已经可以同时平行开展了。 从整个项目的高度来看， 这种每一道工序不断迭代， 工序间又互相平行的做法极大程度缩短了项目时间， 加快了项目的进度，即我们所谓的敏捷的”快”。
