2013 - 1sem - Alan Delgado Da Silva

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 de
Pequeno/Médio porte. / Alan Delgado da Silva; orientador
Prof. Breno Lisi Romano. São João da Boa Vista, 2013.
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 and small-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 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 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
Capítulo
23
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 apresentando
falhas 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).
Capítulo
27
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, ficando a 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
INDÚSTRIA
EMPRESA 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
RECEITA OPERACIONAL BRUTA ANUAL (ROB)
EMPRESA
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 compromisso dos 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 pode ser 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 levamentamento passado 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 Máximo até 6 De 10 a 40 colaboradores.
Colaboradores colaboradores
Duração máxima das Entrega incremental de 2 a Entrega incremental de 3 a 4

interações 3 meses meses
Dimensão do projeto Pequenos, onde a equipe Média dimensão, onde

deve estar localizada em projetos podem durar de 1 a 2
espaço físico comum. 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 da equipe, evitando uma
característica negativa encontrada nas equipes de desenvolvimento, onde uma única pessoa
acaba detendo conhecimento sobre determinado problema ou solução. Além disto, o XP é
uma metodologia leve, eficiente, adaptativa e feita para equipes de tamanho pequeno e médio.
Também se torna útil em projetos que são baseados em requisitos incompletos ou que
sofrem alterações ao longo de todo o desenvolvimento, o que acaba tranquilizando a equipe,
pois os integrantes acabam aceitando as mudanças como algo natural. Isto torna-se importante
na hora de cumprir com o principal objetivo da metodologia, que é entregar o software com
qualidade e que atenda as expectativas e necessidades do cliente e equipe de desenvolvimento
(LEITÃO, 2010).
Para se utilizar a metodologia XP, deve-se seguir quatro príncipios (BECK, 2004):
• Comunicação: O XP necessita que se tenha uma boa comunicação entre a equipe e os
clientes. Devido à redução de documentação, a comunicação é um dos fatores que
podem ocupar este espaço, sendo item fundamental para o sucesso;
• Simplicidade: Deve-se escolher a alternativa mais simples e que tem uma
probabilidade maior de funcionar, assim evitando complicações futuras;
50
• Feedback: Todas as críticas, soluções ou problemas devem ser comunicadas o quanto

antes para que não aconteçam atrasos; e
• Coragem: Algumas vezes é necessário ter coragem para apontar defeitos no sistema
que já está em produção e realizar alterações, mesmo sendo obrigado a refazer
diversas partes já concluídas. Deve ser comunicado ao cliente sobre a alteração de
prazo de entrega nestes casos.
Para colocar em prática esses valores, a metodologia XP utiliza de algumas práticas,
de forma harmônica e complementar, a fim de desenvolver um software de alta qualidade. As
12 práticas podem ser vistas na Tabela 5, onde são apontados também alguns aspectos
negativos de sua utilização (SAVOINE et al., 2009).
Tabela 5 – Principais Práticas do XP e seus Aspectos Negativos. Fonte Adaptada: Savoine et al. (2009).
12 Práticas do XP Aspectos Negativos
1 Reuniões diárias, quando se tiram dúvidas Não indicada para sistemas complexos, pois a
de requisitos complexas e planejam-se análise não é detalhada
iterações do dia
2 Indicada quando o escopo do projeto não Não indicada para equipes muito grandes, pois
é bem definido: os requisitos não são o escopo tem que ser definido e os membros da
totalmente conhecidos ou muito vagos equipe, geralmente, ficam separados
geograficamente
3 Clientes presentes caracterizam a chave Não indicada em ambientes onde os clientes não
para o sucesso podem estar presentes
4 Possui foco na codificação, sendo a Não possui foco na gerência de projeto, sendo
documentação deixada para segundo os resultados o principal interesse da equipe
plano
5 Flexível a mudanças, encorajando as Não indicada em projetos que o cliente exige
pessoas a enfrentarem-na com extensa documentação de software
naturalidade
6 Tarefas com simplicidade e qualidade, Não indicada em equipes que possuem
funcionalidades realmente úteis ao usuário resistências a práticas como refactoring
7 Iterações curtas, com feedback do usuário Não indicada em projetos em que o cliente não
rápido e constante possa participar integralmente do
desenvolvimento
8 Os testes fazem parte do ciclo de Se o feedback entre o cliente e a equipe não for
desenvolvimento, aumentando assim a constante, ou houver uma demora de respostas
qualidade do software entre às partes e o XP não será produtivo
9 Integração diária do código produzido Quando houver resistência em modificar o

código já concluído, com o objetivo de torná-lo
simples, estruturado
51
10 Código coletivo: todos são responsáveis e Não é recomendada em ambientes de trabalhos

aptos a realizar melhorias exaustivos, a XP enfatiza o trabalho de 8 horas
diárias
11 Padronização do código: evitar problemas Não indicada para projetos que necessitem de
na hora da refatoração e da manutenção ciclos de iterações longos
12 Refatorar: simplificar o código, sem A XP não é uma metodologia flexível em

alterar sua funcionalidade relação as suas práticas, que devem ser seguidas
rigorosamente
Para se utilizar a metodologia XP, deve-se utilizar todas estas práticas, pois elas se
complementam, garantindo o sucesso do desenvolvimento neste processo. Além disto, cada
um destes fatores é aparentemente simples, mas que acabam se tornando de grande valor na
sua interação de uma prática com a outra. Os aspectos negativos acabam servindo como um
alerta para que seja avaliado antes de sua tentativa de adoção (BECK, 2004).
2.7.2.5 FDD (Feature Driven Development)
O FDD (Feature Driven Development – Desenvolvimento Guiado por Características)

foi inicialmente criado por Peter Coad e seus companheiros como um modelo de processo
para a Engenharia de Software voltado para orientação à objetos (COAD, 1999). Este modelo
foi melhorado e transformado em um processo ágil por Stephen Palmer e John Felsing,
buscando atender a projetos de médio à grande porte (PRESSMAN, 2006).
A metodologia fornece alguns benefícios de processos rigorosos, como modelagem,
planejamento prévio e controle do projeto, mas mantém as características de processos ágeis.
O FDD ainda preve relatórios que controlam o estado e o progresso das atividades, apesar de
não ser orientada a documentação como o Rational Unified Process (RUP) (SILVA &
HOENTSCH, 2009).
De acordo com Coad (2009), na metodologia FDD, uma caracteristica é a função
valorizada pelo cliente, que pode ser implementada em até duas semanas. Com isto, surgem
os seguintes benefícios (PRESSMAN, 2006):
• Como as características são pequenos blocos de funcionalidade passíveis de
entrega, os usuários podem descrevê-las mais facilmente, entender como elas
se relacionam umas com as outras mais prontamente e revisá-las melhor
quanto a ambiguidades, erros ou omissões;
52
• As caraterísticas são um incremento de software passível de entrega do FDD e,

consequentemente, a equipe desenvolve características operacionais a cada
duas semanas;
• Como as características são pequenas, suas representações de projeto e de
código são mais fáceis de inspecionar efetivamente; e
• Planejamento de projeto, cronogramação e monitoramento são guiados pela
hierarquia de características em vez de por um conjunto de tarefas de
Engenharia de Software arbitrariamente adotada.
Sendo assim, um conjunto de características é agrupado em categorias relacionadas ao
negócio, sendo definido como pode ser observado na Figura 8 (COAD, 1999):
Figura 8 – Categorias de Características FDD. Fonte Adaptada: Pressman (2006).
O processo “Desenvolver um modelo Global” é responsável pelo estudo detalhado

sobre o domínio do negócio e pela definição do escopo do projeto. Ao avançar para a
categoria seguinte, “Construir uma lista de características”, todas as funcionalidades
necessárias ao cumprimento das necessidades do cliente são levantadas e ordenadas por
prioridade de desenvolvimento no processo “Planejar por características”, considerando
inclusive se a caracteristica é funcional ou não, onde ao final deste processo é gerada uma
lista das classes e estas são associadas aos desenvolvedores responsáveis. Um plano de
projeto também é elaborado pelo arquiteto chefe e aprovado pelo cliente (SILVA &
HOENTSCH, 2009).
Iniciam-se então várias iterações que compreende os dois processos finais. No
processo “Projetar através de características”, cada funcionalidade da lista é definida como
uma atividade a ser realizada. Neste processo, o modelo da interface do usuário é esboçado e
os diagramas de sequência e de classe são gerados. Já no processo “Construir por
53
características”, o código é gerado produzindo-se em cada ciclo de interação para cada

característica definida uma função que agregue valor ao cliente (SILVA & HOENTSCH,
2009).
De acordo com Pressman (2006), o FDD enfatiza mais as diretrizes e técnicas de
gestão de projeto do que muitos outros métodos ágeis. Tanto que quando o prazo for apertado,
todos os processos são cronometrados e verificados durante o desenvolvimento.
2.7.2.6 Scrum
A metodologia ágil Scrum possui a característica de ser empírica, adaptativa e

inovadora, sendo utilizada no desenvolvimento de software de uma forma incremental,
solucionando o problema de mudanças de requisitos durante o projeto. Esta característica
torna a metodologia flexível; ágil e adaptável a qualquer situação (SCHWABER & BEEDLE,
2002).
Segundo Leitão (2010), o Scrum possui um foco no gerenciamento da equipe,
preocupando-se com a organização dos processos; no modo como as atividades devem ser
executadas e onde os integrantes do projeto determinam a melhor maneira de executar as
tarefas do desenvolvimento do sistema.
O Scrum na verdade não é um processo ou técnica de criação, mas sim um framework,
que se podem utilizar vários processos e técnicas. Pode ser usando também por equipes
grandes ou pequenas (SCHWABER & SUTHERLAND, 2011).
No framework Scrum, o desenvolvimento é dividido em interações, chamadas de
Sprints, que podem ter a duração de 2 a 4 semanas. Durante uma Sprint, são realizados
eventos com duração fixa sem poder ser estendido. Este conceito de tempo pré-determinado é
chamado de time-boxes e garante uma regularidade no ciclo de desenvolvimento. A cada fim
de ciclo é entregue um release do software para a avaliação do cliente (LEITÃO, 2010).
2.7.3 Metodologias Ágeis e o Mercado de TI
Nos últimos anos, a metodologia ágil tem despertado interesse nas empresas devido à
vários relatos de aumento de produtividade e qualidade no desenvolvimento de software
(LEITÃO, 2010). Nas próximas seções, será apresentado um pouco mais sobre a realidade nas
empresas que adotam esta prática.
54
2.7.3.1 Aspectos da Implantação em Empresas de TI
Atualmente, a metodologia tem se tornado frequente nos planos das empresas

brasileiras, sendo utilizada em diversos projetos. Decidir por adotar uma metodologia de
desenvolvimento muitas vezes não é tão fácil para as empresas, pois envolvem treinamentos,
mudança de hábitos, organização diferente, entre outras mudanças nas quais algumas
empresas precisam de tempo para se mostrar prontas para realizar o investimento (LEITÃO,
2010).
Neste processo de escolha, sempre é realizado uma pesquisa sobre a quantidade de
empresas que já adotam com sucesso está nova metodologia, observando os prós e os contras
de tal investimento. Por isto é interessante observar estes relatos sobre a utilização destas
metodologias no dia a dia das empresas (LEITÃO, 2010).
Em uma pesquisa científica realizada por Melo et al. (2012), em empresas e
universidades, entre 24 de maio e 31 de agosto de 2011, levantou-se o estado da prática de
métodos ágeis no Brasil. O estudo seguiu o modelo de questionário da VersionOne (2011)
que realizou a mesma pesquisa em nível global. Primeiramente, é importante observar a
quantidade de projetos que adotam atualmente alguma metodologia ágil, como pode ser visto
na Figura 9.
Figura 9 – Percentual de projetos da organização que adotam métodos ágeis. Fonte: Melo et al. (2012)
Estes dados apontam que com um total de 60,7% das empresas brasileiras adotam
métodos ágeis em mais da metade dos seus projetos. Outra informação relevante é que a
porcentagem dos entrevistados que utilizam Scrum como metodologia chega a ser de 51,2%,
seguido de 22,5% que adotam a combinação de Scrum + XP, como é demostrado na Figura
10 (MELO et al., 2012).
55
Segundo Melo et al (2012), a escolha de Scrum acontece por ser uma metodologia
muito difundida, e com muitos casos de sucesso. Algumas empresas adotam conceitos mais
técnicos da metodologia XP, como programação em par, para enriquecer a utilização da
metodologia ágil.
Figura 10 – Qual metodologia ágil é mais utilizada. Fonte: Melo et al. (2012)
O estudo também destaca as razões que motivaram a adoção de métodos ágeis, como
mostra a Figura 11, onde se destaca a expectativa de aumento de produtividade (91%),
gerenciamento de mudanças de prioridade (86%) e aumento da qualidade de software (83%)
(MELO et al., 2012).
Figura 11 – Razão mais importante para a adoção de metodologia ágil. Fonte: Melo et al. (2012).
56
Apesar destas expectativas, também acontecem preocupações em adotar este tipo de

abordagem. Segundo a pesquisa, destaca-se a falta de documentação em alguns casos, falta de
previsibilidade e falta de planejamento em longo prazo, como pode ser observado na Figura
12 (MELO et al., 2012).
Figura 12 – Maiores preocupações da organização na adoção. Fonte: Melo et al. (2012).
Após a adoção de metodologias ágeis nos seus projetos, segundo a pesquisa foi
possível observar quais os benefícios que melhoraram o desenvolvimento de software, que
foram: a Habilidade de Gerenciar mudanças de prioridades (76%), Aumento da produtividade
(76%), Aumento da qualidade (75%), Aumento da moral da equipe (75%) e simplificação do
processo de desenvolvimento (75%).
Foi perguntado também em relação à velocidade dos projetos, que apontaram que
67,1% dos entrevistados indicaram que projetos ágeis terminam mais rápido que projetos
tradicionais (MELO et al., 2012). Estas informações são apresentadas nas Figuras 13 e 14,
respectivamente.
Figura 13 – Percepção sobre a velocidade dos projetos após a adoção de métodos ágeis. Fonte: Melo et al.
(2012).
57
Figura 14 – Benefícios observados após a adoção de metodologias ágeis. Fonte: Melo et al. (2012).
E, por fim, a pesquisa revela quais foram os maiores desafios destas empresas que
adotaram a metodologia ágil, como alguns problemas e dificuldades na hora de implantar a
metodologia em seus projetos. As mais frequentes foram: Falta de experiência com métodos
ágeis (16,3%), Filosofia/Cultura da empresa vai contra aos valores ágeis (12,4%) e Pressão
externa para o projeto seguir os ciclos tradicionais ou cascata de desenvolvimento (10,4%),
como pode ser visto nas Figuras 15 e 16.
Figura 15 – Principais causas de falha em projetos ágeis na organização. Fonte: Melo et al. (2012).
58
Em empresas que a metodologia ágil adotada não conseguiu se estabelecer, foram

apontadas as principais causas; falta de habilidade em mudar a cultura organizacional
(50,7%), disponibilidade de pessoas com as capacidades necessárias (43,3%) e resistência
geral à mudança (41,4%), o mostram que os fatores externos interferem muito na hora da
implantação (MELO et al., 2012).
Figura 16 – Desafios em implantar metodologias ágeis. Fonte: Melo et al. (2012).
2.8 Comparação entre Metodologias: Tradicionais x Ágeis
Realizando-se uma comparação entre os dois tipos de metodologias (tradicionais e

ágeis), é possível observar que a diferença não somente é as práticas que elas utilizam, mas
sim o enfoque e os valores. As metodologias ágeis se diferem das tradicionais principalmente
por serem mais adaptativas, ao invés de prescritivas (LUDVIG & REINERT, 2007).
Além disso, as tradicionais se preocupam muito em definir todo o escopo e requisitos
do projeto antes de começar a desenvolvê-lo. Por outro lado, metodologias ágeis já buscam
melhorar os requisitos durante a própria execução. Se observarmos as duas formas de lidar
com as mudanças de requisitos, através da visão do custo que isto gera, a metodologia ágil é
mais apropriada, pois ela possui avaliações constantes, o que impede que as alterações
necessárias se tornem muito complicadas ou que demandam muito tempo da equipe, como é
mostrado na Figura 17 (CAMARA, 2007).
59
Figura 17 – Diferença de custo de uma mudança de escopo nos projetos ágeis versus tradicionais. Fonte
Adaptada: Camara (2007).
Podemos observar na Figura 17 que uma mudança de escopo de uma funcionalidade

na fase de planejamento custa um esforço de retrabalho em torno de 25% para as duas visões,
porém nas fases mais adiantes a diferença se multiplica, podendo sair o dobro do planejado
(CAMARA, 2007).
Uma outra diferença importante a se destacar é de que as metodologias ágeis são
voltadas às pessoas ao invés de serem prescritivas (FOWLER, 2005). Segundo Ludvig &
Reinert (2007), a comunicação e a conversação são valores básicos das metodologias ágeis,
na qual é forma em que se realiza a troca de informações. As documentações utilizadas são
importantes, mas se deve gastar tempo apenas para as quais serão úteis no decorrer do
processo. Sendo assim, as pessoas acabam se tornando os principais condutores do sucesso
em um projeto (LUDVIG & REINERT, 2007;SOARES, 2004).
Diferentemente das metodologias ágeis, a troca de informação nos métodos
tradicionais deve ser passadas apenas através de especificações detalhadas em documentos,
em que a garantia de qualidade está basicamente em cumprir corretamente todas as etapas do
processo (LUDVIG & REINERT, 2007).
Além disso, podem-se observar algumas diferenças de características, entre as
metodologias ágeis e tradicionais, considerando determinadas situações que ocorrem
diariamente. A Tabela 6 foi adaptada do trabalho de Magalhães et al. (2004) e destaca essas
principais diferenças:
60
Tabela 6 – Comparação entre Tradicional x Àgil. Fonte adaptada: Magalhães et al.( 2004).
Caracteristicas Tradicional Ágil

Definição de Escopo Preditivo (detalhar o que Adaptativo (conhecer o
ainda não é bem conhecido) problema e resolver o crítico
primeiro)
Planejamento do Rígido (seguir especificação Flexível (adaptar-se a
Desenvolvimento predefinida, a qualquer custo) requisitos atuais, que podem
mudar).
Desenvolvimento do Sistema Burocrático (controlar Simplista (fazer algo
sempre, para alcançar objetivo simples de imediato e
planejado) alterar, se necessário)
Direcionamento da Metodologia Orientado a processos (seguí- Orientado a pessoas

los possibilita garantir a (motivadas, comprometidas
qualidade) e produtivas)
Foco da Metodologia Documentação (gera Comunicação (gera

confiança) confiança)
Considera-se como sucesso Entregar o planejado Entregar o desejado
Gerência de Projeto Comando e Controle (voltado Liderança/orientação

para trabalho em massa, ênfase trabalhadores do
no papel do gerente, com forte conhecimento (ênfase na
planejamento e disciplina criatividade, flexibilidade,
fortes) atenção às pessoas)
Equipe de Desenvolvimento Desenvolvedor hábil (com Desenvolvedor ágil (com
conhecimentos técnicos rapidez nas respostas as
aprofundados) solicitações dos clientes)
Perfil de cliente Cliente pouco envolvido Cliente comprometido
(autonomia)
Custo de Caro (Por envolver muitas Barato (As mudanças
Retrabalho/Reestruturação etapas para se realizar ocorrem naturalmente)
mudanças)
Planejamento vs. Resultados Planejamento direciona os Resultado direciona o
resultados (incentiva a planejamento (incentiva a
controlar). mudar)
Valorização dos Resultados Premia a garantia da Premia o valor rápido
qualidade obtido
Natureza do Projeto Foco em projetos com Foco em equipes pequenas
restrições de confiabilidade, e médias (exigem maior
planej. estratégico/ adaptação)
priorização.
(exigem mais formalismo)
Objetivo da Metodologia Controlar, possibilitando Simplificar processo de

alcançar o objetivo desenvolvimento
planejado (tempo, orçamento, (minimizando e dinamizando
escopo) tarefas e artefatos)
61
De acordo com Ludvig & Reinert (2007), os métodos tradicionais devem ser
utilizados quando os requisitos do sistema são estáveis e mudanças futuras são previsíveis. Já
as metodologias ágeis devem ser utilizadas, quando não se conhece ao certo todo o escopo do
projeto, permitindo assim que o software evolua no decorrer do desenvolvimento.
Na próxima seção será apresentada, com mais detalhes, a metodologia ágil Scrum que
foi escolhida como base do estudo de caso deste trabalho.
2.9 Metodologia Ágil Scrum
O objetivo desta seção é apresentar um estudo sobre a metodologia ágil Scrum,

mostrando o seu framework, seus papéis, ciclo de desenvolvimento, ferramentas e sua
utilização em conjunto com o Kanban.
A escolha da metodologia ocorreu, principalmente, pelo estudo de caso ser um projeto
que se encaixa no projeto ideal de uma metodologia ágil, em que não se possui uma definição
completa do escopo, podendo ocorrer mudanças nos requisistos durante o projeto (LUDVIG
& REINERT, 2007).
2.9.1 Origens e Conceitos
A metodologia ágil Scrum teve origem como um estilo de gerenciamento de projetos

em empresas de fabricação de automóveis e produtos de consumo, como é relatado no estudo
de caso do artigo de Takeuchi e Nonaka (1986), “The New Product Development Game”.
Nele, é demonstrado o processo de desenvolvimento adaptativo, rápido e auto-organizado,
utilizando equipes pequenas e multidisciplinares.
A partir da experiência executada por Takeuchi e Nonaka (1986), Jeff Sutherland, Ken
Schwaber, John Scumniotales e Jeff McKenna, no início dos anos 90, fizeram semelhante um
trabalho na empresa Easel Corporation, utilizando pela primeira vez o nome Scrum (LEITÃO,
2010).
A origem do nome “Scrum” surgiu justamente na associação que fizeram com uma
formação do rugby, um esporte coletivo originário da Inglaterra. O Scrum ou formação
ordenada, é uma situação frequente no rugby e ,geralmente, é usado após uma jogada
irregular ou em alguma penalização. O nome na metodologia foi introduzido para definir
práticas adaptativas utilizadas em times auto-gerenciáveis (SCHWABER, 2004).
62
Em 1995, Jeff Sutherland e Ken Schwaber juntaram-se para formalizar, refinar e

