熊节谈敏捷在软件开发中的实践

个人简介 熊节是ThoughtWorks中国公司的咨询师，InfoQ中文站的社区编辑，曾参与《重构：改善既有代码的设计（中文版）》、《J2EE核心模式（原书第2版）》、《Contributing to Eclipse中文版》等图书的翻译。目前正在从事Ruby on Rails的项目，并致力于敏捷方法与思想的推广。

   

1. 熊节你好，请向大家介绍一下你自己，然后还有你所从事的一些事情。谢谢。

大家好，我是来自ThoughtWorks中国公司的熊节，那么我的工作呢，是在ThoughtWorks从事咨询方面的工作，包括给我们的客户提供敏捷方面的培训等等。

   

2. 好，那据我们所知敏捷是近年兴起的一个非常流行的一个热点名词，那么到底敏捷是一个什么东西呢？我们为什么要知道敏捷呢？

要说敏捷是什么东西的话，这可能要从一些最基本的地方说起。敏捷，可以把它理解为软件开发中的精益开发，那么就像在汽车制造的精益理念里一样，敏捷的关键是在于消除浪费。所以为什么我们要关注敏捷，因为我们希望在所有的项目，所有的企业里面消除浪费，降低我们的成本，更有效地完成工作。

   

3. 那敏捷如何做到消除浪费呢？

这就要从浪费的根源说起，在软件企业里面，最常见的浪费可以分为两种，第一种是由于质量低下而造成的返工，这是在我们的工作中很常见的；第二种，是一种不那么明显的浪费，它体现为工作的价值被滞留在工作环节中间，而不是直接地给客户创造价值，我们做了很多的事情，但是客户看不到这些。我们的工作没有给客户创造出价值，虽然它也许是高质量的，这两种主要的浪费是在我们的工作中普遍存在的，那么敏捷所有的实践，我可以这样讲，他就是致力于消除这两个方面的浪费。

   

4. 那么我们大家很感兴趣到底敏捷实践的最小集合是怎么样的呢？

我们可以从消除浪费的这个角度来看敏捷所有的实践，那么敏捷的实践我们可以把它分为两大部分。第一部分，致力于消除我刚才所说的价值不流动的造成的浪费，那么我们所采取的措施是增加交流，要在整个团队，整个项目，甚至于整个企业的层面上要增加交流，让所有的人能够有效的沟通起来，让工作的价值能够流动起来；另外一方面，在消除我刚才所说的返工，由于质量低下造成的返工所造成的浪费，那么敏捷对于消除这种浪费的策略是提高质量，持续地改进质量，持续地保证质量，那么从这两个角度出发，我们就可以找到敏捷的一个最小集合，或者说一个团队想要让自己变得敏捷起来，他最少需要做哪些事情，对吧？首先他需要让自己的交流更加的通畅，其次他要想出办法，让自己的工作的质量，让项目的质量能够得到持续的保证和改进，那么所以我的答案是，没有一个一定的最小集合适用于所有的企业，这不是说，不是像一种认证，你做了这些事情，你就是敏捷的，不是这样的，你需要从这两个角度出发，如何提高交流，如何提高质量，从这两个角度出发，去寻找你需要做的事情。

   

5. 那我们想知道一下，到底敏捷能如何在增强你项目的交流，跟提高质量这方面能做到一些什么呢？

