O Batman da Sprint! - Profissionais TI
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?
"http://s.profissionaisti.com.br/wp-content/uploads/2015/03/batman-cartoon.jpg"
alt="batman-cartoon" width="130" height="120">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 - A Prática do Clean Code" href=
"http://www.profissionaisti.com.br/2014/04/desenvolvimento-de-software-a-pratica-do-clean-code/">
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!
"wp-smiley" src=
"http://www.subrotina.com.br/wp-includes/images/smilies/icon_smile.gif"
alt=":)">
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
"http://www.profissionaisti.com.br/2014/03/scrum-a-eficiencia-de-uma-sprint/">
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!
"620" height="420">
Abraços, homens-morcego!
Até a próxima!
0 comments:
Post a Comment