AgileAndArt

The Art Improving Agile Software Development

Browsing Posts tagged xp

1 – Quando e como surgiu a idéia de implantar a XP como método de desenvolvimento?

Começamos a fazer XP em 2006, no time que desenvolvia o PABX Virtual (antiga Locaweb Telecom). Quem trouxe a ideia de XP foi Daniel Cukier, um dos desenvolvedores do time na época. Ele tinha cursado em seu mestrado (IME-USP) duas disciplinas sobre Métodos Ágeis e já era membro da Agilcoop. Ja tinha adquirido certa experiência para tentar aplicar o aprendizado num projeto de verdade. O time era pequeno na época (4 desenvolvedores) e o gerente gostou bastante das ideias propostas no XP que lhes foram apresentadas. O time de Telecom era relativamente isolado dos outros times de desenvolvimento e isso facilitou as coisas. Era possível adotar a metodologia como um projeto piloto, sem afetar outras áreas ou produtos. Durante 8 meses, de outubro de 2006 até junho de 2007 o time se estabeleceu na metodologia. O produto PABX Virtual foi lançado e sua evolução em termos de funcionalidades era rápida e eficiente, com poucos bugs. A cada duas semanas, o time de Telecom lançava novidades no produto.Em paralelo a isso, Daniel Cukier e Maurício De Diana criaram um grupo de estudos de tecnologia, onde um dos assuntos estudados foi Métodos Ágeis. O grupo de estudos serviu para que as pessoas pudessem conhecer mais os detalhes não só de XP, mas também de outras metodologias como Scrum e Lean. As reuniões do grupo tinham entre 10 e 20 pessoas. Esse grupo de estudos tentou iniciar um projeto multi-equipes usando XP, mas devido às várias atribulações do dia-a-dia dos membros do grupo, o projeto não deu certo.Em meados de junho/julho de 2007 foram feitas algumas apresentações para a diretoria da empresa, com o objetivo de estimular a adoção de Métodos Ágeis em todos os times de desenvolvimento da empresa. Para convencer os diretores, foram mostrados números que demonstravam a qualidade do produto PABX, tanto em relação ao código quanto à velocidade de criação de novas funcionalidades. Na mesma época, um consultor internacional veio à empresa dar um curso para o time de produtos. Esse consultor comentou que gostava de Métodos Ágeis para desenvolver software. Isso foi a gota d’água que faltava.

