Being Agile！如何开好迭代计划会-京东云开发者社区

#### 开好迭代计划的技巧：
- 线下自主认领任务，管理成本低
- 采用团队速率评估迭代交付范围
- 三层评估动作：
① 需求梳理会上的可行性和规模粗评估 
② 迭代计划会上的共同估算 
③ 个人任务的详细计划
- 对上一迭代的任务跟进，保障不丢不拉工作
- 根据历史积累，设置团队的故事点规模
- 一次认领一个任务，个人并行的任务小于3个，保障效率

------------
#### 一、什么是迭代计划会
**Scrum有5个迭代事件：**需求梳理会、迭代计划会、迭代评审会、迭代回顾会、每日站会。
**迭代计划会：**是迭代周期中开始阶段的一个会议。
**目的：**是为团队明确当前迭代的目标和范围，团队将用户故事拆解为工作任务，输出迭代计划。

![](//img1.jcloudcs.com/developer.jdcloud.com/416857b7-cebd-45a3-a434-a7c06782917920210113134327.png)

#### 二、迭代计划会的目标
迭代计划会的好坏，直接关系着迭代能否顺利进行。
迭代计划会需要**明确迭代目标、范围、如何完成及验收标准，团队达成共识****，对PO和业务做出承诺。**
高质量的计划会不仅仅细化了用户故事/MVP，也是一次小型规划过程，让团队共同思考业务架构和技术架构的可交付性。
#### 三、好的迭代计划会的特征
- 明确迭代要做哪些用户故事、用户故事的开始和完成时间
- 团队成员对需求的验收标准达成一致
- 根据团队交付速率做出合理承诺
- 好的计划会是经过共同估算充分讨论的

#### 四、迭代计划会怎么开
##### 1.会议要素
- **会议参与人（Who）：**SM、PO、Team（产品经理、开发、测试）、业务方（可选）
- **会议时间（When）：**一般是每个迭代开始的第一天，或上个迭代的最后一天
- **时间盒（Time Box）：**2周的sprint，一般2~4小时；4周的sprint，一般小于8小时

##### 2.迭代计划会流程
![](//img1.jcloudcs.com/developer.jdcloud.com/f1c4155f-3092-480e-82c1-fd9333530e8120210113134545.jpg)
##### 3. 会前准备
- PO输出产品待办列表
① 业务不能确定优先级，PO要做需求收口
② 需求依赖上下游系统，要对齐迭代版本，涉及特别多的系统的时候，要在迭代计划前多预留时间对齐此事儿
- 团队需要在需求梳理会上充分评审需求
- PO梳理需求时**需要注意**：
① 把需求按INVEST原则拆分成**闭环**的**用户故事**
② 拆分后的用户故事应小于**10个理想人天** 
③ 清晰的**优先级**顺序
④ 明确的**验收标准**
- 团队完成需求评审，PO将拆分后的用户故事分配至团队空间
- 必要时，团队需要在会前进行概要设计，可以为团队提供可靠的评估依据

**【备注】：INVEST原则：Idependent(独立的)、Negotiable(便于沟通的)、Valuable(有价值的)、Estimable(可估计的)、Small(短小)、Testable(可测试的)**

#### 4.会议流程
##### Step 1：公示迭代交付能力
- SM跟据团队历史迭代的交付数据，公示团队交付能力
- PO向团队说明本次迭代的目标

##### Step 2：澄清用户故事
- 产品经理围绕看板，澄清用户故事，按优先级每次只讲一个卡片
- 产品经理和团队讨论用户故事，达到统一的理解

##### Step 3：估算用户故事
**如果需求梳理会已经估算过用户故事，跳过Step3。**
- 团队共同对用户故事进行估算，将结果更新到卡片上（如工时估算，则更新个人任务；故事点估算则更新故事点点数）
- 产品经理对估算后颗粒度过大的用户故事进行重新调整和拆分
- 团队判断是否将当前卡片放入迭代
① 不符合需求就绪标准的卡片需要重新梳理需求
② 符合需求就绪标准的卡片加入到当前迭代

**重复Step 2 - Step 3，达到迭代交付能力则不再引入新的卡片**

##### Step 4：认领用户故事、创建个人任务
- 估算完成后，团队成员按优先级顺序以及团队约定认领用户故事
- 认领人在用户故事卡片内创建个人任务，包括开发和测试任务

##### Step 5：制定计划、检查计划合理性
- 制定任务计划时，成员要结合当前个人计划饱和度，来合理安排计划
- SM检查计划合理性，核对人力资源日历中的甘特图和人力资源饱和度
- 成员调整检查中发现的不合理项。更新行云卡片信息，包括：时间、人员、任务等

##### Step 6：调整迭代目标
- 跟据计划，团队向PO反馈可承诺的迭代目标和范围
- PO和团队充分讨论，确定最终迭代目标和范围

#### 5.风险管理
敏捷实施过程中，也伴随范围、进度、质量等方面的风险，需要持续、有效的管理。开展风险管理活动要结合敏捷风险的特点：
- 风险生命周期更短，允许团队识别、预防/处理的时间更加有限
- 一次迭代的规模较小、复杂度较低，风险的严重性和影响相对较小，风险容易管控。

##### 【范围风险管理】
敏捷迭代的目标和范围是固定的。在需求梳理阶段要做好优先级排序，输出清晰、准确的产品待办列表，需求梳理会上业务、产品、技术的干系人对需求价值和优先级达成一致，避免需求新增或优先级调整。

需求/产品方案要尽可能拆分，降低方案复杂度，团队共同讨论和确认，避免需求变更或蔓延。

范围变更风险应在迭代计划会开始前解除风险，否则不应进入本次迭代。若不能消除风险，与干系人协商一致，团队可以接受变更、调整迭代目标。

##### 【进度风险管理】
迭代计划的好坏，对进度有重大影响。迭代计划会上，团队过渡承诺、估算不准确、计划不合理往往会引发进度延期。

复杂的用户故事提前进行概要设计，以便合理评估。PO和SM共同保护团队，不强行倒排期，团队基于交付能力合理计划，尤其要保证关键路径、关键资源的合理性。

每日站会团队共同检查进度状况，及时纠正问题和风险。考虑到敏捷迭代周期短、团队人员固定的特点，增加资源或加班赶工等应对措施，团队要充分考量措施的有效性。

##### 【质量风险管理】
质量风险可以分为**研发质量风险**和**管理质量风险**。

**研发质量风险**来源于业务场景覆盖不全、产品方案缺漏、代码和测试质量不高等方面，这些风险在阶段性工作结束前很难识别，依赖下一阶段的验证和反馈。

敏捷工程中的单元测试、持续集成、自动化测试等实践，加快、缩短了开发和测试阶段的验证频率和周期，通过高效的质量控制策略来前置风险，减少最终交付阶段的质量问题。

**管理质量风险**来源于混乱或缺失的管理制度、模糊的管理职责。管理制度中应明确需求阶段、开发阶段、测试阶段的主要活动和流程，尽量前置管理活动，降低风险紧急度，保证管理过程的可控性。

#### 五、注意事项
##### 打造人人参与、高效的计划会
- 不要让计划会议变成PO或者SM的个人发言会
- 开发团队不需要在计划会议上考虑所有的研发细节，专注于需求细节，SM要进行引导，避免陷入马拉松式的会议状态
- 注意控制会议时长，避免团队成员无法集中精神
- 测试人员需要和团队一起进行估算，和开发一起启动测试工作

##### 充分讨论需求，进行合理拆解
- PO讲解用户故事和产品backlog的过程中，允许团队随时提问
- 如果一个用户故事过大（工时超过10理想人天），团队需要帮助PO对用户故事进行拆分
- 一个任务最大不超过3人天
- 把需求按INVEST原则拆分成闭环的用户故事

##### 做出合理承诺，及时输出结果
- 建议预留10%-30%工时来应对突发情况（根据团队情况来定）
- 迭代开始当天，团队成员将个人任务在行云内完成更新

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者：效能提升部 宋宁
![](//img1.jcloudcs.com/developer.jdcloud.com/bd689890-d5a6-4715-97a1-d343e0067b3620210113135540.png)