Desenvolvimento Ágil - Blog da Improve It: Tag xp

Entrevista com Marcelo Alvim, do Projeto Lucidus

Vinicius Manhães Teles — Tue, 19 Aug 2008 15:16:00 -0300

Há algumas semanas eu entrevistei os desenvolvedores do Projeto Lucidus. Abaixo a entrevista com o Marcelo Alvim, que faz parte da equipe da Improve It no projeto:

Quem tiver iPhone pode ver a entrevista no YouTube.

Link direto para o vídeo.
Download .flv
Download .m4v

Download dos arquivos da palestra de Extreme Programming

Vinicius Manhães Teles — Thu, 14 Aug 2008 19:04:00 -0300

Na semana passada eu publiquei o vídeo da minha palestra de XP, na TDC 2008. Depois disso, algumas pessoas entraram em contato pedindo o arquivo com os slides da apresentação. Eles já estão no ar:

Download dos slides da palestra de Extreme Programming de Vinícius Manhães Teles.

Algumas pessoas tentaram fazer o download do vídeo, mas não conseguiram, por problemas com o Viddler. Fiz várias tentativas de disponibilizar a apresentação no Google Video, de onde também seria possível fazer o download. Entretanto, não consegui obter um resultado satisfatório e acabei tendo que parar com os experimentos por falta de tempo.

Infelizmente o vídeo é um arquivo bem grande. De modo que, se colocássemos para download aqui no próprio site da Improve It, o consumo de banda seria levado à estratosfera rapidamente. Em todo caso, talvez vocês possam ajudar nesta questão. Se tiver alguém aí que possa colocar o vídeo para download em um servidor, dentro de uma universidade, empresa, ou qualquer outra organização que não tenha maiores problemas com o consumo de banda, me avise.

Para aqueles que não assistiram a palestra ainda, aí vai um repeteco:

Link direto para o vídeo.
Download .flv
Download .m4v

A propósito, muito obrigado a todos os que assistiram e enviaram suas impressões. Confesso que estou impressionado e lisonjeado com a quantidade de pessoas que se interessaram e assistiram até o momento. Ele está há pouco mais de uma semana no ar e já foi visto mais de 3700 vezes.

UPDATE: O Igor Musardo gentilmente disponibilizou os arquivos da palestra para download em seu blog:

http://www.igormusardo.com.br/?p=65

Muito obrigado, Igor!

Entrevista com Ricardo Almeida na TDC 2008

Vinicius Manhães Teles — Fri, 08 Aug 2008 16:39:12 -0300

Abaixo mais uma entrevista realizada no dia 26 de julho de 2008, na TDC 2008. Desta vez foi com o Ricardo Almeida:

Link direto para o vídeo.
Download .flv
Download .m4v

Palestra de Modelagem Ágil, de Manoel Pimentel, na TDC 2008

Vinicius Manhães Teles — Wed, 06 Aug 2008 13:08:53 -0300

O vídeo abaixo contém a maior parte da palestra sobre Modelagem Ágil, do Manoel Pimentel, realizada no dia 26 de julho de 2008, na TDC 2008.

Link direto para o vídeo.
Download .flv
Download .m4v

Debate sobre Metodologias Ágeis na TDC 2008

Vinicius Manhães Teles — Tue, 05 Aug 2008 13:50:38 -0300

O vídeo abaixo contém a maior parte do debate sobre Metodologias Ágeis, realizada no dia 26 de julho de 2008, na TDC 2008.

Link direto para o vídeo.
Download .flv
Download .m4v

Palestra de Extreme Programming na TDC 2008

Vinicius Manhães Teles — Mon, 04 Aug 2008 10:35:41 -0300

O vídeo abaixo é da minha apresentação sobre Extreme Programming, realizada no dia 26 de julho de 2008, na TDC 2008.

Link direto para o vídeo.
Download .flv
Download .m4v

Nos últimos anos, ministrei palestras de XP em mais de uma centena de lugares diferentes, sendo a maioria no Brasil e alguns na Europa. O objetivo nunca foi ensinar cada detalhe do XP em apenas uma hora, mas apenas inspirar o público a estudá-lo melhor. Aprendi que é necessário mexer com as emoções para que cada pessoa presente saia da sua zona de conforto e procure conhecer melhor o XP quando voltar para casa. Isso explica a maneira pouquíssimo usual como a apresentação começa. Não fique chateado com o que você verá no início, saiba que este pequeno teatro, é apenas para prender a atenção do público, deixando-o inquieto e desconfortável.

Alguns de vocês já assistiram minha apresentação pessoalmente, mas talvez não tenham conseguido levar um amigo ou o chefe. Bem, agora as coisas ficaram mais fáceis. É só enviar o link deste post para quem você quiser. Mas, cuidado com a mensagem que você estará passando ao fazer isso. Veja o vídeo e você entenderá. :-)

PS: Ainda não dá para ver este vídeo no iPhone. Devido ao tamanho, não pude colocá-lo no YouTube. Minhas tentativas com o Google Video também não deram certo. A qualidade fica bem prejudicada, apesar de eu ter feito inúmeros experimentos, com diversos tipos de encoding. Embora eu não tenha gostado da qualidade, vou fazer o upload para o Google Video, para que haja uma alternativa para vocês verem o vídeo no iPhone (vídeos do Google Video funcionam no cliente YouTube do iPhone).

PS2: Embora eu tenha usado o Vimeo para o vídeo anterior, que também era grande e não podia ser colocado no YouTube e embora o Vimeo tenha a melhor interface de uso, na minha opinião, eu acabei migrando para o Viddler. Este último eu conheci através da palestra do Gary, na SEED3 (que aliás eu filmei e pretendo publicar). Tenho que concordar com ele que o Viddler é uma das melhores opções. Não só porque eu posso colocar vídeos de qualquer tamanho, com ótima qualidade, mas também porque é possível "etiquetar" cada etapa do vídeo. Com isso, você consegue saber rapidamente os assuntos tratados passando o mouse sobre os pontinhos que aparecem na barra de progresso. E, o que é melhor, você pode pular diretamente para os assuntos que mais te interessam.

Documentação Ágil

Vinicius Manhães Teles — Fri, 01 Aug 2008 21:08:00 -0300

