文档介绍：敏捷开发的八个实践经验
敏捷开发的八个实践经验
敏捷开发越来越火热，但在实际应用当中很多时候都是只有敏捷的“形”，却缺少敏捷的“神”，还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的，此外还需要各个业务部门对敏捷的
敏捷开发的八个实践经验
敏捷开发的八个实践经验
敏捷开发越来越火热，但在实际应用当中很多时候都是只有敏捷的“形”，却缺少敏捷的“神”，还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的，此外还需要各个业务部门对敏捷的理解和支持，形成合力。以下分享产品项目里的八个敏捷开发实战经验。
在《Scrum：兼顾计划与灵活的敏捷开发》一文中，作者最后也提到过，借鉴一种新的模式的时候，最好能够批判性的吸收其精华的部分，不能全部照搬，照搬了反而会出问题。
其实敏捷对产品经理的要求是很高的，需要安排至少两个迭代的任务，两个迭代的规划。
对程序员的要求也很高，当所有的任务都拆散了之后，最终做出来的东西要形成一个产品，技术人员的整体意识要比较强，且一开始就得熟知产品的整个规划，否则到最后就会出现所有任务都已完结，合并出来的最终产物却是什么都不是。
并且敏捷开发不仅仅是IT部门的事情，还需要各个业务部门对敏捷的理解和支持，形成合力，从而提升开发效率和业务满意度。
运行一段时间的敏捷之后，发现最容易接受敏捷这种方式的是开发团队，不管是瀑布式还是敏捷，只是做工作的形式不一样了，进度更容易把握了，更能适应需求的变化了，实质其实并没有变化。
对测试团队来讲，测试资源调配会更加的紧张，敏捷要求做完一条测一条，与原先的整体项目排期完全不一样;对产品经理来说，敏捷能让自身更好的掌握整个产品的进度。
敏捷开发的迭代周期没有硬性的规定，结合项目里程碑、目标、功能实现情况、产品稳定性综合决定，如果产品用户活跃、功能实现难度小、维护复杂度低，建议以周为周期。
对于规模比较大、维护复杂度高的产品，考虑以2周-6周为周期发布较为合适;频繁的发布会降低用户的期望并提高用户成本，给用户心理上带来额外的负担：他会认为产品质量低，质量控制不严谨等;
五、敏捷开发为何提倡小版本?小版本有哪些优势?
小版本的目的就是分解复杂度、降低风险，改善团队士气等;小版本有众多优势：
1、总体风险比较少：小版本变化小，总是在上一个版本基础上局部调整和增加，技术复杂度低;由于规划的功能较少，工作量也易于估算，所以其总体风险比较少，常常能如期发布;
2、需求的接纳能力强：由于小版本快速实现并发布测试，然后就进入下一个版本的规划实现周期，这样新需求一旦提出就能快速进入开发视野，就能尽快实现;
3、测试和开发高效协作：开发和测试可以并行工作，当开发实现第一个版本时，测试设计测试方案和用例;发布第一个版本后，开发就进入下一个版本轮次，测试就应用测试方案测试刚才发布的版本，提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug，然后发布新版本，如此循环往复，开发和测试实现高效协作;
六、敏捷开发为何强调团队人员的参与、用户的参与?
敏捷强调团队成员的高度参与就是要统一认识，把团队的目标变成每个人的工作目标，使之为每个团队成员的认同，形成高度的凝聚力，以达到群策群力、高效协作的效果。
由于没有高度细化的文档，成员之间