APLICAÇÃO DE METODOLOGIAS ÁGEIS PARA EMPRESAS DE PEQUENO/MÉDIO PORTE

Prévia do material em texto

INSTITUTO FEDERAL DE CIÊNCIA E TECNONOLOGIA DE SÃO PAULO CÂMPUS 
SÃO JOÃO DA BOA VISTA 
 
 
 
 
 
 
ALAN DELGADO DA SILVA 
 
 
 
 
 
Aplicação de Metodologias Ágeis para Empresas de Pequeno/Médio Porte 
 
 
 
 
 
 
 
 
 
 
 
 São João da Boa Vista 
2013 
 
ALAN DELGADO DA SILVA 
 
 
 
 
 
 
Aplicação de Metodologias Ágeis para Empresas de Pequeno/Médio Porte 
 
 
 
 
 
 
 
Trabalho de conclusão de curso apresentado ao Instituto Federal de 
Educação, Ciência e Tecnologia de São Paulo, como parte dos 
requisitos para a obtenção do grau de Tecnólogo em Sistemas para 
Internet 
 
Área de Concentração: Engenharia de Software 
 
Orientador: Prof. Breno Lisi Romano 
 
 
 
 
 
 
 
 
São João da Boa Vista 
2013 
 
Autorizo a reprodução e divulgação total ou parcial deste trabalho, por qualquer meio 
convencional ou eletrônico, para fins de estudo e pesquisa, desde que citada à fonte. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Ficha catalográfica preparada pela Seção de Tratamento 
 da Informação do Serviço de Biblioteca – IFSP 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Da Silva, Alan D. 
 Aplicação de Metodologias Ágeis para Empresas d e 
Pequeno/Médio porte. / Alan Delgado da Silva; orien tador 
Prof. Breno Lisi Romano. São João da Boa Vista, 201 3. 
 
 
 Trabalho de Conclusão de Curso, IFSP, 2013. 
 
 
1. Metodologia Ágil. 2. Scrum. 3. Empresa de 
Pequeno/Médio Porte. 4. Gerência de Projetos. 
 
I. Aplicação de Metodologias Ágeis para Empresas 
de Pequeno/Médio Porte. 
 
 
 
AGRADECIMENTOS 
Primeiramente aos meus pais, Terezinha J. A. Silva e Jair Delgado da Silva que, com 
muito carinho e apoio, não mediram esforços para que eu chegasse até esta etapa de 
minha vida, compreendendo toda a minha ausência. 
 
A minha irmã querida, Gislaine Delgado e seu marido Clodoaldo, além de toda a nossa 
“Grande Família Sanjoanense”, que demonstraram amor e confiança, e que me 
apoiaram fornecendo momentos de alegria e companheirismo. 
 
Agradeço a minha querida Patrícia Freitas, não somente por estar ao meu lado, mas 
também por compreender minhas ausências, fornecendo suporte emocional e 
intelectual; imprescindíveis para me ajudar manter minhas metas. 
 
Ao professor e orientador Breno Lisi Romano por seu apoio e inspiração no 
amadurecimento dos meus conhecimentos e por ter guiado os meus passos, que me 
levaram a execução deste trabalho. 
 
A empresa SIMPLISS por acreditar e apoiar financeiramente a minha iniciativa de 
realizar um estudo de caso. 
 
A equipe da SIMPLISS, Wagner Boa Ventura, Rafael Sena, Rafael Ruggi, Cironei 
Carvalho, Felipe Benutti, Fabio Serafim e demais outros colegas que com 
companheirismo participaram do estudo de caso, enfrentando aos desafios com bom 
humor e amizade. 
 
Aos amigos eternos, que mesmo tendo minha presença tenha sido escassa, 
continuaram a me apoiar e a incentivar constantemente. 
 
E finalmente a todos aqueles que, direta ou indiretamente, colaboraram para que este 
trabalho consiga atingir aos objetivos propostos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
“Se você pensa que pode ou se pensa que não pode, de 
qualquer forma você está certo.” 
 (Henry Ford) 
 
 
RESUMO 
 
DA SILVA, Alan Delgado. (2013). Aplicação de Metodologias Ágeis para Empresas de 
Pequeno/Médio Porte. Trabalho de Conclusão de Curso - Instituto Federal de Educação, Ciência e 
Tecnologia de São Paulo, São João da Boa Vista, 2013. 
 
 Este trabalho tem como objetivo apresentar à implantação de metodologias ágeis em 
empresas de pequeno/médio porte, visando propiciar um acompanhamento na execução das 
atividades envolvidas no desenvolvimento de projetos de software e, consequentemente, auxiliar no 
controle da utilização de recursos humanos e de tempo nestes desenvolvimentos. Para atingir este 
objetivo, foi realizado um levantamento bibliográfico contendo assuntos relevantes para este 
trabalho, bem como considerações sobre o contexto atual de empresas de pequeno e médio porte no 
Brasil, suas características e dificuldades atuais. É abordado também sobre algumas áreas da 
Engenharia de Software, principalmente em relação às metodologias ágeis, o manifesto ágil, as 
principais metodologias ágeis que são utilizadas e seu impacto no mercado de tecnologia. Por fim, é 
depositado um foco maior nas metodologias Scrum e técnicas como Kanban, Planning Poker e 
Gráfico Burndown, sendo a base para a pesquisa, em que se apresentam, principalmente, os 
princípios, ideologia, os procedimentos e resultados esperados. Depois da realização deste 
levantamento, foi utilizada como estudo de caso desta pesquisa uma empresa de pequeno porte, 
situada em São João da Boa Vista - SP. A aplicação do Scrum nesta empresa foi dividida em um 
processo com três etapas: Infraestrutura, Treinamentos e Prática. A Infraestrutura partindo da 
situação inicial da empresa preparando-a para iniciar a implantação. A utilização de treinamentos foi 
necessária para explicar para a equipe os conceitos da metodologia ágil e prepará-los para utiliza-lá. 
E, por fim, foi realizada a prática dos conceitos do Scrum em um dos projetos da empresa, no qual 
foram relatados os primeiros ciclos de desenvolvimento, sendo apresentados os acontecimentos de 
cada evento durante o desenvolvimento. Podem ser observadas logo nas primeiras interações algumas 
melhorias, principalmente quanto a comunicação, motivação da equipe e agilidade em adaptações 
durante o desenvolvimento do software escolhido. 
 
Palavras-chave: Metodologia Ágil. Scrum. Empresa de Pequeno/Médio Porte. Gerência de Projetos. 
ABSTRACT 
 
DA SILVA, Alan Delgado. (2013). Applying Agile Methodologies for Medium and Small-sized 
companies. Course Conclusion Project – Instituto Federal de Educação, Ciência e Tecnologia de 
São Paulo, São João da Boa Vista - SP, 2013. 
 
 This research proposes to demonstrate the agile methodologies deployment in medium and 
small-sized companies, in order to provide better monitoring of implementation activities involved in 
software projects developing, and thus to support uses’ control of resources like human and time on 
these developments, in addition to increasing the rate of successful delivery of projects. To achieve 
this goal, we conducted a literature review on subjects relevant to this work. It covered the current 
context of Brazil small and medium-sized companies, its characteristics and current difficulties. It 
also discussed about Software Engineering, mainly in relation to Agility, Agile Manifesto, main agile 
methodologies that are used and their impact in the technology market. Finally, it is deposited a 
greater focus on methodologies Scrum and techniques such as Kanban, Planning Poker and 
Burndown Chart, the basis for this research, especially in presenting the principles, ideology, 
procedures and outcomes. After performing this literature review, it was chosen as a case study for 
this research in a small company located in São João da Boa Vista - SP. The application of Scrum at 
this company was divided into a process with three stages: Infrastructure, Training and Practice. 
The Infrastructure stage started from the initial situation of the company preparing it to begin 
deployment. The Training stage was needed to explain to the team the agile methodology concepts 
and prepare them for uses them. Finally, at the last stage there was the practice of Scrum concepts in 
one of the company's projects, which were reported in the early development cycles, presented some 
activities of each event during the development. It can be observed in the first few interactions, some 
improvements mainly about communication, team motivation and agility in the applying adaptation 
during development of the chosen software project. 
 
Keywords: Agile Methodology. Scrum. Medium andsmall-sized companies. Project Management. 
LISTA DE FIGURAS 
 
