Fragmental

7/15/2005

Todo Mundo é Ágil

O blog do XP Rio dá a dica de um ótimo artigo por Pete McBreen. Pete é o autor do aclamado livro Software Craftmanship, que aidna não tive o prazer de ler.

No texto, o autor fala do que está acontecendo com o mercado hoje, onde todo mundoe stá dizendo "eu sou ágil". Isso, como ele afirma, aconteceu com Orientação a Objetos, também com componentização, RAD, MVC e tantas outras coisas.

Realmente isso está acotnecendo, basta olhar em volta. Me lembra uma empresa brasileira que vende uma IDE RAD dizendo ser um "método ágil". Também já ouvi alguns líderes de equipes de desenvolvimento falando uma série de besteiras sobre como sua metodologia é ágil.

Então, Pete dá a dica com dez lições simples para provar que algo não é ágil (tradução livre resumida com comentários adicionais meus):
  1. O "Project Plan" acaba de ser divulgado, mostra o primeiro release acontecendo 18 meses depois do início do projeto.Num projeto ágil o foco é na atividade cosntante de planejar, não no plano resultante. Não adianta ter datas que não serão cumpridas.

  1. O gerente de projeto fala sobre artefatos que os analistas vão produzir para os arquitetos. Modelo Cascata (Waterfall) em cheio. O próximo passo é entregar as especificações de arquitetura aos projetistas, que entregam aos programadores. Isso é tudo, menos ágil (ou bom).

  1. Arquitetos e analistas afirmam orgulhosamente que não codificaram uma linha sequer no último projeto. Mostra que se pensa em codificar como atividade trivial. Isso vai totalmente contra o Agile Manifesto, que diz claramente que software funcionando tem mais valor que documentação.

  1. Programadores e testadores estão no nível mais abaixo da cadeia alimentar. Como no anterior, fazendo isso torna impossível um processo ter Agilidade. Porgramadores são a alma do processo.

  1. O analista cosntantemente tenta fazer os usuarios assinarem o tal documento dos requerimentos. Congelar os requisitos é o sonho dequalquer analista, ams isso não vaia cotnecer nunca, não importa que o cliente assine o documento com seu sangue. A proposta Ágil é colaborar com o cliente, não limitar suas escolhas.

  1. Desenvolvedores reclamam quando uma mudança nos requisitos passa por cima do burocrático processo de controle de mudanças. Processos ágeis acolhem mudanças.

  1. Você está a mais de dois meses no projeto e aidna não foi exibida nenhuma funcionalidade útil aos usuários. PowerPoint e telas mock não contam.

  1. O líder do projeto considera documentação mais importante que comunicação. Fazer registros em documentos oficiais para poder rastrear o significado de qualquer mudança costuma ter como efeito uma equipe confusa sem a menro noção do que está fazendo (ou do que os outros estão fazendo). Se algo é importante para valer um documento, é importante para ser conhecido por todos.

  1. Testes e verificação de qualidade não são partes integrantes e respeitáveis do processo. Ser Ágil é escrever software de qualidade, e a comprovação que um software tem qualidade é dadas de forma prática através de testes. Mesmo empresas com grandes departamentos de QA mutias vezes não elvam a sério esta etapa, deixando a verificação da qualdiade apenas como última etapa, logo antes da entrega.

    Finalmente, você finge ser ágil se em seu processo:

  1. Tarefas são dadas a pessoas, que pegam seu trabalho, se isolam num lugar quieto (sua baia) e tratam aquilo como um trabalho solo. Num lugar onde as pessoas usam fones de ouvido ou se isolam para não serem perturbados por outros membros do time, você pode apostar que o líder de projeto não entende desenvolvimento colaborativo. Se não entendem o básico disto, podem ter certeza que o processo não é ágil, não importa os quadro-brancos, reuniões em pé ou programação em par.


 
f