头图

敏捷改造(上):真实案例研发过程分析

Woody

背景

最近我去一家科技公司做敏捷咨询,通过梳理该公司的研发过程,发现了该公司的研发过程中许多可以改进的地方,于是我便记录下来,与大家分享学习。

本文会剖析该公司的研发过程,把每个环节详细分析一遍,以找出研发过程中的问题和可以改进的地方。然后再讲解如何做敏捷改造。

研发过程分析

全景图

下图是该公司的研发全景图,从时间线来看,上面一条时间线可以看出整个需求流转的生命周期,下面一条时间线可以看出整个代码流转的生命周期。

研发过程

下面我们就把每个环节拆开来仔细分析一下。

需求管理

现状

现在是通过共享Excel来管理所有的需求,业务方在表格里面填写想要的需求,包括新需求或bug等,并为每个需求生成一个序号方便追踪。

大概长下图的样子。这是非常典型的传统需求管理方式。

需求管理

问题

  1. 大颗粒的需求可以这样管理,但是不能所有阶段都这样管理,会造成需求粒度太大,细节太多,边界太模糊。
  2. 如果不做story拆分,这样的需求离能开发还有很多空间,需要做拆分、细化、转化,最后才能开发。
  3. 这样的需求表格缺乏很多细节,比如UI长什么样子,某个业务逻辑有多少条分支等。
  4. 这样的表格无法知道业务方和研发方对需求的理解是否一致,很容易出现返工。
  5. 此类表格管理需求,不便于业务方追踪需求进度和状态,以及可视化需求的转化过程。

需求评审

现状

产品经理会和业务方一起开会,针对表格里面的某个需求,来确定这个需求的细节,以及怎么做。确保双方的理解是一致的。

问题

  1. 需求评审会的时候没有记录过程中确认的结论,导致会后大家又忘记当时的结论是什么。
  2. 由于需求粒度过大,很多细节无法详尽的确认清楚,容易导致返工。
  3. 由于需求粒度过大,需要比较长的时间来完成需求评审,通常会花2小时以上。
  4. 没有sign off,无法判定需求是否通过了业务方的认可。
  5. 需求澄清是一个随时随地的动作,但该公司缺乏能随时做需求澄清的氛围或文化。

产品设计

现状

拿到需求后,产品经理会根据需求以及和业务方的沟通,达成一致后开始设计产品文档,把需求涉及到的原型图,业务逻辑等全部画到产品文档上,以提供给开发人员进行开发。

问题

  1. 需求通常都很大,产品经理很少把需求拆分成story,也很少在JIRA等工具上拆卡建卡来管理所有的需求。导致产品设计周期很长,细节很多,无法一次性考虑全面。
  2. 产品经理设计产品文档的时候,通常是自己设计,设计好了再给业务方或者开发看。没有频繁反馈和需求澄清,导致需求可能被脑补,并不是业务方想要的。
  3. 产品文档目前是用版本管理工具来管理的,比如git,不便与查找和归档。
  4. 需求、产品文档、代码没有关联关系,不方便后期查找某个需求相关的产品文档和代码。

技术评审

现状

目前,产品经理设计完成后,会拉上开发和业务一起进行技术评审,确保设计的产品文档三方能达成一致。

问题

  1. 由于需求太大,评审时间太长,通常超过2小时,久而久之大家会越来越反感这样的评审会议,并且会议后期大家的注意力也不集中了。
  2. 细节太多,容易忽略某些细节,导致最后开发依然有不确定的开发细节,并且开发的结果和业务方的期望不匹配。

开发

现状

拿到产品文档之后,后端会根据文档中的业务逻辑,开发完成服务端的功能,前端会根据文档中的原型图或者高保真UI设计图,开发完成客户端的功能。

再来说说该公司的分支管理模式。

他们把分支分为了:线上分支(master),测试分支(stable),开发分支(dev)等。

保证不同的分支做不同的事情,防止分支污染。

  1. 线上分支(master):是预上线环境和线上环境的分支,以这个分支为准,其他分支都是以这个分支为基础拉取。
  2. 测试分支(stable):测试环境分支,是给测试团队测试使用,如果有些功能在本地及开发不容易测试,开发人员可以到测试分支进行自测。
  3. 开发分支(dev):开发人员自测。

