Scrum框架下如何管理未完成或部分完成的工作合作伙伴认证资质关注我们

在Scrum的教学中，经常会被问到这样的问题：如何处理Sprint未完成的工作？听到最多的最直接的一个回答：“挪到下一个迭代做”。
回答这个问题前，我们首先定义一下“未完成的或部分完成的工作(unfinished work)”的范畴：

（1）没有满足当前Sprint完成的定义（DoD）标准的PBI或产品增量

（2）某些PBI的验收标准（AC）或业务满意条件没有满足约定的范围。这里我们姑且不讨论 Sprit的 DoD 和理想的发布DoD的gap, 有时我们也把这个gap称为未完成的工作（undone work）, 即Sprint DoD 以外的做到真正潜在可发布的未完成的工作，这里我们不涉及如何加强或放大完成的定义（DoD），以免混淆。  

本文中，我们把在Sprint中未完成的或部分完成的工作，统一归属为“迭代未完成的工作”，方便我们讨论。

先从两个维度来分析:（1）在迭代中如何管理以避免未完成工作的滞后和堆集？（2）迭代结束分析未完成的工作是如何造成的？ 然后再回答最初的问题，如何在一个迭代结束后处理未完成的工作。

01

 在迭代中如何管理工作流 （work flow）以避免未完成的工作堆集？

Daily Scrum（站会）的目的就是检视和调整团队每天的工作（replan or planning）, ScrumMaster可以问团队这样的问题：我们Sprint工作的进度和进展如何？团队现在手上有几个PBI或用户故事已“打开”了？哪些用户故事还没有完成？有哪些任务需要今天规划可以加速用户故事的“关闭？有没有阻碍或障碍？Sprint 的燃尽图是否翘的很高超过过我们约定的警戒线？我们离迭代的目标有多远？这些问题有助于提高团队的觉察能力，深入思考和加强团队协作，把问题暴露出来，并且可视化。团队开始越来越关注Sprint的目标和成果，有意加强协作，多数情况下团队内部可以自己搞定“报”出来的多数问题。站会暴露的团队外部的阻碍，有ScrumMaster去跟踪和移除。团队遵循这样的工作原则“start finishing （开始关闭）， stop starting（停止打开）”，控制在制品（WIP）的数量，越少越好。 有些高效的团队甚至约定在Sprint中一次只专注一个PBI (Swarming), 保证一个PBI 干干净净的完成，严格拒绝迭代结束出现大量的“半成品”， 处于“未完成“的状态，这样的情形令PO 很尴尬。

如果一个Sprint的实际进度与理想的Sprint燃尽图参照，落后20% 以上，Scrum团队要启动一个Scrum紧急情况处理（emergency procedure）的流程，这个想法来自Scrum的发明人Jeff 在越战中 Fighter Aircraft 一个操作流程， 如下图。

类比地，Scrum 紧急情况处理流程如下: (do only as much as necessary)

1. 改变工作方式，激发创新思维（Change the way the team does the work. Do something different）.
2. 寻求其他团队的帮助（Get help, usually by offloading backlog to someone else）.
3. 减少范围（Reduce scope）.
4. 终止Sprint 并重新规划（Abort the Sprint and replan）.
5. 及时通知管理层和干系人对发布日期的影响（Inform management how the emergency affects release dates）.

ScrumMaster引导团队首先要把前面的措施1-2步走一遍， 第3步PO参与进来，最大化当前Sprint团队工作的价值。当然PO也有权利把这个Sprint 终止，这类似于精益的概念stop the line，比如团队碰到大的技术瓶颈，迭代的目标无效等。迭代终止后，团队可能会开回顾会，启动一个新的Sprint, 但是要保证Sprint的长度与组织中做同一产品的其他团队的迭代节奏和长度对齐；第5步，PO线下与干系人及时沟通，把他们对当前Sprint的期望值降下来(reset expectation)，比如重新规划和更新发布日期。对于新团队和一般的团队， ScrumMaster 要确保这个Scrum 紧急情况处理流程实施到位。

02

迭代未完成的工作是如何造成的？

