Lado escuro ágil

O leitor atento folheia a fita e faz a pergunta: “Qual é o texto sobre ágil?”. Sim

Este artigo é sobre processos, aspectos técnicos e um pouco sobre como a vida ágil é implementada no Yandex.Money. Se você percorreu pelo menos a metade do caminho para o verdadeiro ágil, algumas coisas podem parecer óbvias para você, e isso é bom.

Debaixo de um gato sobre bancos de teste, trancando pessoas em salas de reuniões e como gerenciar um departamento, quando todos se espalharam pelas equipes e aproveitaram a vida.

E um leitor atento perguntará: "Por que o lado negro? O que há com Darth Vader?" Infelizmente, não, falaremos sobre o lado escuro da lua, que era desconhecido para a humanidade, até que o dispositivo voasse para fotografá-lo e mostrá-lo a todos.

Ao implementar o ágil, você está criando um projeto de exploração da lua, sem saber
o que está do outro lado

Tudo começa com uma tentativa de introduzir novos processos de desenvolvimento.

Scrum, kanban, scrambana ou alguma outra bicicleta local não é tão importante.

Departamentos clássicos de desenvolvimento geralmente são liderados por um gerente de recursos. Ele diz ao mundo exterior: "Não vá para os desenvolvedores, vá para mim, vou distribuir tudo aqui agora". Uma vez que esse gerente pela primeira vez aloca um fluxo, porque algum cliente especial apareceu. Depois, existem mais clientes dentro e fora da empresa, os conflitos começam, a luta por recursos e o gerente precisa resolver tudo. Também por alocação de thread.

Java - esquerda, JavaScript - direita

Esse jogo continua em algum ponto crítico, após o qual a empresa aceita a ideia de que agora é preciso agilidade. As equipes de produtos aparecem porque, para o PO, não há nada mais valioso do que um recurso dedicado e sua própria equipe. O produto está satisfeito porque a equipe ao vivo facilita a resposta pela funcionalidade e assume o ônus da responsabilidade pelo PNL, tráfego e outros KPIs.

Parece correto, mas na vida real, tudo está um pouco errado.

Na maioria dos departamentos de desenvolvimento clássicos, é mais lucrativo trabalhar com um monólito. Nesse caso, todos os atributos estão anexados - ciclo de liberação em 3-4 semanas, longos testes e montagem.

Às vezes, um monólito é normal

Mas as equipes selecionadas não funcionam assim. Em geral, o mundo chegou aos microsserviços devido ao fato de que todos começaram a mudar para pequenas equipes e trabalhar nelas. Sim, isso leva ao fato de que o código "se espalha" e tudo se torna mais difícil de controlar.

Por outro lado, aceleramos o lançamento do produto, lançamos lançamentos com mais frequência, mas encontramos problemas com os testes. E eles também precisam ser resolvidos de alguma forma.

Reforma dos Testes

Se você tem uma equipe e um posto de teste - tudo está em ordem, não pode se preocupar (ou se preocupar, mas por um motivo diferente). Freqüentemente, nesses casos, nem sequer é considerado algo crítico - por exemplo, uma ferramenta adicional como correio ou bate-papo corporativo. Todo mundo está monitorando de perto a produção e eles também estão bem.

Se você já voou para a Lua Edgile, a bancada de testes é algo que atrasará todo o processo, e é por isso.

História de vida : em uma empresa, a entropia em torno do ágil começou a crescer muito rápido. Nesse ponto, os testadores entraram no cronograma da única bancada de testes do calendário - dividiram o tempo em intervalos de meia hora e tentaram de alguma forma controlar o caos.

De fato, 20 equipes devem usar o suporte, mas não podem, porque uma delas quebrou tudo

Sobre bancadas de teste

Era uma vez, tínhamos vários monólitos, cada um com uma bancada de testes, e todos estavam felizes. Depois que fizemos um projeto complexo para a separação dos estandes, alocamos equipes, e então havia 20 estandes.

Agora existem 70 deles, mas nosso objetivo é 200 - para que todos, gratuitamente, e ninguém se ofenda.

No diálogo com o administrador:
- Diga-me, onde está a automação de implantação?
- O cálculo a cada duas semanas leva uma hora, o que devo automatizar aqui?

