学习资源：
http://www.cnblogs.com/umlonline/archive/2011/07/25/2116121.html
心得体会：
在学习MSF这篇网络资源前，谈一下自己对MSF的认识。
MSF最初第一印象，就是微软解决方案框架结构，即Microsoft Solutions Framework，早期，因此我延伸出自己的一套ZSF (Zivsoft Solutions Framework)，智艾悦软件解决方案框架结构。在我最初的理解，它就是一些框架，然后延伸出各种各样的解决方案。
以上是我没看Fireball学习资源的简要印象，当我打开Faireball这篇《超越MSF - 视频分享第7弹！》，刚读完第一段摘要“MSF是Microsoft Solution Framework的简称，是微软软件开发方面的方法论。”时，我还专门打开自己的ZSF看看是不是我弄错了，我记得应该是Solutions，而非Solution，难道我理解多年的ZSF缩写竟然是Microsoft Solution Framework，经查实，MSF应该是Microsoft Solutions Framework。为何提出这个呢？因为小小一个s可见你的领悟是否够深，毕竟微软解决方案框架结构绝非仅一个方案，如果写成Microsoft Solution Framework，让人看了别扭。由于不想写太长，以下简要写写心得：
MSF是一组建立、开发和实现分布式企业系统应用的工作模型、开发准则和应用指南。它帮助企业融合商业和技术的目标，降低采用新技术后系统整体的费用，以及成功的应用微软技术整合商业过程的方法。这是多么庞大的一个词汇，被MSF仅三个字符囊括。
MSF揭示出为成功设计、构建和管理技术基础结构或商业解决方案，所需了解的重要风险、重要的设计基础假设和关键的依赖关系。它包括明确的知识库、应用指南和实践经验，如：
企业结构设计方案—采用交互的方式，侧重于制定长期规划，同时也能完成短期目标。
项目开发准则—包含组队模型和过程模型，用于建立高效的项目组，管理项目的生命周期。
项目设计过程和多层结构的应用程序模型—用于支持设计复杂的分布式企业应用。
企业信息基础设施的实施方法—使用组队模型和过程模型支持实现、操作和技术上的方案。
最初，我理解它仅仅是一种框架结构，好比我自己的ZSF，但它远远不止这些，它不仅是一种框架结构，还是一种资源整合，像Faireball所说的方法论，更像一种工作指南，通过微软培训讲师获得。
1. MSF组队模型：
针对MSF的组队模型，个人体会是它是一个环形圈圈连接起来，而不是像组织结构那样一层一层连起来，因此它没有重要性、优先级之分，它像Faireball所讲，每一个环节都同等重要，我们没有个人英雄，我们只有团队“作战室”。 个人翻译它的六种基本的角色应该是（程序管理、产品管理、开发、测试、业务逻辑和用户培训），如果了解微软工作文化的话，MS里的PM并不是项目经理（Project Manager）而是 Program Manager。同样，作为在MS工作过的自己，最大的一个体会就是开发与测试的待遇是一样的，一个SDE2和一个SDET2的薪水基本一样，也就是说老美花的MSF组队模型用圈圈连起来并不是虚无的，他们的确把各个环节看得同等重要。
对于我们自己，中国的软件项目团队，在中国国情里，有着明显，管理高于开发，开发高于测试的潜在观念。而事实上，如果被人不看好的测试没做好，开发也不会好到哪里，管理也并非卓越。好比，中国没人愿意当农民，都跑到城市，最后假设只剩1%人种粮食了，试想有钱人也同样饿肚子。
总而言之，通过MSF组队模型，给我的启示是，站在每一个岗位的每一个人，都要负责任的把自己的那份事干好，同时很好的与其它环节协作，从而站在一个团队的角度思考问题，将软件项目成功交付。
2. 团队管理与开发模式
下面再针对Faireball的“两个限死，两不确定”谈一下个人体会。我主要从团队管理和开发模式上谈体会。
一、团队管理
许多公司的企业文化都是“以人为本”，对于IT企业来说，“人是企业最重要的资产”，那么对IT项目来说，“团队就是项目成败的要素”， 团队是一个集体，不是个人。没有个人英雄，只有集体”作战室“。因此”协作“、”责任“非常重要。绝不可以推卸责任，出现踢皮球事件。虽然团队成员都非常重要，但不能忽视项目经理的作用，高效率团队协作是要靠PM良好的整合管理能力。
沟通在团队管理里起至关重要的作用，项目组织结构跟具体企业环境有关系，但通过沟通了解团队成员各种冲突； 团队管理的第一要素即是管人，也就是要根据人的心理和思想规律，通过尊重人、关心人、激励人来改善人际关系，充分发挥人的积极性和创造性，从而提高团队工作能力和管理效率。古人云:“人事之最难在于知人”，沟通可以帮助我们调动团队积极性，改善组织结构，提高效益，发展软件生产能力。
二、开发模式
明确详细的设计、需求非常重要，可以有效降低预算、时间。
做任何项目前，不能拿到需求就开始写代码，看似很快进入测试，但出来的交付物非常不稳定，漏洞百出，最后焦头烂额不说，还浪费大量团队人力测试、维护等。
因此拿到需求，对需求做分析非常重要，同时在架构设计上要详细推敲、论证，对各种潜在和已知的风险进行识别与评估，然后找出最佳应对方案，从而选择最佳详细设计解决方案。分析、规划，看似花了很多时间，但大大降低了编码维护、返工的时间，从而整体上保证SPI处于优势，从而大大提高进度。
最后针对“两个限死，两不确定”，作为项目经理，应该理性对待，不能评拍脑袋将预算、进度吝啬，貌似加班赶工可以提前进度，但预算却大大增加，软件项目各种制约因素本就是一种相互矛盾，相互影响的，因此PM是要深思各种项目管理技巧和详细规划。在“两不确定”上其实跟“两个限死”是有很紧密的联系的，合理估算成本，规划进度，并要求在规定的里程碑里一步一步做好需求分析、设计、架构等环节，必然会有“两不限死，两个确定”。