问问专业的Scrum培训师——John Riley和Ben Thorp

Scrum本身是一个简单的框架，用于在复杂产品上进行有效的团队协作。虽然它是轻量级的，易于理解，但很难掌握。在Scrum.org上的“询问专业Scrum培训师”系列中，专业Scrum培训师(PSTs)将在现场会议中回答您关于Scrum团队所面临的挑战和情况的最紧迫的问题。这一章节主要关注IT和非IT团队的工作流程规范，并关注持续交付。

在本集《询问专业Scrum培训师》中，PSTs约翰·莱利而且本·索普回答有关有效调节工作流程和培养测试第一心态的问题。它们提供了对开始持续交付软件和非软件产品的实践和技术有用的见解。

成绩单

Lindsay Velecina (00:05):
早上好，下午好，晚上好，无论你今天在世界各地。欢迎来到今天的请教专业scrum培训师网络研讨会。今天我和约翰·莱利和本·索普在一起。他们在这里回答您关于Scrum的所有问题，并且很乐意帮助您解决有关有效调节工作流和开发测试优先心态的问题。同时，也乐于回答与Scrum相关的非软件相关行业的问题。希望今天能有一些很好的问题和很好的讨论。我是Lindsay Velecina。我是Scrum.org的，我将是你们的主持人。

Lindsay Velecina (00:51):
酷。好了。在我们开始之前，这里有一些简单的指导原则。所以，你可能已经注意到你的麦克风静音了，但是，这并不意味着我们不希望你问问题。这就是我们在这里的原因。所以请把你的问题输入到屏幕底部的q和一个框中。这段录音将在24小时内播出。所以如果你因为任何原因或者类似的原因需要离开，我们会为你提供一份录音。所以请开始，你们知道，填满你们的问题在我们看这些介绍幻灯片的时候。快速回答一下谁是Scrum.org? So we are the home of Scrum. We were founded by Ken Schwaber, the co-creator of Scrum back in 2009. Our mission is helping people and team solve complex problems through higher levels of professionalism.

Lindsay Velecina (01:49):
我们提供专业Scrum培训和认证，全球有超过340名专业Scrum培训师教授我们的课程。我们也有专业的scrum认证来帮助你验证你所获得的知识。我们也有很多免费资源我们鼓励你们在我们的网站上使用像这样的网络研讨会和学习路径。所以请随意查看这些内容，我希望今天的内容对你们的学习之旅有重要的帮助。下面有请John和Ben做自我介绍。

约翰·莱利(02:35)
谢谢你，林赛。大家好，不管你们在哪里。我叫约翰·莱利。我在美国俄亥俄州哥伦布地区工作。我只是想表达我的感激之情，感谢我能参加这个scrum.org社区活动，感谢大家对Scrum有如此多的兴趣，感谢我能看到你们如何有效地将它付亚博一百送一百诸实践。我是Ready Set agile的首席敏捷教练和培训师，我在2017年开始工作。我们只有一个想法，那就是快速获得反馈并对变化做出反应。这就是我们的使命之一，帮助团队理解自我管理的重要性以及拥有经验方法的重要性。这就是我的邮箱地址，如果你想给我发邮件的话。你可以成为我们社区的一部分，我将向你发送Sla亚博一百送一百ck邀请。

John Riley (03:40):
从2010年开始，我就一直在练习敏捷性。所以这大部分是在Scrum框架到位的情况下完成的。你看到的前三件事与IT无关。第一个是一个生产项目的scrum管理员。这就是他们的使命宣言。这就是他们的产品目标是发明一种革命性的建筑材料。是的，他们为此获得了资金。你知道，还有一些其他的事情你知道的，和一个营销团队做信用卡促销。你知道，那是非常有趣的，因为它主要集中在营销上，但不完全是，因为我们必须弄清楚我们如何与一些it团队整合。

John Riley (04:41):
我还与其他几个人建立了合作关系，帮助他们采用敏捷思维。另一项努力是帮助一家媒体制作公司提出DevOps文化，并弄清楚这意味着什么。我还积极参与帮助我们的年轻人和年轻人接受Scrum，并试图在我们的学校中实施它。你知道，一般来说，我就像一个导师，告诉人们如何做到这一点。下面是我的简历所有正式的东西。制造业背景，主要从事软件开发。我是软件开发出身，做了20多年的开发人员，但我仍然不时地涉猎代码。这就是我自己的一些情况。希望有一个很棒的会议，希望有一些非常好的问题可以回答。

本·索普(05:45):
大家好！我叫本·索普。我在这里用了一种视觉的方式来介绍我的个人简介。我曾经在一次面试中收到反馈说我的简历毫无意义。所以我做了很多事情，扮演了很多不同的角色。所以你知道，我是一个写代码的软件工程师。你知道，做了很多琐碎的事情，很快就意识到我真正的热情所在，就是创造一个能充分发挥人的优点的工作环境。因为，你知道，第一，这是正确的事。第二，当你拥有高绩效的团队时，它会创造，你知道，推动更好的业务结果。你们有良好的文化，有良好的合作。 And so I, I realized that that was really where my passion was.

