23 项目规划
- 23.1 软件报价
- 23.2 计划驱动的开发
- 23.3 项目进度安排
- 23.4 敏捷规划
项目计划:在项目开始建立,用于向项目开发团队和客户说明工作如何开展,以及帮助估计项目进展
软件开发项目总成本包括
- 工作量成本(支付给软件开发人员的费用)
- 包括维护在内的硬件和软件费用
- 差旅费和培训费用
开发过程中,为每个软件版本制定一个非正式的项目计划和工作量成本估计,应该让团队所有成员都参与到规划过程中
23.1 软件报价
影响软件报价的因素
因素 | 描述 |
---|---|
市场机遇 | 开发机构可能为进入一个新的软件市场而提出一个低的报价。在一个项目上的低回报可能会换来今今后更大收益的机会,而且获得的经验可有助于开发新产品 |
成本估算的不确定性 | 如果机构对成本估算不太确定,可能增加应急开支项,使得提出的报价超出了一般收益 |
合同条款 | 客户可能愿意开发者保留对源代码的版权,并在其他项目中使用。这样付出的价钱会比将软件源代码交给客户时少些 |
需求易变性 | 如果需求可能会发生改变,机构会降低它的价格以得到合同,在合同签订后,需求的改变将带来高的要价 |
财务状况 | 处于财务困难中的开发者可能会降低报价来得到一份合同。比正常情况下少赚一些甚至亏一点也比没有项目好。在困难时期现金流比利润更重要 |
23.2 计划驱动的开发
- 计划驱动的开发,或者叫做基于计划的开发,是一种给开发过程制定详细的计划的软件工程方法
- 项目计划完整地记录:要完成的工作,谁将执行此项工作,开发进度安排,以及项目的成果是什么
计划驱动开发基于工程项目管理技术,可看做管理大型软件开发项目的传统方法
项目计划书应包括的部分
内容 | 描述 |
---|---|
引言 | 简要论述项目的目标,并列出影响项目管理的种种约束条件,如预算、时间的限制等 |
项目组织 | 阐述开发团队的组织方式、人员构成及其分工 |
风险分析 | 分析项目可能存在的风险,以及这些风险发生的可能性,并提出降低风险的策略 |
硬件和软件资源需求 | 介绍完成开发所需的硬件和支持软件。如果需要购买硬件,应注明估算的价格和交付的时间 |
工作分解 | 把项目分解成一系列的活动,指定项目里程碑和可交付的文档。里程碑是项目的关键阶段,借此可以评估过程,可交付文档是能够交付给客户的工作产品 |
项目进度安排 | 描述项目中各活动之间的依赖关系。到达每个里程碑预期所需的时间以及人员在活动中的分配 |
监控和报告机制 | 说明要提交哪些管理报告、什么时候提交,以及使用什么样的项目监控机制 |
- 项目辅助计划的例子
计划 | 描述 |
---|---|
质量计划 | 描述在项目中所要使用的质量过程和标准 |
有效性验证计划 | 描述系统有效性验证所采用的方法、资源和进度安排 |
配置管理计划 | 描述所要采用的配置管理过程和结果 |
维护计划 | 预测维护需求、成本以及工作量 |
员工发展计划 | 描述如何发展项目人员的技能和经验 |
23.3 项目进度安排
- 项目进度安排:决定如何组织工作,将其分割成单独的一个个任务,并且何时以何种方式完成各项任务
- 估算需要用于完成每个任务的时间、需要的成本以及完成这些既定任务的人员
- 估算完成每项任务所需的资源,比如服务器所需磁盘资源、需在专门硬件上占用的时间以及项目人员的差旅费预算
- 项目启动阶段创建一个初始项目进度安排,在后续的开发规划过程中修改完善
- 初始进度安排计划如何给项目分配人员,检查项目进展是否符合合同承诺
- 计划驱动开发:开始阶段创建完整的进度安排,随着项目进行而修改
- 敏捷过程:必须有一个总的进度安排,确定何时完成项目的各个主要阶段。再使用迭代的方法规划各个阶段
- 注意并行的任务:不同的员工研发不同的不见
- 进度安排表示方法
- 条形图:基于日历时间,表示每项活动的负责人,预计所用时间,以及该项活动预计的开始和结束时间。也叫甘特图
- 活动网络图:表示构成项目的不同活动之间的依赖关系
- 项目活动是基本的规划单元,包括
- 以天或者月计算的工期
- 工作量估计,反映完成工作所需的人日或人月数
- 活动完成的期限
- 定义好的终点,表示完成一项活动的明确结果。可以是一份文档,举行评审会,或是所有测试的成功完成等
23.4 敏捷规划
极限编程的规划过程
步骤 | 描述 |
---|---|
情节识别 | 用户情节反映了系统应包含的特征。项目启动时,开发团队和客户尝试定义一系列情景,使其可以覆盖最终系统的所有功能 |
初始估计 | 项目组阅读并讨论情景,按照实现这些情景所需时间将情形排序。此过程也会将大情景拆分成小情景 |
版本规划 | 包括选择和完善上述情景。这些情景反映出了在系统的发布版本中应实现的功能以及实现这些情景的顺序。然后选择发布日期,检查情景以判断工作量估计是否满足发布日期。不满足的话,增加或删除清单上的一些情景 |
迭代规划 | 迭代开发第一步。选择迭代过程要实现的情景,情景个数反映了交付一次迭代的时间和项目组的进度 |
任务规划 | 迭代开发第二步。是一个更详细的规划阶段,将情景拆分成各个开发任务。每项任务大概是 4-16 小时。列出本次迭代所有的任务,开发者申请自己要完成的任务 |
迭代完成 | 迭代交付日期到达时,即使未实现所有情景,也宣告完成迭代。迭代完成,考虑已实现的情景,增加工作量,重新规划下一个系统版本。即重复迭代规划和任务规划过程 |
- 注意
- 每个开发者根据自己的速度申请任务,申请的任务量不能多于其在规定时间内能完成的任务量
- 如果不能按时完成工作,减少工作量,而不是延长进度安排
- 上述分配任务方法的好处
- 整个项目组对迭代过程中要完成的任务有一个整体认识。因此他们能够理解项目组其他成员的工作内容已经确定任务依赖关系后应和谁交流
- 每个开发者选择要完成的任务,而不是由项目管理者分配任务。这样开发者对自己选择的任务有一种拥有感,可能激发他们更好地完成任务
23.5 估算技术
类型 | 描述 |
---|---|
基于经验的技术 | 使用管理者之前项目和应用领域的经验估算要求的未来工作量,即管理者主观给出所需要的工作量的一个估计 |
算法成本建模 | 使用一个公式方法计算项目的工作量,它基于对产品属性(如规模)和过程特点(如参与员工的经验)的估计 |