PMI-ACP（103：57- 103）

57/103 高绩效敏捷团队的特征

参与式指导
有效的决策
开放和清晰的沟通
价值多样性
相互信任
管理冲突
清楚目标
明确定义角色和职责
协调关系
积极的氛围

58/103 创建授权团队

敏捷强调 具备授权和积极性 的自我管理团队，他们需要对项目成果充分负责，授权是：

责任和所有权
朝着共同的目标工作
理解为什么要做决策
衡量决策对于所有干系人的影响
创造更多权衡

59/103 自组织团队

敏捷团队领导应该在组织接受基本原则的情况下，描述高层级的迭代目标，让团队确定如何最好的完成工作，而不是提供详细的任务清单：

目标：确立团队的目标与价值
授权：团队要自我抉择如何最好地完成工作
沟通：团队成员之间需要互相了解，互相尊重
可视化：工作任务的可视化
辅导：团队可能需要的培训技术援助
奖励：针对好的团队，要有经济上或象征性的奖励

60/103 服务型领导

也叫仆人型领导。以服务员工为第一要务。更多的是以指导、培养、授权、委派、支持、帮助、称赞、倾听等对待员工

仆人式领导的要求：

倾听：倾听团队成员的内在声音，定期反思
说服：不用职务上的权威在组织内推动决策，而是努力让团队信服
感同身受：每个人都需要别人接纳自己，并且认知自己心灵的独特性
省察：高屋建瓴（瓴：房屋上的瓦），从一个统一的角度来看到问题和形势，帮助理解有关道德和价值观的问题
致力于员工成长：帮助团队里的每个人成长，不仅仅是职业成长，还包括个人成长、心灵成长
预见力：吸取过去的经验教训，了解当前的现实，明白决策可能带来的结果
抽象化：仆人式领导应努力培养自己"宏伟梦想"的能力，能够从抽象化的角度来透视问题，考虑长期目标

61/103 敏捷服务式领导

敏捷坚信自我管理的团队，他们不需要任务驱动，而是自我驱动，需要帮助去凝聚、组建
敏捷管理者用他们的行为去满足团队需要，同时愿意去帮助团队实现目标
在敏捷团队中价值应该被珍视，包括信任、同理心、协作等（超级团结的团队）

62/103 领导 VS 管理

|--------|-------|
| 领导关注 | 管理关注 |
| 人员 | 任务 |
| 授权 | 控制 |
| 做最正确的事 | 把事情做对 |
| 方向 | 速度 |
| 原则 | 实践 |
| | |

63/103 教练和辅导

在敏捷中，指导团队涉及 教练和辅导方法，每部分有它不同的关注和技能去帮助团队交付成果

敏捷教练（一定会要有积极的心态）
1. 跟不同团队共事时具备平衡视角：（不要比较、不要抱怨、环境决定一切）每个团队具备不同的进展节奏，可能会面临制约，需要帮助去克服
2. 忠于团队成员价值
3. 认识社会心理及团队复杂性
4. 运用有效方法解决团队面临的问题
5. 开发方法进行非侵入型干预而改变团队动力（干预的时候，让团队和团队成员感到舒服、认可）
敏捷教练技能
1. 积极倾听
2. 提问
3. 语言和沟通
4. 给予反馈
5. 冲突处理

64/103 情商技能评估框架

【感知】（共情，但不要过于共情）能够准确地认识、承认、参与和理解"情感、归属感"的能力
【管理】（该说的一定要合适的表达出来，不要冷战，不要等别人猜）有效地管理、控制、表达情感的能力
【决策】能够适当运用情感管理变化和解决问题的能力
【实现】能够生产必要的情绪自我激励追求目标实现的能力
【影响】（自己一定要非常自律，知道自己要什么，自己先影响自己，潜移默化中也会影响别人。向积极的人、成功的人、正能量的人去学习 ）能够识别和唤起对自我及他人情感变化的能力

65/103 分布式团队

分布式团队，难以实现集中办公的面对面沟通、渗透式沟通、及隐性知识分享所带来的好处；

对于分布式团队建设：要先想办法改善团队成员之间的关系，借助一些工具改善分布式团队的沟通，例如：视频会议、即时通讯工具、基于展现的应用、交互式的白板等

分布式团队特征如下：

作为一个团队，成员在不同城市工作
每个地区的成员具备不同技能
具有成本效益的均衡分布式团队

66/103 集中式团队

把部分或全部项目团队成员安排在同一公共区域集中办公来合作和分享信息。以增强团队工作能力。项目团队可以在办公区域张贴标语和项目进展图表，以增进沟通和集体归属感

67/103 集中式团队 vs 分布式团队

|----------------------|-------------------|
| 集中式团队 | 分布式团队 |
| 团队成员全部在一个空间里 | 团队物理分布 |
| 问题得到非正式的及时解决 | 正式记录产生的知识 |
| 偶尔的互动会激发生产力 | 确保过程的结构化运用 |
| 团队基于冲刺目标来确定角色 | 通过任务明确定义角色 |
| 集中办公 | 使用视频直播、群聊天等及时信息 |
| 共享区域作为团队渗透式沟通的地方 | 有论坛或企业信息中心 |

68/103 渗透式沟通

同处一室，耳可听、目可视，周遭的信息会潜意识的渗透到人脑，达到沟通的效果

属于水晶方法cystal的一项敏捷原则

69/103 信息发射源

信息发射源，在任何人都可见的地方显示信息。有了信息发射源，大家不需要问任何问题
kanban、燃尽图 / 燃气图、可视化图表等都属于信息发射源

70/103 浪费的表现

|---------|--------------------------------------------|---------------|
| 浪费 | 浪费的表现 | 举例 |
| 工作中途被打断 | 工作开始后，没有完成，被打断 | 代码写完，没有测试 |
| 额外的处理 | 额外的工作，却没有带来更多的价值 | 不需要的文档不需要的认证 |
| 多余的功能 | 不需要的特征 | 镀金技术特征 |
| 任务切换 | 在几个不同的项目中进行多任务切换（多个不同的项目：导致思绪总是要重新切换） | 同时在多个项目中 |
| 等待 | 为了等待审核和批准而延迟 | 等待文档审批 |
| 传递 | 在组织之间沟通、信息交流或交接的过程中产生影响 | 工作交接搬运 |
| 缺陷 | 有缺陷的文档或程序需要纠正 | 软件bug |

71/103 适应性计划与瀑布型计划的主要区别

通过实验和示范的方法来发现真正的需求（适应性计划：不断探索，不断反馈，不断纠正，直到发现真正需求）
计划会在整个项目中贯彻始终（适应性计划：时刻随机应变）
计划在中间不断调整，是经常的事情

72/103 敏捷计划洋葱图

敏捷项目管理简化了繁琐的流程和文档管理，主张团队内部面对面沟通和交流。

敏捷项目中，项目管理计划分不同的等级，可以用洋葱图表示：

愿景（战略目标）->路线图（产品路线）->发布（发布计划）->迭代（迭代计划）-日常（每日计划）

73/103 渐进明细

使计划的严肃性和应变性都得到保证
1. 因为执行计划与编制计划的时间接近，内、外条件不会发生很大变化，可以基本保证完成
2. 第一期实施的结果出现偏差，以后各期计划如不作出调整，就会流于形式
提高了计划的连续性
1. 渐进明细，就是规划时的一种接近值，在项目的前期会进行概要的估算，之后，当开发团队有了新的需求后，再进行更详细的估算

74/103 发布计划

发布计划：可以在前期帮助所有干系人了解发布一个产品需要花费的整体时间。

发布计划可以作为项目小组前进的路标

根据产品愿景，确定优先级，先做最有价值的部分
选择sprint冲刺，一般建议1～4周，一旦固定了sprint长度，就避免在项目实施期间随意更改

Relese1

Product Backlog
1. Iteration 1
  1. feature 1
    1. User Story 1
      1. task 1
      2. task 2
  2. feature 2
  3. feature 3
2. Iteration 2
  1. feature 1
  2. feature 2
  3. feature 3
3. ``
4. Iteration n

75/103 迭代计划

一般在迭代开始之前：制定迭代计划。