Figura 1 - Camadas da engenharia de software. Fonte: Pressman (2006). .......................................... 32 
Figura 2 – Modelo Cascata ou Sequencial Linear. Fonte: Pressman (2006). ...................................... 36 
Figura 3 – Modelo Incremental. Fonte: Pressman (2006). .................................................................. 37 
Figura 4 – Modelo RAD. Fonte: Pressman (2006). ............................................................................. 38 
Figura 5 – Modelo Prototipagem. Fonte: Pressman (2006). ................................................................ 40 
Figura 6 – Modelo Espiral. Fonte: Pressman (2006). .......................................................................... 41 
Figura 7 – Ciclo de vida da metodologia DAS. Fonte Adaptada: Pressman (2006). ........................... 45 
Figura 8 – Categorias de Características FDD. Fonte Adaptada: Pressman (2006). ........................... 52 
Figura 9 – Percentual de projetos da organização que adotam métodos ágeis. Fonte: Melo et al. 
(2012) ................................................................................................................................................... 54 
Figura 10 – Qual metodologia ágil é mais utilizada. Fonte: Melo et al. (2012) .................................. 55 
Figura 11 – Razão mais importante para a adoção de metodologia ágil. Fonte: Melo et al. (2012). .. 55 
Figura 12 – Maiores preocupações da organização na adoção. Fonte: Melo et al. (2012). ................. 56 
Figura 13 – Percepção sobre a velocidade dos projetos após a adoção de métodos ágeis. Fonte: Melo 
et al. (2012). ......................................................................................................................................... 56 
Figura 14 – Benefícios observados após a adoção de metodologias ágeis. Fonte: Melo et al. (2012).57 
Figura 15 – Principais causas de falha em projetos ágeis na organização. Fonte: Melo et al. (2012). 57 
Figura 16 – Desafios em implantar metodologias ágeis. Fonte: Melo et al. (2012). ........................... 58 
Figura 17 – Diferença de custo de uma mudança de escopo nos projetos ágeis versus tradicionais. 
Fonte Adaptada: Camara (2007). ......................................................................................................... 59 
Figura 18 – Ciclo de Desenvolvimento Scrum. Fonte Adaptada: Brandini (2011) ............................. 67 
Figura 19 – Exemplo de Gráfico Burndown. Fonte: Cruz (2013). ...................................................... 71 
Figura 20 – Exemplo de quadro Kanban. Fonte: Kniberg e Skarin (2009). ........................................ 72 
 
Figura 21 - Organograma da Empresa...................................................................................................76 
Figura 22 – Fluxo de Trabalho em relação ao setor de desenvolvimento ............................................ 78 
Figura 23 – Processo de Desenvolvimento Existente .......................................................................... 79 
Figura 24 – Etapas da implantação do Scrum no Estudo de Caso. ...................................................... 83 
Figura 25 – Quadro Kanban utilizado no Estudo de Caso. .................................................................. 85 
Figura 26 – Representação da Equipe Scrum Formada para o Estudo de Caso ................................... 89 
Figura 27 – Gráfico Burndown – Sprint 001 ...................................................................................... 101 
Figura 28 – Gráfico Burndown – Sprint 002. ..................................................................................... 112 
Figura 29 – Gráfico Burndown – Sprint 003 ...................................................................................... 122 
LISTA DE TABELAS 
 
Tabela 1 – Classificação do Porte da Empresa confome SEBRAE pelo número de empregados. Fonte 
adaptada: SEBRAE (2011). ................................................................................................................. 28 
Tabela 2 – Classificação do Porte das Empresas Conforme BNDES. Fonte Adaptada: BNDES 
(2012). .................................................................................................................................................. 28 
Tabela 3 – Fases Genéricas da Engenharia de Software. Fonte Adaptada: Pressman (2002). ............ 33 
Tabela 4 – Características das Metodologias Crystal. Fonte Adaptada: Cockburn (2002). ................ 47 
Tabela 5 – Principais Práticas do XP e seus Aspectos Negativos. Fonte Adaptada: Savoine et al. 
(2009). .................................................................................................................................................. 50 
Tabela 6 – Comparação entre Tradicional x Àgil. Fonte adaptada: Magalhães et al.( 2004). ............. 60 
Tabela 7 - Responsabilidades do Product Owner em relação ao Backlog do Produto. Fonte Adaptada: 
Schwaber e Sutherland (2011). ............................................................................................................ 63 
Tabela 8 - Características da Equipe de Desenvolvimento. Fonte: Schwaber e Sutherland (2011) .... 64 
Tabela 9 – Cronograma de Implantação .............................................................................................. 83 
Tabela 10 – Características dos Integrantes da Equipe Scrum. ........................................................... 90 
Tabela 11 – Visão do Produto .............................................................................................................. 91 
Tabela 12 – Modelo de Product Backlog............................................................................................. 92 
Tabela 13 – Sprint Backlog e suas respectivas estimativas – Sprint 001. ............................................ 94 
Tabela 14 – Diário de Bordo das Reuniões Diarias da Sprint 001 – 09/10/2012 à 12/10/2012 .......... 95 
Tabela 15 - Diário de Bordo das Reuniões Diarias da Sprint 001 – 15/10/2012 à 19/10/2012 ........... 96 
Tabela 16 - Diário de Bordo das Reuniões Diarias da Sprint 001 – 22/10/2012 à 26/10/2012 ........... 98 
Tabela 17 – Tarefas Finalizadas – Sprint 001 .................................................................................... 100 
Tabela 18 - Sprint Backlog e suas respectivas estimativas – Sprint 002. .......................................... 104 
Tabela 19 - Diário de Bordo das Reuniões Diarias da Sprint 002 – 27/11/2012 à 30/11/2012 ......... 105 
Tabela 20 - Diário de Bordo das Reuniões Diarias da Sprint 002 – 03/12/2012 à 07/12/2012 ......... 107 
Tabela 21 - Diário de Bordo das Reuniões Diarias da Sprint 002 – 10/12/2012 à 14/12/2012 ......... 109 
Tabela 22 – Tarefas Finalizadas - Sprint 002 ..................................................................................... 111 
Tabela 23 - Sprint Backlog e suas respectivas estimativas – Sprint 003. ........................................... 114 
Tabela 24 - Diário de Bordo das Reuniões Diarias da Sprint 003 –08/01/2013 à 11/01/2013 .......... 116 
Tabela 25 - Diário de Bordo das Reuniões Diarias da Sprint 003 – 14/01/2013 à18/01/2013 .......... 117 
Tabela 26 - Diário de Bordo das Reuniões Diarias da Sprint 003 – 21/01/2013 à 25/01/2013 ......... 119 
Tabela 27 – Tarefas Finalizadas - Sprint 003 ..................................................................................... 121 
Tabela 28 – Comparação da Metodologia Proposta x Tradicional x Ágil ......................................... 124 
Tabela 29 – Padrão de respostas ao questionário ............................................................................... 126 
Tabela 30 – Características pesquisadas e suas justificativas ............................................................ 126 
Tabela 31 –Participantes do Questionário ......................................................................................... 128 
Tabela 32 – Resultado do Questionário - Antes da implantação da metodologia .............................. 128 
Tabela 33 - Resultado do Questionário - Depois da implantação da metodologia. ........................... 129 
Tabela 34 – Comparação de resultados – Antes e Depois da Implantação da Metodologia Ágil. ..... 129 
Tabela 35 – Desempenho da equipe. .................................................................................................. 131 
 
 
LISTA DE SIGLAS 
 
ABRASF Associação Brasileira das Secretarias de Finanças das Capitais 
BD Banco de Dados 
BNDES Banco Nacional de Desenvolvimento Econômico e Social 
COBIT Control Objectives for Information and related Technology 
CRUD Create, Read, Update e Delete 
DAS Desenvolvimento Adaptativo de Software (Adaptative Software Development) 
DECA Declaração Cadastral 
DIPAM Declaração para o Índice de Participação dos Municípios 
DSDM Dynamic Systems Development Method 
FDD Desenvolvimento Guiado por Características (Feature Driven Development) 
IDE Ambiente Integrado de Desenvolvimento (Integrated Development Environment) 
ISSQN Imposto Sobre Serviço de Qualquer Natureza 
NFS-e Nota Fiscal de Serviços Eletrônica 
RAD Desenvolvimento Rápido de Aplicação - (Rapid Application Development) 
ROB Receita Operacional Bruta Anual 
ROI Retorno Sobre Investimento (Return on Investment) 
SEBRAE Serviço Brasileiro de Apoio às Micro e Pequenas Empresas 
TI Tecnologia da Informação 
XP Programação Extrema (Extreme Programming) 
 
SUMÁRIO 
 
