Chapter 5 团队和流程

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Chapter 5 团队和流程相关的知识,希望对你有一定的参考价值。

Chapter 5 团队和流程

一、非团队和团队

     1.非团队:只是一群乌合之众,临时聚集在一起。

     2.团队:①有一致的目标。

                ②成员不一定要同时工作。(如接力跑)

                ③成员有各自的分工,互相依赖合作,共同完成任务。一个人的工作对另一个人有影响。

二、软件团队的模式

     适用于不同的人员和需求的团队的各种形式

     1.一蜂窝模式:(比较混乱

        就是大家一哄而上去抢。可能是一个欢乐而随意的模式。

     2.主治医生模式:(1主多从

        有一个主刀的人,还有其他帮助他的人。

        也就是有一个首席程序员负责主要模块的设计和编码,其他人从各种角度支持他的工作(后备程序员、系统管理者、工具开发、编程语言专家、业务专家)

     3.明星模式:(是主治医生模式的升级版,就是明星能有团队意识

        明星的光芒盖过了团队其他人的总和。

        *明星也是人,也会有错误,如何让团队的利益最大化,而不是明星的利益最大化,如何让团队的价值在明星陨落之后仍然能保持?

        真正有巨大成就的明星都能意识到团队的作用。

        说实话,不是很明白主治医生模式和明星模式的区别?

      4.社区模式:(人多,分工合作,保证质量,不随意

         社区由很多志愿者组成,每个人参与自己感兴趣的项目,贡献力量,大部分人不拿报酬。

         好处:众人拾柴火焰高,但是也要每个人均匀的分工合作,并且提高质量。

         并不意味着“随意”。

      5.业余剧团模式:(每次每个人的角色不同,有导演

         在每一个不同的项目中,每个人挑选的角色也不同。

         且每个人在团队中听从一个中央指挥(导演)的指导和安排。

      6.秘密团队:(神秘

         项目在秘密状态下进行,别人不知道他们具体在做什么。

         好处:团队内部有极大的自由,较高的热情,没有外界的干扰(不用每周给别人介绍项目进展,听领导的最新指示等)。

      7.特工团队:(有特殊技能的专业人士

         由一些有特殊技能的专业人士组成,负责解决一些棘手而又紧迫的问题。

         现在还包括专门做网站安全性服务的团队。

      8.交响乐模式:(种类多,统一,执行力强

         家伙多,种类丰富。

         各司其职。

         有统一的套路(谱子),同时看指挥。

         曲子练习了多次,重在执行。

      9.爵士乐模式:(个性化,互动,创意)  

         同交响乐模式似乎有些相对。

         没有统一的谱子。

         没有现场指挥。

         即兴发挥。

         强调个性化的表达,强有力的互动,对变化的内容有创意的回应。

     10.功能团队模式:(能力不同,平等,交流频繁

         具备不同能力的同事们平等协作。

         在一个功能完成后又重新组合,和别的角色一起去完成下一个功能。

         没有管理和被管理的关系。

         小组内的交流比较频繁。

     11.官僚模式:(领导和被领导

          几个人报告给一个小头目,几个小头目报告给中头目,依次而上。

          成员之间不光有技术方面的合作和领导。

          组织上有领导和被领导的关系。

          跨组织的合作变得比较困难,因为各自头顶上都有不同的老板。

三、开发流程

    一群人一起做软件开发的方式方法。

     1.写了再改模式:(适用于小场面的一些程序

       就是不管三七二十一,先写了再说,如果有问题就再改动不断的进行修改。

       好处:不需要太多其他准备或相关知识,大家上来就写代码,也许就能写出来,写不出来就改,也许能改好。

       eg.只用一次的程序,看过就扔的程序,一些不实用的程序。

       坏处:在要写到比较有实际用户、解决实际需求的软件时就不适用了。

     2.瀑布模型:(单向、不可逆

        硬件行业中:产品一般遵循:【分析->设计->实现(制造)->销售->维护】的流程。

                         且一旦大规模生产,要再返回去修改时就非常困难,甚至是不可能的。

        在设计大型系统时,要做相邻步骤的回溯,解决上一阶段未能解决的问题。

        要让产品成功,最好把这个模型走两边,先有一个模拟版本,在此基础上收集反馈,改进各个步骤,并交付一个最终的版本。

        用户的及早介入、讨论、复审是很重要的。要让顾客正式的、深入的、持续的参与到项目中来。

        软件行业中的局限性:

        ①各步骤之间是分离的,但是软件生产过程中的各个步骤不能这样严格分离出来。

        ②回溯修改很困难甚至不可能,但是软件生产的过程需要时时回溯。

        ③最终产品直到最后才出现。但是软件的客户,甚至软件工程师本人都需要尽早知道产品的原型并试用。

        适用范围:

        ①产品的正确性非常重要,需要每一步的验证

        ②产品模块之间的接口、输入和输出能很好的用形式化的方法定义和验证。

        ③使用的技术非常成熟,团队成员都很熟悉这些技术。

        ④负责各个步骤的子团队分属不同的机构,或在不同的的地理位置,不可能做到频繁的交流

      3.瀑布模型的各种变形:

         1)生鱼片模型(各相邻模块像生鱼片那样部分重叠):

              解决了各个步骤之间分离的缺点,但也有问题:上一个阶段什么时候结束的?

         2)大瀑布带着小瀑布(步步嵌套):

              解决不同子系统之间进度不一,技术要求迥异,需要区别对待的问题。

              要把各个子系统统一到最后做系统测试,用户只有到了最后才能看到结果。

       4.统一流程(RUP):

         从瀑布模型开始的各种模型都有一个共同点:重计划,重事先设计,重文档表达。

         团队的各种成员要在不同阶段做不同的事情,这些不同类型的工作在RUP中叫做规程或工作流

         包括:业务建模。

                 需求。

                 分析和设计。

                 实现。

                 测试。

                 部署。

                 配置和变更管理。

                 项目管理。

                 环境。

        RUP四个阶段:

        ①初始阶段。分析软件系统大概的构成。(开始阶段)

        ②细化阶段。分析问题领域,建立健全的体系结构基础,编制项目计划,按优先级处理项目中的风险。(具体的去做)

        ③构造阶段。开发出所有的功能集,把功能集成为经过各种测试验证过的产品。什么是功能集???

        ④交付阶段。确保软件能满足最终用户的实际需求

      5.老板驱动的流程:( 由行政领导主导或是公司老板驱动。)

        原因:老板的能力决定了一个团队是否能获得订单。

                在大型企业内部,软件功能往往由行政体系来决定。

                有些老板比一般人更懂市场和竞争。

                软件团队尚未成熟。

       缺点:领导对很多技术细节是外行。

                领导未必懂得软件项目的管理很有可能太过权威性。

                领导管理是行政命令。

                领导精力有限。

      6.渐进交付的流程:(开发->发布->听取反馈->根据反馈做改进)不断的循环

         (直到)软件最后完成: 时间到了,钱花光了,用户满意了(或是不满意不继续给钱)。

         但有问题是:产品团队得到用户的反馈太晚了。

         MVP(最小可行产品,最小功能集):

         把产品最核心的功能用最小的成本实现出来,然后快速征求用户的意见。

         指导思想与渐进交付相似,但是更强调更早获得用户反馈,为此可以在产品完成之前就发布,

                                           也强调产品的核心价值,为了突出核心功能,不考虑辅助功能。    

         MBP(最强最美产品):

         对用户的需求了然于心,或者产品团队比用户更了解用户的需求。

     7.TSP(Team Software Process)的原则:

        ①流程中的每一步都是可以重复、可以衡量结果的。

        ②各个成员对团队的目标,角色,产品都有统一的理解。

        ③尽量使用成熟的技术和做法

        ④尽量多的收集数据

        ⑤指定切实的计划和承诺。计划要由具体执行的角色来制定。

        ⑥增加团队的自我管理能力

        ⑦专注于提高质量

 

 

 

 

 

         

   

 

以上是关于Chapter 5 团队和流程的主要内容,如果未能解决你的问题,请参考以下文章

Chapter 6 敏捷流程

软件开发者路线图梗概&书摘chapter4

Chapter4_控制执行流程

菜鸟笔记 -- Chapter 3.5 人生的第一个Java程序Hello World

《Linux内核设计与实现》Chapter 5 读书笔记

Chapter 5 查找