本·索普(06:42)
所以我有点扭曲，你知道，我的软件工程背景，到这个方法。所以你可以看到，在我进入scrum社区后，scrum管理员和产品教练成为了scrum培训师，你知道，开始担任我的scrum管理员职位。亚博一百送一百我从来没有回到我曾经担任过的每个职位或角色，我以scrum master的身份出现，即使这不是我的头衔。你知道，所以我，这是，这是某种嵌入我内心的东西。所以，你知道，这真的是我的职业使命，无论我碰巧扮演什么角色，你知道，我在这里说的使命是，你知道，交付重要的产品，为客户服务，不断学习和试验，培养一种安全与合作的文化。我喜欢Scrum的地方在于，它是一个基于价值的框架，基于经验过程。所以，这也非常符合我自己的职业使命。目前，我是Ever Commerce在家庭专业服务公司的产品开发副总裁。这是一家SaaS公司，所以我在那里负责产品开发。我在那里支持那些品牌的产品开发。 So yeah, that's it.

Lindsay Velecina (08:02):
太棒了，谢谢。好了，现在是提问和会话的时间。请大家把问题填到q和盒子里。我会讲到这些。刚刚加入的同学麦克风静音了。所以如果你有问题，只要把它输入到q和方框中。如果你有任何技术问题，请输入聊天。所以我不分享了。好了，开始有问题了。这个问题是关于产品所有权的。 So do you have any suggestions to convince the product owner to maximize the value of the product itself and not try to maximize the utilization of the Scrum team? Who wants good one to meet that one. Go ahead, Ben.

本·索普(09:06):
是的，我不，约翰和我都在想，嗯，谁会，谁会先咬人?<笑>。是啊，这个问题很难回答。关于这个问题有一个敏捷的答案，你知道，但是我，我认为，这个网络研讨会是关于，你知道，关于如何应对一些挑战的实际的想法和想法。我首先想了解的是这个产品所有者目前是如何被激励的?根据我在很多环境中的经验，产品所有者实际上是被激励的，因为他们有一个可预测的交付过程。所以只要这种情况存在，你知道，产品所有者可能不会受到激励，也不会与组织中的价值联系在一起。产品负责人，在引号里，根据组织的不同可以有不同的含义。

本·索普(10:02):
所以他们不一定拥有Scrum框架里的东西，也就是产品所有者拥有实际的最终结果和最终价值。所以我想建议是一部分，帮助产品负责人理解角色。看看你是否能帮助与那些真正拥有价值的关键利益相关者建立联系。如果你是从scrum管理员的角度来看这个问题，你的角色之一就是在组织中向上和向外进行指导。你可以做的一件事就是在这个周围创建一些透明度。而且，你知道，你可以展示，你知道，与这些，那些关键的利益相关者一起工作，并问，嘿，如果这些软件开发团队更多地参与到价值声明中，会更好吗?但这并不是一个真正的答案。我很想听听约翰对此有什么看法。

约翰·莱利(10:57):
其实我很喜欢你的回答，本。我也想说同样的话。你知道，我指导过很多团队，从产品负责人的角度来看，他们的第一个目标是说，我想要团队的产出。所以我完全理解你的意思。当我在团队中担任scrum主管时，有时我所做的是，让产品负责人明白他们专注于什么，定义什么。我的意思是，花大量的时间来定义将产品待办事项列表项放在产品待办事项列表中的目的是什么。正如本所说，作为产品负责人，你的主要工作是使产品价值最大化，对吗?其中一部分就是要确定价值，对吧?对你的客户、利益相关者和用户来说，什么是有价值的?什么对你有价值，什么对团队有价值? What's going to help the team succeed into being the best self-managing team that they can? And, and really just start there, kind of separate the what from the how so product owner's all about the, what the self-managing developers are about the how so might not have better can something there. Yeah, absolutely.

本·索普(12:26):
所以你,正如你说的让我想到不同的方法定义价值,这你也,你知道,你可以开始推动一个,你知道的,更多的是,一个工厂,一个d交付,基于输出的团队向价值首先至少与每个积压项目刚刚开始,你知道,,,你知道,在scrum中,产品在项目具有某种价值声明,不要结束,必须是完美的,也必须是一个纯客户交付价值,但它对某人来说是有价值的。它可能是利益相关者的价值，你知道，它可能是这个东西对这个利益相关者有价值，即使我们仍然可能与最终的价值有些脱节。但这可能会让产品负责人开始思考为什么要使用这些产品。

本·索普(13:18):
对于scrum指南来说，另一个新概念是产品目标。而且，你知道，有不同的行业术语也被抛出，比如okr的目标和关键结果是另一种看待这个问题的方式。但是用scrum的说法，产品目标实际上定义了一个更长期的目标。因此，如果产品负责人可以提供帮助，可以与团队和利益相关者合作，开始定义这些产品目标，这也可以帮助他们联系到我们为什么要这样做?这有什么关系?你知道，我们所做的不仅仅是运送零件，我们正在把这个整体目标，你知道，希望如你所知，一些更大的目标，与客户价值或业务结果有更明确的联系。还有一些额外的想法。

琳赛·维莱西娜(14:09):
太棒了。谢谢二位。在移动。你能解释一下测试优先和测试驱动的区别吗?

John Riley (14:23):
我想我们会，我，我，我假设这意味着测试驱动开发和测试优先的心态。你知道，我，我，我就直接说这个吧。I, in, in，从它所谈论的原理来看，它们基本上是一样的。拥有测试优先或测试驱动开发的心态。重要的是要明白测试的是什么。那么，让我先从一个测试开始。心态的考验。第一种思维模式是关于本所说的从产品目标的角度来确定价值。你知道，这就是当你想到你的目标的目的时，开始思考，好吧，我们要如何测试它，对吧?我们要怎么测试这个目的? And that's what a test first mindset is, is basically saying actually Ben and I work with a guy at a, a bank here in central Ohio.

