今天例会提了个建议：就是将单个小模块分配到每个人，当然不是像涉及的面比较宽的那种功能或者涉及到系统架构的东西，其实我提这样的想法是有原因的。但是老大们反对这么做。我的理由很简单：
1、可能对于大的公司或者一个比较成熟的项目这么做是不合适，但是对于小的团队或者是处在十分尴尬位置的项目来说，我觉得是可行的。
2、影响开发进度或者失败的原因通常可以总结为：（1）需求变更，（2）计划不具体管理较混乱，（3）开发人员不努力或者技术不过关。（4）人员不够（5）对一个项目或者产品的长远不是很明确。
3、其中大家说的一个理由是“一个人做某个功能如果该人员离职那么维护起来风险太大”，不能说没有道理，但是我觉得系统维护的难易不是人员的问题，项目中的人员变动是不可避免的，如何减少人员流动姑且不论。一个好的或者清晰的架构以及清晰的文档只要做好交接工作，维护起来比一个不好的架构要省很多的力量，如果架构不好即使谁维护可能选择的都是重构。记得当初我写某管理模块的时候，那时刚毕业，技术很有限，代码结构太差，最后只好花了很多时间重构了一把。 针对这个问题的另一面那就是人员离职。其实开发人员离职可能有几个方面的原因：1经济 2环境 3成就感 4提升空间。我觉得开发人员在同等经济利益的情况下对于后2者的关注要大于前面2方面。在一个项目中头们分配了任务，开发人员肯定被动接收任务，这时如果连一个小的功能点自己的想法都无法很好实现的时候，很明显他会感到挫败感。这个时候就是人心思走的时候。相反如果让某个人负责一个整体的小模块或者功能，并且很好的对其进行引导，使这个功能又能充实进来很多人的想法，就相当理想，这里面一个问题就是当遇到不是自己负责的模块的时候，其他人会以怎样的热情来投入呢？其实如果大家互相有所需求，那样就会尽心去帮助别人，因为同时也帮助了自己。
4、当开发一个功能时，其实不可避免的会遇到一些难题，某些难题可能一会就解决了，某些难题可能要很久才能解决，那么其实有可能存在一个空闲因为当你发现一个难题时，花了2天还弄不出来，通常的做法是先放放，然后再寻求解决。或者在同步开发一个功能时，你的模块已经完成了，但是别人做的还没完成，这时不可避免有个空档，如果没活干，那么这个时间就浪费了。可能老大觉得这个时候你应该主动去干一些事情，但是人都是有惰性的，假设没有个明确的任务或者目标，针对开发人员来说就不知道下一步该干啥了，就是知道有新的功能需要做，如果没分配任务，试想我觉得开发人员的第一反应是即使我看了相关技术会让我做这里的功能吗？这就是管理的问题。如果能让一个开发人员同时做2件事 说不定我觉得都能在头们预期的时间内给完成了。否则到了deadline 那就等着延期吧。
乱其8遭的写点，仅表示当时的想法，可能不成熟，等过段时间再来检测。
【软件工程|小团队的开发心得】Powered by ScribeFire.
推荐阅读
- 管理
- C#|LeetCode——160. 相交链表
- 软件工程|UTM（流量统计和分析基础）
- 软件工程|四叶草团队介绍
- 如何招到一个靠谱的程序员
- 八皇后问题（递归回溯）
- 软件工程/项目管理|UML中的用例(Use Case)概念分析及StarUML实例
- 程序员|软件研发的 QSS 悖论
- 软件工程--沃尔沃物流信息系统tp5实现源码