回复关系：
作者 内容
 greatbear   项目开发中的问题，向有项目开发经验的同行讨教
在我们项目开发组中出现的一些问题，不知道有没有普遍性，想和各位同仁一起讨论：
1.在开方案讨论会时，没有人发言，总是几个骨干在讨论，在最后确定方案时没人发表异议，但开发人员的最终结构却往往大相径庭！他们给你的回答总是"我以为..."，“你当时好像就是这么说的...”，难道我每次开会都得用摄像机来做会议记录吗？我们尝试过用Rose开发，但建好的模型往往被束之高阁，相同的问题总在不断发生。有人建议换掉一些人，但我觉得临阵换将似乎不太合适，而且我个人认为我们总应该给员工锻炼的机会，应该允许他们犯错误吧。可我越来越预感到这种做法可能会给项目带来灾难性的结果！
2.每次在进行里程碑总结时，都会发现进度被莫名其妙的拖延了，一个最大的原因就是无谓的迭代和反复，比如一个模块计划在第一周完成，从代码上看完成了，但到第三周有工程师在调用这个模块时提出了意见，一检查是上面所说的第一个问题，只能重写！项目初期，这种问题还不大突出，因为人员的工作基本是并行的，但到了大规模集成开发时，这种问题几乎成了瓶颈，有时候整个工程都在等待一个人排Bug！
3.工程进度的压力，开发人员感觉不到，写完代码后不做单元测试，或对付一下。结果到了系统集成时，所有的问题都出来了，原本早就该做好的工作就这样被分摊在项目开发的全过程了！最严重的结果就是2中所提到的：有时候整个工程都在等待一个人排Bug
4.在项目工程中的经验和教训难以重用，其实很多解决方案是有一定的通用性或起码解决思路有一定的可借鉴性。但一般文档只记录了一个结果，很难回溯过程。我感觉开发团队可以看成一个人在不断学习，总结，进步。所以我一直想建一个知识库，但知识库的数据采集怎么做，如何量化？
 02/05/13 14:06 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 joor   回复: 项目开发中的问题，向有项目开发经验的同行讨教
我想这可能是因为在发挥成员个性和团队写作之间的关系没有处理好的缘故。我想可能首先需要保证的模型的权威性，每个人需要明确权限和责任。最后，我想需要加强团队成员之间的交流，特别是对于建模方法和模型的理解应努力达到一致。
这只是我个人的拙见，事实上我们公司也正在打算用uml语言作为软件建模的工具，目前也没有什么经验，我个人接触uml语言也不过3周的时间，我的感觉是交流是最重要的，非常感谢你提出的这个话题，也希望我们在实践的同时能够充分的交流思想，共同提高。
 02/05/13 14:45 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 happylo   回复: 项目开发中的问题，向有项目开发经验的同行讨教
其实，你所说的这几个问题根源只有一个：设计不充分。
关于第一个问题，其实根本不能怪开发人员，“开发人员的最终结构却往往大相径庭”这个原因肯定是设计上的问题而不是开发人员上的问题，对于一般的开发人员而言，他没有去实现这个方案时，他能提出什么问题和意见为呢？但既然他实现之后有问题，要不就是设计不充分，要不就设计根本就是错的。
关于用ROSE，并不是用ROSE就能解决设计问题。用ROSE这个工具真正要建出有用的模型出来其实是比较难的。就我的经验而言，建出的ROSE模型被束之高阁肯定是这个建模的人面向对象修养还不到家（一般的面象对象修养还不到家的人建出的UML模型往往是简单地按某个示例结合自己的业务依葫芦画瓢，但，在OOA/D过程中，依葫芦肯定画不出瓢）。

我想，你的解决之道，应该是加强设计的深度和用更好的软件设计方法学，在我国的软件界，我想大部分还是“设计不充分”，而远没到出现“过份设计”的时候。
 02/05/13 14:59 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 风雪漫天  回复: 项目开发中的问题，向有项目开发经验的同行讨教
设计人员和开发人员之间有障碍，之间的沟通不充分。从你的问题中可以看出：你怀疑开发人员，不相信开发人员，这就是证据，而实际上，你除了相信他们之外。我想，做好相互之间的沟通是必要的。
另外，你提到在开会时只有骨干发言，你的骨干是不是指设计人员，或者事实上的设计人员。是不是你的会议民主的气氛不够，以至于非骨干人员不敢乱发言，或者发言后怕被笑话。

