| 作者 |
内容 |
| cajan2 |
 各位对基于合同的项目有什么推荐的过程？下列案例能否诊断一下，如何说服美国回来的老板
项目目前规模还比较小，老板又是从美国SUN回来的，据说是按照美国标准的开发流程来的。
总的感觉是偏重ER图的数据建模方法。我们的开发工具主要是Java和PB。Java
使得OOP变得普及，不过OOA&OOD没有跟上。
目前主要的问题有：
以下几个方面：
1.需求分析没有使用UC建模，文档中有很多重复之处，修改文档很可能造成
不一致问题。另外和最终用户的交流是通过数据流/业务流和demo(用户界面或者
原型）。一般业务部门的最终用户看不懂复杂的数据流/业务流。
2.需求变更没有管理，从需求分析、ER图直接到编码。开发人员很多精力放在怎样使界面更加漂亮上面，没有什么建模，全靠经验和感觉来编码。
3.产品化进程比较慢，数据库和其他部分有很多Hard
code。
4.没有多少产品化软件，又没有一个CMM这样的过程认证，不利于接到大项目。
5.开发人员自以为是XP，却没有Pair Programme。使用XP需要很多设计和编码高手，这里大多数的programmer的个人编程能力没有达到一定的高度，对于UML顶多略知一二。
|
| 02/03/04 14:05 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| cajan2 |
回复:
各位对基于合同的项目有什么推荐的过程？下列案例能否诊断一下，如何说服美国回来的老板
另外，美国那边的人是否对XP又成见呢？
今天的过程建立如何为未来的CMM认证打下好基础呢？
XP没有文档，源代码和测试就是文档。有的人XP说不写不需要的文档，好像
所有过程不会鼓励你写多余的文档吧，“什么才是多余的文档”，理解不一样而已。
如果要建立RUP，培训量很大。一般的公司对于培训有以下担忧：
1.费用大，包括人力、时间和讲师费用；
2.培训后，留住人的难度将会增大，如何应对呢？
3.对公司的管理要求也加大了。如何协调？ |
| 02/03/04 15:23 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| lzhihua |
你们老板在sun做什么的？要说服他，只能投其所好。
|
| 02/03/04 15:28 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| cajan2 |
 在SUN是咨询顾问吧。不知道详细情况，作需求分析，对于数据库比较熟悉。对于J2EE比较推崇。对于UML的重要性也有一定的认识
老板没有听说过RUP，开发经理对于UML和RUP没有多少概念。
大多数开发人员只有零星的认识，只有一个Team
leader了解一些，需求分析和实现无法衔接，经常和系统分析员吵架。
还有需求变更对开发人员的伤害也比较大，现在作的项目还比较小，没有暴露出来就是了。
对于这种情况，是先建立好灵活软件过程，还是等到几年以后稍微大一些的项目面临很多痛苦时才考虑此事。也许等不到几年公司就倒闭了也不一定啊！
又要马儿跑，又要马儿不吃草。建立一个好的软件过程和开发团队需要很多
费用，这个事情能不能作呢？
责权利不一致不到位。经理可能觉得学一学UML很容易只安排了2－3天时间，就是introductory都要4－5天。我对这些东西倒是研究和实践过几年，别人不相信你也没法。有的人是官本位，请教你时很虚心，转过身就说理论高的人连界面都画不好。虽然我使用VC++,VB,Ansi
C++，Java多年，难道要我和他们每个人比试一下不成？看来没有一定的权利光靠技术上面的精通是无法完成软件过程的构造的。
我从1996年开始使用Booch方法和Use-case结合C++作OOA&D,有时候顺带玩玩
VB（数据库功能较好，属于快速原型工具）。做过GIS和电信网管通用平台等等软件密集型大项目。Java出现的时候没有理他（太差了，国内又没有人投资作基础平台如应用服务器的开发），J2EE平台成熟时学了半个月，从Java核心到企业版特性和XML全部过了一遍。不算以前的applet,我的第二个Java程序就有800行，边看帮助边用JBuilder3天完成(希望熟悉Jbuilder工具，没有用Rose自动生成代码）。我老婆是硕士生，她学了半个月还不如我其实我也不是特别聪明，唯一的诀窍是不买电视机，顶多看看原版DVD。
我现在比较困惑，难不成又要去考个证书才能取信于领导吗？1997年考的MCSE，当时没有几个。可是你看现在比较泛滥了。我对考证书失去了兴趣。
|
| 02/03/04 16:19 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| cajan2 |
UML和OOAD的结合是我学习Java的过程象回家一样
因为Java某种程度上是对C++的简化。
VB的编码效率高，Java兼有效率高、pure oo和跨平台特性。所以我现在
基本上全用Java了。
我夫人其实也有C++基础，她学了半个月还不如我学了半天的理解透彻。
关键的原因就在于是否真正理解OO思想，抽象能力很关键，这需要在理论和实践中反复多次。 |
| 02/03/04 16:33 |
酷帖！ 臭帖！ 回复 |
酷帖评价： 臭帖评价： |
| 返回页首 |
|
| lzhihua |
目标没错，只能循序渐进，一步一步来了。我曾拿一个我们几近失败的项目来向老板说明需求管理和迭代的重要性。否则老板认为你不coding
就是在浪费时间。
|
| 02/03/04 18:10 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| w_rose |
 太简单了！如果B开发员的代码需要引用A开发员生成的部分，但是B总是怀疑A是笨蛋，迟早会拖累自己，那么就把B的程序设计成“事件”方式的，不需要安装A的代码就可以开发和测试，不就解决了吗？当然这不仅需要了解开发语言，还要了解编译好的代码所运行的操作系统。
|
| 02/03/05 19:19 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| sliuhao |
回复:
各位对基于合同的项目有什么推荐的过程？下列案例能否诊断一下，如何说服美国回来的老板
说说我的看法吧，进供参考。：）
1。可能缺少领域专家的角色。就像要实施erp的话，你一般来说必须要有erp实施顾问一样。
2。用户需求是变化是客观的，所以要准备迎接用户的需求变化。在对用户需求用户需求变化的管理上，我没有什么建议。但在设计的时候，可能就要充分考虑用户需求的变化所带来对自己代码的影响和冲击。
3。产品化进程比较慢，我觉得主要原因还是设计的力度不足带来的结果。可能在后期的主要工作就是fix
bug.如果要add new feature的话，可能对你们现有的类层次和接口带来巨大的影响。在这过程中，主要通过对设计的改善来得到提高。比如对数据库的访问存取，我建议你使用persistece
layer，能有JDO或ODMG3.0的API那就更好。这样，你的设计就不是由数据库的设计来驱动你的类的设计了。
4。不太同意你的观点。关键是要有一个好的管理机制和人文环境。
5。对xp的使用，我觉得是量力而行。
“程序员最常犯的错误并不在他的程序错误列表中。它与程序员的年龄或选择的程序语言没有任何关系。这个最常犯的错误就是误以为自己具有了所有的能力而且根本没有提高的余地了。
这可以说成是人的天性；但我认为人的天性是对知识与提高的不断追求。可是，傲慢自大和害怕犯错使我们止步不前。抵制这两种坏习性不仅可以使我们成为更好的程序员，还可以使我们成为更好的人。”----------from
更佳编程之路
这有两片很好的文章，
http://www-900.ibm.com/developerWorks/linux/sdk/road/part1/index.shtml
http://www-900.ibm.com/developerWorks/linux/sdk/road/part2/index.shtml
fyi |
| 02/03/06 11:23 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| cajan2 |
我发现作程序员还有一个问题，就是过于乐观
一般来说，我们发现问题不能解决，就以为是自己没有掌握某些知识，比如
说不熟悉某个编程语言或者其他什么开发过程。这个时候你会很努力地去学习，
当你基本上已经熟练应用那些语言和工具时，虽然你不一定用他完成什么现实地项目，但是你已经信心十足。
如果一个项目充满着乐观地程序员，而且这些程序员还会作些设计，这时候也许就是灾难的开始。
实际上问题不在于程序员能力是否足够，而是如何填补需求、分析、设计到编码的鸿沟，还有经常被忽略的测试。
你记得有多少项目经过了很好的测试？谁在构造用例的时候同时构造好了测试用例？真的所有的路径都测试过了吗？大家都热衷于学习新技术然后编码然后又学习更新的技术，谁真的认真对待过测试？
项目结束后，是否进行了项目回顾？是否从那些倍感痛苦的项目成员那里得到对项目的真实感受？或者把痛苦的成员赶走，大家为项目的成功欢呼，然后掩盖问题。那所谓的成功项目面对的就是稳定问题和严重的维护问题。
前面项目出现的问题，如果得不到展露更不用说采取行动去解决，那么等待
贵公司的就是每个项目重复同样的错误。
真正成熟的产品是逃避不了这些话题的。 |
| 02/03/07 12:59 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| cajan2 |
也许是个好办法。不过如果你面临的是个虚拟OS(项目的另外一部分人开发的）
而这个虚拟OS的编码仅仅比你的设计早1个月，你在调试自己代码的时候必须为开发平台作测试工作。
现在知道多层次并行开发的痛苦了吧！
如果还有一个你无法控制的调试环境，这些调试环境是一堆Embedded
system组成的前台.那些前台的人员要么觉得自己的部分没有问题要么有新的项目要做。他们已经进入修整阶段，你想加班都会没有人配合你的。
你的项目和这个前台项目有很多的接口。这么说吧，从presentation层的编解码，到前台串行链接的数种不同机架（当然有不同的开发人员）控制程序，和你的管理程序都有接口。而这些接口的定义和协调涉及不同项目不同行政部门，这些部门和项目之间的协调涉及到更高层的领导。这些领导不可能为你协调没完没了的接口会议或者争吵。领导对项目的估计全部是从下属的估计，而这些下属根本不了解全局的依赖情况和面临的风险。一旦某个齿轮出现问题，必然带来连锁反应，而那些被定位为主干部分的模块将占据优先资源。有时候很多次要模块必须让位于主要模块，包括领导的协调和调试环境都优先属于主要模块。但是并不是说主要模块按时完成了次要模块就可以自然完成，你说谁应该为项目的延误负责？
这是我曾经经历过的一个软件密集型项目，一个没有还好管理的项目。但是
经过痛苦的过程，终于成功了。但是项目成员的脾气越来越暴躁，结果只有某些会推卸责任的家伙留下，其他大半包括专家级人物离开了公司。
从失败中我们可以学习到很多，甚至超过了“成功”。尤其是那些倍感痛苦的成功项目，却没有得到及时的回顾，项目不仅仅是为了本身，开发过程的持续改进也是一个重要的成果。
|
| 02/03/07 13:27 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
