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

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

001：毕业设计项目预告 🎓

在本节课中，我们将对《软件产品管理》课程的毕业设计项目进行预告。我们将了解项目的整体目标、核心任务以及它如何帮助我们整合并应用之前所学的全部知识。

毕业设计项目是本课程的最终实践环节。它旨在模拟一个真实的软件产品管理环境，要求我们综合运用从市场分析到产品发布的全套技能。

上一节我们完成了所有核心知识模块的学习，本节中我们来看看如何将这些知识付诸实践。

项目目标与核心任务

本毕业项目的核心目标是创建一个完整的产品方案。你需要扮演产品经理的角色，带领一个虚拟团队，将一个产品创意从概念阶段推进到发布准备阶段。

以下是项目要求你完成的核心任务列表：

  • 定义产品愿景与策略：明确产品要解决的核心问题、目标用户以及长期发展方向。
  • 进行市场与用户研究：分析竞争对手，识别市场机会，并通过用户画像和场景理解目标用户。
  • 制定产品路线图：规划产品功能发布的先后顺序和时间框架。
  • 创建产品需求文档：详细描述产品功能，优先级排序可以使用公式 优先级 = (价值 + 紧急性) / 努力度 进行量化评估。
  • 设计产品指标与发布计划：定义衡量产品成功的关键指标，并规划产品发布的具体步骤。

你将如何完成项目

项目被设计为一系列结构化的步骤。你将跟随指导，逐步交付每个阶段的成果。

以下是项目完成的主要阶段：

  • 第一阶段：产品构思与规划：提交产品创意、愿景声明和初步市场分析。
  • 第二阶段：需求细化与设计：完成详细的需求文档、用户故事和产品原型设计。
  • 第三阶段：规划与交付：制定最终的产品路线图、发布计划和成功指标评估方案。

在整个过程中，你将得到详细的说明、模板和评估标准。这就像在真实工作中一样，你需要清晰、有逻辑地展示你的决策过程和最终方案。

项目价值

完成这个项目，意味着你不仅学习了软件产品管理的理论，更具备了将理论应用于实践的能力。它是对你所学知识的最终检验和整合。

本节课中我们一起学习了毕业设计项目的概览。我们了解了项目的总体目标、需要完成的核心任务以及大致的执行流程。从下一节课开始，我们将正式进入项目第一阶段，开始将你的产品创意转化为具体的计划。准备好迎接挑战，创建你的第一个产品方案吧！

002：简介

在本节课中，我们将要学习毕业项目的整体结构、目标以及你将如何应用之前课程中学到的技能来完成它。

概述

欢迎来到专项课程的最后一门课程——毕业项目。这个项目将为你提供一个绝佳的机会，来应用你在之前课程中所学到的各项技能。这门课程是你完成整个专项课程学习路径的最后一步。

项目结构与目标

毕业项目是整个专项课程的顶点，它模拟了一个真实的软件项目环境。你将与一位客户、一位专家顾问以及一个由三名开发人员组成的小团队合作，为一家大型连锁书店开发一个软件项目。

这家连锁书店希望作为其“读写推广计划”的一部分，开发一款促进识字和阅读的应用程序。你将在初次与客户沟通时了解到更多详细信息。

项目时间安排

本项目为期六周，模拟了六周的工作时间。

  • 前三周 是你的“冲刺零阶段”，项目的大部分规划工作将在此阶段完成。
  • 后三周 将包含三个为期一周的冲刺阶段，你将在此过程中遇到各种真实的挑战。

课程形式与要求

在每一周的学习中，都会包含多种互动环节、视频、阅读材料和/或作业。

以下是关于作业的重要说明：

  • 所有作业均采用同伴互评的方式。
  • 在规划你的学习时间时，请务必为评阅同伴的作业留出时间。

我们建议你按照课程建议的时间线推进每周的学习。这样可以使全班同学在不泄露关键信息的前提下，在课程讨论区就学习内容进行交流。我们也尽力确保了每周的工作量大致相当，以便你有效地安排时间。

结语

我们非常高兴你能参与到这个毕业项目中，更期待看到你将如何运用在整个专项课程中获得的知识与专长。与往常一样，我们的课程团队将在论坛中解答你可能遇到的任何问题。

本节课中，我们一起学习了毕业项目的简介、结构、时间安排以及学习要求。祝你好运，并享受这个毕业项目的过程。

软件产品管理毕业项目：P3：第0.4节 剽窃

在本节中，我们将明确课程中关于学术诚信的核心规定，即禁止剽窃行为。我们将了解剽窃的定义、具体表现形式以及如何避免它，以确保你提交的所有作业都是原创的。

什么是剽窃？

根据课程荣誉准则，剽窃的定义是：在未注明出处的情况下，复制他人作品中的文字、观点或任何其他材料。在任何学术环境中，剽窃都是不可接受的，它严重违反了课程荣誉准则。

剽窃行为可能导致作业不及格、被取消课程资格，甚至被逐出Coursera学习社区。

剽窃的具体表现有哪些？

以下是几种常见的剽窃行为，请注意避免。

1. 复制粘贴他人文字
如果你直接复制粘贴他人撰写的文字，这即构成剽窃，除非你进行了恰当的引用。即使你调整了语序或替换了某些词语，也必须为其原创工作署名。

示例：在作业、测验或讨论区中，复制粘贴其他学员或课程团队成员的答案或发言，并将其作为自己的成果提交，这是被禁止的。

2. 提交他人创建的文件
在本专项课程的某些课程中，你可能会被要求提交图片或图表作为作业。提交由其他学员创建或提交过的图片，并声称是自己的作品，这被视为剽窃且不被允许。

3. 窃取创意
部分作业可能需要发挥创意。即使你自行撰写了提交的文档，但窃取了他人的创意想法，同样构成剽窃。在学术或商业环境中，多人可能产生相似的想法是常见情况。

如何保护自己免于剽窃指控？

为了避免被指控剽窃（不仅在本课程中，在你的职业生涯中也同样重要），养成记录工作过程的习惯是一种很好的做法。

你可以通过记录修订历史或某种方式记录你的思考过程来保护自己。例如，维护一份日志来记录每个想法或概念的起源时间。

请确保在整个专项课程中提交的都是你自己的原创作品。

发现剽窃行为怎么办？

如果你在课程中发现剽窃行为，请举报该作业并提请课程团队注意。

本节总结

本节课我们一起学习了学术诚信的重要性。我们明确了剽窃的准确定义，列举了复制文字、提交他人文件、窃取创意等具体剽窃形式，并了解了通过记录工作过程来保护自己的方法。请始终牢记，提交原创作品是学习与职业发展的基石。

004：视频模拟开发团队简介 🎬

在本节中，我们将通过一段模拟视频来认识一个虚拟的软件开发团队成员。了解团队成员的背景、性格和工作风格，对于未来的产品管理和团队协作至关重要。

团队成员介绍

以下是视频中四位开发团队成员的自我介绍。

凯瑟琳 (Kathleen)

我的名字是凯瑟琳，但请叫我凯特，凯瑟琳太正式了。我在这个行业工作了很久。在我的职业生涯中，我很幸运能从许多不同的视角体验软件行业。我从开发人员起步，但也担任过Scrum主管、产品负责人和Scrum教练。但我确实怀念创造的过程。我喜欢与其他团队合作并激励他们做得更好，但我非常怀念编程所带来的创造性表达。所以几年前，我回归了开发的老本行。我是一名热心的瑜伽爱好者，大多数晚上我都会在几个街区外一个很棒的小工作室练习瑜伽。如果你们有人想加入我，我认为这对创造生活平衡非常有益。实际上，我认为这将是一次很好的团队建设活动，我们可以一起去上课。我认为这会使我们在精神和心灵上成为一个非常强大的团队。好了，这就是我。我真的很期待了解大家，并创造出一些非凡的东西。亚历克莎，接下来你介绍一下？

亚历克莎 (Alexa)

好的。我是亚历克莎。我在这个行业已经工作了好几年，参与过一些很酷的项目。最近，我主要专注于视频游戏开发。是的，我离开了上一家公司，他们控制欲太强了。他们总是想让我记下所有的工作时间之类的。我的意思是，他们为什么不能相信我在工作呢？我编写的代码比那里任何其他开发人员都多。

关于业余爱好：哦，没什么特别的。我弹贝斯，在一个全女子朋克乐队弹贝斯。是的，我们在本地音乐圈实际上越来越受欢迎。我还喜欢画画，喜欢设计服装。不过，我实际上没做过多少衣服，但我有很多设计图，所以也许我会进一步追求这个爱好。

温迪的回应：哇，听起来太棒了。也许团队可以去看你的一场演出。请务必告诉我们你下次演出的时间。乔希，接下来你介绍一下？

乔希 (Josh)

嗨。我是乔希。我干这行有段时间了。我九岁就开始编程，当时造了一个机器人去监视我的兄弟们。我懂大多数编程语言，至少是那些有用的。业余时间，我通常都在电脑前。不编程的时候，我就在写博客。我真的很喜欢游戏，最近因为《英雄联盟》玩得太好觉得没挑战，又重新玩起了《魔兽世界》。

总结

本节课我们一起通过模拟视频认识了一个开发团队的核心成员：经验丰富、注重平衡与创造的凯特；才华横溢、追求自由、多才多艺的亚历克莎；以及技术扎实、热爱游戏的乔希。了解团队成员的个人背景与工作风格，是进行有效产品管理和团队协作的第一步。在接下来的课程中，我们将看到这个团队如何协同工作。

005：模拟开发团队会议

在本节课中，我们将通过一个模拟的开发团队会议，学习如何将产品需求转化为具体的技术方案和设计考量。我们将看到开发团队如何讨论功能细节、权衡技术选择，并澄清需求的模糊之处。

上一节我们讨论了产品需求，本节中我们来看看开发团队如何围绕这些需求展开技术讨论。

会议开始时，团队首先评估了项目的整体情况。大部分功能，例如浏览和搜索，被认为是标准功能，实现起来相对直接。

因此，团队决定将讨论重点放在那些定义较为模糊、需要进一步澄清的功能上。

以下是团队讨论的第一个核心功能：用户互动方式。

  • 问题提出：团队成员对用户如何在应用内交流感到困惑。这与单纯的阅读应用有何区别？是否可以简化为一个消息功能？
  • 初步分析：有成员指出，如果只是发消息，就失去了“为他人朗读”的意义。
  • 方案探讨：团队提出了视频聊天的想法，但立即考虑到视频会消耗大量移动数据。
  • 最终方案：团队决定设计一个音频通话作为主要互动方式，并将其作为视频通话的备用方案。同时，为了实现连接，应用需要包含一个好友列表功能。

这个讨论自然引出了对用户账户系统的思考。

  • 必要性确认：创建好友列表意味着需要用户账户。团队进一步确认，为了存储用户历史记录、已读书籍以及跟踪阅读能力，账户系统是必不可少的。
  • 关联功能：账户系统将附带登录、重置密码等一系列标准功能。

接下来，团队讨论了另一个复杂功能：阅读能力跟踪。

  • 需求回顾：产品负责人丹尼尔提到了跟踪阅读能力。
  • 技术担忧：有开发人员对实现语音识别技术表示担忧，因为这是其不熟悉的领域。
  • 风险应对：团队决定暂时将此功能标记为“可做”，但会在设计阶段开始前，将其作为一项潜在的技术挑战向产品负责人提出。

随后，会议转向了“传递共读”功能。

  • 功能理解：团队最初认为这就像普通的电子书阅读器，缺乏互动性。
  • 价值挖掘：为了增加价值，需要集成某种交互技术。
  • 技术方案：有人建议通过蓝牙无线连接两台设备，并在每台设备上同步显示相同内容。团队认为这个方案可行。
  • 功能定位：团队同时确认，应用仍需保留单人阅读功能，作为电子阅读器使用。

明确了核心功能后，团队开始讨论产品的硬件和平台载体。

  • 载体选择：考虑到产品需要“像一本书”，且智能手机阅读体验较差，团队一致认为应专门为平板电脑设计。
  • 平台决策：关于开发Android、iOS还是两者兼顾，团队认为客户可能希望两者都有，但这将带来大量工作。他们决定向客户确认优先级，并希望暂时只开发一个平台。

关于应用的具体设计，团队也进行了构思。

  • 显示模式：应用应同时支持竖屏和横屏模式。横屏时并排显示两页，竖屏时单页显示但字体更大。
  • 交互细节：团队还提出了添加页面翻动动画以增强阅读体验的想法。

最后，团队讨论了内容数据的存储与管理策略。

  • 数据源：内容将来自客户提供的数据库。
  • 存储策略：将所有内容存储在设备上是不现实的，会占用过多空间。因此，团队决定：
    1. 应用只从数据库拉取书籍标题和元数据进行浏览。
    2. 当用户开始阅读一本书时，才将内容下载并临时存储在设备上。
    3. 收藏夹和待读列表应保存在设备本地，以便用户离线时也能选择阅读这些书籍。
    4. 用户应能从设备上删除已下载的内容，管理存储空间。
  • 词典功能：针对儿童用户，团队否决了内置词典的想法。取而代之的方案是：当用户长按或选中某个单词时，弹出该单词的定义。这模拟了向共读伙伴询问词义的过程。

本节课中，我们一起学习了开发团队如何通过会议将产品需求具体化。团队系统地讨论了用户互动、账户系统、阅读跟踪、硬件平台、UI设计及数据管理等关键问题，将模糊的需求转化为清晰、可执行的技术方案和设计要点，为后续的设计与开发工作奠定了基础。

006：Google文档使用教程 🗂️

在本节课中，我们将学习如何在毕业项目中正确使用Google文档。我们将涵盖创建文档、分享设置以及如何与同伴协作进行评论和审阅。

概述

我们将使用Google文档来完成毕业项目中的各项任务。要访问Google文档，你需要一个Google账户。如果你还没有账户，请立即注册一个。我们建议你完整学习本教程，即使你之前使用过Google文档，因为其中包含提交作业所必需的重要步骤。

创建文档

上一节我们介绍了准备工作，本节中我们来看看如何创建你的第一个文档。

创建Google账户后，请访问Google文档主页：Docs.google.com。

接着，你需要通过点击“空白文档”选项来创建一个新文档。这是你应该看到的页面。

你应该做的第一件事是为文档命名。你在Google文档中创建的第一个文档将是你的需求文档，因此请为其取一个合适的名称。

要重命名文档，你也可以点击显示“未命名文档”的地方。

现在，你可以开始根据从客户和专家互动中获取的信息来创建你的需求文档。

分享与协作设置

下一步非常重要。你的工作会在Google文档中自动保存，但我们需要能够与同伴分享我们的工作。我们不希望同伴更改你的工作，但希望他们能够提出建议。

例如，你的同伴将对此文档进行需求技术评审，他们需要发表评论。

要分享你的工作，请点击屏幕右上角的“共享”按钮。此时会出现一个对话框。

点击“高级”。这是你将看到的高级共享设置对话框。你需要点击“更改”。你需要选择“知道链接的任何人”。

这一点很重要。你需要将访问权限从“知道链接的任何人可以查看”更改为“知道链接的任何人可以评论”。

你的链接共享对话框应该看起来像这样。请仔细检查此对话框是否显示“知道链接的任何人可以访问”以及“可以评论”。如果是，请点击“保存”，这将返回到共享设置对话框。

你将使用此链接来提交作业。现在，当你的同伴评审通过Coursera上的作业页面访问你的作业时，他们将能够添加建议和评论。

如何进行评论与建议

让我们现在来看看具体如何操作。

当我使用另一个Google账户访问该链接时，文档看起来是这样的。你会注意到绿色的“建议”模式。现在，当我在文档中输入时，它会显示为一条建议。

你也可以通过高亮想要评论的文本，然后点击此处找到的“评论”按钮来发表评论。

在毕业项目完成之前，请不要解决、接受或删除同伴在你的作业中提出的建议。

你将在第二周的需求技术评审作业中，对你的同伴的需求文档发表评论。

总结

本节课中我们一起学习了在毕业项目中设置和使用Google文档的核心步骤。我们了解了如何创建并命名需求文档，如何通过调整分享设置允许同伴进行评论，以及评论和建议功能的具体操作方法。正确使用这些协作功能对于顺利完成同伴评审至关重要。

007：模拟风险讨论 🎬

在本节中，我们将通过一个模拟的团队讨论场景，学习如何识别一个软件项目中可能存在的各类风险。我们将看到团队成员如何从不同角度提出潜在问题，并理解风险识别在项目规划中的重要性。

上一节我们介绍了风险的基本概念，本节中我们来看看在一个具体的项目讨论中，团队成员是如何识别风险的。

