一 序言

忙不完的事情，解不完的bug，每次发版都得集体熬个大通宵。干得多，结果还不好。相信绝大部分技术工作者都有过这样的困扰。今天，公司敏捷教练蔡春华以团队敏捷实践为例，与大家分享如何提升研发效率。

某研发团队处在事多、效果差的漩涡之中。在这样的背景下，公司敏捷教练团队受邀，和该研发团队一起，通过4个迭代的持续改进，研发效率和质量取得了显著提升：

  • 大幅缩短了需求开发时间，从一个月变为一周；

  • 从无可用测试环境到具有稳定的测试环境；

  • 从无自动化测试用例到50%的模块实现测试自动化；

  • 从手工部署到自动化部署。

这一切是如何做到的呢？

二 研发困境 

首先 我们了解了该团队的组织结构以及各人员的工作内容。如下图所示。

可以看到，产品、前端 、后台、测试属于不同的职能部门。这是一个非常普遍的组织形式——职能型组织。

在这样的组织形式中，通常会存在以下问题：

  • 工作之间相互依赖，彼此等待；

  • 职能团队之间的目标不一致；

  • 需求变动沟通不及时；

  • 工作完成标准不一致。

其次，集中批量集成发布，时间紧、效率低。团队的迭代周期一般是一个月，需求从准备开发到待测试的周期是4周，测试时间要花掉1天，发布一般都安排在周五晚上，大约第二天天亮才能发完，整个发布过程完全靠工程师手工完成。我们发现测试和发布的时间相对集中，时间紧，而且是完全手工操作，出错的可能性很高。

最后，测试守护薄弱，无法做到有信心发布。因为产品需要发布到公共云，目前没有相应的工具可以帮助公共云的发布；并且，产品的构建部署过程均无工具支持，需要手工打包和部署。在测试守护方面，有一些遗留的单元测试，但是这些单元测试根本就无法运行起来；而集成测试的运行的用例数基本为零，虽然有同学努力在加新的用例，但目前这些用例还无法运行，整个测试守护过程非常薄弱。

这么多的问题，该从哪里入手解决呢？下面分享一下我们的4个迭代措施。

迭代 1 ：可视化研发工作，寻找问题的关键点

通过跟团队的沟通，我们发现团队同学其实已经或多或少地意识到了这些问题，并且他们也做了一些改进的尝试，但是因为各种原因没有继续下去，导致团队现在对改变没有什么信心。

在这样的情况下，需要在尽量少改变团队现状的情况下，去取得一个比较好的效果。

要解决问题，必须让大家能够站在全局的视角来分析现状，从而找到核心问题。因此，我们通过可视化物理板以及站会，把研发团队的工作进行了可视化。

1.1 利用可视化物理板与站会，透明团队工作

初期的可视化板，主要是展现出团队当前迭代要做的工作以及每天出现的问题。过程中对物理板的规则并未做太多约束，主要起到可视化的作用。这样一方面降低了可视化工作的门槛，让大家愿意使用，另一方面，能把大家最真实的工作状况给反映出来，如下图所示：

物理板展示的同时，配置了每日固定站会，时间控制15分钟，要求产品、前端、后端开发、测试一起参与。每人轮流对所有人透明每天完成的工作、接下来要完成的工作、遇到的问题。

1.2 通过可视化物理板，暴露团队的测试瓶颈

物理板与每日站会，很清晰地展现了当前迭代需要完成的工作，团队在需要完成的目标基本上达成一致。并且在每日站会的过程中，因为每日不断需要沟通的需求，团队能及时调整并更明确研发流程规划。

同时我们发现，在项目初始阶段，几乎所有的需求在同一时期投入到了开发中；大约在中期时，有很多任务慢慢地移到了自测阶段，但并没有需求可以移到待测试阶段；直到临近发版前1-2天，大部份需求才一起移到了待测试。整个过程中，测试同学除了了解当前准备开始的工作以及准备测试用例外，一直在等待测试工作中。如下图所示。

为什么测试同学每天都在等待接受新的工作需求，但总没有需求可以提测呢？在离发版的前1天，研发才提测。对测试来说，测试时间很紧迫，验证出来的bug也来不及修，这就会造成上线后仍然需要有一周时间来修复bug。

