GIT

Pra quem ainda não sabe, GIT é o sistema de controle de versão que tem se popularizado muito rapidamente (especialmente entre a comunidade Rails) depois que o Linus Torvalds fez essa apresentação no Google:




O video é bem engraçado, vale a pena assistir. O Linus é mesmo um gênio no que diz respeito a sua capacidade de agregar, criar entropia, motivar... Ou no mínimo atiçar a curiosidade :-)

Desde que participei da definição do processo de desenvolvimento da Mirante, tenho me envolvido e me interessado por sistemas de controle de versão e por gerência de configuração em geral. De lá pra cá, passei por SourceSafe, CVS e Subversion.

Sinceramente, depois do SoftwareConfigurationPatterns e no VersionControlWithSubversion - li ambos quase que de cabo a rabo - e de ter usado e ensinado um monte de gente a usar branches, achei que entendia de SCM.

A algumas semanas, desde que comecei a ter contato com o GIT, tenho percebido que a disciplina ainda pode ser bem mais interessante. Não apenas sob o aspecto técnico da coisa, mas também - e principalmente - sob o da colaboratividade e do modelo bazar. (Vide GitHub !!!)

Confesso que, quando comecei a usar o GIT pra ajudar com a tradução do WhysPoignantGuideToRuby fiquei um pouco atrapalhado. A estrura do sistema é um bocado diferente do SVN, então não entendi tudo de primeira.

Lendo o tutorial do Akita, já conseui ter uma idéia melhor e começar a trabalhar. Precisei de mais umas ajudinhas do CarlosBrando e acabei conseguindo me virar.

Agora, vou te contar... Depois de assistir à palestra que o ScottChacon apresentou na última RailsConf, aí sim as coisas ficaram claras!

Além do ótimo conteúdo, o formato da apresentação é uma verdadeira aula de como se utilizar transparências para apresentar um conteúdo técnico. Não foi a toa que, no meio da apresentação, ao concluir a explicação de um único tópico, algumas pessoas da platéia o aplaudiram como se fosse o fim da apresentação (de "brincadeira", claro!), tamanha foi a clareza e capacidade de comunicação dos slides.

Vejam aqui a versão "screencast" que ele fez. (A versão gravada no auditório tem uns cortes brochantes!) Dá pra assistir online, mas vale mais a pena baixar a versão em alta qualidade e assistir com calma. A apresentação toda dura quase uma hora!



Bom proveito!

Falando em Agilidade: o discurso certo para o público certo.

Já tem algum tempo que me interesso muito por XP. Minha primeira tentativa de usar a metodologia em um projeto real foi em 2004. De lá pra cá, tentei muitas vezes falar sobre XP nos locais onde trabalhei, tentando influenciar de alguma forma o modo como desenvolvíamos software.

No entanto, foi só a partir do ano passado que essas iniciativas começaram a surtir efeito. Hoje já estamos usando grande parte das práticas de XP em 4 projetos na SEA, e considero que pelo menos outros 2 foram muito bem sucedidos especialmente por conta delas.

Apesar dos casos de sucesso que tivemos, ainda acho bem difícil convencer alguns grupos a darem mais atenção a essa inevitável mudança de paradigma por que nossa indústria vem passando.

Recentemente, tive a oportunidade de apresentar algumas palestras sobre XP e Scrum em algumas empresas de Brasília e na UnB. Semana passada, foi a primeira vez que apresentei uma palestra sobre RubyOnRails, dessa vez para estudantes de graduação da Unip, aqui em Brasília.

Dessas experiências, tirei uma conclusão que a partir de agora passará a fazer parte da minha caixa de ferramentas sempre que for chamado para outras apresentações sobre Agilidade: Se for apresentar para gerentes e executivos, fale de Scrum; se for falar para programadores e/ou estudantes, fale de Rails.


Algumas das apresentações mencionadas foram decisivas pra essa conclusão. uma delas foi a palestra que fiz sobre metodologias ágeis na semana de extensão da UnB. Para essa palestra, escrevi um resumo super cuidadoso, relacionando a agilidade com o tema maior do evento - sustentabilidade. Resultado: não apareceu ninguém. Estudantes de graduação simplesmente não têm o menor interesse em assuntos como metodologias de desenvolvimento. Talvez porque ainda não compreendam a importância do assunto.

