Scrum之Story Points

最近很有幸加入到芬兰的项目组，一起感受了一把Scrum。有所收获有所感想，在此分享一下。其实Scrum和TDD，结对编程一样，都是敏捷开发多种最佳实践中的一种。说到其本质无非就是估算项目大小，预计项目进度，处理项目中遇到的各种各样影响项目进度的问题。只是在使用的方法和工具上，与传统的软件项目管理有所不同。这里先对Scrum中的各个概念做一个介绍。就从Story Points这个概念开始吧。

什么是Story Points？

如果有个外国人问我：北京到厦门多远？我回答：两个半小时。这个答案显然是相当不明确的。因为我在答案中没有指明是使用何种交通工具可以在两个半小时之内从北京到达厦门。把这个问题延伸到软件项目管理上，如果老板问我：功能A需要多久完成？我回答：3天可以完成。这个答案显然也犯了同样的错误。因为我没有指明完成功能A的主体，也就是由谁来完成这个功能。也许我需要3天完成，Martin Fowler三分钟就搞定了。

这里我们可以看到，传统的项目管理方法存在的一个问题就是总是假设所有人的工作效率都是一样的。从而以人/月或人/天的形式来估算项目的大小，导致项目进度估算的不准确性很大。那要如何解决这个问题呢？回到一开始老外问的那个问题，如果我回答的是：1700多公里。这样的答案就相当明确了。因为公里这个计量单位是全世界公认的，不存在歧义。所以如果我们在软件项目的估算中，能有这样一个公认的统一的计量单位，那准确估算项目大小肯定不在话下。可是软件的特点决定了这样的一个计量单位在目前来说还是不存在。那么又要如何解决这个问题呢？

还是回到一开始的问题，如果我并不知道厦门到北京绝对的距离是1700多公里，那我应该如何回答呢？正常情况下我们会给出一个相对性的答案。比如我会回答：比到天津还更远一点。而这正是Story Points的本质。Story Points对项目的估算是一种相对大小，而不是一种绝对大小。通过Story Points，我们可以估算出项目中各个功能模块或任务的相对大小。

如何估算Story Points？

明白了啥是Story Points，我们就来看看如何进行估算，以及这么估算有什么好处。假设在需求分析以及简单的概要设计之后，软件的基本功能模块已经有了一个相对清晰的概念。于是项目组会举行一个会议，集体来讨论如何估算项目的大小。

首先要解释一下Story Points是如何区别大小的。其实从概念上来说，并没有规定要如何表示Story Points的大小。比如可以使用1、2、3、4...这种自然数来表征Story Points的大小，也可以使用2、4、6、8...甚至还可以使用衣服的尺码，比如xs,s,m,l,xl来表征大小。只要是能够表达大小概念的一串符号，都可以用来表示Story Points的大小。但是在实践中貌似大部分人还是喜欢使用数字。不过如果使用自然数序列来表示Stroy Points的大小，容易给人造成错觉，引起不必要的争论。首先因为自然数是连续的，那么很容易引发人们对于一个任务的大小到底是4还是5这样的争论。其次自然数容易给人造成倍数关系的错觉，因为人们很自然的会觉得4是2的两倍，那么大小为4的任务的工作量应该是大小为2的任务的工作量的两倍，这显然是不合理的。因此，我所在的项目组在实践中采用的是fibonacci数列，也就是1，2，3，5，8，13....采用这个的好处是，既区分了大小，又避免了连续自然数带来的问题。当然在使用Story Points进行估算的时候，与传统项目相同的是，要尽量细分功能模块或者任务的大小，这样估算才能准确。所以一般使用的数字不会超过13.

ok。现在可以开始估算了。Story Points既然是相对大小，那首先必然要确定一个估算的基准值。我所在的项目组一般会根据以往工作的经验，在当前的众多任务中，选取出两个任务，将它们的大小分别设置为2和5。其余的任务都与这两个基准任务进行比较，估算大小。

注意！精髓来了！在整个估算的过程中，必须是全体项目组成员都参与，并且采用了一种叫做Planning Poker的东西。何谓Planning Poker？其实就是写了1、2、3、5、8、13的小牌子，当会议主持人要求大家对某个任务进行估算的时候，大家一起举起自己认为合适的牌子，如果大家都一样，ok，Pass！如果存在出入，则每个人都要阐述自己的理由，这个过程会一直持续到大家达成一致为止。

个人认为，Planning Poker的使用大大增加了估算的准确性。因为在传统的方法中，绝对没人会举牌来表决某某某的工作效率是多少这件事情，这么干只会加速项目的失败。但也因为没有对每个人的工作效率全面客观的评价，从而导致了信息的不对等，估算的片面性。如果哪一天可以开放到公开讨论和定义每个人的工作效率的话，那估计传统的项目估算方法准确度也会大大提高。

整个估算的流程基本就是这样。从这里我们可以看出Story Points的优势在于它是相对客观的计量，与开发人员水平的相关性较小。项目组新增人员或者有人员离开，都不会对Story Points产生大的影响。当然，Story Points还是受到开发人员水平影响的。假设项目组都是菜咖，在做Story Points的估算时往往会漏掉一些难点和风险，从而导致整个估算值都偏低。但其实这也是有方法补救的，我们可以在后面的文章中看到。

关于Story Points就介绍到这里。大家肯定会有疑问：估算出了Story Points有什么用呢？它只是一堆的数字，既不表示具体的时间范畴，也不是功能模块或任务绝对大小的反映。要理解这个问题，还要了解Scrum中另外一个重要的概念，即Sprint。Sprint将在下篇文章中介绍。