Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender

Título do Trabalho: Coding-Dojo: Uma forma rápida, eficiente e
divertida de aprender e ensinar
Autor 1: SERGE NORMANDO REHEM
Autor 2: MÁRCIO LIMA ALBUQUERQUE
Tema: Gestão Pública e Responsabilidade Social e Ambiental
Total de páginas: 22

Coding-Dojo: Uma forma rápida, eficiente e divertida de aprender e ensinar
ConSerpro 2010
Congresso Serpro de Tecnologia e Gestão
Aplicadas a Serviços Públicos
2010
2

RESUMO DO TRABALHO
1. Nome dos autores
Autor 1: Serge Normando Rehem
Autor 2: Márcio Lima Albuquerque
2. Lista de palavras chaves para classificação bibliográfica
aprendizado. ensino. treinamento. coding-dojo. dojo. xp. extreme programming.
manifesto ágil. agile. tdd. retrospectiva.
3. Resumo
Programadores não treinam. Ao adentrarem formalmente no mercado de trabalho parece
que perdem aquela prática adquirida em tempos de faculdade ou curso técnico, quando
passavam horas juntos com outros colegas, resolvendo listas de exercício ou trabalhos
finais das disciplinas relacionadas à programação. A pressão por prazos e resultados os
faz "praticar" direto em código de produção, na base da tentativa e erro. Daí a quantidade
absurda de "código esquisito" que vai encontrando (e produzindo!) no decorrer da vida
profissional. Se além de talento, claro, artistas e esportistas praticam diariamente para
alcançar níveis de excelência, por que os profissionais de informática não o fazem? Foi
com base nessa indagação que um grupo de programadores franceses resolveu criar
uma oportunidade para que eles pudessem se reunir e aprender. As sessões foram
batizadas de Coding-Dojo, inspirados no local (pronuncia-se Dojô) utilizado pelos
praticantes de artes marciais - desde os iniciantes até os mestres - para a repetição
sucessiva de movimentos. Um espaço convidativo, não hostil, destinado à troca de
experiencias, tendo como base um desafio de programação. Reuniões curtas (2 horas, no
máximo), utilizando práticas da Extreme Programming (XP) como Desenvolvimento
3

Orientado a Testes (TDD - Test Driven Development), Refatoração, Programação em
Pares, Baby Steps, Código Coletivo e Design Incremental. Os participantes exercitam
suas habilidades de trabalho em equipes, comportamento em público, programação, uso
de processos ágeis, ferramentas e técnicas de desenvolvimento. Ao final, uma
retrospectiva envolvendo todos, destacando o que favoreceu e o que dificultou o
aprendizado. E a constatação de consequências inevitáveis: códigos mais bem escritos,
testados, documentados e preparados para evoluir. Software de qualidade, cliente
satisfeito. Os Dojos estão rapidamente se espalhando pelo mundo, em empresas,
faculdades e comunidades virtuais, sendo até mesmo utilizados em processos de
recrutamento e seleção. Também podem ser facilmente aplicados a contextos diferentes
da programação. Em complemento aos treinamentos tradicionais (onde, muitas vezes, um
fala, os outros escutam, repetem exercícios "copiando e colando", dias depois se
esquecem), uma das regionais do Serpro vem frequentemente realizando Coding-Dojos,
transformando as oportunidades de aprendizado em ocasiões práticas, eficientes,
empolgantes e divertidas. Este trabalho visa apresentar as técnicas e compartilhar as
experiencias vivenciadas, que a cada sessão provocam a vontade de envolver mais
pessoas, disseminar a ideia e partir para novos desafios. Pensar e agir diferente, ampliar
horizontes, aprender, ensinar e trabalhar com alegria.
4

CURRÍCULOS DOS AUTORES
Autor 1: Serge Normando Rehem
SERGE NORMANDO REHEM é PMP, especialista em Sistemas Distribuídos pela UFBA
e possui MBA em Administração pela Unifacs. Analista do Serpro há 12 anos, atualmente
lidera a equipe técnica do Framework Demoiselle, na projeção da Coordenação
Estratégica de Tecnologia (Cetec) na regional Salvador. É líder do grupo de usuários
JavaBahia, colunista da revista Java Magazine e autor do blog bazedral.blogspot.com,
sobre trabalho colaborativo.
Autor 2: Márcio Lima Albuquerque
MÁRCIO LIMA ALBUQUERQUE é mestrando em Sistemas e Computação pela Unifacs e
professor de Processos Ágeis na Pós-graduação da Ruy Barbosa. Está no SERPRO há 5
anos e atualmente lidera o setor de Pool de Pessoas da DESDR. É um dos líderes do
PHPBA, disseminador de desenvolvimento PHP com técnicas ágeis e líder técnico do
projeto RekZit, ferramenta livre para gestão de requisitos.
5

SUMÁRIO
INTRODUÇÃO..................................................................................7
1. A Pedra Fundamental .................................................................7
1.1. De Onde Veio a Motivação......................................................9
1.2. Os Valores do Manifesto Ágil................................................10
2. Aprendendo a Aprender...........................................................11
2.1. A Espiral do Conhecimento.................................................................12
2.1.2. Um Exemplo Bem Que Ajudaria.......................................................14
2.2. A Organização que Aprende...............................................................15
3. O Fantástico Mundo da Programação de Computador.........17
4. Coding-Dojo – A Arte de Treinar Programação.....................19
4.1. Princípios do Coding-Dojo...................................................................20
4.2 Modalidades de Coding-Dojo................................................................22
4.3. Dojo na Prática, Experiencias no Serpro............................................22
CONCLUSÃO..................................................................................25
BIBLIOGRAFIA...............................................................................26
6

