如何处理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敏捷博客

欢迎访问交流更多关于技术及协做的问题。

文章转载请注明出处。