一、软件工程概述

1、软件的概念

软件：软件是计算机系统中与硬件相互依存的另一部分。它包括程序、数据及其相关文档的完整集合。

（1）能够完成预定功能和性能的可执行指令（program）

（2）使得程序能够适当地操作信息的数据结构（data）

（3）描述程序的操作和使用的文档（document）

2、软件特点

软件的特点：

• 软件是一种逻辑实体，而不是具体的物理实体；
• 软件的生产与硬件不同；
• 在软件的运行和 使用期间，没有硬件那样的机械磨损，老化问题，但它存在退化问题，开发人员必须维护软件；
• 大多数 软件是自定的，而不是通过已有构建组装而成的；
• 软件成本相当昂贵；
• 软件本身是复杂的

3、软件危机

软件危机定义：软件在开发和维护过程中遇到的一系列严重问题。

软件危机包含两层含义：

• 如何开发软件
• 如何维护数量不断膨胀的已有软件

软件危机的表现：

1）软件开发的进度难以控制，经常出现经费超预算、完成期限拖延的现象

2）软件需求在开发初期不明确，导致矛盾在后期集中暴露，从而对整个开发过程带来灾难性的后果

3）软件文档资料不完整、不合格，由于缺乏完整规范的资料，加之软件测试不充分，从而造成软件质量低下

4）软件的可维护性差，程序错误难以改正，程序不能适应硬件环境的改变

5）软件价格昂贵，软件成 本在计算机系统总成本中所占的比例逐年上升

软件危机的原因：

1）客户对软件需求的描述不精确，可能有遗漏、有二义性、有错误，在软件开发 过程中，用户提出修改软件功能、界面、支撑环境等方面的要求

2）软件开发人员对用户需求的理解与 用户的本来愿望有差异。不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生 疏漏和错误

3）管理人员、软件开发人员等各类人员的信息交流不及时、不准确、有时还会产生误解

4）缺乏有力的方法和工具方面的支持，过分地依靠程序人员在软件开发过程中的技巧和创造性，加剧软 件产品的个性化

克服危机的途径：

1968年秋季，NATO的科技委员会首次提出了“软件工程”这个概念，目的就是为了促进软件项目的成功

4、软件工程的概念与范畴

1、软件工程：

是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上

2、软件工程研究的目标

• 软件开发成本较低
• 软件功能能够满足用户的需求
• 软件性能较好
• 软件可靠性高
• 软件易于使用、维护和移植
• 能够按时完成开发任务，并及时交付使用

3、软件生存周期

是指软件产品从考虑其概念开始到改软件产品交付使用，直至最终退役为止的整个过程。

一般包括计划、分析、设计、实现、测试、集成、交付、维护等阶段。（各个阶段可以是重叠交叉 的）

软件生存周期的各个阶段主要任务

1、计划阶段：确定待开发系统的总体目标和范围。

研究系统的可行性和可能的解决方案，对资源、成本 及进度进行合理地估算

2、分析阶段：分析、整理和提炼所收集到的用户需求，建立完整的分析模型，将其编写成软件需求规格说明和初步的用户手册

3、设计阶段（总体设计和详细设计）：设计阶段的目标是决定软件怎么做。

软件设计主要集中于软件体系结构、数据结构、用户界面和算法等方面

4、实现阶段（编码）：实现阶段是将所设计的各个模块编写成计算机可接受的程序代码

5、测试阶段：设计测试用例，对软件进行测试，发现错误，进行改正

6、 运行和维护阶段：应当在软件的设计和实现阶段充分考虑软件的可维护性。维护阶段需要测试是否正 确地实现了所要求的修改，并保证在产品的修改过程中，没有做其他无关的改动。

维护常常是软件生命 周期中最具挑战性的一个阶段，其费用是相当昂贵的

5、软件工程的三要素

软件工程的三要素：工具、方法、开发过程

6、开发模型

如何理解迭代与增量：

增量：逐块建造

迭代：反复求精

二、开启ICONIX之路

提问？

企业客户为什么会掏钱买我们的软件？

1、需求工程

需求工程：通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

需求开发：（Requirement Development ）

目的是通过调查与分析，获取用户需求并定义产品需求

方法：需求调查、需求分析、需求定义

需求管理：（Requirement Management）

目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他的工作成果的一致性，并控制需求的变量

方法：需求确认、需求跟踪、需求变更控制

需求开发的方法：

需求调查：研究文档、访谈、现场观察、问卷、原型法

需求分析：定义愿景、业务建模、用例分析

需求定义：需求规格说明书、功能需求、非功能需求

2、ICONIX过程特点

特点：

• 尽早进入编码阶段，缩短分析设计周期的软件开发方法。
• 合理地简化同一过程（RUP），基于敏捷软件开发的思想。
• 与RUP相比，是轻量级的过程。与敏捷相比，ICONIX提供充足的需求和设计文档，但不过度分析设 计。
• ICONIX过程从把需求文档编程可运作的代码过程只需四步，使用四张UML图（用例图、序列图、类 图、健壮性图）

