在一组1000名程序员中扩展Scrum
大多数Scrum团队倾向于7到15人，尽管还不清楚如何在100多个人之间扩展Scrum，或者如何将给定团队的有效性与小组内的另一个团队进行比较；这意味着，除了将团队划分为7到15人的Scrum团队之外，团队之间的努力是如何管理和比较的，等等还不清楚。
任何与这些主题相关的建议，或者在规划大规模SCRUM分组时可能更重要的其他相关主题？
*在审查与建议的软件开发团队规模有关的研究时，这似乎是建议的Scrum团队规模的基础，15+在这项研究中，我发现了一个似乎是错误的地方，奇怪的是，它似乎显示了更大的团队，而不是小的团队(7 Ppl)更好.
更新："Re: Scrum不扩展“：亲自研究这个主题取得了巨大的进展，但我认为我会回应一些人的普遍信念，即Scrum不扩展，引用了敏捷成功 迈克·科恩的一段话：
Scrum确实是规模化的:你必须钦佩最早的敏捷作者的智慧诚实。他们都非常谨慎地说，像Scrum这样的敏捷方法适用于小型项目。这种保守主义并不是因为敏捷或Scrum不适合大型项目，而是因为他们没有在大型项目中使用这些过程，因此不愿意建议读者这样做。但是，在“敏捷宣言”和之后不久出现的书籍之后的几年里，我们了解到敏捷开发的原则和实践可以扩展并应用于大型项目，尽管它有相当大的开销。幸运的是，如果大型组织使用所描述的有关产品所有者角色的技术，使用共享的产品待办事项，注意依赖关系，协调团队之间的工作，以及培养实践社区，他们可以成功地扩展Scrum项目。资料来源：(感谢Ladislav Mrnka回答，浏览了这本书)
回答 4
Software Engineering用户
发布于 2012-03-28 11:31:54
与这么大的团队进行有效的scrum是不可能的。即使二十多岁，你也开始挣扎。你必须把这100个人分成小得多的任务组，每个小组都有自己的scrum。然后你就可以有一群团队领袖/代表。这被称为scrum的scrum。
Software Engineering用户
发布于 2012-03-28 12:12:47
Scrum是针对小型团队的，因为scrum的作者发现小型的自组织团队在他们的经验中往往是非常有效的。这是有意义的，如果您考虑到精益原则，即离职是浪费和较大的团队往往需要离职。
如何管理更大的团队的一般做法是创建一个"scrum of scrum“，在这种情况下，每个团队处理自己的子项目，然后每个团队的一名成员在其他子项目的类似代表的团队中代表子项目。这是一座金字塔：
MT (Master Team for full project)
/|\
/ | \
/ | \
T1 T2 T3 (Teams of Sub-projects)
/|\
/ | \
/ | \
ST1 ST2 ST3 (Teams of sub-sub-projects)这类事情的协调是很棘手的，但已经做到了。有效性的概念可以从内在的可见性中看出，那就是scrum--烧伤，等等。
真的，如果你的项目如此之大，以至于你需要数百名开发人员，那么你的可能性就会很大。您需要将其分解为可供工作人员理解的可行项目。
Software Engineering用户
发布于 2012-03-28 12:09:37
如果您有一个拥有1000多人的项目，并且希望直接跳入敏捷，特别是Scrum，那么您很可能正在执行项目自杀。
敏捷开发和Scrum和其他任何技术一样是技能。如果你想使用它，你必须从小项目开始。一旦您掌握了小项目，您就可以开始通过小步骤进行缩放。要说敏捷不起作用，最好的方法是将大型项目从计划驱动的方法转换为敏捷方法，而不需要以前任何扩展敏捷的经验。
扩展敏捷是将计划驱动的方法整合到更高的层次上。你不能无限地缩放Scrum。规模越大，就需要更多的计划驱动机制。有一种叫做Scrum的Scrum，但只有在你用小团队掌握纯Scrum的情况下，你才能做到这一点。Scrum的Scrum也有其局限性--我想大概有5-6个团队/多达40人。
编辑：
最后一个假设来自许多来源，包括CSM和CSPO培训、敏捷成功和平衡敏捷与纪律等书籍，以及我在参加小型Scrum团队(最多5人)时的经验，以及更大的团队，其中15+人员被分成三个团队在同一个项目中工作。项目越大，更高层次上的敏捷性就会被一些旧的计划驱动技术所取代。
甚至连我的CSM培训师都声称，扩展Scrum是Scrum自身面临的最大挑战之一。
https://softwareengineering.stackexchange.com/questions/141882
复制相似问题
腾讯云开发者
