敏捷开发方法的陷阱是什么？
问问题
7500 次
12 回答
8
常见的批评包括：
- 缺乏结构和必要的文件
- 仅与高级开发人员合作
- 包含不足的软件设计
- 需要太多的文化变革才能采用
- 可能导致更困难的合同谈判
- 效率可能非常低——如果某个代码区域的需求通过各种迭代发生变化，则可能需要多次执行相同的编程。然而，如果要遵循一个计划，那么一个单一的代码区域应该被编写一次。
- 不可能对提供报价所需的工作量做出切合实际的估计，因为在项目开始时，没有人知道整个范围/要求
- 由于缺乏详细的需求文档，可能会增加范围蔓延的风险
- 敏捷是功能驱动的，非功能性的质量属性很难作为用户故事
于 2008-12-11T15:54:43.643 回答
7
以敏捷为借口，在规划、需求定义和文档编制上花费的时间和精力不足。
于 2008-12-11T15:57:00.007 回答
7
来自@George Stocker 的引用列表，以及我的反驳......
缺乏结构和必要的文件
- 许多敏捷方法都高度规范了基本实践并具有结构，尽管其中大部分是非正式的。
- 定义必要的。计划驱动方法所需的许多文档未使用和/或已过时。敏捷性专注于生产那些实际需要的可交付成果。
仅与高级开发人员合作
- 最适合可以独立（或成对）工作的开发人员。
- 高级/初级开发人员的组合工作得很好。
包含不足的软件设计
- 具有积极重构的增量设计可以带来更好的设计，因为大部分设计都是在更好地理解应用程序的情况下完成的。
- 一个有效的批评可能是敏捷实施者可能因为害怕不“敏捷”而害怕预先做任何设计——没有一个方法学家会建议完全跳过前端设计。
需要太多的文化变革才能采用
- 可以是有效的，但在我看来这是值得的
可能导致更困难的合同谈判
- 确实。随着更多敏捷成功的实现，这种情况应该会改变。
效率可能非常低——如果某个代码区域的需求通过各种迭代发生变化，则可能需要多次执行相同的编程。然而，如果要遵循一个计划，那么一个单一的代码区域应该被编写一次。
- 只有以牺牲实际期望行为为代价而严格遵守计划，否则您会遇到同样的问题。
- 如果确实发生了变化，敏捷方法比计划驱动的方法更好地处理这个问题。
不可能对提供报价所需的工作量做出切合实际的估计，因为在项目开始时，没有人知道整个范围/要求
- 大多数敏捷方法都为您提供了了解速度的好工具。
- 所有方法都很难规划。这不是敏捷方法所独有的。
- 敏捷方法，通过将软件放在客户手中，比严格的预先计划更快地发现真正的需求，因为客户在看到之前不知道他真正想要什么。
由于缺乏详细的需求文档，可能会增加范围蔓延的风险
- 敏捷对此采取了完全不同的观点。它侧重于范围/时间的权衡，而不是限制范围以保持固定时间。
- 客户可以选择敏捷中的范围/时间权衡，因此他们可以完全控制范围。
敏捷是功能驱动的，非功能性的质量属性很难作为用户故事
- 您可以使用任何您想要跟踪质量属性的方法，如果您愿意，包括来自计划驱动实践的传统方法。
于 2008-12-11T16:25:42.490 回答
6
我认为第一个陷阱是认为“敏捷方法”意味着您可以做或不做任何您想做的事情。我会大胆猜测大多数使用敏捷的人，真正使用“临时”而不是实施那些导致敏捷的实践。敏捷性需要工作和纪律，也许比计划驱动的开发更需要。
有人说敏捷效率较低，因为可能会发生变化并且您必须重新做一些事情，所以我不禁发笑。现实情况是发生了变化，无论采用何种方法，您都必须重新处理（或最终导致客户不满意）。敏捷方法只是接受这种情况会发生，并尝试使用允许它以最少破坏性的方式发生的方法。为了提高效率，您仍然需要对允许的更改保持自律，使用敏捷只会让您有更好的机会说“是”并且仍然按时完成。
于 2008-12-11T16:05:33.467 回答
6
这里的很多答案不是陷阱，而是批评。在我看来，“陷阱”是需要注意的潜在问题，而不是避免敏捷的理由。
以下是我的一些极限编程：
在结对编程中，个人卫生、性舒适和亲密的社交技巧突然变得更加重要
很容易对重构感到兴奋，以至于您想重构无关紧要的代码，将高级模式应用于琐碎的例程，并在截止日期之前进行重构。
这些实践在重要方面相互支持。如果你放弃了一个，你就会在另一个中遇到麻烦。例如，如果您停止执行 TDD，您的重构将变得更加困难和风险更大。
仅仅因为你认为你正在遵循这些做法并不意味着你做对了。您确实需要有才华的人，了解 XP 的工作原理，并正确地进行操作。
你可能仍然失败。仅仅因为你都敏捷并不能保证你会完成你的项目，或者它会是你的客户想要的好软件。
于 2008-12-11T17:48:00.063 回答
5
认为敏捷是做“坐飞机”开发的借口。
于 2008-12-11T16:29:32.123 回答
4
这是一个非常哲学的问题。这里有一个陷阱：认为敏捷开发可以原谅每两周 180 度转变的管理层。另一个陷阱是，如果做错了，团队成员之间的工作量就不能很好地平衡。
于 2008-12-11T15:56:30.723 回答
2
于 2008-12-11T16:00:35.427 回答
2
我的感觉是，敏捷方法的最大风险在于其“灵活”的声誉。也就是说，您冒着开发人员开始填写他们自己的敏捷方法定义的风险。如果发生这种情况，您最终将根本没有方法论。
于 2008-12-11T16:07:07.520 回答
2
最大的陷阱是人们在看实践时会错过一件事：
- 检查和调整
如果您作为一个团队没有不断地评估您的实践并找出哪些有效，哪些无效，哪些需要调整，哪些需要调整，那么您很可能会失败。
于 2008-12-11T16:33:09.590 回答
2
- 只有至少有一个 sprint 的要求，敏捷才能成功。
- 大多数客户往往没有适当的要求，或者他们在 sprint 中间经常更改，这导致重新计划和重新开始 sprint。
- 当应用程序处于维护模式时，敏捷可能会更成功，其中应用程序已经投入生产，而开发人员只是在每个 sprint 中为应用程序添加更多功能。
- 管理层有一个优势，他们可以在工作中潜入 devs/qa 的日常生活（在每天的 sprint 会议中）。
- 如果没有适当的计划，它可能会很快通过budjet 吃掉（大多数情况下，这是由于需要采用的更改）。
- 由于文档较少/没有文档，因此您不能让一个人对错误传达或误解的功能负责。
- 这种缺乏责任感可能会导致更多的问题，即一个人故意不履行他们在团队中的职责。
- 开发人员可能会对不断变化的需求和所涉及的返工感到沮丧。（想象在 5 个 sprint 中调整相同的功能，可以在一个 sprint 中通过适当分析的需求来完成）。
- 业务/客户代表往往不承担提供适当要求的责任。
我已经使用敏捷流程工作了 3 年。在此之前，我曾在遵循瀑布方法的 CMM 5 级公司工作。
于 2008-12-11T17:11:23.490 回答
1
我不同意所有常见的批评，除了“可能导致更困难的合同谈判”。如果您的客户不想与您的开发流程有任何关系，则很难解决这个问题。
仅当您的开发流程以其他方式中断时，其他项目才适用，例如您不进行单元测试或持续集成或版本控制。
主要的缺陷是试图在没有阅读敏捷宣言或对该主题的行为进行任何研究的情况下尝试采用“某种敏捷”方法。
于 2008-12-11T16:03:51.550 回答