Thinking Agile

O Agile Manifesto, guia das metodologias ágeis, muitas vezes é mal compreendido, vamos analisa-lo:

“Nós estamos descobrindo melhores maneiras de desenvolver software, desenvolvendo e ajudando outros a fazê-lo.”

A primeira frase do Agile Manifesto, deixa claro que essas considerações foram retiradas de utilização prática, ou seja, desenvolvendo software e ajudando aos outros. O que apresenta claramente a característica empírica do processo iterativo (define, usa, avalia, redefine, usa, avalia ….).

“Indivíduos e iterações ao invés de processos e ferramentas”

Essa consideração é uma das mais mal entendidas, processo ágeis usam ferramentas sim, IDEs com forte apelo de refactoring, Cruise Controls para integração, ferramentas de teste integrado e automação de testes são alguns exemplos, o que eles querem dizer é, não deixe que uma ferramenta (normalmente de gerenciamento) atrapalhe no fluxo seu desenvolvimento. Muitas vezes tarefas inúteis são adicionadas no dia a dia apenas porque o processo “manda” (processos pesados). Equipes ágeis adaptam seu próprio processo a cada iteração (processos leves). As metodologias ágeis possuem processos leves de baixa cerimonia (mais a frente).

Outra coisa que é mal interpretada é que metodologias ágeis não usam processos. Metodologias ágeis tem processo sim, seja XP, seja Scrum, todos tem suas etapas bem definidas, mas o que ele querem dizer é: Uma equipe de ótimos profissionais com um processo ruim ou sem processo vai sempre fazer um melhor trabalho do que uma equipe de não tão bons profissionais com um ótimo processo.

Software funcionando ao invés de documentação compreensiva

Essa outra consideração é muito mal entendida, metodologias ágeis geram documentação sim, manuais, guias de deployment e etc precisam ser escritos, mas o que as metodologias ágeis aconselham é que sejam escritos o mais para o fim possível, já que é HUMANAMENTE IMPOSSÍVEL de manter todos documentos sempre atualizados durante o desenvolvimento. Diagramas de classe e de sequência são rabiscados nas paredes (cheias de quadros brancos) antes das implementações (Agile Modeling and Design), e tem como meta principal que a ideia seja passada, assim não existe preocupações com a exatidão no desenho dos diagramas, como, “qual o tipo certo de seta utilizar aqui?”, isso não é importante, o importante é discutir a idéia (baixa cerimonia).

Colaboração dos clientes ao invés de negociações contratuais

A colaboração dos clientes e ou usuários finais é FUNDAMENTAL. O segredo do sucesso das metodologias é a reposta rápida as mudanças, a adaptação rápida ao que precisa ser ajustado. Quando se lê que metodologias ágeis entregam vários pequenos releases o mais rápido possível elas esperam logo em seguida o feedback dos clientes, através do feedback ajustes podem ser feitos mais rapidamente. Aquele papo: “olha não é bem isso que eu queria” acontece muito antes se comparado a outras metodologias, onde o cliente só vai realmente ter acesso ao sistema depois de muita coisa “pronta”. Nos próximos dias vou postar “Considerações contratuais em projetos ágeis”.

Responder rápido a mudanças ao invés de seguir estreitamente um plano

Desenvolvimento de software ao contrario do que se acha (e se espera ) não é o mesmo que fabricar algum artigo num conceito de manufatura. O Desenvolvimento de software é o desenvolvimento de algo apenas aquela vez. Se comparado com fabricação de carros por exemplo, após um tempo fabricando carros, você pode facilmente calcular quanto esforço é necessário para se produzir um numero certo de carros, você também já sabe o que pode atrapalhar o dia-a-dia de trabalho, bem como otimizar processos. O Desenvolvimento de software se enquadra mais em um CAS (Complex Adaptive System), ou seja, você precisa estar ligado o tempo todo para onde as coisas estão indo, exemplos ilustrativos são como um cardume, que o tempo todo está coletando dados do ambiente (comida, predadores etc) e se adaptando a ele. Nas metodologias ágeis não existe um plano exato, com um cronograma de tarefas para cada recurso até o fim do projeto, na verdade, nas metodologias ágeis nós temos uma Visão de onde devemos chegar e um Roadmap que mostra caminho e em qual ordem as coisas devem acontecer, ambos fornecidos pelo cliente. Para ilustrar isso, imagine a construção de uma grande estrada, desde o começo se sabe onde se quer chegar, um plano em alto nível é criado, e a medida que a estrada é construída informações sobre ela são coletadas, assim, a qualquer momento a estrada pode fazer uma curva para se adaptar ao relevo, mas ela sempre vai em direção à Visão.

Enquanto existe valor nos itens a direita, nós damos mais valor ao itens a esquerda.

E por ultimo, existe um reconhecimento nos itens da direita, logo, processos, ferramentas, documentação, negociações contratuais e seguir um plano são itens extremamente importantes e possuem valor sim, mas as metodologias ágeis dão preferência aos da esquerda

Claudio Teixeira