第二章 过程改进，没有灵丹妙药

    准备玩橄榄球！

    最后我将讨论的（可能也是被人误解最深的）敏捷方法是Scrum。人们可能把Scrum和极限编程（它实际上不用Scrum）混淆在一起，也可能认为敏捷就等于Scrum（哈？！）。除此之外，Scrum最令人困惑的部分就是下面这些相关的术语了：Scrum大师（Scrum Master）、产品备忘录（Backlog）、burndown图、冲刺（Sprint），甚至包括猪和小鸡——这些足以吓跑任何一位管理者。真是极大的误会啊！

    无论好坏，Scrum是由一个喜欢有趣名字和故事的人发明的。其实施起来既不复杂，也无争议。因此，除了重构和持续集成之外，Scrum是多年来我们内部一直在做的、最接近于敏捷方法的一种实践，并且我们还有一些重大的改进。

    接下去，让我们先来澄清那些令人困惑的术语。“Scrum”是指每天的例会，“Scrum大师”是指功能团队的组织者，“产品备忘录”（backlogs）是一些功能或者工作条目的列表，“实施进程”（burndown）图用于展示剩余的工作，“冲刺”是指小型的里程碑，“猪”和“小鸡”则是指企业家的农场动物（故事很长，但很好笑）。

    这些概念没有一个是创新出来的，但Scrum的确带来了一些大的改进：

    ·Scrum的每日例会组织得非常好，用于收集有用的数据。团队的组织者（Scrum大师）简单地问所有的团队成员3个问题：从昨天到现在完成了哪些工作（并且花费多久时间），现在到明天到来之前准备做什么（并且告知剩余的工作量），阻碍工作进展的问题。

    作者注：跟踪每个任务完成所花费的时间，是我的团队对微软Scrum作的一点小小贡献。通过把这些信息加入到实施进程数据中（还剩下多少工作量），你就可以画出美妙的累积流线图，度量花在进展中的任务和工作上的时间，并且更好地估计团队的生产力。典型情况下，产品团队花在任务上的时间大概为42%，花在沟通上的时间为30%，拿我来说，我花在一起协作的功能团队上的时间有60%之多。

    ·在Scrum会议上收集到的数据输入到一个电子表格或者数据库中。基于这个电子表格，你可以分析花在任务上的时间、完成日期、进展中的工作、计划变更和许多项目问题。这种情况下很流行使用实施进程图——一种展示时间和总剩余工作量之间的动态关系的图表。

    在线资料：冲刺任务清单（SprintBacklogExample.xls，SprintBacklogTemplate.xlt）

    ·Scrum大师是一个独立于团队之外的力量。他甚至最好不是组织中的一员，但这通常不太现实。Scrum大师有权力排除阻碍每日例会进程的因素，保持会议的简短。

    ·功能列表或者时间表称为“产品任务清单”（Product Backlog），而工作条目列表或时间表称为“冲刺任务清单”（Sprint Backlog）。通过分离这两个列表，管理层可以只关注他们想要完成的工作（产品任务清单），而团队则只关注手头的工作（冲刺任务清单）。为了保证所有事情都在正常的轨道上，Scrum大师一般每周跟管理层开一次会（比如每周的主管会议），进行状态更新。

    在线资料：产品任务清单（ProductBacklogExamplexls，ProductBacklogTemplatexlt），冲刺任务清单（SprintBacklogExamplexls，SprintBacklogTemplatexlt）

    ·冲刺作为小型的里程碑，它的时间长度是固定的。当一个特定的时间段用完了，一个冲刺也就结束了。典型情况下，一个冲刺大概30天。

    作者注：写这个专栏6年以来，我在一个团队里采用过1周冲刺、2周冲刺及30天冲刺。现在，我们的团队都采用2周冲刺，这是我最喜欢的。2周的时间正合适，而且无需额外的经费——所有的进展情况可以描绘在一块白板上。但是，对于完成一项重要任务来说，2周有些过长。我现在正打算采用卡班（KanBan）法或一种持续冲刺法，但这又是另一个主题了。

    ·每次冲刺结束后，功能团队会跟管理层一起复审工作（不错的改变，哈？），总结本轮冲刺做得好的地方，以及下轮冲刺需要改进的地方（这总比等上1年或者10年、产品最终出货后再做总结好），然后为下轮冲刺制订计划并重新评估工作条目（改变原先的计划和评估？决不！）。

    通过使用每天、每周或每月的反馈机制，Scrum使团队在一个多变的环境中保持高效的工作，并且富有弹性。通过收集一些关键数据，Scrum使团队和管理层知道团队的运作状况，在问题还没有成为问题之前就把它解决掉。通过分离管理层掌管的功能列表和功能团队掌管的工作条目列表，Scrum使团队实现自我指导，工作更加投入，使团队内的每个成员和团队外的管理层都很有责任感。

    最后你要知道的

    不是所有的敏捷方法都适合于每一个人。很多根本就不适合微软的大型项目。但Scrum、测试驱动开发、重构和持续集成可以被很多微软的团队使用，并且会有显著的效果。结对编程和用户需求描述的适用程度要低一点，但如果条件适宜的话，应用这些方法也能很有效，只要你不是很心急，一下子走得太远，或者强迫你的团队采用敏捷，应用这些方法定会大有收获的。

    作者注：几乎在我任职过的所有地方，我都见到过有管理者强迫工程师改变他们的方法论的情况。这绝对行不通，哪怕像Scrum这样很受大众欢迎的东西。管理者可以建议、支持、资助行为方式的改变，但绝对不要强制。

    如果你想有更多的了解，可在我们的内部网络或者互联网上搜索敏捷方法，同时也请留意关于敏捷方法的课程。如果你的团队方方面面都表现得很出色，那建议你不要做任何改变。但如果你希望看到更高质量，或者更好的基于功能团队的项目管理，你自己思量一下是否要采取一些行动，尝试一下敏捷方法。