交付产品大概需要多少时间，这是客户常常提出的问题，也是让敏捷团队感到不爽的问题。一方面，在没有开始动手前就估算整个产品功能的工作量，等于无头苍蝇到处乱撞。然而，很多情况下，这是一个很现实的问题，团队不能将其抛在脑后。
Jarrod Roberson 提到：不应该估算一整个项目，因为这与敏捷哲学完全是背道而驰。团队最多能够做到的，是根据成本和其他约束条件设定一个日期，产品负责人应该判断到这个日期截止要完成哪些功能。Pascal Thivent 补充道：任何前期的估算都会导致固定的产品范围，这正是敏捷反对的。更极端的建议是：敏捷团队永远不要介入需要前期估算的项目中。
但是，这么做在现实世界中可行吗？
敏捷团队常常遇到这样的情况，客户需要一个大概的估算，以辅助多方面的决策。 Hugo Palma 认为：
我认为，对于实现给定的功能，所有的客户都想了解大致估算，想知道要花多少钱。有人说：如果用敏捷，就不能这么做；我不同意。现实世界中的客户希望知道在一个项目上大概要花多少钱，至少有个粗略的概念，敏捷是可以调整、适应的。
Mike Cohn 提到：他常常被问及，交付一个产品大概要多少个小时。他推荐的第一种方式，是推迟分析，直到有足够的历史数据，或者在 sprint 规划会议上能够得到一些承诺，再做分析。不过，有时候是需要粗略估算。对于这样的情况，Mike 建议使用 backlog 取样技术，找出不同规模用户故事的平均小时数。
如果我们把 1 个点的故事平均一下，也许可以发现大概每个点数需要 3.2 个小时，2 个点的故事要拆分成任务，每个点数大概 4.3 个小时，3 个点的故事平均每个点 4.1 个小时，如此类推。 然后就可以把平均小时数与产品 backlog 中对应规模的故事数乘起来，再加总。
Mike 提醒大家注意：这种技术会把任务识别和估算步骤中引入的不足全部包括进去。Rob Bowley 的评论是： backlog 取样技术没有效果，因为软件开发无法预测，而且像这样的技术估算出来的工作量会低于实际要完成的工作量。
尝试这么做，是没有道理可言的。它必将大大低估所需的工作量。考虑到软件开发需要投入的资金，结果就是对组织造成财务上的伤害，或是毁掉某些人的事业。
Matteo Vaccari 提到：尽管使用 backlog 采样估算也许有助于得到一些数字，但还是会不断出现新的未知数，比如团队成熟度、一起工作的历史数据、完成的定义，等等；这些都将使得估算失去作用。
这种情形下的另一种选择，是采取Martin Fowler 提议的“柔软范围（Scope Limbering）”方法，其用意是：从固定范围合同开始，然后逐步教育客户敏捷的优点，帮助他们克服“固定范围的海市蜃楼（FixedScopeMirage）”。Rob Thomsett 提议的“翻番再加一点（double and add some）”游戏，也与Martin 的方法类似。
因此，在真正意义上，看起来没有哪个方法是完备的。它们都有某种程度的主观性，因此有自己的问题。不过，如果在需要粗略估算的场景中使用这些技术，也许能帮助利益相关者做出更成熟的决策。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论