通过可视化物理板，研发团队很快明白了测试瓶颈的原因——我们是不是可以尽快让测试参与工作呢？

迭代 2 ：合理拆分需求，让需求变小、独立、可测试

如何让测试尽快参与工作呢？我们发现，需求之所以无法进行测试，是因为需求的各个子任务与其他需求之间的子任务相互依赖造成的，多个需求之间耦合在一起，相互等待。其结果就是，所有需求都得一起开发完成才能测试。为什么它们会耦合在一起呢？

我们发现，当前的需求拆分方式是以组件或模块来进行拆分的。例如，一个需求，首先从实现的角度，把它按模块拆分成多个需求，对模块的实现，再对该模块需求拆分成若干个任务。

但是，从测试的角度来看，需求应该是端到端可测的，这样拆分出来的模块需求不能独立测试，它仅局限在这个模块的范围。

那么如何有效地来拆分需求呢？

2.1 从业务目标出发，由外而内逐步拆分需求

什么是有效的需求拆分呢？需求拆分完之后，它必须还是需求，它必须要：

  • 足够小：这样才能做到可持续交付；

  • 端到端：这样才能保证交付有意义的价值；

  • 独立性：便于持续集成和灵活安排；

  • 整体性：拆分完仍能看到整体的结构。

要做到有效的需求拆分，需要：

  1. 澄清目标：需求相关方要共同理解需求的背景，为什么要做需求的原因；

  2. 梳理需求上下文及用户的使用场景；

  3. 列出用户操作及操作步骤。

我们可以从一个具体的例子来了解整个拆分的过程。

需求描述：组件商业化

需求背景：某组件需要接入到E产品,以按量计费的形式提供服务，并通过公司统一按流量收费；组件接入到E产品后，用户通过访问产品页面开通/暂停/使用组件

如果我们按照上面描述的方法进行拆分的话，应该：

（1）澄清目标

组件要从免费的形式转变为按量计费的形式。组件要用统一的接入方式；用户在产品页面上可以看到已经接入的组件，在页面上开通/暂停组件，产生的费用，通过公司来进行计费并反馈给用户。当用户欠费时，该组件直接暂停使用，提示用户进行缴费。

（2）列出上下文及用户使用场景

系统上下文

用户使用场景（用例）

（3）列出用户操作及操作步骤

（4）按用户端到端的使用拆分为4个需求：

  • 组件成功接入到产品，能在产品上展示；

  • 用户能通过产品查看已经接入的组件；

  • 用户能使用组件功能，能根据使用数据提示已使用金额；

  • 用户如已欠费，无法使用组件功能。

其中，组件成功接入到产品需要依赖组件方技术改造，也是后续几个需求的依赖，因此这个需求为其他需求的依赖，需要最高优先级需求。

在整个拆分的过程，其实是需求从目标出发，逐层澄清分析的过程，需求拆分并不直接产生价值，产生价值的是需求分析本身，而需求拆分是需求分析的副产品。

当需求拆分完成之后，如何让需求顺畅流动起来，持续开发呢？

2.2 完善看板规则，前后职能拉通，任务左右对齐

需求除了是交付的单元，同样也是沟通的载体。在整个端到端的交付过程中，经过有效拆分的需求，可以更便捷地进行协作，与此同时，看板的设计也需要做出相应的调整。

（1）明确需求准入规则

进入开发就绪前，必须进行需求拆分，并且明确验收标准，否则不能进入开发。每个需求拆分后的工作量大小不应超过1周，对应需求的每个任务工作量不应超过1天。

（2）前后职能拉通，任务左右对齐

通过看板，呈现需求端到端的交付过程，各职能以需求顺畅流动为共同目标，从需求层面拉通各职能之间的协作。同样，在需求的开发阶段，分解成不同的任务列，同一需求的各任务被安排在同一泳道（行）上，做到任务在需求层面的对齐。如下图所示。

采用新实践的团队，需求做到了有效拆分，提前一周完成了所有需求的开发以及测试验证工作，上线后缺陷比以往显著减少。而未做改变的团队，在发布前一天，仍然有代码未合并。

