清晰的责任和共同的职责

    测试一下大家对这点的理解，如果你的团队中出现这样的问题，这样处理是否合适？

    项目进度推迟、项目预算超出计划，公司领导把项目经理叫去，严厉的批评了一顿，而没有责备过任何其他项目成员。

    软件发布出去后，发现严重的缺陷，公司领导把测试人员叫去严厉批评，也没有责备过任何其他项目成员。

    你们的团队中，有没有这样的情况:

    只有项目经理为项目的进度、预算劳心劳累，其他人都在“安分”地完成“本职”工作，不会主动过问其他情况。

    出现问题时，谁是问题责任人的皮球会被踢来踢去，没有人愿意承担责任。

    为什么有这样的问题呢？应该如何处理呢？是责任定得不够清晰吗？

    团队的每一位成员，肩负起自己所在领域的责任，团队的每一位成员共同对最终解决方案负责，同时鼓励小组成员对非他们直接负责的领域作出评论和贡献。

    软件开发团队中，有项目管理、需求分析、设计、编码、测试等各个领域的人才，每领域的负责人对自己的工作负责。

       另外一个方面，软件是团队共同劳动成果，所有人对最终的解决方案负责，最终解决方案只要有问题，就是整个团队的责任，最终解决方案取得优异成绩，就是整个团队的功劳。软件开发团队，是一个“一荣俱荣、一损俱损”的团队，只有这样才能把全部人的利益扭在一起。

    了解了微软的这个原理后，大家对前面提到的问题是否有了答案？

    关注交付的业务价值

    客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子。看上去可笑，但这样的情况却经常发生在我们的身边。关注交付的业务价值，意思就我们工作中的每一份工作产品，都应该是需求驱动做出来的，这样才能保证我们最终做出的软件就是客户所需要的东西。这个原理有以下几层意思:

    ◆小组成员要对客户的需求有一致的充分的理解;

    ◆要让客户积极参与到项目过程中去，随时了解小组的理解和客户的需要是否一致;

    ◆需求驱动地完成所有工作，保证最后的软件产品符合客户的需要。

    保持灵巧，预测变化

    软件是智力型创造性活动，保持灵活、适应变化是软件开发的最高境界了，笔者认为这条原理是最难把握的一条了。

    这个原理主要体现在以下方面:

    软件开发过程

    微软采用的不是RUP，也不是XP，而是类似于螺旋形的阶段式分版本发布。微软会把软件分成若干的版本发布，除了平时我们见到的Beta版、Release版，其实在Beta版之前还会有若干的内部版本。

    每个版本都包含相对完整的功能，都能实现部分业务价值。每一个版本就是一个开发周期，每个周期包含远景、计划、开发、稳定、部署五个阶段。这样的一种开发模型，能很好地适应需求变化，发现设计、编码缺陷，优化设计，更容易控制软件质量，便于随时做出商业决策。

    设计方案

    执着于优雅设计的人士，可能很喜欢做出完美无缺的设计，关注于业务的人士，可能更关注于尽快要拿出软件。我们追求的是适度设计，而不是过度设计，如何做出一个简单的而又适应变化的设计，是对软件设计高手们的一大考验。

    质量投资

    “质量第一”是很多软件公司的口号，而且仅仅是口号而已，你们的项目有这样的一些问题吗？

    代码没有经过简单的冒烟测试，甚至不进行是否通过编译的测试，就直接提交。

    为了赶时间不写设计或者写了不能指导编码的设计文档。

    开发进度推迟，测试时间被压缩，为了保证软件发布的时间，在不充分测试情况下交付软件，更甚者不测试软件，直接让客户测试。

    开发过程中发现的问题，只要能不解决的就不解决，进度优先！

    测试中发现的易用性方面的缺陷，因不会严重影响使用，一律不解决！

    质量投资要求我们有零缺陷的意识，零缺陷意识要贯穿在全部的工作中，包括:

    零缺陷文档

    计划、需求、设计等开发过程中产生的文档，要用一次写好的决心来编写，所有文档都应该发挥它的价值，而不是为了写文档而写文档。要让相关的小组成员对该文档发表意见，重视他们的意见并修改文档。

    零缺陷代码

    要用一次把代码写好，不让测试发现缺陷的态度来写好代码，写出垃圾代码是不负责任的行为。

    零缺陷发布

    用质量投资的态度对待所有缺陷，包括自己代码产生的缺陷，对用户负责，不满足质量要求的软件坚决不发布。

    全体小组成员都应该同步达到零缺陷里程碑，本着一步一个脚印、不断追求高质量的态度来完成全部工作。

    学习所有的经验

    象Windows这样的一些伟大的软件，都是经过很多人通过很长的时间做出来的，工作量之大、难度之大不亚于一些伟大的建筑工程。软件工程与建筑工程最大的优势就是，如果软件做得不好，可以推倒重来，但建筑工程就不能这样做了。

    我拿软件工程与建筑工程比较，目的就是想强调做软件是很强调学习的，很强调不断改进的（当然建筑工程也重视学习）。我们应该庆幸，我们这些做软件的要比做建筑工程的要幸福的多了，我们不太可能犯一些不可以弥补的错误。

    我们要让大家从自己或者别人的失败和成功中学习，要帮助小组成员再次获得成功，捕捉和共享技术的或者非技术的非常好的实践，并想办法让学习制度化。

    学习制度化的办法很多，如项目总结、例会等，但要注意的是学习应该是随时进行的，抱着学习一切可以学习的态度来工作。

    微软的项目团队结构

    谈了微软MSF的八大基本原理，我们来看看，微软的团队是怎样组成的？

    很多软件公司的开发团队，大部分是由一名项目经理，若干项目成员组成，项目成员包括需求分析、架构设计、编码、测试等角色。

    而微软的团队非常特别是没有项目经理的，由6类角色组成，分别是产品经理(Product Management)、程序经理(Program Management)、开发(Development)、测试(Test)、发布管理(Release Management)、用户体验(User Experience)。

    各类角色负责的职责如表1所示。

    微软的团队模型中的6种角色，不代表团队最少要6个人组成，一个人可以兼任多种角色，也不代表每一种角色只有一个人，可以多个人公担一个角色。

    微软这种团队结构与我们常见的团队结构相比，有这样的特点:

    扁平对等的团队结构，强调每个人的价值。这种团队结构，是“赋予小组成员权力”、“清晰的责任和共同的职责”、“推动开放式沟通”这三个原理的表现。这样的结构，让每位小组成员都感受得到自己的重要性，项目的成败与每位成员直接相关。这样的结构更容易调动每位成员的工作积极性，更容易让团队激发工作热情，产生更多的创造性成果。

    微软很重视的我们常会忽略的用户体验和发布管理

    微软团队的6种角色所负责的工作，覆盖了软件开发中需要考虑的各个方面，用户体验、发布管理是常被我们忽视的地方。微软软件的用户体验都非常好，规范一致的界面，详细的帮助系统，良好易用的安装程序，良好的技术支持等。微软创造了很多界面规范，操作习惯，这些都是我们需要认真去学习的。

    知识管理

    软件开发团队是知识密集型的团队，学习再学习，是软件开发团队的重要特点。没有学习的团队，是没有活力的！

    如何保证团队的每位成员都具备完成本项目的能力呢？就绪管理就是来解决这个问题的。

    小组成员的6种角色，需要不同的技能来完成本职工作，任何一种角色技能的欠缺，都会影响最终解决方案。小组应该根据项目的前景，列出各成员所欠缺的技能，这些技能包括技术方面的也包括非技术方面的，安排相应的学习计划、培训计划，保证每位成员的技能都达到要求。

    就绪管理是知识管理的重要组成部分，知识管理还包括知识的共享和积累、技能的评估、技能提升机制等。从微软提供的系列认证，如MCSD、MCP等，大家就可以感受到微软系统的培训制度。

    项目团队的知识管理，应该在组织层面上进行，跨越项目组进行，每位团队成员都可以学习其他团队的经验，每位团队成员都可以共享知识给其他的团队。

    MSF是灵丹妙药吗？

    2000年我第一次参加MSF课程的时候，给我很大的震撼，微软的团队管理很有学问，而很切合我们这些软件开发人员的心声。MSF的团队管理办法，似乎就是解决我们开发团队管理问题的灵丹妙药。但实际上没有这么简单，这种管理办办法要成功，还必须满足这样的条件:

    必须要有坦诚、积极、向上的企业文化。

    没有这样的文化，什么“推动开发式沟通”、“质量投资”等原理是难以做到的。

    团队中每一位成员都是能力相当水平相当的，没有素质特别差的成员。

    这点做不到，是很难应用“为共同的前景工作”、“赋予小组成员权力”等原理的。

    实际上这两点都是很难做到的，微软是通过招聘优秀的人来满足这两个前提条件，另外美国文化下成长的软件开发人员，都是很有主见，沟通很主动，表达能力强，也注重自我价值的，而我国开发人员，很多是少说话多干事，表达能力特别是书面表达能力差的。

    当然难做到不代表做不到，MSF的团队管理中有很多值得我们学习、品味、实践的地方，我们要做的是掌握其精髓，结合我们自己的实际情况，灵活地用起来。本文结合我多年实践MSF经验，谈了自己的体会，希望对大家有用。