内容简介:在传统的软件研发模型中,从提出需求到最后交付,时间周期较长。瀑布模型遵循需求分析、设计、编码、集成、测试、维护六个步骤进行。一旦需求发生变化,不仅浪费前期投入,还不易于调整。敏捷开发是一种应对快速变化的需求的软件开发能力。特别是互联网软件,前期设计不可能十分完美,在研发的过程中,会不断地调整、优化。敏捷开发是面向交付、面向协作的。相较于主张完善的设计、文档、流程规范,敏捷开发强调的是持续交付,让目标更早得到验收,让缺陷更早暴露。
在传统的软件研发模型中,从提出需求到最后交付,时间周期较长。瀑布模型遵循需求分析、设计、编码、集成、测试、维护六个步骤进行。一旦需求发生变化,不仅浪费前期投入,还不易于调整。
敏捷开发是一种应对快速变化的需求的软件开发能力。特别是互联网软件,前期设计不可能十分完美,在研发的过程中,会不断地调整、优化。
敏捷开发是面向交付、面向协作的。相较于主张完善的设计、文档、流程规范,敏捷开发强调的是持续交付,让目标更早得到验收,让缺陷更早暴露。
在实践过程中,我们需要保持 1-2 周的迭代周期。过长的迭代周期,排期评估通常是不准确的,容易导致延期。同时,较长的迭代周期,意味着复杂的功能。一次迭代将复杂功能引入主版本,不是一个好主意。通过拆分功能,能有效降低问题的复杂度,提高软件质量。
另一方面,需求方、设计方、开发方还需要时刻了解进度。1-2 周的迭代,提供的是一个短期的目标,无法具体到每天的工作内容。建议,负责人每天能组织一次站立晨会,相关人员能花 2 分钟汇报进度,反馈遇到的问题。会后,主要负责人,统一协商解决问题,以保持项目推进。
针对这种快速迭代、持续交付的特点,我们需要寻找合适的分支开发模型。如果是几个人的项目团队,我推荐的是主干集成、分支发布的开发模式。版本管理软件推荐使用 Git,如果使用 SVN,建议转向 Git。这里有一篇博客,可以参考: 从 GitLab 推送代码到 SVN 仓库 。
2. 特征开发,主干集成,分支发布
- 特征开发,就是每个小的功能,都新建一个特征分支进行开发。基于特征开发,能够保障各个特征的独立性,允许并行开发特征。同时,未完成的特征,也不会影响主干分支。
- 主干集成,就是尽可能早地将代码合并到主分支上,在主分支上进行持续集成。
假设每个迭代有 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,继续发行版本。
分支发布的好处,就是让发布的版本可以追溯,允许开发者对发行版本进行修复,持续发布。另一方面,发布分支不会影响新特性的开发,也不会被主干集成干扰。
3. 测试决定了敏捷开发的速度
没有质量的交付是没有价值的。
敏捷开发过程中,测试是持续集成中的重要环节。测试既是目标,驱动开发人员去达成,也是交付的凭证,是给项目质量的背书。
测试应该整合到研发流程,贯穿整个项目过程。单元测试,API 测试,集成测试,功能测试,不同的测试阶段可以发现着不同粒度的问题。
在实践过程中,我们鼓励将测试左移。参照测试金字塔,尽可能多地写单元测试,能够获得较好的效果。在团队中,测试/开发比通常很低。由开发人员写单元测试,测试人员进行集成测试、功能测试比较合理。
在 MR/PR 流程中,添加 CI 流水线,自动执行测试用例,辅助验证功能,也是事半功倍的实践。
以上所述就是小编给大家介绍的《敏捷开发之研发流程》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。