探讨对理想团队模式构建的设想及对软件流程的理解

读《构建之法》有感：

第五章有以下几种软件团队模式，比较各自的优缺点：

一窝蜂模式：一种较为随意的模式，没有什么可遵循的规律，存活时间不长，但气氛较为随意轻松。

主治医生模式：“一个人干活，其他人打酱油。”我觉得，这种模式会造成效率低下，无法“物尽其用”。

明星模式：主治医生模式的极端化，首先，其实我并不是很清楚书中的描述，所以并没能够很好的理解，但我想来这种团队模式应该最后是演变成了一个人的独场秀，其他人反而在项目中已经占据不了什么了？（个人理解）

社区模式：这个模式中成员的目标是不统一的。各人为了各人的目标，有兴趣使然，有利益驱使，这样的项目往往需要很严格的代码复审和签入的质量控制。

业余剧团模式：团队中各人扮演各人的角色，我觉得一般情况而言，这是个很不错的团队模式，有助于各人的交流分享，平等的讨论。然而当这个模式在一个竞争相当激烈。创造性要求十分高的环境中时，往往会带来一些不完美气氛。

秘密团队：这是一个有着很大自由度和独立使命的团队模式，是我认为很理想的团队模式，不受外界干扰，驱动力大，往往能超高效率的完美完成不可能的任务。但我觉得这个团队模式毕竟不可能成为普遍模式，只会针对个别特殊的项目。

特工团队：这个模式听起来就很热血，就和字面上差不多，这个模式中的成员大多是有一些特殊技能专业人士，针对性解决相对棘手的问题，对成员的知识面要求十分广，较为针对技术人员。同样，我觉得这样的团队模式效率上是无可挑剔的，但很显然并不是一个很普遍的团队模式，对于一般的项目来说，用这样的模式显得大材小用了。

交响乐团模式：各司其职，比较“呆板”，重在执行。大多运用于稳定成长阶段的项目。我觉得这种模式还是很普遍的，没什么大特点。

爵士乐模式：与交响乐模式存在相当多的对立，我觉得就像是领导给出一个主题，然后成员们百花齐放，各显本领，快收尾时再总结。这种模式更加偏向于鼓励创新互动，人数反而不能太多，也是不广泛的一种模式。

官僚模式：是一种上司上面还有上司的模式，一般会分成几个小团队有各自的上司带领，原本这是一种很有利的模式，有助于技术的交替与互补，然而容易掺杂一些追名逐利，往往会使团队效率大打折扣。

所以以上总结对比看来，是交响乐模式较为普遍，用于部分软件稳定发展期，而针对一些创新软件时，秘密团队、特工团队以及爵士乐团队会带来更大的效率与惊喜。除此之外，一个团队的领导者也是十分重要的存在。

领导者是需要会管理却更要会领导的，要知人善任，带领一个团队的成长，让一个团队凝聚起来。

开发流程：

写了再改模式：非正式的一些软件，事先不需要做相关的功课，做完之后再根据要求修改。我觉得这是一种相当随意的模式，适用于一些不是很重要的软件工程项目（作业），并不适合大范围使用。

瀑布模式：遵循很缜密的流程，但是是单向、不可逆的过程，无法返回上一级进行修改。所以这个模式需要用户的密切参与。适用于一些定义稳定、正确性较高、需要步步验证、技术成熟并且各部分不许要过多交流的项目。

瀑布模式的变形：

生鱼片模式：各模块有重叠部分，但难以区分各模块的界限。

大瀑布带小瀑布：把系统分出几个子系统，各个子系统都需要进行测试，但十分耗费时间，从用户角度考虑是等不起的。

RUP：将各阶段整合在统一框架中，大尺度上看与瀑布模型相似，但每个阶段又与迭代模型有异曲同工之妙。

老板驱动流程：由行政体系指导，按照老板要求进行，对于不成熟的团队来说，是需要一个人来引导的，有些老板相对于技术人员更加熟悉市场竞争，当无法处理利益相关的项目时只能靠外力驱动了。

渐进交付流程：根据反馈不断进行改进。结束比较简单粗暴，时间到了或者用户满意（不满意）为止。