eXPresso Capital

Dojo e Capoeira 6 - Ações Práticas

2011-09-04T10:58:00.009-03:00

Durante os últimos dois meses, estive escrevendo essa série de posts que manifestam uma opinião e um desejo de que o valor da prática do coding-dojo seja reconhecida como merece. Nesse post, pretendo concluir a série traçando a linha de pensamento que relaciona os outros posts, e tentar enfim ser um pouco prático e concreto, explicando minha idéia de atuação no desenvolvimento social da prática por meio do DojoSpot.

O sistema educacional tradicional não atende mais a nossa sociedade em rede, mas as pessoas continuam escolhendo pagar pós-graduação de faixada a freqüentar as sessões de dojo, ainda que admirem a metodologia do dojo. Foi o assunto que introduzi no primeiro post.

Nesse sentido, o movimento do dojo ainda não conseguiu encontrar o fino equilíbrio entre duas variáveis fundamentais: comprometimento e reconhecimento. As pessoas se dedicam ao dojo, organizando e participando das sessões, mas não se sentem reconhecidas o suficiente para sacrificarem seus fins de semana. Creio que esse equilíbrio pode ser um ponto de alavancagem importante para elevar nossa prática em termos de reconhecimento social, como defendi no segundo post.

Mestre Luiz Renato e eu, na minha formatura de monitor

É claro que as pessoas não participam do dojo só por reconhecimento. Nem parece saudável que assim o seja. Não devemos cultivar a idéia de que a motivação principal para participar de dojos seja o reconhecimento. As pessoas precisam continuar participando das sessões deliberadamente, por estarem de fato profundamente interessadas na ludicidade da atividade. Foi o assunto do terceiro post.

Uma intervenção na organização dos grupos, que eventualmente possa causar a popularização da prática, poderá trazer alguns efeitos colaterais negativos, não há dúvidas. Devemos ter muito cuidado e zelo pra não destruirmos a praia deserta que achamos, enchendo ela de turistas gafanhotos, na linha do que defendi no quarto post.

Mas ainda que alguns prejuizos possam acontecer ao longo desse caminho (e acho que acontecerão!), entendo que muitas outras conquistas grandes (e até bem impensáveis pela maioria de nós) podem acontecer, assim como acho que aconteceram com a Capoeira, como expliquei no quinto post.

'E sem saber que era impossível, ele foi lá e fez...'
(Jean Cocteau) (via Be)

Ainda que os grupos de dojo venham a se dividir em modernistas e tradicionalistas (regional e angola), acredito que no balanço geral vamos sair ganhando se acharmos uma negociação saudável entre os princípios do dojo e o imediatismo ocidental. É melhor começarmos a nos movimentar logo, antes antes que alguém acabe achando um jeito de enriquecer com a coisa (ou, se preferirem, "antes que um aventureiro lance mão").

Sendo prático, enfim ;-)

Minha sugestão é a de que tentemos retribuir o comprometimento das pessoas com o dojo, por meio de um sistema que tangibilize a reputação, parecido com as cordas da Capoeira ou como o que faz StackOverflow, por exemplo. Creio que à medida em que as pessoas se sintam retribuidas, elas passem a participar mais (e melhor) das sessões, aumentando assim a reputação do dojo em si. À medida em que o dojo se torne mais respeitado, os participantes com maior reputação também se tornarão.

A respeito do sistema de reputação, creio que precise ser muito bem pensado e adaptado ao longo do tempo para que se valorize as coisas certas, para que os princípios certos sejam cultivados. Creio que a regra do jogo influencie de modo determinante o comportamento dos jogadores e o desenrolar da partida.

E como os valores e princípios 'certos' a serem cultivados são relativos, acho que precisamos de um sistema que permita a manifestação da diversidade de visões, bem ao modo open-source. Se eu mantenho um dojo, e crio uma regra de reputação com a qual você não concorda, basta reunir as pessoas que concordam com você e criar outro grupo que funciona com outras regras.

E é exatamente o que vejo que acabou acontecendo com a Capoeira e seus grupos. No meu grupo, valoriza-se compromisso, respeito, e criatividade, e portanto capoeiristas que jogam com lealdade e criatividade, e não faltam treinos, podem conseguir uma corda de professor. Em grupos que valorizam apenas a combatividade e a destreza física, eu provavelmente não teria conseguido alcançar a corda que tenho. Ambas as visões estão corretas, e ao meu ver devemos achar mecanismos que valorizem a diversidade, ao invés da padronização.

E pra não ficar só no discurso vazio foi que comecei meu ativismo contribuindo para o dojo-brasília e criando uma primeira versão (ainda bem crua) do que acho que pode ser o sistema por trás dessa idéia: o DojoSpot, que como não podia deixar de ser, é de domínio-público (open-source) para que seja adaptado do jeito que for necessário.

O DojoSpot, por enquanto, ainda não tem nenhum tipo de reputação. Apenas permite que as pessoas marquem uma sessão e que confirmem sua participação nela. A próxima funcionalidade que pretendo acrescentar é o registro de presença, que acho que deve ser o primeiro critério de valorização a se expressar na página de participantes.

Durante o OpenSpace da AgileBrazil2011 ouvi outras sugestões que adorei, das quais destaco duas:

1) O botão de 'obrigado' que permitirá que, a cada sessão, as pessoas distribuam dois agradecimentos aos participantes de quem considerariam ter aprendido alguma coisa valiosa naquela sessão; e

2) A utilização de 'badges' que premiam as pessoas que cumpriram certos critérios de contribuição específicos. Por exemplo, 'batizado' poderia ser concedido à pessoa que tem 10 presenças e um kata apresentado; 'Anfitrião' à pessoa que organizou ou hospedou mais de 5 dojos; e por aí vai...

Por enquanto, se você estiver com vontade de contribuir e não souber como, acho que uma primeira ajuda importante poderia ser a instalação e a utilização do sistema em outros dojos, para melhorarmos a documentação sobre como instalar, como adaptar o layout, e etc.

Fora isso, qualquer tipo de sugestão ou crítica será recebida com festa!

Correções, adaptações ou melhorias poderão sempre ser feitas à vontade, seguindo a lógica do Github.

Isso encerra essa seqüência de posts, bem ao meu estilo (como o Silvano notou outro dia) filosófico, abstrato e repentinamente conclusivo (rs).

Agradeço imensamente pela atenção de quem chegou até aqui, e reitero que adoraria que a discussão continuasse e se desenvolvesse na lista de emails que criamos. Participe lá, que no mínimo ajuda com a minha motivação pessoal ;-)

o/

Dojo e Capoeira 5 - Bimba e a regional

2011-08-29T11:25:00.002-03:00

Na semana passada falamos sobre o dilema entre popularizar e preservar. Dessa vez, num post um pouco mais longo que os anteriores, vou falar sobre como o mestre Bimba influenciou definitivamente a história da Capoeira, e o que podemos tirar de aprendizado daí.

No finalzinho de século XIX, a capoeiragem passou a figurar no código penal brasileiro como crime, passível de pena de prisão. Em 2008, ela passa a ser oficialmente reconhecida como patrimônio cultural do país. O que aconteceu de lá pra cá é uma história longa e complexa que nem me atrevo a tentar resumir (mesmo porque não sou eu o especialista no assunto). Mas quero mesmo assim tocar em alguns pontos que são importantes para minha tese.

Mestre Bimba

Antes de mais nada, é importante esclarecer que a história da Capoeira (assim como tantas outras) é coberta de mitos que até hoje são aceitos pela maioria das pessoas, apesar do grande desenvolvimento recente nas pesquisas históricas nessa área. Diferentemente do que muita gente pensa, a Capoeira teve muito provavelmente origem urbana, no Rio de Janeiro, e representava muito mais uma brincadeira de vadios do que uma tática de guerrilha dos escravos na fuga das senzalas, dos engenhos de cana de açúcar da Bahia. A capoeira não era então praticada de calça branca, com hora e local marcados, não tinha cordas coloridas na cintura e muito menos era ensinada em academias em alguns dias estipulados da semana, na forma como a conhecemos hoje.

No meio desse longo caminho de transformação estava, como já mencionado no post anterior, um homem cujo projeto foi talvez o fator de mudança mais profundo ao longo desse processo: mestre Bimba. Negro e pobre - assim como provavelmente todos os outros capoeiristas da época - foi ele quem percebeu que a luta brasileira vinha perdendo cada vez mais valor e respeito da sociedade do início do século. Bimba era lutador conhecido na cidade por desafiar e vencer praticantes de todas as outras artes marciais, e achava que a incorporação de golpes e movimentos mais agressivos fariam da Capoeira uma luta mais eficiente e respeitada.

Nesse processo, além de transformar a Capoeira do ponto de vista dos movimentos e golpes, ele também incorporou em sua prática alguns simbolismos e ritos familiares a outra camada da sociedade: a classe média-alta, branca, da sociedade baiana. Bimba criou um método de ensino e passou a ministrar aulas da luta brasileira em academias militares. Incorporou uniformes, um sistema de graduação (que deu origem às cordas coloridas que conhecemos hoje), e rituais de batismo e formatura - elementos ocidentais completamente estranhos à manifestação vadia que até então acontecia espontaneamente nas ruas.

De lá pra cá, muitos desdobramentos dessa transformação fizeram da Capoeira isso que conhecemos hoje. Como discutido no post passado, esse processo de transformação é visto por muitos como uma deturpação cultural a que se deve oferecer resistência e da qual a tradição precisa ser preservada. Para outros, ele foi fundamental para que ela sobrevivesse ao preconceito e à repressão que a sociedade brasileira sempre teve em relação às manifestações de raizes africanas e pobres. Minha opinião é a de que ambas as visões estão parcialmente certas e erradas, ao mesmo tempo. É claro que a Capoeira teve prejuizos com essas mudanças, mas também é claro que teve benefícios. Não é a toa que é hoje um dos elementos culturais brasileiros mais valorizados no exterior. Aliás, muito mais que aqui, diga-se de passagem!

Um processo parecido aconteceu com o Jiu-Jitsu, no Japão pós revolução industial, depois da revolução Meiji, durante o processo de 'modernização' e ocidentalização da cultura japonesa. Como parte de um projeto governamental, num processo de negociação bem parecido com aquele feito por Bimba, Jigoro Kano esterilizou a agressividade da luta e criou o Judô, com suas regras e sistemas de faixas. Por um lado ele deturpou a luta e a tornou muito menos eficiente, mas por outro, ele manteve vivo um elemento da cultura samurai que estava então em processo de verdadeiro extermínio e a elevou mais tarde ao status social de esporte olímpico, praticado no mundo inteiro.

Deturpação ou adaptação? É impossível delimitar até que ponto essas mudanças foram benéficas ou destrutivas. Mesmo porque ninguém nunca saberá o que teria acontecido caso esses dois homens não tivessem interferido na história. Eles provavelmente agiram movidos por suas intuições, imersos que estavam nos respectivos processos sociais, e portanto é impossível julgar se estavam certos ou errados.

Jigoro Kano

Eu, de minha parte, prefiro também acreditar em meus instintos de que o desenvolvimento dos processos pedagógicos estão em plena metamorfose (assim com todo o resto da sociedade em rede) e de que os critérios de mérito e reconhecimento profissionais na área de TI são irracionais (no mínimo) e incompatíveis com a nova realidade que esta-se criando. Creio portanto, que algum tipo de intervenção possa (e deva) ser feita para que os processos pedagógicos surgidos e desenvolvido no contexto dos coding-dojo's ganhe mais reconhecimento e adesão social, transformando sua atual situação de marginalidade.

Para isso, me parece inevitável que tenhamos que passar por algum processo de negociação e adaptação, assim como aconteceu com a Capoeira e com o Judô. Acredito ainda que a comunidade deve tomar a frente nesse processo, de modo consciente, refletido, coordenado e pró-ativo, de modo a tomar as rédeas e participar dele dando as cartas, ao invés de apenas reagindo ao que acabar acontecendo por si só.

A partir do próximo post, pretendo começar a refletir sobre possíveis formas de intervir nesse processo. O que podemos fazer em termos de organização dos nosso grupos de dojo? Até que ponto podemos intervir para fortalecer socialmente a prática, mas sem ferir seus princípios fundamentais e sua natureza não-ocidental? Semana que vem eu coloco minha opinião aqui ;-)

Continue lendo a última parte >>

Dojo e Capoeira 4 - O dilema do turista

2011-08-21T08:30:00.005-03:00

Esse é o 4o post da série onde tento relacionar os grupos de Coding-Dojo com a lógica histórica social dos grupos de capoeira. Nos posts anteriores, falamos sobre as motivações que as pessoas têm para se dedicarem aos grupos. Desta vez, vamos começar a falar sobre a dicotomia e a aparente contradição que existe entre a popularização e a preservação.

O turista é uma figura que vive uma contradição interessante. Ao mesmo tempo em que ama e cultua o lugar que visita, acaba sem querer ajudando a destrui-lo. O mesmo sujeito que reclama da praia cheia de turistas - aquela que não é mais o paraíso perdido de quando ele a conheceu pela primeira vez - esse mesmo sujeito acaba fazendo parte da legião de farofeiros, ainda que não goste de reconhecer. As pessoas adoram uma cachoeira vazia, mas não se contêm em anunciar aos amigos que eles "precisam que conhecer [aquele lugar], antes que acabe!" E quanto mais gente vai, mais rápido o lugar se acaba!

Roda de Capoeira Angola
(mestre João Grande - NY)

Pense num pequeno restaurante, cheio de capricho, com atendimento personalizado, música boa, ambiente agradável... O dono logicamente adoraria popularizar seu restaurante, ampliar e ganhar um pouco mais. Afinal de contas, ele merece um reconhecimento por seu esforço de manter um bom restaurante. Mas o que acontece quando ele aluga a loja ao lado, dobra o tamanho do salão e contrata mais garçons e cozinheiros? Perde-se boa parte da qualidade que diferenciava o lugar e o restaurante se acaba!

É como se essas coisas lindas tivessem dentro de si a semente de sua própria destruição. Será uma característica inerente do ser humano, esse estilo gafanhoto de destruir tudo o que toca? Não creio...

O dilema que vivemos no contexto do Dojo é parecido, na minha opinião. E é justamente aqui que começo a fazer o gancho com a história da Capoeira. Devemos desenvolver mecanismos para popularizar e fortalecer a prática, ou devemos ser cuidadosos e preserva-la pura, intacta?

A Capoeira viveu (e ainda vive!) um dilema histórico que acho bastante relacionado. Hoje a maioria das pessoas divide a Capoeira em dois grandes estilos: Angola e Regional. O surgimento nos anos 30 da luta regional baiana, ou Capoeira Regional, foi resultado de um projeto de um homem: Manoel dos Reis Machado - o Mestre Bimba. A Capoeira Angola surge alguns anos depois como movimento de resgate da tradição, opondo-se à 'modernização' da Regional.

Roda de Capoeira Regional

Bimba inseriu na Capoeira elementos de outras lutas, tornando-a mais agressiva, e incorporando simbolismos ocidentais que aproximaram a cultura 'de rua' (negra, africana, pobre, marginalizada), de uma camada da sociedade branca (rica, institucionalista).

Para os olhos de muitos, esse processo representou uma deturpação irreversível da Capoeira. Para outros, é bem possível que a nossa arte-luta não tivesse sobrevivido (como aconteceu outras manifestações 'irmãs') à repressão social histórica que chegou a se manifestar na proibição explícita de sua prática no final do século XIX.

Será que a articulação de Bimba deturpou definitivamente nossa arte luta, ou terá sido um elemento indispensável de fortalecimento e preservação da Capoeira? No próximo post vou elaborar melhor esse conflito, seus resultados, e discutir o que podemos tirar de aprendizado dele para o contexto da organização social dos grupos de Dojo.

Continue lendo a próxima parte >>

Dojo e Capoeira 3 - o caminho do principiante

2011-07-31T11:00:00.006-03:00

Na semana passada, falei do ciclo Comprometimento <=> Reconhecimento que mantém vivas as iniciativas que vão pra frente. Hoje pretendo falar um pouco mais sobre o desequilíbrio que existe na sociedade do Dojo, relacionado a essa fórmula. Pretendo também apresentar outro ponto de vista que faz parte desse cenário: o de que devemos participar dos Dojos sem esperar nada em troca, pelo simples fato de participar - deliberadamente. Assim, explicitar e reforçar esse equilíbrio talvez não seja benéfico para a prática do Dojo!

Creio que essa fórmula Comprometimento <=> Reconhecimento valha em qualquer cultura, mas na nossa sociedade ocidental, materialista, ela costuma se manifestar de forma especialmente explícita e imediata. A criança precisa ganhar um chocolate porque arrumou o quarto e o funcionário precisa ganhar um aumento rapidamente em troca de uma iniciativa importante que teve no trabalho. O retorno precisa ser rápido e explícito. É a forma como nossa cultura nos ensina.

Vejo vários grupos que acham a idéia do Dojo linda, se motivam, criam uma lista, realizam alguns encontros, e algumas semanas depois a iniciativa vai perdendo adeptos, perdendo energia, e aí morre. Estou devendo pro Henrique uma pesquisa nas listas de Dojo brasileiras sobre o tempo médio de permanência das pessoas nas reuniões de Dojo. Acho que deve ser bem pequeno... Imagino umas 3 ou 4 sessões semanais, no máximo!

Mestre Valdemar da Paixão

Minha hipótese é a de que a sociedade do Dojo está sentindo falta de reconhecimento, pra balancear a mistura. Um sinal muito claro disso é o fato de que as pessoas simplesmente a-do-ram colocar fotos nos blogs e tuitar quando vão a reuniões de Dojos. Assim como o que as pessoas fazem depois de assistirem a um cursinho de Scrum, chegar na empresa e pregar o kanban na parede: a primeira coisa a fazer depois de grudar os post-its, invariavelmente, é tirar uma foto e postar no blog. Por quê? Na minha opinião, as pessoas estão procurando (pedindo!) um retorno pela pequena conquista que tiveram. E nesse caso, assim como no do cara aprendendo a tocar violão, se o feedback positivo não vier (um comentário, um elogio) a iniciativa acaba morrendo...

Esse pensamento não tem absolutamente nada a ver com a ética do caminho do principante, da arte Zen, ou com outras manifestações culturais em que o importante não é a chegada, mas o caminho! É um pensamento muito nobre e bonito, que reconhecemos imediatamente como bom, e que tentamos importar pra nosssa cultura algumas vezes. É o que nos foi apresentado desde meninos em filmes como Karatê-Kid. "Daniel San, lixa o assoalho! Pinta a cerca!" Não importa o objetivo. O ponto não é a cerca pintada. Não se preocupe com o objetivo final, concentre-se no caminho que o resto acontecerá.

Mas ainda que reconheçamos a qualidade dessa ideologia, vivemos impregnados e imersos com os valores de nossa cultura. As pessoas acham linda a idéia do Dojo. Mas quando chega a hora H, depois do trabalho, o cara prefere ir ao cinema. O mesmo não acontece com a pós-graduação, que é paga e tem um diploma no final. (Perceba que o Dojo nem ao menos tem um final definido! São lógicas que não se encaixam uma na outra, pelo menos a princípio.)