1 INTRODUÇÃO ............................................................................................................................. 23 
1.1 Motivação .................................................................................................................................................. 24 
1.2 Objetivos .................................................................................................................................................... 25 
1.2.1 Objetivo Geral ......................................................................................................................................... 25 
1.2.2 Objetivos Específicos .............................................................................................................................. 25 
1.3 Organização deste trabalho ........................................................................................................................ 26 
2 PESQUISA BIBLIOGRÁFICA ...................................................................................................... 27 
2.1 Conceito de Empresas de Pequeno e Médio Porte ..................................................................................... 27 
2.2 Características de Empresas de Pequeno e Médio Porte ............................................................................ 29 
2.3 Visão Geral sobre o Desenvolvimento de Software em Empresas de Pequeno/Médio Porte .................... 30 
2.4 Engenharia de Software ............................................................................................................................. 32 
2.5 Processos de Software ................................................................................................................................ 33 
2.6 Modelos de Processos de Software ............................................................................................................ 35 
2.6.1 Principais Modelos de Processo de Software .......................................................................................... 35 
2.6.1.1 Modelo Cascata .................................................................................................................................. 35 
2.6.1.2 Modelo Incremental ........................................................................................................................... 37 
2.6.1.3 Modelo RAD ...................................................................................................................................... 38 
2.6.1.4 Modelo Prototipagem ......................................................................................................................... 39 
2.6.1.5 Modelo Espiral ................................................................................................................................... 40 
2.6.2 Mudança de Paradigma no Desenvolvimento ......................................................................................... 41 
2.7 Metodologias Ágeis ................................................................................................................................... 42 
2.7.1 Histórico e Origem do Manifesto Ágil .................................................................................................... 42 
2.7.2 Abordagens de metodologia ágil ............................................................................................................. 44 
2.7.2.1 Adaptative Software Development (DAS) .......................................................................................... 45 
2.7.2.2 Crystal ................................................................................................................................................ 46 
2.7.2.3 DSDM (Dynamic Systems Development Method) ............................................................................. 48 
2.7.2.4 Extreme Programming (XP) .............................................................................................................. 49 
2.7.2.5 FDD (Feature Driven Development) ................................................................................................. 51 
2.7.2.6 Scrum ................................................................................................................................................. 53 
2.7.3 Metodologias Ágeis e o Mercado de TI .................................................................................................. 53 
2.7.3.1 Aspectos da Implantação em Empresas de TI ................................................................................... 54 
2.8 Comparação entre Metodologias: Tradicionais x Ágeis ............................................................................ 58 
2.9 Metodologia Ágil Scrum ........................................................................................................................... 61 
2.9.1 Origens e Conceitos ................................................................................................................................ 61 
2.9.2 Framework .............................................................................................................................................. 62 
2.9.2.1 Papéis e Responsabilidades ............................................................................................................... 63 
2.9.2.2 Time-boxes ......................................................................................................................................... 66 
2.9.2.3 Ciclo de desenvolvimento .................................................................................................................. 67 
2.9.2.4 Eventos da Sprint ............................................................................................................................... 68 
2.9.2.5 Artefatos e Ferramentas ..................................................................................................................... 69 
2.9.3 Scrum + Kanban ..................................................................................................................................... 71 
3 METODOLOGIA ............................................................................................................................75 
3.1 Estudo de Caso: Caracterização da Empresa SIMPLISS .......................................................................... 75 
3.1.1 A Empresa e o Ramo de Atuação ........................................................................................................... 75 
3.1.2 Setor de Desenvolvimento ...................................................................................................................... 77 
3.1.3 Processo de Desenvolvimento Existente................................................................................................. 79 
3.1.4 Melhorias Almejadas para a Situação Existente ..................................................................................... 80 
3.2 Análise do ambiente em relação à Metodologia Ágil Scrum .................................................................... 81 
3.3 Planejamento Proposto para a Implantação de um Novo Processo de Desenvolvimento ......................... 82 
3.4 Primeira Etapa: Infraestrutura ................................................................................................................... 84 
3.5 Segunda Etapa: Treinamentos ................................................................................................................... 86 
3.5.1 Scrum Master .......................................................................................................................................... 86 
3.5.2 Product Owner ........................................................................................................................................ 87 
3.5.3 Equipe de Desenvolvimento .................................................................................................................... 87 
3.6 Terceira Etapa: Prática ............................................................................................................................... 88 
3.6.1 Time Scrum formado para o Projeto ....................................................................................................... 89 
3.6.2 Escopo do Projeto .................................................................................................................................... 91 
3.6.2.1 Definição da Visão do Produto .......................................................................................................... 91 
3.6.2.2 Definição do Product Backlog ........................................................................................................... 92 
3.6.3 Desenvolvimento do Projeto ................................................................................................................... 92 
3.6.3.1 Sprint 001 ........................................................................................................................................... 93 
3.6.3.1.1 Release Planning Meeting – Sprint 001 ......................................................................................... 93 
3.6.3.1.2 Sprint Planning Meeting – Sprint 001 ............................................................................................ 94 
3.6.3.1.3 Execução da Sprint 001 .................................................................................................................. 95 
3.6.3.1.4 Sprint Review da Sprint 001 ......................................................................................................... 100 
3.6.3.1.5 Sprint Retrospective da Sprint 001 ............................................................................................... 101 
3.6.3.2 Sprint 002 ......................................................................................................................................... 102 
3.6.3.2.1 Release Planning Meeting – Sprint 002 ....................................................................................... 103 
3.6.3.2.2 Sprint Planning Meeting – Sprint 002 .......................................................................................... 103 
3.6.3.2.3 Execução da Sprint 002 ................................................................................................................ 105 
3.6.3.2.4 Sprint Review - Sprint 002 ............................................................................................................ 111 
3.6.3.2.5 Sprint Retrospective - Sprint 002 .................................................................................................. 112 
3.6.3.3 Sprint 003 ......................................................................................................................................... 113 
3.6.3.3.1 Release Planning Meeting – Sprint 003 ....................................................................................... 113 
3.6.3.3.2 Sprint Planning Meeting – Sprint 003 .......................................................................................... 114 
3.6.3.3.3 Execução da Sprint 003 ................................................................................................................ 116 
3.6.3.3.4 Sprint Review - Sprint 003 ............................................................................................................ 120 
3.6.3.3.5 Sprint Retrospective - Sprint 003 .................................................................................................. 122 
4 RESULTADOS ........................................................................................................................... 124 
4.1 Preparação do Questionário ..................................................................................................................... 125 
4.2 Resultados do Questionário ..................................................................................................................... 127 
5 CONCLUSÕES ............................................................................................................................ 133 
5.1 Trabalhos Futuros .................................................................................................................................... 134 
5.2 Produções Científicas e Tecnológicas da Pesquisa ................................................................................. 134 
REFERÊNCIAS ................................................................................................................................ 135 
APÊNDICE A- QUESTIONÁRIO DE AVALIAÇÃO DA IMPLANTAÇÃO DAS METODOLOGIAS 
ÁGEIS ............................................................................................................................................... 141 
 
 
 
 
23 
Capítulo 
 
1 Introdução 
 
Ao longo dos anos, o desenvolvimento de software tem se tornado um componente 
estratégico para diversas áreas de negócio (PRIKLADNICKI, 2003). Segundo Herbsleb et al. 
(2001), para as organizações que buscam sucesso, é clara a necessidade do uso da Tecnologia 
da Informação (TI) como diferencial competitivo. Com isto, o desenvolvimento de sistemas 
tem ganhado grande espaço no mercado mundial. 
Diversas novas empresas, surgiram ao longo dos anos, para suprir esta demanda de 
novos projetos de TI. Com esta nova concorrência, tem-se exigido cada vez mais qualidade, 
custos reduzidos e que prazos sejam cumpridos deste mercado (SAVOINE et al., 2009). De 
acordo com Beck (2004), o desenvolvimento de software tem falhas na entrega e nos valores 
entregues, e essas falhas, têm impactos econômicos e humanos enormes. É necessário achar 
uma maneira de desenvolver software com qualidade e entregas frequentes. 
Segundo Siqueira (2007), na tentativa de organizar as atividades de desenvolvimento 
de software, surgiu à Engenharia de Software e as primeiras metodologias de 
desenvolvimento. Estas primeiras metodologias eram baseadas fortemente em planejamento 
e documentação extensivos, como em outras engenharias. 
Apesar desta tentativa de organização, essas metodologias continuaram apresentandofalhas no desenvolvimento de software, principalmente gerando problemas como estouro de 
prazo e orçamento (STANDISH GROUP, 2001). 
De acordo com Pressman (1997), “o gerenciamento da qualidade total e filosofias 
similares fomentam uma cultura de melhoria contínua de processos e esta cultura leva ao 
desenvolvimento de abordagens mais maduras de engenharia de software”. 
Com a necessidade de melhora contínua do processo, foram criadas novas abordagens 
de gestão de projetos denominadas metodologias ágeis. Em linhas gerais, as metodologias 
ágeis são abordagens de gestão de projetos que tem como principal objetivo orientar o 
processo de produção de sistemas computacionais, conseguindo ser flexíveis à dinamicidade 
do ambiente, que acaba sendo corriqueiro no desenvolvimento de software com geração de 
valor e inovação (CONFORTO & AMARAL, 2007; BERNI, 2010). 
24 
 
Mesmo com toda a evolução no desenvolvimento de software, conforme apresentado 
anteriormente, ainda existem dificuldades a serem sanadas nas empresas em geral (TOLEDO 
et al., 2008; CHAGAS, 2005; MACULAN, 2003). 
. 
1.1 Motivação 
 
Apesar do controle e da tentantiva de garantir uma resposta satisfatória no final de 
projetos de software, recentes pesquisas na área de Engenharia de Software (CHAOS 
MANIFESTO, 2010), do ano de 2009, revelam que apenas 32% dos projetos foram entregues 
respeitando os prazos e os custos e com todas as funcionalidades especificadas. 
Aproximadamente 24% dos projetos foram cancelados antes de estarem completos e 44% 
foram entregues, porém com prazos maiores, custos maiores ou com menos funcionalidades 
do que especificado no início do projeto. 
Considerando todos os projetos que foram entregues além do prazo e com custo maior, 
apenas 60% das funcionalidades originais foram incluídas (CHAOS MANIFESTO, 2010) 
Esses projetos, em sua maioria, são desenvolvidos por empresas de pequeno e médio 
porte, que se apresentam em grande quantidade comparadas as de grande porte e que, 
consequentemente, demostram suas importâncias na economia do país (ALMEIDA, 2009). 
Nesses ambientes, podem-se encontrar alguns fatores que demostram as causas de 
tantas falhas no desenvolvimento de novos software, como a falta de processos para garantir a 
qualidade e prazos não serem adotados, gerando inúmeros problemas na entrega do produto; e 
também manutenção dos mesmos, resultando em custos excedentes (TOLEDO et al., 2008). 
Nota-se também que diversos sistemas desenvolvidos por essas empresas possuem 
problemas técnicos causados, principalmente, pela ausência de um projeto arquitetural ou até 
mesmo um projeto detalhado do software. Outro problema frequente é que a análise de 
requisitos ocorre esporadicamente, além de ser considerado não apropriado, o que pode gerar 
um excesso de funcionalidades que futuramente podem não ser utilizadas (TOLEDO et al., 
2008; CHAGAS, 2005; MACULAN, 2003; MARCH-CHORDÀ et al., 2002). 
Diante de todo contexto apresentado anteriormente, para este trabalho escolheu-se 
uma empresa de pequeno porte da cidade de São João da Boa Vista - SP como estudo de caso, 
visando apresentar a implantação de uma solução de metodologia ágil por ela possuir vários 
problemas frequentes das empresas de pequeno e médio porte, principalmente a falta de 
processos de trabalho no desenvolvimento de novos projetos (CHAGAS, 2005), o que 
25 
 