implantar a metodologia Scrum, produzindo o artigo “The Scrum Development Process”, se
tornando a primeira referência sobre a metodologia ágil de desenvolvimento. Em 2001, Ken
Schwaber e Mike Beedle descreveram a metodologia no primeiro livro sobre Scrum, “Agile
Software Development with Scrum” e em 2004 foi lançada uma nova apresentação sobre a
metodologia, escrita por Schwaber (SCHWABER, 2004; SCHWABER & BEEDLE, 2002).
De acordo com Schwaber e Sutherland (2011), a definição da metodologia é: “Um
framework em que pessoas podem tratar e resolver problemas complexos e adaptativos,
enquanto que produtiva e criativamente entregam produtos com o mais alto valor possível”.
O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar as
previsões do controle dos riscos, além de ser fundamentado nas teorias empíricas de controle
de processo, onde a tomada de decisões são baseadas na experiência da equipe (SCHWABER
& SUTHERLAND, 2011).
A metodologia se apoia em três pilares: transparência, inspeção e adaptação
(SCHWABER & SUTHERLAND, 2011):
• Transparência: Aspectos significativos do processo e do projeto devem estar

visíveis para os responsáveis pelos resultados;
• Inspeção: Aspectos do processo devem ser inspecionados com uma frequência
suficiente para que variações inaceitáveis no processo possam ser detectadas; e
• Adaptação: Sempre que um desvio não desejado ocorra, deve-se adaptar o que
for necessário para que não volte a ocorrer.
Da mesma forma, o framework Scrum possui ferramentas, artefatos e procedimentos

para cumprir com estes três pilares. Nas seções a seguir, serão apresentados cada parte do
framework Scrum.
2.9.2 Framework
O framework Scrum foi criado para suportar o desenvolvimento e a manutenção de

projetos complexos (SCHWABER & SUTHERLAND, 2011). Ele é constituido de equipes,
com seus papéis e responsabilidades; além dos eventos, artefatos e regras, nas quais serão
detalhadas nesta seção.
63
2.9.2.1 Papéis e Responsabilidades
O time Scrum possui três papéis importantes: Scrum Master, Product Owner e a
equipe de desenvolvimento, sendo auto-organizáveis e multi-funcionais. No Scrum, existem
dois tipos de pessoas na equipe, os envolvidos e os comprometidos. Onde os comprometidos
tem a responsabilidade direta no projeto sendo responsáveis pelo mesmo (Scrum Master,
Product Owner e a equipe de desenvolvimento), já os envolvidos são pessoas que auxiliam a
equipe em algum ponto, mas não tem responsabilidade de entregar o software pronto
(Diretoria, clientes, e etc.) (SCHWABER & SUTHERLAND, 2011). Sobre os papéis do time
Scrum:
• Product Owner
É o membro responsável por definir as características do produto e a prioridade da

execução de cada um dos requisitos, maximizando o valor do produto e o trabalho da equipe
de desenvolvimento. Na maioria das vezes, o Product Owner (Dono do produto) é um
representante do cliente que possui muito conhecimento sobre o negócio, ajudando assim a
equipe de desenvolvimento a compreender mais sobre o software a ser feito (SCHWABER &
SUTHERLAND, 2011).
De acordo com Schwaber e Sutherland (2011), o Product Owner é a única pessoa que
pode administrar o Product Backlog, que seriam de acordo com a metodologia, os requisitos a
serem desenvolvidos. Sendo assim, o gerenciamento do Product Backlog inclui cinco
responsabilidades importantes apresentados na Tabela 7.
Tabela 7 - Responsabilidades do Product Owner em relação ao Backlog do Produto. Fonte Adaptada: Schwaber
e Sutherland (2011).
Responsabilidades do Product Owner em relação ao Product Backlog
1 Expressar claramente os itens do Product Backlog
2 Ordenar os itens do Product Backlog para alcançar melhor as metas e missões
3 Garantir o valor do trabalho realizado pelo Equipe de Desenvolvimento

4 Garantir que o Product Backlog seja visível, transparente, claro para todos e mostrar o que
o Time Scrum vai trabalhar a seguir
5 Garantir que a Equipe de Desenvolvimento entenda os itens do Product Backlog no nível

necessário
64
O Product Owner tem que ser apenas uma pessoa, e não um grupo, onde apesar de
poder ser auxiliado por várias pessoas externas, ele é o único que pode tomar as decisões.
Apenas o Product Owner pode passar para a equipe de desenvolvimento o que deve ser feito,
mas não pode ordenar como deve ser feito que, no caso, é responsabilidade da própria equipe
(SCHWABER & SUTHERLAND, 2011).
• Equipe de Desenvolvimento
A equipe de desenvolvimento são os profissionais que realizam o trabalho de

desenvolvimento do software, sendo todos responsáveis por atingir juntos os objetivos de
entregar uma versão funcional, ao final de cada interação. É uma equipe auto-organizada,
composta de 3 à 9 pessoas, em que a organização é feita de forma participativa, auto-
gerenciada e multifuncional (SCHWABER, 2004).
De acordo com Schwaber e Sutherland (2011), as equipes de desenvolvimento
possuem cinco características importantes, que a definem. A Tabela 8 apresenta estas
características.
Tabela 8 - Características da Equipe de Desenvolvimento. Fonte: Schwaber e Sutherland (2011)
Características da Equipe de Desenvolvimento
1 A equipe é auto-organizada. Ninguém diz a Equipe de Desenvolvimento como

transformar os requisitos em incrementos de funcionalidades potencialmente
utilizáveis
2 Equipes de Desenvolvimento são multifuncionais, possuindo todas as habilidades
necessárias para criar o incremento do produto
3 O Scrum não reconhece títulos para os integrantes da Equipe de

Desenvolvimento que não seja de Desenvolvedor, independentemente do
trabalho realizado pela pessoa
4 Individualmente, os integrantes da Equipe de Desenvolvimento podem ter

habilidades especializadas, mas a responsabilidade pertence à Equipe de
Desenvolvimento como um todo
5 Equipes de Desenvolvimento não prevê sub-equipes dedicadas a domínios

específicos de conhecimento, tais como teste ou análise de negócios.
65
É importante observar que os membros desta equipe de desenvolvimento têm

determinadas obrigações durante o desenvolvimento do projeto, como pode ser visto abaixo
(SCHWABER, 2004):
o Todos tem que ter conhecimento sobre o Scrum: regras, papéis, cerimônias e
artefatos;
o Tem que haver colaboração entre si;
o Atuar com transparência, buscando sempre entregar o máximo de valor ao
negocio;
o Trabalhar com qualidade e produtividade;
o Apoiar o Product Owner; e
o Possuir uma auto-organização.
De acordo com Schwaber e Sutherland (2011), a composição do time pode acabar
mudando ao final da Sprint, mas é algo que tem que ser evitado, pois a produtividade ganha
através da auto-organização é reduzida.
• Scrum Master
O Scrum Master é um facilitador e um mediador da equipe, servindo de escudo contra

as interferências externas, sendo responsável por garantir que o Scrum seja aplicado e
entendido. É responsável também por garantir que a equipe trabalhe de forma produtiva,
removendo as interrupções. O Scrum Master acaba se tornando um lider e, ao mesmo tempo,
um servo para o Time Scrum (SCHWABER & SUTHERLAND, 2011).
Como o Scrum Master acaba se relacionando com todas as pessoas da equipe, ele
possui responsabilidades e deveres para cada papel do Time Scrum. Primeiramente, o Scrum
Master auxilia o Product Owner com as seguintes ações (SCHWABER & SUTHERLAND,
2011):
o Encontrar técnicas para o gerenciamento efetivo do Product Backlog;
o Claramente comunicar a visão, objetivo e itens do Product Backlog para a
Equipe de Desenvolvimento;
o Ensinar a Time Scrum a criar itens de Product Backlog de forma clara e
concisa;
o Compreender a longo-prazo o planejamento do Produto no ambiente empírico;
o Compreender e praticar a agilidade; e
o Facilitar os eventos Scrum conforme exigidos ou necessários.
66
Já em relação à equipe de desenvolvimento, o Scrum Master como facilitador e

protetor, deve auxiliar de outras formas (SCHWABER & SUTHERLAND, 2011):
o Treinar a Equipe de Desenvolvimento em auto-gerenciamento e
interdisciplinaridade;
o Ensinar e liderar a Equipe de Desenvolvimento na criação de produtos de alto
valor;
o Remover impedimentos para o progresso da Equipe de Desenvolvimento;
o Facilitar os eventos Scrum conforme exigidos ou necessários; e
o Treinar a Equipe de Desenvolvimento em ambientes organizacionais nos quais
o Scrum não é totalmente adotado e compreendido.
Por fim, o Scrum Master tem responsabilidades e deveres junto à organização em que
vêm sendo desenvolvido o projeto (SCHWABER & SUTHERLAND, 2011):
o Liderando e treinando a organização na adoção do Scrum;
o Planejando implementações Scrum dentro da organização;
o Ajudando funcionários e partes interessadas a compreender e tornar aplicável o
Scrum e o desenvolvimento de produto empírico;
o Causando mudanças que aumentam a produtividade do Time Scrum; e
o Trabalhando com outro Scrum Master para aumentar a eficácia da aplicação do
Scrum nas organizações.
Apesar da forma de atuação parecer com a figura de Gerente de Projetos dos métodos
tradicionais, o Scrum Master trabalha para a equipe, auxiliando no que ela precisar. Por outro
no método tradicional, a equipe trabalha para o gerente de projetos, pois ele estabelece as
tarefas e a equipe deve executar.
2.9.2.2 Time-boxes
Na metodologia ágil Scrum, é utilizado o conceito de time-boxes (caixas de tempo),

que corresponde ao fato de cada um dos eventos tem uma duração máxima, garantindo que
uma quantidade correta de tempo seja gasta no planejamento, sem deixar que ocorra
desperdício com discussões fora do contexto (SCHWABER & SUTHERLAND, 2011).
Os eventos do Scrum considerados time-boxed são: Release Planning Meeting, Sprint
Planning Meeting, Daily Scrum Meeting, Sprint Review e Sprint Retrospective (LEITÃO,
2010).
67
Durante o desenvovimento utilizando a metodologia ágil, é de extrema importância

que se siga o conceito de time-boxed a risca, não deixando que as reuniões ultrapassem os
períodos estipulados ou aumento de prazo para entrega de uma Sprint, pois isto causa
desorganização e perda de ritmo nas interações (LEITÃO, 2010). Em seguida, será abordado
um pouco mais sobre o ciclo de desenvolvimento e o uso dos eventos time-boxed, assim como
seus artefatos.
2.9.2.3 Ciclo de desenvolvimento
O ciclo de desenvolvimento do Scrum é de 2 a 4 semanas, que são chamadas de

Sprints, com o objetivo de desenvolver e entregar um produto ao fim de cada ciclo. Uma
sprint inicia logo que outra acabar (SCHWABER & SUTHERLAND, 2011).
O ciclo tem início a partir de uma visão do produto, que é uma pequena especificação
sobre o que se trata o software a ser desenvolvido. Depois é criado o Product Backlog, que
contém características (requisitos) definidas pelo Product Owner. A equipe de
desenvolvimento se reúne com o Product Owner antes de dar início na Sprint, organizando
quais são as prioridades do trabalho a ser feito. Além disto, a equipe define as tarefas a serem
feitas para cumprir com os determinados requisitos, chamada de Sprint Backlog. Na Figura 18
pode-se ver, de forma resumida, o ciclo de desenvolvimento do Scrum (LEITÃO, 2010).
Figura 18 – Ciclo de Desenvolvimento Scrum. Fonte Adaptada: Brandini (2011)

68
Durante a realização da Sprint, a equipe tem que realizar reuniões diárias de

aproximadamente 15 minutos, no mesmo local de trabalho e horário de preferência. Estas
reuniões são chamadas de Daily Scrum Meeting e possuem como objetivo acompanhar o
andamento do projeto. No final da Sprint, é realizado uma reunião de revisão chamada de
Sprint Review Meeting, no qual é mostrado o que foi desenvolvido durante a Sprint. Por
último, é feito uma reunião apenas entre a equipe e o Scrum Master, onde é revisto o processo
e verificado se aconteceu alguma falha, discutindo possíveis melhorias para as próximas
Sprints (LEITÃO, 2010).
2.9.2.4 Eventos da Sprint
Como citado anteriormente, a Sprint possui alguns eventos importantes durante cada
ciclo de desenvolvimento, que são (SCHWABER, 2004):
• Release Planning Meeting: É uma reunião onde a equipe de desenvolvimento analisa
quais as funcionalidades que serão desenvolvidas na próxima Sprint. Para isto, o
Product Owner apresenta os itens do product backlog, explicando cada um deles e
definindo junto com a equipe quais deverão ser desenvolvidos. O Scrum Master deve
ajudar a organizar a reunião para que se tenha o melhor aproveitamento possível. O
Time Scrum define a meta da Sprint, que seria um objetivo a ser atingido, com a
conclusão da Sprint (SCHWABER & SUTHERLAND, 2011);
• Sprint Planning Meeting: Logo após a reunião de Release Planning Meeting, ocorre
uma reunião entre a equipe de desenvolvimento e o Scrum Master para definir como
será cumprido o objetivo da Sprint. Neste momento, a equipe define as tarefas a serem
feitas, estimando o tempo de cada uma, criando um plano para a entrega. Pode-se
utilizar uma técnica de estimativa chamada Planning Poker para determinar o tempo
para o desenvolvimento (Kniberg, 2007). Os itens de Backlog do produto que foram
selecionados para a Sprint, junto com o plano de entrega destes itens são chamados de
Sprint Backlog. O Product Owner pode estar presente apenas para tirar dúvidas, mas
não pode interferir no planejamento da equipe (SCHWABER & SUTHERLAND,
2011);
• Daily Scrum Meeting: Durante toda a Sprint, é realizado uma reunião diária para que
todos da equipe acompanhem o andamento da Sprint. Apenas a equipe de
69
desenvolvimento e o Scrum Master participam e deve durar 15 minutos no máximo,

iniciando sempre no mesmo horário. O ideal é que está reunião seja feita em pé, na
frente de um quadro com as tarefas e um gráfico, que mostra a quantidade de tarefas já
cumpridas e as que restam ainda, chamado de Burndown. Nesta reunião, cada
participante deve responder três perguntas: “O que você fez desde a última reunião
diária?”, “O que vai fazer até a próxima reunião diária?” e “Existe algum
impedimento?”. Está reunião fortifica os laços de união da equipe, identificando e
removendo impedimentos para o desenvolvimento e promovem rápidas tomadas de
decisão (SCHWABER, 2004);
• Sprint Review: Ao final da Sprint é realizada uma revisão do que foi desenvolvido
durante a Sprint, apresentando para o Product Owner todas as funcionalidades
finalizadas. Deve-se destacar também o que não foi feito, e estas funcionalidades
devem ser desenvolvidas na próxima Sprint. Neste momento, é verificado se o
objetivo da Sprint foi atingido. O tempo combinado para realizar esta reunião não
pode ser ultrapassado, responsabilidade do Scrum Master fiscalizar esta questão. O
Product Owner pode ter que fazer adaptações no Product Backlog, conforme forem
surgindo novas funcionalidades ou melhorias a serem feitas (SCHWABER &
SUTHERLAND, 2011); e
• Sprint Retrospective: Para encerrar a Sprint, apenas a equipe de desenvolvimento e o
Scrum Master se reúne para discutir como foi à execução da Sprint em relação ao
processo de desenvolvimento. A fim de torná-lo mais eficaz para a próxima Sprint
(SCHWABER, 2004).
2.9.2.5 Artefatos e Ferramentas
Como citado anteriormente, durante a execução da Sprint são utilizado alguns

artefatos do Scrum: o Product Backlog, Sprint Backlog, o gráfico Burndown e a técnica
Planning Poker:
• Product Backlog: É uma lista ordenada de tudo aquilo que é necessário no produto,
podendo ser requisitos funcionais ou não. Qualquer item que seja necessário ser
desenvolvida no produto deve estar no Product Backlog. Apenas o Product Owner
pode realizar inclusões, alterações e ordenação nesta lista. Ela deve estar sempre
70
disponível a todos do time Scrum, aplicando o valor da transparência. Um Product

Backlog nunca está completo, ele é incrementado durante o desenvolvimento do
projeto, devido aos novos requisitos ou exclusão de alguns desnecessários
(SCHWABER & SUTHERLAND, 2011);
• Sprint Backlog: É o conjunto de itens que foram selecionados do Product Backlog,
em conjunto com as tarefas necessárias para desenvolvê-los e entregá-los prontos e
potencialmente funcionais. É um artefato utilizado na Sprint Planning Meeting,
sendo que tudo o que a equipe de desenvolvimento deve realizar na Sprint, tem que
estar no Sprint Backlog. Conforme as tarefas são realizadas e o desenvolvimento é
realizado, novas tarefas podem ser identificadas, e outras tarefas podem deixar de
fazer sentido sendo canceladas. Pode ocorrer de algumas precisar de ajustes para
continuar a serem válidas. Somente a equipe de desenvolvimento pode alterar o
Sprint Backlog durante uma Sprint (SCHWABER & SUTHERLAND, 2011);
• Planning Poker: Está técnica não é nativa do Scrum, mas é muito utilizado no seu
processo de estimativa. Deve-se utilizar cartas de baralho que somente são mostradas
após a descrição de atividade a ser executada na Sprint Planning Meeting.
Os valores das cartas seguem a sequência Fibonacci, visando determinar a
complexidade e do tempo em horas para que seja desenvolvida cada tarefa. Todos os
participantes devem escolher a quantidade de horas para fazer uma determinada
tarefa ou complexidade, representadas nas cartas e mostrar todos ao mesmo tempo.
Quando há consenso de todos, a nota é validada e atribuída à tarefa.
No caso de divergência se abre espaço para discussão de toda a equipe e,
depois de refletirem mais detalhadamente sobre os argumentos de cada um dos
participantes, cada membro escolhe novamente e volta a mostrar uma carta. Caso não
houvesse ainda consenso, o Scrum Master tem a responsabilidade de intervir para
determinar qual será nota será atribuida a tarefa (LEITÃO, 2010; KNIBERG, 2007);
e
• Gráfico Burndown: Uma ferramenta muito útil para um desenvolvimento ágil é o
gráfico Burndown, que contribui para a visibilidade do progresso da equipe,
mostrando quanto tempo e trabalho ainda restam para terminar os objetivos da
Sprint. Para gerar o gráfico Burndown, é necessário ter os resultados da estimativa
utilizando o Planning Poker, onde o valor inicial do eixo vertical é exatamente a
soma de todas as horas que foram estimadas para o desenvolvimento das tarefas.
71
O gráfico possui uma reta de tendência, estável, utilizada para usar como
referência, e uma reta verdadeira que representa o trabalho que falta ser realizado em
horas estimadas. Está última decresce conforme as tarefas forem sendo cumpridas, ao
longo da Sprint. O decrecimo só pode ocorrer quando a tarefa estiver sido
considerada como finalizada pela equipe (SCHWABER, 2004). Um exemplo deste
gráfico pode ser visto na Figura 19.
A responsabilidade pela criação e atualização do gráfico burndown é da equipe
de desenvolvimento, onde devem ser realizados todos os dias antes que o ocorra a
reunião Daily Scrum Meeting.
Figura 19 – Exemplo de Gráfico Burndown. Fonte: Cruz (2013).
2.9.3 Scrum + Kanban
Uma associação frequente encontrada no mercado é a junção da metodologia ágil

Scrum com a técnica Kanban (MELO et al., 2012). Foi desenvolvida pela empresa Toyota
para acompanhar o andamento da produção. O Kanban foi adaptado para o desenvolvimento
de software com foco consistente no contexto e acaba oferecendo uma abordagem menos
prescritiva, comparada ao Agile. Por isto, o Kanban é popularmente utilizado em conjunto
com metodologias ágeis Scrum e XP.
A tradução da palavra japonesa “Kanban” significa “Cartão visual” e foi utilizada para
descrever o sistema que vem sendo utilizado há décadas pela Toyota, para visualmente
72
controlar e equilibrar a linha de produção, e que vem se tornando um termo quase sinônimo
da implementação dos princípios Lean (BOEG, 2012).
Os princípios de Lean é basicamente realizar um processo que consiga a obteção de
materiais corretos, no local correto, na quantidade certa, minimizando o desperdício, sendo
flexível e aberto a mudanças durante o processo (LEAN, 2013).
Segundo Boeg (2012), o Kanban é um método de gestão de mudanças que dá ênfase
aos seguites princípios:
• Visualizar o trabalho em andamento;
• Visualizar cada passo em sua cadeia de valor, do conceito geral até software
que se possa lançar;
• Limitar o Trabalho em Progresso (WIP – Work in Progress), restringindo o
total de trabalho permitido para cada estágio;
• Tornar explicitas as políticas sendo seguidas; e
• Medir e gerenciar o fluxo, para poder tomar decisões bem embasadas, além de
visualizar as consequências dessas decisões.
Para se ter uma idéia dos conceitos fundamentais, na Figura 20 é apresentado um
exemplo de um quadro Kanban. O formato do quadro pode variar, conforme a cultura da
empresa, onde cada uma adota o seu limite de WIP e as etapas de desenvolvimento.
Figura 20 – Exemplo de quadro Kanban. Fonte: Kniberg e Skarin (2009).
O conteúdo do cartão pode variar conforme quem a utiliza, geralmente é utilizado as

