No último #Horaextra, nosso amigo Everton Carpes comentou sobre seu excelente post “1 sprint a frente é mini waterfall”. Em seu artigo ele critica a estratégia de manter o time de design sempre um sprint a frente da equipe de desenvolvimento.
Concordo plenamente com a visão do Everton, e pensando sobre o que motiva esse tipo de estratégia, me deparei com o problema do timebox furado. Acontece que é muito difícil para as pessoas olharem apenas para o sprint atual. Mesmo com os demais itens guardados no backlog do projeto, o fato do time conhecer as tendências do projeto gera a terrível ansiedade de “deixar código pronto” para receber as peças restantes que “certamente” chegarão nos futuros sprints. E é exatamente assim que a peça de design acaba preparada para receber a peça de código.
Isso compromete muito do processo ágil! Deixar código “preparado”, acopla incrivelmente os sprints. O código “preparado” é um código incompleto, e código incompleto não é código entregável, logo é código morto.
O resultado é a quebra o princípio evolutivo do código. Sem contar que essa prática sorrateiramente institui o “dono do código”. Como o código está incompleto, só será de fato entendido por aquele que o iniciou, impossibilitando que qualquer pessoa trabalhe naquela parte do projeto.
O resumo da ópera é que não existe almoço grátis! Código barato é código não escrito!
Além disso, se o design do seu código foi feito com testes e seu processo de integração contínua funciona, mudar o seu código não deveria ser caro, então para que fazer mais que o necessário?
[]‘s!
I'm a passionate software developer interested in ways of using technology to improve people lives. I'm an idrealist working on turning ideals into actions.
#1 por Andre Fonseca - 5 de fevereiro de 2010 em 11:06
Mas como fazer para otimizar o uso do time? Esse caso que você cita de designer e os demais é algo que acontece. Tudo deve ser feito, então, dentro do sprint?
Não estou criticando mas apenas colocando uma pergunta que a maioria do pessoal que está em agil começando vai fazer.
#2 por Henrique Bastos - 5 de fevereiro de 2010 em 11:18
Boa pergunta, André!
Você otimiza o time quando desenvolvedores e designers trabalham juntos no conceito do que será entregue no final do sprint.
Para este tipo de tarefa, ferramentas de altíssima tecnologia como papel, quadro, canetas e lápis coloridos, post-its etc são excelentes.
Caso o time não consiga operar corretamente estas ferramentas, sempre é possível fazer um bom investimento em um treinamento de jardim de infância.
[]‘s!
#3 por Hugo Lopes Tavares - 5 de fevereiro de 2010 em 11:32
Bom post Henrique!
Eu já vivenciei isso e um outro problema que em alguns lugares é comum é o caso de aprender usar uma determinada tecnologia/recurso e querer aplicar onde não seria a melhor opção. É o problema de querer mostrar que é “esperto”.
Abraços!
#4 por Ismael Stahelin - 5 de fevereiro de 2010 em 12:08
Legal o post Henrique. Esse tipo de observação é importante principalmente para equipes iniciantes, mas vale como alerta para equipes que trabalham muito tempo juntas também. Esse tipo de coisa é o remédio contra a rotina.
Valeu!
#5 por Henrique Bastos - 8 de fevereiro de 2010 em 07:31
@Hugo pois é, um grande desafio em se montar uma equipe é alinhar o mindset das pessoas para servirem uns aos outros.
@Ismael obrigado! Acredito que esses detalhes são cruciais. Para não cair em uma rotina ruim, é fundamental confrontar o que foi feito com os resultados obtidos.