O ritual prescrito do Scrum é relativamente simples. Sua implementação, contudo, exige a transposição de barreiras culturais (por exemplo, na forma como os budgets e os controles de escopo são tratados, na convivência com o autogerenciamento etc.), o equacionamento de alguns detalhes e o enfrentamento de problemas que a teoria não explica.
Este artigo tratará do segundo bloco de questões, em especial na carga de um sprint (alocação de stories para um sprint, de forma a fechar uma meta para o mesmo).
Vamos então a pontos da vida real com os quais talvez você já tenha se deparado nas sprint plannings:
1 – Sobrou um espaço na carga do sprint – o que fazer?
Digamos que a capacidade nominal do sprint em planejamento seja de 100 pontos (100 story points, 100 homens-hora… enfim, a unidade que estiver sendo utilizada) e que conseguimos carregar stories que totalizam até o momento 95 pontos. Não há no backlog nenhuma outra story pronta que tenha peso de 5 pontos – a menorzinha tem, digamos, 15 pontos. E agora?
Uma alternativa (tentadora e ruim) é fechar o sprint com 95 pontos mesmo, para a equipe ter uma “folguinha de segurança”. Veja bem: o objetivo de um sprint deve ser o de entregar o máximo valor, o que não combina com este tipo de mindset.
Outra opção é carregar também a story de 15 pontos, configurando então uma alocação de 110 pontos (no nosso exemplo, 10% acima da velocidade esperada para o sprint) e colocar isto como um “desafio” para a equipe. Temos aqui uma situação controversa porque por um lado é interessante a equipe se comprometer com a melhoria de seu desempenho mas o sprint carregado acima da capacidade viola o princípio do sustainable pace (“cadência sustentável”) nascido lá no XP e bastante coerente com os valores do ágil.
Se de qualquer forma embarcarmos nesta de fazer a carga acima da capacidade nominal, duas coisas podem acontecer e dissolver o “espírito de desafio”: a meta do sprint ficar mais mole (“se entregarmos a última story de 15 pontos, será lucro, pois ela está na meta mas não está”) ou então a equipe deliberadamente declarar que a story de 15 pontos não está na meta “oficial” e que “será feito o possível para implementá-la, mas sem nenhum compromisso”.
Outra possibilidade é o(a) Product Owner pulverizar mais as user stories de forma a gerar uma menor que caiba no espaço que falta preencher no sprint. No exemplo citado, se for possível quebrar a user story de 15 pontos em três de 5 pontos, uma destas poderia ser carregada no sprint fechando os 100. Esta seria a melhor saída, se for possível, mas sem deixar de observar que a pulverização deve dar origem a “sub-stories” com entregas claras e validáveis (ponto melhor explorado no item 2 mais abaixo).
Diante da impossibilidade de pulverizar stories, penso que o melhor (ou menos ruim) a fazer é de fato carregar o sprint (um pouco) acima da capacidade e a equipe assumir o desafio. Trabalhando com stories pequenas (como manda a boa prática) a sobrecarga não será tão grande. Além disto, há uma ideia no OKR (Objective and Key Results) que diz que “se uma meta foi 100% atingida, então não estava suficientemente digna”. Claro que a forma como o não atingimento da meta de um sprint é encarado na organização conta na adoção ou não destes desafios com a devida tranquilidade.
2 – Pulverização em itens não validáveis pelo(a) PO
Trabalhar com stories pequenas é fundamental, mas é preciso lembrar que toda story tem de ter uma entrega clara associada, validável pelo(a) PO. Uma vez eu vi, em nome do esforço de pulverização, um Product Backlog ser quebrado em vários webservices, bem atomizados, mas a PO não conseguia validar um a um porque seus funcionamentos isolados não faziam sentido como um cenário de negócio mínimo que a PO era capaz de ver, sentir e validar.
Se você é um(a) PO e não sabe o que é um webservice, não se preocupe com isto. Talvez seja melhor nem saber.
Uma user story só pode ser quebrada se cada pedaço der origem a algo concreto, palpável e portanto validável (uma tela, uma janela, um cálculo, um relatório, uma saída completa qualquer, embora pequena).
3 – Sprints com equipes multidisciplinares (em vez de multifuncionais)
Uma equipe multifuncional é aquela onde cada membro consegue mais ou menos exercer qualquer papel demandado. Por exemplo, todos conseguem codificar, mexer no banco de dados e testar, ainda que possa haver membros melhores neste ou naquele tipo de atividade.
Já uma equipe multidisciplinar é aquela onde todos os conhecimentos necessários para o desenvolvimento estão presentes na equipe, mas há pessoas que só conseguem realizar um tipo de atividade. Isto ocorre, por exemplo, quando pessoas da área usuária participam das equipes como testadores (e só como testadores no caso, pois os usuários não sabem programar).
A ideia de usuários e desenvolvedores trabalhando juntos é ótima e a equipe multidisciplinar citada acima é uma maneira interessante de conseguir isto. Todavia, na hora de carregar o sprint, isto gera uma complicação, pois o volume de trabalho alocado ao sprint tem de respeitar a capacidade de programação e a capacidade de testes (há duas chances de surgir um gargalo). Se a equipe for multifuncional, quando o teste começar a “engargalar” as entregas, os membros podem se concentrar nos testes, da mesma maneira que todos podem focar em programação quando não houver nada para testar. No caso de equipes multidisciplinares, não há esta flexibilidade de intercâmbio de papéis (o usuário testador não vai codificar).
Assim sendo, no caso de equipes multidisciplinares, a carga do sprint deve ser feita observando-se estimativas diferentes para cada competência e considerando as limitações de disponibilidade de pessoas de cada uma delas. Ou seja, o risco de erros de estimativa e ociosidades / sobrecargas internas localizadas aumentam.
4 – Ih, faltaram stories – e agora?
Muitos Product Owners não têm dedicação exclusiva ao papel e elaboram user stories “quando dá”, em paralelo a suas atividades operacionais na área de negócio. Há o risco então deste PO “não ter braço” para manter os sprints devidamente abastecidos com stories.
Em um sprint planning, pode ocorrer então de faltarem stories. No nosso exemplo de capacidade nominal de 100 pontos, digamos que só foi possível carregar 50. Mexer na duração do sprint não convém, pois isto viola o princípio de timebox e quebra totalmente a cadência dos trabalhos. Algo que acontece na prática é o seguinte: o sprint começa com as stories que estão disponíveis e depois, ao longo do sprint (ao final da primeira semana, em um sprint quinzenal, por exemplo) o(a) PO entrega mais stories a tempo.
Claro que uma situação como esta não é ideal, mas pelo menos não quebra o fluxo…
5 – Necessidade de testes de regressão – onde encaixo isto?
Um teste de regressão pode ser algo necessário e consumir um esforço considerável. Uma boa prática, sempre que possível, seria automatizar tais testes, mas enquanto isto não ocorrer é necessário ver como endereçar tal trabalho nos sprints.
Uma ideia seria criar um item no Product Backlog (com correspondência unívoca em um Sprint Backlog) relativo ao teste de regressão em pauta. Já vi situações onde um sprint inteiro foi dedicado ao teste – algo como um sprint de “purga de dívida técnica”.
6 – A questão do teste das últimas stories
No caso lá das equipes multidisciplinares (não multifuncionais), pode ocorrer o seguinte fenômeno: as últimas stories terminaram de ser implementadas, os testadores usuários entraram então em ação e, para que houvesse tempo de os testes serem feitos, os desenvolvedores concluíram seus trabalhos antes do final do sprint. Como se trata das últimas stories, eles ficariam parados durante os testes…
Numa situação como esta, o problema está na falta de intercambialidade entre as tarefas (carência de multifuncionalidade). Esta questão pode ser minimizada se, por exemplo, desenvolvedores assumirem algumas atividades de testes, desta forma tornando mais elásticos os esforços dedicados de construção e testes. Com a equipe de testes reforçada, poderia haver uma força-tarefa e testar bastante coisa entregue no último dia do sprint, minimizando então o efeito de termos desenvolvedores parados.
Em uma equipe multifuncional, o esforço de teste está “misturado” na estimativa dada para cada story, de tal forma que o problema de gargalo não se evidencia.
Como vemos neste breve apanhado, surgem na prática alguns desafios que exigem a experimentação de variadas táticas de contorno. Aí estão excelentes temas para discutir em retrospectivas, onde ideias melhores do que as apresentadas podem surgir, com certeza.
Eu nem precisaria dizer, mas nunca deixem de fazer boas retrospectivas, amigos!
Roberto Pina Rizzo
MSc, PMP, PMI-ACP, SAFe Agilist
Lean Agile Change Agent / Gestor Senior de TI