约翰·莱利(15:28):
在我们的改进过程中他会说，这很好，但是我们要怎么测试呢?作为开发者的我们会说，哇，等一下。好问题。所以这就是我所看到的测试第一的心态。测试驱动开发基本上与测试优先的心态是一样的，因为你写了测试，你看着它失败，因为没有代码来支持它。您编写代码以通过测试，然后根据您的质量标准对其进行重构。这就是我微分这两个的方法。本，还有什么要补充的吗?

本·索普(16:12)
总结一下，我们说的测试优先更多的是一种思考的心态，从始至终，有一个实验的心态，而测试驱动开发是一种特定的技术，用于应用测试优先的心态，但也可能更具体，它是一种非常特定的软件开发技术，你仍然可以在软件开发之外使用测试优先的心态。但我认为这是一个很好的总结。

琳赛·维莱西娜(16:46):
谢谢你的家伙。下一个问题来自詹妮弗。我所处的制造环境中，一些领导者想要脱离Scrum流程。作为一名scrum管理员，我不希望看到流程外倾。我认为Scrum已经足够精益了。你在其他公司看到了什么?

John Riley (17:09):
珍妮弗，非常感谢你的问题。由于我有制造业的背景，我很清楚你在说什么。关于Scrum，你必须知道的一件事是，它并不是很透明，但Scrum最初的开发是基于一些精益原则的。我假设你说的精益，指的是精益原则。也就是说，如果你想采用Scrum，作为Scrum管理员，我想让你花点时间想想为什么你想要Scrum，为什么你认为Scrum是正确的选择。如果你，特别是如果你认为它可以帮助你管理复杂性，你有一个复杂的情况，那么这可能就是你想要使用Scrum的地方。你知道，也就是说，我认为Scrum和精益是一个很好的方式，因为我的意思是，第一个精益原则是确定价值和映射，然后是映射价值流，你知道，在Scrum中，这就是我们所做的。所以需要一些时间来分析为什么Scrum是管理复杂性的正确方式。

本·索普(18:31)
是的，我，我的，这取决于答案，你知道，在这些电话中，可怕的答案，但我会假设，就像你说的，约翰，当我们说精益时，我想到的是，如果有人在制造环境中，他们想要减少浪费，如果有，如果有开销，这是，你知道，我在工作中一直看到这个。有一种观点认为，20年前，Scrum被认为是一个轻量级框架。今天，我确实听说，你知道，这是一个重量级的框架，或者它是浪费的，你知道，有所有这些会议。所以我认为重要的是要证明，每个阶段的价值，你知道，什么，你知道，冲刺计划阶段。这对我们有什么帮助?

本·索普(19:26)
这可以帮助我们在冲刺过程中集中注意力。所以我们都，我们都在一起做一件事，我们没有上下文切换。你可以把这些事情联系起来，如果人们理解精益，他们可能会理解，流的概念，你知道的概念，更多的结合的概念，你知道，你可以，你可以把冲刺审查联系起来，嗯，我们正在确保我们实际上在做正确的事情，通过频繁地让利益相关者参与。所以这看起来只是一个额外的会议。但从减少浪费的角度来看，我们的目的是确保我们不会等待，你知道，两三个月，以确保我们建造的是正确的东西。你需要，所以你可以，你知道，在回顾本身，你知道，你可能考虑的一件事是在回顾中把它带到团队中，嘿，我们的利益相关者或我们的管理层，你知道，我听到有人说Scrum是浪费的，或者，你知道，这里涉及的太多了。我们认为，我们实施Scrum的方式是否存在浪费的方面?日常开支太多了。把它带到团队中是scrum人员的常用口头禅。所以，你知道，不要害怕把这些直接带给团队，让他们参与解决问题。

琳赛·维莱西娜(20:50):
太好了。谢谢。下一个问题，我将要加入一个团队，这个团队的主要问题是在最后一分钟接收待办事项，将其包含在正在进行的sprint中。任何建议，以纠正管理这个问题是非常欢迎的。

约翰·莱利(21:11)
另一件我们作为Scrum大师或Scrum团队中经常遇到的事情，我将以指出敏捷原则之一的方式开始，即即使在开发后期也欢迎需求。我要问的第一个问题是，这是需要加入冲刺目标承诺的一部分吗?因为我们在Scrum中尝试并强调的一件事是，Scrum的目标，抱歉，是在sprint中始终不变的目标。然而，工作是可以改变的。首先，看看撒点，它和那个对齐了吗?如果没有，那么与产品负责人合作，看看我们如何将其放在未来冲刺的产品待办事项列表中。如果是这样，那么我会说，这就到了一个，把它带到团队的情况下，你会问一个团队，好吧，这是否与撒点一致?是的，但是我们怎样才能根据我们在冲刺中的位置来帮助我们实现目标呢?或者我们能从冲刺中得到什么?Ba基本上指导团队弄清楚这对冲刺目标意味着什么。 So, so that's kind of where I would start with it. Just knowing that the sprinkle is most important and the work is secondary. Anything I had to bent, John

