ACP敏捷.知识领域及相关概念串讲

1. 敏捷原则和理念/Agile Principles and Mindset 2. 价值驱动交付/Value Driven Delivery

敏捷交付的是价值，而不是功能。

项目草程与商业论证敏捷项目章程与传统项目章程: 相同点:都是对项目大体工作的说明。都-般含有项目的5W1H。 -般都含有愿景。敏捷项目章程重点:还有愿景(电梯演讲)，使命和成功标准。一般情况下公开在白板上。

商业论证: 是项目章程的一个部分，重点包含预期收益、预期成本、SWOT，主要要干系人、不做这个项目的风险等描述。

商业画布：

电梯演讲/产品愿景

愿景无法带来团队信任，实现了才会。

for [target customer] who [statement of the need or opportunity] the [product name] is a [product category] that [key benefit, compelling reason to use] unlike [primary competitive alternative] our product [statement of primary different 为了[目标客户]，他们的[需要和机会]，这个[产品名称] 是一个[产品类型]，它可以[关键优点和使用理由]，而不像[同类竞争者]，我们品的(差异化声明)，价值核心-三个最小

最小可交付价值：一堆功能中，找到最核心的内容来交付。

最小可销售单元：一堆功能中，找到最有价值的一点来销售。

最小可行性产品(Minimum Viable Product,简称MVP，

MVP是一种避免开发出客户并不真正需要的产品的开发策略。该策略的基本想法是，快速地构建出符合产品预期功能的最小功能集合，这个最小集合所包含的功能足以满足产品部署的要求并能够检验有关客户与产品交互的关键假设。

MVP是最符合敏捷思想的产品迭代开发方法。MVP首先着眼于基本的客户需求，快速构建一个可满足客户需要的初步产品原型。部署之后，通过客户反馈，逐步修正产品设计和实现，最终达到完全满足客户需要。而最关键的是，在各个迭代过程中，做出来的产品始终是可为客户所用的产品，而不是只有一部分功能却不能让客户使用。

MMF(minimum marketable feature),最小可市场化特性

政企类项目更多的是争取高层次需求，单单追求生产效率，很难签单

优先级

1. MoSCoW 可考虑强制分布60%-20%-20%

2. Kano模型，基于客户的兴奋点来看待需求---

兴奋性需求，只要做一点，客户就会很高兴，会给客户带来快感。

3. 权重，或者相对量级

1、将所有成功的收获和制约因素均进行罗列
2、分析每一-项影响的大小和范围
3、重点关注做带来什么收益、风险、问题，不做这个功能点的风险、问题
4、每一个都打分
5、基于得分高低获取优先级

3. 干系人(相关方)参与Stakeholder Engagement 3.1 敏捷与项目管理都有的

使用技术相同的: 干系人管理、沟通管理、风险管理、人力资源管理、采购管理、质量管理；

使用技术不相同的:成本管理、范围管理、进度管理敏捷合同说明:敏捷很难像传统项目管理直接规划，所以敏捷需要签订那种框架协议，或者人天合同。

所以，所有固定总价合同均不适用与敏捷，一般合同，然后每次迭代固定价格是可以的。

3.2 干系人管理，识别干系人，根据干系人制定不同的干系人沟通策略

权力利益矩阵；

重要核心干系人，一直邀请其参与活动；邀请协助制定产品待办事项列表；由PO保持沟通。

干系人期望：SM、敏捷管理师、敏捷项目经理、敏捷XXX在其中扮演重要角色，管理干系人期望。向干系人透明展示同步任务、风险、问题信息等

管理干系人期望，也就是构建干系人信任的方法，关键就是说道做到。

3.3 沟通管理

德尔菲技术(匿名专家沟通法)，//--如同打官司时跟律师的沟通沟通强调倾听大于一切，不强调一个人做决策。团队共同决定原则上，什么快，什么好，用什么面对面沟通>频繁的视频会议>统一的应用程序(信息冰箱)>邮件(老外苦邮件久已) >其他渗透沟通:就是不需要过多的说明就完成沟通的行为，存在于集中办公的环境中，结对编程常用到渗透沟通效果，是团队自组织的有效工具。

3.4 沟通试用工具之一：任务看板 vs KANBAN系统板

任务一般只有三个状态。

下面是流程板，或叫看板系统

3.5 沟通试用工具之二：燃尽图；燃起图；条形燃进度；

燃尽图燃的是的任务，横轴是时间，一天天，常用于监控一个单次迭代内的任务开发解决情况；燃尽图实在迭代计划会的时候画出来的。

如果是项目燃进度，或发布燃尽图，则监控项目的状况，横轴可能是每次迭代完成的任务数据；

新增任务大于修改解决掉的任务，

燃尽图监控的是单次迭代内的任务，无法监控项目。

监控项目可以用发布燃尽图。

条形燃尽图，底部表示从发布中添加和删除的非计划中的工作

每一个条形是一次迭代。

1. 有完成部分工作；同时增加部分非计划的工作；

2. 比第二次迭代再完成部分工作；同时再次增加部分非计划内的工作；

3. 原先已经完成的部分工作由于某种原因又回到当前任务中，与上次迭代比没完成任何任务；部分非计划中工作被移动出本次迭代。

3.6 使用工具一累计流量图

每钟颜色是一个泳道，即一个工序；

纵轴：在制品WIP:

横轴：平均前置时间

斜率-Little法则：

4. 团队绩效/Team Performance

自组织团队是最好的状态，有冲突，尽量团队自己解决。

在ACP中，冲突是好的，冲突有利于促进团队的进步；

冲突管理五种方法: 回避、妥协(双输或者单输)、缓解、合作（共赢）、对抗；

冲突层级: 问题待解决、异议、竞赛、运动、战争

冲突的原因是什么，如果跟工作相关，最好的是合作共赢；如果跟敏捷工作无关的，最好回避。

冲突的根因分析法：石川图/鱼骨图； 5Y技术/五个为什么技术；

5WHY从三个层面来实施：

一、为什么会发生？从“制造”的角度。

二、为什么没有发现？从“检验”的角度。

三、为什么没有从系统上预防事故？从“体系”或“流程”的角度。

每个层面连续5次或N次的询问，得出最终结论。只有以上三个层面的问题都探寻出来，才能发现根本问题，并寻求解决。

经典案例

丰田汽车公司前副社长大野耐一曾举了一个例子来找出停机的真正原因

★问题一：为什么机器停了？答案一：因为机器超载，保险丝烧断了。

★问题二：为什么机器会超载？答案二：因为轴承的润滑不足。

★问题三：为什么轴承会润滑不足？答案三：因为润滑泵失灵了。

★问题四：为什么润滑泵会失灵？答案四：因为它的轮轴耗损了。

★问题五：为什么润滑泵的轮轴会耗损？答案五：因为杂质跑到里面去了。

经过连续五次不停地问“为什么”，才找到问题的真正原因和解决的方法，在润滑泵上加装滤网。

如果员工没有以这种追根究底的精神来发掘问题，他们很可能只是换根保险丝草草了事，真正的问题还是没有解决。

解决问题步骤

一部分：把握现状

★步骤1：识别问题

问：我知道什么？

★步骤2：澄清问题

方法中接下来的步骤是澄清问题。为得到更清楚的理解，问：

实际发生了什么？应该发生什么？

★步骤3：分解问题

在这一步，如果必要，需要向相关人员调查，将问题分解为小的、独立的元素。关于这个问题我还知道什么？

还有其他子问题吗？

★步骤4：查找原因要点(PoC)

现在，焦点集中在查找问题原因的实际要点上。你需要追溯来了解第一手的原因要点。问：

我需要去哪里？我需要看什么？谁可能掌握有关问题的信息？

★步骤5：把握问题的倾向

要把握问题的倾向，问：谁？哪个？什么时间？多少频次？多大量？

在问为什么之前，问这些问题是很重要的。

第二部分: 原因调查

★步骤6：识别并确认异常现象的直接原因。

如果原因是可见的，验证它。如果原因是不可见的，考虑潜在原因并核实最可能的原因。依据事实确认直接原因。问：

这个问题为什么发生？

我能看见问题的直接原因吗？

如果不能，我怀疑什么是潜在原因呢？我怎么核实最可能的潜在原因呢？我怎么确认直接原因？

★步骤7：使用“5个为什么”调查方法来建立一个通向根本原因的原因/效果关系链。

问：处理直接原因会防止再发生吗？

如果不能，我能发现下一级原因吗？

如果不能，我怀疑什么是下一级原因呢？

我怎么才能核实和确认下一级有原因呢？

处理这一级原因会防止再发生吗？

如果不能，继续问“为什么”直到找到根本原因。在必须处理以防止再发生的原因处停止，问：

我已经找到问题的根本原因了吗？

我能通过处理这个原因来防止再发生吗？

这个原因能通过以事实为依据的原因/效果关系链与问题联系起来吗？

这个链通过了“因此”检验了吗？

如果我再问“为什么”会进入另一个问题吗？

确认你已经使用“5个为什么”调查方法来回答这些问题。

为什么我们有了这个问题？

为什么问题会到达顾客处？

为什么我们的系统允许问题发生？

★步骤8：采取明确的措施来处理问题

使用临时措施来去除异常现象直到根本原因能够被处理掉。问：

临时措施会遏止问题直到永久解决措施能被实施吗？

实施纠正措施来处理根本原因以防止再发生。问：

纠正措施会防止问题发生吗？

跟踪并核实结果。问：

解决方案有效吗？

我如何确认？

为什么一为什么分析法检查清单

为确认你已经按照问题解决模型操作，当你完成问题解决过程时，使用这个检查清单。

4.1 团队速率

固定时间内团队完成任务的规模，通常是单次迭代。团队速率不是越大越好，而是越稳定越好；跨团队比较不成立，但可以跨迭代比较，前提是统一。

4.2 团队组建的四个阶段，形成、震荡、规范、成熟

领导力模型

不同的团队阶段，用不同领导力类型。

共享领导（Shared Leadership）共享领导是一种新的管理思想，该思想主张由领导者和其下属成员组成的管理团队来共同承担领导责任，领导者必须摆脱传统独自负责和控制一切的观念，使下属成员更愿意担任责任并更具主动性。当团队的所有成员充分参与到团队的领导，为最大限度地发挥团队的潜力而毫不犹豫地进行指导和影响团队其他成员时，则实现了共享领导。

简单讲，共享领导就是团队同时进行的、持续的、相互影响的过程，伴有一系列不同的非正式领导者的出现。某种意义上说，共享领导可以被看作团队充分授权的发展，它是对过去那种期待一个拥有各项领导必备特质的正式领导者带领大家走向成功的观念的修正。

共享式领导力：诚信、前瞻性、竞争性、激励性；渗透沟通；创建和传达远景，构建企业文化；挑战现状；找到合适的人

服务式领导：帮助团队>命令团队、移除障碍>创建阻碍、保护团队>干扰团队。敏捷创建的是自组织团队，所以管理基于团队，不基于任何任务。团队应该在一起。

5. 适应性计划/Adaptive Planning

敏捷强调在一个迭代期间不做变更；变更不仅是需求变更，还包括人员、环境、计划的变化等。

6. 问题探测spike与解决/敏捷风险管理

四步法:识别、评估(定量、定性)、响应、评审。

识别:所有活动均可以风险识别，输出风险登记册。评估:梳理活动经常干这个事情，其他活动也或多或少也会有一些；站会不会评估，或许会提出部分风险。响应:回避、减轻、转移、接受(站会跟踪，看评审:回顾会议上进行工具:风险板、风险日志、风险燃尽图、风险预测图

在敏捷中，风险登记册做好后，重在公开，大家都要看到。另外，敏捷建议优先处理高风险高收益的事情，其次是高收益低风险的事情，其次是低风险低收益的事情。

探测（Spike）敏捷中使用的一种技术，一般情况下只用来判断可行性。新技术，新方法可以小范围制定探测技术。由于有问题，有难点，所以鼓励探测技术来使用。

价值流程图中，WIDETOM可用于记录不同形式的浪费 Waiting-等待 Inventory-库存 Defects缺陷4 Extra processing额外流程 Transportation-运输 Over- production-过度生产 Motion-动态，不必要的行动；

7. 持续改进/Continuous Improvement 7.1 持续集成

CI的工作流程

提交代码到代码库
CI server监听代码库的变更
CI server触发自动化构建
CI server触发自动化测试
通知相关方

HotFix热修

TDD

测试行为推进开发测试
.先撰写测试内容再进行开发工作
统一考虑代码和测试
测试比单元更重要，测试不强调100%覆盖所有内容
单元测试只是其中的一个测试手法，接口测试提倡微服务化

敏捷质量观（戴明老师）：

“停止依赖检验来达到质量”

质量是设计出来的，不是测试出来的。

敏捷测试：

确立敏捷质量观
.建立质量内建的研发流程
.善用互联网化质量保证能力
.适度推进分层自动化测试
优化测试数据和测试环境管理
强化持续集成能力
建立敏捷测试组织

敏捷测试是一种遵循敏捷软件开发规则和原则的测试实践。与瀑布方法不同，敏捷测试可以在项目开始时就开始进行，而开发和测试之间会不断进行集成。

敏捷测试主张尽早开始测试，重点关注持续迭代地测试新开发的功能。敏捷的测试团队还要保证整个软件开发过程是正确的是符合用户需求的。

遵循

1、强调从客户的角度，即从使用系统的用户角度，来测试系统

2、重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段

3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性

Incremental test 增量测试

全回归测试太多了，每次迭代做一部分，分开的总量合起来就是完整的测试用例数量
Exploratory test 探索性测试

敏捷测试有很大一部分工作量在回归测试上面，因为敏捷时间周期比较短，但是之前所有的我们也都要测试，怎么可能在一两天内把几年内积累的所有功能都测一遍，这也是敏捷测试里的一个痛点。
- 解决方案就是让开发提供影响性分析，开发改的代码可能会影响到哪些模块，测试就根据这份列表，去找到对应的测试用例，进行回归测试。

10.其他相关知识

传统铁三角:范围、成本、进度(范围不可变)---中间是质量敏捷铁三角:进度、范围、成本(进度不可变)

敏捷三角指是价值、质量以及三重约束条件（成本、进度、范围）。在敏捷三角中，为了实现价值和质量目标，约束条件也就是进度、成本和范围是可以牺牲和调整的，如果进度和成本不变的情况下就调整范围。敏捷项目评估的三个目标可归纳为： 1、价值目标：提供可交付的产品 2、质量目标：提供可靠的、适应性强的可交付的产品 3、约束目标：在可接受的约束内，实现价值和质量目标。

常见的敏捷架构/方法论包括： Scrum、XP极限编程、精益软件开发、水晶、特征驱动开发（FDD）、动态系统开发方法（DSDM）、敏捷统一过程（AUP）。

精益软件开发的原则是清除浪费；强化学习；尽可能晚决策；尽可能早交付；授权团队；构建完整性；全盘检视。精益软件开发架构中存在的两种完整性类型有：概念性的和感知性的。概念上的完整性是由开发者决定的，如果产品集成良好和功能详细，那么完整性大体上会非常高。感知上的完整性是由客户观察得出的，如果客户最初对产品满意和在之后产品满足需求，那么完整性会很高。

《美国项目管理协会敏捷社区实践社区章程》提出的社区价值包括：前景、仆人式领导、信任、协作、诚实、好学、勇气、开放、适应力、领导变革、透明化。

敏捷术语和概念 1、敏捷最适合具有复杂要求和技术的项目 2、敏捷项目范围不固定，而时间和成本是固定的 3、敏捷使用自上而下的估计 4、敏捷文档通常勉强够用 5、敏捷有利于适应，而传统的管理方法有利于预期

敏捷挣值管理（EVM）用于价值跟踪报告，最好应用于迭代级别。因为范围是变化的，所以项目的EVM计算往往有误差。

渐进明细是敏捷计划的一个理念。敏捷计划有5个层次（计划洋葱）：愿景、产品路线图、产品发布计划、迭代计划、每日计划。其中，产品发布计划、迭代计划和每日计划是从三个不同的角度逐步进行计划的。

1、愿景：目标是定义产品要解决的首要问题和目标人群。这有助于你了解产品为用户带来的真正价值，和如何让你的产品与其他产品区分开来。规划这一层的一个好方法是与组织领导者共同完成产品愿景画布。 2、产品路线图：团队一起创建的高级别计划，说明如何实现产品愿景中定义的目标。通常，路线图的内容在发布层会被分组，让组织中更多成员在确定每个可能的版本中的功能时能更好理解这些内容。 3、产品发布计划：阐明构成路线图中的每一个发布版本的特定功能和每个版本交付的实际时间表。单独的故事和任务会出现在计划上。 4、迭代计划：为每次迭代做计划，包含选择迭代需要完成的用户故事和迭代工作计划。 5、每日计划：团队要在每天开始的时候评估自己的状态，并共同制定第二天的计划。

敏捷项目管理模式的架构的5个阶段：构想—推测—探索—适应—结束，重点在交付(执行)和适应。敏捷是一项平衡灵活性和稳定性的能力。 1、构想：确定产品构想、项目范围、项目社团以及团队共同工作的方式。 2、推测：制定基于功能的发布计划、里程碑和迭代计划，确保交付构想的产品。 3、探索：在短期内提供经测试的功能，不断致力于减少项目风险和不确定性。 4、适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整。 5、结束：终止项目、交流主要的学习成果并庆祝。

有两种流程：一种是即定流程，一种是经验流程。 “看板”和SCRUM是基于经验流程经验流程在复杂流程中使用。 “看板”法和SCRUM法进行每日站会的不同之处：“看板”法先进行高层会议，而SCRUM法先进行团队会议，再派团队代表参加下一轮会议。 Scrum是敏捷项目管理的框架，它是一个冲刺和增量型的框架，它的基石是“一直存在一个理论上可传输的产品”。

1、 Scrum的三大支柱： A) Transparency 透明：为项目结果的负责人提供可见度。 B) Inspection 检查：适时检查项目进度顺利地向目标推进，找寻问题的偏差。 C) Adaption 适应：假设检验发现问题或是不合意的趋势，调整流程。

2、 Scrum团队由Team、PO和SM组成，包含几种不同的活动类型：冲刺、冲刺计划会、每日立会、冲刺评审会和冲刺回顾会。

3、一个健全的站立会议的重点特征包括：同辈压力(因为团队靠大家,所以同辈的期望可带动进步)、密切的配合(团队应当理解对专注的必要性并独立工作)、细在专注(团队应当理解每日站立会议中简洁的必要性,由此团队才有效益)、每日承诺(团队应当理解对每人每日承诺的价值所在,并兑现这些承诺)、辨别障碍(团队应当集体意识到每个人的困难,由此团队可集体尝试解决)。在每日立会中可讨论调整团队的工作量。

4、 Scrum开发团队应保持5~9人的规模（不含PO和SM），开发团队不含测试或业务分析等子团队，它强调跨职能的，自组织的。 5、 PO产品负责人主要职责是对产品待开发项进行管理，梳理产品待开发项，并对其进行优先级排序，确保开发团队所执行工作的价值，确保产品待开发项对所有人可见、清晰、透明，以及开发团队对其有一定程度的了解。

6、 Scrum Master首要职责是确保Scrum被正确地理解和实施，确保团队遵循Scrum的理论、实践和规则，保护团队免受干扰，排除障碍，他以各种方式服务于PO、Team和组织。 7、产品负责人应在会议前准备好产品待开发列表，缺少产品负责人的情况下，Scrum Master应该在会议前创建符合要求的产品待开发项，并代理产品负责人一职。 8、时间盒：冲刺（24周）、冲刺规划会（48小时）、每日立会（约15分钟）、冲刺评审会（4个小时）、冲刺回顾会（1~3小时）、先前迭代回顾会不超60分钟。 9、 Scrum三个工件：产品Backlog、Sprint Backlog、燃尽图。 10、 Scrum的五个价值：承诺、专注、开放、尊重、勇气。 11、在进入首个Sprint之前，需要举行一个发布计划会议，发布计划会议输出是：发布计划、发布Backlog、行动项目、风险、假设、依赖。 12、产品待办事项(product backlog)的 DEEP 原则： D) 详略得当（D etailed Appropriately） E) 做过估算的（E stimated） F) 涌现的（E mergent） G) 排列优先级的（P rioritized）

