在网上看到一篇介绍敏捷开发的不错的文章，其中提到“敏捷开发方法的原则是“刚刚好”(Light and Sufficient)”，刚刚好这个词很贴切，但这个度却很难把握。其中关于敏捷开发方法、核心思想以及方法背后的思想的介绍，很有启发，想想去年下半年开发过程中，采用设立挑战里程碑的方式与此有几分神似。

摘录如下：

    敏捷型方法是“适配性”而非“预设性”。重型方法（海绵注：指传统的规范化开发方法）试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。 

    敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。

    我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心。

    （海绵注：突出了软件开发是一个高智力活动，而传统的正规方法旨在通过规范的过程，打造软件蓝领，实现软件批量生产）

    人们掌握过程(process)可以分为3个阶段：（海绵注：不仅适用于软件开发过程）

　　1 following 遵循一个定义好的process

　　2 detaching 知道不同process的适用范围，在不同的场合使用不同的process

　　3 fluent 不关心是否遵循特定的process，知道在什么情况下采用什么动作

　　软件开发是一个充满发明和交流的协作性游戏(cooperative game of invertion and communication)。软件开发的首要目标是生产出软件，遵循特定的过程和模型只是手段，只要传递了足够的信息，手段是次要的。交流的效果要远远重于交流的形式(Effect of communication is more important than the form of communication)。

   在软件开发中，人的因素要远远大于过程和技术。人是有缺陷的：（海绵注：同样不仅适用于软件开发人员）

　　1 容易犯错误，因此必须在错误扩散之前找到并改正错误

　　2 当觉得可能失去较多的时候，不愿意冒险

　　3 重新构造而不愿意重复使用已有的东西

　　4 难于坚持一个习惯

　　针对个人因素的几个建议：

　　1 具体的模型较抽象的模型更容易理解

　　2 从一个例子开始是容易的

　　3 通过观察他人的成果学习（海绵注：非常认同！）

　　4 要有足够的不受打扰的时间（海绵注：昨天看《The Effective Executive》也有同样的观点，时间片必须达到一定的度，否则即使时间总长相同，产出却有天壤之别）

　　5 分配的工作要与个人意向，能力匹配

　　6 不正确的奖励会有坏作用，从长期看个人兴趣比奖励更重要，培养在工作中的自豪感：

　　1) pride in work参与工作的自豪感，通常参与一个重要的工作会有自豪感

　　2) pride in accomplishment 完成工作的自豪感，长期未完的工作会使士气低落

　　3)pride in contribution 为他人贡献的自豪感

　　7 鼓励关心其他人的工作和整体的工作

   敏捷开发方法过程设计的几个原理：

　　1 面对面的交流是代价最小，最迅速的交换信息的方法

　　2 超过实际需要的过程是浪费的

　　3 大的团队需要重量级方法

　　4 处理重大问题的项目需要重量级方法

　　5 增加反馈和交流可以减少中间产品和文档的需求

　　6 轻量级方法更强调理解(understanding),自律(discipline)和技能(skill)，重量级方法更强调文档(documentation)，过程(process)和正式(formality)

• 　　understanding指整个团队关于项目的全部知识，包括讨论的过程，documentation只能记录其中的一部分
• 　　discipline是指个人主动的完成工作，process指个人根据指令完成工作
• 　　skill指具有良好技能的人可以省略中间的产品，formality指必须按照规定步骤完成工作

　　7 确定开发中间的瓶径，提高它的效率

 这些原理的几个结论：

　　1 向一个项目增加人员要花费较大代价(constly)，因为原有人员和新人员之间的交流要花费大量时间

　　2 团队的规模经常是跳跃的，例子：需要6个熟练的程序员，但是只有4个，于是增加不熟练的程序员，结果团队的大量时间花费在培训不熟练的程序员上面，{zh1}增加到了20个不熟练的程序员。（海绵注：这种模式随处可见）

　　3 应该侧重于提高团队的技能而不是扩充团队

　　4 对不同的项目使用不同的过程

　　5 在适用的条件下，轻量级的方法优于重量级的方法

　　6 对不同的项目要裁减过程

　　总而言之，敏捷开发方法的原则是“刚刚好”(Light and Sufficient)

    摘自：