例如,假设你有一个待办事项,内容是“用户将能够提供他们的电子邮件地址并收到一个带有重置密码链接的电子邮件”,安排在Sprint 1中。
你会开始一个非常粗略的估计并加以完善吗?这个“用户故事”何时变成程序员可以按时间估计的详细操作项?(例如:“构建一个文本框和提交按钮的网络表单”= 2小时)
你是在sprint开始之前还是在sprint开始时进行更精确的估计?或者在设计师/程序员最终遇到任务时,在sprint期间进行更精确的估计?
通常在每个迭代的开始阶段,需要进行两级估算:故事层面和任务层面。为了达到最佳效果,产品负责人和团队应该一起完成这两级估算,尽管有时候在没有产品负责人的情况下,团队可以仅对任务进行估算。
在第一个迭代中,您必须至少估算80%的待办事项(我假设产品负责人已经对其进行了优先排序),以构建一个合理的项目路线图,其中包括按迭代分组的故事和项目长度的初始估计投影。
此时,每个故事的估算都不是用小时、天或周来衡量的,而是使用一个相对大小的单位(同时包含了工作量、复杂度和风险),例如故事点数。我们使用 Fibonacci 序列和 Planning Poker 进行此阶段的估算。整个团队积极参与此过程非常重要。
之后,团队必须猜测他们能够在第一个迭代中完成多少个故事,这将是他们的初始估计速度(点数/迭代)。通常最好不要使用一个月的迭代而是使用两周或一周的迭代长度来提高估算精度。第一次规划通常需要整个团队花费一天甚至两天的时间,具体取决于待办事项的大小、团队的规模和迭代的长度。
在完成第一轮故事估算后,产品负责人与团队可能会重新对待办事项进行优先排序,以优化成本/收益比,因此可能需要反复协商,直到达成一致意见为止。
最终您应该得到类似下面这样的结果:
PROJECT ACME ROADMAP
SPRINT 1 (38 points) <= estimated velocity
--------
Story 1 (21 points)
Story 2 (13 points)
Story 3 (4 points)
SPRINT 2 (40 points)
--------
Story 4 (13 points)
Story 5 (13 points)
Story 6 (8 points)
Story 7 (5 points)
SPRINT 3 (39 points)
--------
...
在接下来的迭代中,这个路线图将被反复修订,在每次迭代开始时,根据团队实际获得的速度调整速度并根据需要重新计算项目长度。有时候,随着团队的发展和需求变化,重新评估故事也是必要的。然而,修订路线图的时间不应超过半天。Sprint 8
--------
Story 17
Task 1: 8 hours
Task 2: 6 hours
Task 3: 2 hours
Story 18
Task 1: 8 hours
Task 2: 6 hours
Story 19
Task 1: 6 hours
Task 2: 3 hours
...
基本上,这些是你在每个迭代开始时应该进行的两种估算类型,通常第一个迭代需要更多的努力来建立初始项目路线图。
由于任务本身没有明确的时间估计,因此重点放在故事点的粗略估计上。如果这些任务一起花费的时间比估计的故事点 * 重点因素更多,那么我们只是在粗略估计时出了错误或者应该在冲刺计划期间进行修正,因为此时大多数信息应该已经可用或者已经整理好了。
目前,我们在冲刺开始之前会制定详细的任务分解和估算。这是由于以下两个原因:
1)我们的业务需要这些估算来帮助他们确定优先级。
2)开发团队承受着按照估算交付并且不偏离自然燃尽的压力。
在我看来,这种方法是错误的,因为它剥夺了敏捷性。我认为流程应该更像这样...
1)业务人员应该使用规划会议上产生的斐波那契数列来帮助他们确定优先级。或者至少只期望从开发团队得到一种"粗略估计"。
2)燃尽图应该被视为项目进展的指南,以指示是否需要添加更多PBI,或降低优先级,而不是作为一个确定完成内容的严格 "目标"。
这样工作将允许我们花费更少的时间在规划和设计上。我们仍然会在冲刺开始时制定高水平的估算,并在冲刺进行时进行修正。
在与我的业务进行争辩之前,我很想听听大家的意见。