INTRODUÇÃO
Começo este trabalho pedindo licença para usar a primeira pessoa do singular1
,
propositalmente contrariando as regras acadêmicas. Buscarei citar as referencias, mas
me darei ao direito de falar diretamente para o leitor, compartilhando minhas ideias e
percepções sem muita formalidade nem rigor estético. Usarei negrito para enfatizar
conceitos e ideias. Esta abordagem tem o objetivo de facilitar tanto a minha escrita quanto
sua compreensão. É um trabalho sobre aprender e ensinar, por isso procuro usar
linguagem e forma que favoreçam a assimilação do conteúdo tratado.
A vontade de escrever esse trabalho surgiu da prática. Embora eu já tivesse lido sobre
Coding-Dojo, sair da inércia e começar a promover e a participar de sessões provocou em
mim - e em vários outros participantes - uma mudança ainda meio que inexplicável de
comportamentos e atitudes. Senti vontade compartilhar esse sentimento, mas ainda não
sabia bem como. Comecei pelo óbvio, disponibilizando os registros de cada reunião em
um site na internet, mais especificamente um grupo de usuários de participação aberta,
que vem agregando novos membros a cada dia.
Se você leu o resumo, pode estar pensando: "mas por que um trabalho sobre técnicas de
aprendizado em programação está num tema relacionado à Gestão Pública e não em
outro mais técnico”? A razão é que não queremos focar nas questões de engenharia de
software, mas sim nas consequências positivas da aplicação de técnicas diferentes
de aprendizado, favorecendo um ambiente de criatividade e inovação. Isso não é o
desejo de todo o bom gestor?
A partir de agora pretendo leva-lo junto comigo nessa história. Topa? Então vamos nessa.
1. A Pedra Fundamental
Desde que tive a ideia de escrever este trabalho, eu queria evitar ao máximo começar
direto falando do Coding-Dojo. Precisaria ir “mais acima”, buscar as “causas raízes”, as
motivações principais que desencadearam esse movimento. Percorri o caminho inverso.
Primeiro observei que na essência do Dojo, como veremos mais adiante, estão várias
práticas da eXtreme Programming (BECK & ANDRES, 2004), que queriam ser
1 É um trabalho de 2 autores, então quando disser EU, entenda que falo em nome de ambos. Quando disser NÓS,
também inclui VOCÊ, leitor.
7

fortalecidas pelos criadores originais do Coding-Dojo. O XP é uma das chamadas
Metodologias Ágeis (REIS, 2008), derivada do Manifesto Ágil2
, cujos detalhes veremos
logo adiante.
Descobri, então, que o signatários originais do Manifesto, 17 nomes proeminentes da
Engenharia de Software, se encontraram em 2001 para compartilhar seus conhecimentos
e experiencias sobre essas metodologias ágeis, todas com alguma inspiração no artigo
The New New Product Game (NONAKA & TAKEUCHI, 1986). Seus autores, professores
universitários japoneses, descrevem um estilo de trabalho para desenvolvimento de novos
produtos que se parece com um jogo de Rugby, mais especificamente numa formação
ordenada conhecida como Scrum. Foi daí que Jeff Sutherland e Ken Schwaber definiram
o framework Scrum (SCHWABER & SUTHERLAND, 2009) e começaram a evangelizá-lo
para o desenvolvimento de software. Na definição da Wikipedia3
, “o Scrum é uma
metodologia de desenvolvimento iterativo e incremental para gerenciamento de projetos e
desenvolvimento ágil ... pode ser utilizado ... como uma abordagem geral de
gerenciamento de projetos/programas”. Em paralelo, Kent Beck deu início à outra
vertente que ficou conhecida como “Extreme Programming (ANDRES & BECK, 2004)”, é
uma metodologia ágil para equipes pequenas e médias que desenvolvem software
baseado em requisitos vagos e que se modificam rapidamente, enfatizando a importância
do feedback constante, a abordagem incremental e o encorajamento da comunicação
entre as pessoas.
Presente em todos esses trabalhos derivados, a filosofia de Respeito pelas Pessoas e
Melhoria Contínua, pilares da Toyota Way (LIKER, 2004) e, portanto, do sistema de
produção da Toyota. A base desse sistema é o Lean Manufacturing (BADURDEEN,
2007), um conjunto de conceitos e procedimentos que visam simplificar o modo como
uma organização produz valor para seus clientes enquanto todos os desperdícios
são eliminados. O Pensamento Lean (JONES & WOMACK, 2003) extrapolou a
manufatura e é também uma forte fonte de inspiração para todo esse movimento. O artigo
on-line de AKITA (2010) sobre Gestão 2.0 me ajudou a montar esta rápida "retrospectiva
reversa", então fica a indicação.
Encontrada essa vertente Agile, eu precisava agora buscar conceitos relacionados a
2 http://pt.wikipedia.org/wiki/Manifesto_Ágil
3 http://pt.wikipedia.org/wiki/Scrum
8

aprendizagem e conhecimento. Seguindo dica de um colega, simpatizante e estudioso do
tema, uma grata surpresa: A obra Criação de Conhecimento na Empresa: Como as
Empesas Japonesas Geram a Dinâmica da Inovação, dos mesmos NONAKA e
TAKEUCHI (2008), é referencia obrigatória. Nela, os autores associam o desempenho
das empresas de seu país à capacidade de gerar novos conhecimentos e usá-los no
desenvolvimento de produtos e tecnologias de grande êxito e alto grau de
inovação. Aí as coisas começaram a fazer ainda mais sentido, não foi uma mera
coincidência. Está tudo realmente interligado.
No restante desta seção vamos explorar um pouco esses fundamentos relacionados a
metodologias ágeis e processos de aprendizagem.
1.1. De Onde Veio a Motivação
Final de 2008, início de 2009, eu já vinha lendo aqui e ali sobre “a tal” das metodologias
ágeis de desenvolvimento de software. Percebia que era um movimento crescente, cada
vez mais gente falando e usando, mas não compreendia bem do que se tratava. Os
“agilistas” pareciam para mim um bando de preguiçosos que não queriam seguir
processos nem fazer documentação. Acham que podem ouvir o cliente e partir direto para
a programação da solução. Pura desinformação e preconceito.
Resolvi que precisava aprender sobre o assunto, até para poder criticar, mas com
embasamento. Eu não queria ficar procurando informações aleatoriamente, ia perder
muito tempo. Seria bom ter contato direto com quem já conhece e pratica. “Preciso
participar de um evento que fale disso ai”. Como “Maomé não vai à montanha”, ignorei o
fato que na minha cidade não tinha nada abordando o tema, conversei com alguns
amigos experientes (eu vinha acompanhando seus blogs e os “vendo” palestrar por aí), de
outros estados, e resolvemos realizar um evento4
com cursos e palestras sobre Agile. Eu
ajudei a organizar, aumentei meu networking, aprendi e favoreci o aprendizado de
bastante gente (foram cerca de 180 participantes), movimentei o mercado (profissionais e
a academia) e me diverti. E comecei a praticar imediatamente, aproveitando que estava
mudando de função no Serpro, com uma equipe nova, num desafio que me permitia
experimentar novidades. Isso já tem mais de um ano e meio.
4 O Maré de Agilidade virou um maior sucesso e já percorreu 6 estados. Realizado pela e para a comunidade, vem
disseminando valores, princípios e práticas ágeis pelo Brasil. www.maredeagilidade.com.br.
9

