谁决定团队规模?

Vinh,

SM当然可以推荐一个理想的团队规模(根据Scrum指南，开发团队应该在3-9名成员之间)。但是，SM在这方面没有任何决策权。

团队规模应该基于技能集、沟通和协调方面的考虑。项目的复杂性和技术专门化是确定一个跨技能团队的考虑因素，以便为业务交付价值。

成熟的敏捷组织可以按照这些准则促进团队的自组织。否则，根据我的经验，组织通常决定团队名单，他们的决定并不总是明智或明智的。这就是为什么SM必须清楚地传达团队规模、技能和经验的利弊。

一个开发团队应该有足够的拥有正确技能的人，在3到9名成员之间，根据团队的“完成定义”来创建发行质量的增量。

只有团队本身可以确定它是否拥有正确的成员和适当的交叉功能。

绝对对之前的回答!通常，管理层决定开发团队的规模，这与自组织团队的理想相反。总体上信任开发团队;他们知道什么时候团队太大而不能有效地协调工作，什么时候团队太小而不能满足跨职能的需求。真正支持敏捷理念的组织会信任并授权团队这样做。并允许他们在Scrum框架内首次开始工作时从错误中学习。

大家好,
Scrum建议团队规模在3-9人之间。
如果我加入了一个新项目，而团队将有13人(没有SM，也没有PO)，那么作为一个SM，我该怎么做?

我应该有两支队伍吗?

谢谢你！

作为一名SM，如果我加入了一个新的项目，我该怎么做
>球队将会是13人(没有SM，也没有PO)?
>
我应该有两支球队吗?

为什么这个决定是你的?难道不应该鼓励团队自组织并为自己确定最佳安排吗?由Scrum Master来指导和促进这些不是更好吗?

卡米洛·阿科斯塔于2016年8月2日下午06:39发布
大家好,
Scrum建议团队规模在3-9人之间。
如果我加入了一个新项目，而团队将有13人(没有SM，也没有PO)，那么作为一个SM，我该怎么做?

我应该有两支队伍吗?

谢谢你！

正如其他人所提到的，您应该促进与团队关于团队规模的讨论，并询问他们认为组织自己的最佳方式是什么，因为他们需要在每个Sprint结束时有一个完成的、潜在的可发布的增量。现有的团队可以组织成4个或2个Scrum团队。

同时，向Scrum团队解释推荐的Scrum开发团队规模背后的“原因”。Scrum建议开发团队的规模为3-9人，因为2人的开发团队通常太小，无法实现跨职能，也无法证明Scrum中事件和角色的开销是合理的。当开发团队超过9人时，沟通通常会开始中断，因为太多人需要密切合作。

对于冲刺，什么时候决定团队的组成?在sprint计划会议上，产品负责人讨论待办事项。但是参加会议的开发团队成员是谁?只有在您了解了backlog之后，才能确定开发团队所需的适当技能。

那么，这是否意味着部门中所有可用的开发人员都加入其中，在听取了需要完成的工作之后，他们确定了实现sprint目标的单个开发人员?

或

随机地有7-9个人加入sprint计划，根据他们的技能，他们决定在sprint中可以覆盖的最佳产品backlog，然后继续前进。

对于冲刺，什么时候决定团队的组成?

基于您对Scrum指南的理解，在多个连续的sprint中拥有一个稳定的团队成员会有多大用处?

难道不应该鼓励团队自组织并为自己确定最佳安排吗?由Scrum Master来指导和促进这些不是更好吗?

有人有机会推动这样一个过程吗?在这个过程中，一些Scrum团队成员在自组织方面删除了其他成员?你能举个例子吗?

我特别感兴趣的是，这些被移除的成员并没有组成另一个团队。对我来说，这是一个非常微妙的问题，甚至可能被认为是一种排斥，因此我很好奇是否有人成功地经历了它(或没有)。

你好,

有人有机会推动这样一个过程吗?在这个过程中，一些Scrum团队成员在自组织方面删除了其他成员?你能举个例子吗?

是的，我们以前有过。我自己作为一个scrum管理员在回顾中推动了讨论。讨论中的成员提到了他自己，他觉得自己没有给团队带来足够的价值，而且他的知识和责任与团队的目标没有足够的重叠。(当然之前也有其他团队成员的反馈。我可能因为问了一个关于团队效率的一般性问题而引发了讨论)。之后，我把团队的决定告诉了我们的部门主管，他自己负责为该成员在其他地方找到一个更合适的职位+确保团队仍然可以在需要时与他进行合作(但作为团队成员并不高度同步)。

我自己也有一个问题:

我们的部门主管需要为不同的项目分配资源。他们中的大多数都是在scrum团队中组织的。如果每个团队决定他们需要来自我们生产计划(和同步)的一个人的支持——但我们只有一个人可用——就会产生利益冲突。招聘更多的生产人员不是解决问题的办法(成本和责任分工会适得其反)。当然，开发负责人会觉得自己有责任(并且有权威)。

在这种情况下，分配稀缺资源是谁的责任?

在Scrum中，Scrum团队应该有责任以最佳的方式自我组织成员。Scrum Master可以促进这一过程，并解释可用的选项及其优缺点，但任何人都不应该代表他们组织团队。

“对于一个短跑项目，什么时候决定团队组成?”

我想这个问题还没有答案。

第一次冲刺计划由SM、PO和DM参与。组织将决定谁将成为SM和PO。但是谁决定DM的初始组成呢?在第一次Sprint计划中，我们将进一步分析谁将继续在Sprint中工作，或者DM中需要哪些新人，但是DM的初始组成是怎样的呢?

根据我对Scrum指南的理解，DM的最初组成将由SM的PO post指导决定。这是因为PO负责使产品价值最大化。

如果我说错了，请指正。

sprint 0中产品负责人的职责是什么?是PO负责scrum团队的组成，还是为构建产品待办事项列表收集需求?

另外，产品待办事项列表项是否必须细化到足以填满前3个sprint ?

sprint 0中产品负责人的职责是什么?

Sprint的目的——任何Sprint——都是为了产生一个完成增量。为什么Scrum职责会发生变化?

产品待办事项列表项是否必须细化到足以填满前3个sprint ?

Scrum指南是否规定这是一个强制性的实践?

我知道这已经是一个老问题了，但它仍然是一个非常有效和有趣的问题。

作为一个庞大团队中的Scrum管理员，我自己也遇到了这个问题。超过14人。这是来自高层的。

在这种情况下，我遇到了一些阻碍我建立真正的自组织团队的问题。我遇到的一些障碍:

1.与供应商合作，Hiërarchie对团队的组织和创建有很大的影响。

2.“习惯了这样工作”……心态，保持以前的工作方式更容易。

基本上你已经看到了，敏捷的部分在哪里?

但这并不是我来这里问这个问题的原因，但如果我们有一个敏捷的思维方式，让团队决定需要发生什么，它会让我更清楚地了解我所面临的问题。

如果hiërarchie和“used to work”这样的说法是压倒人们的心态，或者有更高的影响，如果团队不说出来，即使他们知道，它也不是很有价值。或者他们不认为这是一个问题，因为他们过去经常这样工作。

所以我的解决方案是，作为Scrum管理员，我有两个子团队。做个实验，看看结果如何。心理上是否更安全?有更多的合作吗?这些会议是否比以前更有价值?基本上对这些问题都是肯定的。它来自我，但我知道团队自己不会想出这个解决方案，因为第1和第2点。

我问自己的问题是:

-有没有可能会有分线，这样对车队来说就有价值了。

-拆分的最佳方式是什么?两支队伍是否都有足够的知识在冲刺结束时获得有价值的结果。(团队不会因为没有知识而受阻)

-管理层希望团队中有这么多人的实际原因是什么?(更多的人=更快的送达?)