Roda do Mestre Valdemar

Entendo perfeitamente (e concordo) que criar mecanismos e símbolos 'ocidentais' de recompensa para uma prática como o Dojo, guiada muito mais pelos princípios do caminho do aprendiz que pela lógica do toma-lá-da-cá, vai trazer invariavelmente algumas consequências e efeitos colaterais negativos. Mas no fim das contas, creio que seja apenas uma questão de escolhas. Acho que se nada for feito, ou os Dojos desaparecem, ou se popularizam em decorrência de alguma certificação idiota que estraga completamente a idéia original. Acho que se tomarmos as rédeas da coisa a tempo, podemos tentar ajudar a achar um ponto de equilíbrio entre esses dois fins, em que o Dojo não precise ser completamente "desocidentalizado" e puro, e nem totalmente prostituído e corrompido.

No próximo post dessa série, pretendo elaborar melhor esse ponto da dicotomia entre o popularizar e o preservar (o que gosto de chamar de "o dilema do turista"). É onde quero criar o gancho com a história da capoeira, que passou por um processo bastante semelhante, no meu ponto de vista.

Continue lendo a próxima parte >>

Dojo e Capoeira 2 - A Lógica do Toma Lá Da Cá

2011-07-24T11:22:00.005-03:00

Continuo nesse post a reflexão iniciada semana passada sobre o paralelo entre a prática do coding-dojo e a lógica de reconhecimento nos grupos de capoeira. Esse post introduz o equilíbrio sistêmico necessário para manter vivo uma iniciativa - um dos pontos centrais da idéia que estou tentando defender aqui.

Se enxergarmos o ser humano e a sociedade como sistemas complexos, podemos observar alguns ciclos de energias fundamentais para a sobrevivência de seus elementos. O exemplo mais banal é o trabalhador que recebe em troca seu salário. Outra troca um pouco mais sutil ocorre no relacionamento entre um homem e uma mulher. Cada um coloca um pouco de si no casal, e o casal suporta os dois de várias formas. Uma pessoa estudando violão, fazendo escalas e machucando seus dedos é recompensado pelo elogio de um amigo, pela alegria das pessoas cantando junto, ou pelo prazer de meditar sobre o instrumento interpretando uma música pra si mesmo. Se a recompensa pelo esforço não corresponder, a pessoa abandona o violão no canto.

Mestre Bimba

Uma iniciativa qualquer que alguém tenha, digamos, para motivar um grupo de amigos a almoçar juntos na sexta, funciona como um complexo de trocas. A pessoa investe um pouquinho, sugerindo o programa. Alguém gosta da idéia mais que os outros e retribui dizendo que topa. Esse pequeno retorno motiva o cara a procurar um restaurante na internet e começar a descreve-lo para o grupo. Alguém faz uma piada, entra na conversa, faz um comentário. É o suficiente pro cara levantar e ligar reservando. Se a primeira pessoa não tivesse topado, o cara tinha desanimado e a iniciativa tinha morrido.

É como um pequeno empreendimento. Você investe um dinheirinho e vê no que dá. Se der retorno, você ganha confiança e investe mais um pouquinho. A gente usa o feedback do sistema pra decidir se continuamos nesse caminho ou se mudamos.

Acontece também com o programador que contribui com um projeto open-source. A retribuição do trabalho vem na forma de reconhecimento dentro da comunidade. Ninguém continua eternamente comitando num projeto que não está tendo uso. Se aparece um usuário, a gente já se motiva a responder um email, ou quem sabe ajudar o cara a instalar. Se surge outro e outro usuário, a gente já anima de mexer no código, deixar a página do projeto atualizada e fazer alguma correção.

Depois de muito refletir sobre essas trocas acontecendo em diversos aspectos da minha própria vida, cheguei à conclusão de que as iniciativas que vão pra frente são aquelas que mantém ciclos virtuosos que se reforçam, num equilíbrio fino entre duas variáveis principais:

Comprometimento <=> Reconhecimento

Tenho a impressão de que sociedade do Dojo vive um certo desequilíbrio nessa fórmula. Ir ao Dojo, preparar Katas, ajudar os iniciantes, arrumar um lugar, preparar o projetor, pedir a pizza, reservar o horário na agenda. Tudo isso representa uma boa dose de comprometimento por parte das pessoas. O reconhecimento, por outro lado, talvez não esteja sendo o suficiente.

Semana que vem vou tentar encaixar isso com a lógica do Dojo, do caminho do principante Zen, das artes orientais. Afinal de contas, essa lógica imediatista de retorno não é o único motivo pelo qual a gente participas de Dojos. É?

Continue lendo a próxima parte >>

A Sociedade do Dojo e os Grupos de Capoeira - parte 1

2011-07-17T10:17:00.004-03:00

Como podemos alavancar socialmente a prática do Dojo por meio do desenvolvimento do sistema de reconhecimento de mérito nas comunidades de Dojo, e o que podemos aprender com a história da Capoeira que possa nos auxliar nessa reflexão?

A sociedade está passando por um choque. O nosso sistema educacional retrógrado não serve mais para sociedade em rede. Ficar sentado numa cadeira desconfortável tentando prestar atenção a uma palestra chata pra depois decorar tudo em casa e responder a uma prova que não prova nada no fim do mês não é mais uma opção.

Mestre Pastinha

Manter um Coding-Dojo nos últimos anos me ensinou muita coisa. Bem mais do que aquilo que pretendíamos aprender codando (o que já foi coisa pra caramba!) O Dojo é uma metodologia educacional muito mais afim com a dinâmica do mundo novo.

O ambiente participativo, onde todos são iguais e têm a permissão de errar; onde o exemplo substitui a autoridade do professor e a mão na massa substitui a explicação teórica; onde a prática deliberada e a curiosidade do grupo regem a ementa e o currículo - é esse o ambiente de aprendizado do Dojo e é o tipo de coisa que deve orientar a educação do século 21.

Mas essa forma orgânica e holística de aprendizado se choca diretamente com o modo ocidental de ver o mundo. Quando uma pessoa escolhe fazer uma pós graduação (cara, chata, noturna - depois do expediente de trabalho, já cansado - onde ela reconhece que vai aprender muito pouco) ao invés de participar da reunião semanal do Dojo (onde vamos comer pizza e rir um bocado, de graça, e aprender muuuuuito mais), nesse momento o sonho frágil é silenciosamente sufocado pela tradição estúpida da escola pós-industrial.

Ainda que as pessoas sejam apaixonadas pela visão de educação do Dojo, elas acabam optando pelo diploma! O dia só tem 24 horas, então as faculdades privadas medíocres se proliferam e a reuniões de Dojo seguem vazias. É triste =(

Mas não dá pra mudar o mundo todo de uma vez. Temos que pensar globalmente, mas agir localmente. Pode parecer meio ridículo, mas alguém tem que se permitir ser um pouco ridículo, senão a gente paralisa.

A idéia dessa série de posts que inicia aqui é apresentar pouco a pouco o manifesto que tentei proferir na AgileBrazil2011. Vou tentar degustar essa escrita aqui aos domingos de manhã.

Se estiver afim de discutir a respeito, acho que a lista de email que criamos é mais apropriada que os comentários do blog.

>> Continue lendo a segunta parte!

Dojo, Capoeira, e muita discussão produtiva!

2011-07-05T20:50:00.003-03:00

Esse post é o follow-up do OpenSpace que fizemos no 3o dia da AgileBrazil2011, sobre sistemas de mérito e reputação da Capoeira aplicados ao contexto dos grupos de coding-dojo.

Chegamos ao fim de outro AgileBrazil. O evento desse ano foi muuuuuito rico (pelo menos pra mim)! Um dos pontos altos foi ter apresentado minha palestra sobre Dojo e Capoeira, que rendeu um OpenSpace muito legal onde discutimos sobre o assunto. No evento do ano passado eu já tinha tentado motivar um outro OpenSpace sobre o assunto, mas acho que a idéia ainda precisava de algum amadurecimento e a conversa não vingou... Dessa vez parece que foi =)

O assunto em si, que apresentei na palestra, vou deixar pra um outro post, dedicado, que possa ficar como legado pra posteridade. Mas resumindo muito, apenas pra contextualizar, a proposta que apresentei foi a de desenvolver o sistema de reconhecimento nas comunidades de coding-dojo como alternativa ao modelo de mérito predominante no nosso mercado, baseado em certificações.

A idéia é se espelhar nos sistemas de graduação dos grupos de capoeira, e na história da nossa arte-luta, pra justificar e embasar o cultivo consciente de um mecanismo de reconhecimento que seja coletivo, contínuo, méritocrático e diverso.

A Sociedade do Dojo e os grupos de Capoeira

A intenção principal é tentar equilibrar os relacionamentos dentro do grupo para talvez aumentar a retenção das pessoas, e a valorização social da prática (com todo o cuidado e a precaução necessários para não desvirtuar a prática e seus valores).

A proposta se concretiza hoje no desenvolvimento do DojoSpot, cuja intenção é funcionar mais ou menos como o StackOverflow, criando um sistema de reputação baseado no comprometimento das pessoas com a prática - só que nesse caso envolvendo a presença e a participação real (não apenas virtual, pelo site) das pessoas nos encontros.

O OpenSpace que organizamos no terceiro dia da AgileBrazil foi incrível! Juntamos umas dez pessoas que discutiram e refletiram sobre a proposta, seus pontos fortes e fracos, e deram várias idéias ótimas para evoluir a coisa.

A intenção agora é reunir os interessados em continuar a discussão nessa lista de emails, que acabei de criar:

http://groups.google.com/group/dojo-capoeira

Se vc está interessado, entre lá e se apresente.
Daqui pro fim de semana a gente dá início às discussões.

o/

[OpenSpace] Dojo, Capoeira, morte à certificação!

2011-06-30T11:07:00.000-03:00

Pra quem está na #AgileBR 2011, estou marcando aqui o OpenSpace pra dar continuidade à discussão que iniciou ontem depois da minha palestra.

O OpenSpace será uma discussão livre sobre o tema - Desenvolvimento do sistema de reconhecimento nas comunidades de coding-dojo como alternativa ao modelo predominante de mérito, baseado em certificações.

Acontecerá amanhã (sexta-feira), no lounge, durante o coffee-break da manhã, às 11:00.
(assim ninguém precisa perder nenhuma palestra...)

Os slides da minha palestra, pra quem ainda não viu:

A Sociedade do Dojo e os grupos de Capoeira

View more presentations from brunopedroso

Gestão Pública e Agile: Quem deve mudar?

2011-04-30T10:13:00.006-03:00

Tenho andado cada vez mais sem paciência com burocracias, regras sem sentido e culturas organizacionais enferrujadas. Mas sei que volta e meia perco um pouco da razão e pareço arrogante e radical com algumas ironias e sarcasmos. Por isso vou tentar me controlar um pouco nesse comentário.

O que me fez levantar da cama pra escrever nesse sábado foi o texto tuitado pelo @julioprotzek sobre a opinião de um advogado americano a respeito de porque Agile não funciona no setor público.

Já discuti muito esse assunto. É sempre um ponto levantado quando se fala sobre ágil em órgãos púbicos - coisa que fiz um bocado nos dois últimos anos.

Em poucas palavras o argumento é que como processos ágeis não são preditivos - não se comprometem desde o início com o resultado exato que o projeto vai ter no final - eles não se encaixam na estrutura de decisão que as entidades governamentais usam para contratar.

O governo precisa saber exatamente quanto vai custar, quando vai ficar pronto, e o que vai receber, nos mínimos detalhes. Isso por dois motivos: primeiro porque ele precisa comparar os fornecedores candidatos de forma imparcial e transparente, e segundo porque, se alguma coisa der errado, ele precisa ter alguém para responsabilizar.

(Interessante ver que os problemas são os mesmos aqui e lá)

A princípio, o argumento parece fazer sentido, mas acho que possui uma incoerência muito profunda.

As mudanças que a tecnologia da informação vem impondo ao mundo têm nos ensinado muito a respeito das velhas formas que usamos para 'administrá-lo'. O conflito entre pirataria e direitos autorais, entre o conceito trabalhista protestante e a ética hacker, entre a 'liberdade' de imprensa e as mídias sociais e as próprias relações econômicas, comerciais e legais num mundo onde as fronteiras geográficas importam (bem!) menos que as virtuais.

Enfim, o mundo está reaprendendo a viver, agora que a tecnologia expões teias de aranha bem densas na formas como estávamos acostumados a organizar a sociedade.

O processo de criação e engenharia não fica de fora dessa. Métodos iterativos de trabalho, baseados em feedback e confiança, equipes auto-organizadas e processos decisórios participativos são alguns exemplos de mudanças que Agile vem nos apresentando.

Continuar usando técnicas industriais para desenvolver software não vai funcionar! Chega de bater cabeça!

Então quando se diz que Agile não se encaixa nos processos de gestão que órgão públicos utilizam, pergunto: quem deve mudar?

Só pra não perder a oportunidade de ser um pouco sarcástico, deixo esse vídeo muito muito pertinente, em que tropecei agora a pouco quando estava na frente do computador quase quase desistindo de escrever esse texto. Enjoy!

Tweet Tuite esse texto.

Mensagens de commit

2011-03-19T11:14:00.003-03:00

Pra muita gente, pensar em mensagens de commit é uma coisa chata. Quando estamos descobrindo uma solução no código, o ato de parar um momento pra "commitar" e ainda ter que pensar numa forma rápida e clara pra descrever o último passo pode parecer quebrar a linha de raciocínio. O mais comum é que a ansiedade em voltar pro código faça o programador deixar essas mensagens em branco ou escrever qualquer baboseira.

Não faça isso!

Quem sofre é a pessoa que precisa depois achar o ponto certo pra reverter uma mudança, pra 'mergear' dois branches, ou pra recuperar uma peça de código que se jogou fora, mas então se percebeu que era útil.

Além disso, faço uma relação direta entre essas paradinhas e a organização pessoal das tarefas. Uma paradinha pra consolidar e deixar clara a finalização de um baby-step na evolução do código é muito muito muito útil. Sobre essa relação entre as mensagens de commit e o processo de organização (GTD, TDD, Pomodoro) prefiro recomendar que assistam à apresentação da cozinha ;-)

Minha dica:

Antes de mais nada, acostume-se com a necessidade de dar paradinhas frequentes e refletir sobre o que foi feito. Se você ainda não faz isso é porque ainda tem muito o que melhorar em suas habilidades técnicas como programador.

A hora de "commitar" é a mesma hora de atualizar seus micro-planos (em cartões, folhas de papel, aquivos txt, mind-maps, whatever), progressos, estimativas, etc.

Além disso, quando for pensar na mensagem de commit, uma boa recomendação é adotar o estado de espírito de quem está tuitando algo, mandando um email "dipé", comunicando o status da tarefa, ou batendo um chat com uma pessoa que está não em outro lugar, mas em outro tempo. Imagine que vc está mandando um SMS para o cara que está revisando o histórico do controle de versão, procurando o ponto exato onde se fez uma determinada mudança.

Como vários outros aspectos da programação, isso é apenas uma questão de disciplina e auto-aperfeiçoamento, que obviamente depende da boa vontade e da intenção em fazer um trabalho bem feito.

Da próxima vez que for comitar código, pense nisso.

o/

Arrumando a cozinha - Parte 3/3

2011-01-24T22:20:00.000-02:00

De pouquinho em pouquinho, consegui enfim terminar de gravar a terceira e última parte da apresentação.

Essa é a parte que, tardiamente, costura as técnicas apresentadas no 1o episódio com a viagem do 2o.

Ficou com menos de 10min, caso isso ajude a te convencer ;-)

Arrumando a cozinha - Parte 3

Aqui está a primeira e a segunda parte, pra quem ainda não viu.

Já que estou chegando ao fim, cabe uma micro-retrospectiva pessoal sobre a apresentação:
- Acho que a analogia que apresentei deve estar cheia de problemas, mas acho que ela, no mínimo, esbarra de leve em algumas coisas bem fundamentais do movimento Ágil.
- Não gostei nada da apresentação que fiz pessoalmente na AgilBrazil2010 (que foi o que motivou essa gravação). Aprendi (mais uma vez) que a qualidade da apresentação, do discurso, das palavras, da postura, etc. são tão (ou mais) importantes quanto o conteúdo. Preparação prévia é fundamental para fazer uma boa apresentação!
- O 1o episódio ficou grande demais e talvez um pouco lento. Acho que aprendi a enxugar um pouco o conteúdo depois dele. Talvez eu o regrave algum dia...
- Acho que a parte 2, embora seja a que mais me interessa, ficou meio mal colocada no meio... Talvez a apresentação toda tivesse ficado mais digerível se essa parte tivesse ficado mais 'leve'...
- Alguns errinhos pequenos sobraram nas narrativas, nas passagens de slides, na codificação de video, e em outros pequenos aspectos. Mas nada que comprometa, acho eu... De qq forma, acho melhor entregar assim que ficar lapidando pro resto da vida... ;-)
- Me desculpem os que não gostaram da música (e até pediram pra tirar). Foi uma preferência pessoal que decidi manter.

De um modo ou de outro, posso dizer que o processo todo foi uma experiência muito legal. Desde a idéia inicial, passando pela estruturação das idéias até a gravação deste último episódio. Fui muito legal (mesmo que vcs não tenham gostado, hehehe).

Bom, cabe dizer por fim que se vc tiver gostado da apresentação, um comentário, crítica ou sugestão são sempre uma ótima forma de retribuir ;-)

O sorteio do iPod !!!

2010-12-01T14:21:00.002-02:00

Gostaria então de agradecer penhoradamente às 10 pessoas que se voluntariaram para experimentar o plugin Besouro e contribuir com o meu trabalho de mestrado, conforme o anúncio que publiquei a 2 semanas!

0 Eduardo Santos Marques
1 Fabricio Nogueira Buzeto
2 Ian Gallina
3 Bruno Rolim
4 Mariana Vivian Bravo
5 Daniel Cukier
6 Laécio Freitas Chaves
7 Adolfo Gustavo Serra Seca Neto
* Hugo Corbucci
8 Saulo Arruda

Vale lembrar que ainda estou aceitando doações de Katas, mesmo sem o sorteio do iPod! Se quiserem colaborar, ou souberem de alguém que ainda pode fazer isso, estou às ordens... E feliz! :-)

Estou tentando terminar um artigo para submeter à XP2011 até segunda feira, sobre esse experimento. Não vou conseguir analisar os dados de vcs até lá, mas fica o aviso aí... De qq forma, qndo tiver terminado a análise vou submeter os resultados do experimento em outras confs/journals e qndo minha dissertação for terminada aviso aqui tb...

Agora vamos ao que interessa ;-)

Conforme prometido, faremos agora o sorteio do iPod.