本·索普(22:54)
偷了我的答案。所以我不得不手忙脚乱地想点什么。还有一件事，这个答案可能适用于很多现实世界中出现的问题。通常，你知道，以一种好斗的方式或一种抗拒的方式面对这些事情，你知道，当时感觉很好，对吧?因为这一点，我们知道，就像很多人在这个电话上理解团队的影响，不断切换环境，无法集中注意力，但其他人，他们可能看不到这一点的影响。所以我还建议让它透明。我喜欢在团队中做的一件事，你知道，这不是一个scrum指定的实践，但我想对所有的工作进行分类，你知道，所以你有不同类型的工作项目。

本·索普(23:50)
你可能有，你可能有一个bug，你可能有一个新特性，你可能，所以，你知道，你可以把工作分类。我总是把事情归为计划外。如果它进来,你知道,sprint在sprint计划和后,你知道,sprint是,你知道,开始后,你可以,你可以标签,标签是无计划的,只是有时候我仍然惊讶这一天简单的显示数据,嘿,这是一个,你知道,这是如何的最后四个sprint工作项类型的混合看起来,你知道,我们50%的工作计划外,你可以不去管它。然后，你知道，你可以开始谈论的影响，当东西进来，我们必须枢轴，它可以创造上下文切换，这产生浪费，你知道。但我认为一开始建立一个透明度是一个很好的方式来谈论你正在进行的关于发生了什么而不是意见之类的对话的影响。所以,

约翰·莱利(24:57):
我非常喜欢你给我的关于让计划外工作透明化的小建议，我要用它来分类

Lindsay Velecina (25:08):
<笑>,

本·索普(25:10):
我要收费的。所以。

Lindsay Velecina (25:17):
好的。所以我们要回到考试第一的思维模式。那么你能分享一些培养测试优先心态的技巧吗?这种心态对开发人员来说很有吸引力。

本·索普(25:38):
所以我可以谈谈我自己的旅程。至于如何影响开发者，你知道，这对我们所有人来说都是好运。你知道，真正优秀的开发人员有时也非常固执己见，这是有原因的。你知道，他们做事和不做事都有很好的理由，但这是一种肌肉，一开始并不容易。所以，就像其他任何事情一样，像其他任何实践一样最初有一个首字母s，你知道，卖。嘿，我，我想，我认为这是好处，拥有考试第一的心态，我认为这将帮助我们提高我们的质量。我认为这将帮助我们降低解决方案的复杂性，因为我们在编写这些测试时，就在发现和梳理解决方案，你知道，x, y, z有测试优先的心态的好处。

本·索普(26:45):
这里有几件事我们可以试试。我们可以开始写我们的验收标准，在一个产品后面的项目中，作为一个测试用例，你知道，这样你的验收标准就变成了一个测试计划。你知道，我用的词可能很吓人，但是你，你知道，你必须把一个P B I移到完成，你可以去接受标准，你知道，我可以检查这些东西，它符合标准。这是测试第一的心态，所以你可以尝试一下。做个实验。真正的测试第一心态是一种实验心态。你知道，当你做测试的时候，你要尝试一些东西，你还不知道结果会是什么。所以你，你创造一个假设，你进行测试，你检查结果，你检查和适应。

本·索普(27:38):
所以，这是一种非常科学的方法。这是一种有纪律的方法。当你使用d这个词时，当你使用纪律时，这意味着它确实需要练习和团队的一些承诺来尝试。所以这就是我的建议是做一个实验你知道，让我们，做几个冲刺，我们要尝试这些，这些东西，然后我们看看结果如何。最终，你知道，你把它交给团队，他们最终决定他们的做法。还有别的吗，约翰?

约翰·莱利(28:12):
是啊，我也可以和他们分享我的经历。这和本的实验很相似。当我还是一个开发人员的时候，我遇到了一个问题。我的第一反应是，好吧，我要开始在脑子里形成一个解决方案。我要直接去发展。我很快意识到，哦，我没想到这一点。哦，我没想到这一点。然后，你知道的，开始悄悄靠近我。然后我意识到，这个问题并没有很好地定义，所以必须不断地回溯并产生一个反馈循环，说，好吧，我们在这里需要做什么?然后我终于意识到，嗯，你知道，我们必须先弄清楚我们要怎么做这个测试。 And, you know, Ben alluded to an acceptance criteria. That's, you know, something we had to play with on some teams that I, where I was a developer, is to, you know, figure out what that acceptance criteria is.

John Riley (29:17):
因为正如Ben所说，这将成为您的测试脚本。如果你有一个良好的验收标准，这是一个很好的scrum实践，可以尝试看看验收标准是如何工作的。让你的用户故事透明，如果这是你正在使用的，检查和调整。这是个测试。第一种心态是提出一个测试脚本。我还将借用我在DevOps文化中学到的东西，并尝试保持持续测试的心态。你知道，DevOps的第一种方式是，你知道，强调，你的系统的速度和效率比你的小竖井更重要。所以，你知道，开发人员实际上必须走出他们的开发孤岛，开始思考这将如何影响系统的其余部分。但是，就像本说的，让它成为经验主义。让它透明，这样你就可以检查它，你就可以适应新的方式。 And as Ben says, I'm stealing his phrase again, chip away at it, it's gonna take some time. It, it will take a lot of iterations to be able to start to, you know, get that muscle, as Ben says, going.

