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

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

001：艾伯塔大学软件产品管理专项课程介绍 🎓

在本节中，我们将了解艾伯塔大学软件产品管理专项课程的总体介绍。该课程旨在教授如何成功引导软件产品从构思到交付的全过程。

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

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

强大的协作和沟通技能对于复杂软件的开发至关重要，正如它们在我们生活的许多领域一样。考虑到这一点，我们的计算专家团队将为您提供掌握敏捷软件开发所需的过程和实践。我们对软件产品管理流程的现实理解将为您提供直面挑战所需的一切。

我们将教您如何理解和细化客户的软件需求，以及如何将这些需求传达给开发团队。您将学习从监控项目到确保其符合客户需求、遵循项目计划并达到预期质量水平的技术。您将有机会加入一个软件产品管理社区，在那里您可以分享经验并从他人的见解中学习。

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

我很高兴您有兴趣参加我们的专项课程。我们已经尽力使这成为一次有益的教育体验。现在轮到您了，祝您好运。

在本节课中，我们一起学习了艾伯塔大学软件产品管理专项课程的总体目标、内容结构以及学习价值。该课程强调实践技能与理论知识的结合，旨在培养学员成功管理软件产品全生命周期的能力。

002：软件过程与敏捷实践简介

概述

在本节课中，我们将学习软件过程与敏捷实践的基本概念。课程将介绍如何通过结构化的过程和有效的实践来组织软件项目，以实现“正确的产品、正确地完成、正确地管理”这三个目标。

课程结构与目标

我是 Ken Wang，欢迎来到软件产品管理专项课程中的《软件过程与敏捷实践》课程。本课程是专项课程的基础组成部分，也是描绘我们专项课程结构的重要支柱之一。

在上一系列课程的介绍中，我提到开发更好的软件涉及三个目标。这些目标是：正确的产品、正确地完成和正确地管理。我还提到，开发一个优秀的软件产品需要许多人的协同工作。那么，是什么帮助你将目标与人员联系起来呢？答案是过程和实践。

为了避免项目混乱，你需要引入结构和纪律。在本课程中，你将学习如何利用过程来组织软件项目。你还将学习有助于实现更好软件目标的实践。

课程模块介绍

本课程包含四个模块。

以下是各模块的简要介绍：

模块一：软件过程基础。Or Ptzel 将解释什么是软件过程，并描述它如何分解为阶段、活动和任务，以帮助你组织工作。如果你不熟悉软件开发，无需担心，她还将描述制作软件的关键活动。
模块二：软件过程模型。Ra Pette 将描述一系列软件过程模型。你将学习从早期的线性模型到现代的迭代和并行模型。你们还将讨论不同形式的软件原型设计，这可以帮助你通过更精细版本的循环来交付产品。本模块将帮助你从不同的过程模型和原型策略中进行选择，并为你的项目定制它们。
模块三：敏捷实践。Morgan 将回来指导你学习特定的敏捷实践，这些实践往往与现代软件过程配合得最好。她将介绍两种流行的敏捷方法论：专注于开发的极限编程和专注于管理的Scrum。
模块四：精益软件开发。Brad 将讨论精益软件开发的原则，这将是对敏捷原则的补充。精益将帮助你减少项目中的浪费，并提供提高产品整体质量的解决方案。你们还将讨论看板作为一种可视化任务进度的方法。

总结

在本节课中，我们一起学习了《软件过程与敏捷实践》课程的概览。到课程结束时，你将掌握广泛的过程和实践知识库。你将能够将它们应用到你的下一个项目中，以组织人员并开发出更好的软件产品。

003：流程与实践 🧩

在本节课中，我们将要学习软件开发中“流程”与“实践”的基本概念。我们将了解什么是流程，它如何组织工作，以及构成流程的基本元素。课程内容旨在为初学者提供一个清晰、直观的理解框架。

流程概述

上一节我们介绍了在课程中使用流程的原因。本节中，我们来看看流程具体是什么，以及敏捷实践如何与之相辅相成。我还会在本模块中讨论各种软件工程活动。

流程是软件开发的重要组成部分。事实上，流程往往会自然出现。从高层次看，流程将软件产品的开发组织成不同的阶段。通常，你可以将产品视为从一个阶段进入下一个阶段，每个阶段都有特定类型的工作。

正如我们将在本课程中发现的那样，软件开发的过程并非像从头到尾遵循一个食谱。你需要进行改进、优化想法、尝试实验，甚至可能需要回溯，才能得到一个可接受的、可工作的产品。

软件可以持续很长时间并经历许多变更。想想你的智能手机应用需要更新的频率。每次你收到更新应用的通知，那就是产品发布了一个新版本。由此可见，即使在产品初始发布之后，进一步的开发和测试仍在继续。

我们在本专项课程中讨论的许多流程都是生命周期流程。这意味着它们组织了软件从最初构想到最终产品退役的整个生命周期。

然而，流程并不一定代表产品的整个生命周期。在生命周期流程中，可以存在子流程。例如，可以有一个用于查找和修复产品中错误的子流程。

无论是生命周期流程还是子流程，其结构都是相同的。现在让我们来看看这个结构。

流程的结构

流程被组织成阶段。多年来，人们提出了许多不同的生命周期流程模型。对于生命周期流程，根据流程模型的不同，这些阶段可能有不同的名称。这些阶段可以按顺序、迭代或并行方式组织。

以下是生命周期流程阶段的示例：

规格说明：构思产品想法、获取和表达需求的阶段。
设计与实现：进行产品设计和开发的阶段。
验证与确认：评估产品以确保其按预期工作并满足客户需求的阶段。

阶段示例

假设你和你的开发团队受委托为一家大型银行开发数据库。出于显而易见的原因，你的客户非常关注安全性。你和你的团队提出了许多可以集成到产品中的安全功能。

问题：这项任务会发生在软件生命周期流程的哪个阶段？
A. 规格说明
B. 设计与实现
C. 验证与确认

答案：定义将要集成到产品中的功能属于规格说明阶段的一部分。因此，A是正确答案。

流程的进一步分解

现在，让我们将流程分解得更细致。阶段由活动组成，而活动是相关任务的集合。

活动的例子是“创建测试”。所有与创建测试相关的任务都将归入该活动。这些任务可能包括编写测试框架代码，以及设计和编写测试用例。我们将在下一课中详细查看软件工程活动的例子。

正如我刚刚所说，活动是一组相关的任务。那么，让我们具体看看这些任务。

任务：工作的基础单元

无论使用什么流程，任务都是真正完成工作的地方。任务是项目中需要完成的小型、可管理的步骤。它们是完成一项活动，并最终完成流程整个阶段的基石。

所有完成工作的元素都与任务有某种关系。

以下是任务的示例：

编写一段源代码
设计一个功能
编写文档
安装一个库
测试一个功能

任务依赖关系

任务之间可能存在依赖关系。也就是说，一个依赖于另一个任务的任务必须等待那个任务完成。依赖关系意味着任务之间存在必要的顺序。

例如：

你不能遛狗，除非狗系着狗绳。
你不能系上狗绳，除非狗戴着项圈。
因此，遛狗依赖于你系上狗绳，而系上狗绳依赖于你戴上项圈。

或者在软件开发的上下文中：

你无法通过某个功能的测试，除非源代码已经编写完成。
你无法编写源代码，除非该功能已经设计好。
因此，通过功能测试依赖于源代码的编写，而源代码的编写又依赖于功能的设计。

总结

在本节课中，我们一起学习了软件开发流程的基础知识。我们了解到流程将工作组织成阶段（如规格说明、设计与实现），阶段由活动（如创建测试）构成，而活动则由具体的任务（如编写代码）组成。我们还探讨了任务之间的依赖关系如何决定工作的顺序。理解这些基本构件是掌握更复杂开发方法和敏捷实践的重要第一步。

004：流程和实践

在本节中，我们将学习软件工程中流程和实践的基本构成元素。我们将逐一介绍活动、任务、角色、工作产品和资源这些核心概念，并理解它们之间的关系。

概述

软件流程由一系列相互关联的元素组成，这些元素共同协作以完成软件开发工作。理解这些元素及其关系，是掌握任何软件工程方法的基础。

活动与任务

活动是流程中的高层级工作单元，它由一系列更具体的任务组成。任务则是需要执行的具体、低层级的行动。

例如，“设计用户界面”是一个活动，它可能包含“创建线框图”、“选择配色方案”和“设计交互流程”等多个任务。

角色与职责

任务也与角色相关联。角色是一个人承担或扮演的职责。

一些软件工程角色的例子包括：程序员、测试员、首席执行官、客户或产品经理。

一个实际的人可以扮演一个角色，并执行与该角色相关的任务。简而言之，角色执行任务。团队中的每个人在担任某个角色时，都有特定的职责或任务需要执行。

例如，程序员可能承担为某个功能编写代码的任务。测试员可能被分配去测试该功能。而产品经理则可能在功能完成后进行审查，以确保其工作方式符合客户预期。

你可以看到角色如何帮助根据所涉及的团队成员来组织工作。

考虑一个用户可以分享和查看食谱的应用程序。用户可以选择创建带有个人资料的账户或使用访客账户。账户持有者和访客都可以浏览食谱，但用户必须登录其个人账户才能发布食谱。两种类型的用户也可以从主页浏览和搜索食谱。

以下哪些任务可以由访客角色执行？
A. 向其个人资料添加可选信息。
B. 创建账户。
C. 搜索食谱。
D. 浏览食谱。
E. 发布食谱。

如前所述，用户需要登录账户才能发布食谱。因此，选项E不正确。同样，要拥有个人资料，用户需要拥有账户，因此答案A也不正确。指定了两种用户类型都可以搜索和浏览食谱，这意味着这些任务可以由访客角色执行。此外，访客将能够创建账户以成为账户持有者。因此，正确答案是B、C和D。

工作产品

接下来我们将要考察的元素是工作产品。工作产品是任务产生的输出。这个输出可以是开发过程中涉及的任何东西，而不仅仅是最终产品。工作产品确实包括最终产品，但也包括其他中间输出，例如设计、需求、源代码、测试用例和内部文档。

由于工作产品是任务的输出，我们可以说任务产生工作产品。

然而，有时任务也会将工作产品用作输入。例如，为某个功能编写源代码的任务会参考该功能的设计。该设计是先前创建设计任务的输出。因此，任务也使用工作产品。

资源

最后，任何任务要完成，都需要资源。资源是任何能够改进、推进或资助待完成工作的东西。这些可以是时间、金钱、技术、知识或人员等。因此，我们可以说任务消耗资源。

为了更直观地理解这个关系图，让我们看一个例子。假设我们正在开发一个应用程序，客户要求用户能够上传个人资料图片、更改姓名和更新个人描述。这些就是我们的需求。

我们必须做的一项任务是为上传个人资料图片编写测试。包含此任务的活动是“创建测试”。这个任务将由测试员角色执行。该任务消耗许多资源，如时间、金钱和技术。该任务产生的工作产品是测试用例。该任务也使用需求文档作为工作产品，因为你希望验证产品是否符合其中指定的需求。在这种情况下，我们希望测试用户能够上传个人资料图片。

实践练习

你被分配到一个新项目中。在这个项目中，你的团队正在为当地图书馆开发一个新的数据库和借阅系统。它使用一个移动应用程序将书籍借阅到用户的账户。

西奥多是你的开发团队中的一名程序员。他被分配了以下工作：为向数据库添加新书籍编写源代码、建立数据库、为帮助页面编写文本，以及为创建账户执行测试。

这些分配中哪一项是活动而不是任务？
A. 为向数据库添加新书籍编写源代码。
B. 建立数据库。
C. 为帮助页面编写文本。
D. 为创建账户执行测试。

答案B是最正确的答案，因为建立数据库涉及许多任务。西奥多将不得不执行诸如设计数据库、为数据库编写代码、托管数据库以及将当前数据库迁移到新数据库等任务。任务是指像A、C和D中那样的低层级具体行动。在“建立数据库”这个高层级活动中，可能包含许多低层级的任务。

总结

在本节中，我们一起学习了软件流程的核心构成元素。我们明确了活动是高层级工作单元，由具体的任务组成。角色定义了由谁执行任务，而任务会产生或使用工作产品。最后，任何任务的执行都需要消耗资源，如时间、金钱和人力。理解这些元素及其相互关系，是构建高效软件流程的第一步。

005：流程与实践 🛠️

在本节中，我们将探讨如何更有效地运用软件流程，并介绍一系列被称为“实践”的具体战术。我们将了解实践如何为流程提供指导，以及它们如何帮助团队规划、沟通、跟踪进度并最终交付更好的软件。

上一节我们介绍了软件流程的基本概念，本节中我们来看看如何通过“实践”来让这些流程更顺畅地执行。

实践是软件产品经理用来确保流程顺利执行的战术。它们为开发的各个方面提供指导，例如如何安排和组织任务、防止资源浪费以及监控工作产品的开发。

本课程将涵盖多种实践。以下是几个实践的例子：

规划哪些功能应包含在版本发布中。
估算任务的持续时间。
召开简短的每日站会。

这些实践通常被集合成一套“方法论”。方法论是一组实践的集合。基于敏捷宣言的方法论被称为敏捷方法论，其中包含敏捷实践。Scrum 就是一个敏捷方法论的例子。

可以这样理解：敏捷宣言提供了一种哲学理念，而敏捷方法论则提供了具体的指导方针和规则。

无论你使用何种实践，它们的目的都是为项目所涉及的方方面面提供结构。这种结构可以帮助你有效地规划项目、按时交付、改善沟通、跟踪进度，并最终交付更好的软件。

例如，在需求规格说明阶段，有许多实践概述了如何从客户那里获取和表达需求。

在设计与实现阶段，你会看到许多指导设计和规划的实践。

还有更多的实践建议开发应如何进行。这些可能包括如何使你的项目更灵活地应对变更，以及如何跟踪开发进度。这些实践可以确定你的项目是否按计划进行。跟踪能让你尽早知道是否落后于时间表。这些实践还可以展示项目已完成多少以及剩余多少工作。这不仅为你的开发团队提供了信息，也使你的项目更加透明。你可以快速、轻松地向客户展示项目状态，并管理项目范围。

验证与确认阶段也概述了许多实践。许多方法论鼓励测试和反思。这确保了产品按预期方式工作，并且完全符合客户的意图。

现在，让我们通过一个例子来巩固理解。假设你和你的开发团队正努力在开发中实施一些敏捷实践。你选择采用的一个实践是：每两周向客户交付一个可工作的原型以获取反馈。

请问这个实践属于流程的哪个阶段？
A. 需求规格说明
B. 设计与实现
C. 验证与确认

每两周向客户提供一个可工作的产品，是确保团队交付的内容符合客户期望并令其满意的绝佳方式。这被称为确认。因此，正确答案是 C. 验证与确认。

深入到任务层面，有许多实践建议如何有效地安排任务。还有一些实践旨在建立开发过程中所涉及角色之间的有效工作关系。

大多数方法论鼓励并促进客户、产品经理和开发人员之间的开放沟通。开发人员之间的开放沟通可以实现高效的开发，因为期望明确，并且每个人都知道其他人在做什么。

采用良好的实践还将减少资源浪费。这种浪费可能是时间、材料或金钱。有效的规划和沟通可以防止工作被多人重复完成，也可以防止开发人员生产出可能不完全符合客户意图的功能。这有助于保持项目按计划进行，从而有助于控制预算。

流程和实践的一大优点是它们具有灵活性和可定制性。你可以借鉴各种流程和实践的方面，创造出满足你所有需求的东西。它们也可以随着时间的推移而改进和发展。

流程和实践有许多好处，它们是产品经理不可或缺的工具。通过学习许多不同的软件流程和实践，你将能够生成或选择一套适合你和你的团队的良好流程与实践组合。

总结

本节课中我们一起学习了：

我们将流程定义为将软件产品开发组织成不同阶段或步骤的方式。流程可以是生命周期流程（模拟软件产品的整个生命周期），也可以是生命周期流程内的子流程。
生命周期流程被组织成多个阶段，例如：需求规格说明、设计与实现、验证与确认。
每个阶段由相关的活动组成，活动是一组相关的任务，而任务则与角色、工作产品和资源相关联。
敏捷实践是可以在流程中应用的指导方针。它们已被证明能带来诸多益处，例如增强沟通、跟踪项目进度、管理风险以及减少浪费。

在本课中，我们简要讨论了流程中工作是如何组织的。接下来，我们将更详细地研究软件工程活动，以便你能更好地了解整个软件开发过程。

006：软件工程活动

概述

在本节课中，我们将深入学习软件工程活动。我们将了解什么是软件工程活动，并详细探讨在软件开发过程中可能发生的各类活动。理解这些活动将帮助你更好地把握流程在软件开发中的位置及其作用。

什么是软件工程活动？

上一节我们介绍了流程与实践，并定义了“活动”是一组相关任务的集合。本节中，我们来看看软件工程活动的具体内涵。

一个软件工程活动是软件开发中一组相关的任务。每个活动都有其输入工作产品和输出工作产品。你可以将活动想象成一个工厂机器：输入工作产品进入，输出工作产品作为结果产生。

输入工作产品是完成该活动所必需的工作产品。
输出工作产品是在活动过程中生成的工作产品。

示例：一个软件工程活动是为所有功能编写代码。输入工作产品是功能设计和需求，输出工作产品是该功能的源代码。这个活动在你从设计中提取所有元素、实现了功能的所有需求后完成，并输出功能的源代码。

活动示例分析

让我们通过一个例子来巩固理解。假设将“撰写一篇论文”视为一个软件工程活动。

如果完成的论文是输出工作产品，你认为最佳的输入工作产品是什么？
A. 时间和金钱。
B. 关于该主题先前生成的大纲和笔记。
C. 一台电脑和键盘。
D. 一名研究员和一名写手。

分析：

答案A不正确，因为时间和金钱都是资源。它们有助于你撰写论文，但不是工作产品。
答案C不正确，因为电脑和键盘也是必要的资源，但不是工作产品。
答案D也不正确，因为研究员和写手是角色，而非工作产品。
答案B是正确答案，因为关于该主题生成的大纲和笔记是在更早任务中产生的工作产品。它们为你撰写论文提供了所需的信息。

软件开发中的主要活动

现在，让我们逐一审视软件开发中的几个核心软件工程活动。

项目管理活动

项目管理活动贯穿整个开发周期。以下是项目管理包含的主要活动：

创建流程：选择或创建一个流程是管理项目的重要组成部分。
设定标准：为确保团队工作的一致性，需要设定标准。团队需要共同决定开发的各个方面，例如代码规范、文档级别、测试策略以及“完成”的定义。例如，一个开发团队的“完成”定义可能是：源代码按照规范编写、为开发者和最终用户编写了文档，并且经过了测试。
管理风险：通过持续分析和缓解风险来完成，包括潜在的业务、技术、管理、进度和安全风险。风险管理的输入工作产品可能包括历史项目记录、项目估算、软件详细设计和生命周期流程。本质上，项目中任何可能出问题的部分都可以作为风险管理的输入。风险管理的输出工作产品是一个风险计划，该计划会概述潜在风险及其相应的缓解策略。你将在《软件产品的敏捷规划》课程中更详细地学习风险管理。这是一个你应该经常回顾的活动，通过持续审查风险，你可以在整个开发过程中识别并缓解新出现的风险。
执行估算：估算在软件开发中对你来说是一项至关重要的活动。开发时间线基于对完成任务所需时间的估算。当估算偏差过大时，你的进度计划就会受到影响。估算活动涉及的任务包括收集估算数据、计算估算值和评估估算值。估算所需的输入工作产品包括需要完成的任务列表，以及你通常需要了解开发人员完成任务所需的时间（我们称之为任务开发速率）。输出工作产品就是你的估算结果。这些估算结果在你制定进度计划时会作为输入工作产品使用。你将在《软件产品的敏捷规划》课程中获得更多关于估算的经验。
分配资源：为任务分配合适的人员、设备和预算。
进行度量：收集数据以评估项目进度和流程有效性。
改进流程：基于度量和反馈，持续优化开发流程。

其他工程活动（简要提及）

除了项目管理，软件开发还涉及其他关键工程活动，例如需求分析、设计、实现（编码）、测试和维护等。每个活动都有其特定的输入和输出，共同构成了完整的软件开发生命周期。

总结

本节课中，我们一起学习了软件工程活动的核心概念。我们明确了活动是一组具有明确输入和输出工作产品的相关任务。我们重点探讨了项目管理中的关键活动，包括创建流程、设定标准、管理风险和执行估算。理解这些活动是理解如何构建和应用软件流程的基础。在接下来的课程中，我们将继续探索如何将这些活动组织成有效的开发流程。

007：软件工程活动

在本节中，我们将学习软件工程中的核心活动，特别是项目管理与需求规范阶段的关键任务。我们将了解如何分配资源、进行度量、改进流程，并深入探讨需求规范阶段的具体活动。

项目管理活动

上一节我们介绍了软件工程的基本框架，本节中我们来看看项目管理所包含的具体活动。项目管理是确保项目按计划进行的关键。

分配资源

分配资源是项目管理的重要活动。资源是指任何能够推进、促进或资助项目的事物，例如时间、资金或设备。分配资源活动包括规划和安排人力资源，这意味着需要分解工作计划并分配任务。

进行度量

进行度量是另一个重要的项目管理活动，它涉及定义、计算和分析度量数据等任务。度量用于跟踪和评估产品和/或流程。这些度量可以衡量产品中的缺陷密度、团队完成任务的速度、已完成的功能数量等等。你将在关于软件改进的评审和度量的课程中了解更多关于度量的知识。

改进流程

认识到这一点很重要：就像产品一样，流程本身也可以进行改进。对你而言，测试和评审流程与你的开发团队测试和评审产品同样重要。你可以在这里应用一些度量数据的结果，以便在下一次计算时，你的流程能获得更好的评分。

案例分析：凯文的项目管理

凯文是一个开发团队的软件产品经理，该团队正在为本地外卖餐厅开发一个订餐应用。他因流感在家休息了一周。当他返回时，他想知道在他离开期间完成了哪些项目管理活动。

他环顾办公室，看到了一份待完成的任务日程表，以及一份标有昨天日期的风险计划。然后他登录电脑，看到新的任务开发速率已被录入，并且进度跟踪图表是最新的。

凯文需要完成以下哪项活动？
A. 分配资源。
B. 管理风险。
C. 进行估算。
D. 进行度量。

解析：当所有输入工作产品被消耗且所有输出工作产品被生产出来时，一项活动才算完成。迭代日程、风险计划和进度跟踪图表都是项目管理活动的输出工作产品。任务时间估算是进行估算活动的输入工作产品。由于凯文只看到了更新的任务开发速率，而没有看到估算，因此该活动尚未使用其所有输入并产生所有输出。所以，正确答案是 C。

规范阶段

接下来，我们来谈谈规范阶段。这个阶段通常被视为初始阶段。产品需求在此阶段确定，但这并不意味着它只发生在开发初期。规范阶段会经常被重新审视，以更新和改进产品需求，为后续开发服务。规范阶段的活动在关于软件需求和客户需求的课程中有详细讲解。

规范阶段的活动包括：

识别想法或需求
获取需求
表达需求
确定需求优先级
分析需求
管理需求
制定潜在方案

现在让我们更仔细地看看其中的一些活动。

识别想法或需求

识别想法或需求是软件开发中一项非常重要的活动。没有想法，就没有产品可开发。花时间认真思考产品将有助于创造出优秀的软件。

需求相关活动

一旦有了想法，下一步就是处理需求。需求活动有五项：获取需求、表达需求、确定需求优先级、分析需求和管理需求。你将在软件需求和客户需求的课程中更详细地重温这些需求活动。

制定潜在方案

一旦需求就位，你就可以准备制定潜在方案了。

案例分析：咖啡店应用

你是一家连锁咖啡店的产品经理。你的客户希望你的开发团队创建一个应用程序，允许最终用户通过该应用支付咖啡费用。你正在与你的开发团队一起进行制定潜在方案的活动。

以下哪项会是这项活动的输入工作产品？
A. 估算
B. 已定义的度量
C. 内部文档
D. 需求待办列表

解析：你将在开发过程的某个阶段使用所有这些工作产品。估算通常在创建日程时用作输入。已定义的度量在你计算和分析度量时用作输入工作产品。内部文档在开发可执行代码和测试时使用。你将使用需求待办列表来制定潜在方案，因为你需要确切知道你在开发什么。因此，正确答案是 D。

总结

本节课中我们一起学习了软件工程中的关键活动。我们探讨了项目管理的核心任务，包括分配资源、进行度量和改进流程。我们还深入了解了规范阶段，涵盖了从识别想法到制定潜在方案的一系列活动。理解这些活动是有效管理软件项目和确保产品成功的基础。

008：软件工程活动

在本节中，我们将学习软件项目在完成需求规划后，进入设计与实现阶段所涉及的核心工程活动，以及后续的验证与确认阶段。我们将了解产品经理在这些阶段中的角色与职责，特别是如何跟踪和监控开发进度。

🏗️ 设计与实现阶段

上一节我们介绍了项目规划与需求确定。现在，项目已明确，是时候进入下一个阶段：设计与实现阶段。这些活动更偏向于开发人员，因此我们不会深入技术细节。作为产品经理，你需要帮助跟踪和监控此阶段的工作。

设计与实现阶段的活动包括：

设计架构
设计数据库
设计接口
创建可执行代码
集成功能
编写文档

这是你的开发团队大显身手的时候。但在他们开始编程之前，你和团队需要设计产品，这包括设计架构、数据库和接口。然后，程序员才能开始工作，创建可执行代码。

你的团队应定期集成或组合他们的代码，以确保代码兼容性。

最后一项活动是编写文档。你可能会想，敏捷宣言不是说不需要文档吗？宣言确实指出“可工作的软件胜过详尽的文档”。然而，文档仍然是软件开发中非常重要的一部分。

好的文档有助于新成员加入团队，或让开发人员处理他们不熟悉的部分。这类文档称为内部文档。

你的团队可能还需要为最终用户开发文档，例如使用手册或培训材料。这类文档称为外部文档。

作为产品经理，你负责帮助跟踪和监控开发过程。

你的团队刚刚完成了本次迭代的规划，并已开始为产品编写代码。既然规划已完成，你环顾四周寻找可做的事情。你看到桌上有上次迭代某个功能的使用手册，墙上贴着团队决定使用的度量指标列表，邮箱里有老板发来的关于团队资源分配的邮件，书架上则放着最新版本的风险计划。

你决定是时候开始监控本次迭代的开发进度了。

你认为以下哪项工作成果能帮助你跟踪开发进度？
A. 外部文档
B. 已定义的度量指标
C. 已分配的资源
D. 风险计划

答案分析：

外部文档是供最终用户使用的，而非用于跟踪。
已分配的资源用于推进和支持开发。
风险计划在开发开始后非常有用，但不用于跟踪进度。
你的团队决定使用的度量指标对于跟踪至关重要。你必须重新计算和评估这些指标，以确保开发有效且项目按计划进行。

因此，B是正确答案。

🔍 验证与确认阶段

现在，让我们看看开发下一个阶段的活动：验证与确认阶段。这个阶段旨在评估你的产品是否实现了预期功能，以及是否满足客户需求。

与其他阶段一样，验证与确认阶段也需要经常进行，而不仅仅是在产品完成时。你需要持续验证和确认产品，以确保开发方向正确。

验证与确认活动包括：

制定测试流程
创建测试用例
执行测试
报告评估结果
进行评审与审计
向客户演示
进行回顾会议

测试是验证与确认阶段的重要组成部分，涉及许多活动，包括制定测试流程、创建测试用例、执行测试和报告评估结果。这些活动有助于验证产品是否按预期工作。

为了确认产品满足客户和最终用户的需求，你需要完成诸如进行评审、审计和向客户演示等活动。这是你获取反馈以改进产品的机会。如果最终用户或客户不认可你的产品，它很可能会失败。

回顾会议是由你的开发团队进行的活动。这些回顾可以反思产品或开发过程。产品和过程总有改进的空间，回顾有助于找出下次可以做得更好的地方。

📝 总结与展望

如你所见，软件开发涉及许多活动。重要的是要记住，在敏捷开发中，你需要反复经历这些阶段，并且它们不总是顺序进行的。

通过排序并确定何时以及多久重新进行这些活动，你就创建了一个流程。现在，你可以利用刚刚介绍的活动来创建一个适合你团队的流程。

在下一个模块中，你将接触到一些既定的流程模型。

009：线性模型 🧱

在本节课中，我们将要学习软件工程发展史上几种重要的线性过程模型。我们将了解它们如何工作，各自的优缺点，以及它们为何在特定历史背景下产生，又为何逐渐被其他模型所补充或替代。

概述

在上一模块中，我们了解了什么是流程与实践，以及它们如何帮助组织工作。我们还详细探讨了软件工程中的常见活动。在本模块中，我们将后退一步，回顾一些历史上被证明有用的流程，并看看它们是如何演变成我们今天看到的更常见流程的。

就像使用大锤和打桩机的工人一样，并非更先进、更复杂的流程就一定在所有情况下都是最佳选择。了解所有可用的选项及其利弊至关重要，否则你可能会陷入使用不适合当前任务的流程的陷阱。

线性过程模型遵循一个阶段接一个阶段完成的模式，不会重复之前的阶段。产品在设计、开发和发布过程中，不会重新审视早期阶段。在本课中，我们将深入探讨这些线性生命周期过程模型。

理解线性模型

在继续之前，让我们测试一下你对线性过程模型的理解。请从列表中选择线性过程模型。

A. 每个阶段顺序发生，当所有阶段完成后循环回起点。
B. 每个阶段与其他阶段并行发生，直到产品完成，阶段之间或内部没有重复。
C. 每个阶段顺序发生，从不循环或重复。
D. 每个阶段可以重复，直到产品完成。

正确答案是 C。线性过程模型不支持流程阶段内部或阶段之间的循环。允许循环的模型称为迭代模型。线性模型还要求阶段按顺序完成，阶段之间没有重叠。允许重叠的模型称为并行模型。我们将在本模块后面学习更多关于迭代和并行过程模型的知识。

瀑布模型

首先，我们来谈谈你可能听得最多的一个模型：瀑布过程模型。如果你研究过软件工程，很可能听说过它。尽管旧的瀑布模型常因效率低下和限制性强而受到批评，但让我们更详细地讨论它，以便看清它的优势和弱点。

