Coach em Práticas Técnicas

Sobre o autor

Nos últimos 5 anos, Pedro Santos trabalhou como coach de desenvolvimento de software, ajudando organizações a melhorar suas práticas técnicas.

Pedro Santos se viu trabalhando como coach por acaso. No início, ficou um pouco apavorado, pois nunca havia feito isso antes. Já havia realizado sessões isoladas em TDD e desenho de software, mas nunca precisou organizar um programa em uma sequência lógica.

Seu primeiro desafio foi escolher os assuntos do programa.

Quais assuntos?

Após algumas iterações nos materiais do curso, Pedro focou no coach em práticas de XP. Especificamente em TDD, programação em pares, refatoração e desenho simples.

A medida que adquiriu mais experiência, foi capaz de dividir as práticas em assuntos mais refinados.

Seu objetivo era encontrar o caminho mais tranquilo possível para evitar grandes saltos de aprendizado. Outro objetivo foi encontrar assuntos mais agnósticos em linguagem de programação. Alguns temas são fortemente tendenciosos em relação ao paradigma orientado a objetos, Pedro relembra que a maioria das organizações na qual trabalhou utilizava este paradigma. Abaixo temos uma lista dos temas atuais:

• Programação em pares
• Driver-navigator
• Ping-Pong/Popcorn
• Relógio de xadrez (Chess clock)
• Pomodoro
• Rotação de pares
• Dicas de programação em pares
• TDD
• TDD clássico
• Outside-In (Mockist) TDD
• Teste Duplo
• Premissa de prioridade de transformação
• Refatoração
• Produtividade na IDE
• Refatorando smells
• Refatorando código legado
• Desenho simples
• Objetos Calistênicos
• Code smells
• Os quatro elementos do desenho simples
• SOLID

Em que ordem?

Ao longo dos anos, conforme recebia mais feedback, Pedro continuava fazendo experimentos na ordem dos assuntos. Até que atingiu um ponto onde não estava mais realizando mudanças significativas nessa ordem.

Isso não significa que utilizava sempre a mesma ordem. Em algumas circunstâncias realizar ajustes durante os trabalhos torna-se benéfico. Às vezes trabalhamos com pessoas que precisam de uma sessão introdutória sobre conceitos de orientação a objetos. Pedro também possui uma sessão sobre padrões de desenho que às vezes é preciso utilizar. Outra sessão opcional é o domain driven design (DDD).

Foi difícil encontrar uma ordem que não requer grandes saltos, mas ao mesmo tempo procurar evitar a inclusão de material que não é utilizado em "módulos" subsequentes.

Os testes duplos aparecem ao final da lista por esse motivo. Costumava apresentá-los antes, entretanto, até o Outside-In-TDD, nenhum outro módulo exige testes duplos. Portanto, não faz sentido abordar o assunto mais cedo e deixá-lo inativo por um longo período.

Abaixo a ordem atual dos assuntos:

1. Fundamentos de Orientação a Objetos (sessão de introdução opcional).
2. Programação em pares.
3. TDD clássico.
4. Premissa de prioridade de transformação
5. Objetos Calistênicos.
6. Técnicas de refatoração.
7. Code Smells.
8. Código legado.
9. Os quatro elementos do desenho simples.
10. Princípios SOLID.
11. Testes duplos.
12. Outside in TDD.
13. Padrões de desenho (opcional).
14. Introdução à Domain Driven Design (opcional).

Uma vez que a ordem dos assuntos foi definida, os próximos objetivos foram encontrar exercícios para as pessoas praticarem. Praticar é crucial. Apenas a informação não é muito útil. O conhecimento aplicado significa o domínio do assunto. A prática deliberada é a chave para a sucesso.

Quanto tempo?

"Nós somos o que repetidamente fazemos. Excelência então não é um ato isolado, mas um hábito." Aristóteles

Quando iniciou os trabalhos de coach, Pedro tentou executar sessões pareando as pessoas em suas tarefas. Com isso, descobriu que as pessoas ficavam frustradas com essa abordagem pois poderiam perder velocidade em suas tarefas, além disso, nem todas tinham as habilidades necessárias para trabalhar no material em que estavam estudando.

Como uma forma de resolver essa frustração, utilizou os códigos katas, disponíveis publicamente. Funcionou melhor, mas como ainda estavam trabalhando em pares, as interrupções eram um problema. A solução encontrada foi levá-los à um lugar calmo longe de suas mesas e trabalhar nos exercícios.

Posteriormente, tentou trabalhar com pares de desenvolvedores em vez de fazer uma sessão individual de coach. Este formato funcionou melhor, provavelmente porque as pessoas aprendem umas com as outras e não apenas com o coach. Mais tarde, experimentou misturar pessoas de diferentes equipes e criar pares. O objetivo foi verificar se a comunicação entre as equipes seria aprimorada, e funcionou melhor do que o esperado.

No passado foram utilizados vários exercícios, alguns tiveram efeito positivo e outros não. Na tabela a seguir, são apresentados os exercícios que funcionaram bem no domínio das práticas.

As sessões opcionais são executadas apenas se houver tempo disponível e sentir que o pares estão dispostos. Quanto as introduções, são executadas caso tenha necessidade.

Em uma conversa com outro coach, Pedro foi direcionado para a taxonomia de Bloom. Este é um modelo utilizado na educação para definir objetivos de aprendizagem de acordo com os níveis de complexidade.

O modelo define seis níveis de objetivos: Lembre, Compreenda, Aplique, Analise, Avalie, Crie. Quando este modelo é aplicado às práticas técnicas, Pedro garante que as pessoas atinjam pelo menos o nível de aplicação.

Pedro sempre permanece em um assunto até que as pessoas se sintam confortáveis ​​aplicando a prática específica. Apenas lembrar e entender uma prática não é o suficiente e por isso, tenta resistir à tentação de permitir que as pessoas aprendam apenas em um nível intelectual, considerando uma prática aprendida somente quando as pessoas a aplicam corretamente.

Cenários

No trabalho como coach, diversos desafios foram enfrentados. Os mais frequentes e como lidar com eles estão descritos nesta seção.

Cenário I - "Não preciso aprender/melhorar as práticas."

Geralmente essa frase vem de desenvolvedores mais experientes. Se acreditam que não estão dispostos para as sessões de coach, não devem ser pressionados. O coach deve puxar e não empurrar. Pedro trabalha com qualquer pessoa da equipe ansiosa para aprender e trabalhar em conjunto. Com o tempo, começam a disseminar o aprendizado e geralmente as pessoas que não estavam tão empolgadas para participar se tornam mais propensas a fazê-lo. Essa estratégia funcionou muito bem.

Cenário II - "Quero novas informações, não me faça praticar"

Pedro acredita firmemente que a informação sem prática tem pouco valor, certificando-se de explicar isso muito claramente. Caso alguém se recuse a praticar e quer se concentrar nas informações, se recusa a continuar, embora nunca tenha chegado a esse extremo. Em algum momento, as pessoas percebem a importância da prática deliberada. Às vezes, desafia as pessoas a mostrar o que podem fazer com as novas informações. Outra opção é começar o exercício e gradualmente conquistar o interesse das pessoas.

Cenário III - "Não quero um par"

Isso geralmente vem do medo de expor as fraquezas para alguém. Como coach, é preciso contornar esse medo certificando-se de transmitir que o treinamento é um ambiente seguro para aprender. Muitas vezes, na sessão de abertura, comete alguns erros propositais ou demonstra ignorância sobre um assunto para tornar os outros mais confiantes em relação à exposição de seus pontos técnicos fracos.

Como coach, Pedro presta atenção na criação dos grupos. Tenta evitar dinâmicas de poder em pares, então normalmente forma pares com times diferentes e tenta criá-los com pessoas no mesmo nível de experiência. Dessa forma, descobriu que é mais fácil fazer par com um desconhecido, em um cenário de coach.

Cenário IV - "Como medir o sucesso das sessões de coach?"

A resposta comum para essa pergunta é: 'Como medir a qualidade?' A resposta é totalmente subjetiva.

Mesmo que não haja maneira de medir a qualidade a curto prazo, nota-se alguns efeitos colaterais no médio prazo:

1. Existe uma correlação entre as pessoas que completam o programa e as promoções de cargo;
2. O nível de ruído nas equipes aumenta;
3. A quantidade, duração e foco das discussões que surgem das equipes antes e depois das sessões coach aumentam;
4. As discussões são mais focadas em desenho e menos em novas tecnologias, produtos e novos "brinquedos" em geral;
5. As pessoas começam a cuidar e compartilhar mais.

Cenário V - "Quero entender essas práticas, mas não consigo escrever código."

Haviam algumas pessoas interessadas em aprender as práticas, entretanto, não eram engenheiros de software ou tinham escrito código há tanto tempo que se esqueceram de como fazer novamente. Neste caso, Pedro resolve os exercícios, garantindo que entendam o passo a passo do que está sendo feito. Finalmente algumas pessoas começam a fazer os exercícios, alguns nunca, mas todos acabam compreendendo os materiais em um nível muito mais profundo.

Realizando o mesmo exercício antes e depois de adicionar material novo

Esta técnica faz maravilhas. Primeiro pede aos pares que façam os exercícios sozinhos e sem ajuda na implementação. Pedro apenas esclarece os requisitos e normalmente diz que não vai olhar o resultado.

Após a primeira iteração, introduz o novo material e pede aos pares que realizem o mesmo exercício praticando-o. Quando necessário fornece ajuda. Ao final, sugere que comparem as duas versões do exercício.