以下是模拟讨论中团队成员提出的主要风险点：

  • 功能实现风险：部分建议的功能（如语音识别和远程用户连接）在实现上可能存在较高风险。团队需要在开发前充分评估这些功能的价值，确保其必要性。
  • 技术平台风险：计划同时为 Android 和 iOS 两个平台开发应用，这可能导致工作量倍增和不同操作系统间的兼容性问题。
  • 利益相关者变更风险：关键利益相关者（如产品负责人Lisa）可能频繁改变想法，这会给项目范围和需求稳定性带来挑战。
  • 团队资源风险：团队规模较小，任何一名成员生病或离开都可能对项目进度造成重大影响。
  • 外部依赖风险：项目所依赖的数据库系统近期有过更新，其稳定性和易用性未知。如果它像旧版本一样存在故障，项目将面临极高风险。

在本次模拟讨论中，我们一起学习了如何从功能、技术、人员、依赖等多个维度识别软件项目风险。有效的风险识别是制定应对计划、确保项目顺利推进的第一步。接下来，团队将基于这些识别出的风险制定具体的风险计划。

008：视频模拟任务分解会议

在本节课中，我们将通过一个视频模拟会议，学习如何将用户故事分解为具体的开发任务。我们将跟随一个团队的讨论，了解他们如何规划一个关于平板电脑应用和数据库连接功能的开发工作。

会议开始

会议开始，团队决定从关于平板电脑的用户故事入手，因为这个故事相对简单。

分解第一个用户故事

以下是针对“平板电脑应用”用户故事分解出的任务。

  • 设计应用线框图：需要为应用程序设计视觉布局和交互流程的草图。
  • 搭建iOS开发环境：需要配置好用于开发iOS应用的软件和工具。

团队确认数据库已经存在，无需新建。因此，核心任务是建立与现有数据库的连接。

  • 建立数据库连接：需要配置应用程序，使其能够与已有的数据库进行通信和数据交换。
  • 编写数据获取源代码：需要编写从数据库中提取所需材料的具体程序代码。

讨论开发与审查流程

上一节我们列出了具体的开发任务，本节中我们来看看团队如何规划代码开发和审查的流程。

团队讨论了代码审查的方式。有人提议采用结对编程，但存在效率争议。最终达成妥协方案：在特定时间进行结对编程，或当成员遇到困难时主动寻求结对帮助。

因此，如果代码不是通过结对编程完成的，则需要单独的任务进行代码审查。

  • 代码审查：对于非结对编程编写的代码，需要由其他成员进行审查，以确保代码质量。

团队决定遵循良好的编码标准，并采用测试驱动开发方法。

  • 编写与执行单元测试：在编写功能代码之前或同时，需要编写并运行测试最小代码单元的测试。
  • 编写验收标准与测试：需要根据用户故事定义具体的验收条件，并编写相应的测试来验证功能是否满足这些条件。
  • 执行验收测试：运行验收测试，确认功能符合预期。

讨论文档需求

在确定了开发和测试任务后，团队接下来讨论了项目所需的文档。

关于是否需要内部文档存在分歧。一方引用敏捷宣言认为文档不重要，另一方则指出数据库是复杂组件，未来维护或其他项目复用都需要文档说明。最终团队达成共识，需要为数据库编写内部文档。

  • 编写数据库内部文档：需要创建文档，说明数据库的结构、连接方式和工作原理。

对于用户手册，团队认为数据库连接对用户是自动的，因此无需为此功能单独编写用户手册。

分解第二个用户故事

基于第一个用户故事建立起的流程，团队开始分解另一个关于“播放列表”功能的用户故事。

这个功能看似直接，但同样需要遵循已建立的流程。以下是分解出的任务列表。

  • 功能设计：需要设计播放列表功能的用户界面和交互逻辑。
  • 编写源代码：需要根据设计实现播放列表功能的程序代码。
  • 代码审查：需要对编写的代码进行审查。
  • 编写与执行单元测试：需要为播放列表功能编写并运行单元测试。
  • 编写验收标准与测试：需要定义播放列表功能的验收条件并编写测试。
  • 执行验收测试：需要运行验收测试来验证功能。
  • 编写内部文档：需要为播放列表功能编写说明其技术实现的内部文档。
  • 编写用户手册：需要为用户编写介绍如何使用播放列表功能的手册。

总结

本节课中，我们一起学习了一个模拟的任务分解会议。团队通过讨论，成功地将用户故事转化为具体的、可执行的任务，涵盖了设计、开发、测试和文档等多个方面。会议还确立了代码审查和测试驱动开发的流程，并强调了为复杂组件（如数据库）编写内部文档的重要性。这个过程为后续有条不紊地开发软件产品奠定了基础。

009：第4.1节 视频模拟站立会议

概述

在本节中，我们将通过一个模拟的站立会议视频，学习敏捷开发中每日站会的实际流程与沟通要点。我们将观察一个开发团队在项目第一周中期如何同步进度、提出障碍并协作。

我们正处于开发第一周的中期，并且已经取得了一些很好的进展。

谁想开始我们今天的站会？我可以先开始。昨天我开始着手“阅读器连接”功能的工作。这个功能基本上已经完成了。我的意思是，我今天大概就能完成它，然后我会开始添加音频功能。是的，我目前没有任何阻碍。

好的。我昨天在处理页面格式化。这被证明有点困难。一些功能，它们不太对劲，事情没有按照我想要的方式排列。我已经设置了在纵向和横向模式下都能工作，但是图片把布局打乱了。所以我今天会继续处理这个问题。至于障碍，是的，这比我预想的要花更长时间。

我昨天设置了iOS开发工具，所以那些已经准备好了。今天我将为进行中的功能编写验收测试和标准，这样当你们完成那些功能的编码时，就可以运行这些测试了。我们本应该从这开始，但没关系，我相信我们能完成。是的，我没有任何阻碍。

如果有人需要帮助处理那个页面布局，请告诉我。我可以和某人交换一下，帮忙进行结对编程。你知道的，也许我们只需要一双新的眼睛。我感觉我快要搞定了，但如果今天下午我还在挣扎，也许我们可以调整一下。我不介意帮忙处理验收相关的工作。

好的，无论如何请告诉我。我想我们可以结束会议了，大家都开始工作吧。

总结

本节课我们一起观察了一个模拟的敏捷站立会议。我们看到了团队成员如何依次汇报昨日工作、今日计划以及遇到的障碍。会议中包含了进度同步、问题提出、协作提议（如结对编程）以及测试工作的重要性提醒。这种简短的每日同步是保持团队信息透明和快速响应变化的关键实践。

软件产品管理：6：软件产品管理毕业项目

概述

在本节课中，我们将学习如何通过模拟办公聊天对话来收集用户反馈。我们将了解这种方法的定义、实施步骤、优点与缺点，并探讨如何有效利用收集到的反馈。

什么是模拟办公聊天对话？

上一节我们介绍了多种用户反馈收集方法，本节中我们来看看一种非正式的、模拟真实工作场景的方法——模拟办公聊天对话。

模拟办公聊天对话是一种非结构化的用户研究方法。它通过模仿同事间在即时通讯工具（如Slack、Teams）中的日常对话，来观察和收集用户对某个产品或功能的想法、感受和潜在问题。

如何实施模拟聊天？

了解定义后，我们来看看具体如何操作。实施模拟聊天对话通常包含以下几个步骤。

以下是实施模拟聊天对话的关键步骤：

  1. 设定场景与角色：设计一个简短的工作场景，例如“需要向团队介绍一个新功能”或“解决一个使用中的问题”。明确参与对话的“用户”角色。
  2. 准备对话脚本：编写一个看似自然、非正式的对话开头。脚本应简短，仅提供初始话题，为自由发挥留出空间。例如：“嘿，你试过我们新上线的报告生成功能了吗？”
  3. 选择参与人员：邀请目标用户或同事参与。向他们说明这是非正式的反馈收集活动，鼓励他们像平时聊天一样回应。
  4. 引导与记录：作为发起者，根据用户的回复自然推进对话，深入探讨他们的观点。同时，需完整记录整个对话过程。
  5. 分析对话内容：对话结束后，仔细分析记录，提取关于用户体验、痛点、需求及潜在改进点的关键信息。

这种方法的优点与缺点

任何方法都有其适用场景。接下来，我们分析一下模拟聊天对话这种方法的优势与局限性。

以下是模拟办公聊天对话的主要优点：

  • 环境自然：用户在熟悉的聊天环境中更放松，容易给出自发、真实的反馈。
  • 成本低廉：无需复杂设备或专门场地，只需基本的通讯工具。
  • 发现深层需求：非正式对话可能引出用户在正式访谈中不会提及的细节和潜在需求。

以下是模拟办公聊天对话的主要缺点：

  • 样本偏差：参与者可能无法代表全部用户群体。
  • 信息分散：非结构化对话可能导致信息杂乱，分析起来耗时。
  • 缺乏量化数据：该方法主要产生定性见解，难以获得可统计的量化数据。

如何利用收集到的反馈？

收集反馈是第一步，更重要的是如何运用它们。最后，我们探讨如何将聊天中获得的洞察转化为产品行动。

收集到的反馈应被系统整理，并用于：

  • 生成用户故事：将用户的痛点或愿望转化为格式化的用户故事，例如：作为一个<用户角色>，我想要<达成某个目标>，以便于<获得某种价值>。
  • 优化产品路线图：确认或调整功能开发的优先级。
  • 改进功能设计：为具体的界面或流程设计提供直接输入。

总结

本节课中，我们一起学习了模拟办公聊天对话这一用户反馈收集方法。我们了解了它的定义、实施步骤、优缺点，以及如何将分析结果转化为实际的产品改进措施。掌握这一方法，可以帮助你在轻松的氛围中获得有价值的用户洞察。

011：视频模拟站立会议

在本节课中，我们将通过一个模拟的站立会议视频，学习在软件产品开发冲刺（Sprint）末期，团队如何同步进度、识别障碍并协调工作，以确保演示（Demo）的顺利进行。

会议开场与目标同步

会议主持人开场，明确了当前的时间节点和目标。

“今天是演示前的最后一个上午，我们只有这段时间来完成所有收尾工作。”

团队成员进度汇报

以下是团队成员依次汇报昨日完成的工作、今日计划以及遇到的障碍。

成员A汇报：
“我昨天完成了所有页面布局功能。现在页面看起来像书籍页面，背景是米白色，支持横屏和竖屏显示，所有图片可见，并且字体大小可调。这样用户就可以独立阅读了。我完成了所有单元测试，并且在昨天结束时它们都通过了。我唯一还没做的是编写文档，我计划今天完成。目前我没有遇到任何阻碍。”

主持人确认：
“很好。那些功能的验收测试都已完成。我今天早上早些时候验证了验收测试，所以对你来说应该都能顺利运行。”

追问与细节：
“你什么时候做的测试？你到办公室多久了？”
“我今天早上5点参加了一个很棒的日出瑜伽课，7点就到办公室了。”
“听起来挺可怕的。”
“那让人精神焕发。你应该试试，可能有助于你集中注意力，找到内心的平静。”
“好了，我们跑题了。言归正传，我昨天完成了所有验收测试。我和Alexa结对编程了一会儿，并且如我所说，验证了验收测试。所以一切看起来都很顺利。”

成员B汇报：
“昨天我完成了音频连接功能，已经启动并运行了。Ka，你今天早上试过了吗？挺酷的。”
“试过了，没问题。”
“好的。总之，我猜我会开始着手那些单元测试。”

主持人提醒：
“现在音频功能已经完成，再做单元测试意义不大吧？”
“但你仍然需要它们。你昨晚就说要完成的。”
“是，是，好吧。总之，我昨天写了一点文档，但我觉得在演示前没时间完成了。有人能帮我一下吗？”

协作请求：
“我可以帮你。我可能需要澄清一些事情。你介意我坐你旁边工作吗？这样我有问题可以随时问你。”
“没问题，可以。”

会议总结与行动分配

主持人在所有成员汇报后，进行总结并确认最终行动。

“还有人在演示前有其他需要完成的事情吗？”
“太好了。那我们开始工作吧。”

本节课中，我们一起学习了冲刺末期站立会议的典型流程。会议聚焦于进度同步、障碍清除和任务协调。通过简短的沟通，团队确认了“页面布局”、“验收测试”和“音频功能”已完成，而“单元测试”和“文档编写”是待办事项，并现场形成了结对协作来解决文档问题。这种高效的沟通模式是确保产品按时交付、演示成功的关键。

012：视频模拟客户演示与积压工作细化

在本节课中，我们将通过一个视频模拟场景，学习如何向客户演示产品功能，并根据客户反馈进行产品待办事项列表的细化。我们将重点关注如何将客户的新想法转化为具体的用户故事，并对其进行评估和优先级排序。

概述

本节课程模拟了一个产品团队向客户演示当前开发成果的场景。演示结束后，团队与客户一起讨论新的功能想法，并将这些想法转化为具体的用户故事，随后进行故事点估算和优先级排序，为下一个开发冲刺做准备。

客户演示环节

上一节我们介绍了如何准备演示，本节中我们来看看一个完整的客户演示过程。团队向客户展示了已开发的平板应用核心功能。

团队首先展示了应用的阅读界面。应用模拟了真实书籍的排版布局，并支持以下功能：

  • 关联的图片会显示在页面上。
  • 用户可以调整字体大小以便阅读。
  • 应用支持横屏和竖屏两种模式。

接下来，团队演示了核心的音频连接功能。他们选择点对点音频连接，因为这种方案数据使用量更少，且能更好地保护儿童隐私。

演示中，用户按下连接按钮后，两台设备成功建立了音频连接，并实现了实时通话。

客户对团队的工作成果给予了积极反馈，特别肯定了音频连接功能和经过优化的浅色背景设计。

收集客户反馈与新功能建议

在演示结束后，客户提出了一些新的功能想法，希望团队能考虑加入产品路线图。

客户提出了以下三个功能建议：

  1. 文本高亮：读者可以高亮页面上的文本。
  2. 保存高亮：当读者退出书籍时，其高亮内容应被保存。
  3. 书签功能：读者可以保存阅读进度。

团队与客户确认，目前资料库中尚未包含有声书资源，因此暂不考虑添加“跟随朗读”的音频功能。

积压工作细化：将想法转化为用户故事

在收集了客户的新想法后，团队立即开始了产品待办事项列表的细化工作。首先，需要将这些模糊的想法转化为格式清晰、可执行的用户故事。

团队针对每个建议，协作撰写了对应的用户故事：

  • 想法1：转化为故事——“作为读者，我希望能够高亮书中的文本，以便记住书中的重要内容。”
  • 想法2：转化为故事——“作为读者，我希望创建的高亮内容在退出书籍后能被保存，以便在我返回书籍时可以回顾。”
  • 想法3：转化为故事——“作为读者，我希望我在书中的位置能被保存，以便我可以在之后回到该位置。”

评估用户故事：风险与故事点

定义了用户故事后，下一步是对它们进行评估，包括风险等级和故事点估算。

团队首先评估了风险：

  • 书签功能被认为是低风险。
  • 保存高亮功能因涉及数据持久化，复杂度较高，被评估为中等风险。

随后，团队使用“同时亮牌”的方法进行故事点估算，以避免相互影响：

  • 高亮文本：一致评为 1 个故事点。
  • 保存高亮：一致评为 2 个故事点。
  • 书签功能：经过讨论，最终定为 3 个故事点。

确定下一个冲刺的优先级

最后，团队需要结合现有任务和新故事，为下一个开发冲刺确定优先级。他们列出了冲刺候选任务，并进行了激烈讨论。

以下是优先级排序的讨论要点：

  • 最高优先级：连接数据库。这是应用的基础，必须优先完成。
  • 中等优先级：浏览、选择和搜索功能。
  • 重要考量：客户认为“本地保存资料”比“用户账户”功能更重要，因为它能确保用户在无网络时仍可阅读。
  • 较低优先级：基于理解难度或类型的排序功能。

经过讨论，团队初步形成了下一个冲刺的优先级顺序，并意识到需要根据总故事点容量重新调整发布计划，可能需移除部分功能。

总结

本节课中，我们一起学习了从客户演示到积压工作细化的完整流程。我们看到了如何向客户展示成果、收集反馈，并将模糊的需求转化为具体的用户故事。接着，我们通过评估风险、估算故事点以及团队讨论，确定了功能的开发优先级。这个过程是敏捷开发中持续规划和调整的关键，确保产品始终朝着最有价值的方向演进。

软件产品管理：6：软件产品管理毕业项目

概述
在本节中，我们将通过一个团队模拟冲刺回顾会议的对话，学习如何进行有效的敏捷回顾。我们将分析会议中讨论的正面成果、待改进之处以及为下一次冲刺制定的行动计划。

模拟冲刺回顾会议

团队决定进行一次快速的回顾会议，以从本次冲刺过程中学习经验，并为未来的工作带来益处。

以下是会议中讨论的要点。

做得好的方面
团队首先总结了本次冲刺中表现良好的地方。

  • 完成了所有预期的用户故事。
  • 坚持每天进行站会。
  • 所有用户故事都满足了“完成的定义”。
  • 最终交付了一个可工作的、令人印象深刻的产品。

