这些年目睹之敏捷怪现象

敏捷中很多的实践都是来自于20世纪90年代，甚至更早。随着2001年敏捷宣言的提出，敏捷在IT领域的使用越来越广泛。这也说明了敏捷可以给大家带来很多非常好的帮助。

这次要讲的内容并不是要来赞美敏捷的，而是希望从一些做的不好的方面来对敏捷在IT领域的应用做一些反思。希望能够触发大家对敏捷的一些思考。

敏捷不仅是给原班人马换个称呼

在团队刚开始准备向敏捷转型的时候，经常有人会问“原来的项目经理在敏捷项目中应该做什么？”这个问题的答案是“敏捷项目中没有项目经理这个角色！“。当然这个问题里面的“项目经理”可以换成”Technical Lead“、”测试经理“等角色，答案都是一样的。

大家应该都比较熟悉敏捷中各种角色，例如：产品负责人（Product Owner），Scrum Master和开发人员。于是在敏捷转型后，很多团队有些神奇的做法。那就是将原来团队中的各种角色的称为直接改一下。原来的Technical leader称为敏捷教练（Agile coach）, 原来的项目经理摇身一变称为Scrum Master, 公司的Sales称为产品负责人（product owner）。于是乎，敏捷就转型成功了！ 自组织的团队才是最高效的团队。每个角色换个称呼，并不能帮助构建自组织团队。

只有整个组织都敏捷才是真敏捷

上面一节提到的换个称呼的怪现象其实本质上来源于组织层面对敏捷的认识。换句话说，敏捷并不仅仅是开发团队自己的敏捷。而是整个组织架构的敏捷。从下而上的敏捷罕见成功的，从上到下的敏捷才能真正发挥敏捷的优势。这里的自上而下的敏捷不能仅仅停留在口头上，而是要体现在组织架构和各种机制的敏捷化上。判断一个公司是否敏捷有个非常简单的测验。

一个团队在准备转型成为敏捷团队的时候，希望获得一个来自外部的敏捷相关的培训。那么从这个团队产生这样的培训需求，到最终这个团队真正能够获得培训为止，这段时间的长短，就可以反映整个组织在多大程度上是敏捷的。

这个测验里面可能涉及到整个公司的审批、财务、采购、人力资源等各个环节。很多团队从提出需求到最终获得培训需要几个月的时间。如果这样的组织不从公司机制上做变革，怎么可能实现敏捷呢？

固有势力的阻碍

敏捷可以给整个软件交付带来非常多的好处，可以释放团队的活力，按道理能够非常容易的获得团队的支持。那么实际情况是这样吗？显然不是，在转型的过程中，有非常多的人都会成为敏捷转型的绊脚石。

首先就是已有团队中的各个部门的经理，开发经理、测试经理、产品经理、项目经理等。因为在敏捷开发中，没有给他们留下合适的位置，一旦完成了敏捷转型，他们原来的地位都可能保不住，要么多个经理合并成一个、要么需要转型、要么就会被裁掉。”满嘴都是主义，心里都是生意啊！“。职场里面每个人都有自己的小九九。

其次还有整个测试团队都会陷入极度的焦虑。因为敏捷中留给独立测试人员的空间越来越小了，各种测试驱动开发中的测试活动都是开发人员自己来完成了，没有测试人员什么事了！测试人员需要转型，测试需要前移。于是很多测试团队以质量为旗帜，希望能够继续原有的测试模式，迟迟不愿放手。

最后，开发团队其实也可能是抗拒敏捷转型的人。这个可能大家会比较意外。在转型过程中，凡是解放生产力的都是大家欢迎的。就像大家最喜闻乐道的”敏捷了就不用写文档了“，很多开发人员满心欢喜。但是敏捷中的拥抱变化、透明化等都给开发团队带来了很大的挑战。想要拥抱变化，对开发人员的要求显然是提高了。没有整个基础架构的优化，没有设计的可扩展性的提高，怎么可能突然就能够拥抱变化了呢？敏捷项目中，节奏非常快，而且大家每天做什么都需要非常透明，进度需要及时公开，这些都给开发人员的日常工作带来了压力。“谁家平时还没有点事情啊！谁没有心情不好不想干活的时候啊！”。

