敏捷开发都听过吧？敏捷宣言呢？那可能就不一定了。其实做敏捷也没必要去理会什么敏捷宣言，不过呢，如果你不知道敏捷宣言就不太好意思说你接触过敏捷了，所以呢，还是了解一下吧，而且如果你真的静下心来去了解，你也许会得到更深层的理解，这对你实施敏捷来说是必须的。

敏捷宣言

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

在谈敏捷方法之前就必须先对敏捷宣言有所理解，在2001年由17位世界轻量级方法学家提出了一份敏捷联盟宣言，这个宣言只是上图上面部分的简单四句话，但可不要小看了，这可是敏捷方法的精髓。一般有思想的人都喜欢弄一些简练的话，提纲挈领，也易于扩展和变化，正如敏捷个人的快乐、高效、平衡，到现在的爱学习、有目标和懂生活：）

在和一些人员交流中，我发现大家都知道敏捷，但是能说出这个简单的敏捷宣言的并不多，即使现在知道，过不了多久也就忘记了。因为这个又不需要考试，谁吃的没事去死记硬背这些话呢，公司也不会因为我们知道这个而涨工资。而我们又知道，这其实是敏捷开发的精髓，最好需要通过自己的思考形成自己的理解来记住这四句话。

下面我将对这四句话进行解释，希望大家跟 随我的讲解也能对这个宣言有所认识。

合同谈判　

项目开发一般都是跟随着合同开始的，由客户经理同客户交谈，在合同中确定一些法律条文以及交付产品包含的功能，然后客户经理拿着合同回到公司由开发团队完成开发后再交付给客户使用。在开发期间，如果需要变更合同，则需要经过一系列变更流程，遇到一些客户过程不参与，或只是简单的询问一下进度，有的甚至是到最后交付日了直接来问你要东西，这时产品不是他们想要的时候就麻烦大了，这可能就需要进行谈判商讨解决了。

仅仅通过合同谈判来开发产品，客户在开发过程中就不会进行实质性的反馈，导致最终的产品不满意也就很正常了。也许你说你们做的产品，暂时没有客户使用，其实也不是这样的，产品开发在早期市场不成熟的时候一般为公司领导（产品经理、LPDT）驱动，后期转变为用户驱动、销售驱动、服务驱动，在矩阵式管理模式下，产品事业部和开发管理部作为两个部门时，在做产品开发的时候就会类似在进行合同谈判，从一开始就会在两个部门之间产生争执而不是合作，这势必会影响产品的开发。

遵循计划

当项目或产品开始之后，这时候就会组建一个开发团队了。负责人制定出明确的计划，详细列出需求、设计、开发、测试、部署的各项任务，并将看似完整齐全的计划提交给公司，公司以此不变的计划作为对客户的承诺。

然而软件实在是一个太复杂的东西，业务、技术和人员是影响复杂的主要三个要素：X轴表示技术（成熟度），Y轴表示业务（一致度）：

从图中可以看到，业务和技术是正交的，各自对复杂度都有影响，我们在开发过程中需要做的通过各种办法尽量确保从Anarchy－Complex－Complicated－Simple进行转移。技术和业务最终都需要人来执行，而每个人拥有不同的技能、经验和观点，当这些人在一起合作时又会使得开发过程变得复杂。

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

过程与工具

计划制定后，项目组需要在类似ISO9000、CMMI、IPD等一些常用的项目管理方法下进行开发管理，而且还需要找到很多工具来支持开发，需求阶段有原型工具、需求管理跟踪工具，设计阶段有Rose、PD，开发阶段有各种IDE和辅助插件等。

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

面面俱到的文档

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

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

更重要的一点是，变化是永恒的真理，文档并不能运行，写太多了也不能用来交付。当然，大家不要看到这又走极端了，认为敏捷是不要文档、不要规格说明书的，这个需要具体情况具体分析，切勿太偏执了

瀑布和敏捷

在我的一个敏捷开发培训课程中，我有一张瀑布和敏捷对比的PPT可以简要说明瀑布和敏捷的区别：

瀑布式开发是计划驱动的，合同谈判后项目组制定计划并且遵循计划，在过程与工具支持下通过面面俱到的文档来定义不变的需求和其他文档，在时间不够时可以通过增加人员来缓解压力。而敏捷开发是价值驱动，通过自组织团队在短期迭代过程中不断的交付对用后有用的功能来进行产品开发。

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

