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

拓展阅读：【研发管理101军规001】 两周迭代，形成团队持续习惯 | IDCF

【研发管理101军规002】特种部队——更符合不确定业务的组织架构设计 | IDCF

如果用一句话概述本篇的主题，那就是：关注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）市场调研和需求评估

• 调研包括但不限于：行业动态、竞品分析、客户反馈等
• 需求评估由市场、产品、技术等相关方的负责人参与

2）业务线的敏捷

• 按季度或月确定研发目标
• 由技术负责人、架构师评估，由产品总负责人拆分为产品特性
• 由产品总负责人和各个产品负责人拆分特性
• 由技术、架构师、产品确定各个特性的规模和完成周期
• 将拆分后的用户故事放入各个Scrum团队的PBI中，设置优先级
• 各个Scrum团队计划各自的Sprint工作
• 各个Scrum团队代表每周同步各自的工作进展
• 按期进行各个模块、子产品的集成，部署到UAT环境
• 按期完成目标

3）验证需求和后续行动

• 进行必要的数据收集，例如重要页面的QPS，转化率等等
• 进行数据分析
• 确定后续的产品改动方向

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

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

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

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

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

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

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

未来的市场还会变，但是我们有足够的信心应对。

内容来源：孙敬云
作者：孙敬云