Artigos Canal Mais Adoção de metodologias ágeis - Revista Engenharia de Software Magazine 55
Artigo do tipo Teórico
Recursos especiais neste artigo:
Conteúdo sobre Agilidade.
Adoção de metodologias ágeis
Na busca por processos de desenvolvimento de software mais flexíveis e capazes de suportar ambientes de negócio altamente voláteis e imprevisíveis, várias organizações optam pela adoção de metodologias ágeis. Além de propor algumas recomendações em geral desprezadas, este artigo identifica e explora aspectos que, ora surgem como obstáculos, ora servem de estímulo ao sucesso dessas iniciativas de adoção. Os aspectos propostos e questionamentos levantados sugerem uma abordagem que pode minimizar os impactos negativos comuns aos processos de mudança organizacional.

Em que situação o tema útil
Se a sua organização tem planos para a adoção de metodologias ágeis, a utilidade da discussão proposta neste artigo vai se consolidar quando, ao invés de apenas almejar uma mera adaptação de uma ou outra teoria ao nosso ambiente de negócio, a verdadeira meta for a solução dos desafios e problemas atuais da organização.

Um processo de desenvolvimento de software é um conjunto de atividades e resultados associados que levam à produção de software. Ao longo da história da Engenharia de Software foram concebidos vários modelos de processos de desenvolvimento de software e nenhum deveria ser considerado como ideal ou solução para todos os contextos possíveis. Todos os modelos compartilham de fases essenciais como: especificação, projeto e implementação, validação e evolução; em geral definidas com o propósito de organizar e facilitar o gerenciamento das atividades que compõem o processo de desenvolvimento. Com o passar do tempo, os desafios atrelados ao desenvolvimento de software, tarefa cada vez mais complexa, impuseram novas demandas aos modelos até então utilizados.

Uma das principais demandas surgiu e vem somando força em contextos de negócio cada vez mais marcados pelas constantes mudanças. O cenário de imprevisibilidade não encontrou respaldo nos processos de desenvolvimento, os quais, orientados por uma estrutura rígida e altamente preditiva, não priorizavam a flexibilidade e a adaptação. Diante do desafio de responder com mais rapidez às mudanças, engenheiros de software, percebendo fraquezas na engenharia de software convencional, buscaram soluções para inovar os processos de desenvolvimento, originando o que foi denominado de “movimento ágil”.

A essência desse movimento, definido como agilidade, pode ser traduzida como a disponibilidade contínua de um método para rapidamente ou inerentemente criar a mudança, pró-ativamente ou reativamente adotar a mudança, e aprender com a mudança, enquanto contribui para o valor percebido pelo cliente (economia, qualidade e simplicidade), por meio de seus componentes coletivos e relação com seu ambiente.

Por mais promissora que seja uma teoria, o tempo e as tentativas para colocar em prática as ideias propostas seguramente culminarão numa nova realidade marcada pelo confronto entre as promessas e os resultados obtidos. Abordando o “universo” das metodologias ágeis, essa nova realidade dificilmente se estabiliza num mar de unanimidades e é muito fácilencontrar evidências que suportem diferentes perspectivas (sejaa dos entusiastas, a dos detratores, a dos indecisos, a dosevangelistas, a dos diferentes mercados, a dos vendedores de certificação, etc.).

Tomando como base diversos fatores por trás do sucesso e do fracasso das iniciativas de adoção das metodologias ágeis, a proposta deste artigo é explorar aspectos que, servindo de recomendações para nos anteciparmos aos desafios e riscos de tais iniciativas, também possam garantir ao máximo a produtividade das organizações, das equipes e do indivíduo rumo à melhoria contínua mesmo diante do ritmo crescente de mudanças.

História e Contexto

A “pedra fundamental” dos Métodos Ágeis é o IIDD (desenho e desenvolvimento iterativo e incremental), um método adotado há cerca de 70 anos. Como o termo “Metodologias Ágeis”só foi formalizado em 2001 por um grupo de especialistas em processos de desenvolvimento de software, muita gente ainda se anima com o “tema” assumindo que encontraram a solução mais “moderna” para substituir os velhos culpados pela situação de caos dos nossos projetos. Objetivando algo muito além da mera formalização de novos termos, o grupo de especialistas, depois de alguns encontros, apresentou uma série ou níveis de acordos que estabeleciam, na verdade, um novo paradigma para o desenvolvimento de software.

Estes acordos, essencialmente representados pelo que ficou conhecido como “Manifesto Ágil”, serviram e ainda servem como fundamento para a definição de processos de desenvolvimento caracterizados pela adaptabilidade, transparência (ou visibilidade), simplicidade e unidade. A abordagem proposta por estes novos processos, em resposta aos modelos tradicionais (rígidos e altamente preditivos), pode ser resumida da seguinte forma:

Primeiro nível: Precisamos de métodos particularmente desenhados para suportar e responder à volatilidade de projetos onde a única constante é a mudança. Ágil (ou Agile) foi o termo escolhido, visto que também permitia englobar projetos críticos com equipes enormes que, mesmo exigindo metodologias longe de parecerem “leves”, ainda requerem agilidade;

Segundo nível: Nosso propósito é descobrir maneiras melhores de se desenvolver software,e ao desenvolver, queremos que as pessoas também se desenvolvam. Queremos valorizar:

· Indivíduos e interações ao invés de processos e ferramentas;

· Software operante ao invés de documentações completas;

· Colaboração do cliente ao invés de negociações contratuais;

· Responder a mudanças ao invés de seguir um planejamento.

Atenção especial deve ser dada ao formato em que os valores acima foram apresentados: o primeiro segmento (em negrito) indica a preferência, enquanto o último descreve um item que, embora importante, é de prioridade menor. Muita gente confunde a proposta e elimina processos, ferramentas, documentação, contratos e planejamento.

Terceiro nível: Para sustentar os valores citados, precisamos criar princípios que devem ser seguidos:

· Priorizamos a satisfação do cliente através da entrega contínua e, desde cedo, de software com valor;

· Mudanças de requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Utilizamos a mudança em favor da vantagem competitiva do cliente;

· Entregar frequentemente software em funcionamento, desde a cada duas semanas até a cada dois meses, com uma preferência por prazos mais curtos;

· Pessoas do negócio e desenvolvedores devem trabalhar em conjunto diariamente por todo o projeto;

· Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e o suporte de que precisam e confie neles para fazerem o trabalho;

...
Quer ler esse conteúdo completo? Tenha acesso completo