Vai funcionar assim:
   - Numerei os participantes aí em cima de 0 a 8 (o Hugo abriu mão do ipod, por isso ficou sem número), conforme a data de preenchimento do formulário, ao final do experimento.
   - No dia 04/dez, sábado próximo, vou pegar o número do bilhete ganhador do 1o prêmio no concurso 4507 da loteria federal.
   - Será o vencedor aquele cujo número corresponder a (número_sorteado MOD 9) :-D

É isso! A sorte está lançada! Que vença o mais sortudo :-P
Mais uma vez obrigado!

o/

Doe um Kata e ganhe um iPod!

2010-11-17T15:53:00.000-02:00

Savle!

Estou tentando terminar meu projeto de mestrado, e preciso da sua ajuda, caso vc saiba programar com TDD.

A idéia do trabalho é simples. Implementei um plugin para o Eclipse, o qual chamei de Besouro. Ele é 100% open-source e bastante útil para os pesquisadores que estudam TDD em todo o mundo. Portanto, considere que vc não está ajudando só a mim ;-)

O Besouro tenta aprimorar o sistema de regras do Zorro para avaliar automaticamente se o programador está ou não utilizando TDD. Ele observa as atividades realizadas no Eclipse e reconhece episódios que servirão para derivar uma medida quantitativa (uma porcentagem) que indica QUANTO TDD o cara usou.

Para isso, preciso que as pessoas utilizem o plugin, observem a classificação apresentada e registrem suas discordâncias com o sistema. As instruções detalhadas do experimento encontram-se AQUI.

Para motivar um pouco mais a participação (pouca gente contribuiu até agora), estou sorteando um iPod shuffle novinho em folha entre aqueles que me mandarem o kata até o dia 30 de novembro de 2010.

O limite máximo de participantes é de 20 pessoas, sendo que as pessoas que já me doaram o Kata antes desse anúncio estão automaticamente inscritas. Então, na prática, só temos mais 11 vagas!

Pense bem: a resolução do kata, contando com o tempo de leitura das instruções e instalação do plugin (que é bem fácil) não dura mais que 30min e suas chances serão de, no mínimo, 1 em 20... Se é que vão aparecer 20 pessoas :-(

Mesmo que vc já tenha um iPod, vc pode dar ele de presente pra alguém de presente ;-)

E... pense bem... O importante é dar uma força para o trabalho, dar uma olhada no plugin e programar um pouco ;-)

Obviamente, todos aqueles que participarem terão meu agradecimento público nesse blog e nos agradecimentos da minha dissertação. :-)

Vamos lá o/

ps: vou organizar o sorteio publicamente depois, provavelmente baseado na loteria federal ou algo assim...

Arrumando a cozinha - Parte 2

2010-09-13T07:59:00.000-03:00

Aqui vai a segunda parte da apresentação.

Essa é a parte 'filosófica' do conteúdo. Acho que ela ficou meio confusa quando apresentei na AgileBrazil, então mudei um pouquinho, pra passar mais superficialmente na metafísica da qualidade. Resolvi fazer outra apresentação depois, específica sobre MoQ.

Tomei cuidado também pro video ficar mais curto e dinâmico um pouco. Espero que não tenha ficado rápido demais.

( Feedback é uma ótima foma de retribuir, caso gostem ;-] )

Arrumando a cozinha - Parte 2 from Bruno Pedroso on Vimeo.

Arrumando a cozinha - Parte 1

2010-07-27T08:13:00.002-03:00

Resolvi enfim gravar a primeira parte da palestra que eu fiz na AgileBrazil.

Alguns links que comento durante o vídeo:

Os slides: http://tinyurl.com/aCozinha

Manifesto 2.0

meu post sobre o trabalho no mundo 2.0

o livro do DavidAllen sobre GTD (em pt): link1, link2

O disco que usei como trilha sonora

Espero que vcs gostem.
Por favor, dêem feedback, pros próximos episódios sairem melhores um pouco ;-)

\o

Test-fisrst teaching

2010-07-11T10:30:00.002-03:00

Gostei muito muito dessa apresentação:

Sarah Allen explica com muita clareza (inclusive no inglês) uma metodologia para ensinar programação por meio de test-first.

Minha experiência nos dojos e ensinando calouros a programar sempre me disseram que não seria tão fácil fazer o que o Vinícius Teles sugere em seu apelo. Na metodologia apresentada no vídeo, acho que ela esclarece bem o ponto (é muito difícil aprender a programar e a escrever testes ao mesmo tempo) e dá uma saída genial!

De quebra, ela explica muito bem a questão geral em torno dos benefícios de TDD. Concordo muito com ela!

A apresentação toda dura quase uma hora, mas recomendo.
Vale muito a pena!

Arrumando a cozinha

2010-06-21T14:26:00.006-03:00

GTD, Scrum, Pomodoro, TDD

Esse é o título da palestra que apresentarei na AgileBrazil 2010, na quinta feira (dia 24/06) às 18:15.

Se vc está planejando assistir (ou se não está), eis aqui um resumo bem rápido pra situar melhor as coisas:

A motivação principal para essa reunião de técnicas foi explicada em outro post desse blog, que o convido a ler, caso ainda não o tenha feito. É um post relativamente longo e não é obrigatório, de forma alguma. Mas creio que seja bastante pertinente, já que estabelece o contexto inicial dessa apresentação.

A idéia é apresentar essas 4 técnicas de um ponto de vista bem particular. Vou ressaltar alguns aspectos-chave que me permitam relaciona-las e extrair alguns princípios em comum.

Posso adiantar que o principal valor que pretendo ressaltar em todas elas tem relação profunda com a filosofia de Robert Pirsig - a Metafísica da Qualidade - a qual pretendo abordar de forma suficientemente leve e divertida.

Esse é um conteúdo que venho amadurecendo no último ano, e acho que consegui chegar num resultado muito bom. Estou orgulhoso!

Espero que gostem :-)

DojoSpot: um OpenSpace para a AgileBrazil 2010

2010-06-21T12:38:00.004-03:00

Durante a AgileBrazil 2010, espero conseguir discutir com algumas pessoas uma pequena empreitada que me deu na cabeça de colocar em prática esse ano. Se tudo der certo, espero conseguir organizar uma breve reunião, provavelmente em formato de um pequeno WorldCafé, para discutir os objetivos, a pertinência, a relevância, prós e contras desse pequeno projeto:

DojoSpot

Host your own CodingDojo!

O projeto nasceu do site que criamos para o DojoSEA, e acaba de ser colocado no GitHub. Foi criada também uma lista de emails, da qual vc já pode participar, se estiver interessado em ajudar a organizar o OpenSpace :-)

A idéia desse projeto é desenvolver uma pequena e simples aplicação web, que seja fácil de instalar e usar e que dê um suporte mínimo para colocar funcionando um site para o seu CodingDojo. (É claro que é preciso um pouco mais que um site para se estabelecer um Dojo, e é claro que é possível fazê-lo sem um site. É apenas um ponto de partida, para incentivar aqueles que se interessarem.)

A aplicação ainda não faz muita coisa (quase nada), mas espera-se que ela possa ajudar das seguintes formas:
- estimulando e fomentando a integração e o fortalecimento da comunidade;
- propondo um dispositivo de reconhecimento entre os participantes;
- valorizando as indivualidades de cada grupo de Dojo;
- criando um espaço para discussão e reflexão;

Espero vocês na AgileBrazil! :-)

Porque o Twitter é genial?

2010-05-13T19:27:00.006-03:00

Estava eu saindo pra capoeira encafifado com uma questão do mestrado. Antes de sair, resolvi desabafar a dúvida, rogando a dúvida pra quem a merecia, via Twitter:

12:01: brunopedroso: @KentBeck , do u think it is possible to grow a quick-sort from TDD?

12:12: KentBeck: .@brunopedroso i think you could tdd quicksort. you'd need assertions about the # of comparisons & ways to incrementally improve the count

12:20: the_chrismo: @KentBeck with the karate chop kata (http://bit.ly/aPh2y6) I started to expose comparisons, but felt it revealed internals too much ...

12:23: the_chrismo: @KentBeck ... though without doing those, there's no direct assertion of the efficiency of the algorithm.

12:29: KentBeck: .@the_chrismo i think you'd have to introduce a Comparator & be able to plug in one that keeps a count.

13:55: the_chrismo: @KentBeck ah, nice. makes me want to go back and try that.

12:25: brandheintz: .@KentBeck I'd be interested to see that - would be a crack in the "TDD can't guarantee good algorithms" argument.

12:30 KentBeck :.@bradheintz only people can guarantee good algorithms. tdd can certainly be used to assure that they are used, tho.

13:52: brandheintz: .@KentBeck True, but yr notion of pushing toward better algos through smart use of constraints has appeal.

12:18: davenicolette: @KentBeck @brunopedroso That sounds like it could be a good kata.

12:37: asplake: .@KentBeck @bradheintz TDD for algorithm design seems to verge onto "halting problem" territory

12:38 : KentBeck: .@asplake i don't see why. you need an n log n algorithm. give it n inputs. count the operations. assert that < n log n of them took place.

12:40: asplake: .@KentBeck right. And prove that there are no pathological cases?

12:46 : KentBeck.@asplake that's out of scope for tdd. once you find one, you can write a test to demonstrate it.

14:09: the_real_pablosan: @brunopedroso I have tried growing a binary search from TDD: http://salientblue.com/codenotes/index.html?name=kata2Java01

O que tem de fantástico nisso?

A parte do conteúdo da conversa, que pra mim foi um prato cheio, perceba o que o twitter tornou possível: Primeiro de tudo: *o cara* me respondeu!!!! :-) Segundo: outras cinco pessoas se envolveram na conversa e fizeram indicações e comentários interessantíssimos algumas das quais eu nunca tinha ouvido falar (até agora, pois agora eu sigo os 4...)

Em que outro meio de comunicação essas 7 pessoas conseguiriam se encontrar para fazer comentários sobre uma questão tão específica?!

Internet? Não, não foi a internet, apenas... foi o Twitter!

A internet já estava aí há muitos anos (antes do twitter aparecer) e isso ainda não era possível... Nunca teríamos conseguido ter essa conversa por email, nem por chat, nem por nada! Tanto é que não as tínhamos!

7 pessoas, em 7 lugares diferentes do mundo tiveram uma conversa profunda a respeito de um assunto muito específico que os interessa. E o que é mais incrível: em questão de minutos! É quase tão rápido quanto se os 7 tivessem se esbarrado numa sala de conferência entre duas palestras e ficássem jogando conversa fora por 20 minutos! Só que estávamos cada um em sua casa ou em seu escritório.

(Ah, ganhei mais 5 seguidores e passei a seguir + 4)

Sinistro!

Pesquisa sobre TDD

2010-05-02T10:11:00.005-03:00

Estou bastante envolvido com a pesquisa para minha dissertação de mestrado, que pretendo desenvolver até o fim do ano, se Deus quiser.

Nas útimas semanas tenho passado por uma turbulência forte, mas de um jeito ou de outro vamos chegar no final :-)

A boa nova é que começamos a cooperar mais de perto eu, a Cláudia e o Maurício. Estamos tendo boas disscussões. Espero que saia alguma coisa boa daí!

Pra quem esta interessado em ler um pouco a respeito, eu havia publicado aqui algumas referências no começo da pesquisa, ano passado. Prometo atualizar essa lista em breve!

O mauricio tb compartilhou algumas referências e um paper que ele apresentou no 1st International Workshop on Test-Driven Development (TDD2010). (Parabéns Mauricio \o/).

Outra referência legal é a edição especial que o IEEE lançou em 2007 sobre TDD. (Siga os links '2007 vol.24' e depois 'Issue No. 3 - May/June', não consegui achar um link direto :-/), sobre a qual a InfoQ publicou uma entrevista muito boa com o Erdogmus.

Eu publiquei uma besterinha na XP2010 sobre minha opinião quanto aos estudos que pesquisei (uhuuuu!) Assim que tiver um link eu posto aqui. Pretendo disponibilizar outros textos que escrevi até agora. Vou me organizar e coloco os links por aqui em breve.

Seria legal fortalecermos e unirmos mais os grupos de pesquisa em TDD no Brasil. Se vc tb está nessa (ou se pretende entrar) deixe um comentário ou entre em contato de qq outra forma e vamos unir as forças! Ou pelo menos trocar algumas figurinhas ;-)

o/

Learn some Javascript!

2010-03-05T21:42:00.000-03:00

Fiquei impressionado com a qualidade da revista PragPub.

Em especial, adorei o artigo sobre javascript que aponta na direção de mais uma bela reviravolta no mundo das tecnologias de desenvolvimento para web.

Quem diria? A linguagem de programação que há aguns anos nem era considerada uma linguagem de programação de verdade por muitos, agora começa a mostrar sinais de que vai entrar pra briga do lado do servidor, enfrentando Java, C#, Ruby, Python, PHP, etc. E parece que já vai entrar na vantagem!

Sendo a linguagem padrão no lado dos navegadores, e relativamente bem conhecida pelas tribos de todas as outras tecnologias, acho bem provável que se torne o esperanto das linguagens de programação, pelo menos dentro do contexto da web (que parece estar mesmo engolindo tudo, então dá na mesma...)

E mais: estando a comunidade e todo o eco-sistema de frameworks nascendo agora, durante a hype da programação distribuida de alta performance - Erlang, Scala, Clojure e afins - parece que o pensamento funcional e distribuído, a lá Google e seu MapReduce, já está nascendo nas entranhas dos novos projetos que surgem. (O que é também bastante sincronizado com as reformulações nos paradigmas de dados, noSQL's, e afins).

Com toda a hype do Ajax, Prototype (e agora JQuery), Scriptaculous, e framework de interface rica praticamente WYSIWYG (programadores Delphy adoraram!), e depois que linguagens dinâmicas como Ruby e Python mostraram que a tipagem estática e a velocidade do código compilado não são assim tãããããão importantes, parece que o Javascript vem ganhando ainda mais popularidade.

De minha parte, fico satisfeito em saber que os novos frameworks já estão nascendo também com seu legado metodológico ágil, como uma infra-estrutura decente para TDD/BDD, e espero que herdem muito do modelo de programação ágil embutido no framework, a exemplo de Rails e cia.

Para arrematar, deixo o comentário de que gostei muito também, no tal artigo (e ao que parece em toda a revista), da relevância dada aos aspectos sociais e culturais inerentes à tecnologia. Dêem uma olhada na revista, acho que vão gostar também!

Quem pode te interromper?

2009-11-02T17:09:00.000-02:00

Remédio ou veneno? A diferença está na dose. Eis aqui uma breve reflexão sobre como a tecnologia pode acabar com a sua produtividade.

Não sei você, mas eu sempre tive dificuldade em me concentrar em algumas coisas. Leitura é uma delas. Se alguém passa na rua conversando sobre qualquer coisa que dê pra escutar, lá se vai minha leitura. Por isso eu só leio com fone de ouvido. De preferência ouvindo músicas conhecidas e instrumentais, que não vão surpreender minha mente e tirar minha atenção do texto.

Outras pessoas, como meu irmão, afundam a cara no que quer que estejam lendo e entram numa espécie de transe do qual só saem no terceiro grito, depois de já termos esperneado bastante em sua frente.

Alguns tipos de trabalho exigem um tempo relativamente longo de concentração, para que se possa enxergar toda uma linha de raciocínio até que se alcance os pontos de decisão realmente importantes.

Acontece que ultimamente tem se tornado cada vez mais difícil se concentrar no que quer que seja. Celular, SMS, Messenger, Twitter, Email. São todas ferramentas maravilhosas de comunicação, mas que podem acabar com a produtividade de qualquer um.

O celular é ótimo pra ilustrar isso. Seu celular tem autorização pra te interromper quando... você está lendo? quando está escrevendo? quando vc está no cinema? Quando está em reunião? Quando está no banheiro?! Tem gente que sai correndo, todo borrado, pra atender o celular a tempo...

Somos nós quem determinamos quando e como os meios de comunicação podem nos interromper. Pare pra pensar! A decisão está nas pequenas coisas. Quando seu celular vai pro "silencioso"? Quem tem seu telefone de casa? Vc deixa seu email sempre aberto na janela de trás? Twitter? Messenger?

Em tempos de escassa atenção, saber usar os meios de comunicação pode ser tão importante quanto saber gastar ou aplicar seu dinheiro.

O Trabalho no mundo 2.0

2009-10-25T08:58:00.000-02:00

Nessa virada de século, o Trabalho (com T maiúsculo) passa por um processo de reformulação comparável ao que aconteceu na revolução industrial. A demanda por trabalhos criativos e a situação global como um todo mostram a necessidade de reformular os antigos processos e métodos à luz de mudanças importantíssimas que vêm ocorrendo em nossa sociedade, em especial o surgimento da Internet e todas suas consequências. O desenvolvimento de software e a cultura hacker possuem papel fundamental nessa mudança, assim como o próprio uso de computadores e programas pela sociedade. Fazem surgir - dentre outras coisas - novas técnicas, métodos, metodologias e processos de trabalho mais afins com a natureza do que estamos realizando (a sociedade como um todo), as quais cito nesse texto, por enquanto, apenas como fonte de pesquisa, motivação e conselho.

Já faz algum tempo que me interesso por metodologias, processos e coisas assim. Não é a toa que são as palavras no cartão de visitas do blog.

Nos últimos meses, tenho percebido varias coisas novas surgindo e se encaixando à minha frente. Já percebo sua correlação não é de hoje - venho filosofando isso com o Alê e com o Willi desde as primeiras conversas que culminaram no manifesto 2.0 - mas até alguns dias atrás essas coisas ainda não tinham se encaixado como um todo em minha cabeça.

Dentre os últimos arrebatamentos que ajudaram a unir as pontas, pra mim, está sem dúvida esse filme do TED, em que Dan Pink ajuda a distinguir claramente dois tipos de trabalhos (repetitivo e criativo), e de que forma isso influencia nas relações de trabalho.

A palestra do Akita na RailsSummit também se encaixou como uma luva nisso tudo. Mas foi a palestra do Roy Singham no Ágiles2009 quem realmente montou o cubo mágico que venho mastigando por pelo menos dois anos.

Talvez o ponto chave pra mim tenha sido me tocar da amplitude da influencia que o modelo de trabalho sequencial, "industrial", teve sobre a maioria dos processos e atividades realizadas durante o século XX. Já usei bastante em minhas apresentações e textos a imagem de processos sequenciais e a herança que esse modelo teve na indústria de software, mas nunca tinha me tocado do quanto essa influência foi além do nosso mundinho geek.

O modelo de fábrica

O modelo de trabalho industrial influenciou de forma muito marcante praticamente todas as formas de trabalho no último século. Basta pensar na forma como estão estruturados até os processos mais "humanos" de nossa sociedade: educação, alimentação, comunicação, saúde. Pense nos processos administrativos e burocráticos... Todos eles são estruturados em formas de trabalho muito semelhantes às das indústrias têxtil e automobilística. Quanta informação uma atendente precisa dar à outra para que ela continue o trabalho de montar o seu sanduiche?

O modelo de trabalho de fábrica é caracterizado por sua natureza sequencial, composta por especialistas que se comunicam por meio de interfaces estreitas, rígidas, e bem definidas. Os trabalhos realizados por eles, sobrepostos, resultam no produto final. É o que, em computação, chamamos de pipeline.

Esses processos primam pela repetição, monitoramento e visibilidade como ferramentas de controle do tempo, dos custos e do escopo do trabalho. Valorizam a rastreabilidade e o comprometimento de culpados, baseados em métricas objetivas, punições e recompensas. São muito eficazes para trabalhos repetitivos e mecânicos, razão pela qual mudaram a vida humana no último século.

Acontece que os avanços tecnológicos das últimas décadas vêm transformando o trabalho novamente. Seres humanos são cada vez menos necessários para realizar as tarefas repetitivas, e os trabalhos criativos têm se tornado cada vez mais importantes. Nesse novo mundo as velhas formas de trabalho não funcionam muito bem. Pipelines são péssimos para trabalhos criativos e colaborativos, assim como políticas de recompensa e punição, horário controlado, comando e controle, etc.

Nesse cenário, novos processos e métodos estão surgindo que se adequam muito melhor à natureza do trabalho criativo, que ao que tudo indica será uma das faces do século que inauguramos. O Alê chamou essas formas de "2.0". Eu uso também termos como "a nova forma", mas é preciso alertar que não pretendo com isso criar julgamento de valor (embora seja quase impossível não fazê-lo). Nenhuma das duas formas - a velha e a nova - é "melhor" ou "pior" em qualquer aspecto (a menos que queiramos ir mais fundo na discussão). Elas representam papéis diferentes em contextos diferentes.

Um novo modelo

Vejo essas novas formas surgirem com bastante evidência na área do desenvolvimento de software. Muitas delas têm suas origens nas comunidades hackers, que encontraram (criaram) enfim o ambiente necessário para restaurar a ligação entre trabalho e diversão que se perdeu com a ética protestante.

Os hackers despertaram da dormência as sementes da colaboração ao criar os mecanismos práticos que os permitiram botar pra funcionar talvez a mais magnífica criação humana desde sei lá quando: a Internet. Sem falar na infinidade de projetos open-source que existem hoje e sua importância no equilíbrio desse ecossistema.

Com o domínio dos meios de comunicação - e com o poder de recriá-los e transformá-los conforme sua necessidade - os hackers fizeram necessárias revisões de conceitos fundamentais, como os de nacionalidade e propriedade (començando pela intelectual). Sua organização meritocrática e suas motivações lúdicas - ao invés de financeiras - inauguraram (ou pelo menos recuperaram) uma ética que está mudando definitivamente as relações humanas.

Não é por acaso que a sociedade vem passando por outros processos de amadurecimento e conscientização, ligados direta ou indiretamente ao fenômeno da Internet. Ousaria relacionar essa salada toda à questão do "desenvolvimento sustentável", mesmo sabendo que terei que passar por pelo menos dois debates ferrenhos: com meu irmão e com o Sérgio. ;-)

