SlideShare uma empresa Scribd logo
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

Mais conteúdo relacionado

Mais procurados

Crystal
CrystalCrystal
Cesar.Edu Turma S2I
Cesar.Edu Turma S2ICesar.Edu Turma S2I
Cesar.Edu Turma S2I
Victor Ximenes
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introdução
Achiles Camilo
 
Palestra Gestão de Requisitos através de práticas Ágeis e Enxutas - Manoel P...
Palestra Gestão de Requisitos através de práticas Ágeis e Enxutas  - Manoel P...Palestra Gestão de Requisitos através de práticas Ágeis e Enxutas  - Manoel P...
Palestra Gestão de Requisitos através de práticas Ágeis e Enxutas - Manoel P...
Manoel Pimentel Medeiros
 
Test-Driven Development - Introdução
Test-Driven Development - IntroduçãoTest-Driven Development - Introdução
Test-Driven Development - Introdução
Hélio Costa e Silva
 
Engenharia De Software e O Software Livre
Engenharia De Software e O Software LivreEngenharia De Software e O Software Livre
Engenharia De Software e O Software Livre
Fabio Sperotto
 
Desenvolvimento de software mundo ideal x mundo real
Desenvolvimento de software  mundo ideal x mundo realDesenvolvimento de software  mundo ideal x mundo real
Desenvolvimento de software mundo ideal x mundo real
Willy Salazar
 
Desenvolvimento de software: Mundo ideal x Mundo real
Desenvolvimento de software: Mundo ideal x Mundo realDesenvolvimento de software: Mundo ideal x Mundo real
Desenvolvimento de software: Mundo ideal x Mundo real
Henrique Schmidt
 
Treinamento TDD - Atech
Treinamento TDD - AtechTreinamento TDD - Atech
Treinamento TDD - Atech
cesarcneto
 
Agilidade de Ponta-a-Ponta com Arquiteturas Evolucionárias
Agilidade de Ponta-a-Ponta com Arquiteturas EvolucionáriasAgilidade de Ponta-a-Ponta com Arquiteturas Evolucionárias
Agilidade de Ponta-a-Ponta com Arquiteturas Evolucionárias
Breno Barros
 
Introdução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anosIntrodução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anos
Dionatan default
 
Criando um ambiente ágil! Lições aprendidas em XP, Scrum e Lean Development
Criando um ambiente ágil! Lições aprendidas em XP, Scrum e Lean DevelopmentCriando um ambiente ágil! Lições aprendidas em XP, Scrum e Lean Development
Criando um ambiente ágil! Lições aprendidas em XP, Scrum e Lean Development
Daniel Wildt
 
Apresentação tcc final
Apresentação tcc finalApresentação tcc final
Apresentação tcc final
Jhool Flores
 
Aula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xpAula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xp
Joaquim Lopes Júnior
 
TDD: A Essência do Mantra
TDD: A Essência do MantraTDD: A Essência do Mantra
TDD: A Essência do Mantra
Dionatan default
 

Mais procurados (15)

Crystal
CrystalCrystal
Crystal
 
Cesar.Edu Turma S2I
Cesar.Edu Turma S2ICesar.Edu Turma S2I
Cesar.Edu Turma S2I
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introdução
 
Palestra Gestão de Requisitos através de práticas Ágeis e Enxutas - Manoel P...
Palestra Gestão de Requisitos através de práticas Ágeis e Enxutas  - Manoel P...Palestra Gestão de Requisitos através de práticas Ágeis e Enxutas  - Manoel P...
Palestra Gestão de Requisitos através de práticas Ágeis e Enxutas - Manoel P...
 
Test-Driven Development - Introdução
Test-Driven Development - IntroduçãoTest-Driven Development - Introdução
Test-Driven Development - Introdução
 
Engenharia De Software e O Software Livre
Engenharia De Software e O Software LivreEngenharia De Software e O Software Livre
Engenharia De Software e O Software Livre
 
Desenvolvimento de software mundo ideal x mundo real
Desenvolvimento de software  mundo ideal x mundo realDesenvolvimento de software  mundo ideal x mundo real
Desenvolvimento de software mundo ideal x mundo real
 