User Stories contendo o item a ser desenvolvido. O Kanban utiliza um sistema de puxada de
tarefas, criando um fluxo de evolução pelas etapas.
73
Como pode ser visto na Figura 20, as tarefas seguem o fluxo da esquerda para direita,
onde inicialmente ficam na coluna “A Fazer” empilhadas de acordo com sua prioridade.
Quando algum dos desenvolvedores escolherem esta tarefa para ser trabalhada, ele coloca na
coluna de “Desenvolvimento”. Depois de feito, é colocado na coluna de “Teste”, onde é
testado por outro desenvolvedor. Quando aprovado é colocado na coluna de “Release” para
ser adicionado ao projeto final. Ao fim deste processo, é adicionado na coluna de “Feito!”
concluindo assim a tarefa (KNIBERG & SKARIN, 2009).
Segundo Kniberg e Skarin (2009), o Kanban coloca limites explícitos para quantos
itens podem estar em progresso em cada estado do fluxo de trabalho. Tambem é adicionado
uma anotação de duração da tarefa no cartão, possuindo início e fim.
De acordo com Boeg (2012), o foco do Kanban é conduzir mudanças evolucionárias e,
estes passos simples, têm-se provado extremamente úteis para esse objetivo. A vantagem de
utilizar o Kanban é que se visualizar o fluxo e estabelecer os limites de WIP garantindo que
nunca se pode introduzir mais trabalho no sistema do que a capacidade de processar o
trabalho.
Ainda de acordo com Boeg (2012), alguns autores acabam chamando este sistema
como “Sistema Puxado Kanban” (Kanban Pull System), pois as funcionalidades acabam
sendo “puxadas” pelo sistema, com base na capacidade deste, em vez de empurradas com
base em previsões ou demandas. O desenvolvimento do sistema inicia com a criação das
funcionalidades com maior prioridade, e conforme forem sendo entregue, a equipe irá
desenvolver as outras funcionalidades que ficaram em espera, até que o sistema seja
completado.
O Kanban, junto com a metodologia Scrum, é útil para apresentar o processo de
desenvolvimento da Sprint, acompanhando a execução das tarefas. As reuniões diárias
também devem ser feitas, de preferência, na frente do quadro Kanban, possibilitando a
visualização do fluxo de trabalho (KNIBERG & SKARIN, 2009).
Capítulo
75
3 Metodologia
Neste capítulo será apresentado a implantação da metodologia ágil Scrum em

conjunto com outras técnicas como Kanban, gráfico Burndown e Planning Poker, em uma
empresa de pequeno porte. Definiu-se a metodologia ágil Scrum como a solução a ser
implantada, principalmente por atender as exigências de simplicidade e rápida
aplicabilidade, de modo que a equipe não necessitará alterar muito suas práticas de
desenvolvimento por estar utilizando a metodologia, e sim buscando apenas se adaptar as
características simples da metodologia, buscando assim organização e padronização.
A utilização do Kanban se justifica pela necessidade da empresa em realizar um
controle sobre as tarefas executas, onde será possível observar o andamento do projeto de
uma forma visível para todos. E o uso do Planning Poker e gráfico Burndown para realizar a
estimativa e acompanhamento de tarefas finalizadas, respectivamente.
Primeiramente, é apresentada a sua situação anterior da implantação, sua equipe e seu
processo de desenvolvimento. Posteriormente, é apresentado o planejamento realizado para
a implantação da metodologia. Por fim, é relatado como foi o primeiro projeto utilizando a
metodologia ágil Scrum em conjunto com outras técnicas na empresa.
3.1 Estudo de Caso: Caracterização da Empresa SIMPLISS
Para identificar a eficência da metodologia ágil em empresas de pequeno porte, foi

escolhida uma empresa de desenvolvimento para ser utilizada como estudo de caso. Nas
próximas seções, serão detalhados: o contexto anterior à implantação da metodologia, seu
processo de desenvolvimento e a equipe disponível para o estudo de caso.
3.1.1 A Empresa e o Ramo de Atuação
Utilizando a classificação do SEBRAE, conforme a seção 2.2, foi escolhida uma

empresa de pequeno porte denominada SIMPLISS – Sistemas de Informação LTDA. A
empresa iniciou as suas atividades em 2006, com o objetivo de desenvolver soluções e
76
oferecer serviços para a administração pública, visando levar aos seus clientes eficácia e
simplicidade na arrecadação de impostos (SIMPLISS, 2013).
Com sua sede situada na cidade de São João da Boa Vista - SP e com representantes
comerciais em diversas partes do estado, atende mais de 40 municípios dos estados de São
Paulo, Minas Gerais, Santa Catarina, Paraná e Goiás. Possui atualmente, os software:
ISSQN (Imposto Sobre Serviço de Qualquer Natureza), o sistema de NFS-e (Nota Fiscal de
Serviços Eletrônica) e DIPAM (Declaração para o Índice de Participação dos Municípios).
A SIMPLISS oferece também assessoria técnica, tributária e consultoria aos
municípios, contando com funcionários e colaboradores com experiência na área de
administração pública e de arrecadação de impostos, possuindo mais de 1000 horas de
treinamento e capacitação de fiscais em diversos municípios.
A Figura 21 apresenta um organograma da empresa SIMPLISS, com seus setores e
suas principais atividades.
Figura 21 - Organograma da Empresa
A diretoria gerencia todos os setores, de forma centralizada, sendo responsável pela

elaboração de novas ideias de produtos para serem desenvolvidos.
O Setor administrativo tem a responsabilidade de cuidar do financeiro da empresa, do
marketing dos produtos, dos recursos humanos e de tarefas administrativas, onde atualmente
conta com duas pessoas para executar estas tarefas.
77
O Setor de suporte é dividido em duas partes: suporte ao contribuinte e suporte à

prefeitura. Esta divisão é necessária, pois cada produto possui duas versões diferentes, uma
para os contribuintes do município e outra para a prefeitura administrar as informações
tributárias. O número de funcionários deste setor varia de tempos em tempos, mas
geralmente possui entre 3 e 4 funcionários para atender a todos os clientes.
O setor de desenvolvimento é responsável por desenvolver produtos novos, realizando
todo o planejamento e análise, assim como o realizar a manutenção dos sistemas já
existentes.
O setor de gestão de clientes atua realizando visitas aos clientes, no caso as
prefeituras, para verificar se os sistemas estão atendendo as necessidades, e se é necessário
realizar modificações ou agregar funcionalidades ao software. É responsável também por
realizar treinamentos e consultorias tributárias.
Finalmente, a área comercial da empresa busca realizar a venda de novos contratos,
além de buscar novas licitações para concorrer com algum produto da empresa. Conta com
uma subárea jurídica, que revisa todas as documetações antes e depois do fechamento de
novos contratos.
Atualmente, a empresa está em rápida expansão e busca melhorar seus processos de
suporte aos clientes e desenvolvimento de seus produtos, o que a torna favorável a sua escolha
como estudo de caso para a implantação de uma metodologia ágil.
3.1.2 Setor de Desenvolvimento
A equipe de desenvolvimento é formada por cinco desenvolvedores coordenados por

um diretor de tecnologia. Os desenvolvedores executam as modificações ou
desenvolvimentos, a partir das solicitações que foram passadas pelo suporte técnico, pela
equipe de consultoria ou pela direção. A Figura 22 mostra o fluxo de trabalho entre os setores
de desenvolvimento com os demais.
Todos tem que dividir seu tempo de desenvolvimento de novas funcionalidades, com
plantões de correção de falhas nos sistemas, frutos de um levantamento de requisitos falho ou
planejamento precário. Esta necessidade de se dar manutenção fez com que os
desenvolvedores se tornassem sobrecarregados com tantas tarefas a serem feitas
simultaneamente, prejudicando a concentração e foco, além do nível de stress se tornar maior.
78
Figura 22 – Fluxo de Trabalho em relação ao setor de desenvolvimento
Outra característica que também é encontrada em outras empresas do mesmo porte é

que cada membro da equipe de desenvolvimento acaba tornando-se o expert de uma parte do
sistema, tornando-se o especialista e, por consequência, só ele consegue realizar a
manutenção nestas funcionalidades (PEREIRA et al. 2010). A falta de uma documentação
mínima colabora para que esta situação se torne crítica e perigosa.
Se por algum motivo a empresa não puder contar com aquele profissional, partes dos
sistemas ficarão sem ter alguém para realizar a manutenção ou terá que gastar um bom tempo
para que outra pessoa entenda a funcionalidade e possa ter condições de realizar estas
alterações. Diversos casos já foram vivenciados pela empresa, nos quais acabaram gerando
um prejuízo financeiro e atrasos ainda maiores.
Devido ao crescimento da empresa, esta realidade está mudando, com a diretoria
trabalhando para que o desenvolvimento de novos projetos não sofram os mesmos erros do
passado.
Em relação as tecnologias utilizadas na empresa SIMPLISS, elas são todas voltadas
para o desenvolvimento web utilizando o ASP.NET Web Forms (WEB-FORMS, 2013) e a
linguagem C# (CSHARP, 2013). Todos os desenvolvedores utilizam o Visual Studio Express
2008 (EXPRESS, 2013). A empresa trabalha com diversos sistemas de gerenciamento de
banco de dados, sendo os principais: o Microsoft SQL Server (SQLSERVER, 2013),
79
PostgreSQL (POSTGRESQL, 2013) e Oracle (ORACLE, 2013). Atualmente, não existe

nenhuma ferramenta específica para testes.
Nos novos projetos, a empresa está investindo para utilizar o ASP.NET MVC (MVC,
2013) e a ferramenta Visual Studio Express 2012 (EXPRESS, 2013), mas mantendo o
desenvolvimento com a linguagem C# (CSHARP, 2013). Inclusive este projeto em que será
realizado o estudo de caso utilizará está nova tecnologia.
3.1.3 Processo de Desenvolvimento Existente
A empresa escolhida demostra claramente as mesmas dificuldades de

desenvolvimento de software relatadas na seção 2.3 deste trabalho, por se tratar de uma
empresa de pequeno porte. O processo de desenvolvimento anterior à implantação da
metodologia ágil era considerado falho em diversos pontos. Primeiramente, não existia um
controle sobre os custos, tempo gasto ou prazos de entregas. Sem estas informações, a
diretoria não conseguia tomar ações com precisão, pois não tinha como prever exatamente o
que iria ocorrer durante o desenvolvimento.
O processo de desenvolvimento é semelhante ao modelo cascata, apresentado na
Figura 2, onde eram levantados todos os requisitos, depois era executado o desenvolvimento
destes itens, e por fim era implantado no cliente. Uma representação do modelo de processo
de desenvolvimento existente na empresa pode ser visto na Figura 23.
Figura 23 – Processo de Desenvolvimento Existente

80
Este processo apresenta algumas diferenças do modelo cascata em relação a testes,

modelagem e planejamento tais como: os testes completos da funcionalidade não existiam,
acontecendo apenas testes unitários feitos pelo desenvolvedor durante a criação. Esta falta de
testes padronizados impactava diretamente na qualidade do produto, em que se acabava
gerando mais solicitações de correções após a entrega do produto.
A modelagem realizada era muito ineficiente, onde após receber os requisitos do
sistema a ser desenvolvido, a equipe esboçava apenas como ficariam as tabelas no banco de
dados e quais campos teriam em cada tela. Diversas vezes era necessário modificar tanto as
tabelas já criadas com a inclusão de campos novos nas telas do sistema gerando retrabalho e
atrasos ainda maiores no desenvolvimento. Os resultados deste processo são sistemas, na
maioria das vezes, sem documentação ou qualquer planejamento de sua arquitetura ou
projetos detalhados de software.
Em relação ao planejamento se tornava falho, pois não possuia informações válidas
de históricos de sistemas desenvolvidos e as mudanças de requisitos eram constantes, mesmo
em fase de desenvolvimento e em funcionalidades que já estavam consideradas prontas. As
primeiras versões do sistema eram concluídas em poucos meses, mas a manutenção e
correção durava por 1 a 2 anos após a implantação
São utilizados cronogramas, mas devido à precariedade no processo de
desenvolvimento, existe uma elevada dificuldade de serem cumpridos adequadamente,
ocorrendo geralmente um atraso na entrega dos produtos.
Estas dificuldades acabam criando problemas para qualquer organização, onde os
software geram um excesso de manutenção corretiva, falhas graves e descontentamento dos
envolvidos (Clientes, Funcionários e desenvolvedores). O tempo gasto com a manutenção
acaba se tornando maior que o tempo gasto para desenvolver o sistema, necessitando manter
uma equipe alocada para realizar a manutenção destes sistemas.
3.1.4 Melhorias Almejadas para a Situação Existente
Como citado anteriormente, a empresa SIMPLISS encontra-se em grande expansão e

busca, principalmente, reestruturar a organização, melhorando todos os seus processos para
oferecer qualidade e excelência de seus serviços.
Já foram feitas melhorias nos processos de atendimento ao cliente que conta,
atualmente, com um sistema de ordem de serviço, chat online, atendimento telefônico e
81
visitas presenciais. Ocorreu também uma expansão do quadro de pessoal para atender as
novas demandas nos outros setores.
Nas áreas de assessoria e consultoria não foi diferente, os investimentos ocorreram
para: aumento do número de funcionários; criação de documentação de visitas; documentação
de levantamentos de alterações; e documentação de processos de implantações de novos
sistemas, tornando também o serviço robusto e confiável.
O próximo passo é exatamente a expansão e melhoria dos processos de
desenvolvimento de novos projetos de software. Como existia um necessidade por parte da
diretoria de utilizar um processo de desenvolvimento que se adapte a suas necessidades, a
implantação da metodologia ágil foi apoiada, servindo assim como tentantiva de correção dos
problemas apresentados anteriormente.
3.2 Análise do ambiente em relação à Metodologia Ágil Scrum
Depois de observar a empresa e apoiando-se nas pesquisas de diferentes tipos de

metodologias que podem ser aplicáveis para o contexto, a metodologia ágil Scrum foi
escolhida para ser implantada na organização, por diversas razões que serão apresentadas
nesta seção.
Como a empresa não possuia nenhum tipo de metodologia padronizada de processo de
desenvolvimento, a escolha deveria ser por uma solução fácil de ser entendida e utilizada
pelos demais membros da equipe. Implantar processos muito complexos poderia gerar um
desânimo por parte da equipe, principalmente por interferir diretamente na rotina que estavam
acostumados a trabalhar durante anos.
A metodologia Scrum atende a essas exigências de simplicidade e rápida
aplicabilidade, de modo que a equipe não necessitará alterar muito suas práticas de
desenvolvimento por estar utilizando esta metodologia, e sim buscando apenas se adaptar as
características da metodologia, buscando assim a melhoria da organização e padronização dos
processos.
O Scrum fornece também uma base para que se criar equipes mais comunicativas,
através das reuniões diárias, onde cada membro da equipe estará ciente do que o companheiro
está fazendo e de suas dificuldades. Esta reunião proporciona também a oportunidade de
ocorrer trocas de experiências entre os participantes, nivelando a maturidade da equipe a um
nível mais alto. Com isto, os membros mais novos da equipe aprenderão mais rápido com os
82
membros mais experientes, podendo refletir sobre os seus hábitos para verificar se estão
executando da forma mais produtiva.
Outro fator importante que foi levado em conta na hora de escolher a metodologia
Scrum foi a preocupação da metodologia em estabelecer quais são as pessoas envolvidas e as
comprometidas no projeto. Os desenvolvedores da empresa se sentiam apenas como
executores do projeto e não como parte do projeto. Quando se tem uma equipe comprometida
com o projeto, por consequência, têm-se uma equipe motivada e disposta a entregar o projeto
com qualidade e dentro do prazo que foi solicitado.
Devido à metodologia Scrum ser adaptável à mudanças de requisitos durante o
projeto, ou de trabalhar com requisitos incompletos, esta metodologia tornou-se uma solução
para os problemas anteriores, pois os sistemas eram colocados em produção, mas se
constatava a falta de alguns requisitos, de forma que estes eram enviados de volta para o
desenvolvimento resolver, provocando o desenvolvimento de sistemas sem qualidade
garantida.
Com todas estas características apresentadas, a metodologia Scrum se destaca como a
solução a ser implantada na empresa, apoiada em conjunto, pela diretoria da empresa e pela
equipe de desenvolvimento, que concordaram em realizar o estudo de caso. Serão utilizados
também os conceitos do Kanban para o quadro de tarefas, reforçando ainda mais a
metodologia, conforme foi apresentado na seção 2.9.3, além das técnicas de estimativa e
controle de tarefas realizadas como o Planning Poker e gráfico Burndown, respectivamente.
3.3 Planejamento Proposto para a Implantação de um Novo Processo de

Desenvolvimento
Definida a metodologia ágil Scrum como a solução a ser implantada, é necessário

dividir a sua implantação em três etapas: Infraestrutura, Treinamentos e Prática, como podem
ser visto na Figura 24.
Na etapa de infraestrutura, será resolvido todos os elementos que dizem respeito ao
ambiente da equipe de desenvolvimento, para que tudo esteja pronto antes de iniciar o
processo de desenvolvimento, visando evitar a falta destes elementos durante o início do
projeto.
83
Figura 24 – Etapas da implantação do Scrum no Estudo de Caso.
Em seguida, na segunda etapa serão realizado os treinamentos, dividindo por papéis da

metodologia: Scrum Master, Product Owner e equipe de desenvolvimento. Com todos os
membros da equipe conhecendo o que terão que fazer, chega a hora de realizar a última etapa,
que é a prática da metodologia no desenvolvimento de software. A partir desta divisão, foi
possível estabelecer um cronograma da implantação a metodologia ágil, e estabelecendo um
guia para a equipe cumprir as tarefas exigidas. O cronograma pode ser visto na Tabela 9. Nas
próximas seções, serão apresentadas como foi a execução de cada uma das etapas da
implantação.
Tabela 9 – Cronograma de Implantação

Tarefas Inicio Término
Estudo de Caso - Implantação do SCRUM 01/08/2012 26/03/2013
Reunião inicial - Estabelecendo metas 01/08/2012 01/08/2012
Reunião de Apresentação da Solução 08/08/2012 08/08/2012
Infraestrutura 08/08/2012 10/08/2012
Preparação do ambiente 08/08/2012 10/08/2012
Treinamentos 12/08/2012 04/09/2012
Scrum Master 12/08/2012 17/08/2012
Product Owner 31/08/2012 31/08/2012
Equipe Scrum 04/09/2012 04/09/2012
Definição da Visão do Produto 31/08/2012 15/09/2012
Definição do Product Backlog 16/09/2012 05/10/2012
Prática - Sprint 001 08/10/2012 29/10/2012
Release Planning Meeting - Sprint 001 08/10/2012 08/10/2012
Sprint Planning Meeting – Sprint 001 08/10/2012 08/10/2012
Executando a Sprint 001 + Daily Scrum Meeting 09/10/2012 28/10/2012
Sprint Review – Sprint 001 29/10/2012 29/10/2012
Sprint Retrospective - Sprint 001 29/10/2012 29/10/2012
84
Prática - Sprint 002 26/11/2012 17/12/2012

Prática - Sprint 003 07/01/2013 28/01/2013
3.4 Primeira Etapa: Infraestrutura
Na primeira etapa, na infraestrutura foi feito uma preparação do ambiente para

começar a executar as tarefas do Scrum. Por se tratar de uma metodologia que não necessita
de grandes mudanças de ambiente, são poucos os itens a serem ajustados. Foram identificados
os seguintes pontos:
1. Servidor configurado com uma área pública para troca de arquivos;
2. Servidor de controle de versão, para documentação e projeto;
3. Criação do quadro Kanban para controle de tarefas;
4. Baralho para Planning Poker utilizado nas estimativas;
5. Local para reuniões diárias, em frente ao quadro do Kanban;
6. Reservar um horário fixo para todos da equipe, visando realizar a reunião diária; e
7. Providenciar materiais auxiliares para trabalho como Post-it, canetas, etc.
Foi realizada uma reunião com a diretoria da empresa, para apresentar as mudanças
necessárias e a relação de custos a ser investida para se ter tal infraestrutura. A mesma foi
aprovada e o material foi encaminhado para o administrativo para providênciar.
Item 1: Os servidores foram configurados com a área pública, pois a documentação
teria que ficar disponível para toda a equipe, mantendo o valor de transparência da
metodologia Scrum. Um espaço para isto foi disponibilizado, pouco tempo depois, no
servidor local.
Item 2: O servidor de controle de versão para projeto seria para sanar um problema
que ocorria frequentemente no desenvolvimento, que seria a perda de versão caso um
sobrescreva o projeto de outro colega. Foram estudadas algumas versões disponíveis no
85
mercado e, por fim, foi instalado o SubVersion (SUBVERSION, 2013), com o controle
utilizando o TortoiseSVN (TORTOISESVN, 2013). Apesar de ser um elemento que não
consta na metodologia Scrum, foi necessário colocar esta necessidade em pauta para que não
ocorram atrasos desnecessários.
Item 3: Foi criado o quadro Kanban para ser utilizado no desenvolvimento, sendo sua
versão inicial mostrada na Figura 25. Caso fosse necessário, durante a sua utilização, ele
poderia sofrer adaptações, conforme a equipe achar necessária. Ficou acordado também que
seria feito as reuniões diárias, em pé, conforme orienta o Scrum, em frente ao quadro Kanban.
Apenas as reuniões mais longas seram feitas na sala de reuniões.
Figura 25 – Quadro Kanban utilizado no Estudo de Caso.
Item 4: O baralho de Planning Poker foi providenciado e será criado com o logo da
empresa. Enquanto o baralho está para ser desenvolvido, foi utilizado um emprestado. Em
vista que é mais importante o evento em si, pode ser utilizado até baralhos tradicionais para
realizar o evento, visando estimar as atividades.
Itens 5 e 6: Foi reservado o horário das 09h10min às 09h25min para a realização da
reunião diária. Foi consultado todos os membros da equipe previamente, a fim de não ocorrer
nenhum problema de conflito com os horários.
Item 7: O setor administrativo realizou a compra de todos os materiais necessários
para o inicio do projeto.
Depois de todas estas simples exigências serem cumpridas, a primeira etapa se
concluiu, chegando o momento de iniciar a etapa dos treinamentos da equipe.
86
3.5 Segunda Etapa: Treinamentos
A segunda etapa consiste em preparar a equipe para desenvolver sistemas de software

