Nada testável até 1 dia antes do fim da sprint

Estes dias caímos em uma discussão sobre como planejar de forma efetiva e sadia uma sprint de trabalho, pois havia a dúvida se deveríamos ou não levar com tarefas de desenvolvimento até o último dia. E como ficariam os testes funcionais nesta situação? Daria tempo?

Utilizarei este post para refletir sobre alguns aspectos da metodologia ágil e quais seriam as principais ações a tomar nestas circunstâncias.

Primeiramente, importantíssimo revisar os valores do ágil, onde temos entrega contínua de software funcionando e de valor, colaboração, times com autogerenciamento. Precisamos estar alinhados com todos eles para que possamos na verdade, em conjunto, definirmos desde o primeiro dia da sprint como será a estratégia. Não basta querer entregar por iterações curtas (sprint) se mantemos as nossas cabeças no modelo tradicional e sequencial de atividades onde há a transferência de pacotinhos de entregáveis entre os especialistas, do tipo, do analista passa para o desenvolvedor, do desenvolvedor para o testador.

Mike Cohn apresenta exatamente esta situação em seu livro Desenvolvimento de Software com Scrum (2011), e indica que a transferência de partes extremamente grandes possuem a tendência de não serem concluídas e com isto não termos itens prontos ao final da sprint.

Este fato é impressionante, pois exatamente o que ele apresenta nesta seção do livro ocorreu durante um dos projetos que participo no momento. Durante a retrospectiva apareceu um card de melhoria com a seguinte menção “Nada testável até 1 dia antes do fim da sprint”.

Uma forma de combatermos esta situação é expor através de um quadro de atividades os itens de backlog e os profissionais que trabalham nele, para que possam visualizar uma melhor iteração. O quadro abaixo foi criado para entender a relação no desenvolvimento do nosso produto a partir do exemplo extraído do livro.

No exemplo, trabalho com o desenvolvimento da história de usuário em que é definida a forma de pagamento dos produtos em um e-commerce. Com a formação deste time para atender esta necessidade, todos são envolvidos para a discussão, em seguida já são direcionados para as atividades de especificar estes critérios e testes, bem como projetar e testar em unidade. Em paralelo a estas atividades, já conseguimos também envolver a automação funcional da primeira história e a investigação e prototipação da história seguinte a ser atendida pelo time junto da sequência da construção. A partir disto, temos iterações para atender as próximas histórias, gerando ciclos mais curtos, com valor e itens concluídos que podem ser entregues, podendo assim atingir uma cadência e manter ritmos de entregas constantes.

Resumindo, organize sua equipe focada em terminar o seu item de backlog, com todos os itens da definição de pronto concluídos, para depois poder assumir atividades da próxima.

Importante o time conhecer e entender todos os tipos de testes que são executados durante a definição e desenvolvimento da história, para que não se leve a sensação de que não são realizados testes até o momento no qual o desenvolvedor termina a codificação e repassa para o especialista em testes funcionais. Isto fica visível também no quadro acima, os diferentes tipos de testes a serem realizados.

Utilizo também o gráfico de “Cumulative Flow”, onde podemos visualizar a quantidade de trabalho estocado em uma etapa do processo. Com ele temos a noção exata se estamos levando muito tempo parado com o pacote em um determinado status e não evolui a fim de ser entregue até o final da sprint.

Outra ação a ser tomada e que pode contribuir para o bom fechamento da sprint, é incluir no planejamento da sprint que o último dia não terá atividades de construção e será utilizado para atividades de publicação da versão, resolver débitos técnicos e testes integrados.

Estas são as dicas que me atendem em alguns cenários, podemos ter outras realidades e ações. Experimente, troque ideias com o time e achem em conjunto uma forma adequada de planejar e acompanhar sua demanda.