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

Question

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

Answer 1

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

• 缺乏结构和必要的文档

1. Many agile methods are highly prescriptive of essential practices and have structure, though much of it is informal.
2. Define _necessary_.  Much documentation required by plan-driven methods is not used and/or hopelessly out of date.  Agility focuses on producing those deliverables that are actually needed.

​

• 仅适用于高级开发人员

1. Works best with developers who can work independently (or in pairs).
2. A mix of senior/junior developers works just fine.

​

• Incorporates

的软件设计不足

1. Incremental design with aggressive refactoring can lead to better design because much of the design is done with better understanding of the application.
2. A valid criticism might be that agile implementers may be afraid to do any design up front for fear of not being "agile" -- none of the methodologists would recommend entirely skipping up front design.

​

采用

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

1. Can be valid, but in my opinion it is worth it

​

• 可能导致更困难的合同negotiations

1. Definitely.  This should change as more agile successes are achieved.

​

• 的效率可能非常低-如果某个代码区域的需求经过各种迭代而发生变化，则可能需要多次执行相同的编程。然而，如果有一个计划需要遵循，那么预计只需编写一次单一区域的代码。

1. Only if the plan is rigidly adhered to at the expense of actual desired behavior, otherwise you have the same problem.
2. If changes do occur, agile methods handle this better than plan-driven methods.

​

• 不可能对提供报价所需的工作量进行现实的估计，因为在项目开始时，没有人知道整个scope/requirements

1. Most agile methods give you good tools to understand your velocity.
2. Planning is hard for all methods.  This is not unique to agile methods.
3. Agile methods, by putting software in the customer's hands early discover the real requirements faster than rigorous, up-front planning because the customer doesn't know what he really wants until he sees it.

​

由于缺乏详细的要求documentation，

• 可能会增加范围蔓延的风险

1. Agile takes a completely different perspective to this.  It focuses on scope/time trade-offs rather than limiting scope to keep fixed time.
2. Customers get to make choices about the scope/time trade-off in Agile, so they are in complete control of scope.

​

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

中

1. You can use whatever method you want to track quality attributes, including traditional methods from plan-driven practices if you want.

​

Answer 2

common criticisms包括：

缺乏结构和必要的documentation

• Only与高级developers

• Incorporates一起工作不充分的软件design

• Requires太多的文化变化而不能采用

• 会导致更困难的合同式
• 效率非常低-如果某个代码区域的需求通过各种迭代发生变化，相同的编程可能需要重复几次。然而，如果存在要遵循的计划，则期望编写单个区域的代码来开发提供报价所需工作的实际估计，因为在项目开始时，没有人知道整个scope/requirements
• Can会由于缺乏详细的需求而增加范围爬行的风险documentation
• Agile是功能驱动的，非功能性质量属性很难被放置为用户故事

Answer 3

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