Blog

A história por trás da Agilidade

desenvolvimento-programacao-software-sistema

Você sabe porque os métodos ágeis são tão usados no mercado?

Neste post darei uma visão abrangente da história dos métodos ágeis e como eles podem acelerar os processos na sua empresa, mas há inúmeros fatores que devemos levar em conta no momento da escolha da metodologia a adotar.

Desta forma, não podemos iniciar sem antes entender quais movimentos intelectuais serviram de base para a agilidade, afinal isto pode nos permitir ter uma visão mais ampla, compreendendo assim a evolução do pensamento ágil.

O termo”Ágil” foi usado pela primeira em meados 1990, junto com o surgimento da internet que conhecemos hoje. O termo foi escolhido para representar um movimento em resposta aos pesados e burocráticos métodos tradicionais de gerenciamento de desenvolvimento de softwares.

 

Modelo Cascata

 

O método tradicional, muito conhecido no desenvolvimento de software como um modelo em cascata, ou waterfall.

Esse modelo foi inicialmente descrito por Royce em 1970 e se caracteriza por uma sequência de fases de desenvolvimento, em que cada fase somente se inicia quando a anterior se encerra, e a saída de uma fase é a entrada da fase seguinte, como mostrado na figura. 

 

350px-modelo_em_cascata

Fonte : https://pt.wikipedia.org

Royce, no entanto, criticava o modelo em seu próprio artigo, afirmando que, para o desenvolvimento de software, seu uso era arriscado.

Portanto no modelo em cascata, o progresso de uma fase move-se para a próxima fase somente quando a fase anterior está completa e perfeita. Desenvolvimento de fases no modelo em cascata são discretas, e não há pulo para frente, para trás ou sobreposição entre elas.

Identificou-se então que o modelo Cascata não funciona tão bem em desenvolvimento de software, por alguns motivos:  na ausência de um processo de gestão do projeto e de controle das alterações bem definido, muitas vezes torna-se um ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar.

 O Modelo Incremental

Tendo em vista a limitação e barreiras do modelo tradicional, Barry Boehm sugeriu que o desenvolvimento de sistemas de informação poderia ser administrado numa série de incrementos. Sendo assim, deveria haver uma série de ciclos de vida tradicionais para cada incremento.

O Modelo Incremental foi desenvolvido através da combinação entre os modelos linear e prototipação.

O desenvolvimento é dividido em etapas, denominadas “incrementos”, que produzirão incrementalmente o sistema, até a sua versão final.

Em cada incremento é realizado todo o ciclo do desenvolvimento de software, do planejamento aos testes do sistema já em funcionamento.

O Modelo Incremental apresenta diversas vantagens para o desenvolvimento de um software, especialmente quando os requisitos não estão claros inicialmente. Desta forma, muitos requisitos básicos são implementados, e os detalhes suprimidos apos validação. Esse produto será entregue para uma avaliação, que poderá detectar, inicialmente, problemas que poderiam ser de dimensões muito maiores se detectados somente na entrega do produto final.

Outras possíveis vantagens são:

  • A construção de um sistema menor, demanda menos tempo, menor custo e é sempre menos arriscada que a construção de um grande;
  • Se houver um erro, apenas o último incremento pode ser descartado;
  • Reduzindo o tempo de desenvolvimento de um sistema, as chances de mudanças nos requisitos do usuário durante o desenvolvimento são menores.

O uso de análise e medições como guia do processo de aprimoramento é uma das maiores diferenças entre o desenvolvimento iterativo e o atual Desenvolvimento ágil de software.

 O Modelo Espiral

O modelo espiral, também nos mostra a evolução de pensamentos entre acertos e erros, onde o modelo proposto por EPS (Boehm, 1988) – Evolutionary Spiral Process baseia-se em quatro principais atividades:

  • Determinação dos objetivos, alternativas e restrições;
  • Análise de risco e prototipação;
  • Validação e verificação;
  • Planejamento da fase seguinte.

Este modelo tende a criar um roteiro de atividades e etapas para que se alcance uma maturidade do processo evolutivo de desenvolvimento de sistemas a fim de obter, ao final, um produto em sua forma mais completa possível.

Problemas do Modelo espiral

  • O modelo em espiral, por suas características de avaliação e planejamentos baseadas em riscos, exige uma equipe sênior como gerentes e técnicos experientes.
  • As tarefas gerenciais para acompanhamento e controle do projeto são bem mais complexas, uma vez que o modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado.
  • É necessário alem de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

Prototipação

Baseado no desenvolvimento de um protótipo em engenharia, com base no conhecimento dos requisitos iniciais para o sistema. O desenvolvimento ocorre obedecendo à realização das diferentes etapas de análise de requisitos, o projeto, a codificação e os testes.

A definição de todos os requisitos necessários ao sistema pelo cliente ou usuário geralmente é um dos maiores desafios de desenvolvimento de software.

Sendo quase impossível prever como o sistema irá afetar o funcionamento das atividades dos usuários, como deve ser a interação com outros sistemas e quais operações dos usuários podem ser automatizadas sem maiores impactos.

Desta forma, poder testar os requisitos de uma forma mais eficiente, é necessária a utilização de um protótipo do sistema, ou seja, uma versão inicial de um sistema de software, que é utilizada para mostrar conceitos, experimentar opções de projeto e, em geral, para conhecer mais sobre os problemas e suas possíveis soluções.

 

Um protótipo de software apóia duas atividades do processo de engenharia de requisitos:

  • Levantamento de requisitos
  • Validação de requisitos

Desvantagens:

  • Definir quando um protótipo é potencialmente um produto.
  • Ajustes no codigo pode gerar retrabalhos para que o produto seja aceito.

No Comment

1

Post A Comment