标签：comm href 新项目 特定 鼓励 阶段 经验总结 任务 联网
微软公司中关于软件开发的思想和宣言有一个方法论——微软解决方案框架（Microsoft Solution Framework，MSF），也就是微软推荐的软件开发方法
大约在1993年，微软在总结了自己产品团队的开发经验和教训，以及微软咨询服务部门的业务经验后，推出了MSF。当时的MSF只是这些经验和教训的初步总结。在以后的几年中，MSF进一步吸收了微软各个部门和微软的合作伙伴在实际项目中的经验。2002年，随着Visual Studio .NET的发布，微软发布了一系列关于MSF3.0的白皮书，针对MSF3.0的大规模培训也开始在中国举办。
MSF没有像敏捷那样搞一个宣言，但是它也有一套思想框架—9条基本原则
1. 推动信息共享与沟通（Foster open communications）
第一个原则，就是所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当然，对牵涉到技术机密、安全性等信息要采取必要的保护措施
看不到所有的信息，那么项目进度以及项目中存在的各种问题就不能及时让所有人知道，这样MSF中其他的原则也就不能实行了。没有开放的信息，也就谈不上“授权”，或者“建立清晰的责任和共同的职责”，以及“保持敏捷，预测并适应变化”。这也是为什么“推动信息共享与沟通”是第一个基本原则。MSF团队模型和MSF过程模型也是建立在“信息共享与沟通”原则上的
2. 为共同的远景而工作（Work toward a shared vision）
“共同的远景”是指产品的远景。我们做一个产品，不管是应用软件、行业软件，还是通用软件，要明确项目的目标是什么。
这个目标必须是明确的，没有二义性；
这个目标不是当前就能达到，必须是通过努力才能达到的；
这个目标不是空泛的，它应该对项目成员每天的工作都有指导作用。每天你来上班，如果发现你做的事情对项目的远景没有帮助，你应该跟老板提出来
远景一般是由“有远见的人”提出，然后公开讨论，在讨论的过程中，可以消除误解，凝聚共识。这是一个项目的关键，是项目第一阶段要达到的主要目标
3. 充分授权和信任（Empower team members）
这一点的关键是“授权”这个词，授权（Empower）有两个意思：
在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权在职权范围内按照自己的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也认为团队能兑现承诺，并进行相应的规划
充分授权的管理方式是MSF的核心观念之一。MSF团队模型就是建立在以下两个原则上的：
这就是为什么MSF团队模型是网状，而不是层次结构。这样做有什么好处？好处有两点：
组员充分授权，到头来发现事情都没做完，咋办?
这要靠工具的支持，在VSTS系统中，由于所有工作的进展都记录在案，任何延迟都会被及时发现
这样组长（或其他层次的领导）就不用把力花在“询问”，而花在“帮助解决”上，在最关键的时候提供指导和帮助
领导在项目中的角色是“支持成员完成任务”，而不是“控制成员，迫使他们完成任务”
充分授权在MSF团队模型的另一个含义是：信任，鼓励团队成员成长，每人都可以在某一时段、某一领域当领导
4. 各司其职，对项目共同负责（Establish clear accountability and shared responsibility）
| 关键质量目标 | MSF小组角色 | 出口条件 |
|---|---|---|
| 按约束条件交付产品 | 程序管理 | 我们的项目是在时间/资源的条件内交付的么 |
| 按产品规格说明交付产品 | 开发 | 我们是否按照功能说明完成了各项功能 |
| 保证所有问题都得到处理 | 测试 | 我们发现了所有的问题，而且都有处理方案吗 |
| 产品部署和后续管理 | 发布管理 | 客户能否快速方便地部署产品和进行后续管理 |
| 让产品更好用 | 用户体验 | 产品是否适应用户的使用习惯？易学易用 |
| 让客户满意 | 产品管理 | 客户是否（总体上）满意我们的项目 |
在项目进展的过程中，对于每一项任务，每个人都要明确以下几点。
与“信息共享与沟通”原则相呼应，这样的安排能让所有人都明确自己的职责，同时有“大局观”—知道别人在做什么，为什么，以及整个项目的目标
5. 交付增量的价值（Deliver incremental value）
现在的软件产业，特别是和互联网相关的产业，变化非常快，用户希望产品团队经常提供更新，以适应新的需求。我们要保证在两个方面保证客户的利益：
在MSF团队模型中，“用户体验”这个角色代表了用户的利益，保证产品能真正易于使用；“产品管理”这个角色代表了客户的利益，保证了我们的产品能为顾客提供商业价值。搞技术的，要尊重这两个角色，因为他们代表的是我们的衣食父母
6. 保持敏捷，预期和适应变化（Stay agile, expect and adapt change）
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化
除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开……这些都要求我们团队保持敏捷的身段
7. 投资质量（Invest in quality）
对质量的重视，引起对质量的投资，引起对人、过程和工具的投资。
投资要讲效率
软件开发过程大部分时间花在了解/设计/变更/再了解/再设计的过程中。我们要重视质量，但并不是要不惜一切代价达到最高的质量标准（有人倒吸了一口凉气），因为提高人/过程/工具的质量是要花成本的！我们不是为提高质量而提高质量。我们要讲投资的效率。比如，在做快速原型的过程中，有些部分可以做得粗糙一点
投资要讲时机
比如说对于某项技术的培训，最好的做法是在即将需要的时候进行培训。太超前或滞后都不灵
投资是长期的
和投资股票/不动产一样，真正的投资者看重的是长线的收益；人的成长、团队的成熟都需要时间，不可能短期内立竿见影。那些“短平快”的东西，叫投机，不叫投资
8. 学习所有的经验（Learn from all experiences）
在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题
这一原则有两个含义——
为什么要坚持总结和分享？是为了——
MSF在每一个里程碑结束时都要做一个“里程碑回顾”，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广
在项目结束时，MSF推荐请团队以外的专家来主持召开“事后诸葛亮”会，这样的专家会比较系统地总结团队的成功经验和失败教训，同时也客观评价团队的一些特性和团队的开发过程管理，这样能促使团队成员以客观、向前看、解决问题的心态来参加“事后诸葛亮”会，避免主观臆断或相互指责
9. 与顾客合作（Partner with internal and external customers）
MSF团队模型定义了小组同级成员的一些角色和职责
在MSF团队模型中，任何技术项目都必须达到特定的关键质量目标，才能够被认为是成功的项目。任何一个角色无法实现其目标，都将危及整个项目。因此，每个角色都被认为是同等重要的，重要的决定都要共同作出。相关的目标和角色如上图所示。
一个项目要达到的目标很多，MSF团队模型让不同的角色去实现这些目标。在一个项目结束的时候，每个角色都问自己这样的问题——我是否达到了我的质量目标？
最后，比如测试团队（角色：测试）要保证“我发现的所有问题都得到解决”，那么测试团队就会做一下两件事：
要注意的是，保证这些问题都得到“处理”和得到“解决”是不一样的，有些问题目前不能得到完美的解决，但是可以由让用户满意的处理方案，项目团队不能回避这些问题
发现了问题，但是目前的“处理”不能让用户满意时，测试团队就要和别的角色（如：产品管理/程序管理/开发）一起研究用户需求，在可能的方案中选出一个，比如：
按照目前的状态交付，向用户作出说明（如：在某个操作系统/浏览器版本下，某个功能不能正常工作）
推迟交付时间，让团队有足够的时间来解决问题
修改产品的约束条件（如要求客户的操作系统/浏览器必须是某一个版本以上，或者增加一个附加条件：产品发布后半年会出新的插件解决问题）。在讨论处理方案时，每个角色从自己的质量目标出发并对其负责
每个项目都要经过一个生命周期，图7-2是MSF过程模型的生命周期简图，下图就是MSF过程模型简图
MSF过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中基于里程碑的规划优势与螺旋模型中增量迭代的长处结合了起来
MSF过程模型的基本元素是阶段和里程碑。所谓“阶段”，就是在这一段时间里团队集中精力做某一类事情，每个阶段的结束都代表了项目的进展和团队工作重心的变化。比如在“开发阶段”结束后，团队就不再允许设计/实现新的功能，除非有理由充分的“变更请求”
团队用里程碑来检查工作是否结束和同步各个角色的进度，以此来确定当前阶段的目标是否已经实现。此外，里程碑标志着每个阶段的结束，此时团队应该引导成员转移工作的重心，并鼓励队员以新的视角来看待下一阶段的目标。在上一个阶段产生的各种交付内容，将成为下一阶段的起始点。
在Visual Studio TFS中，MSF演化为以下两个分支：
MSF敏捷开发模式吸收了近几年来在软件业界流行的各种“敏捷”开发模式的优点，认识到目前大部分软件是以网络应用相联系的，强调和用户更紧密地交流，快速迭代，避免不必要的过程。
项目的商业价值要由用户说了算，那些“我觉得用户会喜欢”的东西要及早和用户交流。因为“我觉得”和“用户觉得”是两码事
防止缺陷的发生成为团队质量控制的首要任务，在防止缺陷的发生和确保缺陷被修复上，所有的角色都要负责
有一些团队把开发和测试有意无意地对立起来，好像二者是矛盾的。一个典型的例子是，有时开发人员不想给测试人员足够的信息，好像不想“帮”测试人员找到缺陷；与此同时，测试人员一旦找到缺陷，会有些得意，“看，你写的代码那么臭，我又发现了N个Bug”。这种对立情绪，也许在短期内能刺激成员的工作热情，而从长远来看是有害的。很少有人会希望在这种充满对立情绪的环境中工作
微软公司内部做过统计，在一个中大规模的团队中，一个“缺陷”从发生到被改正，中间经过了近20道工序，平均总的时间开销是12小时。优秀的团队能做到这一点：可能的缺陷在设计阶段之前就讨论过，并且在代码中已经避免了，因此在“缺陷跟踪系统”中，并没有出现很多缺陷记录在案，但是软件的质量仍然很高
这一点要求我们保持随时可以发布的高质量。如果用户说：时间到了，网站要上马。我们应该很快地交给用户一个可用的版本，也许功能不多，但是现有的功能都可用。这就要求我们必须保证项目的质量是“随时可用”。为了达到这一点，我们要重视产品的安装和发布—产品要尽早能够达到随时安装、发布的标准。在一些项目中，安装和发布都是最后阶段才做，这就导致几个问题：
开发过程中，测试团队很难安装产品，阻碍了测试团队的进展。很多情况下，测试人员不得不从多个源头拷贝不同的文件到测试环境中，才能开始测试，浪费了大量时间
关于安装的缺陷得不到重视—用户拿到一个Beta版，意见最大的就是安装不上！或者好不容易装好了，却卸载不了，不得不重新安装系统。
我们一帮人吭哧吭哧干活是为了什么？主题是什么？是为了解决用户的问题。用户给项目投资了成千上万，不是为了看到一堆过时的文档。同样，在团队成员之间的交流要简明，不必为了交接而搞出许多文档。另外一个重要的因素是，如果团队在整个软件生命周期都使用团队协作服务器（TFS），那么很多活动、决定、文档都自然地记录在TFS上，不必额外去为了文档而再写一些东西。
MSF也支持CMMI 的开发模式
CMMI是英文Capacity Maturity Model Inte-grated（能力成熟度模型集成）的缩写
CMMI是CMM模型的最新版本，资料显示，如果一个项目的管理达到了CMMI较高的等级，那么项目的质量与按期完成率都会有较大的提高。
CMMI虽然源于美国，但在世界各地得到了广泛的推广与接受，特别是和外包服务相关的软件企业（例如印度）。
但是要注意的是，众多新兴的小企业，特别是互联网企业，并没有多少采用CMMI来指导软件开发。
在MSF中，CMMI 在所有的流程上都加了一个“提议”（Proposed）阶段，通过“审核”或者决定“开始调查”，处于“提议”阶段的工作项可以变为“激活”状态。如果调查的结果不是要开始着手工作，那么工作项可以退回到“提议”状态。以缺陷类型
标签：comm href 新项目 特定 鼓励 阶段 经验总结 任务 联网
原文地址：http://www.cnblogs.com/ziyixuedie/p/6398080.html
