敏捷开发之研发流程-创站工坊

敏捷开发之研发流程

发布时间：2025-11-05 02:40:37 来源：创站工坊作者：系统运维

本文转载自微信公众号「问其」，敏捷作者陈少文。发流转载本文请联系问其公众号。敏捷

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

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

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

在实践过程中，我们需要保持 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-仓库

随便看看