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

Question

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

Answer 1

common criticisms包括：

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

Answer 2

以敏捷为借口，在规划，需求定义和文档上花费时间和精力。

Answer 3

来自@George Stocker's quoted list，我的反驳......

• 缺乏结构和必要的文件

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

• 仅适用于高级开发人员

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

• 包含不充分的软件设计

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

• 需要过多的文化变革才能采用

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

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

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

• 效率非常低 - 如果一个代码区域的要求通过各种迭代发生变化，则可能需要多次完成相同的编程。然而，如果要遵循计划，则预计会编写一个代码区域。

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

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

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

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

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

• 敏捷是功能驱动的，非功能性质量属性很难作为用户故事放置

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

Answer 4

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

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

Answer 5

这里的很多答案都不是陷阱，而是批评。在我看来，“陷阱”是值得注意的潜在问题，而不是避免敏捷的理由。

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

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

• 很容易对Refactoring感到兴奋，你想要重构无关紧要的代码，将高级模式应用于琐碎的例程，并在截止日期前重构。

• 这些做法在很重要的方面相互支持。如果你抛弃一个，你将陷入另一个麻烦。例如，如果你停止做TDD，那么你的重构会变得更加困难。风险较高。

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

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

Answer 6

认为敏捷是一个借口“飞得你的裤子”的发展。

Answer 7

这是一个非常哲学的问题。这里有一个陷阱：管理层认为敏捷开发每两周可以原谅180度转变。 另一个缺陷是，如果做错了，团队成员之间的工作量就不会很平衡。

Answer 8

PHBes who think "agile" means "get things done with fewer people";）

Answer 9

我的感觉是，敏捷方法的最大风险在于其“灵活”的声誉。也就是说，您冒着开发人员开始填写他们自己的敏捷方法定义的风险。如果发生这种情况，你最终根本就没有任何方法论。

Answer 10

最大的缺陷是人们看着这些做法而错过了一件事：

• 检查和调整

如果您作为一个团队，并不是在不断评估您的实践并找出哪些有效，哪些无效，哪些需要调整，哪些需要调整，那么您可能会失败。

Answer 11

• 如果您有至少一个冲刺的要求，敏捷只能成功。
• 大多数客户往往没有适当的要求，或者他们在冲刺中间频繁更换，这导致重新规划并再次开始冲刺。
• 当应用程序处于维护模式时，Agile可能会更成功，其中应用程序已经在生产中，开发人员只是在每个sprint中为应用程序添加更多功能。
• 管理层有一个优势，他们可以潜入开发日常生活（每天的短跑会议中）。
• 如果没有适当的规划，它可以通过budjet吃得很快（大部分时间都是由于需要采用的变化而发生）。
• 由于文档较少/没有文档，因此您无法让一个人对错误传达或误解的功能负责。
• 这种缺乏问责制可能会导致更多的问题，即一个人在团队中没有履行自己的职责。
• 开发人员可能会因不断变化的需求和重新工作而感到沮丧。 （想象一下，在5个冲刺中调整相同的功能，可以在一个sprint中通过正确分析的要求进行补充）。
• 业务/客户代表往往不承担提供适当要求的责任。

我已经使用敏捷流程3年了。在此之前，我曾在CMM Level 5公司工作，其中遵循瀑布方法论。

Answer 12

除了“可能导致更艰难的合同谈判”之外，我不同意所有的共同批评。如果您的客户不想与您的开发流程有任何关系，那么很难解决这个问题。

其他项目仅在您的开发过程以其他方式被破坏时才会出现，例如您不进行单元测试或持续集成或版本控制。

主要的缺陷是尝试做一种“敏捷”的方法，而不是每次都阅读Agile Manifesto或对该主题的任何研究做过任何研究。