在 Softeq， 我们有很多有想法的人让团队合作变得非常敏捷。最近，我们与我们的交付经理、经过认证的 Scrum 专家 Nadezhda Svirnovskaya 进行了交谈。以下是她关于如何使平均速度概念成为敏捷团队强大工具的见解的总结。
为了说明我们的论点，让我们想象几个角色在一个典型的工作环境中表演。我们有一个项目经理，他的任务是让客户满意。然后我们有一个很酷的部门经理来处理所有资源，还有一个需要特定解决方案的客户。最后，肯定有一个聪明的提供建议的人，他坚信自己有能力拯救地球。让我们开始吧！
任何 PM 的主要目标都是交付一个项目，无论它是什么。然而，正如聪明人所说，项目不同。万一是时间和材料，你只是一个幸运的人：什么都不用担心，因为公司只是从提供的资源中得到钱。不幸的是，这种情况很少发生，因为任何客户都希望完全了解他/她将要支付的费用以及他/她何时会得到它。
假设我们运气不好。固定范围和时间或铁三角内的固定价格项目就是这种情况——这就是项目管理占据中心位置的地方。但在我们着手在时间、范围和成本的三重约束三角形内执行项目之前，我们应该首先将项目出售给客户。那么，如何在固定范围和时间下与客户达成协议呢？
项目范围：非常规对待
让我们应用平均速度概念。将范围解释为不仅仅是我们要满足的一组需求，而是一定数量的故事点，并获得关于平均速度的信息，我们将很容易估计发布日期。或者，通过分析平均速度和发布日期输入，我们定义范围。
第 一个 选项
- 输入： 平均速度，发布日期
- 输出： 项目范围
第二 个 选项
- 输入： 平均速度、项目范围
- 输出： 发布日期
通过简单的计算，加上非生产性费用等，最终达成一致。听起来不像是常见情况。那有什么问题呢？
估计速度：成功被拒绝？
如果我们没有关于平均速度的任何信息怎么办？让我们看看问题出在哪里。实际上，您可能需要处理很多原因，例如以下原因：
- 一个全新的团队
- 一个有新人的团队
- 新的领域或技术
- 一个新的产品负责人
无论如何，您不能依赖统计数据。这就是我们的聪明人说的：“嘿，孩子们，我会帮你的。我们只需进行一些计算，仅此而已”。在这里，我们开始进行预测，按照快速步骤列表得出平均速度：
-
按故事点值评估积压
-
通过冲刺确定团队的平均能力
-
开始模拟计划会议以获得符合前一阶段定义的容量的小时估计
-
计算平均冲刺速度
我们可以把它想象成下面这样：
似乎是我们出售项目的地方。事实上，除非我们仔细考虑这种规划模型确实有效的情况。理想的规划环境意味着以下几点：
- 你有积压
- 积压估计由您的团队完成
- 模拟计划会议由您的团队执行
- 零冲刺和稳定冲刺都被考虑在内
- 您使用实际容量，并考虑休假和节假日（如果有）、可能的病假、喝咖啡/抽烟的时间等。
以下是典型容量评估计划的示例：
|
技术负责人 |
4个小时 |
|
中期开发 |
6个小时 |
|
质检主管 |
4个小时 |
|
中期质检 |
6个小时 |
|
建筑师 |
4个小时 |
|
学士 |
不算 |
尽管如此，在这个阶段走到尽头的项目很少，因为一个经常出现的问题仍然是缺乏一个既定的团队本身。
“假设计师”：组建虚拟团队和模拟冲刺执行
在一个需要大约 120 名专家的资源库的大型项目中，找到这么多人在替补席上等待很可能是一个问题。我们聪明的建议人怎么想？哦，这就是他说的地方：“看，我已经受够了。你自己解决好不好？”
在需要 80 到 120 人的项目中，我们需要特定数量的相同规模的团队。这里最合适的解决方案是采取以下步骤：
- 组建虚拟团队
- 考虑那些受雇于其他项目但具备一套必要技能的人，并为您的项目借用他们以进行估算
- 设置增量
似乎就在我们解决所有问题的那一刻，我们就准备出售该项目。现在是时候了，当我们真正开始管理流程时，努力保持在项目三角约束范围内并让我们的客户满意。
观察速度，利用优势
速度管理再次在舞台上提供了极大的帮助。为什么？在定义项目成功的决定因素时，我们应该承认，以下几点在一开始就取得了很大进展：
- 正确的速度评估
- 影响速度的因素的正确定义
牢记这一点，PM 应该注意关注以下活动：
- 跟踪速度变化
- 发现速度变化的原因和来源
- 管理速度
拆分冲刺：交钥匙资源
为了说明上述指令的使用，让我们从实践中考虑以下示例。我们正在与一支速度稳定的敬业团队合作开展一个很酷的项目。但在某一时刻，我们的部门经理问道：“嘿，帮我借给彼得。我给你约翰——他太棒了，你永远不会后悔”。似乎无法拒绝，不是吗？交换被接受，接下来会发生什么？
John 加入了团队，因此需要时间来了解事情的进展。结果，我们失去了速度。
如果你没有同意交换……你应该说没有人可以取代彼得，向部门经理提供计算证明，你肯定会跟上要求的速度。
另一种情况：产品负责人提出在下一个冲刺期间聘用 CTI。好吧，这似乎是有可能的，因为你已经让 Peter 具备了所需的技能，无论他是否在度假。为了不让客户感到不安，您承担了 CTI 的风险——沉没或游泳。
所以，冲刺开始了。团队的行动是什么？他们都开始谷歌搜索，进行研究，在 CTI 的斗争中分心。很自然地，在冲刺结束时，他们不仅在 CTI 上失败了，而且在所有任务上也失败了。
这里的结论是，有许多因素您通常无法避免，但必须考虑在内。下次在短期规划时，你最好建议 CTI 应该在第 4 个 sprint 内实施，当 Peter 休假回来的时候。
如何考虑每一个速度滞后的情况？就像我们下面做的那样想象它，并开始定期收集统计数据。
将美味佳肴带到餐桌上
在我们的实践中，除了收集速度统计数据外，我们还系统地收集有关影响速度的因素的数据，并将其全部归结为所谓的“偏差列表”。它确实有效，尤其是在雇用多个团队的长期项目中。
我们如何使用它？嗯，这很简单，真的。在计划一个项目时，我们会参考“偏差列表”来做出几种不同的估计：乐观预测、悲观预测和最有可能的预测。然后，在制定风险管理计划时，我们将能够根据已有的统计数据考虑所有风险。这是它的样子：
最后，我们也将“偏差列表”用于短期任务。比如说，如果我们失去速度，该文件有助于找出所有可能给我们带来必要增长的因素。例如，如果我们发现与没有修饰的冲刺相比，每周修饰平均可将速度提高 3-5 个故事点，我们可以选择并使用这一点。