敏捷中应对干扰的七种方法

 

最近在infoq上面有一篇翻译的文章，关于如何应对敏捷中的干扰的

http://www.infoq.com/cn/news/2012/02/options-handling-interruptions

 

我也翻译了里面提到的文章的内容，翻译的不太好，但是意思还是能明白的

 

———————————–I am a seperator———————————————————

在Scrum和其他敏捷方法中对付“干扰”的方式

3年前我们写了一篇关于如何对付“干扰”的简文，在那篇简文中，我们叙述了对付干扰的四种方法。下面我再详细地描述那四种方法，并另外增加三种，更系统化地描述如何对付干扰。

方法一：严格地遵守Scrum

Scrum的规则已经很明确：如果不是团队的Sprint工作，那就不应该去做。从团队开始按照Sprint计划会议的计划投入工作，到Sprint演示会议结束，团队都需要避免被干扰影响。如果一个干扰的确足够紧急，以至对团队在Sprint中的注意力产生影响，那可以取消进行中的Sprint。但是，这是一个非常极端的结果，因为他违背了团队对Sprint的承诺。

 

Scrum方法是基于这样一个理念的：Scrum是一个用于暴露组织中的问题和障碍的制度。痛苦吧！在被干扰的情况下，Scrum会对组织说“这是不好的行为！改正引起这么多干扰的行为吧，不要试图掩盖这些干扰”。

打个比方，很多团队面对维护工作的干扰。在Scrum中，为了对付这些干扰迫使团队和组织找出问题的根源并解决他：如果团队开发的软件产生过多的缺陷，那么就需要改变；如果团队开发的软件难以使用，那么就需要改变；如果团队开发的软件没有适合的用户文档，那么就需要改变。但是这些改变都打破了Scrum规则定义的Sprint安全。

方法二：预留处理干扰的时间

这个方法基于这样的条件：处理干扰的时间是“稳定”的。如果这样，团队可以合理地预留一定百分比的时间用于处理干扰，可以通过跟踪干扰发生的时间和用于处理干扰的时长去判断这种方法是否合适。

在一个团队中使用这种方法，有两种途径去分配处理干扰的时间：每个人每天都预留一定的时间去处理干扰，或者团队中的一到两个人用全部的时间去专门负责处理干扰。如果实际用于处理干扰的时间少于预算的时间，那么剩余的时间必须小心使用。通常，最好把剩余的时间用于处理干扰产生的根源。例如，如果一个成员专门负责处理自缺陷报告的干扰，那么这个成员可以把空余的时间用于处理以往更底层的严重缺陷。

团队分配用于处理干扰的时间不应该超出预计时间，否则团队在迭代开始的承诺就不是“真正的”承诺了。

这个方法是目前为止在迭代中处理缺陷的最为体系化的方法。

方法三：变更的可见协商

另外一种通常用于处理干扰的方法是“荧光卡片”方法，这个方法需要利益相关者对干扰的影响进行协商。每当利益相关者向团队提出一个干扰需求，ScrumMaster/Coach/流程调解人把需求写到荧光卡片上，这样是为了把干扰需求跟当前迭代的其他任务进行区分。然后ScrumMaster会要求团队做一个任务分解，并且像正常流程那样估算工作量。接着，提出要求的人会跟其他利益相关者（Product Owner/Growth Facilitator）进行协商，决定应该移除哪些工作，好让位给新的工作。这个过程，好的地方在于利弊可见，不好的地方在于，他不能让团队的承诺长期地受信任。

 

使用这个方法还需要以下几样东西：

1、 一个用于跟踪任务的任务看板（不是电子看板），可见性让变更更加直接，并且利益相关者都被包含在同一个物理空间内，而电子工具会让事情变得复杂，而且会导致一些重要的相关者无法获知变更。

2、团队必须善于估算。“善于”是指“准确”和“快速”。如果一个团队需要1个半小时做一个准确的估算，那这本身就是一个很大的干扰！一个团队应该可以研究干扰后，在10分钟内分解任务并形成一个合理的工作量估算。不要忘记，做这些工作需要工作切换，因此对于团队来说需要额外的时间。

3、最后，也可能是最重要的，所有相关者都需要同意并认识到，这个方法被用于处理干扰后，团队不能负责他们的承诺！！！我再怎么强调这一点都不为过！

 

方法四：拆分团队

这个方法顾名思义：通过拆分出一个独立的支撑团队去处理干扰。这个团队的技术能力越强，他们就获得越大的授权去修改代码/数据库/等…，他们就能更有效地保护敏捷团队。

在某种程度上，这是一个好方法，因为很容易得出处理干扰的成本：支撑团队的成本是多少？如果这个成本在不断增长，那说明开发团队开发出来的产品越来越难以维护了。

如果使用这个方法，请谨记不要让团队成员在开发团队和支撑团队间轮换，因为这样对两个团队的团队建设都有不好的影响。

（还有一个激进一点的附加措施：把开发团队的薪酬跟支撑团队的成本挂钩。为了让这个措施顺利进行，你需要直接跟开发团队说明：每当一个支撑团队的成员因为产品/系统质量的上升而被解雇，那被解雇的成员的工资将会加到开发团队成员的身上。PS，我还没看到哪个团队使用这种措施 - 它只是理论上可行）

方法五：采用极短的周期

一个不太普遍，但蛮有趣的处理干扰的方法是：采用非常短的迭代周期。通过采用尽量短的迭代，以至可以经常在某些人焦躁不安之前把干扰处理掉。这样做可能比较折腾，但是不失为一个让团队和公司明白干扰的巨大代价的方法。

有一个基于度量去决定周期长度的简单方法：选择一个“自然”周期（比如一周或两周）并且跟踪几个周期中干扰发生的个数，和响应干扰的急迫程度。几个周期过后，团队就可以判断，设置多长的周期，可以在比干扰期望频率更短的时间内开始并完成一个迭代。

举个例子，我的团队发现，他们通常需要在3到4天内处理完一个干扰，还有少数更紧急的干扰。他们决定采用2天的迭代周期，那么平均3天就可以处理完一个干扰。（干扰在迭代的中间发生，它会被放到backlog的前面，下一个迭代开始处理这个干扰，这个过程总的时间是3天）

方法六：维持现状/继续痛苦

继续目前处理干扰的方法，这不一定是个错误。可能有些人感到苦不堪言，但有些人可能会真的享受危机和不断的变更。实际上，这可能是你公司的文化，或者在特定行业中的特殊做法。不代表你们不能敏捷，可能这只是表明你们在用团队效率去交换另外的利益。重要的是，如果你们决定保持现状，那么你需要把这种牺牲透明化，告诉团队中的所有人，为什么你们需要这样做。

方法七：完成速率Option Seven: Commitment Velocity

最复杂的一种方法是基于度量一种特殊的速率：“完成速率”。这个方法可以既保证在迭代中处理干扰，也可以让团队完成迭代承诺。简单来说，完成速率是一个团队Sprint燃尽图的最低斜率。

举个例子，如果团队在Sprint 1的开始阶段有240个功能点，但是，其中因为干扰的原因，在迭代结束的时候还有40个功能点未能完成，那么团队的“完成速率（斜率）”就是 240 – 40 = 200。在他们的下一个Sprint计划会议，他们在迭代计划中只能允许最多有200个功能点。然后团队再继续他们的第二个Sprint，由于干扰的原因，他们又未能完成迭代。也许第二个sprint有195个功能点（<200），结束时还剩余10个功能点未完成，那他们新的完成速率就是 195 – 10 = 185。他们再继续做第三个迭代，这次他们完成了所有的工作。

也许团队会取一个平均值 – 如果第三个迭代他们完成了200个功能点，那么平均值就是195（200，285，200），这不是完成速率。明显地，平均值的意思是说团队只有50%的机会能完成所有的工作。

反而，团队会在第四个Sprint中维持185的完成速率。根据law of large numbers 和 central limit theorem,，随着团队在越来越多的Sprint中使用完成速率的方法，最终他们完成迭代的能力（就算有干扰）肯定会越来越接近100%。

选择一种方法Selecting an Option

最后，选择这些方法最重要的是实际运用这些方法，并抱着用敏捷的学习精神，选择一个方法并坚持，直到你知道它是否适合你为止。

此外，还有一些其他的事情需要考虑：

如果你想在公司内做一次大的改进，那么我建议你选择方法一（严格遵守Scrum）或者方法七（完成速率）。这两种方法都是都是对团队施加改进的压力。

如果没有很强的执行力去推行敏捷，那么或许方法二（预留处理干扰的时间），方法四（拆分团队）和方法五（短迭代）是好的选择。

如果有强的执行力支持，但是你又不想做太大的改革，你可以考虑方法三（可见协商）。

当然，方法六（保持现状）是最容易的… 尽管我不建议这样做！

敏捷需要系统的变化去鼓励持续改进，其他所有的方法都遵循这个原则。