敏捷开发之 4句敏捷宣言
??敏捷开发之热门已达到任何一个开发人员都至少听过，并觉得敏捷方法很好，然而并不是所有的人都学习和实践过，以致于大家谈敏捷的时候其实理解的基准是不一样的，也导致“敏捷”泛滥成灾“，有些看似很敏捷的开发其实并不敏捷。
最近在一个项目中准备采用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对比的图。
?
瀑布式开发是计划驱动的，合同谈判后项目组制定计划并且遵循计划，在过程与工具支持下通过面面俱到的文档来定义不变的需求和其他文档，在时间不够时可以通过增加人员来缓解压力。
而敏捷开发是价值驱动，通过自组织团队在短期迭代过程中不断的交付对用后有用的功能来进行产品开发。
从上图的正反三角形图形可以看出两者的驱动是不同的，虽然宣言中右项（过程与工具、面面俱到的文档、合同谈判、遵循计划）也很有价值，但是我们认为左项（个体与交互、可以工作的软件、客户协作、响应变化）更有价值，同时为了防止有些人学了敏捷之后而认为右边的没有价值了，我会在每条说明后重申一下右边的仍旧需要。以下我将继续对敏捷宣言中的左项内容进行解释。
个体与交互、可以工作的软件、客户协作、响应变化个体与交互胜过过程与工具可以工作的软件胜过面面俱到的文档客户协作胜过合同谈判响应变化胜过遵循计划这四句价值观用语句表达就是：
自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件
胜过
与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求
