O documento descreve a evolução histórica dos métodos de desenvolvimento de software, desde os anos 1960 até os métodos ágeis dos anos 1990. Apresenta o Coding Dojo como uma técnica de aprendizagem colaborativa baseada na resolução de problemas de programação em grupo e apoiada pelo Desenvolvimento Guiado por Testes. O objetivo do Coding Dojo não é encontrar soluções, mas disseminar conhecimentos sobre desenvolvimento de software entre os participantes.

1. Coding Dojo
Aprendizagem Colaborativa aplicado
ao Desenvolvimento de Softwares
Avelino Ferreira Gomes Filho

2. Um brevíssimo histórico sobre o
desenvolvimento de softwares

3. Anos 60 - Caos

4. A place for cowboy’s
Boehm [2006] descreve que durante os anos 60 popularizou-se as “técnicas”
Cowboy Coding.

5. Cowboy Coding
• Padrão Code and fix.
• Forte presença do “dono” do código.
• Geração de muito...

7. Anos 70 – Engenharia e Software

8. Dois passos essenciais no
Desenvolvimento de Software
[ROYCE, 1970]

9. Os passos de Royce para grandes
sistemas

10. O modelo Cascata
• O termo foi utilizado pela primeira vez pelo DoD.
• Definiu o desenvolvimento de software como um processo de engenharia
tradicional com fases muito bem definidas.

11. Abrindo “ ”
Não
Nos métodos tradicionais

12. Royce já descrevia no artigo em 1970
Necessidade de um processo iterativo com
feedback entre as etapas.

13. Anos 90 – Métodos Ágeis

14. Críticas ao uso dos métodos tradicionais
para desenvolvimento de software
• Falta de feedback entre as etapas do processo.
• Descoberta de problemas em etapas tardia quando é mais custoso o conserto.
• Falta de adaptabilidade às mudanças do negócio.
[SOMMERVILLE, 1996]

15. Críticas ao uso dos métodos tradicionais
para desenvolvimento de software
• O esforço de planejamento é muito maior do que para outras engenharias.
• Software não é previsível.
• O “peão” do software é um artista.
[TOLEDO, 2010]

17. Desenvolvimento Ágil
Para resolver esses e outros problemas, diversos autores propuseram uma série de
métodos, frameworks e técnicas desenvolvimento de software que
proporcionavam:
• A flexibilidade do escopo
• Produção iterativa, interativa e incremental de software
• Planejamento adaptativo e evolutivo.
[TOLEDO, 2010]

18. Manifesto Ágil
Em 2001 alguns desses autores se juntaram e produziram o Manifesto Ágil. Lá eles
definem 4 valores e 12 princípios que devem ser adotados pelos desenvolvedores
de software.
Os 4 valores são:
• Indivíduos e interações mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano
[BECK et al., 2001]

19. Métodos Ágeis
Métodos Ágeis é um nome guarda-chuva para diversos métodos, frameworks,
processos e técnicas para desenvolvimento e gerência de projetos de software
compatíveis com os valores e princípios definidos no manifesto ágil.
[TOLEDO, 2010]

20. Abrindo “ ”
Nos métodos ágeis
Não

21. Manifesto Ágil
Os 4 valores são:
• Indivíduos e interações mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano
Os 4 valores não são:
• Indivíduos e interações e não processos e ferramentas
• Software em funcionamento e não documentação.
• Colaboração com o cliente e não negociação de contratos
• Responder a mudanças e não seguir um plano

22. Coding Dojo
Você não precisa de Métodos Ágeis ou TDD para fazer Coding Dojo, mas é
necessário quebrar o paradigma tradicional de aprendizagem que podem ser
catalizados por esses métodos e técnicas.

23. Coding Dojo
Antes de falarmos sobre Coding Dojo precisamos falar de 2 conceitos:
• Aprendizagem Baseada em Problemas
• Desenvolvimento Guiado por Testes

24. Aprendizagem Baseada em Problemas
Publicada em 2003 por Diana F Woods na Revista Nacional de Institutos de
Medicina dos Estados Unidos.
Nesse método o aluno utiliza casos reais para adquirir e compartilhar
conhecimento [WOODS, 2003]
O método consiste em:
• Análise inicial do problema pelo grupo.
• Registro do conhecimento atual dos alunos.
• Estudo individual.
• Resolução do problema em grupo.
[WOODS, 2003] e [VENANCIO et al, 2012]

25. Aprendizagem Baseada em Problemas
São métodos adequados ao desenvolvimento de competências e para tal é
necessária a criação de situações desafiadoras...
[PINTO apud VENANCIO et al., 2013]
O objetivo principal não é a solução do problema em si e sim utilizar o problema
real para aprimorar conhecimento e entendimento do grupo.
[WOODS, 2003]

26. O Desenvolvimento Guiado por Testes ou como é mais conhecido TDD (Test Driven
Development) foi proposto por Kent Beck em 2003.
Desenvolvimento Guiado por Testes