可以改进的方面
随后，团队以改进为目的，坦诚地讨论了可以做得更好的地方。

  • 在开始编写功能源代码之前，没有先编写单元测试。
  • 在开始开发之前，应该先编写验收测试和验收标准。
  • 任务板的使用可以改进，其在冲刺过程中未能准确反映实际进度。
  • 团队沟通仍有提升空间。

针对故事点估算的讨论
团队评估了故事点估算的准确性。虽然所有任务都按时完成，但认为可能需要更多冲刺周期才能更准确地评估个体估算的精度。总体而言，估算被认为是合理的。

下一冲刺的改进措施
基于以上讨论，团队为下一次冲刺制定了具体的改进措施。

  • 尽早编写验收测试和单元测试。
  • 更频繁、及时地更新任务板。
  • 尝试更多的结对编程，以促进知识共享和提升代码质量。
  • 持续关注并改进团队沟通。

总结
本节课我们一起学习了一个完整的冲刺回顾会议模拟。有效的回顾包括：总结做得好的方面以保持优势，坦诚讨论待改进之处而不相互指责，并基于讨论结果制定具体的、可执行的改进措施，以帮助团队在下一个冲刺中持续进步。

软件产品管理毕业项目：5.1：视频模拟站立会议 星期一

在本节课中，我们将通过一段视频模拟，学习如何在实际的敏捷开发环境中进行一次典型的站立会议。我们将观察团队成员如何同步进度、讨论任务依赖关系并协作解决问题。

上一节我们介绍了敏捷开发中的迭代规划。本节中，我们来看看在一个新迭代开始时，团队如何通过站立会议来启动工作。

以下是视频中模拟的站立会议对话内容：

Wilson首先发言：“我今天要开始处理数据库连接。因为我们这个迭代要完成的大部分用户故事，都以某种方式依赖于这个连接。乐观估计，我今天应该能完成，最晚明天。今天是第一天，我目前没有遇到阻碍。”

既然Wilson将负责数据库连接，Alexa接着说道：“那么我们可以完成一些设计元素，并创建验收测试和标准。”

Josh随后说明自己的计划：“接下来我来说。我将开始设计浏览和书签功能的界面。同时，我也会为‘浏览书籍封面’和‘书签’功能创建验收标准和测试。我目前唯一的阻碍是，最好能有数据库连接。但我可以先使用硬编码的数据开始编程，就像上个迭代那样，所以几天内应该没问题。不过要完成我的任务，最终还是需要数据库连接。我的意思是，我可以用假数据，但我觉得等数据库弄好会更方便。”

针对Josh的依赖，Alexa主动提出协作：“Josh，我也可以帮你做验收测试，这样你就可以集中精力处理那个连接。” Josh回应道：“我觉得可以。”

会议以团队共识结束：“让我们开始团队协作吧。”

本节课中，我们一起学习了模拟站立会议的流程。我们看到团队成员清晰地陈述了当日计划、任务间的依赖关系以及可能的阻碍，并通过主动协作来解决问题，这体现了敏捷沟通的核心价值。

015：第5.3节 视频模拟站立会议

概述

在本节中，我们将通过一个视频模拟的站立会议场景，来观察一个软件开发团队如何同步工作进度、讨论遇到的问题以及规划当天的任务。你将了解到敏捷开发中每日站会的实际流程与核心价值。

好的，各位，我们来看看目前的进展。

我意识到我们的进度有点落后，因为我们刚刚才建立好数据库连接。

不过幸运的是，这部分工作已经全部完成了，所以我们可以顺利继续。希望从现在开始一切都能顺利进行。

是的，抱歉各位，昨天建立连接花费的时间比预期长得多。但我已经完成了数据库连接，并且也编写了相关的单元测试，执行后全部通过了。希望这个连接对大家都能正常工作。

今天我将着手开发搜索功能。目前，我没有任何阻碍。

好的，昨天我一直在处理浏览和选择功能的源代码，主要是书籍封面和书签部分。所以我今天会继续这项工作。如果我今天能完成布局程序，那么我将开始将其与数据库连接起来。目前我没有任何阻碍，但是乔希，等我需要连接数据库时，我可能晚点需要你的帮助。

没问题，到时候告诉我就行。

好的。那么，我今天将开始编写本地保存功能的源代码。昨天在等待乔希完成连接时，我处理了几个功能的文档。但现在连接完成了，我可以真正开始开发这个功能了。既然连接已经完成，我也没有任何阻碍了。我们开始工作吧，我们有很多进度要追赶。

总结

本节课中，我们一起观察了一个模拟的团队站立会议。会议中，团队成员依次同步了进度：解决了数据库连接的技术阻碍、明确了当天的开发任务（如搜索功能、浏览选择功能、本地保存功能），并提出了可能的协作需求。这个简短的会议有效地同步了信息、清除了障碍，并帮助团队重新聚焦于项目目标，体现了敏捷开发中每日站会的核心作用。

016：视频模拟站立会议

概述

在本节中，我们将通过一个视频模拟的站立会议场景，来了解敏捷开发团队在日常站会中如何同步进度、识别障碍并规划当日工作。你将看到团队成员如何简洁地汇报工作。

上一节我们介绍了敏捷开发中的迭代规划，本节中我们来看看团队如何在每日站会中保持同步。

以下是视频模拟中团队成员的工作汇报摘要：

  • 成员A（负责搜索功能）：

    • 昨日完成了搜索功能的源代码编写，核心是一个搜索数据库的函数。
    • 今日计划将搜索功能连接到前端应用程序。
    • 依赖成员C完成的文档和验收测试。

  • 成员B（负责本地保存功能）：

    • 本地保存功能已基本完成。
    • 昨日单元测试发现一些错误，但预计修复不难。
    • 今日计划修复这些测试错误，完成后此功能即告完成。
    • 目前没有遇到阻碍。

  • 成员C（负责浏览与书签功能）：

    • 浏览功能已完成，书签可以显示。
    • 当前问题是书封面的显示尺寸不协调，视觉效果不佳。
    • 所有单元测试均已通过。
    • 今日计划花时间优化书封面的显示效果，并完成相关文档编写。
    • 目前没有遇到阻碍。

团队同步信息后，会议结束，成员开始当日工作。

总结

本节课中，我们一起学习了敏捷站立会议的模拟过程。通过三位成员的汇报，我们看到了站会的核心要素：昨日进展、今日计划、遇到的障碍。这种简短的同步机制有助于团队保持信息透明，快速发现问题并协调工作，确保项目朝着演示（Demo）的目标顺利推进。

017：视频模拟客户演示

在本节课中，我们将通过一个模拟客户演示的视频，学习如何向利益相关者展示产品功能、收集反馈，并规划未来的开发冲刺。

概述

视频展示了一个开发团队向产品经理和客户代表演示其阅读应用新功能的场景。演示涵盖了核心功能的完成情况，并基于反馈确定了下一阶段的工作重点。

演示开场与功能展示

团队首先感谢与会者，并介绍产品核心功能已基本完成。

以下是本次演示展示的主要功能：

  • 浏览功能：用户可以从数据库中浏览所有材料，滚动查看书籍封面。选择书籍后，应用会直接打开书籍。
  • 自动书签：如果用户之前阅读过某本书，应用会自动保存阅读进度，并在下次打开时回到上次的位置。
  • 搜索功能：用户可以通过输入genre（类型）、title（书名）、author（作者）或任何相关关键词进行搜索，浏览页面会动态筛选出匹配的结果。
  • 数据库连接：应用已连接到数据库，用户可以通过无线网络获取所有提供的材料。
  • 本地保存功能：用户在浏览时，可以点击每本书旁边的保存按钮。保存后，即使设备处于airplane mode（飞行模式）下断开无线连接，用户仍能查看和阅读已保存的书籍。

客户反馈与未来规划

演示结束后，客户代表和产品经理提供了反馈，并宣布了一个新的机会。

上一节我们介绍了已实现的功能，本节中我们来看看客户提出的建议和接下来的计划。

客户代表丹尼尔提出了两点建议：

  1. 在浏览页面和阅读页面之间增加一个书籍详情页，展示简介或评论，帮助读者决定是否阅读。
  2. 需要持续关注儿童用户的体验，确保所有功能对儿童友好。

随后，产品经理宣布团队获得了一个教育类贸易展览的参展机会，但时间紧迫，就在下周之后。因此，下一轮冲刺需要开发一个更完善的原型用于演示。

考虑到贸易展的性质，下一阶段的工作重点应放在产品的教育功能上。团队对此感到兴奋，并同意立即开始规划下一冲刺的功能。

总结

本节课中我们一起学习了如何有效地进行产品演示。关键点包括：清晰展示已完成的核心功能、现场测试（如离线阅读）以增强说服力、积极听取客户反馈（如增加详情页和提升儿童友好性），并能根据新的业务机会（如贸易展）快速调整后续开发优先级，将重点转向educational aspects（教育功能）。这个过程体现了产品管理中沟通、适应和持续规划的重要性。

018：视频模拟积压工作细化

概述

在本节中，我们将通过一个视频模拟的对话场景，学习如何进行冲刺（Sprint）计划中的积压工作（Backlog）细化。我们将看到产品负责人和开发团队如何讨论下一个冲刺的功能优先级，权衡取舍，并最终确定冲刺待办事项列表。

冲刺计划讨论

上一节我们讨论了产品愿景和路线图，本节中我们来看看团队如何为下一个冲刺细化具体的用户故事和任务。

以下是团队成员对下一个冲刺（Sprint 3）初始计划的讨论。

  • 开发登录和密码维护功能。
  • 添加浏览已读材料的功能。
  • 添加收藏夹列表和“待读”列表。
  • 添加弹出式词典工具。
  • 添加好友列表及与好友连接的功能。
  • 加入在上一个冲刺中被移出的排序功能。

功能优先级调整

虽然许多功能能为产品增加趣味性，但团队认为它们可能不具备最大的教育影响力。点对点阅读功能很重要，但当前需要更多教育相关的功能。

团队一致认为，弹出式词典工具是下一个冲刺的必备功能。此外，产品负责人希望实现最初建议的阅读理解测试工具。

细化阅读理解功能

现在，哪些功能与阅读理解测试相关？之前，与理解测试相关的功能优先级较低，但团队现在可以将其优先级提升，以匹配新的产品重点。

与理解水平相关的功能包括：

  • 测试流利度和阅读理解水平的能力。
  • 根据用户的理解水平推荐材料。
  • 应用程序跟踪阅读理解能力的提升。
  • 通过语音识别跟踪提升。

关于语音识别功能，开发团队认为在一周内实现过于困难，因为识别特定语速和发音需要大量研究和编程工作。但其他所有功能都是可行的。

确定实施方案

既然无法实现语音识别，团队需要确定如何跟踪阅读理解水平。解决方案是采用一个结合书面和多项选择题的标准化阅读理解测试。

团队决定实施多项选择和书面测试。这意味着需要从当前的冲刺计划中移除一些功能，以容纳这些新的高优先级项目。

权衡与决策

如果添加测试理解水平、根据阅读水平提供建议、跟踪提升以及根据阅读水平匹配用户这些功能，总计需要11个故事点的工作量。因此，必须从当前的Sprint 3计划中移除相应工作量的任务。

团队考虑移除以下功能以释放8个故事点：

  • 浏览已读材料。
  • 连接好友及好友列表功能。

然而，团队发现当前阅读材料并没有对应的难度等级，因此无法实现“根据理解水平匹配材料”的功能。该功能将被记录，留待未来冲刺中数据库信息完善后再实现。

目前计划仍超出一个故事点，需要再削减一个用户故事。团队决定移除“重置密码”功能，因为对于即将到来的贸易展示会并非必需。

关于上一个冲刺移出的排序功能，团队认为当前不需要，优先完成其他功能更重要。

最终冲刺计划

经过讨论，团队为下一个冲刺确定了最终的功能列表：

  • 账户功能（不含密码重置）。
  • “待读”列表。
  • 收藏夹列表。
  • 弹出式词典。
  • 阅读理解测试及匹配功能。

团队对最终计划表示满意，认为它既包含了核心的教育功能，也保留了一些实用的趣味性功能。产品负责人将提供阅读理解测试的细节，并承诺在需要时提供支持。

总结

本节课中，我们一起学习了如何通过团队协作来细化冲刺积压工作。我们看到了产品负责人与开发团队如何就功能价值、实现难度进行讨论，通过权衡与取舍，从初始的功能列表中筛选并确定最终冲刺目标。这个过程确保了团队在有限的时间内，能够集中精力交付最高价值的产品增量。

019：视频模拟冲刺回顾 🎬

在本节课中，我们将通过一个模拟的团队冲刺回顾会议，学习如何有效地进行敏捷开发中的回顾环节。我们将分析团队在冲刺中的成功之处、遇到的问题以及未来的改进计划。

上一节我们讨论了冲刺执行，本节中我们来看看如何对冲刺进行回顾与总结。一个高效的冲刺回顾会议能帮助团队持续改进。

团队完成了一次冲刺，并对应用成果感到满意。他们决定召开一次简短的回顾会议，为接下来的重要冲刺做好准备。

成功之处 ✅

以下是团队认为在本轮冲刺中做得好的方面：

  • 完成了用户故事：团队最终坚持并完成了所有计划的用户故事。
  • 提前编写测试：这是一个显著的改进，有助于保证代码质量。
  • 沟通顺畅：每日站会富有成效，项目状态对所有人透明，这是从上轮冲刺改进而来的积极成果。
  • 保持积极与团队合作：尽管遇到一些困难，但团队保持积极态度，共同协作克服了障碍。

不足之处 ❌

在总结优点后，团队开始审视本轮冲刺中可改进的地方。以下是他们识别出的问题：

  • 依赖关系管理不足：例如，数据库连接本应在更早的冲刺中建立，因为它影响众多任务。这次虽然侥幸未出问题，但未来需更仔细地规划依赖。
  • 结对编程实践减少：由于时间紧张，团队减少了结对编程。他们计划在下轮冲刺中重新尝试，例如以结对方式分配任务。
  • 故事点估算不准确：团队承认最初的估算不够精确。幸运的是，他们在冲刺开始前重新评估并调整了计划，今后需要继续保持这个做法。

改进计划 🚀

分析了成功与不足之后，团队需要制定具体的行动方案来提升下一轮冲刺的效率。以下是他们提出的改进措施：

  • 推行结对编程：在下一冲刺中尝试以结对形式分配任务，若效果不佳再调整。
  • 保持良好沟通：维持当前高效的沟通状态，避免倒退。
  • 持续改进估算：继续在冲刺开始前评估和校准故事点估算。

本节课中，我们一起学习了一个完整的冲刺回顾会议流程。团队系统地回顾了成功之处、不足之处，并制定了具体的改进计划。有效的回顾是敏捷团队持续学习和优化工作流程的关键。

020：模拟站立会议视频分析

在本节课中，我们将通过分析一段模拟的团队站立会议视频，来学习如何有效地组织会议、识别问题并进行沟通。我们将重点关注会议流程、成员互动以及如何发现和处理开发过程中的障碍。

会议内容回顾

以下是模拟会议中各位成员的发言记录整理。

成员A的发言：
昨天我完成了Daniel布置的阅读理解测验，并将其开发成了一个功能模块。所有测试均已通过。我还完成了相关文档。目前只需要有人进行验收测试即可。Alexa已经完成了代码审查。
今天我将致力于根据阅读水平为远程用户进行匹配。

成员A对成员C的请求：
我希望在我开始着手跟踪阅读进度改进功能之前，你能完成相关账户的设置工作。没有账户我也可以做，但那样会节省大量时间。你预计什么时候能完成？

成员C的回应：
账户和登录功能已经完成了。太棒了。我也可以在今天晚些时候帮你运行那些验收测试，没问题。

成员C的发言：
我接下来汇报。正如我昨天所说，我完成了账户和登录功能。Daniel的建议应该能让登录流程对儿童更友好。我开始了定义查询功能，找到了一个儿童词典数据库，并从Lisa那里获得了所有必要的授权。目前，长按单词时会出现一个弹窗，但还没有实际功能。今天我将开始着手将定义查询连接到那个弹窗上。
我目前没有遇到阻碍。

成员B的发言：
昨天我在做浏览材料排序的功能。
我想我今天会继续做这个。

成员A对成员B的质疑：
等等，你不是应该在做收藏夹和待读列表功能吗？我以为排序功能已经被砍掉了。

成员B的解释：
我知道，但我对那个功能有很多想法，所以…我的意思是，那两个列表功能只需要一点时间就能做完。没什么大不了的。

成员A的反对：
不，这很重要。

成员C的调解建议：
好吧，我们先把这个问题放一放，等会议结束后再单独讨论。

成员B的同意：
好的，就这么办。

成员B的后续发言：
好吧，那我昨天就是在做那个（排序功能）。现在我也不太确定今天要做什么了。
我目前没有阻碍。

会议分析与关键点

上一节我们回顾了会议的具体对话，本节中我们来看看其中暴露出的关键问题与最佳实践。

