Arquivo da tag: extreme programming

Todo mundo odeia pair programming

Pair programming (ou programação pareada) é provavelmente a prática mais polêmica de extreme programming. É um dos poucos elementos de XP que tem seu valor questionado até por muitos desenvolvedores (além de gerentes e clientes). Provavelmente esta seja a razão para pair programming não ser tão praticada, ou utilizada apenas em doses homeopáticas (ainda mais considerando que pode ser utilizada mesmo sem XP ou algum método ágil). Porque existem pessoas em todos os papéis envolvidos no processo, que odeiam pair programming.

Quando um não quer, dois não fazem pair programming

Quando um não quer, dois não fazem pair programming

Muitas dessas pessoas conhecem as supostas vantagens de parear, mas torcem o nariz, mesmo que nunca tenha experimentado ou que tenham feito apenas uma tarde de experiência com o cara mais chato que conhecem no escritório. Mas na minha opinião, essa resistência não é criada por motivos muito nobres. Além do preconceito que já não é algo muito nobre, resolvi analisar algumas concepções erradas que as pessoas envolvidas tem sobre pair programming. Então venha comigo, de cabeça aberta.

Cliente

Se o cliente estiver contratando um serviço de desenvolvimento de sistemas, o problema provavelmente está no contrato. Muitos contratam esse tipo de serviço pagando pela hora dos desenvolvedores. Logo, quando ficam sabendo que em cada estação de trabalho vão trabalhar duas pessoas, já pensam que estão pagando o dobro do que deveriam pagar. Isso se resolve mudando o contrato para alguma outra forma que não envolva contagem de cabeças. Que aliás, sempre achei um jeito muito estranho de se vender este tipo de serviço, como se o número de pessoas (e não a qualidade) fosse determinante para o sucesso de um projeto. Vendendo a hora do desenvolvedor é como se você terceirizasse os riscos do seu RH e ainda lucrasse alguma coisa quando algum cara ruinzinho fosse contratado.

Se o que você está vendendo é justamente a consultoria para melhoria dos processos de desenvolvimento (o que provavelmente envolve pair programming), então você vai ter que vender todos os benefícios dessa prática. Para isto talvez o resto deste post ou outras referências te ajudem.

Gerente

Para o gerente, provavelmente a maior objeção é a questão da produtividade. Se formos cronometrar o tempo que uma dupla leva desde o começo até a entrega de uma tarefa, muito dificilmente os programadores pareados terão mais que o dobro da velocidade de dois programadores sozinhos. O problema de medir a produtividade desse jeito é que ela não leva em consideração a qualidade do que foi produzido e nem a transferência de informação e conhecimento que acontece durante pair programming. De qualquer jeito, medir produtividade desse jeito seria muito simplista. Em engenharia de software, uma gambiarra pode te fazer terminar muito rápido uma tarefa, mas mais para frente a equipe ter uma dor de cabeça de manutenção e gastar muitas horas resolvendo a gambiarra.

Falando em gambiarras, esta é uma das coisas que se pode evitar com pair programming. Com um co-piloto te vigiando, é muito menos provável que o desenvolvedor aposte numa solução rápida mas feia, porque afinal ninguém quer passar imagem de ser desleixado. Por outro lado, ter um co-piloto também evita que o seu super-mega-engenheiro que gosta de comer design patterns no café da manhã crie uma solução super complicada só porque é mais bonita, já que ninguém está olhando (e que depois ninguém vai entender ou vão gastar um tempão desfazendo). Tanto a gambiarra quanto o over-engineering podem custar muito em manutenção nas próximas iterações.

E por último, mas não menos importante, pair programming é a forma mais orgânica de disseminar informações sobre o projeto, compartilhar conhecimento e formar a cultura de um time. É como se você tivesse coaching, treinamento, revisão de código, brainstorm e mini-reuniões o tempo todo, sem precisar parar a codificação. Se você faz rodízio dos pares muito dificilmente precisará se preocupar se seu programador McGyver sumir, porque provavelmente mais de um programador conhece aquele código. Sem falar na disseminação de boas práticas, truques e macetes específicos a bibliotecas e frameworks que só poucos conhecem. Essa dinâmica de trabalho também permite criar um processo de admissão de novos desenvolvedores muito mais realista. Algumas empresas colocam os candidatos para parear com programadores da empresa para sentir se aquele candidato se encaixa na equipe (avaliando tanto o perfil técnico quanto a compatibilidade da personalidade da pessoa com a equipe já existente).

