Scrum(五)过程详解

参考资料:https://www.uperform.cn/scrum-core-practices-training-learning-ppt-slide-deck-for-free/

Scrum的3个角色

1.Development Team 交付团队的使命和特征
  • 3 – 9 人
  • 跨职能,具备不同的职能,没有子团队,“T” 型人才,通用的专才
  • 全职投入, sprints之间方可换人,坐在一起
  • 自组织:
    没有管理者头衔
    全员责任制
    团队承担大部分微观管理工作
  • 决定迭代的工作容量
  • 每个迭代交付产品增量
  • 对“怎样做”和交付质量负责
  • 管理Sprint Backlog并跟踪进度
  • 找到团队内部合作的最佳方法
  • 与其他团队及相关方协作
  • 持续自我改进
2.Product Owner 产品负责人的特征和职责
  • “一”个人, 而非一个委员会
  • 被授与产品(“做什么”)决策权
  • 驱动产品走向成功
  • 提供产品领导力
  • 面向干系人代表团队
  • 面向团队代表干系人
  • 和所有人合作
  • 理想情况下是真正的用户来担任
  • 建立产品愿景
  • 从“为什么”开始
  • 定义产品功能(“做什么”)
  • 确保迭代输入准备好
  • 负责最大化投资回报
  • 根据反馈,为最好地实现业务目标将产品Backlog排定优先顺序
  • 决定版本发布日期和内容
  • 愿意投入到合作中并且在需要时被团队找到
  • 接受或退回工作成果
3.Scrum Master 团队敏捷教练的特征和职责
  • 面向管理层代表团队
  • 面向团队代表管理层
  • 没有管理头衔和权力 – 不代表团队做出决定
  • 更多是一个教练
  • 被授权的‘牧羊犬’
  • 团队和组织变革的代理人
  • 听多于说
  • 是一个具备影响力的仆人式领导者
  • 向大家布道Scrum
  • 彰显Scrum价值观、原则、实践和框架的模范
  • 保护团队
  • 移除障碍和浪费
  • 教练和培养团队的实践,帮助持续改进
  • 引导大家的协作
  • 提升组织变革的效果

SM Candidate 候选者特征

开放心态,积极探索,愿意分享和帮助他人。经历过转型或至少了解组织政治生态,善用权力但不渴望权力。中等偏上的技术和产品知识水平。具备沟通能力和意愿包括影响力。从性格像限看,友善或表现型偏多

ScrumMaster常见的关注领域
  • Team
    引导仪式和会议
    学习和团队发展
  • PO
    需求待办清单的梳理
  • Tech
    持续集成
    解耦
  • Organizational
    跨团队协作
    对管理层进行教练
    提高透明性

Scrum的3个工件

1.产品Backlog
  • 一份动态的有序列表,包含了符合产品愿景的各种功能
  • 以及其他为用户带来价值的工作
  • 一个健康的product backlog应当满足UPERFORM原则:
    Unified, 唯一的
    Pull-based, 拉动式
    Emergent, 动态的
    Revealed, 公开的
    Feature-sliced, 纵切的
    Ordered, 已排序
    Refining, 持续精炼
    Measurable, 可度量
  • 对所有人开放但最终由PO维护
  • 关注于“什么“带给用户最大的价值
  • 最优秀的PO从“为什么”开始
2.迭代待办项列表
  • 为本Sprint所选择的PBI以及交付所选PBI的工作计划之和
  • 产品Backlog 的延伸和子集
  • 为实现Sprint目标所要完成的工作集合
  • 涵盖‘恰到好处’的设计
  • 将大块的工作分解为更小的单元 (PBI -> SBI)
  • 关注于“怎么做”的问题:如何在一个sprint内完成工作以交付价值
  • 被开发团队拥有
  • 团队从product backlog中选取他们可以承诺完成的项目并创建sprint backlog
  • 协作完成,不是由ScrumMaster负责
  • 一个可视化的工具让团队在sprint内部自我管理
迭代目标
  • 迭代目标是本迭代中通过实现PB来达成的目标
  • 向团队提供构建该增量的理由(why)
  • 会议上产生
    T- 给予团队一些在功能实现上的灵活性
可视化任务墙看板
  • 任务板是一个常见的用于管理sprint backlog的可视化工具
  • 自组织:团队成员或小分队自己领取工作
  • 团队一起将PBI分解为SBI
  • 团队决定合适的SBI颗粒度
  • 没有一个人主导任务的分配
  • 完成一项任务才认领另外一项任务
  • 按照优先级,努力使一个PBI尽早完全完成
  • 团队每天跟踪Sprint中剩余的工作
  • 任何团队成员可以添加,删除或变更sprint backlog事项 (SBI)
  • sprint内的工作有可能动态涌现
  • 对全世界可见
  • 随时更新
  • 直观展示Sprint目标完成的进展
  • 工作可视化管理的工具
迭代燃尽图
  • 燃尽图是一个可选的可视化工件,用来管理Sprint Backlog,并帮助团队自己跟踪进度和暴露风险
  • 随时更新
  • 度量Sprint剩余工作的总量
  • 燃尽图有不同思路
  • 剩余工作量估算
  • 跟踪已完成项
3.潜在可交付产品增量
  • 当前Sprint所完成的PBI,以及之前所有Sprint的增量价值之和
  • 潜在可交付,并符合完成的定义
  • 必须是可用的产品,不管PO是否决定对外发布

Scrum的5个事件

1.迭代计划会
  • 时间:1个月的Sprint最长8小时
  • 第一部分 选择
    内容:定义迭代目标,选择团队可以承诺完成的迭代待办项
    参与者:PO/Team/SM(可选)
    输入: 健康的产品Backlog
    输入: 最新版本的增量
    输入: 团队这个Sprint的速率
    输出: 根据所选择的产品Backlog事项制定Sprint目标
  • 第二部分 计划
    内容:决定如何实现迭代目标,创建 Sprint Backlog,估算迭代待办项
    参与者: Team/PO(可选)/SM(可选)
    输入:团队这个Sprint所有人的工作容量
    输出: 如何实现Sprint目标的工作计划(Sprint Backlog)
    输出: 大家对Sprint目标形成共识
2.Sprint 迭代
  • 项目由一系列“sprint”组成,借鉴了极限编程中的“迭代”
  • 周期:不超过一个月的日历时间, 建议1~2周
    通常是定长的,有利于产生更好的交付节奏
    只有当时间盒到期时,Sprint结束
  • 根据DoD定义,全部相关工作在sprint内完成
  • 不去改变Sprint的目标
  • 不改变当前运行中的Sprint的长度
  • 出于业务需要,Product Owner可以取消Sprint
  • 如果无法完成任何东西,团队可以和PO协商应对
  • 重新做Sprint计划-所有还”未完成的工作”放回产品Backlog
  • 罕有发生!
3.每日站会
  • 时间:每日,15分钟,同一时间同一地点
  • 方式:站立
  • 参与者: Development Team(必选),SM(可选),PO(可选)
  • 目的:为达致Sprint目标检视进展和调整计划
  • 方式:每个人回答三个问题
    昨天我完成了什么,以便帮助交付团队达成迭代目标?
    今天我要完成什么,以便帮助交付团队达成迭代目标?
    有什么障碍影响我的进度和迭代目标吗?
  • 注意:
    不讨论和解决具体问题
    其他人可以受邀来旁听
    只有团队成员,ScrumMaster和Product Owner可以说话
    帮助避免其他不必要的会议
    不是向ScrumMaster汇报状态,而是向所有组员的广播,属于自管理的一部分
4.迭代评审会
  • 目的: 检视和调整产品和产品Backlog
  • 花费时间:1个月的Sprint时间盒最长4小时
  • 环境:非正式,不要用幻灯片,尽量不要准备
  • 参与人员:全Scrum团队,邀请所有干系人及感兴趣的人士
  • 做什么:团队展示Sprint的成果,PO应当尽早验收,产品负责人表明哪些“完成”的工作被接受了,哪些“未完成”的工作被退回了,经常以Demo新功能(及其依赖的架构)的形式,获取反馈和讨论接下来要做的工作,从而持续优化价值
  • 输出:可发布的产品增量
5.迭代回顾会
  • 目的:对我们如何工作(人、关系、过程、工具等)进行检视和调整, 对过程的持续改进
  • 花费时间:每1周的Sprint花费45min
  • 参与人员:全Scrum团队,同时也欢迎其他感兴趣的受邀人士
  • 环境:在安全的环境中进行
  • 做什么,三问:
    开始做什么?
    停止做什么?
    K继续做什么?
  • 输出: 下一个Sprint的改进行动计划,建立任务,有责任人,有预期完成时间。

你可能感兴趣的:(Scrum(五)过程详解)