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

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

(这只是开发不能如期完成时的解决方法之一,这种方法应该是在客户比较有诚意合作的前提下使用。)
用户故事        故事点

卖饮料        4
取消购买        2
输入管理密码                                                        1
补充饮料        3
取出钱箱里的钱        1
安全警报        2
总计        13

然后他还要挑出总和至少为0.5个故事点的故事。

但是如果“月销售报表”这个用户故事对客户来说也是非常重要,而且其他的故事也不能推迟,这时怎么办?这时我们就要试着简化这些用户故事。比如,原来“月销售报表”是要用一个第三方报表库来实现的,而且还要画出饼状统计图,如果我们只是生成简单的文本格式的报表的话(这格式应该可以被Excel导入,以便日后的处理)。那么这个用户故事的故事点就会从4减少到2,节省了2个故事点。如果客户同意的话,我们就可以将“打印月销售报表”分成两个用户故事“生成月销售文本报表”和“生成图形报表”,然后将后者推迟到下一个发布。

现在新的故事卡片出来了:
用户故事        故事点
卖饮料        4
取消购买        2
输入管理密码     1
补充饮料        3
取出钱箱里的钱        1
安全警报        2
打印月销售文本报表        2
总计        15

还有其他的2.5个故事点要推迟,我们可以简化“卖饮料”。假设本来我们可以卖不同价格不同类别的饮料。如果现在我们只是简单支持一种价格一种类别的饮料的话,那这个用户故事的故事点可以从4减到2了。客户如果同意的话,我们就可以将“卖饮料”分割为“卖单一饮料”和“卖多种饮料”,然后将后者推迟到下个周期发布:
用户故事        故事点
卖单一饮料        2
取消购买        2
输入管理密码    1
补充饮料        3
取出钱箱里的钱        1
安全警报        2
打印月销售文本报表        2
总计        13

现在还剩0.5个故事点,我们再考虑一下“安全警报”。假设本来这个故事是要同时触发本机上的警报,跟通知附近的一个警察局的。如果现在我们只是触发本机的警报,那所花的故事点就可以从2减到1了。于是在客户同意的情况下,我们将“安全警报”分割为“本机安全警报”和“通知警察”,然后将后者推迟到下个发布:
用户故事        故事点
卖单一饮料        2
取消购买        2
输入管理密码         1
补充饮料        3
取出钱箱里的钱        1
本机安全警报        1
打印月销售文本报表        2
总计        12

现在我们总计有12个故事点要做了(<=12.5)。上面这个筛选在本次发布的用户故事的过程,叫“发布计划编制”。

增加开发人员来满足发布期限

在上面的例子中,我们以推迟部分用户故事到下个发布周期的办法来解决问题。这种“控制开发范围”通常是最好的解决办法。不过,这种解决办法实施不了的情况下,那你就只好保留所有的用户故事,然后增加更多的开发人员了。在这个例子中,假定我们需要“n”个开发人员,才能在50天内完成17个故事点。50÷10×2.5×n÷2.算出来,n=2.7,我们需要3个开发人员,也就是多加一个开发人员进来。不过注意:
团队人数加倍并不等于开发周期的减半。它可能只会缩短1/3。如果团队超过10个人的话,增加更多的人员可能反而会延缓项目的进度。
而且项目开发周期越长,团队内的成员对整个项目代码的熟悉度就越少,加上不确定的人员流动,新来人员的业务不熟等其他可能性,这项目会越来越复杂。
总的意思就是,项目人数不能太多,周期不能太长。

根据参考值来掌控项目

每个迭代周期2.5个故事点的这个参考值,只是第一个迭代周期的数据,第二个迭代周期可能会变成2或者3(一般是不会变动得太大)。假设是2的情况下,那对于第三个迭代周期,我们就要将参考值设为2,然后让客户以2为故事点总数来挑选用户故事。
对于大多数项目,参考值很快就会稳定下来(比如在几个迭代周期后)。当这个值稳定下来后,我们就要重新估计开发周期,重新进行“发布计划编制”了。如果这个参考值告诉我们,我们每个迭代周期可以做3个故事点的话,我们就要让客户挑选更多的用户故事放在这次的发布计划中。相反如果这个参考值是2的话,我们就要让客户减少用户故事(需要的话可以分割一些用户故事),如果团队人员还不多的话,可以增加更多的开发人员。

这是项目的初始阶段绝对要注意的。

发布计划编制,估算每个用户故事时要考虑哪些细节,忽略哪些细节?