会议流程的优点

  1. 轮询式发言：会议基本遵循了轮流发言的模式，让每个成员都有机会汇报。
  2. 明确昨日成果与今日计划：大部分成员清晰地说明了“昨天完成的工作”和“今天的计划”。
  3. 主动提出帮助：成员C主动提出为成员A进行验收测试，体现了团队协作。

识别出的问题与改进建议

以下是会议中暴露出的几个主要问题。

  1. 偏离任务优先级：

    • 问题描述：成员B正在开发一个已被取消（“cut”）的功能（排序功能），而忽略了高优先级的任务（收藏夹和待读列表）。
    • 根本原因：个人兴趣与项目优先级冲突；任务分配或变更沟通可能不清晰。
    • 改进建议：会前应明确每个人的任务优先级。在会议中，当发现偏离时，应立即澄清优先级并纠正方向。代码上，任务状态应在项目管理工具中明确标记，例如：
      - [x] 账户与登录功能 （成员C）
- [ ] 收藏夹功能 （**高优先级** - 成员B）
- [ ] 待读列表功能 （**高优先级** - 成员B）
- [ ] 材料排序功能 （**已取消**）

  2. 问题处理时机不当：

    • 问题描述：关于成员B工作偏离的讨论在会议中引发了争论，最终决定“会后单独讨论”（sidebar）。
    • 改进建议：对于阻碍整体进度的关键问题，应在站立会议上快速做出决策（例如，重申优先级，明确要求成员B转向高优先级任务）。将细节讨论留到会后是正确的，但核心决策（做什么）应在会上明确。

  3. “无阻碍”汇报不实：

    • 问题描述：成员B在汇报“无阻碍”后，紧接着又表示因任务变更而“不确定今天做什么”。这本身就是一种阻碍（需求/任务不明确）。
    • 改进建议：“阻碍”不仅指技术难题，也包括需求模糊、任务不清、等待依赖等。成员应如实汇报。例如，成员B应该说：“我的阻碍是：我不确定是否应该继续做排序功能，需要明确今天该做什么。”

  4. 依赖关系沟通：

    • 正面例子：成员A明确向成员C提出了对账户功能的依赖，并询问了完成时间，这是很好的实践。
    • 通用公式：有效的依赖沟通可以总结为：“我需要[你的成果X]，以便我能够[完成我的任务Y]。你预计何时能提供X？”

总结

本节课中，我们一起分析了一个模拟的站立会议。我们学习了如何识别会议中的有效实践，如清晰汇报和主动协作。更重要的是，我们剖析了常见问题：个人工作偏离项目优先级、会上未能快速解决关键分歧以及对“阻碍”的定义和汇报不充分。

一个高效的站立会议核心在于聚焦、透明和快速解决问题。通过应用本节提到的改进建议，例如会前明确优先级、会上果断决策、全面定义“阻碍”，团队可以显著提升每日站会的效率，确保所有成员都朝着统一的目标同步前进。

021：视频模拟站立会议

概述

在本节中，我们将通过一个视频模拟的站立会议场景，来学习敏捷开发中每日站会的实际流程和沟通要点。你将看到团队成员如何汇报工作进展、提出困难并协调下一步行动。

会议内容回顾

上一节我们介绍了站立会议的基本概念。本节中，我们来看看一个具体的会议模拟。

以下是会议中每位成员的发言记录：

艾米：昨天我将识字测试功能与账户系统进行了连接。因为丹尼尔建议我们将识字测试设置为账户创建流程的一部分。我整个上午都在努力实现这个功能。我还修改了功能，允许用户重新参加测试，以便他们可以重新评估自己的理解水平。今天我将撰写基于水平的远程匹配功能的文档。如果任何人需要，我也可以审查代码或运行验收测试。我目前没有遇到阻碍。

乔希：我这边也没有阻碍。昨天我基本完成了弹出式定义功能。在一天结束时我运行了单元测试，发现似乎有一个小问题。我打算修复它，然后这个功能就可以进行验收测试了。艾米，如果你能帮我做验收测试，我将非常感激。

艾米：没问题，谢谢。我是一边开发一边写文档的，所以测试完成后，这个功能也就完成了。

萨姆：好吧，各位，我进度严重落后了。那些列表功能花费的时间比我预想的要长得多。我在整个排序功能上花费了大量时间。我想我今天只能完成其中一个列表的删除功能。它已经连接到允许本地保存到设备的功能上了。我们应该先完成哪个列表？

艾米：我个人认为，“待阅读”列表可能比“收藏夹”列表更重要。

乔希：我也是这么想的。你同意吗，萨姆？

萨姆：同意。我应该在接下来的几个小时内能完成它。有人能帮我整理文档吗？我已经有很多笔记了，只是需要把它们写得更正式一些。

艾米：我可以做这个。

萨姆：好的，谢谢。各位，我很抱歉，我感觉自己像个傻瓜。

乔希：嘿，别担心。我相信完成一个列表也没问题。如果有什么我能帮忙的，请告诉我。

艾米：好了，团队，让我们完成这些工作吧。

核心实践解析

在模拟会议中，团队成员遵循了站立会议的核心结构。每个成员的发言都大致包含三个部分，这可以用一个简单的公式来描述：

昨日完成 + 今日计划 + 遇到的阻碍

例如，艾米的汇报可以分解为：

  • 昨日完成：连接了识字测试与账户系统。
  • 今日计划：撰写远程匹配功能的文档。
  • 遇到的阻碍：无。

这种结构确保了沟通高效且信息聚焦。

总结

本节课中，我们一起学习了一个模拟的敏捷站立会议。我们看到了团队成员如何清晰地汇报进度（如“我完成了Y功能”）、规划当日工作（如“今天我将做X”）以及透明地提出困难（如“我进度落后了”）。会议最终以协调互助和鼓舞士气结束，体现了团队协作的精神。掌握这种沟通模式，对于有效参与敏捷项目管理至关重要。

022：视频模拟客户演示

在本节课中，我们将观看一个模拟客户演示的视频，了解如何向利益相关者展示一个软件产品的核心功能与价值。

视频展示了一个名为“Reading Pal”的儿童阅读应用。开发团队向产品经理和客户代表演示了应用的主要功能，并收集了反馈。

功能演示

以下是演示中展示的核心功能点。

账户系统与登录

应用首先展示了一个账户创建与登录界面。家长可以为自己创建账户，也可以直接登录。登录后，家长可以看到一个与其账户关联的子女账户列表。

子女账户与阅读水平测试

家长可以通过点击按钮为子女添加新账户。子女登录时，只需点击列表中自己的头像。如果是首次登录，系统会引导他们完成一个阅读理解测试。该测试的流程如下：

  1. 孩子阅读一小段文本。
  2. 回答几个与文本相关的问题。
  3. 系统根据答题情况，判断文本难度是否合适。如果文本过难或过易，孩子会被重定向到更匹配其水平的文本。
  4. 最终，系统会给出一个直接对应其阅读水平的分数。

孩子可以随时通过主屏幕上的按钮重新参加此测试。

基于阅读水平的配对功能

孩子可以选择基于阅读水平进行配对。当他们像往常一样尝试连接时，会弹出一个窗口，询问是否希望根据阅读水平进行匹配。如果没有相同水平的其他用户在线，系统会将其与分数最接近的可用用户进行配对。

弹出式词典

在阅读任何书籍时，如果孩子遇到不认识的单词，只需长按该单词，一个儿童词典的定义就会立即弹出。这个词典的定义简单易懂。要关闭词典，只需点击弹出窗口外的区域即可。

“待读”书单管理

孩子可以将他们想读的书籍保存到“待读”书单中。该列表中的所有书籍都会自动保存在设备本地，以便随时随地阅读。用户可以通过点击每本书旁边的星形按钮来添加书籍，也可以通过点击垃圾桶按钮从列表中删除书籍。

反馈与讨论

上一节我们详细介绍了应用的功能，本节中我们来看看客户和产品经理对这些功能的反馈。

演示结束后，团队与客户代表进行了简短的讨论。客户提出了一个关于“收藏夹”列表的问题，开发团队解释由于时间限制，目前只实现了“待读”列表，并认为一个列表已足够，两个列表可能会让应用变得过于复杂。客户代表对此表示赞同。

客户代表对应用的整体效果给予了高度评价，特别赞赏了阅读理解测试和弹出式词典功能，认为这些功能将产生巨大的教育影响。同时，他们也提出了一个改进建议：应用可能需要一个入门教程，来引导孩子们发现并使用这些功能。团队认可了这个想法，并决定可以留待后续版本实现。

总结

本节课中，我们一起观看了一个完整的客户演示模拟。我们看到了如何清晰地展示产品功能，如何应对客户的即时提问，以及如何收集有价值的反馈。演示最终获得了客户的积极认可，团队的产品被认为已准备好参加贸易展览会。这个过程展示了有效沟通和展示在软件产品管理中的重要性。

软件产品管理：6.7：视频模拟项目回顾 🎬

在本节课中，我们将回顾一个软件产品管理毕业项目的模拟视频内容，学习如何进行项目回顾会议，并总结团队协作的经验与教训。

上一节我们介绍了项目交付的流程，本节中我们来看看如何对已完成的项目进行系统性的回顾与总结。

项目回顾会议是团队在项目结束后，共同反思过程、庆祝成功并识别改进机会的重要活动。与冲刺回顾不同，它着眼于整个项目的生命周期。

这段旅程相当精彩，我希望大家都乐在其中。现在，我想进行一次项目回顾。

我知道我们过去进行过冲刺回顾。

但你们中有多少人参与过项目回顾？我没有。我听说过，但从未参与过。

好的，正如我们刚刚被巧妙告知的那样，如果没有团队每位成员的辛勤工作，这个项目就不可能完成。

我个人只想说，能与你们所有人共事，我感到非常自豪。

好的，任何项目回顾的第一步都是确保每个人都能轻松地公开谈论自己的想法。

因此，我想先进行一次快速的匿名投票。请在一张纸上写下1到5之间的一个数字。

这个数字代表你在此次会议中参与公开对话的安全感。

1 表示你感到非常不适，5 表示你感到非常自在。

好的，这很棒。我本以为不会有什么问题。

确实没有人给出低于4的分数，当然我对此也毫不怀疑。那么我们继续。

大家都带来了自己的“纪念物”吗？

那么，我们如何处理这些纪念物呢？我希望每个人谈谈哪件纪念物对他们意义最大。

乔希，你想开始吗？好的，我带来了一张截图，是我打印出来的一张屏幕截图。

这是我单元测试失败的截图。

这是我第一次测试失败时截的，当时我以为测试不会失败。

我喜欢它，因为它是一个很好的提醒：我的代码并非总是完美的，单元测试也很重要。

即使它们会占用更多时间。哦，我还带来了一罐Alexa给我买的杀虫剂，是个玩笑。

很棒的选择，乔希。好的，我下一个来。我带来了这张有人留在我桌上的便利贴。

上面写着“今天干得不错，继续加油”。我不知道是谁写的，所以别告诉我，因为我有点喜欢不知道的感觉。是的，它帮我度过了一个有点艰难的日子。

被欣赏的感觉很好。所以，谢谢写这张便条的人。太好了，和你共事真的很愉快。

我当然也带了东西。

我带来了我们项目的燃尽图。我认为我们共同完成的工作量是惊人的，我想提醒大家这一点。

我还带来了一本儿童书，是我们为Candata项目使用的那本的实体版，我特意出去买的。

但它是这个项目的纪念品，希望未来能将这样的书籍带给全世界值得拥有的孩子们。

太完美了。谢谢。也许之后，我们可以团队一起和我们的纪念物拍张照。是的，好主意。太棒了。

那么，让我们再多谈谈这个项目。它成功吗？我不知道。

我们完成了所有应该完成的任务。

但我只是希望我们能继续做下去。我觉得我们没有打造出我们所能打造的最好的产品。

我明白你的意思，但你必须记住，我们在专注于重要事项和按时交付方面确实做得很好。

是的，而且我们必须在仅仅几个冲刺内为贸易展交付一些东西。

在这么短的时间里，你不能指望完成太多工作。你说的没错。我们本可以做得更多。

乔希，你怎么看？实际上，我觉得相当不错。

我的意思是，确实没发生什么大事。那么，好吧，下一个练习是构建我们的项目时间线。

考虑到项目周期很短，这应该相当简单。我们每个人在便利贴上写下一个事件，然后贴在这张纸上，接着写下其他重要事件也贴上去。

那么，我来从项目开始、我们所有人开始一起工作时写起。

所以第一个主要事件应该是我们开始构建应用程序的时候，对吧？

我认为我们应该先写下需求分析过程，我觉得我们可以把两者都写下来。这是一个协作的过程。

完美，好的，让我们思考一下这个时间线。我们可爱的产品经理给了我们一些讨论主题。那么我们来谈谈它们。

我们哪些方面做得很好。我们的流程，我认为我们很好地遵循了敏捷实践。

确实如此。

我认为我们作为一个团队合作得非常好。

而且归根结底，我们的沟通也相当不错。好的，还有其他吗？没有了，好的。

我们学到了什么。我学到了编写测试用例并不真的那么难。

我学到了，不先与大家沟通就按自己认为对的方式去做是不好的。

好的，非常好。你们俩呢？我学到了Scrum可以成功地用于小型项目。我还学到了我在团队中工作得比我想象的要好。还有其他吗？没有。好的，我们继续吧。

下次你会有什么不同的做法？伙计们，你们太棒了，知道吗？这真是很多东西。

哇，我们在这个项目中确实做了很多，不是吗？好了，差不多就这些了。

我认为没有其他需要讨论的了。你们能想到什么吗？

不，我想不到。好的，那么。

这次很有趣。我们和所有这些东西拍张照怎么样？然后我可以马上发给你们。

太棒了，谢谢你们和我一起做这件事。

本节课中我们一起学习了如何进行项目回顾会议。关键步骤包括：营造安全的发言环境、分享有意义的项目纪念物、评估项目成功与否、构建项目时间线，并系统讨论“哪些做得好”、“学到了什么”以及“下次如何改进”。这有助于团队巩固经验，持续提升协作与产品开发能力。

软件产品管理：6.10：恭喜您完成毕业设计项目 🎉

在本节中，我们将共同回顾您在专项课程中的旅程，并对您的成就表示祝贺。

您成功了，祝贺您。阿尔伯塔大学的我们为您在此专项课程中付出的辛勤努力感到无比自豪。

我们希望您能将所学知识应用于职业生涯的任何阶段。

我们珍视每一份论坛帖子和电子邮件，与您共度的这段旅程非常精彩，我们感谢您的投入与坚持。

我们非常荣幸能为您制作这些课程，并希望您在学习过程中同样享受其中。

我们祝愿您在未来的所有努力中都能获得最好的运气。

因此，请随时与我们分享此专项课程将您带向了何方。

谢谢您，并再次祝贺。

在本节课中，我们一起完成了软件产品管理专项课程的最终环节。您已成功掌握了从产品战略规划到市场发布的完整知识体系，并完成了毕业设计项目。请带着这些宝贵的技能与信心，在未来的职业道路上继续前行。再次恭喜您顺利毕业！

025：《软件产品管理毕业项目》🎓

在本节课中，我们将预览《软件产品管理》课程的毕业项目。该项目旨在整合并应用你在整个课程中学到的所有核心概念与技能，通过一个实践项目来展示你的综合能力。

项目概述

毕业项目是你将所学知识付诸实践的机会。你将扮演产品经理的角色，负责一个软件产品从构思到发布的完整生命周期。

上一节我们介绍了课程的整体结构，本节中我们来看看毕业项目的具体内容与目标。

项目核心目标

本毕业项目旨在达成以下三个核心目标：

以下是项目希望帮助你实现的关键成果：

  1. 整合课程知识：将分散在课程各模块中的概念，如市场分析、路线图规划、敏捷开发等，系统性地应用于一个连贯的项目中。
  2. 构建作品集：完成一个可以作为你个人作品集核心内容的项目，向潜在雇主展示你的产品管理能力。
  3. 模拟真实工作：体验软件产品经理在真实工作环境中的职责、挑战与决策过程。

你将完成的任务

为了达成上述目标，你需要在项目中完成一系列具体任务。

以下是项目包含的主要阶段与活动：

  • 产品构思与验证：识别一个市场机会，定义产品愿景，并通过用户调研或市场分析验证其可行性。
  • 制定产品路线图：规划产品的长期发展蓝图，确定不同版本（如MVP、V1.0、V2.0）的核心功能与发布节奏。
  • 创建用户故事与待办列表：将产品功能分解为具体的用户故事，并管理产品待办事项列表。例如：
    - 作为[用户角色]，我希望[达成某个目标]，以便[获得某种价值]。
  • 规划发布与迭代：使用敏捷框架（如Scrum）规划发布周期和冲刺（Sprint），定义每次迭代的目标与交付物。
  • 撰写发布公告：模拟产品发布，撰写面向用户或利益相关者的发布公告，阐述新版本的价值与功能。

项目交付成果

