小的结构文档：源代码是文件 
　　除了API文档，微软不对其产品结构生成相应的文档，虽然有时高级开发员可能会写下高层结构。对复杂的特性，许多开发员在某些点记录并复查特定于他们所负责的结构细节，但此工作是可选的，并不强制执行。除了源代码文件与特性说明，为数不多的组为新程序员准务了描绘某层结构的文档（主要的数据结构，如何工作等等）。但是这些文件并不时常更新，经理们也不要求项目组生成此类内部文档。在有关的说明文件中，并不涉及实现问题。开发员应该知道如何去实现，或者能够去学会。记录的关于结构的文档如此之少是因为“一个开发员的工作是编写我们要卖的代码，而不是花时间写高水平的设计文件”，“设计文件不应与源代码分离”。分割代码与“保持事情的简单”。

特性小组和作为"内容专家"的小组领导 
　　特性小组一般由一个领导和3至8名开发人员组成，工作于相关的特性领域。小组的规模常常视小组领导的经验和能力而定。特性小组领导向项目开发领导汇报并负责项目的全部开发工作；而项目开发领导则拥有对产品的更为全局性的观点，从而有可能发现不互相关联的问题。在特性小组中的每个人均是此领域的“专家”，他们了解如何使用产品、了解竞争对手的产品、了解未来将向何处去。通常为便于交流，提高软件的组织结构（软件倾向于映射出构造它的组织的结构），应保持特性小组的小规模。

原则五：靠个人负责和固定项目资源实旋控制

　　对于软件项目而言，精确估计产品的开发与交付进度是很困难的。对此微软采取的方法是将进度安排和工作管理的责任推到底层，即单个的开发人员和测试人员那儿去。这保证了每个人除了作为小组的一部分外，还负有个人的责任。单独的开发人员设立他们自已的进度表，程序经理把单独的进度表汇总起来，再加上缓冲时间，以制定出一个全面的项目进度表。顶层的总经理也固定人员与时间等基本资源，以确保项目集中并限制其努力与创造程序。

　　关键的目标，尤其对应用软件，是指明产品的目标出品日并争取尽可能长久地坚持它。程序经理和开发员从出品日回溯，规定中间的项目里程碑的日期。这个“固定的出品日法“的中心在开发员身上。以避免因为项目没有固定的结束点，导致在终无用的设计、再设计和测试的循环中消耗一年或更多的时间。

开发人员做出他们自已的进度估计 
　　“日期设定方法"。但是开发人员一般会做出较乐观的估计，因此开发经理还需对他们所提供的日期进行调整并加上缓冲时间以避免因因信息不完全而出现的问题。微软这种制定进度的方法的优点在于：它从人们那儿得到更多的合作，因为日期是自已定的，不是经理定的；进度总是富有进取性，因为开发人员不可避免地会低估他们真正需要的时间。

对细致的任务的进度估计 
　　微软的第二个进度安排方法是：对要完成的任务做非常详尽的考虑，在此基础上请开发人员给出他们对“实现”的估计，以此力图“促使”更加现实主义并避免过度低估。

　　通常微软把任务细化到4小时（半天）到3天之间。对于准确进度的安排，微软的经理是这样认识的：“任何任务只要超过一星期，那人们一定没有充分地全盘考虑它。任何任务某人估计只用少于半天可完成，则他对它考虑得太多了。他应该用更多的时间去编程，更少的时间来考虑”。对于类似类于Windows NT之类的操作系统而言，进度安排更加困难，对其一般以几天或者半周为工作单位进行进度估计。

安排开发人员与小组进度时的心理学 
　　当项目变大时，微软把员工分成小组。然后经理把进度的责任和所有权尽可能地分发下去，直到小组和个人；这使二者都产生了一种拥用工作的感觉。它还在小组中，个人中，尤其是小组领导中造成强烈的跟上其它同事预计进度的压力，因为经理可能再平衡进度，从落后的小组或个人手中拿走工作。这样，同事间的压力使经理不需要太多的努力可以对个人或单个小组的进程实施严格控制。

"固定的"出品日(　RTM: Release To Manufacture) 
　　为了把创造力约束在时间限制之中，微软现在在新产品或者产品新版本开始前争取固定出品日，至少是有出品日的内部目标。这给人们施加砍去特性和集中在一个项目上的压力，逼迫他们去苦苦思考应将哪个新特性加入产品中。虽然终产品的交付目标可能是由高级执行人员设定，但是开发人员与小组仍然设定他们自已的进度表。

　　微软一般根据预先的时间进度的大致估计出一个RTM日期，然后向前回溯相应的各个Milestone日期，如RC、Beta、Tree Lock、UI Freeze、Feature Complete以及CC（Code Complete）等等各个Milestone的相应日期。制定出十分详尽的产品研究开发时间进度表，产品开发组的各个成员以这个进度表为目标统一协调工作。微软十分强调软件开发过程中的Teamwork Spirits，这种理念贯穿在微软各个产品开发的各个阶段。这也是微软得以成功的一个十分重要的原因。

小结：同步－稳定开发法

计划阶段 
定义产品的想象性描述、说明与进度

想象性描述 产品和程序管理部门运用广泛的顾客意见来确定和优化产品的特性。 
说明文件 基于想象性描述，程序管理部门与开发组定义特性的功能，结构问题，以及各部分间的相关性。 
制订进度表与构造特性小组　其于说明文件，程序管理部门协调进度表，安排出特性小组，每个小组包括大约1名程序经理，3 - 8个开发员，3 - 8个测试员(以1:1比例与开发员平行工作。) 
开发阶段 
用3 - 4个顺序的子项目，每个产生一个里程碑式的产品发送，来完成特性的开发。程序经理协调开发过程。开发员设计、编码、调试。测试员与开发员配对，不断进行测试。

子项目1 前1/3的特性：重要的特性与共享的构件。 
子项目2中间1/3的特性。 
子项目3后1/3的特性：不重要的特性。 
　

稳定化阶段 
全面的内外部测试，后的产品稳定化以及发货。程序经理协调OEM与ISV，监督从顾客得到的信息反馈。开发员进行后的调试与代码稳定化。测试员发现并清除错误。

内部测试 公司内部对整个产品做详尽的测试。 
外部测试 公司外在的"β"测试点，象OEM，ISV以及终用户处对整个产品做详尽的测试。 
发货准备 为批量生产准备发布后的“金盘”（Golden Disk）与文档，制作之前，还需要进行各种严格的检查：如政治敏感性术语检查、病毒检查、文件相关性检查等。