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

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

001：专项课程预告

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

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

这套系列课程将教你如何成功引导一个软件产品从构思到交付的整个开发过程。阿尔伯塔大学被认为是世界领先的公立研究型与教学密集型大学之一。

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

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

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

我们的计算专家团队将为你提供掌握敏捷软件开发所需的过程和实践。

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

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

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

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

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

很高兴你对参加我们的专项课程感兴趣，我们已经尽力使这成为一次有益的教育体验。

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

002：1_敏捷软件产品计划简介 🎯

概述

在本节课中，我们将学习《面向软件产品的敏捷规划》课程的总体介绍。我们将了解本课程在专项课程体系中的位置、核心目标以及将要涵盖的关键规划类型。

我是 Ken Wang。

欢迎来到《面向软件产品的敏捷规划》课程。

这是软件产品管理专项课程的第四门课。

本课程建议您在完成《软件过程与敏捷实践》以及《客户需求与软件需求》两门课程后学习。

前两门课程如同橡树的两条腿，构成了专项课程的基础结构。

本课程则将作为橡树的躯干，放置于双腿之上，进一步完善整个知识体系。

在本部分，我将为您预览《面向软件产品的敏捷规划》课程。

我之前提到，打造更好的软件涉及三个目标：正确的产品、正确地完成以及正确地管理。

本课程专注于敏捷规划技术，以确保软件产品项目得到妥善管理。

其核心在于有效地组织工作，同时适应变化。

通过本课程分享的技术，我们可以确保软件过程和敏捷实践被正确执行，并最终实现正确的产品。

本课程汇集了前两门课程的许多基础知识。例如，您将识别出软件需求中的用户故事概念、Scrum方法论中的冲刺，以及过程管理中的时间盒。

本课程将在此基础上进行构建。

无论您是直接管理团队还是通过他人管理，您都会认识到软件项目涉及的三种关键规划类型：发布规划、迭代规划和风险规划。

我们将在本课程的第二、三、四模块中分别讲解这些内容。

课程模块预览

以下是本课程各模块的核心内容简介。

第一模块：工作分解与估算基础

在第一模块中，Morgan将阐述项目需要解决的各种不确定性。

她还将展示如何将工作分解为可管理的部分。

她也会解释估算、目标和承诺之间的区别。

第二模块：发布规划与故事点估算

在第二模块中，Bli Poette将解释如何使用故事点来估算需求的规模。

他还会解释估算如何与速率相关联，后者是衡量开发团队生产力的一种方式。

他将展示如何使用时间盒作为规划工作的基础，进而可以制作成燃尽图。

这最终导向构建一个发布计划，以规划在即将到来的冲刺中交付哪些用户故事。

第三模块：迭代规划与任务管理

在第三模块中，Morgan将回归，描述如何估算任务时间并确定任务依赖关系。

她将展示如何使用关键路径法图和甘特图在任务级别规划工作。

这导向构建一个迭代计划，以规划在下一个冲刺中需要完成的任务。

第四模块：风险识别与管理

在第四模块中，Brad将详细说明可能导致项目失败的问题或风险。

他将描述一系列反模式，即对项目及其人员产生负面后果的情况。

您将学习如何评估风险并确定需要采取何种级别的应对措施。

这导向构建一个风险计划，以规划在风险发生时应采取的行动。

总结

在本节课中，我们一起预览了《面向软件产品的敏捷规划》课程的全貌。通过本课程的学习，您将获得一套有效的技术，帮助您规划下一个项目并创造出优秀的软件产品——一个被正确管理的产品。

003：计划简介

在本节课程中，我们将学习软件项目规划的基础概念。我们将了解如何将项目分解为更小的组成部分，并介绍规划过程中将使用到的核心术语。

概述

在本节课中，我们将要学习软件项目规划的策略与技巧。这些技巧与敏捷宣言的原则一致，能使您的项目更好地适应变化。规划软件项目的关键在于将工作负载分解为更小、更易管理的任务。

我们将从理解如何细致地描述和组织任务开始。接着，我们会学习如何分解大型活动。您还将学习如何创建时间和工作量估算，以便准确地安排所需工作。

软件项目有多种规划方式。我们将涵盖发布层面和迭代层面的规划。发布是指将产品交付至可上市的状态。一个发布通常由多个迭代组成。您使用发布计划来整体规划项目，这包括决定哪些需求将在每个迭代中完成。您使用迭代计划来规划特定迭代中要完成的任务。

您将学习发布规划技巧，例如甘特图和发布计划。您也将学习迭代规划技巧，例如PERT图、CPM图和迭代计划。我们将在课程中详细讲解所有这些技巧。

我们还将涵盖风险规划。正如在介绍性课程中提到的，风险规划是软件规划的重要组成部分。软件开发中可能出现许多风险，因此您需要为这些风险做好准备，以避免对创建和支持产品产生负面影响。

核心概念回顾与引入

让我们花点时间回顾一下之前课程的内容。在“软件过程与敏捷实践”课程中，我们谈到了“任务”这个术语。任务的定义是什么？

A. 一个人承担或扮演的职责。
B. 项目中要完成的一个小的、可管理的步骤。
C. 软件过程产生的输出。
D. 衡量进度的内部检查点。

在“软件过程与敏捷实践”课程中，我们将任务定义为项目中要完成的一个小的、可管理的步骤。因此，B是正确答案。答案A定义了角色，答案C定义了工作产品，答案D定义了里程碑。这些都是我们即将更详细讨论的术语。

接下来，我们将从分析上一个测验中出现的术语开始，并引入本课程将使用的一些新术语。

任务

任务被定义为项目中要完成的一个小的、可管理的步骤。任务是项目的核心。项目中发生的所有事情都可以分解为任务。我们将在本模块后面讨论如何将项目分解为任务。在规划中，您将频繁使用任务来为项目创建估算和进度表。

角色

我们在“软件过程与敏捷实践”课程中定义了角色。角色是一个人承担或扮演的职责。角色的例子包括程序员、测试员、设计师、客户和产品经理。角色执行任务，例如，程序员可能承担为某个功能编写源代码的任务。

工作产品

工作产品在“软件过程与敏捷实践”课程中也有涉及。我们将其定义为由任务或过程产生的输出。

任务不仅产生工作产品作为输出，它们也使用工作产品。一个任务产生的输出工作产品，可以作为后续任务的输入工作产品被使用。

让我们看一个例子。假设程序员角色承担了为特定功能编写测试的任务。该任务产生一个工作产品：该功能的测试用例。这些测试用例是执行测试任务的输入工作产品，因为执行测试这个任务要求事先写好测试用例。

依赖关系

正如我们在讨论工作产品时看到的，执行测试的任务依赖于编写测试的任务，因为一个任务的输出工作产品是另一个任务的输入。在规划时，您需要牢记这些依赖关系，以便以逻辑顺序安排任务。

知识应用

您正在与一个开发团队合作，创建一个允许学生提问作业问题并从在线导师那里获得帮助的网站。学生也会被引导至教程和相关资源链接。您在安排任务时，遇到了“为与导师的在线聊天编写源代码”这个任务。

以下哪个任务必须安排在“为与导师的在线聊天编写源代码”这个任务之前？

A. 上传供导师参考的教程视频。
B. 为在线聊天功能进行验收测试。
C. 设计在线聊天工具。
D. 雇佣在线聊天的导师。

上传视频是一个可以在开发后期才实施的任务。雇佣导师取决于在线聊天功能能正常工作，因此不会安排在此任务之前。所以，答案A和D不正确。

答案B很接近，但也不正确。进行验收测试依赖于源代码已被编写完成。为此功能编写源代码的任务必须安排在验收测试之前。

功能需要在程序员开始编程之前进行设计。因此，答案C正确。设计在线聊天的任务必须安排在为在线聊天编写源代码的任务之前。

总结

本节课中，我们一起学习了软件敏捷规划的基础。我们明确了任务、角色、工作产品和依赖关系这些核心概念的定义。任务是小而可管理的步骤，角色是人员职责，工作产品是任务的输入或输出，而依赖关系则决定了任务执行的逻辑顺序。理解这些概念是进行有效项目规划的第一步。在接下来的章节中，我们将深入探讨如何应用这些概念来分解工作、估算时间和制定计划。

004：3_第4.1.1a节计划简介

在本节课程中，我们将介绍计划中的几个核心概念：时间表和里程碑。理解这些概念是进行有效项目规划的基础。

时间表：任务与时间线的映射

时间表是将任务映射到时间线上的过程。任务是一个项目的基本组成部分。正如之前课程所讨论的，任务之间基于其工作成果存在依赖关系。

识别任务的依赖关系是创建时间表的重要步骤。你需要以这样的方式将任务映射到时间线上：确保作为输入所需的工作成果在其被需要之前已经创建完成。同时，你还需要确保高优先级的需求被优先完成。这意味着你需要规划在每一次迭代中要完成哪些内容。

这听起来可能有些复杂，但本课程将向你展示有效安排这些内容的技术。

里程碑：衡量进展的内部检查点

接下来，我们谈谈里程碑。里程碑是用于衡量项目进展的内部检查点。它们不是基于时间的，而是基于事件或行动的。

里程碑可用于衡量项目的进度。然而，它们在线性流程和早期迭代流程中更为常见。你在关于软件流程和敏捷实践的课程中已经学习过这些流程。

回顾之前课程中对敏捷宣言的探讨，我们了解到在敏捷方法中，通常不设置里程碑。进展是通过可工作的软件来衡量的，而不是通过事件。所有的发布和迭代都是基于时间的，因此它们不符合里程碑的定义。

案例分析：识别正确的里程碑

让我们通过一个案例来加深理解。Sierra正在开发一个允许用户监控和追踪月度支出的项目。她和她的开发团队决定基于里程碑来衡量进度。

以下哪项是里程碑的示例？
A. 一个为期两周的冲刺结束。
B. 项目启动一周年纪念日。
C. 产品的截止日期。
D. 需求已编写并评审完成。

分析：里程碑不是基于时间的。因此，一个为期两周的冲刺结束不是里程碑，因为它是以两周时间为衡量标准的。同样，一周年纪念日也是基于时间的。所以，选项A和B不正确。

截止日期可能被视为一个里程碑，但它仍然是基于时间的，因此选项C也不正确。如果Sierra想将其表述为里程碑，更好的措辞是“最终产品已交付”。然而，最终产品交付的日期并不总是产品的截止日期。

选项D不是基于时间的，而是基于行动的。当所有需求都已完成编写和评审时，你就知道这个里程碑已经达成。这可以是一个项目的主要里程碑。因此，选项D是正确答案。

任务：从需求到开发

正如本课前面所说，项目中发生的所有事情都可以分解为任务。它们是规划的一个重要方面，也在之前的课程中扮演了重要角色。

在关于客户需求和软件需求的课程中，你学习了如何创建需求。一旦你创建并确定了软件需求的优先级，就需要将它们分解为需要完成的开发人员任务。

让我们看一个例子。假设我们正在创建一个允许用户浏览电子书（像一个虚拟图书馆）的应用程序。我们的一个需求是：“作为一名读者，我希望能够基于关键词搜索书籍，以便找到包含我所寻找的文本内容的书籍。”

我们有了一个需求，但你的开发团队如何将其转化为产品的一部分呢？以下是从这个需求可能衍生出的一些开发人员任务示例：

设计关键词搜索工具。
获取或开发关键词搜索算法。
编写关键词搜索工具的源代码。
测试关键词搜索工具。

开发人员任务可以更具体地涉及技术，而需求则应独立于技术。通过开发人员任务，开发团队正在为问题提出解决方案。这些开发人员任务通常使用迭代计划来安排，你将在本课程后续部分学习如何操作。

任务在流程与敏捷中的作用

在关于软件流程和敏捷实践的课程中，我们讨论了任务如何构成活动，活动又如何构成阶段。每个阶段都有要完成的特定任务。因此，任务对于创建流程至关重要。

任务在敏捷实践中也扮演着重要角色。敏捷实践提供了组织任务并确保其有效完成的方法。使用迭代计划是Scrum方法论中常见的一种敏捷实践。正如之前提到的，迭代计划是一种安排任务的技术。而看板则是一种通过一系列步骤可视化追踪任务进展的方式。

总结与预告

现在，你已经掌握了开始深入学习规划知识的良好基础。在下一课中，你将学习不确定性空间以及如何在项目中导航。我们下节课再见。😊

005：不确定空间

概述

在本节课程中，我们将学习一个用于理解和管理软件项目不确定性的核心模型——不确定空间图。我们将探讨项目中“做什么”和“怎么做”这两类不确定性，并学习如何规划路径以高效地降低它们。

启动一个软件项目可能令人望而生畏。从哪里开始，到哪里结束。你的团队将如何开发，以及开发什么。你如何驾驭所有这些不确定性。

研究员兼项目经理亚历山大·莱弗指出，需要同时处理两种类型的不确定性。Scrum方法的贡献者之一迈克·科恩用一个基于不确定性的图表描绘了这个问题。

该图表用于展示产品从概念、经过开发、到可运行状态的过程中，不确定性的水平。对于每个产品，你需要弄清楚你要创造什么以及你将如何开发它。

当你开始时，两者的不确定性都相当高。理想情况下，你希望确切地知道你要生产什么，以及你的团队将如何实现它。现实中，存在很多不确定性，需求会变化，方法也会变化。

这个不确定空间图沿X轴衡量“方法不确定性”。“方法不确定性”是你项目的“如何”。你将如何开发这个产品？你的项目应该从高方法不确定性走向低方法不确定性。

该图沿Y轴衡量“目标不确定性”，这是你项目的“什么”。你实际上在开发什么？同样，这种不确定性应该从高走向低。

观察不确定空间图上的这些点。

以下是这些点的描述：

点A：高方法不确定性，高目标不确定性。
点B：高方法不确定性，低目标不确定性。
点C：低方法不确定性，高目标不确定性。
点D：低方法不确定性，低目标不确定性。

在项目结束时，你希望你的产品处于图表上的哪个位置？

A，高方法不确定性，高目标不确定性；B，高方法不确定性，低目标不确定性；C，低方法不确定性，高目标不确定性；或D，低方法不确定性，低目标不确定性。

希望在项目结束时，你的团队具有低方法不确定性，这样你就知道如何创建或已经创建了你的产品。具有低目标不确定性说明你知道你在创造什么，因此，答案D是正确答案。目标或方法中任何一项具有高不确定性，都表明产品存在一些待解决的不确定性。

上一节我们介绍了不确定空间图的基本概念，本节中我们来看看如何利用这个图表来规划项目路径。

让我们看看一些使用此图导航项目的方法。

一种导航项目的方法是先弄清楚你要创造什么，然后再弄清楚你将如何创造它。这种方法要求你在规划完成这些需求的任何方法之前，预先详细确定所有需求。这类似于遵循瀑布流程。如图所示，在方法不确定性水平开始显著变化之前，目标不确定性水平已经很低。

这种导航方式不允许需求轻易改变，因为它们都是预先确定的，因此不是很敏捷。

或者，你可以先确定如何开发产品，然后在开发过程中创造产品。这种类型的开发属于临时开发，它涉及很少的规划，基本上开发团队会边想实现方案边拼凑产品。这不是一种非常合乎逻辑的软件开发方式，可能导致工作浪费。

你最好的选择是在中间某个路径导航。让我们用另一种方式可视化这一点。

想象一下，在你家和学校之间有一个足球场。你的家和学校在对角。如果你从学校走回家，你可能不会绕着场地走回家。如果你斜着穿过场地，距离会短得多。

类似地，斜着穿过不确定空间所需的工作量也少得多。然而，开发过程通常不会沿直线进行。

常见的情况是，在你开始设计如何完成需求之前，你会与客户和开发团队一起定义大部分需求。一旦确定了需求，你和你的开发团队将开始规划解决方案。此时，项目的目标和方法的确定性更高，这是开始开发的好地方。然后，需求会发生变化或被添加。同样，你的解决方案也会改变。你的开发团队将实施这些更改，并朝着目标和方法的低不确定性目标努力。

无论你在不确定空间中采取何种路径，你都将完成任务。在下一课中，你将学习如何将工作分解为任务。

总结

本节课中我们一起学习了“不确定空间图”这一重要工具。我们明确了软件项目中存在的两种核心不确定性：目标不确定性和方法不确定性。一个成功的项目应力求在结束时达到两者都低的理想状态。我们探讨了不同的项目导航路径，并认识到最有效的路径通常是斜向穿越不确定空间，在逐步明确“做什么”的同时，也迭代地确定“怎么做”，这正体现了敏捷规划的核心思想。

006：工作分解结构

概述

在本节课中，我们将要学习一个关键的规划工具——工作分解结构。我们将了解如何将一个庞大、复杂的软件产品项目分解为更小、更易于管理的部分，从而为后续的任务分配、风险评估和时间估算奠定基础。

将整个软件产品视为一个整体来创建，这个过程可能会令人望而生畏。你需要构思许多功能，设计各个方面，编写大量代码，并进行测试，才能得到一个功能完备的软件产品。在此期间，你可能还需要安排市场营销、技术支持和运营等事宜。

正如你已经知道的，你不能简单地告诉开发团队“去开发一个应用程序”。在幕后需要进行大量的规划工作。无论开发团队是否意识到，他们都会将项目分解成更小、更易于管理的部分。将项目分解成小而易于管理的部分，是创建和规划软件产品的关键步骤。

在关于软件过程和敏捷实践的课程中，我们讨论过过程的结构，即一个过程如何被分解为阶段，阶段再分解为活动，活动可以进一步分解为任务。当你将一个大型软件过程分解为可管理的任务时，它就不再显得那么难以应付了，只需一次处理一个任务即可。

与过程可以分解为任务类似，你也可以将一个大型项目（例如创建一个应用程序）分解为小而易于管理的任务。将软件产品需要完成的工作分解为任务工作产品，对规划非常有帮助。我们称之为工作分解结构。

创建工作分解结构在项目管理中非常普遍。工作分解结构将一个大型工作产品分解为更小、更易于管理的工作产品，形成一个层次结构。创建工作分解结构的方法是审视大型工作产品。通常，这将是你的团队将要交付的整体产品。然后，将这个工作产品分解为更小的工作产品。

这些较小的工作产品会被反复分解，直到每个都足够小且足够清晰，可以分配给一个人。在将这些工作产品分解到多小的问题上需要平衡。如果它们太小，会导致微观管理。

根据经验，你应该将工作产品分解到可以合理地让一个人来创建每个工作产品的程度。例如，假设你正在分解建造房屋的项目，具体是房屋内电气系统布线的任务。你可以将每个任务分解得越来越小，直到达到这样的程度：第一，剥掉电线末端四分之一英寸的绝缘层；第二，将电线插入插座。显然，这是微观管理。一旦达到与角色相关的专业水平，就不再需要任务分解了。因此，在这种情况下，总承包商可以概述安装电气系统的任务，但不需要将事情分解到超出电工理应知道如何做的范围。

维多利亚是一名正在开发一款动画视频游戏的产品经理。她正在制定她的工作分解结构，但不确定应该将她的工作产品分解到什么程度。这款视频游戏旨在拥有出色的背景视觉效果和图形，包括一个描绘繁星满天的夜景背景。以下哪一项会是合适大小的工作产品？A，动画视频游戏；B，所有绘图；C，所有背景；D，夜景背景；或 E，一颗星星。

创建整个动画视频游戏的工作产品对于一个人来说太大了，因此答案A不合适。创建动画视频游戏所有绘图的工作产品也是一项太大的任务，因此答案B不正确。创建所有背景现在是一个更合适大小的工作产品，但这仍然可以分解为更合理的规模，所以让我们排除答案C。答案D是一个相当好的工作产品规模。你可以合理地分配创建那个夜景背景的任务给一个人。分配一个人单独画一颗星星的任务太小了，你的工作分解结构会变得非常庞大。因此，答案D是正确答案。

学习如何将产品分解为工作分解结构的最简单方法是看一个例子，所以让我们一起看一个。在我们的例子中，我们将分解构建一个新闻应用程序的任务。这个应用程序将为一家全球新闻公司展示新闻。在应用程序中，用户可以浏览头条新闻、阅读文章，并查看不同的版块，如财经或娱乐。该应用程序还具有实时嵌入式小部件，用户可以在其中查看关于变化信息（如天气和股票）的实时更新。

对于我们的工作分解结构，我们的整体工作产品是新闻应用程序。构建新闻应用程序的任务可以分解为四个主要的工作产品类别。它们是：内容、UI图形、编程和文档。现在，每个工作产品类别都有自己的一组工作产品。例如，在内容中，我们需要创建头条新闻版块、新闻报道和广告。在UI图形中，我们需要创建应用程序中使用的徽标和按钮。在编程中，我们需要编程链接，将你带到内容中的某个页面。除此之外，我们还需要编程应用程序的布局，使其能在多种设备上工作。我们还需要编程实时嵌入式小部件。在文档中，我们需要创建用户手册或帮助页面，以及内部文档。

这些工作产品中的每一个又有相关的工作产品。让我们更详细地看看编程工作产品，以便更好地理解这一点。编程工作产品被分解为三个相关的工作产品：链接、布局和实时嵌入式小部件。由于这些都是编程项目，我们需要为每个工作产品创建源代码；因此，源代码是每个工作产品的一个工作产品。事件处理程序的工作产品将有关联的工作产品：单元测试和验收测试。回顾之前的课程，单元测试用于测试源代码的低级功能，并且应该在编写源代码之前编写。验收测试验证整个应用程序。因此，在这种情况下，单元测试将确定链接是否正常工作。验收测试将测试界面，以确保没有链接损坏，并且所有链接都能将读者带到你预期的位置。要编程布局，你还需要首先设计它。因此，布局设计将是一个相关的工作产品。你还需要验收测试来确保布局在多种设备上兼容。对于实时嵌入式小部件工作产品，我们还需要测试其功能。因此，单元测试和验收测试也将是相关的工作产品。

你可以使用工作分解结构中的工作产品来创建供开发人员完成的相关任务。以下哪一项会是我们刚刚看到的例子中的相关任务？A，为实时嵌入式小部件编写单元测试。B，创建一个新闻应用程序。C，为用户界面布局创建设计。D，向应用程序添加内容。和/或 E，为读者聊天室创建源代码。我们希望我们的任务是基于层次结构中最小的工件来创建的。因此，“创建一个新闻应用程序”和“向应用程序添加内容”太大，不适合作为好的任务，所以答案B和D不正确。答案A和C是基于层次结构中最小的工件。因为我们在分解的最后一级定义了单元测试和布局设计。因此，答案A和C是正确的。答案E是针对未在定义范围内的功能的任务。目前它不会是这个产品的任务，所以答案E不正确。

正如你所看到的，我们可以通过查看其工作产品来将一个项目分解为任务。这个例子引导你浏览了一个以树状图描绘的产品工作分解结构。它基本上将设计和实现阶段的工作分解为任务，由产品所需的组成部分指导。然而，你可以扩展这棵树，将规范阶段以及验证和确认阶段包括进来，并为这些阶段也推导出开发任务。你还可以进一步扩展这棵树，将开发之外的其他产品管理关注点及其组成任务包括进来，例如推广应用程序、安排技术支持、设置服务器和收集分析数据。

那么，你如何在项目中使用工作分解结构呢？工作分解结构可以通过几种不同的方式使用。首先，你可以基于工作产品确定项目的任务。你可以轻松地将小而易于管理的工作产品转化为小而易于管理的任务。例如，如果工作产品是链接的单元测试，你可以创建任务“为链接编写单元测试”。这可能是工作分解结构最常见的用途。这是规划的一个很好的第一步，因为它为整个产品建立了细节，并且很容易创建任务来安排到开发中。

然而，你也可以使用工作分解结构来确定潜在风险。你可以单独查看每个工作产品，并提出与该特定工作产品相关的潜在风险。这将比你仅仅将产品视为一个整体时得出的风险列表更完整、更广泛。你还可以使用工作分解结构向客户展示产品。它展示了产品的详细概览，你可以单独查看功能和工作产品。工作分解结构对于确定开发团队完成项目需要多长时间也很有用。估算开发人员完成较小任务所需的时间，比将项目视为一个整体并猜测需要多长时间要容易得多。

让我们听听行业专业人士的看法，看看他们如何使用工作分解结构。

我目前的角色是创建新产品，因此我会从销售的角度出发，为现场团队制定销售赋能策略，让他们了解如何销售我们的解决方案，一直到服务交付，确保我们的顾问经过充分培训，能够胜任实际交付我们所销售的任何产品。为了做出管理决策，我们以几种不同的方式使用工作分解结构：我们用它来识别给定项目中不同活动和任务所需的资源；我们按资源识别工作量，以便我们了解项目的努力程度和持续时间，从而最终确定项目进度；作为一家咨询机构，我们还了解与每个资源相关的成本，因此这些按人员、任务和活动分配的成本使我们能够真正创建项目的最终预算；当然，我们还会在所有项目上添加应急储备，从而形成项目的最终总预算。

为了帮助我们的项目经理做出准确的规划估算，我们会创建所谓的自上而下和自下而上的方法。我们将使用工作分解结构，真正了解特定项目以及我们在该项目期间通常会执行的任务和活动所需的工作量或持续时间。这种自上而下的方法真正确定了我们不同的顾问或项目资源各自需要多少天或多少周。这种方法使我们能够从更全局、更宏观的角度理解项目的持续时间以及这些资源的使用情况。然后，我们采用自下而上的方法，有时甚至按分钟来审视任务和活动，这取决于项目的规模和范围。如果是较小的项目，你可能需要按所需努力的分钟数来分解；如果你谈论的是一个较大的项目群，并且该项目有几周、几个月甚至几年的时间，那么深入到分钟显然就太细了。我们会采用这种方法来真正理解完成某些工作包所需的关键任务和活动，然后这种自下而上的方法使我们能够实际创建我们的工作量、进度和预算。

总结

在本节课中，我们一起学习了工作分解结构。我们了解到，WBS 是一种将大型、复杂的项目（如软件产品）分解为更小、更易于管理的工作产品的层次化方法。这有助于将工作产品转化为具体的开发任务，识别潜在风险，向客户展示产品细节，以及更准确地进行时间和成本估算。关键在于找到平衡点，将工作产品分解到足够小以便于管理，但又不会小到导致微观管理。在下一课中，你将学习项目估算、目标和承诺之间的区别。

007：估计、目标和承诺

在本节课中，我们将要学习软件项目管理中的三个核心概念：估计、目标和承诺。理解并区分这些概念对于产品经理和开发团队的成功协作至关重要。

首先，请思考这句话：“我估计我们可以承诺在某个目标日期前完成。” 这句话听起来合理，在软件开发中也十分常见。然而，“估计”、“目标”和“承诺”这些术语经常被随意使用，有时甚至相互混淆。实际上，这些术语的含义截然不同。为了你和你的开发团队，清晰地区分它们非常重要。

接下来，让我们逐一审视这些术语。

估计：基于数据的合理猜测

一个估计是对开发团队完成任务所需时间的猜测。

估计应基于某些数据，例如完成类似任务的历史时间。估计通常应是一个范围，因为精确到小时或天数的预测往往不准确。此外，估计不应被讨价还价，重要的是尽可能准确。估计就是估计，它是什么就是什么。

让我们看一个例子。柯克是一名产品经理。他找到与他合作的开发人员莉兹，询问她开发某个功能需要多长时间。柯克过去与莉兹合作过，他认为如果莉兹努力工作，大约需要三小时。莉兹想了想，决定将她的估计延长一些，以便在工作中更轻松。她告诉柯克需要九小时。柯克告诉莉兹他认为只需要三小时，并提议折中一下。莉兹同意了，于是柯克记录六小时作为估计。这不应该发生。估计应该是现实的，这就是为什么基于先前工作来估计很重要。你可以准确地估计莉兹完成任务需要三到九小时。

为了巩固理解，请看以下场景：

你是一名与小型开发团队合作的产品经理。你正在与开发人员交谈，收集时间估计以帮助确定产品范围。你与一位名叫格雷格的开发人员交谈，问他为某个特定功能编写测试需要多长时间。你猜测需要5小时。格雷格刚刚为一个类似功能编写了测试，花了六小时。他想给自己一些缓冲空间，所以他告诉你需要10小时。你认为也许可以折中一下，写下七个半小时。

以下哪个是此任务最准确的时间估计？
A. 5小时
B. 6小时
C. 10小时
D. 7.5小时

正如我们之前所说，时间估计应基于先前类似的工作。这是获得估计最准确的方法，尤其是由同一人完成时。因此，答案B是正确的。当估计基于开发人员希望完成任务的时间，或基于经理希望开发人员完成任务的时间时，你就有可能高估或低估实际所需时间，因此答案A和C不正确。同样，估计不应是谈判。所以你不应该折中；因此，答案D也不正确。

目标：需要达成的理想时间点

现在让我们看看目标这个术语。一个目标是时间表中需要达成的一个点。这几乎是一个理想的截止日期。目标同样不应被谈判。目标的例子可以是冲刺的结束日期或产品发布日期。这些目标一旦确定，就必须遵守。目标日期用于安排产品推广活动，并且通常是合同性的。遵守这些目标日期对于客户满意度和产品成功至关重要。

承诺：基于协商的可交付范围

如果估计和目标都是不可协商的，那么你如何协商要开发什么内容呢？这就是承诺发挥作用的地方。承诺是进行谈判的地方。基于你的估计和目标，你可以协商你能承诺交付什么。你将不得不不断问自己：基于开发团队的估计和时间限制，我如何在团队承诺完成的内容上做出妥协？承诺是你同意交付的内容。

一个非常普遍的现象是，估计被自动转化为承诺和目标。

如果你被问及制作一个产品需要多长时间，你估计需要七个月，那么这个七个月就变成了你的承诺。而七个月后的日期就变成了你的目标。再次强调，这不应该发生。

让我们通过一个例子来看。假设我正在为一个家庭照看孩子。我问父母他们什么时候回家。他们说应该会在午夜左右回来。这是他们的估计。如果我要求他们做出一个承诺，即如果他们在那个时间没有回家，我将收取三倍的保姆费。他们可能会说12点30分，以便给自己一些缓冲时间，以防他们想多待一会儿或通勤时间比预期长。

理想情况下，你应该与你的开发团队讨论估计，得出一些准确的数字。你也应该与你的客户讨论目标日期。然后，基于这些项目，与你的开发团队和客户共同制定承诺。

请看以下场景：

你正在与你的客户和开发团队开会。你已经与你的开发团队谈过，他们根据以往的工作确定，要完成客户想要的所有功能，这个产品大约需要八个月。客户希望产品在假期前完成，因此她建议一个七个月后的发布日期。你们共同商定了一个包含大约五个月工作量的范围。六个月后，你的开发团队完成了最初商定的所有功能。

以下哪个时间是承诺？
A. 8个月
B. 7个月
C. 6个月
D. 5个月

当你的开发团队确定完成所有功能需要八个月的工作量时，那是一个估计。它基于他们先前的工作。因此答案A不正确。计划在未来七个月的发布日期将是目标；因此答案B不正确。你的团队实际开发所有功能所花的六个月，在这个场景中不是估计、目标或承诺；然而，你可以利用这个开发时间为未来的项目创建估计，所以答案C也不正确。你的开发团队和客户协商了包含大约五个月工作量的范围。那才是承诺。它是你的团队实际承诺要开发的内容。因此，答案D是正确的。

请记住，估计和目标一旦设定就是不可协商的。你可以协商的是你为项目范围所能做出的承诺。注意不要让你的估计变成承诺或目标。将这些项目分开，并确保你的团队和客户也这样做。这将防止你的范围变得过大，同时确保你能够真正满足目标日期。

行业实践：管理大型项目

现在，让我们看看行业人士如何处理涉及许多人的大型项目。

我们项目经理用来管理多个项目的技术之一是使用我们称之为“流”的概念。我们可能会创建活动流或项目流，并在项目集经理之下指派项目协调员或项目经理，真正理解每个项目内部的需求和可交付成果，以便我们可以汇总这些信息，并在项目集层面理解相互依赖性。通常，多个项目是相互关联的。当它们相互关联时，理解它们在先后顺序、什么需要先做、什么需要后做方面的相互依赖性，将所有这些汇总到一个总体时间表中，有助于我们的项目经理更好地理解它们如何相互关联。同样，我们可能会使用工作分解结构来理解所有可能需要相互关联的工作包。

我们使用几种不同的媒介向客户、经理和高管汇报项目情况。这些沟通方法包括状态报告、不同的会议纪要、行动日志、风险登记册等。我们给项目经理和产品经理的一个关键建议是，确保我们也使用非正式沟通，确保我们的文档中不会出现任何意外。因此，进行那种临时的、即兴的沟通，确保我们向利益相关者，特别是高管团队，传达不同的想法、可能出现的风险或问题，这一点很重要。高管团队可能并不总是有时间阅读所有包含大量细节的文档、状态报告和风险登记册。因此，你需要创建新的沟通媒介，以适应那些更繁忙的受众和利益相关者。对我们来说，我们采用“无意外”理念，并确保我们有一些即兴的沟通，通过口头或电话方式交流不同的想法。

在敏捷实践和我们面临的一些挑战方面，我们是一个横跨北美多个分支机构的虚拟社区，因此我们面临的一个挑战是真正理解和管理虚拟团队。我们如何协作？当并非所有人都在物理上在场时，我们如何进行诸如 Scrum 会议这样的活动？因此，跨不同地点的团队之间的协作和统一对我们来说是一个挑战。

产品经理的职责范围

Todd Bser 是 KeyV 产品管理公司的顾问，他对产品经理的职责有一个很好的定义。他着眼于产品经理负责的四个不同领域：市场情报、产品战略、产品开发和生命周期管理。简而言之，市场情报是指研究市场动态、流行趋势、人们使用的解决方案、使用的货币化模型类型、我们的客户或潜在客户在做什么，以及市场上可供我们使用的技术，以帮助解决问题。产品战略方面，我们关注货币化模型、开发环境与技术能力之间的契合度，最重要的是定义差异化优势——我们与其他人有何不同，以及我们如何为世界上需要技术帮助的真实人群解决问题。当这些确定下来后，我们开始制定路线图，即制定如何构建某物以及它应该是什么样子的计划。

协调不同利益相关者

存在一个经典的代理问题，这意味着不同的人有不同的奖励机制，他们对产品有不同的期望。在软件开发中，资源消耗极大，进展速度也不如这些群体所希望的那样快。这非常困难，需要花费大量时间与人交谈，了解他们的需求、观点，并找到共同点。对于一个新项目，如果人们的想法都很新颖，并且有很多共同经验，这可能相对简单。但通常情况下，不同的群体有着非常不同的目标、个性、工作风格，并且需要不同的环境和背景来完成工作。

他们可能使用不同的语言，例如技术人员会使用技术术语，这可能会让其他群体感到不快或误解。因此，表面上常常存在很多冲突。我所做的很多工作是尝试找到共同点。在一些项目中，我会采访人们并制作亲和图。我会拿出不同颜色的记号笔和同义词词典，查看名词、动词和形容词并突出显示它们，然后说：“看，你们实际上说的是同一件事。” 找到那个共同点、那个共同性。另一个重要的事情是，当存在一个焦点和差异化优势时，提醒人们我们为什么从事这项业务，我们正在为特定用户解决什么问题。如果我们能把这种宏观视角带入我们的对话中，设定背景，那将真正有助于让人们保持专注。

总结

在本节课中，我们一起学习了软件项目管理中三个关键概念：估计、目标和承诺。我们明确了估计是基于数据的合理猜测，目标是必须遵守的理想时间点，而承诺则是基于协商确定的可交付范围。区分这三者对于有效管理项目范围、确保团队交付能力和满足客户期望至关重要。记住，估计和目标不可协商，而承诺是谈判的焦点。保持这些概念的独立性将帮助你更好地规划和管理软件产品。

在下一个模块中，布拉德利将教你如何创建准确的估计，以及如何利用这些估计来组织项目发布的任务。

008：故事点

欢迎来到软件产品敏捷规划的下一个模块。在上一个模块中，摩根介绍了一些规划的核心概念，例如不确定性空间、如何分解工作，以及估算、目标和承诺之间的区别。

在本模块中，我将讨论故事点和速率，然后介绍一些将这些估算转化为具体计划的技术。

估算、目标与承诺回顾

在上一课中，摩根谈到了估算、目标和承诺。以下是简要回顾。

任务估算是对一项任务将花费多长时间的近似值。这些估算由预期从事该任务的开发人员做出。估算应基于以往的工作经验。它们是不可协商的，因为它们只是对工作耗时的预测，而非对工作何时完成的承诺。

目标是需要满足的截止日期。目标通常由开发团队外部设定。它们也是不可协商的，因为其他方可能依赖这些日期。
承诺是开发团队承诺完成的具体、强制执行的工作。它们明确规定了在什么时间完成什么工作。承诺基于目标截止日期和现实的估算。承诺是确定项目进度的依据，由客户和开发团队协商确定。

项目承诺受目标和估算的制约。目标是具体的日期，而估算为承诺提供了现实的依据。如果没有对工作耗时的估算，做出的承诺可能不切实际。

小测验：识别概念

我刚刚重申了估算、目标和承诺之间的区别。以下哪个术语描述了在开发团队外部设定且必须满足的截止日期？

A. 估算
B. 目标
C. 承诺

正确答案是 B. 目标。目标是在开发团队外部设定且必须满足的日期。而承诺是可协商的，目标则不可协商。

如何创建良好的估算？

摩根在上一课中提到，开发人员应根据过去实现类似功能所花费的时间来估算。她谈到了几种软件开发人员给出时间估算的场景，通常会留出一些缓冲时间。但这是为什么呢？是什么让软件开发人员觉得他们一开始就必须在估算中留出缓冲？

