这是敏捷系列中的第一篇 - 01AGILE
在敏捷团队中，经常会被问到敏捷的一些具体实践的问题，如下：
如为什么要TDD？为什么要Pair？为什么要每天都要提交到主干？为什么不用分支？
之所以会产生这些问题，是因为团队成员在具体操作某项敏捷实现时，不知道这样做的意义在哪，到底解决了什么问题；如果说带来的好处不明显，就一定会对这些实践产生疑惑。来自内心深处的抗拒也会越来越猛烈。
如果想单独对某个具体问题来进行解答，又会觉得答案再明显不过，似乎没有什么好解释的，就因该这样，就像 1 + 1 本来就等于2一样。
比如：TDD，你随便一搜索，就会有一个很明确的答案：是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。
道理大家都懂，但就是做起来没有什么感觉！这里的‘感觉’，也正是我们这里要解决的问题，希望大家通过本篇对敏捷简史的介绍，从不同的角度找到自己对敏捷、对敏捷实践的一些‘感觉’。
借用下面这张图来看一看敏捷的出生环境：
敏捷简史时间线
人类的发展，社会的进步，都是靠解决问题，提高效率来反复演进的。软件行业也不例外。
20世纪60年代，人们品尝到了计算机软件带来的便捷，需求的膨胀一发不可收，对软件的要求也越来越高，但对软件工程的管理又没有跟上节奏，差距越来越明显，就这样，软件危机爆发了。简单的理解就是，当计算机处理能力和合作能力都很弱的时候，编程根本就不是问题；当我们有几台计算能力一般的电脑时，编程也还只是很平合的问题；但当我们的电脑变得很聪明很巨大时候，我们面临的问题也变得严重和复杂。
软件行业需要发展，那我们就得面对这些问题。世上总不缺少聪明人，而软件行业尤胜。就有人在70年代提出了-瀑布模型，强调系统开发因该有完整的生命周期，分为需求分析、设计、开发、测试和维护这几个主要阶段。有了这套标准后，项目能更准确的计算时间和成本，团队也能更好的安排和计划，一切看起来都变得井然有序，不能再美好了。
不过美好的事情在快速成长的软件行业是很难持久的，很快人们发现，瀑布模型很清晰的明确了流程，但也大大限制了后继的流程，如果已经进入测试了，但需求发生了变化，无论是成本，还是原先约定的交付时间，都很难保证。人们又分别推了快速原型模型、增量模型和螺旋模型，他们各有所长，分别解决了快速确定真实需求、增量构建系统和风险驱动，即给你改变方案的自由，同时也明确约束的条件。
到了这一步，似乎已经能很好的完成软件项目了，随着时间的沉淀，出现了一些组织机构，并制定了一系列的标准，用来控制流程，保证上质量。同时也明确了衡量公司团队资质的标准。条文很丰富，内容很明确但也冗长，基本上也只有一些大公司能够满足他们的条件，拿到相应的资质。这里提到的主要是ISO和CMM。
完整的流程，完备的文档，明确的限制。一些不愿固步自封的人又开始不安份起来，他们希望找到更好的软件开发模式。20世纪未，敏捷软件开发宣言应运而生。
核心理念只有寥寥几条，相对ISO和CMM，确实简化了不少：
个体和互动高于 流程和工具
工作的软件高于 详尽的文档
客户合作高于 合同谈判
响应变化高于 遵循计划
读完你会发现，这里用的都是“高于”，而不是完胜之类的词，很明显，敏捷是一种方法论，更是一种文化。
再回过头来看看本文开始抛出来的几个问题，你是否能够找到对敏捷的感觉，对敏捷实践的感觉？
如果还是不能，请接着看后继章节。因为我们不是-从入门到放弃系列。
参考资料索引：
1：TDD
2：软件危机
3：瀑布模型
4：软件开发模型
6：敏捷软件开发宣言
网友评论