本·索普(30:35):
另一个小建议，这是我在过去几年里开始做的事情，如果你在一个位置上，你是教练，你是教练的角色，不管你的职位是什么，你的工作是帮助提高你的团队的表现。我有一份关于类比的积压笔记，这听起来很傻，但我想把它简化成大多数人都能理解的东西，你知道吗?我在想，我做了一个项目，一个家庭项目，我把我们所有的地板都换成了硬木地板。这是一个大项目，你必须预先购买所有的地板，所以你必须把它做好。所以，你知道，我怎么知道地板是我想要的?

本·索普(31:30):
你知道吗?所以我开始了，好吧，地板需要和墙的颜色相匹配。好吧，你知道的，我没有去买所有的地板，选墙的颜色，我做了个测试，好吧，我去拿个样品。我要把它放在地板上。我要画一小块，用这个颜色的颜料，我要，你知道，确保这是我想要的。所以我做了个测试，你知道，第二个测试是我需要确保地板与地板的牢固程度。我不知道我在做什么。我以前从没装过硬木地板，但我做了个测试，测试的内容是，用我开发的这些新工具，把这个固定在地板上。所以，我的意思是，这可能不是最好的类比，但我认为，如果你的脑海中漂浮着这些东西，很多时候，这些指导是这些指导可教的时刻不知从哪里冒出来，你需要做好准备，你知道，如何走过它的心态部分。

本·索普(32:28):
所以。

Lindsay Velecina (32:31):
太好了，谢谢。下一个问题和整个话题有很大关系。所以它来自他和Jimena，我们在我们的sprint中使用用户故事。团队验证用户故事以确保它们符合invest(全大写的首字母缩写)。所以我们可能需要，我不知道你们是否熟悉它并且有一个接受标准。然而，出于某种原因，开发团队不想测试每个用户故事，并等待整个M V p。我认为这里有问题。你曾经遇到过这种情况吗?你是怎么找到解决方案的?

本·索普(33:22):
所以，我们必须在这种形式下做一些假设。是的。问题本身。所以，你知道，投资，这一点，你知道，只是为了其他人，在电话中，可能不知道，我要查一下这个缩略词，可能投资是，是一个缩略词，用来帮助指导一个用户故事的制作，你知道，投资。我忘记它们是什么了。也许我们可以分享一个链接

林德赛(33:53):
可评估，可测试性小，

本·索普(33:58):
格雷格，格雷格·波特。谢谢你，格雷格·波特，<笑>。谢谢，谢谢你，格雷格。是的，这是一个很常见的技巧。这对于创建用户故事是非常有用的，这是那些可以有价值的东西，它可以被交付，你知道，增量的，增量的部分。如果我得到的问题是，团队不想测试完整的用户故事。我说对了吗?

Lindsay Velecina (34:23):
是的。不想测试每个用户故事，

本·索普(34:26):
每个用户故事。所以最终，团队可能对他们的责任有不同的理解，而不是你。吉梅纳，你知道的，或者是领导层的人。所以我认为，你知道，这可能是一种情况，我们只需要重新调整团队最终的责任，也就是最终的价值交付。这意味着，你知道，我们交付的每一个部件，我们也对其质量负责。所以scrum对这个问题的回答是，完成的定义是这里使用的工具。所以也许现在，完成的定义不包括这个完整的，你知道，每个故事的完整的结束，端到端完整的测试，但是你可以随着时间的推移逐渐添加它。这将团队的责任扩展到下一件事。你知道，你知道，团队在每个产品待办事项列表指南中交付了功能齐全、经过充分测试的用户价值。但是，完成的定义可以随着时间的推移而扩大，增加责任，但这是一个艰难的定义。 Do you have anything, John,

John Riley (35:41):
我将从你的结尾开始回答。这就是完成的定义。我的意思是，scrum指南甚至说，我现在引用它，查找它。完成的定义是当增量满足产品所需的质量度量时对其状态的正式描述。所以我们在这里讨论质量，我的意思是，这是对增量的承诺。所以我想说，这是你应该关注的主要事情是你对“完成”定义增量的承诺。如果有特定的用户故事没有被测试，那么我会问，为什么它不意味着完成的定义?还是因为我们不知道，我们太优秀了，不适合在这个团队里测试东西?

约翰·莱利(36:35):
你知道，可能有无数的原因。我只是选了几个<笑>。但那是我想去的地方。我想说的是，我在用户故事投资的问题中听到的实践，所有这些都是对真正的事情的补充实践，这就是完成的定义。所以你知道，我首先会质疑，我们指的是我们产品的质量标准。我的意思是，Scrum团队有权做出这些决定。这就是我要开始的地方。

本·索普(37:12):
盾的定义就是从SoCo到Scrum，创造透明度，交付质量。作为scrum管理员，这是你工具箱里的关键工具之一，你可以创建真正专业的产品开发团队，交付高质量的投资用户故事，所有的验收标准。这些都很棒，但老实说，这些都可以写在餐巾纸上。这可以是一场对话，也可以写在一张卡片上，最终，真正重要的是最终产品的质量。你知道，这意味着团队真的要确保完成定义的质量。所以，是的，我只是在补充，加上想要你刚才说的，约翰。

琳赛·维莱西娜(37分58秒):
太好了。谢谢。我有个问题。对于那些想要进入Scrum但在IT环境中无法工作的人，有什么建议吗?

约翰·莱利(38:13):
好吧

