Pair Programming & XP

Introdução

Viemos de uma cultura de desenvolvimento de software que nos obriga a acreditar que bem sucessidos são os programadores que sozinhos desenvolvem, a todo custo, uma aplicação robusta e infalível. Desta maneira, muitas vezes preconceituosamente, vemos opções de trabalho em equipe durante o desenvolvimento como uma demonstração de fraqueza ou ainda da falta de experiência dos programadores. E, inocentes, eliminamos de nossas possibilidades a imagem de um desenvolvimento em grupo.

O conceito de Pair Programming tentar quebrar este paradigma e trazer para o desenvolvimento de software o mesmo processo que é feito há centenas de anos em escolas. Trabalhar em equipe, tendo mais de um indivíduo observando o que é digitado, inspecionando métodos e encontrando alternativas mais elegantes para soluções de problemas é o principal objetivo desta técnica.

O que é Pair Programming?

"Two programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software. " "Pair Programming"

Trocando em miúdos: Duas pessoas trabalhando juntas num mesmo computador, compartilhando código, idéias e soluções.

Mitos relacionados à Programação em Dupla

Um dos princípios de XP é que pessoas com diferentes habilidades e conhecimentos colaborem no projeto. Não se deve limitar, entretanto, apenas a memorandos, planílias, cronogramas e recados ao telefone. Muito além disso, a programação em dupla permite que um programador tenha sempre alguém junto a ele ajudando-o a resolver possíveis problemas.

Entretando, esta prática, por ser culturalmente diferente do que temos como "certo" para o desenvolvimento de software, traz consigo uma série de mitos atrelados que muitas vezes ofuscam a visão de gerentes de projeto ou ainda administradores, fazendo-os nem sequer cogitar a possibilidade de utilização desta prática. Entre os principais mitos e lendas a cerca do tema, foram selecionados alguns para que possam ser discutidos. São eles:

Codigo: Propriedade intelectual do programador

No processo de desenvolvimento todo o ambiente em que o programador se encontra leva-o a criar vínculos desnecessários e raízes profundas relacionadas à mesa em que ele se encontra, ao computador que ele ocupa, ao código que ele escreve. Um ambiente dinâmico em constante mutação deve permanecer atento a esse tipo de atitude pois pode acarretar num problema dificil de ser resolvido.

Uma metáfora interessante ao código fonte de um programa é poesia. Um autor vê sua obra como um bem maior, como uma pedra preciosa e imutável, perfeita e completa. Qualquer menção à hipótese de um simples erro de gramática é motivo para discursos inflamados de defesa do escrito. Não é diferente para o programador, pelo mesmo princípio básico: eu escrevi, logo é meu. Uma nova mudança de paradigma deve ser iniciada para que este programador possa perceber os benefícios da programação em dupla. Tornar o código produzido de domínio público é o primeiro passo para que a programação em dupla possa ter seu melhor aproveitamento.

Durante o desenvolvimento deve-se desmistificar para o programador o fato de que o que está sendo escrito ali é, de alguma maneira mais propriedade dele que de qualquer outra pessoa da equipe, e que, para o bem do software a ser produzido, todos devem poder modificar o que é produzido. A utilização de ferramentas de controle de versão é um ótimo princípio para que a situação seja tratada da maneira adequada.

Nunca ouvi falar, logo não funciona!

A lógica clássica de primeira ordem classifica esse comportamento como sendo um Raciocínio por Ignorância, que ainda hoje é muito utilizado, e faz lembrar bastante a atitude de crianças ao ouvir falar de legumes. É necessário mais que apenas conceitos empoeirados a respeito de que o novo, de maneira alguma substituirá o velho processo de desenvolvimento de software. É necessário a experiência em desenvolvimento em dupla para aque se possa verificar sua eficiência ou seu fracasso.

Pensar bem é pensar sozinho

Em grupo as idéias surgem com maior facilidade, já que a discussão saudável pode maximizar o raciocínio dos participantes para encontrar solução de problemas ditos "impossíveis" de serem resolvidos. Muitas vezes, por cansaço ou por inexperiência, um programador pode não enxegar uma saída óbvia para uma situação problemática que seria facilmente visualizada por um outro programador mais experiente.

