⛄️ 🐢 👰🏻 自我隔离条件下的分布式团队的工作：因为我们几乎没有注意到差异 👨🏾‍🚀 🆖 🙍🏾

自我隔离模式迫使许多人在家工作。对某人来说更容易，一个人更难，甚至根本不会注意到它们之间的差异，但是在隔离周（然后是月份）宣布宣布之后，关于提要的信息，生活中的骇客，效率和生产率的增长显着增加。

我叫Mikhail Troshev，我是Yandex搜索界面服务的负责人。我们的团队一直在分布式基础上工作多年-我将在下面告诉您它的区别，它与“远程”的相似之处，如何组织，为何不中断以及我们的经验如何对那些突然因工作方式改变而突然采取工作的人有用。

某些东西似乎对您来说太平庸了（敏捷，Scrum，看板，DevOps-哇！），但这就像在早晨充电：每个人都知道它是有用的，但是出于某种原因，懒惰是定期进行的，并且全力以赴。所以：我们做。而且有效。

不是远程的，而是分布式的

外观：每天有90家前端供应商聚集在莫斯科，圣彼得堡，喀山，Innopolis，叶卡捷琳堡，辛菲罗波尔和明斯克的办公室-很容易注意到，我们不仅被距离隔开，而且被时区隔开。但是，这还不是全部：前端分销商分布在大约三到七个+后端的产品团队（虚拟团队），设计师，测试人员和经理之间（在2019年，他在这里详细介绍了我们的工作结构）。也就是说，一个这样的团队的几乎所有成员都在不同的城市。距离不是很远，但是非常接近：尽管仍然有几个同事在附近，但是与在露天场所工作相比，与其他人进行微同步的可能性非常有限。

必须使用响应时间长的异步通信。团队分散在不同办公室之间的能力越强，则在日常工作互动中，任何项目可以掩埋的等待开销就越大。为了节省时间：

-从构思到生产的每个任务的生命周期都尽可能一致地安排：程序，状态，阶段之间的过渡-一切可能的事情都已形式化（约占任务的90％）。同时，我们试图使官僚机构简单易懂，否则便不再有用，而开始干涉。

-整个团队都知道管理工作流程的规则，并正在努力明确遵循这些规则；我们尝试使例程自动化。因此，每个人都忙于自己的生意，而不会浪费时间做出相同的微决定：程序员程序，程序经理想出功能，设计师设计。

没什么新鲜的吧？但是，这种简单的方法在自我隔离的条件下为我们提供了很多帮助：每个员工都可以充分利用自己的利益，因为他们知道足以胜任工作的细节。

但是首先是第一件事。

阶段0。计划

每个团队都有一个待办事项列表，其最高优先级是：

基本要点是每个团队成员都必须理解：必须完成此任务，因为它与史诗相关，史诗与目标相关，并且目标很重要。否则，要么有人开始做不需要的事情，要么经理被迫不断监视并扑灭大火。顺便说一句，后者在办公室可能很难被注意到，但是不可能在遥远的地方错过它：存在很多混乱，工作正在进行中，使者中有十二个聊天室开始尝试进行同步-结果，整个团队都在聊天，而不是编写代码。在团队中组织计划至关重要，以便流程中的每个参与者都了解他需要做什么以及按照什么顺序进行。这样，团队负责人将能够专注于产品，而不会因不断出现的小问题而分心。

当然，不可能将整个待办事项详细列出到底部，但是对顶部的高质量研究可以使您快速地在sprint中招聘新任务-几乎所有团队都生活在两周的sprint中，并为下一个任务保留一个储备。使用这种方法，即使突然没有人来访，经验丰富的团队也可以在没有经理的情况下键入sprint。

为了不延长工作时间，团队采用了``有用的官僚作风''：经理制定清晰的描述，表演者放下正确的状态，任务从左到右在sprint板上``流动''：

这里整个团队都可以看到sprint的全部和当前情况。如果某人生病，上班或度假，其他参与者会立即以当前状态接管任务。

嗯，当流程的正式组织不足以解决某些特定案件，并且官僚机构更可能干扰流程时，又怎能没有每日同步呢？通常按状态详细说明任务（打开>进行中>审阅中>准备测试>测试>已测试>准备好开发> dev> rc>关闭），但是在10％的情况下，您需要澄清一些内容，用语言说出来，解释“在手指上”。顺便说一句，我坚信所有工作会议（包括站立会议）都必须使用视频通信进行，而不仅仅是通过语音进行，因为这会迫使人们整顿工作并参与工作。

