2018 年底我写了一篇文章，叫「Scrum 实践 - 我们是如何做敏捷开发的」，现在每次看到这篇文章，都觉得自己当时对敏捷的理解太浅，践行的是「中华田园敏捷」。2019 年开始系统地看了很多关于敏捷和极限编程的理论和实践资料，升级迭代了很多我对敏捷的认知，从 2019 下半年开始，决定让团队开始全面转向敏捷。

本次我通过一个系列的文章，从敏捷团队组织架构、工具、流程、数据、激励、自组织等各方面，去分享我们近半年的敏捷实践，以及我们是如何从敏捷中受益的，希望我们的最佳实践能给正在敏捷转型过程中并处于迷茫期的团队以帮助。

我们使用的是 Scrum 框架来做敏捷实践。

Scrum 中两个重要的角色

Scrum Master - 这个角色在转型 Scrum 刚开始甚至中期非常重要，一定要由全职的人来担任，前期的 Scrum 普及工作，非常多的 HOW-TO ，教练工作，协作流程，以及会议组织（特别是回顾会议）是 Scrum Master 的重点。这次转型前，我们的 Scrum Master 一直是团队成员兼职担任，这分散了团队成员开发的注意力，同时又没法将 Scrum Master 本职工作做好。根据不同团队情况，当整个团队走完 10 个至 20 个 Sprint 后，Scrum Master 这个角色可以慢慢淡出，变为兼职，因为这时团队对敏捷的理解已经很充实，而且团队默契已经形成，也有了相对固化的协作流程。

PO - 外包团队的 PO 是客户，在 ThoughtWorks 这类「外包」公司，团队有 BA 和业务方 PO 对接做业务分析。对于我们这类产品型公司，PO 由传统的产品经理担任，职责也基本一致，这里不过多说。

上述两个重要角色的关键一定是需要对敏捷有非常深入且一致的理解和非常高度的认可，所以在转型前，我们团队让 SM 和 PO 都提前去参与了 CSM 和 CSPO 的相关培训，也算是持证上岗。

Scrum of Scrum

转型初期，我们在内部建立了一个叫做 Scrum of Scrum 的组织，这个组织的参与者包括所有的 PO，SM，以及之前兼职担任过 SM 现在作为 DevTeam 的成员等，这个组织的目的是提供一个关于敏捷的学习交流平台，我们直接用 Scrum 的方式来推进这个组织的运作，提出所有我们不知道应该怎么做的事情，去找答案，讨论，让参与者将我们形成的结论和一致认知，带回到团队，将自己学习和理解到的敏捷，去影响其他人，从点到面让所有团队成员都对敏捷逐步有深刻的理解。这个组织每周一次固定一小时的交流，持续了三个月，我们一起解决了转型初期非常多的疑惑，达到了很好的效果。当然，在转型初期，我们要求所有团队成员都完整地看一遍《硝烟中的 Scrum 和 XP》这本实战性非常强的书，并一对一沟通每个人对于书中内容的理解，保证大家的认知一致性。

矩阵式组织架构

说新的组织架构前，简单讲一下我们之前的组织架构，我们之前采用了一种矩阵型的组织架构，如下图：

matrix-arch

矩阵式组织架构是这样运作的

  • 立项时，团队成员由职能主管从职能部门（服务端、客户端等）分配到项目组

  • 在项目中，团队成员被分配任务

  • 团队成员要例行向职能主管进行每周工作汇报

  • 项目结束后，团队成员从项目释放，回到职能部门，待分配到下一个项目

这种矩阵架构存在一些问题

  • 项目团队不固定，团队没有固定的流程和规范

  • 每次项目团队重组后，成员之间协作都需要进行磨合

  • 每次重组项目团队时，职能部门中谁可用就只能用谁

  • 人力资源很难分配均衡

  • 双线汇报

新的组织架构 - 引入小队的概念

组织定位

  • 小队是一个相对固定、高度自治、迷你的「创业公司」，具备开发和发布产品需要的所有知识和技能，肩负一个长期的使命，长期从事某一类任务或者开发产品的某一个部分，例如：

    • 功能团队（FT - Feature Team）：专注于某块功能特性，例如园本库、高质量陪伴等

    • 基础设施小队（IT - Infrastructure Team）：提供如持续集成工具、云平台基础设施工具等，让其他小队更有效率，不进行业务特性开发

    • IT 影响 FT 中相关成员按照 IT 制定的规范和原则进行业务功能开发

小队成员

  • 不存在官方任命的团队领导

  • 各功能小队有一位产品负责人 PO
    • 各小队的 PO 之间需要紧密合作，共同维护一个宏观的产品路线图（Roadmap），指引整个公司的产品发展方向
    • 每个小队的 PO 也分别维护一个自己所在小队的产品待办列表（Product Backlog）

  • 有一位公用的敏捷教练（Scrum Master），帮助 FT 小队改进工作方式

  • 工作方式

    • 坐在一起工作

    • 自组织管理

    • 通过回顾会议等自定义和自改进小队工作流程

新架构与之前矩阵架构的区别

  • 团队成员在小队中持续工作，与小队中其他成员共同打造优秀的产品

  • 团队成员汇报对象是 FT 团队

  • 小队具备开发和发布产品需要的所有知识和技能，能完成所有工作

这样的组织架构，对团队成员的自组织和自驱力要求很高，这也是我对团队成员的一贯要求，因为团队目标的一致，所以团队成员之间在协作时也会形成一个相互制衡，共同向上的拉力。

实际上，我们有两个 FT 团队，每个团队固定两周一个 Sprint，两个团队 Sprint 交替开，于是，对于用户来说，每周会有一个新版本发布上线，这样让整个产品迭代的节奏也非常健康。

通过上述组织架构，可以看出，我们淡化了产品部和研发部的概念，研发内部更没有服务端和客户端部门划分，全部都以纵向的方式组织，PO 和团队完全融合在一起，服务端和客户端完全融合在一组。这样的组织形式，让团队可以拥有长远的共同目标，持续磨合，持续改进流程，通过后面的数据篇可以看出来，团队的效率会稳步提升。

结构决定功能，组织架构变化是走好敏捷转型的第一步。

参考资料：

Spotify敏捷模式详解三部曲第一篇：研发团队 https://mp.weixin.qq.com/s/Srd6esYCy_babI_4Q3RrBQ

硝烟中的Scrum和XP https://www.infoq.cn/article/scrum-xp-from-the-trenches/