1.2. Os Valores do Manifesto Ágil
Em 2001 um grupo renomado de consultores, analistas e programadores resolveu se
reunir em Utah, EUA, para pensar novas formas de desenvolver software, meio que
insatisfeitos com panorama predominante na ocasião: uma ênfase muito grande em
processos, documentação excessiva, contratos, burocracia. O código estava perdendo
importância, ficando em segundo plano, como se fosse uma mera atividade de traduzir
diagramas em uma linguagem de programação. Justamente aquilo que efetivamente faz
uma aplicação funcionar, o único artefato que realmente pode vir a atender a necessidade
de cliente, através de um produto de software funcionando. Era preciso resgatar alguns
valores, princípios e práticas essenciais. O resultado do encontro é o conhecido Manifesto
Ágil publicado em http://agilemanifesto.org. A Figura 1 tem os Valores5
exibidos na página
inicial.
Figura 1. O Manifesto Ágil.
5 Coloquei a inicial em maiúsculo para enfatizar sua importância no contexto deste trabalho. A palavra tem muitos
significados, utilizar aqui uma das definições da Wikipedia: “Os valores humanos são os fundamentos éticos e
espirituais que constituem a consciência humana. São os valores que tornam a vida algo digno de ser vivido,
definem princípios e propósitos valiosos e objetiva fins grandiosos.”. Fonte:
http://pt.wikipedia.org/wiki/Valor_(filosofia)
10

Peço que leia atentamente o que está sendo dito. Agora respire fundo, pare um pouco e
reflita sobre a profundidade do que está escrito. Agora releia trocando a palavra
“software” por “produto”, de qualquer natureza. Consegue perceber a universalidade do
manifesto?
No site há também um link para 12 princípios, muitos deles com foco direto em software.
Destaco 3 (os grifos são meus):
• Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e
suporte necessário, e confiar que farão seu trabalho.
• O Método mais eficiente e eficaz de transmitir informações para, e por dentro de
um time de desenvolvimento, é através de uma conversa cara a cara.
• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se
ajustam e otimizam seu comportamento de acordo.
Olhando valores e princípios podemos observar o quanto eles estão buscando dar a
devida importância às pessoas, a comunicação direta, o feedback, a colaboração a
confiança, a melhoria contínua. Questões que deveriam estar presentes na essência de
qualquer equipe excelente.
2. Aprendendo a Aprender
Treinamento. Essa é “top of mind”. Quando falamos de aprendizado, normalmente a
imagem que nos vem à cabeça é a de um professor de pé, com um giz branco na mão
escrevendo num quadro negro (não sei porque esse nome, pois comumente são verdes),
“transferindo” o conhecimento para seus aprendizes. Tem sido assim desde as nossas
mais tenras lembranças da escola. “Ah, mas agora não é mais desse jeito, o mundo
mudou”, você pode estar pensando. Será?
Quadro negro e giz foram trocados por pincéis atômicos, flip-charts e quadros brancos,
surgiram as transparências (aquelas mesmo, impressas num papel transparente e
projetadas na parede por aquele aparelho que acendia uma luz.... como era o nome
mesmo?) e agora os slides (já reparou que ainda continuamos o vício de chama-los de
transparências?) das apresentações PowerPoint (prefiro o BrOffice, é gratuito e o código-
fonte está disponível sob licença livre) e data shows, tudo computadorizado. Mas ainda é
o velho e bom mestre, repassando toda a sua sabedoria para os ansiosos aprendizes.
11

Somos muitos condicionados a copiar, a repetir, a decorar, mas efetivamente será
que aprendemos a raciocinar?
Como tudo na vida, este modelo tem vantagens e desvantagens. Na escola, cumpre seu
papel, até porque – na sua maioria - os exames de ensino médio e vestibulares são
condizentes com ele. Mas na empresa, quantas e quantas vezes percebemos tempo e
dinheiro jogado fora com “treinamentos que não servem para nada”? As razões para
a falta de efetividade são diversas, vou relacionar algumas: “O professor não tinha
didática”, “O material fornecido era de baixa qualidade”, “A carga horária foi insuficiente”,
“O coffee-break estava fraco”, “Eu até aprendi, mas não tenho oportunidade imediata de
aplicar, então quando eu realmente precisar vou ter que ser treinado de novo”.
Palestras, workshops, seminários, congressos, encontros, …, todos apenas repetem o
mesmo modelo, disfarçado de outros nomes, com outros formatos. Com as mesmas
vantagens e desvantagens.
Será então que essas são as únicas formas de aprender e ensinar? Mas, o que realmente
significa “aprendizagem”? Vamos agora a um pouco de teoria.
2.1. A Espiral do Conhecimento
Derivada do latim apprendere, a palavra aprender significa agarrar, apoderar-se de
alguma coisa. Aprendizagem é, pois, aquisição de um certo saber com ajuda do outro ou
por si só (Silva, 1986). Pela Wikipedia6
, “O processo de aprendizagem pode ser definido
de forma sintética como o modo como os seres adquirem novos conhecimentos,
desenvolvem competências e mudam o comportamento”.
Voltando então ao treinamento tradicional, que citei no item anterior, quantos deles
efetivamente implicaram em uma mudança comportamental? Ah.. por falar nisso você já
deve ter participado daqueles “treinamentos comportamentais”, focados em melhorar a
gestão de pessoas, relacionamento das equipes, abordando palavras bonitas como
coaching e feedback. Tem aquelas dinâmicas legais, né?! Mas o dia-a-dia nos consome e
depois de um tempo “tudo volta a ser como dantes no quartel de abrantes”. Não é culpa
de ninguém em específico, na minha humilde opinião. O problema é que aqueles
conhecimentos para efetivamente serem incorporados no cotidiano precisam ser
praticados, vivenciados. É aí que a “porca torce o rabo”.
6 http://pt.wikipedia.org/wiki/Aprendizagem
12