resultaria em uma melhor qualidade do software e possibilita uma resposta mais rápida as 
dificuldades encontradas durante o processo de desenvolvimento. 
 
1.2 Objetivos 
 
Nesta seção, apresentam-se o objetivo geral desta pesquisa e também os seus objetivos 
específicos: 
 
1.2.1 Objetivo Geral 
 
Este trabalho tem por objetivo demostrar a implantação da metodologia ágil Scrum em 
uma empresa de pequeno porte, visando propiciar um melhor acompanhamento na execução 
das atividades envolvidas no desenvolvimento de projetos de software e, consequentemente, 
auxiliar no controle da utilização de recursos humanos e de tempo nestes desenvolvimentos. 
 
1.2.2 Objetivos Específicos 
 
Seguem abaixo os passos mínimos e necessários para se atingir ao objetivo proposto 
para esta pesquisa: 
• Levantamento bibliográfico sobre processos de desenvolvimento de software, 
metodologias ágeis e sua atual presença nas empresas brasileiras de pequeno e 
médio porte; 
• Relato de trabalhos relacionados com esta pesquisa, principalmente aqueles 
que mostram implantações de metodologias ágeis em empresas de pequeno e 
médio porte; 
• Definição da estratégia para implantação das metodologias ágeis Scrum e de 
algumas técnicas auxiliares, como o Kanban, o gráfico de Burndown e 
Planning Poker; e 
• Apresentação da implantação da estratégia, destacando os resultados e 
conclusões obtidas. 
 
26 
 
1.3 Organização deste trabalho 
 
Este trabalho está organizado em cinco capítulos, sendo que este primeiro 
capítulo apresenta o contexto no qual a proposta de trabalho de conclusão de curso 
está inserida, bem como os objetivos e a motivação para o seu desenvolvimento. 
O Capítulo 2 apresenta o levantamento bibliográfico contendo assuntos 
relevantes para este trabalho. São feitas considerações sobre o contexto atual de 
empresas de pequeno e médio porte, suas características e dificuldades atuais. É 
abordado também considerações sobre Engenharia de Software, abordando 
principalmente em relação às metodologias ágeis, o manifesto ágil e as principais 
metodologias ágeis que são utilizadas. Por fim, é depositado um foco maior na 
metodologia Scrum e nas técnicas auxiliares, como o Kanban, o gráfico de Burndown 
e Planning Poker; pois são a base para a pesquisa, apresentando principalmente os 
princípios, ideologia, os procedimentos e forma de resultados esperados. 
O Capítulo 3 apresenta a experiência obtida na implantação da metodologia 
ágil Scrum em uma empresa de pequeno porte, organizado de forma cronológica, 
partindo da situação inicial da empresa, dos treinamentos feitos com a equipe sobre as 
metodologias, relatos dos primeiros procedimentos e resultados obtidos. 
No Capítulo 4 foca no resultado da aplicação de metodologias ágeis na 
empresa escolhida para a implantação, apresentando, principalmente, quais objetivos e 
ideais da metodologia ágil foram atingidos. Foi relatado também o resultado de um 
questionário de avaliação (Survey) da implantação. 
 No Capítulo 5 encontram-se as conclusões que comentam os resultados 
obtidos, as contribuições e limitação deste trabalho, produções cientificas e 
tecnológicas da pesquisa, além de sugestões para trabalhos futuros. 
 O Apêndice A contem o questionário de avaliação da implantação utilizado 
(Survey). 
 
 
 
27 
Capítulo 
 
2 Pesquisa Bibliográfica 
 
 Apresentam-se, neste capítulo, tópicos relevantes para a melhor compreensão da 
natureza deste trabalho. Inicia-se com a definição de empresas de pequeno/médio porte e suas 
características e dificuldades na gestão de projetos. A seguir, é discutido também o papel da 
Engenharia de Software e sua evolução ao longo dos anos, com a chegada da metodologia 
ágil. Por fim, são apresentadas as principais metodologias ágeis, direcionando o foco para a 
metodologia Scrum e de algumas técnicas auxiliares, como o Kanban, o gráfico Burndown e 
Planning Poker, que são as principais bases para esta pesquisa. 
 
2.1 Conceito de Empresas de Pequeno e Médio Porte 
 
Não é de hoje que as empresas de pequeno e médio porte tem ganhado destaque em 
todo mundo, por sua influência na economia e na população (PERUCH, 2011). 
Segundo Peruch (2011), apesar deste impacto na sociedade e do esforço 
governamental/social na tentativa de favorecer o surgimento de mais empresas deste porte, é 
complicado, nos dias atuais, definir quais são as empresas que fazem parte deste grupo. 
Atualmente, no Brasil não existe uma forma de classificação legal do porte de uma empresa 
oficialmente, ficandoa cargo de alguns orgãos discutirem em utilizarem suas próprias 
definições. As classificações mais utilizadas e reconhecidas para determinar o porte das 
empresas são a do Banco Nacional de Desenvolvimento Econômico e Social (BNDES) e do 
Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) (BNDES, 2012; 
SEBRAE, 2011). 
Segundo o SEBRAE (2011), a classificação do porte das empresas deve ser 
considerada a partir da quantidade de funcionários que as empresas têm registrados em 
carteira de trabalho. É considerado também dois ramos de atividades: indústria e 
comércio/serviços. A Tabela 1 mostra o porte das empresas de acordo com sua categoria: 
 
28 
 
Tabela 1 – Classificação do Porte da Empresa confome SEBRAE pelo número de empregados. Fonte adaptada: 
SEBRAE (2011). 
PORTE DA 
EMPRESA INDÚSTRIA COMÉRCIO E SERVIÇOS 
Micro Até 19 Até 09 
Pequeno De 20 a 99 De 10 a 49 
Médio De 100 a 499 De 50 a 99 
Grande Maior que 500 Maior que 100 
 
É possível observar na Tabela 1 que empresas de pequeno e médio porte, seguindo 
este critério de classificação do SEBRAE, são as que possuem até 100 funcionários no caso 
de comercio e serviços, ou de até 500 se for da indústria. 
Em contra partida, o critério utilizado pelo BNDES (2012), principalmente pelo 
segmento deste órgão ser bancário, classifica as empresas considerando a receita operacional 
bruta anual, como pode ser observado na Tabela 2: 
 
Tabela 2 – Classificação do Porte das Empresas Conforme BNDES. Fonte Adaptada: BNDES (2012). 
PORTE DA 
EMPRESA RECEITA OPERACIONAL BRUTA ANUAL (ROB) 
Micro ROB <= R$ 2,4 milhões 
Pequeno ROB > R$ 2,4 milhões e ROB <= R$ 16 milhões 
Médio ROB > R$ 90 milhões e ROB <= R$ 300 milhões 
Grande ROB > R$ 300 milhões 
 
Sendo assim, empresas com receitas operacionais brutas anuais de até R$ 300 milhões 
são identificadas como empresas de pequeno e médio porte. 
Segundo Peruch (2011), esta classificação está de acordo com a Lei Complementar n. 
123/06 que institui a Lei do Simples, ou seja, as empresas que podem utilizar o meio de 
pagamento simplificado de impostos, quando se enquadrarem na faixa descrita na Tabela 2. 
Tendo como base estas duas principais formas de se classificar empresas, será adotada 
neste trabalho a classificação estabelecida pelo SEBRAE, levando em consideração o número 
de funcionários da empresa. Também será considerado empresas de Micro porte, como sendo 
empresas de pequeno porte, por ter estrutura e recursos humanos semelhantes aos propósitos 
29 
 
deste trabalho (PEREIRA et al., 2010). Diante disto, apresentam-se, na próxima seção, 
algumas características e dificuldades destas empresas. 
 
2.2 Características de Empresas de Pequeno e Médio Porte 
 
De acordo com Pereira et al. (2010), as empresas de pequeno e médio porte são um 
dos principais pilares de sustentação da economia brasileira, tanto pela sua enorme 
capacidade geradora de empregos quanto pelo grande número de estabelecimentos 
desconcentrados geograficamente. Diante disto, torna-se interessante aprofundar-se nas 
características destas empresas e demonstrar o ambiente em que elas se encontram. 
Ao se observar os relatórios do SEBRAE (2011), sobre o número de empresas 
localizadas no país, percebe-se que a maior concentração ocorre no Estado de São Paulo. O 
número de empresas que estão instaladas no estado chega a ser de 99%, empregando 67% dos 
funcionários no setor privado formal ou informal do país, e participam com 28% na receita 
bruta total do setor formal. 
O Instituto Brasileiro de Geografia e Estatística (IBGE) realizou um estudo sobre as 
principais características de gestão destas empresas, dentre as quais se destacam algumas a 
seguir (IBGE, 2003): 
• Baixo volume de capital empregado; 
• Altas taxas de natalidade e mortalidade; 
• Presença significativa de proprietários, sócios e funcionários com laços 
familiares; 
• Grande centralização do poder decisório; 
• Não distinção da pessoa física do proprietário com a pessoa jurídica, inclusive 
em balanços contábeis; 
• Registros contábeis pouco adequados; 
• Contratação direta de mão-de-obra; 
• Baixo nível de terceirização; 
• Baixo emprego de tecnologias sofisticadas; 
• Baixo investimento em inovação tecnológica; 
• Dificuldade de acesso a financiamento de capital de giro; 
• Dificuldade de definição dos custos fixos; e 
30 
 
• Alto índice de sonegação fiscal e utilização intensa de mão-de-obra não 
qualificada ou sem qualificação. 
Essas características apresentadas demonstram as principais dificuldades na gestão 
destas empresas, onde pesquisas apontam que de 470 mil empresas abertas no ano de 2004, 
49,4% encerram as atividades em até dois anos, 56,4% em até três anos e 59,90% em até 
quatro anos (SEBRAE, 2004). 
 Empresas de tecnologia da informação (TI) sofrem com as mesmas dificuldades 
citadas anteriormente e estão incluidas neste grupo. Além disto, segundo Pereira et al. (2010), 
ao estar situada em um ramo de atividade no qual as inovações tecnológicas são rápidas e 
caras, as pequenas e médias empresas de software enfrentam desafios cada vez maiores para 
se manterem competitivas. Nas próximas seções serão apresentadas mais informações sobre 
como atualmente é a visão geral de empresas de pequeno/médio porte no desenvolvimento de 
software. 
 
2.3 Visão Geral sobre o Desenvolvimento de Software em Empresas de 
Pequeno/Médio Porte 
 
Sendo o foco principal deste trabalho, as empresas de pequeno e médio porte que 
atuam no desenvolvimento de software sofrem com diversas dificuldades no momento de 
realizar a execução de seus projetos, principalmente por problemas de gestão, planejamento e 
humano (PEREIRA et al. 2010). 
Em uma pesquisa realizada por Chagas (2005), na qual se analisou uma pequena 
empresa de desenvolvimento de software da região de Maringá-PR, foram identificadas 
algumas situações negativas quanto ao desenvolvimento de software (PEREIRA et al. 2010): 
• Não adota nenhum modelo de ciclo de vida; 
• A análise de requisitos ocorre esporadicamente e é considerada precária; 
• Não são feitos projetos arquiteturais nem projeto detalhado do software; 
• Poucas partes dos projetos possuem algum tipo de documentação; 
• Não é utilizado nenhum software para o gerenciamento de projetos; e 
• É feito acompanhamento das atividades com base em cronogramas, mas 
existem dificuldades para que os cronogramas sejam cumpridos. 
31 
 
Chagas (2005) cita ainda que apesar dessas situações precárias no desenvolvimento de 
software, encontra-se também alguns pontos positivos, como a utilização de ferramentas de 
desenvolvimento (IDE - Integrated Development Environment) e de gerenciamento de banco 
de dados padronizadas. Esta realidade é encontrada em diversas empresas de pequeno e médio 
porte do setor, nas quais faltam padrões e metodologias na gestão de projetos (PEREIRA et 
al. 2010). 
 De acordo com outra pesquisa realizada por Guerra et al. (2008), que relatava 
justamente as experiências vivenciadas com a prestação de serviços de consultoria em 
melhoria de processo, nas micro e pequenas empresas de desenvolvimento de software, 
existem outras dificuldades para o desenvolvimento de projetos em relação a estratégias e 
metas da empresa. De acordo com Guerra et al. (2008), as principais dificuldades foram: 
• Equipes muito pequenas e falta de recursos financeiros para a contratação de 
novos elementos necessários à equipe ou falta de experiência para contratação 
de novos integrantes para a equipe; 
• Equipes das empresas sem conhecimentos básicos de Engenharia de Software; 
• Pessoas das equipes com dificuldade em conciliar os papéis desempenhados 
com as práticas a serem realizadas; 
• Falta de disciplina interna para a realização das atividades de maneira 
equilibrada por todos os participantes das equipes; 
• Falta de compromisso efetivo, por parte dos responsáveis pela empresa e falta 
de compromissodos dirigentes para o desempenho do processo definido, por 
parte dos elementos da empresa, de uma forma homogênea e disciplinada; 
• Condução de trabalhos paralelos envolvendo a reestruturação da empresa, 
comprometendo o trabalho realizado; e 
• Falta de alinhamento quanto aos objetivos dos dirigentes e da equipe 
operacional. Os gerentes de projetos e desenvolvedores sentiam a necessidade 
de adotar melhores práticas, enquanto o objetivo da diretoria era meramente 
comercial. 
Segundo Pereira et al. (2010), devido a essas características negativas encontradas em 
pequenas e médias empresas no setor de TI, podem passar a existir problemas que de alguma 
forma diminuem a produtividade do processo de desenvolvimento, aumentam o custo do 
projeto e comprometem a qualidade do produto, como por exemplo: 
• Erros de projeto que só são descobertos na fase de implementação; 
32 
 
• Na ausência de um programador, o projeto tem um significativo atraso devido 
à falta de documentação; 
• Os cronogramas muitas vezes não são cumpridos, gerando insatisfação de 
todas as partes envolvidas (clientes, gerentes e programadores); 
• Perde-se muito tempo com a manutenção corretiva ou para adaptações 
exigidas; e 
• Insatisfação do cliente. 
Alheio a isto, existem as abordagens da Engenharia de Software que tentam mudar 
este cenário, utilizando processos e métodos que auxiliam na hora de manter o 
acompanhamento de novos projetos. 
 
2.4 Engenharia de Software 
 
Segundo Pressman (2006), a Engenharia de Software é uma área da computação que 
se divide em três camadas, sendo elas; os processos, os métodos e as ferramentas; e em todas 
as camadas o foco é na qualidade do software desenvolvido, como pode ser visto na Figura 1. 
 
Figura 1 - Camadas da engenharia de software. Fonte: Pressman (2006). 
 
Os processos constituem um elo que conectam os métodos e as ferramentas, 
garantindo o desenvolvimento racional e oportuno de sistemas para computadores, seria a 
base do controle gerencial de projetos de software e definem como; os métodos serão 
aplicados, software produzidos, marcos estabelecidos, qualidade assegurada e modificações 
necessárias executadas (LEITÃO, 2010). 
Por sua vez, métodos proporcionam os passos detalhados para construir o software. E 
por último, as ferramentas são responsáveis pelo apoio automatizado ou semi-automatizado 
33 
 
aos métodos. Por exemplo, ferramentas que combinam software, hardware e banco de dados 
(PRESSMAN, 2006). 
A Engenharia de Software pode ser categorizada em três fases genéricas, nas quais 
podem ser encontradas em diversos tipos de projetos, independendo do tamanho, de sua 
complexidade ou área de atuação (LEITÃO, 2010). Segundo Pressman (2002, p. 20), estas 
fases e suas características estão apresentadas na Tabela 3 a seguir: 
 
Tabela 3 – Fases Genéricas da Engenharia de Software. Fonte Adaptada: Pressman (2002). 
Fases Características 
Definição Concentra-se no “quê”. É necessário identificar: 
– que informação deve ser processada; 
– que função e desempenho são desejados; 
– que comportamento do sistema é esperado; 
– que interfaces devem ser estabelecidas; e 
– que restrições de projeto existem. 
Desenvolvimento Concentra-se no “como”. É necessário definir: 
– como os dados devem estar estruturados; 
– como a função deve ser implementada; 
– como as interfaces devem ser caracterizadas; 
– como o projeto deve ser traduzido em linguagem de programação; e 
– como os testes serão realizados. 
Manutenção Focaliza as modificações associadas com a correção de erros e as 
adaptações necessárias, à medida que o ambiente de software evolui. 
 
A garantia da qualidade do software está diretamente ligada aos processos adotados 
durante o desenvolvimento do mesmo e a forma como são executados, tornando assim de 
grande importância se aprofundar nestes conceitos de processos de software (PRESSMAN, 
2006). 
 
2.5 Processos de Software 
 
Segundo Larman (2004, p.37), um processo de software descreve uma abordagem 
para o desenvolvimento, implantação e, consequentemente, a manutenção deste software. 
Adicionalmente, uma definição específica de processo apresentada por Paula (2001, p.17) diz 
que um processo é uma sequência de passos ordenados, constituídos por atividades, métodos, 
práticas e modificações para atingir uma meta. 
34 
 
 Ao se iniciar um desenvolvimento de software, é de grande importância seguir passos 
