Scrum完整剧本
Posted 敏捷家
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Scrum完整剧本相关的知识,希望对你有一定的参考价值。
-
产品列表梳理会议快速入门指南 -
每日站会快速入门指南 -
Sprint规划快速入门指南 -
Sprint评审快速入门指南 -
Sprint回顾快速入门指南
-
故事拆分快速入门指南 -
编写清晰明确的用户故事快速入门指南
-
由产品经理和产品负责人领导的,需求功能不断定义、完善、澄清以及重新确定顺序; -
在Sprint开始之前进行的一次协作会议,以评估新信息,确保准备开发下一组故事。
-
每个Sprint一次(通常是Sprint中,下一个Sprint开始前的1-5天不等)
注意:某些团队选择每个Sprint进行多次"梳理"会话。如2周的SPrint,可能一周梳理1次。
-
参与者 – 产品负责人,ScrumMaster,开发团队 -
输入 – 主要输入是为即将到来的Sprint预测的用户故事,这些可能是后续Sprint的不错选择。处于就绪状态的用户故事要多于下一个Sprint可能会有所帮助。因此,如果团队确定依赖性,并有了影响多个故事的优先级或工作量的新信息,那么就可以灵活处理。 -
输出 – 整个团队达成共识,就一组排好序、清晰定义且独立的用户故事达成共识。
-
查看从当前Sprint中学到的新信息 -
讨论最快速度、可能速度和最差速度 -
是否对当前的Sprint进度进行检查 - 我们是否认为我们将完成Sprint期间的所有工作?
-
在回答这个问题时,请牢记可持续的步伐 -
对于团队来说,在Sprint中去现实地评估事情,比等到Sprint结束后再进行任何变更,要好的多(香不香?)。
-
查看并澄清即将发布的用户故事 -
讨论并同意验收标准(Acceptance Criteria),以确认双方的理解。以及确认估算大小和拆分太大的故事
-
提醒:任何故事,如果团队在一个SPrint内无法完成4个,那么就是太大了。
-
同意下一个Sprint的计划
-
根据我们的速度预测和大小确定,这是一个现实的计划吗? -
如果对上一个问题的回答为"否”,则拆分故事,或交换优先级相近的小故事,直到团队对计划充满信心为止
注意:另请参阅多年前我写的产品列表梳理( https://www.bobjiang.com/scrum_product_backlog_refinement/ )
-
分享知识 -
找出帮助其他团队成员的机会 -
识别依赖性、风险 -
同意删除障碍的后续步骤
-
参与者 – 开发团队,ScrumMaster(或其他主持人),产品负责人 -
输入 – 主要输入是自上次"每日Scrum"以来的任何工作。其他潜在的输入包括在测试过程中可能出现的任何异常情况、优先级的更改,或其他可能影响Sprint计划的任何情况 -
输出 – 团队成员之间在以下方面达成共识,例如何解决已出现的任何障碍,以及如何在接下来的24小时内最有效地合作以将正在进行的工作项移至已完成方面达成共识
注意:与会者按重要性顺序列出:每日Scrum用于开发团队,因此会议属于团队的。Scrum Master通常作为主持人出现。但是,团队中的不同成员轮流担任主持人也很常见(不一定只有ScrumMaster来主持)。对于产品负责人而言,阐明可能出现的任何与产品相关的问题也可能会有帮助。
-
开始对话 -
浏览任务墙(快速查看工作流程中的位置,该墙可以是物理卡墙,也可以是Jira中的虚拟墙,或两者兼而有之) -
头条新闻(是否有特别紧急的事情需要讨论?) -
更新(障碍或其他团队成员想讨论的信息) -
击掌庆祝(无论是线下的还是线上的……;) -
站会之后(与停车场同义 – 必要时可以在站会之后进行的跟进对话)。 -
更新任务板(如果在对话期间更新了任何工作项的状态)
注意:另请参阅Scrum会议的输入输出( https://www.bobjiang.com/scrum_meeting/ )
-
制定和完善迭代目标 -
根据其相对优先级,讨论、确认要在Sprint中处理的功能(故事) -
在某些团队中,可以进行更深入的对话,其中包括任务分解,其中团队可以针对他们计划从事的任何给定故事,来识别需要完成的特定任务
-
参与者 – 开发团队,产品负责人,ScrumMaster -
输入 – 主要输入是来自 “产品列表梳理” 会议的一组定义明确(清晰、确定、按验收标准划分优先级)的故事。其他可能的输入包括自"产品列表梳理"会议以来对优先级的任何更改,或刚刚结束的Sprint中未完成的故事 -
产出 – 迭代目标和迭代列表(Sprint BAcklog)
-
从Sprint目标开始 -
讨论团队正在工作的任何业务或技术假设(这也是确保在产品列表梳理过程中不会丢失任何重要信息的有用方法) -
查看自上次产品列表梳理以来可能出现的任何其他新的信息:
-
对故事优先级的任何更改将在下一步进行 -
刚结束的Sprint期间未完成的所有故事,可以在即将开始的Sprint期间进行处理,具体取决于它们的优先级
-
检查谁(如果有的话)要休假,以及休多长时间 -
浮现出的任何依赖项或风险,包括谁可能是缓解这些依赖项或风险的所有者,以及预期的影响是什么 -
查看并澄清用户故事:
-
确认故事的细节和清晰度、以及故事的验收标准和相对大小 -
(可选)任务分解:某些团队选择在Sprint计划期间,将每个故事进一步分解为一组任务,一些团队单独进行任务分解(在Sprint Planning完成后),而有些团队则根本不执行任务分解(故事比较小的时候不需要拆分任务) -
越是新组建的团队,任务分解对他们有帮助的可能性就越大。(分解有助于理解故事的潜在风险) -
许多已经合作了一段时间的团队发现没有必要分解任务,特别是当这些团队一致地将故事分解成小块时
-
同意Sprint的计划:
-
基于团队能力,这是一个现实的计划吗? -
是否已确定所有依赖关系或风险? -
如果对前面两个问题的回答为"否”,请寻找在团队成员之间更均匀地分配工作的方法,或说明为解决依赖关系或风险而需要采取的措施
-
当团队就计划达成一致时,请确保相应的任务白板(如果团队使用的是物理白板)和Jira同步更新 -
重新审查Sprint目标,并确保它们与团队的Sprint计划相一致
-
自上次Sprint评审以来产品中发生了什么变化 -
当前产品功能的演示(Demo) -
团队接下来要进行的工作预览
-
每个迭代一次(迭代的最后一天,回顾会议之前)
-
参与者 – 产品经理,产品负责人,ScrumMaster,开发团队,利益干系人 -
输入 – 主要输入是团队在Sprint期间完成的一组工作项。其他输入包括自上次Sprint评审以来对战略或产品级别的总体愿景或优先级的任何更改 -
产出 – 明确团队完成的工作;利益干系人对团队完成工作的反馈;明确考虑团队的下一步计划,并考虑到所有利益干系人的反馈以及业务重点
-
当前Sprint完成工作,在整个产品中的位置(总览) -
讨论Sprint目标以及团队达到目标的程度 -
演示团队完成的工作
-
尽量避免以用户故事x,用户故事y(细节水平可能对某些涉众没有意义)来描述作品 -
相反,应专注于讲述有关产品当前行为的连贯叙述 -
确保利益干系人有机会提供反馈
-
(可选)探讨团队在Sprint期间可能遇到的任何挑战,这些挑战的影响以及团队如何克服这些挑战 -
认可团队所做的工作(以及在Sprint期间帮助其他团队的每个人) -
预览下一个Sprint中即将发生的事情 -
确保考虑可能影响这些计划的反馈 -
还可以提供有关团队在下一个Sprint之后将关注的重点的见解;重点是接下来(下一个SPrint)要发生的事情
-
参与者 – ScrumMaster,产品负责人,开发团队 -
输入 – 主要输入是团队在Sprint期间进行的各种活动 -
产出 – 明确说明团队工作方式的潜在变化,明确表达为团队同意的可行步骤,可以帮助团队尽可能有效地开展工作
-
主持人(通常是ScrumMaster)为对话奠定了基础 -
如果主持人已经根据自己的具体情况,预先准备了哪些活动和哪种类型的对话,最有可能为团队提供帮助,那么Sprint回顾会议就会是高效的会议。 -
为了建立心理安全,始终谨记Norm Kerth所阐明的"回顾会议的最高指导原则”:
无论我们发现什么,我们始终理解并坚信,鉴于团队当时所知道的信息、技能、能力和可用的资源以及当前的情况,每个人都已经尽了最大的努力。
-
在ScrumMaster的帮助下,团队重新思考了刚刚结束的Sprint。要讨论常见的三个方面的问题:
-
在Sprint期间进展顺利的地方 -
在Sprint期间进展不顺利的地方 -
团队可以采取哪些可行措施来持续改进
-
重要的是永远不要忽视积极的一面。确保包括积极观察的好方法很简单、例如询问"谁愿意感谢另一位团队成员”(或团队外部的人)在Sprint期间提供的帮助? -
团队同意的行动步骤,张贴到SPrint Backlog。可视化!
(+)引导回顾会议的方法非常多。每个团队每个SPrint都不一样,因此作为SCrumMaster需要有一个工具箱来引导回顾会。
-
如果是,请继续。 -
如果否,请先梳理故事,然后再尝试拆分。请参阅编写清晰明确的用户故事快速入门指南
-
如果是,则应继续进行拆分 -
如果否,无需进一步。
-
如果是,应将其拆分 -
如果否,则无需进一步
-
选择一种模式,导致多个拆分后的故事可以被取消优先级甚至删除。假设应用一种拆分模式会暴露低价值功能,而另一种则不会。这可能表明使用后一种拆分会在拆分后的故事中隐藏浪费(即低价值的故事)。应用拆分模式应该可以降低工作的优先级或消除工作。 -
选择一种模式,以产生大小相同的拆分后故事。如果拆分后的故事大小相同,则可以使优先级划分更加容易。
-
工作流程步骤模式 -
业务规则变化模式 -
简单/复杂模式 -
数据模式的变化 -
数据输入方式 -
操作模式 -
推迟性能模式 -
探针模式
-
作为作者,我希望能够提交我的文章,以便将我的内容发布 -
作为编辑,我希望在文章提交后得到通知,以便我及时进行审查。 -
作为编辑,我需要批准一篇文章,以便该文章可以排队发表。 -
作为编辑,我希望能够请求更多信息,以便及时与作者联系。
-
付款的币种必须于特定地点购买 -
现金付款面额不得超过。。。 -
收款的条形码是使用……设计的
-
作为贷款申请者,我想计算抵押贷款付款额,以便可以确定哪种贷款类型适合我
-
…手动计算我的抵押付款 -
…使用在线电子表格模板计算我的抵押贷款付款 -
…使用在线计算器计算我的抵押贷款还款额
-
作为用户,我可以搜索两个目的地之间的航班,以便选择最适合自己的航班。
-
…使用简单的日期输入来搜索航班。 -
…使用精美的日历界面搜索航班。
-
国际化/本地化 -
安全 -
可伸缩性
注意:我不是说,上述定义的"完成的定义"注意事项并不重要;我们在这里要避免的是尝试通过单个用户故事解决此类问题。
-
作为店主,我要管理在线商店中要出售的产品,以便可以出售人们想要购买的东西。
-
作为店主,我想从我的在线商店中添加和删除产品,以便潜在买家更容易找到产品。 -
作为店主,我想在我的在线商店中编辑产品详细信息,这样我就可以避免重新创建产品以解决错字问题。
-
作为用户,我可以用信用卡付款,因此我的交易可以迅速完成。
-
Spike:选择一种用于信用卡处理的技术
-
如果否,请考虑采用其他模式拆分原始的故事,或选择一种模式拆分任何大于其他故事的拆分后的故事
-
如果否,请考虑采用其他模式拆分原始故事,或重构任何需要重做的拆分后故事。
-
如果是,请与产品负责人一起确定拆分后故事中的部分是否:a)相对优先级高于其他拆分后故事;b)必要的(有时通过拆分故事来揭示并非真正必要的工作)
-
独立的 Independent -
可商谈的 Negotiable -
有价值的 Valuable -
可估算的 Estimable -
较小的 Small -
可测试的 Testable
-
独立的 – 在最大程度上,一个用户故事应该与另一个用户故事无关。这对于同一Sprint中正在处理的故事特别重要,因为故事之间的依赖性会使计划、优先级排序以及估算变得更加困难。尽可能在Sprint中来拆分或修改故事以减少或消除依赖性。 -
可商谈的 – 用户故事是可协商的,因为实际的故事卡(或其电子表示形式)旨在作为与将要构建的团队的"对话邀请”。与故事相关的详细信息在此对话期间得以解决。 -
有价值的 – 每个故事的用词很重要,以使与故事相关的商业价值显而易见。这就是产品负责人在帮助团队了解用户故事的"为什么"和"什么"方面起如此重要作用的原因。与每个故事相关的技术细节(“如何”)可在与该故事相关的描述性细节或单个任务中找到,并且团队根据对"为什么"和"故事"的理解来确定"如何做” -
可估算的 – 至少故事需要足够清晰,以使团队能够对故事的相对大小进行初步估计。可能会影响团队评估能力的常见问题包括:缺乏领域知识(这就是为什么围绕故事的"对话"如此重要)以及过大的故事(在这种情况下,故事需要拆分为多个小故事)。 -
较小的 – 从最基本的角度讲,故事必须足够小才能在Sprint中完成。根据团队的规模,迭代的时间长短和其他因素,团队通常将故事拆分得足够小,以便至少可以在一个迭代中完成六个(通常更多的)故事。简而言之,较大的故事会给团队带来麻烦,因为较大的故事代表着更多的不确定性,以及思考的深度不够。 -
可测试的 – 如果故事无法测试,则团队几乎不可能(更不用说产品负责人)知道故事何时"完成”。一个经典的反模式是当故事包含诸如"易于使用"之类的不精确的语言时(因为没有直接的方法可以测试易用性)。因此,需要以一种可以容易地从中得出测试方法的方式来编写验收标准。
-
目标用户(角色或用户类型) -
目标用户想要达到的目标 -
达到特定目标对用户很重要的原因 -
开发所需功能并测试该功能是否按预期工作的技术方法
注意:常见的误解是,编写用户故事的唯一责任在于产品负责人(或产品负责人的代理人)。尽管大多数情况下是产品负责人起草用户故事,但让团队成员参与编写和完善用户故事这很重要,因为当团队参与此活动时,每个人对什么内容会有相同理解,并且我们也知道为什么要构建以及我们如何知道何时完成。
-
标题 -
描述 -
顺序 -
大小(规模) -
验收标准 -
技术方法
-
更容易在物理媒体上书写,例如索引卡或便签纸 -
在查看多个故事时,团队成员更容易口头参考 -
使用诸如Jira之类的工具编写故事时,团队成员更易于解析
-
主申请人输入密码
注意:(角色)和(动作)是必需的,而(上下文)在标题中是可选的。例如,当有许多标题相似的用户故事时,添加上下文可以帮助区分它们。在上面的示例中,用户可能会在正在构建的应用程序的不同位置输入密码,或者可能存在不止一种密码。在这种情况下,添加上下文可以增加清晰度,例如"主要申请人输入密码(页面类型),或主要申请人输入密码(密码类型)。
-
人或系统输入哪些数据(或其他类型的输入)? -
该输入会产生什么数据(或其他类型的输出)?我们将如何测试?
-
创造价值的最薄的层面是什么?(纵向拆分) -
我们该怎么做才能确保我们是纵向拆分的呢?(而不是针对不同的水平层(例如,UI,数据库)使用单独的用户故事)
-
“不要让完美成为善良的敌人”(写下来然后继续前进;您以后随时可以更新) -
稍后您可能会意识到此用户故事不是必需的,或者必须分成较小的部分(更重要的是,不要花太多时间在编写任何用户故事上!)。注意:故事描述映射到Jira中的"描述"字段。故事描述格式
-
作为(角色/用户画像/用户类型) -
我想要(目标或行动) -
这样以便(目标/行动的期望结果)
-
作为主要申请人 -
我想输入从代理人那里收到的密码 -
这样我就可以访问我的福利请求并验证信息
注意:” Jira优先级"字段提供了许多其他选项,可以指示任何给定工作条目的相对重要性。本快速入门指南不涉及” Jira Priority"字段的用法。
注意:实际上,选择进行估算的团队通常在进行相对估算时会使用T恤尺寸作为起点。
注意:在没有估算的情况下取得成功的团队往往也会擅长将工作项分解成相当小的部分,其中最大的部分可能不会花费几天就能完成,一般来讲一个故事1-2天即可完成。本着检视和调整的精神,他们如何估算以及是否估算,可能是团队进行试验的领域。
注意:验收标准通常不会直接映射到Jira中的特定字段(取决于Jira的配置方式)。
-
将一个文本字段添加到"故事"问题类型(在"项目设置"中),并将其命名为"验收标准”。 -
将验收条件添加到描述字段
-
AT-1。测试当用户输入错误的旧密码时,他们会收到一条错误消息,指示不正确的密码 -
AT-2。测试是否在1小时内三次错误地提交旧密码导致用户从系统中注销 -
AT-3。测试订单确认中包含:
-
订单号 -
预计到达日期 -
客户服务电子邮件地址
注意:通常,属于技术方法的工件会作为附件,链接或子任务映射到Jira。
-
多个故事通常会引用同一工件或一组工件(例如,流程图,数据流程图或序列图)。只要团队了解工件的位置以及工件的内容,就不一定总是需要将这些工件附加到故事中(但是链接通常会有所帮助)。 -
相比之下,线框或实体模型通常是特定于单个故事的工件,因此,将此类工件附加或嵌入到故事中是一种常见的做法(链接到此类工件通常也是可接受的)。 -
一些团队概述了实现故事所需的技术方法,包括一系列步骤。每个步骤通常称为"任务”,弄清楚这些步骤的过程称为"任务分解”。(在Jira中,通常为此目的使用子任务)。
注意:Jira(和许多其他工具)支持输入与任务相关的时间(通常以小时为单位)的实践。许多敏捷从业者认为任务的输入(跟踪小时数)是浪费,更不用说任务持续时间(即"烧掉"时间)了。换句话说,要重点关注的是功能完成,而不是花费时间。
以上是关于Scrum完整剧本的主要内容,如果未能解决你的问题,请参考以下文章