Como sobreviver a colegas de equipe em uma escalabilidade escalável e manter o controle de qualidade do código

O diretor técnico da ivi, Evgeny Rossinsky ( eross ), conhece bem os participantes de nossas conferências sobre relatórios sobre o lado técnico da transmissão. Mas hoje você tem a transcrição do relatório de Eugene no TeamLead Conf sobre como a transformação Agile se reflete nos líderes de equipe.



Há pouco tempo, no ivi, passamos pela transformação do Agile e obtivemos um bom lucro em termos de:

• negócio
  
• velocidade de desenvolvimento
  
• tempo de colocação no mercado;
  
• outras métricas interessantes.
  

Mas as consequências dessa decisão criativa atingiram seriamente os líderes da equipe. O relatório é sobre como lidar com isso e quais ferramentas usar.

Antes da transformação

Para entender do que falarei, precisamos nos familiarizar um pouco com nosso produto. Em seguida, analisaremos por que temos esse formato de comandos e por que escolhemos esse caminho.

O desenvolvimento no ivi está em cinco plataformas principais :

• iOS
  
• Android
  
• Web
  
• Smart TV
  
• Windows + Xbox.
  

E, claro, o back-end, sem o qual nenhum lugar. Antes de decidirmos realizar a transformação, nossas equipes eram formadas por competências.



Caras que conhecem, por exemplo, Swift ou Objective C:

• sentado na mesma sala;
  
• receber tarefas de gerentes de produto;
  
• trabalhe neles e produza um resultado.
  

Tudo parece estar bem, mas há um problema - as plataformas são muito seriamente diferentes em termos de produto e consumo de conteúdo pelo usuário.

Isso significa que em cada equipe seu backlog e suas prioridades começaram a aparecer . Por exemplo, os usuários de um aplicativo Web não gostam de pagar e o conteúdo é consumido por meio de um modelo de publicidade. Os recursos necessários para esta plataforma aparecem naturalmente na lista de pendências. As TVs inteligentes são caracterizadas pelo fato de serem bem compradas, e os recursos de um modelo pago são manifestos.

Acontece a seguinte situação: alguém teve uma idéia brilhante de como melhorar um produto; Escrevi vários tickets para os gerentes de produto, cada um responsável por sua plataforma. Os gerentes passam as idéias pelo prisma de sua percepção, talvez eles modernizem algo e o incluam em seu plano de trabalho. O problema aqui é que um recurso pode ser lançado em todas as plataformas por mais de um ano, porque "acredito que não é de todo uma prioridade para minha plataforma". E em um ano, seis meses ou apenas alguns meses, qualquer coisa pode acontecer com o produto - por exemplo, ocorre uma reformulação ou uma mudança de conceito, e esse recurso já precisa ser implementado e é completamente diferente de todas as outras plataformas.

Como resultado, depois de algum tempo, verificou-se que em diferentes plataformas temos produtos completamente diferentes, com diferentes mensagens de comunicação e lógica de negócios. O usuário nessa situação começa a ficar confuso, porque ele não possui um único espaço no qual se sente confiante. Além disso, é muito difícil criar hipóteses , pois nem sempre é claro em qual plataforma qual funcionalidade será melhor. Tudo depende do tamanho da tela, de como as pessoas consomem conteúdo. E tudo parecia algo assim:



O produto engenhoso traz a ideia, e os desenvolvedores em diferentes plataformas a percebem pouco amigável, com exceção do back-end, que em geral não importa o que escrever.

Portanto, como a empresa tinha competências suficientes em relação ao que são metodologias flexíveis, concordamos com o negócio de que precisamos remover a barreira entre:

• produto
  
• negócio
  
• tecnologia
  

interaja produtivamente e faça uma coisa comum.

Após transformação

Isso resultou em uma arquitetura com fluxo de valor dedicado, na qual cada equipe está envolvida em uma área de negócios específica.



Para formar uma nova estrutura, nós:

• realizou vários treinamentos;
  
• Determinamos quais são as principais áreas de nossos negócios;
  
