敏捷转型

如今越来越多的组织尝试敏捷化，但是大多数都失败了。有些是因为完全走向了另一条压根不是敏捷的”快速敏捷“，有些由于开发人员对技术实践的抵制变成了”伪敏捷“。

敏捷转型是一件挺难的事情，一篇文章或许解决不了什么大问题，这里有一些你或许会用得上的小建议。

敏捷的价值观

前面几篇文章要么解释了敏捷是什么，要么介绍了敏捷实践，现在我们从敏捷的价值观入手，看一个组织如何实现敏捷转型。

勇气

敏捷鼓励在合理范围内敢于冒险。政治意义上的”安全“，意味着可能会丧失质量和机会。管理软件项目的最佳办法是具备一定的侵略性。

但是勇气不等于鲁莽。持续维护和写出高质量的代码需要勇气，随意的不可读代码就是鲁莽；不以妥协质量来遵守时间表需要勇气，通过牺牲质量来遵守时间表就是鲁莽。

质量和纪律是提高速度的唯一方式，这是一种信念和坚持。在时间压力面前强势但幼稚的人选择妥协，抛弃信念，坚持你的信念，需要你的勇气。

沟通

敏捷重视直接、频繁、跨渠道的沟通。所有的角色 - 程序员、客户、测试人员和管理人员应该坐在一起频繁互动。相比起邮件、聊天工具，敏捷更重视面对面、非正式的人际对话。

在快速、混乱、非正式的、风暴式的频繁互动中，灵光会突然乍现，人们会有意外的收获。坐在一起并经常交流可以创造奇迹。

反馈

敏捷的所有实践和纪律的目的都是为了向决策者提供快速反馈。当出现问题时，我们希望尽早识别、及时纠正。这些实践让人们看到此前决策者的效果并从中吸取教训。敏捷团队的反馈越快速，团队越健壮。反馈使团队高效工作，并且促使项目取得有益成果。

简单

敏捷希望直截了当。被动攻击型行为是不直接的表现。你发现了问题，但是一声不吭；你明知后果却仍然同意了经理或客户的要求。

简单价值观希望团队里的一切都是简单的 - 代码遵循简单设计，直截了当；沟通时直接描述问题，不拐弯抹角。保持代码简单，同时保持团队简单。

敏捷转型

如今已经不是 2000 年的时候了，现在敏捷方法多不胜数（我们这里排除”伪敏捷“）。不论你的组织选择的是哪一种方法，敏捷转型都需要根据组织的需要适当调整。

不可或缺的技术实践

无论怎么调整，技术实践必不可少。失去了技术实践的敏捷就是一个陷阱，马丁·福勒称之为”疲软的 Scrum“(Flaccid Scum)。

不引入技术实践，敏捷的业务实践可以高效地搞出一大堆垃圾。项目的生产力随着项目的进行缓慢下降，因为没人能处理那些快速腐化的代码。为了赶上业务，大多数人不在乎结构的整洁和代码的质量，项目终将陷入重写的死亡循环。

转型的困难

转型并非易事，这是一次价值观的转变。且不说敏捷的价值观与大型组织的价值观截然相反，光是想要将一个非敏捷团队的价值观转换成敏捷价值观就不是一件容易的事。

组里前端时间刚好来了一个完全没有接触过敏捷的新人。刚开始的一段时间他陷入了巨大的痛苦之中。

组里的敏捷纪律严格，我们会在 code review 中提出任何觉得不合理的地方，小到一个变量的命名，大到组件的设计和使用；我们严格 TDD - 或者你愿意的话自己慢慢补测试；我们严格遵循简单设计。

这些一切的一切都颠覆了他的认知，之前他的工作中从未将代码质量提升到这样的高度 - 简单的规范和能用的代码就够了。更不用说技术实践之外的业务和团队实践。

当然故事的结尾是美好的，他成功转型，并认为这些实践的确在保证项目的同时提升了自己。

但其实敏捷转型这件事的阻碍从来都不是底层团队，阻碍来自组织中层。高管们也经常被冒险、直接、沟通等敏捷价值观驱动，这也是为什么这么多组织期望敏捷转型。但你仔细想想，中层的工作就是不冒险、避免直接、以最低限度的沟通来服从和执行指挥链。

架构师、技术主管、项目经理等等中层认为他们的角色在敏捷组织中将被削弱。事实上他们的角色确实会有所改变，但并非削弱。

推进转型

假装

如果阻力太大，团队可以悄悄用敏捷价值观来驱动他们的日常工作，同时明面上遵循中层管理者对他们的要求。只要在使用敏捷的同时能够满足中层的要求，大部分人会放任团队行事。

这其实在敏捷和中层管理者直接多加了一层保护层，管理者可以不在乎团队以什么样的方式工作，但要求能够完成管理者的要求，这种方式避免了和管理者之间徒劳的战斗。

如果管理者需要文档，团队大可安排一系列文档故事来编写文档。

但是也有失败的情况，有的管理者发现团队在”搞小动作“，认为团队失控了，要求团队立即禁止敏捷纪律。