Trabalhos sobre Gestão do Conhecimento não faltam por aí. Uma “googleada” rápida e
você pode encontrar centenas de artigos e livros. NONAKA & TAKEUCHI (2008)
defendem que a base para o aprendizado organizacional é a transformação do
conhecimento tácito em explicito através da interação social. Não entendeu? Se
preocupa não, a gente consegue.
Vamos começar conceitando. Conhecimento tácito é aquele não escrito, subjetivo, que
está na cabeça das pessoas. Depende dos valores, crenças e habilidades pessoais, das
experiências vividas por cada indivíduo. Por isso é difícil ser formalizado, transferido ou
explicado a outros. Conhecimento explícito, por sua vez, é objetivo, podendo ser
repassado pela linguagem falada, escrita e corporal através de aulas, palestras, livros,
artigos, gráficos, tabelas, documentos, diagramas, vídeos e tantas outras formas.
Segundo NONAKA & TAKEUCHI (2008), os conhecimentos tácito e explicito são
unidades estruturais básicas que se complementam e a interação entre eles é a principal
dinâmica da criação do conhecimento na organização de negócios. Como assim,
“interação entre eles”? Para explicar, os autores criaram uma espiral do conhecimento,
exibida na Figura 2.
Figura 2. Espiral do Conhecimento.
Cada quadrante corresponde a um dos quatro processos elencados, definidos abaixo:
• Socialização é o compartilhamento do conhecimento tácito entre pessoas, por
meio da observação, imitação ou prática. Experiencias e modelos mentais são
compartilhados via trabalho em equipe. Ocorre diálogo frequente e comunicação
face à face (“hum... acho que já li algo sobre isso nesse texto”).
• Externalização é a conversão do conhecimento tácito em explícito. Em outras
palavras, o conhecimento deixa de estar apenas na mente dos indivíduos e passa
13

a ser externado através de textos, diagramas, modelos, metáforas, conceitos,
hipóteses, imagens, vídeos e tantos outros. O código-fonte gerado por um
programador, por exemplo, se encaixa nesta categoria.
• Combinação é o reagrupamento, classificação ou sistematização de
conhecimentos já explicitados. Esta reconfiguração pode levar a novos
conhecimentos. É mais ou menos o que estou fazendo nesta sessão, agregando
informações publicadas por outros autores, tentando esclarecer os conceitos
fundamentais necessários para uma melhor compreensão do que vem a seguir.
• Internalização (ou Interiorização) é o processo de incorporação do conhecimento
explícito em tácito. É o aprendizado pela prática, é fazer com que o conhecimento
seja agregado às rotinas diárias. Todas os demais processos podem contribuir
para a internalização. Leitura, auto-estudos, dinâmicas de grupo, podem auxiliar,
mas nada como a experiencia.
No centro da espiral, a aprendizagem ocorre entre indivíduos da mesma equipe. Quanto
mais afastado deste ponto, significa que o aprendizado ultrapassa as fronteiras
hierárquicas do setor, departamento, superintendência e até mesmo da organização.
2.1.2. Um Exemplo Bem Que Ajudaria
Para ilustrar, vou usar o exemplo do meu pai7
. Ele conta que, ainda criança, sempre que
saía de carro com meu avô, observava atentamente seus movimentos e atitudes no
trânsito. E se imaginava fazendo o mesmo. Sem nunca ter sido formalmente treinado ou
pelo menos lido um manual de direção, meu pai estava iniciando seu aprendizado sem
jamais ter assumido o volante. Chegou o dia, com 14 anos, que meu avô cedeu o lugar de
motorista e lhe deu a primeira oportunidade de praticar. Meu pai conseguiu movimentar o
carro “de primeira”, sem deixar o carro morrer nem uma única vez
A partir de então, meu avô assumiu o papel de mestre e – junto com as “aulas práticas”
passou também a explicar gradativamente os conceitos de direção, leis de trânsito e
mecânica, externalizando e socializando seus conhecimentos e habilidades. Nas
primeiras vezes, nervosismos a cada meia-embreagem, redução de velocidade, mudança
de faixa. Meu pai precisava se preocupar com cada movimento do seu corpo, do carro,
dos outros automóveis, dos pedestres e do ambiente. Informação demais. Aos poucos,
7 Neste caso, o “meu” é de apenas um dos autores, pois esclareço que não somos irmãos
14

todo este aprendizado vai sendo internalizado, conhecimentos e habilidades são
assimilados e adquiridos. Dirigir passa a se tornar algo banal, automático, até
inconsciente (enquanto motoristas, quantas vezes chegamos em algum lugar e nem
sequer lembramos do caminho percorrido?). Não preciso dizer que tirar a carteira de
motorista ao completar 18 anos foi a maior moleza.
Aulas teóricas sobre funcionamento do carro, leis de transito, mecânica, nada disso
efetivamente nos ensina a dirigir. Os instrutores de auto-escola estudam, sistematizam
(combinação), escrevem os módulos de treinamento (externalização), transmitem seus
conhecimentos e experiências em aulas práticas (socialização), tudo isso visando que
aqueles conhecimentos explícitos sobre direção de veículos possam ser transformados
em tácito (internalização), e os novos motoristas possam tirar sua carteira de habilitação,
adquirindo a permissão legal para dirigir.
Busquei esse exemplo banal para tentar explicar os conceitos de uma forma didática.
Vale ressaltar que os quatro processos podem ocorrer simultaneamente, mesmo tendo a
predominância de algum(ns). Neste próprio trabalho está havendo externalização (estou
“pondo pra fora” um bocado de coisas que venho aprendendo), combinação (agregando e
correlacionando conceitos) e socialização (estou compartilhando experiencias, abrindo
meu coração!). Já quanto à internalização, essa depende muito de você.
2.2. A Organização que Aprende
Nas “organizações que aprendem as pessoas expandem continuamente sua capacidade
de criar resultados que elas realmente desejam, onde maneiras novas e expansivas de
pensar são encorajadas, onde a aspiração coletiva é livre, e onde as pessoas estão
constantemente aprendendo a aprender coletivamente” (SENGE, 1999, p. 21).
“Gestão do Conhecimento” já foi termo da moda, tema de muitos seminários, congressos,
artigos e livros. O próprio Serpro é referencia nacional nesta área. Tem livro publicado e
disponível na Internet (SOUZA et al, 2001), escrito por diversos autores, na sua maioria
funcionários da empresa, no verdadeiro espírito e prática de construção coletiva.
Pode parecer impressão minha, mas em geral, efetivamente poucas organizações
(brasileiras, principalmente) realmente deram passos firmes na direção de estimular e
favorecer o aprendizado coletivo. O máximo que conseguiram, e isso sem dúvida foi
importante, mas não o bastante, foi criar suas intranets e portais corporativos, realizando
uma melhor organização, disponibilização e busca das informações organizacionais. A
15

