Em times bem sucedidos e Sprints bem definidas, algumas vezes é possível que as funcionalidades da Sprint Backlog sejam concluídas antes do término do prazo. Logo, imagine que, em uma Sprint de 30 dias, a equipe consiga finalizar as atividades em 27 dias com sucesso. O que fazer nos 3 dias restantes?
Pois bem, o objetivo deste artigo é apresentar algumas sugestões para aproveitar esse tempo, que eu diria, valioso!
Introdução
Antes que você me pergunte, concluir o backlog antes do prazo é possível, sim! Ao selecionar as user stories para a Sprint Backlog, não temos uma exatidão do tempo que será necessário para implementá-las. É por isso que trabalhamos com estimativas. Às vezes, uma determinada funcionalidade pode demorar o dobro ou o triplo do tempo estimado. Por outro lado, também é possível que uma implementação tenha sido “superestimada”, ou seja, é concluída na metade do tempo. Portanto, se houverem muitas user stories superestimadas, é provável que a Sprint Backlog seja finalizada antes do prazo.
Os dias restantes podem ser utilizados para várias atividades, no entanto, o ideal é tirar proveito deste tempo ao máximo. Confira a lista de sugestões a seguir e identifique quais delas podem ser empregadas na empresa em que você trabalha. Para facilitar o entendimento, utilizarei o cenário dos 3 dias restantes como exemplo.
1) Escolher uma funcionalidade do Product Backlog e implementá-la
Uma boa forma de aproveitar o tempo de sobra é selecionar uma funcionalidade que ainda não foi implementada. A vantagem é que as atividades dessa funcionalidade em particular poderão ser distribuídas entre toda a equipe. Enquanto um desenvolvedor estiver implementando, outros podem adiantar os testes automatizados e a documentação. Como resultado, o software terá uma funcionalidade adicional que, até então, não estava vinculada ao incremento atual do software. O cliente ficaria surpreso, hein? 🙂
Entretanto, é importante destacar que essa opção só é adequada se houver uma funcionalidade pequena na Product Backlog, na qual seja possível implementá-la nos 3 dias restantes. Caso contrário, essa funcionalidade pode comprometer a próxima Sprint. Aí não adianta nada, rsrs.
2) Conhecer as user stories da próxima Sprint
Os 3 dias podem ser utilizados para estudar a analisar o que virá pela frente. Se houverem funcionalidades complexas na próxima Sprint, é uma boa oportunidade para trabalhar nas estimativas, conhecer melhor a regra de negócio e preparar a equipe para implementá-las. Só o fato de descobrir as unidades de código que serão modificadas e os locais do software que serão afetados já é um grande benefício, além de adiantar possíveis imprevistos. Em alguns contextos, isso é chamado de “precipitação dos desafios técnicos”.
Ocasionalmente, essa opção pode resultar novamente em um período de sobra na próxima Sprint. Se acontecer sempre, será ótimo!
3) Conversar com o Product Owner sobre funcionalidades de alto valor
Essa sugestão é um complemento do item acima, porém, vista de outra perspectiva. Algumas vezes, a funcionalidade mais complexa não é necessariamente a mais importante. Portanto, uma boa ideia é discutir com o Product Owner sobre as funcionalidades de maior prioridade e analisá-las. Quanto mais a equipe estiver preparada para essas funcionalidades, maiores serão as chances de implementá-las com sucesso e, talvez, mais rápido!
4) Pagar a dívida técnica e aprimorar a qualidade
Caso o software tenha códigos duplicados, acoplamentos pesados ou dependências desnecessárias, agora é uma boa hora para minimizar estes problemas! Aplicar as práticas do Clean Code, princípios SOLID e Design Patterns pode ser útil para pagar a dívida técnica existente no software. Mas, cuidado: essas refatorações devem ser devidamente estudadas antes de colocadas em prática. Não queremos que uma refatoração dessa natureza traga novos problemas, não é?
Ainda neste contexto, pode-se trabalhar na qualidade do software em geral, principalmente envolvendo requisitos não funcionais, como usabilidade, desempenho e confiabilidade. Sabe aquela tela que os usuários vivem reclamando que está lenta e difícil de usar? Aproveite este tempo para solucionar este incômodo de uma vez por todas!
5) Testes exploratórios
Execute o software e teste-o por algumas horas para descobrir possíveis bugs. Caso encontrar algum, aproveite para corrigi-lo ou deixar a equipe consciente de que ele existe. Essa atividade pode evitar uma futura notificação de erro por parte do cliente.
6) Atualizar, instalar ou aprender novas ferramentas
Talvez você já se encontrou na seguinte situação ao conhecer uma ferramenta: “Nossa, esse software parece ser excelente e pode aumentar a minha produtividade”, porém, não tem tempo de instalar e testá-lo, não é? Comigo também acontece isso, haha.
O tempo de sobra pode ser útil para explorar novas ferramentas ou atualizar as já existentes. Muitas vezes, essas ferramentas trazem recursos que são desconhecidos, mas que podem ser altamente produtivos. A propósito, em breve vou elaborar um artigo sobre algumas ferramentas que têm me ajudado muito ultimamente.
7) Coding Dojo
Essa ideia foi sugerida pelo Diego Garcia, um grande profissional na área de desenvolvimento de software. Obrigado, Diego!
Coding Dojos são atividades de programação que têm como objetivo melhorar as habilidades e o conhecimento da equipe no âmbito técnico. Através de um processo de Brainstorming, a equipe discute melhores formas de resolver determinados desafios, também chamados de “Kata”. Com a experiência adquirida, os desenvolvedores podem replicar o aprendizado nas próximas Sprints durante as atividades de codificação. Particularmente, eu acho essa atividade bastante interessante, inclusive pelo fato de “nivelar” o conhecimento entre a equipe.
8) Ajudar outras equipes
Essa é uma sugestão solidária! 🙂
Caso a empresa tenha duas ou mais equipes de desenvolvimento, elas podem se ajudar neste tempo de sobra. Os desenvolvedores podem ser alocados durante os 3 dias restantes para exercer atividades básicas ou adicionais em equipes que estão com o backlog em cima do prazo ou atrasado. Esse espírito de colaboração é o que traz maturidade para equipes ágeis. No entanto, deixo um adendo: essa sugestão deve ser empregada somente quando viável. Se for preciso que o desenvolvedor da outra equipe interrompa as atividades para prestar orientação, esqueça. O objetivo não é atrasar ainda mais a outra equipe.
Antes de encerrar o artigo, vale fazer uma ressalva. Caso as funcionalidades de uma Sprint sejam concluídas sempre antes do prazo, recomenda-se revisar a velocidade da equipe. Talvez o número de funcionalidades selecionadas esteja abaixo do que a equipe realmente pode realizar. Neste caso, considere adicionar mais algumas funcionalidades nas próximas Sprints e verificar o desempenho da equipe.
Leitores, obrigado pela atenção e até a próxima semana!
Parabéns pelo post!
Excelente abordagem.
Trabalho com Desenvolvimento de Software ha mais ou menos 9 anos, dos quais, os últimos 5 foram com Metodologia Ágil Scrum. As dicas são todas válidas e acredito fortemente na combinação de mais de uma delas.
“Um dos grandes desafios em se utilizar metodologias ágeis, está na necessidade em se ter uma equipe madura.”
Concordo totalmente com o seu comentário, Leandro! Se houver a possibilidade de combinar duas ou mais atividades apresentadas neste artigo, o tempo será ainda mais produtivo. Para que isso seja possível, a equipe deve estar plenamente comprometida com as diretrizes ágeis.
Obrigado pelo comentário! Abraço!
Uma pergunta.. posso puxar para a sprint atual um item do backlog.. se não conseguir finalizar (devido ao tamanho da estória) na entrega migro ela para a próxima sprint.
Olá, Riderman!
Mesmo que a Sprint Backlog tenha sido concluída antes do prazo, o ideal é não trazer estórias grandes do Backlog para a Sprint, já que existe uma grande possibilidade de não finalizá-la até o final efetivo da Sprint. Caso a equipe decida buscar um novo item do Backlog para aproveitar o tempo restante, eu sugiro que seja uma estória pequena, como, por exemplo, estórias que não implicam na alteração de vários locais do software e que não exijam testes extensos.
Geralmente, o tamanho da estória é calculado em pontos de função ou através de estimativas da equipe.
Obrigado pela visita! Abraço!
Olha André, então no meu caso não tínhamos estórias pequenas para pegar. Optamos por puxar uma estória mesmo sabendo que não iríamos entregar, é na reunião de entregar alterar está estória para a próxima Sprint. Isso está correto?
Entendido, Riderman! Bom, não há nada de errado em trazer uma estória grande para a Sprint atual, porém, deve-se tomar bastante cuidado com os seguintes critérios: a implementação não deve afetar o prazo de entrega; não pode prejudicar outras funcionalidades do software (impactos indesejados); não deve comprometer o Backlog da próxima Sprint; e, claro, a entrega da estória não deve ser “prometida” para o cliente no incremento atual. Se a sua equipe contém os recursos necessários para evitar contratempos com estórias grandes divididas entre Sprints, então não há problemas.
De qualquer forma, se não há estórias pequenas, talvez a segunda e terceira sugestões do artigo podem ser adequadas:
– Conhecer as user stories da próxima Sprint
– Conversar com o Product Owner sobre funcionalidades de alto valor