Essa mudança de pensamento, ao que parece, está influenciando cada vez mais outras formas de trabalho e criação humana. Eu mesmo - pra não ir muito longe - já participei de dois trabalhos comunitários de tradução incríveis, especialmente se levarmos em conta que foram realizados por pessoas que nem ao menos se conheciam. Livros e discos não são mais vendidos em lojas, nem distribuídos por editoras e gravadoras. Em muitos casos, mal se sabe quem foram os autores. Imagine o que essa revolução fará (está fazendo) pelo design ou no campo da pesquisa científica.

Não estou obviamente reivinidicando nenhuma superioridade intelectual por parte dos programadores ou coisa assim. Esse pioneirismo não se trata de nenhum privilégio que a área da computação tenha, exceto pelo fato de termos tido a sorte de sermos os que mais estamos confortáveis com os novos canais de comunicação.

Também não estou dizendo que as técnicas citadas abaixo tiveram sua origem nas comunidades hackers. Apenas que foram influenciadas de uma forma ou de outra por essa cultura, e pelas formas de colaboração que dela derivaram.

É como se fossemos os matemáticos e "engenheiros mecânicos" da revolução industrial. (Qual terá sido o canal de comunicação que a indústria passou a dominar com sua revolução?) Com a diferença que os meios e conhecimentos necessários para produzir software hoje são públicos, estão disponíveis a qualquer criança curiosa - à distância de alguns cliques - e se transportam para nossa casa praticamente de graça, como num passe de mágica, com um simples download.

Novas técnicas e ferramentas

Nesse novo modelo de trabalho, algumas técnicas, métodos e processos estão aflorando e ganhando popularidade de forma muito rápida. Essas pequenas ferramentas empíricas retiram o foco de preocupação no trabalho que está sendo realizado e o colocam nas pessoas que o realizam.

Não foram novas máquinas, com tecnologia mais avançada que destacaram os japoneses na indústria automobilística nas últimas décadas. (Aqui está um caso clássico em que o método surgiu na indústria, e só depois foram adaptadas ao desenvolvimento de sistemas.)

As armas fundamentais que destacam as empresas de hoje ao meu ver (especialmente as de software) tratam-se de evoluções metodológicas - não tecnológicas. Processos sociais de organização de tarefas, estruturação mental e social, tratamento de fluxos contínuos de demanda e feedback, manutenção de atenção e estado mental criativo, auto organização de equipes. Essa é a natureza das grandes inovações do trabalho na era da informação. (Acho que não precisa nem comentar sobre a relação disso tudo com o manifesto ágil.)

Fiz aqui uma pequena lista de algumas técnicas e métodos que tenho aprendido (e tentado usar). Vou apenas citá-los, deixando o desenvolvimento dos temas específicos para outros artigos. Já entrou em meu GTD também a criação de uma palestra relacionando esses assuntos e criando o contexto para motivar o interesse nessas coisas. Ela deve aparecer em algumas submissões de trabalhos em eventos sobre agilidade nos próximos meses ;-)

Uma forma breve de descrever um possível objetivo em comum entre elas poderia ser o de organizar o fluxo de demandas e o foco de atenção de pessoas e equipes, tornando o trabalho efetivo por meio do equilíbrio entre planejamento, feedback e adaptação.

Vamos à minha lista:

Scrum

Não precisamos nem falar sobre Scrum, pois está bastante na moda. Embora eu não me dê muito bem com a popularidade repentina que ganhou, nem com as razões que a motivaram, cito ele aqui no lugar do XP por ser especificamente focado no processo organizacional da equipe e no planejamento e acompanhamento de atividades - tema que pretendo relacionar com outras técnicas que serão citadas em seguida. XP trata de outras questões além dessa (pra mim Scrum está contido em XP), então uso o nome Scrum pois acho útil poder me referir apenas a "essa parte específica" do XP.

TDD

Embora não tenha incluído o XP na lista, incluo aqui outra parte dele: o desenvolvimento orientado a testes (e seus desdobramentos). Trata-se de meu principal interesse profissional atualmente, que tomei para objeto de pesquisa em meu mestrado, e que incluo nessa lista por seu aspecto de organização de tarefas e focos de atenção mental, bem relevante à linha de raciocínio que ressaltei aqui.

O desenvolvimento orientado a testes leva a designs mais simples não por qualquer passe de mágica presente na técnica, mas pela organização das atividades e do foco de atenção dos programadores, e pela manutenção da confiança e coragem em mudar o design - todos fatores humanos!

GTD

Esse é o processo de organização pessoal que venho usando desde o início desse ano, e que tem sido pra mim - além de fonte de muita reflexão - motivo de grandes realizações pessoais, tranquilidade, motivação e alegria. Foi ele também o fio condutor principal que começou a costurar essas relações todas em minha cabeça.

É a técnica que organiza o fluxo constante de compromissos e responsabilidades pessoais que nos assola dia a dia. Sem um processo coerente de organização, essa enxurrada de pequenos problemas para resolver afoga a maioria das pessoas que, sem paz de espírito, não conseguem se concentrar no que fazem, perdendo tempo com coisas irrelevantes e deixando de lado as coisas importantes.

O GTD é um método indispensável para empreender, no sentido 2.0.

Pomodoro

Dessa lista essa é a técnica que conheço a menos tempo (umas duas semanas), e talvez a que começou a me ajudar mais cedo. (Basta mencionar que sem ela esse artigo não saía.)

Ouvi falar dela pela primeira vez no Ágiles2009 codificando junto com o BrianMarick.

Mal comecei a ler o livro e já estou viciado em contar tomates ;-) Trata-se da técnica com foco mais pontual, localizado e imediato de todas, que pelo menos pra mim representa o elo que faltava para relacionar GTD, TDD e Scrum de uma forma incrível. A técnica cria uma metáfora clara para a unidade de trabalho (e de estimativa) de forma lúdica e confortável, complementando as demais.

OpenSpaces, BirdsOfAFether, e WorldCafé

Esses são processos cuja finalidade não parece corresponder diretamente àquela dos supracitados, pelo menos à primeira vista, pois são métodos de organização de encontros e reuniões, ao invés de projetos - possuem uma natureza muito semelhante no que diz respeito aos princípios e soluções propostas.

Participei pela primeira vez de seções de OpenSpaces no encontro ágil do ano passado. O WorldCafé me foi apresentado pelo meu irmão antropólogo e tive o prazer de facilitar algumas reuniões assim no planejamento estratégico da SEA.

Coding Dojo

Esse talvez seja o mais estranho item dessa lista, mas garanto (e pretendo mostrar) que possui relações íntimas com várias das outras técnicas/métodos. Essa me interessa ainda mais profundamente por me permitir experimentar com algo que me é de grande interesse - o TDD - além de propiciar grande diversão, aprendizado e fortalecer laços de amizade.

Essa lista não pretende ser exaustiva sob nenhum aspecto. Pretende apenas ilustrar o ponto de vista e apresentar as ferramentas que estão se juntando na MINHA caixa. Servirá muito mais para polarizar a discussão e talvez fazer surgirem outras coisas que podem (e talvez devam) fazer parte dessa coleção.

O que mais me fascina nisso tudo é a relação que percebo entre os princípios que estão por trás dessas técnicas. Pelo menos pra mim, parecem ter emergido todas mais ou menos juntas. Foram todas descobertas empiricamente, longe das grandes empresas e centros de pesquisa.

Pretendo escrever sobre essas relações. Já tenho várias anotações sobre isso. Mas o objetivo desse post, que acho que já foi cumprido, era apenas o de compartihar essa visão geral, para poder me preocupar mais com os detalhes nos próximos posts.

Teste e design

2009-08-26T20:17:00.000-03:00

Muita gente que conheço estranharia demais o fato de um artigo como esse estar em um blog sobre testes:

GoogleTestingBlog: How to think about OO

Ouço pessoas falando em reuso, em SOA, em arquitetura, bla bla bla..., sem nunca ter nem mesmo se interessado por coisas como essa.

Se você ainda não sabia, fique sabendo: testes tem tudo a ver com design.

Esse casamento é uma das coisas mais importantes que a indústria de software desenvolveu na última década, e a maioria das pessoas ainda está em discussões como "PHP é ruim, Java é que bom!"

O fato é que discussões riquíssimas, como a apresentada nesse artigo, praticamente não têm nenhum valor se você não escreveu testes automáticos desde o início do seu projeto. Não adianta nada você saber reconhecer um design ruim e conseguir propor outro melhor, se na hora H você não tiver coragem de fazer a mudança, com medo do impacto que isso vai ter.

Acredite. Praticamente 100% dos gatos que existem em todos os códigos do mundo são fruto de atitudes medrosas, fracassadas, do tipo "não véi! vamo mexer nessa parada não... Vamo dexá assim mesmo, senão a gente vai ter que mudar um monte de coisas..."

Então se você ainda estava parolando por aí e não tinha visto o bonde passar, acorde! Não dá pra fazer software de forma séria sem automatizar testes. Não dá! Só você (e os que trabalham com você) ainda não percebeu.

Deixa de ser cabeça dura e presta atenção no que está acontecendo!

O design está morto?

2009-07-26T12:04:00.000-03:00

Outro dia um amigo cobrou o final da tradução que eu vinha fazendo do artigo do MartinFowler.

Não vamos mais precisar esperar, o pessoal da InfoQ.br se organizou mais rapido e traduziu o artigo todo.

Não deixem de ler!

Apresentação sobre Agile na Câmara dos deputados

2009-06-02T15:40:00.000-03:00

Faz tempo que não reservo um tempinho pra escrever por aqui. Estou cheio de assuntos engatilhados, mas tenho andado meio comprometido demais com coisa demais... :-P

Assim que der eu volto a escrever com mais regularidade.

Por enquanto, aproveito pra deixar publicada aqui essa filmagem que o pessoal fez da palestra que apresentei na Câmara semana passada. Aproveito pra agradecer a gentileza do pessoal ter filmado e me passado.

Patterns e XP

2009-03-08T22:42:00.000-03:00

Ainda traduzindo...

O exemplo do JUnit me leva inevitavelmente a trazer à tona os patterns. A relação entre patterns e XP é interessante, e é uma questão comum. Joshua Kerievky argumenta que patterns são pouco enfatizados em XP e ele coloca seu argumento eloquentemente, de modo que não preciso repeti-lo. Mas vale notar que para algumas pessoas patterns parecem ser conflituosos com XP.

A essência desse argumento é que patterns são frequentemente usado em excesso. O mundo está cheio de programadores legendários, frescos de sua primeira leitura do GOF que aplicam dezesseis patterns em 32 linhas de código. Me lembro uma tarde, movido por uma deliciosa puro-malte, planejando com Kent um artigo a se chamar "Not Design Patterns: 23 truques baratos". Estávamos imaginando coisas como usar um IF ao invés de uma estratégia. A piada tinha um fundo de verdade, patterns são frequentemente usados em excesso, mas isso não faz deles uma má idéia. A questão é como você os usa.

Uma teoria sobre isso é que as forças do design simples o levarão aos patterns. Muitos refactorings fazem isso explicitamente, mas mesmo sem eles, seguindo a regra do design simples, você chegará aos patterns mesmo que você ainda não os conheça. Isso pode ser verdade, mas será que essa é realmente a melhor forma de fazer isso? É claro que é melhor se você já souber de antemão aonde está indo e se tiver um livro que possa te ajudar com as dificuldades, ao invés de ter que inventar isso tudo por conta própria. Eu certamente ainda vou ao GOF sempre que percebo um pattern surgindo. Para mim o design efetivo implica que precisamos saber o preço que vale a pena pagar por um pattern - isso é sua própria habilidade. Similarmente, como Joshua sugere, precisamos estar mais familiarizados sobre como derivar um pattern gradativamente. A esse respeito XP trata o modo como usamos patterns de modo diferente do usual, mas certamente não remove seu valor.

Mas lendo algumas das listas de e-mail eu tenho o sentimento distinto de que muitas pessoas acham que XP desencoraja patterns, apesar da ironia que a maioria dos proponentes de XP foram lideres do movimento de patterns também. Isso é porque eles viram além dos patterns, ou porque os patterns estão tão impregnados em seus pensamentos que eles nem percebem mais? Eu não sei a resposta para os outros, mas pra mim patterns ainda são vitalmente importantes. XP pode ser um processo para desenvolvimento, mas patterns são a espinha dorsal do conhecimento sobre design, conhecimeno que é valioso tanto quanto o processo. Processos diferentes podem usar os patterns de modos diferentes. XP enfatiza tanto a não utilização de patterns até que eles sejam necessários como evoluir o código do seu modo derivando um pattern por meio de uma implementação simples. Mas patterns são ainda uma peça chave de conhecimento a se adquirir.

Meu conselho aos XPeiros usando patterns seriam:

* Invistam tempo aprendendo sobre patterns
* Concentrem-se em quando aplicar o pattern (não tão cedo)
* Concentrem-se em como implementar o patterns em sua forma mais simples primeiro, então adicione complexidade depois.
* Se você utilizar um pattern, e depois descobrir que não valeu a pena - não tenha medo de tirar ele fora de novo.

Eu acho que XP deveria enfatizar mais o aprendizado sobre patters. Não sei ao certo como encaixaria isso nas práticas de XP, mas tenho certeza de que o Kent pode descobrir um jeito.

Maré de Agilidade - Swell Salvador

2009-02-16T13:52:00.000-03:00

Opa,

Só pra avisar que vamos fazer o MaréDeAgilidade versão Salvador-BA.

Ô meu rei, num deixe de participar! :-)

Visão de futuro

2009-02-15T08:48:00.000-03:00

Incrível como a visão que tinham da internet em 1969 estava correta:

Me faz lembrar o primeiro MSX que tive... humm.. nem lembro quando... Devia ser 90, 91...

Me lembro exatamente a expectativa em que fiquei quando minha vó comprou pra mim um modem!

Qual não foi minha frustração quando descobri que só existiam 2 ou 3 serviços disponíveis que pudessem fazer uso do tijolo - que não tinha sido nada barato. Os serviços não eram ainda ligados em rede, a gente tinha que discar diretamente para o número do Bradesco, por exemplo.

E o diabo é que nenhum dos serviços eram úteis pra mim! :-P

Pra mim a internet já existia naquela época. Quando saí da loja com o modem debaixo do braço, tinha certeza abstoluta de que iria chegar em casa e visitar museus pelo computador, comprar vídeos, conhecer pessoas, criar coisas.

Embora a imagem que façamos do futuro não seja exata nos detalhes, simbolicamente parece que já sabemos pra que lado as coisas estão se encaminhando.

Que diabos é GTD?

2009-02-08T15:02:00.000-02:00

Esse vídeo vale a pena ver... Seria ótimo se houvesse uma versão legendada por aí, embora o inglês dele seja bem fácil de entender...

O Video é longo, se tiver sem paciência, dê uma olhada nesse post, que traz uma "resenha" do video.

Refactoring viola YAGNI?

2009-02-08T14:41:00.000-02:00

Continuando a tradução do MartinFowler...

Esse tópico surgiu na lista de XP recentemente, e é importante discuti-lo já que estamos revendo o papel do design em XP.

Basicamente, a questão começa com o ponto que refactoring toma tempo mas não adiciona funcionalidade. Uma vez que o ponto em YAGNI é que deveria-se projetar para o presente, não para o futuro, isso é uma violação?

O ponto em YAGNI é que você não adiciona complexidade que não é necessária para as histórias atuais. Isso faz parte da prática do design simples. Refactoring é necessário para manter o design o mais simples possível, então você deve refatorar sempre que perceber que pode tornar as coisas mais simples.

Design simples tanto explora as práticas de XP como é também uma prática habilitadora. Apenas se você tiver teste, integração contínua e refactoring, é possível praticar design simples efetivamente. Mas, ao mesmo tempo, manter o design simples é essencial para manter a curva de mudanças estável. Qualquer complexidade desnecessária torna o sistema mais difícil de mudar em todas as direções, exceto naquela em que você antecipou com a flexibilidade complexa que colocou. No entanto, as pessoas não são boas em antecipar, então é melhor esforçar-se pela simplicidade. Mas não se consegue a coisa mais simples de primeira, então você precisa refatorar para chegar mais perto do objetivo.