13、 SOS：每 5~9个Scrum TEAM为一个Scrum-of-Scrum。 14、 Sashimi的原意是“生鱼片”，在Scrum中是团队用来表达“完成”的一种说法；不同团队对于“完成”的定义可以是不一样的，但在一个团队内必须统一，在Scrum中一个团队需要定义不同级别的“完成规范”来统一这个概念，“完成规范”可是是任务级别的，团队级别的或者产品特定级别的。 15、 Impediments的意思是“障碍”，是团队在向着“完成规范”所定义的状态努力过程中遇到的阻碍，一般来说，Scrum Master需要作为消除障碍的主要负责人！发布计划不是固定不变的。它可以依照团队的开发速度和优先级排序做出调整。

----------------------------- XP极限编程是敏捷方法中的一中软件开发方法，相对于Scrum关注项目管理工作，XP更加关注软件开发的良好实践。它要求至少有一名客户代表在整个项目周期在现场负责确定需求、回答问题和功能验收测试。 1、 XP的核心价值是：简单、沟通、反馈、勇气、尊重。 2、 XP的13个核心实践是：完整的团队、规划游戏、小型发布、客户测试、共同所有权、编码标准、可持续的速度、隐喻、持续集成、测试先行/测试驱动开发、重构、简单设计、结对编程。 3、肯特.贝克概念中简单设计如下： A）能够通过所有的测试程序； B）没有包括任何重复的代码； C）清楚地表现了程序员赋予的所有意图； D）包括尽可能少的类和方法。 4、 Demeter（迪米特）法则，也称为LoD法则、最少知识原则，指一个对象应当对其它对象尽可能少地了解，通俗地说就是“只与你的朋友通讯”、“不要和陌生人说话”。 5、结对编程技术被誉为XP保持工作质量、强调人文主义的一个典型实践，有助于协作的流畅、知识的交流共享和提高团队的稳定性。 6、原则是代码建立后即集成到完整代码库。由此集成后，代码库和整个系统即建成和测试完成。持续整合只是提高快速软件交付和集成缺陷早期探测的一个极限编程的原则。持续整合理论上是指随时有可传输的工作产品。

