微软公司软件开发模式简介(上)

微软公司软件开发模式简介(上) 
 
北京大学出版社96年底所出的《微软的秘密》一书是目前我所见到的对微软公司软件产品开发过程介绍的最专业、最深入的一本书。通过本书，我们可以看到微软公司是如何对科学地对软件产品开发进行有效地管理，我想这些经验对于中国的广大软件开发人员，尤其是关心中国软件产业发展的各位朋友是大有益处的。所以特将此书中涉及软件产品开发的部分内容摘录出来（第四章“产品定义与开发过程”），加上我在微软中国工作的实际经验总结出这篇文章，希望与大家共同分享。本文作为摘录，自然是挂一漏万，所以建议大家若有时间还是找来原书一读。 
 
在微软的产品定义与开发过程中，微软软件开发遵循着一种可称之为“靠改进特性（Feature）与固定资源（Resource）来激发创造力”的战略。该战略可分为五个原则： 
 
将大项目分成若干里程碑式（Milestone）的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。  
运用想象描述和对特性的概要说明（Program Specification）指导项目。  
根据用户行为（User Behavior）和有关用户的资料确定产品特性及其优先顺序。  
建立模块化的和水平式的设计结构，并使项目结构反映产品结构的特点。  
靠个人负责和固定项目资源实施控制。  
原则一：将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。 
 
项目进度安排与里程碑  
微软通常采用“同步－稳定产品开发法”。典型项目的生命周期包括三个阶段： 
 
计划阶段：完成功能的说明和进度表的最后制定  
开发阶段：写出完整的的源代码  
稳定化阶段：完成产品，使之能够批量生产（Roll Out）  
这三个大阶段以及阶段间内在的循环方法与传统的“瀑布”（Water Fall）式开发方式很不相同，后者是由需求、详尽设计、模块化的代码设计与测试、集成测试以及系统测试组成的。而微软的三个阶段更像是风险驱动的、渐进的“螺旋”式的生命周期模型。 
 
计划阶段的产品是想象性描述与说明文件，用来解释项目将做什么和怎么做。在管理人员拟定进度表、开发员写出代码之前，这些东西都促进了人们对设计问题的思考与讨论。开发阶段围绕三次主要的内部产品发布来进行；稳定化阶段集中于广泛的内部与外部测试。在整个产品生产周期中，微软都使用了缓冲时间的概念。缓冲时间使开发组能够对付意外的困难和影响到时间进度的变故，它也提供了一种手段，可以缓和及时发货与试图精确估计发货时间之间的矛盾。 
 
在开发和稳定化阶段的所有时间中，一个项目通常会将2/3的时间用于开发，1/3的时间用于稳定化。（Office部门副总裁曾这样概述通常的进度：“一般说来，在总的进度表中，用一半的时间写出产品，留下另一半的时间调试或应付意外事故。这样，如果我有一个两年的项目，我会用一年来完成事先想好的东西……如果事情有点麻烦，我便去掉我认为不太重要的特性。”）。这种里程碑式的工作过程使微软的经理们可以清楚地了解产品开发过程进行到了哪一步，也使他们在开发阶段的后期有能力灵活地删去一些产品特性以满足发货时期的要求。  
 
计划阶段  
计划阶段是在一个项目的生命周期中，所有于开发前进行的计划所占用的时间。计划阶段产生出想象性描述、市场营销计划、设计目标、一份最初的产品说明、为集成其他组开发的构件而规定的接口标准、最初的测试计划、一个文档策划（印刷品和联机帮助形式的）以及一份可用性问题清单（Usability List）。计划阶段从想象性描述开始。想象性描述来自产品经理以及各产品单位的程序经理；它是对规划产品的市场营销设想，包括了对竞争对手产品的分析以及对未来版本的规划。想象性描述也可能讨论在前一次版本中发现面必须解决的问题以及应添加的主要功能。所有这些都基于对顾客和市场的分析以及从产品支持服务组处得到的资料。 
 
说明文件从一个大纲开始，然后定义出新的或增加的产品特性，并对其赋以不同的优先级。说明文件只是产品特性的一个预备性概览；从开始开发到项目完成它要增加或变化20% - 30%。虽然在生命周期的后期说明变化一般较小，但越到后期，开发员就越是必须具充分的理由来作改变。 
 
通常程序经理使用VB创建项目原型。他们也开展设计可行性研究以了解设计中的取舍情况，尽快做出涉及产品说明的决定。对于重要产品的说明需由公司高层领导进行复审。对于不太重要的产品，则由部分经理去完成。  
 
开发阶段  
开发阶段的计划对三四个主要的里程碑版本都逐个分配一组特性，规定出特性的细节和技术上的相关性，记录下单个开发员的任务以及对进度的估计。在开发阶段中，开发员在功能性说明的指导下写源代码，测试员写出测试项目组以检查产品的特性与工作范围是否正常，用户教育人员（User Education）则编写出文档草案。 
 
