scrum规范流程

Posted 2023-04-09

参考技术A 1 头脑风暴

流程如下

1） 确定议题（由发起人在头脑风暴前确定，大家提前做好准备），确定风暴具体时间

2） 选举主持人

2） 独立思考3分钟（让大家有时间准备一下发言）

3） 主持人主持，每个与会者轮流发言（发言时间不限）。记录员记录每个人的发言

4）由主持人主持并总结每个人的发言，并跟每个人确认是否总结的合适，不合适要反馈修改

4） 进入自由讨论过程，整个过程不得超过60分钟

5） 最后主持人总结结论

可以以头脑风暴的形式产生User Story列表，团队对用户故事进行拆解和估算，形成最终的Product Backlog （建议：客户代表参与，这里的客户代表是指能代表客户的任何人）

表一 Product Backlog示例

编号 标题 描述(User Story) 优先级 Story Point
010100 定位对话 作为一个用户，我希望通过时间、角色、主题等来筛选我要的对话 1 9

由于团队初试Scrum，所有用户故事的拆解和估算由整个团队共同讨论产生。Backlog中的每个User Story必须控制在一个Sprint内可以完成，否则需要进行拆解。

注1：本次以演示Sprint计划会的形式对“User Story列表”进行Story Point的估算。建议在确定“User Story列表”后，大家回去思考一下，专门开一个拆解会，不要与Sprint计划会混淆，因为Sprint计划会是在“User Story列表”估算后得到了完整的Product Backlog后进行的。

注2：User Story优先级划分，四象限法，纵轴是用户需求，横轴是技术实现的难度，优先级最高区域在第二象限的 User Story（用户最需要且技术实际难度最低），优先级最低区域在第四象限的 User Story（用户需求最小且技术实现难度最大）。

2 立项会

2.1 市场价值

2.2 展示Product Backlog

2.3 确定项目组（PO、SM、Scrum Team、观察者）

PO：

SM:

Scrum Team:

观察者：

特别观察者：

2.4 预算投入

2.5 启动计划书

2.6 审批（审批结果：修改、执行或者驳回）

注：项目组各角色的职责

PO：产品负责人，代表公司和客户的利益，确保交互的产品是满足客户价值的产品。负责创建和维护Product Backlog，管理商业价值。计划产品的发布时间，对每次Sprint的结果进行评审和验收。跟踪团队进展情况。

SM：Scrum Master的角色是教练和服务者。负责Scrum敏捷开发的四个会议的主持。规则的维护者。障碍清除者，负责清除迭代中出现的各种障碍，帮助团队成员解决困难，维护障碍列表。促进过程改进，维护改进列表。

观察者：对整个过程，从产品立项到项目结束的过程的学习，不同角色的人有所偏向，如产品规划部的人偏向PO的工作的学习。

特别观察者：负责整个敏捷过程的监督，规则的草拟者和完善者（最终方案由团队或者管理层通过后具体实施），确保团队按照敏捷的思想进行管理及日常开发。

Scrum团队：Scrum的中心角色，负责开发出可交付的产品。包括开发，测试，文档，UI等产品交付的所有角色。终结目标是实行自组织，自管理。参与Sprint backlog的创建，领取任务，按承诺完成任务，及时向SM汇报障碍，每天更新任务的状态（未开发、进行中、阻塞、完成），配合团队清除障碍。保证整个迭代能够顺利完成。

3 敏捷开发流程（初稿，待细化和修正）

3.1 Sprint计划会

主持人：Scrum Master

与会者：全体项目组成员，包括PO、SM、Scrum Team，其他相关人员（如客户代表，在分解用户故事的时候，可以给出更具体的解释）

时长：控制在一个工作日内。

目的：确认迭代目标

内容：从Product Backlog中选取本次迭代的Sprint Backlog，将Sprint Backlog中的用户故事分解成任务列表，对每个任务估算时间，精确到小时，每个任务最长不超过8小时，否则需要拆解。Scrum Team成员根据自己的兴趣和特长领任务。SM确保每个任务都有人领。

