精彩专题 |
如何做好项目沟通计划
软件项目质量管理
国际工程索赔与反索赔
|
| 更多：
|
|
联系社区管理员 |
咨询电话 010-82273401/11
斑竹申请 admin@mypm.net
版权所有 © 2003-2004
京ICP证070584号
BBS业务许可2007第353号
最佳显示模式：1024*768像素
|
|
 |
[转帖] 重读从程序员升级到工程师有感 [发表于 2004/9/2] 状态 开放帖 浏览量 1197 |
|
|
[从程序员升级到工程师]，重新看一遍，不禁有些许感触。
已经记不清第一次看见这篇文章是什么时候了。只记得当时经验还少，拜读此文，恍然大悟，怪不得我们的软件落后，原来差了这么多。本来觉得自己公司的做法已经够正规了，原来还是差。后来在不同的地方又多次看到这篇文章，这篇文章流传之广，恐怕是程序员圈子里数一数二的，尤其是会上UMLCHINA的程序员，恐怕有不少是受过这篇文章影响的。我本人是随着经验的增长，每次看每次的感触都不一样。尤其是和印度的项目有了实际的接触以后。如今看来，当时的恍然大悟其实不过是经验少带来的浅薄无知罢了。
对于在软件开发的泥沼里苦苦挣扎的程序员来说，有的始终在无序状态，有的见识过所谓的软件工程，却没有多大的实际用处，突然出现了一个印度的成功例子，觉得前景一下子光明起来也是理所当然的。程序员的酸甜苦辣这里出现过的例子也不少了，一下子能变成悠闲，而且还一切尽在掌握中，怎么能不为所动。只可惜这个世界上没有灵丹妙药。
我们羡慕印度软件工业的发达，从这篇文章和其他介绍中我们也了解到印度有完善的软件工程，有CMM，有充足的文档。我们就以为，只要我们也有这些，我们就也能发达。不是吗，印度人都能干到的事，我们聪明的中国人又有什么作不到的。
现在，让我们脱离这个简单的因果关系，动动脑子来仔细分析一下。先从这篇名作开始。
我想，任何一个程序员对这篇文章首先惊讶的应该是开发商能在客户面前坚持300行/人月的开发速度，代码行数虽然没有太大的价值，也是一个简单的参照，国内有哪个软件企业敢这么声称？有没有可能如果我们的软件开发也以此速度作为最初开发的基准，是不是不用别的就能提高开发质量？没有人有这个数据，这个实验不可能在受控条件下可再现的进行。另一方面，如果一个原来30,000行规模的软件能有100个人月的预算，哪怕只用20个人月做设计，也很可能最终能以5,000行就能完成，那么应该如何计算基准时间？是不是意味着同样的功能，用20个人月设计，10个人月编码，测试完成5,000行的开发效率就低于用原来的总共100个人月完成30,000行？然而，这也只是一个数字游戏，事实上在开发时，或者选择了5,000行的方案，或者30,000行的方案，并不会知道别的方案究竟需要多少时间，也就是这个比较其实无从做起。人的因素影响太大。文中同样提到，300行/人月是经验数据，说明这不是基于某个被公认的理论，只是开发商内部的参考数据。这个数据要有效，只有两种可能。一个是现在的开发人员就是提供数据原始统计来源的人员，这意味着这个数据对别的开发组织没有参考价值，因为人员素质差别的影响很大。一个是这是所谓能确保的能力水准数据，人员素质千差万别，但至少能保证这个基本的开发能力，就是说这个是在最坏情况下也能达到的控制线，如果想知道实际上能达到怎样的速度，对不起，没有用。你能知道一群高中生作小学3年级的数学能确保80分，但不会知道需要5分钟，还是10分钟。维持这样的进度事实上浪费了人力资源，却是对项目经理最安全的。而且，任何一个有几年工作经验的程序员都知道，要预计一个开发需要时间是困难的，但还是有可能的。要预计一个开发需要的行数，以100行为误差单位都几乎是不可能的。除非工作只有拷贝+改if判断值/改for的边界值。一周写几千行代码不少见，一周调试排错的结果只是一行代码，甚至某个环境设置的问题也常见。把一个共有函数inline就能增加几百行代码。所以最后的结论就是印度开发商用人月的行代码数作为参考，不过是为自己提供安全余量，要求开发费用的手段而已，对真正的开发过程没有任何帮助。
接下来，我们程序员会对项目进行的流畅程度羡慕不已，不过项目的流畅是因为印度开发商遵循了什么完整的v模型开发过程，还是因为需求分析的内容都没有改过？不否认管理的重要性，无序状态只会带来失败可以算是公理了。但是需要管理，需要流程到什么程度？实际项目开发中很多问题都是需求变化造成的，有不可回避的客观因素，也有需求分析没有做好的缘故，但是设计，编码，测试的步骤并不能帮助最初的需求分析阶段掌握完整的需求也是肯定的，于是问题就是，如果我们有了完整的，不变的需求，是不是还需要这么完整的开发流程？如果由于某些因素，需求还是变化了，这么完整的开发因素是不是真能帮助我们解决问题？如果项目进行到测试阶段，结果需求变更了，前面的流程，review是不是真能避免有时会发生的整体结构变化？这关系到应该在需求阶段还是开发阶段的流程管理投入最重要的资源。所谓两者都重要，得兼顾之类的废话就不用说了，绝对没错，也绝对没有用。项目开始时有100%的资源，需求是投入30%，40%，还是50%，既然是科学的工程，总的有一个实际能用的数字，如果还需要参照项目经理的能力进行自由心证，依赖于随机数这算什么工程科学？同样，这个问题也是事实上无解的。
UMLCHINA的文章不全，原来的文章还有一大堆对程序员的不满，对印度不考虑效率的快速开发方式的崇拜，总之设计，管理上的问题都归中国程序员，项目的顺利结束归功于印度项目经理和设计师。这里就不作引申了。正好，我见过印度开发商宣称需求上没有性能要求从而拒绝改善性能问题。见过印度开发商对客户提出的需求改变意见干脆利落的回答“NO”， 见过印度开发商对客户反映的bug（运行中出现assert）表示在新版本中修改了，客户应该以50万美金购买新版本（虽然这个被拒绝升级的版本是半年前才交货的，所谓的新版本在原来能运行的重要功能也变得不能运行了），见过印度开发商宣称虽然是bug，但是既然用户以前能用别的手法回避这个问题，现在也应该继续回避，不应该要求他们修改。作为商业手段当然值的参考，但是如果学习软件工程的目标是开发这样的系统，我看也就算了。
我们为什么需要软件工程？是为了开发软件，不是符合什么RUP流程，达到CMMn。我们希望需求分析后，能不依赖个人能力，经验就能估算开发规模，需求上能判断哪些是有比较大的变化可能，哪些可能会相对固定。技术上能发现各种方案有哪些风险，哪些技术难点需要尽早解决，不要开发到了一半才发现技术上不可行再改换方案。需要判断需要怎样的人员组合，怎么样的能力。需要决定是培训人员的能力使能实现优秀的设计，还是调整设计使符合现实。决定关注以后类似项目开发的通用性，还是先做出来再说。需要知道当第一个milestone延期时，整个项目按时完成的可能性还剩多少，需要如何调整。从测试结果能不能推算出到最后提交产品还需要多少时间，预计质量如何。我们需要清楚的知道项目能不能，有没有可能按计划完成。需要知道当项目出问题时是减少功能，还是追加工作时间，还是必须增加人手，或是调整发布时间整个时间表。需要能让团队发挥最大效力。这其中牵涉到管理，心理，组织行为，软件工程，时间预算人员压力的平衡。归根结底一句话，人的能力和能让人发挥能力的体制。
我们不需要什么，不需要无数的进度报告，那些无意义的50%，80%进度没有任何价值，不要说90%完成的功能，就算已经完成的机能也随时会因为需求变化，设计变化而化为乌有。如果项目经理不知道实际情况，只会从报告中了解情况，迟早会发现这个世界突然就不转了。不需要理论家来说一些绝对正确，却不能具体操作的废话，只会让人无所适从，变成一仆多主。不需要去追求某个流程，某个标准只是为了某本书上这么说，而不是出于实际的需要。不需要在项目组成员已经了解设计意图的情况下追求生成完美正确的UML图，更不能有了完美正确的UML图以后就放任项目组成员错误理解意图（可能因为只有图的生成者才学对了UML，使用了某些不常用，容易造成误解的形式，充分展现了才能，而别的成员对UML还没有到这么深刻的地步）。不需要大量的管理以至于项目成员的工作不是完成项目却成了提交报告满足各式各样的管理要求。不需要无数的文档以至于没有人知道哪个才是最新，最正确的（也许全是过时的）。不需要那些不懂编程的设计师写出一堆没人会参考的所谓设计图（参考的危害比扔在一边还大）。不需要那些自己也不知道为什么，只知道CMM要求，RUP说，却自诩为元帅的流程工程师设计一堆只会让人精疲力尽的流程和报告，除非这些流程得到的结果有实际上的指导意义。
可惜，需要的还处于人月神话的阶段，不需要的则是登堂入室，喧宾夺主了。
印度的成功在于瞄准软件外包市场，利用人工差价，我们外包开始还没有几年，人工就没有多少差价了。以前还盯着国内市场，国内有什么市场？家用市场是盗版的天下，企业市场，大量的国企是倒闭都来不及。脑白金这样的产品更是在生产管理上投入1元还不如在广告上投入100元，也就只剩少数企业和政府市场了。这时候什么最重要就不用多说了，谁都知道肯定和软件工程无关，大家抢一小块蛋糕，日子能不难过吗。却非要照搬印度经验。
嘿嘿，到处都是说中国国情，不该说的地方也到处都中国国情，独树一帜。到了真正该考虑的时候，我们就和国际接轨了。倒也是奇哉怪哉。也许这才是真正的中国国情
|
--------------------------------------------------------------------------------------------------------
让生活如涓涓细流，欢快，轻盈，歌唱着一路欢腾下去...
让工作成为我生活的图腾... MSN:ruddyli@hotmail.com
>>> 由论坛统一发布的广告：
|
|
楼主
 ruddyli
职务 无
军衔 上校
来自 北京
发帖 1764篇
注册 2003/8/28
PM币 10623
经验 
 
|
|
 Re:[转帖] 重读从程序员升级到工程师有感
[回复于 2004/9/3]
|
|
社会主义初级阶段嘛，好像现在还不能太搞得有模有样，不然就肯定要被“菜掉”的！
|
--------------------------------------------------------------------------------------------------------
nt5.0@sohu.com
|
|
1楼
 BillGao
职务 无
军衔 上校
来自 不告诉你 :)
发帖 1234篇
注册 2004/6/14
PM币 2862
经验
|
|
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
