照片上这个人叫Mike Cohn，他曾是多家公司的技术高管。他写了《Scrum敏捷软件开发》、《敏捷估算和规划》以及《用户故事与敏捷方法》，这几本书都值得大家去读下。他也是敏捷联盟及Scrum联盟创始人之一，在2001年“敏捷”正式提出前，他早在1994年开始在一个大型集团的一个事业部的软件开发组第一次实施了Scrum方法。虽然当时他实施Scrum取得了很显著的成果，但是Scrum仍被看做玩具式的过程，他仍旧无法说服信奉完整方法论的公司把Scrum作为一种通用的开发流程来实施。就算在他自己所在的事业部也还是有人质疑Scrum。
这和软件行业所处的时代有关，在当时有一种叫做统一过程（Unified Process）的方法，真是火的不行，整个开发世界似乎都在转向统一过程，如果你不使用都不好意思说你是做软件研发的。
我和团队也无法挡住这股热潮，2002年我们开始学习使用RUP方法。RUP从系统上来说的确是一个完整的软件开发方法，它把软件生命周期划分为4个阶段：初始阶段，细化阶段，构建阶段，移交阶段。每个阶段都有明确的目标，并且定义了用来评估是否达到这些目标的里程碑，在每个阶段结束前都有一个里程碑评估该阶段的工作成果。RUP并没有沿用瀑布模型的顺序的开发周期，它采用的是迭代过程，采用2-6周未一个迭代周期来持续改进系统，在快速构建软件的过程中不断精细化需求和设计。但它是强计划性的，并且有很多复杂的文档，这些对于小的团队来说简直就是噩梦，因为几乎没人愿意花大把的时间在写文档上。不过我们仍旧相信RUP能带我们走向成功，于是我们当时做了大量文档，UML、用例图、健壮性分析等，但是最终还是没有运转起来告终失败。
那是我进入软件行业第一次正式的采用一种重量级的系统性很强的正规开发方法来指导工作，RUP上的失败让我除了关注自己开发技能提升之外，还开始去关注规模化开发、模型驱动开发、敏捷软件开发等软件工程相关的话题。
这十几年中，随着全球经济的变化和互联网的成长，卖方市场逐渐向买方市场转化，软件企业竞争强烈，客户的影响力越来越大，在需求加速变化的现在，对产品质量和体验有更进一步要求，原有的软件开发模式已经难以适应这种以用户为中心、需要快速响应变化的时代，这个时候会出现什么时代？
一个新的时代开始之初都会出现很多边缘性的产物，在敏捷提出之前，除了Scrum处在这种尴尬的处境，软件开发世界还存在一些其他独立存在的边缘方法，例如极限编程。在2000年春，Kent Beck（软件开发方法学的泰山北斗，是最早研究软件开发的模式和重构的人之一，是敏捷开发的开创者之一，更是极限编程和测试驱动开发的创始人，同时还是JUnit的作者，他和软件开发大师Martin Fowler合著的《Planning Extreme Programming》可谓是关于XP的奠基之作）在俄勒冈州的罗格里夫酒店组织了一次会议，参会者包括极限编程的支持者们和一些“圈外人”，他们表达了对一系列“轻量级”方法的支持。之后适应性软件开发、特征驱动开发、动态系统开发、水晶系列和Scrum等“轻”方法陆续出现在软件圈。在2000年9月Robert C. Martin（芝加哥Object Mentor公司总裁，被后辈程序员尊称为“Bob大叔”，面向对象设计、模式、UML、敏捷方法学和极限编程领域内的资深顾问，著有《代码整洁之道》、《敏捷软件开发：原则、模式和实践》、《UML：Java程序员指南》等）吹响了下次会议的集合哨，他发了一封电子邮件，告诉大家他想召集一个为期2天的小型会议，时间在2001年1月或2月，地点芝加哥，目的是让所有轻量级方法论的领袖汇聚一堂。之后Bob搭了一个wiki，由此开始了热烈讨论。Alistair Cockburn（国际知名软件项目管理方面的专家，用例技术，对象技术和敏捷方法大师）表达了对“轻”这种提法的不满，但还是关于会议地点的争论最激烈。大家觉得芝加哥又冷又没意思；犹他州的雪鸟虽然冷，但是滑雪至少还挺有意思；而加勒比的安圭拉岛暖和又好玩，但又太远；最终大家还是选择这次会议在雪鸟举行。
在2001年2月，有17个来自于XP、Scrum、DSDM、ASD、Crystal、FDD等软件开发领域的领袖代表和希望找到现有开发过程替代品的一些推动者。他们聚在美国犹他州瓦萨奇山雪鸟滑雪胜地，试图找到一种新时代软件开发过程的统一定义。但是大家也知道，要对新的开发方式达成一致是很难的，因为他们每个人都有着自己如何建立一个成功软件的观点，令他们惊讶的是，最终大家竟然共同签署了《敏捷软件开发宣言》来达成共识。
Ward Cunningham（他在面向对象、极限编程方面做出卓越贡献）那天参加了会议，之后他给文章开头说到的Mike Cohn写了封邮件，让他看看自己是如何度过前几天的，并附上一个网站链接：agilemanifesto.org，以及一张很粗糙的照片。
虽然照片上只是一群人围在一个白板前，但是那个网站像一道闪电击中了Mike，他知道了至少还有17个人跟他一样开始期盼和探索这新一代的软件开发时代，他不再孤单。后来，随之像他们这样的人从各处跳了出来，日复一日，越来越多的人都签上了自己的名字，并在agilemanifesto.org上添加了一个团结一致的简短宣言。
宣言很简单，前后一句话，再加上4句“A高于B”的话。这里需要说明一下的是，这里左边和右边的条目都是有价值的，但但敏捷更强调左边陈述的价值。基于这些价值，大家还整理出了敏捷实践的12条原则供大家更多参考：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
这个宣言和原则作为敏捷的头条指引着大家，经过十多年，软件开发时代已经发生了180度的转变。如果你现在没有使用敏捷，或是没有转向敏捷，你可能会觉得自己应该这么做。敏捷有多种形式，现在也成为了可行的、可信赖的开发方法论，但我们发现很多团队虽然正在参照一些敏捷最佳实践开展，但是并未真正了解敏捷的含义。Jim Highsmith（《敏捷项目管理》作者，他也参加了雪鸟会议）在2010年的敏捷澳大利亚大会上的发言中谈到也是这个意思：
管理者需要停止故作敏捷（Doing Agile），而要真正开始敏捷（Being Agile）！
从方法论角度来认识敏捷
在学习敏捷的时候，我冒出一个想法：“如果没有敏捷，我们现在会怎么去做开发？如果是由我来提出敏捷，我会怎么去做？”
敏捷是一种方法论，所以我开始去网上找关于“方法”这个词的深入定义，希望能从中找到一些答案。既可以帮助我去理解敏捷方法，也可以帮助我更好的理解其他方法，甚至可以帮助我自己创立一些方法。
我对方法论的最初的理解是这样的：方法论是基于大量实践的高度抽象之上，加上理论的加工后才形成的一套体系。但这个说法有点太抽象且不具体，没有指导性，我后来从《A method for Requirements Management and modeling》 的一些介绍来理解了Aydin从通用方法工程理论出发提出了一套通用定义。这个定义表明方法论包括三个元素：一种哲学（philosophy）、一个框架（framework）、以及支持工具和技术（The tools and techniques），这也是我创立敏捷个人成长体系时参考的三个重要维度。这个方法定义中的哲学包含所有基本的原则、假定和约束，这部分决定了方法的核心思想；框架包含一些模板、规则和样式来展现和归类不同的方法元素（例如交付物和流程步骤）；而工具和技术支持特定方法步骤来实现最终产品。
如果说敏捷是一个方法论，那么有人说敏捷是哲学、敏捷是框架、敏捷是一些最佳实践就不觉得稀奇了，因为这些正是方法论的各个组成部分。
Aydin方法框架在初始阶段能够用来结构化方法，但是由于还是比较抽象，所以仍旧比较难以实施，所以有其他方法研究者提出另一套定义，这个定义提出了六种方式。我会对每个思路进行概要介绍，并留下一个问题：
- 1. the way of thinking
思考方式是一些原则、假定、约束、基本观点或价值观，它能够回答“为什么”的问题。 这部分我问自己：“敏捷的核心假设和理论基础是什么？” - 2. the way of working
工作方式描述了流程和一些在开发过程中采用的实践，包括任务的分解和排序，以及对任务的执行。这部分我问自己：“敏捷中有哪些流程和最佳实践？” - 3. the way of controlling
管理方式决定通过什么管理文化来解决项目开发的管理方面的问题。这部分我问自己：“敏捷中管理文化是什么样的？“ - 4. the way of modelling
建模方式定义了一些在工作和管理中产出的交付物，可能是一些模型、或者一些符号等。这部分我问自己：“敏捷中可能会有哪些文档？“ - 5. the way of supporting
支持方式寻找有用的工具、培训、文档来协助支持系统的开发。这部分我问自己：“敏捷中有哪些书籍可以让我快速入门呢？” - 6. the way of communicating
沟通方式关注在研发过程中的各个环节、对工作成果等是如何进行沟通交流的。这部分我问自己：“敏捷中大家是如何沟通协作的？”
上面只是我在学习敏捷的时候的几个问题，接下来我先回答第一个问题，以后的慢慢再说。
敏捷的核心假设和理论基础是什么？
如果有人问“敏捷是什么？”我听过很多答案是“迭代”。这个答案对吗？如果你了解了整个软件时代的大概发展历程就知道这个答案是不正确的：
- 1960-1969年软件作坊时代
软件开始作为一种产品被广泛使用，出现了软件作坊专职应别人需求写软件，这个时期的软件规模都还很小，基本上沿用个体化软件开发方式。 - 1970-1979年软件危机时代
随着硬件飞速发展，软件规模和复杂度激增带来的开发成本和维护难度越来越大，失败的项目屡见不鲜，从而引发软件危机，这个时期提出软件工程。 - 1980-1989年瀑布时代
引入成熟管理方法，以“过程为中心”分阶段来控制软件开发，一定程度上缓解了软件危机，但开发成本高，开发周期过长。 - 1990-1999年重型过程时代
软件失败的经验促使过程被不断增加约束和限制，软件开发过程日益“重型化”，严密的过程、大量的文档并未带来需求的准确性，反而大量约束、评审让工作人员按照流程办事，制约了人的创造性和积极性，使得开发效率降低、响应速度变慢。 - 2001-至今敏捷开发时代
软件作坊带来无法大规模开发的问题，软件危机带来开发和维护成本太大的问题，瀑布模型带来产品价值开发周期长的问题，而RUP带来强计划和强文档无法适应用户需求的快速变化的问题，这个时候迎来了敏捷开发时代。
前面已经说到，迭代已经是RUP的最佳实践之一，它主要解决瀑布时代的开发周期过长的问题，所以迭代不是敏捷时代的核心，它只是经过以前软件开发时代验证后被当做好的实践保留下来的。
如果要说敏捷的核心假设，那就要看处于它上一时代的RUP方法论有什么假设是不适应当下的时代的。
我们通过分析XP和RUP有什么不同来看看RUP的核心假设是什么？
有人说RUP里面规定的用例、UML图与敏捷不符，我觉得用例这些都还是有用的，这不是本质不同。RUP把软件当做复杂性事物来处理，而复杂性软件是强调架构设计的，通过计划来控制风险，重视架构的稳定来减少对产品未知的变化。架构要考虑功能、性能、可靠性、重用、约束等诸多因素的权衡，而架构设计的目的是为了消除这些关键的架构风险，这在RUP的细化阶段是主要工作，会要求构造出一个可运行的架构原型作为将来添加需求功能的稳定基础。然而现在是更重视产品价值及时性和用户体验的时代，有些产品的运营比开发过程更为重要，架构虽然仍旧重要，但是XP的迭代会把编码和设计活动融为一体，弱化了架构的概念，强调架构的演化。
我觉得这是一种从基于遵守计划的架构驱动方法到基于适应变化的价值驱动方法的转变。那这两者的核心假设的本质区别是什么呢？
不管是什么互联网时代，什么新的商业模式，对于产品来说，归根结底都是满足用户需求的产物，所以我想从需求出发去探寻这个假设，而这也正是架构驱动和价值驱动的核心假设的差异点。架构驱动是计划性的，它认为需求是稳定不变的，所以可以事先计划产品研发整个进度。而在价值驱动时代，我们承认需求是难以捕捉的，也是容易变化的，所以大家期望通过快速发布产品来验证需求，以保证用户能最快的获得这些价值。
基于需求是变化的这个假设，敏捷的核心思想和优秀实践都是围绕建立高效团队来快速响应变化，而非控制需求变化来实现开发目标，所以当迭代中遇到需求变化时，我们不会采用加班或加资源来应对，而是使用固定资源保持固定节奏来开发变化后的需求。对于在敏捷方式下如何进行需求管理会在后续章节中详细的介绍，这里我们先全面了解一下这两种方法的主要区别，以便大家在对敏捷有一个大致的认识：
| 特征 | 适应变化的价值驱动方法 | 遵守计划的架构驱动方法 |
| 主要目标 | 快速交付价值和响应变化 | 高稳定性和高可靠性 |
| 环境 | 需求难控制，经常变更 | 需求稳定，很少变更 |
| 计划和控制 | 内部计划，定性定量控制 | 文档化计划，定量控制 |
| 沟通 | 面对面的沟通 | 编制和查阅规范文档 |
| 需求 | 排定优先级的backlog | 规范化的需求规格文档 |
| 开发 | 简单设计，少增量，认为重构代价低 | 大量的事前设计，较多的增量，认为重构代价高 |
| 测试 | 测试用例可以执行并用来定义需求 | 文档化的详细测试计划和规程 |
| 管理文化 | 自组织 | 政策和规程 |
| 人员配置 | 不要新手，至少30%级别的熟手 | 可以需要30%级别高级新手 |
