持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第4天
介绍
在第3章中，您已经了解了敏捷方法的基本特征。在本章将所有的概念是如何联系在一起的。
在本章结束时，您将更深入地了解哪些步骤对于准备项目执行至关重要，以及 Scrum 角色需要如何参与以确保应用程序生产的一致和结构化方式。
在本模块中，您将学习：
- Scrum 协作的高级流程概述
- Scrum 流程中各个角色之间的依赖关系
- 如何证明最小可行产品的价值
用例 - 动手练习的个性化
我们答应你动手练习，现在是时候了！由于很难在网上介绍团队合作和敏捷，我们想请您戴上在 Tangram 公司工作的人的帽子！
到目前为止，您只是远远地跟随 Sophie 和她对敏捷方法论的理解，现在是时候动手了！在公司内部，Sophie 决定任命你为产品负责人！ 您不仅受雇于 Tangram 公司，而且您现在被信任为产品负责人，真棒！请记住，这也意味着 Sophie 的想法现在也是您的想法。
当你假装自己是员工时，认真对待每一个练习，并尝试应用之前模块中的知识（你总是可以回来更新你的知识）。
我们还邀请您将这些练习应用于您的公司或情况。您可以根据需要下载任意数量的模板，并为以下练习填写一份模板，一份为您自己的真实情况填写一份！
好了，让我们系好安全带，开始这激动人心的旅程吧！
Scrum 协作流程
从企业主有了开发应用程序的想法的那一刻起，就需要对应用程序的想法进行分析，以检查其有效性和可行性。Sophie 检查了 App Store 上可用的竞争应用程序。她想要构建的 Tangram 应用程序不仅应该在外观和感觉上脱颖而出，而且还应该通过它将提供的功能脱颖而出。她的想法需要清楚地传达给 Scrum 团队。
为了更清楚，让我们一步一步地了解业务和 IT 之间的协作过程——让我们运用我们的理论知识。
在我们进入敏捷特定之前，Mendix 已经介绍了确保产品有效性和基本目标所需的额外步骤。在直接跳到 Scrum（行业特定）之前，此准备工作分三个步骤（特定于 Mendix）完成：
- 商业案例 - 证明合法性- 应该分析您想要实现的应用程序创意是否适合 Mendix，并且它是否利用了高商业价值。
- 组建跨职能团队- 一个受过良好教育、协调一致且结构合理的团队能够以敏捷的方式进行协作，同时提供快速和高质量的结果。
- 定义最小可行产品 (MVP) - 从价值角度定义将作为第一个产品增量交付的功能对于项目成功至关重要。
在下图中查看与 Scrum 流程相关的那些：
好，那我们开始吧！
第 1 步： 商业案例： 证明可行性
在 Sophie 的案例中，在验证应用程序创意时，她的目标是通过在她的应用程序中加入一些创新的新技术并加入使应用程序与其他应用程序区别开来的独特功能，从而达到“哇”的效果。
在开发应用程序时，创建一个描述情况的单页页面是很常见的：它解决了什么以及它将利用什么价值。是产品负责人（记住，是你！），他们的行动在项目的这个阶段至关重要。PO 需要能够从价值的角度进行思考，并在设置和确定积压工作的优先级时使用基于价值的思考。
苏菲让你参与头脑风暴会议。在本次会议中，您将创建一个单独的寻呼机来描述以下内容：
- 应用程序的愿景（创建服务/产品的动机以及它应该启动的转变）。
- 客户和用户（服务/产品地址所在的市场或细分市场）。
- 用户需求（用户通过使用服务/产品可以解决的问题，以及为用户群体带来哪些好处）。
- 业务目标（公司将如何从服务/产品中获利以及业务目标是什么）。
- 解决方案（如何满足现有的用户需求和业务目标）。
步骤 2. 组建跨职能团队
由于您担任产品负责人，Sophie 也填补了 Scrum 团队的其他职位：她聘请了一名 Scrum Master 和几名开发人员。你们总是应该互相了解，并确保每个人都理解你在上一个练习中刚刚起草的 Maker Vision 文件。
（如果您的同事也在学习此课程，请让他/她在您的团队中选择一个角色。如果您愿意，您甚至可以通过转换角色来练习！）。
下一个挑战是定义最小可行产品 (MVP)。
步骤 3. 定义 MVP
如果您花时间在错误的策略上，您的产品可能不会成功。您专注于创建最小可行产品 (MVP)。MVP 是具有最关键功能的应用程序的第一个版本，它解决了用户的特定问题，减少了一些不错的功能。MVP 是最小的第一个产品增量。产品越早上线，您就越早获得投资回报 (ROI)。作为产品负责人，你面临的挑战是定义一个普遍的问题、价值、收集关键用户、尝试理解问题并提炼出你想要构建解决方案的想法。
关注 MVP 的价值是您应用成功的主要因素。与您的团队一起定义所需解决方案的哪一部分将成为您的团队将在第一个 Sprint 之后交付的产品增量。过去曾构建过 Mendix 应用程序的开发人员能够估计在第一个 Sprint 中可以涵盖多少用户故事。请记住，您想证明产品的价值，因此请关注最重要的要求！
自己定义 MVP 是一个很好的练习。继续用 MVP 的定义扩展您在上一个练习中填写的模板。有了 MVP 的明确定义，您就可以开始设置 Product Backlog。你在里面放什么？
步骤 4. 设置 产品 待办事项
首先，您需要创建一个项目来管理 Product Backlog。 导航到home.mendix.com，按下屏幕右上角的Create App按钮并完成应用程序创建步骤。 为了方便起见，选择一个空白模板并为您的名字指定一个名称（我的敏捷应用程序会完成这项工作！）
导航到窗口左侧导航栏中的协作/故事选项卡。 在中间窗格中，您将看到用于添加和维护用户故事的区域。该区域的底部标记为待办事项。 通过点击添加新故事链接，将出现一个弹出窗口，您可以将用户故事添加到此列表中。
按照我们在第3章中介绍的格式定义 10 个用户故事。此时，您不需要分配故事点。确保您已添加标题 和说明字段。故事类型可以设置为功能，因为您的用户故事描述了新功能。让我们同意其中一个故事是：“作为管理员，我希望看到一个仪表板显示注册用户的数量、产生的收入以及有关用户的更详细信息，以便我深入了解我的应用程序的采用和成功”
在接下来的一个步骤中，您将进行产品待办列表细化。开发团队将帮助您使用户故事更加精确。但是请注意，开发人员希望您在开始改进用户故事后指出其优先级。因此，您需要通过将用户故事拖放到Product Backlog 中来重新排序， 确保最重要的故事位于列表顶部。
Product Backlog 作为Sprint Planning的输入。
步骤 5. Sprint 计划
本次活动由 Scrum Master 组织。产品负责人和开发人员参加此会议，以定义将选择产品待办列表中包含的用户故事的哪个子集用于即将到来的 Sprint。
在下一个作业中，您将创建一个新的Sprint。按下New Sprint按钮，并为其命名。将有助于 MVP 实施的用户故事从 Product Backlog 拖放到 Sprint Backlog，并为它们分配故事点。此外，将当前的Get Started Sprint 设置为Completed。这会将您的 Sprint 1 设置为活动状态，使开发人员能够修改用户故事的进度。
在本次会议期间，故事点需要与开发人员协商分配。在本练习中，假设您已达成此协议。所以继续并根据估计的复杂性分配故事点。
除了分配故事点外，每个用户故事都需要分解为一组任务。
让我们考虑一下我们的示例用户故事：“作为管理员，我希望看到一个仪表板显示注册用户的数量、产生的收入以及有关用户的更详细信息，以便我了解我的应用程序的采用和成功”。 对于这个用户故事，可以定义以下任务：
- 创建具有仪表板布局的主页以可视化管理信息。
- 在主页上创建按钮，连接到概述页面，其中包含有关注册用户和产生的收入的信息。
- 创建概览页面，每个页面都提供有关注册用户动态及其付款的历史数据和统计信息。
同样，找出您在 Sprint 1 中分配最高优先级的前 3 个用户故事，并定义相关任务。
一旦设置了 Sprint 1，包括用户故事和相应的任务，开发团队将开始实施它们。
步骤 6. 开发
在 Sprint 计划之后，开发团队将参与 Sprint Backlog 中包含的用户故事的实施。他们会将每个用户故事的状态从To-Do更改为Running，从Running更改为Done。 只有在产品负责人正式接受之后，才能完成用户故事。开发人员可能会以 PO 的身份向您咨询，以阐明与他们正在处理的用户故事相关的需求。
要了解用户故事的状态是如何更新的，请将第一个用户故事设置为完成， 并将接下来的两个用户故事设置为正在运行。
在开发的同时，Scrum Master 计划了一个产品待办列表细化会议。
步骤 7. 产品待办列表细化
在朝着 MVP 努力时，您可能会在此过程中更改优先级。为了确保开发团队了解优先级的变化，产品负责人会向团队介绍情况，并更改待办事项中用户故事的顺序。
改变优先级可能会影响 Sprint 的执行。严格来说，如果 Running Sprint 中的用户故事范围发生变化，则应该取消该 Sprint，并开始新的 Sprint。在实践中，开发团队可能会完成相关的用户故事，完成当前的 Sprint，并开始包含新偏差的新 Sprint。
由于您将经常更改优先级，因此练习这样做也是一个好主意。所以继续改变产品待办列表中用户故事的顺序吧！
第二天（实际上是每一天），团队将聚集在一起参加每日站立会议。
第 8 步. 每日站会
每日站立会议是每天以与开发任务交错的方式发生的会议。这次会议向每个人通报了进展、意图和障碍。通常，Scrum Master 和开发团队会参加这些会议，但您也可以参加此会议以获取最新信息。
当开发团队在这次会议之后继续开发任务时（参见上一步），产品负责人参与到产品待办列表对齐中。
步骤 9. 产品待办列表对齐
作为产品负责人继续发挥领导作用，您需要确保任何可能影响产品待办列表优先级的重要信息与业务负责人保持一致。除了参与产品待办列表细化之外，产品负责人还有责任与业务负责人定期举行协调会议。在这些会议期间，您可以告知业务负责人当前的进展、挑战，并定义必须反映在产品待办列表中的优先级的任何相关更改。
考虑可能的风险以及如何减轻这些风险总是一个好主意。您可以讨论您的缓解策略，并在事情没有按照您的计划进行时做好准备。你能想到在项目的这个阶段可能发生的一些风险吗？如果您确定了一些风险，请尝试定义各种替代方案来减轻这些风险。
当 Sprint 接近截止日期时，是时候举行 Sprint 评审会议了。
第 10 步. Sprint 审查
在 Sprint 结束时，Scrum 团队参加由 Scrum Master 组织的 Sprint Review 会议。基于准备好的测试脚本，开发人员将操作平台，并展示实现用户故事的解决方案。在 Sprint 1 的情况下，将展示 MVP。在这次会议期间，企业主和其他利益相关者很可能会出席，以验证迄今为止在项目中所做的投资。产品负责人展示解决方案并证明所选 MVP 的商业价值。
在 2-5 分钟内练习推销 MVP 及其价值是产品负责人要做的一个很好的练习。如果您不知道从哪里开始，请从编写您要展示的内容开始。别忘了提到MVP的价值！
在您向 Sophie 展示 MVP 后，她会为您提供一些有价值的反馈。是时候将这些反馈纳入产品待办列表了！
步骤 11. 更新产品待办事项
在 Sprint 评审之后，产品负责人收集业务利益相关者提供的反馈，并确保其反映在产品待办列表中。一些积压的项目可能会获得另一个优先级，一些可能会被完全放弃。开发团队通常可以将内容添加到产品待办列表中。您会在更成熟的团队中看到这种情况。当然，为了保持产品待办列表井井有条，您需要就开发团队可以调整的内容以及他们如何调整的明确规则达成一致。确保开发人员在完成更改后通知您是一个明智的协议！
当您注意到 Product Backlog 已扩展时，请确保您了解背后的想法。如果有不清楚的地方，请确保在下一次产品待办列表细化会议期间解决此不明确之处。
第一个 Sprint 已经完成。现在是评估的时候了。整个 Scrum 团队都参加了 Sprint 回顾会议。
步骤 12. Sprint 回顾
随着 Sprint 临近截止日期，Scrum Master 组织了 Sprint 回顾会议。整个 Scrum 团队评估流程、协作和其他需要关注的方面。最多 3 个改进点作为下一个 Sprint 的重点。这是迭代和持续改进过程的良好开端！
由于产品负责人有责任让 Sophie 了解项目的进度，因此请确保您也将回顾的结果告知她！
那么，接下来会发生什么？在通过步骤 5 到 10 迭代直到到达最后一个 Sprint 之后，将进行最后一个产品演示会话。
步骤 13. 产品演示
在本次会议期间，将邀请更广泛的利益相关者群体来预览最终产品。确保让一些关键利益相关者参与多个演示会议，以更好地与业务保持一致。在产品演示期间，将汇总之前 Sprint 中交付的所有产品增量，并作为单个最终产品呈现。满足国防部制定的验收标准的产品被认为是成功的。在计划的时间内交付并保证和确认产品质量是一项重大成就，应该庆祝！
当您的项目取得了成功的切实成果时，Sophie 可能会让您参与头脑风暴新的应用程序创意，并为验证选定业务案例的合法性做出贡献。尽管您已经在敏捷协作过程的第 3 步中练习了创建 MVP，但您需要知道如何开始验证业务案例的合法性，以防不清楚要继续使用哪个应用程序。在下一讲中，您将学习专注于业务案例的价值。
总结
在本章中，您了解了高级 Scrum 流程概述。您已经看到参与 Scrum 流程的各方是如何协作和相互交互的。此外，您了解了 MVP 的价值。
