百木园
随着敏捷在各行各业的普及，一些基本问题又开始浮现：
- 迭代开始后，业务突然告诉开发团队一些迭代外的需求要优先发布，应该如何处理？
- 正在进行开发，产品经理突然要撤回一个需求，因为发生了变化，应该如何处理？
- 团队满负荷工作，突然出现一个紧急需求需要尽快发布，应该如何处理？
一、优雅地批评
问题反复出现，说明组织只触摸到了敏捷的“形式”，并没有理解敏捷的“实质”：在变化越来越快的环境中，提升团队响应变化的能力。
1. 响应变化的三种水平
开发同样的平台，顶级开发团队只需要普通开发团队百分之一的资源就足够了；同一个行业，有的人下午四点就离开客户现场回酒店睡觉了，有的人凌晨四点还在辛苦劳累。这就是响应水平的差异。
知识积累是一个缓慢的过程，本文从方法层面讲一讲在业务频繁变化情况下如何应对。
2. 前置思考
在开始之前我们先思考一下，业务对交付团队的期望究竟什么？高满意度究竟是什么？多快好省当然是绝对正确的答案，但和股市赚钱一个道理，赚一笔钱很容易，持续稳定地赚钱很难。与某个范围内的多快好省相比，可预见性强、稳定、可靠才是长期交付合作关系的保障，这也是敏捷倡导“长期关系”的原因。
二、理解迭代容量
实现对变化的应对与管理，一种敏捷方法是迭代（Iteration）。通过不断的迭代，使产品逐渐符合客户的需求；通过提高稳定性和可预见性，使迭代容量（Capacity）不断增加，从而提升产量，这是迭代管理的另一个目标，其核心概念是时间盒（Timeboxing）。
1. 时间盒控制
每个迭代是一个时间盒，经过多年的普及，很多人已经理解到时间盒是刚性的，不能随意调整周期。但许多团队只专注于如何控制迭代的周期，没有注意到时间盒是对任务完成具体时间（specific deadline）的约束。
可见，敏捷工作方法对人的基本素质有一定要求。对完成时间的紧迫度、在实现条件具备、环境干扰可控的情况下专注、高效地完成工作，是成为“敏捷型员工”的准入门槛。其次，才是管理者如何提供条件的问题。
三、案例：失败的控制
曾经负责改进一个面临巨大交付困难的团队。团队反馈需求太多，做不完，所以交付差，在第一个改进的迭代开始前，我们和产品负责人、开发负责人一起评估了需求量、交付资源，确保双方达成了一致。但在迭代开发过程中，把团队的提交记录导出来一看，晚上八点、十点、十二点直到凌晨二点，还有人在提交代码！
于是我们终于抓出了“实施敏捷后”交付效能越来越差的原因，如下图所示。
1. 工作方式差距
分析原因，我们发现团队还在延续过去的工作方式，无法跟上敏捷“快”的节奏：
- 缺少产品 Backlog 导致需求的能见度、预见性差。产品负责人按照过去版本火车的工作方式和节奏准备每个迭代的需求，与业务沟通频率低，在开发进入中后期才组织下一迭代的业务需求收集会，每个迭代前都需要反复澄清，挤压迭代开发周期，为避免开发空载，在迭代结束时团队不得不勉强接收需求，使进入迭代的需求质量良莠不齐。
- 需求质量影响开发质量。为了快，大部分版本火车中的质量活动（开发自测报告、版本提测报告、质量验证报告）都丢掉了，导致版本质量严重下滑。
- 强行迭代发布，每个迭代都产生大量的线上事故，不断累积修复工作量。
建立产品 Backlog 、形成每周一轮业务需求收集澄清的节奏、将线上事件数量纳入迭代工作项、通过全员的计划会议来评估工作量，几项改进完成后，可排期需求很快稳定积累三个月左右的量，供开发负责人更好地设计架构与模块，线上事件数量在稳定下降，测试缺陷数量也开始收敛。但与真正的敏捷工作方式相比，还缺少一些新的能力支撑。
从交付过程来看，当前的开发、测试团队仅涉及到了很少的工作，红色环节都由外部团队（BA、配置中心、集成验证）完成。比如一些紧急测试版本的发布，还要半夜给别的团队打电话申请支持。
2. 交付能力差距
如果我们将这个团队的工作扩大覆盖到交付全过程（从需求到验收），又需要克服哪些挑战呢？通过评估，团队当前的技能还不足以完成所有工作。以下评估结果是通过问卷调查的方式让团队自评再综合打分，比如自动化一项，调研的是测试人员对各类自动化工具的知晓、配置和项目中使用程度的自我评价。
从上图可以看到，要满足敏捷交付的要求，团队还需要扩展很多的能力项。
3. 改进成效
通过问题发现、原因分析、工作方式改进和能力校准，以及组织级的自动化平台工具引入，经过四个迭代的指导和数月的回访观察，该团队最终成为敏捷实施标杆，年底获得年度客户满意度评分第一名。
四、管理迭代容量
结合上面的案例，成功的迭代管理应包含三个必须步骤：
第一步，评估。对迭代内所有的工作项（workitems）进行透明，包括显性的交付工作项、隐性的事件处理及各个环节中的移交隐性工作（如环境配置更改、测试数据准备）。
第二步，规划。提高需求的可预见性。转为敏捷工作方式后，与客户和业务的沟通需要更频繁，形成滚动的需求收集与优先级调整，将变更尽可能控制在需求澄清阶段，对已澄清的需求进行条目化整理，录入 Backlog 。
第三步，计划。基于评估的结果，对规划产生的需求 Backlog ，基于其澄清质量、业务优先级挑选进入迭代的需求条目。
许多企业是从瀑布式、CMMI 转型敏捷。CMMI 起源于 NASA 系统工程方法，航天事件通常是重大事件，因此，CMMI 重视精确，不喜欢变化，通过需求基线来控制变化、事后回溯改进。而软件的重要特征是可修改性，且满足市场需求通常有一个从模糊到相对准确的过程，因此，敏捷倡导拥抱变化，但根据能力的不同，拥抱变化的结果会出现三种等级。
1. 负荷级
负荷级的特点是缺乏对迭代容量的理解和管理手段，对变化全盘接收。可能有些人会说，业务太强势，开发太弱势，没有谈判的余地。
实际上是因为开发团队缺乏管理能力，才没有谈判的资格，负荷级的开发团队、业务双向不满。
2. 应对级
吃尽苦头之后，团队终于意识到不能全盘接收业务的变化，开始采用“锁定期”强制业务、产品在迭代计划之前想清楚优先级和功能细节。这在一定程度上缓解了迭代内的干扰，但计划始终跟不上变化，一些需求最后还是要调整，甚至在很多时候出现问题需求先上线，下个迭代再调整的浪费。
在这个阶段，开发团队的迭代交付开始稳定，但业务满意度会持续下降。业务开始提问：敏捷方法解决了开发测试团队的问题，但没有解决我们的问题。敏捷有没有解决我们的问题的方法？
3. 管理级
具体的拥抱变化的方法并没有成文，而是来自实践经验的总结。回到文章顶部的问题，我们来讲一讲迭代内需求变更的处理的几点经验，主要是对迭代内需求条目的变更管理。
- 暂停：对已进入开发又发生优先级变更的需求，采取暂停措施，启动其它迭代内需求开发。
- 移除：对未进入开发又发生优先级变更的需求，将其退回到 Backlog ，填充文档、学习、分享及自动化类提高长期效率的任务。
- 替换：对需要进入当前迭代的需求，对等点数替换未进入开发的需求，保持迭代容量不变。
要做到管理级，需在需求质量、工程能力和团队学习能力上有较高的水平：
- 需求准入门槛要求：开发团队和产品/业务形成一致的需求质量标准，能够双向评估需求质量；
- 代码分支工作纪律：通过特性分支开发需求条目，每日同步主干变更并构建测试；
- 自我效率提升：主动性、有随时可用的团队改进任务项。
因此，实现敏捷是一个全面的组织能力治理的过程，敏捷对个人而言是一种成长，对组织而言也是一种市场筛选。
参考
- Try timeboxing: The goal-oriented time management strategy, Asanahttps://asana.com/resources/what-is-timeboxing
- Timeboxing, Clockifyhttps://clockify.me/timeboxing
- Timeboxing: Maximizing Your Productivity, MindToolhttps://www.mindtools.com/pages/article/timeboxing.htm
- The Ultimate Guide to Timeboxing, Calendarhttps://www.calendar.com/timeboxing/
给作者点赞，鼓励TA抓紧创作！
来源：https://www.woshipm.com/pd/5562360.html
本站部分图文来源于网络，如有侵权请联系删除。