3.2 每日站立会

主持人：Scrum Master

与会者：SM、Scrum Team，其他感兴趣的人（只允许SM和Scrum Team发言）

时长：15分钟内。（必须控制在15分钟内，站立的原因也在此，时间过长会导致成员疲惫，影响工作）
目的：让团队每一个成员清楚地知道团队整体进度，离目标的距离。

内容：每天同一时间开（一般为早上工作开始时间），每个人轮流汇报三件事：昨天的承诺完成的怎么样？今天承诺完成什么？影响承诺完成的困难是什么？会议不能讨论问题如何解决，SM记录每个人的困难，在会后组织相应的人讨论解决，清除障碍。

3.3 Sprint评审会

主持人：Scrum Master

与会者：全体项目组成员，包括PO、SM、Scrum Team，其他感兴趣的人。

时长：最长4小时
目的：演示成果，增加成员的成就感。确保成果与预期一致，收集反馈。

内容：SM介绍迭代的总体情况，目标和实际的结果，差距是什么，差距原因是什么。Scrum Team简要介绍所涉及的技术问题（如架构及其变更），演示已实现的功能。SM推动自由讨论，集思广益。最后，PO根据评审结果可能采取如下行动：更新Product Backlog（如没有按计划实现的功能，产生的新想法），重新设定优先级；决定是否将迭代发布成一个新版本；

3.4 Sprint回顾会

主持人：Scrum Master

与会者：SM、Scrum Team，其他感兴趣的人（如PO）。

时长：最长4小时
目的：评价迭代，总结经验教训，促进下一轮迭代的改进。

内容：SM总结本次迭代，重要的事情和决策，预期的和实际情况的差距，及原因。每个成员陈述迭代中的优缺点，SM进行记录。对重要的问题计划解决的措施。

注意：

1）用户故事才是开发的目标，而不是单个任务，故事全部完成才算达成目标。

2）评估时间（每个人给出一个时间，当不知道怎么评估时，可由最熟悉的人先发言，给出一个时间，并阐述原因，其他人据此补充，最后统一大家的评估，如果发生分歧时，取协商一致后的时间，如果不能达成一致，取较大值）

3）照明弹，当遇到没接触过的领域时，先安排时间调研，调研后再做决定。

附录：

记录员需要记录的点：

1.头脑风暴的过程，重点在于观点和观点的形成过程

2.user story列表

3.拆解和估算user story列表形成Product backlog的过程。包括优先级的估算以及Story Point的估算。

4.Story point，需要详细记录每个人对于point 的建议，以及点数估算，及最终大家达成一致的估算point

5.形成并记录 product backlog，backlog由story构成的，需要排列优先级，po是backlog的管理者，日常中要记录backlog的进度并及时跟整个团队汇报。Product backlog中的内容要逐个分析，挑选出本次迭代最终需要的sprint backlog

6.由sm主导将sprint backlog分发为task，task的时间粒度不能大于一天，精确到小时。Task要分发到人，记录员要根据list的每天实现情况，追踪和发现问题

7.经过几次的task执行和评估，逐渐形成一种标准，及按照平均数来估算相似任务需要多长时间，久而久之能够形成直接对product backlog的评估

8.每次迭代的情况，主要是针对燃尽图、估算的情况来整个复盘哪里出了问题，为复盘会提供支持，推动大家的分解和评估能力日趋提高，也推动团队能够有效能成长，及用相同的时间完成更多的points，这些points是按照标准确定下来的，所以会出现之后每个月完成更多points的情况，反应成长性

scrum 和敏捷介绍（概念流程自己的理解）

scrum 和敏捷介绍

背景

本文介绍 scrum 框架，基于自己的理解，有些可能不够准确，请评论反馈

• scrum是敏捷中的一种，比较出名的一种，但并不是所有

• scrum的规模是比较小的，通常都是小团队10人内的

• 很多公司可能实行的是scrum的变种（在流程、人员上稍作改变）

