三国开发思路

我的目标游戏其实很明确,就是类似三国志九的游戏,目前中华三国志(CLIP_ON制作),已经基本上满足要求,但是类似三国志九的游戏关键是在其思想精髓而不是形式本身(本贴不讨论思想精髓),所以做类似三国志九的游戏仍然是我的目标游戏。
从目标游戏这个角度，我与其它开发者有很大区别。其它开发者设计游戏往往以好玩为目的，而不对好玩形式作限定。我认为这样是不妥的，因为既然三国志九游戏能吸引我和很多玩家，就说明它给玩家带来了一种独特的感受，而开发类似三国志九的游戏的目的就是要把这种独特的感受再现，而好玩仅仅是一个泛泛的概念，并不能保证能带来这种独特的感受，而再现这种独特的感受恰恰是我开发的原因，仅仅好玩不足以促成我的开发。但也不反对在三国志九思想精髓基础上增加一些新的好玩的元素，然而三国志九思想精髓是必须有的，而不是笼统的好玩。这正是我反对搞WEB三国，FLASH三国，小三国游戏原因所在。
在开发方法上，我主张以能力为核心，以自身的基本能力为基础加上适当的劳动完成游戏。如果劳动量过大，那么这样的开发付出大于收益，得不偿失，会对自身身体、兴趣、生活等造成不良影响，这正是很多人无法坚持的原因。所以，开发要量力而行。但是量力而行并不意味着类似三国志九的游戏无法做成，因为决定一个游戏能否完成除了劳动还有能力，如果能力高了，劳动量可以减少到合理的范围，那么就可以动工。能力的提高可以通过理论学习，也可以通过实践。因此在能力不足的时侯，并不是说不要开发，而是通过开发起到试探和提高能力的作用。我之前开发的战略三国，模拟三国和战争正是如此，一方面起着试探的作用，了解实际开发需要经历的步骤，但由于我当时对开发的困难（包括技术和管理方面，尤其是管理方面）认识不足，也因为培养合作者的需要，所以发了有关贴子表达我在开发目标游戏的意思，即使是现在这种表达也是必要的，同样是基于试探（虽然困难认识深入了，但是情况也发生变化）和培养合作者的需要；另一方面起着提高实践能力，了解实际问题的作用。我近两年之所以不进行开发实践，除了身体原因以外，还有一个原因就是能力的提高不只有实践这条路。长期以来，我以实践为主，忽视了理论的价值，近两年的所做的正是去学习和思考各种理论，尤其是思维方法方面的理论。而且就目前来说，能力与目标游戏的差距是比较明显的，实践不能有效的缩小差距（当然在不同时期缩小差距的手段是不同的），而我的目标游戏又比较明确，所以没有实践的必要（既不能完成目标游戏，又不能提高能力）
我开发总的思路是以能力为基础，通过不断提高能力，来缩小与目标游戏差距，待其达到劳动量适度，再正式开发目标游戏（至于是否能达到劳动量适度，不在本贴讨论），但是是否适度随实际情况而变，故正式开发目标游戏是个试探过程，并不保证成功。此外，在提高能力的同时，还可以把心得总结出来，供以后开发者参考，以使以后开发者不必再向我当初那样从头开始，从而达到提高开发素质的目的。这个思路能使开发在有乐趣的过程中进行，并且不致于过累，同时能够充分把心得分享，能从态度和方法上符合人的心理规律。对思路的总结就是提高能力，缩小差距。

看起来有些像纯理论研究一样，是真的开发游戏么？

看了一下楼主的开发史，值得学习。不过楼主三国之家里的“思维科学”看起来好玄乎，太哲学了，有些难以理解:hz1042:

通过适当的组织，可以将大工作量的项目在尽量不影响个人生活的情况下通过增加团队人数和拉长制作周期的方式完成。轩辕春秋版的岳飞传在业余团队的组织上是一个成功的例子，但是我个人认为它的成功不可复制到正向开发上，因为岳飞传的技术难度大、工作枯燥的编码工作非常少，而且投入产出比比正向开发要高得多。

个人认为，要解决业余团队的正向开发必然需要软件工程的支持，尤其是开发人员工作时间无法保证，开发能力参差不齐的情况下。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-23 10:54 发表
通过适当的组织，可以将大工作量的项目在尽量不影响个人生活的情况下通过增加团队人数和拉长制作周期的方式完成。轩辕春秋版的岳飞传在业余团队的组织上是一个成功的例子，但是我个人认为它的成功不可复制到正向 ... [/quote]
管理也是技术之一,同样需要研究和学习,而且难度不亚于技术

