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-5天。参与者：架构师。
修复。在这个阶段，我们正在为骨架添加所有的内容。这个阶段占用了大部分的时间和预算，并涉及到许多参与者。在某些项目中，我们会同时邀请多达50人进行工作。由于我们将所有的不一致性都视为漏洞，所以这个阶段主要是关于发现、报告和修复漏洞，以稳定产品并为市场推出做好准备。我们每天增量发布软件多次，最好是给用户冠军。可交付成果：通过拉取请求进行漏洞修复。持续时间：几周到几个月。参与者：程序员（们），设计师（们），测试员（们），代码审查员（们），架构师，项目经理。
使用。在这个最后阶段，我们将产品推向最终用户，并收集他们的反馈（包括积极和消极的反馈）。他们向我们报告的一切都会被记录为一个错误。然后，我们对这些错误进行分类并进行修复。这个阶段可能需要几年的时间，但不涉及新功能的主动实施。可交付成果：通过拉取请求进行错误修复。持续时间：几个月。参与者：程序员，代码审查员，项目经理。
最大的阶段（即最长时间和最昂贵的）当然是修复阶段。通常需要占用大部分时间（超过70%）。然而，最重要且具有风险的阶段是第一个阶段——思考。在思考阶段犯下的错误比之后犯下的错误要代价更高。
思考是第一阶段，也是最重要的阶段。
首先，我们给项目起一个名字，并创建一个Github仓库。我们尽量将所有的项目（包括开源和商业项目）都放在Github上。主要是因为这个平台非常受欢迎、功能强大，而且价格非常便宜（每月7美元，可以有5个私有项目）。我们也将所有的沟通都放在Github的问题跟踪器中。
然后，我们创建一个简单的半页SRS文档（软件需求规格说明书）。通常这个文档会直接写在源代码中，但有时会写在Github的README.md文件中。重要的是，这个文档应该受到版本控制。我们会在项目过程中对其进行非常密集的修改。README.md应该简要地识别系统的主要”参与者”并定义产品范围。
尽管这只是半页纸，但创建这个初始的SRS文档是整个项目中最重要、最昂贵的任务。我们非常重视这一步。通常这个文档由我们的系统分析员之一与项目发起者直接沟通写成。在这一步我们不能犯错。
然后，我们邀请一些新的系统分析员加入项目。他们负责将我们的初始README转化为更完整、更详细的规范。他们会开始提问，并逐个将问题提交为Github的问题。每个问题都会寄给产品负责人。根据他/她的回答，系统分析员会修改README文档。有时我们会使用Requs。
在思考阶段结束时，我们会估计项目的大小，以代码行数（Hits of Code）来衡量。使用这个HoC指标，我们可以大致估算预算。
这是一个建筑师的独自工作。我们参与的每个项目都有一个负责质量和技术决策的建筑师。我们有几位出色的工程师担任这个职位。
建筑阶段相当直截了当。建筑师必须按照“README”中的解决方案在几个工作日内实施。无论想法有多大，规划开发有多庞大，建筑师仍然必须在三天内从头开始创建产品。
除了构建软件本身之外，建筑师还必须配置所有基本的DevOps流程，包括：1）自动化测试和质量控制，2）部署和发布流水线，3）工件仓库，4）持续集成服务等。
这个阶段的结果是一个可部署到目标位置并可供测试人员使用的工作软件包。技术质量要求也在这个阶段定义。
关于建筑阶段的更多信息，请参阅：开始软件项目的九个步骤。
现在是建立一个分布式程序员团队的时候了。首先，我们邀请那些在其他项目上工作过并且已经证明了他们的质量的人。我们经常通过Stack Overflow、GitHub、Upwork和其他渠道找到新人。一个普通项目的平均团队规模是15-25个程序员。
在这个阶段，我们把任何不一致的地方都视为bug。如果文档中有不清楚的地方，或者有些代码可以重构以提高可读性，或者某个函数可以改进以提高性能——对我们来说，这都是bug。我们欢迎项目中的bug。我们鼓励每个人尽可能多地报告bug。这是我们实现高质量的方式。
这就是为什么这个阶段被称为修复阶段。我们报告bug并修复它们。成百上千的bug。有时候甚至成千上万。产品在我们眼前成长，因为每次修复一个bug后，我们都会重新部署整个产品到生产平台。
每个bug都会被报告、分类、讨论和在它自己的GitHub工单和Git分支中修复。我们从不允许任何人直接提交到master分支——所有的修改都必须通过我们的质量控制，并由我们的合并机器人rultor.com合并到master分支中。
还需要重要提及的是，与产品负责人和程序员之间的所有沟通都只通过GitHub工单进行。我们从不使用任何聊天工具、Skype、电子邮件或会议软件。我们只通过GitHub工单和评论进行沟通。
这是最后一个阶段，可能需要相当长的时间。现在，产品已经准备好并上市了。但是我们仍然会收到产品所有者的错误报告和功能请求，并且我们仍然通过与修复阶段相同的流程来修复它们。
我们尽量使这个阶段的错误报告和修复工作尽量少。由于在之前的阶段中进行了密集和积极的错误查找和修复，我们通常在使用阶段遇到的问题很少。
至于大型功能请求？在这个阶段，我们通常会尝试将它们转化为新的项目，并单独开发它们，从头开始思考。
顺便说一下，您在上面看到的插图是由Bárbara Lopes制作的。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-28 at 15:49
