Pular para o conteúdo principal

Reflexões sobre o Agile Brazil

Duas semanas atrás, participei do Agile Brazil, um grande evento da comunidade antenada com metodologias ágeis, que aconteceu em Porto Alegre. Participei apenas dos dois dias de palestras, não dos cursos que antecederam o evento, que segundo relatos foram ótimos. O pessoal da organização está de parabens: o nível técnico do evento foi excelente e os mais de 800 participantes em geral se mostraram muito satisfeitos com o que viram.

Por sorte, a minha palestra "Testar: impossível" foi logo no início do evento, de maneira que consegui curtir melhor o restante do evento. Alguém falou para mim que não acreditava que testar fosse impossível: nem eu, mas tentei passar a ideia de que testar não é trivial, ilustrado por uma imagem inicial inspirada no mito de Sísifo. Surpeendentemente para mim, o auditório da palestra lotou, apesar de haver 5 sessões simultâneas, até com palestrante internacional. Bom, afinal eu também sou internacional...

Acredito que o interesse da plateia se origina nas dificuldades práticas de aplicar testes quando os testes começam a ser levados à sério, que é uma característica esperada em organizações transicionando para desenvolvimento ágil. Não há agilidade sem testes.

A cada evento, percebe-se que as pessoas trazem mais questões práticas e que cada vez há menos interesse em apresentações do tipo "Agile é o máximo". Quais foram os temas mais falados no evento ?

Do meu ponto de vista (obviamente parcial), houve um número expressivo de palestras falando sobre testes. Boa parte da trilha de engenharia foi tomada por assuntos relacionados a testes.

Arquitetura foi outro tema que teve um grande apelo: ficou superada a ideia de que uma arquitetura emergisse espontaneamente sem haver algum tipo de trabalho prévio. Estamos tentando achar um equilíbrio que não inclua arquiteturas mirabolantes, genéricas e de aplicação supostamente universal nem a fé injustificada na geração espontânea de uma arquitetura consistente a partir do nada.

Relativização da aplicação de metodologias, principalmente Scrum, "by the book". Comparando, por exemplo, com as duas edições do Ágiles (Baires 2008 e Floripa 2009), parecia haver um consenso quase geral (meio "bala de prata") a favor do Scrum de carteirinha. A ideia de "Scrum but" ser necessariamente algo ruim está sendo contestada, sem que o palestrante que faz tal afirmação corra o risco de ser queimado na fogueira por blasfêmia.

As práticas de eXtreme Programming estão voltando a ser valorizadas. Muitas equipes estão descobrindo que não podem deixar de lado as práticas técnicas, e XP articula muito bem uma dinâmica que aproveita a sinergia entre essas práticas. Entre estas, falou-se bastante de integração contínua e de deploy contínuo.

Outro assunto recorrente, derivado também do esquecimento temporário da necessidade de investir na excelência do ofício, foi o da dívida técnica. Participei de uma muvuca ("open space"), convocada por Philippe Kruchten, onde este assunto foi destrinchado.

Causou bastante impacto a palestra do Klaus Wuestefeld, uma das últimas, que retomou o espírito de quando Agile era novidade. Para quem não conhece, o Klaus foi pioneiro na implantação de práticas ágeis no Brasil. Ele organizou os dois primeiros eventos sobre o assunto: XP Brasil 2002 e 2004, nos quais tive a honra de palestrar. Naquela época, "agile" não era fashion: a resistência da turma da gestão era tamanha que, depois de alguém apresentar uma palestra de XP ou Scrum na empresa, os gerentes baixavam decretos proibindo a implantação desse tipo de coisas em suas sacrossantas estruturas de comando e controle. Aconteceu exatamente isso quando convidei o Klaus para palestrar em um condomínio de empresas de tecnologia, por volta de 2003.

O paradoxo é que eu mesmo comecei a me interessar por "metodologias leves" em 2000, justamente em reação à utilização de um tal de "RUP" no projeto em que estava envolvido. Eu me questionava: deve haver uma forma mais racional (sem trocadilhos) de levar adiante o desenvolvimento de sistemas. Descobri o ensaio "A nova metodologia", escrito por Martin Fowler (também presente ao evento) em 1999: a partir dai comecei a puxar o fio da meada, começando por XP. Agora, 10 anos depois, tive a oportunidade de conversar bastante com o Philippe Kruchten, o pai do RUP, que me impressionou muito favoravelmente: afinal, o framework de processos por ele proposto tinha várias boas ideias.

