Introdução ao Desenvolvimento Ágil

Este é o primeiro de uma série de artigos que têm como foco mostrar em detalhes a Programação Extrema ou XP (Extreme Programming), que é a metodologia de desenvolvimento ágil mais conhecida na atualidade.

Desenvolvimento Ágil de Software

Desenvolver software é uma atividade difícil e arriscada. Segundo as estatísticas, entre os maiores riscos estão: gastos que superam o orçamento, consumo de tempo que supera o cronograma, funcionalidades que não resolvem os problemas dos usuários, baixa qualidade dos sistemas desenvolvidos e cancelamento do projeto por inviabilidade.

No conceito tradicional, metodologia de desenvolvimento de software é um conjunto de atividades e resultados associados, que auxiliam na produção de software. Todas as metodologias de desenvolvimento tentam, entre outras coisas, reduzir o alto risco associado ao desenvolvimento de software.

Neste trabalho, as diversas metodologias de desenvolvimentos existentes na literatura serão agrupadas de acordo com o modelo básico de desenvolvimento adotado.

Desenvolvimento Tradicional

O termo desenvolvimento tradicional, neste trabalho, é utilizado para identificar as metodologias que de alguma forma adotam o desenvolvimento em cascata. No desenvolvimento em cascata, o software é construído seguindo uma seqüência de fases, sendo que cada fase, com exceção da primeira, depende da conclusão da fase anterior para ser iniciada (figura 1.1).

O desenvolvimento em cascata, a várias décadas é amplamente empregado nos processos de desenvolvimento de software, e ainda hoje é o mais empregado. Por esse motivo, neste trabalho ele é chamado de desenvolvimento tradicional.

Mesmo alguns processos de desenvolvimento de software que, em essência, não são em cascata, como o RUP (Rational Unified Process), são adotados em grande parte dos projetos, de uma forma que se assemelha muito ao modelo em cascata. Nesses projetos, o processo é empregado de forma iterativa e incremental, mas ainda existe uma forte linearidade no desenvolvimento, caracterizada por “cascatas menores” dentro de cada iteração (figura 1.2). Neste trabalho, o termo “desenvolvimento tradicional” também engloba estes casos.

Premissas do Desenvolvimento Tradicional

Existem algumas premissas básicas, derivadas do modelo de desenvolvimento industrial, que são muito comuns no desenvolvimento tradicional e o influenciam profundamente. Segue abaixo estas premissas e seus significados dentro do contexto do desenvolvimento tradicional de software.

Linearidade

A linearidade fica evidente pela própria adoção de um modelo em cascata que, como já foi explicado, é linear por definição.

Determinismo

Um processo de desenvolvimento previamente conhecido por gerar determinados resultados com base nas especificações, gerará resultados semelhantes sempre que suas regras forem rigidamente seguidas. O desenvolvimento tradicional, assim como a indústria, persegue o determinismo por acreditar que esta é uma forma de reduzir erros e perdas de tempo.

Especialização

O processo de desenvolvimento pode ser desmembrado em atividades especializadas que serão executadas de forma independente e depois terão seus resultados integrados para formar o produto final. A especialização torna as tarefas mais simples e conseqüentemente facilita o determinismo. No desenvolvimento de software tradicional, a especialização aparece claramente na rígida divisão de papeis entre membros de uma equipe, como analistas, projetistas, programadores, testadores e implantadores. Cada um deles realiza tarefas bem diferentes e especializadas e terão seus resultados integrados para compor o software finalizado.

Foco na execução

Quando existe especialização suficiente para que as tarefas sejam simples e determinísticas, não existe a necessidade, por parte de quem executa o trabalho, de pensar sobre o que se está fazendo, basta fazer. Ou seja, basta que cada pessoa envolvida no processo de desenvolvimento execute corretamente a tarefa que lhe cabe, conforme rigidamente estipulado numa metodologia que presumivelmente torna o processo determinístico, para que a especificação seja transformada corretamente em software. Isto gera uma grande valorização dos processos e uma conseqüente desvalorização das pessoas, no desenvolvimento de um software.

