程序员与软件工程是永远的矛盾吗?
以下是软件工程版中正热烈讨论的一个问题，从讨论中我学会了很多，我不愿独享，特收集整理如下，愿与大伙分享。
软件工程版的精华区中有很多此类的精彩帖子，希望大家继续关注软件工程，继续关注www.csdn.net的软件工程版!
主题：程序员与软件工程是永远的矛盾吗??
作者：whitelily
所属论坛：软件工程
我在研发部做各个项目的协调(因不懂编码只能做管理),但发现软件开发总会出现大量问题:如,与计划严重偏离;新人无法接手...我一直觉得最直接的解决办法就是严格实施软件工程,按ISO9001管理.
可是程序员们似乎都非常痛恨软件工程:需求分析中写"实现xx方面的所有功能",什么叫所有功能??这算分析吗? 但项目负责人也能按这种东西做(他们相信口头沟通)!概要设计干脆要拖到编码结束时才做出来,说是这中间变化太大,先写好文档再编码是不可能的...所以根本没法实施质量控制
难道先写好文档,待评审完全通过后再编码真的是misson imporssible吗?开发计划真的不能准确制定,必须一改再改吗?
这是因为软件工程脱离实际还是程序员能力不够?
各位是否能从程序员的角度给些指教?
回复人：zxl_l(凌龙)(2001-5-31 13:19:00)
你让程序员写需求分析中不对的程序员负责安照需求分析、概要设计进行写编码，需求分析由系统分析员完成，需求分析须从整体的角度进行，而一个程序员可能完成某一模块或某一项功能的编码，软件工程不可能脱离实际，问题是你什么执行的？
回复人：rocmeteor(流星雨)(2001-5-31 15:21:00)
告诉老板给你的程序员的工资翻一倍，一切就都OK了。
回复人：rocmeteor(流星雨)(2001-5-31 15:23:00)
一两个程序员这么做是水平问题，如果所有人都这么做，那就是心存不满，进而不怀好意。
回复人：ed9er(始祖鸟)(2001-5-31 15:26:00)
我非常同情那些在没有丰富编程经验的项目负责人的手下干活的程序员
回复人：AutoAsm()(2001-5-31 17:49:00)
管理上面的问题，意识上的问题，操作上的问题，习惯上的问题，制度上的问题
算乐，还是请我去主持项目吧 哈哈 ^_^
回复人：mycode(不写代码)(2001-6-1 1:20:00)
关键是要让程序员知道,写文档与会更加快程序的编写,减少出错;并且还要程序员感受到.如何让程序员感受到就需要组织起来进行比较了。
回复人：whitelily(百合)(2001-6-1 9:34:00)
我们现在的主力都是非计算机专业的编码高手,崇拜个人英雄,难以实施团队管理
回复人：zxl_l(凌龙)(2001-6-1 13:50:00)
实施团队管理是项目经理的工作，也是工作能力的表现。
回复人：myan(老狼麦克)(2001-6-2 20:00:00)
我觉得管理者和程序员之间需要沟通。管理者不要以为自己是将军，程序员都是小兵，搞行政命令那一套在软件这个行当里行不通。我可以表面上服从你，但完全不投入热情，最终项目一定失败。程序员也不要以为自己掌握一点技术就如何了不起。我不得不说，某些编程高手在做人方面不及格，这种高手还是趁早让他走人为佳。
Babara Moo说：管理一个程序员团队，就好像放牧一群骄傲的猫。虽然很难，但是归根到底还是管理者的能力问题。
回复人：svbird()(2001-6-5 17:38:00)
凭你的经验，你应该知道，用户只有能够开始使用你开发的东西的时候才能理解你开发的是什么，然后他们会突然产生各种念头并对该软件应该做些什么真正提出要求。一份系统说明书往往只是一份文档，人们往往不会认真地阅读，但是如果你让他们体验一个可运行的程序之后，他们就会确切地明白你的意思。
如果你不明白这一点，无论是软件工程还是ISO9001又或者是CMM都无法挽救项目的失败。我建议你还是深入项目，了解开发流程中出现的所有问题后再做论断，如果你根本就不了解开发流程，盲目的推动ISO9001或CMM，效果只会适得其反，因为你并没有解决问题的根本所在。改革的过程必须谨慎行事，失败的挫折只会令改革的道路更加艰难。
建议先在一个小型的项目组里进行实验，得到正面的echo之后再逐步全面推广。
不懂编码 = 从未写过程序 = 从未深入了解项目开发的流程 = 对问题所在没有清晰的认识
祝你好运，不过我对你的改革不抱期望。
回复人：steven_cheng(成成)(2001-6-6 11:14:00)
一个好的项目负责人应该有技术背景，否则一切都是扯淡
回复人：mirnshi()(2001-6-6 16:59:00)
需求分析中写"实现xx方面的所有功能",什么叫所有功能??这算分析吗?
这不是程序员要做的。
项目负责人也能按这种东西做(他们相信口头沟通)!
哦，还有项目负责人，那你就不应该找程序员了，直接要求项目负责人对你负责。
概要设计干脆要拖到编码结束时才做出来,说是这中间变化太大,先写好文档再编码是不可能的...
停止编码。某一阶段的任务没完成，就不进入下一阶段。
难道先写好文档,待评审完全通过后再编码真的是misson imporssible吗?开发计划真的不能准确制定,必须一改再改吗?
不要为了文档作文档，懂点技术会好的。
这是因为软件工程脱离实际还是程序员能力不够?
这也许是个习惯的问题。
回复人：yhy(风神)(2001-6-6 19:46:00)
怎么会矛盾呢？如果碰上一位优秀的分析员，程序员们的情绪会空前高涨！他们不仅能够尽量少走弯路，还真正可以体会到软件设计的艺术！他们会觉得不讨好你那真是傻瓜！
whitelily(百合)回复于2001-6-7 8:38:00
多谢大家指教!
另外要说一下,我确实不是项目负责人,我的协调工作只是从管理部门的角度进行的,不懂编码可以原谅吗:-)
yrj (2001-6-8 14:13:56)
其实我感觉到我国的软件工程有个误区:程序员最大.
软件工程的最终目的就是将软件生产变成流水线生产.
程序员只是个编程机器罢了.
chinatime (2001-6-8 14:15:04)
现在各项目负责人从程序员升上去，编码忘记不少，管理又没跟上。
wjzhuang (2001-6-8 14:17:06)
我觉得是管理的问题,合理的制度,适当的认可和宽容,清楚的奖罚,有凌聚力的分析员,有激情学习的气氛。
这样的团队不会出现你说的问题的.
yk_001 (2001-6-8 14:26:22)
管理的，项目负责人也要精通编程呀，一开始就应该知道这个工程的复杂度，可能用的技术，需要新开发的技术，新开发技术的难度和时间。而非由其他人的技术报告，如果你不能自己从技术角度来做开发计划，那肯定是一改再改。
还有你如果不精通编程，呵呵，根本不知道问题具体出现在那里，是人为还是天灾还是。。。，难道看报告？
htxstar (2001-6-8 16:23:03)
程序员与软件工程一点都不矛盾，关键是现实情况太不尽人意，主要表现在：
1、拿程序员的待遇，干系统分析员的活，还要自己编码；
2、项目负责人软件水平太差，以为瞎指挥就行了；
3、很多软件企业根本就没有软件工程的意识；
4、系统分析结果和客户实际需求根本对不上号；
5、为了应付客户，先做一个东东，结果越改越不像样；
6、有些人品德太差。。。。。。
ximuwa (2001-6-8 17:11:28)
完全同意老狼的说法，很多编程高手，我不得不说“很多”，的确做人不及格，而且品行太差！
一个团队，如果仅仅从技术要求合作，绝对失败！绝对绝对做不到！优秀的程序员？什么叫优秀？首先学会做人！
这不是程序员和软件工程的矛盾，还有技术与人格的矛盾！
parkmann (2001-6-8 21:20:20)
作为pm,可以没有技术背景,可以不懂编程,但是要善于沟通和协调.作为pl,一定在技术上能够出类拔萃,压住手下.
liming_zh (2001-6-9 19:40:43)
如果程序员是士兵，项目经理是将军
那么 程序员+软件工程 = 将军
softworm (2001-6-9 20:32:28)
我感觉不能用太多的条条框框来束缚自己，不管是程序员还是设计者，只能在大方向上把握，具体的事情还要具体分析和行动。成功的项目并不是都走的同一条路，当然大方向上肯定是一致的。不管是iso9001还是cmm，如果要完全让项目来迁就规范，那必定有些方面是勉强甚至是不合适的。
