Release the Kraken – Pode ser uma boa prática para Empresas de Desenvolvimento de Software!?!?

Release the Kraken – Pode ser uma boa prática para Empresas de Desenvolvimento de Software!?!?

Ontem aconteceu na DígithoBrasil Soluções em Software o primeiro “Release the Kraken”, idealizado pelo Robson Castilho, o evento perdurou por uma hora e meia de boas discussões sobre códigos entre os times de Desenvolvimento.

Mas o que isso quer dizer? “Release the Kraken” – O nome é uma frase clássica dita por Zeus no filme Fúria de Titãs, quando ele pede pra libertarem o Kraken, um monstro aquático gigantesco, para destruir os homens.

Segundo o idealizador Robson Castilho o evento é uma união de Code Reviews1 com um algo a mais, como “mostrem seus monstros“. Segundo Robson Castilho “é mais uma brincadeira pra dizer ‘mostrem seus monstros’ pra gente ver o tamanho do problema e tentar corrigir”.

Os Objetivos são:

  • Melhorar a qualidade e padrão de codificação;
  • Localizar problemas futuros que esse código possa trazer para os desenvolvedores;
  • Possíveis falhas de segurança, sobrecarga e estabilidade do sistema;
  • Melhorar a legibilidade do código;
  • Aprender e alinhar boas práticas com desenvolvedores de outras equipes;
  • Analisar o que o time esta produzindo.

Existe uma grande semelhança entre o objetivo do Code Review e do Release the Kraken. Onde o que Release the Kraken tem todas as vantagens do Code Review, com os incrementos de ser realizado entre times independente da linguagem, para analisar os “Krakens”, e de analisar códigos de sistemas que estejam em produção/manutenção.

Como fazer um Release the Kraken:

  1. Convide todos os times a participar de uma discussão mente aberta.
  2. Cada time escolhe um ou dois códigos que estejam “Feios”, os Krakens.
  3. Dia e hora marcados, o time apresenta o código explicando o porquê acredita que o código não esta bom, o contexto do código na aplicação e as saídas que tinham pensado para melhorias.
  4. Logo inicia uma rodada de discussões sobre como esse código pode ser melhorado, todos tem direito de opinar, independente da linguagem de programação.
  5. Como sempre é bom ter um time-boxed para cada time.

Regra:

  • Não pode ter melindres e nem ficar fazendo graça com o que o código alheio.

Minha impressão sobre o resultado

A ideia surtiu um efeito muito interessante nos times.

  • Alguns desenvolvedores estavam ansiosos para mostrarem os códigos.
  • Observou-se também um alinhamento entre o que é ideal.
  • Nas discussões estavam pessoas de C#, Delphi, Java e PHP e a grande maioria opinou de forma coesa agregando valor aos colegas.
  • Os Designers de Interface estão interessados em participar dos próximos com códigos CSS.
  • Quebra de alguns paradigmas entre times.
  • Deu inicio um alinhamento de expectativas de conhecimentos.
  • Dentre outros.

Experimente, mas lembre de no final faça uma retro.

1 – Code Review tem o objetivo de validar o código desenvolvido por outro membro da equipe dessa forma fazendo que as equipes consigam um feedback sobre o código fonte da aplicação mais rápido evitando que seja enviado para produção alguns bugs mais básicos. Leandro Prado

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *