前言

我个人如果算上大学读书的时间，到目前差不多有将近三十年是接触IT方面工作。在这三十年的时间里，也就是从上世纪八十年代中后期到现在，我基本经历了中国IT高速发展的整个阶段。

在八十年代之前，虽然也有计算机，但计算机并没有进入到企业办公当中，只是在一些核心部门使用。而计算机真正开始大面积普及，则是从八十年*开代**始的。

软件开发的各个时期

讲到敏捷，就不得不提软件开发方面，我所经历过的各个开发时期。

第一个时期，我们称之为大侠时代，比如我们现在熟知的求伯君，其实都是那个时代侠客级的人物，也就是一个人就可以写一个软件。这个时期的特点就是，软件工程师们凭一己之力，就能编辑出非常好的软件。但是大侠时代，即便他们能力非常强，但写大规模软件，依然会出现个人精力不足的状况。

第二个时期，我们称之为混沌时代。因为需求的增加，大学教育开始普及计算机知识。这部分学生进入到社会工作之后，开始组团干活，他们基本上以编程开发为主，但是对于软件开发过程管理，却没有太多的经验。同时对于软件公司，也没有太多的经验积累，往往三、五个人，十几、二十个人，他们需要代码管理，也需要质量控制，工作流程非常混乱。

第三个时期，也就是九十年代中后期到2000年初，整个IT行业开始走向正轨。这个时候软件成熟度模型、设计模式、各种架构，开始进入到普通IT人的视野，大家也开始尝试用软件工程的方法，来改变自己的工作方式。从这个时候开始，IT人认识到，一种标准化的或者比较正规的流程出现，会给企业发展带来好处。

第四个时期，也就是IT发展进入正轨之后，人们的软件开发能力有了大幅提升，随后逐步进入重型军团阶段。在这个时期，软件开发过程管理非常严格，团队非常庞大，通常采用瀑布模型，但往往就会使得事情过犹不及。在这个时候，敏捷就应运而生了。

在文章的题目中，我说到敏捷是一把双刃剑。其实我们看到各种文章，更多的是讲敏捷如何好，DevOps如何好，它能够解决什么问题，但很少有人讲敏捷的伤害是什么，或者我们用不好这个工具时，它对我们的伤害是什么。

为什么要敏捷

我用三个小故事给大家梳理下为什么要敏捷。

首钢经历的三边工程

我第一份工作是在首钢，由于刚毕业，我对工作内容不是很熟悉，同时周边同事都不是计算机行业，因此当我与其他同事聊天时，会发现他们对当时设计工作非常不满意，他们说当时工作方法叫“三边工程”。什么叫“三边工程”？边设计，边施工，边修改。设计人员非常不喜欢这种方式，一方面设计中有着大量需要修改的地方，另一方面，修改设计就意味着浪费大量的时间，尤其当时图纸还是手工画图，修改就相当于重新开工。而对技术人员，这也是巨大的浪费，因为此时成本可能从1，增加到了2甚至是3。但是经验更丰富的师傅，他却从另外一个角度给了答案。早投产则就意味着早收入，而收入将抹平损耗，同时带来更多的收益。

马路上的拉链与边陲小城的10车道马路

在中国改革开放以后，国内整个基础设施都需要大规模改造建设，比如说马路三天两头就被豁开，为的是进行煤气管道改造、通讯线路改造、上下水管路改造等等，民众对此唉声载道。

但在内蒙却有一个神奇的地方：包头。

包头的城市规划，从很早时候开始，就是10车道并行。这在早期是有弊端的，城市太大，交通以及其他方面极其不便。但是进入八十、九十年代以及后期，包头的优势就体现出来了，它的所有设计，都是为了让这个城市在多年之后，是不需要对城市进行改动的。并且随着几十年的发展，城区开始融合，道路交通也变得更加合理，城市井井有条。

以上的两个相反例子，其实正是今天IT人员所面临的窘境，我们既要时间，也需要长远的规划。

永远的beta版

在2004年，我听到了一个词，那便是web2.0。当时我们做传统软件开发，是有测验版，即beta版的，随后会有1.0版、2.0版等等。但是在web中却有一个词，叫做永远的beta版，便是这个软件永远做不完。这便是最早从需求层提出的一个出发点，也就是做敏捷时需要平衡的点。

新时代下瀑布模型面临的问题

需求愈发不明确

过犹不及

唯快不破

整个大环境来讲，需要我们更快的验证我们的想法，去提升客户的体验，完成客户的需求。这便是瀑布模型所面临的问题，也是敏捷方法被大家广泛所使用的根本原因。

敏捷我们准备好了么

认知

我们说做敏捷的时候，是有敏捷需求的，首先就是认知层面的需求。敏捷对大家、对整个团队、对整个公司、对组织的要求，不是降低而是提高了。在认知层面，因为很多有一定经验的人，他们最早接触的都是瀑布模型，或者从公司整体纯管理角度来讲，他们要的是时间节点，所以如果在认知层面，大家没有达成统一的话，很容易在公司内部产生矛盾。如果我们要用敏捷方法，大家至少要在公司最高层面达成一致。我们应该相信它能给我们带来收益，同时对我们的工作和其他方面产生的改变，我们也应该与之相适应。

组织管理与人员

说到组织管理与人员，我们都知道一个很著名的组织，那就是老中青三结合。实际上敏捷方法要求的是，我们人员构成是锥形的。所谓锥形，是做大部分工作的员工，他们的水平至少是中等，他们应该在写程序的同时，还要能够让人看懂程序。这与以前瀑布模型下，人员的构成是不同的，组织管理与人员调配模式发生了很大变化。

团队与技能

以前一个项目可能需要特别大的团队，比如项目经理需要带十几、二十人的开发人员。但现在这种模式就不太适合，我们更适合中小型团队，比如说五到八个人。当然，现在需要完成的模块也相对比较小。这对我们同事的技能要求，就变得更高。之前是可以不写文档的，只是使用代码就行，但是现在如果不写文档，就意味着所有的变量、数据库、结构设计等，都需要用英语表述，但其实国人的英语并不好，远没有达到母语程度，所以只写代码可能就会有问题，文档这个时候就派上了用场。

系统架构与原则

有了技能和人员是不是就够了？其实还要看我们系统是不是符合敏捷工作的架构。例如：我们的系统是不是可以分成若干层面完成？我们的系统是不是像一个大泥球一样，所有的功能都揉在了一起，牵一发而动全身？你能够做到水平扩展或者局部扩展吗？这些都是在做敏捷之前，我们需要在IT架构层面，之相匹配的。

软件架构与原则

在软件设计当中，如何去更好的将软件进行解耦，让软件具有一定灵活性，并且当我们需要做一些调整时，它涉及到的模块不用很多，从而能够快速发布其中一部分，而不是每次发布，都需将整个系统全部重新更新一遍，我们能否做到这一点呢？

总结

以上很多内容，我相信平常大家都是不愿意看到的，但是敏捷能否成功，最关键的其实恰恰就是以上问题。它涉及到的管理成分多于技术成分，枯燥成分多于酷炫成分，但是如果这些方面都能够做好，那么从运维的角度，遇到的所有问题就都能迎刃而解。而如果不考虑这些问题，可能虽然使用了敏捷方法，但却会让工作做得更糟，那还不如用重型方法完成，它至少保证了工期一拖再拖，最终交付的方法是可用的。