Outra experiência importante foi a apresentação de Rails na Unip. Como preparei tudo com bastante pressa, acabei pecando no ponto mais básico de todos: o público alvo. Preparei uma apresentação cheia de exemplos de código e explicações técnicas; comparações com Java, etc. Ao começar a apresentação, percebi que estava em uma enrascada. Aproximadamente 90% do público nunca havia programado profissionalmente ainda!

Fui em frente, fiz minha apresentação, e no final, quando havia planejado uma demonstração, acabei preferindo terminar sem fazer a demonstração. Afinal, já havia mostrado tanto código que achei que a demonstração fosse ficar mais chata ainda.

A grande surpresa é que a reação da platéia foi exatamente a contrária. Todos adoraram a idéia da demonstração e ninguém se levantou, como eu havia imaginado. Achei ótimo! O Paulão colocou uma musiquinha ambiente, sentei na mesa com o microfone e programei uns 2 casos de usos simples narrando passo a passo cada linha de código programada. Foi super legal!

Em contrapartida, ao falar para gerentes e executivos, o que sempre percebi foi uma resistência terrível às práticas de XP, especialmente as mais relacionadas com atividades de engenharia: programação em par, testes automáticos, design evolutivo. São práticas que simplesmente não entram na cabeça dessas pessoas.

Mas, ao falar de Scrum ao invés de XP, tudo muda! As práticas de engenharia (mais controversas) não estão na pauta, temos gráficos bonitos e bem apresentados, argumentos pomposos, certificações e tudo mais que essa turma adora!

Portanto, se vc tem uma apresentação de XP a fazer, considere bem seu público. Estudantes e programadores jovens não se interessam por metodologias, mas ficam fascinados ao ver uma demonstração de RoR. Enquanto isso, bombardeie valores e princípios ágeis. Gerentes em geral são tão preconceituosos com XP, que antes mesmo de começar a apresentação, já terá várias críticas para responder. Apresente-lhes Scrum, com seus gráficos bonitos e certificações, que as portas se abrirão como mágica.

Simples e bem feito

Acho que é um pouco disso que o DHH está falando nessa apresentação. Simplicidade, qualidade. As grandes idéias de hoje são assim.

Reserve 30 minutos do seu dia para assistir a essa apresentação, em que o pai do RubyOnRails explica - com muita simplicidade - onde está o pulo do gato de idéias como Basecamp e Campfire.

Junte com um pouco mais de tempero, e deixe fervilhar na mente por alguns minutos.




A propósito, que belo formato de unir video + transparências para publicar uma apresentação, hein...

Sucata pros senadores

Estou aderindo a esse protesto:



Tem um monte de porqueira aqui em casa e já está indo pra caixa!

Achei o post pelo blog do Akita, com quem normalmente concordo em gênero e grau.

Aqui tem mais algumas opniões interessantes.

