范围蔓延贯穿于每个软件开发项目。它可能发生在任何个人和团队身上，就像其他敏捷实践一样，没有两个团队完全以相同的方式管理范围蔓延。了解如何识别范围蔓延，它对工作的影响以及如何处理它，是避免无益范围蔓延的关键之一。
什么是范围蔓延？
范围蔓延是指在项目进行过程中，项目超出了最初的目标（即在原始的迭代、史诗或发布计划中增加了新的工作）。范围蔓延可能出现的原因包括：
- 市场条件发生变化，需要不同的功能集
- 用户反馈表明某个功能需要以不同的方式工作
- 随着团队工作的展开，实施过程中出现复杂问题或意外的依赖关系
- 对原始项目范围的了解不充分导致项目范围持续扩大（这应该听起来非常熟悉）
如果范围蔓延没有得到妥善管理和透明处理，它可能会使任何团队陷入困境，而我们的团队也不例外。我们直接深入了解我们的两个团队如何应对这种威胁，采访了敏捷团队和开发负责人。尽管这些团队经常一起工作，但我们惊讶地发现他们对于如何管理范围蔓延有着不同的做法。
如何识别范围蔓延？
范围蔓延很少会突然出现，尽早识别它是关键。为什么？因为它可能会导致功能延迟发布，甚至更糟的是，可能会引入不必要的代码和软件风险。
开发经理表示，在一个迭代周期中，团队通常会使用看板、小工具和燃尽图来可视化他们的工作。他在团队周围的电视上设置了看板，并将小部件放在最显眼的位置。小部件显示了对状态/列进行简单求和（估计）分组的栏。他将小部件设置成一个简化视图，以显示进度条以及过去的时间和已完成的范围。这意味着在迭代周期中，经理和整个团队都可以看到范围变化。
开发经理还建议在仪表板上设置敏捷迭代燃尽小工具。对于不熟悉的人来说，燃尽图描绘了在迭代周期中实际完成的工作量与预计完成的工作量之间的对比。这个图表帮助开发经理看到他的团队在迭代过程中如何交付工作，以及达到迭代目标的可能性。当燃尽图不遵循指导方针时，强烈表明有些事情出了问题，范围蔓延可能就是罪魁祸首。由于所有报告都显示实时数据，开发经理无需进行大量挖掘分析就能够看到图表或百分比变化。
对于团队来说，识别范围蔓延依赖于范围变化的类型。团队负责人表示，真正的范围蔓延——（产品负责人说“在完成 X、Y 和 Z 之前不要发布”）是最直接的类型，也是最容易识别的。他创建故事，团队对这些故事进行估算以查看影响。另一方面，由未预见的变量引起的范围蔓延——例如，API发生了变化，或者功能需要适应不同的页面布局——是通过早期和持续的整合发现的。
由于团队需要依赖于其他团队，开发经理还使用“Scrum-Of-Scrum”会议——多个Scrum团队在一个大项目上进行工作的站立会议——来识别范围变化。Scrum-of-Scrums为知识共享开启了大门，并尽早暴露了例如范围蔓延这样的重要问题。
如何管理范围蔓延的影响
借助报告这样的工具，很容易看出范围蔓延何时在工作进度中出现。而管理范围蔓延的影响则更加复杂。正如开发经理所描述的那样，处理范围蔓延不仅仅是为了减轻影响，更是为了理解。
范围变化可能以多种方式表现，但在任何情况下，团队负责人在范围增加之前或之后都应与产品经理进行沟通。正如开发经理所说，团队负责人最关心的是在一个迭代中“我们承诺了多少并完成了多少”。因此，当添加新的需求时，特别是优先级较高的需求，会在下一个站立会议上向团队提出。当范围发生变化时，团队成员之间应该及早进行沟通，讨论范围变化带来的影响。这种沟通可以涉及对工作量的估算和新增工作的讨论。
另一方面，开发经理对以下问题感兴趣：范围变化会对团队的交付时间产生什么影响，因此他进行“假设情景”规划。确保他团队的所有数据都有汇总，这样他就可以对潜在结果进行建模，并了解范围变化对队的路线图的影响。
这种情景规划通常是由团队的产品经理一起完成的。他们可以调整发布日期、范围和资源（即人员）等变量，开发经理称之为“杠杆游戏”。他们进行不同的调整和折中，直到找到适当的平衡点或妥协方案。当发生范围蔓延时，重要的是要考虑到所有选项，以便做出数据驱动的决策。
如何应对范围蔓延
一旦有了范围变化，并且你理解了变化的原因，就需要做出决策。你是否接受范围变化并延迟发布？是否获取更多资源？是否削减一些最初的需求？团队该怎么办呢？
我们的团队使用图表来查看项目的整体情况，以管理范围蔓延。图表显示团队完成一个史诗的进度，按迭代进行划分。它还显示了在完成史诗之前还有多少个迭代的工作预测。在范围蔓延的背景下，该图表突出显示了工作的增加量和时间。一个团队可能最初计划在10个迭代中完成一个史诗，但是在进行了6个迭代之后，图表可能显示剩余工作量还需要另外6个迭代。
另一个团队对燃尽图的依赖较少，更多地是进行假设情景规划，因为“模拟游戏”可以全面了解范围变化的潜在选项和影响。尽管的假设情景和的燃尽图提供了决策所需的数据，但需要团队采取行动并做出艰难的决策。
基于精益敏捷原则，团队可能会一致同意尽快推出最新功能，因此就新的最小可行产品（MVP）达成一致。这样，与团队向该史诗添加更多迭代相比，新功能就能更快地交付给客户。这样的权衡意味着该功能或版本不会像团队在项目开始时所期望的那样进行交付。但没关系，灵活调整正是敏捷的要义。
一旦做出决策，团队负责人可以重新排序待办事项（故事、史诗或计划）。新的待办事项会根据新的发布时间自动更新路线图。使用实时数据可以实现重新安排工作量，而不会导致周末也需要加班。
如何沟通范围蔓延的影响
一旦做出决策，确保所有人都了解变化的影响是处理范围蔓延时的最后一步。增加范围可能会损害团队的士气，因为从表面上看，团队可能没有完成他们计划完成的工作。因此，整个团队都需要理解为什么会增加范围以及范围蔓延对迭代、史诗、发布和项目未来有何影响。
对于团队来说，关于增加范围的讨论发生在团队负责人和产品经理之间，同时，开发经理通过报告密切关注进行中的工作。范围蔓延也是团队回顾会议讨论的重要议题。这些会议让所有人都参与其中，以理解做出的决策，或者新的计划（如果有的话），并了解下一个迭代中预期的情况。团队的每个人都会尽早、尽可能频繁地了解范围变化的情况。
开发经理发现可以更自由地传达范围变化的影响，因为估算是基于数据的，而不是凭空估算。他了解所有可用的选项，这是与利益相关者进行开放交流的好方法。此外，团队的路线图对整个团队都是可访问的，因此每个人都可以在可交付成果和发布日期方面保持一致。
延伸阅读：国内外主流项目管理软件
1.国产研发项目管理工具榜单前二（36Kr发布）：PingCode 【官网：https://datayi.cn/w/z98mjJdR】
2.国外项目管理工具市场占有率非常高：Atassian（如今已经对国内用户停售本地版，政策详情可通过以下文章了解： Jira最新政策及与国内工具大对比 ： https://docs.pingcode.com/blog/tool/16840.html ）
3.国内通用项目协作工具市场占有率非常高：Worktile【官网： https://datayi.cn/w/korbgXZo 】
4.国外最佳易用项目管理工具：Trello 【官网：Trello.com】
5.最佳开源项目管理软件：Redmine 【官网： https://www.redmine.org/ 】
6.最佳个人项目管理软件：Teambition（对个人永久免费）【官网：Teambition.com】
以上工具，以及更多工具的对比测评可以通过以下文章了解：2023年排名前十的项目管理软件大盘点： https://docs.pingcode.com/blog/tool/16767.html
