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.
Introduçã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 tem um ponto, 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, informalmente 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-se 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á 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 impeditivo.
Cada caso é um caso, pessoal. As sugestões deste artigo talvez não seja uma solução plena, mas podem mitigar a instabilidade nas entregas.
Conhece outra alternativa para lidar com essas demandas? Escreva um comentário!
Até logo!
Excelente artigo amigo André. Mas infelizmente na prática a porca sempre aperta pro lado dos programadores. De fato já presenciei cenas onde o gestor obrigou o time a fazer horas extras porque “as correções são irregularidades produzidas durante as sprints, portanto não há como reserva-las dentro da próxima”. Então:
1. Normalmente a gordura nunca é o suficiente. Mesmo se reservar o peso de um obeso mórbido não será o suficiente para atender a demanda de correções;
2. Dividir a equipe entre correção e evolução não é o ideal. Eu já passei pelos 2 lados e digo que equipes de correção tendem a ficarem cada vez mais estressados e desinteressados por conta da pressão constante e ‘mesmice’ por ficar sempre mexendo na mesma coisa sem fazer coisas novas (tem gente que se adapta). Mas o problema disso é que os caras ficam especialistas no software e dificilmente tem tempo de compartilhar o conhecimento. No outro lado da ponte existe a equipe de evolução, que por inexperiência pode continuar produzindo mais erros do que a equipe de correção pode atender. Por isso acredito muito que a equipe é responsável pela sua produção e deve arcar com as inconsistências por ela geradas;
3. O alinhamento da entrega é o nosso mundo perfeito. Seria bom se toda fábrica de software tivesse um gestor disposto a negociar novas funcionalidades em prol de um erro que passou despercebido, mas que agrega muito valor de negócio para o cliente. E quando digo valor de negócio (vale um artigo sobre isso) não quero dizer faturamento, e sim o quanto aquela funcionalidade agrega ao cliente, o quanto ela facilita a vida dele. Por vezes tenho visto inversão de valores onde detalhes fúteis acabam interferindo no resultado das entregas causando estresse entre equipe-gestor-cliente.
Resumindo:
Infelizmente a minha posição ainda é cética a respeito de ’emergências’ durante uma sprint, que por si só já deveria ser blindada e portanto imutável. É lógico que existem exceções, porém a interferência constante de escopo de uma sprint/projeto de software causa um estresse muito grande entre a equipe, uma vez que nunca se tem o máximo de certeza sobre aquilo que ela deve entregar. O fato é que os ‘incêndios’ existem porque o mercado de software brasileiro ainda está muito imaturo em práticas de Desenvolvimento Sustentável de Software, como Testes Automatizados, Medição de Saúde do Código, Cobertura de Testes, Documentação Técnica para Desenvolvedores entre outros.
Boa noite, caro Marcos!
Como sempre, agregando um grande valor ao conteúdo do artigo! Obrigado!
Bom, Marcos, compartilho do mesmo ceticismo e preocupação, o que me fez ser relativamente imparcial no artigo. Aliás, mencionei, apenas no final, que não é uma solução plena, mas pode ser uma iniciativa de mitigação, quando empregadas de forma consciente. A segunda opção, sobre dividir as equipes, já funcionou em uma empresa que eu trabalhava antigamente, no entanto, com a condição de que havia um rodízio entre elas a cada uma ou duas Sprints para evitar o desânimo. Dessa forma, as duas equipes entendiam ambos os ambientes e criavam uma espécie sensibilidade com o que estavam produzindo. Em outras palavras, aprendiam com os próprios erros e praticavam a melhoria contínua.
Como você justificou, a terceira opção realmente seria a ideal nas fábricas. No entanto, é comum encontrar cenários em que o Product Owner “inclina” mais para o lado do cliente do que para a equipe de desenvolvimento. Simplesmente não aceitam negociação de funcionalidades, como se essa ação comprometesse o contrato firmado com o cliente. Mesmo assim, ainda acredito que existam bons Product Owners com essa habilidade de negociação, afinal, é parte do seu papel. Ah, antes que eu esqueça, o tema sobre Engenharia de Valor está na pauta de artigos! 🙂
A reserva de tempo, também sugerida no artigo, só considero ser viável quando há uma certeza de que as correções serão menores do que as expansões, embora seja imprevisível na maioria das vezes. Porém, para equipes que atualmente não dispõem de nenhum método de contingência, esse procedimento já pode ser um início.
A minha postura quanto às sugestões do artigo é relativa. Depende da dimensão do projeto, do ramo de negócio, do perfil dos colaboradores, da cultura corporativa, da metodologia empregada e, claro, do profissionalismo do Product Owner. Além disso, não menos importante, depende também do investimento em Desenvolvimento Sustentável!
Marcos, muito obrigado, novamente, pela visita e pelo comentário! Um grande abraço!
Há algum tempo venho acompanhando seus artigos; são realmente muito bons. Bastante esclarecedores, tanto para iniciantes, como para especialistas. Como percebo que você é uma autoridade no assunto, poderia me indicar um livro realmente bom sobre Delphi? Mas um que trate de uma versão mais recente, a partir da era Embarcadero, de preferência dos XE’s (exigente, não…).
Muito obrigado e que esse sucesso continue. A comunidade Delphi agradece!!!
Olá, Luiz Gustavo!
Primeiramente, fico feliz que esteja acompanhado o blog! Agradeço pelo feedback e pelas visitas!
Bom, Luiz, eu tenho alguns materiais recentes sobre Delphi (não tão bons quanto os da época da Borland), mas estão em inglês. Vou entrar em contato com você em breve, ok?
Obrigado! Espero continuar contribuindo para a comunidade Delphi! Abraço!