软件项目进度控制之浅析.doc
软件项目进度控制之浅析 众所周知 ,软件项目有其特殊性。首先 ,软件产品是无形的。软件项目管理者不能像其他项目管理者那样 ,能够从被开发的产品上看到进度、已经完工的部分是否与设计相符等 ,他们只能从其他人所提交的文档中来掌握相关的情况 ;其次 ,没有标准的软件过程。对软件过程的理解虽然已经取得了长足的进步 ,但是软件管理者还是不能确切地预见某一软件过程何时有可能出现问题 ;再次 ,软件项目常常是“一次性的”。由于软件项目与一个国家、地区的经济政策相联系 ,与用户的发展战略、经济实力、管理水平相适应 ,软件项目的开发过程中所采用的技术和管理方式与当时 的计算机和通信技术有关 ,因此大型软件项目一般都不同于早先的项目 ,管理者纵使有在计划中降低不确定性的经验 ,也很难较准确地预见问题的出现 ,以前的经验教训也较难在新项目中发挥大的作用。 从目前国内外的软件企业来看 ,“软件危机”的阴影仍然存在 ,软件行业的项目实施情况一直很不乐观。研究表明 ,软件项目失败的原因主要有两个 :一是应用项目的复杂性 ;二是缺乏合格的软件项目管理人才。实践证明 ,缺乏有效的项目计划与控制是导致软件项目失控的直接原因。 软件项目中项目进度控制和监督的目的是增强项目进度的透明度 ,以便当项目进展 与项目计划出现严重偏差时可以采取适当的纠正或预防措施。已经归档和发布的项目计划是项目控制和监督中活动、沟通、采取纠正和预防措施的基础。软件开发项目实施中进度控制是项目管理的关键 ,若某个分项或阶段实施的进差 ,及时予以纠正 ;提前预测偏差 ,提前予以预防。 任务本身的工作量估算是否合理 ,进度出现偏差首先要考虑工作量的估算是否合理 ,是否考虑了工作中存在的技术难点 ,是否考虑了项目成员自身的技能 ,是否考虑了其他应该考虑的风险。任务计划下达给项目成员时候应该获取承诺 ,但很多时候获取承诺是无用的 ,是否可以承诺或者是否能完 成承诺跟项目成员的个人经验和技能有太大的关系。 当偏差出在估算上 ,而且后续项目都是采用的相同估算模式的情况 ,调整项目计划往往是必须的了。对于短期型的项目 ,如果这个时候才发现是项目成员技能问题 ,而想通过培训来提高技能以取得立竿见影的效果往往已经是不现实的。 如果项目任务中存在着技术攻关或技术难点需要解决 ,对于这种任务往往是很难估计工作量的 ,而且一旦在技术问题上被卡住往往对项目进度产生致命的影响。唯一的方式就是把无法预测和不透明的东西转换为透明 ,在项目开始之前就应该进行风险分析和应对 ,提前进行技术问题的 预研 ,开发原型 ,积累相关的知识和经验。估算问题的根源又出在历史项目或版本对项目历史数据的采集和分析不够 ,准确的估算依赖于专家的经验 ,但专家的经验同样是依赖于历史项目和历史数据。估算问题的根源还在于对项目成员技能和生产率水平没有较清楚的认识 ,一个软件类任务的完成往往存在着巨大的个人生产率差异和进度差异。 对于一个软件项目 ,出现 1~2 天的偏差很容易得到纠正。而如果出现 1~2 周的偏差则很难再进行纠正。任务本身的粒度和工作量直接和偏差的大小相关。当任务本身的粒度太大的时候是不适宜进行跟踪的 ,任务本身是否会偏差不 在取决于跟踪者 ,而是执行者对于大粒度的任务是否有很好的细分和自我控制能力。任何一个任务 ,要么不出现偏差 ,要么出现成倍的偏差。一个任务的粒度如果是 1个月 ,那这个任务很有可能要 2 个月才能完成 ,如果我们的进度偏差最多允许一周 ,则需要把任务粒度细化到周 ,按周进行跟踪。如果对于任务最多允许偏差 1~2天 ,则需要把任务粒度细化到天 ,按天来进行跟踪。细粒度的跟踪目的就是要消除不确定性因素和风险 ,尽可能早的发现任务中的问题 ,这样才有可能有时间来解决问题和纠正偏差。 对于大粒度的项目任务 ,任务内部本身也存在跟踪但一般只能有 项目成员自己进行。任务没有细分 ,成员反馈的任何任务完成 40%、 70%等完成百分比都是不可靠和主观的数据。项目成员的自我监控能力对进度是否偏差起到重要的影响 ,在这种情况下 ,任务是否能够按期完成对项目经理是不可控的 ,因此项目经理必须对成员有充分的了解和信任。