我个人认为，你的团队存在的最大问题时沟通问题。这时一个leader应该解决的问题。
 02/05/13 15:21 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 greatbear  回复: 项目开发中的问题，向有项目开发经验的同行讨教
嗯，谢谢大家的讨论。其实在沟通时确实存在问题，风雪漫天网友所说的“非骨干人员不敢乱发言，或者发言后怕被笑话。”确实是我所担心的，但我想并不是“会议民主的气氛不够”，因为我们在开方案讨论会时，主要是想协调各方的人员意见，以达到一个统一。比如分析人员提出的方案会不会给开发人员带来压力，因为在开发人员眼里，系分人员总是在纸上谈兵，所以会真正是给开发人员开的，毕竟项目的最终实施依赖于开发人员。
另外网友happylo所说的“原因肯定是设计上的问题而不是开发人员上的问题”，我不太苟同，因为我觉得开发人员在开发前必须很好的理解设计人员的意图，从实施Rose建模的意图来说也是为了开发人员能在设计人员的模型上做，最初以为这么做，就能保持设计人员和开发人员的一致性，但收效甚微。
 02/05/13 16:23 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 Dr.OO  感谢你总结出了很宝贵的体验，这些都是很常见的现象，也很有意思，涉及到更多的管理方法问题...
我已经把它录入了USM社区作为案例，今后我会更多讨论一些组织管理的问题，欢迎大家参与！

Dr.OO
统一软件管理社区
 02/05/13 16:48 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 Dr.OO   关于第（1）个问题，分为两个部分，分析如下：
a. 开发结果与会议讨论大相径庭的原因是，没有达成明确的一致，说的、心里想的与实际做的都不一样。所以应该把会议讨论的结果文档化。用UML模型来统一是正确的一步，这样不会有说不清出的地方。
b. 为什么后来用了Rose又半途而废呢？原因是“建好的模型往往被束之高阁”，说明模型的质量有问题，没有起到实际作用，或者开发人员认为它们没有用。应该加强这方面的能力。
c. 我感觉，你们的开发人员好像有抵触情绪。开发人员大部分是内向型性格的，所以要训练他们，使他们善于沟通和反映问题。
 02/05/13 17:11 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 frankxing   回复: 关于第（1）个问题，分为两个部分，分析如下：
我认为你们换任何人都会是这种结果，即使你们自己做的设计自己去编码有可能也会这样。这不是换人的问题，而是能力都不足和沟通不够的表现。设计人员没有必要去责怪开发人员，其实还是你们自己的设计出了问题。要追究责任设计人员首当其冲。
 02/05/13 17:26 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 Dr.OO   关于第（3）个现象，分析和解决方法：
a. "工程进度的压力，开发人员感觉不到"
说明任务分解有问题，因为没有让开发人员感到进度压力，可能还是因为设计能力有限，不知道该怎么分。
b. “写完代码后不做单元测试，或对付一下。结果到了系统集成时，所有的问题都出来了”
如果不作为却没有惩罚，当然大家都愿意偷懒了。
应该把测试作为正式的任务分配下去，并跟踪和考核，让开发人员认识到测试和开发一样都是应该认真完成的任务。可以考虑采用“同级评审”，互相检查，并与绩效考核挂钩。
c. 项目的风险管理有问题。
“最严重的结果就是2中所提到的：有时候整个工程都在等待一个人排Bug”
既然这个关键构件很容易出错，就应该加大开发和测试的力度。
没有重视抓住质量最薄弱、风险最大、影响整体进度的环节采取有效措施消除风险，基本上放任自流，结果项目经理把风险揽在了自己身上。
 02/05/13 17:30 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 Dr.OO  对，总的来说，你的这个团队，设计师（角色）的问题比较大
 02/05/13 17:32 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 skygis   回复: 对，总的来说，你的这个团队，设计师（角色）的问题比较大
我认为是项目协调问题，需要不断加强
 02/05/13 17:41 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 Dr.OO   [总结] 主要有两个原因：设计能力不足、没有建立有效的开发过程，使得整个团队在构想、节奏、预见和协作4个方面很弱。
1）分析设计能力不足。
使得很多东西说不清、道不明，大家都在那里摸象，对潜在的风险束手无策。

2）没有建立有效的开发过程。
应该明确、细致地定义设计、开发和测试人员的职责、任务、流程、考核方法和奖惩，如果没有这些游戏规则，天晓得项目会做成什么样。

