blocks|key|2646122|text|Scrum可以使用"Scrum+of+Scrum“进行扩展。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2646123|来自Scrum联盟的这个advice是关于如何进行Scrum会议的：|offset|length|2646124|2646125|，scrum会议的Scrum，是将Scrum扩展到大型项目团队的重要技术。这些会议允许团队集群讨论他们的工作，特别是关注重叠和集成的领域。|blockquote|2646126|2646127|2646128|《敏捷和迭代开发》一书也是这个问题的discuss。|2646129|entityMap|0|LINK|mutability|MUTABLE|url|http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting|1|http://books.google.com/books?id=e4FrAFn0ytIC&pg=PA133&dq=%2522scrum%2Bof%2Bscrums%2522&ei=L5vmSPX5DYGgsgOp6-nLBg&sig=ACfU3U1uppfnDpTqUws0g7Qlv8u4aAkX2g^0|0|C|6|0|0|0|0|0|0|I|7|1|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|F|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|13|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|16|8|@]|9|@$D|17|E|18|1|19]]|A|$]]|$1|N|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]|V|$5|Q|R|S|A|$T|W]]]]

Scrum can be scaled using "Scrum of Scrums".

From the Scrum alliance comes this <a href="http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting" rel="nofollow noreferrer">advice</a> on conducting Scrum of Scrums meetings:

<blockquote>
 The scrum of scrums meeting is an important technique in scaling Scrum to large project teams. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.
</blockquote>

The book Agile and Iterative Development also <a href="http://books.google.com/books?id=e4FrAFn0ytIC&amp;pg=PA133&amp;dq=%22scrum+of+scrums%22&amp;ei=L5vmSPX5DYGgsgOp6-nLBg&amp;sig=ACfU3U1uppfnDpTqUws0g7Qlv8u4aAkX2g" rel="nofollow noreferrer">discuss</a> this issue.

blocks|key|281684|text|我不认为有一个界限，毕竟scrum的想法来自于汽车制造，这在人方面是相当大的。大项目的问题是，你需要从一个小团队开始，并随着时间的推移而增长。保持独立的团队通过Scrum的Scrum进行交互，它将会扩展，如果人们愿意合作，它就会工作。在我们的业务中总是如此:分而治之。将大而难的问题分解成可处理的小块。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|281685|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I don't think there is a boundary, after all the ideas of scrum came out of car manufactoring and that's pretty big in terms of people. The thing with big projects is, that you need to start with a small team and grow it over time. Keep separate teams that interact via Scrum of Scrums and it will scale, if the people are willing to collaborate it will work. It's like always in our business: divide and conquer. Break the big hard problem into smaller manageble chunks.

blocks|key|281845|text|看看伯尼·汤普森写的this+blog+post吧。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|281846|它概述了他在微软扩展Scrum+/+XP时遇到的许多问题和权衡，并有一些非常深思熟虑和有趣的解决方案。|281847|在同一个博客上还有其他的帖子也处理了你所关心的这些规模问题--我想这是一个关于“成年人的敏捷”的想法的金矿。|281848|entityMap|0|LINK|mutability|MUTABLE|url|http://leansoftwareengineering.com/2007/11/12/10-pitfalls-of-agility-on-large-projects/^0|A|E|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

Have a look at <a href="http://leansoftwareengineering.com/2007/11/12/10-pitfalls-of-agility-on-large-projects/" rel="nofollow noreferrer">this blog post</a> by Bernie Thompson.

It outlines a lot of the issues and trade-offs he ran into when scaling up Scrum / XP at Microsoft, and has some very thoughtful and interesting solutions.

There are other posts on the same blog that also deal with these issues of scale that concern you - IMO it's a gold-mine of ideas on "agile for grown-ups".