通常发生的情况是，管理者误将开发人员的估算当作承诺。开发人员知道这一点。他们也清楚自己的估算可能偏差很大。为了保护自己免于承诺无法完成的事情，开发人员会给自己留一点缓冲空间，即他们在估算中加入了余量。因此，过去需要4小时完成的任务，现在被估算为需要10小时。

当然，管理者也知道这一点。他们能看出估算何时显得不合理。因此，管理者最终与开发人员协商这些估算也就不足为奇了。现在，一个10小时的估算被削减到6小时。他们在协商本应是绝对的估算。从组织角度来看，这不太合理。

如果能在不使估算听起来像承诺的情况下进行估算，岂不是更好？这里的问题之一是，时间经常被用作工作估算的度量单位。也就是说，每个估算都以小时来衡量：做这个需要5小时，做那个需要1小时。你自然会想，如果一个标准工作日有8小时，你可以完成一个5小时的任务和大约三个1小时的任务。自然而然地，开发人员和产品经理开始将时间估算与工作时间联系起来。这使得人们很容易将估算误认为是承诺。

小测验：识别常见问题

我刚刚讨论了软件项目工作估算的一些问题。当使用小时进行估算时，以下哪项是工作估算最常见的问题？

A. 估算应使用分钟，而不是小时。
B. 基于时间的估算可能被误解为承诺。
C. 软件开发人员不擅长估算时间。
D. 估算应使用天数，而不是小时。

正确答案是 B. 基于时间的估算可能被误解为承诺。

引入故事点

故事点正是我们旨在用来替代时间单位的度量方式。让我们进一步讨论故事点。

本节课总结

在本节课中，我们一起学习了敏捷规划中的核心概念区分：估算、目标和承诺。我们探讨了使用时间（如小时）作为估算单位可能导致的问题，即估算容易被误解为不可变更的承诺。为了解决这个问题，我们引入了故事点的概念，它是一种相对估算单位，旨在更准确地反映工作的复杂性和不确定性，避免与具体时间绑定，从而为团队规划提供更大的灵活性。下一节，我们将深入探讨故事点的具体定义和使用方法。

009：故事点 📊

概述

在本节课程中，我们将学习敏捷规划中的一个核心概念：故事点。我们将探讨为何要使用故事点来替代传统的时间估算，了解其工作原理、优势以及潜在的风险。

故事点的起源与目的

故事点的诞生源于保护开发者心智健康的需要，因为估算常常被误认为是承诺。这在软件项目管理中是一个普遍存在的巨大问题。

因此，开发者对于为特定任务给出确切的时间估算感到抗拒。开发者可能被迫向管理者提供任务完成时间的估算，而管理者最终会将这个估算视为承诺。管理者又会将这个“承诺”传达给他们的上级，突然间，产品的内部截止日期就建立在某位开发者粗略估算的基础上了。

更糟糕的是，如果开发者的工作最终花费的时间超过了他们的估算（这种情况经常发生），那么这位开发者就会感受到压力。这并非因为开发者表现不佳，而仅仅是因为他们没能做出准确的估算。一个不准确的估算也未必反映了开发者缺乏经验或能力。

正如你将在本节关于任务时间估算的课程中看到的，做出可靠且准确的估算非常困难，尤其是当你对未来很远的事情进行估算时。

故事点如何解决问题

故事点试图解决这个问题的方法是：消除时间作为估算工作的度量单位。相反，在估算所需完成的工作量时，使用故事点。

故事点是无量纲且相对的。关键在于，它让开发者不再试图估算某项工作将花费的确切时间，而是转向估算这项工作相对于其他工作所需的时间长短。

故事点的工作原理

以下是它的工作方式。你的开发者从产品待办事项列表中选择一个相对容易估算的产品需求，即一个用户故事。

然后，开发者为其分配一个任意的整数值，我们称之为故事点。一旦有了这个基准值，你就可以基于它为其余的用户故事分配故事点。

因此，如果下一个用户故事规模大致相同，它将获得相同数量的点数。如果随后的故事规模大约是两倍大，那么你就分配两倍的点数，依此类推。

最终你得到的是一个用户故事列表，其工作量估算都是相互比较得出的，而不是开发者在估算每个用户故事所需时间时，无意中承诺了某个具体的时间量。他们是在确定每个用户故事的规模大小。而这正是估算应有的样子。

请记住，估算不应该是承诺，因此将时间因素从中剔除有助于防止它们变成承诺。

这种方法之所以有效，是因为人类实际上非常不擅长精确地估算事物。我们更擅长基于相对大小进行估算。

现实世界示例

让我们看一个现实世界的例子来演示这个概念。假设你想估算一栋建筑的大小。你试图凭直觉估算它的大小，并说它大约有60米高。

另一种方法是将其大小与另一栋建筑进行比较。

选择附近一栋较小的建筑，用它作为比例尺。那么那栋较高的建筑可能相当于三栋小建筑的高度。

在软件领域，这种方法还有一个额外的好处，即有助于保持开发者的心智健康。估算故事点时不必追求精确，因为一切都是相对的。

如果开发者的时间估算超时，即使只是几分钟，也可能对他们造成心理压力。他们可能会因为未能按时完成估算而对自己感到不满。而使用故事点，则不容易“超时”，因为估算与时间无关。

知识检查

你刚刚学习了一些关于故事点的知识。它们是一种避免在使用小时估算时意外做出承诺的方法。

故事点的哪些特性使其适合用于估算而不至于变成承诺？你可以选择多个答案。
A. 故事点是无量纲的。
B. 故事点的数值可能因项目而异。
C. 故事点更难理解。
D. 故事点不直接映射到一个时间值。
E. 故事点完全不映射时间。

答案：A、B 和 D。
故事点是无量纲的，并且它们的数值因项目而异。由于它们因项目而异，其时间价值也可能因项目而异，但这并不意味着故事点完全不映射时间。

使用斐波那契序列

故事点常常被误解，因为它们经常被赋予像小时一样被对待的数值。例如，如果你将第一个用户故事设为100个故事点，那么你的开发者就很容易基于此为其他用户故事分配非常精确的点数。因此，你可能会看到其他用户故事被分配了诸如42点这样的值。

如果使用用户故事的整个要点在于相对性，那么使用如此精确的数字就没有太大意义。为你的故事点设置正确的数值非常重要，这样才能保持点数的相对性。

帮助支持这种相对性的一种方法是使用固定的故事点数值。一个好的做法是基于斐波那契序列来分配故事点。

斐波那契序列是一个数字序列，其中任何一个数字都是前两个数字之和。因此，一个斐波那契序列可能看起来像这样：1, 2, 3, 5, 8, 13 等等。

斐波那契数列使得使用故事点进行估算变得非常简单。你不是使用任何你认为可行的数字，而是限制自己只使用斐波那契数列中的数字进行估算。如果你的估算落在两个可用数字之间，你会向上取整到最接近的可用数字。

这使你的估算保持整洁，并且由于存在不确定性，避免了不必要地使大估算过于精确。

因此，如果你的第一个任务估算被分配了3点，而你的下一个任务看起来大约是它的两倍大，你不会分配6点（因为你受限于斐波那契序列），而是会将你的估算向上取整到8点。通过这种方式，你可以控制你的估算，并在处理不确定性的同时避免做出无意的承诺。

另一个知识检查

以下哪个值最适合作为故事点？
A. 200
B. 3
C. 18
D. 50

正确答案是 B，3。
因为3这个数值既小又好，很容易围绕它估算其他值，而不会陷入点数的百分比计算。3也是最常见的斐波那契序列中的一个数字。因此，如果你在斐波那契序列中使用故事点估算，它仍然是一个你会看到的数字。

故事点的争议与风险

故事点是替代按可能花费的小时数来估算工作的一个很好的选择。然而，故事点并不是业界广泛接受的实践，即使在敏捷软件开发和Scrum最坚定的支持者中也是如此。如果故事点效果这么好，为什么还会存在争议呢？

故事点可能有些棘手。首先，实施它需要一种非常特殊的思维方式。对于开发者来说，突然将思维从时间估算转向点数估算可能是一个令人困惑的要求。

最终经常发生的情况是，开发者会将预测的若干小时数转换为特定数量的故事点，因为这对他们来说最合理。然而，这完全违背了故事点的初衷。你可能会认为这只是个教育问题。确实，经过一些练习后，开发者确实能更好地使用故事点来估算他们的工作。

然而，估算本身存在一些固有的限制，这使得故事点成为一个敏感话题。其中一个限制是，估算行为本身就是一项有风险的工作。你永远无法100%确定任何给定的估算都是准确的，这就是为什么它们被称为“估算”。虽然相对大小的估算比精确的数字估算要准确得多，但相对大小估算仍然不完美。

一个很好的例子是垂直-水平感知错觉，它展示了我们在这方面有多不擅长。本质上，当一条垂直线段放在一条等长的水平线段上方时，人们往往会高估垂直线段的长度。所以，即使只是几条线段，也很容易看出我们并不擅长精确估算某物的大小，即使你有直接的比较对象。

另一个问题是，故事点在大型团队中可能会失控。它们本意是可扩展的，但有些开发者可能会为非常小的任务给自己虚高的故事点，以制造高生产力的假象。如果整个项目中每个点的估算基准是一致的，这倒没问题。但有可能管理者会要求团队在项目中期加倍努力以提高生产力。如果此时开发者通过改变故事点的参考基准人为地虚报数字，准确的估算就变得更具挑战性。

基本上，故事点容易受到“玩弄系统”或作弊的影响，这对管理者来说是一个潜在的担忧。这并不是说故事点一定不好，但使用它们确实存在风险，如果你打算将它们整合到你的项目中，你应该了解这些风险以及如何减轻它们。

总结

本节课我们一起学习了故事点。它是一种基于相对概念来估算工作量的方法，旨在避免将估算误认为承诺。我们探讨了其工作原理、使用斐波那契序列的好处，以及在实际应用中可能遇到的争议和风险。

在下一节课中，我将介绍速率的概念，这是一种衡量团队长期生产率的方法。下次见。😊

010：速度估计

在本节课中，我们将要学习敏捷规划中的一个核心概念：速度。我们将了解速度的定义、如何计算它，以及如何利用它来预测团队未来的工作量。

什么是速度？

上一节我们介绍了故事点及其在估算用户故事规模时的应用。本节中，我们来看看如何衡量团队完成这些故事点的效率，这就是“速度”。

在物理学中，速度衡量的是物体在单位时间内移动的距离。在软件项目中，速度的概念非常相似，它衡量的是团队在单位时间内完成的工作量。这里的“单位时间”通常指一个冲刺的周期。

例如，一个软件项目的速度可以表示为“每个冲刺完成15个故事点”。冲刺与迭代是同一概念，都是将工作划分为固定时长的周期，我们将在下一课详细讨论时间盒。

如何衡量工作量？

就像公路旅行中可以选择用英里或公里来衡量距离一样，在软件项目中，你也可以选择不同的单位来衡量生产力。

以下是两种常见的衡量单位：

完成的用户故事数量：直接计算完成的功能项。
完成的故事点总数：计算所有已完成用户故事的故事点总和。

虽然两者都能衡量项目完成的工作量，但解释方式不同。混合使用用户故事和故事点，就像混合使用公里和英里一样容易造成混淆。由于用户故事的规模可能差异很大，使用故事点总数能比单纯计算用户故事数量更准确地反映实际完成的工作量。

使用用户故事数量，类似于计算公路旅行中经过的城镇数量。这并不能可靠地告诉你何时能到达下一个城镇或最终目的地。

如何计算速度？

现在你知道了速度是什么，让我们来计算它。如前所述，速度是你在特定时间段内完成的工作量。

在敏捷社区中，团队的速度通常通过计算在一个冲刺周期内完成的用户故事所对应的故事点总数来衡量。

速度 = 一个冲刺内完成的故事点总数

“完成”的定义

一个用户故事被标记为“完成”意味着什么？一个可能的理解是所需功能已编码实现。然而，在Scrum等框架中，定义更为严格。

要认为一个用户故事“完成”，该故事的所有测试必须通过。这意味着产品必须通过单元测试和验收测试，产品负责人和团队才能将其视为完成。

因此，只有当一个用户故事的所有测试都通过后，其故事点才能计入当前冲刺的速度中。在实践中，你可能会听到“完成，完成”的说法，这通常意味着：功能已构建、所有测试已通过、并且已完成相关文档。

速度的作用：预测未来工作

为什么要计算速度？速度能帮助你创建有意义的估算，预测团队在整个项目中能完成多少工作。这种方法被称为速度驱动开发。

在速度驱动开发中，每个冲刺的计划都基于团队在以往冲刺中完成的工作量或达到的速度。其前提是，开发团队了解自己在未来冲刺中能完成多少工作的唯一可靠方法，就是参考他们过去的表现。

使用速度进行未来估算时，你通常处于以下两种情况之一：

项目刚开始，没有历史速度数据：此时很难准确估算速度，预计估算会不准确。
项目进行中，拥有一些历史数据：你可以使用过去的实际速度来预测未来的速度。需要注意的是，大多数项目在开始时速度并不稳定，团队需要一些时间来找到节奏。随着时间推移，估算会越来越准确。

关于速度的讨论

现在我们已经讨论了速度及其作为估算工具的用法，值得指出的是，关于速度估算是否准确甚至有用，存在一些争议。在实践中，它功能强大，但也存在一些潜在的缺点。无论如何，了解如何计算团队的速度仍然很有价值，因为大致了解团队的生产力对于规划和管理期望至关重要。

总结

本节课中我们一起学习了敏捷规划中的“速度”。我们了解到，速度是衡量团队在单个冲刺内完成工作（通常以故事点计）的效率指标。它基于“完成”的严格定义，并用于根据过去的表现来预测未来的工作能力。虽然其实用性存在讨论，但掌握速度的计算和应用，是进行有效敏捷规划的重要基础。

在下一课中，我将讨论时间盒的概念。

011：时间框 🗓️

在本节课中，我们将要学习时间框的概念。上一节我们介绍了如何利用团队速率来估算工作量，本节中我们来看看为什么在敏捷开发中，我们通常将工作周期固定为“冲刺”。

概述

时间框是一种将工作划分到固定时间段内完成的方法。它为软件团队提供了组织工作的框架，并留出了反思进度的空间。这是现代流行的组织工作方式，也是Scrum运作背后的核心理念。

什么是故事点？

在深入时间框之前，我们先简要回顾一下故事点。故事点是用于估算任何给定用户故事所需工作量的相对单位。它们不以时间单位衡量，以避免估算听起来像承诺。你可以通过跟踪团队在一个冲刺中能完成多少工作来确定团队的速率。

引入时间框

你可能会想，如何确保开发过程是有纪律的呢？答案就是时间框。

时间框是指在受限的时间段内构建某物的通用术语。你可以为任何活动设置时间框，从为期四周的Scrum冲刺到半小时的计划会议。

以下是一个关于时间框类别的小测验：
问题：Scrum冲刺所属的广泛类别被称为？
A. 时间锁
B. 计划
C. 工作箱
D. 时间框
正确答案是 D. 时间框。

Scrum冲刺被认为是时间框化的，因为它们被限制在相对较短的开发时间和相对较少的工作量内。

如何创建时间框

创建一个时间框很简单，你只需要：

在项目中设定一个时间段，工作将在此期间完成。
为在该时间段内要完成的工作量设定一个限制。
在开始时规划这些工作。

在Scrum中，冲刺的长度通常为两到四周，前后分别有计划和评审阶段。

时间框的重要性

独自开发产品并跟踪进度，然后根据速率估算项目完成日期是一回事。而规划工作以确保保持在正轨上则是另一回事。

这是因为，如果没有开发目标或里程碑，大多数人往往会比定期规划工作时开发得更慢。试想一下，如果你给自己一项任务，但没有明确的完成截止日期，那么很容易分心去做不必要的工作。由于时间看似灵活，范围往往会扩大，这是一种风险。

然而，如果你将工作规划在足够小的时间剂量内，就很容易看到下一个目标是什么，以及在那之前需要完成什么。

时间框的工作原理

当你使用时间框时，你将一定量的工作放入特别规划的、固定长度的时段或“时间盒”中。你取项目结束时需要完成的工作的一个子集，并将其划分为可管理的块，放入这些时间盒中。

在Scrum中，每个时间框或冲刺还涉及在每段时间结束时评审团队完成的工作。所有这些加在一起，使你能够看到项目持续、稳定的进展节奏。

规划的艺术

然而，规划工作是一门艺术。你可以把所有想要完成的工作都放进一个时间框，但这并不意味着在时间框结束时一切都能完成。这不太可能。

这就是为什么使用团队的速率如此有帮助——你可以利用他们的生产力历史来了解在一个时间段内实际可以完成多少工作。

时间框的优势

时间框的妙处在于，除了以理性、可持续的方式组织工作外，你现在还可以定期从工作中学习。

许多方法允许你规划出评审时间。你可以利用这段评审时间回顾你的进展，然后利用获得的见解来为下一个时间框制定计划。这对于时间框原则本身来说并非关键，但却是该原则的一个宝贵延伸。

时间框让你有机会看到工作将如何在你的项目中划分。即使你不知道具体在什么时间会完成什么，有一个大致的想法仍然是很有用的信息。

实现可发布的产品

你不必等到项目最后才拥有一个可发布的产品。它可以分阶段发布。事实上，在每个时间框结束时，你都应该拥有可以潜在地作为产品发布的、可工作的软件。这能保持开发人员的士气，并确保即使资源耗尽，你在项目结束时仍然拥有一个有形的产品。

以下是一个关于时间框关键特征的小测验：
问题：请选择时间框的关键特征。
A. 时间受限
B. 之前有计划会议
C. 之后有评审会议
正确答案是 A. 时间受限。时间框化的工作可以在前后有计划会议和评审会议，但这并不是其概念本身的关键，所以时间框只是一种将你的工作计划分解为可管理块的方式。

总结

本节课中我们一起学习了时间框。它是一种将工作分解到固定、受限时间段内完成的方法，易于实施，并能显著提高项目成功的几率。时间框帮助我们保持开发节奏、控制范围蔓延，并允许我们定期评审和调整计划。

在下一课中，我将讨论一种流行的可视化项目计划的方法——燃尽图。让我们继续学习。

012：甘特图 🗓️

概述

在本节课中，我们将学习一种用于项目规划的可视化工具——甘特图。我们将了解它的基本构成、如何创建它，以及它如何帮助管理者洞察项目的时间安排和任务依赖关系。

甘特图简介

上一节我们介绍了时间盒规划法。本节中，我们来看看另一种项目规划技术：甘特图。

与时间盒不同，甘特图并非组织时间的通用方法，而是一种用于可视化展示项目期间计划工作的图表工具。甘特图能为你提供项目的长期和短期洞察，它们非常有价值，能对项目的成功产生巨大影响。

甘特图是一个用于可视化项目的简单工具。其基本理念是，它能在一个视图中同时展示项目计划、任务依赖关系和截止日期。

甘特图的基本构成

一个基础的甘特图由任务和日期构成。

任务来自工作分解结构，沿着图表的左侧纵向排列。
日期沿着图表的顶部横向排列。

每个任务被逐一列出，第一个计划开始的任务位于最顶部。该任务的开始日期，由一条在顶部对应日期下绘制的横条的起点表示。这条横条从开始日期延伸至该任务计划完成的日期。

当所有任务都布局好后，你就能看到每个独立任务计划何时开始与结束。

甘特图与敏捷性

但是，这难道不是非常不“敏捷”吗？如果甘特图只是一系列顺序任务列表，那它岂不是更适合瀑布式流程？

答案是，如果你只是毫无上下文地一个接一个列出任务，确实如此。然而，你可以在甘特图中添加更多信息。

如果你将图表的某些部分划分出来并标记为“冲刺”呢？这完全可行。并且，如果你允许这个计划发生变化，它也完全符合敏捷理念。

你可以利用甘特图来获取关于项目的一些关键洞察。其中最明显的几点包括：你能够大致看到项目何时完成，以及哪些任务会同时进行。

甘特图的应用实例

奥斯汀是一位软件产品经理，正与软件开发团队合作。他选择使用甘特图向公司领导展示他的项目，以说明项目进度。

基于奥斯汀的甘特图，公司领导能了解到哪些信息？（可选多个答案）

A. 没有信息，没有上下文的甘特图毫无用处。
B. 项目任务依赖关系。
C. 预估的任务时长。
D. 项目预算。

正确答案是 B 和 C。甘特图让你能够看到项目的任务时长，也能看到任务依赖关系。

接下来，我们来详细谈谈任务依赖关系。

任务依赖关系与关键路径

甘特图不仅仅是日历和待办事项列表的混合体。如果你在甘特图中加入任务依赖关系，它会变得更有用。

以下是操作方法：

在创建甘特图之前，先列出将要包含在图表中的任务。
找出哪些任务需要等其他任务先完成。假设你有两个任务，如果第二个任务必须等到第一个任务完成后才能开始，那么你就说第二个任务依赖于第一个任务。
在你的任务列表旁，为第二个任务做备注，说明它依赖于第一个任务。
为所有任务及其依赖关系都这样做，现在你就得到了一个通过依赖关系紧密相连的完整任务列表。

当你将这些信息转化为甘特图时，你像之前一样列出所有任务及其起止日期。唯一的不同是，你现在知道某些任务必须等到其他任务完成后才能开始。

在甘特图上，这通过一个从被依赖任务指向依赖任务的箭头来表示。

将任务依赖关系这样布局的好处在于，你可以非常容易地看到项目的关键路径。这让你能够看清资源的最佳投入点，并了解在什么时间需要完成什么工作。摩根将在下一个模块中更详细地讨论任务依赖关系和关键路径。

甘特图的应用层级

需要注意的是，甘特图可以在迭代（冲刺）层级或发布层级使用。

在迭代层级，你可以用它来洞察当前冲刺时间盒内未来几天的任务安排。
在发布层级，你可以使用用户故事（而非任务）作为图表中的工作单元，来洞察未来几个冲刺中的这些用户故事。

总结

本节课我们一起学习了甘特图。它是一种用于可视化项目计划的超级简单的方法。市面上有大量工具可以帮你创建甘特图。

在下一课中，我将整合本模块讨论的许多内容，并介绍发布计划。发布计划是项目成功的关键方面，请不要错过。

013：发布计划 📅

概述

在本节课中，我们将要学习敏捷规划中的发布计划。发布计划是一种更高层级的规划，用于确定在未来的多个迭代（或冲刺）中，哪些用户故事应该被完成和发布。我们将了解如何从产品待办事项列表中提取用户故事，并根据优先级将它们分配到各个冲刺中，从而构建一个清晰的发布路线图。

欢迎来到本模块的最后一课。在上一课中，我们介绍了甘特图作为项目规划的工具。它是一种可视化项目并了解工作何时完成的绝佳方式。在讨论甘特图时，我也提到它可以用于迭代层面和发布层面的规划。这被称为两级规划。

迭代规划是细粒度的，处理的是作为工作单元的任务。发布规划则是更粗粒度的，处理的是作为工作单元的用户故事。在这两种情况下，迭代或冲刺的概念都很重要。我在之前的课程中讨论过时间盒。冲刺是一个小的、固定长度的时间盒，工作在其中被组织起来。

在本节中，我们将逐步构建发布计划的概念。

迭代与发布规划的关系

在Scrum中，我们有被称为冲刺的时间盒迭代。在一个冲刺开始时，会有一个冲刺规划会议，用于创建迭代计划。在迭代计划中，开发任务被安排在冲刺内完成。这些任务被列在冲刺待办事项列表中。任务在工作开始前由开发人员自行认领。

在一个冲刺结束时，还会有一个冲刺评审会议。这时，可工作的软件会展示给客户或产品负责人。理想情况下，可工作的软件在每个冲刺结束时都应该是可发布的。

然而，迭代规划是非常短期的，因此发布计划被用来确定在接下来几个冲刺中，哪些用户故事应该在每个冲刺结束时完成并发布。

从用户故事到任务

用户故事来自产品待办事项列表，并根据其优先级被安排到即将到来的冲刺中。自然地，你需要在开始第一个冲刺及其迭代规划之前，先进行发布计划，将用户故事分配到各个冲刺中。

假设你有一个用户故事：“作为一个音乐听众，我希望能够暂停我的音乐，以便在我需要听其他东西时能保持在歌曲中的位置。”

这对于一个开发人员来说太大了，无法直接完成。为了使其更易于管理，你必须将这个故事转化为一组任务。这些任务应该与单个开发人员能在几小时内编程完成的工作量相匹配。

考虑到这一点，为管理这个用户故事，你可能会创建以下几个任务：

在图形界面添加一个暂停按钮。
创建保存用户在当前歌曲中位置的功能。
创建当按下暂停按钮时停止播放的功能。
创建恢复歌曲中保存位置的功能。

所有这些任务都是开发人员可以创建的可执行项。它们共同促成了其来源用户故事的总体完成。

如何构建发布计划

在发布计划中，你如何确保在正确的时间规划了正确的工作？哪个用户故事应该在哪个冲刺中被发布并由产品负责人或客户评审？这实际上是一个优先级问题。我在“客户需求与软件需求”课程中讨论过产品待办事项列表中用户故事的优先级排序。

发布计划是通过从产品待办事项列表中提取用户故事，并将它们分配到各个冲刺中来构建的。用户故事在冲刺间的分配应该有其逻辑。否则，用户故事的随意堆积可能导致冲刺混乱无序。

首先，你从中提取用户故事的待办事项列表应该已经由你的产品负责人或客户排定了优先级。最高优先级的用户故事被标记为“必须做”，中等优先级的标记为“应该做”，低优先级的标记为“可以做”。这样，在进入开发之前，你就能很好地了解客户眼中的优先级。

然后，从优先级列表的顶部开始，将已排定优先级的用户故事分配到你的发布计划中的各个冲刺里，直到每个冲刺都填充了适量的工作。

确定“适量工作”

“适量的工作”在这里有点难以准确把握。了解多少工作是合适的最佳方式是通过经验和数据。你的团队在估算工作方面做得越好，你就越能知道他们在给定时间内能完成多少工作。

知道了你的团队在一个冲刺中可以完成的工作量以及每个用户故事的估算时间，你就可以根据用户故事的估算来填充可用时间，直到你的任何一个冲刺都无法容纳更多工作为止。

如果做得好，你最终会对未来几个冲刺结束时产品应该是什么样子有一个相当准确的看法。这是与你的产品负责人或客户设定期望并提升开发人员士气的好方法。每个人都喜欢看到进展和对未来的愿景。发布计划是提供这种愿景的绝佳方式。

知识检查

亚历克西斯是一名软件产品经理，她正与她的开发团队一起规划项目。他们正在创建一个发布计划，并选择要包含在第一个冲刺中的用户故事。亚历克西斯和她的团队如何决定首先完成哪些用户故事？

A. 由开发团队确定优先级。
B. 随机分配以避免偏见。
C. 由客户确定优先级。
D. 由用户确定优先级。

在敏捷中，用户故事由客户或在Scrum中由产品负责人确定优先级。因此，发布计划应反映这些优先级。所以，正确答案是 C。

行业视角：路线图规划

发布计划是工具箱中的一项宝贵技术。它不仅是一个极好的规划工具，还能起到提振士气的作用。当你的开发人员能在上下文中看到他们的工作时，他们很容易保持动力。让我们听听行业专业人士如何管理长期规划。

“路线图是一份战略文件，规划了我们产品或服务的进程。路线图是产品经理可以使用的最重要的工具之一，因为它有助于在不同团队之间达成一致，这些团队可能对应该做什么有不同的看法。因此，制定和定义一个路线图是一项艰巨的任务，可能相当耗时。这需要大量的研究，与不同的人交谈和协商，确保他们的观点被听取。对于路线图本身，我关注三个领域：当前开发、近期开发和未来。对于当前，我们正在做什么，这非常具体。随着我们走向未来，它变得更加抽象，并在我们需要时给我们更多改变的空间。”

“这份文件是一份活的文件，当有充分的理由（无论是技术、业务还是市场原因）需要改变时，我们会更新它。但我们努力坚持它，以帮助构建我们正在构建的内容的背景：我们如何为特定用户解决一个或一系列问题？我们的差异化是什么？我们与其他人有何不同？我分享这份路线图，确保它是可见的，并帮助构建我们的规划。如果我们是一个敏捷团队，我们为冲刺做规划，每个冲刺，我们都会查看路线图，确保我们所做的符合路线图的目标。”

“路线图是这一切的起点。当我创建路线图时，这是一个非常协作的过程。我必须让每个人都参与进来并同意它。我需要为每个人加入一点东西，这样他们才能认同它，并感到自己的意见被听取，他们的观点将在产品中实现。我极力推动的一件事是差异化。很多人构建的产品是别人的复制品，你投入了大量资源，然后去和朋友喝咖啡时说‘我们构建了这个东西’，他们会说‘哦，我正在使用这个竞争产品，你们有什么不同？’然后你开始谈论‘我们使用这个最新的JavaScript框架，使用这个数据库……’他们的眼睛会翻白眼，他们不在乎。所以差异化真的很重要。我关注三个领域：一是‘基本要求’，即我们需要提供的最低限度的东西，才能在这个市场领域被认真对待。接下来是‘差异化’，我们做什么与其他人不同？我们要确保我们正在增强这一点，并且我们添加的功能是差异化的一部分。另一件事我喜欢称之为‘微小而精彩的瞬间’，即一些小惊喜。我想确保在构建东西时，我们加入一些快捷方式、一些有趣的东西、一些在上下文中有效的东西，当有人使用软件时，他们会得到一个小惊喜。”

“很多技术团队会专注于解决方案，而远见者则考虑五年后的事情。所以他们经常会提出想法。这里的关键是确保我们坚持路线图并管理队列。我经常花时间与技术团队在一起，确保我们按照路线图交付，但也会花时间与远见者在一起，让他们自由发挥和头脑风暴，我们可能会也可能不会纳入这些想法。然后，如果你需要改变方向，你需要有一个流程。CEO或项目发起人总是可以否决，但我会警告他们这样做的后果。你不想太频繁地改变，但如果我们需要改变，我会建立一个可以推翻原计划的流程，建立一个否决流程，因为很多远见者有直觉，而且他们往往是对的。因此，专注于路线图，保护团队免受那些可能不会在短期内被纳入的想法的干扰，是确保你正在构建你需要构建的东西的重要部分。”

“我会看市场，看团队在做什么，看重要利益相关者的反馈。总的来说，通过观察许多小事情，你会对大局需要改变有一种感觉。有时，会出现一些极具颠覆性的事情，要么是一个大客户或重要客户有一个真正需要解决的问题，要么是其他人提出了什么并扰乱了市场，要么是出现经济力量如衰退或商品价格变化，要么是发生一些世界事件，让我们所有人都措手不及，这时你必须重新调整，开始研究……”

“就个人而言，市场情报是一个持续进行的事情。你从一个项目到另一个项目地看市场情报，但我也从更大的视角、更全球化的视角来看待它。因此，了解有哪些技术能力、什么受欢迎、人们对什么感兴趣、人们正在解决什么样的问题，然后最关键的是走出去，发现人们需要解决的问题，我们可以用现有技术来解决这些问题。与人交谈并观察他们。很多时候，人们认为你只需要让客户告诉你该构建什么，但他们并不总是有词汇，或者可能有错误的想法。他们可能会说‘我希望你构建这个’，但当你观察他们时，会发现另一个缺口。所以当你指出存在一个缺口，并告诉他们可以用技术解决时，他们常常会对此感到非常惊喜。这需要一些研究，走出去看看需要解决什么问题。我镇上有一位同事丹·沙瓦尼，他是一名产品经理，他说他总是在寻找‘杀手级问题’。这些问题对人们来说可能看起来是小问题，但当人们的问题可以通过技术解决时，看到那种契合感——‘啊哈，我们知道如何为你解决这个问题，我们可以让你的生活更轻松’——真的是一种很棒的感觉。”

总结

本节课中我们一起学习了发布计划。发布计划是一种在更广泛层面上规划项目的方法，它将用户故事分配到项目内的计划冲刺中。通过本模块学到的知识，你可以运行一个组织相当良好的软件项目。但这还不是全部，还有更多需要了解和发现。

在本模块中，我们学习了如何在冲刺之间进行规划。在下一个模块中，摩根将更深入地探讨如何在冲刺内进行规划。她期待向你展示，我们也非常希望在那里见到你。

014：任务时间估计 📊

在本节中，我们将学习如何进行任务时间估计。我们将从理解项目整体的不确定性开始，然后探讨几种不同的估算方法。掌握准确的估算对于制定可行计划和达成项目目标至关重要。

不确定性锥体 📈

上一节我们介绍了估算的重要性，本节中我们来看看影响估算准确性的关键因素——不确定性。在项目初期，不确定性通常很高；而在项目末期，不确定性则很低。这是我们在讨论不确定性空间时曾提及的概念。

如果在不确定性高的时候进行估算，估算结果很可能极不准确。随着项目推进，需求和发展节奏变得更加清晰，做出准确估算会容易得多。这正是“不确定性锥体”所展示的。

在深入讨论不确定性锥体之前，我们先来解读一下图表。

以下图表中，哪个点具有最高的可变性？A点、B点、C点还是D点？

在不确定性锥体图中，当垂直区间最大时，可变性最高。随着时间的推移，可变性越来越小。因此，位于项目起始阶段的A点具有最高的可变性。此时的估算可能比实际值小四倍或大四倍。所以，正确答案是A。

在Y轴上，我们表示的是可变性，即估算可能变化的倍数。区间越大，可变性越高。从图中可以看到，随着时间沿X轴推进，我们的可变性变得越来越小，从而形成了一个锥形，故而得名“不确定性锥体”。

那么，如何将其应用于项目呢？随着项目进行，不确定性被逐步解决，因此估算的可变性会变小。

项目始于初始产品定义阶段，此时形成了产品的初步构想。你脑中有一个大致概念，但没有具体的解决方案。这个时间点的可变性相当高。如果在此早期阶段进行估算，你可能需要一个很大的范围。

当你进入需求启发活动时，可变性变小。此时，产品的特性更加明确，因此更容易做出准确估算，估算范围也可以更小。

接着，你制定潜在方案，可变性进一步减小。一旦完成架构设计和最终的详细设计，可变性就小得多，你的估算也更加可靠。

你可以利用这些可变性来为项目进行估算。根据你在项目时间线中所处的位置，可以将估算值乘以相应的可变性系数，以获得更准确的范围。

例如，假设你猜测一项任务需要4小时完成。如果你正处于需求启发活动阶段，图表估计可变性系数为2和0.5。那么，你可以将4小时的猜测值乘以2和0.5，得到完成该任务的估算时间范围为2到8小时。

估算方法 🛠️

到目前为止，你已经了解了估算是什么、如何使用以及何时可变性最小。但你还没有学习如何进行估算。现在让我们来探讨这个问题。

有多种方法可以用来生成估算。我们之前说过，估算应该是不可协商的，并且应该基于某种数据。

以下是几种常见的估算方法：

自下而上法
在这种方法中，你需要将项目分解为小的、可管理的任务，就像本课程前面介绍的工作分解结构那样。估算小任务比估算整个项目更容易、更准确。分解任务后，为每个任务生成估算，然后将它们全部加起来，就得到了项目总估算。这种方法的优点是基于较小的估算，不确定性应更低。然而，这些任务的估算可能并非基于任何实际数据。你可能需要将此方法与另一种方法结合使用，以获得最准确的结果。

类比法
在这种方法中，你利用类似项目的经验进行估算。当然，这种方法适用于你和你的团队已经完成过类似项目的情况。你需要确保工作流程和使用的技术与之前使用的相似。这种方法的优点是易于使用和理解。如果团队完全相同，且项目与过去的项目相似，它也能基于团队已完成的工作提供准确的结果。但这种情况很少见，因为每个软件项目都有独特的需求和随之而来的独特问题。因此，这种方法肯定有许多缺点。

专家法
在这种方法中，你汇集多位估算者的估算结果。如果让多位估算者专门审视你的项目，这种方法成本可能很高。然而，你会得到更准确的结果。如果你使用的是专家对类似项目的估算，请注意你的项目可能有其独特的问题，因此估算不会完全吻合。

方法选择练习 💡

现在，让我们通过一个练习来应用所学知识。

假设你是一名软件产品经理，正在开发一款小型移动应用程序。你刚刚完成了一个类似的移动应用程序项目。你之前的项目中有两名开发人员也在这个新项目团队中。团队总共有八名开发人员。你已经创建了工作分解结构。你有一些专家的估算，但那是基于一个更大的移动应用程序得出的。你需要为你的项目创建估算。你的客户要求在一小时内提供估算，因此你只有时间完成一种估算技术。

在这种情况下，哪种估算技术效果最好？A. 自下而上法，B. 类比法，C. 专家法，还是D. 直接猜测？

理想情况下，你会利用所有可用信息来生成准确的估算。如果在这种情况下只能选择一种技术，最好的选择是使用自下而上法。因此，答案A是最佳答案，因为你已经有了现成的工作分解结构可供使用。类比法在这里并不理想，因为团队与你之前的团队有很大不同。新开发人员开发这个产品可能需要更多或更少的时间。由于专家的估算是基于更大的移动应用程序，它们可能对你不准确。而你永远不应该只是猜测估算。

总结 📝