3）还要建立有效的团队沟通和风险管理机制。
让风险、缺陷尽早暴露，而不是让所有人下一跳。
 02/05/13 17:46 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 greatbear  你们觉得如果设计人员的方案不能被开发人员接受的话，是因为设计人员设计的太晦涩？？？
开发人员理解不了，或认为设计人员的设计有问题，为什么不能积极的提出来，在企业中一直有一个“越级”的桎梏，我个人感觉是非常要不得的，并不是说设计人员只管设计，开发人员只管开发。开发人员可以说是设计方案的实施者，他有责任反馈设计人员的方案设计。我觉得应该修改RUP的角色定义
 02/05/13 17:49 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 greatbear  很想听听你对第四个问题的看法（在线等待）
 02/05/13 17:54 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 frankxing   回复: 你们觉得如果设计人员的方案不能被开发人员接受的话，是因为设计人员设计的太晦涩？？？
我看你还是没明白这其中的关键问题，因为你们写的未必明确，所以开发人员有可能会按照自己的想法就去做了！直到他们做完后，你们看到了，发现和你们想得不一样才出来的这种问题。虽然你很容忍开发人员的错，但这不代表你真正的了解他们，你压根就把他们看低了，也把自己看高了，所以出什么错都会认为是他们的错。现在最大的问题是出在你们设计人员身上。多从自己身上找找问题吧！老兄！
 02/05/13 17:57 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 greatbear  回复: 你们觉得如果设计人员的方案不能被开发人员接受的话，是因为设计人员设计的太晦涩？？？
不好意思，其实决没有把所有问题都归结到设计人员身上的意思，让你贴个“不爽”的图标，实在抱歉。其实我一直在从自己身上找原因，但我想原因绝对不是单一的，其实我想说的是如何让设计人员的意图能很好的被开发人员所接受或理解，这个过程是双向的，所以如果这里有问题，肯定是双方的问题，对不对？决没有厚此薄彼的意思。最后谢谢你的回复
 02/05/13 18:04 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 colinluo   随便聊几句
我在某跨国团队开发根本未发现上述问题，关键是公司建立了完善的开发体系。
1.各阶段的文档比较详尽，程序开发严格按代码框架编写，禁止耍小聪明随意更改设计。
2.必须在写代码前编写测试文档，各阶段完成均要求校对审核，不能自己说合格就进入下一阶段，各阶段的测试Bug数有严格要求，曲线超常项目后期Bug递增惩罚也较重。
3.对于新人在各阶段都要先培训后开发，培养一个良好的习惯是很重要的，文档必须符合标准，对齐、全半角、格式错误等必须修改。
4.当然高水平的系统分析员和项目经理必不可少，公司的经验积累也很重要，许多标准都很费时间，小公司尽量多采用现有的标准，例如Web界面采用Oracle BLAF自己就不用开发单独的标准，设计可以采用UML，不用象大型软件公司一样设计自己图标和内部标准。
5.应合理安排文档代码的目录索引结构，复杂的系统最好有索引文档，便于其他项目查找复用，通用模块系统分析后要形成手册，一般在编码之前尽早完成。
6.作项目后好好总结一下，代码不一定能重用，开发经验可以重用。可重用代码添加到知识库，权限管理、组织结构等基础信息的开发应考虑通用化。当然现在也可以采用IBM等公司的组件举例而已。
可惜我也未能很好的总结以往的项目，好象有很多话要讲，又没有很好的思路，
希望大家踊跃讨论多提建议。
 02/05/13 19:15 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 colinluo   OK
 02/05/13 19:17 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 wakeful  说不定是个代价最小收获最大的办法：使设计的粒度更小！！(80/20原理?)
 02/05/13 19:39 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 frankxing   回复: 你们觉得如果设计人员的方案不能被开发人员接受的话，是因为设计人员设计的太晦涩？？？
不好意思！刚才有点激动了！：）
其实做软件这东西关键是要做好管理，没有好的管理，任何一个团队都很难做出好的软件产品，尤其是在中国，中国的软件业是经历过个人英雄时代的，那批老前辈已经成了我们这一代程序员的楷模，每个程序员都希望自己能成为他们那种独当一面的强者，这对个人来说是一种激励，但是在某种程度也加大了软件团队的管理难度。做程序员的都有一股傲气（我也是这样），所以在协作的时候会有点难度，搞好了会促进个性的发挥，搞不好就会各行其是。如何协调团队的协作分工关系其实已经成了一个重中之重。所以我觉得在你所提的一些问题中除了个人能力确实有欠缺外，主要还是一个管理问题。就像是玩九连环，理顺了每个环节都很快就可以拆开，理不顺每个环节都是问题！你说对吧？
 02/05/13 19:46 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 colinluo   设计不充分？
