(13.2.1)Scrum敏捷开发框架
来源:互联网 发布:淘宝代购nike 编辑:程序博客网 时间:2024/06/10 19:01
- 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的价值观
- 专注:一段时间内只专注于少数件事情
- 勇气
- 公开
- 承诺
- 尊重
- (13.2.1)Scrum敏捷开发框架
- 关于scrum敏捷开发(1)
- Scrum--敏捷开发过程框架介绍
- 敏捷开发之Scrum框架入门
- 敏捷开发之Scrum框架入门
- 敏捷开发之Scrum(1): 传统开发过程与Scrum
- 敏捷开发之Scrum(1): 传统开发过程与Scrum
- 开发管理 CheckLists(15) -敏捷开发框架SCRUM内容
- 敏捷开发工具scrum
- 敏捷开发SCRUM
- Scrum敏捷开发随笔
- 敏捷开发之SCRUM
- 敏捷开发(XP, SCRUM)
- 敏捷开发 Scrum 总结
- 敏捷开发--scrum
- 敏捷开发之Scrum
- scrum敏捷开发初探
- 敏捷开发之SCRUM
- ionic+requirejs实现图片的懒加载
- linux下客户端检测服务器的 heartbeat
- 如何禁用backspace和enter
- Sublime Text 3 LESS、SASS、SCSS高亮插件、提示插件
- 关于java中Double类型的运算精度问题
- (13.2.1)Scrum敏捷开发框架
- [转载]使用electron构建跨平台Node.js桌面应用经验分享
- 多线程NSOperation--NSInvocationOperation 和 NSBlockOperation 使用(一)
- Ceph对象存储测试中遇到的bucket名称的大小写问题
- 1随机变量及其概率分布
- Centos7安装Shadowsocks-qt5后无法打开的问题
- 欢迎使用CSDN-markdown编辑器
- 操作系统的编写与linux的学习
- 一篇文章看明白 TCP/IP,TCP,UDP,IP,Socket 之间的关系