从迭代过程到自然法则

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

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=839939