com a metodologia Scrum. Para isto, foi realizado treinamentos com todos os membros da
equipe que irão participar. Como cada um dos papéis exige responsabilidades diferentes, os
treinamentos foram divididos em três tipos: Scrum Master, Product Owner e Equipe de
Desenvolvimento.
Foram divididos os papéis entre as equipes, a fim de definir quem participaria de cada
tipo de treinamento e reuniões. Como responsável pela implantação do Scrum na empresa, o
autor desta pesquisa foi escolhido como o Scrum Master dos primeiros projetos e um
consultor foi escolhido como Product Master, devido sua experiência e conhecimento de
regras de negócio. O restante participará dos treinamentos de equipe de desenvolvimento.
O Scrum Master ficou responsável por ministrar o treinamento da equipe de
desenvolvimento e do Product Owner, pois é uma das características originais do papel,
devendo zelar para que todos tenham conhecimento dos processos e regras do Scrum. Só o
treinamento de Scrum Master que foi feito por uma empresa terceirizada.
3.5.1 Scrum Master
Para obter sucesso na implantação do Scrum e, principalmente, por ter que ministrar
os treinamentos do Product Owner e da equipe de desenvolvimento, a diretoria da empresa
preferiu investir no treinamento do Scrum Master, a partir de uma empresa especializada.
Devido ao autor desta pesquisa estar diretamente envolvido e já possuir
conhecimentos sobre o assunto, ficou decidido pela diretoria que ele seria o Scrum Master e
receberia o treinamento externo. Foi escolhido então um treinamento online da TI Exames,
chamado “Fundamentos do Scrum”, que é um preparatório para o exame Profissional Scrum
Master I da Scrum.org (que foi criado por um dos fundadores do Scrum - Ken Schwaber)
(TIEXAMES, 2013).
O Treinamento de 16 horas online foi produtivo, no qual se obteve um bom proveito,
inclusive para preparar o material para os demais treinamentos. O material público do curso
foi repassado para os membros da equipe para eles já irem estudando sobre o assunto.
Foi alocado um tempo maior para este treinamento, para que o Scrum Master pudesse
estudar mais sobre o assunto e criar as apresentações para os outros membros.
87
3.5.2 Product Owner
O Scrum Master reuniu-se com o Product Owner, outros consultores e alguns

integrantes da diretoria, para realizar um treinamento sobre a metodologia ágil Scrum,
focando, principalmente, nas tarefas e responsabilidades do Product Owner.
O treinamento demorou em torno de duas horas e não ocorreu nenhuma interrupção,
sendo bem aproveitado. Um material de apoio contendo o ciclo de desenvolvimento e alguns
tópicos importantes do treinamento foram entregues para os participantes. Foi apresentada,
primeiramente, uma visão de como são os conceitos dos processos de desenvolvimento
tradicionais e uma comparação a esta nova proposta, que seria a metodologia ágil.
Depois disto foi apresentado o Scrum e seu ciclo de desenvolvimento, explicando cada
um dos artefatos e eventos de forma genérica. Na segunda etapa, foi aprofundado nos eventos
e artefatos que são de responsabilidade do Product Owner.
Foi mostrado também como criar um Product Backlog, como definir sua prioridade e
como escrever as estórias de usuários. Alguns exemplos foram apresentados, abrindo espaço
para discussão e perguntas. No final, foi realizada uma simulação de criação de um Product
Backlog e priorizando-o, conforme a necessidade.
No geral, os participantes apresentaram muito interesse pela nova metodologia,
ficando otimistas com as soluções que o Scrum oferece. Durante a participação, eles relataram
algumas falhas que a metodologia corrige, como por exemplo, a do relacionamento com o
cliente, que era só consultado na entrega do produto. Com a nova abordagem, esta troca de
informação com o cliente ocorrerá em no máximo quatro semanas, com a finalização da
Sprint. Consequentemente, o cliente poderá realizar feedbacks, positivos e negativos.
Ficou acordado que o Product Owner irá iniciar o levantamento de requisitos para a
primeira sprint, que deve ocorrer depois do treinamento da equipe. Também ficou acordado
que ele irá criar a visão geral do produto para facilitar o entendimento de todos os envolvidos
no projeto em questão.
3.5.3 Equipe de Desenvolvimento
Depois do treinamento do Product Owner, foi à vez dos desenvolvedores se reunirem

para receber o treinamento na data prevista. Todos receberam manuais e uma cópia do ciclo
de vida da metodologia Scrum.
88
Desta vez, foram necessários mais de cinco horas, sendo discutidos o ciclo de
desenvolvimento e explicado cada um dos artefatos e eventos de forma genérica. Ou seja,
apresentou-se o mesmo conteúdo do treinamento de Product Owner, adicionando explicações
mais aprofundadas sobre a documentação, a utilização do quadro Kanban e sobre a estimativa
utilizando o Planning Poker.
O que se pode observar é que aconteceu uma boa receptividade da equipe, em que eles
aprovaram o novo processo de desenvolvimento. Era nítido que o time estava precisando de
uma metodologia para se organizar. Durante praticamente todas às cinco horas de
apresentação ocorreram perguntas/discussões sobre cada processo, o que demostra que a
equipe estava interessada nesta nova solução.
Algumas questões preocuparam os desenvolvedores, principalmente os mais
experientes, provavelmente por experiências ruins nos projetos passados. O receio na maioria
das vezes era de como seria a documentação do processo, como os requisitos seriam passados
para ser desenvolvidos e em que formato viria está informação. Foi esclarecido que o Scrum
seguirá uma documentação simplificada e com o contato direto com o representante do
cliente, o Product Owner poderia esclarecer as dúvidas com maior facilidade.
A equipe se preocupou também em como o novo processo seria desenvolvido, visto
que os desenvolvedores tem que realizar a manutenção nos projetos anteriores. Assim,
decidiu-se com a diretoria que a equipe de desenvolvimento iria trabalhar apenas uma parte
do dia para os projetos Scrum, apenas até terminar alguns desenvolvimentos e, quando for
possível, alocar apenas os projetos com Scrum.
Ao final, foi possível perceber o clima de otimismo e união que se estabeleceu,
principalmente por dar solução a problemas que se enfrenta há anos com a falta de um
processo de desenvolvimento. Tanto os novos integrantes, quanto os mais experientes,
estavam prontos para começar.
3.6 Terceira Etapa: Prática
Depois de definida a infraestrutura e de realizar todos os treinamentos necessários, era

o momento de realizar na prática os conceitos da metodologia ágil Scrum. Foi escolhido um
projeto novo, que não possuia um prazo definido, sendo um produto novo para a empresa.
Este novo sistema é entitulado DECA (Declaração Cadastral), que é um sistema de
declaração cadastral, no qual a prefeitura mantém todas as informações de todas as empresas
89
do município. Devido a restrições de direitos autorais, não serão apresentados neste trabalho
as informações sigilosas em relação ao projeto, como detalhes de como o sistema irá
funcionar ou diferenciais em relação aos concorrentes.
Nas próximas seções, serão relatados o processo de criação do Product Backlog e
Visão do produto, além de uma descrição detalhada de como foi as primeiras interações
(Sprints).
3.6.1 Time Scrum formado para o Projeto
Antes de relatar a execução do projeto e suas etapas, é interessante conhecer os

integrantes do Time Scrum, responsáveis por todas as interações e o desenvolvimento do
projeto. Na Figura 26, é possível visualizar como está formado o time para este estudo de
caso. Vale ressaltar que cada um dos personagens que aparecem na imagem representam uma
pessoa da equipe formada para desenvolver este projeto.
Figura 26 – Representação da Equipe Scrum Formada para o Estudo de Caso
Na Tabela 10, é possível observar as características de cada um dos participantes,

assim como as suas respectivas experiências em relação ao projeto a ser desenvolvido.
90
Tabela 10 – Características dos Integrantes da Equipe Scrum.

Product Owner • Experiência na área do negócio: 15 anos de experiência na área.
• Experiência com desenvolvimento: Trabalhou como analista de negócios de
alguns projetos de software, durante aproximadamente 7 anos.
• Tempo de Empresa: Aproximadamente 7 anos.
• Horas semanais disponíveis para o projeto: 20 horas.
Scrum Master • Experiência na área do negócio: Durante o período na empresa e período que
trabalhou como estagiário na prefeitura. Aproximadamente 3 anos e meio.
• Experiência com desenvolvimento: Experiência direta durante todo o período
em que está na empresa, fora alguns projetos anteriores. Aproximadamente 3
anos e meio de experiência.
Desenvolvedor 01 • Experiência na área do negócio: Durante o período na empresa,
aproximadamente 1 ano.
• Experiência com desenvolvimento: Nenhuma. Atuava apenas prestando
suporte a clientes.
• Tempo de Empresa: Aproximadamente 1 ano.
Desenvolvedor 02 • Experiência na área do negócio: Durante o período na empresa.
em que está na empresa, aproximadamente 1 ano.
• Tempo de Empresa: Aproximadamente 1 ano.
Desenvolvedor 03 • Experiência na área do negócio: Durante o periodo na empresa.
em que está na empresa, aproximadamente 3 anos.
Desenvolvedor 04 • Experiência na área do negócio: Durante o período na empresa.
em que está na empresa, aproximadamente 3 anos.
Como pode se observar, a equipe é formada por metade de desenvolvedores

experientes e outra metade por novatos, o que será interessante para apresentar o
91
comportamento destes dois tipos de profissionais durante a implementação do processo. É

importante destacar a experiência do Product Owner com o negócio, o que torna um
diferencial importante na hora de trocar experiências com os desenvolvedores.
3.6.2 Escopo do Projeto
O primeiro passo a ser realizado no projeto é a criação da visão do produto, que

representa um documento simples, relatando do que se trata o sistema. Além disto, deve-se
elaborar também a primeira versão do Product Backlog, que contém todos os requisitos do
sistema DECA. É responsabilidade do Product Owner a criação dos dois documentos.
3.6.2.1 Definição da Visão do Produto
A primeira fase do projeto é definir a visão do produto para mostrar à todos os

envolvidos na criação do sistema sobre do que se trata o mesmo, além de marcar um objetivo.
É uma descrição de poucas linhas, apenas para definição.
O Product Owner é o responsável para elaborar esta explicação, sendo que ele
começou a elaborar depois do treinamento que recebeu. Seguindo alguns modelos, não obteve
nenhuma dificuldade. A visão do produto pode ser visualizada na Tabela 11.
Tabela 11 – Visão do Produto

Nome do Produto DECA Eletrônica (DECA – Declaração Cadastral)
Problema/Necessidade Agilizar o processo de abertura, alteração cadastral e
encerramento de empresas/autônomos pela web, permitindo a
integração de vários órgãos.
Principais Permitir a pré-consulta pelo contribuinte sobre a viabilidade do
Funcionalidades exercício de uma atividade em um determinado local. Integração
entre os diversos órgãos e departamentos. Permitir trâmite on-line
de todos os procedimentos necessários à finalização do processo.
Como citado anteriormente, algumas partes foram retiradas para manter os direitos
autorais do sistema. A versão oficial conta ainda com informações como: Diferenciais do
produto, Condição Geral de Satisfação, Premissas, Riscos e Impedimentos.
92
O documento foi mostrado para a diretoria e para os membros da equipe de

desenvolvimento, que o aprovaram, alegando que assim puderam conhecer um pouco mais
sobre o produto.
3.6.2.2 Definição do Product Backlog
A segunda tarefa ao criar o escopo do produto é definir a primeira versão do Product

Backlog. Como já era previsto, o Product Backlog não conhecia todos os requisitos
necessários para desenvolver o sistema completo. Por este motivo, o Product Backlog sofrerá
mudanças e adaptações até o final do projeto, sendo total responsabilidade do Product Owner
realizar tais modificações.
Nesta versão inicial, foram identificados apenas dez requisitos, o que comprova a
afirmação anterior de que ele irá se expandir. Como já tinha sido previsto, o Product Owner
precisou de um tempo a mais para desenvolver este documento. Foram priorizados também
todos os itens, de 0 a 1000, a fim de identificar quais eram os mais importantes a serem
desenvolvidos inicialmente. A escala escolhida ajuda na análise de projetos de grande porte,
onde existem muitos requisitos. O modelo adotado como Product Backlog pode ser visto na
Tabela 12, abaixo.
Tabela 12 – Modelo de Product Backlog
ID Quem? O que? Porque? Prioridade
<Código <Quem solicitou a <O que foi solicitado> <Por que é <Prioridade
identificador funcionalidade > necessário está de 0 a 1000>
sequencial> funcionalidade>
O Product Owner recebeu um prazo de cerca de 20 dias para finalizar a primeira

versão, pois também realizou o levantamento das informações auxiliares aos requisitos, as
especificações de como criar certas funcionalidades, documentos oficiais de órgãos estaduais
e um resumo de como funciona atualmente este cadastro na prefeitura. Foi necessário o
auxílio do Scrum Master para a elaboração deste documento, para seguir a forma correta de
sua criação.
3.6.3 Desenvolvimento do Projeto
Ao finalizar o Product Backlog é o momento de iniciar o desenvolvimento do projeto

DECA, utilizando a metodologia ágil Scrum. Neste trabalho, está previsto o acompanhamento
93
das três primeiras interações (Sprints), acompanhando assim a evolução da equipe e relatando
a implantação da metodologia.
Serão apresentados as Sprints, relatando os acontecimento dos principais eventos:
Release Planning Meeting, Sprint Planning Meeting, Sprint Review e Sprint Retrospective.
Além disto, será apresentado um diário de bordo das reuniões diárias, a fim de acompanhar o
processo durante o projeto.
3.6.3.1 Sprint 001
Depois do Product Backlog ter sido finalizado, pôde-se marcar a primeira Sprint.
Como era esperada, nas primeiras interações de uma equipe que está começando a utilizar
uma metodologia ágil, exige-se muito do Scrum Master para que sejam cumpridas todas as
regras do Scrum, até que todos ganharem experiência com a metodologia. A seguir,
apresenta-se um relato do que ocorreu durante a sequência da Sprint, conforme o ciclo de
desenvolvimento. O período definido para a execução de cada Sprint foi de três semanas para
avaliar o desempenho.
3.6.3.1.1 Release Planning Meeting – Sprint 001
Inicialmente, foi realizada a reunião de Release Planning Meeting no dia 08/10/2012,

das 9h00min ao 12h00min, onde o Product Owner, pela primeira vez, explicou a visão do
produto e do que se tratava o problema a ser resolvido com ele. Como nenhum dos
participantes conhecia as tarefas a serem feitas, foi necessário que o Product Owner
explicasse cada um dos itens.
Toda a equipe fez perguntas sobre o assunto e sobre cada um dos itens, para que se
tivesse uma ideia do que realmente terão que criar durante o projeto. O Scrum Master teve
que intervir em alguns momentos para manter o controle da reunião, evitando o desvio de
foco ou conversas que poderiam atrapalhar o cronograma de atividades.
A equipe realizou a estimativa de complexidade de cada item do Product Backlog
utilizando o baralho de Planning Poker. Devido às restrições de direitos autorais, não será
possível mostrar o Product Backlog, priorizado e avaliado conforme sua complexidade,
durante esta pesquisa.
Por fim, o Product Owner em conjunto com a equipe de desenvolvimento, definiram
que será realizado primeiramente um cadastro mobiliário, o que seria um item com mais
94
prioridade. Também definiram que a meta para esta Sprint é desenvolver a estrutura base para
o cadastro com documentação, levantamento de restrições e validações, assim como as telas
para apresentar a estrutura.
3.6.3.1.2 Sprint Planning Meeting – Sprint 001
No mesmo dia da reunião de release, 08/10/2012, das 14h00min às 16h20min, desta

vez com a participação apenas da equipe de desenvolvimento e do Scrum Master. Ocorreu a
reunião Sprint Planning Meeting, tendo como objetivo planejar como será atingido a meta da
Sprint, definindo quais as tarefas necessárias para isto. Desta forma, criou-se o Sprint Backlog
da Sprint 001.
A equipe definiu as tarefas pensando nos conceitos básicos do desenvolvimento:
levantamento de informação, documentação, modelagem de banco de dados, criação de casos
de uso, implementação e, por fim, testes das funcionalidades. As tarefas podem ser vistas na
Tabela 13, onde também, utilizando o Planning Poker, foram estimadas as horas para serem
completadas.
Tabela 13 – Sprint Backlog e suas respectivas estimativas – Sprint 001.

User Story 001 – Cadastro mobiliário de contribuintes
Tarefa Descrição Estimativa

001 Levantamento de Validações 2h
002 Levantamento de Restrições\ Regras 3h
003 Documentação das Validações 2h
004 Documentação das Restrições\ Regras 5h
005 Caso de Uso 5h
006 Modelagem 5h
007 Diagrama de Classes 1h
008 Dev: Persistência CRUD 5h
009 CN - Metodos Adicionais 8h
010 Dev: tela de Pré-Cadastro 5h
011 Dev: Tela de Create 5h
012 Dev: Tela de Visualizar 3h
013 Dev: Tela de Editar 5h
014 Dev: Tela de Listagem 5h
015 Implementando as Validações 5h
016 Implementando as Restrições\ Regras 5h
017 Teste Tela Pré-Cadastro 1h
95
018 Teste Create 2h

019 Teste Tela Visualizar 1h
020 Teste Tela Editar 2h
021 Teste Tela de Listagem 1h
022 Itens Adicionais - Documentação 3h
023 Levantamento de Informações - Tipo Contrib. 2h
TOTAL 81h
Durante a estimativa de horas para cada tarefa, aconteceram momentos em que o

Scrum Master teve que recuperar o foco da equipe, pois acabavam entrando em detalhes
muito técnicos. Como existia um número igual de desenvolvedores novatos, quanto aos mais
experientes, acabaram surgindo diversas divergências entre as estimativas apresentadas, mas
que depois de algumas explicações de cada lado, acabavam entrando em um acordo.
Finalizado a reunião, as tarefas foram colocadas no quadro Kanban, junto com o
grafico Burndown. A fase de desenvolvimento estava pronta para começar.
3.6.3.1.3 Execução da Sprint 001
A execução da Sprint 001 ocorreu no período de 09/10/2012 à 26/10/2012, com a

realização das reuniões diárias, com toda a equipe, em frente ao quadro Kanban. Como pode
ser visto nas Tabelas 14, 15 e 16 foram documentados todos os dias de reunião, de forma
resumida. Para facilitar o entendimento, foi enumerado de um a quatro os desenvolvedores,
visando facilitar o entendido da interação, sendo os mesmos apresentados na Tabela 10. A
seguir, apresenta-se a Tabela 14, que corresponde ao diário de bordo da primeira semana da
Sprint 001.
Tabela 14 – Diário de Bordo das Reuniões Diarias da Sprint 001 – 09/10/2012 à 12/10/2012
Data/ Hora Descrição da Reunião Diária
09/10/2012 Gráfico Burndown:

09h10min às 09h25min Gráfico iniciou com 81 horas.
O que foi feito desde a última reunião:
Apenas um review das tarefas a serem feitas.
O que será feito até a proxima reunião:
O Desenvolvedor 01 iria tentar iniciar a primeira tarefa de
levantamento de validações.
Interrupções:
Todos os desenvolvedores estavam com tarefas alocadas, então
não foi possível realizar nenhuma das tarefas. Estavam focados
para desenvolver correções para o dia da atualização.
96

09h10min às 09h25min A situação do grafico Burndown permaneceu o mesmo, pois não
foi executada nenhuma tarefa.
Não foi realizado nada.
O Desenvolvedor 01 iria tentar iniciar a primeira tarefa de
levantamento de validações.
Interrupções:
Todos os desenvolvedores estavam alocados em outros projetos.
09h10min às 09h25min Gráfico Burndown caiu para 80 horas.
O único que conseguiu adiantar foi o Desenvolvedor 01, que
iniciou a primeira tarefa de levantamento das validações,
enviando ao Product Owner para que seja informado.
Foi decidido que todos enviassem as planilhas de controles de
horas para o Scrum Master, visando auxiliar na tomada de
alguma ação junto à diretoria. O Desenvolvedor 01 continuará
com o levantamento das validações.
Interrupções:
Todos os desenvolvedores estavam alocados em outros projetos.
12/10/2012 Não ocorreu expediente.
A seguir apresenta-se a Tabela 15, que corresponde ao diário de bordo da segunda

semana da Sprint 001.
Tabela 15 - Diário de Bordo das Reuniões Diarias da Sprint 001 – 15/10/2012 à 19/10/2012

09h10min às 09h25min Reduziu o número de horas de 80h para 79h.
O Desenvolvedor 01 enviou as informações para o Product
Owner para que seja verificado se existem restrições ou
validações. Ficando no aguardando para finalizar
a documetação dos mesmos.
O Desenvolvedor 04 está terminando o modelo do sistema, e até
o dia 17/10/2012 deve estar pronto, pois será utilizado como base
para a implementação. Foi estabelecido que todos iriam tentar,
ao máximo, priorizar o projeto para que seja cumprido o objetivo
da Sprint.
Interrupções:
Muitas interrupções externas, com a necessidade de alocar a
equipe para outros projetos.

09h10min às 09h25min Reduzio o número de horas de 79h para 77h.
O Desenvolvedor 01 finalizou as duas tarefas de levantamento e
97
se comprometeu a realizar a documentação das mesmas.

O Desenvolvedor 03 irá dedicar 2 horas do dia para iniciar o
trabalho com a modelagem. O Desenvolvedor 02 depende de
finalizar outras tarefas para iniciar o processo. E o
Desenvolvedor 04 estará realizando a manutenção de outros
sistemas até o dia 17/10/2012, sendo impossível alocar qualquer
desenvolvimento para ele. Ele se encarregou de começar a mexer
no modelo para ser utilizado.
Interrupções:

09h10min à 09h25min A situação do grafico Burndown permaneceu o mesmo, pois não
A equipe reportou que na hora de executar a modelagem sentiu
muita falta de informações suficientes para realizar a tarefa. O
Desenvolvedor 02 não conseguiu iniciar o desenvolvimento, pois
necessitou-se desenvolver novos itens externos, sendo este o
mesmo caso do Desenvolvedor 04.
O Desenvolvedor 03 achou melhor alocar 4 horas por dia para as
tarefas de modelagem. O Desenvolvedor 01 estará entrando em
contato com o Product Owner para resolver o que faltou das
validações. O Scrum Master já planeja cancelar algumas tarefas
para entregar basicamente o que é necessário. Diminuiria então
em 17 horas, caindo de 77h para 60h.
Interrupções:

