速度和故事点

不幸的是，这个团队并不是跨职能的。

然而，我希望在我的团队中，我们尽我们最大的努力。

“最好”是什么样子的，在这个问题上有共识吗?例如:

• 每个团队成员都应该忙着做事情吗?这似乎是PO的目标
• 团队是否应该提供速度代替价值，这似乎是你的希望，或者
• 团队应该利用经验主义和团队合作吗学会在正确的时间做正确的事情?

这听起来非常“理想情况”，或者书上是这么说的。现实往往大不相同。我需要把它卖给PO和团队。谈论抽象的东西在这里行不通。

我的建议是完全忘记抽象的东西。出售Scrum的基础是经验主义，以及应该期望从中得到的有价值的结果。没有比这更具体的了。

与其试图说服你的采购订单，不如试着在他们所在的地方与他们见面并从那里开始?找出他们的一些痛点，并提供Scrum框架可以提供的帮助。回到伊恩提到的经验主义。透明、检查和适应本身就很强大，Scrum只是为其提供了一个结构和节奏。

你如何为你的订单举一面镜子，让他们更清楚地看到当前情况的现实?开始更多的工作，真的能帮助团队完成更多的工作吗?还是因为未完成的工作而造成交通堵塞?这个资源利用陷阱练习可以很好地演示:https://www.youtube.com/watch?v=CostXs2p6r0

你有可以使用的数据吗?在给定的时间段内完成了多少个待定项?它们有价值吗?团队是否实现了他们的目标?

你有经验证据来支持POs关于团队“无事可做”的担忧吗?这种情况实际发生的频率是多少?原因是什么?团队如何解决这些原因?

事情是这样的:我们的故事有很多难以面对的依赖关系，大部分都不在团队、PO和scrum管理员的掌控之中。比如外部依赖，疾病，或者我们正在借用一个主机开发人员，因为我们团队中现在没有一个主机开发人员，或者与其他团队的依赖(最后一个是唯一可以通过将其引入SoS来改善的)，或者一些故事依赖于其他故事的事实，显然如果一个故事不移动，另一个故事也会……

这导致许多故事在sprint结束时没有结束，不是因为团队没有工作，而是因为所有这些依赖关系……

这个团队也不是跨职能的，而是在竖井中工作。首先，因为有外部员工，他们不能做结对编程或其他任务，除非他们的合同中明确规定，其次，因为一些主题太具体了，在团队内部分享专有技术要么没有意义，要么根本不可能。

我们如何才能更好地解决这个问题?

将backlog中主要外部的故事分开，或者在backlog中以某种方式陈述那些具有外部依赖性的故事，是否有意义/有任何区别?

我的意思是,团队显然是意识到了这一点,和阿宝,但也许sprint结束时我们会清楚地看到一些故事结束,这可能增加团队的动机,并增加透明度,未完成,主要是外部因素,实际上,阿宝看到团队工作得很好,我可以把这个“图片”在项目层面,所以他们看到这些依赖项的问题,也许做些什么?

对此有什么想法吗?

非常感谢!

JFB

也许您可以从完成一个价值流映射练习中受益，以识别和说明整个开发系统，包括任何上游/下游系统和其他团队依赖关系。

我还在一家公司工作，在那里我们有团队之外的依赖关系。我们的API微服务团队就是一个例子。我们依赖它们作为与后端管理系统的交互点。我希望有一天我们可以把这个功能引入我们的团队，但在那之前，我们需要像水一样围绕约束流动。当我们做待办事项优化时，我们会注意到与其他团队的依赖关系，在我们的例子中，我们使用Jira中的链接来连接待办事项。这有助于提高透明度，我们可以很容易地检查进度并进行相应的调整。当产品负责人将backlog与值、大小等一起排序时，需要考虑依赖关系。我们会优先考虑我们能完成的工作，而不是我们只能开始的工作。

我们使用azure Devops而不是Jira。那些有依赖关系的故事呢?当团队完成工作时，会创建一个名为“等待”的新状态，但现在悬而未决的事情取决于外部人员?我认为这至少会带来一些透明度……

我也想过将故事划分为“团队”和“外部”，这样团队就可以更好地专注于他们手中的内容，而且我认为看到完成的故事有助于提高积极性，但我更喜欢上面提到的选项，也许没有那么“透明”，但至少积压更干净，没有那么大。

任何想法吗?

Saludos,

我在以前一家公司的团队中也遇到过类似的问题。他们依赖于外部公司，直到sprint结束，我们都在努力完成故事。

一些任务已经被转移到sprint的前面，所以我们能够在sprint中完成票据。但并不是每一张票都能买到。将外部和内部分开是一个丑陋的解决方案，因为在sprint结束时，仅通过完成内部任务并不能为客户创造价值。

如果你只在你的公司内部有依赖关系，在你的组织中解决这个问题，你的团队也可以做其他的任务，或者你的团队中有人可以做这些，这样你就接近客户了。不要尝试使用一些票据状态来解决组织问题。