|
今天看到几篇不错的英文Blog，关于如何理解Story points，这个Scrum中的概念，现分享如下： 总的理解如下： Story points 是为了让客户或老板预估什么功能什么时间大概会发布。因此它肯定是与时间有关的，也与最后的工作成果有关的，但这个单位不能简单理解成其中任何一个单项，如时间（人天）或复杂度、难度等。 其中Story Points Are Still About Effort 这篇文章中用“到达某个地方”这一目标事件举了一个很好的例子，不同的人要到达这个地方可能用的时间不同，如甲用1小时，而乙用3小时，路途是一样的，这时我们请甲和乙都把“到达这个地方”理解为1个Story point，那么下次在预估另一个目标点时，他们就都可以参考这个预估。 比如另一个目标，甲感觉需要2小时走到，而乙可能感觉需要5小时，这时甲的预估差不多就是2个Story point，而乙也感觉差不多要2个Story point，这样大家就可以有一个“相对的单位”，而不是用时间这个“绝对的单位”来讨论了。 另外，还要考虑与最后的工作成果有关的因素，在上面走路的例子中，大家可能很自然想到用“距离”来评估工作成果，但现实世界中还要考虑很多其他因素，比如道路的难易程度，同样距离的目标，可能一个很好走，因此用时就少，而另一个可能路难走、拥堵等，因此用时就多，那么前一个也许Story point在预估时给了2，但后一个可能就要考虑风险因素，预估为3或4了。文中的例子是说在路途中有几个火车道，有可能会等待火车通过等。 同时，Story point 却不是衡量复杂度的单位，比如文中举了例子说到达同一个目标，是普通走过去，还是边走边唱江南Style过去，复杂度是不一样的，但这个因素就不应该放在Story point中来考虑，因为唱着过去和普通走过去用的时间不会差太多的情况下，它们在Story point来说是一样的。 这样在一个Sprint阶段中，一个Team团队所能完成的工作成果，基本会有一个预估，如一个Sprint（一个月）该Team，甲能做10个Story point，乙能做6个Story point，丙能做9个Story point……，最终整个Team能做的Story point大概就是40个，而这样将Backlog（任务堆）中相应Story point大小的功能需求放进来，就八九不离十了，也就基本是可预估的了，这样老板、客户心里就有底了，开发人员们也基本可以保证按时发布，皆大欢喜啦！ 最后，还是回归到Agile的本质，Story point不期望精确衡量软件开发中的工作量，仅仅是用来预估个大概，八九不离十就可以了，软件开发的管理中对于这方面请不要太较真，特别是不要用这个来作为开发人员绩效的衡量，实际上最好不要有任何的绩效衡量，这需要另文再述。 这里只是解释了一下为什么不用时间、人天（时）或复杂度、难度、代码行等绝对精确的单位来预估，而是采用了这样一个大家感觉上较易统一，但又不很精确，模模糊糊的一个相对单位来预估的原由和理念，希望大家能“大概”明白了，哈哈…… |
|
|
来自： icecity1306 > 《项目管理》