Documentação é assunto que as pessoas vivem me perguntando nas palestras sobre XP. Por exemplo, como fica a documentação em um projeto XP, ou em qualquer metodologia ágil?

O vídeo abaixo é uma tentativa de responder esta questão.

Documentação Ágil from Vinicius Teles on Vimeo.

Link direto para o vídeo.

PS: Amigos com iPhone, não fiquem bravos comigo. Eu sei que vocês preferem que o vídeo esteja no YouTube, para que possam ver no iPhone. Mas, dessa vez ainda não deu. Este vídeo ficou um pouco maior do que eu gostaria, de modo que ultrapassa o limite de upload do YouTube. Uma alternativa é usar o Google Video, que permite vídeos maiores, e você também consegue ver através do cliente YouTube do iPhone. Eu tentei fazer upload para o Google Vídeo, mas ainda não ficou legal. Então, vou continuar tentando obter um resultado satisfatório no Google Video, e assim que alcançar, eu coloco o link aqui no blog. Mas, para adiantar, já estou publicando o vídeo no Vimeo.

Entrevista com Manoel Pimentel, da Revista Visão Ágil

Vinicius Manhães Teles — Thu, 31 Jul 2008 00:06:00 -0300

Continuando com as entrevistas que foram gravadas nas TDC 2008, agora é a vez do Manoel Pimentel, da Revista Visão Ágil:

Link direto para o vídeo.

Entrevista com Cicero Torteli, fundador da Paggo

Vinicius Manhães Teles — Sat, 26 Jul 2008 23:30:00 -0300

Acabo de chegar de São Paulo, onde participei da TDC 2008. O evento foi muito legal. Tive a oportunidade de rever vários amigos, entre eles o Cicero Torteli, fundador da Paggo, que falou sobre a adoção do Extreme Programming por lá:

Link direto para o vídeo.

Ainda sobre a Paggo, escute também o podcast que gravamos há algum tempo com Maurício Hermógenes, Diretor de Tecnologia da Paggo.

Há várias outras entrevistas que foram gravadas na TDC, bem como a minha apresentação sobre Extreme Programming, o Painel de Metodologias Ágeis, a apresentação do Manoel Pimentel sobre Modelagem Ágil e muito mais. Colocarei os vídeos no ar nos próximos dias.

Mais uma vez, gostaria de deixar meu muito obrigado ao Jorge Diz pelo convite para participar do evento, bem como ao apoio e a simpatia da Yara e do Vinicius, as mentes brilhantes que conduzem a Globalcode.

Episódio de hoje: priorização

Vinicius Manhães Teles — Fri, 25 Jul 2008 12:22:00 -0300

Hoje é dia de falar sobre priorização:

Link direto para o vídeo.

Em Julho: Ultra Maratona How To! Com cursos de Rails e XP!

Sylvestre Mergulhão — Sun, 06 Jul 2008 16:44:00 -0300

Nos dias 19 e 20 de julho teremos no Rio de Janeiro a I Ultra Maratona How To de Software Livre! É um evento com 20 tutoriais práticos de 4 horas cada. Terão desde cursos de utilização de BrOffice e Inkscape, passando por segurança de servidores, hardening e desenvolvimento. Para ver a grade completa acesse. Os preços são bem convidativos.

Eu serei tutor de dois. O primeiro, com nome de "XP Game e o Jogo da comunicação", será em conjunto com o Tapajos e a galera do Lucidus. No segundo estarei sozinho e será uma "Introdução ao Ruby on Rails".

Acesse já e faça a sua inscrição, as vagas são limitadas.

Novos rumos em 2008

Vinicius Manhães Teles — Wed, 19 Dec 2007 22:40:00 -0200

Resumo para aqueles que não terão tempo, nem disposição, para ler todo o post: a partir de 2008 a Improve It não irá mais prover serviços de treinamento, mentoring ou qualquer outro tipo de consultoria em desenvolvimento ágil. Continuamos acreditando fortemente nos métodos ágeis de desenvolvimento de software, mas o foco dos nossos negócios passará a ser o desenvolvimento de produtos.

O recado está dado. Provavelmente não é o que a maioria das pessoas espera de nós neste fim-de-ano, então, para quem estiver com tempo, a explicação segue abaixo. Senta que lá vem história.

A Improve It está completando seis anos. Iniciou suas operações no final de 2001 e, como qualquer outra empresa, precisa gerar lucro continuamente para manter-se viva. É possível montar um negócio lucrativo prestando serviços, ou apostando em produtos, ou fazendo as duas coisas. Logo no início, optamos por serviços.

Decidimos por serviços porque não tínhamos porte para investir em produtos no início. Produtos demandam tempo e investimento para serem criados, nutridos e promovidos. Serviço é diferente. Dependendo de seu networking e de suas habilidades, é possível começar a oferecer serviços em um dia e no seguinte já ter algum cliente. E foi exatamente o que aconteceu. Fechamos nosso primeiro trabalho rapidamente. Nossos primeiros clientes eram nossos amigos.

De lá para cá, sempre focamos exclusivamente na prestação de serviços, embora eu sempre tivesse algumas preocupações quanto a isso. A razão é simples: serviço não escala tão bem quanto produto. Em outras palavras, é possível ganhar bastante dinheiro com um produto, sem necessariamente ter uma quantidade enorme de pessoas na empresa. Exemplo óbvio é a 37signals. Eles conseguem crescer em faturamento, sem aumentar significativamente o número de pessoas. Lamentavelmente é difícil ou inviável fazer isso com serviços.

Para aumentar os ganhos oferecendo serviços, quase sempre é necessário ter muita gente. Veja à volta as empresas de TI que mais ganham dinheiro com serviços. Elas são enormes e têm um batalhão de funcionários. Isso me incomoda bastante, porque naturalmente desejo que a empresa cresça em faturamento e, sobretudo, lucro. Mas, não gostaria de ter que elevar significativamente a quantidade de pessoas. Pessoalmente, detesto empresas grandes. A última coisa que desejo para a Improve It é que ela cresça muito no número de pessoas.

O negócio que temos atualmente é saudável e, se decidíssemos continuar na mesma direção, provavelmente continuaria crescendo. Entretanto, estes seis anos me fizeram aprender algumas coisas. Em primeiro lugar, uma empresa precisa buscar negócios sustentáveis. Ou seja, precisa encontrar alguma forma de gerar receita continuamente, mês após mês.

