敏捷实施中的估算与实际效果 - Ottinger

“不好了！我们估计该冲刺有23个故事点，但我们只交了20个故事点。我们使冲刺失败了！”
似乎很多团队，尤其是Scrum和SAFe团队，都花费大量时间进行故事点估计。这是可以理解的，也令人失望。
您会看到，您无法估算有哪些预测性的方法。
有时，我们的期望和实际发生的情况并不相同。我们可以感到失望，羞耻或沮丧。当我们设定目标以及制定这些目标的计划时，尤其如此。这些计划是专门为要遵循的计划而制定的，如果发生任何不按计划进行的事情，都可能使我们的目标面临风险。
计划是对我们期望如何实现某些交付目标的表述。它包括我们打算做的事情，我们将在每个项目上花费多长时间以及我们打算如何解决预见的障碍。
对于项目来说，这似乎是一个合理的定义。
 
欢迎变更需求
在瀑布项目的更加静态的世界中，一个项目始于最终目标。一个人确定“系统”完成后应该是什么样的。考虑到这种经过精心设计，经过仔细研究的最终状态，人们将进行仔细的功能分解，并为各个部分分配时间估计。他们会合在一起完成整个过程。如果对各部分进行了适当的描述，它们可以由并行工作的不同人员来构建。为了保持精妙的计划到位，项目将具有“变更管理小组”。毕竟，如果有任何一件事情花费的时间比预期的要长，那么延迟或错误可能会蔓延开来，使整个项目晚了。当所有零件完成并装配在一起时，最终的图片有望出现，美丽而完整。
尽管使这种方法是可行的，但它不适用于产品开发；这是专门为合同程序设计项目开发的一个过程。
我有一个朋友，他在一家公司中担任董事职务，该公司开发软件来提供服务。几年前，他们拒绝为端点API设计（即使同意端点可能很棒），而是逐步交付API。他们从客户那里学习了使用该功能的早期版本，并更改​​了其愿景以适应客户的实际需求。如果它们已实施端点API设计，则该功能可能无法提供所需的效果，它开辟了新的收入机会。
在产品环境中，产品概念正在不断修订。我们应该交付的内容可能与我们最初计划交付的内容有很大差异。仅此一项就丧失了瀑布过程的资格。
也就是说，让我们检查基于产品的世界中的估算和计划。
 
分解估算
关键问题之一是功能分解仅考虑将功能构建到现有产品中的实际成本的一小部分。
尽管存在更好的方法，但有些团队估计故事点的努力/持续时间。故事要点是XP的一项发明，已移植到Scrum和其他方法中。这样做的想法是从几小时和几天的时间中抽象出来，因为人们可以做出比绝对评估更为准确的相对评估（将一项工作与另一项工作进行比较）。
这种理论似乎已经足够好，并且在过去不存在报告更高或更低数字的压力的情况下，已经为团队所用。
这就是为什么不建议将故事点“标准化”为几天或几小时的原因。故事要点的全部要点是抽象出实际的时钟和日历时间。如果要在实际时间中进行估算，那么故事点的形式化不会带来任何好处。
为了提出一个“更好”（更可口）的估算，开明的经理让程序员分解了工作并估算了各个部分，然后将最小估算加在一起。当然，估算的总和小于程序员的初始估算。
这种技术消除了方程式中的风险和不确定性，仅需花费很少的精力即可完成估算。
当执行实际任务并且实际时间扩展到原始估算的近似值时，找到较小估算值的任何乐趣通常会消失。这不是好的估算方式。
 
更好的估算？
可以理解的是，由于软件项目反复出现的不可预测性，管理人员可能会选择专注于更准确，更准确地进行预测。
最合理的要求是开发团队提供更可靠的估算。
团队可以为估算提供内置的更多应急时间，但是很长的估算时间使团队看上去似乎在“打沙袋”浪费时间，比严格需要的时间要多。怀疑他们可能没有为实现公司目标而努力工作；因此，经理们努力工作以“降低估算”并返回到最初的可预测性问题。
这里的问题不在于估算，而是超出估算领域的社会力量和技术力量。问题不在于您总体上不擅长估算，而是工作有太多风险，不确定性，延迟和中断。
我们无法估算使用哪些预测性的方法。
所以，我们能做些什么？

• 如果我们希望将来做出正确的预测，就必须刻画并减少系统中的混乱情况。
• 意识到我们的计划是软性的，我们可以通过提供完整的端到端“walking skeleton”功能来降低风险，同时检查并改善我们的开发和交付流程。
• 我们可以减少工作量，因此我们可以进行许多小规模，可以成功通过的减少可变性的实验。
• 团队可以保留能力，因此可以更轻松地吸收变化。毕竟，如果团队100％被利用，则没有能力花费检查，检查和改进他们的工作以使其可预测和高效。
• 通过逐步交付，我们可以即时调整和改进计划，找到更节俭的方法来实现目标，甚至可以在向用户学习的同时调整我们的目标。