• voluntariamente forçaram as pessoas a entrar no fluxo de valor;
  
• começou a implementar.
  

É verdade que, antes disso, formamos uma dessas equipes, no exemplo das quais realizamos demonstrações , depois de reduzir um recurso em todas as plataformas com um excelente tempo de lançamento no mercado.

Além disso, o recurso foi escolhido muito bem e teve sucesso em todas as plataformas. Então, tivemos um exemplo que mostrou que tudo pode ser feito mais rápido e melhor . Isso permitiu que toda a equipe de desenvolvimento de 130 a 140 pessoas entendesse que você pode trabalhar de maneira diferente.

Quando determinamos o fluxo de valor, surgiu a questão do que fazer com os líderes de equipe. Anteriormente, eles eram a base de tudo em sua direção, mas agora há um fluxo de valor e uma maior influência dos negócios. O que fizemos? Reunimos pessoas de competências diferentes em cada fluxo de valor, pelo menos um cada:

• desenvolvedor iOS
  
• Desenvolvedor Android
  
• Desenvolvedor JavaScript
  
• Especialista em Smart TV
  
• designer de layout,
  
• para o testador.
  

Acabou sendo uma equipe independente, mas independente em palavras e nos belos slides de um treinador do Agile. De fato, todo mundo esquece que ainda existe algo em comum entre as pessoas que podem escrever na mesma linguagem de programação - esse é o código do programa, através do qual elas devem se comunicar de alguma forma. Por alguma razão, muitos se calam sobre isso, mas esse é realmente um grande problema que precisa ser lembrado.

Suponha que você coloque pessoas em andares ou salas diferentes e elas escrevam o mesmo código. Há um ciclo de liberação e recursos que não devem interferir entre si. Existem muitos problemas.

Do conceito

Adotamos vários conceitos básicos:



Temos comandos de fluxo de valor e plataforma . No fluxo de valor, os funcionários implementam um recurso específico e nas plataformas há um líder de equipe - o centro de competências. Dentro das plataformas, alguns recursos também podem ser desenvolvidos, mas essa é mais uma visão arquitetônica do desenvolvimento de software.

Introduzimos o conceito de " Guildas ". Ao colocar os mesmos desenvolvedores do iOS em salas diferentes, precisamos dar a eles um sinal formal e até informal, de que eles continuavam sendo os mesmos desenvolvedores do iOS, e não apenas participantes do fluxo de valor do produto de publicidade, por exemplo. E então, com essa guilda, você precisa fazer algo e de alguma forma ensinar as pessoas a se comunicar por dentro.

A próxima pergunta era o que fazer com os ciclos de lançamento . Nas plataformas em que você pode implantar quando o recurso estiver pronto, não há perguntas. E no caso do iOS ou Android, quando, devido às especificidades de receber a aprovação da Apple, é impossível enviar o aplicativo duas vezes por dia para liberação, é necessário acumular alguns pacotes.

Decidimos que todas as plataformas que não puderem ser lançadas imediatamente serão lançadas a cada duas semanas . Eles disponibilizaram um calendário especial para todos, onde a equipe publica a data de congelamento do recurso e a data de lançamento. Se, estando no fluxo de valor, você deseja que sua tarefa fique disponível para um usuário real, você deve chegar a tempo de congelar os recursos. Teve tempo - bem, não teve tempo - você está esperando o próximo trem.

Timlid no novo esquema

O que aconteceu com os Timlids? Eles passaram pelo esquema clássico de conscientização de problemas que não podem ser resolvidos.



No começo, nos deparamos com uma negação . Como o líder da equipe construiu uma equipe legal por vários anos, nutriu cada funcionário, atraiu alguém dos concorrentes. E esses especialistas agora foram designados para um trabalho que nem sempre atende às suas expectativas.

É claro que, após a negação, houve raiva .

Houve muitos escândalos, após os quais as negociações começaram. Todo mundo veio com uma pergunta: "Vamos todos seguir o seu próprio caminho, mas eu o tenho como antes, mas vou pegar um marcador, escrever" Ágil "em minha casa, vou vestir uma camiseta com esta inscrição, mas tudo será como antes". Não deu certo.