还有软件工程讲的太浅,不足以指导开发,倒是心理学得好好学,否则协调人的问题很难解决

[color=Silver][[i] 本帖最后由 陈珺 于 2010-5-23 11:36 编辑 [/i]][/color]

[quote]原帖由 [i]numdisp[/i] 于 2010-5-23 09:12 发表
看了一下楼主的开发史，值得学习。不过楼主三国之家里的“思维科学”看起来好玄乎，太哲学了，有些难以理解:hz1042: [/quote]
你看聊天记录,就没那么玄了

[quote]原帖由 [i]陈珺[/i] 于 2010-5-23 11:32 发表

管理也是技术之一,同样需要研究和学习,而且难度不亚于技术

还有软件工程讲的太浅,不足以指导开发,倒是心理学得好好学,否则协调人的问题很难解决 [/quote]

讲得太浅是指。。。？软件工程的发展虽然没有解决所有问题，但是对于提高国内开发团队的开发水平还是绰绰有余的。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-23 11:49 发表


讲得太浅是指。。。？软件工程的发展虽然没有解决所有问题，但是对于提高国内开发团队的开发水平还是绰绰有余的。 [/quote]
就我上面说的,人协调的问题就没解决好,毕竟软件工程一本装不下那么多心理学

[quote]原帖由 [i]陈珺[/i] 于 2010-5-23 12:09 发表

就我上面说的,人协调的问题就没解决好,毕竟软件工程一本装不下那么多心理学 [/quote]

没解决好也比没解决要好得多，一本书装不下可以有多本，软件工程这些年的发展并不是简单重复多年前的观点。其实软件工程无用论在国内还是挺流行的，结果就是自己在低水平徘徊。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-23 12:15 发表


没解决好也比没解决要好得多，一本书装不下可以有多本，软件工程这些年的发展并不是简单重复多年前的观点。其实软件工程无用论在国内还是挺流行的，结果就是自己在低水平徘徊。 [/quote]
软工还是有好书,只不过能读懂的恐怕没几个
[url]http://www.china-pub.com/49090[/url]
[url]http://www.china-pub.com/49263&ref=xilie[/url]
[url]http://www.china-pub.com/49264&ref=xilie[/url]
这些是比较新的发展了

[quote]原帖由 [i]陈珺[/i] 于 2010-5-23 12:36 发表

软工还是有好书,只不过能读懂的恐怕没几个
[url]http://www.china-pub.com/49090[/url]
[url]http://www.china-pub.com/49263&ref=xilie[/url]
[url]http://www.china-pub.com/49264&ref=xilie[/url]
这些是比较新的发展了 [/quote]


有研究编程的劲头何愁看不懂软件工程？近年来各种轻量级软件工程方法也有较大的发展，比如各种敏捷方法，这些方法都很注重实践且易于执行。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-23 12:44 发表



有研究编程的劲头何愁看不懂软件工程？近年来各种轻量级软件工程方法也有较大的发展，比如各种敏捷方法，这些方法都很注重实践且易于执行。 [/quote]
你试试读懂上面那三本

[quote]原帖由 [i]陈珺[/i] 于 2010-5-23 12:49 发表

你试试读懂上面那三本 [/quote]

我读懂问题不大，但是我读懂了对你基本没有什么用处吧。这三本就代表软件工程的全部了？那么多轻量级方法就被你无视了？
你非要造出太空堡垒来才会打仗吗？跟前有AK47就看不上眼？非得赤手空拳到太空堡垒造出来？

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-23 13:31 发表


我读懂问题不大，但是我读懂了对你基本没有什么用处吧。这三本就代表软件工程的全部了？那么多轻量级方法就被你无视了？
你非要造出太空堡垒来才会打仗吗？跟前有AK47就看不上眼？非得赤手空拳到太空堡垒造 ... [/quote]
软件工程跟孙子兵法一个性质,兵书而已,但真正上战场光靠孙子兵法远远不够,实际的战争要比孙子兵法上复杂的多

实际上,即使是公司,团队合作失败率同样很高,合作成功的往往有很大的运气成份

[color=Silver][[i] 本帖最后由 陈珺 于 2010-5-23 20:31 编辑 [/i]][/color]

[quote]原帖由 [i]陈珺[/i] 于 2010-5-23 20:28 发表