目的是为了制定当前迭代的开发目标，以及需要完成的工作（目标 + 具体工作）

迭代计划在迭代计划会后产生，流程过程如下：

讨论用户故事
从Story分解"任务"，团队进行任务估算
团队成员对任务进行认领

76/103 时间盒

时间盒，是一个较短而且固定长度的时间段。

在持续不断的变动中，有一个稳定的点。不让整个交付团队因为无休止的变更造成混乱而失去控制。让交付团队可以集中精力，解决最关键或最优先的问题。

应坚持的原则是：

固定时间长度（一般几天，最高6周），结束的日期不可变更
时间盒内的资源保持稳定
时间盒不应作为绩效考核手段（考核指标应该是最终交付的产品）
要有明确的目标和稳定的范围，减少范围的的变动比例
- 如果时间盒内需要追加需求，需要置换某些用户故事（如果不置换的话，在当前时间盒内可能发生交付延期的情况：可能既交付不了原用户故事，又交付不了新用户故事）
- 并且敏捷教练要进行实践分析。如果有重大变化，应取消当前时间盒，重新计划并执行新的时间盒

77/103 番茄工作法

选择一个待完成的任务，工作25分钟，专注工作，中途不允许做任何与该任务无关的事，当番茄时钟响起，休息5分钟

每4个番茄时间（4*25=100min=1h30min）后，休息时间增加为15分钟，以此循环合适的工作周期

78/103 过程裁剪

选团队：可以决定是增加过程，还是裁剪过程，基于组织的业务需求而定

视组织的具体情况，对过程进行有效的裁剪，只有这样才能增加组织的敏捷性（团队每个人都应该是对项目有实际价值的）

"守"：最初阶段须遵从老师教诲，认真练习基础，达到熟练的境界
"破"：基础熟练后，试着突破原有规范让自己得到更高层次的进化
"离"：在更高层次得到新的认识并总结，自创新招数另辟出新境界

79/103 宽带德尔菲（基于群体的估算方法）

宽带德尔菲 Wide band Delphi，是由PERT和德尔菲法香结合得到的方法，别名"PERT和德尔菲相结合得到的方法"。其主要思路是德尔菲法中参与估计的群体需要进行估计的是三种时间：最乐观时间、最保守时间、最可能时间

基于群体的估算方法，要求一组专家匿名提交估算。将"从众效应"和"光圈效应"的影响降到最低

80/103 计划扑克

宽带德尔菲法技术通常采用"计划扑克"来实施，用卡片中的数字实现估算

参加游戏的人，每人各拿一叠扑克牌，牌上有不同的数字，客户或者产品责任人为大家挑选一个Story并简单解释其功能，以供大家讨论
每个游戏参加者，按自己的理解来估计完成这个Story所需的时间，从自己手里的牌中选一张合适数字的牌，并展示给大家看
游戏参加者各自解释自己选择这个数字的原因，尤其是数字最大和最小的人

|----------|-----------------|
| 牌 | 解释 |
| 0 | 任务已经完成 |
| 1 / 2 | 任务很小 |
| 1，2，3 | 这些用于小任务 |
| 5，8，13 | 这些用于中型任务 |
| 20，40 | 这些用于大型任务 |
| 100 | 这些用于非常大的任务 |
| <无穷> | 任务是巨大的 |
| ? | 不知道完成这项任务需要多长时间 |
| <一杯咖啡> | 我饿了 |

81/103 斐波那契数列（费布纳西序列）

斐波那契数列（费布纳西序列），指的是这样一个数列：0、1、1、2、3、5、8、13、21、34、55···

数列从第3项开始，每一项都等于前两项之和

敏捷中，使用的是改良的斐波那契数列（费布纳西序列）：0，1/2，1，2，3，5，8，13，20，40···

82/103 故事点

故事点数，描述"一个用户故事及其相关努力 "总体规模的测量单元

故事点
1. 是相对测量
2. 用户故事的故事点，互相进行对比
3. 故事点是团队对运用计划扑克（宽带德尔菲、斐波那契数列(费布纳西序列)）等估算技术确定的
4. 故事点对一个项目来说是独特的，不能同其他项目相比较
分配故事点需要考虑的内容
1. 【任务规模】故事规则取决于以下因素：复杂性、投入量、风险大小
2. 【相对价值】故事点数规模的相对测量，绝对值不是很重要
3. 【估算】估算运用基准来完成，相对值被运用
4. 选取最小故事估算价值为一个故事点

