本文转载自微信公众号“问吧”，作者陈绍文。转载请联系公众号。1、什么是敏捷开发？在传统的软件研发模式中，从提出需求到最终交付的时间周期比较长。瀑布模型遵循六个步骤：需求分析、设计、编码、集成、测试和维护。一旦需求发生变化，不仅浪费了前期投资，而且也不易调整。敏捷开发是一种对快速变化的需求做出响应的软件开发能力。尤其是互联网软件，最初的设计不可能是完美的。在研发过程中，会不断调整和优化。敏捷开发是面向交付和协作的。与提倡完美的设计、文档和流程规范相比，敏捷开发更强调持续交付，让目标更早被接受，缺陷更早暴露。在实践中，我们需要保持1-2周的迭代周期。迭代周期过长，进度评估通常不准确，容易导致延迟。同时，较长的迭代周期意味着复杂的功能。一次一个迭代地在主要版本中引入并发症不是一个好主意。通过功能拆分，可以有效降低问题的复杂度，提高软件质量。另一方面，需求方、设计方、开发方也需要跟上进度。1-2周的迭代提供了一个短期目标，不能具体到日常工作内容。建议负责人每天组织一次立早会，相关人员可以花2分钟汇报进度，反馈遇到的问题。会议结束后，主要负责人将统一协商解决问题，使项目继续推进。针对快速迭代和持续交付的特点，我们需要找到合适的分支开发模式。如果是几个人的项目组，我推荐主干整合，分支发布的开发模式。版本管理软件推荐使用Git。如果你使用SVN，建议切换到Git。这里有一篇博客，可以参考：从GitLab推送代码到SVN仓库[1]。2.特性开发，主干整合，分支发布特性开发是指每一个小功能创建一个新的特性分支进行开发。基于特征的开发可以保证每个特征的独立性，允许特征并行开发。同时，未完成的功能不会影响主分支。主干集成就是把代码尽早合并到主分支上，在主分支上进行持续集成。假设每次迭代有N个特征，如果这些特征在同一天合并到trunk分支，交叉验证这些特征是否符合预期所需的工作量是N^2级。但是，如果这些功能开发完成并自测，会立即启动MR/PR流程，并合并到主分支中。N个特征，合并成本下降到N个级别。尽早发起合并请求，并能够尽快将您的更改通知其他开发人员。在开发过程中，其他开发人员可以解决大部分冲突。分支发布是指每次发布都会创建一个新的分支，而不是发布主分支。假设现在需要2.1版本。首先，在主分支的基础上，创建发布分支2.1，在2.1分支上进行测试，缺陷返回主分支。验收通过后，在2.1分支上打上2.1.0标签，对外发布。发布后，如果Tag2.1.0版本存在缺陷，需要在2.1分支修复，然后将缺陷返回主分支，标记Tag2.1.1，继续发布版本.分支发布的好处是可以追溯发布的版本，让开发者修复发布的版本，持续发布。另一方面，发布分支不会影响新功能的开发，也不会受到主干集成的干扰。3、测试决定敏捷开发的速度。没有质量的交付是没有价值的。在敏捷开发过程中，测试是持续集成的重要环节。测试不仅是一个目标，驱使开发人员去实现它，而且是交付的证明和对项目质量的认可。测试应融入研发过程，贯穿整个项目过程。单元测试、API测试、集成测试、功能测试，不同的测试阶段可以发现不同粒度的问题。在实践中，我们鼓励向左移动测试。参考测试金字塔，尽可能多地编写单元测试以获得更好的结果。在团队中，测试/开发比率通常很低。开发人员编写单元测试，测试人员进行集成测试和功能测试更合理。在MR/PR过程中，加入CI流水线，自动执行测试用例，辅助验证功能，也是一种事半功倍的做法。参考[1]从GitLab推送代码到SVN仓库：https://www.chenshaowen.com/blog/some-common-scripts-in-ci.html#3-Pushcodefrom-GitLab-to-SVN-warehouse
