敏捷人必看秘籍：为何你的团队估算总是不准确？

前言

我收到了许多关于估算和预测的咨询，人们常常向我咨询：“团队如何更有效地进行估算？我们的预测一直不准确！”，“可预测性一直是我们的主要挑战！”，还有“有没有更好的工具可以帮助我们在敏捷项目或计划中做出实际可行的预测？”等等。为了避免大家过多讨论“交付价值大于关注结果”的问题，我们假设这方面已经得到解决，并且我们已经收到了许多经过价值验证的、能够满足客户需求的反馈。

问题到底是什么？

当我问他们“问题到底是什么”，他们给出了各种场景：我们有多个团队共同完成计划，但每个团队似乎总有人无法全身投入。

一个团队负责后端任务，另一个团队负责前端任务。UX设计师在估算中不包含，因为设计工作被视为已提前完成，然而经常需要重新调整；一些成员只能投入部分精力；团队会因为生产问题或一些别的职责而被迫反复中断当前的工作；估算建立在全职投入的假设上，但实际上团队同时进行多个计划；因新工作项的高优先级取代旧计划，团队要求重新估算（显然，先前的估算已完全失效，但通常被忽视）；团队不稳定，成员常常离开或外包人员完全离开项目；为显示进展，团队在Sprint中不得不执行任务或故事，以应对依赖项，而不是首先解决依赖项；团队开展全新计划，没有相关经验；架构思路或任务未明确，难以进行估算；团队基于反馈变更工作，但管理层要求遵循初始预测；为满足管理层设定的截止日期，团队牺牲了代码质量，有时甚至在代码混乱的情况下继续工作，因为技术债没有在估算中考虑；更严重的是，在某些情况下，管理层追求掌控感和可预测性，不愿重新配置或创建专注、自治或基于特定目标的团队，因为这可能影响现有团队的工作速率（这引发疑问，为何个别团队的速率比向客户交付价值更重要？）。

估算并不是承诺

请记住，估算并不是承诺，而预测也不是计划。请记住，估算并不是承诺，而预测也不是计划。有些人应该很清楚我们并不需要进行传统估算（请参阅Linkedin #noestimates主题标签）。但我想指出的是，即使仅仅去度量故事吞吐量或故事数量，如果你不知道在特定时间范围内要处理100个故事中的哪一个，也会遇到同样的问题。所以，如果存在上述问题，我们应该如何创造一个能够让团队成功的环境，以让我们的估算和预测（无论好坏）都能够产生实际的作用？

为何敏捷会有效,以及如何改进

无论如何，如果您决定继续进行估算实践，并假设仍然认为这种做法很有价值，并且估算确实是建立在假设人们理解以敏捷方式工作的价值的基础上的话，可以考虑如下改进：

1.将故事或任务拆分得比较小但可度量，可测试，且能完成和展示一些实际进展（这大大降低了以后发现所做的事情不起作用的风险）；

2.一个相互协作的跨职能团队，并且由团队整体为成果负责，而不是一群独立工作并不考虑如何与他人互动的人；

3.一个能够在某个时间范围结束时交付一些可用的东西的团队，或者能够可靠地度量吞吐量和时间周期的团队；

4.一个能够及时提出遇到的障碍并使其得到及时解决的团队（举个可能的例子，比如有个环境无法使用，而团队自己没办法搞定这个问题）；

5.能够根据实时进度，和一些可能会改变预测的反馈去进行检查和调整；

6.人们能够全职投入在团队工作中…如果做不到全职，至少能够保证工作上也不会造成太多瓶颈；

7.人们能够最大程度地减少在制品数量；

8.自动化测试和单元测试必不可少，还有类生产环境以及定期部署的能力；

9.假设团队具有积极性，主动性，想要做正确的事，并且要相信他们能够在不受任何微观管理的情况下完成工作。

因此，想要任何与故事估点或拆分等相关的预测和其他现有的团队问题能够得到解决，我们必须先要专注于解决手头上更大的问题……通常指的是组织层面缺乏对能够使敏捷起作用的原则的理解。问题通常是组织层面对这些能够使敏捷起作用的原则理解不足很显然，没有工具可以“解决”这个 “我们的工作方式”的问题。当我们解决了这个问题，做预测自然就会轻松得多。

从人员组织的角度来看，敏捷解决了许多计划驱动型工作并未考虑的问题–人不是机器，上下文切换，负担过重，以及被指派去完成那些不了解整体目标或愿景的任务，都会产生极大的损耗。这些事情也相应影响了预测和预报工作。

敏捷能够解决这些问题，并且创造了人们乐于上班的环境，某种程度上是因为人们可以对结果负责，取得成果，交付给客户想要的东西并为组织的使命做出贡献。