本节课中，我们一起学习了任务时间估计。我们首先通过“不确定性锥体”理解了估算准确性如何随项目阶段变化：项目初期不确定性高，估算可变性大；随着项目推进和细节明确，估算会越来越可靠。接着，我们探讨了三种主要的估算方法：基于任务分解的自下而上法、基于历史项目经验的类比法以及汇集多方专业意见的专家法。每种方法都有其适用场景和优缺点。在实际项目中，结合具体情况和可用信息选择合适的方法，是做出有效估算的关键。记住，良好的估算是项目规划和成功交付的基石。

015：任务时间估计 📊

概述

在本节课程中，我们将学习一种使用公式来更精确地估算任务时间的方法。由于实际工作中存在各种变数，一个良好的时间估算不应只是一个单一的数字，而应该是一个范围。我们将通过一个具体的公式来计算这个范围，并理解不同置信度下的估算意义。

核心公式介绍

上一节我们介绍了几种估算时间的方法，本节中我们来看看如何通过一个数学公式来得出一个更可靠的估算范围。这个公式基于三个关键时间点：

最可能时间：我们称之为 TM。这是你对任务或项目最可能花费时间的估计。
乐观时间：我们称之为 TO。这是在一切顺利、团队高效工作的情况下，完成任务所需的最短时间。
悲观时间：我们称之为 TP。这是在最坏情况下，完成任务所需的最长时间。

基于这三个数值，我们将计算两个核心结果：

期望时间：我们称之为 TE。
标准差：我们称之为 σ。在数学中，希腊字母σ常用来表示标准差，它将帮助我们确定估算的范围。

计算公式

以下是计算期望时间和标准差的公式：

期望时间公式：
TE = (TO + 4 * TM + TP) / 6

标准差公式：
σ = (TP - TO) / 6

计算估算范围

计算出期望时间 TE 和标准差 σ 后，我们就可以确定估算的范围了。

首先，用期望时间减去标准差，得到范围的下限。
然后，用期望时间加上标准差，得到范围的上限。

用数学术语表示，这个范围就是 TE ± σ。

这个范围（TE ± σ）表示实际任务时间有 68.3% 的可能性落在这个区间内。

如果你希望估算更加可靠，可以将标准差加倍，从而得到一个更宽的范围，即 TE ± 2σ。这个范围表示实际任务时间有 95.5% 的可能性落在其中。

你需要根据项目实际情况来决定：是选择一个范围更宽但准确率更高（95.5%）的估算，还是选择一个范围更窄但准确率稍低（68.3%）的估算。

例题解析

让我们通过一个例子来具体应用这些公式。

假设我们有以下数据：

最可能时间 TM = 15 天
乐观时间 TO = 12 天
悲观时间 TP = 30 天

第一步：计算期望时间 TE

TE = (TO + 4*TM + TP) / 6
   = (12 + 4*15 + 30) / 6
   = (12 + 60 + 30) / 6
   = 102 / 6
   = 17 天

第二步：计算标准差 σ

σ = (TP - TO) / 6
  = (30 - 12) / 6
  = 18 / 6
  = 3 天

第三步：确定估算范围

68.3% 置信度范围：TE ± σ = 17 ± 3 天 → 14 到 20 天。
95.5% 置信度范围：TE ± 2σ = 17 ± (2*3) 天 → 11 到 23 天。

可以看到，95.5%置信度对应的估算范围（12天）比68.3%置信度的范围（6天）要宽，但可靠性更高。

练习题

你正在进行的项目数据如下：最可能时间 TM 为 26 天，乐观时间 TO 为 18 天，悲观时间 TP 为 46 天。

问题：根据公式 TE = (TO + 4*TM + TP) / 6，该项目的期望时间 TE 是多少天？

计算过程：

TE = (18 + 4*26 + 46) / 6
   = (18 + 104 + 46) / 6
   = 168 / 6
   = 28 天

因此，该项目的期望时间是 28 天。

重要提示：如果计算结果不是整数，请务必向上取整。例如，54.5 天应取整为 55 天，6.9 天取整为 7 天，23.1 天取整为 24 天。

学习建议

理解公式概念和亲自进行计算是两回事。为了确保你掌握了这项技能，强烈建议你完成课程提供的练习工作表。该工作表包含了多个示例，并附有详细的步骤解析答案页。如果在学习过程中遇到任何困难，欢迎在课程讨论区提问。

通过练习，你将能更自信地运用这种技术来生成更可靠的估算，这对于软件产品管理至关重要。

总结

本节课我们一起学习了如何使用 PERT（计划评审技术） 公式进行任务时间估算。我们掌握了如何根据最可能时间（TM）、乐观时间（TO）和悲观时间（TP） 来计算期望时间（TE） 和标准差（σ），并据此构建不同置信度（68.3% 和 95.5%）下的估算范围。这种方法将单一的时间点估算转化为一个更符合现实情况的范围估算，有助于进行更稳健的项目规划。

现在你已经学会了如何生成估算，接下来我们可以开始讨论迭代计划。在下一课中，我们将探讨任务依赖性以及如何在迭代规划中考虑它们。

016：任务依赖关系

在本节中，我们将详细探讨任务依赖关系。任务依赖关系是制定项目计划时需要考虑的关键因素，它描述了任务之间的相互制约关系。

在之前的软件过程与敏捷实践课程中，以及本课程的第一课里，我们曾简要提及任务依赖关系。任务依赖关系是指一个任务的开始或完成，依赖于另一个（或多个）任务的状态。

依赖关系的四种类型

两个任务之间可能存在四种依赖关系。我们将以第一个任务的状态为基准，来考察第二个任务如何依赖于它。这四种依赖类型是：开始-开始、开始-完成、完成-开始以及完成-完成。

开始-开始依赖

开始-开始依赖关系关联两个任务的开始。具体而言，第一个任务必须在第二个任务开始之前启动。这种依赖关系不涉及任务的完成时间。

想象一场两人赛跑，其中一位选手（选手A）获得先发优势。选手B必须在选手A起跑后才能开始跑。依赖关系并未规定谁先完成比赛。

一个更具体的例子是编写教科书和创建术语表。这两个任务可以同时进行，但你必须先开始编写教科书并识别出重要术语，才能将它们添加到术语表中。因此，你必须在开始编写术语表之前开始编写教科书。至于你是否在完成教科书后仍在添加术语，或者是否在完成术语表后还未写完书（只要没有新术语需要添加），都无关紧要。

开始-完成依赖

开始-完成依赖是指第一个任务必须在第二个任务完成之前开始。这种依赖关系不涉及第二个任务的开始时间。

当存在某种重叠交接时，可能会出现开始-完成依赖。想象一名值夜班的保安，接班的保安必须在他结束轮班之前开始工作，他才能完成自己的班次。

同样，假设你的团队采用每周冲刺，从周三开始到下周二结束。在冲刺规划中，你可能希望在当前冲刺期间规划下一个冲刺。这样，开发人员就能在下一个周三立即有效地开始下一个冲刺的任务。因此，规划下一个冲刺需要在当前冲刺结束之前开始。或者说，规划下一个冲刺对当前冲刺存在开始-完成依赖。

小测验：
罗纳德是一位为婚礼制作蛋糕的面包师。他需要设计蛋糕、烘烤蛋糕、装饰蛋糕以及将蛋糕交付给客户。以下哪组任务之间存在开始-开始依赖？
A. 设计蛋糕和烘烤蛋糕。
B. 烘烤蛋糕和装饰蛋糕。
C. 设计蛋糕和装饰蛋糕。
D. 装饰蛋糕和交付蛋糕。

罗纳德必须在开始烘烤蛋糕之前开始设计蛋糕，以便知道要烘烤哪种面糊以及大约需要制作多少蛋糕。他可以在蛋糕烘烤期间继续设计，并在蛋糕烘烤完成之前或之后完成设计。这没有影响，因为这是开始-开始依赖。因此，A是正确答案。

完成-开始依赖

完成-开始依赖是最常见的任务依赖类型，你将遇到的大多数依赖都属于此类。它是指第一个任务必须在第二个任务开始之前完成。

例如，你必须先完成给汽车加油，才能开始驾驶汽车。在软件开发中，你必须先完成某个功能的设计并明确其作用，才能开始编写该产品的用户手册或培训手册。

完成-完成依赖

正如你现在可以猜到的那样，完成-完成依赖是指第一个任务必须在第二个任务完成之前完成。

例如，你必须先完成向客户开具产品账单，再完成产品交付，以避免无法获得工作报酬。

小测验：
你的开发团队创建了一个数据库程序，用于存储医生诊所的病人信息。用户可以输入病人信息到数据库中，也可以按姓名搜索病人。这两个用户任务之间存在哪种依赖关系？
A. 开始-开始依赖。
B. 开始-完成依赖。
C. 完成-开始依赖。
D. 完成-完成依赖。

要搜索数据库，需要已经添加了病人信息。因此，搜索病人对向数据库输入病人信息存在开始-开始依赖。这些任务如何或何时完成并不重要。用户不需要拥有所有病人信息才能使用搜索功能。因此，A是正确答案。

总结与展望

本节课我们一起学习了任务依赖关系的四种基本类型：开始-开始、开始-完成、完成-开始和完成-完成。理解这些依赖关系是进行有效任务排期的基础。

现在你已经了解了任务依赖关系的类型，接下来需要看看这些依赖关系如何融入项目计划中。在本模块的剩余部分，我们将探讨基于依赖关系组织任务的规划技术。在下一课中，我们将从关键路径法图表开始学习。

017：CPM图

概述

在本节课中，我们将学习如何应用任务依赖关系来规划项目。具体来说，我们将介绍一种名为关键路径法图的可视化工具，它可以帮助我们组织任务、识别依赖关系，并找出完成项目所需的最短时间。

什么是CPM图？

上一节我们介绍了任务依赖关系，本节中我们来看看如何将其应用于实际项目规划。

当你思考一个大型软件项目时，会发现许多任务之间存在依赖关系，这些关系必须在计划中予以考虑。虽然存在多种任务规划方法，但本节课我们将重点介绍一种我个人喜欢使用的方法：关键路径法图，通常简称为CPM图。

CPM图是一种组织任务依赖关系的可视化方法。让我们先看一个例子，然后详细讲解如何为你的项目创建CPM图。

示例：制作意大利面晚餐

我们将为制作一顿意大利肉酱面晚餐创建一个CPM图。这顿晚餐将包含意大利肉酱面和凯撒沙拉。

首先，我们需要识别完成这顿晚餐所需的任务。

制作意大利面需要以下任务：

煮水
煮面条
沥干面条
加热锅
加热酱汁
将酱汁浇在面上

制作肉丸需要以下任务：

准备食材
混合食材
制作肉丸
预热烤箱
烘烤肉丸
将肉丸加入菜肴

制作沙拉需要以下任务：

切生菜
加入面包丁
加入奶酪
加入沙拉酱
搅拌沙拉

下图展示了我们的工作分解结构。请注意，我为烹饪任务添加了几个额外的关联任务（例如煮水、加热锅、预热烤箱）。

现在，我们需要为每个任务添加一个以分钟为单位的耗时估算。为简化起见，我们将使用单一的预期时间值，而非一个时间范围。

接下来，我们需要根据任务依赖关系开始组织任务。

构建CPM图：意大利面任务

让我们从意大利面任务开始。

我们知道，在煮面条之前需要先煮水。同时，在沥干面条之前需要先煮好面条。独立于这些任务，在加热酱汁之前需要先加热锅。我们需要在面条煮好并沥干、且酱汁已加热之后，才能将酱汁浇在面上。

因此，在CPM图中，它的呈现形式如下。箭头描绘了任务间的依赖关系。为简化起见，我们假设这些都是完成-开始依赖关系，即一个任务必须完成后，下一个任务才能开始。

CPM图包含路径。路径是沿着箭头从一个任务到另一个任务的序列。在CPM图的这个特定部分，有两条从头到尾的路径，即从图的开始到结束的路径。

一条路径以“煮水”开始，以“将酱汁浇在面上”结束。
另一条路径以“加热锅”开始，以“将酱汁浇在面上”结束。

位于不同从头到尾路径上的任务可以独立完成。例如，“煮水”任务可以独立于“加热锅”任务进行。

请注意，两条从头到尾路径的交汇点是任务依赖关系的协调点。在这个例子中，这个协调点就是“将酱汁浇在面上”这个任务；你必须在沥干面条并且加热酱汁之后，才能将酱汁浇在面上。因此，你必须协调“沥干面条”和“加热酱汁”这两个任务。

思考题：根据CPM图的这个部分，完成所有任务的最短时间是多少？
A. 22分钟
B. 14分钟
C. 8分钟
D. 16分钟

答案与解析：观察CPM图时，你需要分别查看每条从头到尾的路径。我们可以在煮水或煮面条的同时加热锅和加热酱汁。但是，我们无法加速“煮水 -> 煮面条 -> 沥干面条 -> 浇酱汁”这个过程，因为这些任务之间都是完成-开始依赖关系。如果我们累加该路径上任务的耗时估算，得到的是16分钟。因此，D是正确答案。

添加肉丸任务

接下来，让我们看看肉丸任务。这些任务基本上是顺序进行的。

我们需要在混合食材之前先准备食材。需要在制作肉丸之前混合食材。需要在烘烤肉丸之前制作好肉丸。同时，需要在烘烤肉丸之前预热烤箱。然后，在烘烤肉丸之后，需要将肉丸加入菜肴。此外，我们还需要等待意大利面和酱汁准备就绪。

现在让我们看看CPM图变成了什么样子。如图所示，我们现在有四条从头到尾的路径。在“将酱汁浇在面上”、“烘烤肉丸”和“将肉丸加入菜肴”处也有协调点。

添加沙拉任务

主菜规划完成后，让我们添加沙拉任务。

首先，我们需要切生菜。然后，面包丁、奶酪和沙拉酱加入沙拉的顺序无关紧要。它们可以各自成为一条路径，但都必须在搅拌沙拉之前加入。

让我们单独看这个沙拉任务计划。在CPM图的这个部分，有三条从头到尾的路径。如果你能同时进行加入面包丁、奶酪和沙拉酱这三个任务，那么你可以在5分钟内完成这整个部分。我们会说这三个任务是并行发生的。切生菜需要2分钟，并行任务需要1分钟，然后搅拌沙拉需要2分钟。

现在，我们可以合并所有的图表。

完整的CPM图与关键路径

这里是我们完整的CPM图。它阐明了我们所有的任务依赖关系和协调点。这是生成时间表的重要第一步。

从CPM图中，你可以确立一条关键路径。关键路径是两个逻辑点之间耗时最长的任务路径。由此，你可以确定项目所需的最短和最长时间估算。它决定了哪些任务是关键的（即位于最长耗时路径上），以及哪些任务存在浮动时间（即这些任务可以延迟而不会给项目增加额外时间）。

在寻找关键路径时，从项目开始到结束的路径很重要。例如，“开始 -> 煮水 -> 煮面条 -> 沥干面条 -> 浇酱汁 -> 加入肉丸 -> 结束”就是一条路径。

关键路径是从开始到结束、关联耗时估算最长的路径。在我们的例子中，“开始 -> 准备食材 -> 混合食材 -> 制作肉丸 -> 烘烤肉丸 -> 加入肉丸 -> 结束”这条路径估算需要38分钟，这是耗时最长的路径。因此，38分钟是完成这个项目可能所需的最短时间。

回想一下我们的工作分解结构，当我们累加所有估算时，显示完成需要77分钟。这假设我们是一个接一个地顺序完成每个任务。而CPM图向我们展示了哪些任务可以并行发生。我们可以在制作肉丸和意大利面的同时制作沙拉。关键路径将显示你完成所有任务可能所需的最短时间，这可能涉及需要额外的人手来承担并行工作。

思考题：考虑以下CPM图，其中方框内的数字是时间估算。关键路径的时间估算是多少？
A. 15分钟
B. 16分钟
C. 11分钟
D. 20分钟

答案与解析：关键路径如下所示（图中应高亮显示最长路径，例如 A->B->D->F）。当你累加这些估算时，得到16分钟。所以16分钟是完成这个项目可能所需的最短时间，因此B是正确答案。

浮动时间与调度

你希望首先安排关键路径上的任务。所有其他任务可以花费更多时间而不会增加项目的总耗时，这是因为项目中存在浮动时间。

当一条从头到尾的路径的估算时间小于关键路径时，就会出现浮动时间。在我们的示例中，我们有四条其他这样的路径，它们都有一些浮动时间。

浮动时间在你制定时间表时会成为你的朋友，因为它提供了灵活性，允许某些任务花费比预期更多的时间，而不会影响达到目标日期。

总结

本节课中，我们一起学习了如何使用关键路径法图进行任务规划。我们了解了如何通过CPM图可视化任务依赖关系，识别关键路径以确定项目的最短可能工期，并利用浮动时间为项目调度提供灵活性。CPM图是将工作分解结构转化为实际可行时间表的重要工具。

在下一课中，我们将看一种类似的任务规划方法，称为PERT图。

018：面向软件产品的敏捷规划

第4.3.4节 PERT图 📊

在本节中，我们将学习一种与关键路径法图表非常相似的任务规划工具——PERT图。我们将了解它的构成、如何解读以及如何利用它来优化项目时间管理。

PERT图简介

PERT图，全称为计划评审技术图。它由美国海军在20世纪50年代开发，用于管理北极星潜艇导弹项目。

与关键路径法图表类似，PERT图是项目的可视化表示。它描绘了一个由节点和边构成的网络或图。边是连接节点的线。

在PERT图中，节点（在关键路径法图表中代表任务）现在代表里程碑。我们在课程早期讨论过里程碑，它们不是基于时间的，因此每个节点代表某个事件的发生，通常是一个工作产品的产出或某个事件的发生。任务则由边来表示。

箭头的方向代表任务必须完成的顺序，这与关键路径法图表相同。在这里，一系列依赖任务由沿着箭头方向的边构成的路径来表示。每条边都标有任务名称和时间估算。

PERT图的构成与解读

上一节我们介绍了PERT图的基本元素，本节中我们来看看如何具体解读图中的路径关系。

当从一个节点引出多条独立的路径时，这表明任务可以并行执行。这意味着如果资源充足，这些并行路径可以同时完成，因为跨路径的任务之间没有依赖关系。

相反，当有多条路径汇聚到一个节点时，这表明这些路径需要同步。这意味着在进入从该节点引出的路径之前，所有汇聚的路径都必须完成。

让我们再次以意大利面和肉丸为例，这次我们将其转化为PERT图。

我们同样从制作意大利面开始。你可以看到，边同时标有任务和时间估算。节点则为了参考和简洁，仅用数字标记。与关键路径法图表类似，你可以看到路径1-2-4-5中的任务可以独立于路径1-3-5中的任务完成。

PERT图让依赖关系更容易看清。我们知道，在节点5之前必须完成两项任务。

在这个简化的PERT图中，任务X直接依赖于多少个不同的任务？
A. 1
B. 3
C. 8
D. 9

由于有三条边指向节点8（即任务X之前的节点），因此任务X直接依赖于三个任务。所以，B是正确答案。任务X也依赖于其他更早的任务，但那些是间接依赖。

识别关键路径与计算时差

现在让我们看看肉丸任务部分。在这个PERT图部分，一条关键路径是7-8-9-10-11-12。但还有另一条路径7-10-11-12。

接下来是我们的沙拉部分。这个PERT图展示了有时存在一些顺序独立但必须在进入下一步之前全部完成的任务。在这个例子中，添加面包丁、奶酪和调料都是顺序独立的，但必须在搅拌沙拉之前全部完成。

现在让我们合并我们的PERT图，为整个项目制作一个图表。

以下是完成后的PERT图的样子。合并图表时，一些共同的节点必须被连接起来。我保留了原始的编号，以便你能看到节点在哪里被连接。使用什么排序方案并不重要，我喜欢从左到右编号，这样当我提到一条路径时，节点编号总是递增的。

与关键路径法图表类似，关键路径在PERT图中非常重要。在PERT图中，你希望你的关键路径在图表中水平描绘。所有其他路径可以画在关键路径的上方或下方。

在这个PERT图中，哪条是关键路径？
A. 1-5-11
B. 1-3-6-9-11
C. 1-2-7-10-11
D. 1-4-8-11
E. 需要更多信息

在PERT图中，关键路径在图表中水平描绘，因此我们不需要更多信息。我们知道路径1-2-7-10-11是关键路径，即使我们不知道任务的时间估算。因此，C是正确答案。

你可以用我们在关键路径法图表中讨论的相同方式来使用关键路径，以计算完成项目所需的最短时间。由于完成关键路径比完成任何其他路径花费的时间都长，因此在安排不属于关键路径的任务时，你有一些灵活性。只要其他从头到尾的路径在关键路径完成之前完成，就不会影响整个项目的时间。

当你有任务不在关键路径上，并且可以延迟而不增加项目时间线时，我们说这些任务存在时差。

如果我们看示例PERT图，如果你累加完成关键路径上所有任务所需的时间，需要38分钟。这是项目可能花费的最短时间。这要求我们按顺序完成关键路径上的所有任务，中间没有间隔，并且我们能够完全多任务处理，在完成关键路径的同时完成所有其他任务。

由于没有其他路径像关键路径一样长，我们在安排时间上有一些灵活性或时差。例如，完成沙拉路径需要5分钟：切生菜2分钟，并行添加面包丁、奶酪和调料1分钟，然后搅拌沙拉2分钟。我们可以在完成关键路径所需的38分钟内的任何时间点安排制作沙拉。无论我们在38分钟内何时安排，都不会给项目增加额外时间。我们可以在准备食材时开始，或者在烤制肉丸时全部完成。这是因为存在时差。

如果我们延长完成关键路径上某个任务的时间，将会增加完成项目的最短时间。例如，如果我们在混合食材和制作肉丸之间有5分钟的休息时间，那么我们的最短时间现在就变成了43分钟。这是因为关键路径上没有时差。

CPM图与PERT图的对比与选择

现在你既了解了关键路径法图表，也了解了PERT图，你应该使用哪一个？

这实际上取决于个人偏好以及你试图做什么。在这个例子以及你将面对的大多数情况下，两者都很好用。关键路径法图表更侧重于任务，你可以向任务添加更多信息，如成本，然后创建一个基于时间的关键路径和一个基于成本的关键路径。

如果你的项目是基于事件或里程碑的，PERT图效果更好。它向你展示了在一个事件之前需要完成的所有任务。

无论你选择哪种方法，两者都是完成你任务规划的重要步骤。

总结与下节预告

本节课中，我们一起学习了PERT图。我们了解了它的历史、构成元素（节点代表里程碑，边代表任务），以及如何用它来识别关键路径和计算任务时差。PERT图特别适合以里程碑为导向的项目规划，能清晰展示任务依赖关系和并行工作机会。

在本模块的下一个也是最后一个课程中，我们将学习迭代计划。这将是你经常用来管理冲刺内任务的日程表。

019：迭代计划 📋

在本节中，我们将学习迭代计划。迭代计划是敏捷开发中的关键活动，它确保开发团队能够以可持续的节奏高效工作，并按时交付产品功能。我们将了解如何召开迭代计划会议、如何基于团队速率选择用户故事、如何将用户故事分解为开发任务，以及如何让团队自主认领任务。

什么是迭代计划？

迭代计划对于确保开发人员专注于任务以及项目按计划进行至关重要。

迭代计划有助于确保您的开发团队在每个迭代中既不会过度承诺，也不会工作量不足。这能使开发保持在一个有效且可持续的节奏上。

迭代计划是大多数敏捷方法的一部分。值得注意的是，Scrum和极限编程都使用迭代计划。在本课中，我们将使用来自Scrum的术语，例如冲刺、产品负责人和Scrum主管。这些术语在《软件过程与敏捷实践》课程中已作介绍。在这里，术语“迭代”和“冲刺”是同义词。

迭代计划会议

迭代计划在冲刺计划会议中生成。这些会议应该是限时的。这意味着会议的长度在会议开始时就被固定下来，并且应该严格遵守。这可以防止您的会议偏离主题，并避免不必要的过度规划。对于第一次冲刺计划会议，四小时通常是一个合适的限时。

设定冲刺目标

在冲刺计划会议开始时，团队应确立一个冲刺目标（如果您在发布计划中尚未这样做）。我们在学习Scrum时讨论过这一点。这是所规划冲刺的总体关注点。这有助于使开发专注于相关任务。

报告项目速率

接下来，您需要报告上一个冲刺的项目速率。这是一个重要的步骤。本次冲刺的所有开发承诺都将基于这个速率。

但是，如果您上一个冲刺是一个异常冲刺，不能代表团队的实际开发速率呢？在这种情况下，请使用您之前冲刺中的最低速率。

示例：
您和您的开发团队已经进入了项目的第四个冲刺。您正在为这个冲刺召开冲刺计划会议。

在第一个冲刺中，您的开发团队能够完成待办事项列表中价值10个故事点的工作。
在第二个迭代中，您的团队完成了12个故事点。
在第三个冲刺中，您的团队遇到了硬件故障，导致损失了一些开发天数。此故障现已修复。然而，您的团队只完成了为该冲刺计划的5个故事点的工作。

您知道应该基于前一个冲刺来规划第四个冲刺的开发。但您认为它不能代表团队的开发速率。您查看发布计划，发现有13个故事点的用户故事被安排在此次冲刺。

问题： 您认为应该基于多少个故事点的用户故事来做出承诺？
A. 10个故事点， B. 12个故事点， C. 5个故事点，或 D. 13个故事点。

答案： 如果您的团队经历了一个与通常开发速率相比异常的冲刺，那么您不应该将该速率用于后续冲刺。它不能代表团队的通常产出。在这种情况下，您应该基于项目中先前的最低速率来估算。在此示例中，先前的最低产出是10。在为您即将到来的冲刺生成迭代计划时，应使用此值。因此，A是正确答案。

确定冲刺的潜在用户故事

接下来，您将确定冲刺的所有潜在用户故事。这将包括根据发布计划计划在此冲刺中完成的所有用户故事。这也可能包括任何未完成但本应在上一个迭代中完成的用户故事。这些未完成的用户故事是那些未满足团队“完成的定义”的故事。重要的是，您的团队要遵守他们承诺的“完成的定义”。这些用户故事可能包括任何未能通过其验收测试的故事。

选择用户故事

从潜在用户故事中，您的产品负责人将选择他们希望在此冲刺中完成的故事。请记住，这是基于先前的速率。因此，只要所选用户故事的故事点估算总和小于或等于速率，产品负责人就可以继续选择用户故事。所有其他未被选中的用户故事将不得不等到未来的冲刺。

将用户故事分解为开发任务

选定的用户故事随后被分解为开发任务。这是由开发团队在没有产品负责人参与的情况下完成的。开发任务应该足够小，以便能在一两天内完成。

如果您有一个通用的用户故事，例如：

作为一个用户，我希望将信息输入数据库，以便我以后可以使用它。

此用户故事的开发任务可能包括：

设计数据库
开发数据库
在用户界面上创建输入字段
为此功能创建文档
为此功能编写测试
为此功能运行测试

示例：
您是开发音乐流媒体应用程序的团队的软件产品经理。您的开发团队正在根据迭代的用户故事确定开发任务。您遇到了以下用户故事：

作为一名听众，我希望将歌曲保存到播放列表，以便我可以轻松找到这些歌曲以便稍后播放。

问题： 以下哪些是此用户故事的开发任务？
A. 编写测试以确保保存的歌曲出现在播放列表中。
B. 编写将歌曲保存到播放列表的功能程序。
C. 为应用程序生成线框图。
D. 向使用手册中添加将歌曲添加到播放列表的说明。

答案： 编写测试、编写功能程序和创建文档都是源自用户故事的常见开发任务。因此，答案A、B和D都是正确的。应用程序的线框图应该已经在早期的需求或用户界面设计活动中确定。添加歌曲的功能不会对用户界面有太大改变（可能是一个添加歌曲的按钮和一个到播放列表的链接），因此不会对用户界面构成重大更改。生成线框图不是此用户故事的开发任务。

估算任务时间

接下来，开发人员需要共同估算他们认为每项任务需要多长时间。Scrum团队是跨职能的，因此任何开发人员都应该能够承担任何任务。然而，开发人员的速度各不相同，因此每项任务估算实际上是团队商定的平均值。如果一项任务需要专业技能并且必须分配给特定人员，那么估算可以基于该人员。尽管如此，团队必须同意该估算。

任务估算应以小时、半天或天为单位。小于一小时的小任务应分组在一起。此外，估计需要超过三天的大型任务应分解为更小的任务。

调整用户故事承诺

一旦完成任务估算，您将需要重新审视为冲刺选择的用户故事。考虑到开发人员的总可用时间和任务估算，所选用户故事的开发任务能否在冲刺内合理完成？

如果无法完成所有用户故事，那么开发人员需要调整他们的承诺。产品负责人需要移除用户故事，直到剩余故事的任务总估算时间与开发人员的总可用时间相匹配。被移除用户故事的相关开发任务也从迭代计划中移除。

相反，如果用户故事可以在有大量剩余时间的情况下完成，那么产品负责人可以选择额外的用户故事。开发人员仍然需要确定这些故事的相关开发任务。只要任务的总估算时间不超过开发人员的总可用时间，产品负责人就可以向冲刺中添加用户故事。

在迭代级别生成的任务估算会覆盖在发布计划中生成的用户故事估算，因为它们更具体且可能更准确。您可能需要相应地调整您的发布计划。由于这种不确定性，发布计划通常只规划最多未来几个冲刺，并定期进行调整。

开发人员认领任务

现在是您的开发团队认领任务的时候了。认识到让他们自主分配任务而管理者不进行分配是很重要的。自主分配使开发人员能够从事他们感兴趣的任务。这带来了更快乐的开发人员以及更好的软件。

与为冲刺选择用户故事的方式类似，开发人员应根据他们的可用时间自主分配和选择任务。这也允许开发人员考虑他们在工作中可能涉及的其他承诺和项目。

总结

现在，您、您的产品负责人和您的开发团队都对即将到来的冲刺中对他们有何期望达成了共识。您已经基于速率、任务估算和可用时间生成了一个现实的承诺。开发人员都知道他们将完成什么以及对他们有何期望。您的产品负责人确切知道在下一次产品演示中可以期待什么。目前，在开发领域一切顺利。

在下一个模块中，Bradley将带您了解风险规划的基础知识。识别、缓解和准备应对风险是一个重要的规划步骤，可以使您的产品免于 unforeseen 的问题。

020：反面模式 🚫

在本节课中，我们将要学习软件项目管理中的“反面模式”。这些是项目中常见的、会导致失败的行为或情况。了解它们有助于我们识别并避免这些陷阱，从而提升项目成功的概率。

前面的三个模块已经为你提供了制定优秀计划、为项目真正成功奠定基础所需的工具。这些工具很有价值，请务必多加练习使用。

然而，还有一些东西是缺失的。缺失的部分是如何处理那些可能导致一个规划完美的敏捷项目失控的个体风险。在本课程中，这些你们可能知道自己不知道的事情，就是运行软件项目所伴随的风险。基本上，你知道存在风险，但不确定具体是哪些风险。本模块的重点就是揭示其中许多风险，并向你展示如何尽可能地减轻这些风险。

让我们开始吧。在本节中，我将介绍反面模式。

反面模式本质上是项目可能失败的常见方式。当然，你希望尽可能避免它们，而避免它们的最佳方法就是了解它们是什么。

一个反面模式是项目中经常出现的、会带来负面后果的情况。存在大量不同的反面模式。有些与编写代码有关，有些与软件架构有关，还有一些与软件项目管理方式有关。由于这是一门软件产品管理课程，我们将重点关注属于管理类别的那些反面模式。

许多反面模式被不同作者赋予了不同的名称，但核心理念是相同的。即使在管理层面，也存在许多不同的反面模式。因此，我将只介绍其中的几个。如果你想查看完整的反面模式列表，请查阅课程资源，那里我列出了链接，供你根据需要探索更多反面模式。

管理类反面模式主要围绕人展开。项目可能因个人或群体的行为方式而失败。让我们从涉及群体的问题开始，稍后再讨论涉及个人的问题。

以下是第一个要介绍的群体反面模式。

分析瘫痪通常发生在你的开发团队陷入项目的规格说明阶段时。客户或产品经理可能陷入困境，试图预先完全分析产品需求，并且在该分析完善之前无法决定产品的方向。这对项目的进展和成功是有害的，因为它通常意味着你的开发团队停滞不前。由于在分析中瘫痪，项目最终被不必要地延迟。开发人员发现这种情况令人沮丧。他们已准备好开始开发，但你更害怕选错道路，而不是取得任何实际进展。结果，你最终坐等更多信息，而不是把事情做完。

要避免这种情况，最好的方法是运行一个具有增量发布的敏捷项目。如果你在项目开始时并不了解所有事情，那没关系，你不必预先知道一切，因为你在整个项目中为灵活性和变更留出了空间。如果每个人都理解项目将随着时间的推移而完善，而不必预先知道一切，事情进展会快得多。

塔尼亚是一名软件产品经理。她和她的开发团队在过去一个月里一直试图与客户细化需求，以确保在开始构建之前一切都完美无缺。她掌握了所有需求的基本情况，其中一些已经可以开始，但整个产品尚未完全定义。鉴于她的产品没有完全定义，塔尼亚的最佳行动方案是什么？

A. 向客户探询更多信息。
B. 用她已有的信息开始开发。
C. 继续细化需求。
D. 放弃项目，没有希望了。

正确答案是 B。找出你的项目是否可行的唯一真正方法就是构建它。塔娜已经陷入了分析瘫痪。她最好继续前进。

上一节我们讨论了分析瘫痪，接下来看看另一个常见的反面模式。

本末倒置是一个常见的英语习语，讽刺以适得其反的顺序做事。在软件产品管理中，本末倒置的定义非常相似。它指的是过分强调项目中应该稍后完成的部分。一个很好的例子是，程序员被从开发关键功能中抽调出来，去开发一个目前不需要的功能。通过本末倒置，团队可能会发现他们有很多重要性不同但开发不佳的功能。更好的替代方案是拥有少数几个开发良好且重要的功能。

为了避免本末倒置，开发团队必须将精力集中在当前需要完成的任务上，而不是未来需要完成的任务上。

除了顺序问题，群体决策也可能出现问题。群体思维是一种可能使软件项目瘫痪的反面模式。群体思维是社会科学中的一个术语，描述了人们倾向于遵循群体的普遍意见，即使他们个人不同意。这种现象导致了许多问题，不仅仅是在软件领域。糟糕的决策可能是群体思维的结果。

群体思维的一个典型例子是，当一群开发人员协作设计产品架构时。如果你曾经是这样一个小组的一员，你可能已经注意到，一两个人的想法可能会主导会议。其他不那么健谈的开发人员为了避免冲突而保持沉默。这可能导致产品不佳。通常，存在一些小组没有讨论的选项。如果建设性地管理，冲突是可以接受的。

避免群体思维的一种方法是默默地生成问题解决方案。还记得《软件过程与敏捷实践》课程中的精益软件开发吗？精益通过让团队分成多个小组来解决这个问题，每个小组负责构想自己的解决方案。然后，当所有小组都制定好解决方案后，团队再聚在一起，合并解决方案。这是最小化群体思维影响的好方法。

我建议你在个人层面也这样做。与其让团队分成更小的小组，不如让每个人在纸上写下自己的解决方案，不说话。然后大家再聚在一起，团队可以依次讨论每个人的想法。这可以防止一两个人主导小组讨论。

你是一名软件产品经理，正在与你的开发团队开会，试图找到客户问题的最佳解决方案。团队正在讨论解决方案，但你注意到你的一位开发人员对主导的解决方案似乎感到不安。为了避免群体思维，在这种情况下你应该怎么做？

A. 什么都不做，如果开发人员有话要说，他们会说出来。
B. 让这位开发人员当场表态，挑战他们说出自己的想法。
C. 引导小组在比较想法之前，先把所有想法写在纸上。
D. 把开发人员拉到一边，告诉他们主导的解决方案通常是最好的。

这里的正确答案是 C。为了避免针对任何人，一个好的策略是让你的开发人员各自离开，在纸上写下解决方案，然后再比较笔记。这样，每个人的想法都能得到表达。

本节课中我们一起学习了软件项目管理中的几个关键反面模式：分析瘫痪、本末倒置和群体思维。了解这些常见陷阱是成功管理敏捷项目的重要一步。通过采用增量开发、聚焦当前任务以及鼓励独立思考等方法，我们可以有效规避这些风险，推动项目朝着正确的方向前进。

021：反面模式团队

概述

在本节课中，我们将要学习软件开发中几种常见的“反面模式”。这些模式描述了团队在规划与开发过程中可能陷入的低效或有害的工作方式。理解并避免这些模式，对于构建高效、协作的团队和成功的产品至关重要。

上一节我们介绍了团队协作的重要性，本节中我们来看看几种阻碍团队效率和产品质量的常见模式。

筒仓效应

一种有效完成开发工作的方式，是让团队分成小组提出想法，然后回来比较解决方案。组织也常因不同项目需求而分成小组。虽然独立小组通常能高效完成工作，但也容易导致这些小组之间失去联系。当一个团队与其他团队失去联系时，我们称之为在“筒仓”中工作。

筒仓对软件开发组织是有害的。它代表了组织内部缺乏沟通。这容易导致公司失去统一的形象，并让适得其反的管理策略占据主导。开发者不是与其他团队公开协作，而是在真空中开发功能。一个开发团队创建的产品，可能与走廊另一头的另一个团队的产品截然不同且互不兼容。

如果这些团队需要在某个时间点合作，会发生什么？没有定期沟通，这将不是一项容易的任务。

以下是解决此问题的一些方法：