琳赛·维莱西娜(38:15):
这是个很宽泛的问题，但是

约翰·莱利(38:17):
它是，

琳赛·维莱西娜(38:17):
你有什么可以分享的例子吗?

约翰·莱利(38:19):
是的，我的意思是，在我的个人简历中，你知道，我最近做的三个项目或产品都与IT无关。知道Scrum习惯于，你知道，通过自适应的复杂问题来产生价值，我会从那里开始。我会说，好吧，混战，对吧?对于这种情况，你真的有一个复杂的问题吗?我用的是我们在课堂上用的。我要么用Canvan图，要么用Stacy图，基本上就是用我的手臂作为坐标轴来测量。如果你对需要什么样的商业价值还没有达成一致，你知道，你不知道如何去做，那么你可能会处于一个复杂的情况。这就是我的出发点。然后从这里开始，找出你的产品目标是什么。

约翰·莱利(39:23):
你的任务是什么?你的愿景是什么?你为什么要这么做?从那里开始。如果你曾经作为scrum管理员参与组建团队，那么其他部分，你知道，就像组建团队一样，形成一个完成的定义，找出你的节奏和所有这些事情。所以你的事件有点像一个宽泛问题的宽泛答案，但这就是我们通常开始的方式，这就是我们开始的方式提出了一个革命性的建筑材料产品目标。

本·索普(40:00):
你有很多方法可以开始。我认为在这个问题上有不同的看法，也有不同的心态。有一种，你知道，让每个人同时下水的心态，你知道，每个人，我们一起做这个改变，这个大的改变，每个人都接受，我们立刻转向Scrum。有一种渐进的思维方式，你知道，我实际上已经取得了更持久的成功，这是我推荐的，特别是如果，如果你在一个不太了解Scrum的环境中，比如在软件产品开发之外，你知道，开始，有几个地方你可以开始。第一件事就是让作品透明。所以，你知道，把你的工作放在一个板上，如果你想成为conbon的学生，conbon可以是一个开始尝试的好地方，但要让工作透明并进入节奏，你知道，这样你就不必一次设置所有的Scrum事件并定义完成的定义。

本·索普(41:07):
而且，你知道，你不需要经历这种重量级的转变。你可以从小事开始，从每天的Scrum和回顾开始，你可以从这些开始，然后在你的回顾会上，你有机会说，好吧，哪里不顺利?你知道，我们能添加什么?我们真的需要让我们的主要利益相关者更多地参与进来。那我们开始冲刺审查怎么样?你知道吗?因此，如果没有广泛的认可或理解，你可以从那里迭代自己进入Scrum实现。

琳赛·维莱西娜(41:40):
好的。谢谢你！我只是想给我们的观众补充一点。我们正在尽可能多地回答问题。我注意到有些人正在进来聊天。如果你能把这些放到问答环节，这样我们就能更好地理解这些问题。谢谢大家。我很感激。下一个问题来自达芬奇关于估计的问题。那么你对Scrum中的评估有什么看法? Do you think that estimating using story points is a good way based on your experience?

约翰·莱利(42:23):
好吧,

本·索普(42:23):
这就是所谓的手榴弹问题。是的,是的。

约翰·莱利(42:27):
笑，这正是我所想的，本。是的，这个问题有很多复杂的地方，本和我已经讨论过了。你知道，当涉及到估算故事点时是很好的。你知道，任何不是绝对的，更多的是一个相对的估计，是更好的。让我来告诉你们我的意思。我们在敏捷中使用相对估计的原因是使用经验主义。所以，这是一种经验的估计方法。基本上，和这个已经完成的功相比，这个p项功和已经完成的第一项功的大小和复杂度相比是多少?好的，这是比较，对吧?是更多，还是差不多? Is it less? Right?

约翰·莱利(43:31):
关于估计，有一点需要了解的是，一般来说，我觉得估计是一种浪费。我这么说的原因是因为，我们正在努力实现冲刺目标，在我看来或者在我的感觉中，估算的行为更像是一种你想花尽可能少的时间并将其用于计划的活动。对于这个P B I，我们能把它放到一个sprint中吗?差不多就是这样。你可能听说过“没有估算”这个标签。如果你能查一下，这就是我们在这里讨论的内容。所以，故事点是可以的。我尽量避免让团队使用尽可能多的指标，但你必须逐渐减少。本，还有什么要补充的吗?

本·索普(44:37):
因为我们是在scrum.org网站上，所以我将从scrum指南中截取内容。调用。这是在支持你说的话，约翰。存在各种各样的实践来预测进度，比如燃烧上升，燃烧下降，或累积流量，这些都被证明是有用的。这些都不能取代经验主义在复杂环境中的重要性。将会发生的事情是未知的，只有已经发生的事情可以用于前瞻性决策。所以估计部分是有用的。我们所追求的是让它成为经验主义的，基于我们已经学到的东西，你知道，从我们的过去。作为一种技术，估计的行为是有用的，因为它让团队成员，你知道，围绕着报价表。然后深入挖掘一些细节，完善它。