个人推进

有时候敏捷的转型是从团队中某个人或某些人开始的。最好的情况是他能够推进组建一个全新的敏捷团队来完成某个项目，并设法以”假装“的方式瞒住中层(当然，我们这里假设中层不希望敏捷转型)。

最坏的情况是没有办法推进，要么个人继续接受旧的开发方式和价值观，要么跳槽到价值观一致的公司工作。

创建新的团队

这个方式通常会在大型组织里面出现。在一个大型组织想要敏捷转型时，由于种种原因没有办法从已有的团队推进转型，他们会考虑组建一支敏捷团队来进行新的项目，然后以这支团队为基础在整个组织层面推进。

还有一种方式是保留现有团队不变，雇佣敏捷咨询公司，将自己的团队和咨询团队放在一起进行开发任务，让咨询公司的团队潜移默化地影响自有团队，这样的合作可以是大规模的，不局限于单一团队。

敏捷教练

在谈敏捷教练这个角色前，我们需要先区分敏捷培训师和敏捷教练。

敏捷培训师的任务是教会团队如何自行实践敏捷，他们通常是从公司外部聘用的培训师。他们的就职周期较短，以一个 10 人规模的团队来说通常只持续一到两周，然后团队需要自己去学习其他需要学习的东西。

而敏捷教练是团队中的一员，他的职责是捍卫团队中的纪律和流程。比如在开发过程中有人可能在无意识中停止了结对、停止了重构，或者忽略了构建中的失败。此时教练就需要站出来指出问题所在并提供解决方案，教练是团队的良知和价值观的守护者。

成熟的敏捷团队通常不需要这一角色，又或者说这个角色更像一顶帽子，在各个成员之间轮换，谁发现了问题，在当时谁就是教练。而如果一个团队处于交付压力下，则可能就需要一个固定的人选来监督团队。

需要明确的是，教练不是管理者。他不负责预算和日程，教练既不负责团队的方向，也不在管理层面前代表团队利益。教练的角色完全是团队内部的，理论上经理和客户不知道教练是谁，甚至不知道是否有教练。

敏捷变革下的敏捷教练

上面提到的是一个成熟敏捷团队中的敏捷教练，我所知道的更多的情况是：想要敏捷转型的组织由于自身没有方向，转而向外界寻求帮助，聘请外部敏捷教练帮助组织转型，此时的敏捷教练任务就相对繁重，所需要具备的技能也更加复杂。

敏捷教练的任务主要是为了在组织中引入敏捷，为此教练需要具备专业的教练技术，同时也需要具备敏捷和转型的知识。

在个体层面上，教练的精髓是帮助人们自己解决问题。在团队和组织层面上，教练技术意味着帮助团队自己实现目标。

首先，教练把敏捷导入过程中受到影响的每个人都视为”客户“。然后，他们通过回顾、开放空间等技术，发现客户眼中的挑战和机遇，这些挑战和机遇将成为组织的敏捷导入待办事项。接下来，教练使用小圆点投票之类的团体决策工具，确定最重要的待办事项。然后，他们帮助组织实施一些最重要的待办事项。最后，他们进行回顾。重复上述过程直至组织逐渐踏进敏捷的圈子。

大型组织中的敏捷

这是一个颇具争议的话题。由于敏捷在开始就被定义为帮助小团队获得成功的一种组织方法，所以在同时就有人提出了一个问题 - 大型团队能够实现敏捷么？

一些人试图解决这个问题，比如 Scrum 的作者提出了 ”Scrum 的 Scrum“(Scrum of Scrum)，后来还有了商业品牌的 SAFe 和 LeSS 方法和书籍。

但也有另外的人持有不同的意见 - 敏捷就只是为中小团队服务的，数千名开发人员的大团队有他们自己的玩法，但不是敏捷。敏捷从诞生之初到现在就没想过要解决大型团队的问题。因为大团队是一个已经被解决的问题。

大型团队的问题是所有社会、所有文明共同的话题，比如如何建造金字塔，比如如何把人送上月球，再比如如何打赢一次大规模战争...无数实例证明我们其实已经解决了这个问题。

而如果中小团队去效仿大团队做事情，几乎都会被这些方法流程拖死。流程和做事方法的规范只会拖慢小团队的效率，小团队需要的就是简单直接和一路向前的勇气。敏捷的出现恰好解决了中小团队这些当时还没解决的问题。

那是不是说小团队的问题就不是一个被解决的问题呢？当然不是，不解决小团队的问题怎么解决大团队的问题呢。敏捷的出现是为了解决软件这一特殊行业中的小团队问题。

所以一个解决大型组织中敏捷的办法是，将开发人员组织成小型敏捷团队，然后使用标准的管理方式来管理这些团队，他们就构成了一个大型组织。

在这部分人看来，根本没有所谓的大规模敏捷。敏捷是一种专门用于组织小型软件团队的创新。当然，这里的情况仅供参考，如果你需要的是大规模敏捷的解决方案，或许可以找找别的路子。