软件开发项目管理

《软件开发项目管理》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

软件开发项目管理的案例解说系列软件开发项目的需求和范围管理-系列(一)引言在今年第一期的程序员杂志中，我对软件开发项目管理的重要性和进行管理的十大工作内容作了一个介绍。你应该已经很清楚地知道今天绝大多数的软件开发已经不是简单地编写一些程序而已，而是一个综合了对多人合作的运作进行必要管理的流程。只要你经历过任何由多人参加的软件开发工作，你一定对整个开发过程是否具有良好的管理对团队的士气以及对开发结果所造成的影响深有体会。一个软件公司或开发团队对软件项目进行管理的素质和水平，是影响到项目是否能够成功完成、开发出来的软件是否能够真正满足市场或客户要求的关键因素。懂得软件开发的项目管理知识不仅仅是项目经理的责任，也是所有开发人员应该掌握的本领之一。从这一期开始，我将在这里用理论与案例解析相结合的一个系列的介绍文章，来阐述软件开发项目管理的更多指南和实践方法。这一期我们从如何进行软件开发需求和范围管理开始，接下来在以后的几期中再分别讨论软件开发项目的计划制定、质量控制、以及项目的执行与驱动的管理指南、等等。常有的项目需求和范围管理的挑战 在软件开发项目进行的早期阶段，项目经理以及开发团队的领导们在制定项目计划时所经常碰到的一个令人头疼的问题是：如何有效地设定一个开发项目的范围，也就是如何确定所需要开发的软件的功能范围、质量的要求范围等各种所必须满足的条件以及相应的工作范围。很多项目管理人员和开发团队的领队往往被这个问题所困惑、无法有效地从大量的、貌似互不相连的各种技术、市场、用户的要求中得出明确的需求总结，从而妨碍了制定完善的项目计划。其实这个问题并不是软件开发所独特具有的。任何大型和复杂的项目、包括各种高科技和工程开发项目，都会面临这个典型的问题。是否能够妥善处理这个挑战、并制定出相应的合理的开发项目的计划，是衡量一个开发团队的管理水准的衡量之一。五年前我在从事微软的新一代嵌入式操作系统(WindowsXPEmbedded)产品开发的项目管理时也碰到同样的问题和挑战：在众多的各种需求中，怎样确定哪些工作是我这个开发项目必须要包含的？怎样保证最主要的需求分析不被漏掉？怎样在开发之前建立整个团队对软件的质量期望的共识、事先确定软件必须达到的质量要求？有效的需求和范围管理的运作流程我们所采用的开发管理方法就是类似于我在《软件开发项目管理》一书中所总结的方法和运作流程来对付这个挑战：1)从需求分析总结确定大方向： 首先，对照任何一个软件开发项目所应该考虑到的九个需求范围的因素，逐步分析和判断这九个因素中对我这个项目影响最大的几个因素是什么、以及每个因素对我这个项目的具体要求，由此确定和总结出所开发的软件产品的功能范围，同时并确定哪些功能是不在这个项目的范围之内。下图是对这九个需求分析的因素的总结：图1：软件开发项目需求管理应该考虑的各种因素根据这个管理指南和原则，我的项目计划的第一步就是首先对所有这些因素进行一个全面的总结，然后把它写在一份“软件需求规范书”(SoftwareRequirementAnalysisSpecification)里。这份项目计划的早期文件然后经过整个开发团队坐在一起像开“诸葛亮会议”一样进行审核，对所有的需求总结进行合理性与可行性的逐条分析和评判讨论，并为每条需求进行重要性与优先权的设定。有的无法可以立即确定的，还得通过开发团队进行必要的技术验证、或向我们的市场营销部门或直接向客户进行调查询问来进一步确证。通过几次这样的审核会议，整个项目团队能够很快对项目的具体目标以及主要的工作任务达到共识。为了方便于该规范书让全体团队成员阅读、并便于在团队审核会议上的逐条讨论，我将这个总结用一个表格将所有的需求分析根据以上需求因素的范围给列出来，作为产品设计规范书的早期内容。这个总结做出来之后，大家就可以逐条审阅和讨论。下面，我用这个项目的历史作为一个案例来举例说明如何制定这些内容 (为了不透露公司的实际产品的开发战略，案例对具体内容作了改动、并用中文说明以便于读者阅读)。以下是这个表格的使用举例：Item条款ProductRequirementAreas:产品需求的范围CommentsorIssues(注解及问题):Priority(优先顺序)1BusinessRequirements(商业需求):AWindowsXPEmbedded(XPE)StudiotoolsTargetDesigner(TD)andComponentDesigner(CD)shallbetheapplicationdevelopmenttoolsuitetoenableembeddeddevicedeveloperstodesignspecialpurposedevicesthatarebasedontheX86platform,andbeabletodevelopembeddedapplicationsondesktopandeasilydeploytodevicesandbootimmediately…视窗嵌入式操作系统的一整套应用开发工具要能够为嵌入式设备开发商们提供一个能够在英特尔X86平台上运行的开发环境，使得他们能够在桌面计算机上使用目前已有的通用型软件开发工具方便地进行嵌入式应用软件的开发，然后很容易地将应用软件安装部署在嵌入式设备、并能够立即启动运行…对这个商业需求所应该达到的要求，需要与市场部门进行协商和确证P1B视窗嵌入式操作系统在开发早期需要能够同时支持来自世界范围的早期应用开发者的样板产品的开发，特别是对６种主要语言的应用软件开发的支持… 对是否需在最初版本的发行时要支持世界范围的各主要语言，需要向营销部门确证。P2C视窗嵌入式操作系统的核心必须是与WindowsXPPro在运行上完全兼容的，任何开发商所开发的应用软件应该都能在XPE的嵌入设备上运行…P2D视窗嵌入式操作系统的开发工具必须满足各小型开发商使用现有开发工具的市场要求，使得他们能够不仅在WindowsXPPro上进行开发，也能够在Windows2000上进行开发…E视窗嵌入式操作系统产品的发行必须通过Windows2000Logo鉴定验证的各种要求，包括产品的初始安装、升级安装、消除等各种要求…:…2Non-Requirements–Standards(非功能需求-标准):A视窗嵌入式操作系统必须满足微软本身在世界范围内产品发行的本地化标准、包括不同文化、政治、地域等因素带来的各种要求，各软件组件本地化翻译必须通过公司的本地化名称检测…P1B开发工具所生成的各种设备接口的驱动组件必须包括支持相关的嵌入式设备在业界的标准，诸如销售记帐器专有的标准、多媒体机顶盒的标准，等等:…2UserRequirements(使用者需求):AXPE产品的开发工具的客户和使用者是那些目前已经在X86平台上进行应用软件开发的开发商。他们对使用开发工具如VisualStudio应该很熟悉，但不见得了解操作系统的所有组件结构，对嵌入式操作系统的要求可能更不熟悉。需要与客户教育部门协商决定对用户的培训的要求以及使用说明书的要求P1 B…3FunctionalRequirements(功能需求):AXPE产品的开发工具为客户解决的第一个最主要的开发问题是：为客户提供一个能够快速、简易地生产基于WindowsXPPro基础上的嵌入式设备所需要的、经过客户个体化了的轻型操作系统。整个生产个体化的轻型操作系统的功能必须要经过对使用方案的确证。见使用方案总结的一章。P1BXPE产品的开发工具为客户解决的第二个最主要的开发问题是：客户要能够方便地加入他们所开发的嵌入式应用软件，然后将整个操作系统的映像部署到嵌入式设备上。加入客户应用软件的功能必须要经过对使用方案的确证。见使用方案总结的一章。P1CXPE产品的开发工具为客户解决的第三个最主要的开发问题是：客户要能够将他们自己的嵌入式应用软件进行模块化的组件生成，使得他们能够有效地控制操作系统映像的大小，满足小型嵌入式设备的生产需要。P1DXPE产品的开发工具应该将开发商进行开发的设计过程用专门的文档储存下来，使得开发商能够很快地一个设计重新载入开发工具，在为不同的设备进行开发时能够很方便地使用已有的类似的设计。P1E…4PerformanceRequirements(性能需求):AXPE产品的开发工具在使用者变换显示界面时不能有超过分之一秒的延迟。P1BXPE产品的开发工具在下载操作系统的组件的数据库信息时，显示列表的刷新的延迟不能超过1秒。P1 CXPE产品的开发工具在生成新操作系统时的总体时间不应超出5分钟，而且必须要有生成进度显示(ProgressBar)。P2E…5QualityRequirements(质量需求):AXPE产品的开发工具在开发阶段必须经过代表软件质量的12个质量属性的测试验证。具体测试要求见测试计划文件。P1B开发工具在发行前必须通过发行的里程碑终点衡量质量标准。具体要求见里程碑终点衡量文件(ExitCriteria)。P1C开发工具所碰到的任何使用错误必须显示于此相关的准确错误信息(ErrorMessage)。所有错误信息必须包括3个部分：出现的具体错误，造成错误的原因，以及如何采取纠正的步骤以消除或避免错误。参见本规范书中对错误信息设计要求的部分。P2D…等等因为篇幅关系，上面这个表格只是一个经过彻底简化了的内容，九个方面的需求分析中的每个方面我只列了几个因素，而实际的文件每个方面的因素至少有几十个之多。但从这个哪怕是十分简单的例子中你也可以看得出来，在开发项目进行计划的第一步，作为项目经理或团队的管理人员，对所有影响到一个项目的各种因素进行思考和验证的重要性。参照以上图1 中的需求管理的考虑因素，从九个方面对开发的要求进行分析和总结，可以帮助你很好地照顾到和把握住应该考虑的各种因素、而不至于遗漏掉重要的东西，从而达到对项目的工作范围起到良好的控制和管理的目的。将这些因素用列表的方法总结出来，可以有效地引导项目参加者和团队成员一起来帮助审核各个需求分析，它同时对整个开发团队在项目的早期建立开发目的和任务的共识也极有帮助。2)从使用方案进一步确定功能需求：光有一个高层次的需求总结对确定开发项目的范围还是不够的。要建立完整的开发计划，项目经理或开发团队的领导人员还必须对每个具体的软件功能进行确定。那么怎样从一个高层次的需求总结得出具体的功能设计呢？答案是，最有效的方法根据高层次的需求总结，设计出完整的使用方案，我们把它叫做UserScenarios。所谓的使用方案设计就是，将用户会怎样使用你的软件为解决某个具体问题的整个过程给想象和设计出来，而且应该是一个完整的、从头到尾的使用过程。有了这个过程的总结，再从它的基础上进一步确定每个功能的具体需求。这些具体的功能需求也是需要用文字总结之后，经过整个团队的审核和确证才确定下来。这样的审核与确证可能要来来回回好几次才能最后确定。但是一旦确定之后，它就是一个较为成熟的总结了，它应该包含了整个开发团队对开发的目的的共同认识和意见的回馈，它同时也是对整个开发项目的范围的一个较为完整的确定。采取我在软件开发项目管理一书中所阐述的从使用方案到功能设计的“三步法”，有了完整的功能需求总结之后，才进行最后的功能设计。这样你就可以保证，所设计和开发的每个功能都有于此相对应的功能需求、有于此相对应的使用方案，而不是毫无目标的、仅仅是因为看起来很“酷”而开发的功能。请参见《软件开发项目管理》有关这方面的论述。 3)从软件的质量属性来帮助确定范围：对软件开发项目的范围进行管理的另一个步骤和有效方法是，针对软件质量的12个属性进行对照，由此向客户、市场部门、或领导确定哪些是重要的、我这个项目是必须达到的要求；哪些是次要的、我这个开发可以疏忽的。这个管理方法的指南原则是，代表了一个软件质量的所有属性有的是有冲突的–见下图：质量标志之间相互融合或对立的关系图2：质量标志之间相互融合或对立的关系图中所示的“+”号表示两个不同的质量标志属性相互融合、不矛盾。如果加强某一行的一个质量的属性，那么这个努力会使得所相对的带“+”号的纵栏里的另一个质量的属性也得到加强；“－”表示两个不同的质量标志属性互相对立，要满足其中一个就无法同时再满足相对的另一个。如果加强某一行的一个质量的属性，那么这个努力会使得所相对应的带“－”号的纵栏里的另一个质量的属性受到负面的影响。 例如，如果一个软件的开发和设计做了大量提高其重复使用性的功能，那么这些工作对提高这一软件的灵活性、兼容性、多用转换性等也有巨大的帮助。但是，为提高其重复使用性所必须做的设计上的一些改动，对这个软件本身的效率性的提高则很可能造成负面效果，像额外的程序码必然造成的对运行速度的影响，同时，额外的程序编码也会使“害虫”增多，影响到软件整体的稳定性能。在有限的开发资源和有限的项目时间情况之下，你往往无法满足代表高质量象征的所有属性。所以你要向客户确证，到底哪些质量属性对他们来说是最重要的。在向客户了解开发质量的要求或分析赢得市场竞争的条件时，制定出满足这些质量需求的侧重点和所要照顾到的优先顺序，并知道避免相互矛盾的质量要求的开发需求。你由此将开发的计划根据客户的要求来安排，将软件的开发和测试的重点围绕着满足客户对质量的期望来做。这样做也就避免了花费时间和精力去做不必要的浪费性劳动，将你的开发项目的工作范围制定得更为紧凑、更讲究效益。一旦确定了满足不同质量要求的优先顺序，你就可以对各个工作注明优先代号，如P1到P3，如上面表格中的例子。你的开发计划也能够根据这个优先顺序来制定了-但然是先完成最重要的P1的工作。总结使用项目管理的本领在项目的计划阶段能有效的帮助你控制和确定一个软件开发的范围，从而能帮助你的开发团队集中力量开发对客户或赢得市场最重要的东西、并且避免无效开发的浪费。做好一个开发项目管理中的范围管理，也是帮助你建立合理的项目计划和时间表的基础。做好这个工作的技巧在于，按照本文所阐述的三个方法和步骤，先从需求分析的因素考虑出发，从高层次先确定开发项目的各个任务，然后根据功能设计的“三步法” 从使用方案来确定具体的功能；最后将所要开发的软件根据质量属性的重要性向客户或领导确证它们的优先权和重要性，由此得出工作重点和范围。这样的开发项目管理方法能够有效地帮助你管理你的开发的范围。在下一期的文章里，我再来讨论如何在做完范围管理的基础上，制定合理的开发计划和时间表。 软件开发项目的计划制定-系列(二)  引言上一期(今年三月份)的《程序员》杂志所开始的软件开发项目管理的系列文章，以一个软件开发项目的需求和范围管理作了开始。我阐述了对任何一个给定的软件开发任务，我们如何利用需求管理的各个因素的考虑以及客户对代表产品质量的12个质量属性的要求来帮助我们确定整个开发项目的范围。这个项目管理的早期工作的目的，是为了帮助我们能够制定出合理的开发项目计划，也就是项目管理的下一步工作。在这一期的连续文章里，我来论述你在具备了一个开发项目范围总结的基础之上，应该如何制定一个全面的开发项目的计划，以保证你的开发项目能够取得成功，并以我所管理过的开发项目作为案例来说明具体的管理手段和方法…正确的计划制定过程以及合理的项目时间表的重要性 如果你是一个进行软件开发项目管理的项目经理或开发团队的领导，是否具备一个完善与合理的项目计划是影响到你所管理的项目成败的关键前提。就像缺少一个完善与符合科学规则的蓝图无法去建造一个大楼一样，没有一个完善的、符合软件开发原则和特性的项目计划，任何一个稍具规模和复杂程度、需要多人配合的软件开发项目也无法做到开发的成功。如果你是一个开发团队的开发技术人员，哪怕你虽然并不做项目管理的工作，但是为了你的项目成功的利益和整个团队与公司的利益，你也应该期望并且要求你的团队领导或项目经理为你提供一个合理的项目管理计划。你也有责任积极地与他们一起进行协调和合作，在项目的开始之前共同制定一个完善的开发计划。那么，一个完整的软件开发项目的计划应该包括什么呢？整个计划制定工作的具体任务和工作的顺序应该是怎样的呢？我在《软件开发项目管理》一书中对开发项目的计划制定以及管理的运作流程作了详细的论述。下图是该书里的对如何进行计划制定的运作流程的概括总结：具体的很多细节你可以从书中读到，这里我就将最重要的管理概念以及对与我所要举的案例相关的一些内容做一些解释。从上图你可以看到以下这些进行计划制定的管理和执行顺序的理念：1.确定软件的功能：在确定了项目范围的基础之上，第一步的计划工作任务是决定所要开发的软件的功能。而这个功能的确定过程是需要经过一个从具体的使用方案到功能需求、再由功能需求到具体的功能设计这样一个三步法来进行的。所以进行设计的项目经理们应该对软件如何被用户使用的整个使用方案做详细的分析总结。 2.确定各个功能的优先顺序：在确定了软件的具体功能设计设计之后，你应该将所有需要开发的功能的重要性进行一个优先顺序的设定和排列，也就是确定哪些最重要、哪些次要、哪些不重要。我们通常使用从P1到P3这样三个级别的优先顺序对所有的功能进行划分和排列。这样做的目的有两个：第一是根据事先定好的重要性顺序来安排开发计划，即最重要的功能先开发；第二是为了应付以后可能碰到的必须砍掉一部分功能的情况的出现做准备(在软件开发中常常会有因为市场竞争或客户要求、或开发完成的推迟而出现的某些功能无法按时完成的情况出现)。在这样的情况下你就应该根据事先定好的准则来做决定，而不是临时任意决定哪些功能可以被砍掉或推迟开发。3.确定工作任务单元和进行工作任务的分解：在软件各个功能的优先顺序被确定了之后，接下来根据所要开发的具体功能，确定具体的开发任务、并对各个开发任务进行工作任务的分解，达到一个项目的工作任务分解结构(WBS)。这个工作的过程中有一些过渡性的提交物需要完成：首先是将经过优先顺序排列的功能，绘制项目工作任务的网络图(Projectnetworkdiagrams)，然后采用分解方式进行分解，最后达到一个完整的工作任务单元的排列。(请参照我在《软件开发项目管理》一书中对WBS的做法以及绘制网络图的细节的叙述)。4. 分配开发资源并进行初步时间估算：当具体的开发工作任务的单元被确定之后，接下来进行开发资源的分配，也就是确定到底由谁进行哪些单元或功能组件的开发。当每个开发工作任务都分配布置了具体的开发人员之后，项目经理应该要求具体执行这些开发工作的人员来进行每个工作单元的时间长度的估算。在这个基础之上，项目经理再将所有的工作任务的时间估算进行汇总，得到一个整个项目的总体时间表。在绝大多数情况下，对有任何并列进行的开发工作的时间表，项目经理还需要进行所谓的关键性通道(CriticalPath)的计算，对整个开发项目的工作任务的网络图进行重新的排列和调整，以缩短总体开发时间，如采取将有太多宽松时间的工作任务给缩短、将处在关键通道上的工作分配给多人来完成等等手段，来进一步优化整个项目的时间。在这个基础上来产生整个开发项目的最终时间表。这里我想强调很重要的一点是：任何一个开发项目只有按照这样的方法去制定开发时间表，才有可能得出一个比较能够符合实际情况的时间计划，因为这样的计划制定的运作流程充分考虑到了开发人员的具体因素。做具体开发的技术人员的实际经历、素质、和水平、和所要开发的软件的具体要求，直接影响到每一个开发工作任务的具体时间长短，因为同样一个开发任务，两个不同经验的人所要花的时间是不一样的。项目的时间估计当然还可以以其他方式来得到，但是只有在由真正进行开发的人员做时间估算的基础上得到的总体项目时间表，才最接近于实际的情况。这一点对软件开发特别重要。有不少软件开发项目因为时间表的制定不符合实际而造成严重拖延、甚至遭到被砍掉的下场，或者领导要求员工们用加班加点的方式来补救被拖延的时间表，最大的原因之一就是那些项目从一开始起就没有一个切合实际的时间表、或者是管理人员不懂如何去制定合理的时间表。那种脱离实际、人为想象的时间估算往往是导致项目失败的祸种，但却偏偏有太多的项目管理人员或领导不在乎听取具体开发人员对时间估算的反馈意见。所以，进行一个从下而上的，由做实际工作的执行人员先做估算，然后进行综合再订出总体项目时间表的方法，是任何软件开发组织必须追求去掌握的管理素质。 完整的软件开发项目计划的两个方面完善的软件开发项目管理的工作要求管理人员在进行计划时同时照顾到两个并列的、几乎各自独立的计划工作任务：一个是软件本身的计划，它侧重于软件功能的计划、影响到软件的设计；另一个是项目的展开和执行的计划，它侧重于软件开发工作的具体运行和管理、影响到项目最终是否能够按时按质量完成。这两个工作所侧重的计划问题并不是一回事：一个与开发的结果有关，也就是对所要开发的软件本身的计划；而另一个与开发的运作流程有关，也就是开发中具体的工作任务的执行过程的计划和规章。但是这两个因素却又是紧密联结、互相影响、不可分割的。它们相互之间既有独立性也有依赖性。要对软件开发项目有一个完善的计划管理，所要制定的计划就必须是同时包括这两个方面的计划。上面图中所总结的整个项目的计划制定过程，就是照顾这两个方面的具体体现：第一，软件本身的设计计划在决定了软件功能的基础上，用软件的设计规范书来体现；第二，整个开发过程的计划也是在确定软件功能的基础上，经过进一步的任务分解和资源的分配、由工作单元安排和优化后得到的项目时间表来体现。 换句话说，这样的计划方法是将软件功能的总结，同时作为计划软件设计和计划开发任务的前提，从而使得这两个工作的计划都建立在同一个基础上，同时又用分开的局部流程使它们能够独立完成，使它们都不被忽视。这是一个将它们相互之间的独立性和依赖性巧妙地结合在一起的计划制定的方法。它将两个方面计划的依赖性来互相影响它们各自的结果，使得开发工作执行的计划不是建立在空虚的基础上，而是建立在所要开发的软件的实际功能需要的基础之上。很多开发团队的管理人员或项目经理往往对软件开发项目的计划的范围感到困惑：到底是计划软件本身的内容还是计划开发工作的细节？它们之间的联系以及顺序是什么？通过对上面图中所总结的同时需要完成设计规范书和工作任务清单的分析，你现在应该明白了，完整的项目计划中这两个方面都要包括，而且要用图中所总结的这个计划流程来运作，才能保证开发工作的任务与所要开发的软件是一致的。这是一个非常重要的需要意识到和理解的管理理念。一个完善和成熟的开发团队或组织必须要求它的项目管理人员或懂得并执行这样的计划制定。所以一个完善的开发计划最后应该包括两个最主要的计划文件：第一是总结软件中的所有功能设计的设计规范书(DesignSpec)，第二是一个与开发这些功能完全相应的开发工作任务的时间表(Schedule)。这两份各自独立的计划文件组成了项目总体计划的骨干文件，成为其他计划文件的依据。比如说，开发团队再根据设计规范书所描述的具体功能要求去进一步制定软件的构架设计以及每个功能组件的实行计划的制定；软件测试团队也根据设计规范书所描述的具体功能来制定测试计划和具体的测试方案。同时，进行项目管理的经理们也再根据工作任务分解结构以及时间表来进一步制定项目的开支计划，并同时根据设计规范书去制定其它的项目管理计划，如风险管理计划、进度状态通报计划、外报计划等等。在下篇的连载中我会再仔细谈设计规范书的具体撰写内容，以及进行功能设计的“三步法”。这里我先将其它有关项目计划的工作内容作一个介绍… 软件开发管理中所需要的其它计划除了体现软件的设计规范书和体现项目进度的时间表的制定这两项重要的计划文件之外，在项目的计划阶段，项目经理还必须与开发团队的领队和其它成员一起协作来制定其它几个和开发管理有关的重要计划：1.确定每个开发阶段的里程碑(Milestone)：在建立了开发时间表的基础之上，通常我们都将整个软件的开发过程分成几个阶段来来进行。每个阶段先着重开发一部分功能。这样的阶段的终结点就叫这个阶段的里程碑，用M加一个号码来表示，比如从M0开始，到M1，再到M2，…等等。这样的将开发任务分成几个不同的阶段、每阶段分别注重于先完成一部分开发任务的运作方法，对绝大多数软件开发来讲带有很大的好处。这样的运作流程有助于将所需要完成的整体开发任务，采取逐步开发的方法来渐渐加入和整合新的功能，同时又能够对开发出来的各个组件进行循环式的不断修改和调整、对设计上需要作的改动进行必要的调整、对出现的问题进行及时的修正。这种渐进式的开发方法要求对每个阶段的目标在刚开始就有一个明确的定义。因此，里程碑的制定、以及与此相关的每个阶段相对应的具体日期、以及每个阶段的重点任务等，都应该是项目计划的一部分。下面我继续拿我所管理过的微软嵌入式操作系统工具的开发项目作为案例来说明这种项目管理的思路，以及里程碑计划的典型内容。以下这个表格就是一种对里程碑进行定义的方法之一： 里程碑里程碑定义里程碑必须完成的功能M06/1/2000CodecompleteforAlphaversion初版本功能开发的代码全部完成Allkeyfeaturescompleted:UsershallbeabletoauthorabasicSLDfile.Helpcontentmaynotbecomplete.所有关键性功能都开发完成。用户将能够使用这个产品进行最基本的嵌入式操作系统设定文件的制作。产品的使用说明书的内容可以还没有全部完成。M17/1/2000QAcompletionforAlphaversion.初版本的测试完成Beabletocompleteallkeyuserscenarios,andincludinglivedatabasesupportforOSfeatureselection.所有关键性的使用方案都能够被完全操作，包括使用实际的操作系统功能组件的分类数据库来选择操作系统的具体功能。AlphaRelease7/15/2000初版本的发行ReleasetoInternalteamandJDPpartnersfordogfooding初版本向内部发行、让内部用户先“吃狗食”(即开发团队内部先使用还不完善的初版本)，并向开发合作伙伴发行。M28/15/2000CodecompleteforBetaversion 试用版本功能开发的代码全部完成Allmajorfeaturesforbetacompleted.Usershallbeabletouseallmajorfeatures:SLDcreationandmodification,browsingSLDfiles,browsingDBobjects,etc.试用版本中所有主要功能都开发完成。用户将能够使用所有主要的功能：包括嵌入式操作系统设定文件的设计和修改、浏览设定文件的内容、浏览操作系统功能组件的分类数据库等等。M39/1/2000QAcompletionforBetaversion试用版本的测试完成Visualfreeze.Allhelpcontentauthored.Usabilitytestcompleted.使用界面的设计冻结。所有使用文件的内容都编辑完成。产品的可用性测试完成。BetaRelease9/20/2000试用版本的发行Releasetobothinternalteamfordogfooding,andtogeneralexternalusersforbetafeedback.初版本向内部发行、让内部用户先“吃狗食”，并向普通的外部客户发行，以获得外部客户的回馈意见。M410/15/2000FeatureComplete所有功能开发完成Allfeaturecompletedaccordingtospec.Allunittestdone.Allsystemtestsdone.Fullregressiononalltestcasesatleastonce. 在设计规范书里所确定的所有功能设计都完成。所有功能组件的单元测试全部完成。系统测试全部完成。任何所需要进行的回归测试至少完成一遍。M511/30/2000RC1Release发行候选版发行Releasecandidate1releasetobothinternalandexternalusers.Usersshallbeabletouseallspecifiedfeatures,viewallhelpcontent.Allotherdocument,suchasSystemDeveloper’sGuide,iscompleted.发行候选版向所有内部和外部使用者发行。用户将能够使用产品中所有的功能，阅读所有使用说明文件的内容，以及像系统开发指南等所有其它文件。M612/15/2000FinalQAcompletion最终的全面测试完成Allactivebugsfixed.Noshipstoppers.Fullregressiontestdonebeforeallfinalbugfixes.Alldocumentation,on-lineandprintingmaterials,completedthefinaleditorialproofing.所有的未被修正的缺陷都被修正。没有剩下任何可以阻止发行的缺陷。在总体的全面最终测试之前，所有回归测试都完成。所有文件的内容、不管是印刷的还是电子版的，都完成最后的编辑审核。GoldRelease12/20/2000OfficialRTM 产品正式发行Allreleaseexitcriteriamet.ProductcodeisreleasedtoCDmanufacturingandon-linedistribution.所有发行前的终结标准都得到满足。产品的源代码向生产光碟的工厂发行，网上发行的版本同时也上载到网上。以上只是一个简单的举例，而且每个开发项目的阶段的多少和里程碑的设定，你当然要根据具体的开发内容来决定。但是从这个案例你可以看到，不同阶段的开发重点和要求是不同的，里程碑代表了阶段的终点，到达每个里程碑的象征就是这个阶段的工作任务都完成了、使软件达到了某种要求。这样的里程碑计划确定每个阶段的主要任务和工作重点。另外，采用像这样的在软件的正式版本发行之前先发行初版和试用版的方法是一个符合软件开发特点的循序渐进的开发流程。它使许多在产品最终发行时可能会碰到的问题、特别是系统整合、最终的汇编建造、以及为了满足产品发行的质量要求所可能碰到的很多质量管理问题，在项目的早期阶段通过这样的“小型发行”(MiniReleases)被及早发现，使得开发团队有足够的时间去及早解决。所以你在进行开发管理时也应该采用类似的方法来进行开发计划的制定。2.制定每个里程碑的离开衡量标准、或叫终结标准(Exit Criteria)。前面第一点的计划是事先确定每个阶段工作的任务和侧重点，但是光有这个计划还不够，因为你如何知道每个阶段结束时你的开发团队的工作结果是否是达到了要求呢？答案是：与每个阶段的工作任务计划相对应的，你还必须要事先制定一个每阶段开发的结果是否达到要求的衡量标准。我们把这些在每个阶段的终点衡量开发结果的标准叫做里程碑的终结标准。这些终结标准明确地订出如何判断项目到达每个里程碑时开发的结果是否符合要求、以及项目的进程是否可以进入到下一个阶段的做决定的衡量准则。那么这样的终结标准、即ExitCriteria，应该包括什么样的内容呢？再以我上面的案例来说明：你可以看到我当时的第一个里程碑是将产品的最基本和关键的一些功能先开发出来、并不是所有的功能都要完成，而且对产品的功能从用户的角度讲有一个基本要求，就是要能够使用这个产品进行最基本的嵌入式操作系统设计的设定文件的制作，所以这个“初版本功能开发的代码全部完成”的里程碑的终结标准就是要确证这个基本的阶段要求是达到了的。下面是这个终结标准的举例：嵌入式操作系统开发工具的初版(Alpha)功能开发完成的里程碑(M0)终结衡量标准□嵌入式操作系统开发工具中有关进行操作系统设计的功能必须是能够从头到尾、按照使用方案进行使用的。□嵌入式操作系统开发工具中的为进行操作系统设计的功能组件和提供构架整合的组件必须都完成、并且没有P1和P2级别的Bug(缺陷)。□开发工具中的其它非关键性功能不能有P1Bug，但可以有P2和P3的Bug.□嵌入式操作系统开发工具中的主要使用界面的菜单、对话框、图标等都必须按照设计规范书的设计完成开发。 □嵌入式操作系统开发工具所制作的系统设定文件必须能够生成和储存完整的、能运行的嵌入式操作系统，并且同样的文件要能够打开再次使用，能够重复生产同样版本的操作系统。□嵌入式操作系统开发工具中的为进行操作系统设计的功能组件都必须完成了它们的单元测试。□嵌入式操作系统开发工具中的使用说明文件的内容还没有最后确定，但从工具的菜单上需要打开产品的使用说明书(HelpFile)的链接必须都要打开目录标题正确的文档页。□…(等等)这里所举出的只是整个M0的ExitCriteria中的一部分，但你可以看得出来，这个早期的里程碑的重点是保证最基本的操作系统开发功能要能够使用，比如保证产品的使用方案都可以从头到尾完成。而产品开发接近结束时的后期里程碑的终结标准就与这个很不一样，它们是着重于发行前的质量保证。比方说，上面案例中的M3的里程碑是Beta版本的质量测试的里程碑，它的ExitCriteria就注重于必须满足的一系列质量度量的标准。下面是这个案例的M3的终结标准举例：嵌入式操作系统开发工具的试用版本(Beta)完成的里程碑(M3)终结衡量标准□检验嵌入式操作系统开发工具的使用界面与使用说明书的解释必须一致的测试应该全部通过。 □嵌入式操作系统开发工具的使用界面所有P1和S1Bug都必须全部纠正。□所有使用文件的编辑内容的测试P1和P2Bug都必须全部纠正。□在初版发行之前，未经处理的软件缺陷(ActiveBugs)的数量必须是零。□在初版发行之前至少一个星期，开发团队的纠错率(FixRate)必须一直高于发现率(IncomingRate)。□被修改的缺陷(ResolvedBug)必须全部经过验证(Verified)，被证明它们的确是被修正了(Fixed/Closed)。□所有缺陷数量的时间走势或趋势必须是在发行前的15天里一直处于下降状态。□未被修改(Assignedbutnotinvestigated)的缺陷数量必须是在过去的5天里一直处于接近零、而且是在过去的10天里维持在零附近。□在过去的10天里没有发现S1的缺陷、也没有未被修改的S1缺陷。同时，S2的缺陷没有超过10的数量、S3的缺陷没有超过25数量。□在发行前的7天里，开发团队能够及时修改所有的S1级别的严重性缺陷。□在过去的5天里，任何被重新激活(Reactivate)的缺陷必须低于被修改过的缺陷数量。□…(等等) 这样的终结标准需要项目经理与开发和测试团队的领队们一起协商决定，这样的具体衡量数字是根据质量管理和测试的要求来订的。一旦有了这样明确的终结标准，除非有特别情况，整个软件开发的过程就要严格按照这样的标准来执行。对软件开发组织来说，一个很重要的企业文化是尊重测试团队的工作和结论，它的象征之一就是让测试团队真正来把关。比方说，如果测试团队还没有来得及对所有的FixedBugs进行验证，也就是上面第6条的标准就没有达到，这时开发的进度就无法达到这个里程碑，初版就不能发行。一般这样的终结标准会有十几条至几十条，视具体的质量管理的严格程度和要求来定。有了这样的标准，它还能帮助你有效地与用户和领导进行沟通，对开发进度的状态能够有清楚的通报。3.完成其它开发计划：作为软件开发计划工作的一部分，光有软件功能设计的设计规范书还是不够的。当设计规范书一旦通过团队的审核，开发团队接着要以它为基础，进行软件的构架设计，以及由各个开发工程师进行各自的开发设计、并制定开发的实行计划(ImplementationPlan)；测试团队也需要以它制定测试计划和具体的测试方案。这些计划都是完整的软件开发管理中不可缺少的计划文件。要是你的开发管理流程中目前还没有制定这些关键计划的习惯或规章，你就应该考虑如何通过加入这些计划的制定来帮助你的团队增进你们的开发效率和质量。除此之外，对大型和复杂的开发项目进行计划时，项目管理人员还应该考虑制定其它一系列的辅助性计划，用它们来帮助加强管理和增进与客户的沟通。这些计划工作的范围包括：•软件更改控制以及管理(ChangeControlManagement)的计划：如果碰到设计更改要求，根据什么样的准则接受或拒绝这些要求？对测试中找到的各种不同的重要性和严重性的缺陷，你根据什么样的准则接受或拒绝修正的要求？ •风险管理计划：你的开发项目中最大的风险是什么？你如何应付由于不成熟的新技术出现的问题、员工的跳槽等等所带来的风险？•外部依赖管理：依赖外部团队或外包商所提供的组件如果碰到无法按时完成、或质量出现问题，你该如何面对？•文档计划：你的软件产品的使用说明和可能需要的用户培训该如何完成？•项目进度通报计划：你应该怎样向客户和领导、以及整个开发团队进行定期的项目进度的状态通报(StatusReport)?通报的频率、内容、读者等等应该是什么？从这里你可以看到，一个完善的开发项目的管理，需要管理人员充分思考和制定与所有这些有关的计划。如果一个开发组织仍旧还是使用毫无章法的管理方法，你作为开发技术人员也有责任去督促你的经理去学习和采用良好的管理方法和制度。这不仅对建立一个可以让你有效工作的良好环境有直接的影响，更影响到你的公司能否赢得长期的激烈市场竞争的结果。它的重要性不言而喻。总结 软件开发项目的计划反映在两个方面：一个是软件开发的本身需要有个计划，用它来帮助确定最后成形的软件应该是什么样的；另一个是开发工作执行的计划，用它来帮助确定开发工作能够按部就班地执行，促进软件能够按时按质地被开发出来。对一个软件开发项目制订计划，就是按照这个体现了将两个种类的计划需要结合在一起的流程，去顺序完成各个分析总结工作和需要提交的计划文件，使得开发工作的计划能够与软件本身的要求结合起来。完整的计划工作还要求管理人员制定一系列的其它辅助性计划来帮助加强管理、降低风险。在下一期的文章里，我们再来看如何制定良好的设计规范书，用它来帮助我们开发高质量的软件。  软件开发设计规范书的撰写—系列（三）引言在上一期（今年五月份）的《程序员》杂志里有关软件开发项目管理的系列文章中，我以自己曾经从事过的开发微软嵌入式操作系统的项目管理作为案例，讲解了制定开发项目计划的一些关键管理概念和实践指南，包括项目时间表的制定流程、如何确定每个开发阶段的里程碑、如何制定衡量是否达到开发里程碑的终结标准，等等。文章中还提到完善的软件开发项目管理要求管理人员在制定项目的执行计划时间表的同时，还要同时照顾到体现软件本身的设计计划，而这个设计计划是用软件的设计规范书（也叫DesignSpecification，或简称Spec)来总结的。在这篇连续文章里，我来进一步讲解软件设计规范书的撰写，包括可供查照的撰写模版提纲、如何总结使用界面的设计、如何总结出错信息等，以及微软在这方面的良好企业文化传统。你要是能够使你的开发团队在项目计划阶段也采用类似的设计计划，对推动你们的开发成功会有很多好处。软件设计规范书的撰写提纲 功能规范书是整个开发团队用来进行设计交流的最主要的文件和手段。它陈述、归纳、总结了一个软件产品或系统中所有的功能设计的具体细节。在一个软件产品或系统最终完成和成型之前，功能设计规范书是整个设计构思的中心。所以它是整个软件开发项目的中心指南文件，也可以说它是开发计划安排的基石，因为它也为其它的开发计划提供一个参照的标准。首先，作为软件开发者，你应该充分重视在开发之前将软件的使用功能的设计先进行全面的总结并以文档作记录的重要性。不同的开发者和开发团队对如何进行这样的使用功能的总结有很多不同的习惯和方法，但是不管采用何种方法，将所需要开发的各种使用功能的设计用文件固定下来，为软件开发会带来巨大的好处：•就像为盖房子提供一个蓝图那样，Spec为整个软件的功能开发提供一个完整的规划：需要开发的功能应该都被总结在设计规范书里，规范书里没有的则不该开发。有这样的明确定义，能帮助开发团队避免无效开发、也能帮助测试团队建立有的放矢的测试计划。•它为整个开发团队提供一个可以共同参照的统一标准：任何功能开发上有疑问的，都以设计规范书所总结的要求来解决。同时，其它各种有关的项目计划，如测试计划、文件编辑计划、可用性计划、本地化计划等各种计划，都以产品的设计规范书作为它们的计划准则。•它为项目的赞助者、客户、以及项目参加人员提供一个对功能设计进行审核、对照、和解决问题的共同讨论点和对证：开发团队的成员以它来协商对设计的建议和意见、对设计提出疑问等等；另外，客户对设计规范书的审核的认可与通过，则表示他同意了被总结了的所需要开发的功能的范围、同时也表示他同意了不要求开发规范书里没有总结的功能。 那么，一个完整的设计规范书应该包含那些内容呢？对不同的开发项目，设计规范书的着重点和范围当然会有些不同，但从总体上来说，如果能对以下这些内容都有明确的定义和总结，在很大程度上能帮助开发团队明确理解功能的设计和开发的目标：软件产品设计规范书的撰写提纲和模版1.文件的梗概和介绍：•总结：在设计规范书的起头，对整个开发项目做个总结。用简单几个段落从宏观的高度对整个项目的目的，和它所开发的功能做一个描述。•范围：说明设计规范文件的所叙述的范围，包括文件中各个分部的内容大纲。•读者：简要地描述阅读和理解此份设计规范文件的读者、以及必要的前提和知识背景。•文件的修订历史：注明这份文件的自初稿后的所有修订历史，包括修订日期、改动的内容和理由、谁作的修改，以及修改内容的页数。2.开发项目的目标：用段落文字总结以下这些内容：•远景：总结整个开发项目的远景，也就是开发的战略目的或目标的定义。•设计目标：陈述开发的结果所需要具体解决的问题，以及为达到这些目的所做的相关功能设计的概述性总结。•项目理由的辩护：说明为什么需要进行这个项目、开发这个功能或产品。　 •项目的客户和合作者：列出项目开发出的结果所要服务的具体客户，以及项目进程中所要依赖的合作伙伴、包括企业内部其它部门的合作者和企业外部的合作者。•项目的风险以及成功的依赖者：列出整个项目的所面临或可能会遇到的风险。•项目进度的里程碑：用表格的方式将整个项目的里程碑给详细地列出来，并将每个里程碑完成结束的衡量标准也做总结陈述。•使用方案和系统流程图:用逻辑图或其它图像来说明系统的数据处理的流程、各种组件单元之间怎样互相配合来提供所设计的功能，以及注明各种数据的输入、输出、和处理等等。3.功能需求的总结：在这一章里详细列出软件所有应该开发的功能。每个功能应该有相对应的客户使用方案为基础。最好的方法是用表格的方法，逐步列出产品必须支持的使用方案，以及每个使用方案所依赖的功能。4.功能的具体设计：在这一章里详细总结和列出软件所有的功能的具体的设计。对每个具体的设计进行详细的陈述，并配之于所需要的图像进行解释。对每个具体的设计进行包括以下内容的详细的陈述：•所提供的功能、性能、或其它服务。•使用界面的解说，包括软件总体的运行界面的框架、不同的视窗的功能、菜单(Menu)、工具条(ToolsBar)以及按键(Buttons)，状态条(StatusBar)，图释(Icon)，以及每个对话框(Dialog Box)的设计和形象，产品的徽标(Logo)，启动画面(SplashScreen)，等等。它们还应该包括每个控制键以及输入时段的使用法，以及系统的反应和回馈的行为；以及每个出错的信息、格式、和具体的文字，等等。•产品使用说明(Onlinehelp)的设计、连接、内容要求。5.设计的考虑因素：总结其它设计中必须满足的要求：•运行平台的要求：此产品或系统对运行环境的各种要求,如操作平台、硬件、网络连接、使用规章等等。•性能要求及可以接受的衡量的准则，以及对产品安装的功能、安全性,国际化和地方化的要求等等。6.开发时间表：列出该项目的开发时间表，对每一具体开发任务所需的人力及时间的初步估计,及所有的项目里程碑。7.项目成功所依赖的因素：总结对所有可以估计到的外在制约的因素,特别是写明哪些因素是该项目成功所依赖的,如特别的人才,设备,所需的技术、某些外部团队的支持或必须完成的组件，等等。7.未解决的问题：总结和列出任何尚未解决的问题,或有待近一步调查商讨才能定出答案的有关设计方案和计划,及任何与客户间尚未同意的事项,等等。 结尾页：设计规范书通过的签字——当设计文件最后审核通过后，各团队领导和客户代表在此签字。制定明确的界面设计除了按照上面所讲的按照特定的模版来进行设计规范书的撰写，以保证很多重要的东西不至于被忘记或遗漏、使得从事设计的项目经理和开发团队的成员们不得不去思考和解决相关的一系列问题，另一个重要的帮助提高软件开发功能规范书质量的关键是，所有软件的使用界面的设计必须要有明确的定义和说明。设定明确的界面设计指的是，软件的使用界面应该在软件开发之前都已经设计好了、并在设计规范书中进行详细的总结和解说，这样开发团队的开发工程师们在进行程序开发时就有一个明确无误的参照，不仅知道开发出来的软件的使用界面应该是怎样的，更重要的是，使用界面在被使用的过程中各个控制组件应该如何反应、软件应该如何给使用者准确的回馈、使他们能够完成必要的使用方案（也叫UserScenarios，即软件功能使用的过程和顺序）去解决具体的问题，开发工程师们事先就有一个可参照的准确的“蓝图” 。要是没有这样详细的设计，开发工程师可以临时发挥去任意开发。那样开发出来的结果也许有时是可以满足要求的，但在很多情况下往往是无法满足要求而造成浪费的无谓开发。合理的软件开发的项目管理，就是要尽量减少和避免这种无谓的劳动和浪费，而要使每个被开发出来的功能、每个使用界面的组成部分，都有它们明确的目的、都是为了保证使用方案的完满的执行而能起到它们的作用，设计规范书中明确无误的界面设计总结就是关键。下面我仍将自己在微软进行过的嵌入式操作系统工具的开发项目管理作为案例，来举例说明如何设定明确的界面设计。图1：目标设计原型图从图1中你可以看到，使用界面的设计不仅要显示界面看起来应该是什么样，更要有对各个界面的控制组件的行为和回馈有详细的解释，比如“按了这个键后会发生什么……”、“在这个对话框里输入数据后会发生什么……”等等。有这样的详细的图像解释，不仅开发工程师们有开发的依据，测试工程师们也能够根据这些具体的要求进行测试方案的制定、文档编辑们也能够根据这些具体的界面行为来撰写使用说明书。这也是为什么详细的界面设计对完整的设计规范书那么重要。图2是另外一个类似的例子，你可以看到这里是两个TreeView列表的界面设计。如同上面举例的概念一样，这里对Tree View中具体的细节也要做说明，包括图标、文字显示、按键等。用类似这样的界面设计的图画，再配上对很多具体的界面的细节加以说明的图示文字，能使设计的概念很容易与开发人员沟通，并使他们在开发时注意到这些重要的细节。这是一种极为有效的设计总结方法。图1：Treeview列表界面设计当然，在设计规范书里对这样的界面设计光有图画是不够的，对每个界面设计的组成部分还应该再配上具体的文字解说。最有效的方法是将每个界面的组成部分标明他们的重要性优先权的（Priority）划分、每个组成部分的名字、以及具体的行为细节，用列表的形式作总结。这样在设计规范书进行团队审核的时候可以很方便地进行逐条讨论，而这样的格式又可以为开发工程师们提供一目了然的参照。下面图3是设计图像配上文字解说的例子（我将原来的英文产品设计附上翻译便于阅读）。图像界面设计总结——状态条（StatusBar）的功能设计里程碑图像界面组成部分界面的使用和反馈行为M1Statusbar–Filed1:GeneralStatustext状态条–第1个数据显示栏：普通的状态文字•Defaulttext:Ready •Itdisplaysotherstatustextbythetool,asspecifiedelsewhereinthisspec.•默认值文字：可正常使用•其它时候显示此设计规范中其它地方所指定的工具的状态文字M3Statusbar–Filed2:Progressbar状态条–第2个数据显示栏：渐进显示条Progressbar,displayedduringaddingdependenciesandbuildprocess,etc.,wheneverTDisrunningabackgroundtaskformore2seconds.在检测其它依赖组件以及操作系统镜像生成时候，每当工具需要有2秒以上的等待时间时，显示渐进显示条。M2Statusbar–Filed3:Totalfootprintsize状态条–第3个数据显示栏：显示操作系统镜像的大小总数Totalfootprintsize•Whennoconfigurationisloaded,itdisplaysblank.•Onceaconfigurationisloaded,itdisplaystotaluncompressedfootprintsize,inMBsizewithonedecimalfraction.操作系统镜像的总数显示应该是 •当没有一个镜像设计被装载在工具中，不显示任何数字。•当一个操作系统的设计镜像被装载在工具中后，显示以兆为单位的、带一个小数点的、非压缩的操作系统镜像的大小总数。M4Statusbar–Filed4:Database状态条–第4个数据显示栏：显示所连接的数据库的名字Currentconnecteddatabase:•WhenTDfirstinvokedandnoDBisconnected,itdisplaysblank.•Onceuserspecifiesthedatabasetouse,theDBnameisdisplayedinthisfield.显示目前工具所连接的数据库：•当工具刚启动时，还没有数据库连接上时，不显示任何数字。•当一旦连接上数据库后，显示数据库连的名字。图3：软件界面的设计用图像加文字解说不要忽视出错信息的设计在软件设计中，我们不可避免地要碰到对各种可能出现的错误，如使用者所犯的错误以及软件本身的缺陷带来的系统错误等，提供回馈的出错信息（Error Message，也叫错误信息)的设计。明确和有效的出错信息的设计，也必须是完整的设计规范书所应该包括的内容。出错信息的设计的好坏，直接影响到一个软件的可用性，所以是任何软件开发者应该重视的设计因素之一。在微软的产品团队，我们的界面设计对出错信息的质量非常重视，因为以前微软有的产品对这方面不够重视，造成一些非常荒唐可笑的出错信息被加入到产品中去，而常常成为业界的笑柄。最有名的一些可笑的出错信息包括“Youjustdidsomethingyoushouldn’tdo.”（你刚做了个不该做的事)，“Anunknownerrorhasoccurred”（一个不知怎么回事的错误发生了），“Acatastrophicerrorisgoingtohappen”（像大灾难似的错误将要发生了）等等。现在微软从事界面设计的团队还有一个专门刊登记录所有这些可笑的出错信息的网站，叫做“UIHallofShame”（令人羞愧的界面设计大展览)，将全公司各个产品团队任何被发现的荒唐出错信息设计登在上面，以此告诫所有开发者们不要忽视出错信息的设计。下面这个出错信息对话框就是其中的展出之一：“呃哟糟糕，也许会出现个问题。还要继续下去吗？”对任何出错信息的设计，都应该按照下面这个设计原则来进行，1.出错信息首先应该向使用者明确说明，究竟发生了什么问题或错误；2.出错信息应该向使用者解释是何种原因造成了出错，即到底是因为使用者的错误、使用还是系统本身的问题造成了问题； 3.出错信息还应该向使用者提示，应该采取什么样的措施、或纠正的步骤，来纠正错误或避免错误，使得使用者可以继续使用软件。所有的出错信息的设计必须通过设计规范书进行全面的记录和总结，然后在程序开发时开发工程师要根据这些设计来开发。也就是说，任何出错信息都必须是事先设计好的，而不应该由程序编写者心血来潮似地任意加入到软件中去。在开发过程中要是发现有新的出错信息需要加入产品，加入的过程同样要按照设计的要求进行，在对设计规范书经过修改、加入新的设计之后，才能进行程序的改动。这样的严格管理方法是避免荒唐可笑的文字混进产品中去的最有效方法。在下一期的文章里，我们再来看如何制定执行良好的开发执行管理，来帮助我们开发高质量的软件。 软件开发项目的执行管理—系列（四）引言在上一期（今年六月份）的《程序员》杂志里有关软件开发项目管理的系列文章中，我将软件开发项目中进行设计总结的设计规范书（简称Spec）的撰写纲要及管理过程做了解释，并介绍了微软在产品开发中的一些相关的企业文化和传统。在这篇连续文章里，让我将讨论的话题从前面几篇文章所着重讲解的有关开发项目的计划工作，转到软件开发时项目管理的具体执行工作上来，并进一步介绍微软在产品开发上的许多独特的管理方法和企业文化。使用统一的纠错和更改管理系统是开发运作管理的中心当一个软件开发项目完成了计划、开始进行具体的开发工作之后，一个开发组织的各种工作结果反映在各个团队随着项目的进程所完成和呈交的各种提交物上，它们包括：开发团队呈交的软件功能组件的源代码、文档编辑团队呈交的各种文件、使用界面专家设计的各种使用界面的资源、可用性专家对用户进行的可用性的验证和调查结果的总结、测试团队对以上呈交的各个工作的成果进行测试的结果以及各种测试记录、等等。所以，任何一个大型和复杂的软件开发的过程是一个需要整个开发部门的各个专业团队进行良好配合和协作的过程。 要协调这么多人的工作、使大家能够进行良好的配合、将大家的工作结果都为达到项目的整体目标而出力，是一个不简单的管理任务。要做到能够有效地进行整个开发项目执行过程的管理，光靠简单化的记录工具和原始性的手动管理方法是远远不够的。开发组织需要遵循开发管理的执行规章和使用高效的管理工具。这也是区分一个开发组织或企业是具有成熟的管理能力还是仅仅具备小作坊式的原始管理能力的衡量之一。在这样一个有多个团队进行同步工作的环境下，不同团队的工作结果和质量会影响到其它团队下一步的工作，比如程序开发的质量会影响到测试工作的范围和工作量。关系到软件开发的实际结果的，就是这些在一个环节出现的差错和问题对下一个环节所造成的影响。所以真正有效的管理，就是要在每个可能出错的环节，用必要的运作流程和规章制度的执行，来尽量保证各种差错或问题被及时抓住，保证每个环节的工作结果符合必需的质量标准。那么，我们如何来保证每个环节的问题（即出现的差错和缺陷，我们通称Bug）都被及时抓住、被注意到，并有相对的措施来保证它们被及时解决呢？答案是，在每个环节都进行质量的把关，将进行质量把关的检验及时地记录下来，并要求整个开发组织的各个团队都严格按照统一的方法进行检验和记录；对于发现的问题该作如何的对策，这个决定手段和过程，整个开发组织也必须按照统一的规则来进行。 微软在这方面经过自己三十多年产品开发的实践和经验教训，总结出了一套极为有效的开发管理的运作流程、和与其相配套的独特的开发管理工具。这一套极其特别的管理方法和使用工具，是一个建立在现代项目管理的理论基础之上的具体实践。它的关键理念就是：任何有效的项目管理都离不开扎实的更改控制管理（ChangeControlManagement），通过共同使用统一的纠错和更改的追踪和管理系统（BugTrackingandChangeControlTrackingandManagementSystem）的工具，建立与之相关的有关规章制度和企业的文化，来达到有效的开发运作管理。我在《软件开发项目管理》一书中对这个系统的使用作了详细的论述，这里我来对其基本概念作一个简单介绍，并谈谈微软在开发管理中与其相关的企业文化。把更改请求记录的统一使用与代表团队意见的审核结合在一起如前所述，开发工作一旦开始，每个不同的环节（即每个不同部门的工作结果）都有可能出现差错和缺陷。我们管理的关键方法就是要使所有这些部门使用统一的差错追踪和记录工具，用它来帮助我们将每个团队的工作给连接起来。当任何问题被发现后，发现问题的人将差错和缺陷（即Bug、或称“害虫”）记录到对差错进行追踪的工具里去。这样的工具带有自己的数据库，所以可以很容易地对缺陷记录档案进行搜索。任何Bug一旦被记录下来，它就“逃不掉” 了：再也不会被忽略或遗忘，因为负责项目管理的项目经理，会定期的（比如每天一次）对所有的缺陷记录审核一遍，并与其他团队的领队或成员对每个Bug做出如何处理的决定。所以采用统一的记录和定期的审核，首先保证了任何作了记录的问题都得到开发组织的审查。我们在微软的传统是，没有经过BugTracking工具记录和决定的任何要求，开发团队可以采取不理睬的态度。我们的口头禅是：“Ifyouwantthatissuetobefixed,fileabug!”。微软为这样管理流程开发了专门的供内部使用的纠错记录工具，叫Raid，这几年又升级换代为ProductStudio。现在，这些工具的功能已经被整合到最新版本的VisualStudioTeamSystem（VSTS）中了，所以任何软件开发公司或进行任何信息系统开发项目的企业，现在都能够借鉴和使用微软的优秀开发管理传统，使用VSTS对自己的开发项目进行同样的高效开发管理。在微软，我们把每天对纠错记录进行审核的会议昵称为“急诊室的会诊”（Triage，意思是像对急诊台上的病人进行手术前的会诊一样），或也叫它为“三国会议”，因为这样的会议必须要有项目管理、开发、测试三方都有代表参加才能召开。如果项目经理要召开TriageMeeting了，可是会议室还缺少三方中的一个代表，比如测试团队的领队缺席，我们要么马上打电话去找能代表测试团队意见的测试工程师来代替、要么将会议推迟。这样的良好风气和传统保证了代表软件开发的关键三个方面的意见在审核每个Bug时都能被听到和得到尊重。如果某个Bug是与文档编辑或使用界面有关，则在做审核的决定时，三国会议会再邀请文档编辑团队或使用界面设计团队的人来参加。这样的规则保证了任何决定都是有熟悉情况的做具体工作的人的参与，避免做出不符合实际的荒唐决定。 这样的记录追踪和管理的方法，不仅对软件的缺陷进行纠错和修订采用、更是对其它任何改动要求也使用。比如说，要是在软件开发过程中发现原来的设计有问题、需要加入新的功能，找到问题的人也是通过记录一个要求对设计进行改动的Bug（我们把它称为DCR，即DesignChangeRequest）去要求三国会议对它进行考虑，而不是径自或随意去要求项目经理做设计上的改动。所以严格说来，这样的管理不仅是对纠错要求做管理、而是一个对任何更改要求做管理的方法和系统，所以它是一个全面的更改控制管理系统。使用这个更改控制管理的最根本的精髓在于，任何缺陷的修改、或对功能需求改动的请求，不是随便可以接受的，已经开发的程序也不是可以任意由开发者随便加入新的功能做改动的。修改缺陷或加入新功能等所有改动要求都必须经过“提交请求→分析批准→改动程序→验证改动→改动完成”这么一个运作流程，来保证改动的要求是合理的、是与项目的目标一致的，同时也保证任何改动符合必要的质量管理要求。下面图１是一个完整的执行纠错和更改请求管理的运作流程总结（详细解释请见我书里的叙述）。图1：微软的纠错及更改管理的运作流程 既然这样的管理工具和规则要考虑到对任何可能出现的改动要求进行审核批准，在使用时就必须要有一套可以顾全到各种情况的、可以帮助进行衡量和审核的标记。在纠错中最常用的方法是对任何问题进行不同级别的重要性（Priority）和严重性（Severity）的划分，比如P1到P3、S1到S3这样的级别划分。这个设定级别的方法也可以用到对任何改动请求进行管理的更改控制管理中来。图２是用来帮助进行更改管理的各种划分标记和使用的范围。图2：更改管理运作流程中所用的各种衡量准则你将图１的操作流程和图２的衡量标准结合起来，就可以建立起一个完整的开发过程中进行纠错和更改控制管理的制度和规章。我们在微软所进行的产品开发就是按照这样的方法来进行项目的执行管理的。它充分尊重软件开发的三个中心团队的意见对开发的成功所具有的同等重要的影响，用一个组织手段来保证软件的设计、开发、测试三个方面的考虑都受到重视，同时还照顾到其他各个辅助性团队的意见不被忽视。微软30多年的历史证明，这种管理流程和方法的灵活性，具有巨大的好处，它使开发团队能保持做决定的灵活性、快速性；帮助公司保持产品开发的效率和速度、保持对市场的高度灵敏的调节能力，所以它对微软的整个企业的成功有不可估量的重大贡献。进行更改控制管理的具体操作方法下面，我仍将自己在微软进行过的嵌入式操作系统工具的开发项目管理作为案例，来举例说明如何使用这样的工具和规章来帮助进行项目的执行管理： 首先，当开发项目开始进行以后，我们整个开发部门各团队就开始统一使用我们专门的纠错和更改管理系统Raid（后来升级到ProductStudio），用它作碰到的任何问题的记录。比如测试团队在产品中找到的缺陷、任何人发现的产品设计的问题、以及任何一个团队所呈交的工作结果中的被发现的缺陷和问题、包括产品文件、使用界面设计、本地化翻译等等。如果市场营销部门有客户回馈或增加新的功能的要求，也用同样的方法提出要求。我作为产品的项目经理，每天定时召开我的“三国会议”，和开发、测试、和其它团队的领队或代表，对所有的请求进行逐个审核，讨论对策、做出应付的决定。在会议上，打开Raid工具，并将计算机显示的数据通过投影仪投射到会议室里的一个大屏幕的荧光屏上，使得参加会议的人都能看到同样的内容。每天的会议我首先搜索所有的ConsiderBug（Raid/VSTS这样的工具可以根据图２中不同的标准进行搜索），Raid就会用列表的方式将所有的ConsiderBug给列出来。然后我就可以根据某个衡量标记来进行排序(Sort)，比如，根据问题的优先级(P1-P3)、严重性(S1-S3)等等来排序，Raid/VSTS这样的工具就会将列表重新排列，比如将最优先的排在前面、同样优先级别的则将最严重的排在前面，等等。先搜索和处理ConsiderBug，也就是先考虑自从前一天的会议以来新发现的“加以考虑”的Bug。就像图１所示，所有新发现的问题都先用“加以考虑” 提交“三国会议”作处理，所以这个做法就是保证新找到的问题马上得到团队的审核和做出相应的决定。对所有的问题和更改请求我们做如下的处理：•对设计的问题进行改动：如果改动请求是要求增加功能、或发现原来的设计有问题、或是Spec里面有错误、需要做改动，这类的更改要求就是DCR。如果是小问题、很容易改动，我们就将这个Bug的属性从Consider换成MustFix（必需修正），同时将更改的类别划分为SpecIssue（设计规范书问题），把它分配给相关的项目经理去对设计规范书进行修订。如果设计改动是复杂的大问题，那么我们就将这个Bug的属性从Consider换成Investigate（进一步调查），分配给相关的项目经理先去调查新设计的方案，然后将调查结果再次通过Consider来呈交。•对软件的缺陷进行改动：如果改动请求是因为在软件中找到了一个Bug、要求批准将其纠正，那么我们对它采取如下处理：根据具体的情况来决定是接受改动请求或拒绝请求。如果“三国会议”在做了分析和评估后认为这个改动的请求合理或足够重要，我就将这个Bug的属性从Consider换成以下某个种类：MustFix(必须修改)、Investigate(做进一步的调查)、等等。如果是需要作修改，则进一步将更改的类别划分，根据具体实际情况按照图２中右边的某一个种类来设定。这样的纠错修改不仅是对软件源代码纠错可用，对整个产品开发中碰到的其它问题和缺陷的纠错也同样可用、例如文档错误、使用界面设计缺陷等等。•拒绝改动：不管是设计改动请求还是对软件源代码纠错的请求，在很多情况下我们的决定是拒绝进行改动。造成这样的决定的原因很多，就如图２中左边所列出的。碰到这一类情况，则进一步将拒绝更改的理由的类别划分，根据具体实际情况按照图２中左边的某一个种类来设定。 处理完所有未加处理的ConsiderBug之后，接下来我再搜索所有的ActiveBug，列出来让会议参加者一起讨论。这些Bug是在以前的会议上已经作了某个决定，但是仍旧还未解决的问题。通常我先查看所有的以前会议上设定的InvestigateBug，看看这些应该做进一步调查的工作还有多少没有完成。接下来，查看有多少P1或S1的纠错还仍旧处于没有完成的状态。因为从图1中你可以看到，任何缺陷被纠错之后，进行纠错的人应该将缺陷的状态从Active转换成Resolved，所以任何仍旧处在Active状态的Bug就说明开发团队还没有对它们进行纠错的工作。通常，我们还将各种Bug按照重要性和严重性进行排列和比较，以及挑选某一个缺陷的属性、种类等进行各种搜索和排列，比如查看某一个软件组件的Bug数量、某一个开发工程师的Bug数量、等等。有的时候，我们会把Bug数量最高的工程师的名字公布出来，开一些善意玩笑，以此来激励每个人都必须及早完成他们的纠错任务，比如谁的P1Bug数量最多，就在他办公室门上挂一把大扫把。那些得到大扫把的人会自觉尽快完成纠错任务，可以将这个象征羞愧的扫把挂到别人门上去。进行这样的纠错记录和历史的查看，能够帮助我们洞察到很多项目进行状态的情况，让我们了解到整个软件的总体质量、每个团队的工作质量等等。比如说，你可以搜索和查看在过去的一周或一个月里有多少新发现的Bug、有多少得到Fix的Bug，这两个数字的比值就是发现率和纠错率(Find/Fix Ratio)的比较。这个度量值告诉了我们目前按整个软件的总体质量状况：如果新的缺陷的发现率高于每天被完成修改的数量(发现率>纠错率)，那么软件源代码的质量还远远不过关。　与此类似的对各种缺陷的统计是极为重要的衡量软件开发质量的度量。我在书中一共列出二十种这样的衡量度量。进行这样的衡量，能帮助你对整个开发项目的进度、是否能够按时完成、是否能够达到预期的质量要求等等，提供一个极为难得的指南。正因为如此，在微软的众多开发团队中，我们常常将这样的各种项目执行状态数据和质量度量的衡量值绘制成大张图表，张贴在开发团队工作的办公桌走廊里，让大家一目了然地随时了解项目的质量和进度。在一个办公楼里我们常常会看到众多这样的张贴。这样的度量值我们也拿它们来开玩笑或给团队提出挑战。有一次在纠错上已经落后的开发团队做出保证：一定在一周内将纠错率赶上测试团队的发现率，不然他们的领队愿意被测试团队剃光头。测试团队当然不甘心、就与他们展开比赛。最后结果是不仅开发团队的领队被剃了光头，测试团队还叫公司的记者来采访，将剃光头的照片登在全公司的新闻公报上。到下一个版本的开发时，开发团队就主动努力保持纠错率在一定的数量上。建立自动接受代表组织决定的良好习惯 一旦对更改请求做出了决定后，像Raid/VSTS这样的工具可以立即将三国会议的决定通过Email将各种纠错修改的任务通知开发团队的开发工程师们。这也是使用统一的工具的好处，大大加强了管理的自动化程度。开发团队的任何人也可以在任何时候使用同样的工具对分配给自己的任务进行搜索和查看。最后我需要提到的是，光有工具的使用是不够的，还必须要有与之相配的规章制度。除了大家都应该遵守任何更改请求通过统一的工具来呈交之外，采用这样的更改控制有助于建立一个自动接受代表组织决定的良好习惯。这个用类似Triage的形式作为决定的权力象征有它的一个独特的奥妙，即任何决定可能有争议性的时候，将决定与任何个人分离开来，而用一个团体来代表决定的过程，这样可以避免人与人之间为不同意见而带来的摩擦、争吵和不愉快。往往某个差错该不该纠正，开发团队的人会有不同意见。如果一个改动的决定是由某个项目经理或某个测试工程师强加到某个开发工程师的头上，一定会造成两个人之间的争论或不愉快。三国会议的形式将任何个人的喜好、取舍和决定，经过会议内部的争论、通过少数服从多数这样一个民主决策的过程之后，变成一个组织机构的决定。开发团队的任何人都愿意接受由三国会议传下来的决定，因为大家知道，每个决定在做出之前，已经经过三国会议内部的争论，各方面的因素都已经都被审视过了，决定来自于一个群体而不是一个人。所以这种方法可以很容易使所有决定得到贯彻执行、同时又避免不必要的人为摩擦和不愉快。在微软产品开发过程中，任何人可以将不同意见拿到三国会议去讨论和争论，可是经过讨论和争论后，结论一旦做出，所有人都被期望去不折不扣地执行。事实上，凡是Triage所做出的一切决定，从来没有被拒绝不执行的。这也是微软的这一管理实践和文化的巧妙和利害之处。 微软的这套深具灵活性的运作方法和它独特的优越性，是它的产品开发管理中真正的精华所在。它是一个看似简单、容易理解，却又是一个真正考虑到软件开发项目特性的、融合进传统管理理论中最优良因素的管理方法。现在，VSTS这样的工具已经公开发行，你也应该去推动你的开发团队建立和执行类似这样的开发执行的运作管理，来大大提高你们开发组织的效率。在下一期的文章里，我们再来讨论如何运用这些质量度量来帮助进行软件开发的质量管理、和进行测试实践的一些指南。  软件开发过程中的测试管理-系列（五）从上一期中的连载文章开始我将系列文章的重点转到了项目管理的具体执行的内容上。这篇文章中我继续来讨论与项目管理执行有关的具体工作和方法，着重讲解软件开发的测试工作。测试是开发中必不可少的工作首先，一个软件产品或系统的开发成功，不仅仅是编写完为使用者提供服务功能的程序而已。软件程序编写的完成，其实只是完成了开发任务中的一半。与程序的开发相配合的、具有同样重要性的另一半工作，是对开发完毕的软件所进行必要的测试。对测试的管理和执行，其重要性不亚于对程序本身的开发。你可以花费巨大的资源和努力进行程序的开发，可是你要是没有与此配套的完善的测试，所开发出来的软件往往会因为质量问题无法满足客户的要求和帮助你赢得市场的竞争。 近几年来国内信息业界的软件开发的成熟程度大大提高，很多公司都开始重视软件测试的重要性、并建立了与此相关的组织结构来保证测试工作得以执行。但是忽视或轻视测试工作的不良习惯和企业文化仍旧普遍存在。在中国项目管理俱乐部的网站上有业界的同仁们反映了这样的情况：他的公司居然还采用所有的软件开发人员都只做程序编写、只有一个人担任软件测试工作这样一种组织结构，而且这个公司的领导认为只有程序的编写才属于实际的开发工作，因此只知道夸奖程序编写人员的工作成果、完全忽视测试人员的贡献。虽然这样的近于荒唐的例子可能是极少数的极端现象，但在相当大比例的软件企业中测试人员往往仍旧是被当作“二等公民”看待，好像他们只是开发人员的配角而已，对软件最终是否合格和能否发行的判决，并没有实际的影响力。一个成熟和高效的开发组织应该、也必须采取与此完全相反的做法：将软件的测试和开发放到同等重要的位置上，对软件的测试和开发给予同样程度的重视。这种项目管理的理念就要求对软件测试给予与软件开发相同的资源和支持，用同等的组织结构和人才来保证软件测试得到严格的执行。微软公司就是用组织结构来保证产品开发的运作流程充分体现对软件测试的尊重、承认测试的重要性。微软总部各个产品部门的所有开发组织都有与程序开发团队并列的测试团队–任何开发组织都是由项目管理、软件程序开发、和软件测试三个并列的团队组成。这样的“三驾马车”的组织结构，保证了测试团队是一个独立于程序开发团队之外的机构，软件测试的结果和测试人员的观点在这样的组织结构中不会被程序开发人员随意推翻或践踏，测试人员能够大胆申诉测试结果、坚持测试的判决、包括阻止不合格的软件发行。我在Windows操作系统部门进行视窗嵌入式操作系统的开发工作时，就碰到过好几起因为测试团队坚持测试结果的审判，从而阻止了开发团队能够按时发行开发完毕的软件的情况。敏捷模式中的测试驱动开发事实上，现在最新的软件开发项目管理的模式之一甚至将软件测试的优先权提高到高于软件功能本身的开发之上。在敏捷模式（AgileModel）实践范围中的测试驱动开发模式（TestDriven Development，简称TDD）要求将软件的测试机制和可测性首先开发到软件中去，把对软件进行测试的功能作为软件功能开发的不可缺少的一部分来对待。它要求所有软件功能组件都必须有自己的进行自我的单元测试的机能、并且要求程序编写人员在开发软件的功能程序编码之前，先开发进行这些功能自我测试的程序。测试的程序编写完成之后，就开始进行单元测试的运行。这时候，由于提供功能的程序源代码都还没有编写，所以刚开始的时候这样的自我单元测试当然都是通不过的。当这些单元测试都能运行之后，开发团队然后才开始编写每个单元里面的具体功能的程序。由于进行自我测试的程序已经完成了，每个功能开发完了之后，开发人员就马上可以启动单元的自我测试程序。要是单元的功能程序开发得完善，这时单元的自我测试就能通过，单元的开发就算完成了，测试人员再进一步进入到下一步的其它测试，比如使用案例的测试和系统整合的测试，等等；要是单元的功能程序在开发中有问题或缺陷，这时单元测试就还是无法通过，那么开发人员和测试人员就先集中精力来分析到底是什么缺陷和错误造成单元组件的功能程序无法通过那些自我测试，然后可以根据测试失败的症状进行单元功能程序的纠错工作。举例来说，如果我们需要开发一个进行文档选择的功能组件。采用传统的开发方法的话，就是开发人员先将文档选择的功能程序开发出来，然后进行黑箱效应测试，证实文档能被选择之后就完了 。采用TDD的开发方法，我们就不是先开发如何选择文档的功能程序，而是先考虑这个组件该如何进行单元测试。所以开发人员先编写在文档选择的使用过程中进行检测可能出现差错的测试程序。这些测试检验代码的白箱效应的测试，比如进行文档选择后的数据检查、以及程序的逻辑检查等等。等到这些单元测试程序完成并能够运行之后，再开始编写实际的文档选择的功能程序。每个局部功能程序编写完毕就立即运行单元测试，直到单元测试全部通过为止。这时开发人员也可以根据软件构架设计的有求，对功能代码中的一些运算方程函数进行模块优化性的分解（也叫Refactor），除去任何重复的代码等等。任何源代码改动和分解之后，必须再次运行所有的单元测试，直到全部通过后才进行证实使用方案的黑箱效应测试，比如检测文档选择正确的结果、选择错误的结果、文档打不开的结果、文档找不到的结果等等。  这样的开发运作流程和管理的理念是，所有的程序都应该有它的可随时启动和利用的测试机制（TestHarness），而且这种测试机制应该是每个软件功能组件单元的不可分割的一个组成部分。我们首先开发这些提供测试机制的程序，建立一个可供测试的框架。然后通过先测试失败、加上功能后然后造成测试成功这样一种反面性的验证，来证实开发出来的软件是符合所设计的测试要求的。所以你可以看得出来，测试驱动开发的模式的主导思想是为满足测试而开发。 比喻来说，这就好像是修建一条铁道线，得先把铁路轨道的标准定了、轨道先铺上，然后再在铁路上运行与轨道宽度标准相符合、专门为它而造的火车。铁路轨道的宽度标准决定了所用的火车必须遵循的宽度。所以可以说，轨道宽度标准是一个制约了火车合格标准的框架。先有了这个框架可以很容易地证实造出来的火车是否符合要求。当然，你也许可以不顾宽度标准先造个火车再说，但这样造出来的火车不见得能在轨道上跑：要是轮距宽度不符合轨道标准，你就得返工重做。TDD的管理模式就是这个先造检测标准的理念在软件开发上的运用，就好像是你先定好轨道的宽度，然后说：按照这个标准造火车，不能在这个轨道上跑的火车就自动不合格；TDD的管理模式使开发人员建立同样的思路：按照这个测试标准去开发程序，通不过这些测试的软件就自动不合格。这样的开发方法有很多好处，最明显的好处是“强迫”开发人员在设计程序的同时，并列进行必须进行的单元测试设计，催促你去思考如何验证你的程序单元的逻辑正确性和单元的完整性。更重要的是，这样的开发模式有助于推动进行自动化测试的工具程序的开发、提高测试的效率，因为那些事先设计好的的单元测试程序，在单元的功能程序编写过程中，可以被随时使用，来验证所开发的功能程序部分是否符合要求。这样的开发项目管理模式和理念，很明显地是将软件测试的作用和重要性提高到一个开发战略的层面。测试不再是简单的开发完毕后再考虑使用的质量管理的辅助手段而已，而是衡量软件在开发过程中每个单元组件是否能够通过，可以说是掌握了项目进度的“生杀大权”。这个开发管理模式相对来说是一个比较新颖的方法，它对传统的开发流程的项目管理造成了不可避免的冲击，因此并不是很容易被开发团队接受，特别在绝大多数的在开发人员说了算的企业文化里，这样的开发方法的使用和推广很容易受到开发团队的阻力，因为它不仅用开发流程的改革来承认测试的重要性，并且由于开发人员被要求进行单元测试的开发和执行的额外工作，开发人员的工作量和习惯也都需要作一定的改变。 但是毫无疑问，这个项目管理模式所能够带来的巨大好处是有目共睹的。这也是为什么这几年来在业界中像敏捷模式、TDD模式等新型管理方法在软件开发的项目管理上被越来越广泛地利用。就拿微软本身来说，我们目前也正在进行一场内部的改革项目管理的“革命”：两年前，总部产品开发部门有少数一些项目经理们自愿组成一个推广敏捷模式的兴趣社团，在少数几个开发团队开始推动敏捷模式和TDD等。他们有点像个“地下组织”，因为绝大多数的产品开发团队还是在使用传统的方法，公司也没有人正式倡导敏捷模式等。但是近两年来，采用TDD等模式来充分发挥测试对质量管理起到的好处，很快就得到很多团队的共识，因为那些采用了这些模式的团队在软件质量的增进上有明确的数据可以证实，这种尊重测试的方法为提高软件质量、降低BugCount（缺陷数）、最终帮助开发项目的成功所能带来的巨大好处。在好几次公司的经验交流会上，一些采用了敏捷模式和TDD等方法的团队公布详细的质量管理的数据比较，来证明这些新方法的优越性。微软快速适应变化的特性使得公司很快地也学会支持对新型模式的采用，现在全公司对技术员工进行开发工程教育的部门也开辟相关的课程，帮助一起来推广对敏捷模式和TDD等管理改革的采用，颇有“星星之火快要燎原”的气势。有的团队甚至采用配对的两人坐在一起开发的工作模式：一个人开发进行单元测试的程序，另一个人接着开发功能程序、并马上进行测试。两个人来回使用同一台计算机来完成对某个组件的开发。完善的测试依赖全面的测试计划前面讲述了测试对软件开发的重要性。那么在开发项目管理的运作中，究竟如何执行具体的测试呢？答案是：每个软件都有它的功能设计，通过它们为用户解决某些问题或提供某些服务。测试的目的有两个：第一是要确证这些为用户解决某些问题的功能设计被正确无误地开发出来了，也就是说，如果用户按照所设计的使用方法和过程（我们称为User Scenario，即使用方案），的确能够利用这些功能所提供的服务和解决问题；第二是保证软件在被使用的情况下，如果使用者并不按照所设计的使用方案在使用软件，它不应该由于任意的使用、或其它外部影响造成任何问题，包括出现差错，比如数据遗失、数据错误、甚至造成系统崩溃等等。为了达到这两个不同的测试目的，在执行具体的测试时就要采用不同的测试方法。为达到第一个目的、也是最主要的目的，最佳的方法是根据所设计的每个功能和使用方案，设计一个相对应的测试执行过程，去验证这个功能或使用方案是能够从头到尾完成的。这个测试执行过程的定义和描述我们称它为测试方案或测试案例（TestCase）。要能够确证所有功能的确是准确地被开发出来了，唯一的办法就是为每一个使用方案都设计出大量的、一套完整的测试案例（在微软的产品开发中往往都是几百甚至上千的测试案例在测试中被使用），然后通过对这些测试案例的按部就班的执行来证明软件的确可以完成所设计的功能。测试案例的全面性和完整性最终决定了为达到第一个目的测试的质量。要能够做到制定完整的测试案例，就需要有一个可以作为依据的纲领性指南，帮助测试人员设计这些案例。这样的纲领性指南是由一份叫做测试计划的文件来总结的。测试计划在软件的设计规范书的基础上进行总结和撰写，根据具体的软件和使用要求，制定出整个软件产品的总体测试构思和设想、测试总体范围、对测试方法和测试自动化工具的要求和定义等等。在测试计划的基础之上，测试工程师们根据它再进一步制定详细的具体测试方案。至于测试计划该怎样写，该包括什么内容，我在《软件开发项目管理》一书的第十一章里有详细的测试计划文件的模版你可以参照使用，这里我就不再重复了。 应该同时满足测试的两个不同目的但是光进行测试案例的执行、按照事先设计好的使用步骤来测试软件的使用状况，只能达到上面所讲的第一个目的，却无法满足第二个目的。原因是，当你的软件在众多的使用者手中被使用时，用户们不见得一定会按照你所设计好的、或所期望的步骤来使用软件，而是任意地使用的。这个时候软件就有可能由于设计得不当或内部的缺陷而发生各种不同严重程度的问题。这一类的问题光用测试案例的执行不见得可以找得出来、而且通常往往是找不出来的。所以与执行测试案例的执行相并列的，还需要进行一系列的与正常的使用方案并不一样、甚至毫无关系的测试。这一类的测试是尽量找出在非正常或随意任意使用的情况下可能出现的Bug。对这样的测试目的，我们采用两种手段来达到：第一种手段是由测试团队设计并执行各种非正常性的测试，包括边界测试、压力测试、安全测试、以及进行一定数量的随机任意性测试（这些测试种类的详细定义见书中的解释）。这样的一些测试可以找出很多在正常使用情况下无法发现的缺陷。但是光靠测试团队的有限人力和资源，还是无法照顾到大量的随机任意性状态下可能发生的出错情况。所以你还得想办法“动员群众”来达到最好效果。微软的企业文化在这方面有两个很有意思的传统，值得国内业界的借鉴：第一个叫“抓虫大扫除”（BugBash）：在某一个版本的发行里程碑到达之后，在发行之前项目经理向全体开发组织发出通知，告诉大家哪一天的某个时间是Bug Bash的时间，到时候全体成员，包括开发、测试、文档等团队、甚至市场部门的员工，全都放下手中的工作，在规定的那一个或几个小时的时间里，每个人把自己当作是用户一样来使用这个未成品的软件，并且进行竞赛，看谁能找到最多的Bug。这样做的目的是，不是按照测试方案的顺序来检查软件，而是通过像真正的用户那样来使用软件，即完全是任意性的、无规则的顺序，看看在这样的使用条件下，还有没有仍旧没有被发现的严重的Bug。我们往往采用谁找到最严重的Bug就得奖的方法来鼓励大家尽力找出Bug。抓虫大扫除一结束，项目经理马上进行新呈交的Bug数量的统计，然后向开发组织中的全体员工公布。得奖的小有免费的咖啡、午餐、电影票等，大有各种礼物。所以每次BugBash大家都踊跃参加，找到很多测试案例执行时没找到的问题。抓虫大扫除对任意性的手动式的测试很有效，但对任意性的自动测试则效率有限。所以我们又采用第二个手段：“分享大家的计算机”（MachineShare）：当我们在测试服务器产品时，需要模拟成千上万的使用者同时使用服务器的情况、或是需要模拟大量的黑客攻击的情况。这时候测试团队的机器往往不够用，还需要大量额外的机器加入到这样模拟中来。这时测试团队就会去逐个请求其他员工、请他们在下班后不使用计算机的时候，在他们的机器上运行模拟大量使用或攻击的程序。谁的机器上的程序造成了服务器的崩溃或造成攻击成功，这个机器的主人就会得到一个免费的冰淇淋。有个人的机器连续三次攻击成功，测试团队还制作了一个巨大的冰淇淋画像挂在他办公室门前的走廊上，第二天上班大家都看到、并昵称他为黑客大王。  总结以上综述，完善的测试是保证软件质量的关键手段，而要做到测试的完善，需要制定完善的测试计划，同时还需要开发团队为达到两种测试的目的进行带创意的各种执行手段来找出各种缺陷和差错。 这里对测试计划的管理理念以及TDD等概念作了一个简单的介绍。有关测试计划的细节、测试方法的种类等，你可以进一步参阅《软件开发项目管理》一书。在后面的连载文章里，我会再来阐述和讨论采用敏捷模式进行开发的一些实践指南。你要是对如何进一步提高你的软件质量有兴趣或有责任负责推动项目管理的改革，可以通过网络进一步了解业界在这方面的发展以及最新的动态。