探索性通话到测试：我们的 Bubble 开发流程

企业不断寻求利用最新工具来创建满足独特需求的产品和服务。在这一领域，最令人兴奋的发展之一是Bubble 等无代码平台的出现，它允许开发人员无需广泛的编码知识即可创建软件应用程序。

在我们的 Bubble 代理机构，我们已经开发了一套使用 Bubble 开发软件应用程序的强大流程。

在本文中，我们将引导您了解我们的开发方法，从最初的发现电话会议到最终的测试阶段。

为什么我们要解释我们的开发流程？

找到合适的 Bubble 代理机构具有挑战性。在发现过程中，知道要问哪些问题可能会令人困惑，而且——最重要的是，项目开始后会发生什么。

如果您已经有一些经验，您会希望确保您的业务能从与代理机构的合作中获得最大收益（即，您不希望有任何隐藏成本或令人不快的意外）。

虽然许多 Bubble 代理机构都在吹嘘他们的作品集、案例研究、预算和时间表，但没有一家会解释他们的开发流程。这是一个黑箱。

在本文中，我们旨在透明地介绍开发流程的不同阶段，并为您详细分解每个步骤的内容。这样您就知道我们是如何为客户实现成果的！

相关：什么是 Bubble 代理机构

1. 发现电话会议

发现电话会议是一次简短的初步会议。这是您和我们互相介绍、分享您的目标、需求和期望，并了解 Bubble 如何帮助您实现这些目标的机会。

发现电话会议通常涉及您（客户）和我们（开发团队，可能还有项目经理）。我们可以在 Zoom、Google Meet 或任何其他视频会议工具上进行通话。

发现电话会议的目标是：

• 互相了解并了解背景
• 获得您愿景、问题陈述、目标受众、价值主张和成功标准的宏观概述
• 确定您应用程序的主要特性和功能
• 确定是否有必要安排另一次电话会议——范围界定电话会议——以讨论您项目的详细信息

发现电话会议的结果是，您对如何帮助您的受众有了大致的了解。您还将收到我们的一封电子邮件，总结讨论的要点并提出下一步计划。

发现电话会议之后的后续步骤可能因您项目的复杂性和要求而异。一些可能的后续步骤是：

• 如有需要，签署合同或保密协议 (NDA)
• 安排范围界定电话会议，以定义您项目的范围、时间表、预算和可交付成果
• 创建您应用程序设计的线框图或模型
• 如有需要，探索 API 文档

这次电话会议为开发流程的其余部分奠定了基础。

2. 范围界定电话会议

范围界定电话会议是一次详细而深入的会议。在这次会议中，我们将深入探讨您的目标、需求和期望，并规划 Bubble 如何帮助您实现这些目标。

范围界定电话会议通常涉及您（客户）和我们（或开发团队，可能还有项目经理）。我们可以在 Zoom、Skype、Google Meet 或任何其他视频会议工具上进行通话。如有需要，可能会有多次范围界定电话会议。

范围界定电话会议的目标是：

• 详细了解您的需求，例如用户旅程、数据结构、工作流程、设计偏好和集成
• 识别您项目的主要挑战和风险
• 确定您项目的范围、时间表、预算和可交付成果
• 澄清您可能对 Bubble 存在的任何问题或疑虑

范围界定电话会议的结果是，就您想用 Bubble 构建什么以及如何构建达成清晰的共识。

接下来的步骤是：

• 分享一份初步提案，详细说明时间表、预算、里程碑和可交付成果
• 审查并批准提案文件
• 创建您应用程序设计的线框图或模型

范围界定电话会议是任何成功的 Bubble 开发流程的重要组成部分。它有助于您调整项目的范围和期望。

3. 用户故事

下一步是用户故事。

用户故事是用户希望通过您的产品做什么或实现什么的简短而简单的描述。它们从用户的角度编写，侧重于使用您的产品的价值或好处。它们帮助我们根据对用户最重要的事情来确定开发的优先级和计划。

为了编写一个好的用户故事，我们遵循一些指导方针：

