Postado por Geraldo Xexéo, D.Sc., CSM, Professor do PESC/COPPE/UFRJ e do DCC/IM/UFRJ, membro do Conselho Técnico da GPE. | Projetos | 4 |
O oitavo princípio do Manifesto Ágil é: “Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente”. Eu explico em uma espécie de “tradução livre” do original em inglês para: “Em processos ágeis, trabalhamos de 9 às 5, de segunda a sexta”. Por que essa interpretação?
Em um artigo destinado a indústria de jogos, Evan Robinson nos ensina que trabalhar mais do que 40 horas por semana só aumenta os nossos custos e diminui a qualidade do trabalho produzido. Programadores cansados programam mal. Sem falar, é claro, da diminuição da qualidade de vida do time. Ele ainda nos mostra que, depois de certo tempo, passamos a produzir negativamente. Estudos sobre o assunto, sempre apontando nessa direção, começaram no início do século XX. A indústria de software realmente leva tempo para aprender.
Minha experiência como professor e consultor, observando o que acontece ao meu redor, mostra que muitos profissionais estão envolvidos em projetos longos, atrasados e trabalhando horas extras para “recuperar o tempo perdido”. Já cheguei a ter alunos saindo de uma aula às 10 horas da noite, depois de trabalhar um dia todo, para voltar às suas empresas e continuar programando.
Uma das principais lições que o Scrum nos dá ao longo do projeto é conhecer o ritmo do time. Sprint após Sprint o time estima e tenta executar o que estimou. Ele percebe quando trabalhou demais ou trabalhou de menos, estimou com a “mão pesada” ou com “demasiado otimismo”. E, como as Sprints são pequenas, ele tem um feedback imediato, o que permite a correção do rumo. Além disso, a estrutura de reuniões de Planejamento, Retrospectiva e Scrum diário faz com que a estimativa esteja em constante discussão, causando um efeito emergente de alinhar a maneira de pensar de todos os membros.
Feedback é a palavra chave. Ciclos curtos fazem com que os seres humanos percebam os efeitos das suas previsões e decisões. Se você errar uma decisão tomada a um ano atrás, nem vai se lembrar que foi você que a tomou. Duas semanas atrás, você ainda se lembra dos motivos, mesmo que não os tenha anotado.
A Sprint pequena, aliás, é um fator importantíssimo para criar um ritmo sustentável. Imaginando que a equipe erre na sua previsão para menos, o maior custo que ela vai ter em uma Sprint de 2 semanas será de um a três dias de “trabalho forçado”. E isso será imediatamente corrigido na Sprint seguinte, permitindo até que seja dada alguma folga para compensar o esforço. Lembremo-nos: quando a equipe se cansa, é o software que fica quebrado.
Agora, tudo isso só vai dar certo se o Scrum for adotado plenamente por todos, inclusive pelo Product Owner. Podemos imaginar um PO ver muitos pontos entregues e não perceber que pediu demais da equipe. Até mesmo posso ver esse PO dizendo que a equipe trabalhou “por que estava motivada” ou ainda “por que esse é o comprometimento que o Scrum define” e esquecer que, motivada ou não, ela ficou cansada. Motivada em uma Sprint, revoltada no seguinte é o padrão que podemos esperar.