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

时间:2008-12-11 15:47:22

标签: agile

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

12 个答案:

答案 0 :(得分:8)

common criticisms包括:

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

答案 1 :(得分:7)

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

  • 缺乏结构和必要的文件

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

    1. 最适合可以独立(或成对)工作的开发人员。
    2. 高级/初级开发人员的组合工作得很好。
  • 包含不充分的软件设计

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

    1. 可以有效,但在我看来是值得的
  • 可能导致更艰难的合同谈判

    1. 当然。随着更加灵活的成功实现,这应该会改变。
  • 效率非常低 - 如果一个代码区域的要求通过各种迭代发生变化,则可能需要多次完成相同的编程。然而,如果要遵循计划,则预计会编写一个代码区域。

    1. 只有严格遵守计划而牺牲实际所需行为,否则您会遇到同样的问题。
    2. 如果确实发生了变化,敏捷方法可以比计划驱动的方法更好地处理这个问题。
  • 无法对提供报价所需的工作量进行实际估算,因为在项目开始时没有人知道整个范围/要求

    1. 大多数敏捷方法都为您提供了理解速度的好工具。
    2. 规划对所有方法都很困难。这不是敏捷方法所特有的。
    3. 敏捷方法,通过将软件放在客户手中,比严格的前期规划更快地发现真正的需求,因为客户在看到之前不知道他真正想要的是什么。
  • 由于缺乏详细的需求文档,可能会增加范围蔓延的风险

    1. 敏捷对此采取了完全不同的观点。它侧重于范围/时间的权衡,而不是限制范围以保持固定的时间。
    2. 客户可以选择敏捷的范围/时间权衡,因此他们可以完全控制范围。
  • 敏捷是功能驱动的,非功能性质量属性很难作为用户故事放置

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

答案 2 :(得分:7)

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

答案 3 :(得分:6)

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

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

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

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

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

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

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

答案 4 :(得分:6)

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

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

答案 5 :(得分:5)

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

答案 6 :(得分:4)

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

答案 7 :(得分:2)

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

  • 检查和调整

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

答案 8 :(得分:2)

答案 9 :(得分:2)

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

答案 10 :(得分:2)

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

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

答案 11 :(得分:1)

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

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

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

免费获取贴纸的机会↓↓↓
豫ICP备18024241号-1