一般是还要让你们进行敏捷开发，每两周提交一个软件新版本的那种，是不是？哈哈
如果是学校项目 5 人小组并且要求几个版本程序（迭代），那么对于第一版程序，就 1 个人出方案，4 个人审核方案提出小改意见，看没啥大问题了之后就按这个方案走
就第一版程序的设计和实现而言：
0 团队合作（把任务分给成员、成员写完、试图整合、整合失败不知道哪错了）会让第一版程序难产
1 个人行动比团队行动更快，尤其当团队里的人都是菜鸟的时候，别人自己都写完了你还在帮菜鸟 debug 还不如直接重写更快，队友就添乱，导致第一版程序难产
2 对于第一版程序，主要是定下来谁收拾烂摊子
3 在第一版程序出问题之后由提方案的那个人（作为主程）主动收拾烂摊子：甚至把第一版程序推翻重做
对于学校项目 5 人小组，一般只有 1 或 2 个人会非常 carry 。对于第一版程序，到最后基本上就是他或他们自己（作为主程）直接把第一版程序全搞定了，其他人在第三版或第四版程序的时候才开始插手。实际工作中也是 项目早期都是一个人设计并实现的。
对于第一版程序，主要责任就在主程一人，团队成员只有在集思广益 or 提一些小意见 的阶段 还有点儿用。
对于后续几版程序，可以逐渐安排每个人都在做什么。即使出现了烂摊子，鉴于第一版程序足够坚实，前几版程序足够坚实，那么新一版程序出问题可以很快扫尾，大不了就是退回到前一个 version 重做嘛。
-
-
实际工作中，一是主程操刀第一版程序，菜鸟不会碰也不敢碰，也不能让碰，通常都不会让插手；二是对于第一版程序 如果主程无法对第一版程度负责，那么直接被开掉 换人 因为一个无法承担责任的人是不能主导第一版程序的，人不行；三是对于第 n 版程序，定责定得比较好，菜鸟级开发者只会被分配到菜鸟级开发任务，若菜鸟级开发者出问题了（很可能发生！）会被边缘化，同时鉴于之前对于项目风险和人员风险的预判，即使项目被菜鸟糟蹋了 项目本身不会出现致命伤；四是致命伤只可能发生在第一版程序里，因未考虑到项目整体复杂度而产生致命伤而不得不推翻重做的情况是很常见的。 参考
http://www.uml.org.cn/xmgl/201110132.asp 风险控制主要是在第一版程序里。在第一版程序出炉之后，其他人在主程的指导下工作开发出第 n 版程序。
-
（但是对于一个从零开始的项目而言，如果你是主程，那么通常是要做好一个人全包的准备，为什么呢？因为同学们往往是非常幼稚的，他们认为 第一版程序就应该已经完成全部功能的 80% 以上的功能都已经实现了，就像他们经常玩的 SDK 一样 所有东西都是现成的 他们只要 call 什么函数 就 OK 了，即使你想分模块开发 你也分不出来 ...
因为他们对软件开发的基本概念是没有的，比如 生命周期、线程阻塞，如果不知道这些那么程序是跑都跑不起来的
哈哈哈哈，他们真的只能被分配到菜鸟级开发任务，而这些任务往往在项目推进到第三版或第四版程序的时候才会出现。
-