你可能已经在生活的许多方面使用过类似瀑布的流程。本质上，它就是一个基本的线性流程，一件事接一件事地发生。

它之所以被称为“瀑布”，是因为流程的每个阶段都由前一个阶段批准的工作产物来推动。例如，在需求阶段结束时，你会得到一份产品需求文档。这份文档被批准后，就流入下一个阶段——设计阶段。在这个阶段结束时，你将完成一组模型、架构和业务规则。然后，这项工作被签署确认，再流入瀑布的下一个阶段，依此类推。

这个模型允许开发人员快速开始构建产品。它通过早期确定范围并坚持执行，避免了需求变更的问题。瀑布模型非常强调记录需求和架构等内容，以便开发团队对软件达成共同的书面理解。

然而，瀑布模型对变化的适应性不强。也就是说，它不够敏捷。瀑布模型的一个主要缺点是它不允许开发团队审查和改进他们的产品。正如我们之前所说，软件是非常动态的。瀑布模型的设计初衷就不是为了应对中途可能发生的、需要重新审视早期阶段的变化。

因此，存在一些瀑布模型的变体，允许向早期阶段及其活动提供反馈机会，以支持某些变更。但如果你的客户在需求文档批准后需要变更呢？不幸的是，客户直到最后才能看到产品，而这可能是许多个月之后。可以理解，这种缓慢的响应经常导致客户失望。

瀑布模型曾发挥过它的作用，但它无法确保正在进行的工作得到适当验证，这是一个严重的缺陷。

V模型

为了解决这个问题，软件开发的V模型应运而生。它与瀑布模型非常相似，事情按顺序一件接一件地发生。不同之处在于，它强调验证活动，以确保实现与设计行为相匹配，同时也确保实现的设计符合需求。其理念是将每个验证级别组织到相应的阶段，而不是一次性全部进行。

V模型与瀑布模型的区别在于，V模型明确地将自身分为两个分支，因此得名“V”。与瀑布模型一样，V模型从需求开始，流入系统架构和设计。这个分支由V的左侧代表，从上到下进行。在这个分支的末端，重点从设计转移到实现，这是V的底部。一旦实现完成，模型的重点就转移到验证活动，这由V的右侧代表，从下到上进行。

右侧的每个阶段都旨在检查V左侧的对应阶段。以下是一个例子：在V模型的左侧，你的开发团队计划稍后要实现的单元测试。这些单元测试旨在确保你编写的代码确实解决了你试图解决的问题。当进入V右侧的单元测试阶段时，这些单元测试就在代码中运行，以确保在一切编写完成后，所有代码都能正常运行。测试运行完毕且一切顺利后，流程就进入集成测试阶段。这样，V的右侧就验证了左侧。

V模型具有与瀑布模型相同的优点和缺点。它应用起来很直接，但没有考虑到软件开发的重要方面，比如变更的必然性。然而，V模型确实允许开发团队验证流程构建阶段的工作成果。所以我们取得了一些进展，但客户仍然要等到一切完成、产品最终完成时才能看到成品。

让我们通过一个练习来巩固理解。研究我们描述软件开发V模型的图表。如果你处于集成测试阶段，当你运行测试时，你正在验证哪个阶段？

A. 单元测试
B. 编码
C. 高层设计
D. 运行测试

答案是 C. 高层设计。当你在高层设计阶段时，你创建了测试，这些测试随后在集成测试阶段运行。你运行的测试不是来自下一个或最后一个阶段，也不是来自编码阶段。

Sashimi模型（生鱼片模型）

现在我们需要一个流程，允许我们在过程中就与客户互动，而不是只在产品被认为完成时才让客户参与。这就是Sashimi模型（或称“生鱼片模型”）的用武之地。这个模型与前两个非常相似，因为它也是软件开发的线性模型。然而，它也有所改进，因为它在整个过程中为你提供了急需的客户互动。

Sashimi模型的独特之处在于它区分了客户和开发团队。在这个模型中，需要客户在场的任务和仅需要开发团队的任务被明确区分开来。这些客户任务穿插在整个过程中，以便在有意义的时刻收集反馈。

与前两个概念相似，你可能已经猜到我要说什么了。是的，Sashimi模型也遭受与前两个线性模型相同的缺点。它应用起来非常容易，但不能很好地应对变化。

总结

在本节课中，我们讨论了软件开发历史上三个重要的敏捷宣言发布前的流程模型：瀑布模型、V模型和Sashimi模型。它们有共同点，也有各自的差异。

这些模型共同的主要特点是，它们都包含按顺序一个接一个发生的阶段。对每个人来说，下一步的预期都非常清晰。这个共同特征是它们共享优点和缺点的主要原因。它们各自允许开发以一种直接的方式进行，但也极大地限制了项目必须适应流程。

本质上，这些早期的线性过程模型遵循一种软件产品的制造观，即软件是根据特定要求机械加工和组装的。一旦生产出来，产品只需要少量的维护保养，有点像家用电器。因此，重点在于前期正确获取需求，之后不再更改。

然而在现实中，开发软件产品是一项创造性的工作，需要进行实验和不断的返工。此外，在过去，计算机时间相对于人力成本是昂贵的，重点在于使编程等任务对计算机高效，但不一定对人高效。对于软件开发来说，从编写代码到看到结果之间的周期可能长达数小时。这不利于开发人员尝试小型编程实验来快速测试他们的想法。但这确实促使人们专注于第一次就做对，并避免返工。线性过程模型符合这种早期的思维方式。

尽管如此，当为新开发人员记录软件产品的内部结构时，你可能仍然会通过阶段和相关文档以线性方式描述项目，即使它可能遵循了其他流程。这提供了一种秩序的表象，使得新开发人员无需重历整个项目就能初步了解其当前实现。这类似于你在教科书中看到的数学证明和科学理论的简洁、理性版本。

在下一课中，我将介绍下一代的软件流程：迭代模型。在那里，我将告诉你一个名为“螺旋模型”的流程及其优势。我们下节课见。

010：螺旋模型 🔄

概述

在本节课中，我们将学习一种重要的迭代式软件开发过程模型——螺旋模型。我们将了解其基本结构、运作流程、核心原则以及优缺点。

在上一节课中，我们介绍了一些最早的线性软件开发过程模型。我举了两个建筑工人使用不同工具修建铁路的例子，并将其与选择不同软件过程进行了类比。在学习本节内容时，请记住这个例子，以提醒自己这些知识的重要性。

在接下来的几节课中，我将介绍一些迭代式软件过程模型。迭代式软件过程模型允许重复过程的某些阶段，它们是循环往复的。迭代模型建立在之前讨论的线性模型基础之上。它们带来的最大优势是增加了回溯到先前步骤的能力。每一次回溯都是一次迭代，因此称为迭代模型。迭代允许在过程中获得反馈。迭代模型可以被视为真正敏捷实践的先驱，但它们也体现了顺序步骤，让人联想到之前的线性过程。当你在下一个模块与Morgan讨论敏捷实践时，请尝试找出敏捷实践与迭代过程之间的兼容点。

螺旋模型的基本结构

本节中，我将讨论螺旋过程模型。螺旋模型由Barry Boehm于1986年提出，它概述了一个通过重复访问已完成阶段来设计和实现软件系统的基本过程。

在继续之前，我需要提醒你，其中一些内容可能涉及技术细节。如果你发现某个概念需要澄清，请查阅本课的课程资源。在那里，你会找到我将要讨论的所有内容的参考资料。

好的，以下是对螺旋过程模型的简化解释。你可以立刻明白它为何被称为螺旋模型。从根本上说，该模型由四个象限组成。当你推进这个过程时，理念是从一个象限移动到另一个象限。将这四个象限中的每一个都视为一次迭代的一个阶段，其中一次迭代是指完成一个完整螺旋（即所有四个象限阶段被完成一次）的持续时间。每个阶段都包含Morgan在第一模块中定义的活动。

螺旋模型的运作流程

以下是螺旋模型的基本运作步骤：

确定目标与方案：首先，为当前迭代确定目标、需求，并生成解决方案。
评估风险与方案：接着，识别和评估风险，并对这些解决方案进行评价。
开发与测试产品：然后，在本次迭代中开发和测试产品。
规划下一次迭代：一旦获得满足目标的产品，便着手规划下一次迭代。

如果每个象限是迭代的一个阶段，那么完成一次迭代后，你就进入下一次迭代。这就是螺旋模型的基本流程。通过重复这个阶段循环，逐步构建产品。

例如，你可以通过确定客户和用户需求来启动一个螺旋模型项目。然后，提出满足这些需求的潜在解决方案。之后，评估提出的解决方案。接着，构建产品的初始原型，并评审下一次迭代需要完成的工作。这便是一次迭代。

在下次迭代中，你可能再次从定义迭代目标开始，例如为你刚刚构建的原型添加功能。然后，评估这些功能，并着手构建你认为合适的功能。接着，评审下一次迭代需要完成的工作，并继续推进，直到项目完成并令客户满意。

因此，与上一课描述的线性模型不同，像螺旋模型这样的迭代模型倾向于在整个过程中重复某些环节。这意味着螺旋模型允许开发团队在每次螺旋迭代结束时评审他们的产品。这样做可以更好地确保产品是按照规格构建的。

知识检查

Jonathan正在使用螺旋模型构建他的软件。他在使用穿孔卡编程和瀑布模型方面拥有丰富经验，因此螺旋迭代对他而言是一个巨大的改变。他刚刚完成了产品的开发和测试，但不记得模型的下一个阶段是什么。

问题：螺旋模型中，在“开发与测试”之后是哪个阶段？
A. 下一次迭代
B. 规划下一次迭代
C. 产品发布
D. 进一步测试

答案：B，规划下一次迭代。因为螺旋模型是迭代的，你会循环回去，再次开始确定目标并完善设计。但只有在迭代结束时首先规划了设计之后，你才会这样做。

螺旋模型的不变式

尽管遵循螺旋模型的项目在某些方面可能因项目而异，但有六个条件几乎总是不变的。这些被称为螺旋模型的“不变式”。它们由Boehm在其2000年发表的后续论文中首次描述。有趣的是，在大多数情况下，这些不变式实际上也适用于许多其他过程模型。

现在，这些不变式可能相当技术性，因此我不会详细讨论所有六个，而只介绍几个关键不变式的核心概念。如果你想了解每个不变式的更多细节，请查阅课程资料。在那里，你会找到每个不变式的详细描述。

以下是几个核心不变式：

第一个不变式：软件项目的所有工作产品应同时创建。这看似奇怪，但基本理念是，如果不同时定义事物，就会使项目面临风险。这是因为在通常的瀑布方法中，顺序执行意味着仅基于有限的信息量做出决策。
第二个不变式：模型的所有象限都必须被处理，不能跳过步骤。这是因为模型的每个象限都带来价值，如果跳过一个，就会不必要地使项目面临风险。因为你很可能是在对项目做出假设，而假设当然可能是错误的。你不想基于错误的假设来构建项目。
其他不变式：最后几个不变式相当技术性，因此我不会深入细节。本质上，它们说明：实施螺旋模型的每个项目，在任何特定活动上花费的时间量，应基于执行该活动所涉及的风险量。它非常注重确保你的决策基于风险数据。其他不变式还提到，螺旋的每次迭代都应产生一个有形的工作产品，并且过程的重点应放在改进整个过程上。

所有这些不变式共同构建了螺旋模型。这有助于定义模型，但你能看出任何问题吗？

螺旋模型的优缺点

尽管螺旋模型在许多方面明显优于线性过程，但它也有其缺点。

缺点一：规划倾向于在每次螺旋开始时预先进行。根据螺旋的持续时间，这可能使得做出良好估算变得困难。

缺点二：该过程所规定的、以计算方式最小化风险的能力，需要大量的分析专业知识。试想一下，为了确切知道在处理一项活动时花费多少时间是过多或过少，你需要多少数据。这类风险评估任务需要消耗大量资源才能正确完成。

如果你所在的组织使用螺旋模型，很可能你正在处理大型项目，并且拥有多年的经验、数据和技术专业知识可供使用。

总结

螺旋模型是迭代过程的一个很好的例子。它以允许在特定时间间隔修订产品的方式完成工作。与其他过程模型一样，它也有其缺点。但它显然与我们之前看到的模型不同，对吗？

在下一课中，我将讨论统一过程模型。请尝试将本课所学内容与之进行比较。

011：统一过程 🌀

在本节课中，我们将学习统一过程模型。这是一种迭代式的软件开发模型，强调渐进式开发和并行工作。我们将详细介绍它的四个主要阶段：初始、细化、构建和移交。

在上一节课中，我们介绍了螺旋模型的基础知识，讨论了它的优缺点，以及它在软件开发流程演进时间线中的位置。螺旋模型是一种迭代式的软件开发模型，意味着产品是通过一系列重复的阶段构建而成的。这与我们在本模块开头介绍的线性流程模型（如瀑布模型和V模型）形成对比。

本节中，我们将探讨另一种迭代式软件开发模型——统一过程模型，通常简称为统一过程。

正如之前所说，统一过程是一种迭代式软件开发模型。它的基本结构是工作在一系列阶段中，这些阶段会重复进行，直到最终阶段被判定为完成。在大多数统一过程阶段内，开发以小型迭代的方式进行，直到该阶段被判定为完成。通常，当一个里程碑达成时，阶段即被视为完成。

统一过程尽可能强调渐进式开发。它并非在项目初期就确定软件产品的所有需求，而是注重随着时间推移逐步构建产品架构的重要性。架构是构建软件产品所依据的一组设计。因此，在统一过程中，开发团队的重点是开发设计模型，同时构建可工作的产品。

虽然统一过程的一般结构是迭代式构建，但该模型允许一个阶段的任务与另一个阶段的任务重叠。这被称为并行工作。因此，开发人员并非仅仅按顺序经历各个阶段，他们实际上可以同时进行多项工作，例如在设计产品架构的同时开发测试。

杰夫在设计产品架构的同时，也在为他的代码构建测试。当他遇到问题时，他也会偶尔向客户澄清和获取需求。杰夫使用的是哪种软件开发风格？
A. 并行开发
B. 迭代开发
C. 增量开发
D. 同步开发

答案是A，并行开发。 由于杰夫同时参与了开发的多个阶段，我们称之为并行开发。

初始阶段

统一过程的第一个阶段称为初始阶段。这个阶段旨在简短，只需足够的时间来确保你有一个足够坚实的基础以进入下一阶段。事实上，初始阶段是统一过程中唯一一个开发不以迭代方式进行的阶段。如果你的初始阶段很长，这可能意味着你在初始阶段花费了过多时间构建需求。

你在初始阶段的主要目标是判断是否有足够强的商业理由来继续开发。这意味着必须有足够好的财务理由来构建产品。

为了实现这个目标，初始阶段要求创建基本的用例。用例概述了用户与产品的主要交互。在此阶段，你还需要定义项目范围和潜在风险。

如果你想了解更多关于用例以及如何创建它们的信息，请查看关于“客户需求与软件需求”的课程。

在初始阶段结束时，你达成了生命周期目标里程碑。此时，你将获得关于产品可行性的合理描述，并准备好进入流程的下一个阶段。

细化阶段

细化阶段是统一过程中第一个实施小型迭代的阶段，正如本节课前面提到的。这个阶段的目标基本上是创建一个产品的模型或原型，我们将在后续进行完善。（我们将在本模块后面更详细地讨论不同类型的原型。）

目前，此阶段的目的是定义系统架构。开发人员定义在初始阶段构思的需求，并开发关键的架构文档，例如用例图和高层类图。这为实际开发奠定了基础。

请记住，这个阶段允许迭代。因此，在迭代中构建原型可能会在需求和架构模型被认为足够完善可以进入下一阶段之前，经历重新设计。

在细化阶段结束时，开发人员会为下一阶段（构建阶段）制定开发计划。这个计划基本上建立在初始阶段开发内容的基础上，并整合了在细化阶段学到的一切，以便构建阶段能够有效进行。

请记住，在统一过程模型中，开发可以并行进行。这意味着当你开始构建阶段时，你将继续进行在细化阶段所做的工作。唯一的区别是工作的侧重点可能会改变。例如，虽然测试和编程在细化阶段很重要，但它们在构建阶段变得更加重要。同样，风险评估在构建阶段也很重要，但在此阶段的重要性低于细化阶段。

构建阶段

构建阶段非常直接。这是另一个开发可以迭代进行的阶段。它侧重于在细化阶段完成的工作基础上进行构建。这是你产品的核心真正被构建出来，产品变得有生命力的阶段。

在构建阶段，会开发详细的用例来驱动产品开发。这些用例比在初始阶段创建的用例更健壮，能更具体地洞察你的产品应如何创建。

你的产品在整个构建阶段迭代构建，直到产品准备好发布。此时，你的开发团队开始将产品移交给客户和用户。

现在你已经了解了统一过程的初始、细化和构建阶段，让我们测试一下你的理解。

以下哪些描述了细化阶段的主要方面？
A. 为项目确定强有力的商业理由
B. 创建用例
C. 创建用例图
D. 创建类图

正确答案是C和D。 用例图和类图是细化阶段的主要工作成果。这并不是说这些工作成果不会在构建阶段出现，只是在细化阶段更侧重于它们。你在初始阶段为项目确定强有力的商业理由。

移交阶段

在移交阶段，你的产品会进行主要发布。你的开发团队会从用户那里收集反馈。正是在这个阶段，你才能真正看到你的设计与用户需求的匹配程度如何。

通过收集这些反馈，你的开发团队可以对产品进行改进，创建错误修复和其他版本。在你的产品完成一次迭代后，有可能再次循环经历统一过程的各个阶段。这适用于你打算为产品创建进一步的主要版本，并将用户反馈作为影响后续开发计划的手段的情况。

这些循环会重复进行，直到你和你的开发团队准备好发布你的产品。

总结与展望

以上就是统一过程。正如我在课程开头所说，统一过程是迭代流程的一个例子。但正如你在整节课中所看到的，统一过程也是一个并行流程。与需求、设计和实现相关的活动可以同时发生。

总的来说，统一过程更像一台打桩机，而不是一把大锤。对于大型项目来说，这是一个很好的流程，因为产品需要大量的完善才能保持在正轨上。拥有迭代允许你的产品自然成长，而不会受到前期计划的限制。

在下一节课中，我将讨论原型设计，以及原型如何用于驱动软件开发。我们下节课见。😊

012：原型化

概述

在本节课中，我们将学习软件产品开发中的原型化方法。我们将探讨五种不同类型的原型，了解它们各自的目的、适用场景以及如何在实际开发过程中运用它们。理解原型化有助于我们更高效地验证想法、降低开发风险并构建更符合用户需求的产品。

回顾与引入

上一节我们介绍了统一过程和螺旋模型作为迭代与并行流程的例子。本节中，我们将看看一个适用于这些模型，并且在软件开发中极为重要的概念：原型。

原型化并不仅限于特定的流程模型，它作为一种通用技术，在未来的课程中也会频繁出现。我们将要介绍的五种原型类型是：示意型、探索型、抛弃型、增量型和演进型。

示意型原型

我们从最基础的原型开始：示意型原型。这类原型形式非常基础。

以下是示意型原型的常见形式：

可以是画在餐巾纸上的草图。
可以是一个简短的幻灯片演示。
甚至可以是在几张索引卡上画出组件。

无论形式如何，示意型原型的核心目的是使用低保真、一次性的图像来分享一个想法。它们有助于在投入大量时间和金钱开发产品之前，确定系统的外观和感觉。这可以为后续开发节省大量时间。

你可以将示意型原型用作筛选糟糕想法的方式，并作为开发的指南。它们为开发团队提供了创建解决方案的指引，而不是需要边想象边编程。

我个人喜欢在原型中模拟计划实现的功能。我最喜欢的方法之一是在绘图软件中勾勒关键功能，然后使用幻灯片编辑器将它们串联起来。这样，原型就能以更少的额外精力，成为产品外观的一个更真实的示例。

你也可以用画在纸上的功能实现类似效果。当最终用户选择某些元素时，你可以通过替换一张“纸屏幕”来演示想法。这种技术通常在时间紧迫、只需要一个基本概念来表达观点时使用。

这个概念可以发挥到极致。有些原型甚至通过让人类在幕后控制系统功能来“伪造”其功能，就像电影《绿野仙踪》中幕后的巫师一样。我曾在一个项目中看到这种方法取得成功，该项目以设备间的无线通信为关键功能。编写允许用户实际无线通信到另一台设备的代码需要很长时间。因此，开发团队发挥创意，在每个设备上运行一个幻灯片程序。当一台设备向另一台发送数据时，开发人员会巧妙地推进另一台设备上的幻灯片。开发团队的时机把握得恰到好处，看起来数据确实是在两台设备之间传输。

你大概能明白为什么示意型原型如此常见了。它只需要很少的时间就能勾勒出功能集，并能让你很好地了解产品完成后的样子。

探索型原型

如果你有更多时间，并且希望对产品的外观有更全面的了解，一些团队会转向我们所说的探索型原型。

探索型原型允许你专注于产品的外观、感觉以及构建该产品所需的工作量。你会编写可工作的代码，以便实际了解什么是可行的，并完全预期在从过程中学习后抛弃这个工作成果。这种方法昂贵吗？当然。但这比后来才发现产品解决方案根本不可行要好。

探索型原型背后的通常动机是产品开发者希望研究某个产品想法的可行性。这不再仅仅是看产品的外观，而是关于开发产品的可实现性，或者在投入更多精力之前产品可能有多有用。

抛弃型原型

任何产品的第一个版本，或者说几乎所有事物的第一个版本，通常都存在各种问题。既然如此，为什么不从头开始构建第二个版本，并抛弃第一个呢？你构建的第一个版本就是所谓的抛弃型原型。

你应该知道，第一个版本并非一无是处。从中学到的许多有用经验和需要避免的问题可以应用到第二个版本中。抛弃型原型让你有机会从过去的错误中学习，这使你有机会让你的发布软件产品看起来比从第一个版本不断演进而来更加稳固可靠。

增量型原型

卡莉刚刚构建了她的产品的第一个迭代版本，现在有了一个第一代可工作的产品原型。她打算在后续的增量中扩展这个原型。测试用户对初始原型提出了批评。在看到产品设计后，他们建议采用一种不同的方法，该方法会用到一些已经构建好的功能。卡莉使用的是哪种原型化方法？A. 可工作型 B. 示意型 C. 抛弃型 D. 增量型。

答案是 D，增量型原型。卡莉从一个可工作的原型开始，后来进行了扩展。初始原型是编码并保留的，所以它不是抛弃型原型或示意型原型。

希望你不会最终得到一个非计划内的抛弃型原型。我刚才描述的三种原型类型，最终都不会直接用于产品的最终版本。那么，在产品实际开发过程中重用原型阶段完成的工作，难道不合理吗？这就是增量型和演进型原型发挥作用的地方。它们让你在原型化阶段的努力能够延续到最终产品中。

关键思想是为每个连续的原型都拥有可工作的软件，其中任何一个都可以作为你软件产品的一个版本发布。当你创建增量型原型时，你一次一个增量地构建和发布你的产品。

增量型原型分阶段工作，基于一个优先级排序系统。这意味着你评估系统的每个组件并为其分配优先级。基于这个优先级，你然后从头开始开发产品。你会从最重要到最不重要地开发你的产品。

所以，你根据必须做、应该做和可以做来为软件产品的功能分配优先级。你将核心功能分配给“必须做”优先级，然后将所有支持产品但并非绝对关键的功能分配给“应该做”。其他所有看起来像是额外功能的东西则分配给“可以做”优先级。

基于这些评级，你将从分配给“必须做”优先级的功能开始开发你的产品。由此产生的软件产品包含核心功能，可以作为增量型原型发布。然后，随着资源允许，你开发“应该做”优先级下的功能，然后是“可以做”下的功能，从而产生一个功能更全面的增量型原型。

举个例子：你正在开发一个消息应用。首先，你希望你的用户能够通过应用相互交谈。任何与此相关的功能，比如集成查找其他用户、消息发送或接收功能，或文本编辑，都可能是你的最高优先级。因此，这些功能将被分配给“必须做”优先级。

你可能会想象用户希望能够添加个人资料图片或发布状态更新，也许还能向人群组发送消息。这些功能将被视为“应该做”的功能。任何像能够更改消息字体、向其他用户发送自定义绘图或发布链接等功能，可能会被分配给“可以做”。

有了所有这些，剩下的就是构建你的应用了。由于你对产品功能进行了优先级排序，你可以轻松地规划和安排你的开发。事实上，这种对功能进行优先级排序并按照计划工作的基本概念，是你在敏捷软件规划课程中将会反复看到的概念。

增量型原型知识测试

你刚刚学习了增量型原型。让我们测试一下你的知识，看看你记住了什么。是什么将增量型原型与示意型、抛弃型或探索型原型区分开来？你可以选择多个答案。

A. 增量型原型采用优先级排序系统。
B. 增量型原型在创建后会被丢弃。
C. 增量型原型不包含任何代码。
D. 增量型原型可能包含最终产品的可工作软件。

正确答案是 A 和 D。增量型原型与我们之前讨论的其他原型不同，因为它允许你的开发团队创建一个潜在可发布的产品。这是通过开发那些已经使用优先级排序系统确定优先级的功能来实现的。

演进型原型

我要讨论的最后一种原型类型是演进型原型。在增量型原型中，你从一组核心功能开始，并随着时间的推移添加新功能。在演进型原型中，你从所有功能的基本形式开始，并随着时间的推移改进或演化它们。无论哪种情况，最终产品都是一个功能丰富的产品。

让我们用我之前概述的消息应用示例来比较一下。在增量型原型中，我们使用优先级排序系统对软件产品的功能进行优先级排序，然后构建包含从最重要到最不重要功能的连续增量型原型。

在演进型原型中，你将拥有所有功能的早期版本，并通过不断完善这些功能直到它们完全成熟来构建连续的原型。例如，后期的演进型原型可以使现有功能更易于使用或更灵活。

以消息应用中的添加个人资料图片功能为例。最初，用户可能必须指定要添加到个人资料的图片路径，这不是一种非常高效的方式，但它能工作。在另一个原型中，开发者可能允许用户从可用照片的下拉菜单中选择照片。更好一点，但在下一个原型中，你可能会想象系统允许拖放功能。通过这种方式，你的产品从一个基本的工作原型演变为功能丰富且健壮的产品。

增量型和演进型原型都是制作可工作软件的方法，这些软件可以定期展示以获得进一步的反馈。在实践中，你可以混合使用这两种方法。对于你的开发团队来说，看到产品随着时间的推移逐渐成型，是一个真正的士气提升。

原型与流程模型的结合

好了，现在你知道了一些不同类型的流程。现在，回想一下你在前几节课中学到的关于螺旋模型和统一过程的知识。你能想象原型如何融入这些模型吗？

在螺旋模型中，想象一下你会从哪里开始。通常起点是创建一个原型，对吧？你可能会通过螺旋模型的第一次迭代，仅仅创建一个示意型原型。你可以在纸上涂鸦几幅画，了解你的系统将如何工作。对于统一过程的初始阶段，不也可以这样说吗？通过创建原型，你可以更好地可视化你的产品功能，从而根据产品可能的样子做出功能决策。

但这还不止。我敢打赌你已经想到了将示意型原型与增量型或演进型原型结合的可能性。这很有道理，对吧？你的第一个版本只是写在几张纸上的想法。然后，为了进一步测试你的想法，你勾勒出一些关键功能并开始构建。不久之后，你最终可能会得到一个原型。然后，你可以将该原型带给客户或潜在投资者，以证明该产品在概念上是可行的。这确实是任何类型原型化背后的核心思想：获取对你产品版本的反馈。

你可以从花费最少的时间开发初始原型开始，以最有效地利用你的资源。

总结

本节课中，我们一起学习了软件产品开发中的五种原型化方法：示意型、探索型、抛弃型、增量型和演进型。我们了解了每种原型的目的、特点以及它们如何帮助我们在不同阶段验证想法、管理风险并逐步构建出功能完善的产品。原型化是连接创意与可交付产品的重要桥梁，灵活运用这些方法能显著提升开发效率和产品成功率。

软件产品管理课程2：《软件流程与敏捷实践》：2.2.5：持续交付

在本节课中，我们将学习持续交付的概念。这是一种旨在通过自动化构建、测试和发布流程，来频繁、可靠地交付软件的方法。我们将了解它如何融入迭代式开发流程，并探讨一个著名的实践案例：微软的每日构建。

在上一节中，我们介绍了原型设计在软件开发中的作用。本节中，我们将通过“铁路建设”类比中的“道钉驱动机”元素，来完善我们对软件流程演进的理解。

在增量或演进式原型设计中，产品会随着时间的推移而不断完善。你从一个基础产品开始，观察其发展。随着时间的推移，会构建出连续的原型。通常，这些原型会发布给客户以获取反馈。

然而，这种“发布”的概念相当宽松。构建代码并将其集成到可运行的原型中可能需要大量手动工作。一个在内部运行良好的原型，对客户来说可能仍然无法工作。他们可能使用了未经测试的设备，或者某些细节可能被忽略了。

避免这些疏忽的一种方法是自动化项目的构建和集成环节。这就是持续交付的用武之地。顾名思义，它允许开发人员持续地交付产品。在开发过程中，每当开发人员提交代码变更，它都会被自动构建、测试、集成，并准备好发布。从做出变更到准备好发布之间的时间可以非常短，因此任何问题都能立刻被发现。

持续交付让你随时准备好发布产品，但如果你觉得原型尚未就绪，并不强制发布。原型发布会被放置到针对不同受众的特定渠道或流中。这样做是为了确保你的持续发布在面向公众发布之前经过了适当的测试。

以下是常见的发布渠道示例：

开发人员渠道：用于开发人员生成的日常构建版本，但尚未准备好广泛使用。
测试渠道：用于为公司内部小组创建的原型。
稳定渠道：面向核心用户的发布。

开发人员可以通过从每个渠道接收反馈来深入了解他们的产品。

持续交付的实践与统一过程等迭代式流程模型非常契合。让我们看看它是如何工作的。回想一下统一过程由并行工作的不同阶段组成，这些阶段是：初始、细化、构建和移交。与持续交付最相关的阶段是构建阶段。

