快速软件开发 学习笔记 之三
第4章 风险管理
软件经理必须悉心学习风险管理，才能在项目中避免项目失控。正如Tom Gilb所说：“如果你不主动击败风险，它们就会主动击败你。”一个成功的软件项目，应该着眼于事前识别和防范风险及事中监控风险，而不是对项目风险坐视不理直至风险变成现实。
下表列出了最常见的进度风险及其化解方法。
表 4-1 最常见的进度风险
| 进度风险 | 化解方法 |
| Feature creep（功能蔓延） | 控制项目的需求变更，详见第13.2节。 |
| Requirements or developer gold-plating（需求镀金或开发人员镀金） | 在项目前期剔除客户不需要的需求，详见第13.1节。 |
| Shortchanged quality assurance（走样的质量保证） | 任何时候都不放松对软件质量的要求，详见第3.6节。 |
| Overly optimistic schedules（过于乐观的进度计划） | 建立合理的进度计划，详见第7章和第8章。 |
| Inadequate design（低劣的软件设计） | 进行高质量的软件设计。 |
| Silver-bullet syndrome（银弹综合症） | 破除银弹综合症，详见第14.2节。 |
| Research-oriented development（研究导向的开发） | 不在软件工程项目中进行软件研究。 |
| Weak personnel（人员不能胜任） | 选择可胜任的人员，详见第11章。 |
| Contractor failure（外包承包方违约） | 有效管理外包项目的风险，详见第16章。 |
| Friction between developers and customers（开发人员与客户之间产生摩擦） | 维护良好的客户关系，详见第9章。 |
表4-2列出了详尽的可能对软件进度产生负面影响的潜在风险。软件经理可以把该表作为基础，对照自己的项目看看存在哪些风险，并思考如何加以化解。
表 4-2 进度风险列表
| 进度计划编制 Schedule、resource和product definition全都由客户或高管说了算，而且这三方面因素并没有很好地被权衡和折中 进度计划是“乐观的”、“只存在于最好情况下”的（而非“现实的”、“存在于预期情况下”的） 进度计划遗漏了必要的任务 进度计划基于使用特定的团队成员，而那些团队成员却并没有到位 无法在限定的时间内创建该规模的产品 产品规模（按代码行数或按功能点数衡量）大于估算规模 项目拖延之后所做的重新估算过于乐观或无视项目既有历史 过度的进度压力造成生产率下降 交付日期提前，而product scope或available resource未做相应调整 单项任务的拖延导致相关任务一并拖延 设计和实现产品中的不熟悉领域的所用时间高于预期 |
| 组织和管理 项目缺乏有效的高层支持 项目前期用时过久而使项目疲沓 裁员和缩减开支削弱团队实力 管理层或市场人员坚持要求执行会延长进度的技术决策 低效的团队结构造成生产率下降 管理层的review/decision cycle长于预期 预期缩水扰乱项目规划 管理层做出挫伤开发团队积极性的决策 非技术性的第三方任务（预算批准，仪器购置批准，法律审议，安保，等等）的所用时间高于预期 项目规划过于糟糕而无法支撑起期望的开发速度 在压力下放弃项目规划，导致混乱的、低效的开发 管理层看重英雄主义而非客观准确的项目状态汇报，这损害了管理层发现并纠正问题的能力 |
| 开发环境 办公场所不能及时到位 办公场所到位但办公装备并没到位（例如，没有电话、网络连接、办公家具、文具等） 办公场所拥挤、嘈杂或者使人无心工作 开发工具不能及时准备就绪 开发工具未按预期发挥作用；开发人员需要时间想出变通方法或者更换新工具 开发工具的选择不是基于技术判断，因而未能提供预期的生产率 新工具的学习曲线长于或陡于预期 |
| 最终用户 最终用户坚持引入新的需求 最终用户对于最后交付的产品不满意，要求重新设计和返工 最终用户没有全身心投入项目，因此不能给项目提供所需支持 由于没有征求最终用户的意见，最终产品不能满足用户预期而必须返工 |
| 客户 客户坚持引入新的需求 客户对规划、原型和规格书的review/decision cycle长于预期 客户不参与或不能参与对规划、原型和规格书的review cycle，导致不稳定的需求和费时的变更 客户沟通时间（例如，澄清需求的时间）慢于预期 客户坚持要求执行会延长进度的技术决策 客户过细管理（macro-manage）开发过程，导致项目进展慢于预期 客户提供的组件无法与开发的产品匹配，导致额外的软件设计和集成工作 客户提供的组件质量低劣，导致额外的测试、设计、集成和客户关系管理工作 客户指定的支持工具和环境不兼容、性能差、或者功能不完备，导致生产率降低 客户不接受交付的软件，即使该软件满足了所有的规格说明 客户对开发速度抱有高期望，而开发人员无法达到该期望 |
| 承包方 承包方未按承诺的日期交付组件 承包方交付的组件质量低劣得不能接受，必须增加时间改进质量 承包方没有全身心投入项目，因而未能达到应有的表现 |
| 需求 需求已经成为项目基准，但变更还在继续发生 需求定义欠佳，而进一步的定义扩大了项目的scope 加入更多的需求 花在产品中含混部分的时间高于预期 |
| 产品 易错模块需要的测试、设计和实现工作多于预期 纠正低劣得不可接受的产品质量需要的测试、设计和实现工作高于预期 要在计算机科学的一个或多个领域取得尖端突破，导致进度变长且不可控 由于开发错误的软件功能而导致重新设计和重新实现 由于开发错误的UI而导致重新设计和重新实现 由于开发多余的、并不需要的功能而延长了进度 要满足产品的规模约束或速度约束，需要比预期更多的时间 兼容现有系统的严格需求，需要进行比预期更多的测试、软件设计和实现 要求与其它系统或不受本项目组控制的系统相连，导致无法预计的设计、实现和测试工作 要求在不同操作系统下运行，需要比预期更多的时间 要求在一个不熟悉或未经检验的软件环境下运行，导致不可预见的问题 要求在一个不熟悉或未经检验的硬件环境下运行，导致不可预见的问题 开发一种对组织来说全新的组件，导致花费的时间多于预期 依赖于某种尚处于开发阶段的技术，导致进度延长 |
| 外部环境 产品依赖于政府规章，而政府规章的改变是不可预期的 产品依赖于技术标准草案，而技术标准草案的改变是不可预期的 |
| 人员 招聘人员所花时间多于预期 作为先决条件的任务（例如，培训，其它项目的完成，取得工作许可证）无法及时完成 开发人员与管理人员之间关系不佳导致决策缓慢，并且这种情况一直没有好转 团队成员没有全身心投入项目，因而未能达到应有的表现 缺乏激励，士气低落，导致生产率降低 缺乏必要的专业化，导致缺陷增加和返工 人员需要额外的时间来学习不熟悉的软件工具或环境 人员需要额外的时间来学习不熟悉的编程语言 人员需要额外的时间来学习不熟悉的硬件环境 合同制人员在项目完成之前离职 雇员在项目完成之前离职 新的开发人员在项目晚期加入，额外的培训和沟通开销降低了现在成员的效率 团队成员无法有效地共同工作 团队成员间的冲突导致沟通不畅、设计欠佳、接口错误和额外的返工 问题成员未被消除出队，破坏团队积极性 最胜任项目工作的人员未能加入项目 最胜任项目工作的人员有望加入项目但却出于政治或其它原因而未能实现 无法找到具备项目所需关键技能的人员 关键人物只能兼职参与 项目人手不够 任务分配与人员技能不匹配 人员工作的进展慢于预期 项目管理人员怠工，导致低效的调度和规划 技术人员怠工，导致工作遗漏或质量低下，需要返工 |
| 软件设计与实现 过于简单的设计无法应对重大问题，导致重新设计和重新实现 过于复杂的设计，导致不必要的和低效的实现 设计欠佳导致重新设计和重新实现 使用不熟悉的设计方法论，导致额外的培训和初次误用方法论引发的返工 产品用低级语言（例如，汇编语言）实现，生产率低于预期 必需的功能无法用选择的代码库或类库实现，开发人员必须更换新的库或自行开发所需功能 代码库或类库质量低下，导致额外的测试，缺陷纠正和返工 过高估计了生产率工具对进度的节省量 单独开发的组件不能很好地集成，需要重新设计和返工 |
| 过程 大量的文书工作导致进度慢于预期 不准确的进度跟踪导致直到项目晚期才发觉项目落后于进度计划 上游质量保证任务走样，导致下游做费时的返工 不准确的进度跟踪导致直到项目晚期才发觉存在影响进度的质量问题 太不正规（完全不遵循软件开发的策略和标准作法），导致沟通不足、质量问题和返工 太过正规（教条地坚持软件开发的策略和标准作法），导致过多耗时无用的工作 向管理层撰写进展汇报对开发人员时间的占用多于预期 风险管理粗心大意，导致没有发现重大的项目风险 软件项目风险管理花费的时间多于预期 |
软件项目是一个动态过程，因此需要从头至尾对项目风险进行监控。“前10大风险榜单”是最有效的风险监控工具之一。
| 最佳实践：Top-10 Risks List（前10大风险榜单） 1. 从项目最早的规划阶段起就建立“前10大风险榜单”。该榜单包含项目当前最大的10个风险，严重程度由高到低排列，并对每个风险制定对应的化解措施。下图是一个示意图。
2. 每周，软件经理都应该和开发人员一道review“前10大风险榜单”，总结当前风险的化解情况，并讨论是否出现了新的风险。 3. 每个major milestone完成时，对“前10大风险榜单”进行一次review，讨论已有风险的化解情况和在一个阶段会遭遇的主要风险。 |
