Um dos grandes riscos no desenvolvimento de software está atrelado à mudança de requisitos. A qualidade dos requisitos do sistema podem não encontrar a corretude, a completude e a consistência, e assim a próxima fase do processo de desenvolvimento pode ser atrasada [53]. No modelo iterativo de desenvolvimento os usuários podem prover os requisitos de forma incremental [53]. O risco de desenvolvimento de software pode ser altamente reduzido, através de protótipos que criam um canal de comunicação com os usuários [53]. Os protótipos podem ajudar no reconhecimento de requisitos incompletos, inconsistentes ou incorretos [53].
No Scrum, os riscos referentes ao levantamento de requisitos, podem ser atenuados pelo fato do usuário fazer parte da equipe. O dono do produto (PO), entende o progresso do desenvolvimento, testando e auditando os requisitos da nova versão. Todos os dias nas reuniões diárias de quinze minutos é estabelecida uma comunicação efetiva entre cliente e time de desenvolvedores. Adicionalmente as estórias de usuários, reduzem a complexidade do software e o PO verifica os entregáveis documentais da próxima iteração enquanto valida o software entregue na iteração corrente [53].
A análise da arquitetura do projeto necessita ser pensada de forma antecipada, assim como as dependências técnicas para determinar quais componentes são necessários antes do início da implementação das estórias de usuários [77]. Também aconselha-se controlar os débitos técnicos, ligados às lacunas tecnológicas, imperfeições estruturais, diferente- mente das que podem ser analisadas por ferramentas de verificação de código [77]. Além disto, é recomendável medir também as opções através da análise de custo VPL (valor presente líquido), pois segundo o autor as predições econômicas, apesar de imprecisas,
por vezes são mais convincentes do que dogmas ágeis, princípios de design genérico ou experiências passadas [77].
Os projetos ágeis distribuídos possuem alguns fatores de risco, tais como: distância espacial, distância temporal (fuso-horários), barreira da língua, cultura de trabalho e um projeto com um escopo grande. Todos estes fatores geralmente, são arriscados quando se utiliza métodos ágeis, onde a colaboração face a face é um requisito primordial [97]. Nesta situação, as cerimônias do Scrum não são realizadas com a devida frequência e quando ocorrem levam mais que o tempo recomendado de 15 minutos, muitas ficam entre 45 a 60 minutos e comprometem a agilidade [97]. Não obstante, o PO está fora do ambiente de desenvolvimento comprometendo a comunicação, assim como o Scrum Master que também não consegue capturar rapidamente os impedimentos da equipe [97].
Pesquisas indicam que de forma geral, as principais limitações no uso dos métodos ágeis são: a falta de uma fase de planejamento, restrições orçamentárias, documentação insuficiente, desobediência aos passos do ciclo de vida de desenvolvimento do software, falta de previsibilidade, excesso de reuniões, atendimento apenas regular aos requisitos de conformidade, necessidade de capacitação e por fim, não é recomendado para pequenas organizações [5].
Além disto, alguns métodos ágeis não estão seriamente comprometidos com os usuários finais. Eles focam na entrega de valor ao cliente, e não na entrega de qualidade para os usuários finais [54]. O papel de dono do produto - PO, deveria expressar as necessidades do usuário final, enquanto responsável pelas necessidades do cliente [54]. Porém, muitas vezes este papel tem sido delegado a pessoas do time de desenvolvimento, ao invés de um representante da população de usuários ou o próprio cliente [54].
Fatores como cultura organizacional são importantes quando se fala em métodos ágeis. Pode-se assumir que quanto mais formalizado um método ágil se tornar, mais cedo será considerado disfuncional em organizações com forte cultura em desenvolvimento [56]. Culturas organizacionais hierárquicas não favorecem a implantação de metodologias ágeis [56]. Uma estrutura de matriz funcional não provê a autoridade necessária ao Scrum Master para a retirada dos impedimentos, fazendo com que ele necessite negociar com o gerente funcional das demais áreas para priorizar o atendimento de certas demandas, quebrando a agilidade da equipe.
Para ilustrar os riscos que comumente ocorrem em projetos de desenvolvimento de software e como eles podem ser reduzidos com os método ágeis, o Quadro 2.3 demonstra que ao utilizar as metodologias ágeis, a maioria dos impactos dos riscos são minimizados. Como pode-se verificar apenas o risco de inadequação de design do software poderá ter um impacto aumentado utilizando métodos ágeis, isso se deve ao fato que o design não é pensado de forma geral e sim a cada iteração, sendo criado de forma contínua, pois o
Quadro 2.3: Riscos comuns de Software. Adaptado de Albadarneh et al. (2015) [6]
Riscos comuns no processo de desenvolvimento de software Impacto ágil sob o risco
Escopo que se arrasta Reduz
Cronograma extremamente otimista Reduz Requisitos aprimorados ou desenvolvedores aprimoradores (gold-plating) Reduz
Qualidade alterada Reduz
Design (no sentido de projetizar/arquiteturar) inadequado Provavelmente aumenta Problemas entre desenvolvedores e clientes Reduz
Risco de orçamento Reduz
Custo de cancelamento Reduz
Erro de requisito Reduz
Risco tecnológico Reduz
Risco de segurança Reduz
Baixa competência técnica da equipe Indiferente
Falha do contratado Indiferente
Scrum, não cobre o ciclo de vida completo do desenvolvimento de software [6]. Porém na Iteração Zero no XP e no estudo do negócio no DSDM, a criação de um design com a visão do todo, seria possível [6]. Outros fatores de risco como: baixa competência técnica da equipe e falhas que podem ocorrer no contrato não são minimizados pelo simples fato de se utilizar métodos ágeis, devendo então estes riscos serem tratados como em qualquer outro método de desenvolvimento. Porém, mais de 75% dos riscos levantados no Quadro 2.3, são reduzidos com o uso dos métodos ágeis pelo fato do escopo e do prazo serem fixados na Sprint e com a comunicação diária da equipe provendo transparência, torna-se difícil esconder uma situação de risco [6]. No caso do risco: "escopo que se arrasta", ou seja, quando há aumento do escopo, este irá para o backlog e necessitará ser priorizado pelo cliente. Cronogramas otimistas demais podem ser corrigidos com um feedback do tempo das entregas realizadas em poucas semanas, isto irá ajustar a velocidade da equipe e as possíveis solicitações de mudanças também serão poucas se comparadas a pacotes de meses de trabalho.
A qualidade é flexível no ágil, podendo ser negociada, assim como aumenta a intera- ção entre clientes e desenvolvedores criando uma maior familiaridade e reduzindo entraves pessoais [6]. O orçamento é de fácil controle pois são apenas estimativas, assim como o custo do cancelamento, pois a medida que se tem entregas mais rápidas e contínuas fica evidente o aumento do custo e assim a qualquer momento o trabalho poderá ser parado, di- ferentemente de um método tradicional onde se demorariam meses até a primeira entrega para que então fosse realizada tal avaliação. Erros de requisitos poderão ser descobertos durante a implementação (reuniões diárias) e na reunião de revisão onde é realizada a apresentação da unidade funcional do software para o cliente. Nos métodos ágeis pro- blemas tecnológicos e de segurança são descobertos mais cedo, pois a cada iteração se tem um pedaço do produto sendo testado em um intervalo de poucas semanas, assim, os problemas são descobertos e tratados mais cedo [6].