GTD.reset()

2009-02-06T11:31:00.000-02:00

O final de 2008 (e o começo de 2009) estão sendo especiais pra mim. Cheguei no final do ano voltando de férias (viajei em novembro). Apesar de ter estado "aéreo" por um mês, quando voltei foi como se não tivesse ido. Todos os problemas vieram à tona novamente, e voltava aquele sentimento de sobrecarga, muitas coisas pra resolver, e tal. Estava eu novamente me segurando pra não explodir com o primeiro que chegasse com mais qualquer coisa pra resolver.

Poucos dias antes do natal, recebo a notícia de que as inscrições no mestrado da UnB terminariam no dia 06 de fevereiro (hoje). Naquele momento a noticia me caiu como uma bomba. Apesar das férias, meu cansaço intelectual era tanto que não cogitava nem de longe que fosse possível eu me inscrever a tempo. Pra se inscrever no mestrado a gente precisa ter um plano de pesquisa. (Já parou pra pensar o que é isso?) e pra isso, precisa de... ... ... um plano! Meu Deus!

Pra ter um plano, preciso ter um objetivo claro, preciso ter uma boa idéia do que a ciência anda pensando a respeito (ler muito), e... caramba! Nem sequer um tema eu tinha! :-o 1 mes de prazo, um saco (bem) cheio, e não mais que alguns interesses na manga... :-(

Foi aí que "sem mais nem menos" me volta à memória o GTD.

Durante todo o ano de 2008, eu fiquei.. hum... "brincando" de GTD - havia passado o olho no livro, achado o maior barato, mas não tinha lido de verdade, e achava que tinha entendido tudo só olhando as figuras. Té parece :-/

Mas então resolvi parar e ler o diabo do livro. Minha estratégia inicial era ler o livro todo, de cabo a rabo (como não costumo fazer) e entender o todo. Depois via como fazia.

Antes da metade eu não pude mais me conter, joguei o livro de lado e comecei a coletar minhas coisas.

O resto da história eu conto com calma, em outros posts.

O importante é que estou comemorando hoje não a inscrição no mestrado (pois o resultado sai só na semana que vem), mas o cumprimento de uma meta que pelo menos pra mim foi maravilhosa. Um mês depois, estou me sentido leve como poucas vezes na vida. Meus compromissos estão todos (absolutamente todos) sob controle e meus fins de semana estão sendo tão profundos que é como se estivesse de férias.

A Guerra Ágil (ou "Outras Verdades Inconvenientes")

2008-12-07T15:28:00.000-02:00

Até que ponto os debates e críticas dentro da própria comunidade ágil devem ser encarados como picuinhas e sopas de letrinhas, e a partir de onde se tornam pertinentes e transformadores? Que questões estão envolvidas? Quem vence, quem perde?

Nas últimas semanas temos assistido a uma verdadeira guerra de palavras, confrontando as metodologias que normalmente se associam ao movimento Agile, como um todo. Resolvi analisar as principais críticas e discursos que se observa pela comunidade a esse respeito (me posicionando) e argumentar, principalmente, a favor da preservação do debate (que não precisa ser uma "guerra") como instrumento de reflexão construtiva e aprendizado coletivo da nossa comunidade.

Passei o último mês de férias, por isso não tenho escrito muito. Apesar disso, estive acompanhando toda movimentação na comunidade e até participei de uma ótima discussão em uma lista de email (embora alguns colegas da lista pareçam não ter gostado muito).

O que me pareceu mais relevante, durante esses dias, foi um foco no que vou passar a chamar "a guerra ágil". Talvez o ponto mais alto das últimas batalhas tenha sido o post do James Shore, e toda a repercussão que isso teve (pelo menos na blogosfera brasileira). Só pra não deixar de me posicionar sobre esse episódio, achei o post fantástico! Gostei especialmente porque noto muita relação com o que escrevi sobre Scrum e XP. Diferentemente do que algumas pessoas interpretaram, acho que a crítica dele está bem mais relacionada ao modelo de negócios por traz do Scrum, do que ao método em si.

Afinal de contas, de quem é a responsabilidade, pelos efeitos colaterais da estratégia de marketing por traz do Scrum? Ouvi a pouco tempo uma das pessoas mais envolvidas com Scrum no Brasil reconhecer com todas as letras que a certificação de Scrum Master não certifica nada... O que é que falta então? Alertar o "consumidor" ?

o ministério da ciência e tecnologia adverte:
o certificado de Scrum Master não certifica nada.
(O nome CertifiedScrumMaster é mera conhecidência.)

Não que o certificado seja a raiz do problema ou coisa parecida, mas faz parte de todo um modelo de negócios que tem contribuido surpreendentemente com a popularização de Agile, mas que tem sido irresponsável (ou no mínimo desatento) com outras questões subliminares.

Não podemos esquecer também da publicação do relatório do SEI sobre CMMI e agilidade, que também deu o que falar!

Recentemente li ainda uma discussão na agile-brasil (e outras) sobre um "ataque" de FDD a XP, que rendeu um post desaforado do Milfont.

Sendo curto e grosso: o bixo tá pegando!

Ao invés de me posicionar a respeito de cada evento desses, isoladamente, preferi escrever um ponto de vista mais amplo sobre a tal guerra.

Dou-me a liberdade de concordar primeiramente com a posição do Al Gore a respeito da convivência entre os costumes antigos e os novos valores da comunidade global. Enquanto um baseou-se na mecanização, produção em larga escala, desenvolvimento tecnológico e econômico, o outro clama por um pensamento mais holístico, que valoriza a sustentabilidade do sistema, e coloca em cheque vários costumes básicos da sociedade moderna, guiada pelo consumo.

A posição dele a respeito dessa mudança de pensamento - segundo um amigo me explicou - é que se trata de uma espécie de "evolução" do pensamento (não necessariamente linear) que engloba e supera as ideologias e concepções atuais. Mas isso não implica, de forma alguma, na classificação dos valores antigos como "maus" ou "ruins", simplesmente. Não se trata de separar o que é bom do que é ruim. O pensamento anterior foi importantíssimo, por bastante tempo. E continua sendo, mesmo porque - mas não apenas por isso - nos serve em análises, comparações, críticas, analogias, etc. (Foi um pouco disso que eu quis expressar quando escrevi sobre agile e pmbok).

O mesmo acontece com Agile. Não é simples como dizer "XP é bom, FDD é ruim". Do ponto de vista prático, a posição mais sensata que ouvi foi a do AlissonVale. Entenda todos os pontos de vista, e aplique aquilo que for mais apropriado ao contexto específico de cada projeto. Nomes e siglas não importam muito mesmo... (Acho que é a opnião do FelipeRodrigues também, BTW) Pelo menos não importam muito (ou não deveriam importar) na prática, no dia a dia de um projeto ou de uma organização.

Mas sob outros pontos de vista (metodológico, comercial, cultural, ideológico, ético) acho a discussão e o confronto dos métodos muito pertinentes e bem vindos. Porque evitar o debate?

Conflitos e divergências são oportunidades de aprendizado!

O que acontece, na maioria das vezes, é que as pessoas se sentem ameaçadas - principalmente por já estarem comprometidas demais com alguma posição, organização, aliança - e não quererem "largar o osso"... Não dão o braço a torcer, e preferem evitar a discussão. Agora, rabos presos e egocentrismos a parte, qual o problema em confrontarmos as ideias e investigarmos as "causas raizes" das discordâncias?

Também não acho que invalida a discussão a posição de que Agile está além dos métodos, pois é um conjunto de valores e princípios; uma postura diante do trabalho, mais que uma forma específica de se trabalhar. Isso tudo é bem verdade! É totalmente viável e benéfico que se agregue valores ágeis a um projeto cascata, tradicional. E é perfeitamente possível também que um projeto XP falhe categoricamente, se levar em conta apenas as práticas, deixando os valores de lado. Seja como for, os métodos existem, são estudados, aplicados e estão no cerne dos projetos, influenciando e contribuindo com a formação da cultura da equipe e da organização, e consequentemente com sua postura. Portanto, a discussão sobre os métodos, por si só, já é relevante o suficiente.

Procuremos a bala de prata para cada caso específico, como o Milfont muito bem colocou.

O último argumento contrario à discussão que quero citar - e aquele com que mais discordo - é o de que nós, agilistas, devemos nos unir, juntar forças, pois nosso inimigo comum, na verdade, é o cascata. Oras, vai catar coquinho! - como diria minha vó... Isso aqui não é jogo de futebol, briga de torcida, nem brincadeira de polícia e ladrão. Aproveitemos os diversos pontos de vista para desenvolver uma nova visão, ao invés de nos conformarmos com as picuinhas infantis, apenas.

Há muito para ser discutido. Afinal de contas, por trás das siglas e nomes existem outros aspectos, além do que se costuma enxergar. Intenções, interesses, estratégias, política, disputa de mercado, egocentrismo, vaidade, e nem sei o que mais... Cabe a cada um julgar e separar o que se trata apenas de picuinhas infantis e o que são questões pertinentes e construtivas, embora incovenientes para alguns.

O que diabos é a simplicidade, afinal ?

2008-12-05T14:32:00.000-02:00

Ainda traduzindo...

Então queremos que nosso código fique o mais simples possível. Não parece muito difícil argumentar a favor disso, afinal, quem quer ser complicado? Mas é claro que isso levanta a questão "O que é simples?"

No XPE Kent indica quatro critérios para um sistema ser simples. Em ordem (o mais importante primeiro):

* Executa todos os Testes
* Revela toda sua intenção
* Não há duplicação
* Menor número de classes e métodos

Executa todos os testes é um critério bastante simples. Sem duplicação é também bem direto, embora um monte de desenvolvedores precisem de orientação sobre como atingi-la. O mais estranho tem a ver com revelar a intenção. O quê exatamente isso significa?

O valor básico aqui é a clareza do código. XP atribui um alto valor ao código que é fácil de ler. Em XP "código claro" é um termo em abuso. O que é a intenção de uns revelando código é a clareza para outros.

Em seu artigo da XP 2000, Josh Kerievsky aponta um ótimo exemplo disso. Ele analisa possivelmente o código XP mais público de todos - JUnit. Junit usa decoradores para adicionar funcionalidades opcionais aos casos de teste, coisas como sincronização concorrente e código de setup de batch. Separar esse código em decoradores permite que o código genérico seja mas claro do que ele normalmente seria.

Mas você deve perguntar-se se o código resultante é realmente simples. Pra mim é, mas eu sou familiarizado ao padrão de decoradores. Mas para muitos que não são, é bastante complicado. Similarmente JUnit usa métodos plugáveis que, conforme notei, a maioria das pessoas iniciantes acha qualquer coisa, menos claro. Então devemos concluir que o design do JUnit é mais simples para designers experientes, mas mais complicado para pessoas menos experientes.

Eu acho que o foco na eliminação de duplicação, tanto do "Once and Only Once" do XP, como do DRY (Don't repeat yourself) do Pragmatic Programmer, é uma daquelas óbvias e maravilhosamente poderosas peças de bom conselho. Apenas seguindo ela sozinha já pode te levar bem longe. Mas isso não é tudo, e simplicidade é ainda uma coisa complicada de encontrar.

Recentemente, estive envolvido fazendo algo que bem poderia ser over-designed. O código foi refatorado e certa flexibilidade foi removida. Mas, como um dos desenvolvedores disse, "é mais fácil refatorar código over-designed do que refatorar código sem design." É melhor ser um pouco mais simples do que você precisa ser, mas não é um desastre ser um pouco mais complicado.

O melhor conselho que já ouvi sobre isso vem do Tio Bob (Robert Martin). Seu conselho era não ficar muito preocupado com o que é o design mais simples. Afinal você pode, deve e vai refatorar ele depois. No final a disposição para refatorar é muito mais importante que saber qual o design mais simples de primeira.

O valor da simplicidade

2008-11-08T18:13:00.000-02:00

Continuando a tradução...

Dois dos maiores gritos de guerra em XP são os slogans “faça a coisa mais simples que poderia possivelmente funcionar”, e “você não vai precisar disso” (conhecido como YAGNI - “You Aren´t Going to Need It”). Ambos são manifestações da prática XP chamada Design Simples.

O modo como YAGNI é normalmente descrita diz que você não deveria adicionar nenhum código hoje que será usado apenas por funcionalidades que serão necessárias amanhã. Diante disso, parece simples. O problema surge com coisas como frameworks, componentes reusáveis, e design flexível. Essas coisas são complicadas de construir. Você paga um custo extra antecipado para construi-los, na esperança de receber de volta mais tarde. Essa idéia de construir flexibilidade antecipadamente é vista como uma parte chave do design de software efetivo.

Todavia, o conselho de XP é que você não construa componentes e frameworks flexíveis para o primeiro caso que necessite deles. Deixe essas estruturas crescerem à medida em que são necessárias. Se preciso hoje de uma classe Dinheiro que trate adição, mas não multiplicação, então eu construo apenas a adição na classe Dinheiro. Mesmo que eu tenha certeza de que vou precisar da multiplicação na iteração seguinte, saiba como fazê-la facilmente, e pense que será realmente rápido fazer, ainda assim vou deixá-la para a próxima iteração.

Uma razão para isso é econômica. Se eu tenho que fazer qualquer trabalho que somente será necessário amanhã, significa que eu perco o esforço das funcionalidades que precisam ser feitas nessa iteração. O plano da release diz o que precisa ser feito para essa iteração, trabalhar em outras coisas para o futuro é contrário ao acordo que os desenvolvedores tem com o cliente. Existe um risco de que as histórias dessa iteração possam não ser concluídas. Mesmo que as histórias dessa iteração não estejam em risco, é o cliente quem deve decidir qual trabalho extra deveria ser feito - e isso pode não incluir a multiplicação.

Esse des-incentivo é composto pela chance de que podemos não ter entendido a funcionalidade direito. Por mais certo que possamos estar sobre como essa funcionalidade deveria funcionar, podemos ainda assim estar errados - especialmente já que não temos os requisitos detalhados ainda. Trabalhar na solução errada cedo é um desperdício ainda maior do que trabalhar na solução certa cedo. E os XPerts normalmente acreditam que somos muito mais propensos a errar do que acertar (e eu concordo com esse sentimento.)

A segunda razão para o design simples é que um design complexo é mais difícil de entender que um design simples. Portanto qualquer modificação do sistema é feita com mais dificuldade pela complexidade adicionada. Isso adiciona um custo durante o período desde que o design mais complicado foi adicionado até quando ele foi necessário.

Agora, esse conselho parece totalmente sem sentido para um monte de gente, e eles estão certos por pensarem assim. Certos, dado que você imagine o mundo usual do desenvolvimento onde as práticas habilitadoras de XP não estão presentes. Entretanto quando, o balanço entre o design planejado e evolutivo é obtido, então YAGNI se torna uma boa prática (e somente então).

Portanto, para sumarizar. Você não quer desperdiçar esforço adicionando nova capacidade que não será usada até uma iteração futura. E mesmo se o custo for zero, você ainda assim não quer adiciona-la porque ela aumenta o custo de modificação, mesmo que não custe nada para colocá-la. Entretanto, você apenas pode se comportar assim quando você está usando XP, ou uma técnica similar que reduza o custo das mudanças.

As práticas habilitadoras de XP

2008-11-01T16:12:00.000-02:00

Continuando a série... ( a propósito, há alguma tradução melhor para "enabling practices" ? )

XP é controversa em muitos sentidos, mas uma das bandeiras vermelhas em XP é que ela advoga design evolutivo ao invés de design planejado. Como sabemos, design evolucitivo não pode funcionar devido ás decisões ad hoc e à entropia de software.

Na raiz do entendimento desse argumento está a curva de mudanças do software. A curva de mudanças diz que, à medida que o projeto decorre, torna-se exponencialmente mais caro fazer mudanças. A curva de mudanças é normalmente expressa em termos de fases "uma mudança feita durante a análise por $1 custaria milhares para consertar em produção". É irônico que a maioria dos projetos ainda trabalhe em um processo ad-hoc que não possui uma fase de análise, mas a exponenciação ainda está lá. A curva de mudanças exponencial significa que o design evolutivo não pode funcionar. Também indica o motivo pelo qual o design planejado precisa ser feito cuidadosamente, porque qualquer erro no design se depara com a mesma exponenciação.

A premissa fundamental a respeito de XP é que é possível nivelar a curva o suficiente para fazer o design evolutivo funcionar. Esse nivelamento é tanto habilitado por XP como explorado por XP. Isso é parte do acoplamento existente entre as práticas de XP: especificamente não se pode fazer aquelas partes de XP que exploram a curva nivelada sem fazer aquelas que habilitam o nivelamento. Essa é uma fonte comum de controvérsia sobre XP. Muitas pessoas criticam a exploração sem entender a habilitação. Frequentemente as críticas surgem da própria experiência dos críticos onde não usaram as práticas habilitadoras que permitam que as praticas exploradoras funcionem. O resultado é que eles se queimam e quando vêem XP eles lembram das chamas.

Existem muitas partes para as práticas habilitadoras. No centro estão as práticas de Testes e Integração Contínua. Sem a segurança provida pelos testes, o resto de XP seria impossível. Integração contínua é necessária para manter a equipe em sincronia, de modo que se possa fazer mudanças sem aborrecimentos para integra-la com os outros. Juntas essas práticas podem ter um grande efeito na curva de mudanças. Me recordei disso mais uma vez aqui na ThoghtWorks. Introduzir testes e integração contínua trouxe melhoras significativas no esforço de desenvolvimento. Certamente o suficiente para questionar a assertiva de XP de que você precisa de todas as práticas para obter uma grande melhoria.

Refactoring possui um efeito similar. Pessoas que refatoram seu código da forma disciplinada sugerida pela XP vêem uma diferença significativa em sua efetividade compara a fazer reestruturações de forma mais frouxa e ad hoc. Essa foi minha experiência quando Kent me ensinou a refatorar corretamente. Afinal, apenas uma mudança forte me motivaria a escrever um livro completo sobre isso.

Jim Highsmith, em seu excelente resumo sobre XP, usa a analogia de um conjunto de escalas. Em uma bandeja está o design planejado, na outra refactoring. Em abordagens mais tradicionais o design planejado domina porque a premissa é que não se pode mudar de idéias depois. À medida em que o custo das mudanças diminui, você passa a poder fazer a maioria do seu design mais tarde como refactoring. O design planejado não some completamente, mas agora existe uma balança de duas abordagens de design para se trabalhar. Pra mim, é como se antes do refactoring eu estivesse fazendo todo o meu design com uma mão só.

Essas práticas habilitadoras de integração contínua, testes e refactoring provêem um novo ambiente que torna plausivel o design evolutivo. Entretanto, uma coisa que ainda não conseguimos visualizar é para onde a balança deve apontar. Tenho certeza de que, tirando a impressão de quem está de fora, XP não é apenas testa, codifica, e refatora. Existe espaco para projetar antes da codificação. Parte dele se faz antes de se existir qualquer código, a maioria ocorre nas iterações antes de codificar uma tarefa em particular. Mas existe uma nova balança entre o design up-front e o refactoring.

continua...

Design planejado e evolucionário

2008-10-13T16:15:00.000-03:00

Então, continuando a série...

Nesse artigo vou descrever dois estilos como design é feito em desenvolvimento de software. Talvez o mais comum seja design evolucionário. Essencialmente design evolucionário significa que o design do sistema cresce à medida em que o sistema é implementado. Design é parte do processo de programação e à medida em que o programa evolui o design muda.

Em seu uso comum, design evolucionário é um desastre. O design acaba virando a agregação de um monte de decisões táticas ad-hoc, onde cada uma delas torna o código mais difícil de alterar. Em muitos sentidos, você poderia argumentar que isso é ausência de design, é claro que normalmente isso leva a um design pobre. Como Kent costuma dizer, o design existe para possibilitar que você continue mudando o software facilmente no longo prazo. Quando o design deteriora, vai junto sua habilidade de fazer mudanças efetivamente. Chega-se ao estado de entropia de software, ao longo do tempo o design torna-se pior e pior. Isso não apenas torna o software mais difícil de mudar, mas também torna os bugs mais fáceis de se reproduzirem e mais difíceis de achar e matar de forma segura. Esse é o pessadelo do "code and fix", onde os bugs se tornam exponencialmente mais caros de corrigir à medida em que o projeto evolui.

Design planejado é um remédio para isso, e contém uma noção nascida em outros ramos da engenharia. Se você quer construir uma casinha de cachorro, basta pegar um pouco de madeira e construir uma forma rude. Todavia, se você quer construir um arranhacéus, você não pode trabalhar assim - ele vai simplesmente desabar antes que se chegue na metade. Então você começa com desenhos de engenharia, feito em um escritório de engenharia como aquel em que minha esposa trabalha no centro de Boston. Enquanto ela faz o design ela considera todos os detalhes, parcialmente por meio de análises matemáticas, mas principalmente usando códigos de construção. Códigos de construção são regras sobre como desenhar estruturas baseado em experiência do que funciona (e alguma matemática subjacente). Uma vez que o design está pronto, então a companhia de engenharia dela pode passar o design para outra empresa construir.

Design planejado em software deveria funcionar da mesma forma. Designers pensam as grandes questões antecipadamente. Eles não precisam escrever software porque não estão construindo o software, eles estão projetando. Então eles podem usar técnicas de design como UML que deixam de fora alguns detalhes de programação e permitem que os designers trabalhem em um nível mais abstrato. Uma vez pronto o design, eles podem passá-lo para um outro grupo (ou até outra empresa) para construir. Já que os designers estão pensando em larga escala, eles podem evitar toda a série de decisões táticas que levam à entropia de software. Os programadores podem seguir as diretrizes do design e, uma vez que sigam o design, chegar a um sistema bem feito.

Então a abordagem do design planejado vem sendo usada desde a década de 70, e um monte de gente a usou. Ela é melhor em muitos sentidos que o design evolucionário "code and fix". Mas ela tem algumas falhas. A primeira é que é impossível pensar em todos os detalhes com que se precisa lidar na hora de programar. Então é inevitável que na hora de programar você encontre coisas que questionem o design. Entretanto, se os designers já tiverem terminado e se engajado em outro projeto, o que acontece? Os programadores começam a codificar por fora do design e a entropia se estabelece. Mesmo se o designer não tiver ido embora, leva tempo para organizar as questões de design, e então mudar o código. Normalmente faz-se um conserto mais rápido pela pressão. Entropia (de novo).

Ademais, há normalmente um problema cultural. Designers se fazem designers pela habilidade e experiência, mas eles estão tão ocupados trabalhando nos designs que não têm mais tanto tempo para codificar. No entanto, as ferramentas e materiais de desenvolvimento de software mudam rapidamente. Quando você não programa mais, não apenas fica defasado com o fluxo tecnológico, mas também perde o respeito daqueles que programam.

Essa tensão entre os construtores e designers acontece na construção civil também, mas é mais intensa em software. Isso porque existe uma diferença chave. Em construção civil existe uma divisão clara entre aqueles que projetam e aqueles que constróem, mas em software não é bem assim. Qualquer programador trabalhando em ambientes de alto design precisam ser muito habilidosos. O bstante para questionar as decisões de design, especialmente quando o designer conhece menos sobre a realidade do dia a dia e a plataforma de desenvolvimento.

Agora veja, esses problemas podem ser corrigidos. Talvez consigamos lidar com a tensão humana. Talvez consigamos designers habilidosos o bastante para lidar com a maioria dos problemas e tenhamos um processo disciplinado o suficiente para mudar os desenhos. Há ainda outro problema: mudanças de requisitos. Mudanças de requisitos são a causa número das enxaquecas nos projetos de software.

Uma forma de lidar com mudanças de requisitos é embutir flexibilidade no design de modo que se possa mudá-lo facilmente à medida que os requisitos mudam. No entanto isso requer insight sobre que tipos de mudanças se espera. Um design pode ser planejado para lidaar com áreas de volatilidade, mas enquanto isso pode ajudar para as mudanças previstas, não pode ajudar (e pode atrapalhar) as mudanças imprevistas. Então é preciso entender os requisitos suficientemente bem para separar as áreas voláteis, e a minha experiência é que isso é muito difícil.

Alguns desses problemas de requisitos são causados por não entender os requisitos de forma clara o suficiente. Então um monte de gente se foca em processos de engenharia de requisitos para obter requisitos melhores, na esperança que isso previna a necessidade de mudar o design depois. Mas até esse caminho pode não levar a uma cura. Muitas mudanças de requisitos imprevistas ocorrem devido a mudanças no negócio. Essa não podem ser evitada, por mais cuidadoso que seja o seu processo de engenharia de requisitos.

Tudo isso portanto faz o design planejado parecer impossível. Certamente esses são grandes desafios. Mas não estou convencido de que o design planejado é pior que o design evolucionário, da forma como é normalmente praticado de maneira "code and fix". Então eu prefiro design planejado a "code and fix". No entanto, estou ciente dos problemas do design planejado e estou procurando um novo caminho.

continua...

O design está morto?

2008-10-05T15:39:00.000-03:00

Começo com esse post a tradução de um dos melhores artigos que conheço a respeito de design ágil de software: "Is design dead?" do Martin Fowler.

Vou traduzir o texto em vários posts, para preservar um pouco do meu tempo, e pra adaptar o discurso longo a um formato mais curto, mais apropriado ao blog.

Para os que já conhecem, é uma ótima oportunidade para recordar. Pra quem nunca leu, meu conselho é que corra logo e leia a versão em inglês no blog do autor (que com certeza é bem melhor que a minha tradução).

Mas se ainda não mexi com sua curiosidade o bastante para vencer a preguiça, acompanhe a série de posts que farei aqui, ou espere até o final da tradução e confira o texto completo, que será publicado junto às outras traduções.

Se por acaso alguém achar que a tradução não ficou boa, e quiser deixar alguma sugestão, será muito bem vinda nos comentários.

Vamos à seção que introduz o artigo, apresentando sua questão central.

(apenas a titulo de registro, estou traduzindo a versão de maio de 2004)

Para muitos que têm seu primeiro contato com Extreme Programming, parece que XP prevê a morte do design de software. Não somente a maioria das atividades de design é ridicularizada como "Big Design Up Front", mas ainda técnicas como UML, frameworks flexíveis, e até mesmo design patterns são pouco enfatizadas ou totalmente ignoradas. Na verdade XP envolve muito design, mas o faz de um modo diferente dos processos de software estabelecidos. XP rejuveneceu a noção de design evolutivo com práticas que tornam a evolução uma estratégia de design viável. Ela também apresenta novos desafios e habilidades já que os designers precisam aprender como fazer um design simples, como usar refactoring para manter um design limpo, e com usar patterns em um estilo evolucionário.

(Esse artigo foi escrito para minha apresentação na conferência XP 2000 e sua forma original foi publicada como parte dos anais.)

* Design planejado e evolucionário
* As práticas habilitadoras de XP
* O valor da simplicidade
* O que diabos é simplicidade, afinal
* Refatoração viola YAGNI?
* Patterns e XP
* Cultivando uma arquitetura
* UML e XP
* Sobre metáforas
* Você quer ser um arquiteto quando crescer?
* Reversibilidade
* A vontade de projetar
* Coisas que são difíceis de refatorar
* O design está ocorrendo?
* Então o design morreu?
* Créditos
* Histórico de revisões

Extreme Programming (XP) desafia muitas das suposições sobre desenvolvimento de software. Uma das mais controvérsas é sua rejeição a esforços significativos em design prévio, em favor de uma abordagem mais evolucionária. Para seus criticos isso é um retorno ao desenvolvimento "code and fix" - normalmente conhecido como hackear. Para seus fãs é frequentemente visto como uma rejeição das técnicas de design (como a UML), princípios e padrões. Não se preocupe com design, se você escutar o seu código um bom design surgirá.

Eu me encontro no centro desse argumento. Grande parte da minha carreira envolveu linguagens gráficas de design - a linguagem de modelagem unificada (UML) e seus precursores - e padrões de projeto. Eu escrevi livros sobre ambos: UML e patterns. O meu envolvimento com XP significa minha renúncia ao que escrevi sobre esses assuntos, livrando minha mente de todos esses conceitos contra-revolucionários?

Bem, não vou conseguir mantê-los nesse suspense. A resposta curta é não. A resposta longa é o resto desse artigo.

A resposta longa será publicada aqui, seção por seção.

Continue lendo a segunda parte: Design planejado e evolucionário

Agile and The Matrix

2008-09-24T22:47:00.000-03:00

Foi lendo o Fragmental que me deparei com essa comparação, em um dos comentários:

Por fim, quem já viu o “making the matrix” que vem no DVD do Matrix? O produtor (GP) explica como eles conseguiram fazer o filme a um custo tão baixo. Porque os diretores conseguiram ver todo o filme no storyboard. Não precisaram ir filmando para irem apurando a idéia. Foi um Waterfall. Matrix!

Adoro analogias, mas também acho que essa deixou um pouco a desejar. A resposta do Philip, sintetizando bem grosseiramente, foi:

- Documentos são caros;
- É difícil prever o futuro;
- Filmar é muito caro, pode valer a pena o preço para tentar adivinhar o futuro;
- Software é flexível;

Não descordo de nenhum dos pontos dele (embora tenha achado o terceiro meio confuso), mas gostaria de fazer as minhas considerações também. Como adoro analogias, achei que o assunto merecia um post só pra mim. ;-) [ licença Philip, licença Augusto. ]

O meu ponto de vista:

Em primeiro lugar, não acho que o story-board por si só configure um waterfall. Story-boards são uma ferramenta maravilhosa, pois conseguem expressar o projeto de forma âmpla. Mas apenas de forma âmpla, não detalhada.

Os detalhes serão, sim, pensados just-in-time. Quanta luz será usada? Incidindo em que posição/direção? Como os atores devem se posicionar? Devem falar essa frase mais ou menos rápido? Com que expressão? Com que tom de voz? E o penteado? Muitos e muitos detalhes são deixados pra última hora, não tem jeito. Ninguém consegue imaginar todos os detalhes com antecedência. E nem seria muito inteligente fazer, pense um pouco...

Esse não é um caso BDUF (Big Design Up-Front), mas de EDUF (Enough Design Up-Front). A diferença é sutil. (Engraçado, olha o primeiro resultado que o Google traz para enough: good enough)

O Philip escreveu que, "[no caso do filme,] pode ser mais barato pagar o preço de tentar adivinhar o futuro e modelá-lo completamente em uma ferramenta gráfica." Mas acho que, no caso do software, o problema é ainda mais crítico. Pois um pequeno detalhe, descoberto em cima da hora, pode acarretar uma mudança gigantesca no custo do projeto (guardadas as proporções).

É como se, na hora de analisar a iluminação da última cena, descobríssemos que o filme todo precisará ser filmado novamente porque senão ninguém vai assistir o filme, e o dinheiro terá sido praticamente jogado no lixo.

No caso do filme, é até difícil imaginar um cenário desses. Mas em software, esse tipo de coisa acontece praticamente todo dia. Não há como evitar as mudanças, pelo menos se estamos querendo desenvolver algo que realmente tenha qualidade, no sentido de maximizar o retorno do investimento.

O problema é mais simples que isso: não dá pra adivinhar o futuro e pronto. Não importa quanto dinheiro se esteja disposto a gastar.

Se não podemos prever as mudanças, e evitá-las é contra-producente (pra não dizer estúpido), a única solução possível é se preparar para a adaptação às mudanças (Embrace Changes): um dos pilares do desenvolvimento de software moderno.

Scrum funciona sem XP?

2008-09-05T00:23:00.000-03:00

Fui ouvir falar de Scrum bem depois de já ter batido muita cabeça tentando convencer as pessoas a usarem XP. Parece que de uma hora pra outra todos os mesmos conceitos que causavam pânico a qualquer gestor derrepente se tornaram moda. É como se o diabo tivesse sido promovido a arcanjo da noite pro dia, só porque mudou de nome (e de roupa). Não tenho dúvidas, Scrum é muito mais "vendável" que XP. Agora, cá pra nós, dá pra aplicar gerenciamento ágil com segurança sem usar práticas de desenvolvimento que o suportem?

Mesmo que se afirme que o Scrum tenha sido criado antes do XP, não foi assim que vi as coisas acontecerem aqui no Brasil. De um jeito ou de outro, não é esse o ponto central nesse post. Também não quero entrar no mérito sobre o Scrum tratar-se de uma disciplina mais âmpla, aplicável a outras áreas, além do desenvolvimento de software. Pretendo menos ainda atiçar uma disputa entre os dois ou dizer que "XP é melhor do que Scrum" ou outros maniqueísmos babacas (com o perdão da(s) palavra(s)).

Então a relação mais simples a se delinear entre esses dois, sob o ponto de vista de seus conteúdos, me parece ser:

E sob esse ponto de vista XP seria mais âmplo que Scrum. Mesmo porque as práticas de planejamento do XP são, em sua essência, Scurm - puro e escarrado. A menos de certos detalhes (ao meu ver) irrelevantes, não há o que tirar nem pôr.

Agora, falando especificamente sobre desenvolvimento de software, me parece arriscadíssimo aplicar o gerenciamento ágil sem técnicas como desenvolvimento orientado a testes, integração contínua, refactoring, etc.

Como posso me dar ao luxo de deixar o cliente escolher a ordem em que as funcionalidades serão desenvolvidas, ou permitir que a equipe levante os detalhes do sistema just-in-time, na hora de codificar?

Não há como implementar um software dessa forma sem se deparar volta e meia com algum detalhe que não havia sido pensado, suposições erradas a respeito do negócio, modelagens incoerente e outros mal entendidos. Aprendizado é uma palavra-chave aqui, certo?

Trabalhar dessa forma, portanto, pressupõe que o design do código volta e meia terá que passar por algumas "reformulações" (como se traduz refactoring mesmo?). Mas como pode uma equipe (de seres humanos) mexer na estrutura de um sistema poucos dias antes de uma entrega de um produto que deve estar "em qualidade de produção", relativamente sem bugs?

Alguém se arriscaria a mudar o modelo relacional do banco de dados de uma aplicação crítica, que já está em produção, e deve permanecer lá, sem erros, depois do upgrade daqui a duas semanas? Ou melhor: alguém se arriscaria a uma coisa dessas sem ter uma bela suite de testes automáticos pra dar segurança?

Costumo dizer que programar sem testes automáticos é o mesmo que um eletricista mexer em um painel de disjuntores sem ter as emendas dos cabos isoladas com fita. Vc botaria a mão ali?

Sinceramente, não me parece seguro aplicar Scrum a um projeto de software sem testes automáticos, integração contínua, design incremental, refactoring, e programação em par.

Na verdade, não me parece seguro aplicar coisa alguma sem isso! Não é privilégio do Scrum, claro.

Meu objetivo não é "falar mal" do Scrum. Como li n'alguma coisa do ViniciusTelles (não lembro onde), "não tenho nada contra Scrum. Adoro Scrum! Tanto que o uso como metodologia de planejamento em meus projetos XP" (ou alguma coisa parecida com isso).

O que me deixa "encafifado", simplesmente, é que é muito comum as pessoas se apaixonarem por Scrum e morrerem de preconceitos de XP. Como pode?

(Veja também minha opnião sobre Agile x PMBok & cia)

PMBok x Agile: análises e manuais

2008-08-01T15:52:00.000-03:00

Aqui estou com o "CMMI - Guidelines for process Integration and Product Improvement" na minha frente, tendo acabado de ler o excelente post do Willi sobre PMBok e Agile. (Me lembro agora como fiquei impressionado com a estruturação desse livro. Cada referência é feita com uma precisão cirúrgica. Cada coisa tem um código, cuidadosamente atribuído e utilizado para remeter aos tópicos citados. )

A discussão sobre se "é possível aplicar PMBok/RUP/CMMI/MPS.Br com Agile" não faz mesmo muito sentido, no fim das contas. Todas essas siglas do time das metodologias tradicionais, não passam de diferentes visões a respeito do processo de desenvolvimento. Tratam-se de modos diferentes de se entender um "mundo" específico: o de projetos de desenvolvimento de software (Eu sei, não se aplicam apenas ao desenvolvimento de software, mas isso não é importante agora).

Modo de entender também específico, diga-se de passagem. São visões essencialmente analíticas, que procuram clarear as coisas "destrinchando" ou "separando" seus elementos, numa estratégia "dividir e conquistar". O oposto seria o entendimento sintético, onde se parte de vários elementos e compõe-se um todo, como fazemos ao concluir um texto: juntamos tudo o que foi dito para se reconstruir a idéia geral novamente.

Sob esse ponto de vista, conjuntos de conhecimento como PMBok e CMMI seriam muito bem apresentados em um MapaMental.

(conteúdo tirado da wikipedia)

Cá pra nós, trata-se de uma bela análise de todos os elementos necessários à grande maioria dos projetos de software. Alguns vão descordar com o meu "necessário". Muitas dessas coisas podem não ser realmente necessárias... Será? Peguemos alguns elementos como exemplo.

Controle de mudanças do escopo

"Ora, em meu projeto ágil eu não preciso fazer controle das mudanças do escopo."

Como não? E o que é que estamos fazendo quando não permitimos, de jeito nenhum, mudanças no backlog ao longo de um sprint? Só permitimos que novas tarefas entrem no planejamento a partir de uma reunião com toda equipe. Pra que? Pra que se possa controlar as mudanças no escopo, oras. Se a equipe não tiver controle sobre as mudanças no planejamento, não poderá lidar com elas.

Gerênca de riscos

"Não tenho um plano de riscos em meu projeto ágil."

Pode ser. Mas dizer que não há gerência de riscos já é demais. Os riscos são gerenciados o tempo todo. Pelo product owner ao escolher histórias durante o planejamento; pela equipe ao estimar; pelo coach ao cultivar a disciplina em se escrever testes automáticos. Todos avaliam os riscos de cada passo ao longo do projeto.

Dê uma olhada na estrutura de tópicos desses livros. São análises extremamente detalhadas, completas e estruturadas. Trata-se de um trabalho de mestre. Identificar, estruturar e descrever cada um desses elementos foi sem dúvida um trabalho notável e de grande valor para nossa indústria. Obrigado.

O problema não está exatamente na análise que essas abordagens fazem. As análises são espetaculares. O problema é que, no dia a dia de um projeto, essas análises são inúteis.

É como comprar um manual de direção de automóveis que faz uma análise detalhada de todas as técnicas para se apertar a embreagem, o momento ideal para se passar as marchas, etc. Por mais detalhado e acertado que esteja o manual, não ajuda nada levá-lo no colo na hora de dirigir. Nem adianta estudar cada detalhe e tentar lidar com tudo de uma vez.

No momento de dirigir, o que importa não são os detalhes, mas o todo. Tentar visualizar, compreender e controlar cada um dos elementos envolvidos é ao mesmo tempo inútil e desgastante. É coisa demais.

Isso nos leva diretamente ao argumento do Willi. Ninguém disse que se precisa aplicar tudo o que está nos livros. Pelo contrário, os capítulos iniciais de todos eles afirmam categoricamente que tudo deve ser adaptado, escolhido, filtrado. O problema é que nenhum deles explica como as coisas devem ser escolhidas, nem tampouco adaptadas. As práticas precisam ser modificadas para o seu projeto especificamente. Mas como? Problema seu.

Dessa forma, a leitura subliminar que se faz é que os projetos devem ser gerenciados sob todos os aspectos. Quanto mais detalhes se consegue visualizar e documentar, mais maduro seu processo é. Sobre isso cria-se uma escala de mérito totalmente deturpada, baseada em inspeções, avaliações, provas, exames e outras atrocidades. Elementos artificiais, que contribuem apenas para enviesar ainda mais o processo de melhoria, cuja preocupação maior passa a ser o certificado que se ganha no final. (Não me parece muito um sinal de maturidade... :-/ )

XP e Scrum, ao contrário, não fazem leituras analíticas. Lidam com questões práticas que se sustentam através de uma cadeia de valores explícita e coerente, reflexo das necessidades reais de projetos reais. Você adora cálculos geométricos complicados e instrumentos de precisão. Ótimo, mas para levantar a parede reta seu pedreiro precisa é do fio de prumo.

Pra ser honesto, no livro mais importante sobre XP (na minha opnião), KentBeck faz também uma leitura analítica: XP divide-se em valores, princípios e práticas. Mas veja que nesse caso não se trata de uma análise do processo de desenvolvimento em si. A análise feita refere-se ao modelo de pensamento utilizado para sustentar as práticas.

Essa sim é uma análise relevante. Ela privilegia não uma visão específica de como se deve fazer software, mas uma estrutura de decisão que nos auxilia a definir como as coisas devem ser adaptadas em cada caso. Diferentemente dos livros citados acima, aqui a forma como as coisas devem ser adaptadas é clara e coerente.

O próprio Kent Beck ressalta que os princípios apresentados em seu livro não são os únicos possíveis. Organizações particulares podem cultivar outros valores, outros princípios. E elas devem fazê-lo! O que se coloca é que se deve utilizar uma cadeia de raciocínio análoga para se definir como deve ser o dia a dia dos projetos. Entenda seus valores, expresse seus princípios e deles derive as práticas a serem seguidas.

"Para dirigir, use as duas mãos ao volante." Isso expressa o princípio da direção defensiva, que se sustenta sob o valor Segurança. Agora, se prefere cultivar o valor do Conforto, então deixe o braço esquerdo escorado na janela, é muito melhor. Qual dos dois valores é mais importante agora? Eis um framework para tomada de decisões realmente útil.

Então, sintetizando :-) , o problema de PMBok/RUP/CMMI/MPS.Br não está exatamente na análise que é feita, mas na leitura (propositalmente?) induzida de que se tratam de manuais de direção. Não são. São instrumentos teóricos maravilhosos. Mas se vc está interessado em dirigir bem, deixe-os em casa e veja as coisas da forma ágil.

