3 软件项目管理(续) 20151124

1. 北京航空航天大学 计算机学院 School of Computer Science and Engineering,Beihang University 软件项目管理(续) --风险管理及过程改进 刘超 北京航空航天大学软件工程研究所 2015年11月 版权所有,未经许可不得以任何方式复制和传播 刘超:liuchao@buaa.edu.cn 电话: (10)82317496
2. 示例 • 邀请5位同学 • 项目 – 大学生们每天都会爱不释手的APP? • • • • • 5个重要角色? 各自的主要职责? 工作方式(模式)? 存在的问题和解决方法? 如何评判?
3. 问题 • 毕业后,加入你加入了某个软件开发团队。你有可能在1-3 年内便开始承担一个项目(或子项目)的管理责任吗? • 什么是敏捷方法? – 面对需求持续的变化,如何进行有效地管理? • 什么是DevOps? – 英文Development和Operations的组合 – 是一组过程、方法与系统的统称,用于促进开发(应用 程序/软件工程)、技术运营和质量保障(QA)部门之 间的沟通、协作与整合。它的出现是由于软件行业日益 清晰地认识到:为了按时交付软件产品和服务,开发和 运营工作必须紧密合作* * http://baike.sogou.com/v63577813.htm
4. • 重新定义公司 – 颠覆传统的MBA模式 – 建立独树一帜的管理哲学 – 未来组织最需要的不是管理或激励? • • 阿里巴巴集团执行副总裁兼总参谋长曾鸣作序 – 《赋能:创意时代的组织原则》 + 我把我们正在面临的时代大变更称为第四次革命,即“创意革 命”(creative revolution)。在创意革命的时代,创意者最主 要的驱动力是创造带来的成就感和社会价值,自激励是他们的 特征。 + 虽然未来的组织会演变成什么样,现在还很难看清楚,但未来 组织最重要的功能已经越来越清楚,那就是赋能,而不再是管 理或激励。
5. • 雅虎怎么了? – 高管会议主题一天三变 – 战略、产品、人心… • 原因? – – – – 能力、魅力 人才、团队 实力、机遇 管理、决策
6. • 我们的课程实践项目 – – – – – 目标? 分工与合作? 进度、成本(工作量)、质量? 效果评估? 改进?
7. 作业 • 作业1:(本周五交) – 软件项目管理,或者其中某项具体的管理工作 + 涉及到哪些基本要素和必要的特征? + 如何用UML模型来描述这些要素和特征? + 通过典型的软件项目管理方法(实例)来说明这些要素和 特征 • 作业2 – 软件项目管理实践总结 + 课程实践项目中如何进行项目管理,及其效果和经验教训
8. 参考书 • 软件工程 -- 实践者的研究方法,[美] Roger S. Pressman著 • 软件工程最佳实践项目经理指南,[美] Mark J. Christensen, Richard H. Thayer著 • 构建之法 -- 现代软件工程,邹欣著 • …
9. 管理软件项目 • • • • • • • 项目管理的概念 软件过程和项目度量 软件项目计划 风险分析和管理 项目进度安排及追踪 软件质量保证 软件项目管理
10. 项目管理的概念—管什么? • 管理的谱系(4Ps) – 人员; + 项目成功的首要因素是人 + 5类:高级管理者、项目(技术)管理者、开发人员、客户 、最终用户 + 团队 – 产品 + 在项目计划之前,首先要定义产品的目标和范围 + 工作产品、最终发布的产品 – 过程 + 定义一个软件过程框架,以便制定全面的计划 – 项目 + 有计划、可控制的项目
11. 项目管理 • W5HH原则 – – – – – – Why:为什么开发该系统? What & When:要做些什么?什么时候做? Who:各项任务(功能)由谁负责? Where: 相关机构在哪里? How: 各项技术工作如何进行?如何管理? How much: 需要哪些资源?需要多少?
12. 软件项目组的构成与管理—管人(沟通、协调)? • 软件组织特点 – 不同的组织有着不同的组织结构,没有统一的规范 • 组织结构 – 直接把任务分配给每个人,彼此之间基本上没有合作,由管理者协调 – 形成非正式小组,有小组负责人,由管理者协调 – 组成若干个小组,有明确的任务分工,小组有明确的结构,协调有小 组负责人和管理者共同控制 • 管理模式 – 民主分散式:没有固定的负责人,协调是短期的,重要问题有小组讨 论决定 – 控制分散式:有固定的负责人,负责协调,包括树形的组织结构 – 控制集中式:顶层问题的解决和小组内部的协调由小组负责人承担
13. 沟通与协调 • 正式的、与人无关的方法 – 软件工程文档和交付物、备忘录、里程碑、进度和项 目控制工具、改变请求、错误跟踪报告 • 正式的、人员间的规程 – 质量保证活动:状态评审会、设计和代码审查 • 非正式的、人员间的规程 – 解决特定问题:需求采集、人员组织、信息沟通 • 电子通信 – 电子邮件、电子公告栏、Web网站、视频会议 • 人员间的网络 – 与项目组之外的人员进行非正式的交流
14. 管理理念 • Jerry Weinberg[1986] – 领导能力的MOI模型:Motivation(激励)、 Organization(组织)、Idea or Innovation(思想或创 新) • 具有实战能力的项目经理的4种关键品质 – – – – 解决问题:诊断问题,解决方案,激励团队,积累改进 管理者特征:掌控全局,发挥团队和骨干优势 成就:奖励积极主动并作出成绩者,能够控制风险 影响与团队建设:善于理解人,并适时作出适当的反应 ,保持良好的控制力
15. 软件团队 • 好的团队取决于组织的管理风格、人数及其技能水平,以 及问题的难度 • Mantei提出了建立一个团队结构时应考虑的7个因素[1981] – – – – – – – 待解决问题的特点和难度 开发程序的规模(代码行或功能点) 成员需要共同工作的时间(团队生存期) 能够对问题做模块化分解的难度 待开发系统的质量要求 交付日期的严格程度 项目所需要的友好交流程度
16. • Constantine提出了软件工程团队的4种“组织范型”[1993] – 封闭式:传统的层次化责权划分,有效但难以“创新” – 随机式:松散,依赖于个人能力和主动性,摆脱束缚有 利于创新 + 主程序员团队结构,独立创新团队 – 开放式:封闭 + 随机,良好的协同和沟通,依据整体意 见作出决策 – 同步式:依赖于问题的自然分解进行分工,无需频繁交 流
17. • Jachman定义了5个导致“含毒团队”的因素[1998] – – – – – † 狂乱的工作氛围 引起团队成员间产生摩擦的重大挫折 碎片式的或协调很差的软件过程 没有清晰的角色定义 接连不断第重蹈覆辙 个性差异且难以协调 • 项目经理的职责 – 目标:建立并保持团队的凝聚力 – 核心:统一的对成功的定义鲜明的团队精神
18. 管理模式与挑战 • 严谨管理 – 系统:大型、复杂、安全关键、长周期 – 监控: + 标准符合性:CMM&CMMI, DO178B/C, IEC61508, etc + 质量评估:可靠性、安全性 + 维护:变更与演化 可追踪 – 灵活:适应性 • 敏捷团队 – – – – – 尽早地逐步交付,以使用户满意 组织小型充满活力的项目团队 采用非正式的方式 交付最小的工作产品 总体开发简易
19. 软件项目计划—管过程(计划、监控)? • 软件工作域:任务与要求 – 系统:规模和难度 + 数据、功能、性能、接口(软硬件、人)、约束 – 质量:可靠性指标等 • 资源: – – – – – 人力:能力、协作、实际投入 可复用构件 环境:软硬件(开发工具)、场地 开发:过程、规程、活动 其他:消耗性材料 • 成本 – 专家估算法 – 类推估算法 – 算式估算法 • 进度:时间
20. 进度计划与监控 • 进度表(Gantt Chart) 周 任务 需求分析 任务1 任务2 概要设计 详细设计 编码 测试 1 2 3 4 5 6 7 8 9 10 11 12
21. • MS Project
22. 进度计划与监控 任务网络图 A编码 1 2 8 A测试 B测试 5 AB组装测试 A设计 ABC系统测试 6 6 6 8 B编码 8 0 3 7 7 5 9 7 8 8 C测试 6 AC组装测试 C理解 C修改 4
23. 项目计划的基础是什么? • 经验 – 实践 • 规范的软件过程 – 标准、规范 – 实践 • 量化数据 – 历史数据的积累:规范的软件活动的文字记录 – 数据的分析和筛选 • 度量 – 过程、项目、产品的度量
24. 产品范围和产品演化—管产品(范围定义和 版本控制)? • 产品范围定义 – 哪些产品?要解决哪些问题? – 项目环境 – 信息目标 – 功能和性能 • 问题分解 • 配置管理 可追踪性 – 版本控制 – 变更控制
25. 项目风险管理 • John Reel在1999年定义了10个表示信息系统项目处于危险 状态的信号 – – – – – – – – – 软件人员不了解其客户的要求 产品范围定已的很糟糕 没有很好地管理变更 选择的技术发生了变化 业务需求发生了变化(或者没有明确的定义) 最后期限不切实际 投资不足 项目团队缺乏具有合格技能的人员 管理者(或实践者)没有很好地利用已有的最佳实践和 接受教训
26. • 90:90规则: – 项目的前90%工作会花费计划工作量和时间的90% – 但是,其最后的10%工作也会花费原计划的90% – 结果是 + 超过50%的项目的进度和经费超出计划89% [DOD,2000]
27. • 项目管理的支持工具 – Project Control Panel:www.spmn.com – 实用的项目管理检查表:www.ganthead.com – 计划指南、过程模板、工作表:www.Ittoolkit.com
28. 风险管理 • 什么是软件项目的风险? • 风险分析 – 风险因素及其识别 – 风险预测与评估 • 风险缓解、监测和管理(控制)
29. 风险 • 定义[Robert Charette,1989] – 涉及未来将要发生的事情 + 昨天的事情已经不可改变 + 问题是:我们是否能够通过改变今天的行为,而为一个不同 的、充满希望的、更美好的明天创造机会。 – 涉及改变 + 如思想、观念、行为、地点的改变…… – 涉及选择 + 而选择本身就具有不确定性。 • 风险是生活中最不确定的因素之一
30. 软件项目风险 • 软件风险 – 不确定性:可能发生,也可能不发生 – 损失:如果发生,则会产生恶性后果或损失 • 软件项目风险 – 威胁到项目计划:拖延进度、增加成本、降低质量 – 因素影响:预算、进度、人员、资源、利益相关者、 需求等 • 技术风险:威胁质量和交付时间 – 影响因素:设计、实现、接口、验证、维护等 • 商业风险:软件生存能力 – 影响因素:市场、策略、销售、预算
31. 风险分析和管理 • 风险分析和管理是一系列帮助软件小组理解和管理不确定 性的步骤 – 被动的:救火模式 – 主动的:标识潜在风险、评估出现概率和影响,制定 计划并对风险进行管理和控制
32. 风险管理的七原则 • CMU SEI定义的“实施有效风险管理框架” – – – – – – – 保持全面观点:从软件所处的系统整体考虑 采用长远观点:未来可能出现的问题(变更) 鼓励广泛交流:重视不同方面的意见 结合:与软件过程结合,考虑过程影响 强调持续的过程:全过程 开发共享的产品:所有利益相关者共享相同版本产品 鼓励协同工作:汇聚所有利益相关者的智慧、技能和知 识
33. 风险的识别 • 尽力系统化地指出对项目计划(估算、进度、资源分配等) 的威胁 – 一般风险 – 特定风险 + 只有对当前项目特定的技术、人员、环境等非常了解的人才 能识别 • 方法 – 建立风险条目检查表 + 产品规模、商业影响、客户特征、过程定义、开发环境、开 发技术、人员才干和经验 – 评估整体项目风险 – 风险因素和驱动因子分析 + 性能、成本、支持(维护)、进度等
34. 影响评估 性能 灾难性的 支持 进度 无法满足需求而导致任务失败 失误导致进度延迟和成本增加 严重退化,无 无法支持 法满足要求 严重的 成本 资金严重短缺,无法按时交付 超预算 无法满足需求而导致性能下降 失误导致进度延迟和成本增加 技术性能有些 软件修改中有 资金不足,可 可能延期 降低 延迟 能超支 轻微的 无法满足需求而导致次要任务 可能略有延期或超支 降级 技术性能有些 对技术支持有 资金足够 降低 一定影响 可忽略的 进度可调 无法满足需求而导致使用不方 延期或超支略有影响 便或不易操作 技术性能没有 可通过技术支 资金足够 降低 持解决 进度可调
35. 风险预测/评估 • 主要活动 – 风险发生的可能性 – 风险相关问题产生的后果 – 估算风险对项目及产品的影响 – 标明风险预测的整体精准度 • 建立风险表 风险项 风险类型 发生概率 影响值 * RMMM:风险缓解、监测和管理计划 RMMM
36. 风险缓解、监测和管理(控制) • 风险回避 • 风险监测 • 风险管理及应急计划 • RMMM(Risk Mitigation, Monitoring and Management)
37. 基于风险评估的风险监控 • • • • 预风险因素列表 风险权重 风险因素产生条件 风险影响评估 • 风险的缓解、监控和管理 – 决策 – 措施和预案 – 追踪、监控、评估和调整 • 总结 文档 + 手段
38. 讨论 • 课程实践项目风险? • 评估和监控方法? – 基于以前的课程大作业经验/经历 – 调研 – 给出具体的方法:风险条目检查表、评估表?

相关幻灯片