(13.2.1)Scrum敏捷开发框架

    • Scrum角色
    • Scrum基本工件
    • Scrum活动或会议
      • 1 产品待办事项列表梳理
      • 2 Sprint计划会议
      • 3 每日Scrum会议
      • 4 Sprint评审
      • 5 Sprint回顾
    • 敏捷宣言的价值观
    • Scrum的价值观

Scrum是最著名的敏捷框架。它是敏捷宣言的价值观和原则背后的重要思想源泉,⽽这些价值观和原则也是所有敏捷⽅法的基础

Scrum是一个用于打造产品的框架,一个团队流程。当利益干系人需要一个产品时, Scrum就启动了

Scrum要求在团队和利益干系⼈之间保持信息透明。因此, Scrum团队会把当前的计划和进度可视化

1. Scrum角色

Scrum团队包括三个角色

  • 产品负责人:决定要做什么
    • 由1个人来担任,他负责在限定期限内拟定可能的最有价值的产品
    • 产品负责人可能需要其他人的支持,但他只能是1个人
    • 产品负责维护产品待办事项列表( Product Backlog),并确保大家都知道包括的内容以及优先级
    • 产品负责人通常是离项目的“业务层”最近的人,一般由组织指派来负责“把这个产品做出来”,而且通常期望他以最好的工作成果来满足所有的利益干系人
    • 产品负责人通过选择开发团队下一步应该做什么以及要推迟什么,来权衡范围和进度,以得到尽可能好的产品

并不是所有的事情都由产品负责人1个人负责。整个Scrum团队需要让团队变得尽可能的高效,改善他们的实践、提出正确的问题、帮助产品负责人等等。
开发团队决定1个Sprint要做多少事情,并负责每个Sprint产出可用的产品增量。

  • 开发团队成员:通过一系列称为Sprint的短时间周期以增量式打造产品
    • 开发团队是由实现产品增量的专业成员组成,他们采用自组织的方式完成工作。对于项目而言,开发团队的成员是全职的
    • 开发团队成员需要以自组织的方式实现Sprint目标,根据Sprint的计划完成产品增量
    • 开发团队成员共同预测在1个Sprint能完成的工作量,并决定如何实现 (产品负责人准备1个有序的代办事项列表)

Sprint是一个固定的时间周期,长度可以是1周到四周,但越短越好。在每个Sprint中,Scrum团队会开发并交付1个产品增量
每个增量是1个可识别的,对产品功能有明显提升的,可操作的功能子集,符合明确的接受条件,并且质量标准达到了“完成的定义”

  • ScrumMaster:一个仆人型领导,帮助团队和组织来让Scrum发挥最大效用
    • 作为Scrum团队的教练,帮助Scrum团队遵守他们的流程
    • 帮助产品负责⼈理解如何创建和维护产品待办事项列表( Product Backlog)
    • 和开发团队一起发现并实施技术实践,确保团队在Sprint结束时能够完成工作
    • 注意团队前进的障碍已被清除
    • ScrumMaster培养团队的自组织能力。团队应该尽可能地独立解决问题
    • 确保团队内部和外部人员对Scrum有充分的理解,并保证Scrum被恰当地使用。
    • 帮助团队之外的人理解流程,并明确和团队的哪些交互是有益的,哪些不是。
    • ScrumMaster帮助每个人改进,使团队更加高效和有价值

2. Scrum基本工件

