研发管理 101 军规#003 实战规模化敏捷：从 8 人到百人的敏捷之路

如果用一句话概述本篇的主题，那就是：关注 8 人团队的自组织性，构建百人团队的研发工作流。

Worktile 是在 15 年的时候引入的 Scrum。在那之前我们并没有采用标准的敏捷实践框架，一是研发团队并不大，二是我们自己的协作工具有足够的可视化能力。

但当我们对外推出了第二款产品 Lesschat（后来 Worktile 企业版/协作版，绿色 Logo）以后，Worktile（这里指 Worktile 基础版，红色 Logo）需要持续更新，Lesschat 也需要持续更新，我们该如何处理工作的优先级呢？

基于实际的问题，公司决定把参与 Lesschat 开发的工程师独立出来，配备上独立的产品负责人，组建了一个 8 人的 Scrum 团队。我们落地 Scrum 的过程大概是这样的：

第一步：Scrum 团队启动会

首先，确定 Terry 大神为我们的 PO，确定 Shaun Xu 大神为我们的 Scrum Master。然后我们共同制定了 Scrum 团队的工作协议：

由 PO 维护产品待办列表 Sprint 周期为 2 周 Scrum 各个会议的时间、地点、内容代码提交方式故事点的标准 ……

第二步：先跑一个 Sprint

我们在第一周周一的早上 10 点，开计划会议。由 PO 进行产品讲解，说明用户故事的优先级，由开发团队预估故事规模、拆分开发任务，以及最后承诺 Sprint 目标。

每天早上 10 点，我们在工位附近的走廊里开站立会议。每人花两分钟的时间同步工作进展。

我们在第二周周五下午 4 点，开验收会议。由开发任务的负责人演示其完成的工作，然后由 PO 决定未完成的任务或新增的 Bug 要不要放在这个版本中。

在第二周周五下午 5 点，开回顾会议。每个人都说一说团队做的好的和不好的地方，我们一起确定改进方案。

第三周周二的晚上，我们部署了第一个 Sprint 完成的产品增量。避开周末上线是担心除了问题没人处理，多预留两天是为改 Bug。

第三步：两周一次，不断的改进

这个习惯我们坚持到现在。

和很多团队一样，我们在早期也遇到了很多问题，比如：

• 前后端共同完成的用户故事预估起来往往偏差较大 

• 移动端小伙伴想要的 API 经常排不上号 

• 突发的紧急任务（来自老板）打乱 Sprint 的计划 

• 每天的站立会议阶段性的流于形式 ……数不胜数

我们不断的发现自己的问题，不断的改进。随着一个又一个的 Sprint，们发现可以应用一些优秀的工程实践提升研发效率，比如简单设计、测试驱动开发、持续集成、持续部署等等。我总结我们的实践如下图：

我们在变，市场也在变，市场变了，我们也要跟着变。大概在 16 年的时候，公司决定在 Lesschat 的基础上开发 Worktile 5.0，也就是企业版，面向的是企业场景，方向转变很大，对我们研发来说又是一次考验。

忘了用了多久完成基础架构的调整，但是一定很快，快到我已经忘了遇到了什么困难。

我们在 16 年年底基本完成 Worktile 5.0，17 年年初对外发布。

5.0 上线后，Worktile 提供了一种新的企业服务方式，简单概述为：Worktile 平台+Worktile 的各个子产品（消息、任务、日历、网盘、审批等等）。

对于我们研发来说，这里的挑战有两个：一是把各个子产品拆分出来，改为微服务的架构方式；二是研发团队的规模化敏捷。第一个问题解决起来很简单，第二个问题确实考验了我们。

开始的时候，我们应对各个子产品的需求，采取的方式是打一枪换一个地方。通俗的解释就是，一个 Sprint 我们投入到“日历”这个产品中，一个 Sprint 我们投入到“网盘”这个产品中。

很明显，这样的方式不足以应对快速变化的市场，因为来自“网盘”这个产品的需求往往要等好几个 Sprint 才能实现，对于客户来说这样的速度太慢了。

虽然从研发的角度，我们是严格按照产品待办列表的优先级安排 Sprint 工作的，但是这绝非是一个理想的安排。另一方面，开发人数在增长，但是大家都在一个 Scrum 团队中，这样的团队开会效率越来越差，严重影响了开发时间。

如何把团队级别的敏捷上升到业务级别，这个问题越发重要，随着 Worktile 6.0、7.0 的开发，我们慢慢的找到了感觉，下图是我总结的经验：

团队级别的敏捷关注的是构建一个高效的自组织团队。这样的团队能够很好的完成开发工作，也能够应用优秀的工程实践提升自我的效率。

而业务级别的敏捷更加关注的是通过规模化管理研发团队，提升研发效能，从而持续稳定的实现业务价值。

组织级别的敏捷更加关注的是通过充足的市场调研确定方向，然后通过产品的真实数据验证方向，为下一步决策提供依据。

具体实施起来的过程是这样的：

1、市场调研和需求评估

a.调研包括但不限于：行业动态、竞品分析、客户反馈等 

b.需求评估由市场、产品、技术等相关方的负责人参与

2、业务线的敏捷

1. 按季度或月确定研发目标 

2. 由技术负责人、架构师评估，由产品总负责人拆分为产品特性 

3. 由产品总负责人和各个产品负责人拆分特性 

4. 由技术、架构师、产品确定各个特性的规模和完成周期 

5. 将拆分后的用户故事放入各个 Scrum 团队的 PBI 中，设置优先级

6. 各个 Scrum 团队计划各自的 Sprint 工作 

7. 各个 Scrum 团队代表每周同步各自的工作进展 

8. 按期进行各个模块、子产品的集成，部署到 UAT 环境 

9. 按期完成目标

3、验证需求和后续行动

1. 进行必要的数据收集，例如重要页面的 QPS，转化率等等

2. 进行数据分析 

3. 确定后续的产品改动方向

随着敏捷实践深入，我们发现研发的效能问题是个全行业的问题。同时，通过数据分析，我们发现自家客户 50%以上是研发场景，那为什么不打造一个专业的研发管理工具赋能给我们的客户呢？

于是 18 年，公司正式决定打造 Worktile 8.0（Worktile 研发版，现已独立品牌为 PingCode），19 年 8.0 上线。

在这个过程中，为了保证我们的交付效率，我们自研了一套持续交付平台，它可以为各个 Scrum 团队赋能，通过少量的配置化即可接入平台，轻松实现 CICD。

到目前为止，我们的敏捷已经涉及 100 人以上，有管理层、市场人员、产品、技术、运维，甚至还有 HR。

为什么我说 HR 也敏捷呢？因为我们的考核和晋级制度，也从硬指标变为以驱动自主性为主，这不就是文化敏捷的标志吗？

2020 年，为了给 Worktile 客户提供更好的服务，Worktile 8.0 正式更名为 PingCode，专注于服务研发场景的企业客户，而 Worktile 则继续服务于协作领域的企业客户。

这对于我们研发来说又是一个新的考验，但是这样的考验已经不算什么难题了。

未来的市场还会变，但是我们有足够的信心应对。我们也非常欢迎有研发管理需求的客户加入我们，敏捷没有终点，我们一起成长。

PingCode—智能化研发管理工具