第9章　尾声：走向敏捷

一灯能除千年暗，一智能灭万年愚。

——慧能，中国禅宗第6代祖师

一点智慧，只要有它便足够了。我们希望大家喜欢对这些敏捷实践的描述，而且其中有一到两个可以点燃诸位智慧的火花。

无论经验是否丰富，不管过去有什么样的成功，遇到过什么样的挑战，只要进行一个新的实践，就可以让人头脑清醒，并让你的工作与生活从此发生改变。使用这些实践的子集，能够救濒临失败的项目于水火，也可以使得从此往后的项目变得完全不同。

9.1　只要一个新的习惯

举个例子，看看Andy曾经服务过的一个客户的故事。他们的办公室位于一座具有玻璃外墙的、高耸的写字楼中，团队的办公室沿着外墙排列，形成一条优雅的曲线。每个人都能看到窗外的风景，整个团队的分布几乎占用了楼层一半的墙内空间。但是这个团队有不少问题：版本发布总在延期，团队逐渐失去了对不断增多的bug的控制。

按照通常的工作方式，Andy和注重实效的程序员们，坐在办公室的一端，开始对团队进行访谈，以了解他们的工作是如何开展的，有哪些进展顺利，哪些构成了障碍。第一位成员解释说，他们在开发一个C/S应用，客户端非常瘦，所有的业务逻辑和数据库访问都放在服务器一端。

然而，随着访谈的不断进行，故事却慢慢发生了变化。每个人对项目的方向和目标的了解都有所偏差。最终，最后一个成员骄傲地宣称：系统的构成包括一个包含全部GUI和业务逻辑的胖客户端，以及仅仅包含一个简单数据库的服务器！

现在问题就很清楚了，团队从来没有坐在一起讨论过项目。实际上，每位成员仅仅与坐在旁边的人有过谈论。就像是学校里的孩子们玩过的“传话”游戏，信息在人与人之间传递时产生了偏差，最终偏离了本意。

需要哪种有实效的建议？马上开始使用立会吧（见第148页习惯38）。这种做法很快就收到了令人惊异的效果。不只很快解决了架构上的问题，而且产生了更深远的影响。团队开始变得更有凝聚力，彼此紧密配合，共同工作。bug产生率降低了，产品变得越来越稳定，截止日期也不再像以前那样令人窒息。

没有花费太多时间，也没有耗费多少精力，只需要一些规矩来保证立会的举行，不过这很快就形成习惯了。只要一个新的习惯，就让团队发生了巨大的变化。

9.2　拯救濒临失败的项目

如果采纳一个习惯可以产生好的效果，那么采纳所有的习惯，就应该产生更好的影响，是吗？最终一定是这样的，但是不能一下子全部上马——特别是对一个已经处于困境的项目。突然改变某个项目的全部开发习惯，是让项目突然死亡的最佳方式。

用一个医学上的比喻，假定有一个胸部疼痛的病人。当然，如果病人经常运动而且保持健康饮食的话，他们不会生病。但是不能因此就马上说：“别赖在床上了，爬起来开始在跑步机上运动吧。”这有可能要了病人的命，而且你的渎职保险赔偿率一定会升高。

必须要稳定病人的状况，并使用最小剂量的（但是必要的）药物和治疗过程。只有在病人身体状况恢复且趋于稳定之后，才能让他按照良好的饮食起居制度来安排自己的生活，保证身体的健康。

当项目岌岌可危时，应该先引入一系列习惯来稳定目前的状况。看这个例子：一个潜在的客户曾经以惊恐的声调打电话给Venkat，说他们的项目陷入危机。他们已经耗费了一半的时间，而项目还有90%的成果要交付。管理层对于开发人员不能及时完成任务感到很不高兴。开发人员对于管理层总是逼得这么急也觉得很不爽。剩下的时间，他们是应该用来修补bug，还是开发新功能？不管危机发展到什么程度，团队总是希望获得成功，然而他们不知道该怎么办。所做的每件事情都让他们落后更远。他们感到了威胁并且不愿再做任何决策。

Venkat没有试图一次解决全部的问题，他必须先稳定病人的状况，使用了下面这些促进沟通和协作的敏捷习惯作为开始：第18页习惯3，第148页习惯38，第162页习惯43，以及第168页习惯45。以此为起点，下一步要引入一些与发布相关的习惯，比如第55页习惯13，第58页习惯14。最终，他们采纳了一些与编码相关的习惯，比如第132页习惯34，第136页习惯35。这就足够解决目前的危机了，项目比预定时间早两周完成，并得到了管理层的认可。

这就是紧急救助的模型。如果事态没有那么糟，可以采取更加全面、整齐的方式来引入敏捷习惯。无论你是经理，还是团队带头人，或者只是一个对敏捷感兴趣、试图从组织内部发起敏捷过程的程序员，我们都有一些针对性的建议。

9.3　引入敏捷：管理者指南

作为一个管理者或者团队的带头人，有责任先让整个团队知道接下来将要发生什么。要向大家说明敏捷开发是要让开发人员的工作变得更加轻松，这主要是为了他们好（根本上来看，对用户和组织也是有益处的）。如果没有达到这样的效果，那就是有些地方出了问题。