你可以通过一系列短迭代来持续交付产品。产品随着时间的推移迭代构建，并逐步成型。在任何给定的迭代期间，你的开发团队可能正在构建下一个用于发布的原型，这可能包括许多活动，如详细设计、编码和功能测试。

持续交付也可以在统一过程的细化阶段使用。在细化阶段，会进行高层产品架构设计和测试编写。

为了支持持续交付，你可以使用自动化工具。这些工具可用于构建和集成代码、运行测试，并将产品打包成可发布的形式。对于代码的自动化测试，一个最佳实践是在实际编写代码之前先编写测试。这种方法被称为测试驱动开发。它确保你实际上在解决正确的问题并实现想要的功能。最初运行这些测试时，它们会失败，因为相应的代码还不存在，但这没关系，因为代码被编写后，测试最终应该会通过。

随着代码的编写，功能开始在产品中成形。持续交付确保这个过程一直在发生。因此，如果在这个过程中没有任何环节出错，那么在任何时候都应该有一个准备好分发的原型。这个原型应该可以供最终用户试用。当然，对于任何系统，当最终用户看到你的产品时，你以前从未注意到的错误就会开始浮现。从用户那里接收反馈是一个持续的过程。你需要从中学习，并修复他们指出的错误。

持续交付的实践旨在拥有一个可发布的原型，本质上是每次迭代结束时的产品。这具有巨大的优势。如果你在迭代结束时放弃项目，你仍然会有一个可发布的产品。如果资源耗尽，你甚至可以在没有完成所有计划功能的情况下发布产品。除此之外，你的产品质量实际上会得到提高。每次迭代都将你的代码集成到一个更大的产品中，这确保了所有功能都能在小范围内正常工作。这解决了许多如果你试图一次性构建、测试、集成和发布一个大型产品时会出现的问题。

现在，让我们通过一个选择题来巩固理解：
Howey和他的开发团队正在构建支持基础设施，以实现其他开发人员组装的产品原型的持续交付。他已经设置了自动化工具来构建和集成代码、打包产品，并将产品安装到测试环境中。在这个基础设施中，他还需要自动化工具来做什么？
A. 制作原型
B. 进行详细设计
C. 编写代码
D. 运行测试

答案是 D。在这些可能性中，制作原型、进行详细设计和编写代码不属于持续交付的范畴（如果它们能被自动化的话）。然而，自动化测试是持续交付的一部分。

让我们看一个持续交付的实际例子：微软每日构建。在其中，构建阶段的每次迭代被安排为一天，因此称为“每日构建”。每日构建最重要的部分就是“每日”。微软每日构建的整个要点是确保你的程序员在每次构建活动开始时保持同步。通过遵循一个流程，让开发人员在每天结束时将他们的代码集成到更大的系统中，你可以确保没有人偏离正轨太远。

为了控制这一点，微软使用了持续集成系统。如果你以前没听过这个术语，没关系。它的意思是，当开发人员编写了一段代码，并希望与团队中的其他人远程共享该代码时，该代码必须首先经过一个自动测试过程。这确保了它能与整个项目协同工作。这对你的团队影响巨大。如果你的所有开发人员都步调一致，他们可以很容易地看到他们的工作如何融入整个项目，同时也能看到他们的工作如何影响团队的其他成员。这不仅保持了开发人员的士气，也提高了产品的质量。

每日构建通过让开发人员能够在错误成为真正的问题之前捕获它们来实现这一点。如果你的一个开发人员向系统推送了一段代码并且测试失败，那么你立即就知道是哪段代码出了问题。或者，如果你尝试运行产品但它不工作，你就知道问题出在之前构建中集成的某些东西上。因此，在这种方式下，错误检查在每日构建中变得极其容易。对于一个大型产品，自动化测试将在夜间对当天的构建版本运行。第二天早上，开发人员可以看到这些测试的结果，并决定修复什么。因此，微软每日构建为你的团队提供了快速行动并在错误成为大麻烦之前捕获它们的机会。通过使用自动化，你也让开发团队的工作变得容易得多。这就是微软每日构建的概要。

现在你已经了解了持续交付和微软每日构建，让我们看看你学到了什么。通过另一个选择题来测试一下：
Thomas 是微软的一名开发人员。他刚刚花了一整天时间编写将成为 Windows 操作系统下一个版本一部分的代码。在一天结束时，他将他的更改上传到服务器。什么原因会导致更改不被测试？
A. 他的代码不工作
B. 他的代码无法构建
C. 产品中的其他代码不工作
D. 产品中的其他代码无法构建

在这些可能性中，无法构建产品会严重阻碍测试。能够构建但不工作的代码仍然可以被测试。所以答案是 B 和 D。

好的，本节课的内容就到这里。让我们回顾一下讨论的内容。

我首先介绍了持续交付，它可以被纳入像统一过程这样的迭代流程中。持续交付用于发布增量或演进式原型。

然后我讨论了微软每日构建作为持续交付的一个例子。

因此，像统一过程与原型设计和持续交付这样的组合，就是我们的“道钉驱动机”。对于大型长期项目来说，它是一个极好的工具，在这些项目中，产品质量可能受到开发团队错误更改的严重影响。它显然是一个比瀑布过程等更健壮得多的流程，只是别忘了它并不适合所有情况。在某些情况下，特别是在小型项目上，建立所需基础设施所花费的时间可能超过其价值。这就是为什么我也谈到了软件世界的“大锤”——瀑布模型、V 模型和 SAFe。它们都非常重要，尽管它们不如螺旋模型和统一过程等后期模型健壮。即使是那些流程，对于一个真正庞大的项目来说也可能过于简单。

我希望你对这些流程保持开放的心态。我不希望你学完后认为迭代或并行的软件流程模型是软件产品管理的最佳且唯一的工具。每种工具都有其应用场景，作为软件产品经理，由你在正确的情境中应用它们。更重要的是，我在本模块中提到的所有流程并非必然完全相互独立。你可以合理地整合每个流程的各个方面来创建你自己的流程。做对你和你的项目最有效的事情。不要觉得你必须适应别人创造的模具。

例如，如果你喜欢在迭代周期中测试代码的想法，但你认为不需要在每次迭代开始时重新审视设计，那么请务必做对你最有效的事情。

软件产品管理课程2：《软件流程与敏捷实践》：2.3.1：在流程模型中使用敏捷

在本节中，我们将深入探讨敏捷实践，并分析它们如何与之前介绍的各种软件流程模型相结合。你将了解哪些模型更兼容敏捷思想，以及为什么。

在课程进行到目前阶段，你已经研究了许多不同的流程模型。在第一模块中，我们也介绍了采用敏捷实践的一些动机。现在，我们将更深入地探讨一些敏捷实践。这些实践在你作为软件产品经理工作时会经常用到。

如果你参加了先导课程，会记得我们讨论过《敏捷宣言》。这份宣言概述了软件开发的四个核心价值以及应遵循的12条原则。如果你没有学习先导课程或需要复习，可以访问相关课程或通过课程资源中的链接阅读《敏捷宣言》的内容。

首先，我们来回顾一下前几课中涉及的一些术语。

流程：是你用来将开发组织成不同阶段的模型。
实践：是你可以用来帮助管理和跟踪开发的技术或行动。
方法论：是定义好的一组实践。

基于《敏捷宣言》的实践和方法论，被称为敏捷实践和敏捷方法论。

现在，我们来看看敏捷原则如何与你上一个模块中研究过的一些流程模型相关联。

《敏捷宣言》中涵盖的原则之一提到了“早期和持续交付”。让我们尝试将此原则应用到你在上一模块中研究的线性生命周期流程模型中，它们分别是瀑布模型、V模型和Sashimi模型。

你会发现，在这些模型中，产品只有在完整的开发过程结束时才真正交付给客户。这既不是早期集成，也不是持续交付。

瀑布模型也严重依赖文档。如果你还记得，《敏捷宣言》的核心价值之一指出，全面的文档不是敏捷开发的首要任务。此外，在瀑布模型中，一个阶段的主要输出文档需要在进入下一阶段前获得批准。这种要求合同或签字的做法也不是敏捷开发的重点。因此，瀑布流程模型与敏捷实践不太兼容。

V模型与瀑布模型有许多共同的缺点。然而，V模型确实鼓励验证以确保产品按预期工作。验证是敏捷开发的重要组成部分，但该模型的线性特性与敏捷实践不太契合。

在敏捷开发中，客户与开发团队之间的关系非常重要。Sashimi模型认识到了这种关系的价值，因为开发团队会向客户提供几个原型。这比之前的流程模型更接近敏捷，因为它允许反馈。然而，仅仅几个原型是不够的。没有足够的机会进行紧密协作和反馈，以纳入对产品的改进或变更建议，这并不非常“敏捷”。

迭代流程模型与敏捷实践更兼容，因为它们具有迭代。迭代是敏捷的核心概念。重复的循环为反思和改进创造了大量机会。迭代模型也鼓励频繁和持续的发布以收集反馈，这些发布会在下一次迭代中重新设计和改进。短迭代也是敏捷的一个特点。

在上一个模块中，Bradley向你展示了螺旋模型。螺旋模型降低了风险，因为它不断迭代，并且在每次迭代中识别和审查风险。风险管理也是敏捷规划中的一个关键考虑因素。在传统的螺旋流程中，迭代往往较长，与客户的协作也不频繁。但是，你绝对可以将敏捷实践与螺旋模型结合使用，因为它确实有迭代。你可以缩短迭代周期，并在迭代结束时举行客户会议并重新评估产品。

在我们回顾的所有流程模型中，统一过程与敏捷价值观和原则最为兼容。统一过程具有短迭代，类似于我们在敏捷方法论中看到的情况。一些敏捷方法论也采纳了统一过程对架构的关注。甚至有一种方法论被创建出来，它结合了统一过程并用敏捷实践加以补充，这种混合方法论被称为敏捷统一过程。

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

你被要求去帮助一个陷入困境的开发团队。该团队正在为一家职业棒球俱乐部开发一款移动票务应用，但未能按时交付可用的产品。他们认为自己大约比计划晚了两周，但由于没有进行任何跟踪，很难确定。他们需要帮助，而且需要快速帮助。

你从其他产品经理那里听说，敏捷实践在过去曾帮助过他们的项目。你只想实施遵循《敏捷宣言》的实践。

你会实施以下哪种实践？
A. 任务一开始，就显示给整个团队看。
B. 客户在初始规划完成后不能添加新功能。
C. 开发计划定期重新评估。
D. 软件产品经理充当客户和开发团队之间的信使。

如果你想实施敏捷实践，定期重新评估开发计划是一个很好的起点。这遵循了敏捷“适应变化”的价值观。因此，答案C是正确的。

A不正确，因为在敏捷中，你希望通过可工作的软件或已完成的任务来跟踪进度，而不是已开始的任务。答案B不允许客户协作或适应变化。D不正确，因为你希望你的开发团队和客户之间保持持续、开放的沟通。

基于《敏捷宣言》的价值观和原则，许多不同的软件实践被确立下来。这些实践是你可以作为软件产品经理使用的指南和规则，以使开发过程更有效。这些实践被组织成方法论。你可能听说过其中一些方法论，甚至可能使用过其中一个。

我们将在本专项课程中涵盖的方法论是：极限编程（也称为XP）、Scrum、精益和看板。我们将在接下来的两个模块中介绍这些方法论的一些要点。

所有Scrum实践都从《敏捷宣言》中提取价值观和原则，并将它们转化为用于软件开发的指南和规则。这就是为什么Scrum被归类为一种敏捷方法论，而Scrum内的实践被归类为敏捷实践。

现在，是时候研究你的第一个方法论了。在下一课中，我们将一起看看极限编程。

015：极限编程 🚀

在本节课中，我们将要学习极限编程的核心实践。极限编程是一种敏捷软件开发方法，它强调客户满意度、团队协作和快速响应变化。我们将逐一探讨其12项基本实践，并理解它们如何共同作用以提升软件开发的效率与质量。

极限编程简介

极限编程通常简称为XP。它之所以被称为“极限”，是因为它将许多良好的软件开发实践推向了极致。XP的核心目标是实现客户满意，这意味着开发团队的首要任务是尽可能让客户感到高兴。同时，它也重视持续交付软件、响应变化、高效团队合作和自我组织，这些原则都体现在敏捷宣言中。

极限编程关注的五个方面

极限编程着重于改进开发的五个方面：沟通、简单性、反馈、尊重和勇气。沟通、简单性和反馈在敏捷宣言中已有涉及。而“尊重”意味着在XP中，客户、产品经理和开发团队的所有成员都被视为平等的，每个人的贡献都受到重视。“勇气”则意味着团队要坦诚面对进度和估算，不畏惧变化，并且因为团队协作而敢于承担经过计算的风险。

极限编程的12项实践

以下是构成极限编程框架的12项基本实践。它们像拼图一样，单独看可能意义不大，但组合在一起就能形成高效的工作流。

实践一：计划游戏

这是指客户与开发团队共同规划产品的过程。它可以发生在不同规模上，例如在开发初期有一次大型计划会议，而在每次迭代后则可能有更小型的会议。

计划游戏的规则通常如下：

客户和开发团队共同列出产品的新功能列表，每个功能都以用户故事的形式表达。
开发团队估算在下一个迭代中可以投入的工作量，以及完成每个用户故事所需的工作量。
客户和开发团队共同对用户故事进行优先级排序，并决定每个功能的可工作版本的发布时间。

实践二：小版本发布

在极限编程中，我们希望版本发布尽可能小而频繁。开发团队需要与客户一起规划哪些功能具有商业价值并可以尽早发布。目标是尽早开发重要功能，以便有更多时间进行完善。发布版本尽可能小，也使得估算更容易，因为预测一两周的工作比预测一个月的工作要简单得多。

实践三：系统隐喻

系统隐喻旨在让你的系统更容易向他人解释。你应该能够轻松地向没有技术经验的第三方解释你的产品。一个好的隐喻能够清晰地传达产品的核心功能。例如，一个人脸识别应用可以被比喻为“派对上的社交达人，认识在场的每一个人并了解他们的所有信息”。

实践四：简单设计

这意味着你的设计应尽可能简单。由于需求会不断变化，为那些可能不会持久的东西做详细设计是没有意义的。只设计你今天正在处理的需求所需的内容，不要为可能不会到来的未来进行过度设计。

实践五：持续测试

在极限编程中，测试是在编写源代码之前为功能或需求编写的。其核心思想是将这些测试作为需求的可执行形式。这样，当测试通过时，你就知道相应的需求得到了满足。这被称为测试驱动开发。

XP中有两种测试方式：

验收测试：由客户执行，用于测试产品的每个功能是否按规范工作。这些测试覆盖产品的较大范围，可以是自动化的，也可以是人工遵循的用户界面操作脚本。
单元测试：由开发人员编写的自动化测试，用于测试较低层次的功能。例如，对于一个允许用户创建、编辑和删除帖子的社交媒体应用，需要有测试来确认这些操作是否成功执行。

实践六：重构

重构是指在不改变代码行为的前提下，重新调整代码的设计结构。它改善了设计，使得新功能可以更容易地添加，从而鼓励团队响应新的变化。例如，重构包括移除重复和不必要的代码。由于开发人员编写了单元测试，他们可以自信地删除代码而不会破坏产品。如果删除后测试仍然通过，就说明那是多余的代码。

实践七：结对编程

结对编程是XP广为人知的实践之一，指两名开发人员并排坐在一台计算机前共同编写代码。这将代码审查推向了极致——代码时刻都由配对的另一人进行审查。虽然这看似需要双倍人力资源，但实际上，两名程序员合作产生的成果通常超过两名程序员独立工作的总和，且质量更高。这也反过来培养了“勇气”，因为程序员在一起工作时更愿意承担经过计算的风险。

实践八：集体代码所有权

这项实践鼓励整个开发团队为产品的任何部分贡献新想法。这意味着任何人都可以向产品的任何部分添加代码。当出现问题时，这是团队的结果，而非个人的责任；同样，当成功时，也是团队的成功。

实践九：持续集成

持续集成要求开发人员频繁地合并代码。这可能每天至少发生一次，但要达到“极限”的程度，发生的频率应该更高。在集成之前和之后，所有的测试都应该100%通过。

实践十：每周40小时工作制

尊重开发人员的工作与生活平衡似乎显而易见，但对于一群充满热情的开发者来说，可能很难让他们离开键盘。XP允许在项目紧要关头有一周的加班时间。如果连续数周都需要加班，那就是项目管理出现问题的危险信号。

实践十一：现场客户

这项实践邀请客户成为开发团队的一部分。客户始终在场，可以澄清和回答开发过程中出现的任何问题。他们参与到开发的每个阶段中。

实践十二：编码标准

这意味着所有开发人员都遵循相同的编码标准。你不应该通过看代码就能分辨出是谁写的。相反，你应该鼓励开发团队遵循共同的编码约定，并以相同的方式格式化代码。这个标准应在开发初期就达成一致。这不仅使代码更易于阅读，也鼓励了集体所有权。

总结

本节课中，我们一起深入学习了极限编程的核心理念与12项关键实践。从强调客户合作的“计划游戏”和“现场客户”，到追求技术卓越的“简单设计”、“持续测试”、“重构”和“结对编程”，再到保障团队可持续性的“小版本发布”、“集体代码所有权”、“持续集成”和“每周40小时工作制”，这些实践共同构建了一个高效、响应迅速且以人为本的敏捷开发框架。理解并应用这些实践，将帮助你作为软件产品经理更好地领导团队，交付令客户满意的高质量软件产品。

016：极限编程实践与反思

在本节课中，我们将通过一个具体的案例来探讨极限编程的核心实践，分析其背后的管理原则，并审视这种敏捷方法在实际应用中的优势与挑战。

丹妮尔是一名产品经理，她与一个五人开发团队合作，共同开发一款允许小企业主向员工支付工资的薪酬应用程序。在交付了一个原型后，客户向开发团队发送了一封措辞严厉的电子邮件，指出应用程序中存在一个计算工资错误的缺陷。客户对此非常不满，因为这个错误会让企业主损失大量金钱，并导致员工获得超出其应得的报酬。

编写此功能单元测试的程序员是蒂米和玛丽亚。结对编写源代码的程序员是斯蒂芬和玛丽亚。产品经理丹妮尔在产品发布前进行了验收测试。

谁应该为这个错误负责？请选择所有适用项。
A. 丹妮尔
B. 蒂米
C. 玛丽亚
D. 斯蒂芬
E. 团队中的其他两名开发人员

极限编程的一项实践是集体所有制。这意味着团队所有成员都对发生的错误负有责任。因此，每个人都有过错。这意味着 A、B、C、D 和 E 都是正确答案。如果客户对产品非常满意，整个团队也将共享成功的荣誉。

上一节我们通过案例理解了集体所有制的含义，本节中我们来看看极限编程实践的其他表述方式。

我之前提到，极限编程传统上由12项基本实践来描述。然而，根据你查阅的资料，这些实践可能有不同的表述方式。唐·威尔斯是极限编程规则第一版的作者。他没有列出12项实践，而是提出了29条极限编程规则。其中许多规则与我们刚刚讨论的12项实践重叠，或者结合了Scrum中的许多实践。不过，也有一些管理实践不属于上述任何类别，值得注意。

以下是其中几项关键的管理实践：

提供专用的开放式工作空间：回想一下你以前工作过的环境。你认为它们提升了你的生产力和团队合作吗？极限编程建议工作空间应配备多台不属于任何个人的电脑，这些电脑应放在房间中央而不是靠墙。这鼓励开发团队一起工作。还应该有一个配备白板的会议桌，供团队协作和头脑风暴。
轮换人员：这鼓励沟通和灵活的工作关系。这意味着每个人都了解如何开发和操作产品的所有部分。试想，如果只有一个人知道某个功能如何工作，将对项目造成多大的损害。当他们离开时会发生什么？你的开发工作将出现空白。轮换人员的替代方案是对功能进行大量文档记录，但这不是敏捷的方式。你不会组建一支没有替补守门员的职业足球队。同样，项目的成功不应依赖于某一个人。在体育或开发中，最有用的团队成员是那些掌握多种技能的人。
适时修正极限编程本身：即“当它出问题时，就修复它”。你可能注意到这里说的是“当”而不是“如果”，因为它必然会出问题。它不会在你产品的整个生命周期中都一帆风顺。并非所有极限编程实践都适合你的团队。当某些方法不奏效时，就改变它。你应该让团队遵循规则，直到规则不再适用。频繁的项目回顾会议是确定哪些方法有效、哪些无效的好方法。

现在，让我们通过另一个场景来检验对极限编程实践的理解。

你被一家自称已精确实施极限编程方法的公司聘用。你走进工作场所，看到的是一片隔间迷宫。你在工作区走动并向隔间内窥视，看到成对的程序员在一起工作。你走进一个隔间，询问开发人员在哪里可以找到客户。一名开发人员递给你一张印有客户电话号码的名片。他说你可以在那里留言，客户会回复你。

你走进下一个隔间，询问在那里工作的两名程序员下一次发布何时到期。他们告诉你每两个星期五发布一次，本周五就有一个发布。你问这些程序员他们在做什么，他们解释说他们是数据库团队，专门负责维护和构建数据库。

你意识到他们在许多方面都没有正确遵循极限编程。为了让极限编程在这个办公室精确运行，你需要改变哪些开发领域？
A. 工作空间
B. 结对编程
C. 客户可用性
D. 小型频繁发布
E. 开发人员多能性

极限编程的工作空间环境是开放的，鼓励协作。隔间迷宫不符合这项实践。客户也应随时可用。难以联系的客户不利于有效沟通。最后，开发人员应该轮换工作，而不是专攻某一功能。让两名开发人员专门负责数据库工作不符合极限编程。因此，A、C 和 E 是正确答案。这家公司并非完全偏离轨道，他们确实进行了结对编程并交付小型频繁发布，这些都是良好的极限编程实践。

既然你已经熟悉了极限编程的规则，现在我们来谈谈它的一些缺点。

极限编程的一个缺点是需要全有或全无的方法。如果你为开发团队采用极限编程，鼓励你采用所有规则以获得全部收益。是的，我确实提到可以改变不起作用的方面，但到什么程度它仍然算是极限编程？当一半的实践都不适合你的团队时会发生什么？单个实践的价值不如整体方法论。但有时实施所有实践既不实际也不可能。

极限编程的另一个弱点是它专为小型开发团队设计。当你的开发团队超过20人时会发生什么？你会在集体所有制和集成方面遇到许多问题。

此外，极限编程缺乏前期规划。与其他方法论相比，极限编程不鼓励真正的软件架构前期规划，这可能导致未来大量的返工。

还有结对编程。它确实有很多好处，但并未像其他实践那样被广泛采用。我可以保证它不会适用于所有团队，性格冲突将是一个重要因素。

最后，安排现场客户很困难。让客户按照极限编程要求的时间全程参与并不常见。期望客户在每次出现问题或疑问时都在场通常是不现实的。在理想世界中，客户始终在场当然很棒，但这是真实的软件开发，事情往往远非理想。

极限编程为软件开发概述了许多优秀的实践，但这个过程也有许多缺点。作为一名产品经理，你需要找到适合你团队的实践。你需要进行实验。也许极限编程完全适合你，也许不适合。这就是为什么你必须研究多种方法论，以便为你的团队找到合适的方法。你需要收集数据来支持哪些实践对你有用。

基于这一点，在下一课中，你将转向另一种名为Scrum的方法论。

本节课中我们一起学习了极限编程的集体所有制原则、关键管理实践（如开放式工作空间和人员轮换），并通过案例分析识别了正确与错误的实施方式。最后，我们客观地探讨了极限编程的潜在缺点，包括其对全盘采纳的依赖、团队规模限制以及客户参与的挑战。理解这些优缺点有助于你作为产品经理在实践中做出更明智的决策。

017：Scrum敏捷实践

在本节课中，我们将学习Scrum的基本结构和实践。Scrum是一种轻量级的敏捷实践方法，在本专项课程中已被多次提及。你将获得对Scrum框架的基本理解，并了解其核心角色与事件。后续课程将深入探讨具体的Scrum技术。

什么是Scrum？🤔

Scrum是一种轻量级的实践方法，它不会占用太多生产时间，管理开销也相对较小。Scrum易于理解，但难以精通。

Scrum采用迭代和增量式的方法。这意味着团队会频繁评估产品进展，从而增强可预测性并降低风险。

Scrum建立在三大支柱之上：透明、检视和适应。

Scrum的三大支柱 🏛️

上一节我们介绍了Scrum的基本概念，本节中我们来看看支撑Scrum的三大核心支柱。

1. 透明

透明意味着项目的每个部分对所有人都是可见的。这种可见性不仅限于Scrum团队内部，也适用于团队外部人员。透明的一个重要部分是就项目的通用标准达成一致，包括在整个开发过程中使用统一的术语，以及对“完成”的定义达成共识。我们将在本节课后面讨论“完成”的含义。

2. 检视

Scrum鼓励频繁检视工作产品和进度，以便及时发现与预期的偏差。Scrum培训师兼作者肯·施瓦伯曾比喻说，Scrum就像你的岳母，它会指出你所有的缺点。开发人员有时对采用Scrum犹豫不决，正是因为它会指出所有做得不对的地方。这些检视应该频繁进行，但不能频繁到干扰开发任务。

3. 适应

在检视过程中，如果发现产品开发开始偏离愿景，团队必须进行调整和适应，以防止进一步偏离。Scrum为检视和适应规定了四种具体的技术，它们分别是：冲刺计划、每日站会、冲刺评审和冲刺回顾。你将在关于敏捷规划、评审和度量的课程中学习这些技术。

Scrum团队的角色 👥

前面提到了Scrum团队，现在我们来详细了解其中的一个关键角色：产品负责人。

产品负责人的主要任务是什么？A. 从商店购买产品；B. 为产品的创建付费；C. 负责做出关于产品的决策；D. 组织开发团队以提高效率。

产品负责人是Scrum中的一个角色，我们将更详细地研究它。他们的主要任务是就产品和产品待办事项列表做出决策。因此，C是正确答案。

一个Scrum团队由产品负责人、开发团队和Scrum主管组成。

你刚刚了解到，产品负责人负责对产品和产品待办事项列表做出决策。他们对产品待办事项列表中的需求进行优先级排序，并决定实际要构建什么。你将在关于客户需求和软件需求的课程中学习产品待办事项列表。

产品负责人是一个人，而不是一个委员会。产品负责人可以代表一个委员会，但只有产品负责人才能对产品实施变更。产品负责人的职责是为Scrum团队提供明确定义的产品待办事项列表，并对其进行优先级排序。产品负责人指定的优先级必须得到尊重并按该顺序进行开发。他们对开发什么拥有最终决定权。产品负责人还有责任确保开发团队理解待办事项列表中各项功能的预期要求。

实践场景：如何处理变更请求？💼

假设你是一名软件产品经理，受雇于一家大型运动服装公司，为其开发一款跑步应用。在第一次与开发团队及公司代表Penny的会议中，团队决定使用Scrum，Penny被任命为产品负责人。

开发进行到一半时，你收到了公司CEO的电子邮件，他要求增加预制的跑步歌单功能，供用户跑步时收听。你知道开发团队已经和Penny讨论过这个功能，并且团队共同决定不实现这个功能，而选择实现另一个功能。

遵循Scrum实践，你应该怎么做？A. 回复邮件说“不，你在这个项目中没有发言权”；B. 告诉你的开发团队将该功能添加到待办事项列表中；C. 告诉你的开发团队在当前迭代中开发该功能；D. 回复邮件，要求所有功能请求都通过Penny提出。

在Scrum中，所有关于产品的决策都必须来自产品负责人。这是否意味着你要拒绝公司CEO？不，那不符合商业常识。最好的做法是礼貌地回复CEO，并抄送产品负责人Penny，要求所有功能请求都通过产品负责人提出。设置单一联系点的目的是减少沟通失误。来自多个来源的过多指示会导致开发团队困惑，并很可能浪费开发时间和资源。在确认产品负责人确实需要此功能之前，你不应将其提交给开发团队。因此，D是正确答案。

Scrum开发团队的特点 🛠️

现在，让我们看看Scrum开发团队的一些特点。

Scrum开发团队是自组织的。这意味着没有人，甚至是Scrum主管，都不能告诉团队如何将他们的功能待办事项转化为可工作的软件增量。

Scrum开发团队也是跨职能的。这意味着团队拥有完成产品所需的所有人员和一切资源。这可能包括来自不同领域的专家。团队不应依赖任何非团队成员。此外，团队成员承担多种任务，例如同时进行编码和测试，而不是有专门的编码人员和测试人员。

因此，开发团队的成员没有头衔。他们只应被称为“开发者”或直呼其名，无论他们是否负责特定任务。Scrum开发团队中也没有子团队。开发者可能在团队内拥有专业技能，但责任属于整个团队。

Scrum开发团队规模较小。理想情况下，团队规模大于3人，小于9人。Scrum主管和产品负责人不计入此人数，除非他们也参与开发工作。一个经验法则是，你应该能用两张披萨喂饱整个团队。披萨也有助于提升团队士气。

实践场景：识别真正的Scrum团队 🧐

假设你在一个关于Scrum实践的会议上，与几位其他软件产品经理谈论他们的开发团队。

第一位SPM名叫Kelsey。她描述她的团队有四名程序员、两名测试员和一名用户界面设计师。
接下来，你遇到了Jim。他说他目前的团队由20名开发人员组成。
然后你遇到了Billy。他简单地说他有一个由七名开发人员组成的才华横溢的团队。
接着你遇到了老朋友Carrie。她说她的团队有九名开发人员，其中五人在开发团队，四人在测试团队。
最后，你遇到了一位新的软件产品经理Hillary。她说她的团队只有三名开发人员，并且他们将测试工作外包了。

这些软件产品经理中，谁拥有真正的Scrum开发团队？A. Kelsey；B. Jim；C. Billy；D. Carrie；E. Hillary。

这些都是你常见的开发团队例子。然而，只有Billy拥有真正的Scrum开发团队。他的团队没有头衔或子团队，并且是跨职能的，规模也合适。Kelsey的团队有头衔，Jim的团队规模太大，Carrie的团队有子团队，Hillary的团队不是跨职能的，因为他们将测试外包了。因此，C是唯一正确答案。

Scrum主管的角色与Scrum事件 ⏰

最后，我们来谈谈Scrum主管的角色。Scrum主管的职责是确保Scrum团队遵循Scrum理论、实践和规则。他们对产品负责人和开发团队都有具体的职责。

Scrum主管对产品负责人的职责包括：寻找管理待办事项列表的技术；帮助Scrum团队理解清晰简洁的待办事项列表的必要性；确保产品负责人知道如何对待办事项列表进行优先级排序以获得最大价值；以及促进Scrum事件。

Scrum主管对开发团队的职责包括：指导团队自组织；移除开发障碍；以及促进Scrum事件。

那么，Scrum主管负责促进的这些Scrum事件是什么呢？这些Scrum事件包括之前提到的用于检视和适应的四种技术：冲刺计划、每日站会、冲刺评审和冲刺回顾。同样，你将在专项课程中更详细地了解这些事件。

所有这些事件都是时间盒的，这意味着你需要为这些事件的持续时间指定一个最长时间，并遵守它。这背后的理念是保持分配的时间并调整范围，而不是保持范围并最终延迟发布。

另一个Scrum事件是冲刺。冲刺是一个特定时间段的开发阶段，在此阶段内向客户交付一个可工作的原型。这些冲刺也是时间盒的，但执行更严格。一个冲刺持续一个月或更短时间，通常是一到两周。一旦你的Scrum团队确定了冲刺的长度，在整个开发过程中必须始终保持这个长度。冲刺不能变长或缩短。在每个冲刺结束时，向客户交付一个可工作的原型。每个冲刺包含我前面提到的四个Scrum事件。

冲刺计划发生在当前冲刺开始时，以确定在该冲刺中将完成什么。
每日站会是每天举行的会议，通常在每个工作日的开始进行，以便开发人员讨论他们将做什么任务以及需要什么来完成这些任务。
冲刺评审和冲刺回顾在冲刺结束时进行。

在冲刺期间，不能进行会影响冲刺目标的变更。冲刺目标是对该冲刺将要完成内容的大局观。会改变冲刺目标的建议将进入待办事项列表，如果产品负责人决定，可以在下一个冲刺中实施。

实践场景：冲刺中的变更管理 🔄

假设你的团队正在开发一款移动应用，允许用户搜索当地餐厅的食品和饮料特价。本次迭代的冲刺目标是设置用户界面，即最终用户将看到并与之交互的一切。

冲刺进行到一半时，客户发来电子邮件说他们改变了主意。他们希望应用程序的主色调是蓝白色，而不是红黑色。这对开发团队来说是一个快速的修改。客户还要求应用程序现在支持在屏幕上弹出广告。

这些变更中哪些可以在当前冲刺中进行？A. 颜色变更；B. 弹出广告；C. 两者都可以；D. 两者都不可以。

更改应用程序颜色是一个不影响冲刺目标的微小变更。因此，该变更可以在冲刺中期实施。添加弹出广告需要更多的开发工作，并且不符合冲刺目标。这应该被添加到产品待办事项列表中，并在未来的冲刺中重新考虑。因此，A是正确答案。

“完成”的定义与Scrum实践要点 ✅

Scrum的一个重要部分是“完成”的定义。在冲刺结束时交付的可工作原型必须是“完成”的。定义决定产品何时“完成”的质量标准是开发团队的责任。

通常，当一个功能被编码、测试和文档化后，才被认为是完成的。团队必须就“完成”的含义完全达成一致。如果你回想一下敏捷宣言，进度应该通过已完成的功能来跟踪。这样做的目的是避免工作处于半完成状态。这可能导致团队独立工作，看起来很忙，却没有完成任何可用的东西。完成一个功能需要沟通、集成和同步。这有时要求开发进展缓慢，以确保每个功能真正完成。

与极限编程类似，Scrum的支持者推荐一种“全有或全无”的方法。然而，Scrum实践可以单独实施，因为它们比一些XP实践更具独立性。但如果你单独实施这些实践，那么你并不是在实践Scrum。真正的Scrum要求完整地实践其全部内容。

正如我在介绍性课程中提到的，许多大型科技公司如Adobe、Amazon、Microsoft和Yahoo都使用Scrum。如果你想了解更多关于Scrum的信息，可以访问scrumguides.org。请查看课程资源以获取最新链接。

尽管Scrum是一种流行的方法论，但它仍然存在一些缺陷。你认为Scrum有哪些缺点？请在课程讨论中谈谈你的看法。在下一个模块中，你将继续研究更多的实践和方法论。

总结 📝

本节课中，我们一起学习了Scrum敏捷实践的核心内容。我们了解了Scrum的三大支柱（透明、检视、适应），认识了Scrum团队的三个关键角色（产品负责人、开发团队、Scrum主管）及其职责，探讨了Scrum开发团队自组织、跨职能和小规模的特点。我们还学习了关键的Scrum事件，如冲刺、冲刺计划、每日站会等，以及“完成”的定义的重要性。通过几个实践场景，我们加深了对Scrum原则在实际中如何应用的理解。Scrum是一种强大的框架，但需要完整实施才能发挥其最大效用。

018：敏捷变体与精益软件开发 🚀

在本节课中，我们将要学习敏捷开发方法的一些变体，并重点介绍一种日益流行的实践——精益软件开发。上一模块我们讨论了极限编程和Scrum等主流敏捷实践。本节中，我们将看看其他敏捷变体，并深入了解精益软件开发的核心原则。

敏捷的演变与变体

敏捷方法始终在变化和演进。总会有新的实践或变体出现，以改进先前方法的不足之处。虽然Scrum目前应用广泛，但在未来几年或特定领域，其他敏捷变体也可能变得流行。

以下是几种从敏捷思想中演化出来的其他实践：

敏捷统一过程：如其名称所示，它结合了统一过程和敏捷实践。它使用并行开发阶段，同时融入敏捷理念以提高开发人员士气和项目协作。它注重遵循流程而非特定工具，强调简洁性、赋能团队以及根据项目需求定制方法。
动态系统开发方法：这是另一种敏捷变体。
特性驱动开发：同样属于敏捷变体范畴。
ScrumBan和行为驱动开发：也是敏捷的变体。

关键在于，敏捷存在许多变体。如果在流程中遇到问题，敏捷允许你根据需求进行调整，以适应特定的流程、方法或实践。例如，如果你发现现有方法在软件产品架构或测试方面效果不佳，可以尝试上述变体，看看是否更适合你的团队。

精益软件开发简介

近年来，有一种敏捷开发方法论获得了极大的关注，预计其流行度在未来几年将持续增长。这种方法论就是精益软件开发。

精益软件开发起源于制造业。“精益思维”的概念在90年代中期被提出，旨在通过减少浪费、仅在必要时开始新工作、减少流程瓶颈以及只专注于为项目增加价值的工作来降低项目风险。丰田公司采用了这种方法，“精益制造”一词自此与其制造流程紧密相连。

2003年，Mary和Tom Poppendieck撰写了一本书，致力于将精益制造原则应用于软件开发。这本书被广泛认为是精益软件开发普及的重要原因。

那么，什么是精益？精益是一种思维方式。它是一套核心原则，旨在降低项目风险，并快速向客户交付高质量产品。

精益软件开发的七大原则

精益软件开发包含七项原则。我们将逐一探讨这些原则。

第一项精益原则受到的关注最多，它被称为消除浪费。

在精益中，任何不增加价值的事物都被视为浪费。而在精益实践中，任何被视为浪费的事物都会被无情地从开发流程中移除。

为了理解软件中可能存在的浪费，让我们回顾一下精益的制造业起源，做一个类比。假设你是一家汽车制造厂的经理。工厂的每个部分专门制造汽车的每个部件。如果每个部件都以其最大产能持续生产，很快你就会拥有大量过剩的部件（例如车轮），它们会占用存储空间，并且当车型更新时可能变得完全无用。这显然是巨大的浪费。

如果认为这种情况不适用于软件开发，那就太天真了。你的“生产”是基于代码，你的“机器”是软件开发者。如果团队中的每个开发者时刻都处于忙碌状态，你可能会发现他们变得低效。通过让开发团队不断编写新代码，而不是专注于核心功能，你可能会得到大量额外功能。这些功能可能会降低最终产品的质量、引发主要产品的问题，或者最终根本不会被整合到产品中。这是软件生产可能造成浪费的一个关键例子。

除了过度生产，软件开发的浪费还可能通过以下方式产生：

流程延迟
不必要的会议
不清晰的需求
产品缺陷

第二项原则是强化学习。软件开发是一个探索和发现的过程。团队需要通过短迭代、持续集成和反馈循环来快速学习和适应。

第三项原则是尽可能延迟决策。在掌握足够信息之前，避免做出不可逆转的决策。这允许团队保持灵活性，并根据最新的知识和市场变化做出更明智的选择。

第四项原则是尽可能快速交付。快速交付可工作软件可以尽早获得客户反馈，验证假设，并实现价值。这通常通过小批量工作和缩短周期时间来实现。

第五项原则是赋能团队。信任并授权给开发团队，让他们自我组织并做出技术决策。管理者扮演服务型领导的角色，移除障碍，为团队成功创造条件。

第六项原则是内建质量。质量不是后期检查出来的，而是应该在开发过程的每一步中构建进去。这可以通过实践如测试驱动开发、持续集成和自动化测试来实现。

第七项原则是整体优化。关注整个系统和价值流，而不是局部优化。确保所有部分协调工作，共同为最终客户创造最大价值。

总结

本节课中，我们一起学习了敏捷方法的各种变体，并深入探讨了精益软件开发的七大核心原则。我们了解到，敏捷是一个不断发展的领域，除了Scrum和极限编程，还有如敏捷统一过程等多种实践。精益软件开发则从制造业汲取智慧，强调通过消除浪费、快速交付、延迟决策、赋能团队、内建质量和整体优化来高效、高质量地交付价值。理解这些不同的方法论和原则，将帮助你在管理软件项目时做出更明智的选择。

019：敏捷变体与精益软件开发

在本节课中，我们将要学习精益软件开发的核心原则，特别是“放大学习”、“尽可能晚做决策”和“尽可能快交付”这三个原则。我们将探讨这些原则如何帮助团队更有效地构建满足客户需求的软件产品。

放大学习原则

上一节我们介绍了精益软件开发的基础，本节中我们来看看其第二个原则：放大学习。这个原则的核心思想是，在深入投入一个想法之前，不要过早地锁定它，而应充分探索多种可能性。

这个原则相当简单。在你彻底探索另一个想法之前，不要过于深入地专注于一个想法。

在采取行动之前，通过思考各种替代方案来彻底探索想法。

以下是它在现实场景中的体现。

你的开发团队创建一个非常基础的用户需求列表，以便快速启动项目。

然后，他们可以非常简要地规划出产品的一种可能方法，并开始开发该基础功能。

当然，这在大多数流程中都很常见。然而，为了放大学习，一个好的做法是在这个阶段停下来，不要在这个版本上做更多工作。😡，问问自己，这件事可以用另一种方式完成吗？如果可以，你的开发团队也应简要规划和开发这些替代方案。

通过允许产品的功能集以这种方式进行调整，你的产品就有最大机会以最令人满意的方式满足客户的需求。😊。

但这并非在软件产品中放大学习的唯一方式。

精益软件开发鼓励在产品每次构建后运行集成测试和单元测试。

这里的理由不仅是为了确保代码编写良好。

测试也可以是学习产品应如何运行的绝佳方式。

测试可以为你的团队带来关键见解，这些见解可用于指导产品的其他版本和未来规划。

在精益软件开发中，这发生在非常短的迭代中。

这里的理念是快速失败并快速学习。此外，如果你在一个设计或一个功能上花费太多时间，你可能会很容易发现自己对一个设计投入过多，以至于无法真正看到其缺陷并考虑其他更好的方法。

精益软件团队被鼓励放大学习的另一种方式，是以一种特殊的方式让客户参与整个开发过程。

开发团队不仅应在专注于一个版本之前创建产品的不同版本，还应不断将这些版本呈现给客户。

这使得开发团队能够通过试错来了解客户的真实需求。

这也让客户能够学习他们希望产品如何解决其特定问题。

在开发过程中，这些需求应不断细化，以保持可行性。

这类似于自然选择，因为许多潜在方法被呈现给客户。

这使他们能够决定希望在产品中构建哪些功能，从而为最终产品带来聚焦和精炼。

因此，通过让客户参与尝试不同的方法，你的开发团队学会了如何最好地解决他们的特定问题。

这带来了更好的软件和更满意的客户。这比你的开发团队不考虑替代设计而直接埋头苦干要好得多。

所以，放大学习的要点是确保你的团队通过开发替代方案、持续反馈和精炼来构建正确的产品。

奥黛丽正在与她的开发团队使用精益软件开发实践构建一个软件产品。她要求她的开发团队在为客户创建不同替代方案时，一次只专注于项目的一个方面。

通过要求她的团队一次只专注于项目的一个方面，奥黛丽正在实施精益的哪个原则？A. 开发小型增量发布。B. 放大学习。C. 专注于频繁交付。或 D. 消除浪费。

答案是 D. 消除浪费。让团队构建不同替代方案是奥黛丽正在做的放大学习。

开发小型增量发布和专注于频繁交付是敏捷的原则，而非精益的原则，尽管精益项目当然可以利用它们。

尽可能晚做决策原则

接下来，我们探讨第三个精益软件开发原则：尽可能晚做决策。现在，这看起来可能像是为争取更多开发时间而延迟产品的借口。但我向你保证，事实恰恰相反。这个原则实际上很好地承接了“放大学习”的理念。

想象一个软件团队为客户构建了一个基础的软件片段。客户看到这个原型后说，是的，这正是我需要的。就按这个做。

很明显，沿着这个初始原型设定的路线继续下去会满足客户，对吧？然而，在你决定之前，请考虑这一点。作为一个精益软件开发团队，开发团队探索了不同的方法以放大学习。

他们知道客户认为他们的原型足以满足需求。因此，团队询问客户这个原型的哪些特性具有吸引力？

基于这些信息，团队继续构建产品的替代版本，整合客户喜欢原型的地方。

在完成了产品的几个更多版本后，客户审视一切并判断原始原型已不再适用。它有一些对最终产品很好的特定功能，但一个替代版本将更好地满足他们的需求。

因此，开发团队回到工作岗位，利用这个反馈将原始原型的特性整合到新版本中。现在，团队拥有了比最初更精炼的产品版本。

客户审视后比以前任何时候都更满意。这个版本似乎真的切中要害。开发继续进行，团队学到了获得正确产品所需的经验教训。

如果开发团队将客户最初决定构建第一个原型视为最终决定，而不是开发更能满足客户需求的替代方案，会发生什么？

开发团队可能会构建出一个糟糕的产品。不仅如此，他们甚至不会知道自己正在构建一个糟糕的产品。

这就是“尽可能晚做决策”背后的核心理念。它不是关于延迟任何事情或争取时间，而是关于在所需数据和信息可用时才做出决策。

例如，你努力确保存在许多替代方案。在信息不足时做出的决策必然导致糟糕的结果。

尽可能晚做决策确保你先拥有所需的信息。

尽可能快交付原则

还记得我说过“尽可能晚做决策”与延迟开发恰恰相反吗？这个原则真正巩固了这一理念。实际上，“尽可能快交付”这一原则与“尽可能晚做决策”密切相关。

我的意思是：当尽可能晚做决策时，开发团队向客户呈现了许多不同的方法。这使得开发团队能够获得必要的客户反馈，从而专注于客户的需求。

然而，如果开发团队花费三个月来开发每个潜在的原型，会发生什么？假设有四个替代方案，每个耗时三个月。那是在做出任何最终产品或决策之前整整一年的时间。谁愿意等待一整年才做出最终决定？

这就是为什么精益软件开发以短而快速的迭代运作。构建一个基础产品，确保它能工作，然后将其交付出去，再考虑下一步。没有填充物，没有不必要的工作，没有浪费。

通过以短周期运作，你的产品不仅以快速的速度演进，还允许客户在整个过程中频繁地提供反馈。

当客户改变对某个功能的看法时会发生什么？如果构建包含该功能的原型需要三个月，那么该功能在那整个时间段内都是错误的。谁知道还有什么其他部分可能依赖于它。然而，如果开发以快速迭代进行，这个问题就能及早发现并纠正。

这最大限度地减少了浪费，并快速提高了构建到产品中的质量。因此，通过快速构建产品，你的软件得以快速成长。😊。但它也通过专注于最终会保留的产品部分，确保你高效地做到这一点。

总结

本节课中我们一起学习了精益软件开发的三个关键原则：“放大学习”、“尽可能晚做决策”和“尽可能快交付”。我们了解到，放大学习 鼓励探索多种方案并从反馈中学习；尽可能晚做决策 强调在信息充分时再做关键决定，以避免错误；而 尽可能快交付 则通过短周期迭代来加速产品演进、减少浪费并快速响应变化。这些原则共同作用，帮助团队更灵活、更高效地构建出真正满足客户需求的优质软件产品。

020：敏捷变体与精益软件开发

在本节中，我们将学习精益软件开发的三个核心原则：赋能团队、内建质量和整体看待。我们将探讨这些原则如何帮助团队更高效地工作，并交付更高质量的软件产品。

赋能团队

上一节我们介绍了精益开发中“尽可能延迟决策”的原则。本节中，我们来看看第五个原则：赋能团队。

这个概念的核心是信任你的开发团队。如果你相信团队具备完成任务所需的技能，那么就不应该花费时间去告诉他们具体该怎么做。作为软件产品经理，你的精力最好用在其他方面，例如理解客户需求、为开发者扫清障碍，然后放手让他们去工作。

这与传统管理方式可能截然不同。传统管理通常意味着管理者事无巨细地告诉团队要做什么以及如何去做。这恰恰反映了管理者对团队缺乏信任。而团队成员也能感受到这一点，日复一日的微观管理会让人精疲力竭。

因此，精益软件开发旨在赋能遵循其实践的团队。它鼓励管理者倾听开发者的意见，而不是指挥他们。你应该让开发者去构思满足客户需求的解决方案。你的目标是倾听他们的想法并提供建议。毕竟，他们应该是你的盟友。

信任你的开发团队，让他们以自己希望的方式工作，并做出正确的技术决策。这不仅确保了开发者使用对他们而言最高效的方法，也极大地提升了他们的士气。当开发团队感到自己拥有控制权，并且能在不被微观管理的情况下自由完成任务时，一切都会顺畅得多。这就是赋能团队背后的逻辑：一个快乐的开发团队，也是一个高效且多产的团队。

让我们测试一下你对这些原则的理解。在开发软件产品时，软件开发团队和客户应尽可能晚做决定的主要原因之一是什么？

以下是选项：
A. 这为他们争取了更多开发时间。
B. 这允许他们探索其他产品设计。
C. 客户从来不知道他们想要什么。
D. 这允许团队快速构建可工作的软件。

正确答案是 B。尽可能晚做决定，可以让你的开发者和客户探索其他可能更好的产品设计。这并不会延长产品截止日期或让事情进展更快，也绝不意味着你的客户不知道他们想要什么。请记住，即使你通过延迟决策为客户提供了最佳选择，也不意味着你可以不按时交付。

内建质量

理解了赋能团队的重要性后，我们接下来探讨精益软件开发的第六个原则：内建质量。

这是一个广泛而全面的原则，其真正目的是确保你的开发团队使用可用的最佳实践来避免错误。那么，这具体如何体现呢？

一种方法是测试驱动开发。这意味着在实际需要代码之前就编写测试。与先构建产品再围绕现有代码编写测试不同，测试驱动开发要求你首先关注代码旨在解决的实际问题。本质上，先构建测试意味着你实际上是在测试你的代码是否解决了问题，而不仅仅是代码是否能运行。

另一种内建质量的方法借鉴自极限编程，即结对编程。这就像是你在构建时身边有一位智能向导。不过需要提醒的是，结对编程在开发者时间成本上非常高。因此，虽然它是开发优秀软件的绝佳工具，但不要依赖它来构建整个产品，否则你可能会违反“尽可能快交付”的原则。

还有其他方法可以将质量内建于产品中，例如：

注释清晰的代码
良好的文档
重构代码以提高效率
自动化测试

所有这些方法都服务于同一个目的：让你的产品变得更好。精益的核心价值观之一是尽可能消除浪费。通过减少开发者修复代码的时间，你就减少了项目中存在的浪费。通过内建质量，你可以大幅减少发布后的缺陷和修复数量，从而显著降低产品中的浪费。

整体看待

在学习了如何通过内建质量来减少浪费之后，我们来看本课程将涵盖的最后一个精益原则：整体看待。

“整体看待”意味着将你的软件视为不仅仅是许多小部件的简单拼凑。毕竟，最终用户看到的不仅仅是串联在一起的一些功能，他们应该看到一个具有凝聚力、各组件逻辑顺畅地融合在一起的产品。

因此，在精益软件开发中，在发布产品之前，将其视为一个整体来思考非常重要。这意味着你的开发者必须时刻意识到他们的工作如何融入大局。这个大局可能是整个产品，也可能是该产品如何与同一制造商的其他产品相配合。没有这种视角，产品可能会变得脱节、不合逻辑或仅仅是笨拙。

整体看待能让你的开发团队构建出一个具有凝聚力、设计精良的整体产品。

让我们通过一个案例来巩固理解。罗斯正在为医学研究构建一个软件产品。由于他的日常工作关乎生命，他不断尝试改进软件开发流程。他最近接触到了精益软件开发，并开始实施其中一些原则。他鼓励团队将项目视为更大目标的一部分，并让他们在最终确定前创建软件的多个不同版本，同时专注于快速构建。为了节省时间，他要求开发团队不要编写单元测试、编写代码文档或使用任何特定的编程实践。罗斯在他的项目中主动忽略了精益软件开发的哪个方面？

以下是选项：
A. 消除浪费。
B. 强化学习。
C. 尽可能延迟决策。
D. 内建质量。

答案是 D，内建质量。通过主动避免这些编程最佳实践，罗斯实际上选择了不内建质量。间接来看，这可能会产生浪费，但并非直接忽略“消除浪费”原则。

总结

本节课中，我们一起学习了精益软件开发的三个关键原则。我们探讨了赋能团队如何通过信任和授权来提升团队士气和效率；了解了内建质量如何通过最佳实践（如测试驱动开发和结对编程）来减少浪费并提升产品可靠性；最后，我们明白了整体看待产品的重要性，以确保交付给用户的是一个具有凝聚力、设计精良的整体解决方案。掌握这些原则，将帮助你更好地管理软件产品开发过程。

021：敏捷变体与精益软件开发 🛠️

在本节中，我们将学习精益软件开发方法的核心原则及其与敏捷实践的关系。我们将了解如何通过减少浪费和提升质量来优化软件开发过程。

精益软件开发基础

精益软件开发方法论的根本在于，在提升产品质量的同时减少浪费。这些原则最初由玛丽和汤姆·波彭迪克在2003年的著作中提出。

随着精益软件开发社区的不断发展，后续又增添了一些新的原则。

附加原则一：运用科学方法

上一节我们介绍了精益的基础，本节中我们来看看其附加原则。其中之一是在构建系统时运用科学方法。

该原则鼓励开发者基于真实数据进行开发，而非依赖直觉、猜测或经验。

作为软件产品经理，你需要发起实验来测试想法并收集数据。分析和依据这些数据采取行动，能使开发者和客户对产品做出明智的决策。通过用数据支持潜在决策，你可以获得可信度。

这一原则与“尽可能延迟决策”的原则能很好地协同工作。

附加原则二：鼓励领导力

这是对“赋能团队”原则的延伸。鼓励领导力旨在激发团队中每个成员的最大潜能。

鼓励领导力意味着促使每位开发者变得勇敢、创新、具有启发性并善于协作。

精益原则总结

综上所述，以下是精益软件开发的整体原则。你在网络上可能会看到它们有不同的名称，但核心理念是相同的。

这些原则是：

消除浪费
强化学习
尽可能延迟决策
尽可能快速交付
赋能团队
内建完整性
整体看待

原则的有效应用与警告

在波彭迪克著作的结尾附有一项“保证”。该保证声明：精益原则已在多个学科中被尝试和验证，若正确应用，也保证适用于软件开发。

正确应用意味着运用所有精益原则，并使用思维工具将其转化为适合特定环境的敏捷实践。

在以下情况下，此保证无效：

如果不加思考地将其他学科或领域的实践直接套用。
如果忽视了“赋能团队”和“内建完整性”的原则。

因此，虽然很容易将此过程简单视为一种减少浪费、提升产品的哲学，但仅应用典型的管理实践并不足以达成这些结果。

精益的核心确实是减少浪费和提升产品。然而，鼓励团队按他们希望的方式构建产品，并确保遵循正确的编程实践，是其中至关重要的一部分，不容忽视。

精益与敏捷的关系

在我谈论精益时，你是否明显感觉到许多原则都非常“敏捷”？确实如此。

精益软件开发遵循许多敏捷原则。事实上，波彭迪克的书名就是《精益软件开发：敏捷工具包》。

在书中，波彭迪克指出，精益软件开发通过将知名且被广泛接受的精益原则应用于软件开发，进一步扩展了敏捷软件开发的理论基础。但它更进一步，提供了思维工具，帮助将精益原则转化为适合特定领域的敏捷实践。

所以，精益是一个工具包。它是一种方法论，一套实践，能帮助你创造更好的软件并拥有更满意的客户。😊

它鼓励快节奏的迭代开发、客户互动以及使用经过验证的软件开发技术以获得成功。😊

精益是强大的，无论你的组织规模大小，它都很有用。

总结与展望

作为软件产品经理，请在开发过程中牢记这些精益原则。在未来几年，你很可能会看到它们被越来越广泛地应用，对其有所了解将对你有益。

以上就是关于精益的内容。在下一课中，我将简要介绍一种常与Scrum和精益结合使用的实践。我们下节课见。

022：看板 🗂️

在本节课中，我们将学习看板方法。看板是一种源自精益制造的实践，旨在实现“准时化生产”，并通过可视化工作流程、限制在制品数量来优化效率。我们将了解其核心概念、运作方式以及如何应用于软件开发。

在上一节中，我们介绍了精益软件开发的主要主题和原则。本节中，我们将探讨精益开发中使用的一种具体方法——看板。

看板是与精益制造共同发展起来的一种方法。它旨在与精益制造配合使用，但也可以独立使用。精益制造始于丰田，旨在提高产品质量，同时减少生产时间和成本。看板帮助精益流程量化系统状态，实现准时化生产的理想。

在丰田的生产车间，每个部件都有记录，并关联一个唯一的ID。当一个部件被取走用于车辆组装时，其状态会通过ID更新，相关支持流程会收到通知。这种ID系统是看板方法有效的核心。

你刚刚了解了看板的起源及其在精益软件开发中的作用。那么，看板哲学中“只在需要时一次做一件事”的理念，是受制造业哪个术语的启发？

A. 丰田制造
B. 准时化制造
C. 按需制造
D. 精益制造

答案是 B. 准时化制造。看板源于丰田及其精益制造流程，而“一次只做一件事，只在需要时做”的具体理念就是准时化。

想象车间里有一组箱子，每个箱子装一个部件，例如轮胎。在看板中，每个轮胎都被分配一个唯一的ID。工人取走一个轮胎安装到新车上，并扫描其ID。部件被取走后，箱子就空了，等待补充。

在传统车间，空箱子会直接从现有轮胎堆中补充。但正如上节课所说，这种系统效率低下，容易导致过度生产等浪费。在看板中，当一个部件被使用时，补充该部件的流程会收到通知，以便尽快制造新部件放入箱子。这种制造方法因此被称为“准时化制造”——所有事情都在需要前的最后一刻完成。

这种持续使用和补充车间箱内物品的策略，被称为“拉动式方法”。当一个箱子清空时，就产生了一个空缺，这个空缺信号会拉动后续流程。将这种方法应用于车间的所有活动，通过拉动部件，你就能洞察系统的状态。在任何时候，你都能看到需要什么、在哪里、何时需要。

如果你跟踪一项工作从一个阶段进入下一个阶段的时间，就能确定制造每个阶段完成所需的时间。由此，你可以轻松计算一项工作走完整个制造流程所需的时间。有了这些知识，你就能发现延迟所在，做出有效改变，并跟踪这些改变随时间产生的效果。

你可能已经猜到，看板很容易转化到软件开发领域。只需做一些改变。例如，将“箱子”替换为任务板，用任务板上的列来可视化你的流程，每一列代表一个软件开发活动。

最左边的列包含待办事项列表中的所有任务。板上接下来的列可以是开发、验收测试、内部发布阶段和生产发布阶段。这个板被称为看板板，是辅助看板方法可视化的常用工具。

你正在为客户开发一个连接移动应用和数据库的软件产品。每个组件都有一套基础功能和一套可以在基础功能之上构建的高级功能。移动应用的发布依赖于数据库，但一个概念验证版的移动应用可以仅使用基础功能，无需数据库连接。

根据准时化制造原则，开发该产品的最佳策略是什么？

A. 先开发数据库的所有功能，再开发移动应用的所有功能。
B. 先开发移动应用的所有功能，再开发数据库的基础功能。
C. 先开发数据库基础功能，再开发移动应用基础功能，然后开发数据库和移动应用的高级功能。
D. 先开发移动应用基础功能，再开发数据库基础功能，然后开发移动应用和数据库的高级功能。

答案是 D。准时化制造强调只在需要时构建组件。因此，如果你能在没有数据库的情况下创建一个可运行的移动应用原型，你的首要任务就是先做这个。如果原型证明成功，你可以在其上构建数据库和其他高级功能。这样做的理由是在设计早期发现缺陷。如果你在能够测试基础功能之前就构建了整个产品，你可能会发现那些基础功能从一开始就不需要。如果是这样，之前的所有工作就都浪费了。

在看板中，所有这些阶段都是协调的。如果一项工作在某列完成，它就准备好被下一列“拉动”。然而，下一列必须形成一个空位，才能允许这项工作被拉入该阶段，继续循环。这就引出了“在制品”的概念。

在制品 顾名思义，就是每个阶段当前正在开发的工作量。在实践看板方法时，你会发现某些阶段产生工作的能力超过了其后续阶段。这些流程中较慢的部分被称为瓶颈，了解如何处理它们很重要。当某个阶段无法跟上其前一阶段产生的工作速度时，就会发生瓶颈。