你的学习成果将通过一系列具体的交付物来体现。

以下是项目结束时你需要提交的核心文件：

  1. 产品需求文档：包含产品愿景、目标用户、核心功能列表与优先级。
  2. 产品路线图：以时间线或表格形式展示的产品发展计划。
  3. 产品待办列表：包含已排好优先级的用户故事列表。
  4. 发布计划：至少两个冲刺（Sprint）的详细计划，包括冲刺目标和任务分解。
  5. 最终演示：一个简短的演示或报告，总结你的产品、所做的决策以及学到的经验。

成功的关键

要出色地完成这个项目，请牢记以下几点建议。

以下是帮助你顺利推进项目的几个要点：

  • 从简单开始：你的第一个产品想法不必过于复杂。一个清晰、能解决特定用户痛点的简单想法，比一个庞大而模糊的概念更容易成功。
  • 应用课程框架：充分利用课程中提供的模板、检查清单和思考框架来构建你的项目。
  • 寻求反馈：如果可能，与同学、导师或朋友讨论你的想法和方案，他们的反馈极具价值。
  • 享受过程：这是一个将理论转化为实践的安全环境。勇于尝试，并从决策中学习。

本节课中我们一起学习了《软件产品管理》毕业项目的整体预览。我们明确了项目的三大核心目标，了解了需要完成的具体任务和最终交付成果，并掌握了成功完成项目的关键建议。这个项目是你整合知识、构建作品集的关键一步，请做好准备，将你的产品管理技能付诸实践。

026：《软件产品管理毕业项目》｜1_05_0-1-课程介绍

在本节课中，我们将要学习毕业项目的整体介绍，了解其结构、目标与时间安排。

你好，欢迎来到专项课程的最后一门课——毕业项目。

毕业项目将为你提供一个机会，应用你在先前课程中获得的技能。

这门课程将是你完成“诺克什”结构的最后一步，该结构代表了本专项课程的组织方式。毕业项目是“诺克什”的顶点。

毕业项目将引导你完成一个模拟项目。在该项目中，你将与一位客户、一位专家顾问以及一个由三名开发人员组成的小团队合作，为一家大型连锁书店创建一个软件项目。

这家连锁书店希望创建一个促进读写和阅读的应用程序，作为其“Lreach”计划的一部分。你将在初次与客户互动时了解更多细节。

这个毕业项目为期六周，模拟了六个工作周。

毕业项目的前三周是你的“冲刺零阶段”，项目的大部分规划工作将在此阶段进行。最后三周将包含三个为期一周的冲刺，你将在此过程中遇到现实的挑战。

在每一周，都会有各种互动环节、视频、阅读材料和/或作业。

所有作业都需要同伴互评，因此在安排学习计划时请务必考虑这一点。你需要分配时间来完成对同伴作业的评审。

我们建议你按照建议的时间线推进每周的学习。这将使班级能够在课程讨论中交流内容，同时不会泄露任何关键信息。

我们也努力使每周的工作量大致相当，以便你能有效地安排工作。

我们非常高兴你能参与这个毕业项目，更期待看到你如何将专项课程中获得的知识和专业技能付诸实践。

与往常一样，我们的课程工作人员将在论坛中解答你可能遇到的任何问题。

祝你好运，享受毕业项目的过程。

本节课中我们一起学习了毕业项目的总体介绍，明确了它是一个为期六周的模拟实践项目，旨在综合运用之前所学的软件产品管理技能。我们了解了项目的阶段划分、时间安排以及学习形式，为后续的深入学习做好了准备。

027：学术诚信与抄袭防范

在本节课中，我们将学习学术诚信的核心概念，明确什么是抄袭，并了解在课程作业中如何避免此类行为。这对于确保你提交的作业代表自己的原创工作至关重要。

什么是抄袭？

根据课程荣誉准则，抄袭是指你在未注明出处的情况下，复制他人作品中的文字、观点或任何其他材料。

抄袭在任何学术环境中都是不可接受的，它严重违反了课程的荣誉准则。抄袭可能导致作业不及格、被取消课程资格，甚至被 Coursera 社区除名。

抄袭的具体表现有哪些？

以下是几种常见的抄袭行为示例。

复制粘贴他人文字
如果你复制粘贴了他人撰写的文字，这将被视为抄袭，除非你以恰当的方式注明出处。即使你调整了语序或替换了特定词语，你仍然必须为其工作成果署名。例如，在作业、测验或讨论论坛中，复制粘贴其他学员或工作人员的文字，并将其作为自己的成果提交，是严格禁止的。

提交他人创建的文件
在本专项课程的某些课程中，你可能会被要求提交图片或图表作为作业。提交由其他学员创建或提交的图片，并将其作为自己的成果，同样被视为抄袭并被禁止。

窃取观点
某些作业可能需要一些创造性。窃取他人的创意观点被视为抄袭，即使提交的文件是由你自己创建的。在学术或商业环境中，两个或更多人可能产生相同的想法是常见现象。为了保护自己不被指控抄袭（不仅在本课程中，在你的职业生涯中也是如此），记录你的修订过程或以某种方式记录你的思考过程是一个好习惯。你可以考虑维护一个日志，记录每个想法或概念的起源时间。

如何维护学术诚信？

请确保在整个专项课程中提交的都是你自己的原创工作。如果你在课程中发现抄袭行为，请标记相关作业并提请课程工作人员注意。

本节课中，我们一起学习了抄袭的定义、具体表现形式以及维护学术诚信的重要性。请始终牢记提交原创作品的原则，并在整个学习过程中实践这些准则。

028：模拟开发团队介绍（周一）👥

在本节课中，我们将通过一个模拟场景，认识一个虚拟的软件开发团队成员。了解团队成员的背景、性格和工作风格，对于理解后续的团队协作与产品开发过程至关重要。

团队成员介绍

以下是团队成员的自我介绍，让我们逐一认识他们。

凯瑟琳 (Kathleen)

大家好，我是凯瑟琳，但请叫我凯特，凯瑟琳太正式了。我在这个行业工作了很久。在我的职业生涯中，我很幸运地从许多不同的角度体验了软件开发。我最初是一名开发者，但也担任过Scrum Master、产品负责人和Scrum教练。但我确实怀念创造的过程。我喜欢与其他团队合作并激励他们做得更好，但我非常怀念编程所带来的创造性表达。所以几年前，我回到了开发岗位。

我是一名热心的瑜伽爱好者，大多数晚上我都会在几个街区外一个很棒的小工作室练习瑜伽。如果你们有人想加入我，随时欢迎。我发现瑜伽对创造生活平衡非常有帮助。实际上，我认为这会是一次很好的团队建设活动。我们可以一起去上一节课。我认为这会使我们在精神和心灵上成为一个更强大的团队。

以上就是我的介绍。我真的很期待了解大家，并一起创造一些出色的东西。艾丽克莎，接下来请你介绍好吗？

艾丽克莎 (Alexa)

好的。我是艾丽克莎。我在这个行业已经工作了好几年，参与过一些很酷的项目。最近，我主要专注于视频游戏开发。是的，我离开了上一家公司，他们管得太多了。他们总是要求我记录所有的工作时间之类的。我的意思是，他们为什么不能相信我在工作呢？我写的代码比那里任何其他开发者都多。

关于业余爱好：哦，没什么特别的。我弹贝斯。我在一个全女子朋克乐队弹贝斯，是的，我们在本地音乐圈已经小有名气了。我还喜欢画画，喜欢设计服装。不过，我实际上没做过几件衣服，但我有很多设计图，所以也许以后会深入发展一下。

乔希 (Josh)

嘿，我是乔希。我干这行有段时间了。我九岁就开始编程，当时造了一个机器人去监视我的兄弟们。我懂大多数编程语言，至少是那些有用的。业余时间，我通常也在电脑前。不编程的时候，我就在写博客。我真的很喜欢游戏，最近又重新玩起了《魔兽世界》，因为《英雄联盟》我已经玩得太好了。

总结

本节课中，我们一起认识了模拟开发团队的三位核心成员：经验丰富、注重平衡与团队建设的开发者凯特；才华横溢、个性独立、热爱音乐与艺术的开发者艾丽克莎；以及技术扎实、充满热情的游戏爱好者开发者乔希。了解团队成员的不同背景和个性，是理解后续团队动态和项目管理挑战的第一步。在接下来的课程中，我们将看到这个团队如何协作并应对产品开发中的各种情况。

029：开发团队周一会议模拟

在本节中，我们将通过一个模拟的开发团队会议，学习如何将产品需求转化为具体的技术方案和设计考量。会议中，团队将讨论一个儿童阅读应用的功能实现细节。

概述

本次会议模拟了开发团队在项目初期，围绕产品经理提出的需求进行技术可行性讨论的场景。团队将逐一分析各项功能，明确技术实现路径，识别潜在挑战，并达成初步共识。

会议讨论内容

上一节我们介绍了产品需求背景，本节中我们来看看开发团队如何具体拆解这些需求。

核心交互功能

首先，团队讨论了应用的核心交互方式，即用户如何通过应用进行交流。

问题： 用户如何在应用内交流？这与普通阅读应用有何不同？能否只是一个简单的消息功能？

讨论与结论：

  • 简单的文本消息功能违背了“为他人朗读”的初衷。
  • 视频聊天会消耗大量移动数据，不适合作为主要方案。
  • 最终方案： 设计一个纯音频选项作为主要交互方式，并作为视频聊天的备用方案。

用户账户系统

接下来，团队探讨了是否需要以及如何构建用户账户系统。

问题： 是否需要为“好友列表”等功能创建用户账户？

讨论与结论：

  • 存储用户历史记录（如已读书籍）需要账户系统。
  • 跟踪每位用户的阅读理解数据更需要独立的账户。
  • 最终方案： 必须构建完整的账户系统，包括登录、密码重置等相关功能。

阅读理解评估

团队对产品经理提出的“阅读理解评估”功能的技术实现提出了疑问。

问题： 如何实现阅读理解的自动评估？是否必须使用语音识别？

讨论与结论：

  • 语音识别对部分开发人员是技术挑战。
  • 作为替代方案，可以考虑让用户完成测验。
  • 行动项： 将此功能标记为“可做”，但在正式设计前需将其作为潜在风险提出。

“传递共读”功能

团队分析了“传递共读”这一特色功能的具体含义。

问题： “传递共读”是什么？如果只是像普通电子书一样阅读，其价值何在？

讨论与结论：

  • 必须有交互技术集成才能增加价值。
  • 技术方案： 考虑使用蓝牙技术无线连接两台设备，并在每台设备上同步显示相同内容。
  • 应用仍需保留单人阅读功能，作为电子阅读器使用。

目标设备与平台

团队明确了产品开发所针对的设备类型和操作系统。

问题： 产品为哪种设备（智能手机、平板电脑、网页）和平台（Android、iOS）构建？

讨论与结论：

  • 设备： 为平板电脑设计。智能手机屏幕小，不利于阅读体验；网页应用需要Wi-Fi，不符合“便携”要求。平板电脑更能模拟书本的形态。
  • 平台： 客户可能希望同时支持Android和iOS，但这将带来大量工作。需要与产品经理确认优先级，希望先专注于一个平台。

应用界面与体验

团队讨论了影响用户体验的界面设计细节。

问题： 应用应支持横屏和竖屏模式吗？是否需要页面翻页动画？

讨论与结论：

  • 屏幕方向： 支持横屏和竖屏两种模式。
    • 横屏模式：并排显示两页。
    • 竖屏模式：单页显示，字体更大。
  • 动画效果： 加入页面翻页动画以增强真实感和趣味性。团队一致认为这是个好主意。

内容存储与管理

团队重点讨论了如何高效管理大量的书籍内容，以平衡用户体验和设备性能。

问题： 如何提供书籍内容？是否将所有材料都存储在应用内？

讨论与结论：
以下是团队提出的内容管理方案：

  1. 在线浏览： 从数据库拉取书籍标题和元数据供用户浏览，不预下载全部内容，极大节省设备存储空间。
  2. 按需下载： 当用户开始阅读某本书时，才将该书内容存储到设备本地，避免每次阅读都访问数据库。
  3. 列表管理： “收藏夹”和“想读”列表应保存在设备本地，即使用户离线也能查看和选择这些书籍。
  4. 内容删除： 用户必须能够从设备中删除已下载的书籍，以管理存储空间。

即时词典功能

最后，团队确认了一个提升阅读体验的辅助功能。

问题： 是否需要内置词典？如何让儿童快速获取词义？

讨论与结论：

  • 内置词典对儿童可能不友好。
  • 实现方案： 采用单词点选查词功能。当用户（儿童或共读伙伴）点击某个单词时，定义会立即弹出显示。

总结

本节课中，我们一起学习了开发团队如何将产品需求转化为可执行的技术方案。通过这次会议模拟，我们看到团队：

  1. 明确了核心功能（音频交互、账户系统）的技术实现。
  2. 识别了高风险功能（语音识别评估）并制定了应对策略。
  3. 确定了产品形态（平板电脑应用）和关键体验设计（双屏模式、翻页动画）。
  4. 设计了高效的内容存储与管理架构（在线浏览、本地缓存）。
  5. 细化了辅助功能（点选查词）的实现方式。
    团队最终获得了足够的信息，可以推进到下一阶段的设计工作。

软件产品管理毕业项目：P30：Google Docs 使用教程 📄

在本节中，我们将学习如何在毕业项目中正确使用 Google Docs 来创建、共享和协作处理文档，特别是需求文档。掌握这些步骤对于顺利完成作业提交和同行评审至关重要。

概述

在本教程中，我们将逐步介绍如何使用 Google Docs 来完成毕业项目中的各项任务。主要内容包括：创建 Google 账户、新建文档、重命名文档、设置共享权限以便进行同行评审，以及了解如何添加评论和建议。即使你之前使用过 Google Docs，也请完整跟随本教程，以确保掌握作业提交所必需的关键步骤。

1. 访问与创建文档

首先，你需要一个 Google 账户。如果你还没有，请立即注册一个。

完成账户创建后，请访问 Google Docs 主页：Docs.google.com。

接着，点击“空白文档”选项以创建一个新文档。

创建后，你将看到如下所示的页面。

2. 命名你的文档

你需要为文档命名。在毕业项目中，你创建的第一个 Google Docs 文档将是你的需求文档。

因此，请为其取一个恰当的名称。

重命名文档的方法是：点击页面左上角显示“未命名文档”的地方。

现在，你可以开始根据从客户和专家那里收集到的信息，创建你的需求文档了。

3. 设置文档共享权限

下一步非常关键。Google Docs 会自动保存你的工作，但我们需要能够与同伴共享文档。

我们不希望同伴直接修改你的文档，但希望他们能够提出建议。

例如，你的同伴将在“需求技术评审”作业中评审此文档，他们需要能够添加评论。

要共享你的工作，请点击屏幕右上角的“共享”按钮。

随后会出现共享对话框。

点击“高级”以进入高级共享设置。

在高级共享设置中，点击“更改”链接。

选择“知道链接的任何人”这一选项。

这一点很重要：你需要将访问权限从“知道链接的任何人可查看”更改为“知道链接的任何人可评论”。

你的链接共享设置最终应如下图所示。

请仔细检查对话框，确认其显示“知道链接的任何人”可访问，且权限为“可评论”。

确认无误后，点击“保存”。这将返回到共享设置对话框。

你将使用这个生成的链接来提交作业。

现在，当你的同行评审员通过 Coursera 上的作业页面访问你的作业时，他们将能够添加建议和评论。

4. 如何进行评论与建议

让我们了解一下评审者如何操作。

当我使用另一个 Google 账户访问该链接时，文档界面如下所示。

你会注意到绿色的“建议”模式已激活。

此时，我在文档中键入的任何内容都会以建议的形式显示。

你还可以通过以下方式添加评论：首先高亮选中想要评论的文本，然后点击此处显示的“添加评论”按钮。

请注意：在毕业项目全部完成之前，请不要解决、接受或删除同伴在你的作业上提出的建议。

你将在第二周的“需求技术评审”作业中，对你的同伴的需求文档进行评论。

总结

本节课我们一起学习了在毕业项目中使用 Google Docs 的核心流程。我们涵盖了从创建文档、正确命名，到设置关键共享权限（设置为“可评论”）的每一步。此外，我们还了解了同行评审者如何进入建议模式并添加评论。正确遵循这些步骤，将确保你的作业能被顺利评审，并促进有效的协作。

软件产品管理毕业项目：6.1.2-3：风险讨论模拟（周三） 🎬

在本节中，我们将通过一个团队讨论的模拟场景，学习如何识别软件项目中的潜在风险。我们将跟随一个团队的对话，了解他们如何从不同角度发现并评估项目风险。

概述

本节课我们将模拟一个项目团队的风险讨论会。团队成员会从功能、技术、人员、外部依赖等多个方面，指出在开发一个软件产品时可能遇到的风险。通过这个案例，我们可以学习如何系统性地进行风险识别。

风险识别讨论

