未雨绸缪 软件项目策划成功的要点

  古人云“万事预则立,不预则废”,项目要成功必须做好计划。软件项目策划是项目管理过程中最基本的一个过程,软件项目策划的方法是软件项目经理必须掌握的。在实际的项目策划过程中,必须掌握以下的9个基本要点......

  (1)掌握好项目策划的时机

  软件项目策划过程的输出是文档化的">项目计划书,在项目的不同阶段都需要进行项目策划,只不过在不同时机项目策划的目的不同,花费的工作量也不同。当有了概要的客户需求而没有形成详细的软件需求规格说明书(SRS)时,进行项目策划产生的是项目的概要计划或者是里程碑计划,当产生了详细的SRS 后,项目策划活动可以产生项目的详细计划,可以明确估计项目的规模、工作量、进度、资源等,作为项目管理的主要依据。当发生了需求变化或者项目计划与实际存在比较大的偏差时,可以对项目进行重计划。需要提醒注意的是在需求未确定的时候,进行软件的估计是比较粗略的,此时不需要在项目策划上花费太多的精力。

  (2)任务一定要明确

  在进行项目策划时,建立工作任务分解(WBS)是必须要做的工作,即把

  工作拆分成一个个独立的、明确的任务,所谓明确的任务是指:

  ● 该任务一定有一个输出结果;

  ● 输出的格式有明确的定义;

  ● 输出的内容有明确的检测手段与验收标准;

  ● 任务的时间是有具体要求的。

  上述4个判定标准有一个达不到就不能称为是一个明确的任务。在实践中,有一些任务难以定义的很明确,因为有些结果是难以预测的,比如说分析工作,具体的时间要求是难以准确预测的。任务如果不明确,就无从谈起任务是否做完了。

  在项目组中往往由于前一阶段的工作没做好,造成后续阶段的任务难以明确定义下来。设计没有做完,编码的工作就不能定义的很清楚,就往往会造成实际的编码工作难以在要求的时间内完工,形成项目风险。

  (3)识别的任务不要有遗漏

  在软件策划时,常犯的一个毛病是:任务没有识别全。在项目的实际执行过程,经常出现计划外的、又必须执行的项目组的任务,而不是项目组外的干扰活动。为了识别的任务比较完备,可以建立任务识别指南以提醒项目经理。经常遗漏的任务包括:

  ● 项目管理类的任务,如项目计划、计划的变更、计划评审等;

  ● 横向关联类的任务,如集成任务、需求跟踪矩阵的制定与更新等;

  ● 项目交付物的制作任务,如用户手册的编写、培训教材的编写等;

   (4)任务的颗粒度要适中

  在划分任务时,任务的颗粒度不能太大,也不能太小。颗粒度太大,就难以及时发现问题;颗粒度太小,就会增加管理成本。任务的颗粒度最小可以到半天,最大到周,一般以小于3天为宜,也就是说,项目经理能够在1周中至少检查2次成员的工作进展情况。适当的任务颗粒度一方面便于监控,另一方面也有利于调整任务。当出现任务拖期时,可以比较灵活地重新安排人员接手其他人员的任务。

  (5)估计要尽可能的合理

  为了保证估计的合理性,可以采用下面的措施:

  ● 借助历史数据。历史数据是“经验”的量化,通过和历史项目的数据对比,

  ● 可以降低估计的风险。需要注意的是,在借鉴历史数据的时候,要注意数据的可比性,要考察项目类型是否类似、生命周期模型是否类似等。

  ● 采用多种估计方法互相验证。在估计时可以采用多种估计方法,然后对多种方法的结果进行对比,通过分析其差异以判断合理性。

  ● 细分任务。任务拆分的越详细,就越容易估计,越容易和历史数据对比。

  ● 任务要完备。在估计的时候,要识别出所有的工作内容,不要有遗漏。

  ● 有估计经验的人参与估计。一方面要对参与估计的人员进行培训,另一方面需要在实践中积累估计经验,每次估计完成后,都要和实际的情况进行对比,经过3~5次的反复,则可以积累估计的经验,提高估计的准确性。

  (6)识别清楚任务之间的依赖关系

  任务和任务之间存在下面的5种依赖关系:

  ● 输入输出关系。即A任务的输出是B任务的输入,A任务完成后,B任务才可以开始。比如编码和测试之间的关系。

  ● 资源依赖关系。即A任务和B任务使用同一个资源,当资源为A使用时,就不能为B使用,当资源为B使用时,就不能为A使用。例如一个程序员不能同时做2个模块的开发,必须做完一个模块再做另一个模块。

  ● 需求之间的接口关系。即A任务和B任务的输出存在接口,2个部分的输出需要组装在一起,如果组装的任务是C,则A,B任务未完成,C任务也无法开始。

  ● 调用关系。主要是对编码任务而言,任务A的代码为任务B的代码所调用,则A必须先完成。

  ● 采购关系。如果存在需要采购的外部构件的话,则采购行为必须先完成。

  定义了任务之间的依赖关系,就可以识别出项目的关键路径,以重点关注关键路径。

  (7)优先安排与系统架构有关的需求的开发

  要优先安排关键功能需求、全局性功能需求、接口需求、非功能需求的开发,这些需求影响的范围比较广,一旦返工,工作量比较大,因此在安排任务前要先安排这些需求的设计、实现、测试与联调。在计划时若没有安排好任务的顺序,会造成在项目的后期阶段比如联调时,发现有些模块无法联调,需要写测试程序或者等待其他模块的完成。

  (8)建立项目的里程碑

  在项目进展的过程中,项目经理、PPQA、CM等从项目的不同的侧面对项目组的进展进行了跟踪,但是缺乏全面、系统地分析与评价,借助里程碑评审可以综合各方面的分析数据进行判断。在项目的里程碑处,一般是通过里程碑评审全面地对项目组外部的成员展示项目的进展,以判断上一阶段的工作是否完成,是否可以进入下一个阶段。很多企业往往将里程碑评审搞成了一种形式,成了走过场,这违背了里程碑评审的初衷。在里程碑评审时,要注意是否全面评价了项目组的进展?是否对项目组外面的相关人员展示了项目组的进展?如果里程碑评审仅有项目组内部的成员参加,则往往大事化小,小事化了,掩盖了真实的问题,不利于发现项目组中存在的问题。

  (9)预留管理缓冲

  在项目过程中总会存在突发事件和估计不准确的情况,因此可以在计划中留有缓冲时间。对于缓冲时间可以有2种设置方法,一是固定缓冲,即每周或者月等固定地留有一定缓冲时间,如半天或1天等。二是在所有的与关键路径接驳的任务之前留有固定比例的缓冲,如A任务是关键路径上的任务,B任务不是关键路径上的任务,但是B做完后,才可以做A,B和A是直接的先后时序关系,此时可以在B任务与A任务之间留有一定的缓冲时间,以降低进度风险。

  管理缓冲应可以明确地识别出来,不要隐藏在每个任务中。

