2

Porque TI não treina ???

No GUMA Agile Day, quer com o Keynote Klaus Wuestefeld ou a instigante lightning talk do Marcel Peixoto sobre o número cabalístico 10Mil – O jogador treina muito mais do que joga jogos oficiais, o cirurgião passa sua vida praticando, viajando o mundo atrás de novas técnicas, os cantores e músicos treinam permanentemente, nas artes marciais treina-se até atingir a perfeição, POR QUE EM TI NÃO TREINAMOS ?!?

Enquanto o tempo passa, dívida técnica, falta de padrões, cada um por sí e nem queremos saber qual é o jeito do outro, o que o mundo lá fora esta fazendo, por que se incomodar? Por que se expôr? Tem que treinar? Esta dizendo que meu código é ruim? Quem é o Senior aqui? Estariam me chamando de incompetente? Acabou de chegar e vai dar palpite? Desenvolvo programas a anos, não tenho porque ouvir isso! Então, vamos TODOS abrir a mente e rever conceitos …

Solução definitiva, será que estamos maduros o suficiente ?

Jogadores treinam diariamente, por que não fazemos o mesmo a cada 15 dias, VOU ALÉM, por que fazer a noite, cansados, por que não pela manhã, de forma sistemática e programada, as empresas querem que os desenvolvedores se aperfeiçoem, mas estão dispostos a esperar anos reclamando, ao invés de montar um sistema definitivo de treinamentos …

Que tal 2 Horas a cada 15 dias, 2 Horas a cada 127,5 Horas ? Ou não temos tempo para parar e melhorar, vamos continuar fazendo mais do mesmo e ficar  eternamente reclamando que não atingimos o Nirvana ? É como se o Grêmio ou o Inter quisessem pagar salario apenas para os tempos de jogo, os treinos e exercícios são de responsabilidade do jogador, que tem que desenvolver-se …

Dojo (道場 lugar do caminho?) é o local onde se treinam artes marciais japonesas, o termo vem do Zen Budismo, lugar de iluminação onde os monges exercitam a meditação, concentração, respiração, físico e outros mais. Alusivo a profissões, local onde um pintor alcança a felicidade pintando, um médico realizando cirurgias ou um judoca praticando judô.

O que é Coding Dojo ?

Trazendo para nossa realidade, convencionou-se chamar de “Coding Dojo” os eventos em que um grupo de desenvolvedores reunem-se para treinar a arte da programação de computadores. Não é um treinamento, nem tampouco um curso, é um desafio coletivo em que todos usarão de uma sistemática cooperativa para aprenderem ao buscarem a solução.

É para ser periódico, sempre com novos desafios, instigando os praticantes para que usem técnicas de desenvolvimento dirigido a testes automatizados, em que desenvolve-se primeiro o teste, depois o código da solução e refatora-se o mesmo até estar o melhor possível. Há dois formatos clássicos de Dojo, conforme segue.

Coding Dojo Randori

Randori [乱取り] é uma luta de treinamento no judô ou no jiu-jitsu, que não vale nenhum ponto no qual você apenas treina com a pessoa. Não há competição, o clima deve ser amigável e colaborativo, omais descontraído e informal quanto possível, mas seguindo as regras de TDD (Test Driven Development).

O formato exige que se tenha apenas um computador e a solução seja desenvolvida um pouco por cada participante, de forma complementar e continuada, sempre aos pares enquanto o restante do grupo mantém atenção crítica ao que esta sendo construído, de forma a dar continuidade ou mesmo refazê-lo em seu turno.

O desafio é resolvido aos poucos, por todos, durante o tempo do Dojo. Atuando em pares, um é o programador junto ao teclado, outro é um ajudante, os demais apenas observam. A cada 5 minutos, o programador deixa o par, o ajudante passa a programar e alguém dos demais assume como ajudante, girando a cada novos 5 minutos.

O par que esta programando deve manter seus pensamentos e decisões em voz alta, para que todos saibam o que esta acontecendo. Quem não esta compondo o par que esta programando deve deter-se a observar e somente pedir maiores informações durante a fase de refactoring.

Coding Dojo Kata

Kata ( ou forma?) é um conjunto de movimentos de ataque e defesa e está presente nas mais diversas artes marciais japonesas. O objetivo do kata é ajudar no desenvolvimento das aptidões psicológicas e físicas necessárias para o verdadeiro combate.

Para nós, é quase uma palestra, onde há a apresentação da solução de determinado desafio e todos treinam reproduzindo o que e como foi criada a solução. O treinamento é a busca por criar certos padrões ou nivelamento entre os integrantes de uma equipe.

Ao final, lembre de dar a palavra aos participantes, uma discussão sobre lições aprendidas, o que continuar fazendo, o que parar e o que começar, sempre com foco em melhorar o próximo Dojo, valorize a participação de todos, Juniores, Plenos e Seniores, pois o mais importante é a transferência de conhecimento.

Coding Dojo Kake

É um randori ninja, com diversos pares desenvolvendo concorrentemente, podendo até mesmo ser em linguagens diferentes, exige alguma experiência e maior organização.

Coding Dojo Boshú

Boshú (募集, recrutamento) – Inicialmente chamávamos de Peneirão-Dojo, realizamos sob o nome de Dojo-de-Dojos, mas o colega Cássio Trindade foi atras e o batizou com uma serenidade oriental, agora, além do Randori, Kata e Kake, também temos o Coding Dojo Boshú, que significa “recrutamento” em japonês.

A principal característica é tratar-se de uma sequencia de Dojos, talvez startup, UX, backend, frontend, Agile, escolhendo-se um mix de forma a ser possível avaliar 360º da galera, sempre com a mão-na-massa, abstraíndo aspectos comportamentais, colaborativos, técnicos, cognitivos e construtivistas.
Ao final deste post tem o link para o resumo de nosso 1º Dojo Boshú.

Recomendações básicas

. Calma, faça uma abertura e encerramento adequados
. Facilite, use uma sala adequada, com projetor e arejada
. Coffee e biscoitinhos, pensamos melhor de barriga cheia
. Crie problemas novo, não traga trabalho para o Dojo
. Não incentive discuções filosóficas ou pessoais
. Não gere um ambiente de competição, relaxe
. Não force uma solução, foque no aprendizado
. Não deprecie ou super-valorize ninguém
. Pode ser que não achem a solução, Ok !
. Não apresse e não enrole, deixe rolar
. Di-vir-ta-se!

Leis do Dojo

Tinha um cartaz na porta do Open Space do Ágiles 2011 em Buenos Ayres com duas leis, que eu faço questão de reeditar para nossos Dojos :

1. Não se estresse, o dojo tem vontade e energia própria, na maçonaria chamariamos de egrégora, evoluirá como tiver que ser e chegará onde quer que seja … apenas faça seu melhor e aproveite!

2. Lei dos dois pés, se você não esta aprendendo nada e não esta colaborando com os outros, use seus dois pés para ir para um outro lugar em que consiga realizar um ou dois destes objetivos!

Post relacionados, recomendo os dois, são bem didáticos:
Clique aqui e leia meu primeiro post sobre eventos ágeis de Dojo (Vale a pena)

Clique aqui e entenda melhor o que é TDD (test driven development)
Clique aqui e leia sobre o primeiro Coding Dojo Bochu da história   \o/

3

Resumo RBS Dojo-de-Dojos

O que dizer de uma jornada de 5 (cinco) Horas de pura troca, contando com profissionais de muita e de menos experiência, com Coding Dojos, Games ágeis, falando sobre o Nosso novo Jeito de Ser e Fazer no Grupo RBS ?

Entre 9:00 AM e 14:00 PM deste Sábado, dia 10/11/2012, 12 colegas de RBS, um time excepcional, de muita pegada, recebeu 34 profissionais interessados em aprender, trocar e ensinar, conhecer um pouco mais sobre a RBS e candidatar-se a uma vaga na área de produtos digitais da RBS em sua sede no TecnoPUC.

Organização e execução – Eu, Cassio Trindade, Hélio Medeiros, Gabriel Zigolis, Daniela Mota, Debora Moreira, Suien Ellensohn, Magda Veríssimo, Vanessa Frainer, Rodrigo Lungui, André Trevisani, Lincolm Aguiar e Rafael Ruivo.

Teve até sorteio de canecas da RBS, muita comemoração ao final, todos com fome, cansados pela maratona e externando felicidade por ter participado, valeu cada minuto de preparação, correria e dedicação … isso foi consenso, o brilho nos olhos da maioria mostravam que o evento será assunto por vários dias.

A colega Dani Mota é uma fotógrafa de primeira e tirou a foto abaixo e mais algumas de excelente qualidade … clique aqui para ver o álbum de fotos dela.

