首页 > 代码库 > 《构建之法》---团队合作

《构建之法》---团队合作

之前学习了两人合作的要点,现在到团队合作了,到底团队合作和两人合作之间存在着怎样的密切关联,就让我们来看看吧。

一个团队,包含的人数至少是多余两个人的,不然就不会叫做团队了,但是团队也并不是只需要几个人就可以了,人数并不是决定是否是一个团队的重要因素。书中举的有关非团队的例子就很有趣且直观。很明显,并不是需要精通于各种技术的“人才”放在一起就行了,还要把这几个人的目标明确下来,这样才有了团队目标。一个团队的成员并不一定要同时工作。团队成员各有各的分工,互相依赖合作,共同完成任务。软件团队的模式书中举了挺多的。至于实际是怎样的我就不知道了,毕竟我没有经历过真正团队合作的事,作者是做过不少大项目的人,自然是逼我要懂的,相信他写的也有很高的可信度,接下来我们就来看看有哪些吧!

软件团队的模式,最初开始就是几个人互相集结在一起的,是混沌的一窝蜂模式,一群人开始写代码,希望写出好软件。随着团队的成熟和环境的变化,团队中的每个人互相磨合,慢慢地演变成了以下几种模式。首先是主治医生模式,看名字我们不难联想到这时候的团队并不是每个人都在工作的。主治医生模式运用到极点,可以蜕变为明星模式。明星的光芒盖过了其他人,那么其他人的原有水平就会发挥不出来,这就导致了团队的很大的损失甚至失败。而真正有巨大成就的明星都能意识到团队的作用。社区模式由很多志愿者参与,每个人参与自己感兴趣的项目,贡献力量,大部分人不拿报酬,这种模式有利有弊,做得好的应该是包含有很严格的代码复审和签入的质量控制。业余剧团模式中每个团队成员的角色不是固定的。秘密团队内部有极大的自由,在没有了外界的干扰的情况下团队成员有极大的投入。特工团队里有一些成员是有特殊技能的专业人士,他们负责解决一些棘手而有紧迫性的问题。交响乐团模式是在某个软件领域处于稳定成长阶段的时候采用的。这时候的团队每个成员的分工是很明确的且成员的水平不低,代码质量也不低。爵士乐模式人数较少,主题是现场直接决定后由团队成员自由发挥,最后再由架构师总结。很多软件公司的团队最后都演变成功能团队。这个团队的成员能力不同而共同来完成同一个项目。官僚模式脱胎于大机构的组织架构,感觉很想上级与下级的组织。

接下来就是开发流程了,写了再改模式,瀑布模型,瀑布模型的各种变形,Rational Unified Process 统一流程(RUP),老板驱动的流程(Boss-Driven Process)渐进交付的流程(Evolutionary Delivery),MVPMBP。这里我主要讲一下瀑布模型和RUP。瀑布模型中包括系统需求,软件需求,前期程序设计,分析,程序设计,编码,测试,运行这几个步骤,而这几个步骤里面还包含着六种文档,文档1--软件需求,文档2--前期设计,文档3--界面设计,文档4--最终设计,文档5--测试计划,文档6--运行说明。书中还描述了不少瀑布模型的相关内容,我就不多说了,。RUP中有规程(工作流),这是团队的各种成员要在不同阶段做不同的事情。业务建模,需求,分析和设计,实现,测试,部署,配置和变更管理,项目管理,环境。RUP包括四个阶段,初始阶段,细化阶段,构造阶段,交付阶段。这些名词的解释我觉得没必要说明了。

以上就是本周的学习内容了,下一章的内容是关于一系列价值观和方法论的集合---敏捷流程。

《构建之法》---团队合作