本·索普(45:36):
所以当一个团队尝试做一种纯粹意义上的估算练习时，会有很多有趣的发现。我也同意约翰的观点，从纯粹意义上来说估算就是浪费。它对产品开发本身没有直接的贡献。所以团队需要把它作为一种有用的，有用的浪费。我不知道这是不是矛盾修辞法，但可能很有用。但这是我们需要研究的东西，确保我们没有花太多时间试图，你知道，水晶球凝视。这里有一个，嗨，问题下面还有一个问题。也许我不想做太多解读。这是如何，如何我们如何分享我们的评估我们的利益相关者，或者组织如何使用我们的评估来预测团队绩效测量?这完全是另一个网络研讨会。 But the, the, the core answer here is this is used by the team internally to do forecasting and, and work refinement, so.

Lindsay Velecina (46:48):
太棒了。谢谢你！下一个问题来自克莱尔。我想可能其他人也有同感。在我工作的团队中，产品负责人被分配了太多的项目，太多的工作，所以我们的团队一直在挣扎。有什么建议吗?如何解释并说服管理层相信产品负责人的时间的价值，而不会对这个极具价值的人产生负面影响?

本·索普(47:23):
<肯定> ?我重申一下这个问题。是具体围绕产品负责人有太多的项目和太多的工作，所以我们需要说服管理层，产品负责人需要更多的时间花在他们的产品所有权职责上

Lindsay Velecina (47:39):
时间的价值，

Ben Thorp (47:41):
产品所有者时间的价值?当然,是的。是的，这是一个，这是一个艰难的问题，我经常看到产品负责人非常忙。你知道，他们可能每周只有几个小时和团队在一起，而且除了核心的scrum团队活动之外，他们还有额外的责任。所以我将给出我的，我将，我将给出我的某种现成的答案，我将，也许约翰有更好的想法，如果可能的话，让它透明。所以你可以分享这些发现，你知道，从回顾中得到的发现，你知道，我们可以说，我们，我们需要产品负责人的时间，但我们，我们不能，因为她太忙了。这导致我们有很多返工，我们有工作项目，这是你可以开始引入一些精益和结合指标的地方。

本·索普(48:46):
在等待产品负责人审查的过程中，我们的工作项目已经持续了5天、6天、8天、10天。你知道，你可以捕捉到所有这些。这是你可以捕捉到的数据，并向上呈现。所以我们需要，你知道，所以我认为在这个问题上要透明，有数据，如果有任何数据，如果有数据，如果有产品所有者的全面参与，情况会有所不同吗?抱歉，如果这是一个一般的答案，这是一种，这将是一个我们需要在喝咖啡时深入研究的问题，我想。

约翰·莱利(49:23):
太好了。是的。是的。本，你，你，抱歉，琳赛，说吧。去做吧。不，我只是想说本这次偷了我的答案。你首先要做的是让它变得透明，对吧?为了补充本的回答，我还想提出一个事实，你知道，接触转换实际上对任何团队都是非常不利的，在你转换的地方，转换团队在转换环境。事实上，如果你在一个领域工作50%，在另一个领域工作50%，你实际上在每个领域都减少了20%到25%。所以实际上你在每个领域只有25%到30%的效率。 So, but that's, make that transparent and know we're definitely bringing up in a retrospective.

Lindsay Velecina (50:25):
好吧，这个问题，又是一个很宽泛的问题，但我认为你们俩也许能提供一些很好的建议。那么，如何激励一个经历了艰难时期的团队呢?

本·索普(50:48):
我敢打赌，我不想这么冒昧，但我敢打赌，在过去的18到24个月里，我们很多人或大多数人都有过这样的经历。

琳赛·维莱西娜(50:58):
绝对的。

本·索普(51:00):
这段时间对我们很多人来说都很艰难。你知道，我亲身经历过。我们所有人都有自己的2020年故事、2021年故事、大流行故事，你知道，我们仍然在努力提高效率。我们在家工作。所以我认为，如果你处于一个职位，再说一次，不管你的头衔是什么，如果你处于领导的位置，最重要的是要有同理心，真正理解团队中个人的困境。这不是你的工作。不管是在Scrum中还是在Scrum之外，谁都没有责任去解决一个人的问题。所以作为一个领导者，你需要有同理心，理解正在发生的事情。所以，这就是我的，希望这不是一个过于肥皂氧的答案，但这就是我所欣赏的，当我自己经历一些斗争时，你知道，如果领导是理解的，所以我认为只要有空间，你知道，在艰难的时期有斗争是可以的，只要有空间。

本·索普(52:14):
第二个答案，利用框架，利用scrum框架。不要放弃回顾。你知道，使用你的回顾。我知道，在这个行业中，我看到过，回顾已经变得非常机械。它们变成。我们必须生成我们的动作项。你知道，回顾是没有用的，除非它生成一个行动项目。我们总是，你知道，积极行动，不断改进，这很好。但回顾还有另一个目的，那就是释放阀门。而且，你知道，对于那些可能正在经历一些艰难问题的团队来说，这也是文化建设，特别是如果你在一个分散的团队环境中，人们不会亲自见面，你知道，有这种人际关系可以让一些艰难的时刻，你知道，更容易度过。所以我真的会说，你知道，花点时间在那些回顾上，并且使用，我想我会做一个2.2点B的答案。 Use the framework, you know, clear goals. The product goal is great. I was, I was so excited about that. Addition to the scrum guide, ambiguity is the enemy. When it comes to being in, in a tough time, people need some clarity. They need, they need to be able to focus on something. So, you know, leverage the framework, define, you know, work with your product owner, define the goals, have real clear, you know, concise sprint goals and, and so that people can, you know contribute. So, sorry I went a little long there, John.