Profissão: analista de sistemas

2008-07-20T22:44:00.001-03:00

Quando me perguntam por aí qual a minha profissão, ou quando preciso responder isso em algum formulário “genérico”, costumo responder: Analista de Sistemas. É uma resposta também “genérica”, rápida, que não exige maiores explicações e satisfaz a maioria das perguntas - normalmente feitas apenas por obrigação.

Embora seja um termo meio “genérico” demais - e até obsoleto sob certos pontos de vista - ainda o utilizamos em muitos contextos, como no debate sobre a regulamentação da profissão. Não pretendo aqui entrar no mérito dessa discussão, mas refletir sobre o significado do termo em si, questão um pouco mais fundamental, cuja reflexão pode alimentar e influenciar opniões sobre o assunto.

Afinal, o que faz um analista de sistemas? Ora, se interpretarmos ao pé da letra, deve ser alguém que estuda sistemas e o divide (corta, quebra) em outros menores, mais simples, para que se possa compreendê-los mais facilmente. Não é difícil encaixar nessa definição alguns papeis e funções que costumamos ver em projetos de software tradicionais.

O “analista de requisitos” esclarece os detalhes de um dado domínio, através de modelos, diagramas e descrições. Seu “sistema” são os processos do cliente. O arquiteto analisa o problema em módulos, componentes, camadas, e outros recortes. Seu “sistema” é um programa, (ou vários) visto como um todo. O programador divide cada funcionalidade e operação em funções, procedimentos, estruturas de dados e instruções.