Prestar serviços de consultoria, mentoring e treinamento é bom, mas não é tão sustentável quanto eu gostaria. A verdade é que ao longo do tempo, vivenciamos muitos altos e baixos. Às vezes, tínhamos vários trabalhos em um mês, às vezes passávamos meses sem trabalho algum. Cada vez os trabalhos se tornam mais constantes, mas, ainda assim, há muita volatilidade e imprevisibilidade na capacidade de gerar receitas. Além disso, a base de clientes é sempre pequena, o que significa que bastam um ou dois interromperem seus respectivos serviços, para gerar impactos significativos sobre nossas receitas.

Nestes seis anos, houve dois momentos que foram mais estáveis para nós. O primeiro aconteceu em 2003. Fizemos um projeto XP de pouco mais de um ano com a Vale. Foi um ótimo projeto em todos os aspectos. Além disso, foi lucrativo e nos manteve vivos durante um bom tempo. O segundo momento está ocorrendo agora, quando estamos envolvidos no Projeto Lucidus. Este é um projeto de 18 meses e ainda há metade dele pela frente.

Como se pode observar, em seis anos, apenas um terço do tempo estivemos envolvidos com negócios razoavelmente sustentáveis. Na maior parte do tempo, trabalhamos para sobreviver, como a maioria das pequenas empresas no Brasil.

No último ano e meio, passamos por algumas transformações que me fizeram refletir muito sobre a possibilidade de, finalmente, começar a direcionar os negócios para a área de produtos, ao invés de serviços. Ano passado, comecei a me envolver com o Rails. Quanto mais eu estudava e praticava, mais ficava claro para mim que havia uma oportunidade fantástica diante de nós. O Rails permite fazer muito mais, com muito menos. Além de tudo, é extremamente prazeroso trabalhar com ele. Isso é ótimo, mas não é suficiente.

Até meados do ano passado a Improve It era composta apenas por mim. Embora ela tenha sido fundada por três pessoas, meus sócios decidiram abandonar o negócio em 2004, alguns meses após o término do projeto da Vale. Na época, eles concluíram que dificilmente conseguiríamos fechar novos negócios, sobretudo do porte do que havíamos tido na Vale. Então, ambos decidiram coletar a parte que lhes cabia nos resultados financeiros do projeto e saíram da Improve It com o objetivo de trabalhar no funcionalismo público.

Na época tínhamos alguns funcionários e um escritório no centro do Rio. Não tive outra escolha, senão fechar o escritório, dispensar todas as pessoas e recolher-me ao conforto do meu lar. Fechar a Improve It não era e nunca foi uma opção para mim. Se eu fizesse isso, provavelmente teria que voltar a trabalhar em alguma empresa grande, ou, pior ainda, virar funcionário público em algum lugar. Esta última opção eu considero impensável, por inúmeras razões pessoais. Não fui feito para trabalhar nem em empresas grandes, nem em empresas públicas. Não importa o quanto elas paguem, meu perfil não casa com o delas. Então, o melhor que eu tinha a fazer era manter o negócio vivo, custe o que custasse.

De 2004 em diante, fiz inúmeros trabalhos de treinamento e mentoring em XP. Em 2006, voltei a contratar. Primeiro veio o Tapajós e logo depois o Marcelo. Este último, partiu logo em seguida para uma temporada de um ano nos EUA. Acabou de retornar. De lá para cá, vieram também o Felipe, o Leandro e o Rafael. Bons produtos precisam de pessoas talentosas para criá-los e é exatamente isso o que temos aqui. Somos cinco pessoas experientes, com muito conhecimento no que fazemos e muito talento. Nós não apenas sabemos como fazer. Nós sabemos fazer bem feito. E isso é essencial se quisermos fazer produtos bem sucedidos.

Outro pré-requisito fundamental é ter capital. Produtos demandam investimentos. É preciso colocar dinheiro antecipadamente, para que se possa criar algo que gere mais dinheiro futuramente (se tudo der certo). Quando começamos, não tínhamos muito capital. Mas, seis anos depois, temos o suficiente para investir durante algum tempo. Além disso, temos um projeto em andamento que continuará ajudando a pagar as contas por um bom tempo. Portanto, não há melhor momento para começar a trilhar novos rumos do que agora. Só falta um último detalhe, o mais difícil de todos.

Para que nós pudéssemos finalmente nos dedicar a produtos era preciso vencer a última barreira, aquela que eu carregava comigo o tempo todo. Eu teria que arrumar a coragem para deixar o passado para trás, ou seja, abandonar tudo o que viemos fazendo até aqui. Essa parte é bem mais difícil do que parece.

Estes últimos seis anos foram quase completamente dedicados a serviços na área de desenvolvimento ágil. Começamos muito cedo. Fomos pioneiros no Brasil e nos envolvemos nisso de maneira extraordinária. Meu envolvimento pessoal, em particular, foi notável. Fiz tudo o que eu podia para disseminar as técnicas ágeis no Brasil. Há cinco anos, fundei o XP Rio com mais três colegas. Ao longo dos anos, promovemos dezenas de reuniões presenciais e incontáveis debates na lista. Na UFRJ, passei a dar aulas de XP na graduação desde 2002. Foram seis turmas de XP entre 2002 e 2006. Tudo o que eu fiz na UFRJ até hoje foi voluntário. Nunca ganhei nenhum centavo pelas aulas. Nestes seis anos, fiz mais de cem palestras sobre desenvolvimento ágil no Brasil e no exterior, quase todas de graça. Viajei para lugares distantes, passei horas em ônibus e aviões para poder levar estes conceitos a pessoas que estivessem nas capitais, no interior, seja onde for. Em 2004, lancei meu livro que até hoje é o único escrito no Brasil sobre XP. Em 2002, participei do primeiro XP Brasil e em 2004, patrocinei o segundo XP Brasil. Paguei um quantia significativa que ajudou a trazer para o Brasil pessoas incríveis, como Mary e Tom Poppendieck e Scott Ambler. Em todos estes anos, é difícil contar a quantidade de mensagens que troquei nas listas. Algumas eram verdadeiros artigos, explicando detalhadamente cada aspecto do que fazíamos usando XP e outras técnicas. Aliás, também escrevi vários artigos em revistas, sites e, sobretudo, no próprio site da Improve It. Mais recentemente, estive pessoalmente envolvido na produção de inúmeros podcasts.

