Scrum培训总结

dowler

已于 2022-10-17 13:12:52 修改

阅读量592

点赞数 1

分类专栏： Scrum 文章标签： scrum

于 2022-10-17 11:50:57 首次发布

本文链接：https://blog.csdn.net/u011692688/article/details/127358862

版权

Scrum 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

周天，公司组织Scrum培训，对本次培训做一个总结。

1. 什么是敏捷开发？

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。是一种开发方法，也就是一种软件开发的流程，整个过各以价值为目标导向人为核心动力的一种开发流程；

1.1 敏捷的四个核心价值观

个体和互动高于流程和工具
工具很重要，但不要过分夸大工具的作用。
团队的构建，比环境的构建重要得多，合作、沟通的能力比单纯的编程能力更重要。
可工作的软件高于详尽的文档
没有文档的软件是一种灾难；但过多的文档比过少的文档更糟糕。
客户合作高于合同谈判
成功的项目需要有序、频繁的客户反馈。
不要依赖于合同或者关于工作的陈述，而要让软件的客户和开发团队密切地在一起工作，并尽量经常提供反馈
响应变化高于遵循计划
响应变化的能力常决定一个软件项目的成败。计划不能考虑过远。
较好的做计划的策略是：为下两周做详细的计划，为下三个月做初略的计划，再以后就做极为初略的计划。

1.2 敏捷宣言原则

主张简单
拥抱变化
快速反馈
高质量的工作
可用的软件

1.3 敏捷宣言

我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

2. Scrum流程

在这里插入图片描述

3. 名词解释

Scrum 是一种可以让人们将复杂的问题解决的同时保证生产率，创造性地交付最高可能价值的框架。
Kanban 可以被引入进任何开发框架去支持和推动持续性软件开发，不管你的开发模式是敏捷的(比如：XP)，还是传统的开发方式(比如：waterfall)。Work In Progress，细分的工作流程。
MVP 最小可行产品是“一个新产品的版本，它允许团队以最少的努力收集关于客户的最大验证学习量”（类似于试点实验）。
Product Backlog
定义：产品需求清单
活动：PO 输出产品需求清单，组织迭代计划会议。
Product Backlog是一个具有优先级的需求列表，并对每个需求进行了粗略的估算。内容包括未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。

Product Backlog就是一个积压的需求池，池中内容如上页所述可以是需求、BUG、优化项等。对于这个池中优先级排序、删除、添加等只有PO才有权限操作。对于池中的的需求来源不一定只是PO收集，可以是来自各个相关干系人如开发、客户、测试等。
Product Backlog形成于项目规划阶段，需求的粒度可以渐进明细进行细化，发布计划时只需要确定前面的1个或是几个Sprnit故事粒度，后面的需求可以滚动式的方式来做拆分细化。
注：Product Backlog由PO维护，但其估算是由团队来进行相关的粗略估算。

Sprint
定义：冲刺、迭代
活动：一个迭代周期，一般2 - 4周。
Sprint Planning
定义：迭代计划会议
活动：评估需求风险、优先级、复杂度，根据迭代团队规模划分每个迭代的需求清单，确定迭代各个阶段的时间点（设计、开发、测试、发版），环境资源准备（迭代分支、技术支持等）。
Sprint Backlog
定义：迭代需求清单
活动：需求分析，评估工作量、设计实现方案、拆分任务、分配需求任务，根据需求工作量的评估确定每个需求的提测时间点，让测试可以提早介入。

迭代冲刺列表是当前Sprint需要完成的用户故事，是当前的冲剌列表。冲刺列表从已排序且经过估算的Product Backlog中挑选。后续这个迭代中的所有任务拆分和跟综都以此列表为准，Sprint Backlog一但确认后续对于新的添加随不可随意更改。敏捷虽然拥抱变化但也有自身的规范，当变更添加或是减少相对的User Store时，就要减少或放入相对故事点大小的其他用户故事。

