Scrum 敏捷开发

流光D

已于 2023-10-18 15:10:48 修改

阅读量8.6k 项目管理文章标签： scrum 敏捷流程产品运营软件工程敏捷开发

于 2023-01-17 15:48:15 首次发布

本文链接：https://blog.csdn.net/a715167986/article/details/128716292

项目管理专栏收录该内容

1 篇文章 2 订阅

敏捷开发是一个术语，用于描述迭代软件开发。迭代软件开发通过在短增量完成工作（通常称为冲刺， Sprint）来缩短 DevOps 生命周期。冲刺通常长达一到四周。敏捷开发通常与传统或瀑布式开发形成鲜明对比，后者会提前规划大型项目，并根据计划完成它们。

每次冲刺交付生产质量代码都需要敏捷开发团队来加快速度。所有的编码、测试和质量验证都必须在每一次冲刺 (sprint) 中完成。除非团队已正确设置，否则结果可能低于预期。虽然这些失望提供了很好的学习机会，但开始之前，学习一些关键教训会很有帮助。

区别于传统的瀑布开发模型，敏捷开发是一种几乎万能地适合现代化软件开发（也包括其他工业项目开发）的一种工作流程/方法论。

https://coding.net/help/docs/collaboration/pattern-choice.html

业界普遍认为瀑布模型是由温斯顿·罗伊斯（Winston Royce）于 1970 年提出的。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，以便于协作。瀑布模型将软件生命周期分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

另外，瀑布模型非常强调文档，前一个阶段的输出就是下一个阶段的输入，文档是各阶段衔接的唯一信息。从瀑布模型角度出发，在设计和记录不充分的情况下，如果团队成员在项目完成之前离开，知识就会丢失，项目可能很难从损失中恢复过来。如果存在可以正常使用的设计文档，新团队成员甚至是全新团队都应该能够通过阅读文档来接手项目。

在这里插入图片描述

瀑布模型指的是在软件开发过程中，由项目管理人员（项目经理）将开发流程分解为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，在每个活动周期，项目人员依具体需求输出对应的文档/代码文件等内容。瀑布模型非常强调文档的全面具体，因为上一个活动流程的输出 文档/产品 会作为下一个活动流程的输入。文档是各阶段衔接的唯一信息。

其实 Royce 最早提出这个模型时，并不是为了力挺瀑布。恰恰相反，他指出了瀑布模型可能会存在较大风险，因为在面对经常变化需求的项目时，瀑布模型毫无价值。但也许意外往往也暗含着某种必然性，瀑布模型提供了一种结构化、易于理解的阶段线性流程；它还在开发过程中提供了易于识别的里程碑。由于这个原因，瀑布模型被用作许多软件工程课本和课程中开发模型的开始示例。截止目前它依然是软件开发企业使用的重要开发模型之一，瀑布模型可适用于要求和范围固定的产品，产品本身牢固稳定且技术易于理解的项目。

Royce 真正提出的是改良版瀑布模型，他将原型设计放到了和瀑布模型并重的地位，而这个原型设计就类似于敏捷当中的一次迭代，通过一次迭代来验证项目的可执行性，从而降低风险。接下来我们来看看迭代思想是如何在 Scrum 当中被深刻使用的。

使用瀑布模型开发存在一些缺点，尤其是面对经常变更需求的项目时更是如此。改良版的瀑布模型更加适用于实际的项目开发中，它的特点是将原型设计放到了和瀑布模型并重的地位，而这个原型设计就类似于敏捷开发当中的一次迭代。

检测结果

得分 0～20，我们更加推荐使用经典模式；

得分 30～50，我们更加推荐使用敏捷模式。

以上来自 CODING 官方文档的选择方法建议，但是这里笔者认为，评价一个项目能否使用敏捷开发并不需要参考类似需求稳定性、环境开放度等因素，笔者认为基于 Scrum 敏捷开放进行的项目管理方式适合于 90% 以上的软件项目开发。因为相比传统的项目管理方式（或者未使用任何项目管理方式），Scrum 有很多不可替代的优点：

及时反馈的各种会议，比如每次一个 Sprint 结束后召开的 Sprint 回顾会议，团队每个成员都可以提出自己在上个 Sprint 参与过程中的感悟，提炼总结出各种优缺点反馈于团队
保证代码质量。Code Review (代码评审) 不是 Scrum 敏捷开发的特色，任何软件开发团队都可以定时作 Code Review, 但在 Scrum 敏捷开放中，尤其是项目伊始，团队的每个研发人员都应该就自己开发的相关功能（一般是比较复杂，有代表性的功能）作 Code Review，一般来说，在项目开发前期的每个 Sprint 中，团队的每名开发人员都应该发起不少于一次的 Code Review。这个次数可在项目进入中后期后相应减少。定时定量的 Code Review，可极大提高团队总体的编码质量，提升团队成员的研发水平和经验。
让每个团队成员都有参与感，不至边缘化任何成员。这也是在软件项目开发中常见的一个问题，尤其是在规模稍大的团队中更可能发生，团队的少部分成员因为参与度、经验水平的不足等常常在团队推进项目中被边际化，可能其他成员的任务繁重，忙不过来，但是少部分成员无所事事。而 Scrum 敏捷开发在一定程度上可以较好的缓解此类问题，比如每个 Sprint 启动会议上，团队所有成员都会到场进行讨论，包括各个需求任务的拆分，以及对应人物的故事点，每个任务故事点的赋予是需要团队所有成员表决的。这些都可以让所有成员动起来，参与起来。