研发流程在敏捷开发中的详解

在传统的软件研发模型中，从提出需求到最后交付，时间周期较长。瀑布模型遵循需求分析、设计、编码、集成、测试、维护六个步骤进行。一旦需求发生变化，不仅浪费前期投入，还不易于调整。

敏捷开发是一种应对快速变化的需求的软件开发能力。特别是互联网软件，前期设计不可能十分完美，在研发的过程中，会不断地调整、优化。

敏捷开发是面向交付、面向协作的。相较于主张完善的设计、文档、流程规范，敏捷开发强调的是持续交付，让目标更早得到验收，让缺陷更早暴露。

在实践过程中，我们需要保持 1-2 周的迭代周期。过长的迭代周期，排期评估通常是不准确的，容易导致延期。同时，较长的迭代周期，意味着复杂的功能。一次迭代将复杂功能引入主版本，不是一个好主意。通过拆分功能，能有效降低问题的复杂度，提高软件质量。

另一方面，需求方、设计方、开发方还需要时刻了解进度。1-2 周的迭代，提供的是一个短期的目标，无法具体到每天的工作内容。建议，负责人每天能组织一次站立晨会，相关人员能花 2 分钟汇报进度，反馈遇到的问题。会后，主要负责人，统一协商解决问题，以保持项目推进。

针对这种快速迭代、持续交付的特点，我们需要寻找合适的分支开发模型。如果是几个人的项目团队，我推荐的是主干集成、分支发布的开发模式。版本管理软件推荐使用 Git，如果使用 SVN，建议转向 Git。这里有一篇博客，可以参考：从 GitLab 推送代码到 SVN 仓库[1]。

• 特征开发，就是每个小的功能，都新建一个特征分支进行开发。基于特征开发，能够保障各个特征的独立性，允许并行开发特征。同时，未完成的特征，也不会影响主干分支。

• 主干集成，就是尽可能早地将代码合并到主分支上，在主分支上进行持续集成。

假设每个迭代有 N 个功能，如果这些功能在同一天被合并到主干分支，交叉验证这些功能是否符合预期，需要的工作量是 N ^ 2 级别。但是，如果这些功能，开发自测完毕后，立即发起 MR/PR 流程，合并到主干分支。N 个功能，合并成本会下降到 N 级别。

尽可能早地发起合并请求，能将自己的修改，尽快地告知其他开发者。在开发过程中，其他开发者，就能解决大部分的冲突。

• 分支发布，就是每次发布都新建一个分支，而不是发布主干分支。

假设现在需要发行 2.1 版本。首先，基于主干分支，创建发布分支 2.1，在 2.1 分支上进行测试，并将缺陷回归到主干分支。验收通过之后，在 2.1 分支上打上 Tag 2.1.0，对外进行发布。

发布之后，如果 Tag 2.1.0 版本有缺陷，需要在 2.1 分支上进行修复，然后回归缺陷到主干分支，打上 Tag 2.1.1，继续发行版本。

分支发布的好处，就是让发布的版本可以追溯，允许开发者对发行版本进行修复，持续发布。另一方面，发布分支不会影响新特性的开发，也不会被主干集成干扰。

没有质量的交付是没有价值的。

敏捷开发过程中，测试是持续集成中的重要环节。测试既是目标，驱动开发人员去达成，也是交付的凭证，是给项目质量的背书。

测试应该整合到研发流程，贯穿整个项目过程。单元测试，API 测试，集成测试，功能测试，不同的测试阶段可以发现着不同粒度的问题。

在实践过程中，我们鼓励将测试左移。参照测试金字塔，尽可能多地写单元测试，能够获得较好的效果。在团队中，测试/开发比通常很低。由开发人员写单元测试，测试人员进行集成测试、功能测试比较合理。

在 MR/PR 流程中，添加 CI 流水线，自动执行测试用例，辅助验证功能，也是事半功倍的实践。

[1]从 GitLab 推送代码到 SVN 仓库: https://www.chenshaowen.com/blog/some-common-scripts-in-ci.html#3-从-GitLab-推送代码到-SVN-仓库