Todo o processo de modelagem e codificação fica mais robusto uma vez que ambos os participantes estarão, cada um a sua maneira, expor suas opiniões e defendê-la como uma solução possível. Assim surgem mais opções, ampliando também as possibilidades de escolha.

Compartilhar conhecimento é o princípio básico do aprendizado mútuo e da evolução conjunta da equipe desenvolvedora.

Pontos a favor da Programação em Dupla

Amplia a comunicação da equipe de desenvolvimento

Programar em dupla é comunicar-se o tempo todo. Vale a pena frisar que interessante numa prática de pair programming é não tornar as duplas fixas, mas também mutáveis, dinâmicas. Desta maneira, todos numa equipe estarão em contato com todos, ampliando a fortalecendo a comunicação entre os envolvidos no desenvolvimento do software.

Nivelador de conhecimento

Quanto à diferença de conhecimento entre os programadores. Pair Programming possui várias de implicações, uma delas é que se os parceiros possuem um nível de conhecimento diferente (tanto técnico quanto do sistema), ele tende a nivelar por cima depois de algum tempo. Ou seja, é bom para treinar novatos sem necessariamente parar o desenvolvimento para treinamentos. Isso não implica que os parceiros devem ter níveis de conhecimento diferentes, mas eles podem ter níveis diferentes.

Quando os parceiros estão em níveis muito diferentes, aconselha-se que o "junior" fique como observador durante algum tempo. Quando ele passar a ter um nível de conhecimento maior e já começar a corrigir alguns erros do "senior", ele passa a pilotar.

Quando a diferença é grande, mas não tanto, aconselha-se que o menos experiente pilote sempre que possível.

Diminui a ocorrência de erros corriqueiros

Tendo duas pessoas observando o código produzido, duas vezes mais rápido erros de implementação simples são encontrados: variáveis instanciadas em locais errados, contadores iniciados com valores errados, etc. Assim, um problemas que poderia ser encontrado apenas durante os testes dos métodos é removido no momento da programação, já que enquanto uma pessoa produz, o outro verifica a consistência dos métodos e pensa a respeito da condução da programação de uma maneira mais geral.

Codigo Ganha maior autonomia: Coding Standards

Com o domínio público do software produzido, isto é, todos dentro da equipe de desenvolvimento podem, em algum momento se depararem com o código escrito de outra pessoa, é necessário que de alguma maneira, todos falem a mesma língua de programação. A técnica de Coding Standards é uma ótima opção para que, de uma maneira geral o código seja homogêneo, facilitando que qualquer um da equipe possa, num momento qualquer, corrigir erros e problemas encontrados durante a utilização do software. Assim, temos a remoção da individualidade no código produzido, o que permite a eliminação da relação do programador com o método programado.

Problemas complexos corrigidos com melhor arquitetura

Um problema mais complexo exige do programador um tempo para que a modelagem da solução seja criada, implementada e testada. Com pair programming, a modelagem pode ser discutida inicialmente, antes mesmo dela ir para a codificação, o que facilita o encontro de erros de modelagem. Assim, de uma maneira geral, a solução encontrada é mais robusta e mais elegante, já que duas pessoas pensaram a respeito dela, modelaram e a codificaram.

Redução do tempo despendido com treinamento do programador

Tanto o treinamento do novo programador na ferramenta que ele utilizará para desenvolver, sobre a arquitetura da aplicação que ele irá ajudar a desenvolver quanto sobre a tecnologia que ele utilizará para desenvolver podem acontecem no mesmo momento em que ele participa do processo de desenvolvimento juntamente com um programador mais experiente. Assim, mais rapidamente ele estará inserido no grupo de programadores, mais rapidamente terá aprendido a respeito da aplicação a ser desenvolvida. E tudo isso em tempo real de desenvolvimento, sem que ele tenha que parar seu processo de desenvolvimento para o treinamento.

Fortalece relacionamentos interpessoais na equipe

Uma equipe feliz produz melhor. Desta maneira, a programação em dupla propicia o melhor entrosamento entre os programadores, antes confinados em baias de desenvolvimentos, sem ter muito contato com os demais do grupo. Assim, o ambiente de desenvolvimento fica mais agradável e saudável, possibilitando um aumento considerável na produtividade.

Pontos contra Pair programming

Problemas culturais