A visão tradicional de um analista de sistemas passa, de um modo ou de outro, por um desses aspectos. Ou por todos ao mesmo tempo, considerando-os especializações, ou rumos a se seguir dentro da profissão. Enxerga “o sistema”, portanto, como toda essa “coisa” que automatiza (informatiza) os processos do cliente.

Em metodologias ágeis costumamos identificar um número menor de papéis, ou especializações, criado uma visão mais holística de equipe, que ressalta valores como interdisciplinaridade, auto-organização, habilidades sociais, lideranças, etc.

Mas, se por um lado tem-se menos tipos de “analistas”, por outro enxergamos mais “sistemas” a serem analisados, compreendidos e geridos. Ou pelo menos um sistema mais completo, que vai além dos saberes técnicos que são ensinados nas faculdades de tecnologia - cursos focados em teorias e técnicas matemáticas, exatas, objetivas.

Essas metodologias reconhecem outros sistemas extremamente relevantes aos processos de desenvolvimento. Aspectos humanos e organizacionais, jogos de intenções e interesses, forças políticas, estruturas sociais e questões motivacionais. Um emaranhado de fatores que compõem o ambiente e a cultura da empresa, e que fazem parte do inconsciente coletivo da equipe. Questões importantíssimas e determinantes para o sucesso de qualquer projeto.

Um arquiteto pode estar mais preocupado com seu ego do que com o bom andamento do projeto, ao propor uma solução complexa demais; um gestor pode estar mais interessado em seguir uma tendência de pensamento com que sua gestão já se comprometeu; um programador pode não tirar uma dúvida importante de projeto com o cliente pela estrutura de comunicação que se criou; ou pode não sinalizar sobre um problema que identificou no design por causa de sua baixa auto-estima junto à equipe.

O desenvolvimento de software é acima de tudo uma atividade criativa, de aprendizado coletivo e de auto-conhecimento para todos: clientes, usuários, programadores. Ao mesmo tempo que a equipe está aprendendo os detalhes tecnológicos envolvidos na solução, usuários estão aprendendo a ver de forma mais clara seus processos de trabalho. A equipe como um todo (incluindo cliente e usuário) está aprendendo a se comunicar e a colaborar para desenvolver uma visão única e coesa do “sistema”, aprimorando seu processo de trabalho a cada dia (melhoria contínua).

Sob esse novo ponto de vista, a expressão “analista de sistemas” ganha uma conotação integral, levando em conta um sistema mais âmplo, que precisa ser não apenas analisado, mas percebido, compreendido, refletido e gerido.

Programação em par

2008-07-02T20:25:00.001-03:00

Essa talvez seja a prática mais demorada de se aprender em XP. Não que seja extensa ou complicada. Nada disso.

A questão é que, para se compreender a prática de verdade, é preciso primeiro acreditar nela.

O pensamento mais imediato, claro, é sempre imaginar que se gasta o dobro para realizar a mesma tarefa. Esse pensamento não está certo. Porque a programação é uma tarefa criativa e não respeita à lei "quanto mais gente, mais trabalho se realiza". Nesse caso, a qualidade do código produzido interfere muito na produtividade dos próximos passos. Então vale muito mais a pena "gastar" o dobro da atenção sobre cada parte dele.

Não é fácil argumentar sobre isso, nem é esse o meu propósito aqui. Quem já experimentou programação em par "na veia" vê isso com uma clareza impressionante. Mas pra quem está iniciando, acreditar nisso não é tão natural.

Quanto mais se acredita, melhor se pratica. Quanto melhor se pratica, mais se acredita. Mais um ciclo virtuoso que costuma estar presente em XP.

Aqui está um screencast muito interessante pela própria "inovação tecnológica" da idéia. Mais interessante ainda pela forma como consegue expor uma seção de programação em par tão de perto. Quase que se participa dela. Impressionante!

(Sugestão: assista em full-screen)

Cola: Real-Time Shared Editing from Mustafa K. Isik on Vimeo.

A programação em par, quando acontece fluida, assemelha-se muito a uma conversa, ou uma seção de design, onde se discute a modelagem do sistema com papel e lápis. Se a programação for guiada por testes ainda por cima, aí é que a coisa fica bonita!

Alguém se habilita pra gravar algumas seções com foco mais metodológico que tecnológico, usando TDD, BDD, etc.?

AgilDF, reunião 2

2008-06-24T16:44:00.000-03:00

Na última sexta-feira, dia 20/06/2008, fizemos nossa segunda reunião presencial do grupo AgilDF. A reunião foi ótima! Alguns bons indicativos que posso citar de antemão são a participação, que dobrou desde a última reunião (éramos mais ou menos 15 dessa vez) e o horário de término da reunião, que prolongamos por uma hora sem nem perceber (acabamos às 22:00 ao invés das 21:00 e ainda ficamos conversando lá embaixo mais uns 15 ou 20 minutos).

A reunião aconteceu mais uma vez na SEARCH, na sala de treinamentos deles que é ótima! Conversamos em volta da mesona oval... Muito bom! Valeu Ricardo, valeu SEARCH !!!

Vou descrever em linhas gerais o que conversamos, mas é bem provável que eu esqueça alguma coisa, já que estou me baseando nos rabiscos que fiz durante a conversa. Por favor, complementem nos comentários!

A reunião foi marcada pras 19:00, mas como o pessoal foi chegando aos poucos, a conversa foi começando informalmente e encorpando enquanto o pessoal chegava. Nesse começo, a conversa ficou um pouco em torno de perguntas em torno das experiências que estamos tendo na SEA, acho que porque somos os únicos que estamos divulgando por enquanto. :-)

Entre 19:30 e 20:00 o Giovani achou por bem intervir e organizar um começo mais formal para a reunião. Fizemos uma rodada de apresentações, onde cada um falou seu nome, onde trabalha, qual sua posição na equipe, as experiências que já teve e que interesses tem no encontro e no grupo, em geral.

O levantamento que ficou anotado na minha folha de papel foi:

Banco Central:

Giovani;
Marcio;
Cristiano;
Djalma;

Search:

Ricardo;

Min. Previdência

Cristopher;

MPU

Ronald Tetsuo;
Ranieri;

Min. Transportes 

Derlon;

Lumi

Waelson

Stephanini @ STF

Jusmar

SEA

Bruno (eu);
Renato Willi;
Ana Carolina;
Euler;

(Errei algum? Esqueci alguém? Alguém quer um link? deixem comentário...)

Pela minha percepção, tirando nós lá da SEA (que já andamos falando bastante do nossos casos), o pessoal da SEARCH está bem encaminhado, com uma equipe de umas 15 pessoas evoluindo bastante com reuniões de planejamento e testes automáticos; e a equipe do Cristopher que tb estão usando bastante coisa de Scrum.

Além disso, o pessoal do Bacen já teve alguma experiência com XP, estão bastante desanimados com a situação atual (RUP/Praxis/Cascatão) e avistam algumas boas oportunidades para começar um projeto piloto por lá. (Boa sorte, contem comigo (concosco) e vamos acompanhar!);

Lembro tb do caso do MPU, onde já fizeram algumas tentativas (com Scrum né?), mas parece que a bola deu uma baixada. Vamos levantar ela de novo!

Mais algum caso que esqueci?

Depois disso, íamos organizar algum assunto específico pra discutir, mas a conversa se deixou levar pelos ímpetos do pessoal. Deixamos rolar.

Conversamos sobre as restrições que os contratos tradicionais criam, atrelando o pagamento de parcelas a entregas de documentação, assunto puxado pelo Jusmar. A conversa evoluiu para contratos em geral, acordos baseados em PCU, etc. e depois foi pra processos e resistências das estruturas sociais que já existem nas "corporações" por aí (o pessoal do PMI, CMMI, RUP e ouras letrinhas...)

Reservamos os últimos 15 minutos pra conversar sobre o formato das próximas reuniões. Em suma, decidimos que vamos variar o local e o horário. O Ricardo sugeriu de fazermos um encontro aos sábados, em volta de uma churrasqueira (eu gostei da idéia). Vamos sempre fazer uma equete e decidir na lista.

Concordamos com uma periodicidade inicial de aproximadamente um mês, enquanto tivermos assunto e quórum.

Levantamos alguns temas para serem discutidos. Como bons agilistas que somos, vamos priorizá-los na lista e escolher os dois mais interessantes para a próxima reunião. Os temas que anotei foram:

Testes automáticos;
Contratos;
Design evolutivo;
(eu que propus esses três primeiros, pra “abrir a porteira”)
Testes de aceitação com Selenium (Caso SEA@Aeronáutica. Fiquei de escrever um blog antes)
Retrospectivas;
Estimativas;
Caso Bacen - dificuldades, oportunidades, etc.

Essa é apenas a lista que levantamos lá na hora. Vamos aprimorar ela na lista. Acho que a próxima reunião promete! :-)

Comentários?

GIT

2008-06-18T21:16:00.000-03:00

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.

2008-05-28T14:56:00.001-03:00

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

2008-04-27T11:51:00.000-03:00

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.

<div><a href='http://www.omnisio.com'>Share and annotate your videos</a> with Omnisio!</div>

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

Sucata pros senadores

2008-04-21T10:55:00.000-03:00

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

2008-03-13T21:49:00.000-03:00

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

2008-02-20T17:42:00.001-03:00

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

2008-02-18T13:52:00.000-03:00

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!).

Melhoria continua

2007-12-20T19:12:00.000-02:00

Não, infelizmente não vou falar sobre melhoria contínua. O título do post é só uma referência vaga ao belo nome que o ViniciusTeles arrumou para a ImproveIT.

Enfim, não tenho como não me expressar sobre o último post do Vinicius no site da ImproveIT. Há tanto para se refletir e discutir a respeito dele que nem vou me atrever a entrar em detalhes. Só gostaria de mencionar a forma como as coisas se parecem pra mim.

Lembro bem a primeira vez que vi o livro de XP do Vinícius numa livraria. Tava esperando a hora do cinema, mexendo nos livros e então me deparei com o livro dele: XP. Caramba, já tem gente falando de XP no Brasil, que massa!

Fiquei empolgado mesmo, pois na época nunca imaginava que o XP ia prosperar tanto. De lá pra cá (lá se vão uns 2 ou 3 anos), é simplesmente impressionante como o próprio conceito Agilidade se incorporou na cultura empresarial brasileira.

O Vinícius comentou no referido post exatamente a visão que tenho sobre a disseminação do Scrum e sua relação com todo esse movimento de agilidade. É bem verdade que o Scrum trouxe essa visão oportunista (pra não dizer vigarista/charlatã) que ironicamente alavancou as coisas por aqui. É duro que nosso país viva nessas sombras imperialistas até hoje, especialmente na área de tecnologia...

Mas por outro lado, notemos a importância de iniciativas como a do Vinicius e da ImproveIt. A quantidade de comentários solidários no post, num período muito curto de tempo (algumas horas) ilustra o tamanho da comunidade que se formou em torno deles. (Da qual, aliás, também faço parte.)

Claro que eu também teria rios de opniões pra debater todos os pontos levantados naquele post, mas vou me conter a felicitar o pessoal da ImproveIt pela coragem e pela sinceridade da iniciativa.

Por um lado, a notícia causou certa tristeza, pois teve um leve tom de "desistência" diante das incoerências desse mercado. Mas por outro, estou tranqüilo, pois sei que o Vinícius e os demais da ImproveIt continuarão "por perto", participando e contribuindo para o amadurecimento de nossa "indústria", como sempre estiveram. Certamente ainda veremos palestras, podcasts, posts, artigos e tudo mais.

Obrigado Vinícius!

Bancos de dados ágeis

2007-12-07T08:20:00.000-02:00

A alguns meses passei por uma situação que me fez refletir um bocado e fortalecer ainda mais a crença de que o fator mais crítico do desenvolvimento de software atualmente está mesmo nas relações sociais.

Estávamos trabalhando em um projeto grande, e já haviamos conseguindo conquistar uma confiança importante da equipe e do cliente em relação aos métodos ágeis. A equipe era formada por programadores da empresa em que trabalho e programadores do cliente, numa espécie de "desenvolvimento a 4 mãos".

Depois que já estávamos conseguindo implantar uma versão toda semana, acertando as estimativas, escrevendo testes e outras coisinhas, deparamos com o problema do banco de dados evolutivo.

Até aquele momento, isso não era realmente um problema, pois ainda não tínhamos uma versão do software efetivamente em produção, o que nos permitia apagar todo o banco e criar de novo, causando problemas (pequenos) apenas para a única pessoa que estava fazendo testes manuais nas versões lançadas toda semana. Mas logo o problema viria à tona, pois o sistema já estava bastante estável e faltavam poucas funcionalidades para que o sistema se torna-se realmente útil e pudesse ser utilizado "no quente".

Nesse momento, durante nossa reunião de planejamento da semana (na segunda feira), gastamos uns 10 minutos discutindo o assunto, e me veio a idéia de implementarmos (em java) algo parecido com as migrations do rails: A idéia era mantermos o modelo do banco em scripts SQL numerados sequenciamente e manter em uma pequena tabela, no banco, o número da "versão" em que o modelo se encontrava, de modo que o modelo e os dados pudessem ser atualizados "automaticamente" pela aplicação, no momento em que ela fosse iniciada.

A princípio a idéia foi bem aceita, e já estávamos pra um post-it e planejar a tarefa, quando um dos membro da equipe torceu a cara e disse algo como "humm.. não sei não, isso de manter o banco de dados é tarefa para DBA. Nós vamos acabar arrumando problemas caso isso dê problema. Melhor não mexermos com isso..."

