构建之法-现代软件工程读书笔记（二）软件开发流程

导读

• 前言
• 第五章 团队与流程
• 第七章 MSF

前言

借着值班的东风，抓紧看了三章，这三章内容主要讲软件开发的流程，作为一个按步加班的码农，多么希望能有一个稳定的环境加高效的环境，然后能高效的开发出别人伸出大拇指的功能，并且能够钱多事少（没有bug，好像又做梦了）。其中有一章讲了敏捷，准备对比现有我们实践的敏捷做个对比，会在读书笔记（三）上面另开一章。

第五章 团队与流程

Question:什么是团队?团队一般有哪几种模式？
所谓团队，首先要有一致的集体目标，团队要一起完成目标。团队内部有自己的分工，互相依赖合作，共同完成任务。
关于模式，作者给出以下几种：

1. 主治医生模式：有一个主刀医师，其他人都为医师服务。
2. 明星模式：极端的主治医生模式，明星的作用超过其他人总和，靠一己之力力挽狂澜。
3. 社区模式：志愿者参加，开源软件大部分都采用这种方式，不过成功的社区对代码的审查和签入质量非常严格。
4. 业务剧团模式：团队中每个人选择不同的角色，下一场可能换另一种模式。个人觉得想多了解自己项目的体系，可以尝试使用这类模式，当然前提是人手充足。
5. 秘密团队：秘密就是别人不知道，自由度高，一般的情况下不会使用这种。
6. 交响乐模式：稳定成熟的团队。
7. 爵士乐模式：自由有创造力，不拘泥于某些条条框框，某些土豪公司的实验室可能使用的是这种模式。
8. 功能团队模式：绝大多数的软件公司既有的团队模式。
9. 官僚模式：小公司、落后公司使用的制度，然饿国内确实有许多就是这样类型的团队。

开发流程

1. 写了再改模式：此模式不适合成熟点规模的公司，只适合哪些 不常用的程序、用完就扔的原型或演示程序。
2. 瀑布模式：非常经典的模式，很多场景现在还是这种模式或者在此基础上做一些修改。
3. 瀑布模式的各种变形：包括生鱼片模式、大瀑布带着小瀑布等等相关模式。
4. Rational Unified Process统一流程（RUP）：瀑布模式有这个特点：重计划，重事先设计，重文档表达。而RUP是把软件开发的各个阶段整合到统一的框架里面，包括：业务建模、需求、分析和设计、实现、测试、部署、配置和管理、项目管理、环境、初始阶段、细化阶段、构造阶段、交付阶段。
5. 老板驱动的流程：行政领导主导的流程，若老板不懂技术，弊病太多，不建议。
6. 渐进交付流程，MVP和MBP:MVP(Minimum Viable Product,最小可行产品)：提供最核心功能，抢占市场，再根据用户反馈改进。MBP（Maximal Beautiful Product,最强最美产品）：产品更了解用户需求，提高最全最美的功能，如iphone4，不过对产品有非常高的要求。
7. TSP（Team Software Process）的原则：（1）使用妥善定义的流程，流程中的每一步都是可以重复的、可以衡量的结果。（2）团队的各个成员对团队的目标，角色，产品有统一的理解。（3）尽量使用成熟的技术和做法。（4）尽量多采集数据，并用数据来帮助团队作出理性的决定。（5）制定切实可行的计划和承诺，团队计划要由负责具体执行的角色来制度。（6）增加团队的自我管理能力。（7）专注于提升质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法师做全面而细致的设计工作。

第七章 MSF

MSF（Microsoft Solution Framwork，微软解决问题框架），因为作者在微软呆了很多年，如果在谷歌，是不是GSF?不开玩笑，先看看它的基本原则。

基本原则

MSF有9条基本原则：

1. 推动信息共享与沟通（Foster open communications）
2. 为共同的远景而工作(Work toward a shared vision)
3. 充分授权和信任(Empower team members)
4. 各司其职，对项目共同负责(Establish clear accountability and shared responsibility)
5. 交付增量的价值(Deliver incremental value)
6. 保持敏捷，预期和适应变化(Stay agile,expect and adapt change)
7. 投资质量(Invest in quality)
8. 学习所有的经验(Learn from all experiences)
9. 与顾客合作(Partner with internal and external customers)
   然后作者通过虚构的人物和demo来详细分析了一下这几个原则。后面又介绍了一下MSF的团队模型和过程模型，以及对敏捷和CMMI的支持，很惭愧，至今还未进入到一家管理非常规范的公司，对此上面缺乏经验，所以看的云里雾里，或许哪天级别高了，参与到部分管理（真正的管理），可以回头借鉴这上面的经验。

总的来说，这两张内容较为理论化，干货不多，可能自身太low，级别高一些的时候回头看或许有更多的感悟，因为切身经历过才会懂得更多，敬请期待下一节：构建之法-现代软件工程读书笔记（三）敏捷流程。