合理的需求拆分，使得持续测试成为可能。现在由于测试工作变得日常化，基本上迭代开始一周后就有需求进入提测，而这时，却没有一个与线上相一致的测试环境。那么环境就成为了当前团队的一个重要瓶颈。

迭代 3 ：构建测试环境，恢复端到端持续测试

要做到持续测试，需要与之相匹配的测试环境。我们发现测试环境主要存在以下这些问题：

  • 测试环境中，服务组件之间的依赖多，准备一套环境让这些组件全部跑通不容易；

  • 某些外部依赖无法搭建线下环境；

  • 整个构建部署全由研发手动操作，缺少环境监控的有效手段；

  • 测试环境服务器部在售卖区，与公司内部不能互通访问。

问题很多，但解决的方法只有一个，即首先必须修复环境，让环境可用；其次，需要保证环境持续可用；最后，让集成测试的流程自动化，让规则自动化。

3.1 提高优先级，修复环境，让环境可用

我们发现，环境的问题并不是技术上不可行，而是在研发过程中，环境修复缺少足够的优先级，不能得到足够的投入。当环境问题已经影响到持续测试后，我们在看板中设一个泳道（下图中的青岛VIP），由测试同学把当前测试环境中的问题在这个泳道展现出来，并作为最高优先级由研发同学来修复。并且在站会时，首先去关注环境是否可用。

3.2 建立团队环境约定，保证环境持续可用

测试环境由测试同学来守护，做到有效监控、及时反馈、快速恢复（环境坏了要及时知道，知道了要及时将问题抛出来，大家进行修复）。在工具暂时还未支撑时：由开发打完包后，测试同学到固定的地方去取包进行部署，并做基础环境是否可用验证。考虑到验证的时间成本，先添加了一个端到端的用例来进行验证。待一个跑通并且持续稳定的前提下，再增加下一个用例。

部署后测试环境有问题的，测试需要判断是属于新提交代码提交导致的还是本身环境的问题，做到准确定位，新提交代码导致的，由代码合入人修复，本身环境问题指定对应人员修复。

整个环境管理的十六字规则就是：有效监控、及时反馈、准确定位、快速恢复。而这一切得到落地，一是测试的同学负责了环境的守护，二是团队有足够的优先级来响应环境的问题。

3.3 有效利用云效自定义流水线，实现构建部署测试全自动化

为了让环境持续可用，整个流程可以不再依靠人力的管控，团队决定接入公司一站式研发平台——云效来打通整个发布过程。因此，研发团队与云效团队一起，打通了从云效到售卖区的整个部署流程，形成一个从代码提交、构建、部署、测试和发布的完整流水线，该方案对后续上云的团队也可以借鉴。有了这样的测试环境和流水线，我们从新增一个完整端到端的测试用例开始，逐步完善测试自动化。

3.4 研发流程规则工具化

经过前面几个迭的改进，团队尝到了改进带来的好处，PD、测试及TL都要求其他研发团队也按照该研发模式进行协作。另外，如果其他团队仍然按照以前的模式进行工作的话，测试环境的稳定性也会难于维系，因此，整个大团队统一切换到新的研发模式中。

大团队的汇入，我们发现需要对原来的规则和模式做一些调整，才能适应大团队的运作，因此，我们将团队的研发过程规则进行了细化，补充和明确了完成标准和提测标准等。如下图所示。

研发流程并非一成不变，应该是一个不断演进调整的过程。规则调整由团队共同商议决定，尤其对于就绪、待测试、待发布几个关键状态的规则定义显得尤为重要，这是因为就绪规则是要控住入口，明确需求是否合理拆分；待测试规则是为了确定提测前是否做过自测，以保证不要一上去就把测试环境给弄趴下了；待发布是要保证发布质量。

当有了可用的测试环境之后，整个CI/CD的流水线打通，并且能够跑通30+自动化用例，该迭代准时发布，开发到测试的时间也缩短为1周。

似乎所有的问题得到了解决，但是，这个时候我们发现每一次部署都会block测试环境120分钟以上，如此长时间的block是什么原因导致的呢？有没有有效的方法可以解决？

迭代 4 ：环境稳定并持续可用