软件工程跟孙子兵法一个性质,兵书而已,但真正上战场光靠孙子兵法远远不够,实际的战争要比孙子兵法上复杂的多

实际上,即使是公司,团队合作失败率同样很高,合作成功的往往有很大的运气成份 [/quote]

且当软件工程跟孙子兵法一个性质吧，那么懂兵法的人和不懂兵法的人上战场哪个打胜仗的机会更大呢？

软件项目失败率高正是软件工程试图解决的问题，虽说现在还看不到完全解决问题的希望，可是你是在坚持造不出太空堡垒就赤手打仗，没有长生不老药就不治病妈？

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-23 20:42 发表


且当软件工程跟孙子兵法一个性质吧，那么懂兵法的人和不懂兵法的人上战场哪个打胜仗的机会更大呢？

软件项目失败率高正是软件工程试图解决的问题，虽说现在还看不到完全解决问题的希望，可是你是在坚持造 ... [/quote]
关键是比软件工程更好的兵书已经很多了,为什么不选更好的兵书呢

[quote]原帖由 [i]陈珺[/i] 于 2010-5-23 20:59 发表

关键是比软件工程更好的兵书已经很多了,为什么不选更好的兵书呢 [/quote]

比如说？

我看上面两位不必为了上面“兵书”的问题太过执着。理论与实践本来就是相辅相成，相互促进的东西。两者其实并无先后顺序与孰轻孰重的关系，也不存在“最好的理论”这样的问题。

不过看到楼主的一些历程，我倒是有些想法想拿出来说说。

现在很多人，特别是国内一些从事研究工作的人，上到教授下到研究生，都喜欢抱着一种思想：一定要把理论研究透了，才能开展实际工作，否者就会走弯路，得不偿失。这种观点也不能说错误，但是这要建立在一个很大的假设上：那就是理论是完全正确的，不需要修正的。但是很不幸的是，迄今为止，人类的任何一门科学都不是“完全正确”的。一切理论总是以或多或少的假设和抽象为前提的。你可以说理论是99.9%正确的，可是正是这0.1%的误差，会导致实际的结果跟理论大相径庭。大猩猩和人类的基因相似度高达97%以上，但是你能说那剩下的3%是可以忽略的么？ “科学”与“技术”两个词的差异也正在于此。

并不是反对楼主研究理论，而是我觉太过于沉迷其中的话也不是什么好事（以纯理论研究为工作的人除外）。所谓尽信书不如无书也是这个道理。

你说的是一部分研究机构做的事情，实际上更影响IT业发展的是无视理论。种种XXX无用论的论调比着一定要把XXX研究透的想法可是流行得多。看看现在中小企业的开发水平还有业余开发社区的水平就知道了。现在还真是缺少理论研究。

[quote]原帖由 [i]numdisp[/i] 于 2010-5-24 03:58 发表
我看上面两位不必为了上面“兵书”的问题太过执着。理论与实践本来就是相辅相成，相互促进的东西。两者其实并无先后顺序与孰轻孰重的关系，也不存在“最好的理论”这样的问题。

不过看到楼主的一些历程，我倒 ... [/quote]
你没有理解清我这主贴的意思
虽然我曾经的确存在过把理论弄完美的想法,但已经不是我现在的想法
关于理论与实践协调的问题,也不是简单的并重理论与实践,具体怎么协调最好,我论坛有专门贴子说明过
还有,业余开发本来就没有要求一定要做项目,能提高并分享心得本身就有意义,这也正是纯理论研究的价值所在,理论研究不需要一定完全正确,而是通过研究开拓思路,提高能力.

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-23 21:03 发表


比如说？ [/quote]
既然你提团队合作,那么更直接针对这个问题的应该是心理学和人力资源管理.
软件工程包括软件开发方法学和软件项目管理,软件开发方法学不管是否需要团队合作都是需要掌握的,与团队合作关系不大,而软件项目管理所提供的方法远远不足以解决实际问题.

虽然不一定需要太空堡垒来打仗,但是拿个破枪打仗,打败的概率很高
所以关键还是先要判断所拥有的枪是否适合打仗,网络合作的背后是现实的社会环境,没有些基本的了解,在计划,沟通,协调都是非常困难的

[quote]原帖由 [i]陈珺[/i] 于 2010-5-24 20:32 发表

既然你提团队合作,那么更直接针对这个问题的应该是心理学和人力资源管理.
软件工程包括软件开发方法学和软件项目管理,软件开发方法学不管是否需要团队合作都是需要掌握的,与团队合作关系不大,而软件项目管理 ... [/quote]

