编辑导语：随着“敏捷”的出现，迭代开发解决了一些问题，但我们只是用到了其“形式”，还未理解到其“实质”。本文就如何理解并管理迭代容量，以期提高变化响应能力展开分析，希望对你有所帮助。
随着敏捷在各行各业的普及，一些基本问题又开始浮现：
问题反复出现，说明组织只触摸到了敏捷的“形式”，并没有理解敏捷的“实质”：在变化越来越快的环境中，提升团队响应变化的能力。
开发同样的平台，顶级开发团队只需要普通开发团队百分之一的资源就足够了；同一个行业，有的人下午四点就离开客户现场回酒店睡觉了，有的人凌晨四点还在辛苦劳累。这就是响应水平的差异。
小知识：基于不同的专业积累与做事方式，产出有数十、数百倍的差距。
知识积累是一个缓慢的过程，本文从方法层面讲一讲在业务频繁变化情况下如何应对。
在开始之前我们先思考一下，业务对交付团队的期望究竟什么？高满意度究竟是什么？多快好省当然是绝对正确的答案，但和股市赚钱一个道理，赚一笔钱很容易，持续稳定地赚钱很难。与某个范围内的多快好省相比，可预见性强、稳定、可靠才是长期交付合作关系的保障，这也是敏捷倡导“长期关系”的原因。
小知识：每个月产量稳定提升 5% 的团队，一年的产量就能提升 60% ！
实现对变化的应对与管理，一种敏捷方法是迭代（Iteration）。通过不断的迭代，使产品逐渐符合客户的需求；通过提高稳定性和可预见性，使迭代容量（Capacity）不断增加，从而提升产量，这是迭代管理的另一个目标，其核心概念是时间盒（Timeboxing）。
每个迭代是一个时间盒，经过多年的普及，很多人已经理解到时间盒是刚性的，不能随意调整周期。但许多团队只专注于如何控制迭代的周期，没有注意到时间盒是对任务完成具体时间（specific deadline）的约束。
Timeboxing is a goal-oriented time management strategy to help you increase productivity and reduce procrastination. When you create a “timebox,” you’re setting a goal to finish a particular task within a certain time frame.[1]
Timeboxing is a simple time management technique that involves allotting a fixed, maximum unit of time for an activity in advance, and then complete the activity within that time frame.[2]
The purpose of timeboxing is to ensure that you use your time productively.[3]
Timeboxing is a time management technique that involves setting fixed amounts of time for tasks to be completed.[4]
可见，敏捷工作方法对人的基本素质有一定要求。对完成时间的紧迫度、在实现条件具备、环境干扰可控的情况下专注、高效地完成工作，是成为“敏捷型员工”的准入门槛。其次，才是管理者如何提供条件的问题。
曾经负责改进一个面临巨大交付困难的团队。团队反馈需求太多，做不完，所以交付差，在第一个改进的迭代开始前，我们和产品负责人、开发负责人一起评估了需求量、交付资源，确保双方达成了一致。但在迭代开发过程中，把团队的提交记录导出来一看，晚上八点、十点、十二点直到凌晨二点，还有人在提交代码！
团队反馈凌晨工作的人是在处理线上事件。
于是我们终于抓出了“实施敏捷后”交付效能越来越差的原因，如下图所示。
分析原因，我们发现团队还在延续过去的工作方式，无法跟上敏捷“快”的节奏：
建立产品 Backlog 、形成每周一轮业务需求收集澄清的节奏、将线上事件数量纳入迭代工作项、通过全员的计划会议来评估工作量，几项改进完成后，可排期需求很快稳定积累三个月左右的量，供开发负责人更好地设计架构与模块，线上事件数量在稳定下降，测试缺陷数量也开始收敛。但与真正的敏捷工作方式相比，还缺少一些新的能力支撑。
从交付过程来看，当前的开发、测试团队仅涉及到了很少的工作，红色环节都由外部团队（BA、配置中心、集成验证）完成。比如一些紧急测试版本的发布，还要半夜给别的团队打电话申请支持。
小知识：敏捷倡导的“团队自治”，不是表面理解的“决策自主”，而是交付过程尽可能降低外部依赖，包括决策的依赖、业务的依赖、技术的依赖，等等……
如果我们将这个团队的工作扩大覆盖到交付全过程（从需求到验收），又需要克服哪些挑战呢？通过评估，团队当前的技能还不足以完成所有工作。以下评估结果是通过问卷调查的方式让团队自评再综合打分，比如自动化一项，调研的是测试人员对各类自动化工具的知晓、配置和项目中使用程度的自我评价。
从上图可以看到，要满足敏捷交付的要求，团队还需要扩展很多的能力项。
通过问题发现、原因分析、工作方式改进和能力校准，以及组织级的自动化平台工具引入，经过四个迭代的指导和数月的回访观察，该团队最终成为敏捷实施标杆，年底获得年度客户满意度评分第一名。
结合上面的案例，成功的迭代管理应包含三个必须步骤：
第一步，评估。对迭代内所有的工作项（workitems）进行透明，包括显性的交付工作项、隐性的事件处理及各个环节中的移交隐性工作（如环境配置更改、测试数据准备）。
第二步，规划。提高需求的可预见性。转为敏捷工作方式后，与客户和业务的沟通需要更频繁，形成滚动的需求收集与优先级调整，将变更尽可能控制在需求澄清阶段，对已澄清的需求进行条目化整理，录入 Backlog 。
第三步，计划。基于评估的结果，对规划产生的需求 Backlog ，基于其澄清质量、业务优先级挑选进入迭代的需求条目。
许多企业是从瀑布式、CMMI 转型敏捷。CMMI 起源于 NASA 系统工程方法，航天事件通常是重大事件，因此，CMMI 重视精确，不喜欢变化，通过需求基线来控制变化、事后回溯改进。而软件的重要特征是可修改性，且满足市场需求通常有一个从模糊到相对准确的过程，因此，敏捷倡导拥抱变化，但根据能力的不同，拥抱变化的结果会出现三种等级。
负荷级的特点是缺乏对迭代容量的理解和管理手段，对变化全盘接收。可能有些人会说，业务太强势，开发太弱势，没有谈判的余地。
谈判的目的是协调，协调的目的是寻找共赢范围，寻找共赢范围的前提是陈清利害关系，陈清利害关系的前提是有事实和数据支撑，这正是管理的基本动作。
实际上是因为开发团队缺乏管理能力，才没有谈判的资格，负荷级的开发团队、业务双向不满。
吃尽苦头之后，团队终于意识到不能全盘接收业务的变化，开始采用“锁定期”强制业务、产品在迭代计划之前想清楚优先级和功能细节。这在一定程度上缓解了迭代内的干扰，但计划始终跟不上变化，一些需求最后还是要调整，甚至在很多时候出现问题需求先上线，下个迭代再调整的浪费。
在这个阶段，开发团队的迭代交付开始稳定，但业务满意度会持续下降。业务开始提问：敏捷方法解决了开发测试团队的问题，但没有解决我们的问题。敏捷有没有解决我们的问题的方法？
具体的拥抱变化的方法并没有成文，而是来自实践经验的总结。回到文章顶部的问题，我们来讲一讲迭代内需求变更的处理的几点经验，主要是对迭代内需求条目的变更管理。
要做到管理级，需在需求质量、工程能力和团队学习能力上有较高的水平：
因此，实现敏捷是一个全面的组织能力治理的过程，敏捷对个人而言是一种成长，对组织而言也是一种市场筛选。
陈加兴，微信公众号：加兴曰，人人都是产品经理专栏作家。陈加兴，场量科技创始人，研究领域：研发组织效能、数字平台、SaaS创业战略。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。