在我们的汽车例子中，如果安装轮胎的工人花费的时间比制造轮胎的工人多，那么轮胎安装阶段就会出现瓶颈。

那么如何解决这个瓶颈？主要有两种方法：在瓶颈处提高产量，或在瓶颈前减少产量。

在瓶颈处提高产量当然是非常有效的方式。然而，提高产量的唯一方法是向该阶段分配更多资源。我们不能假设执行该阶段活动的人能神奇地产出更多工作。我们必须假设他们已在满负荷运转，并据此进行调整。所以，不是要求轮胎安装工工作更快，而是必须分配更多的轮胎安装工来完成任务。

你正在使用看板开发一个软件产品。开发阶段按顺序依次进行：设计、实现、验收测试和交付。每周每个阶段可以完成的工作量如下：设计5个单位，实现6个单位，验收测试3个单位，交付10个单位。每个单位是完成工作量的一个一致度量（例如，一个单位对应一个需求）。

根据每个阶段完成的工作量，瓶颈位于何处？

A. 设计
B. 实现
C. 验收测试
D. 交付

答案是 C。由于验收测试阶段每周完成的工作量少于流入它的阶段，因此瓶颈在验收测试阶段。

你刚刚了解到，增加验收测试阶段的资源可以缓解这个瓶颈，但还有另一种方法。除了在瓶颈处提高产量，你还可以消除在瓶颈之前完成的不必要工作。减少在安装前制造的轮胎数量。这被称为设置在制品限制。实际上，你限制了必须等待被拉入下一阶段的工作量。

现在我们来到我最喜欢的看板部分。那些被告知不要制造更多轮胎的工厂工人现在做什么？在软件团队中，这就是为什么多功能团队如此重要。如果你在测试阶段遇到瓶颈，拥有能在需要时从功能开发转向测试的开发人员会非常有帮助。因此，设置在制品限制是管理多功能团队瓶颈的最佳方式。平衡分配，你将看到生产力的提升。

你如何知道你的改变是否对项目产生了真正的影响？这就是周期时间的作用。周期时间是看板中的关键指标。它是一项工作完成一个完整工作周期所需的总时间。例如，周期时间是汽车轮胎从制造到安装所需的时间。

要测量每个阶段的周期时间，你需要知道一项工作何时开始、何时结束。然后计算这两个时间戳之间的小时数，你就得到了周期时间。这不是开发人员积极工作所花费的时间，而是从开始工作到完成工作之间的全部时间，包括所有人睡觉的时间。这样做的原因是，它消除了个人努力的变化，并适应了现实情况，例如因缺陷而重新开始工作。它是衡量流程处理能力和实践质量的指标，而不是衡量团队努力的指标。如果你的周期时间在减少，而产品质量保持稳定或提高，那么你就做对了。

在结束之前，我想谈最后一件事：你如何知道何时开始一项工作？在Scrum中，这是在冲刺计划会议期间通过计划完成的。在看板中，情况不同。没有计划会议。因为工作以其自身的节奏推进，所需的工作会不断地从产品待办事项列表的顶部被取走。只要需求始终被正确排序，产品自然会按照功能优先级顺序构建。看板中相当于Scrum产品负责人的人，确保产品待办事项列表始终处于正确的顺序。因此，当下一个工作项从待办列表中拉出时，它已准备就绪。

看板与精益软件开发配合得非常好，正是因为它为精益制造而生。它允许团队跟踪其随时间推移的进展，并确保遵循准时化开发策略。这减少了浪费，并确保决策尽可能晚地做出。

以上就是看板的概要。如果你想了解更多关于此策略的信息，请查看课程资源中包含的参考资料。

至此，你已经完成了本课程的学习，恭喜你！🎉

在本课程中，Morgan和我介绍了当今行业中使用的一些软件开发流程和实践的基础知识。在第一模块，Morgan定义了流程、阶段、活动和任务是什么，以及它们之间的关系。她区分了生命周期流程和子流程，并举例说明了它们如何由阶段、活动和任务组成。然后她详细介绍了软件工程活动，展示了典型生命周期流程每个阶段的活动示例。

在第二模块，我向你展示了生命周期流程如何随时间演变。我从线性流程开始，逐步介绍了螺旋、统一和持续交付过程模型。我还涉及了一些不同类型的原型设计。

在第三模块，Morgan开始深入探讨敏捷实践。她介绍了一些在敏捷中使用的流行方法，如极限编程和Scrum，以及它们实施的实践。

在本模块，我讨论了一些敏捷的变体，以及一种新兴的软件实践——精益软件开发。我们讨论了看板如何在精益中使用，以跟踪团队进度并确保每个人都遵循准时化生产策略。

Morgan和我非常享受教授这门课程，我希望你也同样享受学习的过程。😊

本课程是Coursera上软件产品管理专项课程的一部分。正如我们在介绍课程中所说，本课程以及我们的“客户需求与软件需求”课程，设计为可以按你选择的任何顺序学习。无论你计划继续学习需求课程，还是已经完成它并准备进入敏捷规划课程，我都期待与你继续这段旅程，共同创造更好的软件和更满意的客户。

我们很快再见。😊

023：课程概览与介绍 🎯

在本节课中，我们将一起了解阿尔伯塔大学软件产品管理专项课程的总体介绍。本节内容将概述课程的目标、结构以及你将学到的核心技能。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

总结

本节课中，我们一起学习了阿尔伯塔大学软件产品管理专项课程的总体介绍。我们了解了课程的目标是培养从产品构思到交付的全流程管理能力，课程结构包含理论学习和实践项目，并强调了沟通协作与敏捷实践的重要性。

024：课程介绍与概述

在本节课中，我们将对《软件流程与敏捷实践》这门课程进行整体介绍，了解其核心目标、课程结构以及你将学习到的关键知识。

大家好，我是 Ken Wang。欢迎来到软件产品管理专项课程中的《软件流程与敏捷实践》课程。

这门课程将为整个专项课程提供基础要素，并作为描绘我们专项课程结构的知识支柱之一。

在本节概述中，我将为你预览你将学习的内容，同时描述本课程的基本形式和目标。

在本系列课程的导论课中，我曾提到，开发更好的软件涉及三个目标。这些目标是：开发正确的产品、正确地开发产品以及正确地管理产品。

我还提到，开发一款优秀的软件产品需要许多人的协同工作。那么，是什么帮助你将目标与人员连接起来呢？答案是流程与实践。

为了避免项目陷入混乱，你需要引入结构和规范。在本课程中，你将学习如何利用流程来组织软件项目。你还将学习有助于实现更好软件目标的实践方法。

本课程包含四个模块。

以下是第一模块的内容简介。

在第一个模块中，Or Ptzel 将解释什么是软件流程，并描述它如何分解为阶段、活动和任务，以帮助你组织工作。如果你不熟悉软件开发，也无需担心，她还将描述制作软件的关键活动。

上一节我们介绍了课程的第一个模块，接下来我们看看第二模块。

在第二个模块中，Ra Pette 将描述一系列软件流程模型。你将学习这些模型，涵盖从早期的线性模型到现代的迭代与并行模型。你们还将讨论不同形式的软件原型设计，这能帮助你通过更精细版本的循环来交付产品。本模块将帮助你从不同的流程模型和原型策略中进行选择，并为你的项目进行定制。

在了解了不同的流程模型后，第三模块将聚焦于具体的实践方法。

在第三个模块中，Morgan 将回归，引导你学习特定的敏捷实践，这些实践往往与现代软件流程配合得最好。她将介绍两种流行的敏捷方法论：专注于开发的极限编程，以及专注于管理的Scrum。

在学习了敏捷实践之后，最后一个模块将介绍与之互补的精益思想。

在第四个也是最后一个模块中，Brad 将讨论精益软件开发的原则，这将是对敏捷原则的补充。精益将帮助你减少项目中的浪费，并提供提高产品整体质量的解决方案。你们还将讨论看板，作为一种可视化任务进度的方法。

在本节课中，我们一起学习了《软件流程与敏捷实践》课程的整体框架。课程结束时，你将掌握丰富的流程与实践知识库。你将能够将它们应用到你的下一个项目中，以组织团队并开发出更好的软件产品。

025：流程与实践 🚀

在本节课中，我们将学习软件开发中的核心概念：流程。我们将探讨什么是流程、流程的结构，以及它如何组织软件产品的开发工作。

什么是流程？

流程是软件开发的重要组成部分。事实上，流程往往会自然出现。在高层次上，流程将软件产品的开发组织成不同的阶段。通常，你可以将产品视为从一个阶段进入下一个阶段，每个阶段都有特定类型的工作。

正如我们将在本课程中发现的，软件开发流程并非像从头到尾遵循食谱那样简单。你需要进行改进、优化想法、尝试实验，甚至可能需要回溯，才能得到一个可接受的、可工作的产品。

软件可以持续很长时间并经历许多变化。想想你的智能手机应用需要更新的频率。每次你收到更新应用的通知，那就是产品的一个新版本正在发布。由此可见，即使在初始发布一个可工作的产品之后，进一步的开发和测试仍在继续。

生命周期流程

我们在本专项课程中讨论的许多流程都是生命周期流程。这意味着它们组织软件从最初构想到最终产品退役的整个生命周期。

然而，流程并不必须代表产品的整个生命周期。在生命周期流程中，可以存在子流程。例如，你可以有一个用于在产品中查找和修复错误的子流程。

无论是生命周期流程还是子流程，其结构都是相同的。现在让我们来看看这个结构。

流程的结构

流程被组织成阶段。多年来，人们提出了许多不同的生命周期流程模型。对于生命周期流程，根据流程模型的不同，这些阶段可能有不同的名称。这些阶段可以组织成顺序执行、迭代执行或并行执行。

生命周期流程的阶段示例如下：

规格说明阶段：构思产品想法、获取和表达需求的阶段。
设计与实现阶段：进行产品设计和开发的阶段。
验证与确认阶段：评估产品以确保其按预期工作并满足客户需求的阶段。

阶段示例

这个任务会出现在软件生命周期流程的哪个阶段？
A. 规格说明
B. 设计与实现
C. 验证与确认

答案：A. 规格说明
定义将要实现到产品中的功能是规格说明阶段的一部分。

阶段、活动与任务

上一节我们介绍了流程的阶段，本节中我们来进一步分解流程。

阶段由活动组成，而活动是相关任务的集合。一个活动的例子是“创建测试”。所有与创建测试相关的任务都将归入该活动。这些任务可能包括编写测试框架代码，以及设计和编写测试用例。我们将在下一课中详细查看软件工程活动的示例。

正如刚才所说，活动是一组相关的任务，现在让我们具体看看这些任务。

任务是真正完成工作的地方，无论使用什么流程。任务是项目中需要完成的、小而可控的步骤。它们是完成一个活动，并最终完成流程整个阶段的基石。

所有完成工作的元素都与任务有某种关系。任务的例子包括：

编写一段源代码
设计一个功能
编写文档
安装一个库
测试一个功能

任务的依赖关系

任务之间可能存在依赖关系。也就是说，一个依赖于另一个任务的任务必须等待那个任务完成。依赖关系意味着任务之间存在必要的顺序。

例如：

你不能遛狗，除非狗戴着狗绳。
你不能系上狗绳，除非狗戴着项圈。
因此，遛狗依赖于你系上狗绳，而系上狗绳依赖于你戴上项圈。

在软件开发的语境中：

你无法通过某个功能的测试，除非源代码已经编写完成。
你无法编写源代码，除非该功能已经设计完成。
因此，通过功能测试依赖于源代码的编写，而源代码编写又依赖于功能的设计。

总结

本节课中，我们一起学习了软件开发流程的基本概念。我们了解到流程将工作组织成阶段（如规格说明、设计、验证），阶段由活动构成，而活动则是相关任务的集合。我们还探讨了任务之间可能存在的依赖关系，这决定了工作的执行顺序。理解这些基础概念是掌握后续更具体的流程模型和敏捷实践的关键。

026：3_02_2-1-1a-流程与实践

在本节中，我们将学习软件工程中的核心概念：任务、角色、工作产品和资源。我们将探讨它们如何相互关联，共同构成软件开发流程的基础。

任务与角色

任务也与角色相关。角色是一个人承担或扮演的职责。

软件工程中一些角色的例子包括程序员、测试员、首席执行官、客户或产品经理。

一个实际的人可以扮演一个角色，并执行与该角色相关的任务。简而言之，角色执行任务。团队中的每个人在担任某个角色时，都有特定的责任或任务需要执行。

例如，程序员可能承担为某个功能编写代码的任务。测试员可能被分配去测试该功能。而产品经理可能会在该功能完成后进行审查，以确保其工作方式符合客户的期望。

你可以看到角色如何帮助根据所涉及的团队成员来组织工作。

概念应用示例

以下是访客角色可以执行的任务：
A. 向个人资料添加可选信息。
B. 创建账户。
C. 搜索食谱。
D. 浏览食谱。
E. 发布食谱。

根据之前的说明，用户需要登录账户才能发布食谱。因此，选项E不正确。同样，要拥有个人资料，用户需要拥有账户，因此答案A也不正确。说明中提到两种用户类型都可以搜索和浏览食谱，这意味着这些任务可以由访客角色执行。此外，访客将能够创建账户以成为账户持有者。

因此，正确的答案是 B、C 和 D。

工作产品

接下来我们将要探讨的元素是工作产品。

工作产品是任务产生的输出。这个输出可以是开发过程中涉及的任何东西，而不仅仅是最终产品。工作产品确实包括最终产品，但也包括其他中间输出，例如设计、需求、源代码、测试用例和内部文档。

由于工作产品是任务的输出，我们可以说 任务产生工作产品。

然而，有时任务也会使用工作产品作为输入。例如，为某个功能编写源代码的任务会参考该功能的设计。该设计是先前创建设计任务的输出。因此，任务也使用工作产品。

资源

最后，任何任务要完成，都需要资源。

资源是任何能够改进、推进或资助待完成工作的东西。这些可以是时间、金钱、技术、知识或人员等。因此，我们可以说 任务消耗资源。

为了更直观地理解这个关系图，让我们看一个例子。

综合示例

假设我们正在开发一个应用程序，你的客户要求用户能够上传个人资料图片、更改姓名和更新个人描述。这些就是我们的需求。

我们必须做的一项任务是编写上传个人资料图片的测试。包含此任务的活动是“创建测试”。这个任务将由测试员角色执行。该任务消耗许多资源，如时间、金钱和技术。该任务产生的工作产品是测试用例。该任务也使用需求文档作为工作产品，因为你希望验证产品是否符合其中指定的需求。在本例中，我们希望测试用户能够上传个人资料图片。

练习：区分活动与任务

你被分配到一个新项目。在这个项目中，你的团队正在为当地图书馆开发一个新的数据库和借阅系统。它使用一个移动应用程序将书籍借阅到用户的账户。

西奥多是你的开发团队中的一名程序员。他被分配了以下工作：为向数据库添加新书编写源代码、建立数据库、为帮助页面编写文本，以及执行创建账户的测试。

在这些分配的工作中，哪一项是活动而不是任务？
A. 为向数据库添加新书编写源代码。
B. 建立数据库。
C. 为帮助页面编写文本。
D. 执行创建账户的测试。

答案B是最正确的答案，因为建立数据库涉及许多任务。西奥多将不得不执行诸如设计数据库、为数据库编写代码、托管数据库以及将当前数据库转移到新数据库等任务。任务是指像A、C和D中那样的低层次具体行动。在“建立数据库”这个高层次活动中，可能包含许多低层次的任务。

总结

在本节中，我们一起学习了软件工程中的几个核心概念及其关系。我们明确了角色执行任务，任务产生工作产品，同时也使用工作产品作为输入，并且任务消耗资源。理解任务、角色、工作产品和资源之间的这些联系，是掌握软件流程管理和组织团队工作的基础。

软件产品管理课程2：软件流程与敏捷实践：第4.3.2-1-1b节：流程与实践

在本节中，我们将探讨如何更有效地运用软件流程，并介绍一系列被称为“实践”的具体战术。我们将了解实践如何为流程提供指导，以及它们如何帮助团队提升效率、减少浪费并交付更好的软件产品。

我们已经了解了什么是软件流程，但如何才能更有效地运用它们呢？

实践是软件产品经理用来使流程顺利执行的具体战术。它们为开发的各个方面提供指导，例如如何安排和组织任务、防止资源浪费以及监控工作产品的开发。

本课程将涵盖多种实践。以下是一些实践的例子：

规划哪些功能应包含在版本发布中。
估算任务的持续时间。
召开简短的每日站会。

这些实践通常被集合成一套方法论。方法论即是一组实践的集合。基于敏捷宣言的方法论被称为敏捷方法论，其中包含敏捷实践。Scrum 就是一个敏捷方法论的例子。

可以这样理解：敏捷宣言提供了一种哲学理念，而敏捷方法论则提供了具体的指导方针和规则。

无论你使用何种实践，它们的目的都是为项目中涉及的各项活动提供结构。这种结构可以帮助你有效地规划项目、按时交付、改善沟通、跟踪进度，并最终交付更好的软件。

例如，在需求规格说明阶段，有许多实践概述了如何从客户那里获取和表达需求。

在设计与实现阶段，你会看到许多指导设计和规划的实践。

还有更多的实践建议开发应如何进行。这些实践可以包括如何使项目更灵活地应对变更，以及如何跟踪开发进度。这些实践能帮助你判断项目是否按计划进行。跟踪能让你尽早知道是否落后于时间表。这些实践还能展示项目已完成多少以及剩余多少工作。这不仅为你的开发团队提供了信息，也使你的项目更加透明。你可以快速、轻松地向客户展示项目状态，并管理项目范围。

在验证与确认阶段，同样概述了许多实践。许多方法论鼓励测试和反思。这确保了产品按预期方式工作，并且完全符合客户的意图。

你和你的开发团队正努力在开发中实施一些敏捷实践。你选择采纳的一个实践是：每两周向客户交付一个可工作的原型以获取反馈。这个实践属于流程的哪个阶段？A. 需求规格说明，B. 设计与实现，还是 C. 验证与确认？

每两周向客户提供一个可工作的产品，是确保团队交付内容符合客户期望并令其满意的绝佳方式。这被称为确认。因此，正确答案是 C. 验证与确认。

深入到任务层面，有许多实践建议如何有效地安排任务。还有一些实践旨在建立开发所涉及角色之间的有效工作关系。大多数方法论鼓励并促进客户、产品经理和开发人员之间的开放沟通。开发人员之间的开放沟通可以实现高效的开发，因为期望明确，并且每个人都知道其他人在做什么。

采用良好的实践还能减少资源浪费。这种浪费可能是时间、材料或金钱。有效的规划和沟通可以防止工作被多人重复完成，也能防止开发人员开发出不完全符合客户意图的功能。这有助于保持项目按计划进行，从而有助于控制预算。

流程和实践的一大优点是它们具有灵活性和可定制性。你可以借鉴各种流程和实践的某些方面，创造出满足你所有需求的东西。它们也可以随着时间的推移而改进和发展。

流程和实践有许多好处，是产品经理不可或缺的工具。通过学习多种不同的软件流程和实践，你将能够生成或选择一套适合你和你的团队的高效流程与实践组合。

总结

本节课中，我们一起学习了以下核心概念：

我们将流程定义为将软件产品开发组织成不同阶段或步骤的方式。流程可以是生命周期流程（建模软件产品的整个生命周期），也可以是生命周期流程内的子流程。
生命周期流程被组织成多个阶段，例如：需求规格说明、设计与实现、验证与确认。
每个阶段由相关的活动组成，活动是一组相关的任务，而任务则与角色、工作产品和资源相关联。
敏捷实践是可以在流程中应用的指导方针。它们已被证明能带来诸多益处，例如：提升沟通效率、跟踪项目进度、管理风险以及减少浪费。

在本课中，我们简要讨论了流程中工作的组织方式。接下来，我们将更详细地研究软件工程活动，以便你能对整个软件开发过程有更清晰的认识。下节课见。

028：5_01_2-1-2-软件工程活动

在本节课中，我们将深入学习软件工程活动。我们将详细探讨在软件开发过程中可能发生的各种活动。了解一个流程可以涵盖的所有活动后，您将对流程在软件开发中的定位及其用途有更清晰的认识。

上一节我们介绍了流程与实践，并将“活动”定义为一组相关的任务。本节中，我们来看看这些活动的具体内容。

什么是软件工程活动？

一个软件工程活动是软件开发中一组相关的任务。每个活动都有输入工作产品和输出工作产品。

可以将活动想象成一台工厂机器：输入工作产品进入，输出工作产品是结果。

输入工作产品：是完成该活动所必需的工作产品。
输出工作产品：是在该活动过程中生成的工作产品。

示例：一个软件工程活动是为所有功能编写代码。输入工作产品是功能设计和需求，输出工作产品是该功能的源代码。这个活动在您从设计中提取所有元素并实现功能的所有需求后完成，最终输出功能的源代码。

活动示例：撰写论文

让我们将撰写论文想象成一个软件工程活动。如果完成的论文是输出工作产品，您认为最佳的输入工作产品是什么？

A. 时间和金钱。
B. 关于该主题先前生成的大纲和笔记。
C. 电脑和键盘。
D. 研究员和作家。

分析：

答案A不正确，因为时间和金钱都是资源。它们有助于撰写论文，但不是工作产品。
答案C不正确，因为电脑和键盘也是必要的资源，但不是工作产品。
答案D不正确，因为研究员和作家是角色，而不是工作产品。
答案B是正确的，因为关于该主题生成的大纲和笔记是在早期任务中生成的工作产品。它们将为您提供撰写论文所需的信息。

项目管理活动

我们将要看的第一个软件工程阶段是项目管理。项目管理活动贯穿整个开发过程，包括以下内容：

以下是项目管理活动包含的具体任务：

创建流程：选择或创建流程是管理项目的重要组成部分。
设定标准：需要设定标准以确保团队工作的一致性。团队需要决定开发的各个方面，如编码规范、文档级别、测试策略以及“完成”的定义。例如，一个开发团队的“完成”定义可以是：源代码按照规范编写、为开发者和最终用户编写了文档、并且经过了测试。
管理风险：通过不断分析和缓解风险来完成，例如潜在的业务、技术、管理、进度和安全风险。风险管理的输入可能包括历史项目记录、项目估算、软件详细设计和生命周期流程。本质上，项目中任何可能出错的部分都是风险管理的输入工作产品。风险管理的输出工作产品将是一个风险计划，概述潜在风险及其相应的缓解计划。您将在《软件产品敏捷规划》课程中更详细地学习风险管理。风险管理绝对是您应该经常重温的活动，通过不断审查风险，您将识别并缓解在整个开发过程中可能出现的新风险。
执行估算：估算将是您在软件开发中的一项重要活动。开发时间表基于对完成任务所需时间的估算。当估算偏差过大时，您的进度就会受到影响。估算活动涉及的任务包括收集估算数据、计算估算和评估估算。估算所需的输入工作产品包括需要完成的任务列表。您还需要了解您的开发人员通常完成任务需要多长时间，我们称之为任务开发速率。输出工作产品将是您的估算结果。您的估算结果将在您生成进度表时作为输入工作产品使用。您将在《软件产品敏捷规划》课程中获得更多关于估算的经验。
分配资源。
进行度量。
改进流程。

总结

本节课中，我们一起学习了软件工程活动的核心概念。我们明确了活动是一组具有输入和输出工作产品的相关任务，并通过撰写论文的例子加深了理解。随后，我们深入探讨了项目管理这一贯穿开发始终的关键阶段，详细了解了创建流程、设定标准、管理风险和执行估算等具体活动及其输入输出。理解这些活动是掌握软件开发流程的基础。

029：软件工程活动

概述

在本节课程中，我们将学习软件工程中的核心项目管理活动与需求规格说明阶段。我们将了解如何分配资源、进行度量、改进流程，并深入探讨需求阶段的各项具体活动。

项目管理活动

上一节我们介绍了软件工程的基本框架，本节中我们来看看其中几项关键的项目管理活动。

分配资源

分配资源是接下来的活动。我在本课程的第一个模块中提到，资源是指任何能够改进、推进或资助项目的事物。

资源可以是时间、资金或设备等。分配资源活动包括规划和安排人力资源。这意味着分解工作计划并分配任务。

进行度量

进行度量是另一项重要的项目管理活动，它涉及定义、计算和分析度量数据等任务。

度量用于跟踪和评估产品和/或流程。这些度量可以衡量产品中的缺陷密度、团队完成任务的速度、已完成的功能数量等等。您将在关于软件改进的评审和度量的课程中了解更多关于度量的知识。

改进流程

这引出了下一项活动：改进流程。您必须认识到，就像产品一样，流程本身也可以进行改进。

对流程进行测试和评审，与您的开发团队对产品进行测试和评审同样重要。您可以在此应用一些度量数据的结果，以便在下一次计算时，您的流程能获得更好的评分。

案例分析：凯文的项目管理

凯文是一个开发团队的软件产品经理，该团队正在为本地外卖餐厅开发一个订餐应用。他上周因流感在家休息。当他返回时，他想知道在他离开期间，哪些项目管理活动已经完成。

凯文需要完成以下哪项活动？
A. 分配资源。
B. 管理风险。
C. 执行估算。
D. 进行度量。

解析：当所有输入工作产品被消耗且所有输出工作产品被生产出来时，一项活动才算完成。迭代日程表、风险计划和进度跟踪图表都是项目管理活动的输出工作产品。任务时间估算是执行估算活动的输入工作产品。由于凯文只更新了任务开发速率而没有估算，因此该活动尚未使用其所有输入并产生所有输出。所以，正确答案是 C。

需求规格说明阶段

接下来，我们来谈谈需求规格说明阶段。这个阶段通常被视为初始阶段。产品的要求在此阶段确定。

但这并不意味着它只发生在开发初期。需求规格说明阶段会经常被重新审视，以更新和改进产品在后续开发中的需求。需求规格说明阶段的活动在关于软件需求和客户需求的课程中有详细讲解。

以下是需求规格说明阶段包含的活动：

识别想法或需求：这是软件开发中一项非常重要的活动。没有想法，就没有产品可开发。花时间认真思考产品将有助于创造出优秀的软件。
需求获取
需求表达
需求优先级排序
需求分析
需求管理
制定潜在方案

一旦有了想法，下一步就是处理需求。共有五项需求活动：需求获取、需求表达、需求优先级排序、需求分析和需求管理。您将在软件需求和客户需求的课程中更详细地重温这些需求活动。

一旦需求就位，就可以准备制定潜在方案了。

案例分析：制定潜在方案

您是一家连锁咖啡店的产品经理。您的客户希望您的开发团队创建一个应用程序，允许最终用户通过该应用支付咖啡费用。您正在与您的开发团队一起进行“制定潜在方案”活动。

以下哪项会是此活动的输入工作产品？
A. 估算
B. 已定义的度量
C. 内部文档
D. 需求待办列表

解析：在开发过程中的某个阶段，您会使用所有这些工作产品。估算通常在创建日程表时用作输入。已定义的度量在您计算和分析度量时用作输入工作产品。内部文档在开发可执行代码和测试时使用。您将使用需求待办列表来制定潜在方案，因为您需要确切知道正在开发什么。因此，D 是正确答案。

总结

本节课中，我们一起学习了软件工程中的几项核心项目管理活动：分配资源、进行度量和改进流程。我们还深入探讨了需求规格说明阶段，了解了从识别想法到制定潜在方案的一系列关键活动。理解这些活动和阶段是有效管理软件项目的基础。

030：软件工程活动

在本节课中，我们将要学习软件项目在完成需求规划后，进入设计与实现阶段，以及后续的验证与确认阶段所涉及的核心工程活动。我们将了解产品经理在这些阶段中的角色与职责，并学习如何有效地跟踪和监控开发过程。

设计与实现阶段

上一节我们介绍了项目规划与需求定义，本节中我们来看看设计与实现阶段。当项目需求明确后，便进入设计与实现阶段。这些活动主要由开发人员执行，因此我们不会深入技术细节。作为产品经理，你需要帮助跟踪和监控此阶段的工作。

设计与实现阶段的活动包括：

以下是该阶段包含的具体活动列表：

设计架构：规划软件的整体结构和组件关系。
设计数据库：设计数据存储的结构与访问方式。
设计接口：定义软件内部模块之间或与外部系统交互的规范。
创建可执行代码：即编写程序代码。
集成功能：定期将不同模块的代码组合在一起，确保兼容性。
编写文档：为开发和最终用户编写必要的说明材料。

这是你的开发团队大显身手的阶段，但在他们开始编程之前，你和团队需要先设计产品。这包括设计架构、数据库和接口。然后，程序员才能开始编写可执行代码。

你的团队应定期集成或合并他们的代码，以确保代码兼容。

最后一项活动是编写文档。你可能会想，敏捷宣言不是说不需要文档吗？宣言指出，可工作的软件胜过面面俱到的文档。然而，文档仍然是软件开发中非常重要的一部分。

好的文档有助于新开发者加入团队，或处理他们不熟悉的开发部分。这类文档称为内部文档。

你的团队可能还需要为最终用户编写文档，例如使用手册或培训材料。这类文档称为外部文档。

作为产品经理，你负责帮助跟踪和监控开发过程。你的团队刚刚完成了本次迭代的规划，并已开始为产品编写代码。现在规划已完成，你环顾四周寻找可做之事。你看到桌面上有上次迭代创建的功能说明书，墙上贴着团队决定使用的度量指标列表，邮箱里有老板发来的团队资源分配邮件，书架上则放着最新版的风险计划。

你决定开始监控本次迭代的开发进度。你认为以下哪项工作成果能帮助你跟踪开发？
A. 外部文档
B. 已定义的度量指标
C. 已分配的资源
D. 风险计划

外部文档是供最终用户使用的，而非用于跟踪。已分配的资源用于推进和支持开发。风险计划在开发开始后非常有用，但不用于跟踪进度。你的团队决定使用的度量指标对于跟踪至关重要。你必须重新计算和评估这些指标，以确保开发有效且项目按计划进行。因此，B是正确答案。

验证与确认阶段

现在，让我们看看开发下一阶段——验证与确认阶段的活动。验证与确认阶段旨在评估你的产品是否实现了预定功能，以及是否满足客户需求。与其他阶段一样，验证与确认阶段也需要经常进行，而不仅仅是在生产结束时。你需要不断验证和确认产品，以确保开发方向正确。

