从迭代过程到自然法则

迭代过程
       早在20世纪50年代末期，软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型（stagewise model）”，其背景是H.D.Benington领导的美国空军SAGE项目。
       经过40多年的发展，在2001年，一个致力于迭代和敏捷方法的小组走到了一起。敏捷联盟由此诞生了。
       敏捷并没有创造出新的软件开发模型，它是迭代模型的一次升华。对于迭代过程是否真的能提高软件项目的成功率，这方面已经有了很多研究了。本文主要对于使用迭代过程管理软件的复杂度方面讲出一点感悟。
自然中的迭代
致虚极，守静笃。万物并作，吾以观其复。夫物芸芸，各复归其根。归根曰静，静曰复命，复命曰常，知常曰明，不知常，妄作凶。知常容，容乃公，公乃全，全乃天，天乃道，道乃久，没身不殆。（《道德经》第十六章）
达到极度虚无的境界，坚守内心的静寂。万物一起蓬蓬勃勃地生长，我从中观察它们返本归源的运动。万物芸芸种种，周而复始，各自回归到本源里去。回归本源为静，静下来才找到了根本，只有找到事物的根本才能发现普遍永恒的道，发现了道则称为圣明。如果我们不清楚普遍永恒的道，妄动就会招致凶祸。知道守常才能包容，能包容才能公道，公道才全面，全面才能达到天道，天道才能回归大道。只有大道才能终身受用无穷，不会出现困阻。
 
       软件的构建从来就不是简单的线性过程，而是一个不断创造、反馈、创造再反馈的循环往返的活动。起于用户，止于用户。
       以前听到过一个形象的比喻：软件就像是一盘果冻，碰一碰它就会摇一摇，然后慢慢地静止下来。不要期望静止状态能保持多久，因为总是很快就有人会去再碰碰它。而它静止的那一刻就是发版的最佳时机了。
几个真实的小故事
       曾经遇到过一个按照瀑布模型开发的项目。就像所有的其他项目一样，在种种外部的内部的因素影响下终于快到原计划的发版日期了。
       而此时在热闹喧哗的办公室中：测试人员直接在开发人员机器上演示着Bug舞蹈的景象（因为除了测试人员自己，谁也不清楚Bug怎么才能出来的），开发人员总是在不停地修改Bug、制造Bug。测试经理每天都盯着Bug库中新出的近百个似乎进化到拥有狐狸智慧的狡猾的小东西们，开发经理面临着苦于作战的兄弟姐妹们心有余而力不足，项目经理不断地催促到：可以正常发版吗，流程是否可以走通？
       没有人知道项目进展到了什么程度，也没有人知道大家离“成功”或者“毁灭”还有多远。那几个主要的模块老是无法走通。
       长时间与Bug厮杀的过程逐渐磨灭了团队的意志，似乎一切都看不到头。
       我给那位测试经理做过一个建议，至少先做一个Bug的分布“势力图”，让大家可以看到现在自己的处境。不过在所有开发人员包括开发经理在内都忙于面对Bug的情况下，这个策略并没有顺利进行下去。
       幸运的是，那个项目在延期之后仍然安全通过了验收。不过给管理者和公司的决策层却带来了很不好的一次体验。
       随着系统规模的不断扩大，系统中的缺陷也随着构建过程不断地引入，当规模达到一定程度时，会遇到很多不可预知的问题。很多项目都是进行的差不多了的时候，由于缺陷率居高不下，结果以失败告终。
 
       另外还有一个基于组件化开发的项目。在做概要设计的时候首先将系统的框架设计好。在编码阶段顺利地完成了主框架和核心代码的编写。
       单元测试的用例也令人鼓舞地全部通过。这时项目组内的所有人都憧憬这样一幅美好的场景：程序主框架就放在这里，然后将几十个模块一一分配给开发人员实现。等到子模块全部实现好后往主框架里面一放，“啪”，系统就跑起来了，一切都是那么的美好。当然了最后的集成工作还是免不了的，根据以往的经验，安排两个月好了。这样算起来肯定没有问题。
       子模块开发工作紧锣密鼓地进行。等到项目进展到一半的时候（按照计划完成了一半），是应该给客户做一次演示了，可以增强他们的信心，同时也鼓舞士气。
       就这样，在一个依旧紧锣密鼓的下午，一位程序员接到任务开始了组件集成工作。
       ……
       “咦，怎么会这样？”
       “为什么这里会抱错呢？”
       “怎么鼠标随便点点，主程序就崩溃了。”
       没办法，今天晚上只好加班了L
       ……
       就这样经过了三天的时间，有四五个大的模块终于集成进来了。其他的模块仍然在修改过程中。
       等到给客户演示的那天，出于无奈只好说：
“其实XXX功能我们做了，但是没有集成进来”。
“&#$^**~·#~~!”
 
大多数程序员都是乐观派的人，他们对自己的代码和模块非常放心。
“提交吧，绝对没问题”
“为什么没问题呢？”
“因为是我写的”程序员高昂着头，自信满满地说道。
 
客户永远是软件的核心，但客户只认可现在看得到的，能用的功能。当一个大型的项目进展到一定程度的时候，我们需要给客户和自己展示一些完成的成果。这样能够增强团队的自信，同时也可以非常明确地知道目前项目的进展情况。其中很重要的一点就是，这个成果必须是能给客户带来价值的完整系统的一个子集，不能是开发人员做出来的一堆零件。
 
在现实的软件开发生涯中，大家应该会遇到许许多多这样自以为很好，但结果却让人惊讶的例子。随着现代软件复杂程度的增加，越来越多的项目都会失去控制。
怎样才能控制软件的复杂度？这是管理、架构、编码都需要解决的问题。
软件工程的“银弹”？
       想了很久，不知道这里是否适合用到“银弹”这个词。估计看到这篇文章的有些朋友们会想：这位兄台怎么又把“银弹”拉出来现了，同时再来一句“too old!”。
       什么事情都应该有一个理想吧，软件工程这个行业的理想可能就是找到这样一个万能的方法。或许真的有这么一种方法的存在，但就目前来说它仍然仿佛海市蜃楼一般虚无缥缈。

原文转自：http://www.ltesting.net