作为团队的负责人，你希望将研发模式从瀑布式转为敏捷，并进行持续改进，但却不知道从哪里开始？
作为项目管理人员，你希望负责建立迭代机制，并进行规模化的推广和度量，但却不知道如何快速建立机制？
作为产品经理，需求排期后，你希望能方便地跟进需求进展，及时发现问题，但却不知道怎么跟进方便？
上图是双周迭代的运作流程：
在N-2和N-1周，业务和产品会持续做需求的分析和设计，会把要排入迭代的需求按优先级高低准备好，包括需求的分析、设计和澄清；
随后开发和测试同学在排期后的两周内（N周和N+1周），按优先级对需求进行开发、测试、验收和发布上线。
注：排入迭代的需求在迭代排期前要已澄清清楚，并明确验收标准。
迭代排期在双周迭代中起着前后衔接的作用，每两周进行一次，一般每次1～2小时。排期前，业务和产品同学需要准备好待排期的需求，排期后，开发和测试同学需要按照计划对需求进行开发、验证和发布。
迭代节奏和发布频率是要解耦的，迭代节奏可以是两周或一周，而发布频率可以是每两周一次、一周一次、或一周多次等。有的企业或团队会按照每个迭代进行一次发布来落地，也有按照一个迭代进行多次发布来落地。
活动名称
迭代排期（双周迭代）
活动目标
需求小批量输入，减少开发的并行度，确保需求高质量地持续输入和输出
实现对就绪队列（已排期或者待开发）有节奏的填充，明确本次排期到下次排期间的发布计划
负责人
产品经理、研发负责人
主要职责
明确本迭代的业务目标，决定做什么需求，决定需求优先级
参与人
开发、测试
明确本迭代的团队容量，决定需求工作量
频率和时长
输入
过程
输出
明确的本次迭代需要达成的业务目标；
已排好唯一优先级顺序的产品待办列表；
已澄清的待排期需求；
需求已拆分到可在一个迭代内完成交付；
各需求的技术方案已评审通过（包括但不限于各模块间依赖关系、接口定义）；
提前梳理好下一迭代的需求列表；
注：1，2，3，4，6由产品经理负责、5由研发负责人负责
研发负责人回顾上一迭代需求的完成情况，并把未完成需求移入当前迭代中；
产品经理介绍本次迭代的目标，并按优先级讲解迭代待办列表中的需求；
研发团队评估各需求的工作量，根据团队整体人力容量情况，确定本次排期的需求列表；
明确本迭代的需求发布窗口（节奏固定的话，不用每次都讲）
产品经理讲解下一次计划排期的需求列表；
本次迭代的目标和已排期的需求列表（迭代待办列表）；
已排期的需求标记好迭代；
本次迭代内的发布窗口和对应的需求列表；
下一次计划排期的需求列表；
我们会看到，在排期输入、排期过程、排期输出环节的要求比较多，如果没有要求的话，排期会将会比较低效，后续的迭代推进也会出现各种问题。如下，是我们在辅导敏捷开发团队过程中总结的几个注意点：
明确的迭代目标
迭代需要有比较明确的目标，没有目标容易出现需求范围蔓延的情况，导致团队成员无法聚焦
需求唯一优先级
很多产品经理在提迭代需求时，会出现需求的优先级都是“紧急”的情况，其实这反映了需求的真正优先级是不明确的。我们需要明确出唯一优先级排序，这个过程不但能够让团队深入思考、对优先级提出积极挑战，也能梳理出优先级高、真正对业务有价值的需求；
需求已澄清且技术方案已确认
需求已澄清是排入迭代的基本要求，有些团队会把未经过分析、设计和澄清的需求排入迭代，导致排期时无法给出准确的工作量预估，也无法快速进入开发，这会影响其他需求的进展和整个迭代的节奏；
需求已拆分
通常情况下，需求要拆分到在一个迭代内可以完成交付，方便快速验证业务假设，缩短业务的响应周期；
明确需求负责人
需求进入开发时，一般会需要多位技术同学合作完成，如前端和后端，或多个后端，这时我们建议由其中一位同学担任需求负责人，跟进需求到发布上线为止。这样可以更好地协调开发内部协作，避免过程中的争论或互相推脱，提升整体的协作效率。
同步下一个迭代的需求
有的研发团队会说不知道接下来要做什么，也有的团队会出现需求断档，这里建议产品经理可以提前把下一迭代要做的需求同步给大家，让大家了解近期规划，以便更好地安排研发节奏。
敏捷开发落地往往需要平台或工具支撑，下面我们以云效项目协作·Projex为例，介绍如何使用工具来高效落地迭代排期活动。
1.创建迭代，并明确的本次迭代需要达成的业务目标，负责人：产品经理或研发负责人
通常创建迭代由产品经理或研发负责人负责，此时需要明确迭代的名称、负责人、迭代周期、迭代容量和迭代目标，需要注意：
迭代名称：需要遵循一定的规范，如“迭代+迭代结束日期”；
迭代容量：团队人数相对固定时，一个迭代内的工时容量也是相对固定的，如：双周迭代，是10个工作日，如果团队有7位同学，一天的有效工时按照8个小时计算，容量就是560个小时；
迭代目标：目标需要具体可衡量，且与业务目标有直接或间接的关系。
2.将产品待办列表按优先级排序，负责人：产品经理
云效项目协作·Projex的需求管理中，产品经理可以根据诉求使用过滤器，配置“产品待办列表”公共视图，视图默认按照优先级排序，也可以设置成按照状态、负责人等其他自定义属性排序。
3.待排期的需求已澄清，并满足准入排期的要求，负责人：产品经理
4.保证需求已拆分到可在一个迭代内完成交付，负责人：产品经理
5.各需求的技术方案已评审通过（包括但不限于各模块间依赖关系、接口定义）负责人：研发负责人
在云效项目协作·Projex中，对于已澄清的需求，需求更改状态到“已评审”状态。技术方案已确认的需求，可以在需求上打上“技术方案已确认”的标签。
注：团队在云效项目协作·Projex中创建项目时，可以定义需求的工作流，建议为「待处理-已选择-设计中-已评审-已排期-开发中-待测试-测试中-待验收-待发布-已发布」，点击项目中设置，进行需求工作流的配置，可参考PM如何设计工作流和创建看板的4.2章节。
在这个工作流下，仅对状态为“已评审”的需求进行排期。
6.提前梳理好下一迭代的需求列表，负责人：产品经理
为什么要在这个迭代中去讲下一个迭代的需求列表呢？在辅导云效客户的研发团队过程中，我们发现有的研发团队会出现，不清楚下一迭代会做什么或需求断档的情况。如果你们的团队也有类似的问题，建议在迭代排期的时候，邀请产品经理把下一迭代需要做的需求大致讲一下，让研发团队提前了解并识别风险（如果你们团队没有类似的问题，可以跳过这个环节）。
在云效项目协作·Projex中，下一迭代的需求可以用两种方式呈现，一种是给需求打上“下一个迭代需求”的标签；另一种是直接把迭代字段更新到下一个迭代。如下图，是以标签方式实现对下一迭代需求管理的方式：
也可以借助自动化规则，在排期会开始之前，将处于进行中状态的迭代中未完成的工作项，推送到相应的钉钉群中。
钉钉群中的消息提醒：
首先产品经理可以在迭代概览中，看到创建迭代时设置好的迭代目标，并向研发团队介绍。
随后，产品经理按优先级讲解迭代待办列表中的需求（需要通过评审和技术方案确认）。在云效项目协作·Projex的迭代规划中（如下图），产品经理可以通过所需条件过滤需求（过滤条件可以保存），并按照优先级高低讲解需求，讲解过程中或之后，可以直接将排入迭代的需求拖拽迭代卡片中。
在排期的过程中，研发团队需要评估各需求的工作量，根据团队整体人力容量情况，确定本次排期的需求列表：
明确需求工作量：需求工作量是指各需求需要的人力工时数量，可在排期会前或会上进行估算；
确定迭代容量：迭代容量是研发团队一个迭代所能投入到需求完成的工时总量；
在排期的时候，我们可以随时在目标迭代的右上角查看排入需求与团队工时容量的匹配情况。
明确需求的负责人：这里特指需求的开发负责人，需要负责需求从进入开发到发布上线的全过程；
需求拆分到开发任务：需求的开发负责人需要负责将需求拆解到各个开发任务，Web端、H5或客户端的需求，往往需要前端和后端的联合开发，或者一个需求要不同开发同学负责，还会涉及到联调任务，此时便需要对需求进行任务的拆解。不过，对于特别小颗粒度的需求，也可不进行任务拆解。
更新好需求状态：需求排期确定后，需要的状态要更新到“已排期”。可以通过设置自动化规则，当需求规划进迭代后，自动变更状态为“已排期”。
这一点要看团队的实际情况，有的团队是固定发布窗口，有的是一个迭代一次发布，也有的是一个迭代多次发布。
如果是持续发布的，那这一条可以忽略。
产品经理按照优先级和状态讲解下一次排期的需求情况，可以用标签，也可以直接用迭代来标记；
在迭代规划会后，我们需要有明确的产出：
本次迭代的目标和已排期的需求列表；
已排期的需求用迭代标记，规划入迭代；
前面5个点我们在云效项目协作·Projex迭代详情页面的“工作项”中均可查看，包含需求名称和各关键属性，如下图：
当你打算落地敏捷开发方法时，我们建议一开始就要让团队成员理解敏捷迭代的落地过程，并共识双周迭代的运作机制，这样可以让整个团队都心中有数，并提前准备关键事宜。
迭代排期会前，产品和研发团队需要把待排期的需求准备好；
迭代排期会时，产品和研发团队需要达成共识，明确排入迭代的需求列表，并做出相应的承诺；
迭代排期会后，需要对排期的计划进行推动和跟进，直到需求完成开发、测试和发布上线为止。