Mas tchê, me diz uma "cousa", o que é essa tal de agilidade?

Prezados

É com muito prazer que começo mais um post. Vamos ver o que acontece com esse. Perdoem-me aqueles que não são da TI, passaram por aqui, e se depararam com um post falando sobre a dimensão humana dos métodos ágeis, sem que eu tenha explicado que "bicho é esse". Pretendo agora corrigir meu lapso ;-).

Penso ser essa uma oportunidade interessante, inclusive aos "sabidinhos de plantão", pois tem muita gente por aí dizendo que usa métodos ágeis, mas "tá mais perdida que cusco em tiroteio". Aos que não conhecem o termo "cusco", esclareço: é como nós chamamos o cachorro aqui no sul, principalmente o cachorro campeiro.

Mas vamos ao que interessa, que é o software mesmo. O mundo da engenharia de software já passou por algumas crises. A mais famosa é a crise do bug do milênio. Mas até hoje temos problemas básicos, como:
1 - Apenas 1/3 dos projetos de software dão certo (entendam dar certo como cumprir o objetivo proposto dentro de um prazo e custo esperado). Segue o texto retirado do Standish Group sobre o Chaos Report 2010: The Standish Group's just-released report, "CHAOS Summary 2009," "This year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions" (http://www1.standishgroup.com/newsroom/chaos_2009.php).
2 - O Chaos Report 2002 mostra que aproximadamente 50% das funcionalidades desenvolvidas em um software nunca, ou quase nunca, são usadas. Olha o desperdício!

As primeiras crises relativas a problemas com os softwares desenvolvidos desencadearam uma reação natural de busca por meios de evitar que esses problemas tornem a acontecer, através da inserção de controles e "disciplinando" o processo de desenvolvimento de software. O termo "engenharia de software" deriva de uma busca, nas práticas da engenharia (civil, mecânica, ...), de técnicas e métodos capazes de organizar a construção de um software. Então passou-se a ver o processo como um meio importante de se chegar a um bom produto. A idéia era mais ou menos essa: Uma equipe com um processo ruim pode até conseguir construir um bom produto, mas não há garantias de repetir o sucesso. Uma equipe com um bom processo conseguirá fazer bons produtos e repetir o sucesso várias vezes.

Não há nada errado com essa idéia, de uma maneira genérica. O problema (mais uma vez) foi a inserção de controles, documentos, papéis e etapas em torno de um projeto que aumentou exponencialmente o número de tarefas a serem cumpridas em um projeto. Entretanto, não havia uma garantia que o cumprimento dessas etapas traria sucesso ao projeto.

Como dizem num programa de rádio aqui de Santa Maria, vamos exemplificar para que a D. Maria, que não entende patavina de software, possa entender: A D. Maria, dona de um estabelecimento comercial, quer um "programinha" para controlar as finanças da empresa. Então ela chama a empresa XYZ2010, uma das mais conceituadas empresas do país, para um orçamento. Senta na frente da D. Maria um tal de "analista de negócios" e conversa, conversa, conversa, conversa, conversa, conversa, conversa. Ele anota tudo. A D. Maria pergunta: Quando que você me entrega isso? A fim de não perder o negócio, o analista diz assim: Nós vamos projetar segundo as especificações do nosso processo e em alguns dias nós entregamos o orçamento. Umas duas semanas depois volta o cristão, crente que entendeu tudo o que a D. Maria quer, e depois de ter escrito umas 250 páginas de "especificação de requisitos" e vários diagramas, afinal ele precisa saber quantos "bits points" (ou outra unidade qualquer de medida de tamanho de software) o programa terá para estimar um prazo, e diz assim: Levará 4 meses e custará R$ 50.000,00. Como ela não entende nada de "computador" e confia, ela fecha o negócio.

Lá pelo terceiro mês do projeto, sem ela não ter nem ouvido mais falar da XYZ2010, ela liga para falar com o tal analista de negócio. Descobre que ele não trabalha mais na empresa. Ela se apavora. A secretária diz assim: Não se preocupe D. Maria! Nós usamos o processo ABC e somos certificados. Tudo o que a senhora relatou está a salvo e a equipe compreendeu perfeitamente. Vou transferir a ligação para o novo analista que está cuidando da sua conta. A D. Maria então conversa com o novo analista e, mais tranquila, pergunta se pode ser feita uma pequena alteração no projeto. O novo analista responde: D. Maria, se nós fizermos uma alteração agora, teremos que reprojetar tudo, analisar o impacto da mudança e enviar um novo orçamento. A senhora realmente quer? Com uma certa pena dos rapazes, D. Maria diz: Vou aguardar vocês entregarem o projeto então. Afinal, D. Maria contratou uma das melhores.

Quando o projeto foi entregue, a surpresa foi que D. Maria disse ao analista de implantação que foi instalar o produto na sua empresa e mostrar como tinha ficado o trabalho: Não foi nada disso que eu pedi. O rapaz, atônito, disse, ao mostrar o documento de requisitos: Mas está igualzinho ao que a senhora pediu aqui!!!! O final dessa história muitos já conhecem.

