闲聊软件开发过程

软件开发过程是连续的

太多开发人员受瀑布模型的影响太深了，习惯性的将开发过程做严格的划分。这样的划分多半是自欺欺人，软件开发过程主要是靠人的思维创造，而思维过程是连续的。切断一个连续的思维过程，这可能吗？

或多或少有完整项目经验的程序员，在接到新的项目需求时，很自然就会在脑海里浮现代码实现的轮廓，剩下的活就应该是动手编码了，用个成语来形容它就是“顺 理成章”。软件开发过程也应该顺理成章，不要再浪费力气去把这一个完整连续的过程划分需求、概设、详设、编码、验收啦。

此时，应该响起反对的声音了。

反方：“不划分怎么跟踪项目进度呢？”

项目进度是一定要跟踪的，但这样的划分对跟踪项目进度没有任何意义。因为在没有可运行的代码出来之前，需求完成度100%、概设完成度100%、详设完成度100%，这些数据根本不能真实反映项目的实质的进展，若你非要一个数据，我可以告诉你，项目进度为0。

反方：“等运行的代码出来，还用得着跟踪吗？”

当然不是等系统所有的代码出来啦，这都是瀑布模型惹得祸啊！项目可以按系统功能分批次计划实现，每个批次可视作一个迭代，每个迭代的结束点就是一个里程碑。在每个里程碑去跟踪系统功能的实现情况，此时功能实现数量占总量的比例才是有效的项目进度。


软件开发过程是迭代的

说到“迭代”，很多开发人员都会禁不住汗一把，有种近而远之的心态。还有人认为迭代就一个小瀑布，我曾经对此观点深信不疑，现在却感到惭愧不已。这种观点只能说明那个人还是没有打破瀑布的惯性思维的框框。

下面这个图相信大多数人都没有见过，即使眼熟也不见得看得懂。接下来，我们就来聊聊这个图。


这个图是RUP（Rational Unified Process）的一个核心概念图，它诠释了RUP提倡的过程精髓。图解如下：

1. 图的横轴表示项目的生命周期，也就是时间轴；
2. 横轴上划分了四个阶段，每个阶段又会有1～N个迭代，迭代个数的多少视阶段工作进展而定；
3. 图的纵轴罗列了项目中可能实施的工作流程；
4. 每个工作流程都在横轴上有一个波形图，用来表示它在时间线上工作量的起伏变化。

图中四个阶段很容易让人迷惑，我这就来简单解释一下：

• 先启阶段 - 明确项目目标和范围；
• 精化阶段 - 确立系统架构和技术方向；
• 构建阶段 - 大规模并行实施设计、开发、测试；
• 产品化阶段 - 产品验收、部署、发布。

反方：“哈哈，先启不就是需求，精化不就是设计，构建不就是编码，产品化不就是测试，这就是挂羊头卖狗肉，还是个瀑布”

“...来呀，把他给拖出去阉了...对付这类中毒太深的人，必须斩草除根！”

在RUP中，需求、设计、编码与测试不再是过程阶段，而是工作流程，从上图已经明确表明这些工作几乎存在于生命周期的每个阶段，只是不同的阶段工作量有多 有少而已。每个阶段的目标不一样，工作的侧重点自然不同，但上述四个工作流程却一个都不能少。通过各个工作流程的配合，实现阶段目标的演进，最终实现产品 化。

对事物从认知到理解，是一个由抽象到具体的演化过程。软件开发也是一样，起初是一些表象和问题，经过第一次迭代破除了表象和一些问题，但又产生了新的问题，在经过第二次迭代解决了第一次的问题，不过也会产生第二次的问题...

这样反反复复，从二维的角度看好像是原地踏步，但从三维的角度看，在理解事物本质的纵向上我们却又了很大的进展。项目范围是在一段时间内是相对稳定的，那 么迭代的周期也是固定。可从宏观上看，这个迭代是会持续下去的，就像office从97到2007，十年历经了多少迭代啊！迭代可以结束，有两种办法， 1）限定项目范围，这样问题域是有限的；2）终止项目。



收尾

再不收尾，估计没几个人看的下去了。不好意思，天马行空了一把，没办法，正如前文强调的 还请大家勉强接受这个现实吧

迭代开发是必要的。
但是这个软件开发是连续的从何说起？
lz想说明的问题是应用迭代的思想去开发吧，但是
“切断一个连续的思维过程，这可能吗？ ”这个问题似乎说明不了迭代的必要性。
人的思维过程，有时是连续的，有时是跳跃的。就是瀑布开发过程，也不是从思维角度去考虑的，更多的是从分工角度。

1、这个程序员太强了


2、第一次听说，RUP了之后，在可运行代码出来之前，项目进度是无法估算的


3、好简单，比瀑布切的还厉害，每个功能都包括需求、设计、测试、部署吧，怎么才算是实现了呢？


4、什么叫产品？什么叫项目？产品的生命周期是怎么样的？项目的生命周期是怎么样的？

1.这样的程序员存在于大多数公司中，我非常恐怖让这样的人与客户去谈需求，恶梦。
2.所有的项目进度都是蒙的。。。。瀑布也一样。。。
几乎没有什么规律可言。只有加压让程序员向某个时间努力。。。。
3.同意，还是太肤浅了。有很多因素，有看的见的有看不见的。

4.PS：楼主的文章没有一点新东西。。。看着很没味道