No mês de agosto, a diretoria patrocinou um treinamento em Métodos Ágeis para desenvolvedores, gerentes e clientes internos de diversas áreas da empresa (até o presidente participou. A partir daí iniciou-se um processo longo e trabalhoso de adoção das práticas Ágeis dentro da empresa.

2 – Após o planejamento, quanto tempo se gastou para o método ser implantado? Seria possível nos informar o custo médio que a implantação desse método teve? Todos os objetivos da Locaweb foram alcançados?

Foram quase 2 anos de evolução das práticas ágeis dentro da empresa, até o ponto em que podemos afirmar que a Locaweb se tornou de fato uma empresa de Desenvolvimento Ágil. Durante esses anos, muitas coisas mudaram. Várias pessoas saíram da empresa e muitas outras foram contratadas. O perfil dos profissionais mudou drasticamente. No primeiro ano, as práticas de Scrum foram as mais facilmente adotadas (práticas como planejamento, estimativas, ciclos de desenvolvimento, etc.) – as práticas de engenharia e design, como testes, refatoração, integração contínua, só começaram a se estabelecer a partir do 2o. ano. A programação em pares foi uma prática que teve adoção em quase todos os times, mas também demorou 2 anos até que fosse algo arraigado na cultura da empresa. Uma vez que a Locaweb se tornou Ágil nos times de programação, essa mudança começou a impactar outras áreas da empresa: áreas como infra-estrutura, times de sysadmins, e até marketing, vendas e recursos humanos. O objetivo de estruturar a área de desenvolvimento, de forma que a empresa como um todo (diretoria, cobrança, marketing, financeiro) pudesse ter visibilidade sobre os projetos em andamento, foi atingido. Porém, a empresa continua mudando sempre, visando a melhoria contínua dos seus produtos e processos internos. A excelência em Métodos Ágeis na área de tecnologia não significou que todos os problemas fossem resolvidos, pois a empresa é grande e complexa. Mas foi um primeiro passo foi dado e novos aprendizados e ações surgiram desse passo. Então, podemos dizer que a Locaweb é uma empresa muito melhor do que era antes dos Métodos Ágeis.

3 – Houve um aumento de produtividade após a implantação de XP? Ouve uma redução do custo de produção?

continue reading…

A Mariana Vivian Bravo da Agilcoop criou uma linda imagem, relacionando os valores, os princípios e as práticas de XP. Parabéns, Mari, pelo trabalho

Semana passada ministrei um curso prático de XP pela AgilCoop. O formato do curso é bem interessante e ideal para pessoas nunca tiveram contato com a metodologia OU conhecem a teoria mas nunca usaram as práticas.

O curso tem 20 horas de duração. O objetivo é usar a metodologia para desenvolver em 4 ciclos de 4 horas uma Pizzaria Online – a AgilPizza. As outras 4 horas são destinadas a explicações básicas e encerramento do curso.

Cada ciclo de 4 horas está dividido em 30min de planejamento, 3.5h de desenvolvimento e 15 minutos de retrospectivas.

O curso é uma versão no meio do caminho entre o Jogo de XP (onde cada iteração dura 1 minuto) e o ambiente de desenvolvimento real (onde cada iteração tem em média de 5 a 20 dias de duração).

A atmosfera de brincadeira e diversão criada em torno desse projeto de pizzaria é um dos atributos chave para o aprendizado da metodologia. Esse ambiente descontraído deveria ser levado mais a sério nas áreas de desenvolvimento das empresas. Se nós conseguimos criar um software de qualidade, com funcionalidades úteis para o cliente numa brincadeira, por que não podemos fazer essa brincadeira todos os dias em nossos escritórios?

Uma pessoa mais desavisada que assiste ao vídeo do jogo do planejamento (nesse curso usamos Planning Poker) não consegue saber se as pessoas estão jogando ou trabalhando.

John Maddog lembrou isso em sua palestra no FISL 9.0. O título da palestra era “Fun and Software Livre! Return of the Jedi!”. Ele contou a história dos grandes projetos de Softwares Livre. A maioria deles surgiu como uma brincadeira, feitos por divertimento pelos criadores (Linus Torvalds no caso do Linux, Mark Spencer no caso do Asterisk).

No modelo do ócio criativo de Domenico Di Masi vemos uma perfeita sincronia entre trabalhar, estudar e o brincar. Os métodos ágeis tem tudo a ver com esse modelo. Quem é ágil brinca, estuda e trabalha! Tudo Junto!

A arte inspira o que é fora da regra, o que é humano, o que é criação. A arte pode ajudar a trazer ludicismo para o trabalho. O estudo ajuda a aperfeiçoar as técnicas de arte e as práticas no ambiente de trabalho. Como vemos, todas essas coisas, trabalho, jogos, estudos e arte estão integradas, interligadas.

Joca Torres defendeu nesse post algumas vantagens de usar métodos ágeis, do ponto de vista do gerente de produtos. O design incremental e o uso de iterações permite que o cliente veja mais rapidamente aquilo que já está pronto. A partir do momento que o cliente está usando nosso software, ele começa a PAGAR e a ter benefícios (e nós também!).

Porém, do ponto de vista do time de desenvolvimento, existem alguns cuidados que precisam ser tomados para que o software se torne “modificável” para atender as necessidades do cliente. Para entregar funcionalidade de forma incremental, você precisa ter um ambiente de desenvolvimento e uma base de código que facilite e permita essas entregas iterativas.

As práticas de XP são um guia para isso. O gerente de produtos tem muito contato com as práticas de planejamento (histórias, iterações, velocidade etc) mas em software não basta planejar. O código tem que ter alta qualidade e testes (de preferência automatizados). Para se testar, é necessário programar orientado a testes, ou seja, se você começou a fazer um software numa linguagem ou num ambiente que não facilite a criação e manutenção de testes, você está indo no caminho contrário da qualidade e da agilidade. Se você quer acompanhar as mudanças da tecnologia, da vontade do seu cliente e do dia-a-dia dos membros de sua equipe, tenha uma boa base de testes para seu software.

Para escrever bons testes, você precisa ter um design bom e simples. Para transformar seu código legado, obsoleto, em algo testável, você precisa ter bons conhecimentos em Programação Orientada a Objetos e Refatorações.

Quando o time de desenvolvimento é maior do que um time de uma única pessoa, o código será compartilhado. Para diminuir a entropia da comunicação entre pessoas que modificam o mesmo código, você utiliza programação pareada, padronização de código e integração contínua. Além disso, times ágeis não podem ter muito mais do que oito ou dez pessoas.

Resumindo, plano de iterações é parte essencial da agilidade, mas ela só é possível com práticas sustentáveis como testes automatizados, refatorações, integração contínua, propriedade coletiva de código, programação pareada etc.

O tracker é conhecido como a consciência do time. É ele quem mostra números, gráficos, tabelas. Os dados que o tracker coleta podem ser objetivos (ex: número total de testes, total de horas estimadas por release, estimativas versus realizações) ou subjetivos (ex: nível de satisfação da equipe, qualidade do código. Coloco aqui algumas fotos de tracking subjetivo, tiradas de cartazes feitos durante o segundo semestre de 2007 no Projeto Borboleta

A primeira delas (clique na imagem para vê-la em tamanho grande) é do “humorômetro” da equipe. Durante o semestre, em todos os dias de trabalho, cada membro da equipe era responsável por desenhar a sua “carinha”, representando seu estado de espírito: triste, feliz, irritado, etc. Ao longo das primeiras semanas a equipe exagerou no humor. O excesso de humor prejudicou o caráter informativo que o cartaz deveria ter. No cartaz à direita da foto, a equipe tentou melhorar o nível de informação, criando um código de cores para cada estado de humor. As faltas eram marcadas com fantasmas (no cartaz da esquerda) ou hachuras (à direita).
A segunda foto possui um gráfico que mostra a análise da equipe em relação a qualidade do código. No eixo X está o andamento de cada release. No eixo Y uma nota de 0%(ruim) a 100% (ótimo) do que a equipe acredita ser o quesito qualidade. Cada ponto no gráfico corresponde a um dia em que a equipe trabalhou e “votou” na qualidade do código. Observe no release 1.2 a colata de dados começou quando a release já estava 80% completa. Já na release 1.3 houve uma displicência por parte do tracker em coletar os dados. Foram plotados somente os pontos no começo e no fim da iteração, gerando uma linha reta no gráfico, que o coach (eu no caso :-) comentou como “lamentável”Coletar dados subjetivos sobre a equipe é tão (ou até mais) importante quanto analisar dados objetivos sobre o código. Toda equipe de desenvolvimento de software é composta de seres humanos. Seres humanos são imprevisíveis. Grande parte das informações que se pode obter sobre essa equipe é analógica, subjetiva. Observar com atenção essas informações e torná-las visíveis para a equipe certamente tornará o ambiente agradável, divertido e produtivo.

Durante 9 meses de trabalho no projeto do Pabx Virtual da LocaWeb, coletamos informações estatísticas do código do projeto. Baseado nessas informações tirei algumas conclusões.
No gráfico à direita vemos
claramente que o projeto tinha inicialmente muito código duplicado. Depois de várias Refatorações, foram removidas duplicações e o código ficou muito mais limpo e fácil de alterar.

No gráfico seguinte vemos que, enquanto o número de linhas de código diminuiu
drasticamente, o número de linhas de c
ódigo de
teste aumentou, o que significa que além de desenvolver novas funcionalidades, melhorar a qualidade do código do produto, ainda criamos uma série de testes automatizados que ajudam a garantir a qualidade do sistemas nas próximas versões.

No próximo gráfico vemos que o número de classes do sistema aumentou bastante, indicando que houve um aumento na modularização e reutilização do código. Mais classes com menos código significa maior especialização das classes, métodos menores e também maior testabilidade.

Todos estes números nos ajudam a ver que a metodologia adotada foi eficaz para melhorar e manter o projeto. Algumas práticas de XP adotadas pela equipe foram: programação pareada, releases curtos, jogo do planejamento, refatoração, design simples, cliente sempre presente, padronização de código.

Neste último semestre, participei como coach do Projeto Borboleta, no laboratório de Programação eXtrema do IME-USP. A equipe tinha dez programadores, todos alunos de graduação do curso de Ciência da Computação.

O Borboleta é um projeto que começou a ser desenvolvido em 2004, como trabalho de formatura de alguns alunos do IME. O projeto consiste em uma desenvolver uma aplicação para dispositivos móveis (Palmtops, celulares) que auxilie agentes de saúde no atendimento do programa APD (Apoio a Populações Desfavorecidas). Com o uso desse sistema, os agentes poderão preencher prontuários médicos eletrônicos, consultar estoques de remédios, consultar o histórico médico dos pacientes, tudo isso de forma prática e rápida. Além disso, os dados coletados no atendimento podem ser integrados a um banco de dados que fornecerá estatísticas importantes aos órgãos do sistema de saúde.

Em 2006, também no laboratório de Programação eXtrema do IME, o sistema foi melhorado por uma equipe de seis programadores (eu era um deles). Nesse momento ele estava praticamente pronto para começar a ser usado pelo Centro de Saúde, mas ficamos a um passo de colocá-lo em produção.

Agora, em junho de 2007, acabamos de dar esse passo que faltava. Os dez membros da equipe trabalharam quatro meses, criaram novas funcionalidades para o sistema, corrigiram bugs. Dentro da metodologia XP, a equipe:

  • Aumentou a quantidade de testes automatizados do sistema
  • Refatorou código antigo
  • Criou um ambiente descontraído e comunicativo
  • Fez três iterações, planejando e priorizando conforme as necessidades do cliente

Levando em consideração que a equipe se reunia apenas 5 horas por semana, acredito que avançamos bastante. Porém, não acredito que podemos continuar neste ritmo. O mundo da tecnologia avança numa velocidade muito grande e, comparado com esse avanço, o projeto está lento demais. As nossas maiores dificuldades enfrentadas foram:

  • Problemas constantes com a infra-estrutura do laboratório (rede fora do ar, máquinas sem funcionamento, espaço apertado)
  • O repositório de dados da incubadora fapesp estava constantemente fora do ar, o que impedia a equipe de integrar o código.
  • Muitas faltas (15%). Talvez por não ser um ambiente profissional, talvez pelo fato de a equipe ser muito grande.
  • Entender o código legado, muito confuso e mal documentado (acredito que essa dificuldade permanecerá para a próxima equipe)
  • Aprender a usar a tecnologia em si (J2ME, Java, swing, XML): a maior parte dos alunos nunca tenha tido contato com essas tecnologias e tiveram que usar um bom tempo para aprender a usá-las.


Para que a “Borboleta” voasse de verdade (e ela pode voar), seria necessário que tivéssemos uma equipe com dedicação muito maior. O ideal seria termos pelo menos quatro pessoas com uma dedicação mínima de 20 ou 30 horas por semana. O maior problema de hoje é a descontinuidade do projeto. Durante quatro meses uma equipe trabalha. Depois de algum tempo, outra equipe melhora um pouco o sistema, durante somente mais quatro meses. Só o tempo para que os programadores se familiarizem com o código é de quase dois meses (com a dedicação de 5 horas semanais). Isso sem contar que todos os desenvolvedores são ainda alunos de graduação.

Uma das possíveis soluções para que o projeto Borboleta andasse numa velocidade aceitável seria possuir uma equipe híbrida dedicada, com alguns bons alunos e mais alguns profissionais experientes. Isso seria viável de tivéssemos o apoio de alguma empresa privada.

Tive muitos aprendizados como coach deste projeto. O maior dele foi na difícil tarefa de tentar manter a equipe motivada e produtiva. Existe uma forma intuitiva de saber melhor:

  • Como chamar a atenção sem ofender
  • Como estabelecer prazos e limites sem estressar
  • Como resolver dúvidas técnicas de todos os pares, sem um envolvimento grande com o código
  • Como manter o ambiente agradável, bem humorado e ao mesmo tempo focado no trabalho

Acredito que grande parte desta “forma intuitiva” venha do conhecimento humano que cada um possui. No meu caso, atribuo o aprendizado do lado humano a duas coisas: às minhas vivências com a arte, principalmente no teatro e na música; e à meditação, temas que abordarei em posts futuros.

Switch to our mobile site