QUOTE:
原帖由 susan_huangyong 于 2009-8-19 22:19 发表
不太理解敏捷,如何划分产品清单backlog,如上面的3个迭代。
如果第1个迭代完成,第2个迭代进行一半时,客户发现要对第1个迭代变更怎么办呢?如果在第3个迭代过程中要变更前面两个迭代呢?岂不是越变越多,应接不暇了?敏捷不是号称最适合快速开发快速响应变更的吗?
原帖由 susan_huangyong 于 2009-8-19 22:19 发表
![](https://i-blog.csdnimg.cn/blog_migrate/24371f6b1a1305aabbdc929f898b4458.png)
不太理解敏捷,如何划分产品清单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/