什么情况下敏捷是不合适的？
多年来，我一直在听说和阅读有关敏捷的内容。我有一两本关于它的书，我喜欢这个主意。
我终于可以在我工作的地方推出这样的东西了，但我很担心这是否适合我们：
- 这个没有最小尺寸吗？对于三四周的项目来说，前期的大型设计必须更有效率.对吗？
- 我们的客户通常要求固定的价格。他们需要知道他们在处理什么，除非在特殊情况下，我们面对的是一个明显的黑洞，即使这样，人们也会对帽子感到更舒服。那么，如果您要使用的是一个可以容忍正在进行的需求更改的流程，那么您如何提供报价呢？
- 我知道敏捷可能在更复杂的项目中提供更好的成功机会，但它不会给客户带来成本上涨吗？当然，这也是失败的代价--也许我们又回到了最小规模的问题上。
- 在这个世界上，你会怎么解释这种违反直觉的方法呢？非技术利益相关者可能没有经验，无法在瀑布以外的任何事情上周旋。
- 即使是内部项目，也有预算。我遗漏了什么？
- 最近似乎出现了一些针对敏捷的反弹。还有什么东西会很快开始吸引人吗？
注意:我们是一个5开发商店，项目从一天到两天一直持续到几个月。我不相信有一种方法来管理它们，但如果能找到足够灵活的方法来适应我们所有的项目，那就太好了。
非常感谢!
布赖恩MacKay
回答 11
Stack Overflow用户
发布于 2008-12-08 04:02:39
我不认为任何一种方法都能统治它们。我很抱歉。我是一个坚定的信念为正确的项目找到正确的模式。例如，如果您从事外科手术，并且您知道使您保持活力的机器是在快速迭代循环中开发的，并且很少预先设计，您会有什么感觉。
但不管怎样，关于你的问题。我是敏捷方法的忠实拥护者，我相信保持迭代时间短，专注于用户想要的东西，而不是构建战舰，而只是构建您所需要的。我认为95%的项目可以使用敏捷方法，如果不能的话，这通常是一个文化问题，而不是项目问题。
现在，就BDUF ()而言，我们在一个为期4个月的项目中与一个20人的团队取得了巨大的成功，我们把这个项目分解为3个四周的周期，在每个周期开始时，我们都在一个房间里见面，并说:好的，这是我们需要构建的东西，这是我们要构建的，我们尝试了一下我们的界面会是什么样子，我们需要什么数据-- etc...But只是一次尝试，然后我们回到我们的办公桌前，不管是谁拥有了这些细节。
本质上，我们预先做了足够的BDUF来启动团队(并确保我们涵盖了所有的业务需求)。我们过去称这些会话为开发人员日，这是启动团队的好方法。如果你有现金，让团队离开现场，你可以把他们塞在酒店的会议室里，喂他们很多垃圾，看着果汁流动。
Stack Overflow用户
发布于 2008-12-08 04:23:33
简单的解决方案有两个步骤：
- 不要估算项目的成本和时间表，估算特性的成本和时间表
- 测量和记录足够的信息来计算速度和估计误差。
如果可能的话，从小内部开始，得到一些基本数字。如果你仍然想做‘大的预先设计’，做它的个人特点。这将帮助您的初步估计更加准确，也有助于您熟悉“特性”的粒度。
注意:只有当客户致力于完成他们的任务，即开发人员高度可用(回答问题、编写故事和测试描述等)，并且在迭代过程中不改变主意时，这才能奏效。
祝你顺利过渡，并让我们知道它是如何进行的！
Stack Overflow用户
发布于 2008-12-08 18:14:22
到目前为止，我看到的最大禁忌是价值错配。极端编程依赖于尊重、沟通、反馈、勇气和简单。在基于不兼容值的组织中，应用XP将导致摩擦，不会导致任何持久的更改(IME)。
https://stackoverflow.com/questions/348611
复制相似问题
腾讯云开发者
