胖子胡说敏捷

今天为了监视gigix这个小子,于是发现了下面一段话:

迭代是一定不能少的,即使对于用例他也没有这样说.而如果大家经常关注comp.object就会发现关于敏捷的讨论，最后往往落实到的还是对于迭代的态度。
而在敏捷宣言中对于迭代是在原则的第三条提到的：而第一条也说要不断地提交可以工作的软件。
在我看来，敏捷的核心特征就是迭代。
然而迭代并不是那么容易就可以被我们所理解的，往往会和反复所混淆。即便你看原版书，你一样要小心的区分iterative到底是在说迭代还是在说反复。这两者的区别是明显的，即使你在瀑布中也是要在阶段内部不断的实行反复，以保证一个工件的最终合格。那么迭代究竟是什么呢？迭代是要产生最终产品的反复，也就是说你的一次一次的反复必须都能产生最终的产品，而不是中间的半成品。迭代往往是需要你突破阶段这个概念的，需要你飞快地完成一个小项目，而不是在大项目中完成一个部分。也就是说所有迭代结果相加的总和不是项目的各部分之和。这有两个方面的含义，一个是说迭代不是说“我们先完成这个模块，下一个迭代完成另外一个模块”，而是要求你一次迭代完成一个细小的项目，这需要你包括所有的模块。另外一个方面是说，当你把各个小项目都综合起来，会发现各个项目之间并不是所有的项目的目标都指向你在早期确定的最终目标，以至于有些可能根本就是背道而驰的，有些根本就是不着边际，即便和最终的结果比较起来，有些迭代也可能是做了无用功。但是你也要注意，敏捷要你可以不断地移交可以工作的软件，所以即便你从后来的角度看有些努力是无用的，但是在当时的角度看那些是走向成功所必须要做的事情。

o6z, 我用一句话来总结一下你的发言.

整体先于局部.

这段话是翻译之后速录记下的，其实并不精确。Jacobson说的原话，必不可少的有4样：

1、用例
2、单元测试
3、迭代
4、分层的架构

只要是从实践出发的，大家必定会得到同样的结论。

听o6z这样一说，对于迭代的概念倒是模糊了一点了。嗯，什么是迭代，什么又是反复。难道我的理解原来一直是错的，天哪。

大家都知道敏捷的核心思想在于强调人的核心地位，强调敏捷的应对变化。那么这个胖子是什么人，竟敢说迭代才是敏捷方法的核心特征呢？是不是这个胖子吃多了，心脏不好，不能做长期的活动，只能迭代式的进行短期的锻炼呢？
让我们先来看看敏捷宣言中的12条原则和迭代的关系。


尽早？如何尽早呢？如果你采取一次成型的方式，不可能做到尽早。因为你需要对所有的问题都解决之后，才能满足所有的客户需求。而后面还说需要不断的，这显然是说，你要经常性的提交。而如果你每一次都提交同样的东西，显然不能说对于客户有价值。所以你只能使用迭代的方法才能，做到这些。

如何才能做到可以在后期应对变化呢？采取的措施还是迭代，细小的迭代，快速的审视，不断地增量。

这一段就是在说迭代。

为什么要如此，如果不是迭代，项目的后期业务人员为何还要在现场。

这一点我确实没有发现和迭代的直接关系。
但是相信别人我想是要有基础的，如果不是迭代，那么你怎么能相信他们能够做到他们说承诺的呢？迭代的一个作用，就是可以不断地激励起士气，并且给你一个不断确认这些人完成工作的能力的机会。

这似乎也和迭代没有关系。但是我们要注意面对面虽然有效，但是会随着时间的流逝，交流的结果会被遗忘。面对这个风险，最好的策略就是将这些交流的结果尽早的固化。迭代就是一样一个固化交流结果的好手段。

如果你不迭代，那么你的进度表是不是就只有0和100%。

节奏！


这些点确实和迭代没有什么关系。但是迭代可以说为做到这些，提供了最好的基础。精湛的技术来自不断的总结和积累，良好的设计我相信更应该容易的来自不断的重构，而非一挥而就。简单如果不能和迭代结合，往往会越想简单越复杂。自组织的团队我相信需要一个过程才能建立，如果这个过程不能给大家一个节奏性的不断审视自己的机会，那么这个过程将是漫长的。


迭代就是这个时间间隔。

jacbson在CSDN聊天那天,我也问了这个问题
我还问了rup里人的地位，老头半天没回答，还是主持人换了个说法

老头的现在是敏捷的急先锋。其实我看了看敏捷人的简历，忽然发现敏捷人机会后和IBM沾亲带故。看看那些方法也或明或暗的和IBM勾勾搭搭。在看Rational，你会发现他们根本就是敏捷的一丘之貉，只是差把那些敏捷的家伙都拉到旗下了。这个老头现在对敏捷不满意，其实是绝对敏捷还不够轻。他现在搞AOP，就是要把敏捷从另外一个方面搞得更加激进一些。
其实在我看来所谓的敏捷根本就是面向对象社区在搞完了设计和分析的方法论之后，有一次团结起来向软件工程的管理方面进军的一个产物。所以你看起来好像敏捷对RUP气势汹汹，其实这些都是假象。他们背地早就狼狈为奸，互相协调。最终的目标无法就是把软件开发整个过程都纳入他们的轨道。不时有几个人跳出来反对敏捷，你其实也看明白了，那些人纯粹就是没事找事的无聊的家伙。
说来说去，气势宏大的敏捷在我看来也就是软件开发发展到一定阶段的必然产物。

胖子，你说得太理性了，能不能举个例子来说，当然要撇开你的肥胖和心脏。

给我的感觉是越到了项目的后期越讨厌变化，但是这往往会带来很多问题。
假设在一个分层的结构中两帮人马负责不同的层次，很有可能一帮人不经常更新另一部分人开发的东西，这种间隔有时竟可以达一月之久，我不知道这种问题属不属于敏捷开发中能够解决的，胖子你今天话多，就正好指点一下吧。

老头要是拉着booch也扯起敏捷的大旗--哈哈，--想起来都美,美死人了

o6z:你最近为什么总盯着gigix,这小子欠你的钱吗?