• 使用标准格式：作为一名<角色>，我希望<功能>，以便<价值>。
• 具体简洁：我们避免模糊或模棱两可的术语，并专注于基本细节。
• 包括验收标准：我们定义如何知道用户故事何时完成并满足用户的期望。
• 使用角色：我们使用目标用户的真实和代表性示例，使您的用户故事更具相关性和同理心。

以下是博客平台的一些用户故事示例：

• 作为一名博主，我希望创建一个账户，以便我可以在线发布我的帖子。
• 作为一名读者，我希望评论博客文章，以便我可以与其他读者和博主分享我的反馈和意见。
• 作为一名编辑，我希望在博客文章上线前对其进行审查和批准，以便我可以确保质量和一致性。

用户故事与产品功能不同，因为它们侧重于用户的问题或需求，而不是解决方案或功能。产品功能描述产品做什么或如何工作，而用户故事描述产品为什么存在或服务于谁。

• 产品功能：博客平台有一个富文本编辑器，支持格式、图片、链接等。
• 用户故事：作为一名博主，我希望轻松格式化我的帖子，以便我可以让它们对我的读者更具吸引力和参与度。

用户故事帮助我们将复杂的项目分解为可管理的小块，我们可以逐步交付。通过编写清晰有价值的用户故事，我们可以确保我们构建的产品能够为真实的人解决真实的问题。

用户故事地图

我们使用一种称为用户故事地图的技术来更好地组织我们的用户故事。

用户故事地图是客户与我们产品从开始到结束的旅程的可视化。它包括他们通常在旅程中完成的所有任务。

用户故事地图帮助我们识别用户如何体验我们的产品，以及哪些努力将为他们带来最佳结果。它还帮助我们决定什么最重要，将工作组织成发布（提供新的客户体验），并降低用户价值较低的工作的优先级。

要创建用户故事地图，我们遵循以下步骤：

• 识别我们的角色：我们根据目标、需求、行为、痛点等定义我们的目标用户是谁。
• 定义我们的主干：我们按时间顺序从左到右列出我们的角色将使用我们的产品执行的所有高级活动（也称为 Epics）。
• 分解为任务：我们通过将每个活动分解为代表每个 Epic 中特定操作或步骤的较小任务（Stories）来添加详细信息。我们根据优先级（优先级越高越靠上）将它们垂直排列在每个 Epic 下。
• 切片为发布：我们根据其价值主张将相关 Stories 分组为水平片段（也称为 Releases）。

以下是用于托管和组织事件的平台的部分用户故事地图示例。

用户故事地图通过确保每个发布都提供完整的客户体验，而不是孤立的功能或任务，帮助我们创建一个可用的模块。它还帮助我们仅在考虑它们如何适应整体客户旅程时才将任务分配给前端或后端团队。

4. 线框图

线框图是您应用程序设计的视觉表示。它显示了您应用程序每个页面上元素的布局、结构和层次结构。它还指示导航和功能，并可视化用户旅程。

我们使用 Balsamiq 或 Miro 来创建线框图。

线框图应该：

• 粗略：线框图并非最终或精美的设计。它旨在成为捕捉您应用程序设计精髓的草图或蓝图。我们不考虑颜色、字体、图像或其他细节。
• 有界：线框图应定义您应用程序设计的范围和边界。它应显示您的应用程序中包含和排除哪些功能。它还应显示每个页面如何相互关联以及用户如何导航它们。
• 开放：线框图应允许灵活性和创造力。它不应将我们限制在固定或僵化的设计中。它应鼓励我们探索不同的选项，尝试解决方案，并根据反馈进行迭代。

创建线框图的一些最佳实践是：

