O projeto está acabando mas vale lembrar de algumas experiências. Mesmo com XXX testes é normal que algum pequeno bug apareça, e antigamente quando isso acontecia era uma facada no orgulho: - “O que? Um bug!”. Claro, estávamos utilizando o melhor do TDD, escrevíamos os testes antes da implementação, criávamos testes de aceitação e etc. Resumindo, bugs acontecem. Então quando o cliente encontrava algum bug nossa sprint era interrompida no meio para que pudéssemos corrigir os problemas encontrados, isso era horrível por que tínhamos o código incompleto da sprint, tínhamos a pressão do cliente e o este ainda era pressionado para resolver aquilo em 2 minutos! o.O

Em uma determinada sprint, que eu não vou lembrar o número, nós tivemos a pior experiência com bugs, outras pessoas tinham acabado de se juntar a equipe, eles não tinham muita experiência, o que consumiu muito de nós pois tínhamos que explicar o funcionamento do TDD, que quando um teste quebrava o problema era da implementação do programa e NÃO do teste, e por ai vai. Tivemos o pior resultado de todos nessa sprint. Na retrospectiva levantamos esses problemas e “bolamos” uma solução que funciona com perfeição até hoje. Nós criamos a “quinta-feira da faxina”.
Hoje, quando o cliente encontra algum “bug”, se este não for muito, mas muito grave, ele escreve um post-it detalhando o problema e cola no espaço destinado a “faxina” sem ao menos interromper nosso trabalho para comunicar. Na quinta-feira nós damos uma pausa na sprint e pegamos todos os post-its relacionados a bug, melhoria, correção, além de rodar várias vezes os testes. É incrível como o volume de “bugs” encontrados diminuiu em 80% e nunca mais foi encontrado um “bug grave”, essa rotina funciona tão bem que nem é mais mencionada.

Por que escolhemos quinta-feira? Toda sexta-feira nós geramos uma tag e uma versão para o cliente, geralmente pela manhã, com isso ele pode realizar seus próprios testes, apresentar para seus superiores ou qualquer outra coisa que ele queira. Por isso ficou interessante corrigir os problemas antes de gerar a versão.

Nem sempre conseguimos corrigir todos os bugs na quinta-feira, então voltamos a trabalhar neles na próxima quinta e assim sucessivamente. Deixamos definida uma medida para o caso de ocorrer algum problema urgente, que seria:  parar a sprint, planejar a correção e replanejar a sprint.

Essa não é a solução ideal para todos os casos, mas é incrível como funciona bem nesse projeto, o cliente até começou a fazer isso com outros processos internos.

Olá pessoal,

Vou aproveitar a entresafra bloguística do pessoal pra deixar uma notinha.

No começo de outubro, publiquei no Blog da Visão Ágil um artigo sobre uma consultoria de Agile que demos no INEP para desenvolvimento do Encceja.

Foi uma experiência muito interessante pra gente, além de considerar um marco muito importante para as metodologias ágeis no Brasil, pois se trata de um projeto de nível nacional e no governo! (Além de outras coisas, como ter utilizado um servidor de aplicação feito em Software Livre).

Espanta um monte de crenças e preconceitos a respeito de Agile.

Leia o artigo na íntegra aqui.

Ah, e pra quem ainda não leu sobre nossa Saga na Aeronáutica,apresentada no Falando em Agile, o Case Sigadaer descrito em maiores detalhes aqui.

Grande abraço, [                  ]

Willi

Essa discussão é antiga. No dojo-sea nós sempre a temos e ninguém sabe ao certo quando isso deve ocorrer, no dojo-brasilia também tivemos uma discussão mas ninguém quis apontar uma solução ou fixar uma opinião. Então farei isso.

Primeiro vamos entender de fato o que significa refatorar, a Wikipédia diz: “é o processo de modificar um sistema de software para melhorar a estrutura interna do código sem alterar seu comportamento externo.”
De posse desse conceito eu digo que um código “só” deve ser refatorado quando está em seu estado final. Considerando que um código em “estado final” possui vários testes unitários, nós podemos verificar o impacto da mudança facilmente, pois pequenos erros podem ser inseridos durante a refatoração. Denomino esse caso de “polimento de código”.