照你这么讲所有叫作XX工程的学科都可以不要了，只需要开技术课程外加心理学和人力资源管理就可以了？软件工程里面很大一部分内容就是讲如何协作的，而且大部分流行的软件工程方法都是经过实践检验的，不知道你所谓的“远远不足以解决实际问题”是否只是说你所掌握的软件工程知识呢？即便你说软件工程不足以解决实际问题，但是你还是需要说明解决实际问题是否完全不需要软件工程？

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-24 09:17 发表
你说的是一部分研究机构做的事情，实际上更影响IT业发展的是无视理论。种种XXX无用论的论调比着一定要把XXX研究透的想法可是流行得多。看看现在中小企业的开发水平还有业余开发社区的水平就知道了。现在还真是缺 ... [/quote]
这个其实跟国家环境有很大关系,很多人温饱都成问题,所以没有必要精力去关注理论,而认识理论的重要性本身就需要静下心去慢慢体会,而现在连静下心的前题都没有

[quote]原帖由 [i]陈珺[/i] 于 2010-5-24 20:38 发表
虽然不一定需要太空堡垒来打仗,但是拿个破枪打仗,打败的概率很高
所以关键还是先要判断所拥有的枪是否适合打仗,网络合作的背后是现实的社会环境,没有些基本的了解,在计划,沟通,协调都是非常困难的 [/quote]

需要比较的是拿枪和赤手空拳谁的成功率更高。软件工程本来就是要解决实际困难的，可是被你无视了。

[quote]原帖由 [i]陈珺[/i] 于 2010-5-24 20:45 发表

这个其实跟国家环境有很大关系,很多人温饱都成问题,所以没有必要精力去关注理论,而认识理论的重要性本身就需要静下心去慢慢体会,而现在连静下心的前题都没有 [/quote]

软件工程理论是指导实践的，非要放着前人积累的经验不用，自己去摸索一套，岂不是更增加满足温饱的难度？软件工程中纯理论研究少之又少，轻量级的方法论倒是有很多，很难想象连轻量级方法论都没有精力去学习的人还能有精力搞什么。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-24 20:42 发表


照你这么讲所有叫作XX工程的学科都可以不要了，只需要开技术课程外加心理学和人力资源管理就可以了？软件工程里面很大一部分内容就是讲如何协作的，而且大部分流行的软件工程方法都是经过实践检验的，不知道 ... [/quote]
从现代管理学的角度,工程这种做法的确有很多问题,工程的思路其实已经是几十年前的,现代管理理念的是流程再造,工作轮换等等
不过也不是说软件工程的学科都可以不要,关键问题是软件工程理论研究者思路出了问题(就跟人工智能一样,连感情都很难解释),这样的学科就只能借鉴参考,但如果软件工程能有编译原理(形式语言学),数据库(关系规范化理论)那样成熟,当然可以用

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-24 20:51 发表


软件工程理论是指导实践的，非要放着前人积累的经验不用，自己去摸索一套，岂不是更增加满足温饱的难度？软件工程中纯理论研究少之又少，轻量级的方法论倒是有很多，很难想象连轻量级方法论都没有精力去学习 ... [/quote]
不需要自己去摸索一套,管理学本身同样也是解决实际问题来的,而且比软件工程更全面更深入,用管理学不是更好?

[quote]原帖由 [i]陈珺[/i] 于 2010-5-24 20:57 发表

从现代管理学的角度,工程这种做法的确有很多问题,工程的思路其实已经是几十年前的,现代管理理念的是流程再造,工作轮换等等
不过也不是说软件工程的学科都可以不要,关键问题是软件工程理论研究者思路出了问题 ... [/quote]

终于明白了，合着你一句话就把软件工程最近几十年的发展给否定了，那就难怪你得出这种结论了。

我可没说赤手空拳去打仗,而是说换个好点的兵器
至于纯理论,离散数学应该就是纯理论,但它的作用不需要质疑吧,很多时侯纯理论往往能开阔思路,而应用理论只不过是教你怎么把纯理论与实际问题结合起来,比如数据结构,它就是教你怎么把图论与具体编程语言结合起来,学的是契合点,而不是图论本身,实际开发可以用更高级的数学方法解决问题

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-24 21:03 发表


终于明白了，合着你一句话就把软件工程最近几十年的发展给否定了，那就难怪你得出这种结论了。 [/quote]
人工智能也发展几十年了,但它的确有很大毛病,难道不该否定?
我既然说借鉴就不是完全否定.

