简单的谈一谈敏捷，先写第一篇——敏捷的起源。
当下的软件工程项目管理，敏捷可以说是最火，同时也是应用最广泛的软件过程管理方法了。但到底什么是敏捷，为什么会有敏捷，它是如何出现的，未来有将会有怎么样的发展,这些问题其实都值得好好研究一下。
首先，问大家一个问题，做软件项目期间，你写文档吗？你喜欢写文档吗？你喜欢去开长篇大论的过程管理会议吗？
你认为，你写的文档都是有必要的吗？
我想绝大多数开发者，都不会喜欢写文档的，我知道你们绝大多数甚至连Git log和程序的注释都不愿意多写。
那为什么我们需要你们写那么多的文档，这是谁的主意？说清楚这一点，我们需要详细了解其由来。
我个人将软件工程的发展分成了两个阶段，90年代之前与90年代之后。在个人计算机出现之前，那时候计算机还不是很普及，娱乐十分匮乏，计算机也仅仅是承担老本行“计算”这一任务。当计算机越来越普及，也就是从70年代到90年代之间，软件的规模变得越来越大，出现了操作系统（Unix 1973年第一次面世），出现了数据库（69年IBM推出），软件的规模、成本、以及过程控制变得越来越复杂，于是乎出现了一种技术叫做“软件工程”，它是专门研究如何“又快又好”的开发软件的。后来到了80年代，个人计算机、微型工作站和网络的出现，使得分布式软件也成为了一个软件开发的热点。业界发现软件方法越来越重要了，没有一个标准的方法实在玩不转了。于是这时美国政府就在1984年委托卡内基梅隆大学的软件工程学院（SEI）进行一项研究，用于评估国防部委托的外部软件公司的软件开发能力。1987年，SEI推出了SW - CMM框架。1991年，SEI发布了CMM V1.0。CMM推出后，不仅成为了许多大型软件企业用于改善软件工程的评估标准，也应用到了系统工程及软件采购方面，成为全世界范围认同且通用的一种软件生产程序标准。在此基础上开发出了不同的CMM模型，比如软件能力成熟度 (SW-CMM) 、系统工程能力成熟度模型 ( SE-CMM) 、集成产品开发能力成熟度模型 ( IPD-CMM) 、人力资源管理能力成熟度模型 (P-CMM) 等应用模型。
需要注意的是，SEI在2006年发布了CMMI1.2，其涉及四个部分，系统工程（SE）、软件工程（SW）、产品集成和过程开发（IPPD）以及供应商外包管理（SS）。 这个本来就是一个题外话，但是我想说一说。我们国家把这个标准的软件工程SW拿出来，修改后就成为了我们国家的国军标5000A。 但是我们国家的GJB5000A不完整，只引用了其中的软件部分，所以我们在执行过程中就会感觉到很奇怪，因为我们并没有引用其中的系统部分，我们的系统设计和软件设计往往会感觉到脱节。 而咱们国家现在大力推进国军标5000 ，却忽视了系统工程的推进。这也造成了一个非常不好的结果，就是我们现在会非常重视软件的过程，但是却不重视系统的过程控制。
从上面我们可以知道我们的GJB5000是脱胎于CMMI的，CMMI是什么，GJB5000A就是什么。CMMI是一种模型，它里边是业内的最佳实践，它从来没有说自己是标准，也从来没有说自己是流程，CMMI只说自己是一个统一的过程改进框架，他并没有说每个事儿必须要什么怎么做， 他只是给每个过程定义的目标。所以说他有很强的包容性，他是可以容纳各种创新活动的。
那么问题来了，为什么我们现在都把CMMI/GJB5000A和瀑布模型画等号了？
首先我们谈一谈瀑布模型的历史。瀑布模型是1970年由温斯顿罗伊斯提出的一直到80年代的早期他是唯一被广泛采用的软件开发模型。不过模型将软件生命周期划分为计划、需求、设计、编码、测试、运行维护等六个基本活动。 在上世纪七十年代和80年代，由于 软件的规模比较小，需求相对明确，所以瀑布模型的效果比较好。之后在瀑布模型的基础上，业界又推出了螺旋、原型等很多变形。但是其核心都是基于工程管理理论的，在业内看来，软件的管理其实和造房子、造汽车没有什么差别，做这方面管理研究的基本也都是传统企业（类似于休斯、宝马公司）的科研管理人员。那个时代的软件，特别是非PC机软件，很多变动不大，例如1982年才开始服役的航天飞机，使用的信息处理软件和1960年的一样。
但是，计算机发展的速度，实在是太快了。虽然PC机是在80年代推出的，但是其成熟和快速发展确实在90年代，而且九十年代同时发展的还有另一个事物——互联网，这使得软件的规模及级数的形式变大，软件的生命周期，也得到了极大的压缩，软件的变更，也变得越来越频繁。传统的软件开发思路，是抵制变更的，其做法就是让团队在前期一定要把需求分析清楚，从而减少后续的变更，这在软件规模小的时候是没问题的。但是软件变得越来越大，软件的交付时间也变的越来越长，有人做过统计，一个企业管理软件在上世纪90年代的交付时间一般会在两三年，而两三年时间企业的内外部环境可能会发生很大的变化了。这时候人们就发现变更的工作量变得非常非常大，而在传统的项目管理当中，变更是需要严格控制的，于是乎软件管理为了保证变更的正确性和可靠性，软件管理者在传统的项目管理的思维惯性下，想了一系列的措施来确保变更得到正确的实施。其中很多措施被人们当成真理沿用至今。从管理学的角度来讲，这样的做法在质量管控上没有问题，十分可靠，但是，如果让我们回到软件工程的起点，想象软件工程的初衷“又快又好的研发出需要的软件“，那么这些方法是否满足了这一初衷真的是有待商榷。
这都是上世纪90年代的事情了，现在都是2022年了，为什么我们执行5000，还都是在弄瀑布模型呢？
有人可能会问，这些都是老黄历了，是发生在上世纪90年代的事情，为什么我们现在做5000，还会采用瀑布模型呢？这个问题，我觉得我们不能单纯的看5000里边是怎么要求的，5000并没有要求用户必须怎么做，5000里边的解释性条文，都是参考性质的，5000标准本身并没有要求用户单位必须参照这些做法，出具这些过程产品。甚至可以说，不论你采用什么方法，只要能达到5000的过程域（实践域）的目标，那就是满足5000要求的。甚至这些过程域和目标，本身也都是可以裁剪的。之所以我们会采用瀑布模型来做5000，其原因不在于5000本身，而在于其他的标准，例如：我们的GJB 2786A软件研发过程，我们常用的GJB438B，这些最常见的软件标准，都是基于瀑布模型的，可以说，是这些标准，而不是5000，要求我们必须按照瀑布模型来做。不仅如此，我们的军品软件开发过程管理本身就是瀑布形式的，大家约定俗成的软件管理过程就是瀑布形式的。军代表和项目甲方都是按照瀑布形式管理的，你能不按照瀑布过程做吗？
软件工程的转机在哪里？俗话说得好，哪里有压迫，哪里就有反抗。国外有一帮程序员，也是受不了这些所谓的“科学管理”，觉得明明是很简单的工作，让这些搞管理、搞体系的硬是给弄复杂了。非要让我们把写程序的宝贵时间，浪费在开会和文档这些无聊的事情上。于是乎他们“歌鸣“了。
有17个程序员革命者，在革命圣地犹他州的Snowbird滑雪场（这地方和嘉兴南湖一样，都是旅游胜地……）发出了自己的宣言——《敏捷软件开发宣言》，估计这些人也没有想到自己的这几句话能造成这么大的影响。然而，天下苦秦久矣，星星之火可以燎原。
敏捷宣言：
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体和互动 高于流程和工具 工作的软件 高于详尽的文档 客户合作 高于合同谈判 响应变化 高于遵循计划 也就是说，尽管右项有一定的价值，我们更重视左项的价值。
敏捷宣言都是大白话，通俗易懂，这里不多做解释，而且很多敏捷组织和教练的解释，部分内容我也不是很认可。但这里需要注意的是，敏捷并不是否认传统流程中的文档、流程、工具等手段，没有说人们不应该去写文档，而是认为他们的价值不应该高于左边的那些活动。而左边的活动，其实都是一些能直接创造价值的活动。
敏捷除了敏捷宣言以外，还提出了遵循的12条原则：
01.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 02.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 03.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 04.业务人员和开发人员必须相互合作，项目中的每一天都不例外。 05.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 06.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 07.可工作的软件是进度的首要度量标准。 08.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 09.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 10.以简洁为本，它是极力减少不必要工作量的艺术。 11.最好的架构、需求和设计出自自组织团队。 12.团队定期地反思如何能提高成效，并依此调整自身的举止表现。
90年代和2000年前后，正是CMMI如日中天的时候，大家可以想象一下，当敏捷成为一种革命，向SEI实验室那帮老古板开炮的时候，会出现什么一种情况？
我们预想中的火星撞地球般的激情碰撞并没有发生。虽然前期的确有一些分歧，但是经过若干次讨论，那帮老古板觉得“这帮小子说的有道理啊！”于是乎在CMMI1.3修订的时候，SEI的那帮主任评价员们高调的对外宣称“我们的CMMI也是支持敏捷的”，然后在CMMI2。0修正的时候，把支持敏捷作为特性之一彻底的融入到了CMMI的框架内。
如果回顾以前的往事，发散一下思维，大家想一下，敏捷是站在反对以CMMI为主导的软件工程方法的立场上的，为什么CMMI组织并没有激烈的反抗呢？
我个人认为，答案是非常简单的，因为敏捷的思想在理论上是正确的，每一句话都是符合软件工程学的基本理念的。那么CMMI就是错的吗？如果仅仅是看CMMI的条文，我们会发现CMMI也是对的，两者并没有基本的抵触。我想这也是CMMI会在后续修正的时候不断的引入敏捷思想的原因。
大家可以看到，敏捷的共识只有敏捷宣言，那些敏捷思想的开创者和继承者们，在敏捷思想上提出了很多活动的开展形式，如结对编程、冲刺、站会等，这些活动有一些其实在敏捷思想面试之前就已经存在了，但是后来因为敏捷逐渐变成了热点，这些活动也被贴上了敏捷的标签。很多组织者，将这些活动组合，构成了自己的方法族，并在实践中加以应用，公开布道并拥有了自己的支持者，这就形成了不同的敏捷流派。如当下比较流行的Scrum，XP，水晶方法族、精益等。
那么，敏捷这么多，我们应该如何选择适合自己的方法呢
这一篇够长了，下一篇再写吧。