共计 2981 个字符，预计需要花费 8 分钟才能阅读完成。
背景
最近我去一家科技公司做麻利征询，通过梳理该公司的研发过程，发现了该公司的研发过程中许多能够改良的中央，于是我便记录下来，与大家分享学习。
本文会分析该公司的研发过程，把每个环节详细分析一遍，以找出研发过程中的问题和能够改良的中央。而后再解说如何做麻利革新。
研发过程剖析
全景图
下图是该公司的研发全景图，从工夫线来看，下面一条工夫线能够看出整个需要流转的生命周期，上面一条工夫线能够看出整个代码流转的生命周期。
上面咱们就把每个环节拆开来仔细分析一下。
需要治理
现状
当初是通过共享 Excel 来治理所有的需要，业务方在表格外面填写想要的需要，包含新需要或 bug 等，并为每个需要生成一个序号不便追踪。
大略长下图的样子。这是十分典型的传统需要治理形式。
问题
- 大颗粒的需要能够这样治理，然而不能所有阶段都这样治理，会造成需要粒度太大，细节太多，边界太含糊。
- 如果不做 story 拆分，这样的需要离能开发还有很多空间，须要做拆分、细化、转化，最初能力开发。
- 这样的需要表格不足很多细节，比方 UI 长什么样子，某个业务逻辑有多少条分支等。
- 这样的表格无奈晓得业务方和研发方对需要的了解是否统一，很容易呈现返工。
- 此类表格治理需要，不便于业务方追踪需要进度和状态，以及可视化需要的转化过程。
需要评审
现状
产品经理会和业务方一起散会，针对表格外面的某个需要，来确定这个需要的细节，以及怎么做。确保单方的了解是统一的。
问题
- 需要评审会的时候没有记录过程中确认的论断，导致会后大家又遗记过后的论断是什么。
- 因为需要粒度过大，很多细节无奈详尽的确认分明，容易导致返工。
- 因为需要粒度过大，须要比拟长的工夫来实现需要评审，通常会花 2 小时以上。
- 没有 sign off，无奈断定需要是否通过了业务方的认可。
- 需要廓清是一个随时随地的动作，但该公司不足能随时做需要廓清的气氛或文化。
产品设计
现状
拿到需要后，产品经理会依据需要以及和业务方的沟通，达成统一后开始设计产品文档，把需要波及到的原型图，业务逻辑等全副画到产品文档上，以提供给开发人员进行开发。
问题
- 需要通常都很大，产品经理很少把需要拆分成 story，也很少在 JIRA 等工具上拆卡建卡来治理所有的需要。导致产品设计周期很长，细节很多，无奈一次性思考全面。
- 产品经理设计产品文档的时候，通常是本人设计，设计好了再给业务方或者开发看。没有频繁反馈和需要廓清，导致需要可能被脑补，并不是业务方想要的。
- 产品文档目前是用版本管理工具来治理的，比方 git，不便与查找和归档。
- 需要、产品文档、代码没有关联关系，不不便前期查找某个需要相干的产品文档和代码。
技术评审
现状
目前，产品经理设计实现后，会拉上开发和业务一起进行技术评审，确保设计的产品文档三方能达成统一。
问题
- 因为需要太大，评审工夫太长，通常超过 2 小时，长此以往大家会越来越恶感这样的评审会议，并且会议前期大家的注意力也不集中了。
- 细节太多，容易疏忽某些细节，导致最初开发仍然有不确定的开发细节，并且开发的后果和业务方的冀望不匹配。
开发
现状
拿到产品文档之后，后端会依据文档中的业务逻辑，开发实现服务端的性能，前端会依据文档中的原型图或者高保真 UI 设计图，开发实现客户端的性能。
再来说说该公司的分支管理模式。
他们把分支分为了：线上分支（master），测试分支（stable），开发分支（dev）等。
保障不同的分支做不同的事件，避免分支净化。
- 线上分支（
master）：是预上线环境和线上环境的分支，以这个分支为准，其余分支都是以这个分支为根底拉取。 - 测试分支（
stable）：测试环境分支，是给测试团队测试应用，如果有些性能在本地及开发不容易测试，开发人员能够到测试分支进行自测。 - 开发分支（
dev）：开发人员自测。
分支命名标准：姓名 + 需要名 + 日期
分支会依据上线须要，merge 到 stable 进行测试，或者 merge 到 master 进行上线。如下图。
问题
分支管理混乱，每个分支既可能合并到 dev，也可能合并到 master，起因是因为这样能够解决仅局部性能要上线的问题，哪个性能要上线，就合并哪个分支到 master。
- 实践上，拉了分支开发的代码都是应该要上线的，不上线的代码会节约开发资源。
- 分支开发的工夫也不应该太长，太长会导致代码抵触变重大，回滚老本变高。
- 如果是因为测试没做完而临时不上线，那可能是因为分支所代表的性能粒度太大了，测试工夫太长，应该从源头开始拆解需要。
- 如果是因为业务变更而临时不上线，应该应用 feature toggle 来解决。
- 性能分支尽管写了开发者名字和需要名，但仍然很难关联具体的需要是哪一个。
- 尽管规定了从 master 拉取分支，但大家有的从 dev 拉取，有的从 stable 拉取，没有对立标准。
- 分支命名中的日期意义不大，因为分支实践上存在的工夫应该尽量短，能力防止更多的抵触，缩小 review 的工作量，以及缩小回滚的老本。其次分支拉进去的工夫在 git 上都能清晰的看到。
- 开发很少做需要廓清，会依照本人的想法实现某个需要，遇到不确定的中央没有和团队探讨，没有找产品、业务确认。会导致最终实现和业务方的冀望不匹配。
- 没有 code review，无奈对立开发团队成员对代码的标准，无奈及时发现代码中的问题，无奈做代码层面的常识传递。
- 没有写单元测试，无奈做到研发自测与品质内建，无奈保障代码的正确性，无奈保障其他人不会毁坏原有代码性能，无奈继续集成。
- 没有 CI/CD，无奈及时获取反馈，无奈疾速部署，无奈疾速发现问题。
提交测试
现状
开发实现开发工作之后，本人测试通过了之后，会交给测试人员进行测试。测试人员在提测之前会依据产品文档先写测试用例。
问题
- 提测的过程靠口头传递，测试人员无奈可视化的晓得开发进度，做了哪些改变，能够部署哪个环境，应用哪个版本。
测试
现状
测试会依据写好的测试用例对性能进行测试，如果发现问题，会返回给开发，让开发修复。
问题
- 测试用例目前是用独自的工具来治理，没有和需要关联起来。
- 测试实现之后，没有对业务方的 showcase，无奈获取业务方的验收反馈。
上线
现状
每个需要基本上都蕴含了前后端，因而会等前后端都开发测试实现后，再一起做上线。
问题
- 上线内容比拟多，一旦出了问题，会导致回滚老本比拟高，定位问题比较慢。
- 上线工夫比较慢，不能让业务方疾速看到最终的性能。
总结
这样的研发过程梳理完了之后，会发现其实这样的过程就是咱们俗称的小瀑布。它的特点是相比传统的瀑布模式它更轻量级，但相比麻利，它又更重量级。目前很多公司都在采纳这样的小瀑布模式。
- 小瀑布模式的毛病在于它的沟通老本、期待老本、返工老本仍然很高，还有能够优化的空间。
- 同时整个过程中，需要评审、技术评审、用例评审都做得比拟重，每次评审的内容都十分多，工夫十分长，细节十分多。
- 整个过程中的所有产出物并没有明确的关联关系，也没有对立的管理工具和存储地位，随着工夫的推移，所有常识治理将变得越来越难，新人的学习老本将变得越来越高。软件我的项目中的信息量会在耳濡目染中变成异样高的复杂度。
- 环节与环节之间没有文字记录明确一个环节的完结与开始，比方开发到测试。基本上是靠成员之间的口头传递。
- 最初还发现该公司不是全功能团队模式，而是按角色分的，一个角色可能会同时负责几个我的项目，比方 A 开发上午在写 X 我的项目的代码，下午可能在写 Y 我的项目的代码了。
依据这些现状问题，具体怎么革新，将在下篇来具体解说。
