如何处理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的开发速度。正如前面所说，未完成的用户故事应该是个例，因此从长远来看，团队的速率应该维持在平稳水平。

Worktile官网：www.worktile.com

内容整理：Worktile

文章首发于「Worktile官方博客」，转载请注明来源。