Conforme você vem estudando ao longo desta disciplina, quando falamos em gerenciar projetos, não temos uma opção certeira para utilizar, pois o que pode funcionar muito bem para um projeto, pode não servir para outro. É por isso que se faz necessário conhecer e utilizar métodos diferentes. 

Esta lição tem como objetivo complementar as discussões das lições anteriores acerca das metodologias de desenvolvimento de software e prepará-lo para compreender os métodos de desenvolvimento prescritivos e, principalmente, os princípios dos métodos ágeis.

A principal crítica associada à metodologia clássica (prescritiva) é a “burocracia”, necessária para desenvolver o software, ou seja, na metodologia clássica, é necessário desenvolver uma extensa documentação, antes que, realmente, haja a programação do software. Essa característica gerou críticas por parte dos gerentes de projeto e stakeholders, porque não se observa software funcionando rapidamente, apenas uma documentação que não tem aplicabilidade prática.

Em contrapartida, o método prescritivo apresenta bons resultados para projetos grandes, que envolvam uma equipe de desenvolvimento numerosa, desde que não sofram alterações profundas em seus requisitos. O princípio dos métodos prescritivos é que as pessoas envolvidas em um projeto de software são substituíveis porque a documentação desenvolvida pode ser utilizada por um novo componente da equipe.

O ponto positivo das metodologias clássicas (prescritivas) é que elas podem oferecer vantagem em novos projetos, com características similares (PFLEEGER, 2004). A documentação produzida em um projeto pode ser reaproveitada em um outro projeto, e isso pode minimizar problemas já ocorridos anteriormente, pois a equipe de desenvolvimento já possui algum conhecimento sobre o projeto. Os métodos prescritivos tendem a resistir a mudanças mais profundas devido à extensa documentação que é desenvolvida e o projeto consistente do software (PRESSMAN; MAXIM, 2016).

De forma contrária aos modelos prescritivos, os métodos ágeis se adaptam às alterações no planejamento (mudança de requisitos). O modelo tem sua base fortemente baseada em pessoas ao invés de processos, como ocorre nos métodos prescritivos. Os métodos ágeis defendem a ideia de que: uma equipe coesa e integrada tem mais valor do que um conjunto de processos.

As metodologias ágeis são mais adequadas para projetos em que há baixa previsibilidade, ou seja, não se conhece muito bem os requisitos do software ou eles podem mudar com muita frequência. Os métodos ágeis são utilizados, muitas vezes, em projetos associados à criatividade. Empresas que adotam a abordagem ágil podem apresentar uma maior produtividade, de acordo com o tipo de software a ser desenvolvido (PRESSMAN, 2011).

A metodologia ágil NÃO tem como objetivo principal alocar grande quantidade de tempo em um planejamento inicial (levantamento de requisitos e projeto de software). Nessa metodologia, mudanças nos requisitos do software são consideradas normais. O principal objetivo nos métodos ágeis é definir planos que estabeleçam marcos (conquista de pequenos objetivos) e sempre manter as estimativas de tempo e recursos financeiros globais do projeto.

A empresa João das Couves Alimentos Ltda. tem direcionado grandes esforços para se manter no mercado e competitiva diante dos seus concorrentes. Para isso, a empresa tem investido em Tecnologias da Informação e na equipe de analistas e desenvolvedores de software. Assim, a empresa João das Couves Alimentos Ltda. decidiu desenvolver um robusto sistema de Análise de Dados que tem como objetivo integrar os dados das suas 150 filiais distribuídas em todo o Brasil. Nesse momento, você, como responsável pela gerência desse projeto e bom conhecedor dos métodos de desenvolvimento de software, decidiria por qual método? Prescritivo ou ágil?

A sua decisão deve ser baseada nas características do projeto e da equipe, atualmente, disponível na organização. Trata-se de um projeto de grande porte e que pode durar muitos meses. Nesse caso, talvez, métodos ágeis podem não ser adequados porque projetos grandes tendem a exigir uma documentação mais robusta de forma que riscos sejam minimizados durante o projeto. Além disso, é importante observar a característica da equipe de desenvolvimento (analistas, engenheiros e programadores). Essas pessoas possuem conhecimento suficiente para desenvolver um software dessa natureza? Caso seja necessário um treinamento, o tempo já foi previsto no projeto? O envolvimento desses funcionários no projeto não vai comprometer a funcionalidade de softwares que já estão “rodando” na empresa? Considero que esses são questionamentos básicos ao se analisar uma situação como a apresentada. É muito comum a área de Tecnologia da Informação se envolver em novos projetos e se esquecer que já existem softwares implantados que necessitarão, ao longo de toda a sua vida, de manutenções adaptativas, corretivas ou evolutivas.

Lembre-se, sempre: desenvolver e implantar um software é como um filho que você tem; após o seu nascimento, ele precisará de cuidados até que você ou ele faleça.

Se você optar pela utilização de um método ágil no projeto proposto, você deve ter em mente que é fundamental a coesão da equipe. Nos métodos ágeis, é necessário que a equipe trabalhe de forma conjunta e harmônica, além de trabalhar em um mesmo local fisicamente (na mesma sala ou próximos). Nos métodos ágeis, o foco está nas pessoas e a demissão ou a saída de um membro da equipe pode ter sérias consequências porque a documentação é menor e o conhecimento do projeto está nas pessoas (equipe do projeto).

Os modelos prescritivos, como o próprio nome sugere, prescrevem um conjunto de elementos de processo, as tarefas irão ocorrer de forma sequencial, assim como apresentado no modelo clássico. Temos, porém, modelos prescritivos mais adaptados à realidade de determinados tipos de softwares.

