快速开发-风险管理
风险管理的5个层次：
危机管理：风险已经造成麻烦了才去处理它们
失败处理：察觉到风险并迅速做出反应，但只在风险发生之后
风险缓解：事先做好风险发生的补救措施，但不做风险预防措施
着力预防：将风险识别与风险防范作为软件项目的一部分加以规划和执行
消灭根源：识别和消除可能产生风险的根源
风险管理包含两大块内容：风险评估与风险控制，轻重风险评估包括：风险识别、风险分析、风险优先级；风险控制包括：风险管理计划、风险化解、风险监控。
风险识别：提出一个潜在破坏项目进度的风险列表
风险分析：评估每一个风险出现的可能性及其影响，判定风险的级别
风险暴露量 = 发生的概率 * 损失的大小
估计损失大小（值损失的时间）
评估损失概率
设置缓冲期
风险优先级：风险影响大小
“当消除风险已经无济于事、减少风险令人怀疑时，风险管理本身实质上已成为一种风险”
关注重要的20%
风险管理计划：制定一个应对每个重要风险的方案、确保每一个单独的风险管理计划之间以及与整体项目之间相一致。
风险化解：每个重要风险所对应计划的执行
不做冒险活动
风险转移：从系统的一部分转移到另一部分
获取风险信息
消除风险根源
接受风险
发布风险
控制风险
记住风险
风险监控：对风险解决的过程进行监控，并识别新的风险
Top10风险列表
中间检查
风险管理员
各类风险列表：
（1）需求风险
①需求已经成为项目基准，但需求还在继续变化；
②需求定义欠佳，而进一步的定义会扩展项目范畴；
③添加额外的需求；
④产品定义含混的部分比预期需要更多的时间；
⑤在做需求中客户参与不够；
⑥缺少有效的需求变化管理过程。
（2）计划编制风险
①计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；
②计划是优化的，是"最佳状态"，但计划不现实，只能算是"期望状态"；
③计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；
④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；
⑤完成目标日期提前，但没有相应地调整产品范围或可用资源；
⑥涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。
（3）组织和管理风险
①仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；
②低效的项目组结构降低生产率；
③管理层审查 决策的周期比预期的时间长；
④预算削减，打乱项目计划；
⑤管理层作出了打击项目组织积极性的决定；
⑥缺乏必要的规范，导致工作失误与重复工作；
⑦非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。
（4）人员风险
①作为先决条件的任务(如培训及其他项目)不能按时完成；
②开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；
③缺乏激励措施，士气低下，降低了生产能力；
④某些人员需要更多的时间适应还不熟悉的软件工具和环境；
⑤项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；
⑥由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；
⑦不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；
⑧没有找到项目急需的具有特定技能的人。
（5）开发环境风险
①设施未及时到位；
②设施虽到位，但不配套，如没有电话、网线、办公用品等；
③设施拥挤、杂乱或者破损；
④开发工具未及时到位；
⑤开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；
⑥新的开发工具的学习期比预期的长，内容繁多。
（6）客户风险
①客户对于最后交付的产品不满意，要求重新设计和重做；
②客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；
③客户对规划、原型和规格的审核 决策周期比预期的要长；
④客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；
⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；
⑥客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。
（7）产品风险
①矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；
②开发额外的不需要的功能(镀金)，延长了计划进度；
③严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；
④要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；
⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；
⑥开发一种全新的模块将比预期花费更长的时间；
⑦依赖正在开发中的技术将延长计划进度。
（8）设计和实现风险
①设计质量低下，导致重复设计；
②一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；
③代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；
④过高估计了增强型工具对计划进度的节省量；
⑤分别开发的模块无法有效集成，需要重新设计或制作。
（9）过程风险
①大量的纸面工作导致进程比预期的慢；
②前期的质量保证行为不真实，导致后期的重复工作；
③太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发；
④过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作；
⑤向管理层撰写进程报告占用开发人员的时间比预期的多；
⑥风险管理粗心，导致未能发现重大的项目风险。