AgileBrazil

Sem dúvida nenhuma foi um evento de imenso sucesso. Realizado em Porto Alegre nos dias 24 e 25 de junho, este evento teve a participação de várias personalidades da comunidade ágil, porém, para mim dois palestrantes se destacaram dos demais: Martin Fowler e Philippe Kruchten. É claro que tivemos outras palestras excelentes como a do Manoel Pimentel, Klaus Wuestefelde e outros, mas as do Fowler e Kruchten tiveram uma “bagagem” de experiência e visão holística de mundo ágil incríveis.

Para mim os quatro conceitos mais importantes retirados de suas apresentações foram:

  1. Se alguma coisa dói, faça com maior frequência
  2. Levar mais tempo fazendo um bom design porém simples, aumenta a sua velocidade
  3. O que funciona para o outro, pode não funcionar para você
  4. Agilidade não é uma receita e sim uma cultura

Tentarei agora resumir um pouco da minha percepção sobre cada um dos tópicos.

Se alguma coisa dói, faça com maior frequência


A idéia central aqui é que se alguma coisa gera um grande esforço ou uma grande preocupação deve ser feita com maior frequência, isto porque  quanto mais vezes fazemos alguma coisa e quanto menor o seu intervalo de repetições menor será o impacto ou conflitos encontrados. Um exemplo típico e comum que encontramos em várias equipes de desenvolvimento é o processo de deploy (publicação). Quem nunca ouviu de algum líder de equipe que ficou sem dormir as vésperas de alguma grande publicação ou troca de versão. O cara já sai de casa falando para a esposa: “Meu bem, hoje iremos colocar o sistema no ar. Não sei que horas chego em casa, vou comer alguma coisa na rua”. Geralmente o pobre coitado não volta para casa naquela noite, fica de plantão cheio de pepinos para resolver de madrugada, toma bronca por telefone do cliente, da esposa e do dono da empresa.

Bom, se você já viu ou viveu uma situação dessas você sabe do que estou falando, então porque ao invés de fazer esse grande processo de publicação com varias mudança de sistema e mega homologações de cliente, não fazer várias publicações menores? Por exemplo, se você tem uma funcionalidade nova faça uma publicação para essa funcionalidade. Seu horizonte de bugs, erros, modificações ou problemas fica menor, sua homologação mais simples e seu processo de publicação menos traumático.

Nessas horas começam a aparecer as desculpas: “Ah, não posso fazer isso porque meu cliente não deixa”, “Ah, ai vou ter que testar o sistema todos varias vezes”, “Ah isso não funciona”, “Ah isso não da certo, pois meu refactor muda o sistema todo”. Bem nunca vi um cliente que não goste de receber uma funcionalidade nova no sistema que o ajude em seu processo de operação e reduza seu trabalho de homologação, testar o sistema todo varias vezes? você conhece testes automatizados? Sim, antes de você vir com a próxima desculpa, dá para automatizar testes de interface sim, já existem varias ferramentas para isso. Isso não funciona? porque? já tentou?, quantas vezes você faz um refactor que altera toda a base do seu sistema? Bem essas são algumas perguntas que devem ser feitas antes de sair criticando um Continuous Delivery (Publicação continua)

Este conceito se aplica a varias outras partes do processo de desenvolvimento de um software como, por exemplo: integração contínua, refactor e outros

Levar mais tempo fazendo um bom design porém simples, aumenta a sua velocidade


Este é um ponto que gera muita polêmica na comunidade, isto porque é um ponto com um pouco de subjetividade ou difícil de mensurar. Por exemplo: o que é um bom design? ou aumenta a velocidade, em quanto? levar mais tempo, qual o tempo ideal? Bom, não irei entrar nesse mérito simplesmente explicarei o conceito.

A idéia e que se fizermos um software com uma bom design utilizando boas práticas de programação será muito mais fácil acrescentarmos novas funcionalidade a ele. “Uau, nossa nunca ninguém me disse isso antes”. Bom é claro que todos sabem disso ou já ouviram isso antes, mas na prática nem sempre isso acontece. Vocês por acaso nunca encontraram um código “macarronico” em um sistema? nunca encontraram uma função ou serviço com um grande acoplamento? nunca teve pressão de um líder ou gerente para entregar um código para ontem e não fez da melhor forma possível, deixando o refactor para uma outra oportunidade?  Bom se você respondeu não para as três perguntas anteriores ou você não é e nunca foi um desenvolvedor, ou você começou a programar ontem.

Esse tópico apesar de simples e até mesmo intuitivo serve para nos lembrar da importância da qualidade de código que estamos fazendo hoje e que nos poupará tempo amanhã.

O que funciona para o outro, pode não funcionar para você


Bem isso foi muito legal de se ouvir. Está em linha com que eu penso sobre processo e práticas de desenvolvimento de software. Cada empresa tem seu processo de trabalho, certo ou errado ele é único! Isto porque cada empresa possui suas particularidades que englobam área de atividade, posição geográfica, situação financeira, qualidade de mão de obra. Temos que entender que não é porque um conjunto de práticas que deram certos em uma empresa será o melhor para outras. Temos que estudar, entender e escolhermos os processos que podem e devem se adequar em nosso contexto. Ai começam as discussões dos xiitas: “Ah mas se não fizer tudo igualzinho X fez então teremos um Ybut” ai começam os scrumbut, agilebut, xpbut. Bem se um scrumbut me fizer produzir software com melhor qualidade e com melhores resultado que um scrum seguido ao pé da letra, que seja. O importante é estudar e entender o custo e o benefício de cada umas das práticas que serão seguidas ou não.

Não estou aqui defendendo empresas que usam uma ou duas praticas ágeis e se dizem agilistas. Estou defendendo pessoas que estudam métodos ágeis entendem seus conceitos, entendem seus ambientes, sabem de seus benefícios e suas limitações e adaptam esses métodos as suas realidades.

Por exemplo, eu tenho uma equipe de desenvolvedores que sentam em uma mesma sala, conversam e trocam idéias durante o dia todo, uns ajudam aos outros em código e dúvidas, almoçam juntos e gostam de falar sobre trabalho mas não fazem stand-up meeting. Ai você conta isso para alguém e o cara fala: “Se você não tem stand-up metting, você não usa scrum” nossa nem vale a pena continuar a conversa.

Agilidade não é uma receita e sim uma cultura


Bem, acredito que esse último conceito é o resumo de tudo que foi percebido no decorrer do artigo. Agilidade não é uma receita mágica, siga ao pé da letra que você será bem sucedido. Agilidade são idéias e práticas que nos ajudam a desenvolver software com maior qualidade, facilidade, simplicidade e valor. Essas práticas buscam nos orientar e a nos disciplinar a buscar mecanismos que nos auxiliem a ter sucesso. Agilidade não tem linguagem de programação, não tem banco de dados, não tem hardware, ao invés disso, temos comunicação, simplicidade, conceitos de valor agregado, prioridades, transparência e clareza.

Anúncios
  1. 28 de junho de 2010 às 3:28 PM

    parabéns pelo post! excelente sumário do que foi um evento realmente incrível.

  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: