什么是敏捷开发？

“什么是敏捷开发？它是一种开发方法学（Methodology），可以应对客户快速变更的需求。它强调以人为核心，采用迭代的方式，循序渐进地开发软件。在敏捷开发过程中，软件项目被划分成多个相互联系但也能独立运行的子项目。这就使得每个子项目在开发、测试直至完成的过程中一直保持可使用的状态。这个过程实际上就是要形成开发过程中团队之成员之间更加有效的合作关系，使其灵活性更高，以适应不断变化的需求。敏捷开发过程与传统开发过程的最大的不同之处在于，在敏捷开发过程中，团队是有激情、有活力的，能够适应更大的变化，生产出更高质量的软件。”

“接下来我谈一下敏捷的价值观。这是在2001年敏捷联盟成立的时候一些业界专家共同提出来的。可以说，只要真正领悟了敏捷的价值观，就能懂得什么是敏捷。”

“我们开发软件时的首要任务是通过尽早地、持续地交付有价值的软件来使客户满意。请看PPT……”

资料库

个体和交互重于过程和工具

敏捷方法认为，人是软件开发中最重要的因素。开发团队成员之间有效的交流、沟通与协作，比单纯的编程能力更为重要。人与人面对面的交流，是最有效、最迅速的交换信息的方式。

可以工作的软件重于面面俱到的文档

过多的文档需要开发人员花费大量时间来维护。文档应该是为程序服务的，因此应当短小精悍、易于维护，而且主题突出。敏捷方法认为最根本的文档就是源码。

客户协作重于合同谈判

客户对产品的需求是不断变化的，试图在合同中规定项目的细节和进度显然无法应对不断变化的需求。只有开发团队和客户之间真诚的协作，加上频繁的客户反馈，才能让项目走向成功。

随时响应变化重于循规蹈矩

客户的需求可能在项目开发过程中不断变化，即使是在合同谈判阶段确定的需求，也可能在客户看见了逐渐成型的产品之后而发生改变。敏捷方法欢迎并且随时准备应对变化。制定计划的时候应该尽量简洁、灵活，使其能适应技术和需求方面的变化。可以说，随时响应变化的能力往往决定着一个项目的成败。

敏捷开发方法的核心思想概括起来就是“适应变化”和“以人为本”。

（1）敏捷开发方法是面向人的而非面向过程的。

敏捷开发认为人是软件开发中最重要的因素，而且人工作的环境很复杂。它希望使软件开发工作顺应人的天性而非逆之，强调软件开发应当是一项令人愉悦的活动，因此它们注重调动人的积极性、主动性和创造性，并培养人在工作中的自豪感。敏捷开发的理念就是信任开发团队能够很好地完成任务，所有的管理都是围绕这个理念展开的。

（2）敏捷开发方法是“主动适应的”而不是“预先设定的”。

瀑布模型等传统软件开发过程试图对一个软件开发项目在很长的时间跨度内作出详细的计划，并形成详细的文档，然后依照计划进行开发。这类方法在计划制定完成后拒绝变化，后期的需求变化将会花费极大的代价。而敏捷开发方法则乐于迎接变化，其实，它的目的就是成为适应变化的过程。另外，据统计，很多软件产品的功能中，客户常用的功能只占20%左右，其他大部分功能是客户很少使用甚至基本不用的。在这种情况下，采用瀑布方式在详细设计阶段所设计出的功能，其实很多是不必要的，这将浪费很多资源。在敏捷开发中，要求客户始终参与整个开发过程，这使得敏捷团队能不断地获得客户反馈，不断适应需求的变更，从而使最终的产品充分符合客户的要求，也极大地减少了资源的浪费。敏捷开发的理念认为未来的开发过程是不可详细预知的。

David讲解到：“关于这里的第二点，我举一个例子。假如你接到的任务是要为一群人盖房子，如果按照传统的软件开发方法，你应该挨个采访他们，了解他们对房子的条件和各项设施的要求，并将这些不同的要求详细记录下来。等这些工作完成之后才破土动工，按他们的要求建造房屋。在房子没盖好之前，他们一直没有房子住。等房子盖好了，如果有人对它不满意，就得拆掉重新盖。而敏捷呢？你可以先了解他们的大致需求，快速盖好一大间可以住的房子，然后再请他们提意见，按每人的意见继续改进，经测试满意后再继续满足下一个人的要求。”

“我再澄清一些常见的对敏捷开发方法的误解：”

“有的人对采用敏捷开发是否能真的有效提高效率并生产出成功的产品表示怀疑。他们认为，在敏捷方法中，由于没有经理的管理和约束，团队和项目必然是一团糟，仿佛越是上层越有这种想法。但是玩过刚才的游戏大家应该有切实的体会，正如我刚才所说过的，敏捷开发的理念是信任开发团队，信任每一个人。试想一下，如果你们这个团队对你们的项目充满激情，而老板又充分信任你们，那么你们必然会将更多的时间花在如何有效地提高生产率、如何创新地完成某个功能等方面，而不是按老板的意思按部就班地工作了，这样还会节省很多时间并简化流程，例如开会、向老板报告、请示老板、等老板批准等。就像咱们刚才的那个游戏结果所揭示的那样，充分调动参与项目的人员的主动性，让他们自我组织、自我管理，由团队自身来掌握项目进度，比老板整天催促反而更有效率。”

“当然，敏捷开发的团队也需要管理，但这些管理是非命令式的，很多时候是战略指导和服务性质的。在敏捷开发中，管理者对团队和项目的管理表现在挑选合适的人、为团队创造一个开放而自由的工作环境、经常性的反馈、为团队建立评估和奖励机制、当团队有方向性错误时能及早发现并纠正、容忍错误的发生等。”

“还有一种误解，认为敏捷开发就是完全不需要计划、文档和架构设计。这种看法也是不对的。敏捷开发也需要文档，也同样要计划。但我们要明白，计划赶不上变化，在这样一个不断变化的情况下要做出详细的计划是不可能的。因此敏捷方法认为不值得在这些因素上花费过多的资源，可工作的软件才是敏捷方法关注的重点。敏捷团队依靠变化来获取活力，他们更愿意使设计保持尽可能的干净、简单。基于以上的原因，采用敏捷方法的项目初始设计是比较粗略的，并需要使用许多测试手段作为辅助，这就保持了设计的灵活性和易于理解性。团队可以利用这种灵活性持续地改进设计，以便于每次迭代结束时的系统都具有最适合于那次迭代中需求的设计。摆脱一切对软件开发不合理的束缚就是敏捷。”

“敏捷联盟的发起人Martin Fowler和Jim Highsmith曾经这样解释过：敏捷开发所追求的是一种平衡——我们也建模，但不仅仅是画几个模型图存放在少人问津的项目文档库里；我们也需要文档，但从不浪费纸张去编造那些极少使用而又没有保存价值的大部头；我们也做计划，但我们同时也认识到在这纷繁复杂的环境中做计划是困难的。”

“但是，敏捷开发不是可以解决所有问题的银弹。在实际的项目中，受条件的限制，有些原则实施起来确实有困难，那该怎么办？要知道，敏捷并不要求你们一成不变地遵循这些条条框框，遇到困难时应该灵活地调整策略，这样才真正达到了敏捷的目的。”

……

培训结束了，关毅听得十分过瘾，会后还追着David问了不少问题，David也立刻喜欢上了这个中国小伙子。最后，David临走前还给关毅留下了联系方式，并表示以后有问题可以尽管和他交流。