减少管理层级：如果你的组织拥有相对扁平的管理结构，就可以避免许多办公室官僚作风，并让人们直接（最好是面对面）交流。
鼓励积极氛围：在组织内鼓励积极的团队间沟通氛围。如果团队鼓励协作，项目成功的可能性远高于每个人对此漠不关心的情况。

情景练习：
Abel是你的一名顶级开发人员。他来找你，希望你能帮助他与一个开发团队沟通，该团队开发了他正在改进的产品。他曾尝试联系其他开发人员，但他们总是让他去找管理层。

Abel要获得所需信息，理想的组织结构是什么？
A. 横向：开发人员直接与其他开发人员交谈。
B. 纵向：开发人员与经理交谈，经理再与其他经理交谈。
C. 对角线：开发人员与其他团队的经理交谈。

正确答案是 A。Abel如果能与最初编写他正在改进的代码的人交谈，将获得最有用的信息。与经理交谈是一种相当低效的做法，尽管这在组织中很常见。

供应商锁定

另一个常见的反面模式称为“供应商锁定”。顾名思义，当开发团队围绕单一技术解决方案或供应商创建产品并严重依赖它时，就会发生供应商锁定。

使用一项技术是因为它是最佳选择，这是一回事；使用一项技术是因为它是唯一可能的选择，则是另一回事。在供应商锁定的情况下，开发团队会在未来发展中无意中导致其产品依赖一项技术。如果有一天该技术无法满足他们的需求，就会导致无法适应变化。

我见过最糟糕的供应商锁定案例之一，是一个使用供应商专有编程语言的软件项目。通过使用这种语言，该组织被迫使用该供应商提供的所有其他产品：专有文件格式、函数、数据格式等一切。最糟糕的是，该组织使用该系统的时间太长，以至于转向更好的解决方案的成本将高于维持现状。该组织非但没有发展，反而被迫处理迅速过时且难以维护的技术，这对项目中的任何人来说都不是理想的情况。最终，员工开始因为被迫使用该供应商不可靠的产品而离开组织。当这种情况发生时，组织意识到人员成本太高，并做出了适当的改变。然而，情况并非总是如此。有时，供应商锁定在组织中根深蒂固，以至于组织自身的健康也依赖于该供应商。

那么，如何从一开始就避免供应商锁定呢？一种方法是在决定采用某项技术或解决方案之前，真正做好研究。当时这可能看起来是一个微不足道的决定，但如果没有正确的信息，很容易陷入困境。在做出任何财务或其他方面的承诺之前，最好了解所有选项。

情景练习：
Sandy是一名软件产品经理，正在启动一个新项目。一家供应商联系她，想向她销售他们的数据库产品。在与她的开发团队交谈后，她了解到该产品对她的团队确实有用。

Sandy的下一步应该是什么？
A. 退出。如果她需要这个产品，她自己会找到。
B. 做更多研究。也许存在其他产品，或者当前产品有问题。
C. 购买该产品。它符合她开发团队的需求，无需进一步寻找。

答案是 B，做更多研究。为避免被供应商锁定，在做出任何承诺之前，研究你的选项总是一个好习惯。

过度工程与镀金

接下来的两个反面模式——过度工程和镀金——与开发团队创建产品本身的方式有关。

过度工程指的是创建比实际需要更复杂的产品。例如，当开发团队在用户界面中塞入许多不必要或推测性的功能时，就会发生这种情况。这可能会将一个功能完善的产品变成一个臃肿的、带有太多额外功能的产品。产品最好会变得使用起来令人困惑，最坏则会完全无法使用。这在旧系统中体现得尤为明显。想想你遇到过的一些过度设计的用户界面，例子很多：允许你选择播放速率和压缩率的音乐播放器；在让你看到图像之前带你经历一系列自定义设置的基本图片查看器，等等。

镀金指的是在项目中投入努力，直到达到收益递减点。在几乎所有的软件项目中，都存在一个点，超过这个点后，你对某个功能投入的任何额外努力都不会真正为产品增加价值。这不一定意味着产品过度工程化，尽管也可能如此。镀金通常是软件开发团队为了给客户留下深刻印象而添加额外功能的结果。

从本专业之前的课程中你知道，用户需求应由客户指定并与开发团队讨论。有时，特别是在缺乏经验的开发团队中，团队希望超越他们的需求。尤其是当团队提前完成任务时，他们可能会觉得有必要添加他们认为会让客户印象深刻的额外功能。结果非但没有给客户留下深刻印象，反而让客户感到困惑和失望，开发人员的额外努力也白费了。

那么，如何避免过度工程和镀金呢？解决方案很简单：当产品运行良好时，就停止工作。那些花哨的额外功能可能不需要添加。如果你真的认为需要添加，尝试与客户建立一个新功能的审查流程。问问自己，这个功能是改进了产品，还是仅仅让界面更混乱？它是否削弱了产品的主要功能？如果这些问题的答案是否定的，那么你可以考虑添加该功能。当然，这需要得到客户的同意。

确保最终产品尽可能好的另一种方法是进行用户研究。用户研究涉及抽取一小部分用户样本，让他们试用新功能并给你反馈。这些反馈可以为你提供宝贵的见解，了解该功能是否有用、它如何影响你的用户界面、它是否具有广泛的吸引力以及如何改进它。

情景练习：
Kit正在开发一款改善小学教育的软件。她已经发布了产品，并完成了所有利益相关者建议她做的改进。她坐在电脑桌前，决定既然有时间就再添加一些功能。

如果这些功能没有为Kit的产品增加太多价值，Kit陷入了哪种反面模式？
A. 过度工程
B. 积压工作
C. 延迟
D. 镀金

答案是 D，镀金。Kit实际上是在做不会为她的产品增加太多额外价值的工作。她最好将精力集中在其他地方。

总结

本节课中我们一起学习了软件开发中几种关键的反面模式：筒仓效应阻碍了团队间的有效沟通；供应商锁定使产品过度依赖单一技术，限制了未来发展；过度工程和镀金则导致产品变得臃肿或投入了无价值的额外努力。识别并避免这些模式，是进行高效敏捷规划和构建成功软件产品的重要基础。

022：反面模式开发

概述

在本节中，我们将探讨软件开发中的几种“反面模式”。这些模式描述了在项目管理中，因投入精力不当——无论是过多还是过少——而导致效率低下或项目失败的具体情况。我们将逐一分析这些模式，并讨论如何避免它们。

过度投入的问题：视图工程

上一节我们讨论了“镀金”问题，即过度专注于非核心功能。本节中我们来看看另一种因“过度投入”而引发的问题。

乍一看可能很奇怪，但在项目中投入过多精力也可能成为一个问题。然而，这里指的并非开发人员懒惰或因此错过截止日期，那是另一个完全不同的问题。这里讨论的是，由于某些管理实践，导致开发人员难以专注于开发工作，因为他们被其他事务过度分散了注意力。

敏捷软件开发强调可工作的软件胜过详尽的文档，原因在于编写详尽的文档需要时间，而且是宝贵的开发人员时间。这并非主张完全不编写文档，那会带来其他问题。过度专注于详尽文档是“视图工程”这一反面模式的典型例子。

与“镀金”类似，这是工作重心不明确或未聚焦于重要、高价值事务的结果。

以下是“视图工程”的核心定义：

视图工程是指开发人员花费大量时间构建演示文稿、报告和文档，而非编写代码，从而扼杀了自身的生产力。

这种情况通常发生在具有垂直管理结构的组织中。在这类组织中，为了证明一个概念，开发人员必须在推进之前对其潜力进行全面分析。这很像“分析瘫痪”，但发生在组织层面。

最佳的解决方案是消除阻碍开发人员进行产品开发的障碍。通常，用于创建所有必要报告和演示文稿的时间，足以创建一个基本的产品原型。原型通常比任何报告都更具信息量，并且还有一个额外好处：它提供了可工作的软件，后续产品可以在此基础上构建。如果最终确定该产品不值得投入开发时间，那么该原型也可以作为一个经验教训，为未来的项目提供参考。

案例分析：雷汉的期望

雷汉是一位软件产品经理，她要求开发人员在每周例会上使用幻灯片演示他们的想法。她这样做是为了让每个人的想法都能被准确、清晰地表达。

以下是关于雷汉期望的问题选项：
A. 开发人员的时间本应更好地用于编写代码。
B. 没问题，这是一种良好的沟通实践。
C. 软件开发人员不擅长制作幻灯片。
D. 幻灯片无法呈现问题的全貌。

答案是 A。软件开发人员用于项目的时间是有限的。如果他们花费时间制作演示文稿，那么用于创建实际产品的时间就会减少。

投入不足的问题：消防演习与英雄主义

想象一下，你的开发团队专注于编码并成功完成了所有工作。这是否足以说明项目成功？并不完全如此。那么，开发人员被迫加班以满足截止日期这种过于常见的情况呢？这种情况时有发生。

这种反面模式被称为“消防演习”。

消防演习是指开发人员在项目的大部分时间里工作投入不足，然后在临近结束时突然需要大力冲刺。

这可能是由于管理松懈或开发人员自身浪费时间造成的。当与客户的期望未得到妥善设定时，也可能发生这种情况。

“消防演习”是危险的，因为它通常会导致牺牲代码质量，以换取产品快速交付。本可以成为出色的产品，最终却变得平庸，因为没有足够的时间来妥善构建产品。

“消防演习”常常导致另一个反面模式，称为“英雄主义”。

英雄主义是一种略带讽刺的说法，描述项目依赖某一位开发人员近乎超人的技术能力来完成的情况。

这具有风险。人们会变得依赖这个人来完成工作，甚至不仅仅是在最后的大力冲刺阶段。避免这种情况的最佳方法是在项目早期与客户建立明确的期望，并遵循敏捷软件开发实践。

你可以实施时间盒和其他规划技术，为开发人员提供按时完成任务所需的结构。当管理者及其开发团队同样有动力完成项目时，也会有所帮助。如果每个人都能以稳定的节奏工作，就不需要“消防演习”或“英雄主义”。

概念辨析：英雄主义

以下哪项描述了软件开发中发生的“英雄主义”？
A. 软件开发团队是获奖团队。
B. 经常依赖一个人来解决他们的问题。
C. 团队中包含一个被蒙蔽的人。
D. 定期奖励良好行为。

答案是 B。软件开发中的“英雄主义”并非好事。它通常表明你的项目在流程或培训方面有待改进。

终极困境：死亡行军

当开发团队和管理层意见不合时会发生什么？当管理层难以让开发团队相信他们正在做的工作时呢？这被称为“死亡行军”。

死亡行军是指开发团队中的每个人都清楚项目注定失败，但出于义务，所有人仍然继续推进项目。

想象一下这带来的可怕后果。导致这种情况出现的原因可能是管理层出于财务原因将项目强加给开发团队，或者管理层固执己见，拒绝承认不可避免的失败。无论原因如何，如果构建产品的人自己都不相信它，你几乎可以断定该产品无法达到最佳状态。在“死亡行军”中，开发人员的士气低落，产品质量也因此受损。

总结

本节课中我们一起学习了软件开发中的几种反面模式：

视图工程：因过度投入于文档和演示而牺牲了实际的编码生产力。
消防演习：因前期投入不足，导致项目后期需要仓促、低质量的冲刺。
英雄主义：过度依赖个别成员的超常能力来完成项目，具有高风险。
死亡行军：团队在明知项目会失败的情况下仍被迫继续推进，导致士气与质量双输。

理解这些模式有助于我们识别项目管理中的陷阱，并通过设定清晰期望、采用敏捷实践、保持稳定节奏和提升团队士气来有效避免它们，从而更顺利地交付高质量的软件产品。

023：反面模式管理

在本节中，我们将学习软件开发中常见的几种反面模式，特别是由个人行为引发的管理问题。我们将探讨这些模式的表现、成因以及潜在的解决方案，以帮助您识别并改善团队中的不良实践。

反面模式可能源于群体行为或个人行为。许多由个人行为引发的反面模式，旁观者很容易识别，但当事人却难以察觉。当问题不出在自己身上时，批评总是容易的。但这种态度也可能使我们对自己的失误视而不见。为了解决接下来要描述的这些反面模式，营造一种开放、自省和持续改进的文化至关重要。

上一节我们介绍了反面模式的概念，本节中我们来看看几种具体的管理反面模式。

微观管理

让我们从最著名的反面模式之一——微观管理开始。微观管理非常普遍，几乎成了一个流行词。它是许多组织面临的真实问题。

微观管理发生在处于管理职位的人倾向于介入项目的每一个微小细节时。他们通常是那些要求抄送所有团队往来邮件的人，并且觉得有必要对工作场所的每一个决定或分享的观点发表意见。微观管理者想知道开发人员每分钟在哪里、在做什么。本质上，微观管理是关于控制。

微观管理源于某种程度上的不信任。这并不意味着这种不信任有现实依据，或者微观管理者的担忧是合理的。微观管理通常是管理者自身恐惧、不安全和压力的表现。微观管理者并非有意打击开发人员的士气。他们这样做是因为觉得没有他们的干预，整个项目就会崩溃。可能是因为过于激进的时间表、糟糕的产品质量，或者仅仅是担心没有合适的人选来完成工作。

无论原因如何，重要的是要认识到微观管理者是问题的根源。通常，被此人管理的团队成员会因其行为而受到指责。这不仅对团队士气有害，对产品也有害。正如我之前展示的，开发人员的士气不仅影响个人，也影响他们高效工作和与同事协作的能力。组织中的任何层级，没有人愿意在一个心理健康受到威胁的环境中工作。

那么，如何解决微观管理者的问题呢？最终，解决方案必须来自微观管理者自身。就像任何个人层面的反面模式一样，没有快速或简单的解决方法。要真正解决这个问题，表现出这种行为的管理者必须愿意承认其行为对团队有负面影响，并采取措施改进。这可能意味着寻求进一步的管理培训，或者努力增强自我意识并调整自己的行为。

以下是微观管理者通常不会表现出的行为：
A. 要求抄送所有项目往来邮件。
B. 向团队成员提供未经请求的建议。
C. 召开简短的每日会议评估项目状态。
D. 不断关注项目可能失败的方式。

答案是 C。微观管理者会表现出很多其他行为，但简短的每日状态会议本身并不值得担忧。事实上，这在Scrum项目中很常见，它们就是每日站会。

海鸥式管理

与微观管理者密切相关的一个反面模式是“海鸥式管理者”。这种人平时见不到，一旦出现问题，管理者就会“飞”进来，制造很多噪音，对每个人“狂轰滥炸”，然后“飞”走。引用该领域作家肯·布兰查德的话：“这很滑稽，但确实会发生。”这是一种与微观管理者不同的管理者，他们行为的动机也截然不同。

海鸥式管理者可能会在开发团队中引起与微观管理者同样多的骚动和压力。他们甚至可能无意中导致项目变成“消防演习”项目。对于开发团队来说，不断生活在担心下一次“轰炸”何时到来的恐惧中是充满压力的。

与微观管理者类似，海鸥式管理者的独特风格通常是由繁忙的日程、规划不足和巨大压力造成的。海鸥式管理者的行为可以用类似微观管理者的方式来解决，但通常最好的方法是减轻管理者的工作量。当然，作为软件产品经理，这可能不在你的职责范围内。如果你怀疑自己可能表现出海鸥式管理的迹象，或许是时候重新评估你的日程安排以及你与团队的互动方式了。

关于重新评估你与团队互动方式的最后一点本身就很重要。有时，管理者可能会在与团队的互动方式上变成海鸥式管理者。如果团队仍然觉得无法与管理者正常沟通，仅仅减轻管理者的工作量作用不大。

沟通不畅与电子邮件

造成沟通不畅的最大元凶是电子邮件。电子邮件沟通可以很快让一个善意的管理者变得令人不快。电子邮件的问题在于通常缺乏上下文，对于大多数沟通来说过于正式，并且很容易误解作者的意思。这是一个如此普遍的问题，以至于将电子邮件作为主要沟通方式本身也被认为是一种反面模式。

这个问题的解决方法很简单。花时间进行面对面沟通。对于远程团队，如果无法面对面，可以尝试其他解决方案，如在线团队聊天服务、视频会议和电话。花时间给予他人关注，你的投入将获得丰厚的回报。

塞雷娜在让团队回复她关于项目状态的电子邮件时遇到了问题。以下哪个是解决这个问题的最佳方案？
A. 发送更多电子邮件。
B. 打电话给开发团队负责人。
C. 什么都不做。
D. 与开发人员当面交谈。

最佳选择是塞雷娜与她的开发人员当面交谈。电子邮件可能造成隔阂且容易被误解。正确答案是 D。

总结

本节课中，我们一起学习了三种常见的个人管理反面模式：微观管理、海鸥式管理以及过度依赖电子邮件沟通。我们探讨了它们的特征、根源，并提出了改进建议。关键在于培养开放、自省和信任的团队文化，并选择更直接、更人性化的沟通方式。识别并主动调整这些行为模式，对于提升团队士气、生产力和最终的产品质量至关重要。

024：反面模式——个人开发者

概述

在本节课中，我们将要学习两种由个体开发者引发的、可能对团队和项目产生负面影响的“反面模式”。我们将了解“独行侠”和“知识暴力”这两种行为的具体表现、危害以及应对策略。

上一节我们讨论了管理者个人行为可能引发的反面模式。本节中，我们来看看源自个体开发者的几种反面模式及其应对方法。

第一种是“独行侠”。“独行侠”是指在不咨询团队其他成员的情况下，擅自做出重大项目决策的人。

他们也可能通过在任何话题上坚持己见，在工作场所制造问题。

“独行侠”非但不能帮助推进进度，反而常常通过提出琐碎的担忧、质疑每一件小事来阻碍进展。

如果此人频繁地坚持己见，团队中的其他人往往会为了避免争执而选择让步。

慢慢地，原本高效、开放沟通的团队会变成一团糟。更糟糕的是，“独行侠”可能让所有人对问题变得漠不关心，从而导致群体思维的产生。

当“独行侠”不咨询团队就做出决定时，他们可能给其他团队成员制造更多工作，并给所有相关人员带来重大困扰。

这不是英雄主义。正如我在本课前面讨论过的，这是鲁莽行为。

对于“独行侠”，并没有快速的解决办法，解决方案通常取决于个体为何会如此行事。有时“独行侠”只是想制造麻烦，有时他们想证明自己的价值。

应对“独行侠”的理想方案是尝试让个体认识到自身行为的破坏性，并采取措施改变它。

这些人的个性往往使得改变比必要的更加困难。在这些情况下，有时需要采取组织层面的措施来解决问题。

一个“独行侠”可以摧毁一个开发团队，并迅速使生产力脱轨。尽管处理起来可能很困难，但尽快应对“独行侠”的行为至关重要。

另一种由个体（通常是开发团队成员）表现出的破坏性行为是“知识暴力”。这是本课我将讨论的最后一个反面模式。

“知识暴力”既关乎开发者的内心世界，也关乎我描述过的其他反面模式。

“独行侠”也可能使用“知识暴力”，让会议变得难以忍受。

“知识暴力”是指一个人利用其在某个领域的高级知识来恐吓他人的情况。

这可能表现为，当团队成员询问他们不熟悉的技术问题时，开发者居高临下地对他们说话。

正如你可能想象的那样，这种行为可能导致团队成员感到不被欣赏和不重要。

因此，你团队的士气会下降，并且你可能错过一些关键的想法，或者至少是澄清问题的机会。

以下是应对“知识暴力”问题的一些建议：

私下沟通：尝试与当事人私下交谈。请他们反思自己的行为如何影响团队中的其他人。
鼓励提问：鼓励在会议中实行“没有愚蠢的问题”政策。
促进开放沟通：此外，尝试鼓励工作场所的开放沟通，并杜绝预先评判他人的意见或经验不足。

与“独行侠”一样，尽早处理这个问题非常重要，以免它对你的团队和项目产生持久影响。

让我们通过一个例子来巩固理解。

斯图尔特整个星期都坐在自己的办公室里，没有与团队中的其他开发者交流。

作为团队经理，波莉安娜走近斯图尔特，想看看他在忙什么。

当她与斯图尔特交谈时，他告诉她，他已经更改了团队的用户界面，以更好地符合正确的实践规范。

波莉安娜询问团队其他成员是否知道此事，他们告诉她并不知道。

斯图尔特表现出了哪种反面模式？
A. 无效行为
B. 知识暴力
C. 独行侠
D. 专家行为

这里的正确答案是 C。

在未经他人知晓的情况下对产品进行更改，斯图尔特的行为属于“独行侠”。

为了解决这个问题，波莉安娜应该首先鼓励斯图尔特更定期地与团队沟通，并避免在未先与团队其他成员讨论的情况下做出更改。

现在，让我们看看行业专业人士如何处理这些反面模式。

关于沟通媒介的见解：
“将电子邮件作为主要沟通工具在当今听起来是件很容易的事。每个人都在使用电子邮件，事实上，我认为它被过度使用了。我绝不会推荐将电子邮件作为主要的沟通媒介。在考虑沟通媒介时，我建议考虑两点：第一，你的利益相关者偏好的沟通媒介是什么？他们喜欢如何沟通？归根结底，这真的不是关于你的偏好和你的沟通媒介偏好，而是关于接收项目可交付成果的人。所以，他们希望如何被沟通？是通过电话、电子邮件、面对面还是其他方式？因此，要找出他们偏好的沟通媒介。至于将电子邮件作为主要沟通媒介，我还建议回归到电话或面对面的沟通。我认为我们过于依赖电子邮件，而电子邮件作为一种策略常常被误解，或者作为一种沟通媒介可能适得其反。它实际上可能导致沟通不畅，例如你试图通过电子邮件传达的语气或声音可能无法以你希望的方式被理解。因此，电子邮件有时会给你带来新的挑战，因为人们可能不会以你预期的方式理解那条信息，从而给你自己制造了更多工作。所以现在你必须去管理不同的个性、处理不同的情况，而这一切都是因为一封电子邮件的解读方式。因此，我建议主要沟通方式应符合你利益相关者的偏好，同时确保你记得还有电话，实际上也可以与人进行面对面的交谈。”

关于知识暴力的见解：
“知识暴力在我们的项目中是真实存在的。知识暴力可以定义为人们利用信息或知识作为权力，来恐吓项目中的其他人。因此，作为产品或项目经理，你需要真正理解不同人的个性，并了解如何打破一些信息孤岛和团队成员之间的信任壁垒，让他们明白，知识和信息只有在共享时才能真正发挥最大价值。为了取得你试图从项目中获得的结果的成功，你需要找到方法进行团队建设、建立信心，让你的团队和资源真正信任彼此，并创造安全的环境，这样他们才会分享。你希望从团队中得到的是确保和增强对彼此个性的理解，这样他们就能在一个安全的环境中感到舒适，分享他们所拥有的任何信息，并认识到你项目的真正成功取决于他们将进行的信息共享。”

好了，这就是我在本课程中要介绍的所有反面模式。正如我在课程开头所说，反面模式还有很多，这里只是从项目管理角度介绍的一小部分。然而，也存在专门与编码和软件流程相关的反面模式。如果你感兴趣，课程资源中有链接可以帮助你更深入地了解。

引用该领域的另一位作家史蒂夫·麦康奈尔的话：“有些错误犯得太多，以至于被认为是经典。另一些则是特定项目所独有的。”既然我们已经讨论了经典的反面模式，接下来让我们简要谈谈你可以做些什么来应对这些项目特有的错误。

请加入下一节课，一同探索。

025：常见失败原因

概述

在本节课中，我们将学习软件项目中常见的失败原因，这些原因通常被称为项目风险。我们将探讨不同类型的风险，并了解它们如何影响项目的成功。

课程内容

上一节我们介绍了反模式，本节中我们来看看一些常见的、不一定是模式的项目失败原因。这些通常被称为项目风险类型。

风险是指可能导致项目失败的因素。在任何情况下都存在风险，不仅仅是软件项目。事实上，你现在正在做的事情也存在风险。但暂时不要改变你的做法，因为替代方案也有其自身的风险。

范围风险

我将介绍的第一种风险是范围风险。这指的是涉及需求扩展的风险。需求扩展对任何项目都是危险，因此你处理这种风险的方式会影响它对项目的影响。如果你有良好的变更控制措施，例如运行敏捷项目，就不必过于担心。然而，如果你的项目不能很好地处理变更，你可能需要考虑改变一些做法。

技术风险

技术风险是指你的技术失败的可能性。这不仅仅指硬件在客户手中起火。技术可能意味着某个软件协议变得过时或不再受支持。可能意味着你使用的技术无法很好地随客户业务扩展。也可能意味着你的团队根本不理解这项技术，导致其基本无法使用。

客户与利益相关者风险

你的客户和利益相关者也可能给你的项目带来风险。有时客户承诺向你的团队提供启动所需的材料，但他们忘记了或交付延迟。这是一个项目风险。有时客户变得冷漠，或者你的主要联系人发生变化，这是另一个重大风险。

人员风险

人员风险是另一组风险。这可能表现为团队成员离开团队，如果离开的成员拥有其他成员不具备的知识，则风险尤其大。这也可能表现为你的团队缺乏所需的才能。团队成员之间的冲突或沟通问题。群体思维，即我在上一课中介绍的一种反模式，也是一种人员风险。

其他风险

还存在许多其他风险。你的项目可能面临法律问题、安全问题，你的实体位置可能被摧毁。你的管理层或开发团队可能对项目失去兴趣。或者你可能需要处理工业间谍活动。无论风险是什么，你都需要能够为其制定计划。

风险识别练习

你正在与你的开发人员之一斯蒂芬合作一个项目。他告诉你他认识你的客户，并且他们关系不太好。斯蒂芬告诉你，他的工作不会受到影响，但他不确定客户是否同意他参与这个项目。斯蒂芬不确定是否应该让客户知道他正在参与这个项目，因为这可能会危及项目的成功。

以下是斯蒂芬向你提出的风险应归入哪一类？
A. 技术
B. 客户或利益相关者
C. 人员
D. 开发人员

正确答案是 B。这个问题属于客户风险。基本上，你的项目成功有可能因客户的行为而受到威胁。由于斯蒂芬的工作不会受到影响，所以这不是人员风险。

常见风险分析

现在，让我们听听一些可能影响产品成功的常见且反复出现的风险。

特别是在早期阶段的初创公司和一些IT项目中，很多风险与资金有关。人们严重低估了所需的努力和技能，因此常常资金不足。当资金紧张时，它会影响到一切：人们的士气下降，人们担心自己的工作等等。因此，资金问题可能是一个真正的杀手。许多伟大的想法和项目因为成本估算不当而夭折。

另一个问题是人员，尤其是在早期初创公司或公司里以前从未做过的早期项目中。有时你不得不与现有的人员合作，如果你没有从A点到B点所需的正确技能类型，最终可能会遇到很多问题，人们开始互相指责。你需要确保人员配置正确，并拥有正确的技能组合和角色。

我到处都能看到的另一个大问题是缺乏规划。敏捷方法非常适合轻量级、大量的客户互动、大量的测试和很多好想法，但人们会产生一种感觉，认为我们要快速行动，不想做计划。事实并非如此，你不需要一个僵化的计划，但你需要一个能给你灵活性以保持敏捷的适当计划。但我看到的大多数情况是缺乏规划。技术团队会认为，如果他们遵循特定的流程或使用特定的软件解决方案，一切就会顺利进行，但事实并非如此。因此，缺乏规划绝对是项目杀手。在我看到的100%失败的项目中，它们都有一个共同点：规划不善。而那些成功的项目，它们都有计划。计划可能会经常变化，但当你思考问题、将其写下来并进行沟通时，确实有助于让人们达成一致并朝着正确的方向前进。

风险规划

为风险做规划始于评估它们对项目可能产生影响的程度。在下一课中，我将介绍一种你可以用来做这件事的方法。我们下节课见。

总结

本节课中，我们一起学习了软件项目中常见的失败原因，即项目风险。我们探讨了范围风险、技术风险、客户与利益相关者风险以及人员风险等不同类型，并通过一个练习加深了对风险分类的理解。最后，我们了解到缺乏规划是项目失败的一个普遍且关键的因素，强调了即使在敏捷环境中，适当的规划也至关重要。

026：风险评估概率和影响 📊

在本节课中，我们将要学习如何评估项目中风险的发生概率和影响程度。我们将使用一个名为“影响与概率矩阵”的工具来对风险进行优先级排序，并了解如何将类似的概念应用于产品功能的优先级排序。

在关于反模式以及项目失败原因的课程中，我介绍了很多软件项目中常见的共性问题。

其中一些问题非常普遍，以至于行业将其称为“反模式”，即对项目成功产生负面影响的模式。如果你想了解更多，可以在课程资源中找到。那里不仅包含我提到的反模式，还有更多内容。

本节课，我将讨论如何评估项目中风险的发生概率和影响程度。反模式代表了常见的风险，但从现在开始，让我们将风险视为任何可能导致项目失败的因素。这些可能是反模式，也可能包括项目特有的、并非普遍存在的风险。

风险代表了你的产品可能失败的潜在方式。显然，我们希望有能力采取措施来最小化风险。了解潜在的项目风险是第一步，为它们制定计划是下一步。

假设你已经有了一个潜在项目风险的列表。你如何决定如何处理它们？一种方法是成为一个积极主动的领导者，采取行动完全避免这种情况。当然，你无法为项目中的每一个风险都这样做。你将花费更多时间采取预防性行动，而不是在产品上取得实际进展。

因此，我们需要某种方法来对风险进行优先级排序。这就是“影响与概率矩阵”发挥作用的地方。

影响与概率矩阵是一个二维图表，用于表示风险对项目的影响程度。它显示了你需要集中精力预防的事项。

一个影响与概率矩阵看起来像这样：Y轴代表影响，从低到高；X轴代表概率，从低到高。

要使用影响与概率矩阵，只需为项目中相关的每个风险在两条轴上分配一个值。例如，假设存在“项目资金耗尽”的风险。这个风险对你的项目影响巨大，因为它将导致项目被迫关闭。因此，在影响维度上给它分配一个“高”值。假设你正在一个资金有限的初创公司工作，这个风险的概率可能是“中”。有了这两个值，你就可以将“项目资金耗尽”放在矩阵中上方的单元格里。

以下是项目风险吗？你可以选择多个答案。
A. 小行星摧毁地球。
B. 开发人员离职。
C. 技术故障。
D. 客户失去兴趣。

实际上，所有这些都是潜在的项目风险。它们都代表了项目可能失败的方式，尽管有些比其他更戏剧化。

以“小行星摧毁地球”这个风险为例。显然，这将是一个高影响事件。但考虑到我们近期不太可能看到任何小行星摧毁地球，其概率很低。因此，“小行星摧毁地球”应放在你矩阵的右上角。

再看一个例子：你所在的团队中有一位名叫Gary的开发人员。Gary以其开发电脑在项目中途死机而闻名。这是一个项目风险。“Gary的电脑死机”应该放在矩阵的哪个位置？如果团队还有其他电脑可供Gary使用，这可能影响Gary本人，但项目可能不会有大问题。因此，我们将其影响分配为“低”。然而，鉴于他的电脑死机几乎被认为是不可避免的，其概率是“高”。因此，“Gary的电脑死机”应放在矩阵的左下角。

让我们再看一下那个矩阵。注意矩阵每个单元格中的数字。这些数字代表了根据每个风险在矩阵上的值所确定的风险类别。

“项目资金耗尽”将获得值“2”，因为它是高影响、中概率。
“小行星摧毁地球”将获得值“3”，因为它是高影响、低概率。
“Gary的电脑死机”将获得值“3”，因为它是低影响、高概率。

很好。现在，你有了一个风险列表，并且它们都被分配了风险类别。你该如何处理这些信息呢？

这个值实际上代表了风险对你项目的潜在影响程度。它告诉你应该对该风险采取何种级别的行动（如果需要采取任何行动的话）。

类别1（高影响、高概率） 的风险应尽可能彻底地处理。由于影响大且很可能发生，最佳行动方针是尽可能采取措施减轻该风险。任何你现在可以采取的行动，都应该去做。如果该行动能减轻类别1风险的影响，就值得做。
类别2 的风险是你应该关注但不需要立即采取行动的。应该有一个详尽的风险计划，即当风险发生时如何应对的策略。
类别3 的风险对你的项目不太构成威胁，但你仍然应该留意。因此，你应该监控这些风险，但不必花费太多时间思考如果它们发生会怎样。

实际上，这种排名系统还有其他变体。我们刚刚使用的例子只将“1”分配给高影响、高概率的风险。更保守的项目可能会将“1”分配给高影响高概率、高影响中概率或中影响高概率的风险。然后将“2”分配给这些单元格边缘的风险，将“3”分配给其他所有风险。这样做只是将更高的重要性分配给某些风险。实际上，这意味着你降低了项目的风险承受能力，如果你参与的是一个关键任务项目，你可能会对此感兴趣。

请注意，为风险采取行动会为你的项目计划增加活动。反过来，这会影响你项目的截止日期和成本。

假设你是一名软件产品经理，收到警报称一场失控的野火正威胁着你团队关键任务数据所在的工业园。火灾尚未蔓延到工业园，但当局告知该地区的工人要做好随时疏散的准备。如果你将此风险放在影响概率矩阵上，以下哪个类别最能描述其等级？
A. 3
B. 2
C. 1

答案是C，类别1。这场自然灾害有可能通过中断电力、网络甚至数据中心本身来影响数据服务。由于影响可能很高且概率很高，此风险属于类别1。

这种将风险置于矩阵的概念也可以应用于你项目的功能。为此，请为你的功能使用风险价值矩阵。

风险价值矩阵很像影响与概率矩阵。不同之处在于，Y轴代表的是“风险”，而不是“影响”；X轴代表的是“功能对项目的价值”。就像处理项目风险一样，你可以将功能放入此矩阵，这可以帮助你决定如何对这些功能进行优先级排序。

假设你正在构建一个使用面向用户的应用程序和数据库来存储数据的产品。你的开发团队在创建此类应用程序方面经验丰富，但在创建数据库方面经验很少。一般来说，涉及应用程序的功能将被置于相对低风险、高价值的位置。而涉及数据库的功能将是高价值且高风险。

你如何基于此分配优先级？当我第一次看到这个矩阵时，我自动假设你应该从创建高价值、低风险的功能开始。我这样想是因为它们可以快速为项目交付价值。然而，我很快了解到，首先构建高风险、高价值的功能要好得多。这是因为通过首先承担较大的风险，你将有效地解决对项目成功构成最大威胁的产品问题。如果你遇到导致项目延迟或取消的问题，最好在项目早期而不是后期发现它们。

你可以使用与风险排名相同的原则来对功能进行排名并确定其开发优先级。

当使用风险价值矩阵确定功能优先级时，你应该首先完成哪些功能？
A. 高风险、低价值
B. 低风险、高价值
C. 低风险、低价值
D. 高价值、高风险

正确答案是D。你应该专注于首先开发高价值、高风险的功能。这里的理念是“快速失败”——如果出现问题，最好尽早发现。

本节课中我们一起学习了风险评估。我们了解了如何使用影响与概率矩阵来识别和优先处理项目风险，以及如何将类似的风险价值矩阵应用于功能优先级排序，特别是强调应优先处理高价值、高风险的功能以尽早发现重大问题。

在下一节课中，我将向你展示如何创建我在本节课中提到的风险计划。

027：应急与缓解

概述

在本节课中，我们将学习如何制定风险计划。上一节我们介绍了如何使用影响与可能性矩阵来评估项目风险，本节中我们来看看如何将这些评估转化为具体的行动计划。

什么是风险计划？

风险计划，或称风险管理计划，包含一系列潜在的项目风险、其相关的影响与可能性，以及当风险出现时计划采取的应对措施。

你可以将风险管理计划写成一个简单的表格，如下所示：

以下是风险计划表格的构成要素：

风险：我们整个模块讨论的对象，即可能导致项目失败的事件。
等级/类别：根据影响与可能性矩阵为风险分配的优先级。
指标：用于识别可能面临此风险的迹象描述。
应对措施：当通过指标发现项目面临风险时应采取的行动。

风险类别与应对策略

当我讨论影响与可能性矩阵时，我定义了三个风险类别，分别称为1、2和3类。

第1类风险：应尽快处理的风险，对项目构成最大威胁。这些风险被纳入项目计划，相关的应对措施通常是立即执行。
第2类风险：严重性较低，但仍需列入风险计划。这些风险对项目构成中等威胁，因此任何应对措施都应认真规划，但程度不及第1类风险。
第3类风险：基本无需规划，因为它们对项目的威胁很低。

风险计划实例分析

让我们通过几个例子来看看风险如何具体呈现。

实例一：版权获取风险

在我们的音乐播放器应用中，客户需要为其提供给用户的内容获取版权许可。你将此风险放入矩阵评估，确定客户无法获取版权的风险属于第2类风险（影响高，但可能性中等）。

以下是针对此风险的计划条目：

风险：客户无法为应用内容获取艺术家版权。
等级：2
指标：客户向你传达此问题，或表现出对应用失去兴趣的迹象。
应对措施：确保开发团队以增量方式交付产品，让客户看到进展；妥善结算项目财务，并确保已完成的工作能得到补偿。有时，为了项目成功，产品经理帮助客户获取版权也可能是审慎之举。

实例二：未经验证的算法风险

你的开发团队决定使用一种特殊的压缩算法来提高应用内容的加载速度。然而，该算法是开发人员前一晚在酒店房间构思的，基本上未经测试，细节不明，团队不确定其是否有效。你评估此风险为第1类风险（影响高，可能性高）。

以下是针对此风险的计划条目：