Scrum包括三个基本的工件

  • 产品待办事项列表( Product Backlog):1个有关产品想法的有序列表,这些想法将按照其期望被实现的顺序排列

    • 它是所有需求的唯1来源。这意味着开发团队的所有工作都来自产品待办事项列表
    • 每个产品待办事项都包括描述和估算
    • 开始阶段它比较短小而模糊,随着时间的推移,逐渐变长,越来越明确
    • 通过《产品待办事项列表梳理活动》,即将被实现的产品待办事项会得到澄清,变得明确,粒度也拆得更细
    • 由产品负责人维护
    • 可能来自于产品负责人,团队成员,或者其它利益干系人
  • Sprint待办事项列表( Sprint Backlog):下个Sprint的详细开发计划

    • 一个需要在当前Sprint完成的且梳理过的产品待办事项,并包括了一个团队完成这些工作的计划
    • 反映了团队对当前Sprint⾥需要完成工作的预测
    • 有了Sprint待办事项列表后, Sprint就开始了,开发团队成员按照Sprint待办事项列表来开发新的产品增量
  • 产品增量:每个Sprint的必要产出。它是个集成好的产品版本,具备足够好的质量并在产品负责人需要时被交付出去

    • 每个Sprint都应该有新的产品增量。
    • 它的质量好到可以随时交付给客户。
    • 产品增量必须符合Scrum团队当前的“完成的定义”,它的每个部分都应该被产品负责人接受。
  • 其他可见的进度指示

    • Scrum要求在团队内部和外部都保证透明性,产品增量是保证这种透明性的最重要方式
    • 除此之外, Scrum团队还会根据需要去创建一些其他工件来让大家了解项目状态
      燃尽图和任务板是常⻅的展式进度的额外工件

交付产品增量时,需要依据共同认可的“完成”标准来确认完成。
每个Scrum团队的“完成的定义”不尽相同,随着团队的成熟,其范围将扩⼤,并且变得越来越严格
“完成的定义”必须总是保证产品增量的质量足够好,从而达到可交付使用的状态:产品负责人可以选择随时发布它

3. Scrum活动或会议

3.1 产品待办事项列表梳理

产品待办事项通常会很大,也很宽泛,而且想法会变来变去、优先级也会变化,所以产品待办事项列表梳理是一个贯穿整个Scrum项目始终的活动

  • 包含但不限于以下的内容:
    • 保持产品待办事项列表有序
    • 把看起来不再重要的事项移除或者降级
    • 增加或提升涌现出来的或变得更重要的事项
    • 将事项分解成更小的事项
    • 将事项归并为更大的事项
    • 对事项进行估算

产品待办事项列表梳理的最大好处是为即将到来的几个Sprint做准备。为此,梳理时会特别关注那些即将被实现的事项

  • 需要考虑不少因素,这包括但不限于以下的内容:
    • 理想情况下,下一个Sprint的备选事项都应该提升“商业价值”。
    • 开发团队需要能够在一个Sprint内完成每一个事项
    • 每个人都需要清楚预期产出是什么
    • 产品开发决定了,有可能需要其它的技能和输入。因此,产品待办事项列表梳理最好是所有团队成员都参与的活动,而不单单是产品负责人

3.2 Sprint计划会议

每个Sprint都由一个限定时间的会议开始,这个会议称作Sprint计划会议。在这个会议中,Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。
- 所有的Scrum会议都是限定时⻓的。 Sprint计划会议推荐时⻓是Sprint中的每一周对应两个时或者更少
因为会议是限制时间的, Sprint计划会议的成功十分依赖于产品待办事项列表的质量
- 整个团队都要参加Sprint计划会议
- 针对排好序的产品待办事项列表( Product Backlog),产品负责人和开发团队成员讨论每个事项,并对该事项达成共识,包括根据当前的“完成的定义”,为了完成该事项所需要完成的所有事情

决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责

在Scrum中, Sprint计划会议有两部分:

  • 决定在Sprint中需要完成哪些工作;

    • 产品负责人向开发团队介绍排好序的产品待办事项,整个Scrum团队共同理解这些工作
    • Sprint中需要完成的产品待办事项数目完全由开发团队决定
      做多少工作只能由开发团队决定。
      产品负责人或任何其它人,都不能给开发团队强加更多的工作量。
    • 为了决定做多少,开发团队需要考虑当前产品增量的状态,团队过去的工作情况,团队当前的生产能力,以及排好序的产品待办事项列表
    • 通常Sprint都有个目标,称作Sprint目标
  • 决定这些工作如何完成

    • 开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量
    • 进行足够的设计和计划,从而有信心可以在Sprint中完成所有工作
    • 头几天的工作会被分解成小的单元,每个工作单元不超过1天。之后要完成的工作可以稍大些,以后再对它们进行分解
    • 产品负责人可以继续留下来回答问题,以及澄清⼀些误解。不管怎样,团队应该很容易找到产品负责人

Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,并预期在一个合理的条件范围内完成它们。
开发团队预测并共同承诺他们要完成的工作量

