作坊离工厂究竟有多远 (续五) -重型工程
　

---

作坊离工厂究竟有多远 (续五)
-重型工程

smilemac

(六)

故善战者，求之于势，不责于人
——《孙子兵法-兵势篇》

在以前的项目生涯中，我对于重型方法是如此深恶痛绝，认为重型方法是大多数失败项目和死亡之旅项目的主要原因，是真正想工作的程序员的大敌，于是我在一切场合都嘲笑重型方法，然而，最近我评估过的一个项目让我改变了看法，我发现，重型方法并非全无是处。（不过我的性格似乎总有些矛盾，即使在以前，静室工程这种比较显著的重型方法也是我闲暇时最喜欢学习研究的，本文后续的短篇中我会介绍此种方法，也会介绍我为什么喜欢它）。

那个项目是典型的“先射击后瞄准”的开发方式，无疑，如果项目需求不确定，或者质量可以有弹性，这种开发方式也可以做出项目来，能否成功，更多看一下程序员过去的经验和现在的能力就可以了。即使项目有较高要求，如果程序员水平足够高，那么个人英雄式的开发方法成功率也是极高的，但是当大部分程序员都徒有一些经验，而基础，尤其理论基础不足的时候，大一点的项目就非常危险了。而这时，如果想降低风险而又无其他资源可用的时候，重型方法便可显山露水了。

为什么呢？因为对大多数项目而言，首先是能否达成需求目标，其次是能否达成预算目标，最后才是能否达成开发时间目标。而当你发现在达成第一个目标——满足需求方面，人员的整体能力无法依靠的时候，那么最好的做法就是不去依靠他们，而不去依靠有两种做法，一种是在项目开始阶段就彻底替换掉主要人员，代之以合格的工程师，然后采用一些敏捷型或混合型软件工程方法。但如果因为种种非技术的原因，你无法做出这种选择的时候，你就只剩下另外一种做法了：采用重型方法，不能求于人就求于势。

重型方法的特点是详细的计划，仔细的分工加细粒度的模块，严格的控制，完善的文档，细致的评审和严格的规范测试。在这样的开发模式下，因为有严格的流程管理和评审机制，人员可以在任何时刻被合格的或不合格的人替换掉，由于总是可以找到短期的合格人选（如果这都不能满足，那就取消项目吧），虽然不能保证每个人都可以完成任务，但他的工作却可以通过文档和代码的形式保留延续下去。注意，模块粒度必须细，只有这样，才能在必要时彻底放弃某个人的工作。这样做的前提是，时间要有足够的弹性，人员要足够多（如果能达到有些公司所宣称的LOC300行/人月则最佳）。

这种做法对于项目经理将有极高的要求，需要有丰富的经验，优秀的计划和执行能力，敏锐的风险警觉能力，良好的韧性和体力，如开始所称“善战者”。

因此，即使在软件工程领域，也一样是“兵无常势，水无常形。”，即便饱受批评的重型开发方法也有它适用的地方。

（待续）

毕其功于一役的战法总觉得有很大的冒险性。

年龄越大，胆子越小。一个朋友对我说，医院里的老医生有很多规矩，怎样怎样的刀不开。但年轻医生就没有，什么刀都敢开。程序员也差不多。有的程序员什么项目都敢接，什么话都敢说。翻翻历史，就能看到有些老将，知道什么样的仗能打，什么样的仗不能打。

如果真有一个伟大的计划，美好的远景，比较好的是通过对混乱现实进行逐步地改进，而每一步改进都能带来看得见的好处。罗马不是一日建成。三峡工程也要分阶段，划分里程牌。

谁有能力承担大项目？国家？IBM？微软？