09h10min às 09h25min Reduzio o número de horas de 77h para 60h.
Para cumprir o objetivo da sprint, foi reduzido o número de
atividades, que seriam complementares a funcionalidade
entregue, diminuindo em 17 horas. Estas tarefas terão que ser
feitas, mas em sprints futuras. A equipe percebeu que o
levantamento de dados consome muito tempo e que estimou
pouco tempo para resolver estas questões. Isto está servindo
como ótima experiência para o desenvolvimento, pois começou a
pensar muito mais nas prioridades de um desenvolvimento.
O Desenvolvedor 01 teve muitas interrupções na hora de
terminar o levantamento de validações e irá continuar hoje.
O Desenvolvedor 02 alocou o desenvolvimento do Caso de Uso.
O Desenvolvedor 03 alocou 4 horas do dia de ontem para realizar
as tarefas e ele fez um levantamento em conjunto com a receita
federal, sobre os campos que serão utilizados. Além disso, o
Desenvolvedor 03 irá cruzar com os dados da Associação
Brasileira das Secretarias de Finanças das Capitais (ABRASF)
para iniciar a modelagem. O Desenvolvedor 04está cuidando da
98
estrutura do desenvolvimento, que afeta indiretamente, mas não

faz parte do sistema da DECA propriamente dito. Provavelmente
só poderá ajudar a equipe nas próximas sprints.
Interrupções:

09h30min às 09h45min Os números de horas restantes passaram de 60h para 55h.
O Desenvolvedor 04 criou a maioria das estruturas, nas quais não
faz parte diretamente da DECA. O Desenvolvedor
03 praticamente terminou o diagrama, só faltou adicionar uma
tabela de relação que foi sugerida pelos outros membros da
equipe e gerar o diagrama de banco de dados no SQL Server.
O Desenvolvedor 02 irá iniciar o desenvolvimento da à estrutura
interna, do CRUD (Create, Read, Update e Delete) e em seguida
fazer o diagrama de classes utilizando a própria ferramenta.
Interrupções:
O Desenvolvedor 02 não pode comparecer no trabalho hoje,
devido a problemas de saúde, mas ontem ele terminou os casos
de uso. O Desenvolvedor 01 conseguiu mexer muito pouco no
projeto, devido à interferência externa urgente.
Por fim, a Tabela 16, que corresponde ao diário de bordo da terceira e última semana
da Sprint 001.

09h15min à 09h45min Os números das horas restantes passaram de 55 para 50 horas.
O Desenvolvedor 02 está fazendo os códigos da Camada de
negócio e o diagrama de classes.
O Desenvolvedor 04 irá terminar os códigos da Camada de
negócio e o diagrama de classes. O Desenvolvedor 01 irá
finalizar o documento de restrições. O Desenvolvedor 02, depois
de terminar algumas tarefas externas, irá tentar iniciar a tela de
cadastro.
Interrupções:
Surgiu boatos que será necessário alocar a equipe toda para uma
licitação que está para ocorrer.

99
O Desenvolvedor 04, reportou que faltam 2 horas para finalizar

as classes bases.
Desenvolvedor 01 ficou de terminar a documentação de
restrições.
Interrupções:
Como foi comentado, devido a empresa precisar participar de
uma licitação, o desenvolvimento do DECA teve que ser
paralizado e toda a equipe foi deslocada para atender os itens da
licitação. Apenas o Desenvolvedor 01 ficou livre por ter que dar
suporte.

09h35min à 09h45min A situação do grafico Burndown permaneceu o mesmo, pois não
Desenvolvedor 01 não conseguiu terminar a documentação de
restrições.
Desenvolvedor 01 ficou de terminar a documentação de
restrições.
Interrupções:
A maioria da equipe está alocada na licitação.

Desenvolvedor 01 está terminando a documentação
das restrições
Desenvolvedor 01 irá iniciar a tarefa de consulta com o Product
Owner, para terminar de fechar a estrutura.
Interrupções:

09h00min às 09h07min O Gráfico caiu de 50h para 45h.
O Desenvolvedor 01 terminou a tarefa de levantamento de
informação com o Product Owner da documentação das
restrições.
Nada, todos estaram alocados.
Interrupções:
Como foi apresentada nas Tabelas 14, 15 e 16, os membros da equipe demoraram para
começar a executar as tarefas da Sprint por estarem alocados em tarefas de outros sistemas.
Quando a equipe começou a trabalhar no projeto do DECA, a situação melhorou, onde se teve
100
uma queda no número de tarefas restantes. Além de pequenas interrupções inevitáveis que
atrapalhavam a equipe durante o desenvolvimento, no fim da Sprint, precisamente na última
semana, a empresa precisando participar de uma licitação, teve que alocar a maioria dos
desenvolvedores, deixando apenas um por meio período.
O Scrum Master, apesar de suas tentantivas de conter os impedimentos, não conseguiu
impedir principalmente está mudança estratégica da empresa, tendo que conversar com o
Product Owner para deixar a fase de desenvolvimento para próxima Sprint.
3.6.3.1.4 Sprint Review da Sprint 001
No dia 29/10/2012, das 09h00min às 11h00min, a equipe de desenvolvimento e o

Scrum Master reuniram-se com o Product Owner para apresentar o que foi feito e explicar o
que ocorreu durante a sprint. Como apenas algumas tarefas de levantamento de informação
foram finalizadas, apenas a documentação foi demonstrada, além da modelagem.
Foram levantadas as tarefas concluídas e suas horas que foram gastas, como mostra a
Tabela 17. Podem-se observar, em alguns casos que, as horas utilizadas foram superiores as
estimadas. Isto acaba sendo normal em uma equipe que está iniciando com o processo de
estimativa, por ainda não conhecer muito bem quanto tempo leva-se para desenvolver uma
tarefa. Com o tempo, a tendência é reduzir esta diferença, pois a equipe acaba aprendendo
com os erros anteriores.
Tabela 17 – Tarefas Finalizadas – Sprint 001

Tarefa Descrição Tempo Tempo
Estimado Gasto
001 Levantamento de Validações 2h 2h
002 Levantamento de Restrições\ Regras 3h 3h
003 Documentação das Validações 2h 3h
004 Documentação das Restrições\ Regras 5h 4h30m
005 Caso de Uso 5h 5h25m
006 Modelagem 5h 12h30m
022 Itens Adicionais - Documentação 3h 3h15m
023 Levantamento de Informações - Tipo Contrib. 2h 1h30m
TOTAL 27h 35h10m
Para apresentar a evolução da sprint, foi observando também o gráfico Burndown da

Sprint 001, onde pode-se perceber um início lento no desenvolvimento, e quando estava
101
começando a desenvolver, uma estagnação ocorreu justamente pelo fato da equipe ser alocada
para outro processo. O gráfico pode ser visualizado na Figura 27.
No final da reunião, foi definida a data de ínicio da próxima Sprint, que devido a
alguns conflitos com a agenda da empresa, terá que ocorrer dentro de um mês. Todos
concordam que não é a situação ideal, mas que deverá ser adotada, pois a empresa tem que
resolver outros compromissos e finalizar esta licitação. O Scrum Master também aproveitou o
tempo para negociar com a diretoria sobre as interrupções constantes.
Figura 27 – Gráfico Burndown – Sprint 001
3.6.3.1.5 Sprint Retrospective da Sprint 001
Para finalizar a Sprint 001, foi realizado no mesmo dia 29/10/2012, das 14h00min às
16h00min a Sprint Retrospective, com a equipe de desenvolvimento e o Scrum Master, onde
foi discutido como foi o processo de desenvolvimento durante a sprint, a fim de melhorar os
pontos falhos.
Sobre os aspectos negativos, a equipe apontou alguns itens que devem ser melhorados:
o Participação mais presente do Product Owner;
102
o Interrupções externas, como manutenções em outros projetos, atrapalhando o

andamento do desenvolvimento;
o Necessidade de criar um processo de revisão dos levantamentos de
informações, antes de para o desenvolvimento; e
o Melhorar a comunicação entre a equipe.
O Scrum Master ficou responsável por conversar com o Product Owner, para ele estar
mais presente e conversar com a diretoria da empresa para criar uma estratégia de não ocorrer
estas interrupções durante o desenvolvimento, aumentando o tempo de dedicação do pessoal
ao projeto.
As questões de comunicação, por se tratar internamente da equipe de
desenvolvimento, foram acordadas que tentaram conversar mais sobre suas dificuldades e
estágios do processo.
Foram levantados pontos positivos desta primeira Sprint, como pode se ver abaixo:
o Comunicação, apesar de falha em alguns momentos, melhorou;
o Integrantes da equipe sabiam agora realmente o que o colega estava fazendo,
em função das reuniões diárias;
o Notaram a quantidade de tempo que levam para fazer um levantamento de
informações, bem superior ao tempo que imaginavam;
o Melhora na união do grupo; e
o A motivação em realizar o projeto aumentou.
Lembrando por serem percepções da equipe, fica válido observar que mesmo logo no
início do processo de implantação, a metodologia ágil já influência na equipe de
desenvolvimento positivamente. É esperado que isto seja amplificado ao longo das demais
Sprints.
3.6.3.2 Sprint 002
Após alguns dias sem iniciar a nova Sprint para que a equipe se reorganiza, devido a
outros projetos, foi dado início a mais uma sprint. Segue, nesta seção, um relato do que
ocorreu durante à sequência da segunda sprint, conforme o ciclo de desenvolvimento. A
duração definida para a execução de cada sprint também foi de três semanas.
103
No dia 26/11/2012, das 09h00min às 12h00min, iniciou-se a reunião de Release

Planning Meeting da Sprint 002, com a presença do Product Owner, Scrum Master e equipe
de desenvolvimento.
A equipe, durante o desenvolvimento da sprint 001, notou a falta de alguns itens no
Product Backlog e levou para a pauta de reunião, sendo discutidos com o Product Owner.
Vale destacar que praticamente todos foram adicionados. Aproveitaram o momento, já foi
realizado a estimativa de complexidade utilizando o Planning Poker.
Devido ao fato da Sprint passada não ter sido finalizado com todas as tarefas prontas,
o time Scrum decidiu que a Sprint 002 será alocada para finalizar as tarefas incompletas da
Sprint 001. Além disto, será adicionado mais um requisito a ser desenvolvido, que
corresponde a solicitação de adicionar informações no cadastro para cobranças de taxas do
cliente.
A meta da Sprint ficou de terminar, inicialmente, o primeiro requisito e depois realizar
o levantamento de informações, documentações e modelagem da segunda etapa. Como
provavelmente não irá ter tempo hábil para o desenvolvimento. Foi escolhido deixar desta
forma, onde em uma sprint seria levantados os dados de um requisito e na seguinte seria
implementado.
Como a equipe não tem ideia do tempo gasto para realizar o desenvolvimento, visto
que estarão utilizando uma tecnologia nova para a mesma, o ASP.net MVC, não foi possível
determinar se todas as tarefas serão feitas até o final. Com o tempo, este problema deve se
extinguir.
No mesmo dia do Release Planning Meeting, dia 26/11/2012, das 14h00min às

16h20min, desta vez com a participação apenas da equipe de desenvolvimento e o Scrum
Master, ocorreu a reunião Sprint Planning Meeting da Sprint 002, tendo como objetivo
planejar como será atingido a meta da sprint, definindo quais as tarefas necessárias, criando o
Sprint Backlog da Sprint 002.
A equipe de desenvolvimento aproveitou as mesmas tarefas definidas na Sprint 001,
do primeiro requisito (User Story 001), apenas realizando novamente a estimativa de horas
que seriam gastas para cumprir todas as tarefas restantes. Em algumas tarefas ocorreram
104
mudanças, sempre aumentando as horas gastas, principalmente por se basearam nas primeiras
experiências que tiveram na Sprint 001. Depois foram determinadas as tarefas para realizar
apenas o levantamento de informação, documentação e modelagem do segundo requisito
(User Story 002). As tarefas definidas e suas estimativas podem ser vistas na Tabela 18.
Tabela 18 - Sprint Backlog e suas respectivas estimativas – Sprint 002.

User Story 001 – Cadastro mobiliário de contribuintes

001 Persistencia CRUD 1h
002 Implementando as validações 5h
003 Implementando as retrições\regras 8h
004 Diagrama de Classes 1h
005 Tela de Create 8h
006 Tela de Editar 5h
007 Tela de Visualizar 3h
008 Tela de Listagem 13h
009 Tela de Pré-Cadastro 2h
010 Teste Create 3h
011 Teste Visualizar 1h
012 Teste pre-cadastro 1h
013 Teste Editar 3h
014 Teste Listagem 3h
Sub Total 57h
User Story 002 – Cadastro de contribuintes em relação a taxas e alvará

015 Levantamento de Logica (Regime) 8h
016 Documentação (Regime) 3h
017 Modelagem de Banco de Dados (Regime) 2h
018 Revisão da Modelagem de Banco de Dados (Regime) 1h
019 Levantamento de Logica (CNAE x Ativ.) 8h
020 Documentação (CNAE x Ativ.) 2h
021 Modelagem de Banco de Dados (CNAE x Ativ.) 1h
022 Revisão da Modelagem de Banco de Dados (CNAE x Ativ.) 1h
023 Levantamento de Logica (Taxa de Lic.) 3h
024 Documentação (Taxa de Lic.) 2h
025 Modelagem de Banco de Dados (Taxa de Lic.) 2h
026 Revisão da Modelagem de Banco de Dados (Taxa de Lic.) 1h
027 Levantamento de Logica (Pub. E Gerais) 2h
028 Documentação (Pub. E Gerais) 2h
029 Modelagem de Banco de Dados (Pub. E Gerais) 2h
105
030 Revisão da Modelagem de Banco de Dados (Pub. E Gerais) 1h

031 Levantamento de Logica (Ini. E Enc.) 5h
032 Documentação (Ini. E Enc.) 1h
033 Modelagem de Banco de Dados (Ini. E Enc.) 1h
034 Revisão da Modelagem de Banco de Dados (Ini. E Enc.) 1h
035 Levantamento de Logica (Alvará) 8h
036 Documentação (Alvará) 3h
037 Modelagem de Banco de Dados (Alvará) 2h
038 Revisão da Modelagem de Banco de Dados (Alvará) 1h
Sub Total 63h
Tarefas Adicionais
039 Criação de Layout (Adicionada dia 13/12/2012) 8h
Sub Total 8h
TOTAL 128h
Diferente da primeira reunião, a equipe não precisou tanto das intervenções do Scrum
Master, começando a seguir a reunião conforme o framework Scrum recomenda, de forma
mais objetiva. A quantidade de horas a serem desenvolvidas se mostra maior que a sprint
anterior, mas por possuirem dados suficientes para determinar quanto à equipe podem render
ficam aceitáveis para adquirir experiência. As tarefas foram adicionadas no quadro Kanban,
assim como preparado o Grafíco Burndown.
Durante o período de 27/11/2012 à 14/12/2012 ocorreu o desenvolvimento da Sprint

002. Assim, como foi feito na Sprint 001, ocorreu à documentação do diário de bordo do
periodo, como pode ser visto nas Tabelas 19, 20 e 21. A seguir apresenta-se a Tabela 19, que
corresponde ao diário de bordo da primeira semana da Sprint 002.
Gráfico Burndown:
120 horas restantes.
Realizou-se um review das tarefas.
27/11/2012
O que será feito até a próxima reunião:
09h10min às 09h25min
Desenvolvedor 04, por ter mais experiência irá passar para o
Desenvolvedor 01 e o Desenvolvedor 02 como ficou a estrutura do
sistema. Ambos estão esperando estas informações para começar a
desenvolver. O Desenvolvedor 03 irá iniciar algumas tarefas da User
106
Story 002, que seria levantar dados em conjunto com o Product

Owner, mas ele depende da disponibilidade de tempo no fim da
tarde.
Interrupções:
Inicialmente nenhuma.
Gráfico Burndown:
A situação do gráfico Burndown permaneceu o mesmo, pois não foi
executada nenhuma tarefa.
O Desenvolvedor 04 passou para o Desenvolvedor 01 e
o Desenvolvedor 02 um pouco sobre a estrutura.
28/11/2012
O que ficou definido para a proxima reunião foi que o
Desenvolvedor 02, após terminar algumas tarefas, irá trabalhar com
a tela de Create e o Desenvolvedor 01 tentará iniciar o
desenvolvimento da tela de pré cadastro.
Interrupções:
Os desenvolvedores tiveram algumas intereferências externas.
Gráfico Burndown:
A situação do grafico Burndown permaneceu o mesmo, pois não foi
O Desenvolvedor 04 passou mais um pouco sobre a estrutura para o
Desenvolvedor 01 e o Desenvolvedor 02, que acabaram descobrindo
alguns problemas na estrutura, mas o Desenvolvedor 04 conseguiu
29/11/2012
arrumar.
Foi passado para o Desenvolvedor 01 e o Desenvolvedor 02
alocaram uma tarefa, independente se não souberem ainda como
fazer, assim irá focar o trabalho deles.
Interrupções:
O Desenvolvedor 03 ficou alocado no suporte de outros sistemas, e
não conseguiu iniciar as tarefas de banco.
Gráfico Burndown:
O gráfico Burndown reduziu de 120h para 119h.
O Desenvolvedor 04 terminou a parte de persistência CRUD e
passou para o Desenvolvedor 01 e o Desenvolvedor 02.
30/11/2012 O Desenvolvedor 02 está mais tranquilo hoje, tendo apenas que
09h10min às 09h23min fazer uma tarefa externa, depois só ficará em cima da tela de create.
O Desenvolvedor 01 está com quase toda a tela de pre-cadastro
finalizada e depois irá iniciar a tela de visualizar.
Interrupções:
O Desenvolvedor 04 estará ocupado todo o periodo com outras
tarefas externas. O Desenvolvedor 03 não conseguiu trabalhar com
nenhuma atividade e só irá tentar fazer a alteração do banco de
dados, para iniciar os processos na próxima semana.
107

Gráfico Burndown:
A situação do grafico Burndown permaneceu o mesmo, pois não foi
Conforme o Desenvolvedor 04 conversou com Scrum Master, o
diagrama de classe demoraria um pouco mais do que a previsão,
portanto não conseguiu terminar. O Desenvolvedor 01 quase
finalizou a tela de pré-cadastro, necessitando apenas de uma revisão
03/12/2012 do Desenvolvedor 04. O Desenvolvedor 02 continuou o
09h10min às 09h16min desenvolvimento da tela de cadastro, mas não conseguiu terminar
ainda.
Desenvolvedor 04 irá terminar o diagrama de classe. O
Desenvolvedor 01 iniciará outra tarefa. Desenvolvedor 02
continuará a desenvolver a tela de cadastro.
Interrupções:
O Desenvolvedor 03 não pode vir trabalhar por motivo de estar com
alguns problemas de saúde.
Gráfico Burndown:
O gráfico Burndown teve uma queda de duas horas saindo de 119h
para 117h.
O Desenvolvedor 01 conseguiu finalizar a tela de pré-cadastro. O
Desenvolvedor 04 corrigiu alguns erros presentes no modelo, quanto
à estrutura do sistema. O Desenvolvedor 02 continuou trabalhando
04/12/2012 na tela de criação de cadastro, porém foram encontrados alguns
09h26min às 09h37min métodos adicionais que devem ser desenvolvidos.
Desenvolvedor 01 irá trabalhar com a tela de edição para dar
continuidade, O Desenvolvedor 02 pretende, finalmente, finalizar a
tela de cadatro.
Interrupções:
Desenvolvedor 04 ficará apenas de suporte, pois o Desenvolvedor
03 não pôde comparecer novamente.
Gráfico Burndown:
O gráfico Burndown permaneceu o mesmo.
05/12/2012
O Desenvolvedor 01 não conseguiu iniciar nenhuma tarefa, pois foi
um dia excepcionalmente atarefado, com suporte a outros sistemas.
Desenvolvedor 02 percebeu, junto ao Desenvolvedor 04, que eram
necessárias adições de novas classes para a finalização da tela de
108
cadastro, portanto, não conseguiu finalizar.

