软件开发项目管理

软件开发项目管理的案例解说系列软件开发项目的需求和范围管理-系列(一)引言在今年第一期的程序员杂志中，我对软件开发项目管理的重要性和进行管理的十大工作内容作了一个介绍。你应该已经很清楚地知道今天绝大多数的软件开发已经不是简单地编写一些程序而已，而是一个综合了对多人合作的运作进行必要管理的流程。只要你经历过任何由多人参加的软件开发工作，你一定对整个开发过程是否具有良好的管理对团队的士气以及对开发结果所造成的影响深有体会。一个软件公司或开发团队对软件项目进行管理的素质和水平，是影响到项目是否能够成功完成、开发出来的软件是否能够真正满足市场或客户要求的关键因素。懂得软件开发的项目管理知识不仅仅是项目经理的责任，也是所有开发人员应该掌握的本领之一。从这一期开始，我将在这里用理论与案例解析相结合的一个系列的介绍文章，来阐述软件开发项目管理的更多指南和实践方法。这一期我们从如何进行软件开发需求和范围管理开始，接下来在以后的几期中再分别讨论软件开发项目的计划制定、质量控制、以及项目的执行与驱动的管理指南、等等。常有的项目需求和范围管理的挑战在软件开发项目进行的早期阶段，项目经理以及开发团队的领导们在制定项目计划时所经常碰到的一个令人头疼的问题是：如何有效地设定一个开发项目的范围，也就是如何确定所需要开发的软件的功能范围、质量的要求范围等各种所必须满足的条件以及相应的工作范围。很多项目管理人员和开发团队的领队往往被这个问题所困惑、无法有效地从大量的、貌似互不相连的各种技术、市场、用户的要求中得出明确的需求总结，从而妨碍了制定完善的项目计划。其实这个问题并不是软件开发所独特具有的。任何大型和复杂的项目、包括各种高科技和工程开发项目，都会面临这个典型的问题。是否能够妥善处理这个挑战、并制定出相应的合理的开发项目的计划，是衡量一个开发团队的管理水准的衡量之一。五年前我在从事微软的新一代嵌入式操作系统(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应该很熟悉，但不见得了解操作系统的所有组件结构，对嵌入式操作系统的要求可能更不熟悉。需要与客户教育部门协商决定对用户的培训的要求以及使用说明书的要求P1B…3FunctionalRequirements(功能需求):AXPE产品的开发工具为客户解决的第一个最主要的开发问题是：为客户提供一个能够快速、简易地生产基于WindowsXPPro基础上的嵌入式设备所需要的、经过客户个体化了的轻型操作系统。整个生产个体化的轻型操作系统的功能必须要经过对使用方案的确证。见使用方案总结的一章。P1BXPE产品的开发工具为客户解决的第二个最主要的开发问题是：客户要能够方便地加入他们所开发的嵌入式应用软件，然后将整个操作系统的映像部署到嵌入式设备上。加入客户应用软件的功能必须要经过对使用方案的确证。见使用方案总结的一章。P1CXPE产品的开发工具为客户解决的第三个最主要的开发问题是：客户要能够将他们自己的嵌入式应用软件进行模块化的组件生成，使得他们能够有效地控制操作系统映像的大小，满足小型嵌入式设备的生产需要。P1DXPE产品的开发工具应该将开发商进行开发的设计过程用专门的文档储存下来，使得开发商能够很快地一个设计重新载入开发工具，在为不同的设备进行开发时能够很方便地使用已有的类似的设计。P1E…4PerformanceRequirements(性能需求):AXPE产品的开发工具在使用者变换显示界面时不能有超过分之一秒的延迟。P1BXPE产品的开发工具在下载操作系统的组件的数据库信息时，显示列表的刷新的延迟不能超过1秒。P1CXPE产品的开发工具在生成新操作系统时的总体时间不应超出5分钟，而且必须要有生成进度显示(ProgressBar)。P2E…5QualityRequirements(质量需求):AXPE产品的开发工具在开发阶段必须经过代表软件质量的12个质量属性的测试验证。具体测试要求见测试计划文件。P1B开发工具在发行前必须通过发行的里程碑终点衡量质量标准。具体要求见里程碑终点衡量文件(ExitCriteria)。P1C开发工具所碰到的任何使用错误必须显示于此相关的准确错误信息(ErrorMessage)。所有错误信息必须包括3个部分：出现的具体错误，造成错误的原因，以及如何采取纠正的步骤以消除或避免错误。参见本规范书中对错误信息设计要求的部分。P2D…等等因为篇幅关系，上面这个表格只是一个经过彻底简化了的内容，九个方面的需求分析中的每个方面我只列了几个因素，而实际的文件每个方面的因素至少有几十个之多。但从这个哪怕是十分简单的例子中你也可以看得出来，在开发项目进行计划的第一步，作为项目经理或团队的管理人员，对所有影响到一个项目的各种因素进行思考和验证的重要性。参照以上图1中的需求管理的考虑因素，从九个方面对开发的要求进行分析和总结，可以帮助你很好地照顾到和把握住应该考虑的各种因素、而不至于遗漏掉重要的东西，从而达到对项目的工作范围起到良好的控制和管理的目的。将这些因素用列表的方法总结出来，可以有效地引导项目参加者和团队成员一起来帮助审核各个需求分析，它同时对整个开发团队在项目的早期建立开发目的和任务的共识也极有帮助。2)从使用方案进一步确定功能需求：光有一个高层次的需求总结对确定开发项目的范围还是不够的。要建立完整的开发计划，项目经理或开发团队的领导人员还必须对每个具体的软件功能进行确定。那么怎样从一个高层次的需求总结得出具体的功能设计呢？答案是，最有效的方法根据高层次的需求总结，设计出完整的使用方案，我们把它叫做UserScenarios。所谓的使用方案设计就是，将用户会怎样使用你的软件为解决某个具体问题的整个过程给想象和设计出来，而且应该是一个完整的、从头到尾的使用过程。有了这个过程的总结，再从它的基础上进一步确定每个功能的具体需求。这些具体的功能需求也是需要用文字总结之后，经过整个团队的审核和确证才确定下来。这样的审核与确证可能要来来回回好几次才能最后确定。但是一旦确定之后，它就是一个较为成熟的总结了，它应该包含了整个开发团队对开发的目的的共同认识和意见的回馈，它同时也是对整个开发项目的范围的一个较为完整的确定。采取我在软件开发项目管理一书中所阐述的从使用方案到功能设计的“三步法”，有了完整的功能需求总结之后，才进行最后的功能设计。这样你就可以保证，所设计和开发的每个功能都有于此相对应的功能需求、有于此相对应的使用方案，而不是毫无目标的、仅仅是因为看起来很“酷”而开发的功能。请参见《软件开发项目管理》有关这方面的论述。3)从软件的质量属性来帮助确定范围：对软件开发项目的范围进行管理的另一个步骤和有效方法是，针对软件质量的12个属性进行对照，由此向客户、市场部门、或领导确定哪些是重要的、我这个项目是必须达到的要求；哪些是次要的、我这个开发可以疏忽的。这个管理方法的指南原则是，代表了一个软件质量的所有属性有的是有冲突的–见下图：质量标志之间相互融合或对立的关系图2：质量标志之间相互融合或对立的关系图中所示的“+”号表示两个不同的质量标志属性相互融合、不矛盾。如果加强某一行的一个质量的属性，那么这个努力会使得所相对的带