敏捷团队应对打扰的七种方法

每个团队都必然会遇到工作被干扰的情况，如果不能合理应对，那么很可能会影响到团队的交付能力。最近，在 Agile Advice 网站上， Mishkin Berteig 发表了一篇文章，讲述了当 Scrum 或者其他一些采用迭代方式的敏捷团队遇到工作被干扰的情况时，可能可以采用的七种应对方法。

1. 严格遵循 Scrum
2. 安排特定的“干扰”时间段
3. 让变更商谈过程变得透明
4. 拆分团队
5. 超短的交付周期
6. 维持现状，任劳任怨
7. 承诺速率 (Commitment Velocity)

Ken Schwaber 和 Jeff Sutherland 在 Scrum 指南中明确地表示，团队要想获得成功，就必须严格遵循 Scrum。

Scrum 的角色、工件、事件和规则是不可变的。虽然只实施部分的 Scrum 是可能的，但这样就不是 Scrum 了。

因此，Mishkin 认为他的上述建议是对 Scrum 团队的一个开放式的补充。

Scrum 方法论所秉承的基本理念是形成一套发现组织内的问题和障碍的体系……改掉那些导致工作被干扰的行为，而不是试图去寻找兼顾应对干扰的一石二鸟之法。

现实中，很多敏捷团队在使用混合方式。而 Mishkinr 的文章正好指导团队利用一定比例的时间或者人员来应对“不速之客”。

……有两种分配时间的方式：每天特定时间全军上阵，或者轮流指派一到两个人专门全天候应对被打扰的情况……原则上说，挤出来的这点宝贵时间一定要用在刀刃上，最好拔除那些诱发干扰的根源。

Mishkin 文中所述的另一个应对之策是使变更商谈过程更加透明，此处他援引了“荧光卡片 (fluorescent note card)”法。

……无论何时，若有利益关系人想要打断当前周期内的工作……就把他的需求写在一张颜色鲜艳的卡片上，以便于区分团队当前工作周期内的其它任务。随后，提需求的利益关系人就得和其他利益关系人商谈……看看迭代中哪些任务可以移出去，为新任务腾地儿。

此方法和 XP 里应对干扰的方法很类似， James Shore 和 Shane Warden 在他们的敏捷开发的艺术：迭代计划一文中就曾提及此法。

换句话说，如果你要加个两个点的故事到计划里，势必要拿出个两个点的故事来交换。并且，你只可以替换那些尚未开始做的故事。

Mishkin 看来，最具综合性的是承诺速率度量法，他将其解释为一个团队燃尽图的“最小历史斜率 (minimum historical slope)”。他阐述道，迭代团队都应该降低每次迭代的期望速率，以切合他们上个迭代（而不是平均）所完成的实际点数。

……随着团队使用承诺速率度量法完成了越来越多的 Sprint，最终他们的能力将与他们的承诺相吻合，即使时有“不速之客”，也能几近闲庭信步，应对自如。

其它可选方案还有超短的交付周期。InfoQ 网站上有一段 2008 年敏捷大会的演讲，详尽涵盖了这一内容。还有就是任劳任怨、俯首甘为孺子牛，虽然这并不为作者所推崇。

……如果你选择了维持现状，任劳任怨，那么最重要的是向大家展示你权衡利弊的心路历程。明确告诉你团队中的每个人，你为何如此权衡，这么做的好处又在哪里。

如何处理被干扰的方法一直是敏捷社区数年来热议的话题，自 2008 年以至更早，InfoQ 上也发表了诸多相关文章。更多对策和选择可以参见由干扰驱动的开发、应对紧急需求以及应对敏捷项目中的干扰。

关于干扰对团队所造成的影响最恰当的归纳，估计要数 Mark Levison 近期发表的 Scrum Master 系列故事了。

开发团队以外的人往往并不认可团队为了应对干扰所做的努力，尤其是无法理解任务切换要花的时间（如果在做一个复杂的任务，可能需要 20 到 30 分钟才能跳出原来的思维）。

你的团队采用了这些方法中某个来处理干扰吗，或者你是否发现其它什么技术更高效呢，例如看板？

查看英文原文： Seven Options for Handling Interruptions on Agile Teams