zoukankan      html  css  js  c++  java
  • 阅读笔记——《构建之法》4

    这篇阅读笔记主要讨论一下“团队和流程”的相关问题。

         周所周知,在如今的社会中,个人所能发挥的力量实在是太小了,在当今世界各个领域的任何一项工程中,都需要团队的配合来完成。因为现在的任何一项工程应该说都是非常复杂的,只凭个人的能力不能考虑到工程的所有方面,而且即使个人能够独自完成,但是花费的时间肯定比团队来的多,在强调效率的时代,个人单打独斗似乎不再适合。所以我们就要对团队格外进行分析和总结。

    首先我们要明白什么是团队:团队是一个集体,要有同一的目标,每个团队成员要有自己的分工,要相互依赖去完成某一件事。例如球队和搬砖团队的区别。在明确团队的基础上,我们再来讨论一个软件团队在进行工程开发时可以遵循的流程。通过阅读,我发现其实这些流程都是通过最初的实际开发,然后总结归纳出来的比较有效率的工作方式和流程。下面介绍一下文中提到的相关的软件团队模式以及工作流程。

          软件团队模式明确了团队成员的分工。有以下几种模式:

          一窝蜂模式:这是最垃圾的一种模式,没有任何组织,最后往往会导致工程的失败,这就类似于《人月神话》中所描述的巴比伦塔失败的原因。

    主治医师模式:这种模式会有一个首席程序员,他负责整个项目的总体的架构和概念的设计,并进行主要的编码工作。这种工作方式就像医院中的手术团队,再做手术时,总会有一个主治医师,其他所有人都对主治医师提供服务和支持。

          明星模式:将主治医师模式运用到极点。这种模式的弊病很大,当团队中的明星陨落之后,这个团队该何去何从?

    社区模式:这种模式中,个人首先要具有相关的兴趣,不然个人不会加入到一个团队中,其次非常重要的是要求个人应该具有很强的责任心,“社区”并不意味着“随意”,每个人要对质量做充分的保证。

         业余剧团模式:我理解的这种模式和功能团队模式似乎差不多,但是又有区别。在业余剧团模式中,每个人在不同的项目中可能会有不同的定位和角色,个人在团队中听从一个中央指挥的指导和安排。而在功能团队模式中,具备不同能力的同事们平等协作,共同完成一个项目,项目完成后他们可能又各自组成不同的团队。

          秘密团队:在这种模式下,其他人不知道这个团队在该干什么。那么再这样的情况下,团队内部会有极大的自由、较高的热情、没有外界的干扰。

          特工团队:有一些具有特殊技能的专业人士构成,负责解决一些紧急而又紧迫性的问题。例如专门做网站安全的团队。

          交响乐团模式:这是一种比较稳定的模式。当某个软件领域处于稳定成长阶段时,众多大型软件公司的开发团队就会采取这种模式。

          爵士乐模式:这种模式给人的感觉很不靠谱,但是这种模式它强调个性化的表述,强有力的互动,对变化的内容有创意的回答。

        对以上这两种乐团模式来说,我觉得作为刚刚毕业的大学生来说,应该选择具有交响乐团模式的大公司去工作,培养和锻炼自己的编程能力。当然,我个人对新鲜事物比较感兴趣,创新对我有不小的吸引力,如果想要创新的话,最好是在个人具有了一定的技术实力和经验以后再谈。

        官僚模式:这种模式脱胎于大机构的组织架构。是跨组织的合作,这种合作比较困难。

        以上是对团队模式的介绍,对于这些模式来说,各有利弊,不同的团队可能会选择不同的模式,同一个团队在不同的时期也可能会选择不同的模式进行工程的开发。

       下面对开发流程做一下介绍说明。

         瀑布模型:这是脱胎于“硬”行业的一种模型。遵循分析——设计——实现——销售——维护这个流程。但是在软件开发中,要做相邻步骤的回溯,并且成功的产品,至少要把这个流程走两遍,现有一个模拟版本,然后在此基础上收集反馈,改进各步骤,最终交付一个最终版本。在瀑布模型中要加入客户对软件的反馈信息,并对反馈信息做及时的处理。目前我理解的瀑布模型可能是比较僵化,灵活性可能不是太好。而且各个步骤之间的交流可能也是比较困难。

          另外还有统一流程模型(分为初始化阶段、细化阶段、构造阶段、交付阶段)、老板驱动模型、渐进交付的流程、MVP、MBP模型。

         其中的MVP模型是吧产品最核心的功能用最小的成本实现出来,然后快速征求用户意见,它更强调更早有的用户的反馈,为此可以再产品完成之前就发布出来,它更强调产品的核心价值,设置为了核心价值,不得辅助功能在开发阶段可以不用考虑。我觉得这种模型非常好,因为到现在为止,我和几个同学也进行了比较小的软件的开发,在做软件之前我们设想了很多东西,但是在实际开发过程中我们又遇到了很多问题,而且提出了很多新的、我们没有考虑到的情况,类似于用户的反馈吧,那么我们想要在一定的时间内完成软件的开发的话,我们就必须先把我们的核心功能实现,然后在针对用户的反馈做进一步的完善。我觉得这种方式就目前的我们来说是挺实用的一种方式。

        个人感受:最后说一下我对阅读本书的感受,因为在阅读《构建之法》期间,我也在阅读其他的有关软件工程方面的书籍,通过对比阅读我发现,《构建之法》对于我来说更加通俗易懂,涉及的范围很广,在一些方面的深度也能够体现出来,而且文中的各种举例对比分析能更好的表达笔者的思想,我想对于初涉软件工程的人来说,这本书籍能够更加快速的让我们明白什么是软件工程。

  • 相关阅读:
    学习也好,科研也罢,都有内在规律。任何事物,只消抓住规律,就等于牵住牛鼻子
    赵伟国:陆资无法进入台湾紫光要到WTO控告(芯片是为了经济安全,高通找的人不是很聪明)
    小米新旗舰“翻车” 冲击中高端凸显品控短板(小米的缺点还真不少:电商、性价比、爆款、粉丝经济,说到底也都只是商业上的创新)
    WinRarHelper帮助类
    Window7下安装Ubuntu 14.04 64bit
    Kafka基本原理
    Abot爬虫和visjs
    CLR垃圾回收的设计
    NET Core全新的配置管理
    Github Atom
  • 原文地址:https://www.cnblogs.com/1329197745a/p/14905650.html
Copyright © 2011-2022 走看看