Eu aprendi em 2019 a criar uma branch no git. Sério. Não é clickbait:) Em seguida explico como eu funciono.
Para quem não desenvolve software, é comum você criar estruturas auxiliares para poder modificar um pedaço do sistema e depois quando entendo que está tudo ok, você integra na linha principal. Pensa em manter uma cópia de um documento e depois a ferramenta ajuda em juntar as diferentes partes.
Eu sempre fui adepto do trunk based development, onde não existem estruturas auxiliares. Você sempre atualiza a raiz do código fonte, e é sua responsabilidade garantir que seu código vai dormir até que alguém diga que ele pode ser liberado para alguém que usa o sistema. Você faz pequenos avanços e cria controles para garantir o funcionamento, como configurações e testes automatizados. E aqui fica visível a diferença entre deploy e release.
Construir conhecimento é um processo, e não se baseia em um evento ou uma chamada pontual. É preciso desenvolver uma cultura de aprendizado ou até melhor, de aprendizagem, e neste contexto as comunidades de prática podem ser o canal certo para fazer acontecer. Nesta palestra vou apresentar conceitos sobre comunidades de prática, exemplos de comunidades do RS que ajudei e ainda ajudo a desenvolver e como estas práticas podem ser levadas para dentro das organizações em uma espécie de plano de ação.
Mais um episódio disponível, agora falando sobre planejamento e a importância dos pequenos ciclos de entrega.
Atender expectativas dos nossos clientes está muito ligado ao foco em entregas pequenas e frequentes, permitindo a percepção de valor de forma contínua. E também permitindo ajustes do fluxo de trabalho.
Muitas empresas não tem a preocupação de treinar programação e nem de aprender coisas novas. Elas terceirizam isso para as comunidades de prática, para os grupos de usuários. Ou para os indivíduos que fazem parte dela.
Dentro da uMov.me temos uma preocupação com aprendizado desde 2009 de forma mais efetiva e desde então temos momentos para prática, com Coding Dojos e treinamentos internos.
E nas escolas, como funciona isso? Como assim, nas escolas?
Em 2001-2002 conheci o JUnit, ferramenta para escrita de testes unitários em Java. Em 2003 entendi mais da importância dela para o desenvolvimento de software. Descobri junto Delphi Unit, PHP Unit e outras várias versões e pude ajudar amigos a conhecem mais de uma cultura de melhoria contínua e de busca por código de qualidade e automatizado.
Daniel de Oliveira, fundador do DFJUG, Grupo de Usuários Java de Brasilia, foi o questionador do episódio 3 do #dwresponde. Ele quer saber sobre Agile, CodingDojo, CodeKata e Shuhari. Esse foi o assunto do vídeo desta semana.
Uma das grandes maneiras de aprender sobre desenvolvimento de software é praticando. Isto pode acontecer com aplicativos de exemplo, mas existem formas mais efetivas.
Todos times deveriam ter um momento de prática. Um momento para desligar e viver situações diferentes. Treinar programação. Compartilhar pensamentos que não apareceriam no dia a dia de projeto.
Um Dojo é o lugar do caminho, é a casa dos praticantes de artes marciais. Desenvolvimento de Software além de ser uma atividade criativa, é uma arte. E como tal, deve ser estudada, praticada, e melhorada de forma constante.
A troca de experiências que ocorre em uma sessão de treinamento, entre pessoas com mais experiência e iniciantes é algo único, uma oportunidade de aprender e de ensinar. De colaborar e ajudar na formação de melhores desenvolvedores.
É um ambiente de colaboração. Competição não possui lugar. É um ambiente de treinamento, onde práticas do eXtreme Programming como Desenvolvimento Orientado a Testes (TDD), Design Simples, Programação em Pares e Posse Coletiva podem ser compartilhadas. As ideias devem ser provadas com código. E todo novo código precisa aparecer evoluindo dentro do ciclo do TDD (Red-Green-Refactor). Explico: primeiro se faz a criação de um teste falhando um determinado cenário em foco, depois criar o mínimo necessário de código para fazer o teste passar e por fim aplicar técnicas de refatoração para melhorar a estrutura do código fonte, deixando ele mais simples. Ciclos curtos fazendo isto até fazer o que precisa ser feito.
Normalmente para se fazer um dojo se precisa de:
Um problema a ser resolvido. É normalmente um problema de lógica, onde através de técnicas de design, evolução constante do código através da criação de testes e pequenos passos, este problema vai sendo trabalhado e evoluído. Eventualmente se pode chegar na solução do problema, mas o propósito do Dojo é estudar situações e oportunidades de projetar e resolver um determinado problema.
Datashow ou forma de compartilhar o que está ocorrendo com os participantes.
Uma estratégia para tocar o Dojo. Existem algumas, como o (a) Prepared Kata, onde um especialista resolve o problema do início ao fim. O que mais uso, o (b) Randori Kata, possui um timer tocando a cada 5-7 minutos, indicando uma nova rotação a ser feita. Temos apenas um computador sendo usado nesta abordagem, assim como é com o Prepared Kata. A cada rotação o desenvolvedor que ficou na máquina tem a tarefa de passar o conhecimento e situar quem está chegando. Aqui estão as oportunidades perfeitas para parear pessoas com grande diferença de conhecimento. Assim o aprendizado funciona muito melhor. Ainda temos o conceito de (c) Kake Kata, onde pequenos grupos se formam e resolvem o mesmo problena. As rotações ocorrem dentro do grupo e entre grupos. O desafio neste caso comparado com o Randori, é que a cada ciclo, estaremos visualizando código diferente e que não foi tocado anteriormente pelo time. Então o processo de aprendizado tem mais desafios.
Pessoas. Pelo menos 1 pessoa. Se pode fazer um Prepared Kata e gravar para publicar online. 🙂
E o tempo? Uma hora pode ser o suficiente para passar a mensagem e fazer o time trabalhar junto. Gosto de usar 60-80mins de tempo de trabalho.
E quer saber qual a parte mais legal? Esta estrutura de pareamento e colaboração pode ser usada para diversas abordagens! Desenvolvimento de um Business Canvas, escrita de requisitos em um dojo de análise de negócios, e por aí vai.
daniel wildt 