e metas para assim conseguir atingir com sucesso o produto desejado. Estes passos envolvem 
diversos fatores, como atividades, limitações e recursos que influenciam diretamente no 
resultado final (LEITÃO, 2010). 
A utilização de processos se torna importante para fornecer estabilidade, controle e 
organização para atividades que podem acabar se perdendo o foco. Para isto, o processo 
adequado deve definir quais atividades a serem realizadas durante o desenvolvimento de 
software, os artefatos necessários e produzidos para as atividades do processo; os 
procedimentos adotados na realização das atividades; os recursos necessários para elaboração 
dos principais artefatos gerados no desenvolvimento e o modelo de ciclo de vida a ser 
utilizado (LEITÃO, 2010). 
Segundo Pressman (2006), o ciclo de vida de todo processo de desenvolvimento de 
sistema deve executar um conjunto mínimo de atividades para se obter um produto de 
software. Ainda acordo com Pressman (2006), as atividades são as seguintes: 
• Comunicação: envolve alta comunicação e colaboração com o cliente e outros 
interessados e abrange o levantamento de requisitos e outras atividades relacionadas: 
procura descobrir, definir, especificar e documentar as funcionalidades gerais do 
software; 
• Planejamento: estabelece um plano para o trabalho de desenvolvimento do software, 
ou seja, descrevem as tarefas, técnicas a serem conduzidos, os riscos do projeto, os 
recursos necessários, os artefatos a serem produzidos e um cronograma de trabalho; 
• Modelagem: cria os modelos que permitem entender melhor os requisitos do software 
e o projeto que vai satisfazer esses requisitos. É a representação de Engenharia do 
Software que vai ser construído; 
• Construção: combina a geração do código-fonte, que deve implementar as 
funcionalidades especificadas e os testes necessários para descobrir os erros na 
função, no comportamento e no desempenho do software; e 
• Implantação: entrega do software ao cliente, que avalia o produto e fornece feedback 
com base na avaliação. 
Não basta ter os processos, é necessário seguí-los em determinada ordem e com um 
padrão de execução. Esta necessidade metódica de execução influenciou o surgimento dos 
modelos de processos de software, onde podem ser utilizadas como base para indicar o 
35 
 
caminho à equipe. Para se aprofundar mais no assunto de metodologias de desenvolvimento, 
apresentam-se na próxima seção os principais modelos de processos de software. 
 
2.6 Modelos de Processos de Software 
 
Os modelos de processos de software tornaram-se uma maneira de evitar situações 
caóticas em atividades complexas. São definidos como um conjunto de atividades, tarefas, 
ações, marcos e produtos de trabalho importantes e necessários para fazer a Engenharia de 
Software com alta qualidade (LEITÃO, 2010). 
Os diferentes tipos de modelo de processo de desenvolvimento de software podem, 
ocasionalmente, adotar as mesmas atividades padrões, nas quais já citamos na seção 2.5, mas 
com ênfase diferente destas atividades, além de possuir um ciclo de vida de forma distinta 
(PRESSMAN, 2006). 
 No desenvolvimento de software, o ponto de partida para a arquitetura de um 
processo é a escolha de um modelo de processo (LEITÃO, 2010). Ocasionalmente, algumas 
organizações acabam criando o seu próprio modelo de processo ou em alguns casos 
realizando uma adaptação para que se encaixe em sua realidade. 
Sendo assim, existem alguns modelos estabelecidos, considerados tradicionais,e que 
já foram utilizados em diversos projetos, validando a sua eficácia. 
 
2.6.1 Principais Modelos de Processo de Software 
 
A seguir, descrevem-se os principais modelos tradicionais encontrados na literatura 
com as suas características. 
 
2.6.1.1 Modelo Cascata 
 
O modelo cascata, muitas vezes chamado de ciclo de vida clássico, é o modelo mais 
antigo da Engenharia de Software, sendo uma abordagem sequencial e sistemática para o 
desenvolvimento de software, onde uma atividade só pode começar depois do término da 
anterior (PRESSMAN, 2006). 
36 
 
Nos últimos anos, o modelo tem recebido críticas e questionamentos sobre algumas de 
suas dificuldades de execução: 
• Projetos reais raramente seguem o fluxo sequencial que o modelo 
propõe. Apesar do modelo linear poder acomodar a integração, ele o faz 
indiretamente. Como resultado, as modificações podem causar confusão à 
medida que a equipe de projeto prossegue; 
• Em geral, é dificil para o cliente estabelecer todos os requisitos 
explicitamente. O modelo em cascata exige isso e tem dificuldade de 
acomodar a incerteza natural que existe no começo de muitos projetos; e 
• O cliente precisa ter paciência. Uma versão executável do(s) 
programa(s) não irá ficar disponível até o período final do intervalo de 
tempo do projeto. Um erro grosseiro pode ser desastroso se não for detectado 
até que o programa executável seja revisto. (PRESSMAN, 2006, p. 39): 
 O fluxo de trabalho do modelo cascata pode ser visto na Figura 2 abaixo: 
 
 
Figura 2 – Modelo Cascata ou Sequencial Linear. Fonte: Pressman (2006). 
 
Devido ao ritmo de desenvolvimento das empresas, nos últimos anos, onde ocorrem 
diversos tipos de interferências e modificações do projeto durante a execução, o modelo 
cascata se tornou ineficaz, sendo recomendado apenas para situações onde os requisitos são 
37 
 
fixos e que a execução das atividades possam seguir de forma linear (PAULA, 2001; 
PRESSMAN, 2006). 
 
2.6.1.2 Modelo Incremental 
 
No modelo incremental, o sistema cresce de forma incremental ao longo do projeto, 
através de interações. Este modelo combina elementos do modelo cascata, aplicando-os de 
forma interativa (PRESSMAN, 2006). 
Durante um projeto que utilize este modelo, o primeiro incremento é chamado de 
núcleo do produto, pois os requisitos básicos são feitos, mas outras características são 
deixadas para depois. Ao longo dos demais incrementos, o software é complementado. 
O principal objetivo com esta abordagem é apresentar um produto operacional a cada 
incremento até se chegar a um produto final. O fato de dividir o desenvolvimento em módulos 
facilita a sua distribuição na hora do desenvolvimento (LEITÃO, 2010). 
Segundo Pressman (2006), o desenvolvimento incremental é interessante quando não 
se existe mão-de-obra suficiente para a implementação completa. Assim, a cada incremento 
pode adicionar pessoas para completar a equipe, sem prejudicar o andamento. 
O fluxo de trabalho do modelo incremental pode ser visto na Figura 3: 
 
 
Figura 3 – Modelo Incremental. Fonte: Pressman (2006). 
 
38 
 
A cada término de incremento, deve-se ter uma versão estável para que o usuário 
possa utilizar, assim como lhe passar um feedback sobre o software (PRESSMAN, 2006). 
 
2.6.1.3 Modelo RAD 
 
O RAD (Rapid Application Development - Desenvolvimento Rápido de Aplicação) é 
um modelo de processo de desenvolvimento incremental, que busca ter um ciclo de 
desenvolvimento extremamente curto. Esta velocidade se dá pelo uso de uma abordagem 
baseada em componentes. O planejamento acaba se tornando de extrema importância, pois em 
alguns momentos existem equipes trabalhando em paralelo (PRESSMAN, 2006). 
Neste modelo, a aplicação pode ser modularizado de modo que permita que cada 
função principal possa ser completada de forma paralela e cada equipe poderia pegar uma 
função específica para o desenvolvimento. 
 O fluxo de trabalho do modelo RAD pode ser visto na Figura 4: 
 
Figura 4 – Modelo RAD. Fonte: Pressman (2006). 
 
39 
 
Como em todos os modelos, podemos encontrar algumas desvantagens. 
1. Para projetos grandes, mas passíveis de sofrer aumento, o RAD exige 
recursos humanos suficientes para criar um número adequado de equipes 
RAD; 
2. Se desenvolvedores e clientes não estiverem comprometidos com as 
atividades continuamente rápidas, necessárias para completar o sistema em 
um curtíssimo espaço de tempo, os projetos RAD falharão; 
3. Se o sistema não puder ser adequadamente modularizado, a 
construção dos componentes necessários ao RAD será problemática; 
4. Se for necessário um alto desempenho e esse desempenho tiver de 
ser conseguido ajustando as interfaces dos componentes do sistema, a 
abordagem RAD pode não funcionar; e 
5. O RAD pode não ser adequado quando os riscos técnicos são altos. 
(PRESSAMAN, 2006, p. 42) 
 
2.6.1.4 Modelo Prototipagem 
 
Dependendo da complexidade do software a ser desenvolvido, frequentemente durante 
a execução, podem surgir novos requisitos ou adaptações, principalmente a pedido do cliente. 
Estas mudanças durante o processo podem gerar uma necessidade de refazer o que já estava 
pronto para se adequar. O modelo de prototipagem busca resolver justamente este problema 
(PRESSMAN, 2006). 
Sendo um modelo iterativo, tem como premissa que o desenvolvimento pode iniciar 
com a informação incompleta, e através de um processo cíclico e dialético de reações do 
usuário ao utilizar o protótipo, os requisitos serão refinados (LEITÃO, 2010). O protótipo 
serve como um mecanismo para identificação dos requisitos do software e deve ser 
descartado (PRESSMAN, 2006). 
Apesar de ser satisfatório para os clientes e para os desenvolvedores, ainda podem 
ocorrer alguns problemas ao utilizar o modelo de prototipagem: 
1. O cliente vê o que parece ser uma versão executável do software, 
ignorando que o protótipo apenas consiga funcionar precariamente. Quando 
informado de que o produto deve ser refeito para que altos níveis de 
qualidade possam ser atingidos, o cliente reclama e exige que o protótipo 
40 
 
seja transformado num produto executável. Em geral, a gerência de 
desenvolvimento de software concorda; e 
2. O desenvolvedor frequentemente faz concessões na implementação a 
fim de conseguir rapidamente um protótipo executável. Passado certo tempo, 
o desenvolvedor pode ficar familizado com essas escolhas e esquecer todas 
as razões por que elas eram inadequadas. A escolha muito aquém da ideal 
tornou-se agora parte integral do sistema (PRESSMAN, 2006, p. 43). 
 
O fluxo de trabalho do modelo de prototipagem pode ser visto na Figura 5: 
 
Figura 5 – Modelo Prototipagem. Fonte: Pressman (2006). 
 
Se clientes e desenvolvedores estiverem cientes que o desenvolvimento de protótipos 
serve como ferramenta de definição de requisitos, a prototipagem pode ser um paradigma 
efetivo, apesar dos problemas citados (PRESSMAN, 2006). 
 
2.6.1.5 Modelo Espiral 
 
O modelo espiral combina a natureza interativa da prototipagem com aspectos 
controlados e sistemáticos do modelo cascata. Cada volta no espiral é uma interação, onde as 
primeiras podem ser modelo de papel ou protótipos. Este processo acaba fornecendo nas suas 
últimas interações versões do software cada vez mais completas (LEITÃO, 2010). 
41 
 
Este modelo diferencia-se dos demais modelos, pois pode ser adaptado para aplicação 
ao longo da vida do software, não apenas terminando quando o sistema é entregue. Deste 
modo, permanece operacional até que o software seja tirado de funcionamento, onde para 
cada alteração pode se tornar uma volta na espiral (PRESSMAN, 2006). 
De acordo com Leitão (2010), este modelo exige que os riscos técnicos sejam 
considerados em todos os estágios do projeto. Onde o seu principal problema é que requer 
uma gestão muito sofisticada para ser previsível e confiável (PAULA, 2001). 
 O fluxo de trabalho do modelo espiral podeser visto na Figura 6: 
 
Figura 6 – Modelo Espiral. Fonte: Pressman (2006). 
 
Segundo Pressman (2006), o modelo espiral é uma abordagem realista do 
desenvolvimento de sistemas e software de grande porte. Devido sua forma evolutiva, o 
desenvolvedor e cliente entendem e reagem melhor aos riscos de cada nivel evolucionário. 
 
2.6.2 Mudança de Paradigma no Desenvolvimento 
 
Apesar de estas metodologias tradicionais oferecerem controle nas atividades e da 
tentantiva de garantir uma resposta satisfatória no final de projetos de software através de 
metódos de processo padronizados, eles continuaram apresentando falhas no 
desenvolvimento, principalmente gerando problemas como estouro de prazo e orçamento 
(STANDISH GROUP, 2001). 
42 
 
Devido à existência de projetos cada vez mais complexos, com cobranças mais 
exigentes por qualidade dos clientes e a necessidade de agilizar o processo sempre buscando 
entregar mais rápido o produto completo, gerou-se a necessidade de melhorar os processos de 
software existentes. Segundo Pressman (1997), “o gerenciamento da qualidade total e 
filosofias similares fomentam uma cultura de melhoria contínua de processos e esta cultura 
leva ao desenvolvimento de abordagens mais maduras de Engenharia de Software”. 
Surgiram então diversas novas abordagens de gestão de projetos denominadas 
metodologias ágeis. Em linhas gerais, as metodologias ágeis são abordagens de gestão de 
projetos que tem como principal objetivo orientar o processo de produção de sistemas 
computacionais, conseguindo ser flexível a dinamicidade do ambiente, que acaba sendo 
corriqueiro no desenvolvimento de software com geração de valor e inovação (CONFORTO 
& AMARAL, 2007; BERNI, 2010). 
Com o principal objetivo de aperfeiçoar processos, sem perda de qualidade, aos 
poucos as metodologias ágeis ganharam espaço nas empresas de desenvolvimento (BERNI, 
2010). Na próxima seção será aprofundada sobre sua filosofia e método de gestão de 
projetos. 
 
2.7 Metodologias Ágeis 
 
Está seção tem o objetivo de apresentar um pouco mais sobre as metodologias ágeis, 
que, ao longo dos anos, tem sido utilizada pela maioria do setor de desenvolvimento de 
software, como alternativa a dinamicidade dos projetos, sem a perda de qualidade e buscando 
aproveitar melhor os recursos utilizados (SAVOINE et al., 2009; LEITÃO, 2010). 
Primeiramente, será apresentado a origem e os fundamentos associados ao conceito de 
desenvolvimento ágil, apresentar algumas abordagens ágeis e fornecer uma visão de seu 
posicionamento no mercado de TI. 
 
2.7.1 Histórico e Origem do Manifesto Ágil 
 
As metodologias ágeis começaram a surgir devido à necessidade do desenvolvimento 
de software ser mais flexível a mudanças, aproveitando melhor os investimentos em cima do 
projeto, em comparação aos métodos tradicionais – caracterizados por uma pesada 
43 
 
regulamentação, regimentação e micro gerenciamento – que dispendem muito tempo em 
análise e planejamento (SAVOINE et al., 2009; LEITÃO, 2010). 
A partir de fevereiro de 2001, um grupo de desenvolvedores de várias partes do 
mundo, que até o momento não concordavam com as técnicas e métodos de desenvolvimento 
de sistemas usados naquele momento, decidiram se unir e criar uma aliança chamada de Agile 
Software Development Alliance, mais conhecida por Agile Alliance (SAVOINE et al., 2009). 
Este grupo de desenvolvedores, formados por profissionais das diversas áreas de 
formação e com pontos de vista diferentes sobre os modelos e métodos de desenvolvimento 
de software em comum, criaram um manifesto para encorajar melhores meios de desenvolver 
software (AMBLER, 2004). Este documento, que ficou nomeado como o Manifesto Ágil ou 
Agile Manifesto, teve como os principais idealizadores Kent Beck, Ken Schwaber, Martin 
Fowler e Jim Highsmith. O manifesto consiste em uma declaração com quatro máximas que 
regem o desenvolvimento ágil (BECK, 2001): 
 
� Indivíduos e interações entre eles ao invés de processos e ferramentas; 
� Software funcional ao invés de documentação; 
� Colaboração do cliente ao invés de negociação de contratos; e 
� Respostas rápidas a mudanças ao invés de seguir planos. 
 
Ou seja, mesmo havendo valor nos itens à direita, valoriza-se mais os itens à esquerda. 
Além das citações acima, o Manifesto cita estes 12 princípios básicos: 
 
1. Nossa maior prioridade é satisfazer os clientes através de rápidas e contínuas entregas 
de software com valor agregado; 
2. Mudanças de requisitos são bem vindas, até mesmo tarde no desenvolvimento. O 
processo ágil assume a mudança como parte da vantagem competitiva de seus clientes; 
3. Entregar software funcionando frequentemente, em algumas semanas ou meses, 
com a preferência ao menor tempo possível; 
4. Homens de negócios e desenvolvedores devem trabalhar juntos durante todo o 
projeto; 
5. Construa projetos através de indivíduos motivados. Dê à equipe um ambiente que 
atenda suas necessidades, e confie em sua capacidade para realizar o trabalho; 
6. A forma mais eficiente e efetiva de circular, criar consenso, uma informação para a 
equipe de desenvolvimento é através da comunicação cara-a-cara; 
44 
 
7. Software em funcionamento é a primeira medida de progresso; 
8. O processo ágil promove o desenvolvimento sustentável. Os clientes, 
desenvolvedores e usuários devem ser capazes de manter uma paz constante 
indefinidamente; 
9. Atenção contínua a excelência técnica e bom design inspira agilidade; 
10. Simplicidade, arte de maximizar a quantidade de trabalho não feito, é essencial; 
11. As melhores arquiteturas, requisitos e designs surgem a partir de equipes 
autogerenciáveis; e 
12. Em intervalos regulares a equipe reflete sobre como se tornar mais eficiente, então 
adaptando seu comportamento de acordo. 
 
As metodologias ágeis têm se destacado principalmente pelas mudanças de perfil na 
hora de lidar com projetos de software. Os princípios básicos remetem uma honestidade ao 
código de trabalho, eficácia em trabalho em grupo e foco no trabalho de equipe (SAVOINE et 
al., 2009). 
A realidade atual é composta por mudanças a todo o momento e requisitos em 
constante evolução, por isso surge à necessidade de metodologias que se adequem a esse 
paradigma. Na metodologia ágil, todos os participantes do projeto, devem estar bem 
informados e prontos para, se necessários, realizar qualquer mudança no sistema. 
Diferentemente das abordagens tradicionais que são pouco propícias às mudanças no decorrer 
do projeto (LEITÃO, 2010). 
Diferentes metodologias ágeis surgiram ao redor desta filosofia de desenvolvimento 
de software, apesar de parecidas, apresentam diferenças no ciclo de desenvolvimento, ou 
artefatos a serem usados, ou até mesmo na forma do desenvolvimento do código. 
 
2.7.2 Abordagens de metodologia ágil 
 
Existem muitas metodologias ágeis que foram surgindo durante os últimos anos, ou às 
vezes sendo adaptações das que já existiam. Algumas são focadas nos procedimentos de 
desenvolvimento, outras já abrangem mais a gestão de projetos. Nas próximas sub-seções, 
serão apresentadas as principais metodologias utilizadas no mercado. 
45 
 