Desenvolvedor 01 tentará iniciar a tela de detalhes, Desenvolvedor
02 terminará a tela de criação de cadastro, Desenvolvedor 04 não
conseguirá fazer nada por estar alocado em outras tarefas externas.
Interrupções:
Desenvolvedor 01 e Desenvolvedor 02 estavam alocados para
manutenção e suporte de projetos externos. O Desenvolvedor 03
teve que sair de licença por problemas de saúde, e provavelmente
não irá mais partipar desta Sprint.
Gráfico Burndown:
O gráfico Burndown permaneceu o mesmo.
O Desenvolvedor 01 iniciou a tarefa de criação da tela de
Visualização de cadastro, porém não finalizou, pois o
Desenvolvedor 02 ainda não tinha terminado a tela de cadastro,
essencial para a construção da Visualização. O Desenvolvedor 04
06/12/2012 estava alocado para outros projetos. O Desenvolvedor 02 não
09h42min às 09h53min terminou a tela de cadastro.
Desenvolvedor 02 terminará a tela de cadastro, Desenvolvedor 01
irá esperar o Desenvolvedor 02 terminar a tela para voltar ao
desenvolvimento da tela de visualização e o Desenvolvedor 04
continuará alocado em outros projetos.
Interrupções:
O Desenvolvedor 04 continuará alocado em outros projetos.
Gráfico Burndown:
O gráfico Burndown teve uma queda de 8 horas, reduzindo de 117h
para 109h.
O Desenvolvedor 02 terminou a tela de criação de Cadastro no dia
anterior. O Desenvolvedor 01 não conseguiu iniciar
nenhuma tarefa justamente por ter ajudado o Desenvolvedor 02 a
terminar a tela. O Desenvolvedor 04 também contribuiu para que a
tela fosse finalizada com sucesso e não conseguiu iniciar
07/12/2012 nenhuma tarefa.
09h15min às 09h26min O que será feito até a proxima reunião:
Desenvolvedor 02 irá trabalhar na tela de Visualizar do pré-cadastro
que o Desenvolvedor 01 iníciou para que os trabalhos se cruzem, ou
seja, haja troca de informações, o Desenvolvedor 01 iniciará a tela
de Edição de cadastro para que também veja o que o Desenvolvedor
02 fez, Desenvolvedor 04 irá realizar o maior suporte possível e não
iniciará nenhuma tarefa, devido a estar alocado em outras tarefas.
Interrupções:
O Desenvolvedor 04 está tendo que realizar suporte e manutenção
de outros sistemas.
109
Por fim a Tabela 21, que corresponde ao diário de bordo da terceira e última semana
da Sprint 002.
Gráfico Burndown:
O gráfico permaneceu o mesmo.
O Desenvolvedor 01 iniciou a tela de Edição para dar andamento. O
Desenvolvedor 02 trocou a tarefa de visualização de cadastro com
o Desenvolvedor 01 para que ele possa ter ciência do que foi feito na
10/12/2012 tela de Create. O Desenvolvedor 04 arrumou alguns métodos que
09h10min às 09h25min estavam falhos no codigo.
Desenvolvedor 02 desenvolverá a tela de Visualizar e o
Desenvolvedor 01 terminará a tela de edição.
Interrupções:
de outros sistemas.
Gráfico Burndown:
O gráfico burndown teve uma queda de 109h para 104h.
O Desenvolvedor 01 continuou desenvolvedo a tela de Edição de
cadastro. O Desenvolvedor 02 progrediu os trabalhos na tela de
Visualização e terminou de conseguir um método de criação do
11/12/2012 cadastro. O Desenvolvedor 04 está alocado em outros projetos.
Desenvolvedor 02 iniciará a tela de Visualização e o Desenvolvedor
01 terminará a tela de edição.
Interrupções:
de outros sistemas.
Gráfico Burndown:
O gráfico burndown teve uma queda de 104h para 83h.
O Desenvolvedor 01 finalizou a tela de Edição. O Desenvolvedor 02
terminou a tela de Visualização de Cadastro e, com a ajuda do
Desenvolvedor 04, fez também a tela de Listagem de Cadastros. O
12/12/2012
Desenvolvedor 04, como citado, ajudou na criação da tela de
Listagem e pesquisou sobre como será implementada futuramente as
tabelas de detalhes do sistema (DataTables).
O Desenvolvedor 01 e o Desenvolvedor 02 discutirão, dos itens que
ainda tem pendência, quem irá trabalhar com os itens restantes.
Interrupções:
110
de outros sistemas.
Gráfico Burndown:
O gráfico Burndown subiu para 91, por ter adicionado novas tarefas.
Foi necessário adicionar 8 horas para realizar o desenvolvimento da
primeira versão do layout visual da aplicação. A tarefa pode ser
observada na Tabela 18.
O Desenvolvedor 01 iniciou os testar de editar e ainda não finalizou.
O Desenvolvedor 02 começou a atividade das restrições e concluiu
13/12/2012 que a maioria já estava feita, finalizando assim, esta tarefa. O
09h10min às 09h23min Desenvolvedor 04 ficou mais uma vez de suporte para os problemas
que o Desenvolvedor 01 e o Desenvolvedor 02 tiveram.
Desenvolvedor 01 e Desenvolvedor 02 trabalharão com os testes e
restrições novamente.
Interrupções:
de outros sistemas.
Gráfico Burndown:
No gráfico Burndown se ocorreu-se uma queda de 91h para 63h.
O Desenvolvedor 04 ajudou no design. O Desenvolvedor 01
conseguiu ajudar na criação do design. O Desenvolvedor 02 ajudou
na criação do design e implementou algumas restrições.
14/12/2012 O que será feito até a proxima reunião:
09h29min às 09h37min O Desenvolvedor 04 terminará o diagrama de classes, o
Desenvolvedor 01 aplicará o layout nas outras páginas, o
Desenvolvedor 02 terminará de ajustar os layouts e continuará com
os testes.
Interrupções:
de outros sistemas.
Conforme pode ser observado nas Tabelas 19, 20 e 21, as tarefas demoraram a
começar a serem desenvolvidas. Assim como na primeira Sprint, o motivo era que os
desenvolvedores estavam alocados em outros projetos. A partir do momento em que a equipe
começou a participar mais do projeto, no dia 05/12/2012, é possível perceber que as
estimativas de execução de cada tarefa não condiziam com a realidade, sendo necessário mais
tempo para terminar cada tarefa.
No meio da Sprint, ocorreu um problema de saúde com um desenvolvedor, que teve
que ficar fora do projeto. Com isto, a equipe foi obrigada a assumir suas tarefas e obrigações
extra projeto DECA. Como acontece em empresas pequenas, existem poucos desenvolvedores
trabalhando no limite e a equipe teve que se apertar para conseguir cumprir com o combinado,
111
prejudicando a execução da sprint. Novamente, ocorreram fatores que o Scrum Master não
conseguiu evitar ou resolver, apenas sendo possível levar estes contratempos para a diretoria.
3.6.3.2.4 Sprint Review - Sprint 002
Durante o dia 17/12/2012, das 09h00min às 11h00min, o time Scrum se reuniu para
realizar a Sprint Review da Sprint 002, onde foi observado que parte do objetivo inicial da
sprint foi cumprido, com a finalização do primeiro requisito. Já o início do desenvolvimento
do segundo requisito teve que ser adiado para a próxima sprint, pois devido a demora em
iniciar o processo de desenvolvimento, a equipe decidiu começar um novo requisito com
tempo para que seja completado com sucesso.
Foram levantadas as tarefas concluídas e as horas que foram gastas para o primeiro
requisito, e assim como aconteceu na primeira Sprint, ocorreram divergências, que podem ser
vistas na Tabela 22.
Tabela 22 – Tarefas Finalizadas - Sprint 002
Estimado Gasto
001 Persistencia CRUD 1h 2h

002 Implementando as validações 5h 3h
003 Implementando as retrições\regras 8h 7h
004 Diagrama de Classes 1h 1h
005 Tela de Create 8h 19h05m
006 Tela de Editar 5h 8h
007 Tela de Visualizar 3h 6h45m
008 Tela de Listagem 13h 2h
009 Tela de Pré-Cadastro 2h 3h25m
010 Teste Create 3h 4h
011 Teste Visualizar 1h 0h25m
012 Teste pre-cadastro 1h 1h
013 Teste Editar 3h 4h
014 Teste Listagem 3h 0h10m
039 Criação de Layout 8h 16h
TOTAL 65h 77h50m
Foi observado também o gráfico Burndown da Sprint 002 para o requisito 001, como
pode ser visto na Figura 28. Pode-se perceber um avanço em horas desenvolvidas comparado
com o grafíco da primeira Sprint, na Figura 27.
112
Sendo assim, o requisito de cadastro mobiliário (User Story 001) foi considerado
completo pelo Product Owner. Ele também repassou com a equipe as informações sobre o
projeto, eliminando diversas dúvidas dos desenvolvedores sobre os próximos requisitos.
Figura 28 – Gráfico Burndown – Sprint 002.
3.6.3.2.5 Sprint Retrospective - Sprint 002
Sendo realizada no mesmo dia da Sprint Review, dia 17/12/2012, das 14h00min às
16h00min, a Sprint Retrospective, contou apenas com a equipe de desenvolvimento e o Scrum
Master, voltando a discutir sobre o processo de desenvolvimento que ocorreu durante a Sprint
002.
Primeiramente, foi discutido sobre os pontos negativos da segunda Sprint, que
reduziram em comparação à primeira. Foi apontado apenas as interrupções externas e os
projetos paralelos, que apesar dos esforços do Scrum Master e da equipe de desenvolvimento
para focar no projeto do DECA, acabaram atrapalhando o desenvolvimento. A mesma questão
será abordada novamente com a diretoria da empresa para que possa ser estudada uma
solução.
Comparando com os pontos negativos da Sprint 001, percebe-se que ocorreu uma
participação mais presente do Product Owner, solucionando assim o problema apresentado
113
pela a equipe. Também foi decidido pela equipe como terá que ser o processo de revisão dos
levantamentos de informações, no qual duas pessoas deveram ser responsáveis, uma levantará
as informações e a outra realizará a revisão, criando assim duas tarefas na Sprint. Por fim, a
equipe relatou que a comunicação interna melhorou muito, com todos se participativos e
trocando mais informação entre si.
Ao levantar os pontos positivos desta segunda sprint, foi apontado que além dos já
relatados na primeira Sprint, pode ser observado que:
o A comunicação melhorou muito;
o O compromentimento com o projeto aumentou;
o A equipe adquiriu mais confiança em utilizar a metodologia; e
o Os desenvolvedores ficaram mais familiarizados com os procedimentos.
Destes fatores apontados, é importante destacar que a partir do momento que a equipe
começou a se familiarizar com a metodologia ágil, será possível nas próximas Sprints notar as
mudanças que ocorrem do cenário inicial e ao cenário após a implantação do Scrum.
3.6.3.3 Sprint 003
Logo após a Sprint 002 finalizar, a equipe precisou ser realocada para atender um
desenvolvimento urgente, então ficou paralizado a continuação do projeto. Só depois de
finalizar está tarefa, ela pode ser realocada de volta para o projeto. Segue, nesta seção, um
relato do que ocorreu durante à sequência da terceira Sprint, conforme o ciclo de
desenvolvimento. A duração definida para a execução de cada sprint também foi de três
semanas.
No dia 07/01/2013, das 09h00min às 12h00min, iniciou-se a reunião de Release

Planning Meeting da Sprint 003, com a presença do Product Owner, Scrum Master e equipe
de desenvolvimento.
Ao fim da Sprint 002 não foi realizado o levantamento de informações,
documentações e modelagem para o desenvolvimento desta Sprint, pois a equipe notou que
seria mais fácil realizar o levantamento das informações e realizar o desenvolvimento na
mesma Sprint, evitando assim que o assunto tenha que ser revisto.
114
Esta dificuldade foi colocada ao Product Owner, que concordou em realizar tarefas
menores, que podem se encaixar em uma Sprint de 3 semanas tanto o levantamento quanto o
desenvolvimento. O Product Owner realizou uma revisão do Product Backlog, dividindo
algumas User Story grandes e as repriorizando.
A meta da Sprint 003 decidida na reunião ficou em realizar uma parte do cadastro que
envolve o regime de tributação de uma empresa. Sendo assim, busca-se realizar todo o
levantamento de requisitos, documentação, modelagem e desenvolvimento.
É importante ressaltar que, neste momento, a equipe já possui uma noção de como
seria o trabalho de levantamento e documentação, assim como o desenvolvimento em ASP.net
MVC ao contrário dos outros ciclos de desenvolvimento. A equipe acredita que com isto a
estimativa e o desenvolvimento será mais produtivo.
No mesmo dia do Release Planning Meeting, dia 07/01/2013, das 14h00min às

16h20min, desta vez com a participação apenas da equipe de desenvolvimento e o Scrum
Master, ocorreu a reunião Sprint Planning Meeting da Sprint 003, tendo como objetivo
planejar como será atingido a meta da Sprint, definindo quais as tarefas necessárias, criando o
Sprint Backlog da Sprint 003.
Desta vez, a equipe de desenvolvimento recebeu uma User Story totalmente nova,
com o objetivo de dividir em tarefas de levantamento, documentação, modelagem,
desenvolvimento e testes. A equipe conhecia quanto tempo iria ser necessário para cada uma
das tarefas, tanto de levantamento quanto desenvolvimento, devido suas experiências
anteriores. Sendo assim, a estimativa ocorreu sem muitas discussões em relação as
divergências de opiniões, mostrando que a equipe de desenvolvimento estava sincronizada.
As tarefas definidas e suas estimativas podem ser vistas na Tabela 23.
Tabela 23 - Sprint Backlog e suas respectivas estimativas – Sprint 003.

User Story 026 – Cadastro de contribuintes em relação a regime de tributação, de
classificação das empresas
01 Levantamento de Logica (Pub. Gerais) 2h
02 Documentação (Pub. Gerais) 2h
03 Modelagem de Banco de Dados (Pub. Gerais) 2h
04 Revisão da Modelagem de Banco de Dados (Pub. Gerais) 1h
05 Implementação (Pub. Gerais) 8h
115
06 Teste(Pub. Gerais) 2h
07 Levantamento de Logica (Ini. E Enc.) 5h
08 Documentação (Ini. E Enc.) 1h
09 Modelagem BD (Ini. E Enc.) 1h
10 Revisão da Modelagem de Banco de Dados (Ini. E Enc.) 1h
11 Implementação (Ini. E Enc.) 2h
12 Teste (Ini. E Enc.) 1h
13 Correções na tela de cadastro 2h
14 Levantamento\Organograma E1 3h
15 Documentação E1 2h
16 Modelagem BD E1 2h
17 Revisão de Modelagem E1 1h
18 Implementação E1 13h
19 Teste E1 3h
20 Levantamento\Organograma E2 3h
21 Documentação E2 2h
22 Modelagem BD E2 3h
23 Revisão de Modelagem E2 1h
24 Implementação E2 13h
25 Teste E2 3h
26 Documentação de bando de dados (E1 e E2) 2h
27 Adaptação Modelagem Antiga 3h
28 Revisão Modelagem de banco de dados. 1h
29 Correção do sistema em relação ao formato novo 2h
30 Tipo de Endereço - Levantamento 2h
31 Tipo de Endereço - Modelagem de banco de dados 1h
32 Tipo de Endereço - Documentação 1h
33 Tipo de Endereço - Revisão de Modelagem 1h
34 Tipo de Endereço - Implementação 7h
35 Tipo de Endereço - Teste 1h
36 Deleção dos dados no Banco de dados 1h
37 Revisão do Projeto 1h
TOTAL 102h
Conforme ocorreu na segunda reunião, a equipe não precisou tanto das intervenções
do Scrum Master, começando a seguir a reunião conforme o framework Scrum recomenda, de
forma mais objetiva. A quantidade de horas, ao fim da estimativa, foi menor que a Sprint
anterior, mas isto reflete também o amadurecimento da equipe em relação ao processo de
desenvolvimento. As tarefas foram adicionadas no quadro Kanban, assim como preparado o
Grafíco Burndown.
116
Durante o período de 08/01/2013 à 28/01/2013, ocorreu o desenvolvimento da Sprint

003. Assim, como foi feito nas duas primeiras sprints, ocorreu à documentação do diário de
bordo do período, como pode ser visto nas Tabelas 24, 25 e 26. A seguir apresenta-se a
Tabela 24, que corresponde ao diário de bordo da primeira semana da Sprint 003.
Tabela 24 - Diário de Bordo das Reuniões Diarias da Sprint 003 –08/01/2013 à 11/01/2013
Gráfico Burndown:
102 horas restantes.
Realizou-se um review das tarefas.
Desenvolvedor 04 irá trabalhar nas tarefas de levantamento e de
08/01/2013 modelagem de banco de dados. Enquanto o Desenvolvedor 01 está
09h30min às 09h45min terminando o levantamento de menus, tarefa que não fazer parte da
Sprint, e depois irá começar a fazer a tarefa de levantamento
de publicidade. O Desenvolvedor 02 entre hoje e amanhã estará
alocado para terminar as tarefas que ele tinha para desenvolver.
Interrupções:
Desenvolvedor 01 e 02 alocados em tarefas externas.
Gráfico Burndown:
O Desenvolvedor 01 terminou o levantamento sobre publicidade, e o
Desenvolvedor 04 a modelagem. O Desenvolvedor 02 continuou
alocado em uma tarefa externa.
09/01/2013
O Desenvolvedor 01 vai tentar trabalhar no levantamento de data
inicial e encerramento e o Desenvolvedor 04 irá finalizar a
documentação e executar a modelagem da etapa 1.
Interrupções:
O Desenvolvedor 02 continua alocado em tarefas externas.
Gráfico Burndown:
O Desenvolvedor 04 terminou sua parte, e agora só irá fazer a
revisão com o Scrum Master. O Desenvolvedor 02 começou a
realizar a tarefa de correção de itens anteriores, mas teve que ser
10/01/2013
alocado para realizar uma tarefa externa. O Desenvolvedor 01
continuou com suas tarefas alocadas.
O Desenvolvedor 01 irá terminar a documentação dos sistemas, e irá
desenvolver a modelagem da publicidade. O Desenvolvedor 04 irá
auxiliar nesta tarefa.
Interrupções:
117
O Desenvolvedor 02 foi interrompido no meio da execução de sua

tarefa a pedido da Diretoria.
Gráfico Burndown:
A situação do gráfico Burndown permaneceu o mesmo, pois não foi
O Desenvolvedor 04 e o Scrum Master revisaram as tarefas que
foram feitas afim de acompanhar o andamento. O Desenvolvedor 01
continua a executar a tarefa de documentação.
10h00min às 10h12min O Desenvolvedor 04 vai tentar trabalhar na tarefa de correção da
modelagem, o Desenvolvedor 02 irá finalizar a tarefa de correção
das telas de cadastro. O Desenvolvedor 01 irá trabalhar para realizar
a modelagem.
Interrupções:
O Desenvolvedor 02 estará ocupado todo o período com outras
tarefas externas.

Tabela 25 - Diário de Bordo das Reuniões Diarias da Sprint 003 – 14/01/2013 à18/01/2013
Gráfico Burndown:
O Desenvolvedor 01 terminou a parte de documentação. O
Desenvolvedor 02 estava ocupado realizando tarefas externas, e o
Desenvolvedor 04 está trabalhando na modelagem.
09h10min às 09h16min Desenvolvedor 02 irá realizar as correções no sistema e o
Desenvolvedor 01 irá implementar a parte de publicidade do
cadastro. O Desenvolvedor 04 ficou de terminar a modelagem e
depois revisar junto com o Scrum Master.
Interrupções:
Apenas o Desenvolvedor 02 teve pequenas interrupções do suporte.
Gráfico Burndown:
O Desenvolvedor 04 terminou a modelagem e depois ele e o Scrum
Master revisaram a modelagem. O Desenvolvedor 01 foi
15/01/2013
interrompido algumas vezes, mas está tendo que adaptar novamente
o sistema, pois teve mudanças no banco. O Desenvolvedor 02
praticamente terminou as correções.
Desenvolvedor 02 terá que adaptar as novas configurações do banco
na tela que ele corrigiu e como o Desenvolvedor 01 está ocupado
118
com algumas itens externos, ele irá corrigir o que o Desenvolvedor

01 não conseguir.
Interrupções:
Desenvolvedor 01 está ocupado com algumas tarefas externas.
Gráfico Burndown:
O Desenvolvedor 02 está terminando as correções e o
Desenvolvedor 01 estava realizando tarefas externas.
16/01/2013 Desenvolvedor 02 irá começar a verificar o que tem que ser
09h10min às 09h20min desenvolvido na primeira etapa do regime. O Desenvolvedor 1 irá
trabalhar nas tarefas de teste relacionadas ao que o Desenvolvedor
02 fez. Posteriormente, irá desenvolver a parte de início e
encerramento.
Interrupções:
Desenvolvedor 04 irá desenvolver tarefas externas, e irá atuar
apenas como ajudante dos dois outros desenvolvedores.
Gráfico Burndown:
O Desenvolvedor 01 teve alguns contra tempos, mas conseguiu
realizar as tarefas de testes e o Desenvolvedor 02 iníciou o
17/01/2013 desenvolvimento da etapa 1.
Desenvolvedor 01 irá realizar o desenvolvimento da parte de inicio e
fim e o Desenvolvedor 02 continuará a desenvolver a etapa 1.
Interrupções:
O Desenvolvedor 04 continuará alocado em outros projetos.
Gráfico Burndown:
O Desenvolvedor 01 terminou a implementação de Data Início e
Data Fim da Empresa, fez os testes da Publicidade e fez o
Levantamento dos tipos de endereço. O Desenvolvedor 02 continuou
a implementação da E1 (Tipo e Espécie de Estabelecimento e
18/01/2013
Classificação do Contribuinte), porém não finalizou.
Desenvolvedor 01 trabalhará a Documentação e a Modelagem dos
tipos de endereço. Desenvolvedor 02 terminará a implementação da
E1.
Interrupções:
O Desenvolvedor 04 continua alocado em outros projetos.
Por fim, a Tabela 26, que corresponde ao diário de bordo da terceira e última semana
da Sprint 003.
119
Gráfico Burndown:
O Desenvolvedor 01 terminou a Documentação e a Modelagem dos
tipos de endereço. Desenvolvedor 02 continuou o desenvolvimento
na implementação da E1 (Tipo e Espécie de Estabelecimento e
21/01/2013 Classificação do Contribuinte), porém não finalizou ainda e realizou
09h10min às 09h25min a revisão dos tipos de endereço junto ao Desenvolvedor 01.
O Desenvolvedor 01 trabalhará a Implementação dos tipos de
endereço. O Desenvolvedor 02 terminará a implementação da E1.
Interrupções:
Gráfico Burndown:
O Desenvolvedor 01 terminou a Implementação dos tipos de
endereço e realizou testes da implementação da E1. O
Desenvolvedor 02 terminou a Implementação do E1 iniciou o teste
das datas de início e data de fim.
22/01/2013
O Desenvolvedor 01 trabalhará na Implementação da E2. O
Desenvolvedor 02 terminará os testes sobre as implementações
feitas pelo Desenvolvedor 01, data início e fim e tipos de endereço.
Interrupções:
Gráfico Burndown:
O Desenvolvedor 01 começou a implementação da E2, porém não
finalizou. O Desenvolvedor 02 terminou os testes nas datas início e
encerramento, porém encontrou um problema de validação não
23/01/2013
ligado à Sprint, mas sim ao MVC3.
O Desenvolvedor 01 terminará a Implementação da E2. O
Desenvolvedor 02 trabalhara no teste do tipo de estabelecimento.
Interrupções:
Gráfico Burndown:
O Desenvolvedor 01 começou a implementação da E2, porém não
24/01/2013 terminou. O Desenvolvedor 02 terminou os testes nas datas início e
09h10min às 09h23min encerramento, porém encontrou um problema de validação não
ligado à sprint, mas sim ao MVC3.
O Desenvolvedor 01 terminará a Implementação da E2. O
Desenvolvedor 02 trabalhará o teste do tipo de estabelecimento.
120
Interrupções:
Gráfico Burndown:
O Desenvolvedor 01 e o Desenvolvedor 02 terminaram suas tarefas,
e alocaram a implementação do E2 juntos para poder terminar até o
prazo, devido às interrupções do Desenvolvedor 01 que não
conseguiu terminar até o prazo especificado e também devido à
25/01/2013 complexidade das requisições Ajax com o JQuery que foram
09h20min às 09h35min encontradas.
O Desenvolvedor 01 e o Desenvolvedor 02 terminarão a
Implementação da E2 e farão a tarefa de Teste no E2, assim
finalizando todas as tarefas.
Interrupções:
Conforme pode ser observado nas Tabelas 24, 25 e 26, diferentemente das outras
Sprints, o desenvolvimento começou logo no início da Sprint, o que foi o fator determinante
para que todas as tarefas tenham sido cumpridas. A equipe já possuía a maturidade de como
realizar a documentação e dos processos de desenvolvimento necessários, o que resultou em
um melhor aproveitamento da Sprint.
No meio da Sprint, o Desenvolvedor 04 precisou ser alocado em outros projetos,
deixando apenas dois desenvolvedores para finalizar a Sprint, o que ocorreu com o
consentimento do todos. A equipe neste momento começou a se auto gerenciar, descobrindo
seus limites e possibilidades de atuação.
3.6.3.3.4 Sprint Review - Sprint 003
Durante o dia 28/01/2013, das 09h00min às 11h00min, o time Scrum se reuniu para
realizar a Sprint Review da Sprint 003, onde foi observado que o objetivo inicial da sprint foi
cumprido, com a finalização de todas as tarefas.
Foram levantadas as tarefas concluídas e as horas que foram gastas para o requisito.
Percebe-se que, em poucos casos, ocorreram divergências, diferentemente das Sprints
anteriores, que podem ser vistas na Tabela 27. É possivel verificar que a equipe desenvolveu
em menos tempo que tinha sido estimado, devido estar se adaptando a tarefa de realizar a
estimativa, mas é possivel verificar que em alguns casos ficaram perto do ideal.
121
Tabela 27 – Tarefas Finalizadas - Sprint 003

