3 formas de lidar com demandas emergenciais na Sprint

Hello! Tudo certo, leitores?

Diferente dos artigos anteriores sobre Desenvolvimento Ágil, essa publicação será um pouco mais pragmática, envolvendo um cenário comum em equipes de desenvolvimento: as emergências!

Considere que, durante a Sprint, várias demandas emergenciais (erros impeditivos) começam a surgir e exigem prioridade na equipe. Como proceder?

Confira, neste artigo, 3 possíveis formas para lidar com essa situação.

As dicas mencionadas no artigo foram baseadas em uma publicação de Abhishek Agrawal, Agile Coach da HP, no Pulse do LinkedIn. Se você é usuário da rede, recomendo participar do grupo Agile and Lean Software Development (em inglês). Há discussões bastante instrutivas por lá!

Pois bem, certa vez, li um artigo de um gerente de projetos que criticava o conceito de Sprints no Desenvolvimento Ágil, defendendo que este prazo estipulado (timebox) é sempre ilusório em função das correções emergentes no software. Sim, ele está certo, entretanto, eu diria que a crítica deve ser direcionada à abordagem da equipe, e não à metodologia. O Scrum é um framework que recomenda diretrizes e cerimônias para a condução do trabalho e coordenação da equipe, mas, como já justifiquei em outros artigos, não é um bala de prata para exterminar todos os problemas. Muitas ações devem partir da própria equipe.

Para agir contra as demandas inesperadas durante a Sprint, por exemplo, as equipes precisam de seções de inspeção e adaptação, continuamente, para definir como atendê-las. Pensando dessa forma, existem 3 sugestões que podem ser empregadas pela equipe, apresentadas abaixo.

1) Reserva de tempo (ou “gordura”)

Nessa primeira sugestão, a equipe se compromete com apenas 70% ou 80% da sua capacidade durante o planejamento, com a ciência do Product Owner. O restante dessa porcentagem, popularmente conhecida como “gordura da Sprint“, é reservada exclusivamente para as demandas emergenciais. Dessa forma, o trabalho e o prazo planejado não será afetado pelas correções emergentes, já que existe um tempo alocado para esse esforço (lembram do Batman?). Na melhor das hipóteses, caso não surjam correções, a reserva pode ser preenchida com novas funcionalidades solicitadas ao Product Owner, embora eu não recomende essa decisão.

Vale frisar que essa abordagem é adequada somente para situações em que o número de correções será, na maioria das vezes, menor que o trabalho planejado.

2) Ping-Pong

Por sua vez, quando o número de correções é equivalente ao número de funcionalidades planejadas, talvez o “Ping-Pong” seja a melhor alternativa. A equipe se divide em duas sub-equipes: expansão e correção. A primeira sub-equipe assume somente o desenvolvimento que foi definido no planejamento, enquanto a segunda se responsabiliza por corrigir os erros emergenciais. Neste caso, a capacidade da expansão será reduzida a 50%, porém, a probabilidade de cumprir com as entregas será evidentemente maior.

Para incentivar a produtividade e motivação, os papéis das equipes podem ser invertidos a cada Sprint, como um rodízio. Os membros da equipe de expansão passam a trabalhar na correção e vice-versa, caso seja possível.

3) Alinhamento da entrega

Quando sabemos a quantidade aproximada de correções, as duas primeiras alternativas são convenientes. No entanto, muitas vezes não sabemos o número de demandas corretivas que surgirão na Sprint. Este é um caso excepcional e exige uma postura um pouco mais inflexível.

Em primeiro lugar, a equipe não deve se comprometer com 100% da capacidade, considerando que provavelmente será necessário trabalhar em correções. Em seguida, quando uma demanda emergencial surgir, a equipe deve, junto com o Scrum Master, estimar o tempo que será necessário para corrigi-la. Com base nessa estimativa, há duas condições:

3.1) Se for possível “acomodar” a correção na Sprint, a equipe se compromete a realizá-la;

3.2) Caso contrário, se a estimativa extrapolar a capacidade da equipe na Sprint, o Product Owner deve ser acionado para negociar um alinhamento de entregas com o cliente, como, por exemplo, substituir uma nova funcionalidade pela correção do erro, principalmente se este for um impeditivo.

Cada caso é um caso, pessoal. As sugestões deste artigo talvez não sejam uma solução plena, mas garanto que podem mitigar a instabilidade nas entregas.

Conhece outra alternativa para lidar com essas demandas? Escreva um comentário!

Até logo!

André Celestino

Mais artigos deste autor »

Desenvolvedor de software há 7 anos e autor do blog AndreCelestino.com. Graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software com ênfase em Desenvolvimento Ágil. Atualmente trabalha como Engenheiro de Software.


9 Comentários

