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

    想尝试不一样的感觉了吗

    现在你想尝试敏捷方法了。但也许你只是想安抚一下部门里的那几个敏捷疯子，在他们喝着醉人的KoolAid饮料时，给他们送上一些Scrum“小吃”。那么，你应该怎么做呢？你又怎样才能把它最好地集成到正常的工作中去呢？眼下有大量的敏捷方法可供选择，因此我在这里只能谈一谈最流行的那几个：Scrum、极限编程、测试驱动开发、结对编程、用户需求描述、重构和持续集成。

    译者注：KoolAid是美国本土的饮料，里面含维生素C，是美国人在成长时最喜爱的饮品，不含咖啡因，口味多变。

    首先，有两个方法在微软我们已经用了十几年了，它们是“重构”和“持续集成”。重构只是简单地重新组织你的代码，并不改变它原有的功能。重构用来将复杂的函数（面条代码）打散，或者在现有代码的基础上增加新的功能，就像把一个只能读取CSV文件的类改造成一个抽象类，以便能够同时读取CSV文件和XML文件。持续集成的想法是，让新代码总是定期集成到完整的工程创建（理想情况下是每天）中去，以便所有人都能对它进行测试。

    译者注：面条代码（Spaghetti Code）是一种经典的反模式，如频繁使用GOTO语句，用来形容看上去很乱、几乎没有软件结构的一段程序或者一个系统。

    让他说话

    其次是“用户需求描述”，它们就像是应用流程和一页功能规范书的组合。用户需求描述的想法是，提供足够的信息来估计需要执行与测试什么样的功能特性。

    比较麻烦的是，用户需求描述应该是由用户来创建的。很多敏捷方法假设用户经常就坐在功能团队的旁边。遗憾的是，当你有1亿个目标用户时这就成了问题。

    不管你喜不喜欢，我们需要有人代表用户的角色。像市场、产品计划、用户体验、销售和客户支持部门都可以充当这样的角色。他们对用户大量的调研成果可以写入价值主张和远景规划书。然而，当对那些高瞻远瞩的远景规划和端对端的应用流程进行细化时，我们在功能级别上仍然能够使用用户需求描述的概念，以提供足够的事实依据来对一个功能集合的实现和可行性进行评估。

    合作共赢

    “结对编程”是指两个人共用一张桌子和一个键盘在一起编码。它的想法是，当一个人在打字的时候，另外一个人则更有全局观，可以发现设计或实现的不足之处。这一对人常常交换角色。虽然两个脑袋比一个脑袋好，但这样的成本也是双倍的。我更愿意把这两个人分别用在设计和代码审查上面，这样价值会更高。然而，结对编程对于熟悉新代码库效果显著，这时通常把一个熟悉代码库的人和一个不熟悉代码库的人结成一对。

    作者注：在一些陌生的领域，我的团队曾经为创建一些新鲜的事物使用过结对编程。这种方式相当好！

    除了重构和持续集成外，“测试驱动开发”和Scrum已经被证明是在微软应用的最简易、最有效的敏捷方法。我在我的栏目中描述精益工程的时候（本章的第二个栏目），关于测试驱动开发我是这么论述的：你首先为一个类定义它的功能和函数，然后给公共函数编写单元测试，再然后才是写实现代码。这是个反复的过程，并且每次都只写几个单元测试和一点点代码。这种方法相当流行，因为这样为开发者提供了所有开发所需的单元测试代码，从而为实现代码提供即精简又高效的设计框架。

    请参阅本书第5章的“复审一下这个——审查”栏目。

    先写测试也更有趣。当你先写实现代码的时候，单元测试就成了一种花样翻新的痛苦，而且它只会带来坏消息；测试不能真正起到增强代码的作用。当你先写单元测试的时候，编写代码去适应测试会比较容易，而且当测试通过的时候你的心情会非常愉悦。

    作者注：很多业内人士都认为，测试驱动开发的真实目的是一种优秀的实现代码设计方法。虽然我同意这种观点，但单元测试的积极作用不应该被夸大。

    测试驱动开发可以和结对编程组合起来使用：一个开发者负责写一些测试，另一个负责写足够的代码来通过这些测试。他们两人的角色还可以常常交换。最后，测试驱动开发让开发者对“什么时候才算是真正完成了实现”有了清晰的认识。也就是，所有的需求都经过测试，并且所有这些测试都通过。

    有点极端

    “极限编程”是一个完整的开发方法论。它把用户描述、结对编程、测试驱动开发、重构、持续集成和另外一些实践组合在一起，其非常适合应用在跟客户紧密合作的小团队中。

    极限编程大量依赖团队知识，以及与客户之间的直接交互，而且几乎没有文档。如果你的团队是独立的，并且你的客户就在你的走廊边上，这种方法会很有效，但在微软这种现象并不普遍。如果我们不能每年赚到数10亿美元，我们的形势就会很悲惨。然而，就像我已经说过的那样，极限编程中的很多单个方法在我们的产品开发中应用得非常好。