7、 XP 极限编程用语中“caves 和 common”指的是，为团队成员创造的两个分区。公共范围是一个公共的空间，在此常有渗透沟通和协作。洞穴区域是一个私人的交易预留空间，需要一个孤立且安静的环境。为了维护公共领域，每一名团队成员应当工作于一个且是同一个的项目上。

-----------------------

特征驱动开发（FDD）是一种简单的便于理解的构建产品或者解决方案的方法。其已经成为最广泛应用的快速软件开发方法。 1、特征驱动开发（FDD）有一系列良好的实践：领域对象建模、按照特性开发、类（代码）拥有权、特性小组、审查、配置管理、定期构建、可视性进度报告。 2、特征驱动开发（FDD）的五个步骤： A) 开发整体模型； B) 建立特征清单； C) 依特征做规划； D) 依特征做设计； E) 依特征进行建立。动态系统开发方法（DSDM），也称为业务中心框架开发方法。它倡导以业务为核心，快速而有效地进行系统开发。它的基本观点是任何事情都不可能一次性圆满完成，应遵循二八原则；实施思路是在固定的时间进度和可用资源情况下，力争最大化满足业务要求。 1、 DSDM开发过程被形象地称为“两张披萨和一块奶酪”，它的周期有以下7个阶段： A) 项目准备阶段； B) 可行性研究阶段； C) 业务研究阶段； D) 功能建模阶段（冲刺式）； E) 系统设计编程阶段（冲刺式）； F) 实施阶段； G) 项目后期。

2、 DSDM的哲学是“足够就好，无须过多！”。 3、 DSDM在功能建模阶段会产生以下产物：带有优先级的功能、功能性原型的评审文档、非功能需求、实施计划。

----------------------------------------------------- 水晶(Crystal)方法体系与XP一样，都有以人为中心的理念，但在实践中有所不同，它探索了用最少纪律约束而仍能成功的方法。 1、 Crystal系列方法分为Crystal Clear（透明水晶）、Crystal Yellow（黄水晶）、Crystal Orange（橙水晶）、Crystal Red（红水晶）。重要性根据项目中的错误引发的后果分为：C-不舒适、D-经济损失、E-严重经济损失、L生命危险。 2、水晶方法采用了一种比例的方式以匹配项目，它拥抱很多其它的敏捷原则： A) 频繁地交付； B) 反思改进； C) 渗透式沟通； D) 个人安全； E) 焦点； F) 与专家用户建立方便的联系； G) 配有自动测试。 3、反思提高研讨会是水晶方法论的基石。 4、水晶架构是迭代的，它的三个基本过程： A) 章程； B) 交付迭代； C) 项目总结。 5、水晶纲领包括： A) 建设团队； B) 做探索性的360； C) 为团队定义实践标准； D) 建立初始项目计划。精益开发（LEAN）不是一种敏捷的方法，但是精益和敏捷的价值观是密切相关的。Lean是系统的思想，Kaizen（持续改善）是一个手段。

------------------ 1、精益的7大原则： A) 消除浪费； B) 加强学习； C) 尽量晚一点做决定； D) 尽快交付； E) 授权给团队； F) 建立无暇的产品； G) 窥其全貌。 2、精益生产理论是指估算浪费，价值流程图是敏捷采用的精益生产分析技能，用于价值的流动分析。执行价值流程图包括以下5个步骤： A) 确认产品，客户和范围（即流程的始末）； B) 地图作为团队或者个人现时价值流，确认流程步骤，延时和信息需求。估算流程步骤的持续时长和前置期持续时长（lead time durations）。前置期是指在发生前一项流程或者事件需等待的时长； C) 分析价值流程图来确认浪费存在的地方（比如前置期）和流程可完善的地方（流程时间通常认为是价值增加时间，但是应尽量减少整个流程的时间，由此来缩短向客户交付价值流的时间）； D) 通过分析，总结出一份展示价值流应努力达到的前景或者目标的未来价值流程图； E) 通过流程完善活动或者其他方法来达到目标的一些工作。 3、价值流程图识别出来的可完善的地方和浪费的形式非常多，可用WIDETOM来记忆：W-waiting 等待； I-inventory库存； D-defects 缺陷； E-extra processing 额外流程； T-transportation 运输； O-over production 过度生产； M-motion 动态。 4、精益投资组合管理(Lean Portfolio Management ) - 选择项目以最大化投资回报的方法： A) 投资组合应包括最低市场特征（MMF），以便快速交付； B) 尽量减少在制品。 5、最小化可交付的特性（MMF）–为最终用户提供价值的最小功能集. 一个 MMF是最小粒度且有商业价值的特性。MMF 被放在一个队列中维护，（很像 Scrum中的产品 Backlog），但对队列的大小有严格的限制（James 认为应该是两到三个，最多七个）。

看板开发，规则简单，但其有效实施依赖于对原理的理解、对原则的坚持和实践的应变。 1、看板开发方法使用一个拉动系统进行工作，它限制了在制品（WIP）的数量，这样可以帮助识别开发过程中产生的问题和最小化浪费。 2、看板开发方法的5个核心实践如下： A) 可视化工作（价值）流； B) 限制在制品的数量； C) 度量和管理流动； D) 协同改进； E) 显式化流程规则。

敏捷领导者 1、服务型领导的主要职责：保护团队不受干扰、移除工作中的障碍、沟通项目愿景、为团队带来食物和水。 2、在一个自主管理的团队中，仆人式领导是促成者，倾听团队的需求，清除团队障碍并为提高生产率提供工具和其他支持。 3、敏捷领导者常见的行为准则如下： A) 教授团队成员自主决策敏捷实践和方法； B) 允许团队自主管理和自我约束； C) 授权团队适当的决策； D) 激励团队创造力和探索新技术； E) 阐述产品愿景，持续进行愿景激励以完成整体目标； F) 移除团队遇到障碍和问题； G) 宣传敏捷的价值观和理念； H) 确保所有干系人有效协作； I) 依据工作环境改变领导风格，以此确保有力支持敏捷价值和原则。不仅在敏捷中,富有动力的团队对其他任何项目都至关重要。富有动力的团队运作更流畅,生产效率高,表现超越期望值。可提高动力的简单步骤包括: 1、共度黄金时间,团队成员可在个人层面上了解他人以此营造社区氛围; 2、提供反馈,指导和训练,赞扬和感谢团队成员的出色工作,同时为技能和能力提升提供指导和训练; 3、授权,授权团队成员作关键决策,在此期间,建立信任并显示领导对团队能力的信任。

