软件开发项目管理的案例解说(二)
来源:广州软件开发 编辑:广州软件开发公司 日期:2017-03-20
软件开发项目的计划制定 - 系列 (二)
引言
上一期(今年三月份)的《程序员》杂志所开始的软件开发项目管理的系列文章,以一个软件开发项目的需求和范围管理作了开始。我阐述了对任何一个给定的软件开发任务,我们如何利用需求管理的各个因素的考虑以及客户对代表产品质量的12个质量属性的要求来帮助我们确定整个开发项目的范围。这个项目管理的早期工作的目的,是为了帮助我们能够制定出合理的开发项目计划,也就是项目管理的下一步工作。
在这一期的连续文章里,我来论述你在具备了一个开发项目范围总结的基础之上,应该如何制定一个全面的开发项目的计划,以保证你的开发项目能够取得成功,并以我所管理过的开发项目作为案例来说明具体的管理手段和方法…
正确的计划制定过程以及合理的项目时间表的重要性
如果你是一个进行软件开发项目管理的项目经理或开发团队的领导,是否具备一个完善与合理的项目计划是影响到你所管理的项目成败的关键前提。就像缺少一个完善与符合科学规则的蓝图无法去建造一个大楼一样,没有一个完善的、符合软件开发原则和特性的项目计划,任何一个稍具规模和复杂程度、需要多人配合的软件开发项目也无法做到开发的成功。如果你是一个开发团队的开发技术人员,哪怕你虽然并不做项目管理的工作,但是为了你的项目成功的利益和整个团队与公司的利益,你也应该期望并且要求你的团队领导或项目经理为你提供一个合理的项目管理计划。你也有责任积极地与他们一起进行协调和合作,在项目的开始之前共同制定一个完善的开发计划。
那么,一个完整的软件开发项目的计划应该包括什么呢?整个计划制定工作的具体任务和工作的顺序应该是怎样的呢?
我在《软件开发项目管理》一书中对开发项目的计划制定以及管理的运作流程作了详细的论述。下图是该书里的对如何进行计划制定的运作流程的概括总结:
具体的很多细节你可以从书中读到,这里我就将最重要的管理概念以及对与我所要举的案例相关的一些内容做一些解释。从上图你可以看到以下这些进行计划制定的管理和执行顺序的理念:
1. 确定软件的功能:在确定了项目范围的基础之上,第一步的计划工作任务是决定所要开发的软件的功能。而这个功能的确定过程是需要经过一个从具体的使用方案到功能需求、再由功能需求到具体的功能设计这样一个三步法来进行的。所以进行设计的项目经理们应该对软件如何被用户使用的整个使用方案做详细的分析总结。
2. 确定各个功能的优先顺序:在确定了软件的具体功能设计设计之后,你应该将所有需要开发的功能的重要性进行一个优先顺序的设定和排列,也就是确定哪些最重要、哪些次要、哪些不重要。我们通常使用从P1 到P3这样三个级别的优先顺序对所有的功能进行划分和排列。这样做的目的有两个:第一是根据事先定好的重要性顺序来安排开发计划,即最重要的功能先开发;第二是为了应付以后可能碰到的必须砍掉一部分功能的情况的出现做准备(在软件开发中常常会有因为市场竞争或客户要求、或开发完成的推迟而出现的某些功能无法按时完成的情况出现)。在这样的情况下你就应该根据事先定好的准则来做决定,而不是临时任意决定哪些功能可以被砍掉或推迟开发。
3. 确定工作任务单元和进行工作任务的分解:在软件各个功能的优先顺序被确定了之后,接下来根据所要开发的具体功能,确定具体的开发任务、并对各个开发任务进行工作任务的分解,达到一个项目的工作任务分解结构(WBS)。这个工作的过程中有一些过渡性的提交物需要完成:首先是将经过优先顺序排列的功能,绘制项目工作任务的网络图(Project network diagrams),然后采用分解方式进行分解,最后达到一个完整的工作任务单元的排列。(请参照我在《软件开发项目管理》一书中对WBS的做法以及绘制网络图的细节的叙述)。
4. 分配开发资源并进行初步时间估算:当具体的开发工作任务的单元被确定之后,接下来进行开发资源的分配,也就是确定到底由谁进行哪些单元或功能组件的开发。当每个开发工作任务都分配布置了具体的开发人员之后,项目经理应该要求具体执行这些开发工作的人员来进行每个工作单元的时间长度的估算。在这个基础之上,项目经理再将所有的工作任务的时间估算进行汇总,得到一个整个项目的总体时间表。在绝大多数情况下,对有任何并列进行的开发工作的时间表,项目经理还需要进行所谓的关键性通道(Critical Path)的计算,对整个开发项目的工作任务的网络图进行重新的排列和调整,以缩短总体开发时间,如采取将有太多宽松时间的工作任务给缩短、将处在关键通道上的工作分配给多人来完成等等手段,来进一步优化整个项目的时间。在这个基础上来产生整个开发项目的最终时间表。
这里我想强调很重要的一点是:任何一个开发项目只有按照这样的方法去制定开发时间表,才有可能得出一个比较能够符合实际情况的时间计划,因为这样的计划制定的运作流程充分考虑到了开发人员的具体因素。做具体开发的技术人员的实际经历、素质、和水平、和所要开发的软件的具体要求,直接影响到每一个开发工作任务的具体时间长短,因为同样一个开发任务,两个不同经验的人所要花的时间是不一样的。项目的时间估计当然还可以以其他方式来得到,但是只有在由真正进行开发的人员做时间估算的基础上得到的总体项目时间表,才最接近于实际的情况。这一点对软件开发特别重要。有不少软件开发项目因为时间表的制定不符合实际而造成严重拖延、甚至遭到被砍掉的下场,或者领导要求员工们用加班加点的方式来补救被拖延的时间表,最大的原因之一就是那些项目从一开始起就没有一个切合实际的时间表、或者是管理人员不懂如何去制定合理的时间表。那种脱离实际、人为想象的时间估算往往是导致项目失败的祸种,但却偏偏有太多的项目管理人员或领导不在乎听取具体开发人员对时间估算的反馈意见。所以,进行一个从下而上的,由做实际工作的执行人员先做估算,然后进行综合再订出总体项目时间表的方法,是任何软件开发组织必须追求去掌握的管理素质。
完整的软件开发项目计划的两个方面
完善的软件开发项目管理的工作要求管理人员在进行计划时同时照顾到两个并列的、几乎各自独立的计划工作任务:一个是软件本身的计划,它侧重于软件功能的计划、影响到软件的设计;另一个是项目的展开和执行的计划,它侧重于软件开发工作的具体运行和管理、影响到项目最终是否能够按时按质量完成。这两个工作所侧重的计划问题并不是一回事:一个与开发的结果有关,也就是对所要开发的软件本身的计划;而另一个与开发的运作流程有关,也就是开发中具体的工作任务的执行过程的计划和规章。但是这两个因素却又是紧密联结、互相影响、不可分割的。它们相互之间既有独立性也有依赖性。
要对软件开发项目有一个完善的计划管理,所要制定的计划就必须是同时包括这两个方面的计划。上面图中所总结的整个项目的计划制定过程,就是照顾这两个方面的具体体现:第一,软件本身的设计计划在决定了软件功能的基础上,用软件的设计规范书来体现;第二,整个开发过程的计划也是在确定软件功能的基础上,经过进一步的任务分解和资源的分配、由工作单元安排和优化后得到的项目时间表来体现。
换句话说,这样的计划方法是将软件功能的总结,同时作为计划软件设计和计划开发任务的前提,从而使得这两个工作的计划都建立在同一个基础上,同时又用分开的局部流程使它们能够独立完成,使它们都不被忽视。这是一个将它们相互之间的独立性和依赖性巧妙地结合在一起的计划制定的方法。它将两个方面计划的依赖性来互相影响它们各自的结果,使得开发工作执行的计划不是建立在空虚的基础上,而是建立在所要开发的软件的实际功能需要的基础之上。
很多开发团队的管理人员或项目经理往往对软件开发项目的计划的范围感到困惑:到底是计划软件本身的内容还是计划开发工作的细节?它们之间的联系以及顺序是什么?通过对上面图中所总结的同时需要完成设计规范书和工作任务清单的分析,你现在应该明白了,完整的项目计划中这两个方面都要包括,而且要用图中所总结的这个计划流程来运作,才能保证开发工作的任务与所要开发的软件是一致的。这是一个非常重要的需要意识到和理解的管理理念。一个完善和成熟的开发团队或组织必须要求它的项目管理人员或懂得并执行这样的计划制定。
所以一个完善的开发计划最后应该包括两个最主要的计划文件:第一是总结软件中的所有功能设计的设计规范书(Design Spec),第二是一个与开发这些功能完全相应的开发工作任务的时间表(Schedule)。这两份各自独立的计划文件组成了项目总体计划的骨干文件,成为其他计划文件的依据。比如说,开发团队再根据设计规范书所描述的具体功能要求去进一步制定软件的构架设计以及每个功能组件的实行计划的制定;软件测试团队也根据设计规范书所描述的具体功能来制定测试计划和具体的测试方案。同时,进行项目管理的经理们也再根据工作任务分解结构以及时间表来进一步制定项目的开支计划,并同时根据设计规范书去制定其它的项目管理计划,如风险管理计划、进度状态通报计划、外报计划等等。
在下篇的连载中我会再仔细谈设计规范书的具体撰写内容,以及进行功能设计的“三步法”。这里我先将其它有关项目计划的工作内容作一个介绍…
软件开发管理中所需要的其它计划
除了体现软件的设计规范书和体现项目进度的时间表的制定这两项重要的计划文件之外,在项目的计划阶段,项目经理还必须与开发团队的领队和其它成员一起协作来制定其它几个和开发管理有关的重要计划:
1. 确定每个开发阶段的里程碑(Milestone):在建立了开发时间表的基础之上,通常我们都将整个软件的开发过程分成几个阶段来来进行。每个阶段先着重开发一部分功能。这样的阶段的终结点就叫这个阶段的里程碑,用M加一个号码来表示,比如从M0开始,到M1,再到M2,… 等等。
这样的将开发任务分成几个不同的阶段、每阶段分别注重于先完成一部分开发任务的运作方法,对绝大多数软件开发来讲带有很大的好处。这样的运作流程有助于将所需要完成的整体开发任务,采取逐步开发的方法来渐渐加入和整合新的功能,同时又能够对开发出来的各个组件进行循环式的不断修改和调整、对设计上需要作的改动进行必要的调整、对出现的问题进行及时的修正。这种渐进式的开发方法要求对每个阶段的目标在刚开始就有一个明确的定义。因此,里程碑的制定、以及与此相关的每个阶段相对应的具体日期、以及每个阶段的重点任务等,都应该是项目计划的一部分。
下面我继续拿我所管理过的微软嵌入式操作系统工具的开发项目作为案例来说明这种项目管理的思路,以及里程碑计划的典型内容。以下这个表格就是一种对里程碑进行定义的方法之一:
里程碑 里程碑定义 里程碑必须完成的功能
M0
6/1/2000 Code complete for Alpha version
初版本功能开发的代码全部完成 All key features completed: User shall be able to author a basic SLD file. Help content may not be complete.
所有关键性功能都开发完成。用户将能够使用这个产品进行最基本的嵌入式操作系统设定文件的制作。产品的使用说明书的内容可以还没有全部完成。
M1
7/1/2000 QA completion for Alpha version.
初版本的测试完成 Be able to complete all key user scenarios, and including live database support for OS feature selection.
所有关键性的使用方案都能够被完全操作,包括使用实际的操作系统功能组件的分类数据库来选择操作系统的具体功能。
Alpha Release
7/15/2000 初版本的发行
Release to Internal team and JDP partners for dogfooding
初版本向内部发行、让内部用户先“吃狗食”(即开发团队内部先使用还不完善的初版本),并向开发合作伙伴发行。
M2
8/15/2000 Code complete for Beta version
试用版本功能开发的代码全部完成 All major features for beta completed. User shall be able to use all major features: SLD creation and modification, browsing SLD files, browsing DB objects, etc.
试用版本中所有主要功能都开发完成。用户将能够使用所有主要的功能:包括嵌入式操作系统设定文件的设计和修改、浏览设定文件的内容、浏览操作系统功能组件的分类数据库等等。
M3
9/1/2000 QA completion for Beta version
试用版本的测试完成 Visual freeze. All help content authored. Usability test completed.
使用界面的设计冻结。所有使用文件的内容都编辑完成。产品的可用性测试完成。
Beta Release
9/20/2000 试用版本的发行 Release to both internal team for dog fooding, and to general external users for beta feedback.
初版本向内部发行、让内部用户先“吃狗食”,并向普通的外部客户发行,以获得外部客户的回馈意见。
M4
10/15/2000 Feature Complete
所有功能开发完成 All feature completed according to spec. All unit test done. All system tests done. Full regression on all test cases at least once.
在设计规范书里所确定的所有功能设计都完成。所有功能组件的单元测试全部完成。系统测试全部完成。任何所需要进行的回归测试至少完成一遍。
M5
11/30/2000 RC1 Release
发行候选版发行 Release candidate 1 release to both internal and external users. Users shall be able to use all specified features, view all help content. All other document, such as System Developer’s Guide, is completed.
发行候选版向所有内部和外部使用者发行。用户将能够使用产品中所有的功能,阅读所有使用说明文件的内容,以及像系统开发指南等所有其它文件。
M6
12/15/2000 Final QA completion
最终的全面测试完成 All active bugs fixed. No ship stoppers. Full regression test done before all final bug fixes. All documentation, on-line and printing materials, completed the final editorial proofing.
所有的未被修正的缺陷都被修正。没有剩下任何可以阻止发行的缺陷。在总体的全面最终测试之前,所有回归测试都完成。所有文件的内容、不管是印刷的还是电子版的,都完成最后的编辑审核。
Gold Release
12/20/2000 Official RTM
产品正式发行 All release exit criteria met. Product code is released to CD manufacturing and on-line distribution.
所有发行前的终结标准都得到满足。产品的源代码向生产光碟的工厂发行,网上发行的版本同时也上载到网上。
以上只是一个简单的举例,而且每个开发项目的阶段的多少和里程碑的设定,你当然要根据具体的开发内容来决定。但是从这个案例你可以看到,不同阶段的开发重点和要求是不同的,里程碑代表了阶段的终点,到达每个里程碑的象征就是这个阶段的工作任务都完成了、使软件达到了某种要求。这样的里程碑计划确定每个阶段的主要任务和工作重点。
另外,采用像这样的在软件的正式版本发行之前先发行初版和试用版的方法是一个符合软件开发特点的循序渐进的开发流程。它使许多在产品最终发行时可能会碰到的问题、特别是系统整合、最终的汇编建造、以及为了满足产品发行的质量要求所可能碰到的很多质量管理问题,在项目的早期阶段通过这样的“小型发行”(Mini Releases) 被及早发现,使得开发团队有足够的时间去及早解决。所以你在进行开发管理时也应该采用类似的方法来进行开发计划的制定。
2. 制定每个里程碑的离开衡量标准、或叫终结标准(Exit Criteria)。前面第一点的计划是事先确定每个阶段工作的任务和侧重点,但是光有这个计划还不够,因为你如何知道每个阶段结束时你的开发团队的工作结果是否是达到了要求呢?答案是:与每个阶段的工作任务计划相对应的,你还必须要事先制定一个每阶段开发的结果是否达到要求的衡量标准。我们把这些在每个阶段的终点衡量开发结果的标准叫做里程碑的终结标准。这些终结标准明确地订出如何判断项目到达每个里程碑时开发的结果是否符合要求、以及项目的进程是否可以进入到下一个阶段的做决定的衡量准则。
那么这样的终结标准、即Exit Criteria,应该包括什么样的内容呢?再以我上面的案例来说明:你可以看到我当时的第一个里程碑是将产品的最基本和关键的一些功能先开发出来、并不是所有的功能都要完成,而且对产品的功能从用户的角度讲有一个基本要求,就是要能够使用这个产品进行最基本的嵌入式操作系统设计的设定文件的制作,所以这个“初版本功能开发的代码全部完成”的里程碑的终结标准就是要确证这个基本的阶段要求是达到了的。下面是这个终结标准的举例:
嵌入式操作系统开发工具的初版(Alpha)功能开发完成的里程碑(M0)终结衡量标准
□ 嵌入式操作系统开发工具中有关进行操作系统设计的功能必须是能够从头到尾、按照使用方案进行使用的。
□ 嵌入式操作系统开发工具中的为进行操作系统设计的功能组件和提供构架整合的组件必须都完成、并且没有P1和P2级别的Bug (缺陷)。
□ 开发工具中的其它非关键性功能不能有P1 Bug,但可以有P2和P3的Bug.
□ 嵌入式操作系统开发工具中的主要使用界面的菜单、对话框、图标等都必须按照设计规范书的设计完成开发。
□ 嵌入式操作系统开发工具所制作的系统设定文件必须能够生成和储存完整的、能运行的嵌入式操作系统,并且同样的文件要能够打开再次使用,能够重复生产同样版本的操作系统。
□ 嵌入式操作系统开发工具中的为进行操作系统设计的功能组件都必须完成了它们的单元测试。
□ 嵌入式操作系统开发工具中的使用说明文件的内容还没有最后确定,但从工具的菜单上需要打开产品的使用说明书(Help File)的链接必须都要打开目录标题正确的文档页。
□ … (等等)
这里所举出的只是整个M0的Exit Criteria中的一部分,但你可以看得出来,这个早期的里程碑的重点是保证最基本的操作系统开发功能要能够使用,比如保证产品的使用方案都可以从头到尾完成。而产品开发接近结束时的后期里程碑的终结标准就与这个很不一样,它们是着重于发行前的质量保证。比方说,上面案例中的M3的里程碑是Beta版本的质量测试的里程碑,它的Exit Criteria 就注重于必须满足的一系列质量度量的标准。下面是这个案例的M3的终结标准举例:
嵌入式操作系统开发工具的试用版本(Beta)完成的里程碑(M3)终结衡量标准
□ 检验嵌入式操作系统开发工具的使用界面与使用说明书的解释必须一致的测试应该全部通过。
□ 嵌入式操作系统开发工具的使用界面所有P1 和S1 Bug都必须全部纠正。
□ 所有使用文件的编辑内容的测试P1和 P2 Bug都必须全部纠正。
□ 在初版发行之前,未经处理的软件缺陷(Active Bugs)的数量必须是零。
□ 在初版发行之前至少一个星期,开发团队的纠错率(Fix Rate) 必须一直高于发现率 (Incoming Rate)。
□ 被修改的缺陷(Resolved Bug) 必须全部经过验证(Verified),被证明它们的确是被修正了(Fixed/Closed)。
□ 所有缺陷数量的时间走势或趋势必须是在发行前的15 天里一直处于下降状态。
□ 未被修改(Assigned but not investigated) 的缺陷数量必须是在过去的5天里一直处于接近零、而且是在过去的10天里维持在零附近。
□ 在过去的10天里没有发现S1的缺陷、也没有未被修改的S1缺陷。同时,S2的缺陷没有超过10的数量、S3的缺陷没有超过25 数量。
□ 在发行前的7天里,开发团队能够及时修改所有的S1级别的严重性缺陷。
□ 在过去的5天里,任何被重新激活(Reactivate) 的缺陷必须低于被修改过的缺陷数量。
□ … (等等)
这样的终结标准需要项目经理与开发和测试团队的领队们一起协商决定,这样的具体衡量数字是根据质量管理和测试的要求来订的。一旦有了这样明确的终结标准,除非有特别情况,整个软件开发的过程就要严格按照这样的标准来执行。对软件开发组织来说,一个很重要的企业文化是尊重测试团队的工作和结论,它的象征之一就是让测试团队真正来把关。比方说,如果测试团队还没有来得及对所有的Fixed Bugs进行验证,也就是上面第6条的标准就没有达到,这时开发的进度就无法达到这个里程碑,初版就不能发行。
一般这样的终结标准会有十几条至几十条,视具体的质量管理的严格程度和要求来定。有了这样的标准,它还能帮助你有效地与用户和领导进行沟通,对开发进度的状态能够有清楚的通报。
3. 完成其它开发计划:作为软件开发计划工作的一部分,光有软件功能设计的设计规范书还是不够的。当设计规范书一旦通过团队的审核,开发团队接着要以它为基础,进行软件的构架设计,以及由各个开发工程师进行各自的开发设计、并制定开发的实行计划(Implementation Plan);测试团队也需要以它制定测试计划和具体的测试方案。这些计划都是完整的软件开发管理中不可缺少的计划文件。要是你的开发管理流程中目前还没有制定这些关键计划的习惯或规章,你就应该考虑如何通过加入这些计划的制定来帮助你的团队增进你们的开发效率和质量。
除此之外,对大型和复杂的开发项目进行计划时,项目管理人员还应该考虑制定其它一系列的辅助性计划,用它们来帮助加强管理和增进与客户的沟通。这些计划工作的范围包括:
• 软件更改控制以及管理(Change Control Management)的计划:如果碰到设计更改要求,根据什么样的准则接受或拒绝这些要求?对测试中找到的各种不同的重要性和严重性的缺陷,你根据什么样的准则接受或拒绝修正的要求?
• 风险管理计划:你的开发项目中最大的风险是什么?你如何应付由于不成熟的新技术出现的问题、员工的跳槽等等所带来的风险?
• 外部依赖管理:依赖外部团队或外包商所提供的组件如果碰到无法按时完成、或质量出现问题,你该如何面对?
• 文档计划:你的软件产品的使用说明和可能需要的用户培训该如何完成?
• 项目进度通报计划:你应该怎样向客户和领导、以及整个开发团队进行定期的项目进度的状态通报(Status Report)? 通报的频率、内容、读者等等应该是什么?
从这里你可以看到,一个完善的开发项目的管理,需要管理人员充分思考和制定与所有这些有关的计划。如果一个开发组织仍旧还是使用毫无章法的管理方法,你作为开发技术人员也有责任去督促你的经理去学习和采用良好的管理方法和制度。这不仅对建立一个可以让你有效工作的良好环境有直接的影响,更影响到你的公司能否赢得长期的激烈市场竞争的结果。它的重要性不言而喻。
总结
软件开发项目的计划反映在两个方面:一个是软件开发的本身需要有个计划,用它来帮助确定最后成形的软件应该是什么样的;另一个是开发工作执行的计划,用它来帮助确定开发工作能够按部就班地执行,促进软件能够按时按质地被开发出来。对一个软件开发项目制订计划,就是按照这个体现了将两个种类的计划需要结合在一起的流程,去顺序完成各个分析总结工作和需要提交的计划文件,使得开发工作的计划能够与软件本身的要求结合起来。完整的计划工作还要求管理人员制定一系列的其它辅助性计划来帮助加强管理、降低风险。
在下一期的文章里,我们再来看如何制定良好的设计规范书,用它来帮助我们开发高质量的软件。
相关阅读