Mas, no final, o que eu realmente esperava que acontecesse - as pessoas entenderam por que estávamos fazendo isso. Espero que eles tenham entendido, embora talvez tenham mentido. O primeiro caso de sucesso mostrou uma diferença marcante entre o que era antes e como isso pode ser feito de maneira diferente. O tempo de colocação no mercado reduzido pela metade nos permitiu estabelecer uma referência para todos. O próximo passo ocorreu, que no modelo clássico de psicologia é chamado de Síndrome de Estocolmo . As pessoas que adotaram as novas regras aprenderam a existir nelas e começaram a propagar lentamente essa "religião". Não posso dizer por todos os Timlids, mas cerca de 30% deles agora são "pregadores" ativos nessa direção.

Problemas e dificuldades

Agora vou tentar listar mais estruturalmente as dificuldades que encontramos:



Devido ao fato de os funcionários estarem sentados em escritórios diferentes, a comunicação verbal foi perdida. Tornou-se muito difícil por um mês , porque antes era possível perguntar rapidamente a um vizinho, por exemplo, do que você precisa herdar e obter uma resposta. E agora você está sentado em uma sala separada, há pessoas ao seu redor cuja tecnologia você pode não gostar e não há ninguém para consultar. Para fazer uma pergunta a alguém, você precisa escrever em um bate-papo, e a pessoa que pode responder se foi - isso é tudo, você fica com seus próprios dispositivos.

Começamos imediatamente a ter problemas com a Revisão de Código , o que acho que não é um problema, mas uma grande descoberta. Descobrimos que um grande número de funcionários não é independente . Suponha que houvesse um funcionário que, de acordo com as estatísticas, os problemas de revisão passassem o máximo na segunda vez, geralmente na primeira vez que tudo estava bem. E quando ele saiu para trabalhar no fluxo de valor, por algum motivo, tornou-se 5-6 iterações.

Eles começaram a entender, e descobriu-se que a opinião autorizada da figura icônica do líder da equipe, que controla, centraliza todos os fluxos de informações relativos a si mesmo, não afeta muito o desenvolvimento dos desenvolvedores. As pessoas são preguiçosas , pedem ajuda em todas as questões e recebem respostas competentes. E assim a revisão é rápida e legal. Por estarem sozinhos, muitos desenvolvedores tiveram que crescer significativamente acima de si mesmos para tomar as mesmas decisões arquiteturais . Ninguém gosta de ouvir cinco vezes seguidas que seu código não é muito bom. É frustrante, faz você se considerar um funcionário insuficientemente qualificado, pode até levar à depressão ou à convicção de que talvez o trabalho seja ruim. Mas o ponto é que você precisa se olhar, entender que no modo de operação anterior você não pensou nessas coisas, mas agora está desenvolvendo e deve começar a pensar nelas .

Por outro lado, tivemos algumas coisas muito interessantes que, na minha opinião, são redundantes em relação à Revisão de Código. Havia uma regra em uma das equipes: para que a tarefa seja aprovada na revisão, todos os membros da equipe devem tomar sua decisão. Quando se sentaram juntos, tiveram mais ou menos sucesso, e agora todos se sentaram - alguns tiveram uma reunião de stand-up diária de uma vez, outros tiveram outros assuntos - e a revisão das tarefas tornou-se um gargalo estreito. Repetidas vezes, eles aprenderam que algumas tarefas estavam sendo analisadas por duas semanas e foram forçadas a mudar alguma coisa.

Então começou: separatismo, discriminação e inveja .

Anteriormente, uma pessoa pensava que sabia o que queria fazer. E com a separação entre fluxo de valor e plataforma, começou a surgir uma suspeita de que “o vizinho tem um gosto melhor”: as tarefas são mais interessantes e o crescimento é mais rápido. O segundo problema é que, quando tudo se torna centralizado em recursos , a qualidade do código se deteriora muito. Ao seu redor, há pessoas que desejam obter rapidamente o resultado, e não é tarefa deles pensar que ele precisará ser apoiado, modernizado de qualquer forma, e nada deve romper com os colegas com o novo recurso.