风险：团队无法实现该压缩算法。
等级：1
指标：团队在一周的开发中毫无进展；开发团队直接告知算法工作无法推进。
应对措施：告知客户正在尝试的算法可能不成熟且无法工作，优先管理客户期望；制定备用计划，例如与开发团队约定，若开发人员开始工作一周后仍无进展，则改用标准压缩算法；务必告知客户此备用计划。

处理未知风险

如果你为项目中所有评估为第1类或第2类的风险都制定了上述计划，项目成功的可能性将大大增加。然而，那些未知的风险呢？遗憾的是，你无法为未知之事做计划。项目中总会出现无法预见的风险。有时项目的成功取决于你如何即时应对这些风险。这并非说你不应规划项目，而是你无法为一切做好计划。处理未知风险是产品经理应培养的一项技能，其重要性不亚于处理已知风险。

行业实践

为了缓解项目风险，我们会考虑几个不同的因素。我们会创建所谓的“头脑风暴研讨会”，来识别和集思广益与特定项目及不同技术相关的风险。我们会明确谁愿意负责不同的风险，制定风险应对策略，包括规避策略、缓解策略、转移风险或直接接受风险。我们还会更好地理解每个风险的影响和概率，以便评估需要何种应对措施，确定由谁负责这些风险以及时间线。

总结

本节课中，我们一起学习了如何制定风险计划。一个项目风险计划是基于指标和风险类别，对风险及可采取行动的集合。通过预先识别、评估和规划应对措施，你可以更有效地驾驭项目中的不确定性，提高成功的几率。

课程回顾

在本课程中，我们涵盖了大量提高项目成功几率的不同技巧：

第一模块：Morgan介绍了规划的概念，描述了工作分解结构、不确定性空间，并定义了估算、目标和承诺等术语。
第二模块：我描述了如何在发布级别规划项目，以及使用时间盒来协调小块时间内的项目开发。接着介绍了甘特图作为可视化项目进度和依赖关系的手段，并逐步讲解了如何创建发布计划。
第三模块：Morgan深入到迭代级别，描述了如何估算任务时间，展示了任务依赖关系，并举例说明了规划项目时使用的两种图表：关键路径法图和PERT图。该模块以展示如何创建迭代计划结束。
第四模块（本模块）：我通过描述常见的项目风险，向你展示了项目中可能出现的问题。然后我们使用影响与可能性矩阵评估并确定了这些风险的优先级，并通过使用风险计划来规划如何应对风险。

你可以将这些技巧中的任何一种应用到你的下一个软件项目中。没有什么能阻止你将它们也应用到当前的项目中。更重要的是，这些方法不仅限于软件领域。规划方法已被广泛应用于从家庭琐事管理到建造宇宙飞船的各个方面。

如果你将这些技巧应用到你的项目中，请回来分享你的经验。我将为此开设一个讨论论坛。

这是我们专项课程的第四门课。你的下一步是学习我们的第五门课：《软件改进的评审与度量》。在那里，我们将向你展示如何监控项目，并确保你始终走在成功的道路上。我们课堂上见。

028：专项课程预览

在本节概述中，我们将预览艾伯塔大学软件产品管理专项课程的核心内容与目标。该专项课程旨在系统性地教授如何将软件产品从概念构思引导至最终交付。

我是乔纳森·舍费尔，一名计算机科学家，现任艾伯塔大学理学院院长。我很荣幸向您介绍由我校计算机科学系开发的软件产品管理专项课程。

这套系列课程将教会您如何成功引导一个软件产品从初始概念发展到最终交付。艾伯塔大学被公认为世界领先的公立研究型与教学密集型大学之一。作为加拿大顶尖大学之一，我校在科学、人文、创意艺术、商业、工程和健康科学等领域均以卓越著称。我们的热情在于为学生成功提供起点，目标是激励、转变和提升我们的学生，并帮助他们实现目标。

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

我们对软件产品管理流程的实践理解，将为您提供直面挑战所需的一切。我们将教您如何理解并优化客户的软件需求，以及如何将这些需求传达给开发团队。您将学习从项目监控到确保项目符合客户需求、遵循项目计划并达到预期质量水平的技术。

您将有机会加入一个软件产品管理社区，在那里您可以分享经验并从他人的见解中学习。最后的课程是一个为期六周的顶点项目，它将为您提供在真实模拟环境中应用这些管理技术的机会。成功完成顶点项目后，您将获得认证，并为在软件产品管理职业生涯中脱颖而出做好准备。

上一节我们预览了专项课程的整体框架，现在进入结尾部分。我很高兴您对我们的专项课程感兴趣。我们已经尽力使这成为一次有价值的教育体验。现在轮到您了，祝您好运。

在本节课中，我们一起学习了艾伯塔大学软件产品管理专项课程的概览，了解了其教学目标、涵盖的核心技能（如需求沟通与项目监控）以及最终顶点项目的实践价值。

029：1_05_introduction-to-agile-planning-for-software-products.en_subtitled - GPT中英字幕课程资源 - BV14w411a7jH

课程概述 📋

大家好，我是 Ken Wang。欢迎来到《面向软件产品的敏捷规划》课程。这是软件产品管理专项课程的第四门课。本课程旨在您完成《软件流程与敏捷实践》以及《客户需求与软件需求》两门课程后学习。前两门课程构成了专项课程结构的“两条腿”，而本课程将作为“躯干”，放置于“腿”之上，进一步完善整个知识体系。

在本课程中，我们将学习如何运用敏捷规划技术，以确保软件产品项目得到妥善管理。核心在于有效组织工作，同时适应变化。通过本课程分享的技术，我们可以确保软件流程和敏捷实践得以正确执行，最终实现“正确的产品”。

课程内容预览 🧭

我之前提到过，打造更好的软件涉及三个目标：正确的产品、正确地完成以及正确地管理。本课程重点在于敏捷规划技术，以确保软件产品项目得到妥善管理。

本课程融合了前两门课程的许多基础知识。例如，您将识别出软件需求中的用户故事概念、Scrum方法论中的冲刺，以及流程中的时间盒。本课程将在此基础上进行构建。

无论您是直接管理团队还是通过他人管理，您都会认识到软件项目涉及的三种关键规划类型：发布规划、迭代规划和风险规划。我们将在本课程的第二、三、四模块中分别介绍这些内容。

模块详解 📚

以下是本课程各模块的核心内容介绍。

模块一：工作分解与估算基础

在第一个模块中，Morgan Patzelt 将阐述项目需要解决的各种不确定性。她还将展示如何将工作分解为可管理的部分。此外，她会解释估算、目标和承诺之间的区别。

模块二：发布规划与故事点估算

在第二个模块中，Blaine Price 将解释如何使用故事点来估算需求的规模。他还会说明估算如何与速率相关联，以此作为衡量开发团队生产力的方式。他将展示如何以时间盒作为规划工作的基础，进而可以制作成燃尽图。这最终导向构建一个发布计划，以规划在即将到来的冲刺中交付哪些用户故事。

模块三：迭代规划与任务管理

在第三个模块中，Morgan Patzelt 将回归，描述如何估算任务时间并确定任务依赖关系。她将展示如何使用关键路径法图和甘特图在任务级别规划工作。这导向构建一个迭代计划，以规划在下一个冲刺中需要完成的任务。

模块四：风险识别与管理

在第四个模块中，Brad 将详细说明可能导致项目失败的问题或风险。他将描述一系列反模式，即对项目及其人员产生负面后果的情况。您将学习如何评估风险并确定需要采取何种级别的行动。这导向构建一个风险计划，以规划在风险发生时该如何应对。

课程总结 🎯

在本课程中，我们一起学习了面向软件产品的敏捷规划核心技术与方法。课程涵盖了从工作分解、故事点估算，到发布规划、迭代规划，再到风险管理的完整流程。

通过本课程的学习，您将获得一套有效的技术组合，帮助您规划下一个项目，并创造出管理得当的优秀软件产品。

030：课程介绍

在本节课中，我们将要学习面向软件产品的敏捷规划策略与技术。这些技术遵循敏捷宣言的原则，将使您的软件项目更能适应变化。

软件项目规划的关键在于将工作量分解为更小、更易管理的任务。本课程将从理解如何描述和组织细粒度任务开始，接着会重点讲解如何分解大型活动。您还将学习如何创建时间和工作量估算，以便准确安排所需工作。

软件项目有多种排期方式。我们将涵盖如何在发布级别和迭代级别规划项目。发布是指将产品交付至可上市状态。一个发布通常由多个迭代组成。您使用发布计划来整体规划项目，包括决定每个迭代要完成哪些需求。您使用迭代计划来规划特定迭代中要完成的任务。

您将学习诸如甘特图和发布计划等发布规划技术，以及诸如PERT图、CPM图和迭代计划等迭代规划技术。我们将在课程中详细讲解所有这些技术。

您还将学习风险规划。正如在介绍性课程中提到的，风险规划是软件规划的重要组成部分。软件开发过程中可能出现许多风险，因此您需要为这些风险做好准备，以避免对产品创建和支持产生负面影响。

让我们回顾一下之前课程的内容。

在关于软件过程和敏捷实践的课程中，我们讨论了“任务”这个术语。任务的定义是什么？

A. 一个人承担或扮演的职责。
B. 项目中要完成的一个小的、可管理的步骤。
C. 软件过程产生的输出。
D. 衡量进度的内部检查点。

在关于软件过程和敏捷实践的课程中，我们将任务定义为项目中要完成的一个小的、可管理的步骤。因此，B是正确答案。答案A定义了角色，答案C定义了工作产品，答案D定义了里程碑。这些都是我们即将更详细讨论的术语。

我们将从检查上一个测验中看到的术语开始，并介绍本课程将使用的一些新术语。

让我们从“任务”这个术语开始。

任务被定义为项目中要完成的一个小的、可管理的步骤。任务是项目的核心。项目中发生的所有事情都可以分解为任务。我们将在本模块后面讨论如何将项目分解为任务。在规划中，您将频繁使用任务来为项目创建估算和进度表。

接下来，让我们看看“角色”这个术语。我们在关于软件过程和敏捷实践的课程中定义了“角色”。

角色是一个人承担或扮演的职责。角色的例子包括程序员、测试员、设计师、客户和产品经理。角色执行任务，例如，程序员可能承担为某个功能编写源代码的任务。

“工作产品”这个术语在关于软件过程和敏捷实践的课程中已经介绍过。

工作产品被定义为任务或过程产生的输出。

任务不仅产生工作产品作为输出，它们也使用工作产品。一个任务中产生的输出工作产品，可以作为后续任务的输入工作产品被使用。

让我们看一个例子。假设程序员角色承担了为特定功能编写测试的任务。该任务产生该功能的测试工作产品。这些测试是执行测试任务的输入工作产品，因为执行测试这个任务要求事先编写好测试。

正如我们在讨论工作产品时看到的，执行测试的任务依赖于编写测试的任务，因为一个任务的输出工作产品是另一个任务的输入工作产品。在规划时，您需要牢记这些依赖关系，以便以逻辑顺序安排任务。

您正在与一个开发团队合作，创建一个允许学生提问作业问题并从在线导师那里获得帮助的网站。学生也会被引导至教程和资源链接。您正在安排任务，遇到了“为与导师的在线聊天编写源代码”这个任务。

以下哪个任务必须安排在“为与导师的在线聊天编写源代码”这个任务之前？

A. 上传供导师参考的教程视频。
B. 对与导师的在线聊天进行验收测试。
C. 设计在线聊天工具。
D. 雇佣导师进行在线聊天工作。

上传视频是一个可以在开发后期才实施的任务。雇佣导师将取决于在线聊天功能是否正常工作，因此不会安排在此任务之前。所以，答案A和D不正确。

答案B很接近，但也不正确。进行验收测试依赖于源代码的编写。为此功能编写源代码的任务必须安排在验收测试任务之前。功能需要先设计好，程序员才能开始编程。因此，答案C正确。设计在线聊天的任务必须安排在为在线聊天编写源代码的任务之前。

本节课中，我们一起学习了敏捷规划的基本概念，包括任务、角色、工作产品和依赖关系的定义。理解这些基础术语是进行有效项目规划的第一步。在接下来的章节中，我们将深入探讨如何将这些概念应用于实际的发布和迭代规划中。

031：3_02_4-1-1a-规划简介

在本节课中，我们将学习规划中的几个核心概念：进度表和里程碑。我们将了解它们的定义、区别以及在实际项目中的应用。

进度表与里程碑

上一节我们介绍了规划的基础。本节中，我们来看看规划的两个关键组成部分：进度表和里程碑。

进度表是将任务映射到时间线上的安排。任务是一个项目的基本要素。正如之前讨论过的，任务之间会基于其工作成果产生依赖关系。识别任务的依赖关系是创建进度表的重要步骤。

你需要以这样的方式将任务映射到时间线：作为输入所需的工作成果，必须在被需要之前创建完成。同时，你还需要确保高优先级的需求被优先完成。你需要规划每个迭代周期内要完成的内容。这听起来很复杂，但本课程将向你展示有效安排这些内容的技术。

接下来，我们谈谈里程碑。里程碑是衡量进展的内部检查点。它们不是基于时间的，而是基于事件或行动的。里程碑可用于衡量项目的进展。然而，它们在线性流程和早期迭代流程中更为常见。

你在《软件流程与敏捷实践》课程中学习过这些线性和早期迭代流程。在之前的课程中研究敏捷宣言时，我们了解到，在敏捷开发中，通常不设置里程碑。进展是通过可工作的软件来衡量的，而不是通过事件。所有的发布和迭代都是基于时间的，因此它们不符合里程碑的定义。

里程碑示例分析

为了加深理解，我们通过一个例子来分析什么是真正的里程碑。

Sierra正在开发一个允许用户监控和跟踪月度支出的项目。她和她的开发团队决定基于里程碑来衡量进展。

以下是几个选项，哪个是里程碑的示例？
A. 一个为期两周的冲刺结束。
B. 项目启动一周年纪念日。
C. 产品的截止日期。
D. 需求已编写并完成评审。

里程碑不是基于时间的。因此，一个为期两周的冲刺结束不是里程碑，因为它是用两周时间来衡量的。同样，一周年纪念日也是基于时间的。所以，答案A和B不正确。

截止日期可能被视为一个里程碑，但它仍然是基于时间的，因此答案C也不正确。如果Sierra想将其表述为里程碑，更好的措辞是“最终产品交付”。然而，最终产品交付的日期并不总是产品的截止日期。

答案D不是基于时间，而是基于行动的。当所有需求都已编写并完成评审时，你就知道这个里程碑已经达成。这可以是一个项目的主要里程碑，因此答案D是正确答案。

任务：从需求到实现

正如本节课前面所说，项目中发生的所有事情都可以分解为任务。它们是规划的一个重要方面，也是之前课程的重要组成部分。

在《客户需求与软件需求》课程中，你学习了如何创建需求。一旦你创建并确定了软件需求的优先级，就需要将它们分解为要完成的开发人员任务。让我们看一个例子。

假设我们正在创建一个允许用户浏览电子书（就像一个虚拟图书馆）的应用程序。我们的一个需求是：“作为一名读者，我希望能够基于关键词搜索书籍，以便找到包含我正在寻找的文本内容的书籍。”

我们有了一个需求，但你的开发团队如何将其转化为产品的一部分呢？以下是由此需求可能产生的一些开发人员任务示例：

以下是可能由此需求产生的开发人员任务示例：

设计关键词搜索工具。
获取或开发关键词搜索算法。
编写关键词搜索工具的源代码。
测试关键词搜索工具。

开发人员任务可以更具体地涉及技术，而需求则应独立于技术。通过开发人员任务，开发团队正在为问题提出解决方案。这些开发人员任务通常使用迭代计划来安排。你将在本课程后续部分学习如何做到这一点。

任务在流程与敏捷中的作用

在《软件流程与敏捷实践》课程中，我们讨论了任务如何构成活动，活动又如何构成阶段。每个阶段都有要完成的特定任务。因此，任务是创建流程的基础。任务在敏捷实践中也扮演着重要角色。

敏捷实践提供了组织任务并确保其有效完成的方法。使用迭代计划是Scrum方法论中常见的一种敏捷实践。如前所述，迭代计划是一种安排任务的技术。看板则是一种通过一系列步骤可视化跟踪任务进展的方式。

总结与预告

现在，你已经有了一个良好的基础，可以开始学习更多关于规划的知识。在本节课中，我们一起学习了：

进度表的定义：将任务映射到时间线的安排。
里程碑的定义：基于事件或行动的、用于衡量进展的内部检查点。
如何从需求分解出具体的开发人员任务。
任务在传统流程和敏捷实践中的核心作用。

在下一课中，你将学习不确定性空间以及如何在项目中导航。我们下节课见。😊

032：不确定性空间

概述

在本节课中，我们将要学习一个重要的概念：不确定性空间。这个工具能帮助我们理解在软件项目开发过程中，关于“做什么”和“怎么做”的不确定性是如何变化的，并指导我们更有效地规划项目路径。

不确定性空间的概念

启动一个软件项目可能令人望而生畏。你从哪里开始？到哪里结束？你的团队将如何开发？又将开发什么？你如何驾驭所有这些不确定性？

项目管理者研究员亚历山大·莱弗指出，需要同时处理两种类型的不确定性。Scrum方法论的贡献者之一迈克·科恩用一个基于不确定性的图表描绘了这个问题。

这个图表用于展示产品从概念、经过开发、到可运行状态的过程中，不确定性的水平。对于每个产品，你都需要弄清楚你在创造什么以及你将如何开发它。

理解坐标轴

项目开始时，这两者的不确定性通常都很高。理想情况下，你希望确切地知道你在生产什么，以及你的团队将如何实现它。但现实中存在很多不确定性，需求会变化，方法也会变化。

这个不确定性空间图沿X轴衡量方法不确定性。

方法不确定性指的是你项目的“如何”，即“你将如何开发这个产品？”。
你的项目应该从高方法不确定性走向低方法不确定性。

该图沿Y轴衡量目标不确定性。

目标不确定性指的是你项目的“什么”，即“你实际上在开发什么？”。
同样，这种不确定性也应该从高走向低。

分析图中的位置

请看不确定性空间图中的这些点：

点A：高方法不确定性，高目标不确定性。
点B：高方法不确定性，低目标不确定性。
点C：低方法不确定性，高目标不确定性。
点D：低方法不确定性，低目标不确定性。

问题：在项目结束时，你希望你的产品处于图中的哪个位置？

答案：希望在项目结束时，你拥有低方法不确定性（团队知道如何创建或已经创建了产品），同时拥有低目标不确定性（你知道你在创造什么）。因此，答案D是正确的。无论目标还是方法存在高不确定性，都表明产品仍有待解决的未决问题。

在不确定性空间中导航

接下来，我们看看如何利用这个图表来导航项目。

第一种路径：先确定“做什么”，再确定“怎么做”
这种方法要求你在规划如何完成需求之前，预先详细确定所有需求。这类似于遵循瀑布流程。如图所示，在方法不确定性开始显著变化之前，目标不确定性的水平已经很低。

这种导航方式不允许需求轻易变更，因为它们都是预先确定的，因此不够敏捷。

第二种路径：先确定“怎么做”，再边做边确定“做什么”
这种开发方式属于临时性开发，涉及很少的规划。基本上，开发团队会边摸索实现方案，边拼凑产品。

这不是开发软件的合理方式，可能导致工作浪费。

最佳路径：在中间地带导航
让我们用另一种方式来可视化这个过程。想象在你家和学校之间有一个足球场，家和学校在对角。

如果你从学校走回家，很可能不会绕着场地走。直接斜穿场地距离要短得多。同样，斜向穿过不确定性空间所需的工作量也少得多。

然而，开发过程通常不是一条直线。

常见的情况是，在开始设计如何完成需求之前，你会与客户和开发团队一起定义大部分需求。一旦确立了需求，你和开发团队将开始规划解决方案。此时，项目的目标和手段不确定性都降低了，这是开始开发的好时机。

随后，需求可能会改变或增加，解决方案也会相应改变。你的开发团队将实施这些更改，并朝着目标和手段都具备低不确定性的目标努力。

总结

无论你在不确定性空间中采取何种路径，你都将完成任务。在本节课中，我们一起学习了不确定性空间图，它帮助我们可视化项目在“目标”（做什么）和“方法”（怎么做）上的不确定性变化。理解这个空间有助于我们选择更高效、更敏捷的项目规划路径，避免在高度不确定性的区域停滞不前。

在下一课中，你将学习如何将工作分解为任务。

033：工作分解结构 (WBS) 🗂️

概述

在本节课程中，我们将学习一个关键的规划工具——工作分解结构。我们将了解如何将一个庞大、复杂的软件产品项目分解为更小、更易于管理的组成部分，并探讨这一过程在项目管理中的实际应用。

将整个软件产品视为一个整体来创建，这个过程可能会令人望而生畏。
你需要构思许多功能，设计各个方面，编写大量代码，并进行测试，才能得到一个功能完备的软件产品。
在此期间，你可能还需要安排诸如市场营销、技术支持和运营等事宜。
正如你已经知道的，你不能简单地告诉开发团队去开发一个应用程序。
幕后需要进行大量的规划工作。
无论开发团队是否意识到，他们都会将项目分解成更小、更易管理的部分。
将项目分解成小而易于管理的部分，是创建和规划软件产品的关键步骤。

在关于软件过程和敏捷实践的课程中，我们讨论了过程的结构，以及一个过程如何被分解为阶段，阶段再分解为活动，活动可以进一步分解为任务。
当你将一个大型软件过程分解为可管理的任务时，它就不再显得那么难以应付了，只需一次处理一个任务即可。

类似于将过程分解为任务的方式，你也可以将一个大型项目（例如创建一个应用程序）分解为小而易于管理的任务。
将软件产品需要完成的工作分解为任务工作产品，对规划非常有帮助。
我们称之为工作分解结构。
创建工作分解结构在项目管理中非常普遍。
工作分解结构将一个大型工作产品分解为更小、更易管理的工作产品，形成一个层次结构。
创建工作分解结构的方法是审视大型工作产品。
通常，这将是你的团队将要交付的整体产品。
然后，将这个工作产品分解为更小的工作产品。

这些较小的工作产品会被反复分解，直到每一个都足够小且足够清晰，可以分配给一个人。
需要平衡这些工作产品应该分解到多小。

如果它们太小，会导致微观管理。

根据经验，你应该将工作产品分解到可以合理地让一个人来创建每个工作产品的程度。
例如，假设你正在分解建造房屋的项目。

具体来说，是房屋内电气系统布线的任务。
你可以将每个任务分解得越来越小，直到达到这样的级别：第一，剥掉电线末端四分之一英寸的绝缘层；第二，将电线插入插座。

显然，这是微观管理。一旦达到与角色相关的专业水平，就不再需要任务分解了。
因此，在这个例子中，总承包商可以概述安装电气系统的任务，但不需要将事情分解到超出电工理应知道如何做的范围。

维多利亚是一名正在开发一款动画视频游戏的产品经理。
她正在制定她的工作分解结构，但不确定应该将工作产品分解到何种程度。
这款视频游戏旨在拥有出色的背景视觉效果和图形，包括一个描绘繁星满天的夜景背景。
以下哪一项会是合适大小的工作产品？A，动画视频游戏；B，所有绘图；C，所有背景；D，夜景背景；或 E，一颗星星。

创建整个动画视频游戏的工作产品，对于一个人来说任务量太大，因此答案A不是合适的大小。
创建动画视频游戏所有绘图的工作产品，同样是一个太大的任务，因此答案B不正确。
创建所有背景现在是一个更合适大小的工作产品，但这仍然可以分解为更合理的规模，所以让我们排除答案C。
答案D是一个相当合适大小的工作产品。你可以合理地分配创建夜景背景的任务给一个人。
分配一个人单独绘制一颗星星，这个任务太小，你的工作分解结构会变得非常庞大。因此，答案D是正确答案。

学习如何将产品分解为工作分解结构的最简单方法是看一个例子，让我们一起看一个。
在我们的例子中，我们将分解构建一个新闻应用程序的任务。
这个应用程序将为一家全球新闻公司展示新闻。
在应用程序中，用户可以浏览头条新闻、阅读文章，并查看不同的版块，如财经或娱乐。
该应用程序还具有实时嵌入式小部件，用户可以看到关于天气和股票等变化信息的实时更新。

对于我们的工作分解结构，我们的整体工作产品是新闻应用程序。
构建新闻应用程序的任务可以分解为四个主要的工作产品类别。
它们是：内容、UI图形、编程和文档。
现在，每个工作产品类别都有自己的一组工作产品。
例如，在内容类别中，我们需要创建头条新闻版块、新闻报道和广告。
在UI图形类别中，我们需要创建应用程序中使用的徽标和按钮。
在编程类别中，我们需要编程链接，将用户带到内容中的特定页面。
此外，我们还需要编程应用程序的布局，使其能在多种设备上正常工作。
我们还需要编程实时嵌入式小部件。
在文档类别中，我们需要创建用户手册或帮助页面，以及内部文档。

这些工作产品中的每一个又有关联的工作产品。让我们更详细地看看编程工作产品，以便更好地理解这一点。
编程工作产品被分解为三个关联的工作产品：链接、布局和实时嵌入式小部件。
由于这些都是编程项目，我们需要为每个工作产品创建源代码；因此，源代码是每个工作产品的一个工作产品。
事件处理程序的工作产品将有关联的工作产品：单元测试和验收测试。
回顾之前的课程，单元测试用于测试源代码的低级功能，并且应该在编写源代码之前编写。
验收测试验证整个应用程序。因此，在这种情况下，单元测试将确定链接是否正常工作。
验收测试将测试界面，以确保没有链接损坏，并且所有链接都能将读者带到预期的位置。
要编程布局，你还需要先设计它。因此，布局设计将是一个关联的工作产品。
你还需要验收测试来确保布局在多种设备上兼容。
对于实时嵌入式小部件工作产品，我们还需要测试其功能。因此，单元测试和验收测试也将是关联的工作产品。

你可以使用工作分解结构中的工作产品来创建供开发人员完成的关联任务。
以下哪一项会是我们刚才看到的例子中的关联任务？
A，为实时嵌入式小部件编写单元测试。B，创建一个新闻应用程序。C，为用户界面布局创建设计。D，向应用程序添加内容。和/或 E，为读者聊天室创建源代码。
我们希望任务是基于层次结构中最小的工件来创建的。
因此，“创建一个新闻应用程序”和“向应用程序添加内容”作为任务来说太大了，所以答案B和D不正确。
答案A和C是基于层次结构中最小的工件，因为我们在分解的最后一级定义了单元测试和布局设计。因此，答案A和C是正确的。
答案E是针对一个未在定义范围内的功能的任务。目前它不会是这个产品的任务，所以答案E不正确。

正如你所看到的，我们可以通过查看项目的工作产品来将项目分解为任务。
这个例子引导你浏览了一个以树状图描绘的产品工作分解结构。
它基本上将设计和实现阶段的工作分解为任务，由产品所需的各个部分指导。
然而，你可以扩展这棵树，将规范阶段以及验证和确认阶段包括进来，并为这些阶段也推导出开发任务。
你还可以进一步扩展这棵树，将开发之外的其他产品管理关注点及其组成任务包括进来，例如推广应用程序、安排技术支持、设置服务器和收集分析数据。

那么，你如何在项目中使用工作分解结构呢？
工作分解结构可以通过几种不同的方式使用。
首先，你可以基于工作产品确定项目的任务。
你可以轻松地将小而易于管理的工作产品转化为小而易于管理的任务。
例如，如果工作产品是链接的单元测试，你可以创建任务“为链接编写单元测试”。
这可能是工作分解结构最常见的用途。
这是规划的一个很好的第一步，因为它为整个产品建立了细节，并且很容易创建任务来安排开发计划。

然而，你也可以使用工作分解结构来确定潜在风险。
你可以单独查看每个工作产品，并找出与该特定工作产品相关的潜在风险。
与仅仅将产品视为一个整体相比，这将为你提供一个更完整、更广泛的风险列表。
你还可以使用工作分解结构向客户展示产品。
它展示了产品的详细概览，你可以单独查看功能和工作产品。
工作分解结构对于确定开发团队完成项目需要多长时间也很有用。
估计开发人员完成较小任务所需的时间，比将项目视为一个整体并猜测需要多长时间要容易得多。

让我们听听行业专业人士的看法，看看他们如何使用工作分解结构。

我目前的角色是创建新产品，因此我会从销售的角度出发，为新产品和创新制定销售赋能策略，让现场人员了解如何销售我们的解决方案，一直贯穿到服务交付，确保我们的顾问经过充分培训，能够胜任实际交付我们所销售的任何产品。
为了做出管理决策，我们以几种不同的方式使用工作分解结构：我们用它来识别给定项目中不同活动和任务所需的资源；我们按资源识别工作量，以便了解项目的努力程度和最终工期；作为一家咨询机构，我们还了解与每个资源相关的成本，这些成本分配到人员、任务和活动上的工作量，使我们能够真正创建项目的最终预算；当然，我们还会在所有项目上添加应急储备，从而形成项目的最终总预算。

为了帮助我们的项目经理做出准确的规划估算，我们会创建所谓的自上而下和自下而上的方法。我们会使用工作分解结构，真正理解特定项目以及我们在该项目期间通常会执行的任务和活动所需的工作量或工期。这种自上而下的方法真正确定了我们不同的顾问或项目资源各自需要多少天或多少周。这种方法使我们能够从更全局、更宏观的角度理解项目的工期以及这些资源的使用情况。然后，我们采用自下而上的方法，有时甚至按分钟来审视任务和活动，这取决于项目的规模和范围。如果是较小的项目，你可能需要精确到所需努力的分钟数；如果你谈论的是一个大型项目群，项目周期可能长达数周、数月甚至数年，显然精确到分钟就太细了。我们会采用这种方法来真正理解完成某些工作包所需的关键任务和活动，然后这种自下而上的方法使我们能够实际创建我们的工作量、进度和预算。

总结

在本节课中，我们一起学习了工作分解结构。我们了解到，WBS 是一种将大型复杂项目（如软件产品）逐层分解为更小、更易管理的工作产品的有效工具。关键在于找到平衡点，将工作分解到足够小以便分配和估算，但又不过于细小导致微观管理。WBS 不仅有助于创建具体的开发任务，还能用于识别风险、向客户展示产品细节以及进行更准确的工作量和工期估算，是软件产品规划中不可或缺的一步。

在下一课中，你将学习关于项目估算、目标和承诺之间的区别。

034：估算、目标与承诺 📊

在本节课中，我们将要学习软件项目管理中三个核心但常被混淆的概念：估算、目标与承诺。理解并区分它们对于团队协作和项目成功至关重要。

估算：基于数据的合理猜测

上一节我们介绍了敏捷规划的基本框架，本节中我们来看看第一个核心概念：估算。估算是指对开发团队完成任务所需时间的猜测。它应基于过往类似任务的数据，并且通常是一个范围，因为精确到小时或天数的预测往往不准确。最重要的是，估算本身不应被协商或讨价还价。

以下是关于估算的几个关键点：

基于数据：估算应参考过往类似工作的实际耗时。
范围表示：使用时间范围（如3-9小时）比单一精确数字更现实。
不可协商：估算反映的是客观预测，不应因主观意愿而改变。

让我们看一个例子。产品经理柯克询问开发人员莉兹开发某个功能需要多久。柯克根据以往经验猜测需要3小时。莉兹考虑到一些缓冲，告诉柯克需要9小时。柯克试图“折中”为6小时。这不是正确的做法。正确的估算应基于莉兹完成类似任务的历史数据，给出一个合理的范围。

练习题：你与开发人格雷格讨论为某个功能编写测试的耗时。你猜测需要5小时。格雷格刚为类似功能写完测试，花了6小时，但他想留些余地，所以告诉你需要10小时。以下哪个是最准确的估算？
A. 5小时
B. 6小时
C. 10小时
D. 7.5小时

答案分析：最准确的估算应基于过往的相似工作，尤其是同一执行者的数据。因此，B（6小时）是正确的。A和C分别基于管理者或开发者单方面的期望，容易导致估算不准确。D的“折中”做法违背了估算不可协商的原则，因此也不正确。

目标：必须遵守的时间节点

理解了估算后，我们再来看看目标。目标是计划中需要达成的某个时间点，近乎一个理想的截止日期。与估算一样，目标一旦确定，也不应被轻易更改。常见的例子包括冲刺（Sprint）的结束日期或产品发布日期。这些目标日期通常与市场活动安排或合同条款绑定，严格遵守它们对于客户满意度和产品成功非常重要。

承诺：基于协商的可交付范围

既然估算和目标都不可协商，那么如何确定最终要开发什么呢？这就是承诺发挥作用的地方。承诺是协商发生的地方。基于团队的估算和项目的时间目标（目标），你可以协商团队承诺在给定时间内完成哪些工作。你需要不断问自己：基于团队的估算和时间限制，我如何在开发团队承诺交付的内容上做出妥协？承诺就是你同意交付的东西。

一个常见的误区是，估算被自动转换成了承诺和目标。例如，如果你被问及开发一个产品需要多久，你估算需要7个月，那么这7个月就可能变成你的承诺，而7个月后的日期就成了你的目标。这并非理想的工作方式。

用一个比喻来说明：我帮一个家庭照看孩子，问父母何时回家。他们说“大概午夜回来”，这是一个估算。如果我要求一个承诺——如果那个时间点没回来，我将收取三倍费用——他们可能会说“12点半”，给自己留出缓冲时间。在软件开发中，理想的做法是与开发团队讨论得出准确的估算，与客户商定目标日期，然后基于这两者，与团队和客户共同确定项目的承诺（即范围）。

练习题：你与客户和开发团队开会。开发团队基于以往经验估算，完成客户想要的所有功能需要约8个月。客户希望产品在假期前完成，建议了一个7个月后的发布日期。最终，你们共同商定了一个包含约5个月工作量的范围。6个月后，团队完成了所有商定的功能。哪一项是承诺？
A. 8个月
B. 7个月
C. 6个月
D. 5个月

答案分析：开发团队最初提出的8个月是基于过往工作的估算（A错）。客户建议的7个月后日期是目标（B错）。实际花费的6个月是本次项目的实际耗时，可用于未来项目的估算，但本身不是本场景下的估算、目标或承诺（C错）。最终商定的5个月工作量范围，是团队实际承诺交付的内容，因此是承诺（D正确）。

请记住，估算和目标一旦设定就不可协商。你可以协商的是项目范围内你承诺交付的内容。务必小心，不要让估算直接变成承诺或目标。将这些概念区分开，并确保你的团队和客户也这样做，这将有助于控制项目范围不至于过大，并确保你能够真正达成目标日期。

行业实践：管理大型多团队项目

了解了核心概念后，让我们看看行业中如何管理涉及多人的大型项目。项目管理者常使用一种称为“工作流”或“项目流”的技术，将相关活动或项目分组，并为每个流分配协调员或项目经理，以理解各项目的具体需求和交付物，从而在项目群层面汇总并理解相互依赖关系。

沟通与协作：我们使用多种方式向客户、经理和高管汇报项目情况，包括状态报告、会议纪要、行动日志和风险登记册。同时，我们强调非正式沟通的重要性，遵循“无意外”哲学，通过即兴的口头或电话交流，提前同步信息、风险或问题，特别是对于那些可能没时间阅读详细文档的高管层。

敏捷实践的挑战：作为一个跨北美多个分支机构的虚拟团队，我们面临的主要挑战是如何管理和协作虚拟团队，例如在成员不 physically present 的情况下如何进行 Scrum 站会。实现跨地域团队的协作与统一对我们来说是一大挑战。

产品经理的职责框架

最后，我们简要了解一下产品经理的职责。顾问托德·巴塞尔提出了一个很好的框架，将产品经理的职责分为四个领域：

市场情报：研究市场趋势、流行解决方案、 monetization 模型、客户行为及可用技术。
产品战略：关注 monetization 模型、开发环境与技术能力的匹配，最重要的是定义差异化优势——我们如何与众不同，以及如何为真实世界的用户解决问题。
产品开发：在战略明确后，开始制定路线图，规划如何构建产品及其形态。
生命周期管理：管理产品从推出到退市的整个周期。

协调不同利益相关者：软件开发中常存在“代理问题”，即不同角色（如市场、销售、开发）因考核方式不同而追求不同的目标，且开发过程资源密集、进度不如各方期望的快。协调这些不同目标和风格的工作极具挑战性，需要大量沟通以了解各方需求、寻找共同点。技巧包括进行访谈、制作亲和图、统一语言（例如，解释技术术语），并始终围绕“我们为解决用户的什么问题而存在”这一核心来聚焦讨论。

总结

本节课中我们一起学习了软件项目管理中三个关键概念：估算（基于数据的不可协商的猜测）、目标（不可协商的必须达成的时间点）以及承诺（基于估算和目标协商得出的可交付范围）。区分并正确运用这三者，是进行有效敏捷规划、控制项目范围和确保按时交付的基础。在下一个模块，布拉德利将教你如何创建准确的估算，并利用这些估算来组织项目发布的任务。

035：故事点

欢迎来到软件产品敏捷规划的下一模块。在上一模块中，摩根介绍了一些规划的核心概念，例如不确定性空间、如何分解工作，以及估算、目标和承诺之间的区别。

在本模块中，我将讨论故事点和速率，然后介绍一些将这些估算转化为具体计划的技术。

估算、目标与承诺回顾

在上一课中，摩根谈到了估算、目标和承诺。以下是简要回顾。

任务估算是对一项任务将花费多长时间的近似值。这些估算由预期从事该任务的开发人员做出。估算应基于以往的工作经验。它们是不可协商的，因为它们只是对工作耗时的预测，而非对工作何时完成的承诺。
目标是需要满足的截止日期。目标通常由开发团队外部设定。它们也是不可协商的，因为其他方可能依赖于这些日期。
承诺是开发团队承诺要实际执行的、有约束力的工作。它们明确规定了在什么时间完成什么工作。承诺基于目标截止日期和现实的估算。承诺是决定项目进度的依据，由客户和开发团队协商确定。

项目承诺受目标和估算的制约。目标是具体的日期，而估算为承诺提供了现实的依据。如果没有对工作耗时的估算，做出的承诺可能不切实际。

如何创建良好的估算？

摩根在上一课中提到，开发人员应根据过去实现类似功能所花费的时间来估算。她谈到了几种软件开发人员给出时间估算的场景，通常会留出一些缓冲时间。但为什么会这样？是什么让软件开发人员觉得他们必须在一开始就给估算留出缓冲？

通常发生的情况是，管理者误将开发人员的估算当作承诺。开发人员知道这一点。他们也清楚自己的估算可能偏差很大。为了保护自己免于承诺无法兑现的事情，开发人员会给自己留一点缓冲空间，即他们会“虚增”估算。因此，过去需要4小时完成的任务，现在可能被估算为10小时。

当然，管理者也知道这一点。他们能看出估算何时不合理。因此，管理者最终与开发人员协商这些估算也就不足为奇了。现在，一个10小时的估算被削减到6小时。他们在协商本应是绝对的估算。从组织角度来看，这不太合理。

如果能在不使估算听起来像承诺的情况下进行估算，岂不是更好？这里的一个问题是，时间经常被用作工作估算的度量单位。也就是说，每个估算都以小时来衡量：做这个需要5小时，做那个需要1小时。很自然地，你可能会认为，如果一个标准工作日有8小时，你可以完成一个5小时的任务和大约三个1小时的任务。最终，开发人员和产品经理很自然地开始将时间估算与工作时间联系起来。这使得人们很容易将估算误解为承诺。

解决方案：故事点

那么，我们如何解决这个问题？业界常用的一种方法是使用故事点。

故事点是我们旨在用来替代时间单位的度量方式。让我们进一步讨论故事点。

本节总结

在本节中，我们回顾了估算、目标和承诺之间的关键区别，并指出了使用时间（如小时）进行估算的主要问题：它容易被误解为对工作完成时间的承诺。为了解决这个问题，我们引入了故事点作为替代的、更抽象的估算单位，旨在将工作量估算与具体的时间承诺脱钩，从而为团队规划提供更大的灵活性和准确性。

036：故事点详解 🧩

概述

在本节课中，我们将要学习敏捷开发中的一个核心估算工具——故事点。我们将了解故事点是什么、它如何解决传统时间估算的问题、以及如何正确使用它来估算工作量，同时避免将估算误认为承诺。

故事点的起源与目的

故事点的诞生源于保护软件开发人员心智健康的需求，因为估算常常被当作承诺。这在软件项目管理中是一个普遍存在的巨大问题。

因此，开发人员对于为完成特定任务给出一个确切的时间估算感到畏惧。开发人员可能被迫向管理者提供任务完成时间的估算，而管理者最终会将这个估算当作承诺。管理者随后又会将这个“承诺”传达给他们的上级，突然间，产品的内部截止日期就建立在某一位开发人员的粗略估算之上。

更糟糕的是，如果开发人员的工作最终花费的时间超过了他们的估算（这种情况经常发生），该开发人员就会感受到压力。这并非开发人员表现不佳，只是他们没能做出准确的估算。不准确的估算也未必反映了开发人员缺乏经验或能力。

正如你将在本次关于任务时间估算的课程中看到的，做出可靠且准确的估算非常困难，尤其是当你对未来很远的事情进行估算时。

故事点如何解决问题

故事点试图解决这个问题的方式是，消除将时间作为估算工作的度量单位。取而代之的是，在估算需要完成的工作时使用故事点。

故事点是无量纲且相对的。关键在于，它们让你的开发人员不再试图估算某项工作将花费的确切时间，而是转向估算它相对于其他工作需要花费多长时间。

故事点的使用方法

以下是它的工作原理。你的开发团队从产品待办事项列表中选择一个相对容易估算的产品需求，即一个用户故事。

然后，开发人员为它分配一个任意的整数值，我们称之为故事点。一旦你有了这个基准值，你就可以基于它为其余的用户故事分配故事点。

因此，如果下一个用户故事规模大致相同，它将获得相同数量的点数。如果随后的一个故事大约是基准故事的两倍大，那么你就分配给它两倍的点数，依此类推。

最终你得到的是一个用户故事列表，其工作量估算全部基于彼此，而不是你的开发人员在估算每个用户故事需要多长时间时，无意中承诺了某个具体的时间量。他们是在确定每个用户故事的规模大小。而这正是估算应有的样子。

请记住，估算不应该是承诺，因此将时间因素从中剔除有助于防止它们变成承诺。

这种方法之所以有效，是因为人类实际上非常不擅长精确地估算事物。我们更擅长基于相对大小进行估算。

现实世界类比

让我们看一个现实世界的例子来演示这个概念。假设你想估算一栋建筑的高度。你试图凭直觉估算它的大小，并说它大约有60米高。

另一种方法是将其大小与另一栋建筑进行比较。

选择附近一栋较小的建筑，用它作为尺度。那么那栋较高的建筑可能相当于三栋小建筑的高度。

在软件领域，这种方法带来的额外好处是能保持开发人员的心智健康。估算故事点时你不必追求精确，因为一切都是相对的。如果开发人员超出了他们的时间估算，即使只是几分钟，也可能在心理上对他们造成负担。他们可能会因为未能按时完成估算而对自己感到沮丧。而使用故事点，则不容易“超出估算”，因为估算与时间无关。

知识检查

你刚刚学习了一些关于故事点的知识。它们是一种避免在使用小时数估算时意外做出承诺的方法。

故事点的哪些特性使其非常适合用于估算而不至于变成承诺？你可以选择多个答案。
A. 故事点是无量纲的。
B. 故事点的数值可能因项目而异。
C. 故事点更难理解。
D. 故事点不直接映射到一个时间值。
E. 故事点完全不映射时间。

答案：A, B, D。
故事点是无量纲的，并且它们的数值因项目而异。由于它们因项目而异，其对应的时间价值也可能变化，但这并不意味着故事点完全不映射时间。

使用斐波那契序列

故事点常常被误解，因为它们经常被赋予像小时数一样被对待的数值。例如，如果你将第一个用户故事设为100个故事点，那么你的开发人员就很容易基于此为其他用户故事分配非常精确的点数。因此，你可能会看到其他用户故事被分配了诸如42点这样的值。

如果使用用户故事的整个要点在于相对性，那么使用如此精确的数字就没有太大意义。为你的故事点设置合适的基准值非常重要，这样才能保持点数的相对性。

帮助支持这种相对性的一种方法是使用固定的故事点数值。一个好的做法是基于斐波那契序列来分配故事点。

斐波那契序列是一个数字序列，其中任何单个数字都是前两个数字之和。

所以一个斐波那契序列可能看起来像这样：
1, 2, 3, 5, 8, 13, ...

斐波那契数使得使用故事点进行估算变得非常简单。你不是使用任何你认为可行的数字，而是限制自己只使用斐波那契数进行估算。如果你的估算落在两个可用数字之间，你会向上取整到最接近的可用数字。这使你的估算保持整洁，并且由于存在不确定性，避免了不必要地使大估算过于精确。

因此，如果你的第一个任务估算被分配为3点，而你的下一个任务看起来大约是它的两倍大，你不会分配给它6点，因为你受限于斐波那契序列，你会将估算向上取整到8点。通过这种方式，你可以控制你的估算，并在处理不确定性的同时避免做出无意的承诺。

另一个知识检查

以下哪个值最适合作为故事点？
A. 200
B. 3
C. 18
D. 50

正确答案是 B, 3。
因为3这个数值既小又好，很容易围绕它估算其他值，而不会陷入点数的百分比计算。3也是最常见的斐波那契序列中的一个数字。因此，如果你在斐波那契序列中使用故事点估算，它仍然是一个你会看到的数字。

故事点的争议与局限

上一节我们介绍了故事点的理想使用方法，本节中我们来看看它在实践中面临的挑战。故事点是估算工作量的一个很好的替代方案，可以避免使用可能花费的小时数。然而，故事点并不是业界广泛接受的实践，即使在敏捷软件开发和Scrum最坚定的支持者中也是如此。如果故事点效果这么好，为什么还会存在争议呢？

故事点可能很棘手。首先，实施它需要一种非常特殊的思维方式。对于开发人员来说，突然将思维从时间估算转向点数估算可能是一个令人困惑的要求。最终经常发生的情况是，开发人员会将预测的若干小时数转换为特定数量的故事点，因为这对他们来说最有意义。然而，这完全违背了故事点的初衷。

你可能会认为，这只是一个教育问题。确实，经过一些练习后，开发人员在使用故事点估算工作时确实会变得更好。然而，估算本身存在一些固有的限制，这使得故事点成为一个敏感话题。

其中一个限制是，估算行为本身就是一项有风险的工作。你永远无法100%确定任何给定的估算都是准确的。这就是为什么它们被称为“估算”。虽然相对大小的估算比精确的数字估算要准确得多，但相对大小估算仍然不完美。一个很好的例子是垂直-水平感知错觉，它展示了我们在这方面有多不擅长。

这里本质上发生的是，当一条垂直线段放在一条等长的水平线段上方时，人们往往会高估垂直线段的长度。所以，即使只是几条线段，也很容易看出我们并不擅长估算某物的大小，即使你有直接的比较对象。

另一个问题是，故事点在大型团队中可能会失控。它们本意是可扩展的，但一些开发人员可能会为非常小的任务给自己分配过高的故事点，以制造高生产力的假象。如果整个项目中每个点的估算是一致的，这倒没问题。但有可能管理者会要求团队在项目中期加倍努力以提高生产力。如果在此时，开发人员通过改变故事点的基准来人为地夸大他们的数字，准确的估算就变得更具挑战性。

总结

本节课中我们一起学习了故事点。它是一种基于相对概念来估算工作量的方法，旨在避免将估算误认为承诺。我们探讨了其原理、使用方法（特别是结合斐波那契序列）、优势以及在实际应用中需要注意的争议和局限。

在下一节课中，我将介绍“速率”的概念，这是一种衡量团队随时间推移的生产力的方法。我们很快再见。😊

037：9_01_4-2-2-速度估算

概述

在本节课中，我们将要学习敏捷开发中的一个核心概念：速度。我们将了解速度的定义、如何计算它，以及如何利用它来估算团队未来的工作量。

什么是速度？

上一节我们介绍了故事点以及如何使用它们来估算用户故事的规模。故事点是对完成一个用户故事所需工作量的相对估算。

本节中，我们来看看速度，以及它与项目和估算的关系。

那么，什么是速度？就像物理学中的术语一样，速度是衡量你前进快慢的指标。

在物理学中，平均速度是通过测量一定时间内移动的距离来计算的。例如，如果你在公路旅行，你可以通过计算过去一小时行驶的公里数或英里数来计算你的速度。

对于软件项目，情况非常相似。唯一的区别在于，我们测量的不是移动的距离，而是完成的工作量，时间单位则是你的冲刺周期长度。例如，一个软件项目的速度可以表示为“每个冲刺完成15个故事点”。顺便提一下，冲刺和迭代是同一个概念，它们都是将工作按小块进行时间盒定的方式。我们将在下一课讨论时间盒定。

如何衡量工作量？

你可以用不同的单位来衡量生产力。就像公路旅行中，你可以选择使用英里或公里作为单位，它们都能给出速度，只是解释结果的方式会有所不同。

在软件项目中，衡量生产力的单位可以是完成的用户故事数量，也可以是完成的故事点数量。两者都衡量了项目中完成的工作量，但解释方式不同。混合使用用户故事和故事点可能会像混合使用公里和英里一样令人困惑。

尽管在本课程中你会看到同时使用用户故事和故事点来计算速度，但本节我将主要使用故事点作为生产力衡量单位。因为用户故事的规模可能差异很大，使用故事点总数比简单地计算用户故事数量更能代表完成的工作量。

使用用户故事来估算，类似于计算你的公路旅行穿过了多少个城镇。在你的计划路线上城镇数量是有限的，但说你已经穿过了9个城镇中的3个，并不能为你提供关于何时到达下一个城镇或目的地的可靠信息。

计算速度

现在你知道了速度是什么，让我们来计算它。如前所述，速度是在一段时间内完成的工作量。

在敏捷社区中，通常使用团队在一个冲刺周期内完成的、标记为“已完成”的用户故事所对应的故事点总数来衡量团队速度。

以下是计算速度的步骤：

确定一个冲刺周期（例如，两周）。
记录在该冲刺周期内所有被标记为“已完成”的用户故事。
将这些“已完成”用户故事的故事点相加。
总和即为该冲刺的速度。

公式：速度 = 一个冲刺周期内所有“已完成”用户故事的故事点总和

“已完成”的定义

什么叫做一个用户故事被标记为“已完成”？一种可能的理解是，该用户故事的功能代码已经编写完成。然而，按照这个定义，你可能会在所需功能完成后就认为用户故事完成了。这在很多情况下可能没问题，但你如何测试它是否真的完成了呢？

要认为一个用户故事“已完成”，至少在Scrum框架中，该用户故事的测试必须通过。这意味着产品必须通过单元测试和验收测试，你和产品负责人才能认为该用户故事完成。

因此，这意味着你不能将一个用户故事的故事点计入你的速度，除非该故事的所有测试都已通过。在实际工作中，你会听到“完成，完成”的说法，这与Scrum中认为用户故事“已完成”是同一个意思：所有功能必须构建完成，所有测试必须通过，并且必须有相应的文档。

速度的作用

你为什么要计算速度？速度帮助你对你团队在整个项目中可以完成的工作量做出有意义的估算。这被称为速度驱动开发。

在速度驱动开发中，每个冲刺的计划都是基于先前冲刺中完成的工作量或达到的速度。这里的前提是，开发团队要知道在任何一个给定的冲刺中可以完成多少工作，唯一的方法就是看他们过去完成了多少。如果你不清楚过去完成类似工作花了多少精力，就很难估算新工作可能需要多少精力。

因此，使用团队速度进行规划，需要其过去的速度具有一定的稳定性。你需要知道团队完成工作的历史记录是稳定的。这可能需要在项目开始后经过几个冲刺才能实现。如果没有对团队生产力的可靠估算，你就无法可靠地用它来估算未来的工作。

使用速度进行估算

假设你的团队速度是恒定且稳定的。你如何使用它来估算未来的工作？这实际上是关于使用你过去的实际速度来估算未来的速度。你根据之前每个冲刺完成的工作量来预测下一个冲刺可以完成多少工作。

你通常会处于以下两种情况之一：

你刚刚开始项目，没有任何速度数据可以作为估算依据。
你正处于项目中期，至少有一些过去的数据。

在项目开始时，很难估算你的速度，因为你没有可以作为估算依据的先前工作。因此，你可以预期在任何给定项目开始时的速度估算是不准确的。从客观的角度来看，你只是不知道你的生产力能达到什么水平。

当你在项目中期时，你将拥有更多数据可供使用。然而，值得注意的是，大多数项目开始时速度并不稳定。团队需要一点时间来找到节奏。所以在初期，你可能仍然需要处理一定程度的不准确性。不过，随着时间的推移，情况会趋于平稳，你应该能够获得更好的估算。

关于速度的讨论

现在我们已经讨论了速度以及如何将其用作估算工具，让我们开始一点讨论。关于速度估算是否准确甚至是否有用，存在一些争议。我鼓励你在讨论区分享你对这个话题的看法，我会在那里提供一些讨论起点。

总结

本节课中，我们一起学习了速度的概念。速度是跟踪团队生产力并估算未来可完成工作量的手段。理论上，它非常强大；在实践中，它也有一些潜在的缺点。尽管如此，了解如何计算团队速度仍然很有用，因为了解团队的大致生产力仍然具有价值。

下一节课，我将讨论时间盒定。

038：时间盒 📦

在本节课中，我们将要学习一个关键的敏捷规划概念——时间盒。我们将探讨它是什么、为什么重要，以及如何利用它来组织和管理软件开发工作，以确保项目稳步推进。

概述

上一节我们介绍了如何利用团队速率来估算项目工作量。本节中，我们来看看为什么在敏捷开发中，我们总是将工作安排在固定的时间段（即“冲刺”）内完成。这个做法的核心理念就是“时间盒”。

什么是故事点？ 😡

在深入时间盒之前，我们先简要回顾一下故事点。故事点是用于估算任何给定用户故事所需工作量的相对单位。它们不以时间单位衡量，以避免估算听起来像承诺。你可以通过跟踪团队在一个冲刺内能完成多少工作来确定团队的速率。

引入时间盒

你可能会想，如何确保开发过程是有纪律的呢？答案就是时间盒。

时间盒是一个通用术语，指在受限的时间段内构建某些东西。你可以为任何活动设置时间盒，从为期四周的Scrum冲刺到半小时的计划会议。

时间盒：将工作安排在固定长度的时间段内完成。

以下哪一项是Scrum冲刺所属的广义类别？
A. 时间锁
B. 计划
C. 工作盒
D. 时间盒

正确答案是 D，时间盒。

Scrum冲刺被认为是时间盒化的，因为它们被限制在相对较短的开发时间和相对较少的工作量内。

如何创建时间盒

要创建一个时间盒，你只需要：

在项目中设定一个时间段，工作将在此期间完成。
设定在该时间段内将完成多少工作的限制。
在开始时规划这些工作。

在Scrum中，冲刺长度通常为两到四周，前后各有计划期和评审期。

时间盒的重要性

独自开发产品并跟踪进度，然后根据速率估算项目完成日期是一回事。而为了确保项目按计划进行而规划工作，则是另一回事。

这是因为，如果没有开发目标或里程碑，大多数人往往会比定期规划工作时开发得更慢。想想看，如果你给自己一项任务，却没有明确的完成截止日期，那么很容易分心去做不必要的工作。由于时间看似灵活，工作范围往往会扩大，这是一种风险。

然而，如果你将工作规划在足够小的时间剂量内，就很容易看清下一个目标是什么，以及到那时需要完成什么。当你使用时间盒时，你将一定量的工作放入特别规划的、固定长度的时间段或“盒子”中。你取项目结束时需要完成的工作的一个子集，并将其划分为可管理的块，放入这些盒子中。

时间盒的延伸价值

时间盒的妙处在于，除了以理性、可持续的方式组织工作外，你现在还可以定期从工作中学习。许多方法允许你规划出评审时间。你可以利用这个评审时间来回顾你的进展，然后利用获得的见解来为下一个时间盒制定计划。这对时间盒原则本身来说并非关键，但却是该原则的一个宝贵延伸。

时间盒让你有机会看到工作将如何在项目中划分。即使你不知道具体在什么时间会完成什么，有一个大致的想法仍然是很有用的信息。

实现可发布的产品

你不必等到项目最后才拥有一个可发布的产品。它可以分阶段发布。事实上，在每个时间盒结束时，你都应该拥有一个可以潜在地作为产品发布的可工作软件。这能保持开发人员的士气，并确保即使资源耗尽，你在项目结束时仍然拥有一个有形的产品。

请选择时间盒的关键特征。
A. 时间受限
B. 之前有计划会议
C. 之后有评审会议

正确答案是 A，时间盒是时间受限的。

时间盒化的工作可以在前后安排计划和评审会议，但这并不是该概念本身的关键，因此时间盒只是一种将你的工作计划分解为可管理块的方法。

总结

本节课中，我们一起学习了时间盒的概念。时间盒是一种将工作安排在固定时间段内完成的规划方法，它有助于保持开发节奏、控制范围蔓延，并允许团队定期评审和调整。它易于实施，并能显著提高项目成功的几率。

在下一课中，我将讨论一种流行的可视化项目计划的方法——燃尽图。让我们继续学习。

039：甘特图

欢迎来到下一节课。在上一节课中，我们介绍了使用“时间盒”技术来规划项目的价值。

在本节课中，我们将学习另一种项目规划技术：甘特图。与时间盒不同，甘特图并非组织时间的一般性方法，而是一种用于可视化展示项目计划工作的图表工具。甘特图能为你提供项目的长期和短期洞察，它们非常有价值，并能对项目的成功产生巨大影响。

什么是甘特图？📊

甘特图是一种用于可视化项目的简单工具。其基本理念是，它能在一个视图中同时展示项目的计划、任务依赖关系和截止日期。

一个基础的甘特图由任务和日期构成。

任务（通常来自工作分解结构）沿着图表的左侧纵向排列。
日期沿着图表的顶部横向排列。

每个任务被逐一列出，计划中第一个开始的任务位于最顶部。该任务的开始日期，由一条在对应顶部日期下方绘制的横条的起点表示。这条横条从开始日期延伸至该任务计划完成的日期。

当所有任务都布局好后，你就能清晰地看到每个独立任务计划于何时开始与结束。

甘特图与敏捷兼容吗？🤔

你可能会问：这难道不是非常不“敏捷”吗？如果甘特图只是一系列顺序排列的任务列表，那它岂不是更适合瀑布式流程？

答案是：如果你只是毫无上下文地一个接一个列出任务，那确实如此。然而，你可以在甘特图中添加更多信息。例如，你可以将图表的某些部分划分为不同的区块，并标记为“冲刺”。这种做法完全可行，并且只要你允许这个计划根据实际情况进行调整，它就同样是完全敏捷的。

你可以利用甘特图来获取关于项目的一些关键洞察。其中最明显的几点包括：你能够大致看到项目将于何时完成，以及哪些任务会同时进行。

案例分析：甘特图能展示什么？

奥斯汀是一位软件产品经理，正与软件开发团队合作。他选择使用甘特图向公司领导层展示项目计划，以说明项目进度安排。

基于奥斯汀的甘特图，公司领导层将能了解到哪些信息？（可多选）

A. 没有信息，没有上下文的甘特图毫无用处。
B. 项目任务依赖关系。
C. 预估的任务时长。
D. 项目预算。

正确答案是 B 和 C。甘特图使你能够看到项目的任务时长，同时也能展示任务之间的依赖关系。

接下来，让我们详细探讨一下任务依赖关系。

任务依赖关系与关键路径 🔗

甘特图不仅仅是日历和待办事项列表的混合体。如果你在甘特图中包含了任务依赖关系，它们会变得更有用。

以下是具体做法：

在创建甘特图之前，先列出将要包含在图中的所有任务。
找出哪些任务需要等待另一个任务完成后才能开始。例如，假设你有两个任务，如果第二个任务必须等到第一个任务完成后才能启动，那么我们就说第二个任务依赖于第一个任务。
在你的任务列表中，在第二个任务旁做标记，注明它依赖于第一个任务。
为所有任务及其依赖关系重复此过程，现在你就得到了一个通过依赖关系紧密关联的完整任务列表。

当你将这些信息转化为甘特图时，你仍然像之前一样列出所有任务及其起止日期。唯一的不同是，你现在知道某些任务必须等待其他任务完成后才能开始。在甘特图上，这通常用一个从被依赖任务指向依赖任务的箭头来表示。

将任务依赖关系如此清晰地展示出来的一个巨大好处是，你可以非常容易地看到项目的关键路径。这让你能够明确资源的最佳投入方向，并了解在什么时间需要完成什么工作。摩根将在下一个模块中更详细地讨论任务依赖关系和关键路径。

甘特图的应用层级 📈

需要指出的是，甘特图可以在“迭代”或“发布”层级使用。

在迭代层级，你可以用它来洞察当前冲刺时间盒内未来几天的任务安排。
在发布层级，你可以使用用户故事而非具体任务作为图表中的工作单元，从而对未来几个冲刺中的用户故事获得洞察。

总结

以上就是甘特图。它是一种用于可视化项目计划的超级简单的方法。市面上有大量工具可以帮助你创建甘特图。

在下一节课中，我将整合本模块讨论的许多内容，并介绍发布计划。发布计划是项目成功的关键方面，请不要错过。

040：发布计划

概述

在本节课中，我们将要学习敏捷规划中的发布计划。发布计划是一种高层次的项目规划方法，用于将用户故事分配到项目中的各个冲刺里，从而为团队和客户描绘出清晰的产品开发路线图。

欢迎来到本模块的最后一课。在上一课中，我们介绍了甘特图作为项目规划的工具。它是一种可视化项目进度、明确工作何时完成的好方法。在讨论甘特图时，我也提到它可以用于迭代层面和发布层面的规划。这被称为两级规划。

迭代规划是细粒度的，处理的是具体的任务。发布规划则是粗粒度的，处理的是用户故事。在这两种情况下，迭代或冲刺的概念都非常重要。我在之前的课程中讨论过时间盒。冲刺是一个小的、固定长度的时间盒，工作在其中被组织起来。

本节中，我们将逐步构建发布计划的概念。

什么是发布计划？

在Scrum中，我们有被称为冲刺的时间盒迭代。在每个冲刺开始时，会有一个冲刺规划会议，用于创建迭代计划。在迭代计划中，开发任务被安排在这个冲刺内完成。这些任务被列在冲刺待办列表上。任务由开发者在工作开始前自行认领。

在每个冲刺结束时，还会有一个冲刺评审会议。这时，可工作的软件会展示给客户或产品负责人。理想情况下，每个冲刺结束时产生的软件都应该是可发布的。

然而，迭代规划是短期的。因此，发布计划用于确定在接下来几个冲刺中，哪些用户故事应该在每个冲刺结束时完成并发布。用户故事来自产品待办列表，并根据其优先级被安排到即将到来的冲刺中。

自然地，你需要在开始第一个冲刺及其迭代规划之前，先进行发布计划，将用户故事分配到各个冲刺中。

从用户故事到任务

假设你有一个用户故事：“作为一个音乐听众，我希望能够暂停我的音乐，以便在我需要听其他东西时能保持在我歌曲中的位置。”

这个故事对单个开发者来说太大了，无法直接完成。为了使其更易于管理，你需要将这个故事转化为一系列任务。这些任务应该与单个开发者在几小时内能够编程完成的工作量相匹配。

基于这个思路，为管理这个用户故事，你可能会创建以下几个任务：

在图形界面添加一个暂停按钮。
创建保存用户在当前歌曲中位置的功能。
创建当按下暂停按钮时停止播放的功能。
创建恢复歌曲中保存位置的功能。

所有这些任务都是开发者可以创建的可执行项。它们共同促成了其来源用户故事的总体完成。

如何制定发布计划？

在发布计划中，你如何确保在正确的时间规划了正确的工作？哪个用户故事应该在哪个冲刺中发布并由产品负责人或客户评审？

这实际上是一个优先级问题。我在《客户需求与软件需求》课程中讨论过产品待办列表中用户故事的优先级排序。

发布计划是通过从产品待办列表中取出用户故事，并将它们分配到各个冲刺中来构建的。用户故事在冲刺间的分配应该有其逻辑。否则，用户故事的随意堆积可能导致冲刺混乱无序。

首先，你从中提取用户故事的待办列表应该已经由你的产品负责人或客户排定了优先级。你会将最高优先级的用户故事标记为“必须做”，中等优先级的标记为“应该做”，低优先级的标记为“可以做”。这样，在进入开发之前，你就能很好地了解客户眼中的优先级。

然后，从优先级列表的顶部开始，将已排定优先级的用户故事分配到你的发布计划中的各个冲刺里，直到每个冲刺都填充了适量的工作。

“适量的工作”在这里有点难以准确把握。了解多少工作量合适的最佳方式是通过经验和数据。你的团队在估算工作方面做得越好，你就越能知道他们在给定时间内能完成多少工作。

如果做得好，你最终会对接下来几个冲刺结束时产品应该是什么样子有一个相当准确的看法。这是与你的产品负责人或客户设定期望、并提升开发团队士气的好方法。每个人都喜欢看到进展和对未来的愿景。发布计划是提供这种愿景的绝佳方式。

小测验

Alexis是一名软件产品经理，她正与她的开发团队一起规划项目。他们正在创建一个发布计划，并选择要包含在第一个冲刺中的用户故事。Alexis和她的团队如何决定先完成哪些用户故事？

A. 由开发团队确定优先级。
B. 随机分配以避免偏见。
C. 由客户确定优先级。
D. 由用户确定优先级。

在敏捷中，用户故事由客户或在Scrum中由产品负责人确定优先级。因此，发布计划应反映这些优先级。所以，正确答案是 C。

发布计划的价值

发布计划是你工具箱中的一项宝贵技术。它不仅是一个极好的规划工具，还能起到鼓舞士气的作用。当你的开发者能在整体背景下看到他们的工作时，他们很容易保持积极性。

让我们听听行业专家如何管理长期规划。

行业专家观点：产品路线图

路线图是一份战略文件，规划了我们产品或服务的发展路线。它是产品经理可以使用的最重要的工具之一，因为它有助于在不同团队之间达成一致，这些团队可能对应该做什么持有不同的看法。

制定和定义路线图是一项艰巨的任务，可能相当耗时。它需要大量的研究、与不同人员的交谈和协商，确保他们的观点被听取。对于路线图本身，我关注三个领域：当前开发、近期开发和未来。当前开发非常具体，而随着我们走向未来，它变得更加抽象，为我们提供了更多根据需要改变的空间。

这份文件是活的文档，当我们获得更多信息，有充分的技术、业务或市场理由时，我们会更新它。我们努力坚持它，以帮助构建我们正在建设的内容的背景：我们如何为特定用户解决问题？我们的差异化是什么？我们与其他人有何不同？

我分享这份路线图并确保其可见，它有助于构建我们的规划框架。如果我们是一个敏捷团队，我们为冲刺做规划，每个冲刺我们都会查看路线图，确保我们所做的工作符合路线图的目标。

在创建路线图时，我关注三个领域：

基本要求：为了在这个市场领域被认真对待，我们需要提供的最低限度的东西。

差异化：我们做的与其他人不同的地方。我们要确保我们正在增强这一点，并且我们添加的功能是差异化的一部分。

微小而精彩的瞬间：一些令人愉悦的小惊喜。当用户使用软件时，他们会得到一点惊喜。

管理路线图，保护团队免受那些可能不会在短期内被纳入的想法干扰，是确保你正在构建所需内容的重要组成部分。

总结

本节课中，我们一起学习了发布计划。发布计划是一种高层次的项目规划方法，用于将用户故事分配到项目中的各个冲刺里。我们了解到，制定发布计划的关键在于依据客户或产品负责人设定的优先级，从产品待办列表中提取用户故事，并根据团队估算的能力将其分配到冲刺中。一个好的发布计划不仅能有效规划工作，还能为团队和客户提供清晰的产品愿景，从而提升团队士气并管理客户期望。

在本模块中，我们学习了如何在多个冲刺间进行规划。在下一个模块中，Morgan将深入探讨如何在单个冲刺内进行更详细的规划。我们期待在那里见到你。

041：任务时间估算

在本节课中，我们将要学习软件项目中的任务时间估算。我们将探讨估算的重要性、估算准确性随时间变化的规律，并介绍几种实用的估算技术。

概述：估算与不确定性

估算是一个在本系列课程中频繁讨论的话题。你已经了解到，做出良好的估算对于制定时间表和达成目标至关重要。现在，是时候获取一些创建估算的实际经验了。

我们将从整体审视项目开始，了解估算在何时何地最为准确。接着，我们将探讨几种不同的估算方法。你可以采用多种途径，本节课将引导你了解其中一部分。

不确定性锥

首先，我要向你介绍“不确定性锥”。在项目开始时不确定性很高，而在项目结束时不确定性很低，这并不令人意外。这是我们在讨论不确定性空间时曾提及的内容。

当不确定性很高时进行估算，你的估算很可能极不准确。随着项目推进，需求和发展节奏变得更加清晰，做出准确估算会容易得多。这正是“不确定性锥”所展示的。

在我们更详细地讨论不确定性锥之前，先来看看你是否能解读图表所展示的信息。

在不确定性锥图表上，当垂直区间最大时，变异性最高。随着时间的推移，变异性越来越小。因此，位于项目起始点的圆圈A具有最高的变异性。此时的估算可能比实际小四倍或大四倍。所以，答案A是正确的。

在Y轴上，我们表示的是变异性。这是估算可能变化的倍数。区间越大，变异性越高。从图表中可以看到，随着时间沿X轴推进，我们的变异性变得越来越小，从而形成了一个锥形，因此得名“不确定性锥”。

那么，如何将其应用于项目呢？随着项目进行，不确定性得以解决，因此估算的变异性变小。

你从初始产品定义开始一个项目。这是产品初步想法形成的阶段。你脑中有一个大致概念，但没有真正的解决方案。此时的变异性相当高。如果你在这个早期阶段进行估算，可能需要一个很大的范围。

当你进展到需求启发活动时，变异性变小。此时，产品的特性更加明确，因此更容易做出准确估算，你的估算范围也可以更小。

随后，你制定潜在方案，变异性进一步减小。一旦架构设计和最终的详细设计完成，变异性就小得多，你的估算也更加可靠。

你可以利用这些变异性来为项目进行估算。根据你在项目时间线中所处的位置，可以将估算乘以相应的变异性倍数，以获得更准确的范围。

例如，假设你猜测一项任务需要4小时完成。如果你正处于需求启发活动阶段，图表估计变异性倍数为2和0.5。那么，你可以将4小时的猜测乘以2和0.5，得到完成该任务的估算范围为2到8小时。

估算技术

到目前为止，你已经了解了估算是什么、如何使用以及何时变异性最小。但你还没有学习如何进行估算。现在让我们来探讨这一点。

你可以采用多种方法来生成估算。我们之前说过，估算应该是不可协商的，并且应基于某种数据。

以下是几种估算技术：

自下而上技术

在这种技术中，你需要将项目分解为小的、可管理的任务，就像我们在本课程前面创建工作分解结构时所做的那样。估算小任务比估算整个项目更容易、更准确。

一旦分解了任务，你就为每个任务生成一个估算。然后将它们全部加起来，这就成为了你的项目估算。这种方法有优点也有缺点。该方法基于小任务的估算，这些估算的不确定性应该较低。然而，这些任务的估算可能并非基于任何实际数据。你可能希望将此技术与另一种技术结合使用，以获得最准确的结果。

类比技术

在这种技术中，你利用类似项目的经验进行估算。当然，如果你和你的团队已经完成过一个类似的项目，这种技术是适用的。你需要确保工作流程和所使用的技术与之前使用的相似。

这种技术的优点是易于使用和理解。如果团队完全相同，并且项目与你过去见过的项目相似，它还可以基于团队完成的工作提供准确的结果。但这种情况很少见。每个软件项目都有独特的需求，随之会产生独特的问题。因此，这种技术肯定有许多缺点。

专家技术

在这种方法中，你汇集来自多个估算者的估算。如果你让多个估算者专门审视你的项目，这种技术可能成本很高。然而，你会得到更准确的结果。如果你使用的是专家对类似项目的估算，请注意你的项目可能有其独特的问题，因此不会与估算完全吻合。

技术应用场景分析

假设你是一名软件产品经理，正在开发一个小的移动应用程序。你刚刚完成了一个类似的移动应用程序项目。你之前项目中的两名开发人员也在这个项目的团队中。你总共有八名开发人员。你已经创建了工作分解结构。你有一些来自专家的估算，但它们是基于一个更大的移动应用程序。你需要为你的项目创建估算。你的客户希望在一小时内得到估算，因此你只有时间完成一种技术。

在这种情况下，哪种估算技术效果最好？

理想情况下，你应该能够利用所有可用的信息来生成准确的估算。如果你在这种情况下只能选择一种技术，最好的选择是使用自下而上技术。因此，答案A是最佳答案，因为你已经有了可供使用的工作分解结构。

类比技术在这里并不理想，因为团队与你之前的团队有很大不同。新开发人员开发这个产品可能需要更多或更少的时间。由于专家的估算是基于一个更大的移动应用程序，它们可能对你来说不准确。而你绝不应该仅仅猜测估算。

总结

本节课中，我们一起学习了软件项目中的任务时间估算。我们首先通过“不确定性锥”理解了估算准确性随项目进展而提高的规律。然后，我们探讨了三种主要的估算技术：自下而上技术、类比技术和专家技术，并分析了它们各自的优缺点及适用场景。记住，良好的估算应基于数据，并结合项目所处的具体阶段和可用信息来选择最合适的技术。

042：14_02_4-3-1a-任务时间估算

在本节课中，我们将学习一种使用公式来改进任务时间估算的方法。这种方法通过计算一个时间范围，而非单一数字，来更准确地反映项目时间的不确定性。

概述

由于项目执行中存在各种变数，一个估算值应该是一个范围，而不是一个单一的数字。本节将介绍一个基于三个关键时间点的公式，用于计算这个估算范围。

核心公式介绍

上一节我们介绍了多种估算方法，本节中我们来看看如何通过一个数学公式来生成更可靠的估算范围。这个公式基于三个时间点：

最可能时间：我们称之为 TM。这是你对任务或项目最可能花费时间的估计。
乐观时间：我们称之为 TO。这是在一切顺利、团队高效工作的情况下，完成任务所需的最短时间。
悲观时间：我们称之为 TP。这是在最坏情况下，完成任务所需的最长时间。

基于这三个数值，我们将计算两个关键结果：

期望时间：我们称之为 TE。
偏差：我们称之为 σ（西格玛）。在数学中，σ 常用来表示标准差或偏差。

偏差值越小，说明乐观时间和悲观时间之间的差距越小，你的估算范围也就越精确。

计算公式

以下是计算期望时间和偏差的具体步骤。

计算期望时间

期望时间 TE 的计算公式如下：