3、描述愿景

1、愿景：

好项目是从愿景开始的，愿景是核心和起点

（老板提出愿景，花钱购买软件的目的就是要实现愿景，愿景的高度和重要性决定老板投入的力度）

2、获取愿景的三步曲：

第一步：找到软件项目的“老大”，老大就是要改善的组织中最有权力的干系人；

第二步：得到“老大”对项目的期待（愿景），软件项目的愿景是老大愿意掏钱开发这个系统的目的，并且愿景不是功能；

第三步：描述出愿景的度量指标

愿景描述不是记录具体做了什么事，而是描述改善组织的哪些指标

、

三、业务建模

1、业务建模的意义

业务建模要求我们把视角从软件系统转向客户组织，站在客户角度看问题，以达到清晰准确地“诊断”， 对症“开方”。

注意事项：

— 明确为谁服务--找准客户及其愿景，切记不是在为自己做系统；

— 要改进的组织是什么现状--有什么痛处和不足；

— 如何改进--新系统的价值就是解决客户痛处、改良客户不足，这才是客户愿意掏腰包的动力；

— 在业务建模和需求分析阶段，忘掉自己技术专家的身份。

2、业务建模的步骤

业务建模是从组织的角度来定位系统应该提供的价值。

2.1. 明确我们为谁服务（选定愿景要改进的组织）

• 选定的业务组织跟老大的职权范围有关
• 选择业务组织要结合系统愿景

2.2. 要改进的组织是什么现状（业务用例图、现状业务序列图）

1、从外部看：组织是价值的集合，用业务用例图来建模。业务用例图帮助我们从高层次了解组织的业务构成

业务用例图的组成

1、业务执行者（Business Actor）

在组织之外和组织交互的人群和组织

例如储户是银行的业务执行者，食客是餐馆的业务执行者

2、业务用例（Business Case）

组织为业务执行者提供的价值

例如银行业务用例有存款、取款、转账等；餐馆的业务用例有吃饭

3、业务用例描述

业务执行者通过业务组织的某些工作，达到固定目的。

例如取款 用例的简述为：银行客户于财神银行营业时间，到财神银行的营业厅，由银行柜员协助办理取款业务。

2、从内部看：组织是系统的集合（人被看做是一种智能系统），用业务序列图来建模。

业务序列图帮助 我们从细节上了解组织的业务流程。

采用系列图描述业务的优势

序列图以面向对象的思想来看业务流程，把业务流程看作是一系列 业务对象之间为了完成业务用例而进行的协作。

业务序列图的组成

业务序列图详细描述业务执行者、业务工人、业务实体之间如何交互，以完成某个业务用例的实现流程。

业务工人（Business worker）

位于组织内部，负责业务流程中的某些工作的人员，例如银行工作人员，医院医生

业务实体（Business Entity）

在业务用例的实现流程中，业务工人所使用的“系统”。例如银行的取款机，点钞机，学校的校园卡系统。可以与业务工人相互取代各自的职责

业务序列图的作用：

1）识别业务对象：业务执行者、业务工人、业务实体；

2）确定业务对象之间的职责、协作及交互顺序；

3)通过序列图来了解现状，为业务的优化提供依据

分支：

loop 循环

条件分支 Alt =alternative

可选分支 Opt=optional

高级话题：

1、现状序列图，想要实现的系统目前还不存在

2、在序列图中，焦点是对象之间的责任和协作，数据流是作为消息的输入输出参数存在的

3、消息名称中不用带“请求”二字，消息箭头就已经有请求的意思

4、调用消息的名字--代表责任和目的

5、只画与领域相关的系统

6、最小单位是人肉或独立智能系统

7、把时间看作特殊的业务实体

2.3. 我们如何改进（改进业务序列图）

1、发现流程中的改进点：

信息是否能自动流转？

复杂的业务逻辑是否可以封装？

职责是否可以转移？

业务对象是否可以管理？

2、步骤：

1）将“新系统”作为一个业务实体进行整体设计；

2）将“新系统”引入组织现有业务流程；

3）查看其可以改进的流程；

4）评估改进结果

3、最后进行业务建模结果复核

（1）形式：面对面会议；

（2）参会人：甲乙双方在业务建模阶段的主要参与者；

（3）被审材料：系统愿景、选定组织、业务用例、现状业务序列图、改进业务序列图；

（4）过程：需求分析师主持，介绍业务建模成果，所有参与者交流讨论，达成统一理解和确认；

（5）结论：所有参与者签字确认；

（6）目的：一是完善业务建模成果，寻找是否有遗漏或错误的地方进行修正，如果问题明显，就需要迭 代回去继续做业务建模工作；二是关键干系人在信息和意见上达成一致，并共同签字确认，作为下一阶段启动的标志。

注意：后续的工作基本不需要“老大”的参与了

四、需求分析

1、分析需求的主流方法

主流分析方法之原型法：（用户和设计交换最频繁的方法）

原型法是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环 境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。 反复进行这个过程，直到用户满意为止的一种方法。

