Não existe código grátis!

7

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!

você pode gostar também
7 comentários
  1. Você escreve testes que agregam valor ao produto ou apenas escreve testes?Francisco Souza | Francisco Souza

    […] e linhas de código do seu projeto e não agrega valor ao produto, não tenha 100% de cobertura. Não existe código grátis, e isso inclui seus […]

  2. Produtividade e a cultura do test-first | Francisco Souza

    […] escrever muito código em pouco tempo serei produtivo ainda que o código escrito não funcione ou seja lixo? Quando você entrega a funcionalidade para o cliente, qual garantia ele tem que tal funcionalidade […]

  3. Henrique Bastos Diz

    @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.

  4. Ismael Stahelin Diz

    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. Hugo Lopes Tavares Diz

    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!

  6. Henrique Bastos Diz

    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!

  7. Andre Fonseca Diz

    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.

Deixe uma resposta

Seu endereço de email não será publicado.