|
然而有些人仍然认为即使以故事的方式进行估算也会让我们从真正的价值交付上分心。针对这一点，有一个围绕着#NoEstimates的讨论。training.mypm.net
什么是#NoEstimates讨论项目管理论坛
如果你在Twitter上关注了任何一位敏捷方面有影响力的人，你可能已经注意到他们有些人参与了#NoEstimates 标签的讨论。看起来这是要我们完全停止进行估算，其实它是要我们不再进行故事点数的评估，而是立即开始开发。项目管理者联盟
这个讨论自从出现后已经有了一个迅速发展的势头，因为那些在大项目中工作的人他们感觉无论是用故事点数进行评估还是仅仅统计故事的个数，团队产量的跟踪结果基本是相同的。PgMp.mypm.net
一定程度上这可能是因为那些有经验的交付团队每个迭代会将故事实时地(Just-in-time)以一致的标准拆分成更小的故事——这样的拆分使得团队每个迭代能产出更多潜在可交付的增量——无论项目在迭代里是采用的非常小的故事，还是适度大一些的故事，最终每个迭代的产能报告看上去都差不多。项目管理论坛
#NoEstimates这种方式使得故事的优先级设置更简单了，使得交付团队能够更快地开始工作。然而可怜的产品负责人和项目投资方他们仍然需要知道项目大概要花费多少成本，需要多长时间。好消息是我们还可以基于故事个数的统计来进行粗略的估算，只要项目能够建立起足够有效的度量指标来让这样的估算可行。
对于任何刚开始敏捷之旅的新团队来说，无论如何我都强烈建议你们采用故事点数进行估算，直到你具有了和那些团队一样的丰富经验和成熟度。training.mypm.net
结论club.mypm.net
作为总结，引用General Dwight D. Eisenhower的一句名言：“在准备开始一个项目时，我总是发现估算的数字是没有用的，但估算的过程却必不可少”。我们仍然需要进行估算，不管这样的活动叫什么名字，不管在这样的活动中我们如何进行计算。bbs.mypm.net
我要感谢Esther Derby(估算成为目标)，Mike Cohn(为发布计划和优先级设置进行估算)，Ahmed Sidky(全员估算)，Martin Fowler(故事点数)，Ian Mitchell(完成标准)，Vasco Duarte(故事个数vs.故事点数)，Stephen Forte(度量与估算)，Neil Killick(有经验的团队定义更小的故事)，和其他很多人，感谢他们在这个话题上给我的分享——以及我上面对他们各自论文的链接引用。blog.mypm.net
关于作者项目管理者联盟
David Morris 是一位独立业务敏捷性实践者、教练和讲师;通过他的公司Sophorum为新西兰各地的客户提供业务分析、团队领导，教练和培训服务。他有近30年的项目交付经验，在这30年中他以团队成员，团队领导，以及自己企业的负责人身份参与了各种类型的项目，比如战略、经营和技术类的项目，并在这些项目中运用了结构化的、迭代的和敏捷的方法。项目管理者联盟
David 通过了CBAP、ICAgile Certified Practitioner、Certified ScrumMast*r和 IT Certified Professional的认证。他主持研究小组、专业开发讲座和训练营;帮助Agile Auckland和IIBA NZ组织活动;在欧洲和澳大利亚的的各种大会和活动上进行演讲;并参与了多本书的创作(包括“Agile Extension to the BA Body of Knowledge”);他也是一位活跃的博主，tweeter和维基百科编辑。bbs.mypm.net 项目管理者联盟
|
