相对估算方法可能显得比较迂回,它不是敏捷团队可以采用的唯一方式。
理想开发者日(ideal developer days,IDD)估算故事,要求团队估计完成故事所需的总人天数,包括开发和测试。IDD这一概念比故事点更简单,而且它可以引起对故事点方法中一些问题的关注:
1、故事点方法不容易被团队理解,更不容易被外部涉众理解,这包括为团队提供项目管理辅助和财务治理的涉众;
2、故事点方法难以起步,除非团队已经完成若干迭代,否则将没有预计团队能够完成内容的线索。这一点在规划层面更棘手,因为在这个层面我们要合计团队估值,试图预测较大功能性在何 时可用。
3、进行进度和成本估算会非常曲折。你必须先进行相对估算、确定速率等。而且在把故事点转化为成本之前,还必须了解每支团队的负担成本。
4、团队要基于现有成员调整团队速率,有时候这会比较困难。例如,如果某成员只是在一个冲刺中兼职,或是某关键资源在一段时间内不可用,那么预期的速率是什么呢?
5、团队速率不是正规化的。一种并不罕见的情形是,某小型团队拥有每迭代40点的速率,而规模比他们大两倍的团队速率却只有其一半。这会引起一些比较不愉快的争论。
+
取而代之的是,采用IDD,使团队回到较为传统的工作估算方式。利用这种技术,团队查看每个故事,针对我们前面介绍的相同复杂性要素讨论故事,然后估计要用多少IDD完成该故事。这种估算法被称为“理想”开发者日的原因是,团队通常漠视他们在计划、演示、管理会议的能力,以及其它团队和公司的开销项。这种方法有许多优点:
1、团队一直是这样做的;
2、管理层总是需要进度和成本估值;
3、对它的解释理解简单很多;
4、针对病假、休假、培训等容易调整速率
然而,在我们急着把任何故事点团队重新培训到IDD之前,我们也必须指出它的一些严重缺点:
1、经过多次运用使团队倾向于被锁定。这种方式过于实际和意义丰富,团队感到必须把它做正确。而且,这种方式没有大相对数字的法则使每个故事平均到总计速率。
2、这种方式过于个人化并且有过多政治寓意。某开发人员可能说一个故事要用两天,另一人说四天。这对他们来说都可能是正确的,但是其结果是导致更多的有趣讨论,而且这种讨论不太可 能支持我们要努力争取的团队精神,因为这倾向于凸显新团队成员和其它有价值团队成员(他只是速度更慢)的较低速度。这就是现实,但并不是我们想要在每个冲刺中塞到人们面前的现实。更糟的是,如果这样的信息进入个人评价,那么你就有了大问题。
它是我们习惯的方式,但是天作证,那并不是特别有效。