O feedback foi excelente, com muita coisa legal, uma experiência a ser repetida:

  • 9:00 – Abertura e definição das equipes
  • 9:15 – Distribuição
  • 9:20 – Início primeira rodada
  • 10:45 – Coffee-Break
  • 11:00 – Início segunda rodada
  • 12:15 – Distribuição
  • 12:20 – Início terceira rodada
  • 13:45 – Distribuição
  • 13:50 – Encerramento e feedback
  • 14:10 – Tchau!

Três equipes – Amarela / Verde / Azul (cores dos crachás) – O critério para a divisão da turma de 34 inscritos presentes em equipes deu-se por uma análise de tempo de experiência, tipo de atuação e frameworks de conhecimento.

As colegas do RH, impagáveis, se dividiram de forma a termos uma delas acompanhando cada uma das três equipes em todas as 3 bases, o que permitiu a criação de um vínculo e uma percepção mais próxima de cada participante. Assim, pudemos dar consistência ao acompanhamento das 3 (três) bases montadas, conforme segue:

Base de Coding Dojo de BackEnd – Os colegas Hélio Medeiros e André Trevisani se superaram, com um problema proposto com fundo de cena espacial, com imagens, áudio e um contexto divertido e inusitado, que permitiu uma atividade lúdica e divertida.

Base de Coding Dojo de FrontEnd – Os colegas Gabriel Zigolis e Rodrigo Lungui conduziram um dojo sobre telas do projeto de eleições, algo de conhecimento de todos dada a proximidade do último pleito, gerando muitas oportunidade de aprendizado e análise dos aspectos colaborativos, inovação, práticos e de resultados.

Base de NJSF + Arquitetura de SW + Agile Games – Uma aula do colega Rafael Ruivo, falando sobre os valores, princípios, estratégia e gestão de pessoas no Grupo RBS, seguido de uma explanação de toda a nossa plataforma tecnológica pelos colegas Cássio Trindade e Lincolm Aguiar, encerrando com Agile Games, em especial a Aviões 2.0 dos amigos Flávio Steffens e Rafael Prikladnicki, excelente para aprendizado e percepção do mindset de cada participante, mais colaborativo, coercitivo, líder ou introvertido, …

Ao final, todos os colegas que participaram do evento toparam ficar mais 30 minutos, enquanto as informações e percepções estavam fresquinhas na memória e fizemos uma avaliação de todos os participantes e depois uma retrospectiva do próprio Dojo-de-Dojos …

Temos afinal, uma lista de candidatos que receberão uma ligação nos próximos dias para virem conversar e a marcação da 2ª edição para MARÇO/2013, com uma lista de compras e o desafio de superar esta 1ª edição e fazer algo ainda melhor, mais prazeroso, mais divertido e objetivo.

Como haveria de ser, muito aprendizado em como melhorar, mais tempo para os Dojos, mais consistência para o Coffee-Break, introdução melhor pensada, explicitando melhor as regras e oportunidades que vivenciaremos todos, …

O Cássio batizou os que construiram os Dojos de hoje como “Os Inotáveis”  \o/

2

Reunião GUMA 25/07

A reunião de Julho do GUMA foi um sucesso, com mais de 70 pessoas presentes, com 3 lightningtalks sobre engenharia ágil e, após o Coffee-Break patrocinado pela CWI, um debate em formato FishBowl sobre automação e pontos dúvidas restantes sobre as palestras que proporcionou aprofundamento em cases e vivencias dos palestrantes e integrantes da platéia que foram a frente falar.

As sugestões giraram em torno de termos menos lightningtalks e mais palestras, para assim aprofundar mais os temas, além disto, proporcionar mais debates.

Os temas propostos e mais votados para os próximos eventos foram:

  • 14 votos – Lean Software Development
  • 11 votos – Integração Contínua
  • 10 votos – Adoção de métodos ágeis (cases)
  • 08 votos – Kanban
  • 08 votos – Story Mapping (PO)
  • 06 votos – User Stories e critérios de aceitação (PO)
  • 04 votos – ATDD
  • 03 votos – Engenharia ágil

O evento anterior foi o GUMA Agile Games na UniRitter (clique e leia mais).

0

Reunião GUMA 25/07 – pré

Agende-se, pois temos mais um evento imperdível, no dia 25/07 próximo, uma quarta-feira para fazer-se presente na sala 517 do Prédio 32 da FACIN na PUCRS. Venha prestigiar mais uma reunião do GUMA, desta vez vamos fundo em engenharia ágil, venha escutar quem tem experiência e faz de verdade – DDD, TDD, DevOps, debater sobre qualidade e automação.