验证与确认活动包括：

以下是该阶段的核心活动列表：

制定测试流程
创建测试用例
执行测试
报告评估结果
进行评审与审计
向客户演示
进行回顾会议

测试是验证与确认阶段的重要组成部分，包含许多活动，如制定测试流程、创建测试、执行测试和报告评估结果。这些活动有助于验证产品是否按预期工作。

为了确认产品满足客户和最终用户的需求，你需要完成诸如进行评审、审计和向客户演示等活动。这是你获取反馈以改进产品的环节。如果最终用户或客户不认可你的产品，它很可能会失败。

回顾会议是由你的开发团队进行的总结练习。这些回顾可以反思产品和/或开发过程。产品和过程总是有改进的空间，回顾会议有助于找出下次可以做得更好的地方。

总结与展望

如你所见，软件开发涉及许多活动。重要的是要记住，在敏捷开发中，你需要反复经历这些阶段，并且它们不总是顺序进行的。

通过排序并确定何时以及多久重新进行这些活动，你就创建了一个流程。现在，你可以利用刚刚介绍的活动来创建一个适合你团队的流程。

在下一个模块中，你将接触到一些既定的流程模型。

031：线性模型 🏗️

在本节课中，我们将要学习软件工程发展史上几种重要的线性过程模型。我们将探讨它们的工作原理、各自的优缺点，并理解它们为何被开发出来，以及为何后来在行业中变得不那么常见。

概述

上一模块中，摩根介绍了什么是流程与实践，以及它们为何对组织工作有用。她还解释了什么是软件工程活动，并详细介绍了该领域中常见的活动。

在本模块中，我们将稍微退一步，讨论一些在过去被证明有用的流程，以及它们如何演变成我们今天看到的更常见的流程。我们将从一些简单的流程开始，然后探讨流程如何演变以解决这些简单流程的缺陷。

请记住，就像大锤和打桩机一样，一个流程更先进、更高级，并不意味着另一个流程就变得无用或过时。理解所有可用的选项及其优缺点非常重要，否则你可能会陷入使用不适合当前任务的流程的陷阱。

线性过程模型简介

在入门课程中，你已经瞥见了在学习软件工程流程时可能遇到的不同流程。线性过程模型遵循一个模式：各个阶段一个接一个地完成，不重复之前的阶段。产品在设计、开发和发布过程中，不会重新审视早期阶段。

在本课中，我们将更详细地探讨这些线性生命周期过程模型。我将讨论它们的工作方式，以及各自的优缺点。这将让你了解线性模型为何被开发出来，以及它们最终为何在领域中变得不那么常见。

在继续之前，让我们测试一下你对线性过程模型的理解。

以下是关于线性过程模型定义的选项：

A. 每个阶段按顺序发生，当所有阶段完成后，循环回到开始。
B. 每个阶段与其他阶段并行发生，直到产品完成，阶段之间或阶段内没有重复。
C. 每个阶段按顺序发生，从不循环或重复。
D. 每个阶段可以重复，直到产品完成。

正确答案是 C。线性过程模型不支持流程阶段内或阶段之间的循环。允许循环的流程模型称为迭代模型。线性模型还要求阶段按顺序完成，阶段之间没有重叠。允许重叠的流程模型称为并行模型。你将在本模块后面学到更多关于迭代和并行过程模型的知识。

瀑布模型

首先，我们来谈谈你可能听得最多的一个模型：瀑布过程模型。如果你正在研究软件工程，你可能听说过这个。旧的瀑布模型因其低效和限制性而受到批评。让我们更详细地讨论瀑布模型，以便了解它的优点和缺点。

你可能已经在生活的许多方面使用过类似瀑布的过程。实际上，它只是一个基本的线性过程：一件事接一件事地发生。它之所以被称为瀑布，是因为流程的每个阶段都由前一个阶段批准的工作产物输入。

例如，在需求阶段结束时，你会得到一份产品需求文档。这份文档被批准后，输入到下一个阶段——设计阶段。在这个阶段结束时，你将完成一组模型、架构和业务规则。然后，这项工作被签署，并输入到瀑布的下一个阶段，依此类推。

这个模型允许开发人员快速开始构建产品。它允许他们通过早期确定范围并坚持执行来避免需求变更的问题。瀑布模型非常强调记录需求和架构等内容，以便开发团队对软件达成共同的书面理解。

然而，瀑布模型对变化的适应性不强。也就是说，它不是很敏捷。瀑布模型的一个主要缺点是它不允许开发团队审查和改进他们的产品。正如我们之前告诉你的，软件是一个非常动态的东西。瀑布模型的设计初衷就不是为了应对可能需要重新审视早期阶段的中途变更。

因此，存在一些瀑布模型的变体，允许对早期阶段及其活动进行反馈，以支持某些变更。但是，如果你的客户在需求文档批准后需要变更呢？不幸的是，客户直到最后才能看到产品，这可能是许多个月之后。可以理解，这种缓慢的响应常常导致客户失望。

瀑布模型有其作用，但它无法确保正在进行的工作得到适当的验证，这是一个严重的缺陷。

V模型

为了解决这个问题，软件开发的V模型应运而生。这与瀑布模型非常相似，事情按顺序一件接一件地发生。不同之处在于，它强调验证活动，以确保实现与设计行为相匹配。这也确保了实现的设计符合需求。其理念是将每个验证级别组织到相应的阶段，而不是一次性全部进行。

V模型与瀑布模型的不同之处在于，V模型明确地将自己分为两个分支，因此得名V。与瀑布模型一样，V模型从需求开始，输入到系统架构和设计。这个分支由V的左侧表示，从上到下进行。在这个分支的末尾，重点从设计转移到实现，这是V的底部。一旦实现完成，模型的重点就转移到验证活动，这由V的右侧表示，从下到上进行。

右侧的每个阶段都旨在检查V左侧的相应阶段。

这里有一个例子。在V模型的左侧，你的开发团队计划稍后要实现的单元测试。这些单元测试旨在确保你编写的代码确实解决了你试图解决的问题。当处于V右侧的单元测试阶段时，这些单元测试会在代码中运行，以确保在一切编写完成后，所有代码都能正常运行。测试运行完毕且一切顺利后，流程进入集成测试阶段。这样，V的右侧验证了左侧。

V模型具有与瀑布模型相同的优点和缺点。它应用起来很直接，但没有考虑到软件开发的重要方面，比如变更的必然性。然而，V模型确实允许开发团队验证流程构建阶段的工作。所以我们有所进展，但客户仍然要等到最后一切完成时才能看到成品。

让我们研究一下描述软件开发V模型的图表。如果你处于集成测试阶段，当你运行测试时，你正在验证哪个阶段？

A. 单元测试
B. 编码
C. 高层设计
D. 操作测试

答案是 C，高层设计。当你在高层设计阶段时，你创建测试，然后在集成测试阶段运行这些测试。你不会运行来自下一个或最后一个阶段的测试，也不会运行来自编码阶段的测试。

SA/SD模型

现在我们需要一个流程，允许我们在过程中让客户参与进来，而不是只在产品被认为完成时才让客户参与。这就是SA/SD模型（结构化分析与结构化设计模型）的用武之地。这个模型与前两个非常相似，因为它也是软件开发的线性模型。然而，它也改进了它们，因为它为你提供了在整个过程中非常需要的客户互动。

SA/SD模型的独特之处在于它区分了客户和开发团队。在这个模型中，需要客户在场的任务和只需要开发团队的任务被区分开来。这些客户任务穿插在整个过程中，以便在有意义的时刻收集反馈。

与前两个概念相似，你可能已经领先于我了。是的，SA/SD模型也遭受与前两个线性模型相同的缺点。它应用起来非常容易，但不能很好地应对变化。

总结

在本节课中，我们讨论了软件开发历史上三个重要的敏捷宣言发布前的流程模型：瀑布模型、V模型和SA/SD模型。它们都有共同点，也有不同之处。

这些模型的主要共同点是，它们都包含按顺序一个接一个发生的阶段。每个人都很清楚接下来要做什么。这个共同特征是它们共享优点和缺点的主要原因。它们各自允许开发以一种直接的方式进行，但它们也极大地限制了项目以适应流程。

本质上，这些早期的线性过程模型遵循一种软件产品的制造观：即根据特定要求进行机械加工和组装。一旦生产出来，产品只需要轻微的维护保养，有点像家用电器。因此，重点在于前期正确获取需求，之后不再更改。

实际上，开发软件产品是一项创造性的工作，需要实验和不断的返工。此外，在过去，与人力相比，计算机时间很昂贵。重点是使编程等任务对计算机高效，但不一定对人高效。对于软件开发来说，编写代码和看到结果之间的周期时间可能很长。这不利于开发人员尝试小型编程实验来快速测试他们的想法。然而，这确实把重点放在了试图第一次就做对并避免返工上。线性过程模型符合这种早期的思维方式。

尽管如此，在为新的开发人员记录软件产品内部结构时，你可能仍然会通过阶段和相关文档以线性方式描述项目，即使它可能遵循了其他一些流程。这提供了一种秩序的表象，使得新开发人员不需要重历整个项目来初步了解其当前实现。这类似于你在教科书中找到的数学证明和科学理论的干净、理性的版本。

在下一课中，我将介绍下一代的软件流程：迭代模型。在那里，我将告诉你一个叫做螺旋模型的过程及其优点。我们下节课见。

032：螺旋模型 🌀

在本节课中，我们将学习一种迭代式软件开发过程模型——螺旋模型。我们将了解其基本结构、核心阶段、关键特性以及优缺点。通过对比上一课介绍的线性模型，你将理解迭代模型如何通过循环往复的步骤来改进软件开发过程。

概述

上一节我们介绍了一些最早的线性软件开发过程模型。本节中，我们将探讨一种迭代式模型——螺旋模型。与线性模型不同，迭代模型允许重复过程的某些阶段，形成循环。螺旋模型是这类模型的典型代表，它通过周期性的迭代来逐步构建和完善软件产品。

螺旋模型简介

螺旋模型由巴里·博姆于1986年提出。它概述了一个通过重复访问已完成的阶段来设计和实现软件系统的基本过程。请注意，其中一些概念可能涉及技术细节。如果你需要澄清某个概念，请查阅本课的相关课程资源，那里提供了所有讨论内容的参考资料。

模型的基本结构

以下是螺旋模型的一个简化解释。你可以立刻明白它为何被称为“螺旋”模型。

从基本层面看，该模型由四个象限组成。当你推进这个过程时，你需要从一个象限移动到另一个象限。可以将这四个象限中的每一个视为一次迭代中的一个阶段，而一次迭代是指完成一个完整螺旋（即所有四个象限阶段被完成一次）的持续时间。

每个阶段都包含摩根在第一模块中定义的活动。

螺旋模型的四个阶段

以下是螺旋模型一次迭代中四个象限（阶段）的核心活动：

确定目标与方案：在此阶段，你为当前迭代制定目标、明确需求，并生成解决方案。
评估风险与方案：在此阶段，你识别并评估风险，同时评估上一步生成的解决方案。
开发与测试：在此阶段，你根据选定的方案，开发和测试当前迭代的产品。
规划下一迭代：当你获得一个满足目标的产品后，你便进入此阶段，为下一次迭代制定计划。

如果每个象限是迭代的一个阶段，那么完成一次迭代后，你便进入下一次迭代。这就是螺旋模型的基本流程。你通过重复这个阶段循环来逐步构建产品。

工作流程示例

例如，你可能会通过确定客户和用户需求来启动一个螺旋模型项目。然后，你会构思满足这些需求的潜在解决方案。之后，你可能会选择评估这些方案。接着，你可能会构建产品的初始原型，并评审下一次迭代需要完成的工作。这便是一次迭代。

在下次迭代中，你可能会重新开始，定义本次迭代的目标（例如，为你刚刚构建的原型添加新功能）。然后，你会评估这些功能，并着手构建你认为合适的功能。接着，你评审下一次迭代需要完成的工作，并继续推进，直到项目完成并令客户满意。

知识检查

乔纳森正在使用螺旋模型构建他的软件。他在穿孔卡编程和使用瀑布模型方面拥有丰富经验，因此螺旋模型的迭代对他而言是一个重大转变。他刚刚完成了产品的开发和测试，但不记得模型的下一个阶段是什么。

问题：在螺旋模型中，开发和测试阶段之后是哪个阶段？
A. 下一次迭代
B. 规划下一次迭代
C. 产品发布
D. 进一步测试

答案：B，规划下一次迭代。因为螺旋模型是迭代式的，你会循环回去，再次开始确定目标并完善设计。但只有在迭代结束时首先规划了设计之后，你才会这样做。

螺旋模型的不变式

尽管遵循螺旋模型的项目在某些方面可能因项目而异，但有六个条件几乎总是保持不变。这些被称为螺旋模型的“不变式”。博姆在其2000年发表的后续论文中首次描述了它们。有趣的是，在大多数情况下，这些不变式实际上也适用于许多其他过程模型。

这些不变式可能相当技术性，因此我们不会详细讨论所有六个，而只涵盖几个关键不变式的核心概念。如果你想了解每个不变式的更多细节，请查阅课程资料，那里有每个不变式的详细描述。

以下是几个关键不变式的核心概念：

并发创建：螺旋模型的第一个不变式指出，软件项目的所有工作产品都应同时创建。这听起来可能有些奇怪，但其基本思想是，如果不同时定义各项内容，就会使项目面临风险。这是因为，如果使用瀑布模型通常的顺序方法，意味着你只能基于有限的信息做出决策。
象限完整性：螺旋模型的第二个不变式非常简单：必须处理模型的所有象限，不能跳过任何步骤。这是因为模型的每个象限都带来价值。如果跳过一个，就会不必要地使项目面临风险，因为你很可能是在对项目做出假设，而假设当然可能是错误的。你不希望基于错误的假设来构建项目。
基于风险调整与产出导向：最后几个不变式相当技术性，因此我们不会深入细节。本质上，它们说明：实施螺旋模型的每个项目，在任何特定活动上花费的时间量，应基于执行该活动所涉及的风险量。它非常注重确保你的决策基于风险数据。其他不变式还提到，螺旋的每次迭代都应产生一个有形的工作产品，并且过程的重点应放在改进整个过程上。

所有这些不变式共同构成了螺旋模型，有助于定义该模型。但你能看出任何问题吗？

螺旋模型的优缺点

尽管螺旋模型在许多方面明显优于线性过程，但它也有其缺点。

缺点之一：规划倾向于在每次螺旋开始时预先进行。根据螺旋的持续时间长短，这可能使得做出准确的估算变得困难。

缺点之二：该过程所阐述的、以计算方式最小化风险的能力，需要大量的分析专业知识。试想一下，为了确切知道在处理一项活动时花费多少时间是过多还是过少，你需要多少数据。这类风险评估任务需要消耗大量资源才能正确完成。

如果你所在的组织使用螺旋模型，很可能你正在处理大型项目，并且拥有多年的经验、数据和技术专长可供使用。

总结

本节课我们一起学习了螺旋模型，这是一个迭代过程的绝佳例子。它以允许在特定间隔修订产品的方式完成任务。与其他过程模型一样，它有其缺点。但它显然与我们之前看到的模型不同，对吗？在下一课中，我们将讨论统一过程模型。请尝试将本课所学内容与下一课的内容进行比较。

033：统一过程模型

在本节课中，我们将学习统一过程模型。这是一种迭代式的软件开发模型，强调通过一系列重复的阶段来构建产品，并允许不同阶段的工作并行进行。

在上一节课中，我们介绍了螺旋模型的基础知识。我们讨论了它的优缺点，以及它在软件开发流程演进时间线中的位置。螺旋模型是一种迭代式软件开发模型，意味着产品是通过一系列重复的阶段构建的。这与我们在本模块开头介绍的线性流程模型（如瀑布模型和V模型）形成对比。

本节中，我们将探讨另一种迭代式软件开发模型：统一过程模型。

统一过程模型概述

统一过程模型是一种迭代式软件开发模型。其基本结构是工作在一系列阶段中，这些阶段会重复进行，直到最终阶段被判定为完成。在大多数统一过程阶段内，开发工作以小型迭代的形式进行，直到该阶段被判定为完成。通常，当一个里程碑达成时，阶段即被视为完成。

统一过程模型试图尽可能强调渐进式开发。它不要求在一开始就确定软件产品的所有需求，而是注重产品架构随时间逐步发展的重要性。架构是构建软件产品所依据的一组设计。因此，在统一过程中，开发团队的重点是开发设计模型以及一个可工作的产品。

虽然统一过程的基本结构是迭代构建，但该模型允许一个阶段的任务与另一个阶段的任务重叠。这被称为并行工作。因此，开发人员不仅可以按顺序经历各个阶段，实际上还可以同时进行诸如设计产品架构和开发测试等工作。

杰夫在设计产品架构的同时，也在为他的代码构建测试。当他遇到问题时，偶尔也会向客户澄清和获取需求。杰夫使用的是哪种软件开发风格？A. 并行开发。B. 迭代开发。C. 增量开发。D. 同步开发。

答案是A，并行开发。由于杰夫同时参与了开发的多个阶段，我们称之为并行开发。

统一过程的阶段

以下是统一过程模型包含的四个主要阶段。

初始阶段

统一过程的第一个阶段称为初始阶段。这个阶段旨在简短，只需足够的时间来确保你有一个足够坚实的基础以进入下一阶段。事实上，初始阶段是统一过程中唯一一个开发工作不以迭代方式进行的阶段。如果你的初始阶段很长，这可能意味着你在初始阶段花费了太多时间来构建需求。你的主要目标是判断是否有足够强大的商业理由来继续开发。这意味着必须有足够好的财务理由来构建产品。

为此，初始阶段要求创建基本用例。用例概述了用户与产品的主要交互。在此阶段，你还需要定义项目范围和潜在风险。

如果你想了解更多关于用例以及如何创建它们的信息，请查看关于客户需求和软件需求的课程。

在初始阶段结束时，你达成了生命周期目标里程碑。此时，你将获得关于产品可行性的合理描述，并准备好进入流程的下一个阶段。

细化阶段

细化阶段是统一过程中第一个实施小型迭代的阶段，我在本节课前面提到过这一点。这个阶段的目标基本上是创建一个产品的模型或原型，我们将在后续进行完善。我们将在本模块后面更详细地讨论不同类型的原型。

目前，此阶段的目的是定义系统架构。开发人员定义在初始阶段构思的需求。他们还开发关键的需求和架构文档，例如用例图和高层类图。这为实际开发奠定了基础。

请记住，此阶段允许迭代。因此，在迭代中构建原型可能会在需求和架构模型被认为足够完善可以继续前进之前，经历重新设计。在细化阶段结束时，开发人员会为下一阶段（构建阶段）制定开发计划。该计划基本上建立在初始阶段开发内容的基础上，并整合了在细化阶段学到的一切，以便构建阶段能够有效进行。

构建阶段

构建阶段非常直接。它是另一个开发可以迭代进行的阶段。它侧重于在细化阶段完成的工作基础上进行构建。这是你产品的核心真正被构建的地方，产品开始成型。

在构建阶段，开发详细的用例来驱动产品开发。这些用例比在初始阶段创建的用例更健壮。构建阶段的用例为产品应如何创建提供了更具体的见解。你的产品在整个构建阶段迭代构建，直到产品准备好发布。此时，你的开发团队开始将产品移交给你的客户和用户。

现在你已经了解了统一过程的初始、细化和构建阶段，让我们测试一下你的理解。

以下哪项描述了细化阶段的主要方面？A. 为项目确定强有力的商业理由。B. 创建用例。C. 创建用例图。D. 创建类图。

正确答案是C和D。用例图和类图是细化阶段的主要工作成果。这并不是说这些工作成果不会在构建阶段出现，只是在细化阶段更侧重于它们。你在初始阶段为项目确定强有力的商业理由。

移交阶段

在此移交阶段，你的产品会进行主要发布。你的开发团队从用户那里获得反馈。正是在这一点上，你才能真正看到你的设计与用户需求的匹配程度。通过收集这些反馈，你的开发团队可以对产品进行改进，创建错误修复和其他版本。

在你的产品完成一次迭代后，有可能再次循环回到统一过程的各个阶段。这适用于你打算为产品创建进一步的主要版本，并将用户反馈作为影响后续开发计划的手段的情况。这些循环会重复进行，直到你和你的开发团队准备好发布你的产品。

总结与展望

本节课中我们一起学习了统一过程模型。正如我在课程开头所说，统一过程是迭代过程的一个例子。但正如你在整节课中所看到的，统一过程也是一个并行过程。与需求、设计和实现相关的活动可以同时发生。

从宏观角度来看，统一过程更像一台打桩机，而不是一把大锤。它是一个非常适合大型项目的流程，这些项目需要大量的细化工作才能使产品保持在正轨上。拥有迭代允许你的产品自然成长，而不会受到前期计划的限制。

在下一节课中，我将讨论原型设计以及原型如何用于驱动软件开发。我们下节课见。

034：原型设计

概述

在本节课中，我们将要学习软件开发中的原型设计。我们将探讨五种不同类型的原型，了解它们各自的目的、适用场景以及如何在实际开发过程中运用它们。理解原型设计对于高效沟通、验证想法和降低开发风险至关重要。

在上一节中，我们介绍了统一过程和螺旋模型作为迭代与并行流程的例子。本节中，我们来看看一个在这些流程中都非常重要的实践：创建原型。

原型并不仅限于我们刚讨论过的流程，在未来的课程中你会越来越多地看到它们的身影。以下是本节课将介绍的五种原型类型。

五种原型类型

图示原型

图示原型是最基础的原型形式。它们可以是画在餐巾纸上的草图、一个简短的幻灯片演示，甚至是几张画有组件的索引卡。无论形式如何，图示原型的核心目的是使用低保真度、一次性的图像来分享想法。

图示原型有助于在投入大量时间和金钱开发产品之前，确定系统的外观和感觉。它们可以为开发团队提供创建解决方案的指导，而不是凭空想象和编程。这种方法通常在时间紧迫、只需要传达基本概念时使用。

示例：你可以将关键功能在绘图程序中画出草图，然后使用幻灯片编辑器将它们链接起来，形成一个无需花费太多精力就能展示产品外观的、更逼真的示例。

探索性原型

如果你有更多时间，并且希望对产品外观有更全面的理解，一些团队会转向我们所说的探索性原型。

探索性原型允许你专注于产品的外观和感觉。你还能通过它来确定构建该产品所需的工作量。你会编写可工作的代码，以便真正了解什么是可行的，并完全预期在学习过程后会丢弃这些工作成果。这种方法昂贵吗？是的，但这比之后才发现产品方案根本不可行要好。

探索性原型背后的常见动机是产品开发者希望研究某个产品想法的可行性。这不再仅仅是看产品长什么样，而是关于开发产品的可实现性，或者在投入更多精力之前产品可能有多大用处。

抛弃型原型

任何产品的第一个版本，或者说几乎所有事物的第一个版本，通常都存在各种问题。因此，为什么不从头开始构建第二个版本，并丢弃第一个呢？你构建的第一个版本就是所谓的抛弃型原型。

你应该知道，第一个版本并非一无是处。从第一个版本中可以学到许多有用的经验教训，并在第二个版本中避免一些问题。抛弃型原型让你有机会从过去的错误中学习，这使你有机会让你的发布软件产品看起来比从第一个版本不断演化而来更加稳固可靠。

增量原型

那么，有没有可能在产品开发过程中重用原型阶段完成的工作呢？这就是增量原型和演化原型发挥作用的地方。它们让你在原型设计上的努力能够延续到最终产品中。

关键思想是让每个后续原型都拥有可工作的软件，其中任何一个都可以作为你软件产品的一个版本发布。当你创建增量原型时，你一次一个增量地构建和发布你的产品。

增量原型分阶段工作，基于一个优先级排序系统。这意味着你需要评估系统的每个组件并为其分配优先级。基于这个优先级，你从零开始开发产品，从最重要到最不重要。

示例：假设你正在开发一个即时通讯应用。

必须做：用户能够通过应用相互交谈。任何与此相关的功能，如查找其他用户、发送/接收消息或文本编辑，都属于最高优先级。
应该做：用户可能希望添加个人资料图片、发布状态更新或群发消息。这些功能属于“应该做”的范畴。
可以做：能够更改消息字体、向其他用户发送自定义绘图或发布链接等功能，可能被归为“可以做”。

有了这些分类，剩下的就是构建你的应用。由于你对产品功能进行了优先级排序，你可以轻松地规划和安排开发工作。

演化原型

我要讨论的最后一种原型是演化原型。

在增量原型中，你从一组核心功能开始，并随着时间的推移添加新功能。在演化原型中，你从一组具备基本形态的所有功能开始，并随着时间的推移对它们进行改进或演化。无论哪种情况，最终产品都是一个功能丰富的产品。

示例：继续以即时通讯应用为例。考虑“添加个人资料图片”这个功能。

初始版本：用户可能需要指定要添加到个人资料的图片路径，这种方式效率不高，但能用。
后续版本：开发者可能允许用户从可用照片的下拉菜单中选择照片。
再下一个版本：你可能会设想系统允许拖放功能。

通过这种方式，你的产品从一个基本的工作原型演变为功能丰富且健壮的产品。

增量原型和演化原型都是创建可工作软件的方法，可以定期展示以获得进一步的反馈。在实践中，你可以混合使用这两种方法。对于开发团队来说，看到产品随着时间的推移逐渐成型，是一个极大的士气鼓舞。

原型在流程模型中的应用

现在，回想一下你在之前课程中学到的关于螺旋模型和统一过程的知识。你能想象原型如何融入这些模型吗？

在螺旋模型中，想象一下你从哪里开始。通常起点就是创建一个原型，对吧？你可能会通过螺旋模型的第一次迭代，仅仅创建一个图示原型。你可以在纸上涂鸦几幅画，了解你的系统将如何工作。对于统一过程的初始阶段，也可以这样说，不是吗？

通过创建原型，你可以更好地可视化产品的功能，从而根据产品可能的样子做出功能决策。但这还不止于此。我敢打赌你已经想到了将图示原型与增量或演化原型结合的可能性。这很有道理，对吧？你的第一个版本只是写在几张纸上的想法。然后，为了进一步测试你的想法，你勾勒出一些关键功能并开始构建。不久之后，你可能会得到一个原型。然后，你可以将该原型带给客户或潜在投资者，以证明产品在概念上是可行的。

这确实是任何类型原型设计的核心理念：获取对你产品版本的反馈。你可以从花费最少的时间开发初始原型开始，以最有效地利用你的资源。

总结

本节课中，我们一起学习了软件原型设计的五种主要类型：图示原型、探索性原型、抛弃型原型、增量原型和演化原型。我们了解了每种原型的目的、适用场景以及它们如何帮助团队验证想法、降低风险并逐步构建出功能丰富的产品。理解这些原型方法，对于在螺旋模型或统一过程等迭代开发流程中进行有效规划和沟通至关重要。

在下一节课中，我将讨论软件开发中的持续交付，以及它与微软的每日构建有何关联。我们下节课见。

035：持续交付

在本节课中，我们将学习持续交付的概念与实践。我们将了解它如何融入迭代式开发流程，以及它如何通过自动化构建、测试和集成来确保软件产品始终处于可发布状态。

在上一节中，我们介绍了原型设计在软件开发中的作用。本节中，我们将通过“铁路建设”类比中的“道钉机”元素，来完善软件开发流程的历史演进。

然而，这种“发布”的概念相当宽松。构建代码并将其集成到可运行的原型中可能需要大量手动工作。一个在内部运行良好的原型，对客户来说可能仍然无法使用。他们可能使用了未经测试的设备，或者某些细节被忽略了。

避免这些疏忽的一种方法是自动化项目的构建和集成环节。这就是持续交付的用武之地。顾名思义，它允许开发人员持续地交付产品。在开发过程中，每当开发人员提交代码更改时，它都会被构建、测试、集成和发布。

从做出更改到发布之间的时间可以非常短。因此，任何问题都会立刻被发现。持续交付使你能够在任何时间点准备好发布产品，但如果你觉得原型尚未就绪，并不强制发布。

原型发布会被放置到针对不同受众的特定渠道或流中。这样做是为了确保你的持续发布在公开发布前经过适当的测试。

以下是几种常见的发布渠道示例：

开发渠道：用于开发人员日常生成的构建版本，但尚未准备好广泛使用。
测试渠道：用于为公司内部团队创建的原型。
稳定渠道：用于面向核心用户的发布。

开发人员可以通过接收来自每个渠道的反馈来深入了解他们的产品。

持续交付实践与统一过程等迭代流程模型非常契合。让我们看看它是如何工作的。回想一下统一过程是如何由并行工作的不同阶段组成的，这些阶段是初始、细化、构建和移交。

与持续交付最相关的阶段是构建阶段。你可以通过一系列短迭代来持续交付产品。产品随着时间的推移迭代构建，并逐步成型。在任何给定的迭代期间，你的开发团队可能正在构建下一个用于发布的原型，这可能包括许多活动，如详细设计、编码和功能测试。

持续交付也可以在统一过程的细化阶段使用。在细化阶段，会进行高层产品架构设计和测试编写。

为了支持持续交付，你可以使用自动化工具。这些工具可用于构建和集成代码、运行测试，并将产品打包成可发布的形式。对于代码的自动化测试，一个最佳实践是在实际编写代码之前先编写测试。

这种方法被称为测试驱动开发。它确保你实际上在解决正确的问题并实现想要的功能。最初运行这些测试时，它们会失败，因为相应的代码还不存在，但这没关系，因为代码编写完成后，测试最终应该会通过。

随着代码的编写，功能开始在产品中成形。持续交付确保这个过程一直在进行。因此，如果在这个过程中没有任何东西被破坏，那么在任何时候都应该有一个可供分发的原型。所以，原型应该准备好供最终用户试用。

当然，对于任何系统，当最终用户看到你的产品时，你以前从未注意到的错误就会开始浮现。接收用户的反馈是一个持续的过程。你需要从中学习，并修复他们指出的错误。

持续交付实践的目标是拥有一个可发布的原型，本质上就是每次迭代结束时的产品。这具有巨大的优势。