grande questão é que nenhuma mudança organizacional significativa pode ocorrer
sem que haja uma profunda mudança na forma de pensar e interagir das pessoas. A
tradicional ideia do treinamento formal não tem se mostrado suficiente para promover
essas mudanças, por isso e preciso encontrar novos e diferentes caminhos. A cultura
empresarial pode ser, ao mesmo tempo, “mocinho e bandido”.
Veja esses três parágrafos consecutivos da seção sobre Educação Corporativa (SOUZA
et al, 2001, p. 43 e 44), transcritos na íntegra (grifos meus), por se encaixarem
perfeitamente na abordagem que estou adotando:
“Esse novo contexto empresarial redefine o perfil do trabalhador da era do
conhecimento. *Precisa-se de profissionais que aprendam de forma não
convencional e que saibam trabalhar cooperativamente para gerar
soluções inovadoras*. É necessária uma nova abordagem na formação,
agora necessariamente continuada, para que as pessoas permaneçam
produtivas, em condições de acompanhar as mudanças e otimizando seu
tempo. Além disso, a tecnologia vem permitindo desenvolver experiências
para treinar mais pessoas com maior economia.
As empresas começam a perceber a necessidade de transferir o foco
dos esforços de treinamento e educação de eventos em sala de aula,
cujo objetivo é desenvolver qualificações isoladas, para a criação de
uma cultura de aprendizagem contínua, em que os empregados
aprendem uns com os outros e compartilham inovações e melhores práticas
visando solucionar problemas organizacionais reais. O foco do treinamento
vai além do empregado isoladamente para o desenvolvimento da
capacidade de aprendizado da organização, criando situações que permitam
a discussão de problemas comuns e soluções por meio da aprendizagem
coletiva.
Os ambientes de aprendizagem passam a ser reestruturados de forma
a tornarem-se proativos, centralizados, determinados e estratégicos e o
resultado esperado é o “aprender fazendo”, desenvolvendo a capacidade
de aprender e dar continuidade a esse processo na volta ao trabalho."
Preciso dizer mais? Estamos quase prontos para, finalmente, falar sobre o Coding-Dojo.
Antes disso, alguns conceitos básicos sobre Programação, explicados numa linguagem
16

simples e direta. Uma seção dispensável se você já sabe do que se trata, mas útil se você
não é da área de TI.
3. O Fantástico Mundo da Programação de Computador
Quando comecei a faculdade de informática não tinha muita noção do que iria encontrar,
só tinha um sentimento que seria legal “trabalhar com computador”. Fiquei pasmo quando
o professor de lógica de programação revelou que essas máquinas maravilhosas só
“conhecem” ZEROS e UNS. Isso mesmo, os números 0 e 1. Seus circuitos, placas,
transístores, capacitores, memórias, discos rígidos, apenas tem a capacidade de
interpretara ausência (0) e presença (1) de corrente elétrica. A sequencia de zeros e uns
formam instruções específicas (como listar os arquivos de uma pasta, mostrar uma
imagem na tela, enviar um texto para impressão). Como fazem isso numa velocidade
impressionante, temos a sensação que os computadores são superinteligentes por
realizar tanta coisa. A cada clique o mouse temos a impressão que tudo acontece como
num passe de mágica, sem nos dar conta que eles só realizam aquilo que foram
ensinados a fazer.
Quando compramos um computador, ele já vem com com conjunto de programas
instalado. O sistema operacional, que nos ajuda a organizar arquivos, e os aplicativos
utilitários, como o processador de textos que usei para escrever este trabalho. Esses
programas são instruções escritas por um conjunto de programadores e são executadas
vez que solicitamos. Agora imagine escrever programas complexos e cheios de
funcionalidades apenas com sequencias de zeros e uns. Até pode ser possível, mas
inviável né?
Por isso os programadores tem à disposição as linguagens de programação. Instruções
de alto nível, mais próximas dos humanos do que das máquinas. Os programas-fonte
são um conjunto de comandos (armazenados em um arquivo texto) convertidos para a
linguagem da máquina (o programa executável) através de um processo chamado
compilação. Por exemplo, a Calculadora que todo computador tem, precisa de instruções
que saibam somar, dividir, multiplicar e subtrair dois números. Usando a linguagem
Groovy8
, por exemplo, as instruções seriam:
def somar(a, b) { a + b }
8 http://groovy.codehaus.org/
17

def dividir(a, b) { a / b }
def multiplicar(a, b) { a * b }
def subtrair(a, b) { a – b }
A instrução abaixo, então, imprimiria na tela o resultado da soma de 6 e 8.
println “O resultado da soma de 6 e 8 é “ + soma(6, 8)
Os programas normalmente não são tão simples quanto este exemplo, então as
linguagens precisam fornecer estruturas de decisão (realizar uma instrução apenas se
um determinado conjunto de condições for satisfeitas) e laços de repetição (executar um
conjunto de comandos um determinado número de vezes ou até que uma condição de
parada seja encontrada). Para facilitar a vida do programador, existem vários softwares
que ajudam a escrever programas. Conhecidas como IDE (do inglês Integrated
Development Environment), esses ambientes de desenvolvimento integrado fornecem
editores de texto inteligentes, que “conhecem” todas as palavras reservadas (o conjunto
de comandos suportados por determinada linguagem) e por isso as exibem numa
coloração diferente e auxiliam em problemas de sintaxe. Permitem também que os
programas sejam compilados e executados na própria ferramenta, simplificam o processo
de depuração (executar o programa passo a passo para tentar descobrir ou solucionar
defeitos), disponibilizam um sistema de ajuda (os manuais ou helps da linguagem
acessíveis imediatamente) e por aí vai.
Os programas não existem por si só. Eles visam atender necessidades diversas do
mundo real, como gerenciar o processo de matrículas de alunos, o empréstimo de livros
na biblioteca, o pagamento de funcionários de uma empresa, o controle de locação de
veículos, o gerenciamento das rotas dos aviões num sistema de tráfego aéreo, os
cálculos e projeções estatísticas baseadas nas informações de censo demográfico.
Normalmente o caminho entre as necessidades e o programa de computador não é tão
imediato, afinal em sistema tão complexos não dá simplesmente para “ouvir o cliente e
sair programando feito doido”. Existe ciência nisso tudo.
A Engenharia de Software (PRESSMAN, 2006) busca tratar de processos,
metodologias, técnicas e ferramentas que abordam todo o ciclo de desenvolvimento
dessas soluções, indo desde as etapas iniciais de Elicitação de Requisitos (a tradução
das necessidades dos clientes em requisitos computacionais funcionais – as funções que
18

os sistemas devem ter - e não funcionais – performance, usabilidade, escalabilidade),
passando por Análise/Projeto (o desenho da arquitetura da solução),
Implementação/Testes (a codificação na linguagem de programação escolhida e os
respectivos testes), Homologação (a validação formal feita pelo usuário) e Implantação
(a incorporação do sistema nas rotinas operacionais da organização demandante). Depois
que o sistema está no “ar” entra em fase de Manutenção, precisando ser alterado a cada
necessidade de Correção (defeitos), Adaptação (adequação, por exemplo, a alguma
nova legislação) ou Evolução (incorporação de novas funcionalidades).
Pensava que era tudo mais simples? Agora você tem uma breve noção desse fascinante
mundo da programação e da computação. Tem ideia de quanto trabalho e inteligencia
existem nos bastidores dos softwares que usa em seu dia-a-dia, em casa, no trabalho, no
banco, no consultório médico, no aeroporto. A informática está presente – direta ou
indiretamente – em mais coisas da nossa vida do que imaginamos. Se deu conta de
quanto o programador é importante na sua vida e você não sabia?
Agora que você já sabe um pouco sobre Metodologias Ágeis, Aprendizagem e
Programação, finalmente está preparado para conhecer o Coding-Dojo.
4. Coding-Dojo – A Arte de Treinar Programação
O termo talento, numa das definições da Wikipedia9
, é usado para “designar habilidades
inatas das pessoas, ou capacidade natural para realizar determinadas atividades”.
Enfatiza também que “Estudiosos atuais afirmam que mesmo as habilidades
consideradas inatas podem ser desenvolvidas caso haja motivação e com a aplicação de
técnicas apropriadas. Assim, qualquer pessoa está, por exemplo, potencialmente apta a
aprender música, desde que tenha vontade e use as técnicas apropriadas ao estudo de
música”.
Estudos recentes (HUECK, 2010) demonstram que não existem habilidades inatas. Tudo
depende de nós! Chegaram a um número inclusive: 10 mil horas. Essa é a quantidade de
horas que precisa para se tornar um especialista. Acham que Ronaldo “Fenômeno” já
nasceu sabendo futebol? Vejam a infância e adolescência dele: quantas horas acham que
ele passou jogando? Provavelmente, sua mãe deve ter suado para tirá-lo do campinho do
bairro.
9 http://pt.wikipedia.org/wiki/Talento_(aptidão)
19

