本文是一篇翻译文章，内容主要是围绕创业公司的快速开发提出了一些可行的方法和建议。
创业公司如何实现快速开发
在一个公司的任何阶段，能够快速开发产品都是一个巨大的优势。作为公司的创始人来说，你总是想要把所有的事情做好，以此来发展客户公司合服务你的客户。
在过去的几年中，我有幸与许多建立不到 4 年的公司合作，我发现这些公司都有同样的问题，那就是复杂并且拖拉的软件开发合交付过程。积极性是快速开发的一个必不可少的条件，但是这篇文章，我们将专注于整个过程和实现它的具体步骤上。
在我们进入快速开发产品的过程之前，我想说的一件事是：如非必须，请不要自己建造轮子，尽量使用能满足需求的第三方工具或服务，这是一个不错的策略。
一、避免特性分支
在深入讨论高效流程的细节之前，我想先提一个很多公司经常使用的流程，它通常会在很大程度上降低产品的交付效率，这个流程就是特性分支。开发人员在开发一个新的功能时，会单独创建一个新的分支来开发新功能，等到新功能开发完了再将其与主分支合并。
开发一个新功能通常需要几周甚至几个月的时间，所以也因此而造成了下面这些问题：
- 新功能开发完成后，需要大量时间来处理代码合并。
- 代码合并后很可能会导致新的 bug，增加不稳定性。
- 不利于增量重构。
这种开发方式在小团队可能还比较适用，但是当团队中合作的工程师超过 5 位以上时，效率就开始变低了。如果你的团队使用这种方法，将会给你的交付效率造成很大的影响。无论如何都应该避免。
二、自动化 CI/CD 流水线
我希望每个初创公司都使用”持续集成和持续部署“ —— 即构建-测试-发布流程的自动化。说简单点就是，每当开发人员发布代码时，自动化流程能感知并获取最新的代码并将它编译、打包、部署到模拟环境和生产环境中。
10 年前，Jenkins 和 TeamCity 是实现 CI/CD 的不二选择，它们需要大量的配置，但是在自动化方面做的很好。
7 年前，类似 Drone CI 和 Circle CI 这种使用 docker 构建和测试产品的工具开始流行起来。
3 年前，GitHub Actions 变得非常流行。它们也使用 docker 镜像，但是它们还集成了版本控制系统，并且允许你创建非常复杂的 CI/CD 流水线。
在过去的两年中，像 Vercel 和 Render 这样的非常简单并且集成度很高的工具开始出现。这些工具自带了预先构建好的 CI/CD 流水线，开箱即用，非常方便：
- 开发人员将代码推送到主分支。
- 代码变动自动被更新到生产环境中去。
它们还经常自动化执行一些常规的 DevOps 任务，比如环境变量管理、SSL 证书以及基本扩展。
事实上，使用什么工具并不重要 —— 最重要的以及迈向快速交付的第一步是完全自动化的 CI/CD。这将会为你节省大量手动部署的时间，并且让你可以在一天中实现多次部署。
三、使用 monorepo
monorepo(单仓库多项目架构)让事情变得简单、有条理和透明 —— 在这里你可以看到正在发生的事。拥有多个仓库，可以使用不同的方法来构建和部署你的产品，特别是当你的团队开始成长时。
monorepo 有以下优点：
- 所有代码可见，并且单一的源码。
- 单个仓库下代码共享比较容易(有一些像 Turborepo 的工具，可以使之更简单)。
- 单你需要查找一些代码或变量等，在单个仓库下会更容易查找。
- 可以更简单的构建 CI/CD 流程，因为所有代码都在一个仓库里面。
将功能分解为更小的、增量的变化
小的、增量的变化是快速开发产品的关键。通过较小的更改，团队会倾向于应用更好的软件开发实践。即使是很小的改动也需要经过测试，以确保没有引入任何 bug,旧的功能依然按预期工作。
以下是为什么增量变化如此重要的三个主要原因：
- 更快的反馈(如果方向错误，这一点尤其重要)。
- 代码冲突更少，更易于代码合并。
- 降低了系统中大模块出问题的概率。
小的迭代可以提高团队的效率和质量。通常，你可以对工程师和产品团队使用两个简单的规划：
- 对于产品团队：任何任务都不应超过 3 天，平均 1-2 天。
- 对于工程师团队：每个工程师都应该确保每 2 天 pull 一次代码，每天提交一次代码。
这些规范培养了团队每个成员的迭代思维。产品团队需要考量和设计更小的功能迭代。工程师团队需要经常合并他们的变更，并且要考虑如何合并甚至是没有完成的特性。特性标识有利于解决这个问题。
使用特性标识
特性标识(也称为特性切换)是一种允许您在不编写代码的情况下更改产品功能的技术。工程师创建特性标识，并通过某种方式像产品和数据团队公开它们。
特性标识带来的影响团队绩效的两个关键过程变化是：
- 工程师可以发布部分完成的特性，因此这些变动可以经常被审查和合并。
- 产品团队可以在早期进行评审并提供反馈。
这里有一个关于为什么特性标识很重要的更深入的回顾，我们使用Growthflags来实现特性标识。
指定负责人
指定一个小团队负责建每个功能特性交付到产品中，可以提高开发速度和质量。通常，这个团队由负责产品的人和来自工程师团队的人组成。他们的目标是部署每一个功能特性 —— 他们不受任何人的决定的阻碍并且他们应该要解决所有的阻碍。他们会设定一个截止日期，并努力在此之前发布新的功能特性。
清晰的划分各自责任的一些建议：
- 避免共同责任陷阱。即没有人对某件事负责，工作也没有完成。
- 激发个人责任感。功能的负责人很清楚没有人会替他们完成他们的工作。
实行责任人规则可以像创建一个包含功能名称、开发负责人、产品负责人和发布日期的电子表格一样简单。在 concept 或者 Jira 等工具中，你可以添加自定义列以达到这个目的。
使用 Sprint/产品规划来定义功能的归属关系。通常情况下，我们每个月都会有一个产品规划，以便于回顾上个月的进展，设定眼下的目标，分配任务给每个责任人，以及确定所有功能的截止日期。
在 Sprint 规划期间，我们通常要花较多时间来拆分功能，尽可能分解成最小的需求。
每周至少一次演示
一旦你为每个功能指定了负责人，你应该定义一个明确的流程来记录和演示。演示可以让团队成员像用户一样来思考问题，帮助我们在功能上线之前乃至在测试之前发现一些问题。
如果你的团队在不同的时区工作，那么离线演示可以随时为您提供及时反馈。早期的演示甚至还可以作为 QA(测试)文档、帮助文档或者其他团队文档。分享早期演示并获得一些反馈可以极大的提高产品的质量和交付效率，因为你减少了迭代次数。(演示可以提前发现问题修复问题避免绕更多弯路，确保大方向的正确性)
通常情况下，应该要求团队在一下阶段提供演示：
- 原型演示：早期的设计演示，多数情况是 UI，也会有些数据结构、接口设计等。通常会调整功能的方向。
- 预览演示：当功能开发的差不多了，只是还需要修缮，一般在提测前。
- Beta 演示：功能进入 Beta 测试阶段，可以在测试环境中使用对应的功能。
- 预发布演示：即功能即将发布到生产环境之前的最后一次演示。
经验之谈是每个致力于特定功能的团队每周都应该提供 1-2 个演示。
每周部署
使用自动化 CI/CD 流水线，部署项目就像切换分支一样简单。但事实上，它也是有相关的风险的：
- 数据库迁移失败或者迁移缓慢。
- 新功能在生产环境可能无法按预期的工作。
- 应用会变得很慢，影响用户体验。
这个清单还可以写很多，但中心思想是，即使是完全自动化的部署也应该有人来监督。发布变更的人应该在发布后多检查几次，以确保情况良好。
对于更大的公司来说，每周进行多次部署可能是一个简单的指标。但对于初创公司来说，最好坚持在预定的时间每周部署一次。
你会发现：
- 与日常部署相比，生产失败的风险降低了。
- 节省了大量时间，以便用于开发新的功能。
- 有规律的部署项目，让营销、运维和其他工作变得容易协调。
- 给你做手动测试的时间。
使用 Vercel 和 Render 这样的工具，部署过程可以像这样简单：
- 将开发分支的变动部署到测试环境。
- 将主分支的变动部署到生产环境。
- 开发分支每周合并一次到主分支，以进行生产部署，其他更改则总是合并到开发分支。
冻结要发布的代码
这不是为了提高速度，而是为了使质量得到保证。对于我们的产品来说，测试工程师会在产品发布到生产环境之前对功能进行验证。通常情况下，团队至少应该在部署前一天停止合并可能影响生产版本的更改。
这将为测试人员提高宝贵的时间来审查新的功能变动，并确保它们能按预期工作。大多数情况下，我们只是把合并新更改的工作暂停一天。
编写单元测试
写单元测试是一个提升能力的好方法，可以让你对自己的代码更加自信。从长远来看，增加团队编写的单元测试数量将对软件的质量产生积极的影响。这可以帮助团队从每周部署一次变成两次甚至更多。
单元测试减轻了测试团队的压力，因为他们可以更多的专注于测试边缘用例和复杂场景，而不是测试应用的基本功能，如登录或注册。当你在系统中进行大的改动时，单元测试可以确保系统更加安全以发布新的改动。
总结
那么，总结一下能够提高快速发布快速交付的流程：
自动化 CI/CD 流水线。节省大量手动发布时间并允许一天多次发布等。
使用单仓库架构。可以使你的项目保持清晰明了、整齐有序并且透明。
把功能特性尽可能分解到最小的增量的变动。可以确保得到及时的反馈，减少大方向的失误。
- 产品团队应该把工作分成 1-2 天的任务。
- 开发团队应该没天推送变更。
使用功能标志。
- 开发团队不畏惧部署。
- 你可以向 beta 用户推出新功能。
- 你可以更快的从团队和外部用户那里获得反馈。
- 你可以运行 a/b 测试和执行试验。
为每个功能特性指派产品和开发负责人。
- 避免共担责任和交付延期。
- 提升个人责任感激发团队潜力。
每周至少要求一次演示。鼓励团队尽早分享工作进度，提前发现 bug，便于在错误的路上走得更远。
- 原型-预览-测试-预发布 —— 这是每个团队应该提供的流程演示。
- 每个功能团队每周应该提供 1-2 个演示。
每周部署并遵循简单的 CI/CD 流程。
- 使用单一开发分支，每次提交时部署到测试环境。
- 每周将开发分支合并到主分支，以便部署到生产环境。
发版前进行封版。
- 避免发生影响版本发布的改动，便于测试团队对该版本的功能进行测试并确保质量。
如果你刚刚开始，不要写太多单元测试。
- 从长远来看，单元测试是很好的，但是在短期内会降低开发效率。
英文原文地址 :