那我们可以从一些具体的实践来讲这个问题，比如说，我们可以看一个敏捷团队，他每天的工作情况，早上九点钟的时候，这个团队，大家站在一起，开始了一个什么？Stand up meeting 这是来自Scrum的一个实践，对吧？那么它起到的效果是什么？它起到的效果是非常清楚的让整个团队的每一个人交流起来，让他们说出我现在的状态，我在做什么，我昨天做了什么，今天将要做什么？我有什么困难，有什么需要和别人交流的东西，通过这个制度，让所有的人交流起来，让信息不会阻塞在某一个地方，不会让困难阻塞在某一个地方，然后，开完了Stand up meeting以后，这个团队开始到一个Story Wall 上面去移动他们的卡片。为什么我们要用卡片来管理需求，而不是用文档？电脑里面的一个Document来管理需求，因为卡片更可见，就包括，说起这个可见性的话，你还可以想到一个敏捷团队工作环境，大家在一个大圆桌里面，大圆桌的四周互相面对面的工作，而不是坐在小格子间里，这都是促进了整个项目的透明性，让大家能够更好的共享信息，对吧？所以这些都是从敏捷实践的日常的实践里面就可以看到，是如何在改进交流的质量。然后，当他们拿过了Story Card，两个Developers拿到了Story Card，看明白了我们要做什么事情以后，他们两个人开始坐在一起Pair，两个人坐在一台电脑前面用一幅键盘编写程序，并且他们在编写程序的时候，他们会测试驱动：首先写测试，然后再写功能代码。当他们完成了一个功能以后，他们会持续集成，他们会把代码，Check in到项目的代码过滤，然后持续集成服务器会告诉他，你的测试是不是通过，整个项目健康状态是不是仍然良好。所以通过这些，有技术手段，也有团队组织的手段，综合起来我们在日常的工作中一点一点的严格的保证质量。所以我们可以看到敏捷的这些实践都是在有效的加强交流，或者改进质量。

   

6. 你刚才提到就是敏捷实践中里边有一个结对编程，这是极限编程里边非常著名的一个实践，然后我想了解一下，因为这个概念对于其他人来说是非常诡异的，刚才你说敏捷是要为了减少浪费，但是这样看起来，有两个人然后同样编写一个代码，这个难道不是一种浪费吗？

这个问题我听，有很多人问过我。那么最近的一次，有一个客人到我们的，到ThoughtWorks办公室去，看到我们桌上摆着一个显示器，一副鼠标键盘，两个人在那工作的时候，他觉得很诧异，你们为什么要这样做？你们让两个人做一个人能做的事情？这不是很大的浪费吗？那结对编程我可以说出它的很多很多好处，我可以说它具有信息交流的优势，让两个人可以互相交流关于这个项目的知识；我可以说他是一种很好的知识传递的方式，让新来的开发者可以跟着资深的开发者学习，我可以说出它很多的好处。但是，我要说的最重要的一点好处是在于，我们都记得软件工程里面，有一个很重要的计算，如果你能在，我们假设你在分析一个问题的时候出了错，然后你找出这个错误，这个时候你把它修复掉，你的成本是1，那么到了设计的阶段，你再去修复这个错误的话，同样的错误成本就会变成10，到实现的阶段就会变成100，到了上线，或者说后期测试的阶段，这个成本会变成1000，那么到了上线维护的时候，你再发现一个错误，你再去修复这个错误，它造成的损失会是非常巨大。所以，要想降低这种由于错误或者说质量问题，所造成的损害最好的办法，就是提前发现它，提前解决它。那么有什么办法能让一个错误能被尽可能快，尽可能早地发现出来，最好的办法就莫过于让两个人在一起工作，让两个人互相检查，随时随地的互相检查对方的想法，对方所做的每一件事情。然后尽可能早的把所有的问题扼杀在摇篮中，不让它留到这个软件生命周期的后期，去造成更大的危害。

   

7. 好的，那敏捷方法来自于西方，把它们用到中国本土公司里面会出现一些水土不服的现象吗？

直接的答案是肯定会，因为很多的实践来自于，很多的实践来自于西方的项目，欧美的项目，欧美的团队经验总结。但是，如果你仍然回到我们一开始所说的这个根源上来讲，敏捷的目的是消除浪费，提高效率，改进质量，是吧？那么我们仍然站在这个点上来看的话，你就没有办法说敏捷不适合中国，或者说，中国的企业对敏捷水土不服。因为那就意味着你在说，消除浪费不适合中国，改进质量不适合中国，提高竞争力不适合中国，显然这不是事实。我们所有的企业都在寻求着做这样的事情。那么所以这个问题的答案是，我们的出发点是一致的，所有的企业，不管是西方的企业，中国的企业，西方的软件团队，中国的软件团队，大家有一个共同的出发点，消除浪费，提高质量，然后呢，我们必须站在中国的角度上，去找到适合我们的实践，也许会对以前的实践做一些改进，但是这个出发点是不会变的，比如说对质量的重视是不会变的。为什么？因为低质量给中国软件，给我们的软件项目造成的损害，我们已经看得太多了，所以有些重要的东西是不会变的。

   

