《快速软件开发》笔记二，快速开发

第六章 快速开发中的核心问题
活动              小型项目           大型项目
总体/设计           10%                 30%
详细设计            20%                 20%
编码/测试           25%                 10%
单元测试            20%                  5%
综合测试            15%                 20%
系统测试            10%                 15%

软件项目的平衡三角：进度、费用、产品

实现快速开发的方法：
生命期计划
估算
进度计划
面向客户开发
激励
团队合作
团队结构
功能限定
生产力工具
项目校正

第七章 生命期计划
选择了适宜的生命期模型，就可以提高开发速度、提升质量、加强项目跟踪和控制、减少成本、降低风险，或是改善用户关系
错误地选择生命期模型，必定会导致工作拖沓、劳动重复、无畏的浪费和遭受挫折

1，纯瀑布模型
文档驱动，意味着主要工作成果是通过文档从一个阶段传递到下一个阶段
在纯瀑布模型中，各阶段不连续也不交迭
软件概念->需求分析->架构设计->详细设计->编码和测试->系统测试
当你有一个稳定的产品定义和很容易理解的技术解决方案时，纯瀑布模型特别合适
对于那些容易理解但很复杂的项目，采用纯瀑布模型比较适合，因为你可以用顺序的方法处理复杂的问题
当开发队伍的技术力量比较弱或者缺乏经验的时候，瀑布模型更为适宜
如果你采用瀑布模型，遗漏需求的时候是代价高昂的错误
瀑布模型最主要的问题是缺乏灵活性

2，编码修正模型
编码修正模型比较常见，如果你没有明确地选择其他生命期模型，也许你就会不自觉地进行编码，然后进行修改
编码修正模型的好处：一，它不需要什么成本，二，它只需要极少的专业知识
对于稍微大一点的项目，采用这种模型是很危险的
它虽然不需要什么成本，但是它也不提供评估项目进展情况的手段

3，螺旋模型
螺旋模型是一种以风险为导向的生命期模型，它把一个软件项目分解成一个个小项目
每个小项目都标识一个或多个主要风险因素，直到所有主要风险因素都被确认
螺旋模型的基本思路是，从一个小范围的关键中心地带开始寻找风险因素，制定风险控制计划，并交付给下一步骤，如此迭代
每次迭代都把项目扩展到一个更大的规模，每次迭代都包括以下六个步骤：
1)确定目标、方案和约束条件
2)识别并解决风险
3)评价备选方案
4)开发本次迭代可供交付的内容，并检查它们的正确性
5)规划下一个迭代过程
6)交付给下一步骤，开始新的迭代过程

螺旋模型最重要的优势是随着成本的增加，风险程度随之降低
螺旋模型是风险导向的，对于任何无法逾越的风险你都可以预知
螺旋模型的惟一缺陷是它比较复杂，需要责任心、专注和管理方面的只是，通过确定目标和可以验证的里程碑，来决定你是不是已经准备好在“桂皮卷”上再加一层

是比较困难的

4，经过修改的瀑布模型
1)生鱼片模型(把阶段重叠起来的瀑布模型)
2)具有子项目的瀑布模型
3)能够降低风险的瀑布模型(需求分析和架构设计阶段采用螺旋模型)

5，渐进原型
在需求变化很快的时候、用户很难提出明确需求的时候、你和用户都不知道怎么才好的时候，渐进原型特别有用
最初概念->设计和实施最初原型->精化原型直到可以被接受->完成和交付原型

6，阶段交付
阶段交付的特点是不会再项目结束的时候一下交付全部软件，而是在项目整个开发过程中持续不断的交付阶段性成果
阶段交付和渐进原型不同，在阶段交付的时候，你明确地知道下一步要完成什么工作
软件概念->需求分析->架构设计->阶段1：详细设计，编码，调试，测试，交付->阶段2：详细设计，编码，调试，测试，交付...
阶段交付的主要缺点是，如果管理层面和技术层面上缺乏仔细的规划，工作就无法进行

7，面向进度的设计
软件概念->需求分析->架构设计->高优先级：详细设计，编码，调试，测试->中优先级：详细设计，编码，调试，测试...->交付
超出时间或费用: ->中优先级：详细设计，编码，调试，测试->低优先级：详细设计，编码，调试，测试

8，渐进交付
渐进原型和渐进交付的最大不同不在于基本方法，而在于其着重点
在渐进原型中，你最初强调的是系统的看得见的样子，然后回来堵住系统基础上的漏洞
在渐进交付中，你最初的重点是系统的核心，包括了不太可能因为用户反馈意见而改变的底层系统功能
软件概念->初步需求分析->架构和系统内核设计->
循环：开发一个版本->交付该版本->得到用户反馈->并入用户反馈
->交付最终版本