除了已有的各种角色的阻挠以外，已有的组织中的一些工作方式也可能会阻碍敏捷转型。例如：各种工作表格、中间多层次的团队管理等。所以在推动敏捷转型的过程中，一定要考虑“人性化”这个重要的方面。任何变化都应该能够给参与者带来可见的好处，这样才有利于推动转型。

 

 

用一个新的复杂的流程来实现敏捷

传统的公司尝试建立各种各样的流程，然后让所有员工 都遵守这些流程。通过这种方式，希望员工能够把事情做好。敏捷强调的是”个体和互动高于流程和工具“。所以敏捷中的文化、价值观、原则和实践都是围绕个体和互动来进行的。

但是实践中，很多团队的固有思维还停留在传统模式上。最常见的就是，大家经常会问“敏捷中的流程应该是什么样子的？”。Scrum看起来非常完美的解决了这个问题。Scrum提供了一个流程，现在在很多敏捷开发中使用。于是乎出现了这样的认识，”我们团队用了Scrum，于是我们团队就敏捷了！“。

随着敏捷得到越来越多人的认可，很多组织都想转型到敏捷。但是他们发现Scrum的流程好像不能适应他们公司大型项目的需要。于是又出现了一些新的敏捷流程是针对大型项目的。SAFe（Scaled Agile Framework）就是其中之一。大家看一下下面的这个SAFe的流程图。

 

 

这个流程图比较复杂。大家可以在SAFe的官网上找到更清晰的图。我们在回过头来看看敏捷宣言的第一条”个体和互动高于流程和工具“。对比这个复杂的流程图。你是不是惊奇的发现，SAFe通过构造一个复杂的流程来帮助大家实现敏捷。而这样的流程正是敏捷希望”Over“的。那么这个敏捷和之前传统的开发还有什么区别呢？SAFe的流程图中，除了左下角的Srum流程外，其他的整个图的构造和内容和传统的项目有什么不同？

大家希望寻找一个新的流程来over之前的流程本身就已经脱离了敏捷的初衷了。

我们如何做才算敏捷呢？

很多团队在开始敏捷后，经常会对自己的一些做法是否符合敏捷的要求有疑问。

敏捷中的测试应该怎么做啊？
我们这样做代码评审算敏捷吗？
敏捷中的估算是怎么进行的？
我们天天早上开站立会议，我们还不敏捷啊？

当关注点在”是不是敏捷“而不是”如何更好的把事情做好”的时候，团队可能就会进入一个迷茫的状态。敏捷从宣言、原则到各种实践，都是为了能够给客户提供更好的产品服务的。过于纠结于敏捷是什么，自己做的算不算敏捷其实并没有太多的意义。

对于敏捷的理解，每个团队有有所不同。现在大部分团队都把敏捷当成一种文化。下面这种伞图经常出现。就像图中所示，敏捷其实是一把打伞，在这把伞下面包括了各种流程、方法、实践。更重要的是，这些内容并不是一成不变的，而是在不断的演化。

 

 

没有一个团队能够把所有敏捷包括的内容都实施了，任何团队也不需要全部实施。每个宣传是敏捷团队的，都是或多或少用了敏捷的一部分。换句话说，其实每个团队基本上都可以说自己是敏捷团队。问题的关键是，宣称自己的团队敏捷后，到底出现了哪些好的变化？是效率提高了，浪费减少了还是交付质量更高了。

结束语

上面描述了敏捷中出现的一些怪现象，这些现象其实都是在转型过程中非常正常的现象，敏捷本身并没有尽头。每个团队都在敏捷的路上。

参考资料：

1. The death of Agile - Allen Holub https://www.youtube.com/watch?v=vSnCeJEka_s