Skip to content

Instantly share code, notes, and snippets.

@adoyle-h
Last active January 1, 2022 17:51
Show Gist options
  • Save adoyle-h/fdddf8527716d09f5715 to your computer and use it in GitHub Desktop.
Save adoyle-h/fdddf8527716d09f5715 to your computer and use it in GitHub Desktop.
Scrum介绍

Scrum

什么是Scrum?

  • Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum在英语里是橄榄球运动中争球的意思,强调迅速,自我管理和可适应性。 虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法。

谁会用到Scrum?

  • 产品经理
  • 项目经理
  • 开发人员
  • 测试人员

为什么要用Scrum?

反思自己的团队

  • 需求不明确?
    • 需求变得太快?
    • 开发速度赶不上提需求的速度?
  • 实现功能需要太长时间?
  • 进度停滞不前?
  • 修BUG多于开发新功能?
  • 团队缺乏沟通?
    • 不清楚项目进度?
    • 不清楚同伴进度?
    • 分工不清?

我(们)期望怎样的开发?

  • 适应变化
  • 快速迭代
  • 沟通高效
  • 执行高效
  • 目的明确

Scrum特性/优点

  • 快速迭代(周期一般为2~4个星期)
  • 适应变化
  • 量化开发
    • 估算需求的投入量
    • 估算团队生产率
  • 自我管理
  • 进度跟踪
    • 每一个人知道谁负责什么,以及什么时候完成。
  • 透明直观

如何进行Scrum?

前提条件

  • 所有参与者都了解并认同Scrum。
  • 每位参与者都在项目中积极主动,自我管理。
  • 不会有人同时参与两个项目。

术语

  • Sprint
  • Backlog
  • 看板 or 故事板
  • 故事
  • Scrum扑克
  • 燃烬图

基本原则

  • 自我组织,自我管理
  • 沟通至上
  • 注重实践

团队组成

跨职能/多角色的小团队,人数一般为3~9人。

角色

  • Scrum Master:是Scrum教练和团队带头人,确保团队合理的运作Scrum,并帮助团队移除实施中的障碍。通常由项目经理扮演。
  • 产品负责人:确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间等等。通常由产品经理扮演。
  • 开发
  • 设计
  • 测试

编写Product Backlog

backlog从根本上来说,就是一个由需求或特性组成的列表,并按重要性的级别进行了排序。 列表每一行成为故事(story),也可称为一个backlog条目。

目的

制定产品功能需求等。

参与人员

  • 产品负责人(主要负责Product Backlog的编写)
  • 其他人(提意见)(并非指项目团队内的其他人)

原则

  • 只存在一个Product Backlog。
  • 只存在一个产品负责人。
  • 让故事停留在业务层次上。也就是说,每个backlog条目应该着眼于业务功能,而非具体技术实现。
  • 产品负责人之外的人也可以向 Product Backlog 中添加故事,但是他们不能说这个故事有多重要,这是产品负责人独有的权利。他们也不能添加时间估算,这是开发团队独有的权利。
  • 产品负责人应当理解每个故事的含义(通常故事都是由他来编写的,但是有的时候其他人也会添加一些请求,产品负责人对它们划分先后次序)。他不需要知道每个故事具体是如何实现的,但必须知道为什么这个故事会放在这里。
  • 产品负责人只需要关注业务目标,开发团队指出如何解决问题。

故事

故事一般包含以下几个内容/字段:

  • ID:即统一标识符,自增长的数字,以供索引。
  • Name:简短的描述性的名称。
  • Importance:重要程度。数值越高越重要。但这只是相对的概念,比如对于重要程度为1的故事来说,2和100的重要程度是一样的。目的只是为了排序。
  • Initial estimate:团队的初步估算,与其他功能相比,完成该故事所需的工作量。单位以point计数,相当于投入的人/月或人/天。估值不需要保证绝对无误。(Sprint计划会议中填写)
  • Demo:大略描述这个故事应该如何在 Sprint演示会议 上进行示范,本质就是一个简单的测试。(Sprint计划会议中填写)
  • Notes:注解。相关信息、解释说明和对其它资料的引用等等。一般都非常简短。(也可在Sprint计划会议中填写)

还可以添加其他内容/字段,如:

  • Category:故事属于什么分类下。
  • Bug tracking ID:如果你有个bug跟踪系统,那么了解一下故事与bug之间的直接联系就会对你很有帮助。