Desenvolvimento de software: Mundo ideal x Mundo real
Desenvolvimento de software: Mundo ideal x Mundo realDesenvolvimento de software: Mundo ideal x Mundo real
Desenvolvimento de software: Mundo ideal x Mundo real
 
Treinamento TDD - Atech
Treinamento TDD - AtechTreinamento TDD - Atech
Treinamento TDD - Atech
 
Agilidade de Ponta-a-Ponta com Arquiteturas Evolucionárias
Agilidade de Ponta-a-Ponta com Arquiteturas EvolucionáriasAgilidade de Ponta-a-Ponta com Arquiteturas Evolucionárias
Agilidade de Ponta-a-Ponta com Arquiteturas Evolucionárias
 
Introdução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anosIntrodução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anos
 
Criando um ambiente ágil! Lições aprendidas em XP, Scrum e Lean Development
Criando um ambiente ágil! Lições aprendidas em XP, Scrum e Lean DevelopmentCriando um ambiente ágil! Lições aprendidas em XP, Scrum e Lean Development
Criando um ambiente ágil! Lições aprendidas em XP, Scrum e Lean Development
 
Apresentação tcc final
Apresentação tcc finalApresentação tcc final
Apresentação tcc final
 
Aula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xpAula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xp
 
TDD: A Essência do Mantra
TDD: A Essência do MantraTDD: A Essência do Mantra
TDD: A Essência do Mantra
 

Semelhante a Coding Dojo Aplicado ao Ambiente Organizacional

Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Developer Academy
 
Coding dojo
Coding dojoCoding dojo
Coding dojo
Sabrina Andrade
 
UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27
Hélio Medeiros
 
Test-Driven Development serve pra mim?
Test-Driven Development serve pra mim?Test-Driven Development serve pra mim?
Test-Driven Development serve pra mim?
Maurício Aniche
 
Coding Dojo
Coding DojoCoding Dojo
Design Patterns - Com Java
Design Patterns  - Com JavaDesign Patterns  - Com Java
Design Patterns - Com Java
Felipe Do Nascimento
 
Engenharia de Software - Unimep/Pronatec - Aula 5
Engenharia de Software - Unimep/Pronatec - Aula 5Engenharia de Software - Unimep/Pronatec - Aula 5
Engenharia de Software - Unimep/Pronatec - Aula 5
André Phillip Bertoletti
 
Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...
Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...
Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...
Maurício Aniche
 
Tdd On Rails
Tdd On RailsTdd On Rails
Tdd On Rails
Cezinha Cezer
 
Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender
Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprenderCoding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender
Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender
Serge Rehem
 
Coding Dojo - Funcionamento
Coding Dojo - FuncionamentoCoding Dojo - Funcionamento
Coding Dojo - Funcionamento
thiagodp
 
Coding Dojo - Aplicando Princípios Ágeis
Coding Dojo - Aplicando Princípios ÁgeisCoding Dojo - Aplicando Princípios Ágeis
Coding Dojo - Aplicando Princípios Ágeis
Lorival Smolski Chapuis
 
Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...
Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...
Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...
Adolfo Neto
 
Guia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
Guia para a competição Ideation Sua Ideia na Prática - Rio de JaneiroGuia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
Guia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
IdeationBrasil
 
Curso Scrum
Curso ScrumCurso Scrum
Curso Scrum
Paulo Furtado
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
Eduardo Mendes
 
Teste Driven Development
Teste Driven DevelopmentTeste Driven Development
Teste Driven Development
Eduardo Carvalho
 
Especificação por meio de exemplos (BDD, testes de aceitação, ...)
Especificação por meio de exemplos (BDD, testes de aceitação, ...)Especificação por meio de exemplos (BDD, testes de aceitação, ...)
Especificação por meio de exemplos (BDD, testes de aceitação, ...)
Fábio Nogueira de Lucena
 
Analise e desenvolvimento
Analise e desenvolvimentoAnalise e desenvolvimento
Analise e desenvolvimento
Gabriel Moura
 
DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014
Rodrigo Campos
 

Semelhante a Coding Dojo Aplicado ao Ambiente Organizacional (20)

Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
 