如果scrum管理员的工作是移除障碍，并且根据scrum管理员的观察，如果他们认为这样做可以移除某些项目上的障碍，他们会被允许这样做吗?(如果你在一家非常大的公司处于敏捷转型时期，并不是每个人都能接受敏捷思维)。

对我来说，最大的挑战是帮助其他人理解小团队的价值，让更高的管理层理解它，并真正感受到它

所以我的解决方案是，作为Scrum管理员，我有两个子团队。

这听起来很像一个经理为为他们工作的人做决定。而不是像仆人式领导那样帮助人们高效地完成工作。

作为一个庞大团队中的Scrum管理员，我自己也遇到了这个问题。超过14人。这是来自高层的。

当“高层”这样告诉你时，你就失去了成为Scrum Master并帮助他们理解如何让团队自我组织、自我管理能够产生更好结果的机会。如果我处在你的位置，我会建议“高层”与Scrum团队会面，讨论为什么他们觉得它太大了，然后让团队决定他们是否同意，以及如何继续。

在这种情况下，我遇到了一些阻碍我建立真正的自组织团队的问题。

不，你意识到了团队在实现自组织时所面临的障碍。作为Scrum Master，你的重点应该是帮助团队和组织消除这些障碍，或者达成一个让每个人都满意的解决方案。

我问自己的问题是:

这些是您应该向Scrum团队和“高层”提出的问题，以帮助他们自我意识到阻止团队进行自组织和自管理的障碍。

对我来说，最大的挑战是帮助其他人理解小团队的价值，

小团队并不总能让事情变得更好。如果团队很小，但不具备所有必要的技能、途径、经验等，那么小团队实际上会带来负面价值。与其试图解决你认为存在的问题，不如花时间发现是否存在问题。在这种情况下，如果团队在涉众可以吸收的时间表中持续交付高质量的价值增量，那么真的存在问题吗?当然，这可能有违“传统智慧”，但这并不意味着这是一个问题。

我知道我一直对你很挑剔，但在这种情况下，我真的想不出一个更友好的方式来表达我的意见。只是…我的意见．意见是以知识为基础的。经验主义说，知识只能通过学习来获得。你说你的“解决方案”将被用作实验。我认为这很好，但是做实验的人必须了解其中的原因。支持团队做实验的人也必须理解。最重要的是，每个人都必须愿意根据实验结果进行检查、学习和适应。我经历过你不止一次，但我从来没有决定结果很好。然而，每当每个人都参与到这个情况中，就会达成一个非常有效的解决方案。

管理层希望团队中有这么多人的实际原因是什么?(更多的人=更快的送达?)

为什么不问问他们呢?他们并没有在这家公司实施Scrum——相反，他们似乎在强加Scrum其他的东西．他们希望取得什么成果?Scrum Master应该擅长的想知道．

嗨，丹尼尔，伊恩。

谢谢你的回答。我同意你们俩的看法，理论上讲这听起来很容易。你只要支持团队就行了。如果你的团队确实想要提高，这将会起作用。

现在的团队习惯了微观管理，一切都来自于更高的层次。他们的心态是一致的:开发人员是最低级的，每个在公司有更高职能或工作时间长的人都需要倾听。他们最清楚，他们应该提出例子/答案/解决方案。对我来说，如果我们想要进入一个每个人的意见都被考虑在内的敏捷环境，并且人们不会只是等待其他人给出答案，那么这就是最大的瓶颈。

所以问团队不会让你走远，因为一切都“ok”。询问有关改进的问题会被认为是“你工作不好”。所以我的观点是，让他们体验不同。有区别吗，他们在小团队中交谈得更多吗，他们在小团队中更开放吗?

正如你提到的"更高"这是你真正需要从直线经理那里得到的支持。如果你没有，那还值得一试吗?因为hiërarchy仍然是一个很大的部分，有时作为scrum管理员，感觉更像是试图翻越一堵墙。

如果我没理解错的话，是开发人员决定谁将加入团队。如果一个团队成员不能很好地发挥作用(当然是在SM鼓励团队一起工作以完成工作之后)，是否也由他们决定将其移除?