Puxa, aquilo foi brochante. A equipe, num piscar de olhos, se desmotivou e desistiu da idéia antes que eu pudesse pensar num argumento para desfazer o feitiço que nosso amigo havia jogado. Não escrevemos o post-it e, até onde sei, o sistema até hoje não entrou em produção.

Depois que tudo passou (nem estamos mais trabalhando no projeto), guardo esse caso como um exemplo de como as relações sociais entre os envolvidos com o projeto pode afetar em questões técnicas capitais. A insegurança e falta de iniciativa de um único membro da equipe foi suficiente para descartarmos uma decisão técnica que poderia viabilizar as implantações parciais do sistema, o encurtamento do ciclo de feedback, o aumento de comunicação entre a equipe e o cliente, etc., etc., etc..

Me lembrei desse pequeno incidente hoje, depois de ter assistido ao último programa do OnSoftware pelo Miro, que se trata de alguns comentários do Scott Ambler sobre seu livro "Refactoring Databases": http://media.podhoster.com/pearsoned2/30_SOFT_Ambler_01.mp4

XP e resistências sociais

2007-10-05T19:02:00.001-03:00

Eis um desafio a que se propõe qualquer cristão que queira implantar métodos ágeis em um projeto, em uma equipe, em uma organização: vencer as resistências sociais que naturalmente se criam quando surgem novas idéias, especialmente as mais inovadoras.

Admito: XP apresenta conceitos novos que nem sempre são fáceis de aceitar. Programação em par, testes primeiro, design evolutivo. Escopo aberto!

Como convencer um PMP ou um avaliador CMMI de que é melhor planejar aos poucos? ou de que é melhor levantar os requisitos o mais próximo possível do momento de implementá-los? Também não é fácil convencer um programador a escrever testes, a integrar frequentemente, a se expor nas reuniões de reflexão, etc.

Como bem colocou Kent Beck, XP não se trata de um processo de desenvolvimento, que define atividades que devem ser realizadas em determinada seqüência, por determinadas pessoas ou papéis. XP é um mecanismo de aprendizado. Um caminho para a melhoria.

Nesse sentido, ao invés de definir regras para as tomadas de decisões, XP define princípios a que qualquer equipe deveria estar atenta no momento de tomar certas decisões. Tomar as decisões, no entanto, é tarefa que deve ser realizada por seres humanos, não por autômatos. (A definição de um processo aderente a CMMI bem lembra um autômato, não?)

Aqui estão dois princípios que eu tomaria do XP para lidar com as resistências de que falei: baby-steps e oportunidade. Antes de mais nada, convencer alguém de qualquer coisa não é tarefa simples. Especialmente em se tratando de quebras radicais de paradigmas, como algumas mudanças propostas em XP. Logo, é preciso que as pessoas se convençam das coisas pouco a pouco.

Eu já passei por situações onde o simples fato de se pronunciar a palavra “XP” era motivo para que uma idéia simples, como reuniões diárias, fosse rejeitada. Com o tempo, percebi que era mais efetivo não tocar naquele nome.

XP é uma dessas coisas de que a gente só se convence que é melhor quando experimenta. Aos poucos, as pessoas se convencem de que as práticas funcionam, e passam a oferecer menos resistência.

É como convencer seu irmão mais novo a experimentar bacalhau. Não diga que é bacalhau, apenas sirva o prato e permita que ele experimente, sem aquele velho preconceito por perto.

O outro princípio, da oportunidade, nos ensina que a sabedoria está em saber esperar o momento certo para agir. Mutas vezes, é preciso ter muita paciência e coragem para esperar esse momento. Cada prática de XP tem seu timing. Cada equipe e organização tem seu timing. É preciso estar atento, com a mente limpa e tranquila, para se perceber o melhor momento de se introduzir cada nova idéia.

Tentar adotar XP por decreto, sem que os envolvidos estejam convenvidos de seu valor é inútil. O máximo que se consegue é fortalecer as resistências sociais que estamos tentando vencer. Para adotar métodos ágeis com eficácia, é preciso que sua equipe toda (inclusive cliente e executivos) acredite no que está fazendo. Conquistar essa confiança é um trabalho lento e árduo, tenha paciência.

Até

Beta eterno

2007-09-02T16:41:00.000-03:00

Quem usa Gmail? Alguém já parou pra se perguntar porque diabos existe a palavra "beta" escrita na logomarca deles?

Que relação isso teria com desenvolvimento ágil e com a Qualidade do processo de software?

O Gmail foi pra mim o primeiro contato com interfaces AJAX e outros conceitos ligados à Web2. A interface do sistema é mais agradavel do que muuuuitos dos programas para desktop com que estamos acostumados, apesar das várias limitações inerentes ao modelo web. Quem usa o Gmail sabe: não tem nem como comparar com outros webmails, simplesmente não tem.

E o "beta", pensou a respeito? Normalmente se usa essa palavrinha para indicar que uma dada versão de um programa está em fase de testes, experimental, ainda em amadurecimento. Indica que não se deve confirar muito no sistema, pois ainda é instável.

Ora, o Gmail não está em fase experimental nenhuma, e nem é instável, sabemos muito bem disso. Em fase de testes sim. O sistema está e sempre estará em fase de testes, mas não com o significado normalmente usado pelas metodologias tradicionais.

Essa "etiqueta" na marca do site, nesse caso, significa Qualidade. É como uma medalha pregada no peito de alguém. (Hoje em dia, os broches na lapela são mais comuns :-) )

Essa marca denota Qualidade uma vez que reconhece dois princípios fundamentais das metodologias ágeis:

* Melhoria contínua;
* Economia;

Ao reconhecer que o Gmail está "em manutenção" até hoje, o Google está praticamente dizendo que o sistema está em processo de eterna melhoria. É o reconhecimento de que um sistema de informação como o Gmail NUNCA ficará pronto. Sistema nenhum jamais ficará pronto, e é por isso que não faz muito sentido definir o escopo como ponto de contrato em projetos de software. (Eu sei, eu sei. Mal necessário...)

O princípio da economia diz que o desenvolvimento de software deve ser orientado de modo a trazer o maior retorno do investimento, o mais rápido possível. Isso quer dizer que um sistema de software precisa entrar em produção o mais rápido possível, para se tornar útil logo, e começar a recompensar o investimento feito.

Criar as condições para que um sistema entre "em produção" precocemente, em modo "beta", é uma estratégia bem mais efetiva do que tentar especificar todas as funcionalidades detalhadamente, e esperar o sistema "ficar pronto" para começar a usá-lo. O sistema nunca ficará pronto.

Olhando desse modo, é melhor tratar o desenvolvimento de software como um processo de manutenção, ao invés de compará-lo a um processo de construção. Desenvolver a primeira funcionalidade de um sistema é como desenvolver a última. Iniciar um novo projeto é como dar manutenção em um sistema vazio.

O desenvolvimento de software é um processo mais parecido com o aprendizado que com a engenharia civil. Quanto antes se estabelecer o diálogo entre desenvolvedor e usuário final, melhor. Portanto crie logo as condições para implantar seu sistema, mesmo que ele ainda não esteja "pronto".

Comece escrevendo testes automáticos

2007-08-22T20:15:00.000-03:00

Muitas empresas ainda tem receio de experimentar metodologias ágeis, seja pela carga semântica herdada no nome extreme programming, seja por falta de informação ou orientação profissional confiável. (Claro, há muito para se discutir a respeito desse “confiável”.)

Começar a utilizar metodologias ágeis pode ser mais fácil do que se imagina. Isso porque a maioria das práticas pode ser adotada isoladamente, e a qualquer tempo em um projeto, resultando em benefícios claros e rápidos.

Diferentemente dos modelos tradicionais de processos de software, essas metodologias entendem que a adoção de novas práticas e processos em uma organização deve ser feita de forma gradativa. Nenhum processo complexo será efetivamente absorvido se implantado todo ele de uma só vez.

A ordem com que as práticas devem ser adotadas se orienta pelas necessidades e prioridades naturais de cada equipe, em cada projeto, e não por roteiros cartesianos definidos em modelos ou exigidos por certificações.

O lado negativo desse cenário flexível é que muitos líderes de equipe acabam não adotando prática nenhuma, por não saberem por onde começar. Preceber com clareza qual ponto do processo precisa ser otimizado com maior prioridade não é uma tarefa muito simples, pelo menos quando não se está acostumado a analisar as coisas dessa forma.

O intuito desse artigo é o de sugerir a prática de escrita de testes automáticos como ponto de partida para equipes que já se perceberam sintonizadas com os valores e princípios ágeis, mas que ainda não sabem por onde começar. Vale também para aqueles que sentem vontade de experimentar alguns conceitos ágeis, mas não têm coragem, por não conseguirem visualizar de antemão o impacto que isso poderia causar.

Na prática, não há muita diferença se seu projeto é reconhecido ou não como um projeto Scrum legítimo ou XP legítmo. Não há, pelo menos no intuito desse artigo, onde se discute a melhoria efetiva do processo. Não estamos tratando aqui (ainda) de aspectos comerciais ou mercadológicos porventura envolvidos.

Então não interessa muito se alguém acha que, ao aplicar apenas uma prática do XP, você não está fazendo XP. O que interessa é que essa prática melhore seu processo de desenvolvimento em algum sentido, em algum grau, por menor que seja.

Ao aplicar uma prática – inicialmente de forma tímida e experimental, e depois de forma entusiasmada e sistemática – ganha-se confiança para então experimentar alguma outra. É assim que se aprende a praticar uma nova metodologia: aos poucos.

O fato é que a adoção da prática de programação orientada a teses também pode ser feita em vários níveis de profundidade. Se por um lado é uma disciplina ampla, variada em pontos de vista, técnicas e dialetos, por outro se baseia em princípios simples que podem ser muito bem expressos em uma suite de testes relativamente despretenciosa e mesmo incompleta.

Mesmo que seu sistema já possua uma quantidade enorme de funcionalidades desprovidas de testes automáticos, escrever o primeiro teste trará grandes benefícios. É preferível ter parte do código testada a não ter nada. O mais importante, no inicio, é ter uma suite que seja simples e consiga conquistar a simpatia e a confiança da equipe. No desenvolvimento ágil, sempre haverão oportunidades para melhorar a forma com que se escreve os testes. No início, meu conselho é: escreva testes simples.

Segundo esse princípio, fica claro que começar a praticar a disciplina de testes automáticos possui impacto muito pequeno e praticamente nenhum risco. Afinal de contas, basta escrever o primeiro teste, da forma mais simples possível ;-)

É óbvio que a prática envolve mais do que a simples automação dos testes. Bem mais. Há muito pra se aprender e evoluir dentro dessa disciplina, mas para isso é preciso começar.

O que é um teste automático?

Um teste automático é um programa que verifica se um outro programa está funcionando conforme o esperado.

Para entender a utilidade de se automatizar testes, faço uma analogia: para que serve a prova real, na matemática? (Alguns vão preferir lembrar da velha prova dos nove) Para se ter mais segurança a respeito da resposta encontrada.

Chama-se isso de princípio da redundância: quando alguma coisa não pode falhar de jeito nenhum, é preciso verificar seu perfeito funcionamento por, pelo menos, duas vias diferentes.

Nesse sentido, podemos apresentar novamente a definição, com outras palavras: um teste automático é a prova de que uma funcionalidade está corretamente implementada. Assim como se exigiria que um contador nos provasse o resultado final de um balancete, espera-se que um programador “demonstre” que a funcionalidade está corretamente implementada.

No desenvolvimento de software, esse conceito se torna ainda mais amplo, pois uma suite de testes verifica também que o software continuará funcionando corretamente ao longo do tempo, enquanto forem surgindo mudanças no código e nos requisitos.

Um exemplo prático

Vamos utilizar como exemplo o código de uma ferramenta que ajudei a escrever: o Coral . Trata-se de uma aplicação wiki, derivada do genial TiddlyWiki, cujo código java que inserimos tem, por enquanto, a única função de armazenar os conteúdos em banco de dados, em um servidor.

A arquitetura dessa aplicação é bem comum: sistema web, escritao em java, arquitetura em três camadas: Apresentação 100% javascript (a interface é o TiddlyWiki), com chamadas Ajax (utilizamos o DWR) a objetos de negócio, ou serviços, sem estado (stateless POJO's), que por sua vez chamam objetos de acesso a dados (DAO's) baseados em Hibernate para gravar os dados. Tudo isso é integrado com Spring:

Quanto ao domínio da aplicação, é bem simples: o sistema possui uma única entidade chamada Tiddler, que representa um tópico do wiki. Esses tópicos são organizados em namespaces, que representam um tema em particular (um conjunto de páginas relacionadas).

Vamos dar uma olhada em um dos teste do Coral:


public void testLoadTiddler() {

// cria um novo Tiddler
Tiddler t = getTestTiddler();

// Salva no BD
TiddlerService service = (TiddlerService) getBean("tiddlerService");

service.saveUpdateDeleteTiddlers("main", new Tiddler[]{t}, new String[0], new Date());

// Lê novamente o Tiddler
t = service.loadTiddler("main", "TestTiddler");

// Verifica os dados salvos
assertEquals("main", t.getNamespace());
assertEquals("TestTiddler", t.getTitle());
assertEquals("this is a [[Tiddler]] that im using to test.", t.getEncodedText());
assertEquals("welcome test", t.getTagsString());
assertEquals("200607132248", t.getCreatedString());
assertEquals("200607132249", t.getModifiedString());
assertEquals("BrunoPedroso", t.getModifier());

// Verifica se o método retorna null para tiddlers ou namespaces inexistentes

assertNull(service.loadTiddler("namespaceInexistente", "TestTiddler"));
assertNull(service.loadTiddler("TestNamespace", "TiddlerInexistente"));

}

Na prática, um teste automático é um método comum que faz três coisas:

1. Preparação;
2. Exercício;
3. Verificação;

Antes de testar, é preciso preparar o sistema, deixando-o na situação necessária para se realizar um dado caso de teste. No nosso exemplo, o método testLoadTiddler() apenas cria um Tiddler no banco de dados:


Tiddler t = getTestTiddler(); // esse método cria o Tiddler com dados de teste...
(...)
service.saveUpdateDeleteTiddlers("main", new Tiddler[]{t}, new String[0], new Date());

(Não se assuste com a assinatura do método saveUpdateDeleteTiddlers() por enquanto. Nesse exemplo, ele apenas salva um Tiddler no banco...)

Em seguida, o método de testes executa as operações que pretende testar. Nesse exemplo, o objetivo do teste é verificar se o método loadTiddler() da classe TiddlerService funciona corretamente.


t = service.loadTiddler("main", "TestTiddler");

Para ter certeza de que esse método funciona corretamente, precisamos verificar o objeto retornado pelo método. Como fomos nós que criamos o tiddler que estava no banco de dados (na fase de preparação), sabemos quais dados devem estar gravados lá. Essa verificação é feita com métodos assertXXX() da API do JUnit:


assertEquals("main", t.getNamespace());
assertEquals("TestTiddler", t.getTitle());
assertEquals("this is a [[Tiddler]] that im using to test.", t.getEncodedText());
assertEquals("welcome test", t.getTagsString());
assertEquals("200607132248", t.getCreatedString());
assertEquals("200607132249", t.getModifiedString());
assertEquals("BrunoPedroso", t.getModifier());

assertNull(service.loadTiddler("namespaceInexistente", "TestTiddler"));
assertNull(service.loadTiddler("TestNamespace", "TiddlerInexistente"));

Em ferramentas IDE como o Eclipse , uma suite de testes funciona, para o programador, mais ou menos como o verificador de código que sublinha trechos do código sintaticamente errados enquanto se escreve o código.

A diferença é que a suite de testes automáticos verifica erros de semântica, enquanto o compilador verifica apenas os erros de sintaxe.

Cada vez que o programador escreve algum código, e precisa verificar o resultado dos testes, basta apertar um botão e executá-los:

Para os testes que não “passam”, é possível verificar a causa e abrir qualquer trecho de código envolvido, simplesmente usando o duplo-clique no elemento desejado da pilha de erro.

Apenas um exemplo

O exemplo apresentado serve apenas para se ter um primeiro contato com a automação de testes. Sugiro que se leia os outros testes que escrevemos para o Coral. Há outros testes mais interessantes lá. Embora não sejam muitos, já servem para dar uma boa idéia da abordagem que adotamos. Melhor ainda seria baixar o código e executá-lo em sua máquina. (Aqui explica como. )

Existem outros detalhes que poderiam ser explicados sobre a suite de testes do Coral. Como é uma suite que testa vários componentes de uma só vez (e não pequenas unidades, como sugere o nome “teste unitário”), precisa lidar com algumas outras questões – como a criação e execução do banco de dados, e a “montagem” dos componentes da aplicação – antes que os testes possam ser executados. (Essas “funções” são desempenhadas pela classe TestePadrao )
Outras abordagens

Embora outras abordagens possam ser mais eficientes ou completas, gosto muito dessa que testa, de uma só vez, vários componentes da aplicação. No caso do Coral, um único teste exercita serviço (objeto de negócio), DAO, e mapeamento Hibernate.

A primeira vantagem que vejo nessa abordagem é a de que se escreve menos testes. Com um esforço pequeno no inicio, é mais fácil convencer a equipe e a gerência a automatizar os testes.

Além disso, testes unitários costumam parecer inúteis para um programador que está começando. Ao escrever um teste para um método muito simples, cujo código se escreve mais rápido do que o próprio teste, o programador tem a impressão de que está perdendo tempo (é claro que não está), e acaba criando resitência com a prática.

Como os resultados da prática são mais visíveis após algumas semanas (quando se iniciam as mudanças no código), acho melhor começar com testes cuja utilidade é mais fácil de enxergar. Ao escrever um teste para um método de negócio complexo, envolvendo a integração de alguns componentes e acesso ao banco de dados, o programador vê mais nexo na prática, e se permite experimentá-la com mais boa vontade.

É claro que há a contrapartida: como um único teste exercita vários componentes, uma falha pode não apontar a causa do problema imediatamente, exigindo certo esforço de depuração. Entretanto, o simples fato de o teste detectar o erro já é benefício mais que suficiente para convencer os programadores da efetividade da prática.

Amadurecendo a prática

Depois que a equipe já está convencida dos benefícios de se automatizar os testes, é bem mais fácil abordar outras questões, como a granularidade, outras técnicas – como mocks – e o hábito de se escrever os testes antes do código.

Existem muitos outros artigos que abordam essas e outras questões relativas à prática de programação orientada a testes. A comunidade brasileira de agile tem produzido muito material bom a respeito e vale a pena conferir.

Listo aqui apenas alguns links de que me lembrei, para incitar a pesquisa mais detalhada. Esses artigos possuem links pra outros. Se lembrarem de mais algum, é só deixar um comentário.

Desenvolvimento orientado a testes
Introdução ao desenvolvimento orientado a testes
Andando de costas
Exemplo TDD, parte 1: Por onde começar

Falou!