闲聊软件开发过程

软件开发过程是连续的

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

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

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

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

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

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

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


软件开发过程是迭代的

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

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


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

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

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

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

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

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

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

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

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



收尾

再不收尾，估计没几个人看的下去了。不好意思，天马行空了一把，没办法，正如前文强调的

引用:

切断一个连续的思维过程，这可能吗？

还请大家勉强接受这个现实吧