Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Empfohlen
Empfohlen (20)
Coding Dojo - Aprenda codificando em grupo
- 2. CONHECIMENTO ● APRENDER PELO EXEMPLO ● REPETIR ● APRIMORAR
- 3. O QUE É UM DOJO
- 4. O QUE É CODING DOJO
- 7. QUE PROBLEMA TENTA RESOLVER? BUS FACTOR QUALIDADE DISSEMINAR XP
- 9. TDD
- 10. BABY STEPS
- 11. PAIR PROGRAMING
- 12. O QUE TEMOS PARA CONTAR?
- 13. “Estou perdendo meu tempo escrevendo testes quando poderia estar produzindo”
- 14. AUMENTAR A MATURIDADE DOS TIMES
- 15. O DOJO FUNCIONA?
- 16. COMO NÃO FAZER UM CODING DOJO
- 17. FAÇA SEU PRÓPRIO CODING DOJO
Hinweis der Redaktion
- O que mais nos diferencia das outras espécies é uma capacidade maior de gerar e armazenar conhecimento Desde a época das cavernas o homem ver aprimorando sua capacidade de descrever as coisas do mundo. É fato que a escrita, por exemplo, foi a maior invenção já realizada pelo homem, porém, em nossa evolução, viemos aprendendo durante centenas de milhares de anos efetivamente pelo EXEMPLO e pela PRÁTICA
- Prática esta, o principal objetivo do DOJO, termo japonês que significa literalmente Lugar do caminho Lugares onde os Japoneses praticavam qualquer tipo de arte relacionada à parte física e luta. O Conceito de que um DOJO é especificamente para artes marciais é um conceito ocidental São normalmente considerados lugares especiais pelos seus usuários, os quais também realizam sua limpeza e manutenção, que além do óbvio, serve para reforçar a ideia de que o DOJO deve ser gerenciado e mantido pelos “alunos” e não pelo grupo que o disponibiliza de fato, uma instituição educacional, normalmente.
- É um lugar para os desenvolvedores apurarem suas técnicas, praticarem as disciplinas que envolvem o Desenvolvimento de Software. Há pouca informação acerca de sua origem, mas nossos estudos indicam que os primeiros Coding Dojos ocorreram por meados de 2009 nos Estados Unidos, Hoje é uma prática em franca expansão em países de todos os continentes. Nossa missão é trabalhar para que a comunidade possa ter maneiras de incentivar as pessoas a serem profissionais melhores
- A primeira das premissas do Coding DOJO é que, sua prática não trata-se de uma competição, o objetivo maior é a prática e o aprendizado. É um ambiente controlado, seguro e sem julgamento
- A segunda premissa do Coding DOJO é: Ele não é um teste, ninguém será avaliado por seu desempenho no DOJO.
- A primeira das premissas do Coding DOJO é que, sua prática não trata-se de uma competição, o objetivo maior é a prática e o aprendizado
- Falar sobre os 3 tipos possíveis de dojo, focar no randori, que é o que nós utilizamos Randori: O método Randori utiliza um único computador ligado a um projetor. Em intervalos de normalmente 5 a 7 minutos dois participantes unem-se para resolver o problema proposto, explicando o processo para a plateia. Para desenvolver a solução utiliza-se o TDD. Um dos participantes é o piloto que comanda o desenvolvimento da função, enquanto o copiloto corrige os erros e aponta o que pode ser melhorado. Os demais participantes não opinam até que um teste passe ou até um pedido de ajuda. Ao término do período o copiloto torna-se o piloto e outro membro do grupo assume o papel de copiloto. Kake: O estilo Kake é uma variação do estilo Randori, porém utiliza diversos computadores e, em cada um, uma dupla deve resolver um problema diferente ou o mesmo problema em linguagens diferentes. Ao término do ciclo, o piloto torna-se copiloto em outra máquina ou retorna para a plateia enquanto o copiloto torna-se o piloto tornando-se responsável por explicar ao novo integrante o problema que está sendo resolvido. Nesse estilo de Dojo a plateia não participa da solução e aguarda para conhecer o problema somente quando faz parte de uma dupla. Kata: O estilo Prepared Kata é semelhante a uma palestra. É utilizado apenas um computador e o participante apresenta um desafio previamente resolvido demonstrando os passos para a construção dos testes e soluções. Os demais participantes podem interromper o apresentador para solucionar dúvidas ou propor melhorias. Ao final, todos os participantes devem estar aptos a reproduzir os passos executados e resolver o mesmo problema.
- No longínquo ano de 2016 eu havia acabado de sair de uma equipe que programava php espaguete (aquele mesmo, que printa HTML na tela) e ido pra uma equipe de C#. Ainda com uma mentalidade ExtremeGoHorse, odiava a ideia de “perder tempo” escrevendo testes. Na época, fazíamos dojos de testes unitários com frequência, para os novos membros do time. Quando participei do primeiro dojo de TDD (foto), consegui entender os porquês de várias coisas que, para mim, eram perda de tempo. Hoje, dificilmente conseguiria implementar ou refatorar uma classe sem ter alguns cenários de testes cobrindo-a. Com a prática, torna-se muito mais fácil abrir a cabeça, do que com alguém te falando que isso ou aquilo realmente funciona.
- Em 2013 eu assumi um cargo de liderança na Senior, com uma missão: criar um projeto que fosse capaz de aumentar a senioridade dos times de desenvolvimento. Sem saber por onde começar, consultei minhas referências em busca de uma ideia, e um amigo sugeriu que eu pesquisasse sobre coding dojos. Rapidamente vi potencial e apresentei um projeto, que foi aprovado pela diretoria e que eu conduzi até 2015. Montei um time para organizar dojos para um público de ~400 pessoas. Fazíamos 1 dojo por mês com grupos heterogêneos
- Explicar para a gestão os porquês de não ser perda de tempo
- Quando iniciei esse projeto na Senior, a mentalidade da organização na época exigia que as pessoas participassem, e que fosse apresentado um ROI do tempo que estávamos investindo nisso. Isso tinha tudo para dar errado, e percebemos isso logo nos primeiros meses. Isto me motivou a fazer um estudo acadêmico para avaliar estatisticamente a eficiência dos coding dojos, e ao levar os resultados para a organização, mudamos o rumo com a compreensão que não é um investimento de retorno imediato, e que a evolução dos indivíduos é sistemática. Foi então que os dojos passaram a ser divulgados, com inscrições abertas e sem compromisso com o ROI, e aí a coisa começou a ficar divertida, as pessoas começaram a se relacionar mais e o aprendizado começou a fluir. Não obrigue as pessoas a participarem Compreenda que é um investimento sistemático e de longo prazo Não inicie um grupo de dojos se o planejamento das entregas do seu time está uma merda. Arrume o processo primeiro para permitir que você e seus amigos possam planejar um tempo da sprint para a melhoria contínua
- Focamos no KATA também aqui… Acho que nesse slide ficará realmente nossa mensagem principal… Encontre um problema a ser resolvido Encontre um mentor, que saiba resolver o problema (se o fluxo ficar travado é foda… precisa de alguém pra destravar) Junte pessoas dispostas É necessária uma cultura de melhoria contínua O planejamento das entregas precisa ser assertivo e bem feito. Senão, aquela sexta-feira do Dojo vai se transformar numa sexta-feira de terminar o que está atrasado Arrume a casa primeiro, busque influenciar para que o time tenha espaço para fazer melhorias em geral, depois convença que o coding dojo é uma boa ferramenta (ou qualquer outra) Comece pequeno, e mostre o valor para engajar outros indivíduos Esteja aberto a receber pessoas novas no time com um dojo amigável e receptivo a novatos, não fale muita coisa alienígena Promova debates sobre a necessidade de melhorias, estude e apresente ideias para seus colegas A liderança pode ser receptiva ou resistente a uma ideia assim. Faça a leitura do cenário e, se a liderança for resistente, lembre que a revolução começa nas massas, então busque influenciar os seus colegas de equipe e em seguida apresentem a ideia em equipe O aprendizado precisa de consistência e recorrência, então influencie para que as pessoas sempre compareçam aos dojos