主流分析方法之用例法：

用例图是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员实现这些元素。用例图最常用来描述系统及子系统。

2、域建模

为项目创建一个术语表。确保项目中的每个人都能以清晰一致的术语来理解和交流问题领域。

域建模[Domain Modeling]

• 域建模比普通的项目术语表优良的地方体现在：以图的方式清晰地显示出不同术语间的关系（减少理解 偏差）
• 描述业务中涉及到的实体及其相互之间的关系，是帮助系统分析人员、用户认识现实业务的工具
• 域模型图将通过不断修正完善逐步演化为最终的静态类图

域建模的步骤：

1）仔细阅读需求文档，提取出名词和名词短语

2）排除列表中重复、相似的术语

3）排除超出系统范围的术语

4）画出第一版域模型图

5）整理第一版域模型

域模型之间的关系：泛化、关联

泛化【Generalization】：一般元素与特殊元素的关系

关联【Association】：两个类之间存在某种语义上的联系

高级话题：

1、不要花费太多时间纠缠在最初的域建模工作上

2、不要把域模型错误地认为是数据模型

3、在用例分析前做域建模以避免命名混淆

4、不要指望最终的类视图和域模型图完全匹配，但它们在很大程度上应该是类似的

5、不要把与界面相关的类加入域模型中

几小时即可(包括1-2 小时小组讨论)将能够找到80%清晰无歧义的域

3、系统用例建模

1、意义

系统用例建模的意义：把视角从业务组织转向新系统，站在最终用户（不是客户）及其它干系人的角度看问题

系统用例是对（新）系统为系统执行者提供的价值的建模。

业务用例 VS 系统用例

对银行进行业务建模，研究对象是银行。用于分析现有业务的利弊

对银行的软件系统进行系统建模，研究对象是银行的软件系统。用于分析新系统带来的价值

4、系统用例建模步骤

步骤：

1、 绘制系统用例图

2、编写系统用例描述

3、更新域模型

步骤一 绘制系统用例图

步骤：

（1）确定系统边界

1、系统边界，即系统包含的功能与不包含的功能之间的界限。

2、通俗来说就是分割出系统外和系统内

（2）识别系统执行者

执行者是在系统之外，透过系统边界，与系统进行有意义交互的任何事物（人、系统、硬件设备、时间）

（3）识别系统用例

再谈用例（注意：这里指的是系统用例，关注点有业务组织转向系统）

系统用例是系统执行的一系列动作，这些动作可以生成“执行者”可观测的有价值的结果

通俗讲，系统 用例是执行者通过系统可以达到的某个目标

用例命名必须是动宾短语。所有用例应该都能追溯到愿景目标，所有的愿景目标都应有对应的用例实现。

（4）确定用例间的关系

泛化【Generalize】（继承）

包含【Include】

扩展【Extend】

思想：从现有的用例中抽取出公共的那部分信息，作为一个单独的用例。然后通过不同的方法来重用这个公共 的用例，以减少模型维护的工作量。

高级话题：

1、先发现执行者，才能从执行者的角度去寻找用例

2、执行者与重要性无关

3、“时间”执行者

4、用例 ≠ 功能

5、用例 ≠ 步骤

6、如何处理登录？

7、如何处理用例的“四轮马车”

8、用例与愿景目标

所有用例应该都能追溯到愿景目标

所有的愿景目标都应有对应的用例实现

9、用例分包

当存在大量用例是可以对用例进行分包

10、不要滥用用例关系

 步骤二 编写系统用例描述

1、用例描述的作用

系统用例图描述总体，系统用例文档描述细节

每个用例都必须对应有系统用例描述

用例描述基本组成：

干系人利益

基本路径（主语只能是执行者或系统，格式为名词+动词+名词）

扩展路径

业务规则

干系人利益：

用例体现干系人利益的平衡点

基本路径：

客户最想看到的、最关心的路径核心的核心

扩 展路径：

系统要处理的以外和分支

常见的拓展点：

系统验证、步骤失败、执行者的选择

业务规则

高级话题：

1、不要涉及页面细节

2、基本和扩展分开

3、不能假想系统不能负责的事情

4、辅助执行者（系统请求XXX做某事）

5、完整的用例文档

6、前置条件和后置条件

7、字段列表

8、设计约束

步骤三 更新域模型

在用例分析结果的基础上，对早期的域模型进一步完善和调整。

5、非功能性需求分析及需求定义与评审

功能性需求：通俗来讲就是系统可以做什么

非功能性需求：通俗来讲就是系统可以把某项功能做到什么程度

人无我有，人有我优

非功能性需求：（RUPS）

1）可靠性【Reliability】：系统在一定时间内、在一定条件下无故障地执行指定功能的能力。

2）可用性【Usability】：一个产品可以被特定的用户在特定的上下文中，有效、高效并且满意得达成特定目标的程 度。

3）性能【Performance】：系统实现预期功能的能力的特性。

4）可支持性【Supportability】：系统在故障解决和系统升级方面的能力。 需求描述两大原则：简介、段落文字少；列表、图表相结合。

