敏捷开发模式

简介

是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

词源

敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会

适用性

在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：

组织文化必须支持谈判人员彼此信任，人少但是精干，开发人员所作决定得到认可，环境设施满足成员间快速沟通之需要。最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，20、40人或者更少。大规模的敏捷软件开发尚处于积极研究的阶段。

另外的问题是项目初期的大量设想或快速的需求收集可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常会把不恰当的方案授予客户，而直到最后出问题前都能获得客户认同。虽然理论上快速交互的过程可以限制这些错误的发生，但前提是有效的负反馈，否则错误会迅速膨胀。

对比其它方法

敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

对比迭代方法

相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。

对比瀑布式开发

两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。

有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行。

 

遵循的原则：

·我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
·即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
·经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
·在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
·围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
·在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
·工作的软件是首要的进度度量标准。
·敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
·不断地关注优秀的技能和好的设计会增强敏捷能力。
·简单是最根本的。
·最好的构架、需求和设计出于自组织团队。
·每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

敏捷开发体会

    实施敏捷开发近两年来，我对在产品开发中应用敏捷方法有着深刻的体会。首先说下产品背景。我参与的产品是面向行业的产品，在全世界都有客户，有10年历史，和一百多个基于不同版本的客户，我们的团队完全负责产品的未来发展方向、发布计划、架构、设计、开发进度、测试、客户支持等。在这样一个面向全球的产品和自主的团队环境中进行敏捷开发体会尤其深刻。

    1) 注重概念和架构设计，而轻详细设计

    敏捷开发中，注重概念和架构设计，而轻详细设计。这里的概念设计，可以看成是为什么要做这个产品或模块，强调的是产品的路线规划、市场趋势、客户价值、技术趋势等。架构设计，可以看成从整体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计，则是具体的设计和做法、API接口等。

    一个产品，特别是面向行业的产品，概念设计和架构设计非常重要，需要考虑行业未来的发展方向，产品在市场中横向和纵向的比较，技术的发展方向，和每个模块的投入和收益的比例等，这样才能尽可能保证产品沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎，因为一旦新增模块被客户使用，以后就很难在产品中去掉这个模块。还需要考虑产品各个版本之间的兼容性，以及客户的升级迁移。所以，在开始正式开发之前，通过概念设计和架构设计，梳理思路是非常必要的。

    2) SWOT分析

    以前在做项目时，大多是从技术角度来考虑哪一些功能模块需要做，哪一些功能模块先做，而没有一个系统化的分析方法。造成的结果是有一些功能模块投入很多资源，却并不一定是客户最想要的。

    在敏捷开发中，更加注重客户需求。如果对产品进行SWOT分析，就能选出付出最小工作量，但能获得最大价值的模块。

    SWOT分析阶段会在概念设计和架构设计之后进行，输入是概念设计和架构设计，输出是模块的重要度和需要的时间。这样按照性价比可以进行排序，选出最能符合市场的模块。

    一款产品哪个模块重要，哪个先做，需要花多少资源和时间投入，花这么多时间和资源的模块是否在客户心中有相应的重要程度等，这些都是由这款产品的市场策略来决定。所有产品都是为了市场和赢利为目的，Agile方法更好地帮助企业实现了这一点。

    3) 业务和客户驱动，而非技术驱动

    这点说是体会，也可以说是教训。在我们的产品开发过程中，在某一新版本中重新设计了老版本的某一个重要模块，而引发了几个问题：一是，新版本的模块和老版本模块的兼容性问题，导致老版本客户无法平滑的迁移到新版本；二是，新版本的改进是纯技术方面的重新实现，不管对客户而言，还是对内部的架构而言，都没有明显好处；最后导致的结果是我们花了很多资源和人力去重新实现，但是在最后由于种种考虑还是废弃了重新实现的模块，依然沿用老模块。

    在产品的敏捷开发中，虽说拥抱变化，但不盲目变化。产品的改动需要经过概念设计、架构设计以及SWOT分析后，三思而后行。敏捷开发中也强调"在整个项目开发期间，业务人员和开发人员必须天天都在一起工作"，确保技术人员能够开发出客户需要的产品。

    4) 时刻考虑版本兼容性

    敏捷开发，废除了过多冗余的文档和繁杂的设计，强调拥抱变化。但作为产品，敏捷开发不意味着盲目地去变化。

    当设计变动、API接口重构、配置文件变更时，要时刻考虑产品的架构、规划路线图，老版本的兼容性，及迁移平滑性。否则，随着版本的增多，必将面对着大量的维护工作。

    5) 轻文档，但非无文档

    敏捷开发强调沟通的重要性，而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程中，适量的文档还是很有帮助，有助于整理思路，加快沟通和讨论。

    我们产品中的文档包括：概念设计文档、架构图、当前版本要实现的功能列表，以及SWOT分析。

    这些文档在每个产品版本开始之前会有产生，在每个迭代的过程中根据业务人员和市场的反馈也会有一些变更。通过我们实践证明，这对产品的思路、沟通讨论都非常有帮助。

    而且这些文档，大多是几页PPT，书写和维护工作都很小