Coding dojo
Coding dojoCoding dojo
Coding dojo
 
UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27
 
Test-Driven Development serve pra mim?
Test-Driven Development serve pra mim?Test-Driven Development serve pra mim?
Test-Driven Development serve pra mim?
 
Coding Dojo
Coding DojoCoding Dojo
Coding Dojo
 
Design Patterns - Com Java
Design Patterns  - Com JavaDesign Patterns  - Com Java
Design Patterns - Com Java
 
Engenharia de Software - Unimep/Pronatec - Aula 5
Engenharia de Software - Unimep/Pronatec - Aula 5Engenharia de Software - Unimep/Pronatec - Aula 5
Engenharia de Software - Unimep/Pronatec - Aula 5
 
Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...
Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...
Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...
 
Tdd On Rails
Tdd On RailsTdd On Rails
Tdd On Rails
 
Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender
Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprenderCoding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender
Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender
 
Coding Dojo - Funcionamento
Coding Dojo - FuncionamentoCoding Dojo - Funcionamento
Coding Dojo - Funcionamento
 
Coding Dojo - Aplicando Princípios Ágeis
Coding Dojo - Aplicando Princípios ÁgeisCoding Dojo - Aplicando Princípios Ágeis
Coding Dojo - Aplicando Princípios Ágeis
 
Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...
Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...
Coding Dojos para Aprendizagem de TDD - Há Evidências Científicas? - Ignite T...
 
Guia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
Guia para a competição Ideation Sua Ideia na Prática - Rio de JaneiroGuia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
Guia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
 
Curso Scrum
Curso ScrumCurso Scrum
Curso Scrum
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Teste Driven Development
Teste Driven DevelopmentTeste Driven Development
Teste Driven Development
 
Especificação por meio de exemplos (BDD, testes de aceitação, ...)
Especificação por meio de exemplos (BDD, testes de aceitação, ...)Especificação por meio de exemplos (BDD, testes de aceitação, ...)
Especificação por meio de exemplos (BDD, testes de aceitação, ...)
 
Analise e desenvolvimento
Analise e desenvolvimentoAnalise e desenvolvimento
Analise e desenvolvimento
 
DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014
 

Mais de Avelino Ferreira Gomes Filho

Lean kanban Polo digital de manaus
Lean kanban   Polo digital de manausLean kanban   Polo digital de manaus
Lean kanban Polo digital de manaus
Avelino Ferreira Gomes Filho
 
Despencando do Olimpo: As difíceis lições que aprendi ao tentar implantar Mét...
Despencando do Olimpo: As difíceis lições que aprendi ao tentar implantar Mét...Despencando do Olimpo: As difíceis lições que aprendi ao tentar implantar Mét...
Despencando do Olimpo: As difíceis lições que aprendi ao tentar implantar Mét...
Avelino Ferreira Gomes Filho
 
Metodologia de gestão visual acessível para deficientes visuais
Metodologia de gestão visual acessível para deficientes visuaisMetodologia de gestão visual acessível para deficientes visuais
Metodologia de gestão visual acessível para deficientes visuais
Avelino Ferreira Gomes Filho
 
Agilequebrando mais paradigmas: a inclusão de um desenvolvedor cego em um tim...
Agilequebrando mais paradigmas: a inclusão de um desenvolvedor cego em um tim...Agilequebrando mais paradigmas: a inclusão de um desenvolvedor cego em um tim...
Agilequebrando mais paradigmas: a inclusão de um desenvolvedor cego em um tim...
Avelino Ferreira Gomes Filho
 
Levando a Agilidade para além do Desenvolvimento de Software na Administração...
Levando a Agilidade para além do Desenvolvimento de Software na Administração...Levando a Agilidade para além do Desenvolvimento de Software na Administração...
Levando a Agilidade para além do Desenvolvimento de Software na Administração...
Avelino Ferreira Gomes Filho
 
One Laptop per Child: Análise sobre as implementações no Brasil e no Uruguai
One Laptop per Child: Análise sobre as implementações no Brasil e no UruguaiOne Laptop per Child: Análise sobre as implementações no Brasil e no Uruguai
One Laptop per Child: Análise sobre as implementações no Brasil e no Uruguai
Avelino Ferreira Gomes Filho
 
