技术和业务终都需要人来执行，而每个人拥有不同的技能、经验和观点，当这些人在一起合作时又会使得开发过程变得复杂。

　　这些复杂性将导致开发过程中存在很多不确定性，所以项目初期制定的计划其实基本上不能真正的坚持下来。而当项目开发遇到困难时，项目组可能会为了表明自己做计划的能力，或者不想经历复杂的变更过程，而继续努力的坚持这个已经错误的计划。范围、时间和成本，这个金三角几乎没有领导不知道，而项目组为了保证”遵循计划“，对外宣称项目组运行状况良好，保证当前人员在预计时间肯定能保质保量的完成开发。而代码质量只有开发人员知道，领导们容易忽略和难以控制这个环节，所以后一味的遵循计划势必导致提供给客户的是一个不满意的产品。

　　过程与工具

　　计划制定后，项目组需要在类似ISO9000、CMMI、NPD等一些常用的项目管理方法下进行开发管理。工欲善其事，必先利其器，可以找到很多工具来支持开发，需求阶段有原型工具、需求管理跟踪工具，设计阶段有Rose、PD，开发阶段有各种IDE和辅助插件，测试阶段有TD等。

　　合适的工具能很好的帮助开发，但当在开发人员面前出现大量庞大笨重甚至不好用的工具和开发环境时，会像缺少工具一样，都是不好的。在开发过程中，可能会出现夸大了工具的作用，当反应说开发工具对开发起起决定性的影响时，  这很有可能是在计划阶段开始错了，像衣服扣错的时候，一般都是扣第一个扣子的时候，而不是你发现扣错的那个扣子。

　　面面俱到的文档

　　瀑布式开发下，文档承载着各阶段之间的信息传递。需求文档中定义详细用例，每个细节，原型中定义界面表现，甚至每个控件的具体位置，设计中的 UML图，数据库设计图，测试用例文档等等，如果没有文档，开发将不能在过程中顺利依次展开。

　　编写和维护一份详尽的需求文档总是一个好主意，然而像前面所说业务复杂性带来的不确定性，除非给我们充足的时间，否则我们不可能一开始想清楚所有细节。另一方面，编写文档需要花费大量的时间，如果考虑和代码的同步时，工作量更是急速上升，如果不考虑同步时，过多的文档反而比过少的文档还糟。当我们花大部分时间浪费的文档，仍旧只能以降低质量来遵循计划的执行。

　　Waterfall VS Agile

　　在一个ppt中看到一张Waterfall和Agile对比的图。

　　瀑布式开发 是计划驱动 的，合同谈判 后项目组制定计划并且遵循计划 ，在过程与工具 支持下通过面面俱到的文档 来定义不变的需求和其他文档，在时间不够时可以通过增加人员来缓解压力。

　　而敏捷开发 是价值驱动 ，通过自组织团队 在短期迭代 过程中不断的交付对用后有用的功能 来进行产品开发。

　　从上图的正反三角形图形可以看出两者的驱动是不同的，虽然宣言中右项（ 过程与工具、面面俱到的文档、合同谈判、遵循计划） 也很有价值，但是我们认为左项（ 个体与交互、可以工作的软件、客户协作、响应变化 ）更有价值，同时为了防止有些人学了敏捷之后而认为右边的没有价值了，我会在每条说明后重申一下右边的仍旧需要。 以下我将继续对敏捷宣言中的左项内容进行解释。

　　个体与交互、可以工作的软件、客户协作、响应变化 

　　个体与交互　　　　胜过　　　过程与工具
　　可以工作的软件　　胜过　　　面面俱到的文档
　　客户协作　　　　　胜过　　　合同谈判
　　响应变化　　　　　胜过　　　遵循计划
　　客户协作　　　　　胜过　　　合同谈判