As Metodologias Ágeis

Cap. 3

        No capítulo citado, o autor explica e exemplifica a diferença entre o desenvolvimento ágil e o desenvolvimento planejado de softwares, apontando também os maiores motivos de procura em cada caso.

        O processo de desenvolvimento rápido de software tem o intuito de construir em menos tempo um software útil. O software é constituído de uma série de incrementos, cada um com sua funcionalidade, e embora existam muitas maneiras de desenvolvimento, elas compartilham algumas características fundamentais, tais como:

• Não há especificação detalhada do sistema, a documentação é feita de forma geral pelo ambiente de implementação do sistema e o documento de requisitos do usuário apenas define as características mais importantes ao sistema.
• Há várias versões para o mesmo sistema, onde os usuários e os stakeholders (partes interessadas) participam da especificação e avaliação de cada versão, apontando o que pode ser melhorado e implementado em uma próxima versão do sistema.
• Processos de desenvolvimento ágil tem como característica interfaces interativas com desenhos e posicionamento de ícones que visam o fácil acesso, a fácil visualização e fácil interação com o sistema.

Os métodos ágeis são métodos de desenvolvimento incremental, em que os incrementos (partes que juntas formam o todo) são pequenos e normalmente as novas versões do sistema são disponibilizadas a cada duas ou três semanas, assim possibilitando um feedback rápido sobre a evolução dos requisitos.

3.1 Métodos ágeis

        Na década de 1980 e início da de 1990, a comunidade de engenharia de software, responsável pelo desenvolvimento de sistemas de software grandes e duradouros, como sistemas aeroespaciais e de governo, passava uma visão que foi generalizada de que a melhor maneira para se obter a máxima qualidade em um software era através de um planejamento bem elaborado, qualidade de segurança formalizada, uso de métodos de análise e projeto apoiado por ferramentas CASE (Computer-aided software engineering) e do processo de desenvolvimento de software rigoroso e controlado. Esse software era produzido por grandes equipes que trabalhavam para diferentes empresas, muitas dispersas geograficamente que trabalhavam com o software por longos períodos de tempo.

        A inequação desse método para pequenas e médias empresas e outras ocasiões levou um grande número de desenvolvedores de software a proporem, na década de 1990, novos “métodos ágeis”, que focava no software em si e não na sua concepção e documentação.

        Métodos ágeis são mais adequados ao desenvolvimento de aplicativos nos quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento, pois possuem como objetivo a entrega do software de maneira rápida e que ele possa ser facilmente modificado e evoluído. E possuem também como objetivo reduzir a burocracia do processo e qualquer documentação que provavelmente nunca será usada.

        Exemplos de métodos ágeis são a Extreme Progamming (BECK, 1999; BECK, 2000), Scrum (COHN, 2009; SCHWABER, 2004; SCHWABER e BEDDLE, 2001), Crystal (COCKBURN, 2001; COCKBURN, 2004), Desenvolvimento de Software Adaptativo (Adaptative Software Development), (HIGHSMITH, 2000), DSDM (STAPLETON, 1997; STAPLETON, 2003) e Desenvolvimento Dirigido a Características (Feature Driven Development), (PALMER e FELSING, 2002). O sucesso desses métodos levou a uma certa integração com os métodos mais tradicionais resultando no conceito de modelagem ágil (AMBLER e JEFFRIES, 2002) e instâncias ágeis do Rational Unified Process (LARMAN, 2002).

        Embora os todos métodos sejam baseados no método incremental e dividam os mesmos princípios, os processos são diferentes para alcançar seus objetivos. A tabela abaixo (encontrada na página 40 do livro), foca nos dois métodos mais usados: Extreme Programming e Scrum.[pic 1]

Na prática, os princípios básicos dos métodos ágeis são difíceis de se concretizar, por diferentes motivos não técnicos, tais como:

• O processo ágil de desenvolvimento precisa da participação do cliente no processo de desenvolvimento, e por vezes, o cliente não pode participar plenamente do processo.
• O cliente que participa do desenvolvimento pode não ter o necessário para avaliar o sistema por toda a empresa que representa.
• Membros da equipe de desenvolvimento podem ter problemas de interação com outros membros da equipe, o que prejudica o processo.
• Cada stakeholder possui necessidades diferentes, e assim precisam de mudanças diferentes.
• A pressão dos cronogramas torna difícil a implantação da simplicidade, que necessita de um trabalho extra.
• A difícil aceitação do sistema por organizações que passaram anos mudando sua cultura para que os processos fossem definidos e seguidos, tornando difícil a mudança de um trabalho em que os processos são informais e definidos pelas equipes de desenvolvimento.

Os métodos citados contam com contratos nos quais o cliente paga pelo tempo necessário para o desenvolvimento, o que pode dificultar na definição de quem é culpado (cliente ou desenvolvedor) caso haja problemas.

Para o autor, há duas questões a serem consideradas quando se trata da manutenção de métodos ágeis:

1. É possível fazer manutenção dos sistemas desenvolvidos em uma abordagem ágil, dada a ênfase do processo de desenvolvimento em minimização da documentação formal?
2. Os métodos ágeis podem, efetivamente, ser usados para a evolução de um sistema em resposta às solicitações de mudança do cliente?

A documentação, supostamente, serve para descrever o sistema e assim tornar mais fácil seu uso e manutenção, mas a documentação nem sempre é atualizada. Por isso, os métodos ágeis acham desnecessário a criação de uma documentação, e a chave para a fácil manutenção é a produção de códigos de alta qualidade, legíveis e de fácil entendimento. Fazendo da documentação, algo descartável. No entanto, para o autor, o documento-chave é o documento de requisitos do sistema, que informa ao engenheiro de software o que o programa deve fazer. Pois sem ele é difícil avaliar o impacto das mudanças propostas.

...