如何以正确的方式进行敏捷估算

许多敏捷和Scrum团队从基本实践入手，以使自组织团队能够更好地交付业务优先级。 实践包括承诺团队可以在冲刺中完成哪些工作，举行每日站立会议以管理进行中的工作，为利益相关者主持演示以展示已完成的工作以及组织回顾以讨论流程改进。

使用这些基本实践，小型敏捷团队可以通过提供渐进式改进并让利益相关者权衡新的优先事项来展示业务价值。

[了解您的企业如何在敏捷开发中脱颖而出 。 | 将您的敏捷职业提升到一个新的水平： 如何提高您的Scrum Master技能 。 | 不确定“敏捷”的真正含义是什么？ InfoWorld 解释了敏捷方法论 。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

随着组织和团队在敏捷实践中日趋成熟，他们经常面临新的问题。 领导者可能会问：“您能告诉我我们优先考虑的功能何时完成吗？”或“能否与我分享在未来几个月内可能会完成的功能列表？” 产品负责人可能会问：“此增强功能有多昂贵和复杂？”，运营团队可能想知道，“您能否在下一个Sprint中压缩这些缺陷修复程序？”

致力于过程改进的团队通常会在敏捷过程中遇到相关的生产率和质量问题。 许多敏捷工具测量团队速度 ，即团队可以在短跑中完成多少任务，团队将需要定义，测量，稳定并理想地提高他们的速度。 更高级的团队通常希望在许多sprint中查看其整体性能：在处理许多小故事或几个大故事时，它们是否提供更高的质量？ 如果团队成员长时间休假会产生什么影响，或者如果将新人员加入团队，他们还能承担什么呢？

如果您遇到这些问题中的任何一个，则您的组织或团队可能已准备好实施敏捷估算。 敏捷估算旨在为积压中的所有事物分配成本因素。 然后，此成本权重可用于衡量团队速度，围绕功能优先级做出更好的决策，或用于制定预测和路线图。

关于是否实施敏捷估计存在一些争论。 #NoEstimates周围有动静 ，也有专家在使用估算值方面有所权衡 。 如果您负责组织中实施估算的工作，那么通读这些论点很重要。 让人们进行估算并不容易，您可能会发现不想参与的人。 了解辩论将帮助您回应团队或个人的建议或异议。

敏捷估算要求您提出一种方法，以了解团队应如何就估算达成共识。 您可能会听说有关计划扑克，存储桶系统，相似性映射和其他估算技术的信息 。 在我的工作中，我通常授权团队决定如何协同工作以得出估计值，但是我确实提供了一些指导原则。 估算应反映正在处理的问题的工作量和复杂性，并应考虑每个人的工作。

相关视频：敏捷方法的真正作用

似乎每个人都在谈论敏捷软件开发，但是许多组织对流程的运作方式没有把握。 观看这5分钟的视频，以加快速度。

为了给团队提供有关估算的更具体指导，应该对度量单位进行讨论并确定标准。 还是在这里，关于是否要以小时为单位进行估算，这是一种称为故事点的抽象度量，还是带有T恤尺寸之类的标签，这引起了一些争论。

一些团队从T恤尺码入手，因为它更易于理解和沟通。 与“特大号”相比，“小号”可能更容易做到，与“十小时”或“八分”的估算值相比，团队，产品所有者和利益相关者可以更轻松地思考这些术语。 。”

但是，使用T恤尺寸无法量化，因此更难用于测量速度或进行分析。 随着评估实践的成熟，许多团队将从T恤衫尺寸中毕业。

当团队执行具有较低复杂性或风险的标准化工作时，工作时间是一个很好的指标。 如果任务的类型适合于基于工作量的准确指标，那么知道修改用户界面的故事将花费两个小时的时间就很有价值。

但是，软件开发和其他业务流程的精确度较低，未知数更多，并且通常需要多个具有不同技能的人员做出贡献。 如果您的故事需要与新的API交互，开发前端小部件并确保交付满足目标性能标准，则可能很难在工作时间内对故事进行衡量。 使用新的API存在风险，并且两个或多个人员之间可能需要协调才能实现代码和测试用例。

许多团队使用故事点来表示估算中的工作量和复杂性 。 较低的故事点表示复杂度低，工作量少的故事，而较高的故事点表示整个团队的复杂度和工作量。 许多团队根据斐波那契数列来分配分数，因此，增加复杂性和工作量会使故事分数成倍增加。

此外，最好的团队会在分数分配中使用一些合格的语言。 例如，团队可能需要三点故事来进行不需要任何后端或API更改的微小更改或增加的用户体验。 您会看到，这种资格限制了可能是一名前端Web开发人员的努力和风险，因为所做的更改仅在Web层中实现。

通常，团队需要数次冲刺才能标准化他们的估算方法。 但是一旦完成，有几种重要的使用方法。 团队应该通过了解他们的速度以及要提交的故事的类型和大小来优化故事的制定和发展过程。 团队应该更好地了解他们可以最佳地执行多少个中小型故事。 许多团队认识到完成大型故事所需的风险和协调，因此他们在冲刺中致力于少量大大小小的故事。

现在，大多数敏捷管理工具中可用的Sprint燃尽图可以通过估算值加权，并用于优化Sprint期间的工作。 此外，史诗级和发行级燃尽现在具有更多意义，因为它们可以帮助团队在开发过程的早期专注于更高的价值和风险故事。

对于具有自动CI / CD管道和更频繁发布的团队而言，估计的故事成为决定如何管理开发管道的宝贵工具。 可以在功能分支，具有功能标志的中型分支和直接提交给主开发分支的较小更改中更好地管理运行时间较长的功能。

[InfoWorld的要点： CI / CD入门：使用CI / CD管道自动执行应用程序交付 。 • CI / CD的5个常见陷阱以及如何避免它们 。 ]

最后，团队可以开始衡量其技术债务的规模。 当发现债务并积压在债务中时，应为解决债务的工作量和复杂性分配一个估算。 当团队将技术债务案例添加到其积压中并主动进行估算时，他们现在可以衡量总技术债务。 他们还可以报告在每个sprint和发行版中优先考虑和解决了多少技术问题。 由于大多数开发团队都对技术债务的数量充满热情，因此使用估算来衡量这是使团队参与估算过程的一个好方法。

相关视频：如何使用CI / CD更快地交付代码

这个3分钟的视频说明了如何使用持续集成和持续开发来更快，更高质量地交付应用程序。

一旦团队对他们的估计有了信心，就可以与产品负责人和业务负责人一起使用。 首先要制定一个计划过程，该过程旨在使功能的所有故事都得到编写，确定优先次序和进行估计。 一些组织在执行其开发工作的同时执行敏捷计划，而其他组织则为计划制定单独的冲刺周期 。 在我的《 驾驶数字》一书中，我分享了一个故事写作的两个阶段，其中在第一阶段起草并评估了“故事存根”，然后在第二阶段中对优先存根进行了充分的写作和重新估计。

估算功能后，团队可以与产品所有者就其范围和优先级进行更多数据驱动的讨论。 具有五个故事和35分的功能A是否比具有两个故事和12分的功能B重要？ 或者，如果简化了功能A的要求，则可能导致估算值减少。

当团队在他们的积压订单中估计多个功能时，还可以导致更好的发布计划和与产品所有者一起制定路线图。 团队可以查看工作的类型和故事的大小，并提供有关可以为即将发布的版本最佳地使用哪些功能的选项。

在很多地方使用估计值都是有问题的。 首先是组织应用时间跟踪并希望将应用于故事的实际时间与估算值进行比较。 在评估故事点时，这种比较不能很好地进行，因为点通常代表复杂性和努力。 即使以小时为单位进行估算，团队也最好根据承诺和维持或增长速度的能力来评估交付，而不是仔细检查各个估算。

其次是管理者尝试使用估算值进行资源分配时。 他们可能建议团队中的一个人可以从事更多的工作，因为他或她分配的分数比以前的冲刺少。 这种逻辑存在严重缺陷，因为敏捷团队并未完全考虑所有团队成员参与完成用户故事的情况。 这种资源管理形式相当于微观管理，但这阻碍了敏捷团队的成功，而敏捷团队是建立在信任团队做出诚实承诺的基础上的。

一个类似的问题是管理人员是否尝试使用分配和估计来衡量个人绩效。 同样，评估和分配团队在管理其优先级时所做的并不是审查个人生产力的最佳工具。

综上所述，今天您将发现更多使用敏捷估算的团队来提高团队生产力，质量和业务一致性。

From: https://www.infoworld.com/article/3300158/how-to-do-agile-estimation-the-right-way.html