新型的敏捷矩阵组织：部落、分队、分会和协会

（作者：Jacky Shen)

组织导入敏捷往往更加关注形式和标准化，然后却发现不同团队的接受程度不同。 这里介绍了Spotify 的大规模敏捷之路。在从6个人扩张到1200人的过程中，它使用一种了新型的矩阵组织来扩展：部落、分队、分会和协会。

之前@申导 在NSN工作时，诺西的敏捷组织也有些类似这样。每个DA(开发部门，负责系统中一大领域)就是一个Tribe,大约80人左右。每个Scrum Team就是Squad, 大约5-9人，开发测试跨职能团队。横向会有一些技术领域或测试能力的Competence Center，正如Chapter，人们在跨团队之间组成相近领域的小组进行交流和协作，比如某两个团队可能都工作在同一个component上，那么其中的某几个人都是这个component的贡献者和Chapter成员。至于大部门之间，一定也少不了协作，同样需要虚拟专家团队为持续集成系统共同努力，或者对Chrous操作系统的兴趣小组，或者教练社区，这些都可以称为Guild。 这种大规模敏捷的扩展方式，也被称为”LeSS”.

借用@窦涵之 之前画的一张图。

这是矩阵组织，但也不完全是。这个和我们常用的矩阵结构是不同类型的。
大多数矩阵组织中,相似技能的人“扎堆儿”到一起形成职能部门,接着“被分配”到项 目中,并且“汇报”给职能经理。而这里的矩阵偏重于交付。鼓励团队有自己个性化的实践，自发地传染和授粉行为。但每个团队需要与整体目标对齐，避免局部优化。一致性与灵活性之间寻求平衡。

团队的约束和边界在于产品方向和策略，以及短期的迭代的目标。内部开源模型，其实就是集体代码所有制，尽量消除模块团队之间的壁垒。

大型组织内的团队需要高自治(Autonomy)与高对齐(Alignment)。

固定时间盒的release train发布模型，利用feature toogle未完成的特性。做模块解耦这样增加分别发布的灵活性。

频繁地发布与降低发布难度相辅相成。运维部门更多关注如何能帮助研发团队“自行发布”。

在人员培养上，更加着重激励，关注人们为什么不满意。鼓励团体作战，与他人协作找到更好的解决方案。

更多参考：

http://bobjiang.com/wp-content/uploads/2014/02/Scaling-Agile-at-Spotify-v7.pdf
http://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
LeSS
SAFe
http://www.scrum-breakfast.com/2013/10/scaling-scrum-safe-dad-or-less.html