首先我们不要轻易地忽视或“放过”这些未完成的工作，要把它作为一次学习的机会。ScrumMaster抓住这个教练的时机, 在评审会上讨论产品的哪些需求未完成和简要的解释， 在回顾会上大家分析是什么原因导致这样的结果，如何避免类似问题重演。可能的原因有：
• 团队在Sprint计划会议上规划所有的工作，任务分配到人头，计划一次，一个萝卜一个坑
• Sprint中团队在跑小瀑布，测试工作积压在Sprint后期，测试压力大，全手工测试，自动化测试少
• 迭代中，习惯单兵作战，Sprint中缺乏协作, 开发和测试分家，各干各的
• 紧急的需求出现（Emergent requirements）
• 技术问题的壁垒（Technical problems）
• 关键人员的流失或技能的缺失／（Loss of critical people or capabilities）
• 团队盲目乐观，过于高估，忽略团队在迭代的容量（Overestimated capacity） 
• 计划外的打断（Unplanned interruptions）
• 先前未完成的工作对当前迭代的拖累（Previous work not Done） 
• PO 改变迭代中的工作内容（Product Owner changes backlog） 
• 管理层的干预（Management interference）……

总之，充分利用回顾会，大家一起复盘，一起学习成长，会变得更好，不是简单的“放过”或 “放下”，而是持续改进，改善(kaizen)的心态。
在迭代中这个未完成或部分完成的需求，在迭代结束后如何处理呢？是不是一定在下一个迭代接着做， 如果这样处理的话，与瀑布式有什么本质不同？

03

迭代结束如何处理未完成的工作？

对于这个未完成的工作如何处理，是不是非要在下一个迭代继续做？答案是“不一定”。正确的流程是把这个未完成的PBI重新放回在产品待办列表中。PO会做进一步的评估，也可能降低优先级，有时候因为市场发布周期短的压力，或者解决方案的可行性，PO会考虑值不值得花费多余的超过预期的时间去投资这些功能和特性，不排除PO做出判断，果断放弃这些功能。
从精益思想看， 部分完成的工作也是浪费，下次开发人员捡起来这些工作需要花费更多的时间回忆学习， 所以PO有时候会决定在下一个迭代继续做这个未完成的PBI 。那问题来了，我们是重写一个PBI还是就延用原来的PBI呢？这需要PO来快速重新考量，最简单的一个判断标准是：团队看了这个需求是不是会联想到“我们已经做过这个PBI了，如果答案是yes, PO最好重新写一个新的需求，以避免团队误解。

需要澄清的是，在我们计算团队迭代交付速率时，这个未完成的PBI（假如是用户故事的形式呈现） 的相对估算值，故事点计为零。只有Binary 0或1，要么完成，要么未完成， 没有中间状态。
最后一个问题，这个在产品待办列表中未完成的或以新的PBI呈现的需求，是不是需要重新估算还是继续保留原来的故事点估值呢？我们建议要重新估算，原因如下：
敏捷估算是相对的，估算仅仅是最好的猜测，随着团队的知识经验和能力的提升，可以重新估算，估算不是“一锤定音”的买卖。对于这个未完成的PBI，团队通过上个迭代有了全新的认识和理解，敏捷是鼓励和允许重新估算的。重新估算是对新的PBI工作范围和业务条件进一步的评估和学习，以降低风险和提升完成率。如果不重新估算，继续保持原来的估算结果，团队可能会take 上个迭代的credit,　团队的实际速率不准确，速率不准， 这样也会给干系人和PO 一个错觉——团队交付很快。这个速率实际上不符合团队的现状，这样的速率是危险的，会误导PO对发布计划的预测和管理。一句话， 速率是用来做发布管理的， 见下图。  

小结

1. 首先要关注和管理未完成的工作出现和堆集，站会就是一个检视和调整我们每天工作计划的机会。
2. Scrum紧急情况处理流程给ScrumMaster提供了一个可操作的流程和模式化的语言（pattern）去引导和提醒团队，让Scrum团队自我管理Sprint的风险，PO管理干系人对当前Sprint的期望值。
3. Scrum是讲究纪律的，比如“时间盒”的概念是Scrum特有的， 不要忽略或忽视未完成的工作，也不要简单地把未完成的工作“顺延”到下一个迭代继续做，而是作为一次学习和改进的机会，在回顾会上挖掘原因，避免重复就范，久而久之，团队的洞察力和责任感会逐渐提升。
4. 如何处理未完成的PBI, 一切以价值为导向PO来重新评估，准确地度量团队的交付速率，稳定的交付速率对PO对发布管理和对干系人的预期管理非常重要。
5. 可以想象，如果没有一个合格称职的ScrumMaster, 引导和反思这些“未完成的工作”就很难落地和持续，从另一个维度也印证了ScrumMaster这个角色的重要性。

作者：Jim Wang王军  

写于2020年6月18日疫情期间  

参考资料：

（1）A Scrum Book: The Spirit of the Game 1st Edition， by Jeff Sutherland, James O. Coplien,  Kiro Harada, Joseph Yoder, June Kim, Jens Østergaard etc.

（2）Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin.