敏捷开发Scrum和通用实践

1敏捷原则与实践

什么是敏捷？

“敏捷方法”是一个囊括了各种框架和方法的涵盖性术语。图 1结合上下文将敏捷定位为一个总称，它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。还将敏捷方法和看板方法视为精益方法的子集。这样做的原因是，它们都是精益思想的具体实例，都反映了诸如以下概念：“关注价值”、“小批量”和“消除浪费”。敏捷是一种思维模式。

图1-敏捷是许多方法的一个总称

敏捷宣言四大价值观

2001 年，软件业思想领袖共同发表《敏捷宣言》，正式宣告敏捷开发运动的开始。一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此建立如下价值观：

1、个体和互动高于流程和工具；

2、工作的软件高于详尽的文档；

3、客户合作高于合同谈判；

4、响应变化高于遵循计划。

右边的项目固然有价值，但我们更重视左边（加粗）的项目。

个体和互动高于流程和工具

Agile项目非常重视团队合作及授权，因为过程及工具虽然对项目有所帮助，但实际执行项目的仍是团队。故团队才是项目的核心执行力。尽早发展项目团队、提升工作生产力及团队有效沟通，可促使项目成功。项目是被客户所接受的，范围是由人员所界定的，故应花更多时间在人员及互动上，但是并不代表过程及工具不重要。

工作的软件高于详尽的文档

项目的目标通常是创造有价值及高质量的产出。例：软件、解决方案或可用的产品。但是，却很容易因为过程中繁复及过度的文档（例：由组织或规范所要求的）而失焦，甚至困扰项目团队。这并不代表不需要文档，因为有些文档是必要或对项目是有益处的。文档需保持Barely sufficient（刚刚好够用就好）。与其花时间在繁复的初始规格文档，不如花2-4周短期时间，分阶段产出软件，再来修正规格文档。

客户合作高于合同谈判

项目团队与客户应建立彼此互信关系，客户是最知道项目需求的人，所以项目团队应该与客户往相同的方向前进、协同合作并站在客户立场，为其产出价值，而非与其对立或对抗。许多项目往往为保护各自利益，过度专注于合同条款中硬性规定的协商，却忽略了与客户协同合作和保持合同弹性的重要。Agile合同可以提供客户修改及变更的弹性。

响应变化高于遵循计划

在变动的环境、初期信息不足、客户情境改变、客户看到半成品欲修改或其他不可预期的因素，项目难免变动。此时应适时的调整，而不是僵持按原计划执行。这并不代表项目不需要做规划，而是计划不需要一开始就做太多货太详细，可滚动式规划在逐步修正即可。传统的项目是期望在项目进度过程中，客户尽量不要提出变更，故有很严谨的变更控制程序。Agile项目则是欢迎客户变更，所以每个过程迭代都设计有规划会议及Demo（展示）会议，皆可让客户借由反馈而完成变更。

敏捷12原则

源自这些价值观的十二大原则：

1、通过早期连续交付高价值工作来满足客户的需求。

2、大工作分成可以迅速完成的较小组成部分。

3、识别最好的工作是从自我组织的团队中出现的。

4、要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。

5、创建可以改善可持续工作的流程。

6、维护完整工作不便的步调。

7、欢迎对需求提出变更，即使在项目开发后期也不例外。

8、在项目期间每天与项目团队和业务所有者开会。

9、在定期修正期，让团队反映如何能高效，然后进行相应地行为调整。

10、通过完成的工作量来计量工作进度。

11、不断地追求完善。

12、利用调整获得竞争优势。

敏捷的作用？

1、更容易地满足最后的期限要求；

2、减少软件bug；

3、代码容易维护；

4、客户满足度增加；

5、敏捷团队效率高，很少加班。

敏捷思维

敏捷不是一套固定的流程，是一种在工作时所应有的思维与方向；是一个在了解敏捷宣言中提及的4大价值与12大准则后所应有的心态或观点；是一个不被任何单一学说、架构、方法论绑死的团队协同合作方式。

Being Agile

