目录

    1. 敏捷开发是什么

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

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

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

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

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

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

    2. 特征开发,主干集成,分支发布

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

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

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

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

    1. 分支发布,就是每次发布都新建一个分支,而不是发布主干分支。

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

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

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

    3. 测试决定了敏捷开发的速度

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

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

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

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

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