TE = (TO + 4 × TM + TP) / 6

这个公式为最可能时间赋予了更高的权重。

计算偏差

偏差 σ 的计算公式如下：

σ = (TP - TO) / 6

这个公式衡量了估算的不确定性范围。

计算估算范围

得到 TE 和 σ 后，你就可以计算估算范围了。

要得到范围的下限，用期望时间减去偏差：TE - σ
要得到范围的上限，用期望时间加上偏差：TE + σ

用数学术语表示，这个范围就是 TE ± σ。

这个范围（TE ± σ）意味着实际任务时间有 68.3% 的可能性落在此区间内。

如果你希望估算更加可靠，可以将偏差加倍，从而得到一个更宽的范围：TE ± 2σ。这个范围意味着实际任务时间有 95.5% 的可能性落在此区间内。

你需要根据项目情况决定哪个更重要：是一个范围更大但准确率高达95.5%的估算，还是一个范围更小但准确率只有68.3%的估算。

应用示例

让我们通过一个例子来具体应用这些公式。

假设我们有以下数据：

最可能时间 TM = 15 天
乐观时间 TO = 12 天
悲观时间 TP = 30 天

第一步：计算期望时间 TE

TE = (TO + 4 × TM + TP) / 6
   = (12 + 4 × 15 + 30) / 6
   = (12 + 60 + 30) / 6
   = 102 / 6
   = 17 天

第二步：计算偏差 σ

σ = (TP - TO) / 6
  = (30 - 12) / 6
  = 18 / 6
  = 3 天

第三步：计算估算范围

68.3% 可能性范围：TE ± σ = 17 ± 3 天 → 14 到 20 天
95.5% 可能性范围：TE ± 2σ = 17 ± (2×3) 天 → 11 到 23 天

可以看到，95.5%可能性对应的范围（11-23天）比68.3%可能性对应的范围（14-20天）更宽。

注意：如果计算结果不是整数，务必向上取整。例如，54.5天取整为55天，6.9天取整为7天，23.1天取整为24天。

练习题

为了帮助你掌握这些公式，建议你完成课程提供的练习工作表。工作表包含了三个示例，并附有分步解答的答案页。亲自进行计算对于牢固掌握这一估算技巧至关重要。

总结

本节课我们一起学习了如何使用 PERT（计划评审技术） 公式进行任务时间估算。我们了解了如何通过最可能时间（TM）、乐观时间（TO）和悲观时间（TP） 来计算期望时间（TE） 和偏差（σ），并据此生成具有不同置信水平（68.3% 或 95.5%）的估算范围。这是一种量化估算不确定性、提高规划可靠性的有效方法。

现在你已经学会了如何生成估算，接下来我们可以开始讨论迭代计划。在下一课中，我们将探讨任务依赖性以及如何在迭代规划中考虑它们。

043：任务依赖关系

在本节课中，我们将深入学习任务依赖关系。任务依赖关系是项目规划与排程中的一个核心概念，理解它对于制定有效的项目计划至关重要。

概述

任务依赖关系指的是一个任务的开始或结束，依赖于另一个任务的开始或结束状态。在软件过程和敏捷实践的课程中，我们曾提及此概念，并在本课程的第一课中简要介绍过。当我们开始进行任务排程时，这是一个必须仔细考虑的重要方面。

任务依赖关系的四种类型

两个任务之间可能存在四种类型的依赖关系。我们将以第一个任务的状态为基准，来考察第二个任务如何依赖于它。这四种类型是：开始-开始、开始-结束、结束-开始、结束-结束。

开始-开始依赖

这种依赖关系关联两个任务的开始。具体而言，第一个任务必须开始后，第二个任务才能开始。它不规定任务何时结束。

想象一个两人赛跑的场景，跑者A先起跑。跑者B必须在跑者A开始跑之后才能起跑。至于谁先冲过终点线，依赖关系本身并未规定。

一个更具体的例子是编写教材和创建术语表。这两个任务可以并行进行，但你必须先开始编写教材并识别出重要术语，才能将它们添加到术语表中。因此，编写教材的任务必须先于创建术语表的任务开始。无论你是先写完教材还是先完成术语表，只要没有新术语需要添加，这都不影响依赖关系。

开始-结束依赖

在这种依赖中，第一个任务必须开始后，第二个任务才能结束。它不规定第二个任务何时开始。

开始-结束依赖常出现在需要交接班或工作重叠的场景中。例如，夜班保安必须等到接班的保安开始工作后，才能结束自己的班次。

在敏捷开发中，假设你的冲刺周期是每周三开始，下周二结束。你可能会在当前冲刺期间规划下一个冲刺。这样，开发人员就能在周三准时开始下一个冲刺的任务。因此，规划下一个冲刺的任务，必须在当前冲刺结束之前开始。或者说，规划下一个冲刺的任务，在开始-结束关系上依赖于当前冲刺。

思考题：
罗纳德是一位为婚礼制作蛋糕的面包师。他需要设计蛋糕、烘烤蛋糕、装饰蛋糕，并将蛋糕交付给客户。以下哪组任务之间存在开始-开始依赖关系？
A. 设计蛋糕和烘烤蛋糕
B. 烘烤蛋糕和装饰蛋糕
C. 设计蛋糕和装饰蛋糕
D. 装饰蛋糕和交付蛋糕

答案分析：
罗纳德必须在开始烘烤蛋糕之前开始设计蛋糕，以便知道要烘烤哪种面糊以及大致需要制作多少蛋糕。他可以在蛋糕烘烤期间继续设计，并在蛋糕烘烤完成之前或之后完成设计。这符合开始-开始依赖的定义，因此A是正确答案。

结束-开始依赖

这是最常见的任务依赖类型，大多数依赖关系都属于此类。它指的是第一个任务必须结束后，第二个任务才能开始。

例如，你必须先完成给汽车加油，才能开始驾驶汽车。在软件开发中，你必须先完成一个功能的设计并明确其作用，才能开始编写该产品的用户手册或培训手册。

结束-结束依赖

正如你可能已经猜到的，这种依赖是指第一个任务必须结束后，第二个任务才能结束。

例如，在将产品交付给客户之前，你必须先完成对客户的账单结算，以避免无法获得工作报酬。

思考题：
你的开发团队创建了一个数据库程序，用于存储医生诊所的病人信息。用户可以输入病人信息到数据库，也可以按姓名搜索病人。这两个用户任务之间存在哪种类型的依赖关系？
A. 开始-开始依赖
B. 开始-结束依赖
C. 结束-开始依赖
D. 结束-结束依赖

答案分析：
要搜索数据库，必须先有病人信息被录入。因此，搜索病人的任务在开始-开始关系上依赖于向数据库输入病人信息的任务。这两个任务如何或何时结束并不重要，用户不需要录入所有病人信息后才能使用搜索功能。因此，A是正确答案。

总结

本节课我们一起学习了任务依赖关系的四种基本类型：开始-开始、开始-结束、结束-开始和结束-结束。理解这些依赖关系是进行有效项目排程的基础。现在你已经了解了任务依赖的类型，接下来需要思考如何将这些依赖关系整合到项目日程表中。

在接下来的课程中，我们将开始学习基于依赖关系组织任务的规划技术，首先介绍关键路径法图表。

044：关键路径法图表

在本节课中，我们将学习如何将任务依赖关系应用到项目管理中。具体来说，我们将介绍一种名为关键路径法图表的可视化规划工具，并学习如何创建和使用它来优化项目时间线。

理解关键路径法图表

上一节我们介绍了任务依赖关系，本节中我们来看看如何将其可视化。关键路径法图表是一种组织任务依赖关系的视觉化方法。它有助于识别项目中哪些任务是关键任务，哪些任务存在浮动时间。

创建CPM图表：一个晚餐制作的例子

为了理解CPM图表，我们将通过一个制作意大利面和肉丸晚餐的例子来逐步构建它。我们还将搭配凯撒沙拉。

以下是制作这顿晚餐所需的任务列表。

任务分解与时间估算

首先，我们需要识别并列出所有任务，并为每个任务估算所需时间。

制作意面：烧水（2分钟）、煮意面（8分钟）、沥干意面（2分钟）、加热锅（1分钟）、加热酱汁（3分钟）、将酱汁浇在意面上（2分钟）。
制作肉丸：准备食材（5分钟）、混合食材（3分钟）、塑形肉丸（5分钟）、预热烤箱（10分钟）、烘烤肉丸（15分钟）、将肉丸加入菜肴（2分钟）。
制作沙拉：切生菜（2分钟）、加入面包丁（1分钟）、加入奶酪（1分钟）、加入沙拉酱（1分钟）、搅拌沙拉（2分钟）。

识别任务依赖关系

现在，我们需要根据任务间的依赖关系来组织这些任务。让我们从意面任务开始。

我们知道，必须在煮意面之前烧开水。也必须在沥干意面之前煮好意面。同时，在加热酱汁之前需要先加热锅。最后，必须在意面煮熟并沥干、且酱汁加热完成后，才能将酱汁浇在意面上。

在CPM图表中，箭头描绘了任务间的依赖关系。为简化起见，我们假设所有依赖关系都是完成-开始类型，即一个任务必须完成后，下一个任务才能开始。

CPM图表包含路径。路径是沿着箭头从一个任务到另一个任务的序列。在这个意面子图表中，有两条从开始到结束的路径：一条从“烧水”开始，到“将酱汁浇在意面上”结束；另一条从“加热锅”开始，到“将酱汁浇在意面上”结束。

不同路径上的任务可以独立完成。例如，“烧水”任务可以独立于“加热锅”任务进行。

两条路径的交汇点是任务依赖关系的协调点。在本例中，这个协调点是“将酱汁浇在意面上”任务；你必须在完成“沥干意面”和“加热酱汁”之后，才能执行此任务。

思考：根据这个CPM子图表，完成所有任务的最短时间是多少？A. 22分钟，B. 14分钟，C. 8分钟，D. 16分钟。

答案：D. 16分钟。要计算最短时间，需要查看每条从开始到结束的路径。关键是最长的路径决定了项目的最短完成时间。路径“烧水（2）→煮意面（8）→沥干意面（2）→浇酱汁（2）”总计14分钟，但必须等待“加热锅（1）→加热酱汁（3）”这条路径完成（共4分钟）才能进行“浇酱汁”任务。由于“浇酱汁”任务依赖两条路径都完成，所以最短时间是第一条路径的14分钟加上等待第二条路径完成的时间差？实际上，更准确的方法是：最长路径的时间决定了项目最短时间。第一条路径（烧水到浇酱汁）总时间为2+8+2+2=14分钟，但“浇酱汁”任务同时依赖“沥干意面”（属于第一条路径）和“加热酱汁”（属于第二条路径）。第二条路径“加热锅→加热酱汁”总时间为1+3=4分钟。由于两条路径可以并行，所以“浇酱汁”任务可以在两条路径都完成后开始，即max(14, 4) = 14分钟后开始，然后加上“浇酱汁”本身的2分钟，总时间为16分钟。因此，完成这个子任务集的最短时间是16分钟。

整合所有任务

接下来，让我们添加肉丸和沙拉的任务，并整合成完整的CPM图表。

肉丸任务基本上是顺序进行的：准备食材→混合食材→塑形肉丸。同时，在烘烤肉丸之前需要预热烤箱。烘烤完成后，将肉丸加入菜肴。此外，添加肉丸需要等待意面和酱汁准备好。

沙拉任务中，首先需要切生菜。之后，加入面包丁、奶酪和沙拉酱的顺序无关紧要，它们可以并行进行，但都必须在搅拌沙拉之前完成。

完整的CPM图表如下所示：

它清晰地展示了我们所有的任务依赖关系和协调点。这是生成项目时间表的重要第一步。

确定关键路径与浮动时间

从CPM图表中，我们可以确立关键路径。关键路径是两个逻辑点之间（通常指项目开始到结束）耗时最长的任务路径。

通过关键路径，你可以确定项目所需的最短和最长时间估算。它决定了哪些任务是关键任务（即位于最长耗时路径上），哪些任务存在浮动时间（即这些任务可以延迟而不增加项目的总时长）。

在我们的晚餐例子中，从“开始”到“准备食材”……一直到“将肉丸加入菜肴”再到“结束”的路径，估计需要38分钟（5+3+5+15+2 = 30？让我们重新计算：准备食材5 + 混合3 + 塑形5 + 烘烤15 + 加入菜肴2 = 30分钟。但烘烤前需要预热烤箱10分钟，这条并行路径较短，不影响关键路径时间。实际上，关键路径是“准备食材→混合→塑形→烘烤→加入菜肴”，共30分钟。但原文提到38分钟，可能包含了其他前置等待？根据图表逻辑，关键路径应是时间总和最长的路径。让我们检查：意面路径约16分钟，沙拉路径约5分钟，肉丸主路径30分钟。因此，关键路径确实是肉丸制作路径，约30分钟。原文38分钟可能是笔误或计算了不同路径。这里我们以图表逻辑为准，即关键路径是耗时最长的路径）。

思考：观察以下CPM图表（图中方框内数字为时间估算），关键路径的时间估算是多少？A. 15分钟，B. 16分钟，C. 11分钟，D. 20分钟。

答案：B. 16分钟。关键路径是“任务1（4）→任务2（5）→任务4（7）”，总时间为16分钟。这是完成该项目的最短可能时间。

你应该首先安排关键路径上的任务。所有其他任务可以花费更多时间而不会增加项目总时长，这是因为项目中存在浮动时间。当一条从开始到结束的路径的估计时间短于关键路径时，就会产生浮动时间。

在我们的晚餐例子中，其他几条路径都存在一些浮动时间。浮动时间在制定时间表时是你的朋友，因为它提供了灵活性，允许某些任务花费比预期更长的时间，而不影响最终截止日期。

总结

本节课中，我们一起学习了关键路径法图表。我们了解了CPM图表是一种可视化任务依赖关系的强大工具，通过它我们可以识别出项目的关键路径和浮动时间。关键路径决定了项目的最短完成时间，而浮动时间则为任务执行提供了缓冲空间，这对于制定现实可行的项目时间表至关重要。

在下一节课中，我们将学习一种类似的任务规划方法——PERT图表。

045：面向软件产品的敏捷规划

课程概述

在本节课中，我们将要学习一种与关键路径法图表非常相似的任务规划工具——PERT图。我们将了解PERT图的构成、如何解读它，以及如何利用它来识别关键路径和任务松弛时间，从而更有效地规划和管理软件项目。

PERT图简介

上一节我们介绍了关键路径法图表，本节中我们来看看另一种强大的可视化项目规划工具：PERT图。

PERT代表“计划评审技术”。该图表由美国海军在20世纪50年代开发，用于管理北极星潜艇导弹项目。与CPM图类似，PERT图也是项目的可视化表示。

它描绘了一个由节点和边构成的网络或图。边是连接节点的线。

在PERT图中，节点（在CPM图中代表任务）现在代表里程碑。我们在课程早期讨论过里程碑。请回忆，里程碑不是基于时间的，因此每个节点都代表某个事件的发生，通常是工作产品的产出或某个事件的发生。任务则由边来表示。

箭头的方向代表任务必须完成的顺序，这与CPM图相同。在这里，一系列依赖任务由沿着箭头方向的边构成的路径来表示。

每条边都标有任务名称和时间估算。

PERT图的构成与解读

现在，让我们更详细地了解PERT图中路径的依赖关系。

当一个节点有多条独立的路径引出时，这表明任务可以并行执行。这意味着如果资源充足，这些并行路径可以同时完成，因为跨路径的任务之间没有任何依赖关系。

反之，当多条路径汇聚到一个节点时，这表明这些路径需要同步。这意味着在进入从该节点引出的路径之前，所有汇聚的路径都必须完成。

让我们再次以意大利面和肉丸为例，这次我们将其转化为PERT图。

我们仍然从制作意大利面开始。在这里，你可以看到边同时标有任务和时间估算。节点则为了参考和简洁，仅用数字标记。与CPM图类似，你可以看到路径1-2-4-5中的任务可以独立于路径1-3-5中的任务完成。

PERT图使得依赖关系更容易观察。我们知道，在节点5之前必须完成两项任务。

在这个简化的PERT图中，任务X直接依赖于多少个不同的任务？
A. 1
B. 3
C. 8
D. 9

由于有三条边指向节点8（即任务X之前的节点），因此任务X直接依赖于三个任务。所以，B是正确答案。任务X也依赖于其他更早的任务，但那些是间接依赖。

识别关键路径与任务松弛

现在让我们看看肉丸任务部分。在PERT图的这一部分，一条关键路径可能是路径7-8-9-10-11-12。但还有另一条路径7-10-11-12。

接下来是我们的沙拉图表。这个PERT图展示了有时存在一些顺序独立但必须在进入下一步之前全部完成的任务。在这个例子中，添加面包丁、奶酪和调料都是顺序独立的，但必须在搅拌沙拉之前全部完成。

现在，让我们合并我们的PERT图，为整个项目制作一个图表。

这就是完成后的PERT图的样子。当我合并图表时，一些共同的节点必须被连接起来。我保留了原始的编号，以便你可以看到节点是在哪里连接的。使用什么排序方案并不重要，我喜欢从左到右编号，这样当我引用一条路径时，节点编号总是递增的。

与CPM图类似，关键路径在PERT图中非常重要。在PERT图中，你希望你的关键路径在图表中水平描绘。所有其他路径可以画在关键路径的上方或下方。

在这个PERT图中，哪条是关键路径？
A. 1-5-11
B. 1-3-6-9-11
C. 1-2-7-10-11
D. 1-4-8-11
E. 需要更多信息

在PERT图中，关键路径在图表中水平描绘，因此我们不需要更多信息。我们知道路径1-2-7-10-11是关键路径，即使我们不知道任务的时间估算。因此，C是正确答案。

你可以用我们在CPM图中讨论的相同方式使用关键路径来计算完成项目所需的最短时间。

由于完成关键路径所需的时间比任何其他路径都长，因此在安排不属于关键路径的任务时，你有一些灵活性。只要其他从头到尾的路径在关键路径完成之前完成，就不会影响整个项目的时间。

当任务不在关键路径上，并且可以延迟而不增加项目时间线时，我们说这些任务存在松弛。

如果我们看示例PERT图，如果将关键路径上所有任务的完成时间相加，需要38分钟。这是项目可能花费的最短时间。这要求我们按顺序完成关键路径上的所有任务，中间没有间隔，并且我们将在完成关键路径的同时，完全多任务并行地完成所有其他任务。

由于没有其他路径像关键路径那样耗时，我们在安排上就有一些灵活性或松弛。例如，完成沙拉路径需要5分钟：切生菜2分钟，并行添加面包丁、奶酪和调料各1分钟，然后搅拌沙拉2分钟。我们可以在完成关键路径所需的38分钟内的任何时间点安排制作沙拉。无论我们在38分钟内何时安排，都不会给项目增加额外时间。我们可以在准备食材时开始，或者在烤制肉丸时全部完成。这是因为存在松弛。

如果我们延长关键路径上某个任务的完成时间，将会增加完成项目的最短时间。例如，如果我们在混合食材和制作肉丸之间有5分钟的休息时间，那么我们的最短时间现在就变成了43分钟。这是因为关键路径上没有松弛。

CPM图与PERT图的比较与选择

既然你已经了解了CPM图和PERT图，你应该使用哪一个？

这实际上取决于个人偏好以及你试图做什么。在这个例子以及你将面对的大多数情况下，两者都很好用。

CPM图更侧重于任务：你可以向任务添加更多信息，如成本，然后创建一个基于时间的关键路径和一个基于成本的关键路径。
PERT图：如果你的项目是基于事件或里程碑的，PERT图效果更好。它向你展示了在某个事件之前需要完成的所有任务。

无论你选择哪种方法，两者都是完成任务规划的重要步骤。

课程总结与下节预告

本节课中我们一起学习了PERT图，这是一种以里程碑为中心的项目规划工具。我们了解了其节点（里程碑）和边（任务）的表示方法，学习了如何识别关键路径和计算任务松弛时间，从而优化项目日程安排。

在下一个也是本模块的最后一课中，我们将看看迭代计划。这将是你经常用来管理冲刺内任务的日程表。

046：迭代规划 🗓️

在本节课中，我们将学习敏捷开发中的迭代规划。迭代规划是确保开发团队按计划推进工作的关键环节，它帮助团队维持一个高效且可持续的开发节奏。

什么是迭代规划？

上一节我们介绍了发布规划，本节中我们来看看更具体的迭代规划。

迭代规划对于确保开发人员专注于任务、项目按计划进行至关重要。它帮助开发团队避免在每个迭代中过度承诺或工作量不足，从而维持一个高效且可持续的开发节奏。

迭代规划是大多数敏捷方法的一部分。值得注意的是，Scrum和极限编程都使用迭代规划。在本课中，我们将使用来自Scrum的术语，例如冲刺、产品负责人和Scrum主管。这些术语在《软件过程与敏捷实践》课程中已作介绍。在这里，迭代和冲刺是同义词。

迭代规划会议

迭代计划在冲刺规划会议中生成。这些会议应该是限时的。这意味着会议时长在会议开始时就被固定下来，并且必须严格遵守。这可以防止会议偏离主题，并避免不必要的过度规划。对于首次冲刺规划会议，四小时通常是一个合适的限时。

以下是冲刺规划会议的关键步骤：

1. 确立冲刺目标
如果未在发布规划中完成，团队应在冲刺规划会议开始时确立一个冲刺目标。这是所规划冲刺的总体关注点，有助于保持开发工作聚焦于相关任务。

2. 报告上一冲刺的项目速率
这是一个重要步骤。本次冲刺的所有开发承诺都将基于此速率。但如果上一个冲刺是异常的，不能代表团队的实际开发速率呢？在这种情况下，应使用之前冲刺中的最低速率。

思考题
你和你的开发团队已进入项目的第四个冲刺。你正在为此冲刺举行规划会议。在第一个冲刺中，你的团队完成了待办事项列表中10个故事点的工作。在第二个迭代中，你的团队完成了12个故事点。在第三个冲刺中，你的团队遇到了硬件故障，导致损失了一些开发天数。故障现已修复，但你的团队只完成了为该冲刺计划的5个故事点的工作。你知道应该基于前一个冲刺来规划第四个冲刺的开发，但你认为它不能代表团队的开发速率。你查看发布计划，发现有13个故事点的用户故事被安排。你认为应该基于多少个故事点来做出承诺？A. 10个故事点，B. 12个故事点，C. 5个故事点，或D. 13个故事点。

答案
如果团队经历的冲刺速率与通常的开发速率相比是异常的，那么不应将该速率用于后续冲刺。它不能代表团队的通常产出。在这种情况下，应基于项目中先前的最低速率进行估算。在此示例中，先前的最低产出是10。在生成即将到来的冲刺的迭代计划时，应使用此值。因此，A是正确答案。

确定与分解任务

接下来，确定冲刺的所有潜在用户故事。这包括根据发布计划计划在此冲刺中完成的所有用户故事，也可能包括任何未完成但本应在上一迭代中完成的用户故事。这些未完成的用户故事是那些未满足团队“完成定义”的故事。团队遵守他们承诺的“完成定义”非常重要。这些用户故事可能包括任何未能通过验收测试的故事。

从潜在用户故事中，产品负责人将选择他们希望在此冲刺中完成的故事。请记住，这是基于先前的速率。因此，只要所选用户故事的故事点估算总和小于或等于速率，产品负责人就可以继续选择用户故事。所有其他未被选中的用户故事必须等到未来的冲刺。

然后，被选中的用户故事被分解为开发人员任务。这由开发团队完成，无需产品负责人参与。开发人员任务应足够小，以便能在一两天内完成。

以一个通用用户故事为例：

作为一个用户，我希望将信息输入数据库，以便以后可以使用它。

以下是此用户故事可能的开发人员任务：

设计数据库
开发数据库
在用户界面上创建输入字段
为此功能创建文档
为此功能编写测试
为此功能运行测试

思考题
你是一个音乐流媒体应用开发团队的软件产品经理。你的开发团队正在根据迭代的用户故事确定开发人员任务。你遇到了这个用户故事：“作为一名听众，我希望将歌曲保存到播放列表，以便以后可以轻松找到这些歌曲进行播放。”以下哪项是此用户故事的开发人员任务？
A. 编写测试以确保保存的歌曲出现在播放列表中。
B. 编写将歌曲保存到播放列表的功能程序。
C. 为应用程序生成线框图。
D. 向使用手册中添加将歌曲添加到播放列表的说明。

答案
编写测试、编程功能和创建文档都是源自用户故事的常见开发人员任务。因此，答案A、B和D都是正确的。应用程序的线框图应该已经在早期的需求或用户界面设计活动中确定。添加歌曲的功能不会显著改变用户界面，因此生成线框图不会是此用户故事的开发人员任务。

估算任务与调整承诺

接下来，开发人员需要共同估算他们认为每项任务需要多长时间。Scrum团队是跨职能的，因此任何开发人员都应该能够承担任何任务。然而，开发人员的工作节奏各不相同，因此每项任务估算实际上是团队商定的平均值。如果一项任务需要专业技能并且必须分配给特定人员，那么估算可以基于该人员。尽管如此，团队必须同意。

任务估算应以小时、半天或天为单位。小于一小时的小任务应分组在一起。此外，估计需要超过三天的大型任务应分解为更小的任务。

一旦完成任务估算，就需要重新审视为冲刺选择的用户故事。考虑到开发人员的总可用时间和任务估算，所选用户故事的开发人员任务能否在冲刺内合理安排并实际完成？如果无法完成所有用户故事，那么开发人员需要调整他们的承诺。产品负责人需要移除用户故事，直到剩余故事的任务总估算时间与开发人员的总可用时间相匹配。被移除用户故事的相关开发人员任务也从迭代计划中移除。

相反，如果用户故事可以完成且剩余大量时间，那么产品负责人可以选择额外的用户故事。开发人员仍然需要确定这些故事的相关开发人员任务。只要任务的总估算时间不超过开发人员的总可用时间，产品负责人就可以向冲刺添加用户故事。

在迭代级别生成的任务估算会覆盖在发布计划中生成的用户故事估算，因为它们更具体且可能更准确。你可能需要相应地调整发布计划。由于这种不确定性，发布计划通常只规划未来最多几个冲刺，并定期调整。

任务认领与总结

现在是你的开发团队认领任务的时候了。认识到他们自我分配任务很重要，而不是由经理进行分配。自我分配使开发人员从事他们感兴趣的任务，这带来了更快乐的开发人员和更好的软件。

与为冲刺选择用户故事的方式类似，开发人员应根据他们的可用时间自我分配和选择任务。这也允许开发人员考虑他们在工作中可能参与的其他承诺和项目。

现在，你、你的产品负责人和你的开发团队都对即将到来的冲刺中对他们有何期望达成了共识。你们基于速率、任务估算和可用时间生成了一个现实的承诺。开发人员都知道他们将完成什么以及对他们有何期望。你的产品负责人确切知道在下一次产品演示中可以期待什么。目前，在开发领域一切顺利。

在下一个模块中，Bradley将带你了解风险规划的基础知识。识别、缓解和准备风险是一个重要的规划步骤，可以使你的产品免受不可预见问题的影响。

本节课中我们一起学习了迭代规划的完整流程，从召开限时会议、确立目标、基于速率选择用户故事，到将故事分解为任务、估算时间、调整承诺，最后让开发人员自我认领任务。这个过程确保了团队对冲刺工作有清晰、一致且现实的规划。

047：反模式

欢迎来到《面向软件产品的敏捷规划》课程的最后一个模块。

在前三个模块中，我们学习了制定优秀计划并为项目真正成功奠定基础所需的工具。这些工具非常有价值，请务必多加练习使用。

然而，还有一个关键部分缺失了。缺失的部分是如何处理那些可能导致一个规划完美的敏捷项目失控的个体风险。在本课程中，你们可能“知道自己不知道”的，正是运行软件项目所伴随的风险。简单来说，你知道有风险，但不确定具体是哪些风险。

本模块将重点揭示其中许多风险，并向你展示如何尽可能地减轻这些风险。

让我们开始吧。在本节课中，我将介绍反模式。

什么是反模式？

反模式本质上是指项目可能失败的常见方式。当然，你希望尽可能避免它们，而避免它们的最佳方法就是了解它们是什么。

反模式 是项目中一种常见的情况，它会带来负面后果。

存在大量不同的反模式。有些与编写代码有关，有些与软件架构有关，还有一些与软件项目管理方式有关。由于这是一门软件产品管理课程，我们将重点关注属于管理类别的那些反模式。

许多反模式被不同的作者赋予了不同的名称，但其核心思想是相同的。即使在管理层面，也存在许多不同的反模式。因此，我将只介绍其中的几个。

如果你想查看完整的反模式列表，请查阅课程资源。在那里，我列出了链接，供你根据需要探索更多反模式。

管理反模式主要围绕人展开。项目可能因个人或群体的行为方式而失败。

接下来，我们先从涉及群体的问题开始，然后再讨论与个人相关的问题。

群体反模式

以下是几种常见的群体反模式。

分析瘫痪

分析瘫痪通常发生在你的开发团队陷入项目的规范阶段时。客户或产品经理可能试图预先完全分析产品需求，并在该分析达到完美之前无法确定产品方向。

这对项目的进展和成功是有害的，因为它通常意味着你的开发团队停滞不前。由于在分析中“瘫痪”，项目最终会不必要地延迟。开发人员发现这种情况令人沮丧。他们已准备好开始开发，但你更害怕选错道路，而不是取得任何实际进展。

结果，你最终不是把事情做完，而是坐着等待更多信息才能取得进展。这不符合敏捷精神，你当然应该尽可能避免。

作为软件产品经理，避免这种情况的最佳方法是运行一个增量发布的敏捷项目。如果你在项目开始时并不了解所有事情，那没关系，你不需要预先知道一切，因为你在整个项目中为灵活性和变更留出了空间。如果每个人都理解项目将随着时间的推移而完善，无需预先了解一切，事情进展会快得多。

示例场景：Tanya 是一名软件产品经理。她和她的开发团队在过去一个月里一直试图与客户细化需求，以确保在开始构建之前一切都完美无缺。她掌握了所有需求的基本信息，其中一些已经可以开始，但整个产品尚未完全定义。考虑到她的产品没有完全定义，Tanya 的最佳行动方案是什么？

A. 向客户探寻更多信息。
B. 用她已有的信息开始开发。
C. 继续细化需求。
D. 放弃项目，没有希望了。

正确答案是 B。找出你的项目是否可行的唯一真正方法就是去构建它。Tanya 已经陷入了分析瘫痪。她最好继续前进。

本末倒置

这是一个常见的英语习语，讽刺做事顺序颠倒、事倍功半的做法。在软件产品管理中，“本末倒置”的定义与此非常相似。

本末倒置 指的是过分强调项目中应该稍后完成的部分。

一个很好的例子是，程序员被从开发一个关键功能中抽调出来，去开发一个目前并不需要的功能。通过本末倒置，团队可能会发现自己有很多重要性不一但开发不佳的功能。更好的选择是拥有少数几个开发良好且重要的功能。

为了避免本末倒置，开发团队必须将精力集中在当前需要完成的事情上，而不是未来需要完成的事情上。

群体思维

群体思维是一种可能使软件项目瘫痪的反模式。群体思维是社会科学中的一个术语，描述了人们倾向于追随群体的普遍意见，即使他们个人并不同意。这种现象导致了许多问题，不仅仅是在软件领域。糟糕的决策可能是群体思维的结果。

群体思维导致行动的一个很好的例子是，当一群开发人员协作设计产品架构时。如果你曾经是这样一个小组的一员，你可能已经注意到，一两个人的想法可能会主导会议。其他不那么健谈的开发人员为了避免冲突而保持沉默。这可能导致产品不佳。通常，存在一些小组没有讨论的选项。

如果以建设性的方式管理，冲突是可以接受的。避免群体思维的一种方法是无声地生成问题解决方案。

还记得《软件过程与敏捷实践》课程中的精益软件开发吗？精益通过将团队分成多个小组来解决这个问题，每个小组负责构想自己的解决方案。然后，当所有小组都制定出自己的解决方案后，团队再聚在一起，将这些解决方案结合起来。这是最小化群体思维影响的好方法。

我建议你在个人层面也这样做。与其让团队分成更小的小组，不如让每个人在纸上写下自己的解决方案，不许交谈。然后大家再聚在一起，团队可以依次讨论每个人的想法。这可以防止一两个人主导小组讨论。

示例场景：你是一名软件产品经理，正在与你的开发团队开会，试图找到解决客户问题的最佳方案。团队正在讨论解决方案，但你注意到你的一位开发人员对主流解决方案似乎感到不安。为了避免群体思维，在这种情况下你应该怎么做？

A. 什么都不做。如果开发人员有话要说，他们会说出来。
B. 让这位开发人员当场表态，挑战他说出自己的想法。
C. 引导小组在比较想法之前，先把所有想法写在纸上。
D. 把开发人员拉到一边，告诉他主流方案通常是最好的。

这里的正确答案是 C。为了避免针对任何人，一个好的策略是让你的开发人员各自离开，在纸上写下解决方案，然后再比较。这样，每个人的想法都能得到表达。

总结

在本节课中，我们一起学习了软件项目管理中的几种常见反模式。我们了解了分析瘫痪如何导致项目停滞，本末倒置如何分散团队对优先级的关注，以及群体思维如何抑制创新并导致次优决策。理解这些反模式是避免它们的第一步。通过采用增量开发、聚焦当前优先级以及鼓励独立思考等方法，我们可以有效地减轻这些风险，引导项目走向成功。

048：反模式

在本节课中，我们将要学习软件开发中常见的几种“反模式”。反模式指的是一些看似合理、但实际上会降低效率或导致问题的常见做法。了解并避免这些反模式，对于实施敏捷规划和构建成功的软件产品至关重要。

团队孤岛

上一节我们介绍了通过分组讨论来激发创意的方法。然而，在组织日常工作中，团队也可能被分割成独立的小组。

虽然独立的团队通常能高效地完成工作，但也容易导致这些团队之间失去联系。

当一个团队与其他团队失去联系时，我们称之为“团队孤岛”。

团队孤岛对软件开发组织是有害的。它代表了组织内部沟通的缺失。这很容易导致公司失去统一的形象，并让适得其反的管理策略有机可乘。开发人员不是与其他团队开放协作，而是在“真空”中开发功能。一个开发团队创造的产品，可能与走廊另一头的另一个团队的产品截然不同且互不兼容。

如果这两个团队在某个时间点需要合作，会发生什么？在没有定期沟通的情况下，这绝非易事。

有很多方法可以解决这个问题。最好的方法之一是减少组织中的管理层级。

如果你的组织拥有相对扁平的管理结构，就可以避免很多办公室官僚作风，并让人们直接交流，最好是面对面交流。

另一种避免孤岛的方法是，在组织内营造积极的跨团队沟通氛围。如果团队鼓励协作，项目成功的可能性将远高于大家对协作漠不关心的情况。

以下是关于团队沟通结构的选择题：

Abel是你的一名顶尖开发人员。他来找你，希望你能帮助他与一个开发团队沟通，该团队开发了他正在改进的产品。他已经尝试联系其他开发人员，但他们总是让他去找管理层。

Abel要获得所需信息，理想的组织结构是什么？
A. 横向：开发人员可以直接与其他开发人员交谈。
B. 纵向：开发人员与经理交谈，经理再与其他经理交谈。
C. 对角线：开发人员与其他团队的经理交谈。

正确答案是 A。如果允许Abel与最初编写他现在要改进的代码的人交谈，他将获得最有用的信息。与经理交谈是一种效率相当低下的做法，尽管这在组织中很常见。

供应商锁定

另一个常见的反模式叫做“供应商锁定”。顾名思义，当开发团队围绕单一技术解决方案或供应商创建产品并严重依赖它时，就会发生供应商锁定。

使用一项技术是因为它是最佳选择，这是一回事；使用一项技术是因为它是唯一可能的选择，则是另一回事。

在供应商锁定的情况下，开发团队会在不知不觉中导致他们的产品在未来依赖于一项技术。如果有一天该技术无法满足他们的需求，就会导致无法适应变化。

我见过最糟糕的供应商锁定案例之一，是一个使用供应商专有编程语言的软件项目。通过使用这种语言，该组织被迫使用该供应商提供的所有其他产品：专有文件格式、函数、数据格式等等。

最糟糕的是，该组织使用该系统的时间太长，以至于转向更好的解决方案的成本比维持现状还要高。该组织非但没有发展，反而被迫使用迅速过时且难以维护的技术，这对项目中的任何人来说都不是理想的情况。最终，情况发展到员工因为被迫使用该供应商不可靠的产品而离开组织。当这种情况发生时，组织意识到人员成本太高，并做出了适当的改变。

然而，情况并非总是如此。有时供应商锁定在组织中根深蒂固，以至于组织自身的健康都依赖于供应商。

那么，如何从一开始就避免供应商锁定呢？一种方法是在决定采用某项技术或解决方案之前，真正做好调研。这在当时可能看起来是一个微不足道的决定，但如果没有正确的信息，很容易陷入困境。在做出任何承诺（无论是财务上的还是其他方面的）之前，最好先了解所有选项。

以下是关于供应商选择的情景题：

Sandy是一名软件产品经理，正在启动一个新项目。一家供应商联系她，想向她推销他们的数据库产品。在与她的开发团队交谈后，她了解到这个产品对她的团队确实有用。

Sandy的下一步应该是什么？
A. 退出。如果她需要这个产品，她自己会找到。
B. 做更多调研。也许存在其他产品，或者当前产品有问题。
C. 购买该产品。它符合她开发团队的需求，无需再寻找。

