第一章 绪论
软件已经成为世界舞台上最重要的技术之一，在有限的时间和资源下开发和维护出高质量的软件依然是我们面临的难题：软件工程为开发及维护高质量的软件产品提供一个工程框架。
什么是软件工程？
建立和使用一套合理的工程原则，从而经济地获得可靠的、可以在实际机器上高效运行的软件。——Fritz Bauer ，NATO 会议，1968
软件工程是：
（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
（2）在（1）中所述方法的研究 ——IEEE，1983
软件工程是一种层次化的技术：工具->方法->过程->实现对象的质量焦点。（软件工程体系层次图）
质量焦点层：软件工程的根基，支持软件工程的根基就在于对质量的关注，任何工程方法必须以组织对质量的承诺为基础。质量管理的理念刺激了不断的过程改进，正是这种改进导致了更加成熟的软件工程方法的不断出现。全面质量管理。6 西格玛理论
过程层：软件工程的基础，过程定义了一组关键过程区域的框架，这些关键过程区域构成了软件项目管理控制的基础。顺序->产品->管理->里程碑。软件过程将技术层、工具层结合在一起，使得软件能够被合理地、及时地开发出来。
方法层：提供技术解决方案，解决开发软件在技术上需要“如何做”的问题，涵盖了一系列的任务。软件工程方法依赖于一组基本原则，这些原则涵盖了软件工程的所有技术领域。沟通->需求分析->设计建模->编程、测试。
工具层：服务于过程和方法，为过程和方法提供自动化或半自动化的支持。当这些工具被集成起来使得一个工具产生的信息可以被另外一个工具使用时，一个支持软件开发的系统就建立了，称为计算机辅助软件工程（CASE）。
可见软件工程有三个主要研究内容：过程、方法、工具 —— 软件工程三要素
不同的软件团队对 “系统化、规范化、可量化”有不同的定义。软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过实践考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
软件工程体系层次的拓展
软件工程包括技术和管理两方面的内容，是技术和管理密切结合所形成的工程学科。通过计划、组织和控制等一系列活动，合理地配置和使用资源，以达到既定的目标。 技术+管理=软件工程
第二章 过程综述
2.1 软件过程与框架
过程：为实现一个给定目标而进行的一系列运作步骤。软件过程：开发和维护软件极其相关产品所涉及的一系列活动。
软件过程框架是通过定义若干框架活动，为完整的软件开发过程建立基础。其中：每一个活动均由一组软件工程动作组成，每一个动作均包含一系列相互关联的任务并产生一个工作产品。
适合绝大多数软件项目：【通用框架活动（generic activity）】沟通：交流与协作 –> 策划：制定计划–> 建模：创建模型和设计 –> 构建：编码和测试 –> 部署：交付、用户评测和反馈。
具有普适性，适合于各个软件工程: 【保护性框架活动（umbrella activity）】软件过程跟踪与控制–> 风险管理 –> 软件质量保证 –> 测量 –> 软件配置管理 –> 技术评审。
【公用过程框架】通用框架活动适用于所有软件项目，而不在乎其规模和复杂性。构成软件工程动作的任务集合可以依项目需要和团队特点而不同—使得框架活动适应于不同软件项目的特征和项目组的需求。基于通用框架活动和保护性框架活动，软件过程可以提供一个公用过程框架，在该框架下可以建立一个软件开发的综合计划。若干保护性活动独立于任何一个框架活动，且贯穿于整个过程模型之中。
所有的软件过程都可以用公用过程框架来概括。但是，由于软件所需解决的问题、项目特点、开发团队及组织文化的不同，软件过程的适应性调整才是成功的关键。
讨论：不同的软件过程之间有哪些不同之处。
2.2 过程模式与过程评估
过程模式提供了一个模板，一种在软件过程的背景下，统一描述问题解决方案的方法。
Ambler 的过程模式模板：模式名称 –> 目的 –> 类型 –> 启动条件 –> 问题、解决方法 –> 结束条件 –> 相关模式、已知应用实例。
根据抽象层次不同，过程模式有三种类型：阶段模式：描述完整的软件过程或软件过程阶段。步骤模式：描述过程框架活动。任务模式：描述工作任务（逐层细化）
过程模式提供了一种有效的机制描述各种软件过程。过程模式可以复用。建立了过程模式就可以构建过程模型。过程模型需要经过评估以确定是否满足过程标准要求。
过程评估方法：用于组织内部过程改进的 CMM 评估；用于过程改进的标准 CMMI 评估；SPICE（ISO/IEC 15504）；ISO9001-2000。过程评估的作用：软件过程改进和组织能力确定。
第三章 惯例过程模型
3.1 惯例过程模型概述
惯例过程模型是包括活动、动作、任务、里程碑和工作产品的明确的集合，旨在开发高质量的软件。惯例过程模型通过一套框架活动指导项目团队，这些框架活动被组织到一个过程流中，每个过程模型的术语和细节不同，但通用框架活动在一定程度上保持一致。
惯例过程模型的优点：为活动提供稳定、控制和有组织性，以有序和项目的一致性为首要目标。为软件工程工作增加了大量有用的结构化设计，为项目团队提供了有效的路线图。惯例过程模型的不足：使用过程中需要调整才能适应不同项目需要，缺乏灵活性、应对变更能力不强。
3.2 瀑布模型
所有过程模型的鼻祖 —— Royce，1970。
瀑布模型又称经典生命周期，是一个系统的顺序的软件开发方法。瀑布模型从需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供完整的软件并提供持续的技术支持。
传统瀑布模型：{沟通：{项目启动，需求获取}——>策划：{估算，计划，跟踪}——>建模：{分析、设计}——>构建：{编码，测试}——>部署：{交付，支持，反馈}}
实际瀑布模型：每两层之间相互指向，且最下面一层依次指向上面每一层。{沟通：{项目启动，需求获取}<==—>策划：{估算，计划，跟踪}<==—>建模：{分析、设计}<==—>构建：{编码，测试}<=—>部署：{交付，支持，反馈}}
瀑布模型的特点：阶段间具有顺序性和依赖性，推迟程序的物理实现，质量保证：每个阶段必须完成规定的文档；每个阶段结束前完成文档审查，及早改进错误。是一种严格线性的、按阶段顺序的、逐步细化的过程模型，文档驱动，强调文档的做用。
瀑布模型的优点：有利于人员的组织与管理，有利于软件开发方法和工具的研究，可以提高大型软件项目开发的质量和效率。
瀑布模型的缺点：难以解决需求不明确的问题，缺乏灵活性，开发周期长，易于陷入“阻塞状态”
，反馈时间长，风险大，可操作性差。
瀑布模型的适用范围：需求明确、全面，开发过程中没有或很少变更的项目；开发人员熟悉项目产品的应用领域；用户使用环境稳定的项目；开发过程很少或不需要用户参与的项目。
3.3 增量过程模型
增量过程模型是一种以增量的形式生产软件产品的过程模型，适用于以下场景：初试的软件需求有明确的定义，但是，受时间或资源的限制，不宜单纯运用线性模型。迫切需要迅速提供一套功能有限的产品，在后续版本中细化和扩充。
增量过程模型的代表：增量模型；RAD 模型。
3.3.1 增量模型
增量模型以迭代的方式运用瀑布模型。每一个增量都提交一个可以操作的产品。
增量模型的特点：融合瀑布模型的基本成分和迭代的特征；以功能递增的方式进行软件开发。能较快地产生可操作的系统；在每一步递增中，均发布一个可操作的增量版本，把用户/开发者的经验结合到不断求精的产品中。
增量模型的优点：人员分配灵活，刚开始不用投入大量人力资源。规避技术风险。在短时间内提交核心产品，对用户起到镇静剂的作用，有一定市场。
增量模型缺点：秉性开发构建，有可能遇到不能集成的风险，对软件体系结构要求高。容易退化为“边做边改”模型，导致对软件过程的控制失去整体性。
增量模型的适用范围：已有产品升级项目或新版本的开发项目。需求明确并对使用开始时间有严格要求的项目。
3.3.2 RAD 模型
RAD（Rapid Application Development，快速应用程序开发）是一种适用于极端开发周期的增量软件过程模型，是瀑布模型的一个“高速”变种，通过基于构件的构建方法实现快速开发。
RAD 模型的优点: 在项目需求被很好地理解并且项目边界固定的情况下，能够使项目团队在极短的
时间内创造出“全功能系统”。
RAD 模型的缺点：对大型项目而言，rad 需要足够的人力资源。开发者和客户都要实现承诺，否则将导致失败。并非所有系统都适合：不能合理模块化的系统、高性能需求并且要调整构件接口的系统均不适合。不适合技术风险很高的情况。
无论是增量模型，还是 RAD 模型，增量过程模型主要用于需求明确但又受时间或资源约束的项目。
3.4 演化过程模型
演化过程模型利用迭代的思想方法，使软件工程渐渐地开发逐步完善的软件版本。演化过程模型主要适用于在项目开发初期项目需求不明确，把握不充分的项目。
演化过程模型的代表：原型模型、螺旋模型。
3.4.1 原型模型
原型模型针对需求不明确的情况，通过迅速构建可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的需求基础上开发出满意的产品。原型模型是用户驱动的（即需求模糊或随时间变化的系统）。
原型模型要分两步走：第一步，快速构建原型系统，实现用户与系统的交互，通过用户对原型的评
价，进一步细化需求，通过逐步调整原型使其满族用户的要求，从而确定用户的真正需求。（迭代）第二步，在第一步的基础上开发用户满意的产品。
原型的分类> 探索型原型：用于需求分析阶段，目的是要澄清用户的需求，确定所期望的特性，并探索各种方案的可行性。实验型原型：用于设计阶段，考核实现方案是否合适。演化型原型：用于及早向用户提交一个原型系统，在得到用户的认可后不断扩充演变为最终的产品。
原型的使用策略> 抛弃策略：原型仅用于开发过程的某个阶段，该阶段结束后，原型随之作废。附加策略：原型用于开发的全过程，有最基本的和新开始，逐步增加新的功能和新的需求，最后发展为用户满意的最后总系统。
原型模型的优点：克服瀑布模型的缺点，缺少由于软件需求不明确带来的开发风险。
原型模型的缺点：容易引起用户误解。缺少项目标准，对用户参与程度要求高。用户可能不断提出新要求，原型迭代的周期很难控制。额外的花费：研究结果表明构造一个原型可能需要 10%额外花费。为了尽快实现原型，采用了不合适的技术，运行效率可能会受影响。
原型模型的适用范围：适合于那些不能确切定义需求的项目，用于未能详细定义输入、处理、输出
开发人员对算法效率、OS、人机交互的形式不能确定。
3.4.2 螺旋模型
螺旋模型（Boehm，1988 年提出），综合了原型模型的迭代特征和瀑布模型的系统性和可控制性的特点，增加风险分析，是以风险为导向的生命模型。采用循环方式逐步加深系统定义和实现的深度，同时降低风险。确定一系列里程碑，确保项目干系人都支持可行的和令人满意的解决方案。
螺旋模型特点: 把软件开发过程组成一个逐步细化的螺旋周期序列，每经历一个周期，系
统就得到进一步的细化和完善；紧密围绕开发中的风险问题，用风险分析推动软件设计向深一层拓展、求精；强调持续地判断、确定和修改用户任务目标，并按成本、效益来分析候选的软件产品性质对任务目标的贡献；可结合采用多种软件开发方法，但究竟结合哪一种方法，仍由风险分析来决
定。
螺旋模型的优势：设计上具有灵活性，可以在产品的各个阶段进行变更，以小的分段来构建大型系统，易于成本计算。客户参与各阶段的开发，保证项目不偏离正确方向和项目的可控性。引入风险分析，随着迭代的增加风险程度随之降低。
螺旋模型的不足：过多的迭代次数会延长交付时间，增加开发成本。对风险评估技术和经验有较高要求，评估不当会造成重大损失。螺旋模型只适合于大型软件项目的开发。
3.4.3 总结
演化过程模型对持续变更能够迅速做出反应并占据市场，然而：演化花周期数的不确定性，导致难以进行项目策划，演化速度无法确定，软件过程应首先侧重灵活性、可拓展型、开发速度，而不是高质量，在产品的灵活性、可拓展型、开发速度和高质量之间进行权衡是对我们的挑战！！
3.5 统一过程模型
统一过程模型（RUP/UP, Rational Unified Process）：RUP 拥有自己的一套架构，且这套架构是以一种大多数项目和开发组织都能够接受的形式存在【统一】。RUP 是以一种软件开发过程，提供了如何对软件组织进行管理的方式，并拥有自己的目标和方法【过程】。
统一过程模型是一种以用例驱动、以体系结构为核心、迭代及增量的软件过程模型，由 UML 方法和工具支持，广泛应用于各类面向对象项目。
RUP 是按照二维结构进行组织的: 横轴，按时间组织，显示 RUP 的动态特征，通过迭代式软件开发的周期、阶段、迭代和里程碑等动态信息表示。纵轴，按内容组织显示 RUP 的静态特征，通过过程的构件、活动、工作流、产品和角色等静态概念来描述系统。
3.5.1 RUP的静态结构
RUP 的静态结构包括 6 个核心工作流和 3 个核心支持工作流。
核心工作流：1、业务建模 2、需求 3、分析设计 4、实现 5、测试 6、部署
核心支持工作流：1、配置与变更管理 2、项目管理 3、环境
工作流程：业务建模——>需求——>分析设计——>实现 测试 部署——>配置与变更管理——>项目管理——>环境
业务建模工作流产生的工作产品：商业逻辑建模（USE CASE）（ROSE）；业务需求说明书（MS WORD）；专业词汇表（英汉对照）（MS WORD）；风险说明（MS WORD）；复审说明书。
需求工作流：确保开发人员构建正确的系统；了解目标组织的结构及机制；目标组织中当前存在的问题并确定改进的可能性；确保客户、最终用户和开发人员就目标组织达成共识；导出支持目标组织所需的系统需求，建立系统需求模型：用例图（表示系统的功能）。
分析设计工作流：将系统需求转换为未来系统的设计；逐步开发强壮的系统构架；使设计适合于实施环境，为提高性能而进行设计。
分析设计工作流的流程：
分析设计工作流的工作产品: 系统总体设计报告（MS WORD）；系统领域模型 DOMAIN MODEL （ROSE）；系统设计模型 DESIGN MODEL （ROSE）；数据库设计模型 （POWER DESIGNER）
数据字典（MS WORD）；系统详细设计报告（MS WORD）；工作量化书（MS WORD）；风险列表。
实施工作流：定义代码结构；以构件的方式实施类和对象；对已开发的构件按单元来测试，并且将结果集成到可执行系统中；测试仅限于对各个类进行单元测试，系统测试和集成测试将在测试工作流程中进行说明。
实施工作流的流程：
测试工作流：核实对象之间的交互。核实软件的所有构件是否正确集成。核实所有需求是否已经正确实施。确定缺陷，确保在部署软件之前将缺陷解决。
3.5.2 RUP 的动态结构
迭代开发：通过多次执行不同的开发工作流，逐步确定一部分需求分析和风险，在设计、实现并确认这部分后，再去做下一部分的需求分析、设计、实现和确认工作，依次进行下去，直至整个项目完成，这样能在逐步集成中更好的理解需求，构造一个健壮的体系结构。
RUP 中的迭代（每个迭代周期都是一个小的瀑布模型）
对迭代的特定短期目标进行分割并组织迭代开发秩序，迭代过程划分为 4 个连续的阶段:
起始——>细化——>构建——>转换
起始：明确项目规模，了解环境、最重要的需求和约束，得出产品验收标准。计划和准备商业理由，评估风险。评估人员配备、计划、成本、进度、收益折衷的备选方案。明确系统关键用例和主要的功能场景；展现至少一种符合主要场景要求的候选软件体系结构；准备环境做出最初的项目成本和日程估计。为系统建立商业案例和确定项目的边界。
细化：确保软件结构、需求、计划足够稳定；确保风险降低到能预计完成整个项目的成本和日程的程度；通过完成软件结构上的主要场景建立软件体系结构的基线；所有用力均被识别，大多数用例描述被开发；建立一个包含高质量组件的可演化的产品原型；确定项目的总体计划，显示迭代过程和对应的审核标准；分析问题、建立体系结构基础、编制计划、淘汰最高风险元素。
构建：完成所有必须功能的分析、设计、开发和测试工作；根据实际需要形成各个版本，达到适当的质量目标；采用循环渐进的方式开发出完整产品：达到一定程度上的并行开发；重点：管理资源和控制运作以优化成本、日程、质量的生产过程；通过优化资源和避免不必要的返工达到开发成本的最小化。开发构件和应用程序功能并集成为产品，所有功能被详尽的测试。
转换：进行 Beta 版测试，按用户的要求验证新系统。替换旧的系统。对用户和维护人员进行培训。开始调整活动，例如调试、性能或可用性的增强。与用户达成共识，配置基线与评估标准一致。
将软件产品交付给用户。四个阶段分别对应着关键里程碑的划分：每个阶段都有可能经历瀑布模型的从需求分析开始的各个步骤，只是每个步骤的高峰期会发生在相应的阶段。
各阶段的工作量和进度分布。不同的工作流在不同的时间段内工作量不同。值得注意的是，几乎所有的工作流，在所有的时间段内均有工作量，只是大小不同而已。这与瀑布过程有明显的不同。
统一过程各阶段的工作产品
3.5.3 RUP 与通用活动的对照
| 阶段 | 活动 | 焦点 |
|---|---|---|
| 起始 | 沟通策划 | 需求工作流，分析工作流 |
| 细化 | 策划建模 | 需求工作流，分析工作流，设计工作流 |
| 构建 | 构建 | 实现工作流 |
| 转换 | 构建部署 | 实现工作流，测试工作流 |
总结
迭代式软件开发。需求管理。【以体系结构为中心，基于构件的架构应用：1.逻辑视图 2.过程视图 3.物理视图 4.部署视图 5.用例视图】【建立可视化的软件模型：1.Use Case 视图 2.分析视图 3.设计视图 4.实现视图】【软件质量验证】【软件变更控制】
RUP 三大特征：迭代开发、用例驱动、以架构为中心
RUP 的优点：降低风险、加快整个开发工作的进度、易于管理需求的变化
RUP 不足：RUP 只是一个开发过程，并未涵盖软件过程的全部内容、RUP 适用于规模比较大的软件项目，对于中，小规模的项目开销比较大、RUP 强调项目的可控性，是一个用力驱动的基于 UML 和构件架构的迭代增量式开发过程。
RUP 是可以裁减的，对于角色，流程，活动的要求是灵活，可配置的。RUP 的各个里程碑，都规定了要交付的成果，它强调及时的更新与同步。RUP 是一种【重量级】的软件开发方法，比较适合大中型的软件项目和产品的开发。
3.6 专用过程模型
专用过程模型具有传统过程模型的特点，但是，只适用于【某些特定】的软件工程方法，应用面较窄。基于构件的开发模型、形式化方法模型。
3.6.1 基于构件的开发
基于构件的开发采用预先打包的如那件构件开发程序，以迭代的方式构建产品。流程：
1、构建识别，评估，选择 2、设计软件架构容纳所选择构件 3、将选择构建集成到架构中 4、测试
5、重复上述步骤直到产生满意的产品
优势：支持软件复用、缩短开发周期、降低成本、提高软件生产率
局限：依赖于构件库的丰富程度
3.6.2 形式化方法模型
形式化方法模型使用严格的数学描述来说明、开发和验证预计计算机的系统。【主要活动】是生成计算机软件形式化的数学规格说明。
优势：应用数学分析的方法发现和改正歧义性问题、不完整问题、不一致问题。（评审无关性）因而，可以提供无缺陷的软件。
不足：形式化模型开发非常耗时、成本很高；需要大量培训；对用户的技术水平要求高；用于开发高度关注安全的软件。
总结
惯例过程模型力图给软件开发带来次序和结构。每一种惯例过程模型都建议了一种不同的过程流，但是都实现了同样的一组通用框架活动：【沟通、策划、建模、构建、部署】
第四章 敏捷过程模型
回顾历史：20 世纪 50 年代，IID 方法—迭代、增量 ==> 20 世纪 60 年代，Evo 方法—每 1-2 周为一迭代周期 ==> 1970 年，Royce 博士，瀑布模型 ==> 1986 年，Takeuchi、Nonaka "The New Product Development Game" 引入了一种与橄榄球运动相似的软件开发方法，精益产品开发（TPS）的思想出现、成功 ==> 20 世纪 90 年代，出现了一批敏捷方法学… ==> 敏捷软件开发宣言（2001 年，敏捷联盟—Snowbird）：
个人和交互重于方法和工具–Individuals and interactions over processes and tools
可工作的软件重于完备的文档 –Working software over comprehensive documentation
与客户的协作重于合同谈判 –Customer collaboration over contract negotiation
响应变化重于严格遵照计划 –Responding to change over following a plan
惯性过程模型忽视开发计算机软件的人的弱点：软件工程师在技能水平，主动性，服从性，一致性，责任心，沟通能力方面的极大差异；人不能一致连贯的做同一件事
惯性过程模型利用纪律或宽容来处理人的问题：高度纪律性的方法不容易被接受和保持，非常脆弱
、宽容有可能造成产能低下。
敏捷（Agile)方法是一种以人为核心，迭代，循序渐进的开发方法，核心是适应客户需求的快速变化，即拥抱变化。敏捷方法强调迭代式开发，客户参与，小版本。
4.1 敏捷
敏捷包括以下内容：有效地响应变化、鼓励建立便于沟通的团队结构和协作态度、强调可运行软件的快速交付而不是中间产品、强调客户作为开发成员的持续参与
敏捷技术：用户故事 user story、结对编程、测试驱动开发、持续集成 （对每个人的开发结果放在指定的工作目录）、迭代开发。。。。。。
这些技术早在几十年前就被提出并采用了，敏捷的贡献何在？敏捷的主要创新在于“社会工程”
敏捷的主要贡献在于它更多的思考了【如何去激发开发人员的工作热情】，这是在软件工程几十年的发展过程中相对被忽略的领域。【坦诚合作】起始才是敏捷的精髓。
敏捷提倡回归理性，【破除两个迷信】。『软件开发可以成为生产线：每个岗位的职责可以被明确定义，各个岗位之间接口同样可以被明确定义，大家只要各司其职，高质量的软件就可以被生产出来』『软件开发过程可以像建筑一样被准确的预测和计划』
敏捷是“第三颗银弹”：软件工程领域专家们始终在努力不懈的寻找银弹：第一颗：面向对象。第二颗：CMM/CMMI。第三颗：敏捷（Agile）。
如何使自己敏捷？—12 条原则 1.最优先的目标是通过尽早的，持续的交付有价值的软件来满足客户。2.即使在开发后期也欢迎需求变化。敏捷过程利用变更帮助客户取得竞争优势 3.频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度。 4.在整个项目中业务人员和开发人员必须每天在一起工作 5.以积极主动的员工为核心建立项目，给予他们所需的环境和支持，信任他们能够完成工作。6.在开发团队内外传递信息最有效率和效果的方法是面对面的交流。 7.可用的软件是进展的主要度量指标。 8.敏捷过程提倡可持续的开发速度。发起人，开发者和用户应始终保持稳定的步调。9.持续关注优秀的技术和良好的设计能增强敏捷能力。10.简化—使必要的工作最小化的艺术—是关键。11.最好的架构，需求和设计产生于自我组织的团队。12.团队定期的对如何更加有效工作进行反思，并相应的调整，校正自己的行为。
敏捷与社会属性有关：作为一个社会工程，它的许多建议适合欧美的世纪情况有关，对目前的中国
并不完全适合。良好的替代执业发展道路（较容易达到敏捷对“自组织团队”的要求）。完善社会福利体系。相对扁平的薪酬体系。。。
敏捷的实现要点：允许项目团队调整并安排任务、理解敏捷开发方法的易变性并制定计划、精简并维持最基本的工作产品、强调增量交付策略、快速提供适应产品类型和运行环境的可运行软件
4.2 敏捷过程
敏捷过程强调的三个关键假设：1.难以预测需求（代码运行前难以预测哪些需求是稳定的，哪些会发生变化？）2. 难以预测设计（构建验证前部指导究竟有多少设计？哪些是必要的？）3.难以预测计划（计划时难以预测后面的工作）
如何解决以上问题：建立具有自适应性的过程，自适应地调整以应对变化。
敏捷过程与传统软件工程过程之争【敏捷阵营】传统方法学家陷入了误区，乐于生产完美的文档而不是满足业务需要的可运行系统。【传统软件工程阵营】敏捷方法学家是一小撮自以为乐不起的黑客，他们妄图将其手中的玩具软件放大到企业级软件而制造出一系列轰动。
问题：
什么是最佳实现途径？如何构建满足用户当前需要的软件，同时展示具有能满足客户长期需求的扩
展能力？兼顾两派的优点则双方都能得到很多好处，而相互诽谤则而这都将一无所获。
敏捷过程中“人的因素”：敏捷开发关注个人的才智和技巧，根据特定人员和团队来塑造过程。敏捷过程是可以满足人员及团队需求的过程模型。敏捷开发是以人为核心的，是迭代的，是循序渐进的。
有效的敏捷团队，其成员应具备的特点：基本能力、共同目标、精诚合作、决策能力、模糊问题解决能力、相互信任和尊重、自我组织
4.3 敏捷过程模型
所有敏捷过程模型都遵循敏捷软件【开发宣言和敏捷原则】，每种模型又各有特点：
『极限编程（XP） 8%』『SCRUM 49%』『自适应软件开发 22%』『动态系统开发方法（DSDM）、Crystal、特征驱动开发（FDD）、敏捷建模。。。21%』
4.3.1 XP
XP（极限编程，eXtreme Programming) 由 KentBeck 在 1996 年提出，是一个轻量级的，灵巧的软件开发方法，使用面向对象方法作为推荐的开发范型。【适用于 10 人一下项目组，开发地点集中的场合。广泛用于需求模糊和挥发性强的场合。】
XP 的基本观点：软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出人在软件开发过程中的作用。
XP 核心价值观：【沟通】问题往往是由于开发人员与设计人员，设计人员与客户之间的沟通不畅造成的。【简单】在系统可运行的前提下，做最简单的工作。时刻保持代码的简单，无冗余。【反馈】尽快获得用户反馈，越详细越好，使得开发人员能够保证自己的成果符合用户的需要。【勇气】“拥抱变化”对于用户的反馈，要用于对自己的代码进行修改，丢掉坏的代码。
XP 适用范围：XP 适合规模小，进度紧，需求变化大，质量要求严的项目』功能需求可以固定的，可以作比较精确的需求设计的，生命周期很长的，【超大型软件项目不适于适用 XP 方法】』XP 是一种高度动态的过程，它通过非常短的迭代周期来应付需求的变化』XP 体现开发团队的人员价值，激发参与者的情绪，最大限度地调动开发者的积极性，提高开发的软件质量』
XP 过程框架,XP 包含 4 个框架活动：策划\设计\编码\测试
What is a User Story? 用户故事描述的是用户渴望的功能和特性。谁想要它？这个功能如何被使用？这个功能为何被使用？
用户故事的基本成分：卡片：故事的描述，为谁服务，唯一标识，提示信息，对迭代计划编制有所
帮助。讨论：故事的具体内容，和用户一起进行面对面的沟通，记录笔记，模型，文档交流。确认：确立验收测试的标准。
用户故事的 INVEST 模式：Independent：用户故事间应该是（尽可能）独立的。Negotiable：用户故事是便于沟通的。Valuable：每个用户故事必须对客户具有价值。Estimable：开发者需要去估计用户故事以便确定优先级并对故事进行规划。Small：好的故事工作量应该不超过 2-3 人周，描述具有代表性。Testable：用户故事应该是可测试的，用于确认完成。
Summary：一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立，详情应该便于开发者和用户进行沟通，应该对用户有价值，应该对于开发者来说尽可能的清晰以便进行估计，应该短小，通过预定义的测试用例是可以对其进行测试的。
【策划】：建立用户故事==>确定故事权值（优先级）==>确定故事成本（开发周数）==>确定一下个发布版本，排序待开发故事。==>尝试能够解决当前问题的体系结构。第一个发行版本发布之后，XP 团队将计算项目的速度。项目速度用来帮助团队建立后续发行版本的发布日期和进度安排，同时判断整个项目是否存在过分承诺。
【设计】：严格遵循 KIS 原则 （keep it simple)==>提供故事的实现原则（不多也不少，不做额外功能性设计）==>组织和当前增量相关的对象和类，CRC 建模（类名，类的职责，类的协作关系）CRC 卡片==>对设计困难的故事提出 Spike Solution==>XP 鼓励构建重构和设计重构。设计和编码同时发生。设计随着系统的构建连续进行，构建又为设计提供指导。（设计阶段的工作产品就是 CRC 卡和 Spike Solution）
【编码】：测试驱动开发（TDD) 代码未动，测试先行 XUnit JUnit NUnit CPPUnit、结对编程 两个人一起组队、持续集成、每日集成
【测试】：建立通用测试集，每日集成、使用测试自动实施框架，支持即时回归测试 （黄金测试集）、XP 验收测测试
XP 的 12 个优秀实践：现场客户 计划博弈 测试驱动 小型发布 系统隐喻 代码重构 简单设计 持续集成 结对编程 集体拥有代码 每周 40 小时工作制 代码规范
【现场客户】：随时能联系到客户是 XP 方法的基本要求之一、所有阶段要求客户强参与、编写需求、Release 反馈、参与测试
【计划博弈】（Planning Game)：划分迭代周期 要求结合项目进展和技术情况，确定下一阶段要开发与发布的系统范围 技术人员作出具体的成本和科技估计 客户根据成本和商务价值来选择要实现的特性
【系统隐喻】（System Metaphor)：通过一个简单的关于整个系统如何运作的隐喻性描述(story)指导全部开发、隐喻可以看做是一个高层次的系统构想，通常包含了一席可以参照和比较的
类和设计模式、XP 不需要实现进行详细的架构设计。
【简单设计（Simple Design)】：XP 认为需求是会经常变化的，因此设计不能一蹴而就，应该是一项持续进行的过程。简单设计应满足以下原则： 向开发人员清晰描述编码及其内在关系、尽可能包含最少的类和方法、不包含重复的代码、成功执行所有测试
【结对编程(Pair Programming)】：两个程序员，同一套设备，一起工作 一个驾驶，一个导航
角色 WHY？可以提高质量 Who not suitable do? Xper’s Quality? HOW TO
【一】企业管理层次：Pares 更有效的交流，相互学习和传递经验、Pair Programming 能更好的处理人员流动。
开发层次： Pairs 能提供更你好的设计质量和代码质量、 Pairs 更强的问题解决能能力
开发人员自身： Pairs 一起工作能带来更多的信心、Pairs 一起工作能带来更高的满足感
【二】提供不间断的 Design review ,Unit Test Review,Code Review,Document Review 提高代码质量。互相督促可以提高代码的可读性和可维护性、培养 Teamwork 精神，避免个人英雄主义、频繁的交流，增进知识经验的交流。
【三】角色呼唤可以让程序员轮流工作，从而避免出现过度思考而导致观察力和判断力出现偏差。同伴的潜在压力，使得程序员更认真的工作。每个人每天的有效工作时段不超过 3-4 个小时。潜意识的有利竞争。当人在一个团队中工作，总是下意识的努力展现自己的优点。工作及时得到同伴的肯定，自信心和成就感增强。觉得工作是一件愉快的事情。
【四】不适合的人：太过自负、不能容忍别人的一件、我总是对的、我吃盐多过你吃米、太过自卑
没主见、没责任心
【五】XPer 应该具备的基本素质： 诚实，公正，开明，勇敢，谦卑 在这些素质的基础之上，才是对技术水平，能力和天分等的要求。
HOW TO 结对编程：『Driver』1. 写设计文档（class diagram 等）2.编码（unit test and business object) 『Navigator』1.审阅 Driver 的文档 2. 审阅代码 3. 考虑 Unit Test 的覆盖程度 4. 是否需要和如何 Refactoring 5. 帮助 Driver 解决具体的技术问题『不断轮换角色，每小时休息 15 分钟』『主动参与』
【集体拥有代码】：开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责。这并不意味着开发人员可以互相推诿责任，而是强调所有的人都要负责。如果一个开发人员的代码有错误，另外一个开发人员也可以进行 BUG 的修复。
【测试驱动】先测试，在编码，代码未动，测试先行。『Unit Test （正常性和异常性）』『Acceptance Test(Functional Test)』『Regression Test （重用已经建立的所有的测试单元）』『Nightly Test』『 Stress Test』所有的测试都应该独立的自动的运行
【小型发布】在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；同时，也可以及时处理用户的反馈。
【代码重构（Refactoring）】强调代码重构的作用，认为应该经常进行重构。任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员—Martin Fowler。代码重构是指在不改变系统行为的前提下，重新调整，优化系统的内部结构以减少复杂性，消除冗余，增加灵活性和提高性能。
【Why Refacing？】是对软件内部结构的一种调整，目的是在不改变外部行为的前提下，提高其
可理解性，降低其修改成本。作用：改进软件设计、提高代码质量，使其更易被理解、提高开发速度。【When Refactoring？】1 添加新功能时 2 修补错误时 3 Code Review 时。通常有两个关键点应该进行重构；一个功能实现前和实现后。【When No Refactoring？】1 代码太混乱，设计完全错误 2 明天是 DeadLine 3 Refactoring 的工作量影响最后的期限 【Refactoring Vs Add New Feature】Add New Feature：不应该修改既有代码，只管添加新功能。Refactoring：不能再添加功能，只管改进程序结构。此外你不该添加任何测试（除非发现有先前遗漏的东西）【Refactoring Vs Design】设计难以贯穿软件开发全过程 需求改变–>设计变更，How About our Codes？用重构去辅助设计！！【Refactoring Vs Performance】重构常常会使软件运行更慢，但它也使软件的性能优化更易进行。当你拥有了重构的经验，你也就有能力在重构的基础上来改进程序的性能。【How to Refactoring ？】《重构—改善既有代码的设计》[美]Martin 人民邮电出版社1 重新组织你的函数 2 在对象之间搬移特性 3 重新组织数据 4 简化条件表达式 5 简化函数调用 6处理概括关系
【持续集成】提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试。因为，这样可以使得团队保持一个较高的开发速度，同时避免了一次系统集成的恶梦。
【每周 40 小时工作制】要求项目团队人员每周工作时间不能超过 40 小时，加班不得连续超过两周，否则反而会影响生产率。不加班，不熬夜。
【代码规范】强调通过制定严格的代码规范来警醒沟通，尽可能减少不必要的文档。没有一个统计的编码规范会造成团队的每一个成员无法迅速的掌握其它开发人员写出的代码，影响团队整体的协作性。
4.3.2 Scrum
Scrum（Jeff Sutherland 1993 年提出）是较为领先的敏捷开发方法之一，目前世界上有超过 500 家公司在使用。密切协作、高度自主 『Scrum：抛球、开始并列争球』 Scrum 是一个轻量级的敏捷开发框架，是一个增量的，迭代的开发过程。其核心准则就是自我管理和迭代开发。 自我管理：管理者不再发号施令，由团队自己寻找最佳的工作方式完成任务 迭代开发：项目由若干个开发周期构成，每个周期均提交一个系统的增量版本。
Scrum 目标：Manage Complexity,Unpredictability and Change through Visibility,Inspection and Adaptation 通过高透明性，检验和适应性来管理复杂性，不可预测性和变化。
SCRUM 的核心价值观】承诺：只有做和不做，没有试，发自内心的接受和应允。专注：把精力全部集中在承诺的事务上。公开：透明、任何有兴趣的人都可以了解项目当前状况。尊重：每个团队成员都必须被尊重的看待。勇气：为负责任的交付产品，有足够的勇气来说”不“。
SCRUM 框架
SCRUM 的运作原理】哲学基础：授权于开发团队，满足客户需求。管理文化：帮助他人完成目标。技术工具：通过学习过程作出基于适时的决策。沟通和反馈是一切的基础，【即时的反馈】是拥抱变化的前提条件。
Scrum 的产品 Backlog】产品 Backlog 是按照商业价值排序的需求列表。列表条目的体现形式通常为用户故事。产品呢负责人负责产品 Backlog 的内容，可用性和优先级排序。产品 Backlog 的内容和排序都是动态的。
产品BACKLOG示例：
| ID | NAME | Imp | Est | How to demo | Notes |
|---|---|---|---|---|---|
| 1 | 存款 | 30 | 5 | 登录，打开存款界面，存入10欧元，转到我的账户余额界面，检查我的余额增加了10欧元。 | 需要UML顺序图。目前不需要考虑加密的问题。 |
| 2 | 查看自己的交易明细 | 10 | 8 | 登录，点击“交易”，存入一笔款项。返回交易页面，看到新的存款显示在页面上。 | 使用分页技术避免大规模的数据库查询。和查看用户列表的设计相似。 |
SCRUM 的 Sprint】1. Sprint 的长度通常为 2-4 周，一旦确定不允许延长或缩短。2.每个 Sprint 中，团队从产品 Backlog 中挑选最有价值的需求进行开发，一个 Sprint 周期内需求不发生变更。3. 团队构成和质量目标在 Sprint 中均保持不变 4.在每个迭代结束时，Scrum 团队将交付潜在可交付的产品增量。5. Sprint 之间没有时间间隔。
三个角色，五个仪式，四个工件（SCRUM 框架图）【Scrum 的三个角色】产品负责人（Product Owner） ¾ 确定产品功能，负责提出和维护产品 Backlog ¾ 决定产品的发布日期和发布内容 ¾ 为产品的投资回报率（ROI）负责 ¾ 根据市场价值确定功能优先级 ¾ 在每个 Sprint 开始前调整功能和调整功能优先级 ¾ 在 Sprint 结束时接受或拒绝接受开发团队的工作成果。Scrum Master ¾ 保证团队资源完全可被利用并且全部是高产出的 ¾ 保证各个角色及职责的良好协作 ¾ 解决团队开发中的障碍 ¾ 作为团队和外部的接口，屏蔽外界对团队成员的干扰 ¾ 保证开发过程按计划进行，组织会议 ¾ 记录每天完成的工作量，更新燃尽图。Scrum 团队 SCRUM 团队负责在每个 Spring 中将产品 Backlog 中的条目转化成为潜在可交付的功能增量。¾ Scrum 团队的规模控制在 5-9 个人 ¾ Scrum 团队是跨职能的团队 ¾ Scrum 团队是自组织的。【Scrum 的五个仪式】发布计划会议 ¾ 确立项目整体发布目标和预期结果。¾ 确定具有最高优先级的产品 Backlog 条目，重大风险和发布所包含的全部特性和功能 ¾ 确立大致交付日期和费用，以每个 Sprint 为基础调整发布计划 ¾ 产品负责人确定产品 Backlog 的优先级排列 ¾ 团队成员为产品 backlog 条目做工作量估算 ¾ 使用计划指派进行工作量估算。¾ 工作量估算的单位为“故事点”。¾ 一个故事点相当于理想的 1 个人天的工作量。Sprint 计划会议（8 小时以内） ¾ 把既定产品 Backlog，Sprint 时间表，Sprint 评审会议的结果，Sprint 回顾会议的结果公开给所有人 ¾ 产品负责人向团队阐述产品愿景，介绍最高优先级的产品 Backlog 条目 ¾ 团队选择产品 Backlog 条目，确定 Sprint 目标。『利用“昨日天气”计算“投入程度”（focus factor)，(focus factor)=(actual velocity)/(available man-days)』『利用投入程度计算本次 Sprint 中可以完成的“故事点” (available man-days)*(focus factor)=(estimated velocity)』 ¾ 团队成员将 Backlog 分解为多个 1 天以内可以完成的任务，考虑所有工作细节，调整目标 ¾ 任务列表构成 Sprint Backlog。每日站会（15 分钟）团队成员间工作进度的沟通和协调。¾ 维护 Sprint Backlog 上的所有任务（增删改，重新排序） ¾ 确认任务状态（“待处理”，“正在处理”，“已完成”）¾ 每人回答三个问题：昨天做了什么、今天打算做什么、有什么问题或依赖吗。不仅仅是汇报进度，更重要的是 Scrum 成员互相的承诺，不是系统设计讨论会。团队由此得知整个项目进展的时间表，会议中提到的问题应会后解决。Scrum Master 指导团队执行规则来控制会议时间，并保证团队成员进行简短有效的汇报，焦点集中于每个人的三个问题，但是，不允许 Scrum Master 在会议上发言或以各种方式干扰会议。Product Owner 在回忆上旁听，主要兴趣在于项目进展和困难。“任务板”。Sprint 评审会议（4 小时） 根据本 Sprint 所发布的版本，评审相关 Backlog 中的条目，检查是否已达到Sprint 的目标。 ¾ 团队按 Sprint Backlog 中的条目，逐个的介绍结果，演示新功能。¾ 如果产品负责人想改变或对功能有新的想法，则添加新条目到产品Backlog 中 ¾ 如果小组报告项目遇到问题现在还没能解决则把该问题加入到障碍 Backlog。¾ 会议结果：对这次 Sprint 的结果和整个产品的开发状态的共识。Sprint 回顾会议（3 小时）通过总结以往的时间经验来提高团队生产力 ¾ 回顾会议以头脑风暴的方式 Review Sprint 过程和结果，发现和列举存在的问题 ¾ 与会人员投票决定需要在下个 Sprint 中解决的 1-3 个问题，探讨解决方案，确定时间方式。本次 Sprint 中最为重要的是什么？成功经验是什么？有什么地方能够改进的？
团队的定期自我审视。（优点、缺点、挑战）审视和适应的能力是 scrum 的基础。对于挑战，提出 Action。制定相应的负责人，负责执行 Action。【Scrum 的四个工作】产品 Backlog。Sprint BackLlog。发布燃尽图。Sprint 燃尽图。产品 Backlog需求列表。项目中所有希望进行的工作的列表。理想的表达出每一项都对项目的用户或客户有价值。由产品负责人安排优先级。在每个sprint 开始的时候重新排定优先级。Sprint Backlog Sprint Backlog 涵盖了最终版本的既定 Product Backlog 的任务，团队通过它来协调开发进度。每个人标记自己选择的工作，工作不是分派的，而是自己选择的。每天更新剩余的估计工作量。任何团队成员可以增加、删除、改变 Sprint Backlog。如果工作不清晰，定义一个用时更多的 Sprint Backlog 条目，以后再分解。当状况变得更明了时，更新剩余工作量。Sprint 燃尽图 燃尽图（BURN DOWN CHART)是在工作完成之前，对需要完成的工作的一种可视化表示。发布燃尽图 ¾ 前期：产品负责人整理业务需求，形成 Product Backlog 库 ¾ 执行：以 Sprint 为单位迭代式的完成 Sprint Backlog，每个 Sprint 以 Sprint Planning 开始，通过每日例会跟踪进度和 issue，Spirnt 结束时进行评审，交付可运行的产品。¾ 后期：每个 Sprint 完成后，通过 Sprint 回顾发现问题和改进点。 制定下个 Sprint 要引入的新的实践。
【Sprint≠小型瀑布】与瀑布模型相比，Sprint 具有以下特点：持续的设计、开发、集成和测试，跨职能的团队成员，Sprint 期间不允许变更，时间盒，严格定义的开发节奏。
Scrum 特点】：Scrum 规定了一个非常简单的开发流程，是现有设计流程的总结。Scrum 以团队为基础，是一种在需求迅速变化情况下迭代的，增量的开发系统和产品的方法。Scrum 是一个控制由利益和需求冲突导致的混乱的流程。Scrum 是改善交流并最优化合作的方式。Scrum 是一种检测产品开发和生产过程中障碍并将其取出的方式。Scrum 是最大化生产率的一种方法。
Scrum 适用范围】Scrum 适用于打印的项目到整个企业，可以以控制并组织多个具有相关性的产品开发，拥有超过千名开发者和执行者的项目实施过程。Scrum 能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。
Scrum VS XP】XP 与 Scrum 是敏捷方法中被业界采用最为广泛的郎中实践。Scrum 注重的是管理和组织实践，而 XP 关注的是实际的编程实践，两者都聚焦于信息价值流和信息沟通除了迭代长度稍有差别外，大多数Scrum 实践与 XP 是兼容且相互补充。【组合使用 Scurm 和 XP 会有显著收获！】结对编程，测试驱动开发，持续集成等 XP 的最佳实践仍然可以在 Scrum 中使用。
4.3.3 自适应软件开发
自适应软件开发（Adaptive Software Development， ASD）由 James Highsmith提出。ASD 构建复杂软件和系统的一项技术，着眼于人员协作和团队自我组织。包含 3 个框架活动：思考、协作、学习。【思考】：启动项目，完成自适应循环策划。任务描述、项目约束、基本需求、确定项目的增量发布循环计划。【协作】：受激励的人员以超越其聪明才智和独创的方式共同工作，获取需求。毫无恶意地作出评论、毫无怨言地相互帮助、尽最大努力工作、拥有解决手头工作的技能、以能导致有效行动的方式沟通问题和事务。【学习】：开始构建本循环的构件，重点在于为完成项目学习尽可能多的东西。焦点组，接受反馈信息，判断产品是否满足业务需求，正式技术评审，团队评审以提高质量学习知识。事后剖析，自我反省，着眼于自身的表现和过程。强调团队自我组织的动态性、人与人的协作、个人以及团队的学习，提高团队成功的可能性。
4.3.4 动态系统开发方法
动态系统开发方法（Dynamic System Development Method， DSDM）通过在可控项目环境中使用增量原型开发模式完全满足对时间有约束的系统的构建和维护。依据：Pareto80-20 法则，如果交付整个应用系统需用 100%时间，那么 80%的应用系统可以用 20%的时间交付。DSDM 使用迭代软件过程，每一个迭代都遵循 80-20 原则，即每个增量只完成能够保证顺利进入下一个增量的工作，剩余的细节则可以在知道更多业务需求或者提出并同意变更之后完成。
DSDM 生命周期：可行性研究、业务研究、功能模型迭代、设计和构建迭代、实现。【可行性研究】建立业务需求和相关约束，并评估采用 DSDM 过程是否可行。【业务研究】建立功能和信息需求：同时，确定基本架构并识别软件的可维护性需求。【功能性迭代】开发一系列增量原型，用户使用原型系统时诱导出反馈信息以获取其他的需求。【设计和构建迭代】在功能模型迭代中，，重新构建原型以确保每一个原型都以工程化方式实现，并能为最终用户提供可操作的业务价值。功能模型迭代、设计和构建迭代可同步进行。【实现】将最终软件增量（可操作的原型）置于操作环境中。『DSDM 开发转向功能模型迭代后继续进行：增量没有 100%完成。增量置于操作环境以后可能需要改变。』DSDM 可以跟 XP 结合使用，以完善构建软件增量的具体实践。
4.4 小结
（1）敏捷开发是一种以人为核心、迭代、循序渐进的开发方法 【敏捷过程强调适应性而非预见性】【敏捷开发方法“面向人”而非“面向过程”】（2）敏捷过程模型有利于解决惯性过程模型中的问题：¾ 版本发布的时间越来越长 ¾ 无法按时发布 ¾ 发布最后阶段让软件稳定的时间越来越长 ¾ 制定计划时间长，不准确 ¾ 发布期间难以进行变更 ¾ 质量持续恶化 ¾ 稳定化阶段拼命加班挫伤士气。（3）敏捷开发的误区 z 误解一：敏捷对人的要求很高 z 误解二：敏捷没有文档，也不做设计 z 误解三:敏捷好，其他方法不好 z 误解四：敏捷就是 XP，就是 Scrum z 误解五：敏捷很好，要制定标准，所有项目都要遵循这个标准。
CMM VS Agile
组织关注焦点 设计假设
管理 学习
信任 愿景
计划 人力资源
市场和用户假设 失败成本
经典软件项目管理—PMI五大过程组，九大知识领域，44 个管理过程，PMI 的关心和焦点 $\times$ 计划驱动 $\times$ 紧密控制
$\times$ 面向业务进行管理 经典软件项目管理的局限我们需要具有经验，我们需要一个完整、详尽的计划，我们需要设计考虑所有的风险和预留的内容。经典软件项目管理应加强的内容科学的资源管理和控制，弹性的项目管理方式，软件项目管理是软件工程的保护性活动，它先于任何技术活动之前开始，并且持续贯穿于整个计算机软件的定义、开发和维护之中。
第五章 软件项目管理综述
5.1 管理涉及的范围
z 软件项目管理设计对人员，过程和在软件从初始的概念演化为可运行的实现的过程中发生的事件的计划和监控。z 有效软件项目管理，具体管什么？
5.2 人员
人是成功的软件项目的最重要的因素。项目设计的五类人员: 高级管理者。项目（技术)管理者。开发人员。客户。最终用户。
5.2.1 团队负责人
应具有的领导能力（MOI 模型）$\times$ 激励（Motivate)$\times$ 组织（Organization）$\times$ 创新（Innovation） 应具有的关键品质$\times$ 解决问题$\times$ 领导者的特性$\times$ 影响力$\times$ 有效决策。需要管理人员的技能，优秀的技术者未必能胜任。
5.2.2 软件团队
选择团队结构应考虑的因素$\times$ 待解决问题的难度$\times$ 开发程序的规模$\times$ 团队生存期$\times$ 对问题进行模块化划分的程度$\times$ 系统质量要求和可靠性要求$\times$ 交付日期严格程度$\times$ 项目需要的友好交流的程度
优秀软件团队应具有的特点$\times$ 有明确的共同的目标$\times$ 团队成员必须相互信任$\times$ 团队成员的技能分部适合于要解决的问题$\times$ 保持凝聚力
软件团队应注意的问题【团队毒性】$\times$ 狂乱的工作氛围$\times$ 引起成员间产生摩擦的重大挫折$\times$ 项目人力资源管$\times$ 碎片式的或协调很差的软件过程$\times$ 角色定义不清晰$\times$ 连续不断的重蹈覆辙$\times$ 团队成员个性
【软件团队的四种组织范型（constantine)】
| 名称 | 特点 | 优势 | 不足 |
|---|---|---|---|
| 封闭式范型 | 传统的权力层次组织（金字塔） | 开发与过去已经做过的产品类似的软件时十分有效 | 难以创新 |
| 随机式分型 | 松散的组织小组，并依赖于小组成员个人的主动性 | 创新能力强 | 缺乏次序 |
| 开放式 | 结合封闭式范型和随机式范型的方式来组织，工作的执行结合了大量的通信和基于小 | ||
| 组一致意见的决策 | 适于解决复杂问题 | 效率不高 | |
| 同步式范型 | 依赖于问题的自然划分，组织范型小组成员各自解决问题的片段他们之间没有主动的通信需要 | – | – |
5.2.3 敏捷团队
敏捷团队是小型的充满活力的团队，通过尽早地逐步交付软件来使客户满意。$\times$ 强调团队成员的个人能力与团队协作精神相结合$\times$ 自组织团队$\times$ 具有较大自主权（项目管理、技术手段、软件过程等）
5.3 产品
确定并准确描述产品的目标和范围$\times$ 目标：从客户角度描述的产品的总体目标，不考虑实现方法$\times$ 范围：量化地描述产品功能、特征、主要数据。考虑可选的解决方案，识别技术和管理上的限制$\times$ 约束条件$\times$ 前提条件
5.3.1 软件范围
软件项目管理的第一项活动是确定软件范围$\times$ 项目环境：产品，业务环境？软硬件环境？$\times$ 信息目标：输入？输出？$\times$ 功能和性能。无歧异，可理解，量化的软件范围描述是关键。
5.3.2 问题分解
问题分解是软件需求分析的核心活动，是成本估算和进度安排的基础。问题分解的 2 个主要方面$\times$ 必须交付的功能$\times$ 所使用的过程。问题分解的 2 个阶段：$\times$ 确定范围时分解$\times$ 制定进度计划时分解。
5.4 过程
选择一个适合待开发软件的软件过程$\times$ 是否适合需要该产品的客户和从事开发工作的人员？$\times$ 是否适合产品本身的特性？$\times$ 是否适合项目团队工作的项目环境？基于软件过程的框架活动制定初步项目计划过程分解制定完整项目计划反映工作任务。
5.4.1 合并产品和过程
项目计划开始于产品和过程的合并 $\times$ 每一项功能都必须通过组织所选定软件过程中定义的一系列框架活动来完成 $\times$ 完成任何一项功能的项目团队成员都要将各个框架活动应用于该功能的实现上。
5.4.2 过程分解
根据所选过程模型对过程框架做适应性修改。根据项目需要确定框架活动中包含的工作任务。（同一个框架活动所包含的实际工作任务是不同的）
5.5 项目
软件项目处于危险状态的 10 个信号：软件人员不了解客户的要求。产品范围定义得很糟糕缺乏具有核实技能的人员。选择的技术发生了变化。管理者的没有使用最佳实践和教训。客户抵制。失去赞助。最后期限不切实际。业务需求发生了变化。没有很好地管理变更。
避免软件项目发生危险的五点优秀实践：1.在正确的基础上开始工作，正确理解要解决的问题，设置现实的目标和期望。2.保持动力，激励，强调质量，不教条，不干涉，3.跟踪进展，跟踪工作产品的生产和评审，收集数据评估进展情况 4.作出聪明的决定 保持项目的简单性，把更多时间用于完成复杂或有风险的任务。5.进行事后分析 总结经验，收集分析数据，获取反馈，记录发现。
5.6 5W2H 原则
5W2H 原则是制定软件项目开发计划的一种方法，通过一系列提问，来导出对关键项目特性和项目计划的定义。
| 项目计划 | — | 提问 |
|---|---|---|
| 项目目标 | why | 为什么要开发这个系统？这个系统的商业目的值得花费人员，时间和金钱吗？ |
| 项目任务 | what | 将要做什么？ |
| 里程碑和进度 | when | 什么时候做？ |
| 职责 | who | 某功能由谁负责？ |
| 角色 | where | 他们的机构组织位于何处？ |
| 管理及技术策略 | how | 如何完成技术工作和管理工作？ |
| 需要的资源 | how much | 每种资源需要多少？ |
5.7 项目管理关键实践
基于性能管理的关键软件实践被高度成功的软件项目和组织使用和认可。$\times$ 基于度量的项目管理
$\times$ 经验成本和进度估计$\times$ 获得价值跟踪$\times$ 正式的风险管理$\times$ 根据质量目标跟踪缺陷$\times$ 人员计划管理$\times$ 敏捷项目管理
第六章 过程和项目度量
当你能够测度你所说的,并将其用数字表达出来,你就对它有了一些了解;但当你不能测度,不能用数字表达它时,你对它的了解就很贫乏,很不令人满意;它可能是知识的开始,但你在思想上还远没有进入科学的阶段.
度量的定义：度量关注的是在一定的规则下获取关于实体属性的信息。实体：指一个实物或者一个事件。属性：指我们所关注的实体的特征或特性。
为什么要度量？刻划：认知和理解项目过程，产品，资源和环境，建立比较基线。评估：跟踪项目状态，管理进展即使发现偏差，评估质量目标达成情况以及改进的影响。预测：是建立计划的基础。根据度量的实证，预测发展趋势，评估风险，作出权衡。改进：识别问题根源，判断可以改进的机会，交流改进的目标和理由，调整资源非配。问题：如何量化的管理软件开发？量化的管理过程和项目？针对具体的开发组织，如何设定度量方法和量化目标？量化管理时应注意哪些问题？
6.1 过程领域和项目领域的度量
过程度量指对过程能力指标的合理量化，测量组织级别上软件开发过程的质量，成本、盈利、投资回报率和生产率。过程度量涉及所有项目，历时长，旨在提供能够引导长期软件过程改造的一组过程指标。
6.1.1 过程度量和软件过程改进
【基于过程结果的过程度量 （评价过程的效率）】产品交付前发现的错误数。产品交付后最终用户报告的缺陷数。交付的工作产品。花费的工作量。花费的时间。与进度计划是否一致。【过程度量数据的类型】『个人过程数据，个人私有，是个人改进其工作的驱动力』个人缺陷率。模块缺陷率。开发中发现的错误率。『团队过程数据，团队私有，帮助改善团队性能』主要软件功能缺陷数。正式技术复审中发现的错误数。每个模块和功能代码的成功指数。『公用过程数据，组织级，帮助改善组织过程性能』项目级缺陷率，工作量，时间等。【软件度量规则（Grady）】解释度量数据时使用常识，考虑组织的敏感性。向收集测量和度量的个人及团队定期提供反馈。不要使用度量去评价个人。与开发者和团队一起设定清晰的目标及达到这些目标的度量。不要用度量去威胁个人或团队。指出问题区域的度量数据不应该消极的看待，这些数据仅仅是过程改进的指标。不要在某一个别的度量上纠结而无暇顾及其他的重要度量。【过程度量的目的是软件过程改进】【如何进行过程改进？】测量过程的特定属性。基于上述属性开发一组有意义的度量。使用上述度量提供的指标导出过程改进策略。【统计软件过程改进（SSPI）】使用软件故障分析法，来收集应用软件，系统或产品的开发及使用中所遇到的所有错误及缺陷的信息。问题的分类统计及排序—>记录每个问题的修改成本—>计算每一类问题的总成本—>分析结果数据，找出最高成本的问题类型（5why 法）—>产生过程改进计划，消除最高成本错误类型。
6.1.2 项目度量
【项目度量】：指对具体项目指标的合理量化，测量数目级别上软件开发过程的质量、成本、盈利、投资回报率和生产率。【项目度量数据在项目期间使用】评估项目状态、跟踪潜在风险、及早发现问题、调整流程和任务、评估质量控制能力 【项目度量是过程度量的一部分】【项目度量的主要内容:
| 阶段 | 依据 | 度量内容 | 度量目的 |
|---|---|---|---|
| 计划 | 项目任务过去的项目数据 | 工作量时间 | 估算，制定计划 |
| 实施维护 | 实际进展 | 投入的人工量，花费的时间，完成的工作量，（功能点数、代码行数），发生的错误数/缺陷数，生产率 | 1、与计划对比。评估进展状况，控制项目实施。2、跟踪项目的实施情况 |
项目管理者和软件项目组使用项目度量及从其中到处的指标，可以改进项目工作流程和技术活动。
【项目度量的目的】：$\times$ 指导进行一些必要的调整以避免延迟，并减少潜在问题及风险，从而使
得开发时间减到最小。$\times$ 在项目进行的基础上评估产品质量，并且可在必要时修改技术方法以改
进质量，降低整个项目的成本。
6.2 项目测量
项目测量的 2 类方法：$\times$ 直接测量：测量软件过程中花费的成本、工作量测量产品的代码行数、运行速度、缺陷数$\times$ 间接测量：测量产品的功能、质量测量产品的复杂性、有效性、可靠性、可维护性
任何产生能够在组织范围内不同项目间进行比较的软件度量呢？
6.2.1 面向规模的度量
面向规模的软件度量是基于已经开发的软件规模通过规范化质量或生产率测量而得到的。【面向规模的度量：】每千行代码（KLOC）的错误数，千行代码（KLOC）的缺陷数，每千行代码（KLOC）的文档页数，每千行代码（KLOC）的成本，每人月错误数，每人月代码行（LOC），每页文档的成本。
【采用 LOC 的注意点】要采用相同的计数方法、不同编码语言的生产率和缺陷率是不同的、不同应用领域、不同复杂度的代码的生产率是不同的、聪明快速的方法可导致代码减少、要考虑代码服用的因素、不要过分强调 LOC 单个因素的度量，忽略了质量等因素。“使用代码行作为关键测量”是否合适的争议：【支持者】：LOC 是所有软件项目的“生成晶”，容易计算；许多现有的软件估算模型使用 LOC 或 KLOC 作为关键输入；有大量的文献和数据涉及到 LOC，应用广泛；【反对者】：LOC 测量依赖于程序设计语言；对设计的很好但较小的程序会产生不利的评判；不适用于非过程语言；
6.2.2 面向功能的度量
面向功能的软件度量使用软件所提供的功能的测量数据作为规范化值。
目前应用最广泛的功能测量数据是功能点，它时根据软件信息域的特性及复杂性计算的。
功能点的计算方法：①内部逻辑文件②外部接口文件③外部输入④外部输出⑤外部查询
估算流程：1、 决定功能点计算的信息域2、确定计算范围和应用程序边界3、确定所有数据功能及其复杂性4、确定所有事务功能及其复杂性5、得出未调整功能点计数6、得出基于 14 项基本特征的值调整因子7、计算已调整功能点计数
面向功能的度量测量: 使用功能点以规范软件生产率、质量及其它属性的测量。
面向功能的度量：每个功能点（FP）的错误数。每个功能点（FP）的缺陷数。每个功能点（FP）的文档页数。每个功能点（FP）的成本。每人月完成的功能点（FP）数。“使用功能点作为关键测量”是否合适的争议。『支持者』：FP 与程序设计语言无关，对于使用传统语言和非过程语言的应用系统比较理想。FP 所依据的数据是在开发初期就可以得到的。作为一种估算方法，FP 更具有吸引力。『反对者』：FP 估算法计算的依据是主观的而非可观的数据，实施需要某种“熟练手法”；信息域的计算难以在事后收集；FP 没有直接的物理意义，仅仅是一个数字而已。
6.2.3 调和代码行和功能点的度量方法
结合 FP 与 LOC 的测量：功能的估算应该与要开发的 LOC 数及开发所需工作量关联起来。
度量中最关心的问题：生产率：软件开发“输出量”的测量。质量：工作产品“适用性”的测量
历史绩效信息：过程改进和项目策划的基础。包括：以往项目的生产率数据。以往项目的质量数据
以往项目的成本数据。
6.2.4 面向对象项目的度量
用于 OO 项目的度量$\times$ 场景脚本的数量$\times$ 管件类的数量$\times$ 支持类的数量$\times$ 每个管件类的平均支持类的数量$\times$ 子系统的数量。
这些数据必须同项目测量数据一起收集，以便建立面向 OO 测量与项目测量之间的联系，有助于项目估算。$\times$ 工作量数据$\times$ 错误和缺陷数据$\times$ 文档数据$\times$ 模型
6.2.5 面向用例的度量
【使用用例作为规范化的测量时合理的】：用例是在项目早期定义的；用例估算可以再建模和构造之前开始；用例是系统的基本需求，是用户课件的功能和特性；用例和程序设计语言无关；用例的数量与 LOC 和测试用例的数量成正比。【面向用例的测量仍在研究之中】：用例可以在不同的抽象级别上创建，用例的大小没有标准；目前由于用例本身缺乏标准测量，因此基于用例的度量是不可信的。
6.2.6WEB 工程项目度量
WEB 工程项目度量数据库的建立：静态 WEB 页的数量。动态 WEB 页的数量。内部页面链接的数量。永久数据对象的数量。通过界面链接的外部系统的数量。静态内容对象的数量。动态内容对象的数量。可执行的功能的数据。
随着数据库规模的扩大，就可以使用该数据库评估组织内容的生产率和质量。同时建立起 WEB 测量与项目测量之间的关联，服务于项目估算。①工作量数据②错误和缺陷数据③文档数据
6.3 软件质量度量
软件工程的最高目标就是产生高质量的系统、应用或产品。必须掌握有效的方法及使用现代化的工具；必须能够通过测量来判断能否实现高质量。应用软件质量的测量指标主要有：正确性，可维护性，可用性，完整性，缺陷排除效率。【正确性】：正确性是软件完成所要求的功能的程度，通常用每千行代码的缺陷数来测量。缺陷是指在程序发布后经过全面使用由程序用户报告的问题。在进行质量评估时，缺陷是按照标准时间段来计数的。【可维护性】$\times$ 可维护性包括：遇到错误时程序能够被修改的容易程度。环境发生变化时程序能够适应的容易程度。变更需求时程序能够被增强的容易程度。$\times$ 平均变更时间（MTTC）用于间接地测量可维护性：$\times$ MTTC 包括分析变更请求，设计合适的修改方案，实现变更并进行测试，把变更发布给用户所用的时间。$\times$ 平均变更时间越短程序的可维护性越好。【完整性】完整性是指系统对安全性攻击的抵抗能力：危险性指一个特定类型的攻击在给定时间内发生的概率；安全性指一个特定类型的攻击将被击退的概率；完整性=求和：[1-(危险性*（1-安全性）)]。【可用性】可用性是指程序使用的容易程度，包括：便于学习。帮助初学者记住他们已经学到的东西。降低犯错的可能。使得用户更加有效率。使得用户对系统感到满意。可用性系统可以提高销售量和用户的满意度，具有竞争优势，在媒体中获得良好评论和口碑、降低支持费用，减少文档开销，减少来自不满意用户的投诉。【缺陷排除效率】：缺陷排除效率(DRE)在项目级和过程及都能提供有益的质量度量。缺陷排除效率 DRE=E/(E+D)，其中，E=软件交付给最终用户前所发现的错误数，D=软件交付之后富哦返现的错误数，DRE 本质上是质量控制和保证活动的过滤能力的衡量标准，它鼓励软件项目组采用先进技术以便在交付之前发现尽可能多的错误，即，使得 DRE 接近 1。DRE 也可以用来评估一个小组在错误传递到下一个框架活动之前发现错误的能力。【软件项目组质量】项目内部缺陷排除效率：DRE(i) = E(i) / (E(i) + E(i+1))。其中：E(i) = 在软件工程活动 i 中所发现的错误数；E(i+1) = 在软件工程活动 i+1 中所发现的错误数；软件项目组质量目标是使 DRE 接近 1，即，错误应该在传递到下一个活动之前被过滤掉。
6.4 在软件过程中集成度量
在软件过程中集成度量：建立项目基线 ==>明确过程改进目标，质量软件度量大纲 ==> 进行测量和度量，评估过程改进目标==>分析评估结果找出问题根源调整软件过程解决问题
6.4.1 建立基线
【度量基线】是由从以往的软件开发项目中收集数据构成的。基线可以在过程改进、成本和工作量估算中加以使用并接受评估。【基线数据应具有的属性】：$\times$ 数据必须相当精确，应避免对过去项目进行“推测” $\times$ 应该从尽可能多的项目中收集数据 $\times$ 测量数据必须是一致的 $\times$ 基线数据所在的应用系统应该与将要做估算的工作类似。【度量基线的建立过程】见图：质量评估主要分析结果产生的原因
6.4.2 制定软件度量大纲
基于目标的软件度量——-GQM 度量模型。【第一层：概念层（目标G）包含：目标、目标设计的度量对象及其属性信息。==> 第二层：运作层（问题Q）有目标细化出多个问题，描述实现目标的方式。==> 第三层：量化层（度量M）一组以量化的方式问答上述问题的数据（主观、客观）】【GQM 的观点】：对一个组织而言，度量应该是有目的性的，它应首先定义其自身或其内部某项目的目标，根据目标去跟踪那些定义目标的数据，然而提供一个框架用于解释这些数据域所确定的目标之间的关系。【目标驱动的软件度量大纲的综合指导手册】：1、明确业务目标 2、弄清需要了解或学习的内容 3、确定子目标 4、确定与子目标相关的实体或属性 5、确定测量目标 6、识别可量化的问题和相关的指标 7、明确要收集的数据元素，从中得到有助于回答问题的指标 8、定义将要使用的测量，使这些定义具有可操作性 9、弄清实现测量需要做的操作 10、准备一份实施测量的计划—–》软件度量大纲。『所选软件度量是由希望达到的业务或技术目标驱动的。』
6.5 度量的适用范围
测量适用于各种组织，与组织规模无关。小型组织的度量要保持简单。根据项目需要进行定制，确保带来增值。『从测量中导出的度量能够帮助组织改进其软件过程，提高所开发产品的质量、缩短开发时间。』
6.6 小结
测量能使管理者和开发者改进软件过程，辅助进行软件项目的计划、跟踪和控制，评估生成的产品的质量。对过程、项目及产品的特定属性的测量可用来计算软件度量，分析这些度量可以获得指导管理及技术行为的指标。软件质量度量关注的是过程、项目和产品，一个组织通过建立和分析质量度量基线，能够纠正那些引起软件缺陷的软件过程区域。软件度量的三个步骤是：数据收集、度量计算和度量分析，目标驱动的方法有助关注与对其业务的正确度量。
第七章估算
7.1 项目策划过程
没有很好地制定计划是一个项目犯的最严重的错误之一……有效的计划是必需的。可以在上游以较低的成本解决问题。而不是在下游以较高的成本解决问题。一般的项目要将 80%的时间花费在返工上——改正在项目早期所犯的错误。——Steve McConnell
7.2 软件范围和可行性
软件范围描述了功能、性能、约束条件、接口及可靠性。定义范围的方法：$\times$ 与所有项目干系人交流，写出对软件的叙述性描述 $\times$ 由最终用户开发一组用例，描述用户与软件的交互场景。$\times$ 范围可行性分析。考虑技术、经济、时间、资源。
7.3 资源
三类主要的软件工程资源：$\times$ 资源描述$\times$ 可用性说明$\times$ 何时需要$\times$ 使用持续时间。必须在开发初期建立资源的可用性。
7.3.1 人力资源
7.3.2 xx资源
7.3.3 环境资源
7.4 软件项目估算
【准确估算的能力是 IT 组织关键的成功因素】：外包和竞争更加激烈的时代，更准确地进行估算的能力……已经成为很多 IT 组织关键的成功因素。——Rob Thomsett。估算是一门科学 $\times$ 估算时间和工作量的实用技术。项目度量数据过程度量数==> 过去的经验 ==> 历史信息 ==> 勇气。【估算具有与生俱来的风险，永远不会是一门精确的科学】$\times$ 资源、成本、进度的定量估算的不确定性$\times$ 需求、人员、技术、环境和策略的变化对估算结果的影响。应满足于事务本性所能容许的精确度，当只可能近似于真理时，不要追求绝对的准确。——Anstotle。软件项目估算正在从一种神秘的技巧向一系列系统化的步骤转变。【影响软件项目估算准确性的因素】$\times$ 计划人员估算待开发产品规模的正确程度$\times$ 把规模估算转换成人的工作量、时间及成本的能力$\times$ 产品需求的稳定性及支持软件工程工作的环境$\times$ 项目计划反映软件项目团队能力的程度。规模估算是主要挑战：软件项目估算主要集中于对项目成本和工作量的估算。可选方案：
| 可选方案 | 评价 | |
|---|---|---|
| 后期估算 | 把估算推迟到项目的后期进行 | 不现实 |
| 类比估算 | 根据已经完成的类似项目进行估算 | 只适用极端情况 |
| 自下而上估算 | 使用分解技术，分而治之、逐步求精 | 可行 |
| 参数模型法 | 使用一个或多个经验模型进行估算 | 可行 |
估算方法的好坏取决于估算使用的历史数据。没有历史数据，估算就没有稳定的基础。
7.5 自下而上估算——分解技术
| 为什么要使用分解技术？ | 问题 | 解决方案 |
|---|---|---|
| 待解决的问题太过复杂，不能作为一个整体来考虑 | 对问题进行分解，把它分解为一组较小的更易于管理的问题，再定它们的特征。 |
如何分解？$\times$ 问题分解$\times$ 过程分解$\times$ 用例分解
7.5.1 软件规模估算
软件规模是指软件项目的可量化结果，可以用代码行（LOC）或者功能点（FP）来测量。规模估算的四种方法（Putnam&Myers）.
| 方法 | 主要内容 |
|---|---|
| 模糊逻辑法 | 使用了模糊逻辑基础的近似推理技术。先确定应用的类型，定性地确定其量级，在初始范围内再细化该量级。 |
| 功能点法 | 对信息域的特征进行估算。 |
| 标准构件法 | 估算每一个标准构件的出现次数，然后使用历史项目数据来确定每个标准构件交付时的大小。 |
| 修改法 | 一个项目中包含对已有软件的使用，要估算必须完成的要修改的数目及类型，估算出修改的规模。 |
【将上述每种方法的估算结果在统计意义上结合起来，产生最终的结果】
基于 LOC 估算的实例 【基于 LOC 测量的方法估算一个机械零件 CAD 应用软件的成本、工作量。】软件范围陈述：CAD 软件接受来自工程师的二维或三维几何数据。工程师通过用户界面与 CAD 系统进行交互，并控制它，该界面应表现出良好的人机界面设计的特征。所有几何数据及其他支持信息都保存在一个 CAD 数据库中。开发设计分析模块，以产生所需的输出，这些输出将显示在各种不同的图形设备上。软件在设计中要考虑与外设进行交互并控制它们，包括鼠标、数字化仪和激光打印机。
¾ Step1.功能分解与测量。功能分解==>用户接口及控制设备==>二维几何分析==>三维几何分析==>数据库管理==>计算机图形显示设备==>外部设备控制功能==>设计分析模块。 ¾ Step2.计算工作量和成本度量。回顾历史数据，得到应用领域的基线生产率数据。根据 LOC 测量结果与历史数据，得到度量结果，工作量=33200LOC/620LOC/MM=54MM，总成本=总成本=8000 美元/MM*54=43.1 万美元。应用领域基线生产率，【生产率 620Loc/MM，成本：8000 美元/MM】
7.5.2 基于问题的估算
【基于问题的估算流程】 Step1 根据界定的软件范围陈述，将软件分解成可分别独立进行估算的功能问题。 Step2 估算每个功能的 LOC 或 FP。『直觉和经验是必不可少的』 Step3 选择项目应用领域的基线生产率度量。 Step4 将基线生产率度量应用于估算变量中，得到每个功能的成本和工作量。 Step5 将所有功能的估算合并起来，产生整个项目的整体估算。『生产基线度量含：LOC/MM
FP/MM，成本/KLOC』【基于问题的估算中应注意的问题 】 LOC 估算和 FP 估算所要求的详细程度和划分目标不同 基线生产率度量要根据项目领域计算：1.根据项目的团队规模、应用领域、复杂性及其他相关参数对项目分类（划分应用领域）2. 计算每类项目的生产率平均值，以此作为该应用领域的基线生产率度量。 利用三点估算法提高估算准确程度，控制不确定性的可能范围：任何估算技术都必须与其他方法交叉使用、相互验证。
基于 FP 估算的实例
Step1：信息域分解与 FP 测量。
| 信息域 | 乐观值 | 可能值 | 悲观值 | 估算值 | 加权因子 | FP 值 |
|---|---|---|---|---|---|---|
| 外部输入数 | 20 | 24 | 30 | 24.3 | 4 | 97 |
| 外部输出数 | 12 | 15 | 22 | 15.7 | 5 | 78 |
| 外部查询数 | 16 | 22 | 28 | 22 | 4 | 88 |
| 内部逻辑文件数 | 4 | 4 | 5 | 4.2 | 10 | 42 |
| 外部接口文件数 | 2 | 2 | 3 | 2.2 | 7 | 15 |
| 总计 | 320 |
Step2：基于系统基本特征计算调整因子
| 系统特征 | 得分 | 系统特征 | 得分 |
|---|---|---|---|
| 数据通讯 | 2 | 在线升级 | 3 |
| 分布式数据处理 | 0 | 复杂处理 | 5 |
| 性能 | 4 | 可重用性 | 4 |
| 大业务量配置 | 5 | 易安装性 | 5 |
| 处理速度 | 易操作性 | 5 | |
| 在线数据输入 | 4 | 多场所 | 3 |
| 最终用户使用效率 | 4 | 支持变更 | 5 |
| 特性总分 | 52 |
调整因子=0.65+0.01*特性总分=1.17。Step3：计算调整后 FP，调整后 FP=FP 合计*调整因子=375。Step4：工作量与成本度量。回顾历史数据，得到应用领域的基线成产率数据。z 根据 FP 测量结果与历史数据，得到度量结果。工作量=375FP/6.5FP/MM=58MM。总成本=8000 美元/MM*58=46.1 万美元。
7.5.3 基于过程的估算
【基于过程的估算是将过程分解为相对较小的活动或任务，再估算完成每个任务所需的工作量。Step1 从项目范围中抽取出软件功能。Step2 给出为实现每个功能必须执行的一系列框架活动。Step3 针对每个软件功能估算完成各个软件过程活动所需的工作量。Step4 将平均劳动力价格应用于每个软件过程活动的估算工作量，即可估算出成本。Step5 计算每一个功能及框架活动的成本和工作量。基于过程估算的实例
7.5.4 基于用例的估算
【基于用例的估算的例子】基于用例的方法估算一个机械零件 CAD 应用软件的成本、工作量。软件范围陈述，CAD 软件接受来自工程师的二维或三维几何数据。工程师通过用户界面与CAD 系统进行交互，并控制它，该界面应表现出良好的人机界面设计的特征。所有几何数据及其他支持信息都保存在一个 CAD 数据库中。开发设计分析模块，以产生所需的输出，这些输出将显示在各种不同的图形设备上。软件在设计中要考虑与外设进行交互并控制他们，包括鼠标、数字化仪和激光打印机。
应使用多种方法对项目进行估算，把每种方法产生的输出看作是一个“数据点”，再从中导出估算，而不是将其作为估算的唯一来源。
7.6 经验估算模型
经验估算模型使用由经验导出的公式来预测工作量。$\times$ 工作量是 LOC 或 FP 的函数$\times$ LOC/FP 值使用基于 LOC/FP 估算的方法得到。$\times$ 不使用基线生产率度量数据。没有一种经验模型适合所有的项目，经验模型所得结果要慎重使用。针对具体项目应对模型进行调整和验证。
7.6.1 回归分析模型
7.6.2 COCOMO II 模型
【COCOMO II 模型是一种结构性成本估算模型，适用于广泛汇集各种技术的软件项目，根据应用领域不同 COCOMO II 模型分为以下三种：$\times$ 应用组装模型，适用于软件工程早期$\times$ 早期设计阶段模型，需求稳定且体系结构已建立时使用$\times$ 体系结构后阶段模型，在软件构造时使用。【COCOMO II 模型中使用到三种规模估算信息：】对象点、功能点、源代码行。
应用组装模型COCOMO II 的应用组装模型用在软件开发早期，支持对原型开发项目所需工作量的估算，同时也支持基于已有构件进行开发的软件项目。【模型使用加权“对象点”，而不用“源代码行”进行估算】【对象点是一种软件间接度量。根据（用户界面）屏幕数、报表数、建造应用可能需要的构件数来进行加权计算】【应用组装模型的估算流程】Step1.确定对象数目，即：（用户界面）画面数、报表数、建造应用可能需要的构件数。Step2.确定每一个对象实例（每个画面、报表）的复杂度，统计每类对象实例的个数Step3.每类对象个数与复杂度加权因子相乘确定对象点数，求和后得到总对象点数Step4.基于构件开发成软件复用时，估计复用百分比，调整对象点数。Step5.根据开发者经验与环境成熟度选择生产率，估算工作量。
早期设计阶段模型 早期设计阶段模型在系统需求的初始设计实现的情形下使用，用评价软件/系统架构和操作概念。$\times$ 基于功能点进行估算，首先估算功能点，然后把功能点转换为代码行数(LOC) $\times$ 估算方程.PM = 2.45 × (KLOC)b × EAF。其中，b 的具体取值与项目的复杂程度有关EAF 是工作量调整因素，可根据产品可靠性、复杂度等因素调整。体系结构后阶段模型 后期阶段模型用于产品实际开发和维护。使用功能点或 LOC 进行估算估算方程：PM = 2.55 × (KLOC)b × EAF。其中，b 的具体取值与项目的复杂程度有关EAF 是工作量调整因素，可利用软件可靠性、数据库规模、产品复杂度、要求复用性、文档编制等情况进行调整。估算进度 【COCOMOII 不仅可以评估开发工作量，而且可以对项目的进度进行具体估计。】估算方程：TDEV = 2.5 × PM (0.33+0.2× B−1.01 )【对于进度估算则基本上不会出现简单的线性关系】
7.6.3 软件方程式
7.7 面向对象项目的估算
面向对象项目的估算流程:（使用工作量分解、FP 分析和任何其他适用于传统应用的方法进行估算。）1、 使用面向对象的分析模型建立用例并确定用例数。2、 由面向对象的分析模型确定关键类的数量。3、 对应用的界面类型进行归类，确定支持类的乘数、计算支持类数量的估算值。4、 类的总数（关键类+支持类）乘上每个类的平均工作单元数，得到基于类的估算结果。5、 用例数乘以每个用例的平均工作单元数，对基于类的估算做交叉检查。
| 界面类型 | 乘数 |
|---|---|
| 没有图形用户界面 | 2.0 |
| 基于文本的用户界面 | 2.25 |
| 图形用户界面 | 2.5 |
| 复杂的图形用户界面 | 3.0 |
7.8 特殊的估算技术
特殊的估算技术面向持续时间非常短并且有可能出现连续不断的变更的项目。$\times$ 敏捷开发的估算：1.将故事分解为一组功能，确定完成功能所需软件工程任务。2.解估算每一个任务的规模，汇总得到每个增量的工作量。$\times$ Web 工程项目的估算：使用经修改的基于功能点的测量方法，定义信息域为输入、输出、表、界面、查询。
7.9 自行开发或购买的决策
自行开发或购买的决策用于决定是在组织内部制作某些产品或进行某项服务，还是从组织
外部购买这些产品或服务的一种管理技术。应考虑以下几个方面：1、 交付日期 2、 成本问题『估算提供产品和服务的内部成本并与采购成本进行比较，注意：必须包括全生命期成本』3、 能力问题4、 可用性5、 商业秘密等
7.9.1 决策树分析。
创建决策树，沿决策树的任一分支进行计算，得到成本的预期值。
预期值成本=∑（路径概率）i ×（估算的路径成本）i其中，i 是决策树的某个路径。
决策树的分析案例：某软件系统 x，组织能够 $\times$ 从头开始建造系统 x； $\times$ 复用已有具有部分经验的构建来构造系统；$\times$ 购买现成软件产品并修改它以满足当前项目的需要$\times$ 将软件开发承包给外面的开发商
7.9.2 外包
外包将软件工程活动城堡给第三方厂商，他们能够以较低的成本和较高的质量来完成工作。优点：减少软件人员及相应设备，通常能够节约成本。缺点：失去了对其所需软件的部分控制权要冒将其命运交到第三方厂商手中的风险。
7.10 小结：
| 项目开始之前，必须估算的三件事：所需时间、所需工作量、所需人员，明确的范围陈述对估算很重要。估算技术 | 分解 | 经验建模 |
|---|---|---|
| 基于规模(LOC 度量) | 回归分析模型 | |
| 基于问题(FP 度量) | COCOMO2 | |
| 基于用例(实现每个用例所需的人月数) | 软件方程式 | |
| 基于过程(每个软件工程活动所需的人月数) | – | |
| 调和各种方法 | – |
第八章 项目进度安排表
8.1 延期交付的思考
【软件延期交付的原因？】$\times$ 不现实的截止期限，截止期限由项目团队以外的人所设立并强加给软件工程组内的管理者和项目开发者。$\times$ 需求发生变化，而这种变化没有在项目变更进度表上预先安排$\times$ 对工作量和或完成该工作所需的资源数量估计不足$\times$ 在项目开始时，没有考虑可以预测的和或不可预测的风险$\times$ 出现了事先无法预计的技术困难$\times$ 出现了事先无法预计的人力困难$\times$ 由于项目团队成员之间交流部畅而导致的延期$\times$ 项目管理者未能发现进度拖后，也未能采取行动解决这一问题。【现实的进度安排是保证软件按时交付的基本条件】$\times$ 在所有的软件项目中，过于理性或缺少理性的进度安排可能最具破坏性影响。$\times$ 过于乐观的进度安排并不会缩短实际进度，反而会拖后进度。$\times$ 任何同意执行一个他本人都认为有缺点的计划的指挥官都应该受到指责：它必须提出自己的反对理由，坚持修改者以计划，最终甚至提出辞职而不是使自己的军队遭受惨败。【有原则的谈判】站在他人立场上思考。关注共同利益，不要过分坚持立场。提高开发速度。增加成功的机会。援引以前失败项目的教训。提出对双方都有利的备选方案。坚持客观标准和原则。
8.2 项目的进度安排
项目进度安排是一种活动，它通过将工作量分配给特定的软件工程任务而将所估算的工作量分布于计划好的项目持续时间内。进度安排是一个渐进、迭代的过程：计划早期，宏观进度表（活动层面）。计划中后期，详细进度表（任务层面）。
8.2.1 进度安排的基本流程：
活动定义：将项目划分为多个可以管理的活动、动作、任务，为项目建立任务集(分解产品和过程)。活动排序：识别活动、动作、任务之间的相互依赖关系，排列工作顺序，定义任务网络分配人员，确定责任(工作量分配)。分配时间，确保在任意时段分配的人员数量不超过总人员数量，确认工作量(工作量分配)。制定进度计划，明确结果，确立里程碑(明确每个任务的输出结果)。
8.2.2 人员与工作量之间的关系：
项目进度具有弹性：增加额外的资源可以在一定程度上缩短交付日期，减少资源数量可以拖延项目交付日期。项目后期增加人员对项目会产生破坏性的影响：新增人员的培训。项目沟通复杂度的增加会进一步拖延进度。Brooks 定律：向一个已经延期的项目增加开发人员可能使他完成的更晚。项目工作量与交付时间的关系: (PNR 曲线)。源代码行数与工作量和开发时间的关系:
某复杂实时软件项目，源代码行数为 33000 行，那么：开发周期 1.0 年时工作量约为 36 人年；开发周期 1.3 年时工作量约为 12 人年；开发周期 1.75 年时工作量约为 3.8 人年。
8.2.3 工作量分配：
| 指导原则: 40-20-40 法则: | 阶段 | 所占比例 | 详细划分 |
|---|---|---|---|
| 前期分析和设计阶段 | 40 | 项目计划:2-3,需求分析:10-25,软件设计:10-25 | |
| 编码实现 | 20 | – | |
| 后期调试 | 40 | – |
分配比例应根据各个项目的特点进行调整，这不适用于敏捷开发的项目。
8.3 为软件项目定义任务集
过程模型由任务集组成，没有普遍适用于所有项目的任务集；有效的软件过程应该定义一组任务集以满足不同类型的项目的要求。任务集选择依据:严格程度及项目特点，严格度指标:
| 随意的 | 使用了所有过程框架活动，但只需要一个最小的任务集合。一般情况下将保护性任务最小化，并将文档需求降低，所有基本的软件过程原则仍然都是适用的 |
|---|---|
| 结构化的 | 使用过程框架。框架活动和适用于这种项目类型的相关任务以及为保证高质量所需的保护性活动将得到应用，SQA、SCM、文档和度量任务将以一种经过优化的有效方式进行 |
| 严格的 | 整个过程将按照一种能够确保高质量的严格规程要求应用于项目之中，所有的保护性活动将被采用且要建立健壮的文档 |
| 快速反应的 | 使用过程框架，但是由于某种紧急情况的出现只应用了那些为保持软、件系统质量所必须完成的任务，在应用程序/产品交付给客户之后再完成”回填工作”即开发一套完整的文档进行额外的复审 |
【确定严格度指标的适应性准则】：(共 11 条，等级在 1-5，权重为 0.8-1.2) 项目的规模、潜在的用户数量、任务的关键性、应用程序的寿命、需求的稳定性、客户与开发者之间通信的容易程度、应用技术的成熟度、性能约束、嵌入式/非嵌入式特性、项目人员配置、再工程因素。
【计算任务集选择因子 TSS】∑i=1~m(等级分数 i加权因子 i条目点乘数 i)/m。a)条目点乘数在 0 到 1 之间取值，表示该适应性准则与项目类型之间的相关程度。b)根据 TSS 选择任务集，TSS<1.2 随意的，1.0<TSS<3.0 结构化的，TSS>2.4 严格的。
【任务集举例—某概念开发项目的任务集】概念开发项目是在必须探索某些新技术是否可行时发起的，其需要完成以下主要任务（用于创建宏观进度表,然后将宏观进度表精化来创建一个详细的项目进度表）a)确定概念范围 b)初步的概念计划 c)技术风险评估 d)概念证明 e)概念实现 f)客户对概念的反应。【用 WBS 来表达任务集任务】这些任务和子任务共同构成了制定“确定概念范围”这一活动的详细进度表的基础。
8.4 定义任务网络
1.项目网络图告诉我们：能表示项目的所有活动并表明活动之间的依赖关系；能表明项目活动将以什么顺序继续；在进行工期估计时能表明项目需要的最短时间；当改变某项目活动工期时能表明项目工期将如何变化 2.计划者必须确定任务之间的依赖关系以保证项目朝着最终完成的方向持续发展 3.概念开发项目的任务网络:
任务网络也称活动网络，是一个项目的任务流程的图形表示，它作为在自动项目进度安排工具中输入任务序列和依赖关系的机制，当创建宏观进度表时使用。此为宏观任务网络，详细的任务网络应对各活动加以扩展，显示细化、求精之后的所有详细任务.
8.5 进度安排
1.在完成了活动定义、活动排序、活动所需资源估算和活动所需时间估算之后，进度安排就是要确定每项任务的开始时间和结束时间 2.进度安排要依据先期取得的如下信息：工作量估算、产品功能分解、适当过程模型和任务集的选择、任务的分解 3.进度安排使用的技术：甘特图、计划评审技术、关键路径法。
8.6 跟踪进度
【如何跟踪进度？】定期举行项目状态会议，由项目组中的各个成员分别报告进度和问题。评估所有在软件工程过程中所进行的复审的结果确定正式的项目里程碑是否在预定日期内完成比较项目表中列出的各项任务的实际开始日期与计划开始日期与开发者进行非正式会谈，获取他们对项目进展及可能出现的问题的客观评估。有经验的管理者都会使用以上所有的跟踪进度。【目的】：对项目实施控制，管理项目资源、处理问题和指导项目参与者。没有问题就不必施加控制，发现问题就必须施加控制，采取应对措施。【进度控制的“时间盒“技术】通过对增量的交付日期倒退着推算来调整每项任务的进度，保证项目朝着交付日期，推进而不是卡在某项任务上。时间盒长度（40 小时）：15%设计 70%开发 15%复审，结束期不可变，人员不要变化【常见问题：】a)只跟踪进度不记录项目数据；b)追赶计划，进度落后只是简单地觉得从后续进度上弥补回来；c)不及时细化和更新计划，计划沦为应付领导的手段；d)缺少质量保证措施(取消测试计划，只做必要的功能测试;削减或取消评审工作；取消设计) 【跟踪 OO 项目的进展：】OO 过程模型是以迭代方式进行的通过使用相应的准则来衡量主要技术里程碑是否完成。$\times$ OO 分析完成：已经定义和评审了所有的类和类层次；已经定义和评审了与每一个类相关的属性和操作；已经建立和评审了各类之间的关系；已经建立和评审了行为模型；已经确定可复用的类 $\times$ OO 设计完成：已经确定和评审了子系统集合；各类已经分配给相应的子系统并已经通过评审；已经建立和评审了任务分配；已经明确责任和协作；已经设计和评审了属性和操作；已经创建和评审了通信模型；$\times$ OO 程序设计完成：按照设计模型，每一个新类都已经编码实现；从可复用库中提取的类已经实现；已经构建了原型或增量；$\times$ OO 测试：已经评审了 OO 分析和设计模型的正确性和完整性；已经建立和评审了类-责任-协作网络；已经设计了测试用例并已经对每个类进行了类级测试；已经设计了测试用例并已经完成簇测试，已经完成类的集成；已经完成系统级测试。【Web 项目进度安排】
小结
1.计划活动是软件项目管理的重要组成部分，进度计划是计划活动的首要任务。进度安排与估算方法和风险分析相结合，可以为项目管理者画出一张路线图。2.进度计划始于过程分解，根据项目特性需要为项目选址任务集3.任务网络描述了各项任务之间的依赖关系及工作工期，可用来确定项目的关键路径、甘特图和各种项目信息 4.基于进度表，项目管理者可跟踪和控制软件工作过程中的每一个工作任务。
第 9 章 风险管理
9.1 风险与风险策略
【风险定义】：风险是指具有不确定的事件或情况，一旦发生，会对项目目标产生积极的或消极的影响。三要素：风险事件识别，风险发生概率，风险结果。【风险策略】：1.被动风险策略：针对可能吃咸的问题不采取任何措施，知道问题出现才进行处理。比如：救火模式。2.主动风险策略：识别潜在问题，评估问题发生的概率和影响，按照重要程度排序，制定计划来管理问题。比如：预警模式。
9.2 软件风险
【软件风险】：是指有可能影响软件项目、软件过程或软件产品的事件。a.软件风险是与生俱来的b.软件风险随着系统复杂程度的增加而增加c.软件风险阻碍人们实现目标。软件风险的特性：不确定性、损失。3.按领域划分的软件风险类型：
【按是否可预测划分的软件风险类型】a.已知风险：通过评估项目计划、商业及技术环境、其他可靠信息来源之后发现。b.可预测风险：从过去项目的经验中推理出来。c.不可预测风险：难以事先加以识别。【软件风险管理流程】
9.3 风险识别
【风险识别试图系统化的指出对项目计划的威胁】a.已知风险 b.可预测风险【每类风险都存在两个类型】a．一般风险:对每一个软件项目而言都是潜在威胁 b.产品特定风险：当前项目特有的潜在威胁 【风险识别要确定以下事项】a.风险事件：可能会对项目造成损害的具体情况 b.风险症状：实际风险事件的指示器或触发器。分析风险发生的条件及子条件，按照“条件-变迁-结果”的格式来表示风险，即：给定<条件>，则有结论：（可能）<结果> 【风险识别的方法】建立风险条目检查表识别风险；访谈、信息搜索（头脑风暴法、德尔菲技术）；文档回顾；会议/评审、SWOT 分析、专家判断。
9.3.1 风险识别的检查表
为各种风险类型组织一组问题，计划者根据对这些问题的回答识别风险。使用风险调查问卷识别组织是否已经建立了一份已经成文的，用于本项目的软件过程的说明？开发人员是否“签约”统一按照文档所写的软件过程进行开发工作，并自愿使用它？是否定期地对需求规约，设计和编码进行正式的技术复审？是否定期地对测试过程和测试情况进行复审？是否使用配置管理来维护系统需求，设计，编码及测试用例之间的一致性？是否使用了一个机制来控制用户需求的变化及其对软件的影响？过程问题示例 组织是否已经建立了一份已经成文、用于本项目的软件过程的说明？开发人员是否签约同意按照文档所写的软件过程进行开发工作，兵资源使用它？是否定期的对需求规约、设计和编码进行正式的技术复审？是否定期的对测试过程和测试情况进行复审？是否使用配饰管理来维护系统需求、设计、编码及测试用例之间的一致性？是否使用一个机制来控制用户需求的变化及其软件影响？技术问题示例 该技术对于你的组织而言是新的吗？客户的需求是否需要创建新的算法或输入、输出技术？待开发软件是否需要与开发商提供的未经证实的软件产品接口？待开发软件是否需要与其共功能及性能均未在本领域中得到证实的数据库系统接口？产品的需求中是否要求开发某些程序构件，这些构件与你的组织以前所开发过的构件完全不同？需求是否要求使用新的分析、设计或测试方法？评估整体项目风险的问题示例（按重要性排序） 高层的软件管理者和客户管理者已经正式承诺支持该项目了吗？最终用户对项目的待开发的系统/产品热心支持吗？ 软件工程团队及客户充分理解需求了吗？客户已经完全参与到需求定义中了吗？最终用户的期望现实吗？项目范围稳定吗？项目团队对将实现的技术有经验吗?项目团队的人员满足项目需求吗？所有客户/用户对项目的重要性和待开发的系统/产品的需求有共识吗？PS：任何一个问题的答案是否定的，则需立即启动缓解、检测和管理风险的步骤。
9.4 风险预测
风险预测，又叫“风险估计”或“风险分析”，试图从两个方面评估风险：a.风险发生的可能性或概率；b.风险相应问题产生的后果。风险预测的步骤:a.建立一个反映风险发生可能性的尺度b.描述风险产生的后果c.估计风险对项目或产品的影响d.表明风险预测的整体精确度，以免产生误解
9.4.1 建立风险表
【风险表】又称“风险登记册”，为管理者提供一种简单的风险预测方法。
9.4.2 确定风险发生概率和风险影响
- 各个风险的概率值由团队成员进行估计，按照循环投票的方式进行，直到大家的估计值趋于接近为止。2. 针对性能、支持、成本、进度这四大风险，查表（9.3.2）以最符合表中描述的特性为基础，确定风险影响类型。3. 根据风险影响类型，估算风险一旦发生对项目产生影响的货币值。
列出与风险类型相关的特性，给出风险因素和驱动因子以及它们发生的概率。【风险因素】（美国空军，1988）：性能风险，成本风险，支持风险，进度风险。【驱动因子】标识出风险因素的影响程度：可忽略的，轻微的，严重的，灾难性的。9.4.3 计算风险显露度
【风险显露度（RE、risk exposure）】：是风险事件发生概率与风险影响货币值得乘积。a.确定每个风险发生的概率 P;b.确定每个风险的影响以及风险发生时带来的项目成本 C；c.计算风险显露度 RE=P*C。
9.4.4 风险排序
| 1.按照概率、影响、风险显露度对风险排序 | 风险 | 风险类型 | 概率 | 影响值 | RMMM指示器 |
|---|---|---|---|---|---|
| 规模估算可能很不正确 | ps | 60% | 2 | – | |
| 用户数量大大超出计划 | PS | 30% | 3 | – |
9.4.5 评估整体风险影响
【计算风险的整体影响】性能、支持、成本、进度的影响类别加权平均。权值由各风险因素对项目的重要程度而定。【计算总体显露度】计算风险表中的截线之上的总体风险显露度，作为调整项目最终成本估算的依据，预测在项目进度过程中不同阶段的人力资源需求。
9.5 制定风险管理计划
【风险管理计划是风险缓解、监测和管理的策略】
【制定风险管理计划的步骤】a.确定管理策略分类『哪些风险通过改变计划回避掉』『哪些风险转移给第三方』『哪些风险要制定应对方案对其进行缓解和控制』『哪些风险可以接受』b.制定风险管理和应急计划，也称“风险缓解、监测和管理计划（RMMM 计划）”。【RMMM 计划大纲】1. 引言。 文档的范围和目的； 主要风险综述； 责任 a)管理者 b)技术人员 2. 项目风险表 1） 中止线之上的所有风险的描述 2）影响概率及影响的因素 3. 风险缓解、监测和管理 a. 缓解：一般策略；缓解风险的特定步骤。 b. 监控：被监控的因素；监控方法。 c. 管理：意外事件计划；特殊的考虑。4.RMMM 计划的迭代时间安排表。5.总结
制定风险管理计划的例子 以识别的风险：频繁的人员变动。预测：发生概率 70%，一旦发生项目成本及进度有严重影响。管理计划：与现有人员一起探讨一下人员流动的原因；项目开始前，采取行动以缓解那些在管理控制下的原因；采取一些技术以保证当人员离开时的工作连续性；对项目进行良好组织，使得每一个开发活动的信息能被广泛传播和交流；定义文档的标准，并建立相应的机制，以保证文档能被及时建立；对所有工作进行详细复审，使得不止一个人熟悉该项工作；对于每一个关键的技术人员都指定一个后备人员。
9.6 风险监测和控制
1.风险监测的目的：1）评估一个被预测的风险是否真正的发生了；2）保证为风险而定义的管理计划被正确地实施；3）收集能够用于未来风险分析的信息。2.风险监控是在整个项目中，实施风险管理计划、跟踪已识别风险、监测残余风险、识别新风险和评估风险过程有效性。
实施风险管理计划将导致额外的项目开销。要进行评估，确保实现他们所产生的效益高于所花费的成本。
9.7 小结
1.项目风险管理会占用管理者大量时间，但是，这个投入是值得的。2.风险管理可以从多个方面得到回报：更加平稳的项目进度过程；较高的跟踪和控制项目的能力；由于在问题发生之前已经做了周密计划而产生的信心。
第 十 章 质量管理
10.1 质量概念
【ISO 对质量的定义】：质量是反映实体满足规定和潜在需要能力的特性的总和。质量是产品、服务或过程各自对客户需求的适应性，即满足客户需求的能力。符合要求（Conformance to requirements）适用性
10.2 软件质量
【软件质量的定义】：$\times$ 软件质量是与软件产品满足规定的和隐含的需求能力有关的特征或特性的全体。ANSI/IEEE S 它的 729-1083 $\times$ 所有描述计算机软件优秀程度的特性组合 MJ Fisher
10.3 软件质量特性
| 【软件质量特性反映了软件的本质】：$\times$ 讨论一个软件的质量，问题最终要归结到定义软件质量特性。$\times$ 定义一个软件的质量，就等价于为该软件定义一系列质量特性。【人们通常把影响软件质量的特性用软件质量模型来描述】【Garvin 的 8 维度质量模型】提供了从符合性评估到抽象的观点，是对软件质量的“软”评判。『Garvin多维观』==>{特性质量，可靠性，符合性，耐久性，适用性，审美，感知，性能质量} 【ISO9126 质量属性模型】 | 质量属性 | 子属性 |
|---|---|---|
| 功能性 | 适合性、准确性、互操作性、依从性、安全保密性 | |
| 可靠性 | 成熟性、容错性、易恢复性 | |
| 易用性 | 易理解性、易学习性、易操作性 | |
| 效率 | 时间特征、资源利用特征 | |
| 维护性 | 易分析性、易改变性、稳定性、易测试性 | |
| 可移植性 | 适应性、易安装性、符合性、易替换性 |
为间接测量提供了有价值的基础，为评估系统质量提供了一个优秀的检查单。McCall 的质量维度模型（1976）侧重于软件产品的 3 个方面：$\times$ 操作特性$\times$ 承受变更的能力$\times$ 对新环境的适应能力
可以间接的测量，能够真实的反映软件的质量。【软件质量特性还被定义成分层模型】$\times$ 最基本的称为基本质量特性，它可以由一些子质量特性定义和度量。$\times$ 子质量特性在必要时又可由它的一些子质量特性定义和度量。【典型软件分层模型】$\times$ 1976 年 Boehm 质量模型$\times$ 1979 年 McCall 质量模型（对 1976 年的改进）$\times$1985 年 ISO 质量模型。【ISO 质量模型度量模型】由三层组成：软件质量需求评价准则（SQRC）软件质量设计评价准则(SQDC) 软件质量度量评价准则(SQMC) 【高层和中层建立国际标准，低层可由各使用单位视实际情况而定】
【软件质量特性度量方法】
10.4 质量成本
【软件质量困境”及其解决之道】：在质量和成本之间权衡. $\times$ 产品质量要足够好，不会立即被抛弃 $\times$ 产品质量不是那么完美，不需要花费太长时间和太多成本。【足够好的软件提供用户期望的高质量功能和特性，但同时也提供其他包含已知错误的功能和特性】。『产品质量是一个函数，该函数确定了它在多大程度上使这个世界变得更好…….』==> 『如果一个产品能给用户带来实质性的益处，他们可能会心甘情愿的忍受偶尔的可靠性或性能问题』【软件质量就是应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值】【质量成本包括追求质量过程中或在履行质量有关的活动中引起的费用以及质量不佳引起的下游费用等所有费用】【一致成本、非一致成本】$\times$ 质量成本 = 一致成本 + 非一致成本 $\times$ 一致成本 = 预防成本 + 评估成本 $\times$ 非一致成本 = 内部故障成本 + 外部故障成本【软件错误修复成本变化趋势:】$\times$ 随着软件生命周期的进展，成本急剧增加。$\times$ 例：假定某系统编码阶段引入 200 个错误：1.若在编码阶段发现并修复，则成本：977*200=195400 美元；2.如测试阶段发现并修改 50 个错误，则成本：736*5=356800 美元 3.维护阶段发现并修复 150 个缺陷，则成本：14102*150=2115300 美元；4.编码之后发现和解决问题的代价是：2472100 美元。$\times$ 质量总成本：包含外部故障成本，内部故障成本，评估成本，预测成本；【如何缩小质量总成本？】$\times$ 50%或者更多质量成本来自内外部的故障；$\times$ 通过缩减一致成本来节省费用会带来灾难性的后果。【故障的完全消除是一种理想但非有效的解决方案】Juran 认为：只要每单位的评价和预防费用低于非一致成本，资源会分配到预防和评价中；当预防和评价成本开始增加每单位的质量成本时，应采取“维持质量不变”的策略。
10.5 软件评审
软件评审是软件工程师发现错误、提高软件质量的有效手段。【软件工作产品，规则】==> 【软件评审】==> 【发现错误，预防缺陷】软件评审的作用：1.提高产品质量；2.及早发现问题，降低产品开发和维护阶段的时间和成本；3.提高生产率；4.提高软件估算的正确性；5.培训。【缺陷放大模型】缺陷放大模型用以说明在软件工程的设计和编码活动中错误的产生和检测。【来自前面步骤（N-1）的错误】==>【开发步骤N：缺陷：1.通过的错误 2. 放大的错误1：X 3. 新产生的错误。 检测：错误检测有效的百分比ue】==>【传给下一个步骤（N+1）的错误】前面的步骤传进来的错误会在当前步骤中被放大。
【软件评审方法（正式化程度从高到低）】1.审查2.小组评审3.走查4.结对编程5.同级桌查6.轮查7.临时评审【技术评审参考模型】其包括四个部分：计划和筹备；个人角色扮演；会议组织；修改和验证。
【正式技术评审】正式技术评审（FTR）是一种由软件工程师（以及其他人）进行的软件质量控制活动。$\times$ FTR 的目标：1.发现软件任何一种表现形式的功能、逻辑或者实现上的错误；2.验证评审中的软件是否满足其需求；3.保证软件的表示符合预先制定的标准；4.获得以统一的方式开发的软件。$\times$ #审查1.审查小组明确分工；2.使用缺陷检查表；3.使用严格定义的，文档化的评审过程：a.计划、准备，召开评审会议，返工，验证；b.完成评审报告。$\times$ 小组评审 1.评审过程：计划，准备，开会，返工；2.评审组长主持会议；3.评审组长询问其他评审者是否有问题；4.使用记录员；5.使用缺陷检查表；6.完成评审报告。$\times$ 走查 1.评审过程：计划、开工、返工；2.作者主持会议，起主导作用，陈述产品3.常用方法：A.使用样本数据单步执行模块，检查逻辑和行为是否正确；B.使用交互式调试器；C.使用脚本，用脚本描述具体任务和场景，检查模块功能和行为；$\times$ 同级桌查：两次编译之间仔细检查源代码，以保证程序正确执行，是一种自评审，不属于同级评审。A.寻找一位足够专业且值得信赖的人担任评审者；B.由评审者对工作产品进行检查；C.评审完成后把错误表交给作者或者将简单标记过的工作产品交给作者；$\times$ 轮查 1.有多人组成的并行同级桌查； 2.有助于缓和同级桌查的两个主要风险： A.评审者不能及时提供反馈； B.评审效果不好。$\times$ 结对编程：由搭档的实时评审，结对这可以迅速纠正错误，快速的迭代能是设计和程序更加健壮，不仅适用于编码还适用于需求，设计和测试文档。$\times$选择合适的评审方法
$\times$ 评审流程
$\times$流程细节解释：A.工作产品：包括项目计划，需求规格说明书，概要设计，详细设计，测试计划，用例，报告，代码。B.计划：审查组长判断是否满足审查进入标准；明确审查目标；确定审查人员。C.准备：将待审查的资料交给审查人员；审查人员进行审查，提出问题；75%的错误是在准备阶段发现的；D.审查会议：每次会议不得超过 2 个小时；目标是尽可能多的发现问题而不是解决问题；$\times$评审的最佳实践准则：1.制订评审计划，明确项目目标和评审目标；2.使用严格的准入和准出条件；3.在文档生成的初期阶段就开始对其进行评审；4.核对源代码和相关的文档；5.在最适当的时机进行准备和评审；6.把焦点放在发现问题上；7.测试评审的投资回报率；8.重视缺陷预防和过程的改进.
10.6 统计软件质量保证
统计软件质量保证是创建自适应软件过程的重要步骤：1.收集软件的错误和缺陷信息，进行统计；2.追溯每个错误和缺陷的根本原因；3.使用 Pareto 原则分离引起 80%的缺陷的 20%的问题；4.纠正引起错误和缺陷的问题。
总结：
质量是个非常严重的问题，必须引起重视；各种软件质量度量和因素都试图定义一组属性作为衡量质量的指标；质量是有成本的，体现在预防，评估，失效三个方面。高质量的完美的软件所需的时间和工作量在现实世界里难以达到；“足够好”的软件是很现实的质量目标；项目质量管理包括质量规划，质量保证，质量控制三个主要过程；评审技术是一种重要的质量保证的手段，其目标是尽早发现和纠正错误，减少缺陷。正式技术评审是一种程序化的会议，在发现错误方面非常有效。
第十一章 项目变更
11.2 变更管理
【项目基准，变更流程和变更控制委员会】 $\times$ 基准管理：基准是变更的依据，每次变更通过评审后，都应该重新确定基准$\times$ 建立变更控制流程：所有变更都必须遵循控制流程$\times$ 明确组织分工：明确变更评估，评审和执行职能$\times$ 完整体现变更的影响：客户方影响，项目内部工作影响$\times$ 妥善保存变更产生的相关文档：可利用配置管理工具.【变更管理的基本原则】
11.3 变更管理组织机构与工作程序
【变更控制委员会 CCB】$\times$ 由项目所涉及的多方人员共同组成。通常包括用户和实施方的决策人员。$\times$ 是决策机构，其工作是通过评审手段决定项目是否能变更但不提出变更方案；【项目经理在变更管理中的职责】$\times$ 响应变更提出者的要求$\times$ 评估变更对项目的影响及应对方案$\times$ 将要求由技术要求转化为资源需求供授权人决策$\times$ 根据评审结果实施项目基准。【变更管理的工作程序】
11.4 变更管理的工作内容
严格控制项目变更申请的提交$\times$ 变更申请是变更管理流程的起点$\times$ 严格项目基线管理，对变更处理的流程达成共识$\times$ 将变更内容具有可操作以性变更控制$\times$ 对进度变更的控制$\times$ 对成本变更的控制$\times$ 对范围变更的控制$\times$ 对合同变更的控制【变更管理的注意要点】$\times$ 对变更产生的因素施加影响，防止不必要的变更$\times$ 对变更的确认应当正式化$\times$ 变更的操作过程应当规范化【变更管理与其他项目管理要素间的关系】$\times$ 变更管理与整体管理，变更管理是整体管理的一部分$\times$ 变更管理与配置管理，当配置管理用于项目基准调整时，变更管理作为配置管理的一部分。
小结
变更管理是应用于整个软件过程的一种普适性活动。变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。
第十二章 敏捷项目管理
12.1 敏捷项目管理模式
【敏捷相互依赖宣言】$\times$ 我们通过使得我们所关注的价值持续流转来增加投资回报$\times$ 我们通过与客户频繁交互，与客户分享责任，来交付可靠的结果$\times$ 我们预料到不确定性，通过迭代、预防和适应来管理它$\times$ 我们承认个人是价值的最终源泉，建设一个使他们能够表现不同的环境，以此来发挥创造力和创新力$\times$ 我们通过对结果进行团队问责和对团队效率共同担当责任，从而提升绩效$\times$ 我们使用根据具体情况而定的策略、过程和实践来提高效率和可靠性
12.1.1 敏捷企业架构
项目管理在敏捷组织中的重要性：确保组织可以采用混合的敏捷方法以满足特定的需要。【技术实践】【迭代管理】【项目管理】【投资组合管理】
12.1.2 敏捷交付框架
对敏捷交付框架的要求$\times$ 支持构想、探索、适应文档$\times$ 支持自我组织、自律的团队$\times$ 根据项目的不确定性程度，尽量提高可靠性和连贯性$\times$ 保持灵活和易于适应$\times$ 支持流程的透明化$\times$ 合并知识$\times$ 囊括支持各个阶段的做法：提供管理检查点
12.1.2 敏捷交付框架
敏捷项目管理交付框架：$\times$ 构想$\times$ 推测$\times$ 探索$\times$ 适应$\times$ 结束
敏捷项目管理的五个阶段: $\times$ 构想：确定产品构想、项目目标和控制要素、项目团队以及团队如何共同工作 $\times$ 推测：制定基于性能和/或功能的发布计划，确保交付构想的产品 $\times$ 探索：在短期内计划和提供经测试的功能，不断致力于减少项目风险和不确定性。$\times$ 适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整$\times$ 结束：终止项目、交流主要的学习成果并庆祝
【两个主要合作周期（强调周期而非流程）】
12.1.3 扩展的敏捷交付框架
12.2.1 产品构想
产品构想激励产品团队成员将各自对产品的不同观点集中成简练的、直观的简短文本格式
『把高度概括的产品信息提供给开发人员和市场人员』{$\times$ 产品的构想框 $\times$ 电梯测试声明}
『产品的基本骨架描述（OS/DB/Server，框架、功能分解结构）』{$\times$ 产品体系结构 $\times$ 指导原则}
【电梯测试声明例子】1、对于（目标客户）4、它（主要优点、引人注目的购买原因）2、谁（需要或有机会声明）5、不同于（主要的竞争产品）3、这个（产品名称）是（产品类别） 6、我们的产品（主要差别）【产品构想的主要内容】$\times$ 任务说明$\times$ 构想框图$\times$ 目标客户及其各自的需要$\times$ 电梯测试说明书$\times$ 客户满意评估标准$\times$ 主要技术和业务要求$\times$ 关键产品限制$\times$ 竞争分析$\times$ 主要财务指标
12.2.2 项目目标和约束
| 【明确项目的商业目标、质量目标和一套明确定义的性能，界定出可交付产品的范畴】【包含三个部分：项目数据表、权衡矩阵、探索系数】 项目数据表 【项目数据表用一页纸概括主要商业和质量目标、产品功能和项目管理信息，记录项目的范围和界限、表达如何根据产品构想交付项目的核心内容】【项目数据表是项目目标和约束的最少文档编制，有重要的影响】【项目数据表构成】 |
1-顾客/客户 | 2-项目经理 |
|---|---|---|
| 3-产品经理 | 4-高级主管 | |
| 5-项目目标声明 | 6-商业目标 | |
| 7-权衡矩阵 | 8-探索系数 | |
| 9-延误成本 | 10-功能一览表 | |
| 11-质量目标 | 12-性能及质量属性 | |
| 13-体系结构指导方针 | 14-问题/风险 |
其中，项目目标声明要简短，包括重要范围、进度和成本信息；权衡矩阵是确定范围、进度、成本的相对优先次序的表格；探索系数是衡量项目风险和不确定的度量标准。项目目标声明例：系统提供运动员网上自助服务，包括：场地时间表、账单、谷物费用结算，要求 14 年 6 月 30 日前上线，成本不超过 15 万美元。
12.2.3 项目社团
【项目社团的主要目标是找到合适的人员】$\times$ 具备适当的技术能力（专业技术）————能力$\times$ 表现出适当的自律行为————自律。【项目社团的误区】$\times$ 找到合适的人员意味着要找到最具天赋的、经验最丰富的人$\times$ 适当的流程可以弥补不适当的人员的问题$\times$ 严格的自律就是无情强加的纪律$\times$ 即使没有合适的人员项目也可以启动确定参与者 【项目参与者包括项目社团的任何个体和群体】【参与者分为三类】$\times$ 客户：使用产品创造价值的参与者$\times$ 开发团队成员：从事产品交付的开发人员和管理者$\times$ 利益相关方：提供监督、约束、合规活动要求和资源【参与者有三个级别】$\times$ 关键的：对项目具有特别影响力的人，可以阻止项目成功$\times$ 必需的：对项目具有特别影响力的人，可以拖延项目成功$\times$ 非必需的：感兴趣者，对项目没有直接影响【典型的项目参与者】:高级主管、高层管理者、项目领导者、产品团队、产品经理、项目团队、产品专员、开发团队、迭代经理、供应商、总工程师、政府。『参与者的群体越复杂，项目领导者在管理期望值、做关键的项目决策和防止团队不受太多方向的潜质方面花费的时间久越多，确定参与者是将各个参与者融合到项目社团的第一步』
产品团队与开发团队的交互 明确产品团队和开发团队的责任以及两个团队之间的交流是成功的关键。
其中产品团队负责“建造什么”，确定优先级开发团队负责“如何建造它”.【织内部 IT 项目失败的一个关键原因是：错误地理解了项目经理和产品经理这两个角色的本质，产品经理必须来自 IT 部门外部】【 角色具有灵活性，应根据担当角色的人进行具体的调整】
12.2.4 交付方法
【方法决定了一个团队如何执行、如何交付结果以及团队之间如何协作。方法与构想和目标同等重要】自我组织策略：重点在于决定人们如何在一起工作、如何协作以及协作的机制。{流程架构裁剪
，做法的选择和裁剪}『定义了项目团队交付某个产品将使用的方法』【团队自律的部分内容是团队就某种方法达成一致，然胡实际地应用它】【无论是未能达成一致，还是没有执行该方法都是缺乏自律的表现】自我组织策略 【自我组织策略确定了团队的沟通、协调、协作、决策，以及个体之间、团队之间的交流方法】【自我组织策略的形成需要回答一下问题】我们如何与客户协作？来自不同功能团队的项目成员如何协作？位于不同地理位置的团队如何协作？授权对我们团队来说意味着什么？谁需要在何时与谁交流？相互交谈的这些人如何决策？谁负责什么？打算用哪些方法推动上面提出的问题？流程架构与做法的选择与裁剪 【对流程组成元素、必要的过渡产物、决策的数量、文档形式进行裁剪，使之尽可能的精简，达到可以接受的最小程度】【团队讨论那些做法应该使用，哪些不应该使用，按照成员能力、项目规模、客户数量等因素进行裁剪】哪些做法是必需的？还需要哪些辅助性做法？需要对选择的做法做哪些修改？做法的编档、批准、更改需要什么手段和形式？【按照团队自身特点，塑造流程和做法】【要与过早地增加辅助性做法的趋势做斗争，只有在出现具体而重大的需要时才能增加】
构想阶段小结（12.2）
构想不仅仅是启动项目。预算、进度等都需要以清楚表达的、经过讨论并统一的构想为基础。
构想的 4 个元素：$\times$ 产品构想是什么？$\times$ 项目目标和约束是什么？$\times$ 谁应该包括在项目社团内？$\times$ 团队如何交付产品？构想需要历时，只有这样才能让项目团队各方面明确了解该构想，迭代不结束构想不会停止。
12.3 推测阶段
【推测阶段关注产品和项目，创造和理解产品结构、性能和故事功能清单以及发布计划】『推测产品和项目』==『产品功能清单』==『发布计划』【推测和计划不同】计划是对未来的猜想，我们期望实际结果与计划相符，当与计划背离时则被视为团队的错误或者是团队不够努力。推测确立目标和方向，推测对实际结果予以肯定，当它背离推测时人们会怀疑推测是否错了。
12.3.1 产品功能清单
【产品功能清单是对构想阶段制定的清单的扩充和提炼，列出产品功能】【产品功能清单由产品经理维护，随着开发阶段的演变而演变】$\times$ 构想阶段：创建初步的功能或产品细目结构。$\times$ 推测阶段：细化功能结构，为每种功能建立一张或多张故事卡。【产品团队和工程团队讨论功能的优先级，列出这些功能在发布计划中的迭代时间表】范围演变 产品范围的推动因素包括：客户价值、技术可行性、成本和关键的业务进度需要。功能应随着开发周期不断演变。$\times$ 构建最少功能策略（简化）和简单适度地适应变化$\times$ 集中于项目的主要构想和目标$\times$ 计划的重点应该放在客户关心的、易于确定优先级的功能上$\times$ 短期迭代能让开发人员精力高度集中，减少增强功能的倾向。功能与故事功能被定义为产品的一部分，向客户交付价值。$\times$ 一个完整的功能由若干条故事构成。$\times$ 故事是一个小的可交付的功能。例如：功能：信用分析师能够审查客户的信用等级。故事 1：信用分析师能够审查客户以前的付款记录。故事 2：信用分析师能够审查客户的信用机构状况。故事 3：信用分析师能够根据记录和信用报告计算客户的信用等级。敏捷项目开发中，故事是最小的开发模块。故事随时间而演变，不代表一套固定的需求。故事卡片 故事卡片提供简单的媒介，用于收集有关故事的基本信息、记录高层次的需求、开发工作估计和定义验收测试。$\times$ 故事卡片是面向客户的$\times$ 用于列出功能而非详细定义功能$\times$ 是客户和开发团队在需求讨论后达成的协议$\times$ 讨论是理解的关键，理解是估计的关键。故事卡片信息$\times$ 故事 ID 和名称$\times$ 故事描述：用一两个句子，从客户角度描述功能$\times$ 故事类型：客户领域（C）、技术领域（T）$\times$ 估计工作量：交付该故事所需工作量估计$\times$ 估计价值点：$\times$ 需求不确定性（探索系数）$\times$ 故事依赖关系$\times$ 验收测试。创建功能清单 功能清单是产品团队确定的产品特性、功能和故事的一个列表。$\times$ 功能清单上的信息包括：ID、名称、简要描述、优先级别、提示系数、估算。$\times$ 发布计划和迭代计划都会使用功能清单上的数据。
12.3.2 发布计划
【发布计划是团队在项目数据表中所描述的在项目目标和约束内实现产品构想的路线图。】$\times$ 敏捷生命周期以迭代和故事驱动，将计划和执行的主要重点从任务转变为产品功能。$\times$ 敏捷开发让团队将重点放在交付产品功能而不是中间文档产品上，中间产品与制造最终产品的实际过程并无太大关系。发布计划的主要任务是以价值和风险为基础把故事分配到迭代中。发布计划与详细迭代计划 发布计划：以故事为单位分配每次迭代的工作，与技术任务无关，产品团队可以参与到这个过程中来。详细的迭代计划：故事被拆分成技术任务供开发团队使用。第 0 次迭代 第 0 次迭代，在迭代周期内不交付客户价值，完成真正迭代开始之前的技术准备工作，其中包括：$\times$ 技术培训$\times$ 需求收集，形成文档，建立功能卡$\times$ 体系结构确立，环境准备$\times$ 定义与其他应用程序的接口【第 0 次迭代有助于团队在预期和适应之间保持平衡】第 1~N 次迭代 制定发布计划需要开发团队和产品团队共同完成以下工作：$\times$ 确定已知风险对迭代计划的影响$\times$ 确定进度目标（不考虑可实现性，只从产品管理的角度思考）$\times$ 为每次迭代编制主题$\times$ 将故事卡片分派给每次迭代，必要时平衡价值、风险资源和依赖关系$\times$ 结合故事卡片布局完整的发布计划$\times$ 运用权衡矩阵，必要时调整该计划更加精确。
12.4 探索阶段
【探索阶段旨在交付可运行的、已测试的和已验收的功能】【探索阶段关注敏捷领导如何创建自我组织和自律的团队，从而交付可发布的产品，不关注实现这一目标的技术细节】【探索阶段的核心内容包括】：$\times$ 项目管理：涉及较长时间范围的发布管理和与外围利益相关方的合作$\times$ 迭代管理：涉及短期迭代和领导功能团队制定规划和管理$\times$ 技术做法
12.4.1 敏捷项目领导
【敏捷项目领导关注增加项目价值】【项目管理应该是提供鼓舞领导，集中交付客户价值的管理】$\times$ 敏捷项目经理应该是愿景领导者$\times$ 作为一个领导者把主要精力放在项目愿景上，激发团队勇气，促进团队协作，排除项目过程中的障碍，使项目开发过程顺利进行$\times$ 不仅是项目运作的控制者，更应该成为适应性领导者$\times$ 项目经理的工作重点不是日常管理，日常管理不能够增加价值。注意：敏捷项目管理要求更高的领导技能
12.4.2 迭代计划和监督
迭代计划迭代计划和监督包括 3 个主要活动：迭代计划、工作量管理、监督迭代过程。由迭代经理负责完成，迭代结束时召开回顾会议。『制定迭代计划』【召开迭代计划会议，团队从发布计划总找出本次迭代的故事卡片，确定实现这些故事所需的技术任务和其他任务】$\times$ 所有团队成员均应参加迭代计划会议、交付故事人人有责$\times$ 迭代计划会议的时间基于项目的类型和迭代的长度【估计和任务规模】$\times$ 使用故事点的开发速度标识团队能力大小、计划要与能力匹配$\times$ 故事通常需要 2~10 天的工作量，任务不超过 8 小时【迭代长度】$\times$遵循 3 个标准：交付的价值、构建和测试、验收。迭代长度受发布时间、探索系数、准备和评审时间、学习需要影响。迭代长度应该是个常量，能够使团队保持较好节奏。『工作量管理』工作量管理涉及团队成员在迭代期间监督自己的进度，进行必要的调整，项目领导者主要是通过制定业绩目标（故事、质量目标、所需的方法）并监督其实施，不是通过制定任务进行监督管理$\times$ 敏捷领导者把任务留给团队成员自己去管理$\times$ 敏捷领导者不应是监视器，而应是帮助提供资源、信息或是技术指导的老师$\times$ 敏捷领导者需要做的是引导而不是控制、轻推而不是强迫；领导者连续干预是失败的象征『监督迭代进程』迭代经理通过与团队并肩工作和每日立会了解迭代进度团队的进度图表和故事/任务检查表对迭代精力掌握进度情况也很有帮助。仅仅通过燃尽图了解进度可能会阻碍团队的自我管理。
14.4.3 技术做法
对适应性至关重要、通用于多种类型的产品的 4 种技术做法：$\times$ 简单设计$\times$ 持续集成$\times$ 无情测试$\times$ 不失时机的重构『技术债务』【技术债务是指对不适合做法的补救成本的总和】$\times$ 常见的技术债务$\times$ 代码异味、代码复杂性$\times$ 测试债务$\times$ 文档债务$\times$ 编码风格混乱$\times$ 架构债务$\times$ 技术鸿沟 【技术债务的不断增加会直接较少对客户需求相应能力】【技术债务周期越长弥补它所需的花费就越多】『发生重大问题的危险信号：』系统加载的时间越来越长，某个模块缺陷率不断增加，相同的问题在不同的模块或者组件中出现，新的功能数量增加，引发新的 bug 数量持续增加，修复 bug 的时间越来越长，团队对某个模块或者组件抱怨很难理解或者很难测试。【技术债务常见处理方法】发现技术债务==> 吧技术债务加入产品列表==> 根据债务的影响和修改成本作优先级排序==> 在不同的迭代中分阶段修改。【处理技术债务常用的具体实践】$\times$ 在技术债务的影响和快速交付的要求之间做平衡$\times$ 尽量把最核心的技术债务在本次迭代完成$\times$ 增强架构师的角色，增强架构师和技术选择的评审（技术鸿沟和架构债务，越晚修复成本越高）$\times$ Coding show 会议，和规范不符的、编写质量较差的内容及时修改$\times$ 通过代码检查工具解决静态代码质量的问题（Stylecop，Fxcope、Gendarme 用于C#开发；Checkstyle、Findbugs、PMD 用于 Java 开发）『简单设计』简单设计就是摒弃不重要的东西将重点放在客户价值，以此来减少工作量可以节省时间更好的做事。$\times$ 简单设计并不意味着简单化的设计。提出让人理解的，适应能力强的简单设计需要额外的时间$\times$ 简单设计的目的是让工程团队基于已知知识而不是基于对未知的预测而设计$\times$ 简单设计意味着适应比预测更有价值『持续集成』持续集成的目标是在开发期间尽早、经常确保产品能组合成一个整体，从而减少以后无法组合造成的测试负担。$\times$ 集成频率越低、发现和修正问题的难度就越大，花费就越多。注意：出色的技术集成才是成功的关键。『无情测试』无情测试的目标是确保产品在整个开发过程中保持高质量$\times$ 每次迭代中越能提供可运行的、经过测试的功能，团队的工作就越有效。高绩效的团队是那些拥抱无情测试的团队。$\times$ 无情测试包括：持续进行单元测试、将质量保证和验收测试融入每次开发迭代中，让全系列的测试自动化。『不失时机的重构』不失时机的重构旨在不断地、连续地改进产品设计、让它的适应能力更强，以满足如今和未来交付客户价值这两个目标。重构的两个重要因素$\times$ 自动化测试：将测试融入开发流程中最大限度的自动化，可以减少重构破坏正在运行功能的风险$\times$ 坚持：不断投入到重构、重新设计和测试活动中，保证产品响应市场需求的变化。
12.4.4 指导和团队开发
【遵循团队规则】$\times$ 每个人都有平等的发言权$\times$ 每个人的贡献都是有价值的$\times$ 对事不对人$\times$ 在团队内保留隐私$\times$ 相互尊重、尊重分歧$\times$ 每个人都参与【自律行为】$\times$ 承担实现结果的责任$\times$ 严谨思维、面对现实$\times$ 参与激烈的交流和辩论$\times$ 愿意在组我组织的框架内工作$\times$ 尊重同事【提高团队的能力】$\times$ 使团队集中精力于提交结果$\times$ 将一群人塑造成一个团队$\times$ 开发每个人的能力$\times$ 为团队提供资源清楚路障（移山、引水）$\times$ 教导客户$\times$ 使团队的节奏保持一致
12.4.5 参与式决策
参与方式决策旨在为项目社团提供一个氛围，让其用具体的做法来限定、分析和做出项目期间的决策。决策的重点不仅仅是由谁来决定，更重要的是由谁来执行和与谁相关强调在辩论和充分参与的基础上做出可持续发展的双赢决策决策流程的 3 要素：$\times$ 决策形成：确立“谁”和这个流程有关（参与者要用共同的价值观和原则）$\times$ 做决策：确定“哪些人”如何进行决策（基于相互信任和尊重、重新构思解决问题的流程）$\times$ 决策回顾：向决策流程提供反馈
12.4.6 合作与协调
【促进团队合作与协调的敏捷做法】$\times$ 每日立会$\times$ 与产品团队的日常交互$\times$ 协调利益相关方
12.5 适应和结束阶段
敏捷项目的成功取决于得到基于现实的反馈，其适应是建立在理解大范围信息的基础之上的。【敏捷团队需要在以下 4 个方面不断评估并作出适当的改变】：产品价值。产品质量。团队绩效。项目状态。<==『强调“适应”而非“纠正”』
12.5.1 适应
敏捷项目经理注重成功地适应不可避免的变化$\times$ 适应事件比遵循计划更困难$\times$ 能向客户交付价值吗？$\times$ “生产可靠的、适应能力强的产品”这一质量目标能实现吗？$\times$ 项目在可接受的约束内进展的令人满意吗？$\times$ 对于管理层、客户、技术施加的更改要求团队做出有效回应了吗？$\times$ 团队管理层要在动态的环境中衡量成功，将实际绩效和构想与价值挂钩，不断审查绩效是否与构想一致，是否满足实际的交付价值。
12.5.2 评审及适应措施
确保在各个规模的项目中经常反馈信息并进行高水平的学习。$\times$ 在每次迭代的结束时进行评审和适应措施反省、学习和适应,改变步伐$\times$ 反省期间评审的类型，从客户团队的角度看产品的功能性，从设计及团队的角度看技术质量，团队绩效检查点，对整个项目进度的评审。【客户中心组评审】向客户中心组（由 6~10 人的客户组成）展示产品最新版本从而获得更好的反馈意见。$\times$ 鼓励参与、讨论、提问和变更请求$\times$ 参与者：客户、产品团队、和开发团队$\times$ 评审产品本身而非文档$\times$ 发现和记录需求变化。客户中心组评审与验收测试不同。确保团队不致偏离方向太远。注意：控制时间 2~4 小时。【技术评审】技术评审包括非正式的和定期安排的。为项目团队提供有关技术问题、设计问题和体系结构缺陷的反馈$\times$ 提出简化设计、连续集成、无情测试、重构等关键技术做法，确保有效执行。$\times$ 遵循简单、刚刚好、最低限度的文档、短时会议、大量相互交流等敏捷开发精神。$\times$ 2~6 个有能力评估技术的人参加，2~4 小时。$\times$ 评审产品、文件、数据等技术质量。注意：减少技术债务【团队绩效评估】团队绩效评估的原则$\times$ 自我组织原则：有效的框架应赋予团队尽可能大的灵活性和决策权$\times$ 自律原则：一旦框架取得一致同意团队成员就应遵循该框架团队绩效评估的内容$\times$ 评估交付绩效（上次迭代中我们竭尽全力了吗？（与计划无关））评估整体绩效和行为，制定改进意见$\times$ 评估团队行为（我们自己的责任履行的如何？企业的责任旅行的如何？）$\times$ 评估流程和做法：流程和做法是可调整的，没有必要去执行那些对项目目标无益的活动。【项目进度报告】项目进度报告对项目经理，产品经理，主管，利益相关方和团队本身都很有价值$\times$ 进度信息能促进对项目的控制并提高团队绩效$\times$ 有助于促进项目竞合产品经理反省进度问题报告的数量、频率和信息应与项目规模、期限和重要程度相匹配。报告主要内容有： 价值和范围状况$\times$ 质量状况$\times$ 进度和风险状况$\times$ 成本状况$\times$ 敏捷性$\times$ 项目团队信息。
12.5.3 结束阶段
结束阶段涉及的活动 $\times$ 庆祝$\times$ 对所有为该项目而努力工作的成员表示感谢$\times$ 让重要客户参加庆祝有助于宣告项目已圆满结束，具有完结之意$\times$ 清理未完成的工作$\times$ 编制最后的正是文档$\times$ 准备必要的管理报告，版本说明和财务报告$\times$ 项目评议$\times$ 为了团队之间相互学习，传递优秀的做法和失败的教训。产品是不断发展的，而项目是有限定期限的。
打赏作者
