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