Press "Enter" to skip to content

用户故事可以部分完成吗?

cheney 0

如果你的客户同意开着配图里那辆车上路,那你就可以交付一半的用户故事。

理解理论不代表我们都做得到。在实际的项目中,你是否为了体现当前迭代的成果,在知道某些用户故事当前迭代无法完成时,把它拆成Part1(标为完成)和Part2(移到下个迭代)呢?即使没有拆分,把整个故事移到了下个迭代,那你是否按照剩余工作对此故事重新估点呢?

如果你没有这方面的问题,那么恭喜你,可以不用看下去了。

如果你经历过以上的问题,那或许你还没有明白“不能交付半辆车”的真正含义。

举个很简单的例子,如果你的客户在当前迭代结束时,要求你上线这个用户故事所描述的功能。那么显然,完成了的Part1是不能满足要求的。但是客户一般不会这样做,他们往往还是会按照PO设计好的发布计划来要求交付。从而给足了我们拆分Part1&2的“空间”。这样的拆分会立刻带来两个“好处”:

  1. 团队的付出在当前迭代得到了体现,有完成的故事点记录在案了
  2. 当前迭代的团队完成速率会高一些

但是,产品的交付上没有一点点的进展!我们不是要打造一个看起来完成故事点更多的团队,也不是为了提供看起来更完美的状态报告。我们的目的只有一个,那就是尽快地交付可用的增量!客户不会介意你完成了多少,他们只问你完成了没有?

是的,一个迭代的辛苦之后,整个用户故事以未完成的状态移至下个迭代确实令人沮丧。但是团队更有信心完成它了!这么做会导致下个迭代的故事点完成数增高,但也绝对符合一个事实:下个迭代交付了这些故事点。

说到这里你可能明白了,故事点代表可用的增量,它仅在被完成的时间点上整体生效。

好比今天你结婚,突然有了一个老婆/老公,今天之前没有法律效力。不可以有半个老婆/老公,或好像有好像没有。

理解了这一层,我们来看个极端例子。假设第一个迭代(S1)团队做10个故事,每个故事5个故事点,但完成度为0;第二个迭代继续做,完成度依然是0;直到Sn,全部完成了10个故事,50个故事点。那么团队的在Sn的迭代速率为50,在此之前的所有迭代速率为0。虽然平均速率为50/n,但是还有意义吗?是不是很眼熟?

这个例子提供了一个视角来看瀑布和敏捷的区别。那么如何把故事拆多,拆细,且完成标准明晰,从而使每个故事不会被带入下个迭代呢?

下次再聊

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注