软件工程是一门年轻的科学，很多概念、方法，至今都在摸索之中。比如说，如何形成一支健康的、易于成功的软件团队，依然是那些顶级的秘密，即便是有过上百次成功经验的项目经理、团队管理者，依然会说这种成功的过程建立在团队当时情况之上的，是不可复制的。

　　到底为什么呢？

　　我们经常看到软件领域的两种比喻：很多老师、方法、软件组织的管理者都把做软件比作是盖楼房，要有人设计、制造，要有良好的接口，要易于维护，等等。唯有这样，才能工业化大规模生产。也有很多组织中的程序员把写程序比作写作文，要写代码，就要想写作文一样，避免打扰，专心致志，还要有灵感，才能才思泉涌。

　　我们要注意两个问题：一，这两类比喻有着行为学和方法论上的差别，是不能同时存在于一个团队中的；二，第一类说的是做软件，第二类说的是写程序。我相信，正是管理层和执行层概念的差别才是造成软件团队问题的根源。大家都在各说各话，怎么能统一步伐走向共同的目标呢？

　　做软件和写程序有区别吗？或者说，软件和程序有区别吗？

　　程序（program）是为实现特定目标或解决特定问题而用计算机语言编写的命令序列的集合。 软件是一系列按照特定顺序组织的计算机数据和指令的集合。（以上来自百度百科）说实话，我之前的概念来自于课堂，就是程序是小的、个人性质的玩意，而软件则是带有商业目的的一套产品；而看了百度百科，反倒好像两者一样了。

　　那如果两者一样，为什么会有差异如此大的两种方法呢？

　　那么就应该是看问题角度导致的差异了吧。管理层，作为现代经济体中的获益方，势必会想办法融入成熟的现代商业模式中，自然而然的把问题想成像是工业化大生产的模式，因为这样个人对于公司的影响就很小了，不可能出现一个普通的人事变动对公司造成大的影响。然而程序员作为决策的执行者，却时刻感受到工业化生产和编码过程方法论的不同，造成实际上的执行力低下。最明显的是我第一次实训的时候，虽然模块、功能都划分好了，让大家按部就班，但是结果很多人不能按时完成规定的任务，很多功能都堆到了最后。当然，这个问题最直接的原因是课业负担，但是我认为根本问题是想用工业化的方法来安排软件流程是必然不能顺利的。

　　那么完全按照写作文的方法呢？小峰做组长的时候我觉得就是这样的方法，但是也没成功。他的方法是规划了某个这个模块后，模块负责人要发挥自己的主观能动性，完全自觉自动的完成这个模块。虽然完全交由组员了，却使得控制力失去了。

　　由此我觉得这次实训我再次作为组长，方法要改一改。首先在大体上要自己规划，但是小块上边，除了接口外，剩下的要由他们自己实现。对于时间上边我要求每次任务都有时间的约束，每次耽误时间的交付都将扣除一定的分数直到及格线。一旦被扣到及格线，该名同学也就不必继续完成任务。他对于集体就不再负有责任了。交付的时候是有提交标准的，比如，要在测试用例里面编译通过（最基本要求），要有一定的质量。编译不过比没有交付好一些，不过少扣些分数而已。

　　总之，就是大体上，是个工业化分工合作的过程；在细节上，是个人比较自由的创作时间。或许这样可以打造一个比较成功的团队。