该帖子同步发自：(嗨呦的博客  访问该博客)

问题：
　　项目团队=主程（检设计)+辅程+文档员（检服务）+测试（检版本管理） 这样组合，怎么样？
　　主程一人，文档员（检服务）一人，测试（检版本管理）一人，辅程至少一人。

网友回答：

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

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

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

*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的白盒测试效果非常好。
两个人在一起沟通，有点像结对编程。
通过游戏的确是不小创新。