2.7.2.1 Adaptative Software Development (DAS) 
 
O Desenvolvimento Adaptativo de Software (DAS) foi idealizado por Jem Highsmith 
como sendo uma técnica para construção de software complexa. As bases do DAS são a 
colaboração humana e a auto-organização da equipe. Como pode ser visto na Figura 7, o ciclo 
de vida do DAS se divide em três fases: Especulação, Colaboração e Apreendizado 
(PRESSMAN, 2006). 
 
Figura 7 – Ciclo de vida da metodologia DAS. Fonte Adaptada: Pressman (2006). 
 
De acordo com Pressman (2006), as fases têm as seguintes características: 
• Fase de Especulação: Durante esta fase, o projeto é iniciado e o planejamento do 
ciclo adaptativo é conduzido. Neste planejamento, é utilizado informações de 
iniciação do projeto, ou seja, um levamentamentopassado pelo cliente contendo as 
restrições do projeto e requisitos básicos. A partir destes dados, será definido o 
conjunto de ciclos de versão que serão necessários para o projeto. 
• Fase de Colaboração: Os participantes trabalham junto de um modo que multiplica 
seus talentos e resultados criativos, que é uma abordagem colaborativa, presente em 
todas as metodológias ágeis. Esta colaboração não é fácil, pois está além de ter muita 
46 
 
comunicação, ou de se ter uma equipe suficiente de trabalho; acima de tudo é uma 
questão de confiança, onde todos que trabalham colaborativamente têm que ter 
confiança nas outras para: 
� Criticar sem animosidade; 
� Ajudar sem ressentimento; 
� Trabalhar tão duro ou mais duro do que costumam; 
� Ter um conjunto de habilidades para contribuir com o trabalho em mãos; e 
� Comunicar problemas e/ou preocupações de um modo que conduza à ação 
efetiva. 
• Fase de Aprendizado: Conforme os membros de uma equipe DAS começam a 
desenvolver os componentes que fazem parte de um ciclo adaptativo, a ênfase está 
tanto no aprendizado quanto no progresso em direção a um ciclo completo. As equipes 
acabam aprendendo de três modos: 
o Foco no grupo: o cliente/usuário fornecem feedback sobre os incrementos de 
software que são apresentados, avaliando se está satisfatório ou não em relação 
às necessidades do negócio; 
o Revisões técnicas formais: Os integrantes da equipe revisam os componentes 
de software que são desenvolvidos, aperfeiçoando a qualidade e aprendendo à 
medida que continuam o desenvolvimento; e 
o Pós-conclusão: a equipe avalia os seus próprios processos com intenção de 
aprender e depois aperfeiçoar a sua abordagem. 
Ainda de acordo com Pressman (2006), é importante destacar um fator importante 
sobre o DAS: “A ênfase global do DAS na dinâmica de equipes auto-organizadas, na 
colaboração interpessoal, no aprendizado individual e em equipe produz equipes de projeto de 
software com uma probabilidade de sucesso maior”. 
 
2.7.2.2 Crystal 
 
Alistair Cockburn e Jim Highsmith criaram a “família Crystal de métodos ágeis”, que 
consiste de uma serie de metodologias distintas que se adequam às circunstâncias de 
diferentes projetos (COCKBURN, 2002). Para conseguir está flexibilidade, os criadores 
definiram um conjunto de metodologias nos quais os elementos centrais são comuns a todas e, 
47 
 
papéis, padrões de processos, produto de trabalho e práticas específicas são de cada uma 
(PRESSMAN, 2006). 
 Todas as metodologias da familia Crystal se baseam em regras, características e 
valores iguais, tais como os projetos sempre utilizam ciclos de desenvolvimento incremental, 
com um período máximo de quatro meses, que pode estar incorporado de práticas de outras 
metodologias ágeis, como Extreme Programming (XP) e Scrum. Outro valor comum a 
importância na comunicação e cooperação das pessoas durante o processo de 
desenvolvimento, considerado fundamental para a utilização do mesmo (COCKBURN, 
2002). 
 Segundo Cockburn (2002), existem três principais metodologias Crystal construídas: 
Crystal Clear, Crystal Orange e Crystal Orange Web. O Crystal Orange Web é igual ao 
Crystal Orange, mas apenas com algumas práticas específicas para web. A Tabela 4 apresenta 
as principais características de cada modelo (COCKBURN, 2002): 
 
Tabela 4 – Características das Metodologias Crystal. Fonte Adaptada: Cockburn (2002). 
 Crystal Clear Crystal Orange\Crystal 
Orange WEB 
Quantidade de 
Colaboradores 
Máximo até 6 
colaboradores 
De 10 a 40 colaboradores. 
Duração máxima das 
interações 
Entrega incremental de 2 a 
3 meses 
Entrega incremental de 3 a 4 
meses 
Dimensão do projeto Pequenos, onde a equipe 
deve estar localizada em 
espaço físico comum. 
Média dimensão, onde 
projetos podem durar de 1 a 2 
anos, e o projeto é dividido 
por várias equipes com grupos 
multifuncionais. 
 
Segundo Cockburn (2002), a principal vantagem adaptativa dessas metodologias 
acaba sendo o fato de suas normas poderem ser substituídas por práticas equivalentes de 
outras metodologias, como XP ou Scrum. 
 Apesar de possuir “manobrabilidade” em se adequar as necessidades dos projetos, as 
metodologias Crystal acabam possuindo alguns pontos negativos, como as limitações de 
espaço físico e horário de trabalho, devido à necessidade se estabelecer comunicação 
constante (LEITÃO, 2010). 
 
48 
 
2.7.2.3 DSDM (Dynamic Systems Development Method) 
 
O DSDM (Dynamic Systems Development Method) é uma metodologia ágil que 
fornece uma base para o desenvolvimento de software, na criação e na manutenção do 
mesmo, quando existem restrições de prazo, utilizando a prototipagem incremental em um 
ambiente controlado do projeto (PRESSMAN, 2006). 
 De acordo com Teixeira et al. (2005), a DSDM aborda os problemas que 
frequentemente ocorrem no desenvolvimento de software, onde atrasam principalmente 
devido à falta de tempo, com orçamentos mais apertados ou até mesmo falta de envolvimento 
da equipe. 
 A metodologia adota uma filosofia parecida com o princípio de Pareto, onde 80% das 
funcionalidades de uma aplicação podem ser entregue em 20% do tempo que levaria para 
entregar a versão completa (100%). A DSDM segue este conceito de 80%, mas com uma 
modificação, os 20% restantes pode ser finalizado depois, quando mais requisitos forem 
conhecidos ou quando modificações forem solicitadas (PRESSMAN, 2006). 
 De acordo com Teixeira et al. (2005), a DSDM segue alguns princípios chaves, que 
delimitam as bases do desenvolvimento utilizado nesta metodologia: 
o O ponto fundamental desta metodologia prende-se com a entrega de um 
sistema que se aproxime das atuais necessidades de negócio. Não é uma 
metodologia tão direta que forneça todos os requisitos do negócio, mas 
centraliza todo o potencial na concretização final de todos os objetivos do 
projeto; 
o A entrega do projeto deve ser feita na data estipulada, dentro do orçamento 
previsto e com boa qualidade; 
o As exigências para o Sistema de Informação têm que ser flexíveis; 
o Esta metodologia apenas requer que cada etapa do desenvolvimento seja 
completada até que seja possível iniciar o passo seguinte. Isto faz com que 
cada fase do projeto possa começar sem ter que esperar que as fases que 
começaram anteriormente sejam totalmente terminadas; 
o A comunicação entre todas as partes envolvidas (stakeholders) é também um 
pré-requisito importante para que o projeto corra com a eficiência desejada; e 
o As equipes responsáveis têm que possuir um sentido de decisão, pois é um 
ponto crucial na progressão do projeto. 
 
49 
 
Dependendo do projeto, a DSDM pode não ser recomendada, devido as suas 
características apresentadas não se adaptarem a algumas situações: projetos complexos que 
são difíceis de dividir; requisitos pouco claros ou que não possam ser escalonados por uma 
ordem de preferência; quando o sistema final necessita de um estado de segurança-críticas e 
por fim, os projetos que apontam para componentes reutilizáveis podem não ser apropriados 
já que as necessidades de perfeição neste tipo de projetos colidem com o princípio de pacto 
adaptado e descrito anteriormente (TEIXEIRA et al. 2005). 
2.7.2.4 Extreme Programming (XP) 
 
A metodologia Extreme Programming (XP) teve início no final da década de 80, a 
partir de um trabalho pioneiro realizado por Kent Beck (BECK, 1999). Os fundamentos 
iniciais da metodologia, na qual se baseava no desenvolvimento em SmallTalk, são práticas 
como pair programming, refactoring, testes contínuos e um desenvolvimento interativo, 
sendo hoje as bases da metodologia (LEITÃO, 2010). 
Ao longo dos anos, a metodologia evoluiu se adaptando aos diversos tipos de 
problemas encontrados durante o desenvolvimento de modelos tradicionais. Atualmente, XP 
adotou o paradigma orientado à objeto como sua abordagem mais utilizada (BECK, 1999). 
Segundo Beck (2004), a metodologia gera um nivelamento