O modelo cascata é uma abordagem sistemática e sequencial de desenvolvimento. Você, futuro técnico em Análise e Projeto de Sistemas, pode considerar o uso do modelo em cascata quando há uma facilidade na identificação e compreensão dos requisitos. Quando se percebe a possibilidade de um desenvolvimento linear do sistema, o modelo cascata pode ser uma opção — requisitos bem definidos e prazos mais longos podem viabilizar o uso desse método (SOMMERVILLE, 2011). 

Uma variação do modelo em cascata é o modelo V (ver Figura 1), já apresentado em lições anteriores. O modelo V sugere ações de garantia da qualidade, comunicação, modelagem e construções iniciais do sistema. A ideia central do modelo em V é que, à medida que a equipe de software “desce” pelo lado esquerdo do V, os requisitos básicos do problema são refinados em representações cada vez mais detalhadas do problema e sua respectiva solução (PRESSMAN; MAXIM, 2016). Assim que o código executável é gerado, passa-se a uma série de atividades de testes a fim de garantir a qualidade.

O modelo em cascata e o modelo em V são bastante parecidos e com abordagens praticamente idênticas, ou seja, necessita-se de uma definição dos requisitos no início do projeto e estes não podem ser voláteis. Diante da semelhança dos métodos prescritivos, é importante observarmos aqueles métodos que apresentam uma óptica oposta para o desenvolvimento de software, estes são os métodos ágeis.

Métodos Ágeis

Os princípios dos métodos ágeis são apresentados no ano de 2001, quando um grupo de pesquisadores e desenvolvedores de software do campo de Engenharia de Software assinaram o chamado “Manifesto para o Desenvolvimento Ágil de Software”.  A base do manifesto dizia o seguinte: “Estamos descobrindo maneiras melhores de desenvolver softwares, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo” (PRINCÍPIOS... [2022], on-line). O manifesto ágil define os seguintes valores (BECK et al., 2001):

Dessa forma, apesar de ser valorizado os itens à direita (processos e ferramentas, documentação abrangente, contratos e planos), valoriza-se os da esquerda mais ainda (indivíduos e interações, software em funcionamento, colaboração com o cliente e responder a mudanças).

A ideia do desenvolvimento ágil surgiu como oposição aos métodos de desenvolvimento de software que, até então, dominavam o mercado. No desenvolvimento ágil, vale mais a entrega de software funcionando do que análise e projeto. Também se prioriza a comunicação ativa e contínua entre desenvolvedores e clientes.

No manifesto ágil, são apresentados, ainda, os 12 princípios que regem o desenvolvimento de software por meio da filosofia ágil, a saber (BECK et al., 2001):

A utilização de métodos prescritivos, muitas vezes, não se adequa bem a softwares mais simples ou em equipes auto-organizadas. Os princípios ágeis buscam suprir essa necessidade, propiciando uma maior flexibilidade no processo de desenvolvimento de software, apesar de que fases, ainda, são seguidas. As fases de comunicação, planejamento, modelagem, construção e entrega, ainda, são realizadas, mas de uma forma diferente, orientadas por um processo ágil (discutiremos essas fases ou etapas em lições posteriores).

Muitos alunos confundem o desenvolvimento ágil com aquele desenvolvimento que não segue nenhum método, nem mesmo o tradicional. No desenvolvimento que não segue um processo (tradicional ou ágil), você cria um software sem realizar qualquer planejamento, apenas se senta à frente do computador e programa sem que houvesse o amanhã. No modelo ágil, por sua vez, são seguidos princípios, como os apresentados acima. Não se parte do nada para o desenvolvimento de software, segue-se uma filosofia de desenvolvimento de software.

Um ponto importante a destacar é o fato dos princípios ágeis defenderem a ideia de funcionamento do software acima da documentação, isso NÃO SIGNIFICA que nenhum documento é criado quando se aplica o método ágil. Os métodos ágeis reconhecem que as pessoas são os principais condutores responsáveis pelo sucesso do projeto. Enfatizam a comunicação, o comprometimento de seus integrantes e as habilidades individuais durante o desenvolvimento de software e minimizam os aspectos burocráticos (característica dos métodos prescritivos).

Assim, como já discutimos no Case estudado, a escolha por um outro método dependerá das características do projeto, características da organização com relação à área de Tecnologia da Informação e da própria equipe que estará envolvida no projeto. Considero que analisar esses fatores antes de decidir que método usar é um dos pontos centrais para o sucesso de um projeto de software.

Hoje em dia, eu vejo muita gente defender “cegamente” os métodos ágeis pelo fato de muitos defenderem as suas abordagens. Considero, contudo, que não é adequado para um profissional envolvido com projetos de software defender “cegamente” um outro método, porque a decisão não deve ser baseada no que o profissional acredita ou não no que é melhor, mas deve ser fundamentada pelos fatores que apontei acima. Por isso, nas nossas próximas lições, vamos aprender a projetar softwares seguindo métodos prescritivos que misturam princípios de métodos e vamos entender como, exatamente, você pode desenvolver um projeto, seguindo os valores e princípios ágeis que discutimos.

Ainda temos muito o que discutir, por isso, nas próximas lições, sairemos das discussões teóricas e conceituais e partiremos para algo mais prático/palpável. Continue, nesta jornada, que vai valer muito a pena.

Clique aqui, teste seus conhecimentos sobre esta lição e confirme sua participação nesta disciplina!