时间: 2024-09-21 07:07:25

未雨绸缪 软件项目策划成功的要点的相关文章

《Microsoft.NET企业级应用架构设计(第2版)》——2.2 软件项目的机制

2.2 软件项目的机制 如果你问:"什么导致项目失败?",你得到的最常见的回答可能会把失败归咎到与业务有关的问题,比如说,缺少需求,项目管理不到位,成本估算不正确,缺少沟通,甚至各个团队的人员相互不配合.你很难看到坏代码可能导致问题这种情况. 有鉴于此,我们认为未被发现的BBM可以严重损害软件项目,但未能处理的BBM却可以真的毁了它. 最终,个体以及个体之间的实际互动才能真的决定软件项目的成功或失败.但是,组织结构及其整体文化也会影响最终结果. 2.2.1 组织文化 Apple公司的组

小型软件项目开发流程探讨

一.导言 国内很多项目都是小型项目,参与人员少(两到五个人),要快速交付(一两个月) . 要成功完成这种项目,除了使用成熟且被团队成员熟练使用的技术之外,有一个良好的开发流程,也是很必要的. 二.小型软件项目开发流程 下图是我对小型软件项目开发流程的一个设想: 需求分析的重要性想必大家都应该清楚,对于项目来说,满足用户的需求是第一位的. 因为时间紧,系统设计经常被忽略. 这会留下很大的隐患,国内很多项目的需求通常是很简略的,还需要在系统设计阶段把一些需求进一步的明确. 不然会出现因为前期一些需求

CMM可重复级在特殊软件项目中的应用

引言 由 SEI 在 1991 年 8 月发布的软件能力成熟度模型( SW-CMM ),用来评估软件企业的 成熟度级别,使软件企业了解自己的优势和不足之处,从而持续地改进企业的软件开发过程,提高管理水 平,降低管理成本,保证软件开发效率和软件质量. 然而, CMM 是针对大型项目和企业制定的. 小项目和中小企业由于受到相应条件的限制,如组织结构.角色和关系.过程模式定义等,生搬硬套 CMM 框架只能给自己带来沉重的负担.可取的做法是把 CMM 作为一个参考,从 CMM 评估体系中汲取适合于自 身