• 从纸笔开始：在使用任何数字工具之前，我们通常从纸笔开始。它让我们能够快速勾勒出我们的想法，而不会被技术细节或限制分散注意力。
• 使用简单的形状和符号：为了使您的线框图简单明了，我们使用基本形状和符号来表示每个页面上的元素。例如，我们使用矩形表示按钮或文本字段，圆形表示图标或单选按钮，线条表示分隔符或边框等。
• 使用标签和注释：为了使您的线框图更易于理解和信息丰富，我们使用标签和注释来描述每个页面上的元素。例如，我们使用注释来解释元素的功能或交互等。
• 使用内容占位符：为了避免在此阶段陷入内容细节，我们使用文本或图像等内容的占位符——例如，段落或标题的 lorem ipsum 文本。
• 使用示例和参考：为了激发您的灵感，我们附上其他具有与您的应用程序相似功能或特性的应用程序或网站的示例和参考。例如，如果您的应用程序需要日历视图，我们将参考 Google 日历或 Outlook 日历如何实现。
• 使用反馈和测试：为了验证和改进您的应用程序设计，我们使用来自潜在用户或利益相关者的输入和测试。
• 使用迭代和修订：我们根据反馈和测试迭代和修订线框图，以完善和最终确定您的应用程序设计。

5. 最终提案

一旦我们绘制出用户故事和线框图，我们就详细了解了项目。我们现在可以与您分享一份具有约束力的提案，其中包含所有已规划好的内容——时间表、预算、里程碑和工作范围。

6. 高保真设计

高保真设计是您的产品完成时外观和感觉的详细而真实的表示。它们包括颜色、字体、图标、图像和交互。

我们使用 Figma 作为我们的设计工具，因为它易于使用、协作且功能强大。我们还可以与您的团队和利益相关者分享我们的设计以获取反馈和批准。

要在 Figma 中创建高保真设计，我们遵循以下步骤：

• 以用户故事和线框图为基础：我们使用用户故事来指导我们需要设计哪些特性和功能。我们还使用线框图作为布局和结构的基础。
• 应用视觉设计元素：我们定义并应用常见的视觉设计元素，例如调色板、排版、图标、间距等。我们的大多数项目都使用设计系统。
• 测试和迭代：我们与您分享我们的设计，以展示产品将如何工作。根据您的反馈，我们将对设计进行更改。

由于我们正在构建 MVP（最小可行产品），我们更注重功能而非形式。这意味着我们优先设计为用户提供价值的功能，而不是那些可有可无但可选的功能。这并不意味着我们的 UI 看起来像 2000 年代的产品。它将是一个美观的设计，但不会赢得任何奖项。

7. 开发

在最终确定用户故事、线框图和高保真设计之后，我们就可以开始 MVP 的实际开发了。在这里，我们使用 Bubble（一个无代码平台，让我们无需编写代码即可构建应用程序）将您的愿景转化为功能性 Web 应用程序。

我们使用 Trello 来跟踪每个功能的用例和验收标准。Trello 是一个工具，它允许我们创建带有列表和卡片的看板，这些看板代表开发过程的不同任务和阶段。我们还可以将文件、评论、清单和估算附加到每张卡片上。

我们将整个项目分解为多个冲刺（通常为一到两周），重点是交付为应用程序增加价值的功能。冲刺由多个史诗组合而成——所以我们不会先完成设计，然后是工作流，不是这样的。

每个冲刺都处理一个特定的应用程序模块，这样我们就可以保持专注并更快地取得成果。例如，我们可能会将一个冲刺专门用于登录页面、注册流程和用户个人资料页面。

每个冲刺的用户故事和验收标准都会添加到 Trello 看板中。随着开发的进展，我们会更新 Trello 看板——这样客户就可以看到进度。

没有成功的软件开发可以在“无线电静默”中进行。对于所有沟通，我们使用 Slack 来讨论疑问和其他问题。它比通过电子邮件或视频通话进行沟通要好得多。

一旦一个史诗完成，我们就进入测试的下一步。

8. 测试

测试是检查软件产品或应用程序中的缺陷和错误的过程。测试与 QA 不同，QA 更广泛，侧重于改进整个软件开发生命周期中的流程和实践。

测试是一种反应性和纠正性方法，侧重于发现和修复软件中的错误和问题。

测试的一个关键方面是使用每个用户故事的验收标准。必须满足验收标准，用户故事才能被视为完成并准备交付。它们有助于澄清期望和要求，并指导我们的工作。

测试团队使用验收标准对每个用户故事执行不同的测试。一些常见的测试类型是：

• 单元测试：验证每个软件单元是否按预期执行。单元是应用程序中最小的可测试组件。
• 功能测试：通过模拟业务场景来检查功能，基于功能需求。
• 回归测试：检查新功能是否破坏或降低了现有功能。

