基于用户故事的计划及跟踪(二)

然后开始考虑其他用户故事。比如,对于“取出钱箱里的钱”这个故事,我们认为它跟“输入管理密码”这个故事一样简单,所以它应该也是算1个故事点。我们在列表里面标上。当然,实际操作的时候,我们是在“取出钱箱里的钱”的故事卡上填上故事点。
用户故事            故事点
卖饮料
取消购买
输入管理密码     1
补充饮料
取出钱箱里的钱   1
安全警报
打印月销售报表

对于“取消购买”,我们认为它应该是“取出钱箱里的钱”的两倍的工作量,所以它算2个故事点。
用户故事           故事点
卖饮料
取消购买             2
输入管理密码    1
补充饮料
取出钱箱里的钱  1
安全警报
打印月销售报表

对于“卖饮料”,我们认为它应该是“取消购买”两倍的复杂度,所以它应该算4个故事点。
用户故事           故事点
卖饮料            4
取消购买            2
输入管理密码   1
补充饮料
取出钱箱里的钱 1
安全警报
打印月销售报表

对于“补充饮料”,我们又认为它比“取出钱箱里的钱”复杂,但又比“卖饮料”简单,然后它又应该比“取消购买(2个故事点)”复杂,所以我们认为它应该是3个故事点:
用户故事          故事点
卖饮料            4
取消购买            2
输入管理密码   1
补充饮料            3
取出钱箱里的钱 1
安全警报
打印月销售报表

类似的,我们认为“安全警报”应该比“补充饮料”简单一些,所以应该是2个故事点:
用户故事        故事点
卖饮料        4
取消购买        2
输入管理密码   1
补充饮料        3
取出钱箱里的钱        1
安全警报        2
打印月销售报表

“打印月销售报表”应该跟“卖饮料”一样复杂,所以应该是算4个故事点,这样的话,我们总共有17个故事点:
用户故事        故事点
卖饮料        4
取消购买        2
输入管理密码  1
补充饮料        3
取出钱箱里的钱        1
安全警报        2
打印月销售报表        4
总计        17

现在挑出任意一个用户故事,估计一下它要花(你一个人)多少时间来完成。假设我们之前做过跟“取出钱箱里的钱”类似的功能,所以我们就挑这个来计算,估计它要花5天的时间。也就是说,一个故事点要花5天的时间来完成。现在我们有17个故事点,也就是说,我们需要17×5=85天来完成这个项目(如果只是一个开发人员来做的话)。假设现在我们的团队里面有两个开发人员,所以我们就需要85÷2=43天来完成。

从目前的估计来看,我们可以在50天的期限里面做完这个项目。但现在说这个还太早了!这样的评估,更多的是猜测。通常开发人员在工作量上的估算都很差。事实上,人们经常会低估了工作量。那我们应该怎么估计得更准?

开发速率
为了做到更准的估计,我们就让客户先给我们两周的时间做一些实际的开发,来测量一下我们在这两周里面可以做多少的用户故事。我们叫这两周的时间为“迭代周期”。

哪些用户故事应该放在第一个迭代周期里面做?这可能完全是客户决定的,也可能是大家讨论以后决定的。不过挑出的这些用户故事的故事点不应该超过这两周的承受能力。因为一个迭代周期有10天(假设我们周末不工作),然后我们估计一个开发人员5天可以完成一个故事点。现在我们有两个开发人员,所以我们应该可以在这个迭代周期中完成(10÷5)×2=4个故事点。

然后客户可以在总故事点不超过4的前提下,挑出一些用户故事在这个迭代周期里实现。他们可能会尽量挑选他们觉得最重要的故事。比如,对他们来说,销售报表跟找零钱最重要,所以他们就挑出这两个:
用户故事        故事点
取出钱箱里的钱        1
打印月销售报表        2
总计        3

假设两周的迭代周期过去了,我们完成了“取出钱箱里的钱”,不过“打印月销售报表”没有完成,还剩0.5个故事点没有完成。也就是说,我们在这个迭代周期内完成了3-0.5=2.5个故事点(比原来的预计要差一些)。

2.5个故事点这样的数值,就是我们现在的参考值。也就是说,这个团队每个迭代周期可以完成2.5个故事点。这个参考值对我们很有用。它有两个用处:
首先,我们可以假定我们在下个迭代周期也可以完成2.5个故事点,然后客户选择的用户故事的故事点总和不能超过2.5。
其次,在从第一个迭代周期取得参考值以后,我们可以重新估算我们的发布时间了。本来我们估算我们每个开发人员完成1个故事点的时间是5天,现在我们有了实践后的数据了,我们的团队(两个开发人员)可以在一个迭代周期(10天)内完成2.5个故事点。现在总的故事点是17,计算一下,我们需要17÷2.5=7个迭代周期来完成。14周,也就是70天。也就是说,我们满足不了客户提出的期限(50天内)!怎么办?

不能如期完成时

很明显,现在我们完成不了全部的用户故事。在这50天里面,我们只能完成50÷10×2.5=12.5个用户故事。因为现在有17个故事点,我们应该让客户挑出总计4.5个故事点的用户故事,推迟到下一个发布周期去。客户应该选择那些比较次要的用户故事。比如,客户可以推迟“打印月销售报表”这个用户故事。

(…….待续)

火爆 售票中
Scrum.Org 主办
搜索
近期公开班
scrum alliance csm认证徽章
12月14-15日 (周六、周日)
Scrum Master (CSM) 中文认证课
远程
Lance Zhang 张宁宁 授课
专业Scrum Master (PSM I) 认证徽章
12月26-27日(周四、周五)
专业Scrum Master (PSM I) 认证公开课
远程
Derek Ding 丁志润 授课
Scrum.org专业Scrum产品负责人(PSPO)认证徽章
1月4-5日 (周六、周日)
专业Scrum产品负责人(PSPO)中文认证公开课
远程
Derek Ding 丁志润 授课
领导大规模敏捷Leading SAFe认证徽章
1月11-12日(周六、周日)
Leading SAFe领导大规模敏捷认证课
远程
Scott Wang 王庆付 授课
safe scrum master ssm
2月22-23日(周六、周日)
SAFe ScrumMaster 官方认证公开班
远程
Eric Liao 廖靖斌 授课
大规模敏捷顾问SAFe SPC认证课徽章
2月27-3月2日(周四-周日)
SAFe认证-SPC SAFe认证培训师导师班
上海
Eric Liao & Marsha Xue授课
safe scrum master ssm
8月10-11日
SAFe ScrumMaster 官方认证公开班
Eric Liao 廖靖斌 授课
scrum alliance csm认证徽章
11月09-10日
Scrum Master (CSM) 中文认证课
Lance Zhang 授课
scrum alliance csm认证徽章
10月26-27日
Scrum Master (CSM) 中文认证课
中文远程
Scott Dunn & Eric Liao 授课
领导大规模敏捷Leading SAFe认证徽章
10月19-20日
Leading SAFe领导大规模敏捷认证课
Eric Liao 廖靖斌 授课
Scrum联盟acsm认证徽章
10月19-20日
高级Scrum Master(A-CSM)认证公开课
Jim Wang 王军 授课
0
0
小时
0
分钟
0
由Scrum.org主办的 2024中国Scrum大会 8月17日将在上海开幕
0
0
小时
0
分钟
0
预约回电
留下您的手机号,我们会在第一时间联系您。
热线电话:400-696-6280
预约回电
预约成功,我们会尽快联系您。