实战规模化敏捷：从8人到百人的敏捷之路

内容来源：孙敬云作者：孙敬云拓展阅读：【研发管理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则继续服务于协作领域的企业客户。这对于我们研发来说又是一个新的考验，但是这样的考验已经不算什么难题了。未来的市场还会变，但是我们有足够的信心应对。