• 敏捷的英文叫Agile，scrum只是其中一种小团队的（一般10人以下），更大规模的叫SAFe（上百上千）

• 敏捷，常常会跟软件开发的瀑布模型（waterfall）来进行比较

  • waterfall是老式的开发周期比较长的
  • 敏捷一般是小量迭代的，适应快速的市场变化的

人员

• Product Owner（PO）：一般翻译为产品经理，直译是"产品所有人"，对product backlog负责的人

• Scrum Master（SM）：一般没有常用的中文翻译（敏捷教练？项目经理？有道词典上也有 “流程管理员” 的翻译）。管敏捷流程的人

• Development Team：简称Team，由开发、测试等人员组成。

其他概念

• backlog 待办事项，分为prodct backlog和sprint backlog

  • product backlog：待办事项
  • sprint backlog：某次sprint要做的待办事项，由product backlog挑选出来放入sprintt backlgo

• sprint：某次迭代周期要做的事情，如sprint 1 / sprint 2 …（一次sprint安排的量通常是 1-3周完成），一般命名比如 sprint 1 加数字

• 会议

  • sprint planning：在这个会议中讨论并从product backlog挑出下次sprint要做的事情，输出有sprint goal和sprint backlog
  • daily scrum：指的是每天的会，也有叫daily meeting/daily standup/standup meeting，总之是每日站会，会上每个人一般会说明昨天做了什么、今天做什么、遇到什么困难，有时明天计划做什么也会说，其实就是每日交流会。一般还会提到白板这个概念
    • 白板：一般指实体的白色黑板，上面贴上类型to do/doing/…等不同时期的便利贴以便跟进进度情况
  • sprint review：这个容易误以为是回顾会、复盘会，其实是对交付内容（即产品增量）进行review，即审查结果 （针对产品）
  • sprint retrospective：回顾会，会上讨论做得好的做得不好的，是一个总结类似复盘的会议。（针对人）

• 3个文件

  • 前面提到过的product backlog
  • 用户故事user stories
  • 燃尽图：burndown chart

• increment：是一次sprint完成后的产出，即 “产品增量”，是产品增加了什么、修改了什么

• user story：用户故事，一般是用 “作为…我需要…以便…” 描述用户的需求的。

• story：可以理解为描述要做什么的，story可拆分为更加细的任务（task）

• epic：这个概念其实不是在scrum里的，其实就是指需求，不过是一个比较大比较粗的需求，会分解为story

总结：以上scrum的元素基本呈现出来了，3-3-5-5

• 3个组件：product backlog、sprint backlog、increment

• 3个角色：product owner、scrum master、development team

• 5个事件：sprint、sprint planning、daily scrum、sprint review、spring retrospective

• 5个价值观：respect、openness、courage、commitment、focus（专注）

流程

sprint backlog中挑出若干，在sprint planning中进行分析和拆分，会议输出sprint goal（目标）和sprint backlog（这次sprint要做的事情），进行迭代开发，每天有daily scrum（daily meeting），此次sprint完成后输出increment，对increment对行review的是spint review的过程，同时有sprint retrospective会议去总结团队成员做得好的做得不足的。

整个流程是Scrum Master去组织和把控的，所以SM会被翻译为 “流程管理员” 或者项目经理。

结束语

其实这些是标准的scrum流程，实际可能会有些出入，比如似乎没有Product Owner，由SM去收集需求；

有些情况是没有SM角色，该角色由Product Owner 或 “领导” 去做了。

有些公司可能有BA（Business Analyst），感觉做的公司更加像产品经理，即分析业务的业务分析师

思考：

1. 你说有Product Owner和SM存在的时候，谁是 “更大的领导”？
2. 产品经理很多公司已经叫PO了，我觉得原因可能是叫Produc Manager缩写为PM的时候容易与项目经理（Project Manager）混淆在一起，所以叫PO（Project Owner），另外一个国内管产品经理叫PO可能也是从Scrum中雪莱的吧？