scrum
Posted 我的脑洞比你大呀
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了scrum相关的知识,希望对你有一定的参考价值。
scrum
scrum是什么?相信初次见到这个名词大家会感到很陌生,那么我再来说一个词,敏捷,相信大家就能猜到scrum是什么东西了吧。Scrum 是一个用于开发和维护复杂产品的框架 ,是一个增量的、迭代的开发过程,这个也就是最近非常受欢迎的敏捷思想。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。
scrum的大致流程如下:
看到这张图,大家也许会问“backlog”是什么鬼?“那个sprint计划会议又是什么东西?”别着急,且听我细细讲解:
首先我们先介绍一下scrum一些重要的组成部分。scrum框架包括3个角色、3个工件、5个事件、5个价值。其中3个角色包括产品负责人、scrum master和开发团队;3个工件表示的是产品backlog、sprintbacklog和产品增量;5个事件表示的是sprint、sprint计划会议、每日站会sprint评审会议和sprint回顾会议;5个价值代表的是承诺、专注、开放、尊重和勇气,下面就由我来详细介绍一下。
01
3个角色
1. 产品负责人。产品负责人负责最大化产品以及开发团队工作的价值。在互联网行业中,这不就是产品经理要做的事情了吗(找到了自己的位置,开心),但是不要高兴地太早,产品负责人的工作与我们现在的产品经理还是有着比较大的区别,产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:
1)清晰地表达产品代办事项列表条目
2)对产品代办事项列表中的条目进行排序,最好地实现目标和使命
3)确保开发团队所执行工作的价值
4)确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作
5)确保开发团队对产品代办事项列表中的条目达到一定程度的理解
产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是 负责任者。为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负 责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发 团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。
由此可见,这里的产品负责人与我们理解的产品经理还是有些不同的。一个团队里的产品经理可以有多个,而且都会对最终的产品产生影响,而产品负责人只能是唯一的。
2. 开发团队。开发团队相信大家都了解了,就是是实现我们的产品的一个团队,但是开发团队不包含测试或业务分析等负责特定领域的子团队。
3. scrum master。scrum Master 负责确保 scrum 被理解并实施。为了达到这个目的,scrum master要确保 scrum 团队遵循 scrum 的理论、实践和规则。scrum master是scrum团队中的服务式领导。通俗一点说,scrum master类似于一个中间人的角色,保证产品负责人、开发团队以及组织之间能够更好的协同工作。
02
3个工件
1. product backlog– 产品待办事项列表
产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。
产品待办事项列表通常以价值、风险、优先级和必须性排序。它是一个按照优先级由高到低排列的一个序列,每个条目有唯一的顺序。排在顶部的产品待办事项列表条目需要立即进行开发。排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。
产品待办事项列表在产品经理职能中的体现就是对需求进行优先级的排序。
2. sprint backlog– sprint待办事项列表
sprint 待办事项列表是一组为当前 sprint 选出的产品待办事项列表条目,外加交付 产品增量和实现sprint 目标的计划。sprint 待办事项列表是开发团队对于哪些功能要包含在下个增量中,以及交付那些功能所需工作的预计。
product backlog 功能点被放到sprint的固定周期中,sprint backlog 会因为如下原因发生变化:
1). 随着时间的变化,开发团队对于需求有了更好的理解,有可能发现需要增加一些新的任务到sprint backlog中。
2). 程序缺陷做为新的任务加进来,这个都做为承诺提交任务中未完成的工作。
product owner也许会和scrum team一起工作,以帮助team更好的理解sprint的目标,scrumMaster和team也许会觉得小的调整不会影响sprint的进度,但会给客户带来更多商业价值。
3.产品增量。增量是一个 sprint 完成的所有产品待办列表项的总和,以及之前所有 sprint 所产生的增量的价值总和。增量是在 Sprint 结束时支持经验主义的可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它,增量必须可用。
03
5个事件
事件一:sprint。sprint 是 scrum 的核心,其长度(持续时间)为一个月或更短时间的限时,在这段时间内 构建一个“完成的”、可用的和潜在可发布的产品增量。在整个开发过程期间,sprint 的长 度通常保持一致。前一个 sprint 结束后,新的下一个 sprint 紧接着立即开始。sprint由 sprint计划会议、每日scrum 站会、开发工作、 sprint评审会议和 sprint回顾会议构成。也就是说sprint包括下面四个事件。
事件二:sprint计划会议。sprint 中要做的工作在 sprint 计划会议中来做计划。这份工作计划是由整个 scrum 团队共 同协作完成的。
Sprint 计划会议回答以下问题:
1). 接下来的 Sprint 交付的增量中要包含什么内容?
2). 要如何完成交付增量所需的工作?
事件三:每日scrum站会。每日 scrum 站会是一个以 15 分钟为限的事件,它让开发团队同步开发活动,并为接下了的 24 小时制定计划。这需要检视上次每日站会以来的工作和预测下次每日站会之前所能 够完成的工作。
每日 scrum 站会在同一时间同一地点举行,以便降低复杂性。在会议上,每一个开发团队 成员都需要说明:
1)昨天,我为帮助开发团队达成 Sprint 目标做了什么?
2)今天,我为帮助开发团队达成 Sprint 目标准备做什么?
3)是否有任何障碍在阻碍我或开发团队达成 Sprint 目标?
事件四:sprint 评审会议。sprint 评审会议在 sprint 快结束时举行 ,用以检视所交付的产品增量并按需调整产品待办 列表。在 sprint 评审会议中,scrum 团队和利益攸关者协同讨论在这次 sprint 中所完成的 工作。根据完成情况和 sprint 期间产品待办列表的变化,所有参会人员协同讨论接下来可 能要做的事情来优化价值。这是一个非正式会议,并不是一个进度汇报会议,演示增量的目的是为了获取反馈并促进合作。
sprint 评审会议包含以下内容:
1)产品负责人邀请 scrum 团队和主要的利益攸关者参加会议;
2)产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”;
3)开发团队讨论在 sprint 期间哪些工作做的很好,遭遇到什么问题以及问题是如何解决 的;
4)开发团队演示“完成”的工作并解答关于所交付增量的问题;
5)产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可能的完成日期(如果有需要的话);
6)参会的所有人就下一步的工作进行探讨,这样, sprint 评审会议就能够为接下了的sprint 计划会议提供有价值的输入信息;
7)评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变;同时,
8)为下个预期产品版本的发布评审时间表、预算、潜力和市场。
事件五:sprint 回顾会议
sprint 回顾会议是 scrum 团队检视自身并创建下一个 sprint 改进计划的机会。
sprint 回顾会议的目的在于:
1)检视前一个 sprint 中关于人、关系、过程和工具的情况如何;
2)找出并加以排序做得好的和潜在需要改进的主要方面;同时,
3)制定改进 scrum 团队工作方式的计划。
04
5个价值观
1.承诺 – 愿意对目标做出承诺
2.专注– 把你的心思和能力都用到你承诺的工作上去
3.开放– scrum 把项目中的一切开放给每个人看
4.尊重– 每个人都有他独特的背景和经验
5.勇气– 有勇气做出承诺,履行承诺,接受别人的尊重
scrum的基本理论就介绍到这里,看到这,是不是发现这个框架与自己每天做的工作非常相似?scrum的理论从上个世纪的软件工程危机爆发后就逐渐兴起了,如今已经渗入到软件开发的各个方面,只要你是在开发一款产品,你一定会发现,scrum的思想会让你的风险降低到最小,从而最正确最大化的放大你的收益。希望本次分享会对大家有所启发。
END
以上是关于scrum的主要内容,如果未能解决你的问题,请参考以下文章