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

背景

最近我去一家科技公司作敏捷咨询，经过梳理该公司的研发过程，发现了该公司的研发过程当中许多能够改进的地方，因而我便记录下来，与你们分享学习。

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

研发过程分析

全景图

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

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

需求管理

现状

如今是经过共享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项目的代码了。

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