Diante de tudo o que eu fiz até hoje, não é muito fácil mudar. Primeiro porque a simples idéia de deixar tudo isso para trás é assustadora. Desenvolvimento ágil é algo que eu conheço profundamente. Poucas pessoas no Brasil têm vivência semelhante nesta área. Por isso, sou bastante procurado. É difícil passar um dia sem que haja uma mensagem de alguém querendo uma palestra, ou um curso, ou uma ajuda. E este é outro ponto que dificulta muito a mudança. Tem sempre alguma coisa para fazer aqui e ali. Alguma coisa que vai render um dinheirinho, mas não é o que vai resolver a nossa vida. Não é o que vai tornar o nosso negócio sustentável. Mas, é sempre atrativo, pois é algo no curto prazo.

Felizmente (ou infelizmente) algumas coisas começaram a acontecer no cenário ágil nacional, que não me deixaram particularmente feliz e que têm servido para me empurrar ainda mais para novos caminhos. Até o início de 2006, desenvolvimento ágil no Brasil era sinônimo de XP. Pouca gente conhecia outros métodos ágeis. Isso felizmente começou a mudar. Começaram a aparecer pessoas interessadas em estudar, divulgar e prover serviços em Scrum, FDD e Lean. Isso foi excelente, exceto por alguns detalhes.

Algumas pessoas passaram a atacar o XP como forma de vender as idéias de outros métodos ágeis. Isso me deixou particularmente chocado, não apenas pelo incômodo de ver algo que funciona imensamente bem ser difamado, mas sobretudo pelo tamanho da mediocridade e da burrice! A comunidade ágil no Brasil ainda é muito pequena diante do comunidade nacional de desenvolvimento de software. Todos nós lutamos por um mesmo ideal: deixar para trás os métodos tradicionais de desenvolvimento e caminhar na direção de algo que acreditamos ser mais humano, mais racional, que simplesmente funciona melhor, por uma fração do tempo e dos custos tradicionais. Nosso "inimigo" é o mundo tradicional. Se ainda somos um grupo pequeno, lutando para mudar o status quo estabelecido, qual o sentido de brigar entre nós mesmos? Qual o sentido de promover uma metodologia ágil através da difamação de uma outra? Enfim, comecei a ver estas coisas acontecendo e isso me entristeceu profundamente. É notável o quanto algumas pessoas conseguem ser pequenas, medíocres. Ao invés da união, a desagregação. Estratégia brilhante!

O passo seguinte também foi muito interessante. No final de 2006, fui procurado pelo Boris Gloger, da Sprint It para estabelecer uma parceria com o objetivo de promover o Scrum no Brasil através dos treinamentos de Certified Scrum Master (CSM). O Boris veio ao Rio, eu o levei para visitar alguns clientes e para fazer uma apresentação sobre Scrum no XP Rio. Foi ótimo contar com uma pessoa nova para reforçar alguns conceitos que já estávamos cansados de repetir por aqui. É sempre bom ter outra pessoa que possa falar dos assuntos, ainda que sejam os mesmos, de uma forma diferente.

Ficamos por aí, pois eu nunca tive interesse em me associar com nada que tivesse a ver com qualquer tipo de certificação na área de software. Ainda mais a CSM, que é notoriamente anti-ética e quase infantil. Para ser um CSM, basta pagar uma boa grana e passar dois dias em uma sala de aula. Não há provas, não há nada. Pagou e esteve presente, o certificado é seu. Parabéns! Eu nunca conheci nenhuma certificação na área de desenvolvimento de software que não fosse nociva, mas esta além de ter esta mesma propriedade, ainda consegue ser uma afronta à inteligência das pessoas.

Note que esta não é uma crítica ao Scrum. Longe disso. Trata-se de uma metodologia excepcional. É tão boa que faz parte do XP. O XP herdou toda a parte de gestão e planejamento do Scrum. Nós usamos isso o tempo todo, há anos e eu posso garantir: funciona muito bem! O que o Scrum tem para oferecer é absolutamente eficaz para desenvolvimento de software e para praticamente qualquer outra área do conhecimento. A minha crítica não é quanto ao Scrum, é quanto à certificação. Já falei muito sobre esta questão em outras oportunidades, então, não vou me alongar. Voltando ao caso do Boris, fiz o possível para ajudá-lo a promover o treinamento de CSM, mas nunca pela certificação, apenas pelo treinamento, que é ótimo. Em todos os casos em que eu ajudei a divulgar, deixei isso muito claro: vá pelo treinamento, mas não pela certificação, que não vale nada.

Um ano se passou e uma coisa interessante começou a acontecer. Scrum virou uma febre. Surgiram inúmeros cursos de Scrum pelo Brasil e isso é ótimo. Muitas empresas passaram a querer ouvir sobre desenvolvimento ágil através do Scrum e isso é ótimo. Gestores passaram a se interessar por desenvolvimento ágil através do Scrum e isto é excepcional. Percebi que, possivelmente, avançamos mais em desenvolvimento ágil no Brasil com Scrum, em um ano, do que em todos os anos anteriores com o XP. Por que será?

Em primeiro lugar, é necessário destacar o mérito comercial daqueles que foram alguns dos principais responsáveis por disseminar o Scrum no Brasil neste ano que termina. Juan Bernabo e Boris Gloger fizeram um excelente trabalho. Conheço o Juan pessoalmente, considero um amigo e admiro bastante. Nós pensamos de maneira muito parecida em vários pontos, exceto, naturalmente, na questão da certificação. Mas, isso não é nenhum problema. O Juan fez um trabalho belíssimo ao longo deste último ano e vem lutando para promover as técnicas ágeis no Brasil. Não é o único, mas passou a ter um papel excepcional ao longo deste último ano. Seu talento comercial também tem sido muito importante.

