Em minha reflexão anterior, iniciei uma análise sobre hábitos inadequados que podem se manifestar em equipes Scrum, levando, inevitavelmente, a falhas nas entregas. Neste novo artigo, aprofundarei essa discussão, concentrando-me agora nos procedimentos funcionais intrínsecos à dinâmica da equipe.
Tais procedimentos são tão cruciais quanto a competência técnica do time. Mesmo que os membros da equipe possuam qualificações excepcionais para as tarefas designadas, ainda existem áreas propensas a comprometer seus esforços em busca da perfeição. E, em geral, isso não se deve a falhas individuais, mas sim às decisões de gestão de projetos e à capacidade de fornecer à equipe processos adequados, com objetivos claros e atividades previsíveis.
Equipes com Habilidades Altamente Segmentadas
Imagine um cenário onde a equipe seja composta por desenvolvedores altamente qualificados, capazes de trabalhar de forma independente e cumprir os prazos e entregas estabelecidos no sprint. Mesmo em um contexto tão idealizado (o que, convenhamos, é bem raro), a equipe terá dificuldades para lidar com o acúmulo de tarefas (backlog) em constante expansão, caso as habilidades sejam rigidamente divididas entre seus membros.
Exemplos Ilustrativos
- A equipe conta com apenas um ou dois engenheiros DevOps, capazes de realizar quaisquer ajustes nos pipelines automatizados ou gerenciar os serviços da plataforma, enquanto o restante da equipe desconhece esses processos. Nesses casos, a discussão de tais tarefas nas cerimônias Scrum, como os refinamentos, resultará em perda de tempo para a maior parte da equipe, que permanecerá alheia às discussões, enquanto o(s) desenvolvedor(es) DevOps não se sentirão engajados nas demais tarefas.
- A equipe tem apenas um especialista em banco de dados. Dependendo da complexidade e utilização das soluções de dados no sistema que estão desenvolvendo, esse profissional poderá ficar sobrecarregado com tarefas que não conseguirão ser concluídas em tempo hábil, considerando suas prioridades. E, o que é pior, outras tarefas ficarão paradas, pois dependem da disponibilização de dados por parte desse profissional.
- Em um produto voltado para o desenvolvimento de back-end, o único desenvolvedor de front-end é uma figura marginalizada. Nesses casos, a maioria das cerimônias Scrum se torna uma perda de tempo para esse profissional, já que seu conhecimento é restrito ao front-end, e o restante dos assuntos não lhe diz respeito.
Implicações
Em todos os exemplos acima, o resultado é o mesmo: pessoas desperdiçando tempo ou incapazes de lidar com a demanda. Elas impedem que o restante da equipe avance nas tarefas seguintes, ou reduzem a eficácia geral do time Scrum, devido ao tempo ocioso durante o sprint.
A equipe, no entanto, ainda mantém o mesmo número de desenvolvedores. Do ponto de vista externo, pode não ficar claro que certas tarefas não podem ser realizadas por alguns membros, em virtude de serem muito específicas em termos de habilidades. Eles não podem auxiliar os colegas, mesmo que tenham capacidade e disponibilidade, e as prioridades das tarefas assim o permitam.
Torna-se desafiador para o Product Owner (PO) organizar um conteúdo de sprint relevante para a equipe, pois o PO precisa considerar quantas pessoas podem trabalhar em cada tarefa e se diversas tarefas similares forem trazidas para o sprint ao mesmo tempo, a capacidade da equipe será ultrapassada, mesmo que haja membros capazes de realizar as tarefas, mas que não possuem as habilidades necessárias para iniciá-las.
A Solução para o Dilema
Esse é um dilema que precisa ser enfrentado, e os gerentes de projeto devem estar cientes das alternativas disponíveis. Especificamente, a escolha entre:
- Ter diversos desenvolvedores full-stack, capazes de atuar em uma gama mais ampla de tarefas, mas sem serem especialistas em muitos assuntos. Nesse caso, o time pode ser amplo, mas não aprofundado. A entrega pode ser mais rápida, mas a qualidade pode ser comprometida.
- Ter especialistas em cada tecnologia, aceitando as limitações inerentes e direcionando o conteúdo do sprint de forma mais adequada. Nesse caso, o time pode se aprofundar e desenvolver excelentes tarefas, mas estas precisarão ser abordadas sequencialmente, demandando mais tempo para a entrega.
Product Owner Ineficaz
Este problema não se encaixa na definição de “problema de processo” em si, mas o abordo aqui por entender que a criação de tarefas sólidas pode ser considerada um processo que a equipe precisa ter de forma sólida e consistente com o time de desenvolvimento.
Quando me refiro a um PO ineficaz, não estou questionando seu domínio sobre o produto, mas sim a capacidade de apresentar tarefas que sejam compreensíveis para os desenvolvedores e que façam sentido na perspectiva do roadmap do produto. Ambos são essenciais para o sucesso de uma equipe Scrum.
Se as tarefas carecerem de detalhes que permitam que os desenvolvedores compreendam claramente o objetivo, valor funcional ou expectativas técnicas, duas situações podem ocorrer:
- Os desenvolvedores produzirão algo diferente do que o PO desejava. Essa divergência pode ser difícil de identificar durante o sprint, já que, em geral, o PO não tem condições de acompanhar o progresso das tarefas em detalhes. O PO espera que as coisas aconteçam de forma mágica.
- Os desenvolvedores gastarão tempo discutindo e tentando esclarecer as tarefas, ao invés de iniciá-las. Isso resulta em chamadas adicionais, discussões repetitivas e adiamento do trabalho para o fim do sprint. As estimativas originais perdem a precisão, as tarefas não são concluídas no sprint e são transferidas para os sprints seguintes, repetindo-se em outros sprints.
Momento de Reflexão
Embora seja difícil admitir, o PO precisa reservar tempo para refletir, analisar as tarefas no backlog e compará-las com o roadmap do produto, para verificar se ainda existe coerência entre os dois, ou se o roadmap sequer existe. Caso contrário, esse é o primeiro problema a ser resolvido. Às vezes, a solução envolve admitir que o PO está muito distante da equipe e dos objetivos do projeto.
Nesse cenário, a função do PO na equipe precisa ser reavaliada. Como alternativa, a inclusão de um analista de negócios, focado no conteúdo da equipe (e não nos aspectos de negócio, que já são responsabilidade do PO) pode ser uma opção válida, mesmo que isso signifique um aumento nos custos da equipe.
Processos de Teste Sem Cronograma Definido
E se as atividades de teste não estiverem vinculadas a um cronograma específico dentro de um sprint Scrum?
À primeira vista, isso pode parecer positivo para uma equipe ágil ou Scrum. A flexibilidade é sempre bem-vinda, e soa bem quando mencionada.
Minha experiência mostra que a liberdade excessiva causa mais caos do que flexibilidade. Isso não significa que a solução seja criar “cascatas dentro do sprint”, com fases de testes específicas após a conclusão do desenvolvimento. Essa abordagem está equivocada. Para saber mais, consulte meus artigos sobre estratégia de testes Scrum e ciclo de vida de testes ágeis.
A flexibilidade ainda pode existir, permitindo que a equipe defina o cronograma de testes mais adequado, levando em conta as propriedades do produto sendo entregue. Existem dois objetivos principais que precisam ser atingidos:
- Minimizar a interrupção do desenvolvimento durante os testes.
- Garantir que os testes sejam confiáveis, consistentes e previsíveis.
Se esses requisitos forem cumpridos, a equipe se adaptará naturalmente ao processo, e o cronograma de entrega não será afetado por atividades de teste prolongadas e não planejadas.
O que mais importa é a entrega confiável e previsível do sprint, o que me leva ao próximo ponto deste artigo.
Processo de Release Indefinido
Esse ponto pode parecer óbvio para qualquer equipe Scrum, mas, curiosamente, é um dos processos mais negligenciados.
Muitas vezes, a equipe Scrum apenas afirma que o release será feito após cada sprint, mas não há um processo definido por trás dessa afirmação. A consequência é que surgirão atividades caóticas e imprevisíveis durante o período de release. De repente, todos estarão envolvidos em “tarefas de release”, e ninguém conseguirá se concentrar no desenvolvimento de novas histórias. As métricas do sprint ficam comprometidas, e o release parece aleatório e imprevisível, especialmente para o cliente.
As pessoas estão tão focadas no backlog, conteúdo do sprint, desenvolvimento, testes e apresentação de resultados que se esquecem que, assim que tudo isso terminar, o próximo sprint já terá começado, e elas já estarão perdendo tempo.
Quando Fazer o Release?
Afinal, quando a equipe deve fazer o release para produção? Essa é a pergunta mais importante.
A resposta está no processo, se ele existir. Dependendo de:
- Complexidade do conteúdo produzido em cada sprint,
- Duração do sprint,
- Número de componentes afetados no sistema,
- Número de usuários afetados pelas alterações,
um processo de release consistente deve ser estabelecido e seguido. As regras exatas desse processo podem ser flexíveis, mas, assim como nas atividades de teste, a equipe precisa torná-lo um hábito sólido, previsível e agendado para datas específicas.
Possíveis Abordagens
Alguns exemplos de processos podem ser os seguintes:
- Concluir os testes dos recursos do sprint atual durante o sprint seguinte, e lançar o conteúdo no final desse sprint (assim que os testes forem concluídos). Isso significa que cada release não terá nenhum conteúdo do sprint mais recente, mas incluirá histórias dos dois sprints anteriores.
- O último sprint antes do release é sempre dedicado a testar o conteúdo dos dois sprints anteriores.
- O desenvolvimento não precisa parar durante o “sprint de teste”. Apenas o conteúdo desenvolvido nesse sprint não será incluído no próximo release.
- Se houver testes automatizados suficientes, fazer o release ao final de cada sprint. Nesse caso, é necessário um processo muito rigoroso, com pessoas focadas 100% nessas atividades por alguns dias. Isso não deve afetar o restante da equipe de desenvolvimento.
- Também é possível optar por fazer um release por mês, ou a cada “N” meses, principalmente se isso for aceitável para os usuários finais. Isso aumentará o esforço de testes para cada sprint, mas resultará em menos atividades repetitivas. Como resultado, a equipe pode criar mais recursos entre os releases, mesmo que eles cheguem à produção em uma cadência mais lenta.
Como já foi dito, não importa qual processo será escolhido, mas sim a forma como a equipe irá adotá-lo e transformá-lo em um hábito.
Você também pode consultar este guia sobre o processo e as práticas de gerenciamento de versões.