有很多的书籍讨论敏捷方法是怎样工作的（How it works？），在这个主题演讲中，Martin Fowler 和他的同事 Neal Ford 讨论了敏捷方法能够在软件开发项目中行之有效的原因（Why it works？）。作为敏捷方法的发起人和传道者，Martin Fowler 和 ThoughtWorks 一直试图从理论层面证明敏捷方法的可行性，同时不厌其烦地解答着客户们的各种困惑，正如他们所说，敏捷方法中的很多概念不是特别的直观，除非人们真正实践过一段时间，否则有些概念很难从字面上去完全理解。

Martin Fowler 谈到一个有意思的现象，那就是今天许多人们口中谈论的敏捷方法，和最初的敏捷方法大相径庭，他把这种现象称为“语义扩散（Semantic Diffusion）”，大意是某种思想在传播的过程中，在逐渐扩散的同时，其语义也渐渐变得模糊。在敏捷开发领域里，“语义扩散”导致的一个问题是，在一些使用敏捷方法的项目或者公司中，我们甚至无法辨别出敏捷方法的影子，原因是很多人没有真正地理解敏捷方法，也就不能够正确地运用和实践，从而也就无法真正了解自己是否能够从敏捷方法中获益。

以下是为什么敏捷方法行之有效的原因：

1. 敏捷方法和传统的计划驱动方法的两个主要区别

i. 预测性计划（Predictive Planning）和自适应计划（Adaptive Planning）

计划驱动方法首先计划要做的工作（plan your work），然后着手工作以完成计划（work your plan）。这是一种带有预测性质的方法，其衡量项目成功的标准则是我们是否按计划、按时、按预算完成了工作。这种方法在很多领域里是适用的。但是对于软件开发而言，如果我们的需求没有办法做到不变更的话，我们就无法保证我们的计划以及其后的工作是不会变更的。Martin Fowler 向现场观众提出了一个问题，大意是你们当中有多少人的软件开发项目的需求是一成不变的，结果没有一位观众举手。因此，敏捷方法引入了自适应计划的概念，既然我们无法保证需求不变更，那么就让我们随时准备接受变更，接受挑战吧。自适应计划将计划驱动的流程缩短为以数周为单位的循环周期，在每一个周期中，我们根据当前的情况不断地调整计划以及计划的执行过程，同时不断地产生能够工作的代码，并且不断地将代码部署到应用环境中去。当然要实现这个目标我们需要一些具体方法的支持，如：自测试代码（Self-Testing Code），持续集成（Continuous Integration），重构（Refactoring），和简洁设计（Simple Design）等等这些技术层面上的方法。Martin Fowler 指出，一些公司和项目之所以受困于敏捷方法，原因之一是他们忽略了这些技术层面的方法，而仅仅实施了项目管理层面的方法。

ii. 以流程为本（Process First）和以人为本（People First）

在传统的方法论中，我们总是需要事先定义好工作的方法和流程，然后“工人们”被要求遵照这些方法和流程来工作。在软件开发领域，很多人把软件开发过程等同于软件本身，也就是说，软件开发的过程也如同软件程序般象机器一样运行，组件之间环环相扣，严密地协同工作。问题是软件开发的核心是人，人相对于机器零件和流水线而言，是相对不可预测的和不那么精密的。所以敏捷方法反其道而行之，提倡将“首先定义流程，然后要求软件开发人员遵照流程工作”变为“让参与软件开发的人员自己来定义和选择适合他们的流程”。简单来说就是以人为本，不把人当螺丝钉，发挥人的主观能动性，当然前提是需要团队成员有较高的平均素质。

2. 沟通（Communication）

