《避免过度构建 —— 最小可行产品（MVP）和故事映射如何让你保持专注》—— 博客系列第三部分
我们已涵盖的内容及后续内容
在第二部分中，我们通过确保利益相关者的参与、明确且可执行的需求、可行的设计方案、结构化的文档记录、主动的依赖关系管理，以及运用 ROAM 方法尽早识别风险，奠定了坚实的质量基础。在第三部分，我们将在此基础上探索先进的质量实践方法，这些方法将推动项目的持续改进并助力项目取得长期成功。
- 最小可行产品（MVP）和故事映射：真正需要的功能是什么？
7.1 为什么最小可行产品（MVP）行之有效
最小可行产品（MVP）迫使你专注于核心功能。你无需立即构建一个具备所有花哨功能的全面系统，而是着眼于能够交付价值的最小必要功能。这使你能够更快地交付产品，收集反馈并做出调整。与之相反的做法 —— 一次性构建所有功能 —— 则存在风险，并且可能导致无休止的延误。
这是否应纳入质量计划呢？也许不一定，但质量关乎控制。专注和明确的项目范围能带来这种控制。
7.2 故事映射的实际应用
为了确定第一个版本中应包含哪些内容，你可以使用故事映射。将所有可能的用户故事写在便利贴上或记录在数字看板上，按照流程的逻辑步骤对它们进行分组，然后与你的团队和利益相关者共同决定哪些是首次发布时的必备功能。这样自然而然地就形成了一系列故事，它们共同构成了最小可行产品（MVP）。之后，你可以根据反馈和优先级来规划其余的故事。
- 架构设计：一个可视化的基准
8.1 参与式设计
当我们想到架构时，常常会认为它是由一位架构师制定的 “圣杯” 般的方案。更好的做法是让整个团队参与到一个会议中，共同讨论高层次的架构。有哪些服务？它们如何相互通信？有哪些数据？安全和监控在其中扮演什么角色？
8.2 一份动态文档
与设计方案一样，你的架构图也是可以随着项目进展而变化的。因此，要确保将其集中记录下来（可以使用 Confluence、SharePoint 或其他你所使用的工具）。如果你后来决定换用一个更好的数据库，那就更新架构图。这样能让每个人都了解技术决策背后的理由。最好使用架构决策记录（ADRs）（因为，当然，图表也需要更新）并应用 “架构即代码” 的理念。这使得工程师与架构师之间的协作更加容易。
最小可行产品（MVP）与架构设计的快速有效方法：
- 专注于核心功能
- 使用故事映射来确定优先级
- 让整个团队参与架构设计
- 维护一份动态的架构文档
-
应用 “架构即代码” 以保持一致性
-
概念验证（PoC）：在全力投入之前验证你的假设
9.1 为什么概念验证（PoC）如此有价值
在创新项目中或使用新技术时，概念验证（PoC）通常是回答诸如 “这个 API 速度够快吗？” 或 “将这个人工智能模型集成到我们现有的技术栈中难度有多大？” 这类问题的最佳方式。通过概念验证（PoC），你构建一个小型的产品，测试你所需要的内容，并吸取经验教训。其代码本身实际上应该被丢弃，因为它纯粹是用于实验的。
9.2 演练你的开发和测试流程
概念验证（PoC）阶段也是设置持续集成 / 持续交付（CI/CD）管道和测试流程的绝佳时机。开发人员如何提交代码？哪些测试会自动运行？你希望多快得到关于构建的反馈？通过在概念验证（PoC）阶段对这些进行实验，你可以避免在后续真正的产品开发中不得不搭建一个全新的管道。
- 开发过程：代码审查、分支管理、持续集成 / 持续交付（CI/CD）
10.1 达成共识可避免混乱
不同团队的开发过程可能差异巨大。最重要的是要达成清晰的共识，这样每个人都知道该如何工作，并且不会不必要地相互妨碍。可以考虑以下方面：
- 分支策略：你是使用 Gitflow 模式（带有开发分支和功能分支），还是采用基于主干的方法？
- 代码审查：何时必须进行审查？由谁来进行审查？具体要检查哪些内容（仅仅是代码质量，还是也包括功能行为）？
- 持续集成 / 持续交付（CI/CD）：自动化你的构建、测试以及任何部署过程，这样你就能持续获得关于代码质量的反馈。
10.2 避免 “分析瘫痪”
虽然达成共识是好事，但也有可能在这些共识上过于纠结。要讲究实际。如果一个团队规模较小且成员之间每天都有交流，那么一个过于复杂的分支策略可能弊大于利。所以要根据团队的实际情况和文化来调整你的流程。目标是快速且稳健地交付产品，而不是制定过多的流程。
概念验证（PoC）与开发过程的快速有效方法：
- 使用概念验证（PoC）来验证假设
- 在概念验证（PoC）阶段尽早设置持续集成 / 持续交付（CI/CD）
- 保持流程务实，避免过度设计
总结
在第二部分中，我们通过利益相关者的参与、明确的需求、结构化的文档记录、主动的依赖关系管理，以及运用 ROAM 方法尽早识别风险，建立了坚实的质量基础。在第三部分，我们专注于先进的质量实践，包括使用最小可行产品（MVP）和故事映射来确定功能的优先级，通过参与式的架构讨论并维护动态文档，以及在全面实施之前进行概念验证（PoC）测试以验证技术可行性。最后，我们通过在分支策略、代码审查和持续集成 / 持续交付（CI/CD）自动化方面达成清晰的共识来完善开发流程，以确保效率，避免不必要的复杂性。
下期预告：我们将剖析测试、自动化和质量责任方面隐藏的陷阱 —— 如何在速度与稳定性之间取得平衡，避免陷入 “看似完成实则未完成” 的陷阱，并建立一个能让你的团队保持敏锐、让你的产品坚如磐石的流程。《在每一个步骤中嵌入质量 —— 从测试到持续改进》
如果你对如何引入最优质量计划有疑问，请随时通过邮件 qa@the-experts.nl 与我们联系。
