阿尔伯塔软件项目管理-V-笔记-全-

阿尔伯塔软件项目管理 V 笔记（全）

001：《软件改进的评审与度量》｜专项课程预告

概述

在本节课程中，我们将简要介绍艾伯塔大学软件产品管理专项课程的整体内容与目标。该系列课程旨在教授如何成功地将一个软件产品从概念构思引导至最终交付。

大家好，我是乔纳森·舍费尔，一名计算机科学家，现任艾伯塔大学理学院院长。

我很荣幸地向大家介绍由我校计算机科学系开发的软件产品管理专项课程。

这套系列课程将教你如何成功引导一个软件产品从初始概念发展到最终交付。

艾伯塔大学被公认为世界领先的公立研究型与教学密集型大学之一。

作为加拿大顶尖大学之一，我们在科学、人文、创意艺术、商业、工程和健康科学等领域均以卓越著称。

我们的热情在于为学生成功提供起点，我们的目标是激励、转变和提升我们的学生，并帮助他们实现目标。

强大的协作与沟通技能对于复杂软件的开发至关重要，正如它们在我们生活的许多领域一样。

考虑到这一点，我们的计算专家团队将为你提供掌握敏捷软件开发所需的过程与实践。

我们对软件产品管理流程的实践理解，将为你提供直面挑战所需的一切。

我们将教你如何理解并优化客户的软件需求，以及如何将这些需求传达给开发团队。

你将学习从监控项目到确保其符合客户需求、遵循项目计划并达到预期质量水平的技术。

你将有机会加入一个软件产品管理社区，在那里你可以分享经验并从他人的见解中学习。

最后一门课程是一个为期六周的顶点项目，它将为你提供在真实模拟中应用这些管理技术的机会。成功完成顶点项目后，你将获得认证，并为在软件产品管理职业生涯中脱颖而出做好准备。

我很高兴你对学习我们的专项课程感兴趣。我们已经尽力使这成为一个有价值的教育体验。

现在轮到你了，祝你好运。

总结

本节课我们一起了解了艾伯塔大学软件产品管理专项课程的总体介绍、教学目标以及最终的学习成果。该课程体系旨在全面培养学员从需求分析到项目交付的软件产品管理能力。

002：评审指标简介以改进软件

在本节课中，我们将要学习如何通过评审和度量来持续改进软件产品。我们将探讨如何确保开发出“正确的产品”，并以“正确的方式”执行和管理开发过程。

概述

假设你正在开发一个软件产品。你已经识别了产品机会，与潜在用户进行了沟通，定义了明确的需求，规划了整体发布计划，并且开发团队正在进行设计与实现。但一切都在正轨上吗？在敏捷开发中，什么需要改变？

我之前概述过，更好的软件涉及三个目标：正确的产品、正确地执行以及正确地管理。但你如何知道自己是否与这些目标保持一致？又如何提升自己在这三方面的能力？

对于每一个目标，你都需要从特定类型的评审和度量所获得的持续反馈中，获取改进的见解。在考虑改进产品本身、底层流程和整体项目时，你需要分析主观和客观数据的混合信息。

三个目标与对应的反馈机制

上一节我们介绍了软件改进的三个核心目标，本节中我们来看看每个目标分别对应哪些具体的反馈活动。

1. 正确的产品

为了确保开发出“正确的产品”，你需要获取关于产品是否满足用户和市场需求的反馈。

以下是获取此类反馈的关键活动：

产品演示：向利益相关者展示产品，以获得早期反馈。
用户研究：观察用户如何使用产品，评估其有效性和效率。
满意度数据收集：收集关于用户满意度的数据。
市场成功指标监测：关注产品在市场上取得初步成功的迹象。

团队利用所有这些信息来确定产品功能中需要改进的部分。

2. 正确地执行

为了确保开发过程“正确地执行”，开发团队需要关注工作产出的质量和开发流程的效率。

以下是确保过程正确的关键实践：

同行评审：开发人员审查和检查他们创建的工作产品，以便及早发现和修复问题。
质量指标监控：监测与重要质量因素相关的数据，例如以缺陷率衡量的正确性。

团队利用这些信息来确定在项目实现过程中需要改进什么，以及为了达到期望的质量水平需要对流程进行哪些调整。

3. 正确地管理

为了确保项目“正确地管理”，开发团队需要关注工作进度、团队协作和任务完成情况。

以下是支持有效项目管理的关键实践：

每日站会：团队每天进行简短会议，同步更新彼此的工作进展。
速率跟踪：跟踪测量团队的工作速率。
进度监控与沟通：监控并沟通计划内用户故事和任务的完成情况，让每个人都知道项目状态。

团队应用这些信息来协调工作，并确定如何改进才能更有效、无浪费地完成工作。

本课程结构

本课程涵盖了一系列实践，旨在及早、定期且持续地揭示潜在的产品、流程和项目问题。随着问题得到解决，软件会在每次迭代中变得更好。

本课程包含四个模块：

第一模块：聚焦于“正确的产品”目标。将详细讨论冲刺评审会议、用户研究以及衡量产品成功的示例指标。
第二模块：聚焦于“正确地执行”目标。将描述开发人员用于检查和改进工作的同行评审技术，解释度量的目的，并介绍有用的软件度量应具备的属性，最后讨论与缺陷相关的度量。
第三模块：回归到“正确地管理”目标。将描述名为每日站会的常见敏捷实践，回顾速率的概念，并详细介绍用于跟踪连续冲刺中已完成用户故事的发布燃尽图，以及用于跟踪冲刺内任务完成的任务板和迭代燃尽图。
第四模块：讨论回顾会议。这是一种用于总结经验教训的实践，可以在每个冲刺结束后或整个项目结束后进行。将描述项目回顾会议中的练习，以识别成功、揭示不足、复盘过程、认可所有贡献者，并产生建设性的经验教训以应用于未来项目。

总结

本节课中，我们一起学习了软件改进的三个核心目标（正确的产品、正确地执行、正确地管理）及其对应的反馈机制。通过本课程，你将学习到一套有效的反思性实践，用以改进你的产品、流程和项目。这些知识将帮助你创造出优秀的软件产品——一个正确的产品，以正确的方式完成，并得到正确的管理。😊

003：监控简介

在本节课中，我们将学习软件产品管理中的核心概念：监控、度量与反馈。这些是确保我们“交付正确的产品”并“正确地交付产品”的关键实践。

我们首先回顾一下之前课程中学到的重要术语。在之前的课程中，我们定义了“验证”和“确认”这两个概念。

验证指的是软件产品满足所有规定的要求。它通过执行单元测试来实现，确保具体的底层功能按预期工作。在测试驱动开发中，这些测试甚至在一个功能源代码编写之前就已写好。
- 公式/定义：验证 = 产品符合规格说明
确认指的是发布的软件产品让客户和/或用户感到满意。你可以通过频繁演示和开放沟通从客户那里获得确认，也可以通过用户研究、调查或焦点小组从用户那里获得确认。
- 公式/定义：确认 = 产品满足用户/客户需求

简而言之，验证确保你“正确地构建产品”，而确认确保你“构建了正确的产品”。本模块的重点是如何交付正确的产品，因此“确认”是本模块的一个关键术语。

现在，让我们为本课程引入一些新的术语。

监控在软件开发中，指在整个开发过程中对产品和过程进行跟踪、评审和评估。监控对于确保你“交付正确的产品、正确地交付、并正确地管理”至关重要。敏捷开发强调增加透明度，而各种监控技术使得项目状态在任何时候都能被所有人知晓。

度量是一种测量事物的方法。在开发中，你可以使用度量来测量产品、过程和项目的各个方面。度量是一种能产生可量化结果的、有效的监控方式。但请注意，并非所有可计数的东西都有价值，也并非所有有价值的东西都可被计数。

监控和度量有助于提供反馈。

反馈是为提出改进建议或确认你走在正确轨道上而提供的信息或批评。在软件开发中，反馈可能表现为计算结果、用户研究结果、团队提出的建议或客户的反应。反馈可以是定性信息，也可以是定量信息。它是识别产品改进方向的绝佳方式。敏捷致力于尽可能频繁地持续改进，这可能意味着改进产品、沟通、流程或所用实践。反馈也可用于其他场景，例如在精益方法中评估备选方案时，你可以利用反馈来决定哪个选项是正确的。

在下一节中，我们将讨论第一种评审类型：Sprint评审会议。这是你从客户那里获得关于产品的确认的关键环节。

本节课总结

本节课我们一起回顾了“验证”与“确认”的区别，并引入了“监控”、“度量”和“反馈”这三个核心概念。我们明确了监控和度量是确保项目透明和方向正确的重要工具，而反馈则是驱动持续改进的关键输入。接下来，我们将深入探讨具体的评审实践。

软件产品管理课程5：第5.1.2节：冲刺评审会议 🎯

概述

在本节中，我们将学习冲刺评审会议。这是敏捷开发中一个关键的活动，用于展示产品成果、获取反馈并确保团队正在构建正确的产品。

敏捷术语回顾

在深入细节之前，我们先回顾一下本课将用到的敏捷术语。

冲刺评审会议：一种常见的Scrum活动。
Scrum主管：负责推动Scrum实践的角色。
产品负责人：负责管理产品待办事项列表的角色。
冲刺：指代迭代周期。

在冲刺结束时，会发生两个不同的Scrum活动：冲刺评审会议和冲刺回顾会议。简单来说，冲刺评审会议是展示产品的地方，而冲刺回顾会议是重新评估和讨论团队流程的地方。

你将在本课程的最后一个模块中学习冲刺回顾会议。冲刺评审会议在冲刺回顾会议之前举行。

冲刺评审会议详情

现在，让我们深入了解细节。我们在“软件过程与敏捷实践”课程中关于Scrum的课程里介绍过Scrum活动。

Scrum活动与时间盒

Scrum活动贯穿整个开发过程。冲刺、每日站会、冲刺评审会议和冲刺回顾会议都是Scrum活动的例子。除了冲刺本身，其他Scrum活动都是获取反馈和评估进展的正式机会。

所有Scrum活动都是时间盒化的，这意味着它们不能超过预定的时间。

为冲刺评审会议建议分配的时间是：冲刺的每一周对应一小时。
因此，如果你的冲刺为期两周，你应该将评审会议时间盒设定为两小时。如果你的冲刺为期一个月，评审会议应分配四小时。

小测验
你正在为你的开发团队安排冲刺评审会议。你的团队刚刚完成了一个为期三周的冲刺，他们渴望展示进展。这个会议最长应该持续多久？
A. 一小时
B. 每周结束时各一小时
C. 三小时
D. 需要多久就多久

答案：C
你应该将冲刺评审会议时间盒设定为冲刺每周对应一小时。由于你的团队采用三周长的冲刺，你应该为此会议安排三小时。会议不应超过三小时，因此C是正确答案。

会议参与者

接下来，我们谈谈谁应该被邀请参加冲刺评审会议。答案很简单：任何对产品感兴趣的人都被邀请。或者用本专业的术语来说，所有利益相关者都应被邀请。

通常，会议包括Scrum主管、产品负责人、Scrum团队、管理层、一些客户和用户，可能还有其他项目的开发人员。

会议旨在保持非正式。这意味着不需要幻灯片演示，只需最少的准备。由于会议的核心是展示产品，唯一需要的准备就是将产品开发成可工作的软件——这正是开发团队在冲刺期间应该做的事情。这些会议几乎不需要额外准备，因为冲刺评审会议不应分散开发团队的注意力。

会议中的角色

我们来谈谈冲刺评审会议中的一些角色。

Scrum主管：负责引导会议。他们确保会议保持在时间盒内，确保对话不偏离主题，人们提出相关意见，并以适当的方式提问和提供反馈。
开发团队：虽然Scrum主管引导会议，但通常由开发团队来主持会议。团队中的每个人都应在会议中有所贡献，因为他们都参与了工作。
产品负责人：负责批准功能，并确保Scrum团队遵循整体的产品愿景。
其他利益相关者：在会议结束时有机会提出反馈和改进建议。

小测验
你是冲刺评审会议上的Scrum主管。当开发团队演示产品时，一位利益相关者提出了一个新功能的建议。开发团队、产品负责人和该利益相关者开始讨论这个新功能。作为Scrum主管，你应该怎么做？
A. 加入讨论
B. 将该功能添加到待办事项列表中
C. 让他们完成讨论
D. 要求他们将功能建议留到会议结束时再提

答案：D
作为Scrum主管，你负责引导会议，这意味着要确保会议按计划进行。你希望将功能建议留到会议结束时再提，这样可以让开发团队完整地演示他们的产品而不受干扰。如果对话开始偏离主题，你应该引导他们回到正轨，否则你可能会超出时间盒。因此，D是正确答案。

会议流程

现在，我们来谈谈会议中具体会发生什么。

Scrum主管应以介绍会议准则开始。这些准则可能包括人们何时可以发言或提出建议等。

随后，Scrum团队应回顾冲刺目标。重申冲刺目标后，冲刺评审会议会发生三个主要事件：

以下是会议的核心环节：

产品演示
产品负责人批准
利益相关者反馈

1. 产品演示

首先，Scrum团队演示产品。演示应尽可能真实，使用合适的平台。例如，如果团队正在创建移动应用，他们应该使用移动设备进行演示。

演示也应该是真实的。这意味着功能不应仅为演示而进行硬编码。它应该是已完成功能的现场演示。

功能只有在满足团队的“完成定义”时才能被演示。 未完成的功能应留待未来的冲刺评审会议，当它们完成时再展示。

例如，产品演示只包括那些已编码、已测试、已文档化、可用且准备发布的功能。

小测验
在当前冲刺中，开发团队计划构建四个功能（我们称之为用户故事A、B、C和D）。用户故事A和B满足了团队的“完成定义”。用户故事C已完成且能工作，但尚未经过充分测试。用户故事D离完成还很远，但开发人员可以对其进行硬编码，使其在演示中看起来能工作。开发团队应该在冲刺评审会议上演示哪些用户故事？
A. 用户故事A、B
B. 用户故事B、C
C. 用户故事C、D
D. 用户故事D

答案：A
你的开发团队应该只演示那些满足Scrum团队“完成定义”的用户故事。这通常意味着它们已编码、可测试且可用。只有用户故事A和B符合这个标准。用户故事C在演示前仍需测试，这对于确保产品按预期工作很重要。你绝不应为演示而硬编码功能，因此A是正确答案。

2. 产品负责人批准

产品演示之后，产品负责人从产品待办事项列表中批准已完成的功能。一旦产品负责人批准了一个功能，它就会从产品待办事项列表中移除。团队可以选择在会议上完成批准，或者产品负责人可以在花额外时间评估产品后再批准。

3. 利益相关者反馈

批准之后，Scrum主管向利益相关者开放发言权。这是利益相关者提问、建议功能和提供反馈的机会。

通常，反馈采取以下三种形式之一：

可以是赞扬，表示产品或功能方向正确。
也可以建议需要更改或改进的领域。
或者，反馈可能指出引发新问题或需要重新审视假设的领域。

由于待办事项列表由产品负责人维护和确定优先级，利益相关者可以自由提出任意多的功能建议。由产品负责人决定是否以及何时开发这些功能。这也是产品负责人可以建议将功能加入待办事项列表的时机。

我们之前提到过，不应在冲刺中途将建议添加到冲刺待办事项列表中。现在（评审会议结束时）是添加建议的适当时机。

小测验
在冲刺评审会议上，你已经进入了第三个阶段，即开放会议以征求建议和反馈。此时，谁可以提出额外的功能建议？
A. 产品负责人
B. 利益相关者
C. 开发团队
D. Scrum主管

答案：A, B, C, D
在会议的这个阶段，任何人都可以建议将功能添加到待办事项列表中。产品负责人负责确定待办事项的优先级，并选择何时以及是否构建功能。让任何人提出建议并无害处，因此A、B、C、D都是正确答案。

总结

本节课我们一起学习了冲刺评审会议。冲刺评审会议是展示Scrum团队辛勤工作、提高透明度并获取宝贵反馈的绝佳机会。它们也为Scrum团队提供了明确的工作目标，并鼓励他们产出可工作的软件。

在下一课中，我们将继续讨论如何交付正确的产品，重点介绍用户研究及其在软件开发中的应用。

005：用户研究

在本节课中，我们将学习如何通过用户研究来验证你的软件产品是否真正适合目标用户。我们将探讨用户研究的定义、类型、实施方法以及如何解读其结果。

为你的客户生产正确的产品是一回事。为你的用户生产正确的产品是另一回事。我们在关于客户需求和软件要求的课程中已经讨论过一些可用性的内容。在那门课程中，我们更多地讨论了如何设计一个能为用户工作的产品。在本课中，我们将讨论如何验证你的产品能为用户工作。

在开发软件产品时，考虑可用性极其重要。如果用户不会用或不喜欢你的产品，他们就不会使用它。进行用户研究是验证你正在为用户创造正确产品的一种方法。用户研究可以衡量产品的可用性。

我找到的最好的可用性定义来自哥本哈根大学一项关于可用性研究挑战的论文。该研究很好地概述了当今常见的不同类型的可用性研究。如果你有兴趣阅读更多内容，可以在课程资源中找到它的参考文献。

他们将可用性定义为：特定用户在特定环境中达成目标的效率、效果和满意度的度量。

我喜欢这个定义，因为它指出了用户研究的几个关键方面。首先，它指出用户研究可以衡量效果、效率和/或满意度。通常，用户研究侧重于效果和效率，并推断出满意度是拥有一个有效且高效产品后的结果。虽然有时可能存在相关性，但情况并非总是如此，我们将在本课后面讨论这一点。

该定义强调的另一个方面是，研究包含在特定环境中达成目标。使用软件产品完全是为了达成目标。即使它不像游戏等产品那样明显，产品也有其预期用途或目标。

可用性研究可以发现许多问题。一是用户是否以预期方式达成了指定目标。另一个是用户是否以非预期方式使用产品来达成目标，或达成一个全新的目标。如果用户没有以预期方式使用产品或达成预期目标，那么原因是什么？是用户界面的结果吗？还是说这个产品可以解决一个新的、可能更好的问题？

该定义还强调了“特定用户”和“特定环境”。为你的研究选择合适的用户，并控制环境和测试方法非常重要，我们将在本课后面讨论这两点。

上一节我们介绍了用户研究的核心定义和目的，本节中我们来看看一个具体的测量案例。

你正在为你的产品进行一项用户研究。在研究中，你给受试者一个要达成的目标。然后你观察用户如何与产品交互。你还在计时他们达成目标所需的时间以及达成目标所需的点击次数。

这项用户研究测量了哪些因素？A 效果， B 效率，和/或 C 满意度。

这项研究只测量了效果和效率。因此，A和B是正确答案。效果通过受试者是否达成目标来衡量。效率通过达成目标所需的时间和点击次数来衡量。如果你想测量满意度，可以在用户使用产品后对他们进行访谈。你可以询问一些关于他们是否喜欢该产品，或者他们对自己是否正确达成目标的信心程度的问题。

了解了基本测量维度后，以下是几种常见的用户研究实施方式。

一种常见的用户研究方式是让测试参与者在专家观察和记录下使用产品。有时会为用户提供他们试图达成的目标。有时用户也可以随心所欲地浏览产品。用户在尝试达成目标时，通常被要求进行“出声思考”。

当用户有特定目标要达成时，用户研究验证产品是否允许用户达成目标。它还揭示了应用程序中可能阻碍用户达成目标的部分。

另一种类型的用户研究是要求用户按照自己的感觉使用产品。通过这种方式，你可以了解很多关于产品的信息。在这类研究中，用户通常被要求进行“出声思考”。从这类研究中，你可以确定产品自然地鼓励用户做什么。这与产品的预期目标不同吗？你甚至可能发现产品如何被用于不同的目的。当这种情况发生时，你要么必须调整产品以匹配其原始预期目标，要么可以改变产品的重点以匹配这个新用途。

这些类型的用户研究可以让你获得关于产品的反馈，例如产品使用起来是否有趣、其美观性、明显的可用性以及产品流程。

还有一种类型的用户研究是你会“跟随”你的用户，看看用户的典型一天是什么样的。他们完成什么任务？是否有产品能让这变得更容易？这种类型的用户研究可以引导你开发出适合用户的创新产品。

除了直接观察，另一种测试产品的方法是A/B测试。在A/B测试中，你将产品的两个版本相互比较。通常，这是通过发布两个非常相似、仅改变一个功能的产品来实现的。然后，你将获得关于新产品与旧产品相比表现如何的可量化结果。

你正在为一家在线购物公司进行A/B测试。该公司的在线邮件列表有1000名订阅者。你向其中500名订阅者发送一个版本的电子邮件，向另外500名订阅者发送另一个版本的电子邮件。每个版本的电子邮件都有不同的优惠券代码。一周后，你检查网站的统计数据，查看每张优惠券被使用了多少次。第一个版本的电子邮件对应有10人使用了优惠券代码。第二个版本的电子邮件产生了15次优惠券代码使用。

你可以从这个A/B测试中得出什么结论？A，你有可量化的结果表明第一个版本的电子邮件更有效。B，你有定性的结果表明第一个版本的电子邮件更有效。C，你有可量化的结果表明第二个版本的电子邮件更有效。D，你有定性的结果表明第二个版本的电子邮件更有效。

这个A/B测试提供了可量化的结果，因为我们有可以用统计分析的数字。结果显示，第二个版本的电子邮件比第一个版本产生了更多的优惠券销售。因此，C是正确答案。

用户研究也可以选择应用可量化的可用性指标。例如，这类指标可以衡量用户完成任务所需的时间、页面点击次数以及被点击最多的按钮和元素。这类指标比产品的满意度更少主观性。但这会使它们不那么重要吗？正如我之前提到的，满意度通常不是有效和高效产品的直接结果，尽管那可能有所帮助。

在用户研究中，你应该仔细选择研究中的参与者。这些人就是你的“特定用户”。你要确保你选择的人能代表你的目标受众。你希望你的特定用户与你实际打算使用产品的人具有相似的特征。这可能是他们的背景或计算机技能水平等特征。例如，你不希望让开发人员作为针对幼儿产品研究的参与者。

同样，虽然让朋友和家人试用你的产品很容易，但你需要确保他们给你的是公正的反馈，而不仅仅是告诉你你想听的话。

如果你想亲眼看看用户研究是如何进行的，可以报名参加一个。大多数科技公司都会进行用户研究，并且需要参与者。找一家当地的科技公司，看看你是否能成为用户研究的一部分。你不仅能获得第一手经验，还能帮助你当地的科技圈。

还有许多其他方法可以测试产品的可用性。让我们在课程讨论中谈谈其他方法。在下一个模块中，我们将看一些行业例子，看看他们如何验证自己正在为用户创造正确的产品。

本节课中我们一起学习了用户研究。我们明确了可用性的定义是衡量特定用户在特定环境中达成目标的效率、效果和满意度。我们探讨了用户研究的不同类型，包括目标导向测试、自由探索和A/B测试，并了解了如何选择代表性的用户以及如何解读量化与质化的研究结果。这些方法共同构成了验证产品是否真正适合用户的重要工具。

006：行业范例 🏢

在本节课中，我们将探讨几家主要公司如何打造正确产品的行业范例。之后，我们将了解一位高效产品经理需要关注的其他领域。

苹果公司的设计流程 🍎

首先，我们从一个以持续交付正确产品而闻名的公司开始：苹果公司。苹果以其优雅的产品著称。他们是如何做到持续交付正确产品的呢？

当一个想法形成后，苹果会从原型设计开始。苹果的原型设计通常被称为“像素完美”原型或“10-3-1”原型设计法。

他们最终的、接近成品的原型之所以被称为“像素完美”，是因为其设计精细到了每一个单独的像素。这意味着他们不仅设计界面，更是以最高级别的细节——像素级——进行设计。可以想象，这种做法成本高昂且不够敏捷，但它似乎行之有效。

“10-3-1”原型设计法得名于设计师开发原型的方式。设计师们不受限制地构思出10个不同的原型。这非常类似于精益开发，即在做出决策前探索多个原型。然后，他们会选出3个最佳设计并进一步探索这些选项。最后，他们会选定1个最优方案，并将其原型设计到像素完美级别。

苹果公司还进行定期评审。他们每周举行一次高管团队评审会，审查生产过程。此外，他们还有同行设计会议，这是一个专注于改进设计的、由设计团队和工程师参与的会议。

苹果的设计流程非常详尽，因此成本也很高。但正如市场所见，它是成功的。苹果产品多年来主导市场，因此精心设计工作的投入似乎是值得的。

问题：为什么苹果的原型设计方法被称为“像素完美”？
A. 因为苹果产品中的像素总是完美的。
B. 因为原型设计确保产品中的所有像素都是完美的。
C. 因为原型设计精细到了单个像素的级别。
D. 因为这听起来很酷。

答案：C。苹果将其一种原型设计方法称为“像素完美”，是因为原型设计达到了最高级别的细节——像素级。

谷歌的设计冲刺流程 ⚡

现在，我们来谈谈软件产品与服务领域的另一个巨头：谷歌。谷歌创建了他们的“设计冲刺”流程。这一流程也被其他公司采用，如爱彼迎和蓝瓶咖啡。

这个过程快速且迭代，将过去需要数周或数月的工作压缩到一周，有时甚至更短。谷歌眼镜的原型就是使用这个过程在不到两小时内完成的。这类似于“尽可能快地交付”的精益原则。

设计冲刺包含五个阶段：

以下是设计冲刺的五个阶段：

理解：工程师和设计师评估当前问题，并确定设计对象。
发散：鼓励参与者为问题想出尽可能多的解决方案，无论它们看起来多么不切实际。
决定：参与者投票并讨论哪些想法值得进一步详细探索。
原型：参与者快速绘制草图并构建原型，重点关注用户界面和用户体验。
验证：将产品交给用户，鼓励设计师和工程师进行演示，并收集用户反馈。

这个流程的每个阶段都计划在一天内完成。

问题：设计冲刺的五个阶段是什么？
A. 理解、发散、决定、原型、验证。
B. 评估、头脑风暴、投票、创建、测试。
C. 理解、头脑风暴、决定、原型、测试。
D. 评估、头脑风暴、决定、原型、测试。

答案：A。设计冲刺的五个阶段是：理解、发散、决定、原型、验证。

Intuit的“跟我回家”验证法 🏠

我们已经讨论了一些大公司如何设计正确的产品，现在来看看另一家大公司如何验证其产品确实是正确的产品。Intuit采用了一种名为“跟我回家”的方法。

Intuit是一家制作会计软件的公司。其创始人斯科特·库克在公司早期就开始了这项实践。库克会待在当地的办公用品商店，等待有人购买他的软件。然后，他会询问顾客是否可以跟随他们回家，观察他们安装和使用软件的过程。这种做法听起来有点令人不安，但非常有效。它让Intuit能够打造出真正适应用户环境并完全满足其需求的产品。

Intuit现在仍以更可控的方式继续使用这种方法。他们平均每年进行约20次访问，每次访问大约一小时。在访问期间，他们观察客户使用软件的情况，并记录客户的工作环境、办公室的工作方式以及软件如何融入业务。

问题：“跟我回家”方法提供的是什么？
A. 验证
B. 确认

答案：B。“跟我回家”方法提供的是对产品的确认。它测试的是用户的满意度，而不是测试特定功能是否按预期工作。

IBM的设计思维实践 💡

IBM实施了一项名为“设计思维”的实践，它结合了原型设计、用户观察和敏捷开发。设计思维是斯坦福大学开发的一个概念，后来被IBM采用并调整以适应其需求。

设计思维专注于识别人们的需求，并提出满足这些需求的解决方案。传统的设计思维有四个主要阶段：理解、探索、原型、评估。IBM对此进行了调整，增加了三个阶段：赞助用户、山丘和回放。

这个过程始于最终用户。你需要找出用户需求未被满足的原因。为了理解用户需求，你需要找出实际的用户是谁，并发现他们如何思考、看到什么、如何使用产品以及用产品做什么。

然后，他们寻找对产品感兴趣的候选人，并最终确定一位具备典型用户许多特征并面临许多相同问题的候选人，这就是赞助用户。随着产品的成长，他们被用来提供见解。团队与赞助用户合作以获得见解和信息，并以此识别产品的问题。这个挑战就是山丘陈述。

接着，团队将这个问题带给更大的团队以寻求解决方案。团队探索针对该挑战的各种解决方案，剔除糟糕或不切实际的想法。一旦解决方案范围缩小，他们就开始为这些解决方案绘制草图，然后更正式地将想法原型化。可能需要几次迭代才能确定最佳方案，这些迭代被称为回放。

最终，创建一个工作模型并与最终用户一起评估。根据赞助用户的反馈对想法进行迭代改进。改进后，产品发布，但会根据新的用户需求持续测试和改进。

本节课总结：在本节课中，我们一起学习了四家领先科技公司（苹果、谷歌、Intuit、IBM）用于确保产品正确性的核心方法论。从苹果的“像素完美”精细设计，到谷歌的快速“设计冲刺”，再到Intuit深入用户环境的“跟我回家”验证，以及IBM结合用户洞察与敏捷迭代的“设计思维”，这些范例展示了产品开发中理解用户、快速迭代和持续验证的重要性。

007：行业范例访谈

在本节课中，我们将通过一位视频游戏行业产品经理的访谈，学习产品经理如何运用产品战略、生命周期管理和市场情报来识别并实现正确的产品。我们将了解产品经理的核心职责、所需技能以及衡量产品成功的关键方法。

上一节我们探讨了行业巨头如何交付正确的产品。本节中，我们来看看产品经理如何运用产品战略、生命周期管理和市场情报来识别并实现正确的产品。

我的名字是Clon Costa，我是一名制作人，相当于视频游戏行业的产品经理。

作为一名产品经理，我需要负责产品的三大支柱：一是产品战略，我需要深刻理解产品的愿景，并确保团队也理解它；二是产品本身的开发；三是产品如何触达消费者，即产品的分发。

软件产品经理需要具备出色的沟通能力。他们还需要深刻理解市场趋势和竞争对手的优势。你必须擅长了解市场现状，并且非常精通如何创造软件。你对软件开发理解得越深，就越能帮助团队实现之前设定的产品愿景。最后，同样重要的是，你需要理解产品的商业层面，包括你将采用何种商业模式、如何最终触达消费者（是通过数字分发还是零售）。所有这些能力的结合，才能造就一名优秀的软件产品经理。

市场情报是理解市场现状的能力：你的消费者是谁？你的受众是谁？你和消费者之间是否有零售商（他们可能也是你的客户）？当前市场在技术、分销或商业模式等方面有何趋势？它也是你理解市场需求的能力：当前市场是否存在尚未被满足的空白？你能否触及这个空白并比其他人做得更好？这就是我所说的市场情报。

我认为这需要大量的研究。你必须投入精力去理解市场，所以你需要大量阅读。在软件开发领域，你还需要去玩、去使用其他软件，以便理解竞争对手的优势。你还需要阅读与你领域（比如我所在的视频游戏领域）相关的杂志、博客或网站。同时，你需要理解如何触达消费者。如今，你可以通过社交媒体直接联系消费者，询问他们在特定产品中寻找什么，或者他们认为某个竞争对手好在哪里、不好在哪里，从而去填补市场空白。

你必须大量使用市场上现有的软件。你需要非常了解自己的软件，需要非常注重细节，深刻理解你的软件为市场提供了什么。同时，你也需要对所有竞争对手做同样的事情。此外，你需要找到一种方式与消费者直接对话，可能是焦点小组，也可能是利用社交媒体。你需要理解是否存在市场空白，是否存在新出现的不同需求，或者市场领导者是否存在你可以做得更好的弱点。

对于用户画像，我们通常的做法是考虑原型和人物角色。你需要尝试理解，以视频游戏开发为例，我们拥有非常广泛的受众，需要理解其中的细分群体，然后为每个细分群体创建人物角色。例如，这可能是一个20岁、21岁的医学生，他想玩电子游戏，因为这对他是一种逃避。另一个角色可能是一位艺人或一位有空闲时间的母亲。你需要创建这些人物角色，一旦有了这些角色，你就要看看你软件的功能如何与这些角色对齐，是否真正满足了这些角色的需求。

产品战略首先是理解你需要构建什么的能力。你的软件必须具备什么才能击败市场上的竞争对手？这是产品战略需要做的事情之一。另一件你需要理解的事情是，你需要为你的产品制定商业模式：你将如何销售你的软件？是订阅制、一次性付费，还是某种免费软件（30天后销售软件的另一部分）？商业模式多种多样，这真的取决于你的市场、你的竞争对手以及你正在做的事情。所以你需要理解你需要构建什么、如何销售它以及如何实际触达消费者、如何分发它。

产品经理需要创造愿景。他需要成为消费者和开发团队之间的桥梁。他需要创造这个愿景，并以非常简洁、简单的方式告诉团队他们需要构建什么、为什么这很重要，以及为什么这足以击败市场上所有的竞争对手。

你的产品愿景可以包含我们所谓的独特卖点。如果你有，比如说五个独特卖点，希望你的产品也会有与这些支柱相关的强大功能。一旦你有了软件的原型，或者已经有了测试版或Alpha版，你就可以创建焦点小组，接触特定的用户群体，实际测试他们如何接受你的软件：他们喜欢这个新功能吗？它足够有吸引力吗？它比市场上的现有产品更好吗？这是一种方法。你可以获得反馈，如果存在摩擦点，你可以减少摩擦点，改进功能，然后再次推向市场。如果你在整个开发周期中持续这样做，那么在发布时，你应该会有一个强大得多的产品。

我认为将你的产品与市场上其他产品区分开来的第一步，是理解你自己的优势和劣势。以我们公司为例，我们在某些领域拥有其他竞争对手所没有的优势，我们努力强调这些优势，确保我们的产品带有我们的标志，让消费者知道这是我们公司的产品。

所以，首先要理解你的优势和劣势，并理解它们如何与市场需求相关联。因为如果你在一个市场并不真正需要的领域很强，那对你没有帮助。但如果这里存在市场空白或需求，而你恰好擅长于此，那么你就能真正做出改变。

产品的货币化模型，对于软件产品来说，现在有很多不同的模式，而且市场变化很快。你可以采用传统的零售模式，在商店销售实体盒装产品；可以采用数字分发，用户只需下载你的软件；可以采用订阅制，就像现在很多软件做的那样；也可以混合模式，比如提供某种免费游玩的软件版本，消费者可以免费下载，但如果想要高级功能，则需要订阅、支付全价或为产品的部分功能支付不同类型的费用。所以，现在桌面上有很多不同的商业模式，这真的取决于你试图进入的市场，取决于你特定市场的消费者。

在初创公司，产品经理拥有更大的灵活性，他必须身兼多职。通常他没有很多资金，但他有一个小团队，可以非常灵活和迭代。我认为这些对于初创公司的产品经理来说是积极的方面。但你需要非常执着和有韧性，因为事情不会容易，因为你的团队很小，资源通常也很有限。在大公司，你拥有更多可用资源的优势，可以进行更好或更广泛的研究、不同类型的调查，甚至可以专门前往世界上有消费者的特定地点与他们交谈。但同时，你可能需要经历更冗长的流程来完成事情，有时需要协调组织内的许多不同团队。因此，对于产品经理来说可能更困难，因为他需要说服更多的人才能完成某件事。

一个软件产品常见的生命周期是：首先有一个预生产阶段，在这个阶段你需要理解你的产品需要是什么（不同行业可能称之为构思阶段）。你需要理解你需要构建什么，以及为什么这个产品比市场上的现有产品更好。这是你设定愿景、让团队围绕一个足以击败市场上所有人的愿景达成一致的阶段。你还需要确保在预生产阶段有足够的资金，并尝试迭代和创建原型，以尽快验证你设想的功能是否真的如你预期那样强大。

预生产阶段之后是生产阶段。这时你已经知道需要构建什么，现在就是关于构建它、扩大规模，并确保在预算或时间等约束下完成一切。你将在生产阶段工作并开发产品。

开发产品之后，我们会进入所谓的最终阶段。在这个阶段，我们尽可能地对产品进行打磨，尝试消除所有错误。我们甚至可能发布一个测试版软件给成千上万的消费者，让他们使用我们的软件，然后反馈给我们哪些地方运行良好，哪些地方不行，他们喜欢什么，不喜欢什么，以便我们在软件正式发布前进行修复。

发布软件之后，我们进入发布阶段。在这个阶段，你需要分发你的软件，让软件实际触达你的消费者。如果你有数字分发和零售商，确保一切正常运转，消费者知道这个软件，并且有办法购买它。

发布阶段之后，在我们特定的案例中，有一个我们称之为实时服务的阶段。这意味着我们必须为软件发布后的所有工作制定路线图，可能包括修复软件的错误补丁，也可能是基于从消费者和游戏记者那里收到的反馈，推出带有新功能的软件扩展。

一旦我们获得反馈，我们会根据现有团队对需要做的事情进行优先级排序，然后制定路线图，产品经理领导这个路线图的制定。

产品发布后，你需要理解的第一件事是你的产品如何被消费者接受。你必须快速分析从消费者角度看，哪些方面做得很好，哪些方面做得很糟。对于一些做得不好的地方，你可能能够通过补丁来修复，或者可能需要快速添加一个功能，从而为你的产品创建一个扩展和更新。另一件你需要做的事情取决于你的产品是否也变成一项服务。如果是一项服务，你需要与消费者保持持续的沟通，了解哪些方面进展顺利，他们不喜欢什么，这样他们可以帮助你为产品制定更好的长期路线图。

衡量软件产品成功的方法有很多种，这真的取决于你的行业。你可能以销售数量、收入、利润率来衡量，也可能以产品质量来衡量（这可以根据行业通过某种评分来测量和比较你的软件与其他软件）。但通常，最终都会回到消费者满意度上。你需要理解消费者如何接受你的软件。一个好的产品经理需要非常精通分析，知道如何利用软件的遥测数据来获取关于需要更改事项的重要数据。

