1,265
社区成员
发帖
与我相关
我的任务
分享开发人员的配置问题……
在线性开发模式下，可以运用如下的方法来配置开发人员：
1、项目伊始，从开发组中选出几名系统分析员，负责系统的概要设计，从测试组抽出几名高级测试人员，负责概要设计的测试和评估。
2、详细设计阶段，前期的系统分析员按模块分为项目小组，每个系统分析员负责一个模块。从开发组中选出高级程序员，加入到项目小组中。高级测试人员也带领中级测试人员，对详细设计进行评估和测试。
3、编码阶段，再加入程序员和普通测试人员，完成编码和测试。
但是，当采用迭代的开发模式，如果对每个迭代采用如此的人员配置模式，则会在信息交流上浪费大量的时间。而如果所有人员一直跟进的话，又会产生大量的空闲时间。
大家的公司在这方面都是怎么做的呢？
1、项目伊始，从开发组中选出几名系统分析员，负责系统的概要设计，从测试组抽出几名高级测试人员，负责概要设计的测试和评估。
2、详细设计阶段，前期的系统分析员按模块分为项目小组，每个系统分析员负责一个模块。从开发组中选出高级程序员，加入到项目小组中。高级测试人员也带领中级测试人员，对详细设计进行评估和测试。
3、编码阶段，再加入程序员和普通测试人员，完成编码和测试。
但是，当采用迭代的开发模式，如果对每个迭代采用如此的人员配置模式，则会在信息交流上浪费大量的时间。而如果所有人员一直跟进的话，又会产生大量的空闲时间。
大家的公司在这方面都是怎么做的呢？
...全文
请发表友善的回复…
发表回复
zhf_karen 2002-09-11
- 打赏
- 举报
:)你说的是一个问题,但实际上,我们的方法中不存在很多这样的问题,因为如果在项目进行到1/3的时间的时候,开发人员可以切入到项目中去的时候,你的设计就在不段出现,所以不会出现代码人员长期休闲的状态.如果说要精确到日的工作计划,或者要充分利用所有每一个小时,这需要你从"项目计划入手".你说的问题,实际上是项目计划的问题,或者说你们公司技术部门人力配置问题,不是某一种项目管理方式的问题.
关于项目人力资源配置的书呢,我看过一些,但大多是一种经验之谈,我也没有看过什么理论性的工作.实际上这一块你可以通过项目跟踪工具看出来,你可以根据这些反馈资料来调节人员的配置.
关于项目人力资源配置的书呢,我看过一些,但大多是一种经验之谈,我也没有看过什么理论性的工作.实际上这一块你可以通过项目跟踪工具看出来,你可以根据这些反馈资料来调节人员的配置.
mis98ZB 2002-09-11
- 打赏
- 举报
谢谢zhf_karen(zhf)的指点。
想来时间碎片这个问题是无法避免的，
特别是在因为创新而无法作出准确预计的时候……
少少分数，不成敬意。
想来时间碎片这个问题是无法避免的，
特别是在因为创新而无法作出准确预计的时候……
少少分数，不成敬意。
mis98ZB 2002-09-10
- 打赏
- 举报
谢谢zhf_karen(zhf)的指点。
你的意思是这样么：
在初始阶段由少量骨干人员参与项目，细化阶段追加少量人力。到构造阶段，每次迭代都是所有人员全员跟进。移交阶段保留少量人员留守。
可是有这种情况：细化阶段和构造阶段难以分割。详细设计的某些部分（通常是一些创新的、没有经验的部分），不构造出实体就无法检验其有效性。这样，要么设计人员心急如焚的等待编码人员出结果；要么设计人员拼命赶设计，而编码人员无所事事，喝茶、上网、聊天。（我现在就在拼命赶设计，我旁边的哥们儿就正QQ得眉开眼笑…… ∶（）
这种情况应该如何缓解呢？
你的意思是这样么：
在初始阶段由少量骨干人员参与项目，细化阶段追加少量人力。到构造阶段，每次迭代都是所有人员全员跟进。移交阶段保留少量人员留守。
可是有这种情况：细化阶段和构造阶段难以分割。详细设计的某些部分（通常是一些创新的、没有经验的部分），不构造出实体就无法检验其有效性。这样，要么设计人员心急如焚的等待编码人员出结果；要么设计人员拼命赶设计，而编码人员无所事事，喝茶、上网、聊天。（我现在就在拼命赶设计，我旁边的哥们儿就正QQ得眉开眼笑…… ∶（）
这种情况应该如何缓解呢？
zhf_karen 2002-09-10
- 打赏
- 举报
先期,项目经理,架构工程师,需求工程师进入项目,了解需求,设计系统结构.
系统设计阶段:设计工程师,测试主管,子合同商进入,进行系统的接口设计,模块设计.
进行对关键模块的详细设计以后,编码人员进入,然后就是迭代开发了过程了.
这没有什么冲突,原来应该做的工作还是一样要做,只是由于一些工作并行操作了,时间上可以节省一些,而且把风险暴露出来,同时提高团队士气和提高领导层的信心而已.
系统设计阶段:设计工程师,测试主管,子合同商进入,进行系统的接口设计,模块设计.
进行对关键模块的详细设计以后,编码人员进入,然后就是迭代开发了过程了.
这没有什么冲突,原来应该做的工作还是一样要做,只是由于一些工作并行操作了,时间上可以节省一些,而且把风险暴露出来,同时提高团队士气和提高领导层的信心而已.
mis98ZB 2002-09-10
- 打赏
- 举报
是不是时间碎片是迭代开发的固有缺点呢？
就好像动态内存分配就一定会产生内存碎片一样（内部碎片/外部碎片）……
现在到处都是rup、xp，
不能合理的分配资源，还谈什么软件工程啊！
大家有没有知道那有关于项目人力资源配置的书啊？
请推荐一下，不胜感谢……
就好像动态内存分配就一定会产生内存碎片一样（内部碎片/外部碎片）……
现在到处都是rup、xp，
不能合理的分配资源，还谈什么软件工程啊！
大家有没有知道那有关于项目人力资源配置的书啊？
请推荐一下，不胜感谢……
mis98ZB 2002-09-10
- 打赏
- 举报
感谢大家的回答。
可是多个项目的话也不好控制啊。
比如A项目的分析员出现了一周左右空闲，而B项目正由于设计滞后而吃紧，那么，你愿意让A项目的分析员去B项目辅助么？
且不说一周时间不够A项目的分析员熟悉B项目，单是由于与A项目的分析员的交流就会拖垮B项目的日程表……
如果精明能干的A项目的分析员在短短一周以内作出了几个模块的设计，那么，在这周结束以后，A项目的分析员返回A项目之后，谁来指导编码人员完成这几个模块呢？靠厚厚的设计文档么？编码人员完全理解文档又要花多少时间呀。进入下一次迭代的时候，谁来改进这些模块呢？看完文档的编码人员么？
编码人员也是一样，到另一个项目组写了一个星期的代码，然后走人，出了bug谁来维护？下次迭代谁来改进？难道要让本来就任务吃紧的程序员来一行一行读代码、读注释么？
可是多个项目的话也不好控制啊。
比如A项目的分析员出现了一周左右空闲，而B项目正由于设计滞后而吃紧，那么，你愿意让A项目的分析员去B项目辅助么？
且不说一周时间不够A项目的分析员熟悉B项目，单是由于与A项目的分析员的交流就会拖垮B项目的日程表……
如果精明能干的A项目的分析员在短短一周以内作出了几个模块的设计，那么，在这周结束以后，A项目的分析员返回A项目之后，谁来指导编码人员完成这几个模块呢？靠厚厚的设计文档么？编码人员完全理解文档又要花多少时间呀。进入下一次迭代的时候，谁来改进这些模块呢？看完文档的编码人员么？
编码人员也是一样，到另一个项目组写了一个星期的代码，然后走人，出了bug谁来维护？下次迭代谁来改进？难道要让本来就任务吃紧的程序员来一行一行读代码、读注释么？
zhf_karen 2002-09-10
- 打赏
- 举报
恩,是这样的,一个项目的化的确是这样的,因为不能因为不想让这些人动起来而让他们一起参与进来项目,这往往没有什么好结果,因为有时候人多也坏事详细设计的那一部分需要出详细代码的,应该在设计之初就有一个结论性的意见出来,这如果安排得好一些,应该是不会出现大家在互相等待的情况(当然,这说来容易,做起来难,我自己有时候也这样,不过出现问题以后就该问问自己,为什么会这样,是否还有更好的时机解决这个问题,也许能发现一些问题)
zxl_l 2002-09-10
- 打赏
- 举报
若你们公司有多个项目,就可以进行工作量最优化,不然每个阶段的工作重点不同,当然有忙有邂.
