第1 章
回 顾 101
本章的主要目的是向大家介绍回顾。我会告诉你在家庭环境中如何使用回顾，向你介绍阶段模型，并给你一些有关如何用生活来填充这些阶段的提示。阅读本章之后，你将拥有开启首次回顾需要的所有基础知识，那我们就此开动吧。
1.1 回顾是什么
一般来说，回顾(拉丁语是retrospectare)就是审视，是往回看。晚上你躺在床上，脑海中回想着当日种种，这是回顾；一家人坐下来共进晚餐，聊聊这一天发生的事情，这是回顾；回望某位艺术家、作家或导演一生的作品也是回顾。作为此种回顾的一部分，会有各种各样的事件，各自展现艺术家的一系列作品。所有的重要片段集中在一起，构成了艺术家作品的完整画面。这样可以形成良好的整体印象，并有机会比较和对比不同的艺术作品。如果我们只查看一个例子，那就没可能了。只有通过整体印象才有可能看到全局，并有机会推测艺术家为什么做了这一件事而不是另一件事。 另一种回顾发生在电视业，通常是在每年年底以年度回顾节目的形式出现，不同广播公司互相争夺以让最有趣、最美丽或最有名的人出现在节目中。娱乐是这里的重点，它并没有过多强调全面了解。这些年度回顾节目相对来说更片面，并不怎么适合得出结论或查看不同事件之间的联系。
我在本书提到的回顾与上述不同。我所讨论的回顾也涉及回看，但这只是第一步。更重要的是从这项活动中获取知识和见解。这样的知识和见解可以帮助我们从过去的经历中学习并相应地进行调整。我们既可以从成功中学习，也可以从失败中学习；好的事情通常可以做得更好。你可以将它与进化相比较：不奏效的事物会灭绝，但所有有助于物种存续的东西都得到了保存和进一步发展。最后，每次调整适应只不过是一个试验，因为你永远无法确切地知道结果会是什么。在最好的情况下，这些试验对当前情况有所改善。有时它们会让事情变得更糟，我们就必须在下次回顾时进行分析。
每次回顾都有一名引导者负责引导，由此人来确保大家达成既定目标。他帮助这些团队得到将成为未来成功之基础的实效结果。引导者不是参会者(尽管这在小团队中难以避免)；他会全程相伴但并不主动参与实施方案。一个好的引导者对于成功的回顾来说是至关重要的。
这种回顾最先由Norman Kerth 在他的Project Retrospectives: AHandbook for Team Reviews[1]一书中进行了描述：回顾是一个项目结束时的正式仪式，评议所发生的事件并从经验中学习。没有谁能够知晓一个项目的全部情况。每个人都只知道一部分情
况。回顾是一起讲故事并从经验中挖掘智慧的仪式。
Kerth 在他的书中解释了回顾与所谓的“事后调查”和“经验教训”的不同。主要区别在于，回顾侧重于积极的未来行动并将其用作改变的催化剂。它们不是项目的结束，而是持续改进过程中的里程碑。
2001 年，几个人聚集在一家滑雪旅馆，为敏捷软件开发起草了一份宣言[2]。宣言的基础由4 组价值观和12 条原则组成。最后一条原则非常贴切地描述了回顾中会发生的事情：团队定期反思如何变得更有效，然后对自己的行为进行相应的优化和调整。该宣言是敏捷社区特别热衷于将回顾纳入其工作流程的主要原因之一。这些人意识到他们不必等到项目结束才从已发生的事情中学习，并做出适当改变。相反，他们会在每次迭代结束后都组织一次回顾，也就是间隔一个固定时段。这个间隔应该不超过一个月，否则你会面临反馈周期过长的风险。
什么是迭代
迭代这个词源自拉丁语iterare，意思是“重复”。迭代被广泛应用于问题可以被逐步解决的各种领域。在计算机科学中，迭代所指的就是在达到预期条件之前采取不同步骤的过程(例如FOR循环)。在Scrum中，迭代被称为Sprint。
我使用术语“迭代”来描述基于明确定义的、简短的重复性步骤来运作一个项目的过程。每次迭代后，会停下来确定项目目标是否已实现以及在多大程度上实现了目标，并在必要时调整原始计划。目标是将不确定性和意外风险降到最低，同样的程序也适用于变革管理。
举办回顾会可以帮你建立起一个持续改进的过程，不断检查前进方向是否正确，能有机会及时地介入并做出必要的改变。通过腾出专门的反思时间，可以让自己有机会立即解决问题，而不必等到项目结束。如果没有在项目结束之前进行追溯，那很可能没到下个项目你就把学到的东西给忘了。此外，你还有机会在每次迭代中实施改进。
“敏捷”一词在当前背景下的真正含义
敏捷一词源自拉丁语agilis，即“做、进行或行动”。如前所述，该敏捷性基于敏捷宣言的12 条原则[2]。
敏捷宣言如下：我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观。
• 个体和互动高于流程和工具
• 可工作的软件高于详尽的文档
• 客户合作高于合同谈判• 响应变化高于遵循计划
也就是说，尽管右项有其价值，但我们更重视左项的价值。
相应的12 条原则如下所示。
(1) 我们最重要的目标是通过持续不断地及早交付有价值的软件使客户满意。
(2) 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，由敏捷过程掌控变化。
(3) 经常性交付可工作的软件，通常相隔几星期或一两个月，倾向于采取较短的周期。
(4) 业务人员和开发人员必须相互合作，项目进行中的每一天都不例外。
(5) 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
(6) 无论团队内外，传递信息效果最好且效率也最高的方式是面对面的交谈。
(7) 可工作的软件是进度的首要度量标准。
(8) 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
(9) 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
(10) 以简洁为本，它是极力减少不必要工作量的艺术。
(11) 最好的架构、需求和设计出自自组织团队。
(12) 团队定期反思如何变得更有效，然后对自己的行为进行相应的优化和调整。
如你所见，一些原则直接针对软件开发。但是，大多数原则用于其他领域也很容易。敏捷宣言所植根的基本思想是我们生活在一个复杂且不可预测的世界里。因此，制订几年或是几个月的详细项目计划是没有意义的。做过项目计划的人大多数都知道，只需要很短的时间，这个计划就会脱离现实。敏捷开发人员知晓这种情况并尝试使用短反馈周期以及与客户密切合作来最小化其影响。在敏捷宣言的基础上，发展出了不同的框架和流程，包括XP、DSDM、Open UP，当然还有当前最受欢迎的Scrum。与此同时，敏捷软件开发的理念也已经传播到其他领域。例如，Stephen Denning 在他的The Leader’s Guide to RadicalManagement[3]一书中就描述了敏捷宣言的理念在管理领域的应用。
1.2 除夕夜回顾
几年前，我和家人开始了一项新年传统仪式。我们称之为除夕夜回顾。它不仅很有趣，而且也有助于消磨午夜到来前的时间(用来对付小孩尤其有用)。除夕夜回顾是这样的：开始时大家都先坐下来，一起看今年拍摄的照片和短片。我会事先准备一个U 盘将照片和视频拷进去。
我们的回顾在这个阶段总是妙趣横生、笑语连连。之后，我们会看看这一年里所采取的措施和当时的假设。这点非常重要，因为只有通过这种方式，我们才能知道我们去年所做的决定是否达到预期效果。如果决定不正确，那么我们会考虑是否还有必要继续，并采取不一样的措施。审视完假设之后，我们会重新思考去年那些特别
值得记忆的事情。这些事情分成以下三类。
• 今年我喜欢什么？
• 今年我不喜欢什么(或什么让我生气)？
• 谢谢你。
第一类包括所有有趣的或让我们很开心的事情，例如在吉尔吉斯蒙古包度过的家庭假日。第二类包括所有的负面事情，例如“袜子到处乱扔”或“唠叨烦人的父母”。第三类就是要对妻子或妈妈、孩子或兄弟姐妹说声“谢谢”之类的。把感激与具体事件联系起来，这往往很重要，例如“谢谢你把Skylander 玩具给我玩”或者“谢谢你每天早上给我做点心”。
然后是获取知识和见解的时刻。每个家庭成员可以选择一个自己认为特别重要的议题。议题会依次被讨论。讨论的目的是要找出该议题的深层根因。目前，我们发现“5 个为什么”提问法非常有效。
“5 个为什么”方法
这个方法从提出问题“为什么x 会发生”或者“为什么x 总是发生”开始，问题的答案成为下一个“为什么”问题的基础。然后就是重复这个过程，继续深入挖掘，直到最终找出问题的真正原因。确保把这个根因写到纸上，因为它是下一阶段的基础。“5 个为什么”方法有大约100年的历史，它由丰田公司创始人Sakichi Toyoda[4]所创建，旨在找出生产问题的根源以防止问题再次发生。
下一步是针对找出的原因为明年制订具体而可衡量的措施。为此，我们用一个简短的头脑风暴来收集大家的想法。你或许无法想象，即使是父母们心里自我感觉非常清楚的话题，孩子们也能想出很多超乎想象的点子。每个人针对每个话题说出自己的想法，然后一起选择出最有希望的想法。我们把彩色圆点贴纸贴到写有想法的纸条旁边，以此来做出选择。这项技巧被称为“圆点投票”。我们每个人都有三个带黏性的圆点贴纸。我们可以将它们贴在任何我们喜欢的想法边上。结束后，我们会将那些被选中的纸条放在显眼处——客厅的软木板上，形成高可见度的待办列表。没有比回顾结束后而结果却不可见更糟糕的事情了。这些待办事项会帮助我们留意自己所采取的新措施，并确保我们确实在执行。重要的是，我们将每一项措施都与可验证的假设联系起来，并在下一次回顾时检查。
当然，每个回顾都需要一个与之相配的收尾。我们的选择很简单：
除夕夜的烟花。
1.3 回顾阶段模型
如果你在前一节中看得足够仔细，那么可能会注意到我们的除夕夜回顾经历了6 个阶段，如图1-1 所示。这些阶段构成了回顾会的结构，它们是基于Esther Derby 和Diana Larsen 合著的书[5]中的原始阶段模型修改而来的。我所描述的这个模型是Derby 和Larsen 的模型的扩展形式，最大的区别在于，我增设了“检查假设”环节，并扩展“定义试验”环节以纳入假设。稍后我将在书中
解释原因。接下来将更详细地解释这6 个阶段。
图1-1 回顾会的6 个阶段
1.3.1 阶段一：设定基调
回顾的第一阶段是要设定好基调。这个阶段非常重要，因为每个参会者都必须将情绪“调整过来”回到当下。如果你忽略了这个阶段，就可能会出现一个或多个参会者在思想上开小差的情况，因为他们还在想着他们在参会前做的最后一件事。准备好场地，以便吸引住所有参会者的注意力，让他们参与进来。最好是先说几句欢迎的话，并感谢每个人的参与。然后你作为引导者简要地解释回顾的原因和目的以及时间和议程。议程很重要，毕竟我们都很想知道我们投入时间到底要做什么。
实用技巧
确保房间里的每个人都说点什么。在这个阶段保持沉默的人很可能在回顾会的其他阶段也会保持沉默。每个声音都能被听到显得很重要，因为只有这样你才能得到全局景象。参会者不需要讲很多，每个人说几句就够了。例如，你可能会让人们说说他们的名字，或是用一个词来描述他们对回顾的期望。有趣的是，这种简单的技巧在大多数情况下都非常有效，即便是比较安静和沉默的团队成员们也会参与讨论。第一阶段的最后一步也非常重要。其目的是营造出可以轻松探讨困难议题的气氛。只有在不愉快的事情也能被讨论的这种气氛中，才有可能追根究底，找到问题的真正根因。此外，它也是成功回顾的基础。正所谓，过去的就让它过去吧。
你可以通过建立协作规则或“工作协议”来营造这种氛围。有些团队已经定义了他们日常工作的价值观，这种情况下，你应该直接使用这些价值观，只要提醒团队记得它们即可。可能需要针对回顾会调整少数几条价值观。这种做法也适用于团队已经定义协作规则的情况。许多敏捷团队都在协作一开始时就创建了团队章程。
什么是团队章程
团队章程规定了团队合作的所有规则，包括沟通和行为准则，以及定期会议的时间和长度。软件开发团队还会有一个所用开发工具的列表，以及可获取更多信息的链接。对团队新成员而言，团队章程是一个很好的起点。它应该是一份不断完善的活文档。如果有任何团队成员感到并明确表示团队章程需要调整，那团队就应探讨该请求，达成一致后进行调整。
如果还没有协作规则，那就应该去设定了。然而，为什么这些规则
如此重要？下面列举一个简单例子。
假设你的同事詹姆斯习惯带着笔记本电脑参加所有会议。他利用在这些会议上的时间来回复电子邮件或浏览网页。如果你在没有事先明确设定规则的情况下开始回顾会，他可能会做同样的事情。这将会惹恼所有人，但大家都没有可援引的规则要求他关闭笔记本电脑。但是，如果已经设定了规则，那就随时都可以指出来。有公共规则的另一个优势是，所有参会者都有责任观察这些规则的执行情况。这也让引导者更容易专注于回顾会的实际工作。
实用技巧
如果团队还没有团队章程，那就在回顾会后立即邀请团队成员进行一次工作坊以创建团队章程。
遗憾的是，这是被忽略最多的一个回顾阶段，因为人们想要节省时间并且想马上开始。根据我的经验，带领团队经历这个阶段从来都不曾浪费时间。如果团队合作了很长时间，那么这个阶段通常不超过5 分钟。
这5 分钟可以：
• 降低大家不说话的风险。
• 确保每个人都感受到自己身处在安全的工作环境中。
• 让每个人都出席这个重要会议并清除头脑中的杂念。
有时也可以做5 分钟的趣味活动。例如，你可以问团队：“如果上一个迭代是一辆车，它会是辆什么样的车？”只需要一两个字，你就能让每个人都积极地参与到会议中来。
签到
Derby 和Larsen 的书[5]中介绍了这种签到技巧，在讲完欢迎词和表明回顾会的目的之后使用。引导者问一个简短的问题，参会者逐个快速地回答，下面是几个示例。
• 用一两个词语来描述你希望从这次回顾中得到什么。
• 如果上一个迭代是一个国家，它会是哪个国家？
• 你会用什么样的天气词汇(晴、多云、雨、雷雨交加)来描述你现在的心情？
参会者直接说“过”也是可以的。即便是这一个词，只要能让大家听到也已经足够。顺便说一下，在我家的除夕夜回顾中，我们是通过观看去年的照片和视频来设定基调的。相信我，这非常有趣！
1.3.2 阶段二：检查假设
“检查假设”阶段的目的是审视上一次回顾时建立的假设。理想情况下，这些假设是根据所选择的试验创建的(参见1.3.5 节)。那么，为什么这一步如此重要呢？
假设上次回顾时你们和产品管理团队一起讨论了沟通不畅的问题。产品经理很难被联系到，并且只有在发生重大延期后才解答问题。上次回顾会结束时，你决定采取一项措施：产品经理每天预留一个特定时段给团队，用于探讨当前的问题并给出建议，从而最大限度地减少延迟。你对这个试验可能有如下假设：当前的问题将可以在24 小时内得到回复。相比团队有时得等上好几个星期才能得到答复的现状，这个措施应能带来切实改进。
设定了基调后，团队开始检查假设。结果我们发现这个试验是错误的。虽然看似响应时间已有所改善，但是离24 小时的标准仍然差很远，所以问题还在。在接下来的回顾会中，团队会试图查明问题的缘由，然后可以调整当前试验，也可以重新定义一个新试验。在此过程中，你可能会发现，有新变更时产品经理从来没有被请教过，而只是被告知要实现它。这可不会激励他与团队更紧密地合作，只会惹他生气。使用假设可以让团队聚焦一个议题，直到问题被解决或降至可容忍的程度。
实用技巧
如果假设都未能被证实与你的预期相符，则利用回顾会的后续环节来找出原因。
此案例表明假设是一个重要的工具。有些团队很少检查之前回顾会的举措是否落实。只有少数团队不厌其烦地检查这些措施是否达到预期的效果。然而，只有通过检查预期的效果，你才能真正实现改进。这当然不是万能的，但大多数情况下都很有效。假设还有助于让回顾更有意义并帮助你聚焦一个主题，而不是任由讨论蔓延。
1.3.3 阶段三：收集数据
现在我们来仔细看看“回顾”这个词。“收集数据”阶段的目的是要收集某个明确界定的时段内的数据。这个时段可能是上个迭代(或
Scrum 中的Sprint)、项目全程甚至是最后一个工作日。从事件发生到回顾会之间的时间应该保持尽可能短。此阶段的主要目标是对大家正在考虑的时段形成共识。没有这个共识，参会者可能无法理解彼此的观点和意见，并倾向于将他们的感受强加给别人。有了共识后，每个人都有机会表达他对事物的看法。
先从收集事实数据开始。这些事实可以是在此期间发生的任何事情，从会议和决定到个人的经历。它包括那些对团队任何人的过去和现在具有意义的事情。数字(度量)也能在这一步中起到作用，例如已完成的需求数量或者已关闭、未解决和新错误的数量。结果越深刻越好。可以只是口头讨论所有这些事情，但做出一个可视化的效果要好得多。可视化简化了信息的记录，特别是对于那些时间较长的回顾会的情况，是不可或缺的。通过在墙上贴出一条时间轴，可以更容易地观察时间与事件的关系，这是可视化的一个例子(见图1-2)。
图1-2 用时间轴收集数据
虽然事实很重要，但它们仍然只是故事的一部分而已。关注人们当时对事情的看法也同等重要，因为它会帮我们分辨哪些事情更重要、哪些不太重要。收集事实和个人观点有助于找到对团队影响最大的问题。同时，这些观点的情绪特征也会反映出人们在哪些情况下感觉良好。知道人们什么时候感觉良好可以让你有机会更频繁地重新营造相似场景。讨论情绪问题还有一个原因，那就是它们有可能会榨干日常工作生活中的激情和动力，但这经常被团队忽视。只有通过与团队交谈，你才能理解正在发生的事情，并着手去解决问题、消除负面影响和加强正面影响。
术语“团队”的定义
当我在本书中使用“团队”这个术语时，指的是职业情境中任何形式的团队。它可能是一个软件开发团队、人力资源团队或任何其他类型的团队，甚至可能是你们运动俱乐部的团队。换句话说，团队就是协同合作实现共同目标的一群人。
在开始下一步之前，先花点时间和团队一起确定你们所审视时段的整体情况。让每个团队成员都说说他的见解，或是给整个团队一点时间深思你已收集的信息(例如用时间轴)。
提示一下，在除夕夜回顾中，我们通过将事件分为如下三类来收集数据。
• 今年我喜欢什么？
• 今年我不喜欢什么(或什么让我生气)？
• 谢谢你。
接着我们每个人简要地介绍所选择的主题。通过在问题上使用情绪词汇，我们逐渐地将事实和感受结合起来。经验告诉我，回顾的这个阶段应该经常变换形式。我会贯穿全书各章节介绍它的各种形式。如果你已急不可待，那可以看看后面的1.4 节。
1.3.4 阶段四：生成见解
“生成见解”阶段可以尽可能多地了解现状背景，以及可能的原因和关联。
分析前一个阶段收集的事件并且提问“这些事为什么发生”。我们所要探求的是有关引发此事件的根本原因的见解。除了阶段一，被忽略最多的就数这个阶段了。很多团队会跳过此阶段，急着尝试去定义未来的试验，而不考虑当前情况的可能原因。这意
味着他们仅抓住了表面现象，而他们的措施也只是针对这些(表面)症状而非根因。这就像摔伤了腿去吃止疼药。疼痛短时间内是会消失，但由于没有处理根本病因，疼痛很快就会再次来袭。这办法不好，因为它看似能解决问题但往往只会带你再回到老路。另一方面，圆满完成此阶段可以为下一阶段“定义试验及其假设”提供一个坚实的根基。不要试图一次处理完所有问题。相反，选出团队觉得最重要的问题。你们不可能一次回顾会就解决所有问题。此阶段的设计是要帮助团队退后一步来观察全局，并开始查找根因。在下个迭代期间同时应对3 个以上议题是不合理的，因为这些议题并非你们必须应对的全部。你需要用在这个阶段
收获的认知来确定合理且有效的措施。
在我家的除夕夜回顾上，每个家庭成员都可以选择一个他认为最重要或是那一刻他最想讨论的主题。我们目前是用“5 个为什么”来找原因。等孩子们长大了，我们会换用别的方法。
1.3.5 阶段五：定义试验
前四个阶段为定义试验这一步打下了坚实基础。我们对所考虑的时段达成了整体共识，并且对所发生的各种事件也有所了解。在此刻，大多数团队已经对下面要改进或尝试的内容有了一些想法。所以团队接下来要做的就是选择一两个行动措施并讨论如何落地。这也能确保团队投入时间去落实这些决定。毕竟，日常工作仍需要完成。试图一次改太多东西可能会出问题，而且也会让大家回头很难分辨哪些试验真正有效。我刻意选用了“试验”这个词。没人知道做出尝试后会发生什么。
尽管我们对可能发生的结果(我们的假设)有一些看法，但是没人能肯定。这类似于一名研究员创建一个试验来测试他的假设。只有到试验的最后才能知道它实际上成功与否。大多数时候，应对这些试验最有效的方法是定期回顾，周期尽可能短。这营造出一个安全的空间：对于一个出错的试验，如果你能很快地结束它，损失比任由它泛滥成灾低得多。
定义相匹配的假设与定义试验本身同样重要。之所以完成试验，不(只)是为了好玩，而是因为想让它产生效果。这些假设让我们可以在下一次回顾时判断试验的效果程度。所以，假设必须是可以检验的。一个像“这会减少软件中的错误”这样的假设是模糊的且很难进行有意义的评估。这个假设的改良版本可能是“已知的软件错误数会降到10 个以下”。必须经常考虑如何检验假设。这是使假设有意义的唯一方法，如果第一次证明不成功，就基于原来的假设来定义新的试验。
实用技巧
明确地向团队解释在这个阶段定义的任何行动只不过是一个试验。没人能事前确定实际产出是什么。让回顾的成果对所有人可见是一个好做法。敏捷团队(例如一个Scrum 团队)总是把定义的试验列入下一个迭代。所选择的试验被认为是正常工作量的一部分，而非额外任务。事情就应该如此。团队有意愿去完成这些任务也是很重要的。最好每个试验由一个人负责。负责人无须全靠自己独立完成试验，但是必须负责确保行动的开展。如果现在不指派给任何人，你很可能会发现谁也不觉得自己对试验的完
成有责任。
在除夕夜回顾时，我们用圆点贴(如图1-3 所示)来选择试验。然后我们将这些试验呈现在公告板上来跟进它们的状态。没有什么比把任务列表记录在文档、Wiki 或电子邮件里然后不了了之的做法更差的了。
图1-3 圆点投票
1.3.6 阶段六：收尾
“收尾”阶段主要是花几分钟作一个简短的审视并庆祝一下本次回顾会的成果。这是对团队投入回顾和前期工作或迭代的时间和精力的认可。另外还应该妥善地记录下成果。做法很多，例如对白板拍照留存或是保留团队用于梳理他们想法的白板纸。就像之前所说的，要把这些东西放在团队工作空间的显眼处。最后，引导者对本次回顾作总结，这是为了确认每个人都理解这个计划。
作为最后一步，一个好办法是对回顾本身也作一个简要回顾。毕竟，我们也想让持续改进活动延伸到回顾本身。这方面有个工具称为ROTI (Return on Time Invested，时间投资回报率)图，如图1-4 所示。
图1-4 ROTI 图
什么是ROTI 图
ROTI 图常被用于在会议结束后从团队那里快速获得反馈。用此方式确认回顾效果是良好还是仍需改进很方便。画ROTI 图时，只需要先画出x 和y 轴，然后画一条对角线并标记上1～5 的数字。1 代表“这个会议纯粹是浪费时间”，3 代表“这个会议刚好值回我投入的时间”，5代表“这个会议超级棒，我投入的时间物超所值”。参会者每人在图上画个叉，代表他的观点，最终完成的曲线图就是结果。正如从图1-4 中看到的，团队在他们的回顾会上还是很愉快的。
我和家人可以在五彩缤纷的烟花景象下庆祝我们的除夕夜回顾。遗憾的是，烟花不可能天天放，但是回顾结束时来一小片美味的蛋糕也能给回顾画上完美的句号。
实用技巧
回顾的各个阶段所花费的时间很显然取决于每个阶段所选择的具体活动，也同样取决于可支配的总时间。不过，一般来说，可以基于总时间和各阶段占时百分比来推算出所需的时间。举例来说，如下是60分钟的回顾各阶段的时间分配情况。
(1) 设定基调(5 分钟＝总时间的1/12)
(2) 检查假设(5 分钟＝总时间的1/12)
(3) 收集数据(10 分钟＝总时间的1/6)
(4) 生成见解(20 分钟＝总时间的1/3)
(5) 定义试验(15 分钟＝总时间的1/4)
(6) 收尾(5 分钟＝总时间的1/12)
这些时间安排只是一般性的规则，不过在你规划回顾时，参考它们作为起步还是很靠谱的。
阶段模型提供了一个能帮助你规划和高效完成回顾的简单框架。通过使用这个框架，你将拥有一个理想的基础。但请记住，每一个回顾都是独一无二的。这6 个阶段已经过多次检验证明是有效的。在本书剩余章节中，你将会学习到如何将这个模型运用于工作和生活中，同时如何处理可能出现的典型问题。
节选自《改善敏捷回顾 提升团队效率》第一章
《改善敏捷回顾 提升团队效率》试读电子书，免费提供，有需要的留下邮箱，一有空即发送给大家。邮箱留到微信回复更快（邮箱地址+试读书名），别忘啦顶哦！
微信：qinghuashuyou
更多最新图书请点击查看哦（即日起-5月31日：关注@qinghuashuyou 发送：关注技术方向，不定时有新书上新，参与互动即有机会获得推广新书样书）