通常，一个好的产品经理会首先尝试创建关键绩效指标。一旦你有了你的KPI（这真的取决于你所在的行业），你就可以开始衡量你的软件是否成功。在内部，你可能有一些KPI，比如对于开发团队，你可能关注每小时崩溃次数或服务器正常运行/停机时间。另一方面，你可能有一些其他指标，比如同时访问服务器的实际人数，即你当前的最高同时在线用户数。有很多不同的指标可以帮助开发团队理解他们的服务或产品是否运行良好。

在外部，你衡量其他一些因素。通常我们有一个我们称之为AOE-M的漏斗：A代表获取，O代表引导，E代表参与，M代表变现。对于获取，我们有诸如实际下载或购买你软件的人数、每日活跃用户数等指标。对于参与度，我们有用户每天使用你软件的会话次数、每次使用时长等指标。我们还有其他参与度指标，比如他们是否可能向朋友推荐你的软件（我们称之为净推荐值）。对于变现，我们有关于他们每天或终身在软件上花费总金额的指标，比如用户终身价值。例如，如果用户最初在产品上花费了60美元，终身又花费了20美元，那么他就值80美元。你还需要关注付费用户的平均收入、每用户的平均收入、付费用户的比例等。有很多不同的KPI来衡量变现。

我跳过了引导阶段。对于一些软件，你可能需要教用户如何使用你的软件，这就是我们所说的引导。对于引导，你可能也有指标，比如他们是否完成了整个教程流程，还是中途停止了。在分析方面，你可以利用这些信息来查看那些完成了完整引导漏斗的用户是否更成功。例如，如果他们完全跳过了教程，他们是否遇到了更多问题，是否更频繁地联系客服？你可能会注意到，那些完成了教程的用户实际上掌握了软件的关键基础，因此需要更少的帮助。

我认为一个成功的产品背后需要一位成功的产品经理。这意味着你需要一个人来充当所有消费者（你拥有的数百万消费者）和开发团队之间的重要桥梁。这个人不仅要做这个桥梁，还要从商业角度理解你将采用何种商业模式、如何分发你的软件、如何触达你所有的消费者。你需要在三大支柱上做得很好：商业模式方面、对市场的深刻理解以及对开发过程的深刻理解。如果一个好的产品经理能在这三大支柱上都做得很好，他很可能会成功。

我认为对于新产品经理来说，他们需要做的第一件事是对软件、对你试图从事的产品充满热情。如果你热爱你所做的事情，你成功的几率会高得多。第二是保持非常好奇的心态。你需要非常好奇，需要努力理解市场现状，需要尽可能多地玩或使用竞争对手的软件，内心需要保持这种好奇心，并且要不断提问：他们为什么那样做？为什么我们不能这样做？或者为什么我们不能做得更好？我认为这是一点。另一点当然是，你需要大量学习。无论你在哪个市场，你都需要大量研究你的市场，深刻理解它的运作方式。最后，我认为对于产品经理来说，知道如何与人相处也极其重要。你不是独自制造软件或产品，你有一个团队，你需要知道如何与团队以及团队内的不同小组良好沟通。你如何确保每个人都在同一个愿景、同一个目标下保持一致？

在本节课中，我们一起学习了产品经理的核心职责，包括管理产品战略、生命周期和市场情报三大支柱。我们探讨了如何通过研究、创建用户画像和设定愿景来制定产品战略，以及产品从预生产到发布后服务的完整生命周期。我们还了解了衡量产品成功的关键指标，如AOE-M漏斗和各类KPI。最后，我们认识到，一名成功的产品经理需要兼具对产品的热情、好奇心、持续学习的能力以及出色的沟通协作技巧。

在下一个模块中，你将学习如何确保你的产品被正确地完成。Bradley将带你了解一些监控技术和指标，帮助你确保产品正确无误。

008：评审技术 🧐

在本节课中，我们将学习如何确保你的软件产品被正确地完成。我们将重点介绍几种用于检查软件开发过程中产出的工作产品的评审技术。这些技术能帮助你更早地发现缺陷，避免它们在后期修复时产生更高的成本。

回想一下冲刺评审会议。在这些会议中，开发人员与客户会面，回顾上一个冲刺周期完成的工作，并确保项目进展正常。本节课程将聚焦于开发团队内部进行的评审，具体讨论不同类型的同行评审。同行指的是在同一级别工作的人员，例如，两位开发人员互为同行。

我们将介绍的同行评审包括：软件技术评审、审查和走查。你将看到，软件同行评审的形式可以从非常正式到非常不正式，其范围可以从深入的技术代码分析延伸到高层的需求设计。

软件走查 🚶‍♂️

最不正式的同行评审是软件走查。

软件走查简单来说，就是一位软件开发人员展示代码如何工作。这是一种“展示与讲述”，开发人员向一小部分听众介绍他们的代码。在整个走查过程中，听众可以提问并指出潜在问题。

走查是非正式的，因为它旨在为开发人员提供一种快速、简便的方法来帮助他们提高软件质量。

以下是一个走查的例子：一位开发人员刚刚构建了一个软件模块，该模块通过连接公司的客户数据库并提取客户支付信息，来授权客户的支付。构建此功能后，开发人员叫来几位同行，询问是否可以快速进行一次代码走查。大家聚集在开发人员的电脑周围，开发人员引导他们浏览代码，跳过许多次要细节。在代码评审期间，开发人员的同行会质疑诸如用于访问数据库的库的可靠性、当前代码是否是资源效率最高的选择，或者代码是否足够安全可以发布给公众等问题。同行们还帮助确保代码可读并符合团队的编码标准。此外，开发人员的同行也会更加熟悉这段代码。当他们处理其他项目时，可能会整合从这次走查中获得的一些知识。正因为这个特点，代码走查常被用作培训新团队成员的一种手段。总而言之，软件代码走查是一种有价值的评审技术。它允许个体开发人员利用同行的力量，获得建议、改进和熟悉度，而无需花费太多额外精力。

在软件走查中，软件开发人员需要产出以下哪项工作产品？
A. 代码评审总结。
B. 需求文档。
C. 会议纪要。
D. 无。

答案是 D. 无。软件走查旨在随意进行，因此不需要产出任何工作产品。

软件技术评审 🔧

软件技术评审与走查不同。

软件技术评审更为正式，其目的是解决产品的技术方面问题。软件技术评审的正式程度取决于实施它的组织。例如，一家军事防务承包商的评审过程会比一家开发手机游戏的公司严格得多。本质上，软件技术评审的全部目的是在技术层面改进软件产品。

软件技术评审可用于创建更健壮的设计、从客户那里形成明确的需求，或对代码进行多项技术改进。

软件技术评审以讨论为导向，包含三个主要角色：

决策者：其工作被评审的人。决策者负责设定评审目标并确定这些目标是否已达成。
评审负责人：确保评审有序进行并保持在正轨上。
记录员：负责记录所有已识别的问题。这并不意味着他们是会议记录员。记录员是在会议上记录会议发现的人。

在评审之前，所有参与评审的人员都需要准备。决策者创建一份希望在会议中达成的目标清单。评审负责人确保每个人都能访问待评审的软件产品。所有其他人员则负责预先评审他们收到的材料。

在实际的评审会议中，评审负责人促进所有相关方之间的对话。如果这是一个需求获取会议，评审负责人会确保客户及其产品团队正确传达需求，并引导会议朝着决策者的目标前进。在需求获取会议的情况下，这些目标很可能是获得一份用户故事列表，开发团队可以据此规划工作。

在软件技术评审中，一个人可能担任多个角色。评审的贡献者可能是参与整体讨论的人，同时也担任评审负责人的角色。有人可能既是决策者又是记录员。这完全取决于谁自愿做什么以及什么对当前情况有意义。

在软件技术评审结束时，应达成某个特定目标。例如，可能是消除歧义或对当前产品进行改进。技术评审的结果是一套针对软件产品改进的建议。

以下哪一项不应被视为软件技术评审（无论是针对需求还是代码）的结果？
A. 新的软件需求。
B. 改进的软件生产过程。
C. 提高的代码效率。
D. 为高效员工加薪。

答案是 D. 为高效员工加薪。虽然软件技术评审可能会提高对员工效率的认识，但其目标不是关注个别团队成员，而是改进整体产品。

总结 📝

本节课我们一起学习了两种关键的软件评审技术。我们首先介绍了非正式的软件走查，它是一种快速、协作的代码展示和讨论方式，主要用于早期质量改进和知识共享。接着，我们探讨了更正式的软件技术评审，它通过明确的角色（决策者、评审负责人、记录员）和结构化的流程，专注于在技术层面（如需求、设计、代码效率）系统性地识别问题和提出改进建议。掌握这些技术能帮助你在开发过程中更早、更有效地发现并解决问题，从而提升最终软件产品的质量。

009：评审技术

在本节课中，我们将要学习软件同行评审的最后一种类型——软件审查，并深入了解两种具体的评审技术：需求技术评审和需求审查。我们将探讨它们的结构、角色、流程以及如何应用它们来提升软件产品的质量。

软件审查概述

上一节我们介绍了软件走查和技术评审，本节中我们来看看最正式的同行评审类型：软件审查。软件审查，也称为正式技术评审，其核心目的是发现并修复工作产品中的缺陷。

软件审查比前两种评审类型更为正式，它包含多个明确的角色并遵循严格的结构。其主要目的是发现并修复工作产品中的缺陷，例如一份需求文档或一段代码。

审查中的角色

以下是软件审查中涉及的关键角色：

作者：创建被审查软件产品的人。
主持人：类似于技术评审中的评审负责人，负责监督整个审查过程，确保一切顺利进行。
读者：负责向审查员朗读文档，审查员随后指出文档中的缺陷。
审查员：负责审查产品并找出缺陷的人员。
记录员：负责记录会议笔记的人。

与软件技术评审类似，多个角色可以分配给同一个人。

审查的阶段

软件审查包含多个阶段，其中一些阶段可以重复，直到产品达到适当的标准。

规划阶段：在此阶段，主持人熟悉被审查的产品以及作者主要关注的领域。
概述会议：所有角色人员聚集在一起，由主持人对产品进行简要介绍。通常在此阶段结束时，审查员会拿到待审查的产品，从而启动准备阶段。
准备阶段：审查员审查产品以寻找缺陷并做笔记。完成此阶段可能需要几分钟到几天，具体取决于被审查的工作产品。
审查会议：在此会议上，读者将文档分成小块进行朗读。审查员随后对他们发现的每个块中的缺陷发表评论，记录员确保记录所有内容。作者可以提问和寻求澄清，但由于审查更为严格，不鼓励讨论。
返工阶段：审查会议后，作者根据从审查员那里收到的反馈进行必要的修改。
跟进阶段：完成修改后，进行跟进以确保更改已完成、恰当，并解决了审查会议中发现的缺陷。

我之前提到，一些审查阶段可以重复。通常被重复的阶段是返工和跟进阶段。这是因为有时在返工阶段完成的工作不足以解决审查会议中提出的缺陷。当在跟进阶段指出这一点时，作者必须返回并完成工作。

严格的完成标准

软件审查还执行严格的程序来确定每个阶段何时完成以及何时准备好进入下一阶段。例如，为了开始审查过程，可能有一个需要完成的事项清单。

这个清单可以包括：

软件走查已完成。
代码已通过所有测试用例。
每个函数都包含足够的文档。

这样做是为了帮助主持人和审查员在讨论之前妥善审查工作产品。

需求技术评审

现在，让我们讨论一种非常流行的软件审查技术：需求技术评审。需求技术评审是一个两阶段过程。第一阶段是评审，第二阶段是讨论会议。这个过程可以与多个审查员进行或进行多次。

评审阶段

在评审阶段，评审员检查由作者编写的一组需求。作者可能需要向每位评审员提供术语表和其他相关信息源。

每位评审员检查需求文档，以定位尽可能多的缺陷。这可能包括错误或遗漏，这些错误或遗漏会阻止产品执行其一项或多项任务。

每位评审员还应识别需求标准方面的高风险区域。例如，需求看起来不完整、过于僵化或过于浅薄而无法处理所有可能发生的情况。

每位评审员还应突出显示任何疑虑。例如，他们可能突出显示一种情况，即需求正确且完整，但在复杂性或可重用性方面可以改进。

问题严重性分级

然后，每位评审员应将其发现分类为严重、中等或轻微级别。

严重发现：意味着问题的修复方案不明显，需要非常仔细的进一步探索。
中等发现：意味着问题的修复方案是直接的，但需要进一步审查。
轻微发现：表明修复要么不必要，要么很明显，无需进一步审查。

讨论会议阶段

评审阶段完成后，进入过程的第二阶段：讨论会议。在这个会议中，应有评审员、作者、主持人和记录员。

主持人负责确保会议不偏离主题，并且批评以建设性的方式提出。他们确保评审不会让作者感觉受到攻击。类似 Scrum Master 主持其他会议的方式，他们也可以主持此会议。

还应有会议记录员。这个人可以与项目无关，他们只负责记录会议笔记。作者将参考这些笔记来修复已识别的问题。为会议设定时间盒是一个好主意，以使其保持在正轨上，并且不会占用评审员或作者太多时间。

在此会议中，将讨论收集到的发现并可能重新分类。尽可能减少对轻微问题的讨论是一个好主意。不期望作者回应提出的每一个问题或评论，但记录员应记下所有问题。作者在场主要是为了更好地理解发现并在需要时寻求澄清，这将有助于将会议控制在既定的时间盒内。

修复过程

遵循需求技术评审过程之后是修复过程。在修复过程中，需求作者将根据评审的反馈对需求进行调整。他们不需要解决所有建议的更改，因为提出的一些问题可能无效或已经解决。

需求审查

在我们结束之前，让我们谈谈需求审查。需求审查是一个正式过程，其中审查用户故事列表的模糊性、一致性和完整性。

模糊性是软件需求的一个大问题，通常让第三方审查你的需求以确保一切清晰是很有用的。当需求的所有问题都被识别出来后，就由作者来修复它们。

通常作者是产品负责人或软件产品经理，也可能包括开发团队的成员。有时作者是客户。在所有这些情况下，在审查会议中提出的缺陷随后得到解决，并在跟进中再次呈现。

需求审查是确保你的需求清晰、一致和完整的有用方法。审查过程使任务直接且易于理解，这可能是它在行业中流行的原因。

总结

本节课中我们一起学习了软件审查的正式流程、角色和阶段，并深入探讨了两种具体的评审技术：需求技术评审和需求审查。我们了解到，无论上下文如何，软件同行评审都是有用的。无论是非正式的走查、技术评审还是正式的审查，评审在几乎所有软件项目中都有一席之地。

现在我已经介绍了一些如何评审软件的技术，接下来让我们谈谈软件评审过程中一些常见的问题。这就是我将在下一课中要讲的内容。

010：监控问题 🔍

概述

在本节中，我们将探讨软件项目中监控环节的常见问题。我们将分析为何某些度量指标可能不适用于软件开发，以及如何避免使用不良指标。理解这些问题有助于我们更明智地选择和应用度量方法，从而有效提升软件产品的质量与开发效率。

上一节我们介绍了软件开发中使用的几种同行评审技术。现在，让我们退一步，讨论监控项目时可能遇到的一些问题。

例如，为何应避免使用某些度量指标？以及哪些指标对软件项目是有害的？

你刚刚看到，监控可以通过同行评审（如代码走查）来实现。但正如本课程标题所示，这并非监控的唯一方式。

软件中有许多度量指标可用于跟踪进度、生产力和质量。速度（Velocity） 就是其中之一。

我在上一门课程中简要介绍了如何估算速度，Morgan 将在下一个模块中深入讲解如何计算和跟踪它。

实际上存在很多度量指标，它们各自评估项目的不同方面。然而，在许多软件项目中，这些指标根本未被使用。这是为什么呢？

大多数时候，问题在于难以找到合适的时间来正确编制这些指标。

正如我在关于反模式以及软件项目敏捷规划的课程中所说，开发人员实际用于编码的时间是有限的。

这意味着开发人员花在任何非编码任务（例如编制指标）上的时间，都会占用他们用于编码的总时间。

为了最大化开发团队在产品创建上的进展，通常首先被省略的就是度量指标。团队构建了一个可靠的产品，早期并迭代地交付给客户，每个人都很满意。

然而，除了那些希望退一步定量分析项目、以便及时发现和妥善解决问题的人。

那么，他们为何不愿意这样做呢？为了进行跨项目比较，采用更行业标准的测量实践难道不合理吗？

这个问题并不容易解决，尤其是在一个专注于快速高效开发的敏捷框架中，很容易理解为何度量指标会被搁置一旁。在一个项目成功取决于当下能完成多少工作的范式中，很难看到计算指标的价值。

或许度量指标最大的问题之一是，开发人员和管理者在这方面知识显著缺乏。

外界有很多例子，很难判断哪些指标值得你投入时间去计算。

这一点，加上缺乏行业标准，确实让决策变得困难。有些人说要跟踪这个，另一些人说要跟踪那个。该领域的研究往往没有定论或无法推广。它们可能只适用于特定环境或特定组织。最终，每个组织都必须确定什么适合他们的情况。

你能明白为何行业标准如此之少吗？

以下是我提到的软件项目中度量指标未被正确使用的主要原因之一：
A. 资金不足。
B. 可选择的指标太多。
C. 缺乏开发人员或管理者的知识。
D. 缺乏开发人员或管理者的兴趣。

答案是 C，缺乏开发人员和管理者的知识。

通常，被指派管理软件项目的人员在衡量质量方面没有接受过实质性培训；因此，项目指标要么被误用，要么根本不被使用，这很常见。

行业中一个相对常见的指标是代码行数（Lines of Code，简称 LOC）。基本上，代码行数跟踪为一段软件编写的代码行数，并使用该数字生成一些数据。

这些数据可能包括：

每行代码的成本：通过将整个项目的成本除以编写的代码行数来计算。
单位时间内编写的代码行数：一种技术速度的测量。

虽然将代码行数作为生产力的衡量标准似乎有道理，但事实并非如此。

首先，这个指标不可靠。你在项目某一部分获得的代码行数指标，可能与另一部分获得的指标大相径庭，即使在同一团队内也是如此。

这有几个原因：

开发人员编写的代码行数很大程度上取决于他们使用的编程语言。如果你熟悉各种语言，你会知道 C 是一种非常低级的语言，需要编写多得多的显式内容才能实现与 Python 这样的高级编程语言相同的高级功能。因此，粗略来说，实现相同功能，Python 程序的代码行数可能比 C 程序少五倍。对于不同语言的不同程序，代码行数的度量之间没有真正的可比性。
事实上，即使使用同一种语言，代码行数也很难显示产品内部的生产力。这是因为不同的功能可能具有不同的复杂性。如果不考虑这一点，你可能会在不该比较的地方进行比较。

这个例子显示了了解为何要进行测量的重要性。

代码行数的度量本身就是一个问题，但伴随这种测量往往会产生一个有趣的副作用：开发人员的行为会改变。每当有人获得一个可以衡量自己的分数时，他们的自然倾向就是最大化这个分数。考虑到这一点，你能想到代码行数指标的另一个问题吗？

如果开发人员根据他们编写的代码行数来衡量，他们的自然倾向很可能会比不编制该指标时编写更多的代码行数。这种非预期的后果起初可能不是坏事，但如果你的开发人员花更多时间编写这些代码行，生产力很容易下降。

了解你在测量什么很重要。这不是关于收集所有你能收集的数据并进行分析。你必须能够评估你在所提供指标的价值与编制它们所需时间（以及这些指标的其他相关成本）之间所做的权衡。正如社会学家威廉·布鲁斯·卡梅伦所说：“并非所有可计数的东西都重要，也并非所有重要的东西都可计数。”

以下哪项使得“每个冲刺的代码行数”成为评估软件生产力的不良指标？
A. 代码行数是衡量已完成工作量的不良指标。
B. 冲刺是衡量项目长度的不良指标。
C. 代码大小无法用代码行数衡量。
D. 每个冲刺的代码行数是评估软件生产力的良好指标。
E. 所有语言中，不同功能的代码行数是相同的。

答案是 A，代码行数是衡量项目规模的不良指标。正如我之前所说，代码行数在不同项目之间可能差异巨大，并不能真正反映开发人员的努力。

评审和度量指标存在问题，但这并不会降低它们的价值。事实上，行业中确实需要更多的评审和度量。问题的存在意味着有很大的研究空间。为了改进软件产品和流程，在决定实施任何度量时，保持明智和知情非常重要。

总结

本节课我们一起学习了软件项目监控中度量指标的应用挑战。我们了解到，由于时间限制、知识缺乏以及指标本身的缺陷（如代码行数指标的不准确性和行为误导性），许多指标未被有效使用。关键在于理解测量目的，并明智地权衡指标价值与收集成本。在下一课中，我将介绍一个帮助你做出明智决策的模型——目标-问题-指标模型。

软件产品管理课程5：5.2.3：目标问题度量GQM 🎯

概述

在本节中，我们将学习一种名为“目标问题度量”的方法，它能帮助我们为软件项目制定有效的度量指标，确保这些指标能准确衡量对项目和团队有价值的方面。

在上一节中，我们讨论了监控软件项目时可能遇到的一些问题，这些问题主要围绕度量指标的有效性及其可能被误用的情况。本节中，我们将探讨一种制定度量指标的方法，以确保它们能衡量对您和团队有价值的项目方面。这种方法被称为“目标问题度量”。

目标问题度量，简称GQM，是一种为软件项目选择度量指标的方法，由马里兰大学的维克多·巴希利于1994年提出。根据巴希利本人的观点，GQM背后的核心理念是：一个组织要有目的地进行度量，必须首先为其自身及其项目设定目标，然后将这些目标追溯到用于操作性定义这些目标的数据，最后提供一个框架，根据既定目标来解释这些数据。

简单来说，为了确保为项目使用了正确的度量指标，您必须首先明确想要衡量的概念，即您的目标。明确目标后，您需要找出定义该目标的内容，即您的问题。接着，您需要找到一种方法来计算这个定义，以便解释数据并了解实现目标的进展，这就是您的度量指标。

首先，如何设定目标？根据巴希利的观点，目标应用于对象，这些对象包括产品、过程和资源。本质上，您可以选择改进这三者之一作为目标。例如，改进您的产品（如代码或文档），改进您的流程（如测试或需求获取流程），或者改进您的资源（如办公空间、开发团队使用的计算机或开发人员的投入与薪酬）。核心思想是您可以度量任何事物，但将项目目标分解为这三个类别有助于您思考如何度量它们。

小测验：GQM的目的是什么？
A. 确保您正在构建正确的产品。
B. 确保您有效地使用度量指标。
C. 确保度量指标使用正确的数据。
D. 确保您向客户提出正确的问题。

答案：B。GQM是一个使用度量指标的框架，其重点是确保您使用最佳度量指标来回答关于项目的关键问题。

设定每个目标后，接下来需要考虑的是针对这些目标提出的问题。本质上，您需要提出哪些问题才能判断每个目标是否正在实现？这取决于具体目标，但总体思路是您的问题应足够具体，以便问题的答案能够直接对应目标。

那么，如何找到答案呢？这就是度量部分的作用。度量是一种定量方式，用于收集数据以回答您提出的问题。这与我们在之前课程中讨论的其他度量指标完全相同。GQM中度量指标的特殊之处在于，它们通过事先的规划过程而变得更有意义。因为度量指标旨在回答的问题已经过事先深思熟虑，所以它们在GQM中变得更有价值。

度量指标可以是主观的或客观的。客观度量基于不依赖任何个人观点或解释的数据，例如产品下载次数、销售数字、处理时间或完成的用户故事。主观度量则依赖于解释，例如用户的产品评分、开发人员的士气或代码质量。

如果将度量比作软件，这很像我们在“客户需求与软件需求”课程中讨论的“收集需求”与“引导需求”的区别。您不希望盲目地开始收集度量指标。就像从客户那里引导需求很重要一样，事先明确度量指标的目标也同样重要。当然，一旦有了用户故事，您也不会直接开始构建它们，而是首先创建开发任务——那些可以在几小时内完成的小型、可操作项。GQM中的问题也是如此：您创建小的项目，当它们组合在一起时，就能解决整个目标。只有在您通过发布和迭代计划提前规划好工作后，才会进入代码开发阶段。同样，只有在您通过具体问题提前定义了度量指标的目标后，才会真正开始实施度量并收集数据。

小测验：GQM代表什么？
A. 目标问题测量
B. 收益问题测量
C. 目标问题度量
D. 收益问题度量

答案：C，目标问题度量。

让我们看一个GQM的示例。假设您正在开发一个软件产品，并且想知道您的产品是否“做得正确”。那么，产品质量就是您的目标。以下是一些可以帮助您解决这个目标的问题：

我的产品代码有多少被单元测试覆盖？
我的产品中存在多少缺陷？

提出这些问题后，下一步就是确定您的度量指标。如果我们以“我的产品中存在多少缺陷？”这个问题为例，我们可以通过几种方式来处理。一种度量指标可以是：在最终被接受之前，用户故事在验收测试中被拒绝的次数。这可以表示为整个项目中拒绝次数与接受次数的百分比。您可以认为，较高的拒绝与接受比率表明您的流程中某些环节需要改变以减少缺陷。要知道什么是“高比率”，您可能需要比较在成功项目与不成功项目中这个数字的差异。

另一个解决此问题的度量指标是：在任何给定时间，产品待办事项列表中存在的错误数量。如果您发现待办事项列表中的错误激增，这可能表明您需要审查技术，以便更早地发现缺陷。当然，您可以制定比这复杂得多的度量方案。这里的想法只是让您了解度量指标如何在GQM范式中应用。

总结

本节课我们一起学习了目标问题度量方法。我们了解到，GQM通过引导我们首先明确目标，然后提出具体的问题，最后制定可量化的度量指标，从而确保我们为软件项目选择和使用的度量是有效且有目的的。这种方法有助于将度量与项目的实际改进目标紧密结合起来，避免度量的盲目性和误用。

012：好的度量属性 📊

在本节课中，我们将学习软件度量的核心概念，并探讨一个好的度量应具备哪些关键属性。我们将从定义基本术语开始，然后分析一个“坏”度量与一个“好”度量的例子，帮助你理解如何选择和使用有价值的度量。

关键术语定义

为了整体理解软件度量，首先必须掌握三个关键术语：度量项、度量和指标。

度量项：一个测量标准或单位。它本质上是测量的一个实例。例如，“英寸”就是一个度量项，因为英寸是一个标准的测量单位。这意味着将一英寸与另一英寸进行比较时，它们是完全相同的。确保测量的一致性对于获得有意义的度量至关重要。
度量：两个或更多度量项的组合，能产生有意义的结果。一个例子是“公里每小时”。公里是你的第一个度量项，小时是第二个。当它们结合时，就创造了有意义的东西。然而，并非所有度量都有意义。
指标：能引起测量者注意的度量。一个好的例子是测量某人的口腔温度。一个人健康状况良好的指标是其口腔温度在36.5至37摄氏度之间。如果你测量某人的口腔温度读数为38度，这就是他们发烧的指标。没有这些值作为指标，仅凭温度你无法判断某人是否发烧。指标让你更容易知道你的度量项或度量何时在告诉你一些需要注意的事情。

小测验：39摄氏度每小时，是度量项、度量还是指标？

A. 度量项
B. 度量
C. 指标

答案：B，它是一个度量。39摄氏度和小时都是度量项，但当它们结合时，就创造了一个度量。

现在你知道了度量项、度量和指标之间的区别。收集和分析数据以洞察你的产品是一项常见任务。正如在上节关于GQM的课程中所说，你不应该在没有明确目标的情况下使用度量。同样重要的是，你要使用一个你知道能提供可信结果的度量。这就是为什么了解度量的理想品质很重要。

什么是“坏”的度量？

让我们回到测量开发人员每小时击键次数的例子。是什么让这个度量在软件项目中如此糟糕？

首先，击键次数与软件创建有什么关系？有人可能会争辩说，跟踪开发人员的击键次数可以让他们跟踪在任何一天写了多少代码。然而，就像代码行数度量会因编程语言和开发人员而有很大差异一样，这种击键方法也是如此。这本身就是一个问题。

再考虑如何记录击键。例如，如果你在电脑上使用击键记录程序，你怎么知道记录的击键实际上是在写代码？你的开发人员可能在做其他事情，比如在在线聊天论坛上打字，或者写他们过去两年一直试图完成的小说。

重要的是选择正确的度量，而其中一部分意味着选择一个能真正回答你想问的问题的度量。

度量的理想属性

那么，度量应具备哪些理想属性呢？一个好的度量应该：简单易计算、直观有说服力、客观、单位使用一致、与编程语言无关，并能提供改进软件质量的有效机制。

以下是每个属性的详细说明：

简单易计算：主要原因在于，度量越复杂，使用它的人犯错误的可能性就越大。如果你使用的度量过于复杂，一个在简单公式中很容易识别的小错误，当你意识到有问题时，可能会变成追踪的噩梦。
直观有说服力：如果你计算了一个度量，把它拿给你团队中的某个人看，并让他们告诉你它意味着什么，它应该对他们有意义。这并不是说你只应该使用简单的度量，但它应该具有直观意义。每小时击键次数度量就是一个很好的反面例子，你可以计算它并向任何人说明，但归根结底，跟踪开发人员的击键次数并没有多少直观意义。
客观：这意味着它们不依赖于任何人的意见，而是基于经验数据。这对任何科学都至关重要，监控项目的科学也不例外。一个反面例子是使用开发人员对自己生产力的估计来跟踪开发人员生产力。很难从中获得准确的客观度量，因为你的数据来源本身就有偏见。一个更好的方法是测量他们在给定时间内完成了多少工作，例如使用故事点。
单位使用一致：如果你使用故事点作为项目速度的度量，那么你需要对故事点的定义保持一致。如果你在项目中途将某些用户故事的故事点估计值翻倍，你将无法从速度度量中获得太多信息。保持你所测量事物的定义稳定一致非常重要。否则，你处理的度量可能难以解释，甚至完全无法使用。此外，你还要确保比较的单位是一致的。例如，你不会在度量中将故事点与小时相加。

小测验：以下哪项是度量的理想属性？

A. 基于主观数据
B. 适用于人力资源问题
C. 对任何数据给出相同的数字
D. 直观

正确答案是D，一个度量应该是直观的。如果它不直观，你使用的度量可能不会对改进有多大帮助。

与编程语言无关：正如前面以及前一课所说，代码行数度量是一个很好的反面例子。虽然它似乎是衡量软件项目完成工作量的直观度量，但实际上这个度量相当具有误导性。更重要的是，不同的编程语言实现特定功能所需的代码行数差异很大。为了保持一致性，你的度量应该能够提供一个可靠的测量，可以在不同编程语言之间进行比较。
提供改进能力：你不是为了跟踪数字而跟踪数字。你需要做的是为了改进项目而跟踪数字。如果你改进了你的项目，你的度量能够显示这些改进吗？以开发人员每小时击键次数为例，如果你试图通过让开发人员击键更多来改进项目，你认为会发生什么？更糟糕的是，如果你的开发人员实际上是更高效的程序员，他们击键的次数可能会减少，因为编写代码所需的字符远少于用自然语言写东西。最好使用一个能在取得进展时显示进展的度量。重要的是，一个好的度量也应该能够显示你所测量事物的质量是否在下降。

一个“好”度量的例子

一个好的度量例子是每周在产品中发现的缺陷数量。

为了计算这个度量，你只需要跟踪以错误报告或记录问题形式报告的新缺陷数量，并在每周结束时制成表格。

计算简单易行：每周缺陷数 = 本周新报告的缺陷总数
直观有说服力：缺陷在任何软件项目中显然都是坏事，减少产品中的缺陷数量是人们公认的理想目标。
客观：如果记录了一个新缺陷，那就是一个新缺陷。除非开发人员完全忽略问题，否则无法伪造。
单位一致且与语言无关：假设你的开发人员编写不同编程语言的技能相当，每周发现的缺陷数量在不同编程语言之间将保持相当一致，并且缺陷的定义不会改变。
提供改进能力：如果你随时间跟踪这个度量，并实施允许你增加修复缺陷数量或提高代码质量的流程，你每周观察到的缺陷数量应该会随着时间的推移而减少。通过跟踪这个度量，你的代码质量会得到改善。

小测验：以下哪项不被认为是度量的理想属性？

A. 提高你的产品或流程的质量
B. 与编程语言无关
C. 维度使用一致
D. 减少完成项目所需的小时数

答案是D。虽然如果你的度量能帮助你减少完成项目所需的小时数会很棒，但这并不是所有度量普遍具备的理想属性。提高产品或流程的质量是度量的目标，但这本身不是度量的属性。

跟踪每周发现的缺陷数量的另一个优点是，它不必只应用于整个产品。你可以分解这个度量来分析产品的不同部分。通过这样做，你可以识别项目中的任何问题区域并专注于它们。

另外需要提到的是，度量并不总是绝对的。有时你最终会得到只对你的项目有用的度量，因为它们所基于的值是相对的。基于故事点的速度就是一个很好的例子。故事点的定义因项目而异。使用基于相对值的度量是可以的，重要的是要认识到你的度量项何时是相对的，这样你就不会犯错误去尝试比较两个基于略有不同度量项的度量。

总结

本节课我们一起学习了软件度量的理想属性。最重要的收获是有意识地使用度量。确保你使用的度量是恰当且有意义的，这样你就不会出错。

在下一节课中，我将介绍一些用于评估产品和流程的度量。你将学习一些可靠的现实世界度量，请不要错过。

013：其他度量

概述

在本节中，我们将学习如何运用度量来评估软件产品在非功能性需求方面的表现。我们将探讨可维护性、性能、可靠性和产品成功等关键领域的度量方法。

在上一节中，我们介绍了度量的一般理想属性，并区分了度量、测量和指标。本节中，我们来看看如何基于非功能性需求来评估你的产品和项目。

在关于GQM的课程中，我们讨论了为度量设定目标。现在，我们来谈谈其中一些具体目标。你可能希望度量可维护性、性能、可靠性或产品成功。

度量可维护性

要度量可维护性，可以使用复杂度度量。复杂度度量衡量的是产品源代码的复杂程度。这通常通过源代码中逻辑分支的数量来体现。简单来说，逻辑分支数量越多，项目的复杂度就越高。复杂度更高的软件更难以维护。因此，如果你的代码过于复杂，你可能需要考虑降低复杂度以提高产品的可维护性。

度量性能

你也可以评估产品的性能。为此，可以使用诸如响应时间这样的度量。响应时间是一个描述任务开始执行后需要多长时间才能完成的度量。例如，如果你的应用程序在服务器执行请求后需要三秒钟来显示数据，那么你的响应时间就是三秒。你可以对多次执行进行平均，以获得平均响应时间。

度量可靠性

可靠性同样可以被度量。要衡量产品的可靠性，可以使用诸如产品正常运行时间这样的测量。正常运行时间衡量的是产品能够启动并可供用户使用的时长。正常运行时间通常以百分比表示。例如，数据库的标准正常运行时间通常在99%以上。这意味着数据库在超过99%的时间内都可以接收和发送信息，这是一个相当好的水平。

度量产品成功

最后，还有产品成功度量。这些度量在本课程前面已经讨论过，例如客户满意度。客户满意度可以通过从用户那里获取五分制评分，然后对所有用户的评分进行平均来计算。你也可以衡量产品的正确性，但这更多属于功能性需求。衡量产品正确性的最佳方法是通过缺陷分析，这将是下一节要讨论的内容。

总结

本节课中，我们一起学习了如何运用不同的度量来评估软件产品的非功能性需求。我们了解了如何通过复杂度度量评估可维护性，通过响应时间评估性能，通过正常运行时间评估可靠性，以及通过客户满意度等指标评估产品成功。掌握这些度量方法，有助于你更全面地管理和改进软件产品。

问题：在软件项目中，通常使用度量来衡量的三个类别是什么？
A. GQM
B. 可维护性
C. 可访问性
D. 可靠性
E. 性能

答案：B, D, E。可维护性、可靠性和性能都是在软件项目中经常被衡量的方面。

014：缺陷分析

在本节课中，我们将要学习一个在行业中非常有用且常用的工具：缺陷分析。这是一种评估产品质量的方法。

概述

缺陷分析，顾名思义，用于分析产品中的错误数量。错误是指产品中出现的故障。这通常可以追溯到源代码，但并非总是如此。

缺陷分析的基本方法

进行缺陷分析的一种方法是跟踪代码中的缺陷数量，并将其与已修复的缺陷数量进行比较。

正如前几节课所说，您可以通过统计系统中所有已报告的错误来找到代码中的缺陷数量。理想情况下，这可以来自一组特定的内部软件测试人员，以确保系统发布时不带太多错误。然而，这些数字也可能来自产品发布后的最终用户。

市面上有许多工具可以帮助您跟踪产品的漏洞、问题和错误。使用这些工具时，也容易跟踪这些问题的解决进度，例如是否已修复，以及对其所做的任何更新。您还可以随时间比较这些数字。

缺陷发现率与修复率

如果您跟踪每周发现的漏洞数量与每周修复的漏洞数量，并随时间绘制这个趋势，您可以看到在开发新功能之前，是否应该投入更多精力来修复当前的问题。这被称为缺陷发现率与缺陷修复率。

如果每周发现的漏洞数量远远超过每周修复的漏洞数量，那么投入时间修复这些问题可能是个好主意。

作为一个满足所有理想度量属性的指标，这个指标也允许您跟踪进度。如果您专注于修复缺陷，那么您最终会看到每周修复的缺陷数量上升。

通过随时间跟踪缺陷发现率与缺陷修复率，您可以了解产品内部质量的变化情况。希望随着项目的推进，您修复的缺陷会多于发现的缺陷，产品中遗留的缺陷会越来越少。

