【51CTO独家特稿】51CTO对于实施敏捷过程中，***的障碍是什么？我们先咨询了吴昊先生。
吴昊“其实这个时候我们可能碰到最多的，实际上是一种文化上的冲突。51CTO刚才提到的敏捷，可能敏捷是不一样的。比如从时间角度上来看，敏捷可能是一种功能实践和管理实践，在它背后有12个原则。其实我们认为只要你是符合这些原则的实践都是敏捷实践，而不是说你仅仅有这些就够了，它可能遵守也可能违背最开始的原则。举例说，敏捷的编程，这个时候他可能在很多情况下符合敏捷的原则，但是在很多极端情况下，实际上你是违反了敏捷的原则的，所以这个时候并不是每次都要判断他是不是符合后面敏捷的精神或者敏捷的基本原则，他在每个场景下都会有不同的例子。我基本上不能跟你说有任何实践放在任何环境下都有这样的实践，你需要在一个环境下进行具体判断。
敏捷不能套用生硬的条文
我们往往碰到的问题是，有些实施敏捷的人，他只要实施了全套的实践，那么我就是一个敏捷了，那么在他们实施这套实践的时候，反而是一种非敏捷的方法，或者更重视这样的过程，所以和他们开始的意愿是违背的，这个时候从实践来看做的都是对的，只是他们选择采取这样的时机和方式不是很好的时机和方式，使得他们看上去是敏捷的实践，实际上并不是。那这样的话造成这样的情况，我们最常见的敏捷障碍就是文化上的冲突，当一些企业管理者，他有这些变革式的方法的时候，他希望来保持我原来的生产效果，他不希望受到我新鲜事物的影响，然后他又强调你这个团队应该是以新的方式来工作，那么我们都知道当你掌握一个新东西的时候，你都有一个学习阶段，在这个阶段相比原来的时候，生产效率会有所降低，但是从他的决策人的角度来看，往往我们听到一些使用敏捷的时候都会说，在不影响现在的进度下使用这个方式，在这个前提下，当你跟敏捷的原则产生冲突的时候，往往这个项目决策人，项目进行前提会远远高于你的新的实践，就会造成很多团队在实施过程中他们自己也会觉得我们的实践是违敏捷的，是走样的，他根本上仍然是你的最终的团队决策人，他是不是真的接受了敏捷的思想和文化，我真的愿意拥抱这样的思想和文化，从而通过文化上的转变带来生产效率的提高，还是仅仅把它当做一种工具和一种新的过程，比如瀑布式，敏捷式你也可以强制的定义成这样的过程，那是不是还有它原来的效果，这些都是我们不清楚的，12原则之上的敏捷宣言，里面最重要的一句是人是重于交互和工具的，这一点来说敏捷是发挥人的主干创造力和能动性，我们充分信任每一个人的能力，激发他们的创造力从而提高这样的生产效率，而不是我们通过定义你的过程，使用你的工具提高你的生产效率，实际上当你能不能真正地接受这样的文化，消除这样的冲突，我觉得这个可能是，我们看到遇到很多问题，最终都能够归结于这样的冲突。”
对于宋金永先生，我们感兴趣的是他们在日常的工作中，会用到哪些敏捷工具？
宋先生说“工具方面也是我们在敏捷之前，也是预估到的，是一块比较大的工作，我们这一块逐步地引入一些工具，在需求管理上我们逐步引入一些管理需求上的工具，比如EXCEL的表格，可能我们能够定制一下一个规范，我们就形成了FutureList，这个是一个小工具，大家把它用起来了，也有一些产品线属于自发性比较好，他开源也好，网上也好，他会下载一些软件，他会管理，甚至形成状态图，都有这样的应用，后来慢慢地我们就发现可能对工具的统一也是必要的，后来我们自己也在尝试做需求管理这一块的工具，这是一方面。”
“另外一方面可能工具的大头还在工程方法，比如单测，原来我们这边，因为很多产品线，他们也是有自己的选择，比如我是用CB的，还有用其他的，后来我们发现在这一块是有成本的，为什么？就是它的代码风格，框架不统一的时候会带来很多问题，这一块我们再统一掉，就是我们有统一的测试工具，我们有开发组专门做开发的，另外今天上午马汀大师也在讲持续集成，半年多之前我们开始在准备这个事情，也在开发这个事情，应该说初步的东西我们已经看到自己的持续集成平台了，但是后面的路还非常长，因为我们发现这种工具首先可能是解决***步问题，后面的工作绝对是重头戏，需要用各种方法，包括实践上的，包括一些前期的引导的，还有和产品线具体合作的，类似的规律都要去做及可能我想到的工具主要这几大块。”
51CTO记者表示，在与一些程序员进行交流的时候，他们有一种想法，敏捷这种东西还不如原来用的瀑布式，觉得那样开发起来，熬两个晚上就开发出来了，也很好，老板也很满意。所以他觉得敏捷的东西很虚，甚至于特别在一些小规模公司，那么几个人，他们认为敏捷的方法很不适合他们，您觉得他那种想法是对还是错误的想法？您对于这种规模比较小一点的公司，在运用敏捷上有哪些方面的建议？
徐昊：这个其实很有意思，其实我很难评判你刚才说的情况，到底敏捷更合适还是现在的方法，很难评判，但是我想强调一点，当敏捷在强调效率的时候，好像我刚才讲的，会有工程实践，管理方法等等等等这些东西，当你做出任何一个决定的时候，都是这些东西平衡之后的结果，对于任何一家公司都存在这样一个风险，比如这个人他很快，他花一两天把这个做了，花一天可以做好这个工程，但是当你有了代码的时候并不代表你拥有修改这个代码的能力，可能只有他自己一个人，别人谁都看不懂，但是他写的代码除了他自己，别人想理解要花很长时间，在这样的情况下，实际上对于公司而言会存在一种人力风险，如果这个人明天他不干了，走人了，他说我代码都放在这儿，不能是完全正确的，老板有没有评估我需要花多少精力和时间，这个里面可能是非常高的成本，也可能非常低，我并不能说一定非常高，但通常而言他可能成本相对而言要高出我们的想象，因为其实很多人我们并没有意识到这样的成本，当我修改别人的代码，我得读懂它变成个人理解的时候都会变得很困难。所以这个时候你就会理解敏捷方法它看上去慢，但是它是宏观考虑，我承认当你做探索性开发的时候，效率并不高，如果其中有一个人能力很强，应不如他自己开发的效率更高，这个我们是能观察到的，这个并不是通常情况，很多情况下，往往是这样的，它是一个探索性的，大家都不知道什么样子，人与人之间的能力又差别很大。之所以要做决策编程，就是把你知识壁垒的风险降低，我有一个人放这里，你必须要让我能够理解你在做什么的情况下，实际上你在做的是知识传递，那么你在这种过程中，实际上每时每刻都在培养我一组人，而不是一个人了解你的代码，而实际上你是在培养一组对你这个代码有修改能力的人，这个效率是***的，从宏观角度来讲，它的效率是非常低的，甚至有过了一两年之后，你自己再过来看，很可能你都不知道，所以让一个人保有一份独有的知识对于任何一个公司都是极大的风险。
很多企业在做这样的事情的时候都会有这样的困扰，比较初期的公司，他需要很长时间，那么在这样的时候，我可能会做很多培训，可能效果都很小，那么其实真正地让一个人很有效地承担方式就是把它放到一个能力的极限应用这种环境下面激发它，在这样的情况下他自己做可能承担很大的风险，找一个人跟他一块儿做，对于有经验的人他觉得沃德效率降低了，因为你自己做，我带另外一个人可能效率会很高，那么这个里面有一个宏观的问题，不仅仅是把工作做完，如果仅仅是这一个标准，我们有很多效率更高的方法，当你在做敏捷时间的时候，让它变成囤积知识，让成员整体能力提高，那当这四个放在一起的时候，哪个更高？综合来看敏捷更高，因为它解决的问题不是单一的问题，我们解决任何单点问题都有更高的效率，但是你想同时解决一些问题的时候，我个人感觉敏捷方法是更高的效率。
左为吴昊先生，右为宋金永先生
【编辑推荐】