我实际的我没看出楼主的意思到底是啥，大概楼主是看了一些RUP的书，发表的一席迭代学习阶段的感慨。
不过有些问题，我要说一说。
第一，敏捷的迭代是小迭代，包括RUP的迭代也不是很大的。而且每一个迭代普遍情况都是按照时间周期划分的，而且大多数情况都是会存在很多个周期。这个时候你把所有的迭代结束都按一个里程碑，这个是自找麻烦的办法，也是不明白里程碑究竟该如何设定的办法。同时也请注意，项目的进度跟踪完全可以不依赖里程碑，而采取其他方式。代码行和功能点，虽然陈腐和不合实际，但是这些都是可以去跟踪进度的。这样的东西都能拿来跟踪进度，那难道就不存在别的方法进行跟踪吗？
第二、很多情况下理解迭代是一些列的小瀑布，也未尝不可。而且就是楼主给的那个图，恰恰也可以说明在RUP的方式下，很多时候一个迭代就是一个小瀑布。
而且最后用office的例子，恰恰是很不合适的。因为这之中存在一个迭代周期过于不匀称的问题，而不匀称可以说是迭代计划失败和迭代实施失败的一个主要标志。

看了半天，楼主无非就是搞了半天也没有搞明白UP的一群里面的一个罢了。
最后还要说一句，并不是所有的项目进度都是蒙的，至少曾经存在和现在依然存在那么多模型就是干这个的。这里当然有好的有坏的，但是绝对不是拍脑袋蒙的，而且成熟的方法应该可以得到具体的数据。
说实在的最近很讨厌RUP，比CMM更甚。

果然不出所料，一篇有争议的言论就是比平铺直叙的技术总结要更吸引眼球。

感谢上面4位高人的积极中肯的回复，你们观点给我启发

o..z大大，请教关于迭代的问题：
1. 第一迭代完成的功能，后面的迭代能够继续吗？即某次迭代完成功能的部分？
2.后面的迭代是否需要等前面的迭代完成后，才能继续进行？
3.在CMMI的管理框架内(无法改变)，如何进行更好的迭代？

1、这个问题问的不好。
首先迭代的计划有多种形式，存在以功能为导向的，也存在以程序结构为导向的。
因此你这个问题，可以看作前面迭代已经达成的目标，是不是可以在后续迭代中再次达成？
迭代的优势在于可以更好的支持增量开发，这个增量既可以使需求的增量，也可以是程序结构的增量。而显然增量的前提是你对需求做了分解，并且把功能也作了分解。而显然不对功能进行分解，就无法理解业务的细节，也无法将功能是否正确做验证。而迭代的计划更多的考虑是周期的均匀性，从而把一个大型的功能放到一系列小的迭代计划中去。同时你还会发现，随着后面工作的进行，对前期的工作会有新的认识，那么就存在一个修正和改造的问题。也就是说，需求导向的迭代式在每一次迭代周期中针对某些功能去构建，并且在今后的迭代周期中不断完善。

虽然一次就把事情做好很诱人，但是实际上又多少人能做到？

2、后面迭代的当然要等前面迭代完了以后才能进行。不过你要注意，我说的是完了，不是完成。实际上我们经常会发现计划是有瑕疵的，有问题，以至于是错误的，在这个时候还坚持严格实施计划是荒谬的。而实际上我想你的问题应该是，前面迭代需要完成的工作完成后，后面的迭代才能进行。其实这里还是一个迭代计划的策略问题，其实本着风险控制的原则及对客户需求关注的考虑，需要优先完成的功能顺序，是应该不断的调整的。即使前面迭代中被认为是重要的功能，但是一旦被判断为不重要，优先顺序就会下降，从而让位给更重要的功能去优先实现。也就是说下面的迭代应该总是完成最重要的部分。


3、本人无此类成功经验，因此无法给出有效建议。我想大概可以采取增大迭代周期的方式，来保证迭代计划在cmmi系统下的成功。比如项目在实施阶段分成两个迭代，当然如果想保住管理系统的稳定可以采取单一迭代周期的形式。嘿嘿。

我建议你还是去看看《敏捷迭代开发——管理者指南》，那里有对迭代的系统研究和介绍。

非常感谢。
1.之所以问第1个问题，是因为很多人一个功能一次迭代需要彻底完成的，后面在回来进行，那是一个非常非常的特例。我很赞同你的意见。
2.你理解错我的意思了，可能是我没有描述清楚，我的意思是，多次迭代错开进行，前次迭代开始4天后，另一次迭代开始。还有种情况，开发与测试的迭代错开进行，这样是否可行，或者是否是常见的迭代情况。
3.嘿嘿。

4.马上去找书去。

对于2的理解，你存在问题。首先你的这种方式很少见，也就是并发迭代方式，这种方式其实并不能算严格意义上的迭代。但是当项目中存在许多及其专门的人才，并且他们更加愿意只从事及其专业的工作的时候，才可能发生。此种方式管理和职责分配非常复杂，协调和整合也非常复杂，需要特别的技巧和策略才可以实施，因此我就不做深入介绍了。
本质上说迭代方式，应该叫增量开发的迭代实现方式。所谓增量开发，也就是围绕一个系统，不断的以增加新内容的方式进行开发：而迭代，则是按照固定的时间周期，将活动分配成一系列的小的流程，每一次流程都完整的经过一次流程，并且产生新的输入和输出。显然并发式的方式，并不完全符合。这里一层含义是，开发和测试等都应该是构筑程序的核心流程，也就是说它们都属于在一个迭代流程中必须存在的工作流，而不是说存在什么测试迭代和开发迭代。
同时请注意，迭代的过程是这样的。对迭代做计划，迭代1开始，迭代1结束，回顾和反馈迭代1，并修正迭代2或者3的计划，迭代2开始，迭代2结束，回顾和反馈前面迭代工作，并修正下次或者下下次迭代计划，。。。。。。。。