Na ascensão do Scrum, há também um segundo fator: os termos usados. A palavra Scrum é desconhecida no nosso vocabulário. Não apenas é uma palavra em inglês, como é também uma palavra que pouca gente sabe o que significa, mesmo em inglês. Isso é muito bom. Na verdade, isso é ótimo, pois não cria nenhuma resistência. Aliás, cria até uma certa curiosidade: o que será que siginifica Scrum? Como se isso não fosse suficiente, a metodologia é inteiramente regida por termos em inglês: sprint, scrum master, product backlog, sprint planning meeting etc. No Brasil, isto é perfeito. Quanto mais termos em inglês, melhor em se tratando de venda. Aqui as pessoas sempre acham que o que vem de fora é bom e o que é brasileiro é ruim. Então, nada melhor que termos em inglês e um nome que não gera resistências, ao contrário do Extreme Programming. Este último, não poderia ser pior. Consegue juntar duas coisas que dão arrepio nas pessoas: extremo e programação. Só pode ser ruim! :-) Quem não conhece, não quer conhecer e, para piorar, ainda aproveita para criar os mais diversos tipos de FUDs. Nessa linha, alguns assuntos são verdadeiros clássicos, como programação em par e documentação. Aliás, minha paciência para lidar com estes e outros FUDs já se esgotou.

Por fim, na questão do Scrum, a parte mais importante de todas: a certificação. Do ponto de vista comercial, aqui no Brasil, a certificação é uma jogada de mestre. As pessoas buscam, cada vez mais, todo tipo de selinho que puderem encontrar no mercado para colocar em seus currículos. É uma cultura insana, mas absolutamente pervasiva. Vai de pessoas a empresas. Todos estão atrás de um selo. Neste sentido, o Scrum dá as pessoas aquilo que elas querem. Querem poder ir para um curso de dois dias e poder sair de lá enchendo a boca para dizer: agora eu sou um Certified Scrum Master. Aliás, que expressão linda. Em apenas três palavras, temos um certified e um master. Normalmente, ser certified ou master em qualquer coisa já seria bom demais. Mas, a certificação de Scrum vai além. Por que ser uma coisa ou outra, quando é possível ser as duas: certified E master? Brilhante! É como dizer que uma pessoa não é apenas boa. É boa ao quadrado. É como dizer que você é ultra super powerful Yoda Ninja. Ou seja, o cara. E para ser tudo isso, basta passar dois dias fazendo um curso. A isca perfeita!

Neste ano que passou, vi coisas impressionantes relacionadas à questão da certificação. Talvez o mais bizarro tenha sido ver pessoas que eu conheço, que têm experiência de anos com métodos ágeis, correndo desesperadamente para trasformar-se em Certified Scrum Masters. Os caras pagaram uma nota, não para aprender o que eles já estavam carecas de saber e praticar, mas para, ao final, receber o selinho! Impressionante. É claro que alguma coisa nova eles devem ter aprendido, mas...

Volto a repetir, esta não é uma crítica ao Scrum, que é excepcional. É uma crítica à mediocridade das pessoas, à incrível necessidade que elas têm de um selinho como forma de dizer ao mundo que são "alguma coisa". Comercialmente, Scrum é brilhante justamente porque dá às pessoas exatamente o que elas querem: a oportunidade de pagar caro, para obter mais um selinho e, assim, deixar o currículo com mais uma sigla. Aliás, não só o currículo. Tem gente que conseguiu herdar o pedantismo hercúleo dos PMPs, os quais assinam seus emails com um ", PMP" ao lado de seus nomes. Agora temos também o ", CSM". Certamente isso se inspira nos doutores, que após uma jornada colossal pelo mundo acadêmico, finalmente podem assinar seus nomes com um ", PhD" ao lado. Para um doutor, isso já é pedante, mas para um PMP, cujo mérito não se compara ao de um doutor, isso é ridículo. Para um CSM... bem, deixa para lá.

À medida que este ano termina, algumas coisas ficam claras para mim. Primeiro, é preciso admitir que comercialmente XP é muito ruim. Há uma resistência enorme ao seu uso, baseada nas mais diversas interpretações equivocadas. A maioria das pessoas não sabe o que é, mas pelo nome, é melhor nem saber mesmo. Com certeza não é coisa boa. Segundo, não tem certificação, o que é um pecado capital neste país. Terceiro, demanda das pessoas, das equipes, das empresas, um nível de atitude social e comportamental que parece ser avançado demais para o pensamento pequenino que reina nas empresas brasileiras, com raras exceções.

Fico muito feliz com o avanço do desenvolvimento ágil no Brasil, seja ele através do Scrum, XP, FDD, Lean, ou qualquer outro método ágil. Nada do que comentei acima sobre o Scrum foi um fator determinante na decisão que estamos tomando neste momento. Foram apenas questões que nos ajudaram a refletir e compreender melhor o contexto em que estamos inseridos. Se continuássemos apostando apenas no XP, com certeza continuaríamos tendo espaço no mercado, como temos tido até hoje, só não teríamos um negócio tão sustentável quando gostaríamos.

A razão básica pela qual estamos mudando de rumos é o real desejo de buscar um futuro mais sustentável para a Improve It. Neste sentido, é inevitável pensar sobre o modelo da 37signals. Sem dúvidas esta empresa é, atualmente, nossa principal inspiração. Acreditamos ter as pessoas, o talento e o capital necessário para começar. Precisaremos de muito mais do que isso ao longo do caminho. Mas, por enquanto, precisamos apenas começar e é exatamente o que estamos fazendo agora. Adoraria poder fazer as duas coisas: continuar prestando serviços e, em paralelo, desenvolver produtos. Parece uma ótima idéia. Na prática, entretanto, descobrimos, a duras penas, que não dá. Somos poucos, temos tempo e recursos limitados. É preciso escolher e focar. Então, o foco é atender os clientes que já estão conosco e trabalhar em produtos. Novos clientes de serviços na área de desenvolvimento ágil não serão mais aceitos.

Na área de produtos, nos concentraremos em produtos web, cujo modelo de cobrança seja através de assinatura e que seja destinado a pessoas físicas, profissionais liberais e pequenos negócios. Por inúmeras razões, não queremos ter grandes empresas como clientes. Nosso objetivo é ter muitos clientes pequenos e, assim, pulverizar nossa fonte de receitas.