Brincadeira esse nosso legislativo... Dá um pouco (muito) de tristeza viu... :-(

Produtividade ou liderança

Nós agilistas costumamos dizer que as questões técnicas não são o ponto crucial na maioria dos projetos de software. Lidar com todas as forças sociais que agem sobre a equipe e dentro dela é que são elas.

Pra isso, toda equipe precisa de um bom líder que tenha tato, e saiba conduzir as coisas com respeito e coragem. Liderança é uma característica que se desenvolve com tempo, humildade, e persistência.

Vejam o belo artigo com que RonJeffries nos presenteou na semana passada. Tive a iniciativa de traduzi-lo assim que acabei de ler.`

A propósito. Não me parece um texto sobre produtividade, mas sobre liderança e coaching:

----oo---oo----

No início de sua gestão como CTO, Kate Oneal enviou uma breve nota a suas equipes, dizendo:

"Gostaria que nossas equipes trabalhassem para melhorar continuamente sua produtividade. Cada equipe, por favor, desenvolva um plano de como pensa em fazer isso, e como pode relatá-lo brevemente, por escrito, de modo que possamos aprender com suas experiências, sintetizá-las e enviar para nossos executivos. Contem comigo, se precisarem. Aguardo seus relatório no início do mês, por favor. Obrigado."

As equipes tiveram reações diversas, desde a defensiva imediata, até a iniciativa de começar a coletar algumas métricas para ver onde se poderia chegar. A equipe do projeto Rimshot se reuniu para conversar. Eis as principais linhas de pensamento que suriram:

- Susan disse, "A Kate deveria ter nos dito o que ela entende por produtividade e como devemos medi-la, de modo que possamos fazer exatamente o que ela quer."

- Bill disse, "Nós devemos resistir o quanto pudermos. Todos sabemos que otimizar os números não funciona."

- James disse, "Vamos pensar em algumas formas de melhorar e medir a melhoria, e passamos isso a ela."

- David disse, "Talvez seja melhor esperarmos e vermos o que as outras equipes farão."

- Bill disse, "Não! Isso é apenas mais uma estratégia pra fazer a gente trabalhar mais."

- James disse, "Não é tão ruim assim. Nós ainda não conhecemos a Kate muito bem, e nem ela nos conhece. Devemos nos esforçar para construir uma relação de confiança."
- Bill disse, "Eu sou um programador Jim, não um psicólogo. Eu trabalho com código, não com relacionamentos."

Todo mundo riu. A discussão parecia não terminar, então decidiram marcar uma reunião com Kate para discutir o assunto.

--o-o--

Alguns minutos antes da reunião, estavam todos na sala de Kate, prontos para irem embora, como sempre acontecem nas reuniões com ela. Assim que o relógio marcou a hora combinada, ouviu-se os passos de Kate no corredor. Ela entrou e se posicionou em frente a seu lugar de costume na mesa de reuniões.

Bill, que tinha certeza que ela iria no mínimo se atrasar, cochichou com Alan, ao seu lado: "Como ela faz isso? A um minuto atrás ninguém sabia onde ela estava, e de repente aí está ela."

Do outro lado da sala, Kate falou, "Teletransporte na cadeira de rodas. Eu estava em Denver agora a pouco."

Todos riram. Mas como é que ela consegiu ouvir aquilo?

Kate iniciou a reunião: "Olá pessoal, o que está havendo?"



Como ninguém respondeu de imediato, ela procurou com os olhos até que que James, de algum modo, se viu diante do grupo e, como um locutor repentinamente designado, ele decidiu falar:

"Bem, sabe aquele memorando sobre produtividade que nos mandou?"

"Sim," disse kate.

"Bem, gostaríamos de conversar sobre isso."

Kate sorriu e aguardou em silêncio.

"Gostaríamos de entender melhor o que você quer, para podermos fazê-lo," disse James.

"Então vocês querem saber o que preciso, para poderem fazer?" perguntou Kate.

"Sim, o que você precisa?"

"Ok, podem perguntar."

"Bem," disse James, "o que você precisa?"
"O que estou pedindo é que trabalhemos para melhorar continuamente nossa produtividade, e para fazermos isso de um modo que possamos demonstrar como estamos fazendo."

"Ok, mas o que significa melhorar a produtividade?", perguntou James.

"O que vocês, da equipe do Rimshot, fazem?" perguntou Kate.

Do outro lado da sala, Bill virou-se para Susan e e sussurrou. "Ela nem ao menos sabe o que nós fazemos?!"

Susan sussurrou de volta, "Ela sabe tudo."

Kate olhou para Susan do outro lado da sala, sorriu, e assentiu com a cabeça.

"Imaginem que eu não saiba. O que a equipe de vocês faz?"

"Bem, nós implementamos as histórias para o cliente do Rimshot."

"Bom," disse Kate, "eu já esperava que fosse isso. O que a produtividade pode significar pra vocês então?"

Silêncio. Então Susan disse, "nós podemos implementar mais histórias."

Kate respondeu, "Isso me soa bem. Mais histórias significa mais produtividade, então?"

Bill precisava corrigir isso. "Não necessariamente. E se nós implementarmos mais histórias, mas com mais bugs?"

"Bugs são ruins, certo?" perguntou Kate.

"Dã... Claro que são," disse Bill.

Kate fingiu uma risada. "Dã, claro. Então menos bugs seria bom?"

"Claro," disse Bill.

"Espere," disse Susan. "E se tivermos menos bugs, mas implementarmos menos histórias? Isso também não seria bom."

"Entendo," disse Kate. "Como o número de histórias e o número de bugs influenciam na produtividade, então?"

A equipe discutiu um pouco. James foi então compelido novamente a falar. "Bem, mais histórias é melhor, a princípio, a menos que outra coisa venha a piorar. E menos bugs é melhor, a princípio, a menos que isso diminua muito nosso ritmo."
"Me parece certo," disse Kate.

"Então você está nos pedindo para registrar os defeitos e a quantidade de histórias, para diminuirmos um e aumentar o outro?" perguntou Bill.

A equipe sabia que a pergunta era capciosa, assim como Kate. "A decisão é sua. Mas se trabalharem apenas pelos números, não haverá formas de burlá-los? Não que vocês o fariam de propósito, claro."

Kate tirou da manga a melhor carta de Bill, antes que ele pudesse jogá-la.

Bill seguiu em frente. "Hummm, sim. Nossa maior concepção sobre as métricas é a de que elas nos levam a resultados ruins. Mesmo se fizermos várias métricas, isso apenas tornará as coisas mais complicadas, sem levar a resultados reais."

Kate disse, "Está certo. É por isso que eu não estou pedindo métricas"

"Um dos meus livros favoritos relacionado a isso é o 'Punished by Rewards' [Punido pela recompensa], de Alfie Kohn. O que eu aprendi desse livro é que incentivos, recompensas e punições na verdade não funcionam muito bem. Eu tenho uma cópia em meu escritório, se alguém quiser emprestado."

"Mas espere," disse Kate, "não somos perfeitos, somos? Nós temos espaço para melhoria? Existe algum modo de melhorar, e saber que estamos melhorando?"

A equipe pensou um pouco, então James tomou a frente. "Bem, tem coisas que fazemos que desperdiçam tempo. Quando estávamos nos preparando para essa reunião, alguém comentou que perdemos muito tempo resolvendo problemas de integração. Isso fica em algo perto de oito pessoas-hora por semana. O que dá um dia inteiro de trabalho!"

"Se reduzissem esse tempo, o que conseguiriam?" perguntou Kate.

"Bem, conseguiríamos mais tempo." disse James.

"E porque isso seria bom?" perguntou Kate.

"Humm. Poderíamos gastar esse tempo fazendo coisas mais produtivas. Poderíamos gastar um dia inteiro refatorando o código, por exemplo."

"E porque eu deveria me importar com refactoring?", perguntou Kate.

"Porque torna o código mais limpo." disse Bill.

"E porque eu deveria me importa com código mais limpo?"

"A gente trabalha mais rápido quando o código está limpo." disse Bill.

"E mais rápido é melhor porque..." disse Kate.

"Bem, porque conseguimos implementar mais histórias?" disse Bill.

"Isso seria bom, a menos que pioremos outras coisas, certo?" disse Kate.

"Sim." disse James. "Se diminuirmos esses problemas de integração, ficaremos menos aborrecidos, poderemos manter o código bem mais limpo, e poderemos seguir para outra história. Está bom pra você se apresentarmos um plano dizendo que, nos próximos meses, pretendemos reduzir os problemas de integração, transformando essas horas em tempo produtivo? "

"Isso me soa bem," disse Kate. "Existe algum modo pelo qual vocês possam demonstrar onde esse tempo está sendo investido? Imagino que as pessoas gostariam de saber que ele está sendo usado com sabedoria."

"Eis uma idéia," disse Susan. "E se estabelecermos nosso objetivo como sendo reduzir o tempo gasto com problemas de integração, e usar esse tempo com atividades mais valiosas. Nós poderíamos reportar o progresso com dois pequenos gráficos. Um mostrando algo como o número de problemas de integração, e o tempo para resolvê-los. E o outro mostrando a porcentagem média de tempo alocado."

"O que o segundo gráfico nos mostraria?" disse Kate.

"Mostraria como estamos gastando nosso tempo. Se fizermos coisas que nos tornam melhores, nós provavelmente veremos mais tempo sendo gasto com coisas boas, como novas histórias e refactoring, e menos tempo com coisas ruins, como resolvendo bugs e nos irritando com integrações." disse Bill.
"Me parece bom. Se todos acabarem contando como economizaram tempo, e onde usaram esse tempo, poderemos comparar as notas e compartilhar idéias. E mais, tenho certeza de que outros departamentos, além do de tecnologia, vão adorar saber o que estão fazendo. Vocês podem pensar sobre isso e decidir se pretendem ir nessa direção, ou se preferem desenvolver mais a idéia, e nos trazer algo ainda melhor?" disse Kate.

A equipe discutiu um pouco. "Sim, podemos." disse James. "E faremos. Obrigado."

"Obrigado a vocês, pessoal. Estou ansiosa pra ver o que me trarão."


A equipe do Rimshot voltou a seu ambiente de trabalho. Todos estavam felizes e contentes.
"Ok," disse Bill, "conseguimos que ela respondesse à nossa pergunta, e nem precisaremos coletar métricas estúpidas."

Todos começaram a concordar, até que Alan falou, "Espere. Kate não chegou nem a responder nossa pergunta. Nós mesmos é que chegamos à resposta ali, bem na frente dela. Nós somos melhores do que imaginávamos!"

Longe dali, em seu escritório, Kate sorria. :-)

Primeira reunião do grupo AgilDF

Semana passada tivemos o primeiro encontro presencial do pessoal da lista AgilDF. Coloquei algumas fotos no flickr. Se tiverem mais fotos, me mandem!

O teste do post-it para diagramas UML

Esses dias, na primeira reunião presencial do grupo AgilDF, discutimos um pouco (como sempre) sobre documentação de requisitos e projetos técnicos (design) em documentos.

Como é uma questão que sempre vem à tona, achei por bem traduzir essa dica do Dean Wampler publicada a alguns dias no blog da ObjectMentor. Vejamos se isso rende alguma discussão:

Muitas equipes exigem que os desenvolvedores documentem o design da aplicação em UML, usando o Visio ou outra ferramenta do tipo, antes que comecem a codificar.

Obviamente, essa não é uma abordagem tipicamente ágil. Primeiramente, é muito provável que o design mude um pouco com o aprendizado da equipe, enquanto o código é criado. Como dificilmente alguém retorna aos diagramas e os atualiza, eles acabam, por fim, descrevendo uma mentira, já que não refletem mais o estado atual do sistema.

A UML ainda assim possui um papel importante em projetos ágeis, claro. É uma ótima ferramenta para brainstorm das ideias sobre o design. Agora, como podemos saber se vale à pena guardar e manter um dado diagrama? Aqui está uma pequena estratégia que recomendo.

Desenhe os diagramas, durante as sessões de brainstorm, em um quadro branco ou em um post-it grande o suficiente. Dessa forma, você não terá investido praticamente nada, além do tempo do brainstorm, para criar os diagramas. E mais: você não se sentirá mal pelo trabalho perdido, caso jogue o diagrama fora algum dia (se ele não se mostrar mais útil, ou mudar radicalmente).

Deixe o diagrama na parede para que todos possam consultá-lo enquanto o implementam.

Quando o post-it começar a cair da parede, ou quando o desenho começar a se apagar e borrar no quadro, avalie se a ideia desenhada ainda é relevante ou se já se tornou obsoleta.

Se for obsoleta, apague o quadro ou queime o post-it. Se o desenho ainda for relevante - e provavelmente já terá mudado um pouco - você já pode se considerar convencido de que vale à pena guardá-lo. Vá em frente e gaste algum tempo criando uma versão mais permanente em sua ferramenta de desenho (mas cuidado pra não perder tempo demais com isso!).