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

PingCode

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

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

image.png

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

image.png

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

image.png

第一步:Scrum团队启动会

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

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

image.png

第二步:先跑一个Sprint

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

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

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

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

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

image.png

第三步:两周一次,不断的改进

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

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

  • 前后端共同完成的用户故事预估起来往往偏差较大
  • 移动端小伙伴想要的API经常排不上号
  • 突发的紧急任务(来自老板)打乱Sprint的计划
  • 每天的站立会议阶段性的流于形式 ……数不胜数

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

image.png

我们在变,市场也在变,市场变了,我们也要跟着变。大概在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的开发,我们慢慢的找到了感觉,下图是我总结的经验:

image.png

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

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

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

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

image.png

1、市场调研和需求评估

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

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

image.png

2、业务线的敏捷

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

image.png

3、验证需求和后续行动

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

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

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

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

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

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

image.png

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

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

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

Worktile—一个工具满足工作所需

阅读 514

PingCode 是简单易用的新一代研发管理平台,让研发管理自动化、数据化、智能化,帮助企业提升研发效能。

2.5k 声望
2k 粉丝
0 条评论
你知道吗?

PingCode 是简单易用的新一代研发管理平台,让研发管理自动化、数据化、智能化,帮助企业提升研发效能。

2.5k 声望
2k 粉丝
宣传栏