“VP5的精神是小项目大系统的精神。XP的反对者指责XP只考虑了小项目，其实这反映了一种理念的差异。我们认为，项目的大小应该在一个便于控制的范围。规模庞大项目将带来很多的麻烦。如果把围棋盘放大到30*30，那我们很多的经验都会失效，会处于比较麻烦的境地。项目应该切分到十个人、三个月的水平。新的产品不应该有大量的新代码。Borland公司的JBuilder是一个例子，他们把一个软件产品做成了“系统集成”。如果项目很大，开发周期很长，就应该将其划分为小的子项目，每个子项目能单独提交有价值的产物。例如由于商业的需要，产品的开发期是一年，那就应该将它分成四个阶段，每个阶段实现一部分能用的功能。从另外一个角度来看，“早发布，常发布”对开发团队的士气影响很大。长期大规模的项目容易滋生变数，从而导致项目失败，所以小项目也是保护投资的好办法。在瞬息万变的今天，大项目的开销越来越难以承受。大项目就象一场豪赌，输掉的可能性越来越大。项目应该是小的，但做出来的系统可以是大的。做到这一点的关键在于复用。当我们听到某个软件有二千万行新增代码时，就不难理解它在发布时还有8万个Bug没有修正。”

说明一下,我说的重型工程不是指规模大的工程,而是指基于严格流程管理基础
上的分析设计先行,强调文档,代码质量和评审的工程方法.另外,重型方法与迭
代开发并不矛盾呀,其实静室工程的主要特点之一就是采用控制迭代的方法开
发.但不管什么方法,第一次迭代的工作量,规模和风险都是存在一个下确界的
,不可能突破,如果第一次迭代顺利完成,其他的都可随心所欲的控制规模和风
险了. 对于整体来说,划分里程碑和阶段也是"势"的一部分.

确实,有些仗是不能打的,我说的前提也是公司里和外面有充分的短期资源或共
享资源可以提供,否则也不成立.现实总是有很多无可奈何的事情,不是完全合
理,因此,即使在不合理的情境下,也应该努力找出一条路来开展工作.不知我们
理解是否不同?

我理解sealw的想法：任何一场大战役也是可以分为小战斗组成，于是，就不需要重型武器了。
从分形学的角度我赞同sealw的想法，也能解释为什么smilemac一直不情愿推荐重型方法的原因。因为我也如此。分形学讲究的是微宏同形，我们只要找到其用于迭代的基本形和迭代规则（这就是重用），小项目一样可以做成大项目，大项目就是小项目。也就是说：轻方法一样能够开发重型项目。
挑战在于smilemac所说的项目组必须有一个既能站得很高，又能潜得很深来看项目的人，象毛主席说的“鹰击长空，鱼翔浅底”一样。只有他，才能发现项目的基本形和迭代规则，从而带领团队用最轻的方法，走最轻便的道路。他和传统意义上的个人英雄的概念是不同的，是团队主义时代的真正的个人英雄。
怎么才能“既能站得很高，又能潜得很深”，精通建模是关键。

　

不仅仅是建模,还需要精通从分析到测试发布的全过程.其实我个人认为,最关
键的还是设计能力.

另外,使用分形来类比迭代不太恰当,分形的维度可以一直分下去,但迭代不行
,分形的部分与整体是自相似的,而迭代模型中的不同迭代(增量)之间要求也不
同.

笑笑。

围棋换成30×30，很多经验就失效了？我们就得从头摸索了？哈哈，真逗。你丫会不会下围棋？

去买本构架的书来看吧。构架师就是那个高瞻远瞩的人，他要考虑技术、需求、时间、资源。

rup适合任何类型的项目，但是要裁剪。正如围棋的金角、银边、石肚皮的原则适用于9×9、11×11、13×13和19×19的棋盘，同样也会适用于30×30的棋盘一样。rup的迭代，也可以理解为对项目的划分，化整为零。但是，仅仅有砖头、水泥、钢筋是盖不出帝国大厦的。需要蓝图、需要构架。大战役可以变成小战役来打，但是得有统筹规划。

同意你的意见，分形和迭代是两回事，是两个不同的概念。我并没有把他们拿来类比。只是用它们的含义来说明如和在大项目中使用轻方法。也就是如何“举重若轻，举轻若重”？现实的分形并不象数学概念那么线性化，一个迭代公式给定初值和扰动就能模拟出山川岩石，雪花河流。软件项目中的分形是具有层次性，片段性的，要不就不会有“整体大于局部之和”了，软件重用其实就是要在实战中发现这些层次性的、片段性的分形。如果你抓到了万变不离其宗的宗，这个宗也不会有多大的规模。