Deixando eles seguirem

Como coach, Pedro procura trabalhar para uma estratégia final no qual as pessoas treinadas não precisem mais de seu suporte.

A medida que as sessões progridem, oferece cada vez menos ajuda, mas sempre está presente para evitar erros que se transformem em maus hábitos, permitindo que as pessoas errem para então oferecer conselhos.

Nas primeiras sessões, Pedro atua como um loop de feedback. Em sessões posteriores, as pessoas deveriam ter desenvolvido seu próprio loop de feedback interno.

Nas últimas sessões, costuma deixar os pares sozinhos e não oferece ajuda enquanto realizam um exercício. Somente fornece feedback quando o exercício estiver concluído e geralmente como perguntas.

Formato

Pedro trabalhou em diversos formatos:

• Realizando sessões por alguns dias com um grupo (nunca trabalhou com mais de 20 pessoas).
• Pedro acredita que esse formato é o mais desafiador.

• É difícil evitar interrupções de pessoas fora do grupo.
• É complicado encontrar um horário e um local adequado para todos no grupo.
• Não é fácil fornecer o mesmo nível de feedback personalizado.

• Se puder superar os obstáculos, este provavelmente é o formato mais eficiente.
• Divida o grupo em pares e trabalhe em duas sessões de 90 minutos por semana por par.
• Divida o grupo em dois pares e trabalhe em uma sessão de 120 minutos por semana.

Resumo

Nesta seção, Pedro oferece alguns conselhos gerais para coaches de desenvolvimento de software:

• As pessoas devem dominar as práticas mais peculiares do XP (TDD, refatoração, programação em pares, desenho simples)
• Certifique-se de que as pessoas passem o tempo praticando até que atinjam, pelo menos, o nível de aplicação da taxonomia de Bloom.

• Evite o coach apenas do nível intelectual.

• Idealmente, execute sessões com pares de pessoas.

• Isso permite praticar programação em par e promove o compartilhamento.

• Seja flexível. Se trabalhar com pequenos grupos, pode desviar-se um pouco das regras.
• Trabalhe constantemente para criar um ambiente seguro de aprendizado.
• Quando montar um programa, considere usar um modelo puxar em vez de um modelo empurrar.
• Explique os objetivos de aprendizagem dos exercícios e mantenha as pessoas focadas nesses objetivos.
• Certifique-se de não tornar as pessoas dependentes do coach. Dê a elas cada vez mais espaço à medida em que as sessões avançam.
• Como coach, deverá vestir três chapéus diferentes. Geralmente na seguinte ordem:

• Professor. Nas primeiras sessões, está ensinando a maior parte do tempo, preenchendo qualquer lacunas no conhecimento.
• Mentor. Conforme as sessões avançam, assume um papel de mentor, oferecendo conselhos somente quando necessário.
• Coach. Deixa as pessoas seguirem por conta própria. Tenta orientar realizando perguntas, quando apropriado. Não oferece soluções.

• Com o passar dos anos, descobriu que o que mais falta são as habilidades de desenho de software.
• Todas as práticas e aprendizados não significam nada sem boas habilidades de desenho.

• O desenho simples é a prática mais ambígua no XP.
• Gaste uma quantidade generosa de tempo trabalhando no desenho de software.
• Dê feedback sobre problemas de desenho, discuta abordagens alternativas.
• Incentive as pessoas a conectar os pontos no desenho:

• Objetos Calistênicos -> Code Smells.
• Code Smells -> Os quatro elementos do desenho simples.
• Os quatro elementos do desenho simples -> SOLID.

• Certifique-se de salientar que as pessoas devem incluir todas as outras práticas de XP em seu desenvolvimento/cultura Ágil.
• Enfatize que as equipes não devem parar nas práticas do XP.
• Quais práticas estão usando para descobrir o que construir (requisitos)?
• Quais práticas estão usando para o desenho macro (arquitetura)?
• Quais práticas estão usando para a dinâmica de equipe (SCRUM / Kanban)?
• Quais práticas estão usando para entregar o software (cultura de DevOps)?
• Seja gentil, seja paciente, "seja água meu amigo" Bruce Lee :)
• Divirta-se.

Pedro Santos está escrevendo um livro mais aprofundado sobre práticas de técnicas ágeis. Siga-o no twitter para atualizações sobre o progresso do livro (@pedromsantos).

Sobre o autor

Pedro Santos tem mais de 25 anos de experiência em desenvolvimento de software. Recentemente passou a se concentrar em educar e inspirar outros desenvolvedores.

Passou centenas de horas realizando sessões em pares, treinando e ensinando desenvolvedores. Trabalhou com desenvolvedores em conceitos básicos de programação, desenho orientado a objetos, refatoração de código legado, práticas de teste, decisões de arquitetura e opções de desenvolvimento de carreira.