价值评估工具和技术 1、投资回报率（ROI）是指通过投资而应返回的价值，ROI=年利润/投资总额×100%。 2、净现值（NPV）是指投资方案所产生的现金净流量以资金成本为贴现率折现后与原始投资额现值的差额。PV=FV/(1+R)^N。 3、内部收益率（IRR）有助于评估计算项目投资的回报期，内部收益率就是净现值（NPV）等于0时的折现率。 4、挣值管理（EVM）不仅能反映出目前的项目状态，也能对项目未来的完成情况进行预测。它的最大好处是可视化管理，通过图表技术，使得大家对项目状态一目了然。 5、关键指标绩效（KPI）：进展率、剩下的工作、可能完成的日期、可能完成时需要的成本。产品列表排列的优先级标准： DIVE 1、依赖关系(Dependencies ) 2、风险(Insure against risk ： business and technical) 3、商业价值(Business Value) 4、估算工时(Estimated Effort)

价值优先级排序方案 1、基于客户价值的优先级排序 A) 简单的方案，完全基于主观经验； B) MoSCoW优先级方案，M-必须做的、S-应该做的、C-可以做的、W-不要做的； C) 虚拟钱币，利用固定钱币去购买特征，最多的为优先级最高； D) 100点方法，每个相关方决定如何分配自己的100点数，点数最高的优先级最高； E) Kano分析，它定义了三个层次的顾客需求：基本型需求、期望型需求和兴奋型需求； 2、相对优先级或排序就是按照特性的相对大小，从上往下进行排序，依次为：高、中、低；依据风险来优先处理特性,可运用风险-价值指标。风险-价值指标含4个象限,横轴表示价值,竖轴表示风险。用户故事被分配到其中一个分类/象限:低价值,低风险;低价值,高风险;高价值,低风险;高价值,高风险。成本-价值指标同样可用这种方式形成。敏捷中所有的优先化都是“相对的”,也就是说一个用户故事只是相对优先于其他用户故事,而非在固定规模上得到优先处理；相对级别/优先级是指根据团队对优先的定义,对一列清单(比如用户故事,叙事诗,任务,缺陷等)

软件开发中的测试和验证 1、探索性测试，核心思想是：测试是一个不断学习、不断探索的创造性过程。它将戴明环（PDCA）做到了极致。 2、可用性测试，指的是让一群有代表性的客户对产品进行典型操作，同时观察员和开发人员在一旁观察、聆听、做记录。可用性有5个指标：易学性、易记性、容错性、交互效率和用户满意度。可用性测试适用于解决以下问题： A) 确定测试产品的可用性水平； B) 与预期目标、竞争对手、老版设计相比的可用性水平； C) 比较不同方案，确定哪个方案更可行； D) 现测试产品的可用性问题。

持续集成的步骤如下： 1、持续集成服务器不断检查版本服务器上的代码状态，看代码是否有更新； 2、如发现代码有最新提交，那么就从版本服务器上下载最新的代码； 3、代码完全更新后，调用自动化编译脚本进行编译； 4、运行所有的自动化测试； 5、进行代码分析； 6、产生可执行软件，能够提供给测试人员进行测试。

测试驱动开发（TDD）要求先编写测试代码，然后只编写使测试通过的功能代码。它有助于编写简洁可用和高质量的代码，并加速开发过程。 1、测试驱动开发的基本过程如下： A) 快速新增一个测试； B) 运行所有测试（有时候是部分），发现新增的测试不能通过； C) 做一些小改动，尽快让测试程序运行，为此可以在程序中使用一些不合情理的方法； D) 运行所有的测试，并全部通过； E) 重构代码，以消除重复设计，优化设计结构。 2、测试驱动开发不是一种测试技术，而是一种分析技术、设计技术，更是一种组织所有开发活动的技术。它具有以下优势： A) TDD根据用户需求编写测试用例，对功能的过程和接口都进行了设计，而且这种从使用者角度对代码进行的设计通常更符合后期开发的需求。 B) 出于易测试和测试独立性的要求，将促使我们实现松耦合设计，并更多地依赖接口，提供系统的可扩展性和抗变性； C) 将测试工作提到编码之前，并频繁地运行测试，可尽量避免和尽早发现错误，降低了后期测试和修复的成本，提高了代码质量； D) TDD提供了持续的回归测试，可以重构代码； E) TDD所产生的单元测试代码就是最完美的开发者文档，它展示了所有的API是如何工作的，并且是同步的、最新的； F) TDD可以减轻压力、降低忧虑，提高团队对代码的信心和对代码重构的勇气； G) 快速地提高了开发效率。

验收测试驱动开发（ATDD）技术使得测试的焦点从代码本身转向业务需求，它的测试案例代表了功能在验收测试水平上所被期望的行为。它包含讨论、提炼、开发和演示四个阶段： 1、 Discuss 讨论：敏捷团队和客户或者商业干系人详细讨论用户故事,包含用户故事应有和不应有的预期行为； 2、 Distill 提取：开发团队研习讨论中的条目并提取成可验证和确认这些行为的测试。提取流程中, 整个团队应充分认识“完成”对用户故事的意义,这正是验收标准所在； 3、 Develop 开发：提取后,团队开发测试代码和产品代码以产生产品特性； 4、 Demo 示范：产品特性开发后,团队向客户或商业干系人展示以获得反馈。

敏捷章程的一些实际应用有以下几部分： 1、在实际项目开始前，作为冲刺0的一部分； 2、通过高级管理层进行签署，并且授予团队资源和权利； 3、如果可能，在这份文档里也会写出团队成员的名字； 4、解决项目的5W1H（What，Why，Who，When，Where and How）; 5、类型项目章程，但详细程度不同，敏捷章程不是很详细，并且关注于渐进明细； 6、内容包含概要需求、关键的成功要素、里程碑和初步的预算； 7、必须为团队授权进行敏捷过程定义； 8、敏捷章程不是可有可无的，是必需的。

完成的定义（DoD），在敏捷软件开发中存在多级不同的完成定义，包括冲刺的DoD、发布的DoD、用户故事DoD、每日DoD和每周DoD，DoD应该由干系人共同认可。 1、冲刺DoD，是最初DoD应用的地方，常见的冲刺DoD条款有以下几个： A) 所有完成的用户故事得到产品负责人的验证； B) 所有的代码得到静态分析，纠正最高级别的不符合项； C) 所有新增代码得到人工评审； D) 所有完成的用户故事都有对应的测试用例。 2、发布DoD的典型条款有如下几条： A) 完成发布的规划所要求的重点内容； B) 通过发布的全量测试，回归测试范围是全范围的，回归率不低于50%； C) 修复所有等级为1、2、3的缺陷，4级及4级以下的缺陷不超过200个。1、2级缺陷必须修复，3级缺陷经过带缺陷发布审批后可以发布。 3、用户故事DoD有以下几个条款： A) 用户故事最终描述符合INVEST原则； B) 用户故事得到测试用例的对应覆盖； C) 用户故事得到对应的自动化测试用例； D) 用户故事得到用户代表使用并初步认可。客户和产品负责人负责编写用户故事。