2012年最可怕的软件项目事故汇总

数十亿美元就这样打了水漂--今年多个软件项目遭遇失利,此类事故已经引起管理者的高度重视. 诚然,很多企业在软件项目的推进过程中获得了成功,也将供应商所承诺的新特性与新功能顺利传递给终端用户:更低的运营成本.更简洁的管理流程以及各类足以取悦消费者的要素. 但遗憾的是,仍然有一些项目以失败告终:投入巨资的客户只能面对"断瓦残垣"而欲哭无泪,并被卷入危害事业进展.有损合作关系的漫长诉讼当中. 而从积极的角度来看,我们能够将这些过往的事故当作前车之鉴,无论是供应商还是项目客户都能够从中吸取经验

软件项目“免坑”指南

"谁也无法改变现状,唯有无数程序员血洒大地,才能使项目重建天日."这一点也不夸张,软件项目做烂了就是个坑,参与者也不过是填坑的.就像是在魔兽世界战场遇到国家队一样,你赢也赢不了,出也出不去. 一.坑有多深? 当我们进入一个项目时,通过不断观察我们可以发现我们的项目到底是不是一个坑.造坑的项目,往往具有某些"臭味",以下是我的一些认识,这些"臭味"即是项目健康状态不佳的明显标志: ● 编码规范形同废纸,代码质量低下.每个项目都有编码规范,但真正严格

软件项目质量管理与度量

软件项目/产品的质量问题一直困扰软件企业.监理方和甲方,如何预防.发现.治理软件项目/产品质量问题,是目前我国it发展面临巨大的挑战,这也是it发展过程中关注的主要问题.软件企业.甲方和监理方在研发过程中常常要面临很多难题: 1.软件质量管理基础 (1)质量的概念与定义:(2)软件的质量要素:(3)软件质量评价的准则:(4)iso 9000软件质量体系结构:(5)软件质量保证过程:(6)质量管理大师简介:(7)质量管理的发展历程: 2.软件质量与质量管理 (1)软件质量面临的挑战及模糊认识:(2

软件项目,什么叫坑爹!大家注意了

"谁也无法改变现状,唯有无数程序员血洒大地,才能使项目重建天日."这一点也不夸张,软件项目做烂了就是个坑,参与者也不过是填坑的.就像是在魔兽世界战场遇到国家队一样,你赢也赢不了,出也出不去. 一 坑有多深? 当我们进入一个项目时,通过不断观察我们可以发现我们的项目到底是不是一个坑.造坑的项目,往往具有某些"臭味",以下是我的一些认识,这些"臭味"即是项目健康状态不佳的明显标志: ◆  编码规范形同废纸,代码质量低下 每个项目都有编码规范,但真正严

《程序员度量:改善软件团队的分析学》一软件团队是成功还是失败

软件团队是成功还是失败 在体育运动中,每个团队都为胜利而战,而成功的定义也很清晰.精确.软件开发与此不同,我们缺乏对成功的恰当测度.我所发现的最佳策略是软件开发团队的成功三角形,它基于三方面的因素:客户响应.质量指标和效率.这些都能按发布版.特性来测量,并且可以相对于先前的水平.团队目标和组织目标加以评估. 用户对每个软件发布版的响应是什么 开始时,你可以考虑以三个月为周期测量用户对新发布版的采用率是否达到了20%.你能够同设定的目标相比较.为客户响应.质量指标和效率进行这种检测,为团队提供了一

一地鸡毛——软件项目中的人际困局

一地鸡毛--软件项目中的人际困局作者结合切身经历,展示了他之前所在团队软件项目延期的种种原因,而其中印象最深刻的是各种人事纷扰乃至于勾心斗角. 六年前,毕业未久的我在一家外企工作,我所在团队开发的软件项目在交付到集成测试组时因种种原因延期一周.这本身根本不是什么大事情,但其间各种人事纷扰乃至于勾心斗角却着实令我印象深刻. 公司 我的老东家是一家大型跨国电信设备开发商,曾具有辉煌的历史.我还记得在公司110周岁的生日庆典上,一位高管致辞说:"110年,这不是奇迹,是成绩",令人不胜欷歔.