8. 把敏捷方法推广到中国公司当中，会碰到那些具体的挑战吗？我们是不是有可能会克服它呢？

首先挑战是一定存在的，因为，我举一个最简单的例子，在ThoughtWorks的工作环境里面，我们会一个大办公室，然后里面没有格段，一个项目组坐在，围着一张大圆桌坐在四周，然后在周围的墙上或者是窗上贴着各种各样的卡片，画着，用白板画着各种各样的图，这显然是和国内的大多数软件公司的情况不一样的。那么，要让你的团队更好地交流起来，要把这些敏捷实践推行起来，也许这种办公室的布置方式就是你需要的。那要想推进这样一个东西，我们就不用说，更多的诸如组织结构啊，诸如工作流程啊方面的东西，就是在这一个办公室的布置上，你就有可能遇到非常大的阻力。那么像我刚才说的，在更深入的层面上，这个组织，这个团队如何去构成，团队之间的人如何交流，团队的之间的，团队的这个工作流程如何构造，大家是日常的工作的时候，要遵守哪些规则，要遵守哪些规定，如果你实施敏捷的的话，就会给你带来方方面面的改变。当然你作为一个软件团队来讲，你要引入敏捷本身就是为了改变，对吧？因为以前的开发方式里面，有他的问题存在，如果没有问题存在的话，那为什么要引入敏捷呢？那么所以是不是能克服，是不是能在国内的环境底下克服这些阻碍呢？我相信是完全可以的，因此我们有看到实力在这里，有几种典型的公司，我亲自见到，来自从美国回来创业的小团队，他们采用敏捷方法，他们构造了一个让我们看起来，让我作为一个ThoughtWorker看起来都非常羡慕的工作环境。也有国内的互联网企业，他们在自己的办公室里面，搭建起来一个敏捷的环境，然后他们遵循了敏捷的日常的要求。也有更大的组织，他们在也许比较小的范围内，也许一个项目的范围内搭建起了敏捷的环境，所以这些问题是存在的，但是没有什么问题是不能克服的。因为如果说敏捷，实施敏捷能够给你带来切实的利益的话，那么就没有什么问题是不能克服的。

   

9. 敏捷如何降低风险呢？

那么提到风险的问题，我们知道在风险管理里的理论里面，讲到你在面对风险的时候，有几种基本的策略，第一你可以选择回避，我知道这个地方有风险，我就索性不干这件事情；第二，你可以选择包容，也就是说我知道前面会有危险，但是我们走过去看看，等到出现问题的时候，我们再看，出现一个坑跳过去，所谓逢山开路遇水架桥；第三可以防范，可以提前的去为未来的风险做准备；第四，你可以选择什么都不做，可以双手合十，然后祈祷上天保佑，那么对于大多数的团队和大多数的情况来说，回避和忽略都不是好的选择，因为没有风险就没有成功的机会，没有收益，而忽视风险的话，不是一个好的选择。所以大多数情况下，我们是在选择包容或者防范，那么如果说要防范风险的话，我们往往需要付出很大的成本，那么怎么能把这个成本变小？很简单的一个办法，化整为零，把你的风险从一块很大的风险，变成一个一个一个的小问题，那怎么能够把你的大问题变成一个一个小问题？答案也很简单，加强反馈，让你的工作尽快的拿到客户面前去，接受客户的验证，然后客户告诉你做的对不对。有这么一种说法，说软件开发是一种变魔术的事情，你这个在分析需求的时候，他想的是业务的一件事情，然后呢，软件开发者就是要得到的是一个技术的东西，至于中间怎么把业务变成技术的，就变魔术，嘭一下就变出来了。那么敏捷所做的事情就是，让这个魔术变的小一点，每次变一小块，变出来给客户看看我们变得对不对，那客户说变得对，然后我们再接着变下一块，这样子你可以有效的避免，你因为犯一个错误，变错了一个大魔术，而造成巨大的损失，所以这是敏捷对于风险控制的一个重大贡献。

   

