Thinking Agile

Ola amigos,

estou temporariamente sem escrever aqui no blog, porque tenho recebido diversos emails pedindo mais material a respeito do assunto, o que sem duvidas me pegou desprevenido ja que a ideia inicial era fazer comentarios e discutir o assunto!

Assim estou juntando material e devo mudar a ideia do site de blog para um forum!

Qualquer duvida ou comentario me escreva!

claudio@claudio.com.br

Abraco.

Claudio

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

O que seria do desenvolvimento de software hoje sem as comunidades? A web 2.0 está aí provando que o já tinha sido provado muito tempo antes mas não era moda: “duas cabeças pensam melhor do que uma”.

Lideradas por nomes conhecidos no mercado, muitas vezes nesse meio só para fazer um bom dinheiro com livros e etc, levam o senso comum para uma direção não tão certa ou madura ainda naquele momento.

Com isso, outro velho e conhecido problema que nós enfrentamos com freqüência nos projetos aparece forte: O Modismo.

Quando alguma coisa está na “techno-moda” todo mundo fica desesperado, quer aprender, quer usar, quer comprar livros, quer fazer cursos etc etc etc. Mas muita vezes (se não na maioria delas) nos damos muito mal: Sistemas desenvolvidos usando tecnologias não maduras, sem pessoal experiente (na verdade inexistente ) assessorados por ferramentas versão 1.0 cheias de bugs, nos assombram dia a dia

Quem nunca deu manutenção em um sistema usando Struts 1.0 por exemplo, um bom exemplo de tecnologia que não morreu, mas teve grandes alterações se comparado com a versão 1.1 (por que não espera madurar um pouquinho antes de usar?).

Mas onde eu quero chegar com tudo isso é, será que o desenvolvimento ágil hoje não é a waterfall (cascata) de ontem? Será que essa nova “techno-moda” não vai sumir daqui alguns meses? Com toda certeza em 10 anos podemos estar mudando esse blog para a próxima grande bala de prata dos processos de desenvolvimento de software! !

Mas hoje, por que eu acredito em desenvolvimento ágil? Porque ele apresenta sensíveis diferenças quando comparado com outros processos, e essas sensíveis diferenças estão diretamente ligadas ao maiores problemas com os quais eu já lidei no passado.

Aplicando hoje no meu dia a dia, uma mistura de técnicas vindas de vários processos como UP, Extreme Programming e Scrum eu vejo na cara dos usuários finais, tão acostumados a precisar de A, pedir B e receber Z, a satisfação ao receber um A menos e sem duvidas ao ver Product Owners, os que realmente pagam os projetos, entenderem como é mais importante o resultado alcançado com o investimento feito do que um número mágico de horas num cronograma furado!

Acredito em processos ágeis não porque li uma meia dúzia de livros, e sim porque eles resolvem na pratica os maiores problemas com os quais lidei no passado e porque ao contrario de outras techno-modas, tem gente grande usando isso a mais de 10 anos, na verdade eles datam da década de 60 com EVO.

Assim, pode ser que processos ágeis sejam vistos apenas como mais uma techno-moda no mercado, mas eu realmente visto essa camisa

Claudio Teixeira