我们如何利用“Ship Small”在 GitHub 上快速构建新功能

“船小！船快！”和“船要学！”

你在推特上看到过这种说法。但实际操作起来又如何呢？

我是GitHub Actions团队的成员，我们每天都会“少量交付”，以便快速构建新功能。就我个人而言，这是我最喜欢的软件构建方式。在这篇文章中，我将向你展示我们是如何做到这一点的。

让我们构建一个新功能

在这篇文章中，我们假设正在为一个 Web 应用构建一个新功能。它拥有复杂的 UI 和后端，一个小团队大约需要 6 周的时间才能完成。

项目规划，定义最小范围

首先，首席工程师、产品经理和工程经理共同协作，确定最小范围。我们确定哪些部分是必须的，才能让这个新功能对用户有价值。

然后，首席工程师会将任务分解，并在项目板上确定优先级。他们的工作不是解决所有技术细节，而是找到足够的信息，将项目分解成足够小的部分，以便人们能够立即开始工作。

在规划过程中，我们不会花费大量时间去敲定细节。完美的前期规划可能会成为交付的大敌。我们知道，只要定义了最小范围，我们就能不断迭代和改进。软件永远不会完美。

仍有一些事情需要解决，但我们不需要等待就开始。

开始编写代码

尽快开始至关重要。我从未见过任何软件项目完全按照计划进行。一旦开始编写代码，我们就知道会发现一些可能改变我们方法的新信息。

我们需要灵活应对，并随着了解的深入而不断改进。当个人发现问题时，他们会将其记录在新的问题中，并将其添加到项目计划中。

第一个拉取请求：样板

由于此功能有一个 UI，一位工程师会为其完成样板设置。这是一个空白页面，带有 URL，并带有功能标志。它本质上是该功能的“Hello, World”。

这应该是一个非常快速的任务。他们会打开拉取请求，标记其他参与该功能开发的人，然后我们会将其交付到生产环境。团队中的每个人都会被添加到功能标记中，现在他们就可以在生产环境中看到空白页面了。

我不能过分强调这个第一个拉取请求有多么重要。

一旦合并，我们现在可以让其他人更容易地在其基础上进行构建，而不会互相冲突。如果你的目标是“小规模交付”，我相信项目一开始就这样做也至关重要。第一个变更是为后续变更树立的榜样。现在，将
尚未完成的产品交付到生产环境中已经成为一种文化。

我们现在可以拥有并行的工作流：

• 1 名工程师可以开始处理向该页面提供数据的后端工作。
• 另一位工程师可以开始从事前端工作。
• 设计师负责 UI 设计。如果他们懂编程，就直接写标记 + CSS。

现在每个人都可以做出贡献，并且我们能够自信地将部分完成的工作交付生产（请记住，它是在标志后面）。

随着小部分工作的完成，每个人都会发起拉取请求，互相征求意见，并最终合并到生产环境中。项目的共享环境很高。

如果我们需要其他团队（例如安全团队）的审核，这些小型 PR 对于外部团队来说审核起来相对容易，这让我们能够更快地获得反馈。

这很重要，因为：

• 它允许人们异步工作（我们是远程/不同的时区）。
• 每个拉取请求都很小，并且会被其他人审核。这样既方便审核，又能让每个人都了解进度/背景
• 项目利益相关者可以获得标记的功能并查看生产以了解进度（并提供反馈！）

永不被阻止，尽快开始

在开发软件时，我们经常会陷入一种境地：认为“我们需要其他人提供 X 才能开始”。我从未发现这种说法完全正确。
我见过一些软件项目陷入停滞状态，工程师们互相等待（这可能会浪费几天甚至几周的时间）。通常情况下，我们总能开始做某件事。

例如，在启动前端之前，您可能需要 API 中的数据。您可以将其粘贴到 JSON 文件中，然后模拟 API。这样，您就解锁并可以开始使用了。之后，您将了解所需数据的信息，并能够将这些信息提供给负责 API 的开发人员。这将使他们的工作更轻松，并且可能更快地为您提供所需的 API 端点。

生产代码是最好的代码

我们希望尽快将变更投入生产，这是有原因的。

当代码成功合并并部署到生产环境时，我们就已经消除了许多不确定性。我们知道它通过了持续集成 (CI)，我们知道它不会导致网站瘫痪。

即使它被标记在后面，也总有出错的可能。将它投入生产可以增强我们对它的信任，也使团队更容易在
此基础上继续推进。信心是推动发展的巨大动力。如果我们想要快速构建这个功能，两者缺一不可。

反馈回路

随着项目的进展，我们每天都能看到生产环境的变化。一旦功能开始发挥作用，我们就有机会邀请更多人参与进来。
我喜欢与安全、文档、支持、销售、业务开发等部门的人员分享。将他们添加到功能标记中，并征求他们的反馈。

还记得我们是如何从一个非常基本的项目计划开始的吗？这时，我们会收到反馈，我们会将这些反馈转化为新的问题（项目板上的任务），并将其反馈
到开发过程中。

我们现在正在迭代该功能，使其更加完善。迭代对团队来说很容易，因为我们一直在进行细微的修改。大家对
所有功能的运作方式都有着共同的理解，因此贡献代码也很容易。我们对此充满信心，因为大部分代码都已投入生产。

就我个人而言，这是每个项目中我最喜欢的阶段。如果一切从一开始就安排得当，那么此时应该会有很大动力推动一切向前发展。

反馈 -> 代码 -> 交付这一过程不断循环，直到我们可以将产品交付给真正的用户。

运送给真实用户

一旦团队完成了最低限度的开发，就该开始将这个新功能推向真正的用户了。
我们遵循的大致流程是“人员入职”->“获取反馈”->“正式上线”。这里可能还有很多其他细节（例如文档、容量、安全性、滥用情况）取决于具体功能。

“员工沟通”是指我们将该功能提供给每位员工，并征求他们的反馈。我们公司规模庞大，这对于发现
潜在问题非常有效。在此期间，我们还会更密切地关注仪表，以发现潜在的错误/性能问题。人们使用我们产品的方式千差万别
，我们无法预料所有情况。

“正式版”是指我们将该功能面向所有人开放。我们提供了工具，以便我们逐步向一定比例的用户推出该功能。在此期间，我们会持续
密切监控。如果发现严重问题，我们可以随时关闭该功能，修复问题后再继续推出。

原则

以上只是对我们工作方式的一个概括，具体细节会因项目而异。但我认为我可以提炼出几个重点。

• 首先定义 MVP。回顾并缩减范围，直到真正感觉最小化。
• 软件永无止境。我们乐意交付不完美的产品。我们随时可以提交新的 PR 来改进它。
• 始终保持畅通。让大家能够随时轻松贡献（即使身处不同时区）。
• 项目计划从最基本的开始，随着代码的交付而不断完善。尽早邀请其他人提供反馈，并在项目进展过程中将其纳入计划。

一些要点

• 您需要能够快速部署和回滚（如果您每周仅部署几次，则效果不佳）
• 你需要功能标志来控制代码并仅发送给特定用户
• 这是我曾经工作过的团队工作方式的一般示例（GitHub 是一家大公司，各个团队都会选择最适合自己的方式）
• 我是一名工程师，这是一个以工程为中心的流程视图