3 Coisas Boas e Ruins Sobre Programar em Par

Programar em par é uma prática muito contraditória e que sempre gera discussões de amor e ódio. É difícil construir argumentos pois, assim como quase tudo em Engenharia de Software, é impossível reconstruir o mesmo cenário. Por exemplo, não dá pra comparar uma estória feita por uma pessoa e por um par e dizer qual foi melhor.

Mas, depois de alguns anos num ritmo de pareamento quase 100% do tempo, eu consegui observar alguns pontos que se repetem, tanto positivos quanto negativos.

O que funciona bem

Melhora no Foco

A qualidade do código geralmente é o tópico mais falado quando se fala sobre as vantagens de programar em par, mas eu acho que vai muito além disso. Geralmente o foco de um par é maior e isso se reflete também na comunicação com outras pessoas, seja por email ou em reuniões. E isso fica mais evidente ainda quando o par precisa se comunicar em outra língua. Fica mais fácil ir para uma reunião sabendo que tem outra pessoa para conversar depois e ter certeza de que você entendeu o que precisa ser feito.

Ter outra pessoa do seu lado, esperando por você, dificulta parar para “ler emails”. Mas ter uma pessoa do seu lado também ajuda a trocar ideias e geralmente simplifica a solução. Várias vezes eu estava pareando (com pessoas menos e mais experientes que eu) e a solução final ficou bem mais simples do que o que eu pensava. É cansativo parear, mas, achando o ritmo certo, os benefícios são bons.

Menos defeitos

Sempre que eu precisei trabalhar sozinho eu gastava uma boa parte do tempo pedindo ajuda para revisar o código e ver se eu não tinha feito nenhuma besteira. E algumas vezes eu fiz besteiras grandes – ou seja em produção – por estar só e não ter ninguém pra me lembrar de fazer aquela pequena mudança.

Dificilmente problemas como esquecer um break point ou uma mensagem de log passam desapercebidos por um par. Falhas na captura de requisitos ou em casos inesperados são encontradas mais facilmente, pois pessoas diferentes tem um maior conhecimento em partes diferentes do sistema.

Continuidade de Contexto

Um problema bem comum é quando alguém que tem muito contexto em uma parte específica do sistema sai de férias, está doente ou sai do projeto. Em alguns casos a empresa tenta “prender” a pessoa pois sabe que se ela sair ninguém mais consegue dar manutenção no sistema.

Quando a equipe programa em par isso dificilmente acontece, pois a pessoa está o tempo todo passando contexto para o seu par. Assim, mesmo que ela tenha muito mais contexto que os outros, geralmente uma ou duas pessoas tem mais contexto que a maioria e conseguem descobrir o que fazer, mesmo que demore um pouco mais. Esse ponto por si já é convincente o suficiente para que uma equipe adote programação em par.

Os desafios de programar em par

Infraestrutura

Pra mim este é o problema mais óbvio com programação em par. OS, teclado, editor de texto e outros similares são os tópicos que mais geram discussões entre desenvolvedores. O que eu vi que melhor resolve esse problema é ter uma estação de trabalho comum a todos, assim cada um continua com suas próprias configurações em seus laptops. Assim o time concorda com um conjunto de ferramentas e configurações sem abrir mão das suas pessoais.

Claro que essa solução possui um custo elevado, mas outras ferramentas podem facilitar o compartilhamento do código e diminuir a dor, como por exemplo criar máquinas virtuais para desenvolvimento. Assim as aplicações e versões serão as mesmas para todos, mas cada um pode editar o código da maneira que preferir.

Fadiga

A melhora no foco do par vem com um preço, as vezes bem alto. É comum ouvir pessoas dizendo que ficam exaustas depois de parear, e infelizmente não existe muito o que fazer sobre isso, a não ser não parear. Entretanto, algo que se pode tentar é estabelecer horários para sessões de pareamento, assim cada um continua com um tempo solitário para descansar um pouco.

Outra alternativa é fazer paradas durante o dia, como sugerido pelo Pomodoro, ou estabelecendo metas e descansando entre elas. Muitas pessoas simplesmente não abrem mão de trabalhar só, então para esses casos é melhor não utilizar programação em par e tentar ganhar seus benefícios de outra forma.

Ego

Esse é ponto bem polêmico. Quando se está pareando é muito importante se manter humilde e aberto para escutar as opiniões do seu par. Muitas vezes eu já vi um par que estava discutindo sobre a solução, ao invés de conversar e apresentar argumentos. Algumas vezes chega ao ponto de que parear fica tão chato que ninguém mais quer fazer.

Essa situação é bem complicada e as vezes é melhor aceitar que é difícil parear, seja com uma pessoa específica ou com a equipe em geral, e procurar outras maneiras de colher os benefícios citados acima.

Vale a pena ou não?

No final tudo depende. O melhor é ter uma conversa com a equipe e chegar a uma conclusão juntos. Com certeza os benefícios são muito bons, mas também é preciso ficar de olho no sentimento geral da equipe para evitar que os problemas sejam maiores que os benefícios.

As melhores sessões de pareamento que já fiz a solução final foi algo que eu não conseguiria fazer, mas que ainda assim sentia que era meu código.

Em breve vou publicar outro texto com uma atividade que fiz com a equipe para discutir maneiras de melhorar o pareamento. Mas essa atividade também pode ser feita para iniciar uma discussão sobre se a equipe quer tentar ou não começar a parear.

Integração Contínua com Snap em 3 passos

Integração Contínua é um conceito que já é amplamente utilizado na prática. E hoje em dia é cada vez mais fácil fazer isso, graças as várias ferramentas livres, como Go, Jenkins e Snap.

O legal do Snap é que é muito fácil pegar um repositório no GitHub e configurar um servidor de Integração Contínua, sem precisar instalar nada!

Vamos ver um passo a passo bem simples pra mostrar o quão fácil é.

1. Crie sua conta no Snap

Acesse www.snapci.com e clique em “Sign in with GitHub”. Pronto, agora você tem sua conta no Snap e pode visualizar facilmente todos os seus builds:

Página inicial do Snap

2. Importando seus builds

Clique no botão “+ REPOSITORY” e selecione o repositório.

Depois disso você vai ser redirecionado para a página de configurar o Build Pipeline, que é basicamente todos as tarefas que serão executadas para validar o seu projeto. No primeiro acesso é feito um tour sobre as principais opções e configurações.

3. Criando um Stage

Basicamente um build pipeline é composto de uma sequência de Stages. Cada Stage possui comandos que serão executados, como rodar determinada suite de testes, compilar e gerar binários, realizar um deploy ou qualquer outra tarefa. Além disso também é possível configurar variáveis de ambiente específicas do Stage.

O Snap já provê um conjunto comum de Stages, basta clicar em “+ ADD STAGE” para ver na barra esquerda exemplos de Stages como RSpec, Cucumber, Gradle, Grunt, além de outros específicos para deploy como Heroku.

Uma vez que o Build Pipeline for definido basta clicar em “► Build now” e ver o build ser executado! As execuções ficam em uma página mostrando todo o histórico:

Sequencia de execuções de Builds no Snap

A cada execução do Build é possível acompanhar os logs ou ver logs antigos, basta clicar em cima do Stage para ver mais informações e editar configurações.

Simples e rápido! Agora você tem um servidor de integração que vai ser executado a cada novo commit 🙂

Dá até pra colocar uma imagem no README com o status mais recente do build:

Imagem atual do Build com Snap no GitHub

Se quiser mais informações e detalhes, basta ir na página de documentação: http://docs.snap-ci.com/getting-started/

E Esse Negócio de Entrega Contínua?

O problema de entregar software

No dia-a-dia de uma equipe que desenvolve software, novas funcionalidades são adicionadas ao sistema atual, ou as já existentes são melhoradas. Assim, entregar uma nova versão é, basicamente, melhorar o sistema.

Quem faz a entrega do sistema geralmente (e idealmente) é o grupo de desenvolvedores. E frequentemente o processo de entrega é dominado pela equipe de desenvolvimento. Vamos citar um exemplo:

A implantação é manual e arriscada, então apenas um certo grupo de pessoas mais experientes fica responsável por colocar a nova versão no ar.

Nesse caso, mesmo que a equipe de Negócios da empresa decida uma data para entregar a nova versão, não seria uma decisão dela, mas sim da equipe de desenvolvimento, se eles poderiam realizar a implantação.

Se as entregas não são muito frequentes, ou não tem frequência nenhuma, fica mais difícil ainda decidir quando implantar.

É bem comum congelar a versão atual em momentos de riscos – durante uma grande promoção de vendas. Não existe previsibilidade e confiança no que vai acontecer quando uma nova versão for entregue.

Realizar entregas frequentes é ainda mais crucial para startups, pois novas ideias precisam ser testadas e avaliadas rapidamente.

Então tá, precisamos melhorar o processo de entrega para que a equipe de negócios tome as decisões sem depender da equipe de desenvolvimento. Como fazemos isso?

Voltando no tempo

Alguns anos atrás começamos a adotar testes automatizados, deixando a máquina fazer o que ela é boa, repetição, e deixando os humanos fazerem o que eles são bons, explorar.

Automatizar o processo de testes manual foi algo tão bom que inclusive evoluiu para o TDD, técnica onde os testes automatizados são feitos antes da implementação do código.

E não parou por ai. Depois de automatizar os testes, decidimos também por automatizar a execução deles. Assim, cada possível mudança do sistema passa por toda a suite de testes e a equipe recebe um feedback bem mais rápido.

Seguindo essa linha de raciocínio, a automação surge como uma resposta para esse problema. Automatizar a maneira como o software é entregue dá maior previsibilidade e confiança para o processo, fazendo com que a equipe de desenvolvimento não seja mais uma dependência.

De volta para o futuro

Nesse outro artigo, Automação Como Pontapé Inicial para Entrega Contínua, eu falo um pouco sobre como a equipe que faço parte conseguiu melhorar o processo de entrega utilizando automação.

Mas automatizar um script não é o suficiente! É preciso garantir que aquilo que será entregue tenha qualidade.

O servidor de Integração Contínua executa somente os testes locais, mas como saber se os serviços externos (software/hardware) estão funcionando? Como saber se esse código vai funcionar como esperado fora do ambiente de desenvolvimento?

Extrapolando a ideia de Integração Contínua, podemos pensar em uma Pipeline de Implementação (Build Pipeline):

Build PIpeline - ThougthWorks Go

A ideia é que cada pedaço de código, além de ser testado pelos testes automatizados, seja também implementado em um servidor de homologação. Dessa forma, não apenas o código é testado, mas também a infra estrutura e o banco de dados.

Ferramentas que controlam e versionam a configuração das máquinas e do banco de dados são muito importantes nesse ponto, pois elas facilitam voltar atrás e verificar onde estão os problemas.

Resumindo: cada commit gerado vai passar por toda a suite de testes, em seguida será implementado em um ambiente de homologação e testes de integração serão feitos lá, garantindo que tudo funcione direitinho.

Quer colocar a mais nova versão do sistema no ar hoje? Basta utilizar o último commit que passou por toda a Pipeline!

Dessa mesma forma fica fácil voltar a versão em caso de problemas graves em produção. Basta utilizar o último commit funcional e realizar uma nova implantação.

Entrega Contínua e Implantação Contínua

A diferença entre Entrega (Delivery) e Implantação (Deploy) Contínua é bem sutil, considere o exemplo a seguir:

Cada commit passa pelo Pipeline de Implantação e testes exploratórios são realizados, mas só no final da iteração é que a nova versão vai ao ar.

Nesse caso a Entrega do sistema é contínua, mas a Implantação não! Cada commit gera uma nova versão do sistema que passará por testes exploratórios, então teremos uma nova versão do sistema para entregar. Mas a decisão de implantá-la fica para o final da iteração.

A Implantação Contínua em ambientes pré-produção pode ser o primeiro passo para conquistar a confiança da equipe de negócios e convencê-los a adotar a Implantação Contínua em produção. Com um processo automatizado e confiável, fica mais fácil prever o que vai acontecer quando uma nova versão do sistema for ao ar.

É comum falar sobre Entrega Contínua como a técnica global que envolve todo o processo de entrega e implantação. Então a técnica da Entrega Contínua se diferencia da maioria das outras técnicas (como TDD, Programação em Par, etc.), pois requer que a equipe de Negócios aceite mudar e que seja parte da mudança.

O planejamento não será mais feito baseando-se no final da iteração ou quando a implementação puder ser realizada, mas sim em quando faz mais sentido que a nova versão seja entregue.

Empresas como Github fazem milhares de implantações por dia (Deploying at GitHub), o que não quer dizer que você deva fazer também. Implantar uma nova versão é uma decisão da equipe de Negócios e a Entrega Contínua faz com que isso seja realidade.

Qual é o truque?

Obviamente falar é bem mais fácil do que fazer. Existem vários problemas para se chegar em um estado onde é possível colocar uma nova versão do sistema no ar sem preocupações.

Como garantir que o testes são suficientes? Como migrar o banco de dados sem derrubar o sistema? E as dependências externas?

Nos próximos posts eu pretendo falar um pouco sobre as pedras que estamos encontrando no caminho da Entrega Contínua. Fique ligado para saber mais!

Pessoas > Papéis

Quantas vezes você já ouviu alguém falando algo do tipo “Os devs estão perguntando …” ou “Eu conversei com a equipe X e …”?

Eu escuto isso muito, quase que diariamente. Talvez esse não seja o seu cenário, o que é muito bom.

Mas se você também ouve isso frequentemente, gostaria de encorajá-lo a tentar mudar a situação.

Papéis

Uma das grandes mudanças na maneira de pensar quando se utiliza alguma forma de desenvolvimento ágil é o foco em pessoas. O primeiro valor do manifesto ágil mostra que o foco sai do processo e ferramentas para os indivíduos e as interações entre eles.

Se você observar algumas metodologias ágeis, é fácil notar a menção a papéis no lugar de cargos. Isso mostra que qualquer pessoa na equipe pode, ou deveria poder, atuar em qualquer papel dentro da equipe, desde que tenha aptidão e vontade para tal.

Geralmente as equipes que eu vejo são dividas em papéis tais como Desenvolvedor, Analistas de Qualidade, Analistas de Negócio e Gerente de Projeto/Iteração. A suas habilidades atuais lhe apontam qual o melhor papel que você pode desempenhar, já os seus desejos profissionais lhe guiam para quais papéis você poderá desempenhar no futuro, e quais habilidades você precisará desenvolver.

Toda essa conversa foi para mostrar que papéis são meras formalidades, já que podem ser intercambiáveis dentro da equipe/empresa. O foco real são as pessoas que compõe a equipe.

Pessoas

O primeiro grande erro de quem fala “Conversei com o time X” ou “Os devs me disseram …” é que essa “entidade” a qual a pessoa está se comunicando não tem nenhuma capacidade de comunicação. Simples, não é possível fala com “os devs” pois não existe “os devs” e sim um grupo de pessoas desempenhando tal papel.

Se alguém falou com “os devs” na verdade falou com algum desenvolvedor específico, ou talvez um par/grupo. Nesse caso ela falou com pessoas e não com o papel dessas pessoas. O quão difícil é então dizer que “Eu conversei com o João e a Maria”?

Posso não poder responder essa pergunta, pois não tenho capacidade de entender tal dificuldade, no entanto eu posso dizer que o benefício de falar “João e Maria” ao invés de “os devs” é gigantesco.

O primeiro grande benefício é a melhoria na Comunicação, que talvez seja a maior fonte de problemas (ou não) para projetos.

Suponha que a informação que João e Maria tem tenha sido difícil de encontrar. Seria menos dispendioso para outra pessoa perguntar diretamente para eles. Ou então, suponha que seja necessário confirmar alguma parte da informação dada. Sabendo quem proveu a informação fica mais fácil decidir a quem perguntar.

Ao citar os nomes a informação ganha credibilidade, caso mais detalhes sejam necessários já se sabe a quem perguntar. De novo, Comunicação é chave para o sucesso de um projeto, seja ele pequeno ou grande.

Um outro benefício é que, ao citar os nomes de João e Maria, eles automaticamente ganham o sentimento de donos da informação e sabem que são responsáveis por ela. Esse aumento na auto-estima tende a tornar as pessoas mais produtivas.

Pessoas>Papéis

Se esse texto não foi suficiente para lhe convencer a tratar as pessoas por nomes e não por cargos/papéis, então vou usar a minha carta na manga: João é João e Maria é Maria! Respeito é bom e proporciana um ambiente de trabalho saudável.

Como nós fazemos Retrospectivas

Uma excelente maneira de manter a melhoria contínua do seu time é realizar retrospectivas. A retrospectiva é uma reunião onde o time conversa sobre melhorias e coisas boas que aconteceram. A prática sugere que as reuniões sejam feitas todo fim de iteração, no entanto eu acredito que elas devem ser realizadas sempre que o time sentir necessidade.

Nesse post eu vou apresentar como a equipe que eu estou atualmente realiza retrospectivas e o impacto delas no nosso processo, positivo e negativo. Também espero dar algumas dicas sobre como melhorar as retrospectivas e garantir que não seja só mais uma reunião chata.

O que é necessário

  • Uma equipe motivada a melhorar
  • Um quadro branco
  • Post-its
  • Um facilitador

Geralmente, o fluxo da retrospectiva é o seguinte:

O facilitar desenha o quadro, de acordo com a técnica, e a equipe preenche vários post-its com ideias e posiciona de acordo com a dinâmica da retrospectiva. Ao final os itens são discutidos e o time sai com um conjunto de itens para que ações sejam tomadas e as melhorias sejam feitas.

Alguns itens podem ter “donos”, que irão garantir que a melhoria seja feita, e outros serão de propriedade coletiva do time. Para não ficar com o sentimento de andar em círculos, pode ser feito o acompanhamento dos itens no começo de cada reunião.

Fuja da mesmice

Não siga uma receita de bolo. Para times novos, onde todo mundo está se acostumando as práticas e não existe alguém com mais experiência em métodos ágeis, talvez seguir algum exemplo pré-determinado seja uma boa ideia.

No entanto não se espante caso o time perca a motivação rapidamente. Aquele modelo onde sempre a mesma pessoa (“Scrum Master”) conduz a reunião seguindo sempre o mesmo modelo e foca apenas no processo, não vai atrair a atenção da equipe, lembre-se que pessoas são mais importantes que o processo!

Na nossa equipe realizamos retrospectivas toda semana, sendo que algumas são apenas com o time local do escritório e outras são com todos os times remotos. Nas reuniões locais sempre temos um membro diferente da equipe como facilitador. Essa pessoa pode sugerir qualquer modelo de retrospectiva que quiser tentar, assim evitamos que as reuniões fiquem chatas.

Possíveis problemas

Um dos possíveis problemas é que muitas ideias apareçam. Não que muitas ideias seja um problema, mas o tempo que a reunião consome do time pode ser um problema. Durante a retrospectiva, é importante que toda a equipe esteja presente, independente de papel ou cargo.

Algumas dicas: leia rapidamente cada ideia e tente agrupa-las em tópicos, diminuindo os itens e mantendo o escopo; priorize pedindo que a equipe vote nos tópicos, garantindo que apenas aquilo que seja de interesse de todo o grupo seja falado.