Existem muitos que se empolgam com extreme programming e correm para aplicar, e que na verdade gostam mesmo é da promessa de que não vão precisar produzir pilhas de documentação, passar meses tentando adivinhar como deveria ser o design do sistema. Mas muitos desses caras aplicam XP deixando de fora coisas como pair programming (para não desperdiçar contagem de cabeças). É aí que a qualidade começa a cair, porque as duas principais formas de comunicação na equipe (documentação e pais programming) foram abolidas. Sem comunicação em uma equipe, você sabe o que acontece.

Desenvolvedor

Aqui eu vou assumir que estamos falando de um desenvolvedor que seja honesto e esteja compromissado com a equipe e com a qualidade do projeto. Por isso nem vou falar do carinha que preferia trabalhar sozinho só para poder ter mais tempo ao MSN, Twitter e Orkut e nem do programador que não está nem aí para a qualidade do que produz e só está preocupado em receber o salário e bater ponto. Esses não tem muita razão para gostar de pair programming (talvez não tenham razão nem para estarem empregados).

Mesmo para as pessoas honestas e esforçadas algumas das razões para odiar pair programming não são ditas em voz alta. Uma delas está relacionada ao ego, esta parte tão sensível de tantos programadores. Nisso se encaixam os dois extremos, tanto o cara que não confia muito no próprio taco e fica se perguntando se deveria refatorar tudo o que faz, quanto o programador rock star que tem muita experiência e se imagina capaz de escrever um software que faça seu trabalho. O primeiro vai preferir trabalhar sozinho para não ficar exposto ao julgamento de outra pessoa e o segundo por sentir que não precisa de ajuda e na verdade seu par só vai retardá-lo. Ambos seguem um raciocínio que ignora o fato de que um dos objetivos de pair programming é equilibrar a troca de experiências e de informações. O inexperiente aprende algo e o super experiente ajuda o time a se tornar melhor. Pair programming é um exercício de humildade.

Não quero ninguém me desacelerando no meu trabalho diário de SER FODA!

Não quero ninguém atrapalhando meu trabalho diário de SER FODA!

Provavelmente o fato dos desenvolvedores estarem confortáveis com a forma de trabalho atual seja a maior barreira para adoção de pair programming. Claro, você poder ficar no seu canto e fazer as coisas do seu jeito, no seu tempo é muito agradável. Também acharia super agradável trabalhar na praia, sem computador nenhum e podendo dormir o quanto eu quisesse. A grande questão é o quanto a predominância desse trabalho individual ajuda o trabalho em equipe, principalmente quando falamos de comunicação. Claro que a adoção de trabalhos em pares não significa que as pessoas não possam ter seus momentos de trabalho solitário, que em alguns casos são necessários (coisas que necessitem de muita concentração, como uma leitura por exemplo).

Talvez como complemento você se interesse por ler o excelente post de Obie Fernandez sobre o assunto “10 reasons pair programming is not for the masses” (em inglês), que apesar do nome é uma defesa da prática. Esse post foi escrito logo após o New York Times publicar uma matéria sobre o tema: “For Writing Software, a Buddy System“.

Metodologias ágeis X Metodologias tradicionais

Existem infinitas formas de se contruir sistemas de software, e todo mundo que trabalha com isso procura pela galinha dos ovos de ouro, a metodologia perfeita para se construir software perfeito, no menor prazo possível, e que no final clientes e desenvolvedores são felizes para sempre.  É óbvio que isso só existe em contos de fadas. Mas nos corredores de empresas de software e em alguns botecos estranhos você deve ouvir calorosas discussões de defesa sobre a metodologia X ou o processo Y. E nos últimos anos (nos últimos 10 anos mais ou menos) a batalha da vez acontece entre as metodologias ágeis contra as metodologias iterativas mais tradicionais.

Usar cascata já era!

Usar cascata já era!

As metodologias iterativas mais utilizadas são o RUP e suas variantes (para criar uma variante, adicione o sufixo UP no final de uma palavra legal). Dão muita ênfase ao processo, ao controle do andamento do projeto através de delivarables (que normalmente são diagramas de diversos tipos, como diagramas de classes ou diagramas de interação). São muito utilizadas em fábricas de software, em projetos que envolvem muitos desenvolvedores, e não são sinônimos, mas estão sempre de mãos dadas com siglas como CMMi, e PMI. Se os gerentes da empresa gostam dessas duas siglas, tem pouco cabelo e estão na área há mais de 20 anos, é alta a probabilidade de que utilizem uma metodologia iterativa tradicional. Surgiram em resposta às metodologias em cascata, que já foram predominantes.