然而，如果您修复的缺陷数量与发现的缺陷数量相当，那么您就遇到了所谓的软件障碍。正如之前所说，这可能是时候做出改变了。遇到软件障碍表明您的产品尚未准备好发布，您应该在发布前投入更多时间修复漏洞。

以下是关于缺陷分析的一个小测试：

缺陷分析是评估您产品____的一种方式。
A. 生产力 B. 规模 C. 用户满意度 D. 质量
答案是 D，质量。

缺陷分析主要是为了了解项目在质量方面的当前状态。

子系统缺陷分析

您还可以将已修复的缺陷按产品的不同组成部分（称为子系统）进行划分。本质上，要了解各子系统的缺陷，您只需跟踪与每个已修复缺陷相关联的子系统。

然后，您可以统计每个子系统的已修复缺陷数量，以查看产品中需要关注的区域。为了公平比较，这个数字应该除以每个子系统的规模。大的子系统自然会有更多缺陷，这就引出了缺陷密度的概念。

缺陷密度

缺陷密度是确定整个产品缺陷数量的标准方法。

要计算缺陷密度，只需取代码中发现的缺陷数量与代码规模的比率。规模可以用千行代码来衡量。对于结构化编程技术，行业平均水平大约是每千行代码15到50个缺陷。

您可以使用这个指标对项目的发布准备情况做出一些有趣的预测。

示例：假设您正在构建一个软件产品，并与团队一起进行第三次发布。

第一个版本在发布前发现了900个缺陷，发布后发现了100个缺陷。代码量为10万行。这使得您第一个发布版本的缺陷密度为 每千行代码10个缺陷。
在第二个发布中，您的团队增加了5万行代码，发布前发现了400个缺陷，发布后发现了45个缺陷。这使得第二个版本的增量代码缺陷密度为 每千行代码8.9个缺陷。
现在您计划发布第三个版本。您的团队新增了10万行代码，目前在这部分代码中发现了600个缺陷。这使得该增量代码的缺陷密度为 每千行代码6个缺陷。

考虑到前两个已发布版本的增量缺陷密度在每千行代码8.9到10个缺陷之间，这次您的产品准备好发布了吗？

答案是否定的。除非自第二个版本以来您的开发流程有所改进，否则您可以预期在第三个增量中，每千行代码会发现8.9到10个缺陷。对于10万行代码，大约是890到1000个缺陷。在之前的发布中，您在发布前发现并修复了90%的缺陷。这意味着您可以预期在这个发布中，每千行代码会发现801到900个缺陷。既然目前只发现了600个，您可以预期在发布前还会发现201到300个缺陷。在产品发布前发现缺陷总是更好的，因此您的产品可能还不适合发布。

以下是另一个小测试：

一个软件项目有10万行代码，发布前识别出640个漏洞，发布后识别出211个漏洞，其发布前缺陷密度是多少？
A. 每千行代码2.1个缺陷
B. 每千行代码6.4个缺陷
C. 每千行代码7.51个缺陷
D. 每行代码0.00751个缺陷
答案是 B，每千行代码6.4个缺陷。记住，这里我们只计算发布前的缺陷。

缺陷分析实战案例：航天飞机飞行软件

让我们看一个缺陷分析的实际案例。航天飞机飞行软件以其几乎无错误而享有最佳声誉之一——它必须如此，否则可能导致人员伤亡和数十亿美元的损失。

那么，编写该软件的机载航天飞机小组是如何实现这种完美水平的呢？对他们来说，仅仅发现一个缺陷、修复它，然后收工是不够的。当发现一个缺陷时，存在强制性的协议来分析该缺陷，识别该缺陷可能出现的其他类似区域，并调整流程以避免未来出现此类缺陷。

示例：航天飞机有一个著名的加拿大组件，称为Canadarm，这是一个在恶劣太空环境中协助完成复杂任务的机械臂。如果在Canadarm手腕旋转的方式中发现一个漏洞，那么也可以检查其他涉及硬件旋转的代码是否存在类似错误。因此，通过缺陷分析，可以在一个完全独立的、用于旋转通信天线的子系统上发现类似的漏洞，从而避免潜在的灾难。

事实上，这正是航天飞机软件发生过的真实场景，它帮助节省了大量的工作、时间和金钱。通过实施这种严格的测试和修订程序，机载航天飞机小组能够在其运行软件方面达到完美的状态。如果您想了解更多关于他们流程的信息，请查看课程笔记中的资源。

总结

以上就是缺陷分析。它是一种简单的技术，可以帮助您确保了解项目的质量，并就其测试和发布做出正确的决策。

这也是本模块的结尾。我们在本模块中涵盖了很多内容，让我们回顾一下：

首先，我们讨论了一些软件产品的评审技术，如代码走查和需求技术评审。
然后，我们讨论了监控软件项目时的一些常见问题，并指出了一些常用但价值不高的度量指标。
之后，我们介绍了目标-问题-度量（GQM）框架，以及实施它如何帮助您确保在项目中使用适当的度量指标。
接着，我们探讨了度量指标的理想属性，了解了什么构成了一个好的度量指标。
之后，我们讨论了当今行业中一些流行的度量指标。
最后，我们深入学习了缺陷分析。

这些活动有助于确保产品通过经过评审和度量的工作正确完成。在下一个模块中，Morgan将通过与您讨论每日站会、回顾速率以及向您展示燃尽图是什么，来告诉您如何确保项目得到正确管理。请继续学习。

015：每日站立会议 🎯

在本节中，我们将学习如何通过每日站立会议来确保产品开发过程得到有效管理。我们将了解会议的目的、结构、参与规则以及如何高效地运行它，以保持项目按计划进行并维持可持续的开发节奏。

概述

每日站立会议，通常称为每日Scrum或站会，是敏捷开发中用于同步团队工作、识别障碍并保持项目进度的关键实践。本节将详细介绍其运作方式、核心规则以及常见误区。

会议目的与结构

每日站立会议的核心目标是同步开发团队的工作，并为新的一天设定正确的方向。它不是一个向管理层汇报的状态会议，而是团队内部的协调会议。

会议结构非常简单，每位核心参与者需要依次回答三个问题：

昨天完成了什么？
今天计划做什么？
遇到了什么障碍？

参与者角色：“猪”与“鸡”

为了确保会议高效，需要明确参与者的角色。这里引用一个经典比喻来区分：

一只鸡和一头猪在聊天。鸡建议：“嘿，猪，我们一起开家餐厅吧。”猪同意了：“好主意，鸡。但我们该叫它什么呢？”鸡建议：“叫‘火腿蛋’怎么样？”猪回答：“不了，谢谢。那样我是全身心投入，而你只是参与其中。”

在每日站会中：

“猪”：指对项目有实质性承诺、必须发言的人。通常是开发团队成员，以及有重要更新需要同步的产品负责人。
“鸡”：指可以旁听但不应发言的人。可能包括其他团队的开发者、想了解状态的高管，或没有重要更新的产品负责人。

会议内容：什么该说，什么不该说

以下是你在站会中更新内容时应该遵循的原则。你的发言应严格围绕三个核心问题。

正确的更新内容应包括：

A. 昨天，你完成了数据库结构的设计。
C. 今天，你将要开始设计用户界面。
D. 储藏室没纸了，导致你无法绘制用户界面的草图（这是一个障碍）。

不应在站会中提及的内容有：

B. 昨天，你下班后看了一部很酷的电影（与工作无关）。
E. 我对产品有一个功能改进建议（站会不是讨论未来改进的场合）。

会议实践与流程

上一节我们明确了会议内容，本节中我们来看看会议的具体执行流程和最佳实践。

会议通常按以下步骤进行：

开始：所有人在无障碍的圆圈中站立，不携带笔记本电脑或手机。
轮流发言：每位“猪”依次回答三个问题。一个典型的更新可能是：“大家好。昨天我完成了用户个人资料页的所有单元测试。今天我将开始编写该功能的源代码。我目前的障碍是对这个编程语言不太熟悉，今天有人愿意和我结对编程这个功能吗？”
视觉辅助：会议通常在任务板或看板前进行，以便团队在需要时移动任务状态。
时间盒：会议严格限时15分钟。
处理跑题：如果对话偏离三个问题，Scrum Master应中断讨论，并将其加入“停车场”列表，邀请相关人员在会后讨论。
记录障碍：Scrum Master负责记录会议上未直接解决的障碍，并确保后续有人处理。
明确结束：会议结束时应有明确的信号（如团队口号），避免大家尴尬地不知是否散会。

场景应对：如何处理未完成的承诺

每日站会旨在建立开放的沟通渠道，而非问责攻击。当团队成员未能完成昨日承诺时，应以协作精神应对。

假设在站会中，开发者Danny昨天承诺完成登录功能的源代码，但今天他表示昨天已着手处理并计划今天完成，且没有提及任何障碍。

正确的做法是：

B. 礼貌地询问Danny为何未能完成，并询问团队是否可以提供帮助（例如建议结对编程）。

不恰当的做法包括：

A. 对他发火。
C. 什么都不做。
D. 指派其他人完成该功能。

场景应对：如何处理跑题讨论

作为Scrum Master，维护会议纪律和效率是你的职责。当会议中出现跑题讨论时，你需要果断干预。

假设会议进行顺利，仅用时10分钟，最后一位开发者的更新引发了大家的跑题讨论。

此时你应该：

D. 中断讨论，将其加入待议事项列表，并建议任何想继续讨论的人可以在会后进行。

其他选项均不合适：

A. 让讨论继续，因为会议还有时间。（这会养成坏习惯）
B. 让讨论继续，并允许超时。（违反了时间盒规则）
C. 中断讨论并直接散会。（不利于团队开放沟通）

总结

本节课中我们一起学习了每日站立会议。我们了解到它是一个简短的、面向开发团队的同步会议，核心是回答三个问题。我们明确了“猪”和“鸡”的角色区别，以确保会议高效。同时，我们掌握了会议的标准流程、Scrum Master维护会议纪律的方法，以及如何以协作而非问责的方式处理未完成的承诺。正确实施每日站会能有效保持团队同步，及时发现障碍，并维持积极的工作节奏。

软件产品管理课程5：软件改进的评审与度量：第5.3.1a节每日站立会议挑战 🚀

概述

在本节中，我们将探讨每日站立会议（Daily Scrum）可能遇到的常见问题及其解决方案。每日站立会议是敏捷开发中的核心实践，旨在促进团队同步和协作。然而，如果实施不当，它可能变得低效甚至无效。我们将逐一分析这些问题，并提供具体的改进技巧。

问题一：无人开始会议或发言顺序混乱

你的团队可能面临无人愿意开始每日站立会议，或者不清楚发言顺序的问题。团队常常依赖Scrum Master来主持会议。虽然Scrum Master可以宣布会议开始，但他们不应总是负责引导会议。Scrum Master应尽可能避免主导会议，否则会议会显得像状态汇报，而非团队同步会议。

以下是解决此问题的几种技巧：

最后到者先发言规则：最后加入会议的人必须首先发言。这能鼓励守时，但最后到的人通常准备最不充分，因此效果可能有限。
传递令牌法：使用一个令牌（如球、毛绒玩具或办公用品）在团队中传递。拿到令牌的人发言，发言完毕后将令牌抛给下一个人。这增加了趣味性，促使参与者保持专注，并明确了发言顺序。
轮询法：由一人自愿开始，然后按顺序（如顺时针或逆时针）让每个人进行更新，直到所有成员发言完毕。

场景练习：你的Scrum团队总是迟到参加每日站立会议，且人到齐后无人愿意开始。应采用哪种技巧使会议更有效？
A. 最后到者先发言
B. 传递令牌
C. 轮询法

答案与解析：实施“最后到者先发言”规则既能鼓励团队守时，也能强制某人开始会议。因此，A是正确答案。

问题二：会议经常超时

每日站立会议的一个常见问题是经常超过15分钟的时间盒限制。我们已经知道，确保只有核心开发成员（“猪”）发言，并将离题讨论留到会后，有助于缩短会议时间。

如果会议仍然超时，可以尝试以下附加技巧：

保持站立：如果会议围绕舒适的会议桌进行，人们容易拖延。要求团队全程站立，不适感会促使他们希望尽快结束会议。
使用小型计时器：将15分钟的时间盒平均分配给每个人。当时间快用完时，正在发言的人会知道需要快速总结。
使用“重物令牌”：结合之前提到的传递令牌法，但使用较重的物品（如健身球）。这会激励发言者想尽快传递它。如果效果不佳，可要求他们伸直手臂持球，这会进一步增加尽快结束发言的动力。

问题三：无人提出障碍

可能你的团队没有遇到任何阻碍，但这并不常见。如果无人提出障碍，但团队却持续错过截止日期，这就亮起了红灯。

你可以通过以下方式鼓励提出障碍：

以身作则：在你自己的更新中包含小障碍，让团队知道鼓励提出任何规模的障碍。
主动提问：用诸如“我或团队能做些什么让你今天的工作更轻松吗？”这样的问题来提示他们。

问题四：并非所有成员都在上午到场

在实行弹性工作制的办公室中，团队成员可能无法都在上午到场。在这种情况下，应将会议安排在所有人都会在场的时间。

需要注意的是，如果将会议安排在上午较晚时，通常高效的工作时间在会议前就无法开展。晚开会议通常意味着晚开始一天的工作，并损失高效工时。

最有效的方法是在一天开始时举行会议。如果不可能，则安排在午饭后或一天中稍晚的另一个时间，使会议不与一天的开始直接关联。

场景练习：你的办公室实行弹性工作制。两名开发人员通常在早上10点送孩子上学后到岗。一名开发人员喜欢早开始，每天早晨7点准时到办公室。最后一名开发人员喜欢中午左右到岗并工作到很晚。安排每日站立会议的最有效时间是什么？
A. 上午10点，然后向最后一名开发人员同步会议内容。
B. 午饭后，当所有开发人员都在场时。
C. 完全不举行每日站立会议，因为上午没有适合所有人的时间。

答案与解析：你需要确保整个Scrum团队都出席会议，因此上午10点无效。在一天中稍晚举行每日站立会议比完全不举行更有效。因此，B是正确答案。午饭后举行会议能鼓励高效的下半天工作，并且与一天开始的时间足够远，团队成员不会将会议与工作日的开始联系起来。

问题五：会议感觉像状态汇报会

如果团队是在向Scrum Master或产品负责人汇报，而不是向其他开发团队成员同步，那么这代表着一个状态汇报会，而非同步会议。

为纠正此问题，可以提醒进行更新的成员面向开发团队分享。你可以建议发言者避免与上级进行眼神接触，这能鼓励他们看向其他开发团队成员。

总结

本节课我们一起学习了如何识别和解决每日站立会议中的常见挑战。每日站立会议旨在良好地开启一天、改善团队支持、鼓励改进、强化团队意识并作为另一个沟通渠道。这是一种非常有效且易于实施的实践。

如果你正尝试在工作场所逐步推行敏捷实践，每日站立会议是一个很好的起点。不妨与你的团队尝试一下。

思考与讨论：
你是否曾参与过每日站立会议？它们有效吗？
你可以实施哪些技巧使其更有效？
过去有哪些关于每日站立会议的建议对你有效？
如果你未曾参与过，你认为它们对你曾共事过的团队会有效吗？为什么？

欢迎在课程讨论中分享你的想法。在下一个模块中，我们将探讨如何利用速率来确保项目的正确管理。

017：速度

概述

在本节中，我们将详细探讨敏捷项目管理中的一个核心概念：速度。速度是衡量团队在特定时间段内完成工作量的指标，对于确保项目正确管理至关重要。

什么是速度？

速度是一个简单的概念。它衡量的是团队在给定时间间隔内完成的工作单位数量。这通常以每个冲刺周期完成的故事点数来衡量。

我们在《敏捷规划与软件需求》课程中讨论过故事点及其如何用于估算用户故事的规模。如果你不熟悉这个概念，可能需要回顾一下那节课。

关于速度，有几点需要明确：

首先，一个用户故事必须根据团队对“完成”的定义完成，其故事点才能计入团队的速度。
其次，速度应在用户故事层面进行衡量，而不是在任务层面。

速度计算练习

现在，我们来计算你的团队在特定冲刺周期内实现的速度。以下哪项应计入团队的速度？
A. 在该冲刺周期内完成的用户故事数量。
B. 在该冲刺周期内完成的用户故事的故事点数。
C. 一个已完成一半任务的功能，因此可以计入其一半的故事点数。
D. 一个已完成编程和文档记录但尚未测试的功能的故事点数。

正确答案是 B。只有满足团队“完成”定义的用户故事，其故事点数才能计入团队的速度。不应计入半成品功能或任务的故事点数。因此，只有在该冲刺周期内完成的用户故事的故事点数才能计入速度。

如何估算速度？

估算速度并不十分精确。在《软件产品敏捷规划》课程中我们曾简要讨论过这一点。理想情况下，估算的速度应基于以往的工作。如果团队和产品相似，你可以使用之前的项目来估算速度。

但如果你没有此类信息怎么办？一种估算速度的方法是将工作分解为任务。将计划在冲刺周期内完成的用户故事分解为工作分解结构。你需要确保估算的任务时间与团队可用时间相符。如果不符，可能需要增加或移除用户故事。

一旦确定了冲刺周期内将完成哪些用户故事，将这些用户故事的故事点数相加，结果就是你第一个冲刺周期的目标速度。这个目标速度将用作你第一个冲刺周期的估算速度。

速度估算练习

你和你的团队正在为开发的第一个冲刺周期做准备。你想计算一个估算速度，但你的团队从未合作过，并且他们也没有此类产品的经验。

你计划在本冲刺周期完成四个用户故事：

用户故事 A 被分配了 3 个故事点。
用户故事 B 和 C 各被分配了 5 个故事点。
用户故事 D 被分配了 1 个故事点。

你将用户故事分解为任务并估算了任务时间。你估计这些故事总共需要 110 小时完成。你的开发团队在本冲刺周期只有 95 个可用小时。你决定从冲刺周期中移除用户故事 A，因为它估计需要 15 小时。

那么，你的团队在第一个冲刺周期的估算速度是多少？
A. 3 个用户故事
B. 14 个故事点
C. 11 个故事点
D. 110 小时
E. 95 小时

正确答案是 C。速度估算应基于用于用户故事的规模度量单位。在这个例子中，我们使用故事点。因此，答案 A、D 和 E 都不正确，因为它们是以用户故事或小时来衡量的。在根据任务估算确定团队没有时间完成用户故事 A 后，你决定将其移除。因此，你的速度估算将基于用户故事 B、C 和 D 的故事点之和，即 11 个故事点。

实际速度与稳定性

团队在每个冲刺周期实现的实际速度可能会因各种原因而波动。你团队的第一个冲刺周期速度可能低于其他冲刺周期。如果团队仍在学习如何协作，或者在学习新技术，就可能发生这种情况。你还会遇到可能影响团队速度的错误或其他风险。

然而，随着时间的推移，团队的速度应该会趋于稳定。一个相对稳定的速度表明你的团队遵循了敏捷原则，即保持可持续的开发节奏。

实际速度用于创建发布和迭代燃尽图。这将是我们在本模块接下来两节课中要学习的内容。

总结

本节课我们一起学习了速度的概念及其在敏捷项目管理中的重要性。我们明确了速度是基于已完成用户故事的故事点数来计算的，并探讨了如何估算速度以及实际速度可能波动的原因。稳定的速度是团队健康运作的标志。接下来，我们将开始应用速度的概念来创建燃尽图。

018：发布燃尽图 📉

概述

在本节中，我们将学习一种在Scrum方法中非常常见的可视化监控工具——发布燃尽图。我们将了解它的构成、如何解读它，以及如何利用它来跟踪项目进度和预测完成时间。

发布燃尽图是一种可视化监控工具，在Scrum方法论中非常常见。

发布燃尽图会向你展示开发团队已经完成了多少工作、还剩余多少工作、团队在每个冲刺中的速度，以及你预计何时能完成产品。可以想象，它是确保项目得到正确管理的绝佳工具。

既然发布燃尽图能展示所有这些信息，你可能会想象它是一张相当复杂的图表。但发布燃尽图的妙处在于，它的概念很简单。让我们来看一个基本的发布燃尽图。

如图所示，我们在水平轴上列出了冲刺。这个示例项目有六个冲刺。在垂直轴上，是总工作量。这可以用你的团队选择来衡量需求规模的任何单位来描述。

在我们的示例中，我们将使用故事点。图表中每个与冲刺对应的条形，代表了在该冲刺开始时仍然剩余的故事点总数。

自然地，在冲刺1开始时，我们拥有所有剩余的故事点，因为我们尚未开始完成它们。这代表了你的总工作量。你的总工作量是你计划在项目中完成的所有用户故事的故事点总和。

当你完成需求时，你将其故事点从燃尽图中移除。

解读燃尽图数据

上一节我们介绍了燃尽图的基本构成，本节中我们来看看如何从中提取关键信息。

你的开发团队即将开始第六个也是最后一个冲刺。这是该项目的发布燃尽图。你的团队已经完成了多少故事点，还剩余多少？

以下是选项：
A. 100个故事点已完成，15个故事点剩余。
B. 100个故事点已完成，0个故事点剩余。
C. 85个故事点已完成，15个故事点剩余。
D. 85个故事点已完成，0个故事点剩余。

在这个项目中，总共有100个故事点。我们知道这一点，因为在冲刺1开始时是100个故事点。在冲刺6（项目的最后一个冲刺）开始时，剩余15个故事点。由于我们以100个故事点开始，剩余15个，这意味着团队已经完成了85个故事点；因此，C是正确答案。

预测线与进度跟踪

了解了如何读取当前状态后，我们来看看如何利用燃尽图进行预测和进度管理。

假设我们的总工作量是90个故事点。我们在第一个冲刺中完成了15个故事点。从发布燃尽图中，我们可以看到该冲刺的速度是15点。我们还可以看到剩余工作是75点。我们也知道我们以75个剩余故事点开始冲刺2。

如果我们想预测完成这个产品需要多少个冲刺，我们可以画一条线穿过条形图来预测。我们称这条线为预测线。由于我们是基于一个冲刺的速度来预测，我们将以该值作为预测依据。根据我们的预测线，它表明应该需要六个冲刺。你可能认为这条线指向了第七个冲刺，但请记住，发布燃尽图是基于每个冲刺开始时剩余的故事点数量。这意味着在冲刺7开始时将没有故事点需要完成，也就是说你不需要那个冲刺。

你也可以使用预测线来查看开发是否按计划进行。

假设我们刚刚完成冲刺4，我们的发布燃尽图看起来是这样的。在第一个冲刺中，我们完成了15个故事点。我们想保持这个速度，所以那是预测线。然而，在冲刺2中，我们只完成了5个故事点。如图所示，我们冲刺3的条形现在位于预测线上方。在冲刺3中，我们完成了15个故事点。我们将速度恢复到了初始值，但由于冲刺2，我们仍然落后于计划。在冲刺4开始时，我们应该总共完成45个故事点，并且开发进行到一半。但如图所示，我们冲刺4的条形位于预测线上方。我们比预期进度落后了10个故事点。

现在假设在冲刺4开始时，因为我们看到项目落后于计划，我们又雇佣了两名开发人员。在冲刺4中，我们完成了25个故事点。这使我们的项目回到了正轨。在冲刺5中，我们又完成了25个故事点。这现在使我们的项目进度超前了。如图所示，我们冲刺6开始时的条形现在位于预测线下方。这意味着你的团队可能能够为产品完成更多需求。

实际上，你的发布燃尽图看起来像这样的可能性极小。更常见的情况是你的发布燃尽图看起来类似这样。

应用示例与“完成”的定义

通过预测线，我们可以评估进度。但这一切都基于一个前提：如何定义“完成”。本节我们来探讨“完成”的定义对燃尽图的影响。

考虑这个发布燃尽图。你已经完成了第一个冲刺。如果你保持从这个冲刺开始的初始速度，你预计需要多少个冲刺来完成工作？

以下是选项：
A. 5个冲刺
B. 6个冲刺
C. 7个冲刺
D. 8个冲刺
E. 你需要更多信息

如果你保持这个速度，你的预测线表明在冲刺6开始时你将没有故事点需要完成。这意味着你将在五个冲刺内完成项目。因此，A是正确答案。

由于发布燃尽图衡量的是已完成的故事点，你可以想象你团队对“完成”的定义非常重要。在敏捷开发中，我们通过可工作的软件来衡量进度，因此，为了将故事点标记为完成，该需求必须满足你团队的“完成”定义。

我曾在一个不专注于可工作软件的团队工作过。我们正在开发一个需要数据库连接的产品。我们一半的团队在开发数据库，另一半在开发产品用户界面。尽管许多功能已经为界面编程，数据库也在开发中，但我们不能将任何需求标记为完成，因为我们正在等待数据库开发完成并连接到应用程序。我们的燃尽图最终看起来像这样。从我们的燃尽图可以看出，看起来好像我们在三个冲刺中什么都没做，然后在冲刺4中非常努力地工作。我们知道情况并非如此，但燃尽图会显示你的团队是否在完全完成功能后才转向新的功能。否则，燃尽图就不能很好地代表产品的进度。

实战练习

理解了理论后，让我们通过一个具体场景来应用所学知识。

你正在一个开发移动应用程序的团队中工作。你刚刚完成了第三个冲刺。你团队的“完成”定义包括仅那些已编程、已文档化、已测试并准备好上市的功能。以下哪些功能应被计为已完成，并在该冲刺的发布燃尽图中扣除其点数？

以下是选项：
A. 一个在上个冲刺已开发并文档化但测试失败的功能，在当前冲刺中已收到小修复并通过了测试。
B. 一个你没有时间测试，但你确信它能工作的功能。
C. 一个已编程、文档化并测试的界面功能，但尚未连接到数据库。
D. 一个运行完美、在冲刺中通过了所有测试并已正确文档化的功能。

只有满足团队“完成”定义的功能才能为发布燃尽图标记为完成。答案B和C都是未满足“完成”定义的功能，因此绝不能为发布燃尽图标记为完成。答案A展示了一个在上个冲刺未满足“完成”定义但现在满足的功能，因此可以在本冲刺为发布燃尽图标记为完成。答案D也满足团队的“完成”定义，因此可以为发布燃尽图标记为已完成。A和D是正确答案。

总结

在本节课中，我们一起学习了发布燃尽图。我们了解了它作为Scrum中可视化监控工具的基本构成，学会了如何从中读取已完成和剩余的工作量。我们掌握了如何绘制和使用预测线来预估项目完成时间并跟踪进度偏差。最重要的是，我们认识到团队对“完成”的明确定义是燃尽图能够准确反映项目真实进展的基石。通过正确使用发布燃尽图，团队可以更有效地管理项目，确保按时交付可工作的软件。

019：发布燃尽图与需求变更

在本节课中，我们将要学习如何在发布燃尽图中清晰地展示需求变更的影响。需求变更是软件开发中的常态，它可能表现为用户故事点数的调整。我们将探讨两种主流的可视化方法，并学习如何解读这些图表。

基础燃尽图的局限性

上一节我们介绍了基础的发布燃尽图。基础燃尽图中不明显的一点是需求变更的影响。

如你所知，需求是持续变化的。可能某个需求的故事点估算发生了改变。我们需要一种方法在燃尽图中表示这种变化。

想象我们正处于一个项目的Sprint 4 开始时，我们的燃尽图看起来是这样的。假设在 Sprint 4 中，团队完成了 15 个故事点的工作。但在 Sprint 5 开始前，新增了两个用户故事，每个价值 5 个故事点。

我们的燃尽图现在看起来会是这样。图表显示开发团队在 Sprint 4 只完成了 5 个故事点，但这并非事实。

展示需求变更的两种方法

以下是两种在发布燃尽图中展示需求变更的常用方法。

方法一：显示“总工作量完成”图

第一种方法是在表示剩余工作的柱状图上方，显示每个冲刺完成的总工作量。图表会呈现如下效果。

在这种燃尽图中，底部是剩余总工作量，顶部是已完成总工作量。你可以看到在 Sprint 2 开始时，故事点没有增减，因为 Sprint 2 开始时的剩余工作量和已完成工作量之和，与 Sprint 1 开始时的总工作量高度相同。

在 Sprint 3 开始时，新增了 10 个故事点。我们可以看出这一点，因为此时剩余工作量和已完成工作量之和大于上一个冲刺。故事点总数保持不变，直到 Sprint 5 开始。此时，总故事点数变少了，因为剩余工作量和已完成工作量之和现在小于前一个冲刺。

这种燃尽图现在同时展示了团队的速率以及故事点的变化。

思考题：观察这个“总工作量完成”发布燃尽图。团队在 Sprint 2 的速率是多少？
A. 0 个故事点
B. 5 个故事点
C. 10 个故事点
D. 15 个故事点

为了确定 Sprint 2 的速率，我们需要看 Sprint 3 开始时的柱状图。请记住，柱状图的下半部分代表剩余故事点，而柱子的总高度代表所有故事点。

Sprint 2 开始时剩余 75 个故事点，Sprint 3 开始时剩余 65 个故事点。表面上看，Sprint 2 似乎完成了 10 个故事点。然而，Sprint 2 的总高度是 90 个故事点，而 Sprint 3 的总高度是 85 个故事点，这意味着有 5 个故事点的工作被移除了。

因此，从看似完成的 10 个故事点中，减去被移除的 5 个故事点，可以得出 Sprint 2 的速率是 5 个故事点。所以正确答案是 B。

方法二：使用“可调整基线”图

第二种展示故事点变化的方法是使用可调整基线。在这种发布燃尽图中，你在图表底部展示故事点的变化。这种燃尽图看起来是这样的。

这是我们测验前示例中使用的同一个燃尽图。在 Sprint 2 开始时，故事点没有变化，你可以看到 Sprint 2 的柱子仍然紧贴 X 轴。

在 Sprint 3 开始时，我们新增了故事点。我们可以看出这一点，因为现在 X 轴下方出现了故事点。故事点数量在 Sprint 4 保持不变。然后在 Sprint 5，我们看到故事点再次发生变化——这次是移除了故事点。我们可以看到这一点，因为 Sprint 5 的柱子现在比前一个冲刺的柱子更高。

你还需要调整预测线，使其与可调整的基线对齐。如果我们从未在 Sprint 5 开始时移除故事点，预测线会是这样的。

思考题：基于这个发布燃尽图以及根据前两个冲刺计算的预测线，如果团队保持这个速率，他们预计这个项目会有多少个冲刺？
A. 5 个冲刺
B. 6 个冲刺
C. 7 个冲刺
D. 8 个冲刺

如果这是一个基础发布燃尽图，你可以预期项目有 6 个冲刺，因为预测线表明第七个冲刺将没有工作。但由于这是一个可调整基线的发布燃尽图，我们必须考虑故事点的变化。

在 Sprint 3 开始时，有许多故事点被添加到项目中。如果你要保持相同的速率，这意味着项目需要更长的时间才能完成。如果你延长基线和预测线直到它们相交，你会发现直到第八个冲刺才没有剩余故事需要完成。因此，团队可以预期项目将需要 7 个冲刺。正确答案是 C。

如何选择燃尽图类型

那么，何时适合使用基础发布燃尽图，何时应该使用“总工作量完成”或“可调整基线”燃尽图呢？

基础形式是展示剩余总工作量的绝佳方式。如果你不关心跟踪团队的速率，那么选择简单版本即可。

如果你打算使用发布燃尽图来提供更多信息，那么你应该使用“总工作量完成”发布燃尽图或“可调整基线”发布燃尽图。这两种发布燃尽图展示了相同的信息，因此使用哪一种没有区别，这只是一个偏好问题。

另一个需要注意的重要点是，有时发布燃尽图被绘制成折线图，而不是我在演示中使用的柱状图。在这种情况下，你的基础发布燃尽图会从这样变成这样。“总工作量完成”发布燃尽图会从这样变成这样。最后，“可调整基线”发布燃尽图会从这样变成这样。

总结

本节课中我们一起学习了发布燃尽图如何可视化整个开发进度。一张简单的图表可以展示项目的总工作量、已完成的工作、剩余的工作、预期的完成时间、故事点的变化以及团队的速率。燃尽图还可以在你项目未按计划进行时提供早期预警。

燃尽图不仅可用于发布层面，也可用于迭代或冲刺层面。这就是我们下一节课将要讨论的内容。

020：迭代燃尽图 📉

概述

在本节课程中，我们将学习几种用于跟踪冲刺或迭代期间开发进度的技术。我们将重点介绍迭代燃尽图，并将其与发布燃尽图进行比较，同时探讨如何将其与Scrum任务板结合使用。

迭代燃尽图简介

上一节我们介绍了发布燃尽图。本节中，我们来看看燃尽图如何进行调整，以跟踪冲刺期间的进度。

迭代燃尽图的工作原理与发布燃尽图非常相似。下图展示了一个典型的迭代燃尽图。

与发布燃尽图类似，迭代燃尽图也有一条预测线。这条预测线展示了可持续完成任务进度的理想状态。

迭代燃尽图可以绘制为折线图或条形图，这与发布燃尽图相同。下图展示了作为条形图的燃尽图样式。

这主要取决于个人偏好。我喜欢对发布燃尽图使用条形图，对迭代燃尽图使用折线图，以便快速区分。本节中我将使用折线图，以便您熟悉两种样式。

根据这个迭代燃尽图，团队计划在冲刺的每一天完成多少工时的工作？选项：A. 220小时， B. 20小时， C. 22小时， D. 需要更多信息。

预测线显示团队在冲刺中共有220小时的待完成工作，冲刺长度为10天。请记住，第11天开始时没有工作要做，因此冲刺只有10天。这意味着团队计划在冲刺的每一天完成22小时的总工作量，因此C是正确答案。

迭代与发布燃尽图的区别

现在，让我们看看迭代燃尽图和发布燃尽图有何不同。

在迭代燃尽图中，横轴是天数，而不是发布燃尽图中的冲刺数。

在迭代燃尽图中，纵轴是以小时为单位的总工作量。而在发布燃尽图中，总工作量是以故事点来衡量的。

这种变化是因为在迭代燃尽图中，我们跟踪的是任务的完成情况，而在发布燃尽图中，我们跟踪的是用户故事及其对应故事点的完成情况。

迭代燃尽图应该每天更新。这通常在每日站会上进行，您需要绘制前一天的工作量。

与发布燃尽图在每个冲刺开始时测量待办工作类似，迭代燃尽图中每天的总工作量代表每天开始时剩余的工作量。

迭代燃尽图上只应包含工作日，不应包括周末或节假日，除非计划在这些日子工作。下图所示的迭代燃尽图代表一个为期两周、包含10个工作日的冲刺。您会注意到周末已被考虑在内，日期从2月26日跳到了2月29日。

规划迭代燃尽图

假设您正在为一个开发团队创建迭代燃尽图。该团队进行为期两周的冲刺，冲刺中间有一个两天的周末，开发人员周末不工作。团队在冲刺期间还要参加一天的会议，当天无法进行产品开发。您的迭代计划应包含多少天？选项：A. 14天， B. 10天， C. 9天。

迭代燃尽图只应包含团队将在产品上工作的天数。由于开发人员在两天的周末和会议日不工作，他们在两周的冲刺中失去了三天，因此迭代燃尽图上只应出现9天。所以，C是正确答案。

Scrum任务板

更新迭代燃尽图通常与Scrum任务板相关联。在深入探讨如何更新迭代燃尽图之前，我们先花点时间看看什么是Scrum任务板以及如何使用它。

Scrum任务板与看板非常相似。有时Scrum任务板被称为白板任务板或简称为任务板。

在Scrum任务板中，您计划在第一个冲刺中完成的所有用户故事都放在第一列。然后，将每个用户故事分解为开发人员任务，并为这些任务创建估算。

通过为每个用户故事创建任务，可以确保没有任务被遗漏或忽略。

当任务处于进行中、等待验证或已完成状态时，它们会在任务板上移动，类似于看板。开发人员可以在领取任务时将自己的名字写在任务上，这有助于在您对某个任务有疑问时知道该找谁。

一旦任务移动到任务板的“已完成”区域，就可以认为它完成了。然后，在更新燃尽图时，您可以将该任务“燃尽”，这意味着可以从剩余工作中扣除该任务关联的工时。

一旦一个用户故事的所有任务都进入“已完成”区域，那么该用户故事就应该满足团队的“完成定义”。与发布燃尽图只包含满足团队“完成定义”的用户故事类似，迭代燃尽图也只应包含完全完成的任务。这就是为什么将迭代燃尽图与任务板结合使用是一个好主意，您可以清楚地看到哪些任务已经完成并经过验证。

任务板与迭代燃尽图结合示例

让我们看一个如何结合使用任务板和迭代燃尽图的例子。

假设我们添加一个任务：“为产品登录页面编写测试”，该任务对应任务板上的第三个用户故事。我们估算这个任务需要10小时。开发人员Ellie将这个任务分配给自己。她将任务移动到“进行中”列并开始编写测试。

当她完成测试编写后，她将任务移动到“待验证”列，供另一位开发人员验证。另一位开发人员Alfred检查了Ellie的测试并确认其完成。在审查过程中，他将任务移动到“验证中”列。完成后，他将任务移动到“已完成”列。

在接下来的每日站会上，Scrum主管Benjamin在迭代燃尽图上将该任务标记为完成。Ellie的任务是当天唯一完成的任务。下图展示了更新后的迭代燃尽图。

更新燃尽图

假设在第六天，这些任务被移到了您团队任务板的“已完成”列。您在第七天早上第一时间更新迭代燃尽图。第七天开始时，剩余多少任务工时？选项：A. 50小时， B. 40小时， C. 25小时， D. 15小时。

第六天完成了价值25小时的任务。这意味着第七天开始时，剩余工作量比第六天开始时少了25小时。第六天开始时，剩余40小时。减去当天完成的25小时，第七天开始时剩余15小时的工作量。因此，D是正确答案。

迭代燃尽图是否需要调整基线？