6、需求评审

三种相对正式的评审：审查、小组评审、走查

三种相对不正式的评审

结对编程：（/需求分析/设计/测试）

轮查：交叉交换文档产物，互相提出意见

临时评审：在日常沟通中做回顾确认。例如和用户沟通时，对沟通内容做总结，请用户确认理解是否一致

7、小结

需求分析就是确定新系统的目的、范围、定义、和功能

域建模用来生成统一的关键术语表

用例建模用来定义系统的功能性需求

系统的非功能性需求通常包括RUPS

需求评审确定需求分析的结果，然后才能进入设计阶段

五、 健壮性分析

连接分析与设计（承上启下，非必要）

1、健壮性分析的优点

用例的对象化图示，将用例和对象链接起来；

指出了参与用例场景的对象相互之间 如何交互；

确保用例文本的正确性，从而提供了健康性检查；

确保用例考虑了所有必需的扩展路径，从 而提供完整性和正确性检查；

让你能够(持续)发现对象；

缩小分析和设计的鸿沟，从而最终完成初步设计

2、健壮性分析中的基本概念

健壮性分析的三种元素：边界类、实体类、控制器类。

边界类【Boundary objects】：与用户交互的对象，系统和外部的世界的界面，如窗口，对话框等等

实体类【Entity objects】:是现实世界存在的实体对象，域建模中的类，它通常对应于数据库表中和文件。有些实体对象是“临时”对象（如搜索结果），当用例结束后将消失

控制器类【Controller objects】：边界和实体类的“粘合剂”，将边界对象和实体对象关联起来，它包含了大部分的应用逻辑，在用户和对象之间架起一座桥梁。控制对象中包含经常修改的业务规则和策略

3、健壮性分析的步骤

步骤：

1）创建空健壮性图

2）将用例描述关联到健壮性分析图上（方便同步更新）

3）从基本流程的第一句话开始画

4）贯穿画完用例基本流程

5）画出所有扩展流程

4、高级话题

1、如果类似的控制器类，可以缩成一个

2、完善用例描述

5、健壮性分析的九条指导建议（不重要）

1）将用例描述关联到健壮性图上

2）从域模型中提取实体对象，如果发现之前有缺漏，则补充上

3）在画健壮性图时修正之前用例中模糊的地方

4）将每一个屏幕对象定义为边界对象，并进行清晰的命名

5）切记控制器对象大部分时候对应的是逻辑操作方法，偶尔也会对应真实的控制器对象

6）在画健壮性图时，如果调用另一个用例，就直接在图上画出调用此用例即可

7）切记健壮性分析描绘的是概要设计而不是详细设计

8）健壮性图上的边界对象和实体对象会转化为时序图中的对象实例，而控制器对象会转化为消息或控制 器实例

9）切记健壮性图是用例的“对象化图示”，它的目的是优化和完善用例文本和域模型

6、基于健壮性分析更新域模型

思考：健壮性分析在什么情况下可以不做？

1、有丰富的类似项目经验

2、熟悉业务细节

六、关键设计

1、关键设计的意义和方法

关键设计的方法：

基于用例图、用例描述和健壮性图，采用序列图来描述参与者、边界、实体之间的交互。

关键设计的意义：

就是要通过寻找对象之间的交互关系，进而进行方法（操作或行为）分配。

序列图的要素：

每一个箭头都是一个方法

类图和序列图的映射，类图中的每一个方法都可以作为序列图中的方法

消息的传入：类对象所具有的操作--责任

消息的传出：类对象完成操作所需要合作--协作

练习：

2、关键设计的步骤

步骤：

1）将现有的域模型直接作为第一版静态类模型；

2）基于用例描述和健壮性分析结果，画出每个用例的序列图

• 健壮性图中的控制类会转化为方法
• 如果也转化为控制器类，那么就添加类图中（一般边界类不添加到类图中）

3）整理静态类图和序列图；

4）关键设计复核，迭代更新用例图、类图和序列图

步骤一、形成第一版静态类图

步骤二、画出每个用例的序列图

1、逐步贯穿健壮性图上的每一个控制器，每次一个，画出序列图上的相应方法，然后核对，移至下一个控制器

2、控制器和方法之间并不一定是完全一对一匹配的，也可能会转化为两个或多个方法

3、有时，控制器也可能转换位一个真正的控制类

4、序列图会对类图做出进一步的更新，完善其方法

决定控制器分配给哪个类？

高内聚，低藕合。是判断设计好坏的标准

高内聚：是指一个软件模块(类)是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。
低耦合：是指一个软件模块与模块之间的接口，尽量的少而简单。如果某两个模块间的关系比较复杂的话，最好首先考虑进一步的模块划分，降低相互的依赖。这样有利于修改和组合。
目的:  使得模块的“可重用性”、"移植性”大大增强

完成所有用例序列图后的类图：

高级话题：

1、简单扩展点：可以合并到基本路径上

2、复杂扩展点：单独一张图，在基本路径图引用，Include、Extend 用例也适用

