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