Coding Dojo Aprendizagem Colaborativa aplicado ao Desenvolvimento de Softwares Avelino Ferreira Gomes Filho
Um brevíssimo histórico sobre o desenvolvimento de softwares
Anos 60 - Caos
A place for cowboy’s Boehm [2006] descreve que durante os anos 60 popularizou-se as “técnicas” Cowboy Coding.
Cowboy Coding • Padrão Code and fix. • Forte presença do “dono” do código. • Geração de muito...
Anos 70 – Engenharia e Software
Dois passos essenciais no Desenvolvimento de Software [ROYCE, 1970]
Os passos de Royce para grandes sistemas
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.
Abrindo “ ” Não Nos métodos tradicionais
Royce já descrevia no artigo em 1970 Necessidade de um processo iterativo com feedback entre as etapas.
Anos 90 – Métodos Ágeis
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]
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]
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]
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]
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]
Abrindo “ ” Nos métodos ágeis Não
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
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.
Coding Dojo Antes de falarmos sobre Coding Dojo precisamos falar de 2 conceitos: • Aprendizagem Baseada em Problemas • Desenvolvimento Guiado por Testes
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]
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]
O Desenvolvimento Guiado por Testes ou como é mais conhecido TDD (Test Driven Development) foi proposto por Kent Beck em 2003. Desenvolvimento Guiado por Testes
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.
Duas regras são fundamentais no Desenvolvimento Guiado por Testes Desenvolvimento Guiado por Testes
Baby Steps
Dúvidas sobre TDD? Poste uma pergunta no Quora. O próprio Kent Beck responde.
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]
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]
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]
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ê.
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]
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]
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...
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)
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
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.
Minha motivação para realizar essa monografia Realizar um estudo de caso de utilização de Coding Dojo no meu trabalho.
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.
Obrigado

Coding Dojo Aplicado ao Ambiente Organizacional

  • 1.
    Coding Dojo Aprendizagem Colaborativaaplicado ao Desenvolvimento de Softwares Avelino Ferreira Gomes Filho
  • 2.
    Um brevíssimo históricosobre o desenvolvimento de softwares
  • 3.
  • 4.
    A place forcowboy’s Boehm [2006] descreve que durante os anos 60 popularizou-se as “técnicas” Cowboy Coding.
  • 5.
    Cowboy Coding • PadrãoCode and fix. • Forte presença do “dono” do código. • Geração de muito...
  • 7.
    Anos 70 –Engenharia e Software
  • 8.
    Dois passos essenciaisno Desenvolvimento de Software [ROYCE, 1970]
  • 9.
    Os passos deRoyce 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 Nosmétodos tradicionais
  • 12.
    Royce já descreviano artigo em 1970 Necessidade de um processo iterativo com feedback entre as etapas.
  • 13.
    Anos 90 –Métodos Ágeis
  • 14.
    Críticas ao usodos 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 usodos 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 resolveresses 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 2001alguns 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 “ ” Nosmétodos ágeis Não
  • 21.
    Manifesto Ágil Os 4valores 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ãoprecisa 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 defalarmos sobre Coding Dojo precisamos falar de 2 conceitos: • Aprendizagem Baseada em Problemas • Desenvolvimento Guiado por Testes
  • 24.
    Aprendizagem Baseada emProblemas 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 emProblemas 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 Guiadopor Testes ou como é mais conhecido TDD (Test Driven Development) foi proposto por Kent Beck em 2003. Desenvolvimento Guiado por Testes
  • 27.
    Desenvolvimento Guiado porTestes 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ãofundamentais no Desenvolvimento Guiado por Testes Desenvolvimento Guiado por Testes
  • 30.
  • 31.
    Dúvidas sobre TDD? Posteuma pergunta no Quora. O próprio Kent Beck responde.
  • 32.
    Coding Dojo É umaté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 objetivoprincipal 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 • CodingDojo 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 • Thomaspropõ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 Bousavitmais 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 (Randoriou 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) Paratornar 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ãodo 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çãodo 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 pararealizar essa monografia Realizar um estudo de caso de utilização de Coding Dojo no meu trabalho.
  • 43.
    Hipótese As técnicas deaprendizagem 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.