从加入公司到现在快三年，从进入公司的那一刻开始实践敏捷，但是说起来惭愧，如果你问我敏捷是什么，我好像不能给出一个专业的回答。由此我开始探索敏捷的过去现在和未来，然后我发现了Bob大叔的新书 Clean Agile: Back to Basics。
从敏捷诞生以来，它被赋予了太多东西，诚然有些东西很好地发扬了敏捷，但是很多东西可以说是蹭热度强行加上去的，只是为了让大家认识敏捷的同时学习自己的”私货“。这本书如同它的翻译一般，是为了正本清源，澄清大家对敏捷的误解和混淆，重述敏捷最初的用意。
一切要从一个对后世影响深远的会议说起。
瀑布模型出现
在聊这场会议之前，我们将时间拨回软件行业的早期。其实在那时，我们现在称之为敏捷的做法就已初见端倪，并且与之对应的还有一个在后来同样获得巨大成功的方法 -- 科学管理。
与选择小的中间目标，并在各个目标之后确认进展的敏捷不同的是，科学管理讲究先有大的前期规划，再有认真细致的实施。
两种方法在20世纪70年代都已出现，可以看出，敏捷适用于变更成本较低的项目，用于解决定义不完全清晰、目标不够明确的问题。而科学管理适合那些变更代价高昂，但目标定义清晰明确的问题。
那么软件项目到底属于哪一种呢？不管属于哪一种，在那时的人们由于种种原因选择了后者，而其中的关键因素来自于1970年，温斯顿·罗伊斯的一篇论文。
在这篇论文中作者阐述了他对管理大型软件项目的想法，并在论文比较靠前的位置贴了一张类似于瀑布流的软件开发管理方式：
瀑布流开发方式虽然在他的论文中并不提倡这样的方案且进行了一系列批评，但是由于这几张图在论文中过于显眼，并且大多数人看论文只看前几页，于是这种沿袭了科学管理特点的瀑布流的开发模式进入了人们的视野，并在未来的30多年里迅速发展壮大，在软件行业里占据了主导地位。
虽然它占据了主导地位，但是好像并没有想象中那么神奇。在分析和设计阶段，一切看起来都是那么完美，一旦进入开发阶段，面对需求的变更和交付时间的临近，不可避免的疯狂冲刺使得一切计划都毫无意义。
在当时看来，这么完美的理论和模型是不可能出错的，出错的只可能是自己，一定是有什么地方没做对，导致没能按照计划完成。
雪鸟会议
20世纪80年代末90年代初，敏捷变革开始了。最初在 smalltalk 社区，后来到书籍论文，到1995年一群走在前面的人已经写下了关于 Scrum 的著名文章并影响至今。
同时期，Bob大叔接触了肯特·贝克关于极限编程的著作(Extreme Programming Explained)后来在与本人接触后第一次尝试了 TDD 并深陷其中。
2000年夏天，肯特从XP社区和模式社区邀请了一批人探索围绕XP的下一步计划，这次会议被肯特成为”XP领袖集会“，虽然由于意见分歧这次会议并没有什么有效的产出。但是在会议结束后马丁·福勒希望以后有机会能够谈谈。
秋天，这次面谈确定了”轻量级过程峰会“人员名单和目标 -- 他们想提出一个统一的轻量级流程宣言。受邀者阿里斯泰尔·库克伯恩表示他其实也有这样的想法并已经有了一份名单，他将两份名单合并并负责了会议的筹备工作。
这就是后来著名的雪鸟会议。
与会者有17人，他们分别代表着自己的轻量级流程：XP、Scrum、Feature-Driven Development、Dynamic Systems Development Method、Crystal、pragmatic programmers、Model-Driven，以及拥抱所有方法又对所有方法持怀疑态度的老马。
在一系列的归类分组和讨论过后，一些关键词被整理出来 - ”个体和互动“、”可工作的软件“、”客户合作“、”响应变化“。同时大家还达成了共识 - 这些价值观不会替代过程、工具、文档、合同和计划，更像是它们的有益补充。
这就是敏捷宣言的中心思想。
雪鸟会议现场左起第三位是Bob大叔，中心的人是老马
整个讨论过程中没有分歧，没有争论，甚至没有替代方案的实质讨论，敏捷宣言就这么奇迹又安静地诞生了。虽然敏捷宣言诞生了，但其实当时它还不叫敏捷，大家想了一堆词汇，但是都觉得很糟糕，于是矮子里面拔高个，最终选择了敏捷这个词。
在第二天会议快要结束时，沃德自告奋勇搭建了敏捷宣言的官方网站并流传至今。
雪鸟会议之后，与会者花了大量的时间撰写敏捷文档，用于解释和指导敏捷宣言的4个价值观。以防人们无法理解这些价值观对工作方式的要求。
敏捷全貌
这是敏捷和瀑布的故事，但是故事还没有告诉你到底什么是敏捷？在聊敏捷之前，我们聊聊项目管理的铁十字。
项目铁十字
在一个项目中，质量、速度、成本、完成你只能取其三，不可能全部都要。你可以要求高质量、快速、低成本，但是这样的项目没法按照预期完成。你也可以要求项目低成本并快速完成，那样的话项目的质量就不会好。
优秀的项目经理会是项目足够高质量、快速、低成本，尽量按需完成。优秀的产品经理不会要求每一项都100%完成，但会尽量综合管理各个属性。敏捷正是帮助努力实现这种管理。
敏捷是一个框架，他可以帮助开发人员和管理人员进行务实的项目管理。但请注意，敏捷并不能保证经理能够做出恰当的决定，完全有可能将一个项目推向失败。
数据驱动的管理
敏捷重要的一项功能是提供数据。敏捷开发团队能够提供管理人员所需的各种数据，供管理人员做出选择。
比如下面这张图可以叫做速率图，它很好地体现了一个团队的开发速率，其中的速率单位是”故事点数“
velocity从图中可以看出这个团队一个迭代大约可以完成35个故事点，那么是不是意味着不出意外的话这个团队10个迭代可以完成大约350个故事点呢？与之对应的，燃尽图可以告诉团队我们还剩多少故事点没有完成：
burn down chart这张图也可以得出一些关键信息 - 如果以一个固定速率完成项目，那么我们需要多少天能够完成整个项目。但是图中有一些异常点，后一个点不降反升，这里可能是由于加入了新的需求，也可能团队内部出现了一些问题。
这两张图是敏捷的一个关键目标。敏捷的一个动机就是提供管理者所需的数据，以决定如何调整铁十字的系数，推动项目的完成。
管理铁十字
数据有了，现在管理者需要通过变更需求范围、时间表、人员和质量来平衡项目铁十字。
改变时间表
首先我们需要明确，上线日期的选择往往是出于重要的商业理由，这些理由可能是没法改变的。因此，改变上线日期往往意味着业务会受到某种重大冲击。
但是如果在项目行进过程中发现没有办法如期上线，应该尽早将这个消息暴露给项目干系人，如果日期真的没法延期，那么就得尽早考虑其他方案了。
增加人手
在人们的意识中，增加人手包治百病。但是根据布鲁克斯定律，如果此时项目已经延期或者处于项目后期，那么增加人手反而会使项目更加延迟。
brooks's law.png原因很简单，新人加入项目是没办法立刻上手的，老人们还得抽出时间帮助新人理解业务和代码库，整个团队的生产率势必下降。
牺牲质量
每个人都知道写垃圾代码可以让开发速度增快，那么我们停止编写所有测试，把所有精力扑到编写代码上来，如果可以的话，时间拉满，一个月工作380个小时。
静下心来好好想想朋友，”快而脏“是不存在的，垃圾代码只会让你把你所有时间用在debug里，垃圾代码只会拖累你。请记住，加快速度的唯一办法就是保证质量。
调整范围
问问你的客户，是不是所有的需求都必须在上线时间内完成？能不能把一些不那么重要功能往后延迟？
告诉你的客户，全部都要，就只能延期，当然你需要数据来说话，不能只靠嘴巴，如果对方是一个理性的组织，那么一定会考虑你的意见的。
什么？你说对面听不进去？那你还不走搁这等着过年呢？这不是敏捷能解决的，说不定拳头能 =.=
优先级排序
在每次迭代开始前请先进行优先级排序，先完成那些优先级高的功能，再完成那些不那么重要的功能。
所以在调整范围时你的客户就不会说：不好意思，这个不太重要的可以延期的功能已经被你们做完了。
所以到底什么是敏捷？
敏捷是一组原则、实践和纪律，帮助小型团队构建小型软件项目。敏捷不是什么大话题，不要把敏捷想的很神秘，敏捷不是给做大事的大编程团队解决大问题的大概念。那么是不是敏捷对于大型团队就没用了呢？当然不是，毕竟大部分大型项目都是由一个个小型项目组合起来的。
敏捷的核心思想是 - 选择小的中间目标，并在每个目标之后确认进展，采取可度量的小步前进。
有人认为敏捷就是快，当然不是，敏捷从来就无关乎于快。当人们幻想某个项目很完美的时候，需要一些东西将幻想摧毁，这是敏捷的主要目标之一。
敏捷帮我们尽早了解我们做的到底有多糟糕，然后尽早管理这种糟糕的局面，而敏捷产生的数据就是帮助我们管理项目的关键。
敏捷的另一个目标是弥补业务与开发之间的鸿沟，要想实现这个目标，上面提到的数据显然是不够的，这依赖于一系列业务实践和团队实践，依靠这些实践和纪律，我们能够尽量使得业务团队和开发团队直接没有误解，大家在同一条跑道上向着相同的目标一起前进。
总的来说，敏捷是一个支持专业软件开发的纪律框架，它不是一个流程，也不是一种时尚。敏捷不仅仅是一组规则，还是构成软件开发职业道德基础的权利、期望和纪律的组合体。