测试环境被block120min以上，影响了每一次的验证工作。针对所有block的问题进行分析，发现问题有以下几类：

  • 新提交代码产生的问题

  • 历史bug导致的

  • 测试环境本身未搭建好

  • 暂时无法判断原因的

分析原因主要是背后的理念，是先开始重要呢？还是先完成重要？我们从两方面进行了改进：

4.1 明确优先级以及需求owner意识

目标是更早的交付价值。每个需求提交应该更早的去验证、集成，再去做下一个需求。

4.2 bug的修复流程

★ 快速排查问题：

  • 测试环境问题，测试同学先做基本的排查；

  • 在云效发布工具上更多的展示发布单的反馈状态与信息，帮助排查；

★ 缺陷消灭：

  • 新Feature引入的bug,研发同学默认高优先级解决，以加速单个需求的快速流转；

  • 整理一份当前测试环境功能点的Feature列表及其对应的Owner；

  • 遗留历史bug,版本owner组织review一遍，判断影响，影响度不大，修复成本高的，产品进行排期；

★ 提前预防：

  • 提测前自动触发轻量级版本的自动化测试；

  • 代码强制codereview,代码合到测试分支的前提是自动化测试用例通过。

第四个迭代结束，测试环境已经明显不再有block的现象；团队研发流程也比较顺畅，迭代中也解决了异地站会同步问题。并且自动化测试用例已经覆盖主要核心业务。经团队评估，团队有能力在白天发布，发布熬夜已经不是团队的困扰了。

总结

通过4个迭代，研发团队达到了很多0到1的效果。从不被看好到大家都更有信心成为更高效的研发团队，最主要的原因是：大家能在同一高度来看到团队共同的问题，每次选择一个当前最迫切最重要的问题来改进，不贪多。

4个迭代后，通过数据我们来看整体的改进效果：

1.自动化测试释放人力的变化

以前每轮回归测试，需要7个开发*4小时的手动测试，通过自动化用例的添加，在回归测试人力上已经释放了2个研发人力。

2.研发周期时长明显缩短

从团队开始开发到提测从原来的4周缩短到了1周；测试的时间更充分了；限制了提测最后时间点，需求的发布时间也更充分，再没有通宵发布的情形。

3.软件质量也得到提升

从图中所示，由于需求的拆分、环境的稳定、让每个需求可以提前测试创造了有利的条件，测试时间更充分，缺陷在测试期间暴露得更多，因此遗留到线上的缺陷也就降低。

研发流程并非一成不变，应该是一个不断演进调整的过程。规则调整由团队共同商议决定，尤其对于就绪、待测试、待发布几个关键状态的规则定义显得尤为重要，这是因为就绪规则是要控住入口，明确需求是否合理拆分；待测试规则是为了确定提测前是否做过自测，以保证不要一上去就把测试环境给弄趴下了；待发布是要保证发布质量。

最后

4个迭代只是改进的开始，未来，仍然有许多的问题需要团队持续改进。但是，只要路走对了，就不怕远。

参考文献：

https://www.cnblogs.com/byvar/p/7235650.html

https://www.cnblogs.com/derekchen/p/3575428.html

https://download.csdn.net/psearch/0/10/0/2/1/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91

声明：部分图片来源于网络，相互借鉴、相互学习、共同提高