最小价值产品（MVP）是一个新产品的版本，允许团队以最小的付出收集客户最大量的有效的知识它使团队可以以最少的努力收集最大数量的经过验证的客户了解信息。

在敏捷设计流程中，原型有助于客户了解当前设计状态。3 种常见的原型是 HTML，书面（即概述）和线框。线框图是由一些简单的方框组成，用来在用户界面上显示元素的位置、界面布局和软件功能。 1、线框图的主要功能如下： A) 显示界面元素； B) 显示这些元素是如何组织在一起的； C) 显示用户界面如何工作； D) 显示用户如何与程序或者网站进行交互。 2、线框图可用很好地用于敏捷项目： A) 线框图鼓励团队成员积极交流，协同工作； B) 线框图是轻量的，并且是易于理解消化的，而不是繁琐的文档； C) 线框图可以获得用户和客户的早期反馈，并且是持续性的反馈； D) 线框图允许在项目开始时使用交互式的草稿图，再逐步演化为最终设计。人物画像可以让开发人员快速地知道关键相关方所感兴趣的事情，为开发人员提供快速的指导。 1、人物画像将： A) 提供用户描述的原型； B) 植根于实际； C) 以目标为导向，更加具体和相关； D) 是有形的、可以行动的； E) 使人们更加聚焦。 2、人物画像不能代替需求，但是它们可以代替争执。信息雷达图可能会呈现以下的数据： 1、所交付特征的数据和没有交付特征的数据； 2、谁工作在哪件工作上； 3、这一轮迭代所选择的特性； 4、速率； 5、威胁和问题列表； 6、故事地图； 7、燃尽图。

敏捷的可视化 1、燃尽图（Burndown Chart）可以直观地展现项目总体进度，它展示了时间和项目剩余总体工作量间的关系，有效的描绘了团队进展的速度和生产能力。燃尽图可以判别完成的时间，但不能判别完成的内容。有发布燃尽图和迭代燃尽图等。 2、燃起图（Burnup Chart），它能够直观展现项目时间与已完成的工作间的关系的一种图表，根据每天完成的story情况动态展现工作成果的曲线。 3、停车场图表用来对用户故事按主题进行分类和管理。包括确定主题的名称、用户故事的数量、其包含的故事点、展现故事点完成百分比的进度图表。 4、看板图是一个拉动式的图表，用来帮助团队理解当前做得如何，以及下一步要做什么，令团队能够自我指导。在看板图、燃尽图和停车场图三者之中，看板图的信息最详细。看板方法关注的是价值的流动效率。 5、累积流图（CFD: Cumulative Flow Diagram)是看板方法里的核心度量，可以很好地反映工作项在每个流程环节的流动问题。累积流图可以用来分析在制品、平均周期时间、吞吐率(Throughput)、需求范围的变化、预测交付日期。 6、价值流程图是敏捷采用的精益生产分析技能，用于对形成客户产品或服务的原料和信息（即价值）的流动进行分析。一张价值流程图可能用于分析信息或者材料的流动，从它们的源地到终点，以此来识别浪费区域，识别出的区域成为流程可完善的地方。 7、停车场图快速的看一下已经完成的特性的等级。 8、“信息雷达图”上是记录所有团队成员在规定日期内完成任务的板；“信息雷达图”是一台高大，可见的显示器，软件开发团队用它来跟踪进展；“信息雷达图”和精益方法中的“可规划控制”类似。

协同工作 1、工作坊是一个多人共同参与的场域与过程。以下的一些技巧可以让工作坊更加有效： A) 让更多的人参与进来，可以有不同的观点，因为其会带来有价值的想法和解决方案； B) 在讨论中应避免某个人主导，应该让团队集体产生想法； C) 轮流发言，每个人都应该做出贡献，而不仅仅是一个被动的听众。 2、头脑风暴是指一群人或小组围绕一个特定的兴趣或领域，进行创新或改善，产生新点子，提出新方法。头脑风暴可以通过安静地写作、循环方法或无限制的方式实现。头脑风暴的好处有： A) 提高创造力； B) 建立更好的社交圈和职员关系； C) 营造更让人愉快的工作环境； D) 创造新市场、新产品、新服务； E) 创造更好的产品和服务，实现更好的管理； F) 减少冲突和争论，提高生产力和可信度。团队可以使用头脑风暴来完成以下几种功能： A) 确定特定任务的产品角色； B) 为发布版本确认最小市场特性； C) 识别影响项目的风险； D) 制定针对特出问题的解决方案。

协作游戏 1、回想未来。目的是理解客户所定义的成功。 2、修剪产品树。目的是休假产品以符合市场需要。 3、高速游艇或帆船。目的是找出客户不喜欢你的产品或服务的地方。 4、买特性/虚拟货币。项目发起人要求团队通过考虑一面财务价值以及缺乏这个特性的负面财务影响来确定它们的优先级，目的是对特性进行优先级划分。 5、“大富翁”法，使用道具货币，团队投钱； 6、性价比。目的是对待开发项进行优先级排序。 7、 Bank-for-the-Buck：审视价值与成本的游戏。 8、产品盒（Vision Box）：设计产品的虚拟盒子（确定最重要的前 3 项工作）以确定优先级。

温馨而舒适的环境是在设计团队氛围时重点考虑的方面,它可以促进有效沟通,提升创造力和激励团队成员。构建良好的敏捷团队氛围的指导包括: 1、团队成员的协作; 2、减少非必要的干扰/分心; 3、为信息发射源提供专用白板和墙面空间; 4、为每日站立会议和其他会议提供空间; 5、结对工作站;其他人性的措施如植物和舒适的家具。项敏捷项目中,典型的信息发射器包括:项目燃尽图,任务板,燃起图,缺陷图表。

积极倾听 1、层次一：内心收听。认真听对方讲话，但会根据自己的理解重新解读。 2、层次二：专心收听。设身处地地为说话人着想，完全专注他的话语本身。 3、层次三：全心收听。结合具体的环境用心收听每句话，包括说话人的语气、姿势等。积极聆听的基本包括: 关注当下,集中精力于演讲者; 作笔记,不打断; 用意译来确认和回顾所收听的内容; 讲话结束时为后续归纳对话内容。擅用开放式问题,适当肢体语言和沉默来提高聆听技巧; 积极倾听包括听，理解，保持和积极响应，但不包括记录冲突的解决技术级别描述处理方法 5、世界大战摧毁对方很少或没有语言交流做任何必要的事情来防止大家彼此伤害 4、圣战保护自己的族群成了焦点语言是意识形态再次构建安全框架，使用“穿梭”外交，把一个派系的想法带给另一个派系 3、争辩胜利重于解决语言包含个人攻击迁就：当问题本身更重要时交涉：冲突的事情可以分解的情况下得到事实：搜集数据，建立事实 2、争执个人保护胜于协作语言是戒备的但允许解释支持：允许对方解决问题