如果你在迭代结束时放弃项目，你仍然会有一个可发布的产品。如果资源耗尽，你甚至可以在没有完成所有计划功能的情况下发布产品。除此之外，你的产品质量实际上会得到提高。

每次迭代都将代码集成到一个更大的产品中，可以确保所有功能在小剂量下都能正常工作。这解决了许多如果你试图一次性构建、测试、集成和发布一个大型产品时会出现的问题。

现在，让我们通过一个选择题来巩固理解。

问题：Howey和他的开发团队正在构建支持基础设施，以实现其他开发人员组装的产品原型的持续交付。他已经设置了自动化工具来构建和集成代码、打包产品，并将产品安装到测试环境中。在这个基础设施中，他还需要自动化工具来做什么？
A. 制作原型
B. 进行详细设计
C. 编写代码
D. 运行测试

答案：D
在这些可能性中，制作原型、进行详细设计和编写代码不属于持续交付的范畴（如果它们能被自动化的话）。然而，自动化测试是持续交付的一部分。

让我们看一个持续交付的实际例子：微软每日构建。在其中，构建阶段的每次迭代都安排为一天，因此称为“每日构建”。

每日构建最重要的部分就是“每日”。微软每日构建的整个要点是确保你的程序员在每次构建活动开始时保持同步。通过遵循一个流程，让开发人员在每天结束时将他们的代码集成到更大的系统中，你可以确保没有人偏离正轨太远。

为了控制这一点，微软使用了持续集成系统。如果你以前没听过这个术语，没关系。它的意思是，当开发人员编写了一段代码，并希望与团队中的其他人远程共享该代码时，该代码必须首先经过自动测试过程。这确保了它能与整个项目协同工作。这对你的团队影响巨大。

如果你的所有开发人员都步调一致，他们可以很容易地看到他们的工作如何融入整个项目，同时也能看到他们的工作如何影响团队的其他成员。这不仅保持了开发人员的士气，也提高了产品质量。

每日构建通过让开发人员能够在错误成为真正的问题之前发现它们来实现这一点。如果你的一个开发人员向系统推送了一段代码并且它未能通过测试，那么你立即就知道是哪段代码出了问题。或者，如果你尝试运行产品但它不工作，你就知道问题出在之前构建中集成的某些东西上。因此，在这种方式下，错误检查在每日构建中变得极其容易。

对于一个大型产品，自动化测试将在夜间对当天的构建版本运行。第二天早上，开发人员可以看到这些测试的结果，并决定修复什么。因此，微软每日构建为你的团队提供了快速行动并在错误成为大麻烦之前抓住它们的机会。通过使用自动化，你也让开发团队的工作变得容易得多。

这就是微软每日构建的简要介绍。

现在你已经了解了持续交付和微软每日构建，让我们看看你学到了什么。

问题：Thomas 是微软的一名开发人员。他花了一整天时间编写将成为 Windows 操作系统下一个版本一部分的代码。在一天结束时，他将他的更改上传到服务器。什么原因会导致更改不被测试？
A. 他的代码不工作
B. 他的代码无法构建
C. 产品中的其他代码不工作
D. 产品中的其他代码无法构建

答案：B 和 D
在这些可能性中，无法构建产品会严重阻碍测试。能够构建但不工作的代码仍然可以被测试。所以答案是 B 和 D。

好了，本节课的内容就到这里。让我们回顾一下讨论的内容。

我首先介绍了持续交付，它可以融入像统一过程这样的迭代流程中。持续交付用于发布增量或演进式原型。

然后我讨论了微软每日构建作为持续交付的一个例子。

因此，像统一过程与原型设计和持续交付这样的组合，就是我们的“道钉机”。对于大型长期项目来说，它是一个极好的工具，在这些项目中，产品质量可能因开发团队的错误更改而受到严重影响。它显然是一个比瀑布过程等更健壮得多的流程。

只是别忘了，它并不能适应所有情况。在某些情况下，特别是在小型项目上，建立所需基础设施所花费的时间可能得不偿失。这就是为什么我也谈到了软件世界的“大锤”——瀑布模型、V模型和Sashimi模型。它们都非常重要，尽管它们不如后来的螺旋模型和统一过程那样健壮。

即使是那些流程，对于一个真正庞大的项目来说也可能过于简单。我希望你对这些流程保持开放的心态。我不希望你学完后认为迭代或并行的软件流程模型是软件产品管理的最佳且唯一的工具。

每种工具都有其应用场景，作为软件产品经理，由你在正确的情境中应用它们。更重要的是，我在本模块中提到的所有流程都不一定是完全相互独立的。你可以合理地整合每个流程的各个方面来创建你自己的流程。

做对你和你的项目最有效的事情。不要觉得你必须适应别人创造的模具。例如，如果你喜欢在迭代周期中测试代码的想法，但你认为不需要在每次迭代开始时都重新审视设计，那么请务必做对你最有效的事情。

总结：本节课中，我们一起学习了持续交付的核心概念，它通过自动化构建、测试和集成，确保软件在开发过程中始终处于可发布状态。我们还探讨了它在统一过程中的应用，并以微软每日构建为例，说明了持续集成和自动化测试如何帮助团队快速发现并修复问题，从而提升产品质量和开发效率。最后，我们强调应根据项目实际情况，灵活选择和组合不同的开发流程。

软件产品管理课程2：《软件流程与敏捷实践》：P36：13_01_2-3-1-在流程模型中应用敏捷实践

在本节课中，我们将深入学习如何将敏捷实践与之前介绍的各种软件流程模型结合使用。我们将回顾敏捷的核心价值观，并分析不同流程模型与敏捷原则的契合度。

到目前为止，本课程已经探讨了许多不同的流程模型。在第一模块中，我们也介绍了采用敏捷实践的一些动机。

现在，我们将更深入地探讨一些敏捷实践。这些实践在你作为软件产品经理工作时会经常用到。

如果你参加了先导课程，会记得我们讨论过《敏捷宣言》。这份宣言概述了软件开发的四个核心价值，以及应遵循的12条原则。

如果你没有参加先导课程或需要复习，可以访问相关课程或通过课程资源中的链接阅读《敏捷宣言》。

首先，我们来回顾一下之前课程中涉及的一些术语。

流程是你用来将开发组织成不同阶段的模型。
实践是你可以用来帮助管理和跟踪开发的技术或行动。
方法论 是定义好的一组实践。

基于《敏捷宣言》的实践和方法论被称为敏捷实践和敏捷方法论。

现在，我们来看看敏捷原则如何与你上一个模块中研究过的一些流程模型相关联。

《敏捷宣言》中涵盖的一条原则提到了“尽早且持续地交付有价值的软件”。让我们尝试将此原则应用到上一个模块中研究的线性生命周期流程模型。

这些模型包括瀑布模型、V模型和Sashimi模型。

你会注意到，在这些模型中，产品只有在整个开发过程结束时才真正交付给客户。这既不是早期集成，也不是持续交付。

瀑布模型也严重依赖文档。如果你还记得，《敏捷宣言》的核心价值之一指出，全面的文档不是敏捷开发的首要任务。

此外，在瀑布模型中，作为阶段主要输出的文档需要在进入下一阶段之前获得批准。要求合同或签核的文化也不是敏捷开发的首要任务。因此，瀑布流程模型与敏捷实践不太兼容。

在敏捷开发中，客户与开发团队之间的关系非常重要。Sashimi模型认识到了这种关系的价值，因为开发团队会向客户提供几个原型。这比之前的流程模型更接近敏捷，因为它允许反馈。然而，仅仅几个原型是不够的。没有足够的机会进行密切协作和反馈，以纳入对产品的改进或变更建议，这并不非常“敏捷”。

迭代流程模型与敏捷实践更兼容，因为它们具有迭代周期。

迭代是敏捷的核心概念。重复的循环为反思和改进创造了大量机会。迭代模型也鼓励频繁和持续的发布以收集反馈。这些发布会在下一次迭代中重新设计和改进。短迭代也是敏捷的一个特点。

在上一个模块中，Bradley向你展示了螺旋模型。螺旋模型降低了风险，因为它不断迭代，并且在每次迭代中都会识别和审查风险。风险管理也是敏捷规划中的一个关键考虑因素。

在传统的螺旋流程中，迭代周期往往较长，与客户的协作也不频繁。但是，你绝对可以将敏捷实践与螺旋模型结合使用，因为它确实有迭代。你可以缩短迭代周期，在迭代结束时举行客户会议并重新评估产品。

在我们回顾的所有流程模型中，统一过程与敏捷的价值观和原则最为兼容。统一过程具有短迭代，类似于我们在敏捷方法论中看到的情况。一些敏捷方法论也采纳了统一过程对架构的关注。甚至有一种方法论被创建出来，它结合了统一过程并用敏捷实践加以补充，这种混合方法论被称为敏捷统一过程。

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

你被要求帮助一个陷入困境的开发团队。该团队正在为一家职业棒球俱乐部开发一款移动票务应用，但未能按计划交付可用的产品。他们认为自己大约落后计划两周，但由于没有进行任何跟踪，很难确定。他们需要帮助，而且需要快速帮助。

你从其他产品经理那里听说，敏捷实践在过去曾帮助过他们的项目。你只想实施遵循《敏捷宣言》的实践。

你会实施以下哪种实践？

A. 任务一开始，就显示给整个团队看（在一个表格中）。
B. 客户在初始规划完成后不能添加新功能。
C. 开发计划定期重新评估。
D. 软件产品经理充当客户和开发团队之间的信使。

如果你想实施敏捷实践，定期重新评估开发计划是一个很好的起点。这符合敏捷“响应变化”的价值观。因此，答案C是正确答案。

A不正确，因为在敏捷中，你希望通过可工作的软件或已完成的任务来跟踪进度，而不是已开始的任务。答案B不允许客户协作或响应变化。D不正确，因为你希望你的开发团队和客户之间保持持续、开放的沟通。

基于《敏捷宣言》的价值观和原则，许多不同的软件实践被确立下来。这些实践是作为软件产品经理可以用来使开发过程更有效的指导方针和规则。这些实践被组织成方法论。你可能听说过其中一些方法论，甚至可能使用过一种。

本专项课程将涵盖的方法论包括极限编程（也称为XP）、Scrum、精益和看板。我们将在接下来的两个模块中介绍这些方法论的一些要点。

所有Scrum实践都从《敏捷宣言》中提取价值观和原则，并将其转化为用于软件开发的指导方针和规则。这就是为什么Scrum被归类为一种敏捷方法论，而Scrum内的实践被归类为敏捷实践。

现在，是时候研究你的第一个方法论了。在下一课中，我们将一起了解极限编程。

037：极限编程实践

概述

在本节课中，我们将学习极限编程（Extreme Programming，简称XP）的核心实践。极限编程是一种敏捷软件开发方法，它强调客户满意度、频繁交付、团队协作和快速响应变化。我们将逐一解析其12项基本实践，并理解它们如何共同作用以提升软件开发效率与质量。

极限编程之所以被称为“极限”，是因为它将许多在其他方法论中使用的良好实践推向了极致。它的核心目标是实现客户满意，这意味着开发团队的首要任务是尽可能让客户感到高兴。

极限编程同样重视持续交付软件、响应变化、高效团队合作和自我组织，这些原则都包含在敏捷宣言中。它主要关注改进开发的五个方面：沟通、简单性、反馈、尊重和勇气。其中，沟通、简单性和反馈已在敏捷宣言中涵盖，而尊重和勇气则强调团队中每个成员的平等价值与敢于说真话、适应变化的团队文化。

极限编程的五大价值

以下是极限编程旨在提升的五个方面：

沟通：确保信息在客户、产品经理和开发团队之间顺畅流动。
简单性：设计尽可能简单的解决方案，避免过度工程。
反馈：通过频繁交付和测试，快速获得并响应反馈。
尊重：团队所有成员（包括客户）因其贡献而受到平等尊重。
勇气：团队敢于面对进度和估算的真相，不畏惧变化，并能共同承担风险。

实践解析：结对编程

为了理解这些价值如何体现，让我们看一个具体实践的例子。假设你是一家小型初创公司的软件产品经理，正在开发一款匹配家长与本地保姆/育儿师的应用程序。你的开发团队决定采用极限编程方法，并组织成两人一组，在单个工作站前协同工作。

这种实践被称为结对编程。你认为它主要提升了上述哪个（或哪些）价值？

A. 沟通
B. 简单性
C. 反馈
D. 尊重
E. 勇气

答案：A, B, C, D, E

结对编程实际上涵盖了所有五个方面。它鼓励两名程序员沟通协作以解决问题（沟通）；两个视角通常能产生更简单、更高质量的代码（简单性）；由于直接与他人合作，你能获得即时反馈（反馈）；它利用程序员的互补技能解决问题，促进了相互尊重；最后，因为程序员不是独自工作，他们更愿意承担经过计算的风险（勇气）。

极限编程的12项基本实践

极限编程由一系列规则构成，这些规则像拼图一样，单独看可能意义不大，但组合起来就能形成完整的开发图景。传统上，XP以其12项基本实践而闻名。

实践一：计划游戏（Planning Game）

这是客户与开发团队共同规划产品的环节。规划可以发生在不同规模上，例如在开发初期有一次大型规划会议，而在每次迭代后则进行较小规模的规划。

初始会议决定了可工作产品的发布频率。无论规模大小，规则通常一致：

客户和开发团队共同列出产品的新功能列表，每个功能都以用户故事的形式表达。
开发团队估算在下一个迭代中可以投入的工作量，以及完成每个用户故事所需的工作量。
客户和开发团队共同对用户故事进行优先级排序，并决定每个功能的可工作版本的发布时间。

实践二：小版本发布（Small Releases）

在极限编程中，你希望发布尽可能小且频繁。开发团队将与客户一起规划哪些功能具有良好的商业意义，并可以在项目早期发布。你希望尽早开发重要功能，以便有更多时间进行完善。团队需要在客户希望完成的功能与可以早期开发的功能之间找到平衡点。

实践三：系统隐喻（System Metaphor）

系统隐喻旨在让你的系统更容易向他人解释。你应该能够轻松地向没有技术经验的第三方解释你的产品。

例如：假设客户有一个面部识别应用的想法，该应用可以告诉你一个人的姓名和信息。一个好的隐喻可能是：“这个应用就像一个派对上的社交达人，认识那里的每个人并了解他们的一切。” 一个好的隐喻能让人在了解具体功能前就大致理解应用的用途。

实践四：简单设计（Simple Design）

这意味着你的设计应尽可能简单。由于需求会不断变化，为可能不会持久的东西制作详细设计没有意义。只设计你今天正在处理的需求所需的内容，不要为可能不会到来的未来进行过度设计。

实践五：持续测试（Continuous Testing）

在极限编程中，测试是在编写源代码之前为功能或需求编写的。通常，这些测试被用作需求的可执行形式。这样，当测试通过时，你就知道相应的需求得到了满足。这被称为测试驱动开发（Test-Driven Development）。

在XP中，功能或需求通过两种方式测试：

验收测试（Acceptance Tests）：由客户执行，用于测试产品的每个功能是否按规范工作。这些测试覆盖产品的较大范围，可以是自动化的，也可以是人工遵循的用户界面操作脚本。
单元测试（Unit Tests）：由开发人员编写的自动化测试，用于测试较低层次的功能。

实践六：重构（Refactoring）

重构是指在不改变代码行为的前提下，重新构建代码的设计。它改进了设计，使得新功能可以轻松添加，从而鼓励响应新的变化。例如，重构包括移除重复和不必要的代码。由于开发人员创建了单元测试，他们可以自信地删除代码而不会破坏产品。如果删除后测试仍然通过，就说明那是多余的代码。

实践七：结对编程（Pair Programming）

这是XP广为人知的规则之一，意味着两名开发人员在一台计算机旁并肩工作以编写代码。这将代码审查推向了极致：代码不是定期审查，而是由配对的另一人持续审查。两名程序员一起工作实际上比两名程序员分开独立工作能产出更多、质量更高的代码。

实践八：集体代码所有权（Collective Code Ownership）

这项实践建议鼓励整个开发团队为产品的任何部分贡献新想法。这意味着任何人都可以向产品的任何部分添加代码。当出现问题时，这是团队的结果，而非个人的责任；同样，当成功时，也是团队的成功。

实践九：持续集成（Continuous Integration）

持续集成要求你的开发人员经常合并代码。这可能至少每天发生一次，但要达到“极限”的程度，发生的频率应该更高。所有测试在集成前后都应100%通过。

实践十：40小时工作周（40-Hour Week）

尊重开发人员的工作与生活平衡似乎显而易见，但如果团队充满热情，可能很难让他们离开键盘。在紧要关头，XP允许最多一周的加班。如果连续多周加班，那就是项目管理出现问题的危险信号。

实践十一：现场客户（On-Site Customer）

这项实践邀请客户成为开发团队的一部分。他们始终在场，以澄清和回答可能出现的任何问题。他们参与开发的每个阶段。

实践十二：编码标准（Coding Standards）

这意味着所有开发人员都遵循相同的编码标准。你不应该通过看代码就能分辨出是谁写的。相反，你应该鼓励开发团队遵循通用的编码约定，并以相同的方式格式化代码。这个标准应在开发初期达成一致，这不仅使代码更易于阅读，也鼓励了集体所有权。

总结

在本节课中，我们一起深入学习了极限编程（XP）的核心理念与12项基本实践。我们了解到XP通过将沟通、简单性、反馈、尊重和勇气等价值推向极致，来追求客户满意和高效交付。从“计划游戏”、“小版本发布”到“结对编程”、“持续集成”，每一项实践都像拼图的一块，共同构建了一个适应性强、协作紧密的敏捷开发框架。掌握这些实践，将帮助你作为软件产品经理，更好地引导团队应对变化，交付高质量的软件产品。

038：极限编程实践案例与反思

在本节课中，我们将通过一个具体的案例来深入探讨极限编程的核心实践，并分析其在实际应用中的优势与挑战。我们将学习如何识别团队是否遵循了极限编程的原则，以及当实践出现偏差时应如何调整。

案例背景

Danielle 是产品经理，她与一个五人开发团队合作，共同开发一款允许小企业主向员工支付工资的薪酬应用程序。

在交付一个原型后，客户向开发团队发送了一封措辞严厉的电子邮件，指出他们在应用程序中发现了一个错误，该错误会导致工资计算不正确。客户对此非常不满，因为这个错误会让企业主损失大量资金，并导致员工获得超出其应得的报酬。

团队成员分工如下：

Timmy 和 Maria 是为该功能共同编写单元测试的程序员。
Stephen 和 Maria 是结对编程编写源代码的程序员。
Danielle，产品经理，在发布前对产品进行了验收测试。

那么，谁应该为这个错误负责？请选择所有适用项：A. Danielle, B. Timmy, C. Maria, D. Stephen, E. 团队中的其他两名开发人员。

极限编程的核心实践：集体所有权

极限编程的一项实践是 集体所有权。这意味着团队的所有成员都对发生的错误负责。因此，每个人都是有责任的。

这意味着 A, B, C, D 和 E 都是正确答案。如果客户对产品非常满意，整个团队也将共享成功的荣誉。

极限编程的其他管理实践

之前我们提到，极限编程传统上由12项基本实践描述。然而，根据不同的资料，其表述方式可能有所不同。Don Wells 是极限编程规则第一版的作者，他列出了29条极限编程规则，其中许多与我们刚讨论的12项实践重叠或结合了Scrum的实践。但也有一些有趣的管理实践不属于上述类别，值得注意。

以下是其中几项关键的管理实践：

1. 为团队提供专用的开放式工作空间

回想一下你以前工作过的环境。你认为它们提高了你的生产力和团队合作吗？极限编程建议工作空间应配备多台不属于任何个人的电脑，这些电脑应放在房间中央，而不是靠墙。这鼓励开发团队一起工作。还应该有一个配有白板的会议桌，供团队协作和头脑风暴。

2. 轮换人员

这项实践鼓励沟通和灵活的工作关系。这意味着每个人都应知道如何开发和操作产品的所有部分。试想，如果只有一个成员知道某个功能如何工作，当他离开时，项目将受到多大损害。轮换人员的替代方案是进行大量文档记录，但这不符合敏捷方式。你不会让一支职业足球队没有替补守门员，同样，项目的成功也不应依赖于某一个人。在体育或开发中，最有用的团队成员是那些掌握多种技能的人。

3. 适时调整极限编程本身

即 当极限编程出现问题时，修复它。你可能注意到，这里说的是“当”而不是“如果”，因为它必定会出现问题。极限编程的所有实践不可能在你的产品整个生命周期中都运行顺畅。并非所有实践都适合你的团队。当某项实践不起作用时，就改变它。你应该让团队遵循规则，直到规则被打破。频繁的项目回顾会议是确定哪些做法有效、哪些无效的好方法。

实践场景分析

现在，让我们应用所学知识分析一个场景。

假设你被一家公司聘用，该公司声称已尝试精确实施极限编程方法论。你走进工作场所，看到的是一排排迷宫般的隔间。当你环顾工作区并向隔间内窥视时，你看到程序员们正在结对编程。

你走进一个隔间，询问开发人员在哪里可以找到客户。一名开发人员递给你一张印有客户电话号码的名片，并说你可以留言，客户会回复你。

你走进下一个隔间，询问正在那里工作的两名程序员下一次发布何时到期。他们告诉你，发布定于每隔一个周五进行，本周五就有一个发布。你问这些程序员他们在做什么，他们解释说他们是数据库团队，专门负责维护和构建数据库。

你意识到他们在许多方面都没有正确遵循极限编程。为了在这个办公室精确运行极限编程，你需要改变哪些开发领域？选项：A. 工作空间， B. 结对编程， C. 客户可用性， D. 小型频繁发布， E. 开发人员多能性。

分析如下：

极限编程的工作空间环境是开放的，鼓励协作。迷宫般的隔间不符合这一实践。
客户也应随时可用。难以联系的客户不利于有效沟通。
开发人员应轮换工作，而不是专攻某一功能。让两名开发人员专门负责数据库工作不符合极限编程。

因此，A、C 和 E 是正确答案。这家公司并非完全偏离轨道，他们确实进行了结对编程并交付小型频繁发布，这些都是良好的极限编程实践。

极限编程的潜在弱点

既然你已经熟悉了极限编程的规则，现在我们来谈谈它的一些缺点。

1. “全有或全无”的方法
如果你为开发团队采用极限编程，鼓励你采用所有规则以获得全部收益。虽然前面提到可以改变不起作用的方面，但到什么程度它仍然算是极限编程？如果一半的实践对你的团队都不起作用怎么办？个别实践的价值不如整体方法论大，但有时实施所有实践并不现实或可能。

2. 适用于小型团队
极限编程是为小型开发团队设计的。当你的开发团队超过20人时，你会在集体所有权和集成方面遇到许多问题。

3. 缺乏前期规划
与其他方法论相比，极限编程不鼓励真正的前期软件架构规划，这可能导致未来大量的返工。

4. 结对编程的局限性
结对编程固然有很多好处，但并未像其他实践那样被广泛采用。可以保证它不会适用于所有团队，性格冲突将是一个重要因素。

5. 安排现场客户的困难
让客户按照极限编程要求的时间全程参与是不常见的。期望客户在每次出现问题或疑问时都在场通常是不现实的。在理想世界中这很棒，但真实的软件开发往往远非理想。

总结

本节课中，我们一起学习了极限编程的集体所有权原则，并通过案例分析了责任归属。我们还探讨了极限编程的其他关键管理实践，如开放式工作空间、人员轮换和过程调整。通过一个公司场景，我们识别了实践中常见的偏差。最后，我们客观地审视了极限编程的潜在弱点，包括其对小型团队的适用性、前期规划的不足以及实践中的现实挑战。

极限编程为软件开发概述了许多优秀的实践，但该过程也存在许多不足。作为一名产品经理，你需要找到适合你团队的实践。你需要进行实验。也许极限编程完全适合你，也许不适合。这就是为什么你必须研究多种方法论，以便为你的团队找到正确的方法。你需要收集数据来支持哪些实践对你有效。

基于此，在下一课中，你将转向学习另一种名为 Scrum 的方法论。

039：Scrum基础入门

在本节课中，我们将学习敏捷开发中的核心实践之一：Scrum。我们将了解Scrum的基本结构、核心支柱、团队角色以及关键实践。通过本课，你将掌握Scrum的基本框架，为后续深入学习具体的Scrum技术打下基础。

🏗️ Scrum的核心支柱

上一节我们提到了Scrum是一种敏捷实践，本节中我们来看看支撑Scrum的三个核心支柱：透明度、检视和适应。

透明度意味着项目的每个部分对所有人都是可见的。这种可见性不仅限于Scrum团队内部，也向团队外部人员开放。透明度的一个重要部分是就项目的通用标准达成一致，这包括在整个开发过程中使用统一的术语，以及对“完成”一个功能意味着什么达成共识。

检视是指Scrum鼓励频繁地检查工作产品和进度，以便及时发现与期望不符的偏差。这些检查应该足够频繁，但又不能过于频繁以至于干扰开发任务。

适应是指在检视过程中，如果发现产品开发开始偏离既定目标，团队必须进行调整和适应，以防止进一步的偏离。

Scrum为检视和适应规定了四种具体的技术，它们是：

冲刺规划
每日站会
冲刺评审
冲刺回顾

你将在关于敏捷规划、评审和度量的课程中深入学习这些技术。

👥 Scrum团队的角色

在了解了Scrum的支柱后，我们来看看构成Scrum团队的三个核心角色：产品负责人、开发团队和Scrum Master。

产品负责人

产品负责人的主要任务是对产品和产品待办事项列表做出决策。他们负责对产品待办事项列表中的需求进行优先级排序，并决定实际要构建什么内容。产品负责人是一个人，而不是一个委员会。他们可能代表一个委员会，但只有产品负责人有权对产品进行变更。

以下是产品负责人的关键职责：

为Scrum团队提供清晰定义的产品待办事项列表。
对该列表进行优先级排序，团队必须尊重并按照该顺序进行开发。
确保开发团队理解待办事项列表中每个功能的预期要求。

开发团队

Scrum开发团队具有以下几个关键特征：

自组织：这意味着没有人（甚至包括Scrum Master）可以命令团队如何将他们的功能待办事项转化为可工作的软件增量。

跨职能：团队拥有完成产品所需的所有技能和人员，可能包括来自不同领域的专家。团队不应依赖团队之外的任何人。成员通常会承担多种任务（例如既编码又测试），而不是有专门的编码员和测试员。

无头衔与子团队：开发团队的成员没有头衔，只应被称为“开发者”或其姓名。团队内也没有子团队。开发者可能在团队内有专长，但责任属于整个团队。

规模小：理想的团队规模大于3人且小于9人（不包括Scrum Master和产品负责人，除非他们也参与开发）。一个经验法则是，能用两张披萨喂饱整个团队。

Scrum Master

Scrum Master的职责是确保Scrum团队遵循Scrum的理论、实践和规则。他们对产品负责人和开发团队都有具体的职责。

以下是Scrum Master对产品负责人的职责：

寻找管理待办事项列表的技术。
帮助Scrum团队理解清晰、简洁的待办事项列表的必要性。
确保产品负责人知道如何对列表进行优先级排序以获得最大价值。
促进Scrum事件。

以下是Scrum Master对开发团队的职责：

指导团队实现自组织。
移除开发过程中的障碍。
促进Scrum事件。

⏱️ Scrum事件与冲刺

Scrum Master负责促进的Scrum事件，正是之前提到的四种检视与适应技术。所有这些事件都是时间盒的，意味着需要为这些事件的持续时间设定一个最大时限并严格遵守。其理念是保持分配的时间，调整范围，而不是保持范围最终导致发布延迟。

另一个核心的Scrum事件是冲刺。冲刺是一个特定时间长度的开发阶段，在此阶段结束时，会向客户交付一个可工作的产品增量。冲刺也是时间盒的，但执行更严格。一个冲刺持续一个月或更短时间，通常为一到两周。一旦Scrum团队确定了冲刺的长度，在整个开发过程中就必须始终保持这个长度，不能随意延长或缩短。

每个冲刺都包含之前提到的四个Scrum事件：

冲刺规划：发生在当前冲刺开始时，用于确定在该冲刺中将完成什么工作。
每日站会：每天举行（通常在每天开始时），开发者讨论他们将做什么任务以及需要什么来完成这些任务。
冲刺评审与回顾：发生在冲刺结束时。

在冲刺进行期间，不能做出会影响冲刺目标的变更。冲刺目标是对该冲刺要完成工作的大局观。那些会改变冲刺目标的建议将进入产品待办事项列表，如果产品负责人决定，可以在下一个冲刺中实施。

✅ “完成”的定义

Scrum的一个重要部分是“完成”的定义。在冲刺结束时交付的可工作产品增量必须是“完成”的。由开发团队负责定义决定产品何时“完成”的质量标准。

通常，一个功能在已编码、已测试和已文档化时才被认为是完成的。团队必须就“完成”的含义完全达成一致。根据敏捷宣言，进度应该通过已完成的功-能来跟踪。这样做的目的是避免工作处于半完成状态，这可能导致团队各自为政，看起来很忙却没有完成任何可用的东西。

完成一个功能需要沟通、集成和同步。这有时要求开发进度放慢，以确保每个功能都真正完成。

💡 总结与注意事项

本节课中我们一起学习了Scrum敏捷实践的基础知识。我们了解了Scrum的三大支柱（透明度、检视、适应），认识了Scrum团队的三个核心角色（产品负责人、开发团队、Scrum Master），并探讨了关键的Scrum事件（如冲刺）以及“完成”的定义。

与极限编程类似，Scrum的倡导者推荐“全有或全无”的实施方式。虽然Scrum的某些实践可以单独实施，但如果你单独实施这些实践，那么你并不是在实践真正的Scrum。真正的Scrum要求完整地实践其全部内容。

尽管Scrum是一种流行的方法论，但它仍然存在一些缺陷。你可以在课程讨论中谈谈你认为Scrum有哪些不足之处。在下一个模块中，你将继续研究更多的实践和方法论。

040：敏捷变体与精益软件开发 🚀

在本节课中，我们将要学习敏捷开发方法的一些变体，并重点介绍一种日益流行的实践——精益软件开发。上一模块我们讨论了极限编程和Scrum等主流敏捷实践，本节中我们来看看其他同样遵循敏捷原则但形式不同的方法。

