（Stakeholder）都要参与到产品的需求分析，设计，以及其他活动的决策制定中来。致力于在短时间内帮助团队实现将客户的需求转化为高质量的可消费产品，并转化成利润。

回页首

敏捷开发的商业价值

敏捷开发自 2001 年《敏捷宣言》（“AGILE MANIFESTO”） 1 的创生，经过多年的打磨和退火已经成为今天非常流行和有过许多成功案例的开发模式。正如前人所说，传统的东西就是用来打破的，传统的瀑布式开发模式必然逐渐退出历史舞台，敏捷开发、敏捷测试是在新环境里产生出来的打破传统的新开发模式。而敏捷也将会在将来，甚至现在转化成更适合现代化软件开发、测试团队的方法和实践。在本文的第一部分，我们以两个游戏类比了敏捷和传统开发的差异，这里为了进一步帮助大家对敏捷的价值有更清晰的理解，我们借鉴前人的研究结果：

图 2. 敏捷与传统开发的比较

首先敏捷开发过程比传统开发要为项目和产品带来更低的风险（RISK）。为什么呢？传统开发缺乏持续的客户反馈 , 产品一旦从需求阶段退出，整个开发团队近似封闭工作，团队虽努力去实现曾经认定的目标，但因月有阴晴圆缺，市场需求也瞬息万变（例如提出需求的客户已经退休）。这使得产品在数月后，数年后发布时已经失去了占领甚至进入市场的最佳契机。

而如果你还在考虑使用传统开发模式用现在乃至将来一、两年的时间来开发一个结构复杂，精益求精而又功能庞大的产品，那么你得好好做好失败的准备了。而正是因为出于对这种风险的考虑，越来越多的人认识到敏捷开发要比传统开发能够为企业带来更大的利润空间和更低的投资风险。

其次，利益干系人（Stakeholder）的频繁参，与使得团队在产品开发的各个环节遇到的种种问题得

到了及时的解决。因此，我们认为敏捷开发拥着比传统开发更大的透明度（VISIBILITY）。作为老板，项目的负责人一定对这样的开发模式带来的可控性充满了向往。

团队或者产品的适应能力（ADAPTABILITY）也决定着其生命力，因为敏捷开发模式鼓励团队采纳新技术，欢迎变化，并能够快速应对之，使得产品和团队自身都有很强的适应力和生命力。而在传统模式里，当需求变更时，复杂的变更管理流程要求通过正式讨论、审批，也备以足够的文档和说明来支持每次“决策”。这不但带来了人力，物力的浪费，更重要的是它严重延长了企业投资到利益回报的周期。而只有拥有反应迅速的敏捷开发才能够帮助企业赢取市场，降低风险。

以上我们谈及了敏捷开发拥有的比传统开发能为企业带来更大的商业价值和提供企业更大的发展空间。而对于个人而言，笔者认为敏捷开发也提供给了个人更多的发展机会和提出了更高的要求。以下是笔者从个人角度做出的分析。

回页首

敏捷开发有益于个人发展

敏捷项目首先拥有一支支小规模但职能全面的团队，在这样一个普通的敏捷团队里，拥有具备不同职能的 7 名成员，1 名 UCD(User Centered Designer)，1 名 Visual Designer，1 名测试人员（Tester）， 1 名 Information Developer 和 3 名开发人员（Developer）。因此，每一支敏捷团队中的设计、开发、测试、美工、文档等等工作分属给了这个团队里不同的，唯一的人。每个人在团队里因而必须具有对其所涉及领域强的责任心和领导力。就测试而言，测试人员就是好比一辆跑车里的唯一的驾驶员，项目就好比这辆跑车，测试人员需要及时修正行驶方向的偏差，确保这辆车在正确的道路上稳步前行。如果，测试人员没有具备足够的责任心和领导力，只是人云亦云，恐怕这种测试要与不要没什么分别，敏捷项目的质量也更让人担忧，而敏捷也就失去了原有的意义。因此，作为唯一的测试人员，他（她）将拥有对测试的所有权，计划、设计并且执行所有的测试工作。而也因为拥有了更多的主人翁精神，积极的工作热情，测试人员勇敢的面对工作中的各种挑战，学习新的知识和努力培养自己的工作技能。敏捷无疑对个人发展产生了很大的推动作用。

敏捷团队中的每个人，需定时和团队的其他成员坐下来看看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。也需适时的寻求团队中其他成员的帮助解决时下紧要的问题。通过频繁的合作与沟通，个人的协作能力、沟通能力也得到了较大的提高。下面我们具体就这两个方面进一步谈谈敏捷开发是如何帮助提高个人的协作能力和沟通能力的。

敏捷开发培养了个人的协作能力

与传统开发不同，敏捷开发更加侧重以人为本，发挥人的积极性，以此提高团队的工作效率。真正实现以结果为导向的职场守则。作为团队的一份子，无论是测试、开发人员，还是设计人员，他们都将为团队成败担当不可或缺的责任。团队是高度协作的团队，个人除了做好本职工作外，敏捷开发模式要求个人能够了解和争取更多的扩展性的工作，也能帮助团队其他成员解决他们的遇到的各种独特问题，以加快实现团队的统一目标，即在更少的时间里生产出能够推向市场的可靠产品。 这里再次提及高度协作，笔者认为高度的团队协作主要表现为以下特点：

1. 团队成员积极分享经验，知识，自我培养所需技能和自我成长；