10. 对于我们中国的观众会非常感兴趣的一个问题，就是中国这个大土壤吧，这么广阔的这个土壤，到底有没有可能孕育出一整个敏捷的大环境呢？

首先，就是像我一开始说的，没有任何理由说敏捷不适合中国，对吧？那么中国的企业关键是在于，这不是说你去选择适合它或者不合适它的问题，而是在竞争越来越激烈的情况下，企业必须去想办法消除浪费，提高效率，否则这个后果就不言自明了，所以这不是说中国的环境适不适合的问题，中国的环境一定适合，一定会有企业，一定会有敏捷的企业出现，活下来的企业会变得越来越敏捷，但是另外一方面，要让一个软件企业，一个软件团队一个项目敏捷起来，他需要很多的工作要做，一方面，这个团队的组织结构，工作方式，需要很大的改变；第二，技术，他所采用的技术，因为现在我们可以看到，像C和C++这样的语言工具已经用的越来越少了，那么当你使用这样的工具的时候，我们可以毫不犹豫的说，C和C++是开发效率比较低的，相对于Java，.NET或者更多的更新的技术来说。那么当你在使用这种开发效率比较低的工具时候，你就很难让你的团队敏捷起来，因为你要把很多的时间花在希望做这些事情上；很难说让你的客户参与进来，大家能够很有效的交流起来，那么而当我们换到了Java、.NET，这样的开发效率比较高的工具之后，有些事情就会发生了。大家的交流频率可以变得更频繁，客户可以有机会，比如说每周，每两周看到我们做了哪些事情，那么随着向Ruby on Rails这种技术的出现，有一些更多的事情会发生了，客户不是每周，每两周看到我们做的事情，他可以每天看到我们做的事情，他可以每天看到他想要的这个网站在发生变化，然后给我们现场的反馈。所以这个是可想而知的，你每过两周想出来的反馈与当天的想法这是，这种有效性，信息的有效性是有明显的区别的，所以，就是说当我们在谈论敏捷的方法的时候，绝对不可忽视的是技术，有这些技术让你的开发、集成、测试，各个环节的工作变得高效以后，你才能够谈的上让客户，让团队高效地交流，你才能够谈得上，用大量的精力去提高你的质量。从敏捷这个词就可以看得出来，敏捷就意味着“快”，当然我们知道它并不是仅仅是指开发快，但是做事快，这必然是它的一个组成部分，所以选择合适的工具，同样是一个团队想要变得敏捷的重要的一方面。

   

11. 每一种过程方法都会有相应的最适工具集合，那么人能谈谈就是敏捷到底有没有适用于自身过程的最适工具集合呢？