一味地追赶潮流采用的敏捷，既不了解敏捷精神，也不清楚敏捷适用的环境，这样会造成重大失败而舍弃敏捷，所有要成功的应用敏捷，必须要：了解敏捷的优势与适用项目，确定可提供施行敏捷的必要资源，最后在聚集与如何操作敏捷的手法。在迭代之间欢迎变更，在迭代之中专注不变。

2Scrum方法

Scrum团队三大角色

由PO、SM和DT组成且缺一不可，团队数量一般7±2（5-9人）包括PO和SM。

PO即Product Owner 字面意思是产品或业务负责人，SM即Scrum Master，字面意思是敏捷教练、敏捷专家或者敏捷大师；DT即Development Team,字面意思是开发团队，角色可以互相支援。

1、是跨职能的自组织团队；

2、自组织团队自己选择如何最好地完成工作，而不是由团队外的人指导；

3、跨职能团队拥有完成工作所需要的全部技能，不需要依赖团队以外的人；

4、这种团队模式的目的是最大限度地优化灵活度、创造力和生产效率。

图2

专业名词

Sprint（冲刺）

Product Backlog（产品待办事项列表）

Sprint Planning Meetings（冲刺规划会议）

Sprint Backlog（冲刺待办事项列表）

Sprint Execution （冲刺执行）一般是2至4周时间

Daily Stand-up Meeting（每日站会）

Sprint Review Meeting（冲刺审查会）

Sprint Retrospective Meeting（回顾会议）

什么是Iteration或Sprint？

Iteration（迭代）是敏捷项目的一段周期，又称为Sprint（冲刺），工作包含：规划这段周期要做什么、执行开发、展示完成品给客户审查、开展Retrospective会议；迭代长度约2-4周，通常越短越好。因为可以趁早发现问题、调整方向及实现客户的价值；在展示增量成品给客户时，客户可以提早看到他所要的功能，让客户IKIWISI（I Know It，When I See It；眼见为真）进而确认开发的方向。同时，可以调整下一个迭代的用户故事优先级。

Scrum 管理五大事件Events

1、Sprint（冲刺）：一个时间盒迭代，一般是2周sprint，不超过30天的sprint也很常见。

2、冲刺规划会议：30天sprint时间盒是8小时，2周sprint时间盒是4小时。

3、每日站立会仪：一般在早上开15分钟左右。

4、冲刺审查会议：一般30天sprint时间盒是4小时。

5、冲刺回顾会议：一般30天sprint时间盒是3小时。回顾会议时间盒到期，这个sprint就结束。

每日站会内容

1、昨天做的什么？

2、今天准备做什么？

3、遇到什么问题或阻碍？提出来然后我们大家去解决。

仆人式领导

敏捷方法强调，仆人式领导是一种为团队赋权的方法。通过对团队服务来领导团队的实践，它注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。作用促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。仆人式领导按照目的、人员、过程从事项目工作。目的：与团队一起定义“为什么”或目的，以便他们能围绕项目目标进行合作互动。整个团队在项目层面而不是人员层面优化；人员：目标确立后，鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作中做出贡献。过程：不要计划遵循“完美”的敏捷过程，而是要注重结果。如果跨职能团队能够常常交付完成的价值并反思产品和过程，团队就是敏捷的。团队将其过程叫什么并不重要。

仆人式领导职责

仆人式领导通过管理关系，在团队内和组织中建立沟通与协作。这些关系可以帮助领导在组织中得心应手地为团队提供支持。这种支持有助于消除障碍，促进团队理顺过程。由于仆人式领导了解敏捷，在应用具体方法时践行敏捷，因而他们能帮助满足团队的需求。以下仆人式领导特征让项目领导变得更加敏捷，促进团队的成功：

1、提升自我意识；

2、倾听；

3、为团队服务；

4、帮助他人成长；

5、引导与控制；

6、促进安全、尊重与信任；

7、促进他人精力和才智提升。