2. 团队成员相互帮助，愿意成为他人后备队员，随时做好准备投入新的战斗，因而保障了团队

的高昂士气和强大的生命力。

3. 任何决策是团队共同的决策，工作是团队共同的工作，团队工作的最后成果因而也是来自团

队中每个人的辛勤培养和贡献。而团队的失败更是整个团队的失败，绝不会是某个人的单方面的过失。这种荣辱与共，共生共息的信念将让团队的力量超过团队各个力量之和。同时，项目团队的工作效率在团队成员技能的提升和信念的巩固中不断提高

敏捷开发锻炼了个人沟通能力

我们把团队看做一个高度协作整体的同时，不可忽视的是团队内部仍存在的各种矛盾，对这些问题的听之任之将破坏团队的凝聚力、生产力。这中间反映出来的很多问题不是敏捷方式独有，但团队成员因为敏捷，学会了自己解决各种问题。而相应的沟通能力也随着问题的解决得到很大幅度的提高。 在过去的项目经验中，我们不难发现种种人与人之间矛盾的产生。而经典的矛盾论也让我们不得不的接受，矛盾是永远存在的，但这并没有什么可怕。而是一旦我们发现了矛盾的存在，就要迅速找到解决办法，这也是团队的相当重要的工作。尤其是在团队组建初期，团队开始采纳新开发模式时，锻炼团队解决如下矛盾的工作非常重要：

? ? ? ?

测试人员是质量的工程师，开发人员是产品的缔造者，在对质量标准的认同上常有不一致（当然，传统开发也会产生）；

UCD 的设计实时反应用户需要，但有时不能顾及代码的可实现性；

开发人员而却更喜欢用想当然的理解，和习惯的方式填写代码，甚至主观的抵制接受新设计思想和拒绝新类型缺陷的修复，因此与团队的整体目标、出发点产生分歧；

从整个项目组织结构看来，敏捷团队之间（一个项目通常有多个敏捷团队组成，各个团队有自己的侧重点）存在设计，开发的不一致性，这使得产品在整合阶段产生额外的成本。

正如前面所论述，矛盾总是有能够解决的途径，敏捷项目的组织中用管理方式去干预是一种直接、快速的方式，而今天敏捷方法论者们更加推崇的是鼓励团队内部进行很好的交流和沟通后自行解决。也正是通过不断加强团队间和团队内部的相互理解，不但矛盾得到很好的解决（解铃还须系铃人嘛），个人的交流和沟通技能也得到了进一步提高。

回页首

敏捷开发培养了个人的创新意识

创新能够为企业带来新发展契机，创造新价值，因此，创新对于企业还是个人而言都非常之重要。不断培养员工的创新能力、鼓励创新活动也是几乎所有企业的人才培养战略之一。而敏捷开发恰恰就是要打破传统的模式，形成全新的敏捷开发、敏捷测试方法、实践和过程，并鼓励团队采用新技术和技术创新。因此，团队的每个人需要能够创造性的工作，并乐于接受新事物，通过不断的改进、突破过时的做法，努力提高团队的工作效率，来适应产品的增量发展需要。

而也因为敏捷开发模式对于很多团队仍很陌生，在运用敏捷开发的过程中我们会遭遇许多新挑战、新困难。如何处理这些问题，解决方案本身就是无以借鉴的，自主创新才是唯一出路。

举个例子，敏捷项目初期，产品停留在原型论证和底层架构初步设计中，产品功能不多，复杂度较小，

一般的手动测试就可以将质量保障做好。产品的中后期，因不断有新需求、新功能的加入，产品复杂度增大。团队倘若仍仅凭固有的手动测试方式来覆盖产品的各个功能、非功能点需求只恐怕是力不从心了。因此，考虑用自动化测试来提高团队工作效率是可取的方法之一。但是，当产品发展到中后期，也没有富余的资源可以被抽取出来做自动化测试了。即使现招聘新人，也因为新人对产品不了解，只怕自动化测试的效果也未如人愿。那我们是否应该在开发活动的初期就尝试自动化测试的设计、并自动化一部分功能测试呢？也未然，因为在产品开发初期，产品的功能和界面的变动会比较大，自动化测试收入产出比异常低。因此，何时、何地、如何设计、运用自动化测试来帮助降低人力成本，提高测试效率是需要我们大胆创新的。

回页首

敏捷方法的共同点

以上我们通过商业、个人发展两个方面讲述了敏捷开发的价值和意义。那什么才是敏捷开发呢？在业界又有那些方法是敏捷开发的具体实现呢？各种方法有什么共同点吗？通过下文对各类敏捷方法的共性分析，我们也将进一步了解敏捷的实质。

敏捷方法

业界流行的敏捷开发的方法有许多（要了解各类敏捷方法和分类请参阅本文参考资料中文献），我们需要根据项目大小，性质来选择合适自己的敏捷方法。比如说 XP（极限编程，eXtreme Programming）更加适合小型项目 3-5 人的团队。Scrum，DSDM (Dynamic Systems Development Methodology) 等更加适合大型团队的项目开发。而敏捷开发也不是一成不变放之四海皆准的准则，而是一个方法的最佳实践。各个团体和企业也不断定制着自己的最佳游戏规则。VersionOne 的敏捷开发的调研报告中很好的对比了各个方法被业界采纳的比例（见下 图 3）。这个图表就是 2007 年对来自 71 个国家 1700 多人的调查结果的说明。

图 3. 流行的敏捷方法