分支命名规范:姓名+需求名+日期

分支会根据上线需要,merge到stable进行测试,或者merge到master进行上线。如下图。

分支管理

问题

  1. 分支管理混乱,每个分支既可能合并到dev,也可能合并到master,原因是因为这样可以解决仅部分功能要上线的问题,哪个功能要上线,就合并哪个分支到master。

    1. 理论上,拉了分支开发的代码都是应该要上线的,不上线的代码会浪费开发资源。
    2. 分支开发的时间也不应该太长,太长会导致代码冲突变严重,回滚成本变高。
    3. 如果是因为测试没做完而暂时不上线,那可能是因为分支所代表的功能粒度太大了,测试时间太长,应该从源头开始拆解需求。
    4. 如果是因为业务变更而暂时不上线,应该使用feature toggle来解决。
  2. 功能分支虽然写了开发者名字和需求名,但依然很难关联具体的需求是哪一个。
  3. 虽然规定了从master拉取分支,但大家有的从dev拉取,有的从stable拉取,没有统一规范。
  4. 分支命名中的日期意义不大,因为分支理论上存在的时间应该尽量短,才能避免更多的冲突,减少review的工作量,以及减少回滚的成本。其次分支拉出来的时间在git上都能清晰的看到。
  5. 开发很少做需求澄清,会按照自己的想法实现某个需求,遇到不确定的地方没有和团队讨论,没有找产品、业务确认。会导致最终实现和业务方的期望不匹配。
  6. 没有code review,无法统一开发团队成员对代码的规范,无法及时发现代码中的问题,无法做代码层面的知识传递。
  7. 没有写单元测试,无法做到研发自测与质量内建,无法保证代码的正确性,无法保证其他人不会破坏原有代码功能,无法持续集成。
  8. 没有CI/CD,无法及时获取反馈,无法快速部署,无法快速发现问题。

提交测试

现状

开发完成开发工作之后,自己测试通过了之后,会交给测试人员进行测试。测试人员在提测之前会根据产品文档先写测试用例。

问题

  1. 提测的过程靠口头传递,测试人员无法可视化的知道开发进度,做了哪些改动,可以部署哪个环境,使用哪个版本。

测试

现状

测试会根据写好的测试用例对功能进行测试,如果发现问题,会返回给开发,让开发修复。

问题

  1. 测试用例目前是用单独的工具来管理,没有和需求关联起来。
  2. 测试完成之后,没有对业务方的showcase,无法获取业务方的验收反馈。

上线

现状

每个需求基本上都包含了前后端,因此会等前后端都开发测试完成后,再一起做上线。

问题

  1. 上线内容比较多,一旦出了问题,会导致回滚成本比较高,定位问题比较慢。
  2. 上线时间比较慢,不能让业务方快速看到最终的功能。

总结

这样的研发过程梳理完了之后,会发现其实这样的过程就是我们俗称的小瀑布。它的特点是相比传统的瀑布模式它更轻量级,但相比敏捷,它又更重量级。目前很多公司都在采用这样的小瀑布模式。

  • 小瀑布模式的缺点在于它的沟通成本、等待成本、返工成本依然很高,还有可以优化的空间。
  • 同时整个过程中,需求评审、技术评审、用例评审都做得比较重,每次评审的内容都非常多,时间非常长,细节非常多。
  • 整个过程中的所有产出物并没有明确的关联关系,也没有统一的管理工具和存储位置,随着时间的推移,所有知识管理将变得越来越难,新人的学习成本将变得越来越高。软件项目中的信息量会在潜移默化中变成异常高的复杂度。
  • 环节与环节之间没有文字记录明确一个环节的结束与开始,比如开发到测试。基本上是靠成员之间的口头传递。
  • 最后还发现该公司不是全功能团队模式,而是按角色分的,一个角色可能会同时负责几个项目,比如A开发上午在写X项目的代码,下午可能在写Y项目的代码了。

根据这些现状问题,具体怎么改造,将在下篇来具体讲解。

阅读 288

Woody的专栏
Woody的专栏会记录一些技术文章,技术洞见,和好玩的技术东西。

ThoughtWorks|高级咨询师

804 声望
45 粉丝
0 条评论
你知道吗?

ThoughtWorks|高级咨询师

804 声望
45 粉丝
宣传栏