敏捷型(agile，也被称之为“轻量型”，lightweight)的软件开发方法
敏捷型不是很面向文档，通常只要求尽可能少的文档，它们认为最根本的文档应该是源码
摘要：本文主要讨论敏捷型方法适应性（adaptive〕性质 和以人优先的理念
敏捷型方法是“适应性”而非“预见性”。
敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。
工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法 则认为没有任何过程能代替开发组的技能，过程起的作用是对开发组的 工作提供支持。
预设性与适应性
将设计与建造分离开来
传统的软件开发正规方法：建造计划(设计图纸)=>交由建造者做(施工)
设计是难于预见的，并且 需要昂贵的有创造性的人员，建造则要易于预设。
在软件开发中，具体建造费用非常低，几可忽略不计。
软件开发中所有工作是设计，因此需要富有创造性的才智之士。
创造性的过程是不太容易计划的，因此，可预见性是个不可能达到的目标。
我们应该对用传统工程模式来进行软件开发的做法保持足够的警觉，因为它们是不同类型的活动，因此需要不同的过程。
需求的不可预见性
需求频繁改变，可以看成：因需求工程（requirements engineering〕 没作好而导致的结果。
问题是
1.要准确获取所有需求是困难的
2.软件的“不可触摸”性，只有当你在实实在在地使用系统时，你才能知道哪些功能是有用的，哪些没什么用
软件开发的一切都取决于系统需求，如果需求不固定，你就不能制订出一个可 预见性的计划。
预见性是不可能的吗？
一般来说，不可能。
通常， 一个正规方法的创造者不是很善于（或乐于〕给出其方法的边界条件，换句话说，当这些边界条件不满足时，则该方法就不适用。所以说，在不可预见性的环境中是不能使用预见性方法的。
你所需要的是另一类过程，它们可以让你对不可预设性进行控制，这就是“适应性” 的作用了。
不可预见过程的控制 － 迭代
如何对付一个不可预测的世界呢？
要随时知道我们在开发中的情形处境，这需要一个诚实的反馈机制来不断准确地告诉我们。
“迭代式”（iterative〕开发方法类似名称是：“递增式” （Incremental〕，“渐进式”（Evolutionary)，“阶段式”（Staged〕， “螺旋式”（Spiral〕等等
迭代式开发的要点是经常不断地生产出最终系统的工作版本，这些版本逐部地实现系统所需的功能。它们虽然功能不全，但已实现的功能必须忠实于最终 系统的要求，它们必须是经过全面整合和测试的产品。
这样做的理由是：没有什么比一个整合了的、测试过的系统更能作为一个项目 扎扎实实的成果。
一个迭代周期需要多长?
XP（极限编程〕建议一到三周，
SCRUM建议一个月，
Crystal（水晶系列〕 更长一些。
适应性的客户
这种开发方式可以给客户带来很多的益处。
首先，这种开发的“回应性” （responsive）很好的。一个可用的，尽管是很小的系统能够尽早投入使用。 客户可以根据实际使用情况，以及变更了的需求，来及时改变一些系统功能。
这样一种方式能够更真实地反映出项目的实际状态。
可预见性过程的问题是： 项目的质量是根据与计划的一致性来衡量的。
在敏捷型的项目中，每一个周期都对计划进行评审。如果有什么糟糕的事情 的话，它也会早点被发现，因此仍然会有时间来解决。
把人放在第一位
并非只是适应性过程需要强的团队，多数优秀的开发人员也愿意采用适应性过程。
可兼容性程序插件
传统正规方法的目标之一是发展出这样一种过程，使得一个项目的参与人员成为可替代的部件。
参与软件开发的人员是可替代的部件吗？敏捷型方法的一个重要特征就是拒绝这种观点。
把人作为资源的思想其根源可追溯到泰勒的“科学管理”方法。当管理一个 工厂时，这种泰勒主义途径是有效的。但对有着高度创造性和专业性的工作，泰勒主义并不适用（事实上现代制造业也在脱离泰勒主义模式〕。
程序员是负责任的专业人员
泰勒主义的一个关键的理念是认为干活的人并非是那些知道怎样才能把这件活干的好的人。
程序员是专业人员，最有资格决定如何干好他们的技术工作。泰勒主义让计划部门来决定如 何干好一件工作的作法只有当计划者比实际操作者更能知道怎样作时才有效。 如果你拥有优秀的、自觉自励的员工，那么这点并不成立。
面向人的过程的管理
实施敏捷型过程的一个关键之处是让大家接受一个过程而非强加一个过程。而接受一个过程需要一种“自愿致力” （commitment），这样大家就能以积极的态度参与进来。
只有开发人员他们自己才能选择并遵循一个适应性过程。这一点在XP中特别明显，因为这需要很强的自律性来运行这个过程。
另一点是开发人员必须有权作技术方面的所有决定。XP非常强调这一点。管理人员仍然扮演着他们的角色，但需认识并尊重开发 人员的专业知识。
测度的困难性
要测度软件是非常困难的。如生产率。如果没有一套有效的测度方法，任何外部的控制都会是困难的（doomed）。
不存在一套有效的测度方法而要在管理中引入测度将会导致管理本身出问题。
基于测度的管理是非常适合 简单的、重复性的工作，知识要求低并且易于测度输出。
与基于测度的管理相反，可以选择“委托式” （delegatory）管理（干工作的人决定该怎么干）。
敏捷开发者则认为软件开发的特性会使得基于测度的管理导致非常高度的测度 “失效”（dysfunction）。实际上使用委托式的管理方式要有效得 多，这正是敏捷论者所持观点的中心所在。
业务专家的引领作用（The Role of Business Leadership〕
技术人员需要与应用领域的业务专家非常紧密的联系。这种沟通不是由管理层来处理的，而是每个开发人员需要做的事。
这是由适应性过程的特点来决定的。因为敏捷开发的前提是在整个开发过程中， 事情变化很快，你需要经常不断的联系沟通以使每个人都能及时知道这些变化。 开发人员能随时获取准确的高质量的应用系统的业务知识就显得很重要。
自适应过程
适应性是指在一个开发项目中如何频繁地修改软件以适 应不断的需求变更。但是，还有另一种适应性，即是过程本身随着时间推移变 化。随着时间的推移，开发团队会发现什么方式对他们的工作最好，然后改变过程以适应之。
自适应的第一步是经常对过程进行总结检讨。一般来说，在每一次迭代结束后， 你可以问自己如下问题 〔 Norm Kerth〕：
。有哪些做的好的部分
。有哪些教训
。有哪些可以改进的部分
。有哪些没搞清楚的部分
建议开发人员专门用一段时间做一次更为正式的回顾总结
你绝不能期待着只用一个过程。相反，每个项目组不仅 能选择他们自己的过程，并且还能随着项目的进行而调整所用的过程。公开 发表的过程和其他项目的经验都可以拿来作为参考和样本。但是开发人员需 根据手中项目的具体情况而对其加以调整，这也是开发人员的专业职责。
这种自适应性在ASD和Crystal（水晶系列〕中都鲜明地提及。XP的严格规则 似乎不允许这样，但这只是表面现象，因为XP是鼓励调整过程的。这一点上 XP和其他方法的主要区别之处在于，XP的倡导者建议在采用XP时，先根据书本 循规蹈矩不走样地做几个迭代之后，再考虑调整。另外，回顾总结这点在XP中 没有被强调，也不是这个过程的组成部分，尽管XP建议经常性的回顾应作为XP 的实践准则之一。