《敏捷开发技术及其应用》由会员分享，可在线阅读，更多相关《敏捷开发技术及其应用（6页珍藏版）》请在金锄头文库上搜索。
1、敏捷开发技术及其应用敏捷开发技术及其应用敏捷开发技术及其应用至前几年一直到现在，很多人谈论敏捷开发、研究敏捷开发，实施敏捷开发，那么敏捷开发由何而来呢？究竟什么才是真正的敏捷开发呢?敏捷开发的应用又如何呢？敏捷开发的由来，我想得从软件开发的状态调整说起了。从无到繁重再到敏捷敏捷开发横空出世了。 （下面这段话摘自Martin Fowler 的Refactoring: Improving the Design of Existing Code ）多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix） 。设计过程充斥着短期的，即时的决定，而无完整的规划。这种模式对小
2、系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的影响。 我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择，那就是“正规方法” （methodology） 。这些方法对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践。这些正规方法已存在了很长时间了，但是并没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐，要是
3、按照它的要求来，那有做太多的事情需要做，而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法，或 Jim HighSmith 所称的“巨型” （monumental)方法。 作为对这些方法的反叛，在过去几年中出现了一类新方法。尽管它们还没有正式的名称，但是一般被称为“敏捷型”方法。主要的敏捷方法有: XP（Extreme Programming 极端编程） , Cockburn 的水晶系列方法, 开放式源码 , Highsmith 的适配性软件开发方法（ASDAdaptive Software Development) , SCRUM , Coad 的功用驱动开发方法（FDDFeatur
4、e Driven Development,动态系统开发方法等等。对许多人来说，这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。 敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档。从许多方面来看，它们更象是“面向源码” （code-oriented） 。事实上，它们认为最根本的文档应该是源码。 但是，并不是说文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象，它其实反映的是更深层的特点： 1、敏捷型方法是“适配性”
5、而非“预设性” 。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。 2、敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。 以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心。总之，简单的说，敏捷开发的定义即为敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在
6、敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发背后的思想:人们掌握过程(process)可以分为 3 个阶段：1 following 遵循一个定义好的 process2 detaching 知道不同 process 的适用范围，在不同的场合使用不同的 process3 fluent 不关心是否遵循特定的 process，知道在什么情况下采用什么动作软件开发是一个充满发明和交流的协作性游戏(cooperative game o
7、f invertion and communication)。软件开发的首要目标是生产出软件，遵循特定的过程和模型只是手段，只要传递了足够的信息，手段是次要的。交流的效果要远远重于交流的形式(Effect of communication is more important than the form of communication)。 一般软件开发有两个目标：1 尽快的生产出软件 2 为下一个 team 或项目做准备，有时这两个目标是矛盾的，我们要在这两个目标之间寻求平衡。 （以上一段选自 Alistair Cockburn 在Agile Software Development对敏捷开发
8、背后思想的描述）敏捷开发的方法和原则如下：?迭代式开发、即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。?增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。?开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。?持续集成。新的功能或需求变化总是尽可能频繁地被整合
9、到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。 ?开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。 （摘自Scrum 敏捷项目管理一书）说了这么多，我想敏捷开发的特点显而易见了，那么敏捷开发的优势到底有些呢？下面我们就来说说。敏捷开发技术的特点和优势：1。个体和交互胜过过程和工具；人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员
10、失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。2。可以工作的软件胜过面面俱到的文档；没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造
11、成重大的误导。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是惟一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map） 。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。3。客户合作胜过合同谈判； 不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。有时，失败是惨重的。告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导致
12、低劣的质量和失败。成功的项目需要有序、频繁的客户反馈。项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间，也会出现整个功能块被减掉，而加进来另外一些功能块。然而，合同和项目都经受住了这些变更，并获得成功。成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。4。响应变化胜过遵循计划；响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。计划不能考虑得过远。其实我个人觉得敏捷开发的优势通过下图的对比我们可以很明显的看出。 （例图摘自轻松 SCRUM 之旅敏捷开发故
13、事 ）传统的瀑布软件开发效果示意图 敏捷软件开发效果示意图那么敏捷开发技术的在日常生活中又有哪些应用呢，其实践应用效果又如何呢？首先我们必须明确的是其适用范围：敏捷开发技术的适用范围?项目团队的人数不能太多?项目经常发生变更?高风险的项目实施?开发人员可以参与决策其次我们要了解其实践地位如何。敏捷的核心是什么？敏捷给软件企业（以及软件开发者个人）带来的好处究竟在哪里？这个问题有很多不同的答案。例如“重视个人和交流” ，软件开发者喜欢这样的态度，这是毫无疑问的。例如“重视可工作的软件” ，它的价值是显而易见的。但在这一切的背后，敏捷的核心是什么？时下流行的观点是：敏捷就是软件行业里的精益（lea
14、n）生产，它的核心是消除浪费。ThoughtWorks 中国公司的高层在近日接受采访时明确指出了这一点。首先考虑质量问题。一些软件企业为了降低成本而忽视质量，但质量低下的软件会造成返工的浪费，反而提高成本。相反，在日常工作中投入更多的精力来保证质量，反而能够为企业节约成本。因此说明敏捷开发技术在软件开发行业的可行性及其优越性。许多公司企业也都乐于采用这种技术。最后，很多人也提出了质疑我们是否该走向敏捷呢？当然并非人人都能使用敏捷型方法。当你决定走这条路时，你得记住许多准则。但是，我确切相信，这些新方法可被广泛的应用。只是考虑使用它们远远不够，应该有更多的人来实践中运用它们。 “敏捷开发随时拥抱
15、变化、响应变化，而不是恪守计划。敏捷开发认为，在软件开发过程中，未来是不可完全预知的，并且要求软件开发团队进行高度的自我管理，管理者要充分信任开发团队” 显然，敏捷更真实地符合现实并顺应了管理的趋势，那种从上到下高压式的控制管理方法已经过时了，不单是在软件开发领域，在很多领域都已经被抛弃了，那其实是工业时代的产物。 （选自解析极限与编程：拥抱变化 ）总而言之，就我个人而言，我认为敏捷开发的本质，第一是一切活动以价值为导向，第二是以人为本。以价值为导向可以帮助我们大大提高软件开发的效益，以人为本的精神可以帮助我们大大提高软件开发的效率。因此我们在日常工作中可以大胆的尝试应用敏捷开发技术，我相信敏捷必将走向未来，21 世纪需要效率，需要敏捷。