"软件项目中的分形",第一次看到这样的理论.你是说evolution吗?那到有点相
似.但你说的似乎不是,我怀疑是否换个说法更好.分形有严格的理论,直接借用
到管理领域是否恰当?

在19*19的棋盘上两分的定式，在13*13的棋盘上还是两分吗？

我觉得棋盘大小变了之后,确实不少经验不能用了,比如19X19的时候,布局阶段
取外势还是取实地没有优次之分,但换成11X11后,还取外势无异于找死,而换成
30X30后,取实地恐怕与取外势的行子效率也无法抗衡.

所有工作都需要统筹规划,差别其实主要在过程.

到底是金角银边草肚皮呢，还是能者在腹呢？

如果只能重用“围棋十诀”或“棋经十三篇”，大部分两分的定式都不再适用，我们的经验是不是损失太多呢？

叹气，怎么这么执迷不悟呢？

那你说小孩的裤子，大人能不能穿下？但是裤子的构架还不是一样的？两条腿加一个洞？

要从大处看，要站得够高。原则是一致的。甚至判断定式是否两分的原则也有通用的地方，但是要裁剪，要改变。
　

时也，势也。拘泥不变，必死无疑。

有能放之四海而皆准的定律，也有只有一家一户可用的规则，看情况而定了。
　

我理解：进化过程包含自组织过程，自组织过程包含分形过程。

1、如果开发软件象做裤子一样明显，大家也没什么好讨论的了，。。
2、如果把原则放在只要能赢就行，关棋盘大小什么事。
3、要剪裁，要改变，说了等于没说

不关格子数的事。
我们是否还需要一种对同一个项目进行“无级缩放”查看的能力？

道可道，非常道。名可名，非常名。

一切有为法，如梦幻泡影。如雾亦如电，应作如是观。

吾善养吾浩然之气。

凡不可言说的，就不要说。

站在一个很高的层次来看，下围棋和做裤子是一样的。我懂了。

一颗黑子，一颗白子。没有气的提掉。看谁围的空多。从哲学的层面上说，我儿子和李昌镐的围棋水平是一样的。

有人竟然在方寸的棋盘上耗掉一生的精力，计较一目半目的得失，而不去学习哲学，真是愚啊，愚不可及。

有些人底气这个足啊，我遇到了心里这个发虚啊

帖子不见了”的问题。你发的帖子突然不见了，先不要急，组长是不会删贴的。1. 首先用“查找消息”确定是否真的不见了。有时因为不同排序规则的原因，被挤到后面去了。2. 如果确实不见了－－组长不会删贴，但发言人自己可以删自己的贴，此时连带下面的子贴也会被删除。例如，A发言，你跟在A下面回复。A把自己的贴删掉了，你的贴也就没有了。3. 如果不是发言人删，可能是系统问题，请告知组长，组长找维护人员。

这棋盘好大呀，天元在哪里呀！我怎么找不到北呀！
这种感觉是否在面对“大型”的软件项目的时候似曾相识？
摘下显微镜再来下围棋，还是那个棋盘，结果会怎么样？

经常对你的项目变换一下ZOOM比例，感觉会不同，项目并不那么大得吓人。

需要zoom的当然不仅仅是空间，还有时间。
一只蝉的生命只有一天，如果拿秒当小时过，它的命还不算短呢？
一个10年的项目又怎样？如果拿月当天，也不过是个半年的项目而已。

当然，我并不鼓励自欺欺人地变换比例。如果必要的时候，我们总能选择一个适当的Zoomscale,我们也许不会有太多的彷徨。
　

重型工程度最大风险就是把宝全压在开始了. 初期成本非常高. 开始的错误要纠正需要的代价非常的大

这种风险是由任务性质决定的,不是由工作方式决定,而且对于软件开发,不管
什么开发方法,主要成本一定是发生在初期的. 把宝往后压岂不是越往后风险越大.

 回复: 作坊离工厂究竟有多远 (续五) -重型工程
　