blocks|key|2646099|text|在一个团队中，沟通渠道与(N+*+N-1)+/2成正比，作为上限，因此可以松散地视为O(N%5E2)。敏捷团队的分散性质意味着没有中心参考点，与存在这样的参考点相比，沟通将变得更接近上限。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2646100|如果您有书面规范和更正式的结构(请参阅Painless+Functional+Specification以获取规范文档的讨论)，则通信更接近于中心辐射式模型，该模型具有更接近O(N)通道(针对项目中的N个员工)。我看到的大多数经验法则评论都将敏捷团队的最佳点放在6或更少，上限在10左右，尽管您的里程可能会有所不同。|offset|length|2646101|在PFS文章中，Joel+(是的，Joel)讨论了Programme+Manager的角色，他的角色是开发和拥有规范。无痛功能规范系列对此进行了相当详细的介绍，并且对于非技术管理人员来说也很容易理解-我已经向相当多的人推荐了这篇文章。|2646102|entityMap|0|LINK|mutability|MUTABLE|url|http://www.joelonsoftware.com/articles/fog0000000036.html|1|http://www.joelonsoftware.com/articles/fog0000000034.html^0|0|J|X|0|0|P|H|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

Within a team the communication channels are proportional to (N * N-1) / 2 as an upper bound, so could loosely be viewed as O(N^2). The decentralised nature of agile teams means that there is no central point of reference and the communication will grow closer to the upper bound than if there was such a point of reference.

Where you have a written specification and a more formal structure (see <a href="http://www.joelonsoftware.com/articles/fog0000000036.html" rel="nofollow noreferrer">Painless Functional Specification</a> for a discussion of spec documents) the communication is closer to a hub-and-spoke model, which has closer to O(N) channels (for N staff on the project). Most of the rule-of-thumb commentary I've seen puts the sweet spot for Agile teams at 6 or less and the upper bound at around 10, although your mileage may vary.

In the PFS articles Joel (yes, that Joel) discusses the role of a <a href="http://www.joelonsoftware.com/articles/fog0000000034.html" rel="nofollow noreferrer">Programme Manager</a>, whose role is to develop and own the specification. The Painless Functional Specifications series goes into this in quite a bit of detail and is also quite accessible to non-technical management - I've referred quite a few people to this article.

blocks|key|4062032|text|将Scrum/XP想象成一系列迷你瀑布。最初，您希望进行前期工作，以获得良好的、定义良好的待办事项。不一定是整个系统，我认为一旦你得到了一两个冲刺价值的产品待办事项，就是时候开始冲刺了。在sprint的同时，您应该创建额外的PBI(并适当地重新排列它们的优先级)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4062033|其想法是，您可以在系统完全定义之前交付业务价值。|4062034|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Picture Scrum/XP as a series of mini-Waterfalls. Initially, you want to do an upfront effort to get a good, well-defined backlog. Not necessarily the whole system, I'd argue that once you get one or two sprints worth of product backlog items, it's time to start sprinting. Concurrently with the sprint, you should be creating additional PBIs (and reprioritizing them appropriately).

The idea is that you can get business value delivered before the system is FULLY defined.

blocks|key|4062169|text|扩展scrum或任何敏捷方法都取决于您的环境。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4062170|如果您有多个项目和多个团队，则扩展只是在团队之间共享最佳实践。一旦你开始需要系统/项目之间的集成，就要小心了。在这一点上，团队之间的紧密集成是可取的。|4062171|如果你有一个大型项目(我曾经有一个45人的团队)，有不同的扩展方法。我们选择让一个团队拥有多个独立的团队-开发人员独立于BA/QA独立。迭代经理都参加了，并且双方至少有一人参加了另一方。我们有一个卡片墙，但它包括迭代前的东西(分析过程中的故事，要追逐的生产but+)和迭代后的东西(发布/部署工作)。|4062172|我还参与了一个非常大的项目，有很多scrum团队(大约20个团队--有些是分布式的--每个团队有10-20个成员)。每一个都有单独的站立，有scrum+of+scrum，甚至还有scrum+of+scrum。我认为我们通过职能领域而不是工作流程来划分团队是一个错误。我们的细分造成了代码所有权的竖井，以及团队之间繁重的集成管理问题。|4062173|总而言之，这不仅仅是关于缩放的大小...这也是关于项目的内容。请随时分享有关您的环境的更多细节，以了解解决您环境中的规模问题的更具体方法。|4062174|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Scaling scrum or any agile approach is dependent on your environment.

