Cascade and Agile Methodology
REGISTRO DOI: 10.5281/zenodo.7390028
Lauany Cristina Santos Oliveira
Leonardo Hackenhaar
Letícia Rodrigues Simão
Natália Freitas de Carvalho
Wiliam Alves Pereira Gomes
Orientador: Prof.ª Dra. Claudia Lucia de Moura
Resumo: Em um mercado altamente competitivo as empresas de tecnologias buscam por se destacarem e evoluírem constantemente, evolução esta que vem sendo considerada também dentro das organizações, estimulando a produtividade e contentamento dos colaboradores. Com a eclosão da cultura ágil, houve a desburocratização dos processos, possibilitando maior gerenciamento e participação das equipes envolvidas, atualmente existem diversas ferramentas que simplificam a gestão de processos de desenvolvimento, em destaque tem-se a Scrum.
O presente artigo expõe um estudo bibliográfico relacionado as metodologias Cascata e Ágil de desenvolvimento de softwares. Ambas possuem o propósito de estabelecer organização, padronização de processos, diminuição de riscos e custos, além de contribuir para o êxito na gestão e desenvolvimento de projetos, no entanto, o desempenham de forma distintas. O foco principal é demonstrar os diferentes métodos utilizados nos ciclos de desenvolvimentos e analisar de forma comparativa a viabilidade de aplicação de cada um, observa-se que a metodologia a ser empregada está sujeita a dimensão e exigência do projeto
Palavras-chave: Ágil; Cascata; Metodologias; Software; Scrum.
Abstract: In a highly competitive market, technology companies seek to stand out and constantly evolve an evolution that has also been considered within organizations, stimulating productivity and employee satisfaction. With the emergence of the agile culture, there was a reduction in the bureaucracy of processes, enabling greater management and participation of the teams involved, currently there are several tools that simplify the management of development processes, in particular Scrum.
This article exposes a bibliographical study related to Waterfall and Agile software development methodologies. Both have the purpose of establishing organization, standardization of processes, reduction of risks and costs, in addition to contributing to successful management and development of projects, however, they perform in different ways. The main focus is to demonstrate the different methods used in the development cycles and to comparatively analyze the feasibility of applying each one, it is observed that the methodology to be used is subject to the size and requirement of the project.
Keywords: Agile; Waterfall; Methodologies; Software; Scrum.
1. Introdução
Constantemente empresas de avanços sistêmicos procuram inovações e melhorias, a fim de atender as incessantes transformações do mercado cada vez mais exigente. A vista disso, as companhias rastreiam os melhores recursos de trabalho para o desenvolvimento de produtos de excelência, destacando-se em relação as demais organizações.
No que tange à avanço de software a metodologia utilizada é responsável diretamente pelo seu êxito, atuando como um suporte através de um compilado de atividades já estabelecidas objetivando o aumento de produtividade, maior interatividade, além da diminuição de riscos e custos. Temos diversas metodologias de desenvolvimento acessíveis ao mercado, na presente pesquisa bibliográfica citaremos duas delas sendo: Modelo Cascata ou processo Waterfall e Metodologia Ágil, presume-se demonstrar as principais características de ambas através de uma comparação de suas etapas e analisando a viabilidade.
1.1 Justificativa
Em um Mundo tecnológico em constante desenvolvimento e inovações, a necessidade de seguir este cenário se torna algo de suma importância, e passa a ser visto de forma mais criteriosa e estimada pelas empresas que almejam acompanhar este crescimento. Levando em consideração este contexto, a presente pesquisa tem o propósito de auxiliar no conhecimento dos métodos de desenvolvimento de processos mais utilizados, a fim de provocar inquietações propositivas e auxiliar na análise do método que mais se adapta a necessidade do projeto.
Empregamos como base de pesquisa a análise de uma implantação da metodologia ágil Scrum em uma determinada empresa de pequeno porte, detalhando o processo adotado, bem como os principais pontos abordados, demonstrando as etapas realizadas para êxito na implantação. Utilizamos como apoio pesquisas bibliográficas que fundamentam a estruturação do estudo.
Ao especificar as metodologias ágeis e cascata, possibilitamos uma análise comparativa concisa e direcionada, que facilita a escolha assertiva pelas empresas, do método que melhor se adapta a sua realidade de gestão, e seus objetivos de crescimento junto ao mercado.
1.2 Objetivos
Objetivo geral
Apresentar o estudo pontuando as vantagens de utilização das metodologias ágeis nas empresas de desenvolvimento de softwares, o processo de substituição e adaptação em cada uma delas, além da apresentação das metodologias, seus mecanismos e tipos de aplicações.
Objetivos específicos
1. Abordar a implementação da metodologia Scrum em empresas de software que atualmente utilizam o método em cascata;
2. Analisar graficamente as desvantagens da metodologia em cascata;
3. Analisar graficamente as vantagens da utilização do Scrum, seja em redução de custos, prazos de entrega utilização de recursos e entrega de valor ao cliente;
4. Analisar os resultados de comparação entre os métodos Scrum x Cascata, e apresentar as considerações finais do porquê o Scrum é o método mais eficiente para empresas de desenvolvimento de software.
1.3 Metodologias Tradicionais x Ágeis
Para SBROCC e MACEDO (2012) podemos identificar a desigualdade entre as metodologias tradicionais e as ágeis através de suas características, as ágeis são adeptas a modificações no decorrer do processo de desenvolvimento do software, se fundamentam através de bases estatísticas obtidas através de análises históricas, enquanto as tradicionais são resistentes as variações durante o processo, e seguem rigorosamente normas estipuladas que indicam padrões a serem adotados. O método a ser seguidos nos processos ágeis é determinado pela equipe responsável pelo desenvolvimento, e não demanda de um controle moroso dos processos, o contrário podemos notar nas tradicionais, uma vez que existem diversas normas e políticas a serem seguidas, bem como, rigorosos contratos e a não abertura ao cliente de decisão ao desenvolvimento do projeto, pode-se citar ainda o alto número de envolvidos, por não estarem adeptas a possíveis mudanças, caso haja a real necessidade de ocorrerem, está sujeito ao aumento do custo previsto de forma exponencial.
As metodologias ágeis possuem equipe reduzida, que atuam de forma integrada geralmente em um único ambiente, por estar aberta a alterações estando direcionada nas pessoas em não em processos, possuem custos já definidos e que dificilmente sofrem grandes alterações, o sistema pode ser desenvolvido de forma incremental. Porém, é válido salientar que independentemente das inúmeras vantagens do método ágil, é necessário que ao implantar o método, seja observado o contexto de desenvolvimento do software, tendo em vista que em casos de extrema confiabilidade a metodologia tradicional é a mais utilizada.
1.3.1 Metodologia Cascata
A Metodologia em cascata, ou modelo sequencial linear, originou-se por volta de 1970, o primeiro a utilizar o método foi Winston Walker Royce e surgiu como uma forma de otimizar a gestão de projetos, é considerado o mais antigo de todos os processos e é nomeado por sua forma de cascata sequencial, que pode ser simplesmente pensada como fluindo em uma direção constante para frente, ou seja, uma queda d’água de um rio.
Segundo Royce, inicialmente é apontado que para projetos existem duas etapas essenciais para o desenvolvimento de qualquer programa de computador, independentemente do tamanho ou complexidade: análise e a codificação (Figura 1). Contudo, esse conceito de desenvolvimento, como explica o mesmo autor, é o suficiente apenas para um produto simples. Para projetos de sistemas de software grandes, um esforço como esse, os condenará ao fracasso.
Figura 1 – Análise e Codificação
Fonte: Royce, 1970
Royce (1970) relata que quando se trata de um sistema de desenvolvimento de software grandes, as etapas de análise e codificação estão presentes, mas são precedidas por dois níveis de análise de requisitos, de sistema e do software, sendo separadas por etapa de design do programa e seguidas de uma etapa de teste. Portanto, todo o processo se constitui por sete etapas que devem ser trabalhadas na ordem predefinida para que se tenha sucesso no processo de desenvolvimento do software (Figura 2).
Figura 2 – Sete etapas do cascata
Fonte: Royce, 1970
Apesar do autor afirmar que a implementação “é arriscada e convida ao fracasso”. Royce (1970) diz acreditar nesse conceito de desenvolvimento. Seu Ceticismo, porém, está ligado em suas experiências, pois na prática que na fase de testes ocorreram eventos relativos com o tempo, ligadas aos fenômenos não precisamente analisáveis. Caso esses fenômenos não satisfizerem as muitas restrições externas, fatalmente o processo deverá ser redesenhado. Segundo o autor, essas alterações no processo são “passíveis de serem disruptivas que os requisitos de software sobre os quais o projeto se baseia e que fornece a racionalidade de tudo que serão violados. Os requisitos devem ser modificados, ou uma mudança substancial no design é necessária” (Royce, 1970, p. 329).
Trazendo como consequência desse redesenho no processo, seu retorno para fase inicial a cada modificação acaba sobrecarregando nos cronogramas e custos para o seu processo de desenvolvimento. Royce (1970) não nomeia esse modelo e considera-o arriscado e indutor ao fracasso em grandes processos. Contudo, a despeito das cautelas do próprio autor, os desenvolvedores adotaram o modelo de maneira acentuada e nomearam de Modelo Cascata (Waterfall Model).
Portanto, o modelo cascata apresenta diversas vantagens quando o escopo de trabalho é bem definido ou pouco personalizável, como licitações e serviços específicos para órgãos públicos. Outro uso muito eficaz são os aplicativos em cascata para atualizar um sistema já existente ou fazer alterações específicas em um aplicativo construído. Assim, em projetos menores, você tem um controle mais rígido. Nesse caso, os requisitos são conhecidos e fáceis de gerenciar. Além disso, o produto em si está pronto, então não haverá um longo período de espera. No entanto, como os modelos têm pouca ou nenhuma flexibilidade, os modelos passam a ser considerados frágeis, surgindo então modelos lineares e interativos.
Segundo Pressman (2006) e Paula Filho (2003) o modelo em cascata caracteriza-se pelo seu carácter preditivo, prescritivo, sequencial, burocrático, rigoroso, orientado a processos, dados formais e controlado, que tem, tem o sucesso atingido desde que esteja em conformidade com tudo que foi planejado.
Para que isso ocorra será esclarecido em cinco fases da metodologia, sendo o método cascata um mais conceito simples e fácil de implementar do que o método ágil. A abordagem se assemelha a um fluxo que flui através de uma série de cascatas. Essa abordagem de desenvolvimento significa que uma nova fase não começa até que a fase anterior seja concluída. Desenvolvendo-se nas etapas seguintes.
1 – Análise e Definição dos Requisitos
Nessa fase, acaba sendo estabelecido todos os requisitos do produto que o idealizador deseja desenvolver, que normalmente se baseia nos serviços que precisam ser fornecidos, seguindo as limitações aceitáveis e os objetivos do software. Os pontos principais são transformados em funcionalidades a serem implantadas e a definição das expectativas do idealizador em relação ao produto. Após determinado os requisitos precisam ser estabelecidos de uma forma que também sejam úteis para a próxima etapa. Esta fase compreende a documentação e a viabilidade do projeto com a finalidade de estimular o processo de início de desenvolvimento do projeto no sistema.
2 – Projeto do Sistema
Nessa fase, o projeto de elaboração de sistema consiste em vários processos que focam em quatro atributos distintos do sistema, a saber: estruturas de dados, arquitetura de software, características da interface e detalhes do processo. O processo de design apresenta os requisitos de forma a suportar a codificação do produto (como uma fase de codificação anterior). Assim como a análise de requisitos, os projetos são documentados e se tornam parte do software.
3 – Implementação
A fase de implementação é a fase em que o programa é criado. Se o projeto tiver um nível de detalhamento maior, as etapas de codificação podem ser automatizadas. Em princípio, recomenda-se adicionar testes de unidade a cada módulo desenvolvido nesta etapa. Nesse caso, as unidades de código criadas são submetidas a testes individuais antes de entrar nas etapas globais de integração e teste.
4 – Teste do Sistema
Depois que a fase de codificação termina, a fase de teste do sistema começa. Este processo de teste concentra-se principalmente em dois pontos principais, ou seja, a lógica interna e as funções externas do software. Esta etapa é importante porque demonstra se os erros de comportamento do software foram resolvidos e garante que as entradas definidas produzam resultados válidos e que atendam aos requisitos previamente determinados.
5- Manutenção
A fase de manutenção baseia-se na correção de bugs não detectados durante os testes, melhorias funcionais e preferencialmente outros tipos de suporte. Esta etapa faz parte do ciclo de vida do produto de software, não apenas seu desenvolvimento. Melhorias e alterações em correções de software podem ser classificadas como parte do processo de desenvolvimento.
1.3.2 Metodologia Scrum
O scrum foi criado por Jeff Stherland que como piloto da aeronáutica acreditava ser possível comparar o processo de gestão e finalização de um projeto como a delicada missão de pousar um avião. De acordo com o seu pensamento e sua experiência, o maior desafio de pousar um avião consistia no fato de que não existe uma fórmula fixa para fazer isso. Sendo assim, a todo momento o piloto precisa fazer ajustes para adequar a aeronave à rota de pouso. O mesmo vale para um grande projeto que envolve diversas pessoas e um nível de complexidade muito alto de atividades.
A metodologia Scrum Agile propõe que um projeto seja dividido em pequenos ciclos de atividade, com reuniões frequentes para que a equipe possa alinhar o que vem fazendo e pensar formas de melhorar o processo com agilidade. Essa metodologia propõe que seja acompanhado sempre bem de perto e passe por mudanças de planejamento o tempo todo, de forma livre e pouco engessada. A figura 1 apresenta uma ilustração do ciclo do Scrum.
Figura 3 – Ciclo Scrum
Fonte: Adaptado de (SCRUM, 2014).
Termos técnicos utilizados no Scrum:
•Sprints: é o nome utilizado para os ciclos de cada projeto.
•Product Backlog: é o nome utilizado para o conjunto de objetivos de um projeto.
•Sprint Planning Meeting: são reuniões periódicas que acontecem no início de cada sprint, ou ciclo, para planejar e priorizar os itens do Product Backlog que serão desenvolvidos naquele período;
•Sprint Backlog: é o nome dado as tarefas específicas que serão realizadas e desenvolvidas em cada ciclo ou sprint;
•Daily Scrum: é uma reunião diária que ajuda a acompanhar o projeto.
•Sprint Review Meeting: é uma reunião que acontece ao final de cada sprint para que a equipe possa apresentar o que foi realizado e os resultados do trabalho daqui ciclo.
O foco principal do Scrum é a transparência na gestão dos projetos. Uma das principais regras da metodologia é que todos no projeto saibam o que está sendo feito e que as atividades de cada ciclo sejam mostradas para todos da equipe.
Principais papéis no gerenciamento de projetos com Scrum
Basicamente as equipes de projetos da metodologia Scrum são compostas por três papéis o Product Owner, Scrum Master e Time Scrum.
Product Owner
É o ponto central com poderes de liderança sobre o produto. Ele é o único responsável por decidir o que será feito e qual será a ordem de prioridade.
É de responsabilidade do PO comunicar a todos os participantes, uma visão clara do que a equipe Scrum está buscando alcançar no projeto. Também é responsável pelo sucesso global do projeto.
Scrum Master
É responsável por ajudar todos os envolvidos a entender os valores, princípios e práticas do Scrum.
O Scrum master age como uma espécie de coach, executando a liderança do processo e ajudando a equipe Scrum a desenvolver sua própria abordagem, que tenha o melhor desempenho, respeitando as particularidades da organização.
Também tem um importante papel de facilitador no desenvolvimento de projetos com Scrum. Ele deve ajudar a equipe a resolver problemas e realizar melhorias no uso do Scrum, sendo responsável por proteger a equipe contra interferências externas e assumindo um papel de liderança na remoção de impedimentos que possam atrapalhar a produtividade.
A principal diferença entre papel tradicional dos gerentes de projetos e o Scrum Master, é que o Scrum master age como um líder e não como um gerente.
Time Scrum
Dentro do projeto tradicional são criadas diversas “cascatas” com cargos e funções bem delineados. Na metodologia Scrum é definido o papel do Time de Scrum, que é a simples junção de todas essas pessoas em uma equipe multidisciplinar e são responsáveis pela concepção, construção e testes dos produtos do projeto. A principal ideia é que a equipe se autogerencie para determinar a melhor maneira de realizar o trabalho para atingir a meta estabelecida pelo Product Owner.
Geralmente o time Scrum são pequenos. Mesmo tendo foco em grupos pequenos, o Scrum também pode ser usado em projetos que exijam equipes muito maiores.
Artefatos
Os artefatos do Agile Scrum são informações usadas pelas equipes e partes interessadas do Scrum para detalhar o produto que está sendo desenvolvido, as ações para produzir o produto e as ações realizadas durante o projeto.
Artefatos são criados durante as principais atividades de um sprint Scrum:
•Planejando o trabalho e os objetivos futuros
•Crie tarefas para atingir esses objetivos
•Organize tarefas em sprints com base em dependências e prioridades executar tarefa
•Revise e analise os resultados para comparar com as metas
Backlog
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. Este artefato é a principal fonte de informação para o planejamento de sprint (Sprint Planning). No decorrer da sprint o Product Owner, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar. O Product Owner mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento da sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog da sprint.
Product Backlog
O Product Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão do mesmo.
Sprint Backlog
O Sprint Backlog é uma lista de itens selecionados do Product backlog e contém tarefas concretas que serão realizadas durante a próxima sprint para implementar tais itens selecionados.
O Sprint Backlog é uma representação em tempo real do trabalho que o Development Team planeja concluir no sprint corrente, e ele pertence unicamente ao Development Team.Lean
Lean é uma gestão introduzida no mercado pela indústria automotiva para alcançar um desenvolvimento enxuto e eficiente. A aplicação de recursos e tempo é mínima, reduzindo custos para a empresa. O objetivo é combater a superprodução e reduzir a complexidade para otimizar os resultados.
Em uma abordagem enxuta, as equipes têm fluxos de trabalho mais claros e compreensíveis, entrega rápida e identificação de problemas ou gargalos no processo. Isso economiza custos, torna a empresa mais competitiva e permite uma gestão financeira inteligente.
Os princípios desta abordagem são:
- Eliminar desperdício;
- Ampliar o aprendizado;
- Decidir o mais tarde possível;
- Entregar o mais rápido possível;
- Empoderar o time;
- Construir qualidade;
- Otimizar o todo.
1.4 Implantação metodologia ágil Scrum
Neste parágrafo será apresentado o cenário de uma empresa onde o scrum foi implantado, demonstraremos o desenvolvimento da ferramenta, e o antes e depois do processo.
Por parte do processo foi adequado um questionário de nível de satisfação da equipe com o objetivo de avaliar a mudança da cultura organizacional.
Com a intenção de preservar o nome da empresa e seus objetivos não será divulgado o seu nome, será tratado com o nome fictício “empresa”.
A empresa é de pequeno porte, com a estrutura pequena e o quadro de funcionários reduzido.
Atualmente atende cerca de quinze clientes no desenvolvimento de um sistema específico que é utilizado por mais de sete mil usuários, sendo que cerca de duzentos desses usuários fazem solicitações, onde demanda uma organização pontuada quando se trata de novas interações com o produto, esse produto é separado em cinco módulos independentes.
A empresa adequa um papel bem definido para os colaboradores, sendo eles: um analista de sistema, um programador, um gerente de projetos e testes, e um profissional de testes.
A empresa preza pela qualidade do software e para eles é de extrema importância os testes para que haja menor transtorno possível para os clientes, nas implantações e na entrega final do produto.
É necessário o conhecimento de todos os participantes do grupo com relação ao segmento em que o produto se encaixa, devem atender às solicitações propostas e entregue com qualidade.
1.4.1 Etapa de desenvolvimento antes do Scrum
O problema que resulta no interesse das empresas na metodologia é o fato de não utilizarem nenhum processo específico de desenvolvimento de software. O processo de desenvolvimento pode ser descrito em sete etapas, sendo elas:
1. Solicitação de cliente ou interna
2. Identificação de prioridade
3. Solicitação vai para fila de espera, sendo avaliada como “urgente” ou “normal”
4. Analista ou programador realiza a alteração
5. Etapa de teste
6. Caso esteja “ok” vai para a etapa de atualização do sistema no cliente, caso contrário retorna para etapa “4” para realizar os ajustes.
7.Atualização validade pelo cliente.
Existem alguns problemas nesse processo e o maior deles é a ausência de controle das solicitações, onde acaba gerando falha de comunicação entre os envolvidos no processo. Quando ocorre uma solicitação “urgente” acaba gerando muitas horas extras, onde é entendido por parte da equipe que o tempo está mal-empregado, interferindo diretamente na qualidade em que a Empresa busca tanto no processo quanto no produto.
O controle das atividades e solicitações eram feitas por meio de tabelas e ferramentas desenvolvidas pela própria equipe.
A divisão das solicitações era feita em seções, nomeada por cliente ou módulo do produto, sem detalhamento adequado e acompanhado por um responsável pela atividade.
Dois problemas que ocorriam com frequência era encontrar solicitações iguais em mais de uma seção, o segundo era o nível baixo de detalhamento das solicitações, tendo a ausência de dados necessários para realizar o incremento, causando transtorno entre a equipe e solicitante.
A tabela 1 mostra os dados referentes a solicitações disponíveis no sistema utilizado na empresa, com dados de até 8 meses anteriores a adoção do Scrum.
Tabela 1 – Solicitações antes da implantação do Scrum.
| Mês/Ano | Solicitações cadastradas | Solicitações concluídas | Período médio para conclusão |
| Dez/2021 | 7 | 0 | – |
| Jan/2022 | 30 | 8 | 34 dias |
| Fez/2022 | 9 | 1 | – |
| Mar/2022 | 6 | 5 | 127 dias |
| Abr/2022 | 19 | 0 | – |
| Mai/2022 | 21 | 2 | 48 dias |
| Jun/2022 | 16 | 12 | 130 dias |
| Jul/2022 | 46 | 38 | 37 dias |
| Totais | 154 | 68 | 70 dias |
| Média mensal | 19 | 7 | – |
1.4.3. Desenvolvimento da implantação
Utilizando como base características principais apontadas pela equipe, foi realizado um estudo com algumas metodologias ágeis e, posteriormente foi identificado que o Scrum seria a melhor opção para ser implementado na empresa, pois segundo Cohn (2011), é de suma importância que seja identificado que o processo atual não esteja dando o resultado esperado, como também, o desejo da adoção do Scrum como ferramenta de solução. Identificado isso, foi realizada uma apresentação para toda a equipe com o objetivo principal de mostrar as características e o funcionamento do Scrum.
As etapas a seguir representam o planejamento para a implantação do Scrum:
- Organizar as solicitações por níveis de prioridade, que seja mais prático e de fácil acesso, realizando o backlog do produto. Alterando também o detalhamento das descrições, adicionando dados mais consistentes.
- Realizar uma reunião para definir o prazo e o backlog para o primeiro sprint a ser realizado
- Realizar a primeira reunião de encerramento da sprint
- Definir a primeira entrega feita aos clientes após a doação do Scrum.
Para garantir o controle do backlog do produto, foi utilizado um software chamado Jira, utilizando o plugin bigpicture.
A ferramenta é de suma importância para a organização no processo de implantação do Scrum em relação as Sprints e ao backlog do produto, permitindo à equipe de desenvolvimento uma visão macro sobre as atividades já realizadas, como também o acompanhamento das atividades que estão em andamento, bem como as futuras. Existe também a opção de adicionar comentários específicos para cada solicitação, possibilitando a comunicação entre a programação e os testes mais simples e eficientes.
As requisições são divididas em seções para melhor organização, sendo que as que envolvem módulos do sistema e clientes fazem parte do Product Backlog. Outros referem-se ao Sprint backlog em desenvolvimento e consistem em três partes: o conteúdo da parte de desenvolvimento, o conteúdo da parte de teste e o conteúdo que foi concluído no final, bem como sprints anteriores e atualizações antigas.
1.4.4 Mudança de Papéis
Mudar os papéis em uma equipe pode tornar a adoção do Scrum dolorosa. Seja com o surgimento de novos personagens, seja com a retirada dos utilizados anteriormente (COHN, 2011). A implementação do Scrum trouxe duas novas funções para a equipe: Scrum Master e Product Owner. Os analistas de sistema são definidos como proprietários do produto, obtendo mais conhecimento sobre o produto e seus recursos. Por outro lado, o papel do Scrum Master, responsável pelo projeto e gerente de testes, muda um pouco sua forma de trabalhar para se tornar mais flexível e confiante com a equipe.
Não há muito trabalho para um analista de sistemas se ajustar à sua nova função de product owner, e como a empresa tem uma equipe pequena, ele já está assumindo uma função mais próxima dessa função. Numa equipa Scrum, o programador não só recebe o que tem para programar, como se envolve mais na compreensão dos requisitos do produto. Quando o objetivo é concluir o Sprint, ele também deve aceitar tarefas fora de seu domínio específico (COHN, 2011). A empresa já está trabalhando dessa forma, mas não tão explicitamente quanto no Scrum. Já é função do programador realizar testes básicos durante a escrita do código e, muitas vezes, ele se aproxima do cliente em busca de um melhor entendimento dos requisitos.
Os testadores também têm um papel diferente no Scrum porque, assim como os programadores não recebem mais especificações perfeitas, os testadores não recebem mais requisitos perfeitos para garantir a funcionalidade do sistema (COHN, 2011). Certifique-se de que o que está sendo desenvolvido é realmente uma sugestão do cliente. Ele é o líder servidor da equipe, ajudando-os a maximizar seu desempenho e a adotar o Scrum. Mesmo antes de adotar o Scrum, a equipe já tinha uma boa comunicação entre todos os membros do processo, e após a adoção do Scrum essa comunicação ficou muito mais fácil. As conversas sobre como os recursos devem produzir produtos de alta qualidade são frequentes. Ao final de cada Sprint, preferencialmente, é entregue um software funcionando com novos incrementos ou correções. Aprender como entregar esse software funcional é um dos maiores desafios da adoção do Scrum (COHN, 2011).
Para ter sucesso nisso, a empresa busca controlar as versões Sprint a Sprint, com pequenas mudanças feitas na primeira Sprint, formando uma Sprint de duas semanas que produz um novo Incremento de Produto. A coleta de dados é uma tarefa difícil, mas traz grandes benefícios. Dados positivos podem encorajar as equipes e superar contratempos, além de quantificar melhor os progressos e problemas, indicando para onde direcionar as ações de melhoria de processos. Também é importante considerar a avaliação de todos os membros da equipe (COHN, 2011)
2. Revisão Bibliográfica
Esse artigo teve como objetivo principal apresentar um estudo pontuando as vantagens da utilização das Metodologias ágeis nas grandes empresas de desenvolvimento de softwares, buscando o aprofundamento no tema, foram traçados alguns objetivos específicos: Abordar a implementação da metodologia Scrum em empresas de software que atualmente utilizam o método em cascata; Analisar graficamente as desvantagens da metodologia em cascata; Analisar graficamente as vantagens da utilização do Scrum, seja em redução de custos, prazos de entrega utilização de recursos e entrega de valor ao cliente; Analisar os resultados de comparação entre os métodos Scrum x Cascata, e apresentar as considerações finais do porquê o Scrum é o método mais eficiente para empresas de desenvolvimento de software. Diante das necessidades de um mercado cada vez mais versátil e buscando sempre trazer um resultado satisfatório para o cliente final, este trabalho buscará esclarecer as principais diferenças entre a metodologia em cascata para as metodologias ágeis.
A. Google Acadêmico;
B. SciELO;
C. Biblioteca Virtual São Judas.
2.1. Metodologia Cascata
A metodologia em cascata baseia-se na execução sequencial de tarefas, em um artigo publicado por Winston Walker Royce em 1970, o modelo cascata ou ciclo de vida do software foi a primeira metodologia de desenvolvimento de software a ser publicada. Segundo Pressman (2006) e Paula Filho (2003) Como um modelo linear em que cada etapa deve ser completada antes que as próximas tarefas sejam iniciadas, pode ter seu sucesso atingido desde que tudo seja cumprido conforme planejado.
2.2. Metodologias ágeis
De forma geral, nos estudos e literaturas acadêmicas, é notável que as metodologias ágeis são definidas por possuírem em sua maioria, equipes auto-organizadas, adaptáveis e multidisciplinares, eficientes em busca por melhoria contínua no desenvolvimento dos seus processos (SUTHERLAND, 2014)
A adaptação no planejamento é baseada em ciclos colaborativos que agrega flexibilidade e maior taxa de adaptabilidade nos processos, essas interações têm como foco buscar a melhoria contínua e agregar valor ao cliente.
Autonomia para os indivíduos é o ponto chave. Com o apoio de ferramentas ágeis, são definidas individualmente as tarefas a serem realizadas, a priorização e urgência de cada uma delas, definição de prioridades a serem realizadas, esse acompanhamento é feito de forma “full time”. O foco total é na entrega do produto ou serviço, a documentação que é exigida fica para um segundo momento, é mais importante a entrega do produto final com total funcionalidade, agregando valor e satisfação ao cliente, do que uma documentação que deveria explicar como o produto deveria funcionar, mas não funciona exatamente daquela forma.
O cliente faz parte do processo de execução, a comunicação e feedback do mesmo durante o desenvolvimento é de extrema importância, dessa forma é possível realizar mudanças e ajustes necessários antes da entrega do produto final, agregando maior valor na relação com o cliente.
A adaptação as mudanças ao invés de seguir com o plano inicial torna o processo mais objetivo, caso surjam problemas, mudanças, antecipações ou postergações, é de maior interesse o ajuste de cronograma conforme o cenário atual para os ajustes necessários.
3. Materiais e Métodos
Para atingir os objetivos propostos, foram percorridos os seguintes passos:
1) A Fase 1 inclui uma revisão bibliográfica de práticas, metodologias e frameworks ágeis, com foco em Scrum, para identificar quais conceitos e práticas podem ser aplicados;
2) A segunda etapa visa investigar com a equipe de desenvolvimento da empresa, levantar problemas existentes e propor possíveis soluções utilizando Scrum;
3) Na terceira fase, ocorreu o planejamento e implementação da metodologia;
4) E, na quarta e última etapa, avaliar o impacto das mudanças realizadas.
4.Resultados e Discussão
Após a apresentação dos métodos ágeis, neste tópico iremos apresentar os benefícios e resultados que os métodos podem trazer para as companhias, otimizando seus processos internos e trazendo resultados positivos, sejam em aumento da produtividade, organização da equipe, lucros e satisfação aos clientes.
O relatório “State of Agile” realizado pela Digital.ai, atualmente na sua 15° edição, realizada em 2021, fornece informações das técnicas e utilizações ágeis. É a maior e mais longa pesquisa sobre os métodos ágeis atualmente, são mais de 1.380 entrevistadas ao redor do mundo. Atualmente o estudo traz dados de empresas de desenvolvimento de softwares, até empresas que utilizam dos métodos em demais áreas.
Segundo o relatório, a adoção de métodos ágeis obteve grande aumento, e é previsto aumentos significativos em demais áreas, conforme o gráfico abaixo:
Figura 4 – Quais áreas da sua organização adotaram
Fonte: Report state of Agile
Comparado com o Report de 2020, houve aumento significativo na adoção das metodologias ágeis nos setores de desenvolvimento de softwares, de 37% em 2020 para 86% em 2021. Podemos considerar o aumento da utilização das metodologias ao fato de as empresas terem adotado o home office no período de quarentena da Covid 19. Segundo o Report apenas 3% dos entrevistados desejam voltar ao trabalho presencial após o Covid, 16% sempre trabalhou remotamente e deseja permanecer remoto, 25% adotaram o home office durante a pandemia e esperam continuar remotamente, enquanto 56% irão voltar ao escritório de forma híbrida, conforme o gráfico abaixo:
Figura 5 – Distribuição time Agile em equipe pós-COVID-19
Fonte: Report state of Agile
Segundo os estudos realizados por André Miceli (2021), coordenador de MBA em Marketing e inteligência de negócios digitais na FGV (Fundação Getúlio Vargas), o home office continuará crescendo mesmo após a pandemia, cerca de 30%. Se fazendo necessário assim, cada vez mais presente a utilização de métodos ágeis entre as empresas.
Metodologias mais abordadas
Assim como nas últimas edições, a metodologia mais abordada pelas organizações foi o Scrum, com 66%, e as demais foram junções de mais de um método, conforme gráfico:
Figura 6 – Metodologias mais abordadas
Fonte: Report state of Agile
Razões para a adoção de métodos ágeis
Segundo o Report, o que as organizações buscam ao adotar os métodos ágeis em seus processos, variam entre diversos motivos, iremos analisar os mais citados, que são:
A habilidade de gerenciar as prioridades;
Acelerar a entrega de softwares;
Aumento da produtividade da equipe.
Fazendo uma breve análise sobre os temas acima, conseguimos fazer a ligação entre essa busca das empresas com a maior utilização do Scrum, conforme tópico acima. Os desejos citados pelas empresas coincidem com os princípios da Scrum, desta forma fica clara a vantagem do Scrum em relação as outras metodologias. Abaixo o gráfico com a relação mais detalhada da busca das empresas:
Figura 7 – Desafios ágeis
Fonte: Report state of Agile
Métricas para definir o sucesso da implementação dos métodos ágeis
As métricas utilizadas pelas companhias para definir se a implementação dos métodos é positiva pode ser analisada de diversas formas, sendo o “ponto fraco” da empresa que após a introdução das metodologias foi otimizado, pela satisfação de seus clientes, ou pelo valor agregado que a organização alavancou, seja pela melhora em seus processos, entre outros. Cabe a cada setor ou gestor analisar os possíveis pontos de otimização e compará-los em termos quantitativos, após as aplicações e melhorias.
No documento, podemos avaliar as principais métricas que as empresas utilizam e, com elas, enxergar que a adoção dos métodos ágeis se faz possível em diversas áreas e setores, podendo ser empregado e trazendo resultados positivos. Abaixo o gráfico:
Figura 8 – Adoção ágil
Fonte: Report state of Agile
Principais Técnicas dos métodos ágeis
As técnicas dos métodos ágeis por mais diferentes que sejam, muitas vezes são parecidas ou até iguais, dessa forma podemos “combinar” métodos, por exemplo o ScrumBan, que é a junção dos métodos Scrum e Kanban, que por mais que possuam princípios diferentes, possuem técnicas semelhantes. Isso acontece com demais metodologias, e dessa forma, com a necessidade da equipe, podendo haver o acréscimo de uma técnica de qualquer metodologia na qual está sendo utilizada como principal, desde que os princípios não sejam afetados. Conforme o relatório demonstra abaixo, a principais técnicas são:
Figura 9 – Técnicas Ágeis e Maturidade
Fonte: Report state of Agile
Com o auxílio de softwares algumas ferramentas ágeis estão disponíveis no mercado, ferramentas que podem auxiliar as equipes em suas tarefas, progressos, prioridades, necessidades de reposição, entre outras. O Report trouxe quais são as principais ferramentas que as equipes que adotaram as metodologias ágeis utilizam e recomendam atualmente, são grandes aliadas pelas suas funcionalidades.
Figura 10 – Ferramentas ágeis
Fonte: Report state of Agile
Temos como destaque o JIRA, com 81% de recomendação, seguido pelo Digital.ai com 70% e o Azure DevOps, com 66%.
Para quantificar os resultados obtidos após a adoção do Scrum, foram utilizados dois métodos. Inicialmente, comparando os dados da Tabela 1 obtidos antes da empresa implementar o Scrum com os dados da Tabela 2 após a implementação do Scrum. O número de solicitações registradas e concluídas após a adoção do Scrum é mostrado na Tabela 2:
Tabela 2 – Implementação do Scrum
| Mês/Ano | Solicitações cadastradas | Solicitações concluídas | Período médio para conclusão |
| Ago/2022 | 33 | 30 | 54 dias |
| Set/2022 | 59 | 59 | 20 dias |
| Out/2022 | 34 | 31 | 13 dias |
| Totais | 126 | 120 | 24 dias |
| Média mensal | 46,5 | 45 | – |
Observa-se que tanto a média mensal de pedidos de inscrição saltou de 19 para 46,5 vezes, um aumento de 144,7%, quanto a média mensal de pedidos de participação aumentou, passando de 7 vezes para 45 vezes, um aumento de 542,8%. O Scrum não apenas permite que mais solicitações sejam atendidas, mas também permite que a equipe use um fluxo de trabalho mais rígido para que nenhuma solicitação fique sem registro. Outro aspecto importante que precisa ser verificado é a redução do tempo médio de ciclo para conclusão de uma solicitação de 70 dias para 24 dias.
Desafios para a implementação de métodos ágeis
Ainda existem desafios para a adoção dos métodos ágeis nas empresas, o report trouxe os principais motivos citados, são eles:
Inconsistências nos processos e práticas, com 46%;
Choques culturais, com 43%;
Resistência organizacional geral a mudança, com 42%;
Falta de habilidades e experiência, com 42%;
Ausência de participação da liderança, com 41%.
Podemos avaliar que, as principais barreiras para a implementação dos métodos, são questões de cultura organizacionais. Empresas que não enxergam o potencial das metodologias, ou que não suportam o processo de mudança de mentalidade, atribuição de novas tarefas e cargos, irão possuir dificuldades nessa adoção, deixando de evoluir conforme os estudos apontam, dessa forma ficando para trás em relação aos seus concorrentes que utilizam os métodos.
5.Considerações Finais/Conclusões
Através dessa pesquisa podemos considerar que os índices de êxito da metodologia ágil são relativamente maiores quando comparados aos da metodologia cascata, ao considerarmos a dimensão do projeto esta discrepância fica ainda mais explícita. Na metodologia ágil, mudanças de objetivos no projeto são bem recepcionadas e compreendidas com naturalidade, e o Scrum é um dos métodos mais empregados nas empresas.
Em concordância com os pontos levantados, os métodos ágeis são excelentes escolhas, entretanto, é necessário considerar alguns fatores fundamentais a fim de obter bons resultados, como a disponibilidade de capital, comprometimento da equipe, propósitos claros e bem definidos, expertise em projetos pelos colaboradores envolvidos além de assumir a estrutura padrão do método, do contrário, existe a possibilidade de imprecisões análogas ao método cascata ocorrerem.
Apesar de termos a concepção através do estudo realizado de que os métodos ágeis são mais positivos e possuem menor chance de falha ao serem confrontados ao tradicional, devemos considerar coeficientes externos que podem influenciar de modo direto no resultado dele, sendo de forma positiva ou negativa. Para a escolha do modelo ideal, deve-se acatar a real necessidade da área, bem como, quais os objetivos, prazos e direcionamentos estipulados, o que pode ser definido pela equipe designada para o desenvolvimento do projeto.
6. Referências Bibliográficas
Royce , Winston W. (1970): Gerenciando o Desenvolvimento de Grandes Sistemas de Software: Conceitos e Técnicas. Fonte: Artigo Royce: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
Antônio José F. Andrade, J. C. (2012). Artigo Scrum. Fonte: EnuComp – Encontro Unificado da Computação: http://www.enucomp.com.br/2012/conteudos/artigos/scrum.pdf
Caio Noleto (2020) Modelo Cascata: O que é e por que está ultrapassado? https://blog.betrybe.com/tecnologia/modelo-cascata/#:~:text=O%20modelo%20cascata%20%E2%80%94%20tamb%C3%A9m%20conhecido,s%C3%A3o%20executadas%20de%20forma%20sequencial.
PRESSMAN Roger S. Engenharia de software. Mc Fraw Hill, 6 ed, Porto Alegre, 2006.
SOMMERVILLE, Ian. Engenharia de Software. Pearson, 9 ed, São Paulo, 2011.
PAULA FILHO, Wilson de Pádua. Engenharia de software: fundamentos, métodos e padrões. 2. ed. Rio de Janeiro: LTC, 2003.
SBROCCO, J.H.T.de C., MACEDO, P.C. Metodologias ágeis: engenharia de software sob medida. São Paulo: 1. Ed. Érica, 2012.
15TH ANNUAL STATE OF AGILE REPORT. Boston, Massachusetts: Digital.Ai, v. 15, n. 15, 01 out. 2021. Anual. Disponível em: https://digital.ai/resource-center/analyst-reports/state-of-agile-report/. Acesso em: 05 abr. 2022.
HOME OFFICE’ DEVE CRESCER 30% APÓS CRISE DE CORONAVÍRUS, APONTA FGV. São Paulo: Valor Investe – Globo, 14 dez. 2020. Mensal. Disponível em: https://valorinveste.globo.com/objetivo/empreenda-se/noticia/2020/04/14/home-office-deve-crescer-30percent-apos-crise-de-coronavirus-aponta-fgv.ghtml. Acesso em: 10 maio 2022.
SANTOS, Renata. Metodologias Ágeis para desenvolvimento de software. 2013. Disponível em: <http://www.blogti.microcampsp.com.br/metodologias-ageis-para- desenvolvimento-de-software-parte-i/>. Acesso em: 04 set. 2014.
SCRUM. Disponível em: <http://desenvolvimentoagil.com.br/scrum/>. Acesso em: 08 out. 2014.
SILVA, Carlos Eduardo Azevedo Costinhas da. Um estudo de caso sobre a adoção de práticas ágeis em um ambiente tradicional. 2013. 103 f. TCC (Graduação) – Curso de Sistemas de Informação, Universidade Federal do Estado do Rio de Janeiro (UNIRIO), Rio de Janeiro, 2013.
VARASCHIM, Jacques Douglas. Implantando o SCRUM em um Ambiente de Desenvolvimento de Produtos para Internet. 2009. Curso de Ciência da Computação, Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro, 2009.
MOURA, G. C. de M. Citação de referências e documentos eletrônicos. Disponível em: <http://www.elogica.com.br/users/gmoura/refere.html> Acesso em: 09 out. 1996.