De fato, isso: (200 estandes + produção) * (mais de 50 componentes) = Muito esforço para implantar.
Agora, temos mais de 50 componentes que o robô lança. Se não fosse por ele, todo mundo seria ruim.

Nesse estágio, a empresa, que segue em direção ágil, terá sistemas automatizados para montagem e entrega à produção, o trabalho em equipe melhorará gradualmente e o desempenho também aumentará - até 60 a 80 lançamentos por semana, e cada componente será lançado 2-3 vezes por dia .

Neste ponto, todos entendem que o sistema se tornou muito grande para uma pessoa entender.

Em qualquer equipe que apóie o monólito, certamente haverá alguns veteranos. Eles estavam aqui desde o início e lembram-se de todos os erros de todos os tempos, lembram-se das estranhas decisões lógicas que a empresa estava vendendo.

História de vida:
"Em geral, é normal tentar bater em um cliente três vezes, mas esse cliente é especial e bateremos 100 vezes, existe um fator de correção e não é necessário tocá-lo, por favor, toque-o, não é exatamente assim."

São tantos os recursos gastos na manutenção do trabalho dos estandes que a operação se torna "dourada" - multiplique o farm inteiro pelo número de estandes de teste, adicione produção, fique chateado e, finalmente, chame os administradores.

Outro monitoramento

Os administradores virão e dirão: "Tudo é coberto pelo monitoramento em nós". Isso é bom, mas com um esclarecimento - o monitoramento seria bom de ser personalizado.

Métricas “ferro”, quantidade de memória consumida por Java, temperatura de todos os núcleos de todos os processadores - tudo isso é útil, mas nem sempre ajuda em caso de incidentes com os clientes. As métricas de negócios também não terão noção se você não as tiver personalizado. O mundo é complexo - é raro que todos os clientes ideais usem sua API ideal idealmente. As pessoas fazem tudo e todos precisam se adaptar - às vezes os clientes são para você, às vezes você é para os clientes.

Como uma usina nuclear

História de vida : durante muito tempo pesquisamos e corrigimos um bug em nossos produtos. Depois disso, um dos clientes quebrou vários processos nos quais esse bug foi levado em consideração.

Nesses momentos, você precisa adicionar um monitoramento personalizado, porque, sem isolar situações e agregações excepcionais, ele simplesmente não funciona. Portanto, a propósito, eles costumam falar e escrever sobre aprendizado de máquina e sistemas complexos que definem problemas em vez de pessoas.

A cada seis meses, é necessário realizar revisões de monitoramento, porque as expectativas dos negócios aumentam com o tempo. Acontece assim - tudo é construído e controlado na empresa, e os negócios trazem um novo cliente que precisa de um SLA muito mais alto. E a história toda acabou.

Se isso for superado, o sistema funcionará muito bem em todos os casos, exceto em projetos "genéricos".

Projetos de guarda-chuva

Por exemplo, é a introdução do 54-FZ, quando o estado diz: "E reestruturar todos os processos de caixa no país". Ou, quando o marketing pagava pelo projeto, o produto ainda tinha que funcionar e trabalhar, e o prazo era real e, então, eles o atendiam. Ou quando alguém da alta gerência acaba de entrar, não importa por que motivo, e ele também tem um projeto com prazo.

Spoiler - poucas pessoas no mercado sabem como fazê-las. Você pode comprar complementos diferentes no scrum e no kanban, pode ler histórias de sucesso, mas a prática mostra que é mais caro fazer esses projetos em teoria. Além disso, todos esses SAFE e LEAN são caros em termos administrativos e de recursos e também exigem competências caras e complexas que não estão no mercado.

História de vida: O Spotify é uma das empresas ágeis exemplares. Em algum momento, eles criaram uma assinatura da família, mas não conseguiram realizá-la devido à dificuldade de sincronizar e planejar entre equipes que têm seu próprio roteiro e planos. Um ano depois, Google e Apple lançaram a assinatura da família.

Conflitos de sincronização e agendamento

O principal problema dos projetos guarda-chuva é a sincronização de todas as equipes participantes. Está relacionado ao fato de que as pessoas não gostam de negociar.