As metodologias ágeis são uma tentativa de refinar as metodologias iterativas, tirando o foco do processo em si e dando mais ênfase à contribuição das pessoas, dos integrantes do projeto. Trazem alguns conceitos que as diferenciam radicalmente das metodologias antecessoras, como deixar o cliente participar mais próximo ao processo, iterações extremamente curtas e grande ênfase em testes automatizados. Por outro lado, pesquisadores e mesmo defensores dessas práticas não recomendam times muito grandes para um projeto (e alguns propõem dividir o projeto em subprojetos e trabalhar com equipes menores). Os métodos mais conhecidos nesta categoria são Extreme Programming (mais carinhosamente conhecido como XP) e Scrum.

Mesmo tanto tempo depois da definição de métodos ágeis, da publicação do Manifesto Ágil, e de tanta gente pregando e achando que métodos ágeis são legais, porque é que isso não é ainda utilizado em larga escala? Entre alguns motivos estão:

  • Burocracia como requisito: existem clientes que pedem pela burocracia, pelo processo mais rígido. Só contratam empresas que tenham fábrica de software com CMMi nível 50, e fazem questão de saber que foram definidos 432 diagramas, mesmo que nunca vá parar para dar uma olhada para eles.
  • Maturidade: obviamente existe um número muito maior de projetos bem sucedidos utilizando metodologias que existem a mais tempo. Não precisa ser um gênio para perceber isso. Por isso, mais gente que conhece e tem experiência com esses processos. Processos mais novos são obviamente mais atrativos para algumas empresas picaretas oferecerem serviço de desenvolvimento de software.
  • Nível técnico da equipe: no caso de muitos gerentes, ao mesmo tempo que métodos ágeis são vistos como processos que exigem ninjas-Mcgyver-programadores, eles acham que suas equipes são formados por macacos bonobos. Ou para diminuir os custos, realmente tentam contratar macacos bonobos a preço de banana. Quando você acredita que tem uma equipe não muito capacitada, acaba querendo ter mais controle sobre o processo. Quanto menos a mão de obra precisar pensar, menor o seu risco, você só bota um monte de especificações para eles executarem e dá choquinho se eles fizerem errado (não me apedrejem, essa é a visão dos caras de gravata).
  • Medo: meio que resume os outros itens. Mas basicamente, as pessoas preferem não mexer em time que aparentemente está ganhando. Você sabe que a metodologia B.A.T.A.T.A. vai te entregar um sistema. Pode demorar, custar caro e ficar cheio de problemas, mas vai entregar um sistema. Preferem não arriscar.

Se nenhuma dessas razões acima perturba sua área de desenvolvimento, acho que posso assumir que a razão para que vocês não tenham considerado Agilizar seus processos é o simplesmente não conhecer muito bem o que são métodos ágeis. Vou tentar entregar o caminho das pedras abaixo.

Mitos e concepções erradas

A primeira coisa que muita gente pensa quando ouve falar de métodos ágeis é que não existe documentação para o software sendo desenvolvido, que o processo é um oba-oba em que vale tudo e as pessoas saem fazendo as coisas que querem, praticamente uma suruba no escuro.

É verdade que métodos ágeis na verdade não chegam a ser métodos e nem processos, mas sim conjuntos de diretrizes para se chegar a um bom resultado final, e por isso, não existe o passo 32 do processo que exige que você desenhe um diagrama UML usando 3 cores diferentes coloridos com crayon. Mas diagramas e documentação existem, mas são ditados pelo bom senso. Você gera um documento para comunicar algo para outros seres humanos, para deixar algo mais claro no design para outros seres humanos entenderem. Você não gera um diagrama que ninguém vai ler mas que você foi obrigado a gerar para não tomar choquinho do seu gerente de projeto. Mas o lado ruim disso é que bom senso é um conceito bem pouco formal. Ou seja, se seu time tiver um “bom senso” ruim (existe isso? ou seria mau senso?) você está lascado.

Por causa dessa percepção que as pessoas tem de que as coisas podem meio que ser feitas de qualquer jeito com métodos ágeis, existem muitos casos reportados de projetos fracassados utilizando essas metodologias, o que acabou espantando ainda mais as empresas grandes em relação a sua adoção. Mas também existem casos conhecidos de muito sucesso como a Primavera Systems e o Salesforce.com, que utilizavam anteriormente processos iterativos tradicionais.

Conheça as histórias de sucesso e de fracasso. Provavelmente se alguém olhar para a porcentagem de projetos tradicionais que fracassam e olhar para a mesma estatística no caso de metodologias ágeis, vai chegar a conclusão de que a competência do time é mais importante que o processo utilizado.