Se voce acha que é casualidade, engano seu, engenharia ágil já não é sugestão de boas práticas, é uma exigência de mercado, se voce é desenvolvedor, tem que saber mais e começar a praticar, esta na hora !


http://www.sucesurs.org.br/evento/iii-evento-guma

1

TDD – Test Driven Development

TDD – Test Driven Development
Kent Beck – 2003

Qualidade não pode ser avaliada ou pretensamente alcançada através de testes em um produto já construido. Com o uso de  TDD temos por objetivo prevenir defeitos em primeiro lugar, desde antes e durante toda a construção do software, permitindo uma medida real de qualidade, que podem ser assim traduzidas:

1. A cada decisão construida e não testada, existe uma grande probabilidade da decisão ou da sua implementação estar errada;
2. Funcionalidades de software que não podem ser demonstradas através de testes automatizados não são confiáveis;
3. Testes garantem que refletiremos sobre o que e onde queremos chegar, independente da forma como a solução será implementada.

Comecei a entender o que de fato era TDD após assistir um Coding Dojo, você inicia pela classe de teste, evoluindo seu código aos poucos, sempre a partir do seu teste unitário. Algumas vantagens desta abordagem são:

• Ajuda na documentação: testes bem construidos são mais simples de ler pela equipe que o próprio código, como se fossem critérios de aceitação;
• Incentiva a simplicidade: como a solução vai surgindo pouco a pouco, a tendência é que se foque no imprescindível;
• Aumenta a confiança: todos os testes são montados antes e durante a construção do software, dando-lhe maior confiança;
• Facilita refactorings: quanto mais testes existem no sistema, maior é a segurança para fazer e entregar refactorings.

O código de testes têm 2 funções principais:
1. De especificação, para definir uma regra que seu software deve obedecer.
2. De validação, para verificar que a regra é obedecida pelo software.

Para tornar a construção de testes mais produtivas, existem no mercado frameworks e plugins, como por exemplo o jUnit e Mocks, que são objetos que simulam o comportamento de objetos reais de forma controlada.

O processo de criação de programação orientado a testes segue um ciclo contínuo de desenvolvimento, conforme a seguir referenciado. Estes 3 passos são repetidos até que não se consiga pensar em novos testes, pois a funcionalidade está 100% desenvolvida e testada:

  1. Escrevemos um teste que falhe, ainda para uma classe/método que não existe. Como se fossemos declarar os critérios de aceitação, pensamos primeiro no teste e só depois que o teste estiver pronto, crie somente o suficiente de código necessário para que ele compile e falhe ao rodar.
  2. O passo seguinte é fazer o teste passar, construa um mínimo de código de forma que o teste passe OK.
  3. Agora que temos o mínimo viável de código, refatore e melhore ele um pouco, otimizando-o naquilo que for possível, em pequenos passos. Existe uma técnica chamada FAKE IT,por duplicação através de constantes.

Na WikipPedia tem uma página com várias laudas, extensa e didática:
http://pt.wikipedia.org/wiki/Test_Driven_Development

Descobri uma página que diz que aqui na UFRGS, na sala 104 do Prédio 67, tem Coding DOJO toda Segundas-Feira as 15:30 da tarde … quem é da UFRGS tem que verificar e comentar aqui se isso esta rolando mesmo (site).

Uma frase recorrente é, “qual o desafio para nosso primeiro Coding DOJO?”, pois acabei com este impecilho, pois encontrei um site só de desafios sugeridos … lá diz que as sugestões foram utilizadas em 1577 Dojos, eu acredito: http://dojopuzzles.com/

Várias cidades, como Brasilia, RJ, Floripa, etc, tem blogs com a agenda e muito conteúdo  sobre TDD e Coding Dojos, achei o de Floripa muito legal, com conteúdo, vídeos, exemplos, livros e tudo o que precisa-se para iniciar:

Floripa – http://dojofloripa.wordpress.com/2007/09/10/tudo-sobre-tdd/
Rio de janeiro – http://dojorio.org/material/
Brasilia – http://www.dojobrasilia.org/pages/sobre_coding_dojo

Também encontrei um vídeo de uma palestra da LocaWeb sobre Dojo que eu gostei muito, é bem extenso, mas muito didático, eu sugiro dar uma olhada: