👐🏽 🙏🏻 👩🏽‍🍳 O trabalho de uma equipe distribuída em condições de auto-isolamento: como quase não percebemos a diferença 👿 👩🏻‍💼 🚸

O modo de auto-isolamento obrigou muitos a trabalhar em casa. É mais fácil para alguém, mais difícil, e alguém não teria notado a diferença, mas após o anúncio da semana de quarentena (e depois do mês), o crescimento de postagens sobre hackers, eficiência e produtividade no feed aumentou significativamente.

Meu nome é Mikhail Troshev, chefio o Serviço de Interface de Pesquisa Yandex. Nossa equipe trabalha em uma base distribuída há muitos anos - mostrarei abaixo como é diferente e como é "remotamente", como é organizada, por que não quebra e como nossa experiência pode ser útil para aqueles que foram repentinamente pegos de repente por uma mudança no modo operacional.

Algo certamente parecerá banal para você (Agile, Scrum, Kanban, DevOps - uau descobertas!), Mas é como cobrar pela manhã: todo mundo sabe que é útil, mas por algum motivo a preguiça é feita regularmente e com força total. Então: nós fazemos. E isso funciona.

Não remotamente, mas distribuído

Como é: 90 fornecedores de front-end se reúnem todos os dias nos escritórios de Moscou, São Petersburgo, Kazan, Innopolis, Ecaterimburgo, Simferopol e Minsk - é fácil perceber que estamos separados não apenas por distâncias, mas também por fusos horários. No entanto, isso não é tudo: os distribuidores front-end são distribuídos entre equipes de produtos (equipes virtuais) de cerca de três a sete + back-end, designers, testadores e gerentes (em 2019, ele falou detalhadamente sobre nossas estruturas de trabalho aqui ). Ou seja, quase todos os membros de uma dessas equipes estão em cidades diferentes. Não muito remoto, mas muito próximo disso: embora vários colegas ainda estejam por perto, as possibilidades de microssincronização com os outros são significativamente limitadas em comparação com o trabalho em espaço aberto.

É necessário usar a comunicação assíncrona com um longo atraso de reação. Quanto mais forte a equipe estiver dispersa entre diferentes escritórios, mais na interação diária de trabalho a sobrecarga de espera que qualquer projeto pode enterrar. Para economizar tempo:

- o ciclo de vida de cada tarefa, da idéia à produção, é organizado da maneira mais consistente possível: procedimentos, status, transição entre etapas - tudo o que é possível é formalizado (aproximadamente 90% das tarefas). Ao mesmo tempo, tentamos manter a burocracia simples e compreensível, caso contrário ela deixa de ser útil e começa a interferir;

- toda a equipe está ciente das regras que regem o processo de trabalho e está tentando segui-las claramente; Tentamos automatizar a rotina. Assim, todo mundo está ocupado com o seu próprio negócio e não perde tempo tomando as mesmas micro-decisões: programadores de programa, gerentes de programa apresentam recursos, design de designers.

Nada de novo, certo? No entanto, essa abordagem simples nos ajudou muito nas condições de auto-isolamento: cada funcionário pode trazer o máximo benefício por conta própria, pois conhece os detalhes suficientes para o trabalho.

Mas as primeiras coisas primeiro.

Etapa 0. Planejamento

Cada equipe tem uma lista de pendências, cuja parte superior é classificada e priorizada:

O ponto fundamental é que cada membro da equipe deve entender: essa tarefa precisa ser realizada porque está ligada ao épico, ao épico e ao objetivo, e o objetivo é importante. Caso contrário, as pessoas podem começar a fazer o que não é necessário ou o gerente será forçado a monitorar e extinguir constantemente os incêndios. A propósito, este último pode ser difícil de notar no escritório, mas é impossível perdê-lo remotamente: há muita confusão, o trabalho está em andamento, uma dúzia de salas de bate-papo começa no messenger na tentativa de sincronizar - como resultado, toda a equipe está conversando, em vez de escrever código. É extremamente importante organizar o planejamento em uma equipe para que cada participante do processo entenda o que e em que ordem ele precisa fazer. Em seguida, o líder da equipe poderá se concentrar no produto sem se distrair com pequenas e constantes perguntas.

