Desde o ano passado estou escrevendo apenas no meu outro blog. Estou morando na Inglaterra e manter dois blogs simultaneamente ficou complicado. O Victor Hugo e o Rafael que me deram uma força aqui também estão tocando apenas seus próprios blogs. Ou seja, é hora de atualizar seu leitor de feeds:

• Meu outro blog é o isanchez.net (RSS / twitter)
• O Victor Hugo escreve na Maldita Comédia (RSS)
• O Rafael Mueller escreve no Quero Ser Ágil (RSS / twitter)

Se você está interessado nas reuniões do Dojo Floripa, elas continuam acontecendo regularmente e a maneira mais fácil de participar é através da lista de discussão.

Obrigado a todos que leram, comentaram e principalmente aos que acreditaram nas ideias sobre Coding Dojo que eu tentei colocar aqui nesses últimos anos. Hoje em dia assino a maioria das listas dos dojos espalhados pelo Brasil e me alegra bastante ver como esta idéia evoluiu desde quando tivemos nossa primeira reunião.

Enfim, nunca pensei que iria escrever um post de encerramento aqui mas, já que estamos todos fora, por que não pelo menos apagar a luz?

Olá Pessoal,

Em janeiro, o Curso de Sistemas de Informação da FACENSA (Gravataí), juntamente com o Grupo de Usuários de Metodologias Ágeis (GUMA-RS) estará promovendo uma palestra beneficente sobre Metodologias Ágeis de Software. O assunto trata de um conjunto de metodologias de desenvolvimento de software que trabalham baseadas em um conjunto de princípios e valores, e baseadas em foco no cliente, na equipe e geração de resultados com métricas e atitudes que promovem a melhoria contínua.

Esta palestra vai trazer aos participantes uma introdução ao assunto, permitindo o debate e discussão dos tópicos tratados.

Data: 06 de janeiro de 2009, às 19h30min. A palestra tem duração de 3 horas.

Para esta ação, o Curso de Sistemas de Informação/FACENSA está arrecadando alimentos não perecíveis. A inscrição para a palestra é feita a partir da doação de 2Kg de alimentos. Os alimentos arrecadados serão doados para o Asilo Santa Bárbara (Gravataí).

Mais informações no blog do grupo XP – Rio Grande do SUL.

Phillip Calçado:

[...] What James describes in his text is what we, consultants, see every single day.

Rafael Mueller:

[...] Tá cheio de consultor por aí pronto para quebrar os valores ágeis somente para ganhar um dinheiro da sua empresa.

Victor Hugo Germano:

[...] São os princípios, e não os métodos, que decidirão sobre a sobrevivência dos projetos

José Papo

[...] Scrum é apenas a porta de entrada para a agilidade. Uma equipe que não evoluir além disso, com certeza irá fracassar.

Manoel Pimentel

[...] Não existe uma só forma de agilidade [...] Será que não há espaço para todas essas vertentes da agilidade?

Fernando Meyer

[...] não é trazendo um evangelista e adotanto Scrum para sua empresa que fará seus projetos darem certo, mas se e somente se as pessoas envolvidas acreditarem no que estão fazendo.

Frank Trindade:

[...] O problema acontece quando tudo isso se torna muito na moda e popular, o que leva um monte de gente a adotar metodologias ágeis sem ter muita noção do que está fazendo.

Guilherme Chapiewski:

[...] muitas pessoas na comunidade – assim como eu – têm receio que realmente estejamos entrando numa era de declínio das metodologias ágeis causada pelo seu mal uso e péssimo entendimento.

Minha opinião continua a mesma então não vou entrar na discussão. Ao invés disso vou tentar manter este post atualizado com outros posts que eu encontrar por aí. Estou curioso para saber o quanto esta discussão vai mudar a cara da comunidade brasileira

Atualizado! Mais algumas opiniões: Fernando Meyer, Frank Trindade e Guilherme Chapiewski (se souberem de mais alguém me avisem!)

• Versão em PDF para imprimir
• Um wiki FitNesse executável
• Um wiki on-line

A melhor maneira de acelerar Selenium é usar menos Selenium

Ou seja: use mais testes de unidade, mais testes de integração e dependa menos dos testes a partir da interface com o usuário. Use Selenium apenas para validar a navegação, mas não regras de negócios. E, finalmente, use Page Objects, porque pior do que testes difíceis de se executar são testes difíceis de se manter.

Depois de falar com o Gojko já fui incluído no projeto e estou traduzindo os primeiros capítulos. Se você quiser ajudar da tradução, pode começar dando uma olhada nos fontes que estão no projeto do Source Forge e entrar em contato comigo via comentários ou e-mail se quiser botar a mão na massa. Qualquer um pode ajudar.

Ah! O documento foi feito usando DocBook, então se você se interessa pela ferramenta também é uma boa maneira de aprender um truque ou outro…

As reuniões do dojo não precisam muito mais que um computadores e um projetor emprestados. Pagar pizza e umas cervejas para o final das reuniões também não sai caro, e com certeza é muito bem-vindo. Agora, se a empresa for bacana mesmo, pode-se tentar algumas reuniões no horário de trabalho para incentivar que mais pessoas participem. Nada disso custa rios de dinheiro, nem é muito complicado. Só é preciso um pouco de iniciativa por parte dos desenvolvedores e bom senso em investir nas pessoas por parte da empresa.

