构建之法 第七章学习
MSF简史
微软公司中关于软件开发的思想和宣言有一个方法论——微软解决方案框架（Microsoft Solution Framework，MSF），也就是微软推荐的软件开发方法
大约在1993年，微软在总结了自己产品团队的开发经验和教训，以及微软咨询服务部门的业务经验后，推出了MSF。当时的MSF只是这些经验和教训的初步总结。在以后的几年中，MSF进一步吸收了微软各个部门和微软的合作伙伴在实际项目中的经验。2002年，随着Visual Studio .NET的发布，微软发布了一系列关于MSF3.0的白皮书，针对MSF3.0的大规模培训也开始在中国举办。
MSF基本原则
MSF没有像敏捷那样搞一个宣言，但是它也有一套思想框架—9条基本原则
1. 推动信息共享与沟通（Foster open communications）
- 第一个原则：就是所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当然，对牵涉到技术机密、安全性等信息要采取必要的保护措施
- 看不到所有的信息，那么项目进度以及项目中存在的各种问题就不能及时让所有人知道，这样MSF中其他的原则也就不能实行了。没有开放的信息，也就谈不上“授权”，或者“建立清晰的责任和共同的职责”，以及“保持敏捷，预测并适应变化”。这也是为什么“推动信息共享与沟通”是第一个基本原则。MSF团队模型和MSF过程模型也是建立在“信息共享与沟通”原则上的
2. 为共同的远景而工作
- “共同的远景”是指产品的远景。我们做一个产品，不管是应用软件、行业软件，还是通用软件，要明确项目的目标是什么。
3.充分授权和信任
这一点的关键是“授权”这个词，授权（Empower）有两个意思：
- 给某人权力和权威
- 给予某人更多自信和自尊
在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权在职权范围内按照自己的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也认为团队能兑现承诺，并进行相应的规划
充分授权的管理方式是MSF的核心观念之一。MSF团队模型就是建立在以下两个原则上的：
- 平等协作—成员之间、团队之间是平等协作的关系
- 充分授权给团队和成员
这就是为什么MSF团队模型是网状，而不是层次结构。这样做有什么好处？好处有两点：
- 被授权的人会承担起自己对项目的责任，同时也期望同事们也同样对项目负责
- MSF提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间，而不是上级交给的时间，这意味着让真正做这件事的人按照自己的估计去完成任务。这样做的结果是啥？是人人都会支持项目的计划和时间表，因为这个时间表是每个人自下而上订出来的
组员充分授权，到头来发现事情都没做完，咋办?
- 这要靠工具的支持，在VSTS系统中，由于所有工作的进展都记录在案，任何延迟都会被及时发现
- 这样组长（或其他层次的领导）就不用把力花在“询问”，而花在“帮助解决”上，在最关键的时候提供指导和帮助
- 领导在项目中的角色是“支持成员完成任务”，而不是“控制成员，迫使他们完成任务”
- 充分授权在MSF团队模型的另一个含义是：信任，鼓励团队成员成长，每人都可以在某一时段、某一领域当领导
4. 各司其职，对项目共同负责
5.重视商业价值，提供渐进的价值
- 衡量一个项目的成功，并不是在于技术有多酷，而是在于商业的成功
- 我们提供的新版本对用户真的有价值
- 和客户商讨一个最优的新版本的发布频率
最优的频率会因为产品的特点（企业产品，消费者产品）和发布平台（办公电脑、家用电脑、互联网、智能手机及平板电脑）的不同而大不相同
6.保持敏捷，预期和适应变化
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化
除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开……这些都要求我们团队保持敏捷的身段
7.投资质量
8.学习所有的经验
在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题
这一原则有两个含义——
- 把经验总结出来
- 分享经验
为什么要坚持总结和分享？是为了——
- 让团队成员从别人的成果和失败的例子中学到东西
- 帮助新项目重复以往成功的做法
- 培育团队总结的习惯和“批评与自我批评”的文化
MSF的团队模型
MSF过程模型
MSF敏捷开发模式
在Visual Studio TFS中，MSF演化为以下两个分支：
- MSF敏捷开发模式
- MSF CMMI开发模式
更强调与用户的交流
项目的商业价值要由用户说了算，那些“我觉得用户会喜欢”的东西要及早和用户交流。因为“我觉得”和“用户觉得”是两码事
质量—防患于未然
- 防止缺陷的发生成为团队质量控制的首要任务，在防止缺陷的发生和确保缺陷被修复上，所有的角色都要负责
- 微软公司内部做过统计，在一个中大规模的团队中，一个“缺陷”从发生到被改正，中间经过了近20道工序，平均总的时间开销是12小时。优秀的团队能做到这一点：可能的缺陷在设计阶段之前就讨论过，并且在代码中已经避免了，因此在“缺陷跟踪系统”中，并没有出现很多缺陷记录在案，但是软件的质量仍然很高
重视在实战条件下的质量
这一点要求我们保持随时可以发布的高质量。如果用户说：时间到了，网站要上马。我们应该很快地交给用户一个可用的版本，也许功能不多，但是现有的功能都可用。这就要求我们必须保证项目的质量是“随时可用”。为了达到这一点，我们要重视产品的安装和发布—产品要尽早能够达到随时安装、发布的标准。在一些项目中，安装和发布都是最后阶段才做，这就导致几个问题：
- 开发过程中，测试团队很难安装产品，阻碍了测试团队的进展。很多情况下，测试人员不得不从多个源头拷贝不同的文件到测试环境中，才能开始测试，浪费了大量时间
- 关于安装的缺陷得不到重视—用户拿到一个Beta版，意见最大的就是安装不上！或者好不容易装好了，却卸载不了，不得不重新安装系统。
精简过程，直奔主题
- 主题是为了解决用户的问题
- 另外一个重要的因素是，如果团队在整个软件生命周期都使用团队协作服务器（TFS），那么很多活动、决定、文档都自然地记录在TFS上，不必额外去为了文档而再写一些东西。
MSF CMMI开发模式
- CMMI是CMM模型的最新版本，资料显示，如果一个项目的管理达到了CMMI较高的等级，那么项目的质量与按期完成率都会有较大的提高。
- MSF能帮助团队快速达到CMMI第三级“明确”阶段