[quote]原帖由 [i]陈珺[/i] 于 2010-5-24 21:15 发表

人工智能也发展几十年了,但它的确有很大毛病,难道不该否定?
我既然说借鉴就不是完全否定. [/quote]

我说你否定了软件工程最近几十年的发展，也就是说你观念中的软件工程是几十年前的软件工程，不是现在的软件工程。

[quote]原帖由 [i]陈珺[/i] 于 2010-5-24 21:11 发表
我可没说赤手空拳去打仗,而是说换个好点的兵器
至于纯理论,离散数学应该就是纯理论,但它的作用不需要质疑吧,很多时侯纯理论往往能开阔思路,而应用理论只不过是教你怎么把纯理论与实际问题结合起来,比如数据结构 ... [/quote]

我记得我前几年发过一个帖子是说学与用脱节的事情，从你的描述还是看到了这个现象，可能也是因为这个原因，会让你看不上软件工程。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-24 22:14 发表


我记得我前几年发过一个帖子是说学与用脱节的事情，从你的描述还是看到了这个现象，可能也是因为这个原因，会让你看不上软件工程。 [/quote]
那你就是很大的误解,事实上恰好相反,我能用操作系统解释日常生活中各种管理问题,能用生产管理学解释软件工程的思想,这种学以致用如果还是学与用脱节,那别的更是脱节
要知道,高级语言设计的再好最终都要转成机器代码,那那抛开代码机器设计高级语言是不是就没意义呢

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-24 22:02 发表


我说你否定了软件工程最近几十年的发展，也就是说你观念中的软件工程是几十年前的软件工程，不是现在的软件工程。 [/quote]
那你说说有什么重大成果,据我了解敏捷开发之类的还是从生产管理学里弄过来的,还有很多思想,比如流程再造,内部客户,还没来得及弄

再说一句,很多人只是简单的说理论要与实践结合,那么怎么结合?为什么不会深入思考这个问题,而往往满足"理论要与实践结合",对于深入思考这个问题的观点,往往又以浅显的"理论要与实践结合"观点去评价它,那不就是喜欢浅显的观点而排斥深入的观点?

[quote]原帖由 [i]陈珺[/i] 于 2010-5-24 22:37 发表

那你就是很大的误解,事实上恰好相反,我能用操作系统解释日常生活中各种管理问题,能用生产管理学解释软件工程的思想,这种学以致用如果还是学与用脱节,那别的更是脱节
要知道,高级语言设计的再好最终都要转成机 ... [/quote]
你能不能用软件工程方法指导软件开发才是主要的。能用管理学指导日常生活的管理，能用操作系统原理指导操作系统开发，能用生产管理学指导生产才算学以致用，当然只是能解释也已经不易了，保守估计最近一级的本科毕业生至少一半做不到这一点。

[quote]原帖由 [i]陈珺[/i] 于 2010-5-24 22:41 发表

那你说说有什么重大成果,据我了解敏捷开发之类的还是从生产管理学里弄过来的,还有很多思想,比如流程再造,内部客户,还没来得及弄 [/quote]
我对管理学接触不多，请教敏捷开发中的几个重要实践，比如测试驱动、持续集成、快速迭代、集体代码所有权，都是从生产管理学的哪里弄过来的？

企业管理学我更是没有系统学过，在我粗浅的理解里，CMM之类可以理解为有关软件开发流程再造的，不知道理解的对不对？

[quote]原帖由 [i]陈珺[/i] 于 2010-5-24 22:49 发表
再说一句,很多人只是简单的说理论要与实践结合,那么怎么结合?为什么不会深入思考这个问题,而往往满足"理论要与实践结合",对于深入思考这个问题的观点,往往又以浅显的"理论要与实践结合"观点去评价它,那不就是喜欢浅显的观点而排斥深入的观点?[/quote]
那看来在你眼里软件工程就是一门阐述“理论要与实践结合”的学科而不是一个指导实践的学科了？

[color=Silver][[i] 本帖最后由 Maxwell 于 2010-5-24 23:46 编辑 [/i]][/color]

测试驱动、持续集成基本是从全面质量保证弄来的
快速迭代是从并行工程弄来的
集体代码所有权也是从全面质量保证弄来的