用时

因环境而定。

成果

  • 已排序的Product Backlog。

Sprint计划会议

目的

  • 为了让团队获得足够的信息,能够在几个星期内不受干扰地工作。
  • 确立本次Sprint的完成目标,指明奋斗方向。
  • 确立本次Sprint的参与成员名单。(每次Sprint可以人员不一样,但是Sprint进行中时最好不要有人员调动)
  • 确立Sprint 演示日期,即确定此次Sprint时间长度。(一般为2~4周,具体可根据团队生产率计算)
  • 从Product Backlog中梳理出Sprint Backlog。
  • 确立每日站立会议的时间及地点。(非常重要)

成果

  • 团队成员名单
  • Sprint 目标
  • Sprint Backlog
  • Sprint 演示日期
  • 每日站立会议的时间及地点

参与人员

  • 项目团队所有人(默认包括产品负责人)

用时

时间较长。一般为2~5个小时。

参考时间表

Sprint 计划会议:13:00 – 17:00 (每小时休息 10 分钟)

内容

按照参考时间表,具体时间划分与讨论内容如下:

13:00 – 13:30:产品负责人对 sprint 目标进行总体介绍,概括产品 backlog。定下演示的时间地点。

13:30 – 15:00:团队估算时间,在必要的情况下拆分Product Backlog里的条目。评估通过Scrum扑克来进行。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的 backlog 条目都要填写“如何演示”。

15:10 – 15:30:团队选择要放入 Sprint Backlog 中的故事。计算生产率,用作核查工作安排的基础。

15:30 – 15:40:为每日站立会议安排固定的时间地点(如果和上次不同的话)。

15:40 – 17:00:将故事拆分成具体的任务,加到Sprint Backlog中,并关联对应的故事。

这个日程绝不是强制执行的。根据会议进程的需要,可以对各个阶段的子进程时间安排进行调整。

每日站立会议

目的

  • 促进交流
  • 明确/解决问题

参与人员

  • 团队成员

用时

固定在短时间,如半小时或十五分钟以内。

成果/内容

  • 昨天完成了哪些工作?
  • 今天准备做什么?
  • 当前遇到了什么问题/阻碍?

Sprint演示会议

目的

  • 让其他人可以了解你的团队在做些什么。
  • 团队的成果得到认可。提高团队积极性。
  • 演示可以吸引相关干系人的注意,并得到重要反馈。
  • 演示迫使团队真正得完成工作。

参与人员

  • 团队成员
  • 用户
  • 其他可能对项目感兴趣的人

用时

演示时间很短,十几分钟。交流时间可长。

Sprint回顾会议

每一个Sprint完成后,都会举行一次Sprint回顾会议。

目的

  • 回顾过去,展望将来。
  • 去糟粕,取精华。
  • 促进团队交流。

成果

  • 会议记录
  • 用于下次Sprint的建议

参与人员

  • 团队所有成员。

用时

根据要讨论的内容范围,设定时间为1~4个小时。

内容

  • Scrum Master向大家展示Sprint Backlog,在团队的帮助下对Sprint做总结。包括重要事件和决策等。
  • 轮流发言。每个人都有机会在不被人打断的情况下讲出自己的想法,他认为什么是好的,哪些可以做的更好,哪些需要在下个 sprint 中改变。
  • 我们对预估生产率和实际生产率进行比较。如果差异比较大的话,我们会分析原因。
  • 快结束的时候,Scrum Master 对具体建议进行总结,得出下个Sprint需要改进的地方。

测试

TDD/BDD

这又是一个很长的话题……

提醒

  • 不能恪守教条,实践才是硬道理。
  • 团队和项目场景的不同,决定了Scrum实施方式的不同。所以没有通用的最佳Scrum实践,只有多多实践,走出适用自己的道路。
  • Scrum需要每个人的积极配合参与,否则效率还不如传统迭代开发。
  • 敏捷并不只是“快速开发,快速交付”,更重要的是“快速响应,快速调整”。

Scrum工具

  • Trello
  • Teambition

推荐书籍

《硝烟中的Scrum和XP - 我们如何实施Scrum》,作者: Henrik Kniberg,出版社: infoQ

@XadillaX
Copy link

Mark.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment