构建之法-阅读笔记4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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