在本文中，我想分享我如何解决公司“冻结”任务问题的经验。
我在一家初创公司工作，与所有初创公司一样，它正经历从一年前的10人发展到如今的35人的增长阶段，这段时间程序员的数量已从5人增加到25人，其中大多数是过去六个月来的。
尽管公司还很年轻，但我的组织结构还是老式的，因为没有人参与过构建过程。 随着增长，我们分成了开发团队，测试团队和开发团队，一切都或多或少地起作用。
开发过程（如果可以称为“过程”）是这样的：
一旦代码通过代码审查，开发人员的工作就结束了，他在开发中将其抵押。
当他在master分支中进行测试和smerzhil时，测试人员的工作结束了。
在日常项目经理说：“他们已经很长时间没有部署了，也许我们今天将被取消吗？”之后，Devops有时会单击“部署到产品”按钮。
有什么好处：
- 许多自动化操作，例如Jira中的状态与GitLab中的分支标签同步，Jira中的任务在部署到产品后关闭，代码分别自动部署到测试和登台环境中，并分别合并到开发和主环境中。
- 测试覆盖了一切。
- 程序员自己编写测试计划并测试主要功能。
问题：
- 测试人员一周不能做任何事情，因为 任务挂在状态code_review中。 在本周末，程序员仍然会进行此检查，并且星期一测试人员会做很多工作。
- 由于代码审查后，所有问题都已在开发中修复，并且如果其中包含错误，那么我们将无法部署任何东西。 当一个开发人员修复此错误时，另一位开发人员可能会发现另一个包含该错误的功能。 因此，我们过去通常需要等待一到两周，直到这种早午餐稳定下来，并且测试人员有时间将其掌握在开发人员中，然后再由一名开发人员提交其他开发内容。
- 大型捆绑包中的部署功能会增加在部署过程中测试或捕获某些东西的风险。
我将描述两个案例，这些案例使我们明白，不可能进一步开展工作。
因此，例如，在星期五的一个星期五，我们的状态code_review有15个早午餐，而在星期一，它们都将状态更改为ready_for_test。 测试人员告诉《日报》，他们有多爱我们。 由于种种原因，三个月以来我们最终都无法销售一些相当大的功能。
首先，我们找出了很多code_review。 事实证明，由于以下规则，可以非常简单地解决此问题：
- 只能有三个任务处于code_review状态。 这是不可违反的最重要的规则。
- 如果程序员已完成开发并希望将任务转换为code_review，则将查看是否可以执行该任务（请参见规则1）。
- 如果状态为code_review的任务已经存在三个，则首先他帮助他的同事进行代码审查。 并且，如果在审查过程中他有意见或对变更的建议，那么他将与正在审查其任务的同事进行配对编程。
主要思想不是在编写代码后就冻结它，并为测试人员提供一周的均匀工作量。
我们在一小时内实现了这一点：我们聚在一起讨论并进行了结对编程。
如果碰巧有人忘记了（有时有人忘记了）第一条规则，那么短语“我们在code_review中拥有3个以上的PR”会立即进入聊天室。 让我们回顾一下!!!“。 同时，没有特别的人来确保不超过三个拉取请求，这是由开发人员自己完成的。
尽管这些更改使我们能够防止任务冻结，但在部署和开发中的错误泄漏方面仍然存在问题。 由于在进行代码审查之后，我们始终合并在development分支中，并且将其自动部署到测试环境中进行测试。
此解决方案是一种修补程序，因此有必要对流程进行基本更改。
我们决定要做的主要事情是移动责任范围。 现在，该公司没有一个单独的开发团队，测试团队或devop团队来相互转移任务，并且仅对他们的部分负责。
我们将开发人员分为几个小组：每个小组一个，因为我们有一个主要产品，但是很长一段时间都为每个顾客定制（我们是产品和服务公司的混合体）。 现在，将功能交付给产品是团队的责任。 没有熟悉的测试团队和开发人员，但是有QA服务和DevOps服务。
质量检查即服务是一个不进行测试但可以确保产品质量的团队。 质量检查工程师帮助开发人员编写测试计划并参加测试会议。 因此，我们将他们从手动测试中解放了出来，他们有时间编写端到端测试并开发有助于测试的工具。 我们还实施了监控系统。
DevOps即服务团队是一个团队，负责开发部署脚本，支持测试环境的工作并自动执行各种任务。
新的开发过程是这样的：
- 来自客户，产品经理或高层之一有一项任务。
- 在sprint计划阶段，我们将其开发。
- 开发人员将代码编写在该任务的单独分支中，完成后将其转换为状态code_review。
- 一位同事进行了审查。
- 任务通过审查后，开发人员将与所有致力于开发的任务合并到该分支中，并将该分支部署到测试环境中。
- 然后，他计划召开一次集会，我们称之为“测试会议”，并在必要时邀请质量检查工程师和同事参加。
- 质量检查工程师在测试会话之前检查并完善测试计划。
- 在测试会议上，开发人员将演示整个测试计划。 有时，测试计划会分成几部分，然后我们进行并行测试。 最主要的是，这是在单独的会议室中共同完成的。
- 如果在测试之后未发现错误，则开发人员会将其代码合并到developer分支中，然后立即合并到master分支中（由于我们仍然需要更新部署脚本，因此我们尚未更改）。 将来，我们计划仅离开master分支。
- 此后，开发人员将按阶段启动部署，只是要验证部署是否仍在与产品相同的环境中运行。
- 如果一切正常，请立即部署到产品。 是否部署是由开发团队决定的，但是如果QA认为有必要进行额外的测试，或者如果有必要在产品上修复一些严重的错误，则有必要停止部署。
有趣的是，这种转变引发了一些其他变化，这些变化不是在开发过程中，而是在计划中，并且改变了我们在《每日新闻》上谈论的主题。
现在，因为 开发人员负责将用户故事交付给产品，在计划时，我们开始以这样的方式编写用户故事：每个用户故事彼此独立，也可以独立部署（例如可部署单元）。 用户故事变大了，但是他们变小了。
同样在规划中，我们不评估开发时间，而是在计划何时部署功能。
在Daily上，我们不是说“我已经完成开发”，而是说“今天我要部署功能X”或“今天我要离开测试环境，谁有时间帮助我进行测试会议？”
因此，我们开发了独立的开发团队，他们拥有自己的测试环境并计划部署什么以及何时部署。