关于敏捷开发宣言中的理解

    敏捷开发宣言是整个敏捷开发的基石，这几个要点很简明扼要，我从以前经历过的项目对其稍加印证。
    1.个体和互动 高于 流程和工具；
    2.工作的软件 高于 面面俱到的文档；
    3.客户合作 高于 合同谈判；
    4.响应变化 高于 遵循计划；

    1.个体和互动 高于 流程和工具；
       应该说我是一个比较喜欢按流程办事的人，有一套好的流程和工具，我们可以比较清楚知道自己在某个阶段应该有交付物，在去到某个里程碑的时候，应该有那些具体的工作成果，这个是有流程的好处。我个人觉得是在有流程的基础上，作为项目负责人，有责任去提高团队的互动性，明确大家的目标，发挥个人价值。
   2.工作的软件 高于 面面俱到的文档；
      我个人承认冗长的文档确实会让人感到头痛，而一个活现眼前的软件确实吸引得多，但这里有一个问题是如何保障这个工作的软件当出现需求变更，当出现维护问题的时候，内部的代码质量是怎样。虽然XP有很多工程实践，例如：测试驱动、重构。但这个很讲究个人修养，以及项目的工期都有密切关系，太容易有execuse去不写测试用例，懒得去进行重构。作为项目管理人员，也还是有责任去推广这些良好的工程实践。
   3.客户合作 高于 合同谈判
      和客户有良好的沟通，确实可以起到事半功倍的作用，如果客户愿意和你一起去不断改进软件，确实是一件好事，在我从事这么多年的软件职业中，合作得最好的应该是白云机场的一个客户，大家合作很愉快，大家也是用心去希望事情做好。客户不愿合作有很多原因，而往往也是很难控制，而合同谈判对双方来说，应该对双方来说有一个履行承诺的时间，做任何事情都应该是有时间限制。
   4.响应变化 高于 遵循计划
     响应变化这个词一直都是敏捷开发的核心，也是所有软件项目希望做到的，但可能我功力未够，当出现各种变化，诸如：需求变更，资源调整，资源流失时，一定会出现计划调整，计划主要的目标是为了让所有人清楚里程碑点的时间，至于中途出现变化，如果影响里程碑的交付，也只能按流程申请计划变更。我始终觉得敏捷开发，要有一套简单而明了的方法学，例如迭代或增量开发如何与UP融合，但UP真的太复杂，敏捷应该也需要一套从规划、需求、编码及单元测试、集成及系统测试直到项目交付的一套方法学，这样才比较好，现在弹性太大，给人一种笼统的感觉。