第五次随笔

看了第五章讲了很多软件团队模式

蜂窝模式：组内成员分工不明确，不专业。这种模式我认为像是娱乐，不像认真合作一件事，除非磨合出一个分工明确的团队的样子，要不然不会长久。

 

主治医师模式：组内有一个高技术成员，其他人给他打下手。这种模式我认为有高风险，虽然队伍中允许加入一些平庸的组员，但是团队对于“主治医师”的依赖非常强烈，一旦这个“主治医师”出了什么问题，整个团队就停止运转。

 

明星模式：主治医师模式的加强版，仅仅是“主治医师”加强。这个模式就像某些NBA球队一样，明星在，光芒在，一旦队伍中的明星有伤病，整个队伍就跌到谷底。

 

社区模式：社区是靠有兴趣的人，无偿、自愿地参加自己感兴趣的项目。我觉得这个模式的好处在于项目充满了未知性，可能有一些新鲜的元素加入，而且成本低廉，但是这个未知性是一把双刃剑，参差不齐的人去完成这个项目，可能会对导致项目的可读性差、项目不够强壮。

 

业余剧团模式：每个人可能会担任不同的角色，这一切由团队领导人决定。模式的优点是可以迅速填上团队的空白，但是缺点是不能做到“术业有专攻”，而且空白仅仅是能填上，不能填满。

 

秘密团队：秘密地开发一个项目。这么模式我不知道该怎么评价。

 

特工团队：就是让一个高能团队做指定的是，一般是处理一些棘手的问题。这个模式我觉得效率会非常高，但是成本会很大，而且并不是每个团队都能做到所有成员都是极专业型。

 

交响乐团模式：团队成员各司其职，团队有总指挥，团队经过多次演练，只需要几次完美执行。这种团队很稳定，分工明确，什么位置确认可以很准确的找到代替，而且成果质量很高；但是为了一个项目会花费所有成员的精力，适合专一的做一个项目。

 

爵士乐模式：队伍分工明确，由领导人指明方向，之后靠成员自由发挥，最后由领导人收尾。这种模式对于组内成员能力要求较高，但是成果会不拘一格，经常能让人眼前一亮。

 

功能团队模式：由不同功能的小组构成一个团队，去共同完成一个项目，项目完成后，团队自动解散成原来的小组，各自进行下一个项目。可以适应不同的项目，效率较高，但是对于一个软件的后期维护比较困难。

 

官僚模式：做一个项目得由组员逐级向上汇报到小老板，中老板，大老板的一个团队。这种模式我不太想作出评价。

 

还有几种开发模式，我将下周作出评价。