The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
除了作为一名动手编程者外，我还是Zerocracy的联合创始人和首席技术官，这是一家定制软件开发公司。在我们合作的所有项目中，我扮演技术和管理领导者的角色。
我为那些对雇用我和/或我的团队感兴趣的人编写了这篇文章。当你选择与我们合作时，本文将展示从第一天到项目结束的整个过程。
您将会看到，在下面，我们的软件开发方法与许多其他团队使用的方法有着显著的不同。我个人非常注重代码质量和连接我们团队的内部流程的质量。
在我与Zerocracy合作的每个项目中，有四个阶段。
思考。在这里，我们试图理解：产品将解决的问题是什么？我们还在调查产品的边界—谁将与软件一起工作（角色）以及他们将如何使用它（用户故事）。交付成果：规格说明。持续时间：从2天到3周不等。参与者：产品负责人、分析师、架构师、项目经理。
构建。在这里，软件架构师正在创建一个概念验证（也称为MVP或原型或骨架）。这是一个单人的工作，几乎没有与其他人交互。架构师根据规范在非常有限的时间内构建产品。结果将有多个错误和未完成的部分，但将实现主要的用户故事。架构师还配置了持续集成和交付流水线。可交付成果：可工作的软件。持续时间：2-5天。参与者：架构师。
修复。在这个阶段，我们正在给骨架添加所有的内容。这个阶段占用了大部分的时间和预算，并涉及许多参与者。在某些项目中，我们邀请多达50人同时工作。由于我们将所有的不一致之处都视为错误，所以这个阶段主要是为了找出、报告和修复错误，以稳定产品并使其准备好上市。我们每天增量发布软件多次，最好是向其用户冠军。交付内容：通过拉取请求进行错误修复。持续时间：从几周到几个月。参与者：程序员，设计师，测试人员，代码评审员，架构师，项目经理。
使用。在这个最后阶段，我们将产品推向最终用户，并收集他们的反馈（包括正面和负面）。他们向我们报告的一切都被登记为错误。然后，我们对这些错误进行分类并修复。这个阶段可能需要几年时间，但从不涉及新功能的主动实施。可交付成果：通过拉取请求修复错误。持续时间：几个月。参与者：程序员、代码审核员、项目经理。
最大（即最长和最昂贵）的阶段当然是修复。它通常需要大部分时间（超过70%）。然而，最重要和最具风险的阶段是第一个阶段——思考。在思考阶段犯的错误会比后面的阶段犯的错误要花费更多。
Thinking
思考是第一个也是最重要的阶段。
首先，我们为项目命名并创建一个 GitHub 存储库。我们尽量将所有的项目（包括开源和商业项目）都放在 GitHub 上。主要是因为这个平台非常流行、功能强大，并且价格非常便宜（$7/月 可以拥有 5 个私有项目）。我们还在 GitHub 的问题跟踪器上进行所有的沟通。
然后，我们创建一个简单的半页式SRS文件（软件需求规范）。通常这是直接在源代码中完成的，但有时也会在GitHub的README.md文件中完成。重要的是，该文档应该受版本控制。在项目进行过程中，我们会对其进行非常密集的修改。README.md应该简要地标识系统的主要“参与者”并定义产品范围。
尽管只有半页纸，但这个初始SRS文档的创建是整个项目中最重要且最昂贵的任务。我们非常重视这一步骤。通常，这个文档由我们的系统分析员之一与项目发起人进行直接沟通而编写。我们不能在这一步骤中犯任何错误。
然后，我们邀请了几位新的系统分析师加入项目。这些人负责将我们最初的 README 转化为一个更完整和详细的规范。他们首先提出问题，逐个将其作为 GitHub 问题提交。每个问题都是针对产品负责人的。系统分析师根据他/她的回答修改 README 文档。有时我们使用 Requs。
在思考阶段的最后，我们估计项目的规模，以代码行数（Hits of Code）为单位。使用这个代码行数指标，我们可以大致地估计预算。
Building
这是建筑师的个人工作。我们参与的每个项目都有一位建筑师，他个人负责质量和技术决策。我们有几位出色的工程师担任这个角色。
建筑阶段相对来说比较简单。建筑师必须根据README中的说明，在几个工作日内实施解决方案。无论想法有多么宏大，规划开发有多么庞大，建筑师仍然必须在，比如，三天内从零开始创建产品。
除了构建软件本身之外，架构师还必须配置所有基本的DevOps流程，包括：1）自动化测试和质量控制，2）部署和发布流水线，3）构件库，4）持续集成服务等等。
这个阶段的结果是一个可部署到目标环境并可供测试人员使用的可工作软件包。在这个阶段还会定义技术质量要求。
关于构建阶段的更多信息，请点击这里：开始软件项目的九个步骤
Fixing
现在是建立一个分布式程序员团队的时候了。首先，我们邀请那些在其他项目中工作过并且已经证明了他们的质量的人。很多时候，我们会邀请新的人员，通过Stack Overflow、GitHub、Upwork和其他渠道找到他们。一个平均项目的团队规模是15-25名程序员。
在这个阶段，我们将任何不一致的地方都视为错误。如果文档中有不清楚的地方，或者有可以重构以提高可读性的部分，或者有可以改进以提高性能的函数——对我们来说，这些都是错误。我们欢迎项目中的错误。我们鼓励大家尽可能报告更多的错误。这是我们实现高质量的方式。
这就是为什么这个阶段被称为修复阶段。我们报告错误并修复它们。成百上千的错误。有时候是成千上万。产品在我们眼前不断发展，因为每次修复错误后，我们都会重新部署整个产品到生产平台上。
每个错误都会被报告、分类、讨论并在其自己的GitHub工单和Git分支中进行修复。我们绝不允许任何人直接提交到master分支—所有更改必须经过我们的质量控制，并由我们的合并机器人rultor.com合并到master分支。
还值得一提的是，与产品负责人和程序员之间的所有沟通都只通过GitHub问题进行。我们从不使用任何聊天工具、Skype、电子邮件或会议软件。我们只通过GitHub的工单和评论进行沟通。
Using
这是最后阶段，可能需要相当长的时间。到目前为止，产品已经准备好并推向市场。但我们仍然会收到产品所有者的错误报告和功能请求，我们仍然会通过与修复阶段相同的流程来修复它们。
我们尽量保持这个阶段的安静，就报告和修复的错误数量而言。多亏了我们在之前阶段积极主动地找出和修复了Bug，通常在使用阶段我们很少遇到问题。
而大型功能请求呢？在这个阶段，我们通常会尝试将它们转化为新的项目，并单独开发它们，从头再开始思考。
顺便说一下，您在上面看到的插图是由Bárbara Lopes创作的。
Translated by ChatGPT gpt-3.5-turbo/35 on 2023-09-06 at 19:36