3、循环

4、画序列图的注意事项

• 箭头代表责任分配而非数据流动
• 画方法的同时将方法分配给类，反复核对类图，确保所有的方法分给适当的类
• 不要花费太多的时间在控制焦点上
• 不要把序列图画成流程图

步骤三、整理静态类图和序列图

步骤四、关键设计的复核

七、 详细设计

1、详细设计的目标和任务

关键问题：怎样具体地实现这个系统。

技术架构及相关考虑

• 选择开发语言
• 网络拓扑及安全
• 体系结构
• 硬件支持环境
• 软件支持环境
• 数据存储设计
• 交互设计

2、 详细设计范例

结合体系结构、编程语言、数据模型和设计模式等来细化类图；

调整序列图（为了清晰易读，可以考虑 去掉执行者和界面层的部分，因为这部分没有复杂的逻辑）

组件图

组件图（component diagram）是用来反映代码的物理结构。可以了解各软件组件之间的编译器和运行时依赖关系。组件图可以将系统划分为内聚组件并显示代码自身结构。

描述如何把设计的类分配给不同实体组件。

部署图

部署图（deployment diagram，配置图）是用来显示系统中软件和硬件的物理架构。从部署图中，可以了解软件和硬件组件之间的物理关系以及处理结点的组件分布情况。使用部署图可以显示运行时系统的结构，同时还传达构成应用程序的硬件和软件元素的配置和部署方式。

3、关键设计复核

参考关键设计复核

之后就是编码、测试、部署、维护、升级。

八、Scrum敏捷开发

1、初识Scrum

传统软件开发过程的常见症结：

交付周期长；害怕需求变更；中间过程不可控；测试周期被一缩再缩； 最终结果差强人意。

敏捷软件开发模式：

敏捷开发的核心思想是以用户的需求进化为核心，采用迭代、循序渐进的方法进行 的软件开发。

由传统迭代式软件开发模式发展而来，强调产品价值、团队协作、客户参与、先期验收、 简化流程、拥抱变化。

总结和吸收成功软件项目研发的最佳实践；与现代管理思想相辅相成。

1.1、敏捷宣言（重点）

个体和交互 胜过 过程和工具

可以工作的软件 胜过 面面俱到的文档

客户合作 胜过 合作谈判

相应变化 胜过 遵循计划

虽然右项也具有价值，但我们认为左项具有更大的价值

1.2、敏捷 = 理念 + 优秀实践 + 具体应用

敏捷包括三个层次：

1）理念（敏捷核心思想）

value：聚焦客户价值，消除浪费

team：激发团队潜能，加强合作

adapting：不断调整以适应变化，软件具有复杂性、一致性、可变性和不可见性

2）优秀实践（敏捷的经验积累） 业界敏捷优秀实践概览

3）具体应用（能够结合自身灵活应用才是真正敏捷） 因地制宜选择适合的敏捷实践

2、敏捷过程

2.1、Scrum敏捷开发过程概述

Scrum是一个增量的、迭代的敏捷开发过程。

迭代式开发

迭代开发将整个软件生命周期分成多个小的迭代（一般2-6周）

每一次迭代都由需求分析、设计、实现、测试和集成在内的多个活动组成

每一次迭代都可以生成一个稳定和被验证过的软件版本

产品增量

迭代开发是有节奏地小步快跑，但建立在坚实的质量基础上

迭代式开发的好处：

• 通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险
• 通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的 需要
• 通过小批量减少排队，提供更灵活、快速的交付能力
• 平滑人力资源的使用，避免出现瓶颈

Scrum敏捷开发过程：

1）项目整个开发周期包括若干个小的迭代周期，每个迭代周期称为一个Sprint， 每个Sprint的建议长度2到6周

2）使用产品Backlog来管理项目的需求，产品Backlog是一个按照商业 价值排序的需求列表，体现形式通常为用户故事

3）团队从产品Backlog中挑选最有商业价值的需求， 经过Sprint计划会议上的分析、讨论和估算得到任务列表，称为Sprint Backlog

4）在每个迭代结束 时，Scrum团队将交付潜在可交付的产品增量

2.2、Scrum敏捷开发涵盖内容

2.3、Scrum敏捷团队组成

敏捷团队包括三个核心角色：

PO（product Owner 产品负责人）

Scrum Master（Scrum 教练）

Team（开发团队）

PO的特征：

1）领域能力：有预见性、知道有些事是无法预见的、具备业务和领域专长

2）人际交往能力：和利益干系人关系好、促成谈判/达成一致意见、良好的沟通能力、有正能量会激励人

3）策力：得到授权，可以指定决策、关键时刻敢于拍板、有决断力、从经济的视角权衡业务或技术问题

4）责任心：承担产品责任、参与并随时可以到场、充当Scrum团队成员

SM的特征：

见多识广、善于提问、有耐心、有协作精神、保护团队、公开透明

开发团队的特征：

自组织、跨职能的多样化和全面化、T型技能、火枪手态度、高带宽沟通（广泛）、透明沟通、团队规模 适中、专注、有责任感、工作节奏可持续、团队成员稳定。

完整团队（特种兵小组）：

什么是完整团队：

以Story为单位的持续交付要求系统组、开发和测试等跨功能团队进行密切协同，相互独立的功能团队难以应对。

完整团队是跨功能领域（需求分析师、设计师、开发人员、测试人员等）的人员组成一个团队，坐在一起工作，团队成员遵循同一份计划，服从于同一个项目经理。

完整团队的好处：

1）有助于团队成员形成共同目标和全局意识，促进各功能领域的拉通和融合；

2）通过面对面沟通提升沟通效率；

3）实现团队成员的高度协同，支撑持续地、短周期的交付。

完整团队的关键要点：

1）成员来自多功能领域：团队拥有完成目标所需的各职能成员；

2）坐在一起办公：团队成员无障碍地沟通；

3）团队保持相对稳定：临时组建的团队生产效率较低，团队稳定非常关键；

4）T型人才，背靠背精神：每个成员都一专多能，工作上互助互补。

2.4、Scrum敏捷工作件

2.4.1、Product Backlog 产品Backlog

Product Backlog：经过优先级排序的动态刷新的产品需求清单，用来制定发布计划和迭代计划。

产品Backlog的好处：

• 通过需求的动态管理应对变化，避免浪费
• 易于优先交付对用户价值高的需求

产品Backlog关键要点：

清楚表述列表中每个需求任务对用户带来的价值，作为优先级排序的重要参考

动态的需求管理而非“冻结”方式，PO持续地管理和及时刷新需求清单，在每轮迭代前，都要重新筛选出 高优先级需求进入本轮迭代

迭代的需求分析过程，而非一次性分析清楚所有需求。（只对近期迭代要做的需求进行详细的分析，其他的需求停留在粗颗粒）

2.4.2、Product Backlog Item 产品功能列表

按优先级排序的预期产品功能集，通常组成包括：特征、缺陷、技术工作、知识获取。

好的产品功能列表具备DEEP特征：

1）详略得当。马上要做的在顶部，工作量小，内容非常详细，可以在最近的一个冲刺实现。近期不打算做的放在底部，工作量大，内容粗略

2）涌现的。根据不断涌入、具有经济价值的信息持续更新，适应变化。产生涌入的原因：客户的新想 法、竞争对手的行动、意外的技术问题等。

3）做过估算。每个条件都做过大小估算（就是完成这个条目需要的工作量，用故事点或理想天数表 示）。顶部的详细精确，底部的可以用L、XL等表示。

4）排列了优先级。最近几个冲刺，排好顺序，后续的先不排。如果有新条目出现，插入队列（原则上不插入当前冲刺）

2.4.3、Sprint Backlog 迭代Backlog

什么是迭代Backlog

• 迭代Backlog是团队在一轮迭代中的“任务”清单，是团队的详细迭代开发计划；
• 当团队接收从产品Backlog挑选出要在本轮迭代实现的需求时，召开团队迭代计划会议，将需求转化为具体的“任务”
• 每项 任务信息包括当前剩余工作量和责任人

迭代Backlog的好处

• 将需求分解成更细小的任务，利于对迭代内进度进行精确控制
• 剩余工作量可用来 实时跟踪团队当前进展。

迭代Backlog的关键要点

• “任务”由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工 作都可以列为任务；
• 任务要落实到具体的责任人；
• 任务粒度要小，工作量大于两天的任务要进一步分解；
• 用小时做为任务剩余工作量的估计单位，并每日重估计和刷新。
• 

2.4.4、Definition of Done 完成标准

什么是完成标准

完成标准是基于“随时可向用户发布”的目标制定衡量团队工作是否已完成的标准，由团队和PO形成共识

完成标准的好处

• 共同协商的完成标准是团队的自我承诺，团队会更认真
• 用于准确评估团队工作进展
• 清晰和明确的完成标准保证了每次迭代是高质量的

完成标准确保团队每一步前进都奠定在坚实的质量基础之上

完成标准的关键要点

• 团队自协商：团队根据项目实际情况来定义完成标准，并严格遵守
• 有层次：一 般分为三个层次：Story级别，迭代级和发布级，每个级别都有各自的完成标准
• 

2.4.5. Task kanban Board 任务看板

2.4.6. Burn Down Chart燃尽图

2.5. Scrum会议及过程实践

2.5.1、迭代计划会议

什么是迭代计划会议

每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品backlog，输出是团队迭代backlog。

迭代计划会议内容

1）澄清需求、对“完成标准”达成一致

2）工作量估计、根据团队能力确定本轮迭 代交付内容

3）细化、分配迭代任务和初始工作计划。 迭代计划会议由团队共同确定迭代交付内容和完成标准

迭代计划会议的好处

• 通过充分讨论，使团队成员对任务和完成标准理解一致
• 团队共同参与，促进团 队成员更认真对待自己的承诺

迭代计划会议的关键要点