1. 教育相关方，使其了解为什么要敏捷以及如何敏捷。根据优先级说明商业价值的好处，对被赋权团队加强问责，提高工作效率，并通过更频繁的评审改进质量。
2. 通过指导、鼓励和帮助为团队提供支持。倡导团队成员的培训和职业发展。“我们通过支持的方式领导团队”，这句话说的是领导在发展其团队成员时所扮演的角色。通过支持、鼓励和专业发展，团队成员将获得信心，承担更多的职责，并在组织中做出了更大的贡献。仆人式领导的一个关键作用是，培养和发展团队成员，帮助他们超越自身当前的角色，即使团队将失去他们也在所不惜。
3. 通过技术项目管理活动，如量化风险分析帮助团队。有时团队成员可能并不具备在某些角色或功能方明的知识或经验。对相关技能有更多接触、或者接受过相关培训的仆人式领导可以通过提供培训或开展这些活动来为团队提供支持。
4. 庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁的作用。创相互欣赏的积极氛围，建立加强合作的良好意愿。

Scrum3大工件Artifacts

1、Product Backlog（产品待办事项列表）完成最终产品前所有应完成的工作事项，并按照优先级排序。是项目唯一的范围和需求来源。产品待办事项列表会在项目开发的过程中动态调整；待办清单的用户故事内容。优先级越高的越详细，估算也较精确。低优先级的用户故事内容则尚不需发展。

图3

2、Sprint Backlog（冲刺待办事项列表）是产品待办清单里。被选定在该冲刺周期需完成的用户故事。通常包含如何达到该Sprint goal的计划。团队可用此预测该冲刺应完成的产品功能或特性。由开发团队来负责管理机更新。

​​​​​

3、Increment（增量成品）在冲刺中产出的增量成品。增量成品要符合Scrum团队定义的Definition of Done（完成的定义）一定要具有可用性、可操作性。增量是这个sprint结束时实际完成和交付的所有产品待办事项列表的总和。

客户价值优先级排序

客户价值优先级排序是一种以客户观点确认价值的优先级手法，项目团队与客户一起排序工作的优先级。以确保项目的方向是正确的。新增加或修正的用户故事会记录在产品待办清单。在后续迭代规划会议时，在评估其优先级。排序价值活动时，需让客户及团队共同参与。以增加彼此对价值的认知。

Scrum价值观

1. Scrum的五大价值观分别为承诺、勇气、专注、尊重、开放。
2. 唯有Scrum团队能充分内化与实践这五大价值观，三大支柱才能成为现实。
3. Scrum团队成员通过Scrum的角色、事件、工件来学习与探索这些价值观
4. 组织提供支持、团队用于承诺、有勇气面对工作挑战，专注于项目产品的开发，并尊重组织与干系人交付的资源，以开放信任的心态与其他成员互动完成项目目标。​​​​​​​

谈对=团队

图4

唯有scrum团队能充分内化于实践这五大价值观，三大支柱才能成为现实。Scrum团队成员通过Scrum的角色、事件、工件来学习与探索这些价值观；组织提供支持，团队勇于承诺，有勇气面对工作挑战。专注于项目产品的开发，并尊重组织与干细系人交付的资源。已以开放及信任的心态，与其他成员互动完成项目目标。

Scrum三大支柱

1、Transparency（透明）

过程的关键环节，对相关负责人员必须是明显易见的。透明度要求的是一套共同标准，以定义所有的关键环节所有观察者对所见的事物需有相同认知。

2、Inspection（检查）

Scrum使用者必须频繁地检查Scrum的工件以及达成Spring goal的进度；Scrum同时也强调检查不应过度频繁且阻碍到开发工作本身。

3、Adaptation（适应）

当检查人员发现过程有一个或多个面向偏离到可接受范围之外，可能导致客户无法接受相关产品，必须调整此过程；调整必须尽快及时，以免偏离扩大。

尽可能晚做决策

针对产品方向及未来目标的不确定性，强调任何重大的决策越晚做决定越佳。信息越晚越明确，故越晚做决策，可挑选的决策选项就越来越少了。确保决策的正确性。可大幅度降低因太早做决策而造成晚期大量变更所带来的风险，最晚的决策点是（最晚回应时刻）在这个时刻之后就没有必要再做决定了。Sprint规划会议不怕时间短，可以后续慢慢分解工作。