Obviamente, é impossível detalhar detalhadamente todo o backlog, mas um estudo de alta qualidade do topo permite recriar rapidamente novas tarefas no sprint - quase todas as equipes vivem em sprints de duas semanas - e manter uma reserva para o próximo. Com essa abordagem, uma equipe experiente pode digitar um sprint mesmo sem um gerente, se de repente se tornar inacessível.

Para não prolongar o tempo de trabalho na tarefa, a equipe está envolvida em uma "burocracia útil": o gerente formula uma descrição clara, os executores declaram os status corretos, as tarefas "fluem" da esquerda para a direita no quadro de sprint:

Aqui toda a equipe vê a imagem completa e atual do sprint. Se alguém ficar doente, em serviço ou em férias, outros participantes imediatamente pegam as tarefas em seu status atual.

Bem, como pode ser sem sincronizações diárias, quando a organização formal do processo não é suficiente para resolver alguns casos específicos, e é mais provável que a burocracia interfira no processo. Normalmente, o detalhamento das tarefas por status (aberto> em andamento> em revisão> pronto para teste> teste> testado> pronto para dev> dev> rc> fechado) é suficiente, mas em 10% dos casos você precisa esclarecer alguma coisa, diga com palavras, explique " nos dedos ". A propósito, estou convencido de que todas as reuniões de trabalho (incluindo as de pé) devem ser realizadas por meio de comunicação por vídeo, e não apenas por voz, porque isso obriga a se colocar em ordem e sintonizar no trabalho.

É muito importante que toda a equipe estivesse presente na sincronização: eles verificaram rapidamente o contexto, organizaram as tarefas e começaram a trabalhar, guiados pelo conselho, sem perder mais tempo com perguntas. Obviamente, também temos chats em funcionamento, mas tentamos não inundá-los e usá-los para obter uma resposta rápida (idealmente binária): é possível lançar o release, onde encontrar instruções, com quem discutir a API da fonte de dados.

Onde o tempo ganhou: sincronização, tomada de micro-decisão

Etapa 1. Desenvolvimento: aberto> em andamento

“Aberto” - a tarefa está aguardando o artista. Os desenvolvedores os escolhem para que cada um esteja pronto o mais rápido possível. Por exemplo, acontece sexta-feira no quintal e o desenvolvedor entra em serviço na próxima semana (e isso é conhecido com antecedência, há um mês). Nesse caso, é melhor ele executar uma pequena tarefa para conseguir fazê-lo em um dia: tentamos não transferir o que foi iniciado. Se alguém não tiver tempo para terminar o trabalho, é melhor despejar como está e terminar os restos com uma solicitação de piscina separada.

Implantei uma cópia de trabalho local do projeto - não se esqueça de transferir a tarefa de "aberto" para "em andamento" para que outra pessoa não a assuma. “Local”, a propósito, é uma palavra-chave - você pode trabalhar de qualquer lugar, a qualidade da sua conexão com a Internet não será um fator de bloqueio. Agora que a infraestrutura e as redes estão sobrecarregadas, é muito importante. Nosso servidor de desenvolvimento local permite usar despejos de dados - compactar arquivos com dados para várias solicitações, para que você possa trabalhar totalmente sem a Internet. Após o desenvolvedor concluir o trabalho e enviar a solicitação de pool, a automação é ativada.

Onde o tempo ganha: uma avaliação independente de forças e capacidades, nem sempre é necessário superar uma conexão instável à Internet

Etapa 2. Verificações automáticas: em andamento> em revisão

Antes de a tarefa ser revisada, ela passa na verificação da qualidade do código, desempenho, falta de bugs visuais e funcionais. Aqui, pode-se escrever muito sobre a abrangência e variedade de nossas verificações automáticas, mas, em primeiro lugar, ele se baseia em várias histórias separadas e, em segundo lugar, vai muito além do tópico discutido. Vou apenas fornecer links para a descrição das ferramentas:

- um conjunto padrão de ferramentas para análise estática: ESLint e Stylelint com um rico conjunto de plug-ins;
- nossas próprias verificações estáticas: disponibilidade e qualidade das traduções, validação dos arquivos yaml;
- ferramentas padrão para testes de unidade: Mocha , Karma , PhantomJS ,Istambul ;
nossa própria ferramenta de teste funcional e visual, Hermione ;
- Pulse - para teste de desempenho - também é nosso. Eles o mencionaram aqui .

