第五章 团队和流程
团队有一致的集体目标,团队要一起完成这目标。一个团队的成员不一定要同时工作,例如接力赛跑。
团队成员有各自的分工,互相依赖合作,共同完成任务。
软件团队有各种形式,适用于不同的人员和需求。基于直觉形成的团队模式未必是最合适的。软件团队的模式,最初是混沌的一窝蜂形式:一群人开始写代码,希望能写出好软件。随着团队的成熟和环境的变化。
团队模式会演变成下面几种模式之一。
1.主治医师模式:有首席程序员,他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作(后备程序员、系统管理员、工具开发、编程语言专家、业务专家)。
2.明星模式:让团队的利益达到最大化
3.社区模式:每个人参与自己感兴趣的项目,贡献力量,
4.业余剧团模式:这样的团队在每一个项目中,不同的人会挑选不同的角色。但都听从一个指挥的指导和安排。
5.秘密团队: 团队内部有极大的自由,没有外界的干扰,不用每周给别人介绍项目进展,听领导的最新指示,团队成员有极大的投入。
6.特工团队:软件行业的一些团队由一些有特殊技能的专业人士组成,负责解决一些棘手而有紧迫性的问题。
7.交响乐团模式:家伙多,门类齐全。 各司其职,各自有专门场地,做项目期间没有聊天、走动等现象,同时看指挥的,重在执行。
8.爵士乐模式:和上面的“交响乐团模式”在很多方面都对立,但不能简单地说孰优孰劣。
9.功能团队模式:具备不同能力的同事们平等协作,共同完成一个功能。
10.官僚模式:脱胎于大机构的组织架构,几个人报告给一个小头目,几个小头目报告给中头目,依次而上。跨组织的合作变得比较困难,因为各自头顶上都有不同的老板。
瀑布模型:(单向、不可逆)
硬件行业中:产品一般遵循:【分析->设计->实现(制造)->销售->维护】的流程。
且一旦大规模生产,要再返回去修改时就非常困难,甚至是不可能的。
在设计大型系统时,要做相邻步骤的回溯,解决上一阶段未能解决的问题。
要让产品成功,最好把这个模型走两边,先有一个模拟版本,在此基础上收集反馈,改进各个步骤,并交付一个最终的版本。
用户的及早介入、讨论、复审是很重要的。要让顾客正式的、深入的、持续的参与到项目中来。
软件行业中的局限性:
①各步骤之间是分离的,但是软件生产过程中的各个步骤不能这样严格分离出来。
②回溯修改很困难甚至不可能,但是软件生产的过程需要时时回溯。
③最终产品直到最后才出现。但是软件的客户,甚至软件工程师本人都需要尽早知道产品的原型并试用。
适用范围:
①产品的正确性非常重要,需要每一步的验证。
②产品模块之间的接口、输入和输出能很好的用形式化的方法定义和验证。
③使用的技术非常成熟,团队成员都很熟悉这些技术。
④负责各个步骤的子团队分属不同的机构,或在不同的的地理位置,不可能做到频繁的交流。