SILVA, Francisco Eronildo da [1]
PINTO, Aurílio Guimarães [2]
FREITAS, Caio Guimarães [3]
ALMEIDA, Cristiany Caliri de [4]
RIBEIRO, Dallas dos Santos [5]
LEITE, Francisco Canindé da Silva [6]
OLIVIERA, Geveson de Souza [7]
MORAIS, Gilvanete Melo de [8]
PERES, Paulo Júnior de Jesus [9]
SILVA, Francisco Eronildo da; et.al. Aplicabilidade da Metodologia Agil no Desenvolvimento de Software – Scrum como Referência. Revista Científica Multidisciplinar Núcleo do Conhecimento. Edição 07. Ano 02, Vol. 03. pp 05-16, Outubro de 2017. ISSN:2448-0959
Resumo
Este estudo tem o objetivo de analisar a celeridade que as metodologias ágeis dão ao processo de desenvolvimento de software, mostrando como as empresas do mercado utilizam essas metodologias como forma de diminuir tempo e esforço no desenvolvimento de software, tomando como referência a metodologia SCRUM. A metodologia ágil parte da premissa em que os resultados devem ser alcançados de maneira rápida sem comprometer a qualidade do produto final (software), nesse sentido o SCRUM é uma metodologia que tem por finalidade aperfeiçoar o planejamento de projetos de software cuja premissa é quebrar o produto em partes menores e assim entregar ao cliente funcionalidades sem que este espere muito tempo para visualizá-las. Dentre os autores pesquisados para a constituição conceitual deste trabalho, destacaram-se Aragon Fernandes (2014), Sommerville (2007), Roger Pressman (2011), Kim Pries (2010) e Schwaber Ken (2014). As conclusões mais relevantes são que o uso de metodologias ágeis pode dar celeridade ao desenvolvimento de software, mostrando mais eficácia, dinamismo e oferecendo vantagens para as empresas que adotarem a metodologia, fatos esses, demonstrados neste trabalho.
Palavras-chave: Metodologias Ágeis, Scrum, Governança de TI, Engenharia de Softwares.
1. Introdução
As metodologias ágeis começaram a ter ênfase na década de 80. O site DEVMEDIA destaca que: “Metodologias ágeis existem há anos, desde a década de 80, mas algumas informações passam por distorções, fato que dificultou no início a utilização das metodologias. Por conseguinte, desenvolvedores passaram a entender a metodologia ágil como algo que tudo se pode, ou seja, podemos desenvolver sem documentação, sem padrão e sem cuidado. Isto não é verdade, as metodologias ágeis podem trazer sucesso ao projeto, e são utilizadas inclusive na indústria.” Este trabalho demonstra baseado em autores renomados que as metodologias ágeis matem a organização e o cuidado necessário que o projeto de software necessita para ser eficiente e eficaz, e a cada dia, ganha o mercado de desenvolvimento de software, sendo utilizadas nas indústrias e órgãos públicos que contratam fábricas terceirizadas para desenvolver seus sistemas.
O presente estudo delimita-se a mostrar os benefícios que a metodologia ágil traz para o desenvolvimento de software. Como exemplo se tem o modus operandi da CTIS, empresa de software que atua no mercado nacional e que adota a metodologia de desenvolvimento de software comum, mas que está dependendo do cliente, optando pela metodologia ágil.
É o caso da Superintendência da Zona Franca de Manaus – SUFRAMA, que, através de licitação, contratou o serviço da CTIS e optou pela mudança para a metodologia ágil.
A SUFRAMA é uma autarquia federal responsável por gerir incentivos fiscais. A maioria dos seus sistemas são críticos e operam com limitações, por isso, licitou-se o serviço de fábrica de software que trabalhe com métodos ágeis. A opção por métodos ágeis se deu em razão de entregas rápidas e com qualidade, pois a metodologia tradicional engessava o processo.
A metodologia ágil dispensa um calhamaço de papel, foca na qualidade do produto, pois o que interessa ao cliente é o software funcionando.
Não é objetivo deste trabalho entrar nos detalhes da mudança de metodologia adotada pela SUFRAMA, e sim, exemplificar que várias indústrias e órgãos governamentais, estão optando pela mudança de seu modelo de desenvolvimento de software para a metodologia ágil.
Apesar de ser uma opção para o desenvolvimento de software, a metodologia ágil, que oferece certamente vários benefícios para o desenvolvimento, pode não ser indicada para todos os projetos. Para um melhor entendimento do assunto, deve-se, rever um pouco da história do desenvolvimento ágil.
O objetivo geral deste trabalho é fazer uma revisão sistemática da metodologia ágil. O método SCRUM será o objeto desse estudo, onde serão elencados os pontos negativos e positivos.
Esta pesquisa justifica-se pela necessidade que a indústria de softwares tem de realizar entregas de produtos com o menor tempo possível aos seus clientes, sem perder de vista a qualidade, economicidade e satisfação.
A metodologia deste trabalho é a pesquisa descritiva e explicativa, tendo como coleta de dados o levantamento bibliográfico.
2. Desenvolvimento
Este estudo tem início revendo o conceito de Software que foi inicialmente proposto em 1968, em uma conferência organizada para discutir o que foi então chamado de “crise do software”. A crise do software resultava indiretamente da introdução de um novo hardware de computador baseado em circuitos integrados. A aplicação de circuitos integrados fez das aplicações de computador, consideradas até então não realizáveis, propostas viáveis. O software resultante era maior e mais complexo que sistemas anteriores de software (SOMMERVILLE, 2007).
A Engenharia de Software é um ramo de engenharia, cujo foco é o desenvolvimento dentro de custos adequados de sistemas de software de alta qualidade. A Engenharia de Software é uma tecnologia em camadas, que envolvem ferramentas, métodos, processo e foco na qualidade. (SOMMERVILLE, 2007). Qualquer abordagem de engenharia (inclusive de software) deve estar fundamentada em um comprometimento organizacional com a qualidade.
A gestão da qualidade total Seis Sigma1 (GYGI; DECARLO; WILLIAMS, 2008) e filosofias similares promovem uma cultura de aperfeiçoamento contínuo de processos, e é esta cultura que, no final das contas, leva ao desenvolvimento de abordagens cada vez mais efetivas na Engenharia de Software. A pedra fundamental que sustenta a engenharia do software é o foco na qualidade (PRESSMAN, 2011).
Com relação à história do desenvolvimento ágil, a mesma teve início em 2001, com o “Manifesto para o desenvolvimento ágil de software”, que foi assinado por Kent Beck, um engenheiro de software americano criador do Extreme Programming e Test Driven, e mais dezesseis renomados desenvolvedores. Detalhes desse fato podem ser verificados no endereço https://www.agilealliance.org/agile101/the-agile-manifesto/.
O manifesto prioriza os indivíduos e as interações mais que os processos e as ferramentas; o software funcionando mais que uma documentação completa, a colaboração com o cliente ao invés de negociações de contratos e respostas a mudanças acima de seguir um plano.
Isso não tira a importância da documentação ou dos processos, e de maneira nenhuma reportam a ineficácia das ferramentas, significa, no entanto, que a entrega do software é mais valorizada, como declara Pressman:
“A engenharia de software ágil combina filosofia com um conjunto de princípios de desenvolvimento. A filosofia defende a satisfação do cliente e a entrega de incremental prévio; equipes de projetos pequenas e altamente motivadas; métodos informais; artefatos de engenharia de software mínimos e, acima de tudo, simplicidade no desenvolvimento geral. Os princípios de desenvolvimento priorizam a entrega mais que a análise e projeto (embora essas atividades não sejam desencorajadas); também priorizam a comunicação ativa e contínua entre desenvolvedores e clientes”. (Pressman, 2011)
Um projeto envolve pessoas e mudanças, principalmente quando falamos de entregas constantes. Desta forma as metodologias ágeis trabalham com equipes altamente motivadas, por estarem ligadas diretamente ao processo, envolvidas em cada parte do mesmo, sentindo sobre si a responsabilidade do êxito do trabalho e sabendo que tem a possibilidade de suporte a mudanças durante todo o processo de desenvolvimento.
No desenvolvimento ágil, não se faz um plano completo com tudo que devemos realizar para depois iniciar o desenvolvimento, sem contato com o cliente, ao invés disso, desenvolvemos incrementalmente, ou seja, o produto é feito aos poucos e entregue constantemente, desta forma, qualquer mudança necessária solicitada pelo cliente ou vista pelos membros do projeto, em qualquer momento do desenvolvimento, não acarretará danos total e a mudança pode ser realizada sem prejuízos maiores, pois o projeto está em desenvolvimento e não foi concluído por completo.
Os incrementos iniciais do sistema podem fornecer uma funcionalidade de alta prioridade, de forma que os clientes logo poderão obter valor do sistema durante seu desenvolvimento. Os clientes podem assim ver os requisitos na prática e especificar mudanças para serem incorporadas nos releases posteriores do sistema.
Desta forma, o cliente pode usufruir dos recursos do sistema de forma mais rápida. O que antes demoraria meses será entregue em semanas, podendo verificar erros e especificar novas mudanças ou melhorias, não necessitando chegar ao final do desenvolvimento para ver os problemas.
Essa metodologia também proporciona um maior conhecimento do sistema à equipe, pois a mesma vai entendendo o negócio ao desenvolvê-lo, fazendo-o assim, com maior velocidade e precisão, e em caso de erros, a equipe perderá menos tempo para a análise, podendo corrigir o erro rapidamente.
Segundo Aguinaldo Aragon Fernandes (2014), inicialmente, o “Scrum foi idealizado com foco acentuado na entrega de projetos de desenvolvimento de software em ambiente complexos. Entretanto, tem sido cada vez mais aplicado em projetos de desenvolvimento de produtos de outras naturezas”.
Aragon afirma ainda que:
“O Scrum consiste em método iterativo e incremental para o gerenciamento de projetos complexos, cujo objetivo é garantir agilidade nas entregas e maximizar a aderência aos requisitos dos clientes, a cooperação entre os integrantes da equipe e a produtividade de cada participante. É um dos métodos dos denominados “ágeis” mais difundidos no mercado de TI, (Aragon Fernandes 2014).
As metodologias ágeis podem ser aplicadas nas resoluções de problemas complexos de desenvolvimento de softwares, como informa Schwaber:
“Situações de projetos complexos ocorrem quando a complexidade das atividades intermediárias não permite que seja criado um processo definido controlado, que consiga gerar repetitivamente produtos em níveis aceitáveis de qualidade. A complexidade de um projeto é diretamente proporcional à complexidade dos requisitos dos clientes e da tecnologia envolvida, ale de ser bastante dependente das características de cada membro da equipe, levando-se em conta a diversidade de habilidades, conhecimentos, atitudes etc, que pode ser encontrada em qualquer grupo de pessoas”. Schwaber (2004)
Em situações como essa, Schwaber recomenda a utilização do conceito de controle empírico de processo, que utiliza mecanismos como auto-organização e senso de urgência e conta com os seguintes pilares:
“Visibilidade: todos os aspectos que afetam os resultados almejados devem ser visíveis para os processos de controle.
Inspeção: Os vários aspectos do processo devem passar por inspeções frequentes, visando detectar variações inaceitáveis.
Adaptação: o processo ou seus produtos intermediários devem ser ajustados após a inspeção para minimizar futuros desvios mais severos, caso suas características e resultados estejam fora dos limites aceitáveis e coloque em risco a aceitação do produto final”. Schwaber (2004)
O Scrum está estruturado em um conjunto de práticas conduzidas por equipes em papeis específicos, organizados em um fluxo de atividades ou eventos de duração fixa, totalmente controlado com artefatos e regras bem definidos, que visa à obtenção de produtos utilizáveis em intervalos curtos de tempo.
Todas as práticas do Scrum estão baseadas em um “esqueleto” representado por iterações sucessivas de atividades de desenvolvimento, (cada uma delas gerando um incremento de produto), inspecionadas e ajustadas diariamente por membros da própria equipe de trabalho, e orientadas por uma lista de requisitos iniciais.
No começo de cada iteração, a equipe revisa o que deve ser feito e determina o que de funcionalidade viável para ser entregue no final da iteração. A equipe é liberada para empregar o seu melhor esforço no restante da iteração e apresenta no final o produto final construído.
A figura abaixo mostra o fluxo do Scrum:
Em um projeto Scrum, todas as responsabilidades estão divididas entre três papéis:
ProductOwner: pessoa responsável por gerenciar o Backlog do Produto (garantindo que esteja visível para todos), gerar e disseminar os requisitos do projeto, assim como o plano para as entregas sucessivas, priorizando os resultados que trarão maior valor agregado ao projeto.
Scrum Master: responsável por implementar o método Scrum, assim como ensiná-lo a todos os envolvidos nos projetos e assegurar que todos sigam as regras e práticas.
Time Scrum: grupo de desenvolvimento coletivamente responsável pelo sucesso de cada iteração e do projeto como um todo, deve ser composto por pessoas multidisciplinares e com capacidade auto-organização e autogestão.
O processo preconizado pelo Scrum abrange os seguintes elementos conforme ilustração abaixo:
A Visão: deve ser elaborada pelo ProductOwner, incluindo o plano de releases e o marcos de entregas de produtos a cada Sprint, de forma a maximizar o retorno sobre o investimento do projeto de desenvolvimento do produto.
O Backlog do Produto: também elaborado pelo ProductOwner, contém uma lista dos requisitos funcionais e não funcionais, priorizados e divididos em releases (Sprints).
A Reunião de Planejamento da Sprint: o projeto é dividido em Sprints com duração de trinta dias corridos cada, a serem executadas uma após a outra, sem interrupção. O planejamento é feito em uma reunião com a participação do Time Scrum e pelo ProductOwner, em dois períodos de quatro horas cada:
Na primeira hora é definido o escopo (“o quê”) será tratado pela Sprint, por meio da seleção dos requisitos do Backlog do Produto que serão colocados no Backlog da Sprint.
Nas quatro horas finais, ocorre o planejamento propriamente dito das tarefas a serem executadas na Sprint, (“como”) e o início oficial da Sprint, momento em que começa a correr o prazo de 30 dias.
O Sprint: a própria iteração de desenvolvimento do produto, que possui duração fixa. Uma Sprint compreende também as suas reuniões de planejamento, revisão e retrospectiva.
O Scrum Diário: reunião diária de quinze minutos, onde cada membro da equipe responde as seguintes questões:
- que fiz no projeto desde o último Scrum Diário?
- O que estou planejando fazer até o próximo Scrum Diário?
- Existe alguma restrição ou impedimento para que eu honre meu compromisso da Sprint atual e/ou do projeto?
Além disso, a equipe sincroniza as atividades de todos e programa reuniões necessárias para a continuação do projeto.
Detalhando um pouco mais as partes vistas até o momento.
A Reunião de Revisão da Sprint: em quatro horas, o Time Scrum apresenta para o ProductOwner (e os demais stakeholders) o resultado do trabalho gerado na Sprint e determina junto a eles o que deve fazer na próxima Sprint.
A Reunião de Retrospectiva da Sprint: em três horas, o Scrum Master estimula os membros do Time Scrum a revisarem o seu processo de desenvolvimento à luz das práticas e do modelo de processo do Scrum, visando torná-lo mais eficaz e gratificante para a próxima Sprint.
Ainda de acordo com Schwaber (2004), as reuniões de planejamento da Sprint, o Scrum Diário, a revisão e a retrospectiva da Sprint constituem, juntas, as práticas empíricas de inspeção e adaptação do Scrum.
Existem duas categorias de artefatos no contexto do Scrum: as tabelas de Backlog e os gráficos que mostram o trabalho que inda falta até o final (denominado BurndownCharts).
As tabelas de Backlogs são: Backlog do Produto: consiste em um documento “vivo” elaborado e mantido pelo ProductWoner que, por definição, nunca está completo (uma vez que sempre existem melhorias a serem implantadas em um produto, até que este esteja finalmente retirado de circulação). Contém uma lista de tudo o que constitui as mudanças que serão realizadas no produto para suas futuras versões (características, funções, tecnologias, adaptações, melhorias, correções etc.). tais requisitos são ordenados por prioridade e detalhados em termos de atributos de descrição, fatores de complexidade/ajustes e estimativas (de esforço e prazo) ao longo das futuras Sprints.
O Backlog da Sprint: define as tarefas que o Time Scrum deve executar para criar os incrementos do produto (oriundo do Backlog do produto) durante a execução de uma Sprint. O seu detalhamento deve ser suficiente para que possa ser acompanhado nas reuniões do Scrum Dario, em tarefas que duram entre quatro e dezesseis horas.
Cada tarefa deve ser documentada, pelo menos, em termos do seu responsável, do status (não iniciada, em andamento, finalizada) e da quantidade de horas de trabalho restante a cada dia da Sprint.
Os BurndownCharts mostram, graficamente, a quantidade de trabalho estimado (esforços restantes) ao longo do tempo, refletindo a sua correlação com o progresso das equipes do projeto em reduzir o seu trabalho. Podem ser utilizados no contexto do Backlog do Produto (incluindo todas as Sprints) ou dentro de cada uma das Sprints (Burndow da Sprint).
O Scrum, como citado anteriormente, foi originalmente criado para utilização em projetos de software em ambientes complexos, ou seja, onde os requisitos mudam com alguma freqüência, que possam ter o seu escopo ou a sua estrutura analítica de projeto EAP ou WBS organizado e estruturado em pacotes de artefatos incrementais, consistentes e utilizáveis, a serem entregues ao cliente em períodos sucessivos de quinze a trinta dia cada.
A princípio este conceito é perfeitamente aplicável a qualquer projeto ou programa cujo objetivo seja o desenvolvimento de produtos ou serviços de outra natureza, ou mesmo que envolva iniciativas de melhoria por meio da utilização de metodologias com Lean, Seis Sigma etc. Em suma, o Scrum é uma abordagem recomendada, que tem demonstrado forte aplicabilidade, para projetos que exigem a combinação focada das habilidades e dos conhecimentos de um time e que envolvam esforços colaborativos intensos.
Segundo Pries&Quigley (2010) existem maneiras de adaptar o Scrum para aplicação em vários tipos de programas e projetos complexos, tais como:
Combinando com métodos tradicionais de gerenciamento de projetos: podem-se relacionar conceitos e artefatos, tais como EAP (Estrutura Analítica do Projeto) e Backlog do Produto, Análise de Valor Agregado, os BurndowsCharts e o Plano de Comunicação, às reuniões de controle das Sprints (planejamento, diária, revisão, retrospectivas) etc.
Gerenciamento de programas complexos: adoção de uma estrutura de Scrum de Scrum, onde o Backlog do produto pode ser decomposto em sub-backlogs, cada um sendo consumido pelo seu respectivo Time Scrum.
Atuação em áreas funcionais que atende a vários projetos (por exemplo, equipes de testes ou garantia de qualidade): no Baclog de Produto, podem entrar tarefas dos vários projetos e no Backlog de cada Spint, aquelas tarefas que couberem no prazo de trinta dias.
Combinado com a tecnologia no formato “cascata”: pode-se dividir o cronograma em modelo de duração fixa, de forma a sincronizar, por exemplo, uma sequência de Sprint com um marco (milestone) previsto no projeto, assim como realizara as atividades de verificação e validação de forma evolutiva em cada Sprint.
Combinando com a abordagem Seis Sigma: podem-se encapsular cada uma das fases da metodologia DMAIC (Define, Measure, Analyze, Improve, Control) em uma Sprint, executando-se uma após a outra.
Schwaber (2004) menciona a possibilidade de utilização do Scrum em um contexto de contrato com preço e duração prefixados. Nesses casos, o Backlog do Produto pode ser utilizado não somente para demonstrar ao cliente que os requisitos foram compreendidos, mas também que a prioridade de cada um para geração de valor foi compreendida. Os requisitos mais relevantes podem ser selecionados para as primeiras Sprints e os incrementos na funcionalidade mensurados a cada reunião de acompanhamento.
É importante salientar que a adoção do Scrum por uma organização deve ser realizada de forma criteriosa e que há muitos desafios a serem enfrentados.
Vamos relacionar alguns dos pontos que, se não forem bem gerenciados, podem colocar em risco a eficácia da metodologia Scrum:
É fundamental ter uma equipe que funcione bem trabalhando em grupo, uma vez que o sucesso do trabalho depende de um esforço intensivo nas habilidades que cada um tem como diferencial;
É importante que cada membro dos Times Scrum tenha um forte senso de autogestão.
Deve-se garantir que os integrantes da equipe estejam alocados a somente um projeto.
Deve-se garantir o comprometimento de todos os envolvidos (principalmente por parte daqueles que representam o cliente).
Deve-se assegurar que os Backlogs estejam bem documentados, de forma que não haja mal-entendidos entre os envolvidos.
Pode haver algumas dificuldades para “atomizar” as tarefas a serem colocadas em cada linha dos backlogs, assim como para estabelecer as dependências entre elas, o que poderá prejudicar o planejamento e o bom andamento na execução das Sprints.
Deve-se garantir que todas as reuniões (planejamento, diária, revisão, retrospectiva) das Sprints sejam realizadas e que os tempos fixos sejam efetivamente cumpridos, sob risco de prejudicar o senso de disciplina, que é crucial para o sucesso do método.
Conclusão
Diante das citações de vários autores, fica notório a agilidade e celeridade que as metodologias ágeis, em especial o SCRUM, escolhida para exemplificar as demais neste trabalho, dão às empresas que contratam fábricas de softwares.
Entre as vantagens, podemos destacar: a maior agilidade no controle e no gerenciamento do andamento dos trabalhos, ênfase no trabalho em equipe e foco em resultados rápidos, responsabilidade dividida com o grupo causando um maior senso de comprometimento, entregas mais rápidas e eficientes, encurtar feedback dando ênfase a comunicação e aumentando a satisfação do cliente por ter o tempo de entrega do software diminuído, sem perder a qualidade, e aumentado o lucro da empresa.
Referências
FERNANDES, A. A.; ABREU, V.F.: Implantando a governança de TI, 4ª Ed.- São Paulo, SP: Editora Brasport Livros e Multimídia Ltda, 2014.
PRESSMAN, R. 2011 Engenharia de Software Uma Abordagem Profissional. Tradução Ariovaldo Griesi, Mario Moro Fecchio. 7º ed. – São Paulo, SP: MGH Editora Ltda, 2011.
PRIES, Kim H., QUIGLEI, Jon M. Scrum Project Management. CRC Press, 2010
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo, Pearson Addison Wesley, 2007.
SCHWABER, Ken. Agile Project Mangement with Scrum. Microsoft Press, 2014.
The agile manifesto. Disponível em: <https://www.agilealliance.org/agile101/the-agile-manifesto/>.Acesso em 21 de outubro de 2016.
Manifesto para o desenvolvimento ágil de Software. Disponível em: <http://www.manifestoagil.com.br/>. Acesso em 21 de outubro de 2016.
Uma visão geral sobre Metodologia Ágil. Disponível em: <http://www.devmedia.com.br/uma visao-geral-sobre-metodologia-agil/27944/>. Acesso em 21 de outubro de 2016.
[1] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.
[2] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.
[3] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.
[4] Graduada em Administração, atua como servidora pública na SUFRAMA, no cargo Administradora.
[5] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.
[6] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.
[7] Graduado na área de computação, atua como servidor SUFRAMA, no cargo de Analista Técnico Administrativo – TI.
[8] Graduada em Economia, atua como servidora pública na SUFRAMA, no cargo de Economista.
[9] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.
