敏捷开发浅谈

    在看过资料后，本身对敏捷开发有了一些粗浅的认识，在这里略作浅谈。

    简单的说，敏捷开发是一种以人为核心、迭代、按部就班的开发方法。在敏捷开发中，软件项目的构建被切分红多个子项目，各个子项目的成果都通过测试，具有集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程当中软件一直处于可以使用状态。

    敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提升开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可使你更深层次的理解敏捷开发。其实，敏捷开发有本身的核心价值观：沟通、简单、反馈、勇气、谦逊。

    多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” 。设计过程充斥着短时间的、即时的决定，而无完整的规划。 这种模式对小系统开发其实很管用，可是当系统变得越大越复杂时，要想加 入新的功能就愈来愈困难。同时错误故障愈来愈多，愈来愈难于排除。一个典 型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期 之感，从而对项目的完成产生严重的影响。软件行业中最初的一场运动是要改变这种状况，而引入了“正规方法” 的概念。这些方法对开发过程有着严格而详 尽的规定，以期使软件开发更有可预设性并提升效率，这种思路是借鉴了其余 工程领域的实践 － 所以我把它们称为工程方法。工程方法已存在了很长时间了，可是没有取得使人瞩目的成功，甚至就 没怎么引发人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐， 要是按照它的要求来，那有作太多的事情须要作，而延缓整个开发进程。敏捷型方法的发展是对这些工程方法的反叛。 对许多人来讲，这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们 在无过程和过于繁琐的过程当中达到了一种平衡，使得能以很少的步骤过程获取 较满意的结果。

     敏捷型与工程型方法有一些显著的区别。其中一个显而易见的不一样反映在文档 上。敏捷型不是很面向文档，对于一项任务，它们一般只要求尽量少的文档。 从许多方面来看，它们更象是“面向源码”。事实上，它们 认为最根本的文档应该是源码。

可是，我并不觉得文档方面的特色是敏捷型方法的根本之点。文档减 少仅仅是个表象，它其实反映的是两个更深层的特色：1.敏捷型方法是“适应性”而非“预见性”。 工程方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划， 而后依计划进行开发。这类方法在通常状况下工做良好，但（需求、环境等） 有变化时就不太灵了。所以它们本质上是拒绝变化的。而敏捷型方法则欢迎 变化。其实，它们的目的就是成为适应变化的过程，甚至能容许改变自身来适 应变化。2.敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 工程型方法的目标是定义一个过程，不论是谁用都工做。而敏捷型方法 则认为没有任何过程能代替开发组的技能，过程起的做用是对开发组的 工做提供支持。

      敏捷开发的预见性与适应性：1.将设计与建造分离开来  设计是难于预见的，而且 须要昂贵的有创造性的人员，建造则要易于预设。咱们有了设计以后， 即可对建造进行计划了。而有了建造计划后，咱们进行建造则能够是很是可 预见性的了。在土木工程中，建造不论在经费上仍是在时间上的成本都要比 设计和计划大得多。因此，软件工程方法的途径是象这样的：咱们想要可预见的生产进度计划， 以便能使用技能较低的人员。要达到这一点，咱们必须得把设计与建造分离 开来。所以，在软件开发中，咱们得想法做出这样的设计，使得计划一经完 成，建造将会是直接而明确的。2.需求的不可预见性  做软件开发的费用估算是不容易的，这有多种缘由。部分缘由是由于软件 开发是一种设计活动，所以难于精确计划。部分缘由是系统的“基本材料”变化 很是之快。部分缘由是开发活动极大地依赖于项目参与人员，而个体是难于 预测和量化的。软件的“不可触摸”性也是一个缘由。在系统建成以前，有时很难判断一项 功能的具体价值。也就是说，只有当你在实实在在地使用系统时，你才能 知道哪些功能是有用的，哪些没什么用。软件开发的一切都取决于系统需求，若是需求不固定，你就不能制订出一个可 预见性的计划。3.不可预见过程的控制 － 迭代   那么，咱们如何对付一个不可预测的世界呢？最重要，也是最困难的是要随时 知道咱们在开发中的情形处境，这须要一个诚实的反馈机制来不断准确地告诉 咱们。这种机制的关键之点是“迭代式”开发方法。这并非一个 新思路，迭代式开发方法已存在好久了，只是名称不一样。迭代式开发的要点是常常不断地生产出最终 系统的工做版本，这些版本逐部地实现系统所需的功能。它们虽然功能 不全，但已实现的功能必须忠实于最终 系统的要求，它们必须是通过全面整合和测试的产品。这样作的理由是：没有什么比一个整合了的、测试过的系统更能做为一个项目 扎扎实实的成果。文档能够隐藏全部的缺陷，未经测试的程序可能隐藏许多缺 陷。但当用户实实在在地坐在系统前来使用它时，全部的问题都会暴露出来。 这些问题多是源码缺陷错误，也有多是对需求理解有误。虽然迭代式开发也可用于可见性环境，但它基本上仍是用做“适应性” 过程,由于适应性过程能及时地对付需求变动。需求变动使得长 期计划是不稳定的，一个稳定的计划只能是短时间的，这一般是一个“迭代周 期”。迭代式开发能让每一个迭代周期为下面的开发计划提供 一个坚实的基础。

    此外，敏捷开发须要把人放在第一位，在软件开发中应以人为中心，其实这种概念在许多软 件行业的有识人士中已经是共识。这形成了一个很强的正反馈机制。若是你指望你的开发人员是可互替的编程插件，则你不会去试着把他们当作是不一样的个体。这会下降士气，并使优秀的人才跳到一个能发挥其个性特长的地方，最后你却是获得你所须要的：可互替的编程插件。敏捷型过程当中“以人为本”的理念能够有不一样的表现，这会致使不一样的效果， 而并不是全部结果都是彻底一致的。实施敏捷型过程的一个关键之处是让你们接受一个过程而非强加一个过程。 一般软件开发的的过程是由 管理人员决定的，所以这样的过程常常受到抵制，特别是若是管理人员已脱离 实际的开发活动很长时间了。而接受一个过程须要一种“自愿致力” ，这样你们就能以积极的态度参与进来。这样致使了一个有趣的结果，即只有开发人员他们本身才能选择并遵循一个适 应性过程。这一点在XP中特别明显，由于这须要很强的自律性来运行这个过程。 。另外一点是开发人员必须有权做技术方面的全部决定。XP很是强调这一点。 在前期计划中，它就说明只有开发人员才能估算干一件工做所需的时间。对许多管理人员来讲，这样形式的技术领导是一个极大的转变。这种途径要求 分担责任，即开发人员和管理人员在一个软件项目的领导方面有同等的地位。 注意我说的同等。管理人员仍然扮演着他们的角色，但需认识并尊重开发 人员的专业知识。之因此强调开发人员的做用，一个重要的缘由是IT行业的技术变化速度很是之快。今天的新技术可能几 年后就过期了。这种状况彻底不一样于其余行业。即便管理层里的之前干技术的人 都要认识到进入管理层意味着他们的技术技能会很快消失，所以必须信任和依靠当前的开发人员。