E Mozart? Quantas horas acham que passava por dia quando criança em frente a um
piano. Ele não é um prodígio à tôa: eram quase 6 horas por dia. Ele realmente compôs
sinfonias aos 12 anos, mas sua primeira obra-prima, considerada como tal por vários
críticos, foi escrita quanto ele já tinha 21 anos de idade, e mais ou menos 10 mil horas de
prática (HUECK, 2010). Quantas horas por dia, programadores gastam praticando
sua arte, sua função?
Diferentes dos artistas ou desportistas, que potencializam seus talentos através de
exaustivas e repetitivas rotinas de treinamento, os programadores saem da faculdade ou
cursos técnicos direto para e empresa, escrevendo seus programas reais “de caneta”,
direto para a produção. É como se um ator saísse da escola de teatro direto para uma
produção da Broadway em Nova Iorque, ou um aprendiz de judô fosse disputar seu
primeiro torneio em plenas Olimpíadas, ou um músico amador tivesse sua estreia num
show solo em pleno Carneggie Hall. Todos poderiam até ser bem sucedidos, mas
podemos imaginar que estatisticamente isto seria exceção.
Um grupo de programadores franceses, praticantes da eXtreme Programming, em
meados de 2003, constatou que – assim como a maioria dos seus colegas de profissão -
eles não tinham o hábito de treinar programação. Para se tornarem melhores em suas
funções, resolveram então se reunir periodicamente para aprenderem uns com os outros,
trabalhando juntos na resolução de um desafio de programação. A essa técnica, deram o
nome de Coding-Dojo. A inspiração do nome veio das artes marciais, também praticadas
por alguns deles. Dojo (pronuncia-se Dojô) é o nome do espaço onde aprendizes e
mestres se juntam para praticar os movimentos da luta, através de repetições sucessivas.
Eles criaram o site CodingDojo.org10
e em dezembro de 2004 fundaram o grupo Paris
Dojo11
. A idéia logo se difundiu pelo mundo com vários grupos de Dojo formados ao redor
do planeta. Aqui no Brasil não foi diferente: Dojo Bahia, Dojo Floripa, Dojo Recife, Dojo
Rio, e Dojo SP, são alguns dos grupos que surgiram.
4.1. Princípios do Coding-Dojo
Como comentado anteriormente, o Coding-Dojo tem como princípios básicos alguns dos
princípios do XP: programação em pares, desenvolvimento orientado a testes (test-driven
development - TDD), pequenos passos (baby steps) e refatoração.
10 http://codingdojo.org
11 http://codingdojo.org/cgi-bin/wiki.pl?ParisDojo
20

A principal ideia da programação em par é ensinar sobre código coletivo, colaboração e
disseminação de conhecimento. A programação em par tem como prática duas pessoas
trabalhando no mesmo código, uma como piloto e outra como copiloto. Elas fazem
revezamento de período em período (por exemplo, 30 minutos). Na outra semana, uma
dessas pessoas saem deste módulo e vão para outro trabalhar com outra pessoa,
enquanto a que permaneceu em seu módulo tem um novo colaborador. E continua assim.
Em algum momento, todos terão passado por todos os módulos, criando a cultura de
colaboração, código coletivo (todos mexeram em tudo) e disseminação do conhecimento
(todos sabem de tudo) (TELES, 2004).
O TDD é uma das práticas do XP mais difíceis de implementar numa empresa. Testes,
normalmente é a etapa que logo descartamos quando estamos atrasados (TELES, 2004).
Por isso, exigir que escrevamos os testes antes mesmo de iniciar a implementação é uma
quebra de paradigma forte para o programador. Segundo a Wikipedia12
, a ideia consiste
em escrever um teste pequeno, que garanta que parte do software rode da maneira
esperada. Ou seja, escrevemos um teste que falha para, depois, implementarmos o
código que faça o teste passar. Isso garante que o código já está testado quando
chegarmos a implementação final. Garante também que possamos refatorar todo o
sistema sem nos preocuparmos, pois os testes apontarão os possíveis problemas e
quebras do sistemas.
Já a refatoração do código nos levam às boas práticas. Refatorar sempre é um dos
mantras do XP (TELES, 2004; KNIBERG, 2007). Refatoramos para melhorar o código
para que este responda melhor aos requisitos não-funcionais do sistema. Isto nos leva
obrigatoriamente às melhores práticas de programação e uso de padrões. E tudo isto feito
cada passo de uma vez. Refatoramos sempre e refatoramos pouco, o necessário.
E finalmente, chegamos aos baby steps: tudo é feito com passos pequenos. Não fazemos
testes enormes; fazemos testes pequenos para testar partes pequenas do software. Não
refatoramos o código todo; refatoramos porções pequenas de cada vez, pois caso quebre
a funcionalidade, podemos estudar o que erramos e consertar, ou mesmo voltar ao código
anterior mais facilmente. Com passos pequenos, chegamos a solução final, um passo de
cada vez, mas tudo bem estudado, testado, executado.
12 http://en.wikipedia.org/wiki/Test-driven_development
21