快速开发生命期模型和项目需求结合得十分紧密，最有效的模型的选择完全依据项目需求

第八章 估算
除非你很清楚地知道客户想要什么，否则你很难知道能否在期望时间段内建造客户想要的产品
估算步骤：
1，估算产品规模（代码行或功能点）
2，估算工作量（人月）
3，估算进度（日历月份）
4，提供某一范围内的估算，并且随着项目的进行，定期改进范围，以提供更高的精确度

第九章 进度计划
很多进度计划都过于乐观，原因是多方面的
不好的管理方法的表现之一是：当某件事进展缓慢时，应加倍地督促
进度压力与计划偏离间的恶性循环：
更大的进度压力->更重的负担->更多的错误->更加偏离进度计划->更大的进度压力...
坚持客观标准：
1，谈判不要局限于估算本身（指出不可实现进度计划的不合理之处并表示拒绝接受，才是真正的为客户利益着想）
2，坚持由专业组织进行进度估算
3，坚持科学的估算过程
4，顶住压力

第十章 面向客户开发
调查表明，项目成功的第一要素是用户的参与，造成项目完成时间延迟、成本超出预算、达不到预期功能的前三个因素分别是缺乏与用户沟通、需求说明不完备以及

中途变更需求说明
面向客户的开发方面对开发过程的影响：
1，计划
1）选择适当的生命期模型
2）弄清项目最终是让谁满意
3）建立有效的客户沟通渠道
4）力争采用双赢的解决方案
5）进行风险管理
2，需求分析
1）使用需求诱导方法帮助客户找出真正的需求
2）组成一个中心攻关组，帮助搞清用户到底需要什么
3）把用户使用软件的情况录在录像带上
4）进行客户满意度问卷调查，以便得到你同客户的关系的量度值
3，设计
在系统设计中应允许客户偶尔提出需求变更
4，实现
1）编写易读易改的代码，这能提高对客户需求变化的能力
2）采用诸如最短里程碑等进度监控方法，以便客户了解项目进度
3）选择一个能为用户提供稳定明显的进度标识的生命期模型

软件开发领域中的诸多问题，尤其是关于开发速度的争执，大都源于客户对项目持有的不现实的期望
作为开发人员，应尽量客观准确地设定自己的期望值，以免客户对进度计划或交付日期寄予不现实的希望

第十一章 激励机制
激励是决定工作表现最重要的影响因素

1，开发人员的典型动机
不同人员动机比较：
顺序   开发人员                       项目管理人员                         普通人
1      成就感                         责任感                               成就感
2      发展机遇                       成就感                               受认可程度
3      工作乐趣                       工作乐趣                             工作乐趣
4      个人生活                       受认可程度                           责任感
5      成为技术主管的机会             发展机遇                             领先
6      领先                           与下属关系                           工资
7      同事间人际关系                 同事间人际关系                       发展机遇
8      受认可程度                     领先                                 与下属关系
9      工资                           工资                                 地位
10     责任感                         操控能力                             操控能力
11     操控能力                       公司政策和经营                       同事间人际关系
12     工作保障                       工作保障                             成为技术主管的机会
13     与下属关系                     成为技术主管的机会                   公司政策和经营
14     公司政策和经营                 地位                                 工作条件
15     工作条件                       个人生活                             个人生活
16     地位                           工作条件                             工作保障

与管理人员相比，开发人员较少关系责任感或受认可程度
若要激励开发人员，更应强调技术挑战性、自主性、学习并使用新技能的机会、职业发展以及对他们私人生活的尊重等

踹一脚并不能产生动力，只能产生被动行为
为达到开发人员工作表现的最高级，不仅要让开发人员表面上动起来，更要调动其内在动力
要激发研发人员的创造力，就要为他们创造满足内在需求的环境
当被激发出创造力时，研发人员会投入时间和精力并享受其中
激励研发人员的最重要的5个因素是：成就感、发展机遇、工作乐趣、个人生活和成为技术主管的机会
其他激励因素：奖赏和鼓励、向导项目、对业绩的评价

士气杀手：
1，保健因素
2，管理操控
3，执行计划的压力
4，缺乏对开发而付出努力的表扬
5，因技术措施不当受到牵连
6，开发人员没有参与同自己有关的决策行为
7，生产率障碍
8，低质量
9，过分夸张的激励形式
微软非常关注员工士气。微软的每一个小组都有一份士气基金，可以做这个小组成员任何想做的事情。有些小组用它来买爆米花机；有些去滑雪，去打保龄球，或去

