您的位置:首页 > 其它

一个小型的项目团队,怎么组合更好一些

2009-04-06 07:45 330 查看
项目团队=主程(检设计)+辅程+文档员(检服务)+测试(检版本管理) 这样组合,怎么样?
主程一人,文档员(检服务)一人,测试(检版本管理)一人,辅程至少一人。

* 那要看有多少人了,人少了啥都得干

* 很多小公司都是这样,什么都做,那样不是很高效的。

*呵呵 团队 太小 人就要万能的

*4个人的话,这样比较合理。

* 人员控制10个之内,这样吧8-10人。怎么做成本最少?

*你的说法比较古典,比较理想。
一般而言,小的话,管理1(很多时候由SE兼职) + SE1(设计) + 1~2PG(编码) + 1~ 2测试(QA)。
软件开发这个行当,不说要全能,但你至少要“铁人”三项
能设计(需求,GUI,系统),能写码(日写千行,下笔无虫),能加班(披星戴月)。。。

* 小团队,还是小公司呢?
我觉得文档和版本管理应该是可以由公司统一进行的吧,有必要给这么mini的团队一个专门的人做吗?

不论如何,项目里面应该有一个负责需求和进度管理的人吧。我倒是觉得两个dev,一个偏重需求和管理,一个偏重架构和设计,另外再找一个test,这样比较好。

* 一般而言,小的话,管理1(很多时候由SE兼职) + SE1(设计) + 1~2PG(编码) + 1~ 2测试(QA)。
软件开发这个行当,不说要全能,但你至少要“铁人”三项
能设计(需求,GUI,系统),能写码(日写千行,下笔无虫),能加班(披星戴月)。。。
it精英的写照

* 我觉得文档和版本管理应该是可以由公司统一进行的吧,有必要给这么mini的团队一个专门的人做吗?

不论如何,项目里面应该有一个负责需求和进度管
这样理解:
测试人,知道什么情况可以用了,他可以打包发版。
服务人员知道客户怎么理解,可以组织文档。
偏重需求和管理的应是产品经理或项目经理,
偏重架构和设计的是架构师,这个公司的话,我认为有一人就行,团队可以没有。

* 难道能测试和能调试不算是一条吗?

*如何理解小型项目团队

是小项目?还是小团队?小项目如何定义(小于?人月)?小团队如何定义(小于?人)
小项目可以用大团队来开发, 小团队也可以开发大项目

*小公司都以项目为单位了,像测试、架构师等等,估计没有专门这样的职位。虽然可以多个项目共用。

* 看是什么样的项目吧。有的项目对文档的要求很低的,完全不需要专门的文档人员。开发人员和测试的人员比例2:1合适一些

*能者多劳
大家看的到谁出力多!

* 10人的团队

1 架构师
1 DBA
1 UI + 网页
2 系统分析员(兼高级程序员)
2 高级程序元
2 程序员员
1 项目经理

然后分成3个小队
1 架构师 + DBA + UI 决定项目的核心
2 team A 系统分析员 + 1个高级程序员 + 1 个程序员
3 team B 系统分析员 + 1个高级程序员 + 1 个程序员

team A 和B 互为对方的测试人员。

项目经理负责统筹3个小组。并且项目经理身兼多职。做质量控制和协调

* 如果是太小的团队,我就不会这么细的分工了。
一般分完模块,我会安排每两个人负责相同的模块,二者实际上是共同开发的关系,看起来效率低,但是RD的白盒测试效果非常好。
当然一个系统分析员必不可少,不过我在担任这个角色的时候,喜欢开会。
我们的规定,两个人在一起沟通,就叫开会,每次开会,一定要有结果,两个人拿不出结果的,就加人进来讨论,总之讨论出结果为止。每次会议,一定要有记录,程序的注释上,要体现出来,==
嗯,我们做传输的,分布式程序比较多,我们还玩过角色扮演的游戏,就是每个人站在自己负责的模块的角度演戏,大家站到讲台上,谁开始说,我这边输入了什么数据,经过什么处理,哪些细节,然后给谁,下一个人接着说。。。
这样效果极好,前期开会很多人没有认真听,或者弄不清楚的,这么一演练,大家负责什么模块,功能如何,需要用到什么关键算法,为什么这样用,上家是谁,下家是谁,大家如何交互,通过游戏就弄明白了。
呵呵。大家有兴趣,可以玩玩。

* 一般分完模块,我会安排每两个人负责相同的模块,二者实际上是共同开发的关系,看起来效率低,但是RD的白盒测试效果非常好。

长见识了。高。

* 一般分完模块,我会安排每两个人负责相同的模块,二者实际上是共同开发的关系,看起来效率低,但是RD的白盒测试效果非常好。
两个人在一起沟通,有点像结对编程。
通过游戏的确是不小创新。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: