案例讨论：传统项目管理 vs 敏捷项目管理

张恂

原帖由 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），

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

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

[ 本帖最后由 张恂 于 2009-8-21 11:43 编辑 ]

bq_wang

请问一下，您有没有MSN，能否加一下，呵呵

张恂

原帖由 bq_wang 于 2009-8-21 10:30 发表
请问一下，您有没有MSN，能否加一下，呵呵

已经加你了。

bq_wang

原帖由 张恂 于 2009-8-21 11:49 发表


已经加你了。

呵呵，看到了，多谢，MSN网络太差了，有空想您请教

susan_huangyong

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

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

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

感谢您的回复！
看来我的想法太局限了，只想到了变更代价太大，却没有想到由于是敏捷开发，变更会比传统模式更早的被提出，反而代价相对会少很多，响应的速度也会快很多。
不过，我还有问题：
1、每一个迭代过程都需要需求分析、开发、测试、发布这样的过程吗？
2、迭代的划分什么样的原则更为合理？可以简单理解为一个功能项吗？它的优先顺序是从什么角度来决定的？重要度还是难易度？
3、如果是您所说的第一类变更——积极的变更发生了，应该定义为一个新的迭代过程还是原有的迭代过程的延续？
4、敏捷开发的架构设计如何进行？会不会影响架构师对系统的通盘的设计，而导致系统先天缺陷？（可能有点杞人忧天，呵呵）

[ 本帖最后由 susan_huangyong 于 2009-8-22 20:51 编辑 ]

pharos

老张，下回来讲一次敏捷实践吧。

张恂

原帖由 pharos 于 2009-8-23 00:16 发表
老张，下回来讲一次敏捷实践吧。

好啊，线上，线下？

不如搞一个敏捷 FAQ 的栏目，我喜欢回答问题。

张恂

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

只想到了变更代价太大，却没有想到由于是敏捷开发，变更会比传统模式更早的被提出，反而代价相对会少很多，响应的速度也会快很多。

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

不过，我还有问题：

1、每一个迭代过程都需要需求分析、开发、测试、发布这样的过程吗？

2、迭代的划分什么样的原则更为合理？可以简单理解为一个功能项吗？它的优先顺序是从什么角度来决定的？重要度还是难易度？

3、如果是您所说的第一类变更——积极的变更发生了，应该定义为一个新的迭代过程还是原有的迭代过程的延续？

4、敏捷开发的架构设计如何进行？会不会影响架构师对系统的通盘的设计，而导致系统先天缺陷？（可能有点杞人忧天，呵呵）

好家伙，一口气 4 个问题

我先简单问答一下：

1、每一个迭代过程都需要需求分析、开发、测试、发布这样的过程吗？

是的，包括计划、需求分析、系统设计、开发、集成、测试、评审、发布、文档更新等等必要的活动。

但不是每次迭代都对外发布。


2、迭代的划分什么样的原则更为合理？可以简单理解为一个功能项吗？它的优先顺序是从什么角度来决定的？重要度还是难易度？

不只一个功能项，一个迭代可以完成多个需求项（items）。

开发的优先级需要考虑多种因素的叠加，包括重要度和难易度等，通常采用权重累加值。


3、如果是您所说的第一类变更——积极的变更发生了，应该定义为一个新的迭代过程还是原有的迭代过程的延续？

不，不是定义一个新的迭代过程。

通常可以通过每日例会或迭代评审发现这些计划外的变更。一般有两种处理办法：

a) 把对该变更的处理放入下一个迭代计划中。

b) 如果比较紧急，可以直接调整本次迭代的开发计划，把新的任务放入 sprint backlog 中。


4、敏捷开发的架构设计如何进行？会不会影响架构师对系统的通盘的设计，而导致系统先天缺陷？（可能有点杞人忧天，呵呵）

这个话题不小，简单地说就是风险驱动的 evolutionary design 以及 T 型设计，广度和深度的结合，通盘设计和关键细节设计的结合，设计、编程和测试的结合。

所以，敏捷架构设计并不会影响系统的通盘设计。

至于会不会导致先天缺陷？没有人敢打保票，但是敏捷的这种做法显然比传统做法更科学、更合理，出现严重问题的风险要小得多。

XP 有点偏激，给人的印象是对前期架构、建模好像不重视，这是它的缺陷。而其他许多敏捷方法（Scrum、AgileUP、FDD、Crystal 和太极等）对架构设计、业务建模等等前期工作和通盘考虑都是比较重视的，不排斥也不反对。

敏捷强调的是 just enough，不要做过了头。

[ 本帖最后由 张恂 于 2009-8-25 15:07 编辑 ]

laou2008

学习

susan_huangyong

原帖由 张恂 于 2009-8-25 14:37 发表

2、迭代的划分什么样的原则更为合理？可以简单理解为一个功能项吗？它的优先顺序是从什么角度来决定的？重要度还是难易度？

不只一个功能项，一个迭代可以完成多个需求项（items）。

开发的优先级需要考虑多种因素的叠加，包括重要度和难易度等，通常采用权重累加值。

我以为是需求中最明确最简单的部分先开始迭代呢，因为这样返工的机率会比较小。

感谢张恂老师耐心的回答，