Já estamos trabalhando em um primeiro produto, mas só comentaremos sobre ele quando já estiver mais próximo ao seu lançamento. Em todo caso, os clientes potenciais não são da área de TI, portanto, vocês provavelmente irão conhecer o produto, mas dificilmente irão usá-lo. Trata-se de outro público-alvo, bastante diferente.

O site da Improve It sofrerá alguns ajustes nas próximas semanas. Como ele é uma referência bastante acessada por quem procura informações sobre desenvolvimento ágil, sobretudo XP, continuará no ar com todo o material que lá se encontra. Porém, faremos algumas mudanças com o objetivo de não mais promover os serviços que oferecemos atualmente e deixar claro que estamos saindo deste segmento.

Muito obrigado a todos os que estiveram envolvidos conosco até aqui. Foi bom estar com vocês, mas estamos arrumando as malas e, a partir de 2008, nossa jornada segue em outra direção. Aos que permanecem nesta estrada, desejamos muito sucesso e um 2008 de grandes realizações. Que os métodos ágeis avancem rapidamente pelo Brasil!

Rio on Rails 2007

Vinicius Manhães Teles — Tue, 11 Dec 2007 19:59:00 -0200

No último sábado aconteceu o Rio on Rails 2007 e no dia seguinte embarquei em uma longa e cansativa viagem para o interior do Paraná, onde estou fazendo um mentoring em XP e Rails. Só agora consegui forças para escrever aqui no blog.

O Rio on Rails foi muito legal. As palestras foram todas de ótimo nível e o dia foi bem descontraído. Tive a oportunidade de conhecer algumas pessoas novas e rever outras que já vinha encontrando nas semanas anteriores, nos eventos que ocorreram em São Paulo, Bauru e Belo Horizonte.

Gostaria de deixar aqui o meu muitíssimo obrigado ao Senac e aos amigos da Improve It que ajudaram na organização, sobretudo o Tapajós e o Leandro, cujo pimpolho nasceu na última sexta-feira, razão pela qual ele não compareceu (parabéns, Leandro!). A ajuda de vocês foi essencial. Também quero reforçar meu imenso agradecimento aos palestrantes, principalmente àqueles que fizeram todo o esforço para vir de outras cidades. Finalmente, meu muito obrigado ao público, que apostou no evento e participou ativamente durante todo o dia. Naturalmente, obrigado especial àqueles que vieram de outras cidades, tais como São Paulo e Belo Horizonte, entre outras, para prestigiar o evento.

Em 2002, pouco depois de fundar a Improve It, tomei contato com o Extreme Programming e isso teve um impacto muito positivo no meu trabalho e, sobretudo, na minha satisfação com o desenvolvimento de software. Foi um marco importante para mim e colhi inúmeros frutos a partir do meu envolvimento nesta área. No ano passado, quando comecei a conhecer e trabalhar com o Rails, revivi os sentimentos de quando comecei com o XP. O Rails vem sendo responsável por uma transformação na Improve It e por uma satisfação ainda maior com o ato de desenvolver software. Cada dia eu gosto mais de programar em Ruby e de desenvolver sistemas web em Rails. O Rio on Rails foi uma forma de permitir que outras pessoas também comecem ou continuem a experimentar essa mesma satisfação agradável de desenvolver software de forma ágil, leve e descontraída.

Espero que o evento tenha atendido às expectativas e desejo rever todos vocês em 2008! Continuem nos trilhos! :-)

Extreme Programming e Ruby on Rails em Bauru

Vinicius Manhães Teles — Fri, 30 Nov 2007 12:20:00 -0200

No último sábado estive em Bauru (SP), onde eu e o Fábio Akita estivemos presentes para um evento sobre Extreme Programming e Ruby on Rails. O evento foi organizado por Lucas Húngaro e Guilherme Alves, ambos da UNESP de Bauru (SP). Na parte da manhã eu falei sobre XP e na parte da tarde o Akita falou sobre Rails.

O evento foi muito bacana. Agradeço ao Lucas Húngaro pelo convite e espero que minha apresentação tenha sido proveitosa. O Lucas publicou as fotos do evento.

Amanhã a maratona continua. É dia de Minas on Rails.

Saldo do Imersão Ágil de Juiz de Fora

Vinicius Manhães Teles — Fri, 30 Nov 2007 08:02:00 -0200

Este mês de novembro foi bastante intenso para nós. Por esta razão, quase não consegui escrever aqui no blog e não tivemos novos podcasts.

Entre os dias 5 e 9 de novembro estive em Juiz de Fora (MG), onde estudantes, professores e profissionais da região formaram uma turma do treinamento Imersão Ágil. Eles conseguiram um laboratório emprestado, em uma faculdade e, juntos, bancaram o valor do treinamento que normalmente é destinado apenas a empresas. Veja as fotos.

Este é um modelo bastante interessante. No Brasil inteiro, existem inúmeras cidades onde as pessoas gostariam de receber treinamento, mas os mesmos só são oferecidos, tipicamente, nas grandes capitais, sobretudo Rio e São Paulo. A idéia de formar um grupo na própria cidade, arrumar um local para o treinamento e chamar o instrutor é muito válida e significativamente mais econômica para todos os envolvidos.

O curso foi muito proveitoso. Veja o que os alunos disseram:

"O curso é realmente empolgante pois quebra todos os paradigmas sobre XP que você 'ouviu alguém dizer' pra mostrar na prática que é possível desenvolver software de verdade, de forma organizada e menos buRRocrática.

Acredito que foi essencial para descobrir como, com práticas relativamente simples, é possível elaborar sistemas complexos e de qualidade, sem se atolar em quilos de documentações desatualizadas.

Felizmente algumas empresas já perceberam que alguns modelos de desenvolvimento simplesmente são inviáveis, pois o tempo não espera, o cliente também não. Quero agradecer ao Vinícius pela sua humildade em partilhar do seu conhecimento conosco, pela atenção em cada minuto que parou a aula, ou abdicou do seu lanche pra tirar todas as nossas dúvidas a respeito.

Não o conhecia nem através do seu livro, e encontrei a Improve It pelos podcasts, e te digo, virei um admirador do seu trabalho de carteirinha.

Porque realmente você sabe do que fala, domina o assunto e tem experiência, deixo aqui meu muito obrigado e espero agora poder levar esse conhecimento a outras pessoas."
Bruno Oliveira da Silva
Veja também o que o Bruno escreveu sobre o Imersão Ágil em seu blog.

"O Treinamento Imersão Ágil foi muito bom para meu aperfeiçoamento profissional. Esse treinamento me ajudou bastante a entender o XP. Gostei de nossas discussões e de sua didática. Recomendo."
Camillo de Lellis Falcão da Silva

"O Treinamento Imersão Ágil é um curso que consegue misturar tanto a parte teórica quanto as dinâmicas que possibilitam ter uma visão na prática sobre o XP e que faz a gente se envolver de modo descontraído com o assunto mostrado em aula. XP é uma metodologia bem diferente do que nós, que já trabalhamos com desenvolvimento de software, estamos acostumados, por isto este curso traz uma certa mudança de visão e paradigma para quem está envolvido com outras metodologias."
Jeferson Luis Gonçalves

" O curso abriu novos horizontes para o desenvolvimento em equipe e mostrou uma outra abordagem sobre o desenvolvimento de softwares. Foi um curso muito prático, com uma dinâmica bem interessante e eficiente. Os casos de sucessos abordados durante o curso fazem com que tenhamos vontade de aplicar isso de imediato em nossas equipes de desenvolvimento. O lado prático, eficiente e ágil de uma equipe é invocado todo o tempo, além de permitir a interação e a satisfação do cliente que é o objeto de nosso desenvolvimento."
Marcos Alexandre Miguel

"Com o curso aprendi que desenvolver software vai mais além que tecnologia, e em uma equipe de desenvolvimento, todos temos que nos unir para chegarmos a um trabalho com qualidade.
Não poderei colocar todos os ensinamentos aprendidos em prática, pois sou o único na equipe (risos), mas já consegui um grande avanço, pois com as suas idéias de cartões consegui aproximar meu cliente. Assim, estou conseguindo desenvolver módulos mais eficientes sem desgastar-me com reuniões prolongadas.
Outro ponto interessante foi a didática, pois houve uma grande interação entre os integrantes através das técnicas exercidas no curso. Assim, o aprendizado tornou-se mais claro e interessante."
Samuel Vieira Pinto

Se você também quiser montar uma turma do Imersão Ágil em sua cidade, entre em contato!

Improvecast 22: Entrevista com Edson de Lima

Vinicius Manhães Teles — Fri, 02 Nov 2007 17:02:00 -0200

Acaba de ser publicado o Improvecast 22 no qual entrevistei Edson de Lima, que falou sobre a implantação do Extreme Programming na LeoSoft, uma empresa do Paraná que contou com o treinamento Imersão Ágil há alguns meses e está trabalhando com o XP desde então. Eu havia escrito há algum tempo sobre como foi o Imersão Ágil na LeoSoft e o pessoal de lá nos concedeu este depoimento. Se quiser, você também pode ver as fotos do treinamento.

Falamos sobre diversos assuntos relacionados à adoção do XP e também sobre a implantação do MPS.BR na LeoSoft. Antes do treinamento Imersão Ágil, a LeoSoft havia iniciado um processo de implantação do MPS.BR junto a outras empresas da região. Algum tempo após o Imersão Ágil, começou de fato a implantação do MPS.BR em um dos projetos da empresa. Isso está sendo um desafio, visto que a filosofia do MPS.BR é, em vários aspectos, bem diferente da filosofia do Extreme Programming. Esta é uma das questões que discutimos no Improvecast 22. Se você quiser saber mais sobre o MPS.BR, escute o Improvecast 8.

Ouça a entrevista com Edson de Lima!

Improvecast 21: entrevista com Demetrius Nunes

Vinicius Manhães Teles — Fri, 26 Oct 2007 11:32:00 -0200

Na última quarta-feira entrevistei Demetrius Nunes para o Improvecast 21. Demetrius atua como Gerente de Projetos no Grupo de Tecnologia em Computação Gráfica da PUC-Rio, o TecGraf. Lá ele utiliza Scrum e práticas de outras metodologias ágeis, tais como Extreme Programming e Lean Software Development. Demetrius também desenvolve usando Ruby on Rails e foi um dos primeiros desenvolvedores Rails do Rio de Janeiro. Ele é autor do act as taggable e será um dos palestrantes do Rio on Rails.

Veja o Improvecast 21.

Novas fotos no ar

Vinicius Manhães Teles — Mon, 15 Oct 2007 12:59:00 -0200

Acabamos de publicar diversas fotos com a nossa participação em conferências de desenvolvimento ágil e outros eventos relacionados. As fotos são antigas, mas eu nunca conseguia tempo para colocá-las no ar. Finalmente consegui fazer isso e espero que vocês gostem. :-)

Os álbuns publicados foram:

XP 2006 (Finlândia) - dia 1, dia 2, dia 3 manhã, dia 3 tarde, dia 4 manhã, dia 4 tarde, dia 5
Workshop de Desenvolvimento Ágil na Segula (Portugal)
XP Brasil 2004
XP Brasil 2002

Barrigas abertas

Vinicius Manhães Teles — Thu, 11 Oct 2007 10:08:00 -0300

O Marcelo Baltar fez alguns comentários, nesse artigo, sobre a utilização do CruiseControl no processo de integração contínua e eu gostaria de levantar algumas considerações. Preferi fazer isso através de um novo artigo. O Marcelo cita o seguinte:

"Parabéns, mais um excelente post. Mas devo dizer que eu também tenho uma preferência pelos testes assíncronos (CruiseControl-like ;) ). Além das questões técnicas, já bem exploradas no seu post e em alguns comentários, esse tipo de abordagem aproxima-se mais dos conceitos pregados pelas metodologias 'ágeis'.

No meu entender é mais proveitoso o desenvolvedor 'commitar' seu trabalho o quanto antes (lógico, com os devidos testes implementados) e já avançar para as próximas tarefas ao invés de ser obrigado a passar por todo esse processo de integração 'pré-commit'. Afinal de contas, quão realmente grave/problemático seria o commit de código que quebra o que está no repositório? Pela minha experiência, isso acontece pouquíssimo, e quando acontece, graças a granularidade dos commits, pode ser facilmente corrigido."

