您了解Scrum吗？还是您了解Scrum？

最新推荐文章于 2024-09-14 19:55:48 发布

weixin_26752759

最新推荐文章于 2024-09-14 19:55:48 发布

阅读量183

点赞数

文章标签： python

原文链接：https://medium.com/serious-scrum/have-you-understood-scrum-or-have-you-understood-scrum-3581f10f2edf

版权

“Complete the system technical architecture document. Submit three interface design specification documents for review. Review the logical data model with the clients and rework if there are any changes needed”— was the Sprint Goal of yet another struggling Scrum teams.

“ 完成系统技术架构文件。 提交三个接口设计规范文档以供审查。 与客户一起审查逻辑数据模型，并在需要进行任何更改时进行返工”，这是又一个挣扎的Scrum团队的Sprint目标。

A few days later-

几天之后-

“Can we shorten the scope of the Sprint Goal?” — said one of the Development Team members during the Daily Scrum.

“ 我们可以缩短Sprint目标的范围吗？” —在每日Scrum大会上，开发团队的一位成员说。

And the Sprint Goal was modified to — “Complete the system technical architecture document. Submit one (not three) interface design specification documents for review. Review the logical data model with the clients (incorporate client comments in the next Sprint).”

并将Sprint目标修改为-“ 完成系统技术架构文件。 提交一份(不是三份)界面设计规范文档以供审核。 与客户端一起检查逻辑数据模型(在下一个Sprint中包含客户端注释) 。”

A day before the Sprint Review-

Sprint审查的前一天-

“Can we formulate the Sprint Goal closer to reality?” — said one of the Development Team members during the Daily Scrum.

“ 我们可以制定接近现实的Sprint目标吗？ ” –在每日Scrum大会上，开发团队的一位成员说。

And the Sprint Goal was modified to — “Complete the system technical architecture document. Send the logical data model to the clients for offline review”.

并将Sprint目标修改为-“ 完成系统技术架构文件。 将逻辑数据模型发送给客户端以供脱机查看 ”。

During the Sprint Retrospective, the Scrum Team addressed the issues due to which originally formulated Sprint Goal was changed during mid-Sprint and “pledged” to not modify the Sprint Goal in between the Sprint as it defeats the essence of Scrum. They also discussed that during the Sprint Planning Meeting, the Development Team should do due diligence before moving the stories from the Product Backlog to the Sprint Backlog.

在Sprint回顾期间，Scrum团队解决了一些问题，这些问题导致最初制定的Sprint目标在Sprint中期发生了变化，并“变质”为在Sprint目标之间不修改Sprint目标，因为它击败了Scrum的本质。他们还讨论了在Sprint计划会议期间，开发团队应先进行尽职调查，然后再将故事从产品待办事项列表移至Sprint待办事项列表。

The Product Owner recommended that the Scrum Team perform the Agile Maturity Assessment of the project and look at areas where they need to improve. The assessment score was 4 out of 5 points and indicated that the project is on the right track to implement Agile methodologies and Scrum framework.

产品负责人建议Scrum团队对项目进行敏捷性成熟度评估，并研究他们需要改进的地方。评估得分为5分中的4分，表明该项目可以正确地实施敏捷方法论和Scrum框架。

The Scrum Master “told”: “Let us formulate a more realistic Sprint Goal for this sprint.”

Scrum Master“告诉”：“ 让我们为这个Sprint制定一个更现实的Sprint目标 。”

Which came out as:

出来的是：

“Complete the system technical architecture document. Complete (with review) three interface design specification documents. Finalize the logical data model (complete with all reviews).”

“ 完成系统技术架构文件。 完整(含审阅)三个界面设计规范文档。 最终确定逻辑数据模型(完成所有审核)。 ”

Image for post — Photo by Paul Hanaoka on Unsplash

The system technical architecture document was finally completed in four Sprints, feel free to guess on the remaining.

该系统技术架构文档最终在四个Sprint中完成，您可以随意猜测其余的内容。

How did the project receive an assessment score of 4?

项目如何获得4的评估分数？