A retrospectiva não tem como objetivo lavar roupa suja. Apontar dedos vai, na melhor das hipóteses, trazer outro problema. A famosa diretiva da retrospectiva resume bem qual deve ser o sentimento durante uma retrospectiva (http://martinfowler.com/bliki/PrimingPrimeDirective.html):

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
— Norm Kerth

Alguns recomendam até que no começo de cada uma das retrospectivas a diretiva seja lida e que todos os participantes concordem com ela.

Experimente novas técnicas

O modelo básico (o que foi bem, o que pode melhorar e que está ruim) funciona bem e dá uma visão clara para o time de o que como melhorar. No entanto existem vários outros modelos de retrospectivas, alguns exemplos que já utilizamos e que são bem legais:

Starfish

É um modelo bem conhecido de retrospectiva e que permite enxergar um pouco mais longe do que as três perguntas básicas. A divisão do quadro acontece da seguite forma:

Starfish retrospective

A divisão é bem direta e fácil de entender. Vale notar que esse modelo dedica uma parte específica para novas ideias da equipe. Para mais informações, segue o link original (http://www.thekua.com/rant/2006/03/the-retrospective-starfish/)

This person, that person

Esse é um modelo bem interessante e focado totalmente nas pessoas da equipe. A ideia aqui é que os membros da equipe discutam comportamentos bons e ruins. Esses comportamentos não são obrigatoriamente de membros da equipe, não sendo tomados como pessoais mas sim como um feedback coletivo da equipe para a equipe.

A divisão do quadro acontece da seguinte forma: um lado do quadro representa a pessoa que ninguém gostaria de trabalhar e o outro é a pessoa que todo mundo gostaria de ter na equipe:

This person & that person

Para mais informações segue o link original http://agileretroactivities.blogspot.com.br/2013/05/that-guy-this-guy.html?m=1

Outros exemplos

No site http://agileretroactivities.blogspot.com.br/ é possível encontrar vários outros tipos de atividades para realizar na retrospectiva.

Falando sobre práticas

Hoje em dia podemos dizer que as metodologias ágeis deixaram de ser o futuro para se tornar o presente. A maioria dos escritórios com equipe de desenvolvimento utilizam testes, alguns aderem a programação em par, realizam reuniões mais curtas e mais focadas, não planejam todos as possibilidades existentes.

No entanto não é pondo dois desenvolvedores em um computador, realizando reunião em pé e tendo post-it colados na parede que fazem uma equipe ser ágil, e muito menos render como uma equipe ágil. Aplicar práticas apenas para obter resultados dificilmente vai mostrar algum benefício, pois práticas por si só não motivam pessoas.

Se sua equipe está pondo as práticas em prática mas nunca discutiu quais as motivações de utilizá-las, recomendo rever quais são os reais valores e princípios que guiam o seu time. É fácil aplicar programação em par, mesmo que não seja 100% do tempo, mas e quanto a comunicação, coragem, feedback? Alguma vez sua equipe já discutiu sobre isso? É fácil reclamar do código que algum membro da equipe e fazer piadas interna sobre isso, mas e a Propriedade Coletiva de Código? Todos deveriam ser responsáveis por todo o código, não adianta só git-blame.

Práticas

Práticas por si só são estéreis. A menos que você dê algum propósito, dado por um conjunto de valores, elas não fazem muito sentido. Programação em par, por exemplo, não faz sentido como algo para simplesmente ir fazendo.

Essa citação do grande Vinicius Teles [1], um dos responsáveis pela disseminação do XP no Brasil, define bem a importância dos valores e princípios defendidos pelo XP. Até mesmo uma prática bem concreta, como Programação em Par, pode prejudicar o projeto caso não tenha comunicação ou compartilhamento de conhecimento.

Segundo a wikipedia [2] Prática é a realização de uma teoria, então todas as práticas possuem uma teoria que as sustentam. A vantagem da formalização da teoria em prática é que fica fácil disseminar e aplicar o pensamento ágil em vários cenários, dando à equipe algo concreto para seguir e adotar. As práticas mostram um caminho em direção ao pensamento ágil.

Outro ponto extremamente importante quando se fala sobre práticas é o contexto. Assim como quando se fala de Padrões de Projeto, o contexto pode tornar a aplicação da prática impossível. Por exemplo, uma equipe de dois ou três desenvolvedores talvez não se beneficie tanto de uma reunião diária quanto uma equipe de 10 pessoas. Provavelmente a pequena equipe já se comunique o suficiente durante o dia para não precisar de uma stand-up.

Adaptando práticas

Aplicar práticas em uma equipe sem valores pode ser muito prejudicial, no entanto o outro extremo também é possível. Equipes que realmente acreditam nos valores e princípios acabam por perceber que o contexto não é exatamente o ideal e realizam alterações na maneira trivial da aplicação das práticas, adaptando ao seu contexto.

Um “Modelo de Maturidade XP” que eu vi pela primeira vez por Klaus Wuestefeld, e que eu acredito e defendo é:

Nível 1. Usa todas as práticas
Nível 2. Adapta as práticas
Nível 3. Faz qualquer coisa que funcione

No livro The Art of Agile Development [3], Shore e Warden alertam para o fato de não criar sua própria metodologia quando se está iniciando a adoção de Métodos Ágeis. No começo realmente seguir “by the book” é a melhor maneira de testar se, no seu contexto, a metodologia vai trazer um benefício real.

Depois é preciso mover para o segundo nível. As pessoas são diferentes, não adianta empurrar a prática goela a baixo. Se alguém não gosta de Programar em Par, tente outras alternativas, como revisão de código. Nesse ponto o livro de Shore e Warden é excelente, pois discute várias práticas ágeis e no final apresenta possíveis alternativas para quando não é possível aplicá-las. Com o tempo a sua equipe terá sua versão customizada da metodologia.

Faça qualquer coisa que funcione!

Mas antes tenha certeza de que sua equipe não tem o contexto ideal para aplicação de algumas práticas. Antes de chegar nesse nível lembre dos outros dois. Criar novos métodos exige muita maturidade e coragem da equipe, mas podem trazer um valor que não está descrito em nenhuma palestra ou livro. Se todos estão confiantes em tentar algo novo, vá em frente. E se o resultado for bom (ou não) compartilhe! 🙂

Nos próximos posts eu vou tentar falar um pouco mais sobre algumas práticas que são pouco discutidas pela comunidade, como Trabalho Energizado, Retrospectiva, Sentar Junto, mas que fazem uma enorme diferença na produtividade da equipe.

Referências:

[1] http://improveit.com.br/xp/praticas
[2] http://pt.wikipedia.org/wiki/Prática
[3] The art of agile development, James Shore e Shane Warden. O’Reilly, 2008.

Pair Programming

Existem vários artigos por aí falando sobre Pair Programming, muitos deles são bons e realmente ajudam a entender a prática e como iniciar a sua aplicação na sua equipe. Nesse post eu vou falar sobre a experiência que tive com pair programming, comentando os pontos positivos e algumas dificuldades e como elas foram superadas.

Para quem não sabe o que é Pair Programming

Acho que não existe nenhum desenvolvedor que não conheça a técnica, sério.

Alguns pontos importantes a serem notados é que a prática faz parte do XP[1], ou seja, é importante avaliar a prática junto com o resto do ecossistema da metodologia.

A programação em par, junto com as mudanças de pares são o centro da propriedade coletiva de código do XP. A propriedade coletiva do código é o centro da etapa de desenvolvimento do XP, que por sua vez é o centro das interações. Por tanto a programação em par pode ser considerada uma das bases do XP. Para mais informações visite o site oficial do XP [1] e veja o “flow chart” do XP.

Compartilhando o conhecimento

Trabalhar em uma parte do código lhe dá confiança para não só realizar as tarefas que foram atribuídas, mas também discutir sobre as questões que pairam ao redor daquela parte do sistema. Por tanto é muito importante que cada membro trabalhe com o maior parte possível do sistema, idealmente com todo o sistema.

Para que esse conhecimento seja compartilhado por toda a equipe a programação em par desempenha um papel chave. Se você desenvolve uma funcionalidade com alguém, quando outra pessoa vem parear com você ela ganha conhecimento nessa área também. Mais tarde, quando você vai parear com outra pessoa, você ganha conhecimento na outra funcionalidade. A rotação entre os pares também é essencial para esse processo.

Code Review ao extremo

Uma prática não tão comum entre equipes é a revisão de códigos. Uma pessoa que não esteve envolvido na produção do código  olha o código e sugere mudança e avalia os impactos das decisões tomadas na produção do código. A programação em par leva essa prática ao extremo pois enquanto uma pessoa produz o código outra faz a revisão na mesma hora.

O piloto, desenvolvedor que está programando ativamente, tem como preocupação fazer o teste passar o mais rápido possível (considerando que em pleno 2012, não existe desenvolvedor que não escreve testes). O navegador, desenvolvedor que está revisando o código, tem como objetivo analisar o código e avaliar o impacto das decisões considerando o código como um todo.

É importante trocar papéis durante uma seção de pareamento, pois é fácil para o piloto ficar cansado, bem como é fácil para o navegador se distrair com outras coisas. As vezes o entrosamento do par é tão grande que a mudança ocorre naturalmente, com um desenvolvedor peando o teclado para si.

No entanto pode ser importante chegar a um acordo sobre as mudanças, como por exemplo utilizar a técnica do ping-pong, onde uma pessoa escreve o teste, a outra escreve o código para fazer o teste passar e em seguida ambos sugerem refatorações.

Compartilhando a configuração

É importante notar que a programação em par envolve duas pessoas (dahh). Mais do que duas pessoas, dois desenvolvedores. Cada um tem suas opiniões, preferências e esquisitices. As diferenças vão desde o browser preferido até os atalhos personalizados que cada um utiliza. Assim o ambiente de trabalho precisa ser bem semelhante para que ambos os desenvolvedores sintam-se livres para trabalhar.

Uma solução é ter um computador neutro, com configurações que todos concordam, ou pelo menos aceitam utilizar. Desta forma, os desenvolvedores acabam se acostumando a trabalhar com estas configurações e os conflitos são evitados. Além disso cada um pode utilizar seu próprio laptop para resolver problemas pessoais, verificar e-mails etc.

Caso ambos precisem codificar em um computador pessoal, então é melhor que os pares cheguem a um acordo sobre as configurações ou com o tempo revesem o computador em uso para que cada um possa utilizar suas configurações.

Discutindo a relação

Outro ponto importante é sobre o código. Desenvolvedores costumam ter opiniões muito fortes sobre a “melhor maneira” de se resolver algum problema. Se os pares não souberem administrar as diferenças e aceitarem as opiniões uns dos outros, simplesmente não é possível que os pares consigam trabalhar juntos.

Uma boa ideia é juntar programadores experientes com outros menos experientes, assim um pode passar o conhecimento que possui para o outro. Mesmo quando dois desenvolvedores experientes estão pareando, é importante notar duas coisas: (1) o código possui um pouco do seu estilo de programar, ou seja, você consegue reconhecer o código como seu, e (2) o código não parece ser escrito por você por si só, ou seja, o código possui uma parte do estilo do outro desenvolvedor.

Apesar de parecerem opostos, ou até mesmo contrários, os dois pontos acima asseguram que ambos os pares tenham influencia no código produzido. Dessa forma ambos os desenvolvedores tem o sentimento de propriedade do código e podem assumir a responsabilidade pelo que foi feito.

Pair Programming != Mentoring

A programação em par, mesmo entre pares em diferentes estágios de experiência, não deve ser encarada como uma pessoa ensinando outra. Nestes casos, o maior problema é que o par com menos experiência acaba se inibindo e deixando de opinar sobre o código.

O desenvolvedor mais experiente deve deixar espaço para que o desenvolvedor menos experiente opine, pois assim ele tem a chance de refletir sobre o seu conhecimento do sistema. Também é importante que fique claro para ambos os motivos de uma ideia não ser aceita, ao invés de apenas dizer que a ideia não é boa, ou “o meu jeito é melhor”.

Para quem quiser explorar um pouco mais sobre Pair Programming eu recomendo muito o artigo da ImproveIT [2], é bem extenso mas vale muito a pena.

Referências:

[1] http://www.extremeprogramming.org/

[2] http://improveit.com.br/xp/praticas/programacao_par