---

对于软件项目来说，项目的需求决定了项目采用的方法，而对于小项目来说，是否采用重型工程，我看也就未必，“杀鸡焉用宰牛刀”。但对于大项目来说，只采用XP等轻量工程来整体把控也一样不可。
我个人认为，如果采用的方法已经影响到现有团队的效率（不能通过适应期来解决），加之产品质量没有很好的提高，则需要进行总结，是否该方法适应本项目。
重型工程实施起来比较困难，不仅对项目经理要求高，同时对架构设计师同样要求高，否则如果将设计粒度控制合适，即不影响系统的各项目质量指标，又能充分发挥团队工作的效率，好象许多外包业务中，国外大多设计较细，但也未必设计得很好。
就现在来看，国内大多数的软件企业没有能够真正采用重型工程，除没有有经验的人员（针对重型工程实施）的人员外，就是没有企业自身制定的工程规范。而其实在企业中，规范可以集合整个团队的能力，可以不断完善。如果能在企业的角度上多下点力气，或许就会好些。

目之所視，亦大亦廣，始為得宜。 視遠為近，視近為遠，乃劍道之技也。

高手才做得到，这样的高手，只在传说中见过。

看怎么衡量是小项目还是大项目. 重型方法的好处就在于可以最大限度的共享
项目经理/体系架构师的知识.但想做好需要出色的操作,所以需要项目经理有
比较高的水平和能力.

我认为重型方法不是不好，而只是大多数的企业现在还未拥有高素质的项目经理和架构设计师，不是一下就能做好的，所有我建议可以通过逐步建立适合自身的规程，人员的水平提高之后，才能做好。
在建立规程时，还可以结合类似XP的开发方法，就如对于10个人月的项目。其实每个企业都有自身的长处和缺点，如果说对XP的方式不是很理解或习惯，那么不要采用。我认为对于方法的采用，如果理解不清就使用，还不如不用。
对于项目经理来说，主要是在于项目的计划和控制上，在项目任务粒度很细的情况下，自然要求极管理能力，就象我前面说的，是否有足够的人才？所有企业选择自身的路，但已经有很好的方法和方式可以参考，也应该吸收别人之精华。

我也没有特别推崇重型方法,这篇文章只是谈谈它可以在什么情况下使用,你的
观点我同意,其实我这篇文章前面几节讲的也是同一个意思(一年前在这个论坛
贴的,现在可能还能搜索到).所以这里讨论我想也应该主要讨论它的优点,因为
缺点已经讨论的很多了.

呵呵. 与奥本海默相比,我们既不会做工程,也不懂项目管理.
　

这样改确实是好一些，既保证了自己发表的帖子不会被别人删除的权利，又保证了支配自己所发帖子的权利，不过目前讨论组没有修改帖子的设置。

所以还是保留此设置，先保证后一项权利。“自己发表的帖子不会被别人删除”可以通过不跟自己认为有删贴习惯的人的贴来防止。
　

我看了些贴子，感觉说得较散，重型工程也不是只有一种，能不能对每个常用的重型工程组织一个单独的讨论，之后再进行总论。

重型方法虽然不是一种,但都有一个共同特征,没有此特征就不能叫做重型方法
,而此特征也恰是为人们所诟病的.

我想写的只是一些来自于经验的认识,所讲的也不是各种软件工程的具体特点
或如何具体应用软件工程,这些知识随便找本软件工程的书都可以得到,而我想
讲的是应该从什么角度来驱动对软件工程的认识和使用,有什么误区,如何避免
,(不要只是说"从实用出发").

当然,你说的对,作为文章,我写的比较散,也比较抽象,我不太会写文章,谢谢你
的意见.

我不是说你写的文章有点散，我想你是要带着来一起讨论。主要是大家的角度可能有不一致，就象我一开始对这个主题也有些把握不住。可能是我曾经有段时间没来看看的原因。

如果所谓经验就是外势和实地有分割点，那么和没有经验也没什么区别。