Leonardo Teixeira
1

Muito bom post André!
Atualmente estou iniciando coordenação de desenvolvimento implantando Scrum, já me vi em casos de ter que “matar” a sprint em razão de correções por regras de negócios não terem sido devidamente estipuladas, trazendo falhas no planejamento. Vi nesse sentido parar o desenvolvimento, replanejar e recomeçar.
Uma dúvida é: até que ponto posso considerar que correções impactam fortemente no andamento da sprint, sendo que obedecendo as diretrizes do Scrum, essas falhas não poderiam ocorrer em razão da planning metting?

André Luis Celestino
2

Olá, Leonardo, tudo bem?
Por coincidência, também já me deparei com essa situação de quase abortar a Sprint em virtude de erros oriundos de falhas no levantamento e especificação de requisitos. Sempre defendo a ideia de que a Engenharia de Requisitos é uma das fases mais cruciais na vida de um projeto e, portanto, deve ser bem desempenhada.
Leonardo, gostei da forma como você expôs a sua dúvida. Durante a Sprint, as correções no software devem ser contempladas somente dentro do tempo alocado para essa atividade, utilizando, talvez, uma das 3 formas sugeridas no artigo. Se as correções excederem este tempo, a evolução do projeto será prejudicada.
No entanto, Leonardo, caso as correções no software se tornem recorrentes, eu sugiro outro tipo de abordagem: negociar a interrupção da evolução por algumas Sprints e iniciar uma força-tarefa para eliminar os erros do software. É melhor limpar a casa primeiro para depois colocar mais móveis. Dessa forma, os próximos planejamentos serão mais assertivos.
Obrigado pelo comentário!
Abraço!

Leonardo Teixeira
3

Agradeço pelo feedback e pelas valiosas indicações André.
Abraço!
P.S.: Sugestão: O leitor que comentou o post poderia receber uma notificação que seu comentário teve resposta pelo autor. Só li agora porque tive a curiosidade de saber se teve ou não sua resposta. Não recebi notificação alguma.

    Redação PTI
    4

    Olá, Leonardo!
    Aqui é o Jackson, responsável pela parte técnica do portal, tudo bem?
    Já estamos com esta funcionalidade em pauta como emergencial. Em breve ela será lançada.
    Grato pela interação e sugestão.
    Abraço!

Ademir
6

Acredito que as duas primeiras alternativas(Reserva e Ping Pong) são prejudiciais a agilidade no TIME.
Tentei imaginar situações em que essas demandas emergências, no texto indica que seriam Bugs ou ajustes uma vez que se é uma oportunidade do negocio normalmente ganham prioridade e podem cancelar a Sprint em andamento. Dessa forma a abordagem de “Alinhamento da entrega” é melhor e mais adequadas aos princípios de Agile.

André Luis Celestino
7

Olá, Ademir, tudo bem?
Já tivemos bons resultados com o Ping-Pong, principalmente pelo compartilhamento de conhecimento do produto que a técnica traz para a equipe, melhorando as soluções propostas.
Sem dúvidas, o alinhamento de entrega é a opção mais compatível com as diretrizes do Agile. Concordo com você!
Abraço!

Amadeu Paes
8

Caro André,
Achei interessante a abordagem, mas dependendo da situação não dá pra avançar muito quando se tem uma dívida técnica alta.
Com certeza se vc tem uma dívida técnica alta é porque a definição de pronto não está madura ou os testes não fazem parte da rotina dos desenvolvedores.
Eu tive uma situação, onde meu cliente queria alguns relatórios, mas o sistema legado era tão cheio de bugs que eu não poderia garantir a veracidade das informações.
Ae cara, tem q jogar aberto com o cliente, expliquei q levaria dois meses pra corrigir os bugs pra termos a base pra iniciarmos o relatório.
Pois pior do q não ter a informação e ter a informação errada.
Pois bem, conseguimos resolver, mas sinceramente não consigo ver o sistema avançar se há falhas nele.
Abs

André Luis Celestino
9

Olá, Amadeu!
Muito interessante o seu comentário, pois reflete uma situação relativamente comum em empresas que possuem projetos de software complexos.
Também já trabalhei em um software dessa natureza. As evoluções eram feitas com bastante qualidade (Clean Code, Design Patterns, SOLID…), porém, o que nos atrapalhava era a grande dívida técnica. Erros não paravam de ser reportados.
A nossa solução foi semelhante à sua. Interrompemos completamente os itens de evolução (embora isso tenha trazido um prejuízo para a empresa) para “arrumar a casa”. Levamos aproximadamente 3 meses para que a arquitetura do projeto ficasse “estável”, nos deixando mais seguros para prosseguir com as evoluções.
Obrigado pelo comentário!

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!