冲刺展示会议-Sprint Review

冲刺展示会议又称为冲刺评审会议在sprint结束前举行，用于已检查Increment及调整Product backlog；

于Sprint Revive开发团队和干系人协同讨论本次Sprint所完成的工作；这是非正式会议。产品增量展示是为了让所有人反馈意见及鼓励大家共同讨论。通常1月的sprint会有4小时展示会议，sprint越短，会议也越短。

Scrum Master 确保此会议的召开，并让参与者了解本次展示会仪的目的，同时也教导大家如何于限时内完成。

Sprint review工作包含：

1. po邀请开发团队和主要干系人出席
2. 解说哪些哪些产品待办事项列表已经完成及尚未完成
3. 开发团队讨论在此冲刺中哪些做得很好、碰到什么问题及如何解决这些问题
4. 开发团队展示他们所完成的工作及回答干系人的问题，来解决相关方/干系人的疑问
5. 重新评估产品在市场或潜在使用者是否改变，以及接下来要做的最高价值的事情
6. 检查下一个预期版本发布的时间表、预算及市场
7. Sprint review成果是一份修正后的产品待办清单，也定义了可能进入下一个Sprint的PBI
8. 产品待办清单也可因新的机会而进行全面性的调整

冲刺回顾会议

• 提供开发团队一个自我检验的机会，并规划下一个Sprint的改善计划。
• 回顾会议紧接在展示会议之后，而在下一个Sprint plaanning 之前。
• 通常一个月的Sprint会有3小时的会议，Sprint越短，会议也较短。
• SM以作为团队成员身份参加此会议，确保Scrum过程舒畅。
• 会议冲刺回顾会议目的有3点：

1. 检验本次Sprint关于人员、关系、过程及工具的运作情况，提出检讨与改善。
2. 找出并排序什么做得很好及需要改善的部分
3. 建立改善计划使开发团队能持续优化敏捷运作。

• SM在Scrum的过程框架内，鼓励开发团队改善其开发过程，让下一个Sprint更有效率，更愉快。
• 在每个冲刺回顾会议开发团队适当地改进工作过程，调整完成的定义，以提高产品质量。
• 会议最后开发团队应该找出下一个Sprint应实施的改善行动。
• 实施改善是开发团队的自我检验与调整的结果。
• 虽然这些改善可于任何时间点实施，但回顾检讨会议提供了专注检查与调整的正式机会。

3敏捷通用实践

用户故事（User Story）

用户故事是敏捷项目的需求记录，采用活泼生动述说故事的方式，以取代传统项目对于客户需求格式化的描述。用户故事宜短不宜长。基本格式：身为什么角色，我想要产品拥有什么特性，如此可以实现什么价值。

用户故事从客户角度来描述其对于项目产出所期望的功能，且大约能在1-3天完成的工作量大小。将用户故事整合后成为用户故事待办清单，或称产品待办列表。用户故事相当于传统文档而言相对简单、有趣、易于沟通，而且帮助我们持续更正。

每个用户故事皆需要具备三个 要素：Card（卡片）、Conversation（对话）、及Comfirmation（确认）。

1、card

将用户故事写在约1/4A4大小的卡片上，内容不是为记录完整客户需求为目的，而是提供恰好足够的说明 ，以协助识别客户需求。卡片上记录优先级与成本的简要信息，卡片通常在进入工作排程时，会交给负责团队成员，工作完成之后，卡片会递回到客户手里。

2、conversation

用户故事要便于团队与PO双方的持续对话，这些对话绝大多数都是口语的面对面谈话。借由持续的对话沟通以达成共识。（po与团队之间对话，版本发布规划阶段，团队需要估算哪些用户故事迭代规划阶段，团队执行哪些用户故事）

3、confirmation

确认是用户故事重要的一环。用户故事接收原则，在迭代规划前就被制定、并在规划过程中得到双方的认可。在版本发布规划阶段，有客户制定完成的定义，用户故事开发完成后，可以借此判定是否满足，并在展示时看有没有满足客户的接收原则。