在项目初始,我们要找出这个发布周期内所有主要的用户故事,评估每个故事的故事点。可是要怎么评估里面的细节呢?比如对于“卖饮料”, “卖饮料”这个简单的标题,省略了很多的细节:用户会投入什么样的钱?纸币可以吗?人民币可以吗?按钮的灯的亮度要多少?可不可以多个按钮对应一种饮料?按钮被按下以后,要不要变暗?找零钱是不是全部找10分的面额?
我们是不是要考虑上面所有的细节?对于按钮灯的亮度,我们就不用考虑了,它对我们的工作量没影响。不过,零钱的面额就对我们的工作量很有影响,我们要认真考虑一下(找一堆10分的零钱就很容易实现;如果要尽量减少零钱的个数就比较麻烦了)。处理不同币种也要考虑。
一般情况,我们不用太担心会漏过什么细节。对于每个用户故事,只要考虑一些“重要”问题就行了。当然,这里面的“重要”,就要根据经验以及客户的观点来决定了。

如果我们不好估算的话怎么做

如果我们觉得,这个用户故事不好估算,那可能的原因就是:

1.  这个用户故事太大。这种情况我们就可以将这个用户故事分割出若干个新的用户故事,比如:
将“卖饮料”分割出:
1:显示总投入金额。
2:金额够买的饮料对应的按钮灯亮起来。
3:按下亮灯的按钮,可以买到对应的饮料。
2.  我们之前从没开发过自动售货机的程序。因此,我们不知道开发这样的程序有多复杂。这样的话,我们就要做一些实验了,比如做一个让售货机找钱的小程序。这种试验就叫“spike”(翻译不出来)。

迭代周期内的计划编制

对于这个迭代周期内选择的所有用户故事,不像在发布计划编制那样,只是考虑一些重要的细节,现在我们要从客户那里调查到所有的细节。比如对于“卖饮料”,我们可能会在白板上画出用户交互的草图,然后跟客户一起讨论:
这是一台自动售货机……
用户投入硬币……
假设他投入的是50分,而价格是40分,那么按钮就会亮起(别忘了我们现在做的只卖单一饮料)
用户按一个亮起的按钮,一罐饮料会掉到售货机的出口
找零钱……

在跟客户详细讨论完,了解了足够的细节以后,我们才发现,事实上这个用户故事“卖饮料(只卖单一的)”的故事点远远比我们预计的要麻烦,这时候应该类似前面的发布计划编制那样,1、分割出小的用户故事,挑出一些放在下一个迭代周期内;或者2、挑出这个迭代周期内的一些用户故事放在下一个迭代周期。反之,如果发现这个用户故事比我们想像的还要简单,那我们就要增加更多的用户故事到这个迭代周期内。

用户故事只是跟用户交流的开始,而不是全部

假想现在已经从客户那边得到足够详细的需求了,我们可以开始实现了。注意,我们不用把所有用户提供的细节都记录下来。为什么呢?假设以后,你有点忘记用户故事,而客户又在你旁边,你是直接问客户,还是去找看需求文档找到你要的东西?当然是直接问客户了。客户可以提示更准确,更完整的需求给你。特别要注意的是,以后只要你一完成一个用户故事,你就要让客户看一下,或者实际的操作一下,因为客户对已经做的的东西了解得越多,那他就可以提供越准确越完整的需求。
用户挑选完用户故事以后,在之后的两个星期内,我们就要将这些用户故事逐个完成。每个用户故事我们都会设计结构,编码,测试等等。每做完一个用户故事,我们都要让客户验证一下系统是不是他所想的那样。

在这两个星期内,如果我们提早完成了用户故事,我们就要让客户挑更多的用户故事。相反的,如果我们不能及时完成,我们就要让客户知道当前的进度。

总结
我觉得这章的内容跟其他的软件工程书一样,看看,参考参考,具体的情况还是要具体的分析,不过这里面的用户故事(user story)跟故事卡片的概念就很不错,可以引用。

Search
最新敏捷认证课 ~ 火热报名中
5月18-19日
Leading SAFe领导大规模敏捷认证课
Eric & Scott 授课
5月18-19日
专业Scrum Master (PSM I) 认证公开课
丁志润 Derek Ding 授课
5月25-26日
Scrum Master (CSM) 认证课
Lance Zhang 授课
6月22-23日
Scrum Master (CSM) 认证课
Scott Dunn & Eric Liao授课
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