O Batman da Sprint!

Alô, pessoal, tudo bem?

Algumas vezes, por conta da quantidade de incidentes (correções no software) e novas implementações, é necessário ajustar a equipe para atender essa demanda. Uma opção é empregar o conceito Batman, ou melhor, definir um super-herói para atuar na equipe. Ficou curioso? Eu também fiquei! Vamos ler o artigo?

batman-cartoon Quando lemos sobre a organização de equipes ágeis para trabalhar no desenvolvimento de software, enxergarmos um mundo perfeito. Basta alocar os desenvolvedores para implementar as funcionalidades do software com base na velocidade da equipe, métricas e estimativas. Porém, temos a ciência de que essa teoria não ocorre de modo tão acurado. Assim como os softwares estão em constante evolução, é natural que eles também estejam em constante manutenção, exigindo correções. Na prática, então, nos deparamos com algumas dificuldades, principalmente relacionadas ao prazo e escopo do projeto.

Vamos a um cenário. Imagine que uma nova funcionalidade do Product Backlog foi selecionada para ser implementada na Sprint atual e que a equipe foi devidamente alocada para essa evolução. Eis que, durante a Sprint, novos erros são reportados para a equipe. Poucos? Não, muitos erros! E são erros críticos de produção. Como resultado, o foco na evolução é perdido em função da criticidade dos erros e a equipe precisa se contorcer para suprir as tarefas imprevistas. Bom, não é preciso nem dizer que isso é relativamente comum no cenário de desenvolvimento de software.

É bom ressaltar que o surgimento destes erros, em boa parte, não é oriundo da irresponsabilidade técnica dos desenvolvedores. Devido à complexidade, dimensão ou segmento do projeto, erros são introduzidos durante o ciclo de vida. É uma caraterística do desenvolvimento de software. Claro, há meios de mitigar este risco, como a análise de impactos e testes, mas, mesmo assim, não existe uma bala de prata.

Pois bem, com esse montante de correções para serem codificadas, a Sprint ficou comprometida! Por um lado, é necessário implementar a nova funcionalidade, como parte do acordo com o cliente. Por outro lado, os erros devem ser corrigidos para não impedir a utilização do software em produção.

Nossa! E agora?

Simples! Chamem o Batman!

Brincadeiras à parte, o conceito “Batman”, neste contexto, se refere à definição de um dos membros da equipe para atuar na seguinte proporção: 50% para a evolução e 50% para a correção. Em outras palavras, este membro assume uma postura diferente na equipe: exercer uma função de intermediador entre a evolução e manutenção para que nenhum dos dois lados fique desfalcado. Dessa forma, o Batman quebra a exclusividade que existe em cada lado.

Exclusividade?

Sim. Se você entregar um item de correção crítica para um desenvolvedor que está no quadro de evolução, essa será a resposta:

“Hummm, não vai dar. Estou alocado somente na evolução. Não tenho tempo para a correção…”

Consequentemente, perde-se o escopo das prioridades. Todos compreendem a situação mas não estão preparados para aceitar responsabilidades paralelas. Logo, se houver um desenvolvedor encaminhado para as duas atividades, é possível equilibrar as demandas.

Legal! Já vou definir um Batman para a minha equipe!

Calma, espere aí, apressado! Para definir esse super-herói, é preciso estabelecer alguns critérios:

As user stories de evolução atribuídas ao Batman (durante o planejamento da Sprint) não devem ser complexas ou grandes. Caso contrário, há um risco dessas user stories não serem finalizadas até o final da Sprint;
As correções conferidas ao Batman são emergenciais, como erros de produção ou críticos para o sistema. Em adição, as correções que, caso não sejam realizadas, resultem em um possível problema futuro no software, também podem ser incluídas nessa lista;
É fortemente recomendável que a função de Batman seja atribuída a um membro diferente para cada Sprint. Esse rodízio evita o code ownership (proprietário da funcionalidade) e incentiva o conhecimento coletivo da regra de negócio;
Por fim, ao finalizar as correções emergenciais e as atividades de evolução, o Batman não deve receber novas user stories, já que deve estar disponível para possíveis erros que surgirem. Para evitar a ociosidade, ao invés de user stories, procure alocá-lo para apoiar outros desenvolvedores ou atuar em spikes (atividades de pesquisa, testes de ferramentas/tecnologias, etc).

Agora, vale fazer uma crítica. Existem muitas equipes de desenvolvimento que definem todos os membros, ou pelo menos a maioria, como um conjunto de “Batmans”. Os membros dessas equipes, logo no começo daSprint, não sabem o que realmente vão codificar ou se passarão mais tempo na correção ou evolução. Pior mesmo quando o Scrum Master diz: “Ei, você, inicie a evolução XYZ e, caso surgir uma correção, você interrompe a evolução para atendê-la. Depois que terminar, volte novamente para a evolução, ok?”. Não! Isso não deve existir! O custo de ficar alternando a função de um desenvolvedor é muito alto por causa preparação de ambiente e da linha de raciocínio, além de ferir as métricas. Essa prática deve ser evitada.

Para fechar, destaco mais uma vantagem. Na maioria das empresas, a alocação típica dos recursos é feita da seguinte forma: 80% para a evolução e 20% para a correção. Com a definição do Batman, a equipe pode controlar essa porcentagem dentro da Sprint (in-sprint), tornando-a variável. Dessa forma, as correções emergenciais recebem prioridade e, na ausência destas, a evolução é trabalhada.

No LinkedIn, os membros até disseram que, com o Batman, “emergencies become no big deal”, ou seja, as correções críticas deixam de ser uma preocupação.

Já que estamos nesse clima, vamos ouvir o tema, hahaha!