检查列表的威力

最近，在《New Yorker》的一篇文章中，Atul Gawande 提到了Peter Pronovost 医生利用低技术含量的检查列表，降低医院重症监护病房感染率的研究。Peter Pronovost 医生找出了那些最可能引起感染的步骤，并为每个步骤定义了简单的检查列表。有了这些列表以后，大大降低了病人在各步骤中受感染可能性。

他并不是为所有的事情来制定完整的检查列表，而只是针对解决单一问题而开列清单……开始使用这一列表后，Pronovost 让在其重症监护病房工作的护士对医生的工作过程进行了一个月的观察，并记录他们每完成一步需要多长时间。最后发现，在诊疗过程中至少被略过一个诊疗步骤的病人多于三分之一。

在接下来的一个月，他和他的团队一起说服院方，授权护士依据检查列表来制止医生跳过任何步骤，也要求护士每天就“是否应该删除某些条目？”征求他们的意见，以保证那些不必要的步骤被及时剔除。这是革命性的……如果医生不按照检查列表中的每一步执行，在院方的支持下，护士有权干涉。

Pronovost 与其同事一起跟踪了一年多的时间。结果简直难以置信：十天的导管感染率从 11％降到了零。随后，他们又跟踪了病人十五个月。在整个过程中，只有两例导管感染率发生。他们通过计算得出，在这样的医院里，检查列表防止了 53 例感染和 8 例死亡的发生，节省成本两百万美金。

看到这一成功以后，ICU 的人开始了自管理的过程：

研究人员发现，仅仅让 ICU 的医护人员列出每天他们想到并应该做的检查列表，这就可以改善治疗的连续性，并在几星期内，病人在 ICU 的时间就减少了一半。

但医护人员都是经过专业培养的专业人员，为什么如此简单的列表却收到这样明显的成效呢？

Pronovost 注意到：检查列表有两点好处。首先，他们有利于提醒，特别是那些在处理病人紧急事件中很容易被忽视的小事儿；其次，在复杂的治疗过程中，使细小却必要的步骤更为清晰明了。Pronovost 很惊奇地发现：即使是有丰富经验的医生也会忘记某些特定预防措施的重要性。

多疑的读者可能注意到了，这里只提到了一个医院的状况而已。很可能是因为工作环境的特殊性吧？Pronovost 把他的列表用于整个密歇根州很多医院的 ICU，包括在底特律的一些最差的医院。其结果做为一项研究发表在《New England Journal of Medicine》上：

在项目的前三个月，密歇根州 ICU 的感染率下降了 66％。其中，有代表性的 ICU（包括在 Sinai-Grace 医院的）的感染率从原来的四分之一下减到了零。密歇根州的感染率降得如此之低，以至于它的普通 ICU 做得都比全国 90% 的 ICU 好。在 Keystone Initiative 的前十八个月，节约了 1.75 亿美元成本，挽救了超过 1500 条生命。就因为这个看上去笨拙的检查列表，这种成功已经保持了四年了。

但这与软件开发有什么关系呢？敏捷开发团队试图用恰好够用的过程，在合适的时机，按照预期交付高质量的软件。那么接下来的问题就是：有没有类似于 Pronovost 医生所给出的、简单的检查列表，可以适用到软件开发过程呢？

Kent Beck 最初提出的十二个 XP 实践看起来象是一个检查列表，但并不完全是。主要目的是识别出短小且简单的列表，用于检查开发过程中易于被忽略、并且会给团队和系统带来问题的部分环节。例如，当被问及在他的日常工作中使用什么样的检查列表时，Kent 说道：

我用“笨而短小的检查列表”来做我的 IDE 无法直接支持的重构。例如，把一个 field 移动到一个 component 中：

1. 将所有这个 field 的 setter 代码修改为 component 的 setter 方法；
2. 修改所有使用 field 的 setter 方法来访问它的代码，变为使用 component 的 setter 方法来访问它；
3. 删除这个 field 的声明；
4. 使其尽可能的简单化。

当然，简单的检查列表无法解决将敏捷引入组织所面临的棘手问题。但敏捷社区可能从识别和共享产出大于投入的检查列表中获益。在日常工作中，你用什么“笨而短小的检查列表”了吗？