Most of the simple Agile Maturity Assessment Models are based on a point system and follow an objective approach. For example, these models may ask the following questions:

大多数简单的敏捷成熟度评估模型都是基于分数系统并遵循客观的方法。例如，这些模型可能会问以下问题：

How often do you hold the Daily Scrum Call?
您多久举行一次每日Scrum通话？
Do you conduct Sprint Retrospective meetings and capture notes on Confluence?
您是否举行Sprint回顾会议并记录有关Confluence的记录？
Do you run a Sprint Planning session and track the Sprint progress through Sprint Backlog?
您是否运行Sprint Planning会话并通过Sprint Backlog跟踪Sprint进度？
Do you create the Sprint Goal at the start of every Sprint?
您是否在每个Sprint的开始都创建了Sprint目标？
Do you focus on creating a valuable increment after the end of the Sprint?
在Sprint结束后，您是否专注于创造有价值的增量？

And so on…

等等…

When the Scrum Team did their assessment, they scored well on all the above questions as they are religiously following all the Scrum events. They have defined all the Scrum roles and maintain all the Scrum artifacts.

当Scrum团队进行评估时，他们认真地遵循了所有Scrum事件，因此在上述所有问题上得分都很高。他们已经定义了所有Scrum角色并维护了所有Scrum工件。

为什么Scrum团队成员专注于创建系统技术架构文档？ (Why did the Scrum team members focus on creating the system technical architecture document?)

The client contract (legal statement of work between the project team and the client) mentioned system technical architecture document as one of the payment milestones deliverables. In turn, this led the Scrum team to focus on delivering system technical architecture document so that they can get paid on completion of the first milestone.

客户合同(项目团队与客户之间的合法工作说明)提到系统技术架构文档是付款里程碑可交付成果之一。反过来，这导致Scrum团队专注于提供系统技术架构文档，以便他们在第一个里程碑完成时就可以获得报酬。

法律合同只是借口吗？ (Was the legal contract just an excuse?)

Let us look into what the Scrum Guide says about the role of Product Owner;

让我们研究一下《 Scrum指南》中有关产品负责人角色的内容；

“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” — The Scrum Guide, 2017

“产品负责人负责使开发团队的工作所产生的产品价值最大化。” — Scrum指南，2017年

and continues to mention

并继续提及

“Optimizing the value of the work the Development Team performs;”

“ 优化开发团队执行工作的价值； ”

In this situation,

在这种情况下，

Did the Product Owner believe that the creation of a system technical architecture document will maximize the value for the stakeholders?

产品负责人是否相信系统技术架构文档的创建将为利益相关者带来最大的价值？

Did he/she consider to optimize the value of the work that the Development Team is performing?

他/她是否考虑过优化开发团队正在执行的工作的价值？

“Scrum Master Service to the Product Owner: Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;” — The Scrum Guide, 2017

“ 为产品所有者提供Scrum主服务：确保产品所有者知道如何安排产品待办事项清单以实现最大价值； ” — Scrum指南，2017年

Did the Scrum Master ensure that the Product Owner is arranging the Product Backlog to maximize value by prioritizing the system technical architecture document?

Scrum Master是否通过优先考虑系统技术架构文档来确保产品负责人安排产品待办事项以最大程度地提高价值？

“Scrum Master Service to the Development Team: Helping the Development Team to create high-value products.” — The Scrum Guide, 2017

“ 为开发团队提供Scrum主服务：帮助开发团队创建高价值产品。 ” — Scrum指南，2017年

Did the Scrum Master consider that the system technical architecture document is the high — value product that the development team should deliver?

Scrum Master是否认为系统技术架构文档是开发团队应交付的高价值产品？

Did the Development Team believe that by creating the system technical architecture document, they are producing value and showing respect to their stakeholders?

开发团队是否相信通过创建系统技术架构文档，他们正在创造价值并表示对利益相关者的尊重？

Let us look at the Definition of Scrum;

让我们看一下Scrum的定义；

“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — The Scrum Guide, 2017

“ Scrum(n)：一个框架，人们可以在其中解决复杂的适应性问题，同时以富有创造力的方式交付最高价值的产品。 ” — Scrum指南，2017年