Maiores vantagens

  • Iterações curtas. Você entrega versões funcionais do sistema com mais frequência, em espaços mais curtos de tempo (que podem ser poucas semanas, ou um mês). Assim seu cliente corre menos risco, porque sabe sempre como está o andamento do projeto, e pode te dar muito mais feedback. Todo mundo fica feliz.
  • Diminuição dos custos de comunicação. É o tipo de custo que as pessoas dificilmente colocam no papel. Mas olhe para métodos mais dirigidos por especificações e diagramas. Todos esses artefatos são feitos com o objetivo de comunicar alguma coisa (pelo menos deveria ser esse o principal objetivo de um diagrama). O problema é que ao mesmo tempo, as pessoas utilizam exatamente os mesmos diagramas como documentação de longo prazo. O resultado disso é que durante o processo são gerados muitos documentos e diagramas que não são utilizados para comunicar nada, apenas para registrar como as coisas deveriam ser. E no final de tudo, tente descobrir se seu software realmente está seguindo toda aquela documentação gerada. É mais fácil construir outro sistema.
  • Levar em consideração que as coisas vão mudar ao longo do caminho. Enquanto você está especificando o sistema, as coisas estão mudando, e quem sabe aquilo que você bolou só vai servir para forrar galinheiro. Então você faz iterações curtas, para que essas mudanças tenham o mínimo de impacto no projeto. Você controi testes para garantir que mudanças futuras sejam mais seguras de fazer através de refatoração do código. E você tenta sempre resolver o problema que você tem na mão, não fica tentando criar a super solução genérica para casos que você nem sabe se vão aparecer. O último ponto é algo extremamente útil quando você tem na equipe pessoas que gostam muito de modelagem de arquitetura de sistemas, e que gostam de bolar coisas extremamente complicadas. O cliente não vai pagar mais pelo software que tiver a arquitetura mais bonita. Mas vai ficar mais feliz pelo software entregue mais cedo.

Algumas práticas são boas de qualquer jeito

Mesmo que você não vá adotar um processo ágil, existem práticas bem difundidas pela comunidade que DEVERIAM ser adotadas independente do processo utilizado. Repare que coloquei DEVERIAM em maiúsculas e negrito de propósito. Deveria ser lei, obrigação, sujeito a 30 açoitadas em praça pública para quem não seguisse essas práticas.

Testes automatizados. Automatize o máximo de testes que puder. Sim, vai dar mais trabalho. Não, não vai acabar com todos os bugs. Mas mais tarde, quando você precisar fazer uma refatoração mais radical, ou resolver algum bug ou alteração que surgiu, você não precisa mais ter medo e suar frio. Com um clique em um botão você sabe se quebrou alguma coisa (dependendo de quanto os seus testes são bons, claro). É infinitamente mais útil você ter um negócio que te dá essa informação sobre seu software do que pilhas e pilhas de qualquer tipo de documentação e especificação. Tente usar um UML para descobrir se você pode fazer uma alteração nas suas classes de objetos. Incontáveis vezes pude resolver problemas muito rapidamente simplesmente porque gastei algumas horas a mais escrevendo testes. Lembre-se, testes são como remédio ruim. Na hora que você está tomando vai reclamar, mas vai agradecer pelos benefícios no futuro.

Integração contínua. Pode ser visto como uma extensão dos testes automatizados. Automatize a integração e o build do seu software. Não deixe para descobrir no dia da entrega que o negócio não funciona (ou só funciona se o seu código e o do Juca estiverem separados).

Iterações curtas. Entregue versões do seus sistema com mais frequência e descubra mais cedo se você está indo na direção certa. É muito melhor quando isso acontece depois de duas semanas do que três meses depois. E se quer realmente saber se é possível cumprir seu prazo, você precisa deixar que os desenvolvedores, as pessoas que botam a mão na massa, estimem o tempo. Eles tem mais noção que você (que quer o prazo para ontem) e seu cliente (que quer o prazo para duas semanas atrás).

Gostei, como posso saber mais sobre isso?

Como literatura, acho que o melhor começo é o livro do Kent Beck, Extremme Programming Explained, um dos primeiros livros lançados sobre o assunto. Depois que você ler o livro do Beck, e quiser um livro mais prático, direto e DE GRAÇA, eu recomendo o Scrum and XP from the Trenches, do Henrik Kniberg.

Abaixo uma rápida e divertida introdução a Scrum:

Em breve vou fazer um post sobre ferramentas gratuitas para gerenciamento de projetos ágeis.

Me desculpem, mas só consigo links e vídeos bons em inglês. Se alguém tiver sugestões em português ou mesmo vídeos legendados, por favor me indiquem que eu coloco aqui.