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