敏捷开发方法的缺陷是什么？

Question

敏捷开发方法的缺陷是什么？

Answer 1

在常见的批评包括:

• 缺乏结构和必要的文件
• 仅适用于高级开发人员
• 采用不充分的软件设计
• 要求采用太多的文化变革
• 可能导致更艰难的合同谈判
• 可能效率非常低 - 如果对一个代码区域的要求通过各种迭代进行更改,则可能需要多次完成相同的编程.如果要遵循计划,则预计会编写一个代码区域一次.
• 无法对提供报价所需的工作量进行实际估算,因为在项目开始时没有人知道整个范围/要求
• 由于缺乏详细的需求文档,可能会增加范围蔓延的风险
• 敏捷是功能驱动的,非功能性质量属性很难被用作用户故事

Answer 2

使用敏捷作为借口,在规划,需求定义和文档上花费的时间和精力不足.

Answer 3

来自@George Stocker的引用名单,以及我的反驳......

• 缺乏结构和必要的文件

  1. 许多敏捷方法都是基本实践的高度规范,并且具有结构,尽管其中大部分都是非正式的.
  2. 定义必要的.计划驱动方法所需的大量文档未被使用和/或无可救药地过时.敏捷性专注于产生实际需要的可交付成果.

• 仅适用于高级开发人员

  1. 最适合可以独立工作(或成对)的开发人员.
  2. 高级/初级开发人员的组合工作得很好.

• 采用不充分的软件设计

  1. 通过积极的重构进行增量设计可以带来更好的设计,因为大部分设计都是通过更好地理解应用程序来完成的.
  2. 一个有效的批评可能是敏捷实施者可能害怕做任何设计,因为害怕不"敏捷" - 没有一个方法学家会建议完全跳过前端设计.

• 要求采用太多的文化变革

  1. 可以有效,但在我看来这是值得的

• 可能导致更艰难的合同谈判

  1. 当然.随着更加灵活的成功实现,这应该会改变.

• 可能效率非常低 - 如果对一个代码区域的要求通过各种迭代进行更改,则可能需要多次完成相同的编程.如果要遵循计划,则预计会编写一个代码区域一次.

  1. 只有严格遵守计划而牺牲实际所需行为,否则您会遇到同样的问题.
  2. 如果确实发生了变化,敏捷方法比计划驱动的方法更好地处理这个问题.

• 无法对提供报价所需的工作量进行实际估算,因为在项目开始时没有人知道整个范围/要求

  1. 大多数敏捷方法都为您提供了理解速度的好工具.
  2. 所有方法都很难规划.这不是敏捷方法所特有的.
  3. 敏捷方法通过将软件放在客户手中,比严格的前期规划更快地发现真正的需求,因为客户在看到之前不知道他真正想要的是什么.

• 由于缺乏详细的需求文档,可能会增加范围蔓延的风险

  1. 敏捷对此采取了完全不同的观点.它侧重于范围/时间权衡,而不是限制范围以保持固定时间.
  2. 客户可以选择Agile中的范围/时间权衡,因此他们可以完全控制范围.

• 敏捷是功能驱动的,非功能性质量属性很难被用作用户故事

  1. 您可以使用任何方法来跟踪质量属性,包括计划驱动实践中的传统方法(如果需要).

Answer 4

我认为最重要的陷阱是认为"敏捷方法"意味着你可以做或不做你想做的任何事情.我猜想大多数使用敏捷的人确实使用"临时"而不是实施那些导致敏捷的做法.敏捷需要工作和纪律,或许比计划驱动的开发更为重要.

我从那些认为敏捷效率较低的人那里得到了一个轻笑,因为变化可能发生,你必须做些什么.现实情况是,无论采用何种方法,都会发生变化,而且您必须做一些事情(或最终得到一个不满意的客户).敏捷方法只是接受这种情况会发生并尝试使用允许它以最少破坏性方式发生的方法.为了提高效率,您仍然需要对您允许的更改保持纪律,使用敏捷只是让您有更好的机会说是,并且仍能按时完成.

Answer 5

这里的很多答案都不是陷阱,而是批评.在我看来,"陷阱"是值得注意的潜在问题,而不是避免敏捷的原因.

以下是极限编程的一些内容:

• 通过结对编程,个人卫生,性安慰和亲密的社交技巧突然变得更加重要

• 很容易让Refactoring如此兴奋,你想要重构无关紧要的代码,将高级模式应用于琐碎的例程,并在截止日期前重构.

• 这些做法以重要的方式相互支持.如果你抛弃一个,你将陷入另一个麻烦.例如,如果您停止执行TDD,您的重构将变得更加困难和风险更大.

• 仅仅因为你认为你遵循这些做法并不意味着你做得对.你真的需要有才华的人,了解XP的运作方式,并做正确的事.

• 你可能仍然失败.仅仅因为你敏捷并不保证你将完成你的项目,或者它将是你的客户想要的好软件.

Answer 6

认为敏捷是一个借口,"飞得你的裤子"的发展.