多年来，我一直在听到和阅读有关敏捷的信息。我拥有一两本书，我喜欢这个主意。
我终于可以在我工作的地方推出这样的东西了，但我非常担心这是否适合我们：
注意：我们是一个 5 开发商店，项目从一两天到几个月不等。我不相信有一种方法可以统治所有这些，但是找到足够灵活的方法来适应我们所有的项目会很棒。
非常感谢！
布赖恩·麦凯
我不认为一种方法可以统治所有这些。对不起。我坚信为正确的项目找到正确的模型。例如，如果您正在接受手术并且您知道让您保持生命的机器是在快速迭代周期中开发的，并且前期设计很少，您会有什么感觉。
但无论如何，关于你的问题。我非常相信敏捷方法，保持迭代简短，专注于用户想要的东西，而不是建造战舰，而只建造你需要的东西。我想说 95% 的项目可以使用敏捷方法，如果不能，这通常是文化问题，而不是项目问题。
现在就 BDUF（前期大设计）而言，我们与一个 20 人的团队在一个为期 4 个月的项目中取得了巨大的成功，我们将项目分解为 3 个 4 周的周期，在每个周期开始时，我们都会在一个房间，然后说好的，这就是我们需要建造的东西，这就是我们将如何建造它，我们试了一下我们的界面会是什么样子，我们需要什么数据等等......但这只是一个试探，我们然后回到我们的办公桌前，拥有各种作品的人把细节都刷了出来。
本质上，我们预先做了足够多的 BDUF 来启动团队（并确保我们涵盖了所有业务需求）。我们过去将这些会议称为“开发者日”，这是启动团队的好方法。如果您有现金，可以将团队带离现场，您可以将他们塞进酒店的会议室，喂他们很多垃圾，然后看着果汁流淌。
简单的解决方案有两个步骤：
如果可能的话，从小处和内部开始，以获得一些基数。如果您仍想进行“大型前期设计”，请针对个别功能进行。这将有助于您的初始估计更准确，以及您对“功能”的粒度感到满意。
注意：这只有在客户承诺尽其本分时才有效，即对开发人员高度可用（回答问题、编写故事和测试描述等），并且在迭代期间不改变主意
祝您过渡顺利，让我们知道进展如何！
到目前为止，我见过的最大禁忌是价值观不匹配。极限编程依赖于尊重、沟通、反馈、勇气和简单。在一个基于不相容价值观行事的组织中，应用 XP 将导致摩擦，不会导致任何持久变化 (IME)。
这取决于你问谁以及他们是否相信敏捷......
至于这个：
我想找到一种方法来统治它们。
http://www.opaquelucidity.com/facepalm.jpg
你所有的客户都一样吗？您已经说过持续时间差异很大……您为什么认为各种不同的项目都适合一种单一的方法？
寻找让敏捷实践失败的原因……如果你得到 1-2 个未成年人积分，你会找到克服它们的方法。否则，您正在寻找失败。而一旦你失败了，你就再也没有机会尝试了。即使失败的不是敏捷实践……
从内部项目开始，了解您的敏捷流程是如何工作的，以及如何最好地估计事情需要多长时间。当你觉得你已经准备好接受真正的客户时，选择一个你非常信任的客户，然后选择一个相当小的项目开始。这里的关键是你想建立信心。解释你在做什么以及为什么——你想为他们提供更好的软件，更快地反映他们的优先事项——并向他们展示你是如何在内部项目中取得成功的。兑现你的承诺——因为我相信敏捷方法，我认为这不会太难做到。
一旦你成功了（并且让客户赞叹不已），他们会要求你在他们的其他项目中使用这种方法。一旦您有了一个满意的客户，您就可以开始向其他客户扩展，并使用您的第一个客户作为参考。很快你就会发现你正在使用的做法非常有效，以至于它们也潜入了你的“瀑布”过程。最终，你会像我们其他敏捷者一样喝足够多的kool-aid。:-)
哦。是的，有些项目并不特别适合敏捷方法。诸如生命关键系统、核电站控制、高度监管的行业之类的东西都可能需要比敏捷所允许的更多的前期设计和流程。我们大多数人从不从事这些项目。
Scott Ambler 是对此做出回答的权威人士之一。他的文章很好地突出了固定价格的一些陷阱，但这绝对是可能的。Alistair Cockburn也同意这也是可能的，但指出您从敏捷中获得的一些好处在固定价格合同中丢失了。
“前期大设计”（BDUF）的一个基本问题是花费时间设计很少使用的功能，如果有的话。如果您需要在一个月或更短的时间内完成产品，则必须事先明确定义问题。
至于失败的成本，这是一个非常合理的担忧。敏捷的一个好处是，与遵循瀑布方法的项目相比，任何失败都发生得更早，成本也更低。能够从这些失败中吸取教训并最终获得好的产品并不是瀑布方法可以提供的结果。联邦政府在遵循瀑布方法和 BDUF 的软件项目中有相当多的引人注目的失败。我在博客上写过FBI 的 Virtual Case File 项目失败。
您使用的方法将取决于您与团队的匹配程度，以及您正在构建的软件类型和您的客户。对于不适合敏捷方法的项目，tvanfosson 是完全正确的。我同意肯特贝克关于价值观不匹配的观点。从文化的角度来看，一些组织还没有为敏捷做好准备，不管它在其他地方的优点和成功。
让我逐点回答您的担忧：
这没有最小尺寸吗？对于三到四个星期的项目来说，前期的大型设计必须更有效率......对吗？
我不确定是什么让您认为在纸上绘制矩形一定比重构代码更快。
无论如何，即使是这样，BDUF 是否回报的问题更多地取决于您在项目期间期望的学习量，而不是项目规模。在实施系统时，您期望了解的有关设计、要求等的越多，您的前期设计就越浪费。
我还没有遇到过在实施系统时没有学到重要知识的项目。
我们的客户通常要求固定价格。他们需要知道他们在处理什么，除非在特殊情况下，我们遇到了一个明显的黑洞，即使这样，人们也更愿意戴上帽子。那么，如果您要采用能够容忍持续需求变化的流程，您如何提供报价呢？
只接受不会改变总工作量的需求变更。也就是说，当新的需求出现时，放弃不太重要的需求。让客户做出决定，这样他就可以获得最大的收益。
您不会以这种方式获得敏捷的所有好处，但据我所知，它与固定价格所能获得的一样好。
我知道敏捷可以在更复杂的项目中提供更好的成功几率，但它不会增加客户的成本吗？
您是否建议以敏捷方式运行的项目比传统项目成本更高？实际上，有些公司的情况正好相反，最多可以降低 50% 的成本。
当然，还有不考虑的代价——也许我们又回到了最小尺寸问题。
由于早期的反馈，敏捷项目的失败成本会降低。您可以更早地注意到失败 - 因此决定取消项目。
您将如何向客户解释这种违反直觉的方法？非技术利益相关者可能没有经验来围绕瀑布之外的任何事情。
即使是内部项目，也有预算。我错过了什么？
我不知道。敏捷适用于预算 - 实施最高优先级的功能，直到预算用完。您拥有可以用这笔钱实施的最有价值的系统。
最近似乎有人反对敏捷。其他东西会很快开始受到关注吗？
从一开始就遭到强烈反对。随着它变得越来越流行（而且确实如此！），您也很自然地会看到更多的反弹。
精益软件开发正在获得很大的吸引力。不过，它不是与敏捷开发的竞争，而是互补的。社区实际上是相当重叠的。
关于“一种方法来统治它们”——看看 Alistair Cockburn 的“Crystal”敏捷过程系列。他（相当有能力地）争辩说，每个项目都需要它自己的过程，而且即使是一个项目的过程也需要随着项目的进行而改变。他提供了一个轻量级的框架来开发你的流程。
正如我所想的那样，Scrum 也是如此。Scrum 实际上并没有告诉你太多关于如何运行你的项目，而是更多地告诉你如何找出什么在起作用，以及如何让团队适应这些发现。
我不一定会将敏捷用于预先知道所有内容的项目。当变化极有可能发生时，敏捷工作得很好。万一变化不大可能，人们可以使用预测或瀑布过程来管理这样一个项目。
对您的特定问题的回答如下： 这没有最小尺寸吗？ 从实践的角度来看，敏捷与规模无关。话虽如此，项目越大，发生变化的可能性就越大。如果一个项目足够小，那么一切都是可知的，改变是不可能的。
对于三到四个星期的项目来说，前期的大型设计必须更有效率......对吗？ 由 TDD 驱动的简单和渐进式设计总是更有效。您应该预先完成足够的架构，以了解主要部分的位置。不要用架构来猜测你要做什么，只捕捉已知的东西。让简单而渐进的设计使您能够在构建应用程序时改进您的详细设计。
我们的客户通常要求固定价格。他们需要知道他们在处理什么，除非在特殊情况下，我们遇到了一个明显的黑洞，即使这样，人们也更愿意戴上帽子。那么，如果您要采用能够容忍持续需求变化的流程，您如何提供报价呢？ 最初需要一些教育。您将建立一个产品积压工作，要求产品负责人对其进行优先排序，然后对工作进行初步评估。这确实要求产品负责人在积压订单上为固定投标建立一条切割线。然后你调整团队和持续时间以满足估计。然后合同规定您将在确定的时间范围内使用团队的固定容量。这将使产品负责人在对积压工作进行优先调用时专注于时间框和预算。
我知道敏捷可以在更复杂的项目中提供更好的成功几率，但它不会增加客户的成本吗？ 一个成功的项目总是比一个失败的项目便宜。
您将如何向客户解释这种违反直觉的方法？非技术利益相关者可能没有经验来围绕瀑布之外的任何事情。 教育（即敏捷训练营）和访问成功的敏捷团队将大有帮助。然后让团队继续前进。工作会让他们忙碌，结果会卖给他们。
即使是内部项目，也有预算。我错过了什么？最近似乎有人反对敏捷。其他东西会很快开始受到关注吗？ 我知道的唯一反对意见是敏捷项目没有有效地使用工程实践（即，仅 SCRUM）。使用 SCRUM 和 XP 有效的团队将在交付和可持续速度方面做得很好。
在开发新的空中交通管制系统时，我建议反对敏捷。
恕我直言：
敏捷与否，您应该在实施之前设计已知的东西——在“只是尝试一些东西”之前。递归地将事物分解为可管理的任务，然后设计已知的东西，无论是细节还是宽泛的概念。诸如 UI 和日常业务需求之类的东西在开发之前几乎从来都不是一成不变的，而飞机模拟功能可能是。
One way to try to "sell" agile to customers is grant them two options: 1. Waterfall, where there is no cancelling as long as we (the devs) meet our end of the agreement. 2. Agile, where you get weekly updates on status, hands-on demos as they become available, and the right to discontinue service every 2 weeks (in case you don't like our work).
