多年来，我一直在听取和阅读敏捷。我拥有一两本书，我喜欢这个主意。
我终于处于可以在我工作的地方滚动这样的东西的位置，但是我非常担心这是否适合我们：
注意：我们是一家5开发商店，项目从一天或两天一直持续到几个月。我不相信有一种方法可以统治它们，但是找到足够灵活的东西以便我们能够适应所有项目都会很棒。
非常感谢！
Brian MacKay
答案 0 :(得分：7)
我不认为一种方法可以统治它们。对不起。我坚信为正确的项目找到合适的模型。例如，如果您进入手术并且您知道保持活着的机器是在快速迭代循环中开发的，并且前期设计很少，您会感觉如何。
但无论如何，关于你的问题。我非常相信敏捷方法，保持你的迭代简短，专注于用户想要的东西，而不是建立战舰，而只是建立你所需要的。我想说95％的项目都可以使用敏捷方法，如果不能，那通常是文化问题，而不是项目问题。
现在，就BDUF（Big Design up Front）而言，我们在一个为期4个月的项目中拥有20人团队取得了巨大成功，我们将该项目分解为3个四周周期，在每个周期开始时我们所有人都在一个房间里相遇，并说好了我们需要建立的，这里是我们将如何构建它，我们采取了什么样的接口看起来像什么，我们需要什么样的数据等...但它只是一个刺然后我们又回到了办公桌前，无论是谁拥有各种各样的东西都冲了出来。
基本上我们提前做了足够的BDUF来快速启动团队（并确保我们满足所有业务要求）。我们曾经把这些会议称为开发者日，这是一个快速启动团队的好方法。如果您有现金将团队带到场外，您可以将它们塞进酒店的会议室，为他们提供大量的垃圾，并观察果汁的流动。
答案 1 :(得分：7)
简单的解决方案有两个步骤：
如果可能的话，从小到内部开始获得一些基数。如果您仍想进行“大型前期设计”，请针对个别功能进行操作。这将有助于您的初步估算更准确，以及您熟悉的“功能”粒度。
注意：这只有在客户承诺履行其职责的情况下才有效，即为开发人员提供高度可用性（回答问题，撰写故事和测试说明等），并且在迭代期间不改变主意
祝你过渡顺利，让我们知道它是怎么回事！
答案 2 :(得分：6)
到目前为止，我看到的最大禁忌症是价值观不匹配。极限编程依赖于尊重，沟通，反馈，勇气和简单。在基于不兼容值的行为的组织中，应用XP将导致摩擦并且不会导致任何持久更改（IME）。
答案 3 :(得分：4)
这取决于你问的是谁以及他们是否相信敏捷......
至于此：
我想找到一种方法来统治它们。
http://www.opaquelucidity.com/facepalm.jpg
您的所有客户都一样吗？你已经说过持续时间变化很大......为什么你认为所有不同的项目都适合单一的方法？
答案 4 :(得分：0)
寻找使敏捷练习失败的原因......如果你有1-2个未成年人的分数去找它，你会找到方法来解决它们。否则，你在寻找失败。一旦你失败了，你将没有机会尝试它。即使不是敏捷实践失败了......
答案 5 :(得分：0)
从内部项目开始，了解您的敏捷过程如何运作，以及如何最好地估计事情需要多长时间。当你觉得自己已经准备好迎接真正的客户时，选择一个你非常信任的人并选择一个相当小的项目开始。这里的关键是你要建立信心。解释您正在做什么以及为什么 - 您希望为他们提供更好的软件，以便更快地反映他们的优先事项 - 并向他们展示您在内部项目中取得成功的方式。承诺你的承诺 - 因为我相信敏捷方法，我认为这不会太难。
一旦您成功（并且让客户满意），他们会要求您在其他项目中使用该方法。一旦您拥有一个满意的客户，您就可以使用您的第一个客户作为参考，开始扩展到其他客户。很快你就会发现你正在使用的实践工作得非常好，以至于它们也会渗透到你的“瀑布”过程中。最终，你已经喝醉了足够的kool-aid就像我们其他的敏捷分子一样。 ： - ）
喔。是的，有些项目并不特别适合敏捷方法。生命关键系统，核电站控制，高度管制的行业等都需要比敏捷允许的更多的前期设计和流程。我们大多数人都没有参与这些项目。
答案 6 :(得分：0)
Scott Ambler是an answer对此的一个很好的权威。他的文章很好地突出了固定价格的一些陷阱，但这绝对是可能的。 Alistair Cockburn agrees它也有可能，但指出你从敏捷中获得的一些好处在固定价格合同中会丢失。
“大型设计前端”（BDUF）的一个基本问题是设计功能的时间很少（如果有的话）使用。如果您需要在一个月或更短的时间内完成产品，那么问题必须事先确定好。
至于失败的代价，这是一个非常合理的问题。敏捷的一个好处是，任何故障都可以比使用瀑布式方法的项目更早，成本更低。能够从这些失败中吸取教训并在最后获得一个好的产品并不是瀑布式方法可以提供的结果。联邦政府在瀑布方法和BDUF之后有相当多的高调软件项目失败。关于FBI的虚拟案例文件项目失败，我blogged。
您使用的哪种方法将根据您的团队与您正在构建的软件类型以及您的客户的适合程度来确定。对于那些不适合敏捷方法的项目，tvanfosson非常正确。我同意肯特贝克关于价值观不匹配的看法。一些组织从文化的角度来看，并没有为敏捷做好准备，无论其在其他地方的优点和成功如何。
答案 7 :(得分：0)
让我逐点回答你的问题：
这不是最小尺寸吗？ 前面的大设计必须更多 有效期为三到四周 项目......对吗？
我不确定是什么让你认为在纸上绘制矩形必须比重构代码更快。
无论如何，即使是这样，BDUF是否回报的问题将更多地取决于您在项目期间学习的程度而不是项目规模。在实施系统时，您对设计，要求等方面的了解越多，您的前期设计就越浪费。
我还没有遇到一个项目，在实施系统时我没有学到重要的东西。
我们的客户通常需要修复 价格。他们需要知道他们是什么 处理，特殊情况除外 我们在哪里面对一个明显的 黑洞，即便是人 盖帽更舒适。又怎样 如果你是，你能提供报价吗？ 采用宽容的过程 持续的需求变化？
仅接受不会改变总工作量的需求变更。也就是说，当新要求出现时，丢弃不那么重要的要求。让客户决定，以便他能获得最大的收益。
你不会以这种方式获得敏捷的所有好处，但据我所知，它与固定价格一样好。
据我所知，敏捷可能会在更复杂的项目中提供更好的成功几率，但这不会增加客户的成本吗？
您是否建议以敏捷方式运行的项目比传统项目更昂贵？实际上有些公司经历了相反的情况，成本降低了50％。
当然还有未考虑的成本 - 也许我们回到了这里的最小尺寸问题。
由于早期反馈，敏捷项目的失败成本下降。您可以更早地注意到失败 - 因此决定取消该项目。
您如何在世界范围内向客户解释这种反直觉的方法？非技术性的利益相关者可能没有经验来围绕瀑布之外的任何事情。
Why does Agile Software Development pay?
即使是内部项目，也有预算。我错过了什么？
我不知道。敏捷在预算方面运行良好 - 在预算用完之前实施最高优先级的功能。你拥有可以为这笔钱实施的最有价值的系统。
最近似乎对敏捷有一些反对意见。还有什么东西会很快开始获得吸引力吗？
从一开始就反对它。随着它变得越来越受欢迎（它就是！），你也会看到更多的反弹，这很自然。
精益软件开发正在获得很大的吸引力。它不是与敏捷开发的竞争，而是相互补充。社区实际上相当重叠。
关于“统治所有人的一种方法” - 看看Alistair Cockburn的“Crystal”敏捷过程系列。他认为（非常有竞争力）每个项目都需要它自己的流程，甚至一个项目的流程也需要在项目过程中进行更改。他为开发流程提供了一个轻量级框架。
和Scrum一样，我想到了。 Scrum实际上并没有告诉你如何运行你的项目，更多的是关于如何找出工作原理以及如何使团队适应这些发现。
答案 8 :(得分：0)
我不一定会将敏捷用于预先知道所有事情的项目。当变化很可能时，敏捷很有效。如果不能改变，可以使用预测或瀑布流程来管理这样的项目。
回答您的具体问题如下： 这不是最小尺寸吗？ 从实际角度来看，敏捷与规模无关。话虽如此，项目越大，发生变化的可能性就越大。如果一个项目很小，那么一切都是可知的，并且不太可能发生变化。
预先进行大型设计必须在三到四周的项目中更有效...对吗？ 由TDD驱动的简单和进化设计总是更有效。你应该在前面做足够的架构，以了解主要部件的位置。不要使用架构来猜测你将要做什么，只捕获可知的东西。让简单的进化设计使您能够在构建应用程序时改进您的详细设计。
我们的客户通常需要固定价格。他们需要知道他们正在处理什么，除非在我们遇到明显黑洞的特殊情况下，即使这样人们也更容易接受上限。那么，如果您的流程能够容忍持续的需求变更，那么如何提供报价呢？ 最初需要一些教育。您将建立产品待办事项，要求产品所有者对其进行优先排序，然后对工作进行初步估算。这确实要求产品所有者在固定出价的积压工作上建立切割线。然后你调整团队和持续时间以满足估计。然后合同规定你将使用团队的固定容量来确定时间框。这将使产品所有者专注于在积压时进行优先呼叫时的时间框和预算。
我知道敏捷可能会在更复杂的项目中提供更好的成功几率，但是它不会增加客户的成本吗？ 一个成功的项目总是比失败的项目便宜。
您如何向全世界的客户解释这种反直觉的方法？非技术性的利益相关者可能没有经验来围绕瀑布之外的任何事情。 教育（即敏捷训练营）和访问成功的敏捷团队将有很大帮助。然后让团队继续前进。这项工作将使他们忙碌，结果将会出售。
即使是内部项目，也有预算。我错过了什么？ 好像最近对敏捷有一些强烈的反对意见。还有什么东西会很快开始获得吸引力吗？ 我所知道的唯一反应是敏捷项目没有有效地使用工程实践（即仅限SCRUM）。使用SCRUM和XP effectivley的团队将在交付和可持续的步伐中做得很好。
答案 9 :(得分：-1)
我建议在开发新的空中交通管制系统时反对敏捷。
答案 10 :(得分：-1)
IMHO：
敏捷与否，你应该在实施之前设计已知的东西 - 在“只是尝试东西”之前。递归地将事情分解为可管理的任务，然后设计已知的内容，无论是细节还是广泛的概念。像UI和日常业务需求这样的东西在开发之前几乎不会一成不变，而飞机模拟功能可能就是这样。
尝试向客户“销售”敏捷的一种方法是给予他们两种选择： 1.瀑布，只要我们（开发者）符合协议的终止，就不会取消。 2.敏捷，每周更新状态，动手演示，以及每两周停止服务的权利（如果您不喜欢我们的工作）。