Começaram a surgir situações em que a alta velocidade de desenvolvimento tinha seu lado oposto - código de baixa qualidade , que começava a se multiplicar em quantidades desumanas. Quando o líder da equipe responsável assume a correção desses erros e a refatoração, sua vida se transforma em um lixo arrebatador para funcionários negligentes. Os desenvolvedores são rápidos em obter tudo, todos estão felizes e não percebem o trabalho titânico do líder da equipe, graças ao qual, de fato, tudo funciona. Após cerca de dois meses, cada líder da equipe expressou insatisfação com a situação atual.

Para resolver esses problemas, realizamos várias reuniões primeiro com os Timlids e depois com todas as guildas, a fim de explicar às pessoas que é possível trabalhar de maneira diferente. Se você quiser tentar outra coisa, então, com isso, precisará assumir a liderança da equipe e mudar facilmente de lugar. O principal é concordar entre si.

A força das metodologias flexíveis é que não importa para todos como tudo acontece, o principal é que as pessoas concordem e estejam satisfeitas.

Isso está por um lado. Por outro lado, para que haja justiça em relação a quem está envolvido na refatoração e quem está realizando novos recursos, os líderes de equipe começam a trabalhar com registros em atraso, voltarei a isso um pouco mais tarde.

E então as dificuldades começaram com o Gerenciamento de Liberação . Existem testadores no fluxo de valor, testadores nas plataformas, algo é automatizado, algo não é automatizado, você precisa pensar em como fazer uma regressão geral. E há termos. Decidimos voluntariamente liberar uma vez a cada duas semanas, e se um parceiro vier com um pedido para fazer tudo até amanhã (e um saco de dinheiro, por exemplo), peça para ele esperar o próximo ciclo? Ainda assim, é necessário buscar um compromisso . E então, um belo esquema com lançamentos pode mudar bastante.

Um bom exemplo é a lei FZ-54, segundo a qual todas as compras na Internet devem ser acompanhadas pelo envio de cheques eletrônicos aos usuários e ao imposto. Você pode falar em conferências o quanto quiser e falar sobre metodologias flexíveis e sobre o que há regulamentos e assim por diante, mas assim que houver o risco de obter uma penalidade de 70% da sua receita, você muda para um regime completamente diferente e garante que sua empresa não seja multada. Tais casos não são frequentes, mas existem. Em particular, tivemos que fazer o segundo nível de comunicação em caso de mudanças no esquema. Não é fácil, mas é possível.

O próximo problema que encontramos como resultado da transformação está relacionado a novos funcionários . Na minha opinião, os iniciantes devem estar imersos em um ambiente o mais próximo possível daquele em que ele trabalhará. E lá, devido ao meio ambiente, ele receberá rapidamente o conhecimento necessário. Mas arrastamos os especialistas que compunham esse ambiente em diferentes andares e salas. A vida de um iniciante em uma empresa se torna uma tarefa administrativa bastante séria, cuja solução deve ser pensada.

As ferramentas

Aqui estão as ferramentas que usamos.



Vou começar a história com um mapa de rotas para um novo funcionário. Infelizmente, isso é algo que ainda não aprendemos a automatizar completamente e, de fato, refletir sobre cada funcionário separadamente, dependendo do que ele fará.

Havia um exemplo bastante interessante: precisávamos desenvolver um testador universal , capaz de testar absolutamente todos os produtos para um fluxo de publicidade. Eles têm muito em comum, mas também têm suas próprias especificidades. Não é segredo que um testador que é legal em testar um aplicativo Web será perdido pela primeira vez ao trabalhar com ferramentas, por exemplo, para iOS. Para esse testador, nosso diretor de controle de qualidade construiu um mapa de rotas especial. Nesse cartão, um novo funcionário em cada competência adquiriu conhecimento por duas semanas, participou de regressões e muito mais. Com os desenvolvedores, a situação com a implementação é aproximadamente a mesma. Assim, mesmo na entrevista, descobrimos o que Candida gravita e o que lhe interessa, e tentamos escolher em que direção enviá-lo.

