A metodologia ágil foi criada por um pessoal que percebeu algumas coisas de métodos tradicionais, ou modelos de trabalho da época e perceberam que existia uma coisa intrigante: sistemas em cascata eram muito ineficazes.

Exemplo: Imagine que você foi contratado para fazer um serviço. Planejou todas as etapas. Acertou com o cliente, deu um prazo de três meses para desenvolver. No planejamento o cliente ficou extremamente feliz e esperançoso no sistema.

Você, no melhor caso, passa os três meses trabalhando. Deixou o sistema conforme o combinado. No dia da apresentação o cliente olha seu trabalho e diz: “Tá, mas não foi bem isso que eu queria”. Possivelmente você não receba uma parte do pagamento se não entregar as alterações. Resultado: o prazo atrasa, o cliente fica insatisfeito com o serviço e você, desacreditado. Muitas empresas sofrem com esse problema constantemente. Isso é o velho sistema de cascata.

A grande sacada é que o método ágil já subentende que o cliente não sabe o que quer. (ao menos no todo do projeto)

Volando a ideia inicial… Vendo isso a galera resolveu criar um manifesto, com ideais a serem seguidos. O principal foco dessa metodologia é responder bem à mudanças, tornando o metodologia “leve”.

O manifesto diz…

Copiando o conteúdo do Manifesto ágil:

  • Indivíduos e interação entre eles mais que processos e ferramentas;
  • Software em funcionamento mais que documentação abrangente;
  • Colaboração com o cliente mais que negociação de contratos e;
  • Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Um quadro bastante atual

Pessoas que trabalham com softwares tendem a sofrer muita pressão, mais ainda com um planejamento falho, equipes despreparadas e desmotivadas. É muito comum encontrar desenvolvedores se achando improdutivos.

Muitas vezes a energia e criatividade dos colaboradores é sugada pela rotina cansativa de prazos apertados, ou há uma sobrecarga nos desenvolvedores de modo que se criem Ilhas de desenvolvimento. Isso é péssimo para as férias.

O segredo é dar um “basta” nisso, ajustando a equipe para ser especialista em gerenciar mudanças. Nesse modelo as empresas não precisam gastar com horas extras. Estas ficam para a família, dar uns beijos e gastar dinheiro. :P

Foco no código! Isso é baboseira!

Se você pensa assim, code monkey, significa que essa postagem é pra você! Codificar, acredito eu, é o menor dos desafios. Lidar com equipes, com o cliente, fazer releases, testar, consomem mais tempo que você imagina.

Perdemos bastante tempo em um dia de trabalho. De um cafezinho à rotina de Deploy. Se soubermos administrar dá certo!

Como trabalhar nessa metodologia?

Trabalhamos em equipe. E precisamos enfatizar isso. Nada de orgulho. Esse é o principal ponto para o sucesso da metodologia. As equipes são autogerenciáveis, ou seja, possuem autonomia para tomarem as melhores decisões pro time.

Pessoalmente

Organize-se. Ache um lugar onde anotar alguma informação rápida. É importante que você seja bom no que faz, e que fundamentalmente seja o tipo de pessoa que “saiba onde achar as coisas”. Um desenvolvedor é diferente de um programador. (Estou buscando o post que eu vi há tempos de um colega, mas quando achar publico aqui)

Sobre seu time

Ele precisa ser formado de pessoas boas e multidisciplinadas. Algo que, se você precisar, poderá contar com qualquer um para resolver o serviço. De programar à atender clientes. Todos precisam estar aptos. Equipe máxima de 9 pessoas porquê a comunicação face a face é de extrema importância. Um time ruim é prejudicial ao extremo!

Não existe indivíduos, existe “equipe”

O trabalho precisa ser realizado no intuito de a equipe resolver o problema. Ilhas de conhecimento não devem existir, ou seja, a lógica estar apenas com um desenvolvedor. Pra isso é necessário documentar, mas de forma a atender o mínimo necessário para que qualquer um da sua equipe consiga tocar o trabalho. Padronizar, usar convenções é uma boa pra cumprir esse objetivo. Se ocorrer um problema, também a equipe resolve e se acerta. A crítica é individual, mas o elogio, coletivo.

Casa de ferreiro, espeto de “aço valiriano”

A grande sacada é que os desenvolvedores estejam sempre buscando as melhores formas de resolver o problema. Nossa área é uma das que mais sofrem atualizações. Parar de estudar é o mesmo que atirar no pé.

Ferramentas bastante interessantes são:

  • Ambiente de desenvolvimento xNix (Linux, Mac…) [não desprezando o Windows, mas convenhamos que é bem mais interessante! rs {A não ser que você programe em Delphi}];
  • Ferramentas de versionamento (git, hg…);
  • Ferramentas para automação de testes (TDD, BDD…)
  • Tracker de tarefas (Issues do github, bitbucket, Trello, Pivotal…);
  • Integrador contínuo (Travis, Jenkins, Scripts do fabric, Capistrano…);
  • Ambientes de Desenvolvimento Integrado, ou IDEs.

Além das metodologias ágeis, especificamente:

  • Scrum;
  • XP;

(Há mais outros, mas esses são os que eu mais gosto!)

Por fim

Espero que eu tenha conseguido lapidar um pouco sobre a metodologia ágil. Ter conhecimento sobre isso fará com que você se valorize bastante. Espero em outras postagens falar mais sobre.

Por favor, deixa aí nos comentários o que acharam e se faltou algum outro detalhe! Até uma próxima!! o/