The Scrum Team understood Scrum, and they had defined roles, artifacts, and events as defined by Scrum.

Scrum团队了解Scrum，并且他们已经定义了Scrum定义的角色，工件和事件。

Did the Scrum team members understand the Scrum? Or was it just an artificial implementation of Scrum?

Scrum团队成员是否了解Scrum？还是仅仅是Scrum的人工实现？

I think the better approach could have been to start delivering value (in terms of product increments) in initial sprints itself. Some people may argue that how can we meet the expectations of the contract then. I would suggest not to hide behind the contractual terms and to avoid making it an excuse to do the things better.

我认为更好的方法可能是在初始冲刺本身中开始交付价值(就产品增量而言)。有人可能会争辩说，那时我们怎么能满足合同的期望。我建议不要隐瞒合同条款，并避免以做更好的事情为借口。

Let us turn the situation a bit here. Let us assume that the Development Team demonstrated the working product prototype. Do you think that the client would have asked the Development Team to stop work on the increment? Do you think that the client would have asked the Development team to create the document first?

让我们在这里稍微谈一下情况。让我们假设开发团队演示了工作产品原型。您认为客户会要求开发团队停止增量工作吗？您认为客户会要求开发团队首先创建文档吗？

I believe "No". I think the client would have preferred working functionality over a non-working document.

我相信“不”。我认为，与非工作文档相比，客户会更喜欢工作功能。

Rather, it could have turned into a more straightforward conversation with the clients to review the contractual terms and who knows they never wanted the system technical architecture document in the first place. I believe that we can amend the legal contracts; we have not carved them in stone. We create legal contracts only to safeguard the interests of the parties involved, and nobody wants to break them intentionally. And I also think the stakeholders certainly will embrace the amendment if they see it more effective and valuable.

相反，它可以变成与客户进行更直接的对话以查看合同条款，并且谁知道他们从一开始就不需要系统技术架构文档。我相信我们可以修改法律合同；我们还没有把它们刻在石头上。我们创建法律合同只是为了维护有关各方的利益，没有人愿意故意破坏它们。我还认为，如果利益相关者认为修正案更有效，更有价值，他们肯定会接受该修正案。

Now, let us again look at the two questions that I asked in the title of this article -

现在，让我们再次看一下我在本文标题中提出的两个问题：

Have you understood Scrum? Or have you understood Scrum?

您了解Scrum吗？还是您了解Scrum？

Are you only following the mechanics of Scrum or are you embodying the true spirit of it? If it is former, you may not be able to see the benefits of Scrum framework implementation, and the world would look like the same as it was earlier before Scrum. If you have understood the essence of Scrum, you are on the right path to deliver maximum value to your clients faster.

您是仅遵循Scrum的机制还是体现其真正精神？如果是以前的版本，您可能看不到Scrum框架实现的好处，并且世界看起来与Scrum之前的情况相同。如果您了解Scrum的本质，那么您将走上正确的道路，以便更快地为客户提供最大价值。

尾注 (EndNote)

Scrum implementation should not be understood as mere following the Scrum events, creating the Scrum roles, and producing the Scrum artifacts. To call it a successful implementation of Scrum, we should understand the true essence of the Scrum framework. Scrum is founded on empirical theory. Three pillars of inspection, adaptation, and transparency uphold the implementation of every empirical process.

Scrum的实现不应仅仅理解为遵循Scrum事件，创建Scrum角色以及生成Scrum构件。要称其为Scrum的成功实现，我们应该了解Scrum框架的真正实质。 Scrum基于经验理论。检查，适应和透明度的三个Struts支持每个经验过程的实施。

The Scrum team members should learn and explore the Scrum values inside out. Once the Scrum team members have discovered a way to deliver high productive value to their clients, they can easily handle the impediments of contractual obligations. It is always worth to focus on the outcome than output.

Scrum团队成员应该从内而外学习和探索Scrum价值观。一旦Scrum团队成员发现了一种为客户提供高生产价值的方法，他们就可以轻松应对合同义务的障碍。始终要注重结果而不是产出。