设计也许真的不充分，程序员无法理解系统分析员的意图有两种可能：
1.培训不足，对业务或UML等标准一知半解
2.分析不足或文档太差，给程序员的想象空间太大
 02/05/13 20:02 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 imdt   随便说几句……
这里且不说设计人员和开发人人员的相互交流、沟通的问题，即使设计人员本身也存在交流的问题，换句话就是人与人交流的问题。
我认为，沟通本身存在四个方面的问题。
1、你要表达的内容。
2、你能否一个很好表达方式表达你要表达的思想。
3、听众是否接受（收）了你的表达方式。
4、听众是否完全正确的理解他接收到的内容。

这四个环节的任何一个错误（或者不明晰），都有可能导致，沟通的失败。

我想，uml本身就是要给我们提供一个共同的表达方式。
设计人员要完成的就是1、2，
即： 1、对项目本身的设计有正确的设计思想
2、能够正确的使用uml(表达方式)表达自己的思想

而对设计人员，需要完成3、4
3、能够从uml的文档中理解设计人员的设计思想。
4、形成自己的认识（这里存在一个和1的差异）。

如果，项目的每个人都能很好的完成这个过程，那我想上面提到的问题就不会有那么严重。

《初次，在论坛发言。不足和错误之处，还望各位指正……》
 02/05/13 20:15 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 grantlee  回复: 项目开发中的问题，向有项目开发经验的同行讨教
最大的问题是管理的问题。
1、作为一个项目经理，首先你要对自己的团队又一个清醒的认识，程序员的能力如何？设计人员的能力如何？测试人员的能力如何？等等。所谓知己知彼，首先要知己。
2、项目的进度要随时检查，不能等到里程碑的时候才检查进度。同时，设计要科学，调用时发现错误只能证明设计有问题。当然，有时需求变化也会造成问题，在制定计划的时候要考虑到变化（留出余量）。
3、要有代码检查机制，不能由程序员口头报告完成，应该由测试人员报告完成测试（有一定难度），可以考虑XP的双程序员和测试优先。至少要有代码检查。
4、保证必要的文档。会议要有会议记录，设计要有设计模型。设计的粗细程度要根据程序员的水平来决定（赶进度的时候、正常情况下应该有一个标准）。最重要的是要牢记需求，知道为什么要这样做（设计人员往往为了先进而设计）。知道什么样的需求是用户最关心的、什么需求是最难的。要严格跟踪这些方面（尤其在资源有限的时候）。
 02/05/13 21:18 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  很显然是设计不充分！！！
除非是你手下的开发员彻底没有面向OO的概念和经验，而你手上拥有的所谓有经验人员同时也没有进行任何确认和控制。基本上没有这种可能。如果你的小组真的能作出充分设计的话。

你也不用伤心，情况肯定很普遍，标准的缺乏实践经验的系统分析员和鼓吹程序员蓝领的项目组问题。

提倡软件蓝领没问题，项目不依赖某（几）个明星程序员，随时可以换人，但系分就得给出足够充分的设计，不能依靠程序员的能力和经验，才能达到这里很多人梦想的程序员只是基本上是个人就能干的泥水匠程度。换句话说，你必须给出完整的类图，所有的成员变量和函数，参数接口，函数说明等等。这样就决不会出现你所说的情况1，所有的条件都已经被确定了，可能出现设计上的遗漏，但不可能对已经定义的条件的对应处理有不同理解。这样你的情况2就很容易确认了，或者是第一周模块其实没有完成，因为某些应该对应的处理没有进行，是进度确认上的问题。或者是被确定对应的处理对应了，但第三周一些新条件出现才发现对应不充分，是设计上的问题。至于你的情况3，至少测试方面的安排是项目管理上的大问题，依赖程序员自己检查代码是大忌，不是敬业上的问题，你只要想想，程序员能想到的测试他会对应，被他遗漏的判断他同样不会想到去测试，除非是碰巧遇上。不过如果真的设计粒度很细，至少在模块测试的环节，测试方案应该就有现成的了，只要详细设计书的要求达到了，当然可以认为经过了模块测试。
看你的语气，应该是项目经理吧，所谓“有人建议换掉一些人”，应该是系分要换程序员吧，你认为“应该允许他们犯错误”也就是说你认为错误是在程序员，只是在容忍吧。但问题在这里，你的设计文档能够允许“开发人员的最终结构却往往大相径庭”，不采取“开会都得用摄像机来做会议记录”的方法都不能消除双方在理解上的歧义，设计员的想法和程序员大相径庭的做法都能在表面上吻合设计文档，这种设计无论如何不可能被称为充分吧。除非你充分授权给开发员设计，只提出总体设计思想，而开发人员的能力则令人失望也有可能，但看到既然曾用Rose，好像不是如此吧。