故事的6大特性

图5

6.Testable（可测试的）：一定要具备接收原则，以供项目团队测试去确认完成。

相对故事点数

故事点数是一种相对估算法，估算的单位是故事点数（SP  Story Points）。敏捷使用此工具让项目能快速的进行估算。

此估算方法可解决以下2个常见的估算问题：

1.人们通常无法精确估算工作大小。

2.精确的估算流程是复杂且不受欢迎。

比如：若要确切的估算出奇异果、橘子或哈密瓜几公分大是很难的。但我们可以在瞬间将水果由小到大排序这就是相对确切的估算。

图6

最佳估算用户故事的作法：

1、当特定的用户故事信息有新信息涌现时，估算者可以随时改变估算想法。

2、同时适用于大型用户故事（史诗）及小型用户故事。

3、前期不需要花太多时间估算，因为估算数据的逐步完善是敏捷项目的常态。

4、提供对项目进度和后续工作有利的信息。

5、应容忍估算的不精确。

6、可用于规划版本发布日期。

进行用户故事估算注意事项

1、团队需负责故事点数大小的定义，由团队负责定义SP的大小。每个项目的故事点数大小不尽相同，无法相互比较。

2.由于故事点数不是理想时长，所以估算时需要考量所有可能因素。故事点数的估算已涵盖所有活动，不需增加额外的时间。（例：估算某工作为2个故事点数，这时间包含问题处理、等待、实际工作及沟通协调时间）

3.在正常运作的节奏下，项目团队可量测及预测项目开发的Velocity（速度）。【例如：过去2个迭代周期平均完成20个故事点数，若项目目标还剩下100个故事点数，则整个项目推测尚需5个迭代方能完成项目】

4.尺寸大小需前后相对应

3个sp的用户故事，所投入的工作量必须大约是1个sp的用户故事工作量的三倍。同一个项目中所有用户故事的故事点数大小需维持一致。

规划扑克牌

扑克牌上的数字，可代表单位的大小。例：开发天数或Story Point（sp；故事点数）规划扑克牌也使用斐波那契数列因为前后数字之间有明确的差异，可剔除估算者之间的微小差异。

图7

操作方法

1.参与者每人发一副规划扑克牌。

2.会议主持人朗读一张用户故事卡片，团队互相讨论以对于故事需求产生共识。

3.参与者根据自己对用户故事的估算，选出一张扑克牌。

4.所有人一起掀牌，让彼此可以看到扑克牌数字。

结果分为2种：

第一种所有人数字都差不多，可取众数。

第二种其中1-2人的数字和大家差很多，这可能是异常点，此时差很多分数的成员说明意见后，再重新估算。

规划扑克牌的优点

可分多次循环估算，让参与者同时提出估算，以去除从众效应和光环效应，可收敛团队对估算结果的看法。

理想时长（Ldeal Time）

成员在项目过程中受到干扰是无法被完全避免的。例如：打扰、突发状况、日常会议、执行非项目工作。估算项目工时因此充满许多变数。使用（Ldeal time）理想时长估算工时，可简化估算流程。可以使用美式足球来比喻此概念，一场足球只有四节，每节15分钟。理想时长1小时完成。但是，每场球赛平均时间是3小时，因为中间要加上暂停，电视广告、犯规、中场休息等非正式比赛运行时间。

理想时长的假设前提如下：所有上班时间都投入在产品开发的工作，工作不会被打断；不需要参加会议，不需要等待，已具备所有工作上需要的资源。

通常会再搭配一个真实工作时间的计算系数：例如一天有8小时理想工作时间*0.7（真实工作时间）5.6小时实际工作时间。

任务板（Task Board）

任务板通常有白板或者一面墙即可使用，是信息发射源的概念，确保有效地将信息发布到整个团队。任务板的信息通常在每个迭代开始时重设，以对应新的迭代规划；并且在每日站会会议中由开发团队更新进度。可成为每日站会会议的焦点，让团队于项目进度及障碍。就算是分布在不同地理位置的团队，也可应用电子化的任务板来管理跨地区的项目。