Marcelo, muito obrigado pelo comentário. Compreendo sua percepção de que o uso do CruiseControl possa estar mais associado a metodologias ágeis, porém não compartilho essa mesma visão. Acredito que isso tem a ver com a interpretação do que seja uma "metodologia ágil". Não sei se você chegou a ler o artigo sobre agilidade x Agilidade. O termo "ágil" não está associado apenas ao conceito de velocidade, mas sim ao Manifesto Ágil e seus princípios.

Um dos valores fundamentais no mundo ágil é feedback. Receber feedback cedo e agir sobre ele rapidamente. A forma de receber feedback e atuar sobre ele é diferente dependendo se você utiliza um modelo de integração síncrona ou assíncrona. No assíncrono, o feedback tende a ser mais demorado e pode passar despercebido. Por exemplo, se ele vier por email, pode ser que o desenvolvedor não esteja consultando os emails com freqüência. Isso é comum de acontecer em XP, por exemplo, devido à programação em par e outros fatores.

Desenvolvimento ágil também está relacionado a entregar software funcionando. Então, cada novo código introduzido no projeto tem que estar funcionando para gerar valor de verdade. Por essa razão, o código que vem do repositório tem que estar em ordem permanentemente. O uso de uma ferramenta como o CruiseControl, pelas razões descritas acima, permite a existência de código quebrado no repositório. Ele não leva a isso, mas permite.

Nos projetos que eu conheci, que utilizavam CruiseControl, era comum o repositório estar quebrado. A razão era sempre alguma coisa "boba" que ia ficando lá porque ninguém queria parar para consertar. Nós aqui chamamos isso de "barriga aberta". Pense em um cirurgião. Quando ele vai operar uma pessoa, ele abre a barriga, faz o que precisa ser feito e fecha, antes de partir para outra cirurgia. Ele não abre a barriga de um, começa a operar e, em seguida, abre a barriga de outro antes de terminar a primeira cirurgia (como ilustrado abaixo). Ele sabe que isso seria perigoso e improdutivo. Nós não. Nós somos de computação, então a gente adora fazer aquilo que parece rápido, mas costuma gerar dores de cabeça mais adiante. :-)

Ilustração de Leandro Mello.

Na minha opinião, fazer um commit e partir para outra atividade, antes de receber feedback sobre o que foi colocado no repositório é o mesmo que "deixar uma barriga aberta". Para nós, desenvolvedores, que estamos sempre ansiosos para passar para a próxima atividade, é tentador demais seguir com o próximo cartão, mesmo enquanto ainda há pendências no atual. E o modelo de integração assíncrona permite isso. Já a integração síncrona, não. Ela obriga o desenvolvedor a parar momentaneamente, ter certeza de que tudo correu bem e só então prosseguir para a próxima atividade. Isso está alinhado a um princípio do XP chamado passos de bebê. Acredito que o importante não seja a velocidade com que partimos para a próxima atividade, mas sim quão rápido conseguimos entregar código que temos certeza de estar funcionando.

Outra questão, também ligada ao feedback é o próprio tempo de execução dos testes. A integração síncrona, para funcionar, exige testes que executem rapidamente. Mais de cinco minutos para integrar já é um problema. Kent Beck costuma dizer: se essa atividade é difícil, execute-a freqüentemente. Fazer builds que executem rapidamente é desafiador. É algo que exige atenção permanente. A integração síncrona nos obriga a ter essa atenção e nos leva a melhorar os testes quando o tempo cresce. Na assíncrona, é fácil demais deixar os testes demorarem cada vez mais e não fazer nada a respeito.

No meu entender, essa é uma questão sistêmica, ou seja, no curto prazo, trabalhar com o CruiseControl pode parecer uma boa idéia, pela aparente velocidade que ele traz ao processo de integração. No médio e longo prazo, entretanto, o comportamento da equipe, influenciado pelas facilidades oferecidas pelo CruiseControl, atrapalham o projeto. Digo isso com base no que pude observar em projetos que usavam o CruiseControl. Entretanto, cada projeto é uma realidade. Se no seu caso o CruiseControl funciona e não causa os problemas sistêmicos que mencionei, use-o. No meu caso, ainda prefiro a integração síncrona.

Nosso processo de integração contínua

Vinicius Manhães Teles — Fri, 05 Oct 2007 09:45:00 -0300

O Lucas Húngaro deixou-nos um comentário pedindo que escrevêssemos sobre nossa infra-estrutura de controle de versão, integração contínua, testes unitários e cobertura de código para projetos Rails. Ótima pergunta! Muito obrigado, Lucas.

Nós utilizamos o Subversion como repositório e optamos por um modelo de integração contínua síncrono. Isso significa que toda vez que um desenvolvedor precisa integrar, ele roda uma script do Rake que faz o update do código, executa todos os testes, verifica a cobertura de código e, se tudo estiver em ordem, faz o commit do código.

Nós trabalhamos com 100% de cobertura em todos os projetos. Para isso usamos o Rcov. O script de integração executa a análise de cobertura antes de cada commit e cancela a integração caso o desenvolvedor tenha esquecido de fazer os testes para um código recém-introduzido.

A integração síncrona obriga o desenvolvedor a aguardar a execução do script de integração, antes de partir para outra tarefa de programação. Isso é bom porque evita que a gente comece outra coisa antes de saber que fizemos corretamente a atividade corrente. Além disso, ter que esperar pela execução do script nos leva a ter atenção permanente com o tempo de execução dele. Se crescer muito, a gente o aprimora para reduzir o tempo. No geral, tentamos manter o tempo de execução sempre abaixo dos cinco minutos.

O contrário da integração síncrona é a assíncrona, que utiliza algum servidor, como um CruiseControl. Nesse caso, o desenvolver faz o commit, o qual dispara um script no servidor do CruiseControl. Ele executa todos os testes e demais verificações enquanto o desenvolvedor já passou para outra atividade. Algum tempo depois ele recebe um email ou outro tipo de notificação avisando se tiver acontecido um erro. É um modelo interessante em várias circunstâncias, mas nos projetos que fazemos tentamos evitá-lo. James Shore escreveu um excelente artigo que resume as razões para não usar o CruiseControl. Nossas razões são basicamente as mesmas.

Para os testes unitários, utilizamos o Test::Unit, naturalmente, além do Mocha para os mock objects e o Selenium on Rails para os testes de aceitação.