要慢慢来。记得领导所做的每一个小动作，都会随着时间对团队产生巨大的影响。^[1]

将这些主意介绍给团队的时候，要说明在第10页第2章中的几条基本原则。确保每个人都知道项目将会以此运转——而不只是口头上说说而已。

从立会开始（见第148页习惯38）。这可以让团队有机会进行彼此讨论，并对一些重大问题达成共识。把之前相对孤立的架构师带到团队中，并让他们参与到日常开发工作（见第152页习惯39）。开展非正式的代码复查（见第165页习惯44），并做出计划，让客户与用户也参与到项目中来（见第45页习惯10）。

接下来要准备好开发的基本环境。也就是说要开始采纳（或改进）基本的入门级别习惯。

□　版本控制

□　单元测试

□　自动构建

版本控制是第一要务。在任何项目中，它都必须是要最先搭建好的基本架构。设置好后，就要为每个开发人员安排好各自要使用的本地构建项目，这些项目要与服务器保持一致，可以通过脚本运行构建操作，还要能够运行任何可用的单元测试。这些都搞定之后，就可以开始为正在开发的新代码创建单元测试，并按需为已有代码创建新的测试了。最后，要准备一台供后台运行持续构建的机器，使之起到棒球比赛中“挡球网”的作用，以捕获任何发生的问题。

如果你对这些领域不熟悉，到最近的书店（或www.PragmaticBookshelf.com）去买一本Ship It！[RG05]，它会告诉你如何设置相关的环境和运行机制。入门工具箱（Starter Kit）系列图书可以帮你完成如何在特定环境下配置版本控制、单元测试，以及自动化等具体细节。

基础架构搭建好后，就要考虑如何将项目和团队带入到固定的节奏中了。可以再次阅读第43页第4章，来了解项目的时间安排和节奏相关的内容。

现在应该已经对基本知识都有所了解了，接下来应该调整习惯，以让它们适用于你的团队。在设定环境时，可以回顾一下在第76页第5章，接下来再看看在第98页第6章和第138页第7章，了解如何以敏捷的方式来解决日常问题。

最后，开始引入在第26页第3章提到的自备午餐会和其他习惯，并开始使用在第146页第8章敏捷协作的习惯，让团队可以紧密配合，共同工作。但这并不是结束，还有很多其他工作可以开展，很多习惯可以采纳。

要不时——也许是在每个迭代结束后，或每个版本发布完成后——举办项目回顾会议。从团队处得到反馈：哪些做得不错，哪些需要调整，哪些不起作用。如果之前采纳的某个习惯没有达到预期效果，翻回头查阅本书中对应习惯的“切身感受”和“平衡的艺术”两个部分，看看是不是有哪些细节方面出了问题，并且进行修正。

9.4　引入敏捷：程序员指南

如果你不负责带领团队，但是希望让大家向敏捷的方向努力，就要面临不少挑战了。不单要完成前一节列出的各种事项，还应该通过实际的例子，而不是行政命令来引领大家。

有句老话说得好：“你可以把马带到水边……但是你不能强迫它使用你最钟爱的代码编辑器。”^[2]当然，除非你已经用得非常熟练了。只要好处明显，团队成员肯定会希望尽快着手使用的。

举例来说，从单元测试开始是一个不错的选择。可以先针对自己的代码开始使用。在短时间之内（几周甚至更少），就可以看到代码质量提升了——减少了错误的数目，提高了质量，健壮性也有所提升。你下午5点就可以下班回家，而且所有的任务都可以顺利完成——不必担心半夜被电话叫醒，去修复bug。旁边的开发人员想知道你是如何做到的，而且消息也渐渐传开了。整个团队现在都想尝试这些新奇的习惯，而不需要你努力去说服他们。

如果要将团队带入新的领域，必须首先以身作则。所以不妨从可以马上着手的习惯做起。在第10页第2章中的习惯是个不错的起点，比如这几个偏重编码的习惯：第78页习惯19和第82页习惯20；还有第98页第6章和第128页第7章中的习惯。还可以在自己机器上运行一个持续构建服务器，发生问题时可以马上知道。队友可能会觉得你有“千里眼”呢。

过些时间之后，可以试着开始一些非正式的自备午餐会（见第31页习惯6），与大家一起讨论关于敏捷项目的节奏（见第40页习惯9）和其他感兴趣的话题。

9.5　结束了吗

本书内容马上就要结束了，下面该怎么做就看你自己了。不妨应用这些习惯，看看对自己有哪些好处，也可以带领整个团队着手，以更加轻松和快速的方式开发更好的软件。

可以访问我们的网站，在那里可以找到作者的博客以及其他文章，包括相关资源的链接。

感谢你的阅读。

【注释】

[1]可以查看Behind Closed Doors[RD05]，这是一本关于如何领导团队和提升管理技能的好书。

[2]西方谚语，原文为：You can lead a horse to water， but you cannot make him drink（你可以带马到水边，但不能免强它喝水），其意指：善意不足以成事。——译者注