Obviamente, a primeira vez que um novo funcionário bombeia competências, ou seja, em nossos termos, faz parte da equipe da plataforma e já pode migrar para o fluxo de valor de que precisamos. A propósito, os mapas de rotas são bons, mas sua adaptabilidade também não precisa ser descartada.

Em seguida, introduzimos o Guild Sync - sincronização de ações da guilda .

Por que isso é necessário? Todos ouviram uma palestra sobre Scrum, que falou sobre a necessidade de uma reunião de stand-up diária para que você saiba o que está acontecendo ao redor. Mas nosso especialista, por exemplo, é um desenvolvedor Android, por um lado, e um membro da equipe de produto, por outro. Se ele tiver que andar e se comunicar duas vezes por dia, receberá algum tipo de culto à carga. Nesse ritmo, você pode passar a vida toda em reuniões. Definitivamente, isso irritará as pessoas.

Se dissermos que somos baseados em um modelo centrado em recursos, a reunião de stand-up diária é mais importante em seu fluxo de valor. Mas, ao mesmo tempo, você pode se afastar do que está acontecendo na guilda. Para fazer isso, algumas guildas organizam reuniões uma vez por semana, algumas - duas vezes por semana. E aqui o líder da equipe pensa metodicamente sobre o que vale a pena falar. Isso não deve se traduzir em conversa vazia, é uma estratégia de desenvolvimento para a equipe de tecnologia, que é a guilda. As reuniões do Guild Sync são necessárias para que todos entendam quais tecnologias a empresa usará, que decisões estratégicas são tomadas em relação a essa plataforma. Nele, é realizada uma revisão parcial das soluções arquitetônicas.

Em algumas equipes, temos mais de um líder de equipe. Em geral, a definição de líder de equipe é muito ambígua. Existem líderes de opinião que podem ser líderes de equipe e levar a solução de algumas questões organizacionais. Pode haver vários líderes de opinião com habilidades de gerenciamento em uma equipe. E então eles podem se organizar, quem é responsável por quê. Por exemplo, um dos líderes de opinião pode ir para o fluxo de valor. Nesse caso, você precisa sincronizar suas decisões de arquitetura, que no futuro determinarão a estratégia de desenvolvimento de toda a plataforma tecnológica.

Então começamos a realizar mitaps internos e externos em certas áreas. Em geral, esse é um caso parcialmente padrão de RH, parcialmente um caso de formação de equipe. Para reuniões internas, às vezes é realizada uma votação sobre qual tópico é mais interessante, os oradores são procurados dentro da empresa ou convidamos alguém de fora, alugamos uma sala especial e discutimos vários pontos importantes. Em média, temos dois mitaps internos por mês, mas às vezes quatro. Pessoas de outras competências podem vir a essas mitaps para ouvir como os vizinhos vivem e ver se eles querem mudar sua especialização. Isso também acontece.

Agora, no mercado de trabalho, em questões de desenvolvedores, tudo não é muito simples. , , . , , , . , , .

. , , Agile- , Guild Sync .

, , , . , , Guild Sync , .



, , , , , . 10 .

— . , , -. - , , , . - , , , . , - . , , , , , - .

. , . , , , , . , , , . , - , , , , , .. . , « ». , , .

Guild , . - , , .

, product owner' value stream. , 10 , - , , . , product owner' . backlog' . , , . , ( , , , , ).

— , .

Teamlead —

, , - .

, . , , , , , , — .

, , , « ». , , , . , , , , value stream. , , . , , .

O próximo comício para a troca de truques de Timlid está agendado para 24 e 25 de setembro. Nos reuniremos em São Petersburgo no Saint TeamLead Conf para discutir todos os tipos de problemas de gerenciamento de equipes.

O programa já está começando a tomar forma, há mais de 40 inscrições na lista de relatórios enviados e, até agora, há uma oportunidade de adicionar seu tópico lá - o Comitê do Programa aceita inscrições até 10 de agosto .