如何处理scrum中未完成的用户故事?

你听过柏林新建机场的故事吗?机场原定2006年开工,2007年启用,但由于机场建设过程中到处出现施工和安全问题,补东墙漏西墙,导致工期一拖再拖,预算一涨再涨,以至于2019年了还没开张,预计开业时间已经被拖到了2020年10月。

无论是建机场还是开发软件,人们往往会低估未完成的工作量。即便没有低估,也会尽可能以能安抚老板客户的方式回复,例如“我已经完成95%了”毕竟,这种粉饰太平的回答总好过“这个复杂的任务,我大概只完成了一半”、“是的,我低估了完成这项任务所需的工作量”、“老实说,我也不知道还会不会有其他不可预见的问题出现”这些回复。

虽然这种“即将完工状态”听起来很好,但它会影响整个项目状态的透明度。这也是为什么在敏捷开发—如scrum过程中,我们只会关注彻底完成的功能。完成与否只能二选一。在scrum演示会中,我们会查看每个用户故事,根据所有的验收标准和团队制定的DoD(完成的定义)进行审查。只有在所有工作完成、所有的非功能性需求(NFR)和其他部分的DoD满足的情况下,用户故事才能被认定为完成并结束开发。

在敏捷软件开发中,功能的状态是非此即彼的,即要么完成,要么未完成——不存在任何中间状态。

以工作流节点、业务规则或数据变化等作为依据来拆解用户故事,并将拆解后的用户故事放到每个sprint中完成,但被定义的范围和质量必须要彻底完工。因此不要因为用户故事A已经快要完工,就让团队转而开始其他任务,与此同时在backlog中添加一个新的“完成用户故事A的收尾工作”的故事。
这就意味着我们需要知道如何处理未完成的功能。我参与过的很多团队都对此进行过很激烈的讨论。如果你只强调故事点,开发团队可能觉得遭遇了不公平待遇,因为他们已经完成了“95%的工作”(详见上文),但并没有得到应有的认可和肯定。尤其是在管理层对scrum和故事点的概念理解有偏差,仅仅通过scrum团队的开发速度来评价团队表现的情况下,针对这一问题的讨论则会愈演愈烈。
所以,到底应该怎么处理scrum中未完成的用户故事呢?
首先,我认为:不要太在意这个问题。因为团队没能完成用户故事的情况只是个例,不会经常发生。因此,无论采取什么样的解决方案,都不应该对团队的任何指标产生重大影响。但如果团队经常出现此类问题,那么你实际上应该解决的是为何团队经常不能完工这一问题,而不是试图通过接受团队产出的半成品来妥协。

总之,不要过分在意这种特殊的情况!

其次,我认为:未完成的用户故事不应该在演示会议上展示。它们应该被移到Product Backlog的顶部重新评估规划,而不是自动进入下个sprint的backlog。因此,没有故事点会为未完成的用户故事标记“完成”。在下一次规划会议前,PO(在与开发人员沟通后)决定是否需要花更多的时间在这个未完成的用户故事上。如果答案是“需要”,那么在下一次的规划会议上,这个用户故事就会被移到Sprint Backlog中,且保持原始估算值。即便开发人员自称功能已经完成了90%,我们也能根据所有的故事点预估当前sprint的开发速度。正如前面所说,未完成的用户故事应该是个例,因此从长远来看,团队的速率应该维持在平稳水平。

作者:Felix Braun
翻译/校对:Worktile
文章首发于Worktile官方博客,转载请注明出处。