【Scrum经济学(2)-分析Scrum各项推荐实践为什么有用】我们的迭代要不要延期

本篇是【Scrum经济学】系列第2篇

Q： 为什么要讲时间盒子？在一些特殊情况下，我们的迭代似乎不得不延期了，我们应该延么？

答：时间盒子就是把计划讨论中的一个因素时间固定（另外一个被固定的因素是团队成员），以降低沟通复杂度，如果要延期，可以！但是你很有可能会回到复杂度更高的讨论里面去，而且其实你遵从“时间长度不变”这一原则，要灵活解决任何问题都是肯定有办法的，agilechina 的讨论组有一个场景讨论把这个问题讲得比较生动。

分析：

没有实施Scrum时候的计划讨论大家都比较熟悉：

项目经理：我们在1个月之内实现A，B特性吧，要几个人多久
技术组长：我觉得我们现在4个人，2个月可以把故事A做完
项目经理：给你加2个人呢，有没有办法一起搞定B，在一个半月之内？
技术组长：哪两个人？我也不清楚能不能搞定B，没有信心，关键你派谁给我，如果你说的是上个月才招来的那两个，我没有办法的，如果不能保证新人做产品的质量，我后面没有办法维护的
项目经理：B特性的a指标不要了，你们现在的团队，一个月A+B！！
技术组长：。。。。我现在给你答案我也没有谱啊。

实施Scrum之后：作为Scrum卫道者言必称时间盒子，说简单一点，时间盒子就是说：时间的长度是不变的，包括迭代长度，会议长度，让其他一切的因素去变化吧。然后把内容装到我们的盒子里面来吧，装不进来的就留到盒子外面，或者换个内容出来，总之不要把盒子撑大了。

为什么？

软件开发的估计恐怕是世界上最难的事情，要估计能够多少不同水平的人，用多少的投入程度，以及多久的时间，可以完成什么样的价值……我们深知世界上没有解决这个问题的银弹。

虽没有解决办法，但我们还是有两个改善的办法，一个是拆分，一个是经验。拆分就是把一个不确定的的大问题，拆分成一些确定的小问题和另外一些不确定的小问题,对确定问题定下常量，并对不确定的问题分开估计。

看看Scrum 的计划会议怎么做的：

• 先被固定的有人员数，团队成员是常量很合理（短期内新加人员短期内不能带来生产力，即使最一般的Boss也能够理解，不能理解的boss不跟也罢，呵呵）
• 然后固定的还有时间（因为时间是有绝对刻度的，也是一个常量的最好选择）
• 然后时间和人员一起被一个叫做 “点”的概念固定了下来。 （“人”和“月”都不变，变了就是《人月神话》了）
• 如果有了每个团队成员估计的投入度，那么迭代总能够完成的点数就出来了。（迭代长度 * 团队人数 * 每人投入度 = 迭代总生产力点数）
• 如果每个故事都能估计出需要用多少点，那么迭代的计划就完成了。（故事需要完成点数 < = 迭代生产力点数）

现在比较之前的变量来说，已经少了2个，只剩下投入度和故事的完成点数分开来需要估计，而且他们的问题相对更单纯，我们不能说我们绝对正确，但是估计的正确性肯定会提升。而且经验越丰富，对剩下2个估值越准！

擅自破坏２个不变的原则会让有可能你的团队沟通得更辛苦，破坏他之前要想清楚！但项目经理问：要是程序员口是心非呢，估值不由心呢？这是Scrum经济学下一问会顺便回答的内容，问题是：“为什么要在迭代会议上估值？”


欧阳丹-天爬者的blog

• http://blog.csdn.net/danoyang
• http://twitter.com/danoyang
• http://digu.com/danoyang