上一节我们介绍了风险管理的概念，本节中我们来看看一个团队在实际讨论中如何识别具体风险。以下是团队成员提出的各类潜在风险。

功能实现风险

  • 某些提议的功能（如语音识别和远程用户连接）在实现上可能存在风险。
  • 团队需要在开发前充分评估这些功能的价值，确保其必要性。

技术平台风险

  • 同时为 Android 和 iOS 两个平台开发会带来大量工作。
  • 不同操作系统间的兼容性问题可能构成重大风险。

项目干系人风险

  • 关键干系人（如产品负责人Lisa）可能经常改变想法。虽然她的想法通常很好，但需求频繁变更本身是一种风险。

团队资源风险

  • 团队规模小，任何成员生病或无法工作都会对项目进度产生重大影响。

外部依赖风险

  • 项目依赖的数据库系统近期有过更新，其当前状态未知。
  • 如果该系统仍像上次使用时那样存在故障（glitchy），项目将面临极高风险，甚至可能失败。

总结

本节课中，我们一起学习了一个团队如何通过集体讨论来识别项目风险。我们看到了风险可能来源于功能复杂性、技术选择、人员变动和外部依赖等多个方面。有效的风险管理始于全面而坦诚的风险识别。在接下来的课程中，我们将探讨如何为这些已识别的风险制定应对计划。

032：7_07_3-10-视频模拟任务分解会议

概述

在本节课中，我们将通过一个视频模拟会议，学习如何将用户故事分解为具体的开发任务。我们将跟随一个团队，观察他们如何讨论并确定实现某个功能所需的所有工作项，包括设计、编码、测试和文档等环节。

任务分解会议模拟

会议开始，团队准备着手处理用户故事。

从平板应用用户故事开始

团队决定从关于平板电脑的用户故事开始，认为这个任务相对简单。

以下是针对该用户故事识别出的任务：

  • 设计应用程序的线框图。
  • 搭建iOS开发环境。

数据库连接任务

团队确认材料数据库已经存在，无需新建。主要工作是建立与数据库的连接。

以下是针对数据库连接所需的任务：

  • 设置与数据库的连接。
  • 编写从数据库拉取材料的源代码。

确立代码审查流程

团队接下来讨论代码审查流程。有人质疑结对编程会降低效率，但最终达成共识：在特定时间进行结对编程，当有人遇到困难或需要他人检查代码时，可以请求结对。

因此，团队决定：

  • 为需要单独编写的代码创建代码审查任务。
  • 结对编程的代码则无需单独的审查任务。

确立开发与测试标准

团队决定遵循良好的编码标准，并采用测试驱动开发。

以下是为此制定的任务：

  • 编写并执行单元测试。
  • 编写验收标准与测试。
  • 执行验收测试。

讨论文档需求

关于文档的必要性产生了讨论。有人引用敏捷宣言认为不需要文档，但被纠正：敏捷宣言更看重可工作的软件，而非完全不要文档。

团队最终达成一致：

  • 数据库是一个复杂组件，需要内部文档来说明其工作原理。
  • 由于数据库连接对用户是自动的，因此该功能不需要用户手册。

处理另一个用户故事

团队转向另一个用户故事，其任务分解模式变得清晰。

针对此用户故事的任务包括：

  • 编写源代码。
  • 审查代码。
  • 编写并执行单元测试。
  • 编写验收标准与测试。
  • 执行验收测试。
  • 为该功能设计内部文档。
  • 为该功能编写用户手册。
  • 进行功能设计。

总结

本节课中，我们一起观察并学习了一个团队如何将用户故事逐步分解为可执行的具体任务。这个过程涵盖了设计、环境搭建、编码、代码审查（包括结对编程）、测试（单元测试与验收测试）以及文档（内部文档与用户手册）等多个关键环节。通过模拟会议，我们看到了团队协作、标准制定（如测试驱动开发）以及对敏捷原则正确理解的重要性。团队最终确立了一套清晰的任务分解流程，并计划将其应用于后续的所有用户故事中。

033：周三站会

概述

在本节课程中，我们将通过一个模拟的站会场景，观察一个软件开发团队在项目第一周中期如何同步进度、讨论问题并规划当日工作。你将了解到站会的基本流程、团队成员如何报告工作，以及如何协作解决障碍。

我们已进入开发第一周的中段，团队取得了一些良好进展。

现在开始今天的站会，谁想先来分享？

我可以开始。昨天我着手处理了“读者连接”功能。

该功能已基本完成。我今天应该就能最终完成它，之后我将添加音频部分。

目前没有任何事情阻碍我。

好的。

昨天我在处理页面格式化工作。这被证明有点困难。

一些功能的表现不如预期，元素的排列方式未能达到我的要求。

我已将其设置为能在竖屏和横屏模式下工作，但图片的插入打乱了布局。

所以我今天会继续处理这个问题。

至于阻碍，是的，这项工作比我预想的要花更长时间。

昨天我设置了iOS开发工具，现在它们已准备就绪。

今天我打算为进行中的功能编写验收测试和验收标准。

这样，当相关功能编码完成后，你们就可以运行这些测试。

我们本应更早开始这项工作，但没关系，我相信我们能完成。

我目前没有遇到任何阻碍。

如果有人需要帮助处理页面布局，我可以与某人交换任务，进行结对编程。

也许我们只需要一个新的视角。我感觉我离解决它很近了。

但如果今天下午我仍在挣扎，或许我们可以调整一下。

我不介意帮忙处理验收相关的工作。

好的，无论如何请告诉我。

我认为我们可以结束站会了，大家开始工作吧。

总结

本节课我们一起观察了一次典型的敏捷站会。站会中，每位成员依次说明了昨日完成的工作、今日计划以及遇到的阻碍。团队通过简短的沟通同步了进度，主动提出了协作建议（如结对编程），并明确了下一步行动。这种日常同步机制有助于保持团队信息透明，及时发现问题并促进协作。

034：9_03_4-4-周四办公室聊天模拟对话

概述

在本节课中，我们将通过一个模拟的办公室聊天对话场景，来观察和体会产品经理在项目后期，特别是临近发布时，可能面临的沟通挑战与决策情境。这个场景展示了团队成员之间如何就产品功能、发布时间和用户反馈进行交流。

场景背景

上一节我们讨论了产品发布前的准备工作。本节中，我们来看看在一个典型的工作日，产品经理与开发人员之间可能发生的真实对话。这个对话发生在周四，产品计划在周五发布。

以下是模拟的办公室聊天记录，它揭示了项目后期常见的几种动态。

  • 亚历克斯（产品经理）：嘿，团队。我刚收到一些关于新登录流程的早期用户反馈。看起来有一部分用户遇到了问题。
  • 乔丹（开发人员）：具体是什么问题？我们的测试覆盖率很高，login_spec.js 单元测试全都通过了。
  • 亚历克斯：反馈说，在密码重置后，页面重定向到了错误的仪表盘视图。这似乎是一个边缘情况。
  • 萨姆（开发人员）：哦，那个流程。我们为了赶进度，在重定向逻辑里用了一个简单的条件判断：if (passwordReset) { redirectTo(‘/dashboard’); }。可能漏掉了用户角色判断。
  • 乔丹：修复它需要修改用户会话验证和路由逻辑。我估计需要4-6个小时进行代码修改和回归测试。
  • 亚历克斯：我们原定明天发布。这个问题的严重性如何？会影响多少用户？
  • 萨姆：只有通过密码重置流程登录的用户才会遇到，比例可能小于5%。但对他们来说，这是100%的糟糕体验。
  • 亚历克斯：我明白了。让我们评估一下选项。选项一：按原计划发布，发布后立即投入修复，作为紧急补丁。选项二：推迟发布，先修复这个缺陷。

关键决策点分析

从上面的对话中，我们可以提取出产品经理需要权衡的几个核心因素。这些因素共同构成了一个决策框架。

以下是决策时需要考虑的几个关键维度：

  1. 缺陷严重性：该问题是否会导致数据丢失、系统崩溃，还是仅造成使用不便？
  2. 影响范围：受影响的用户比例是多少？是全体用户还是特定子集？
  3. 修复成本：修复所需的时间、人力和技术资源是多少？公式可以简化为：修复成本 = 开发时间 + 测试时间 + 部署开销。
  4. 发布压力：是否有外部承诺（如客户合同、市场活动）或内部目标（如季度目标）要求按时发布？
  5. 用户体验与品牌风险：发布一个有已知缺陷的产品，对用户信任和品牌声誉的潜在损害有多大？

过渡到决策

综合以上因素，产品经理需要做出一个平衡各方利益的决策。这通常没有完美答案，但必须有明确的理由。

在本次模拟场景中，亚历克斯可能会进行如下思考：
“虽然该缺陷影响面较小，但它发生在关键的登录流程中，会给受影响用户留下极差的第一印象。考虑到修复时间在可控范围内，为了确保发布质量和用户体验，我决定选择推迟一天发布，优先修复此问题。”

总结

本节课中，我们一起学习了一个产品发布前的决策模拟场景。通过分析一段真实的团队对话，我们看到了产品经理如何收集信息（用户反馈、技术评估），并基于缺陷严重性、影响范围和修复成本等多个维度做出是否推迟发布的艰难决定。这种在质量、时间和范围之间的权衡，是软件产品管理工作中不可或缺的一部分。

035：模拟站立会议（周五）

概述

在本节课程中，我们将通过一个模拟的周五站立会议场景，了解在软件产品演示（Demo）前一天，团队成员如何同步进度、识别风险并协调最后的工作。会议聚焦于功能完成度、测试状态以及文档撰写等收尾任务。

会议内容记录

上一节我们介绍了迭代开发中的日常同步，本节中我们来看看项目演示前的最后一次站立会议是如何进行的。

以下是会议中各位成员的进度汇报与讨论。

成员A：
我昨天完成了所有页面布局功能。页面现在看起来像书籍页面，背景为米白色，支持横屏与竖屏显示。用户可以查看所有图片，并且字体大小可调，确保用户能够独立阅读。我完成了所有单元测试，并且在昨天结束时它们都通过了。我唯一还没做的是编写文档，我计划今天完成。目前没有遇到任何阻碍。

成员B：
很好。所有这些功能的验收测试都已完成。我今天早上早些时候验证了验收测试，所以对你来说运行应该会很顺利。

成员A：
你什么时候做的？你到办公室多久了？

成员B：
我今天早上5点参加了一个很棒的日出瑜伽课，7点就到办公室了。

成员A：
听起来挺可怕的。

成员B：
那让人精神焕发。你有时应该试试，它可能帮助你集中注意力，找到内心的平静。

成员A：
好了，我们跑题了。

成员B：
对。所以我昨天完成了所有那些验收测试。我和Alexa结对编程了一会儿，并且如我所说，验证了验收测试。所以一切看起来都很棒。

成员C：
我昨天完成了音频连接功能，已经启动并运行了。Ka，你今天早上试过了吗？挺酷的。

成员B：
嘿，试过了，没问题。

成员C：
总之，我猜我会开始着手那些单元测试了。

成员A：
现在音频功能都做好了，做单元测试有点没必要了吧。但你仍然需要它们。你昨晚就说要完成的。

成员C：
是，是，好吧。总之，我昨天写了一点文档，但我觉得在演示前我没时间完成它了。我能得到一些帮助吗？

成员B：
我可以帮你。我可能需要澄清一些事情。你介意我坐在你旁边工作吗？这样我可以在需要时问你问题。

成员C：
没问题，可以。

会议主持人：
在演示之前，还有人需要完成其他事情吗？

全体：
没有。

会议主持人：
很好。我们开始工作吧。

核心要点总结

本节课中，我们一起学习了项目演示前站立会议的关键要素。会议展示了团队成员如何清晰汇报进度（如“完成了页面布局与单元测试”），确认验收标准（“验收测试已验证”），并提出协作请求以解决剩余任务（如文档撰写）。有效的沟通与及时的帮助请求是确保项目顺利收尾的重要实践。

036：客户演示与待办事项优化

在本节课中，我们将通过一个模拟的客户演示会议，学习如何向客户展示产品功能、收集反馈，并基于反馈进行产品待办事项列表的优化与优先级排序。

概述

本次会议模拟了开发团队向客户代表展示产品当前进展的场景。团队演示了一个支持用户间音频连接的平板应用，并收集了客户关于新功能的想法。随后，团队与产品负责人一起，将这些新想法转化为具体的用户故事，并进行了故事点估算、风险评估和优先级排序，为下一个冲刺周期做准备。

客户演示与反馈

上一节我们介绍了课程背景，本节中我们来看看具体的客户演示环节。团队向客户展示了已开发的核心功能。

团队使用两台设备进行演示。当前应用展示了一本电子书，其布局模拟了真实书籍的阅读体验。

  • 所有与材料相关的图片都会显示在页面上。
  • 用户可以调整字体大小，以便轻松阅读文本。
  • 平板电脑支持横屏和竖屏两种使用模式。

接下来，团队演示了音频连接功能。他们选择了点对点音频连接方案，因为这种方案允许孩子们相互交谈，同时消耗更少的数据流量，并能更好地保护儿童的身份隐私。

用户可以通过点击一个按钮来连接在线的其他用户。由于当前只有这两台设备在线并打开了应用，它们成功建立了连接。随后，通过按下另一个按钮，可以启动音频流。此时，两台设备便可以相互通话了。

演示者走到室外进行测试。

演示者：“你好，能听到我吗？”
客户：“嗨，能听到，你的声音非常清晰。”

演示者返回会议室，并总结道，目前高优先级、高风险的功能已经开发完成，后续开发应该会更容易。

收集客户反馈

客户对团队的工作给予了高度评价。

  • 关于设计：客户确认团队采纳了其关于使用米白色背景而非纯白色的建议，这显著减轻了视觉疲劳，同时保持了良好的对比度。
  • 关于功能：客户对音频连接功能感到非常兴奋，并期待其对提升读写能力产生积极影响。

随后，客户提出了几个新的功能想法：

  1. 文本高亮：读者应能高亮页面上的文本。
  2. 保存高亮：当读者退出书籍时，其高亮内容应被保存。
  3. 书签功能：读者应能保存阅读进度。
  4. 有声书功能：读者可以收听录音朗读，并同时跟随书本阅读。

团队指出，当前资料库中尚未包含有声书资源，因此该功能暂缓考虑。团队感谢了客户的建议，并表示会将这些想法纳入考虑。

待办事项列表优化

在客户离开后，团队与产品负责人立即开始了待办事项列表的优化会议。目标是将客户的新想法转化为可执行的任务。

创建用户故事

首先，需要将客户的想法转化为格式化的用户故事。以下是创建的过程：

  • 想法：高亮文本。
    • 用户故事：作为读者，我希望能够高亮书中的文本，以便记住书中的重要内容。
  • 想法：保存高亮。
    • 用户故事：作为读者，我希望创建的高亮内容在退出书籍后能被保存，以便在我返回书籍时可以回顾它们。
  • 想法：书签功能。
    • 用户故事：作为读者，我希望我在书中的位置能被保存，以便我可以在之后返回到该位置。

评估故事点与风险

创建故事后，下一步是评估每个故事的工作量（故事点）和风险。团队采用了一种“同时亮牌”的方法来避免评估时的相互影响。

以下是评估结果：

  1. 高亮文本：风险低，故事点为 1。
  2. 保存高亮：风险中等（涉及数据保存，可能复杂），故事点为 2。
  3. 添加书签：风险低，故事点为 3。

确定功能优先级

最后，团队需要为下一个冲刺周期确定功能的优先级。他们列出了当前已计划的任务：

  1. 连接应用与数据库。
  2. 本地保存阅读材料。
  3. 实现浏览（带书籍封面）、选择和搜索功能。
  4. 创建用户账户系统（登录、重置密码）。
  5. 按理解难度或体裁对阅读材料进行排序。

经过讨论，优先级排序如下：

  • 最高优先级：连接数据库。这是应用的基础，必须优先完成。
  • 中等优先级：浏览、选择和搜索功能。
  • 较低优先级：本地保存功能被认为比书签、排序和账户功能更重要，因为它能确保用户在无网络时仍可访问书籍。
  • 最低优先级：账户功能和排序功能。

团队意识到当前冲刺的故事点可能已超负荷，需要在重新制定发布计划时移除一些功能。

总结

本节课中，我们一起学习了产品开发中的一个关键环节：客户演示与待办事项优化。我们看到了如何有效地向客户展示产品、获取有价值的反馈，并将模糊的需求转化为具体的用户故事。通过评估故事点、风险并排定优先级，团队能够清晰地规划下一步工作，确保开发资源集中在最能产生价值的功能上。这个过程是敏捷开发中持续交付和响应变化的核心实践。

037：模拟冲刺回顾会议

在本节课中，我们将通过一个模拟的团队对话，学习如何有效地进行一次冲刺回顾会议。冲刺回顾是敏捷开发中用于反思和改进团队工作方式的关键活动。

概述