总之:在Sprint计划会议中,开发团队

  • 和产品负责人一起考虑并讨论产品待办事项,
  • 确保他们对这些事项的理解,
  • 选择一些他们预测能完成的事项,
  • 创建足够详细的计划来确保他们能够完成这些事项
  • 产出《Sprint待办事项列表( Sprint Backlog)》

3.3 每日Scrum会议

开发团队是自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。这个会议每天在同样的时间和同样的地点召开

  • 每个开发团队成员需要提供以下三点信息:

    • 从上一个每日Scrum到现在,我完成了什么;
    • 从现在到下一个每日Scrum,我计划完成什么;
    • 有什么阻碍了我的进展。
  • 每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。
    通常,许多团队会在每日Scrum之后马上开会处理他们遇到的任何问题

  • 每日Scrum既不是向管理层汇报,也不是向产品负责人或者ScrumMaster汇报
    它是一个开发团队内部的沟通会议,来保证他们对现状有一致的了解

  • 每日Scrum是Scrum的一个关键组成部分,它可以带来透明性,信任和更好的绩效。能帮助快速发现问题,并促进团队的自组织和自立

  • 所有Scrum会议都是限定时⻓的。每日Scrum通常不超过15分钟

3.4 Sprint评审

Sprint结束时, Scrum团队和相关人员一起评审Sprint的产出。

所有Scrum会议都是限定时间的, Sprint评审会议的推荐时长是Sprint中的每一周对应2个小时
Sprint评审会议向每个人展示了当前产品增量的概况。因此,通常都会在Sprint评审会议中调整产品待办事项列表

  • 讨论围绕着Sprint中完成的产品增量

    • 由于Sprint的产出会涉及到一些人的“利益”,因此一个明智的做法是邀请他们参加这个会议,这会很有帮助
    • 这个会议是个非正式的会议,帮助大家了解我们当前进展到哪⾥,并一起讨论我们下一步如何推进
    • 每个人都可以在Sprint评审会议上发表意见
    • 产品负责人会对未来做出最终的决定,并适当地调整产品待办事项列表( Product Backlog)
  • 团队会找到他们自己的方式来开Sprint评审会议

    • 通常会演示产品增量
    • 整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现
    • 还会讨论产品待办事项列表的状态、可能的完成工期以及在这些工期前能完成什么

3.5 Sprint回顾

Sprint回顾会议的推荐时间是Sprint中的每1周对应1个小时

在每个Sprint结束后, Scrum团队会聚在一起开Sprint回顾会议,目的是回顾下团队在流程、人际关系以及工具方面做得如何

Scrum团队总是在Scrum的框架内,改进他们自己的流程

4. 敏捷宣言的价值观

  • 个体与互动 高于 流程和工具
    赖于不同团队和团队中的个体之间的信任以及他们之间的合作方式

    • 团队确定该做什么,
    • 团队确定如何去实现
    • 然后由团队来完成
    • 团队发现前进道路上的障碍,并负责解决职责范围内的所有困难。
    • 团队也会与组织内的其他部门合作去解决团队职责范围外的困难
  • 工作的软件 高于 详尽的文档
    团队每个Sprint都必须交付可工作的产品增量
    尽管还会有类似于分析、设计、测试的工作,可能需要文档记录下来,但是只有可工作的软件能帮助组织达到项目成功

  • 客户合作 高于 合同谈判

  • 响应变化 高于 遵循计划

5. Scrum的价值观

  • 专注:一段时间内只专注于少数件事情
  • 勇气
  • 公开
  • 承诺
  • 尊重

你可能感兴趣的:(框架,敏捷开发,敏捷,Scrum)