软件开发流程方法论, 2022-06-08

(2022.06.08 Wed)
完整的软件开发流程SDLC也被称为瀑布式开发waterfall，该流程随着场景的多样化需求而不停进化。本文介绍几种常见的软件开发流程方法论，以及各自擅长的场景，包括

• 瀑布式开发 waterfall
• 敏捷开发 agile and scrum 和Devops
• 迭代递增 iterative and incremental
• V型 V-shaped
• 螺旋型开发 spiral
• 快速应用开发 Rapid Application Development, RAD

瀑布式开发 waterfall

也称线性顺序开发模型linear sequential model或计划驱动型开发，它是最常见和传统的开发模式，严格遵循SDLC，逐步依次完成每一步进程，

优势包括易于理解，开发团队可以遵循清晰的开发流程、便于管理。
劣势包括

• 耗时过多：开发的各步骤按顺序执行，在前一步完成之前，下一步无法开展
• 非自适应：如果需求不明确则无法开展项目，客户需要对需求有清晰的认知和表述
• 不适合短期项目：不适合持续时间短的项目
• 缺乏灵活性：无法测试最小可用模型 MVP，直到上线才可以

适用于目标、需求、技术栈在开发周期中都相对稳定、不会产生剧烈变化的情况，适合于需要在开始前有清晰sign-offs、文档和范围饿大型项目。

敏捷开发 agile and scrum 和DevOps

相较于有严格流程的waterfall，敏捷开发更加灵活和自适应。它基于短促的开发流程(sprints)。与waterfall不同的是，开发团队不会花大量时间从头开始建立一个完整的软件产品，而是创建一个Minaimal Viable Product MVP最小可用产品，并逐步交付给客户。

采用敏捷开发的项目会被分解为更小的增量builds。每个增量build对应的周期被称为sprints。每个sprint持续时间大约2到4个星期。每个sprint之初，开发团队与客户沟通明确该sprint的目标，并进行开发测试。最终在sprint结束时交付于客户。

敏捷开发的常见变体包括scrum，extreme编程和特征驱动开发。

敏捷开发方式适合于需要持续更新的项目和产品，但管理成本和难度会相对提高。

敏捷开发聚焦于：

• 增量改进
• 用户反馈
• 2到4周为周期的sprint
• 持续测试

敏捷开发的优势包括

• 自适应：灵活，团队随时根据需求调整工作
• 提高客户满意度：与客户的沟通频率提高，便于客户在开发的每一步提供反馈
• 容易加新特性：每个开发周期为2到4周，加入新特性很方便

劣势包括：

• 经验要求高：需要团队成员或管理者有经验
• 无文档：关注软件品质胜过文档
• 需要清晰：客户需要清晰指出他们的预期，因为敏捷开发没有SDS文档

敏捷开发适用于对产品做持续更新的动态团队。由于其以用户为中心的属性，敏捷开发被众多初创公司青睐，技术公司测试新产品和对长期产品的持续更新也会应用敏捷开发。由于使得快捷发布和收集用户反馈变得容易，敏捷开发允许公司快速推进项目和测试，而免去了major release带来的潜在风险。而且每次迭代后都要测试，便于跟踪bug和版本回滚。

敏捷开发不适用于预算和时间都紧张的团队。敏捷开发的灵活性意味着项目可能轻易超出最初的时间框架和预算，与现有架构冲突，或由于管理失误而进展缓慢。此外采用敏捷开发需要对底层的过程有深入的了解，需要团队有scrum大师以保证sprint和milestone都能够达成。

DevOps是敏捷开发的扩展，它优先了持续改进与合作。与其说DevOps是一种开发方法论不如说是一种组织文化，DevOps依赖于开发流程上不同团队之间的合作。

在传统方法论中，开发者倾向于使用单一工具完成一个任务并将其传递给流水线的下一人。而DevOps开发者常使用工具链-系列工具使得他们可以与项目的stakeholder持续沟通与合作。对于需要持续和尽快更新的项目，DevOps是一个好方法但是对于过程驱动型的公司和项目来说可能会有很多问题。

迭代递增 iterative and incremental

针对waterfall开发的缺陷，迭代递增方式应运而生，该模型支持以循环迭代的方式进行开发，介于waterfall和敏捷开发之间。在迭代递增开发过程中，每次产品递增都根据反馈对MVP也就是核心功能加入新的特性。

迭代递增开发模块有不同的阶段：

• 开端 Inception：这个阶段明确需求和项目的范围
• 思考 Elaboration：根据开端的需求设计产品架构
• 建设 Construction：开发团队根据产品架构，分析、设计、实现和测试代码
• 转译 Transition：将产品推向生产环境

优势：

• 易于修改：软件可以轻易适配新的需求
• 识别风险：开发在迭代中进行，风险也可以在早期识别和解决
• bug检测：每次迭代中发现
• 易于管理：将项目分解为多个阶段，使得创建、测试和管理软件变得容易

劣势：

• 完全理解：开发团队需要对产品有足够了解并逐步建立产品

适用于有着清晰需求且不采用waterfall方法的团队。

不适用于没有长期未来技术规划的团队。该方法需要详细规划和早期的架构构建，这意味着对于仍然测试user-case的小项目或正在寻找产品与市场结合点的团队并不理想。

迭代递增与敏捷开发的对比
递增中的每次增量都构建一个完整的feature。而迭代中每次构建的是所有feature中的一小部分。

敏捷开发结合了不同方法的不同方面。在敏捷开发的sprint中，构建每个feature的一小部分，每次只开发一个，并向其中逐步添加新功能和feature。

V型 V-shaped

V型对waterfall中QA部分做了扩展，强调测试并加强测试的比重。QA一步扩展为unit testing，integration testing，system testing和acceptance testing。
适用于有严格范围和明确、静态需求的小项目。

螺旋型开发 Spiral

螺旋形开发结合了V型开发过程中的测试和迭代递增方式中的风险评估。
一旦在某个迭代周期中计划正常进行，下一步就是做深度风险分析以识别出误差和可能引起风险的领域。比如，你想出了一个未经客户验证的feature特性想要加到产品中。比起将该feature直接加到milestone中，你可以先建立一个原型prototype交给用户测试，之后再将其移动到开发周期中。每个milestone完成之后，范围像落选一样进一步扩展，根据计划执行开发并做下一次的风险评估。

适合于开发大型项目且厌倦风险的团队。该方法的核心是降低风险。如果从事大型或重要项目，在开发过程中对文档和验证的要求较高，采用该方法则合情合理。如果客户对需求不能完全确认，并且期待在开发过程中有大幅修改，这个方法也适用。

不适合于大多数人。尽管理论上听上去新奇，螺旋形开发过程很少被付诸实践，因其高昂的时间成本。相反，该法更多应用于对迭代法应用于开发的批判性思考的举例。

快速应用开发 RAD

RAD的目标是以最小代价得到产品最大化的品质。RAD以用户为中心，并依赖于用户在开发过程中提供的输入。

RAD摒弃了严格的开发流程，以最快速度开发出功能性的产品原型，并不断打磨直到可以部署到线上。

RAD只适用于小型、时间敏感型项目和有经验的团队。