Estimado Gasto
001 Levantamento de Logica (Pub. Gerais) 2h 1h15min
002 Documentação (Pub. Gerais) 2h 3h
003 Modelagem de Banco de Dados (Pub. Gerais) 2h 1h
004 Revisão da Modelagem de Banco de Dados (Pub. Gerais). 1h 15min
005 Implementação (Pub. Gerais) 8h 6h
006 Teste (Pub. Gerais) 2h 30min
007 Levantamento de Logica (Ini. E Enc.) 5h 1h
008 Documentação (Ini. E Enc.) 1h 20min
009 Modelagem BD(Ini. E Enc.) 1h 1h
010 Revisão da Modelagem de Banco de Dados (Ini. E Enc.) 1h 1h
011 Implementação (Ini. E Enc.) 2h 2h
012 Teste (Ini. E Enc.) 1h 40min
013 Correções na tela de cadastro 2h 3h30min
014 Levantamento\Organograma E1 3h 2h
015 Documentação E1 2h 2h
016 Modelagem BD E1 2h 2h
017 Revisão de Modelagem E1 1h 30min
018 Implementação E1 13h 18h
019 Teste E1 3h 30min
020 Levantamento\Organograma E2 3h 3h
021 Documentação E2 2h 30min
022 Modelagem BD E2 3h 2h
023 Revisão de Modelagem E2 1h 30min
024 Implementação E2 13h 12h
025 Teste E2 3h 1h23min
026 Documentação de bando de dados (E1 e E2) 2h 2h
027 Adaptação Modelagem Antiga 3h 3h
028 Revisão Modelagem de banco de dados. 1h 1h
029 Correção do sistema em relação ao formato novo 2h 4h
030 Tipo de Endereço - Levantamento 2h 1h
031 Tipo de Endereço - Modelagem de banco de dados 1h 1h
032 Tipo de Endereço - Documentação 1h 1h30min
033 Tipo de Endereço - Revisão de Modelagem 1h 30min
034 Tipo de Endereço -Implementação 7h 4h
035 Tipo de Endereço - Teste 1h 50min
036 Deleção dos dados no Banco de dados 1h 30min
037 Revisão do Projeto 1h 30min
TOTAL 102h 85h13min
122
Foi elaborado também o gráfico Burndown da Sprint 003 para o requisito 001, como
pode ser visto na Figura 29. Pode-se perceber um avanço em horas desenvolvidas comparado
com os grafícos das duas primeiras Sprint, na Figura 27 e Figura 28.
Figura 29 - Gráfico Burndown – Sprint 003
Sendo assim, o requisito de Cadastro de contribuintes em relação a regime de

tributação, de classificação das empresas (User Story 026) foi considerado completa pelo
Product Owner. Ele também repassou com a equipe as informações sobre o projeto,
eliminando diversas dúvidas dos desenvolvedores sobre os próximos requisitos.
3.6.3.3.5 Sprint Retrospective - Sprint 003
Sendo realizada no mesmo dia da Sprint Review, dia 28/01/2013, das 14h00min às
16h00min, a Sprint Retrospective contou apenas com a equipe de desenvolvimento e o Scrum
Master, voltando a discutir sobre o processo de desenvolvimento que ocorreu durante a Sprint
003.
Primeiramente, foi discutido sobre os pontos negativos da terceira Sprint, que
reduziram em comparação à segunda. As interrupções externas diminuiram e apenas um dos
desenvolvedores teve que ser alocado para outro projeto. Conforme foi conversado com a
123
diretoria, há um esforço para que este problema seja corrigido e algumas ações já vêm sendo
tomadas.
Sobre os pontos positivos que foram relatados, destaca-se que equipe se mostrou
satisfeita com a nova forma de realizar a revisão e a documentação no desenvolvimento, em
comparação com a Sprint 002. A comunicação entre a equipe continuou positiva, todos se
ajudando e colaborando. E como a equipe já conhecia como deveria atuar, tanto para
documentar quanto para desenvolver, ocorreu uma melhora na estimativa de horas, e a
velocidade de desenvolvimento aumentou.
Resumindo, os pontos positivos desta terceira sprint, foi apontado que além dos já
relatados nas primeiras Sprints, pode ser observado que:
o Aconteceu uma excelente comunicação entre o grupo;
o Aumento no compromentimento;
o Ocorreu um aumento na velocidade de desenvolvimento; e
o Os desenvolvedores conseguiram estimar melhor as tarefas.
Depois de apresentado a metodologia utilizada no estudo de caso, nas proximas seções
será apresentada os resultados da implantação da metodologia ágil Scrum em uma empresa de
pequeno/médio porte.
Capítulo
124
4 Resultados
Ao fim da realização dos primeiros ciclos de desenvolvimento, em que foram

relatadas as 3 primeiras Sprints, pôde ser observado o desenrolar da proposta de metodologia,
bem como os resultados obtidos durante o processo.
A abordagem proposta para a implantação de metodologia ágil, no estudo de caso
deste trabalho, pode ser comparada as características apresentadas na Tabela 6, que mostra
uma comparação entre Metodologias Ágeis e Tradicionais. As características da metodologia
proposta podem ser visualizadas na Tabela 28.
O objetivo desta comparação é destacar que a implantação da metodologia agil
apresentada no Capítulo 3, apesar de ser uma metodologia ágil (Scrum), teve que sofrer
adaptações para contemplar o cenário apresentado pelo estudo de caso escolhido.
Tabela 28 – Comparação da Metodologia Proposta x Tradicional x Ágil

Metodologia
Características Análise
Proposta
Definição de Escopo Ágil Objetivo era resolver o crítico primeiro
Planejamento do Ágil Adaptar-se a requisitos atuais que podem mudar

Desenvolvimento
Desenvolvimento do Sistema Tradicional /Ágil Realizar o controle para alcançar o objetivo

planejado, mas buscando a simplicidade no
desenvolvimento
Direcionamento da Metodologia Tradicional /Ágil Orientando as pessoas, mas criando alguns

processos para garantir a qualidade
Foco da Metodologia Tradicional /Ágil Utilizar mais comunicação interpessoal, sem

deixar de realizar uma documentação mínima em
paralelo
Considera-se como sucesso Ágil Entrega do desejado
Gerência de Projeto Ágil Liderança / Orientação a equipe de

desenvolvimento
125
Equipe de Desenvolvimento Ágil Desenvolvedor ágil
Perfil de cliente Ágil Cliente comprometido
Custo de Ágil Barato

Retrabalho/Reestruturação
Planejamento vs. Resultados Ágil Resultado direciona o planejamento
Valorização dos Resultados Tradicional Preocupação com a qualidade
Natureza do Projeto Ágil Foco em equipes pequenas e médias
Objetivo da Metodologia Ágil Simplificar processo de desenvolvimento
Como se pode observar, em alguns momentos, a metodologia proposta segue as

características da metodologia tradicional pela necessidade da empresa em possuir um
controle maior sobre o desenvolvimento ou exigir mais qualidade do produto a ser entregue.
As adaptações surgiram pela a necessidade da empresa em ter processos e documentação dos
projetos definidas, além da preocupação com a qualidade final.
Devido o projeto escolhido como estudo de caso ainda estar em fase de
desenvolvimento, não foi possivel realizar uma comparação direta em relação aos projetos
anteriores, considerando a redução de custos, agilidade no desenvolvimento e cumprimentos
de prazos.
A fim de definir um parâmetro de comparação com o cenário anterior ao da
implantação apresentada, foi realizada uma pesquisa, em formato de questionário (Survey),
onde foi possível observar a opinião dos envolvidos no processo.
4.1 Preparação do Questionário
A ideia de se realizar uma pesquisa padrão foi de coletar a opinião nos integrantes que
participaram do processo de utilização da metodologia ágil, realizando uma comparação entre
o desenvolvimento antes da implantação da metodologia ágil, em relação a depois da
implantação.
126
Foi necessário estabelecer as possíveis respostas dos participantes, a fim de realizar

uma padronização. Foram estabelecidas quatro tipos de respostas, conforme apresentado na
Tabela 29 e de acordo com a ideia apresentada por Fernandes et al. (2011).
Tabela 29 – Padrão de respostas ao questionário

Classificação Interpletação
S Satisfeito A situação atende ao item na maioria dos casos, ou seja, em pelo

menos 90% dos casos.
PS Parcialmente A situação atende parcialmente ao item, ou seja, acima de 60%
Satisfeito dos casos.
I Insatisfeito A situação não atende parcialmente ao item, ou seja, abaixo de 60
% dos casos.
D Desconhece Desconhece ou preferiu não avaliar.
Após definidos os critérios de avaliação, foram estabelecidos também as

características a serem observadas tanto antes da implantação da metodologia quanto depois.
A Tabela 30 destaca as características estabelecidas, seguidas de uma explicação sobre o sua
justificativa.
Tabela 30 – Características pesquisadas e suas justificativas

Caracteristicas Descrição
Comunicação da Equipe A fim de observar como foi à comunicação interna da

equipe durante o desenvolvimento
Motivação da Equipe Para observar como a equipe se comportava em relação aos

projetos, considerando a motivação dos integrantes da
equipe
Participação da Equipe Verificar se a equipe tinha uma participação satisfatória, de

forma pró-ativa, principalmente em relação ao
desenvolvimento do projeto
Comprometimento da Equipe Verificar se a equipe era realmente comprometida com os

projetos, com as responsabilidades das atividades bem
divididas e executadas
127
Documentação dos Sistemas Verificar se a houve melhora na documentação dos

sistemas dos projetos, tanto com quantitativa quanto
qualitativa
Desempenho no Observar qual era o desempenho (Planejamento X
Desenvolvimento Cumprimento) da equipe no desenvolvimento
Interrupções Verificar se existiam muitas interrupções externas no

processo de desenvolvimento, o que interfere
negativamento no desempenho do desenvolvimento
Testes Observar se houve melhora na realização das atividades de
testes de software e confiabilidade dos mesmos
Qualidade Verificar qual era a qualidade dos produtos desenvolvidos,

Se eles atendiam aos requisitos ou se possuiam muitos
problemas a serem resolvidos
Estimativa de Prazo Verificar se houve melhora na realização do processo de
estimativa de conclusão das atividades da equipe de
desenvolvimento
Atender ao Prazo de Entrega Observar se eram cumpridos os prazos estimados para o
desenvolvimento
Após definir os critérios de avaliação e suas respostas prévias, foi possível aplicar o
questionário aos funcionários envolvidos e verificar os resultados obtidos. O questionário, na
íntegra, pode ser visualizado no Apêndice A.
4.2 Resultados do Questionário
Após ser realizado o procedimento de elaboração do questionário e ter sido

estabelecido os critérios de avaliação, foram disponibilizado para os envolvidos responderem
sobre os itens estabelecidos.
Para demonstrar os resultados, foi adicionada uma sigla para cada entrevistado,
conforme definido na Tabela 31. A fim de destacar qual foi a importância de cada membro no
processo de implantação, os participantes foram classificados em Ativo (envolvidos
diretamente na implantação da metodologia, como por exemplo, analista de sistemas e
desenvolvedor) ou Passivo (envolvidos parcialmente na implantação da metodologia, como
por exemplo o proprietário da empresa).
128
Tabela 31 – Participantes do Questionário

Sigla Descrição Participação
E1 Desenvolvedor 01 Ativo
E5 Scrum Master Ativo
E6 Product Owner Ativo
E7 Diretoria Passivo
Na Tabela 32, são apresentados os resultados do questionário em relação ao processo

de desenvolvimento antes da implantação da metodologia. A avaliação final é uma média
ponderada de todos os resultados do item. Caso ocorra empate, foi considerado a classificação
mais baixa.
Tabela 32 – Resultado do Questionário - Antes da implantação da metodologia

Antes da implanção da Participantes Avaliação
metodologia ágil E1 E2 E3 E4 E5 E6 E7 Final
Comunicação da Equipe I S PS PS PS PS PS PS
Motivação da Equipe PS PS PS PS S S PS PS
Participação da Equipe S S S PS S S S S
Comprometimento da Equipe PS PS S PS PS PS S PS
Documentação dos Sistemas I I S I I I I I
Desempenho do Desenvolvimento I I S I I I PS I
Interrupções PS I I I I I I I
Testes I I PS I I I I I
Qualidade I I S I I I PS I
Estimativa de Prazo PS I PS I I I I I
Atender ao Prazo de Entrega I I I I I I I I
Na Tabela 33 é apresentado os resultados do questionário em relação considerando o

período após a implantação da metodologia ágil na empresa.
129
Tabela 33 - Resultado do Questionário - Depois da implantação da metodologia.

Depois da implanção da Participantes Avaliação
metodologia ágil E1 E2 E3 E4 E5 E6 E7 Final
Comunicação da Equipe S S S PS S S S S
Motivação da Equipe S S S PS S S S S
Participação da Equipe S S S PS S S S S
Comprometimento da Equipe S S S PS S S S S
Documentação dos Sistemas PS PS S PS PS PS PS PS
Desempenho do Desenvolvimento PS S PS PS PS PS PS PS
Interrupções PS PS PS PS PS PS PS PS
Testes PS S PS PS PS PS PS PS
Qualidade S S S PS PS PS S S
Estimativa de Prazo S PS PS PS S S S S
Atender ao Prazo de Entrega S S PS PS PS PS PS PS
Observando os dois cenários apresentados nas Tabelas 32 e 33, relatados pelos

participantes, pode-se observar a evolução do desenvolvimento com a nova abordagem. A
Tabela 34 apresenta um comparativo final entre os dois resultados, a fim de fornecer uma
oportunidade de análise mais consistente.
Tabela 34 – Comparação de resultados – Antes e Depois da Implantação da Metodologia Ágil.

Antes da Implantação Depois da Implantação
Comunicação da Equipe Parcialmente Satisfeito (PS) Satisfeito (S)
Motivação da Equipe Parcialmente Satisfeito (PS) Satisfeito (S)

Participação da Equipe Satisfeito (S) Satisfeito (S)
Comprometimento da Equipe Parcialmente Satisfeito (PS) Satisfeito (S)
Documentação dos Sistemas Insatisfeito (I) Parcialmente Satisfeito (PS)
Desempenho do Desenvolvimento Insatisfeito (I) Parcialmente Satisfeito (PS)
Interrupções Insatisfeito (I) Parcialmente Satisfeito (PS)
Testes Insatisfeito (I) Parcialmente Satisfeito (PS)
Qualidade Insatisfeito (I) Satisfeito (S)
Estimativa de Prazo Insatisfeito (I) Satisfeito (S)
Atender ao Prazo de Entrega Insatisfeito (I) Parcialmente Satisfeito (PS)
130
Em todos os casos, ocorreram mudanças positivas, se considerar a participação da

equipe que já era satisfatória. Os resultados também apotam uma melhora significativa na
qualidade e estimativa de prazo, que segundo relatos eram falhos ou não existentes quando
não se aplicava a metodologia ágil.
Os resultados apresentam também que o desempenho de toda a equipe de
desenvolvimento vem evoluindo, conforme acontecem os ciclos de interação. A melhora na
motivação, comprometimento e comunicação da equipe são fundamentais para que a
metodologia se torne mais presente na empresa.
No questinário realizado, foi oferecida uma oportunidade para os participantes
fornecerem as suas sugestões, opiniões ou críticas sobre a implantação da metodologia ágil,
sendo de grande importância para se entender o ambiente após a implantação.
Primeiramente, um dos resultados positivos que a equipe percebeu foi a melhora na
comunicação interna, em que todos começaram a trabalhar em conjunto para atingir um
objetivo. O grupo se tornou mais forte, no qual um companheiro começou a entender as
tarefas dos outros colegas, sabendo das qualidades, defeitos e no que ele poderia ajudar.
Além disso, os desenvolvedores reconheceram as falhas que vinham cometendo, por
falta de ter uma metodologia de desenvolvimento apoiando as tomadas de decisões de projeto.
Isto gerou um desejo nos funcionários e da direção de corrigir as falhas e se comprometer a
entrega de um produto com maior qualidade.
Em relação à utilização do quadro Kanban, a equipe de desenvolvimento aprovou a
sua utilização, onde notou-se uma maior facilidade de observar as tarefas em execução, o que
antes não era visível por todos os envolvidos. Ocorreram até recomendações para que se
utilizasse o Kanban para outros setores da empresa, como por exemplo, o suporte técnico
controlando as ordens de serviços.
Segundo relatos no questionário, as reuniões diárias adquiriram maior foco por serem
realizadas na frente do quadro, onde facilitava no entendimento das metas e tarefas restantes.
Outro ponto elogiado e que se demonstrou muito útil foi à utilização do Planning
Poker e do gráfico Burndown. Segundo a equipe, ao se realizar a estimativa de tempo das
tarefas com o baralho de Planning Poker, ocorreu um nivelamento de habilidades, no qual os
desenvolvedores com pouca experiência puderam expor suas dificuldades e, os mais
experientes, orientar em relação a qual o caminho a ser adotado. Além disto, a equipe elogiou
131
a efetividade que o gráfico Burndown fornece na hora de mostrar o andamento da Sprint e de

quantas tarefas ainda faltam para serem concluídas.
E por fim, um resultado positivo que pôde ser observado é a motivação da equipe em
encarar os novos projetos com o apoio da metodologia ágil, principalmente por ela gerar
confiança e oferecer ferramentas úteis para qualquer tipo de projeto, seja complexo ou não. A
motivação gerou comprometimento ao projeto, melhorando o seu desempenho. Durante a
implantação da metodologia não ocorreu resistência por parte da equipe, nas mudanças de
hábitos, pois segundo os desenvolvedores, sem metodologia de desenvolvimento, a
desorganização era muito grande, impedindo a evolução do desenvolvimento.
Por outro lado, foram observados pela equipe alguns pontos negativos durante a
execução das três sprints, principalmente causados por falta de experiência na equipe com o
processo. Foi destacada pela própria equipe que ela precisa melhorar os níveis de
comunicação interna para satisfazer os requisitos do Scrum, o que já buscou melhorar ao
longo da última Sprint apresentada.
Outro resultado negativo, não da metodologia, mas sim do ambiente de uma empresa
de pequeno e médio porte, é o excesso de interrupções externas. Por serem empresas com
poucos funcionários e, geralmente, cada um desempenhando mais de um papel na
organização, muitas vezes os desenvolvedores foram interrompidos para resolver questões
relacionadas a outros projetos.
Pela metodologia ágil necessitar que a equipe esteja focada no projeto, estas
interrupções externas atrapalham o andamento do projeto. Infelizmente, é complicado para os
próprios integrantes não pararem com o projeto para atender estas demandas extras, pois se
não fizerem não existirá ninguém para fazer. Estas situações não eram detectadas
anteriormente, por não ter nenhum tipo de avaliação e método de revisão dos processos
internos.
Com a metodologia ágil Scrum, foi possivel observar o desempenho e a evolução da
equipe na execução de cada uma das Sprints, conforme é apresentado na Tabela 35.
Tabela 35 – Desempenho da equipe.
Sprints Horas Horas Tarefas Tarefas Porc. de
Previstas Realizadas na Previstas Completadas Conclusão
Inicialmente Prática (%)
Sprint 01 81h 35h10 23 8 34,78%
Sprint 02 120h 77h50 39 16 41,02%
Sprint 03 102h 85h 37 37 100%
132
Nota-se que a equipe teve dificuldades nas duas Sprints iniciais em estimar as horas
necessárias para o desenvolvimento e de se adaptar a metodologia. Já na Sprint 03, com a
maturidade adquirida pela equipe, o andamento da Sprint aconteceu melhor do que o estimado
inicialmente.
Devido à falta de informações em relação aos projetos anteriores a implantação da
metodologia ágil, não foi possivel realizar uma comparação de melhorias alcançadas em
relação custos, recursos humanos e de tempo de desenvolvimento. No próximo capítulo serão
apresentadas as conclusões obtidas.
Capítulo
133
5 Conclusões
Foi observado que no cenário do desenvolvimento de software em empresas de