Neal Ford 让我们回顾或想象一下失败的软件开发项目，它们的失败是由于技术因素还是人的因素呢？《人件》的作者认为都是人的因素。人类的社会性决定了沟通的重要。Neal 举了几个有趣的例子，如：监狱里的犯人宁愿和其他人渣待在一起也不愿被关禁闭。很多国家禁止驾驶员驾驶时打移动电话，那为什么和乘客聊天就没有问题呢？原因是直接对话是最为有效和便捷的沟通方式，信息的传递在对话过程中非常顺畅和完整。虽然现在的移动通讯已经非常先进，信号质量也很高，但是我们的通话过程仍然是有损的，我们的大脑这个时候就需要努力地试图将通话信息拼凑得更完整以便能够理解对方的意思，因此才会分散驾驶的注意力。随后，Martin Fowler 举了另一个例子，拿他做水果蛋糕的方法和他在酒店的浴室中冲凉的方法来进行比较。因为做水果蛋糕的整个流程和配料都是非常固定的，所以他只需要按步照搬地烹饪即可做出味道非常一致（地好或者差）的水果蛋糕。而在酒店中冲凉就有些不同，因为每一个酒店浴室的开关设计几乎都是不一样的，所以他需要不断地调整开关来获得一个理想的水温，也就是需要不断地重复“调整开关”（输入），“用手试温”（输出）这个过程。相对于做水果蛋糕，在酒店浴室冲凉更好地反应了软件开发的特征，这就是在软件开发领域中，如果我们善于根据用户反馈的信息来做出新的判断和调整，就有可能提高产品的质量和用户的满意度。

沟通的确是一个非常重要的环节，它是敏捷方法的核心。在敏捷方法中，单元测试是程序员和代码组件的沟通，功能测试是程序员以及QA和系统的沟通，故事墙（Story Wall）和回顾（Retrospective）是团队和成员之间的沟通，功能演示（Showcase 或者 Demo）是团队通过产品和最终用户的沟通，持续集成（Continuous Integration）是产品和企业计算环境的沟通。沟通好了，什么事情都可以妥善解决，沟通得不好，好事也会变坏事。和广大技术爱好者交流沟通也是酷壳存在的目的和意义。

整个演讲时长一个小时，本文只是节选了我认为比较有意思的观点加上本人的理解写成，如有错误之处欢迎指正，不同看法欢迎交流。

以下是座谈的内容：

1、如何在常规业务中应用敏捷方法？

常规业务（Business As Usual）是指使公司业务正常运营而进行的一些日常业务活动，对于IT部门而言则包括系统维护、技术支持以及应用更改。这些工作相对于独立的软件项目而言即琐碎又零散，但又是不可或缺的。“如何在常规业务中应用敏捷方法？”，这是我们向Martin提出的第一个问题。Martin阐述道，首先需要澄清一下对项目的定义，传统的项目运作方式是集中一批业务人员、开发人员和管理人员进行产品开发，开发完成后将产品交付系统运行和支持部门，项目也就随之结束了。在敏捷方法中，项目是一个持续性的过程，系统随着业务的需要不断地更改和重构，参与项目的人员也相应地在不断地增加或者减少。笔者的理解是只要系统仍在支持业务运营，项目就不会结束，因为业务几乎不可能不变更，并且必要的重构也不可避免，对于ThoughtWorks的顾问们来说这意味着他们和客户的业务关系也不会结束，呵呵，双赢的策略！

2、集中式办公和分布式办公

Martin强烈反对项目成员分散式办公，甚至觉得如果你需要业务人员每天到你的办公室来访问你，那简直是不可接受的，至少你应该每天都去拜访他们。“It is a shame if the business stakeholders need to come to your office every day”大意如此。但是现实却是，对于很多公司而言，将业务经理、项目经理、业务分析人员、开发人员和测试人员都集中在一个办公室简直就是一件不可能完成的任务。笔者目前所在的项目有三个团队，一个在悉尼，两个在墨尔本，每周进行四次远程视频会议，同时通过使用电话、即时消息系统、电子邮件、项目WiKi系统等手段来解决分布办公带来的沟通不及时和信息不透明等问题。Martin最后也不得不承认，很多时候如果实在不能够做到集中式办公，那只有准备好为此付出一定的成本。笔者认为要做到完全的集中式办公可能不太现实，不过可以尽可能在异地团队之间保持相关业务的对等沟通，比如在各个团队中都尽可能安排项目相关的各类角色，如：业务经理、项目经理、开发人员等，让这些人员与在异地的相同职能的人员沟通，然后再将信息在各自的团队内消化和共享，这样的效果也许会好于纯粹的按照职能来分布团队。

3、交叉技能（Cross Skills）

这里主要讲的是BA（Business Analyst 业务分析人员）和QA（Quality Assurance 质量保证人员或测试人员），Martin说在理想的情况下，BA和QA的角色可以合并，开发人员和QA的角色也可以互换。因为BA和QA都需要对系统功能有很清晰全面的了解，他们也是系统测试的主要参与者和鉴定者，他们用来定义系统功能的主要文档是用户故事（Story），而用来测试系统功能的则是功能测试代码，测试人员和开发人员有责任将功能测试代码写得易于阅读，特别是对于BA，如果他们能够象阅读用户故事一样阅读功能测试代码，将会提高他们测试系统的效率和兴趣。这也是在功能测试中使用领域特定语言（Domain Specific Language）的目的，如果BA和QA都能够阅读和使用DSL编写测试代码，那该多好啊！（憧憬中…） 通过让开发人员轮换地担任QA的角色，可以帮助提高测试代码的质量，也可以让开发人员真正从用户的角度来考虑系统功能的设计，还可以建立相互信任、相互尊重（appreciate each others work）的良好氛围。

4、设计和编码

一位同事谈到对业务模型缺乏了解会导致代码难于理解，有时候即使代码的质量过关并且系统功能都在正常工作，但是系统的设计却和业务模型出现很大的偏差。“ 在实现设计之前，开发人员需要正确理解整个业务模型（The big picture）”，这是被经常提及的解决方法之一。Martin对此却不置可否，当然能够理解整个业务模型是最理想的情况，但是往往很少有人能够做到这一点，即便能够做到，业务模型也会随着时间和具体情况而变更。Martin首先认为设计和编码不是两个分离的过程，开发人员在设计过程中编码，也在编码过程中设计。开发人员在编码的过程中实现自己当前对业务模型的了解，首先让功能模块工作起来（Get it working），同时考虑如何让代码更便于日后的必要的重构，随着时间的推移，开发人员对业务模型的了解会不断清晰和全面，只要代码易于重构，整个系统的设计和实现将会不断地、最终地符合业务模型。

5、公司内部的开源项目，鼓励用户参与产品开发

很多公司里不同的IT部门可能会重复开发相同功能的产品，这样会导致很大的资源浪费，用户也会面临选择的难题。再者，Martin发现很多IT部门对用户提出的功能需求缺乏足够快的响应速度，主要原因是开发人员资源有限，即使再玩命地工作也不可能在用户的预期时间内处理完本来就很长的功能需求队列。典型的例子是：公司有两个IT部门A和B，A部门需要B部门对邮政编码的Web Service做一个功能更改，而B部门的开发人员正忙于处理n个之前提交的功能需求，所以A部门的需求只能在队列中耐心等待直到B部门有开发人员空闲。如何缩短用户的等待时间？Martin建议如果A部门有开发人员熟悉Web Services，他可以从B部门的源代码库中提取邮政编码Web Service的代码，并且编码实现他需要的功能，完成之后生成代码包提交给B部门审核和测试，通过后就可以将代码合并到代码库中。这样做的优点是：1. 将功能需求由开发部门驱动转变为用户驱动，因为用户是真正了解并需要这个功能的人，所以用户会更为迫切地运用各种手段实现该功能，同时保证功能如其预期的那样运行。 2. 缩短开发周期，如果用户不愿意等待的话他可以立即着手开始功能的实现，而不必等待B部门的人员。3. 有利于公司内部的知识共享和交流，即便A部门的开发人员不熟悉Web Services但是愿意学习，B部门的开发人员可以通过结对编程（Pair Programming）的方法指导对方，待对方上手之后即可返回自己的工作，相对于B部门开发人员由始至终开发整个功能而言，这仍然可以大大缩短整个开发周期。当然，公司内部的开源策略需要一些前提，首先是部门之间应该有共同的知识领域，代码和文档需要版本控制的支持，部门人员能够理解和运用结对编程。

6、选择和运用框架

“It is like you buying a new PC every 2 years” 当Martin被问道“这么多的应用框架层出不穷，我们该如何选择？”的时候如是回答。每几年我们都会换一台新电脑，是因为新的电脑内存更大，处理速度更快，应用软件也更复杂，要求的系统资源也更多。我们使用框架的目的也是解决业务相关的问题，只要是对业务有利的框架，都值得花一点时间去关注。 Martin鼓励公司允许开发人员占用一定的工作时间来实验新的框架，因为不这样如何能够知道它是否对提升业务价值有帮助。当然框架在生产环境（Production Environment）中的表现是衡量的一个重要标准，因为不经过生产环境中各种复杂情况的检验，很难最终确定框架是否适用。

（本文系作者原创，请勿用于商业用途，如转载请注明出自酷壳www.cocre.com）