当测试员发现错误时，开发员并不是留待以后处理，而是马上改正，并在整个开发阶段内使测试不断地、自动地进行。这就改善了产品的稳定性并且使版本发布日期更易估计。当达到项目中的一定阶段点后（40%时），开发员就试图“锁定”产品的主要功能要求或特性，从此只允许小范围的改动。如果在此点之后开发员想作大的改动，他们必须与程序经理以及开发经理进行讨论协商，也许还要征求产品部门经理的意见。 
 
一个项目是围绕着3或4个主要的内部版本，或“里程碑子项目”来组织开发阶段的。一般用2至4个月来开发每一个主要的里程碑版本。每个版本都包括其自身的编码、优化、测试以及调试活动。项目为意外事故保留总开发1/3的时间，即“缓冲时间”（Padding Time）。（苹果公司的小组是割裂的、独立的，各自开发各自的东西。在还有3个月就要发货时，才会将所有的东西集成起来；Borland公司以一种渐近的方式进行开发，即把工作分成许多小的部分，并且总是让开发的东西能够运转。看起来似乎这种渐进的方法费时，但实际上几乎没有用过很长时间，因为这使你总是能掌握住事情真实的情况。） 
 
当对最后一个主要的里程碑版本做了测试与稳定化之后，产品就要进行“外观固定”（UI Freeze），即确定产品的主要用户界面，如菜单、对话框以及文件窗口等。此后有关用户界面将不再进行大的改动，以免引进同步修改相应文档的困难。  
 
稳定化阶段  
稳定化阶段着重于对产品的测试与调试。项目在此阶段尽量不再增加新的功能，除非是竞争产品或者市场发生了变化。稳定化阶段也包括了缓冲时间，以应付不可预见的问题或者延迟。 
 
下面我将Micosoft开发软件的模式用以下这张简图加以描述：（这张图对微软的测试进行了比较详细的描述，我个人认为微软的测试是Microsoft软件产品开发中一个十分重要也是十分有特色的分工。这是通过在微软将近一年的观察和与国内同类企业的分析，我才得出这样的结论。大家都很明白，国内的软件开发商在这方面做得很不够，尤其不重视软件的内部测试，在他们的思想中，可能有一个误区：认为测试应该完全去由用户去负责，其实不然，在软件的开发流程中，软件的测试与开发是一种“矛与盾”的关系，互为补充，缺一不可。在微软，可能这种关系发挥到了极至：有时开发部门与测试部门互相较着劲，开发经理和测试经理的地位是相同的，有时甚至测试经理的地位甚至凌驾于开发经理之上，但他们之间没有根本的利益冲突，只有一个共同的目标：将产品的质量提高。） 
 
补充一点：（对微软的测试流程加以简要的描述一下）微软内部，专门有一个小组负责为微软的工程师们提供日常工作和管理的工具软件，他们是非盈利机构，其主要任务是开发微软内部所需要的工具软件：例如： 
 
SLM(Source Library Tree),源代码管理工具，负责管理软件开发过程中各个程序员的源码，各个程序员负责写自己的模块，每天将完成的代码Check-in到一个中央服务器的SLM树中，这个SLM树由预先定义好的脚本在固定的时间开始编译，通常这个过程需要好几个小时，所以微软内部根据各个项目组的情况有各自的规定：比如开发员必须在下班前（比如下午6：00）之前将当天修改的代码Check-in进去，这样SLM才开始编译。  
第二天，QA组的各个测试员从服务器上下载前一天的一个Build开始测试，将测试的情况及时的反映到另外一个工具软件中：RAID（Raid is a tool for entering, tracking, analyzing, and reporting product defects during development and maintenance.）.这个工具负责管理产品的BUG情况，每个BUG包含很多属性：比如状态（活动的、解决的、关闭的）、严重级、优先级、哪个区域、哪个版本出现的、发现者、要将这个BUG赋给哪一个开发员等等一系列属性。还可以根据这个工具查询哪个开发员当天的BUG活动的、解决的数量，哪个测试员的BUG质量数目等等一些基本的产品质量情况，这样项目经理可以很容易的掌握该项目的具体进展情况。如果在项目的开发中期，发现的BUG数目比解决的BUG数目持续的多（意味着该产品的活着的BUG越来越多），可能意味着这个项目出现了问题，决策者可以迅速的作出相应的决策，及时的纠正产品开发中出现的失误（微软曾经有很多产品因为这样的因素被Cancel了）。还有项目经理可以根据这个工具，及时的掌握、了解每个测试员和开发员的工作状态，这一点很重要。有很多人曾经说过：Microsoft凭借着SLM和RAID打败了无数的竞争对手，通过我在微软的经历，我看这话一点也不假。这两个工具确实是非常杰出的工具，微软将它们使用到了十分艺术的程度上，对微软的成功起着非常重要的作用。更难能可贵的是，目前这些工具在功能上还在不断的进行改进、升级，使得微软的工程师们工作起来更加如虎添翼、虎虎生风，这样的企业哪有不成功的道理?  
在测试过程中，也不是随便的对软件产品毫无目的的瞎使用、乱使用，微软也有一套十分先进的方法和工具支撑着测试的每个方面：比如ATCM(　Access Test Case Management)，一种基于Test Case（测试用例）的测试管理工具就承担着这方面的工作。  
微软也许正是靠着“程序员的聪明和测试员的勤奋”构建起软件帝国的大厦、谱写着软件事业的辉煌。  
 
