敏捷不适合哪些情况？

多年来,我一直在听力和阅读敏捷.我拥有一两本书,我喜欢这个主意.

我终于处于可以在我工作的地方滚动这样的东西的位置,但我非常担心这是否适合我们:

这个没有最小尺寸吗？对于一个为期三到四周的项目,前期大设计必须更有效...对吗？

我们的客户通常需要固定价格.他们需要知道他们正在处理什么,除非在我们遇到明显黑洞的特殊情况下,即使这样人们也更容易接受上限.那么,如果您正在使用能够容忍持续需求变更的流程,您如何提供报价？

我知道敏捷可能会在更复杂的项目中提供更好的成功几率,但是它不会增加客户的成本吗？当然还有未考虑的成本 - 也许我们回到了这里的最小尺寸问题.

您如何在世界范围内向客户解释这种反直觉的方法？非技术性的利益相关者可能没有经验来围绕瀑布以外的任何事物.

即使是内部项目,也有预算.我错过了什么？

好像最近对敏捷有一些强烈的反对意见.还有其他事情会很快开始起作用吗？

注意:我们是一家5开发商店,项目从一天或两天一直持续到几个月.我不相信有一种方法可以统治它们,但是找到足够灵活的东西以便我们能够适应所有项目会很棒.

非常感谢!

布莱恩麦凯

我不认为一种方法可以统治它们.对不起.我坚信为正确的项目找到合适的模型.例如,如果您进入手术并且您知道让您保持活着的机器是如何在快速迭代循环中开发的,并且前期设计很少,您会感觉如何.

但无论如何,关于你的问题.我非常相信敏捷方法,保持你的迭代简短,专注于用户想要的东西,而不是建立战舰,而只是建立你所需要的.我想说95%的项目都可以使用敏捷方法,如果不能,通常是文化问题,而不是项目问题.

现在,就BDUF(Big Design up Front)而言,我们在一个为期4个月的项目中拥有20人团队取得了巨大的成功,我们将该项目分解为3个四周的周期,在每个周期的开始我们都会遇到一个房间,并说这是我们需要建立的,这是我们将如何构建它,我们采取了我们的接口看起来像什么,我们需要什么数据等...但它只是一个刺,我们然后回到我们的办公桌前,无论谁拥有各种各样的碎片都冲了出来.

基本上,我们提前做了足够的BDUF来启动团队(并确保我们满足所有业务要求).我们曾经把这些会议称为开发者日,这是一个快速启动团队的好方法.如果您有现金将团队带到场外,您可以将它们塞进酒店的会议室,给他们提供大量垃圾并观察果汁的流动情况.

简单的解决方案有两个步骤:

不要估算成本和项目计划,成本估算和时间表功能

测量并记录足够的信息以计算您的速度和估计误差

如果可能的话,从小到内部开始获得一些基数.如果您仍想进行"大型前期设计",请针对个别功能进行操作.这将有助于您的初步估算更准确,以及您熟悉的"功能"粒度.

注意:这只有在客户承诺尽自己的责任,即为开发人员提供高度可用性(回答问题,编写故事和测试描述等),并且在迭代期间不改变主意时才有效.

祝你过渡顺利,让我们知道它是怎么回事!

到目前为止,我看到的最大禁忌症是价值观不匹配.极限编程依赖于尊重,沟通,反馈,勇气和简单.在基于不兼容值的行为的组织中,应用XP将导致摩擦并且不会导致任何持久更改(IME).