敏捷改造（上）：真实案例研发过程分析

背景

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

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

研发过程分析

全景图

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

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

需求管理

现状

现在是通过共享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项目的代码了。

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