hello，同学们，同胞们，同志们，同龄们，这样们，那样们，们们们，我又回来写“论文”了，半年时间没见我发布任何博文，是不是认为我被潜规则了啊，哈哈。我想死你们了。好了，废话不多说，进入今天主题：
你的软件开发团队有这样的一些问题吗: 日程安排一团糟、功能不合适、到处都是系统错误，而原因就是左撇子不知道右撇子在做什么，一想到要出下一个版本，就觉得头晕想吐，神出鬼末的缺陷，杀之不尽的缺陷，无止境的加班，对计算机完全失去兴趣，萌生转行的念头。
……
在谈软件开发团队之前，我们先看看优秀的团队，都具备怎样的一些特点？
-
- 英明的领袖
- 优秀的个人
- 严明的纪律
- 良好的沟通
- 一致的目标
- 协调的行动
- 良好的团队氛围
- 良好的习惯
（更多的优秀特点请参阅PMBOK）
-- 您的团队有这样的特点吗？
MSF，全称是Microsoft Solution Framework，微软解决方案框架（模型），不是什么技术框架，而是微软进行研发活动的方法论。微软的研发团队是让人羡慕、让人关注的团队，微软的研发团队是如何工作的？本文我们来一起探讨一下。
原文链接在此：https://docs.microsoft.com/en-us/previous-versions/tn-archive/bb497060(v=technet.10)
下载链接在此：https://download.microsoft.com/download/2/3/f/23f13f70-8e46-4f44-97f6-7dfb45010859/MSF_v3_Overview%20Whitepaper.pdf
虽然这个框架（模型）是微软十几年前（2004年）的产物了，但很多模式和思维，都被不少团队管理进行学习和研究，或者，你的一套管理论中就有他，请继续往下看。
MSF的八大原理
软件开发团队管理有自身的特殊性，它更强调：
-
- 激发大家的潜能和创意。
- 让每一位成员有机会成为“牛人”。
- 充分发挥“牛人”的作用，并让牛人和其他团队成员和谐地工作。
- 让每位成员投入到创造性的工作中，享受成功的愉悦。
软件开发团队是一个种很特别的团队，很容易形成群众领袖，这种领袖并不是公司任命的，而是在实际工作中通过突出的工作表现，在所有成员的心目中自发形成的，这些人就是我们常说的“牛人”，这些牛人是最让公司又爱又恨的人了，如何让管理好这些牛人，如何让牛人们和谐地工作，这是软件开发团队管理的一大难点。微软可以说是牛人如云了，微软的团队管理有什么秘密呢？
微软的MSF有以下八大基本原理：
一、开放式沟通(Foster open communications)
The MSF Process Model enables an open and free flow of information among the team members and key stakeholders to prevent misunderstandings and reduce the probability that work will have to be redone. Documenting the progress of the project and making it available to the team members, stakeholders, and customers can best achieve this.
几乎90%的团队问题，都可以归结为沟通问题，“沟通管理”已经成为团队管理中最泛滥的一个词语，“开放式沟通”具备以下的特点：
-
- 即时、主动：沟通时马上进行沟通，感觉到有问题时马上进行沟通，事后诸葛亮是为人所不齿的。
- 有效：最直接最有效的方式沟通，抓住要害，准确表达，尽量简短。
- 形式多样：尽可能多的最合适的方式沟通，面对面谈话、邮件、msn、QQ等，哪种方式最有效最直接，就用哪一种。
- 参与：人人参与，人人都要主动沟通，同时也要主动去和每一个人沟通。团队每一位成员都参与到每一个活动中。
- 包容：聆听各方面意见，鼓励不同意见。
- 直接、坦诚：不需要拐弯抹角，不需要诸多粉饰，用最直接最坦白的话来表达。
- 对事不对人：戴有色眼镜看人，所有的沟通都是为了把事情做好。
二、为共同的愿景而工作(Work toward a shared vision)
The MSF Process Model provides a phase (the Envisioning Phase) and a separate milestone (Vision/Scope Approved) for creating a shared vision. A vision includes detailed understanding of the goals and objectives that the solution needs to achieve. A shared vision highlights the assumptions that the team members and customers have for the solution.
简单的说就是大家的目标要一致，并一起为这个共同的目标努力工作。所有伟大的软件必定有一份宏伟的愿景文档，该文档描述了软件将会带来什么社会价值、经济价值，开发本软件的目的是什么，本软件应用的范围、领域，本软件能解决什么业务问题，本软件有什么特性等等。如果达不到以下任何条件之一，都不能算“为共同的愿景”工作：
-
- 这个愿景是大家一起来制定并一致通过的；
- 团队中的任何一个人在任何时候都能清晰地说出本项目的愿景的大致内容。
- 用愿景来指导工作，明确工作的重点，明确工作的方针，用愿景来解决工作中的分歧。
很多人都会喊团队需要有一致的目标这样的口号，能不能做得到？以上三点就是检验的标准。
三、授权团队成员(Empower team members)
Empowering the team members implies that the members accept responsibility and ownership of work assigned to them. Team empowerment can be achieved by preparing schedules where the team members commit to complete their work on a fixed date. This makes the team members feel accountable and also provides a method for identifying any potential delays early in the project.
“在最优秀的小组里，不同的个人会在不同场合下体现出其领导能力，他们会在其专长的领域里担负起领导职责。没有哪个人是永远的领导，因为如果这样的话，这个人就无法和其他人融为一个整体，而小组的互动会因此而开始分裂。小组的结构应该是一个网络型的而不是一个层次型的。”
据我们所知，微软的团队是没有固定的领导的，因为任何人都是领导，每位成员都有不可替代的作用，每位成员在自己专长的领域中担当领导的作用。
四、建立清晰的责任和共同的职责(Establish clear accountability and shared responsibility)
The MSF Team Model is based on the principle that each role is accountable for the quality of the solution. All the team members share the overall responsibility of the project because the project can fail due to a mistake made by a single member.
测试一下大家对这点的理解，如果你的团队中出现这样的问题，这样处理是否合适？
- 项目进度推迟、项目预算超出计划，公司领导把项目经理叫去，严厉的批评了一顿，而没有责备过任何其他项目成员。
- 软件发布出去后，发现严重的缺陷，公司领导把测试人员叫去严厉批评，也没有责备过任何其他项目成员。
你们的团队中，有没有这样的情况？
- 只有项目经理为项目的进度、预算劳心劳累，其他人都在“安分”地完成“本职”工作，不会主动过问其他情况。
- 出现问题时，谁是问题责任人的皮球会被踢来踢去，没有人愿意承担责任。
为什么有这样的问题呢？应该如何处理呢？是责任定得不够清晰吗？
团队的每一位成员，肩负起自己所在领域的责任，团队的每一位成员共同对最终解决方案负责，同时鼓励小组成员对非他们直接负责的领域作出评论和贡献。
软件开发团队中，有项目管理、需求分析、设计、编码、测试等各个领域的人才，每领域的负责人对自己的工作负责。另外一个方面，软件是团队共同劳动成果，所有人对最终的解决方案负责，最终解决方案只有有问题，就是整个团队的责任，最终解决方案取得优异成绩，就是整个团队的功劳。软件开发团队，是一个“
一荣俱荣、一损俱损”的团队，只有这样才能把全部人的利益扭在一起。
了解这个原理后，大家对前面提到的问题有答案了没有？
五、专注业务的价值(Focus on delivering business value)
The solution must deliver value to the organization in the form of business value. This business value is achieved only after the solution is completely deployed into the production environment.
客户需要的是一把梯子，产品分析并设计的是一张凳子，开发人员做出来的是一张桌子，测试人员却以为是一张椅子。看上去可笑，但这样的情况却经常发生在我们的身边。
专注交付的业务价值，意思就我们工作中的每一份工作产品，都应该是需求驱动做出来的，这样才能保证我们最终做出的软件就是客户所需要的东西。这个原理有以下几层意思：
-
- 小组成员要对客户的需求有一致的充分的理解。
- 要让客户积极参与到项目过程中去，随时了解小组的理解和客户的需要是否一致。
- 需求驱动地完成所有工作，保证最后的软件产品符合客户的需要。
六、保持灵巧，拥抱变化(Stay agile, expect change)
MSF assumes that the solution will encounter continuous changes before being deployed to the production environment. The team should be aware and prepared to manage such changes.
expect change，确切的翻译应该是期待变化，但是“期待”的不是主动的，而是被动的，就像我期待物价不要上涨，但结果还是会上涨。正好我前几个月在何师烧烤驻场的时候，看到过他们的警示语：“拥抱变化”，
拥抱这个词，是主动的，是积极的，正如回到物价的问题上，明知要100%会上涨，已经无法改变的事实，那么不干脆接受他，积极的拥抱他。换一种说法，我们怀着积极的心态去拥抱他的变化，对他的变化提出可行的解决方案，这才是我们作为项目管理者应该要做的。
软件是智力型创造性活动，保持灵活、适应变化是软件开发的最高境界了！我感觉这条原理是最难把握的一条了，至今都是非常难于把握。这个原理主要体现在以下方面：
软件开发过程
微软采用的不是RUP，也不是XP，而是类似于螺旋形的阶段式分版本发布。微软会把软件分成若干的版本发布，除了平时我们见到的Beta版、Release版、RTM版，其实在Beta版之前还会有若干的内部版本。每个版本都包含相对完整的功能，都能实现部分业务价值。每一个版本就是一个开发周期，每个周期包含愿景、计划、开发、稳定、部署五个阶段。这样的一种开发模型，能很好地适应需求变化，发现设计、编码缺陷，优化设计，更容易控制软件质量，便于随时做出商业决策。
设计方案
执着于优雅设计的人士，可能很喜欢做出完美无缺的设计，关注于业务的人士，可能更关注于尽快要拿出软件。我们追求的是适度设计，而不是过度设计，如何做出一个简单的而又适应变化的设计，是对软件设计高手们的一大考验。
七、投资质量(Invest in quality)
In MSF, each team member is responsible for the quality of the solution. To confirm the quality throughout the project's duration, a test team is formed. This ensures that the solution meets the quality level of the stakeholders.
“质量第一”是很多软件公司的口号，而且仅仅是口号而已，你们的项目有这样的一些问题吗？
-
- 代码没有经过简单的冒烟测试，甚至不进行是否通过编译的测试，就直接提交。
- 为了赶时间不写设计或者写了不能指导编码的设计文档。
- 开发进度推迟，测试时间被压缩，为了保证软件发布的时间，在不充分测试情况下交付软件，更甚者不测试软件，直接让客户测试。
- 开发过程中发现的问题，只要能不解决的就不解决，进度优先！
- 测试中发现的易用性方面的缺陷，因不会严重影响使用，一律不解决！
质量投资要求我们有零缺陷的意识，零缺陷意识要贯穿在全部的工作中，包括：
-
- 零缺陷文档：计划、需求、设计等开发过程中产生的文档，要用一次写好的决心来编写，所有文档都应该发挥它的价值，而不是为了写文档而写文档。要让相关的小组成员对该文档发表意见，重视他们的意见并修改文档。
- 零缺陷代码：要用一次把代码写好，不让测试发现缺陷的态度来写好代码，写出垃圾代码是不负责任的行为！
- 零缺陷发布：用质量投资的态度对待所有缺陷，包括自己代码产生的缺陷，对用户负责，不满足质量要求的软件坚决不发布。
全体小组成员都应该同步达到零缺陷里程碑，本着一步一个脚印、不断追求高质量的态度来完成全部工作。
八、学习所有的经验(Learn from all experiences)
MSF states that the experiences derived from one project should be used and shared with teams in other projects. These experiences can also help to identify the best practices that should be followed in your organization.
像Windows这样的一些伟大的软件，都是经过很多人通过很长的时间做出来的，工作量之大、难度之大不亚于一些伟大的建筑工程。软件工程与建筑工程最大的优势就是，如果软件做得不好，可以推倒重来，但建筑工程就不能这样做了。
我拿软件工程与建筑工程比较，目的就是想强调做软件是很强调学习的，很强调不断改进的（当然建筑工程也重视学习）。我们应该庆幸，我们这些做软件的要比做建筑工程的要幸福的多了，我们不太可能犯一些不可以弥补的错误。“那些忘记过去的人肯定会重复过去（的错误）。”
我们要让大家从自己或者别人的失败和成功中学习，要帮助小组成员再次获得成功，捕捉和共享技术的或者非技术的最佳实践，并想办法让学习制度化。学习制度化的办法很多，如项目总结、例会等，但要注意的是学习应该是随时进行的，抱着学习一切可以学习的态度来工作。
微软的项目团队结构
谈了微软MSF的八大基本原理，我们来看看，微软的团队是怎样组成的？
很多软件公司的开发团队，大部分是由一名项目经理，若干项目成员组成，项目成员包括需求分析、架构设计、编码、测试等角色。
而微软的MSF团队定义非常特别，他们是没有项目经理（实际Program Management 就是 Project Management）的，由6类角色组成，分别是产品经理(Product Management)、程序经理(Program Management)、开发(Development)、测试(Test)、发布管理(Release Management)、用户体验(User Experience)。
| 角色 | 目标 | 职能领域 | 职责 |
| 产品管理 | 满足客户 | 市场开发 业务价值 客户拥护 产品计划 |
为项目小组充当客户角色 驱动共同的项目和方案设想 管理客户需求说明 开发和维护业务案例 管理客户期望 驱动产品特征、日程表、资源权衡决策 管理市场开发、产品宣传和公共关系 开发、维护和执行交流计划 |
| 程序经理 | 交付满足项目约束的解决方案 | 项目管理 解决方案体系结构 过程保证 管理服务 |
驱动开发过程以期按时的交付产品 管理产品规格说明书 － 首席项目构架师 促进小组内部的交流和商议 维护项目日程表和报告项目状态 驱使关键的权衡决策的实现 开发、维护和执行项目总规划和日程表 驱使和管理风险评估和风险管理 |
| 开发 | 根据规格说明创建解决方案 | 技术咨询 实现的构架和设计 应用程序开发 基础结构开发 |
指定物理设计的特征 估算完成每个特征所需的时间和精力 构建每个特征并监督其实现 准备部署时使用的产品 为小组提供技术主题的专门知识 |
| 测试 | 在所有产品质量事宜被识别并处理后进行发布 | 测试规划 测试工程 测试报告 |
确保了解所有问题 决定测试策略和制定计划 执行测试 |
| 用户体验 | 提高用户效率 | 技术交流 培训 可用性 用户界面设计
国际化 易用性 |
为项目小组充当用户的角色 管理用户需求说明 设计和开发性能支持系统 驱动可用性和用户性能增效的权衡决策 为用户提供帮助特点和帮助文档的规格说明书 开展和提供用户培训 |
| 发布管理 | 进行平滑的部署及日常运行 | 基础结构 支持 操作 业务发布管理 |
管理产品部署 驱使可用性和可支持性权衡决策 管理各种操作、支持和交付渠道之间的关系 为项目小组提供后勤支持 |
微软的MSF团队模型中的6种角色，不代表团队最少要6个人组成，一个人可以兼任多种角色，也不代表每一种角色只有一个人，可以多个人公担一个角色。微软这种团队结构与我们常见的团队结构相比，有这样的特点：
扁平对等的团队结构，强调每个人的价值
这种团队结构，是“赋予小组成员权力”、“清晰的责任和共同的职责”、“推动开放式沟通”这三个原理的表现。这样的结构，让每位小组成员都感受得到自己的重要性，项目的成败与每位成员直接相关。这样的结构更容易调动每位成员的工作积极性，更容易让团队激发工作热情，产生更多的创造性成果。
微软很重视的我们常会忽略的用户体验和发布管理
微软团队的6种角色所负责的工作，覆盖了软件开发中需要考虑的各个方面，用户体验、发布管理是常被我们忽视的地方。微软软件的用户体验都非常好，规范一致的界面，详细的帮助系统，良好易用的安装程序，良好的技术支持等。微软创造了很多界面规范，操作习惯，这些都是我们需要认真去学习的。
知识（储备）管理
软件开发团队是知识密集型的团队，学习再学习，是软件开发团队的重要特点。没有学习的团队，是没有活力的！
如何保证团队的每位成员都具备完成本项目的能力呢？就绪管理就是来解决这个问题的。
小组成员的6种角色，需要不同的技能来完成本职工作，任何一种角色技能的欠缺，都会影响最终解决方案。小组应该根据项目的愿景，列出各成员所欠缺的技能，这些技能包括技术方面的也包括非技术方面的，安排相应的学习计划、培训计划，保证每位成员的技能都达到要求。
知识管理还包括知识的共享和积累、技能的评估、技能提升机制等。从微软提供的系列认证，如MCSD、MCP等，大家就可以感受到微软系统的培训制度。项目团队的知识管理，应该在组织层面上进行，跨越项目组进行，每位团队成员都可以学习其他团队的经验，每位团队成员都可以共享知识给其他的团队。
风险管理
MSF团队提倡积极主动的风险管理、持续的风险评估，并在整个项目和运营生命周期内融入风险决策。对风险进行持续的评估、监控和积极的管理，直到风险得到解决。MSF团队风险管理流程定义了六个逻辑步骤，团队使用这些步骤来管理当前风险、计划和执行风险管理策略，以及为企业获取知识。
-
- 识别风险：风险识别的过程要求所有团队成员参与风险的识别，使团队意识到潜在的问题。作为风险管理过程的输入，应尽早进行风险识别，并在整个项目生命周期内频繁重复。
- 分析并确定优先级：风险优先级使团队能够投入项目资源来管理和决策最重要的风险。
- 计划和时间表：风险规划从风险分析和优先顺序中获得，并将其用于制定战略、计划和行动。风险调度确保这些计划得到批准，然后纳入项目管理过程和基础设施，以确保风险管理作为团队日常活动的一部分进行。风险调度明确地将风险规划与项目规划联系起来。
- 跟踪和报告：风险跟踪监控特定风险的状态及其各自行动计划的进展情况。
- 控制：风险控制是执行风险行动计划及其相关状态报告的过程。风险控制还包括当风险状态或风险计划的变化可能导致项目特征、资源或进度的变化时，启动项目变更控制请求。
- 学习：风险学习将从项目中获得的经验教训形式化，收集相关的项目工件和工具，并以可重用的形式获取这些知识。
（感觉这里跟PMBOK差不多）
结语
MSF的团队管理办法，似乎就是解决我们开发团队管理问题的灵丹妙药。但实际上没有这么简单，这种管理办办法要成功，还必须满足这样的条件：
-
- 必须要有坦诚、积极、向上的企业文化。没有这样的文化，什么“推动开发式沟通”、“质量投资”等原理是难以做到的。
- 团队中每一位成员都是能力相当水平相当的，没有素质特别差的成员。这点做不到，是很难应用“为共同的愿景工作”、“赋予小组成员权力”等原理的。
实际上这两点都是很难做到的，微软是通过招聘优秀的人来满足这两个前提条件，另外美国文化下成长的软件开发人员，都是很有主见，沟通很主动，表达能力强，也注重自我价值的，而我国开发人员，很多是少说话多干事（大多是撸起袖子加油干），表达能力特别是书面表达能力差的。当然难做到不代表做不到，MSF的团队管理中有很多值得我们学习、品味、实践的地方，我们要做的是掌握其精髓，结合我们自己的实际情况，灵活地用起来。