Architecture XP/SCRUM有多大？

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

---

这种敏捷方法在系统规模、团队规模、LOC等方面有什么限制？

我认为没有边界，毕竟scrum的所有想法都来自汽车制造业，这对人来说是相当大的。大项目的关键是，你需要从一个小团队开始，并随着时间的推移不断成长。保持独立的团队，通过一个又一个的Scrum进行交互，这样它就可以扩展，如果人们愿意协作，那么它就会工作。我们的生意总是这样：分而治之。将大难题分解为更小的可管理块。

在一个团队中，沟通渠道与（N*N-1）/2成比例，作为上限，因此可以松散地视为O（N^2）。敏捷团队的分散性意味着没有中心参考点，交流将比有这样的参考点更接近上限

如果您有书面规范和更正式的结构（请参阅规范文档的讨论），则通信更接近于中心辐射模型，该模型具有更接近O（N）通道（适用于项目中的N名员工）。我看到的大多数经验法则评论都将敏捷团队的最佳点设置为6或更少，上限设置为10左右，尽管您的里程数可能会有所不同

---

在PFS文章中，Joel（是的，Joel）讨论了a的角色，其角色是开发和拥有规范。《无痛功能规范》系列非常详细地介绍了这一点，非技术管理人员也非常容易理解——我已经向很多人介绍了这篇文章。

将Scrum/XP描绘成一系列迷你瀑布。最初，您希望做一个前期工作，以获得一个良好的、定义良好的积压工作。不一定是整个系统，我认为一旦你获得了一到两个sprint值的产品积压项目，是时候开始sprint了。在sprint的同时，您应该创建额外的pbi（并适当地重新确定它们的优先级）

其思想是，您可以在系统完全定义之前获得交付的业务价值

可以使用“Scrum of Scrum”扩展Scrum

来自Scrum联盟的是关于举行Scrum会议的Scrum：

scrum of scrum会议是将scrum扩展到大型项目团队的一项重要技术。这些会议允许小组讨论他们的工作，特别关注重叠和整合的领域

---

《敏捷和迭代开发》一书也提到了这个问题。

敏捷可以很好地扩展。这不是一门火箭科学。事实上，这一切都与模块化有关。软件开发是一个CAS（复杂适应系统），与几乎所有CAS一样，它具有更好地控制复杂性的模块。Scrum中的Scrum是开发过程扩展的可能模块化方法之一。功能部门（开发人员、QA等）是另一种模块化方法。最糟糕的情况是在大型项目中根本没有模块

根据项目的性质，团队可以决定哪些模块适用于该项目。一般的模式是组建几个团队，在一些低内聚模块上工作。每个团队都应该是自主的，但与其他团队的互动应该是良好的

CAS的类比是以人体为例。我们有心脏和肝脏这样的器官。它们是独立的模块（细胞团队：），通过神经系统/血液等相互作用。

看看伯尼·汤普森的作品

它概述了他在微软扩展Scrum/XP时遇到的许多问题和权衡，并提供了一些非常周到和有趣的解决方案

---

同一个博客上的其他帖子也讨论了您关心的这些规模问题——在我看来，这是“成人敏捷”思想的金矿。

扩展scrum或任何敏捷方法都取决于您的环境

如果您有多个项目和多个团队，那么扩展就是跨团队共享最佳实践。一旦您开始需要系统/项目之间的集成，请保持警惕。在这一点上，团队之间更紧密的整合是可取的

如果您有一个大型项目（我曾经有一个45人的团队），那么有不同的扩展方法。我们选择保持一个团队有多个站立-开发者站立与BA/QA站立分开。迭代经理同时参加，双方至少有一人参加。我们有一个卡片墙，但它包括迭代前的东西（分析过程中的故事、要追踪的生产bug）和迭代后的东西（发布/部署工作）

我也参与过一个非常大的项目，有很多scrum团队（大约20个团队，有些是分布式的，每个团队有10-20名成员）。每个人都有各自的站姿，有一堆堆堆，甚至有一堆堆堆。我认为我们犯了一个错误，按功能领域而不是工作流程划分团队。我们的细分造成了代码所有权的孤岛，团队之间存在着繁重的集成管理问题

---

总之，这不仅仅是规模的缩放。。。这也是关于项目的内容。请随意分享有关您环境的更多细节，以了解解决您环境中规模问题的更具体方法。

我的经验是，将敏捷的任何方面描述为“迷你瀑布”都会让团队陷入困境