近日，Michael Sync 提出这样一个问题：如何对大项目或是大特性进行估算：
我知道我们不应该对一个以上的 sprint 进行估算，因为后面可能会对其进行修改。但真实情况往往并非如此。我们需要提前对整个项目或是一些特性进行估算，这样才能确定目标日期并对特性进行调整或是改变其优先级。 为了能更加精确地进行估算，我们需要在创建 sprint 之前将用户故事分解为任务。 那该如何处理或是估算呢？
Peter Bell对估算与承诺进行了严格的区分：
是否有人问过你关于估算或是承诺的问题呢？所谓估算，就是根据目前可用的信息做出的合理猜测。估算不是偏高就是偏低，通常在构建复杂软件时估算会偏低。他们不是承诺，也不能当作承诺。
Scrum Development 邮件列表上的成员所达成的共识是项目估算并非特别有用，也不值得你花很多时间在这上面。“woynam”写到：
进行估算的组织请不要再忧虑某些东西要花费多少代价了，请转到变化上来吧。如果你知道要花费多少代价、要花费多少时间，那么唯一变化的就是你的这些钱会实现多少个高优先级的特性了。关键在于如果你不再进行估算， 那么你仍旧可以确保首先实现最有价值的那些特性。
George Dinwiddie写到：
如果利润或是损失取决于对花费的精准预测，那么你可能选错产品了。这种产品的升值潜力太低了。 我经常发现组织中的高层很清楚这一点，但中层经理往往不太理解：
对于大多数组织来说，估算都不是什么好事：他们被当作承诺和威胁，还会导致人们机械化地决定工作量、增加故事点或是小时数，而非仔细洞察团队到底能完成什么，如何完成。 我完全不赞成对故事进行估算，除了这样的描述：“几个人干几天”。当然了，这仍然是估算，但却不易被误用。
我喜欢让团队在几周内对大的故事进行估算，然后不断累加。这么做的结果会让人们对项目大小形成一种共识。不能将这当作承诺，但可以作为一个点，你可以提出重要的问题，比如说：在 N 美元和 M 月的前提下， 我们能否交付呢？
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论