现在考虑一个问题：迭代燃尽图是否需要可调整的基线？

这取决于您的团队。在大多数情况下，我认为不需要。但是，如果您的团队想使用这个功能，这绝对是您可以轻松实现的。

迭代燃尽图的主要目的是快速可视化团队在冲刺内的进度。您不像使用发布燃尽图那样，用迭代燃尽图来计算速度。因此，添加或删除任务对迭代燃尽图所传达的信息影响不大。

但是，如果您的燃尽图开始“燃烧起来”怎么办？当您添加的任务多于完成或移除的任务时，就会发生这种情况。这表明您的团队在将用户故事分解为任务时，没有进行仔细的迭代规划，可能有些任务被忽视或遗忘了。显然，这不是一个好情况，尤其是在冲刺后期发生。

您通常可以通过花费足够的时间将用户故事分解为任务来避免这种情况。如果确实发现团队在迭代期间添加了大量任务，那么可以考虑移除或优先处理一些任务。这将有助于确保在冲刺结束时，您的所有任务不会都处于半完成状态。

识别异常燃尽图

下图是您团队的迭代燃尽图。水平的燃尽线可能表明什么？选项：A. 您的团队添加的任务工时与他们完成的工时一样多。B. 您的团队正在开始任务，但没有完成它们。C. 您的团队没有做任何工作。D. 您的团队正在以恒定的速度完成任务。

水平的燃尽线，也称为“燃烧横线”，可能很常见且危险。选项A、B和C都代表了燃烧横线可能指示的情况。因此，A、B和C都是正确的。燃烧横线表明您的团队没有完成任务，因此D是错误的。

正如测验所提示的，燃烧横线可能表示三件事：

您的团队添加的任务与他们完成或移除的任务一样多。
您的团队正在处理任务，但没有按照“完成定义”来完成它们。
您的团队在休假。

最可能是第二种情况。当燃尽图开始出现水平线时，通常意味着任务已经开始但没有完成。如果遇到这种情况，最好的解决方案是与团队讨论，优先完成进行中的任务，而不是开始新任务。这可能意味着当团队成员有空闲时间时，他们可以帮助其他人完成工作，而不是开始一个独立的新任务。

如果燃烧横线持续存在，您将面临在迭代结束时用户故事处于半完成状态的风险。我喜欢把这样的项目比作一个管理不善的DIY家居装修项目：您想翻新房子，升级多个房间，并且同时开始一堆任务。您拆掉了客厅的地板，拆除了浴室的台面，打磨了所有的室内门，并移除了厨房水槽。结果多个房间都处于半完成状态，房子会显得混乱且无法使用。这在燃尽图上看起来就像一条燃烧横线。这并不是说您没有做任何工作，而是没有房间被完成。

总结

如您所见，迭代燃尽图能在一两天内就突出显示问题开始出现的迹象。燃尽图在冲刺中期就识别出任务未完成，远比在冲刺结束时才发现要好得多。

迭代燃尽图是一个优秀且简单的工具，可以快速识别您的进度何时开始偏离预期。它们有助于确保您的产品在日常基础上得到妥善管理。

本节关于如何确保项目得到妥善管理的模块到此结束。在下一个模块中，Bradley将带您了解回顾会议。

021：回顾

欢迎来到本课程的最后一个模块。在本模块中，我将讨论回顾。

让我们开始吧。回顾是软件开发社区中使用的一个术语，用于描述反思项目中已完成和未完成工作的行为。

回顾主要有两种基本类型：冲刺回顾和项目回顾。

回顾的基本理念是反思项目中进展顺利的部分、进展不顺利的部分，以及未来可以采取哪些措施来改进流程。

在冲刺回顾中，这是通过反思上一个冲刺中发生的事情来完成的。还记得在《敏捷规划与软件项目》课程中，我谈到了时间盒法，摩根谈到了迭代规划吗？这两种实践都引入了将时间组织成小而可管理的块的想法。在这些时间盒块之后，至少在敏捷项目中，安排一次计划内的自我评估会议也很重要。这就是冲刺回顾。

在冲刺回顾中，从团队自我评估中获得的见解会被应用到下一个冲刺中，这使得项目能够持续改进。团队选择什么是重要的，什么应该被关注。这赋予了团队对改进的贡献感，并让他们拥有改进的所有权。它帮助团队从内部获得成功的动力，他们不需要外部力量来推动他们改进。

在项目回顾中，有时也称为事后分析，团队会在整个项目被认为完成时，回顾整个项目。项目回顾的一个主要区别在于，没有下一个冲刺可以将回顾中获得的经验教训应用其中。但这不应阻止你进行项目回顾。尽管当前项目可能没有下一个冲刺，但团队成员很可能还会参与其他项目。这些项目可能是团队共同参与的其他项目，或者团队解散后成员加入其他项目。这并不重要。重要的是整个团队有机会反思整个项目，并将学到的经验教训带入未来的工作中，无论团队是否在一起。

进行项目回顾的另一个非常重要的原因是，它能让团队释放积压的情绪能量。在大多数项目中，都会存在个性差异、分歧和妥协。如果在项目结束时，这些问题没有得到解决，可能会产生不健康的影响。进行项目回顾使团队能够在协作、开放、无评判的氛围中解决分歧。我们将在下一课中讨论如何确保营造这种氛围。

进行软件项目事后回顾的两个原因是什么？

A. 将先前项目中学到的经验教训应用到未来项目中。
B. 保证先前项目中的问题不再发生。
C. 让团队成员修复彼此受损的关系。
D. 根本不应该进行事后分析。

答案是 A 和 C。事后分析是将经验教训应用于未来项目的好方法，同时也让人们有机会公开谈论他们的经历并修复关系。

进行回顾的价值是显而易见的。但当你避免进行回顾时会发生什么？设想一个没有进行冲刺回顾的Scrum项目。每个冲刺之后会发生什么？团队很可能会计划下一个冲刺并直接投入开发。事实上，这种情况经常发生。然而，如果不允许反思，这些项目往往会延续之前的状态，没有明确意识到项目中哪些进展顺利，哪些不顺利。人们可能有自己的感受，并且可能经常表达这些感受。但如果没有全团队的回顾来捕捉这些感受，就很难就哪些需要改变、哪些应该保持不变做出团队决策。请记住，无论你的团队多么优秀，总有改进的空间。没有人是完美的，我们不是机器。因此，与其在项目中回避反思，不如鼓励反思。由此产生的改进通常是切实可见的。

以上我们介绍了回顾是什么以及为什么要使用它们。在下一课中，我将讨论围绕回顾的一些问题。我们下节课见。

022：回顾问题

在本节课中，我们将探讨与回顾会议相关的常见问题，并学习如何克服这些问题，以确保回顾会议能成功地在项目中发挥作用。

上一节我们介绍了回顾会议的概念及其价值。本节中我们来看看在实施回顾会议时可能遇到的一些障碍。

为何有些团队不进行回顾会议？

以下是团队可能不进行回顾会议的一些原因。这些原因虽然常见，但并非无法克服。

错误动机：团队可能仅仅因为审计要求等外部压力而进行回顾。
时间不足：团队可能觉得没有足够的时间进行回顾。
倾向向前看：团队可能更愿意关注未来计划，而非反思过去。
不愿讨论自身节奏：团队成员可能不愿意讨论自己的工作模式或效率。
职业倦怠：团队可能因项目压力而感到疲惫，不愿再思考项目问题。

安全感：回顾会议的核心障碍

正确实施回顾会议的一个主要障碍是团队缺乏安全感。

安全感并非指物理安全，而是指团队成员在情感和职业上感到安全。这意味着他们能够以真实、坦诚的方式表达自己，而不必担心来自同事或管理层的负面反应。这是一种能够与队友开放沟通的能力，因为你知道自己的声音会被倾听，并且无论你说什么，都会得到支持。

这个概念可能有些抽象，我们来看一个例子。

皮埃尔是一名开发人员，正在与团队进行每日站会。他坦诚地告诉团队自己前几天效率低下，原因是工作过度导致倦怠。他之所以能这样做，是因为他知道不会因为效率低下而受到惩罚。皮埃尔感到足够安全，可以向团队公开表达自己的感受。

反之，如果皮埃尔感到不安全，他可能会倾向于夸大自己前一天的工作量，使自己看起来更高效。例如，他可能会过分详细地描述对某个软件工具集的研究，而不是坦言自己遇到了倦怠问题。这表明皮埃尔在工作环境中感到不安全，无法完全表达自己。

如何营造安全感？

营造一个让团队感到安全的环境至关重要。以下是一些关键方法。

首先，明确告知团队你希望营造一个鼓励开放沟通、欢迎新想法和新观点的文化环境。确保团队中的每个人都有权表达自己的意见，只要这些意见不伤害其他成员或破坏健康的团队文化。

其次，对成员的贡献表示赞赏。在团队环境中表达自己并不总是容易的。没有反馈，人们很难知道自己的意见是否被重视。更糟的是，没有反馈，许多人会默认自己的意见不被重视。因此，对贡献表示赞赏非常重要。这并不意味着你必须同意每个人说的每句话，而是让人们知道他们的贡献是有价值的。

一种方法是直接告诉每个人他们的意见受到重视。然而，如果处理不当，这可能显得不够真诚。更有效的方法是鼓励他人对你的观点和想法给予反馈，同时也对他人的想法提供反馈。展示对他人想法赞赏的一个好方法是，在此基础上进一步构建想法，并将原始想法的功劳归于提出者。这不仅验证了该想法，也肯定了提出者。

最后，积极的领导力是营造安全环境的关键。作为产品经理，领导力通常从你开始。通过赞赏他人和保持积极态度，成为团队内的榜样。不要让小问题影响大局，更不要让个人偏见妨碍你对每位团队成员给予同等高度的尊重。领导团队的能力是优秀管理者的重要特质，而这很大程度上来自于以身作则。

回顾会议中的安全环境

让我们看看如何将安全感应用于回顾会议中，以确保其促进开放协作。

首先，你需要建立一个功能性团队文化，而非功能失调的文化。在功能性文化中，团队中的每个人都努力让其他人看起来更好。没有秘密或戒备性的语言，没有信息隐藏，也没有争夺团队明星位置的竞争。在一个功能性团队中，每个人共享工作的所有权，因此也共享荣誉。每个人看起来都很好。

在功能性团队中，是团队成员个体驱动会议的效率，而不是经理。因为团队知道他们的行为会影响项目，并且他们对项目拥有所有权，所以他们有动力采取措施进行改进。因此，功能性团队的会议是建设性的，决策来自团队。

另一个重要的注意事项是：人们参与项目并非为了破坏它。他们是在自身技能和所处环境的限制下，尽力做到最好。思考这个问题的一个好方法是参考航空事故调查。航空公司和管理机构不会简单地指责飞行员失职，而是会调查导致失败的所有因素，即使失败是由于人为错误。他们会调查飞行员是否遵循了程序，如果没有，是否是因为缺乏培训、注意力不集中，或者睡眠不足。通过这种客观、可衡量的方式反思事件，更容易做出未来的改进。

总而言之，回顾会议不应是一场指责游戏。它不是人们互相指责和争吵的时候。事实上，它可以是一个修复感情、建立信任关系的机会。如果操作得当，回顾会议将成为软件产品经理工具箱中强大的工具，几乎可用于每个项目。

总结

本节课中我们一起学习了阻碍团队有效进行回顾会议的常见问题，特别是安全感的缺失。我们探讨了如何通过建立开放沟通的文化、赞赏贡献以及积极的领导力来营造安全的环境。我们还了解了功能性团队文化的重要性，并强调回顾会议应基于实证数据，而非指责。现在你已经了解了回顾会议可能遇到的问题，下一节我们将深入探讨如何成功地进行一次回顾会议。

023：冲刺回顾会议 🧐

在本节课中，我们将要学习敏捷开发中的一个关键会议——冲刺回顾会议。我们将了解它的目的、流程以及如何有效地进行，以确保团队能够持续改进其工作方式。

回顾会议既发生在迭代层面，也发生在项目层面。本节中，我们来看看冲刺层面的回顾会议。

冲刺回顾会议应该是一个冲刺中最后进行的事项。它通常在冲刺评审会议之后举行。冲刺评审会议用于向客户或产品负责人演示产品成果。而冲刺回顾会议则用于评估开发过程本身。

敏捷开发要求你不仅要评审和调整产品，也要评审和调整开发过程。这是一个回顾产品构建得如何、哪些方面运作良好以及哪些方面可以改进的机会。

确保冲刺回顾会议的氛围安全，允许开放对话，这一点至关重要。参与者需要能够自由地表达他们对冲刺的真实感受。如果团队不能诚实地指出问题所在，就无法产生有效的解决方案。

冲刺回顾会议的时间盒通常设定为一小时。然而，它不像其他Scrum事件那样严格。你希望会议简短高效，但如果出现重大问题，不应为了遵守预定时间而掩盖问题。

你正在主持团队的冲刺回顾会议。以下哪些是会议中合适的讨论话题？

以下是选项列表：

A. 一名开发人员表示对产品的用户界面不满意。
B. 一名开发人员指出团队在上个冲刺中低估了任务量。
C. 你强调了团队在上个冲刺中完成的出色工作。
D. 一名开发人员建议在下个冲刺中实施迭代燃尽图。
E. 产品负责人建议在下个冲刺中实现某个功能。

你需要确保冲刺回顾会议的重点是过程，而非产品。因此，答案A和E是不正确的。冲刺回顾会议是讨论开发过程中哪些做得好、哪些做得不好以及哪些可以改进的绝佳场合。因此，答案B、C和D是正确的。

在冲刺回顾会议中，通常会提出三个主要问题。上一节我们介绍了会议的核心目的，本节中我们来看看这些具体问题。

以下是三个核心问题：

这个冲刺中，哪些方面做得好？
这个冲刺中，哪些方面做得不好？
为了下一个冲刺，我们可以改进什么？

我建议按照这个顺序提出问题。Scrum Master应该以积极的基调开始会议，对团队完成的工作表示赞赏和认可。通常，批评不容易被接受。Scrum Master应引导会议，确保人们不感到被攻击。对话应该开放、诚实，同时保持尊重。

最后，要以建设性的方式结束会议。这也能让会议圆满收尾，避免人们带着负面情绪离开。以需要改进的方面来结束会议，能给团队带来期待，并为下一个冲刺开个好头。如果一个冲刺没有按预期进行，这一点尤其重要。你不希望下一个冲刺受到前一个冲刺失败感的影响。

有时，为了前进，我们必须回顾过去。在下一课中，我们将通过探讨项目回顾会议的内容，来扩展对回顾会议的理解。

本节课中，我们一起学习了冲刺回顾会议。我们明确了它的目的是评估和改进开发过程，而非产品功能。我们了解了会议应营造安全、开放的氛围，并遵循“做得好”、“做得不好”、“可改进”三个问题的结构来引导讨论，从而帮助团队持续进步，并为下一个冲刺做好准备。

024：项目回顾练习

📖 概述

在本节课中，我们将学习如何组织一场有效的项目回顾会议。我们将把回顾会议比作一顿包含三道菜的大餐，并详细介绍每道“菜”对应的具体练习活动，以及会前需要做的准备工作。

🍽️ 项目回顾会议：一顿三道菜的大餐

Kurth 将项目回顾会议比作一顿包含三道菜的大餐。

第一道菜是开胃菜，即“阅读”环节。其目的是在团队中建立信任，让团队认识到他们完成了什么，并制定一些基本规则。

接下来是主菜，即“回顾过去”环节。在会议的这一部分，团队将回顾产品生命周期中发生的一切。这是一个分享实际发生情况的机会。团队中并非每个人都清楚开发过程中发生的所有事情，这种情况很常见。这个环节能让所有人信息同步，并有助于找出一些问题的根本原因。

最后是甜点，即“展望未来”环节。这是团队向前看、提出改进领域的机会。

任何一顿美餐都需要一些准备。因此，在“上菜”之前也必须做一些准备工作。

在本节中，我们将讨论回顾会议引导者可以在每道“菜”中使用的一些练习。本课程假设你以外部人员的身份为另一个项目担任此角色。你在产品发布后主持一场项目回顾会议。

🧩 回顾会议应涵盖的主题

在项目结束时，有几个功能未能按时实现。以下哪些应该是项目回顾会议涵盖的主题？
A. 关于未按时实现的功能的细节。
B. 为什么功能没有按时实现？
C. 团队下次可以改进哪些方面以确保所有功能都能实现。
D. 为按时实现功能而采取的有效措施。

与冲刺回顾类似，项目回顾旨在发现哪些方面做得好、哪些方面做得不好以及哪些方面可以改进。你不应该讨论任何具体的功能细节。然而，你应该讨论它们是如何被实现的，以及这种方式是否有效。你还应该确定下次可以改进的领域。因此，答案 B、C 和 D 都是正确的。

📋 会前准备工作：第一道“开胃菜”

正如之前所说，每顿美餐在会议前都需要一些准备工作。第一项是回顾会议会前准备材料。这是一份通过电子邮件发送给所有受邀参加回顾会议的人员的材料。它提出了一些问题，可以帮助识别会议期间可能出现的任何普遍模式。它还鼓励参与者在实际的回顾会议上分享更多内容。他们更有可能分享他们已经写下来的东西。这也能让他们在会前就开始思考这个项目。

会前准备材料应提出以下问题：

为了让我们从这次经历中学到最多，需要讨论哪些主题？
你希望在回顾会议期间发生什么？
你希望这次回顾会议产生什么样的长期影响？
你对这次回顾会议有什么保留意见、担忧或顾虑？
当你想到这次会议时，你有什么感受？
我还应该问什么？你会如何回答？

这些问题的答复应返回给引导者。应确保参与者的答复保密，并且仅用于寻找普遍趋势。

如果你作为团队的外部人员引导回顾会议，请事先向团队介绍自己。这将建立信任，并让你有机会亲自讨论项目。或许可以指出你在会前准备材料中注意到的一些趋势。这也给了你一个机会提醒人们完成会前准备材料。人们忽略这一步而依赖记忆是很自然的。

🧳 会前准备工作：鼓励携带项目制品

你需要做的另一项准备工作是鼓励参与者携带项目制品参加会议。这些制品可以是项目中发挥作用的任何东西：备忘录、时间表、燃尽图、随意的便利贴、纪念品、图片、礼物、笔记等。

你应该鼓励参与者尽可能多地携带制品。甚至可以设置一个竞赛，为能带来最多制品、或最具创意、最不寻常制品、以及最重要制品的人颁发奖项或奖品。

❓ 什么是项目制品？

你正在为项目回顾会议做准备。你告诉开发团队携带任何与项目相关的制品。一位开发人员对什么会被视为制品感到困惑，想让你看看他考虑要带的东西。以下哪些会被视为项目制品？
A. 用户界面的原始草图。
B. 他的雇佣合同副本。
C. 解决一个重大问题后有人留在他桌上的一个小奖杯。
D. 启发产品灵感的一部电影，是他从客户那里借来的。
E. 一份总结当时进展的旧备忘录。

制品的定义是包容性的。这意味着任何被某人认为对项目重要或有意义的东西都可以被视为制品。因此，所有答案都是正确的。

✅ 总结

本节课中，我们一起学习了如何将项目回顾会议结构化为一顿包含“开胃菜”（建立信任与规则）、“主菜”（回顾过去）和“甜点”（展望未来）的大餐。我们明确了会议应关注过程而非具体功能细节，并重点介绍了会前准备的关键步骤：分发会前问卷以收集初步想法，以及鼓励团队成员携带多样化的项目制品来激发讨论和回忆。这些方法有助于确保回顾会议富有成效，真正服务于团队的持续改进。

025：项目回顾练习准备

在本节课中，我们将学习如何为项目回顾会议做准备，特别是几个关键的“准备性”练习。这些练习旨在为回顾会议营造合适的氛围，建立团队信任，并帮助团队全面审视项目。

概述：准备性练习的重要性

首先，我们从准备性练习开始。需要认识到，并非每个项目回顾都需要执行所有练习。正如我们讨论的大多数事情一样，你需要考虑你的团队，并使会议适应你的团队。

介绍练习

第一个练习是介绍练习。这个练习发生在回顾会议的开始，大约需要30分钟。这是确保每个人都已被介绍的好时机。如果你怀疑或知道团队成员之间或与你并不完全熟悉，现在就是进行一轮介绍的好时机。你还应该为会议建立一个大致的时间表和议程。请记住，事情可能会根据会议的进展而改变。

开始介绍的一个好方法是让人们定义“智慧”这个词。什么是智慧？一个人如何变得智慧？为什么一个75岁的男人会比一个16岁的男孩被认为更有智慧？这通过认识到智慧是从经验中学习获得的来开启对话，而这正是本次会议旨在做的事情。

接下来，你应该建立并强调这不是一场指责游戏。这是介绍“凯斯首要指令”的好机会：无论我们发现什么，我们都必须理解并真正相信，每个人在当时已知的情况、他或她的技能和能力、可用资源以及当时的情况下，都已经尽了最大努力。

为什么完成准备课程中的练习很重要？
A. 在团队中建立信任。
B. 让团队相信这次会议将产生积极的结果。
C. 设计创造安全环境的基本规则。
D. 消磨时间，使会议持续整整三天。

准备课程旨在建立信任、为项目设定积极目标，并建立指导方针以维护团队的安全环境。它不是浪费时间的方式，因此正确答案是A、B和C。

定义成功练习

上一节我们介绍了如何开启会议，本节中我们来看看如何定义项目的成功。这个练习旨在定义团队认为什么是成功，确定团队是否认为他们的项目是成功的，并找出他们本可以做些什么来使项目被视为成功。

在项目回顾中，你的团队能记住的可能只是最近为完成项目所做的挣扎和冲刺。他们会专注于出错的地方。退一步认识到团队的成功和成就是很有用的。即使项目失败了，团队也有很多值得骄傲的地方。

回顾会议的这一部分应花费30分钟到1小时。通过询问团队“这个项目成功吗？”来开启小组讨论。记录回答。然后，你想向团队展示他们完成的一切，向他们展示他们为项目付出的努力。最后，你想用这个成功定义来结束这个练习：一个成功的项目是每个人都说‘我希望我们能以完全相同的方式再做一次’的项目。

询问团队这个项目是否符合这个成功定义。如果不符合，团队本可以做些什么来使其符合？这个定义将突出项目中许多不成功的领域，并提出许多改进建议。

在回顾会议中建立安全感很重要。团队如果觉得会有不良后果，就不会有效地分享所有需要分享的内容。你可以通过哪些方式在回顾会议中建立安全感？
A. 设定基本规则。
B. 团队如何认识会议的目标。
C. 使练习成为可选项。
D. 逐步引入困难话题。

这些都是你可以在回顾会议中建立安全感的方式，我们将介绍如何在你的会议中实施这些方法，为你的团队创造一个安全的环境。

建立安全感练习

现在，让我们继续讨论建立安全感练习。这个练习旨在确保团队中的每个人都感到足够安全，可以分享他们对项目的感受。如果团队彼此之间已经相当熟悉，或者已经习惯参与回顾会议，那么你可以考虑跳过这个练习。

你应该建立的第一件事是回顾会议中的每个练习都是可选的。如果人们觉得是被迫参与，他们更可能说他们认为应该说的话，而不是他们真实的想法。然后，你应该进行一次无记名投票，以确定团队感到的安全程度。让他们写一个1到5之间的数字，代表他们感到的安全程度。1表示他们感到不安全，不会分享真实感受。5表示他们感到足够安全，可以分享任何事情。如果每个团队成员都表示3或以上，那么你就可以安全地继续会议。

接着，你应该为回顾会议建立一些基本规则。团队如何创建能鼓励他们感到更安全的规则？如果团队自己没有提出，你应该添加这些规则：回顾会议中的所有参与都是可选的。我们不会拿房间里的任何人开玩笑。 最后一条规则应该是：基本规则可以在任何休息后修改。

你应该添加到团队创建的规则列表中的一条规则是：“我们不会拿房间里的任何人开玩笑。”为什么这是一条重要的规则？
A. 这是一个严肃的会议，任何玩笑都是不合适的。
B. 有时很难判断一个玩笑是出于好玩还是伤人。
C. 如果人们认为可能会有人拿他们开玩笑，这会阻碍他们分享。
D. 你想专注于拿不在房间里的人开玩笑。

有时很难判断一个玩笑的意图，或者它可能被误解。一个本意是好玩的玩笑可能被接收者理解为伤人的。最安全的方式就是完全避免它们。这条规则也很重要，因为如果人们认为可能会有人拿他们开玩笑，他们可能会不愿意分享。因此，正确答案是B和C。

项目成果竞赛练习

本课我们将讨论的最后一个准备性练习是项目成果竞赛练习。我在本课早些时候提到过项目成果。鼓励参与者带来他们能找到的与项目相关的任何及所有成果。这个练习应花费一到两个小时，具体取决于团队人数和他们带来的成果数量。

首先让人们解释他们的成果。为什么它对个人或项目很重要？询问关于成果的问题，并鼓励其他人也这样做。在所有成果都展示完毕后，是时候对成果进行投票了。首先确定最大的成果集合，然后让人们提名并投票选出最具创意或最不寻常的成果，以及最重要的成果。你应该为这些类别的获胜者准备小奖品。

成果帮助每个人看到他们在项目期间完成的一切。它帮助他们记住美好的时光和出色的工作。它也鼓励团队思考整个项目，而不仅仅是最后的冲刺阶段。

总结

本节课中，我们一起学习了为项目回顾会议做准备的几个核心练习。我们了解了介绍练习如何开启对话并设定基调，定义成功练习如何帮助团队从积极角度审视项目，建立安全感练习如何通过设定基本规则（如“参与可选”、“不开玩笑”）来营造安全的分享环境，以及项目成果竞赛练习如何通过展示实物成果来帮助团队回忆成就、全面看待项目。这些练习共同为深入、有效的项目回顾奠定了基础。

026：项目回顾练习——回顾过去

在本节中，我们将学习如何通过一系列结构化的练习来回顾项目的过去。这些练习旨在帮助团队全面、深入地反思项目历程，识别关键事件、总结经验教训并促进团队建设。

上一节我们介绍了项目回顾的整体框架，本节中我们来看看专门用于回顾“过去”的具体练习方法。

🗓️ 创意时间线练习

首先，我们将进行创意时间线练习。这个练习的目的是让团队按时间顺序梳理项目中所有的重要事件。

以下是进行创意时间线练习的步骤：

清理一面墙或白板，并贴上纸张。
给每位成员一叠索引卡或便利贴。
团队成员将使用这些卡片在时间线上标记重要事件。
如果适用，让成员在时间线上标记出他们加入项目的日期。
如果有成员在项目结束前离开，也标记出他们的开始和结束日期。
然后，团队开始共同创建重要事件列表。这是一个包容性的列表，任何成员认为重要的事件都应添加到时间线上。
活动结束时，你将获得一个展示整个项目历程及其所有事件的视觉化图表。

⛏️ 挖掘宝藏练习

在时间线创建完成后，下一个练习是挖掘宝藏练习。在这个练习中，团队将按时间顺序分期回顾时间线。

以下是进行挖掘宝藏练习的步骤：

在房间内准备五块白板或海报纸，分别标注以下主题：
- 我们做得很好且不希望忘记的事情。
- 我们学到的东西。
- 下次我们应该以不同方式做的事情。
- 仍然让我们困惑的事情。
- 我们需要更详细讨论的事情。
在讨论每个时间段时，成员可以建议将相关内容添加到这些主题下。
在回顾各时期时，你可以提出以下问题来激发团队讨论：
- 哪张卡片最重要？
- 哪张卡片让你感到惊讶？
- 哪些卡片你不理解？
- 你看到任何正在形成的模式吗？
- 接下来我们应该讨论哪张卡片？
- 哪些卡片还需要讨论？

这个练习需要投入时间，预计耗时五到八小时，最好分两天进行。这是对项目中发生的一切进行深入调查的过程。

我提到创意时间线练习最好分两天进行。你认为为什么这样做很重要？
A. 因为连续八小时讨论一个话题时间太长了。
B. 给团队时间反思项目。
C. 为了让会议持续更久。

这个练习是回顾会议的核心部分。连续八小时专注于一个话题确实很长，因此休息很重要。利用晚间进行反思也会产生更好的结果。因此，答案A和B是正确的。

📈 情绪地震仪练习

在时间线创建和“挖掘”完成后，你可以进行情绪地震仪练习。这个活动有助于探索引发情绪的事件，从而帮助理解项目的意义。

以下是进行情绪地震仪练习的步骤：

让参与者在时间线下方画一条线，用以代表他们在当时的情緒起伏。
这将有助于从项目中识别出那些引发强烈情绪的重要事件。

🙏 表达感谢练习

我们要探讨的最后一个“回顾过去”的练习是表达感谢练习。这个练习可以根据需要在回顾会议的任何时间进行多次。

表达感谢练习是团队成员相互表达赞赏的机会。在向某人表达感谢时，措辞应像“莎娜，我感谢你帮助我学习Java”，而不是“我感谢莎娜帮助我学习Java”。使用“我感谢你为了...”的句式显得更亲切。

以下是进行表达感谢练习的步骤：

所有人站成一个圈。
由一个人开始，向圈内的另一个人表达感谢。
接收到感谢的人再向其他人表达感谢。
这个过程持续进行，直到每个人都收到了一次感谢。

这有助于修复关系并提升团队士气。

本节课中，我们一起学习了四种用于回顾项目过去的练习：创意时间线用于可视化项目历程，挖掘宝藏用于深入分析各阶段，情绪地震仪用于关联事件与情感，以及表达感谢用于加强团队凝聚力。这些结构化方法能有效引导团队进行全面的项目反思。

027：展望未来 🚀

在本节中，我们将学习项目回顾会议的最后阶段——展望未来。我们将重点介绍两个核心练习，旨在引导团队讨论敏感话题并圆满结束会议，从而为下一个项目制定切实可行的改进计划。

上一节我们介绍了回顾会议中分析过去的练习，本节中我们来看看如何引导团队面向未来，特别是处理那些棘手的、未被提及的问题。

启动“创造奇迹”练习

在回顾会议的这个阶段，通常会出现一些团队成员回避讨论的话题。“创造奇迹”练习旨在主动引发关于这些敏感议题的讨论。此时，团队已更适应分享感受，对项目有了更深入的集体理解，并且意识到会议即将结束。如果此时不提出敏感话题，可能就永远没有机会讨论了。作为引导者，你需要邀请大家进行这场艰难的对话，然后退后一步，让对话自然发生。

以下是启动此讨论的几种方式：

你可以说：“这次回顾即将结束。现在是提出任何你希望讨论但尚未提及的事情的好时机。”
或者，你可以提及在整个回顾会议中察觉到的一些暗示。
如果以上方法都不奏效，你可以直接提出：“我们已经花了好几天时间讨论所有事情，除了一个非常重要的问题……”

让团队讨论该问题或这些问题，并尝试共同找出解决方案。你的角色是观察对话的展开，并确保其朝着正确的方向进行。

引导敏感讨论

假设团队正在进行“创造奇迹”练习，讨论一个敏感话题。一名开发人员感到自己工作过度且被利用，讨论开始变得充满攻击性和伤害性。

你应该如何将讨论带回相互尊重的轨道？
A. 完全停止讨论。
B. 回顾之前共同制定的会议准则。
C. 让其继续，他们会自己解决。
D. 开始提问，询问某些行为让他们感受如何，或他们为何采取某种行动方式。

答案分析：让讨论继续下去很重要，但必须以尊重的方式进行。如果有人公然违反已制定的准则，应提醒他们这些规则及其设立的原因。如果这不起作用，你可以通过提问来引导讨论，例如询问某些行为让当事人感受如何，或他们为何采取某种行动方式。在大多数情况下，人们并非心怀恶意，而是存在某些误解。引导讨论以揭示这些误解。因此，B和D是正确答案。

进行“结束回顾”练习

“结束回顾”练习旨在为回顾会议画上句号，并收拢所有未尽的议题。这个活动能积极、团结地结束会议。

以下是进行此练习的步骤：

给团队每位成员分发纸和笔。
请他们写下希望在回顾会议结束后能看到实现的一个“希望”或“愿望”。告诉他们可以匿名写下愿意与团队分享的内容。
收集所有卡片并打乱顺序。
给每人发一张卡片，让他们阅读。
在小组内传递卡片，直到每个人都阅读了所有卡片。
在每个人都阅读完毕后，用一句积极的话结束会议，例如：“我认为我们在过去几天里取得了很大进展。我相信很多这些希望和愿望都会实现。现在，就看你们的了，去让它发生吧！”
最后正式宣布：“本次回顾会议到此正式结束。”

本节课中我们一起学习了如何通过“创造奇迹”练习引导团队讨论敏感但关键的改进点，并通过“结束回顾”练习以积极、富有凝聚力的方式结束会议。这些练习能帮助团队将回顾的见解转化为未来的具体行动。若想了解更多回顾练习或更详细的指导，可以参考Norman L. Kerth的著作《Project Retrospectives: A Handbook for Team Reviews》。

028：《软件改进的评审与度量》课程总结

在本节课中，我们将回顾整个课程的核心内容，总结我们在确保构建正确产品、正确执行流程以及正确管理项目方面所学的各种方法。

上一节我们回顾了课程各模块的主要内容，现在我们来对整个课程进行总结。

本课程涵盖了多种旨在改进产品、流程和项目的方法。其核心目标是实现 构建正确的产品、正确地完成 以及 正确地管理。

以下是本课程四个模块所学关键方法的总结：

模块一（Morgan主讲）：确保构建正确的产品。方法包括：迭代评审会议、用户研究、衡量产品成功，以及业界用于创建成功产品的流程实例。
模块二（Bradley主讲）：确保开发流程正确执行以获得高质量产品。方法包括：同行评审技术（如走查、技术评审和审查），引入了度量的目的、一个指导其使用的目标导向框架，以及一些优秀和不良度量的例子。
模块三（Bo主讲）：确保项目得到正确管理。方法包括：每日站会、优先级排序、发布迭代、燃尽图以及用于监控进行中和已完成工作状态的任务板。
模块四（Brad主讲）：回顾与改进。讲解了两种回顾会议：迭代回顾和项目回顾。两者都旨在发现问题、认可贡献，并总结经验教训以改进未来的工作。

由于这是专项课程中的第五门课，接下来将是顶点课程。

如果将本专项课程的结构比作一个身体，那么顶点课程就相当于至关重要的头部，它建立在代表之前课程的双腿、躯干和手臂之上。

顶点课程将整合你目前所学的大部分知识。在那里，你将在一个模拟环境中应用敏捷方法论，与用户和利益相关者互动，定义产品的用户故事，对产品待办列表进行优先级排序，规划发布，获取反馈，处理变更，跟踪进度，应对风险等等。

我们顶点课程再见。

本节课中，我们一起学习了如何通过评审、度量和敏捷实践来持续改进软件产品、开发流程和项目管理，最终达成“正确构建、正确执行、正确管理”的目标。

029：《软件改进的评审与度量》｜课程概览｜

概述

在本节课中，我们将要学习艾伯塔大学软件产品管理专项课程的概览。本节将介绍该专项课程的目标、内容结构以及学习完成后你将获得的技能与认证。

大家好，我是乔纳森·舍费尔，一名计算机科学家，现任艾伯塔大学理学院院长。

我很荣幸地向大家介绍由我校计算机科学系开发的软件产品管理专项课程。

这套系列课程将教你如何成功地引导一个软件产品从构思到交付的整个开发过程。

艾伯塔大学被公认为世界领先的公立研究型与教学密集型大学之一。作为加拿大顶尖大学，我们在科学、人文、创意艺术、商业、工程和健康科学等领域均以卓越著称。我们的热情在于为学生成功提供起点，我们的目标是激励、转变和提升我们的学生，并帮助他们实现目标。

强大的协作与沟通技能对于复杂软件的开发至关重要，正如它们在我们生活的许多领域一样。考虑到这一点，我们的计算专家团队将为你提供掌握敏捷软件开发所需的过程与实践。

我们对软件产品管理流程的实践经验，将为你提供直面挑战所需的一切。我们将教你如何理解和细化客户的软件需求，以及如何将这些需求传达给开发团队。

你将学习从监控项目到确保其符合客户需求、遵循项目计划并达到预期质量水平的技术。

你将有机会加入一个软件产品管理社区，在那里你可以分享经验并从他人的见解中学习。

最后一门课程是一个为期六周的毕业设计项目，它将为你提供在真实模拟环境中应用这些管理技术的机会。成功完成毕业设计后，你将获得认证，并为在软件产品管理职业生涯中脱颖而出做好准备。

我很高兴你对学习我们的专项课程感兴趣。我们已经尽力使这成为一个有价值的教育体验。

现在轮到你了，祝你好运。

总结

本节课中我们一起学习了艾伯塔大学软件产品管理专项课程的总体介绍。我们了解了课程的目标是培养从产品构思到交付的全流程管理能力，课程内容涵盖需求分析、团队协作、项目监控以及一个综合性的毕业设计项目。完成学习后，你将具备成为专业软件产品经理的技能并获得相应认证。

030：引言与概述

在本节课中，我们将学习软件产品管理专项课程中的《软件改进的评审与度量》课程。本课程旨在介绍如何通过评审和度量来持续改进软件产品、开发过程及项目管理，以确保我们构建出“正确的产品”，并以“正确的方式”完成和管理它。

我是 Ken Wang。

欢迎来到软件产品管理专项课程中的《软件改进的评审与度量》课程。

本课程建议在您完成《软件产品的敏捷规划》课程后学习。在我们的专项课程结构中，本课程如同橡树的枝干，建立在已学习的基础知识之上。

假设你正在开发一个软件产品。你已经识别了产品机会，与潜在用户进行了沟通，定义了出色的需求，规划了整体发布计划，并且开发团队正在设计和实现产品。

