Scrum是一个高效、有质量的迭代。

能够高效、有质量地交付每一个迭代计划的目标，是一个敏捷团队成熟的标志。

如何管理好迭代容量是迭代成功的关键，也是一个难题！

敏捷、Scrum如何快速适应变化

Scrum框架适应需求变化的要点：

1. 动态、基于优先排序的产品代办清单（无传统变更管理流程）
2. 短迭代计划，小步快跑，延迟承诺

敏捷迭代管理中常遇到的典型问题

新团队不知道迭代排多少故事合适？

1、集体估点，按业界参考公式计算粗略迭代容量（人数含开发与测试）

注意：随着迭代的持续运作，经过一段时间的积累按实际的平均的团队速率来排迭代容量。

问题二：迭代中需求持续超载，团队不可持续，难以保证质量?

迭代管理技巧：

1. 基于之前的容量预估方法，或参考历史迭代速率（近期几个迭代的平均速率），量化团队平均容量，基于真实容量制定迭代计划。
2. PO、DM与业务方或领导沟通，将代办清单中所有工作项统一排优先级，基于团队容量先聚焦真正高优先级需求制定计划，而额外的期望定位挑战目标，不承诺。
3. 与DM合作进行，将大需求拆小，拆分后先交付满足业务处理必须的最基本功能，尽量将其中非必须的、低优先级的部分延后交付——敏捷需求拆分和渐进拆分的精髓。
4. 与业务、领导加强沟通，信息对业务透明，消除业务和领导的进度焦虑感；

• 与业务一起，持续滚动进行产品规划，让业务看到想要的功能何时能交付。
  

• 将产品规划、后续需求清单与每迭代计划及工作量向业务透明
  

5. 不要完全暴露给业务方团队容量上限，有所保留，团队需要一些容量来弹性处理范围大小、关注质量和进行技术改造（比如团队加班加点也许可以完成50个点，那么给业务只暴露35点的容量，不轻易超过）
6. 团队人员稳定，基于优先级，以容量安排工作，而不是以工作临时安排人力

问题三：迭代中很多必须临时响应的事项占用人力？计划执行不顺

迭代管理技巧：

1. 根据产品当前阶段，PO与DM一起判断当前阶段每个迭代临时性事项所占投入比重。

   可能的临时性事项包括：

   •生产事故、问题（新产品刚上线，或产品质量较差的情况下这类多）

   •支持其他团队的非开发工作（团队间分工不清，或系统间耦合性高时这类多）

2. 团队在进行迭代计划时，为可能的临时性、需要立即响应的问题或任务预留人力（如预留15%），迭代计划中承诺交付的故事点少一些

3. 当接到生产问题，PO和DM应分析其紧迫性，影响不大的非紧急问题且需要修改代码的，作为用户故事放进产品待办清单统一排优先级，在后续迭代处理（其他的立即响应）

4. 在看板上，建立单独泳道、或单独的价值流来管理非计划内工作，也必须将责任人、进度和问题、风险可视化出来管理

5. 对于规模化的大产品，多个敏捷团队，可以考虑成立运营支持小组，统一处理所有生产事件，只有需要程序修改代码的问题才到开发团队解决，减少临时工作对团队的影响6. 优化分工，减少跨团队共享资源，专职到团队。

问题四：业务或领导在迭代进行中临时加需求，提出需求变更

迭代管理技巧：

1. 首先PO\DM要能够不断地（或借助教练、顾问）向业务和管理者传递迭代内需求稳定对效率、质量的重要性；敏捷的拥抱变化不等于随时加需求，而是通过短迭代和动态优先级排序

2. 迭代越短对变化响应越快，若需求变化过于频繁，考虑缩短迭代周期（如一周一迭代）或流动式交付（前提是DevOps能力够成熟）

3. 对于业务或领导临时要加入的需求，PO\DM按如下处理：

   • 首先与相关干系人讨论变更的实际紧迫性（除了解决严重生产事故，或快到Deadline的国家政策，很少有变更真正等不了2星期！- 若等不了，说明版本规划有问题）

   •将变更或新需求定义为故事卡，让相关干系人将其与其他已计划故事排优先级。若变更故事没有已计划故事的优先级高，放后续迭代处理

   •若变更的优先级确实很高，DM或团队评估其点数，可从当前迭代计划中将点数相当的一个或几个最低优先级故事拿出去（即故事置换）

4. 根本解决办法：PO、DM与业务、领导合作滚动做好产品规划（从大的里程碑到细的近期迭代计划），聚焦产品目标和价值，合理规划需求优先级

问题五：如何解决团队间依赖影响迭代计划按时完成？

敏捷团队依赖管理技巧：

1. 建立特性团队（对端到端完整需求、特性交付负责），而不是组件团队（对某一个子系统、模块负责），减少同一份需求多团队交付的情况，降低团队间依赖；但要求有较成熟的分支管理和持续集成能力
2. 同一个领域/大产品内紧密相关的多团队，建立统一节奏的产品规划（如采用用户故事地图），在领域或大产品层面拉通关联需求排期，协调优先级
3. 同一个领域内多个关联团队Scrum迭代周期对齐，同时开始、同时结束，便与沟通需求和排期，领域内召开SoS会议。
4. 不同团队负责的系统在架构上解耦，拆分服务和数据库，弱依赖，开发测试可以独立进行
5. 不同团队负责的系统之间接口做多版本接口兼容，提供新版接口，保留老版本接口（推动消费方升级，老版本接口无人调了再去掉），上线发布可以各自独立
6. 涉及外部依赖，且联调时间不确定，原则上将可控部分与不可控部分分离！即将团队内可控开发和测试的部分定义一个故事，将外部联调部分拆分出一个技术故事，分别跟踪；前者迭代内完成，后者可能等待或延续几个迭代

问题六：如何拒绝“不合理”需求？

首先，你认为不合理，而领导/业务认为合理，谁说了算？

你很难拒绝领导/提出的你认为不合理的需求，除非PO和团队能够：

1. 主动探索并主导设计，形成需求，而不是等待接受他人提出的需求
2. 主动地，透明地做好产品规划，将领导的关注点引导到你认为合理的需求和优先级排序上去（尤其是避免提出需求的交付时间，优先级不合理）
3. 比提出需求的人更专业，有更丰富的领域知识，能够讲出说明力的理由，超出领导的认知
4. 理解真正领导想解决的问题，并提出更好、更合理的解决方案
5. 以客观的用户行为，用户反馈数据和运营数据说话，以此证明需求的价值低，或设计方案不合理。

阅读更多[敏捷知识]、[敏捷转型经验]、实践等…欢迎关注@敏捷_鲸舟
如果对我们的产品感兴趣，可以逛逛我们的官方网站鲸舟研发管理平台 试用了解