4.2. Modalidades de Coding-Dojo
Com uso dessas práticas, atualmente, existem duas modalidades de Dojo que os grupos
praticam: o Prepared Kata e o Randori. No primeiro, uma dupla de programadores
estudam uma possível solução para um problema, se preparam anteriormente e, no dia
da apresentação, vão se revezando (como na programação em par) e vão desenrolando a
implementação que praticaram antes. Tudo isso usando TDD, refatoração e baby steps.
No Randori, a solução será feita por todos os presentes. De tempo em tempo (5 a 10
minutos), existe um rodízio de pessoas: o piloto da programação em par, vai para a
plateia, uma pessoa da plateia torna-se copiloto e o copiloto torna-se o novo piloto. Com
isso, todos, em algum momento, tem contato direto com código, tendo livre acesso e
poder sobre este naquele momento. No caso do Randori em específico, algumas regras
se fazem necessárias: todos da plateia podem dar sugestões apenas quando todos os
testes estiverem passando. Enquando os testes não passarem, piloto e copiloto devem
tentar remediar o erro por conta própria (caso o erro seja sintaxe, pode-se ajudar).
O Randori ainda apresenta uma particularidade: a Retrospectiva, uma etapa do XP muito
importante para evolução do processo. Aqui, no Dojo, tem o mesmo intuito: evolução do
processo de aprendizagem. As pessoas registram e comentam sobre o que deu certo no
processo e sobre o que pode melhorar. Com isso, mantemos o que sucesso das práticas
que deram certo e tentamos modificar as práticas do que pode ser melhorado. Ou seja, é
um processo que evolui com o tempo, melhora continuamente.
Sugere-se o uso do Randori com poucas pessoas (entre 15 e 20) e o Kata com um
número maior de pessoas.
4.3. Dojo na Prática, Experiencias no Serpro
Logo na introdução deste trabalho, eu – um dos autores - disse que resolvi sair da inércia
e começar a realizar e praticar sessões de Dojo. Mesmo tendo participado de uma em
novembro de 2009, até então eu só tinha ficado na intenção. Aí tive contato com o
excelente post “Apelo: parem de "ensinar" Comp. I nas faculdades!”13
de Vinícius Teles,
praticamente e disseminador de XP, autor do primeiro livro escrito sobre Extreme
Programming em língua portuguesa. A leitura é altamente recomendada, veja esse
parágrafo:
13 http://blog.improveit.com.br/articles/2010/05/28/apelo-parem-de-ensinar-comp-i-nas-faculdades
22

“Em muitos cursos de computação os calouros têm alguma matéria do tipo 'Comp.
I' com duas aulas por semana, cada uma com duas horas de duração. Imagine se
não houvesse aula, mas apenas Dojo. Então, teríamos duas sessões de Dojo por
semana, durante um semestre inteiro. Se isso fosse adotado, tenho absoluta
certeza de que os calouros chegariam no final do semestre sabendo programar
mais e melhor que 90% daqueles que se formam em computação. E não só isso,
eles saberiam programar mais e melhor que a maioria dos professores
universitários que "ensinam" programação!”
Era a motivação que faltava. Em junho deste ano coloquei no meu twitter que ao voltar de
férias (precisava recarregar as energias) organizaria um primeiro Dojo. Alguns colegas
seguidores que trabalham direta e indiretamente comigo foram bem receptivos à ideia.
Assim que retornei, colocamos em prática. Pesquisei um pouco mais sobre o assunto,
busquei dicas com uma pessoa experiente, defini o desafio e “partimos para o ataque”. O
resultado foi excelente. Tiramos fotos, registramos a retrospectiva e disponibilizamos tudo
livremente na internet, no grupo de usuários Dojo14
de participação aberta (48 membros
até a escrita deste trabalho) que havíamos acabados de fundar.
Ao todo, o grupo já realizou 6 sessões “oficiais”, a cada 15 dias, com público médio de 13
pessoas (mínimo de 9, máximo 15, tendo sempre a participação de “novatos”), usando
linguagens (até agora Java, PHP, JavaScript, Groovy e Python) e ambientes (Eclipse,
NetBeans, editor de texto simples) diferentes. Ao todo, 41 pessoas participaram, sendo 8
convidados de fora do Serpro (quatro, vindo de duas faculdades, mais quatro, de uma
empresa particular). Tivemos até coding-dojos específicos, direcionados para líderes de
equipe (afinal eles são formadores de opinião e servem de modelo para seus liderados) e
equipes de Testes de software. O “fenômeno” está se espalhando, tem Dojos sendo
realizados em faculdades e outras empresas, exatamente como imaginávamos. Existem
grupos de usúarios praticantes de Dojo por todo o Brasil e em vários outros países. Tem
inclusive empresas realizando recrutamento e seleção utilizando a técnica (imaginou
selecionar estagiários sem fazer uma prova, apenas observando seu comportamento,
habilidades e atitudes durante uma sessão de Dojo?)
Nas retrospectivas, mais de 140 registros (81 pontos positivos, 65 pontos de melhoria)
foram efetuados. A título de amostragem, destacamos alguns dos mais interessantes sem
importar a ordem de aparição:
14 http://groups.google.com.br/group/dojo-bahia
23

