软件项目风险管理——《与熊共舞》读书笔记(六) ——改进的风险管理处方

在软件开发过程中，经常忽略的一个因素——风险。风险是一把双刃剑，因为风险的另一面就是价值，我们不能因为它的负面影响避而不谈。这书就围绕着风险这个东西展开阐述。此书作者是一个实践家而不是思想家。在文中他指出了为什么风险管理会给忽略，跟着谈了如何做合理的风险管理。我认为，在现实的环境中，影响风险最关键的还是人，因此作者在序编里面就引用了英国以为思想家William K. Clifford的论文《信仰的

 我们真的进行风险管理了吗？ 1.1、有一个风险清单； 2.2、有一个持续的风险发现机制； 3.3、不确定性图随处可见； 4.4、项目既有目标值又有估算值，两者从不相同； 5.5、每个风险都有明确的转化指标； 6.6、有一个不间断监控风险转化指标的机制； 7.7、每项风险都有应急计划和缓解计划； 8.8、每项风险的暴露值都得到了计算； 9.11、

摘抄自：与熊共舞-软件项目风险管理（Tom DeMarco、Timothy Lister著，熊节、马姗姗 译） 通过风险发现过程调查出项目面临的风险。确认软件项目所有的核心风险都已经出现在你的调查结果中。针对每项风险，完成下列”家庭作业“： 为风险命名，并提供一个唯一的编号。通过头脑风暴找出这项风险的转化指标----风险具现的所有征兆中最早出现的那个。估算风险一旦发生可能对成本和进

对待风险管理的正确态度：     勇于承担风险而不是逃避，不做没有风险的项目! 几个关键概念：1、风险：未来可能发生的导致项目不好的结果的事件；不好的结果本身。2、风险和问题的区别：风险是尚未发生的问题；问题是业已成真的风险。3、风险转化：风险的具现。4、转化指标：判断风险已经转化或正在转化的依据5、风险缓解：必须在风险转化之前采取的措施。风险管理的行为构成：1、风险发现：头脑风暴，筛选，保持持续

量化不确定       顾问的一段话：听着，这个项目根本不可能在明年1月前完成，它的可能性为零，最有可能的时间是明年4月，但也不能打保票，你最高不要承诺在明年5月1日前的任何时间交付，你最好承诺在五月以后某个时间交付，这样你成功的概率在50%以上。最保守的是承诺明年12月前交付，那是一个不可能失败的日期!       软件产业的整体经验：不确定性的范围与N点前的时间之比介于1.5到2.0之间最

      在众多企业中没有做风险管理,本书给出了一般的不进行风险管理的借口：         1.客户或上级还没有成熟到坦然接受风险的地步；（实际不然，客户可能已经很成熟，另外，也取决于我们的沟通技巧）          2.不确定性的范围太大，让人无法接受；（面对现实，行业的经验告诉我们会很大）         3.不确定性的范围让低效成为借口；(目标和估算的区别：估算是考虑了各种不确定性的一

系统整体实施流程概述 一、实施概述 软件实施人员工作内容是合理调配公司、现场资源，制定推进计划并保证实施，争取节约成本并在合同签订的时间范围内完成项目的验收。具体工作包括：常用操作系统、应用软件及公司所开发的软件安装、调试、维护，现场软件应用培训，协助项目验收，需求的初步确认以及项目后期维护。   二、系统流程图 三、系统实施过程 3.1项目启动 项目启动包括内部启动

昨天不知道为什么，贼拉想买书，可能是周期到了呵呵 。   最近在卓越上买了几回书，感觉很方便，本打算以后都在卓越上买了，可昨天，特别想搞点什么东西来读，不能等的感觉，于是乎中午杀到了书店。   那个书店叫学龄书店，以前在星海哪里住的时候总去光顾，后来搬到现在的新家之后，就去得少了。一进入书店，再熟悉不过了，我曾经还跟老板打趣说：“你雇我来卖书吧，你们家哪本书在哪我都能找到。” 老板说:"你先问问我...

       我个人觉得，我们对一个项目价值的认识比对风险的认识更为糟糕。其实对风险的量化本身就很难，对价值的量化就更难了。似乎量化价值只是客户的事情，正如书中所说的，我们一般忽视对价值的量化的理由是：       系统的规模太小，不知道这么做； 我们没有选择，我们只是必须完成它；上面的主管要这个系统；能有多少收益这取决于市场，特别是市场届时的发展情况有关；这个系统只是要替代现有的系统；命令是上面

1.WHY名词：风险：（1）未来可能发生的某一件事，该事件将导致不好的结果（2）不好的结果本身风险是尚未发生的问题，问题是业已成真的风险。区分风险管理（管理风险）和危机管理（问题的补救措施）风险转化：风险发生（具现）了转化事件，通常不可见，可见的为转化指标，通过指标看转化事件。风险缓解：“必须在风险转化前做的工作”风险管理包括：风险发现，暴露分析，应急计划，风险缓解，持续转化控制。  风险管理的理...

     我们的软件产品或者项目，其需求都有三个层级和三个方面。     一、我们首先看需求的三个层次          软件需求包括3个不同的层次――业务需求、用户需求和功能需求。　　业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开

一、什么是SOA：        面向服务的体系结构（Service-Oriented Architecture，SOA）是一种 IT 体系结构风格，支持将您的业务转换为一组相互链接的服务或可重复业务任务，可在需要时通过网络访问这些服务和任务。当在战略业务目标的引导下进行 SOA 实现工作时，可确保对业务进行积极转换，并能够实现 SOA 的好处：IT 与业务的一致性和IT 资产的最大化重用。

一、什么是业务驱动开发        业务驱动的开发(Business-driven development，BDD)是一种由业务需求驱动的端到端软件开发方法。其主要的手段是通过主要流程步骤对业务流程进行建模，建立业务部门通过投资回报 (ROI)、主要性能指标 (KPI) 或其他度量标准来对业务流程或主要用例进行评估过的BPM(业务流程模型)——业务部门和IT部门沟通业务需求的桥梁的主要机制。

 需求的漫画：       关于需求问题，有一幅漫画十分生动地展现了这些问题（这幅漫画我其实最早是在07年一次“敏捷中国”一次软件开发技术人员日上上见到的），如果我们认真剖析后面的东西，还是会给我们的工作带来许多启发的：      究其原因，这幅漫画给人最大的启示就是在需求沟通过程中产生了严重的失真，从客户的描述到项目经理的理解、分析员分析并文档化、程序员的编码、商业顾问的诠释，每个角

计算环境由计算机、相关的软件平台和以及连通这些计算机和相关软件平台网络组成。不同的计算环境有不同的计算风格和编程模型，由一些特定于该计算环境的技术来支撑。      在面向服务的计算环境（其实更准确的说，是面向服务架构的计算环境）中，系统可以是高度分布、异构的。它一般包括服务运行时环境（Service Runtime）、服务总线（Service Integration Infrastructure