任务板通常使用多个栏位标示，以促进团队的自我组织；有五栏位和三栏位标示法。任务板可用来区分一般用户故事与缺点改善活动的差别。使用特定颜色代表有障碍的Task；当团队每日看到任务板的卡片自左到右移动，会有很大成就感。

燃起图（Burn Up）/燃尽图（Down Chart）

燃起图与燃烧图是用以展示项目进度的工具，也可以追踪其他变数；这2个图形最大功用，可以辅助判定项目进度，并且预测下一个版本何时可以完成发布。

燃尽图无法展现因变更造成的范围变化；燃起图可将进度与范围分别展示出来，不会因为范围改变让进度的信息失真；和燃尽图相比，在进度展示方面，燃起图信息比较丰富；燃起图的另一好处是可协助计算团队的开发速度。

速度（Velocity）

Velocity是敏捷项目的指标，用以测量出团队在单一迭代周期能够完成多少的工作量；速度也可用以估算及预测后续的迭代数量、版本发布或是整个项目所需要的时间是多少；敏捷项目速度的计量单位与团队用来估算工作的单位相同；（例如：工时、工作日、理想时间或故事点数）

项目初期，速度是以初始迭代团队能够完成的工作量作为后续估算的基础。通常初期开发速度不稳定，但历经数个迭代之后，团队成员在项目工作的经验积累，加上工具使用的熟练度提高，开发速度会逐渐上升并呈现持平趋势，此时团队可借由稳定的速度来估算剩余工作进度与可能完成日期。

例：团队平均一个迭代完成50个sp，若待办清单尚有500个未完成的sp，接续只要500除以50，即可估算出此项目还需要10个迭代才能完成。

故事地图（Story Map）

是一极佳的视觉工具，其主要用途是展示功能重要性，项目产出所涵盖不同的范围。

区分：骨干、可行走骨架、附加特性。

骨干：系统必要的特性。如引擎、刹车系统。

可行走的骨架：挂在骨干下，让系统可顺利运作的最基本特性。如轮胎、车架、刹车组件。

附加特性：增加系统附加价值，但无此功能特性，系统还是可以运作。如天窗、导航系统、油电混合。

用户画像（Persona）

让团队成员可以站在虚拟人物的角度能够更加了解，推论出用户的真正需求，且更利于成员之间相互沟通。优势：

1、帮助成员了解不同群组的属性以及特定需求，以及明确使他们意见达成一致。

2、经由合乎个别用户画像的需求，提出合适的解决方案。

3、用一张面孔来激发团队成员于特殊族群的同理心。

在项目初期，团队要能深入了解最终使用项目产出的用户群组，最有效的方式就是使用用户画像；用户画像针对相关方群组特性的快速关键描述，越写实越好，单用户画像描述的是虚构而非真实人物。

用户画像4大内容

1.名字（加上昵称利于记忆）

2.图片（代表性的人物图示）

3.描述（此人物如何与项目产出的互动）

4.价值（其对项目最终价值交付的认知，这个人物期望最后能得到什么，不是专注人物的what与how，而是聚焦于why）

图8

回顾检讨会议

回顾检讨会议是敏捷开发特殊的自我学习及调整会议，所有的敏捷方法皆有此机制。主要目的是Learning（学习）、Reflection（意见反映）和Readjustment（重新调整）工作项目或作法。

Retrospective发生在每一个迭代/冲刺结束前，团队成员集合在一起，共同检查及调整团队的做事方法和协同合作方式。

由于Retrospective是发生在项目过程中，所得到的修正作法，可以马上运用到接下来的迭代循环中，当下进行中的项目因此立即收益。

PMBOK中传统经验教训会议，与敏捷项目中的回顾检讨会议形态不同，是将经验记录于文档。并期望下一个相同特性的项目可以应用。但是有以下缺点：

1.下一个项目的特性（例：技术、团队、PM、商业需求）未必相同。

2.观看前一位项目经理所做的经验教训文档时，由于项目并非自己所做，故不会很认真看待。

