《构建之法》读书笔记第5章——团结就是力量？

本章节讲的是团队编程
随着现在软件规模越来越大，团队编程的作用也愈加凸显。
团队模式有以下模式：

1. 一窝蜂模式：一堆人上来就干，没有协调性因为这样的团队存活时间不长，所以被观察到的不多
2. 主治医师模式：首席程序猿工作，其余人打辅助，不少学校的软件工程的团队作业沦为这种模式，只靠团队中一两个完成任务，其余人打酱油。
3. 明星模式： 主治医生的极端版本
4. 社区模式：Unix和Linux属于这种，依靠严格的质量管理和志愿者参与完成
5. 业余剧团模式：学生的实践培训项目大概属于这种
6. 秘密团队模式：苹果研发发Macintosh以后的系统和不少创业公司团队属于这种
7. 特工团队：由特殊技能的专业人士组成，比如早年解决千年虫的团队和负责网络安全的团队
8. 交响乐团团模式：大多数大型软件公司开发团队采用这种模式，比如office系列
9. 爵士乐模式：比较散漫自由
10. 功能团队模式
11. 官僚模式：即老板驱动

开发流程模式：软件开发过程中有很多种类的流程方法，目的是提高软件开发、运营和维护的效率，以及提升用户满意度、软件的可靠性和可维护性。书中总结的开发流程模式如下：

1. 写了再改
   不少软件工程课程的作业属于这种模式：

2. 瀑布模型
   

3. 统一流程模式（RUP，Rational Unified Process ）
   把软件开发的各个阶段整合在一个统一的框架里，包括业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理、环境。并且每个阶段设置一个里程碑（milestone），分为初始、细化、构造、交付四个阶段，并且每个阶段可以迭代几次

4. 老板驱动模式
   由公司老板或行政主管直接推动，在团队尚不成熟或者领导水平较高方能显出效果，但在领导是外行或者领导不在、不称职的时候会很麻烦。

5. 渐进交付和MVP
   不断重复“开发→发布→听取反馈→根据反馈做改进”四个阶段，直到用户满意或者钱用完。09年开始一些互联网团队采用MVP方法，即—Minimal Viable Product，最小可行产品，具体做法是：把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。

在介绍完团队模式和开发流程模式后，书中又介绍了优秀模式和流程的共同点(CMU软件工程学院把这些共同点抽象总结为Team Soft-ware Process（TSP）的原则)：

使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。
2.团队的各个成员对团队的目标，角色，产品都有统一的理解。
3.尽量使用成熟的技术和做法。
4.尽量多地收集数据（也包括对团队不利的数据），并用数据来帮助团队做出理性的决定。
5.制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定（而不是从上级而来）。
6.增加团队的自我管理能力。
7.专注于提高质量，争取在软件生命周期的早期发现问题。

团结就是力量，但是团队如何“团结”起来，同学们在完成团队作业前也可以好好看看这一章