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

   我很难做出判断。也许你可以帮我。我不能断定以下两种观点，哪种更糟心：一种观点认为使用“敏捷”方法，并且恨不得微软在全公司范围内采用它，用它解决我们面临的所有麻烦；另一种观点认为敏捷是被一些无知的学者鼓吹出来的，它实际上是一种改头换面的愚昧方法，它让开发者不用承担任何责任。这是个两难的决定，两种观点都会使我有种作呕的感觉。

    作者注：这是我最喜欢的栏目之一，因为其间爱恨交错不能自已。尽管它并不完美，但我在这个主题上的评论还是相当公允的。

    现在让我们来纠正这两种观点：

    ·如果你认为敏捷方法解决了产品开发过程中的所有错误，那你真是愚蠢至极。雇用成千上万个人来开发高度复杂、深度集成的软件给上亿客户来使用，这不是件容易的事。这世界上没人比我们对这个任务知道得更多，包括敏捷联盟的那些聪明家伙。并不是我们现在做的所有事情都是错的，也不是所有事情都能用敏捷方法来满足我们的需要。

    ·如果你是极端的反敏捷人士，你认为Scrum是System of Clueless Reckless Untested Methods（一个毫无头绪、不计后果、未经试验的方法系统）的缩写，那你也是个蠢蛋，而且更加无知。不假思索就随便以什么理由妄加否定，本身就是带有偏见且不专业的做法。像敏捷这样的草根运动总是有一些事实基础的，它可以使我们的团队和客户受益。那些概念可能并不一定直接适合于我们的业务，但当你停下来理解它们的时候，那些事实基础总是有一些用武之地的。

    作者注：敏捷是在微软整个公司范围内，也就是由一小撮人和一些小团队牵头的一次草根运动。

    该是破除敏捷方法的神话的时候了。我还将解释如何去使用这些方法背后的创新思维，以构建我们自己的优势。

    真理的敌人

    首先，让我们来破除下面这些敏捷神话……

    ·传说之一：敏捷就等于极限编程（结对编程、Scrum、测试驱动开发、用户需求描述或者其他敏捷方法）。敏捷方法实际上是软件开发方法的一个集合，这些方法遵从一套统一原则，但除此之外其他方面都没什么关联性，有时甚至还是对立的。你可以从敏捷联盟（wwwAgileAlliancecom）了解到关于敏捷的更多真实信息。

    ·传说之二：敏捷方法不适合大型组织。这种说法很荒谬。敏捷是各种方法的一个集合。这些方法中有一些不适合大型组织，但有一些适合，还有一些如果你创新一下的话也可能适合。在做出一个武断的结论之前，你必须先好好研究一下具体的方法。

    ·传说之三：敏捷方法很适用于大型组织。敏捷哲学崇尚“客户合作胜过合同谈判”和“随机应变胜过循规蹈矩”。但跟1亿多个客户合作是艰难的。合同谈判在跨团队依赖关系管理方面是至关重要的。（参见第8章的“各走各的路——谈判”栏目。）循规蹈矩对于商业承诺来说是必要的，因为合作伙伴在上百万美元面前会变得难以相处。在大规模项目上应用敏捷方法，要求你灵活而有创造力地去处理好这些问题。

    ·传说之四：敏捷意味着不写文档。敏捷哲学崇尚“能用上手的软件胜过面面俱到的文档”。很多敏捷的狂热者看到这个就认为，“啊，不需要文档了！”这么认为的话只能说你是井底之蛙。敏捷哲学声称，“精益求精。”换句话说，能用上手的软件比文档更重要，但必要的文档对客户、合作伙伴和跨部门的依赖方仍然是有价值的。

    ·传说之五：敏捷意味着不需要前期设计。敏捷哲学崇尚“随机应变胜过循规蹈矩”。很多敏捷的狂热者将其误解为，“没必要思考或做计划，设计到时候将突然出现！”突然从哪里出现？一个放射性污水池吗？这里的要点是说，随机应变胜过过分死板地遵循原来的计划——而不是撞了南墙后再回头。

    ·传说之六：敏捷意味着没有个人责任。敏捷哲学崇尚“个体性与交互性胜于过程管理与工具”和“随机应变胜于循规蹈矩”。很多管理者看到这个感到很恐惧，认为这个意味着完全没有责任可言。实际上，敏捷在这个领域收到的效果恰恰与管理者担心的相反。敏捷使个体对团队负责，而团队对管理层负责。责任性大大地加强了，并且这种独特的哲学理念让敏捷团队更加有效、有弹性并且名副其实地“敏捷”。

    ·传说之七：Scrum是个缩写词。这是个很无聊的传说，但它几乎让我发疯。Scrum是最有名的并且使用得最广泛的敏捷方法之一，但它绝不是一个缩写词。Scrum是根据橄榄球术语来命名的，代表球队聚在一起，手挽手，准备争球。它也是Scrum团队每日例会的名字。在微软，我们已经使用了一种类似Scrum的方法达数十年，比这个术语的出现要早得多。Scrum是最简单的敏捷方法之一，也最接近于微软的很多团队在现实中采用的方法。稍后再对Scrum作更详细介绍。

    拨乱反正

    抽象地谈论敏捷只会招来漫无边际的争论，但是实际中的应用才是重点。我们已经知道，敏捷实际上是软件开发方法的一个集合，问题是，“哪种方法适合在大规模项目中应用呢？”很多人对这个问题已经思考过或者撰稿论述过，但写这样的栏目的人却不多。在我给出我的观点之前，请看下面的几条基本规则：

    ·能不变就不变。如果一个团队已经在业务注重的标准上表现得很好，那就没有必要再改变了。改变总是有代价的，哪怕它的结果可能会很美好。你改变的目的只能是为了在最后获得改进。因此如果不需要改进，也就不需要改变。

    ·不要陷入太深。如果改变是必要的，也不要一下子改变所有的东西。让功能团队每次只挑一两样改进，并且留意它们的进展状况。不是所有的团队都要一起改变，也不是所有的团队都要做相同的改变。当然，如果你改变的是一个像创建系统这样的中心服务，那么所有的团队最终都必须接受它。但即使是这种改变，我们也可以选择让它对某个团队公开或先隐瞒。推荐的方法是：一点一点尝试，一点一点学习，循序渐进。

    ·区分项目级别和功能级别。人们感到困惑最大的地方，尤其对于敏捷方法，是在项目级别和功能级别上的差异。在项目级别，团队之间需要严格的日期和协议约束。在功能级别，你…好吧，事实上…管它呢。很多管理者都不能理解这个奇异的概念——你的团队可以在你规定的任何期限内完成工作；问题只是在于在这个日期之前要完成多少功能模块而已。只要项目级别的计划能够被跟踪和控制，那么你的功能团队应该选择任何一种能够让他们工作得最有效率的方法。

    作者注：这一段话体现这样一个理念，环环相扣。它给我们的警示是，当组织中的几个小团队使用相似的方法时，通常这个组织会工作得更好。这些方法不需要完全相同，但如果团队步调一致的话，他们会在一起工作得非常好。否则，因为团队之间的预期时间各不相同，结果他们之间的协调和沟通就会变得一团糟。