2. Estimula habilidades sociais e de auto-organização

Muitos desenvolvedores têm alguma dificuldade para falar em público, expor suas idéias e colaborar com outras pessoas. Outros têm dificuldade de se organizar, trabalhar em equipe ou até mesmo liderar. Quando é que uma empresa investe neste tipo de habilidade de um desenvolvedor? Raramente. O dojo é um ótimo começo para estas pessoas, e mesmo quem não possui nenhuma dessas dificuldades acaba tendo a chance de aprender coisas novas e explorar pontos que precisa melhorar.

3. É publicidade para a empresa

Se a empresa já deu o primeiro passo e os desenvolvedores estão confortáveis com a rotina do dojo, por que não abrir as portas para outras pessoas? O nome da empresa vai ficar associado aos princípios ágeis por trás do dojo e ninguém terá que sair do escritório para fazer networking. E de quebra, pode ser que nem precisem mais postar anúncios de emprego por aí, já que candidatos em potencial já farão parte da rotina da empresa.

4. Incentiva os desenvolvedores a participarem da comunidade

Divulgando o dojo da sua empresa em listas de discussão e fóruns das tecnologias que são aplicadas nas reuniões podem dar um incentivo a mais para os desenvolvedores trocarem idéias na comunidade de desenvolvimento de software em geral. Além disso pode ser o primeiro passo para participação em projetos open source, publicação de artigos e participação de conferências.

5. Quebra a rotina

Programar algo diferente dos projetos do dia-a-dia, em outras linguagens, usando outras técnicas, com outras pessoas e numa dinâmica bem mais informal do que os projetos das empresa exigem pode ser muito estimulante no final das contas.

Então, será que precisa de mais motivos? Infelizmente não estou mais no Brasil para poder participar das reuniões que estão acontecendo por aí, mas ficarei muito contente em ajudar qualquer um que queira botar um dojo em prática no seu ambiente de trabalho. As listas do dojo de SP e Floripa também estão de portas abertas para tirar dúvidas e incentivar essa idéia.

Primeiro conheci no Google Open Source Jam o pessoal de uma empresa que está fazendo dojos internos e me convidaram para participar. E não é que foi um dos melhores dojos que já participei até hoje? Organizar dojos dentro de uma empresa tem várias peculiaridades, mas isso é assunto para outro post…

Na semana seguinte aconteceu o primeiro dojo na empresa onde eu trabalho. Infelizmente minha organização foi precária e não pude avisar com antecedência o suficiente para o Danilo Sato do Dojo SP poder participar, porém acabamos contando com a visita de um outro programador de fora. Foi bem divertido também e agora estamos tentando tornar o dojo algo mais rotineiro.

Enfim, depois de quase 7 meses sem participar de reuniões do dojo, finalmente estou voltando à ativa!

Ah! E se você nunca usou FitNesse, talvez esteja na hora de dar uma olhada. Na pior das hipóteses é uma excelente ferramenta para escrever testes de maneira expressiva. No melhor caso, é uma ótima ferramenta de comunicação entre desenvolvedores, clientes e testers.

Começamos aos poucos, um conceito aqui, outro ali, vendendo os princípios tanto para desenvolvedores quanto para gerentes. Antes mesmo do primeiro projeto terminar os resultados foram tão visíveis que dali foi só questão de tempo para o perfil da empresa mudar de CMM “wannabe” para XP “addicted”.

A luta, nessa época, era convencer justamente quem constrói software que desenvolvimento ágil era uma boa idéia. Todo mundo questionava não ter fases bem definidas, não produzir toneladas de documentação ou não estabelecer um processo detalhado para executar um projeto de software qualquer. Fábrica de software era o futuro, grandes consultorias eram o futuro, especialização era o futuro.

Engraçado ver como hoje desenvolvimento ágil já virou senso comum. A agilidade que surgiu com o Manifesto Ágil caiu na boca do mercado e já virou mais uma ferramenta de marketing para vender projetos e imagem de empresas.

Ninguém mais questiona se vale a pena passar meses escrevendo diagramas UML antes da primeira linha de código. Ninguém pergunta se deve esperar o sistema estar construído antes de começar a testar. Em compensação agora se discute muita sobre certificações (conceito nada ágil, diga-se de passagem) enquanto a quantidade de treinamentos sobre o assunto aumenta assustadoramente.

E o melhor: quem até alguns anos atrás questionavam substituir anos e anos de conhecimento tradicional de engenharia de software por práticas muito mais humanistas para construir sistemas são os mesmos que hoje fazem de tudo para trabalhar num projeto que aplique estas práticas. Ou que ao menos envolvam Scrum ou TDD.

Acredito que desenvolvimento ágil já atingiu o seu auge. Já cumpriu seu papel e revolucionou a maneira de pensar sobre software. Agora é ladeira abaixo.

Muita empresa já está usando a palavra ágil só para contratar mão-de-obra ou vender seus projetos, agora que sua “linha de montagem” já foi substituída por um modelo incremental e iterativo. A crista da onda de buzzwords hoje em dia é Scrum, enquanto o que segura a barra ainda é a (já) boa e velha XP.

E se tudo der certo em pouco tempo a maioria das faculdades vai estar ensinando bastante sobre desenvolvimento ágil, o que infelizmente é a prova que o conceito já não é mais nenhuma novidade.