pequeno e médio porte, que foi relatado na seção 2.3, a existência de dificuldades no
desenvolvimento de seus produtos – atrasos na entrega do projeto, software com baixa
qualidade e falta de estimativa – que são causados, principalmente, pela falta de
gerenciamento nos processos. Isso gera a necessidade da utilização de processos simples e
ágeis para obter o controle do projeto de desenvolvimento, sendo adaptáveis as mudanças que
ocorrem com grande frequência.
Por meio da análise dos resultados do estudo de caso realizado neste trabalho, pôde-se
constatar que a implantação da metodologia ágil Scrum em conjunto com a técnica Kanban
em empresas de pequeno e médio porte se mostrou adequada para realizar o acompanhamento
na execução das atividades do desenvolvimento de software.
A metodologia ágil Scrum se mostrou ser fácil, quanto ao aprendizado, mas um pouco
complicada em sua utilização, por exigir muito controle de seus eventos e artefatos. Com uma
documentação mais simples, a comunicação tem que se tornar mais frequente entre os
participantes. A vantagem para as empresas de pequeno e médio porte é que elas geralmente
não possuíam documentações complexas. Sendo assim, elas se adaptam facilmente as regras
da metodologia.
O questionário aplicado na equipe após a implantação mostrou resultados positivos,
principalmente na melhoria da comunicação, na motivação e compromentimento da equipe e
da agilidade no desenvolvimento do software. Estes resultados foram fundamentais para que o
uso da metodologia continue sendo utilizada pela empresa.
Foram observados uma melhora nas estimativas de prazo, qualidade do produto e
realização de testes que, segundo a própria equipe está, evoluindo a cada projeto. Estes
resultados positivos resultam em uma eficiência maior no controle da utilização de recursos
humanos e de tempo nestes desenvolvimentos.
A única ressalva seria sobre o ambiente ter uma organização que permita a equipe
trabalhar focada nestes projetos na maior parte do tempo do dia. A metodologia Scrum é
flexível para tolerar algumas destas interrupções, mas não pode se tornar frequente no
134
ambiente de desenvolvimento. É necessario manter o controle da realização dos eventos e da

utiliação dos artefatos.
5.1 Trabalhos Futuros
Para realizar a continuidade desta pesquisa, o autor sugere a elaboração de um estudo

dos resultados obtidos após a implantação da metodologia, podendo assim realizar a
comparação de custos do projeto e aspectos humanos, em comparação a empresa antes da
implantação.
Seria interessante também realizar um acompanhamento de todas as Sprints de um
mesmo projeto, assim reunindo dados para que se possa fazer uma comparação completa da
evolução da equipe, nas dificuldades encontradas.
Em relação aos dados gerados pelo questionário e das sprints relatadas, seria
interessante realizar uma análise mais detalhada, utilizando gráficos de barras ou de linhas,
associando fatores numéricos nas respostas, com o objetivo de ampliar a visualização dos
resultados do estudo de caso.
5.2 Produções Científicas e Tecnológicas da Pesquisa
Durante a realização deste trabalho de conclusão de curso, foi submetido, aprovado e

apresentado um artigo intitulado “Aplicação de Metodologias Ágeis para Empresas de
Pequeno/Médio Porte” em um evento apoiado pela Sociedade Brasileira da Computação -
SBC, denominado IV Simpósio de Tecnologia da Informação do Noroeste do RS - STIN/RS
2013, realizado de 13 a 17 de Maio de 2013, em Cruz Alta - Rio Grande do Sul, Brasil (DA
SILVA; ROMANO, 2013).
135
Referências
ALMEIDA, M. I. R. Manual de Planejamento Estratégico. São Paulo: Editora Atlas, 2009.
AMBLER, Scott W. Lessons in Agility from Internet-Based Development. IEEE

Software. p. 66-73. 2004.
BECK, K. Programação Extrema (XP) explicada: acolha as mudanças. Bookman, Porto

Alegre, 2004.
BECK, Kent et al. Manifesto for agile software development. 2001. Disponível em:
<http://agilemanifesto.org> Acesso em: 10/01/2013.
BECK, K. Embracing Change with Extreme Programming. IEEE Computer. p. 70–77.

1999.
BERNI, Jean Carlo Albieri. Gestão para o processo de desenvolvimento de software

cientifica, utilizando uma abordagem ágil e adaptativa na micro empresa . 2010. 77f.
Dissertação de Mestrado (Mestrado) - Universidade Federal de Santa Maria, Rio Grande do
Sul.
BRANDINI, Roberto Provinciali. Funcionalidade Scrum (Ciclo) 2011. Disponível em:

< http://sbicse.wordpress.com/2011/04/30/funcionalidade-scrum-ciclo/>. Acesso em 12 jun.
2013.
BNDES. Classificação de Empresas. Disponível em:

<http://www.bndes.gov.br/SiteBNDES/bndes/bndes_pt/Navegacao_Suplementar/Perfil/porte.
html>. Acesso em: 20 nov. 2012.
BOEG, Jesper. Kanban em 10 passos. São Paulo: Infoq.com, 2012. 43 p. Disponível em:
<http://www.infoq.com/br/minibooks/priming-kanban-jesper-boeg>. Acesso em: 11 jun.
2013.
CAMARA, Fabio. Experimente um Projeto Ágil. 2005. Disponível em:

<http://www.linhadecodigo.com.br/artigo/1285/experimente-um-projeto-agil.aspx>. Acesso
em 24 mar. 2013.
CHAGAS, N. Melhoria do Processo de Desenvolvimento de Software em uma Pequena

Empresa Utilizando a Norma NBR ISO/IEC 12207. Maringá: Conclusão do curso de
Bacharelado em Informática, 2005. 56p. Cap. 4: Levantamento e Análise dos Dados Obtidos.
CHAOS MANIFESTO. Chaos Manifesto: The Laws of Chaos and the Chaos 100 best PM
Practices. The Standish Group, 2010.
COAD, P. Lefebvre, E.e DeLuca, J., Java Modeling in Color with UML, Prentice-Hall,
1999.
COCKBURN, A. Agile Software Development. Boston, Addison-Wesley, 2002.

136
CONFORTO, E.; AMARAL, D. Escritório de projetos e gerenciamento ágil: um novo

enfoque para a estrutura de apoio à gestão de projeto ágeis. Anais do Encontro Nacional
de Engenharia de Produção - ENEGEP, 2007.
CRUZ, Fabio. Artefatos Scrum: Gráfico Burndown. Disponível em:

<http://www.fabiocruz.com/outros/artefatos-scrum/>. Acesso em: 14 jun. 2013.
CSHARP. Linguagem C#. Disponível em:

<http://msdn.microsoft.com/pt-BR/vstudio/aa336809.aspx>. Acesso em: 15 jun. 2013.
DA SILVA, Alan Delgado; ROMANO Breno Lisi. Aplicação de Metodologias Ágeis para
Empresas de Pequeno/Médio Porte. In: IV Simpósio de Tecnologia da Informação do
Noroeste do RS - STIN/RS, 2013, Cruz Alta, 2013.
EXPRESS. Visual Studio Express. Disponível em:

<http://www.microsoft.com/visualstudio/ptb/products/visual-studio-express-products>.
Acesso em: 15 jun. 2013.
FERNANDES, B. B. et al. Metodologia FDD aplicada a especificação dos requisitos no

processo GRE do nível G de maturidade do modelo MPS.BR. In: ENCONTRO DE
COMPUTAÇÃO E INFORMÁTICA DO TOCANTINS, 13., 2011, Palmas. Anais... Palmas:
CEULP/ULBRA, 2011. p. 199-208. Disponível em <http://www.bandalerda.com.br/wp-
content/uploads/2011/11/Metodologia_FDD_aplicada_a_especificacao_dos_requisitos_no_pr
ocesso_GRE_do_nivel_G_de_maturidade_do_modelo_MPS_BR.pdf> Acesso em: 08 jul.
2013.
FOWLER, Martin. The New Methodology. 2005. Disponível em:

<http://www.martinfowler.com/articles/newMethodology.html>. Acessado em 24 março
2013.
GUERRA, C. A. et al. Implementação de boas práticas para o desenvolvimento de

software em micro e pequenas empresas brasileiras. In: Conferência IADIS IBERO-
AMERICANA WWW/INTERNET, 2008, Americana. Conferência IADIS Ibero
2008.Americanas: , 2008. p. 545 - 549.
HERBSLEB, James; MOITRA, Deependra. Global Software Development. IEEE Software,

California, v. 16, n. 2, p. 16-20, Mar. /Abr. 2001.
IBGE, As Micro e pequenas empresas comerciais e de serviços no Brasil. 2001. Rio de

Janeiro, 2003. Coordenação de Serviços e Comércio.
KNIBERG, H., SKARIN, M. Kanban e Scrum - obtendo o melhor de ambos. C4Media,

2009.
KNIBERG, H. Scrum e XP direto das Trincheiras. Como nós fazemos Scrum. C4Media,
2007.
137
LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e ao projeto

orientado a objetos e ao Processo Unificado. Trad. Luiz Augusto Meirelles Salgado e João
Tortello. 2 ed. Porto Alegre: Bookman, 2004.
LUDVIG, D., REINERT, J. Estudo do uso de Metodologias Ágeis no Desenvolvimento

de uma Aplicação de Governo Eletrônico. 2007. Conclusão do curso de Sistemas de
Informação - Universidade Federal de Santa Catarina. Florianópolis, 2007
LEAN. Lean Institute Brasil. Lean Thinking (Mentalidade Enxuta). Disponível em:
< http://www.lean.org.br/o_que_e.aspx> Acesso em: 08 jul. 2013.
LEITÃO, Michele de Vasconcelos. Aplicação de Scrum em Ambiente de Desenvolvimento

de Software Educativo. 2010. 72 f. Conclusão do curso de Engenharia da Computação -
Escola Politécnica de Pernambuco – Universidade de Pernambuco. Recife, 2010.
MACULAN, A. M. Ambiente empreendedor e aprendizado das pequenas empresas de

base tecnológica. In: LASTRES, H. M. M.; CASSIOLATO, J. E.; MACIEL, M. L. Pequena
empresa: cooperação e desenvolvimento local. Rio de Janeiro: Relume Dumará: UFRJ,
2003. p. 311-327.
MAGALHÃES, Ana Liddy C. C. O Gerenciamento de Projetos de Software

Desenvolvidos à Luz das Metodologias Ágeis. ProQuality (UFLA), Lavras-MG, v. 1, n.1, p.
29-46, 2004.
MARCH-CHORDÀ, I.; GUNASEKAN, A.; LLORIA-ARAMBURO, B. Product

development process in Spanish SMEs: an empirical research. Technovation, v. 22, n. 5,
p.301–312, 2002.
MELO, Claudia de O. ; SANTOS, Viviane A.; CORBUCCI, Hugo; KATAYAMA, Eduardo;

GOLDMAN, Alfredo; KON, Fabio. Métodos ágeis no Brasil: estado da pratica em times e
organizações. Relatório Técnico RT- MAC-2012-03. Departamento de Ciência da
Computação. IME-USP. Maio, 2012.
MVC. Asp.net MVC. Disponível em: < http://www.asp.net/mvc>. Acesso em: 15 jun. 2013.
ORACLE. Oracle Database. Disponível em:

<http://www.oracle.com/br/products/database/overview/index.html>. Acesso em: 15 jun.
2013.
PAULA, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões.

LTC Editora. Rio de Janeiro - RJ, 2001.
PEREIRA, Rodolfo M.; TAIT Tania F. C.; BRUZAROSCO, Donizete C. O Uso e

Desenvolvimento de Softwares em Micro e Pequenas Empresas. Maringá: Revista
Tecnológica Maringá, v. 19, p. 37-41, 2010.
PERUCH, Fernanda Pagnan. As Pequenas e Médias Eempresas (PMEs) e a Convergência

das Normas Contábeis ao Padrão Internacional: Uma Abordagem Geral. 2011. 201 f.
Conclusão do curso de Ciências Contábeis- Universidade Do Extremo Sul Catarinense –
Unesc, Criciúma, 2011.
138
POSTGRESQL. PostgreSQL Org. Disponível em: <http://www.postgresql.org>. Acesso em:

15 jun. 2013.
PRESSMAN, R. S. Engenharia de Software. 6º ed. Rio de Janeiro: McGraw-Hill, 2006.
PRESSMAN, R. S. Engenharia de Software. 5º ed. Rio de Janeiro: McGraw-Hill, 2002.
PRESSMAN, R. S. Software Engineering: A practitioner’s approach. McGraw-Hill. 4ª

Edição, 1997.
PRIKLADNICKI, R. MuNDDoS - Um Modelo De Referência

Para Desenvolvimento Distribuído De Software. 2003. 144f. Tese (Mestrado) -
Faculdade de Informática da Pontifícia Universidade Católica do Rio Grande do Sul,
Rio Grande do Sul.
SAVOINE, M.; et al. Análise de Gerenciamento de Projeto de Software Utilizando

Metodologia Ágil XP e Scrum: Um Estudo de Caso Prático. In: XI Encontro de Estudantes
de Informática do Tocantins, 2009, Palmas. Anais do XI Encontro de Estudantes de
Informática do Tocantins. Palmas: Centro Universitário Luterano de Palmas, 2009. p. 93-102.
SCHWABER K; SUTHERLAND J. Scrum Guide: Developed and sustained. Out. de 2011

Scrum.org.
SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2004.
SCHWABER, K.; BEEDLE, M. Agile Software Development with Scrum. Prentice-Hall,

Nova Jersey, 2002.
SEBRAE. Anuário do Trabalho na Micro e Pequena Empresa 2010 - 2011. São Paulo.
2011. Disponível em: <http://www.dieese.org.br/anu/anuSebraeMicroPeqEmp/
anuarioSebrae10-11.pdf>. Acesso em: 31 jan. 2013.
SEBRAE. Estudo da Atividade Empresarial Setor Calçadista – Fabricação de Calçados

Femininos – JAÚ – SP. São Paulo. Diagnóstico do APL Jaú. 2004. Disponível em:
<http://migre.me/d4wVE> Acesso em: 01 fev. 2013.
SILVA, F. G.; HOENTSCH, L Silva. Uma análise das Metodologias Ágeis FDD e Scrum
sob a Perspectiva do Modelo de Qualidade MPS.BR. Maringá: Scientia Plena, v. 5, 2009.
SIQUEIRA, H. Mapeamento das práticas de Scrum nas áreas de processo do CMMI e

uma proposta para sua aderência. Universidade Federal de Pernambuco, Trabalho de
Graduação em Ciência da Computação, 2007.
SIMPLISS. SIMPLISS Sistemas de Informação LTDA. Disponível em:

<http://www.simpliss.com.br>. Acesso em: 15 jun. 2013.
SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para
o Desenvolvimento de Software. Unipac - Universidade Presidente Antônio Carlos, 2004.
139
Disponível em: <http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf> . Acessado em 24

mar. 2013.
SQLSERVER. Microsoft SQL Server. Disponível em:

<http://www.microsoft.com/sqlserver/pt/br/default.aspx>. Acesso em: 15 jun. 2013.
STANDISH GROUP International, Inc., The, Extreme Chaos.Disponível em:

<http://www.cin.ufpe.br/~gmp/docs/papers/extreme_chaos2001.pdf>. Acesso em: Outubro
2012.
SUBVERSION. Apache SubVersion. Disponível em: <http://subversion.apache.org/>.

Acesso em: 01 fev. 2013.
TAKEUCHI, H.; NONAKA, I. The New Product Development Game. Harvard Business
Review. p. 137-146. 1986.
TEIXEIRA, Daniel D.;PIRES, Fernando J. A.; PINTO, José P. G. S.; SANTOS, Alexandre G.
P. DSDM – Dynamic Systems Development Methodology. 2005. 72 f. Faculdade de
Engenharia da Universidade do Porto. Porto, 2005.
TOLEDO, José C.; DA SILVA, Sérgio L.; MENDES, Glauco H. S; JUGEND, Daniel.
Fatores críticos de sucesso no gerenciamento de projetos de desenvolvimento de produto
em empresas de base tecnológica de pequeno e médio porte. Gest. Prod., São Carlos, v. 15,
n. 1, p. 117-134, jan.-abr. 2008.
TIEXAMES. Fundamentos do Scrum: Preparatório exame PSM I da Scrum.org. Disponível

em: <http://www.tiexames.com.br/curso_Scrum_Master.php>. Acesso em: 17 jun. 2013.
TORTOISESVN. TortoiseSVN. Disponível em: <http://tortoisesvn.net/downloads.html>.

VERSIONONE. State of Agile Development Survey Results.VersionOne. 2011.

Disponível em: <http://www.versionone.com/state_of_agile_development_survey/11/>
WEB-FORM. Asp.net Web Form. Disponível em: <http://www.asp.net/web-forms>. Acesso

em: 15 jun. 2013.
141
APÊNDICE A- Questionário de Avaliação da

Implantação das Metodologias Ágeis
QUESTIONÁRIO DE AVALIAÇÃO DA IMPLANTAÇÃO DAS METODOLOGIAS ÁGEIS
Com a justificativa de realizar uma análise dos resultados obtidos, a partir de

implantação da metodologia ágil na empresa SIMPLISS, solicita-se a colaboração dos
envolvidos no preenchimento deste formulário.
A pesquisa tem como objetivo comparar algumas características que eram encontradas
antes da implantação, e depois da implantação. O quadro abaixo mostram as características e
suas justificativas.
Caracteristicas Descrição
Comunicação da Equipe A fim de observar como foi à comunicação interna da equipe

durante o desenvolvimento.
Motivação da Equipe Para observar como a equipe se comportava em relação aos

projetos, considerando a motivação dos integrantes da
equipe.
Participação da Equipe Verificar se a equipe tinha uma participação satisfatória, de
forma pró-ativa, principalmente em relação ao
desenvolvimento do projeto.
Comprometimento da Equipe Verificar se a equipe era realmente comprometida com os
projetos, com as responsabilidades das atividades bem
divididas e executadas.
Documentação dos Sistemas Verificar se a houve melhora na documentação dos sistemas
dos projetos, tanto com quantitativa quanto qualitativa.
Desempenho do Observar qual era o desempenho (Planejamento X

Desenvolvimento Cumprimento) da equipe no desenvolvimento.
Interrupções Verificar se existiam muitas interrupções no processo de

desenvolvimento, o que interfere negativamento no
desempenho do desenvolvimento.
Testes Observar se houve melhora na realização das atividades de
testes de software e confiabilidade dos mesmos.
142
Qualidade Verificar qual era a qualidade dod produtos desenvolvidos,

se eles atendiam aos requisitos ou se possuiam muitos
problemas a serem resolvidos.
Estimativa de Prazo Verificar se houve melhora na realização do processo de
estimativa de conclusão das atividades da equipe de
desenvolvimento.
Atender ao Prazo de Entrega Observar se eram cumpridos os prazos estimados para o
desenvolvimento.
Para responder ao questionário, basta selecionar uma entre as 4 opções de respostas

que foram definidas abaixo:
Classificação Interpretação
S Satisfeito A situação atende o item na maioria dos casos, ou seja, em 90%

dos casos.
PS Parcialmente A situação atende parcialmente ao item, ou seja, acima de 60%
Satisfeito dos casos.
I Insatisfeito A situação não atende ao item, ou seja, abaixo de 60 % dos casos.
D Desconhece Desconhece ou preferiu não avaliar.
Segue na próxima folha o questionário.

Desde já agradeço sua participação!
Nome:__________________________________________________
1 – Como era o desenvolvimento dos projetos antes da

implantação da metodologia ágil?
Comunicação da Equipe Parcialmente

Satisfeito Insatisfeito Desconhece
Satisfeito
Motivação da Equipe Parcialmente

Satisfeito
Participação da Equipe Parcialmente

Satisfeito
Comprometimento da Equipe Parcialmente

Satisfeito
Documentação dos Sistemas Parcialmente

Satisfeito
Desempenho do Parcialmente
Satisfeito
143
Desenvolvimento
Interrupções Parcialmente
Satisfeito
Testes Parcialmente
Satisfeito
Qualidade Parcialmente
Satisfeito
Estimativa de Prazo Parcialmente

Satisfeito
Atender ao Prazo de Entrega Parcialmente

Satisfeito
2 – Como ficou depois da implantação da metodologia ágil?
Comunicação da Equipe Parcialmente

Satisfeito
Motivação da Equipe Parcialmente

Satisfeito
Participação da Equipe Parcialmente

Satisfeito
Comprometimento da Equipe Parcialmente

Satisfeito
Documentação dos Sistemas Parcialmente

Satisfeito
Desempenho do Parcialmente
Satisfeito Satisfeito Insatisfeito Desconhece
Desenvolvimento
Interrupções Parcialmente
Satisfeito
Testes Parcialmente
Satisfeito
Qualidade Parcialmente
Satisfeito
Estimativa de Prazo Parcialmente

Satisfeito
Atender ao Prazo de Entrega Parcialmente

Satisfeito
3- Alguma sugestão, critica ou opinião sobre o processo?

(Opcional)

2013 - 1sem - Alan Delgado Da Silva

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

2013 - 1sem - Alan Delgado Da Silva

Enviado por

Direitos autorais:

Formatos disponíveis

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

Aplicação de Metodologias Ágeis para Empresas de Pequeno/Médio Porte

Trabalho de conclusão de curso apresentado ao Instituto Federal de

Área de Concentração: Engenharia de Software

Orientador: Prof. Breno Lisi Romano

São João da Boa Vista

Ficha catalográfica preparada pela Seção de Tratamento

Trabalho de Conclusão de Curso, IFSP, 2013.

1. Metodologia Ágil. 2. Scrum. 3. Empresa de

I. Aplicação de Metodologias Ágeis para Empresas

Ao professor e orientador Breno Lisi Romano por seu apoio e inspiração no

A empresa SIMPLISS por acreditar e apoiar financeiramente a minha iniciativa de

DA SILVA, Alan Delgado. (2013). Aplicação de Metodologias Ágeis para Empresas de

Este trabalho tem como objetivo apresentar à implantação de metodologias ágeis em

Palavras-chave: Metodologia Ágil. Scrum. Empresa de Pequeno/Médio Porte. Gerência de Projetos.

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

et al. (2012). ......................................................................................................................................... 56

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 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

adaptada: SEBRAE (2011). ................................................................................................................. 28

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 17 – Tarefas Finalizadas – Sprint 001 .................................................................................... 100

Tabela 22 – Tarefas Finalizadas - Sprint 002 ..................................................................................... 111

Tabela 23 - Sprint Backlog e suas respectivas estimativas – Sprint 003............................................ 114

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

ABRASF Associação Brasileira das Secretarias de Finanças das Capitais

BNDES Banco Nacional de Desenvolvimento Econômico e Social