[quote]你能不能用软件工程方法指导软件开发才是主要的。能用管理学指导日常生活的管理，能用操作系统原理指导操作系统开发，能用生产管理学指导生产才算学以致用，当然只是能解释也已经不易了，保守估计最近一级的本科毕业生至少一半做不到这一点。[/quote]
指导实践不难,关键是难处理兵书上没提到的问题

[quote]那看来在你眼里软件工程就是一门阐述“理论要与实践结合”的学科而不是一个指导实践的学科了？[/quote]
可以指导实践,但指导的程度不够,而且一些方法存在问题
更关键的是有点呆板,缺乏应变能力
还有对人的培养这方面比较欠缺,似乎停留在利用现有能力的层面

[quote]原帖由 [i]陈珺[/i] 于 2010-5-24 23:58 发表
测试驱动、持续集成基本是从全面质量保证弄来的
快速迭代是从并行工程弄来的
集体代码所有权也是从全面质量保证弄来的 [/quote]
我所提到的几个都是敏捷方法中的具体实践，不知道分别对应于全面质量保证和并行工程中的哪些实践？

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 00:06 发表

指导实践不难,关键是难处理兵书上没提到的问题 [/quote]
心理学和人力资源管理已经覆盖了实践中所有问题？

全面质量管理的基本思想:
全面的质量概念
全过程质量管理
全员参与的质量管理
全企业质量管理
运用一切现代管理技术和管理方法
1、顾客至上
            以顾客为中心，明确顾客的需求，并贯穿于整个管理、决策过程中。
2、预防为主
             质量问题产生于设计、制造、供应，强调以事前预防、工作质量管理为重点。
3、基于事实
            以搜集、分析数据把握事实为基础做出决策。
4、质量教育
           持续不断地对企业全体员工进行教育与培训，使他们在思想观念、管理方法和技术水平等方面能够满足支持与推进全面质量管理的要求。


那几个就是针对不同方面提的,但是预防为主实在做得太不够

产品设计的新方法——并行工程
       并行工程是对产品设计及其相关过程包括制造过程和支持过程进行并行、一体化设计的一种系统化的工作模式。

       这种工作模式力图使开发者从设计一开始就考虑产品在生命周期中的所有因素，包括质量成本、进度及用户需求。

并行工程的本质分析:
1、强调产品设计的“可制造性”、“可装配性”和“可检测性”
2、强调产品的“可生产性”
3、强调产品的“可使用性”、“可维护性”和“可报废性”
4、强调产品开发各种活动的并行交叉
5、强调技术人员要学会在信息不完备的情况下进行设计
6、强调面向过程和面向对象
7、强调系统集成与整体优化

快速迭代的思想基本就是上面那几条

[quote]心理学和人力资源管理已经覆盖了实践中所有问题？[/quote]
起码覆盖了很多软工没提到的,比如沟通,协调

其实我借鉴的意思是用生产管理学,人力资源管理去比对软工的做法,有缺陷的去改进,没有的去补充

[color=Silver][[i] 本帖最后由 陈珺 于 2010-5-25 00:27 编辑 [/i]][/color]

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 00:11 发表

可以指导实践,但指导的程度不够,而且一些方法存在问题
更关键的是有点呆板,缺乏应变能力
还有对人的培养这方面比较欠缺,似乎停留在利用现有能力的层面 [/quote]
软件工程中哪些方法是指导的程度不如心理学和人力资源管理的？
在各种项目中恐怕很少有像软件项目这样需求变化迅速多样的了，为了解决软件项目的开发问题而生的软件工程学的应变能力也不会次于其它工程学，尤其是以“拥抱变化”为口号的敏捷方法，实在看不出哪里呆板了。
术业有专攻，软件工程涵盖不了软件开发人员的生老病死，软件工程中确实不包括教育理论，但是软件工程中很关注人的因素，有如何充分发挥个人能力和团队能力的内容。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 00:26 发表

软件工程中哪些方法是指导的程度不如心理学和人力资源管理的？
在各种项目中恐怕很少有像软件项目这样需求变化迅速多样的了，为了解决软件项目的开发问题而生的软件工程学的应变能力也不会次于其它工程学，尤 ... [/quote]
呆板是指它只能知其然,而不知所以然,而管理学是能知所以然,这样才不会生搬硬套,软工实践最大问题恰恰是生搬硬套.
软工的确有关注人的心理,但还是不知所以然
比如说知觉的选择性,注意的浮动,性格的影响,还有从众行为等等,都没涉及到,特别是性格这方面影响很大

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 00:19 发表
全面质量管理的基本思想:
全面的质量概念
全过程质量管理
全员参与的质量管理
全企业质量管理
运用一切现代管理技术和管理方法
1、顾客至上
            以顾客为中心，明确顾客的需求，并贯穿于整个管理 ... [/quote]

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 00:22 发表
产品设计的新方法——并行工程
       并行工程是对产品设计及其相关过程包括制造过程和支持过程进行并行、一体化设计的一种系统化的工作模式。

       这种工作模式力图使开发者从设计一开始就考虑产品在生 ... [/quote]

