ANÁLISE DA IMPLANTAÇÃO DA METODOLOGIA ÁGIL SCRUM PARA GERENCIAMENTO DE PROJETOS DE DESENVOLVIMENTO DE SOFTWARE

ANÁLISE DA IMPLANTAÇÃO DA METODOLOGIA ÁGIL SCRUM PARA GERENCIAMENTO DE PROJETOS DE DESENVOLVIMENTO DE SOFTWARE

Philipe Amaral dos Santos

Universidade Presbiteriana Mackenzie

Av. Sargento Geraldo Santana, 1100 – Jardim Marajoara

04674-225 – São Paulo – Brasil

[e-mail]

Prof. Msc. Arão Sapiro

Universidade Presbiteriana Mackenzie

---

RESUMO

Este Trabalho de Graduação Interdisciplinar tem como objetivo analisar a implantação da metodologia ágil Scrum em empresas brasileiras de desenvolvimento de software, comparando suas motivações, desafios e possíveis vantagens em relação à utilização de metodologias tradicionais. Para isso, é feita extensa investigação em papers, livros e sites especializados em metodologias de gerenciamento de projetos software, além de um estudo de caso, analisando relatos e entrevistas em empresas que passaram pelo processo de adoção do Scrum. Os principais pontos observados em cada relato são comparados entre si e entre pesquisas de âmbito nacional sobre a implantação de metodologias ágeis.

Palavras-chave: Scrum. Gerenciamento de Projetos. Desenvolvimento de Software.

---

ABSTRACT

This research aims to analyze the implementation of the agile method Scrum in Brazilian software development companies, comparing their motivations, challenges and potential advantages over the use of traditional methodologies. For this, extensive research is done on papers, books and websites specializing in management methodologies software projects, as well as a case study, analyzing reports and interviews in companies that have gone through the adoption of Scrum. The main points identified in each report are compared to each other and nationwide surveys on the deployment of agile methodologies.

Keywords: Scrum, Project Management. Software development.

---

1. REVISÃO DA LITERATURA

Entre os anos 1950 até o fim dos anos 1990 muitas metodologias e ferramentas foram criadas para otimizar o processo de desenvolvimento de softwares e adaptá-los à evolução das necessidades mercadológicas de cada década. Dentre os modelos criados nesse período, o mais conhecido e utilizado é o modelo sequencial linear, ou método Cascata, como ficou conhecido devido à sua abordagem top-down. O método Cascata serviu de ponto de partida para grande parte das metodologias criadas a partir da década de 1970, que ficaram conhecidas como metodologias tradicionais. Por ser o mais conhecido e praticado em todo o mundo, este método será o foco deste capítulo.

Winston Royce propôs na década de 1970 um modelo direcionado a grandes projetos de desenvolvimento de software, principalmente motivado por desafios que surgiam durante a elaboração de programas militares para o governo dos Estados Unidos. (ROYCE,1970).

Royce (1970) afirmou que existem duas fases essenciais em todos os projetos de criação de software, independentemente do tamanho e da complexidade. Primeiro a fase de análise, seguida pela fase de programação. Utilizar apenas essas duas etapas pode ser extremamente útil e suficiente em projetos pequenos e de baixa complexidade. No entanto, para projetos de maior complexidade e tamanho, ao adotar somente estas duas etapas, há grandes chances do projeto fracassar. Em vista disso, Royce desenvolveu seu modelo utilizando, mas expandindo, estas duas fases, acrescentando a elas fases sequenciais bem definidas e estruturadas.

 Também chamado de ciclo de vida clássico ou método Cascata, este modelo sugere uma abordagem sistemática e sequencial para o desenvolvimento de software que se inicia no nível de sistema e avança através da análise, arquitetura, programação, teste e suporte. (PRESSMAN, 2001).

No método Cascata, a execução de cada projeto segue um fluxo linear bem definido e constituído de várias fases distintas que são realizadas em série.

Pressman (2001), descreve as etapas do processo da seguinte forma: requisitos do sistema, requisitos do software, arquitetura, elaboração do código (programação), teste e suporte. Pelo software ser sempre parte de um sistema maior, o processo inicia-se estabelecendo requisitos para todos os elementos do sistema e alocando alguns subconjuntos destes requisitos ao software. Esta visão global é essencial quando o software precisar interagir com outros elementos como hardware, pessoas e bases de dados.

O processo de coleta dos requisitos é intensificada e passa a focar especificamente no software. Os requisitos do sistema e do software são então documentados e revisados junto ao cliente. Ao fim da etapa de requisitos, terá sido criada uma especificação minuciosamente detalhada e acordada entre as partes que servirá como referência e irá guiar as etapas seguintes do projeto.

A TechRepublic (2014), argumenta que o método Cascata, como é descrito acima, oferece uma série de vantagens aos desenvolvedores de software. Primeiro, o estágio de desenvolvimento enfatiza a disciplina: cada fase possui um ponto de início e fim definidos, e o progresso pode ser claramente identificado com o uso de milestones (marcações que definem pontos importantes no cronograma do projeto), tanto pelo desenvolvedor quanto pelo cliente. A ênfase dada aos requisitos e arquitetura antes de se escrever uma única linha de código garante mínimo desperdício de tempo e esforço, e reduz o risco de descumprimento do cronograma, ou das expectativas do cliente não serem atendidas.

O rigor formal, em especial no que se refere à documentação, é uma das características que permeiam o método Cascata. Privilegia-se a elaboração de uma boa documentação de todos os elementos obtidos e produzidos em todas as fases dos projetos, além dos respectivos artefatos. Tudo aquilo que é documentado como pertencente ao escopo do projeto é considerado objeto do desenvolvimento (TOMOMITSU, 2008).

Embora a proposta original de Royce (1970), fizesse considerações sobre a importância de “curvas de feedback” entre as fases do processo, a grande maioria das organizações que aplicam este modelo faz uso de uma abordagem estritamente linear Além disso, muitas vezes é difícil para o cliente declarar todos os requisitos do software explicitamente. O método Cascata exige isso e tem dificuldade em acomodar a incerteza natural que existe no início de muitos projetos. O cliente precisa ter paciência. Uma versão em desenvolvimento do programa não estará disponível até uma das fases finais do projeto. Uma grande falha, se não for detectada até que o programa chegue à fase de revisão/teste, pode ser desastroso. (PRESSMAN, 2001).