:-)
• Participação de todos na solução, buscando
nivelar conhecimento
• TDD antevê problemas que não
enxergamos. Foi bom para aprendermos a
metodologia.
• Interação entre piloto e copiloto foi legal
• Improviso!
• Ajuda no aprendizado de programadores
menos experientes
• Ajudou a iniciar o aprendizado de uma
linguagem nova.
• Cooperação entre desenvolvedores
• Aprende-se com os acertos e erros dos que
programam antes.
• Aprendizado;
• Trabalho em equipe;
• Motivação para solucionar o problema;
• Aprendizagem rápida, divertida e dinâmica
:-(
• Não avançamos muito porque fizemos muita
refatoração
• Chegar no horário. Disciplina
• Evitar desvios de foco,conversas paralelas
• Inibição inicial (mas depois houve
descontração da turma)
• Pouca familiaridade com classes de teste
(TDD)
• Confusão entre classes de código
(resolução do problema) e classes de teste.
• Problema poderia ser simplificado;
• A plateia estava muito ansiosa, por isso
houve muitos palpites fora de hora
• Colaboração entre desenvolvedores apenas
após o teste passar. Muitos davam palpites
com o teste falhando.
• Pouco tempo para o problema ser resolvido
• Piloto e copiloto devem comunicar mais o
que estão fazendo
Quadro 1. Consolidado da Retrospectiva das Sessões de Coding-Dojo Serpro
O mais interessante deste processo inteiro é notar no dia-a-dia a mudança de atitude dos
praticantes do Dojo. Naturalmente tornam-se mais proativos, buscam trabalhar mais em
pares, se relacionam melhor em equipe, diminuem o sentimento de posse sobre o “seu”
trabalho, ficam mais abertos a emitir e ouvir opiniões, tornam-se mais colaborativos.
Sentem “sede” de ampliar seus conhecimentos, buscam estudar mais sobre as técnicas
que rapidamente experimentaram nos Dojos, tentam se tornar pessoas e profissionais
melhores. Aumentam o foco no produto, no cliente. Começam a questionar seus líderes e
colegas sobre porque não tem investido em fortalecer as práticas de testes, e também
porque não usam mais a técnica de Dojo em situações cotidianas. Tendem a eliminar
desperdícios. Ficam mais empolgados em utilizar verdadeiramente as Metodologias
Ágeis. Nos corredores, comentam sobre como foi o Dojo anterior, querem saber quando e
como será o próximo, pensam em novos desafios e situações a experimentar.
Observe o quanto um investimento de 4 horas por mês pode fazer tanta diferença. Como
24

já dissemos antes, é o almejado processo de aprendizagem organizacional: “o modo
como os seres adquirem novos conhecimentos, desenvolvem competências e
mudam o comportamento”
CONCLUSÃO
Este trabalho buscou conceituar e demonstrar, através do compartilhamento de
experiencias reais, o quanto formas diferentes de aprendizado podem ser aplicadas com
alto grau de sucesso nas organizações. O Coding-Dojo é apenas um exemplo disso. Seu
fundamento e suas técnicas podem ser adaptados para os mais diferentes tipos de
situação, como na construção conjunta de Cronogramas, Requisitos e Modelos de Análise
e Projeto.
Já temos pessoas mudando sua visão do que deveria ser o aprendizado de novas
técnicas e tecnologias. Já estão questionando mais, se tornando mais pro-ativas, “saindo
da caixa”. Achamos que encontramos uma maneira muito interessante de ser
internalizada na empresa. Uma forma lúdica de aprender, ensinar e se relacionar com os
colegas.
Podemos parecer pretensiosos (notou o uso do plural? Agora já estamos incluindo
VOCÊ), mas estamos plenamente convencidos que é possível “pensar e agir diferente”.
Estimular a criatividade, o trabalho colaborativo, a comunicação, o feedback. Tornar
nosso ambiente de trabalho mais humano, divertido, prazeroso. Fortalecer as relações
interpessoais. Melhorar a qualidade dos nossos trabalhos, a nossa satisfação com os
resultados, os serviços prestados pelo cliente. Favorecer a cultura da inovação, sair da
“mesmisse”, se reinventar.
25

BIBLIOGRAFIA
AKITA, Fábio. O que é Gestão 2.0. Abril Info ON-LINE, 2009. Disponível em:
<http://info.abril.com.br/noticias/rede/gestao20/gestao/o-que-e-gestao-2-0/>. Acesso em:
27 ago. 2010.
ANDRES, Cynthia; BECK, Kent. Extreme Programming Explained: Embrace Change.
Addison-Wesley, 2a edição. 2004
BADURDEEN, Aza. Lean Manufacting Basics, 2007. Disponivel em:
<http://www.leanmanufacturingconcepts.com/LeanManufacturingBook.htm>. Acesso em:
21 ago. 2010.
HUECK, Karin. O Segredo do Sucesso, 2010. Em Superinteressante, edição 280,
julho/2010.
JONES, Daniel T; WOMACK, James P. Lean Thinking: Banish Waste and Create Wealth
in Your Corporation. Free Press, 2003.
KNIBERG, Henrik. Scrum e XP direto das trincheiras. C4Media, 2007.
LIKER, Jeffrey. The Toyota Way - 14 Management Principles: From The World's Greatest
Manufacturer. McGraw-Hill, 2004.
NONAKA, Ikujiro; TAKEUCHI, Hirotaka. The New New Product Game. Harvard Business
Review. 1986.
NONAKA, Ikujiro; TAKEUCHI, Hirotaka. Criação de Conhecimento na Empresa: Como as
Empesas Japonesas Geram a Dinâmica da Inovação. Campus, 2008.
PRESSMAN, Roger S. Engenharia de Software. McGraw-Hill, 2006.
REIS, Daniel F. Conceitos básicos sobre Metodologias Ágeis para Desenvolvimento de
Software (Metodologias Clássicas x Extreme Programming), 2008. Disponível em:
<http://www.devmedia.com.br/articles/viewcomp.asp?comp=10596>. Acesso em: 25 ago.
2010.
SENGE, P. A Quinta disciplina: arte e prática da organização de aprendizagem. 7a ed.
São Paulo: Best Seller, 2000.
SCHWABER, Ken; SUTHERLAND, Jeff. O Guia do Scrum, 2009. Disponivel em:
26

<http://www.scrum.org/scrumguides/>. Acesso em: 23 ago. 2010.
SOUZA, Alcyr M. et. al. Gestão do Conhecimento: Uma experiência para o sucesso
empresarial . Paraná: Ed. Universitária Champagnat , 2001. Disponível em:
<http://www1.serpro.gov.br/publicacoes/gco_site/>. Acesso em: 27 ago. 2010.
TELES, Vinicius. Extreme Programming – Aprenda como Encantar seus Usuários
Desenvolvendo Software com Agilidade e Alta Qualidade. Novatec Editora, 2004.
27

Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (8)

Similaire à Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender

Similaire à Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender (20)

Plus de Serge Rehem

Plus de Serge Rehem (20)

Dernier

Dernier (9)

Coding-Dojo: Uma forma rápida, eficiente e divertida de ensinar e aprender