你不如再抽象一点说一切都是从哲学来的。就算这几个实践牵强附会能够从管理学理论而来，这又能说明什么？说明这些实践实际上不可行？还是说明这些实践不如根据非软件工程理论自创的实践？

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 00:35 发表

呆板是指它只能知其然,而不知所以然,而管理学是能知所以然,这样才不会生搬硬套,软工实践最大问题恰恰是生搬硬套.
软工的确有关注人的心理,但还是不知所以然
比如说知觉的选择性,注意的浮动,性格的影响,还有 ... [/quote]
那请问你了解了“知觉的选择性,注意的浮动,性格的影响”的所以然之后对软件项目开发实践产生了哪些影响？产生的这些影响对生产率的提高是否超过了或者有潜力超过现有软件工程方法对软件项目生产率的提高？

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 00:38 发表




你不如再抽象一点说一切都是从哲学来的。就算这几个实践牵强附会能够从管理学理论而来，这又能说明什么？说明这些实践实际上不可行？还是说明这些实践不如根据非软件工程理论自创的实践？ [/quote]
就说预防为主,软工提倡这么多测试,为什么不从预防下功夫,生产管理学甚至提倡产品免检,而到软工里变成测试与设计并重
还有并行工程讲究价值分析,一个个分析是否创造价值,没有的舍掉,甚至还有通过排序来提高效率,软工有这么细致分析吗

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 00:51 发表

那请问你了解了“知觉的选择性,注意的浮动,性格的影响”的所以然之后对软件项目开发实践产生了哪些影响？产生的这些影响对生产率的提高是否超过了或者有潜力超过现有软件工程方法对软件项目生产率的提高？ [/quote]
比如为什么长时间劳动以后生产率下降就可以用注意的浮动解释,实践就要注重安排休息,或者安排提高注意力的项目
还有引发低级错误,就可以分析是语言的哪个特性引发的,然后可以通过改变编码习惯避免
知觉的选择性就影响学习和沟通,比如某些信息不容易引起注意,所以沟通时就需要强化

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 00:52 发表

就说预防为主,软工提倡这么多测试,为什么不从预防下功夫,生产管理学甚至提倡产品免检,而到软工里变成测试与设计并重
还有并行工程讲究价值分析,一个个分析是否创造价值,没有的舍掉,甚至还有通过排序来提高效率,软工有这么细致分析吗 [/quote]
那请问你在心理学和人力资源管理的指导下，会采用何种方法来做到预防为主并且有效减少测试的？
软件工程中哪种方法不是分析需求并优先实现最有价值的需求的？进一步说有哪一门神经正常的学科不是这么做事的？这可不是管理学中独有的。

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 01:00 发表

比如为什么长时间劳动以后生产率下降就可以用注意的浮动解释,实践就要注重安排休息,或者安排提高注意力的项目
还有引发低级错误,就可以分析是语言的哪个特性引发的,然后可以通过改变编码习惯避免
知觉的选择性就影响学习和沟通,比如某些信息不容易引起注意,所以沟通时就需要强化[/quote]
你这还是理论啊，怎么算注重安排休息？几个小时休息一次？一次多久？哪些是提高注意力的项目？如何在实践中避免低级错误重复出现？哪些信息是不容易引起注意的？如何强化？
你这不过还是在强调“理论要与实践结合”而已吗？要想有说服力就要说明在实践中如何如何做，该做法是XXX学中的理论而软件工程中是没有的，应用该做法之后比在软件工程指导下的实践在YYY方面有优势。要想空口证明软件工程比XXX学更有效也是容易得很。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 01:02 发表

那请问你在心理学和人力资源管理的指导下，会采用何种方法来做到预防为主并且有效减少测试的？
软件工程中哪种方法不是分析需求并优先实现最有价值的需求的？进一步说有哪一门神经正常的学科不是这么做事的？ ... [/quote]
做到预防为主就不是纯心理学和人力资源管理问题了,跟计算机技术关系很密切,心理学所能解决的是把握人的思维规律,真正做到预防为主靠的是系统设计阶段把问题分析清,生产管理学毕竟对象范围广,只是说到往免检方向努力
软工的需求分析,系统分析,系统设计那堆工序,真的审视过存在的价值吗

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 01:13 发表