A propósito, a tarefa será revertida aqui em caso de problemas em qualquer estágio - infelizmente, mesmo o planejamento mais cuidadoso não economiza 100% de erros, algo pode dar errado. Se ele encontrar a pessoa certa na tarefa, ele descreve a essência do problema, carrega capturas de tela ou até vídeos, ele também pode escrever comandos no bate-papo para que todos notem que a tarefa foi interrompida. Seja o que for - o bug saiu durante o teste, o design mudou, não havia dados suficientes do back-end.

: — , - —

3. -: in review > ready for test

Em primeiro lugar, desejo chamar uma solicitação de pool, não apenas um revisor gratuito, mas uma pessoa que entenda o que está acontecendo no seu código; segundo, de uma equipe adjacente, para que todo o serviço tenha uma idéia de quem está fazendo o que - tudo isso está explicitado em nossos regulamentos. Mesmo em um pequeno escritório, pode ser difícil e demorado organizá-lo manualmente, para não falar da distribuição (e auto-isolamento!). Um revisor de código automatizado vem em socorro: ela também altera seus status por conta própria. Não vou me debruçar em detalhes sobre como funciona, não vou - é melhor ouvir a história do desenvolvedor. Ela também sabe como executar ping nos artistas: quanto mais a tarefa fica na revisão, mais violentamente ela fica.

Onde você ganhou o tempo: procure o revisor relevante, lembretes para processar a solicitação de pool

Etapa 4. Teste: teste> testado

Quando a alteração tiver passado na revisão de código, execute os autotestes. Somente depois que todos ficarem verdes, a tarefa será transferida para o teste manual. É importante que, para a tarefa, até que seja claramente transmitida a outra pessoa, o executor seja sempre responsável - é ele quem deve arrastar rapidamente seu código através da revisão e teste de código para produção. Ou seja, sempre sabemos quem é extremo, todo mundo monitora constantemente não apenas suas tarefas, mas também tudo o que acontece na equipe. O testador da equipe geralmente está sozinho, e isso também é conveniente para ele: ele vê que voará a seguir, poderá usar seu tempo com mais eficiência.

O testador pode:

- atribuir a tarefa de teste aos avaliadores - um post com todos os detalhes. Como resultado de testes realizados por avaliadores, algo pode exigir testes de pesquisa ou nova verificação;
- Teste você mesmo a tarefa em um dispositivo ativo ou usando um conjunto de dispositivos com acesso remoto - Farm Coletivo.

Os dispositivos ativos estão localizados nos Hypercubes em todos os escritórios da Yandex. Qualquer funcionário pode levar o dispositivo de que precisa com as características necessárias, depois de selecionar o ponto mais próximo com um dispositivo gratuito. Normalmente, depois de um tempo, o sistema lembrará automaticamente que é hora de devolver o dispositivo, mas essa função foi desativada durante o período de auto-isolamento. A equipe de serviço certificou-se de que aqueles que precisavam dele precisavam criticamente dos dispositivos vivos, e que todos os outros, para não desacelerar os processos de trabalho, ajudassem na conexão com a fazenda coletiva.

Um farm coletivo é um farm de dispositivos de teste remoto que qualquer pessoa pode usar. Android, iOS - verificamos as alterações até nas versões mais antigas e mais difíceis dos sistemas, para que nossos serviços estejam disponíveis para qualquer pessoa. Mas também estamos tentando obter capitânia o mais rápido possível, tanto na Fazenda Coletiva quanto nos Hipercubos. Lembre-se da "cortina" (é a "monobrow") que apareceu no nono iPhone e de todos os problemas associados a ela?

Onde ganhar tempo: planejamento, testes automáticos, distribuição de dispositivos: disponível mesmo com auto-isolamento

Etapa 5. Infusão: pronta para fev> dev

A tarefa é testada - é hora de colocá-la em um ramo comum.

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

Quando existem muitas injeções (por exemplo, temos mais de 30 solicitações de pool com infusão por dia), surgem dois problemas:

- menor : o histórico no git, se você se cadastrar aleatoriamente e não se recuperar, isso se tornará muito confuso e se houver algum tipo de bug , retroceder é muito difícil;