概述

敏捷方法始终在变化和演进。虽然Scrum目前应用广泛，但软件行业不断涌现新的实践变体，以改进原有方法的不足。了解这些变体有助于你根据项目具体情况，做出更明智的流程选择。

敏捷实践的其他变体

除了Scrum和极限编程，还存在多种敏捷实践变体。以下是其中一些例子：

敏捷统一过程：结合了统一过程的并行开发阶段与敏捷的核心理念，注重流程而非工具，强调简洁性、团队赋能和方法定制。
动态系统开发方法
特性驱动开发
ScrumBan
行为驱动开发

关键在于，敏捷框架允许你根据项目中遇到的具体问题（例如需要对架构或测试更严格），灵活调整和适配流程与实践。

精益软件开发的兴起

有一种敏捷开发方法论近年来获得了极大关注，即精益软件开发。它起源于制造业，其核心是通过减少浪费、只在必要时开始新工作、消除流程瓶颈以及只做能为项目增加价值的事情，来降低项目风险。

2003年，Mary和Tom Poppendieck撰写了将精益制造原则应用于软件开发的专著，推动了精益软件开发的发展。

精益的七项原则

精益是一种思维模式，包含七项核心原则，旨在降低项目风险并快速向客户交付高质量产品。

以下是这七项原则：

消除浪费：任何不增加价值的活动都被视为浪费，应坚决从开发过程中移除。
强化学习：通过短迭代、反馈和持续改进来促进团队学习。
尽可能延迟决策：在掌握足够信息后再做决策，以保持灵活性。
尽可能快速交付：通过小批量、持续流的方式加快交付速度，尽早获得反馈。
赋能团队：信任并授权团队做出决策，激发其主动性和创造力。
内建质量：在开发过程中持续保证质量，而非事后检查。
整体优化：关注整个价值流和系统效率，而非局部优化。

深入理解“消除浪费”

第一项原则“消除浪费”最受关注。在软件开发中，浪费可能以多种形式存在。

为了理解软件中的浪费，我们可以类比制造业。假设一个汽车工厂同时全力生产车身（需5天）和车轮（需0.25天）。如果两者都持续满负荷生产，很快就会出现大量过剩的车轮积压在仓库，占用空间和成本，并且当车型更新时可能完全报废。

这种情形同样适用于软件开发。如果强迫所有开发人员时刻保持忙碌，他们可能会产出大量非核心的、甚至不必要的功能代码。这些代码可能拖累产品质量、引发问题，或者最终根本无法集成到产品中。这就是软件开发中一种关键的浪费形式。

其他浪费形式还包括流程延迟、不必要的会议、需求不明确以及产品缺陷等。

总结

本节课中我们一起学习了敏捷开发的各种变体，并深入探讨了精益软件开发的起源及其七项核心原则。理解这些不同的方法有助于你构建更适合自身项目需求的开发流程。记住，没有一种方法是放之四海而皆准的，关键在于根据实际情况灵活选择和调整。

041：精益软件开发原则（第二部分）

在本节课中，我们将继续学习精益软件开发的核心理念，重点探讨“放大学习”、“尽可能晚做决策”和“尽可能快交付”这三个原则。我们将了解这些原则如何帮助团队更有效地构建满足客户需求的软件产品。

放大学习 📚

上一节我们介绍了精益软件开发的第一原则“消除浪费”，本节中我们来看看第二个原则：放大学习。

这个原则的核心很简单：在深入投入一个想法之前，不要过早地锁定它。在采取行动之前，应通过思考多种替代方案来彻底探索各种可能性。

以下是一个现实场景中的例子：

你的开发团队创建了一份非常基础的用户需求列表，以便快速启动项目。然后，他们可以简要规划出一种可能的产品方案，并开始开发其基本功能。这在大多数开发流程中都很常见。

然而，为了放大学习，一个好的做法是在这个阶段停下来，不再对这个版本做更多工作。相反，你应该问自己：这件事是否可以用另一种方式完成？ 如果是，你的开发团队也应简要规划和开发这些替代方案。

通过允许产品的功能集以这种方式进行调整，你的产品就有最大机会以最令人满意的方式满足客户的需求。

但这并非在软件产品中放大学习的唯一方式。

精益软件开发鼓励在产品的每次构建后都运行集成测试和单元测试。这样做的理由不仅是为了确保代码质量良好，测试本身也是学习产品应如何运行的绝佳方式。测试可以为团队带来关键洞察，这些洞察可用于指导产品的其他版本和未来的规划。

在精益软件开发中，这一切发生在非常短的迭代周期内。其理念是快速失败、快速学习。此外，如果你在某个设计或功能上花费太多时间，很容易发现自己过于投入其中，以至于无法真正看到其缺陷，也无法考虑其他更好的方法。

精益软件团队被鼓励放大学习的另一种方式，是以一种特殊的方式让客户全程参与开发过程。

开发团队不仅应在专注于一个版本之前创建产品的不同版本，还应持续将这些版本展示给客户。这使得开发团队能够通过试错来了解客户的真实需求。同时，也让客户能够学习他们希望产品如何解决其具体问题。在开发过程中，这些需求应不断被细化，以保持项目的可行性。

这类似于自然选择：向客户展示多种潜在方案，让他们决定希望将哪些功能构建到产品中，从而为最终产品带来聚焦和优化。

因此，通过让客户参与尝试不同方案，你的开发团队能够学习如何最好地解决他们的具体问题。这比团队不考虑替代方案、埋头苦干更能带来更好的软件和更满意的客户。

放大学习的要点是确保你的团队通过开发替代方案、获取持续反馈和不断优化，来构建正确的产品。

小测验：识别原则

奥黛丽和她的开发团队正在使用精益软件开发实践构建一个软件产品。她要求开发团队在为客户创建不同替代方案时，一次只专注于项目的一个方面。

通过要求团队一次只专注于项目的一个方面，奥黛丽正在实施精益的哪个原则？

以下是选项：
A. 开发小型增量发布
B. 放大学习
C. 专注于频繁交付
D. 消除浪费

答案是 D. 消除浪费。奥黛丽让团队构建不同替代方案的做法，实际上是在放大学习。而“开发小型增量发布”和“专注于频繁交付”是敏捷开发的原则，并非精益独有的原则，尽管精益项目当然也可以利用这些实践。

尽可能晚做决策 ⏳

精益软件开发的第三个原则是尽可能晚做决策。这听起来可能像是为延长开发时间而找的借口，但我向你保证，事实恰恰相反。这个原则实际上与“放大学习”一脉相承。

想象一个软件团队为客户构建了一个基础软件原型。客户看到后说：“是的，这正是我需要的。就按这个做。” 看起来，沿着这个初始原型设定的路线继续下去就能满足客户，对吗？

但在你决定之前，请考虑一下：作为一个精益软件开发团队，他们为了放大学习，探索了不同的方法。他们知道客户认为原型足以满足需求，于是团队询问客户：“这个原型的哪些特性吸引您？” 基于这些信息，团队继续构建产品的替代版本，整合客户喜欢的原型特性。

在完成了几个更多版本后，客户审视所有方案，并意识到最初的原型已经不够用了。它有一些对最终产品很好的特定功能，但另一个替代版本更能满足他们的需求。于是，开发团队回到工作中，利用这些反馈将原始原型的特性整合到新版本中。现在，团队拥有了比最初更精炼的产品版本。客户审视后，比以往任何时候都更满意，这个版本似乎真正切中要害。开发继续推进，团队也学到了构建正确产品所需的经验。

如果开发团队将客户最初决定构建第一个原型的意见视为最终决定，而不是去开发更能满足客户需求的替代方案，会发生什么？团队可能会构建出一个糟糕的产品，而且他们甚至不会知道自己正在构建一个糟糕的产品。

这就是尽可能晚做决策背后的核心理念。它不是为了拖延或争取时间，而是为了在拥有所需数据和信息时才做出决策。例如，你努力确保存在多种替代方案。在信息不足时做出的决策，必然会导致糟糕的结果。尽可能晚做决策能确保你先获得所需的信息。

尽可能快交付 ⚡

精益软件开发的第四个原则是尽可能快交付。

还记得我说过“尽可能晚做决策”与拖延开发完全相反吗？这个原则真正巩固了这一理念。实际上，“尽可能快交付”与“尽可能晚做决策”是紧密相关的。

我的意思是：当“尽可能晚做决策”时，开发团队向客户展示了许多不同的方案。这使得开发团队能够获得必要的客户反馈，从而专注于客户的需求。

然而，如果开发团队花费三个月来开发每个潜在的原型，会发生什么？假设有四个替代方案，每个耗时三个月，那么在做出任何最终产品或决策之前，需要整整一年时间。谁愿意等待一整年才做出最终决定？

这就是为什么精益软件开发以短周期、快速迭代的方式运作。构建一个基础产品，确保它能工作，然后交付出去，再考虑下一步。没有填充物，没有不必要的工作，没有浪费。通过短周期运作，你的产品不仅能以高速率演进，还能让客户在整个过程中频繁地提供反馈。

当客户对某个功能改变主意时会发生什么？如果构建一个包含该功能的原型需要三个月，那么在这整个期间，该功能都是错误的，而且谁知道还有什么其他部分依赖于它。然而，如果开发以快速迭代进行，这个问题就能被及早发现和纠正。这最大限度地减少了浪费，并快速提升了产品的内置质量。

因此，通过快速构建产品，你的软件得以高速成长，同时也通过专注于最终能保留下来的产品部分，确保了效率。

总结

本节课中，我们一起学习了精益软件开发的三个关键原则：

放大学习：通过探索替代方案、持续测试和客户反馈来深化对问题和解决方案的理解。
尽可能晚做决策：在获得足够信息（尤其是通过“放大学习”获得的信息）之前，推迟关键决策，以避免基于不完整信息做出错误选择。
尽可能快交付：通过短周期、快速迭代的方式构建和交付产品，以便及早获得反馈、减少浪费并加速产品演进。

这三个原则相互关联、相辅相成，共同构成了精益软件开发快速响应变化、高效构建价值、持续优化产品的核心方法论。

042：精益软件开发原则（下）

在本节课中，我们将继续学习精益软件开发的剩余核心原则，包括赋能团队、内建质量与整体看待。这些原则旨在提升团队效率与产品质量。

上一节我们介绍了精益软件开发的前四个原则，本节中我们来看看剩下的三个重要原则。

赋能团队 👥

精益软件开发的第五个原则是“赋能团队”的概念。

以下引用自西奥多·罗斯福，它总结了我们即将阐述的一切：

最好的管理者，是有足够的智慧去挑选合适的人来完成他想要做的事，并有足够的自制力在他们做事时不加以干涉。

这就是“赋能团队”这一原则的全部内涵。如果你相信你的开发团队具备正确完成工作所需的技能，那么你为何还要花时间告诉他们具体怎么做呢？作为软件产品经理，你的精力最好用在其他事情上，例如理解客户需求。移除开发者的障碍，然后让开道路。

这听起来是否与传统管理方式相悖？通常，当我们想到管理时，会想到一个专横的人，事无巨细地告诉团队需要做什么以及如何去做。这很大程度上说明了那些管理者对团队缺乏信任。当然，团队成员也能感觉到这一点。日复一日地被微观管理和告知该做什么，是令人心力交瘁的。这就是为什么精益软件开发旨在赋能遵循其实践的团队。

精益软件开发鼓励管理者倾听开发者的意见，而不是告诉他们如何做事。作为软件产品经理，你应该鼓励你的开发者构思满足客户需求的解决方案。你的目标应该是倾听开发者的想法并提供建议。毕竟，他们应该是你的盟友。这种信任开发团队的实践，能让团队以他们希望的方式工作。相信他们能做出正确的技术决策。这不仅确保了开发者使用对他们而言最高效的方法，也极大地提升了他们的士气。当开发团队感觉他们能掌控工作，并被赋予在没有微观管理的情况下完成任务的自由时，事情会顺利得多。这就是赋能团队背后的逻辑。一个快乐的开发团队，也是一个高效且多产的团队。

让我们测试一下你对这些原则的理解。在开发软件产品时，软件开发团队和客户应尽可能晚做决定的主要原因之一是什么？

正确答案是 B。尽可能晚做决定，可以让你的开发者和客户探索其他可能更好的产品设计。这并不会延长产品截止日期或让任何事情变得更快，也绝不意味着你的客户从来不知道他们想要什么。请记住，即使你通过晚做决定向客户呈现了最佳可能选项，也不意味着你可以不按时交付。

内建质量 🛡️

精益软件开发的第六个原则是“内建质量”原则。这是一个广泛而全面的原则。其真正目的是确保你的开发团队使用可用的最佳实践来避免错误。

那么这具体是怎样的呢？我在之前模块中简要提到过测试驱动开发的实践。这意味着在实际需要测试之前就编写测试。与其先构建产品再进行测试（即开发者在现有代码周围编写测试），不如聚焦于代码旨在解决的实际问题。基本上，先构建测试意味着你实际上是在测试你的代码是否解决了问题，而不仅仅是代码是否能运行。

另一种内建质量的方法借鉴了极限编程，摩根在上一个模块中讨论过：结对编程。如果你需要复习，我鼓励你重新观看那节课。然而，我要说的是，结对编程是开发者真正提高产品质量的一种方式。基本上，这就像在你构建时身边有一位智能向导。我要提醒你，结对编程在开发者时间方面成本也很高。因此，虽然它是开发优秀软件的绝佳工具，但不要依赖它来构建整个产品。否则，你可能最终会违反“尽可能快交付”的原则。

还有其他方法可以为你的产品内建质量。例如：

代码注释清晰
文档完善
重构代码以提高效率
自动化测试

这些都是你可以采用的方式。如果你想获得关于这些主题的更多具体信息，请参阅课程资源，我已包含一些参考资料供你参考。

所有这些都服务于让你的产品更好的目的。精益的核心价值观之一是尽可能消除浪费。因此，通过减少开发者修复代码所需的时间，你就减少了项目中存在的浪费。通过内建质量，你可以大幅减少发布后的缺陷和修复数量。所以，通过内建质量，你就能大幅减少产品中存在的浪费。

整体看待 🧩

本课程将涵盖的精益最后一个原则是“整体看待”原则。“整体看待”意味着将你的软件视为不仅仅是许多小部件的组合。毕竟，最终用户看到的不仅仅是串联在一起的一些功能，最终用户应该看到一个具有逻辑且流畅地相互衔接的组件的、连贯的产品。

因此，在精益软件开发中，在发布前将产品视为一个整体来思考非常重要。这意味着你的开发者必须不断意识到他们负责的部分如何融入大局。大局可能是整个产品，但也可能是该产品如何与同一制造商的其他产品相配合。没有这种视角，产品可能会变得脱节、不合逻辑或仅仅是笨拙。整体看待能让你的开发团队构建出一个连贯、设计精良的整体产品。

让我们通过一个案例来巩固理解。罗斯正在为医学研究构建一个软件产品。由于他的日常工作拯救生命，他不断尝试改进软件开发流程。他最近接触到了精益软件开发，并开始实施其中一些原则。他尝试鼓励团队将项目视为更大目标的一部分，并让他们在最终确定前创建软件的多个不同版本，同时专注于快速构建。为了节省时间，他要求开发团队不要编写单元测试、编写代码文档或使用任何特定的编程实践。罗斯在他的项目中主动忽略了精益软件开发的哪个方面？

以下是选项：
A. 消除浪费。
B. 放大学习。
C. 尽可能晚做决定。
D. 内建质量。

答案是 D，内建质量。通过主动避免这些编程最佳实践，罗斯主动选择了不内建质量。间接来看，这可能会产生浪费，但并非直接相关。

本节课中我们一起学习了精益软件开发的三个关键原则：赋能团队以提升自主性与士气，内建质量以减少浪费并提升产品健壮性，以及整体看待以确保产品作为连贯的整体交付。掌握这些原则将帮助你更好地管理软件项目，平衡速度与质量。

043：精益软件开发与敏捷实践

在本节课中，我们将学习精益软件开发方法的核心原则及其与敏捷实践的关系。我们将探讨如何通过减少浪费和提升质量来优化软件开发流程，并理解精益思想如何为敏捷方法提供工具包。

精益软件开发的基本原则

上一节我们介绍了敏捷方法的核心理念，本节中我们来看看精益软件开发的具体原则。精益方法的核心在于减少浪费的同时提升产品质量。这些原则最初由玛丽和汤姆·波彭迪克在2003年的著作中系统阐述。

以下是其七项核心原则：

消除浪费：识别并移除开发流程中不增加价值的活动。
强化学习：通过持续反馈与改进来积累知识。
尽可能延迟决策：在掌握足够信息后再做关键决定，以保持灵活性。
尽快交付：快速向客户提供可工作的软件以获取反馈。
赋能团队：信任并授权开发团队做出技术决策。
内建完整性：确保软件在设计和代码层面保持高质量与可维护性。
整体优化：着眼于整个价值流和系统，而非局部效率。

精益社区的演进与新增原则

随着精益开发者社区的不断发展，一些新的原则被补充进来，进一步丰富了该方法论。

运用科学方法

此原则强调，开发应基于真实数据而非直觉或猜测。作为软件产品经理，你需要发起实验来测试想法并收集数据。

if (hypothesis.isValid()) { runExperiment(); collectData(); makeInformedDecision(); }

分析与依据这些数据采取行动，能使开发者和客户对产品做出明智决策。用数据支撑潜在决策能为你赢得信誉。这一原则与“尽可能延迟决策”的原则能很好地协同工作。

鼓励领导力

这是“赋能团队”原则的延伸，旨在激发团队中每个成员的最大潜能。

鼓励领导力意味着促使每位开发者变得勇敢、创新、善于启发并乐于协作。

精益原则的整体性与应用保证

你可能会在网上看到这些原则的不同名称，但其核心理念是一致的。波彭迪克在书中附有一项“保证”，声明这些原则已在多个学科中被尝试和验证，若恰当应用，也保证适用于软件开发。

恰当应用意味着所有精益原则都被采用，并且使用思维工具将其转化为适合当前环境的敏捷实践。

如果未经思考就直接从其他学科生搬硬套实践，或者忽视了“赋能团队”和“内建完整性”的原则，那么这项保证将失效。

因此，虽然这个过程看似只是一种减少浪费、提升产品的哲学，但仅靠典型的管理实践并不足以达成目标。精益的核心固然是减少浪费和提升产品，但鼓励团队按他们期望的方式构建产品，并确保遵循正确的编程实践，同样是其中至关重要、不可忽视的部分。

精益与敏捷的紧密联系

在我讲述精益时，你是否发现许多原则都非常“敏捷”？确实如此。精益软件开发遵循大量敏捷原则。事实上，波彭迪克的著作书名就是《精益软件开发：敏捷工具包》。

书中指出，精益软件开发通过将广为人知并被接受的精益原则应用于软件开发，进一步扩展了敏捷软件开发的理论基础。它更进一步，提供了思维工具，帮助将精益原则转化为适合特定领域的敏捷实践。

所以，精益是一个工具包。它是一种方法论，一套实践，能帮助你创造更好的软件并拥有更满意的客户。它鼓励快节奏的迭代开发、客户互动以及使用经过验证的软件开发技术以获得成功。无论组织规模大小，精益都是一种强大而有用的方法。

总结与展望

本节课中，我们一起学习了精益软件开发的起源、核心原则及其演进。我们了解到精益不仅是一套哲学，更是一个实用的工具包，它与敏捷实践深度融合，强调数据驱动、团队赋能和整体优化。

作为一名软件产品经理，请将这些精益原则牢记于心。在未来几年，你很可能会看到它们被越来越广泛地应用，提前了解它们对你将非常有益。

这就是关于精益的内容。在下一课中，我将简要介绍一种常与Scrum和看板（Kanban）结合使用的实践。我们下节课见。

044：看板方法 🗂️

概述

在本节课中，我们将学习一种与精益软件开发紧密相关的方法论——看板。我们将了解它的起源、核心概念、如何将其应用于软件开发，以及它如何帮助团队可视化工作流程、识别瓶颈并提升效率。

看板的起源与核心理念

上一节我们介绍了精益软件开发的主要原则。本节中，我们来看看一个源自精益制造、并在软件开发中广泛应用的实践：看板。

看板方法论是与精益制造共同发展起来的。它旨在与精益制造配合使用，但也可以独立应用。回顾上节课，精益制造始于丰田公司，旨在提升产品质量的同时，减少生产时间和成本。看板帮助精益流程量化系统状态，并实现“准时化生产”的理想。

在丰田的生产车间，每个零部件都被精确管理。每个零部件都有一个与之关联的唯一标识符（ID）。这个ID系统是看板方法有效的核心。当一个零部件从车间被取走用于车辆组装时，其状态会通过ID更新，相关支持流程会收到通知。

核心概念：每个工作项都有一个唯一标识，用于跟踪其状态和流动。

准时化生产与拉动系统

你刚刚了解了看板的一些起源及其在精益软件开发中的作用。那么，看板哲学中“只在需要时一次做一件事”的理念，是受制造业哪个术语的启发？
A. 丰田制造
B. 准时化生产
C. 按需制造
D. 精益制造

答案是B，准时化生产。

看板源于丰田及其精益制造流程，而“一次只做一件事，只在需要时做”的具体理念就是准时化生产。

想象车间里有一组箱子，每个箱子装一个零部件，比如轮胎。在看板中，每个轮胎都被分配一个唯一的ID。工人取走一个轮胎安装到新车上，并扫描其ID。箱子空了，就需要被补充。

在其他车间，空箱子可能直接从现有轮胎堆里拿一个补上。但正如上节课所说，这种系统效率低下，可能导致过度生产等浪费。在看板中，当一个零部件被使用时，补充该零部件的流程会收到通知，从而尽快制造一个新部件放入箱子。这就是“准时化生产”——所有事情都在被需要的最后一刻完成。

这种持续使用和补充车间物品的策略，被称为拉动方法。当一个箱子变空，就产生了一个空缺，这个空缺信号会“拉动”后续流程进行补充。将这种方法应用于所有车间活动，通过拉动零部件，你就能洞察系统的实时状态：在任何时刻，你都能看到需要什么、在哪里、何时需要。

从制造到软件开发：看板板

如果你跟踪一个工作项从一个阶段移动到下一个阶段的时间，就能确定每个制造阶段完成所需的时间，进而计算整个制造过程的总时长。有了这些知识，你就能发现延迟所在，做出有效改变，并跟踪这些改变随时间产生的效果。

看板可以很容易地转化到软件开发领域。只需做一些改变：例如，用任务板来可视化你的流程，板上的每一列代表一个软件开发活动。

最左边的列包含待办事项列表中的所有任务。接下来的列可以是开发、验收测试、内部发布阶段和生产发布阶段。这个板被称为看板板，是辅助看板方法的常用可视化工具。

核心工具：看板板，用于可视化工作流，列代表不同阶段，卡片代表工作项。

实践：应用准时化策略

假设你正在为客户开发一个连接手机应用和数据库的软件产品。每个组件都有一套基础功能和一套可在此基础上构建的高级功能。手机应用的发布依赖于数据库，但一个概念验证版手机应用可以仅使用基础功能，无需连接数据库。

根据准时化生产理念，开发该产品的最佳策略是什么？
A. 先开发数据库的所有功能，再开发手机应用的所有功能。
B. 先开发手机应用的所有功能，再开发数据库的基础功能。
C. 先开发数据库基础功能，再开发手机应用基础功能，然后开发数据库和手机应用的高级功能。
D. 先开发手机应用基础功能，再开发数据库基础功能，然后开发手机应用和数据库的高级功能。

答案是D。 准时化生产强调只在需要时才构建组件。因此，如果你能在没有数据库的情况下创建一个可运行的手机应用原型，就应该优先做这件事。如果原型证明成功，再在其基础上构建数据库和其他高级功能。这样做的理由是在设计早期发现缺陷。如果你在测试基础功能之前就构建了整个产品，可能会发现那些基础功能从一开始就不需要，那么之前的所有工作就都浪费了。

在制品与瓶颈管理

在看板中，所有阶段都是协调的。如果一个工作项在某列完成，它就准备好被下一列“拉动”。然而，下一列必须形成一个空位（容量），才能允许该工作项被拉入该阶段，继续循环。这就引入了在制品的概念。

在制品顾名思义，就是每个阶段当前正在开发的工作量。实践看板方法时，你会发现某些阶段产生工作的能力大于其后续阶段。这些流程中较慢的部分被称为瓶颈，知道如何处理它们很重要。

当某个阶段无法跟上其前一阶段产生的工作速度时，就会发生瓶颈。在我们的汽车例子中，如果安装轮胎的时间比制造轮胎的时间长，那么轮胎安装阶段就会出现瓶颈。

如何处理瓶颈？主要有两种方式：

在瓶颈处增加产能：当然，这是非常有效的方式。但增加产能的唯一方法是向该阶段分配更多资源。我们必须假设执行该阶段活动的人员已经在满负荷工作，并据此进行调整。所以，不是要求安装工更快，而是分配更多安装工。
减少瓶颈前的工作量：除了在瓶颈处增加产能，你还可以消除在瓶颈之前完成的不必要工作。减少在安装前制造的轮胎数量。这被称为设置在制品限制。有效地限制必须等待被拉入下一阶段的工作量。

现在到了我最喜欢的看板部分：那些被告知不要制造更多轮胎的工人怎么办？在软件团队中，这就是为什么多功能团队如此重要。如果你在测试阶段遇到瓶颈，让开发人员在需要时能从功能开发转到测试会非常有帮助。因此，设置在制品限制是管理多功能团队瓶颈的最佳方式。平衡两者，你将看到生产力的提升。

衡量改进：周期时间

你如何知道你的改变是否对项目产生了真正的影响？这就需要周期时间。周期时间是看板中的关键指标。它是一个工作项完成一个完整工作周期所需的总时间。例如，周期时间是汽车轮胎从制造到安装所需的时间。

要测量每个阶段的周期时间，你需要知道一个工作项何时开始、何时完成。然后计算这两个时间戳之间的小时数，就得到了周期时间。这不是开发人员积极工作所花费的时间，而是从开始工作到完成工作的全部时间，包括所有人睡觉的时间。这样做的原因是排除个人努力程度的差异，并适应现实情况，比如因缺陷而重新开始工作。它衡量的是流程能处理什么以及你实践的质量，而不是团队的努力程度。

如果你的周期时间在减少，而产品质量保持稳定或提高，那么你就做对了。

看板中的工作启动

在结束之前，我想谈谈最后一件事：你如何知道何时开始一项工作？在Scrum中，这是在冲刺计划会议期间通过计划完成的。在看板中则不同，没有计划会议。因为工作以其自身的节奏进行，所需的工作不断从产品待办事项列表的顶部被取走。

只要需求始终被正确排序，产品自然会按照功能优先级顺序构建。看板中相当于Scrum产品负责人角色的人，确保产品待办事项列表始终处于正确的顺序。因此，当下一个工作项从待办列表中被拉出时，它已经准备就绪。

总结

本节课我们一起学习了看板方法。看板与精益软件开发配合得非常好，正是因为它为精益制造而生。它允许团队跟踪随时间推移的进展，并确保遵循准时化开发策略。这减少了浪费，并确保决策尽可能晚地做出，以便基于最新信息。

这就是看板的概要。如果你想了解更多关于此策略的信息，请查看课程资源中包含的参考资料。

课程总结

在本课程中，我和Morgan介绍了当今行业中使用的一些软件开发流程和实践的基础知识。

在第一模块，Morgan定义了流程、阶段、活动和任务是什么，以及它们之间的关系。她区分了生命周期流程和子流程，并举例说明了它们如何由阶段、活动和任务组成。然后她详细介绍了软件工程活动，展示了典型生命周期流程每个阶段的活动示例。
在第二模块，我向你展示了生命周期流程如何随时间演变。我从线性流程开始，逐步介绍了螺旋、统一和持续交付流程模型。我还提到了几种不同类型的原型设计。
在第三模块，Morgan开始深入探讨敏捷实践。她介绍了一些在敏捷中使用的流行方法论，如极限编程和Scrum，以及它们实施的实践。
在本模块，我讨论了一些敏捷的变体，以及一种新兴的软件实践——精益软件开发。我们讨论了看板如何在精益中被用来跟踪团队进度，并确保每个人都遵循准时化生产策略。

我和Morgan非常享受教授这门课程，希望你也同样享受学习它。本课程是Coursera上软件产品管理专项课程的一部分。正如我们在介绍课程中所说，这门课程以及我们的“客户需求与软件需求”课程，可以按你选择的任何顺序学习。无论你计划继续学习需求课程，还是已经完成它并准备学习敏捷规划课程，我都期待与你继续这段旅程，共同打造更好的软件和更快乐的客户。

下次见。😊

posted @ 2026-03-29 09:33 布客飞龙II 阅读(17) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

人最大的痛苦就是说一些自己都不相信的话。

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

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

001：艾伯塔大学软件产品管理专项课程介绍 🎓

002：软件过程与敏捷实践简介

概述

课程结构与目标

课程模块介绍

总结

003：流程与实践 🧩

流程概述

流程的结构

阶段示例

流程的进一步分解

任务：工作的基础单元

任务依赖关系

总结

004：流程和实践

概述

活动与任务

角色与职责

工作产品

资源

实践练习

总结

005：流程与实践 🛠️

006：软件工程活动

概述

什么是软件工程活动？

活动示例分析

软件开发中的主要活动

项目管理活动

其他工程活动（简要提及）

总结

007：软件工程活动

项目管理活动

分配资源

进行度量

改进流程

案例分析：凯文的项目管理

规范阶段

识别想法或需求

需求相关活动

制定潜在方案

案例分析：咖啡店应用

总结

008：软件工程活动

🏗️ 设计与实现阶段

🔍 验证与确认阶段

📝 总结与展望

009：线性模型 🧱

概述

理解线性模型

瀑布模型

V模型

Sashimi模型（生鱼片模型）

总结

010：螺旋模型 🔄

概述

螺旋模型的基本结构

螺旋模型的运作流程

知识检查

螺旋模型的不变式

螺旋模型的优缺点

总结

011：统一过程 🌀

初始阶段

细化阶段

构建阶段

移交阶段

总结与展望

012：原型化

概述

回顾与引入

示意型原型

探索型原型

抛弃型原型

增量型原型

增量型原型知识测试