软件项目管理
一. 软件项目管理的案例
- 软件项目管理的挑战
- 在预定的范围、质量、时间和成本等约束条件下交付项目
- 通过优化资源（资金、人、原料、能源、空间等）的分配与集成来满足预先定义的目标
- 软件项目的特征
- 软件产品的不可见性
软件项目复杂和抽象 - 项目高度不确定性
预定计划和实际情况存在较大偏差 - 软件过程的多变化性
不确定、不稳定 - 软件人员的高技能及其高流动性
风险
- 软件产品的不可见性
软件项目管理的“4P”
二. 人员 People
- 软件项目的参与人员
- 高级管理者：负责定义业务问题（产品经理）
- 项目（技术）管理者：计划、激励、组织和控制软件开发人员（项目经理）
- 开发人员：拥有开发软件所需技能的人员
- 系统分析员、系统架构师、设计师、程序员、测试人员、质量保证人员、…
- 客户：甲方
- 最终用户：直接使用软件的人
- 软件开发团队的组织模式
- 一窝蜂模式：没有明确分工
- 主治医师模式：首席程序员处理主要模块的设计和编码，其他成员从各种角度支持Ta的工作
明星模式 - 社区模式：志愿者参与，参与自己感兴趣的项目；众人拾柴火焰高，不拾柴火熄灭；社区不意味着随意，代码复审和签入的质量管理
开源项目 - 交响乐团模式：门类齐全，各司其职；演奏协调，遵循曲谱
类似工厂，严格遵循预定生产流程 - 爵士乐模式：主乐手吹主题，其余人员即兴发挥，主乐手最后再加入，回应主题
类似于一群天才构成的敏捷团队 - 功能团队模式：不同能力，平等协作（没有管理与被管理的关系），项目完成重新组织
- 官僚模式：除了技术上的合作和领导，还混进了组织上的领导和被领导关系
大型项目的技术管理组织结构
三. 产品 Product
- 首先确定软件范围
- 功能和非功能（性能、可用性、安全、法律等）
- 软件范围应确定：包括管理层和技术层都必须无歧义
- 确定范围后，对其进行分解——分而治之
- 产品结构分解（Product Breakdown Structure, PBS）产品分解工具
- PBS：通过分层的树型结构来定义和组织项目范围内的所有产出物(产品)，自顶向下，逐级细分
- 产出物：项目结束时需要提交的最终产品，在项目之初就可以准确预计
四. 过程 Process
- Step1：选择合适的软件过程模型
- Step2：根据选择的过程模型，对其进行适应性修改
- Step3：确定过程中应包含的工作任务列表
工作结构分解（Work Breakdown Structure, WBS），过程分解工具
五. 项目 Project
- 项目关注的四个方面：范围、时间、成本、质量
- 项目管理的主要任务：项目可行性分析与估算、项目进度安排、项目风险管理、项目质量管理、项目跟踪与控制
原则：Why（为什么开发这个系统）、What（将要做什么）、When（什么时候做）、Who（某功能谁来做）、Where（他们的组织机构位于何处）、How（如何完成技术和管理工作）、How much（各种资源分别需要多少）
六. 可行性分析与估算
可行性分析与估算
- 项目开始之前，预先估计三件事：需要多少工作量、需要多少时间、需要多少人员
- 此外，预测所需要的资源（硬件和软件）以及蕴含的风险
- 由上述得出项目是否可行的结论
确定范围
- 范围：描述将要交付给最终用户的功能和特性、输入输出数据、用户界面、系统性能、约束条件、接口和可靠性等，以及期望的时间、成本目标（主要是业务范围，时间和成本只需要简述且从业务范围得出）
- 两种方法：项目成员交流之后，写出软件范围的叙述性描述（开发人员给出）；由最终用户给出一组用例
- 注意：并不是客户所有的需求都来者不拒，需要分别对待；用户签字确认
可行性分析：技术、经济、时间、资源
软件项目估算（时间、成本、资源）
变化多
估算越精确
估算方法：代码行、功能点、过程时间、其他（不同方法
COCOMO (COnstructive COst MOdel, 软件构造性成本模型)：回归分析，从项目历史和现状某些特性作参数进行计算，用于工作量估算与成本估算，广泛使用和全面估算。
七. 项目进度计划与监控
项目管理里通常采用甘特图(Gantt Chart)来描述任务的进度安排
- 将资源分配给任务：资金、人员、设备、环境
- 明确产出结果：每一项产出结果是什么，对应PBS哪一部分
- 明确里程碑：项目关键产出物，标志某一阶段完成
项目进度表只是提供了一张进度路线图，在实际执行过程中，需要定期对其进行跟踪和控制，以决定是否需要对进度计划进行调整
敏捷开发的项目管理工具：VersionOne，敏捷领域最流行的商业化项目管理工具之一