关注交付的业务价值

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

小组成员要对客户的需求有一致的充分的理解;
要让客户积极参与到项目过程中去，随时了解小组的理解和客户的需要是否一致;
需求驱动地完成所有工作，保证后的软件产品符合客户的需要。
保持灵巧，预测变化

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

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

软件开发过程

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

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

设计方案

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

质量投资

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

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

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

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

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

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

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

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

零缺陷代码

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

零缺陷发布

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

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

学习所有的经验

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

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

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

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

微软的项目团队结构

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

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

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

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