Agora vamos desconstruir o raciocínio. Suponha que uma classe X está em desenvolvimento, você está escrevendo os testes antes da implementação, quando eles quebram você implementa e roda de novo, e por ai vai… Porém a cada dois minutos você tem que escrever vários comentários sobre o que aquele trecho de código esta fazendo, percebeu? O.o? O funcionamento do código não está claro o suficiente, devemos refatorá-lo! Ou quando estamos escrevendo uma classe Y que tem trechos idênticos as classes X e Z, ora por que não separamos esses trechos? Costumo chamar esses casos de “necessidade de refactoring”.

Seguindo o raciocínio proposto chegamos a dois conceitos criados por mim, não riam, que são refatorações para polimento e refatorações por necessidade. Nós ainda temos refatorações que visam desempenho, testabilidade, etc. Essas ficam para uma próxima oportunidade.

Este post está longe de definir todos os casos em que uma refatoração é necessária, mas abre a discussão, e você o que acha sobre o assunto?

Me lembrei da história de um cara que visitou uma enorme construção e perguntou a um operário o que ele estava fazendo. Ele respondeu que estava assentando tijolos. Perguntou pra outro e esse respondeu que estava levantando uma parede. Perguntou a mesma coisa a um terceiro, que estava fazendo a mesma coisa que os outros dois, e ele disse que estava construindo uma catedral.

É nesse sentido que coloquei no título o “Construindo um Brasil Melhor”.
Muita gente pode achar que o que fizemos foi só uma tradução de um livro, mas acredito que estamos fazendo mais que isso.
Estamos favorecendo a popularização das metodologias ágeis. Com isso, favorecemos a produção de mais software de qualidade, a compreensão dos prejuízos causados por contratos de escopo fechado, deixando melhores legados para nossos colegas, diminuindo os tantos sistemas inteiros que são jogados no lixo todo ano para serem refeitos por fortunas cada vez maiores, fazendo com que os recursos sejam melhor utilizados, ajudando o país a enriquecer de uma forma sustentável, para gerar mais impostos, para sobrar mais dinheiro pra educação, pro povo aprender a ter senso crítico, pra votar melhor, pra daqui a um bom tempo ocorrer uma limpeza real no nosso sistema e o Brasil ser um país melhor pra todos nossos tataranetos.

Viajei? Se deixar chego até a contribuição para a diminuição do aquecimento global! :)

Mas toda essa jornada começa com um simples passo, e esse passo foi dado por 30 pessoas que ao melhor estilo bazar construíram a catedral.

Não me lembro quando a idéia apareceu, mas apareceu depois de terminarmos de traduzir as tirinhas do Why’s Poignant Guide to Ruby. Mandei um e-mail pro Henrik Kniberg com a idéia de traduzir o livro pra português, depois de um tempo ele me respondeu topando, e em seguida mandou o livro em formato editável. Dividi o livro em 114 pequenos pedaços, e dia 16/07/08 lançamos um post  convocando nossos leitores e a galera da comunidade no Brasil, e explicando o procedimento. No mesmo dia, três pessoas já apareceram. Pra gente já foi uma vitória. Quem poderia imaginar que ao total iriam aparecer 30? São eles:
 

• Acyr José Tedeschi
• Adam Victor Brandizzi
• Alexandre Gomes
• Álvaro Maia
• Bruno Pedroso
• Cássio Marques
• Daniel Wildt
• Eduardo Bobsin Machado, que traduziu todas as imagens
• Emanoel Tadeu da Silva Freitas
• Fernanda Stringassi de Oliveira
• Francisco M. Soares Nt.
• Gustavo Grillo
• Ian Gallina, cuja mãe ajudou na revisão do português
• Israel Rodrigo Faria
• José Inácio Serafini
• Juliana Berossa Steffen
• Marcos Machado
• Marcos Vinícius Guimarães
• Mauricio Vieira
• Pablo Nunes Alves
• Rafael Benevides
• Rafael Recalde Caceres
• Renato Willi
• Rodrigo Palhano
• Rodrigo Russo
• Taiza Sousa
• Victor Hugo Germano
• Vinícius Assef

