请教专业的Scrum培训师——Jay Rahman——领导力等等!
Scrum作为复杂产品上有效团队协作的简单框架已经存在超过25年了。虽然它是轻量级的，易于理解，但它可能很难有效地应用。在Scrum.org上的“询问专业Scrum培训师”系列中，专业Scrum培训师(PSTs)将在现场会议中回答您关于Scrum团队所面临的挑战和情况的最紧迫的问题。
在这集《询问专业Scrum培训师》中，PST杰伊•拉赫曼将回答您迫切的Scrum问题以及与领导力相关的话题，包括:
-定义敏捷领导者
-Scrum Master提示
产品的所有权
回顾技巧
——!
成绩单
林赛Velecina:
欢迎来到Scrum.org社区播客，这是一个来自S亚博一百送一百crum之家的播客。在本播客中，我们将邀请专业Scrum培训师和其他Scrum实践者分享他们的故事和经验，以帮助学习他人的经验。本集是我们现场提问专业Scrum培训师系列的先前录音，现场观众向专业Scrum培训师提问。希望大家喜欢本期节目。早上好。下午好。晚上好，不管你今天在哪里。欢迎来到今天的PST提问环节。我是来自scrum.org的Lindsey Bella Sina。今天，我请到了j·拉赫曼。 And he is going to field all of your questions today about agile leadership and any scrum questions that you have as well. So let's get started. And just a little bit about scrum.org. We were founded by Ken swaybar, one of the CO creators of Scrum back in 2009. Our mission is to help people in teams solve complex problems. And we do that through professional scrum training, certification and also ongoing learning experiences. And this webinar is just one of those free ongoing learning experiences that we offer. So please be sure to check out all of that on our website, we always want you to continue your learning beyond the classroom. And with that, I'd like to kick this off to Jay, one of our Professional Scrum Trainers. And he can introduce himself and kind of set set the stage here for the q&a, and we'll get rolling with questions.
杰伊·拉赫曼:
很好，谢谢，琳赛。我叫杰。我是一名博士，分形系统的创始人。我们是一家敏捷咨询公司，诞生于目睹了许多敏捷实施和转换失败的挫折之中。我们的目标是帮助公司建立真正有效并交付的敏捷能力。所以我们不仅仅是培训师，我们还是积极的实践者，在产品领导和工程方面与公司合作。哦，我们还整理了一个5分钟的记分卡，帮助人们了解他们在敏捷交付中所处的位置。如果需要，他们如何改进。屏幕上有个链接。所以请大家去看看。 And do let me know how you think. Well, how it goes for you. Super happy to be here and answer some of your more pressing questions. Lindsay over to you.
林赛Velecina:
好的。太棒了。所以我要停止分享了。好的。那就是我。好了。好的。让我们从一个相当基本的问题开始。那么什么是敏捷领导者呢?
杰伊·拉赫曼:
这是个很好的问题，琳赛。因此，我们将敏捷领导视为创造团队和组织蓬勃发展的环境的艺术和科学。敏捷领导者建立紧密的协作，关注快速的组织和团队学习。我认为他们还关注持续有价值的交付，实际上是让组织或他们的团队实现公司的使命目标。我认为敏捷领导力是最简单的理解方式，它通常由去中心化命令、基于意图的领导力、去中心化执行和仆人式领导力等方法来区分。当你谈到领导力的时候，你已经看到了所有这些关键的短语。
林赛Velecina:
太好了。这就为大家准备好了有问题请提问。请让他们继续参加问答环节，那就太好了。这个问题。所以只有那些能给客户带来价值的东西才能计算到速度，你能为维护任务创建估计的用户故事吗?
杰伊·拉赫曼:
对不起，再说一遍。
林赛Velecina:
Demetrio的问题是，只有能给客户带来价值的东西才算速度。您能否为维护任务创建估计的用户描述?这更像是一个开发者类型的问题。
杰伊·拉赫曼:
所以我不担心速度是一个很好的计划工具。所以当你想知道你的团队能够在一个特定的sprint中交付什么时，这是一个很好的历史衡量标准。但是我不会担心，我不会太担心速度，我想的是，我们需要集中精力完成的工作是什么，我们如何释放有价值的增量，如果有工作或额外的工作，这不是，你知道，这可能不是一个非常简单的工作，客户会看到，但对于交付来说是必要的。在你的估计中一定要考虑到这一点。这对我很有帮助。
林赛Velecina:
好的。谢谢。工资。敏捷领导者常犯的一个错误是什么?
杰伊·拉赫曼:
所以这里实际上有一个视图。我认为，当涉及到高压力时，敏捷项目和交付，战略交付，有时我看到的是，我们倾向于看到的是敏捷领导者没有考虑到学习曲线。所以你有一个1000人的组织，再加上开发人员，甚至500人，甚至30人。开发人员从来没有这样做过。他们有明确的目标或者重要的战略目标需要去实现。领导团队不会考虑，我们的员工要学会如何做到这一点需要付出什么代价?你知道，他们会犯什么错误?我们如何计算出倒退呢?我们将如何管理周围的挑战你知道团队将如何互动，联系和学习，所有这些事情往往没有被考虑到，他们只是假设这是目标。我们要采用敏捷，用一半的时间做两倍的工作，我们一定能搞定。 So just looking at the realities and thinking about what, what the teams need to do to shift towards that new way of working. It's important to ask. Okay,
林赛Velecina:
谢谢你！好的。所以这个问题说我们有不止一次的小雨，抱歉，是现实。我真的在努力把每天的会议从状态检查转变过来。让它朝着冲刺目标前进。人们真的倾向于报告任何提示，谢谢。
杰伊·拉赫曼:
所以日报最重要的事情是考虑到每天的混乱，问题是关于Lindsey的。
林赛Velecina:
是的，它是在询问关于日常会议的问题。是的，有点从状态检查转向真正检查冲刺目标的进展。
杰伊·拉赫曼:
真该好好感谢你。看待每日Scrum的方式是，它实际上是一个风险管理事件。所以提供一个状态,提供一个状态不可能或不可能是有益的对MT管理这种风险,但如果你如果你靠近它,这是我们做的战术风险管理在每天的基础上实现我们冲刺目标,然后会影响sprint的交付目标是什么会出现泡沫,这将把你的每日例会。我们已经这样做了，你知道，我们在很多很多团队中都这样做了，但最重要的是，在经理和领导团队中，因为领导团队不想参加每天的会议。这只是状态检查。他们要做的就是管理交付过程中的风险。因此，如果你从这个角度考虑，这可能会改变你与团队在日常scrum中的互动方式。正确的。
林赛Velecina:
这是个好建议。每日例会不是一个状态会议。下一个问题。所以scrum指南没有提到管理者，那么管理者在scrum团队中有位置吗?
杰伊·拉赫曼:
那么，经理在scrum团队中有位置吗?这是个好问题。我看待这个问题的方式是，我们的经理，帮助scrum团队实现目标，如果他们没有，那么他们有一个位置，你的角色是什么并不重要，你知道你的正式角色是什么吗?但如果你实际上。如果你是团队的一员，你在帮助实现目标，你在推动目标前进，那么是的，绝对是。管理者本身，在组织中有一个重要的位置，他们的目标是帮助团队消除摩擦。所以一个团队在交付过程中可能遇到的任何挑战可能只是一些平凡的事情，比如没有技能或需要技术上的东西，解决这些问题以消除摩擦，帮助团队真正向前发展。他们不是来打球队的。好吧?这是一个非常重要的区别。你不是去鞭策团队，让他们一天工作18个小时。 That's not what a manager's role is, the manager's role is to eliminate friction. Their role in the scrum team is there specifically to help them achieve achieve the goal. So if you're there to help the team achieve a goal, that's great.
林赛Velecina:
好的，很好的建议。谢谢你！当然。这是我们经常遇到的问题。那么，您如何从处理工作的方式上解释Scrum和敏捷之间的区别呢?所以，这一直是一个有趣的问题，因为Scrum是一个敏捷框架。所以如果你想解释的话，
杰伊·拉赫曼:
当然，敏捷就像一个涵盖了各种框架的总称。所以你有像DSDM km这样的东西，所有这些都是敏捷的形式。Scrum是一个特定的框架，它有自己的规则。这就是失败的方法。它实际上是敏捷的一个子集。这就是我看待它的方式。是的。这就像说，你能解释数学和几何吗?数学是一个总称，对吧?是啊，只是，我确定我已经搞定了。 Right.
林赛Velecina:
是的。完美的。这是一个关于领导力的问题。领导层应该参加每日例会吗?这种影响会影响心理安全吗?
杰伊·拉赫曼:
所以，首先，我认为领导者不一定要参加每天的会议，如果他们想要参加，如果他们想要倾听，我不认为这有任何问题，我们已经有了我们的领导团队。但是，如果scrum主管认为心理安全会受到影响，或者团队会感到害怕，那么我会劝阻。用外交手段向当权者说出真相是件好事，或许还可以向领导团队解释，嘿，让你在这里让人害怕，我们需要想办法让他们安全。让我们一起努力吧。让我们开诚布公，共同努力。这就是我们需要做的。这都是关于合作的部分。对吧?正确的。大多数团队都不习惯让领导团队进行交流。 But if you're doing it right, having a leader turn up, makes no difference whatsoever. Teams should be okay to talk about what's going on what's really happening and be transparent in their in their approach, it shouldn't make a difference. That's the ideal.
林赛Velecina:
对吧?说到领导力本身，这是可以教的吗?还是说这是与生俱来的?它的存在吗?你对此有什么看法?
杰伊·拉赫曼:
那是，那是我们都不是自然吗?的问题。我们已经，我们已经看到，伟大的领导能力被教会了。我的意思是，大多数人不会有一天醒来就成为伟大的领导者。这个想法是，你需要学习一套特定的技能，练习心态。你必须不断练习这些行为，直到它们变得次要和自然。另一件事是你需要能够在正确的环境中部署正确的行为。这需要练习、训练和时间。所以我们总是鼓励，我们总是，当我们与领导者合作时，我们确保他们受过训练，对自己的知识有很好的理解。有指导，这需要发生。 And that that helps them helps leaders operate in real time. So when they're working with challenges and stuff, a mentor will help them figure out what is the right way forward, and execute the behavior that there needs to be that need to be doing. And then finally, there's the coaching piece where a leader has the necessary skill set. They know what they need to do, and they kind of need a coach to help them really kind of finesse it. But those those three approaches, absolutely help leaders develop, and they develop wealth.
林赛Velecina:
太好了，谢谢。对于在座的观众，我想说一个简短的PSA，如果你在聊天中输入问题，你能不能把这些问题移到问答环节，这样我们就能记录下来?那太好了，谢谢。好，下一个问题。所以它来自亚洲。我是Scrum的新手。但是我很快就会转到scrum master的角色，我明白评估应该由开发人员来完成，鉴于他们拥有决定如何完成工作的专业知识，然而，当开发人员进行评估时，是否建议产品负责人在场?
杰伊·拉赫曼:
所以有很多所以我会建议产品所有者当开发者在做那种事情的时候。这主要发生在两个地方。要么是细化，所以不一定是事件。但这绝对是必须发生的事情。我们发现，改进对于质子向开发人员、工程师和团队解释我们试图构建的是什么，以及为什么要构建，是绝对关键的。它是一种背后的假设，好东西是什么样的，诸如此类。所以开发者也可以在这一点上进行估算。问题是，在产品负责人在场的情况下进行评估，要做两件事。首先，它确保工程团队或开发团队真正理解开发人员必须真正理解他们正在构建的是什么。最重要的是，产品负责人也开始理解构建一些东西需要什么。 So I always I always recommend that when you're doing things like that. Make sure the product owner is present.
林赛Velecina:
是的。这是个好建议。所以当组织文化非常传统的时候，括号里写着，无错误政策。
杰伊·拉赫曼:
注意他们的政策。是的,对的。对的
林赛Velecina:
每个人都以结果为导向。scrum团队该如何处理这个问题呢?
杰伊·拉赫曼:
所以，问题是，这是直接的吗
林赛Velecina:
面向结果的?我的意思是,
杰伊·拉赫曼:
直接结果导向。好吧?他们马上就要。是的,是的。100%理解。我们在金融服务领域工作，我们在金融服务和金融科技等方面做了很多工作。这种文化非常普遍。对吧?正确的。没错，几乎所有的政策都是可以的。 It's not a it's not a tell the future policy. Right. So when you speak to senior managers today, if I came along, and I gave you a plan with no contingency and budget or time, what would you say to me? I've always had, I've never had anyone say, Oh, that's great. Let's do that. I've always had somebody come back and say, Look, you can't tell the future, where's your contingency planning? Where is all of that stuff? Okay. So we can use that approach. So when you're speaking to management teams, and when you're thinking about building out gold, Scrum teams, managers, project managers, no one knows how to tell the future. And that's that that's the lovely thing about Scrum, and agility, we start with that with that foundational piece of knowledge. And we accept that from the beginning from the get go. So whenever we're kind of thinking about building stuff, it's really important that when we do estimation, or when we when we're giving, when we're talking to leadership teams about what it takes to deliver something, we're talking about a roadmap that we don't talk in absolutes. Most importantly, we found an approach that works for us is that we talk in terms of probability. So we'll say, Hey, this is the this is the roadmap, we think we're going to deliver, you know, this widget by June and the probability of us doing that is around 75 80%. So there's a 20% wiggle room, right? And what we're actually communicating, so there's a risk there that we're not going to deliver, right, we're putting because we can't tell the future. And leadership teams, good leadership teams understand that they they understand that risk management is part of the game. So when you're doing that, you can then figure out and you can find ways for the teams to communicate some variance in the in the actual delivery, and that there's going to be a bit of a fudge factor. And that's okay.
林赛Velecina:
太好了，谢谢。这些问题非常广泛，而且在地图上无处不在。不过这很好。谢谢大家提出问题。这是带他们来的好地方。那么，你如何让开发人员自愿承担工作，而不是把工作强加给他们呢?
杰伊·拉赫曼:
但我是前开发人员。所以不仅仅是开发者，没有人想被告知做这个或做那个?正确的。所以我认为问题是，一个很好的方法是在复古的时候谈论它。所以你有一个回顾，你说，嘿，伙计们，我们要如何我们要如何合作?所以十有八九，如果你如果你有组建一支团队的机会，你是对的，在开始的时候，你可以想出并建立一个团队章程。那么这些值是什么呢?我们将如何互动?对于那些我们不想做，也没人想做的事，我们该怎么办?我们要怎么做呢? What is the way that we're going to work together to deal with those sorts of things? And guys, do we really want to be the kind of team that? You know, the manager says, Hey, you're going to do this? And he's going to do that? Is that? Is that how we're going to play the game? Or would rather work as a unit and try and figure out, okay, some days, I'm going to pick up the great stuff, sometimes I'm going to pick up the other stuff, and we're going to work together to get the goal done. Ultimately, if we deliver as a team, if the team wins, we all win. Right? So that's, that's where I'd have that conversation. The retrospective is the best place for it.
林赛Velecina:
好了,好了。这就是倒车的作用。下一个问题来自珊德拉。我们如何衡量scrum团队的成熟度?scrum管理员应该如何改进它?
杰伊·拉赫曼:
你如何衡量一个scrum团队的成熟度?这是个大问题。这是个很大的问题。有一些有一些你可以做的事情。最重要的是弄清楚成熟对你来说意味着什么?我发现那些刚接触scrum的团队并不真正理解实践。他们不理解框架。他们不明白为什么。为什么我们要做倒车为什么我们要做每日扫荡?这到底是什么意思呢? And we talked early on about risk management as being a fundamental tenant for the daily scrum. So we were working with an asset manager in Georgia, we had the CFO as part of that team, that leadership scrum team. And we had to explain to him why would have him turn up to a retrospective. So he's saying to me, Look, Jay, I'm managing. I'm the CIO for the bank. Why do you need me here? And the question was, well, the answer was, Well, look, it's the risk management exercise. How is your leadership team performing? How are you going to help them? Do you understand why that's important? Can you see why that's important? It was like What if his risk management I'm going to Aviva. So, those sorts of things are fundamental things, right? So when, when a team is at that fundamental level, you want to be making sure that they understand why they're doing Scrum. Why are they doing Agile? Why are the the events are important? Why, you know, why are the roles and responsibilities and the accountabilities? Why are they there? They should they really should understand why. Okay? When teams move from that kind of basic view, so they understand the framework, they're executing it well, and we start to think about things like, definitions of done, are we releasing value? Are we picking up work automatically? When challenges come along? Do we wait for the scrum master to turn up? So when I was working? Yeah, I was working with a brand new team in a financial firm. And I came in one day as a scrum master. I came in one day, we had a desk move. I come in, and no one has moved. What had happened. The developers were sitting around going, are we waiting future? While we wait for me? Oh, well, we lost the Destiny plan. Right. So no one decided to go and ask anyone where the plan was, or you just wait for the scrum master to stay out? Right? Yeah. And that was a brand new team, they hadn't thought about self organizing, or self healing or fixing their own problems. They were like, we're just going to wait for the scrum master to rock up and tell us what to do. So that's a new team, right? A more self organizing team will be thinking about, okay, we don't need the Scrum Masters sort this out, we can figure this out ourselves. And you'll start to see them self organizing, fixing problems, fixing challenges themselves, nine times out of 10, if you're doing it right, when a team is really cooking with gas challenges will come and disappear and problems will be eliminated. And the scrum master won't even know about it, it will just happen. Because the team will be self organized and knows the kind of work on that kind of continuum. The most important thing for a scrum master to do is to be consistently observing how the team is doing and how they're dealing with challenges and problems, as well as how they're executing the framework. Are they doing it? Well, I'll be getting every out the door, or we will be working with the product owner? Well, do we understand what it is we're building? You know, how is that predictability? How do we deal with challenges? Those are the kinds of things that a scrum master should should be doing, observing and intervening when they need to? Right. I was trying to make that really big question.
林赛Velecina:
是的。那，那太好了。我希望这回答了你们的问题。Shandra。如果你有什么问题，请在这里的问答中提出。所以下一个问题，我认为这对你来说是一个机会，杰伊，思考一个你可以分享的故事。也许你也可以从领导的角度来看。但是，要成为一个成功的scrum团队，我们可以实施哪些具体的步骤呢?
杰伊·拉赫曼:
要成为一个成功的scrum团队，我们可以实施哪些具体的步骤?是的。这是个好问题。我认为我认为最重要的事情是真正理解实际上，作为类型问卷的一部分，你能做的最重要的事情是真正理解你为什么要做敏捷，你想用敏捷实现什么，对吗?那么，scrum如何适应那些非常非常擅长scrum的人呢?那么，通常会发生的是团队会非常擅长解决局部问题，基于团队的问题会很快得到解决，因为你更强大，然后会发生的是团队会开始对抗有机领导层，对吧，管理层，上层领导层。这就是团队可以开始影响领导者的地方，帮助他们弄清楚他们需要做什么来帮助支持你作为一个团队，以及如何推动你前进。我们在做一个很棒的故事，我们和一个量化团队一起工作，几年前，就在COVID之前，实际上，我们在帮助那个团队，有大约50个男孩和女孩，非常聪明的人，博士，绝对，就像合法的火箭科学家，这些人是地球上受教育最多，最聪明，最聪明的男人和女孩。你知道，他们管理着很多钱。所以我们发现，我们必须帮助这些家伙和女孩，这些团队，很好地协调，交付，交付价值，交付产品，最重要的是，管理好他们管理的资金，做好这些并降低风险。 What happened was was when those teams started to manage and fix all of their local problems, all the interrelationships and all those sorts of things, they would have other challenges that they couldn't resolve. And so the managers need to step in. Now in financial firms, managers tend to be quite command and control. And so we had to help these guys learn a different way of of helping their teams instead of, you know, carrot and stick. It's more about what are the frictions that you're dealing with that I can help you eliminate? You know, leaders have a massive, massive responsibility. And they're also under a massive amounts of stress and pressure, right, so they don't always have the time to fix everything. The lovely thing about Scrum is that reduces their time. It reduces their management time because the teams will only come to you when they've got a challenge. What these guys were doing is that they were finding ways them to instead of telling teams what to do was to assisting and supporting teams in eliminating the frictions that they were facing. So they will just get quicker and quicker and faster and faster. And some of the great things that came out of that was that the teams pretty much doubled their productivity, so that any kind of goals that they had to achieve that achievement quicker, most importantly, they were their decision making the decision cycles went down. So when you're managing, say, 25 billion, right, and you really need to think through how long things take. It will take sometimes three to six months for them to come up with a decision. We've got that down to days and weeks, just because the operating better, communicating better, and all those sorts of things. That's great.
林赛Velecina:
这是个很好的建议。是的，听到一个真实的故事来解释它总是很好的。
杰伊·拉赫曼:
问题在于精益领导。喜欢敏捷，因为如果他们如果他们把它看作一种管理方法和风险管理方法，它就会降低他们的开销。所以他们不需要去追逐团队，弄清楚他们在哪里，你知道，我需要去找谁，工作在哪里，他们不需要做任何这些事情。他们需要做的是帮助团队自我修复，自我组织，自我提高，这是他们需要集中时间的地方，这样当有挑战时，你不需要去追赶团队去欺骗团队会追赶你。有人会说，嘿，你知道，一个林赛，你在这里管理着三个团队，你知道，你能帮我们克服这个障碍吗，当你这样做的时候，你就变成了一个力量倍增器，你开始解锁不只是5个人或10个人，而是50到100个人，因为你要你要处理共同的挑战，这些团队真的迫切需要支持。所以你作为管理者的角色开销就会下降。
林赛Velecina:
这很有道理。那么下一个问题是，如果你在三个团队中担任scrum管理员，你应该参加哪些活动?
杰伊·拉赫曼:
哇。所以如果你作为一个scrum管理员在三个团队中工作，第一件事是，做得好吗?对吧?那，那，那真是太多了。所以，很明显，这是三倍的工作量，可能，希望是三倍的报酬。有人真的在努力最大化自己的价值。我的建议是，首先，你知道，第一个问题是，你在为这些团队服务吗?嗯，他们是三支正在火上浇油的球队吗?我知道你没问这个问题。但了解它真的很重要，对吧? Because if you're if you want three teams that are just flying, and they don't need that much support, then call no problem. I would, you know, I would attend, I would attend the events, that I've pretty much made it you don't need to attend the daily scrums. If the teams don't need you there, obviously the other events, you're pretty much there. So to be there for those. But my first question to you would be, you know, are you serving your teams? Well, by managing all three teams, as as as as Scrum Masters, our role is to train, mentor develop, coach our teams, right? So if they're all if they're struggling, or if their various points are struggling, our time commitment is going to be much, much more, those teams won't be doing planning very well. They won't be estimating won't be they won't be learning Well, right. And our time commitment in that space will be expanded. So that's probably the first question. Can you know is that happening? If the teams are cooking with gas, and they're just absolutely flying, then you know, drop, maybe drop the daily scrums, they don't need you. They're certainly be available for the other events.
林赛Velecina:
这很有道理。谢谢你！当然。下一个问题。所以我们使用Scrum来交付学习和开发计划，而不是传统的软件开发?对于编写用户故事和非软件项目的完成定义，您有什么建议?
杰伊·拉赫曼:
所以你，好的，让我们说scrum可以。我们用scrum来建立创业公司，帮助营销团队和审计团队，以及诸如此类的事情。对你们来说最重要的是要弄清楚定义可能是最简单的。所以我不太了解你的背景。所以我要讲的是原理。你怎么知道事情已经完成了?我们都需要同意的清单是什么?如果是学习和发展，是否需要有学习目标需要设立培训师?是否需要安排一个时间表?我们需要做些什么来完成部署，部署培训?我们需要派人准备吗? Do we need to have managers approve? Is that is that is that all part of the fix? Is that all part of the game? Sorry. So those that idea of, you know, what is the checklist? I would start with that as a candidate definition of done and continue to improve it right. So every every couple of weeks, you're going to retrospect is this a good definition of Done Do we capture everything? Did? Did we drop the ball somewhere? If so, how can we fix it? How can we build the gap? Can we do something with our definition of done to ensure that we don't drop the ball next time? So that's how I probably play with it the most, the most important thing is to start with something. It doesn't have to be great to start with something and improve as you go. Okay. Yep. That was that was a two parter. But I hopefully I think I covered both parts.
林赛Velecina:
是的。如果你还想深入了解的话，也可以在问答环节中提出来。所以这里有很多关于估计的问题。所以我要试着把这些东西联系起来。所以这里存在一个问题，即如何发现或理解开发者是否公平地估算故事点。这里还有一些关于评估计划的最佳建议的问题。你有什么推荐的吗?
杰伊·拉赫曼:
好的,很酷。好的。
林赛Velecina:
诸如此类。是的，这方面有很多问题。
杰伊·拉赫曼:
当然。好的。我们先看第二题，关于如何估计男性不这么做。他们稍后会做一个公平的。但是让我们，让我们让我们这样做。你知道，你怎么估计?关于评估，最重要的事情是确保开发人员对“小”的定义达成一致。所以我假设你在用故事点。或者你可以用几个小时，也可以用一天，这不是真正的估算，你用什么并不重要。好的。 So if you're using, say, for example, we're trying to build a piece of code. What we want to be able to figure out is, what is what is the smallest piece of code? What does that look like? Why do we call that a one? Human beings generally a great African out size of things, they're not so great at figuring out exactly to the minute how long something is going to take, right. But they kind of know the bigness stuff. Right? So figuring out what the smallness of something is. So how do you know, a great a great thing? Is it what's the smallest dog? You know, I would say Chihuahua. Great. So what's the biggest dog? You know? It's a great day. Okay, so how many chihuahuas fit in a great day 1050 You're gonna get, you're gonna get some kind of, hey, there's gonna be 15 chihuahuas in a great day, right? Or 22 hours in a great day. So it's a big dog and a teeny dog. So, and people weren't going to generally agree around what that takes. And that's what we're looking for. We're looking for general agreement. Okay. So when you're looking at software, I'm assuming this is a software question, right? So when you're looking at software, then you want to think about, okay, what is the smallest, smallest piece of work that we think we can do and the team agrees on? Is the smallest piece of work? Let's call that a one, one hour, one day, whatever. All right, we're talking to make it easy. Let's just say it's one point. Okay, cool. What's the biggest piece of work? Well, it's this. This is what we did last time. And it took us I don't know, it took us 15 points, we're gonna say, right. Okay, so now we know what one is. And we know what 15 is. So what's the middle? Seven points? Great. Whether you seven points. What was that? Is there a piece of work that looks like that? Yeah, it's this. So now we have three reference points. So now with those reference points, when we then considering other pieces of work that the team is doing, right, we can figure out where those pieces of works based on our estimates, where that fits on the continuum. Okay. By the way, this is why points or estimations in one team does not translate over to another team. Because each team is doing different things. They have a different context, right. So if you're building web pages, for example, your big, maybe 15 points, and your small maybe one point, but it's to do with webpages, your context sort of webpages, if you're building data, you know, data back end servers or whatever, or you're you're implementing infrastructure, your one point and your 15 points or your 18 points, whatever Fibonacci sequence you're using is going to apply to your particular context. You can't then you can't then compare teams, because it's not apples to apples, right? So that's, that's a great way of doing it. And another thing is, the teams can get practice just by going through the dog exercise. It's such a great exercise, and it's so fast, you can use chimps monkey, and you can even get really wild with it. Okay, well, how many great data inside an elephant? All right, and people will come back with the answers and ideas, and the team will generally agree. Why. Because teams are good. And people are good at figuring out sizes of stuff and bigness of things and smallest of things. Okay, so that's that question. Hopefully that will be. That's that's clear. If not come back to me. And I'll try and I'll try and be clear. We'll second one.
林赛Velecina:
另一个，是的。那么如何发现和理解开发人员是否公正地估计故事点呢?这有点模棱两可。
杰伊·拉赫曼:
所以这个词似乎暗示这是一个信任的问题，而不是，这不是我信任我的开发团队吗?我是否信任我的开发者?他们是否夸大了自己的工作，这样他们就可以放松下来，每天去找吉姆15个小时这些都是我听到这个词时会问的问题，这些都是我脑海中浮现的问题。我认为，在这个领域最重要的事情是，如果你有信任问题，那是另一种谈话，对吧，我们需要思考，嘿，我们雇对人了吗?他们了解我们的价值观吗?这就是公司的价值观吗?他们明白吗?他们理解透明、开放和诚实吗?他们都是这样的吗?如果他们很棒，那我们就得谈谈你是怎么估计的? What is it you're thinking about? Okay? If it's about just making sure that the guys have considered everything, then ask for help ask for support, right. So let's imagine that a team are building a product that they have nothing, no idea about. No idea, they've never built it before that or anything, they're brand new team. And they're coming up with wild estimates, then bring some help him bring some architects in some engineers in bringing some guys with some experiments. And so bringing in some guys with some experience, those people will help you figure out and help you work through your actual estimation. The other thing you can do is is that refinement sessions are, are there to help you think ahead. So you know, you know, potential product backlog with the stories that are going to be coming in, in the future sprints. So refinement doesn't necessarily have to be just about the story you can run to, you know, I asked technical teams to run technical requirements. So if you don't know what something is, you can work together as a technical team and go, Okay, we're gonna build this widget never done it before, what does it take, and then you as a team, break down the actual thing that you're trying to build, figure out the detail together as a unit and as a group. And that will familiarize you with what's coming. The technologies involved, where the holes are, where the gaps are. And so your estimates will be closer, a little bit closer to what is achievable. Oh, that helps.
林赛Velecina:
这是个好建议。谢谢你！是的，信任是非常非常重要的。
杰伊·拉赫曼:
是的。我希望只是一秒钟。这只是一个全新的团队。和
林赛Velecina:
是的。今天的观众中似乎有不少全新的团队，这是基于他们提出的问题。这是一个有趣的私人问题。那么，你能分享一件关于Scrum或敏捷的事情吗?你自己也很惊讶地了解到这一点。
杰伊·拉赫曼:
太好了。这是个好问题。这让我很惊讶。我想我可以告诉你一些我不确定的惊喜。我认为我喜欢它的原因是我们不知道未来的原则。你知道，我是一个创业公司，作为一个开发人员，我有点喜欢敏捷。后来因为我的过错，我成为了团队领导，成为了项目经理。当我做项目管理的时候，真正困扰我的是我必须预测未来。我都不知道下周要做什么。对吧? I've got to tell these guys, I've got to tell the leadership team, that we're going to deliver this really kind of expensive products, like multimillion pound per up with 30 guys working for the guys and girls working across this. And I've got to give you a date when it's gonna happen. And my engineers don't know. And my leaders don't know. And I don't know. But the most refreshing thing about agility, I think and about Scrum is that it's okay not to know, right? It's right not, in fact, if you tell people things that if you give people absolutes, and certainty is good leaders experience leaders, even though they're not good leaders, but they're tough leaders, they will tell you that if you don't put in some kind of uncertainty, you don't, you don't own up to the truth that you don't know the future. All of your plans are in in sand, right? It's all going to fall to bits. So that's the thing I love the most about agility that helps.
林赛Velecina:
那么下一个问题，作为Scrum Master，如何帮助团队对故事进行切片?你有什么特别的技巧或技术可以推荐给scrum管理员来帮助团队进行故事切片吗?小块吗?
杰伊·拉赫曼:
当然，看，你知道，我总是发现，作为切片故事，我总是发现我的观点是，如果你是一个技术scrum大师，你有编码背景，这真的很有帮助，因为你真的可以进入细节或构建的细节。理想情况下，尽管如此，我总是会说，看，仔细想想我们需要做的最小的工作是什么，才能真正传递一些价值，我们不想主要关注复杂的后端东西，或者你不想只关注小的，小的组件。你要做的是思考我们能做些什么来释放价值?我们能做的释放价值的最小事情是什么?这就是我的想法，这就是我的出发点。切片故事尤其具有挑战性，特别是当上下文相当复杂时，有很多移动的部分，你有用户体验，你有后端，你有所有这些，当你有所有这些发生时。我们能做的最小值是多少?这就是我开始的地方，诱惑变成，哦，让我们今天只做用户体验。除非只做后端，下一个冲刺，然后再做破伤风。突然之间，你要建造所有这些不同的组件和东西，增加浪费和技术债务，以及所有这些不能一起工作的东西。 So the key is trying to keep try to keep the whole thing moving, try to go end to end. And try to think of the smallest stuff that you can do and build on that. That's, that's hard. It's a hard question to answer, because I don't understand the context. But hopefully, there'll be enough in terms of principles for you to go after it.
林赛Velecina:
是的。如果你需要，也可以随意添加更多的后续问题。这是个有趣的问题。今天这里有很多关于Scrum Master的问题。那很酷。所以是Scrum master。当scrum管理员的第一天你会做什么?
杰伊·拉赫曼:
这是个很好的问题。
林赛Velecina:
这也是一个很好的问题，也许可以在这里描绘一个场景。好吧，很酷。所以,
杰伊·拉赫曼:
有一些有一些情况，我们可以是第一天的scrum主管或者我们自己是第一天的scrum主管，就像我们第一次做这件事一样，或者我将成为一个有经验的scrum主管新的团队领导，我认为最重要的事情是首先弄清楚希望，你会有另一个scrum主管接替你，对吧。如果是这样的话，那么在这种情况下最重要的事情就是开始与他们分享，看看他们是如何运作的，并开始了解这个团队。弄清楚正在进行的工作的背景，了解我们正在构建的是什么?我们为什么要做这个产品，和产品负责人交谈，试着真正了解这个团队是做什么的，以及他们想要做什么。我要做的下一件事是，一旦你弄清楚了工作，就要试着弄清楚涉及到的个性，团队在哪里，他们的成熟程度以及他们推出产品和交付的能力。现在我用了product这个词。但我，你知道，Scrum团队在各种环境中运作，审计营销，我们已经提到过，我们讨论过贸易管理和类似的东西我们讨论过软件，对吧?所以这一切都是为了将价值传递出去。那么，这个团队是如何实现价值的呢?他们面临的主要挑战、问题和挫折是什么? What is what is preventing the team from doing all the great stuff that they're there to do? I always find that great Scrum Masters add value by fixing or helping the team eliminate impediments. So whenever I'm in there, I'm trying to figure out whenever whenever I've started a new team, once I've understood what it is they're trying to build the personalities involved in the challenges they're facing. I try and work hard to try and eliminate some value. So I try and eliminate some of the frictions, and create value, not eliminate value if you do that you're doing it wrong.
林赛Velecina:
是啊，这很有道理。我有个关于回顾的问题。所以有人要求推荐一些互动或有趣的工具来举办罕见的回顾。但同样的，只是建议更有吸引力的回顾。
杰伊·拉赫曼:
所以有很多工具，取决于你是否正确。还有迈拉，还有这些东西，对吧?你只需要谷歌，你就能得到很多。我不打算讲实际的工具本身。乐趣。逆转录病毒。我们要做的是当我有一个团队，我要告诉你们一个秘密。对吧?所以我希望你们准备好了。所以每当我们有一个新团队做复古的时候，我总是会做的一件事，我真的很出名，但肯定是出名的，那就是Krispy Kreme，复古。 Okay, so why is it called the Krispy Kreme, retro? Because the most important thing about retrospective is to help teams relax, and to think about how things have gone over the last sprint. All right. You want to do what you can to, you know, I would always bring Krispy Kremes whenever I'm bringing Krispy Kremes for those of you that are not, um, you have Krispy Kremes up there in the States, right? It's not just a UK thing.
林赛Velecina:
哦,是的。我们
杰伊·拉赫曼:
很酷的Krispy kreme就像，你知道的，甜甜圈之王，就如何保暖而言。100% - 100%。所以当我在的时候，我会做的是我一直在吃Krispy Kreme和咖啡。它所做的是最重要的事情，它所做的是帮助开发团队做Scrum团队。以不同的方式思考事件和对话。大多数会议都很专注。回顾也很集中，但心态必须有所不同，以便更具探索性。它必须更多的是内在的思考。只要带点咖啡和食物来，就能帮助人们放松一下，更加内省。印度，我们摇滚我们，你知道，我们会带来我们会带来一些办公室之类的东西，退休，bofi和所有这些东西。 But here in the UK, and the states is all about the doughnuts, man. But we've run we've run we Even retros in coffee houses and different spaces and gardens, those just changing, just changing where you are, makes a huge, huge difference. And helps the team kind of relax a little bit and think and just kind of open themselves up to thinking about how they're doing. You want it to be that the team is open to introspection. And this is not a blame situation. This is about hey, we did great here, we smashed it here. And because of that reason, Krispy Kremes. We didn't do so well there, you know, we could have done a bit better there. And what can we do? Maybe we could try this, maybe we can try that and come up with some experiments that we can, that we can rock and roll with, and the next sprint to actually get better.
林赛Velecina:
这真是个好建议。
杰伊·拉赫曼:
那么甜甜圈呢?
林赛Velecina:
下一个问题?所以这又回到了估计，只是一点点。我知道，我们在这个话题上花了很多时间。但是它是细化和估计，相同的意思是两个不同的意思。那么团队应该什么时候做这些呢?估计?
杰伊·拉赫曼:
对的,正确的。好的,很酷。看，当你有一个细化集，所以估计，我们能相信吗当我把它用到空间里，对吧?你可以，当你当你有一个很好的细化过程时。团队真正了解他们正在构建的是什么，以及所有不同的组件和诸如此类的东西。十有八九，当团队真正理解时，他们可以马上进行评估。然后他们可以说这是这是我们想要建造的东西。没有什么可以阻止他们在改进中进行评估，他们也可以在计划中进行评估，对吧?所以他们可以留下评估，他们可以他们可以他们在计划的时候理解工作。他们谈论的不仅仅是衡量事物的大小。 And at that point, they can start to estimate, I tend to find that when refinements are running really, really well the team is really is is pretty much ready to estimate and they'll just they'll just knock it out there. And then. So I tried to get my view is try and get all the all the estimation done in refinement. If you do that, right, you're planning is 20 minutes. It's like, Hey, we're going to do this, this and this. These are the stories. This is the sprint goal. This is what we're going to do. So this is the this is where we're heading toward in terms of the protocol team figures out the sprint goal. This is what we're going to do these are different stories that estimates are already there. Do we all agree with them? Yeah, we do any changes? Nope. Let's rock and roll. Let's go. And the planning becomes really, really slick.
林赛Velecina:
有道理吗?所以我们要蹑手蹑脚地回到回顾会上。再说一遍，很快，因为我们突然冒出了几个问题。所以你主要谈论的是面对面的回溯。那么，当你拥有一支远程团队或混合团队时，对于更吸引人的复古风格有什么建议呢?
杰伊·拉赫曼:
是的，所以我倾向于发现高混合水平的团队，或者我说难度更高的，混合团队可能会更难一些。因为当你当你当你当你有一群男孩和女孩在房间里，他们他们得到了一种不同于镜头前的人的体验，对吧?我发现，那些在镜头前或在电话里的团队成员，往往会错过很多回顾所创造的有机对话的细节。所以我的观点是，这并不一定是对或错。但我的观点是，要么试着做，要么不做混合，它并不会变得很好。然而，如果你能让内容继续下去。你可以有像前Myro董事会那样的人，他们把所有的东西都放在那里，他们对电话有纪律。但这样你们就都在线了，对吧?如果你在做。如果你在做一个完全在线的回顾，那么重要的是，再次强调，同意你的工作方式。我们，你知道，我们都在那里，有人在做复古，团队在那里，所有人的摄像机都关掉了。 And what's really going on is that they're trying to get their work done. And it happens, right life happens. People are trying to get their work down, they're trying to listen in with one year while they're trying to get something out the door. They're trying to take care of their kids or the dog needs feeding or something like that. So my view is, is that when you're doing a retro, try to do as much as you can to keep the team engaged. If that means cameras on then call if your camera is off, then that means that you're not present. And that's okay. All right. The way you're going to figure that out is through your team charters, through your team agreements. Yeah, by speaking to each other and figuring out Hey, guys, how are we going to retro online? What are we going to do? What is it what is it that we agreed to do it? None of us wants to be the police. Okay, so none of us wants to say, hey, jays got his camera off. He's a bad guy we want to say is we want to say let's make it easy for Jay to be present with his cameras on and his mic is on. That means he's here with us. And if the cameras off, or the mic is off, that means Jay is dealing with something important and he will be right back as soon as he can. Okay, so those sorts of things. I'm not saying that's right or wrong. What I'm saying is, is that those sorts of agreements, help the team operate as one.
林赛Velecina:
这是个好建议。是的。感谢观众们提出关于远程方面的问题。这绝对是非常重要的。谢谢你提出来。这个问题稍微改变了一下。那么产品目标和冲刺目标之间的区别是什么呢?如果你能给出每一个例子，那就太好了。
杰伊·拉赫曼:
所以我的看法是产品的目标是最重要的，你知道，我们在朝着什么方向前进?我们到底想做什么?对吧?冲刺目标更多的是一种战术。所以产品目标更具战略性。所以它们在更远的地方。冲刺目标是战术上的，在冲刺中我们要做什么?我想之前有人提到过技术债务或小部件，它们对客户来说不一定有价值，但它们对完成交付是必要的。这些都是可能影响冲刺目标的因素。开发者自己会发现的。 So hopefully, that helps. Thank you. So
林赛Velecina:
梅根的问题。我是一名scrum主管，每次sprint计划活动，我们都一起制定sprint目标。我们进行信心投票，以确定我们有多大可能实现这些目标。最近的两到三次，所有的目标都被打破了。那么我们是否需要故事点来进行相对的规模划分呢?他们的工作方式好吗?
杰伊·拉赫曼:
那么团队是团队规划的职责达到了还是违反了?达到了吗?哦，那是他们的目标之一吗?他们是谁?他们问我是否需要故事点?是的。好吧，我的意思是，如果你们。如果你们已经算出了功的大小，那有什么价值。我认为你甚至不需要故事点，对吧?目前还没有任何消息。实际上，我们教的是同样的东西，如果你能得到你的故事，大小差不多。 So let's imagine every story is around the same size. It's just about counting stories, right? Or carrying PBIS. So we know hey, we can do 10, New 10 PBIS? And what's the confidence there? 95%. And we hit it every time, we know that we can knock out 10 PBIS? Why would you need as to why would you need to do points on this and on the third? So if it's working, then you know if it ain't broke, don't fix it. There's nothing to fix. You guys. Just keep going. Do you more? Well done. Right. I
林赛Velecina:
当我们有大量关于评估之类的问题时，这个问题就出现了，可能是梅根突然想到的。谢谢你的提问。梅根。这里有一个关于产品所有权的问题。这可能是我们最后一个问题了。不确定。所以我的scrum团队有不止一个产品负责人向产品待办事项列表中添加项目?scrum主管如何与多个产品负责人一起促进sprint目标的制定?也许可以谈谈产品所有权?我想是将军之类的。 I think that
杰伊·拉赫曼:
问题是，你有一个症状表明为什么只有一个产品所有者。正因为如此，你应该有一个产品负责人，他与不同的利益相关者合作，或者其他对正在交付和解决的问题感兴趣的人。他们要建造什么?为什么他们要按照优先级的顺序，所有这些伟大的事情都按照产品待办事项列表的顺序，这就是他们的想法。所以你有一个，一个真相的来源，可以说，就我们要追求的东西而言。当你有多个产品负责人，多个产品时，我的意思是，我见过，我见过scrum团队的场景，他们的产品backlog只是一个笼子，对吧?人们往里面扔东西。因为他们认为那只是一张愿望清单。没有相关性，没有协调，什么都没有，所以一分钟内团队在做一件事，他们在做另一件事，团队完全没有效率和效率。一切都以一种可怕的方式建立起来。 So the purpose of a product owner is to is to release value. And most importantly, you need one product so that the team knows which way they're heading. Right. So what I would do is I would, I would first of all, make that transparent department on his board don't know that that's what's happening. So have a conversation with them. Say, look, guys, I see the three of you here or two of you here doing this stuff. What the effect of it is this there's this is the effect this is having on the team. This is the data this is what's happening with the team. We have no idea what it is. It's one minute we're doing this next minute we're doing that. And also, I bet they're probably reordering the product backlog as they go. So now you've got all this kind of real time stuff happening. In I've seen it happen where product owners then start to interfere in the sprint backlog too. So wait a minute that my story is super important I needed done yesterday. That story that Bob's looking at He put in. It's not that's not that's not that important. So let me just take that out, and I'll throw something else in. And next thing, you know, the sprint backlog is all over the shop as well. So the most important thing is to make transparent the challenges that the team is facing by that approach. And then have the product owners figure out who really is going to be the product owner for that team. Right? How are they going to? How are they going to negotiate the work and all that kind of good stuff? Right. That's part of the game when it comes to being productive.
林赛Velecina:
是的，谢谢你，杰。好了，我想我们没有时间再问问题了。不过，我们这里有很多空位。所以观众们放心，你们的问题都会得到解决。我要和杰分享问题列表。如果你提供了联系方式杰会给你答复的活动结束后我会和杰分享。我们也可以找到一种方法来回答匿名问题。我们会算出来的。非常感谢大家。 Oh, go ahead.
杰伊·拉赫曼:
去做吧。我想说的是，如果你想，我的意思是，如果你想在领英上联系我，在领英上联系我，如果有非常紧迫，非常紧迫的事情，来领英上找我，很高兴我喜欢帮助人们敏捷地成功，来领英上找我。我是杰·拉赫曼。我们可以从这里开始。也许我们可以做一个播客，讨论这些问题。林赛。是的,我们
林赛Velecina:
当然可以考虑这样做。所以当我们结束这里时，我们总是鼓励你们继续学习。所以请在scrum.org上查看学习路径。也可以通过我们的博客和播客系列，以及我们的网络研讨会系列来联系我们和scrum.org亚博一百送一百社区，就像你们今天在这里一样，还有我们网站上的所有其他免费资源，包括我们的论坛和其他供你们提问的好地方。再说一遍，这就是你和杰交流的方式。所以，请一定要这样做。我们希望每个人都能从这次会议中获得价值。我很抱歉。我们无法回答所有的问题。但我们通过了其中的28个。 So rapid fire. So thank you all for attending. And please keep an eye out for other Ask a PST sessions in the near future, as well as our scrum pulse webcast series. We have a webcast coming up next week, focused focused around value with two of our colleagues from McKinsey. So please feel free to check that out. And have a great day and Scrum on and thank you again, Jay for fielding these questions today.
杰伊·拉赫曼:
别担心。我期待着再来一次。
林赛Velecina:
祝大家今天愉快。祝你晚上愉快。再见