Profissionais TI - Pra quem respira informação

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!