Não é só sobre você

O sprint não se resume apenas às histórias que você entrega, e seu comprometimento não diz respeito apenas a você. Ao comprometer-se com as histórias que compõem o sprint, é crucial considerar o tempo e esforço mental necessários para outras fases do ciclo de desenvolvimento.

Num ambiente ágil, temos muitas reuniões e processos, que vão além do desenvolvimento individual das histórias, quer isso nos agrade ou não.

Consideremos dois cenários, ambos com sprints de 2 semanas e um compromisso de 8 pontos.

Cenário 1: O sprint acabou de começar, você tem uma noção superficial do que deve ser feito na história à qual se comprometeu, pois não entendeu completamente os critérios de aceitação. Preferiu não perguntar, pensando que as coisas ficariam mais claras durante o desenvolvimento. Ao abrir o código, você passa uma hora tentando encontrar o arquivo com o componente necessário para a alteração e mais duas horas compreendendo como os componentes se comunicam. Após uma pausa para o almoço, reuniões à tarde e, com sorte, mais uma hora de codificação, o expediente termina.

Os dias passam, você fica travado, algo normal em nossa área. No entanto, ao invés de buscar ajuda de um colega (seja por meio de "rubber ducking" ou pair programming), você se sente com tempo, certamente descobrirá a solução sozinho, afinal ainda há mais de uma semana até o final do sprint, então não comunica sua dificuldade ao resto do time e decide que a melhor coisa a se fazer é ir pensar em outras coisas (por vezes é), você acaba se perdendo na world wide web sem resolver o problema.

A três dias do fim do sprint, você ainda não entendeu os critérios de aceitação, então pergunta ao Product Owner (PO) sobre o significado em termos de negócios. Ele explica, você acredita ter entendido e começa a implementar. Contudo, é interrompido por uma reunião de refinamento à tarde, na qual, sem entender quais histórias precisam ser refinadas, adota uma postura passiva, sem contribuir para a discussão.

A um dia do fim do sprint, seu Scrum Master está preocupado, sua história é crucial para o sprint goal, você está um pouco tenso, acabou de enviar o PR para revisão. O resultado? Quatro tarefas abertas, 11 comentários e uma implementação que precisa ser refeita devido a um mal entendido na regra de negócios, definitivamente não vai dar tempo.

No último dia do sprint, o sprint goal não é alcançado.

(Certamente, pode parecer absurdo, mas acontece mais frequentemente do que se imagina.)

Cenário 2: Mesmos 8 pontos, você tem clareza do que deve ser feito na história. Inclusive, já escreveu algumas notas pessoais para auxiliar na implementação, fruto do tempo investido nos refinements. As primeiras horas do dia transcorrem bem; próximo ao almoço, você se depara com um problema não previsto e solicita a um colega uma sessão de "rubber ducking", que felizmente resolve a questão.

Ao final da semana, seu código está implementado. Na quinta-feira, abre um Pull Request (PR) e pede revisões aos colegas. Enquanto espera, revisa histórias do backlog que necessitam de refinamento. No final do dia, ajuda um colega a resolver um problema técnico relacionado à regra de negócio e encerra o dia.

Na sexta-feira, os colegas deixam comentários em sua história. Você percebe que esqueceu de remover um parâmetro não utilizado e que sua nova função pode ser otimizada. Trabalha nessas melhorias e envia o novo PR. Seus colegas são ágeis, e o merge é realizado antes do almoço.

Ainda resta uma semana de sprint. Seu PR está integrado, e você pode se dedicar ativamente a ajudar outros colegas. Há tempo na agenda e, principalmente, espaço mental para participar ativamente das reuniões. Você revisa PRs de colegas e aproveita para estudar um tópico técnico que reconhece em si como um ponto fraco.

Na sexta-feira, antes do fim do sprint, nem você nem sua equipe estão estressados. Tudo foi entregue.

Este cenário, não tão fictício quanto parece, ilustra como o trabalho de um desenvolvedor de software vai além da entrega de pontos de história. Envolve comprometimento e participação em todo o ciclo de desenvolvimento, auxílio aos colegas e aprendizado das regras de negócio. A gestão do tempo é fundamental, e perceber que o sprint é mais do que um compromisso individual é crucial. Minha sugestão é: aprenda gestão de tempo, comprometa-se com histórias considerando refinamentos, apresentações e revisões de PRs e principalmete entenda que essas coisas são tão importantes quanto os pontos que você entrega.