我能想到的一个类比是……我希望我的飞镖飞镖靶,不一定和公牛的眼睛....它需要很多的细节显然是评估期间失踪。然而,如果我不被击中飞镖板上的任何地方…就像在黑暗中射击;一个非常令人失望的估计场景。
一块巨大的新团队在到达正确的斗争故事/特性估计产生相当大的浪费;与大多数他们失败由于巨大的变异(估计与实际)!很少有成功的这段旅程,更接近实际的初始周期本身。
项目经理在传统的开发重点详细的范围、时间和成本,估计,是准确和冷冻前踢开始一个项目。多远这是成功和精确的值得商榷!在敏捷项目中,在产品待办事项列表细化开发团队成员到达高层估计产品待办事项列表中的每个故事通常在故事点(斐波纳契数列),艾滋病在sprint计划更好的估计。这有助于团队开始,而不是等待所有项目的细节敲定。
故事点是一个任意测量功能的大小相对于其他特性,而不是完成一个功能所需的时间。
例如,通过观察鲸鱼的图片不能确定每个鲸鱼的确切年龄和体重,但可以比较每个彼此的大小。这是一个非常方便的方法来估算的详细信息可用的努力可能不会这么早。故事点用于计算有多少用户故事在sprint团队可以完成这称为速度。
故事点大小的假设解释使用评价等级,最常见的包括数值大小(1 - 10),t恤尺寸(XS, S, M, L, XL, XXL, XXXL),斐波那契数列(1、2、3、5、8、13日,21日,34岁的…),等等。
一个团队开始故事点估计必须清楚,同步,并同意在以下方面(我称之为“五微妙的规则”,因为他们是隐藏的,在我们的脑海中工作。)。
常见的参考相同,每个团队成员估计应该有一个参考。例如,L规模来衡量一个故事
点大小团队中的每个人都应该是一样的标准。任何冲突对参考指数在巨大的变化和错误的估计结果。同意在一个共同的参考是非常关键的。
集体智慧——估计是一个团队,因此都应该参与这个活动。有一个人这样做将是一个巨大的风险随着误差将会很高!然而,集体决定帮助到达普遍估计,很可能将是准确的。
此外,在相对评估团队还应该考虑到努力,复杂性和不确定性,每个故事之前到达一个数字。
努力——故事需要多少努力完成,相对于参考的故事。
复杂性——多么复杂的故事关于参考的故事。
不确定性——/未知的故事拥有多大的风险相对于参考的故事
即使有这个共同的协议,可能还需要几个迭代团队到达前常见的估计值。估计是肯定很难,我们如何获得最佳的估计故事大小?
为什么不仔细看看”基于证据的评估”,是经验,学习经验,精通掌握每个校准,并采取在最初的项目评估阶段,理解它的真正好处!
这是一个团队的方法应该继续“基于证据的评估”:
让我们考虑一个scrum团队的成员开始10个工作日的sprint 2周。每天6小时的努力,能力将大约是7 * 10 * 6 = 420小时。
- 第一sprint计划会议期间,团队从头开始,没有故事点分配给产品待办事项列表中的故事。
- 一个故事从产品待办事项列表选择任务和时间分解为每个紧随其后。这一步继续直到估计能力增加了大约400小时/ 5的故事(考虑团队能力平均420小时)。
- 通过sprint团队努力完成所有计划的故事。通过旅行他们识别的不确定性、复杂性和精力来完成这个故事。
- 在回顾会议,团队组装故事点完成的故事(当然现在与一些经验/证据)。
- 5个故事中,团队选择的媒介工作,复杂性和不确定性和分配一个故事点(记住5微妙的规则)。例如,当我们把一个评价等级1,2,3,5,8,13;这个故事被赋予一个故事点3和它成为普遍引用的故事。仔细看看这个练习清楚地表明故事点数量是新兴的工作经验/证据而不是仅仅想工作!
- 团队继续故事点估计所有的故事在Sprint 1(每个步骤5)和分配一个值低,相比更高或相同的参考点的故事。
- 从一个故事到另一个团队收益,比较参考点变得多种多样的除了明显有助于他们更好的估计。此时如果团队认为需要改进之前的估计,他们可以。这个想法是为了获得更好的与经验,是现实的估计。
团队可能决定使用这个估计在最初几个冲刺,直到他们有信心的过程。有经验,团队变得更好的估计和装备精益方法推导近乎准确的故事点产品待办事项列表细分的过程中,从而帮助更好的敏捷性和透明度。