Uma introdução à Agilidade em Projetos
Este artigo apresenta uma introdução à cultura e às práticas ágeis de desenvolvimento e gerenciamento de projetos de software. Com elas foi definida a base das metodologias ágeis existentes e amplamente utilizadas na atualidade.
Este artigo será útil no aprendizado inicial sobre os impactos e mudanças ocorridos quando se decide trabalhar com metodologias ágeis. Além disso, ajudará a entender melhor quais são as principais práticas ágeis usadas, bem como os benefícios que elas trazem às equipes de desenvolvimento e aos produtos desenvolvidos.
É notável a relevância que a indústria de software tem nas mais diversas áreas de mercado hoje em dia. A demanda por produtos de software para atender as necessidades de pessoas e empresas nas mais diversas áreas aumenta continuamente. Cada vez mais estes softwares têm que ser entregues com um alto nível de qualidade e a custos financeiros tangíveis aos clientes e fornecedores. Além disso, em inúmeros momentos também há a necessidade que se criem soluções simples para problemas cada vez mais complexos. No entanto, ao passo que esta demanda por software aumenta, nem sempre estes são entregues dentro de prazos e níveis de qualidade satisfatórios para os clientes e seus usuários.
Desde o início da atividade de criação e desenvolvimento de software, principalmente quando ela inseriu-se em âmbitos comerciais, busca-se estabelecer modelos e métodos padronizados para se atingir um objetivo pré-definido, que é fornecer um produto ao cliente atendendo aos seus níveis de qualidade, custo e duração necessários.
Um dos modelos mais tradicionais de desenvolvimento de software conhecido é o modelo cascata que, durante muito tempo, foi o principal utilizado para se desenvolver software. Ele define uma sequência estruturada de etapas a serem seguidas de forma a obter um produto final, que é o software concluído, conforme mostra a Figura 1.
Neste modelo, para que uma etapa seja iniciada, sua etapa anterior deve ter sido totalmente finalizada. Apenas após a última etapa deste processo o software é entregue ao cliente, sem que ele tenha tido a oportunidade de avaliar e validar parte do produto durante sua criação. Caso ocorra algum atraso em algumas destas etapas, todas as etapas seguintes serão afetadas, de forma que o atraso se propagará por todo o processo.
Figura 1. O Modelo Cascata de Desenvolvimento – Fonte: Sommerville, 2003.
Apesar de estruturar bem as etapas de desenvolvimento de software, o modelo cascata tem sido bastante criticado nos últimos anos por apresentar desvantagens como as mencionadas anteriormente e não atender de forma ágil e dinâmica as necessidades atuais dos clientes e do mercado.
Nos dias de hoje os requisitos de software mudam com frequência, pessoas entram e saem de projetos e empresas a todo instante, os prazos são cada vez mais curtos, o mercado dita diariamente novas necessidades de negócio, entre outros. Estes são apenas alguns dos motivos que fazem com que as equipes de desenvolvimento tenham que atender de forma rápida e organizada a todas as mudanças externas ao seu ambiente, sem que haja influência negativa no seu dia a dia nem nos produtos que elas criam.
Diante desse cenário, os modelos e metodologias tradicionais de desenvolvimento de software e gerenciamento de projetos não têm obtido uma taxa de sucesso satisfatória, de forma a atingir os objetivos estabelecidos por clientes e fornecedores. Um estudo realizado periodicamente pelo Standish Group, chamado Chaos Report, apresenta uma análise sobre um grande conjunto de projetos, informando, entre outros, as taxas de sucesso e insucesso deles, como mostra a Figura 2.
Figura 2. Taxas de Sucesso, Desafio e Fracasso em Projetos – Fonte: Chaos Report, Standish Group, 2010.
Nesta figura, o Standish Group divide os projetos em três grupos: Sucesso, Fracasso e Desafiado. O grupo dos projetos de sucesso engloba os projetos que foram entregues dentro do prazo, custo e escopo planejados. O grupo de projetos fracassados representa os projetos que foram cancelados ou entregues e nunca chegaram a ser utilizados. Já o grupo dos projetos desafiados representa os projetos que foram entregues, porém com atraso, ou fora do custo ou escopo planejados inicialmente.