If you have multiple projects with multiple teams, scaling is simply sharing best practices across teams. As soon as you start requiring integration between systems/projects, be wary. Tighter integration between teams is preferable at that point.

If you have one large project (I had a team of 45 at one point), there are different approaches to scaling. We chose to keep one team with multiple standups - developer standup separate from BA/QA standup. The iteration manager attended both and at least one from each side attended the other. We had one card wall, but it included pre-iteration stuff (stories in process of analysis, production bugs to chase) and post-iteration stuff (release/deployment work). 

I've also been a part of one very large project with many scrum teams (~20 teams - some distributed - ranging from 10-20 members each). Each had separate standups, and there was a scrum-of-scrums and even a scrum-of-scrum-of-scrums. I think we made a mistake by segmenting the teams by functional area rather than workflows. Our segmentation created silos of code ownership with onerous integration management issues between teams.

In sum, it's not just about size for scaling... it's also about the content of the project. Feel free to share more specifics about your environment to hear more specific approaches to addressing scale in your environment.

blocks|key|281811|text|敏捷伸缩性很好。这不是一门火箭科学。事实上，这一切都是关于模块化的。软件开发是一个复杂的自适应系统(Complex+Adaptive+System，简称CAS+)，和几乎所有的CAS一样，它具有更好地管理复杂性的模块()。Scrum+of+Scrum是开发过程扩展的一种可能的模块化方法。功能部门(开发人员、QA等)是另一种模块化方法。最糟糕的情况是，在大型项目中根本没有模块。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|281812|根据项目的性质，团队可能会决定哪些模块将为项目工作。一般的模式是组成几个团队来处理一些低内聚模块。每个团队都应该是完全自主的，但与其他团队的交互应该很好。|281813|例如，CAS中的类比是人体。我们有心脏和肝脏等器官。它们是通过神经系统/血液等相互作用的独立模块(细胞组:)。|281814|entityMap^0|T|3|0|17|5|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

Agile scales fine. It is not a rocket science. In fact it is all about modularity. Software development is a CAS (Complex Adaptive System) and, as almost any CAS, it has modules to rule the complexity better. Scrum of Scrums is one of the possible modular approach for development process scaling. Functional divisions (Developers, QA, etc) is an another modular approach. The worst case is when you do not have modules at all in a large project. 

Depending on a project nature, team may decide what modules will work for the project. General pattern is to form several teams that work on some low cohesion modules. Each team should be quite autonomous, but interaction with another teams should be good.

The analogy from CAS is a human body for example. We have organs like heart and liver. They are separate modules (teams of cells :) that interacts via nervous system/blood/etc.

In the earliest stages of planning the development of a new system, which development model to follow seems paramount. I've always held onto the belief that a classic waterfall (or hybrid waterfall/iterative prototyping) is the best approach for medium to large projects. It seems that once a project gets to be a certain size, the Agile/XP/Scrum paradigms can't account for complex requirements, a large team, the complexities between multiple sub-systems, the need for documentation, personnel changes, etc, etc.

What's the limit of such agile methodologies in terms of system size, team size, LOC, etc?

How big is too big for XP/SCRUM?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在规划新系统开发的最早阶段，遵循哪种开发模型似乎是最重要的。我一直坚信，经典的瀑布(或混合瀑布/迭代原型)是大中型项目的最佳方法。似乎一旦项目达到一定的规模，Agile/XP/Scrum范例就无法考虑复杂的需求、庞大的团队、多个子系统之间的复杂性、文档需求、人员变动等。这种敏捷方法在系统规模、团队规模、LOC等方面的限制是什么？

问多大对于XP/SCRUM来说是太大了？
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多大对于XP/SCRUM来说是太大了？EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多大对于XP/SCRUM来说是太大了？
EN