Em tempo: Essa realidade também acontecem com as equipes dos "pequenos rincões distantes da capital". Acontece até mesmo com o sobrinho do amigo que faz faculdade de informática ;-). Aconteceu comigo também :-(.

De olho na realidade da D. Maria (e de muitos outros), uns "caras" perceberam que a coisa não andavam bem e resolveram se encontrar para trocar umas idéias. Se isso fosse aqui no sul, esse encontro seria num galpão, a beira do fogo de chão numa roda de chimarrão. Mas isso foi no Norte. Mais precisamente nas montanhas geladas de Utah, entre os dias 11 e 13 de fevereiro de 2001.

Foram 17 mestres que se reuniram, esquiaram, descansaram, comeram e chegaram a um ponto em comum. Todos eles vinham trabalhando de forma diferente. Eram as vozes vivas do Extreme Programming, Scrum, Crystal, FDD e outros. Sim, estou falando do manifesto ágil. Uma forma diferente de ver o trabalho de desenvolver software. Segue abaixo os princípios e valores que eles encontraram:

"Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:

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

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

São signatários desse manifesto:
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

Dentre os quais, tive a honra de ver a palestra do Martin Fowler, no Agile Brazil 2010.

Basicamente, os métodos ágeis de desenvolvimento de software constituem uma forma diferente (dos métodos tradicionais) de ver o desenvolvimento de software. Desenvolver software é basicamente um processo contínuo de resolução de problemas complexos. Demanda pessoas motivadas e com uma vontade muito grande de encarar problemas de frente todo santo dia! Então os processos de apoio devem ser vistos como algo necessário, útil e simples. As pessoas passam a ter um papel fundamental para o sucesso da empreitada.

Nesse tempo em que resolvi adentrar no mundo dos métodos ágeis, conheci muitas feras. Esses feras andaram conceituando agilidade lá em Pingos de Agilidade. Segue abaixo alguns desses conceitos que encontrei por lá.

Daniel Wildt: "Atitude, foco em entrega de software, trabalho em equipe e mehoria contínua."

Manoel Pimentel: “Em minha opinião, agilidade não é apenas um conjunto de práticas aplicadas para melhorar o desenvolvimento de software, mas sim uma verdadeira filosofia de vida, que nos faz encarar as questões do dia-a-dia, através do reconhecimento de nossas limitações e ao mesmo tempo, do desenvolvimento de nossas potencialidades como ser humano.”

Rafael Prikladnicki: "Eu gosto da definição do Philippe Kruchten: 'Agilidade é a habilidade de uma organização de responder à mudancas no seu ambiente de atuação mais rápido do que a taxa de ocorrência destas mudanças.' Além disso, a agilidade reforça a importância do fator humano em projetos de software, bem como inspeção constante e entregas rápidas."

Luiz Claudio Parzianello: "É engraçado, mas não sei mais como definir agilidade … Se eu tentar fazê-lo, acho que vou destruir o conceito! Para mim, agilidade é um caminho de descobertas que conduz à ética e ao aperfeiçoamento contínuo, tanto do indivíduo quanto da organização de software. Na primeira edição do Community Journal da Visao Ágil, pude escrever o seguinte sobre uma pergunta muito semelhante:
Muitos acreditam que o Manifesto Ágil não passa de uma piada, enquanto outros acreditam que ele marca o início de uma mudança na história do desenvolvimento de software. Alguns acreditam que tudo isso é um mero modismo, enquanto outros conquistam continuamente melhorias substanciais na qualidade e produtividade de suas equipes de desenvolvimento. Muitos acreditam que agilidade é assunto para pequenos, enquanto poucos já demonstraram que milhares de pessoas trabalhando de forma colaborativa e distribuída é coisa de gente grande. Pois bem, pude perceber ao longo dos últimos 10 anos, assessorando empresas e capacitando profissionais em projetos de implantação de Metodologias Ágeis, que a agilidade não está associada somente a uma nova cultura de crenças e valores, mas principalmente a uma nova busca de descobertas e iluminação. Iluminação no sentido de enxergar de vez que o desenvolvimento de software é um problema de logística que deve ser sustentado por uma forte cultura de comunicação e colaboração entre todas as partes interessadas num produto ou projeto de software. Logística no sentido de desenvolver competências para a entrega rápida de pequenos incrementos de software de alta qualidade, mantendo sempre um ritmo constante sustentável. Comunicação e colaboração no sentido de compreender como a menor quantidade de software irá aumentar a vantagem competitiva de nossos clientes (fazer cada vez mais com cada vez menos). Se você promover de forma honesta a melhoria contínua de pessoas, ferramentas e métodos, você com certeza encontrará o pensamento Ágil e descobrirá que esse é o único caminho para o sucesso e a satisfação de sua equipe de desenvolvimento."

Bom espero ter trazido a todos uma visão sobre o que são os métodos ágeis. Fico a disposição para sugestões, críticas ou até convites para festa.

P.S.: Havia colocado que o blog Pingos de Agilidade era mantido pelo Manoel Pimentel. Estava equivocado. É mantido pelo Rafael Helm e agora pelo Daniel Wildt. Procurei corrigir.