那么，一切都在正轨上吗？在敏捷开发中，什么需要改变？

我之前概述过，更好的软件涉及三个目标：正确的产品、正确地完成以及正确地管理。但你如何知道自己是否与这些目标保持一致？又如何提高自己构建正确产品、并以正确方式完成和管理它的能力呢？

对于每一个目标，你都需要从特定类型的评审和度量所获得的持续反馈中，汲取改进的见解。在考虑改进产品本身、底层过程和整体项目时，你需要分析主观和客观数据的混合信息。

实现三个目标的评审与度量

上一节我们提出了软件改进的三个核心目标，本节中我们来看看为每个目标所需的具体实践。

以下是针对“正确的产品”所需的实践：

产品演示：获取早期反馈。
用户研究：观察用户如何使用产品，评估其有效性和效率。
用户满意度数据收集：收集关于用户满意度的数据。
市场成功指标监测：关注产品在市场上初步成功的迹象。

你可以利用所有这些信息来确定项目中需要改进的功能。

现在，针对“正确地完成”（过程），开发人员需要：

工作产品评审与检查：审查他们创建的工作产品，以便及早发现和修复问题。
质量因素监控：监测与重要质量因素（如以缺陷率衡量的正确性）相关的数据。

开发团队利用这些信息来确定在项目实现过程中需要改进什么，以及为了达到期望的质量需要对流程进行哪些调整。

最后，针对“正确地管理”（项目），开发团队需要：

每日站会：每天进行简短会议，同步更新彼此进展。
速率跟踪：跟踪如速率（Velocity） 这样的度量指标。
进度监控与沟通：监控并沟通计划内用户故事和任务的完成情况，让每个人都知道项目状态。

团队应用这些信息来协调工作，并确定如何改进才能更有效地、无浪费地完成工作。

课程结构与内容

本课程涵盖了一系列实践，旨在及早、定期且持续地揭示潜在的产品、过程和项目问题。随着问题的解决，软件会随着每次迭代变得更好。

本课程包含四个模块。

在第一个模块中，Morgan Patriz 将聚焦于“正确的产品”这一目标。她会深入讨论冲刺评审会议，在会上演示和评审产品以获取反馈。然后，她会描述用于观察用户使用产品有效性和效率的用户研究。她还将概述产品成功的示例度量指标，并讨论行业中用于创建成功、设计精良产品的流程。

在第二个模块中，Brad Poette 将聚焦于“正确地完成”（过程）这一目标。他将描述开发人员用于检查和改进其工作的同行评审技术。他将解释度量的目的，以及它们如何解决与产品或过程固有目标相一致的具体问题。他会概述有用软件度量应具备的理想属性，介绍流行的度量指标，并以缺陷相关度量的讨论作为结束。

在第三个模块中，Morgan 将回来聚焦于我们“正确地管理”（项目）的目标。她将描述一种常见的敏捷实践——每日站会，并回顾速率的概念。她会详细说明用于跟踪连续冲刺中已完成用户故事的发布燃尽图。她还将描述任务板和迭代燃尽图，用于跟踪冲刺内任务的完成情况。这些实践有助于发现工作是否半途而废，未能有效完成。

在第四个模块中，Brad 将回来讨论回顾会议。这是一种用于总结经验教训的实践，可以在每次冲刺后或整个项目结束后进行。他将描述项目回顾会议中的各项活动，以识别成功、揭示不足、回顾发生的事件、认可所有贡献者，并产生建设性的经验教训，应用到未来的项目中。

总结

本节课中，我们一起学习了《软件改进的评审与度量》课程的概述。到本课程结束时，你将学会一套有效的反思性实践，用以改进你的产品、过程和项目。这些知识将帮助你创造出优秀的软件产品——即正确的产品，以正确的方式完成和管理。😊

031：课程介绍与核心概念

在本节课中，我们将要学习如何定义、交付和管理正确的软件产品。我们将介绍验证与确认的区别，并引入监控、度量和反馈等核心概念，为后续学习具体的评审方法奠定基础。

核心概念：验证与确认

在之前的课程中，我们介绍了两个关键术语：验证和确认。这两个概念在本课程中将频繁出现，理解它们的区别至关重要。

验证是指软件产品满足所有规定要求的情况。它关注的是“是否正确地构建了产品”。验证通常通过单元测试来完成，这些测试在测试驱动开发中，甚至在编写功能源代码之前就已写好。

代码示例：单元测试（验证）

# 示例：一个验证加法函数是否正确的单元测试
def test_addition():
    assert add(2, 3) == 5  # 验证功能是否按规格工作

确认是指发布的软件产品让客户和/或用户感到满意。它关注的是“是否构建了正确的产品”。确认可以通过向客户频繁演示、保持开放沟通，或进行用户研究、调查和焦点小组讨论来获得。

公式表示：

验证：产品功能 == 规格要求
确认：产品体验 >= 用户/客户期望

简单来说，验证确保你正确地构建产品，而确认确保你构建了正确的产品。本模块的重点是交付正确的产品，因此确认是本模块的一个关键。

引入新概念：监控、度量与反馈

上一节我们介绍了验证与确认，本节中我们来看看在开发过程中用于确保质量的其他核心实践：监控、度量和反馈。

在软件开发中，监控包括在整个开发过程中跟踪、评审和评估产品及流程。监控对于确保你“交付正确的产品、正确地交付并正确地管理”至关重要。敏捷开发强调提高透明度，而各种监控技术使之成为可能。

度量是一种测量事物的方法。在开发中，你可以使用度量来衡量产品、流程和项目的各个方面。度量是一种能产生可量化结果的、有效的监控方式。但请注意：并非所有可被计算的东西都重要，也并非所有重要的东西都可被计算。

监控和度量有助于提供反馈。反馈是提供的信息或批评，用以建议改进或确认你正走在正确的道路上。

以下是反馈在软件开发中的几种形式：

计算结果
用户研究的结果
团队提出的建议
客户的反应

反馈可以是定性或定量的信息。它是识别产品改进方向的绝佳方式。敏捷致力于尽可能频繁地持续改进，这可能意味着改进产品、沟通、流程或所用实践。反馈也可用于其他场景，例如在精益方法中权衡不同方案时，你可以利用反馈来决定哪个选项是正确的。

课程内容预告

现在，我们已经为开始本课程做好了准备。在下一课中，我们将讨论第一种评审类型：冲刺评审。这是你从客户那里获得关于产品确认的关键环节。

本节课中我们一起学习了验证与确认的核心区别，并引入了监控、度量和反馈的概念。理解这些是掌握后续具体评审与度量方法的基础。

032：Sprint评审会议

概述

在本节课中，我们将要学习敏捷开发中的一个关键事件：Sprint评审会议。我们将了解其目的、参与者、流程以及如何有效地利用它来确保交付正确的产品。

敏捷术语回顾

在深入细节之前，我们先回顾一下本课中将使用的敏捷术语。

Sprint评审会议 是一个常见的Scrum事件。
Scrum主管 是负责促进Scrum实践的角色。
产品负责人 是负责产品待办事项列表的角色。
Sprint 指的是迭代周期。

在一个Sprint结束时，会发生两个不同的Scrum事件：Sprint评审会议和Sprint回顾会议。简单来说，Sprint评审会议是展示产品的地方，而Sprint回顾会议是团队重新评估和讨论其流程的地方。

你将在本课程的最后一个模块中学习Sprint回顾会议。Sprint评审会议在Sprint回顾会议之前举行。

Sprint评审会议详情

现在让我们深入了解细节。我们在“软件过程与敏捷实践”课程中关于Scrum的课程里介绍过Scrum事件。Scrum事件贯穿整个开发过程。Sprint、每日站会、Sprint评审会议和Sprint回顾会议都是Scrum事件的例子。

除了Sprint本身，其他Scrum事件都是获取反馈和评估进展的正式机会。所有Scrum事件都是有时间盒限制的，这意味着它们不能超过预定的时间。

为Sprint评审会议建议分配的时间是：Sprint的每一周对应一小时。因此，如果你有两周的Sprint，你应该将Sprint评审会议的时间盒限制在两小时。如果你的Sprint长达一个月，你的Sprint评审会议应该分配四小时。

示例问题：
你正在为你的开发团队安排Sprint评审会议。你的团队刚刚完成了一个为期三周的Sprint，他们渴望展示他们的进展。这个会议最多应该持续多长时间？
A. 一小时
B. 每周结束时一小时
C. 3小时
D. 需要多长时间就多长时间

解答：
你应该将Sprint评审会议的时间盒限制为Sprint的每一周对应一小时。由于你的团队采用三周长的Sprint，你应该为这次会议安排三小时。你的会议不应超过三小时，因此C是正确答案。

会议参与者

现在我们来谈谈谁会被邀请参加Sprint评审会议。答案很简单：任何对产品感兴趣的人都会被邀请。或者用本专业的术语来说，所有利益相关者都被邀请参加会议。

通常，会议将包括Scrum主管、产品负责人、Scrum团队、管理层、一些客户和用户，可能还有其他项目的开发人员。会议旨在非正式进行。这意味着没有幻灯片演示，且准备工作最少。

由于会议的核心是展示产品，唯一需要的准备就是将产品开发成可工作的软件，而这正是开发团队在Sprint期间应该做的事情。这些会议的准备工作很少，因为Sprint评审会议不应该分散开发团队的注意力。

会议中的角色

我们来谈谈Sprint评审会议中的一些角色。如前所述，Scrum主管负责促进会议。这意味着他们要确保会议保持在时间盒内。Scrum主管要确保对话不偏离主题，人们提出相关意见，并且适当地提问和提供反馈。

虽然Scrum主管是促进会议的人，但开发团队通常会主持会议。开发团队中的每个人都应该在会议中有所贡献，因为他们都参与其中。

产品负责人在场是为了批准功能，并确保Scrum团队遵循整体的产品愿景。

其他利益相关者将在会议结束时有机会提出反馈和改进建议。

示例问题：
你是Sprint评审会议上的Scrum主管。当开发团队正在演示产品时，一位利益相关者提出了一个新功能的建议。开发团队、产品负责人和这位利益相关者开始讨论这个新功能。作为Scrum主管，你应该怎么做？
A. 加入讨论
B. 将该功能添加到待办事项列表中
C. 让他们完成讨论
D. 要求他们将功能建议留到会议结束时再提

解答：
作为Scrum主管，你负责促进会议。这意味着要保持会议按计划进行。你应该将功能建议留到会议结束时再提。这允许开发团队完整地演示他们的产品而不受干扰。如果对话开始偏离主题，你应该引导他们回到正轨，否则你就有超出时间盒的风险。因此，D是正确答案。

会议流程

我们来谈谈会议中会发生什么。

Scrum主管应该首先介绍会议的指导原则。这些原则可能包括人们何时可以发言或提出建议等。

之后，Scrum团队应该回顾Sprint目标。重申Sprint目标后，Sprint评审会议中会发生三个主要事件：

产品演示
产品负责人批准
利益相关者反馈

以下是每个环节的详细说明：

1. 产品演示
首先，Scrum团队演示产品。演示应尽可能真实，使用合适的平台。例如，如果团队正在创建移动应用程序，他们应该使用移动设备进行演示。

演示也应该是真实的。这意味着功能不应仅为演示而硬编码。它应该是已完成功能的现场演示。只有当功能满足团队的“完成定义”时，才应进行演示。未完成的功能应留待未来完成后的Sprint评审会议。

例如，产品演示只包括那些已编码、已测试、已文档化、可用且准备发布的功能。

示例问题：
在当前Sprint中，开发团队计划构建四个功能。我们称它们为用户故事A、B、C和D。用户故事A和B满足了团队的“完成定义”。用户故事C已完成且能工作，但尚未经过充分测试。用户故事D离完成还很远，但开发人员可以对其进行硬编码，使其在演示中看起来能工作。开发团队应该在Sprint评审会议上演示哪些用户故事？
A. 用户故事A
B. 用户故事B
C. 用户故事C
D. 用户故事D

解答：
你的开发团队应该只演示那些满足Scrum团队“完成定义”的用户故事。这通常意味着它们已编码、可测试且可用。只有用户故事A和B符合这个标准。用户故事C在演示前仍需测试。这一点很重要，以确保产品功能符合预期。你绝不应为演示而硬编码功能，因此答案A和B是正确的。

2. 产品负责人批准
产品演示之后，产品负责人从产品待办事项列表中批准已完成的功能。一旦产品负责人批准了一个功能，它就会从产品待办事项列表中移除。团队可以选择在会议上完成此操作，或者产品负责人可以在花额外时间评估产品后再批准该功能。

3. 利益相关者反馈
批准之后，Scrum主管向利益相关者开放发言权。这是利益相关者提问、建议功能和提供反馈的机会。

通常，反馈采取以下三种形式之一：

可以是赞扬，表示产品或功能方向正确。
也可以建议需要更改或改进的领域。
或者，反馈可能指出引发新问题或需要重新审视假设的领域。

由于待办事项列表由产品负责人维护和确定优先级，利益相关者可以自由提出他们想要的任意多功能建议。由产品负责人决定是否以及何时开发这些功能。这也是产品负责人可以为待办事项列表建议功能的时候。

我们之前提到过，不应在Sprint中途将建议添加到Sprint待办事项列表中。现在是将他们的建议添加进来的适当时机。

示例问题：
在Sprint评审会议上，你已经进入了第三个阶段，即开放会议以征求建议和反馈。此时谁可以建议额外的功能？
A. 产品负责人
B. 利益相关者
C. 开发团队
D. Scrum主管

解答：
在会议的这个阶段，任何人都可以建议将功能添加到待办事项列表中。产品负责人对待办事项列表进行优先级排序，并选择何时以及是否构建功能。让任何人建议功能都没有坏处，因此答案A、B、C和D都是正确答案。

总结

本节课中，我们一起学习了Sprint评审会议。Sprint评审会议是展示Scrum团队辛勤工作、提高透明度并获得宝贵反馈的绝佳机会。它们也为Scrum团队提供了努力的目标，并鼓励他们生产可工作的软件。

在下一课中，我们将继续讨论交付正确产品的方法。我们将介绍用户研究，以及如何在开发软件产品时使用它们。

033：用户研究 🧑‍💻

在本节课中，我们将学习如何通过用户研究来验证你的软件产品是否真正适合目标用户。

上一节我们讨论了客户需求，本节中我们来看看如何确保产品对用户而言是易用的。为用户打造正确的产品至关重要。如果用户无法使用或不喜欢你的产品，他们就不会使用它。进行用户研究是验证这一点的有效方法。

什么是可用性？

用户研究可以衡量产品的可用性。关于可用性，一个最佳定义来自哥本哈根大学一项关于可用性研究挑战的报告。该报告很好地概述了当今常见的各类可用性研究。

他们将可用性定义为：特定用户在特定环境中达成目标时所表现出的有效性、效率和满意度。

这个定义指出了用户研究的几个关键方面：

首先，它明确了用户研究可以衡量有效性、效率和/或满意度。
其次，它强调研究涉及在特定环境中达成目标。

使用软件产品就是为了达成目标。即使不像游戏产品那样目标明显，每个产品也有其预期用途或目标。

用户研究能发现什么？

以下是用户研究可能揭示的几类问题：

用户是否以预期方式达成了指定目标？
用户是否以非预期方式使用产品来达成目标，或达成了全新的目标？
如果用户未按预期方式使用产品或达成预期目标，原因是什么？是用户界面的问题，还是产品能解决一个全新的、可能更好的问题？

定义还强调了“特定用户”和“特定环境”。为研究选择正确的用户，并控制环境和测试方法，这两点都非常重要。

互动思考

你正在为你的产品进行一项用户研究。在研究中，你给受试者一个要达成的目标。然后你观察用户如何与产品交互，同时记录他们达成目标所需的时间和点击次数。

这项用户研究衡量了哪些因素？
A. 有效性
B. 效率
C. 满意度

这项研究只衡量了有效性和效率。因此，A和B是正确答案。有效性通过受试者是否达成目标来衡量。效率通过达成目标所需的时间和点击次数来衡量。

如果你想衡量满意度，可以在用户使用产品后进行访谈，询问他们是否喜欢该产品，或者对正确达成目标的自信程度。

如何进行用户研究？

用户研究有几种常见的进行方式：

目标导向测试：一种常见方式是让测试参与者在专家观察和记录下使用产品。有时会为用户提供他们试图达成的目标。当用户有特定目标时，用户研究可以验证产品是否允许用户达成该目标，并揭示应用中可能阻碍用户达成目标的部分。
自由探索测试：另一种类型是要求用户按自己的感觉使用产品。在这种研究中，用户通常被要求“边做边想”。通过这种研究，你可以确定产品自然鼓励用户做什么。这与产品的预期目标不同吗？你甚至可能发现产品如何被用于不同的目的。
情境访谈/观察：另一种用户研究是观察你的用户，看看他们的典型一天是怎样的。他们完成什么任务？是否有产品能让这变得更容易？这类研究可能引导你开发出真正适合用户的创新产品。
A/B测试：测试产品的另一种方法是A/B测试。在A/B测试中，你将产品的两个版本相互比较。通常，这是通过发布两个非常相似、仅一个功能有变化的产品来实现的。然后，你将获得关于新功能产品与旧产品相比表现如何的可量化结果。

关于A/B测试的思考

你正在为一家在线购物公司进行A/B测试。该公司的在线邮件列表有1000名订阅者。你向其中500名订阅者发送一个版本的电子邮件，向另外500名订阅者发送另一个版本的电子邮件。每个版本的电子邮件都有不同的优惠券代码。一周后，你检查网站统计数据，查看每张优惠券被使用了多少次。

第一个版本的电子邮件对应有10人使用了优惠券代码。
第二个版本的电子邮件带来了15次优惠券代码使用。

你能从这次A/B测试中得出什么结论？
A. 你有可量化的结果表明第一个版本的电子邮件更有效。
B. 你有定性的结果表明第一个版本的电子邮件更有效。
C. 你有可量化的结果表明第二个版本的电子邮件更有效。
D. 你有定性的结果表明第二个版本的电子邮件更有效。

这次A/B测试提供了可量化的结果，因为我们有可以用统计分析的数字。结果显示，第二个版本的电子邮件比第一个版本带来了更多的优惠券销售。因此，C是正确答案。

可用性指标与参与者选择

用户研究也可以选择应用可量化的可用性指标。例如，这类指标可以衡量用户完成任务所需的时间、页面点击次数以及被点击最多的按钮和元素。这类指标比产品满意度更少主观性。但这是否意味着它们不那么重要？正如之前提到的，满意度通常不是有效和高效产品的直接结果，尽管那会有所帮助。

在用户研究中，你应该仔细选择研究中的参与者，即你的“特定用户”。你需要确保选择的人能代表你的目标受众。你希望你的特定用户与你实际期望使用产品的人具有相似的特征，例如他们的背景或计算机技能水平。

例如，你不希望让开发人员作为针对幼儿产品研究的参与者。同样，尽管让朋友和家人试用你的产品很容易，但你需要确保他们给你的是无偏见的反馈，而不是仅仅告诉你你想听的话。

实践建议

如果你想亲眼看看用户研究是如何进行的，可以报名参加一个。大多数科技公司都会进行用户研究并且需要参与者。找一家当地的科技公司，看看你是否能成为用户研究的一部分。你不仅能获得第一手经验，也在帮助当地的科技生态。

测试产品可用性的方法还有很多，我们将在课程讨论中探讨其他方式。

总结

在本节课中，我们一起学习了用户研究的概念及其在验证产品对用户适用性中的核心作用。我们了解了可用性的定义（有效性、效率、满意度），探讨了不同类型的用户研究（如目标测试、自由探索、A/B测试），并强调了选择正确研究参与者的重要性。下一模块，我们将通过一些行业案例，看看他们如何验证自己是否为用户打造了正确的产品。

034：行业案例

在本节课中，我们将学习几家主要公司如何生产正确产品的行业案例。之后，我们将了解高效产品经理需要关注的其他领域。

🍎 苹果公司的原型设计方法

首先，我们从一个以持续交付正确产品而闻名的公司开始：苹果公司。苹果以其优雅的产品而闻名。他们是如何持续交付正确产品的呢？

当一个想法形成后，苹果从原型设计开始。苹果的原型设计通常被称为“像素完美”原型设计，或“10到3到1”原型设计。

他们最终的、接近成品的原型是像素完美的，因为设计精确到了每一个单独的像素。这意味着他们不仅设计界面，而且设计到了最高级别的细节——像素。可以想象，这种做法成本相当高，并且不太敏捷。但它似乎很有效。

“10到3到1”原型设计之所以得名，是因为设计师开发原型的方式。设计师不受限制地工作，提出10个不同的原型。这非常类似于精益开发，即在做出决定前探索多个原型。然后，他们会选择三个最佳设计并进一步探索这些选项。最后，他们会选择最有力的竞争者，并将该原型设计到像素完美的级别。

苹果还进行定期评审。他们每周举行一次高管团队评审会，审查生产过程。他们还有同行设计会议。这是设计团队和工程师之间的会议，专注于改进设计。

苹果的设计过程非常广泛，因此成本也很高。但正如你在市场上所见，它是有效的。苹果产品多年来主导市场，因此精心设计工作的花费似乎是值得的。

问题：为什么苹果的原型设计方法被称为“像素完美”？
A. 因为苹果产品中的像素总是完美的。
B. 因为原型设计确保产品中的所有像素都是完美的。
C. 因为原型设计精确到了单个像素的级别。
D. 因为这听起来很酷。

答案： 苹果将其一种原型设计方法称为“像素完美”，是因为原型设计达到了最高级别的细节——像素。因此，C是正确答案。

🔍 谷歌的设计冲刺流程

现在，我们来谈谈软件产品和服务领域的另一个巨头：谷歌。谷歌创建了他们的“设计冲刺”流程。这个流程也被其他公司使用，如爱彼迎和蓝瓶咖啡。

这个过程快速且迭代，将过去需要数周或数月的时间压缩到一周，有时甚至更短。谷歌眼镜就是使用这个过程在不到两小时内完成原型设计的。这类似于“尽可能快地交付”的精益原则。

设计冲刺包含五个阶段：

理解：工程师和设计师评估当前问题，并确定为谁设计。
发散：鼓励参与者为问题想出尽可能多的解决方案，无论它们看起来多么不现实或牵强。
决定：参与者投票并讨论要更详细地追求哪个或哪些想法。
原型：参与者快速绘制草图并构建原型。这些原型侧重于用户界面和用户体验。
验证：将产品交给用户，鼓励设计师和工程师进行演示，然后接收用户的反馈。

这个过程的每个阶段都旨在各用一天完成。

问题：设计冲刺的五个阶段是什么？
A. 理解、发散、决定、原型、验证。
B. 评估、头脑风暴、投票、创建、测试。
C. 理解、头脑风暴、决定、原型、测试。
D. 评估、头脑风暴、决定、原型、测试。

答案： 设计冲刺的五个阶段是理解、发散、决定、原型和验证。因此，A是正确答案。

🏠 Intuit的“跟我回家”方法

既然我们已经讨论了一些大公司如何设计正确的产品，现在让我们看看另一家大公司如何验证其产品确实是正确的产品。Intuit使用一种名为“跟我回家”的方法。

Intuit是一家制作会计软件的公司。其创始人斯科特·库克在公司早期就开始了“跟我回家”的实践。库克会去当地的办公用品商店闲逛，等待有人购买他的软件。然后，他会询问顾客是否可以跟随他们回家，观察他们安装和使用软件的过程。这种做法听起来有点令人不安，但很有效。它让Intuit能够构建真正适应用户环境并完全满足其需求的产品。

Intuit现在继续以更可控的方式使用这种做法。平均每年大约进行20次访问。每次访问大约持续一小时。在访问期间，他们观察客户使用软件的情况。他们还会记录客户的工作环境、办公室的工作方式以及软件如何融入业务。

问题：“跟我回家”方法提供什么？
A. 验证（Verification）
B. 确认（Validation）

答案： “跟我回家”方法提供的是对产品的确认（Validation）。它测试用户的满意度，而不是测试特定功能是否按预期工作。因此，B是正确答案。

💡 IBM的设计思维实践

IBM实施了一种名为“设计思维”的实践，它结合了原型设计、用户观察和敏捷开发。设计思维是斯坦福大学开发的一个概念，后来被IBM采用并调整以适应其需求。设计思维专注于识别人们的需求并提出满足这些需求的解决方案。

传统设计思维有四个主要阶段：理解、探索、原型和评估。IBM对此进行了调整，增加了三个阶段：赞助用户、山丘和回放。

这个过程从最终用户开始。你需要找出用户需求未得到满足的原因。为了理解用户需求，你需要找出实际的用户是谁，并发现他们如何思考、看到什么、如何使用产品以及用产品做什么。

然后，他们寻找对产品感兴趣的候选人。他们将其缩小到一个候选人，该候选人具备典型用户的许多特征并面临许多相同的问题。这就是赞助用户。随着产品的发展，他们被用来提供见解。

团队与赞助用户合作以获得见解和信息。他们利用这些来识别产品的一个问题。这个挑战就是“山丘陈述”。然后，他们将这个问题带给更大的团队以提出解决方案。团队随后探索针对该挑战的各种解决方案。剔除糟糕或不切实际的想法。

一旦解决方案范围缩小，他们就开始为这些解决方案绘制草图。然后，他们更正式地对想法进行原型设计。可能需要几次迭代才能确定要追求的最佳想法。这些被称为“回放”。

最终，创建一个工作模型，并与最终用户一起进行评估。这个想法会根据赞助用户的反馈进行迭代完善。完善后，产品发布，但会根据新的用户需求持续测试和完善。

📝 总结

本节课中，我们一起学习了四家主要公司用于确保产品正确性的不同方法：

苹果公司采用像素完美和10到3到1的详细原型设计流程，并通过定期评审确保质量。
谷歌公司使用快速迭代的设计冲刺流程，在短时间内完成从理解问题到验证解决方案的全过程。
Intuit通过“跟我回家” 方法进行产品确认，深入用户环境获取真实反馈。
IBM将设计思维与敏捷开发结合，通过赞助用户、山丘陈述和回放等阶段，系统地识别需求并迭代解决方案。

这些案例展示了在产品管理中，结合深入的用户理解、快速迭代的原型设计和持续的验证反馈，是交付成功产品的关键。

035：行业案例访谈

在本节课中，我们将通过一位行业专家的访谈，学习产品经理如何运用产品战略、生命周期管理和市场情报来打造成功的产品。我们将了解产品经理的核心职责、所需技能以及衡量产品成功的关键方法。

产品经理的核心职责

产品经理需要深入理解软件开发生命周期。其核心职责围绕三大支柱展开：产品战略、产品开发以及产品如何触达消费者（即产品分发）。

上一节我们介绍了行业巨头如何交付正确的产品，本节中我们来看看产品经理如何运用这些支柱来识别并实现正确的产品。

我的名字是Clon Costa，我是视频游戏行业的制作人，其角色等同于产品经理。

作为产品经理，我需要负责产品的三大支柱：

一是产品战略。我需要真正理解产品的愿景应该是什么，并确保团队理解它。
二是产品本身的开发。
三是产品如何触达消费者，即产品的分发。

产品经理的关键技能

软件产品经理需要具备出色的沟通能力。他们还需要深刻理解市场趋势和竞争对手的优势。因此，你需要非常擅长了解市场现状，同时也需要非常精通如何创造软件。你对如何创造软件理解得越深，就越能帮助团队实现之前设定的产品愿景。最后但同样重要的是，你还需要理解产品的商业层面，例如你将采用何种商业模式，以及最终如何触达消费者——是通过数字分发还是零售。所有这些能力的结合，造就了一名优秀的软件产品经理。

市场情报

市场情报是指理解市场现状的能力：你的消费者是谁？你的受众是谁？你和消费者之间是否有零售商（他们也可能成为你的客户）？当前市场在技术、分销或商业模式等方面有何趋势？同时，它也是你理解市场需求的能力：当前市场是否存在空白，尚未有人满足？你能否触及那个空白并比其他人做得更好？这就是我所说的市场情报。

我认为这需要大量的研究。你必须投入精力去理解市场，所以你需要大量阅读。在软件开发领域，你还需要去玩或使用其他软件，以便理解竞争对手的优势。你还需要阅读与你领域（对我来说是电子游戏）相关的杂志、博客或网站。此外，你还需要理解如何触达消费者。如今，你可以通过社交媒体直接联系消费者，询问他们在特定产品中寻找什么，或者他们认为某个竞争对手好在哪里、不好在哪里，从而让你可以去填补市场空白。

你必须大量使用市场上现有的软件。你需要非常了解自己的软件，需要非常注重细节，深刻理解你的软件为市场提供了什么。但同时，你也需要对所有竞争对手做同样的事情。此外，你还需要与消费者直接沟通。这可能是焦点小组，也可能是使用社交媒体。你需要理解是否存在市场空白，是否出现了不同的需求，或者市场领导者是否存在你可以弥补并做得更好的弱点。

用户画像与产品战略

在人口统计方面，我们通常的做法是考虑原型和用户画像。你会尝试理解特定细分受众，并为每个细分创建用户画像。以视频游戏开发为例，我们拥有非常广泛的受众，需要理解我们拥有的细分市场，然后为每个细分市场创建用户画像。例如，这可能是一个20岁、21岁的医学生，他想玩电子游戏，因为这对他是一种逃避。另一个可能是娱乐人士或有空闲时间的妈妈。你需要创建这些用户画像，一旦有了这些画像，你就能看到你软件的功能如何与这些画像对齐，是否真正满足了这些画像的需求。

产品战略首先是理解你需要构建什么的能力。你的软件必须具备什么才能击败市场上的竞争对手？这是产品战略需要做的事情之一。另一件你需要理解的事情是，你需要为你的产品设计商业模式。你将如何销售你的软件？是订阅制、一次性付费，还是某种免费软件（30天后销售软件的另一部分）？商业模式多种多样，这真的取决于你的市场、你的竞争对手以及你正在做的事情。所以你需要理解你需要构建什么、你将如何销售它，以及你将如何实际触达消费者、如何进行分发。

产品经理需要创造愿景。他需要成为消费者和开发团队之间的桥梁。他需要创造那个愿景，以一种非常简洁、简单的方式告诉团队他们需要构建什么，以及为什么这很重要，为什么这足以击败市场上所有的竞争对手。

你的产品愿景可以包含我们所说的独特卖点。假设你有五个独特卖点，希望你的产品能有强大的功能来支撑这些支柱。一旦你有了软件的原型，或者已经有了测试版或Alpha版，你就可以创建焦点小组。你可以触达特定的用户群体，实际测试他们如何接受你的软件：他们喜欢这个新功能吗？它足够有吸引力吗？它比市场上的产品更好吗？这是一种方法。你可以获得反馈，如果存在摩擦点，例如，你可以减少摩擦点，改进功能，然后再次推向市场。如果你在整个开发周期中持续这样做，那么在周期结束时，你应该会有一个更强大的产品发布。

我认为将你的产品与市场上其他产品区分开来的第一步，是理解你自己的优势和劣势。以我们公司为例，我们在某些领域拥有其他竞争对手没有的优势，我们努力强调这些优势。我们努力确保我们的产品带有我们公司的印记，让消费者知道这是我们公司的产品。

基本上，首先要理解你的优势和劣势，同时也要理解它们如何与市场需求相关联。因为如果你在某个市场并不真正需要的领域非常强大，那对你没有帮助。但如果这里存在市场空白，存在市场需求，而你恰好在这方面很强，那么这就是你可以有所作为的地方。

商业模式与生命周期

软件产品的盈利模式现在有很多种，而且市场变化相当快。你可以采用传统的零售模式，在商店销售盒装产品；可以采用数字分发，用户只需下载你的软件；可以采用订阅制，就像现在很多软件做的那样；也可以采用混合模式，比如提供某种免费版本，消费者可以免费下载，但如果想要高级功能，则需要订阅、支付全价或为产品的部分功能支付不同的价格。所以现在桌面上有很多不同的商业模式，这真的取决于你试图进入的市场，取决于你特定市场的消费者。

在初创公司，产品经理拥有更大的灵活性，他必须身兼多职。通常他没有很多资金，但他有一个小而精悍、可以快速迭代的团队。我认为这对初创公司的产品经理来说是积极的一面。但你需要非常执着和有韧性，因为事情不会容易，因为你的团队很小，资源通常也很有限。在大公司，你拥有更多可用资源的优势，可以进行更好或更广泛的研究、不同类型的调查，甚至可以专门前往世界上有消费者的特定地点与他们交谈。但同时，你可能需要通过更冗长的流程来完成事情，有时需要协调组织内的许多不同团队。因此，对产品经理来说可能更困难，因为他需要说服更多的人才能完成某件事。

一个常见的软件产品生命周期会包括：

预生产阶段：在这个阶段，你需要理解你的产品需要成为什么样子（不同行业可能称之为构思阶段）。你需要理解你需要构建什么，以及为什么这个产品比市场上的更好。这是你设定愿景、让团队围绕一个足以击败市场上所有人的愿景达成一致的阶段。你还需要确保在预生产阶段有足够的资金，并尝试迭代和创建原型，以尽快验证你设想的功能是否真的如你预期的那样强大。
生产阶段：在预生产阶段之后，进入生产阶段。这时你已经知道需要构建什么，现在就是关于构建它、扩大规模，并确保在预算或时间等约束下完成一切。
最终阶段：开发出产品后，进入我们所谓的最终阶段。在这个阶段，我们尽可能地对产品进行打磨。我们会尝试修复所有漏洞，甚至可能发布一个测试版软件给成千上万的消费者，让他们使用我们的软件，然后反馈给我们哪些地方运行良好，哪些地方有问题，他们喜欢什么，不喜欢什么，以便我们在软件正式发布前进行修复。
发布阶段：最终阶段之后是发布阶段。在这个阶段，你需要分发你的软件，让软件实际触达你的消费者。如果你有数字分发和零售商，要确保一切正常运作，消费者知道这个软件，并且有办法购买它。
运营服务阶段：发布阶段之后，在我们特定的案例中，有一个我们称之为“运营服务”的阶段。这意味着我们必须为软件发布后的所有工作制定路线图，可能包括修复漏洞的补丁，也可能包括带有新功能的软件扩展，因为我们从消费者和游戏记者那里收到了反馈。一旦获得反馈，我们会根据现有团队对需要做的事情进行优先级排序，然后制定路线图，产品经理领导这个路线图的制定。

发布后的工作与成功度量

产品发布后，你需要理解的第一件事是你的产品如何被消费者接受。你必须快速分析从消费者角度看，哪些方面做得很好，哪些方面出了问题。有些问题，你可能能够通过软件补丁来修复，或者可能需要快速添加一个功能，从而为你的产品创建一个扩展和更新。另一件你需要做的事情取决于你的产品是否也变成一项服务。如果是一项服务，你需要与消费者保持持续沟通，了解哪些方面进展顺利，他们不喜欢什么，以便他们能帮助你为产品制定更好的长期路线图。

衡量软件产品成功的方法有很多种，这真的取决于你的行业。你可能关注销售数量、收入、利润率，也可能是产品质量（根据行业不同，可能有某种评分来衡量和比较你的软件与其他软件）。但通常，最终都会回到消费者满意度上。我的意思是，你需要理解消费者如何接受你的软件。一个好的产品经理需要非常精通分析，知道如何利用软件的遥测数据来获取关于需要更改事项的重要数据。通常，一个好的产品经理会首先尝试创建关键绩效指标（我们称之为KPI）。一旦你有了KPI（这真的取决于你所在的行业），你就可以开始衡量你的软件是否成功。

在内部，例如对于开发团队，你可能会有诸如每小时崩溃次数、服务器正常运行或停机时间等KPI。另一方面，你可能还有其他指标，比如同时访问服务器的实际人数，即你当前的最高同时在线用户数。有很多不同的指标可以帮助开发团队理解他们的服务或产品是否运行良好。

在外部，还有一些其他因素可以衡量。通常我们有一个称为A-O-E-M的漏斗模型：

A（获客）：我们有诸如实际下载或购买你软件的人数、每天有多少人在玩、你拥有的每日独立用户数等指标。
O（引导）：对于引导，你可能有一些指标，比如用户是否完成了整个教程流程，他们是否中途停止。
E（参与）：在参与度方面，你有用户每天使用你软件的会话次数、他们使用你软件的时长。我们还有其他参与度指标，比如他们是否可能向朋友推荐你的软件（我们称之为NPS净推荐值）。
M（盈利）：在盈利方面，我们有关于他们每天或生命周期内总共花费多少钱的指标，即用户生命周期价值。例如，如果用户最初在产品上花了60美元，在整个生命周期内又花了20美元，那么他就值80美元。还有每付费用户的平均收入、每用户的平均收入、付费用户的比例等。有很多不同的KPI来衡量盈利。

在分析方面，你可以利用这些信息来查看这些用户是否成功。例如，那些完成了完整引导流程的用户和那些跳过了教程的用户相比，是否遇到了更多问题？他们是否更频繁地联系客服，因为他们不知道如何使用软件？你可能会发现，那些完成了教程的用户实际上掌握了软件的关键基础知识，因此需要更少的帮助。

成功产品与产品经理的特质

我认为一个成功的产品背后需要一位成功的产品经理。这意味着你需要一个人来充当所有消费者（你拥有的数百万消费者）和开发团队之间的重要桥梁。这个人不仅要做这个桥梁，还要从商业角度理解你将采用何种商业模式、如何分发你的软件、如何触达你所有的消费者。你需要在三大支柱上做得非常好：商业模型方面、市场理解方面以及开发流程方面。如果一个好的产品经理能在这三大支柱上都做得很好，他很可能会成功。

