构建之法 第五章 团队和流程

典型的团队开发模式和流程，完全是新的内容；涉及到更多的术语和有意思的策略性东西

1.团队模式【我比较认可的】

1. 主治医师模式
   • 由首席程序员（相当于首席医生）负责整个工程，周围人员各司其职，配合支持中心人物的工作；
   • 【我认为这种模式适合于有着杰出程序工程师的规模略小的团队】
2. 社区模式
   • 我非常心水的linux社区就是最大的成功案例之一。
   • 社区并不意味着“随意”，而是有着严格的复审和质量控制
3. 交响乐团模式
   • 【不适用于创新型的项目，反而是对于稳定的、种在执行的项目的效率比较高】
   • 门类齐全，各种任务都已经有了经验
4. 功能团队模式
   • 具备不同能力的同事平等地协作，共同完成某个任务；
   • 【没有管理和被管理的模式】

2.开发流程

1. 瀑布模型（waterfall model）
   • 用于单向的、不可逆转的生产过程；
   • 要有相邻步骤的回溯；
   • 用户及早介入非常重要。
   • 适用范围【个人认为】
     • 产品的定义准确但是正确性重要【这样才适合花力气去回溯】
     • 团队成员无法频繁交流【这样才会用得到那么多记录文档】
   • 缺陷
     • 最终产品最后才出现，这样其实是很危险且成本很高的
2. 统一流程RUP（rational合理的 unified统一的 process）

RUP就是把软件开发的各个阶段整合在一个统一的框架里面。其规程（discipline）或者工作流（workflow）如下———

- 业务建模：用精确语言描述用户活动
    - 这里提到了UML（统一建模语言），其实这种建模的思想应用很广泛；举例来说，“编码理论”或者是“数字电路基础”这种课程所用的状态图等都可以归属于UML中
- 需求：从活动中感知并表达需求，从需求中抓出软件（至少）要实现的功能；
- 分析和设计：将系统划分成子模块；
- 实现：紧接上一步，搭建可执行的系统；
- 测试：验证已经交付的组件之间的正确性、组件之间交互的正确性以及所有的需求是否已经被正确地实现；
- 部署：生成最终的版本并分发给所有用户；【其实我之前的想法是到此为止，然而在现实中并不是这样，作为一个目标是拥有一定生命周期的软件，后期的维护、管理也是必不可少的】
- 配置和变更管理：记录各个阶段产生的各种工作结果；
- 项目管理：平衡各种因素，以便在各个阶段交付达到要求的产品；
- 环境：向软件开发组织提供软件开发环境【每个阶段都有点类似迭代开发（把一个大的目标逐步完成，每一个阶段所完成的都可以为下一个阶段做铺垫）】

1. 渐进交付的工作流程MVP&MBP
   • MVP（minimal viable product）最小可行产品，即把产品最核心的功能用最小成本实现出来（或者甚至可以只是描绘出来），然后快速征求用户意见。
     • 强调更早地获得用户反馈，为此可以在产品完成之前就发布
   • MBP（maximal beautiful product）与MVP相反，走的是最美最强产品思路