至于你所说情况3的“系统集成时，所有的问题都出来了”，的确常见，麻烦在于你认为是“开发人员写完代码后不做单元测试，或对付一下”引起的，我想问一声，真的所有问题都在编写代码时遗漏IF判断或大于还是大于等于的边界值的简单错误上吗，诸如不得不增加函数，参数，类，类关系调整之类的设计问题就没有吗，如果真的如此，系统集成时的问题应该算很小了。

从你的字里行间看，你是推崇设计主导的，这肯定没错，但因为开发人员承担了具体的开发任务，一旦出了问题，全被认为是开发员的错误，在你的团队里开发员处在什么地位也就一清二楚了，用大家爱举的建筑工地的例子来说，你是工程经理，系分是工程师，程序员是泥水匠，这没有问题，问题是一旦建筑出了问题，你查的不是工程师有没有设计足够的地基，或正确的承重桩，而是泥水匠怎么把楼房盖坏了，现在你又问如果泥水匠认为工程师的设计有问题，或承重桩打错地方了，为什么不提出来。回答很简单，职责不同，泥水匠可能知道承重桩的位置错了，但不是泥水匠必须知道承重桩的正确位置。在工程师的指示下盲目干活不是最好的泥水匠吗。如果想要工程师说一句打桩，泥水匠就能知道应该在哪里打才正确，好像要求高了一点？恐怕不是用RUP或MS Project来管理项目，用UML还是伪代码来写设计文档就能解决的问题。关于人际，管理，人力资源等方面的资料可能更有针对性。

可以想象，对于很多看不起编程，也没有足够编程经验的系统分析员来说，尤其是那些硕士博士毕业就自然而然搞设计的精英来说，我对程序蓝领过于重视了。问题只有一个，要在项目中不依赖个别人当然好，程序蓝领能给公司节约资金和人力，绝对是好事，但既然是蓝领，就不能指望什么丰富经验和判断，于是详细设计的粒度必须很细，有很详细的说明文档说明需求，才能随时换人而不影响项目。而这个详细设计的分析员，必须很精通具体实现，不管是自己的编程经验还是从别人那学到的。否则说难听一点，死都不知道怎么死的。比如说设计一个动物系统，基类“动物”有“取得年龄”，“成长（加一岁）”等方法，子类“水生动物”有“游泳”方法，子类“哺乳动物”有“保持恒温”方法，现在要设计子类“鲸”，从“水生动物”和“哺乳动物”双重继承，在OO的思想没有问题。如果开发语言是C++，编程没有问题，但在系统集成时会为了是否虚基类的问题把人搞死。当然有实践经验的人会知道多重继承是C++的高级课题，能避则避。那么延误的开发时间责任应该算谁？如果用JAVA，可能其他的程序都写好了，在写“鲸”类时发现JAVA不支持类的双重继承（为了降低开发难度，是语言特性），程序不得不大改，怪谁？这只是最简单的例子，诸如同步，线程安全等实现时的问题还多的很。总之，想要实现软件蓝领的理想，首先必须确保能提供细粒度，高质量的详细设计书，这样，如果程序员看不懂UML的类图，培训也学不会，经理可以很轻松的换人，再也不用担心程序员流动了。当然，是否需要担心写详细设计书的人员流动，则超出了软件蓝领的范围，是另一个问题了。

当然如果你的设计的确很好，但开发员对UML类图的符号理解错误，首先是培训，如果教不会，当然只有换人了。这是没有办法的。那样的话，就不用管我上面说的话，我为上面的胡猜乱测道歉。
 02/05/13 22:59 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel   知己最难。另外
至少程序复查，专职测试对保证开发质量很重要，问题是几个项目经理能接受所要付出的资源呢？双程序员就更不用提了。
需求取舍是心理上的考验。

公司政治对项目用什么解决方案这方面的影响恐怕比任何因素都大。
 02/05/13 23:14 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 吴三疯   回复: 项目开发中的问题，向有项目开发经验的同行讨教
我认为应该需要一种跟踪机制，从需求到开发，开发不能理解需求，或自己单干，在详细设计时就应该指正；同理，测试也应该以需求为依据，检验开发的设计。每个人应该都对要做的东西有个全面的认识，不能挑战权威的不是好战士，在讨论中统一思想，开会要有纪要，事后有据可查。
 02/05/14 01:05 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 frankwoo  回复: 项目开发中的问题，向有项目开发经验的同行讨教
看里上发言，觉得有点不妥：
1。责任在项目经理以上，在软件开发中，人的因素至少占70%，以及的不合格，本质上在于上级的不合格。一个项目经理如果对于整个项目采用的是“摸石头过河"的方式，又怎磨能要求“底下“得同僚呢?
2.how could a good designer be a real good designer if he (she) is not at least a good programmer, at least the designer is the mentor of the junior guys.maybe these guys are good programmer but they are not good business analyst. so I advise you to hire the real expert no matter she/he knows or not the software to do the requirments gattering and analyst. and for the architect if he/she is not a good programmer at least then I think she/he is incompetent.
3.the test and development/design should be arranged parallized, and don't hope all the errors be correcte and found out by the programmer.
4.if a lots of trouble showed up when doing integrity then 100% responsibility should be took by the project manager( he did not find the crisis from beginning , so don't make complaints and work hard :).5.
 02/05/14 04:09 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 holly_lee   透过现象看本质: 关键是两个问题
1. 人员水平问题
2. 沟通问题

这两点导致了所有的问题出现. 而通常 1 会导致 2.

不要说中国人的编码水平如何如何高, 我看差得远呢.
也不要说都是管理做得不好, 管理一好软件工程一用一切搞定, 没有的事.

一点一点说.

1. 讨论时没人说. OK. 正确. 因为人员能力不够, 他们无法在讨论时就明白到底是什么, 他们需要在
做的时候慢慢地试图了解, 因此没有人发言是非常常见的现象.

2. 由 1 产生的, 不用多说了吧? 排除 1 的因素, 其实返工也是常见的, 这时关键在于返工的
速度/效率问题了. 而这又取决于落实做此事的人员的能力问题了.

3. 依然是人员能力问题. 在一个较低技术能力层次上的人员来说, 他们是对代码质量没有概念的.

4. 理解才能应用. 就算你能建成这样一个知识库. 想用的人理解不了又能如何?


在人员能力普遍低下的情况下, 谈什么"只要管理搞好就 OK" 真是天大的笑话. 就算你说
"你们如果再出现 bug 就 fire" 那么最后也只能是全部 fired. 软件过程? 过程只是手段,
而人员的能力是基础, 没有基础谈什么手段.
 02/05/14 10:38 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  Can't agree any more.高，实在是高！
 02/05/14 10:47 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 glovebx   回复: 项目开发中的问题，向有项目开发经验的同行讨教
同意一部分人的说法。之前我领导的一个项目，也有一抹一样的问题，最后
导致大部分程序由我自己来修改。
原因，我想一是沟通不够，往往想着赶项目进度，忽略了如何去关心组员，
组员没有了主人感，做事情的时候会缺乏足够的责任心。
二是没有充分信任组员，我在带第一个项目的时候，兼任技术经理，检查程序
一看到不行，马上亲自动手修改。后来他们说我不信任他们。

事实上，做项目和做人一样，要不停鼓励别人，要允许其他人犯错误，并且
要帮助组员，无论生活还是工作，这样这个团队的战斗力和凝聚力才会不断
增强。
 02/05/14 12:56 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 Dr.OO   关于第（4）个问题，可以从总结实践方法（practice）和模式（包括设计和管理模式）入手
围绕解决眼前的问题是效率最高的，也最富有成效。

可以收集、总结对常见问题的解决方法。这需要团队集体做出贡献，一般可以由项目经理或架构师出面组织，通过研讨的形式，把好的方法记录下来，赢得大家的信任，并运用到平时的工作中去，成为组织的知识结晶和行为规范。

不知道你说的“如何量化”指什么？
是否指过程的测量数据，那就是另外一个问题了。但好像你的团队还没有达到这个阶段，应该先从一些基本的最佳实践方法做起，改变项目失控的状况。
 02/05/14 14:03 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 Dr.OO   非常好的建议！colinluo，能否再介绍一下你在跨国团队中的其他问题和经验？
 02/05/14 14:12 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 alexandro   就事论事说几句。
关于1。很正常啊。方案是很概念性的东西。讨论时在怎么详细也还是难免比较抽象，就算大家都认可，理解上还可能不一致，在实现上也有可能碰上问题。这个时候需要的是持续控制，不是说方案定下来，大家开会传达一下就OK了。如果他说“我以为....”是在所难免的，那就想办法让他早说。

2。模块完成是指测试通过才算完成。持续集成有助于及早暴露问题。

3。基于2。所以开发人员不会没有压力。有时侯，单元测试不足，但在持续集成时，可以被查出来。

4。每份文档都有变更记录。但还没有上升到库的概念。什么时候引入个知识管理吧。
 02/05/14 15:41 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 n6002  回复: 项目开发中的问题，向有项目开发经验的同行讨教 我看毛病多了
我看毛病多了，其实从自身来寻找毛病最贴切，你不可能改变别人。

首先，明显设计没有完成就走到下一步了。
 02/05/14 16:17 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  回复: 透过现象看本质: 关键是两个问题
如果只是全部人员能力低下，倒真是软件工程学发挥作用的地方了。可能性的确很大。
大批国内的高手程序员其实水平远比自己以为的低，真正的好程序员在哪里都不多，中国也不例外。

就怕统一按学徒工进行标准化管理，真要是运气好来了个高级技工也白搭。
以前是五十步笑一百步，现在是一百步笑五十步了。
从分析到编程，GARBAGE IN, GARBAGE OUT.
 02/05/14 18:42 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 holly_lee  回复: 透过现象看本质: 关键是两个问题
hehe ... garbage in, Large garbage out.

中国高水平的比其他地方还要少得多
 02/05/15 00:08 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel   回复: 透过现象看本质: 关键是两个问题
记者是天生大脑进水，以为我们不缺程序高手，可以理解。业内居然也有这么多人信以为真，就充分证明我们的真正水平了。
不过看一群还没搞懂模式的精英讨论反模式，XP，还是很有趣的。至少潮流现在跟得比较快。
结论，为什么国内不缺高手，因为我们不缺会说几个自己其实不懂，但别人没听说过的缩写词的人。其中不少人还真的以为自己很能干，看不起程序员这一低级工种了，不错不错，大有前途。
要真的说我们和别人的差距的话，九十年代C++，SMALLTALK的广泛使用是OO开始大量被使用，95年设计模式就出版了，经过几乎同样多的时间后，开始认识到过度设计，讨论起反模式，XP。我们是2001年设计模式的翻译本出版，没编程经验的精英也能认为看懂了设计模式，还没开始设计就和别人同步进入反模式，反过度设计了。程序员会用JAVA的一些库函数，知道SWING的一些类就自以为是高手，精通OO了。到处宣传我们不缺高手了。究竟差了多少也就不用多说了。嘿嘿，标准的现代版夜郎自大。不过看笑话的感觉还是不错。
 02/05/15 01:55 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 caidehui  说得不错，能否介绍一下开发过程，以及系统架构师的工作等情况
 02/05/15 09:04 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 风雪漫天   嘿嘿，高手都来了，小弟特意来听课
 02/05/15 09:21 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 caidehui  团队分工不明确，沟通不够、设计不充分、架构未优先、系统优先级不清楚，没有轻重、测试没有提前、没有架构，日构建无法进行
我也说几句，感觉问题是比较普遍，大部分开发团队或多或少遇到过同样的问题。
我认为首先开发团队和团队分工有点问题。系统分析和设计是一伙人，开发是一伙人，不像一个团队。好像每个人的责任也分的不清楚。如果在一个团队中的每一个人不知道自己的责任是做什么，让他开会（不知道是开什么会，好像要在一个会上确定结构，难啊）时泛泛而谈，他要么口若悬河，离题万里（高高手）；要么等着别人说，自己嘀咕（我们很多时候是这样）；要么无话可说，一尊雕塑（新手）。
合理的分工（不是歧视）是非常必要的。在分工前提下，充分的沟通是成功的基础，设计系统框架的人和实现系统框架的人本来就应该互相通气，稳定的框架，慢慢的变化（除非设计系统框架的人本身就对自己没有信心，那就非常危险了）。
从你描述来看，真的就是设计系统框架的人技术有问题，设计不充分，这样导致信心也不够（不过推脱起责任来应该有一套，就像你说的），最后房子是盖了，不过原来是楼房，后来成了板房而已，而沟通又不够，即使知道会盖成板房，也会先盖成板房后再说（如果时间压力紧，更加会这样，先给人家一个板房再说。）
感觉系统架构在你的系统中也没有优先考虑，在大多说系统中，系统架构总要先行。这个架构在分析设计阶段就进行考虑了，为什么没考虑呢，应该是系统的优先级没有划分好，为什么划分不好，那还是设计人员水平不够。任何时候都要考虑系统最重要的部分。迭代中，系统架构往往是重点迭代，一般是初始架构和稳定架构两个部分，初始时首先考虑系统中最重要的需求、最影响架构的需求、技术上问题最大的需求，分析、设计、实现。没有架构，后面要进行Build EveryDaty，也无法做到，做不到这点，你的测试问题就大了，单元测试也好、集成测试也好，有你头疼的。

所以我建议：1、雇佣更好的设计师，或者培训现有的设计师，恢复他们的信心。2、合理的团队分工，消除歧视。3、合理的沟通途径。4、划分系统的优先级、架构优先。4、测试提前，前期主要检查设计的一致性，各种文档的追溯性（质量问题需要有专人或者独立的小组负责）。开发不但要进行单元测试，还要进行集成测试等等。5、架构优先的前提下，实现每日集成或者重要点上集成，进行全面的测试。6、在系统优先级的基础上，设计适宜的迭代。7、评审，各种评审，还是评审。

多说了几句，请勿见怪。
Cai
 02/05/15 09:53 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 holly_lee  回复: 透过现象看本质: 关键是两个问题
呵呵, 我可是每天到这里看笑话的啊....呵呵...老兄哪里高就? 现在象老兄般脑子清醒的人可真不多了.
如果在上海, 大家可以一起聊聊....呵呵...
 02/05/15 12:14 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 品雪  饭局？
 02/05/15 12:29 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  Holly同志的发言充分体现了“葵花宝典”的思想精华，呵呵
那就是：
1.无止尽地追求个人能力的提高
2.团队能成为团队是因为沟通成本很低

看来葵花宝典团队篇还是得写啊，我本以为前辈都讲清楚了，大家都明白了。呵呵。
 02/05/15 13:03 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 greatbear  通过大家的讨论，我对我们团队的问题有了更清晰的了解。尽管问题的解决不是立杆见影的但还是谢谢各位！！！
 02/05/15 17:41 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  呵呵,不敢当
好歹也是从96年开始职业编程到现在快30岁了，要还象小孩一样不懂也太不像话了。
人倒是上海的，惭愧的紧，现在当汉奸给鬼子编程，要聊的话恐怕要等年底回国了。不过想想现在看笑话虽然不错，如果真要我和这些精英打交道，说不定还是我上司，未免就太过无趣了，也算出国的好处吧。
老兄那10条没把我乐死，居然还有人没看出是反讽，一直以为自己比较迟钝，当时就放心了。
 02/05/15 20:31 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee   编码前通过设计文档建立起共同理解，编码后强制执行单元测试，加强主动性
 02/05/15 21:14 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  那就年底吧，先在我这里预订一下
我是饭局总代
 02/05/15 21:42 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  好,好。一切以饭局为中心
以圣小猪的名义
 02/05/15 22:00 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  找一地方吃烤全圣小猪？
 02/05/15 22:02 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  OK
 02/05/15 22:04 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 原教旨  faint! 算是知道先知是怎么死的了。
以圣小猪的名义吃很好了嘛，把圣小猪烤烤吃了就是你的不对了
 02/05/15 22:24 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 holly_lee  呵呵...终于露面了?
万一烤到小朋友怎么办? 没烤到小朋友烤到花花草草也不好啊.....
 02/05/15 22:31 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 原教旨  呵呵，最近比较忙^_-
 02/05/15 23:01 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 colinluo  以后有时间再和大家多聊聊，在Unified Software Management论坛吧
 02/05/16 18:16 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 wwwdy  help!挑战性能压力测试！！！高手我在能你！
请高手指点！
如何用Rational SuiteEnterprise v2002进行性能压力测试？
软件体系架构为：browse(frame+applet)－WebLogic－Oracle三层体系.采用http、weblogic的t3协议。
是用loadtest?但在Rational SuiteEnterprise v2002中好象已经没有loadtest了？
如何用QALoad进行性能压力测试？
软件体系架构为：browse(frame+applet)－WebLogic－Oracle三层体系.采用http、weblogic的t3协议。

如何用LoadRunner进行性能压力测试？
软件体系架构为：browse(frame+applet)－WebLogic－Oracle三层体系.采用http、weblogic的t3协议。

这3个测试工具哪一个好？哪一个能支持上面的体系架构和采用的协议？
 02/05/16 18:29 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：