多年来我一直在听说和阅读有关敏捷的内容。我有一两本书是关于它的，我喜欢这个想法。
我终于可以在我工作的地方推出这样的东西了，但我非常担心这是否适合我们:
- 这没有最小尺寸吗？对于三到四个星期的项目来说，预先的大型设计必须更加高效......对吧？
- 我们的客户通常要求固定价格。他们需要知道他们正在处理什么，除非在特殊情况下我们面临着一个明显的黑洞，即使这样人们也更愿意戴帽子。那么，如果您要采用能够容忍持续需求变更的流程，如何提供报价呢？
- 我知道敏捷可能会在更复杂的项目中提供更大的成功几率，但它不会增加客户的成本吗？当然，还有不考虑的代价 - 也许我们又回到了最小尺寸问题。
- 您究竟会如何向客户解释这种违反直觉的方法？非技术利益相关者可能没有经验了解瀑布之外的任何事物。
- 即使是内部项目，也有预算。我错过了什么？
- 最近似乎出现了一些针对敏捷的强烈抵制。其他东西很快就会开始受到关注吗？
注意:我们是一家 5 人开发工作室，项目范围从一两天到几个月不等。我不相信有一种方法可以统治所有这些，但如果能找到一种足够灵活的方法来适应我们所有的项目，那就太好了。
非常感谢!
布莱恩·麦凯
最佳答案
我不认为一种方法可以统治所有这些。对不起。我坚信为正确的项目找到正确的模型。例如，如果您正在进行手术，并且您知道维持您生命的机器是在快速迭代周期中开发的，几乎没有预先设计，您会有什么感觉。
但无论如何，还是回答你的问题。我非常相信敏捷方法，保持迭代简短，专注于用户想要的东西，而不是 build 战舰，而只 build 你所需要的东西。我想说 95% 的项目可以使用敏捷方法，如果不能，通常是文化问题，而不是项目问题。
现在就 BDUF(大设计预先)而言，我们的 20 人团队在一个为期 4 个月的项目中取得了巨大成功，我们将该项目分解为 3 个四周的周期，在每个周期开始时我们所有人都在一个房间里见面，然后说好吧，这就是我们需要构建的东西，这就是我们将如何构建它，我们尝试了我们的界面是什么样子，我们需要什么数据等等......但这只是尝试，然后我们回到自己的办公 table 前，无论谁拥有这些不同的部件，都会清除详细信息。
本质上，我们预先做了足够的 BDUF 来启动团队(并确保我们满足所有业务需求)。我们过去将这些 session 称为“开发者日”，这是启动团队的好方法。如果您有现金，可以将团队带离现场，您可以将他们塞到酒店的 session 室里，给他们喂很多垃圾，然后观察果汁的流动。
关于agile - 敏捷在哪些情况下是不合适的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/348611/