1）充分参与：Scrum Master确保PO和Team充分参与讨论，达成理解一 致；

2）相互承诺：Team承诺完成迭代Backlog中的需求并达到”完成标准“，PO承诺在短迭代周期不增 加需求；

3）确定内部任务：Team和PO协商把一些内部任务放入迭代中（例如重构、持续集成环境搭建等），由PO考虑并与其他外部需求一起排序 。

2.5.2、 迭代执行

迭代执行包含规划、管理、执行和沟通工作，以确保创建可工作的、经过测试的特性。

2.5.3、每日站立会议

什么是每日站立会议

每日工作前，团队成员的例行沟通机制，由Scrum Master组织，Team成员全体站立参加

聚焦在下面 的三个主题

• 我昨天为本项目做了什么？
• 我计划今天为本项目做什么？
• 我需要什么帮助以更高效的工作？

每日站立会议的好处

• 增加团队凝聚力，产生积极的工作氛围
• 及时暴露风险和问题；促进团队内成员 的沟通和协调

每日站立会议的关键要点

• 准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯
• 高效会议：会议限时15分钟，每个人都保持站立，依次发言
• 问题跟踪：Scrum Master应该记录下来所 有的问题并跟踪解决

2.5.4、迭代评审会

什么是迭代验收

• 每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求
• 由Scrum Master组织， PO和用户代表（外部或内部利益相关人）负责验收、Team负责演示可工作软件

迭代验收的好处

• 通过演示可工作的软件来确认项目的进度，具有真实性
• 能尽早的获得用户对产品的 反馈，使产品更加贴近客户需求

迭代验收的关键要点

• 展示“真实”的产品：Team 应在真实环境中展示可运行的软件，判断是否达到“完 成”标准
• 收集反馈：PO 根据验收情况及客户反馈意见，及时调整产品Backlog

迭代评审准备工作

1）确定邀请谁参加：团队、内外部干系人

2）安排活动日程：最好固定时间和地 点，形成规律，通常2~4小时

3）确认迭代工作已经完成：由PO确认

4）为演示做准备：以演示成果 为主，减少PPT演讲

5）确定谁做什么：通常SM组织、PO主持，团队代表演示，每一次让不同的团队成员演示

2.5.5、迭代回顾会议

什么是迭代回顾会议

在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步

围绕如下三个问题

• 本次迭代有哪些做得好
• 本次迭代我们在哪些方面还能做得更好
• 我们在下次迭代准备在哪些方面改进

迭代回顾会议的好处

• 激励团队成员；帮助团队挖掘优秀经验并继承
• 避免团队犯重复的错误
• 营造团 队自主改进的氛围

迭代回顾会议的关键要点

• 会议气氛：Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题， 共同分析根因
• 关注重点：Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）
• 会议结论要跟踪闭环：可以放入迭代backlog中

迭代回顾准备工作

1）定义回顾重点：可以是对整个过程的回顾，也可以有所侧重点，例如：如何提高 团队的TDD能力

2）选择练习活动：建立并挖掘迭代事件的时间线、通过头脑风暴获得见解、将获得的 见解进行分组并投票表决

3）收集客观数据：未完成的PBI数量、燃尽图特征等

4）安排回顾日程： 最好固定时间和地点，形成规律，通常2~4小时

3、总结

Scrum的组成

三个角色

产品负责人、敏捷教练、团队

四个会议

迭代计划会议、每日站会、迭代评审会议、迭代回顾会议

三个产物

Product Backlog、Sprint Backlog、燃尽图

Scrum的特点

适用于在不确定性高的环境中开发复杂产品

简洁但有效

• 易于学习和掌握
• 能够在开发过程中不断检查，并作出相应调整

项目信息对所有干系人高度透明

便于快速发现问题，促使团队和组织持续改进

九、敏捷工程实践

敏捷工程实践技术

用户故事、结对编程TDD、持续集成、CodeReview、发布规则

1、用户故事

什么是用户故事

• 用户故事是一个用来确认用户和用户需求的简短描述。
• 典型的描述句式为：作为一个XXX，我需要XXX功能，能够带来XXX好处。
• 用户故事是站在用户角度描述需求的一种方式
• 每个用户故事须有对应的验收测试用例
• 用户故事是分 层级的，在使用过程中逐步分解细化

用户故事的好处

• 站在用户视角便于和客户交流，准确描述客户需求；
• 用户故事可独立交付单元、规模 小，适于迭代开发，以获得用户快速反馈；
• 用户故事强调编写验收测试用例作为验收标准，能促使需求 分析人员准确把握需求，牵引开发人员避免过度设计。

用户故事的关键要点

• I – Independent，可独立交付给客户
• N – Negotiable，便于与客户交流
• V - Valuable ，对客户有价值
• E - Estimable ，能估计出工作量
• S - Small ，分解到最底层的用户故事粒 度尽量小，至少在一个迭代中能完成
• T - Testable，可测试

用户故事特征

体现客户价值，轻量级的点位符

遵循3C原则

