中国的敏捷之路

【前言】中国的敏捷之路由文秘帮小编整理而成，但愿对你的学习工作带来帮助。但有过传统需求分析的经历的分析师和开发人员应该都知道，首先，需求分析是最难，也是最关键的一环，只有前期需求分析做的精准和到位、全面，才能最终开发出符合业务需求的系统。但问题是，他们有进度的要求，不可能无限制的延长需求调研的时间，总感觉需求调研没有完...

理论上说，敏捷的天生优势，应该让中国企业们都积极地拥抱才对，甚至借机开创敏捷外包之路。那么，事实是这样吗?

敏捷开发、Martin Flower、ThoughtWorks，这算得上是几个在2005年前后最能刺激我耳听的几个词汇了。2006年前后的中国，对敏捷开发的认知还处在一个相对较低的程度。为了传播敏捷思想，一向低调的Martin Flower频频现身说道，这不仅说明敏捷本身能带给软件业颠覆的转变，也更说明Martin认为敏捷能给中国市场带来巨大价值。

中国先期通过制造业外包，走出了一条中国特色的制造业崛起之路，同样，软件开发外包也有望带动软件产业的整体提升。正如ThoughtWorks中国区总经理郭晓所说，“敏捷开发方法可以非常有效的解决大量外包开发过程中所面临的问题，以很小的代价快速开发出高质量的软件。”那么，敏捷开发的核心思想究竟是什么样的?发展到今天，敏捷思想在中国的生存状况如何?在开发过程中，它又是怎样帮助开发者提升价值的?

传统软件开发的“革命”

在传统软件工程方法中，软件开发的生命周期固定的划分为若干顺序的阶段(需求、分析、设计、实现、集成测试和维护)。这种方法的弊病就是必须尽可能的调研完所有的需求才能实质进行编码，不完成上一个阶段就不能进入下一个阶段；测试和集成是对开发阶段的辅助或收尾，形式上意味着项目的结束等。

但有过传统需求分析的经历的分析师和开发人员应该都知道，首先，需求分析是最难，也是最关键的一环，只有前期需求分析做的精准和到位、全面，才能最终开发出符合业务需求的系统。但问题是，他们有进度的要求，不可能无限制的延长需求调研的时间，总感觉需求调研没有完结。而且无论是在有限的时间里需求调研的不准确，还是在设计、开发等阶段需求已经发生变化，都有可能影响到最终项目的交付质量。

这样就难免影响到项目的进度、交付质量，甚至使项目处于不可控的境地，产生预算的无底黑洞。在这个过程中，就产生了一对无法调和的矛盾：需求调研时间纬度是越长越好，项目交付经度是越短越好。

事实情况表明，在前期做到一次性的全部需求调研到位，不仅是不可能的，而且也是没有必要的。

在项目实际运行过程中，真正起作用的是，其中一些切合业务需求的核心功能。前期只需要用20％的时间就能获取整个项目80％的需，求(这已足够满足整个系统开发的需求)。

从“时间一需求”曲线上，我们就能看出，随着时间的越发延长，需求的获取处在一个下降的状态，而且这些需求相对那些前期需求来说，已处于次要地位。如果有必要，在后期有80％的时间已足够获取20％的边缘需求(当然，这也要求系统有很好的扩展性)。把握住一些关键需求并保证系统的快速上线，不仅在时间上了占领了战略高地，而且也很好的满足了业务需求。

敏捷方法就是这么一种符合开发规律和适应软件开发向更高层次迈进的思想和理念。“敏捷是对传统开发的部分否定，敏捷最重要的一点是，如何使开发的软件创造商业价值，软件的成功不是短期内上线就结束了，而是要在后续的使用中适应市场的变化，实现业务对IT的需求。”郭晓说，“为实现这个目标，我认为有两点不同，一个是反馈，即重视变化，另外一个就是与其做出计划，按照计划执行，不如做出流程，使之能更好的适应变化，我们必须承认未来是无法预测的。”

敏捷走到了哪里?

想当初2005年，Martin第一次来到中国，向中国的软件开发人员介绍敏捷软件开发方法时，“敏捷”在中国还是一片空白。我们也已经看到，敏捷从“一生下来”不仅从根本上消除了传统软件开发的诟病，而且它还具有了很多天然优势。那么，软件开发企业应该都很积极地拥抱敏捷，迅速的从传统开发切换到敏捷开发才对。难道，现今软件开发已走到非敏捷不可的地步?

“从目前情况来看，中国正处在一个刚起步、快速向上发展的阶段，远远没有达到广泛应用的地步。更多的讨论是集中在技术方面，现在只有部分企业尝试使用，没有达到在所有企业有效使用，普及度不及澳大利亚，”郭晓补充到，“2005、2006年敏捷方法在中国受关注程度才逐渐升温，而欧美在2004、2005年已经在广泛使用敏捷方法。中国很有可能在澳大利亚接受的2～3年内就达到普及，或者也可能会花费更长的时间，这就存在一个时间差的问题。”

据了解，敏捷的基本思路运用的很早，2000年就在欧美提出来了，在之后的3～4年里发展比较快，目前，在财富500强企业中，绝大多数都在使用敏捷开发。ThoughtWorks2000年时在澳大利亚成立了一个分公司，但并没有很多企业在用敏捷，到2004、2005年开始有大量企业询问怎样做敏捷开发的东西，悉尼东海岸绝大多数金融企业都在进行敏捷开发，它成为一个主流的开发思想。

Thoughtworks作为敏捷开发的身体力行者，从1998、1999年就开始做敏捷，同时铸造了敏捷的企业文化。对于新人职员工，ThoughtWorks都会有一个敏捷技能和思想的培训。