安全 1、解决问题信息分享和协作语言是开放的并基于事实协作：寻求双赢的局面共识：学习各自的想法，达成一致敏捷冲突的三步干预方法：您是否与_________分享了您对此的疑虑和感受？ _______应该知道你的担忧。如果我和你一起去，会有帮助吗？我可以告诉_________你有这些顾虑吗？参与式决策方法 1、简单投票，让团队用手势的方式表示“同意”或者“反对”，这是最快捷的方法。 2、拇指向上/下/边。 3、决策分级，它给予参与者更多的选择，将参与者的回答画成线，整改团队就可以看到集体的意见了。 4、 5个手指投票，0-绝对支持、1-支持、2-支持但有很少保留、3-关注，需要讨论、4-不赞成，需要讨论、5-停，反对这个决策。

用户故事 1、好的用户故事包括3个要素： A) 角色。谁要使用这个功能； B) 活动。需要完成什么样的功能； C) 商业价值。为什么需要这个功能，这个功能带来什么价值。 2、一个良好的用户故事应遵循INVEST原则： A) 独立的（Independent）。 B) 可协商的（Negotiable）。 C) 有价值的（Valuable）。 D) 可估算的（Estimable）。 E) 小的（Small）。 F) 可测试的（Testable）。 3、 3C：Card卡片 Conversation对话 Confirmation确认。卡片记录，记录用户对话，需要与干系人确认。 4、基于不同的技术对故事进行分割，有以下几点好处： A) 减少结构风险 B) 更容易排列用户故事优先级； C) 因为特征的完成，软件可以较早发布； D) 有利于自动化测试。 5、需求层次的结构：特性—>史诗—>用户故事—>任务。 6、用户故事地图，为敏捷团队提供了一种实现“用户体验是一个完整的过程”的产品管理方法，一个打通“产品规划”与“开发计划”的工具。本质上等同于传统项目管理中的项目计划，它将用户故事/产品特性按逻辑主题排列，作为开发的计划。 7、故事地图中显示每个版本中用户故事/史诗的分类方式： A) 主线(backbone)：基本功能 B) 行走的骨骼(walking skeleton) Walking Skeleton：最小的功能集 C) 附加功能：其他功能 8、梳理待开发项的步骤如下： A) 产品负责人和团队一起讨论用户故事的背景、业务目标、用户角色、用户场景、业务流程、业务规则，保证团队理解充分且无异议； B) 产品负责人和团队一起讨论界面和交互流程，画出低保真和交互流； C) 产品负责人和团队讨论用户故事的测试要点、技术实现方案、可能存在的技术风险，必须输出的测试要点（验收标准），测试要点形式不限。 D) 团队估算出用户故事的规模（故事点数），对于过大的用户故事要拆分成小故事； E) 产品负责人对用户故事排优先级。

估算是Scrum和其它敏捷过程的核心实践 1、宽频德尔菲是基于团队的估算方法，这种技巧要求一组专家匿名提交估算，这有助于将“从众效应”和“光圈效应”的影响减到最小。 2、宽频德尔菲技术通常用“计划扑克”来实施，这个技术的转化使用了一个快速的、合作的过程，并结合了所有基本的宽频德尔菲元素。 3、相对大小和故事点，这个方法可以解决以下两个问题： A) 人民不擅长精准地预测工作的绝对大小； B) 估算过程是困难的、不受欢迎的。 4、亲和估算是一种用于快速和更容易地估算大量用户故事的技术。其要求产品待开发项列表中，开发项最小的大小为20.

5、理想时间和耗用时间。理想时间代表时间量,即不受会议,个人生活,非工作日或其他拖延,障碍和分心的干扰的情况下,相对于待办事项中其他用户故事,单独个人建立,测试和发布用户故事所花的时间。理想时间代表时间量,即不受会议,个人生活,非工作日或其他拖延,障碍和分心的干扰的情况下,相对于待办事项中其他用户故事,单独个人建立,测试和发布用户故事所花的时间。问题解决的步骤 1、收集数据。常用工具如下： A) 时间表，工作相似的人分在同一组(评估—>学习。 B) 多层次的改进，敏捷项目中多层次的持续改进包括：结对编程、每日立会、评审回顾会、产品发布。 C) 持续改进的流程，可使用系统性思考、过程分析、价值流程土等来评估流程和需要改进的领域。 D) 价值流分析，目标是通过优化每一个流程中的环节，消除浪费，为客户提供更优的价值。 2、团队参与解决问题，其作用如下： A) 通过向团队寻求解决方案，可以让团体成员达成一致； B) 可以让团队获得更广泛的知识； C) 团队的解决方案往往是比较实用的； D) 通过讨论，人们在一起工作可以相处更好的方法； E) 团队在一起可以更加自信。周期时间（应该随着迭代期的推进一直缩短直到其达到最佳水平） 1、周期时间：实际花费在工作项目上的时间总和； 2、前置时间：从客户创建请求开始到这项工作被完成。 3、吞吐量：生产的能力 4、周期时间=WIP/吞吐量利特尔法则可以表述为：生产率=在制品（WIP）/周期时间。长周期将严重影响生产率。项目和质量标准指的是要匹配项目的适用性。它包括以下内容： 1、通过测试和客户验收来度量产品质量； 2、尽可能多地做自动化测试； 3、确保测试成为每个冲刺的一部分； 4、在下一个冲刺中至少修复90%的缺陷； 5、鼓励质量控制和质量保证人员与开发人员、业务人员一起工作，了解每个特性的验收标准。失败和成功模式 1、失败的模式包含以下5种情况： A) 犯错误； B) 宁可失败也要选择保守； C) 创新而不研究； D) 不能始终如一； E) 使用纪律和容忍来应对。 2、成功的模式包含以下4种情况： A) 善于四处寻找； B) 有学习能力； C) 具有可塑性； D) 以工作为自豪。

项目管理办公室的类型如下： 1、价值驱动型； 2、面向创新型； 3、多学科型。

敏捷中，有效的“知识分享”是成功的关键因素，它需要所有的团队成员和干系人对关键信息的近乎实时的交流。可使用以下方式促进知识分享： 1、使用全面专家/多功能团队 2、自主管理和自我约束团队 3、协作 4、每日站立会议 5、迭代/冲刺计划 6、发布计划 7、结对编程和结对轮换 8、项目回顾和反思 9、现场客户支持

燃烧率：每次迭代的人工（最大部分）和其他成本，用于准备预算或 EVM。是一个迭代期间团队花费金额的总和。费用迅速上升，有两种可能的情况：团队加班或人员增加累积流图(CFD) -一个实践工具，可以帮助我们看到 WIP 的状态、项目的步调、并且快速识别出交付时间存在的风险以及瓶颈。