Pornografia na internet: Come ela chega aos seus filhos e como evitá-la
Pornografia na internet: Come ela chega aos seus filhos e como evitá-laPornografia na internet: Come ela chega aos seus filhos e como evitá-la
Pornografia na internet: Come ela chega aos seus filhos e como evitá-la
Avelino Ferreira Gomes Filho
 
Visual Management and Blind Software Developer
Visual Management and Blind Software DeveloperVisual Management and Blind Software Developer
Visual Management and Blind Software Developer
Avelino Ferreira Gomes Filho
 
Agilidade no governo 02
Agilidade no governo 02Agilidade no governo 02
Agilidade no governo 02
Avelino Ferreira Gomes Filho
 
Iscram 2014 Presentation
Iscram 2014 PresentationIscram 2014 Presentation
Iscram 2014 Presentation
Avelino Ferreira Gomes Filho
 
Resumo sobre Recovering from a decade: a systematic mapping of information re...
Resumo sobre Recovering from a decade: a systematic mapping of information re...Resumo sobre Recovering from a decade: a systematic mapping of information re...
Resumo sobre Recovering from a decade: a systematic mapping of information re...
Avelino Ferreira Gomes Filho
 
Engenharia de Resiliência - Estrutura para a gestão de sinais fracos e difusos
Engenharia de Resiliência - Estrutura para a gestão de sinais fracos e difusosEngenharia de Resiliência - Estrutura para a gestão de sinais fracos e difusos
Engenharia de Resiliência - Estrutura para a gestão de sinais fracos e difusos
Avelino Ferreira Gomes Filho
 
Engenharia de Resiliência - Narrando a emergência de um consenso confuso.
Engenharia de Resiliência - Narrando a emergência de um consenso confuso.Engenharia de Resiliência - Narrando a emergência de um consenso confuso.
Engenharia de Resiliência - Narrando a emergência de um consenso confuso.
Avelino Ferreira Gomes Filho
 
Engenharia de Resiliência - Incidentes, indicadores de resiliência ou fragili...
Engenharia de Resiliência - Incidentes, indicadores de resiliência ou fragili...Engenharia de Resiliência - Incidentes, indicadores de resiliência ou fragili...
Engenharia de Resiliência - Incidentes, indicadores de resiliência ou fragili...
Avelino Ferreira Gomes Filho
 
Engenharia de Resiliência - Complexidade, Emergência e Resiliência
Engenharia de Resiliência - Complexidade, Emergência e ResiliênciaEngenharia de Resiliência - Complexidade, Emergência e Resiliência
Engenharia de Resiliência - Complexidade, Emergência e Resiliência
Avelino Ferreira Gomes Filho
 
Engenharia de Resiliência - Características Essenciais da Resiliência
Engenharia de Resiliência - Características Essenciais da ResiliênciaEngenharia de Resiliência - Características Essenciais da Resiliência
Engenharia de Resiliência - Características Essenciais da Resiliência
Avelino Ferreira Gomes Filho
 
Engenharia de Resiliência - Resiliência o Desafio do Instável
Engenharia de Resiliência - Resiliência o Desafio do InstávelEngenharia de Resiliência - Resiliência o Desafio do Instável
Engenharia de Resiliência - Resiliência o Desafio do Instável
Avelino Ferreira Gomes Filho
 

Mais de Avelino Ferreira Gomes Filho (17)

Lean kanban Polo digital de manaus
Lean kanban   Polo digital de manausLean kanban   Polo digital de manaus
Lean kanban Polo digital de manaus
 
Despencando do Olimpo: As difíceis lições que aprendi ao tentar implantar Mét...
Despencando do Olimpo: As difíceis lições que aprendi ao tentar implantar Mét...Despencando do Olimpo: As difíceis lições que aprendi ao tentar implantar Mét...
Despencando do Olimpo: As difíceis lições que aprendi ao tentar implantar Mét...
 