客户协作  胜过   合同谈判

寻求客户合作的价值重于对合同的谈判。软件开发的最终目标是提供给客户满意的软件，而只有客户才更清楚怎么样才能满意，敏捷开发提倡客户和开发团队密切的在一起工作，并尽量经常行得提供反馈。各种不同的敏捷方法都会利用短期迭代，通过尽早提供软件来达到与客户频繁沟通和反馈的，这也可以把问题及早暴露出来，以免隐藏的问题在后期造成更大的影响。

虽然我们致力于客户协作，但为了双方利益和需要仍旧需要进行合同谈判。

响应变化  胜过    遵循计划

计划赶不上变化，敏捷项目承认开发过程中的不确定性，所以不会在开发中制定长时间的复杂计划，它们的成功都是建立在现实反馈的基础上的。Scrum依照一组简单实践及规则，实施经验性过程控制方法的检查、适应和保证可视性等步骤，处理软件开发项目中的复杂问题。通过迭代开发，每次迭代都是基于上一迭代的完善基础之上进行的，通过不断的响应变化来消除开发中的不确定性。

作出的计划常常会出错，面对这样的问题，开发小组往往会走上两个极端：要么根本不做任何规划，要么在计划中投入大量的精力直到自己确信计划是正确的。不做规划的小组对一些最基本的问题，例如“你们什么时候能完成？”以及“我们可以在6月份安排产品发布吗？”都无法回答。而做了大量计划的小组会自欺欺人地认为某个计划是“正确的”。他们的计划也许更全面，但这并不一定意味着它更准确或更有用。这两种极端都是敏捷需要避免的，最开始漫画所说的“我们实施敏捷，不再需要计划和文档了”的论调是及其错误的。

敏捷不是不需要计划，相反它需要更多的规划。不确定性是影响计划正确的主要因素，对大部分不确定而言，在获取知识、减少不确定性的唯一办法是通过执行－作一些事情、构建一些东西或模拟一些东西－然后获得反馈。许多项目管理方法是“规划、规划。规划－执行”，而敏捷开发方法是“规划－执行－调整”、“规划－执行－调整”。一个项目的不确定性越高，敏捷开发方法对取得成功就越是至关重要，不断学习和调整是敏捷开发的核心。

虽然我们致力于响应变化，但并不是不需要计划了，只是变得更多规划了。

个体与交互   胜过    过程与工具

方法和工具是死的，人是活的，如何没有优秀个人和团队协作，再强大的方法和工具都是摆设。一个使用普通工具的优秀人员会比使用优秀工具的普通人员做得更好，一个具有合作精神、自组织的团队比通过过程规范的团队工作得更好。敏捷项目首先拥有一个小规模但拥有各种不同职能的成员，每个成员都需要定时和团队的其他成员一起查看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力，可以自发的通过各种途径解决开发过程中遇到的问题。

虽然我们致力于个体和交互，但并不是不需要过程与工具了。Scrum、XP等方法本身也有一些方法和过程，每日构造等敏捷实践也需要工具的支持，需要哪些过程和工具由自组织团队制定，而不是由领导制定。

可以工作的软件   胜过     面面俱到的文档

在合同中有时会看到分别在需求、设计、开发、测试阶段提供什么文档，支付多少金额等内容，而这些文档对用户来说是不是真的有价值呢？面面俱到的文档对客户来说确并不重要，用户需要的是一个能够运行起来，能够实质解决工作中问题的可以工作的软件。面面俱到的文档对开发团队也不重要，上百页的报告没有人愿意写，更没有人愿意去读，对开发团队来说最好的两份文档就是代码和团队。通过频繁的提供可以工作的软件，我们也可以更为频繁的搜集对产品和开发过程的反馈，保证开发小组始终是在处理最具有价值的功能，而且这些功能可以满足用户的需要。

虽然我们致力于提供可供做的软件，但并不是不要文档。我们在开发过程中仍然需要进行内部交流， 也需要和客户交流，我们仍旧可能需要制作原型，书写一些主要需求和算法，只要自组织团队认为足够就行了。

这四句价值观用语句表达就是：

• 自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件

胜过

• 与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求