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.

PlanejamentoSprintAtividades

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.

3 comentários sobre “Nada testável até 1 dia antes do fim da sprint

  1. Muito bom Diraci!

    Em muitas equipes temos uma pessoa específica e especialista de qualidade.
    Nestas equipes eu também acredito que o grande segredo do sucesso da Sprint esteja em utilizar o melhor possível o tempo deste especialista.

    Concordo que a equipe inteira precisa ter claro que fechar pacotes completos é importante para que a Entrega da Sprint não seja impactada.

    Também vale a ressalva que o Burndown nestes casos pode causar uma ilusão de prazo adequado mas que o ideal é olhar o quanto a capacidade do especialista de qualidade para saber se a Sprint está no prazo.

    Curtir

  2. Excelente Post Diraci!
    É um ponto complicado de se administrar na metodologia Ágil. Já participei de um projeto bem sucedido onde havia um membro do time específico para testes, e na Planning desse projeto prevíamos os dois últimos dias da Sprint sem atividades de construção, apenas correções, caso houvessem. Dessa forma, se no penúltimo dia da Sprint, as estórias não estivessem liberadas para testes, era identificado no burndown e o alerta já era levantado na própria daily meeting.
    Por isso, no Scrum, muitos defendem times multi-diciplinares, onde os membros não possuem um papel específico no time, porém sabemos que isso é muito difícil se aplicar nas equipes. Algumas Startups estão implementando isso com sucesso.
    Abraços!

    Curtido por 1 pessoa

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s