Crescimento exponencial do custo de alteração

No modelo de desenvolvimento tradicional, em cascata, o custo de uma alteração cresce exponencialmente, à medida que o processo de desenvolvimento avança (figura 1.3). Esta premissa básica da engenharia de software tradicional foi formulada por Boehm em Software Engineering Economics. A aceitação desta premissa tem como conseqüência natural uma busca por processos determinísticos, já que estes prometem menos alterações e maior previsibilidade.

Este princípio também reflete e justifica de certa forma, a busca pela aproximação conceitual entre os processos de desenvolvimento de software e os processos industriais típicos, ou seja, justifica a busca por metodologia lineares, determinísticas, especializadas e focadas na execução.

Segundo Brooks, isto não seria nenhum problema se o processo de desenvolvimento tradicional, em cascata, não estivesse errado nas seguintes afirmações:

O modelo em cascata assume que o projeto irá passar por cada etapa apenas uma vez. Ou seja, assume que a arquitetura é excelente, que o design é correto e que a implementação pode ser corrigida durante os testes. Nenhuma destas afirmações funciona bem na prática, seja no modelo em cascata tradicional, seja nas metodologias iterativas e incrementais que empregam “cascatas menores” dentro de cada iteração (figura 1.2).

O modelo em cascata puro, assume que o sistema todo é construído de uma única vez. Isso implica que para poder testar todo o sistema é preciso que todas as fases anteriores, desde o levantamento dos requisitos até a implementação estejam concluídas e integradas num sistema único. Na prática, entre outros problemas relacionados, os erros ocorrem em todas as etapas do desenvolvimento e deixar os testes para depois da implementação é algo altamente ineficiente.

Problema do desenvolvimento tradicional

O grande problema do desenvolvimento tradicional é que ele baseia-se em premissas que não se aplicam ao trabalho de desenvolvimento de software.

Segundo Drucker, existem duas categorias de trabalhadores: o trabalhador manual e o trabalhador do conhecimento. Um trabalhador manual executa atividades que dependem basicamente de habilidades manuais e que não se baseiam no uso intensivo do conhecimento. São atividades relativamente fáceis de automatizar por serem altamente determinísticas e repetitivas. O trabalhador do conhecimento, em contrapartida, é aquele que produz com base no uso intensivo da criatividade e do conhecimento.

Apesar de ser um trabalho executado basicamente por trabalhadores do conhecimento, o desenvolvimento tradicional utiliza premissas que só são válidas para o trabalhador manual.

Segundo Vinicius Teles: “Inúmeros estudiosos, entre eles Drucker, DeMarco, Lister, Toffler e DeMarsi têm demonstrado que a produtividade do trabalho do conhecimento deriva de fatores completamente diferentes daqueles usados para o desenvolvimento tradicional. De fato, eles mostram que as premissas da produtividade do trabalho do conhecimento são praticamente opostas às do trabalho manual e o grande erro cometido na maioria dos projetos de software é desconsiderar este fato e adotar as mesmas práticas do ambiente industrial.”.

Um exemplo da grande diferença em relação ao trabalhador manual e do conhecimento está na escolha da melhor política para tratar a ocorrência de erros. Para atividades que envolvem trabalhadores manuais, erros podem e devem sempre ser evitados, e os processos rígidos e determinísticos ajudam a alcançar este objetivo. Já para atividades que envolvem trabalhadores do conhecimento, erros devem ser encarados como coisas naturais, saudáveis e até inevitáveis. Neste caso, tentar sistematizar ou impor metodologias rígidas ao processo de desenvolvimento, visando o determinismo, no máximo torna as pessoas envolvidas defensivas e pouco criativas.

Resultados do Desenvolvimento Tradicional

Desde 1994, o Standish Group International publica a cada dois anos um estudo intitulado de Chaos Research que consolida as informações de uma grande pesquisa sobre sucessos e fracassos dos projetos de software (figura 1.4). Neste estudo, os resultados dos projetos são enquadrados em uma das seguintes categorias:

• Bem sucedidos: O projeto é finalizado no prazo, dentro do orçamento e contendo todas as funcionalidades especificadas.
• Comprometidos: O projeto é finalizado e um software operacional é entregue, porém o orçamento e o prazo ultrapassam os limites estipulados, e, além disso, o software entregue possui menos funcionalidades do que o especificado.
• Fracassados: O projeto é cancelado em algum momento durante o desenvolvimento.

Este estudo é bastante abrangente, pois engloba uma grande quantidade de projetos com as mais diversas metodologias de desenvolvimento. Porém, apesar da diversidade de metodologias, a grande maioria delas é baseada no desenvolvimento tradicional. A figura 1.4 mostra que apesar de ter ocorrido um aumento substancial da porcentagem de projetos bem sucedidos e diminuição de fracassados, os últimos resultados ainda são muito ruins, pois os projetos fracassados e comprometidos equivalem a 66% do total.

Como já foi dito neste trabalho, todas as metodologias tentam, entre outras coisas, reduzir o alto risco associado ao desenvolvimento de software. Porém, de acordo com os resultados alarmantes conseguidos nos últimos anos (figura 1.4), está claro que o desenvolvimento tradicional não tem conseguido atingir este objetivo. Estes resultados respaldam a afirmação de Brooks (seção 1.2.5) de que o desenvolvimento tradicional é equivocado.

Desenvolvimento Ágil

O desenvolvimento ágil é um fruto da constatação feita, de forma independente, por diversos profissionais renomados na área de engenharia de software, de que, apesar de terem aprendido segundo a cartilha tradicional, só conseguiam minimizar os riscos associados ao desenvolvimento de software, pensando e agindo de forma muito diferente do que tradicionalmente está nos livros. Estes profissionais, a maioria veteranos consultores para projetos de softwares, decidiram reunir-se no início de 2001 durante um workshop realizado em Snowbird, Utah, EUA.

Embora cada envolvido tivesse suas próprias práticas e teorias preferidas, todos concordavam que, em suas experiências prévias, os projetos de sucesso tinham em comum um pequeno conjunto de princípios. Com base nisso eles criaram o Manifesto para o Desenvolvimento Ágil de Software, freqüentemente chamado apenas de Manifesto Ágil. O termo Desenvolvimento Ágil identifica metodologias de desenvolvimento que adotam os princípios do manifesto ágil. Estes princípios são os seguintes:

Saiba mais: Análise e Projeto Orientado a Objetos

• 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;
• Responder a mudanças mais que seguir um plano.

O manifesto reconhece o valor dos itens à direita, mas diz que devemos valorizar bem mais os itens à esquerda.

No desenvolvimento ágil, os projetos adotam o modelo iterativo e em espiral (figura 1.5). Neste processo, todas as fases descritas no modelo em cascata são executadas diversas vezes ao longo do projeto, produzindo ciclos curtos que se repetem ao longo de todo o desenvolvimento, sendo que, ao final de cada ciclo, sempre se tem um software funcional, testado e aprovado. Os ciclos são chamados de iterações e crescem em número de funcionalidades a cada repetição, sendo que, no último ciclo, todas as funcionalidades desejadas estarão implementadas, testadas e aprovadas.

Premissas do Desenvolvimento Ágil

O cliente aprende ao longo do desenvolvimento, à medida que é capaz de manipular o sistema.

Um dos problemas mais complexos que afetam o desenvolvimento de software é a enorme quantidade de detalhes que precisam ser considerados. Normalmente, ao especificar um sistema, o cliente tem o conhecimento de alguns aspectos do software que deseja. Entretanto, muitos outros só ficam claros quando ele tem a oportunidade de utilizar o sistema. Portanto, o cliente não especifica estes detalhes no início do projeto por uma razão muito simples: ele não os conhece. Além do mais, mesmo que tais detalhes fossem conhecidos previamente, seria muito difícil especificá-los através de documentos, devido à grande quantidade de elementos que precisariam ser descritos.