敏捷，如何高效估算故事点？

敏捷开发与故事点介绍

敏捷开发的核心理念：敏捷开发不仅仅是一种软件开发方法，更是一种思维方式。敏捷开发鼓励团队快速响应变化，持续交付有价值的软件，并始终将客户的需求放在首位

敏捷开发的核心理念包括：

个体和互动：敏捷开发强调团队成员之间的互动和沟通，认为它们比流程和工具更为重要
可工作的软件：敏捷开发的目标是持续交付可工作的软件，而不是完美的文档或计划
客户合作：敏捷开发鼓励与客户紧密合作，确保软件满足客户的真正需求
响应变化：在敏捷开发中，变化是一种机会，而不是威胁。团队应该灵活地应对变化，确保项目始终与市场和客户的需求保持一致

什么是故事点？

故事点是一种量化任务复杂性的方法。与传统的工作量估算不同，故事点更加注重任务的相对复杂性和不确定性

故事点的估算通常基于以下几个因素：

任务的复杂性：这涉及到任务的技术难度、涉及的系统组件数量、需要的技能和专业知识等。一个涉及多个系统或需要特定技能的任务可能会有更高的故事点
任务的不确定性：这与完成任务所面临的未知因素和风险有关。例如，如果一个任务涉及到新技术或者团队之前没有经验的领域，那么这个任务不确定性就会增加，相应地，它的故事点也会更高
任务的工作量：尽管故事点主要是衡量复杂性和不确定性，但完成任务所需的时间和资源仍然是一个重要的考虑因素。一个需要大量时间和人力资源的任务可能会有更高的故事点

除了上述因素外，故事点估算还可能考虑其他与任务相关的因素，如任务的依赖关系、外部约束等

故事点估算的目的不仅是为了提供一个任务大小的度量，更重要的是为团队提供一个共同的参考框架，帮助团队成员之间建立共识，确保每个人对任务的理解和期望都是一致的。通过使用故事点，团队可以更加系统地进行任务的优先级排序，更加合理地分配资源，更加有效地跟踪和管理项目的进度

为什么需要故事点估算？

故事点与工作量的区别

故事点与工作量，都是估算任务的方法，但它们有本质的区别。

【工作量】

估算注重任务完成所需的时间

工作量估算往往是线性的，即：任务的大小直接与所需的时间成正比

【故事点】

估算注重任务的复杂性和不确定性

故事点估算则是非线性的，故事点估算考虑了任务的各种复杂性和风险，可能会导致任务的故事点远高于该任务实际的工作量

故事点可以使能力不同的成员在估算同一个任务时快速达成一致

例如：一个任务可能很简单，但由于某些未知因素，该任务的不确定性很高，因此该任务的故事点可能会比实际工作量更高。

故事点估算的价值

可以帮助团队更好地规划迭代和发布，团队可以更加客观地评估任务的大小
优化资源分配，团队可以更加合理的跟配资源
提高项目的成功率，确保项目始终与市场和客户的需求保持一致
帮助团队更好地理解和掌握项目的进展和风险
帮助团队建立一种共同的语言和理解，促进团队成员之间的沟通和合作

与传统的工作量估算相比，故事点估算更加灵活和适应性强，可以更好地应对项目中的变化和不确定性。

故事点估算的常见方法 ：

【斐波那契数列】斐波那契数列是一种常见的故事点估算方法，它使用斐波那契数列（如1,2,3,5,8···）来表示任务的复杂性。斐波那契数列的优点是可以提供一个相对稳定的任务大小度量，避免过度估算或低估任务的复杂性
【T恤尺寸法】T恤尺寸法使用T恤的尺寸（如XS、S、M、L、XL）来表示任务的复杂性。T恤尺寸法直观简单，容易被团队接受。但T恤尺寸法有一些局限性，例如：T恤尺寸法不适用于非常大或非常小的任务
【估算会议与规则扑克】估算会议是团队成员共同参与的活动，通过讨论和投票来确定任务的故事点。规划扑克是一种常用的估算工具，规划扑克可以帮助团队成员更加客观地参与估算。规划扑克的使用方法是：团队成员首先独立地为任务估算故事点，然后一起讨论并达成共识（类似"宽带德尔菲-计划扑克"）