整个团队都必须出席同步会议，这一点非常重要：他们在董事会的指导下迅速检查了上下文，整理了任务并开始工作，而又不浪费彼此的时间。当然，我们也有可进行的聊天，但我们尽量不要淹没它们，并使用它们来获得快速（理想的二进制）答案：是否可以滚动发行版，在哪里找到说明以及与谁讨论数据源API。

赢得时间的地方：同步，微决策

第一阶段：开发：开放>进行中

“打开”-任务正在等待表演者。开发人员选择它们，以便尽快准备好它们。例如，碰巧是在院子里的星期五，而开发商在下周开始值班（这是一个月的提前通知）。在这种情况下，最好让他完成一项小任务以在一天之内完成该任务：我们尽量不转移开始的任务。如果某人没有时间完成工作，最好按原样倒入，然后通过单独的合并请求结束遗体。

我部署了项目的本地工作副本-不要忘记将任务从“打开”转移到“进行中”，以便其他人不会接手。顺便说一句，“本地”是一个关键字-您可以在任何地方工作，互联网连接的质量不会成为阻碍因素。现在，基础架构和网络已超负荷运行，这一点非常重要。我们的本地开发服务器允许您使用数据转储-包含各种请求数据的zip存档，因此您完全可以在没有Internet的情况下工作。开发人员完成工作并发送池请求后，将打开自动化功能。

在获得时间的地方：对优势和能力进行独立评估，并不一定总是需要克服不稳定的Internet连接

第2阶段。自动检查：进行中>审核中

在任务进行审查之前，它会通过代码质量，性能，缺少视觉和功能错误的检查。在这里，我们可以写很多关于我们自动检查的完整性和多样性的信息，但是，首先，它借鉴了几个独立的故事，其次，它远远超出了所讨论的主题。我将提供指向这些工具的描述的链接：

-静态分析的标准工具集：带有丰富插件的ESLint和Stylelint；
-我们自己的静态检查：翻译的可用性和质量，yaml文件的验证；
-单元测试的标准工具：Mocha，Karma，PhantomJS，伊斯坦布尔 ;
我们自己的功能和视觉测试工具Hermione；
-脉冲-用于性能测试-也是我们自己的。他们在这里提到他。

顺便说一句，如果在任何阶段出现问题，该任务都将回滚到此处-不幸的是，即使是最仔细的计划也不能将100％的错误保存下来，否则可能会出错。如果他在任务中找到合适的人，他将描述问题的实质，上传屏幕截图甚至是视频，他还可以向聊天记录添加命令，以便每个人都可以注意到任务已停止。无论是什么-测试期间发现的错误，设计已更改，后端没有足够的数据。

: — , - —

3. -: in review > ready for test

首先，我不仅希望提供免费的审阅者，而且还要求了解您的代码中发生了什么的人。其次，来自相邻的团队，以便整个服务部门都知道谁在做什么-这是我们的法规中阐明的所有内容。即使在小型办公室中，手动组织它也很困难且很耗时，更不用说分发（和自我隔离了！）。自动化的代码检查器可以帮助您：她还可以自行更改状态。我不会详细介绍它是如何工作的，我不会-最好听听开发人员的故事。她还知道如何对表演者执行ping操作：任务在评论中的挂起时间越长，则ping操作越剧烈。

您赢得时间的地方：搜索相关的审阅者，提醒您处理池请求

第4阶段。测试：测试>已测试

更改通过代码审查后，请运行自动测试。只有当它们全部变为绿色后，任务才会转移到手动测试。重要的是，对于该任务，在将其明确传递给其他人之前，执行者始终是负责任的–正是他应该迅速将其代码拖入代码审查和测试中，直至投入生产。也就是说，我们总是知道谁是极端的，每个人都不仅在监视他们的任务，而且还在监视团队中发生的一切。团队中的测试人员通常是一个人，这对他来说也很方便：他看到自己将下一个飞行，他可以更有效地利用自己的时间。

测试人员可以：

-将测试任务交给评估员- 包含所有详细信息的帖子。由于评估人员进行了测试，因此可能需要进行研究测试或重新检查；
-在实时设备上或使用具有远程访问权限的设备场中自己测试任务-集体场。