Trabalhar paradigmas inerentes aos programadores é uma tarefa árdua. O processo deve ser lento e sem grandes traumas, sob o risco de perder muito em produtividade caso a mudança seja drástica demais. Pode ser desastroso ter a equipe de desenvolvimento revoltada por não ter tido os devidos esclarescimentos a respeito desta e de outras técnicas de Extreme Programming, fazendo com que a produtividade tenda a zero.

Programadores com níveis muito diferentes tendem a ter um período longo antes de um entrosamento perfeito

Com uma equipe menos homogênea de programadores (muitos "novatos" e poucas pessoas experiêntes na área) em que a diferença entre nível é gritante, o processo pode ser longo ou nem ao menos acontecer. É necessário ter muito cuidado para não estragar o desenvolvimento forçando duplas trabalharem juntas. Leva um tempo muito maior o nivelamento nessa situação, e dependendo das necessidades da equipe, deve-se buscar uma outra alternativa.

Medida de produtividade

Métricas de produtividade são bastante obscuras quando se trata de programação em dupla. Os critérios de avaliação podem ser muito subjetivos, indo desde a afinidade entre a dupla, até mesmo o processo de ensinar um método criado a outra pessoa. Mensurar o rendimento da equipe nessa situação é possível, mas na mesma linha é também trabalhoso.

Conseguir convencer gerentes de desenvolvimento e administradores sobre a técnica

É necessário catequizar gerentes de desenvolvimento e administradores de que esta técnica pode ser muito útil no desenvolvimento. A melhor opção para o problema é convencê-los a fazer um teste em pequenas partes de um projeto, ou ainda em um projeto menor, mais simples e com prazos mais maleáveis.

Assim pode-se ter a experiência necessária para verificar a eficiência da técnica aqui descrita.

Estudo de Caso: Binara Informática

Analizaremos o caso da empresa Binara Informática, sitiada em Florianópolis que está fazendo testes com a implantação de práticas de Extreme Programming, incluindo Pair Programming para o desenvolvimento de uma ferramenta de Análise BSC(Balance Scorecard) chamada BS3.

A empresa possui, para este desenvolvimento, quatro programadores de níveis diferentes de experiências, entretanto existe um bom entrosamento entre toda a equipe e o ambiente da empresa facilita a comunicação entre os desenvolvedores e o cliente.

Binara: Pair Programming Híbrido

Como o primeiro projeto utilizando-se de técnicas de XP, de maneira alguma conseguiu-se colocar as técnicas em seu mais puro estado por resistência dos gerentes da empresa. Desta maneira, uma saída simples encontrada foi incorporar as principais características para o desenvolvimento e adaptar técnicas para a realidade da empresa. Não foi diferente para a programação em dupla. Como os programadores não estão totalmente vinculados a um único projeto, não houve a possibilidade de se ter um desenvolvimento 100% XP e pair programming. O processo é descrito abaixo:

Definições de User Stories

Todas as definições das users stories são feitas em duplas reunidas com o cliente ou o gerente de projeto, que possui as informações de como está o andamento do desenvolvimento. Criados os testes de aceitação e definidas tarefas para a user story inicia-se a fase de modelagem-codificação.

Modelagem & Codificação

Ambos processos são feitos juntos. Ambos pela dupla, que discute as decisões com relação ao código a ser produzido. A codificação, por sua vez, é feita individualmente seguindo um padrão de desenvolvimento pré-definido e ensinado aos programadores. Todas as dúvidas são discutidas pela dupla, e a solução implementada e verificada da mesma forma pela dupla. Dificuldades encontradas pela dupal são discutidas diretamente com o cliente ou o gerente de desenvolvimento.

Conclusões

A implantação de técnicas de Extreme Programming acontece na empresa desde Junho de 2004, e já houve a verificação por parte da equipe administrativa, através de processos empíricos e da experiência em desenvolvimento, do real ganho de produtividade utilizando a técnica, sendo completamente aprovada e incentivada. Uma barreira forte encontrada foi a diferença de níveis entre os programadores. Especificamente entre duplas com níveis muito distintos de experiência com a tecnologia utilizada pela empresa, o processo de desenvolvimento tornou-se lento e de certa maneira desgastante para ambos os programadores. Entretanto acreditamos, na empresa, que essa situação logo será modificada devido à constante evolução dos programadores. Assim, podemos esperar o nivelamento dos programadores mais rapidamente que se fossem eles mantidos isolados no processo de desenvolvimento.