第三章 根除低下的效率

    动起来

    苏雷什的软件小组在他们的日程表中落下了。对于服务项目来说这是个坏消息——或者可以说对所有的项目工程。需要周末加班吗？不。对这不中用的团队要惩戒一下吗？不。要单件流及核对清单吗？是的。

    苏雷什小组成员的构成没什么特别——几个项目经理，包括一个服务开发工程师、一群开发人员及一班数量相当的测试人员。项目经理编写规范书，开发人员编写代码，测试人员进行测试。这个小组采用类似的Scrum冲刺法，按优先级别安排功能开发备忘录。

    遗憾的是，项目经理建立规范书的速度远快于其所能被开发的速度。在黎明到来之前他们为修改或删节规范书浪费了大量时间与精力。当开发人员与测试人员遇到障碍的时候，他们从一项功能转换到另一项功能。没一次是同步进行的。也没完成任何功能。工作日程不断延后。痛定思痛，所有苏雷什的小组成员只是考虑了相关人员都能顺利完工的情况。

    尽管，苏雷什的团队采用的是类似Scrum的冲刺法，但他们没使用单件流。他们没有将小组分成一个个跨工种的小团队，而是将所有小团队集中在一起一次只进行一项功能开发，直到这项功能完成。他们甚至没有使用核对清单注明已完成的工作。悲剧了。

    只要他们分为不同的团队，一次只对一项功能编写规范书，写代码，或测试（有时称为功能小组），并列出核对清单，标明什么已经完成了。这样，工作进展就有戏了。单件流解决了阻碍工作进展的问题，因为每个人都在处理一个相同的问题。核对清单使团队变得更可靠，并激励着他们协同作战，一起完成工作并保持专注，而不是出错了从头再来。现在，这个团队不再为上下文切换而浪费时间，并且可以明确，完成一项功能到底要多长时间，赢得可信的工作日程表以及高质量的产品及服务。

    作者注：很多人想知道当功能小组的项目经理完成规范书后，或是开发人员完成代码编写后他们该干什么。对于项目经理，有两种选择——成为多个功能小组的一部分或参与到开发人员或测试人员中解决问题及进行程序开发。对于开发人员来说，与测试人员协同进行工具测试、自动化测试、单元测试及组件测试。

    还有一个更明智的选择，是由微软的一个前雇员——科里·拉扎斯发明的。他称为Scrumban，你可以在由他与伯尼·汤普逊创建的“精益软件工程”网站上找到：（leansoftwareengineeringcom/ksse/scrumban/）。

    两手武器

    现在，你手握利器——单件流及核对清单。有了这两个功能强大、意义非凡又简单的方法（可惜并未充分利用），就能进行有效的工作进程管理，提供高质量的软件。

    单件流与核对清单可能应用于个人、小团队及大型部门。这没什么可争议的，只要用得有的放矢。经过几年的实施案例下来，历史会给其功效以明证。

    是的，你可以在草根基层间掀起一次单件流与核对清单的应用狂潮，但是单纯这样想似乎有点过了。或许，你应该只是择机而用。享受你过往的时光，享受你的成果不断提升的喜悦吧，人生最惬意的事莫过于简约与本真。

    作者注：詹姆斯·维斯基有一篇有趣的博客提供了一些核对清单作参考，文章名为：“核对单？我们不需要擦屁股用的核对清单！”