Scrum Team
定义：完整功能的交付能力的团队，开发、测试、设计。
活动：SM 负责整个团队的管理、协调及敏捷交付模式的执行。
Daily Scrum
定义：日常迭代活动，
活动：日例会，早晚可各一次，10分钟左右，跟踪迭代需求开发进度，发现、解决风险，SM 更新需求清单表、燃尽图，跟踪、协调风险。
Increment
定义：产品增量，经过一个迭代交付的产品需求增量
活动：演示，验收。
Sprint Review
定义：迭代评审会议
活动：迭代评审会议，2个小时，讨论迭代开发中的优缺点，总结、改进。
Sprint Retrospective
定义：迭代回顾会议，产品发展一个里程碑的交付
活动：迭代回顾会议，回顾多个迭代中的敏捷交付规范是否认真落实，改进建议。
Burn Down Chart（燃尽图）
燃尽图(Burn Down Chart)。是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的单项的数目。通常用于敏捷编程，下面是一个具有代表意义的燃尽图。
计划纸牌

上图可不是扑克牌，它是计划纸牌，它的作用是防止项目在开发过程中，被某些人所领导。
怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时…

4. 角色

在这里插入图片描述

Scrum Master，SM
定义：开发团队负责人
职责：负责团队管理，交付执行。

职责	诠释
1. 教练	关注每一个个体的思想和行为，并指导他们，让团队处于持续的提升，组织处于和Scrum团队真切合作的状态。
2. Scrum专家	搭建让团队合作的舞台，并提供清晰的边界。把敏捷的知识与经验传授给团队，确保团队理解并实践Scrum和其他相关的方法。
3. 推土机	推动一切阻碍开发团队工作的问题。在兼顾团队自组织能力的情况下，帮助团队解决影响团队工作进展的障碍。
4. 保护伞	保护开发团队免受外部的干扰，确保团队能集中精力完成冲刺。
5. 服务型领导	关注于团队成员的需求，以及通过实现组织的价值、原则和商业目标从而提供价值给顾客的人。

Product Owners， PO
定义：产品需求负责人
职责：负责需求录入。

职责	诠释
1. 对产品的ROI负责	ROI = profitability of the product，ROI即为产品的盈利负责，或考虑产品的投资回报率。
2. 梳理产品列表，确定产品功能	PO负责梳理产品列表，包括PBI的建立、细化、估算和排列优先级顺序。在估算期间负责澄清需求。
3. 参与规划活动，决定发布的日期和内容	PO做组合规划、产品规划、版本规划和Sprint规划的重要参与者。
4. 定义接收标准并验证工作成果	PO负责为每一个PBI定义验收标准，只有达到这些条件才确信功能需求和非功能需求已经满足。
5. 与开发团队合作	PO必须经常与开发团队保持紧密合作，每天参与到团队活动中，产品负责人与开发团队一起确定Sprint目标。
6. 与利益干系人合作	产品负责人与利益干系人一起制定产品愿景，以及确定下一个版本的内容。内部利益干系人：业务系统负责人、行政管理人员、项目管理人员等外部利益干系人：客户、用户、合作伙伴等。

Scrum Team
定义：开发成员，前端、后端、测试
职责：开发、测试。

职责	诠释
1. Sprint执行	开发团队的大部分时间都花在Sprint执行上。
2. 每日检视和调整	每个开发团队成员都应该参与每日站会，一起检验Sprint目标的进展情况，跟进当天的工作情况调整计划。
3. 梳理产品列表	每个Sprint都需要花一些时间来准备下一个Sprint，主要用来梳理产品列表，包括PBI的创建和细化、估算和排列优先级顺序。
4. Sprint规划	在Sprint计划会议（Sprint Planning Meeting）上，在ScrumMaster的引导下，开发团队和PO合作合作为下一个Sprint建立目标。
5. 检视和调整产品与过程	每个Sprint结束后，开发团队都要参加两个检视和调整的活动，即Sprint评审会议（Sprint Review Meeting）和 Sprint回顾会议（Sprint Retrospective Meeting）。评审会议上所有人一起评审当前Sprint完成的特性，并讨论下一步改进措施。回顾会议上Scrum团队检视和调整自己的Scrum过程和技术实践，进一步改善团队使用Scrum来交付业务价值的方法。