27. Desenvolvimento Guiado por Testes
Quebra de paradigma no processo tradicional de desenvolvimento
No TDD a primeira coisa a ser construída é o Teste e depois o código da aplicação.

28. Duas regras são fundamentais no Desenvolvimento Guiado por Testes
Desenvolvimento Guiado por Testes

30. Baby Steps

31. Dúvidas sobre TDD?
Poste uma pergunta no Quora. O próprio Kent Beck responde.

32. Coding Dojo
É uma técnica de aprendizagem colaborativa aplicada ao contexto de
desenvolvimento de softwares.
Tem como essência a Aprendizagem baseada em problema e é apoiada pelo
Desenvolvimento Guiado por Testes.
[DELGADO et al, 2012]

33. Coding Dojo
O objetivo principal do Coding Dojo não é a solução do desafio em si e sim
proporcionar um ambiente de aprendizagem colaborativa onde os programadores
sejam capazes de aprender com os outros e desenvolver suas habilidades e
técnicas de programação
[SATO et al., 2008]

34. Code Kata
• Coding Dojo nasceu da técnica de Code Kata
• Publicado por David Thomas em 2003.
“How do you get to be a great musician? It helps to know the theory, and to
understand the mechanics of your instrument. It helps to have talent. But
ultimately, greatness comes from practicing; applying the theory over and over
again, using feedback to get better every time.
How do you get to be an All-Star sports person? Obviously fitness and talent help.
But the great athletes spend hours and hours every day, practicing.
But in the software industry we take developers trained in the theory and throw
them straight in to the deep-end, working on a project”
[THOMAS, 2007]

35. Code Kata
• Thomas propõe que os problemas devem ser tratados em etapas Katas.
• Um dos participantes cria a solução para o problema e a apresenta para os
demais.
• Passo a passo semelhante a um kata de caratê.

36. Code Randori
Laurent Bousavit mais tarde propôs a ideia de Code Randori
As diferenças são:
• Não há uma divisão de etapas. A dinâmica é feita em rodadas com um limite de
tempo.
• Os participantes chegam à solução em conjunto
• Ninguém sabe previamente a solução.
• Inexiste estudo individual
[DELGADO et al, 2012]

37. Coding Dojo (Randori ou Kata)
Funcionamento:
• O grupo se reúne para definir um problema que deverá ser solucionado.
• O grupo discute diferentes abordagens para solução do problema.
• O grupo realiza a seção de uma sessão de codificação (Coding Dojo)
• Retrospectiva para avaliar como foi o aprendizado durante a sessão.
O objetivo principal não é a solução do problema em si. É a disseminação,
construção e aquisição de conhecimento em desenvolvimento de softwares.
[SATO et al, 2008]

38. Coding Dojo (Randori)
Para tornar mais fácil o processo de solução e auxiliar a aprendizagem, o problema
é tradicionalmente dividido em pequenos testes (TDD).
Com isso os participantes conseguem: Nesse teste vamos resolver essa parte do
problema utilizando...

39. Durante a sessão do Dojo ocorrem diversas rodadas de
programação
• Cada rodada de programação dura de 5 até 7 minutos.
• Antes de cada rodada o grupo discute a possível solução.
• Apenas 2 pessoas implementam a solução (Programação
em Pares) fazendo o papel de Piloto e co-piloto.
• Ao final do tempo definido para a rodada:
• O grupo deve discutir (dúvidas, crítica, sugestões) a solução
apresentada (completa ou incompleta).
• A dupla deve ser trocada.
• Todos devem desempenhar o papel de piloto e co-piloto.
Coding Dojo (Randori)

40. Coding Dojo (Randori)
É muito importante a realização da retrospectiva após a sessão de Dojo.
O conhecimento é gerado pelo grupo para o grupo. Não existe o dono da solução.
O objetivo não é chegar no final da sessão com uma solução pronta e sim
disseminar conteúdo em desenvolvimento de software.
• Trabalho em Equipe
• Técnicas de Programação
• Linguagens
• Frameworks e bibliotecas
• Ferramentas
• Arquiteturas

41. Problemas na utilização do DOJO
• Infraestrutura disponível (espaço físico, equipamentos, mesas, projetores)
• Desnível muito alto entre os participantes do grupo.
• Timidez dos participantes
• Fatores motivacionais de cada integrantes do grupo.
• Cultura da organização.
• Brasileiros são comunicativos [SATO et. al, 2008].
• Em grupo muito grandes a dispersão é mais fácil.

42. Minha motivação para realizar essa
monografia
Realizar um estudo de caso de utilização de Coding Dojo no meu trabalho.

43. Hipótese
As técnicas de aprendizagem colaborativa baseadas em Coding Dojo são capazes
de disseminar os conhecimentos necessários para desenvolver softwares de
acordo com as especificidades da organização.

44. Obrigado