原帖由 knighter 于 2007-9-29 12:18 发表 http://bbs.chinaunix.net/images/common/back.gif
耗子就是被我拉过来参与讨论D:m01: :m01:
:em02: :em02: :em03: :em03:
耗子这里所说的，就我公司而言，我的部门经理就是希望在需求分析阶段一起参与讨论，让每位成员都参与到项目中。
只是现在… ...
我是写程序的，只是从程序员的角度来看，有很大局限性的:em15: :em15:
原帖由 jaffaz 于 2007-9-29 12:20 发表 http://bbs.chinaunix.net/images/common/back.gif
我是写程序的，只是从程序员的角度来看，有很大局限性的:em15: :em15:
倒，你这么说，那我做测试的 :em03:
每个人都有认识的局限性:)
原帖由 jaffaz 于 2007-9-29 12:20 发表 http://bbs.chinaunix.net/images/common/back.gif
我是写程序的，只是从程序员的角度来看，有很大局限性的:em15: :em15:
之前发现跟你同城，就有兴趣搜了下你的帖子，发现你除了在清茶灌水外就基本只是在这里混了。
来了只会看了些老虎的帖子，觉得写得不错，就久不久来这里看看了:em17:
原帖由 knighter 于 2007-9-29 12:27 发表 http://bbs.chinaunix.net/images/common/back.gif
倒，你这么说，那我做测试的 :em03:
每个人都有认识的局限性:)
呵呵，别那么认为。
我的意思是说我之前对于工程管理这部分很少关注，所以你跟老虎讨论这这些问题对我来说都算比较陌生的。
原帖由 jaffaz 于 2007-9-29 12:36 发表 http://bbs.chinaunix.net/images/common/back.gif
呵呵，别那么认为。
我的意思是说我之前对于工程管理这部分很少关注，所以你跟老虎讨论这这些问题对我来说都算比较陌生的。
呵呵，这本来就是一起讨论的嘛
我也是菜鸟:mrgreen:
原帖由 山中无老虎 于 2007-9-29 11:59 发表 http://bbs.chinaunix.net/images/common/back.gif
嗯，我否定软件工程实际上是从对人培养是否有利的方向出发的。
分工上我还是喜欢后分工，因为先参与能够最大限度的了解软件人员技术的优势，这样可以根据不同的人安排不同的方向，能最大限度的发挥其优势。实 ...
软件工程考虑的是怎么样更好的完成一个项目，包括项目的后期维护和跟进。而不是从人的培养来说的。但是我觉得即使从对个人的发展来说，我也会赞同软件工程的分工方式的。对一个新手来说，如果一下子就让他从头到尾都要一个人去完成一个项目，只怕他是苦不堪言啊。但是如果分工的方式，他最初做的也许就是一个很机械的编程工作，就是要求你要完完全全的把别人的设计文档实现，他要考虑的只是怎么更好的熟悉和运用好编程语言和工具，这对他来说会容易多了。而随着这样的工作多了，任何一个有思想的人，都会慢慢去思考，为什么设计人员会这样设计，而且会结合自己实际用编程工具实现的过程中的实际情况，思考这样的设计好在哪，不好又在哪，如果由自己来设计，又会怎样做。这样一步步的，他的成长会更加明晰。而做为领导，如果你想创造一个有利于手下成长的环境，你要做的是，给这些有想法有兴趣的去参与其他不同工作的员工一个机会。同时，你也可以鼓励手下在做好自己的那份分工之余，多思考别的分工和别人的做法的优劣。
后分工的做法，对一个具体的项目来说，会降低效率。了解软件人员技术的优劣，是在平时工作和做项目的过程中，慢慢了解的，你不可能要做一个项目了，然后才去了解每个人，然后才分工。
原帖由 aha111 于 2007-9-29 12:56 发表 http://bbs.chinaunix.net/images/common/back.gif
软件工程考虑的是怎么样更好的完成一个项目，包括项目的后期维护和跟进。而不是从人的培养来说的。但是我觉得即使从对个人的发展来说，我也会赞同软件工程的分工方式的。对一个新手来说，如果一下子就让他从头到尾都要一个人去完成一个项目，只怕他是苦不堪言啊。但是如果分工的方式，他最初做的也许就是一个很机械的编程工作，就是要求你要完完全全的把别人的设计文档实现，他要考虑的只是怎么更好的熟悉和运用好编程语言和工具，这对他来说会容易多了。而随着这样的工作多了，任何一个有思想的人，都会慢慢去思考，为什么设计人员会这样设计，而且会结合自己实际用编程工具实现的过程中的实际情况，思考这样的设计好在哪，不好又在哪，如果由自己来设计，又会怎样做。这样一步步的，他的成长会更加明晰。而做为领导，如果你想创造一个有利于手下成长的环境，你要做的是，给这些有想法有兴趣的去参与其他不同工作的员工一个机会。同时，你也可以鼓励手下在做好自己的那份分工之余，多思考别的分工和别人的做法的优劣。
后分工的做法，对一个具体的项目来说，会降低效率。了解软件人员技术的优劣，是在平时工作和做项目的过程中，慢慢了解的，你不可能要做一个项目了，然后才去了解每个人，然后才分工。
软件工程的理论特别是流水线方式剥夺了一部分人提高自己的机会，一个公司用一个人，应该是即让这个人工作，也给这个人接触其他事物且学习提高的机会，只用人，不培养人，只靠员工自身学习来提高自己我认为是不对的。就好比两个人结婚一样，公司既然在这段时间雇佣了他/她，就要对他/她这段时间的成长负责，而软件工程理论忽略了这方面。你说的那些是我们全都经历过的，但不是软件工程带给我们的，是我们自己体会的。
后分工的作法，对一个具体项目来说，绝不会降低效率。了解软件人员的优劣，在平时了解的只能是一个大面但不会了解非常细，而在项目中了解问题更大，可能会发现此人根本不适合做。所以我还是坚持认为，先集体参与，通过讨论技术解决方案（或需求分析），更细致的了解成员的个人能力，然后再进行有针对性的分工比较好。
原帖由 山中无老虎 于 2007-9-29 13:20 发表 http://bbs.chinaunix.net/images/common/back.gif
软件工程的理论特别是流水线方式剥夺了一部分人提高自己的机会，一个公司用一个人，应该是即让这个人工作，也给这个人接触其他事物且学习提高的机会，只用人，不培养人，只靠员工自身学习来提高自己我认为是不 ...
造成这个问题不是软件工程，而是公司的用人制度。
原帖由 aha111 于 2007-9-29 13:51 发表 http://bbs.chinaunix.net/images/common/back.gif
造成这个问题不是软件工程，而是公司的用人制度。
我不觉得是这样。
我觉得是两方面的因素全有。当然，软件工程我指的是纯理论。
原帖由 aha111 于 2007-9-29 12:56 发表 http://bbs.chinaunix.net/images/common/back.gif
软件工程考虑的是怎么样更好的完成一个项目，包括项目的后期维护和跟进。而不是从人的培养来说的。但是我觉得即使从对个人的发展来说，我也会赞同软件工程的分工方式的。对一个新手来说，如果一下子就让他从 ...
我目前的公司就是不负责培训，比较郁闷啊，靠我们自学，而我又比较不自觉:oops: :oops:
最近才想多了解软件工程:em15:
后分工的做法，应该是挺有效率的，对比流水线生产就知道。但正如老虎所说的，这样做对员工不负责，这一点好像国内很多企业都是这样。外企或者合资企业做得相对好一点。软件业下的后分工导致一些员工只对他/她手头上的任务了解，而对整体则一知半解，长此下去，员工真的只能在IT届混上几年。所以国内才有那种在IT届搞技术混不了多少年之说。