Para aprender automação de testes e Test Driven Development (TDD)

Em 2001-2002 conheci o JUnit, ferramenta para escrita de testes unitários em Java. Em 2003 entendi mais da importância dela para o desenvolvimento de software. Descobri junto Delphi Unit, PHP Unit e outras várias versões e pude ajudar amigos a conhecem mais de uma cultura de melhoria contínua e de busca por código de qualidade e automatizado.

O que mudou?

Continue a ler “Para aprender automação de testes e Test Driven Development (TDD)”

#dwresponde – episódio 3 – agile / coding dojo / code kata / shuhari

Daniel de Oliveira, fundador do DFJUG, Grupo de Usuários Java de Brasilia, foi o questionador do episódio 3 do #dwresponde. Ele quer saber sobre Agile, CodingDojo, CodeKata e Shuhari. Esse foi o assunto do vídeo desta semana.

Continue a ler “#dwresponde – episódio 3 – agile / coding dojo / code kata / shuhari”

Seja o que quiser ser e também seja um desenvolvedor de software!

Não. Não estou dizendo que é fácil. Desenvolver software é uma arte. Requer muita responsabilidade, e qualidade técnica no trabalho que é feito. Pode ser um segundo fluxo de valor na sua vida, uma diversão, ou sua renda principal.

No mínimo, uma forma de aprendizado e de desenvolvimento de novas capacidades.

Continue a ler “Seja o que quiser ser e também seja um desenvolvedor de software!”

Agile Day 2013 em Porto Alegre!

Para fechar o ano do Grupo de Usuários de Metodologias ágeis do RS (GUMA-RS), lançamos o Agile Day Porto Alegre 2013, evento confirmado para o dia 11/dezembro.

Teremos várias palestras e neste dia faremos uma ação trabalhando para que as pessoas possam ter contato com linguagens de programação que não tem tanto contato. Serão várias “Hour of Code”. É isto aí.

Se você manda bem em Java e não conhece C#, fica o convite para você participar do Coding Dojo de C# que vai ser organizado pelo DevRS.NET. Se você não conhece sobre User Experience, vai poder participar de uma dinâmica para ganhar mais habilidades. JavaScript, C#, Ruby, Java, Delphi, serão as opções de linguagens de programação durante este dia.

Quer praticar programação? Coding Dojo!

Todos times deveriam ter um momento de prática. Um momento para desligar e viver situações diferentes. Treinar programação. Compartilhar pensamentos que não apareceriam no dia a dia de projeto.

Um Dojo é o lugar do caminho, é a casa dos praticantes de artes marciais. Desenvolvimento de Software além de ser uma atividade criativa, é uma arte. E como tal, deve ser estudada, praticada, e melhorada de forma constante.

A troca de experiências que ocorre em uma sessão de treinamento, entre pessoas com mais experiência e iniciantes é algo  único, uma oportunidade de aprender e de ensinar. De colaborar e ajudar na formação de melhores desenvolvedores.

É um ambiente de colaboração. Competição não possui lugar. É um ambiente de treinamento, onde práticas do eXtreme Programming como Desenvolvimento Orientado a Testes (TDD), Design Simples, Programação em Pares e Posse Coletiva podem ser compartilhadas. As ideias devem ser provadas com código. E todo novo código precisa aparecer evoluindo dentro do ciclo do TDD (Red-Green-Refactor). Explico: primeiro se faz a criação de um teste falhando um determinado cenário em foco, depois criar o mínimo necessário de código para fazer o teste passar e por fim aplicar técnicas de refatoração para melhorar a estrutura do código fonte, deixando ele mais simples. Ciclos curtos fazendo isto até fazer o que precisa ser feito.

Normalmente para se fazer um dojo se precisa de:

  1. Um problema a ser resolvido. É normalmente um problema de lógica, onde através de técnicas de design, evolução constante do código através da criação de testes e pequenos passos, este problema vai sendo trabalhado e evoluído. Eventualmente se pode chegar na solução do problema, mas o propósito do Dojo é estudar situações e oportunidades de projetar e resolver um determinado problema.
  2. Datashow ou forma de compartilhar o que está ocorrendo com os participantes.
  3. Uma estratégia para tocar o Dojo. Existem algumas, como o (a) Prepared Kata, onde um especialista resolve o problema do início ao fim. O que mais uso, o (b) Randori Kata, possui um timer tocando a cada 5-7 minutos, indicando uma nova rotação a ser feita. Temos apenas um computador sendo usado nesta abordagem, assim como é com o Prepared Kata. A cada rotação o desenvolvedor que ficou na máquina tem a tarefa de passar o conhecimento e situar quem está chegando. Aqui estão as oportunidades perfeitas para parear pessoas com grande diferença de conhecimento. Assim o aprendizado funciona muito melhor. Ainda temos o conceito de (c) Kake Kata, onde pequenos grupos se formam e resolvem o mesmo problena. As rotações ocorrem dentro do grupo e entre grupos. O desafio neste caso comparado com o Randori, é que a cada ciclo, estaremos visualizando código diferente e que não foi tocado anteriormente pelo time. Então o processo de aprendizado tem mais desafios.
  4. Pessoas. Pelo menos 1 pessoa. Se pode fazer um Prepared Kata e gravar para publicar online.  🙂
  5. E o tempo? Uma hora pode ser o suficiente para passar a mensagem e fazer o time trabalhar junto. Gosto de usar 60-80mins de tempo de trabalho.

E quer saber qual a parte mais legal? Esta estrutura de pareamento e colaboração pode ser usada para diversas abordagens! Desenvolvimento de um Business Canvas, escrita de requisitos em um dojo de análise de negócios, e por aí vai.

Update Jan/2019, vídeo sobre Coding Dojo.

Extras:

Dúvida para o seu primeiro Dojo? Pegue um problema simples como o FizzBuzz, escolha uma linguagem, um framework de teste e mande ver!