微软用特性小组组织产品开发，这种方法使得每个人都容易明白小组是如何与整个产品相关联的。项目从规定概要说明开始。概要说明的形式是一份已确定了优先级安排的内容清单，涉及产品下一版本将要开发的相对独立的特性，以便由分开的特性小组加以开发。
程序经理和开发员把项目分成特性子集，再将之分配给每个特性小组，让他们在3到4个主要的内部项目里程碑中进行生产。这种产品组织与开发方法使微软能靠简单地增加开发员和创建一个大的小组来渐进地增加产品的功能。
把特性(与函数)作为开发单位
微软软件产品的特性是用户最终可见的相对独立的功能单位，就如建筑材料一般，对应用软件产品更是如此。系统软件产品，如NT或者95的特性，对最终用户通常不直接可见。微软和其他公司有时简单地称这些不直接可见的特性为“函数”。
程序经理承担开发一组特性或函数，实现从说明经测试、文档化直到最后完成的过程。他们必须与开发员合作，后者负责估计进度表与完善每个特性。开发员还要在一台联网开发计算机上存储一到几个文件，用以保存特性的程序源代码。大多数特性的开发与改进只要一名开发员，而有的大型特性则要一个小的小组。
产品结构是决定其长期结构完整性的基石
产品结构是产品内部的基干，它规定了重要的结构构件以及这些构件如何组装到一起。产品结构及用于组装结构的构件，提供了实现产品特性(即做详细设计与编码)的支柱。产品的结构对最终用户而言，通常并非直接可见。只有结构要实现的特性是可见的。产品结构也是决定产品长期结构完整性的基石。产品功能的任何改变都不应造成潜在的产品结构散架。
产品的层次结构
对于产品，也可以采用层次结构的方法加以分析。通常定义良好的层次结构有助于对产品特性进行灵活的增加、删除与改进。此外良好的层次结构有助于产品在不同平台上的移植。(例如Excel总共定义了五层，其中只有最底层的操作系统层是与平台相关的，其它各层均是通过调用其下层所提供的API接口加以实现的，所以其移植极其方便。而在Windows 95中通过“虚拟机”的概念实现了对16位、32位以及DOS程序的支持。)
小的结构文档：源代码是唯一文件
除了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)与文档，制作之前，还需要进行各种严格的检查：如政治敏感性术语检查、病毒检查、文件相关性检查等。 
更多内容请看常用软件加密宝典、杀毒软件专栏、软件插件专题，或进入讨论组讨论。
相关专题
- 常用软件加密宝典 (7851篇文章)
- 杀毒软件专栏 (7154篇文章)
- 软件插件 (7484篇文章)
- Wlan组网----家庭专题 (4184篇文章)
- 最新数据结构(试题）习题解答 (10493次浏览)
- 《数据结构》试题下载2004 (6688次浏览)
- 数据结构自测试题(节选章节) (5507次浏览)
- Linux系统的硬件驱动程序编写原理 (4647次浏览)
- 搭建Ruby on Rails开发环境 (4333次浏览)
- 2000年试题集锦（下半年）数据结构试题 (4069次浏览)
- Solaris 10 安装及SVC管理及X及Vmware及其 (3781次浏览)
- 网游外挂编写完全攻略 (3754次浏览)
- 《数据结构》教学大纲--入门必看 (3607次浏览)
- UML业务建模实例分析 (2941次浏览)