我认为对于新产品经理来说，他们需要做的第一件事是对软件、对你试图开发的产品充满热情。如果你热爱你所做的事情，你成功的几率会高得多。这是第一点。第二点是保持非常好奇。你需要非常好奇，需要努力理解市场现状，需要尽可能多地使用竞争对手的软件，内心需要保持那种好奇心。同时，你需要问为什么：他们为什么那样做？为什么我们不能这样做？或者为什么我们不能做得更好？我认为这是一点。另一点当然是，你需要大量学习。无论你的市场是什么，你都需要大量研究你的市场，真正理解你的市场如何运作。最后，我认为对产品经理来说，知道如何与人相处也超级重要。你不是独自制造软件或产品，你有一个团队，你需要知道如何与团队以及团队内的不同小组良好沟通。你如何确保每个人都在同一个愿景、同一个目标下保持一致？

总结

在本节课中，我们一起学习了产品经理在打造成功产品中的核心作用。我们探讨了产品经理需要具备的三大支柱能力：产品战略、市场情报和生命周期管理。我们了解了如何通过用户画像理解受众，如何制定产品愿景和独特卖点，以及软件产品从预生产到运营服务的完整生命周期。最后，我们学习了如何通过A-O-E-M漏斗模型和KPI来度量产品的成功，并认识到好奇心、学习能力和人际沟通能力是优秀产品经理的关键特质。

在下一个模块中，你将学习如何确保你的产品“做得对”。Bradley将带你了解一些监控技术和指标，你可以用它们来确保你的产品是正确的。

036：评审技术 🧐

在本节中，我们将学习如何确保软件产品被正确地构建。我们将重点介绍几种用于检查软件开发过程中产出的工作产品的评审技术。这些技术能帮助团队更早地发现缺陷，从而避免在后期修复时付出更高的成本。

回想一下冲刺评审会议。在那些会议中，开发团队与客户一起审查上一个冲刺周期完成的工作，并确保项目进展符合预期。本节我们将聚焦于开发团队内部进行的评审，具体讨论不同类型的同行评审。同行指的是在同一级别工作的人员，例如两位开发者互为同行。

软件走查 🚶‍♂️

最不正式的同行评审是软件走查。

软件走查简单来说，就是一位软件开发者向他人展示代码如何工作。这是一种“展示与讲述”的形式，开发者向一小部分听众介绍自己的代码。在整个走查过程中，听众可以随时提问并指出潜在问题。

走查之所以是非正式的，是因为它旨在为开发者提供一种快速、简便的方法来帮助他们提高软件质量。

以下是软件走查的一个例子：一位开发者刚刚构建了一个软件模块，该模块通过连接公司的客户数据库并提取客户的支付信息，来授权客户的付款。构建完此功能后，该开发者邀请了几位同行，询问是否可以快速进行一次代码走查。大家聚集在这位开发者的电脑周围，开发者带领他们浏览代码，并跳过了许多次要细节。在代码评审过程中，开发者的同行会提出诸如“用于访问数据库的库是否可靠”、“当前代码是否是资源效率最高的选择”以及“代码是否足够安全可以发布给公众”等问题。同行们还会帮助确保代码的可读性并符合团队的编码标准。此外，通过这个过程，开发者的同行也会更加熟悉这段代码。当他们处理其他项目时，可能会整合从这次走查中获得的知识。正因为这个特点，代码走查也常被用作培训新团队成员的一种手段。

总而言之，软件代码走查是一种有价值的评审技术。它允许个体开发者借助同行的力量，获得建议、改进意见并熟悉代码，而无需花费太多额外的精力。

在软件走查中，软件开发者需要产出以下哪项工作产品？
A. 代码评审总结
B. 需求文档
C. 会议纪要
D. 无

答案：D. 无。 软件走查旨在保持随意性，因此不要求产出任何工作产品。

软件技术评审 🔧

上一节我们了解了非正式的走查，现在让我们看看更正式的评审形式。软件技术评审与走查不同。

软件技术评审更为正式，其目的是处理产品的技术层面。评审的正式程度取决于实施它的组织。例如，一家军事防御承包商的评审过程会比一家开发手机游戏的公司严格得多。本质上，软件技术评审的全部目的是在技术层面改进软件产品。它可以用于创建更健壮的设计、从客户那里形成明确的需求，或对代码进行一系列技术改进。

软件技术评审以讨论为导向，包含三个主要角色：

决策者：其工作被评审的人。负责设定评审目标并判断这些目标是否已达成。
评审负责人：确保评审有序进行并保持在正轨上。
记录员：负责记录所有已识别的问题。这并不意味着他们是会议记录员，记录员是在会议上记录会议发现的人。

在评审开始前，所有参与者都需要进行准备。决策者创建一份希望在会议中达成的目标清单。评审负责人确保每个人都能访问待评审的软件产品。其他所有参与者则负责预先评审分发给他们的材料。

在实际的评审会议中，评审负责人促进所有相关方之间的对话。如果这是一个需求获取会议，评审负责人会确保客户及其产品团队正确地传达需求，并引导会议朝着决策者的目标前进。在需求获取会议的情况下，目标很可能是获得一份用户故事列表，开发团队可以据此规划工作。

在软件技术评审中，一个人可能担任多个角色。例如，评审的贡献者可能同时担任评审负责人。也可能有人既是决策者又是记录员。这完全取决于谁自愿承担什么角色，以及什么对当前情况最合理。

在软件技术评审结束时，应该达成某个特定目标。例如，可能是消除歧义或对当前产品进行改进。技术评审的结果是一套针对软件产品改进的建议。

对于需求或代码的软件技术评审，以下哪项不被视为其可能的结果？
A. 新的软件需求
B. 改进的软件生产过程
C. 提高的代码效率
D. 为高效员工加薪

答案：D. 为高效员工加薪。 虽然软件技术评审可能会提高对员工效率的认识，但其目标并非关注个别团队成员，而是改进产品整体。

总结 📝

在本节中，我们一起学习了两种关键的软件同行评审技术。我们首先介绍了非正式的软件走查，这是一种快速、协作的代码展示与讨论方式，旨在早期发现问题并促进知识共享。接着，我们探讨了更正式的软件技术评审，它通过明确的角色（决策者、评审负责人、记录员）和结构化的流程，专注于在技术层面系统地改进软件产品或需求。理解这两种技术的形式和适用场景，将帮助你在软件产品管理中选择合适的工具，以确保工作产品的质量并推动持续改进。

037：评审技术

在本节课中，我们将要学习软件同行评审的第三种类型——软件审查，并深入了解两种具体的审查技术：需求技术评审和需求审查。我们将探讨它们的结构、角色、流程以及如何应用它们来提升软件产品的质量。

软件审查：最正式的同行评审

上一节我们介绍了软件走查和技术评审，本节中我们来看看最正式的同行评审类型——软件审查。

软件审查，也称为正式技术评审。请注意不要将其与软件技术评审混淆。软件审查比前两种评审类型更为正式。与软件技术评审类似，软件审查也包含多个角色并遵循严格的结构。

软件审查的主要目的是发现并修复工作产品中的缺陷，例如一段代码模块的需求文档。为了实现这一目标，软件审查会利用以下角色：作者、主持人、朗读者、审查员和记录员。与软件技术评审一样，多个角色可以分配给同一个人。

以下是各角色的职责：

作者：创建了被审查软件产品的人。
主持人：类似于软件技术评审中的评审负责人，负责监督审查过程并确保一切顺利进行。
朗读者：负责向审查员朗读文档，审查员随后指出文档中的缺陷。
记录员：负责记录笔记。

软件审查的多个阶段

软件审查由多个阶段组成，其中一些阶段可以重复，直到产品达到适当的标准。

以下是软件审查的主要阶段：

规划阶段：在此阶段，主持人熟悉被审查的产品以及作者关注的主要领域。
概述会议：所有角色人员聚集在一起，由主持人对产品进行简要介绍。通常在此阶段结束时，审查员会收到待审查的产品，从而启动审查的准备阶段。
准备阶段：审查员审查产品以寻找缺陷并做笔记。完成此阶段可能需要几分钟到几天，具体取决于被审查的工作产品。
审查会议：在此会议上，朗读者分小块朗读文档。审查员随后对他们发现的每个块中的缺陷发表评论，记录员确保记录所有内容。作者可以提问和寻求澄清，但由于审查更为严格，不鼓励讨论。
返工阶段：审查会议后，作者根据审查员的反馈进行必要的修改。
跟进阶段：完成修改后，进行跟进以确保更改已完成、恰当，并解决了审查会议中发现的缺陷。

我之前提到，一些审查阶段可以重复。通常重复的阶段是返工和跟进阶段。这是因为有时在返工阶段完成的工作不足以解决审查会议中提出的缺陷。当在跟进阶段指出这一点时，作者必须返回并完成工作。

严格的完成标准

软件审查还实施了严格的程序来确定每个阶段何时完成以及何时准备好进入下一阶段。例如，为了开始审查过程，可能需要一个待办事项清单。

这个清单可能包括：

软件走查已完成。
代码已通过所有测试用例。
每个函数都包含足够的文档。

这样做是为了帮助主持人和审查员在讨论之前正确审查工作产品。

三种评审类型的比较

在我本节课讨论的三种不同类型的同行评审中，哪种结构最严格？A. 软件走查。B. 软件技术评审。C. 软件审查。

答案是 C，软件审查。软件审查是最正式的同行评审类型，其次是软件技术评审，然后是走查。

需求技术评审：一种流行的审查技术

现在，让我们来讨论一种非常流行的软件审查技术：需求技术评审。

需求技术评审是一个两阶段过程。第一阶段是评审，第二阶段是讨论会议。您可以与多个审查员或多次进行此过程。

第一阶段：评审

在评审阶段，评审员检查作者编写的一组需求。作者可能需要向每位评审员提供术语表和其他相关信息源。

每位评审员检查需求文档，以定位尽可能多的缺陷。这可能包括错误或遗漏，这些错误或遗漏会阻止产品执行其一项或多项任务。

每位评审员还应识别需求标准方面的高风险领域。例如，需求似乎不完整、过于僵化或过于浅显而无法处理所有可能发生的情况。

每位评审员还应突出显示任何疑虑。例如，他们可能突出显示一种情况，即需求正确且完整，但在复杂性或可重用性方面可以改进。

然后，每位评审员应将其发现分类为主要、中等或次要的严重性级别。

以下是严重性级别的定义：

主要发现：意味着问题的修复方案不明显，需要非常仔细的进一步探索。
中等发现：意味着问题的修复方案是直接的，但需要进一步审查。
次要发现：表示修复要么不必要，要么显而易见，无需进一步审查。

严重性级别判断练习

假设您正在为另一个团队的需求执行评审阶段。您发现一个问题：他们的一项需求在其预算、时间线和资源范围内不可行。您认为他们将不得不重新考虑整个产品规划。

您会将此问题的严重性级别评为：A. 主要。B. 中等。C. 次要。

这种类型的问题将是主要严重性级别，因为没有明显的解决方案，并且该团队必须仔细审查他们的产品。因此，A 是正确答案。

第二阶段：讨论会议

一旦评审阶段完成，您就进入流程的第二阶段：讨论会议。在此会议中，应有评审员、作者、主持人和记录员。

主持人负责确保会议不偏离主题，并以建设性的方式提出批评。他们确保评审不会让作者感觉受到攻击。Scrum Master 可以主持此会议，类似于他们主持其他会议的方式。

会议也应有记录员。此人可以与项目无关，他们只负责记录会议笔记。作者将参考这些笔记来修复已识别的问题。

为此会议设定时间盒是一个好主意，以便其保持在正轨上，并且不会占用评审员或作者太多时间。

在此会议中，将讨论收集到的发现并可能重新分类。尽可能减少对次要问题的讨论是一个好主意。不期望作者回应提出的每个问题或评论，但记录员应记下所有问题。作者在场主要是为了更好地理解发现并在需要时寻求澄清。这将有助于将会议控制在既定的时间盒内。

后续的修复过程

遵循需求技术评审流程之后是修复过程。在修复过程中，需求作者将根据评审反馈对需求进行调整。他们不需要解决所有建议的更改。提出的一些问题可能无效或已经解决。

我发现这个需求技术评审过程对于确保您的团队拥有高质量的需求非常有帮助。这对于确保产品做对非常有帮助。通过进行评审，您还可以学到很多关于开发和创建良好需求的知识。

需求审查：确保清晰、一致和完整

在结束之前，让我们谈谈需求审查。

需求审查是一个正式过程，在此过程中审查用户故事列表的模糊性、一致性和完整性。模糊性是软件需求的一个大问题，通常让第三方审查您的需求以确保一切清晰是很有用的。

当识别出需求的所有问题后，由作者负责修复它们。通常作者是产品负责人或软件产品经理，也可能包括开发团队的成员。有时作者是客户。在所有这些情况下，在审查会议中提出的缺陷随后得到解决，并在跟进中再次呈现。

需求审查是确保您的需求清晰、一致和完整的有用方法。审查过程使任务直接且易于理解，这可能解释了它在行业中的流行。

总结

在本节课中，我们一起学习了最正式的同行评审——软件审查，了解了其严格的阶段和角色。我们还深入探讨了两种具体的审查技术：需求技术评审（包括其两阶段流程和严重性分类）以及需求审查（专注于消除模糊性、确保一致性和完整性）。

无论上下文如何，软件同行评审都是有用的。无论是非正式的走查、技术评审还是正式的审查，评审在几乎所有软件项目中都有一席之地。

既然我已经介绍了一些如何评审软件的技术，接下来让我们谈谈软件评审过程中一些常见的问题。这就是我将在下一课中要讲的内容。

038：监控项目时需注意的问题

概述

在本节课中，我们将探讨在软件项目中监控进度时需要注意的问题。我们将了解为何某些度量指标可能不适用，以及如何避免使用不良指标。通过理解这些概念，你将能更明智地选择和使用度量指标来改进软件产品和流程。

在上一节课中，我们介绍了几种在软件开发中使用的同行评审技术。

现在，让我们退一步，讨论一些关于监控项目时可能遇到的问题。例如，为何应避免某些度量指标，以及哪些指标对软件项目不利？

你刚刚看到，监控可以通过同行评审（如代码走查）来实现。正如本课程标题所示，这并非监控的唯一方式。软件中有许多度量指标可用于跟踪进度、生产力和质量。速度（Velocity）就是其中之一。

我在上一门课程中简要介绍了如何估算速度，Morgan将在下一个模块中深入探讨如何计算和跟踪它。

实际上，存在很多度量指标，它们各自评估项目的不同方面。然而，在许多软件项目中，这些指标根本未被使用。这是为什么呢？大多数时候，问题在于找到合适的时间来正确编译这些指标。

正如我在关于反模式的课程以及软件项目的敏捷规划课程中所说，开发人员实际用于编码的时间是有限的。这意味着开发人员花在非编码任务（如编译指标）上的任何时间，都会占用他们用于编码的总时间。

为了最大化开发团队在创建产品方面取得的进展，通常首先被跳过的是度量指标。团队构建了一个可靠的产品，早期并迭代地交付给客户，每个人都很高兴。然而，除了那些希望退一步定量分析项目以便及时发现和妥善解决问题的人。

那么，他们为何不愿意这样做呢？为了跨项目比较，采用更行业标准的测量实践难道不合理吗？

或许度量指标最大的问题之一是，开发人员和管理人员在这方面知识严重不足。市面上有很多例子，很难判断哪些真正值得你投入时间。这一点，加上缺乏行业标准，确实让决策变得困难。有些人说要跟踪这个，另一些人说要跟踪那个。该领域的研究往往没有定论或无法推广。它们可能只适用于特定环境或特定组织。最终，每个组织都必须确定什么适合他们的情况。

你能明白为何行业标准如此之少吗？

以下是我提到的软件项目中度量指标未被正确使用的主要原因之一：
A. 资金不足。
B. 可供选择的指标太多。
C. 开发人员或管理人员知识缺乏。
D. 开发人员或管理人员缺乏兴趣。

答案是 C，开发人员和管理人员知识缺乏。经常被指派管理软件项目任务的人，在衡量质量方面没有接受过实质性培训；因此，项目指标要么被误用，要么根本不被使用，这很常见。

行业中一个相对常见的度量指标是代码行数（Lines of Code，简称LOC）。基本上，代码行数跟踪为一段软件编写的代码行数，并使用该数字生成一些数据。这些数据可能包括每行代码的成本，通过将整个项目的成本除以编写的代码行数来计算。另一个可能是单位时间内编写的代码行数，这是一种技术速度测量。

虽然跟踪代码行数作为生产力的衡量标准似乎有道理，但事实并非如此。首先，这个指标不可靠。你在项目某一部分获得的代码行数指标，可能与另一部分获得的指标大相径庭，即使在同一团队内也是如此。这有几个原因。首先，开发人员编写的代码行数很大程度上取决于他们使用的编程语言。对于那些熟悉各种语言的人来说，你们会知道C是一种非常低级的语言，需要编写多得多的显式内容才能实现与Python这样的高级编程语言相同的高级功能。因此，粗略来说，实现相同功能的Python程序可能比C程序少五倍的代码行数。对于不同语言的不同程序，代码行数的度量之间没有真正的可比性。事实上，即使使用同一种语言，代码行数也几乎无法显示产品内部的生产力。这是因为不同的功能可能具有不同的复杂性。如果不考虑这一点，你会发现自己进行了本不应该进行的比较。

这个例子显示了了解为何要进行测量的重要性。代码行数的度量本身就是一个问题，但伴随这种测量常常会产生一个有趣的副作用：开发人员的行为会改变。每当有人得到一个可以用来衡量自己的分数时，他们的自然倾向将是最大化这个分数。考虑到这一点，你能想到代码行数指标的另一个问题吗？

如果开发人员根据他们编写的代码行数来衡量，他们的自然倾向很可能会比不编译该指标时编写更多的代码行数。这种非预期的后果起初可能不是坏事，但如果你的开发人员花更多时间编写这些代码行，生产力很容易下降。了解你在测量什么很重要；这不是关于收集所有你能收集的数据并进行分析。你必须能够评估你在所提供指标的价值与制表所需时间（以及这些指标的其他相关成本）之间所做的权衡。正如社会学家威廉·布鲁斯·卡梅伦所说：“并非所有可计数的东西都重要，也并非所有重要的东西都可计数。”

以下哪项使得每冲刺周期的代码行数成为评估软件生产力的不良指标？
A. 代码行数是衡量已完成工作量的不良指标。
B. 冲刺周期是衡量项目长度的不良指标。
C. 代码大小无法用代码行数衡量。
D. 每冲刺周期的代码行数是评估软件生产力的良好指标。
E. 所有语言中，不同功能的代码行数是相同的。

答案是 A，代码行数是衡量项目规模的不良指标。正如我之前所说，代码行数在不同项目之间可能差异巨大，并不能真正反映开发人员的努力。

评审和度量指标存在问题，但这并不降低它们的价值。事实上，行业中确实需要更多的评审和度量。问题的存在意味着有很大的研究空间。为了改进软件产品和流程，在决定实施任何度量时，保持明智和知情非常重要。

在下一节课中，我将讨论一个帮助你做出明智和知情决策的模型：目标-问题-指标模型（Goal Question Metric model）。我们下节课见。

总结

本节课我们一起学习了在软件项目监控中需要注意的问题。我们探讨了度量指标未被广泛使用的原因，特别是开发人员和管理人员相关知识缺乏的影响。我们重点分析了“代码行数”这一常见指标为何是衡量生产力的不良指标，原因包括其对编程语言的依赖性、无法反映功能复杂性以及可能引发开发人员追求数量而非质量的行为改变。最后，我们认识到，尽管存在挑战，明智地选择和使用度量指标对于改进软件流程至关重要。下一节我们将学习一个帮助进行这种明智选择的框架。

039：目标-问题-度量法 (GQM) 🎯

在本节课中，我们将要学习一种名为“目标-问题-度量法”的框架，它能帮助我们为软件项目选择和制定有效的度量指标，确保我们测量的内容对项目和团队真正有价值。

上一节我们介绍了监控软件项目时可能遇到的一些问题，这些问题主要与度量指标的有效性及其可能被误用有关。本节中，我们来看看如何系统地制定度量指标，以确保它们能衡量对您和团队有价值的项目方面。

什么是GQM？

目标-问题-度量法，简称GQM，是一种为软件项目选择度量指标的方法。它由马里兰大学的维克多·巴希利于1994年提出。

根据巴希利本人的观点，GQM背后的基本思想是：一个组织要有目的地进行度量，就必须首先为自己及其项目设定目标。然后，它必须将这些目标追溯到旨在从操作层面定义这些目标的数据，最后，提供一个框架来解释这些数据与既定目标的关系。

简单来说，为了确保为项目使用了正确的度量指标，您必须首先知道想要度量的概念，即您的目标。明确目标后，您必须找出定义该目标的因素，即您的问题。接着，您需要找到一种方法来计算这个定义，并以一种可以解释的方式，来了解您向目标迈进的进度，这就是您的度量。

GQM的核心流程可以概括为：
目标 (Goal) -> 问题 (Question) -> 度量 (Metric)

如何设定目标？

根据巴希利的理论，目标应用于对象，这些对象是产品、过程和资源。本质上，您可以选择改进这三者之一作为目标。

产品：例如您的代码或文档。
过程：例如您的测试或需求获取过程。
资源：例如您的办公空间、开发团队使用的计算机，或开发人员的投入与薪酬。

核心思想是您可以度量任何事物，但将项目目标分解为这三个类别有助于您思考如何度量它们。

小测验：GQM的目的是什么？
A. 确保您正在构建正确的产品。
B. 确保您有效地使用度量指标。
C. 确保度量指标使用正确的数据。
D. 确保您向客户提出正确的问题。

答案：B

GQM是一个使用度量指标的框架，其重点是确保您使用最佳的度量指标来回答您想了解的关于项目的问题。

从目标到问题

在确定每个目标之后，下一步需要考虑的是您想针对这些目标提出的问题。基本上，您需要提出哪些问题才能告诉您每个目标是否正在实现？

这取决于具体的目标，但总体思路是，您的问题应该足够具体，以便问题的答案能够直接指向目标的达成情况。

从问题到度量

那么，如何找到这些问题的答案呢？这就是度量部分的作用。度量是一种收集数据的定量方式，用以回答您提出的问题。

这与我们在之前课程中讨论的其他度量指标完全相同。GQM中度量指标的特殊之处在于，它们因事先的规划过程而变得更有意义。GQM中的度量指标之所以更有价值，是因为度量指标旨在回答的问题已经过事先的深思熟虑。

度量指标可以是主观的或客观的。

客观度量：基于不依赖任何个人观点或解释的数据。例如：
- 产品下载次数
- 销售数据
- 处理时间
- 完成的用户故事数量
主观度量：依赖于解释。例如：
- 用户的产品评分
- 开发人员的士气
- 代码质量

如果您将度量指标比作软件，这很像我们在“客户需求与软件需求”课程中讨论的“收集需求”与“获取需求”的区别。您不希望盲目地开始收集度量指标。就像从客户那里获取需求很重要一样，事先明确度量指标的目标也同样重要。

当然，一旦有了用户故事，您也不会直接开始构建它们，而是先创建开发任务——那些可以在几小时内完成的小型、可执行项。GQM中的问题也是如此，您创建小的项目，当它们组合在一起时，就能解决整个目标。

只有在您通过发布和迭代计划提前规划好工作后，才会进入代码开发阶段。同样，只有在您通过具体问题提前定义了度量指标的目标后，才会进入实际实施度量指标和收集数据的阶段。

小测验：GQM代表什么？
A. 目标-问题-测量
B. 收益-问题-测量
C. 目标-问题-度量
D. 收益-问题-度量

答案：C

GQM应用示例

让我们看一个GQM的例子。假设您正在开发一个软件产品，并且想知道您的产品是否“做得正确”。那么，产品质量就是您的目标。

以下是一些可以帮助您解决这个目标的问题：

我的产品代码有多少被单元测试覆盖？
我的产品中有多少缺陷？

提出问题后，下一步是确定您的度量指标。

以“我的产品中有多少缺陷？”这个问题为例，我们可以通过几种方式来处理。

一种度量指标可以是：在验收测试中，一个用户故事在被最终接受之前被拒绝的次数。这可以表示为整个项目中拒绝次数与接受次数的百分比。

您可以认为，较高的拒绝/接受比率表明您的流程中某些环节需要改变，以减少缺陷。要知道什么是“较高”的比率，您可能需要比较在成功项目与不成功项目中这个数字的差异。

另一种解决此问题的度量指标是：在任何给定时间，产品待办事项列表中存在的缺陷数量。如果您发现待办事项列表中的缺陷激增，这可能表明您需要审查技术，以便更早地发现缺陷。

当然，您可以制定比这复杂得多的度量指标。这里的例子只是为了让您了解度量指标如何在GQM范式中应用。

在本节课中，我们一起学习了目标-问题-度量法。我们了解到，GQM是一个系统的框架，通过首先定义清晰的目标，然后推导出具体的问题，最后设计可量化的度量指标，来确保我们为软件项目收集的数据是相关且有意义的。这种方法有助于避免盲目度量，使团队能够专注于对项目成功至关重要的方面。

040：理想度量指标的特性 📊

概述

在本节课中，我们将学习软件度量中的关键术语，并探讨理想度量指标应具备的特性。我们将通过对比好坏度量指标的实例，帮助你理解如何选择和使用有效的度量指标来改进软件项目。

关键术语定义

上一节我们介绍了目标-问题-度量范式，本节中我们来看看软件度量中的几个基础概念。为了整体理解软件度量，你必须首先理解三个关键术语：度量元、度量指标和指示器。

度量元 是一个测量标准或单位。它本质上是测量的一个实例。例如，英寸是一个度量元，因为英寸是标准的测量单位。这意味着如果你比较一英寸与另一英寸，它们是完全相同的。这看似简单，但确保测量的一致性对于获得有意义的度量指标至关重要。

度量指标 是两个或更多度量元的组合，能产生有意义的结果。一个例子是公里每小时。公里是你的第一个度量元，小时是第二个。当它们结合时，就创造了有意义的东西。然而，并非所有度量指标都有意义。例如，你可以测量开发人员每小时击键次数，但这未必能告诉你关于项目的任何有意义信息。

指示器 是能引起测量者注意的度量元。一个很好的例子是测量某人的口腔温度。一个人健康状况良好的指示器是其口腔温度在36.5至37摄氏度之间。如果你测量某人的口腔温度读数为38度，这就是他们发烧的指示器。没有这些值作为指示器，你无法仅凭温度判断某人是否发烧。指示器让你更容易知道你的度量元或度量指标何时在告诉你需要注意的事情。

小测验

问题：39摄氏度每小时，是度量元、度量指标还是指示器？
A. 度量元
B. 度量指标
C. 指示器

答案：B，它是一个度量指标。39摄氏度和小时都是度量元，但当它们结合时，就创造了一个度量指标。

现在你知道了度量元、度量指标和指示器之间的区别。

度量指标的理想特性

收集和分析数据以洞察产品是常见任务。正如上一节关于GQM所说，你不应在没有明确目标的情况下使用度量指标。同样重要的是，你应使用你知道能提供可信结果的度量指标。这就是为什么了解度量指标的理想品质很重要。

让我们回到测量开发人员每小时击键次数的例子。是什么使这个度量指标在软件项目中如此糟糕？

首先，击键与软件创建有什么关系？有人可能认为跟踪开发人员的击键可以让他们跟踪在任何一天写了多少代码。然而，就像代码行数度量指标在不同编程语言和开发人员之间可能有很大差异一样，这种击键方法也是如此。这本身就是一个问题。

考虑如何记录击键。例如，如果你在电脑上使用击键记录程序，你怎么知道记录的击键实际上是正在编写的代码？你的开发人员可能在做其他事情，比如在在线聊天论坛打字，或者写他们过去两年一直试图完成的小说。

显然，选择正确的度量指标很重要，而其中一部分意味着选择一个能真正回答你想问问题的度量指标。

那么，度量指标应具备哪些理想特性呢？以下是理想度量指标的特性列表：

简单且易于计算：度量指标应简单且易于计算。主要原因在于，度量指标越复杂，使用它的人犯错误的可能性就越大。如果你使用的度量指标过于复杂，一个在简单公式中容易识别的小错误，当你意识到有问题时，可能会变成追踪的噩梦。
直观且有说服力：度量指标应具有直观说服力。如果你计算了度量指标，把它带给团队中的某个人，并请他们告诉你它的含义，它应该对他们有意义。这并不是说你只应使用简单的度量指标，但它应该具有直观的使用意义。每小时击键数就是一个很好的例子，你可以计算它并向任何人说明，但归根结底，跟踪开发人员的击键并没有太多直观意义。
客观：度量指标应该是客观的。这意味着它们不依赖于任何人的意见，而是基于经验数据。这对任何科学都至关重要，监控项目的科学也不例外。一个例子是使用开发人员对自己生产力的估计来跟踪开发人员生产力。很难从中获得准确的客观度量，因为你的数据来源本身就有偏见。一个更好的方法是测量他们在给定时间内完成了多少工作，例如使用故事点。
单位和维度使用一致：度量指标在单位和维度的使用上应保持一致。如果你使用故事点作为项目速度的度量指标，那么你需要对故事点的定义保持一致。如果你在项目中途将某些用户故事的故事点估计值翻倍，你将无法从速度度量中获得太多信息。保持你所测量事物的稳定、一致定义很重要。否则，你可能会处理一个难以解释甚至完全无法使用的度量指标。
编程语言无关：你希望使用的任何度量指标都与编程语言无关。正如之前所说，代码行数度量指标就是一个很好的反面例子。虽然它似乎是衡量软件项目完成工作量的直观度量，但实际上这个度量指标相当具有误导性。更重要的是，不同的编程语言在实现特定功能所需的代码行数上差异很大。为了保持一致性，你的度量指标应该能够提供可靠的度量，可以在不同编程语言之间进行比较。
提供改进软件质量的有效机制：度量指标应能让你有能力改进软件项目或过程的质量。你不是为了跟踪数字而跟踪数字。你需要做的是为了改进项目而跟踪数字。如果你改进了项目，你的度量指标能够显示这些改进吗？以每小时击键数为例，如果你试图通过让开发人员击键更多来改进项目，你认为会发生什么？更糟糕的是，如果你的开发人员实际上是更高效的程序员，他们击键的次数实际上可能会减少，因为代码所需的字符远少于用自然语言写东西。最好使用一个能在取得进展时显示进度的度量指标。重要的是，一个好的度量指标也能显示你所测量事物的质量是否在下降。

小测验

问题：以下哪项是度量指标的理想特性？
A. 基于主观数据
B. 适用于人力资源问题
C. 对任何数据给出相同的数字
D. 直观

正确答案是 D，度量指标应该是直观的。如果不直观，你使用的度量指标可能不会对改进有多大帮助。

好度量指标与坏度量指标示例

一个好度量指标的例子是每周在产品中发现的缺陷数量。

为了计算这个指标，你只需要跟踪以错误报告或记录问题形式报告的新缺陷数量，并在每周结束时制成表格。

计算这个度量指标简单易行。缺陷在任何软件项目中显然都是坏事，减少产品中的缺陷数量是人们公认的理想目标。这个度量指标也相当直观。假设你的开发人员编写一种编程语言与另一种同样熟练，那么每周发现的缺陷数量在不同编程语言之间将保持相当一致，并且缺陷的定义不会改变。这涵盖了跨编程语言和单位的一致性。缺陷也不基于任何人的意见；如果记录了一个新缺陷，那就是一个新缺陷。除非开发人员完全忽略问题，否则无法伪造。最后，如果你随时间跟踪这个度量指标，并实施允许你增加修复缺陷数量或提高代码质量的过程，你每周观察到的缺陷数量应该会随着时间的推移而减少。通过跟踪这个度量指标，你的代码质量会得到改进。

小测验

问题：以下哪项不被视为度量指标的理想特性？
A. 改进你的产品或过程的质量
B. 编程语言无关
C. 在维度使用上保持一致
D. 减少完成项目所需的小时数

答案是 D。虽然如果你的度量指标能帮助你减少完成项目所需的小时数会很棒，但这并非所有度量指标普遍具备的理想特性。改进产品或过程的质量是度量指标的目标，但这本身不是度量指标的特性。

度量指标的相对性

跟踪每周发现的缺陷数量的另一个优点是，它不必仅应用于整个产品。你可以分解这个度量指标来分析产品的不同部分。通过这样做，你可以识别项目中的任何问题区域并专注于它们。

另外需要提到的是，度量指标并不总是绝对的。有时你最终会得到只对你的项目有用的度量指标，因为它们所基于的值是相对的。基于故事点的速度就是一个很好的例子。故事点的定义因项目而异。使用基于相对值的度量指标是可以的，重要的是要认识到你的度量元何时是相对的，这样你就不会犯错误去尝试比较两个基于略有不同度量元的度量指标。

总结

本节课我们一起学习了软件度量的关键术语和理想度量指标的特性。关键要点是有意识地使用度量指标。确保你使用的度量指标是恰当且有意义的，这样你就不会出错。

在下一课中，我将介绍一些用于评估产品和过程的度量指标。你将学习一些坚实的现实世界度量指标，请不要错过。

041：其他度量指标

概述

在本节课中，我们将学习如何运用度量指标来评估软件产品及其项目，特别是针对非功能性需求。我们将探讨可维护性、性能、可靠性和产品成功等关键目标的度量方法。

在上一节课中，我们介绍了一些理想的度量属性，并区分了度量、测量和指标之间的差异。本节中，我们将重点讨论用于评估产品与项目非功能性需求的度量指标。

在关于GQM的课程中，我们讨论了为度量指标设定目标。现在，让我们看看一些具体的目标。

以下是软件项目中常被度量的几个关键目标类别：

可维护性：衡量软件代码的复杂程度，高复杂性通常意味着更难维护。
性能：评估软件执行任务的速度和效率。
可靠性：衡量软件系统能够持续正常运行、可供用户使用的能力。

度量可维护性

要度量软件的可维护性，可以使用复杂度度量。

复杂度度量用于衡量产品源代码的复杂程度。这通常通过源代码中逻辑分支的数量来体现。简单来说，逻辑分支越多，项目的复杂度就越高。复杂度更高的软件更难以维护。因此，如果你的代码过于复杂，可能需要考虑降低其复杂度，以提升产品的可维护性。

度量性能

要评估产品的性能，可以使用诸如响应时间这样的度量指标。

响应时间是一个描述任务从开始执行到完成所需时间的指标。例如，如果你的应用程序在服务器执行请求后需要三秒钟来显示数据，那么你的响应时间就是三秒。你可以对多次执行进行平均，以获得平均响应时间。

度量可靠性

产品的可靠性同样可以被度量。要衡量产品的可靠性，可以使用诸如产品正常运行时间这样的测量方法。

正常运行时间衡量的是产品能够启动并可供用户使用的时长。它通常以百分比表示。例如，数据库的标准正常运行时间通常在99%以上。这意味着数据库在超过99%的时间内都可以接收和发送信息，这是一个相当好的水平。

度量产品成功

最后，还有产品成功度量指标。这些指标在本课程前面已经讨论过，例如客户满意度。

以客户满意度为例，可以通过从用户那里获取五分制评分，然后将所有用户的评分总和除以用户数量来计算平均分。你也可以度量产品的正确性，但这更多属于功能性需求的范畴。度量产品正确性的最佳方法是通过缺陷分析，这将是下一节课的主题。

总结

本节课中，我们一起学习了如何运用不同的度量指标来评估软件的非功能性需求。我们探讨了通过复杂度度量来评估可维护性，通过响应时间来评估性能，以及通过正常运行时间来评估可靠性。此外，我们还回顾了客户满意度等产品成功度量指标。理解并应用这些度量，有助于你更全面地把握产品质量和项目健康状况。

042：缺陷分析

概述

在本节课中，我们将要学习一个在行业中非常有用且常用的工具：缺陷分析。这是一种评估产品质量的方法。

缺陷分析简介

上一节我们介绍了行业中常用的一些度量指标，本节中我们来看看如何通过分析缺陷来评估软件质量。缺陷分析是一种评估产品质量的方法。顾名思义，当你想分析产品中的错误数量时，就会使用缺陷分析。

一个错误是指产品中出现的故障。这通常可以追溯到源代码，但情况并非总是如此。

如何进行缺陷分析

进行缺陷分析的一种方法是跟踪代码中的缺陷数量，并将其与已修复的缺陷数量进行比较。

正如我在前几节课中所说，你可以通过统计系统中所有已报告的错误来找到代码中的缺陷数量。理想情况下，这些数据可以来自一组特定的内部软件测试人员，这样你的系统在发布时就不会带有许多错误。然而，这些数字也可能来自产品发布后的最终用户。

存在许多工具可以帮助你跟踪产品的漏洞、问题和错误。使用这些工具时，也容易跟踪这些问题的解决进度，例如它们是否已被修复，以及对其所做的任何更新。你还可以随着时间的推移比较这个数字。

缺陷发现率与修复率

以下是缺陷分析中的一个核心概念：缺陷发现率与修复率。

如果你统计每周发现的漏洞数量与每周修复的漏洞数量，并随时间跟踪这个数字，你就可以看到在开发新功能之前，是否应该投入更多精力来修复当前的问题。这被称为缺陷发现率与缺陷修复率。

如果每周发现的漏洞数量远远超过每周修复的漏洞数量，那么投入时间修复这些问题可能是个好主意。

作为一个满足所有理想度量属性的指标，这个指标也允许你跟踪进度。如果你集中精力修复缺陷，那么你最终会看到每周修复的缺陷数量上升。

通过长期跟踪缺陷发现率与缺陷修复率，你可以了解产品内部质量的情况。希望随着项目的推进，你修复的缺陷会多于发现的缺陷，产品中残留的缺陷会越来越少。

然而，如果你修复的缺陷和发现的缺陷一样多，那么你就遇到了所谓的“软件障碍”。正如我之前所说，这可能到了需要做出改变的时候。遇到软件障碍表明你的产品尚未准备好发布，你应该在发布前投入更多时间来修复漏洞。

