聊聊敏捷转型（上篇）︱敏捷软件开发

2.2无法按时发布
 
在敏捷流程中，版本的发布延迟最多不会超过30天，因为每个迭代的最长期限就只有30天。当到达交付期限的时候，就可以交付累积的增量。由于不会在迭代中开发低价值的功能，因此可以比以往更早地发布完整的系统。
 
2.3在版本发布的最后阶段让软件稳定的时间越来越长
 
在敏捷流程中，每个迭代所产生的增量都是完整和可用的，后续迭代所产生的增量都会包含之前所有迭代产生的增量，因此任何迭代产生的增量都是完成且可用的。也就是说，没有软件稳定化时期，因为软件一直保持稳定。
 
2.4在发布期间很难进行改变
 
版本发布中期的概念在迭代增量式项目中已经不复存在了。我们能够以最小的代价，在每个迭代开始前发现或者提出需求。
 
2.5质量持续恶化
 
在敏捷流程中，每个迭代产生的增量都是完整可用的。因此，增量必然已经通过质量测试。而后续迭代产生的增量同样要满足相同的质量要求，也就是说我们再也不必在项目的最后阶段为了赶上交付期限而牺牲质量，因为质量始终伴随着这个软件的整个开发过程。
 
3、敏捷有哪些优缺点
 
3.1敏捷的优点
 
敏捷的优点比较显著，主要有下面几点：
 
1、可以拥抱变化。可行的长期计划比较难制定并执行，在计划执行过程中会导致需求的变化，需求的变化必然导致开发工作不能按计划进行，而且“人”作为开发过程中最重要的因素时时刻刻都在变化，人员会有更替，人会有情绪，人会有私事，各种因素都会影响计划的执行，所以计划要短，及时调整才能响应一切变化导致的计划的不可行性，避免走弯路。
 
2、能够快速响应市场。市场环境的变化，越来越要求产品、服务的响应及时。比如按照传统方式，规划半年一个版本，一旦需要调整需求，后面所有的计划都得改变，会为项目管理带来极大的挑战，变化的成本奇高，多数情况下会因为多数人的反对而不了了之。 
 
3、快速将功能推向市场变现。“成为第一，胜过做得最好”，在很多商业环境下是有效的，特别是在互联网行业，迅速占领市场更显得尤其重要，这是在向时间要效益。
 
4、在有限的资源条件下，做最值得做的事。因为Backlog的每一项都具有按唯一优先级顺序，都是已经排好序了，敏捷要求逐项完成用户故事，而不是全面开花，因为其评价结果是二值的，做完就是1，做不完就是0，没有75%一说，因为做完了才能交付，做完了才能投向市场变现。
 
3.2敏捷的局限性
 
敏捷也有它一定的局限性，个人认为主要有下面几点：
 
1、项目人数不能太多，一般在5~10人左右；
 
2、对团队成员要求比较高，要有很高的自主性；
 
3、不是很适合传统大型项目，如基建，大型工程等；
 
4、缺少过程资产积累，注重沟通轻文档。若人员流动性太大会给项目维护带来不少难度。
 
在现在管理项目过程中，各种开发模式都有其独特的地方和优缺点。并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。
 
在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用。
 
我们在选择敏捷之前，首先需要解决的是要多问自己几个为什么，找到项目或产品中需要敏捷解决的真正问题是什么，再来选择是不是采用敏捷方式。