Em 21 dias, mais de 150 e-mails depois, a idéia virou realidade. Todo o livro já estava traduzido, dia 07/08. Cada pedaço levou em média 2,22 dias pra ser traduzido. No total, entre tradução e revisão, levamos apenas 1 mês e 1 semana. O Cássio Marques e Vinícius Assef juntos traduziram quase 50% dos pedaços.
Parabéns novamente a todos. Foi um trabalho excepcional. Comemorem!!!

Convencer, ensinar, vender… são todos processos internos (acontecem no espaço entre 2 orelhas). Teremos muito mais sucesso se agirmos no sentido de motivar as pessoas para que se convençam, motivar pra que aprendam ou para que comprem alguma coisa. Parece apenas um jogo de palavras, mas a idéia por trás é bastante forte! Apenas 2,5% da população é de pessoas inovadoras, que são naturalmente ávidos por mudança e não têm aversão ao risco. Quer dizer que de cada 100 chefes que você tentar convencer, só 2 irão te dar ouvidos.

Os demais irão agir provavelmente assim:

Se você riu é porque já passou por isso. Eu tive uma crise de riso! :)

Vejam que um dos padrões para introduzir novas idéias é plantar sementes.

Eis a semente!

[                       ]
Willi

De Votuporanga, zarpamos para São Paulo (com breve escala em São José do Rio Preto), onde participaríamos, em 01/11/2008, do InfoQ Launch Meeting, apresentando as tendências de conteúdo para a queue de SOA do portal.

De quebra, até participei de um painel de discussão sobre plataformas distribuídas, no qual não defendi nem o Java, nem o .NET e nem o Rails. Muito pelo contrário!

Alguns amigos já andaram falando por aí sobre o evento. Confiram nos blogs de Edgar Silva e do Victor Hugo (quem mais?), no Twitter e na mensagem do Manoel Pimentel.

E fique ligado no infoq.com/br que em breve os vídeos das palestras começarão a ser disponibilizados.

[]s

Idéia: “sinônimo de conceito ou, num sentido mais lato, como expressão que traz implícita uma presença de intencionalidade.” Tudo isso aconteceu quando participei pela primeira vez do dojo-sea. Era incrível como um ambiente descontraído conseguia gerar tantas discussões e conhecimento. Eu tinha que tentar essa idéia, afinal outras pessoas também mereciam aquela oportunidade.

Em uma conversa com o Willi discutimos sobre dojo, sea, eu, ele, a sala… E ele disse que seria muito interessante a criação de outro dojo, replicar o que é bom é bom…

Fiquei muito empolgado com a idéia, porém seguir pelo caminho do “novo” é difícil, sala vazia pra mim. =[

Mas desanimar pra que? Não tava perdendo nada, continuei com o projeto e com orgulho apresento para vocês o dojo-brasilia, que pode ser acessado aqui com código aqui.

Estamos com pouca infra-estrutura, mas isso está mudando. O post do Bruno sobre dojo já diz tudo sobre a motivação e a metodologia. Adaptamos algumas coisas para testar mas no geral seguimos o mesmo padrão.

Ainda não temos projetor, como na SEA, mas serve o quadro? O pessoal já aprovou a idéia e ganhamos reforços a cada dia. Começamos a utilizar o infinitest para que os testes rodem automaticamente quando um código for salvo, isso da mais dinamicidade ao desenvolvimento.

Mudamos um pouco a forma de discutir no final do dojo…

Mas o resultado foi bem interessante…

Acredito que o dojo seja uma forma muito interessante e inovadora de praticar e estudar. Que venham os dojos!

O que estamos fazendo? Entre no grupo e confira!

Conforme anunciado no post Gestão heurística, ágil e premiada, seguem slides da apresentação que fizemos em 31/10/2008 no Encontro Regional de Empreendedorismo em Votuporanga/SP.

[]s