如何提高故事点估算的准确性？

团队合作与沟通：团队合作与沟通是提高故事点估算准确的关键。团队成员应该共同参与估算，分享知识和经验，确保估算的准确性和一致性。此外，团队应该定期回顾估算的准确性，根据实际情况调整估算方法和标准
定期回顾与调整：团队应该定期回顾估算的准确性，根据实际情况调整估算方法和标准，这可以帮助团队不断学习和改进，确保故事点始终与项目的实际需求和目标保持一致
使用工具与技术辅助：现代的敏捷工具，如Jira、Trello，提供了许多故事点估算的功能，可以帮助团队更加高效地进行估算。这些工具不仅可以自动计算故事点，还可以提供历史数据和统计信息，帮助团队更好地理解和掌握故事点估算的技巧

面对挑战：故事点估算的常见误区与解决策略

故事点估算虽然有许多优点，但也存在一些常见的误区。

例如：过于注重任务的细节，忽视任务的整体复杂性；或者过于依赖工具，忽视团队的经验和直觉。为了避免这些误区，团队应该持续学习与改进，确保故事点估算始终与项目的实际需求和目标保持一致

在哪一个会议上进行故事点估算？

如果有梳理会，就在梳理会上进行；如果没有的话，就在计划会上进行

估算完成后，可以任意亮牌吗？

不可以，必须一起亮牌，并且在估算过程中，团队成员之间也不可以互相讨论预估的点数

PO、SM，参与估算吗？

不参与，只有开发团队参与估点，注意是"开发团队"，包括研发和测试人员

超过多少点数，用户故事需要重新拆分？

每个团队的基准故事点规模不一样，所以没法给个确切数字，但是建议刚组建的敏捷团队最好不要超过5，后期可以根据团队的反馈进行调整

实际开发中发现了估算失误，要不要修改点数？

不要。估算是为了辅助我们的工作安排，而不是用来管理员工的绩效表现。

为了达到精准的估算而耗费过多的时间精力，这是本末倒置。

很小的需求，也必须要团队集体估算吗？

要。估点是团队对需求来理解对齐的过程，如果需求真的很小，估点的过程也会很快达成一致的，不会耽误大家多少时间

83/103 相对大小故事点估算

团队自己定义故事点
估算应该是将所有的时间都包括的
规模是相对的

84/103 亲和估算（快速更容易地估算大量用户故事）

团队用于快速和更容易地估算大量用户故事的形式

亲和估算，是估算用户故事工作量的方法

亲和估算的优势：

快速简单
决策制定过程透明可见
亲和估算创造了一种积极合作的体验，而非对抗性

亲和估算的步骤：

团队确定相对尺码
将不同规模大小的故事卡片按顺序排列，并贴在墙上
团队成员对每个故事卡片进行规模定义，根据相对尺寸移动
团队完成估算后，产品经理可以对评估进行质疑和挑战，就某个故事卡片重新进行规模估算

亲和估算的步骤（详细介绍）：

【沉默的相对大小】产品负责人向团队提供用户故事，敏捷团队悄悄地建立用户故事的相对大小。团队在水平范围内按升序排列故事。也可以通过重新整理笔记或索引来完成，直到整个团队都对订单满意为止。这个步骤是"静悄悄地"执行的，就像在mute映射中一样，以保持过程的快速和非对抗性
【编辑墙】团队成员在墙上编辑相对大小。此步骤涉及产品所有者（PO）和团队之间的讨论，后者可以根据他们的相对讨论和决策重新排列第一步中决定的顺序
【将项目放入相对大小桶】项目被放置在确定的"桶"中，并根据选择的估计规模进行标记。例如，木桶可以被标记为"非常小、小、中、非常大··"，或者它可以基于一个非线性的刻度来标记，例如1,2,3,5,8···
【产品所有者的挑战】此步骤中的产品负责人可以与团队讨论大小。如果团队确实决定更改一个故事的大小，他们首先将它从墙壁上移除，然后根据与产品负责人的讨论，将它放置在他们得到的修改大小上
【存储数据】在整个团队完成估算之后，将存储数据并记录关联估算。在完成这一步之后，关联估算的过程就完成了

