文章标题（敏捷双周迭代模式）
导语：敏捷研发管理原文链接：https://blog.csdn.net/weixin_41224436/article/details/140702504
正文：
前面几篇了解了敏捷开发的实践以及敏捷迭代管理，Scrum敏捷中，建议是2～４周一个迭代周期，较为广泛应用的是双周迭代模式，即两周完成一个迭代周期，一个迭代周期是指，软件开发到上线的时间。
在研发人员还在开发当前迭代的功能时，产品经理就规划好下一个迭代的需求，工作交替进行，这样能保证设计工作和开发工作无缝衔接。
双周迭代的开发过程
双周迭代执行过程
在 N-2 和 N-1 周，产品会持续做需求的分析和设计，按优先级梳理并完成规划进入下个迭代的待办事项列表。
迭代开始后，开发和测试同学在迭代Sprint 1排期内（ N 周和 N+1周），按优先级对需求进行开发、测试、验收和发布上线。
每两周进行一次，一般每次 1～2 小时。当sprint 1进行时，产品持续做好衔接，进行sprint 2的需求分析和设计等。
发布频率：可以是每两周一次、一周一次、或一周多次等。一般团队会按照每个迭代进行一次发布来落地。
排期时一定要预留出部分时间，来处理突发事件或技术需求，如个别紧急需求、线上重大 bug 、技术类性能优化、数据迁移、服务器部署等。
迭代可能存在的问题及解决方案
迭代容量的评估不准确
可能造成的原因：
中途插入紧急需求和紧急BUG。
容量评估不准确。
解决方案：
迭代评估排期时预留10%-20%的时间解决紧急线上BUG和紧急需求。
迭代内需求排优先级，优先做优先级高的需求，确保基本迭代目标完成。
对于线上紧急BUG提高优先级，规划进迭代优先处理，确保用户正常使用。
考虑将低级别的需求或BUG移到下个迭代解决。
若无紧急事件插入迭代，再完成迭代内优先级低的需求或缺陷。
容量评估：基于团队研发经验的「故事点」来明确迭代的团队容量。「故事点」与研发工作量（人日）没有明确的换算关系。它包含了对开发任务量、复杂度、风险和不确定性的整体预估。具体估算方法、步骤可以参考产品「PingCode」的「故事点估算」相关介绍。
团队积极性不高
可能造成的原因：
单个需求拆分不合理，需求太大，开发周期长，长时间看不到产出，容易让开发人员产生疲惫。
规划时没考虑前后端任务分布，比如后端任务繁重，而前端没有多少任务。
解决方案：
产品经理拆分需求，将需求拆分到「单周开发、双周上线」的粒度，如果不行，就继续拆分；
规划时考虑前后端任务平衡问题，可适当加一下后端技术优化、性能优化、数据迁移类等以及前端组件优化类的需求来进行平衡。
跨项目协同，研发节奏互相依赖
解决方案：
产品经理一般在当前迭代开始进行时就开始着手准备下个迭代的待办事项了，在准备期间，如果有出现跨项目的需求，则需求提前添加那条产品线的产品所有者（Product Owner）为关注人。
对那条产品线的产品所有者进行描述，需要他在他所在团队的下个迭代里添加一个支持类的需求。并将两边迭代的需求进行关联。
等下个迭代开始评估时，分别由两边团队的Scrum Master指定需求开发负责人，并由他们进行编码联调。
选择合适的迭代模式
迭代节奏是可变的，偶尔可能会从固定的两周延长三周或四周。尤其在面对复杂的业务实现，可能前期技术实现就占掉了一周，做的需求也无法在系统上有直观的体现，不能让用户立马使用体验，可能考虑迭代周期是否要延长一周。
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
上传的图片插入到文章编辑器内