如果一个用户故事通过了所有测试，它将被标记为完成并进入下一步。如果一个用户故事未能通过任何测试，它将被返回给开发人员进行修复。

一旦一个冲刺完成，我们会要求您验证史诗（包含多个用户故事的大功能）以进行验收。您可以根据满意度接受或拒绝一个史诗。如果一个史诗被接受，它将被视为 MVP（最小可行产品）的一部分。如果一个史诗被拒绝，它将被送回开发团队进行改进。

测试过程确保 MVP 以最少的缺陷和错误交付，并满足您的需求和期望。它还有助于提高软件的质量、可靠性和性能。

9. 移交

一旦所有史诗和用户故事都经过测试，MVP 就被标记为完成。现在可以移交了。在移交过程中，有 4 件事要做：

• 应用程序所有权转移：Bubble 应用程序将转移到您的 Bubble 账户并设置账单。
• 应用程序连接到域名：应用程序可以连接到自定义域名。DNS 更改很简单，只需不到 10 分钟即可完成。有时，我们会在开发早期将应用程序连接到域名。
• 培训：我们的 Bubble 开发人员将向您演示应用程序——数据库结构和页面布局。我们不会要求您维护应用程序，但 Bubble 即使对于非技术人员来说，也很容易在高层次上理解。我们的客户很欣赏他们了解应用程序内部工作原理。
• 文档：我们记录应用程序并与您分享文档。它包括工作流、数据库结构、页面结构以及如何对网站的静态内容进行微小更改。我们为此使用 Notion 或 Google Docs。

10. 维护

维护是我们开发流程的最后阶段。

维护确保软件产品或应用程序在移交并部署给最终用户后继续正常高效地运行。维护还涉及更新和改进软件产品或应用程序以满足不断变化的需求和期望。

我们以两种方式提供维护服务：按需或按月付费。

按需维护意味着只要您请求或需要，我们就会提供维护服务。我们对按需维护服务收取固定的每小时费率。

按月付费维护意味着我们定期提供维护服务，例如每月、每季度或每年。我们对按月付费维护服务收取固定的月费。您可以选择适合您需求和预算的维护服务类型和级别。

您如何处理整个开发过程中的范围变更？

范围变更在任何项目中都是不可避免的。它们可能由于各种原因而产生，并可能影响项目的时间表、预算、质量和可交付成果。

我们理解范围变更有时是必要且不可避免的。但是，我们也尝试通过用户故事和线框图步骤尽可能地减少它们。

我们会与您一起审查用户故事和线框图，并在进入开发阶段之前获得您的反馈和批准。我们还在合同或协议中清晰明确地记录工作范围，其中概述了新的可交付成果、时间表、成本和责任。这确保我们在项目范围上达成共识。

然而，我们也承认在开发过程中，一些范围变更是在预期之中且不可避免的。我们遵循以下步骤来管理范围变更：

• 我们评估任何范围变更请求，并考虑变更的可行性、必要性和价值。
• 我们讨论范围变更请求——变更的利弊，并尝试达成双方同意的解决方案。我们还提出可以满足需求的替代方案。
• 我们在正式的变更单或修正案中记录任何范围变更请求及其解决方案，该变更单或修正案修改了原始合同或协议。我们还会相应地更新项目计划、进度、预算和可交付成果。

相关：如何与 Bubble 代理机构合作

客户在开发过程中的参与程度如何？

在线框图阶段之前，参与程度很高。在此之前，我们需要您的输入来了解我们需要构建什么以及我们是否走在正确的道路上。

大多数软件开发项目失败不是因为预算、时间表或技术挑战，而是因为期望未能实现。

将您心中的想法转化为纸面并不容易。当您必须向他人解释时，就更困难了。通过用户故事和线框图，我们试图理解您心中的愿景。

一旦我们理解了，您就可以退后一步，我们就可以开始开发产品了。

这正是 NocodeAssistant 运作每个项目的方式。如果您已准备好开始 Bubble 构建，our Bubble agency team 将全程遵循此流程——从探索到交付。预约一次电话和答，讨论您的需求。