Perceber que o cliente aprende ao longo do desenvolvimento é a chave para se compreender o grande desafio existente no desenvolvimento de software. O cliente aprende à medida que tem acesso ao sistema e se envolve em discussões sobre ele. Este aprendizado pode ser utilizado para realimentar o processo de desenvolvimento ou pode ser ignorado. Esta última alternativa é o caminho adotado normalmente no desenvolvimento tradicional, pois ele parte da premissa que o cliente já sabe o que quer no início do projeto e a ele cabe apenas descrever os requisitos. Depois, ao final, ele receberá o sistema e não haverá ciclos de realimentação entre a especificação e a entrega do sistema.

O custo de uma alteração mantém-se estável a partir de um certo ponto no projeto.

Ao contrário do desenvolvimento tradicional que acredita que o custo de uma mudança cresce exponencialmente a medida que o tempo de desenvolvimento avança, no desenvolvimento ágil acredita-se que o custo de mudança do software ao longo do tempo tende a se tornar constante (figura 1.6). Tal idéia se fundamenta, entre outros, nos seguintes fatores: avanços ocorridos na microinformática, adoção da orientação a objetos, uso da refatoração para aprimorar e simplificar o design, adoção de testes automatizados, melhores linguagens e ambientes de desenvolvimento.

As duas premissas anteriores ajudam a explicar algumas das posições totalmente opostas adotas pelos dois modos de desenvolvimentos. Por exemplo, no desenvolvimento ágil, modificações no projeto são naturais, pois não existe nenhum custo exponencial associado às alterações. Ou seja, não existe nenhuma necessidade de tentar especificar detalhadamente tudo que ocorrerá durante a implementação do sistema, para tentar minimizar possíveis alterações, até porque, isto dificilmente traz os resultados esperados.

Conclusões

No desenvolvimento ágil os envolvidos no desenvolvimento são tratados como trabalhadores do conhecimento e conseqüentemente são estimulados a aprender durante o desenrolar do próprio trabalho e tomar decisões melhores com base neste aprendizado. Não existe um processo rígido que impõe o que pode ou não ser feito e desestimula a criatividade.

No desenvolvimento tradicional, os especialistas do negócio conversam com os analistas, que digerem, abstraem e passam as informações mastigadas aos programadores, que não pensam nada além do necessário para escrever o código do software. Esta especialização (seção 1.2.3) de atividades é péssima porque é completamente desprovida de feedback. O analista tem toda a responsabilidade de criar o modelo de domínio, baseado somente nas informações fornecidas pelos especialistas do negócio. Eles não têm a oportunidade de aprender com o desenvolvimento ou ganhar experiência com as versões iniciais do software.

O desenvolvimento ágil sabe que trabalhadores do conhecimento rendem mais e melhor em ambientes que estimulam o uso intensivo da criatividade e do conhecimento. Escrever softwares é um trabalho tão ou mais criativo que escrever um livro, um artigo ou uma monografia. É uma atividade tipicamente intelectual, onde é muito comum ocorrerem idas e vindas, já que o aprendizado adquirido com o seu desenrolar torna possível aos envolvidos perceberem maneiras cada vez melhores de fazerem as coisas. Este tipo de trabalho – não linear – funciona muito melhor de forma iterativa e incremental (em espiral).

Considerações finais

Este trabalho tem como objetivo principal mostrar em detalhes como funciona e quais as vantagens da Programação Extrema ou XP (Extreme Programming), que é a metodologia de desenvolvimento ágil mais conhecida na atualidade. Esta introdução é muito importante, pois aborda características comuns a todos os processos ágeis, incluindo, é claro, a XP, que apesar de ter sua identidade garantida por um conjunto rico de características próprias, em essência, é mais uma metodologia ágil.

Outros exemplos de metodologias ágeis são: SCRUM, Adaptive Software Process, Feature Driven Development (FDD), Crystal, Agile Modeling e Win-Win Spiral.