ITPub博客

首页 > 应用开发 > IT综合 > 实战规模化敏捷:从8人到百人的敏捷之路

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

原创 IT综合 作者:DevOps订阅号 时间:2021-03-15 09:06:33 0 删除 编辑


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

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

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31558019/viewspace-2762788/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-10-12

  • 博文量
    64
  • 访问量
    46986