Isso se manifesta em muitas coisas, começando com o scrum, quando as pessoas não conseguem concordar na estrutura de um departamento de recursos. No ágil, você precisa sincronizar e coordenar tudo o que acontece com várias equipes. E se, em algum momento, você parar de exigir que todos trabalhem juntos, cada equipe retornará ao seu canto escuro favorito e trabalhará de forma independente. Isso leva ao fracasso.


Life hack
Se restarem dois meses antes da próxima lei, ou antes da campanha publicitária, ou o chefe exigir - leve pessoas de quatro equipes, tranque-as em uma sala, dê comida, água e controle. Isso é rude, mas funciona. Porque se você tentar se envolver na sincronização por um tempo limitado, você falhará no projeto.

Em geral, a sincronização é necessária e sem ela você não pode seguir em frente. Isso complica a vida em projetos com prazo claro e alta criticidade - os prazos variam de 10% a 50%, e isso geralmente é inaceitável.

Como gerenciar isso?

O líder clássico no departamento distribuído não entende qual é o seu papel, porque ele aprendeu o paradigma "Eu dei tarefas a todos" e tenho que trabalhar com "Não tenho pessoas, por que estou na empresa?".



O pior é que os malucos de controle que não perdem uma única tarefa que o departamento resolve, organizam revisões duplas de código público e controlam literalmente tudo. Quando as pessoas são distribuídas em equipes, elas fazem a pergunta: "Por que estou aqui?". A resposta é para que os desenvolvedores de todas as equipes troquem informações, cresçam de forma síncrona em uma direção e o sistema não rastreie.

Em geral, quando essa pergunta soa, o líder precisa ser mudado ou ensinado.

Ensinar porque muitos líderes (inclusive nós) crescem com os engenheiros e ninguém nunca lhes ensinou habilidades pessoais. Acreditamos que isso é importante, e uma vez chegou ao RH e solicitou um grande curso de dois anos para os gerentes - do básico ao desempenho e à motivação não financeira.

Cultura em TI

Há outro ponto sutil sobre a agilidade na organização de equipes. Quando os desenvolvedores concordam com algo dentro da equipe, eles podem começar a defender os interesses da equipe, esquecendo os interesses da empresa.



Idealmente, quando as pessoas entendem que há mais alguém em torno de sua lua Ajail - um serviço de segurança com seus próprios requisitos; arquitetura que não foi apenas inventada; outras equipes cujos interesses precisam ser considerados. Nós nos esforçamos para identificar, nutrir e incentivar esse comportamento.

Ágil - ponta do iceberg

Este caminho tem características importantes.
Muito tempo. Por exemplo, o DevOps apareceu no mercado há cinco anos e sua implementação agora custa de um a dois anos, dependendo do tamanho da empresa. Se você começar a lidar com isso quando tiver filas nas bancas de testes, terá seis meses de inferno, porque os administradores ficarão divididos entre tudo.

Caro Você pode implementar agilidade e seguir esse caminho apenas se tiver um negócio forte e uma empresa forte, e entender que, no futuro, ainda precisará crescer.

Não há pessoas. O Agile precisa de novas competências, que as pessoas não têm tantas. Acontece um círculo vicioso - não há pessoas -> tudo não está indo muito bem -> não há dinheiro -> não há para onde tirar as pessoas.

Três conclusões

1. Não toque nos departamentos de desenvolvimento "clássicos" sem a necessidade. Um sistema híbrido funciona no Yandex.Money - existe uma equipe de produtos, mas existem departamentos que podem trabalhar efetivamente sem agilidade.
   
2. Se você não tem uma tarefa de reconstruir toda a empresa, mas deseja ou precisa acelerar um novo produto com novas abordagens, às vezes é mais fácil contratar terceirizados que trabalham com agilidade e fornecem ao produto um recurso externo.
   
3. Se a transformação de TI for inevitável, é melhor concordar com tudo "em terra". Vale a pena concluir uma espécie de "acordo de cavalheiros" com a liderança - que haverá um orçamento para hardware, pessoas (para novas posições para administradores de sistemas, testadores e desenvolvedores). Nesse caso, é possível retornar periodicamente a este contrato e discutir o que foi feito e como.
   

Todos os itens acima têm um problema. Vá até o fim! = Venha para o sucesso. Não passe = garantia de falha.

Mas se você estiver a caminho - boa sorte!