Product Developing Process in Microsoft  
 
上图中： QA是微软大的产品部门下设的一个比较专业的测试部门（Quality Assurance Dept） 
 
项目进度表中的缓冲时间（Padding Time）  
微软使用缓冲计划，以在最高的效率与较好地对未来作预计之间求得平衡。这种应付突发事件的时间在开发和稳定化过程中是每一个主要里程碑的一部分。缓冲时间主要用于弥补由于对特性（Feature）的不完全理解，或者是技术困难或是由于疏忽而忘记把任务写入进度，或者是未料到的难题而形成的漏洞。缓冲时间有助于一个项目适应意料之外的事件。  
 
原则二：运用想象性描述和对特性的概要说明指导项目 
 
为了给出足够的开发框架以使工作能持续进行，并且能容纳开发过程中出现的变化并保持足够的灵活性，微软采用想象性描述和概要的说明来指导项目开发，而不是在一开始就努力写出一份完整和详细的说明。所谓想象性描述是由程序经理和来自市场营销组的产品计划人员共同编写的一份非常短的文件，在其中主要是定义产品开发的目标（不涉及产品的具体细节！）。通常对一个全新的产品，想象性描述一般会相对较详细，在其中还含有一份粗略的说明文件。总的来说，微软对于想象性描述的要求是： 
 
越短越好，尽量说明"产品不做什么"(而不是"产品要做什么"！)。  
 
运用想象性描述，程序经理开始编写功能说明文件，该文件解释产品的特性是什么以及这些特性如何与其他特性及产品发生关系。最初它只是一个概要性的说明文件，随着项目的进展，程序经理会随时向其中添加更多的细节，最终的说明文件将变得象用户手册一样。完整的说明不只起着对产品最新功能的描述作用，而且它还是在产品投产与发货之前进行测试与评估的主要依据。  
想象性描述有助于决定删除哪些特性。  
微软内的各个开发组采用想象性描述帮助细化产品版本的规定主题，然后以此主题来决定是否需要增加产品各个可能的特性。通常不要轻易改变所确定的主题，否则可能造成产品开发上的混乱。 
 
编写说明文件  
说明文件在产品小组的所有成员之间，产品小组之间以及产品小组与管理部门之间起着传递产品的设想与要求的作用。在说明文件中必须清楚地描述产品特性（描述每个特性如何工作，外观如何以及从用户的角度出发如何与用户交互。如果特性有一个界面，还应包括一张示意图，以显示出界面的效果），并赋于其相应的优先级。程序经理据此建立起项目的开发进度表。此外在其中还应包括以下各项内容：用一句话表示的项目开发目的，关于产品是什么与不是什么的清单，对顾客的定义，对竞争产品的定义，产品对系统的要求（包括操作系统版本、最小内存要求、硬盘空间、处理器速度以及显示器分辩率），对第三方（如打印机驱动程序、组件）的任何依赖性。程序经理负责协调并"写下"说明 
 
程序经理（Program Manager）应考虑以下问题： 
 
这项特性的要点是什么？  
用户如何使用该特性？  
这项特性有意义吗？  
该产品中或微软的其他产品中有类似的特性吗？  
有哪些问题被遗漏了？  
组内的交流令人满意吗？  
最终程序经理通过与组内开发人员的共同讨论决定有关特性的内容，并将其写下来。 
 
构造原型  
构造原型是程序经理具体说明一件新产品或一个新版本的最好方法，这从许多方面来说都使开发前测试成为可能，尤其在可用性方面，并且有助于对与用户交互情况作出好的理解，它也能使产品说明更紧凑。 
 
微软的开发人员通常采用VB构造用户界面原型，但是对于构造计算机屏幕模型之类的工作，画笔（Paint brush）也是一个很好用的工具。死板的说明变成有生命的文件，说明不应过于详细以至限制了发明创造。在项目开发过程中，说明文件的早期版本会有相当大的增加与改变。由于说明的变动可能会导致相应开发工作的极大变动，所以微软通常是将精力首先集中于那些没有什么用户界面的特性上，因为在完成开发前不必去了解用户对它们有何反应，也就是说这些特性不大可能改变。然后再面对其它特性。但是当产品开发到一定程序后，例如40%之后，程序经理必须严格控制对特性的修改（主要是指增加新的特性），否则不光会造成开发延迟，而且会压缩可用的测试时间。