《构建之法》(三)---流程
本周学习了第五~七章，了解了各种软件流程。
团队和流程
1.软件团队的模式
主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式（下面主要是几个重要的模式）
主治医师模式
由首席程序员（相当于首席医生）负责整个工程，周围人员各司其职，配合支持中心人物的工作；适合于有着杰出程序工程师的规模略小的团队
社区模式
社区并不意味着“随意”，而是有着严格的复审和质量控制。开发和维护linux操作系统的社区就是最大的成功案例之一
交响乐团模式
不适用于创新型的项目，反而是对于稳定的、种在执行的项目的效率比较高。门类齐全，各种任务都已经有了经验
功能团队模式
具备不同能力的同事平等地协作，共同完成某个任务；
2.开发流程
写了再改模式、瀑布模型、瀑布模型的各种变形、Rational Unified Process统一流程（RUP）、老板驱动的流程、渐进交付的工作流程MVP&MBP、其他（“敏捷流程”和“MSF”）
瀑布模型（waterfall model）
用于单向的、不可逆转的生产过程；要有相邻步骤的回溯；用户及早介入非常重要。
适用范围；产品的定义准确但是正确性重要
缺陷：团队成员无法频繁交流；最终产品最后才出现，这样其实是很危险且成本很高的
统一流程RUP（rational合理的 unified统一的 process）
RUP就是把软件开发的各个阶段整合在一个统一的框架里面。其规程（discipline）或者工作流（workflow）如下———
- 业务建模：用精确语言描述用户活动
- 这里提到了UML（统一建模语言），其实这种建模的思想应用很广泛；举例来说，“编码理论”或者是“数字电路基础”这种课程所用的状态图等都可以归属于UML中
- 需求：从活动中感知并表达需求，从需求中抓出软件（至少）要实现的功能；
- 分析和设计：将系统划分成子模块；
- 实现：紧接上一步，搭建可执行的系统；
- 测试：验证已经交付的组件之间的正确性、组件之间交互的正确性以及所有的需求是否已经被正确地实现；
- 部署：生成最终的版本并分发给所有用户；
- 配置和变更管理：记录各个阶段产生的各种工作结果；
- 项目管理：平衡各种因素，以便在各个阶段交付达到要求的产品；
- 环境：向软件开发组织提供软件开发环境
渐进交付的工作流程MVP&MBP
MVP（minimal viable product）最小可行产品，即把产品最核心的功能用最小成本实现出来（或者甚至可以只是描绘出来），然后快速征求用户意见。
强调更早地获得用户反馈，为此可以在产品完成之前就发布
MBP（maximal beautiful product）与MVP相反，走的是最美最强产品思路
敏捷流程
1.敏捷开发原则【个人进行了分析组合】
1. 可用的、尽早交付的软件是项目进展的主要指标
2. 保持可持续的发展，以需求作为发展优势
3. 自我管理。无论是交流还是信任还是共同工作
2.敏捷的流程
找出product backlog、
决定当前的sprint即sprint backlog（团队成员根据任务量和自身条件认领backlog）
sprint（每日一例会，各自汇报做了什么，有什么困难，下一步计划）
敏捷的团队
要求：自我管理、自我组织、多功能型
我们需要敏捷（agile）的开发流程，而不是匆忙（rushed）或者忙乱（chaotic）的流程
MSF
MSF（Microsoft Solution Framework）微软解决方案框架
基本原则：
推动信息共享与沟通。所有信息都保留并公开；
为共同的远景工作。这个远景/目标是一个对所有人而言都没有二义性并且有一定距离的可实现目标；
充分授权和信任。给予充分的权力（也会有记录软件作为“监工”防止偷懒）
给予充分的自尊。（领导在项目中的角色是“支持”而非“控制”）
各司其职，共同对项目负责。无责任的旁观者和有重大责任的当局者的看法自然是不一样的
重视商业价值，提供渐进的价值。一个团队如果没有经得起考验的商业价值，没有明确的远景，是很难坚持下去的
保持敏捷，预期和适应变化。（不期望变化）
投资质量。
“投资质量”绝对不是质量第一，而是“有条件的”重视质量：衡量质量的时机、效率、代价
MFS团队模型：测试，项目管理，用户经验，测试，发布管理，开发，交流。
MFS过程模型：构思->远景/范围认可->计划->项目计划认可->开发->开发完成->稳定->发布就绪认可->部署->部署完成。
MSF的敏捷开发模式
质量：防患于未然。开发实用性产品的过程中，防止缺陷发生成为团队的首要任务。
注重保持一个随时可以发布的高质量