冲刺回顾会议旨在让团队反思刚刚结束的冲刺周期，总结做得好的地方和需要改进的地方，并制定具体的行动计划，以便在下一个冲刺中做得更好。这是一个协作、非指责性的过程。

会议开场

上一节我们介绍了冲刺回顾会议的目的，本节中我们来看看会议是如何开始的。团队领导需要引导会议，并确保每个人都感到舒适和安全。

团队领导提议进行一次快速的回顾会议，认为团队可以从中学习，并对未来的工作有益。在获得团队成员同意后，领导建议了会议的基本流程：首先头脑风暴讨论做得好的和不好的地方，然后基于讨论结果找出改进方法。

总结成功经验

以下是团队认为在本次冲刺中做得好的方面：

  • 完成了所有预期的用户故事：这是一个显著的成就，尤其是在第一个冲刺中。
  • 坚持了每日站会：虽然不是每天早上的第一件事，但团队总能找到时间完成。
  • 用户故事均符合“完成的定义”：所有工作成果都达到了团队预先设定的质量标准。
  • 交付了可工作的产品：团队最终交付了一个令人印象深刻的可运行产品。

识别改进领域

在肯定成绩之后，团队需要以建设性的态度审视可以做得更好的地方。这个过程不是为了指责，而是为了持续改进。

以下是团队识别出的待改进事项：

  • 单元测试编写滞后：有成员承认在开始编写功能源代码之前，没有先写好单元测试。
  • 验收测试和标准定义较晚：团队应该在开始开发之前就写好验收测试和标准。
  • 任务板使用不足：任务板在冲刺期间多次未能准确反映实际进度，需要更勤勉地更新任务状态。
  • 故事点估算的准确性有待验证：虽然所有任务都按时完成，但个体故事点的估算精度可能需要更多冲刺周期来验证。

制定改进措施

基于识别出的问题，团队接下来需要商讨具体的、可执行的改进方案，以便在下一个冲刺中实施。

以下是团队为下一个冲刺制定的改进措施列表：

  1. 提前编写验收测试和单元测试：确保测试活动先行。
  2. 更积极地使用任务板：及时更新任务状态，保持信息透明。
  3. 增加结对编程：通过结对编程来加强知识共享、代码质量和团队沟通。
  4. 持续关注并改善团队沟通：将沟通改善作为一个持续的目标。

会议总结与结束

在制定了明确的改进计划后，团队领导对会议进行了总结。大家一致认为这次回顾非常有帮助，并对下一个冲刺的工作感到兴奋。会议在积极的氛围中结束。

总结

本节课中我们一起学习了冲刺回顾会议的完整流程。从会议开场、总结优点、识别不足，到最终制定具体的改进措施，每一步都旨在促进团队的反思与成长。记住，有效的回顾会议核心在于心理安全、聚焦改进和行动导向，其目标是让每个后续的冲刺都比前一个更加高效和顺畅。

038：模拟站立会议（周一）

在本节课中，我们将通过一个模拟的周一站立会议场景，学习敏捷开发团队如何规划冲刺（Sprint）初期的工作。我们将看到团队成员如何同步进度、识别依赖关系并协作解决问题。

上一节我们介绍了冲刺规划会议，本节中我们来看看团队如何在冲刺开始后的每日站立会议上同步工作。

以下是模拟会议中每位成员的发言与计划。

项目经理（PM）：
我将从今天开始着手处理数据库连接。因为我们这个冲刺中需要完成的大部分用户故事，都在某种程度上依赖于这个数据库连接。
乐观估计，我应该在今天结束前完成它，最晚不超过明天。
鉴于今天是冲刺的第一天，我目前没有遇到任何阻碍。

设计师（Wilson）：
既然你将负责数据库连接，那么我们可以同步完成一些设计元素，并创建验收测试和标准。

前端开发（Alexa）：
好的，接下来我来说。我将开始设计浏览和书签功能的界面。同时，我也会为“浏览书籍封面”和“书签”功能创建验收标准和测试。
我目前唯一的阻碍是，最好能有数据库连接。不过我可以像上个冲刺那样，先使用硬编码的材料开始编程，所以几天内应该没问题。

后端开发（Josh）：
我需要数据库连接才能完成我的任务。我的意思是，我也可以用模拟数据，但我觉得等数据库弄好会更方便。所以，我可以先创建验收测试，并开始编写单元测试。

测试工程师：
我也可以帮你做验收测试，Josh。这样你可以把所有精力都放在数据库连接上。

Josh：
这听起来不错。

团队：
让我们开始工作吧。

本节课中我们一起学习了敏捷团队在周一站立会议上的典型沟通模式。我们看到团队成员如何明确各自任务、识别对共享资源（如数据库）的依赖，并通过主动协作（如分担测试工作）来确保冲刺目标顺利推进。这种简短的每日同步是保持团队信息透明和快速响应障碍的关键。

039：站立会议模拟（周三）

在本节课中，我们将通过一个模拟的周三站立会议场景，了解软件开发团队在冲刺阶段如何同步进度、识别障碍并协调工作。我们将重点关注团队成员之间的沟通与任务更新。

好的，各位，我们来看看目前的进展。

我意识到我们的进度有些落后，因为我们刚刚才把数据库连接设置好。不过值得庆幸的是，这部分工作已经全部完成，所以我们可以顺利进行了。希望从现在开始一切都能顺利运行。

是的，抱歉各位，昨天花的时间比预期长得多，但我已经完成了数据库连接，并且也编写了相关的单元测试，执行时全部通过了。希望这个连接对大家都能正常工作。

今天我将着手开发搜索功能，目前没有任何阻碍。

好的，我昨天在编写浏览和选择功能（包括书籍封面和书签）的源代码。所以我今天会继续这项工作。如果我今天能完成布局程序，那么我将开始将其与数据库连接起来。所以目前我也没有阻碍。不过，乔希，我之后在连接时可能需要你的帮助。

没问题，到时候告诉我就行。

好的。我今天将开始为“本地保存”功能编写源代码。昨天我在等待乔希完成连接时，为几个功能编写了文档。既然现在连接完成了，我就可以真正开始开发这个功能了。现在连接已完成，我没有任何阻碍，让我们开始工作吧，我们有很多进度要追赶。

本节课中，我们一起观察了一个软件开发团队在站立会议上的交流。会议中，团队成员同步了各自的任务进度（如完成数据库连接、编写单元测试、开发搜索与浏览功能），确认了当前没有重大阻碍，并规划了当日的重点工作。这展示了团队如何通过简短高效的每日站会来保持信息同步、解决问题并推动项目前进。

040：周五站会

在本节课中，我们将通过一个模拟的周五站会场景，了解敏捷开发中每日站会的实际流程与沟通要点。我们将看到团队成员如何同步进度、识别风险并协调工作。

会议开始

让我们看看目前的进展。我不确定我们是否能在今天下午演示前100%完成所有工作。

成员进度汇报

以下是团队成员依次汇报的工作状态：

成员A（负责搜索功能）：
昨天，我正在编写搜索功能的源代码。我已经实现了一个搜索函数 searchDatabase(query)，它可以查询数据库。但我仍需将其连接到前端应用程序。这是我今天上午要完成的主要工作。

成员B（负责本地保存功能）：
我即将完成本地保存功能。昨天结束时我运行了单元测试，发现了一些错误，但我认为修复起来不会太难。这是我今天上午要处理的工作。该功能的其他部分均已完成。一旦这些测试通过，我的任务就完成了。目前没有阻碍。

成员C（负责浏览与书签功能）：
我完成了浏览功能，书签也能显示出来，但视觉效果不佳，尺寸比例有问题。我所有的单元测试都已通过。今天上午我会花些时间，尝试让书籍封面的显示效果更好一些。我应该在会议前完成所有文档的编写。我这边也没有阻碍。

会议结束

那么，我们开始工作吧。

本节课中，我们一起学习了敏捷站会的模拟场景。我们看到了三位团队成员如何清晰地汇报昨日成果、今日计划以及遇到的障碍。有效的站会沟通有助于团队保持同步、快速发现问题并集中精力完成冲刺目标。

041：16_04_5-5 客户演示模拟

概述

在本节课中，我们将通过一个模拟的客户演示场景，学习如何向客户展示产品功能、收集反馈，并规划下一个开发冲刺。我们将看到开发团队如何演示一个电子书阅读应用的核心功能，以及客户如何提供关键反馈来指导产品的未来方向。

演示开场与核心功能展示

感谢各位今天到场。我们的产品进展非常顺利，许多核心功能已经完成，因此这将是一次令人兴奋的演示。我将请Alexa开始介绍。

是的，我负责的是浏览功能。现在用户可以从数据库中浏览所有资料，可以滚动查看所有书籍并看到每本书的封面。当用户决定要读哪本书时，可以选择它。

如果用户之前从未读过这本书，选择后会直接进入书籍开头。如果用户之前已经开始阅读，应用现在会自动保存阅读进度，并将用户带回上次离开的地方。这意味着应用现在具备了自动书签功能。

此外，用户还可以搜索书籍。他们只需输入任何内容，浏览页面的结果就会根据搜索内容进行筛选。用户可以按流派、书名、作者或任何相关关键词进行搜索。

同时，你可能已经注意到，我们的应用已经连接到数据库。这意味着你们提供的所有资料，在无线网络连接下，都可以通过应用供用户使用。

离线阅读功能演示

我们的最后一个功能是本地保存资料的能力。当用户在浏览资料时，每本书旁边都有一个小的保存按钮。如果用户按下它，这本书就会保存到他们的设备上。这样，即使没有无线连接，用户也能查看和阅读这本书。

让我们来测试一下。我们选择这一本。现在，我们将设备切换到飞行模式，断开无线连接。然后我们返回应用。如你所见，除了我选择的那两本，所有其他书籍都已从浏览功能中消失。然后你可以像平常一样打开并阅读它们。

以上就是我们的演示。你们有任何问题吗？

客户反馈与未来规划

你们再次让我感到震惊。我简直不敢相信，仅仅两周时间，你们就完成了所有这些工作。

现在，我有一条关于这个项目未来的消息。但在谈这个之前，Daniel，你有什么想说的吗？

你们确实做得非常出色。我认为一个可能非常有价值的功能是，在浏览页面和实际阅读页面之间增加一个页面。我想读者会希望看到一个包含简介或评论等的页面，这样他们才能真正决定是否要读那本书。

另一件需要记住的事情是孩子，要关注孩子。所有这些功能都对儿童友好，但在上一次演示中，你们更多地关注了儿童。如果你们需要帮助，让这些功能对儿童更友好，请随时联系我。

是的，我们不想忽视儿童用户，这将非常重要，尤其是在下一个冲刺阶段。这引出了我要宣布的消息。

我过去可能跟你们提过一个教育贸易展。我们曾试图获得一个展位，但没有成功。现在，有一个展位空出来了，他们提供给了我们。问题是，展会就在下下周，所以我们需要一个相当扎实的原型在下一个冲刺阶段进行演示。鉴于你们刚刚展示的工作成果，我认为这不是问题。但我们应该讨论一下你们下一个冲刺要开发的功能。

考虑到贸易展的性质，我认为我们应该专注于产品的教育功能方面。

Daniel，你有空留下来帮我们决定下一个冲刺要开发哪些功能吗？

当然可以。

太好了，太棒了。那么，你们大家觉得怎么样？

我认为这听起来绝对太棒了。这是一个展示我们所有辛勤工作的绝佳机会。

听起来很酷。

我同意。

好的，我认为最合理的做法是回去讨论下一个冲刺的功能。你们觉得怎么样？

听起来很棒，带路吧。

总结

本节课中，我们一起学习了一个完整的客户演示与反馈收集流程。我们看到了开发团队如何清晰地展示浏览、搜索、自动书签和离线阅读等核心功能。更重要的是，我们学习了客户反馈如何提供关键的产品改进方向，例如增加书籍详情页和深化儿童友好设计。最后，我们看到了外部机会（如贸易展）如何影响产品路线图，并促使团队围绕新的目标（教育功能）规划下一个开发冲刺。这个过程体现了软件产品管理中持续沟通、灵活调整和以用户为中心的核心原则。

042：待办事项列表优化（周五）

概述

在本节课程中，我们将通过一个视频模拟场景，观察一个产品团队如何为下一个冲刺阶段优化他们的产品待办事项列表。我们将看到团队成员如何讨论功能优先级、权衡取舍，并最终确定冲刺计划。

根据我们之前的计划，在下一个冲刺中，我们计划开发账户功能，包括登录和密码维护。

我们还将添加浏览已读材料的功能。

此外，我们计划添加收藏夹列表、待读列表和弹出式词典工具。

然后，我们将添加好友列表以及与好友连接的功能。另外，还有上一个冲刺中被移出的排序功能。

这些功能中有许多能为产品带来很酷的体验，但我认为它们不会产生最大的教育影响力。你知道，同伴阅读功能会很重要，但我们需要更多。

我认为弹出式词典工具是下一个冲刺的必备功能。

我还希望看到我最初建议的阅读理解测试工具被实现。

这个想法听起来不错。那么，阅读理解测试会包含哪些功能呢？

此前，与理解测试相关的功能优先级较低，但我们绝对可以重新提高它们的优先级，以匹配我们新的关注点。与理解水平相关的功能包括：测试流利度和阅读理解水平的能力，以便根据你的理解水平为你推荐材料；应用程序可以跟踪阅读理解的进步情况；这些进步可以通过语音识别来跟踪。

你认为这些功能你们能完成吗？

说实话，我认为我们无法实现语音识别。要在一周内实现它太困难了。编程识别哪些声音和语速不仅需要大量研究，还需要大量编程工作。不过，所有其他功能都是完全可以完成的。

我同意。但是，如果不使用语音识别，我们如何跟踪阅读理解水平呢？丹尼尔，是否已经存在一个我们可以用作功能的阅读理解测试？

我想到一个测试，它是书面和多项选择题的结合，基于一个用于阅读理解测试的标准文本。否则，如果不听读者朗读，测试阅读流利度是相当困难的。

好的，那太好了。我认为我们应该实现多项选择和书面测试。

那么，我们必须去掉哪些功能呢？如果我们添加测试理解能力、根据阅读水平提供建议、跟踪进步情况以及根据阅读水平匹配用户这些功能。

那么，这意味着我们必须从当前为冲刺3制定的计划中，移除价值11个故事点的工作量。我考虑去掉浏览已读材料、与好友连接以及好友列表这些功能，这应该能释放出8个故事点。

是的，我同意。等等，阅读材料是否已经有对应的难度等级，我们可以用来根据用户的阅读理解水平匹配材料？

不，还没有。而且我认为我们无法在这个冲刺中完成这个功能。

有道理。我会记下来，为未来的迭代研究如何为数据库获取这些信息。

好的，我们现在还超出了一个故事点，所以必须再削减一个故事。

重置密码功能怎么样？我认为这对贸易展览来说不是必需的。

我同意。这听起来没问题。等等，我们上个冲刺移出的那个排序功能呢？我们还会创建它吗？

我认为我们并不真正需要它。我更愿意完成其他功能。

好吧，我本来真的很期待创建那个功能的。那么，我们将要完成账户功能、待读列表、收藏夹列表、弹出式词典以及阅读理解测试和匹配功能。

我认为这听起来很棒。你觉得呢，丹尼尔？

我同意。我认为我们既有一些很棒的教育功能，也有一些其他很酷的功能。我会把那个理解测试发给你，如果你需要帮助，我可以过来，或者你可以随时打电话或发邮件给我。

好的，团队，我迫不及待想看看成果了。祝你们顺利。

好的，待会儿见。

总结

在本节课中，我们一起观察了一个产品团队进行待办事项列表优化的过程。我们看到了团队如何：

  • 根据产品目标（教育影响力）重新评估功能优先级。
  • 对功能进行权衡取舍，决定增加哪些高价值功能（如阅读理解测试），并移除或推迟哪些功能（如好友列表、排序功能）。
  • 考虑技术可行性（如放弃语音识别）。
  • 最终确定下一个冲刺的、范围明确且可行的计划。

这个过程展示了敏捷开发中持续规划和调整的重要性，以确保团队始终致力于交付最高价值的产品功能。

043：冲刺回顾会模拟

概述

在本节课程中，我们将通过一个模拟的冲刺回顾会视频，学习敏捷开发中冲刺回顾会的标准流程和核心要点。回顾会是团队反思与改进的关键环节。

会议开场与目的

团队完成了冲刺，应用看起来很不错。团队对成果感到自豪。

项目经理提议进行一次快速的回顾会，因为接下来有一个重要的冲刺，需要确保团队处于最佳状态。

回顾会第一部分：做得好的方面

以下是团队在本冲刺中表现良好的方面：

  • 完成了用户故事：团队坚持不懈，最终完成了所有用户故事。
  • 提前编写测试：这是一个巨大的改进。
  • 沟通顺畅：站会富有成效，项目经理始终清楚项目状态，这是从上个冲刺以来的一项积极改进。
  • 保持积极与团队合作：尽管遇到了一些困难，但团队共同协作克服了它们。