实时设备位于每个Yandex办公室的Hypercubes中。在使用免费设备选择最近的地点之后，任何员工都可以使用具有必要特性的设备。通常，过一会儿，系统会自动提醒您该返回设备了，但是此功能在自我隔离时被禁用。值班小组确保那些急需它的人需要生活用具，并且其他所有人（为了不减慢工作流程）有助于连接集体农场。

集合服务器场是任何人都可以使用的远程测试设备场。Android，iOS-我们甚至在支持的最旧，最困难的系统版本上检查更改，以便任何人都可以使用我们的服务。但是我们也正在尝试尽快在Collective Farm和Hypercubes中获得旗舰产品。还记得第九部iPhone上出现的“窗帘”（它是“单眉”）以及与之相关的所有问题吗？

节省时间的地方：计划，自动测试，设备分发：甚至可以进行自我隔离

阶段5.注入：准备就绪> dev

该任务已经过测试-是时候将其倒入一个公共分支了。

N.B. , master trunk, dev. . trunk.

当有大量注入时（例如，我们每天有30个以上注入的池请求），会出现两个问题：

- 次要的：git中的历史记录，如果您随机加入并且不重新设置基准，它将变得非常混乱，并且如果存在某种错误，回滚非常困难；

- 关键：集成测试。在物理上并不总是可以等到测试结束后再与最新版本的中继线一起等待，因此可能会发生以下情况：注入后，两个池请求（每个请求不会单独破坏任何内容）会破坏中继线。为了防止这种情况，我们坚持基于Trunk的开发，即可以从任何提交中推出发布。尽管我们尚未最终实现持续部署，但我们的主干是“绿色的”。绝对每周一次收支平衡是我们绝对不可接受的。

几年来，我们一直在使用“合并队列”工具来自动化队列，并不断对其进行改进。更改不是由开发人员而是由机器人进行的。在每个池请求中，它都会根据最新版本的中继线进行基准调整，并运行全套测试。这是一个相当漫长的过程，因此不可能将它建立在有生命的人身上-一个人根本不会等待最终结果。而且，该机器人无需睡眠，休息和休息即可工作。此外，开发人员自己可能不会将任务放在队列中，而是在测试结束后立即由测试人员将其放在队列中，这又可以节省时间。

更多细节关于合并队列。

节省时间的地方：我们防止阻塞故障，您无需手动控制池请求的注入

第6阶段。发布：rc>已关闭

从主干中的最后一次提交开始，每个工作日凌晨5点，我们都会自动获得一个新版本：静态和动态包的组装，预稳定的计算，评估人员的测试。接下来，值班测试人员将检查报告，如果有错误，则报告有关此问题的待命开发人员。如果一切顺利，则将其传递给值班经理。如果他同意，那么值班的开发人员就会推出该发行版。

需要说明的是，不同团队的任务应包含在发布中，因此，当一个待命的开发人员被明确分配给发布时，这对每个人都是有益的，而开发人员整周都在滚动发布和监视错误监视方面进行工作。这使其他项目开发人员可以尽早切换到新任务（实际上是在发送到Merge Queue之后立即切换）。

通常，所有发布活动都是在工作时间进行的（即使是在家里，我们也会要求所有人遵守该制度-因此，每个人都会朝不同的方向打破它，但我们不会停止尝试），但是如果生产中出现问题，那么值班将唤醒开发人员的职责，他迅速回应。

我提醒您，主要任务是减少团队成员彼此同步的时间和日常工作量：每个人都知道谁在值班。每个人都知道该做什么和如何做，每个人都有说明。当经理允许发布该发行版时，他将不向开发人员解释该过程，开发人员知道一切并且知道如何进行。

赢得时间的地方：同步，做出微决定
。

分布式工作可以预防不良，效率低下的流程，这些流程即使在通常情况下也会抑制项目，更不用说非标准项目了。我们团队的经验证实，如果您由于乏味而沉迷于设置程序和交互，并诚实地遵守所有规则，那么不管它们看起来多么普遍，工作流程都将很难瘫痪。

让人想起交通管理：当汽车很少且行驶缓慢时，很少有人想到交通规则。现在有很多汽车，而且速度很快-没有规则的移动变得不可能。这些规则制定得越好（同时越简单），交通参与者就越充分地履行它们，道路的通行能力就越高。

感谢您阅读到最后。在评论中见！

自我隔离条件下的分布式团队的工作：因为我们几乎没有注意到差异