- crítico : teste de integração. Nem sempre é fisicamente possível esperar até o final do teste de suas alterações junto com a versão mais recente do tronco, para que ocorra o seguinte: duas solicitações de pool, cada uma das quais individualmente não quebra nada, interrompe o tronco após a infusão. Para evitar isso, aderimos ao desenvolvimento baseado em tronco, ou seja, uma liberação pode ser lançada a partir de qualquer confirmação. E embora ainda não tenhamos chegado finalmente à Implantação Contínua, nosso tronco é "verde". E quebrá-lo mesmo uma vez por semana é categoricamente inaceitável para nós.

Há vários anos, usamos a ferramenta Merge Queue para automatizar a fila e a aprimoramos constantemente. As alterações não são derramadas pelo desenvolvedor, mas pelo robô. Em cada solicitação de pool, ele é redefinido de acordo com a versão mais recente do tronco e executa um conjunto completo de testes. Este é um processo bastante demorado, portanto, é impossível construí-lo em pessoas vivas - uma pessoa simplesmente não espera os resultados finais. E o robô trabalha sem dormir, descansar e descansar. Além disso, a tarefa não pode ser colocada na fila pelo próprio desenvolvedor, mas pelo testador imediatamente após o final do teste, mais uma vez, você economiza tempo.

Mais detalhesSobre a fila de mesclagem.

Onde o tempo venceu: impedimos o bloqueio de falhas, você não precisa controlar manualmente a infusão da solicitação de pool

Etapa 6. Liberação: rc> fechado

Todos os dias úteis, às 5 horas da manhã, desde o último commit no tronco, obtemos automaticamente uma nova versão: a montagem de pacotes estáticos e dinâmicos, o cálculo de prestabilidade, o teste pelos avaliadores. Em seguida, o testador de plantão analisa o relatório e, se houver erros, informa o desenvolvedor de plantão sobre eles. E se tudo estiver bem, passa para o gerente de serviço. Se ele aprovar, o desenvolvedor de plantão lança a versão.

É importante esclarecer que as tarefas de diferentes equipes se enquadram no release; portanto, é benéfico para todos quando um desenvolvedor de plantão é claramente alocado para os lançamentos, que tem trabalhado durante toda a semana em lançamentos contínuos e monitorando o monitoramento de erros. Isso permite que outros desenvolvedores do projeto alternem para novas tarefas o mais cedo possível (na verdade, imediatamente após o envio para a Merge Queue).

Geralmente, todas as atividades de liberação ocorrem durante o horário comercial (mesmo em casa, pedimos a todos que observem o regime - como resultado, todo mundo o quebra em direções diferentes, mas não paramos de tentar), mas se algo estiver errado na produção, a mudança de plantão acordará o desenvolvedor de plantão, que ele respondeu prontamente.

Lembro que a principal tarefa é reduzir o tempo de sincronização dos membros da equipe e a quantidade de rotina: todo mundo sabe quem está de plantão. Todo mundo sabe o que fazer e como, todo mundo tem instruções. Quando o gerente permite o lançamento da versão, ele não explica ao desenvolvedor o procedimento, o desenvolvedor sabe tudo e sabe como.

Onde o tempo ganhou: sincronização, tomada de micro-decisões.O
ciclo foi encerrado.

O trabalho distribuído é uma vacinação contra processos ruins e ineficientes que inibem os projetos, mesmo nas condições usuais, para não falar dos não padronizados. A experiência de nossa equipe confirma que, com o devido tédio, você estabelecerá procedimentos e interações e respeitará honestamente todas as regras, não importa quão comuns sejam, o fluxo de trabalho será bastante difícil de paralisar.

Algo que lembra o gerenciamento de tráfego: quando havia poucos carros e eles eram lentos, poucas pessoas pensavam nas regras de trânsito. Agora há muitos carros e eles são rápidos - o movimento sem regras se tornou impossível. Quanto melhores (e ao mesmo tempo mais simples) essas regras são formuladas, mais profundamente os participantes do tráfego as cumprem, maior a capacidade de tráfego das estradas.

Obrigado por ler até o fim. Vejo você nos comentários!

O trabalho de uma equipe distribuída em condições de auto-isolamento: como quase não percebemos a diferença