构建之法阅读笔记04

第五章 团队和流程

团队和非团队：

　　1.团队有一致的目标，团队要一起完成这个目标。

　　2.团队成员有各自的分工，互相依赖合作，共同完成任务。

软件团队模式：

　　1.主治医师模式：“一个学生干活，其余学生跟着打酱油”。

　　2. 明星模式：明星的光芒改过了团队其他人的总和。

　　3. 社区模式：好处是“众人拾柴火焰高”，坏处是如果大家都只来烤火，不去拾柴；或者捡到的柴火质量太差，最后火也就熄灭了。

　　4. 业余剧团模式。

　　5.秘密团队，在秘密状态下进行，别人不知道他们具体在干什么。好处是：团队内部有几大的自由，没有外界的干扰，团队成员有几大的投入。

　　6. 特工团队。由一些专业人士组成，负责解决一些棘手二又紧迫性的问题。

　　7. 交响乐模式。当某个软件领域处于稳定成长阶段的时候，总舵大型软件公司开发团队结汇采取这种模式，例如微软公司的office软件。

　　8. 爵士乐模式：不靠谱，没有现场指挥。没有模式，人数较少。

　　9. 功能团队模式，具备不同能力的同时平等协作，共同完成一个功能。功能完成之后，这些人又重新组织和别的角色一起完成下一个功能。

　　10. 官僚模式。 

 

开发流程：我们在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中，叫“软件开发流程”。

　　1. 改了在写模式：适合于“只用一次”的程序，“看过了就扔”的原型，一些不使用的演示程序。

　　2. 瀑布模型：分析-->设计-->实现（制造）-->销售-->维护的流程。使用范围：

　　　　1）如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证。

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

　　　　3）使用的技术非常成熟，团队成员都很熟悉这些技术。

　　　　4）负责各个步骤的子团队分属不同的机构，火灾不同的地理位置，不可能做到频繁的交流。

　　　　局限性：

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

　　　　2）回溯修改很困难甚至不可能。

　　　　3）最终产品知道最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并适用。

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

　　4. Rational Unified Process 统一流程

　　　　1）业务模型

　　　　2）需求

　　　　3）分析和设计

　　　　4）实现

　　　　5）测试

　　　　6）部署

　　　　7）配置和变更管理

　　　　8）项目管理

　　　　9）环境

　　　　RUP把软件开发分成几个阶段：

　　　　　　（1）初始化阶段：分析软件系统大概的构成，系统与外部系统的边界在哪里的，大致的成本和预算是多少，系统的风险主要来自哪里。

　　　　　　（2）细化阶段：分析问题领域，建立健全的体系结构基础，编制项目计划，按优先级处理项目中的风险。

　　　　　　（3）构造阶段：团队开发出所有功能及，并有序地把功能集成为经过各种测试验证过的产品。

　　　　　　（4）交付阶段：团队的工作重点是确保软件能够满足最终用户的实际需求。

　　5. 老板驱动的流程：开发流程事实上是由行政领导主导，或者有公司的老板驱动。

　　　　1）当软件订单的获得不是主要靠技术实力，而是靠个人关系，或者暗箱操作的时候。

　　　　2）大型企业内部，软件功能往往有行政体系来决定。

　　　　3）有些老板比一般技术人员懂得市场和竞争。

　　　　4）软件团队尚不成熟，不懂得如何对行政领导有技巧的说不。

　　6. 渐进交付的流程，MVP和MBP：【开发-->发布-->听取反馈-->根据反馈做改进】

 

阅读感受：

　　以前我虽然知道一款软件的发布需要及其复杂的流程，制作一款软件并不比其他类的功能简单。但是我并没现有想过软件开发中会有哪些具体的流程，与其说没想道倒不如说想不到。这么多开发模式当我，我并不知道哪一个适合我，我有时哪一种，如果仅凭我的认识自然认为统一流程最好了，但是若是真的遇到实战项目，我真的可以做到吗？这个很难说。也许我应该向这方面努力，虽然我知道现阶段的我是不可能达到能够领导一个团队的水平的，至少我也得有这样的梦想。