Sou PM no
serviço de correspondência
UniSender . Há 6 anos, vim como programador e agora sou responsável pela interação entre as equipes de produtos. Anteriormente, nosso desenvolvimento consistia em uma equipe distribuída e tivemos 2 problemas. Mas não tolos e estradas, mas atrasos em corridas e acrobacias chatas por meia hora.
Vou lhe contar como os resolvemos.
Como eu disse, tivemos 2 problemas:
- O Sprint pode demorar devido à falha de uma tarefa . O controle de qualidade e o Dev trabalharam no mesmo sprint, os escopos das tarefas foram corrigidos no início do trabalho e toda a equipe heroicamente se apressou em implementá-lo. Às vezes chegavam erros urgentes que eram direcionados para os hotfixes "principais". As tarefas de sprint podem ser bastante volumosas. Quando algumas tarefas estavam prontas para o lançamento, outras ainda estavam em desenvolvimento. Como resultado, a equipe pode atrasar o sprint devido a uma tarefa.
- As paradas demoravam e eram de utilidade duvidosa . A equipe cresceu, os stand-ups foram realizados no Skype e, no início, nada trazia problemas. Começamos a suspeitar que algo estava errado quando os levantamentos começaram a aumentar por 20 a 30 minutos. Os presentes nem sempre entendiam o que os outros membros da equipe estavam fazendo.
Por algum tempo, convivemos com esses problemas, depois tentamos lutar.
- Eles reduziram os levantamentos com a introdução de regulamentos sobre seres humanos.
- Reduziram o número de presentes - apenas o líder da equipe ficou de pé.
- Tentei sprints semanais.
- Reduzido o número de tarefas no sprint.
Essas tentativas não deram o resultado esperado. Chegou-se a um entendimento de que mudanças radicais não podem ser dispensadas.
Aqui é necessário dizer algumas palavras sobre o produto.
Somos uma solução SaaS disponível 24/7. Além da parte visível para os usuários - a GUI -, também temos uma grande camada de lógica do sistema que funciona independentemente da hora do dia ou da situação política no país. Ou seja, o desenvolvimento e a atualização do serviço estão em andamento, sem parar.
Indo para Kanban
A primeira revolução em larga escala aconteceu quando percebemos: "Scrum não é adequado para nós".
Decidimos mudar para Kanban. Obviamente, não éramos a Toyota e não começamos a implementar a implementação completa. Portanto, "nosso Kanban" será diferente de "Seu Kanban".
Sprints e trabalho em equipe
Em poucas palavras sobre a nossa versão:
- Consideramos o sprint (uma funcionalidade completa) como a unidade de trabalho.
- Uma equipe para a tarefa foi coletada, dependendo da carga e das habilidades necessárias. Uma equipe geralmente tinha até 3 desenvolvedores e 1 controle de qualidade. Não havia equipes permanentes.
- O número de sprints simultâneos se tornou mais de um.
- Não havia quadro físico e outros atributos do Kanban; as tarefas foram realizadas através da adição ao Jira.
Nesse caso, a equipe teve que fazer um sprint do início ao fim. Isso também se aplicava à fase de teste: as mesmas pessoas que trabalhavam no sprint corrigiam os erros.
Resultado.- Com o atraso de grandes tarefas, as demais não sofreram, cujo desenvolvimento foi concluído.
- O número de problemas durante as implantações diminuiu - em um sprint, há menos tarefas heterogêneas.
Standups
Os levantamentos foram transformados - eles foram visitados por um representante de cada equipe que trabalhou em um sprint separado.
Resultado.- As paradas tornaram-se como paradas e novamente começamos a nos encaixar nos 10-15 minutos padrão.
Assim, fomos capazes de resolver problemas críticos.
Mas ... todo o iceberg começou a emergir de trás da ilha!
Depois de mudar para o Kanban, conseguimos uma equipe de front-end dedicada e havia mais funcionários na equipe de back-end e produto. A interação entre os departamentos ficou mais complicada - várias equipes poderiam trabalhar em um projeto.
Resolvemos alguns problemas, mas novos surgiram:
- Nem todo mundo participou de stand-ups - muitas vezes a equipe teve que recontar informações.
- Um controle de qualidade pode ter 2-3 sprints paralelos com equipes diferentes. Eu tive que mudar: lembre-se dos recursos do sprint e reimplante constantemente o código nos ambientes de teste.
- O controle de qualidade não estava totalmente envolvido no processo de trabalho em sprints. Freqüentemente, a tarefa chegava até eles no final do sprint e os requisitos eram estudados após o término do desenvolvimento.
- As equipes reunidas para o projeto e sua composição frequentemente mudavam. Uma equipe de dois desenvolvedores poderia trabalhar em 3 sprints simultaneamente: 2 sprints no teste mais 1 sprint atual.
- Foi difícil estimar o tempo de desenvolvimento. Não está claro quanto tempo o sprint inacabado anterior comerá.
Por algum tempo, vivemos de acordo com as novas regras e lutamos com novos desafios. Tentamos abordagens diferentes e enchemos muitos cones.
No final, novamente começamos a suspeitar que algo estava dando errado. Uma nova revolução a ser.
Divisão em equipes, novos stand-ups, introdução do Fireteam
Analisamos os processos desde o início da ideia até a implantação da implementação finalizada no prod. Vimos como as metodologias ágeis funcionam em outras empresas. Percebemos que nossas abordagens ao processo de desenvolvimento não eram tão ruins.
Não há necessidade de quebrar um sistema de trabalho, você precisa corrigir os momentos que causam dor.
Foi isso que mudamos durante o processo de desenvolvimento.
Sprints
Ainda operamos no conceito de "sprint". Sprint é um escopo de trabalho de "quase duas semanas" para a equipe.
Qual é a vantagem. O código não "vai mal" e chega ao produto sem atrasos significativos. Se a equipe fizer um sprint em duas semanas - é necessário tentar aumentá-lo para um mês.
O que pode ser melhorado. Muitas vezes perdemos a marca e os sprints estão um pouco atrasados. O tempo para trabalhar em alguns sprints é inicialmente difícil de avaliar (por exemplo, muita refatoração). Temos que resolver esse problema.
Divisão em equipes
Dividimos uma equipe grande em várias equipes menores. Cada um deles inclui 2 a 3 desenvolvedores e um controle de qualidade dedicado. Agora as equipes estão estáveis e não mudam de projeto para projeto. Às vezes, as pessoas alternam entre equipes para otimizar a lista ou adicionar o conhecimento necessário a uma equipe. A BA participa da equipe, mas ao mesmo tempo pode liderar 2-3 projetos.
Embora o resto ainda seja uma equipe)Ao mesmo tempo, toda a equipe trabalha em um projeto desde o início até sua conclusão. Um projeto pode consistir em vários sprints.
Qual é a vantagem.- As equipes estão na mesma sala. Antes disso, todo mundo estava sentado em departamentos.
- A equipe é incluída no trabalho do projeto do começo ao fim, o que reduz o fator de barramento.
- Os membros da equipe estão presentes em todos os eventos: retro, stand-ups, plenings. Todos os funcionários estão atualizados com as tarefas atuais.
- A equipe não trabalha mais nos sprints de outras pessoas. Agora tudo é nativo.
O que pode ser melhorado. Eu gostaria de apresentar completamente o BA na equipe. Isso é problemático porque o VA geralmente começa a trabalhar mais cedo do que o resto da equipe.
Trabalho em equipe
Uma equipe em trabalho não pode ter mais do que dois sprints: “o que ainda está em teste” e “o novo que veremos”. Como regra, após o final do desenvolvimento, todos, à medida que são liberados, começam a trabalhar em um novo sprint.
Qual é a vantagem. O trabalho em equipe tornou-se mais previsível, todos estão familiarizados com o código e podem dar suporte ao sprint durante os testes. É menos provável que os participantes alternem entre tarefas, e o processo de alternância agora é mais rápido.
O que pode ser melhorado. Idealmente, uma equipe deve ter apenas um sprint no trabalho. Mas, por enquanto, um mundo ideal não é o nosso mundo.
Fireteam
Cada equipe é eleita por uma semana. Este comando responde a todos os irritantes externos: chamadas de outros departamentos, comportamento anormal do serviço, hotfixes. Chamamos essa equipe de "Fireteam".
Qual é a vantagem. A semana do Fireteam não conta para a equipe no tempo de sprint. Entre o combate a incêndios, os funcionários podem se concentrar em suas tarefas:
- Refatorar.
- Complete a tarefa de sprint.
- Escreva documentação.
- Realize uma transferência de conhecimento com outras equipes.
Desvantagem. Na semana da equipe, a vida da equipe é muito agitada. Todos os departamentos amam e conhecem essas pessoas pessoalmente, principalmente o suporte técnico. Você precisa alternar constantemente entre diferentes tarefas: debitar, ler registros, serrar tarefas urgentes e apagar todos os incêndios. Tudo isso deve ser feito simultaneamente.
Standups
Introduzimos 2 tipos de stand-ups:
- Equipa Eles envolveram uma equipe que trabalha no projeto.
- Geral Eles são realizados uma vez por semana, os líderes de cada equipe participam deles.
Qual é a vantagem.- A equipe é informada sobre o estado do sprint.
- Os funcionários estão cientes do que outras equipes estão fazendo.
- Os stand-ups não se transformam em "atividades chatas para ler em um pedaço de papel alguns conjuntos de números". Todos os presentes compreendem o que está em jogo. Tornou-se mais fácil detectar áreas problemáticas no trabalho.
- As paradas demoram de 5 a 10 minutos.
Desvantagem. A equipe ainda carrega informações para a equipe.
Sumário
Assim, mudando gradualmente o processo, resolvemos a maioria dos problemas prementes:
- Reunimos equipes estáveis de 2 a 3 desenvolvedores e controle de qualidade. Agora, cada equipe não tem mais que 2 sprints, os participantes não trabalham nos projetos de outras pessoas.
- Havia uma equipe que processa mensagens de outros departamentos, responde a comportamentos anormais do serviço e hotfixes. Outras equipes não se distraem com essas tarefas.
- Agora a empresa possui 2 tipos de stand-ups: equipe e geral. Todos os funcionários são informados sobre o estado dos assuntos do sprint, e um stand-up leva de 5 a 10 minutos padrão.
Bem, estamos trabalhando.
