在规划新系统开发的最初阶段，遵循哪种开发模式似乎是最重要的。我一直坚信经典瀑布（或混合瀑布/迭代原型）是中型到大型项目的最佳方法。似乎一旦项目达到一定规模，Agile / XP / Scrum范例就无法解决复杂的需求，庞大的团队，多个子系统之间的复杂性，文档需求，人员变动等等，等
这种敏捷方法在系统规模，团队规模，LOC等方面的限制是什么？
答案 0 :(得分：6)
可以使用“Scrum of Scrums”缩放Scrum。
从Scrum联盟来advice进行Scrum of Scrums会议：
scrum会议的scrum是将Scrum扩展到大型项目团队的重要技术。这些会议允许团队成员讨论他们的工作，尤其关注重叠和整合的领域。
敏捷和迭代开发一书也discuss这个问题。
答案 1 :(得分：2)
我不认为存在边界，毕竟scrum的想法来自汽车制造商，而且就人而言这是非常大的。大项目的事情是，你需要从一个小团队开始，并随着时间的推移而增长。保持通过Scrum of Scrums进行交互的单独团队，如果人们愿意进行协作，它将会扩展。就像我们的业务一样：分而治之。将重大难题分解为更小的可管理块。
答案 2 :(得分：2)
看看Bernie Thompson的this blog post。
它概述了他在微软扩展Scrum / XP时遇到的许多问题和权衡，并且有一些非常有思想和有趣的解决方案。
在同一个博客上还有其他帖子也处理这些与您有关的规模问题 - IMO它是关于“成年人敏捷”的想法的金矿。
答案 3 :(得分：1)
在团队中，通信信道与（N * N-1）/ 2成比例，因此可以宽松地被视为O（N ^ 2）。敏捷团队的分散性意味着没有中心参考点，并且沟通将比有这样的参考点更接近上限。
如果您有书面规范和更正式的结构（有关规范文档的讨论，请参阅Painless Functional Specification），通信更接近于轮辐模型，它更接近O（N）个通道（对于该项目的N名工作人员）。我见过的大多数经验法则评论都认为敏捷团队的最佳位置为6或更低，上限为10左右，尽管您的里程可能会有所不同。
在PFS文章中，Joel（是的， Joel）讨论了Programme Manager的角色，其作用是开发和拥有规范。无痛功能规范系列非常详细地介绍了这一点，并且非技术管理也非常容易使用 - 我在这篇文章中引用了不少人。
答案 4 :(得分：0)
Picture Scrum / XP作为一系列迷你瀑布。最初，您希望尽早做出好的，定义明确的待办事项。不一定是整个系统，我认为一旦你得到一到两个短跑的产品积压项目，就该开始冲刺了。在sprint的同时，你应该创建额外的PBI（并适当地重新设置它们的优先级）。
我们的想法是，您可以在系统完全定义之前获得业务价值。
答案 5 :(得分：0)
扩展scrum或任何敏捷方法取决于您的环境。
如果您有多个团队的多个项目，那么扩展只是在团队之间共享最佳实践。一旦开始要求系统/项目之间的集成，请小心谨慎。此时团队之间更紧密的整合是可取的。
如果您有一个大型项目（我的团队一次只有45人），则有不同的扩展方法。我们选择让一支球队保持多个立场 - 开发人员站立与BA / QA站立分开。迭代管理器参加了两个，并且每一方至少有一个参加了另一个。我们有一个卡墙，但它包括预迭代的东西（分析过程中的故事，追逐的生产错误）和迭代后的东西（发布/部署工作）。
我也参与了一个非常大的项目，其中包括许多scrum团队（约20个团队 - 一些分布式团队 - 每个团队10-20名成员）。每个人都有单独的站立，并且有一个Scrum-scrums，甚至scrum-scrum-of-scrums。我认为我们通过功能区域而不是工作流程来划分团队是错误的。我们的细分创建了代码所有权的孤岛，团队之间存在繁重的集成管理问题。
总之，它不仅仅是关于缩放的大小......它也与项目的内容有关。随意分享有关您环境的更多细节，以了解更具体的方法来解决您环境中的规模问题。
答案 6 :(得分：-1)
敏捷可以很好地扩展。它不是火箭科学。事实上，它完全是关于模块化。软件开发是CAS（复杂自适应系统），与几乎所有CAS一样，具有更好地统治复杂性的模块。 Scrum of Scrums是开发过程扩展的可能模块化方法之一。功能部门（开发人员，QA等）是另一种模块化方法。最糟糕的情况是，在大型项目中根本没有模块。
根据项目性质，团队可以决定哪些模块适用于项目。一般模式是组建几个团队，这些团队可以处理一些低内聚模块。每个团队都应该非常自主，但与其他团队的互动应该很好。
CAS的类比是人体。我们有心脏和肝脏等器官。它们是独立的模块（细胞团队:)，通过神经系统/血液等进行相互作用。