Metodologia de gestão visual acessível para deficientes visuais
Metodologia de gestão visual acessível para deficientes visuaisMetodologia de gestão visual acessível para deficientes visuais
Metodologia de gestão visual acessível para deficientes visuais
 
Agilequebrando mais paradigmas: a inclusão de um desenvolvedor cego em um tim...
Agilequebrando mais paradigmas: a inclusão de um desenvolvedor cego em um tim...Agilequebrando mais paradigmas: a inclusão de um desenvolvedor cego em um tim...
Agilequebrando mais paradigmas: a inclusão de um desenvolvedor cego em um tim...
 
Levando a Agilidade para além do Desenvolvimento de Software na Administração...
Levando a Agilidade para além do Desenvolvimento de Software na Administração...Levando a Agilidade para além do Desenvolvimento de Software na Administração...
Levando a Agilidade para além do Desenvolvimento de Software na Administração...
 
One Laptop per Child: Análise sobre as implementações no Brasil e no Uruguai
One Laptop per Child: Análise sobre as implementações no Brasil e no UruguaiOne Laptop per Child: Análise sobre as implementações no Brasil e no Uruguai
One Laptop per Child: Análise sobre as implementações no Brasil e no Uruguai
 
Pornografia na internet: Come ela chega aos seus filhos e como evitá-la
Pornografia na internet: Come ela chega aos seus filhos e como evitá-laPornografia na internet: Come ela chega aos seus filhos e como evitá-la
Pornografia na internet: Come ela chega aos seus filhos e como evitá-la
 
Visual Management and Blind Software Developer
Visual Management and Blind Software DeveloperVisual Management and Blind Software Developer
Visual Management and Blind Software Developer
 
Agilidade no governo 02
Agilidade no governo 02Agilidade no governo 02
Agilidade no governo 02
 
Iscram 2014 Presentation
Iscram 2014 PresentationIscram 2014 Presentation
Iscram 2014 Presentation
 
Resumo sobre Recovering from a decade: a systematic mapping of information re...
Resumo sobre Recovering from a decade: a systematic mapping of information re...Resumo sobre Recovering from a decade: a systematic mapping of information re...
Resumo sobre Recovering from a decade: a systematic mapping of information re...
 
Engenharia de Resiliência - Estrutura para a gestão de sinais fracos e difusos
Engenharia de Resiliência - Estrutura para a gestão de sinais fracos e difusosEngenharia de Resiliência - Estrutura para a gestão de sinais fracos e difusos
Engenharia de Resiliência - Estrutura para a gestão de sinais fracos e difusos
 
Engenharia de Resiliência - Narrando a emergência de um consenso confuso.
Engenharia de Resiliência - Narrando a emergência de um consenso confuso.Engenharia de Resiliência - Narrando a emergência de um consenso confuso.
Engenharia de Resiliência - Narrando a emergência de um consenso confuso.
 
Engenharia de Resiliência - Incidentes, indicadores de resiliência ou fragili...
Engenharia de Resiliência - Incidentes, indicadores de resiliência ou fragili...Engenharia de Resiliência - Incidentes, indicadores de resiliência ou fragili...
Engenharia de Resiliência - Incidentes, indicadores de resiliência ou fragili...
 
Engenharia de Resiliência - Complexidade, Emergência e Resiliência
Engenharia de Resiliência - Complexidade, Emergência e ResiliênciaEngenharia de Resiliência - Complexidade, Emergência e Resiliência
Engenharia de Resiliência - Complexidade, Emergência e Resiliência
 
Engenharia de Resiliência - Características Essenciais da Resiliência
Engenharia de Resiliência - Características Essenciais da ResiliênciaEngenharia de Resiliência - Características Essenciais da Resiliência
Engenharia de Resiliência - Características Essenciais da Resiliência
 
Engenharia de Resiliência - Resiliência o Desafio do Instável
Engenharia de Resiliência - Resiliência o Desafio do InstávelEngenharia de Resiliência - Resiliência o Desafio do Instável
Engenharia de Resiliência - Resiliência o Desafio do Instável
 

Coding Dojo Aplicado ao Ambiente Organizacional

  • 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...
  • 6.
  • 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]
  • 16.
  • 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
  • 29.
  • 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.