敏捷及Scrum简介

最新推荐文章于 2024-01-28 19:23:40 发布

律风无外

最新推荐文章于 2024-01-28 19:23:40 发布

阅读量754

点赞数

分类专栏：软件工程文章标签：敏捷方法软件工程 Scrum

本文链接：https://blog.csdn.net/yg_hou/article/details/85341050

版权

软件工程专栏收录该内容

5 篇文章 0 订阅

订阅专栏

1. 瀑布模型

本篇博客打算向大家介绍SCRUM，SCRUM是敏捷方法中最流行的一种。谈到敏捷方法，就不得不提它的对立面，即严格软件过程。敏捷方法的提出，一定是为了解决严格软件过程中存在的局限性，那么这个局限性是什么呢？

1.1 提出

Winston W. Royce 在在1970年IEEE WestCom软件工程会议中，首次提出了著名的传统瀑布方法。颇具讽刺意味的是，Royce之所以提出这个模型，就是要拿它当靶子说明不能这样做软件开发。

1.2 定义

瀑布模型将开发和交付企业软件项目的流程分割为相互独立的阶段：需求收集->设计->编码->测试。在瀑布流程中，每一步骤都必须等待前一步骤结束后才能继续，也只能在所有步骤都结束后才有可能向用户交付价值。

1.3 局限性

支持瀑布模型的人认为，在开始实现之前先进行“完美化”（perfecting）设计，能够早点捕获错误和缺陷，从而降低项目全过程成本。然而事实上，完美化太不现实了，软件产品是复杂系统而不是静态物件，不能像设计汽车一样设计软件。

2. 敏捷方法

2001年，17位超级极客齐聚犹他州的雪鸟滑雪山庄，共同探索有关软件开发未来发展的共同理念。与会者将此次运动命名为敏捷，并草拟出一份言简意赅的敏捷宣言。

2.1 敏捷宣言

敏捷价值观
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
相应变化高于遵循计划

2.2 迭代式开发

所有种类的敏捷流程都有一个共同点：他们拥抱变化，视变化为成长的良机，而非障碍。简单的看，瀑布方法只有在完成当前步骤后才能头也不回地迈向下一步骤。而敏捷方法会一点点地完成各步骤，周而复始，工作过程中不断改善、调整。

迭代方法实践：

边做边测试
及早且频繁的地交付产品
文档边做编写
构建跨职能团队

3. SCRUM

3.1 历史

1995年，在奥斯汀举办的OOPSLA’95上，Sutherland和Schwaber联合发表了论文首次提出Scrum概念。

大多数Scrum实践者认定Ken Schwaber的早期版本就是Scrum的事实标准.
没有人拥有Scrum，没有Scrum的标准。

3.2 定义

Scrum不是不是构建产品的一种过程或一项技术，而是一个框架，在这个框架里可以应用各种流程和技术。Scrum可使产品管理和开发实践的相对功效显现出来，以便随时改进。

3.3 理论基础

Scrum 基于经验过程控制理论，或称之为经验主义。经验主义主张知识源自实际经验以及当前已知情况下做出的决定所获得。Scrum 采纳一种迭代和增量式的方法来优化对未来的预测和控制风险。

透明、检视和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。

透明

过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一的标准。通俗的说，scrum过程应被团队成员所理解，并且没有模糊定义的地方。
2. 检视

Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要的差异。（Scrum工件、Sprint目标在后面介绍）。

适应

如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。也就是发现问题后调整的过程，这正是瀑布方法所不具备的。

4. 三个角色

产品负责人

产品负责人的职责是将开发团队开发的产品价值最大化，并且他/她是管理产品待办事项列表的唯一负责人。产品待办列表的管理包括：

清晰地表述产品待办列表项；
对产品待办列表项进行排序，使其最好地实现目标和使命；
优化开发团队所执行工作的价值；
确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；
以及确保开发团队对产品待办列表项有足够深的了解。

Scrum Master

Scrum负责确保Scrum被理解并实施，通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。

Scrum Master 以各种方式服务于开发团队，包括：

作为教练在自组织和跨职能方面给予开发团队以指导；
帮助开发团队创造高价值的产品；
移除开发团队工作进展中的障碍；
按被请求或需要时，引导 Scrum 事件；以及，
在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。

开发团队

开发团队包含各种专业人员，负责在每个 Sprint结束时交付潜在可发布并且“完成”的产品增量。

自组织团队 and 全功能团队

自组织团队选择如何最好地完成他们的工作，而不是由团队外的其他人来指示他们。

全功能团队拥有完成工作所需的全部技能，不需要依赖团队外部的人。

5. 三个工件

Scrum 的工件以不同的方式表现工作任务和价值，可以用来提供透明以及检视和适应的机会。Scrum 所定义的工件是特别地设计的，是为了给关键信息提供最大透明化，因此每个人对工件都需要有相同的理解。

产品待办事项（Product Backlog）

产品待办列表是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。

产品待办列表永远是不完整的。最早开发的产品待办列表列举最初所知的以及理解最透彻的需求。产品待办列表会随着产品及其应用环境的改变而演进。
产品待办列表是动态的，需要持续更新以反映出产品需要什么来保持其适用性、竞争力和有用。如果产品存在，产品待办列表也就同样存在。

Sprint待办事项

Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测。

可交付产品增量

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。

6. 五个事件

冲刺（Sprint）

Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。

Sprint 计划会议

Sprint 中要做的工作在 Sprint 计划会议中来做计划。这份工作计划是由整个 Scrum 团队共同协作完成的。

计划会议中讨论以下两个话题：

这次 Sprint 能做什么？
如何完成所选的工作？

每日站会

每日 Scrum 站会在 Sprint 的每一天都举行。在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制定计划。

Sprint 评审会议

Sprint 评审会议在 Sprint 快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表。在 Sprint 评审会议中，Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。