缺陷分析的目的

缺陷分析是一种评估产品的方式。A. 生产力。B. 规模。C. 用户满意度。D. 质量。答案是D，质量。

进行缺陷分析主要是为了了解项目在质量方面的当前状态。

子系统缺陷分析

你还可以将已修复的缺陷按产品的不同组成部分（称为子系统）进行划分。本质上，要了解各子系统的缺陷，你只需跟踪与每个已修复缺陷相关联的子系统即可。

然后，你可以统计每个子系统的已修复缺陷数量，以查看产品中需要关注的区域。为了公平比较，这个数字应该除以每个子系统的规模。大的子系统自然会有更多缺陷，这就引出了缺陷密度。

缺陷密度

缺陷密度是确定整个产品缺陷数量的标准方法。要计算缺陷密度，只需取代码中发现的缺陷数量与代码规模的比率。规模可以用千行代码来衡量。

对于结构化编程技术，行业平均水平大约是每千行代码15到50个缺陷。你可以使用这个指标来对你的项目发布准备情况做一些有趣的预测。

缺陷密度预测示例

想象一下，你正在构建一个软件产品，并和团队一起进行第三次发布。你的第一个版本在发布前发现了900个缺陷，发布后发现了100个缺陷。代码量为10万行。这使得你第一个发布版本的缺陷密度为每千行代码10个缺陷。

在第二个发布版本中，你的团队增加了额外的5万行代码，发布前发现了400个缺陷，发布后发现了45个缺陷。这使得第二个版本的增量缺陷密度为每千行代码8.9个缺陷。

现在你计划发布第三个版本。你的团队已经构建了额外的10万行代码，到目前为止在这部分代码中发现了600个缺陷。这使得你的增量缺陷密度为每千行代码6个缺陷。

考虑到前两个已发布的增量版本缺陷密度在每千行代码8.9到10个缺陷之间，这次你的产品准备好发布了吗？答案是否定的。除非自第二个版本以来你的开发流程有所改进，否则你可以预期在第三个增量版本中，每千行代码会发现8.9到10个缺陷。对于10万行代码，大约是890到1000个缺陷。

在之前的版本中，你在发布前发现并修复了90%的缺陷。这意味着你可以预期在这个版本中，每千行代码会发现大约801到900个缺陷。因此，如果只发现了600个，你可以预期在发布前还会在产品中发现201到300个缺陷。在产品发布前发现缺陷总是更好的，因此你的产品可能还不适合发布。

缺陷密度计算练习

对于一个规模为10万行代码、发布前识别出640个漏洞、发布后识别出211个漏洞的软件项目，其发布前缺陷密度是多少？A. 每千行代码2.1个缺陷。B. 每千行代码6.4个缺陷。C. 每千行代码7.51个缺陷。D. 每行代码0.00751个缺陷。答案是B，每千行代码6.4个缺陷。请记住，这里我们只计算发布前的缺陷。

缺陷分析实战案例：航天飞机软件

让我们看一个缺陷分析的实际案例。航天飞机飞行软件以其几乎无错误而享有最佳声誉之一。它必须如此，否则可能导致人员伤亡和数十亿美元的损失。

那么，编写该软件的机载航天飞机小组是如何实现这种完美水平的呢？对他们来说，仅仅找到一个缺陷、修复它，然后收工是不够的。当发现一个缺陷时，存在强制性的协议来分析该缺陷，识别该缺陷可能出现的其他类似区域，并调整流程以避免将来出现此类缺陷。

例如，航天飞机有一个著名的加拿大组件，称为Canadarm，这是一个在恶劣太空环境中协助完成复杂任务的机械臂。如果在Canadarm手腕旋转的方式中发现一个漏洞，那么也可以检查其他涉及硬件旋转的代码是否存在类似错误。

因此，通过进行缺陷分析，可以在一个完全独立的、用于旋转通信天线的子系统上发现类似的漏洞，从而避免潜在的灾难。事实上，这是航天飞机软件发生的一个真实场景，帮助节省了大量工作、时间和金钱。

通过实施这种严格的测试和修订程序，机载航天飞机小组能够在其运行软件方面达到完美的状态。如果你想了解更多关于他们流程的信息，请查看课程笔记中的资源。

总结

本节课中我们一起学习了缺陷分析。这是一种简单的技术，可以帮助你确保了解项目的质量，并在测试和发布方面做出正确的决策。

这也是本模块的结尾。我们在这个模块中涵盖了很多内容，让我们回顾一下。首先，我讨论了一些软件产品的评审技术，如代码走查和需求技术评审。然后，我讨论了监控软件项目时的一些常见问题，并指出了一些常用但价值不高的度量指标。之后，我讨论了目标-问题-度量（GQM）框架，以及实施它如何帮助你确保在项目中使用适当的度量指标。接着，我们探讨了度量指标的理想属性，涵盖了什么是好的度量指标。然后，我讨论了当今行业中一些流行的度量指标。最后，我们深入学习了缺陷分析。这些活动有助于确保产品通过经过评审和度量的工作正确完成。

在下一个模块中，Morgan将与你讨论如何通过介绍每日站会、回顾速率以及向你展示燃尽图来确保项目得到正确管理。请继续学习。

043：每日站会 🎯

在本节中，我们将学习如何通过每日站会来确保产品开发过程得到有效管理。我们将了解站会的核心目的、标准流程以及如何高效地运行它，以保持项目按计划推进。

概述

每日站会是敏捷开发中一个简短的同步会议，旨在帮助团队快速同步进度、规划当日工作并识别障碍。它并非状态汇报会，而是团队内部的协调会议。

每日站会的目的与结构

上一节我们介绍了项目管理的整体框架，本节中我们来看看其中一个核心实践——每日站会。它的主要目标是让开发团队快速启动新一天的工作，并确保所有人目标一致。

每日站会是一个时间盒严格限定为15分钟的会议。在会议中，所有核心参与者围成一圈，依次回答三个问题。

以下是每位参与者需要回答的三个核心问题：

我昨天完成了什么？
我今天计划做什么？
我遇到了什么障碍？

“猪”与“鸡”的角色区分

你可能会想，如何在15分钟内听完所有人的更新？这引出了一个经典的角色比喻来区分参与者。

在每日站会中，建议只有“猪”（即对项目有实质性承诺的人）才需要发言。“鸡”（即项目的相关方或观察者）可以旁听，但通常不参与发言。

“猪”：通常指开发团队成员，以及有重要更新需要同步的产品负责人。他们对项目成果有直接承诺。
“鸡”：可能包括来自其他团队的开发者、希望了解状态的高层管理者，或没有重要更新的产品负责人。他们关心项目但并非直接执行者。

站会内容演练

假设你正在参加每日站会，下一个轮到你发言。哪些内容应该包含在你的更新中？

以下是几个选项示例：
A. 昨天，你完成了数据库结构的设计。
B. 昨天，你下班后看了一部非常棒的电影。
C. 今天，你计划开始设计用户界面。
D. 物料间没有纸了，导致你无法绘制用户界面的线框图。
E. 你对产品有一个功能改进的建议。

分析：在每日站会中，你只需要回答那三个核心问题。更新昨天完成的工作、今天承诺的工作以及遇到的障碍是合适的。因此，选项A、C和D是正确的。分享下班后的活动（B）不应在站会提及。提出未来的改进建议（E）也不是站会的场合。

站会的本质与最佳实践

每日站会并不仅限于Scrum框架，它在许多敏捷方法中都很常见，在极限编程中被称为“每日站立会议”，也常被称作“每日短会”或“晨会”。

每日站会不应是产品经理或负责人获取进度报告的状态会议。状态更新应通过看板或燃尽图等进度跟踪工具来完成。站会应是开发团队为开发团队召开的同步会议。

在站会中，团队成员是在相互做出承诺。如果一个开发者承诺在站会当天完成某个功能，那么团队就有权期待他在次日的站会上报告该功能已完成，或者说明遇到了阻碍完成的障碍。

一次成功的站会应该是快速且充满活力的，不应是开发者们觉得是负担、 dreaded 的会议。它应该让团队成员感到兴奋并准备好开始一天的工作。

处理站会中的特殊情况

假设在一次站会中，开发者丹尼昨天承诺完成登录功能的源代码。但在今天的站会上，他说昨天已经着手开发，并计划在今天完成，且表示没有遇到任何障碍。作为Scrum主管，你应该怎么做？

以下是几个选项：
A. 对他生气，因为他昨天承诺要完成。
B. 礼貌地询问丹尼为何没能完成，并询问团队是否能提供帮助。
C. 什么都不做，他说了今天会完成。
D. 指派其他人去完成这个功能。

分析：每日站会应该是一个开放的沟通渠道，而不是相互指责的地方。虽然他未能完成且声称没有障碍的情况有些奇怪，但最好的做法是询问团队是否能提供帮助，例如建议有人可以和他进行结对编程。因此，选项B是正确的。

站会的详细流程与Scrum主管的职责

让我们更详细地走一遍每日站会的流程。

会议开始时，所有人站成一个无障碍的圆圈，圈内不应有笔记本电脑或手机。每位“猪”依次回答三个问题。一个典型的开发者更新可能听起来像这样：“大家好。昨天我效率很高，完成了用户个人资料页的所有单元测试。今天，我将开始编写该功能的源代码。我目前唯一的障碍是，我对这个编程语言不太熟悉，今天有谁愿意和我结对编程这个功能吗？”

会议通常在看板或任务板前进行，以便团队在需要时可以移动他们的任务卡片。会议应每天在同一时间、同一地点举行。

如果对话开始偏离那三个核心问题，Scrum主管有责任打断对话，并将该话题添加到“停车场”列表中，以便在会后与相关人员进行讨论。这有助于将会议控制在15分钟的时间盒内。这个会后讨论列表通常被称为“停车场”、“侧边栏”，或者说“我们线下讨论这个问题”。

Scrum主管还需要记录任何未在会议上直接解决的障碍，并负责确保这些障碍被解决或指派人员去处理。

会议结束时，应有某种行动来示意会议结束，例如团队喊一句口号或Scrum主管说一句熟悉的话，这样可以避免人们尴尬地站着，不确定会议是否已经结束。

Scrum主管的情景决策

假设你是每日站会的Scrum主管。会议进行得非常顺利，最后一位开发者正在做更新，会议只进行了10分钟。但她的更新引发了开发者们一次离题的讨论。你应该怎么做？

以下是几个选项：
A. 让讨论继续，会议还剩5分钟，而且没有其他更新了。
B. 让讨论继续，这反正是我们需要讨论的事情，超过15分钟时间盒也没关系。
C. 打断讨论，结束会议，让所有人回去工作。
D. 打断讨论，将其添加到讨论事项列表中，并建议任何想继续讨论的人可以在会后进行。

分析：无论会议还剩多少时间，离题的讨论都应被打断。你不应鼓励离题讨论的习惯，因为并非每次都有额外时间。你也不希望任何人在会议中停留超过必要的时间，特别是当讨论与他们无关时，这会占用他们的工作时间。然而，你也不想打击沟通。打断讨论后就不再提及该话题，这不是开放沟通的范例。最佳实践是打断讨论，并邀请感兴趣的人在每日站会后继续讨论。因此，选项D是正确的。

总结

本节课中我们一起学习了每日站会的核心概念与实践。我们明确了站会的三个核心问题、参与者“猪”与“鸡”的角色区分，以及Scrum主管在维护会议纪律和效率中的关键职责。记住，每日站会的目标是促进团队同步和快速识别障碍，而非进行详细的问题解决或状态汇报，这些活动应安排在会后进行。

044：每日站会的常见挑战与解决方案

概述

在本节课程中，我们将探讨每日站会可能遇到的常见问题，并提供一系列实用的解决方案。每日站会是Scrum框架中的核心实践，旨在促进团队同步和协作。然而，如果实施不当，它可能会变得低效甚至适得其反。我们将逐一分析这些问题，并学习如何让每日站会重新变得高效。

每日站会为何失效？

如果你的每日站会效果不佳，可能存在以下情况：会议经常超时；团队成员不愿分享进展；或者会议氛围沉闷、缺乏热情。接下来，我们将详细讨论每日站会中常见的问题以及相应的解决方法。

问题一：无人愿意或不知如何开始发言

你可能会遇到一个问题：没有人愿意开始每日站会，或者不清楚发言顺序。团队总是依赖Scrum Master来发起会议。

Scrum Master可以宣布会议开始，但不应该总是由他来负责启动会议。Scrum Master应尽可能避免主导会议进程，因为这容易让会议看起来像状态汇报会，而非团队同步会。

以下是解决此问题的一些技巧：

最后到者先发言规则：这意味着最后一个加入会议的人必须首先发言。虽然这可能鼓励守时，但最后到达的人通常也是最没有准备好发言的人，因此这个技巧可能效果有限。
传递令牌法：许多团队使用一个令牌进行传递。这个令牌可以是一个球、一个毛绒玩具或一件办公用品。传递令牌通常能让会议更有趣，鼓励参与者集中注意力，并消除“下一个谁发言”的问题。当一个人完成更新后，他将令牌扔给圆圈中的另一个人。如果团队成员想带着早晨的咖啡参加站会，或者团队规模较大时，这个方法可能不太适用。
轮流发言法：采用轮流发言技巧，即一个人自愿开始会议，然后按顺序轮流，直到每个人都完成更新。

场景练习：你的Scrum团队总是迟到参加每日站会。当大家终于到齐后，又没有人愿意开始会议。你应该实施哪种技巧来使每日站会更有效？
A. 最后到者先发言
B. 传递令牌
C. 轮流发言

实施“最后到者先发言”技巧将鼓励团队更加守时，同时也会迫使某人开始会议。因此，A是正确答案。

问题二：会议经常超时

每日站会一个非常普遍的问题是经常超过15分钟的时间盒限制。

我们已经讨论过，可以通过确保只有核心成员（“猪”）发言来缩短每日站会的时间。我们也建议将任何离题的讨论添加到会后讨论主题列表中。

如果你仍然超时，以下是一些可以尝试的额外技巧：

以下是你可以尝试的一些额外技巧：

站立开会：确保你的团队在整个会议期间保持站立。如果你的每日站会是在会议桌旁舒适的椅子上进行的，这会鼓励人们逗留并拖长会议。通过让他们站立，他们会感到不适，从而希望更快结束会议。
使用小型计时器：将会议的15分钟时间盒分配给每个人。当时间快用完时，正在发言的人会知道需要快速结束。
使用有“分量”的令牌：你也可以创造性地使用前面提到的“传递令牌”技巧。但不要使用普通的令牌，而是使用一个沉重的健身球。这会鼓励他们想尽快传递它。如果这仍然不起作用，可以让他们双臂向前伸直托着球。在这种情况下，他们绝对会想尽快摆脱这个球。

问题三：无人沟通障碍

你可能遇到的另一个问题是没有人沟通障碍。可能是你的团队没有遇到阻碍，但这并不常见。如果没有人提出障碍，但你们却经常错过截止日期，这就应该引起警惕。

解决这个问题的一种方法是，在你自己的更新中包含一些小障碍，让团队知道他们被鼓励提出任何障碍，无论多小。你也可以用一些问题来提示他们，例如：“我或团队可以做些什么让你今天的工作更轻松吗？”

问题四：并非所有成员都在上午出席

并非所有团队成员都在上午出席，这在实行弹性工作制的办公室中很常见。

在这种情况下，你应该将会议安排在所有人都会在场的时间。需要注意的是，如果你将会议安排在上午较晚的时候，通常富有成效的工作就无法在会议前完成。会议较晚通常意味着开工较晚，并损失了有效工作时间。

在一天开始时开会是最有效的。但如果不可能，可以将会议安排在午饭后或当天晚些时候的另一个时间，这样会议就不会与一天的开始相关联。

问题五：会议感觉像状态汇报会

我们将探讨的最后一个问题是，会议感觉像状态汇报会。如果团队是在向Scrum Master或产品负责人汇报，而不是向开发团队的其他成员同步，那么这代表的是状态汇报会，而非同步会议。

为了解决这个问题，可以提醒进行更新的人与开发团队分享。你可以建议进行更新的人避免与他们的主管进行眼神交流。这鼓励他们看向开发团队的其余成员。

场景练习：你的办公室实行弹性工作制，这意味着员工可以在一天中的任何时间工作，只要满足要求的工时即可。你的两名开发人员通常在早上送孩子上学后，于10点到达。一名开发人员喜欢提早开始一天的工作，每天早晨7点准时到办公室。你的最后一名开发人员喜欢中午左右来，并工作到很晚。安排每日站会最有效的时间是什么时候？

A. 上午10点，然后向最后一名开发人员更新会议内容。
B. 午饭后，当所有开发人员都在场时。
C. 根本不进行每日站会，因为早上没有一个人人都合适的时间。

你需要确保整个Scrum团队都出席会议，所以上午10点效果不佳。在一天中较晚的时候进行每日站会比根本不进行要有效得多。因此，B是正确答案。无论何时进行，每日站会都是一种很好的实践。在午饭后开会可以鼓励下午的高效工作，并且与一天的开始有足够距离，团队成员不会将会议与他们工作日的开始联系起来。

总结与反思

本节课中，我们一起学习了每日站会可能面临的各种挑战及其解决方案。每日站会旨在良好地开启一天，改善团队支持，鼓励改进，增强团队凝聚力，并作为另一个沟通渠道。它是一种非常有效且易于实施的实践。

如果你正尝试在工作场所逐步实施敏捷实践，每日站会是一个很好的起点。不妨与你的团队一起尝试一下。

反思问题：

你曾经参加过每日站会吗？它们有效吗？
你可以实施哪些技巧来使它们更有效？
关于每日站会，你过去有哪些行之有效的建议？
如果你没有参加过每日站会，你认为它们对你曾工作过的团队会有效吗？为什么有效或为什么无效？

欢迎在课程讨论中分享你的想法。在下一个模块中，我们将讨论如何利用速率来确保你的项目得到正确管理。

045：速率（Velocity）🏃‍♂️

在本节中，我们将深入学习敏捷项目管理中的一个核心概念——速率。速率是衡量团队工作效率的关键指标，能有效帮助你确保项目在正确的轨道上运行。

什么是速率？

速率是一个相当简单的概念。它衡量的是团队在给定时间间隔内完成的工作单位数量。这通常以每个冲刺（Sprint）完成的故事点数来衡量。

我们在《敏捷规划与软件需求》课程中讨论过故事点以及如何使用它们来估算用户故事的规模。如果你不熟悉这个概念，可能需要回顾一下那节课。

关于速率，有几个重要事项需要明确：

首先，一个用户故事必须根据团队对“完成”的定义真正完成后，其故事点才能计入团队的速率。
其次，速率应在用户故事层面进行衡量，而不是在任务层面。

如何计算速率？

以下是计算团队在特定冲刺中实现的速率时，哪些项目可以计入的示例：

A. 该冲刺中完成的用户故事数量。
B. 该冲刺中完成的用户故事的故事点。
C. 一个已完成一半任务的功能，因此可以计入其一半的故事点。
D. 一个已完成编程和文档记录但尚未测试的功能的故事点。

只有满足团队“完成”定义的用户故事，其故事点才能计入团队速率。不能计入半成品功能或任务的故事点。因此，只有选项 B 是正确答案。

如何估算速率？

估算速率并不十分精确。理想情况下，估算的速率应基于以往的工作。如果团队和产品相似，你可以使用之前的项目来估算速率。

但如果没有此类信息怎么办？一种估算速率的方法是将工作分解为任务。取你计划在一个冲刺中完成的用户故事，并为这些需求创建工作分解结构。你需要确保估算的任务时间与团队可用时间相符。如果不符，可能需要增加或移除用户故事。

一旦确定了冲刺中将完成哪些用户故事，将这些用户故事对应的故事点相加，结果就是你第一个冲刺的目标速率。这个目标速率将用作你第一个冲刺的估算速率。

估算速率练习

假设你和你的团队正在为开发的第一个冲刺做准备。你想计算一个估算速率，但你的团队从未合作过，并且对此类产品没有经验。

你计划在本冲刺完成四个用户故事：

用户故事 A：分配了 3 个故事点。
用户故事 B 和 C：各分配了 5 个故事点。
用户故事 D：分配了 1 个故事点。

你将用户故事分解为任务并估算了任务时间。你估计这些故事总共需要 110 小时完成。而你的开发团队本冲刺只有 95 个可用小时。你决定从冲刺中移除用户故事 A，因为它估计需要 15 小时。

那么，你的团队对冲刺一的估算速率是多少？

A. 3 个用户故事
B. 14 个故事点
C. 11 个故事点
D. 110 小时
E. 95 小时

速率估算应基于用于用户故事的规模度量单位。在本例中，我们使用故事点。因此，以用户故事或小时计量的选项 A、D 和 E 不正确。在根据任务估算确定团队没有时间完成用户故事 A 后，你决定移除它。因此，你的速率估算将基于用户故事 B、C 和 D 的故事点之和，即 11 个故事点。所以，C 是正确答案。

速率的波动与稳定

团队在每个冲刺中实现的实际速率可能会因各种原因而波动。你团队的第一个冲刺速率可能低于其他冲刺。如果团队仍在学习如何协作，或者在学习新技术，就可能发生这种情况。你还会遇到可能影响团队速率的缺陷或其他风险。

然而，随着时间的推移，团队的速率应该会趋于稳定。一个相对稳定的速率表明你的团队遵循了敏捷原则，即保持可持续的开发节奏。

实际速率用于创建发布和迭代燃尽图，这将是我们本模块接下来两节课要学习的内容。

本节课中，我们一起学习了速率的概念、计算方法、估算技巧及其在敏捷项目管理中的意义。速率是衡量团队稳定交付能力的关键指标，理解并正确运用它，对于把控项目进度至关重要。

046：发布燃尽图 📉

概述

在本节课程中，我们将学习一种在Scrum方法中非常常见的可视化监控工具——发布燃尽图。我们将了解它的构成、如何解读它，以及如何利用它来跟踪项目进度和预测完成时间。

发布燃尽图简介

发布燃尽图是一种可视化监控工具，在Scrum方法中非常常见。

发布燃尽图会向你展示开发团队已经完成了多少工作、还剩下多少工作、团队在每个冲刺中的速度，以及你预计何时能完成产品。可以想象，它是确保项目得到正确管理的绝佳工具。

既然发布燃尽图能展示所有这些信息，你可能会想象它是一张非常复杂的图表。但发布燃尽图的妙处在于，它的概念很简单。让我们来看一个基本的发布燃尽图。

如图所示，我们在水平轴上列出了冲刺。这个示例项目有六个冲刺。在垂直轴上，是总工作量。这可以用你的团队选择的任何度量单位来描述需求规模。

在我们的示例中，我们将使用故事点。图表中与每个冲刺对应的每个条形，代表了在该冲刺开始时仍然剩余的故事点总数。

自然地，在冲刺1开始时，我们拥有所有剩余的故事点，因为我们尚未开始完成它们。这代表了你的总工作量。总工作量是你计划在项目中完成的所有用户故事的故事点总和。

当你完成需求时，你将从燃尽图中移除它们的故事点。

解读燃尽图数据

你的开发团队即将开始第六个也是最后一个冲刺。这是该项目的发布燃尽图。你的团队完成了多少故事点？还剩下多少？

选项：
A. 100个故事点完成，15个故事点剩余。
B. 100个故事点完成，0个故事点剩余。
C. 85个故事点完成，15个故事点剩余。
D. 85个故事点完成，0个故事点剩余。

预测线与进度跟踪

如果我们想预测完成这个产品需要多少个冲刺，我们可以画一条穿过条形图的线来预测。我们称这条线为预测线。

由于我们是基于一个冲刺的速度来预测，我们将以该值作为预测依据。根据我们的预测线，它表明应该需要六个冲刺。你可能认为这条线指向了七个冲刺，但请记住，发布燃尽图是基于每个冲刺开始时剩余的故事点数量。这意味着在冲刺7开始时将没有故事点需要完成，也就是说你不需要那个冲刺。

你也可以使用预测线来查看开发是否按计划进行。

假设我们刚刚完成冲刺4，我们的发布燃尽图看起来是这样的。在第一个冲刺中，我们完成了15个故事点。我们想保持这个速度，所以那是预测线。然而，在冲刺2中，我们只完成了5个故事点。如图所示，我们冲刺3的条形现在位于预测线之上。在冲刺3中，我们完成了15个故事点。我们将速度恢复到了初始值，但由于冲刺2，我们仍然落后于计划。在冲刺4开始时，我们应该总共完成45个故事点，并且开发进行到一半。但如图所示，我们冲刺4的条形位于预测线之上。我们比预期进度落后了10个故事点。

调整与进度变化

现在假设在冲刺4开始时，因为我们看到项目落后于计划，我们雇佣了两名开发人员。在冲刺4中，我们完成了25个故事点。这使我们的项目回到了正轨。在冲刺5中，我们又完成了25个故事点。这现在使我们的项目进度超前了。如图所示，我们冲刺6开始时的条形现在位于预测线之下。这意味着你的团队可能能够为产品完成更多需求。

在现实中，你的发布燃尽图看起来像这样的可能性极小。更常见的情况是，你的发布燃尽图看起来像这样。

考虑这个发布燃尽图。你已经完成了第一个冲刺。如果你保持从这个冲刺开始的初始速度，你预计需要多少个冲刺来完成工作？

选项：
A. 5个冲刺
B. 6个冲刺
C. 7个冲刺
D. 8个冲刺
E. 你需要更多信息

如果你保持这个速度，你的预测线表明在冲刺6开始时你将没有故事点需要完成。这意味着你将在五个冲刺内完成项目。因此，A是正确答案。

“完成”定义的重要性

我曾在一个不专注于可工作软件的团队工作过。我们正在开发一个需要数据库连接的产品。我们团队的一半人致力于开发数据库，另一半人致力于开发产品用户界面。尽管许多功能已经为界面编程，数据库也在开发中，但我们不能将任何需求标记为完成，因为我们正在等待数据库开发完成并连接到应用程序。

我们的燃尽图最终看起来像这样。从我们的燃尽图中可以看出，看起来好像我们在前三个冲刺中什么都没做，然后在冲刺4中非常努力地工作。我们知道情况并非如此，但燃尽图会显示你的团队是否在完全完成功能后才转向新的功能。否则，燃尽图就不能很好地代表产品的进度。

应用实例与测验

你正在一个开发移动应用程序的团队工作。你刚刚完成了第三个冲刺。你团队的“完成”定义包括仅那些已编程、已文档化、已测试并准备上市的功能。以下哪个功能应被计为已完成，并在该冲刺的发布燃尽图中扣除其点数？

选项：
A. 一个在上个冲刺已开发并文档化但测试失败的功能，在当前冲刺中已收到小修复并通过了测试。
B. 一个你没有时间测试，但你确信它能工作的功能。
C. 一个已编程、文档化并测试的界面功能，但尚未连接到数据库。
D. 一个运行完美、在冲刺中通过了所有测试并已妥善文档化的功能。

只有满足团队“完成”定义的功能才能为发布燃尽图标记为完成。答案B和C都是未满足“完成”定义的功能，因此不能为发布燃尽图标记为完成。答案A展示了一个在上个冲刺未满足“完成”定义但现在满足的功能，因此可以在本冲刺中为发布燃尽图标记为完成。答案D也满足团队的“完成”定义，因此可以为发布燃尽图标记为完成。A和D是正确答案。

总结

在本节课中，我们一起学习了发布燃尽图。我们了解了它如何作为Scrum中的可视化工具，来展示已完成工作量、剩余工作量、团队速度并预测项目完成时间。我们探讨了如何绘制和解读预测线以跟踪进度，并强调了团队拥有清晰“完成”定义的重要性，因为这是燃尽图准确反映进度的基础。通过实例分析，我们巩固了如何根据“完成”定义来判断哪些工作成果可以计入燃尽图。掌握发布燃尽图将帮助你更有效地监控和管理软件项目的开发进程。

软件产品管理课程5：3.3a：发布燃尽图与需求变更 🔄

在本节课程中，我们将探讨一个关键问题：当项目需求发生变更时，如何通过发布燃尽图来准确反映这些变化及其对项目进度的影响。

概述

发布燃尽图是跟踪项目整体进度的有效工具。然而，基础版本的燃尽图无法清晰展示需求变更（如新增或移除用户故事）带来的影响。本节课我们将学习两种改进的燃尽图形式，它们能同时展示团队的工作速率和需求范围的变化。

基础燃尽图的局限性

上一节我们介绍了基础的发布燃尽图。这种图表的一个不明显之处在于，它无法有效体现需求变更带来的影响。

众所周知，需求是不断变化的。可能某个需求的故事点估算发生了变更。我们需要一种方法在燃尽图中表示这种变化。

假设我们处于项目的Sprint 4开始时，燃尽图如下所示。

假设在Sprint 4中，团队完成了15个故事点的工作。但在Sprint 5开始前，新增了两个用户故事，每个价值5个故事点。

此时，我们的燃尽图会变成类似这样。看起来开发团队在Sprint 4只完成了5个故事点，但这并非事实。

展示需求变更的两种方法

为了准确反映情况，有两种常见的方法可以在发布燃尽图中展示需求变更。

方法一：总工作量完成图

第一种方法是在表示“剩余工作”的柱状图上方，展示每个冲刺完成的总工作量。

图表会变成这样。在此燃尽图中，底部是剩余总工作量，顶部是已完成总工作量。

你可以看到，在Sprint 2开始时，故事点没有增减。因为Sprint 2开始时的“剩余工作”和“已完成工作”柱体总高度，与Sprint 1开始时的总工作量高度相同。

在Sprint 3开始时，新增了10个故事点。我们可以看出这一点，因为此时“剩余工作”和“已完成工作”的总量比上一个冲刺更大了。

故事点总数在Sprint 5开始前保持不变。在Sprint 5开始时，总故事点数减少了，因为“剩余工作”和“已完成工作”的总和现在小于前一个冲刺。

这种燃尽图现在既能展示团队的工作速率（Velocity），也能展示故事点的变化。

思考一下这个总工作量完成燃尽图：团队在Sprint 2的速率是多少？
A. 0个故事点
B. 5个故事点
C. 10个故事点
D. 15个故事点

为了确定Sprint 2的速率，我们需要观察Sprint 3开始时的柱状图。请记住，柱状图的下半部分代表剩余故事点，而柱体的总高度代表所有故事点。

Sprint 2开始时剩余75个故事点，Sprint 3开始时剩余65个故事点。表面上看，Sprint 2似乎完成了10个故事点。

然而，Sprint 2的柱体总高度是90个故事点，而Sprint 3的柱体总高度是85个故事点。这意味着有价值5个故事点的工作被移除了。

因此，从表面完成的10个故事点中，减去被移除的5个故事点，可以得出Sprint 2的速率是5个故事点。所以正确答案是B。

方法二：可调基线图

第二种展示故事点变化的方法是使用可调基线。

在这类发布燃尽图中，故事点的变化体现在图表的底部基线调整上。这种燃尽图看起来是这样。

这与我们在小测验前使用的例子是同一个燃尽图。

在Sprint 2开始时，故事点没有变化。你可以看到，因为Sprint 2的柱体仍然紧贴X轴。

在Sprint 3开始时，我们新增了故事点。我们可以看出这一点，因为现在有故事点出现在X轴下方。

Sprint 4的故事点数量保持不变。然后在Sprint 5，我们看到故事点再次发生变化——这次是移除了故事点。我们可以看到这一点，因为Sprint 5的柱体现在比前一个冲刺的柱体更高了。

你还需要调整预测线，使其与可调基线对齐。如果我们在Sprint 5开始时从未移除故事点，预测线会是这样的。

基于这个发布燃尽图以及根据前两个冲刺计算的预测线，如果团队保持这个速率，他们预计这个项目会有多少个冲刺？
A. 5个冲刺
B. 6个冲刺
C. 7个冲刺
D. 8个冲刺

如果这是一个基础发布燃尽图，你可以预期项目有6个冲刺，因为预测线表明第七个冲刺将没有工作。

但由于这是一个可调基线发布燃尽图，我们必须考虑故事点的变化。在Sprint 3开始时，有许多故事点被添加到项目中。如果你要保持相同的速率，这意味着项目需要更长时间才能完成。

如果你延长基线和预测线直到它们相交，你会发现直到第八个冲刺才没有剩余故事需要完成。因此，团队可以预期项目将需要7个冲刺。正确答案是C。

如何选择燃尽图类型

那么，何时适合使用基础发布燃尽图，何时应该使用总工作量完成图或可调基线图呢？

基础形式是展示剩余总工作量的绝佳方式。如果你不关心跟踪团队的速率，那么选择简单版本即可。

如果你打算使用发布燃尽图来提供更多信息，那么你应该使用总工作量完成发布燃尽图或可调基线发布燃尽图。这两种燃尽图展示的信息相同，因此使用哪一种没有区别，只是个人偏好问题。

另一个需要注意的重要点是，有时发布燃尽图被绘制成折线图，而不是本演示中使用的柱状图。

在这种情况下，你的基础发布燃尽图会从这样：

变成这样。

总工作量完成燃尽图会从这样，变成这样。

最后，可调基线发布燃尽图会从这样，变成这样。

总结

本节课中，我们一起学习了如何通过改进的燃尽图来应对需求变更。

发布燃尽图是可视化整个开发进度的优秀工具。
一张简单的图表可以展示项目的总工作量、已完成的工作、剩余的工作、预期完成时间以及故事点的变化和团队的速率。
燃尽图还可以在你项目偏离计划时提供早期预警。
燃尽图不仅可用于发布级别，也可用于迭代或冲刺级别。这将是我们下一节课要讨论的内容。

048：迭代燃尽图 📉

概述

在本节课中，我们将学习几种用于在冲刺或迭代期间跟踪开发进度的技术。我们将重点介绍迭代燃尽图，并将其与发布燃尽图进行比较，同时探讨如何将其与Scrum任务板结合使用。

迭代燃尽图简介

上一节我们介绍了发布燃尽图。本节中，我们来看看如何将燃尽图进行调整，以用于跟踪冲刺期间的进度。

迭代燃尽图的工作原理与发布燃尽图非常相似。下图展示了一个典型的迭代燃尽图。

与我们在发布燃尽图课程中看到的类似，迭代燃尽图也有一条预测线。这条预测线展示了可持续完成任务进度的理想情况。

迭代燃尽图可以绘制为折线图或条形图，这与发布燃尽图相同。下图展示了作为条形图的燃尽图样式。

这主要取决于个人偏好。我喜欢对发布燃尽图使用条形图，对迭代燃尽图使用折线图，以便快速区分。在本课中，我将使用折线图，以便您熟悉两种风格。

问题：根据此迭代燃尽图，团队计划在冲刺的每一天完成多少工时？
A. 220小时
B. 20小时
C. 22小时
D. 需要更多信息

答案：预测线显示团队在冲刺中共有220小时的待完成工作，冲刺长度为10天。请记住，第11天开始时没有工作要做，因此冲刺只有10天。这意味着团队计划在冲刺的每一天完成22小时的总工作量。因此，C是正确答案。

迭代与发布燃尽图的区别

现在，让我们看看迭代燃尽图和发布燃尽图有何不同。

在迭代燃尽图中，横轴是天数，而不是发布燃尽图中的冲刺数。

在迭代燃尽图的纵轴上，总工作量以小时为单位衡量。而在发布燃尽图中，总工作量以故事点衡量。

这种变化是因为在迭代燃尽图中，我们跟踪的是任务的完成情况，而在发布燃尽图中，我们跟踪的是用户故事及其对应故事点的完成情况。

迭代燃尽图应该每天更新，这通常在每日站会中进行，会上会标绘前一天的工作量。

与发布燃尽图在每个冲刺开始时测量待办工作类似，迭代燃尽图中每天的总工作量代表每天开始时剩余的工作量。

迭代燃尽图上只应包含工作日，不应包括周末或节假日，除非计划在这些日子工作。此迭代燃尽图代表一个包含10个工作日的两周冲刺。您会注意到周末已被考虑在内，日期从2月26日跳到了2月29日。

问题：您正在为一个开发团队创建迭代燃尽图。该团队进行为期两周的冲刺，冲刺中间有一个两天的周末，开发人员周末不工作。团队在冲刺期间还将参加一天的会议，当天无法进行产品开发。您的迭代计划应包含多少天？
A. 14天
B. 10天
C. 9天

答案：在迭代燃尽图中，只应包含团队将在产品上工作的天数。由于开发人员在两天的周末和会议日不工作，他们在两周的冲刺中损失了三天，因此迭代燃尽图上只应出现9天。所以，C是正确答案。

Scrum任务板

更新迭代燃尽图通常与Scrum任务板相关联。在深入探讨如何更新迭代燃尽图之前，让我们先花点时间看看什么是Scrum任务板以及如何使用它。

Scrum任务板与看板非常相似。有时，Scrum任务板被称为白板任务板或简称为任务板。

以下是Scrum任务板的使用方法：

在第一列中，放置计划在冲刺中完成的所有用户故事。
然后将每个用户故事分解为开发人员任务，并为这些任务创建估算。
通过为每个用户故事创建任务，可以确保没有任务被遗漏。
当任务处于进行中、等待验证或已完成状态时，它们会在任务板上移动，类似于看板。
开发人员可以在领取任务时将自己的名字写在任务上，这有助于跟踪特定问题的负责人。
一旦任务移动到“完成”区域，即可视为完成。然后在更新燃尽图时，将该任务的工作量“燃尽”，这意味着可以从剩余工作中扣除该任务关联的工时。
一旦一个用户故事的所有任务都进入“完成”区域，那么该用户故事就应该满足团队的“完成定义”。

与发布燃尽图只包含满足团队“完成定义”的用户故事类似，在迭代燃尽中，我们也只希望包含完全完成的任务。这就是为什么将迭代燃尽图与任务板结合使用是一个好主意，您可以清楚地看到哪些任务已完成并经过验证。