亲和估算：是相对估算的一种形式，其中，团队成员将产品未完项条目组织到产品未完项条目组中（每个产品未完项条目的大小相同），或者团队成员使用类似T恤尺码（如小号、中号、大号、特大号）作为估算尺度

亲和估算的参与者：

项目的产品负责人
交付敏捷团队
敏捷专家

85/103 T恤尺码的估算

一种流行的敏捷相对估算技术：（中码、大码、加大码等）

操作简单

介绍团队使用相对估算的好方法
亲和估算非常有效
在进行用户故事估算前，每个T恤尺码的基准需要由团队决定

86/103 理想时间

在不考虑其他因素的情况下，完成工作需要的时间

理想时间的估算需要基于这样的假设：

所估算的故事，是唯一要做的工作（没有意外的隐性工作，或未了解到的工作）
所有需要的东西在故事开始前都会准备好
故事开发过程中不会被打断

87/103 适应性计划特点

多层级的计划（迭代时有迭代计划、发布时有发布计划、日常有日常计划）
客户参与到团队中
通过不断地反馈进度和推进速度来管理期望值
根据项目特征裁剪过程
根据优先级更新计划
确保估算能够考虑到风险、干扰和团队的可用性
估算的精确度是有一定的范围性
估算时要考虑外部的工作和精力分散的因素

88/103 周期时间

周期时间：实际花费在工作项上的时间综合。当任务进入"工作"栏时，周期时间就开始了
前置时间：从客户发出请求开始到该项工作被完成。即客户等待这项工作被交付的时间

89/103 漏网缺陷

漏网缺陷，也叫作"溜走的缺陷"

客户发现的、试用阶段发现的、产品上市以后发现的、以及应该在迭代阶段发现却没有发现的

不同的项目，溜走的缺陷来源不同，需要进行详细分析，找到缺陷遗漏的原因

90/103 持续集成

持续集成，是一种软件开发实践

持续集成，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，以尽快发现错误

代码质量保障步骤：

统一编码规范
静态代码检查
单元测试
持续集成
代码评审和重构

需求调研（市场需求、用户需求）--> user stories 用户故事 --> themes ～ release user story backlog 用户故事待办 --> 分解 --> sprint user case/task backlog 用户故事任务待办

持续集成的好处：

【减少风险】一天中进行多次的集成，并做了相应的测试，及时了解软件的健康状况
【减少重复过程】通过自动化的持续集成可以将这些代码编译、数据库集成、测试、审查、部署等动作变成自动化的，无需太多人共干预
【任何时间、任何地点生成可部署的软件】利用持续集成，可以经常对源代码进行一些小改动，并将这些改动和其他的代码进行集成。如果出现问题，项目成员马上就会被通知到，问题会第一时间被修复。不采用持续集成的情况下，这些问题又可能到交付前的集成测试的时候才发现
【增强项目的可见性】有效决策，有些持续集成系统可以报告功能完成度和缺陷。趋势呈现：如构建成功或失败、总体品质以及其他的项目信息

91/103 探针

探针Spike**英[spaɪk]**这个术语来自"极限编程（XP）"

一个探针spike，指的是一个用来探索/寻找潜在的解决问题的方法

迭代前工作量不好估计
敏捷开发造成技术方案不确定，无整体规划
迭代中方案变化，交付风险大，基于风险的探针spike

92/103 测试驱动开发（TDD test-driven development）

敏捷测试｜聊聊测试驱动开发_测试驱动开发模式-CSDN博客

测试驱动开发TTD，是指在编写某个功能的代码之前先编写测试代码。然后编写使测试通过的功能代码，采用"测试-编码-测试"的方式积累代码

优点：

