敏捷 FAQ：迭代式开发会导致变更越来越多，难以控制吗？

QUOTE:

---

原帖由 susan_huangyong 于 2009-8-19 22:19 发表

不太理解敏捷，如何划分产品清单backlog，如上面的3个迭代。

如果第1个迭代完成，第2个迭代进行一半时，客户发现要对第1个迭代变更怎么办呢？如果在第3个迭代过程中要变更前面两个迭代呢？岂不是越变越多，应接不暇了？敏捷不是号称最适合快速开发快速响应变更的吗？

---

susan,

敏捷有一个口号，叫 embrace change!

你说的这种情况很有意思，属于经典 FAQ，也正好说明了敏捷迭代的优点和长处。对于这种变化很多的情况，迭代可以做到应接有序，而恰恰是传统做法会应接不暇。

首先，应该理解“越变越多”不一定是件坏事。我们通常所说的变化大，很多是负面的，比如那些通常由工程经验不足、管理失控等造成的返工。还有一些变化是正面的，是由产品或项目本身的特点所决定的，比如在不少创新型产品开发中，原本就需要大量的试探和摸索，那么出现多次反复、甚至推倒重来都是正常的。

消极变更

“客户发现要对第1个迭代变更怎么办呢？如果在第3个迭代过程中要变更前面两个迭代呢？”

关于变更，要分多种情况。出现了变更，我们还要分析一下变更的原因。第一种是正常合理的、有价值的、积极的变更，比如正常的需求变更，客户对产品的理解加深了；第二种是非正常、不合理的、返工型的、消极的变更。你说得好象是第二种情况。

你说的“对第1个迭代变更”、“变更前面两个迭代”是什么意思？是不是说，开发商的前面两个迭代都做错了，不是客户想要的东西，不符合客户的要求？

那么，正好，由于采用了短迭代，我们在很短时间内（不到 1 个月）就发现了问题，避免了更大的损失。甚至如果到了第 4 个迭代，还是需要大面积返工，前 3 个迭代都做错了，那么客户可以考虑直接取消合同，因为这个开发商实在太逊了。而这种变更的代价比传统做法小得多，因为只损失了最近 1 个迭代或前几个迭代的工作。

如果你说的这种消极变更的情况，发生在传统采用瀑布式的项目中，情况会怎么样？显然会更糟糕，因为你一般要到项目中后期才能发现需要返工，原来花几个月在需求阶段、设计阶段做的工作做错了，这时候改起来浪费就大了。

“敏捷不是号称最适合快速开发快速响应变更的吗？ ”

yes.

现在公认的看法是，采用短迭代的敏捷方法，非常有助于响应变更，及时发现问题、解决问题，把问题和风险消灭在早期阶段。

敏捷在原则上是积极欢迎变更和变化的。只要这些变更对客户和项目有利，更有价值，为什么不能变呢？一旦出现了变更的需求，敏捷团队会敏捷地做出合理的响应，接受或拒绝变更，表现出很好的适应性，这正是 Agile 的本义。

这个问题如果展开来说，还有很多有意思的话题和细节，我会在《中式太极敏捷》作进一步的分析。

小结一下：

由于采用了风险驱动、自适应、迭代、递增、演进式开发（RAIIED），

对于积极的变更，敏捷团队会主动拥抱和接纳，帮助客户获得更大的商业价值；

对于消极的变更，敏捷团队会及时作出反应和调整，帮助客户减少和避免更大的损失。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13633641/viewspace-612848/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13633641/viewspace-612848/