卡片（Card）：作为XX，我希望XXX，这样可以XXX

对话（Conversation）：不描述到细节，由团队通过持续对话细化，激发大家的深度理解。

用户故 事经过会话确认后，才能正式进入开发阶段（用户故事实现）。敏捷开发的流程完整体现了用户故事（需求）的流转过程。

确认（Confirmation）：有明确的验收标准。

• 用户故事的确认由测试人员完成
• 测试报告是对用户 故事实现程度的最直接体现

用户故事大小级别

史诗故事（1-2个月）

特性故事（1-2周）

冲刺故事（1-2天）

任务（几个小时）：可分工执行

第一层为月度级别，即史诗级别。 

第二层为星期级别，大于一个冲刺，也称为特性。

第三层为天级别，冲刺就绪。

底层为小时级别，是具体的任务（任务并不是故事，比如强调的是如何构建不少构建什么）。

INVEST标准

独立性（Independent）：故事之间松耦合，具有独立性，不应该依赖于其他的用户故事

可协商（Negotiable）：开始仅用于做占位符，逐步细化

有价值（Valuable）：用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写

可估算（Estimatable）：设计、开发、测试团队可估算工作量和成本。（不可估算的原因：太大 需要分解，或信息不全需要进一步探索）

短小（Small）：故事应该尽量的短小（如两周冲刺，故事一般是2天以内的）

可测试（Test）：有相应测试验收标准

2、结对编程

什么是结对编程

• 两位程序员在一台电脑前工作，一个人输入代码，另一个人实时检视每一行代码
• 输入代码的人被称为“驾驶员”，负责实时评审和协助的程序员称作“领航员”
• 领航员检视的同时还负责考虑下一步的工作方向，如可能出现的问题以及改进等

优点

• 提升代码和产品质量
• 有效减少BUG。研究表明结对生产率比两个单人总和低 15%，但缺陷数少 15%，考虑修改缺陷工作量和时间都比初始编程大几倍，所以结对编程总体效率更高；
• 降低学习成本， 促进团队能力提升和知识传播

缺点

• 对于有不同习惯的编程人员，坐在一起工作可能会产生矛盾
• 两个人一起工作可能会出现工作精 力不能集中的情况

结对编程的关键要点

• 程序员应经常性地在“驾驶员”和“领航员”间切换，保持成员间平等协商和相互理解，避免出现一个角色支配另一个角色的现象
• 开始新Story开发的时候即可变换搭档，以增进知识传 播
• 培养团队成员积极、协作的心态能够增进结对编程效果
• 实施初期需精心辅导，帮助成员克服个性 冲突和习惯差异

3、测试驱动开发（TDD）

什么是测试驱动开发

• TDD以测试作为编程的中心，它要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的 代码要通过用例，并不断进行重构优化
• TDD要求测试可以完全自动化运行

驱动测试开发的好处

• 和代码同步增长的自动化测试用例，能为代码构筑安全网，保证代码重构的质量
• TDD有助于开发人员优化代码设计，提高代码可测试性

测试驱动开发的关键要点

• 测试代码和源代码一样都需要简洁，可读性好
• 测试用例的设计要保证完 备，覆盖被测单元的所有功能
• 每个测试用例尽量保持独立，减少依赖，提高用例的可维护性
• 当功能单元较大时，为降低难度，可分解为多个更小的功能单元，并逐一用 TDD 实现

4、持续集成（CI）

什么是持续集成

持续集成，指团队成员经常集成他们的工作，通常每人每天至少集成一次每次集成都通过自动化的构建 （包括编译，发布，自动化测试）来验证。

持续集成的好处

• 大幅缩短反馈周期，实时反映产品真实质量状态
• 将集成工作分散在平时
• 尽早发现 集成错误，避免产品最终集成时爆发大量问题

持续集成的关键要点

• 持续集成强调 “快速”和“反馈”，要求完成一次系统集成的时间尽量短，并提供完备且有效反馈信息
• 自动化测试用例的完备性和有效性是持续集成质量保障
• 修复失败的构建是团队 最高优先级的任务
• 开发人员须先在本地构建成功，才可提交代码到配置库
• 持续集成的状态必须实时 可视化显示给所有人
• 大系统持续集成需分层分级，建立各层次统一的测试策略

5、产品发布规则

6、Code Review

代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。

好处

• 代码复查者(reviewer)能从他们的角度来发现问题并且提出更好的解决方案
• 公开reviewer和被 复查者的想法和经验能够促进团队间的知识的分享
• 通过给新员工看有经验的开发者的代码能够提高他 们的水平
• 能够鼓励开发者将工作进行的更彻底，因为他们知道代码将被其他的人阅读

审查的内容

• 码规范问题：命名不规范
• 代码结构问题：重复代码、巨大的方法和类、分层不 当、紧耦合
• 工具、框架使用不当：Spring、Hibernate、Ajax
• 实现问题：错误验证、异常处 理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不好、扩展性不佳
• 测试问题：测试 覆盖度不够、可测试性不好

EA部分请观看我主页的其他部分