“Thoughtworks 100％的项目都是用敏捷的方法，但在行业里所有外包项目中，敏捷的普及率还不到20％，”郭晓告诉记者，“不同的客户介入程度，限制了敏捷的方法在某些项目上的应用。比如ThoughtworkS在印度的公司，在项目拿到印度去做时，前提是客户愿意使用敏捷的开发方式，愿意进行沟通，愿意先不把需求完全规定好，然后采用可以变化的方式来完成项目。”当被问到，是否因推广力度尚有待提高时，郭晓停顿了一下说，“虽然敏捷的思想很好，能实际帮助用户解决问题，但中国用户属于慢热型，这需要一个过程。”

能否走出一条敏捷外包之路?

在采访中，笔者了解到，Thoughtworks一直注重的对新人职员工的敏捷思想培训大多放在印度的班加罗尔进行。以敏捷为主导文化的Thoughtworks在印度的敏捷推广，虽然取得了很大成效，但成果并不是相当明显。

毕竟长期以来，印度作为接包大国，根深蒂固的传统开发方法占据了很大一部分主导作用，除非客户做出要求。他们大多采用CMMl5的开发方法，强调的是商业合同，比如GM、GE有大量的项目外包到印度。CMMl5对项目的范围、时间、价格的控制要求非常高，它自然有它的价值，但在某种程度上损失了很多利益。比虹需求定制完成了，印度公司六个月后能做出完全满足需求的产品，

但业务可能已经发生变化了，辽得进行修改，开发二期或三期，当然实现功能的改变还需要相当长的一段时间。

我们一直羡慕印度的外包之路，也着意把软件外包作为整体软件产业的一个突破口。那么，我们可不可以从敏捷开发上找到外包出路呢?

对发包方来说，他们不仅要考虑接包企业的规模、人员素质，他们也更注重最终业务需求的满足。项目交付了，然而需要又变更了，无休无止的bug修补，看不见底的经费黑洞，甚至最后连最初的架构都要推倒重新设计是很可怕的事情。即使交付速度再快，缩短在6个月以内甚至更短，需求改变或新需求发掘都是不可避免的事情。与其苦苦等待的结果是过时，倒不如“持续的需求获取”，实行对企业紧密跟进。

因此，对中国来说，由于没有印度那么重的历史包袱，更容易实现“轻松转身”，走出一条中国特色的敏捷外包之路。在这个过程中，必然有很多困难要克服。接包企业要从思想上认识到敏捷的优势所在(当然这要得益于整个国内大环境的营造，需要各方的共同努力)，同时要与客户直接接触，建立起充分的信任关系，这样的需求满足才是及时和精准的，IT才是符合业务驱动需求的。

链接

沟通，沟通，再沟通

也许是ThoughtWorks的传说增添了它的神秘色彩，使我对它充满了好奇和期待。而当我真正近距离碰触它的“脉搏”，我才真切体会到外界所谓的它的那些“与众不同”，感受到它展现的生命跃动和所进发的旺盛生命力。

特色一：在这里，你看不到所谓的经理室，有的只是以项目为划分的一个个圆桌团队。当时我们正赶上几个圆桌在进行传说中的“站立会议”，有时也伴有激烈的争论。

ThoughtWorks人员郑钧鸿告诉记者，“在ThoughtWorks每天每个团队都会进行一次站立会议。每个成员要说出昨天做了些什么，今天会做些什么，遇到了什么困难是否需要别人的帮助等，站立会议鼓励每个人说出事情的真相。而且也鼓励团队的成员们遇到问题随时都可以自由沟通。”正是这种随时随地的沟通，使项目的执行能够达到很好的效果。这也是创建者Roy所秉持的企业文化的其中之一的“道”。

事实上，在ThoughtWorks沟通不仅仅局限于项目团队内部，甚至在公司高层身上，也体现了极致的平等和尊重。他们喜欢和员工打成一片，有时会上来拍拍你的肩膀然后叫你的新外号，有时会和你讨论他们最近的尴尬经历，甚至吃饭时被员工灌醉，这种平等和尊重也更说明在厂houghtWorks，沟通是无障碍的，ThoughtWorks的沟通还不仅仅局限于工作，同时还是渗透到生活中的。

特色二：在ThoughtWorks，随处能看到一个个小卡片贴在所谓的“需求墙”上。这已经成了ThoughtWorks一道独特的风景。“你可千万别小看了这些卡片，”郭晓告诉记者，“由于卡片很小，这就迫使BA(BusinessAnalyst)不能将太多的内容放在同一张卡片中。另外，短迭代周期很短，通常是两到三周，就需要给用户展示一些主要的功能，这就要求团队思考哪些是核心需求，首先需要解决，用多长时间。第一个迭代周期能完成多少卡片，开发进度如何”等一些很重要的问题。

其次，卡片可以灵活移动，表示不同的进度状态，在办公室走一圈就知道每个项目的进展程度。同时如果处理不同卡片的小组需要彼此沟通，可以快速在卡片墙上锁定对应负责人。

特色三：说起ThoughtWorks，也就不能不提到它的结对编程。开发人员以两个人一组围坐在一张张毫无等级之别的办公圆桌旁，他们时而笑意交谈，时而激烈争论。“这就相对于一个监督激励机制，不仅是对工作内容的监督，而且也是对工作态度的监督。”郭晓半开玩笑的说道。

结对编程的初衷是其中一个人在编程时，另外一个人在做“codereview”，第一时间提出反馈意见。其实，结对编程的价值不仅仅在于此，当一个资深人和一个刚毕业学生结对时，这就相当于在手把手教他东西。这也就保证了每一时刻都写出高质量的东西。

事实上，结对思想不仅仅局限于编程中，在ThoughtWorks，很多事情都是结对的，老师们结对讲课，学生们结对演讲，结对研究新技术，结对做课后作业……