使开发者从使用者的角度出发，深入思考用户需要的功能
缩短了决策反馈链，降低返工代价
生产出内部质量尽可能好的软件
自动化的单元测试和组件测试的安全保障，使程序员可以频繁的重构

93/103 验收测试驱动开发（ATDD）

ATDD 验收测试驱动开发，不是一种测试方法论，而是一种开发方法论

产品、开发、测试，都需要参与到 ATDD验收测试驱动开发中来

在"ATDD验收测试驱动开发"活动中，团队需要就需求''定义出：期望的质量标准和验收细则'

4 个阶段

讨论，收集验收标准问题
提炼，准备好测试
开发，直到通过测试
演示，客户验证

94/103 回顾会

回顾会：是敏捷中普遍使用的方法，回顾会发生在每个迭代后面，可以让团队成员检视和提升自己的工作

优点：

改善生产率，总结经验教训，识别瓶颈，减少返工
提升能力，为知识共享提供了场地，提升团队成员能力
提高质量，发现缺陷，去除根本原因

95/103 回顾会步骤

【开场】设置阶段，预设基调，创造舒适的空间，坦诚讨论''明确会议的议题和目标''
【收集数据】回忆发生的场景，收集和展示全面性的数据
【产生见解】给团队时间，评估收集的数据，推导出深层次意义或根本原因
【决定做什么】考虑下个迭代如何改变，识别出最高优先级的行动项，设置可度量的目标
【总结收尾】为团队成员提供交流和感激的机会，总结团队哪些事情需要保留，哪些事情需要改变

96/103 ESVP一种非常有意思的收集与会者心态的小活动

【Explorer 探索者】我希望能够引领大家找到我们项目的改进方向

【Shopper 采购者】我希望今天的会议上能够有振奋人心的改进方向

【Vacatiober 度假者】我并不想参加，但我觉得来开会比干活有意思

【Prisoner 囚徒】放过我吧，我不要参加这个会议

97/103 聚焦、散焦

消除参会者担心受到批判而产生的恐惧心理

|----|-----|--------|-----|
| 聚焦 || 散焦 ||
| 探寻 | xxx | 而不是辩护 | xxx |
| 对话 | xxx | 而不是争论 | xxx |
| 交流 | xxx | 而不是争吵 | xxx |
| 理解 | xxx | 而不是防备 | xxx |

98/103 SMART原则

SMART原则，5个原则：

【S Specific 具体】目标明确且具体，不能模棱两可
【M Measyrable 可度量】必须是可以追踪、考核、评估的
【A Attrainable 可实现】目标必须务实，避免设立过高或过低目标
【R Relevant 相关性】目标和完成目标的人要紧密相关
【T Time Bound 有时限】目标必须具有明确的截止时限

99/103 价值流图

是基于精益生产概念而产生的
由一系列步骤、增值、非增值活动组成
是识别和消除过程浪费、提高效率、吞吐量和效果的核心工具

100/103 创建价值流的步骤

识别分析的产品
创建目前流程的价值流，识别步骤、顺序、延迟
找出浪费
为未来的流程创建新的价值流，移除减少延迟、浪费、约束
创建路线图
规划流程的再次访问，以持续优化

101/103 重构

重构，就是在不改变软件系统外部行为的前提下，改善它的内部结构

软件重构需要借助工具完成，重构工具能够修改代码，同时修改所有引用该代码的地方

在极限编程XP的方法学中，重构需要单元测试来支持

重构的优势：

改进软件的设计
重构帮助尽早的发现缺陷
提高代码质量，更易被理解
重构可以提升开发速度

102/103 鱼骨图

鱼骨图是由日本管理大师石川馨先生所发明出来的，故又名"石川图"

鱼骨图是一种发现问题"根本原因"的方法

103/103 问法

5问法，通过对一个问题点连续以5个"为什么"来自问，以追究其根本原因

例子：

|-----|----------------------|----------|
| why | 工厂地板上有漏出的油 | 清除地板上漏油 |
| | 因为地板上漏油（为什么地板上漏油） | 修理机器 |
| why | 因为机器油封磨损（为什么机器油封磨损） | 更换机器油封 |
| | 因为购买的油封质量不佳 | 更换机器油封规格 |
| | | |
| | | |