敏捷开发之热门已达到任何一个开发人员都至少听过，并觉得敏捷方法很好，然而并不是所有的人都学习和实践过，以致于大家谈敏捷的时候其实理解的基准是不一样的，也导致“敏捷”泛滥成灾“，有些看似很敏捷的开发其实并不敏捷。

最近在一个项目中准备采用Scrum开发方法来解决以往开发方法中遇到的一些问题，所以近期将发表一些个人对敏捷的一些看法，欢迎和大家交流。

过程与工具、面面俱到的文档、合同谈判、遵循计划

2001年2月由17位世界轻量级方法学家提出了一份敏捷联盟宣言，这个宣言只是简单的四句话，但却是敏捷方法的精髓，在谈敏捷方法之前就必须先对敏捷宣言有所理解。在和一些人员交流中，我发现大家都知道敏捷，但是能说出这个简单的敏捷宣言的并不多，都说当时知道，过了一阵子就忘记了。究其原因是靠死记硬背是不行的，需要通过自己的思考形成自己的理解才能够真正记住。上面的敏捷宣言非常简单，仅仅四句话而已，有的项目会出现上面这个漫画所描述的状况，领导说“我们开始尝试使用一种叫做敏捷的方法了，这就代表不再需要计划并且不再需要文档，只需要开始编码”。这其实就是简单记住敏捷宣言的几个字而出现的严重误解，下面我将对这四句话进行解释，希望大家跟随我的讲解也能对这个宣言有所认识。

合同谈判

项目开发一般都是跟随着合同开始的。由客户经理同客户交谈，在合同中确定一些法律条文以及交付产品包含的功能，然后客户经理拿着合同回到公司由开发小组经过长时间开发后再交付给客户。在开发期间，如果需要变更合同，则需要经过一系列流程。开发过程中，有些客户可能只是简单的询问一下进度，有的甚至是到最后交付日了直接来问你要东西，当产品不能满足合同规定时就需要和客户谈判进行解决。仅仅通过合同谈判来开发产品，客户在开发过程中就不会进行实质性的反馈，导致最终的产品不满意也就很正常了。

产品开发在早期市场不成熟的时候一般为公司领导（产品经理、LPDT）驱动，后期转变为用户驱动、销售驱动、服务驱动，在矩阵式管理模式下，产品事业部和开发管理部作为两个部门时，在做产品开发的时候就会类似在进行合同谈判，从一开始就会在两个部门之间产生争执而不是合作，这势必会影响产品的开发。

遵循计划

当拿到合同时，公司就开始组建项目组进行开发。此时需要项目经理制定出明确的计划，必须详细列出需求、设计、开发、测试、部署的各项任务。当项目组提交看似完整齐全的计划后，公司就视这个不变的计划作为项目组对公司的承诺，没有特殊情况时必须遵循制定的计划，如果想要变化，则需要经过公司评审。

软件复杂度有三个主要因素：业务、技术和人员。

关于业务和技术的关系我已经写了一些博文，有兴趣的可以去看看（从横向领域和纵向领域来谈业务和技术的关系 ）

《agile project management with scrum》（中文书名：Scrum敏捷项目管理）一书中有一个复杂度的图。

X轴表示技术（成熟度），Y轴表示业务（一致度）。从图中可以看到，业务和技术是正交的，各自对复杂度都有影响，我们在开发过程中需要做的通过各种办法尽量确保从Anarchy－Complex－Complicated－Simple进行转移。

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

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

过程与工具

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

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

面面俱到的文档

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

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

Waterfall VS Agile

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

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

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

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

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

客户协作 胜过 合同谈判

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

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

响应变化 胜过 遵循计划

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

虽然我们致力于响应变化，但并不是像上面漫画所说的不需要计划了,反而我们需要更多的规划。

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

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

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

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

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

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

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

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

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

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

胜过

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