结合使用任务板与迭代燃尽图

让我们看一个如何结合使用任务板和迭代燃尽图的例子。

假设我们添加一个任务：“为产品登录页面编写测试”，该任务对应任务板上的第三个用户故事。我们估计此任务需要10小时。开发人员Ellie将此任务分配给自己。

Ellie将任务移动到“进行中”列，并开始编写测试。
当她完成测试编写后，将任务移动到“待验证”列，供另一位开发人员验证。
另一位开发人员Alfred检查Ellie的测试并确认其完成。在审查时，他将任务移动到“验证中”列。完成后，他将任务移动到“完成”列。
在接下来的每日站会上，Scrum主管Benjamin在迭代燃尽图上将此任务标记为完成。假设Ellie的任务是当天唯一完成的任务。更新后的迭代燃尽图如下所示。

问题：这些任务在您团队任务板的“完成”列中于第6天被移动。您在第7天早上第一时间更新迭代燃尽图。在第7天开始时，剩余多少任务工时？
A. 50小时
B. 40小时
C. 25小时
D. 15小时

答案：第6天完成了价值25小时的任务。这意味着您在第7天开始时，剩余工作量比第6天开始时少了25小时。在第6天开始时，您有40小时剩余。减去当天完成的25小时，您在第7天开始时剩余15小时工作。因此，D是正确答案。

迭代燃尽图是否需要可调整下限？

这取决于您的团队。在大多数情况下，我认为不需要。但是，如果您的团队希望使用它，这绝对是可以轻松实现的功能。

但是，如果您的燃尽图开始“燃烧上升”怎么办？当您添加的任务多于完成或移除的任务时，就会发生这种情况。这表明您的团队在将用户故事分解为任务时，没有进行仔细的迭代规划，可能有些任务被忽视或遗忘了。显然，这不是一个好情况，尤其是在冲刺后期发生。

您通常可以通过花费足够的时间将用户故事分解为任务来避免这种情况。如果确实发现团队在迭代期间添加了大量任务，那么可以考虑移除或优先处理某些任务。这有助于确保在冲刺结束时，您的所有任务不会都处于半完成状态。

问题：这是您团队的迭代燃尽图。水平的燃尽线可能表明什么？
A. 您的团队添加的任务工时与他们完成的工时一样多。
B. 您的团队正在开始任务，但没有完成它们。
C. 您的团队没有做任何工作。
D. 您的团队正在以恒定的速度完成任务。

答案：水平的燃尽线，也称为“燃烧横线”，可能很常见且危险。答案A、B和C都代表了燃烧横线可能表明的情况。因此，答案A、B和C都是正确的。燃烧横线表明您的团队没有完成任务，因此D不正确。

正如测验所提示的，燃烧横线可能表明三件事：

您的团队添加的任务与完成或移除的任务一样多。
您的团队正在处理任务，但没有按照“完成定义”来完成它们。
您的团队在休假。

最可能是第二种情况。当燃尽图开始出现横线时，通常意味着任务已开始但未完成。如果遇到这种情况，最好的解决方案是与团队讨论，优先完成进行中的任务，而不是开始新任务。这可能意味着当团队成员有空闲时间时，他们可以帮助他人完成工作，而不是开始一个独立的新任务。如果燃烧横线持续存在，您将面临在迭代结束时用户故事处于半完成状态的风险。

我喜欢将这样的项目比作管理不善的自制家居装修项目：您想翻新房子，打算升级多个房间，并同时开始一堆任务。您拆掉了客厅的地板，拆除了浴室的台面，打磨了所有室内门，并移除了厨房水槽。结果多个房间都处于半完成状态，房子会显得混乱且无法使用。这在燃尽图上看起来就像一条燃烧横线。这并不是说您没有做任何工作，而是没有房间被完成。

总结

如您所见，迭代燃尽图能在一两天内突出显示问题开始出现的迹象。燃尽图在冲刺中期就发现任务未完成，远比在冲刺结束时才发现要好得多。迭代燃尽图是一种出色且简单的工具，可以快速识别进度何时开始偏离预期。它们有助于确保您的产品在日常基础上得到妥善管理。

本节课中，我们一起学习了迭代燃尽图的原理、其与发布燃尽图的区别、如何与Scrum任务板结合使用，以及如何解读图表中出现的异常情况（如燃烧横线）。这些工具和技术共同帮助团队在冲刺期间有效跟踪和管理进度。

049：回顾会议

在本节课中，我们将要学习软件开发中的“回顾会议”。这是一种通过反思已完成和未完成的工作，来推动项目持续改进的重要实践。

什么是回顾会议？

回顾会议是软件开发社区中使用的一个术语，用于描述对项目中已完成和未完成的工作进行反思的行为。

回顾会议背后有两个基本理念：反思项目中进展顺利的部分，反思项目中进展不顺利的部分，以及思考未来可以采取哪些措施来改进流程。

回顾会议的类型

回顾会议主要有两种基本类型：迭代回顾会议和项目回顾会议。

上一节我们介绍了回顾会议的基本概念，本节中我们来看看这两种具体类型。

迭代回顾会议

在迭代回顾会议中，团队通过反思上一个迭代周期内发生的事情来进行回顾。

还记得在敏捷规划与软件项目课程中，我谈到了时间盒，摩根谈到了迭代规划吗？这两种实践都引入了将时间组织成小的、可管理的模块的理念。

在这些时间盒模块之后，至少在敏捷项目中，安排一个计划内的自我评估会议也很重要。这就是迭代回顾会议。

在迭代回顾会议中，从团队自我评估中获得的见解会被应用到下一个迭代中，这使得项目能够定期改进。团队选择什么是重要的，什么应该被重点关注。

这赋予了团队对改进的贡献感，并让他们拥有改进的所有权。它帮助团队从内部获得成功的动力，他们不需要外部力量来推动他们改进。

项目回顾会议

在项目回顾会议中，有时也称为事后分析，团队会在整个项目被认为完成时，回顾整个项目。

项目回顾会议的一个主要区别在于，没有下一个迭代可以应用从回顾中获得的经验教训。

但这不应该阻止你进行项目回顾会议。尽管当前项目可能没有下一个迭代，但团队成员很可能还会参与其他项目。这些可能是团队共同参与的其他项目，或者团队解散后各自参与其他项目。这并不重要。

重要的是，整个团队有机会对整个项目进行反思，并将学到的经验教训带入未来的工作中，无论团队是否在一起。进行项目回顾会议的另一个非常重要的原因是，它允许团队宣泄积压的情绪。

在大多数项目中，都会存在个性差异、分歧和妥协。如果在项目结束时，这些问题没有得到解决，可能会产生不健康的影响。进行项目回顾会议使团队能够在协作、开放、无评判的氛围中解决分歧。我们将在下一课中讨论如何确保营造这种氛围。

回顾会议的价值与风险

我们已经了解了回顾会议的类型，现在来探讨其价值以及不进行回顾的风险。

进行回顾会议的价值相当明显。但是，当你避免进行回顾时会发生什么？设想一个没有进行迭代回顾会议的Scrum项目。每个迭代之后会发生什么？团队很可能会计划下一个迭代并立即投入开发。事实上，这种情况经常发生。

然而，如果不允许反思，这些项目往往会按照以前的方式继续下去，没有明确意识到项目中哪些进展顺利，哪些不顺利。人们可能有自己的感受，并且可能经常表达这些感受。但是，如果没有一个全团队的回顾会议来捕捉这些感受，就很难就哪些需要改变、哪些应该保持不变做出团队决策。

请记住，无论你的团队多么优秀，总有改进的空间。没有人是完美的，我们不是机器。因此，与其在项目中避免反思，不如鼓励反思。由此产生的改进通常是切实可见的。

小测验

以下是关于软件项目回顾会议的两个原因的问题：

A. 将从前一个项目中学到的经验教训应用到未来的项目中。
B. 保证前一个项目中的问题不再发生。
C. 允许团队成员修复彼此受损的关系。
D. 根本不应该进行事后分析。

答案是A和C。 事后分析是将经验教训应用到未来项目的好方法，同时也让人们有机会公开谈论他们的经历并修复裂痕。

总结

本节课中我们一起学习了回顾会议。我们了解了回顾会议是反思项目工作以推动改进的实践，区分了迭代回顾会议和项目回顾会议两种类型，并探讨了进行回顾会议的价值在于促进持续改进和团队健康，而避免回顾则可能导致问题重复和团队动力不足。

这就是回顾会议的内容以及你应该使用它们的原因。在下一课中，我将讨论围绕回顾会议的一些问题。我们下一课见。

050：回顾会议的问题与应对 🛠️

在本节课中，我们将探讨软件项目回顾会议（Retrospective）实施过程中可能遇到的常见问题，并学习如何克服这些问题，以建立安全、开放的团队环境，从而有效利用回顾会议推动项目持续改进。

回顾会议面临的挑战

上一节我们介绍了回顾会议的概念与价值。本节中，我们来看看在实施回顾会议时，团队可能遇到哪些障碍，以及为何有些团队选择不进行回顾会议。

团队不进行回顾会议的原因多种多样，且都看似合理，但这并不意味着它们是充分的理由。以下是一些常见原因：

团队可能出于错误的原因进行回顾，例如仅为满足审计要求。
团队可能没有足够的时间。
团队可能更倾向于向前看，而非回顾过去。
团队成员可能不愿讨论自身问题。
团队可能已精疲力竭，不想再思考项目相关事宜。

核心障碍：心理安全感

正确实施回顾会议的一个主要障碍是，团队感觉参与其中并不安全。这里的“安全”并非指人身安全，而是指情感与职业上的安全感。

心理安全感意味着团队成员能够以真实、坦诚的方式表达自己，而不必担心来自同事或管理层的负面反应。它代表着在确信自己会被倾听、会得到支持的前提下，与队友进行开放沟通的能力，无论你要表达的内容是什么。

为了更清晰地理解这个概念，请看以下示例：

皮埃尔是一名开发人员。在每日站会上，他坦诚地告诉团队自己前几天效率低下，原因是工作过度导致精力枯竭。因为他知道不会因效率低下而受到惩罚，所以他感到足够安全，可以向团队公开自己的感受。

反之，如果皮埃尔感到不安全，他可能会倾向于夸大自己前一天的工作量，使自己显得更高效，而不是坦诚沟通精疲力竭的真实问题。这表明他感到工作环境不安全，无法完全表达自己。

营造安全环境的策略

那么，如何确保团队感到安全？关键在于为开发者创造一个安全的工作环境。不同组织有类似的方法来实现这一目标，以下是几个关键策略：

首先，明确告知团队你希望营造这样的环境。声明你鼓励一种开放沟通的文化，不排斥新想法或新观点的产生。

其次，确保你对团队成员的贡献表示赞赏。在群体中表达自己并不总是容易的，没有反馈，人们很难知道自己的意见是否被重视。更糟的是，没有反馈时，许多人会默认自己的意见未被重视。因此，对贡献表示赞赏至关重要。这并不意味着你必须同意每个人说的每句话，而是让人们知道他们的贡献是有价值的。

一种方法是直接告诉每个人他们的意见受到重视。然而，如果处理不当，这可能显得不够真诚。通常更有效的方法是鼓励他人对你的观点和想法给予反馈，同时也对他人提供反馈。展示对他人想法赞赏的一个好方法是，在此基础上进一步构建想法，并将原始想法归功于最初提出它的人。这不仅验证了该想法，也肯定了提出想法的人。

另一个鼓励安全环境的关键是积极的领导力。作为产品经理，这种领导力通常从你开始。通过展示对他人的赞赏和保持积极态度，成为团队内的榜样。不要让小麻烦妨碍大局，更不要让你的个人信念妨碍你对每位团队成员给予同等高度的尊重。

回顾会议中的实践应用

让我们看看如何将上述原则应用到回顾会议中，确保你创造的安全环境能促进会议中的开放协作。

首先，你需要建立一种功能性团队文化，而非功能失调的文化。在功能性文化中，团队中的每个人都努力让其他人看起来出色。没有秘密或戒备性语言，没有信息隐藏，也没有争夺团队明星位置的竞争。在功能性团队中，每个人共享工作的所有权，因此也共享荣誉。每个人都很出色。

在功能性团队中，是团队成员个体驱动会议的成效，而非经理。因为团队知道他们的行为会影响项目，并且他们对项目拥有所有权，所以有动力采取措施进行改进。因此，功能性团队的会议是建设性的，决策来自群体。

另一个需要注意的重要点是：人们参与项目并非为了破坏它。他们是在自身技能和所处环境允许的范围内尽力而为。思考这个问题的一个好方法是类比航空飞行事故调查。航空公司和运输当局不会简单地指责飞行员工作能力差，而是会调查导致失败的所有因素，即使失败是由于人为错误。他们会调查诸如飞行员是否遵循了程序、如果没有是因为缺乏培训还是注意力不集中、或许飞行员睡眠不足等因素。通过以这种客观、可衡量的方式反思事件，更容易做出未来的改进。

课程总结

本节课中，我们一起学习了回顾会议实施过程中的主要挑战——心理安全感的缺失，并探讨了如何通过明确沟通意图、赞赏贡献、积极领导以及建立功能性团队文化来营造安全、开放的团队环境。我们了解到，回顾会议不应成为指责游戏，而是反思、改进以及建立信任关系的时机。如果操作得当，回顾会议将成为软件产品经理工具箱中可用于几乎所有项目的强大工具。

现在你已经了解了回顾会议相关的一些问题，接下来我们将深入探讨如何成功执行一次回顾会议。这将是下一节课的内容。

软件产品管理课程5：5.4.3：Sprint回顾会议 🧐

在本节中，我们将学习敏捷开发中的一个关键会议——Sprint回顾会议。我们将了解其目的、流程以及如何有效地进行，以确保团队能够持续改进其工作方式。

回顾会议既发生在迭代层面，也发生在项目层面。本节我们将重点审视Sprint回顾会议。

Sprint回顾会议应是一个Sprint中最后进行的活动。它通常在Sprint评审会议之后举行。Sprint评审会议用于向客户或产品负责人演示产品成果，而Sprint回顾会议则用于评估开发过程本身。

敏捷要求团队不仅要评审和调整产品，也要评审和调整流程。回顾会议提供了一个机会，来审视产品构建的效果如何，哪些做法有效，哪些地方可以改进。确保回顾会议的氛围安全、允许开放对话至关重要。参与者需要能够自由表达他们对本次Sprint的真实感受。如果团队不能诚实地指出问题所在，就无法产生有效的解决方案。

Sprint回顾会议的时间盒通常设定为一小时。然而，它不像其他Scrum事件那样严格。目标是保持会议简短高效，但如果出现重大问题，不应为了遵守预定时间而掩盖问题。

在引导团队进行Sprint回顾会议时，区分讨论焦点很重要。以下是回顾会议中可能出现的对话，我们来判断哪些是合适的：

A. 一名开发人员表示对产品的用户界面不满意。
B. 一名开发人员指出团队在上个Sprint中低估了任务量。
C. 你（引导者）强调了团队在上个Sprint中完成的出色工作。
D. 一名开发人员建议在下个Sprint中实施迭代燃尽图。
E. 产品负责人建议在下一个Sprint中实现某个功能。

回顾会议的重点应放在过程上，而非产品本身。因此，讨论产品功能（A和E）是不合适的。Sprint回顾会议是讨论开发过程中哪些做得好、哪些做得不好以及可以如何改进的绝佳场合。因此，讨论过程问题（B）、认可团队努力（C）和提出过程改进建议（D）都是正确的。

在Sprint回顾会议中，通常会提出三个核心问题：

本次Sprint中，哪些方面进行得很顺利？
本次Sprint中，哪些方面进行得不顺利？
为了下一个Sprint，我们可以改进什么？

建议按照这个顺序提出问题。Scrum Master应以积极的基调开始会议，对团队已完成的工作表示赞赏和认可。这有助于营造开放的氛围。通常，批评不易被接受，因此Scrum Master应引导会议，确保与会者不感到被攻击。对话应开放、诚实且相互尊重。

会议应以建设性的方式结束。这能让会议圆满收尾，避免人们带着负面情绪离开。以讨论改进方面来结束会议，能给团队带来期待，并为下一个Sprint开个好头。如果某个Sprint未能按计划进行，这一点尤为重要，因为你不希望下一个Sprint受到前一个Sprint失败情绪的影响。

有时，我们需要回顾过去才能更好地前进。在下一课中，我们将通过审视项目层面的回顾会议来扩展对回顾会议的理解。

本节总结
本节课我们一起学习了Sprint回顾会议。我们明确了它是用于评估和改进开发过程的会议，应在Sprint结束时举行。会议的核心是围绕“哪些做得好”、“哪些需改进”和“下一步行动计划”三个问题展开开放、安全的讨论。记住，会议焦点是过程而非产品，目标是促进团队的持续学习和改进。

052：项目回顾会议练习

概述

在本节课中，我们将学习如何有效地组织和执行项目回顾会议。我们将把回顾会议比作一顿包含三道菜的大餐，并详细介绍每道“菜”对应的具体练习活动，以及会前需要做的准备工作。

项目回顾会议的结构 🍽️

Kurth 将项目回顾会议比作一顿包含三道菜的大餐。

第一道菜是开胃菜，即“阅读”环节。其目的是在团队中建立信任，让团队认识到他们完成了什么，并制定一些基本规则。

最后是甜点，即“展望未来”环节。这是团队向前看、提出改进领域的机会。

任何一顿美餐都需要一些准备。因此，在“上菜”之前也必须做一些准备工作。

在本节中，我们将讨论回顾会议引导者可以在每道“菜”中使用的一些练习。课程描述假设你以外部人员的身份为另一个项目承担这个引导者的角色。

回顾会议应涵盖的主题

你正在产品发布后主持一个项目回顾会议。在项目结束时，有几个功能没有按时实现。

以下哪些应该是项目回顾会议涵盖的主题？
A. 关于未按时实现的功能的细节。
B. 为什么功能没有按时实现？
C. 团队下次可以改进哪些方面以确保所有功能都实现。
D. 哪些做法有助于按时实现功能。

与冲刺回顾类似，项目回顾旨在发现哪些方面做得好，哪些方面做得不好，以及哪些方面可以改进。你不应该讨论任何具体的功能细节。然而，你应该讨论它们是如何被实现的，以及这些做法是否有效。你还应该确定下次可以改进的领域。因此，答案 B、C 和 D 都是正确的。

会前准备工作

正如之前所说，每顿美餐都需要在会前做一些准备工作。

回顾会议会前准备材料

第一项是回顾会议会前准备材料。这是一份通过电子邮件发送给所有受邀参加回顾会议的人员的材料。它提出了一些问题，可以帮助识别会议中可能出现的任何普遍模式。它还鼓励参与者在实际的回顾会议上分享更多内容。他们更有可能分享他们已经写下来的东西。这也能让他们在会前就开始思考这个项目。

会前准备材料应提出以下问题：

为了让我们从这次经历中学到最多，需要讨论哪些主题？
你希望在回顾会议期间发生什么？
你希望这次回顾会议产生什么长期影响？
你对这次回顾会议有什么保留意见、担忧或顾虑？
当你想到这次会议时，你有什么感受？
我还应该问什么？你会如何回答？

这些问题的答复应返回给引导者。应确保参与者的答复保密，并且仅用于寻找普遍趋势。

引导者的会前沟通

如果你作为团队的外部人员引导回顾会议，请事先向团队介绍自己。这将建立信任，并让你有机会亲自讨论项目。或许可以指出你在会前准备材料中注意到的一些趋势。这也让你有机会提醒人们完成会前准备材料。人们忽略这一步而依赖记忆是很自然的。

鼓励携带项目制品

你需要做的另一项准备工作是鼓励参与者携带项目制品参加会议。

这些制品可以是项目中扮演过任何角色的任何东西。例如：备忘录、时间表、燃尽图、随意的便利贴、纪念品、图片、礼物、笔记等。

你应该鼓励参与者尽可能多地携带制品。甚至可以设置一个竞赛，为能带来最多制品、或最具创意、最不寻常的制品、以及最重要的制品的人颁发奖项或奖品。

什么是项目制品？

你正在为项目回顾会议做准备。你告诉开发团队携带任何与项目相关的制品。一位开发人员对什么会被视为制品感到困惑，想让你看看他考虑要带的东西。

以下哪些会被视为项目的制品？
A. 用户界面的原始草图。
B. 他的雇佣合同副本。
C. 在解决了一个重大问题后，有人留在他桌上的一个小奖杯。
D. 启发产品灵感的电影，这是他向客户借的。
E. 一份总结当时进展的旧备忘录。

制品的定义是包容性的。这意味着任何被某人认为对项目重要或有意义的东西都可以被视为制品。因此，所有答案都是正确的。

总结

本节课中，我们一起学习了如何将项目回顾会议结构化为一顿“三道菜的大餐”，并明确了会议应关注过程而非具体功能细节。我们重点介绍了会前准备的关键步骤：分发会前准备材料以收集初步想法、引导者与团队建立信任，以及鼓励团队携带多样化的项目制品来激发讨论。这些练习旨在帮助团队系统性地反思过去、规划未来，从而实现持续改进。

053：项目回顾会准备练习 🧩

在本节课中，我们将学习如何为项目回顾会做准备。我们将介绍一系列练习，旨在帮助团队建立信任、明确目标并创造一个安全的分享环境，从而确保回顾会富有成效。

准备阶段练习简介

首先，我们从准备阶段的练习开始。需要认识到，并非每个项目回顾会都需要执行所有练习。正如我们讨论的大多数事情一样，你需要考虑你的团队，并让会议适应你的团队。

以下是准备阶段的核心练习。

练习一：介绍练习

此练习发生在回顾会开始时，应持续约30分钟。这是确保每个人都已相互认识的好时机。如果你怀疑或知道团队成员之间或与你并不完全熟悉，现在就是进行一轮介绍的好机会。

你还应确立会议的大致时间表和议程。请记住，议程可能会根据会议的进展而改变。

一个开启介绍环节的好方法是让人们定义“智慧”一词。什么是明智？一个人如何变得明智？为什么一个75岁的老人会比一个16岁的男孩被认为更明智？这通过认识到智慧是从经验中学习获得的来开启对话，而这正是本次会议旨在达成的目标。

接下来，你应该确立并强调这不是一场指责游戏。这是介绍“凯斯首要准则”的好机会。“无论我们发现什么，我们都必须理解并真正相信，每个人在当时已知信息、其技能和能力、可用资源以及当时情况下，都已经尽了最大努力。”

为什么完成准备阶段的练习很重要？
A. 在团队中建立信任。
B. 让团队相信这次会议将产生积极成果。
C. 制定创造安全环境的基本规则。
D. 消磨时间以使会议持续整整三天。

准备阶段的练习旨在建立信任、为项目设定积极目标，并制定准则以维护团队的安全环境。它不是浪费时间的方式，因此正确答案是A、B和C。

练习二：定义成功练习

上一节我们介绍了如何开启会议，本节中我们来看看如何定义成功。此练习旨在定义团队认为的成功是什么，确定团队是否认为他们的项目是成功的，并找出他们本可以做些什么来使项目被视为成功。

在项目回顾会上，你的团队可能只记得项目后期为完成它而进行的挣扎和冲刺。他们会专注于出错的地方。退一步认识到团队的成功和成就是有益的。即使项目失败了，团队也有很多值得骄傲的地方。

回顾会的这一部分应持续30分钟到1小时。

通过询问团队“这个项目成功吗？”来开启小组讨论。记录回答。然后，你想向团队展示他们完成的一切。向他们展示他们在项目中付出的努力。最后，用以下成功定义来结束此练习：一个成功的项目是每个人都说“我希望我们能以完全相同的方式再做一次”的项目。

安全是在回顾会中需要确立的重要事项。如果团队觉得会有不良后果，他们将无法有效地分享所有需要分享的内容。

有哪些方法可以在回顾会中建立安全感？
A. 设定基本规则。
B. 团队如何认识会议目标。
C. 使练习成为可选项。
D. 逐步引入困难话题。

这些都是你可以在回顾会中建立安全感的方法，我们将在后续内容中介绍如何在你的会议中实施这些方法，为你的团队创造一个安全的环境。

练习三：建立安全感练习

现在，让我们继续讨论建立安全感的练习。此练习旨在确保团队中的每个人都感到足够安全，可以分享他们对项目的感受。如果团队彼此之间已经相当熟悉，或者对参与回顾会的实践已经很适应，那么你可以考虑跳过此练习。

你应该确立的第一点是，回顾会中的每个练习都是可选的。如果人们感到被迫参与，他们更可能说他们认为应该说的话，而不是他们真实的想法。

然后，你应该进行一次无记名投票，以确定团队感到的安全程度。让他们写一个1到5之间的数字，代表他们感到的安全程度。1表示他们感到不安全，不会分享真实感受。5表示他们感到足够安全，可以分享任何事情。如果每个团队成员都表示3或以上，那么你就可以安全地继续会议。

接着，你应该为回顾会制定一些基本规则。让团队创建能鼓励他们感到更安全的规则。如果团队没有自己提出，你应该添加这些规则：1. 参与回顾会是可选的。2. 我们不会拿房间里的任何人开玩笑。3. 基本规则可以在任何休息后修改。

你应该添加到团队创建的规则列表中的一条规则是“我们不会拿房间里的任何人开玩笑”。为什么这是一条需要实施的重要规则？
A. 这是一个严肃的会议，任何玩笑都是不合适的。
B. 有时很难分辨一个玩笑是出于好玩还是伤人。
C. 如果人们认为可能会成为被取笑的对象，这会阻碍他们分享。
D. 你想专注于取笑那些不在房间里的人。

有时很难识别一个玩笑的意图，或者它可能被误解。一个本意为好玩的玩笑可能被接收者理解为伤害。最安全的做法就是完全避免它们。这条规则也很重要，因为如果人们认为可能会成为被取笑的对象，他们可能会不愿意分享。因此，正确答案是B和C。

练习四：项目成果展示竞赛练习

本课我们将讨论的最后一个准备练习是项目成果展示竞赛练习。我在本课前面提到过项目成果。鼓励参与者带来他们能找到的与项目相关的任何及所有成果。

此练习应持续一到两小时。这将取决于团队人数和他们带来的成果数量。

首先让人们解释他们的成果。它为什么对他们或项目很重要？询问关于成果的问题，并鼓励其他人也这样做。

在所有成果都展示完毕后，是时候对成果进行投票了。首先确定最大的成果集合，然后让人们提名并投票选出最具创意或最不寻常的成果，以及最重要的成果。你应该为这些类别的获胜者准备小奖品。

总结

本节课中我们一起学习了为项目回顾会做准备的四个关键练习：介绍练习、定义成功练习、建立安全感练习和项目成果展示竞赛练习。这些练习共同为富有成效的回顾会奠定了基础，帮助团队建立信任、聚焦成功、创造安全的分享环境，并全面回顾项目历程。

054：项目回顾练习之“回顾过去”

在本节课中，我们将学习项目回顾会议中用于“回顾过去”部分的具体练习方法。这些练习旨在帮助团队系统地回顾项目历程，识别关键事件、总结经验教训并增进团队凝聚力。

概述：回顾过去的核心练习

上一节我们介绍了项目回顾会议的整体结构，本节中我们来看看专门用于审视项目历史的几个核心练习。这些练习包括创意时间线、挖掘宝藏、情感地震仪和表达感谢，它们共同构成了深入分析项目过往的基础。

创意时间线练习

创意时间线练习旨在可视化项目的完整历程，迫使团队从头回顾项目中发生的所有重要事件。

具体步骤如下：

清理一面墙或白板，并贴上纸张。
给每位成员一叠索引卡或便利贴。
团队成员使用这些卡片在时间线上标记重要事件。
如果适用，先让成员标记自己加入项目的时间点。
如果有成员在项目结束前离开，也标记他们的开始和结束日期。
然后，团队开始共同创建重要事件列表。这是一个包容性的过程，任何成员认为重要的事件都应添加到时间线上。

活动结束时，你将获得一个代表整个项目及其所有事件的视觉化图表。

挖掘宝藏练习

在创建时间线之后，下一个练习是挖掘宝藏。在此练习中，团队将按时间顺序分期回顾时间线。

以下是进行此练习的步骤：

在房间内准备五块白板或图表纸，分别标注以下主题：
- 我们做得很好且不希望忘记的事情。
- 我们学到的东西。
- 下次我们应该以不同方式做的事情。
- 仍然让我们困惑的事情。
- 我们需要更详细讨论的事情。
在讨论每个时间段时，团队成员可以建议将相关内容添加到这些主题下。
为了促进讨论，在回顾各时期时应提出以下问题：
- 哪张卡片最重要？
- 哪张卡片让你感到惊讶？
- 哪些卡片你不理解？
- 你看到任何出现的模式吗？
- 我们应该接下来讨论哪张卡片？
- 哪张卡片还需要讨论？

这个练习需要投入时间，大约需要5到8小时，最好分两天进行。这是对项目中发生的一切进行深入调查的过程。

将创意时间线练习分两天进行很重要，原因如下：

A：八小时专注于一个话题时间太长。
B：给团队时间反思项目。

因此，A和B都是正确答案。长时间的专注需要休息，而经过一夜的反思通常能产生更好的结果。

情感地震仪练习

在创建时间线并进行反思后，可以进行情感地震仪练习。这个活动有助于探索触发情绪的事件，从而帮助理解项目的深层意义。

具体操作是：让参与者在时间线下方画一条线，用以代表他们在当时的情感波动。这有助于从项目中识别出那些引发强烈情绪的重要事件。

表达感谢练习

我们要探讨的最后一个“回顾过去”的练习是表达感谢。这个练习可以在回顾会议中根据需要多次进行，或在任何时间点进行。

表达感谢练习为团队提供了相互表达赞赏的机会。在表达感谢时，措辞应更具个人色彩，例如：“莎娜，我感谢你帮助我学习Java”，而不是“我感谢莎娜帮助我学习Java”。使用“我感谢你为了…”的句式更亲切。

以下是进行此练习的步骤：

所有人站成一个圈。
由一个人开始，向圈内的另一个人表达感谢。
接收到感谢的人，再向其他人表达感谢。
如此继续，直到每个人都收到至少一次感谢。

这个练习有助于修复关系并提升团队士气。

总结

本节课中我们一起学习了项目回顾会议中“回顾过去”环节的四个关键练习。我们掌握了如何通过创意时间线可视化项目全貌，通过挖掘宝藏深入分析各阶段并归类见解，通过情感地震仪关联事件与团队情绪，以及通过表达感谢来加强团队纽带。这些结构化工具能有效引导团队从过往经历中系统性地学习与成长。

055：项目回顾练习——展望未来 🚀

在本节课程中，我们将学习项目回顾会议中“展望未来”环节的核心练习。我们将重点介绍两个关键活动：“创造奇迹”练习和“结束回顾”练习，它们旨在帮助团队坦诚讨论敏感话题，并以积极、富有建设性的方式结束会议。

上一节我们介绍了回顾会议中分析过去的练习，本节中我们来看看如何引导团队面向未来，识别改进机会并规划行动。

创造奇迹练习 🪄

此练习旨在引导团队讨论那些被回避的敏感话题。在回顾会议的这个后期阶段，团队通常已更愿意分享感受，并对项目有了更深入的集体理解。团队也开始意识到回顾即将结束，如果此时不提出敏感话题，可能就再也没有机会讨论了。作为引导者，你需要邀请大家进行这场艰难的对话，然后退后一步，让对话自然发生。奇迹往往就在这里发生，人们通常会开始分享他们一直回避的事情。

以下是启动此对话的几种方式：

直接邀请：你可以这样说：“这次回顾即将结束。现在是提出任何你希望讨论但尚未提及的事情的好时机。”
暗示引导：你可以提及在整个回顾中你察觉到的一些线索。
开门见山：如果以上方法无效，可以直接提出：“我们已经花了好几天时间讨论所有事情，除了一个非常重要的问题。”

让团队讨论这个问题或这些问题，并尝试提出解决方案。你只需观察其展开，并引导其走向正确的方向。

情景模拟与引导技巧

假设团队正在进行“创造奇迹”练习，讨论一个敏感话题。一位开发人员感到工作过度且被利用。讨论开始变得具有攻击性和伤害性。

你应该如何将讨论带回相互尊重的轨道？

A. 完全停止讨论。
B. 回顾之前共同制定的会议准则。
C. 让其继续，他们会自己解决。
D. 开始提问，询问某些行为如何让他们感受，或他们为何以某种方式行事。

正确答案是 B 和 D。让讨论继续下去很重要，但必须以尊重的方式进行。如果有人明显违反了既定准则，应提醒他们规则及其制定的原因。如果这不起作用，你可以通过提问来引导讨论，例如询问某些行为如何影响他人感受，或行为背后的原因。在大多数情况下，人们并非心怀恶意，而是存在一些误解。引导讨论去揭示这些误解是关键。

结束回顾练习 🎯

这个活动用于收尾回顾会议，并处理所有未竟事宜。它帮助团队以积极、充满希望的方式结束会议。

以下是进行此练习的步骤：

给团队每位成员分发纸和笔。
请他们写下希望在回顾会议结束后能看到实现的一个“希望”或“愿望”。
告诉他们写下一些可以匿名与团队分享的内容。
收集所有卡片并打乱顺序。
给每人发一张卡片，让他们阅读。
在小组内传递卡片，直到每个人都阅读了所有卡片。
在每个人都阅读完所有卡片后，用一句积极的话语结束会议，例如：“我认为我们在过去几天取得了很大进展。我相信很多这些希望和愿望都会实现。现在，就看你们的了，去让它发生吧！”
最后，正式宣布：“本次回顾会议到此结束。”

本节课中我们一起学习了项目回顾会议中“展望未来”阶段的两个核心练习。“创造奇迹”练习鼓励团队勇敢讨论敏感议题，而“结束回顾”练习则以收集匿名希望与愿望的方式，赋予团队行动的责任感与积极的结束氛围。这些练习能有效促进团队沟通，并为后续改进奠定基础。

如果你想了解更多关于回顾练习的细节，可以参考 Norman L. Kerth 的著作《Project Retrospectives: A Handbook for Team Reviews》。

至此，本课程（顶点项目前的最后一课）内容全部结束。期待在顶点项目中与你相见！😊

056：《软件改进的评审与度量》课程总结

在本节课中，我们将回顾整个课程的核心内容，总结如何通过评审与度量来改进软件产品、流程和项目管理。

模块一：确保构建正确的产品

在第一个模块中，Morgan探讨了如何确保你正在构建正确的产品。她描述了迭代评审会议、用户研究、产品成功标准，以及行业中用于创建成功且设计精良产品的流程示例。

模块二：确保以正确的方式构建产品

接下来，Bradley描述了如何确保开发人员以正确的方式完成流程，以实现高质量的产品。这涉及同行评审技术，例如：

走查
技术评审
审查

他还介绍了度量的目的、一个用于指导其使用的目标导向框架，以及一些良好和不良度量的例子。

模块三：确保项目得到正确管理

在第三个模块中，Bo详细说明了如何确保项目得到正确管理。她讨论了：

每日站会
优先级排序
发布迭代
用于监控进行中和已完成工作状态的燃尽图和任务板。

模块四：通过回顾进行改进

在这个最终模块中，Brad解释了两种回顾会议：

迭代回顾
项目回顾

两者都旨在承认问题、认可贡献，并总结经验教训以改进未来的工作。

课程核心总结

在本课程中，我们涵盖了许多方法来发现改进产品、流程和项目的途径，以实现 “正确的产品”、“正确地完成” 和 “正确地管理” 的目标。

由于这是专项课程的第五门课，下一门课是顶点课程。如果将整个专项课程的结构比作一个人体，那么顶点课程就相当于至关重要的头部，它建立在代表前面课程的双腿、躯干和手臂之上。顶点课程将汇集你目前所学的大部分知识。在那里，你将在一个模拟环境中应用敏捷方法论，与用户和利益相关者互动，定义产品的用户故事，对产品待办列表进行优先级排序，规划发布，获取反馈，处理变更，跟踪进度，应对风险等等。

期待在那里与你相见。

posted @ 2026-03-29 09:33 布客飞龙II 阅读(5) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

人最大的痛苦就是说一些自己都不相信的话。

阿尔伯塔软件项目管理-V-笔记-全-

阿尔伯塔软件项目管理 V 笔记（全）

001：《软件改进的评审与度量》｜专项课程预告

概述

总结

002：评审指标简介以改进软件

概述

三个目标与对应的反馈机制

1. 正确的产品

2. 正确地执行

3. 正确地管理

本课程结构

总结

003：监控简介

概述

敏捷术语回顾

冲刺评审会议详情

Scrum活动与时间盒

会议参与者

会议中的角色

会议流程

1. 产品演示

2. 产品负责人批准

3. 利益相关者反馈

总结

005：用户研究

006：行业范例 🏢

苹果公司的设计流程 🍎

谷歌的设计冲刺流程 ⚡

Intuit的“跟我回家”验证法 🏠

IBM的设计思维实践 💡

007：行业范例访谈

008：评审技术 🧐

软件走查 🚶‍♂️

软件技术评审 🔧

总结 📝

009：评审技术

软件审查概述

审查中的角色

审查的阶段

严格的完成标准

需求技术评审

评审阶段

问题严重性分级

讨论会议阶段

修复过程

需求审查

总结

010：监控问题 🔍

概述

总结

概述

总结

012：好的度量属性 📊

关键术语定义

什么是“坏”的度量？

度量的理想属性

一个“好”度量的例子

总结

013：其他度量

概述

度量可维护性

度量性能

度量可靠性

度量产品成功

总结

014：缺陷分析

概述

缺陷分析的基本方法

缺陷发现率与修复率

子系统缺陷分析

缺陷密度

缺陷分析实战案例：航天飞机飞行软件

总结

015：每日站立会议 🎯

概述

会议目的与结构

参与者角色：“猪”与“鸡”