约翰·莱利(53:54):
回答得很好，本。为了补充本所说的，我实际上正在看一些关于这个的数据，你知道，我们现在正在进行的大的工作狂热。在一个网站上，人们辞职的首要原因就是他们没有受到赏识。你知道，真的没有多少其他的东西能达到顶峰，但这是第一件事。而且，你知道，作为一个领导者，你可以做的一件事，就像本说的，帮助一个团队度过艰难时期，就是告诉他们他们是多么感激。有同理心是非常重要的。你知道，就像本说的，利用那些回顾，你知道，尽你所能地利用它们。我最近一直在研究一些关于回顾的自由结构，它实际上是非常有效的，你知道，嘿，好吧，让我们看看产品目标。

约翰·莱利(55:08):
让我们看看我们是如何进行冲刺的。但也有一些其他的东西出现了。你知道，如果你因为任何原因分成小组，你走到一起，你开始看到一些共同点你知道，就像，嗯，我们筋疲力尽了，你知道，那些时候你真的，有原因，为什么回顾是你和团队在一起，通常是在一个封闭的房间里。花时间，让它变得有效，我们能做些什么来让公司满足我们的需求，让他们知道我们在这里做一些重要的事情?我们在做很多艰难的事情。让它变得透明，把它带入你的冲刺计划中。那是，那是我要开始的地方。

Lindsay Velecina (55:56):
太好了。非常感谢。我觉得这是个很重要的问题。我们还有时间再讲一个。我看到很多人通过聊天请求回答他们提交的问题。我要从头到尾看一遍，我要选出能回答多个答案的问题。但在这之后，我将和约翰和本分享所有的问题。这样他们以后就可以和你讨论这些问题了。所以别担心，你的问题会有答案的。只是可能撑不过这次会议。 So this last question here it hits a few that were asked that are similar. So what's the best way to facilitate a team through scrum sprints where they do not really know how to use Scrum or not very well? Should we train people first or try to teach as we go? And this question is for non-developer teams, and there was a similar question that came in for non it.

约翰·莱利(57:11):
所以，如果我理解了，请正确地纠正问题，请插话。我认为这实际上是关于采用Scrum。我们应该先进行训练，还是应该，你知道，你知道，有点对，对。顺其自然吧。学习

琳赛·维莱西娜(57:27):
比如，我们如何，如何让这些人跟上进度?

约翰·莱利(57:34):
你知道，作为一个Scrum培训师，我总是会说，是的，你需要<笑>。我的意思是，这是一个简单的答案。你知道，这就是说我，你知道，这是关于最大化那些需要学习Scrum和实践的人的价值。Scrum。就像我说的，从2010年开始，我就一直在练习Scrum，而且我每天都在学习一些东西。你知道，也就是说，加快速度是，真的是一个广义的术语。我将使用我过去使用过的方法来组建，风暴，规范，执行组建团队并且能够通过他们现在使用的任何过程来进行机械的混乱，这可能是一个很好的开始方式，如果你决定不进行培训。我的意思是，我喜欢APS课程的一点是，我们把冲刺付诸实践，我们允许你做案例研究，你知道，你可以练习scrum。

约翰·莱利(58:43):
在第一次冲刺中，最重要的部分是要意识到价值是最重要的，我们所提供的是最重要的，因为我们产生了反馈。所以，你知道，即使，我的意思是，我培训其他，其他团队来交付一些小的东西，因为你要做的是试图与你的利益相关者建立信任。即使它只是一个hello world应用，这也很重要，因为它们会给你反馈说，嘿，你交付了一些东西，它有点没有价值，但你交付了一些东西。而不是，哦，我们现在要进行几次冲刺，却一无所获。对吧?你与利益相关者真正建立了什么样的信任?所以组建团队，开始推广你的产品，从那里开始学习APS课程。

Lindsay Velecina (59:40):
<笑>。

约翰·莱利(59:43):
好的。

本·索普(59:43):
是的，我想在约翰的回答中补充一点，就是创造，找一些盟友。所以你不想像一个孤独的战士一样进入一个变革管理变革的环境，你知道吗?所以找一些盟友，找一个赞助人，你知道，一个处于领导地位或相应职位的人，你知道，建立这样的关系。这可能是一个开始训练的好方法，即使你开始训练是一种很棒的方式。的确如此。即使你不知道，这也不是，你知道的，试图推销。如果你想把你自己的训练整合起来，你知道，训练很好，但是进行一些开始训练，然后才开始，那就会感觉很机械。你用了一个很棒的词，约翰。一开始我们会觉得很机械，有点走过场，就像你在学习空手道或跆拳道一样，你要走过场，直到它成为你的第二天性。所以,

Lindsay Velecina (60:39):
太棒了。非常感谢二位。所以我们在我们的时代。还有许多未解之谜。谢谢大家的耐心等待。我试着跳了一下所有这些都将被分享，就像我之前提到的。所以我们会想办法解决所有问题。非常感谢约翰和本。我觉得这次会议很棒。我希望观众们，我希望你们都能从中学到很多。 So as always, we encourage you to continue your learning. So please check out the free resources on our website and feel free to reach out to Ben or John with any lingering questions that you have. And I hope you all have a great rest of your day or evening and scrum on.

本·索普(61:42):
谢谢,林赛。谢谢你约翰。谢谢

约翰·莱利(61:44):
你,林赛。谢谢大家。

本·索普(61:46):
再见。