决策谱（由 Jim Highsmith 提供） - 一种参与式决策制定工具，允许人们表明对决策的支持/保留。 DRY (don’t repeat yourself) –一种编程哲学，要求程序员不要重复相同的代码。经验过程控制(Empirical Process Control) –关于项目的决策是基于项目执行期间的持续观察和实验而不是预先计划。史诗故事(Epic Story) – 一般的故事是大型用户故事，可能横跨几个迭代周期。它也被称为一种能力。可以分解为较小的用户故事，可以在产品 backlog 的底部找到。当它们被逐渐分解后逐渐逐渐移向顶部。逃逸缺陷(Escaped Defect) – 客户发现的问题或错误，即逃过验证，验证和验收测试。功能缓冲区(Feature Buffer) – 用于管理风险，以确保可以提供必须具备的功能。强化迭代(Hardening Iteration) (Iteration H) –为产品准备产品的最后一次迭代，通常涉及最终测试，管理，文档。帕累托原则 - 也称为 80-20 规则，对于敏捷项目， 80％的最有用的功能可以在 20％的努力中完成，强烈建议关注“20％”。项目数据表（PDS） - 是所有关键业务和质量目标，产品功能和项目管理信息（包括里程碑，风险等）的单页摘要。产品路线图(Product Roadmap) - 提供功能发布里程碑的高级概述。为产品负责人所拥有的。,常用作特性优先处理,特性归类和粗略时间框架确定的工具。创建产品路线图需遵循4个步骤: 确认需求(这些会成为产品待办事项的一部分)；将需求分类或分定主题；评估相对工作量(例如,计划扑克或者亲和估算)和优先化(价值)；评估粗略时间框架(评估高速和冲刺持续时间,以及粗略发布时间)。面对面沟通 3个组成部分： 1、口语表达传递的信息是 7% 就是语音语调(verba口头表达)。 2、语言就是文字表达传递的信息是 38%。 3、肢体语言传递信息是 55%。 chaos是无政府状态这种状态是混乱且无序的。 ROIT 回顾会议有效性度量。关键步骤开场，收集数据，生成灵感，决定要做什么，关闭回顾 ARCS模型是由约翰·M·凯勒（John M Keller）教授于20世纪80年代提出的一个教学设计模型。所谓ARCS，是Attention（注意）、 Relevance（关联）、Confidence（信心）和 Satisfaction（满意）四个英文单词的首字母。流逝的时间指的是时钟走过时间的总和或者日历活动。错误反馈率指的是当解决了现存缺陷的时候，新产生的缺陷数量。内部回报率(IRR) 是使现金流出量的现值和流入量的现值之间的差额等于零的折现率，在比较两种不同现金流的价值时是最好的参数。团队需要在下面的四个领域进行持续的评估和做出合适的调整：产品价值、产品质量、团队绩效、项目状态。收益的分类 1、新收益：增加新客户而带来的收入； 2、留存收益：如果不开发项目或者主题公司会损失收入； 3、增加收益：现有客户可以获得的额外收入。

分布式团队要首先考虑文化的差异性，尊重不同问题化的差异，致力于项目的成功。对于分布式团队除了关注文化的差异，也要考虑沟通的多样性。 Shewhart控制图 --控制限度可能会应用在敏捷项目中,它通过设置一个客观的限度,来指明一个过程是否受控制,或者是否稳定或者是否无缺陷(比如,在平均值的三个西格玛内)。三个西格玛的控制限度通常是用在休哈特控制图上。一个西格玛是指一个标准偏差。所以三个西格玛则是指在正负方向上均离平均值三个标准偏差的限度。这种限度适用于能获取正态分布曲线的普通数据。有效沟通是敏捷的奠基石。沟通是在不同部分传递信息。沟通管理是敏捷的一个知识和技术区域。PMI除此之外有几个关于沟通的定义。沟通计划:确定项目干系人信息和沟通的需要信息分布:适时地提供给项目干系人需要的信息 .绩效报告:收集,分派绩效信息,包括状态报告,进展衡量,预告管理项目干系人:管理沟通去满足要求还有和项目干系人一起解决问题。当在规划会议中风险被分析和处理，敏捷的团队关注于定性类型的风险分析。迭代H也称为强化迭代，没有新的功能被开发，而是已有功能要测试。迭代0关注建立工具和环境，并验证方法，风险燃尽图将是展示团队正在进行工作的好方法。虽然它们没有构建任何业务功能，但是希望能够减少一些技术风险，并证明使用了一些关键的方法闪电战计划包含故事的依存关系和涉及使用卡片来计划项目，其中时效性、任务和故事的依存关系被确定和考虑。

守破离的三种领导策略：守（指导型）--破（教练型）--离（顾问型，建议）。

11. 概念

敏捷最常用框架：SCRUM

3个角色 1）产品负责人(ProductOwner PO)：

客户/业务代表定义所有产品功能：必须参与所有的产品梳理会，如果不能参与，需要调整时间，如果PO仍旧没有时间，需要找他的全权代理人（Backup）参加，如果还不行，那必须更换PO 决定产品发布的内容及日期对产品的投入产出负责根据市场变化对需要开发的功能排列优先顺序：只听PO的合理的调整产品功能和迭代顺序认同或者拒绝迭代的交付确保开发团队知道产品待办事项列表 2）Scrum Master(SM)：

项目早期SM和PM相对统一（制定规则、管理期望、管理干系人、制定沟通策略、管理承诺等）项目执行起来则SM和PM进行切割（不做决策）鼓励言论自由保证仪式的完整性团队有问题，优先内部讨论解决保护团体一个整体 3）开发团队(Dev Team):

自主选择：自主决策问题解决的方式方法全职能：技能复制，团队成员技能能力差不太多全职：全勤投入到团队工作中跨团队本身不进行解决：去中心化，高级带低级，提升技能，但并不分配任务决策在团队内平级

3个工件： 1）产品待办事项列表 Product Backlog---排了序的需求池

产品需求的列表包含业务需求、技术需求、NFR非功能性需求（技术优化、合规需求）等理想情况下，每一个待完成的工作都将对客户产生价值 PO对该列表进行优先级排序每个迭代开始前，优先级排序还需要再修正待办事项列表中的条目以用户故事的形式呈现遵循DEEP模型：

Detaild---适当的详细程度 Estimated---被估算的：PO & SM 预先估算 Emergent---涌现的 Prioritized---排了优先级的 2）迭代待办事项列表 Sprint Backlog---迭代完成的需求列表

Product Backlog的子集，只记录当前迭代的工作将用户故事拆分成任务，团队成员主动领取任务团队成员有共同的迭代目标，未交付可工作的成果而努力团队成员可以添加、删减或者更改迭代中的任务迭代列表中的任务进行了估算，剩余工作量的估计每天需要更新 DOD（Definition Of Done完成的定义）核心就是做到什么样就是完成了

可以通过流程或者本身交付物来进行限定

3）产品增量 Product Increment---交付物

团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付每次交付的用户故事必须符合验收条件每次交付的增量成果必须处于可用状态，而不管PO是否决定发布这个用户故事（交付和上线） 5个活动（仪式）

时间箱

固定时间、固定活动

优势：专注、增加创造力、时间的价值实现程度、可用时间比较多

待办事项梳理会（DEEP）增删改查用户故事估算规模故事优先级排序拆解用户故事可以邀请利益相关者来进行参与和评审可以有技术相关的讨论用户故事 As a【User Role】，作为【用户角色】

I want 【Activities】，我想要【活动】

So that 【Reason/Value】以便【原因/价值】

3C Card卡片 Conversation 交谈（语言要一致）， Confirmation 确认

Acceptance Criteria

- Given（在什么样的情景或条件下）