Como podemos planejar sprints que acomodem, com sucesso, tanto histórias de desenvolvimento quanto de pesquisa aplicada?
Há vários meses, publiquei uma adaptação do guia do SCRUM. Eu estava planejando dar continuidade com uma série de posts compartilhando algumas dicas e outras experiências que aprendi nos últimos 4 anos usando e desenvolvendo essa metodologia. No entanto, durante esse tempo, outras coisas aconteceram na minha vida; falei sobre isso na HackTown 2024, em Santa Rita do Sapucaí, MG, e acabei não tendo tempo de continuar escrevendo sobre o assunto. Agora é a hora de continuar!
Neste post, vou compartilhar algumas experiências sobre o que aprendi ao planejar sprints em projetos de pesquisa que tinham histórias tanto de desenvolvimento quanto de pesquisa.
Sprint Planning
Embora o guia comece pelo Sprint, aqui vou começar falando sobre a Planning: a Sprint Planning é o processo em que definimos o trabalho a ser realizado durante um Sprint. Esse é um plano colaborativo, construído com desenvolvedores, pesquisadores e outros stakeholders.
Geralmente começamos olhando o Sprint Backlog e selecionando possíveis histórias de Pesquisa e Desenvolvimento para adicionar ao sprint. No entanto, há alguns tópicos interessantes que devem ser abordados durante o planejamento, como:
Qual é o valor deste Sprint?
Neste ponto, devemos identificar e definir o que é valioso neste sprint? Qual é o objetivo que o grupo está tentando alcançar durante esse sprint específico. Com isso, o time define o Sprint Goal, que será usado na próxima pergunta.
O que pode ser feito neste Sprint?
Essa talvez seja a principal pergunta que todos têm: quais histórias de pesquisa e desenvolvimento conseguimos encaixar neste sprint para alcançar o Sprint Goal definido?
Esse processo é ainda mais difícil para um time novo, que não tem experiência prévia trabalhando junto e, portanto, não sabe qual é o desempenho real do time.
Existem várias formas de definir esforço, tempo ou pontos de história para cada história. E não existe um método perfeito. No entanto, o maior problema aqui é que, geralmente, no desenvolvimento de software, por exemplo, já sabemos, por conhecimento prévio, qual é o esforço de uma tarefa: sabemos que uma nova página vai levar X horas para ser desenhada, Y horas para ser desenvolvida e Z horas para ser testada e validada; em pesquisa, isso não é tão claro.
Em um cenário de pesquisa, podemos ter uma tarefa que pede uma revisão de literatura dos trabalhos mais recentes em um tópico específico (um exemplo que muitos de nós podemos enfrentar, já que é bastante comum). Essa é uma tarefa complicada, porque é difícil saber quanto tempo vamos precisar para pesquisar um novo tópico, já que não sabemos quantos artigos e livros podemos encontrar sobre o assunto; por isso, é bem fácil superestimar, ou, de forma mais realista, subestimar o esforço real necessário.
Nesses e em outros casos em que é difícil determinar o esforço real, ou em que o esforço não é claro, ou seja, em que poderíamos acabar ficando um ou 6 meses no mesmo assunto, precisamos definir pontos de parada e outros parâmetros que limitem nossa pesquisa: obviamente podemos definir o período em que vamos pesquisar a literatura, mas, mais do que isso, devemos definir a quantidade de tempo que estamos confortáveis em investir em uma linha de pesquisa para determinar se ela é relevante ou não.
Mas o que isso significa? Significa que talvez uma linha de pesquisa possa nos trazer resultados úteis, mas o esforço para reunir informações a ponto de realmente nos beneficiarmos dos resultados pode ser grande demais para o tempo disponível no projeto em questão. Isso pode acontecer porque a curva de aprendizado é muito íngreme, ou porque essa linha de pesquisa é complexa demais, ou por outro motivo, e talvez precisemos abandoná-la e buscar uma alternativa mais viável.
Portanto, nesses casos, durante o planejamento, não devemos definir o esforço que sabemos ser necessário para concluir a revisão de literatura, mas sim, quanto esforço o time pode gastar nessa tarefa. Isso pode até levar mais de um sprint, o que não é problema, porque, de qualquer forma, podemos ter resultados preliminares para a Sprint Review. Mas devemos definir quanto tempo temos disponível para investir naquela linha de pesquisa.
Essa definição deve ficar clara para todos os stakeholders, e eles devem ser atualizados regularmente sobre o progresso feito durante as reuniões diárias e as reuniões de revisão.
No próximo planejamento, a mesma história pode voltar à discussão, se for necessário mais ou menos tempo investido, mas o time deve definir um limite para evitar que a pesquisa entre em um estado de limbo de pesquisa infinita.
Como o trabalho escolhido será realizado?
Este é o último tópico, e é onde entramos nas especificidades de como vamos atacar uma história para conseguir concluir o trabalho. Aqui verificamos a Definition of Done e planejamos ações que nos permitirão alcançá-la.
Este também é o momento em que podemos definir os parâmetros de pesquisa para uma tarefa específica e em que criamos tarefas pequenas o suficiente para serem divididas entre os membros, a fim de paralelizar o trabalho ou facilitar o acompanhamento do progresso.
Enxágue e Repita
Esse processo se repete para cada item de pesquisa ou desenvolvimento no backlog e no início de cada Sprint. É importante notar que quanto mais tempo a Planning leva, mais tempo é tirado da pesquisa e do desenvolvimento reais; além disso, quanto mais tempo em uma reunião, maior é o risco de a atenção das pessoas se dispersar e a efetividade da reunião diminuir.
Por isso, é importante manter as Plannings curtas e, se necessário, agendar outras reuniões antes da próxima Planning para refinar o backlog e discutir trabalhos futuros.
Além disso, o Scrum Master e o Project Owner têm a palavra final em qualquer tópico, porém, harmonia e concordância entre todos os membros e stakeholders são extremamente benéficas para o sucesso de qualquer projeto.
Por hoje é isso! Se você tiver algum comentário, deixe aqui que vou tentar responder. Se quiser compartilhar uma experiência que você teve, sinta-se à vontade para postar também, e qualquer discussão é válida para melhorar essa metodologia!