野餐，有些买T恤衫；还有的去看电影
在当地，微软被称为“高薪的血汗工厂”，这说明微软太会激励其员工了

第十二章 团队合作
并不仅仅是一组人恰巧在一起工作就可以构成一个团队
在“团队的智慧”一书中将团队定义为：能相互负责的、具有共同的目的、共同的执行目标和共同的方法的有互补技能的一些人
一个高业绩、定形的、有凝聚力的团队的特点：
1）共同的、可提升的愿景或目标
2）团队成员的认同感
3）结果驱动的结构
4）胜任的团队成员
5）对团队的承诺
6）相互信任
7）团队成员间相互依赖
8）有效的沟通
9）自主意识
10）授权意识
11）小的团队规模
12）高层次的享受

成功管理高凝聚力团队的关键：
1）建立一个愿景
2）创造变化
3）管理团队
4）以具有挑战性的、清楚的和支持的方式委派团队任务
5）将如何完成任务的细节留给团队，可能包括个人工作责任的分配
6）当团队运行得不好的时候，想想MOI模式：多数的团队问题来源于动机、组织或信息

团队为什么会失败：
1）缺乏共同的愿景
2）没有认同感
3）缺乏认可感
4）生产力障碍
5）低效率的沟通
6）缺乏信任
7）有问题的员工

团队领导实战指南：
1，避免团队目标向政治问题妥协
2，向团队目标显示个人的承诺
3，不用太多优先级的事物冲淡团队的工作
4，公平、公正地对待团队成员
5，愿意面对和解决与团队成员不良表现有关的问题
6，对来自员工的新思维和新信息采取开放的态度

团队成员实战指南：
1，展示对个人角色和责任的真实理解
2，展示目标和以事实为基础的判断
3，和其他团队成员有效地合作
4，使团队目标优先于个人目标
5，展示投身于任何项目成功所需的努力的愿望
6，愿意分享信息、感受和产生适当的反馈
7，当其他成员需要时给予适当的帮助
8，展示对自己的高标准要求
9，支持团队决策
10，展示直接面对重要问题的勇气和信念
11，以为团队的成功而奋斗的方式体现带头作用
12，对别人的反馈做出积极的反应

第十三章 团队结构
有效运行的团队设计特征：
1，明确的角色和责任
2，监控个人表现和提供反馈
3，有效的沟通
4，以事实为依据制定决策

第十四章 功能限定
1，项目早期：功能的简化
2，项目中期：功能蔓延的控制
3，项目后期：功能剪切

第十五章 生产率工具
工具遴选标准：
1，预计收益
2，供货商稳定性
3，质量
4，成熟度
5，培训时间
6，适用性
7，兼容性
8，发展规划
9，定制遴选标准

第十六章 项目修复
一般的修复方案：
1，缩减项目规模，以便在计划的时间与工作量内完成项目
2，把注意力放在短期的改善上，以提高过程的生产率
3，面对软件不可能按时完成的现实，放弃原计划，并着手准备危害控制，可能包括取消项目
本章要介绍的方式：
扔掉一些功能，尽量提升生产率，必要时抛弃原进度计划

理念：
如果你想改变现状的话，动作就要做大一点，而且马上去做。小修小补对整个开发组的士气不利，而且在管理层看来就仿佛你也不知道该怎么办一样。要想重新获取

控制权，采取断然行动要比长时间的小打小闹要好得多

修复计划：
1，第一步
1）评估你的处境
2）应用W-理论分析（平衡各方需要，使项目所有干系人都成为Winner）
3）自己作好修复项目的准备
4）问问你的开发组需要做什么
5）变得现实一些
2，人员
1）采取一切措施恢复开发组的士气
2）要确保你已为开发组创造了保健类因素
3）消除重大的人员问题
4）消除重大的领导问题
5）增加新手一定要审慎
6）充分利用开发人员的时间
7）允许开发组成员各有不同
8）观察开发人员的节奏
3，过程
1）修正明显支离破碎的开发过程
2）创建详细的小型里程碑
3）依据里程碑的完成来安排进度
4）细致地追踪进度进展状况
5）记录里程碑未完成的原因
6）短期后再调整--1周或2周
7）在得出有意义的进度前不要固守着某一个
8）进行风险管理要不辞辛劳
4，产品
1）稳定需求
2）修正特性集
3）评估你的政治地位
4）去除没有用的垃圾
5）降低缺陷数目，并要持续降低
6）达到一个可知的良好状态，并在此基础上继续
5，找准时机
如果项目的确已经陷入困境，建议你抓好展示修复计划的时机，以便让项目的其他人员有着充分的接受准备，项目成功也就有保障了