软件开发项目管理常用技术介绍 - 其它资料

当前位置：信管网 >> 其它资料 >> 文章内容

软件开发项目管理常用技术介绍

来源：信管网 2012年07月28日【所有评论】

一般项目管理的常用技术在软件开发项目管理中同样具有价值，是项目管理的效能推动器。这些技术主要包括工作分解结构、里程碑、关键路径法、计划评审技术、S曲线、挣值管理、目标管理、责任矩阵、资源需求直方图、图表化、头脑风暴法、KJ法、蒙托卡罗模拟法、检查清单/模板、基础统计技术等。

工作分解结构

工作结构分解(WBS：work breakdown structure)是将项目完成之前的所有必要作业项目从上到下层次性罗列出来。WBS是项目管理的起点，WBS的设计可以说是项目管理的最重要工具。项目管理的第一步是项目范围定义，明确项目的交付物，进而定义项目需要进行的活动、角色、责任以及项目组的结构。项目范围定义可以使用WBS，将项目的“交付物”自上而下逐层分解成易于管理的若干元素，组成一个树状图。WBS每细分一层都是对项目元素更细致的描述，细分的元素称为工作细目，其中最低层的工作细目即树状图的叶节点叫作工作包，工作包定义了需要达成的性能、质量、日程和成本。为了便于分层统计和识别，WBS中的每个元素都被指定一个惟一的标识符，并分层表示。制作WBS的注意点是：不是以现存组织为基准进行作业分解，而是以“做什么”为基础，从零开始进行作业分解；不是项目管理者一个人单独制作，而是项目组成员共同制作；WBS的任意层次的要素都需要具有(1)工作范围明确、(2)日程确定、(3)具有成本计划(预算)、(4)资源已经分配、(5)具有业绩测评尺度、(6)组织责任明确等特征。

计划评审技术

计划评审技术(PERT：program evaluation review technique)是用网络图来表达项目中各项活动的进度和他们之间的相互关系，并在此基础上进行网络分析，确定关键活动与丶?/span>路线，利用时差不断地调整与优化网络，以求得最短周期。然后，还可将成本与资源问题考虑进去，以求得综合优化的项目计划方案。PERT可以表现出工作包或者活动、担当者、交期、日程以及各活动之间的依存关系等等。PERT与WBS相互关联和支援，使用PERT有赖于WBS的完成，但是PERT的制作又可以发现WBS的遗漏。PERT着眼于项目管理者应该考量的“质量、成本、交期(QCD)”，是质量最佳化、成本最小化、交期最短化的分析工具。PERT不拘泥于细枝末节，而是着眼于发现将来要直面的重要课题和问题点，从能否实现项目目标而不是各工作包的角度进行分析。首先从微观角度制作PERT，在考量各工作包的重要性以及相关性的基础上着眼于QCD相关内容：里程碑的设定；项目风险的挖掘；项目瓶颈的抽出；人、财、物、信息、时间等项目资源的最佳分配；项目成员的最佳配置；工作包与活动的统合；工作包与活动的分解；现有资源的灵活运用；工作包之间、团队成员之间的整体效果的分析；最短路线、重要路线等关键路线的确定；活动顺序的妥当性。

挣值管理

挣值管理(EVM：earned value management)是综合项目范围、进度计划和项目资源，测量项目绩效的一种方法。挣值管理通过比较计划工作量、实际挣得多少与实际花费成本，决定成本和绩效是否符合原定计划。挣值管理将计划与挣值换算为成本，并通过与达成实绩所用实际成本的比较来对项目的实绩进行度量和分析，可以说是成本与进度的统合控制管理工具。挣值管理也离不开偏差管理。

在项目过程中，通过监视成本差异和进度差异以及成本效率指数、进度效率指数的变动，预测超过成本和进度滞后的情况后采取对策。在分析计划与实绩差异的原因及对策时，可以使用图表化、头脑风暴法+KJ法。如果计划与实绩差异过大，就应该考虑缩小项目范围等对策。

头脑风暴＋KJ法

头脑风暴(brain storming)和KJ法都是发现问题和解决问题行动中实施创造性开发的方式。

头脑风暴法又叫作集思广益法，它通过创造一个无批评的自由的会议环境，使与会者畅所欲言、充分交流、互相启迪，产生大量创造性的意见，其目的是利用组合脑力刺激创造性，想出更多更好的主意。其作用在于：打破思维定势，鼓励开放性的思考；发挥集体智慧，在他人的看法上建立自己的意见；打破沟通障碍，形成团队精神；防止少数人控制会议。其实施步骤如下：(1)将头脑风暴的中心议题写在白板、胶片或挂图上，确保每个人都充分理解中心议题的含义。(2)项目组成员轮流发言，任何意见都会得到肯定。轮流的过程鼓励大家参与，但任何人如果没想好则发言可以随时跳过。(3)将每一条意见用大号字写在胶片或挂图上。用原话记录每条意见，不作任何解释。(4)继续轮流发言，直到每个人都没有意见为止。(5)复查意见记录，去除完全重复的条目。小心识别并保留在用词上有极细微差别的意见。头脑风暴法对于认识现状、整理问题、讨论问题过程中挖掘参与人员的意见非常有效。在PMBOK所谓范围、成本、质量、沟通、风险等知识领域的管理中比较有效。

在问题并不明朗的情况下通过KJ法可以使问题逐渐清晰起来。所以，在软件开发过程中，多用于需求分析、业务分析等。在项目计划阶段，对于PMBOK所谓风险管理知识领域中的风险识别、对策立案等方面比较有效。但是，如果理解KJ法的成员比较少，其使用会比较困难。特地集中起来的创意和意见如果仅仅简单加以分类，就难以引出问题点和创意点。

检查清单/模板

在项目执行期间，可以由项目管理团队作成检查清单或者模板(checklist/template)，也可以由项目管理室那样的支持项目管理的组织在项目审查和监督的成功案例和失败案例的基础上作成。检查清单或者模板是组织的最佳实践，通过这些经验的积累可以提高项目管理的效率，有助于防止失败。检查清单用于确认作业或工程是否存在遗漏。模板作为产出物的雏形式样，具有WBS、网络图、需求变更书、进展报告书、合同标准文件等形式。通过雏形的灵活运用，经验较浅的项目管理者可以明白必须做些什么，并能在其他项目中重复利用。

软件开发项目管理检查清单：天气晴雨表

检查清单用于确认作业或工程是否存在遗漏，是反映项目管理是否存在问题的“天气晴雨表”。下面是软件开发项目管理的一个检查清单，比本章中所言“软件开发项目管理过程中的祸根及其后果”更加详细。通过这个清单，可以发现项目管理存在的问题，并采取措施加以改善。

需求式样晴雨表