No meu artigo anterior, comecei a discussão sobre hábitos mal desenvolvidos dentro de um time scrum que acabarão levando (mais cedo ou mais tarde) a uma falha na entrega. Neste artigo, gostaria de expandir este tópico mais uma vez e focar agora nos processos funcionais dentro da equipe.
Esses são tão importantes quanto a excelência técnica da equipe. Mesmo que as pessoas lá dentro sejam superqualificadas para o trabalho que estão prestes a realizar, ainda há áreas que podem arruinar seu esforço pela perfeição. E não será tanto culpa deles, pois será responsabilidade direta das decisões de gerenciamento de projeto e sua capacidade de servir a equipe com processos adequados para apoiar a equipe com intenções claras e atividades previsíveis.
últimas postagens
Equipe altamente segregada com habilidades distintas
Imagine que a equipe tenha desenvolvedores habilidosos, perfeitamente independentes e com capacidade de cumprir suas promessas e entregar o conteúdo do sprint acordado antes do final do sprint. Mesmo em um cenário tão perfeito (o que é altamente improvável que aconteça de qualquer maneira), a equipe terá problemas para acompanhar os recursos do backlog (em constante crescimento) se as habilidades forem estritamente segregadas entre os membros da equipe.
Poucos exemplos
- A equipe tem 1 ou 2 engenheiros de DevOps capazes de fazer qualquer alteração nos pipelines automatizados ou cuidar dos serviços dentro da plataforma, mas o restante da equipe não tem ideia dessas coisas. Em seguida, discutir essas histórias em cerimônias scrum como refinamentos levará a perda de tempo para a maioria da equipe, aguardando a reunião sem qualquer participação e vice-versa – o desenvolvedor DevOps não terá interesse no restante das histórias orientadas à funcionalidade e o tempo da reunião também será desperdiçado.
- Há um único especialista em banco de dados para toda a equipe. Dependendo da complexidade e do uso das soluções de dados no sistema que a equipe está desenvolvendo, essa pessoa pode estar constantemente sobrecarregada com histórias que não tem chance de concluir em breve, especialmente ao considerar suas prioridades. Pior ainda, outras histórias também terão que esperar, pois dependem da fonte de dados fornecida pelas histórias do banco de dados.
- Quando um determinado produto é principalmente orientado para o desenvolvimento de back-end, o único desenvolvedor de front-end está lá apenas por precaução (porque, de tempos em tempos, algumas pequenas alterações são necessárias até mesmo no aplicativo de interface do usuário). Nesse caso, novamente, a maioria das cerimônias do scrum é uma perda de tempo para esse membro da equipe, pois seu conhecimento é limitado apenas ao front end, e nada mais importa.
Onde conclui
Em qualquer um dos casos acima, o resultado é que as pessoas estão perdendo seu tempo ou, alternativamente, são incapazes de acompanhar a demanda atrasada. Eles estão impedindo que o restante da equipe comece a trabalhar nas próximas histórias ou estão efetivamente diminuindo a eficácia geral da equipe scrum porque há muito tempo que não é utilizado no sprint.
A equipe, porém, ainda conta com esse número de desenvolvedores. Do lado de fora, não é visível (mesmo não querendo ser exposto) que as pessoas dentro da equipe não são capazes de assumir algumas histórias apenas porque são muito voltadas para algum conjunto de habilidades específicas. Portanto, eles não podem ajudar os outros membros da equipe com as histórias, mesmo que sua capacidade permita isso, e as prioridades das histórias também o favoreçam.
É até difícil para o proprietário do produto compor algum conteúdo de sprint significativo para a equipe, pois o proprietário do produto deve sempre levar em consideração quantas pessoas podem trabalhar em cada história e se mais histórias semelhantes são trazidas para o sprint ao mesmo tempo , no final das contas, a capacidade da equipe é estourada, mesmo que haja de fato pessoas que poderiam trabalhar nessas histórias, mas não têm as habilidades necessárias para começar com elas.
Resolvendo o Dilema
É um dilema a ser resolvido, e os gerentes de projeto devem estar cientes do caminho a seguir. Especificamente, uma escolha entre:
- Ter muitos desenvolvedores full-stack capazes de trabalhar em um conteúdo mais amplo, mas não realmente especialistas em muitos tópicos. Assim, eles podem ser largos, mas não profundos. Então a entrega pode progredir rapidamente, mas a qualidade pode ser prejudicada.
- Tendo especialistas dedicados para cada tecnologia, mas aceitando a limitação e trabalhando mais no conteúdo de impressão mais adequado. Então as pessoas podem ir fundo e construir ótimas histórias, mas as histórias precisarão ser abordadas sequencialmente, levando mais tempo para serem entregues.
Dono do produto fraco
Este não é necessariamente um “problema de processo” por definição, mas eu trato assim justamente porque a criação de histórias sólidas pode ser entendida como um processo que o time deve querer ter sólido e compatível com o time de desenvolvimento.
O que quero dizer com fraco não precisa estar se referindo à propriedade do conhecimento de uma pessoa, mas sim à capacidade do proprietário do produto de servir às histórias da equipe que os desenvolvedores podem entender e que fazem algum sentido claro da perspectiva do roteiro do produto. Ambos são muito importantes para uma equipe scrum de sucesso.
Se faltam detalhes nas histórias para que os desenvolvedores possam entender claramente o propósito, o valor funcional ou as expectativas técnicas, basicamente dois cenários podem acontecer:
- Os desenvolvedores criarão algo diferente do que o proprietário do produto realmente queria. É até difícil de entender durante o próprio sprint, porque principalmente o proprietário do produto não teve a capacidade de acompanhar o progresso das histórias em um nível tão detalhado e, principalmente, o PO apenas espera que a coisa aconteça (magicamente).
- Os desenvolvedores gastarão muito tempo esclarecendo as histórias e discutindo-as continuamente, em vez de começar a construí-las. Isso envolve muitas chamadas adicionais, acordos repetidos e adiamento do trabalho para a fase final do sprint. Chega a um ponto em que as estimativas originais para as histórias não podem mais ser consideradas precisas, e as histórias não podem ser fechadas dentro do sprint e estão rolando para os próximos sprints. No pior caso, a situação se repete nos sprints subsequentes.
Tempo para auto-reflexão
Geralmente é difícil admitir, mas o proprietário do produto deve encontrar tempo para refletir, olhar para as histórias do backlog criadas e, eventualmente, compará-las com a visão do roadmap do produto se ainda houver algum vínculo sensato entre os dois – se houver algum roadmap de forma alguma. Se não, essa é a primeira coisa a resolver. Às vezes, a solução é admitir que o product owner está muito longe da equipe e muito longe do próprio alvo.
Nesse caso, a parte do proprietário do produto da equipe deve ser resolvida. No mínimo, trazer para a equipe um analista de negócios sólido e orientado mais para o conteúdo da equipe do que para o conteúdo do negócio (para isso, já temos um product owner neste caso) pode ser uma opção válida, mesmo pelo preço de aumento dos custos totais da equipe.
Processos de teste sem cronograma fixo
E se as atividades de teste não estiverem restritas a um cronograma concreto dentro de um sprint scrum?
À primeira vista, isso pode parecer algo bom que queremos para uma equipe ágil/scrum. A flexibilidade é sempre bem-vinda e soa bem quando apresentada ao ar livre.
Minha experiência mostra que o resultado dessa liberdade é mais caos do que flexibilidade. Isso não significa que a solução para isso deva criar “cachoeiras dentro do sprint” com fases de teste dedicadas seguidas logo após o término do desenvolvimento. Esta não é de forma alguma a abordagem correta neste caso. Você pode ler mais sobre isso em minhas postagens sobre estratégia de teste scrum e ciclo de vida de teste ágil.
Ainda podemos permitir alguma flexibilidade e escolher o cronograma de teste que pareça mais apropriado para a equipe de desenvolvimento atual e as propriedades do produto que a equipe está entregando. Existem, no entanto, dois objetivos principais que devem ser alcançados com esta escolha:
Se essas condições forem atendidas, a equipe se adaptará naturalmente ao processo de adaptação e o cronograma de entrega não será afetado por atividades de teste prolongadas não planejadas.
No final, o que mais importa é o lançamento confiável e previsível do sprint, o que me leva ao último ponto deste blog.
Processo de Liberação Indefinido
Agora, isso é uma coisa tão óbvia para cada equipe scrum. No entanto, curiosamente, também costuma ser um dos processos mais subestimados.
Muitas vezes, uma equipe scrum apenas diz que o lançamento será após cada sprint, mas não é respaldado por um processo sólido. O que acontece então, na realidade, é que muitas atividades caóticas e imprevisíveis surgirão durante o período de liberação. De repente, todas as pessoas estão ocupadas com “tarefas de lançamento” e ninguém consegue se concentrar em continuar desenvolvendo novas histórias de sprint. As métricas do Sprint estão desativadas e o lançamento parece uma atividade aleatória e imprevisível do ponto de vista da terceira pessoa (geralmente o cliente).
As pessoas estão tão focadas no backlog, no conteúdo do sprint, no desenvolvimento, no teste e, finalmente, na apresentação dos resultados que se esquecem de que, uma vez feito tudo isso, o próximo sprint já está em andamento e eles já estão perdendo tempo.
Procurando um bom momento para lançar
Então, quando exatamente a equipe deve fazer o lançamento real para produção? A única coisa importante que importa no final.
A resposta a essa pergunta está no processo, supondo que você tenha uma. Dependendo:
- a complexidade do conteúdo que a equipe está produzindo nos sprints,
- duração de um sprint,
- número de componentes afetados no sistema
- o número de pessoas usando e solicitando as alterações,
um processo de liberação repetida deve ser estabelecido e seguido daqui para frente. As regras exatas do processo podem ser novamente flexíveis na definição. Mas, como acontece com as atividades de teste, torná-lo um hábito sólido, previsível e programado para dias concretos no futuro, torna-o algo em que confiar e consultar.
Opções para escolher
As possíveis formas de tal processo podem ser qualquer uma das seguintes ou outras:
- Conclua o teste dos recursos do sprint atual durante o sprint seguinte e libere o conteúdo no final desse sprint (assim que o teste for concluído). Isso significa que cada versão não terá nenhum conteúdo do último sprint, mas conterá histórias dos 2 sprints anteriores.
- O último sprint antes do lançamento é sempre dedicado a testar o conteúdo dos dois sprints anteriores.
- Isso não significa que o desenvolvimento durante o “testing sprint” será interrompido; ele apenas diz que o conteúdo desenvolvido naquele sprint de teste ainda não será incluído no próximo lançamento.
- Se já houver atividades de teste automatizado suficientes, esforce-se para fazer o lançamento após o final de cada sprint. Então este deve ser um processo muito rigoroso com pessoas dedicadas focando 100% nesses poucos dias. Isso ainda não deve afetar o restante da equipe de desenvolvimento de forma alguma.
- Você também pode optar por liberar uma vez por mês ou uma vez a cada N meses, principalmente se isso for aceitável do ponto de vista dos usuários finais. Isso aumentará o esforço do lado do teste para cada sprint (já que o conteúdo será maior para cada versão). Mas, por outro lado, significará uma menor quantidade de atividades repetidas ao longo do tempo, o que, neste caso, pode trazer benefícios para a equipe. Como resultado, pode permitir que a equipe crie mais novos recursos entre os lançamentos, apesar do fato de que os recursos realmente chegarão à produção com uma cadência mais lenta.
Mas, como já foi dito algumas vezes antes, não é tão importante qual desses processos será escolhido. É muito mais importante quão bem a equipe irá aderir a esse processo e torná-lo um hábito duradouro.
Você também pode ler este guia sobre o processo e as práticas de gerenciamento de versões.