• 00
  • 00小时
  • 00
  • 00
2023敏捷武林大会-上海站,正火热免费报名中...
Search
Close this search box.

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

然后开始考虑其他用户故事。比如,对于“取出钱箱里的钱”这个故事,我们认为它跟“输入管理密码”这个故事一样简单,所以它应该也是算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个故事点的用户故事,推迟到下一个发布周期去。客户应该选择那些比较次要的用户故事。比如,客户可以推迟“打印月销售报表”这个用户故事。

(…….待续)

Search
最新敏捷认证课 ~ 火热报名中
3月30-31日
Scrum Master (CSM) 认证课
张宁宁 Lance Zhang 授课
4月20-21日
Leading SAFe领导大规模敏捷认证课
Eric & Scott 授课
4月20-21日
专业Scrum Master (PSM I) 认证公开课
丁志润 Derek Ding 授课
6月22-23日
专业Scrum产品负责人(PSPO)认证公开课
丁志润 Derek Ding 授课
分类文章
9月15-17日
SAFe ScrumMaster & Leading SAFe官方认证双证班
Eric Liao & Scott Wang 授课
9月18-22日
SAFe认证-SPC SAFe认证培训师导师班
Kurt Jäger & Eric Liao 授课

预约回电

课程顾问将尽快给您回电
电话咨询 400 696 6280