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