3.经验教训的频率太少，仅每个项目或阶段（例：三个月或半年）执行一次，可能因时隔已久而淡忘。

回顾检讨会议五个步骤，都充满着许多实用的Workshop（研讨会），可解决团队在每日站立会所汇报遇到的问题和障碍，并在回顾检讨会议依据团队的反映与观察识别出问题点或需要改善的地方。五个步骤的工具在“Agile Retrospective Making Good Teams Great” by Esther Derby 有详细描述，此书为PMI的书单之一。

回顾检讨会议皆是与“关系”、“工具”、“流程”、及“人”有关的内容，可为项目带来的好处为：

1.改善生产力：可降低返工；

2.改善能力：可强化不足的知识。当团队有更多人知道这些知识，则可更有效的执行工作；

3.改善质量：找出问题及缺陷并消除原因；

4.改善产能：找出流程效率不足的地方，用以提升团队的产能。

Retrospective 的五个过程

一、开场

回顾会议开始时，需要设定开场气氛，以协助参与者专注于思考工作进行的状况，让参与者做好接下来的Gather data（收集数据）和Generate insights（产生见解）过程的心理准备。开场的目的是创造会议气氛，让参与者可以很自在的发表意见。开场的技巧，是让参与者越早发言越好。若参与者没有在回顾会议一开始时有机会发言，他们会认为不需要发言或保持沉默是可以被接受的。但不发言或保持沉默会导致无生产力的回顾会议。

开场常用工具通常为：签到（Check-ins）、ESVP。

签到：就是协助参与者抛开其顾虑，专注在回顾会议，可以使用圆桌会议的轮流发言方式（一般5-9人），请参与者简单说明以下任一个问题：

1、你期望可以从回顾会议获得什么？

2、你对于回顾会议的主要想法？

3、你现在在想什么？

ESVP：活动的目的是了解参与者对回顾会议的看法，用以量测参与者的参与活动及投入程度。步骤如下：

1、参与者匿名选择回顾会议所扮演的角色：

Explorers（探索者）：乐于学习任何事物，像海绵吸水一般。

Shoppers（采购者）：寻找对他们有用的信息，参与此次的回顾会议有他们特别的目的。

Vacationers（渡假者）：对回顾会议没有兴趣，但是可以暂时离开工作岗位，来这里渡假很开心。

Prisoners（囚犯）：感觉被强迫参加回顾会议，像是关在会议室里，心里非常抗拒。

2、匿名的结果被收集后，为避免填写者有压力，由第三者把统计结果写在白板上。如下图

图9

3、经过统计后，主持人应该公开的把所有纸条撕掉，让参与者安心。

4、最后询问参与者对统计结果的看法，并讨论这结果对他们回顾会议的意义。

二、收集数据（Gather Data）

利用回顾会议收集团队成员关于该次迭代循环执行状况的感受，用以建立团队对于问题的共同看法。

若缺乏数据，团队对于哪些地方需要改变或改善都只能猜测，或只聚焦于片面的改善活动而丧失全面性改善的机会。

收集数据不止于定量数据，也有可能是定性的数据，客观描述或事实也是数据的一部分。收集数据方法：时间轴（Timeline）、颜色代码点（Color Code Dots）

例1：项目迭代完成100个SP。

例2：资深成员A在Demo meeting（演示会议）时常常迟到。

例3：客户对第3次迭代的演示结果赞赏有加。

时间轴：透过模拟项目工作期间发生的主要事件，从不同面向建立工作执行状况的画面。用以协助团队收集并识别该次迭代循环的问题状况，团队成员使用便利贴，写下载此次迭代期间，Good（好的）、Problematic（有问题）、Significant（有意义）的事件，并将其依时间顺序贴到白板上。会议主持人接着让团队成员讨论这些事件，以了解当时大家对事件的感觉。

操作步骤：

1.主持人在白板画出时间轴，并切分出相对的时间隔栏位。如下图  1-7代表时间天数

图10

2.对团队解说活动目的。请团队将事件填入时间轴，以建立此次迭代期间，不同面向的全貌。