你这还是理论啊，怎么算注重安排休息？几个小时休息一次？一次多久？哪些是提高注意力的项目？如何在实践中避免低级错误重复出现？哪些信息是不容易引起注意的？如何强化？
你这不过还是在强调“理论要与实践 ... [/quote]
只是说明对实践有影响,如果要系统的实施,那得有计算机方面的知识,我说的心理学这些都是在有计算机方面的知识基础上才能落到实处

其实我前面说过一点,就是培养人的问题,首先要了解每个成员知识结构,性格,了解知识结构就需要懂计算机方面的知识,然后看是否有欠缺,是否需要补,而不是软工里搞制度完事,那人家代码写不出怎么办?我想软工也拿不出办法

[color=Silver][[i] 本帖最后由 陈珺 于 2010-5-25 01:30 编辑 [/i]][/color]

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 01:16 发表

做到预防为主就不是纯心理学和人力资源管理问题了,跟计算机技术关系很密切,心理学所能解决的是把握人的思维规律,真正做到预防为主靠的是系统设计阶段把问题分析清,生产管理学毕竟对象范围广,只是说到往免检方 ... [/quote]

那么心理学和人力资源管理对软件开发的具体指导在什么地方？指导系统设计阶段的又是什么理论？

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 01:23 发表

只是说明对实践有影响,如果要系统的实施,那得有计算机方面的知识,我说的心理学这些都是在有计算机方面的知识基础上才能落到实处 [/quote]
那么对实践的影响又在何处？这些影响与单纯应用软件工程产生了哪些差别？

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 01:24 发表


那么心理学和人力资源管理对软件开发的具体指导在什么地方？指导系统设计阶段的又是什么理论？ [/quote]
就说分工问题吧,有的人擅长算法,有的人擅长优化,这些需要计算机知识的参与
有的人认真,有的人三心二意,有的人喜欢广度,有的人喜欢深度,这些需要心理学的参与
然后以此安排任务,缺人时按心理学规律培养,出错时按心理学规律找原因
如果要再细下去,就得拿具体项目说了

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 01:30 发表

那么对实践的影响又在何处？这些影响与单纯应用软件工程产生了哪些差别？ [/quote]
最大的差别,就是不会那么呆板,可以根据具体项目和组织情况设计流程,安排人事,而不像软工那么死的需求分析,概要设计等等,还有就是通过沟通发现知识欠缺,及时弥补,注重开发成员的思维规律,而不是靠一堆规章制度,非要测试驱动,测试集成,可以根据开发成员的言语和代码分析出现问题的本质原因

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 01:37 发表

就说分工问题吧,有的人擅长算法,有的人擅长优化,这些需要计算机知识的参与
有的人认真,有的人三心二意,有的人喜欢广度,有的人喜欢深度,这些需要心理学的参与
然后以此安排任务,缺人时按心理学规律培养,出错 ... [/quote]

软件工程中不讲分工问题吗？软件工程中对资源的调配还包括了更广泛的内容，恐怕是心理学覆盖不到的吧？软件工程所覆盖的内容是远超你想象的，即使你能够从管理学、心理学、人力资源管理等等学科中总结出一些指导实践的方法，那也不过是重新发明了一个原始的轮子而已。只有站在前人的基础上才能真正有所创造。


[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 01:46 发表

最大的差别,就是不会那么呆板,可以根据具体项目和组织情况设计流程,安排人事,而不像软工那么死的需求分析,概要设计等等,还有就是通过沟通发现知识欠缺,及时弥补,注重开发成员的思维规律,而不是靠一堆规章制度 ... [/quote]
呆板的是人不是软件工程。你灵活一个先概要设计后需求分析看看？不靠规章制度是管理学教你的？你能说出不靠规章制度来可见你的管理学还得重修。

[color=Silver][[i] 本帖最后由 Maxwell 于 2010-5-25 01:56 编辑 [/i]][/color]

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 01:50 发表


软件工程中不讲分工问题吗？软件工程中对资源的调配还包括了更广泛的内容，恐怕是心理学覆盖不到的吧？软件工程所覆盖的内容是远超你想象的，即使你能够从管理学、心理学、人力资源管理等等学科中总结出一些 ... [/quote]
你说什么内容