ANÁLISE DA IMPLANTAÇÃO DA METODOLOGIA ÁGIL SCRUM PARA GERENCIAMENTO DE PROJETOS DE DESENVOLVIMENTO DE SOFTWARE

...

O processo de coleta dos requisitos é intensificada e passa a focar especificamente no software. Os requisitos do sistema e do software são então documentados e revisados junto ao cliente. Ao fim da etapa de requisitos, terá sido criada uma especificação minuciosamente detalhada e acordada entre as partes que servirá como referência e irá guiar as etapas seguintes do projeto.

A TechRepublic (2014), argumenta que o método Cascata, como é descrito acima, oferece uma série de vantagens aos desenvolvedores de software. Primeiro, o estágio de desenvolvimento enfatiza a disciplina: cada fase possui um ponto de início e fim definidos, e o progresso pode ser claramente identificado com o uso de milestones (marcações que definem pontos importantes no cronograma do projeto), tanto pelo desenvolvedor quanto pelo cliente. A ênfase dada aos requisitos e arquitetura antes de se escrever uma única linha de código garante mínimo desperdício de tempo e esforço, e reduz o risco de descumprimento do cronograma, ou das expectativas do cliente não serem atendidas.

O rigor formal, em especial no que se refere à documentação, é uma das características que permeiam o método Cascata. Privilegia-se a elaboração de uma boa documentação de todos os elementos obtidos e produzidos em todas as fases dos projetos, além dos respectivos artefatos. Tudo aquilo que é documentado como pertencente ao escopo do projeto é considerado objeto do desenvolvimento (TOMOMITSU, 2008).

Embora a proposta original de Royce (1970), fizesse considerações sobre a importância de “curvas de feedback” entre as fases do processo, a grande maioria das organizações que aplicam este modelo faz uso de uma abordagem estritamente linear Além disso, muitas vezes é difícil para o cliente declarar todos os requisitos do software explicitamente. O método Cascata exige isso e tem dificuldade em acomodar a incerteza natural que existe no início de muitos projetos. O cliente precisa ter paciência. Uma versão em desenvolvimento do programa não estará disponível até uma das fases finais do projeto. Uma grande falha, se não for detectada até que o programa chegue à fase de revisão/teste, pode ser desastroso. (PRESSMAN, 2001).

Um dos maiores problemas com o Cascata é que ele assume que todos os requisitos do projeto podem ser assertivamente coletados no início do projeto. Os analistas de requisitos precisam trabalhar exaustivamente por semanas ou meses compilando tudo o que eles puderem juntar sobre o sistema proposto em uma especificação clara e detalhada. Uma vez finalizada, a especificação é enviada para o time de designers que irá se incumbir das próximas fases, enquanto os analistas de requisitos são liberados para assumir outros projetos. (SZALVAY, 2004).

Nenhuma destas etapas incrementais contribuem tanto para o produto final quanto as etapas de análise e programação e todas aumentam os custos de desenvolvimento. Por isso, os clientes tipicamente tendem a não querer pagar por elas e os desenvolvedores tendem a não querer implementá-las. (ROYCE, 1970).

Um dos principais problemas com as abordagens tradicionais é que elas procuram se precaver contra o futuro ao invés de estarem preparadas para ele. Como a premissa técnica básica é que o custo das alterações aumenta quase que exponencialmente com o tempo, é preciso fazer planejamento e modelagem prévios em larga escala. Isto tem o efeito colateral de tornar o desenvolvimento de software uma aposta: todas as fichas são colocadas nos modelos e especificações de requisitos que são criados no início do projeto. Neste contexto, a mudança é uma inimiga, pois irá certamente ferir o planejamento, com consequências sobre alguma(s) das variáveis da gestão do projeto. Da visão negativa da mudança, surge a necessidade de controlá-la de modo férreo, o que acaba por gerar ainda mais efeitos negativos: as pessoas envolvidas no projeto, tanto a equipe de desenvolvimento quanto os clientes, são desestimulados a sugerir inovações.

No contexto de desenvolvimento de software, o termo “ágil” tende a caracterizar abordagens específicas de trabalho, para Highsmith (2002a), agilidade é a habilidade de criar e responder à mudança de forma a lucrar em um ambiente turbulento de negócios. A seguir são apresentadas outras definições:

Ágil – denota “a qualidade de ser rápido, prontidão para movimentar-se, agilidade, ação, destreza no movimento” – métodos de desenvolvimento de software tentam oferecer mais uma vez uma resposta à ansiosa comunidade dos negócios buscando por processos de desenvolvimento ao mesmo tempo leves, rápidos e ágeis. Isto aplica-se em especial ao cenário de crescimento rápido e volátil da indústria de softwares da Internet assim como o cenário emergente de aplicações para telefonia móvel. (ABRAHAMSSON, 2002).

Agilidade e dinâmica, específica do contexto, e orientada pelo crescimento. Não é sobre crescimento de eficiência, redução de custos etc. É sobre sucesso e vitória: obter sucesso em áreas emergentes e competitivas, ampliando a lucratividade, a participação de mercado e clientes no centro do distúrbio de competitividade que muitas empresas temem atualmente. (GOLDMAN, 1994).

Segundo Highsmith (2002b), o conceito de desenvolvimento ágil surge em fevereiro de 2001, quando a Aliança Ágil redigiu o “Manifesto para Desenvolvimento Ágil de Software”. Os valores que deveriam ser honrados pelos “agilistas” são apresentados e detalhados a seguir:

Indivíduos e interações mais que processos e ferramentas: o movimento ágil enfatiza a relação e a comunalidade dos desenvolvedores de software e do papel humano que se reflete nos contratos, em oposição aos processos institucionalizados e ferramentas rígidas de desenvolvimento. Nas práticas ágeis existentes, isto se manifesta em equipes de trabalho de relação mais próxima, arranjos de ambiente de trabalho mais interconectados e outros procedimentos para catalisar o espírito de equipe.

Softwares funcionais mais que documentação: o objetivo vital da equipe de software é transformar continuamente o software de trabalho testado. Novos lançamentos são produzidos em intervalos frequentes, os desenvolvedores são encorajados a manter o código simples, direto e tão avançado tecnicamente quanto possível, diminuindo assim a carga de documentação desnecessária.

Colaboração com o cliente mais que negociações de contrato: é dada preferência ao relacionamento e à cooperação entre os desenvolvedores e clientes ao invés de manter o foco em contratos rigorosos, embora a importância dos contratos bem elaborados faz crescer no mesmo ritmo que o