不在Scrum和《ScrumGuide》中的概念或定义

Posted 2021-04-23 scrumorg

不在Scrum和《ScrumGuide》中的概念定义

通过《Scrum Guide》学习，总结了不是Scrum的一部分，如果你有，请补充

UserStory

某管理层：“所有故事都必须以敏捷的格式编写。”

什么是“敏捷格式”？有人听过这个词吗？是否必须以用户案例的形式编写所有Product Backlog Item？“

用户故事(User Story)”一词在Ken Beck的著名著作《Extreme Programming Explained》中得到推广。ScrumGuide中提到了多少次用户故事(User Story)？

答案是零。

ScrumGuide使用术语“产品待办事项ProductBacklog items”，也称为PBI，不局限于用户故事(User Story)。

StoryPoint

故事的重点是什么？您很有可能会从不同的人那里得到不同的答案。

Mike Cohn对故事点的定义，“故事点是一种度量单位，用于表达对全面实施产品待办事项或任何其他工作所需的总体工作的估计”(“Story points are a unit of measurefor expressing an estimate of the overall effort that will be required to fullyimplement a product backlog item or any other piece of work”)。一些团队可以将故事点与小时数、时间等其他单位相关联这种做法我们将单独在另一个话题讨论。

其实ScrumGuide中找不到类似故事点的内容。在ScrumGuide中，我能找到的最接近的是“Product Backlog具有描述、排序、估算和价值的属性” (“Product Backlog items have theattributes of a description, order, estimate, and value”)。可以以任何有意义的方式进行估算，而不必使用“故事点”进行估算。

Velocity

通常我们从领导和管理层那里总会得到有关如何提高团队速度的指导的情况。

如果故事点Story Point不属于ScrumGuide的一部分，那么我们如何计算“速度”？

团队如何衡量绩效随时间的变化由ScrumTeam 决定。

ScrumBoard

“Kanban board和Scrum board有什么区别？” 

“什么是Scrum board？”。

大多数团队都在使用某个面板来显示Sprint的当前状态，并且几乎所有软件工具中都提供了该面板，但是这些只是一个简单的board牌，不是真正意义上的KANBAN，没有任何WIP限制和特定的swim lane。

ScrumGuide中没有定义Scrum Board之类的东西。团队可以自由使用他们喜欢的任何工具，只要是informationradiators对Scrum Team透明可见，而不局限于 Kanban board。

Backlog

一次培训和会议中的对话。“我将其放进Backlog中。”，

“哪个Backlog？”“我的Backlog”。我们从未听说过“我的Backlog”这个词语。

因此更具体地说， “ProductBacklog或SprintBacklog”都是“我的Backlog”。在实际沟通中，您遇到了多少次“Backlog”一词，不得不推断他的具象含义，并会造成误解。

Scrum中没有“Backlog”之类的东西。ScrumGuide仅定义“Product Backlog items”和“ Sprint Backlog items”。

ScrumGuide中的“ProductBacklog items”一词始终以Product和Sprint之一为前缀。

Team

ScrumGuide仅描述了“ ScrumTeam”和“Development Team”。只说“Team”时如果未在适当的context使用，沟通会用“Team”一词来推断不同的含义造成误解。 

如果有一种组织多团队模式，有很多开发团队和许多产品所有者，并且开发团队和产品所有者之间的关系是多对多的。一个产品负责人与许多开发团队一起工作时不是问题，多对多的一起工作时就违反了Scrum的一项基本规则，即 (“The Product Owner is one person,not a committee.”)。

Assign

在fake Agile中，我们会听到：“进展非常顺利，如果有人去度假，我们将适当的用户故事和故事点分配给团队中其他人，以保持我们的速度”。这种Fake Agile 就有很大问题，即使我们忽略了“故事点”，“用户故事”，“团队”和“速度”，这里最大的问题是分配工作。

Scrum遵循5像价值观，每个人都朝着一个共同的愿景和目标而努力，不是也不能有分配、推送等等被动或者任何官僚的主动动词推动。

Definition of Ready

在fake agile中，会有：现在是“Backlog refinement”的时刻，每个人手里都有“Definition of Ready义”的副本，讨论围绕“准备就绪的定义”清单进行等等对话。

尽管“Definition of Done”是Scrum的一部分，但是“Definitionof Ready is not”。正如Mike Cohn在他的文章中所描述的那样，使用这种做法的潜在危险被用作phase-gate。团队可能会在Sprint planning期间停止将PBI从Product Backlog移至Sprint Backlog，声称并非所有“ Ready of Ready”项都经过检查，使其像waterfall或phase-gate。它应该作为指南一样指导开发团队更好地了解工作。

Release Planning

在fake Agile中，经常有这样的对话：“Release planning是一项长期计划，使我们能够回答诸如“何时完成？”

 “到年底我可以获得哪些“feature“？” 

“这将花费多少？”等等

ScrumGuide中没有定义“Releaseplanning”。

Jira

我遇到很多声称因为使用Jira而感到敏捷，或Scrum的团队、组织、部门他们说他们使用Jira和“Daily Standup”。

Jira只是一个软件工具，并非必须使用它才是Agile或者Scrum。

ScrumGuide任何地方均未提及。没有Jira，甚至根本没有任何工具，甚至我曾经使用过的Microsoft Excel，都可以做到Agile或者Scrum。

Daily Standup

ScrumGuide里面没有“每日站会”的观点和词语，“每日站会”来自“Daily Standup“的翻译。

ScrumGuide中只有”Daily Scrum“，没有任何关于Standup的描述，每日Scrum会议一定要站着吗？

对这个我问题，咨询了很多PST和CST以及通过邮件请教了业内顶尖专家，答复是不一定，Daily Scrum完全可以按照下图那样坐着进行，强调的是Daily而不是Standup。

更多

还有更多不是在Scrum和ScrumGuide中的定义：他们是Agie发展以来的各领域或从业者百花齐放的实践，逐渐被大家接受和引用，但绝对不是Scrum和ScrumGuide定义和倡导的，比如：

• Storygrooming

• NFR(NFRs)(Nonfunctional Requirements )

• MVP(MinimumViable Product )

• Stakeholders

• PlanningPoker

• Epic

• Theme

• Feature

• Task

• Brundown(up)

参考

• 《ScrumGuide》

• 《Extreme Programming》

• Mike Cohn “storypoints“https://www.mountaingoatsoftware.com/blog/what-are-story-points

• Mike Cohn ＂DoR＂https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready

 

掃碼關注

让更多人了解scrum.org在中国的推广

PSM課程報名：http://i7q.cn/6xmHpY

这是Scrum.org的注册商标