首先这个工具集合肯定是存在的。但是呢，另外一方面，他又不是一个固定的最适应的工具集合，因为就像我一开始说的，在敏捷的项目里面，很多时候需要根据自己的情况来选择你需要的工具集合。那么根据大家的经验总结已经可以看到一些工具，可以说是敏捷项目里面必不可少的版本控制的东西，一个团队必须有版本控制Subversion，或者CVS或者之类的；那么在有了版本控制的工具之后，单元测试的工具，这个Java的JUnit、TestNG等等，有了单元测试的工具之后呢，你就可以开始进行测试驱动开发，当你开始进行测试驱动开发以后，下一步就是要让这些单元测试，不仅仅是在你的开发机器上运行，而是在整个团队的层面上，在团队共有的代码库的基础上运行，这个时候，你就需要持续集成的工具，比如说Cruisecontrol等等，当然如果是一个Rails项目的话， Cruise control到RB，那么，在如果你要运行，在一个持续集成的环境下，运行你的测试，集成你的整个应用，那么你需要自动构建的工具，比如说Java的Ant，Ruby的Rake，包括C，用C编程的时候Make，都是这样的工具。好，那么现在你有了单元测试，你有了持续集成，下一步是这个项目仍然要给用户，或者说用户要验收它，用户的验收测试，同样是应该并且能够自动化的，那么用户验收测试的工具，对于Web项目的话，比较常见的就是Selenium，这是一个Web项目的验收测试工具。那么在把这个，在把软件生命周期扩展开来一点，还可以看到，部署和维护也需要自动化的工具。这个时候由Ruby on Rails可以用Capistrano来部署。部署环境，也需要一个自动搭建的布置环境，例如Ruby on Rails的项目可以用Rubywork来部署。那么再把这个项目周期，项目的生命周期延伸开，整个项目的管理、需求获取、需求的监控、项目的进度、项目的统一数据等等，这些东西你也需要适当的工具来管理它，也许不是一定，也许你可以有更好的方式，也许你需要一个工具。那么这方面的工具，我们同样需要找到一个适合于敏捷项目的工具，因为工具实际上它是融合了你做事的方式在里面，所以如果你想要找一个敏捷项目的管理的工具，你需要一个融合了敏捷的工作方式的工具在里边，那么例如说像ThoughtWorks的Mingle，这是一个适合于敏捷项目的管理工具，所以，现在我们可以看到，从项目管理、需求分析，到开发、测试、集成、部署，各个环节上面，都已经有现成的工具存在，那么是不是说把所有这些工具拿到一起来，就形成一个敏捷项目呢？答案是肯定的不对，因为你需要根据项目的情况来选择适当的工具，并且把敏捷的实践融汇到这些工具里面，这样你才能得到一个真正敏捷的项目，而不是一堆工具的堆砌。

   

12. 那么如果我们想让自己敏捷起来，那么我们应该怎么做？

我自己经常看见的一种情况，是在很多的论坛上，或者是私下交流的时候，别人告诉我，他觉得哪一个敏捷实践也许不好用，他觉得结对编程是在浪费时间，他觉得测试驱动开发很难进行下去，他觉得重构没有什么价值。但是，有趣的现象是，很少有人说，他这样做了以后，他感到这样做不对，更多的反对的意见，或者说质疑的意见是在说“他觉得这样不对”，那就说明什么现象呢？说明似乎在我看来，大多数人在真正的着手采用敏捷实践以后，他感到了这对他有帮助，而更多的这种怀疑是来自于仅仅是在读书，通过自己的猜想，而非实际的体验，来得出的这样的怀疑。所以，对于想要了解敏捷的个人也好，团队也好，我的第一个建议是——去做，去把这些敏捷的实践做起来。从哪里开始呢，我觉得第一件事情，开始写测试，为你的程序写上测试，哪怕你没有做到测试驱动，先把以前的程序补充上测试也好；第二步，建立起你的持续集成环境，让你的项目能够时刻的保持在一个健康的状态，当你做到了这两步以后，呢，你会发现这时候你可能开始结对了，因为你有测试来作为这种代码层面上的交流途径，所以你可以开始结对了，同时你会发现，你可以开始实施短迭代了，因为你有一个持续集成的环境。你可以随时的发布一个可用的软件，这个时候，你就可以做到，只要你喜欢，你就可以做到每周或者说更短的时间，每二天三天，让客户来看一看这个可工作的软件到底是什么样子，所以从这些最简单的事情，测试、持续集成，包括重构，从这些最简单的事情开始做起来，你会发现变化是会逐渐产生的，所以这是我的第一个建议：开始做，从简单的事情开始做起来。那么另一个建议是，如果说出现问题的话，在实施敏捷的过程中间，是很容易出现问题的，并且出现这些问题有时候是很容易打击积极性的，也许你在你采用了一些实践，比如说结对编程，然后在团队中引起了负面的影响，然后如果你一开始说我们是在引入敏捷，也许会让整个团队对敏捷产生不好的影响，所以我的第二个建议是，不要告诉别人你在做敏捷，你只要把这些实践引入进去，去发现你的团队，你的项目中的问题，然后看看有哪一个事件可以帮助解决这个问题，那就去做它。但是不要太早的，太急于说，我们是在做敏捷，只要我做的事情，每一件能够产生它的价值，所以最终你是不是真的在做敏捷，其实不是一件很重要的事情，这是这两点建议大概就是我能给。