回顾会第二部分：出现的问题

上一节我们总结了团队的优点，本节中我们来看看需要改进的地方。以下是团队在本冲刺中遇到的问题：

  • 依赖关系管理不足：数据库连接本应在之前的冲刺中设置好，因为本冲刺的许多工作都依赖于此。如果当时没有完成，整个冲刺可能失败。
  • 结对编程减少：由于时间紧迫，团队减少了结对编程。
  • 故事点估算不准确：幸好团队在开始前发现了这个问题。

回顾会第三部分：改进措施

在分析了优点和问题后，现在我们来制定具体的改进计划。以下是团队为下一个冲刺提出的改进措施：

  • 增加结对编程：尝试在分配下个冲刺任务时以结对形式进行。如果一两天后效果不佳，可以恢复原来的方式。
  • 保持良好沟通：目标是维持当前的沟通水平，避免倒退。

会议总结

团队认为这次回顾会很有成效，并为下一个冲刺做好了准备。

总结

本节课中我们一起学习了冲刺回顾会的模拟过程。回顾会通常包含三个核心部分：总结做得好的方面、分析出现的问题、并共同制定改进措施。有效的回顾会能帮助团队持续反思、协作并提升后续冲刺的效率。

044：模拟站立会议（周三）

概述

在本节课程中，我们将通过一个模拟的周三站立会议场景，来观察一个敏捷开发团队在日常站会中如何同步工作进度、讨论问题并规划当日任务。你将了解到站会的基本流程、有效的沟通方式以及如何处理开发过程中的优先级冲突。

会议内容实录与分析

会议开始，团队成员逐一进行汇报。

以下是第一位成员的汇报：

  • 昨日完成：完成了Daniel布置的阅读理解测验，并将其开发成了一个完整的功能。所有测试均已通过，文档也已编写完毕。
  • 今日计划：开发基于阅读水平为远程用户进行匹配的功能。
  • 所需帮助：希望相关账户能在其开始跟踪阅读进度改进功能前设置好，以节省时间。
  • 阻塞问题：无。

接下来，第二位成员进行汇报。

  • 昨日完成：完成了账户系统和登录功能，并根据Daniel的建议使登录流程对儿童更友好。开始了“单词释义”功能的开发，找到了儿童词典数据库并从Lisa处获得了必要的授权。目前实现了长按单词弹出窗口，但尚未连接释义数据。
  • 今日计划：开始将释义数据连接到弹出的窗口。
  • 阻塞问题：无。

随后，第三位成员开始汇报，但内容引发了关于任务优先级的讨论。

  • 昨日完成：一直在开发浏览材料排序功能。
  • 今日计划：原计划继续此工作。
  • 阻塞问题：无。

此时，其他成员提出了疑问：“等等，你不是应该在做‘收藏夹’和‘待读列表’功能吗？我以为排序功能已经被砍掉了。”该成员解释说自己对排序功能有很多想法，并认为“收藏夹”和“待读列表”功能只需要很少时间就能完成。

这引出了一个关键的项目管理问题：个人兴趣与项目优先级冲突。另一位成员明确指出：“不，这很重要。”团队决定暂时搁置争议，提议“我们稍后再单独讨论这个问题”。

由于上述讨论，该成员调整了计划：“好吧，我昨天是在做那个（排序功能）。现在我也不太确定今天要做什么了。”

总结

本节课我们一起模拟观察了一次敏捷团队的站立会议。会议中，团队成员同步了开发进度（如“完成登录功能”、“通过所有测试”），并明确了当日任务（如“连接释义数据”）。同时，我们也看到了一个典型的团队协作挑战：当个人想继续从事被搁置的功能（排序功能），而团队优先级要求他转向其他任务（收藏夹和待读列表）时，如何妥善处理。有效的解决方式是及时识别冲突，并约定在会后进行专门讨论，以确保站会高效、聚焦。

045：模拟站立会议（周五）🎬

在本节中，我们将通过一个模拟的周五站立会议场景，来观察一个敏捷团队如何同步工作进度、讨论障碍并规划当日任务。你将看到团队成员如何简洁地汇报工作、寻求帮助并协调任务优先级。

会议内容

以下是团队成员在站立会议中的发言记录，展示了各自的工作进展、计划及遇到的挑战。

Josh:
昨天，我按照Daniel的建议，将识字能力测试功能与账户创建流程连接了起来。我花了整个上午来实现这个功能。我还增加了允许用户重新参加测试的功能，以便他们可以重新评估自己的理解水平。今天，我计划编写基于水平的远程匹配功能的文档。此外，如果任何人需要，我也可以帮忙审查代码或运行验收测试。我目前没有遇到阻碍。

Samantha:
昨天，我基本完成了弹出式定义功能。在一天结束时我运行了单元测试，发现似乎还有一个小问题需要修复。修复之后，这个功能就可以进行验收测试了。Josh，如果你能帮我做验收测试，我将非常感激。

Josh:
太好了，谢谢。我是一边开发一边编写文档的，所以测试完成后，这个功能也就彻底完成了。我这边没有阻碍。

Daniel:
好吧，各位，我的进度严重落后了。那些列表功能花费的时间比我预想的要长得多。我在整个排序功能上花了大量时间。我想我今天只能完成其中一个列表的删除功能。这个功能已经与允许本地保存到设备的功能连接好了。我们应该先做哪个列表？

Samantha:
我个人认为，“待读”列表可能比“收藏夹”列表更重要。

Josh:
是的，我也是这么想的。你同意吗，Daniel？

Daniel:
同意。我应该在接下来几个小时内能完成它。另外，有人能帮我整理文档吗？我已经有很多笔记了，只是需要把它们更正式地写出来。

Samantha:
我可以做这个。

Daniel:
好的，谢谢。伙计们，我很抱歉，我感觉自己像个傻瓜。

Josh:
嘿，别担心。我相信完成一个列表也没问题。如果有任何我能帮忙的，请告诉我。

Samantha:
好了，团队，让我们把这件事完成吧。

核心实践与要点

上一节我们介绍了站立会议的基本形式，本节中我们通过具体对话看到了其实际应用。以下是本次模拟会议中体现的几个关键敏捷实践要点：

  • 进度同步：每位成员清晰地陈述了“昨天做了什么”、“今天计划做什么”以及“遇到了什么障碍”。
  • 障碍识别与解决：Daniel公开提出了进度延迟的问题，团队立即协作，通过优先级讨论（优先完成“待读”列表）和任务分担（Samantha协助整理文档）来应对。
  • 保持简洁与专注：会议围绕任务进展展开，没有深入技术细节，符合站立会议短小精悍的原则。
  • 团队支持氛围：当Daniel表达挫折感时，团队成员给予了鼓励和支持，这有助于维持团队士气。

总结

本节课我们一起学习并模拟了一个典型的周五站立会议。我们看到了团队成员如何通过结构化的沟通（昨日成果、今日计划、当前阻碍）来保持同步，如何协作解决优先级和资源问题，以及如何维持积极支持的团队环境。有效的站立会议是敏捷开发中确保信息透明、快速响应变化和保持团队前进动力的重要仪式。

046：客户演示模拟

概述

在本节课中，我们将观看一个客户演示的模拟场景。这个演示展示了一个为儿童设计的阅读应用，涵盖了账户管理、阅读水平测试、配对功能、词典工具和书单管理等核心功能。我们将通过这个演示来了解如何向客户展示一个软件产品的核心价值与用户体验。

演示开场与账户系统

演示者首先回顾了本周的进展，并向客户展示了一款功能完善的产品。

以下是账户系统的主要功能点：

  • 家长账户创建：家长可以通过点击按钮为自己创建账户。
  • 登录功能：家长可以登录自己的账户。
  • 管理子账户：登录后，家长可以看到关联到自己账户下的孩子账户列表。
  • 添加子账户：家长可以通过点击指定按钮添加新的孩子账户。

儿童登录与阅读水平测试

上一节我们介绍了家长端的账户管理功能，本节中我们来看看儿童用户如何登录以及应用如何评估他们的阅读能力。

儿童登录过程非常简单，他们只需点击列表中自己的头像即可。如果是首次登录，系统会引导他们完成一个阅读理解测试。

以下是阅读理解测试的流程：

  • 测试内容：儿童阅读一小段文本，并回答几个相关问题。
  • 动态调整：如果文本对孩子来说太难或太容易，系统会根据他们的得分，将他们重定向到更难或更简单的文本段落。
  • 生成阅读等级：最终，系统会给出一个分数，该分数直接对应孩子的阅读水平。
  • 重试机制：儿童可以随时在主屏幕上通过按钮重新参加测试。

基于阅读水平的配对功能

在确定了儿童的阅读水平后，应用可以利用这一信息来优化社交阅读体验。

儿童可以选择基于阅读水平进行配对。当他们像往常一样尝试连接时，会弹出一个窗口，询问他们是否希望根据阅读水平进行配对。如果周围没有阅读水平完全相同的人，系统会将他们与分数最接近的可用用户进行配对。

内置词典与书单管理

除了核心的阅读和社交功能，应用还包含了一些提升阅读体验的实用工具。

接下来展示的是弹出式词典功能。当儿童在阅读任何书籍时，如果遇到不认识的单词，只需长按该单词，词典定义就会立即弹出。这是一个儿童词典，定义非常易于理解。要退出词典，只需点击弹出窗口外的区域即可。

应用还允许儿童管理自己的阅读计划。

以下是书单管理的具体操作：

  • 添加到“想读”列表：儿童可以通过点击每本书旁边出现的星形按钮，将书籍添加到“想读”列表。
  • 本地保存：“想读”列表中的所有书籍都会自动本地保存到设备上，以便他们随时随地阅读。
  • 删除项目：可以通过点击每本书旁边的小垃圾桶按钮，从列表中删除书籍。

客户反馈与讨论

在功能演示结束后，客户团队与开发团队进行了交流，并提供了反馈。

客户首先确认了一个功能点：“不是应该还有一个收藏夹列表吗？” 开发团队承认这原计划中，但由于时间限制未能完成，并认为目前一个列表已经足够。客户表示同意，认为两个列表可能会让应用变得过于复杂，并称赞了当前的设计。

客户对应用的整体成果给予了高度评价，认为它将在贸易展上大获成功。他们特别赞赏了以下几点：

  1. 阅读理解测试：认为它比人工测试方便得多。
  2. 功能的教育影响力：相信所选择的功能将产生巨大的教育影响。
  3. 弹出式词典：认为它能帮助孩子在阅读时顺畅地查询生词。

同时，客户也提出了一个改进建议：可能需要一个入门教程，来引导孩子们发现并使用这些功能。开发团队认为这是一个好主意，但可以留待后续实现。

总结

本节课中，我们一起观看并分析了一个软件产品向客户演示的完整模拟过程。我们看到了一个儿童阅读应用从账户系统、智能测试、社交配对到阅读辅助工具的全功能展示。演示不仅清晰地呈现了产品价值，还通过客户互动环节，展现了如何处理反馈、调整优先级以及规划后续改进。这体现了软件产品管理中，沟通、演示和灵活响应需求的重要性。

047：项目回顾模拟 🎬

在本节课中，我们将通过一个模拟场景，学习如何进行一次完整的项目回顾会议。项目回顾是敏捷开发中的重要环节，旨在总结经验、识别改进点，以帮助团队在未来做得更好。

上一节我们介绍了项目收尾的各项工作，本节中我们来看看如何通过结构化的回顾会议，对整个项目进行复盘和反思。

这次项目旅程相当精彩，希望大家都乐在其中。现在，我想进行一次项目回顾。

我知道我们过去做过冲刺回顾，但你们中有多少人做过项目回顾？我没有。我听说过，但从未实践过。

这个项目的成功离不开团队每一位成员的辛勤工作。我个人想说，能与你们所有人共事，我感到非常自豪。

第一步：营造安全氛围

任何项目回顾的第一步，都是确保每个人都能舒适地、开放地谈论自己的想法。因此，我想先做一个快速的匿名投票。请在一张纸上写下一个1到5的数字，这个数字代表你在此次会议中参与开放对话的安全感程度。1表示非常不舒适，5表示非常舒适。

很好。我本以为不会有什么问题，确实，没有人给出低于4的分数。我们继续。

第二步：分享意义物件

大家都带了自己的“意义物件”吗？我们该如何处理这些物件呢？我希望每个人谈谈哪个物件对他们意义最大。

以下是团队成员分享的物件：

  • 乔什：我带来了一张截图，是我第一次单元测试失败时的打印件。我喜欢它，因为它提醒我，我的代码并非总是完美的，单元测试也很重要，即使它们会占用更多时间。哦，我还带来了亚历克莎给我买的一罐“杀虫剂”，是个玩笑。
  • 亚历克莎：我带来了这张有人留在我桌上的便利贴，上面写着“今天干得不错，继续加油”。我不知道是谁写的，请别告诉我，我有点喜欢这种未知的感觉。它帮我度过了一个艰难的日子，被欣赏的感觉很好。所以，谢谢写它的人。
  • 产品经理：我当然也带了东西。我带来了我们项目的燃尽图。我认为我们共同完成的工作量是惊人的，我想提醒大家这一点。我还带来了一本童书的实体版，就是我们为坎达塔项目使用的那本，我特意去买了一本。它是这个项目的纪念品，希望未来能将这样的书籍带给全世界更多需要的孩子。

也许之后，我们可以作为一个团队，和我们的物件一起拍张照片。

第三步：评估项目成功与否

那么，我们来多谈谈这个项目。它成功吗？我不知道。我们完成了所有预定任务，但我只是希望我们能继续做下去。我感觉我们没有打造出我们能打造的最好的产品。

我明白你的意思，但你必须记住，我们在专注于重要事项和按时交付方面确实做得非常好。而且我们必须在仅仅几个冲刺内为贸易展交付一些东西。在这么短的时间里，你不能期望完成太多。你说得对，我们本可以做得更多。乔什，你怎么看？实际上，我认为它相当不错。我的意思是，确实没发生什么大事。

第四步：构建项目时间线

那么，下一个练习是构建我们的项目时间线。考虑到项目周期很短，这应该相当简单。我们每个人在一张便利贴上写下一个事件，然后贴在这张纸上。之后我们再写下其他重要事件也贴上去。我来从项目开始，我们所有人开始一起工作的时候写起。

第一个重大事件应该是我们开始构建应用程序的时候，对吧？我认为我们应该先写下需求分析过程。我们可以把两者都写下来，这是一个协作的过程。

第五步：结构化讨论

现在，让我们思考一下这个时间线。我们可爱的产品经理给了我们一些讨论主题。我们来谈谈它们。

什么对我们很有效？

  • 我们的流程。我认为我们很好地遵循了敏捷实践。
  • 我认为我们作为一个团队合作得非常好，并且在所有事情结束后，我们的沟通也相当不错。

我们学到了什么？

  • 我学到了编写测试用例并没有那么难。
  • 我学到了在未与所有人沟通前，不应只做自己认为正确的事。
  • 我学到了Scrum可以成功应用于小型项目。我还学到了我在团队中工作得比我想象的要好。

下次我们会有什么不同的做法？

伙计们，你们太棒了。知道吗，这有很多内容。哇，我们在这个项目中确实做了很多，不是吗？

好了，差不多就这些了。我认为没有其他需要讨论的了。你们还能想到什么吗？没有，我想不到了。

第六步：会议收尾

那么，就这样吧。这次很有趣。我们拿着所有这些物件拍张照片怎么样？然后我可以马上发给你们。太棒了，谢谢你们和我一起完成这次回顾。

本节课中我们一起学习了项目回顾会议的标准流程。从营造安全氛围开始，通过分享意义物件建立情感连接，进而评估项目整体成败，并可视化项目时间线。最后，通过结构化讨论聚焦于“什么做得好”、“学到了什么”以及“下次如何改进”这三个核心问题，从而系统性地完成项目复盘，促进团队持续成长。

048：毕业祝贺与总结

在本节课中，我们将一起回顾并总结整个毕业项目的学习历程，并对未来的职业发展致以祝福。

你成功完成了课程，我们表示祝贺。阿尔伯塔大学为你在此专项课程中付出的辛勤努力感到无比自豪。

我们希望你能将所学知识应用于未来职业生涯的每一个阶段。

我们珍视你发布的每一条论坛帖子和发送的每一封邮件。与你共同学习的这段旅程非常精彩，我们感谢你的全心投入。

我们非常享受为你制作这些课程的过程，并希望你也同样享受学习的过程。

我们祝愿你在未来的所有努力中都能获得最好的运气。

因此，请随时告知我们此专项课程将你带向了何方。

再次感谢你，并祝贺你成功毕业。

本节课中我们一起学习了毕业项目的最终总结。我们回顾了整个学习旅程，强调了将知识应用于实践的重要性，并对未来的职业道路表达了美好祝愿。恭喜你完成这一重要的学习阶段。

posted @ 2026-03-29 09:33  布客飞龙II  阅读(10)  评论(0)    收藏  举报