3.分组，每组成员小于5人（含），并给各小组便利贴。

4.请每位参与者回想，并使用不同颜色的便利贴写下此循环时间内发生的Good（好的）、Problematic（有问题）、Significant（有意义）的事件。

5.将便利贴贴在时间轴上，并讨论这些事件，依据讨论的结果在时间轴图的下方画出心情曲线，以追踪每一段时间周期内的团队心情变化。

颜色代码点（Color Code Dots）

是一种团队心情意见展现技术。此技术可与时间轴技术结合。用以收集参与成员的心情。成员使用不同颜色的圆形贴纸显示情绪的高低，贴在时间轴事件上。操作步骤如下：

1.发给每位参与者7~10点的2种颜色的圆形贴纸，并说明哪个颜色代表高能量，哪个代表低能量。（例：蓝色代表心情好，红色代表心情不好）

2.请参与成员将圆形贴纸贴在时间轴的事件上，以显示每段时间的团队心情指数。如下图

图11

三、产生见解（Generate Insights）

产生各种各样的见解，主要是针对收集数据阶段收集到的数据进行分析，此阶段主要促进团队分析问题、了解问题的影响，以利于在下一个阶段提出解决方案。以下5种常见的产生见解技术：

1、Brainstorming（头脑风暴）

2、Five whys（五个为什么）

3、Fish bone（鱼骨图）

4、Dot Voting（记点投票）

5、Identify themes（识别主题）

鱼骨图是一种视觉化的根本原因分析工具，通常与5个问什么技术合并使用。团队透过识别某问题或状态的原因与其影响，寻找可能的问题真因。是一种Top-down（自上而下）的作法，从造成问题的各项原因依序往下探索发掘真因。步骤如下：

1、画出一个空白的鱼骨图在白板上，并在鱼头写上需要改善的问题或状况。

2、分析可能造成问题的主要因素类别，并写在鱼骨上。

五个为什么是透过问题原因及其影响的关联性，进而找出问题的Root cause（根本原因），此活动通常使用2人小组或小组的方式实施。透过小组内一次次的对谈（Ask “Why？”）逐渐找出问题的根本原因。小组讨论时，针对目前讨论的议题问5次Why，以取得惯性思考之外的思维。五个为什么仅为代表性的说法，主要是期望团队借由对问题的不断讨论，找到根本原因。

记点投票又称为Prioritize with dots，是排序优先级的活动，可使用在回顾会议时期产生见解或Decide what to do（决定行动方案）阶段，此活动协助团队从一连串的建议清单中找出执行的优先级，是通过多人投票技术，以决定优先级，操作步骤如下：

1、假设有40个方案可选择，每人分到8个点，每个方案不限定只能给1点，若投票者觉得此方案重要可将8点全投在统一方案。所有的点数都要用完。

2、待全部人完成投票后，在依据总和点数排出优先级。（偷电数可以是公开或不记名的，以防止某人影响最终方案或给予记名投票者潜在的压力）

图12-记点投票

四、决定行动方案（Decide What To Do）

决定行动方案是针对产生见解过程识别出的主题与跟本原因，制定后续的行动方案，此阶段利用各种技术建立明确的改善目标与实施方案，并决定后续追踪实施方案的绩效与进度的方式。以下是四种常见的Decide what to do 活动：

1、Short subjects（简短主题）

2、SMART goals（SMART目标）

3、Retrospective panning game（回顾规划游戏）

4、Circle of questions（问题圈）

简短主题可以协助团队快速达成问题解决行动的共识，此活动应用在团队产生见解过程产出之解决问题的Ideas上，将这些想法分类成简短主题并写上白板，让团队聚焦于这些主题中，快速讨论，达成行动的共识。简短主题分类范例如下：

哪些做得很好、哪些下次可以改善Keep（保留）、Drop（移除）、Add（新增）、Start doing（开始做）、Stop doing（停止再做）、Do more of（可多做一些）、Do less of（可少做一些）。

图13-简短主题

下一篇分享极限编程和精益敏捷开发。