Pena que essas ideias foram enlatadas e marqueteadas como metodologia proprietária por uma corporação interessada principalmente em vender ferramentas CASE por preços nada camaradas. Deu no que deu: na esmagadora maioria das implantações, virou um cascata com artefatos UML: o Processo mUmificado. Aliás, para quem trabalhava com TI nos anos 90 era natural que empresas oferecessem metodologias proprietárias: na prática, um conjunto de formulários e templates que tinha pouca utilidade fora do contexto da empresa que o havia criado. Hoje nem se fala nesse tipo de oferta: ninguém mais acha sentido.

Se tivesse que apostar nas tendências para a próxima temporada de eventos de Agile, seriam Lean, Kanban e assuntos de governança. Vamos aguardar os próximos. Torço para que Dev+Ops, naked planning, usabilidade, gestão de riscos e práticas ágeis para a qualidade entrem também na pauta.

Jorge Diz
twitter: @jorgediz

Comentários

Unknown disse…
Parabéns pelo post!

Mostra um ponto de vista mais crítico do que aquele apresentado por aí, por vários agilistas, sobre o evento e a comunidade de métodos ágeis!
Yara Senger disse…
Eu tambem gostei bastante. 100% estilo Jorge Diz.
Gostaria de mais opiniões sobre o Scrum but e o Scrum by the book. :)
[]s
Yara
Grande Jorge.
Parabéns pelo texto.
Grande abraço.

Postagens mais visitadas deste blog

Saiba como programar para Arduino sem ter nenhum hardware disponível

O Arduino já é uma tecnologia muito difundida entre os amantes de tecnologia. É difícil encontrar um profissional da computação que não brincou um pouco com esta ferramenta de prototipagem ou, que gostaria de fazer isso. Porém, em alguns casos, o programador quer conhecer o arduino mas não dispõe de nenhum hardware, nem mesmo da placa. Como isso poderia ser resolvido? A primeira resposta seria aquela mais simples e direta: ir as compras. Isso pode ser feito em uma loja física ou pela internet. No meu caso, por exemplo, tive a felicidade de encontrar em um site (não me lembro qual) um kit arduino, com um conjunto de sensores e um DVD com 41 vídeo aulas. Mas digamos que o profissional não esteja passando por um bom momento financeiro, ou ainda, simplesmente não queira comprar o Arduino sem antes conhecê-lo um pouco melhor. Para a última situação também já existe uma resposta, e diga-se de passagem, uma excelente resposta. Trata-se do site 123D Circuits.io . Depois de criar seu u

Entendendo como funciona a programação de computadores: linguagens de programação, lógica, banco de dados

Nesse post, diferente dos últimos que foram mais enfáticos nas experiências com tecnologias, vou focar um pouco mais nos profissionais que estão começando, ou pretendem ingressar na área de desenvolvimento de software, falando sobre conceitos fundamentais relacionados a programação em geral . Mercado de trabalho para programação Conforme já sabemos, o mercado de desenvolvimento de software, especialmente no Brasil, continua em franca expansão, sendo que cada vez mais as empresas buscam desenvolver seus próprios sistemas usando as mais diferentes e novas tecnologias. Algumas matérias interessantes: As seis profissões mais valorizadas em 2010 no IDG Now! Muitas vagas e sensação de reaquecimento da economia Por isso, a área de desenvolvimento de software tem despertado interesse em muitos profissionais de outras áreas que desejam mudar de profissão, já que as oportunidades de trabalho tendem a ser maiores. Esse é um perfil presente em muitos dos clientes da Globalcode que acabou m

JSON fácil em Java com GSon !

Ola pessoal ! O formato JSON ( J ava S cript O bject N otation) vem se consagrando cada vez mais na comunicação de dados, principalmente nos dispositivos móveis devido a esse formato ser mais leve que o XML e também mais legível. Uma prova disso são as inúmeras bibliotecas que existem para manipular esse formato, e no caso do Android, o suporte ao JSON é nativo. Mas apesar de ter esse suporte nativo, algumas operações devem ser feitas manualmente e o código acaba ficando um pouco verboso e repetitivo, já que para cada objeto que se deseja transmitir é necessário fazer um método que lê as propriedades do JSON e faz as devidas atribuições no seu objeto Java. Vamos supor o seguinte objeto sendo transmitido em JSON: {   user: {     id: 123456,     name: "Neto Marin",     username: "netomarin",     email: "netomarin@globalcode.com.br"   } } Se você fosse tratar um Webservice que envia esse JSON para o seu aplicativo Android, além de criar a o