从传统技术团队职能化向敏捷迭代转变成功案例(互联网公司快速扩张阶段研发团队效率提升)相关推荐

  1. Spotify敏捷模式详解三部曲第一篇：研发团队

    本文转自:Scrum中文网 引言 2018年4月,来自北欧瑞典的音乐流媒体公司.百亿美元独角兽Spotify创造了历史,它成为了当代上市公司当中,第一家通过"直接上市"的方式在美国 ...

  2. 敏捷开发系列学习总结（13）——Spotify敏捷模式详解三部曲第一篇：研发团队

    分享一个大神的人工智能教程.零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到人工智能的队伍中来!点击浏览教程 引言 2018年4月,来自北欧瑞典的音乐流媒体公司.百亿美元独角兽Spotify创造 ...

  3. 敏捷开发系列学习总结（8）——创业公司研发团队怎么建设

    前言 小编从小就是个喜欢挑战.喜欢折腾的人.我一直认为,宁做饿死创业狼,不做养肥打工狗.小编国内某著名重点高校计算机小硕,毕业后在世界著名500强做码农.码了几年后,蕴藏于小编心底的创业激情就按捺不住 ...

  4. QCon演讲| 从团伙到团队，PingCode研发团队敏捷实践血泪史

    文章整理自PingCode基础平台部总监 徐子岩 QCon大会演讲:(大会视频及PPT文末获取) 当研发团队发展到新的规模或阶段,原有适应的开发管理模式都会面临新的瓶颈和问题,这个时候就需要去引入新的 ...

  5. 传统研发团队的敏捷转型实践之路

    在行业数字化转型加速的今天,精益敏捷.DevOps等已成为软件研发团队经常提起的热点词汇.对于软件研发而言,效率.质量是永恒的主题,提升软件研发效能的关键是要提升持续交付能力,而要构建持续交付能力,走 ...

  6. 现在才发现：敏捷迭代的好处实在太多了

    上周,公司要求我们的一号种子团队开发一个新的app,开发倒不是难事,主要是开发出来的app怎样更我们以后的更新,也方便下一个接力团队的更新.经过讨论,我们最终采用 敏捷迭代 的方式进行开发. 一.敏捷 ...

  7. 关于远程办公，微软MVP 15年研发团队的经验分享

    今天是2月5日,春节假期结束后的第三天了.为了能够应对来势汹汹的疫情,众多互联网企业纷纷开启了远程办公模式.不知道各团队前两天的远程办公效果如何,我们 Worktile 管理层在大年初四就开始讨论远程 ...

  8. 如何打造高绩效的研发团队

    作者介绍:王建志,汉诺云创教育科技有限公司CEO.近20年IT企业工作经验,曾在华为.支付宝.链家.好大夫在线,Sybase等多家企业担任架构师.CTO.CEO等职位.熟悉汽车新零售.在线医疗.房产. ...

  9. Spotify敏捷模式详解三部曲第二篇：研发过程

    本文转自:Scrum 中文网 引言 在本系列文章的第一篇,我们介绍了Spotify的敏捷研发团队,以及它独特的组织架构.Spotify的研发团队采用的是一种非常独特的组织架构,如下图所示: 整个研发组 ...

最新文章

  1. 《OpenCV3编程入门》学习笔记4 OpenCV数据结构与基本绘图
  2. Codeforces 1188
  3. 教科书上的LDA为什么长这样？
  4. boost::mp11::mp_transform_front相关用法的测试程序
  5. 速度提升一倍，无需实例掩码预测即可实现全景分割
  6. centos elasticsearch7 安装_SkyWalking学习笔记(CentOS环境)
  7. CentOS 6升级默认python版本
  8. MATLAB gui 绘图设置
  9. 关于Redis的概念
  10. 生成模型应用——使用变分自编码器（VAE）控制人脸属性生成人脸图片
  11. 学习笔记(8)之VelocityTracker
  12. android用讯飞实现TTS语音合成 实现中文版
  13. 关键词文章生成器-智能关键词文章生成器
  14. Java期末复习速成（一）
  15. 爬虫 Scrapy 学习：Spiders
  16. php学习笔记：登录练习（3）
  17. 【渝粤题库】国家开放大学2021春1253C语言程序设计答案
  18. python爬虫用到的技术_python爬虫技术的选择
  19. java如何调用驱动程序_使用Java驱动程序查找和上载
  20. ZLib的数据压缩和解压缩

热门文章

  1. Android-PopupMenu弹出式菜单的基本使用
  2. Java 位运算系列之通过位运算操作状态
  3. 浅谈用delphi来编写蠕虫病毒
  4. 在MacBook 13“机器上无法安装Boot Camp x64驱动程序问题的处理
  5. EasyX教程（一）续：画十字
  6. linux桌面环境哪个好,你应该选择哪一个Linux桌面环境？
  7. spring 定时器 表达式 org.springframework.scheduling.quartz.CronTriggerBean
  8. offbye的Dottext 1.0 Beta 2汉化美化版发布了！欢迎下载
  9. Jt808协议头部包解析
  10. strcmp的返回值 Linux与Windows下区别 源代码实现区别