《快速软件开发》笔记一，有效开发
序
调查表明，大约70%的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20%到50%，90%以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高
第一章 欢迎学习快速软件开发
快速开发的成功取决于两个要素：
1，选择有效的实践而不是无效实践
2，选择有利于完成项目锁定目标的实践
面向进度的实践有三类：
1，面向速度的实践：可以提高开发速度，帮助你更快交付软件
2，面向进度风险的实践：可以降低计划风险，帮助你避免更大计划风险
3，面向可视化的实践：可以提高进程可视化程度，帮助你驱散慢速开发的阴云
第二章 快速开发策略
快速开发的4个支柱：
1，避免典型错误（如产品质量低下）
2，打好开发基础（如系统设计）
3，风险管理（如关键承包商的开发进度落后）
4，面向进度的实践
快速开发的四维：人员、过程、产品、技术
1，人员
从某种程度上讲，我们已经认识到人力因素比其他因素对软件性能与软件质量影响更大
反复的研究发现，经验相当的程序员之间效率的差别也是很大的，甚至达到10:1
技术并不是问题的答案，最有效的实践是那些能够发挥工作人员潜能的实践
人力因素极大地影响着生产效率，同时任何关注提高生产效率的组织首先必须有一套良好的人员激励、团队合作、员工选择及培训的机制
几种发挥人员最大潜能缩短项目周期的方法：
1）项目组成员的选择
绝顶的天才
工作匹配
职业的晋升
团队平衡
排除不称职的人员
2）项目组结构
软件企业会从项目团队与项目规模、产品特点以及进度目标的匹配中受益
3）人员激励
一个缺乏动力的人很难努力工作并达成目标
人员激励是使你能够达成快速开发的最具潜力的方法
2，过程
1）避免重复工作
2）质量保证
3）开发基础
4） 风险管理
5）资源目标
6）生命期计划
7）面向客户的开发
3，产品
1）产品规模
2）产品特性
4，技术
选择有效的工具并管理好由此所带来的风险也是争取快速开发主动权的关键之一
5，协同
研究发现，对职员薪金、培训及工作环境的花费由较低水平增长为中等水平时，生产率可以产生比例相当的增长：额外的花费基本可以获得1：1的回报，但当以上花费从中等水平增长到较高水平时，生产率的回报将迅速上升到2：1或3：1
组织范围内的编码标准有助于各个项目的开展，它可以便于一个项目使用另一个项目的部件，同时，重复使用的部件也有利于编码标准的使用，并确保部件在各个项目中具有相同的含义
设计和代码审核有助于编码标准和现有可重复使用部件知识的传播，可以促进成功使用重复部件的质量等级
好的实践应该彼此相互支撑
第三章 典型错误
人员篇：
1，挫伤积极性
2，人员素质低
3，对有问题的员工失控
4，英雄主义
5，项目后期加入人员
6，办公环境拥挤嘈杂
7，开发人员与客户之间发生摩擦
8，不现实的预期
9，缺乏有效的项目支持
10，缺乏各种角色的齐心协力
11，缺乏用户介入
12，政治高于物质
13，充满想象
过程篇：
1，过于乐观的计划
2，缺乏足够的风险管理
3，承包人导致的失败
4，缺乏计划
5，在压力下放弃计划
6，在模糊的项目前期浪费时间
7，前期活动不合要求
8，设计低劣
9，缺乏质量保证措施
10，缺少管理控制
11，太早或过于频繁的集成
12，项目估算时遗漏必要的任务
13，追赶计划
14，鲁莽编码
产品篇：
1，需求的镀金
2，功能蔓延
3，开发人员的镀金
4，又推又拉的交易
5，研究导向的开发
技术篇：
1，银弹综合症
2，过高估计了新技术或方法带来的节省量
3，项目中间切换工具
4，缺乏自动的源代码控制手段
建立你自己的最差实践列表，可以避免在以后的项目中犯同样的错误
第四章 软件开发的基本原则
管理原则：
1，项目估算和进度安排
2，计划编制
3，跟踪
4，度量
技术原则：
1，需求管理
2，设计
3，构建
4，软件配置管理SCM
质量保障原则：
1，易错模块
2，测试
3，技术回顾（走查、代码阅读、检查、技术回顾）
多数有进度问题的软件项目的规模都类似于房屋或更大，对于这种项目，遵循开发的基本原则是可以达到节约时间的目的的
如果你抛开这些指导，那就是在冒风险了
第五章 风险管理
总体上讲，风险管理由风险评估（风险识别、风险分析、风险优先级）和风险控制（风险管理计划、风险化解、风险监控）组成
进度计划风险的完整列表：
计划编制风险：
1，计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致
2，计划是优化的，是“最佳状态”（但不现实，只能算是“期望状态”）
3，计划忽略了必要的任务
4，计划基于使用特定的小组成员，而那个小组成员其实指望不上
5，在限定的时间内无法建成已定规模大小的产品
6，产品规模比估计的要大
7，工作量大于估算数
8，进度已经延迟的项目在重新评估时过于优化或忽视项目历史
9，过度的进度压力造成生产率下降
10，目标日期提前，但没有相应地调整产品范围或可用资源
11，一个任务的延迟导致相关任务的连锁反应
12，涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多
组织和管理：
1，项目缺乏一个有凝聚力的高层领导人
2，由于前期乏力，项目长时间被搁置
3，解雇和消减开支导致项目小组能力下降
4，仅由管理层或市场人员进行技术决策，导致计划进度延长
5，低效的项目组结构降低生产率
6，管理层审查/决策的周期比预期时间长
7，预算消减打乱项目计划
8，管理层做出了打击项目组积极性的决定
9，非技术的第三方的工作比预期长
10，计划性太差，无法适应预期的开发速度
11，项目计划由于压力而放弃，导致开发混乱、低效
12，管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力
开发环境：
1，设施没有及时到位
2，设施到位，但不配套
3，设施拥挤、杂乱或者破损
4，开发工具未能及时到位
5，开发工具不如期望地那样有效，开发人员需要时间创建工作环境或者切换新的工具
6，开发工具的选择不是基于技术需求，不能提供计划要求的性能
7，新开发工具的学习期比预期的长，内容繁多
最终用户
1，最终用户坚持新的需求
2，最终用户对于最后交付的产品不满意，要求重新设计和重做
3，最终用户不买进项目产品，无法提供后续支持
4，最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做
客户
1，客户坚持新的需求
2，客户对规划、原型和规格的审核/决策周期比预期的要长
3，客户没有或不能参与规划、原型和规格的审核，导致需求不稳定和耗时的变更
4，客户答复的时间比预期长
5，客户坚持技术决策而导致进度计划延长
6，客户对开发进度管理过细，导致实际进展缓慢
7，客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作
8，客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作
9，客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低
10，客户不接受交付的软件，尽管它满足了所有的规格
11，客户期望的开发速度是开发人员无法达到的
承包商
1，承包商没有按承诺交付组件
2，承包商递交的组件质量低下无法接收，必须花时间改进质量
3，承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平
需求
1，需求已经成为项目基准，但变化还在继续
2，需求定义欠佳，而进一步的定义会扩展项目范畴
3，添加额外的需求
4，产品定义含混的部分比期望需要更多的时间
产品
1，错误发生率高的模块需要比预期更多的测试、设计和实现工作
2，校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作
3，在一个或多个新兴领域推广计算机技术使得计划进度的延长不可预期
4，由于软件功能的错误，需要重新设计和实现
5，开发额外不需要的功能（镀金）延长了计划进度
6，要满足产品规模与速度要求，需要比预期更多的时间，包括重新设计和实现的时间
7，严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作
8，要求与其他系统、其他复杂系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作
9，要求在不同操作系统下运行将花费比预期更长的时间
10，在不熟悉或未经检验的软件环境中运行产生未预料到的问题
11，在不熟悉或未经检验的硬件环境中运行产生未预料到的问题
12，开发一种对组织全新的模块将比预期花费更长时间
13，依赖正在开发中的技术将延长计划进度
外部环境
1，产品依赖政府规章，而规章的改变将是不可预期的
2，产品依赖草拟中的技术标准，而最后的标准将是不可预期的
人员
1，招聘人员所花时间比预期的长
2，作为先决条件的任务不能按时完成
3，开发人员和管理层之间关系不佳导致决策缓慢，影响全局
4，项目组成员没有全身心投入项目，进而无法达到需要的产品性能水平
5，缺乏激励措施，士气低下，降低了生产能力
6，缺乏必要的规范，增加了工作失误与重复工作
7，某些人需要更多时间适应不熟悉的软件工具和环境
8，某些人需要更多时间适应不熟悉的硬件环境
9，某些人需要更多时间适应不熟悉的编程语言
10，项目结束前，合同制人员离开团队
11，项目结束前，雇员辞职
12，项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率
13，项目组成员不能有效地一起工作
14，由于项目组成员间的冲突，导致沟通不畅、设计欠佳、接口错误和额外的重复工作
15，有问题的成员没有调离项目组，损害了项目组其他成员的积极性
16，项目的最佳人选未能加入项目组
17，项目的最佳人选已加入项目组，但因政治或其他原因未能合理使用
18，没有找到项目急需的具有特定技能的人
19，关键人物只能兼职参与
20，项目人员不足
21，任务的分配与人员技能不匹配
22，人员工作的进展比预期的慢
23，项目管理人员怠工导致计划和进度失效
24，技术人员怠工导致工作遗漏或质量低下，工作需要重做
设计和实现
1，设计过于简单，无法确定主要事件，并导致重新设计和实现
2，设计过于复杂，导致一些不必要的工作，影响实现效率
3，设计质量低下，导致重复设计和实现
4，使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误
5，产品采用低级语言来实施，导致生产率比预期的低
6，一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发必要的功能
7，代码和库质量低下，导致需要额外的测试、错误修正或重做
8，过高妒忌了增强型工具对计划进度的节省量
9，分别开发的模块无法有效集成，需要重新设计或重做
过程
1，大量的纸面工作导致进程比预期的慢
2，进程跟踪不准确，导致无法预知项目是否已落后于计划进度
3，前期的质量保证行为不真实，导致后期的重复工作
4，质量跟踪不准确，导致无法得知影响进度的质量问题
5，太不正规，导致沟通不足、质量问题和工作重做
6，过于正规，导致过多耗时无用的工作
7，向管理层撰写进程报告占用的开发人员的时间比预期的多
8，风险管理粗心，导致没有发现重大的项目风险
9，软件项目风险管理花费的时间比预期的多
最有效的风险监控工具之一就是建立前10个风险的列表，该列表包含每个风险当前的级别、以前的级别、已经上表的次数和从上次审核后风险化解的步骤等
调查表明，大约70%的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20%到50%，90%以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高
第一章 欢迎学习快速软件开发
快速开发的成功取决于两个要素：
1，选择有效的实践而不是无效实践
2，选择有利于完成项目锁定目标的实践
面向进度的实践有三类：
1，面向速度的实践：可以提高开发速度，帮助你更快交付软件
2，面向进度风险的实践：可以降低计划风险，帮助你避免更大计划风险
3，面向可视化的实践：可以提高进程可视化程度，帮助你驱散慢速开发的阴云
第二章 快速开发策略
快速开发的4个支柱：
1，避免典型错误（如产品质量低下）
2，打好开发基础（如系统设计）
3，风险管理（如关键承包商的开发进度落后）
4，面向进度的实践
快速开发的四维：人员、过程、产品、技术
1，人员
从某种程度上讲，我们已经认识到人力因素比其他因素对软件性能与软件质量影响更大
反复的研究发现，经验相当的程序员之间效率的差别也是很大的，甚至达到10:1
技术并不是问题的答案，最有效的实践是那些能够发挥工作人员潜能的实践
人力因素极大地影响着生产效率，同时任何关注提高生产效率的组织首先必须有一套良好的人员激励、团队合作、员工选择及培训的机制
几种发挥人员最大潜能缩短项目周期的方法：
1）项目组成员的选择
绝顶的天才
工作匹配
职业的晋升
团队平衡
排除不称职的人员
2）项目组结构
软件企业会从项目团队与项目规模、产品特点以及进度目标的匹配中受益
3）人员激励
一个缺乏动力的人很难努力工作并达成目标
人员激励是使你能够达成快速开发的最具潜力的方法
2，过程
1）避免重复工作
2）质量保证
3）开发基础
4） 风险管理
5）资源目标
6）生命期计划
7）面向客户的开发
3，产品
1）产品规模
2）产品特性
4，技术
选择有效的工具并管理好由此所带来的风险也是争取快速开发主动权的关键之一
5，协同
研究发现，对职员薪金、培训及工作环境的花费由较低水平增长为中等水平时，生产率可以产生比例相当的增长：额外的花费基本可以获得1：1的回报，但当以上花费从中等水平增长到较高水平时，生产率的回报将迅速上升到2：1或3：1
组织范围内的编码标准有助于各个项目的开展，它可以便于一个项目使用另一个项目的部件，同时，重复使用的部件也有利于编码标准的使用，并确保部件在各个项目中具有相同的含义
设计和代码审核有助于编码标准和现有可重复使用部件知识的传播，可以促进成功使用重复部件的质量等级
好的实践应该彼此相互支撑
第三章 典型错误
人员篇：
1，挫伤积极性
2，人员素质低
3，对有问题的员工失控
4，英雄主义
5，项目后期加入人员
6，办公环境拥挤嘈杂
7，开发人员与客户之间发生摩擦
8，不现实的预期
9，缺乏有效的项目支持
10，缺乏各种角色的齐心协力
11，缺乏用户介入
12，政治高于物质
13，充满想象
过程篇：
1，过于乐观的计划
2，缺乏足够的风险管理
3，承包人导致的失败
4，缺乏计划
5，在压力下放弃计划
6，在模糊的项目前期浪费时间
7，前期活动不合要求
8，设计低劣
9，缺乏质量保证措施
10，缺少管理控制
11，太早或过于频繁的集成
12，项目估算时遗漏必要的任务
13，追赶计划
14，鲁莽编码
产品篇：
1，需求的镀金
2，功能蔓延
3，开发人员的镀金
4，又推又拉的交易
5，研究导向的开发
技术篇：
1，银弹综合症
2，过高估计了新技术或方法带来的节省量
3，项目中间切换工具
4，缺乏自动的源代码控制手段
建立你自己的最差实践列表，可以避免在以后的项目中犯同样的错误
第四章 软件开发的基本原则
管理原则：
1，项目估算和进度安排
2，计划编制
3，跟踪
4，度量
技术原则：
1，需求管理
2，设计
3，构建
4，软件配置管理SCM
质量保障原则：
1，易错模块
2，测试
3，技术回顾（走查、代码阅读、检查、技术回顾）
多数有进度问题的软件项目的规模都类似于房屋或更大，对于这种项目，遵循开发的基本原则是可以达到节约时间的目的的
如果你抛开这些指导，那就是在冒风险了
第五章 风险管理
总体上讲，风险管理由风险评估（风险识别、风险分析、风险优先级）和风险控制（风险管理计划、风险化解、风险监控）组成
进度计划风险的完整列表：
计划编制风险：
1，计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致
2，计划是优化的，是“最佳状态”（但不现实，只能算是“期望状态”）
3，计划忽略了必要的任务
4，计划基于使用特定的小组成员，而那个小组成员其实指望不上
5，在限定的时间内无法建成已定规模大小的产品
6，产品规模比估计的要大
7，工作量大于估算数
8，进度已经延迟的项目在重新评估时过于优化或忽视项目历史
9，过度的进度压力造成生产率下降
10，目标日期提前，但没有相应地调整产品范围或可用资源
11，一个任务的延迟导致相关任务的连锁反应
12，涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多
组织和管理：
1，项目缺乏一个有凝聚力的高层领导人
2，由于前期乏力，项目长时间被搁置
3，解雇和消减开支导致项目小组能力下降
4，仅由管理层或市场人员进行技术决策，导致计划进度延长
5，低效的项目组结构降低生产率
6，管理层审查/决策的周期比预期时间长
7，预算消减打乱项目计划
8，管理层做出了打击项目组积极性的决定
9，非技术的第三方的工作比预期长
10，计划性太差，无法适应预期的开发速度
11，项目计划由于压力而放弃，导致开发混乱、低效
12，管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力
开发环境：
1，设施没有及时到位
2，设施到位，但不配套
3，设施拥挤、杂乱或者破损
4，开发工具未能及时到位
5，开发工具不如期望地那样有效，开发人员需要时间创建工作环境或者切换新的工具
6，开发工具的选择不是基于技术需求，不能提供计划要求的性能
7，新开发工具的学习期比预期的长，内容繁多
最终用户
1，最终用户坚持新的需求
2，最终用户对于最后交付的产品不满意，要求重新设计和重做
3，最终用户不买进项目产品，无法提供后续支持
4，最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做
客户
1，客户坚持新的需求
2，客户对规划、原型和规格的审核/决策周期比预期的要长
3，客户没有或不能参与规划、原型和规格的审核，导致需求不稳定和耗时的变更
4，客户答复的时间比预期长
5，客户坚持技术决策而导致进度计划延长
6，客户对开发进度管理过细，导致实际进展缓慢
7，客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作
8，客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作
9，客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低
10，客户不接受交付的软件，尽管它满足了所有的规格
11，客户期望的开发速度是开发人员无法达到的
承包商
1，承包商没有按承诺交付组件
2，承包商递交的组件质量低下无法接收，必须花时间改进质量
3，承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平
需求
1，需求已经成为项目基准，但变化还在继续
2，需求定义欠佳，而进一步的定义会扩展项目范畴
3，添加额外的需求
4，产品定义含混的部分比期望需要更多的时间
产品
1，错误发生率高的模块需要比预期更多的测试、设计和实现工作
2，校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作
3，在一个或多个新兴领域推广计算机技术使得计划进度的延长不可预期
4，由于软件功能的错误，需要重新设计和实现
5，开发额外不需要的功能（镀金）延长了计划进度
6，要满足产品规模与速度要求，需要比预期更多的时间，包括重新设计和实现的时间
7，严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作
8，要求与其他系统、其他复杂系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作
9，要求在不同操作系统下运行将花费比预期更长的时间
10，在不熟悉或未经检验的软件环境中运行产生未预料到的问题
11，在不熟悉或未经检验的硬件环境中运行产生未预料到的问题
12，开发一种对组织全新的模块将比预期花费更长时间
13，依赖正在开发中的技术将延长计划进度
外部环境
1，产品依赖政府规章，而规章的改变将是不可预期的
2，产品依赖草拟中的技术标准，而最后的标准将是不可预期的
人员
1，招聘人员所花时间比预期的长
2，作为先决条件的任务不能按时完成
3，开发人员和管理层之间关系不佳导致决策缓慢，影响全局
4，项目组成员没有全身心投入项目，进而无法达到需要的产品性能水平
5，缺乏激励措施，士气低下，降低了生产能力
6，缺乏必要的规范，增加了工作失误与重复工作
7，某些人需要更多时间适应不熟悉的软件工具和环境
8，某些人需要更多时间适应不熟悉的硬件环境
9，某些人需要更多时间适应不熟悉的编程语言
10，项目结束前，合同制人员离开团队
11，项目结束前，雇员辞职
12，项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率
13，项目组成员不能有效地一起工作
14，由于项目组成员间的冲突，导致沟通不畅、设计欠佳、接口错误和额外的重复工作
15，有问题的成员没有调离项目组，损害了项目组其他成员的积极性
16，项目的最佳人选未能加入项目组
17，项目的最佳人选已加入项目组，但因政治或其他原因未能合理使用
18，没有找到项目急需的具有特定技能的人
19，关键人物只能兼职参与
20，项目人员不足
21，任务的分配与人员技能不匹配
22，人员工作的进展比预期的慢
23，项目管理人员怠工导致计划和进度失效
24，技术人员怠工导致工作遗漏或质量低下，工作需要重做
设计和实现
1，设计过于简单，无法确定主要事件，并导致重新设计和实现
2，设计过于复杂，导致一些不必要的工作，影响实现效率
3，设计质量低下，导致重复设计和实现
4，使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误
5，产品采用低级语言来实施，导致生产率比预期的低
6，一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发必要的功能
7，代码和库质量低下，导致需要额外的测试、错误修正或重做
8，过高妒忌了增强型工具对计划进度的节省量
9，分别开发的模块无法有效集成，需要重新设计或重做
过程
1，大量的纸面工作导致进程比预期的慢
2，进程跟踪不准确，导致无法预知项目是否已落后于计划进度
3，前期的质量保证行为不真实，导致后期的重复工作
4，质量跟踪不准确，导致无法得知影响进度的质量问题
5，太不正规，导致沟通不足、质量问题和工作重做
6，过于正规，导致过多耗时无用的工作
7，向管理层撰写进程报告占用的开发人员的时间比预期的多
8，风险管理粗心，导致没有发现重大的项目风险
9，软件项目风险管理花费的时间比预期的多
最有效的风险监控工具之一就是建立前10个风险的列表，该列表包含每个风险当前的级别、以前的级别、已经上表的次数和从上次审核后风险化解的步骤等