什么情况下敏捷是不合适的?[闭门]

我不认为一种方法可以统领所有这些。我很抱歉。我坚信为正确的项目找到正确的模式。例如,如果你正在做手术,并且你知道让你活下去的机器是在一个快速的迭代周期中开发的,前期设计很少,你会有什么感觉。

但不管怎样,请回答你的问题。我非常相信敏捷方法,即缩短迭代周期,关注用户的需求,而不是构建战舰,而是只构建您需要的东西。我想说95%的项目都可以使用敏捷方法,如果他们不能,这通常是一个文化问题,而不是项目问题。

现在,就BDUF(大型前期设计)而言,我们在一个为期4个月的项目中与一个20人的团队取得了巨大的成功,我们将项目分解为3个四周的周期,在每个周期开始时,我们都在一个房间里会面,并说好的,这是我们需要构建的,这是我们将如何构建它,我们尝试了我们的界面,我们需要什么样的数据等等……但这只是一个尝试,然后我们回到我们的办公桌上,不管是谁拥有这些不同的东西,我们都会把细节一览无余。

基本上,我们在前期做了足够多的BDUF来启动团队(并确保我们涵盖了所有业务需求)。我们过去称这些会议为开发者日,这是一个很好的启动团队的方式。如果你有现金,可以把团队带离现场,你可以把他们塞进酒店的会议室,给他们喂很多垃圾,看着他们的果汁流出来。

1. 不要估算项目的成本和进度,估算项目的成本和进度 特征

如果可能的话,从小型和内部开始,以获得一些基本数字。如果你仍然想做“大的前端设计”,那么就针对个别功能进行设计。这将有助于您的初始估计更加准确,以及您对“功能”的粒度感到满意。

只有当客户承诺尽自己的责任时,这才有效 ,也就是说,对开发人员高度可用(回答问题、编写故事和测试描述等),以及 在迭代过程中不改变他们的想法

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

关于这一点:

http://www.opaquelucidity.com/facepalm.jpg

寻找敏捷实践失败的原因。。。若你们得到了1-2分,你们会找到方法去超越他们。否则,你就要失败了。一旦你失败了,你就再也没有机会尝试了。即使不是敏捷实践失败了。。。

一旦你成功了(让客户惊叹),他们会要求你在他们的其他项目中使用这种方法。一旦你有了一个满意的客户,你就可以开始扩展到其他客户,将你的第一个客户作为参考。很快,您就会发现您正在使用的实践工作得非常好,以至于它们也潜入了您的“瀑布式”流程中。最终,你会喝得足够多的kool aid,像我们其他敏捷专家一样。:-)

Scott Ambler是一位优秀的管理者 an answer 在这个问题上。他的文章很好地突出了固定价格的一些缺陷,但这绝对是可能的。阿利斯泰尔·科伯恩 agrees

至于失败的代价,这是一个非常合理的担忧。敏捷的一个好处是,任何失败都会发生得更早,而且成本远远低于遵循瀑布方法的项目。能够从失败中吸取教训并最终获得一个好的产品并不是瀑布式方法所能提供的结果。联邦政府有相当数量的遵循瀑布方法论和BDUF的软件项目高调失败。我已经 blogged 关于FBI的虚拟案件档案项目失败。

您使用的方法论取决于您的团队与您正在构建的软件类型以及您的客户。对于不适合敏捷方法的项目,tvanfosson是非常正确的。我同意肯特·贝克的观点。从文化的角度来看,有些组织还没有做好敏捷的准备,不管它在其他地方的优点和成功。

让我逐一回答你的关切:

前面的大设计必须更大 有效期为三到四周 项目正当

我不知道是什么让你认为在纸上画矩形一定比重构代码快。

无论如何,即使是这样,BDUF是否会有回报的问题更多地取决于你在项目期间期望学习多少,而不是项目规模。在实现系统时,您对设计、需求等了解得越多,前期设计就浪费得越多。

我还没有遇到过一个在实施系统时没有学到重要东西的项目。

价格。他们需要知道他们在干什么 处理,特殊情况除外 在这里,我们遇到了一个显而易见的问题 戴帽子更舒服。那怎么办 如果你是,你能提供一个报价吗 遵循一个宽容的过程

只接受不改变总工作量的需求变更。也就是说,当新需求出现时,放弃不太重要的需求。让客户自己决定,这样他就能得到最划算的回报。

你不会以这种方式获得敏捷的所有好处,但据我所知,它是固定价格所能获得的最好的。

你是否认为以敏捷方式运行的项目比传统项目成本更高?实际上,有一些公司经历了相反的情况,成本降低了50%。

当然还有失败的代价——也许我们回到了这里的最小尺寸问题。

你究竟如何向客户解释这种反直觉的方法?非技术利益相关者可能没有经验去思考瀑布之外的任何事情。

Why does Agile Software Development pay?

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

我不知道。敏捷可以很好地处理预算——在预算用完之前实施最高优先级的特性。你有最有价值的系统,可以用这些钱来实现。

最近似乎有人反对敏捷。其他东西很快就会开始吸引人了吗?

从一开始就有人反对它。随着它变得越来越流行(确实如此!),你也很自然地会看到更多的反弹。

精益软件开发正在获得巨大的吸引力。不过,它与敏捷开发并没有竞争,而是互补的。这些社区实际上是相当重叠的。

关于“一种方法论来统治一切”——看看Alistair Cockburn的敏捷过程“水晶”家族。他认为(相当胜任地)每个项目都需要自己的过程,甚至一个项目的过程也需要在项目过程中改变。他还为开发您的流程提供了一个轻量级框架。

我认为Scrum也是如此。Scrum实际上并没有告诉你很多关于如何运行你的项目的事情,但是更多的是关于如何发现什么在起作用以及如何使团队适应这些发现。

我不一定要在一个项目中使用敏捷,因为在这个项目中,所有的东西都是预先知道的。当变化很可能发生时,敏捷工作得很好。如果变化不大可能发生,可以使用预测或瀑布过程来管理这样的项目。

对您的具体问题的答复如下: 这个不是有最小尺寸吗?

由TDD驱动的简单且进化的设计总是更有效。你应该事先准备好足够的架构,以便知道主要部分落在哪里。不要用架构来猜测你将要做什么,只捕获已知的东西。让简单和进化的设计使您能够在构建应用程序时进化您的详细设计。

我们的客户通常要求固定价格。他们需要知道他们在处理什么,除非在特殊情况下,我们遇到了一个明显的黑洞,即使这样,人们也更喜欢戴帽子。那么,如果您正在进行一个能够容忍持续需求变化的流程,那么如何提供报价呢?

我知道敏捷可以在更复杂的项目中提供更好的成功机会,但它不会增加客户的成本吗?

教育(即敏捷训练营)和参观成功的敏捷团队将大有帮助。那就让团队行动起来。这项工作会让他们忙个不停,结果会让他们满意。

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

我建议在开发新的空中交通管制系统时不要使用敏捷。

不管是否敏捷,你都应该在实现之前设计已知的东西——在“尝试”之前。递归地将事情分解为可管理的任务,然后设计已知的内容,无论是本质细节还是广义概念。像UI和日常业务需求这样的东西在开发之前几乎从来都不是一成不变的,而飞机模拟功能可能是一成不变的。

尝试向客户“销售”敏捷的一种方法是授予他们两种选择: 1.瀑布,只要我们(开发人员)满足协议的要求,就不会取消。