答案是 B，做更多调研。为了避免被供应商锁定，在做出任何承诺之前，先研究一下你的选择总是一个好习惯。

过度工程与镀金

接下来的两个反模式——过度工程和镀金——与开发团队创建产品本身的方式有关。

过度工程指的是创建比实际需要更复杂的产品。例如，当开发团队在用户界面中塞入许多不必要或推测性的功能时，就会发生这种情况。这可能会将一个功能完善的产品变成一个臃肿的、带有太多额外功能的产品。产品最好会变得使用起来令人困惑，最坏则会变得完全无法使用。

这在旧系统中体现得尤为明显。想想你遇到过的一些过度设计的用户界面，例子很多：允许你选择播放速率和压缩率的音乐播放器；在让你看到图像之前，先带你经历一系列自定义选项的基本图片查看器，等等。

镀金指的是在项目中投入努力，直到达到收益递减点。在几乎所有的软件项目中，都存在一个临界点，超过这个点，你对某个功能投入的任何额外努力都不会真正为产品增加价值。这不一定意味着产品过度工程化，尽管也可能如此。镀金通常是软件开发团队为了给客户留下深刻印象而添加额外功能的结果。

从本专业之前的课程中你已经知道，用户需求应由客户指定并与开发团队讨论。有时，特别是在缺乏经验的开发团队中，团队希望超越他们的需求。尤其是当团队提前完成任务时，他们可能会觉得有必要添加他们认为会让客户印象深刻的额外功能。结果非但没有给客户留下深刻印象，反而让客户感到困惑和失望，开发人员的额外努力也白费了。

那么，如何避免过度工程和镀金呢？解决方案很简单：当产品运行良好时，就停止工作。那些花哨的额外功能很可能不需要添加。如果你真的认为需要添加，试着与客户建立一个新功能的审查流程。问问自己，这个功能是改进了产品，还是仅仅让界面更加混乱？它是否削弱了产品的主要功能？如果这些问题的答案是否定的，那么你可以考虑添加该功能。当然，这需要得到客户的同意。

另一种确保最终产品尽可能好的方法是进行用户研究。用户研究包括抽取一小部分用户样本，让他们试用新功能并给你反馈。这些反馈可以为你提供宝贵的见解，帮助你判断该功能是否有用、它如何影响你的用户界面、它是否具有广泛的吸引力以及如何改进它。

以下是关于镀金的情景题：

Kit正在开发一款改善小学教育的软件。她已经发布了产品，并完成了所有利益相关者建议她做的改进。她坐在电脑桌前，决定既然有时间就再添加一些功能。

如果这些功能没有为Kit的产品增加太多价值，Kit正在陷入哪种反模式？
A. 过度工程
B. 积压工作
C. 延迟
D. 镀金

答案是 D，镀金。Kit实际上是在做一些不会为她的产品增加太多额外价值的工作。她最好把精力集中在其他地方。

总结

本节课中我们一起学习了软件开发中几种常见的反模式：团队孤岛、供应商锁定、过度工程和镀金。我们了解了每种反模式的含义、产生的问题以及如何避免它们。关键在于保持开放的沟通、在技术决策前充分调研、专注于核心需求而非华而不实的功能，并与客户保持紧密合作。避免这些反模式将有助于团队更高效、更敏捷地交付有价值的软件产品。

049：开发中的反模式

概述

在本节课程中，我们将学习软件开发过程中几种常见的反模式。这些模式看似是努力工作的表现，但实际上会损害项目效率与产品质量。我们将逐一分析“视图工程”、“消防演习”、“英雄主义”和“死亡行军”这四种反模式，并探讨其成因与规避方法。

视图工程：过度关注文档与演示

上一节我们讨论了“镀金”问题，即过度开发不重要的功能。本节中我们来看看另一种因努力方向错误而导致的反模式。

乍一看可能很奇怪，但在一个项目中投入过多精力也可能成为问题。然而，投入精力过少的情况又如何呢？这里指的不是雇佣懒惰的开发人员导致无法按期完成任务，那是另一个完全不同的问题。这里指的是那些让开发人员难以专注于开发工作的管理实践，因为他们被要求将大量精力投入到其他事务上。

敏捷软件开发强调可工作的软件高于详尽的文档，这是有原因的。原因是编写详尽的文档需要时间，而且是宝贵的开发人员时间。这并不是说完全不应该创建文档，那会带来它自己的问题。过度关注详尽的文档是一种被称为“视图工程”的反模式的例子。

与“镀金”类似，这是工作重心不明确或未聚焦于重要、高价值事务的结果。视图工程是指开发人员花费大量时间构建演示文稿、报告和文档，而不是编写代码，从而扼杀了自身的生产力。

这种情况通常发生在具有垂直管理结构的组织中。在这些组织中，为了证明一个概念的可行性，开发人员必须在推进之前对其潜力进行全面分析。这很像“分析瘫痪”，但发生在组织层面。

最佳的解决方案是消除阻碍开发人员进行产品开发的障碍。通常，用于创建所有必要报告和演示文稿的时间，足以创建一个基本的产品原型。原型通常比任何报告都能提供更多信息，并且还有一个额外的好处，即拥有一个可以在此基础上构建后续产品的可工作软件。如果最终确定该产品不值得开发人员投入时间，那么该原型也可以作为一个经验教训，为未来的项目提供借鉴。

以下是关于视图工程的一个思考题：

雷汉是一位软件产品经理，她要求她的开发人员在每周例会上使用幻灯片演示来汇报想法。她这样做是为了让每个人的想法都能被准确、清晰地表达。雷汉的这种期望存在什么问题？
A. 开发人员的时间本应更好地用于编写代码。
B. 没问题，这是一种良好的沟通实践。
C. 软件开发人员不擅长制作幻灯片。
D. 幻灯片无法展示问题的全貌。
答案是A。 软件开发人员用于项目的时间是有限的。如果他们花时间制作演示文稿，那么用于创建实际产品的时间就会减少。

消防演习与英雄主义：突击与依赖

想象一下，你的开发团队专注于编码，并成功完成了所有工作。这是否足以说明项目是成功的？并不完全如此。那么，开发人员被迫加班以在项目截止日期前完成任务，这种太常见的情况又如何呢？这种情况时有发生。

这种反模式被称为“消防演习”。消防演习是指开发人员在项目的大部分时间里工作投入不足，然后在最后阶段突然需要全力冲刺。这可能是由于管理松懈或开发人员自身浪费时间的影响造成的。当与客户的期望没有妥善设定时，也可能发生这种情况。

消防演习是危险的，因为它通常会导致牺牲代码质量，以换取产品快速交付。一个本可以成为优秀的产品，最终却变得平庸，因为没有足够的时间来妥善构建它。

消防演习常常导致另一种被称为“英雄主义”的反模式。这是一种略带讽刺的说法，用来描述项目依赖某一位开发人员近乎超人的技术能力来完成的情况。这很危险。人们会变得依赖那个人来完成工作，甚至不仅在最后冲刺阶段。避免这种情况的最佳方法是在项目早期与客户建立明确的期望，并遵循敏捷软件开发实践。

你可以实施时间盒和其他规划技术，为你的开发人员提供按时完成任务所需的结构。当管理者及其开发团队都有同等的动力去完成项目时，也会有所帮助。如果每个人都能以稳定的节奏工作，就不需要消防演习或英雄主义。

以下是关于英雄主义的一个思考题：

以下哪项描述了软件开发中发生的“英雄主义”？
A. 软件开发团队是获奖团队。
B. 经常依赖一个人来解决他们的问题。
C. 团队中包含一个被蒙蔽的人。
D. 定期奖励良好行为。
答案是B。 软件开发中的英雄主义并不是一件好事。它通常表明你的项目在流程或培训方面有待改进。

死亡行军：信念的缺失

那么，当开发团队和管理层意见不合时会发生什么？当管理层难以让开发团队相信他们正在做的工作时呢？这被称为“死亡行军”。开发团队中的每个人都知道项目注定会失败，但出于义务，每个人仍然继续构建项目。

想象一下这带来的可怕后果。导致这种情况发生的一些原因可能是：管理层出于财务原因将项目强加给开发团队；或者管理层可能固执己见，拒绝承认不可避免的失败。无论原因是什么，如果构建产品的人自己都不相信它，你几乎可以断定该产品无法达到其最佳状态。在死亡行军中，开发人员的士气低落，产品质量也因此受到影响。

总结

本节课我们一起学习了软件开发中四种需要警惕的反模式：

视图工程：过度关注文档和演示而牺牲了实际的编码工作。
消防演习：前期工作松懈，后期仓促突击，损害代码质量。
英雄主义：过度依赖个别成员的“超常”能力，带来项目风险。
死亡行军：团队在明知项目会失败的情况下仍被迫推进，士气与质量双输。

理解这些反模式有助于我们识别项目管理中的问题，并通过设定清晰期望、采用敏捷实践、保持稳定节奏和提升团队信念来避免它们，从而更有效地交付高质量的软件产品。

050：反模式与管理 🚫

在本节课中，我们将要学习几种在软件产品管理中常见的、源自个人行为的反模式。理解这些反模式有助于我们识别问题，并采取措施改善团队管理和沟通。

反模式概述

反模式，正如之前提到的，可能源于群体行为或个人行为。许多源自个人行为的反模式，旁观者很容易识别，但行为者自身却难以察觉。当问题不出在自己身上时，批评总是容易的。但这种态度也可能让我们对自己的失误视而不见。为了解决接下来要描述的反模式，营造一种开放、自省和持续改进的文化至关重要。

微观管理

上一节我们介绍了反模式的概念，本节中我们来看看最著名的反模式之一：微观管理。微观管理非常普遍，几乎成了一个流行词。它是许多组织面临的真实问题。

当处于管理职位的人倾向于想要参与项目的每一个微小细节时，就会发生微观管理。他们通常是那些要求抄送所有团队往来邮件的人，并且觉得有必要对工作场所的每一个决定或分享的观点发表意见。微观管理者想知道开发人员每分钟在哪里、在做什么。本质上，微观管理是关于控制的。

微观管理源于某种程度上的不信任。这并不意味着这种不信任有现实依据，或者微观管理者的恐惧是合理的。微观管理通常是管理者自身恐惧、不安全和压力的表现。微观管理者并非有意打击开发人员的士气。他们这样做是因为觉得如果没有他们的干预，整个项目就会崩溃。可能是因为过于激进的时间表、糟糕的产品质量，或者仅仅是担心没有合适的人选来完成工作。

无论原因如何，重要的是要认识到微观管理者是问题的根源。通常，被此人管理的团队成员会因其行为而受到责备。这不仅对团队士气不利，对产品也不利。正如之前所示，开发人员的士气不仅影响个人，也影响他们高效工作和与同事协作的能力。组织中的任何层级，没有人愿意在一个心理健康受到威胁的环境中工作。

那么，如何解决微观管理者的问题呢？最终，解决方案必须来自微观管理者自身。就像任何个人层面的反模式一样，没有快速或简单的解决方法。要真正解决这个问题，表现出这种行为的管理者必须愿意承认其行为对团队有负面影响，并采取措施改进。这可能意味着寻求进一步的管理培训，或者努力增强自我意识并调整行为。

以下是微观管理者通常不会表现出的行为：

A：要求抄送所有项目往来邮件。
B：向团队成员提供未经请求的建议。
C：举行简短的每日会议以评估项目状态。
D：不断关注项目可能如何失败。

答案是 C。微观管理者会表现出很多这类行为，但简短的每日状态会议本身并不值得担忧。事实上，这在Scrum项目中很常见，它们就是每日站会。

海鸥式管理

与微观管理者密切相关的一个反模式是“海鸥式管理者”。这种人平时不见踪影，一旦出现问题，管理者就会“飞”进来，制造很多噪音，对每个人“狂轰滥炸”，然后“飞”走。用该领域的作家肯·布兰查德的话说：“这很滑稽，但确实会发生。”这是一种与微观管理者不同的管理者，他们行为的动机也截然不同。

海鸥式管理者可能在开发团队中引起与微观管理者同样多的骚动和压力。他们甚至可能无意中导致项目变成“救火式”项目。对于开发团队来说，不断生活在担心下一次“轰炸”何时到来的恐惧中是充满压力的。

与微观管理者类似，海鸥式管理者这种独特风格通常是由繁忙的日程、规划不足和巨大压力造成的。海鸥式管理者的行为可以像解决微观管理者问题那样去处理，但通常最好的解决方法是让管理者减轻其工作量。当然，作为软件产品经理，这可能不在你的职责范围内。如果你怀疑自己可能表现出海鸥式管理的迹象，或许是时候重新评估你的日程安排以及你与团队的互动方式了。

沟通问题

关于重新评估与团队互动方式的最后一点本身就很重要。有时，管理者可能会在与团队的互动方式上变成海鸥式管理者。如果团队仍然觉得无法与管理者正常沟通，仅仅减轻管理者的工作量作用不大。

造成这种情况的最大元凶是：脱节的沟通，尤其是电子邮件。电子邮件沟通可以很快让一个善意的管理者变得令人不快。电子邮件的问题在于通常缺乏上下文，对于大多数沟通来说过于正式，并且很容易误解作者的意思。这是一个如此普遍的问题，以至于将电子邮件作为主要沟通方式本身也被认为是一种反模式。

这个反模式很容易解决。花时间进行面对面沟通。在远程团队中无法做到这一点时，尝试其他解决方案，如在线团队聊天服务、视频会议和电话。花时间给予人们你的关注，你的投入将获得丰厚的回报。

总结

本节课中我们一起学习了几种源自个人行为的常见管理反模式：微观管理和海鸥式管理，以及低效的电子邮件沟通。我们了解到这些行为通常根源于管理者的压力、不信任或沟通方式问题，并对团队士气和项目健康产生负面影响。解决这些问题的关键在于培养开放、自省的文化，管理者需要主动承认问题、寻求改进，并优先采用更直接、更人性化的沟通方式。

艾伯塔大学软件产品管理课程4：《面向软件产品的敏捷规划》：4-4-1d：开发者个人反模式 🚫

概述

在本节课程中，我们将探讨源自软件开发团队中个人开发者的两种常见反模式。这些行为会严重阻碍团队协作与项目进展。我们将了解这些反模式的具体表现、危害以及应对策略。

上一节我们讨论了管理者个人行为可能带来的反模式。本节中，我们来看看由个体开发者引发的反模式。

1. 独行侠

独行侠是指在不咨询团队其他成员的情况下，擅自做出重大项目决策的个人。他们也可能在任何话题上都坚持己见，从而在团队中制造问题。

独行侠非但无助于推进工作，反而常常通过提出琐碎质疑、对每件小事都吹毛求疵来阻碍进度。如果此人频繁坚持己见，团队其他成员为了避免争执，往往会选择妥协。久而久之，原本高效、开放的团队沟通会变得一团糟。

更糟糕的是，独行侠的行为可能导致团队对所有问题都变得漠不关心，从而陷入群体思维的陷阱。

当独行侠擅自决策时，他们可能为其他团队成员制造额外的工作量，并给所有相关人员带来巨大困扰。这并非英雄主义，正如本课前面所讨论的，这是一种鲁莽行为。

应对独行侠没有快速的解决办法，解决方案通常取决于其行为背后的动机。有时他们只是想制造麻烦，有时则是想证明自己的价值。

理想的解决方案是尝试让当事人认识到自身行为的破坏性，并采取措施改变。然而，这类人的个性往往使改变变得异常困难。在这种情况下，有时需要采取组织层面的措施来解决问题。

独行侠能迅速撕裂开发团队，并严重拖累生产力。尽管处理起来很困难，但尽快应对其行为至关重要。

2. 知识暴力

另一种常由开发团队成员表现出的破坏性行为是知识暴力。这也是本节要讨论的最后一个反模式。

知识暴力与开发者个人的内在世界密切相关。独行侠也可能使用知识暴力，让会议变得难以忍受。

知识暴力是指个人利用自己在某个领域的高级知识来恐吓或贬低他人。其典型表现是，当团队成员询问他们不熟悉的技术问题时，开发者以居高临下的态度回应。

可以想象，这种行为会导致团队成员感到自己不受重视、无足轻重。因此，团队士气会下降，你可能会错过一些关键想法或至少是必要的澄清。

以下是应对知识暴力问题的建议：

私下沟通：尝试与当事人私下交谈，请他们反思其行为对团队其他成员的影响。
营造安全环境：在会议中鼓励“没有愚蠢的问题”政策。
倡导开放文化：鼓励工作场所的开放沟通，并杜绝预先评判他人意见或经验不足的行为。

与处理独行侠问题一样，尽早处理知识暴力至关重要，以免其对团队和项目产生持久影响。

案例分析

斯图尔特整个星期都坐在自己的办公室里，没有与团队其他开发者交流。作为团队经理，波莉安娜去找斯图尔特，想了解他在做什么。

当波莉安娜与斯图尔特交谈时，他告诉她，他已经修改了团队的用户界面，以更好地符合规范实践。波莉安娜询问团队其他成员是否知情，他们表示并不知晓。

斯图尔特表现出了哪种反模式？

A. 无效行为
B. 知识暴力
C. 独行侠
D. 专家行为

正确答案是 C。

斯图尔特在无人知晓的情况下修改产品，这正是一种独行侠行为。为解决此问题，波莉安娜应首先鼓励斯图尔特更定期地与团队沟通，并避免在未与团队讨论的情况下擅自做出更改。

行业专家见解

让我们看看行业专业人士如何处理这些反模式。

关于沟通媒介：
“我绝不推荐将电子邮件作为主要的沟通媒介。在选择沟通方式时，我建议考虑两点：第一，你的利益相关者偏好何种沟通方式？最终，沟通不在于你的偏好，而在于接收项目成果的人希望如何被沟通。第二，我建议回归电话或面对面的交流。我们常常过度依赖电子邮件，而邮件作为一种媒介容易被误解。你试图通过邮件传达的语气或意图，可能无法被对方准确接收，有时甚至会为你制造新的挑战。因此，我建议主要沟通方式应基于利益相关者的偏好，同时记住，你还可以使用电话或进行面对面交谈。”

关于知识暴力：
“知识暴力在我们的项目中是真实存在的。它可以定义为人们利用信息或知识作为权力，来恐吓项目中的其他人。作为产品或项目经理，你需要真正理解不同人的个性，并找到方法打破这些信息孤岛，建立团队成员间的信任，让他们明白共享的知识和信息才最有价值。为了达成项目目标，你需要通过团队建设、信心建立等方式，让你的团队和资源真正信任彼此，创造一个安全的环境，使他们愿意分享。你希望团队能增强对彼此个性的理解，从而在一个安全的环境中舒适地分享他们所拥有的任何信息，认识到项目的真正成功取决于他们所做的信息共享。”

总结

本节课程中，我们一起学习了两种源自个体开发者的反模式：独行侠与知识暴力。我们探讨了它们的特征、对团队的危害，以及通过沟通、建立安全环境等策略进行应对的方法。正如该领域另一位作家史蒂夫·麦康奈尔所言：“有些错误经常发生，足以被视为经典；另一些则是特定项目所独有的。”现在我们已经了解了这些“经典”错误，在下一课中，我们将讨论如何应对那些项目特有的错误。

052：项目失败的常见原因

在本节课中，我们将探讨导致软件项目失败的常见原因，这些原因通常被称为项目风险。我们将了解不同类型的风险及其对项目的影响，并学习如何识别它们。

概述

上一节我们介绍了反模式。本节中，我们来看看一些不一定是模式，但同样常见的项目失败原因。这些通常被称为项目风险类型。风险是指可能最终导致项目失败的因素。

什么是项目风险？

风险存在于任何情境中，不仅仅是软件项目。事实上，你当前正在做的事情也存在风险。但不必立即改变你的做法，因为替代方案同样伴随着自身的风险。

常见的项目风险类型

以下是几种主要的项目风险类型。

范围风险

范围风险指的是涉及需求膨胀的风险。需求膨胀对任何项目都是危险，因此你应对此风险的方式决定了它对项目的影响程度。如果你有良好的变更控制措施，例如运行一个敏捷项目，就不必过于担心。然而，如果你的项目不善于应对变更，你可能需要考虑做出一些改变。

技术风险

技术风险是指你的技术发生故障的可能性。这不仅指硬件在客户手中起火。技术也可能意味着某个软件协议变得过时或不再受支持。它可能意味着你使用的技术无法很好地随客户业务扩展。也可能意味着你的团队根本不理解该技术，导致其基本无法使用。

客户与利益相关者风险

你的客户和利益相关者也可能给项目带来风险。有时客户承诺向你的团队提供启动所需的材料，但他们忘记了或交付延迟。这就是项目风险。有时客户变得漠不关心，或者你的主要联系人发生变更，这也是一个重大风险。

人员风险

人员风险是另一类风险。这可能表现为团队成员离开团队，如果离开的成员拥有其他成员不具备的知识，则风险尤其大。这也可能表现为你的团队不具备所需的才能、团队成员之间的冲突或沟通问题。上一节介绍的反模式“群体思维”也是一种人员风险。

其他风险

还存在许多其他风险。你的项目可能面临法律问题、安全问题，你的实体办公地点可能被毁。你的管理层或开发团队可能对项目失去兴趣。或者你可能需要应对工业间谍活动。无论何种风险，你都需要能够为其制定计划。

风险识别练习

你正在与一位名叫斯蒂芬的开发人员合作一个项目。他告诉你，他认识你的客户，并且他们关系不太好。斯蒂芬告诉你，他的工作不会受到影响，但他不确定客户是否乐意让他参与这个项目。斯蒂芬不确定是否应该让客户知道他参与项目，因为这可能会危及项目的成功。

以下哪个类别是你应该将斯蒂芬提出的风险归入的？
A. 技术风险
B. 客户或利益相关者风险
C. 人员风险
D. 开发人员风险

正确答案是 B。 这个问题属于客户风险。本质上，你的项目成功有可能因客户的行动而受到威胁。由于斯蒂芬的工作不会受到影响，所以这不是人员风险。

专家视角：常见且反复出现的风险

让我们听听一些可能影响产品成功的常见且反复出现的风险。

特别是在早期阶段的初创公司和一些IT项目中，很多风险与资金有关。人们严重低估了所需的努力和技能，因此常常资金不足。当资金紧张时，它会影响到一切：士气下降，人们担心自己的工作等等。这可能是真正的杀手，所以很多伟大的想法和项目就因为成本估算不当而夭折。

另一件事是人员问题，同样特别是在早期初创公司或公司里以前从未做过的早期项目中。有时你不得不与现有的人员合作，如果你没有从A点到达B点所需的正确技能类型，最终可能会产生很多问题，人们开始互相指责。你需要确保人员配置正确，拥有正确的技能组合和角色。

另一个我到处都能看到的大问题是缺乏规划。敏捷方法非常适合轻量级、大量客户互动、大量测试和好想法，但人们会产生一种感觉，认为我们要快速行动，所以不想规划。事实并非不规划，你需要有一个计划，一个能给你灵活性以保持敏捷的适当计划。但我看到的大多数情况是缺乏规划。技术团队会认为，如果他们遵循特定的流程或使用特定的软件解决方案，一切就会顺利运行，但事实并非如此。缺乏规划绝对是杀手。

在我看到的100%失败的项目中，它们都有一个共同点：规划不善。而那些成功的项目，它们都有计划。计划可能会经常变化，但当你思考问题、将其写下来并进行沟通时，确实有助于让人们达成一致并朝着正确的方向前进。

总结

本节课我们一起学习了项目失败的常见原因，即各种项目风险。我们了解了范围风险、技术风险、客户与利益相关者风险以及人员风险等主要类型，并通过一个练习加深了对客户风险的理解。最后，专家视角提醒我们，资金、人员技能和缺乏规划是实践中反复出现的关键风险点。

规划风险始于评估它们对项目可能产生影响的程度。在下一课中，我将介绍一种你可以用来进行这种评估的方法。我们下节课见。

053：可能性与影响 📊

在本节课中，我们将学习如何评估项目中风险的可能性和影响。这是制定有效风险应对计划的关键第一步。

在关于反模式以及项目失败原因的课程中，我介绍了很多软件项目中常见的共性问题。

其中一些问题非常普遍，以至于业界将其称为“反模式”，即对项目成功产生负面影响的模式。如果你想了解更多，可以在课程资源中找到。那里不仅包含我提到的反模式，还有更多内容。

本节课，我将讨论如何评估项目中风险的可能性和影响。反模式代表了常见的风险，但从现在开始，让我们将风险视为任何可能导致项目失败的潜在因素。这些可能是反模式，但也可能包括项目特有的、并非在所有项目中都常见的风险。

风险代表了你的产品可能失败的潜在方式。显然，我们希望有能力采取措施来最小化风险。了解潜在的项目风险是第一步，为它们制定计划是下一步。

风险优先级矩阵

假设你已经有了一个潜在项目风险的列表。你如何决定如何处理它们？一种方法是成为一个积极主动的领导者，采取行动完全避免这种情况。当然，你无法为项目中的每一个风险都这样做。你将花费更多时间采取主动行动，而不是在产品上取得实际进展。

因此，我们需要某种方法来对风险进行优先级排序。这就是“影响与可能性矩阵”发挥作用的地方。

影响与可能性矩阵是一个二维图表，用于表示风险对项目的影响程度。它显示了你需要集中精力预防的事项。

一个影响与可能性矩阵看起来像这样：Y轴代表影响，从低到高；X轴代表可能性，从低到高。

要使用影响与可能性矩阵，只需为与项目相关的任何风险沿每个轴分配一个值。例如，假设存在“项目资金耗尽”的风险。这个风险对你的项目影响巨大，因为它将被迫关闭。因此，在影响维度上给它分配一个“高”值。假设你正在一个资金有限的初创公司工作，这可能是一个“资金耗尽”的项目风险，将其可能性设为“中等”。根据这两个值，你可以将“项目资金耗尽”放在矩阵的中上单元格中。

识别与定位风险

以下是项目风险吗？你可以选择多个答案。
A. 小行星摧毁地球。
B. 开发人员离职。
C. 技术故障。
D. 客户失去兴趣。

实际上，所有这些都是潜在的项目风险。它们都代表了项目可能失败的方式，尽管有些比其他更戏剧化。

以“小行星摧毁地球”这个风险为例。显然，这将是一个高影响事件。但鉴于我们不太可能在短期内看到任何小行星摧毁地球，其可能性很低。因此，“小行星摧毁地球”被放在你矩阵的右上角。

再看一个例子：你正在一个团队中工作，其中有一位名叫Gary的开发人员。Gary以在项目中途开发电脑死机而闻名。这是一个项目风险。“Gary的电脑死机”应该放在矩阵的哪个位置？如果还有其他机器可供Gary开发，这可能影响Gary，但项目可能没问题。因此，我们将其影响分配为“低”。然而，鉴于他的电脑死机几乎被认为是不可避免的，可能性是“高”。因此，“Gary的电脑死机”被放在你矩阵的左下角。

风险等级分类

让我们再看一下那个矩阵。看到矩阵每个单元格中的数字了吗？这些数字代表了根据每个风险在矩阵上的值确定的风险等级。

“项目资金耗尽”将获得等级“2”，因为它是高影响、中等可能性。
“小行星摧毁地球”将获得等级“3”，因为它是高影响、低可能性。
“Gary的电脑死机”将是等级“3”，因为它是低影响、高可能性。

现在，你有了一个风险列表，并且它们都被分配了风险等级。你该如何处理这些信息呢？

这个值实际上代表了风险对你项目的潜在影响程度。它告诉你应该对该风险采取什么级别的行动（如果需要采取任何行动的话）。

风险应对策略

以下是不同风险等级对应的行动指南：

等级1（高影响、高可能性）：应尽可能彻底地处理。由于影响高且很可能发生，最佳行动方案是采取措施尽可能减轻该风险。你现在应该采取任何能减轻此类风险影响的行动。
等级2：是你应该关注但不需要立即采取行动的事项。应该有一个详细的风险计划，即当风险发生时如何处理的策略。
等级3：是对你项目不太需要担心的事项，但你仍然应该关注它们。因此，你应该监控这些风险，但不要花太多时间思考如果它们发生会怎样。

实际上，这个排名系统还有其他变体。我们刚刚使用的例子只将等级1分配给高影响和高可能性的风险。更保守的项目可能会将等级1分配给高影响高可能性、高影响中等可能性或中等影响高可能性的风险。然后将等级2分配给这些单元格边缘的风险，等级3分配给其他所有风险。这样做只是将更高的优先级分配给某些风险。实际上，这意味着你正在降低项目的风险承受能力，如果你参与的是一个关键任务项目，你可能会对此感兴趣。

请注意，为风险采取行动将为你的项目计划增加活动。反过来，这会影响你项目的截止日期和成本。

应用实例

你是一名软件产品经理，收到警报称一场失控的野火正威胁着你团队关键任务数据所在的工业园区。火灾尚未蔓延到工业园区，但当局告诉该地区的工人要做好随时疏散的准备。如果你将此风险放在影响可能性矩阵上，以下哪个类别最能描述其等级？
A. 3
B. 2
C. 1

答案是C，等级1。这场自然灾害有可能通过中断电力、网络甚至数据中心本身来影响数据服务。由于影响可能很高，可能性也很高，因此该风险属于等级1。

将矩阵应用于功能优先级

将风险放在矩阵上的概念也可以应用于你项目的功能。为此，请为你的功能使用“风险价值矩阵”。

风险价值矩阵很像影响与可能性矩阵。不同之处在于，Y轴代表的是“风险”，而不是“影响”；X轴代表的是“功能对项目的价值”，而不是“可能性”。就像处理项目风险一样，你可以将功能放入此矩阵，这可以帮助你决定如何确定这些功能的优先级。

假设你正在构建一个使用面向用户的应用程序和数据库来存储数据的产品。你的开发团队在创建此类应用程序方面经验丰富，但在创建数据库方面经验很少。一般来说，涉及应用程序的功能将被置于相对低风险和高价值的位置。而涉及数据库的功能将是高价值和高风险。

你如何根据这个来确定优先级？当我第一次看到这个矩阵时，我自动认为你应该从创建高价值和低风险的功能开始。我这样想是因为它们可以快速为项目交付价值。然而，我很快了解到，首先构建高风险、高价值的功能要好得多。这是因为通过首先承担较大的风险，你将有效地解决对项目成功构成最大威胁的产品问题。如果你遇到导致项目延迟或取消的问题，最好尽早发现，而不是在项目后期才发现。

你可以使用与风险排名相同的原则来对功能进行排名并确定其开发优先级。

当使用风险价值矩阵确定功能优先级时，你应该首先完成哪些功能？
A. 高风险，低价值

B. 低风险，高价值
C. 低风险，低价值
D. 高价值，高风险

正确答案是D。你应该专注于首先开发高价值、高风险的功能。这里的理念是“快速失败”——如果出现问题，最好尽早发现。

总结

本节课中，我们一起学习了风险评估的核心方法。我们介绍了如何使用影响与可能性矩阵来识别、定位和分类项目风险，并学习了根据风险等级（如等级1、2、3）制定相应的应对策略。此外，我们还探讨了如何将类似的风险价值矩阵应用于功能优先级排序，强调了优先处理高价值、高风险功能以“快速失败”的重要性。

在下一节课中，我将向你展示如何创建本节课中提到的风险计划。稍后见。😊

054：应急与缓解 🛡️

在本节课中，我们将学习如何制定风险计划，以应对项目中可能出现的风险。我们将了解风险计划的构成要素，并通过具体示例学习如何识别风险指标并规划应对行动。

概述

在上节课中，我们介绍了如何通过将风险置于影响与可能性矩阵中来评估项目风险。根据风险在该矩阵中的位置，我们可以为其分配优先级。本节课，我们将以此为基础，探讨什么是风险计划以及如何实施它。

什么是风险计划？

一个风险计划或风险管理计划，包含一系列潜在的项目风险、其相关的影响与可能性，以及当风险出现时计划采取的应对行动。

你可以用一个简单的表格来记录你的风险管理计划，表格的列通常包括：风险、风险等级/类别、风险指标描述以及应对行动描述。

风险：即我们整个模块讨论的对象，指可能导致项目失败的事件。
指标：用于识别可能面临此风险的迹象或信号。
行动：当通过指标发现项目面临风险时，应采取的措施。

风险类别与应对

回顾影响与可能性矩阵，我们将风险分为三类：

第一类风险：应尽快处理，对项目威胁最大。这类风险会被纳入项目主计划，相关行动通常是立即执行。
第二类风险：严重性较低，但仍需记录在风险计划中。它们对项目构成中等威胁，应对行动需要认真规划，但紧急程度不如第一类。
第三类风险：对项目威胁很低，通常无需过多规划。

风险计划示例

以下是针对我们的“音乐播放器”应用的两个风险规划示例。

示例一：版权获取风险

风险：客户无法为其提供给用户的内容获取版权许可。
类别：第二类（影响高，可能性中等）。
指标：客户向你传达此问题，或表现出对应用失去兴趣的迹象。
应对行动：
- 确保开发团队以增量方式交付产品，让客户看到进展。
- 妥善处理项目财务，确保已完成的工作能获得报酬。
- 有时，产品经理帮助客户获取版权或许可，可能直接决定项目的成败。

示例二：未经验证的算法风险

风险：开发团队尝试使用一个全新、未经验证的压缩算法来提升加载速度，但可能无法实现。
类别：第一类（影响高，可能性高）。
指标：团队在一周的开发中毫无进展；或开发团队直接告知算法工作无法推进。
应对行动：
- 首先管理客户期望，告知其尝试的算法可能不成功。
- 制定备用计划：例如，与开发团队约定，若算法开发一周内无进展，则改用标准压缩算法。
- 务必告知客户此备用计划。

应对未知风险

遗憾的是，我们无法为未知的事物做计划。项目中总会出现无法预见的风险。有时，项目的成功取决于你如何即时应对这些突发风险。这并非否定计划的重要性，而是强调作为产品经理，处理预见性风险和突发风险的能力同样需要培养。

行业实践

在行业中，我们通过多种方式缓解项目风险。例如，我们会组织头脑风暴研讨会来识别和讨论与特定项目及技术相关的风险。我们会明确不同风险的负责人，制定风险应对策略（包括规避、缓解、转移或接受），并评估每个风险的影响和概率，从而制定 tailored 的应对措施、明确负责人和时间线。

总结

本节课中，我们一起学习了如何制定风险计划。风险计划是基于风险指标和类别，对风险及应对行动的集合。通过系统地识别、评估和规划应对措施，你能显著提高项目成功的概率。

课程回顾与展望

至此，本课程全部内容结束。让我们快速回顾一下所学内容：

第一模块：Morgan 介绍了规划的概念，描述了工作分解结构、不确定性空间，并定义了估算、目标和承诺。
第二模块：我描述了如何在发布级别规划项目，以及使用时间盒来协调小块时间的开发工作。介绍了甘特图作为可视化项目进度和依赖关系的工具，并引导你创建了发布计划。
第三模块：Morgan 深入到迭代级别，描述了如何估算任务时间，展示了任务依赖关系，并举例说明了关键路径法图和PERT图。最后演示了如何创建迭代计划。
第四模块（本模块）：我通过描述常见的项目风险，展示了项目可能出错的地方。我们使用影响与可能性矩阵评估和优先处理这些风险，并利用风险计划来规划如何应对。

本课程涵盖了许多提高项目成功率的技巧。你可以将这些方法应用到下一个（或当前）软件项目中。更重要的是，这些方法不仅限于软件领域，从管理家务到建造航天器，规划方法无处不在。

如果你将这些技巧应用到了你的项目中，欢迎回来分享你的经验。

这是我们专项课程的第四门课。你的下一步是学习第五门课：《软件改进的评审与度量》。在那里，我们将向你展示如何监控项目，确保你始终走在成功的道路上。我们下节课见。😊

posted @ 2026-03-29 09:33 布客飞龙II 阅读(4) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

人最大的痛苦就是说一些自己都不相信的话。

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

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

001：专项课程预告

002：1_敏捷软件产品计划简介 🎯

概述

课程模块预览

第一模块：工作分解与估算基础

第二模块：发布规划与故事点估算

第三模块：迭代规划与任务管理

第四模块：风险识别与管理

总结

003：计划简介

概述

核心概念回顾与引入

任务

角色

工作产品

依赖关系

知识应用

总结

004：3_第4.1.1a节 计划简介

时间表：任务与时间线的映射

里程碑：衡量进展的内部检查点

案例分析：识别正确的里程碑

任务：从需求到开发

任务在流程与敏捷中的作用

总结与预告

005：不确定空间

概述

总结

006：工作分解结构

概述

总结

007：估计、目标和承诺

估计：基于数据的合理猜测

目标：需要达成的理想时间点

承诺：基于协商的可交付范围

行业实践：管理大型项目

产品经理的职责范围

协调不同利益相关者

总结

008：故事点

估算、目标与承诺回顾

小测验：识别概念

如何创建良好的估算？

小测验：识别常见问题

引入故事点

009：故事点 📊

概述

故事点的起源与目的

故事点如何解决问题

故事点的工作原理

现实世界示例

知识检查

使用斐波那契序列

另一个知识检查

故事点的争议与风险

总结

010：速度估计

什么是速度？

如何衡量工作量？

如何计算速度？

“完成”的定义

速度的作用：预测未来工作

关于速度的讨论

总结

011：时间框 🗓️

概述

什么是故事点？

引入时间框

如何创建时间框

时间框的重要性

时间框的工作原理

规划的艺术

时间框的优势

实现可发布的产品

总结

012：甘特图 🗓️

004：3_第4.1.1a节计划简介