又适应变化的设计，是对软件设计高手们的一大考验。
质量投资
“质量第一”是很多软件公司的口号，而且仅仅是口号而已，你们的项目有这样的一些问题吗？
代码没有经过简单的冒烟测试，甚至不进行是否通过编译的测试，就直接提交。
为了赶时间不写设计或者写了不能指导编码的设计文档。
开发进度推迟，测试时间被压缩，为了保证软件发布的时间，在不充分测试情况下交付软件，更甚者不测试软件，直接让客户测试。
开发过程中发现的问题，只要能不解决的就不解决，进度优先！
测试中发现的易用性方面的缺陷，因不会严重影响使用，一律不解决！
质量投资要求我们有零缺陷的意识，零缺陷意识要贯穿在全部的工作中，包括:
零缺陷文档
计划、需求、设计等开发过程中产生的文档，要用一次写好的决心来编写，所有文档都应该发挥它的价值，而不是为了写文档而写文档。要让相关的小组成员对该文档发表意见，重视他们的意见并修改文档。
零缺陷代码
要用一次把代码写好，不让测试发现缺陷的态度来写好代码，写出垃圾代码是不负责任的行为。
零缺陷发布
用质量投资的态度对待所有缺陷，包括自己代码产生的缺陷，对用户负责，不满足质量要求的软件坚决不发布。
全体小组成员都应该同步达到零缺陷里程碑，本着一步一个脚印、不断追求高质量的态度来完成全部工作。
学习所有的经验
象Windows这样的一些伟大的软件，都是经过很多人通过很长的时间做出来的，工作量之大、难度之大不亚于一些伟大的建筑工程。软件工程与建筑工程最大的优势就是，如果软件做得不好，可以推倒重来，但建筑工程就不能这样做了。
我拿软件工程与建筑工程比较，目的就是想强调做软件是很强调学习的，很强调不断改进的（当然建筑工程也重视学习）。我们应该庆幸，我们这些做软件的要比做建筑工程的要幸福的多了，我们不太可能犯一些不可以弥补的错误。
我们要让大家从自己或者别人的失败和成功中学习，要帮助小组成员再次获得成功，捕捉和共享技术的或者非技术的最佳实践，并想办法让学习制度化。
学习制度化的办法很多，如项目总结、例会等，但要注意的是学习应该是随时进行的，抱着学习一切可以学习的态度来工作。
微软的项目团队结构
谈了微软MSF的八大基本原理，我们来看看，微软的团队是怎样组成的？
很多软件公司的开发团队，大部分是由一名项目经理，若干项目成员组成，项目成员包括需求分析、架构设计、编码、测试等角色。
而微软的团队非常特别是没有项目经理的，由6类角色组成，分别是产品经理(Product Management)、程序经理(Program Management)、开发(Development)、测试(Test)、发布管理(Release Management)、用户体验(User Experience)。
各类角色负责的职责如表1所示。
微软的团队模型中的6种角色，不代表团队最少要6个人组成，一个人可以兼任多种角色，也不代表每一种角色只有一个人，可以多个人公担一个角色。
微软这种团队结构与我们常见的团队结构相比，有这样的特点:
扁平对等的团队结构，强调每个人的价值。这种团队结构，是“赋予小组成员权力”、“清晰的责任和共同的职责”、“推动开放式沟通”这三个原理的表现。这样的结构，让每位小组成员都感受得到自己的重要性，项目的成败与每位成员直接相关。这样的结构更容易调动每位成员的工作积极性，更容易让团队激发工作热情，产生更多的创造性成果。
微软很重