一、软件工程概述
1.软件工程三要素
- 工具【系统】
EA
Axure RP
墨刀 - 方法【技能】
业务建模分方法（组织用例图、业务序列图…UML）
需求方法（系统用例识别和书写规约）
项目管理方法
配置管理方法 - 开发过程【框架】
关键是对核心活动的选取和定义，业务建模（分析业务过程中发现软件的价值）、需求（使开发人员和用户就“系统做什么”达成共识）、分析、设计（用来保证系统的功能和性能）、实施、发布
2.瀑布模型
需求分析、需求定义、概要设计、详细设计、实现、系统测试、验收测试、维护
3.RUP【统一软件过程】的中心思想是
用例驱动、架构为中心、迭代和增量
4.Scrum敏捷过程
由产品负责人建立产品功能列表，在迭代计划会上，产品负责人讲解迭代任务，团队在迭代内完成所列需求，每日都需要召开每日站立会议，完成迭代，在迭代终点召开迭代评审会展示开发成果
5.迭代与增量
- 增量：模块建造
- 迭代：反复求精
6.UML统一建模语言
- 使用的目的：主要用于交流、有利于清晰、有利于精确
- 用途：
①分析阶段：用例图、活动图
②观察对象交互：交互图
③设计阶段：类图
④观察对象所处状态不同时的行为差异：状态图
⑤配置阶段：部署图 - 分类：
①静态图：
类图【模型化系统的结构】、对象图【对象及对象间的相互关系】、组件图【模型化组件的组织和依赖】、部署图【模型化系统的硬件分布】
②动态图：时序图【模型化系统的行为】、协作图【模型化系统的行为】、状态图【模型化状态相关的方面】、活动图【模型化系统内的事件流】、用例图【模型化系统与外界的交互】
二、踏上ICONIX软件过程之路
7.需求工程
- 需求开发的目的是通过调查与分析，获取用户需求并定义产品的需求。其中包括需求调查、需求分析、需求定义
- 需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。其中包括需求确认、需求跟踪、需求变更控制
8. 需求调查的手段
研究文档、访谈、现场观察、问卷、原型法
从需求调查到需求分析
老板：定义愿景
中层经理：业务建模
一线员工：用例分析
9.Iconix
- 过程总览
- 过程特点
①尽早进入编码阶段，索顿分析设计周期的软件开发方法
②合理的简化统一过程(RUP),基于敏捷软件开发的思想
③与RUP相比，是轻量级的过程。与敏捷相比，ICONIX提供充足的需求和设计文档，但不过度分析设计
ICONIX过程从把需求文档变成可运作的代码只需要四步，使用四张UML图【用例图、序列图、类图、健壮性图】
10.获取愿景
- 获取愿景的三部曲
①找到软件项目的“老大”
②得到“老大”对项目的期望（愿景）【愿景不是功能】
③描述出愿景的度量指标【买了这个系统对组织有什么好的用处】 - EA构建愿景
三、业务建模，精准了解客户
11.业务建模
- 意义：业务建模要求我们把视角从软件系统转向客户组织，站在客户角度看问题，以达到清晰准确地“诊断”，对症“开方”
①明确为谁服务-找准客户，切记不是在为自己做系统
②要改进的组织是什么现状-有什么痛处和不足
③如何改进-新系统的价值就是解决客户痛处、改良客户不足，这才是客户愿意掏腰包的动力 - 步骤
①明确我们为谁服务（选定愿景要改进的组织）
②要改进的组织是什么现状（业务用例图、现状业务序列图）
③我们如何改进（改进业务序列图）
12.业务用例图
组成：
①业务执行者：在业务组织之外，预期交互，享受其价值的人或组织
②业务组织：业务组织为业务执行者提供的价值
③业务用例：【的撰写】业务执行者通过业务组织的某些工作，达到固定目的
13.业务序列图
- 概念：业务序列图帮助我们从细节上了解组织的业务流程
- 优势：序列图以面向对象的思想来看业务流程
- 组成：业务执行者、业务工人、业务实体之前如何交互，已完成某个业务用例的实现流程。
- 注意：
①消息的名字–代表责任和目的
②消息的方向–责任委托，不是数据流
最小的单位是人或则独立智能系统
14.序列图中常用分支的画法
- 循环loop
- 条件分支Alt
- 可选分支Opt
15.改进的业务序列图【就是将人换做了要做的系统】
- 步骤
①将新系统作为一个业务实体
②将其引入组织现有业务流程
③查看其可以改进的流程
④评估改进结果 - 好处：
通过改进业务序列，可以提前模拟出新系统的出现，将对组织线性的业务流程造成哪些影响，可以提前评估新系统的可行性或提前进行相应的准备工作，实现安全平稳的组织改进
16.业务复核方法-面对面会议
目的：完善业务建模成果，寻找是否有遗漏或错误的地方进行修正，如果问题明显，就需要迭代回去继续做业务建模工作
联系干系人在信息和意见上达成一致，并共同签字确认，作为下一阶段启动的标志。
四、需求分析，用例分析法
17.需求分析的主流方法
- 原型法：按照用户的需求定义，快速的交付一版，用户试用、补充后再进行新版本的开发，反复进行，最后得到用户满意的版本
- 用例法：是由软件需求分析到最终实现的第一步，以用户的角度分析用户如何使用一个系统，展示关联，最终实现。最常用来描述系统及子系统。
18.域模型
- 意义：
①为项目创建一个术语表，确保项目中的每个人都能以清晰一致的术语来理解和交流问题领域
②域模型比普通的项目术语表优良地方体现在：以图的方式清晰地显示出不同术语间的关系
③域模型图将通过不断修正完善逐步演化为最终的静态类图 - 步骤
①仔细阅读需求文档，提取出名词和名词短语
②排除列表中重复、相似的术语
③排除超出系统范围的术语
④画出第一版域模型图
⑤整理第一版域模型 - 关系
①泛化：一般元素和特殊元素的关系
②关联：两个类之间存在着某种语义上的联系
- 高级话题：
①域模型的迭代
②域模型和数据模型的区别
1)域模型：是分析模型是，是由系统分析员、用户认识现实业务的工具，描述业务实体及相互之间的关系，域模型在设计期间不用考虑数据存放问题，只考虑业务描述中涉及的实体以及实体之间的关系
2)数据模型：是系统设计、实现的一部分，描述的是对用户需求在啊数据机构上的实现
③域模型的重要原则
1)不要花费太多的时间，纠缠在最初的域模型工作上
2)不要把域模型错误地认为是数据结构
3)在用例分析前做域模型，以避免命名混淆
4)不要指望最终的类视图和域模型图完全匹配，但它们在很大程度上应该类似
5)不要把与界面相关的类加入与模型中
19.系统用例建模
- 意义
①系统需求分析的目的就是把视角从业务 组织转向新系统，站在最终用户及其他干系人的角度看问题
②系统用例是对新系统为系统执行者提供的价值的建模
- 业务用例和系统用例的区别
①业务用例是对银行进行业务建模，研究对象是银行，用于分析现有业务的利和弊
②系统用例是对银行的软件系统进行系统建模，研究对象是银行的软件系统，用于分析新系统所带来的价值
20.系统用例图
- 组成部分
- 步骤
①绘制系统用例图
1)确定系统边界：
a.系统边界：是系统包含的功能和不包含的功能之间的界限，通俗来说就是分隔出系统内和系统外
b.系统内：需要投入大量精力进行建设
c.系统外：需要我们考虑与它们的接口
2)识别系统执行者
a.执行者：是系统之外，透过系统边界，与系统进行有意义交互的任何事物
b.主执行者：用例发起者，用例为其实现价值的目标
c.辅执行者：用例支持者，用例的完成需要与其交互，得到其支持
3)识别系统用例
a.系统用例是系统执行的一系列动作，这些动作可以生成“执行者”可观测的有价值的结果，系统用例是执行者通过系统可以达到的某个目的。例如：银行客户的系统用例是取款
4)确定用例间的关系
用例之间的关系：
a)泛化：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系
b)包含:使用包含用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基用例复用
c)扩展：将基用例中一段相对独立并且可选的动作，用扩展用例加以封装，再让它从基用例中声明的扩展点上进行扩展，从而使基用例行为更简练和目标更集中
5)高级话题
a.先发现执行者还是先发现用例？
执行者比用例明显；执行者的个数远比用例的个数少；找到一个执行者，就可以找到一堆用例；执行者是系统外部人物代表，所以当然是要先找到执行者，才能够从执行者的角度去寻找用例
b.执行者与重要性无关
c.时间执行者：用时间执行者来标示预定的事件
d.用例的命名
a)用例名称必须死动宾短语 例如：提交退货申请单
b)采用域模型中的名词术语
c)慎用弱动词弱名词会掩盖真正的业务
e.用例不等于功能
描述一个事物的三个出发点：结构、功能、价值
f.用例不等于步骤
用例是执行者对系统的一个愿望，完成这个愿望可能需要经过很多个步骤，但任何步骤不能够完整的反映执行者的目标
g.如何处理登录
h.用例与愿景目标
a)用例用例应该都能追溯到愿景目标
b)所用的愿景目标都应有对应的用例实现
i.用例分包
当存在大量用例时可以对用例进行分包
j.不要滥用用例关系
②编写系统用例描述
1)作用
a.系统用例图描述总体，系统用例文档描述细节
b.每个系统用例必须对应系统用例描述
2)基本组成
a.干系人利益
b.基本路径
c.扩展路径
d.业务规则
3)系统用例描述中的干系人及其利益
4)基本路径
a.客户最想看到的、最关心的路径—核心的核心
b.把基本路径单独分离，凸显用例的核心价值
c.与扩展路径相比，更为有序
注意：基本路径的书写要求
d.以主动语态，“名词-动词-名词”格式书写 例：银行客户-输入-密码
e.主语只能是执行者或系统
5)拓展路径：
a.系统要处理的意外和分支
b.与基本路径相比，更为无序
6)识别扩展路径的方法：
a.从基本路径的第一句开始，不断地问“还可能发生别的事情”
b.常见的扩展点：系统验证、步骤失败、执行者的选择
注意：每一种扩展尽量用一句（段）描述
7）高级话题
a.基本与扩展分开
b.不要假想系统不能负责的事情
c.辅助执行者
d.完整的用例文档
e.前置条件：开始用例前系统及其环境的状态，形式必须是系统能检测到的。内容不涉及到涉众的利益
f.后置条件：用例成功结束后系统应该具备的状态
g.字段列表：可以用自然语言，也可以用表达式
细致程度取决于干系人共识
不同于数据模型，只是数据模型的一部分
不等于数据字典，不要过早的把时间花在细节上
③更新域模型
1)概念：
在用例分析结果的基础上，对早期的域模型进一步完善和调整，以所有的用例描述为基础，采用首次与建模类似的方法，完善和调整已有的域模型
2)步骤
a.基于用例描述更新域模型
b.整理新发现的名词（排重）
c.整理新发现的名词（排除系统外）
d.更新域模型
整理域模型
21.功能性需求和非功能性需求的区别
- 功能性需求：就是系统可以做什么
- 非功能性需求：系统可以吧某项功能做到什么程度
①可靠性：系统在一定时间内，在一定条件下无故障地执行指定功能的能力
②可用性：一个产品可以被特定的用户在特定的上下文中，有效、高效并且满意的达成特定目标的程度
③性能：系统实现预期功能的能力的特性
可支持性：系统在故障解决和升级方面的能力
22.需求描述两大原则
- 简洁、段落文字少
- 列表、图表相结合的表示法
23.需求评审
五、需求与设计的桥梁；健壮性分析
24.健壮性分析的价值和基本概念
- 健壮性分析帮助完善和确认需求分析的成果
- 优点：
①用例的对象化图示，将用例和对象链接起来
②指出了参与场景的对象相互之间如何交互
③确保用例文本的正确性，从而提供了健康性检查
④帮助确保用例考虑了所有必需的扩展路径，从而提供了完整性和正确性检查
⑤能够持续的发现对象
⑥缩小分析和设计的鸿沟，从而最终完成初步设计 - 基本概念：【健壮性分析中的三种元素】
①边界类：与用户交互的对象，系统和外部世界的界面。如窗口、对话框
②实体类：是现实世界存在的实体对象，域模型中的类，它常对应于数据库表和文件。有些实体对象是“临时”对象，当用例结束后将消失
控制器类：边界和实体间的“粘合剂”，将边界对象和实体对象关联起来，它包含了大部分应用逻辑，他们在用户和对象之间架起一座桥梁。控制对象中包含经常修改的业务规则和策略
- 三种元素的交互规则：
①执行者只和边界对象通话
②边界对象和控制器可以互相通话（名词《–》动词）
③控制器可以和另一个控制器通话（动词《–》动词）
④控制器和实体对象可以互相通话（动词《–》名词） - 注意事项：
①交互规则帮助强化用例文本的“名词-动词-名词”的语法格式
②如果用例文本遵循这个格式，健壮性图非常容易画出‘如果不是，则画起来会很困难
③时序图本质是完全的“名词-动词-名词”格式；对象是名词，对象间传递的消息是动词，通过以此格式描述的用例文本，可以非常容易地进行详细设计
25.壮性分析的步骤：
- 创建一个空的健壮性图
- 直接将用例文本粘贴到图上（基本路径和扩展路径）
- 从基本路径的第一句话开始画健壮性图
- 贯串整个用例基本路径，一次一个句子，画执行者、适当的边界对象和实体对象以及控制器，和各元素之间的连线。
- 将每一个扩展路径画在健壮性图上，并以红色标示出
26.优化健壮性分析图
- 将用例文本直接粘贴到健壮性图上
- 从域模型中提取实体对象，如果发现之前有缺漏，则补充上
- 在画健壮性图时修正之前用例模糊的地方
- 将每一个屏幕对象定义为边界对象，并进行清晰的命名
- 切记控制器对象大部分时候对应的是逻辑操作方法，偶尔也会对应真实的控制器对象
- 在画健壮性图时，如果调用另一个用例，就直接在图上画用例，用此用例即可
- 切记健壮性分析描绘的是概要设计而不是详细设计
- 健壮性图上的边界对象和实体对象会转化为时序图中的对象实例，二控制器对象会转化为消息或则控制器实例
- 切记健壮性图是用例的“对象化图示”，它的目的是优化和完善用例文本和域模型
27.更新域模型
六、关键设计
28.关键设计的意义和方法
- 意义：就是通过寻找对象之间的交互关系，进而进行方法(操作或行为)分配
- 方法：基于用例图、用例描述和健壮性图，采用序列图来描述参与者、边界、实体之间的交互
29.序列图的要素
30.关键设计的步骤
- 将现有的域模型直接作为第一版 静态类模型
- 基于用例描述和健壮性分析结果，画出每一个用例的序列图
①健壮性图中的控制类会转化为方法
②如果也转化为控制类，那么就添加到类图中（注意：边界类不添加到类图中）
③具体步骤：
1)贯穿健壮性图上每一个控制器，每次一个，画出序列图上相应的方法，然后核对，移至下一个控制器
2)控制器和方法之间并一定是完全一对一匹配的，也可能会转化为两个或多个方法
3)有时，控制器也可能会转换为一个真正的控制器类
4)序列图会对类图做进一步的更新，完善其方法
④如何决定控制器分配给哪个类？
1)高内聚，低耦合。是判断设计好坏的标准。
a.高内聚是指一个软件模块类是由相关性很强的代码组成，只负责一项任务，简单的说是单一责任原则
b.低耦合是指一个软件模块与模块之间的接口，尽量的少而简单，如果某两个模块间的关系比较负责的话，最好首先考虑进一步的模块划分，降低相互间的依赖。这样有利于修改和组合。
2)使用高内聚，低耦合的目的：使得模块的“可重用性”、“移植性”大大增强 - 整理静态类图和序列图
①画序列图的注意事项：
1)简单扩展点；可以合并到基本路径图
2)复杂扩展点：单独一张图，在基本路径图引用Include、Extend用例也适用
3)使用循环loop
4)箭头代表责任分配而不是数据流动
5)画方法【method】的同时将方法分配给类，反复核对类图，确保所有方法分配给了适当的类
6)不要花费太多时间在控制焦点上
7)不要把序列图画成流程图
②明确“钱”属于系统外实体对象，我们统一采用“硬件接口控制”来与外部实体交互，因此不会直接操作它，把它去掉
③验证控制类完成了取款验证和转账验证，去掉单独的“去看条件”和“转账条件”
④结合序列图，定义类与类之间的关系（关联、聚合、组合、泛化、依赖），以及关系的多重性 - 关键设计复核，迭代更新用例图、类图和序列图
①方法：面对面会议
②指导性建议：
1)确保关键设计的“如何做”和需求阶段的“做什么”匹配。也就是说每个用例都要和序列图匹配，包含了用例的 基本流程和分支流程
2)复核设计的品质，应该至少有一个设计专家在场
3)检查消息的连贯性，检查时序图上消息箭头的指向，有时我们会发现对象之间缺少消息而造成跳跃，我们必须消除这些逻辑跳跃
4)确保方法分配给了适当的类，类视图中的饿每一个类拥有适当的方法和属性
七、详细设计
31.详细设计内容
- 技术架构及相关考虑
①选择开发语言
1)客观条件需要
2)客户要求
3)开发团队习惯
②网络拓扑及安全
③体系结构
1)三层的体系结构
a.用户界面层
b.业务逻辑层
c.数据访问层
d.数据库
2)多层
a.用户表示层
b.业务外观层
c.业务规则层
d.数据访问层
④硬件支持环境
⑤软件支持环境 - 交互设计
对产品的界面和行为进行交互设计，让产品和它的使用者之间建立一种有机关系，从而可以有效达到使用者的目标，这就是交互设计的目的
32.详细设计的规范
- 结合体系结构、编程语言、数据模型和设计模式等来细化类图
- 调整序列图（为了清晰易读，可以考虑去掉执行者和界面层的部分，因为这部分没有复杂的逻辑）
33.组件图：
是用来反映代码的物理结构。从组件图中，可以了解各软件组件之间的编译器和运行时依赖关系，使用组件图可以将系统划分为内聚组件并显示代码自身的结。描述如何把设计的类分配给不同实体组件
34.部署图：
是用来显示系统中软件和硬件的物理架构。从部署图中，可以了解到软件和硬件组件之间的物理关系以及处理节点的组件分布情况。使用部署图可以显示运行时系统的结构，同时还传达成应用程序的硬件和软件元素的配置和部署方式。描述如何把实体组件部署在不同的机器上。
八、scrum敏捷过程概述
35.敏捷宣言
- 内容：
我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法，通过这项工作，我们认为：“个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文档；客户合作胜过合同谈判；响应变化胜过遵循计划” - 敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品
36.正确认识敏捷
- 对敏捷的常见误解
①敏捷开发意味着可以不需要文档、计划和设计
②敏捷只是一些优秀实践，或则是优秀实践的结合
③敏捷只适用于小项目开发
④敏捷只会对研发产生改变
⑤管理者不需要亲自了解敏捷，只需要管理上支持就可以了
⑥引入敏捷只需要按照既定的步骤去找就可以了
⑦敏捷是cmm的代替品，是另一种流程
⑧敏捷只注重特性的快速交付，在敏捷下架构不重要了 - 正确的认识
①理念：敏捷核心思想
1)Team：激发团队潜能，加强协作
a.团队是价值的真正创造者，应加强团队协作，激发团队潜能
b.软件开发是一种团队活动，首先应做到提升共同效率降低交流成本
2)Value:聚焦客户价值，消除浪费
a.产品商业成功为目标，聚焦客户价值、围绕价值流消除浪费
3)Adapting：不断调整适应变化
a.不断的根据经验调整，最终交付达到业务目标的产品
②优秀实践：敏捷的经验积累（站立会议、持续集成、单一主干、系统解剖、重构、TDD、结对编程、FDD、迭代）
③具体应用：能够结合自身灵活应用才是真正敏捷【因地制宜选择合适的敏捷实践】
37.敏捷实践（scrum）
38.敏捷软件开发核心–迭代增量开发
- 概念：迭代开发将整个软件生命周期分成多个小的迭代
每次迭代都由需求分析、设计、实现和测试在内的多个活动组成
每次迭代都可以生成一个稳定和被验证过的软件版本 - 好处：
①通过较高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险
②通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使得最终产品更加符合客户的需要
③通过小批量减少排队，提供更灵活、快速的交付能力
④平滑人力资源的使用，避免出现瓶颈
39.敏捷团队
- 三个角色
- 完整团队
①概念：敏捷开发中，以story为单位的持续交付要求系统组、开发和测试等跨功能团队进行密切协同，相互独立的功能团队难以应付完整团队是跨功能领域（需求分析师、设计师、开发人员、测试人员、资料人员等）的人员组成一个团队，坐在一起工作，团队成员遵循同一份计划，服从同一个项目经理
②好处：
1)有助于团队成员形成共同目标和全局意识，促进各功能领域的拉通和融合
2)通过面对面沟通提升沟通效率
3)实现团队成员的高度协同，支撑高密度地、持续地、短周期的交付
③关键要点：
1)成员来自多功能领域：团队拥有完成目标所需的各职能成员
2)能在一起办公：团队成员无障碍地沟通
3)团队保持相对稳定：临时组建的团队生产效率低，团队稳定非常关键
4)T型人才，背靠背精神：每个成员都能一专多能，工作上互助互补
40.传统方式和敏捷方式管理者的转变
- 传统方式：管理者努力“控制”团队
①制定详细的工作计划，并做出详细的工作安排
②指令性工作方式
③监控过程
④基于复杂规则的管理 - 敏捷方式：管理者努力“激发”团队
①通过目标来牵引团队自主工作
②帮助团队提供资源，排除障碍
③营造团队自我管理的工作氛围
④作为教练辅导团队进步
⑤基于简单原则的管理，原则简单但必须被准守
41.传统方式和敏捷方式团队成员的转变
- 传统方式：团队成员是“听从安排的独立贡献者”
①被动等待主管下指令安排工作
②独立工作为主，协作少
③以文档和邮件为主要沟通方式
④只关注个体任务“做完”，不关注团队目标
⑤能力相对单一，学习动力不足 - 敏捷方式：团队成员是“全方位的积极参与者”
①共同参与计划制定和任务安排
②团队协作贯穿工作始终
③面对面交流是主要沟通方式
④关注团队目标，共担责任
能力要求更广，主动学习适应岗位要求
42.PO的特征
43.SM的特征
- 见多识广
- 善于提问
- 有耐心
- 有协作精神
- 保护团队
- 公开透明
44.开发团队的特征
45.敏捷工作件
- 产品Backlog
- 迭代Backlog
- 完成标准
- 完成标准
- 任务看板
- 燃尽图
46.产品功能列表
- 按照优先级排序的预期产品功能集，包括
①特性
②缺陷
③技术工作
④知识获取 - 好的产品功能列表需要具备DEEP特征
①详略得当
②涌现
1)客户的新想法
2)竞争对手的行动
3)意外的技术问题
③做过估算-使用卡片来估算PB工作量
④排列优先级
47.敏捷管理实践
- 迭代会议：
①概念：每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品Backlog，输出是团队迭代Backlog
②多团队迭代计划会议要分层召开
版本迭代计划会议：将产品Backlog（需求）分配给团队
团队迭代计划会议：将选取的产品Backlog需求转换成迭代Backlog（任务） ，分配给团队成员；
③迭代计划会议内容：
1)澄清需求、对“完成标准”达成一致
2)工作量估计、根据团队能力确定本轮迭代交付内容
3)细化、分配迭代任务和初始工作计划。迭代计划会议由团队共同确定迭代交付内容和完成
④好处：
1)通过充分讨论，是团队成员对任务和完成标准理解一致
2)团队共同参与，促进团队成员更认证对待自己的承诺
⑤关键要点：
1)充分参与：SM确保PO和team充分参与讨论，达成理解一致
2)相互承诺：Team承诺完成迭代BackLog中的需求并达到“完成标准”
PO承诺在短迭代周期不增加需求
3）确定内部任务：Team和PO协商把一些内部任务放入迭代中，由破考虑并与其他外部需求一起排序 - 迭代BackLog规划：
每个迭代的周期通常是2-4周，对应的规划时间为4-8小时
参与者：
Po：分享本迭代的目标，展示排好序的PBI，回答团队提出的问题
团队：确定可交付哪些特性，在冲刺规划结束时做出承诺
SM：观察规划活动，提出深入细节的问题，引导并帮助团队确保有成果
步骤：
- 迭代执行
包括：规划、管理、执行和沟通工作，以确保创建科工作的、经过测试的特性 - 每日站立会议
①概念：由SM组织，Team成员全体站立参加
②内容：
1)我昨天为本项目做了什么？
2)我计划今天为本项目做什么？
3)我需要什么帮助以更高效的工作？
③好处：
1)增加团队的凝聚力，产生积极的工作氛围
2)及时暴露风险和问题
3)促进团队内成员的沟通和协调
④关键要点
1)准时开始
2)高效会议
3)问题追踪 - 迭代评审会
①概念:
1)每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求
2)由SM组织PO和用户代表负责验收、Team负责演示可工作软件
②好处：
1)通过演示可工作的阮家安来确认项目的进度，具有真实性
2)能尽早的获得用户对产品的反馈，使产品更加贴近客户需求
③关键要点：
1)展示“真实”的产品：Team应在真实环境中展示可运行的软件，判断是否达到“完成”标准
2)收集反馈：PO根据验收情况及客户反馈意见，及时调整产品BackLog
④准备工作
⑤典型内容
1)PO:概要说明迭代目标中哪些完成，哪些没完成
2)成员：演示完成的增量
3)参会人：讨论产品当前状态
4)团队：调整产品未来方向 - 迭代回顾会议：
①概念：在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步；
②问题：
1)本次迭代有哪些做得好
2)本次迭代我们在哪些方面还能做得更好
3)我们在下次迭代准备在哪些方面改进
③好处：
1)激励团队成员；
2)帮助团队挖掘优秀经验并继承；
3)避免团队犯重复的错误；
4)营造团队自主改进的氛围。
④关键要点：
1)会议气氛：Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；
2)关注重点：Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；
3)会议结论要跟踪闭环：可以放入Backlog中
⑤准备工作
⑥典型内容
48.敏捷工程实践技术
- 用户故事
①概念：用户故事是站在用户角度描述需求的一种方式，每个故事必须有对应的验收测试用例，用户故事是分层分级的，在使用过程中逐步分解细化
②模板：作为一个XXX客户角色，我需要XXX功能，带来XXX好处
③关键点：
1)I-independent，可独立交付给客户
2)N-negotiable，便于与客户交流
3)V-valuable，对客户有价值
4)E-estimable，能估计出工作量
5)S-small，分解到底层的用户故事粒度尽量小，在一个迭代中能完成
6)T-testable，可测试
④INVEST标准
⑤好处：
1)用户故事站在用户视角便于和客户交流，准确描述客户需求
2)用户故事可独立交付单元、规模小，适合于迭代开发，以获得用户快速反馈
3)用户故事强调写验收测试用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计
⑥特征
⑦大小级别：
1)史诗故事（1-2个月）
2)特性故事（1-2周）
3)冲刺故事（1-2天）
4)任务（几个小时）；可分工执行
⑧约束条件（验收条件）
作为用户故事的约束体现（Card背面）
⑨知识获取性故事如何表达：
1)一般偏重后台实现
2)必须向PO说明价值，并且不宜出现太多
⑩如何搜集：
1)开展用户故事写作研讨会，通过头脑风暴
2)故事地图,史诗故事按时间流横向排开，纵向按优先级排序 - 结对编程
①关键要点：
1)程序员应经常性地在“驾驶员”和“领航员”间切换，保持成员间平等协商和相互理解，避免出现一个角色支配另一个角色的现象；
2)开始一个新Story开发的时候即可变换搭档，以增进知识传播；
3)培养团队成员积极、主动、开放、协作的心态能够增进结对编程效果；
4)实施初期需要精心辅导，帮助团队成员克服个性冲突和习惯差异
②好处：
1)有助于提升代码设计质量
2)编程效率更高
3)大幅度促进团队能力提升和知识传播 - TDD（测试驱动开发）
①概念：TDD是以测试作为编程中心，它要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构优化
②要求：测试可以完全自动化运行
③关键要点：
1)测试代码和源代码一样都需要简洁，可读性好
2)测试用例的设计要保证完备，覆盖被测单元的所有功能
3)每个测试用例尽量保持独立，减少依赖，提高用例的可维护性
4)当功能单元较大时，为降低难度，可分解为多个更小的功能单元，并逐一用TDD实现
④好处
1)和代码同步增长的自动化测试用例，能为代码构筑安全网
2)保证代码重构的质量
3)TDD有助于开发人员优化代码设计
4)提高代码可测试性 - 持续集成(CI)
①概念：持续性集成是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成
②好处：
1)大幅度缩短反馈周期，实时反映产品真是的质量状态
2)缺陷在引入的当天就被发现并解决，降低缺陷修改成本
3)将集成工作分散在平时，通过每天生成可部署软件；避免产品最终集成时爆发大量问题
③关键要点
1)强调“快速”和“反馈”，要求完成一次系统集成的时间尽量短，并提供完备且有效的反馈信息
2)自动化测试用例的完备性和有效性是持续集成质量保证
3)修复失败的构建是团队最高优先级的任务
4)开发人员必须在本地构建成功，才可以提交代码到配置库
5)持续集成的状态必须实时可视化显示给所有人
6)大系统持续性集成分层分级，建立各层次统一的测试策略 - CodeReview
①目的：持续的提高开发团队的工作质量
②好处：
1)代码复查者能从他们的角度来发现问题并且提出更好的解决方案
2)确保至少你院队的另一个其他成员熟悉你的代码
3)公开reviewer和被复查者的想法和经验足够促进团队间的知识分享
4)能鼓励开发者将他们工作进行的更彻底，因为他们知道他们代码将被其他人阅读 - 发布规则
