Dissertação - Benefícios e Limitações Das Metodologias Ágeis No Desenvolvimento de Software

Pós-Graduação em Ciência da Computação
“Benefícios e Limitações das Metodologias

Ágeis no Desenvolvimento de Software”
Por
Fernando Kenji Kamei
Dissertação de Mestrado
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE, AGOSTO/2012
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
FERNANDO KENJI KAMEI
“BENEFÍCIOS E LIMITAÇÕES DAS METODOLOGIAS ÁGEIS NO

DESENVOLVIMENTO DE SOFTWARE"
ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO

EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE
INFORMÁTICA DA UNIVERSIDADE FEDERAL DE
PERNAMBUCO COMO REQUISITO PARCIAL PARA
OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA
COMPUTAÇÃO.
ORIENTADOR: PROF. ALEXANDRE MARCOS LINS DE

VASCONCELOS
CO-ORIENTADOR: PROF. FÁBIO QUEDA BUENO DA SILVA
RECIFE, AGOSTO/2012
Catalogação na fonte
Bibliotecária Jane Souto Maior, CRB4-571
Kamei, Fernando Kenji

Benefícios e limitações das metodologias ágeis no
desenvolvimento de software / Fernando Kenji Kamei. -
Recife: O Autor, 2012.
xiv, 141 p.: il., fig., tab., quadro
Orientador: Alexandre Marcos Lins de Vasconcelos.

Dissertação (mestrado) - Universidade Federal de Pernambuco. CIn,
Ciência da Computação, 2012.
Inclui bibliografia e apêndice.
1. Engenharia de software. 2. Metodologias ágeis. I. Vasconcelos,

Alexandre Marcos Lins de (orientador). II. Título.
005.1 CDD (23. ed.) MEI2012 – 149

Dissertação de Mestrado apresentada por Fernando Kenji Kamei à Pós-
Graduação em Ciência da Computação do Centro de Informática da
Universidade Federal de Pernambuco, sob o título “Benefícios e Limitações
das Metodologias Ágeis no Desenvolvimento de Software” orientada pelo
Prof. ALEXANDRE MARCOS LINS DE VASCONCELOS e aprovada pela
Banca Examinadora formada pelos professores:
__________________________________________________
Prof. Sergio Castelo Branco Soares
Centro de Informática / UFPE
__________________________________________________
Prof. Cristine Martins Gomes de Gusmão
Núcleo de Telessaúde / UFPE
__________________________________________________
Prof. Alexandre Marcos Lins de Vasconcelos
Centro de Informática / UFPE
Visto e permitida a impressão.

Recife, 29 de agosto de 2012
___________________________________________________
Prof. Nelson Souto Rosa
Coordenador da Pós-Graduação em Ciência da Computação do
Centro de Informática da Universidade Federal de Pernambuco.
i
Dedico este trabalho aos meus
queridos pais, por toda a dedicação
e amor aos seus filhos, sem os quais
nada disso se tornaria realidade.
ii
AGRADECIMENTOS
Agradeço aos meus queridos pais por todo amor, carinho, dedicação e
ensinamentos que sempre me deram, pois foram essenciais para a realização
deste trabalho. Nada disso seria possível sem vocês.
Aos meus queridos irmãos que mesmo distantes sempre estiveram em meus
pensamentos. Obrigado por todo o apoio e incentivo. Aos meus queridos
sobrinhos, Hideki e Lis, que me trouxeram muita alegria.
Ao professor Alexandre Marcos Lins de Vasconcelos por todo o seu apoio,

oportunidade, incentivo e ensinamentos para esta pesquisa; direcionamentos
para minha vida profissional, que abriram novos caminhos e horizontes.
Ao professor Fabio Queda Bueno da Silva por todo o seu apoio, ensinamentos
e disponibilidade, fundamentais para o meu crescimento e desenvolvimento
desta pesquisa.
Aos amigos da pós-graduação: Fernando Selleri, Ivanildo Monteiro e Elisa

Sattyam por todas as contribuições e apoio; dos grupos de pesquisa HASE e
PROMISE pelas dúvidas tiradas, apoio e aprendizado; do laboratório de
Engenharia de Software, Felipe Buarque, Leonardo Fernandes, Weslley Torres,
João Paulo, Diego Dias, Benito, Marcio Ribeiro, Laís Neves, Rodrigo Cardoso e
Liliane Sheyla, por toda a amizade e momentos de descontração; Obionor
Nóbrega e Marco Domingues pelas conversas nas madrugadas e conselhos;
das disciplinas, Salânio Júnior, Dener Didoné, Fernando Kakimoto e Tassio
Vale por toda amizade e conhecimento adquirido juntos.
Aos amigos: Mario Godoy pelo apoio e orientação desde o início do mestrado;
ao Felipe Furtado, por toda amizade, apoio, colaboração, oportunidade e
aprendizado.
Aos amigos do Agilidade na Prática por todo aprendizado adquirido e amizade:

Teresa Maciel, Rodrigo Cursino e Luís Sanches.
iii
Às empresas e entrevistados “anônimos” por toda paciência e disponibilidade
em contribuir com a pesquisa, o que possibilitou uma maior riqueza nos dados
coletados.
Aos amigos Raphael e Jefferson do “ap” do CDU por toda amizade, apoio e
compreensão.
Aos amigos do IF-Sertão (Ouricuri) por todo apoio e compreensão: Maílson

Couto, Jean Carlos e Mabele de Jesus.
Por fim, agradeço aos professores da banca, pois seus comentários permitiram
a melhoria deste trabalho. À FACEPE pela bolsa concedida durante o período
do curso e ao INES por toda a infraestrutura disponibilizada do laboratório de
Engenharia de Software.
iv
RESUMO
As Metodologias Ágeis emergiram nos últimos anos em busca de melhor

qualidade no desenvolvimento de software. No entanto, estudos afirmam que
rigorosas pesquisas empíricas sobre a efetividade dessas metodologias ainda
são escassas e que pouco ainda se sabe sobre como estas estão sendo
conduzidas na prática. Com base nestes problemas, este trabalho objetivou
identificar os benefícios e as limitações das Metodologias Ágeis existentes na
literatura e em um conjunto de empresas de desenvolvimento de software do
Porto Digital de Pernambuco, objetivando um estudo comparativo. Os métodos
de pesquisa utilizados foram: survey para mapear as empresas do Porto Digital
de Pernambuco que utilizam Metodologias Ágeis; Revisão Sistemática da
Literatura para identificar os benefícios e as limitações das Metodologias Ágeis
na literatura; Estudos de Casos múltiplos em duas empresas de
desenvolvimento de software do Porto Digital de Pernambuco. Os resultados
da pesquisa foram: identificadas 30 empresas do Porto Digital de Pernambuco
que utilizam as Metodologias Ágeis; Na Revisão Sistemática da Literatura
foram identificados 6.856 estudos. Entre estes, 125 estudos primários que
passaram por uma avaliação da qualidade foram incluídos para serem
analisados em profundidade; Os resultados dos estudos de caso foram obtidos
a partir de 22 entrevistas realizadas em duas empresas. Com base nos
resultados obtidos, percebe-se que diversos benefícios e limitações foram
identificados, muitas vezes semelhantes entre a literatura e os estudos de
caso. Os principais benefícios da literatura e dos estudos de caso incluem a
melhoria na comunicação das equipes, a facilidade de compartilhar o
conhecimento e de acompanhar e monitorar os projetos. A principal limitação
da literatura e que exige atenção, foi a carência de estudos empíricos com as
metodologias ágeis e para os estudos de caso foi a dificuldade de trabalhar
com equipes grandes.
Palavras-Chave: Metodologias Ágeis, Revisão Sistemática da Literatura,

Estudos de Caso.
v
ABSTRACT
Agile methodologies have emerged in recent years in search of better quality in

software development. However, studies claim that rigorous empirical research
on the effectiveness of those methodologies are still scarce and little is known
about how these methodologies are conducted in practice. According to these
problems, this work aimed to identify the benefits and limitations of Agile
Methodologies in the literature and in a set of software development companies
of Porto Digital in Pernambuco, in order to have a comparative study. The
methods of research were: a survey to map the companies in the Porto Digital
of Pernambuco that use Agile Methodologies; a Systematic Literature Review to
identify the benefits and limitations of Agile Methodologies; and multiple-case
studies in two software development companies of Porto Digital in Pernambuco.
As result of the research: the research was found 30 companies using the Agile
Methodologies were identified in the Porto Digital of Pernambuco, Systematic
Literature Review identified 6856 studies, among which 125 primary studies
were included to be analyzed in depth, having undergone a quality assessment
and the results of case studies were obtained from 22 interviews in two
companies. According to the results gained, several benefits and limitations
were identified, often similar between the literature and case studies. The main
benefits of literature and case studies include improved communication teams,
the ease of sharing knowledge and tracking and monitoring projects. The main
limitation to the study of the literature that require more attention was the lack of
empirical studies with agile methodologies and case studies was the difficult to
working in a large teams.
Keywords: Agile Methodologies, Systematic Literature Review, Case Studies.
vi
LISTA DE FIGURAS
Figura 1 – Ciclo da pesquisa ............................................................................ 23

Figura 2 – Porcentagem de empresas que utilizam uma Metodologia Ágil ...... 39
Figura 3 – Metodologias Ágeis utilizadas pelas empresas ............................... 40
Figura 4 – Práticas ágeis utilizadas pelas empresas ........................................ 40
Figura 5 – Tempo de uso das Metodologias pelas empresas .......................... 41
Figura 6 – Quantidade de projetos que as empresas possuem ....................... 41
Figura 7 – Quantidade de projetos que utilizam metodologias ágeis ............... 42
Figura 8 – Quantidade de projetos finalizados utilizando uma Metodologia Ágil
......................................................................................................................... 42
Figura 9 – Resultado do processo de busca e seleção nas fontes de pesquisa
......................................................................................................................... 47
Figura 10 – Resultado da busca automática .................................................... 48
Figura 11 – Resultado da busca manual .......................................................... 49
Figura 12 – Métodologias Ágeis investigadas pelos estudos ........................... 52
Figura 13 – Distribuição temporal dos estudos primários................................. 53
Figura 14 – Pontuação de cada critério da avaliação da qualidade ................. 58
Figura 15 – B1. Facilita o compartilhamento do conhecimento entre a equipe 61
Figura 16 – B2. Melhora a comunicação da equipe ......................................... 64
Figura 17 – B3. Facilita o acompanhamento e monitoramento do projeto ....... 66
Figura 18 – B4. Feedback rápido/frequente ..................................................... 69
Figura 19 – B5. Melhora a qualidade do código ............................................... 70
Figura 20 – B6. Permite uma maior colaboração entre a equipe ..................... 73
Figura 21 – B7. Aumenta a produtividade da equipe ....................................... 75
Figura 22 – B8. Melhora a comunicação entre o cliente (ou representante) e a
equipe .............................................................................................................. 78
Figura 23 – B9. Entrega frequente de software funcional ................................ 79
Figura 24 – B10. Melhora a qualidade do projeto............................................. 81
Figura 25 – B11. Reduz a documentação ........................................................ 83
Figura 26 – B12. Reduz a complexidade do código/projeto ............................. 84
Figura 27 – B13. Reduz a quantidade de defeitos/erros no projeto ................. 86
Figura 28 – B14. Melhora o entendimento sobre o projeto .............................. 87
Figura 29 – B15. Facilita a interação entre a equipe ........................................ 89
Figura 30 – Quantidade de benefícios da literatura por Metodologia Ágil ........ 91
Figura 31 – L3. Aspectos culturais ................................................................... 97
Figura 32 – L4. Dificuldade em aplicar práticas ágeis com equipes
inexperientes em Metodologias Ágeis .............................................................. 99
Figura 33 – Quantidade de limitações da literatura por Metodologia Ágil ...... 112
Figura 34 – B1_EC. Facilita o acompanhamento e monitoramento do projeto
....................................................................................................................... 127
Figura 35 – B2_EC. Facilita o compartilhamento do conhecimento entre a
equipe ............................................................................................................ 130
vii
Figura 36 – B3_EC. Facilita a interação entre a equipe ................................. 135
Figura 37 – B4_EC. Melhora o entendimento das histórias de usuários ........ 137
Figura 38 – B5_EC. Facilita a resolução de problemas ................................. 140
Figura 39 – B6_EC. Melhora a comunicação da equipe ................................ 142
Figura 40 – B7_EC. Permite uma maior colaboração entre a equipe ............ 145
Figura 41 – B8_EC. Melhora a comunicação entre o cliente (ou representante)
e a equipe....................................................................................................... 148
Figura 42 – B10_EC. Melhora a qualidade do código .................................... 151
Figura 43 – L1_EC. Dificuldade para se trabalhar com equipes grandes ...... 153
viii
LISTA DE QUADROS
Quadro 1 – Diferenças entre este trabalho e o de Dybå e Dingsøyr (2008) ..... 16

Quadro 2 – Diferenças entre este trabalho e o de Petersen e Wohlin (2009) .. 18
Quadro 3 – Quadro metodológico .................................................................... 21
Quadro 4 – Classificação da revisão da literatura ............................................ 27
ix
LISTA DE TABELAS
Tabela 1 – Valores de Concordância do índice Kappa (LANDS e KOCH, 1977)

......................................................................................................................... 50
Tabela 2 – Distribuição dos estudos por conferências ..................................... 53
Tabela 3 – Distribuição dos estudos por periódico ........................................... 55
Tabela 4 – Distribuição dos estudos por método de pesquisa ......................... 56
Tabela 5 – Distribuição da pontuação por Faixa de Qualidade ........................ 58
Tabela 6 – Quinze principais benefícios identificados nos estudos primários .. 60
Tabela 7 – Quinze principais limitações identificadas nos estudos primários .. 92
Tabela 8 – Descrição do foco das limitações empíricas ................................... 93
Tabela 9 – Mapeamento entre os benefícios identificados por Dybå e Dingsøyr
(2008) e esta revisão ...................................................................................... 118
Tabela 10 – Mapeamento entre as limitações identificadas por Dybå e Dingsøyr
(2008) e esta revisão ...................................................................................... 120
Tabela 11 – Características das empresas .................................................... 121
Tabela 12 – Características dos entrevistados do projeto ALFA_P1 ............. 123
Tabela 13 – Características dos entrevistados do estudo de caso BETA_P1 124
Tabela 14 – Características dos entrevistados do estudo de caso BETA_P2 125
Tabela 15 – Dez principais benefícios identificados nos estudos de caso ..... 126
Tabela 16 – Dez principais limitações identificadas nos estudos de caso ..... 152
Tabela 17 – Mapeamento entre os benefícios dos estudos de caso e da
literatura ......................................................................................................... 169
Tabela 18 – Mapeamento entre as limitações dos estudos de caso e da
literatura ......................................................................................................... 171
Tabela 19 – Referência bibliográfica dos estudos primários .......................... 220
Tabela 20 – Características dos estudos primários da revisão ...................... 240
Tabela 21 – Resultado da Avaliação da Qualidade dos Estudos Primários ... 260
Tabela 22 – Benefícios identificados nos estudos primários .......................... 265
Tabela 23 – Limitações identificadas nos estudos primários ......................... 271
Tabela 24 – Benefícios identificados nos estudos de caso ............................ 275
Tabela 25 – Limitações identificadas nos estudos de caso ............................ 280
x
LISTA DE ABREVIATURAS / ACRÔNIMOS
ASD – Adaptative Software Development

DDS – Desenvolvimento Distribuído de Software
DSDM – Dynamic Systems Development Method
PO – Product Owner
SLR – Sistematic Literature Review
TDD – Test Driven Development
XP – Extreme Programming
xi
SUMÁRIO
1 INTRODUÇÃO 1
1.1 Definição do problema 2
1.2 Motivação 2
1.3 Questões de pesquisa 2
1.4 Objetivo Geral 3
1.4.1 Objetivos Específicos 3
1.5 Contexto 4
1.6 Contribuições e Resultados esperados 4
1.7 Estrutura do trabalho 4
2 REVISÃO DA LITERATURA 6
2.1 Referencial teórico 6
2.1.1 Metodologias Ágeis 7
2.1.2 Estatísticas com as Metodologias Ágeis 8
2.1.3 Extreme Programming (XP) 9
2.1.4 Scrum 11
2.2 Soluções alternativas 13
2.2.1 Agile methods rapidly replacing traditional methods at Nokia: A survey
of opinions on agile transformation (LAANTI et al., 2011) 13
2.2.2 Usage and Perceptions of Agile Software Development in an Industrial
Context: An Exploratory Study (BEGEL e NAGAPPAN, 2007) 14
2.3 Trabalhos Relacionados 14
2.3.1 Empirical studies of agile software development: A systematic review
(DYBÅ e DINGSØYR, 2008) 15
2.3.2 A Comparison of Issues and Advantages in Agile and Incremental
Development between State of the Art and an Industrial Case (PETERSEN e
WOHLIN, 2009) 17
2.4 Resumo 18
3 METODOLOGIA DA PESQUISA 20
3.1 Quadro metodológico 20
3.2 Ciclo da pesquisa 22
3.2.1 Procedimento de coleta dos dados 24
3.3 Resumo 37
4 RESULTADOS 38
xii
4.1 Síntese dos resultados da aplicação dos questionários 38
4.1.1 Resultados da aplicação dos questionários 38
4.1.2 Análise e discussão dos resultados 43
4.2 Síntese dos Resultados da Revisão Sistemática 45
4.2.1 Resultados do procedimento de Busca e Seleção 45
4.2.2 Mapeamento das evidências 59
4.3 Síntese dos resultados dos Estudos de Caso 120
4.3.1 Descrição dos estudos de caso 121
4.3.2 Mapeamento das Evidências 125
4.4 Síntese da comparação: Revisão Sistemática da Literatura versus
Estudos de Caso 168
4.4.1 Mapeamento das Evidências 169
4.5 Resumo 173
5 CONSIDERAÇÕES FINAIS 175
5.1 Limitações e Ameaças à Validade 175
5.2 Implicações para a pesquisa e prática 177
5.3 Lições aprendidas 177
5.4 Recomendações para Trabalhos Futuros 178
5.5 Conclusões 179
REFERÊNCIAS 180
APÊNDICE A – Questionário para mapeamento das empresas do Porto Digital
186
APÊNDICE B – Protocolo da Revisão Sistemática da Literatura 190
APÊNDICE C – Roteiro das Entrevistas 211
APÊNDICE D – Termo de Sigilosidade da Empresa 216
APÊNDICE E – Termo de Sigilosidade do Entrevistado 218
APÊNDICE F – Estudos primários da Revisão Sistemática da Literatura 220
APÊNDICE G – Características dos estudos primários 240
APÊNDICE H – Resultado da Avaliação da Qualidade dos Estudos Primários
260
APÊNDICE I – Benefícios identificados nos estudos primários 265
xiii
APÊNDICE J – Limitações identificadas nos estudos primários 271
APÊNDICE K – Benefícios identificados nos estudos de caso 275
APÊNDICE L – Limitações identificadas nos estudos de caso 280
xiv
1 INTRODUÇÃO
Em razão do rápido crescimento da indústria de software, juntamente com o
aumento da demanda por soluções cada vez mais robustas e, ainda, com
requisitos mutáveis, a busca por excelência e melhoria contínuas da qualidade
de software tem aumentado ao longo do tempo (CHOW e CAO, 2008). Neste
contexto, Teixeira e Delamaro (2008) afirmam que diversos métodos, técnicas
e ferramentas têm sido propostos e utilizados, visando a aumentar a
produtividade no desenvolvimento de software.
Sommerville (2011) afirma que existe uma estreita relação entre a
qualidade de um processo de desenvolvimento de software e a qualidade dos
produtos desenvolvidos por meio deste processo. Tal relação pode ser apoiada
por uma metodologia que, segundo Fowler (2005), é uma abordagem
disciplinada para o desenvolvimento de software, com o objetivo de tornar o
processo mais previsível e eficiente. No entanto, nem todas as metodologias
têm sido adequadas, pois ainda existe uma alta taxa de insucesso no
desenvolvimento de software, atribuída principalmente à complexidade das
metodologias tradicionais, por estas realizarem um levantamento completo dos
requisitos e, ainda, pela dificuldade que elas apresentam em lidar com as
mudanças trazidas pela dinâmica e evolução do ambiente de negócios (HO,
2006 et al; FERREIRA e COHEN, 2008).
Com intuito de eliminar os problemas causados pelas metodologias
tradicionais, surgiram as Metodologias Ágeis, que possuem processos flexíveis
e adaptativos e que aceitam as mudanças como parte inseparável do seu
processo de desenvolvimento, visando à melhoria na qualidade de software e
ao aumento da satisfação do cliente (HIGHSMITH, 2000).
Segundo Ferreira e Cohen (2008), existem vários relatos na literatura de
que estas metodologias diminuem as taxas de insucesso dos projetos de
software. Porém, os autores afirmam que as pesquisas empíricas sobre a
efetividade dessas metodologias ainda são escassas, pois a maioria é de
natureza exploratória.
Esse mesmo problema é relatado no trabalho de Dybå e Dingsøyr
(2008), que afirmam que pouco ainda se sabe sobre como essas metodologias
estão sendo conduzidas na prática e quais são os seus efeitos. Por esta razão,
1
Strode et al. (2009) afirmam que rigorosas pesquisas empíricas com tais
metodologias são importantes para comprovarem a sua eficácia.
De modo a permitir a reduzir esta problemática, esta pesquisa conduziu
um estudo secundário baseado em uma revisão sistemática da literatura para
compreender melhor, através das evidências empíricas, os benefícios e as
limitações que são derivadas devido ao uso das Metodologias Ágeis no
desenvolvimento de software. Ainda, investigou estudos de casos múltiplos em
duas empresas de desenvolvimento de software do Porto Digital de
Pernambuco, de modo a obter resultados sobre essas metodologias na prática.
1.1 Definição do problema

Mesmo com a ascensão do uso das Metodologias Ágeis em projetos de
desenvolvimento de software, autores afirmam que pouco ainda se sabe como
essas metodologias estão sendo conduzidas na prática e quais são os seus
efeitos. Tais metodologias carecem de estudos empíricos que comprovem os
benefícios e as limitações obtidos pelo seu uso, pois a maioria dos estudos é
de natureza exploratória.
1.2 Motivação
De acordo com a definição do problema apresentado, espera-se que os
resultados deste trabalho possam servir de apoio à compreensão dos efeitos,
dos benefícios e das limitações que podem ser obtidas com o uso das
Metodologias Ágeis em projetos de desenvolvimento de software, beneficiando
assim a comunidade de software e, além disso, permitir a abertura de novos
caminhos para futuras pesquisas relacionadas.
1.3 Questões de pesquisa

De acordo com a problemática exposta, este trabalho objetiva responder às
seguintes questões de pesquisa:
 Q1: O que atualmente se sabe sobre os benefícios e limitações das
Metodologias Ágeis de desenvolvimento de software através de estudos
empíricos apresentados na literatura?
2
 Q2: O que atualmente se sabe sobre os benefícios e limitações das
Metodologias Ágeis em um determinado conjunto de empresas de
desenvolvimento de software do Porto Digital de Pernambuco?
 Q3: Quais são as similaridades e diferenças entre os benefícios e as
limitações das Metodologias Ágeis reportados na literatura, com relação
aos resultados obtidos com um conjunto de empresas de
desenvolvimento de software do Porto Digital de Pernambuco que
utilizam tais metodologias?
1.4 Objetivo Geral

Este trabalho objetiva identificar e reunir de forma sistemática, o conhecimento
sobre os benefícios e as limitações das Metodologias Ágeis apresentadas em
estudos empíricos da literatura e também em um conjunto de empresas de
desenvolvimento de software que compõem o Porto Digital de Pernambuco,
objetivando um estudo comparativo.
1.4.1 Objetivos Específicos

Este trabalho possui os seguintes objetivos específicos:
 Identificar os estudos empíricos da literatura que tratam sobre as
Metodologias Ágeis;
 Identificar os benefícios e as limitações das Metodologias Ágeis nos
estudos da literatura;
 Identificar as empresas que trabalham com desenvolvimento de software
associadas ao Porto Digital de Pernambuco que utilizem as
Metodologias Ágeis;
 Identificar as evidências dos benefícios e limitações das Metodologias
Ágeis que são obtidos por um conjunto de empresas de
desenvolvimento de software do Porto Digital de Pernambuco;
 Comparar os resultados obtidos da literatura com os resultados obtidos
em pesquisas aplicadas a um conjunto de empresas do Porto Digital de
Pernambuco.
3
1.5 Contexto
Este trabalho foi conduzido em dois contextos:
 Condução de uma pesquisa secundária, por meio de uma Revisão
Sistemática da Literatura em estudos publicados no formato de artigos
científicos sobre as Metodologias Ágeis de desenvolvimento de
software. Tal pesquisa é uma extensão da revisão apresentada em Dybå
e Dingsøyr (2008).
 Condução de estudos de caso com um conjunto de empresas de
utilizam as Metodologias Ágeis.
1.6 Contribuições e Resultados esperados

A seguir são apresentadas as contribuições e os resultados esperados com o
desenvolvimento deste trabalho:
 Para a prática do desenvolvimento de software, permitir que todos os
envolvidos nos projetos compreendam melhor os benefícios e as
limitações que a adoção das Metodologias Ágeis pode propiciar;
 Para a comunidade científica na área das metodologias ágeis, permitir
que novas pesquisas sejam desenvolvidas a partir dos resultados e das
possíveis lacunas na área de investigação obtidos com este trabalho.
1.7 Estrutura do trabalho

Esta seção apresenta uma breve descrição do conteúdo dos demais capítulos
deste trabalho, de modo a facilitar o entendimento do mesmo para o leitor:
 Capítulo 2 (Revisão da Literatura):
o Recomenda-se a leitura da Seção 2.1 àqueles que desejam
entender os conceitos básicos sobre as Metodologias Ágeis, com
ênfase sobre os métodos XP e Scrum.
o A Seção 2.2 apresenta os trabalhos identificados que apresentam
resultados semelhantes a esta pesquisa, utilizando métodos de
pesquisa diferentes.
4
o A Seção 2.3 apresenta os principais trabalhos relacionados
identificados que apresentam resultados semelhantes a partir dos
mesmos métodos de pesquisa. As diferenças entre esta
dissertação e esses trabalhos são apresentadas, de modo a
permitir um melhor entendimento da pesquisa.
 Capítulo 3 (Metodologia da Pesquisa):

o Recomenda-se a leitura deste capítulo para entender os
procedimentos metodológicos utilizados no trabalho, destacando
as razões de escolha de cada método e os detalhes do ciclo de
pesquisa realizado.
 Capítulo 4 (Resultados):
o São apresentados os resultados obtidos com a execução de cada
etapa da pesquisa, bem como uma análise e interpretação dos
dados.
 Capítulo 5 (Considerações Finais):

o Apresenta uma análise das limitações e ameaças à validade da
pesquisa, assim como as lições aprendidas e as recomendações
para trabalhos futuros, além das conclusões do trabalho.
 Apêndices: apresenta os modelos dos instrumentos de coleta que

foram utilizados no trabalho e os resultados com mais detalhes da
Revisão Sistemática da Literatura e dos Estudos de Caso.
5
2 REVISÃO DA LITERATURA
Este capítulo apresenta os resultados de uma revisão da literatura conduzida
de maneira não sistemática (adhoc), que será utilizada como fundamentação
teórica para o melhor entendimento deste trabalho, de modo que tais conceitos
sejam suficientes para a contextualização da pesquisa e a correta interpretação
dos resultados aqui apresentados.
O capítulo está organizado nas seguintes seções:
 Referencial teórico – apresenta os conceitos das Metodologias Ágeis,
com uma descrição breve das principais existentes. Em seguida, são
apresentados resultados estatísticos sobre essas metodologias e,
depois, são apresentados os conceitos e fundamentos das metodologias
XP e Scrum;
 Soluções alternativas – apresenta dois estudos que mostram
resultados semelhantes a este trabalho, mas que foram conduzidos por
métodos de pesquisa diferentes;
 Trabalhos relacionados – apresenta os dois principais trabalhos
relacionados a esta pesquisa, apresentando as diferenças desta
pesquisa em relação a esses trabalhos.
2.1 Referencial teórico

Esta seção apresenta uma descrição das principais teorias utilizadas para a
condução desta pesquisa, resultante de uma revisão bibliográfica não
sistemática (adhoc) mediante a coleta de informações e dados que foram
levantados antes (para determinar as lacunas) e durante o desenvolvimento
deste trabalho.
Nas próximas seções serão exploradas as Metodologias Ágeis (Seção
2.1.1), apresentando a motivação para o seu surgimento, suas principais
características. Em seguida, serão enfatizadas as fundamentações teóricas dos
conceitos de Extreme Programming (XP) (Seção 2.1.3) e Scrum (Seção 2.1.4),
por serem as metodologias que mais influenciaram este trabalho.
6
2.1.1 Metodologias Ágeis
A definição oficial de Desenvolvimento Ágil de Software foi criada sob forma de
um manifesto, publicado em fevereiro de 2001 por um grupo de 17
especialistas em desenvolvimento de software que se reuniram com o objetivo
de propor maneiras melhores de desenvolver softwares. Este grupo foi
denominado Aliança Ágil (CHOW e CAO, 2008).
Após dois dias de debates, o grupo não chegou ao consenso quanto a
propor uma única metodologia, porém identificaram valores e 12 princípios.
Esses valores foram divulgados com a publicação do Manifesto Ágil (AGILE
MANIFESTO, 2001).
Baseadas nos princípios e valores do Manifesto Ágil, diversas
metodologias têm sido propostas, tais como: Adaptative Software
Development, Crystal, Dynamic Systems Development Method, eXtreme
Programming (XP), Feature Driven Development, Lean Development e Scrum
(BOEHM, 2006).
De acordo os dados apresentados por diversas pesquisas
(apresentados na seção 2.1.1.1), percebe-se que as Metodologias Ágeis estão
em ascensão no mercado e existem vários relatos na literatura de que estas
metodologias diminuem as taxas de insucesso dos projetos de software, no
entanto, Ferreira e Cohen (2008) afirmam que as pesquisas empíricas sobre a
efetividade dessas metodologias ainda são escassas, pois a maioria é de
natureza exploratória.
Esse mesmo problema é relatado no trabalho de Dybå e Dingsøyr
(2008), que afirmam que pouco ainda se sabe sobre como essas metodologias
estão sendo conduzidas na prática e quais são os seus efeitos. Por esta razão,
Strode et al. (2009) afirmam que rigorosas pesquisas empíricas com tais
metodologias são importantes para comprovarem a sua eficácia.
Na seção a seguir, são apresentados alguns resultados estatísticos
conduzidos sobre a adoção das metodologias ágeis, de modo a apresentar as
que possuíram maior adesão ao longo dos anos.
7
2.1.2 Estatísticas com as Metodologias Ágeis
Diversas pesquisas utilizando o método survey têm sido realizadas para se
entender melhor a adoção e o uso das Metodologias Ágeis e suas práticas. A
seguir apresentamos alguns resultados dessas pesquisas.
Em uma pesquisa conduzida pela Shine Technologies (2003), houve
131 respostas para o seu questionário online. Dos respondentes, 59%
afirmaram utilizar uma metodologia ágil.
Em 2006 foram constatadas 03 pesquisas com aplicações de
questionário online. A empresa Digital Focus, especializada em consultoria em
TI, obteve resposta de 136 pessoas; 81% delas afirmaram utilizar uma
metodologia ágil (DIGITAL FOCUS, 2006 apud VIJAYASARATHY e TURK,
2008). Outra pesquisa identificada foi conduzida por Ambler (2006), obtendo
resposta de 4.232 pessoas, das quais 65% utilizavam uma técnica ágil e 41%
utilizavam uma metodologia ágil, sendo que 23,40% destes respondentes
utilizavam o XP, 12,30% o FDD e 11,30% o Scrum. A terceira pesquisa foi
conduzida pela VersionOne em 2006 e publicada em 2007 (VERSIONONE,
2007a), obteve resposta de 722 pessoas. Esta pesquisa não especificou o
percentual de uso das Metodologias Ágeis, apresentou apenas que 40% dos
respondentes utilizavam o Scrum, 23% o XP, 14% uma abordagem híbrida e
8% o DSDM. Como poderiam ser escolhidas mais de uma metodologia,
percebeu-se que 77% utilizavam uma abordagem híbrida entre Scrum e XP.
Em 2007, a pesquisa conduzida pela VersionOne (VERSIONONE,
2007b), que obteve resposta de 1.681 pessoas, identificou que 81,5% delas
utilizavam uma metodologia ágil, sendo que 37% utilizavam o Scrum, 23% uma
abordagem híbrida de Scrum e XP, 12% apenas o XP, 5% o DSDM e 9%
abordagens híbridas de várias metodologias. Ambler (2007) obteve um
resultado semelhante, segundo o qual 69% dos respondentes afirmaram utilizar
uma metodologia ágil.
Em 2008, a pesquisa de Ambler (2008) manteve o mesmo resultado de
adoção, com 69% de adoção das metodologias ágeis pelos respondentes. A
pesquisa da VersionOne (2008) não explicitou a quantidade de respondentes
nem o percentual de adoção das metodologias ágeis, apresentou apenas que
49,1% dos respondentes utilizavam o Scrum, 29% não especificaram a
8
metodologia, 22,3% utilizavam uma abordagem híbrida de Scrum e XP, 8% o
XP e 5,3% abordagens híbridas de várias metodologias.
Em 2009 foi identificada apenas a pesquisa publicada pela VersionOne
(2009), a qual obteve respostas de 2.570 pessoas; destas, 84% utilizavam uma
metodologia ágil, sendo 50% o Scrum, seguido de 24% de uma abordagem
híbrida de Scrum e XP e 6% para o XP.
Em 2010, mais uma vez apenas a pesquisa da VersionOne (2010) foi
identificada, em que 4.770 pessoas responderam às perguntas. Destas
pessoas, 90% utilizavam uma metodologia ágil, sendo 58% o Scrum e 17%
uma abordagem híbrida de Scrum e XP.
Com resultados baseados em dados de 2011, foram identificadas
pesquisas da VersionOne (2011) e a de Melo et al. (2012). A primeira obteve
6.042 respostas, entre as quais 80% das pessoas afirmaram utilizar uma
metodologia ágil, sendo o Scrum adotado por 52% dessas, seguido de uma
abordagem híbrida de Scrum e XP (14%), as metodologias Kanban e
Scrumban com 3% cada e as demais com valores menos expressivos. A
segunda pesquisa foi conduzida apenas no Brasil, onde foram obtidas 466
respostas, entre as quais 88,6% afirmaram utilizar uma metodologia ágil, sendo
o Scrum adotado por 51,1% dessas pessoas; a abordagem híbrida de Scrum e
XP por 22,70%, abordagem híbrida de diversas metodologias por 7,7%, o XP
com 7,3%, e o uso do Scrumban por 4,1%.
De acordo com os resultados das pesquisas, nota-se que o Scrum e
XP são as metodologias ágeis que têm sido mais utilizadas ao longo dos anos.
Por este motivo, a revisão da literatura sobre os tipos de Metodologias Ágeis
está restrita a essas duas metodologias. Na seção 2.1.3 está descrito a
Extreme Programming (XP), apresentando seu surgimento e suas principais
características. E na seção 2.1.4 está descrito o Scrum.
2.1.3 Extreme Programming (XP)

A Extreme Programming (XP), ou em português, Programação eXtrema, foi
lançada oficialmente como metodologia a partir da publicação do livro “Extreme
Programming Explained: Embrace Change” (BECK, 1999).
9
De acordo com Beck (1999), a XP é leve, de baixo risco, flexível,
previsível e científica, além de ser uma maneira divertida para desenvolver
software, uma evolução a partir dos problemas causados pelos longos ciclos
dos modelos tradicionais de desenvolvimento. O método XP é organizado em
torno de um conjunto de valores, princípios e práticas que, de acordo com
Teles (2005), juntos atuam de forma harmônica e coesa para assegurar que o
cliente sempre receba um alto retorno de investimento em software.
Valores
Na primeira versão do livro Extreme Programming Explained: Embrace Change
(BECK, 1999), XP baseava-se em quatro valores. Na sua segunda edição, foi
adicionado um quinto valor, o Respeito, para ressaltar a importância do valor
humano no desenvolvimento de software. Os cinco valores de XP de acordo
Beck (1999 e 2004) são: Comunicação (Communication), Simplicidade
(Simplicity), Feedback, Coragem (Courage) e Respeito (Respect).
Princípios
Os princípios da metodologia foram introduzidos para transformar os valores
que são abstratos em práticas a serem seguidas. Beck (1999) propôs cinco
princípios fundamentais: Rápido feedback (Rapid feedback), Assumir a
simplicidade (Assume simplicity), Mudança incremental (Incremental change),
Aceitar as mudanças (Embracing change), Trabalho de qualidade (Quality
work).
Com a reformulação da metodologia XP (BECK, 2004), quatorze
princípios fundamentais foram propostos: Humanidade (Humanity), Economia
(Economics), Benefício mútuo (Mutual Benefit), Autossemelhança (Self-
similarity), Melhoria (Improvement), Diversidade (Diversity), Reflexão
(Reflection), Fluxo (Flow), Oportunidade (Opportunity), Redundância
(Redundancy), Falhas (Failure), Qualidade (Quality), Passos pequenos (Baby
Steps) e a Aceitação da responsabilidade (Accepted Responsibility).
10
Práticas
De modo a permitir a inserção dos valores de XP nos projetos, doze práticas
foram propostas na primeira versão (BECK, 1999) para serem utilizadas no dia
a dia dos projetos: Jogo do Planejamento (The Planning Game), Versões
pequenas (Small releases), Metáfora (Metaphor), Design simples (Simple
design). Testes (Testing), Refatoração (Refactoring), Programação em Pares
(Pair programming), Propriedade coletiva (Collective ownership), Integração
Contínua (Continuous integration), 40 horas por semana (40 hour week),
Cliente no local (On-site customer) e os Padrões de Codificação (Coding
standards).
Beck (2004), na segunda versão do livro, afirmou que as práticas são
desprovidas de valores e que, ao menos que se tenha definido um valor por
trás destas, podem tornar-se rotinas do processo de desenvolvimento de
software. Essa declaração do autor foi em virtude das experiências de uso
relatadas por praticantes da metodologia, que simplesmente estavam aplicando
todas as práticas, sem ao menos compreender os seus valores e princípios. As
práticas, então, se tornaram mais flexíveis na segunda versão (BECK, 2004),
de modo a facilitar o seu uso e permitir melhor adaptação às necessidades
particulares de cada projeto.
Ciclo de vida
De acordo com Shore e Warden (2007), os projetos XP trabalham sobre as
atividades de análise, design, implementação e testes todos os dias. Isso se
torna possível devido à ênfase na colaboração e na comunicação face a face,
que eliminam atrasos na comunicação e problemas de mal entendidos, fazendo
com que não seja mais necessário o uso de fases distintas.
2.1.4 Scrum
As raízes do Scrum estão em um artigo que sumariza as 10 melhores práticas
em empresas japonesas cujo título é “The New Product Development Game”
(TAKEUCHI e NONAKA, 1986). Este artigo introduziu o Scrum para se referir
às reuniões de equipes que praticam a auto direção e a adaptabilidade.
11
Em 1993, incorporando o estilo de gerenciamento de Takeuchi e
Nonaka (1986), Jeff Sutherland, John Scumniotales e Jeff McKenna, iniciaram
as ideias e as práticas do Scrum, antes deste ser formalizado, implementando-
o na empresa Easel Corporation, em 1994. O desenvolvimento e a
formalização do Scrum como processo de desenvolvimento de sistemas foram
realizados por Ken Schwaber (SCHWABER, 1995)
O Scrum é um processo iterativo e incremental, baseado em uma
abordagem empírica que assume que a análise, o design e o processo de
desenvolvimento são imprevisíveis, possuindo, assim, mecanismos de controle
para melhorar a flexibilidade do processo (SCHWABER, 1995). Esses
mecanismos são um conjunto de práticas, artefatos e regras que são fáceis de
aprender e que são sustentados por três pilares (Visibilidade, Inspeção,
Adaptação) que devem trabalhar juntos para garantir o bom e adequado
funcionamento do seu ciclo de vida.
Papéis
Schwaber (2004) definiu três papéis para o Scrum (Scrum Master, Product
Owner e o Time), fornecendo um mecanismo de controle descentralizado, de
modo que todos os papéis estejam comprometidos com a execução, resultados
e sejam responsáveis pelo gerenciamento do projeto.
Práticas e Cerimônias
De modo a permitir que os pilares do Scrum estejam presentes nos projetos,
algumas práticas e cerimônias foram definidas: Planejamento da Sprint (Sprint
Planning), Scrum Diário (Daily Scrum), Revisão da Sprint (Sprint Review) e a
reunião de Retrospectiva da Sprint (Sprint Retrospective).
Artefatos
Schwaber (2004) define alguns artefatos a serem utilizados durante o processo
do projeto: Product Backlog, Burndow chart e Sprint Backlog.
12
Ciclo de vida
O ciclo de vida de um projeto Scrum deve envolver todos os papéis definidos
no framework que devem trabalhar juntos, realizando as práticas e cerimônias
para que os artefatos possam ser gerados. Juntos permitem que os pilares do
Scrum sejam alcançados. Para maiores informações sobre como funciona o
ciclo de vida do Scrum, recomenda-se a leitura de Kniberg (2007).
2.2 Soluções alternativas

Alguns estudos apresentaram resultados semelhantes aos investigados por
esta pesquisa, utilizando métodos de pesquisa diferentes. A seguir são
apresentados alguns desses estudos.
2.2.1 Agile methods rapidly replacing traditional

methods at Nokia: A survey of opinions on agile
transformation (LAANTI et al., 2011)
Laanti et al. (2011) afirmam que existe uma quantidade limitada de evidências
científicas sobre o sucesso das metodologias ágeis em diferentes
configurações de desenvolvimento de software. Afirmam ainda que pouco se
sabe sobre a percepção do impacto das metodologias ágeis em organizações
de desenvolvimento de software de larga escala, e se estas continuarão sendo
utilizadas nesse tipo de ambiente.
Objetivando minimizar a problemática e entender os impactos dessas
metodologias em organizações de larga escala, foi utilizado o método de coleta
de dados baseado em um questionário online (survey), que ficou disponível
para mais de mil funcionários da empresa Nokia, alocados em sete países
diferentes.
Os resultados do estudo apresentaram que o uso das metodologias
ágeis aumentou a satisfação dos funcionários, o sentimento de efetividade das
equipes, a qualidade e a transparência do projeto. Permitiu aumentar a
autonomia e a felicidade dos funcionários com relação ao trabalho e também
que os erros dos projetos fossem detectados mais cedo.
13
Alguns problemas foram identificados, como o aumento do esforço
para o cumprimento dos prazos, ocasionando elevação estresse nos
funcionários e mudanças frequentes das prioridades dos requisitos. Mesmo
com tais problemas, a pesquisa concluiu que o impacto das metodologias ágeis
é predominantemente positivo e que as mesmas continuarão sendo usadas na
organização estudada.
2.2.2 Usage and Perceptions of Agile Software

Development in an Industrial Context: An
Exploratory Study (BEGEL e NAGAPPAN, 2007)
Begel e Nagappan (2007) afirmam que as metodologias ágeis estão sendo
bem aceitas pelo mercado; no entanto, afirmam também que pouco se sabe
ainda sobre o sucesso dessas metodologias em organizações tradicionais.
Para resolver esse problema, procuraram entender como essas metodologias
estavam sendo utilizadas e aceitas, e quais foram os sucessos e as falhas que
ocorreram em comunidades que as utilizam.
De modo a atingir o objetivo, foi conduzido em 2006 um survey
baseado na aplicação de questionários online na empresa Microsoft,
recebendo 492 respostas. Entre os respondentes estavam desenvolvedores de
software, testadores e gerentes, distribuídos em diversas localizações
geográficas (América do Norte, Ásia e Europa).
Como conclusão e resultados da pesquisa, diversos benefícios e
problemas foram identificados devido ao uso de tais métodos, principalmente
com relação ao uso do Scrum, a metodologia mais identificada entre os
pesquisados.
2.3 Trabalhos Relacionados

Nas próximas seções são apresentados dois trabalhos relacionados à área de
investigação desta pesquisa; ao final de cada seção é apresentada uma tabela
comparativa entre esta pesquisa e cada um dos trabalhos relacionados.
14
2.3.1 Empirical studies of agile software development:
A systematic review (DYBÅ e DINGSØYR, 2008)
Dybå e Dingsøyr (2008) afirmam que existem poucos estudos empíricos sobre
as metodologias ágeis, e que pouco ainda se sabe sobre como essas
metodologias estão sendo conduzidos na prática e quais são os seus efeitos.
Objetivando minimizar esta problemática, conduziram uma revisão
sistemática da literatura para avaliar, sintetizar e apresentar os resultados
empíricos sobre as metodologias ágeis, apresentando uma visão dos tópicos
de pesquisa, os resultados, as forças das evidências e as implicações para a
pesquisa e a indústria.
 RQ1: What is currently known about the benefits and limitations of agile
software development?
 RQ2: What is the strength of the evidence in support of these findings?
 RQ3: What are the implications of these studies for the software industry
and the research community?
A busca pelos estudos resultou na identificação de 1.996 estudos

potencialmente relevantes. Após essa etapa, ocorreram outras: aplicação dos
critérios de inclusão e exclusão, avaliação da qualidade, extração de dados e
síntese. Ao final, 36 estudos primários foram incluídos na revisão.
Com base na análise dos estudos incluídos, benefícios e limitações
foram identificados e categorizados. Foram apresentadas discussões acerca
dos resultados obtidos, bem como das limitações da pesquisa. Como
conclusão, afirmaram a necessidade de maior qualidade na elaboração dos
estudos empíricos.
Com base nesse problema identificado, a Revisão Sistemática da
Literatura proposta por este trabalho correspondeu a uma extensão do estudo
de Dybå e Dingsøyr (2008), procedendo à busca pelos estudos nos anos de
2006 a 2010, seguindo basicamente todas as suas etapas metodológicas, com
apenas algumas diferenças que estão descritas no Quadro 1.
15
Categoria Este trabalho Dybå e Dingsøyr (2008)
Método Revisão Sistemática da Revisão Sistemática da
Literatura e Estudos de Caso Literatura
Protocolo Protocolo desenvolvido Protocolo desenvolvido
seguindo o Guideline de seguindo o livro “Cochrane
Kitchenham (2007). Handbook for Systematic
Reviews of Interventions”
(HIGGINS e GREEN,
2008).
Estratégia de 1. Pesquisa pelos estudos 1. Pesquisa pelos estudos
busca publicados de 2006 até publicados até 2005;
2010;
2. Inclusão de novos sinônimos
na String de busca, e
exclusão de algumas
palavras repetidas.
Fontes de busca Oito engenhos de busca Oito engenhos de busca
automática e nove fontes de automática e três fontes de
busca manual. busca manual.
Critérios de Somente estudos primários Foram selecionados três
inclusão foram selecionados. estudos secundários.
Busca e seleção 1. Leitura do Título e Abstract 1. Leitura do Título e
em uma única etapa; Abstract em etapas
2. Inclusão de uma etapa para diferentes;
leitura do título, abstract,
conclusões e metodologia.
Extração dos Uso da codificação aberta e Não definido.
dados axial.
Análise dos Uso da Teoria Fundamentada Não definido.
dados em Dados (Grounded Theory).
Quadro 1 – Diferenças entre este trabalho e o de Dybå e Dingsøyr (2008)
Fonte: Elaboração própria
16
2.3.2 A Comparison of Issues and Advantages in Agile
and Incremental Development between State of
the Art and an Industrial Case (PETERSEN e
WOHLIN, 2009)
Petersen e Wohlin (2009) afirmam que muitos dos estudos empíricos sobre as
metodologias ágeis focam em sua maioria no uso do Extreme Programming
(XP) e projetos de pequeno porte. Por este fato, o estudo objetivou investigar
projetos de larga escala para identificar vantagens e problemas obtidos com o
uso das metodologias ágeis e comparar esses resultados com estudos
anteriores.
Para atingir o objetivo, foi conduzido um estudo de caso em um projeto
de larga escala na empresa Ericson AB, que oferece serviços na área de
telecomunicação e multimídia. Três subsistemas foram selecionados de um
projeto de larga escala. Os projetos foram caracterizados (linguagem de
programação, quantidade de linhas de código, número de pessoas). A coleta
de dados foi realizada através de 33 entrevistas conduzidas com pessoas
envolvidas no desenvolvimento dos softwares dos projetos.
Com base nos resultados obtidos no estudo de caso, fez-se uma
comparação com alguns estudos da literatura, podendo-se observar que os
benefícios são compatíveis entre ambos, enquanto que os problemas diferem-
se quando são comparados os projetos de pequena com os de larga escala.
As conclusões do estudo foram: existe a necessidade de novas
pesquisas empíricas com as metodologias ágeis, de modo a ajudar a
elaboração de estudos comparativos. Como trabalho futuro, os pesquisadores
afirmaram que novas pesquisas qualitativas com foco na identificação dos
problemas de tais metodologias devem ser conduzidas.
No Quadro 2 são apresentadas as diferenças entre este trabalho e o
de Petersen e Wohlin (2009).
17
Categoria Este trabalho Petersen e Wohlin (2009)
Método Condução de um estudo Revisão bibliográfica adhoc
terciário, a partir de uma para identificar estudos
Revisão Sistemática da empíricos aplicados em
Literatura, e Estudos de projetos de grande porte, e
Caso. Estudo de Caso.
Estratégia de Focos em estudos empíricos, Foco em projetos de grande
cobertura aplicado a projetos de porte.
qualquer porte de tamanho.
Quadro 2 – Diferenças entre este trabalho e o de Petersen e Wohlin (2009)
2.4 Resumo
O capítulo apresentou os principais conceitos, fundamentação teórica sobre
sas Metodologias Ágeis e resultados de pesquisas com base em questionários
(surveys), demonstrando que o número de aderentes às Metodologias Ágeis
tem aumentado ao longo dos anos, principalmente com relação ao Scrum e
XP. Mesmo com a ascensão destas metodologias, problemas foram
identificados: (1) Ferreira e Cohen (2008) afirmam que as pesquisas empíricas
sobre a efetividade dessas metodologias ainda são escassas, pois a maioria é
de natureza exploratória; (2) Dybå e Dingsøyr (2008) afirmam que pouco ainda
se sabe sobre como essas metodologias estão sendo conduzidas na prática e
quais são os seus efeitos; e (3) Strode et al. (2009) afirmam que rigorosas
pesquisas empíricas com tais metodologias são importantes para comprovarem
a sua eficácia.
Dois trabalhos que apresentaram soluções alternativas de uso de
métodos diferentes de pesquisa foram identificados: (1) Laanti et al. (2011)
conduziram um survey baseado na aplicação de questionário online para
identificar o impacto do uso das metodologias ágeis em uma organização de
larga escala; e (2) Begel e Nagappan (2007) conduziram um survey baseado
na aplicação de questionário online para identificar os benefícios e problemas
do uso das metodologias ágeis.
Dois trabalhos relacionados foram identificados: (1) Dybå e Dingsøyr
(2008) conduziram uma revisão sistemática da literatura para identificar os
benefícios e as limitações das metodologias ágeis em estudos empíricos da
18
literatura, publicados até o ano de 2005; e (2) Petersen e Wohlin (2009)
conduziram um estudo de caso em projetos de larga escala e comparou os
resultados obtidos em estudos na literatura (adhoc).
19
3 METODOLOGIA DA PESQUISA
Este capítulo descreve em detalhes os métodos de pesquisa utilizados para a
condução deste trabalho, de modo a tornar os resultados mais confiáveis e
possíveis de serem reproduzidos por outros pesquisadores.
Segundo Marconi e Lakatos (2008), um método de pesquisa é o
conjunto das atividades sistemáticas e racionais que, com maior segurança e
economia, permite alcançar um objetivo, traçando um caminho a ser seguido,
detectando erros e auxiliando as decisões do cientista. No entanto, antes da
definição do método, Easterbrook et al. (2008) recomendam que seja definido o
posicionamento filosófico a ser seguido pela pesquisa, podendo ser: positivista,
construtivista, teoria crítica e pragmático.
De acordo com o Easterbrook et al. (2008), o posicionamento
pragmático acredita que todo conhecimento é aproximado e incompleto, e seu
valor depende dos métodos pelos quais foi obtido (MENAND, 1997 apud
EASTERBROOK, 2008), sendo portanto, a verdade relativa ao observador.
Este posicionamento valoriza o conhecimento prático sobre o abstrato, e o uso
de métodos de pesquisa mista, pois vários métodos são utilizados para lançar
luz sobre a questão em estudo, investigando assim maneiras diferentes de se
chegar a uma verdade.
Por considerar o conhecimento prático, e o uso de métodos de pesquisa
mista, o posicionamento filosófico Pragmático foi considerado o mais
adequado para este trabalho, pois a abordagem metodológica utilizada se
alterna de acordo com as etapas da pesquisa.
Este capítulo se divide nas seguintes seções:
 Quadro metodológico – apresenta a classificação da pesquisa com o
quadro metodológico definido;
 Ciclo da pesquisa – todas as etapas da pesquisa são detalhadas nesta
seção: pesquisa de campo (survey), revisão sistemática da literatura e
estudos de caso.
3.1 Quadro metodológico

Marconi e Lakatos (2008) afirmam que o quadro metodológico quando bem
selecionado, é o que confere rigor científico a um trabalho de pesquisa. O
20
Quadro Metodológico adotado por este trabalho é apresentado a seguir
(Quadro 3) e detalhado posteriormente.
Método de abordagem Indutivo

Natureza das variáveis Qualitativa
Quanto ao Escopo Pesquisa de campo
Revisão Sistemática da Literatura
Estudos de caso
Método de Procedimento Teoria Fundamentada em Dados
Comparações constantes
Meta-Etnografia
Variáveis Independentes Metodologias Ágeis
(X) Desenvolvimento de Software
Variáveis Dependentes (Y) Possíveis benefícios e limitações proporcionados
pelo uso das Metodologias Ágeis em projetos de
desenvolvimento de software
Quadro 3 – Quadro metodológico
Este trabalho optou pela abordagem indutiva, que, segundo Marconi e

Lakatos (2008), caracteriza-se por partir de um conjunto de dados particulares,
suficientemente constatados (amostra), inferindo-se uma verdade geral ou
universal, não contida nas partes examinadas (população). Portanto, o objetivo
dos argumentos é levar a conclusões prováveis, cujo conteúdo é muito mais
amplo do que o das premissas nas quais se basearam.
Com base na revisão ad hoc da literatura, foi constatado que a maioria
dos estudos analisados sobre Metodologias Ágeis não apresenta dados
quantitativos, inviabilizando a pesquisa sob um enfoque quantitativo. Por este
motivo que a natureza das variáveis é qualitativa, apesar de que alguns
resultados desta pesquisa apresentam dados quantitativos.
De acordo com Marconi e Lakatos (2008), a abordagem qualitativa é
apropriada para obter entendimento mais profundo e detalhado sobre as
investigações, ambientes e comportamentos, o que de acordo com Seaman
(1999 apud MONTEIRO, 2010), força o pesquisador a investigar a
complexidade do problema, ao invés de abstraí-lo.
21
O escopo da pesquisa envolveu três métodos de pesquisa: pesquisa de
campo, conduzido pelo método survey, para identificar o conjunto de empresas
de desenvolvimento de software associadas ao Porto Digital de Pernambuco
que utilizam Metodologias Ágeis; Revisão Sistemática da Literatura
(KITCHENHAM, 2007), como forma de analisar e interpretar um conjunto de
dados obtidos na literatura existente sobre uma questão de investigação
particular, área temática ou fenômeno de interesse, baseando-se em
evidências; e estudos de caso, conduzidos em empresas de desenvolvimento
de software do Porto Digital de Pernambuco.
Os métodos dos procedimentos são apoiados pelo método de
comparações constantes (SEAMAN, 1999 apud MONTEIRO, 2010), que
provê suporte para a construção da teoria fundamentada em dados, do inglês
Grounded Theory (GLASER E STRAUSS, 1967), e pelo procedimento de
Meta-etnografia, do inglês Meta-ethnography, que foi baseado em Noblit e
Hare (1988) e é iniciado com a extração de conceitos-chave dos estudos
encontrados, que fornecem informações relevantes para a pesquisa.
Segundo Marconi e Lakatos (2008), as variáveis do trabalho podem ser
consideradas independentes ou dependentes. As independentes são
consideradas determinantes que fornecem condição ou causa para um
resultado, influenciando, determinando ou afetando as variáveis dependentes.
Com esta definição, este trabalho pretende investigar as Metodologias Ágeis no
desenvolvimento de software como variáveis independentes (X) e os
possíveis benefícios e limitações obtidos com o uso dessas metodologias como
variáveis dependentes (Y).
3.2 Ciclo da pesquisa

Esta seção apresenta as principais etapas que constituíram o ciclo desta
pesquisa, com uma breve descrição e associação entre as etapas. A Figura 1
apresenta este ciclo.
(1) A pesquisa foi iniciada com a definição dos conceitos teóricos
mediante uma Revisão ad hoc na Literatura sobre as Metodologias Ágeis,
sendo incluídos artigos e livros como fontes de leitura. Por meio desta etapa, e
sob a orientação dos professores orientadores deste trabalho, foram
22
identificadas as lacunas na teoria atual. Assim o Problema de Pesquisa, os
Objetivos e as Questões de Pesquisa foram definidos para serem
investigados.
Figura 1 – Ciclo da pesquisa

(2) Com a base teórica adquirida na etapa anterior, deu-se o início do

planejamento da pesquisa, primeiramente delineando as Questões de
Pesquisa a serem investigadas. Posteriormente, os instrumentos de coleta
da pesquisa (questionário, protocolo da revisão sistemática da literatura e o
roteiro da entrevista semiestruturada) foram planejados e elaborados.
(3) Cada etapa da coleta de dados foi iniciada separadamente, onde
uma etapa só iniciou ao finalizar a anterior.
23
(4) Após os dados serem coletados, os mesmos foram analisados e
interpretados objetivando responder as questões de pesquisa propostas.
(5) A última etapa consistiu na consolidação dos dados, onde foram
apresentadas as contribuições do trabalho para a pesquisa e a prática, as
limitações existentes e o direcionamento para trabalhos futuros, finalizando
com a produção de um relatório final.
Na Seção a seguir são apresentados os procedimentos de coleta de
dados baseado na pesquisa qualitativa, com descrições detalhadas sobre cada
instrumento de coleta elaborado.
3.2.1 Procedimento de coleta dos dados

Para atingir os objetivos e responder às questões de pesquisa, foram utilizadas
várias fontes de informações e métodos para realizar a coleta dos dados. Esta
seção tem por objetivo explicar os três procedimentos utilizados para a coleta
de dados e está dividida de acordo com as seguintes seções:
 Aplicação de questionários (survey) – apresenta os procedimentos
adotados para a elaboração do questionário, como foi realizada a
condução desta etapa, e os resultados obtidos de modo geral;
 Revisão Sistemática da Literatura – apresenta uma breve descrição
sobre revisões sistemáticas, e os procedimentos que foram adotados na
elaboração do protocolo da revisão;
 Estudos de caso – apresenta os procedimentos adotados para o
planejamento, seleção e condução dos estudos de caso.
3.2.1.1 Aplicação de Questionários (survey)

Segundo Easterbrook et al. (2008), uma pesquisa survey é utilizada para
identificar características de uma ampla população de indivíduos, comumente
associada ao uso de questionários para a coleta dos dados. De acordo com os
mesmo autores, uma pré-condição de uso deste método é que a questão de
pesquisa a ser investigada em uma determinada população deve estar bem
clara.
Com base nessas recomendações, este trabalho utilizou o método
survey baseado na aplicação de um questionário online, porque, de acordo
24
com Laanti et al. (2011) é um meio mais rápido e fácil de obter as respostas do
que o uso de questionários em papel, além de que a manipulação das
respostas torna-se menos trabalhosa, evita erros humanos, garante um número
de respostas maior em um menor tempo, e reduz os custos.
O questionário foi aplicado com o objetivo de identificar as empresas
(130 ao total)1 associadas ao Porto Digital de Pernambuco que se enquadram
na categoria de desenvolvimento de software e quais delas utilizam as
Metodologias Ágeis para o desenvolvimento de software. Das empresas que
utilizavam uma metodologia ágil, também foram coletadas informações sobre:
função do respondente ocupada na empresa, tipo de metodologia ágil utilizada,
tipos de práticas ágeis utilizadas, tempo de uso das metodologias ágeis na
organização, quantidade de projetos que utilizam metodologias ágeis no
momento e a quantidade de projetos finalizados que utilizaram tais
metodologias.
As faixas utilizadas para identificar o tempo de uso das metodologias
ágeis foram classificadas como: menos de um ano (pouco tempo), entre 01 a
quatro anos (tempo médio) e mais de 04 anos (muito tempo).
A coleta de dados ocorreu entre os dias 01 de janeiro de 2011 a 31 de
maio de 2011, onde foi disponibilizado um questionário online, baseado no
modelo disponível no APÊNDICE A, divulgado em grupos de e-mails (Scrum
Recife e a lista de pós-graduação do Centro de Informática (CIn) da UFPE) e
através de e-mails encaminhados diretamente aos funcionários das empresas
(obtidos pelos sites das empresas).
Devido ao baixo índice de respostas, houve a necessidade de aplicar
os questionários pessoalmente nas empresas. Ao total, 63 respostas foram
obtidas com a aplicação do questionário.
3.2.1.2 Revisão Sistemática da Literatura

Segundo Kitchenham (2007), uma Revisão Sistemática da Literatura
(Systematic Literature Review - SLR) tem o objetivo de identificar, avaliar e
interpretar tudo o que existe de relevante para uma particular questão de
pesquisa, área ou fenômeno de interesse. Ainda, Petticrew e Roberts (2006)
1
De acordo com o site: www.portodigital.com.br. Acessado em 23/11/2010
25
afirmam que uma SLR é uma abordagem disciplinada para conduzir uma
revisão da literatura, possuindo, assim, maior credibilidade, pois esta deve ser
conduzida por métodos bem definidos que devem ser seguidos rigorosamente.
Assim, é permitida a redução do viés de uma SLR, pois ela deve ser auditável,
e permitir a sua repetição.
Kitchenham (2007) afirmou que existem dois tipos de revisão que
complementam uma revisão sistemática da literatura: (1) mapeamento
sistemático, que deve ser realizada em estágio inicial de investigação de um
determinado tópico, antes que seja realizada uma revisão sistemática, ou
quando o tema é muito amplo. Dessa forma, este tipo de revisão permite
identificar possíveis áreas em que são necessárias realizações de estudos
primários; (2) revisões terciárias é uma revisão sistemática de revisões
sistemáticas, a fim de responder a questões mais amplas de pesquisa, sendo
possíveis de serem realizadas somente quando existem várias revisões
sistemáticas sobre o domínio em estudo.
De acordo com Kitchenham (2007), a diferença entre uma Revisão
Sistemática e um Mapeamento Sistemático é que a primeira foca em questões
de pesquisa mais específicas, que podem ser respondidas por pesquisa
experimental, enquanto que a segunda foca em questões mais amplas, com o
propósito de dar uma visão geral de uma área de pesquisa.
Com base nas definições e diferenças de Revisões Sistemáticas e
Mapeamentos Sistemáticos apresentados acima, este trabalhou optou por
realizar uma Revisão Sistemática da Literatura, pois se pretende investigar
tópicos específicos sobre as Metodologias Ágeis: os benefícios e as limitações
proporcionados devido ao seu uso relatados em estudos empíricos da
literatura.
Kitchenham (2007) afirma que antes de iniciar o planejamento de uma
SLR, o pesquisador deve verificar se realmente existe a necessidade de
realizá-la. A autora apresentou algumas razões para se realizar uma:
 Quando se deseja consolidar as evidências existentes de um
determinado fenômeno;
 Identificar lacunas/gaps na pesquisa atual de modo a sugerir novas
áreas de investigação;
26
 Para poder prover um arcabouço adequado para posicionar novas
pesquisas.
Esta SLR é uma extensão da revisão conduzida por Dybå e Dingsøyr

(2008) e tem o objetivo de identificar os estudos empíricos sobre Metodologias
Ágeis e consolidar as evidências destes estudos sobre os benefícios e as
limitações destas metodologias no desenvolvimento de software.
Segundo Justus (2009), um método efetivo para iniciar o planejamento
da revisão da literatura é classificá-la com base na Taxonomia da Revisão da
Literatura proposta por Cooper (1988 apud JUSTUS, 2009). O Quadro 4
apresenta como esta revisão foi classificada.
Característica Categoria da revisão

Foco Resultados de pesquisa e práticas ou aplicações
Objetivo Integrar e Identificar questões centrais
Perspectiva Exaustiva com citação seletiva
Cobertura Representativo
Organização Conceitual
Público-alvo Pesquisadores em geral e praticantes das metodologias ágeis
Quadro 4 – Classificação da revisão da literatura

Para permitir que uma revisão seja auditável, Kitchenham (2007)

sugere que seja elaborado um protocolo descrevendo todos os procedimentos
e métodos de como a revisão será conduzida. Seguindo tais orientações, um
protocolo de pesquisa foi desenvolvido com base na própria Kitchenham
(2007), que se encontra disponível por completo no APÊNDICE B.
Nas seções a seguir, um resumo do protocolo utilizado para a
condução de toda a pesquisa é apresentado.
3.2.1.2.1 Protocolo da pesquisa

Uma breve descrição das seções do protocolo é apresentada a seguir.
27
Questões de pesquisa
Com o objetivo de identificar resultados de pesquisas, práticas e aplicações
com o uso das Metodologias Ágeis, de modo a estender a revisão de Dybå e
Dingsøyr (2008), esta revisão possui 03 questões de pesquisa:
 Q1: O que atualmente se sabe sobre os benefícios e limitações
das metodologias ágeis de desenvolvimento de software?
 Q2: Quais são as forças das evidências que suportam os
resultados encontrados?
 Q3: Quais são as implicações desses estudos para a indústria de
software e a comunidade de pesquisa?
A primeira questão de pesquisa é a principal, sendo as outras duas

secundárias, pois somente foram respondidas para os estudos que
apresentaram respostas para a questão principal da pesquisa.
Estratégias de busca
Para conduzir as buscas pelos estudos, foram utilizadas fontes de busca
automática e manual. A busca automática foi realizada a partir da definição de
uma String de busca, derivada da questão principal da pesquisa.
A String de busca foi construída utilizando a combinação de palavras-
chave da Q1 e seus sinônimos ou palavras derivadas, concatenados por meio
dos operadores booleanos “OR” e “AND”. A seguir é a apresentada a String de
busca derivada da combinação:
 ("agile" or "agility" or "scrum" or "extreme programming" or "xp" or
"dynamic system development" or "dsdm" or "crystal clear" or "crystal
orange" or "crystal red" or "crystal blue" or "feature driven
development" or "fdd" or "lean software development" or "adaptive
software development" or "asd" or "test driven development" or "tdd")
and ("software development" or "software engineering" or "information
system development" or "information system engineering" or "software
production")
28
Os termos utilizados para a String de busca foram os mais abrangentes
possíveis, de modo que seja a busca retornasse a maioria dos estudos sobre
as Metodologias Ágeis, e somente após a leitura dos mesmos identificar os
possíveis benefícios e limitações.
Fontes de busca
De modo a garantir uma busca exaustiva, e atingir a maior cobertura da
literatura existente a respeito do tema, foram realizadas as buscas
automáticas em 08 engenhos utilizando a String de busca nas principais
bases de dados na área de investigação disponíveis na internet, e manuais
nas principais referências (conferências e periódicos) de engenharia de
software e métodos ágeis. Os detalhes utilizados para cada fonte encontram-se
disponível no protocolo completo (APÊNDICE B).
Seleção dos estudos

Todos os estudos retornados do processo de busca foram avaliados com base
em critérios de inclusão e exclusão, descritos na Seção 2.4 do APÊNDICE B.
Foram definidos nove critérios de inclusão e nove de exclusão. Para que um
estudo fosse incluído, o mesmo deveria atender a todos os critérios de
inclusão. E para que fosse excluído, bastava se enquadrar em apenas um
critério de exclusão.
Os critérios foram aplicados em dois estágios: o primeiro com base na
leitura do Título e Abstract. E no segundo, com base na leitura da Introdução,
Conclusão e Metodologia, e em casos onde não ficou claro o entendimento
sobre o estudo, a leitura completa foi efetuada sobre o mesmo.
Os estudos desta etapa foram divididos em três grupos, e avaliados por
pares de pesquisadores. Cada par aplicou os critérios sobre cada estudo
individualmente. O resultado de cada critério foi comparado entre cada par, e
para as divergências um terceiro avaliador foi convocado para gerar o
desempate.
29
Avaliação da qualidade
Todos os estudos incluídos na etapa anterior foram avaliados quanto a sua
qualidade metodológica com base em 10 critérios definidos por Dybå e
Dingsøyr (2008), objetivando compreender a força das evidências encontradas
que suportam os seus resultados para responder a segunda questão de
pesquisa. O modelo de formulário de avaliação da qualidade utilizado encontra-
se disponível na Seção 2.6 do APÊNDICE B.
Os estudos foram novamente divididos em três grupos, para serem
avaliados por pares de pesquisadores. E os mesmos procedimentos da etapa
anterior foram adotados para as divergências na aplicação dos critérios de
qualidade sobre cada estudo.
Extração e Análise dos dados

A extração de dados foi realizada por um único pesquisador e revisada pelo
orientador da pesquisa, a partir da leitura de cada estudo, onde foram
coletadas todas as informações importantes que pudessem auxiliar nas
respostas às questões de pesquisa. Os estudos foram excluídos caso não
respondessem à Q1.
Para a coleta dos dados, foram utilizados dois formulários
armazenados no Microsoft Excel™: um para registrar as características de
cada estudo, e o outro para os resultados encontrados. Os formulários
utilizados estão disponíveis na Seção 2.6 do APÊNDICE B.
O método de extração e análise dos dados ocorreu em paralelo.
Durante a extração, foram utilizados os procedimentos de codificação aberta
(STRAUSS e CORBIN, 2008) para identificar os conceitos para responder a
Q1, as propriedades desses conceitos e suas dimensões, foram derivadas de
cada estudo. Em seguida, o procedimento de codificação axial (STRAUSS e
CORBIN, 2008) foi utilizado para reagrupar os dados, e entender como as
categorias e subcategorias se relacionam. Anotações sobre as categorias ou
subcategorias derivadas de cada estudo também foram realizadas, de modo a
entender melhor as características de cada categoria.
Para a análise dos dados, foi utilizado o método da Teoria
Fundamentada em Dados, do inglês, Grounded Theory (GLASER e
30
STRAUSS, 1967), pois de acordo com Racheva et al. (2010) é um método que
pode ser utilizado quando não se tem ideias pré-concebidas, e as categorias
dos dados vão surgindo à medida que os dados são coletados, podendo
emergir novas categorias, ou modificar as existentes por meio de comparações
constantes.
Síntese dos dados

Os dados obtidos (autor(es), ano, metodologia ágil utilizado, práticas ágeis
utilizadas, respostas para as questões de pesquisa, etc) na coleta de cada
estudo foram extraídos e sintetizados utilizando o Microsoft Excel™. O método
de Meta-Etnografia (NOBLIT e HARE, 1988) foi utilizado porque de acordo com
os próprios autores, é um método recomendado para apresentar conceitos
apenas quando a síntese dos dados for realizada, sendo assim, considerada
uma síntese interpretativa a partir dos dados relatados nos estudos primários.
3.2.1.3 Estudos de Caso

De acordo com Yin (2005), um estudo de caso é uma investigação empírica
sobre um fenômeno contemporâneo dentro de seu contexto da via real,
especialmente quando os limites entre o fenômeno e o contexto não estão
claramente definidos. Uma pré-condição para conduzir um estudo de caso, de
acordo com Easterbrook et al. (2008), é que a questão de pesquisa tenha como
proposta entender como ou por que certos fenômenos ocorrem, e quais são os
resultados que o estudo pretende mostrar.
De acordo com Yin (2005), existem dois tipos de estudos de caso, os
de caso único e os de casos múltiplos. Um estudo de caso único geralmente
representa um caso decisivo para testar uma teoria bem-formulada, ou ainda,
casos raros ou extremos. E os de casos múltiplos refletem situações de projeto
diferentes, mas que podem existir unidades unitárias ou múltiplas de análise
comum. Ainda, os estudos podem ser classificados de acordo com o seu
objetivo de investigação, podendo ser exploratório e confirmatório
(EASTERBROOK et al., 2008).
Com base nessas definições e recomendações, este trabalho conduziu
estudos de casos múltiplos com duas empresas de desenvolvimento de
31
software do Porto Digital de Pernambuco, de modo explorar e confirmar (com
base na literatura) os resultados que são obtidos com o uso das Metodologias
Ágeis em contextos diferentes de projetos, objetivando responder à segunda
questão de pesquisa deste trabalho.
A unidade de análise dos estudos de caso são os relatos dos
participantes dos projetos investigados, com base em suas experiências
com o uso das metodologias ágeis nos projetos.
Esta seção está dividida de acordo com as seguintes seções:
 Seleção da amostra – apresenta os critérios utilizados para seleção das
empresas;
 Coleta de dados – apresenta o procedimento de coletas que foi
utilizado na pesquisa;
 Extração e análise dos dados – apresenta os procedimentos adotados
para extração e análise dos dados;
 Síntese dos dados – apresenta o procedimento adotado para a síntese
dos dados;
 Validade de constructo – apresenta os procedimentos adotados na
pesquisa de modo a permitir uma validade de constructo;
 Validade interna – apresenta os procedimentos adotados para a coleta
de dados, de modo a aumentar a validade interna da pesquisa.
3.2.1.3.1 Seleção da amostra

A amostra selecionada para o estudo de caso foi derivada das empresas de
responderam ao questionário descrito na Seção
A escolha para conduzir a pesquisa com as empresas do Porto Digital
foi motivada pelo fato deste ser o maior parque tecnológico do país 2 e ter sido
eleito em 2011 o melhor na categoria do Prêmio Nacional de
Empreendedorismo Inovador (ANPROTEC, 2011).
Os procedimentos de amostragem das empresas foram intencionais,
objetivando uma variação máxima (maior e menor tempo de uso das
2
UOL Economia: http://economia.uol.com.br/ultimas-noticias/redacao/2012/08/03/parques-tecnologicos-
disputam-titulo-de-vale-do-silicio-brasileiro.jhtm
32
Metodologias e empresas em que as metodologias ágeis estejam sendo
utilizadas na maior quantidade de projetos).
Quanto aos participantes da pesquisa, foi solicitado aos responsáveis
de cada uma das empresas que disponibilizassem a maior quantidade de
pessoas dos projetos para realizar a coleta de dados. E que, se possível, no
mínimo uma pessoa de cada função (gerente, analista, desenvolvedor,
testador, etc.) fosse disponibilizada, objetivando uma variação máxima dos
papéis dos entrevistados, de modo permitir obter diferentes visões de
pensamento.
Ao total foram selecionadas 22 pessoas, entre os cargos de gerentes,
líderes técnicos, analistas, engenheiros de sistema, desenvolvedores e
testadores.
3.2.1.3.2 Coleta de dados

De acordo com Yin (2005), existem seis fontes de coleta de dados que podem
ser utilizadas em estudos de caso: documentos, registros em arquivo,
entrevistas, observação direta, observação participante e artefatos físicos.
Para esta pesquisa, entrevistas foram realizadas para a obtenção dos
dados primários. Os procedimentos de coleta de dados utilizados nas
entrevistas são descritos a seguir.
Entrevistas
Yin (2005) afirma que o uso de entrevistas é uma das mais importantes fontes
de informação para um estudo de caso, que de acordo com Lutters e Seaman
(2007, apud SEAMAN 2008), são geralmente utilizadas para coletar opiniões
ou impressões sobre alguma coisa.
De acordo com Gray (2012), as entrevistas podem ser classificadas em
cinco categorias: estruturadas, semiestruturadas, não direcionadas,
direcionadas, e com conversas informais.
Esta pesquisa optou por realizar entrevistas semiestruturadas, pois, de
acordo com Flick (2009), esta abordagem permite utilizar um planejamento
aberto e permite que os pontos de vista dos sujeitos entrevistados sejam mais
33
bem expressados, do que em uma entrevista padronizada ou a partir da
aplicação de um questionário.
Um roteiro descrito no APÊNDICE C foi desenvolvido para conduzir as
entrevistas, que foi dividido em seis partes: (1) Objetivo: iniciar a entrevista
explicando os objetivos da pesquisa, e apresentando os termos de sigilosidade;
(2) Dados do entrevistado: conhecer um pouco sobre o entrevistado (tempo de
empresa, tempo no projeto, função exercida, etc); (3) Informações sobre o
projeto: tamanho da equipe, definição dos papéis da equipe, contexto dos
projetos, linguagem de programação utilizada, etc.; (4) Atividades
desenvolvidas: do entrevistado e de sua equipe no projeto; (5) Percepção do
entrevistado quanto aos benefícios que as Metodologias Ágeis propuseram aos
projetos; e (6) Percepção do entrevistado quanto as limitações que as
Metodologias Ágeis propuseram aos projetos.
3.2.1.3.3 Extração e Análise dos dados

As entrevistas foram transcritas, e os mesmos procedimentos de extração de
dados adotados na condução da Revisão Sistemática da Literatura foram
realizados, ou seja, os procedimentos de codificação aberta e axial. Para a
análise dos dados também foi utilizado o método da Teoria Fundamentada em
Dados, do inglês, Grounded Theory (GLASER e STRAUSS, 1967).
Cada uma das empresas recebeu um identificador único (ALFA e
BETA), os projetos (P1, P2, P3) e as entrevistas foram nomeadas da seguinte
maneira: identificador da empresa + “_” + identificador do projeto + “_” + “E” +
identificador sequencial.
3.2.1.3.3 Síntese dos dados

Comparações constantes foram realizadas com os dados obtidos na extração
das entrevistas, e os dados foram sintetizados utilizando o método de Meta-
Etnografia (NOBLIT e HARE, 1988), também utilizado na Revisão Sistemática
da Literatura. Tal método é mais bem conduzido em sete passos de acordo
com os autores: (1) iniciar o processo; (2) decidir o que é relevante para a
pesquisa; (3) realizar a leitura do material; (4) determinar a relação dos
34
estudos; (5) traduzir as relações dos estudos em categorias; (6) sintetizar as
categorias; e (7) apresentar a síntese dos resultados.
3.2.1.3.4 Validade de constructo

De acordo com Yin (2005), a validade de constructo visa estabelecer medidas
operacionais corretas para os conceitos que estão sob o estudo. No entanto, o
autor afirma que garantir essa validade é especialmente problemático para
estudos de caso, pela dificuldade de se desenvolver um conjunto
suficientemente operacional de medidas.
De modo a garantir essa validade, foi elaborado um roteiro para
condução das entrevistas, descrito no APÊNDICE C. O roteiro foi direcionado
para as empresas que utilizam o Scrum e algumas práticas do XP, devido
serem as metodologias utilizadas pelas empresas pesquisadas. O conteúdo do
roteiro foi escrito com base na literatura e experiência do autor deste trabalho,
onde foram abordados pontos específicos das etapas de desenvolvimento de
um software utilizando tais metodologias, de modo a identificar possíveis
benefícios e limitações obtidos com o uso dessas metodologias.
Foram realizadas duas entrevistas piloto com estudantes de pós-
graduação (um aluno de mestrado, e outro de doutorado) com experiências no
Scrum e XP, de modo a identificar possíveis melhorias para o roteiro.
3.2.1.3.4 Validade interna

De acordo com Yin (2005), a validade interna de um estudo de caso diz
respeito às inferências que podem ser feitas quando um evento não pode ser
diretamente observado, com base em evidências obtidas de entrevistas e
documentações.
De modo a permitir aumentar a validade interna da pesquisa e a
confiabilidade dos dados obtidos, o representante da organização recebeu um
termo de sigilosidade (APÊNDICE D). Os entrevistados participaram
voluntariamente das entrevistas, estavam cientes dos objetivos da pesquisa e
de acordo com o Termo de Sigilosidade (APÊNDICE E). Neste termo, ficou
explicita a garantia do anonimato do entrevistado e do projeto, de modo a não
intimidá-lo nas suas respostas durante a entrevista.
35
Antes de iniciar cada entrevista, foi pedida permissão ao entrevistado
para que a mesma fosse gravada em áudio. Todos os entrevistados
concederam a permissão de gravação.
Os dados coletados a partir das entrevistas foram obtidos através de
transcrições fidedignas. Para evitar o viés do pesquisador sobre a análise e
interpretação dos dados, os entrevistados foram contatados por e-mail, de
modo a verificar se as interpretações do pesquisador estavam corretas. Dos 22
entrevistados, dezesseis confirmaram a correta interpretação dos dados, três
esclareceram alguns pontos para melhor interpretá-los, e não foram obtidas as
respostas de três entrevistados.
Os resultados obtidos com os estudos de caso são discutidos de
acordo os resultados obtidos em Begel e Nagappan (2007), Dybå e Dingsøyr
(2008), Petersen e Wohlin (2009) e em Laanti et al. (2011).
3.2.1.3.5 Validade externa

A validade externa de um estudo de caso de acordo com Yin (2005), diz
respeito se os resultados encontrados podem ser generalizados. Para isso,
devem-se replicar as constatações em um segundo ou mesmo em um terceiro
local, nos quais a teoria supõe que deveriam ocorrer os mesmos resultados.
Uma vez que sejam feitas essas replicações, os resultados poderiam ser
aceitos como algo que fornece forte sustentação para a teoria, mesmo que não
se realizem mais replicações.
De acordo com Flyvbjerg (2006), os estudos de caso são bastante
questionados e criticados quanto a possibilidade de generalização dos seus
resultados, devido a sua natureza qualitativa. O autor apresenta diversos
argumentos contrariando esses questionamentos e explica que até mesmo um
estudo de caso único pode permitir uma generalização.
Flyvbjerg (2006) afirma que um estudo de caso deve ser bem
selecionado a partir de uma definição clara do problema da pesquisa e suas
circunstâncias; argumenta que muitas das descobertas da ciência têm sido
realizadas a partir de observações e não de dados estatísticos; e discute os
possíveis vieses que podem ocorrer devido a natureza qualitativa de obtenção
e interpretação dos dados.
36
De modo a garantir a validade externa da pesquisa, a escolha da
condução de estudos de caso foi baseado em questões de pesquisas
formuladas pelo trabalho, de modo permitir a comparação dos resultados dos
estudos de caso com a literatura. Os casos foram selecionados com base em
critérios bem definidos, de modo permitir a variação máxima (maior e menor
tempo de uso) das empresas que utilizavam uma metodologia ágil. Para reduzir
as possibilidades de vieses diversas abordagens foram utilizadas, descritas na
seção 0.
3.3 Resumo
A pesquisa adotou o posicionamento filosófico pragmático, por acreditar
valorizar o uso de métodos de pesquisa mista para alcançar o objetivo da
pesquisa.
Os procedimentos de coleta de dados foram apresentados e
detalhados, sendo utilizados três métodos: (1) aplicação de questionários
(survey); (2) revisão sistemática da literatura (SLR); e (3) estudos de casos
múltiplos.
O objetivo do primeiro método de coleta foi utilizado para identificar as
empresas de desenvolvimento de software do Porto Digital de Pernambuco que
utilizavam as Metodologias Ágeis. O segundo, a SLR foi conduzida para
identificar os benefícios e as limitações das Metodologias Ágeis apresentadas
na literatura. E o terceiro método de coleta foram os estudos de caso, que
objetivaram identificar de um conjunto de empresas do Porto Digital de
Pernambuco, os benefícios e as limitações do uso das Metodologias Ágeis no
desenvolvimento de software.
37
4 RESULTADOS
Esta seção apresenta os resultados obtidos com as diversas etapas da
pesquisa.
4.1 Síntese dos resultados da aplicação dos

questionários
Esta seção apresenta os resultados e a análise da aplicação dos questionários
(survey) com as empresas de desenvolvimento de software que fazem parte do
Porto Digital de Pernambuco, fornecendo subsídios necessários para permitir a
condução dos Estudos de Caso. Os resultados desta etapa são apresentados
levando-se em consideração duas partes distintas.
 Resultados da aplicação dos questionários – apresentam como a
pesquisa foi conduzida, os dados gerais obtidos com a aplicação do
questionário: quantidade de respostas, metodologias ágeis
adotadas, tempo de uso das metodologias ágeis, quantidade de
projetos finalizados utilizando as metodologias ágeis, quantidade de
pessoas por projeto, etc.;
 Análise e discussão dos resultados – apresenta uma análise dos
principais resultados obtidos pela pesquisa.
4.1.1 Resultados da aplicação dos questionários

O questionário ficou disponível na internet no período de 01 de janeiro de 2011
a 31 de maio de 2011 e também foi aplicado pessoalmente em algumas
empresas, obtendo-se um total de 63 respostas.
Foram consideradas 19 respostas como inválidas, ou porque não
pertenciam ao grupo de empresas associadas ao Porto Digital, ou porque eram
de empresas que não trabalhavam com desenvolvimento de software (pergunta
1), ou porque eram respostas de pessoas da mesma empresa. Para esta última
situação as respostas foram comparadas e, em caso de divergência, foi
encaminhado um e-mail para os respondentes, para avaliarem suas respostas
e chegarem a um consenso. É importante salientar que a sigilosidade dos
respondentes também foi mantida nessas situações.
38
Restaram 44 respostas válidas, correspondendo a 33,85% do total da
amostra selecionada de 130 empresas. Portanto, na análise das respostas
para cada questão do questionário, foram consideradas apenas as respostas
válidas. Para a segunda pergunta do questionário, 30 respondentes informaram
que utilizam uma metodologia ágil na organização, correspondendo a 68% dos
respondentes. A Figura 2 apresenta o gráfico dessa relação.
P2. Utilizam alguma Metodologia ou prática

Ágil no desenvolvimento de software?
Não utilizam uma

32% metodologia ágil
68% Utilizam uma

metodologia ágil
Figura 2 – Porcentagem de empresas que utilizam uma Metodologia Ágil

Para a terceira pergunta destinada aos que não utilizam uma

metodologia ágil, 04 não possuem previsão para a implantação, 03 pretendem
implantar no futuro e 05 afirmaram que uma metodologia ágil está em processo
de implantação.
A quarta pergunta do questionário objetivou identificar quais são as
metodologias ágeis que as empresas estão utilizando. Como resultado, todos
os respondentes afirmaram utilizar o Scrum, seja individualmente ou através de
uma abordagem híbrida com outra metodologia, como mostra o gráfico na
Figura 3.
As práticas ágeis mais utilizadas foram as reuniões da Sprint (Planning,
Review e Retrospective), seguido das reuniões diárias, desenvolvimento
iterativo e incremental e equipes autogerenciáveis, além da técnica do Planning
Poker. As práticas menos utilizadas pelas empresas foram: ter o cliente sempre
presente no projeto e o uso do TDD. O gráfico da Figura 4 apresenta o
quantitativo de cada uma das práticas.
39
P4. Quais são as Metodologias Ágeis
utilizadas pela empresa?
21
6
2 1
Scrum Scrum, FDD Scrum, Kanban Scrum, XP
Figura 3 – Metodologias Ágeis utilizadas pelas empresas

P5. Quais são as práticas das Metodologias Ágeis utilizadas na

empresa?
35 30
30 27 25 24 24
25 19 18 16 16
20 15
15 9
10
3
5
0
Figura 4 – Práticas ágeis utilizadas pelas empresas

O tempo de uso das metodologias ágeis pelas empresas é

apresentado na Figura 5, onde é possível perceber que a maioria dos
respondentes utilizavam as metodologias ágeis há pouco tempo (56,67%) e
com o tempo médio de uso (36,67%). Apenas 6,67% das empresas utilizavam
há muito tempo.
Mais da metade das empresas possui mais de cinco projetos em
desenvolvimento e 40% dessas empresas possuem de dois a três projetos em
desenvolvimento. Uma pequena parcela possui de quatro a cinco projetos. Os
resultados com os valores percentuais para esta sétima pergunta encontram-se
no gráfico da Figura 6.
40
P6. Há quanto tempo a empresa tem utilizado
Metodologias Ágeis?
Mais de 4 anos (muito tempo) 6,67%
Entre 1 e 4 anos (tempo médio) 36,67%
Menos de um ano (pouco tempo) 56,67%
Figura 5 – Tempo de uso das Metodologias pelas empresas

P7. Qual a quantidade de projetos que a

organização possui em desenvolvimento?
Mais de 05 projetos 53,33%
De 04 à 05 projetos 6,67%
Figura 6 – Quantidade de projetos que as empresas possuem

Os resultados para a oitava pergunta mostram que a maioria das

empresas utiliza uma metodologia ágil em dois ou três projetos (36,67%),
seguido da resposta de mais de cinco projetos que utilizam tais metodologias
(23,33%). Os resultados para esta pergunta são apresentados no gráfico da
Figura 7.
41
P6. Qual a quantidade de projetos que utilizam
atualmente Metodologias Ágeis?
Apenas 01 projeto 20,00%
Figura 7 – Quantidade de projetos que utilizam metodologias ágeis

A maioria dos respondentes ainda não havia finalizado um projeto

utilizando uma metodologia ágil (33,33%). No entanto, 26,67% das empresas já
finalizaram mais de 05 projetos. O gráfico da Figura 8 apresenta os resultados
para esta nona questão.
P9. Quantos projetos foram finalizados

utilizando alguma Metodologia Ágil?
33,33%
Nenhum
Apenas 01 projeto 16,67%
De 02 a 03 projetos 13,33%
De 04 a 05 projetos 10,00%
Figura 8 – Quantidade de projetos finalizados utilizando uma Metodologia Ágil

Com relação ao tamanho médio das equipes (pergunta dez), a maioria

dos respondentes possuía de quatro a seis pessoas (63,33%) nos projetos,
seguido da quantidade de uma a três pessoas (16,67%) e projetos com mais
de oito pessoas (13,33%).
42
4.1.2 Análise e discussão dos resultados
Esta seção apresenta algumas discussões sobre os resultados mais relevantes
obtidos com esta etapa da pesquisa.
 Pergunta 2: Utilizam alguma metodologia ou prática ágil no

desenvolvimento de software?
De acordo com o resultado apresentado no gráfico da Figura 2, percebe-se
que 68% (30) das empresas respondentes utilizam uma metodologia ágil,
correspondendo a 23,08% do total da amostra de 130 empresas do Porto
Digital.
É interessante observar que 13 empresas afirmaram não utilizar uma
metodologia ágil; no entanto, para a pergunta 4, duas dessas empresas
marcaram que utilizam o Scrum e outra afirmou que utiliza o Scrum juntamente
com a metodologia Microsoft Agile - Team Foundation. Isso nos leva a
considerar que esses respondentes utilizam tais métodos, mas não sabem que
estes se enquadram em uma Metodologia Ágil.
Os resultados para esta pergunta nos mostra também que a adoção de
metodologias ágeis está em tendência de ascensão, pois das 13 empresas que
não utilizam, 06 informaram que uma metodologia ágil está em processo de
implantação na empresa.
 Pergunta 4: Quais são as Metodologias Ágeis utilizadas pela

empresa?
Os resultados mostram que o Scrum é a metodologia mais utilizada pelas
empresas, sendo adotada por 100% delas. Esse resultado mostra a grande
adoção do Scrum, observado também em outros cenários apresentados por
diversos surveys, como a pesquisa publicada por Melo e Santos et al. (2012)
sobre as metodologias ágeis no Brasil, onde o Scrum é utilizado por 51,1% dos
respondentes. Além disso, uma pesquisa mundial realizada em pela empresa
VersionOne (2011) apresentou que 52% dos respondentes adotam o Scrum.
O uso de uma abordagem híbrida do Scrum e do XP foi apresentada
por 06 empresas, sendo a segunda abordagem mais utilizada, seguindo a
mesma tendência apresentada por VersionOne (2011) e por Melo e Santos et
43
al. (2012).
 Pergunta 5: Quais são as práticas das Metodologias Ágeis utilizadas

na empresa?
As práticas do Scrum foram as mais utilizadas, em virtude do percentual de
adoção desta metodologia pelas empresas, o que mostra que essas empresas
utilizam mais práticas voltadas para a gestão do projeto do que práticas
técnicas de programação. O resultado segue uma tendência similar de adoção
em relação aos surveys da VersionOne (2011) e de Melo e Santos et al.
(2012), estando as práticas de planejamento da iteração entre as mais
adotadas, seguida das reuniões diárias. Entre as práticas menos adotadas,
encontra-se a prática do cliente sempre presente, que apresentou um
percentual parecido com os outros surveys (VERSIONONE, 2011 e, MELO e
SANTOS et al. 2012), enquanto que a técnica de TDD (10%) seguiu uma
tendência diferente dos demais surveys, como o da VersionOne (2011) que
apresentou 38%, e de Melo e Santos et al. (2012) com 39,7%.
 Pergunta 6: Há quanto tempo a empresa tem utilizado Metodologias

Ágeis?
De acordo com os resultados apresentados para esta pergunta, percebe-se
que o uso das metodologias ágeis é recente para as empresas de
desenvolvimento de software do Porto Digital que participaram da pesquisa,
pois a maioria (56,67%) utilizava há pouco tempo uma metodologia ági.
 Pergunta 8: Qual a quantidade de projetos que utilizam atualmente

Metodologias Ágeis?
De acordo com os resultados, 25,58% das empresas estão utilizando as
metodologias ágeis em dois ou três projetos. E, de acordo com as respostas
para pergunta 7, mais de 50% das empresas possuem mais de cinco projetos
atualmente em execução. O que nos leva a concluir que não são todos os
projetos de desenvolvimento de software das empresas que está sendo
utilizada uma metodologia ágil.
44
 Pergunta 9: Quantos projetos foram finalizados utilizando alguma
Metodologia Ágil?
De acordo com os resultados apresentados, percebe-se que nenhum projeto
utilizando uma metodologia ágil foi finalizado para a maioria das empresas.
Esse resultado tem uma provável relação com o tempo de uso das
metodologias ágeis pelas empresas, visto que a maioria as utiliza há menos de
seis meses.
4.2 Síntese dos Resultados da Revisão Sistemática

Esta seção apresenta os resultados obtidos com a condução da Revisão
Sistemática da Literatura, bem como a análise dos mesmos, que permitem
responder à Q1 deste trabalho: “O que atualmente se sabe sobre os benefícios
e limitações das Metodologias Ágeis de desenvolvimento de software através
de estudos empíricos apresentados na literatura?”. Os resultados deste estudo
são apresentados levando-se em consideração três partes distintas.
 Resultados do procedimento de Busca e Seleção – apresentam
como a pesquisa foi conduzida, as mudanças ocorridas com relação
ao protocolo, e os dados gerais obtidos com a busca e seleção dos
estudos: quantidade de estudos retornados nas buscas, processo de
seleção, distribuição temporal, por país, por pesquisador, etc.;
 Mapeamento das evidências – apresenta e descreve as evidências
identificadas pela revisão sistemática para cada questão de
pesquisa (Q1, Q2, Q3);
4.2.1 Resultados do procedimento de Busca e Seleção

Esta seção apresenta os procedimentos executados para a obtenção dos
estudos para esta revisão. Na Seção 0 é descrita a equipe envolvida nas
etapas da pesquisa. Na Seção 0, são apresentados os passos conduzidos pela
revisão e os resultados dos mesmos.
45
4.2.1.1 Equipe envolvida
Para a condução desta pesquisa, foram envolvidos nove pesquisadores, sendo
sete estudantes de pós-graduação (dois doutorandos, e cinco mestrandos) em
Ciências da Computação, pelo Centro de Informática (CIn) da Universidade
Federal de Pernambuco (UFPE), e dois professores orientadores. Entre os
pesquisadores, três estudantes possuíam experiências prévias na condução de
Revisões Sistemáticas da Literatura ou Mapeamento Sistemático, e os
professores orientadores auxiliaram e orientaram durante todo o processo.
Segundo Dybå e Dingsøyr (2008), a principal limitação de uma revisão
sistemática é o viés introduzido pelos pesquisadores na seleção dos estudos.
Para reduzir essa possibilidade de viés, quase todas as etapas da revisão
foram conduzidas envolvendo pelo menos três pesquisadores, com exceção
das etapas de extração e síntese dos resultados, que foram conduzidas pelo
autor desta dissertação.
4.2.1.2 Execução
A revisão sistemática foi conduzida de acordo com o protocolo apresentado
resumidamente no Capítulo 3 e disponível por completo no APÊNDICE B. Os
resultados de cada etapa da condução estão descritos nas próximas seções.
4.2.1.2.1 Etapa 1: Busca Automática e Manual

A partir da String de busca, da definição das fontes de pesquisa e dos demais
critérios definidos no protocolo, a busca primária foi realizada no mês de Abril
de 2011, sendo conduzida por três grupos pares de pesquisadores.
Antes das buscas automáticas serem iniciadas, testes foram realizados
em cada engenho, de modo a permitir que a busca automática fosse executada
do mesmo modo por todos os pesquisadores, e garantir que este estudo
pudesse ser replicado.
A partir das buscas primárias, foram retornados 9.845 estudos, dos
quais 9.642 foram provenientes da busca automática nos engenhos eletrônicos
e 203 identificados pela busca manual. Vale ressaltar que para a busca
manual, estão listados apenas os estudos que já passaram por uma pré-
seleção com base na leitura do título e abstract, que foram obtidos a partir da
46
busca em periódicos e nos anais das conferências selecionadas nos anos
indicados (2006 a 2010).
Os estudos retornados e suas referências foram armazenados em
planilhas do Microsoft Excel™ e compartilhado na pasta do grupo no Dropbox3
de modo a facilitar o acesso e o gerenciamento dos documentos.
A Figura 9 apresenta este resultado e mostra que houve diversos
estudos duplicados que foram removidos.
Figura 9 – Resultado do processo de busca e seleção nas fontes de pesquisa

Os estudos retornados da busca automática foram quantitativamente

distribuídos da seguinte forma: ACM Digital Library (2.486), El Compendex
(1.587), IEEE Xplore (842), ISI Web of Science (399), ScienceDirect – Elsevier
(1.783), Scopus (1.363), SpringerLink (292), Wiley Inter Science Journal Finder
(890). O gráfico na Figura 10 ilustra a participação dos engenhos da busca
automática no montante dos estudos encontrados.
3
www.dropbox.com.br
47
Wiley Inter
Science Journal
SpringerLink Finder
3% 9%
ACM Digital
Library
Scopus 26%
14%
ScienceDirect – El Compendex
Elsevier 16%
19%
IEEE
Xplore
ISI Web of 9%
Science
4%
Figura 10 – Resultado da busca automática

Para a busca manual, os estudos retornados foram quantitativamente

distribuídos da seguinte forma: ACM Transactions on Software Engineering and
Methodology (1), Agile Development Conference (40), Computer IEEE Software
(38), IEEE Transactions on Software Engineering (4), International Symposium
on Empirical Software Engineering (ESEM) (25), Journal of the ACM (0) e o XP
Conference (95). O gráfico da Figura 11 apresenta a distribuição percentual da
busca manual.
Após a remoção dos estudos duplicados, os dados dos estudos (título,
autores, fonte de busca, ano de publicação, canal de publicação, etc.) restantes
(6.856) foram armazenados em uma planilha. Cada estudo recebeu um
identificador único para facilitar a comunicação entre os pesquisadores.
É importante ressaltar que em todas as etapas foram realizadas
reuniões para discutir e verificar o entendimento de cada pesquisador sobre os
procedimentos a serem adotados na execução da revisão. Como sugerido por
Kitchenham (2007), testes pilotos foram realizados e os pontos de desacordos
discutidos entre todos os pesquisadores, de modo que todos possuíssem um
entendimento comum.
48
ACM
Transactions on
Software
Engineering and
Agile Methodology
Development 0%
Conference
XP Conference 20%
47%
Computer IEEE
Software
19%
International
Symposium on IEEE
Empirical Transactions on
Journal of the Software Software
ACM Engineering Engineering
0% (ESEM) 2%
12%
Figura 11 – Resultado da busca manual

4.2.1.2.2 Etapa 2: Seleção dos estudos pelo Título e

Abstract
Os estudos da busca manual já foram selecionados com base na leitura do
título e abstract, sendo retornados 203 estudos. Os estudos da busca
automática sem as duplicações (6.467) com os estudos da busca manual foram
divididos igualmente entre três grupos de pares de pesquisadores, que
efetuaram a leitura do Título e Abstract. Apenas os estudos considerados fora
da área de pesquisa foram excluídos. Foi sugerido em reunião que, em caso de
dúvida sobre a potencialidade do estudo, o mesmo deveria ser incluído. Assim,
do total de estudos identificados, restaram 1.647 estudos potencialmente
relevantes.
Na próxima seção são apresentados os resultados da segunda etapa da
seleção dos estudos, com base na leitura da introdução e conclusão dos
estudos.
4.2.1.2.3 Etapa 3: Seleção dos estudos pela

Introdução e Conclusão
Os 1.647 potenciais estudos foram divididos e distribuídos para 03 grupos,
cada um com dois pesquisadores, para serem aplicados os Critérios de
Inclusão e Exclusão (ver a Seção 2.4 do APÊNDICE B) de forma
49
independente por cada pesquisador, com base na leitura efetuada sobre a
Introdução e Conclusão de cada estudo. Nas situações em que a partir desta
leitura não fica claro, inviabilizando a aplicação dos critérios, o estudo foi lido
na íntegra.
Os resultados do acordo de cada dupla (antes da convocação de um
terceiro pesquisador) sobre a aplicação dos Critérios de Inclusão e Exclusão
foram analisados e foi medido o índice de concordância desta etapa com base
no coeficiente Kappa. O resultado do coeficiente apresentado por cada dupla
foi: dupla 1 (K1 = 0.71), que indica graua de concordância substancial; dupla 2
(K2 = 0.88) que indica grau de concordância excelente; dupla 3 (K3 = 0.70) que
indica grau de concordância substâncial. Para interpretar o coeficiente,
consideramos a Tabela 1 a seguir, que apresenta uma classificação para os
intervalos do índice.
Tabela 1 – Valores de Concordância do índice Kappa (LANDS e KOCH, 1977)

Índice Kappa (K) Concordância
<0 Pobre
0.01 – 0.20 Ligeira
0.21 – 0.40 Considerável
0.41 – 0.60 Moderada
0.61 – 0.80 Substancial
0.81 – 1.00 Excelente
Os índices de concordância apresentados podem ter sido influenciados

pelos testes piloto que foram conduzidos, e pelas discussões sobre cada
critério a ser adotado na etapa.
Para cada desacordo identificado entre os pares, os mesmos
discutiram para tentar chegar a um consenso. Nos casos em que isso não foi
possível, um terceiro pesquisador foi convocado para aplicar o seu critério e
gerar o desempate.
Durante esta etapa foram excluídos 1.369 estudos, restando 278
potencialmente relevantes. A maioria das exclusões ocorreu em virtude dos
estudos não apresentarem dados empíricos, por apresentarem resultados com
50
o foco em práticas ágeis isoladas (pair programming, TDD, etc.) e não com o
uso de uma Metodologia Ágil, ou pelo motivo das metodologias ágeis não
serem o foco do estudo.
4.2.1.2.4 Etapa 4: Avaliação da Qualidade

Os estudos potencialmente relevantes que passaram pela etapa anterior foram
avaliados criticamente quanto a sua qualidade, de acordo com 10 perguntas.
Vale ressaltar que nesta etapa alguns estudos também foram excluídos (34),
pois foi consenso entre mais de um pesquisador que alguns não deveriam ter
sido incluídos na etapa anterior.
Após a avaliação, restaram 244 potenciais estudos que foram analisados
cuidadosamente para serem extraídos dados de modo a responder às
questões de pesquisa.
4.2.1.2.5 Etapa 5: Extração e Síntese dos Dados

A etapa de Extração de Dados foi realizada apenas pelo autor deste trabalho.
Alguns estudos precisaram ser excluídos por diversos motivos: 1) não
responderam a Q1; 2) não apresentaram dados empíricos sobre as
Metodologias Ágeis; 3) focaram em práticas isoladas das metodologias ágeis;
4) estudos que apenas afirmaram que houve algum benefício ou limitação, mas
não deixou claro quais seriam estes.
Todos os estudos excluídos pelo autor durante a extração foram
enviados a um segundo pesquisador, para que fossem discutidos e se
chegasse a um consenso. Deste modo, os resultados da extração de dados
são apresentados com base em 125 estudos primários, que foram obtidos
com base na aplicação dos métodos da Teoria Fundamentada em Dados
(Grounded Theory) e da Meta-etnografia sobre a leitura dos estudos primários.
Estes resultados estão descritos no Mapeamento das Evidências (Seção
4.2.2). A referência dos estudos primários e suas características encontram-se
disponíveis no APÊNDICE F e G.
Na seção a seguir, são apresentados dados importantes obtidos com
os estudos primários, como a distribuição temporal, a configuração dos
estudos, os métodos de pesquisa utilizados, etc.
51
4.2.1.3 Visão geral dos estudos
Esta seção apresenta as informações gerais dos estudos que foram obtidas a
partir da extração de dados.
Diversos tipos de metodologias ágeis foram investigados pelos
estudos, e o percentual encontrado de cada metodologia está apresentado no
gráfico da Figura 12, onde se pode notar que a maioria dos estudos
apresentou resultados de investigação com o Scrum (31,58%) e com o XP
(30,83%). Uma abordagem híbrida entre as duas metodologias teve uma
representação considerável (18,80%) com relação aos demais métodos
identificados.
O processo de busca incluiu as metodologias ágeis Lean e o Adaptive
Software Development, no entanto nenhum estudo potencialmente relevante
abordando esses métodos foi incluído nesta revisão.
Scrum, Kanban 0,75%

DSDM 0,75%
Feature Driven Development 0,75%
Crystal 0,75%
Mixed 1,50%
Mobile-D 1,50%
Agile Software Solution Framework 1,50%
Scrum (adaptado) 1,50%
General 9,77%
Scrum, XP 18,80%
XP 30,83%
31,58%
Scrum
Figura 12 – Métodologias Ágeis investigadas pelos estudos

A distribuição temporal dos estudos primários é apresentada no

gráfico da Figura 13, onde é possível perceber uma ascensão do quantitativo
de estudos que respondem a Q1 desta revisão a partir de 2006, mantendo-se
em equilíbrio de 2008 a 2010.
52
35 30 30
30 27
25 22
20 16
15
10
5
0
2006 2007 2008 2009 2010
Figura 13 – Distribuição temporal dos estudos primários

Os estudos primários foram publicados em Conferências (74,40%) e

Journal (25,60%), e distribuídos entre diversos canais de publicações (54)
como mostra a Tabela 2 e a Tabela 3. As conferências que tiveram maior
representatividade foi o XP Conference (20,80%) e o Agile Conference (8%).
Para os periódicos, em primeiro foi o Empirical Software Engineering (4%), em
seguida o Journal of Systems and Software (3,20%).
Tabela 2 – Distribuição dos estudos por conferências

Canal de Publicação Percentual (%)
XP Conference 20,80%
Agile Conference 8,00%
Hawaii International Conference on System Sciences 4,80%
EUROMICRO 4,80%
International Symposium on Empirical Software Engineering and

Measurement (ESEM) 4,00%
International Conference on Software Engineering (ICSE) 2,40%
Central and East European Conference on Software Engineering

Techniques 2,40%
International Conference Global Software Engineering 1,60%
Product-Focused Software Process Improvement (PROFES) 1,60%
International Conference on Software Engineering Advances

(ICSEA) 1,60%
Asia-Pacific Software Engineering Conference 1,60%
53
EuroSPI 1,60%
Workshop on Software Development Governance 1,60%
International Conference on Computational Science and its

Applications (ICCSA) 0,80%
Participatory Design Conference 0,80%
Conference of the Center for Advanced Studies on Collaborative

Research 0,80%
International Conference on Computer Science and Information

Technology (ICCSIT) 0,80%
Requirements Engineering Conference 0,80%
HCI and Usability for E-Inclusion 0,80%
International Conference on the Quality of Information and

Communications Technology (QUATIC) 0,80%
International conference on Reuse of Off-the-Shelf Components

(ICSR) 0,80%
National Software Engineering Conference 0,80%
SoutheastCon 0,80%
Australian Conference on Software Engineering 0,80%
Conference on Computational Intelligence for Modelling Control

and Automation (CIMCA) 0,80%
South African Institute of Computer Scientists and Information

Technologists on IT (SAICSIT) 0,80%
International Computer Software and Applications Conference 0,80%
International Conference on Software Technology and Engineerin

(ICSTE) 0,80%
International Conference on Software Science, Technology &

Engineering (SWSTE) 0,80%
Conference on Software Architecture and European Conference

on Software Architecture (WICSA/ECSA) 0,80%
Computing in the Global Information Technology (ICCGI) 0,80%
International Conference on Design of Communication (SIGDOC) 0,80%
International conference on On the move to meaningful internet

systems (OTM) 0,80%
54
International Conference on Enterprise Information Systems 0,80%
International Conference on Management of Innovation and

Technology (ICMIT) 0,80%
Total geral 74,40%
Tabela 3 – Distribuição dos estudos por periódico

Canal de Publicação Percentual (%)
Empirical Software Engineering 4,00%
Journal of Systems and Software 3,20%
European Journal of Information Systems 2,40%
IEEE Transaction on Software Engineering 1,60%
Journal of Information Systems Research 1,60%
Information and Software Technology 1,60%
Software Process: Improvement and Practice 1,60%
Human-Computer Interaction Symposium 0,80%
IT Professional 0,80%
Communications in Computer and Information Science 0,80%
Journal of the Brazilian Computer Society 0,80%
Journal of Computer Supported Cooperative Work 0,80%
Agility Across Time and Space 0,80%
Journal of Software Maintenance and Evolution: Research and
Practice 0,80%
International Journal of Information and Communication
Engineering 0,80%
Human Factors and Ergonomics In Manufacturing 0,80%
International Journal of Knowledge, Culture and Change
Management 0,80%
Information Systems Research 0,80%
International Journal of Human Computer Studies 0,80%
Total geral 25,60%
Os estudos, em sua maioria, possuem dados empíricos com pesquisas

realizadas na indústria (84,80%), e em ambientes acadêmicos (5,60%). O
55
restante foi distribuído em ambientes que misturam a academia e a indústria, e
ambientes governamentais.
Foram identificados quatro métodos de pesquisa nos estudos
primários como mostra a Tabela 4, com destaque para os Estudos de Caso
(60,80%), que, além de possuírem suas variações (estudo único ou de
múltiplos casos), foram utilizados em conjunto com outros tipos de métodos. O
segundo método mais encontrado foi o Survey (16,80%), conduzido mediante
aplicação de questionários.
Tabela 4 – Distribuição dos estudos por método de pesquisa
Método de pesquisa Quantitativo por método Percentual (%)
Estudo de caso 76 60,80%

Estudo de caso exploratório 9 7,20%
Estudo de caso múltiplo 5 4,00%
Estudo de caso, experimento 1 0,80%
Estudo de caso, pesquisa-ação 2 1,60%
Estudo de caso, survey 4 3,20%
Experimento 2 1,60%
Experimento, survey 1 0,80%
Pesquisa-ação 4 3,20%
Survey 21 16,80%
Total Geral 125 100,00%
A revisão identificou o envolvimento de 267 autores entre os estudos

primários selecionados. Entre os que mais publicaram estudos relevantes para
esta pesquisa estão: Pekka Abrahamsson (10), Nils Brede Moe (9), Helen
Sharp (6), Torgeir Dingsøyr (6), Frank Maurer (5), e Orit Hazzan, Tore Dybå,
Raimund Moser, Alberto Sillitti, Giancarlo Succi, Hugh Robinson, Kieran
Conboy, todos com 04 estudos.
Os países dos autores dos estudos também foram identificados,
apresentando um total de 33 países envolvidos com os estudos primários
desta revisão, com destaque para: Estados Unidos (47), Finlândia (41), Reino
Unido (36), Noruega (29), Irlanda (27), Itália (17), Brasil (16), Canada (16),
Suécia (14), e Israel (14).
No total foram 150 instituições de ensino ou organizações públicas
envolvidas nos estudos selecionados, entre as quais se destacam: SINTEF
56
ICT (20 estudos), The Open University (10 estudos), VTT Technical Research
Centre of Finland (10), Free University of Bolzano-Bozen (10), University of
Calgary (9).
Dos 16 estudos contribuídos pelo Brasil, foram identificadas 4
instituições de ensino: Universidade Federal de Santa Catarina (6),
Universidade de São Paulo (5), Universidade Federal de Pernambuco (3), e a
Universidade Federal do Rio de Janeiro (2).
4.2.1.4 Avaliação da qualidade

Esta seção apresenta os resultados para os 10 critérios de avaliação da
qualidade descritos no APÊNDICE B.
Antes de iniciar a etapa com os estudos desta revisão, foram
realizados testes pilotos com os estudos incluídos e avaliados por Dybå e
Dingsøyr (2008), de modo a entender como os pesquisadores da revisão
anterior realizaram a avaliação e para eliminar qualquer tipo de
desentendimento sobre os 10 critérios.
Os 244 estudos foram divididos e avaliados por quatro grupos, cada
grupo contendo dois pesquisadores. Cada pesquisador avaliou os estudos de
forma independente, e os resultados foram comparados entre as duplas. Os
desacordos em algum dos dez critérios foram resolvidos convocando-se um
terceiro pesquisador para realizar o desempate.
O índice de concordância de cada dupla foi analisado utilizando o
coeficiente Kappa. Os resultados do coeficiente apresentado por cada dupla
foram: dupla 1 (K1 = 0.69), dupla 2 (K2 = 0.66), dupla 3 (K3 = 0.31) e dupla 4 (K4
= 0.62). De acordo com os valores de concordância, obteve-se um valor médio
para este coeficiente, onde (K1 + K2 + K3 + K4) / 4 = 0.57, tendo desse modo,
um nível de concordância moderada, o que aumenta a confiabilidade dos
resultados dessa etapa.
O resultado apresentado nesta seção é correspondente aos 127
estudos que restaram após a extração de dados. No APÊNDICE H, são
apresentados os resultados da avaliação da qualidade de cada estudo. De
acordo com o resultado, os estudos foram classificados em 04 faixas de
qualidade (BELBIN, 1981 apud CARDOZO, 2012): baixa, média, alta e muito
57
alta. A Tabela 5 apresenta como foi feita a distribuição da pontuação entre as
faixas estabelecidas.
Tabela 5 – Distribuição da pontuação por Faixa de Qualidade

Baixa Média Alta Muito Alta
0≤N≤2 3≤N≤5 6≤N≤8 9 ≤ N ≤ 10
A distribuição dos estudos por faixa de qualidade ficou do seguinte

modo: Baixa (2), Média (41), Alta (76), Muito Alta (8). No entanto, devido ao
critério definido no protocolo, estudos com Baixa qualidade foram excluídos,
restando 125 estudos de qualidade entre Média e Alta. A faixa da qualidade
de cada estudo está ligada diretamente à nota atribuída a cada um dos 10
critérios.
O gráfico da Figura 14 apresenta a pontuação total que cada um dos
dez critérios da qualidade recebeu com base na avaliação dos 125 estudos.
Com base na análise do gráfico é possível perceber que os critérios 3, 4, 5 e 8
receberam baixa pontuação na avaliação da qualidade. Esses critérios são
discutidos a seguir.
120 111 110
105
97 97
100
80
60
47
40 35
25
20 12
0
Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10
Figura 14 – Pontuação de cada critério da avaliação da qualidade

O critério 3 (Q3) é relacionado ao design da pesquisa, onde foi

verificado se o estudo justificou o método utilizado. Todos os estudos deixaram
claro o método utilizado, no entanto a minoria (47), correspondendo a 37,60%
58
justificou o motivo do uso dos métodos.
O critério 4 (Q4) é relacionado à amostra utilizada no estudo, onde foi
verificado se foram explicados os motivos e critérios de seleção, se o tamanho
da amostra foi representativo, etc. Foi identificado que os estudos
apresentavam o tamanho total da população pesquisada, no entanto, apenas
35 estudos (27,56%) descreveram como os casos foram selecionados. Isso
aconteceu principalmente nos estudos em que foi utilizado o estudo de caso
como método de pesquisa.
Entre os critérios de mais baixa qualidade estão os critérios 5 e 8. De
acordo com a avaliação sobre o critério 5 (Q5), percebe-se que apenas 25
estudos (19,69%) apresentaram resultados em que tratamentos comparativos
de grupos de controle foram utilizados. E para o critério 8 (Q8), apenas 12
estudos (9,45%) apresentaram discussões sobre os potenciais vieses da
pesquisa.
Todas as evidências apresentadas são devidamente referenciadas
pelos 125 estudos primários da pesquisa. Os números das referências são
precedidos por ‘prs’ (potential relevant study), objetivando identificar cada
estudo na revisão. As informações bibliográficas de cada um desses estudos
estão disponíveis no APÊNDICE F.
4.2.2 Mapeamento das evidências

Esta seção apresenta os resultados para cada questão de pesquisa. Na Seção
0 são apresentadas as evidências para responder a primeira questão de
pesquisa, apresentando os benefícios e limitações das Metodologias Ágeis
identificados nos estudos primários. Na Seção 0, são apresentadas as
evidências que apoiam os resultados encontrados. E na Seção 0 são
apresentadas as implicações dos estudos identificados para a indústria de
software e a comunidade de pesquisa.
4.2.2.1 (Q1) O que atualmente se sabe sobre os

benefícios e limitações das Metodologias
Ágeis de desenvolvimento de software?
Esta é a questão principal da pesquisa que visa apoiar a problemática exposta
59
pelo trabalho, de modo a apresentar o que atualmente se sabe sobre os
benefícios e as limitações das Metodologias Ágeis no desenvolvimento de
software.
Com a condução desta Revisão Sistemática, foram identificados 125
estudos primários que respondem a essa questão de pesquisa, e que tiveram a
qualidade do estudo satisfatória de acordo com os critérios estabelecidos. Foi
realizada a análise e a extração dos dados nesses estudos, onde foram
encontrados diversos benefícios e limitações.
Na próxima seção serão apresentados os resultados dos benefícios, e
posteriormente os resultados das limitações.
4.2.2.1.1 Benefícios
Foram identificados 79 benefícios nos estudos, cuja lista completa e o
mapeamento destes com os estudos encontram-se no APÊNDICE I. Nos
próximos tópicos desta seção, são discutidos os 15 benefícios que mais foram
identificados nos estudos (Tabela 6) e no final é apresentado um mapeamento
dos benefícios por Metodologia Ágil. Os benefícios receberam um identificador
único, para se diferenciarem uns dos outros.
Tabela 6 – Quinze principais benefícios identificados nos estudos primários

% Total de
ID Descrição Benefício
estudos
B1 Facilita o compartilhamento do conhecimento entre a equipe 25,60%
B2 Melhora a comunicação da equipe 24,80%
B3 Facilita o acompanhamento e monitoramento do projeto 20,80%

B4 Feedback rápido/frequente 18,40%
B5 Melhora a qualidade do código 17,60%
B6 Permite uma maior colaboração entre a equipe 13,60%
B7 Aumenta a produtividade da equipe 11,20%
Melhora a comunicação entre o cliente (ou representante) e a
B8 11,20%
equipe
B9 Entrega frequente de software funcional 11,20%
B10 Melhora a qualidade do projeto 10,40%
B11 Reduz a documentação 10,40%
B12 Reduz a complexidade do código/projeto 10,40%
60
B13 Reduz a quantidade de defeitos/erros no projeto 10,40%
B14 Melhora o entendimento sobre o projeto 8,80%
B15 Facilita a interação entre a equipe 8,00%
B1. Facilita o compartilhamento do conhecimento entre a

equipe
Entre os benefícios identificados, o compartilhamento do conhecimento foi um
dos que mais foi identificado nos estudos. A Figura 15 apresenta as
metodologias e as práticas que proveram este benefício.
O método que mais proveu o benefício foi o XP, seguido do Scrum e
depois o ASSF (Agile Software Solution Framework). Também foram
encontrados estudos que falam de uma maneira geral sobre as metodologias
ágeis sem especificar o método.
Figura 15 – B1. Facilita o compartilhamento do conhecimento entre a equipe

A seguir, são apresentadas as práticas ágeis que mais foram

identificadas para o benefício em questão, e o mapeamento destas com alguns
estudos.
Pair Programming
O Pair Programming foi a prática ágil mais encontrada nos estudos, sendo
utilizada tanto em projetos que utilizam o XP, como em projetos com o Scrum e
ASSF. Em muitos estudos, essa prática propiciou a troca de conhecimento
entre os desenvolvedores, tanto em nível técnico, como de negócio para
entendimento do problema a ser desenvolvido. O estudo [prs322] realizou uma
61
pesquisa com estudos de casos múltiplos em empresas de desenvolvimento de
software da Áustria, com obtenção dos dados a partir de um survey, onde
60,5% dos entrevistados afirmaram que a prática da programação em par
possibilitou a transferência do conhecimento.
Os estudos ([prs44], [prs535]) informaram que a prática foi utilizada
somente em ocasiões para prover o equilíbrio de experiência entre
desenvolvedores experientes e novatos, a fim de expô-los em novas áreas de
código desconhecidas. Segundo o estudo [prs571], isso permitiu reduzir pela
metade o tempo de introdução de uma nova pessoa em um projeto.
Para as atividades em que foram necessários estudos para prover uma
solução para um problema técnico desconhecido, após a descoberta da
solução, o aprendizado pôde ser transferido por meio da programação em par
[prs591]. Além do compartilhamento do conhecimento para prover soluções,
habilidades técnicas de refactoring foram melhoradas com o uso da prática
[prs466].
Daily Stand Up Meetings

Outra prática bastante citada que potenciou esse benefício foram as reuniões
diárias (Daily Stand Up Meetings) utilizadas pelo Scrum e XP, que permitiram
que os membros das equipes dos projetos trocassem conhecimento técnico, e
o compartilhassem diariamente o andamento das atividades, permitindo uma
inspeção constante do projeto.
As reuniões diárias permitiram mais discussões entre os membros do
projeto, que compartilharam informações e receberam feedback de qualquer
parte interessada no projeto [prs879], além de manter as equipes atualizadas
em relação ao estado atual do projeto [prs1039].
Collective Ownership
A adoção da prática de propriedade coletiva foi percebida como uma maneira
eficaz de compartilhar o conhecimento. Um desenvolvedor da Nova Zelândia
[prs535] afirmou que devido a esta prática ágil, qualquer membro pôde
trabalhar em qualquer parte do código, independente da habilidade técnica.
Desenvolvedores do estudo [prs651] afirmaram que o código coletivo
assegurou que vários membros do projeto conheciam o código bem, o
62
suficiente para fazer mudanças ou alterações solicitadas.
Transcrições dos estudos

A seguir, seguem algumas transcrições extraídas durante a análise dos
estudos que justificam tal benefício.
"Hence it is no surprise that we found knowledge sharing and

access to relevant expertise to be well supported. For example,
in all teams, pairs were formed explicitly on occasions to
provide a balance between experience and novice novice
status in order to expose novices to areas of the code that they
did not know.” – prs44
“They are performed by all teams together everyday before

lunch with the purpose to keep everyone up to date with the
current status of the project and to exchange useful
information.” – Project manager, prs1039
“We just didn’t do things based on technical skills...people

would just grab whatever and if they couldn’t do it themselves,
they get help. And that worked well.” – prs535
B2. Melhora a comunicação da equipe

O Manifesto Ágil possui como princípio a forte ênfase na comunicação durante
o projeto. Por isso que diversas metodologias ágeis possuem práticas que
propiciam a comunicação constante entre os envolvidos no projeto.
Entre os estudos primários, a melhoria na comunicação da equipe foi
um dos benefícios que mais foi identificado. A Figura 16 apresenta as
metodologias e as práticas que proveram este benefício.
63
Figura 16 – B2. Melhora a comunicação da equipe
A metodologia ágil que mais proveu tal benefício foi o Scrum, seguido
do XP, e após, uma abordagem híbrida utilizando o Scrum e XP. Também foi
identificado o benefício com o uso do Mobile-D, uma metodologia ágil para
desenvolvimento de softwares para dispositivos móveis.
estudos primários.

De acordo com os estudos, as reuniões diárias das equipes que utilizavam o
XP e/ou o Scrum permitiram uma melhoria significativa na comunicação da
equipe [prs1583], pois, de acordo com um desenvolvedor [prs1491], a prática
permitiu manter uma comunicação aberta entre a equipe, o que aumentou a
comunicação global do projeto [prs1296]. Um desenvolvedor do estudo
[prs1037] informou que essas reuniões diárias, de comunicação aberta e direta
entre os desenvolvedores, são a forma mais importante de obter feedback em
um projeto.
Diversos outros estudos apontaram uma melhoria na comunicação da
equipe, no entanto, apenas informaram o a metodologia ágil utilizada, não
informando quais foram as práticas que foram utilizadas que proveram tal
benefício ([prs135], [prs236], [prs490], [prs688], [prs694] e [prs1607]).
64
Co-location team
A adoção da prática de equipes colocalizadas permitiu um espaço comunitário
e útil que melhorou a comunicação, colaboração e a coordenação entre os
membros da equipe [prs719], e tem sido um sucesso no projeto. Só não tem
sido um sucesso total, porque ainda ocorrem muitas interrupções [prs1497].
Devido à melhoria na comunicação, houve menos necessidade de
documentação [prs1497], pois todos sabiam o que o outro estava fazendo
[prs1136] e a equipe estava perto o suficiente para realizar a comunicação face
a face, facilitando a resolução de problemas e discussão de design [prs797].
Uma equipe de um projeto trabalhou por um bom tempo colocalizada,
no entanto, posteriormente, teve que separar os membros em lugares
diferentes. Esta nova forma de trabalho foi percebida como negativa por um
desenvolvedor, já que a comunicação espontânea é importante para o projeto
[prs1001].
Face to face communication

Permitir a comunicação face a face entre os envolvidos nos projetos foi um dos
benefícios identificados pelo estudo [prs1037], de modo que a comunicação
direta foi o meio mais importante de feedback percebido nas reuniões diárias.

“However, the daily meetings increased the overall

communication.” – Developer, prs1296
“The most important form of feedback found in the project was

the daily feedback [Daily Stand Up Meetings] given in the
direct communications between developers, QAs, and spocs
in order to get a common understanding about what the
content of the user stories was.” – Developer, prs1037
“Generally the Developers and the Testers were physically

close together. The lack of co-location was highlighted as an
65
issue showing a recognition of the value of spontaneous
communication and an acknowledgement of what could be
lost if conversations were not “overheard”.” – Developer,
prs1001
B3. Facilita o acompanhamento e monitoramento do projeto

A facilidade de acompanhar e monitorar um projeto foi identificada como um
dos grandes benefícios providos pelas metodologias ágeis, em especial o
Scrum, e em seguida o XP. A Figura 17 apresenta as metodologias e as
práticas que proveram este benefício.
Figura 17 – B3. Facilita o acompanhamento e monitoramento do projeto


estudos.

As reuniões diárias foram identificadas nos estudos como a principal prática
que permitiu o acompanhamento e monitoramento dos projetos, tanto em
equipes que utilizam o Scrum, quanto em XP. A pesquisa [prs1530] apresentou
um estudo de caso de um projeto que utiliza o XP, onde as reuniões realizadas
todas as manhãs foram consideradas pelos desenvolvedores o ponto-chave de
partilha do conhecimento e percepção da situação do projeto. O mesmo pode
ser confirmado pelos estudos ([prs1133] e [prs767]). Além disso, os estudos
([prs466] e [prs918]) informaram que tais reuniões são importantes para
66
identificar e discutir os problemas existentes no projeto.
Task board
As metodologias ágeis como o Scrum, XP e Kanban propõem o uso do quadro
de tarefas para as equipes, que foi utilizado por alguns estudos, provendo o
benefício de facilitar o acompanhamento e monitoramento do projeto, devido ao
seu aspecto visual.
Os estudos ([prs1530] e [prs719]) afirmaram que o uso do quadro foi
benéfico para os projetos, possuindo uma estrutura que oferece às equipes
uma ideia clara de progresso/status do trabalho. O quadro revela informações
importantes [prs564], o que permite um compartilhamento visual que ajuda a
entender a situação de cada tarefa, e do projeto como um todo [prs651].
Sprint Review
A reunião de Revisão da Sprint (Sprint Review) do Scrum foi vista como
provedora de informações que permitem acompanhar e monitorar o projeto,
sendo útil para discutir o progresso, e encontrar precocemente os problemas
([prs636] e [prs716]). Ainda, o estudo [prs918] afirmou que esta reunião,
quando ocorre com a participação dos interessados, permite uma maior
visibilidade e transparência do projeto, e ajuda o gerente de projeto com uma
supervisão mais eficiente.
Sprint Retrospective
A reunião de retrospectiva da Sprint (Sprint Retrospective) foi identificada em
estudos que utilizam o Scrum, por permitir uma boa visão sobre o progresso
atual do projeto para os envolvidos [prs879], além de permitir a identificação
dos problemas, e a avaliação das iterações passadas do projeto [prs636].
Ainda, o estudo [prs797] afirmou que tais reuniões são importantes para apoiar
o rastreamento, ajudando as equipes a entenderem o ritmo do projeto,
melhorar o processo e o desempenho para as próximas iterações.

A seguir seguem algumas transcrições extraídas durante a análise dos estudos
que justificam tal benefício.
67
“In these meetings [Daily Stand Up Meetings] the project team
members were informed what had been done thus far, and
what needed to be done; any existing problems were also
covered in these meetings.” – prs918
“There are status boards [Task board] showing information,

such as status of the work, in the communal space of each
team room. Anyone can get this information just by looking at
the boards without disturbing team members.” – Developer,
prs719
“Meetings [Review and Retrospective] are useful to discuss

progress, encountered problems of team members and
evaluation of past iteration/project.” – Developer, prs636
B4. Feedback rápido/frequente

O Manifesto Ágil valoriza a comunicação e o feedback rápido e constante no
projeto, de modo a permitir um melhor relacionamento entre a equipe, e melhor
gerenciamento do projeto. Para isso foram definidas diversas práticas técnicas
e de processos entre as mais diversas metodologias ágeis que seguem este
valor.
Diversos estudos primários apresentaram resultados de que o uso das
metodologias ágeis propiciou um feedback rápido/frequente durante o projeto.
O XP foi o método que mais foi identificado por prover tal benefício, seguido do
Scrum e após os estudos que utilizaram uma abordagem híbrida do Scrum e
XP.
A Figura 18 apresenta as metodologias ágeis e as práticas utilizadas
que permitiram o benefício em questão.
68
Figura 18 – B4. Feedback rápido/frequente

estudos primários.
Short iterations
As metodologias ágeis valorizam as iterações curtas por permitirem um
feedback frequente. O gerente de um projeto de desenvolvimento de software
na Alemanha afirmou que as pequenas iterações do processo ágil facilitaram
os testes de usabilidade e interface com o usuário, que permitiram a avaliação
rápida do produto e proveram feedbacks rápidos, facilitando as possíveis
correções e melhorias o mais rápido ([prs1016], [prs1607]).
O estudo [prs591] apresentou um relato de um desenvolvedor que
afirmou que as entregas semanais são melhores, por permitirem descobrir
cedo quando existe a falta de entendimento de requisitos do usuário por parte
dos desenvolvedores, do que um mês depois.

69
“[...] The usability tests and evaluating UI with users bring lot of
feedback to be fixed, so it was easy for us to fix those
usability results into small iterations of agile process.” –
Project manager, prs1016
“Software functionality progress can be checked and

monitored much more frequently rather than at end of long
milestones.” – Developer, prs1607
“Every week we have a delivery. It’s better to discover that

you have not understood some user requirements after a
week than after one month.” – Developer, prs591
B5. Melhora a qualidade do código

A melhoria na qualidade do código foi identificada em diversos estudos, sendo
a maioria destes em projetos nos quais foi utilizado o método XP. Alguns
estudos que utilizaram abordagens híbridas também foram identificados. A
Figura 19 apresenta as metodologias e as práticas ágeis que proveram este
benefício.
Figura 19 – B5. Melhora a qualidade do código


estudos.
70
Pair Programming
A programação em par foi a prática mais encontrada por prover o benefício em
questão, devido a constante revisão do código entre dois membros dos
projetos, e as discussões geradas entre os pares para prover uma melhor
solução de design ao problema.
Em entrevista realizada pelo estudo [prs1037] com um desenvolvedor,
o mesmo afirmou que os membros do projeto haviam parado com o uso da
programação em par, mas retornaram, pois a prática proveu uma melhoria
significativa, tanto na produtividade da equipe, como na qualidade do código.
Desenvolvedores do estudo [prs571] afirmaram que com o uso da
prática, a qualidade do código melhorou em termos de design, sendo
descobertos menos erros no projeto.
TDD
A prática do desenvolvimento orientado a testes foi identificada por diversos
desenvolvedores como benéfica para os projetos, por permitir produzir os
códigos com melhor qualidade, devido aos designs simples e constantes
refatoramentos propostos pela prática.
O estudo [prs1001] apresentou relatos de um desenvolvedor que
sentiu que o uso da prática melhorou a qualidade, e ainda outro desenvolvedor
[prs1002] comparou o código produzido por uma equipe com o uso do TDD,
com um código similar produzido pela mesma equipe aplicando métodos
tradicionais, e afirmou que o código com o TDD foi significantemente melhor.
Tais benefícios são vistos por um desenvolvedor [prs1019] como resultado da
simplicidade, eliminação da complexidade e constante melhoria da qualidade
proposta pela prática.
Refactoring
A prática de refactoring foi benéfica por prover a simplicidade, e eliminar a
complexidade dos códigos dos projetos. Esta prática está muito associada à
prática do TDD que aplica constantes refatoramentos do código, como pôde
ser percebido o uso associado das práticas nos estudos ([prs1019], [prs1607]).
Um desenvolvedor do estudo [prs1607] afirmou que o uso da prática
71
promove a maior reutilização e um código de melhor qualidade. Ainda,
arquitetos de software afirmaram que com o uso de refatoramentos, foi possível
tanto no nível de código, quanto de arquitetura, alcançar atributos de qualidade
desejados, como prover melhorias na capacidade de manutenção do projeto
[prs488].
Continuous integration
A integração contínua foi a prática menos observada nos estudos para prover a
melhoria na qualidade do código, tendo apenas dois estudos associados. Em
[prs27] foi conduzido um estudo de caso, onde um entrevistado afirmou que a
integração contínua permitiu melhor controle do processo, transparência, e
aumentou a qualidade do projeto, pois permitiu que pequenas tarefas fossem
gerenciadas. As alterações ocorridas no projeto puderam ser implementadas
com maior facilidade, devido à integração do código, de acordo com um
desenvolvedor [prs1019].

“Developers realized that PP [Pair Programming] also helped
produce better code in terms of design quality and the
number of bugs discovered later.” – Developers, prs571
“Ongoing refactoring leads to higher code reuse and better

quality.” – Developer, 1607
“[...] the code produced with an agile methodology [TDD] [...]

[...] significantly better than similar code produced by the
same team using more traditional methods.” – Developer,
prs1002
"Developers from large companies [...] confirmed that the

practice [Continuous Integration] improves code quality,
enabling the implementation of late changes.” – Developer,
prs1019
72
B6. Permite uma maior colaboração entre a equipe
As metodologias ágeis enfatizam a comunicação e a interação entre a equipe,
por isso que nos estudos primários foram identificadas diversas práticas que
propiciam a maior colaboração entre os membros da equipe.
Entre os estudos, o XP e o Scrum foram os métodos mais identificados,
seguidos pelo ASSF e uma abordagem híbrida do Scrum e XP. A Figura 20
apresenta esses métodos e as práticas utilizadas que permitiram o benefício
em questão.
Figura 20 – B6. Permite uma maior colaboração entre a equipe

A seguir, são apresentadas as metodologias ágeis com as respectivas

práticas que mais foram identificadas para o benefício em questão, e o
mapeamento destas com alguns estudos.
Projetos Scrum
Nos estudos em que o Scrum foi utilizado, algumas práticas ágeis foram
identificadas, sendo: metas compartilhadas, Sprint Planning, Daily Stand Up
Meetings, Collective Code, Iterative and Incremental.
O estudo de caso [prs535] avaliou 16 organizações de software
distribuídas em diversos países. Um desenvolvedor de um dos projetos
estudados afirmou que a Sprint é um compromisso da equipe, ao invés de um
esforço individual, o que permite a ajuda mútua entre os membros, para atingir
o objetivo.
Devido a esta característica do Scrum em trabalhar com metas
compartilhadas, o planejamento e controle das Sprints também envolve toda a
73
equipe [prs651]. Durante a execução das Sprints ocorrem as reuniões diárias
(Daily Stand Up Meetings), que, de acordo com o estudo [prs716], também
foram percebidas como uma maneira eficaz de permitir a colaboração entre a
equipe.
Projetos XP
Os projetos que utilizam o XP valorizam a comunicação frequente e direta entre
a equipe, o que, segundo o estudo [prs1132], propicia o rápido
desenvolvimento, que as dúvidas sejam sanadas, os problemas sejam
resolvidos, e a colaboração entre os membros seja garantida. No entanto, o
ambiente deve ser adequado para permitir essa comunicação e colaboração. O
estudo [prs719] afirmou que o espaço comum (Co-location team) melhora a
comunicação, colaboração e coordenação entre os membros da equipe.

“The sprint is a commitment of the team, so if a story’s not

getting finished, that means somebody is not doing their job...
it’s a team effort as opposed to an individual effort.” –
Developer, prs535
“[Sprint] Planning and tracking become a collaboration involving

the whole team.” – Developers, prs651
“By having every member of the team see every day [Daily
Stand Up Meetings] what every other team member was
doing, the team's productivity, morale, adaptability,
accountability and collaboration will significantly increase.” –
prs716
“One of the main factors associated with enjoyment and

excitement in agile software development teams was the ease
and speed by which team members could get things done;
74
questions were answered, problems were resolved, and
collaborative opportunities were quickly grasped.” –
Developer, prs1132
B7. Aumenta a produtividade da equipe

Foi perceptível nos estudos que houve aumento da produtividade das equipes
devido ao uso das Metodologias Ágeis. O Scrum foi o principal método que
proveu tal benefício, seguido do XP, e alguns estudos trataram de uma maneira
geral, sem explicitar o método. Ainda foi encontrado benefício utilizando uma
abordagem híbrida do Scrum e XP em um estudo. No entanto, mesmo com o
aumento da produtividade mencionado, poucos estudos apresentaram
informações comparativas de situações antes e depois do uso das
metodologias ágeis. A Figura 21 apresenta as metodologias e as práticas
ágeis que proveram este benefício.
Figura 21 – B7. Aumenta a produtividade da equipe


estudos.
Aspectos gerais das Metodologias Ágeis

Alguns estudos não especificaram qual a prática que proveu o benefício,
descrevendo os resultados encontrados em torno do método. Todos esses
estudos se tratavam do uso do Scrum nos projetos.
O benefício foi identificado pelo estudo [prs689], que relatou um estudo
75
de caso em uma empresa de grande porte, utilizando o desenvolvimento
distribuído de software entre os escritórios localizados em diversos países. De
acordo com o estudo, a produtividade de seus projetos do usando o Scrum
foram aumentados em 40%, em comparação ao projeto tradicional.
O estudo [prs1607] conduziu um survey em uma empresa de grande
porte (Microsoft), onde foram obtidas 492 respostas. Entre os respondentes,
foram incluídos desenvolvedores, testadores e gerentes. As metodologias
ágeis utilizadas pelos respondentes em seus projetos eram o Scrum e/ou XP.
Entre os dez maiores benefícios encontrados no estudo devido ao uso das
metodologias ágeis estava incluído o aumento na produtividade da equipe.
Pair Programming
A prática da programação em par foi identificada em dois estudos por prover
aumento na produtividade da equipe. Um estudo abordou o método de XP, e
outro uma abordagem híbrida de uso do Scrum e XP.
O estudo [prs1037] apresentou um estudo de caso da indústria, onde
um desenvolvedor afirmou em entrevista que o uso da programação em par
aumentou significativamente a produtividade da equipe, e, como consequência,
a qualidade do projeto.
O estudo [prs466] apresentou resultados da indústria de estudos de
casos múltiplos em diversos contextos (financeiro, empresa de segurança,
transporte) de sistemas que utilizaram o método ágil XP, e informou que o uso
das práticas ágeis (design simples, TDD, refactoring, código coletivo, e a
programação em par) aumentou a produtividade da equipe e o feedback sobre
o código, e reduziu o retrabalho.
Refactoring
A prática de refactoring foi relatada em dois estudos que apresentou resultados
no aumento da produtividade das equipes.
O estudo [prs17] realizou um experimento próximo da indústria
(participação de estudantes e profissionais do mercado), onde foram efetuadas
análises no código do projeto, antes e depois de ser realizado o refactoring.
Como resultado, constatou-se que houve um aumento significativo na
produtividade da equipe depois de o código ser refatorado.
76
O estudo [prs466] afirmou que as tarefas que envolveram código
refatorado levaram menos tempo (22h) para serem desenvolvidas, e permitiu
um desenvolvedor afirmar que a refatoração melhorou a produtividade do
projeto.

“[...] they returned to pair programming, and the interviewee

telling about this reported a significant improvement in both
productivity and quality as a consequence.” – Developer,
prs1037
“Tasks which involved refactored code took less hours and

refactoring during the first iteration took 22 hours, so we can
say that refactoring had actually improved productivity.” –
Developer, prs466
B8. Melhora a comunicação entre o cliente (ou representante) e

a equipe
A comunicação e a interação com o cliente e demais patrocinadores do projeto
são um dos princípios do Manifesto Ágil, de modo a melhorar o relacionamento
e obter sucesso no projeto. Alguns estudos apresentaram informações de que
o uso das metodologias ágeis, em especial o Scrum e XP, propiciou uma
melhora na comunicação entre o cliente e a equipe. A Figura 22 apresenta as
metodologias ágeis e as práticas utilizadas que permitiram o benefício.
77
Figura 22 – B8. Melhora a comunicação entre o cliente (ou representante) e a equipe

estudos.
Projetos XP
Nos projetos mencionados nos estudos que utilizaram o XP, algumas práticas
foram citadas por permitir essa melhoria, como as reuniões de planejamento
das iterações, que, utilizando a prática do Jogo do Planejamento (Planning
Game), foi o principal meio de comunicação entre a equipe de desenvolvimento
e o cliente [prs767]. A prática também foi importante para o estudo [prs49],
que possuía diversos interessados no projeto, dificultando o acordo de noções
de qualidade entre as partes. Assim, a prática intensificou a comunicação,
necessária para chegar a permitir o consenso.
Outra prática identificada foram as histórias de usuário colocadas em
cartões de parede (Cards wall), que facilitou a comunicação com o cliente
[prs593] e permitiu sua aproximação com a equipe de desenvolvimento
[prs1497].
estudos.
“Throughout the project, the project management personnel

and the development lead took part in release and iteration
planning meetings. During the first month of the project, these
78
meetings [Planning Game] served as the primary means of
communication between the two groups.” – Developer,
prs767
“FinanApp recognized that different stakeholders may have

different notions of quality and adopted the practice of
‘planning game’ that facilitated intense communication that
was necessary to reach an agreement on quality.” – prs49
“Cards promote collaboration between developers and

customers.” – Developers, prs593
“Stories were a mechanism to bring customers closer to the

development and reveal the core requirements” – Developer,
prs1497
B9. Entrega frequente de software funcional

O desenvolvimento ágil de software preza pela entrega frequente de software,
dividido em pequenos ciclos iterativos. Alguns estudos primários apresentaram
resultados em que foram obtidos benefícios com esta prática. O método ágil
que mais reportou este benefício foi o XP, seguido do Scrum.
A Figura 23 apresenta estes métodos e as práticas ágeis utilizadas por
esses estudos.
Figura 23 – B9. Entrega frequente de software funcional

79
estudos.
Short iterations or releases

O benefício das iterações curtas foi identificado em estudos que utilizaram o XP
e o Scrum. O estudo [prs434] conduziu um survey envolvendo 10 empresas de
desenvolvimento de software do Recife-PE (Brasil) que utilizaram o Scrum, e
apresentou como resultado a correlação de entrega frequente de software, com
o sucesso dos projetos. A mesma correlação foi identificada no estudo
[prs129].
Constant communication
A comunicação foi um fator importante por permitir a entrega frequente de
software, conforme os resultados de um survey apresentado em [prs331], pois
de acordo com a maioria das organizações pesquisadas que utilizaram as
metodologias ágeis, foi o contato ativo com o cliente que garantiu a entrega
mais rápida e frequente de software.

“[...] only eight of the 25 attributes presented a significant

correlation to project success: A01 - Regular delivery of
software [...]” – prs434
“Most of the organizations practicing agile methodologies have

their business analysts associated with clients who keeps
an active contact with them, ensuring faster delivery of
releases to the end users and improving productivity.” – prs331
B10. Melhora a qualidade do projeto

A ênfase na qualidade do projeto é preocupação das diversas metodologias
ágeis, possuindo, assim, técnicas e práticas para beneficiar o projeto como um
80
todo. Foram identificadas nos estudos primários algumas melhorias ocorridas
nos projetos em virtude do uso das metodologias ágeis, com destaque para o
XP e o Scrum. A Figura 24 apresenta as metodologias ágeis e as práticas
utilizadas que permitiram o benefício.
Figura 24 – B10. Melhora a qualidade do projeto


estudos.
Projetos Scrum
Alguns benefícios foram identificados com o uso do Scrum em alguns estudos,
como é apresentado por [prs1583], que apresenta o resultado de um estudo de
caso, onde foram realizadas algumas entrevistas. Entre os entrevistados, o
Product Owner disse que, devido ao uso do Scrum, o foco na qualidade do
projeto aumentou por causa do constante feedback que ocorrem nas reuniões.
Um desenvolvedor entrevistado informou que o número de defeitos reduziu
devido a constante comunicação que ocorriam nas reuniões diárias.
O estudo [prs688] afirmou que o uso do Scrum melhorou a qualidade
do projeto como um todo, e, para [prs689], a qualidade do projeto foi
aumentada em 36%.

81
“During the interviews, the Product Owner commented that the
focus on software quality had increased after introducing
Scrum, because of continuous feedback in the daily
meetings, short sprints, and sprint retrospectives.” –
Product Owner, prs1583
"I believe it should be fewer defects after introducing Scrum

because we are now communicating more frequently about
what we were doing before. Especially the short meetings
every morning improve the team communication [...]" –
Developer, prs1583
“One of the biggest differences to the earlier way of working

was an improvement in overall quality” – prs688
“Therefore, the productivity and quality of international

deployment projects of Chameleon [agile] have been increased
by 40% and 36% respectively, compared to Zorro [traditional]”
– prs689
B11. Reduz a documentação

Um dos valores do Manifesto Ágil é realizar a documentação apenas do que for
necessário e útil ao projeto. Alguns estudos primários apresentaram indícios de
que a quantidade de documentação foi reduzida a partir do uso das
Metodologias Ágeis. Tais estudos em sua maioria apresentaram resultados de
projetos que utilizaram o método ágil XP, seguidos do ASSF, e depois do
Scrum. Um estudo com abordagem híbrida também foi identificado. A Figura
25 apresenta as metodologias ágeis e as práticas utilizadas que permitiram o
benefício.
82
Figura 25 – B11. Reduz a documentação

estudos.
Working software over comprehensive documentation

Diversos estudos não explicitaram a prática ágil a qual foi utilizada para permitir
a redução da documentação. No entanto, esses estudos deixaram claro que
essa redução foi em virtude do ambiente ágil, por isso tratamos um dos valores
do Manifesto Ágil como responsável por tal benefício.
O estudo [prs1114] informou que com a introdução do Scrum na
organização, foi possível gastar mais recursos apenas em atividades que
geravam valor, como o código, o que minimizou o trabalho de documentação. E
esta redução foi vista positivamente pela organização. O mesmo ocorreu com o
estudo [prs1665], que realizava uma extensiva documentação que nunca era
finalizada, e com a implantação do Scrum nos projetos, documentou apenas o
essencial. E isso foi visto positivamente por um desenvolvedor do projeto.
No projeto do estudo [prs1039], a quantidade de documentação foi
reduzida, permitindo mais tempo para trabalhar na implementação do software.
Isso foi visto positivamente pelo gerente do projeto, e pelos desenvolvedores.
No entanto, alguns desenvolvedores afirmaram que não poderiam parar de
fazer a documentação por completo. Foi necessário o equilíbrio para definir o
que é essencial ao projeto.

83
“The reduced focus on documentation was throughout the

organization received positively.” – Organization, prs1114
“And you were kind of wasting that time during all this
repetition, and those documents never get up to date. So they
were not even useful once the project was done, you know.
They did not reflect reality any more. That was part of the
biggest improvement [reduced documentation] I saw in
development with Agile over Waterfall.“ – Developer, prs1665
“Quite a number of different documents exist, but they are all

comparably short and concise.” – Developer, prs1039
B12. Reduz a complexidade do código/projeto

A redução da complexidade do código e do projeto foi identificada nos estudos
que fizeram o uso do método XP. Esse resultado pode ser justificado devido o
método possuir bastante foco em práticas de codificação. A Figura 26
apresenta as práticas de XP que permitiram o benefício.
Figura 26 – B12. Reduz a complexidade do código/projeto


estudos.
84
Práticas de XP
Cinco práticas de XP foram identificadas nos estudos, sendo as principais: TDD
e Refactoring.
O estudo [prs1002] apresentou os resultados de estudos de casos
múltiplos, que objetivou analisar o impacto do uso das metodologias ágeis
sobre o código. O TDD foi uma das práticas analisadas, onde foi identificado
que o seu uso reduziu a complexidade ciclomática do código.
Devido ao uso do TDD com testes automatizados, aplicado juntamente
com a prática de Recfactoring, um gerente identificou que a prática proveu um
feedback constante, ajuda a manter o código mais simples, e melhora a
qualidade do mesmo [prs1019]. A simplicidade gerada pela prática aumentou a
velocidade do desenvolvimento do projeto [prs466] e permitiu uma maior
segurança para modificar o código [prs1078].
A prática de Refactoring permitiu eliminar as duplicações de código,
simplificando e tornando o código mais flexível [prs918], consequentemente
aumenta a produtividade das equipes no curto prazo [prs17].

“[...] when the agile methods [TDD] were employed, the

Cyclomatic number has decreased.” – prs1002
”One of the biggest effects [of TDD] is that it is easy to do even

big changes in the code as long as it does the same thing.” –
prs1078
“’Refactoring’ which restructures the system by removing

duplication, improving communication, simplifying and
adding flexibility, provided both teams with a better
understanding of project outputs.” – prs918
“[...] we can conclude that the productivity data sustain the

claim that refactoring raises development productivity in the
85
short-term, thus nullifying to some extent the complexity
naturally added during development.” – prs17
B13. Reduz a quantidade de defeitos/erros no projeto

A busca pela qualidade do código e melhoria do projeto são características das
Metodologias Ágeis. De acordo com os estudos primários, alguns foram
selecionados por permitirem ao beneficio de reduzir a quantidade de erros e/ou
defeitos nos projetos. O principal método que proveu tal benefício foi o XP. A
Figura 27 apresenta as metodologias ágeis e as práticas utilizadas que
permitiram o benefício.
Figura 27 – B13. Reduz a quantidade de defeitos/erros no projeto


estudos.
Pair Programming
A prática da programação em par foi identificada em cinco estudos, entre os
quais, quatro foram em projetos que utilizavam o XP, e o outro o método ASSF.
O estudo [prs56] apresentou um estudo em que um projeto utilizou o
método ágil ASSF, juntamente com a prática da programação em par. Neste
estudo, desenvolvedores do projeto afirmaram que o uso da prática ajudou a
melhorar a qualidade do código, o que fez surgir menos bugs relatados durante
os testes de aceitação do usuário. Os mesmo resultados foram percebidos
pelos desenvolvedores do estudo [prs571].
A falta da prática da programação em par, em um projeto que já
86
utilizava a prática anteriormente, ocasionou em aumento na taxa de falhas em
uma iteração do projeto [prs1352].
TDD
A relação entre o uso do TDD com o benefício em questão foi identificada em
03 estudos ([prs571], [prs1002] e [prs1078]), todos utilizando o método XP,
apresentaram resultados de estudos de casos que relataram a diminuição da
quantidade de erros nos projetos após o uso da prática de TDD.

“PP [pair programming] and PR [pair review] both helped to

improve the quality of the services (components) before user
acceptance testing and very few bugs were reported during
user acceptance testing.” – Developer, prs56
”TDD reduces a number of bugs. I would say it improves my

way of working 10 to 20 per cent [...].” – prs1078
B14. Melhora o entendimento sobre o projeto

A compreensão sobre o projeto como um todo é fundamental para o sucesso
do mesmo. Entre os estudos primários, foram identificados diversos benefícios
relacionados às práticas ágeis em projetos que utilizaram o Scrum e XP, como
mostra a Figura 28.
Figura 28 – B14. Melhora o entendimento sobre o projeto

87
dentificadas para o benefício em questão, e o mapeamento destas com alguns
estudos:
Projetos XP
Devido à pouca repetição das práticas relacionadas ao benefício, abordaremos
neste tópico todos os benefícios identificados devido ao uso do XP.
O valor do Manifesto Ágil de comunicação constante foi percebido
entre os projetos com o XP, onde o estudo [prs980] afirmou que ter se
comunicado com frequência com o cliente facilitou a compreensão das suas
necessidades. E o estudo [prs49] afirmou que o intenso envolvimento do
cliente no processo ajudou a equipe a entender melhor as suas expectativas.
Seguindo o valor da comunicação constante, um desenvolvedor
afirmou que as reuniões diárias (Daily Stand Up Meetings) serviram para
discutir problemas e buscar entendimento sobre detalhes do projeto [prs767]. A
prática de On-site customer que também valoriza a comunicação, de acordo
com o resultado de um survey [prs129], é um dos fatores críticos de sucesso
dos projetos ágeis.
O TDD ajudou a manter uma visão compartilhada sobre o projeto,
facilitando o melhor entendimento sobre o que é cada funcionalidade, de
acordo com a perspectiva do cliente [prs918].
Projetos Scrum
Nos projetos que fizeram uso do Scrum, nenhuma prática ágil ganhou destaque
sobre a outra. A cerimônia da Sprint Planning, segundo o estudo [prs918],
permitiu reduzir os mal-entendidos e confusões sobre o projeto.
A elaboração dos testes de aceitação, devido ao uso do TDD, forneceu
uma visão clara e suficiente para os desenvolvedores implementarem o código
[prs604]. As reuniões diárias, de acordo com um gerente de projeto
apresentado no estudo [prs1594], facilitaram o entendimento e alinhamento da
visão sobre o projeto.

88
“This meeting [Daily Stand Up Meetings] also served as a

forum for the developers to discuss any issues that needed
to be resolved with the project management team. The
development manager could also use this time to explain
design details or project planning details that the developers
needed to know.” – Developer, prs767
“Test Driven Development (TDD) also helped to maintain a

shared standard development view, facilitating a better
understanding of what functionality was required from the
client perspective.” – prs918
“It is now easier to communicate what is happening in the

market. After a meeting with a potential customer I always use
1-2 minutes informing the team about what happened in the
next daily stand-up.” – Project manager, prs1594
B15. Facilita a interação entre a equipe

Devido à ênfase dada pelo Manifesto Ágil para as interações entre os
indivíduos, e a comunicação entre eles, diversas práticas ágeis seguem esses
valores. Alguns estudos primários relataram que as metodologias ágeis
facilitaram a interação entre a equipe. A Figura 29 apresenta os métodos e as
práticas utilizadas por esses estudos.
Figura 29 – B15. Facilita a interação entre a equipe

89
estudos.
Projetos Scrum
Todas as reuniões do Scrum, desde o planejamento até a última reunião de
uma Sprint, foram identificadas por facilitarem a interação entre os membros da
equipe, como foi descrito pelo estudo [prs1525].
De acordo com o estudo [prs918] que apresentou os resultados de um
estudo de caso de projetos distribuídos, a Sprint Planning proporcionou uma
boa interação entre os participantes do projeto, ajudando a reduzir os
entendimentos equivocados.
Projetos XP
O estudo [prs1132] em que foi aplicado o XP afirmou que houve a forte
valorização dos indivíduos e a interação entre eles, o que facilitou o
entendimento das necessidades do projeto, e o gerenciamento do mesmo. Isso
foi perceptível também no estudo [prs1610], que afirmou que essa relação
aumentou a camaradagem entre os membros da equipe.

“The participants felt that since team had been together for
about eighteen months and because of the rich
communication among the team (daily calls, frequent
reviews and planning), the team had developed excellent
informal relationships which helped them handle the
disruption better.” – prs1525
"The “Sprint planning meeting” which provided close

interaction among distributed project stakeholders that helped
to minimize misunderstanding and misinterpretations about
project standards." – prs918
90
“And so once we started adopting some of the agile
techniques [XP] in the previous product I was working on, they
were very welcomed. It was instantly recognizable as a
pleasant way to work for the people, for the developers, for
the managers, for everybody involved; because there is
less crisis, it’s easier to manage, you have a better idea of
what it really takes to deliver what people are asking for. It’s so
much more manageable. . . I mean it takes out uncertainty, it
reduces the risk, crisis management, it’s easy to schedule
and plan — everyone’s happier.” – prs1132
“XP increases the degree of interaction among team

members, and this leads to a high degree of camaraderie.” –
Developer, prs1610
Mapeamento dos Benefícios por Metodologia Ágil

Diversos benefícios foram identificados pela Revisão Sistemática, provenientes
do uso de diversas metodologias ágeis. O gráfico da Figura 30 mostra as sete
metodologias ágeis que permitiram os benefícios identificados e quantidade de
benefícios associados a cada uma delas.
A metodologia ágil XP foi a que mais proveu benefícios
individualmente, estando relacionada a 59 (74,68%) benefícios identificados na
literatura. Em segundo lugar vem o Scrum, relacionado com 54 (68,35%). A
abordagem híbrida do Scrum e do XP está associada à 31 (39,24%) benefícios.
70 59
60 54
50
40 28 31
30
20 9
10 1 1 3
0
Figura 30 – Quantidade de benefícios da literatura por Metodologia Ágil

91
4.2.2.1.2 Limitações
Foram identificadas 63 limitações nos estudos, cuja lista completa e o
mapeamento destas com os estudos encontram-se no APÊNDICE J. Nos
próximos tópicos desta seção, são discutidas as 15 limitações que mais foram
identificadas nos estudos (Tabela 7) e no final é apresentado um mapeamento
das limitações por Metodologia Ágil. As limitações receberam um identificador
único, para se diferenciarem uma das outras.
Tabela 7 – Quinze principais limitações identificadas nos estudos primários

% Total de
ID Descrição Limitação
estudos
L1 Falta de estudos empíricos com os métodos ágeis 29,92%
L2 Dificuldade de trabalhar com individualismo e especializações 10,24%

L3 Aspectos culturais 9,45%
Dificuldade em aplicar práticas ágeis com equipes inexperientes
L4 7,09%
em Métodos Ágeis
L5 Dificuldade de se trabalhar com equipes não ágeis 6,30%
Falta de informações históricas, relatórios e métricas para apoiar
L6 5,51%
o gerenciamento
Dificuldade de comunicação / coordenação entre equipes
L7 3,94%
distribuídas
L8 Dificuldade de programação em par 3,94%
L9 Dificuldade em trabalhar com limite de tempo 3,94%

L10 Aumenta a pressão para entrega do trabalho 3,15%
L11 Aumenta os custos do projeto 3,15%
L12 Dificuldade de se adaptar a constantes mudanças 3,15%
L13 Dificuldade para se trabalhar com equipes grandes 3,15%
L14 Falta de planejamento de longo prazo 3,15%
L15 Pouca documentação 2,36%
L1. Falta de estudos empíricos com as metodologias ágeis

Entre os estudos primários, a falta de estudos empíricos foi a principal limitação
encontrada das Metodologias Ágeis, sendo identificada em 38 estudos,
representando 29,92% do total de incluídos. A Tabela 8 apresenta estes
estudos e o foco das evidências encontradas.
92
Tabela 8 – Descrição do foco das limitações empíricas
ID Categoria Foco das limitações empíricas
prs448 Arquitetura de software Arquitetura de software com metodologias
ágeis
prs535 Autogerenciamento Natureza do autogerenciamento e desafios
das equipes ágeis na prática industrial
prs688 DDS Desenvolvimento distribuído com
metodologias ágeis
metodologias ágeis
metodologias ágeis
prs597 DDS / Comunicação Comunicação em projetos ágeis distribuídos
prs1625 Eficácia Eficácia de práticas ágeis
prs129 Geral Fatores críticos de sucesso dos projetos ágeis
de software
prs1610 Geral Análise da aplicação das metodologias ágeis
em países emergentes
prs723 Geral Qualidade dos sites desenvolvidos com
metodologias ágeis
prs809 Geral Adoção das metodologias ágeis nos países
emergentes
prs322 Geral Aplicação prática das metodologias ágeis
prs651 Geral / Adaptação Adaptação das metodologias ágeis

prs612 Geral / Design Tomada de decisão de design em equipes
ágeis
prs434 Geral / Efeitos Sucesso dos projetos com as metodologias
ágeis
prs236 Geral / Empresas de Uso das metodologias ágeis em empresas de
serviços prestação de serviços
prs428 Geral / Evolução Evolução de software com as metodologias
ágeis
prs591 Geral / Prática Teoria e prática das metodologias ágeis
93
prs1335 Geral / Projetos de larga Aplicação das metodologias ágeis em projetos
escala de larga escala
prs1112 Gerenciamento Gerenciamento de defeitos
prs123 Gerenciamento Gerenciamento de risco
prs452 Linhas de Produto de Metodologias ágeis e Linha de produto de
Software Software
prs462 MPS Resultados dos estudos com MPS e as
metodologias ágeis
prs1607 Organizações Aplicação das metodologias ágeis em
tradicionais organizações tradicionais
prs17 Refactoring / Impacto do refactoring na produtividade
Produtividade
prs700 Requisitos Priorização e re-priorização de requisitos em
projetos ágeis
prs610 Satisfação Satisfação de equipes ágeis e não ágeis
prs346 Satisfação Metodologias ágeis e a satisfação das partes
interessadas
prs1296 Scrum Eficácia de uma equipe Scrum
prs1301 Scrum Aplicação do Scrum em projetos de larga
escala
prs1583 Scrum Efeitos do Scrum sobre a qualidade do
software
prs703 TDD Melhoria de código com o TDD
prs1019 XP Vantagens do XP
prs1497 XP Efeitos do XP sobre a comunicação
O uso das Metodologias Ágeis no Desenvolvimento Distribuído de

Software (DDS) foi o assunto mais abordado sobre a falta de evidências
empíricas. De acordo com o estudo [prs688], existem apenas alguns relatos de
experiência utilizando essas abordagens no ambiente industrial, e como essas
estão sendo adaptadas [prs689].
O problema da comunicação em DDS foi citado por alguns estudos, e
para suprir essa problemática, práticas ágeis foram utilizadas. No entanto, os
estudos ([prs687] e [prs608]) afirmaram que pouco ainda se sabe sobre a
94
comunicação em um ambiente ágil distribuído.

estudos que justificam tal limitação.
“Nevertheless, advice on pairing agile software development

and GSD, also referred to as distributed agile development
(DAD), is scarce. There are only a few reported experiences
in applying DAD to industrial projects [...]” – prs688
“Little is published about the adoption and adaption of Agile

methods in a distributed team and software
globalization/localization project environment.” – prs689
“Despite this, little is known about communication in

distributed agile development.” – prs687
“Distributed development is already burdened with several

problems and agile methods bring further challenges in the form
of their reliance on verbal communication and volatile
requirements. There is little empirical knowledge on
distributed agile software development.” – prs608
L2. Dificuldade de trabalhar com individualismo e

especializações
Um aspecto comportamental que limita o desenvolvimento e uso das práticas
ágeis é o individualismo e as especializações das equipes. Tais limitações
poderiam ser incluídas nos Aspectos Culturais, mas, foi preferível agrupar em
categorias separadas, devido à razoável quantidade de estudos que
apresentaram tais limitações.
O estudo [prs1296] apresentou resultados de um estudo de caso, onde
ocorreram problemas devido ao individualismo existente em alguns membros
da equipe. Um desenvolvedor do projeto declarou que durante as reuniões
diárias alguns membros da equipe não escutavam o que os demais membros
95
estavam dizendo. Poucos problemas foram discutidos nessas reuniões, pois os
desenvolvedores encaravam-os como problemas pessoais.
A especialização da equipe causou problemas para as reuniões de
planejamento da Sprint (Sprint Planning), de acordo com o estudo [prs1031],
onde uma especialista em um domínio se recusou em participar da reunião,
alegando que não queria saber como as atividades seriam estimadas pela
equipe, por possuir especialidade diferente de outros membros, dificulta o
entendimento sobre o que cada especialidade iria fazer.
O Scrum foi adotado pelo projeto do estudo [prs135], sendo utilizado o
autogerenciamento das equipes, onde cada membro tinha a liberdade de
escolher suas próprias atividades. Um desenvolvedor reconheceu isso não foi
bom para o projeto, pois houve menos interação entre a equipe.

“The daily scrum was held almost every day, but people did
often not listen to what others were talking about [...]” –
Developer, prs1296
“[..] one of the specialists refused to participate in the

estimation/planning process at all. She [...] "didn't care"
about the number on the items associated with her. The
reason she gave was that in a specialized team it was difficult
to understand what the other specialists were actually
going to do.” – Developer, prs1301
“When it comes to the daily scrum, I do not pay attention

when Ann is talking. For me, what she talks about is a bit far
off the topic and I cannot stay focused. She talks about the
things she is working on. I guess this situation is not good for
the project.” – Developer, prs135
96
L3. Aspectos culturais
As metodologias ágeis possuem princípios e valores que priorizam a satisfação
do cliente, a entrega frequente de software funcional, a colaboração entre a
equipe, a motivação da equipe, a comunicação face à face, entre tantos outros.
Por isso, para a adoção de tais metodologias, são necessárias mudanças
comportamentais dos indivíduos e das organizações, o que pode ocasionar em
resistências, ou diversas barreiras culturais para a sua adoção. A Figura 31
apresenta as principais limitações impostas por aspectos culturais identificados
nos estudos.
Figura 31 – L3. Aspectos culturais

De acordo com o estudo [prs1607], onde foi conduzido um survey na

Microsoft para entender os benefícios e as limitações das metodologias ágeis
sob a visão particular das equipes investigadas, foi identificado que muitas
vezes tais métodos exigem mudança de mentalidade e comportamento que os
desenvolvedores não estão dispostos a aceitá-las. Por isso, de acordo com o
estudo [prs797], é mais fácil ensinar as metodologias ágeis aos programadores
inexperientes do que aos mais experientes.
O estudo [prs1069] apresentou uma situação em que uma equipe
realizou um treinamento com uma metodologia ágil, e o gerente não. Isto
ocasionou dificuldades para continuar com os processos ágeis, pois o gerente
quis trabalhar da maneira tradicional (cascata), identificando todos os requisitos
no início do projeto.
A necessidade de mudança de comportamento também foi identificada
como uma barreira para as metodologias ágeis, de acordo com dois estudos
que apresentaram resultados empíricos com o Scrum. Em [prs688], foi
97
apresentado um estudo de caso de projetos distribuídos que utilizou o Scrum,
onde foram identificados problemas na comunicação durante as reuniões
diárias da equipe, pois descendentes da cultura asiática se comunicavam
pouco, dificultando saber o andamento e os impedimentos de suas tarefas.

“[...] agile development often requires a change in mindset

that developers may not be eager to undertake.” – Developer,
prs1607
“From our experience, we also noticed that it is usually easier

to teach agile practices to inexperienced programmers.
More mature, experienced programmers sometimes tend to
resist against agile practices such as Test-First
Programming, Collective Code Ownership, and Pair
Programming because they have to change dramatically
their work style.” – prs797
"While the majority of the team received training it was reported

that the product managers did not and they stuck to the old
waterfall method of trying to clarify all requirements up-front.” –
Project manager, prs1069
“In the beginning, it was difficult to encourage everybody to

talk and tell enough about their tasks and impediments. This
was the case especially for persons coming from an Asian
culture.” – Developer, prs688
L4. Dificuldade em aplicar práticas ágeis com equipes

inexperientes em Metodologias Ágeis
Foram identificadas nos estudos primários limitações provenientes da
dificuldade de serem aplicadas algumas práticas ágeis, devido à inexperiência
98
da equipe em utilizá-las. As práticas identificadas foram: TDD, Simple Design,
User Stories, Daily Stand Up Meetings, sendo o TDD a prática mais
identificada, que estava associado aos projetos em que o XP foi utilizado, como
mostra a Figura 32.
Figura 32 – L4. Dificuldade em aplicar práticas ágeis com equipes inexperientes em

Metodologias Ágeis
De acordo com os resultados do estudo de caso [prs462] sobre 05

projetos que utilizaram o XP, foi identificado que foi difícil a aplicação do TDD,
devido à falta de experiência na prática, e que não foi realizado nenhum
treinamento com as equipes. Tal problema também foi identificado pelo estudo
[prs1002], onde afirmou que a prática necessita de pessoas com experiência
na mesma.
O estudo [prs1607] afirmou, de acordo com a opinião de um
desenvolvedor, que as reuniões diárias do Scrum muitas vezes se tornaram
ineficientes devido à falta de experiência da equipe com as Metodologias
Ágeis.

“The unit testing problems were mostly related to the test-

driven development (TDD). [...] in the first two projects there
was simply not enough training and expertise available for
applying TDD.” – Developer, prs462
“That is, in general, or whatever tip I can give is to have one
99
good really experienced guy in the team that has worked
with TDD before. Otherwise you will take short cuts probably.”
– prs1002
“Scrum meetings were sometimes considered inefficient,

especially when the team was inexperienced with Agile, or it
was large (over 8-10 people).” – Developer, prs1607
L5. Dificuldade de se trabalhar com equipes não ágeis

O uso das metodologias ágeis nos projetos exigem mudanças de
comportamento, e às vezes, após essas mudanças, torna-se difícil o
relacionamento entre equipes ágeis e não ágeis. Nos estudos primários foram
identificadas limitações que envolvem o relacionamento entre essas equipes.
O estudo [prs1212] afirmou que existem projetos que envolvem
equipes ágeis e clientes que não possuem tal cultura, ou o contrário também
pode ocorrer. Sendo considerado problemático pelo estudo, pois, por exemplo,
se os clientes são adeptos às metodologias ágeis, os mesmos irão querer uma
comunicação mais direta com os membros da equipe. Esse problema na
comunicação também foi identificado pelos estudos ([prs597] e [prs687]).
Um survey foi conduzido pelo estudo [prs346], e identificou-se que
muitos projetos ainda não aderiram às metodologias ágeis, devido aos desafios
de misturá-las com as metodologias tradicionais.

“Both scenarios can be problematic, but when an external

client is an agile believer they will want and require direct
interaction with team members.” – prs1212
“This lack of agile adoption highlights possible challenges

faced by developers in attempting to blend agile with more
traditional methods.” – prs346
100
L6. Falta de informações históricas, relatórios e métricas para
apoiar o gerenciamento
Os gestores dos projetos utilizam muitas vezes informações obtidas durante os
projetos para auxiliarem às tomadas de decisões. No entanto, em 07 estudos
identificou-se que as metodologias ágeis ainda carecem dessas informações.
O estudo [prs813] apresentou informações sobre um estudo de caso
de uma empresa multinacional de grande porte, que desenvolvia sistemas B2B
de maneira distribuída, onde foram utilizadas as metodologias Scrum e XP. No
entanto, em um dos projetos da empresa, um gerente foi relutante em adotar o
Scrum, pelo motivo de que o mesmo necessitava de dados históricos de
desempenho da equipe, para poder iniciar o projeto.
O estudo de caso apresentado em [prs1069] descreveu um projeto em
que foi utilizado o XP, e um gerente do projeto afirmou que a abordagem ágil
utilizada não permitiu a obtenção de dados para custos de análise e
estatísticas sobre o projeto. O mesmo foi identificado no estudo [prs135], onde
um desenvolvedor afirmou que a falta de informações sobre o progresso do
projeto como um todo tornou difícil monitorar o desempenho dos membros da
equipe.
Uma declaração de um gerente de projeto apresentado no estudo
[prs1607] afirmou que seus superiores estavam preocupados com a dificuldade
que teriam para elaborar relatórios e obter métricas em um ambiente de
trabalho ágil.

"On a more rational note, another manager explained why he

was reluctant to implement Scrum in his distributed project
teams in the first place: We have nothing [historical
performance data] to base what a Scrum model could deliver
... and I don’t want to be the first one to sign up for that
process." – prs813
101
“Management was also used to a delivery date, costs
analysis and statistics on progress being presented however
this was also not available.” – Project manager, prs1069
“[...] However, the team did not manage to update the plan
[Task board] to adapt to the changing conditions. Subsequently,
it was unclear how much progress had been made, which
made it difficult to monitor team members’ performance.” –
Developer, prs135
“Many program managers were worried that upper-level

management would ask for progress reports and productivity
metrics that would be hard to gather in an Agile work
environment.” – Project manager, prs1607
L7. Dificuldade de comunicação/coordenação entre equipes

distribuídas
O Manifesto Ágil e as diversas metodologias valorizam a comunicação entre os
indivíduos, e possuem reuniões e/ou práticas que permitem a coordenação das
equipes, e entre a equipe. No entanto, alguns estudos em que foram
apresentadas informações sobre projetos de desenvolvimento distribuído de
software, a comunicação e a coordenação têm se tornado difícil.
Os estudos ([prs1019], [prs12] e [prs689]) afirmaram que ocorreram
problemas na comunicação nos projetos apresentados devido às diferenças
culturais, que impediram a boa comunicação e coordenação entre as equipes.
Visando eliminar essas problemáticas, os projetos apresentados adotaram as
práticas ágeis. No entanto, devido à distribuição geográfica e a diferença de
fuso horário, as práticas ágeis não foram suficientes para suportar totalmente a
melhoria na comunicação entre as equipes.

102
“Distributed work across multiple teams and cultural
differences between agile and traditional teams hinder
communication and coordination among teams” – prs1019
“It was very difficult because of problems with the

communication.” – Project manager, prs12
“Most challenges faced by distributed teams are related to

communication and trust.” - prs689
L8. Dificuldade de programação em par

A prática da programação em par, onde duas pessoas sentam juntas para
resolverem um único problema, é uma das práticas de XP, mas quem tem sido
utilizada também em projetos que adotam outras metodologias.
Diversas dificuldades foram relatadas nos estudos com o uso desta
prática, todas elas em projetos que utilizaram o método XP. Uma dessas
dificuldades foi o conflito de personalidade, como apresentada em 3 estudos.
No estudo [prs1019], problemas foram relatados sobre as dificuldades que
alguns programadores têm quando se trabalha com outros. Esses problemas
foram percebidos também foram percebidos por [prs49], alegando que a
prática estava gerando tensões entre a equipe, tendo que ser abandonada,
acontecendo o mesmo com [prs1001].
Outros estudos apresentaram alegações de que os desenvolvedores
não gostavam de trabalhar em par, pois preferiam encontrar as soluções por
conta própria [prs705], e em [prs651], alguns desenvolvedores afirmaram que
a prática quebrava o fluxo de concentração, pois era difícil se concentrar com
alguém ao lado.
O estudo [prs705] também apresentou informações de que trabalhar
em par todos os dias foi inviável, e em [prs651], a prática era inviável para
problemas simples ou bem compreendidos, ou aqueles que poderiam ser
rapidamente resolvidos por um único desenvolvedor.

103
"Problems have been reported on the difficulties some

programmers have when working with others [...]” – prs1019
“TransApp experimented with paired development in the

beginning, but quickly found that it ‘was creating tensions that
were not conducive to the development goals’.” – prs49
"[...] but there was much concern regarding personality

conflicts.” – Project manager and developer, prs1001
“In team W one developer openly confessed that he didn’t like

pairing because he preferred to get on with things on his
own [...]” – Developer, prs705
“Team B also reported that they gave up trying to pair all day
every day because it became too intense and difficult to
sustain." – Developer, prs705
“[...] it was found to be unsuitable for simple or well-

understood problems, which could be fixed as quickly as a
single developer could type." – Developer, prs651
L9. Dificuldade em trabalhar com limite de tempo

As metodologias ágeis Scrum e XP trabalham com períodos de tempo bem
definidos, chamando a isso de “Time Box”, que são utilizadas nas iterações ou
Sprints, e nas reuniões. Com o uso do tempo definido para realização das
atividades, diversos problemas foram identificados.
De acordo com o estudo de caso apresentado em [prs1301], um
desenvolvedor afirmou que era um desafio estipular um tempo fixo de
desenvolvimento para as atividades difíceis de serem avaliadas.
Trabalhar com tempo definido também foi um problema para um
desenvolvedor apresentado no estudo [prs1583]. De acordo com o mesmo,
trabalhar dessa maneira foi como ter uma pistola no pescoço, o que dificultou a
104
refatoração das tarefas, porque a equipe precisava entregar o que havia
prometido. Um problema semelhante foi percebido no estudo [prs448], onde
um arquiteto de software afirmou que essa abordagem reduziu a possibilidade
de escolha de uma melhor solução de design.

que justificam tal limitação.
"The need to timebox the activities that were difficult to

evaluate and were quite different from the activities of the rest
of the team remained a challenge for some time." –
Developer, prs1301
“It is like having a pistol against your neck. It’s good and bad.
You fix things now and not later. But there are also tasks you
should have done like code refactoring. I think we do not use
enough time on refactoring, because you need to deliver
what you promised, and what the team promised.” –
Developer, prs1583
“We found that agile teams were forced to focus on a limited

number of solutions to achieve the required features within
time and budget. One risk of this approach was architects
might have missed out on a possibly better design choice
by not really doing full design upfront.” – Software architect,
prs448
L10. Aumenta a pressão para entrega do trabalho

Bastante relacionada à categoria anterior, esta limitação foi identificada em
diversos estudos que apresentaram resultados de projetos que utilizaram
iterações curtas em seus projetos.
O estudo [prs1583] apresentou os resultados de um estudo de caso,
onde um desenvolvedor afirmou que o Scrum faz com que os desenvolvedores
se sintam mais estressados para entregar funcionalidades no tempo e
105
orçamento, do que com as abordagens tradicionais. De acordo com o estudo
[prs1037], um desenvolvedor afirmou que essa pressão gera insatisfação dos
membros do projeto.
O mesmo foi percebido no estudo [prs813], que afirmou que o Scrum
sobrecarregou os membros da equipe de um projeto com mais demandas com
prazos curtos e constante pressão para a entrega.

"However, Scrum makes developers feel more stress to

deliver functionalities on time and budget than the plan-
driven process." – Developer, prs1583
“[...] originate in dissatisfaction among the project members,

and when the pressure built up.” – Developer, prs1037
“Again, Scrum seemed to be burdening team members with

more demands on time and constant pressure” – Developer,
prs813
L11. Aumenta os custos do projeto

Com base nos resultados apresentados por alguns estudos primários, foi
possível extrair informações de que o uso das metodologias ágeis aumentaram
os custos dos projetos. Entre os 04 estudos identificados, 03 estão associados
ao uso da prática de Pair Programming, e um à prática de Unit Testing.
De acordo com o estudo [prs1001], a prática de programação em par
foi utilizada em 30% do tempo na primeira fase de um projeto. No entanto, com
base nas entrevistas aplicadas durante a segunda fase, houve barreiras ao uso
da prática devido ao aumento de custos por causa de duas pessoas
associadas a um único problema. Esse mesmo problema foi identificado no
estudo [prs571].
A aplicação dos testes de unidade foi vista como benéfica, no entanto,
106
existem custos adicionais que envolvem a necessidade de mudar os processos
atuais do projeto de acordo com o estudo [prs809].

“Pair programming was on average used only about 30% of the

time and generally between experienced and inexperienced
pairs, but from analyzing the second stage interviews the main
barrier to using it was pressure on resources. [...]” – Project
manager, prs1001
“Substantial problems arose when the consequences of

pairing - higher costs - were exposed to the client.” – prs571
“Unit Testing: The benefits are clear, but many organizations

have yet to establish a formal unit testing framework. Many
cited the additional costs involved, and the need to change
their current processes.” – prs809
L12. Dificuldade de se adaptar a constantes mudanças

Um dos valores do Manifesto Ágil é responder às mudanças mais que seguir
um plano. No entanto, em alguns estudos foi identificado que existiram
dificuldades nos projetos para se adaptarem às mudanças.
Um projeto em que o Scrum foi utilizado, o Product Owner do projeto
que representava vários clientes passou a ter problemas, pois sempre eram
apresentadas novas ideias, mesmo durante a Sprint. Essas constantes
mudanças dificultavam a melhoria do produto e do processo [prs1238].
O estudo [prs1260] analisou a influência das mudanças ocorridas nos
projetos com o sucesso dos mesmos, conduzindo para isso um survey e
entrevistas. Como resultado, foi possível identificar que existe uma influência
negativa significativa. Tais influências também foram percebidas no estudo
[prs135], pois a equipe não conseguiu atualizar o plano do projeto para se
adaptar às mudanças, o que tornou difícil o monitoramento do desempenho
107
dos membros da equipe.

“The Product Owner constantly visited existing and potential

new customers. When he got back he presented several new
ideas, even during the sprint. The Scrum-master did not
manage to protect the team, and this decreased the level of
autonomy.” – Developer, prs1238
"Linear regression analysis was used to investigate the

influence of requirement changes on project success. [...]
[...] The analysis shows a significant negative influence [...]” –
prs1260
"[...] We observed the team being sensitive to changes in both

the internal and external environment. However, the team did
not manage to update the plan to adapt to the changing
conditions. Subsequently, it was unclear how much
progress had been made, which made it difficult to monitor
team members’ performance." – Developer, prs135
L13. Dificuldade para se trabalhar com equipes grandes

Com a ascensão do uso das Metodologias Ágeis nos projetos de
desenvolvimento de software, equipes com variações distintas de tamanho
(pequena, média e grande porte) têm utilizado tais metodologias. Os estudos
primários identificaram algumas limitações com o uso dessas metodologias,
estando principalmente associadas aos projetos que utilizaram o Scrum.
O estudo [prs1607] apresentou problemas que foram identificados por
meio de um survey, como as reuniões do Scrum que foram consideradas
ineficientes devido à inexperiência da equipe com metodologias ágeis, ou pelo
motivo de ser grande (08 a 10 pessoas). O problema da escalabilidade das
Metodologias Ágeis também foi identificado no estudo [prs27], afirmando que o
108
mesmo causa uma sobrecarga de gerenciamento e coordenação.
Problemas com as reuniões de Revisão (Review) e diárias foram
percebidos em dois estudos. Em [prs1133] as reuniões diárias se tornaram
tediosas em função do grande tamanho da equipe, pois pontos abordados
durante a reunião por alguns desenvolvedores foram irrelevantes para outros.
Os mesmos problemas ocorreram nas reuniões de revisão, onde alguns
desenvolvedores sentiram que as mesmas eram um desperdício de tempo
[prs1037].

“Scrum meetings were sometimes considered inefficient,

especially when the team was inexperienced with Agile, or it
was large (over 8-10 people).” – Developer, prs1607
"Management overhead and coordination: Agile methods do not

scale well (I03). In fact, we found that it is challenging to make
agile methods scalable” – prs27
"The entire team participated in daily stand-up meetings.

Developers noted that this exercise could become tedious
with their team size, since some points brought up by
developers seemed irrelevant to others on the team who
had little to do with other people’s components.” – Developer,
prs1133
“This happened around the demo sessions that were held at the
end of Sprint [Review]. The number of participants and the
amount that should be demoed made this event grow to a size
so that many felt it was a waste of time.” – Developer,
prs1037
109
L14. Falta de planejamento de longo prazo
Quatro estudos apresentaram informações de que o uso das metodologias
ágeis desencadeou a falta de planejamento de longo prazo. Entre esses
estudos, 3 apresentaram resultados com o método Scrum, e um com o XP.
De acordo com os estudos ([prs1595], [prs652] e [prs910]),
desenvolvedores sentiram que estavam perdendo a visão total do projeto,
devido ao foco em módulos individuais e à falta de compreensão do sistema a
ser desenvolvido como um todo, o que dificultou fazer projeções de prazos dos
projetos.

"The focus on individual modules was probably one of the

reasons that several developers felt they were missing the total
overview of the project. Without a clear understanding of the
system being developed, planning was difficult." – Developer,
prs1595
“[...] during the planning phase, the original scrum method only
focuses on incremental sprints, therefore not allowing a
clear picture of the overall project schedule.” – prs652
“[...]. Still however, they [Scrum] lack long-term release

strategy.” – prs910
L15. Pouca documentação

Um dos valores do Manifesto Ágil é que os projetos passem a valorizar o
software funcionando, mais do que documentação abrangente. Esse valor
ocasionou em alguns projetos a redução da documentação, que não foi bem
vistas nos resultados de três estudos.
De acordo com o estudo [prs1665], houve problemas na relação com o
cliente, pois o mesmo queria uma documentação do projeto mais abrangente,
110
tornando assim, a transição para o método ágil difícil.
Outro problema foi identificado no estudo [prs44], onde as decisões da
comunicação informal não foram documentadas e foram esquecidas por uma
das partes envolvidas.
Para o estudo [prs910], a redução da documentação limitou os
registros históricos do processo, e com relação ao código do projeto, limitou o
conhecimento dos desenvolvedores sobre o mesmo, e dificultou realizar
análises da causa raiz dos problemas.

“From her experience with customers, she explained that the

switch to Agile is often difficult because of how it changes the
relationship to process and documentation.” – Developer,
prs1665
“In each team, we found evidence of breakdowns, or potential

breakdowns. Informal communication can breakdown when
the parties involved don’t have a common memory of the
conversation and what was decided.” – prs44
“Lack of process documentation, on the other hand, leads to

the problem of not being able to make root cause analyses
and to track important steps and decisions about the system
and the process.” – prs910
Mapeamento das Limitações por Metodologia Ágil

Diversas limitações foram identificadas pela Revisão Sistemática, provenientes
do uso de diversas metodologias ágeis. O gráfico apresentado na Figura 33
mostra as sete metodologias ágeis com o quantitativo de limitações
identificadas na literatura para cada método.
A metodologia ágil XP foi a que mais teve limitações associadas
111
individualmente, estando relacionada com 37 (58,73%) limitações identificadas
na literatura. Em segundo lugar vem o Scrum, relacionado com 22 (34,92%). A
abordagem híbrida do Scrum e do XP está associada a 14 (22,22%) limitações.
Nenhuma limitação foi identificada para metodologia ASSF e para a abordagem
híbrida do Scrum e Kanban.
40 37
35
30
25 22
20 14
15
10 5
5 0 1 1 0
0
Figura 33 – Quantidade de limitações da literatura por Metodologia Ágil

4.2.2.1 (Q2) Qual a força da evidência em apoio às

conclusões encontradas?
De acordo com Dybå e Dingsøyr (2008b), existem trabalhos que apresentam
informações de como avaliar a força das evidências de revisões sistemáticas.
Um desses trabalhos é a abordagem “Grades of Recommendation
Assessment, Development and Evaluation Working Group” (GROUP, 2004),
com base em uma hierarquia de evidências, estando no topo as revisões
sistemáticas e os experimentos aleatórios. No inferior da hierarquia estão os
estudos baseados em observações e opiniões de especialistas.
Dybå e Dingsøyr (2008b) não concordam plenamente com esta
hierarquia, pois afirmam que experimentos aleatórios nem sempre são
exequíveis e que em alguns casos, estudos qualitativos e observacionais
podem proporcionar melhores evidências, particularmente na engenharia de
software.
Com base no sistema GRADE, Dybå e Dingsøyr (2008) sugerem que os
estudos primários em engenharia de software sejam avaliados com base em
três critérios: o rigor do estudo, a credibilidade dos métodos utilizados para
112
chegar aos resultados apresentados e a relevância do estudo para a indústria e
a comunidade de pesquisa. Com base nesses critérios, os estudos primários
foram avaliados criticamente quanto à sua qualidade metodológica com base
em 10 questões que abordavam o rigor, a credibilidade e a relevância dos
estudos. Os 125 estudos primários incluídos na revisão possuíam sua
qualidade entre média, alta e muito alta.
Os métodos de pesquisa utilizados nos estudos primários em sua
maioria (97) apresentavam resultados a partir de estudos de caso, com coleta
de dados com base em entrevistas e observações. O que de acordo com o
Dybå e Dingsøyr (2008b), podem proporcionar melhores evidências na
Engenharia de Software.
Os estudos incluídos foram apenas de estudos de projetos reais
(acadêmicos ou da indústria) que utilizavam as metodologias ágeis, sendo
eliminados estudos que apresentavam resultados sobre o ensino dessas
metodologias. Contudo, os resultados em sua maioria apresentavam
evidências com base no uso do Scrum e XP nos projetos. Isso pode ser
justificado pelo motivo destas metodologias serem as mais utilizadas com base
em pesquisas apresentadas na Seção 2.1.2.
Com base nos métodos de pesquisa utilizados, nos critérios de inclusão
e exclusão dos estudos e na qualidade metodológica dos estudos primários,
pode-se concluir que existe uma forte de evidência para suportar os resultados
encontrados nesta revisão.
4.2.2.1 (Q3) Quais são as implicações desses estudos

para a indústria de software e a comunidade de
pesquisa?
Os resultados desta revisão mostram que houve um aumento do número de
estudos publicados sobre as metodologias ágeis, em comparação com a
quantidade de estudos retornados pela revisão conduzida por Dybå e Dingsøyr
(2008).
Para a pesquisa, assim como a revisão de Dybå e Dingsøyr (2008),
esta revisão mostra que de acordo com 38 estudos ainda existe a necessidade
de que mais estudos empíricos com as metodologias ágeis sejam realizados,
sendo isso, a principal limitação destas metodologias. Os métodos empíricos
113
mais utilizados foram os estudos de caso e o survey, mostrando que existe
espaço para estudos com outros métodos empíricos, como os experimentos e
a pesquisa-ação.
Com relação à qualidade, os resultados mostram que existe uma
grande necessidade de que os estudos justifiquem o motivo da decisão pelos
métodos de pesquisa utilizados. Outro aspecto é a necessidade de que os
estudos apresentem informações claras de como os casos ou a amostra foi
selecionada, qual a sua representatividade com relação ao tamanho da
população, etc., pois, apresentando essas informações, mostra um maior rigor
da pesquisa com relação aos métodos utilizados, e aumenta a credibilidade
dos resultados obtidos.
Poucos foram os estudos que compararam os resultados por meio de
grupos de controle. E o critério de qualidade que mais se torna necessário com
os estudos que abordam as metodologias ágeis é a reflexividade crítica do
pesquisador com a própria pesquisa. Pois foram poucos estudos que
apresentaram as chances de vieses ou implicações que comprometeram os
resultados da pesquisa ou causado pelo próprio pesquisador ou pela
população participante ou, ainda, pelo tamanho da amostra selecionada.
Para os praticantes, esta revisão mostra que existem inúmeros
benefícios relatados com o uso das metodologias ágeis, providos
principalmente pelo uso do XP e do Scrum. Entre os principais benefícios
identificados estão a melhoria da comunicação e a facilidade de
compartilhamento do conhecimento, ambos providos principalmente pelas
reuniões diárias em ambientes com o Scrum, e pelo Pair Programming e
equipes colocalizadas em ambientes com o XP. A facilidade do
acompanhamento e monitoramento do projeto, bem como o feedback
rápido/frequente e a melhoria na qualidade do código também estão entre os
principais benefícios.
Limitações também foram identificadas, como a falta de estudos
empíricos que comprovem a sua eficácia, principalmente com relação ao uso
das metodologias ágeis no desenvolvimento distribuído de software. Outras
limitações, como os aspectos culturais da organização e das equipes, e a
dificuldade de tais métodos serem aplicados com pessoas individualistas ou
equipes muito especializadas, foram as principais limitações apresentadas
114
pelos estudos empíricos, que comprometem o uso das metodologias ágeis, e o
bom andamento dos projetos.

Busca manual e automática

Com base na análise dos valores, percebe-se que o esforço gasto na busca
manual efetuada no ACM Transactions on Software Engineering and
Methodology, Journal of the ACM e no IEEE Transactions on Software
Engineering não foi válido, visto a quantidade mínima de estudos
potencialmente relevantes identificados, e que todos esses também foram
retornados no processo de busca automática.
Para esta revisão foram retornados 6.856 estudos na busca manual e
automática, publicados nos anos de 2006 a 2010, correspondendo a intervalo
de cinco anos. Esse mesmo intervalo foi conduzido por Dybå e Dingsøyr (2008)
em anos anteriores, sendo retornados 1.996 estudos. O que nos leva a concluir
que o número de estudos publicados com tais metodologias aumentou nos
últimos anos.
Processo de busca e seleção

O processo de busca e seleção sempre foi realizado por pares de
pesquisadores, evitando a exclusão de estudos relevantes ou o contrário. O
resultado substancial para o índice de concordância na aplicação dos critérios
de inclusão e exclusão aumenta a confiabilidade dos resultados obtidos nessa
etapa.
 Visão geral dos estudos

Metodologias Ágeis investigados pelos estudos
Os estudos primários, em sua maioria, apresentaram resultados de pesquisas
com o Scrum (31,58%) e o XP (30,83%), seguindo uma tendência diferente da
115
revisão de Dybå e Dingsøyr (2008), onde o XP foi o método mais investigado
(76%), seguido das abordagens em aspectos gerais (15%), e em terceiro lugar
o Scrum (3%).
Os resultados da pesquisa mostram a ascensão dos estudos empíricos
com o uso do Scrum, o que pode ter relação com a sua ascensão no mercado,
como é apresentado na Seção 2.1.2.
Distribuição temporal dos estudos primários

Ao compararmos a distribuição temporal dos estudos incluídos para esta
revisão com relação ao de Dybå e Dingsøyr (2008), percebemos uma
ascensão do número de estudos que respondem a Q1 ao longo dos anos, pois
em 2005, dezessete estudos primários foram identificados pelos autores, e em
2006, vinte e dois por esta revisão.
Estes resultados têm uma estreita relação com o quantitativo de
estudos retornados no período de cada pesquisa.
Avaliação da qualidade
Os resultados mostraram que os critérios 3, 4, 5 e 8 receberam uma baixa
pontuação na avaliação da qualidade. Analisando estes resultados e
comparando com a revisão de Dybå e Dingsøyr (2008), a média de ambas as
revisões para o critério 3 apresentou resultados bem diferentes. Para esta
revisão, a média da pontuação baixa foi em virtude de que a maioria dos
estudos informava os métodos utilizados, mas não apresentava justificativa
para o seu uso, de modo que o leitor pudesse entender o motivo de uso de tal
método, e não de outro.
Para o critério 4 desta revisão, assim como em Dybå e Dingsøyr
(2008), a minoria dos estudos incluídos em ambas as revisões descrevia como
a amostra apresentada foi selecionada, se o tamanho da amostra era
representativo, etc. Tais resultados mostram que os estudos empíricos sobre
as metodologias ágeis ainda carecem no fornecimento dessas informações,
diminuindo, assim, a confiabilidade para generalizar os resultados.
Os critérios 5 e 8 desta revisão também foram os que receberam as
mais baixas pontuações em Dybå e Dingsøyr (2008), mostrando que os
116
resultados apresentados com as metodologias ágeis pelos estudos não foram
comparados a outros métodos, e que os pesquisadores dos estudos incluídos
para as revisões não apresentam reflexões críticas de possíveis sobre a
própria pesquisa.
 Benefícios e limitações identificados

Com base nos benefícios e limitações identificados por esta revisão, sendo os
principais apresentados em seções anteriores e as relações completas destes
podem ser consultadas nos APÊNDICE I e J. Esta seção apresenta uma
discussão sobre alguns destes, realizando comparações com os estudos
apresentados na Seção 2.2 e 2.3, devido à semelhança dos objetivos entre as
pesquisas.
Benefícios
O principal benefício identificado por esta revisão foi que as metodologias ágeis
“Facilita o compartilhamento do conhecimento entre a equipe”, tal beneficio
também foi identificado por Petersen e Wohlin (2009). No entanto, Dybå e
Dingsøyr (2008) não fizeram menção a este benefício.
Ao fazer uma análise do método ágil de cada um dos estudos incluídos
nesta revisão que apresentaram benefícios com o uso das Metodologias Ágeis,
o XP e o Scrum foram os métodos mais utilizados, tendo desse modo uma
grande diferença com relação à revisão de Dybå e Dingsøyr (2008), pois na
pesquisa desses autores, o XP foi a metodologia mais utilizada, sendo
apresentado poucos estudos que apresentaram resultados sobre o uso do
Scrum.
O segundo benefício foi a “Melhora na comunicação da equipe” provido
tanto por estudos apresentando o uso do Scrum quanto do XP. Dybå e
Dingsøyr (2008), Begel e Nagappan (2007) e Petersen e Wohlin (2009)
também identificaram este benefício, atribuído principalmente às reuniões
diárias do Scrum.
O terceiro benefício mais identificado nos estudos foi que o uso das
metodologias ágeis “Facilita o acompanhamento e monitoramento do projeto”,
em sua maioria, decorrente de estudos que utilizaram o Scrum, provenientes
117
das reuniões (Daily Scrum Meetings, Sprint Review e Sprint Retrospective). O
benefício também foi identificado por Dybå e Dingsøyr (2008), Petersen e
Wohlin (2009) e também citado por Begel e Nagappan (2007), mas não
discutido.
Outros benefícios identificados por esta revisão foram identificados por
Laanti et al. (2011): “Aumento na satisfação da equipe”, “Melhora a qualidade
do projeto”, “Aumento na transparência do projeto”, “Aumenta a autonomia da
equipe” e “Permite a identificação rápida de defeitos/erros”.
Devido ao fato desta revisão sistemática ser uma extensão da revisão
conduzida por Dybå e Dingsøyr (2008), um mapeamento entre os resultados
destas revisões foi realizado. Dybå e Dingsøyr (2008) apresentaram 21
benefícios que estão listados e o mapeamento destes com os benefícios
correspondentes identificados nesta revisão são apresentados na Tabela 9.
Tabela 9 – Mapeamento entre os benefícios identificados por Dybå e Dingsøyr (2008)

e esta revisão
Mapeamento
com a SLR
Beneficios identificados por Dybå e Dingsøyr (2008)
deste
trabalho
Acompanhamento do progresso do projeto B3
Aumenta a confiança entre os membros da equipe B29
Aumenta a qualidade do código B5
Aumenta a satisfação da equipe no trabalho e pelo produto B23
Aumenta a satisfação do cliente B26

Aumento na produtividade da equipe B7
Colaboração com o cliente
Combinação de práticas ágeis e tradicionais
Compartilhamento do conhecimento com a programação em par B1
Equílibrio entre um alto nível de autonomia individual com alto

B43
nível de autonomia da equipe
Feedback rápido B4
Maior envolvimento do cliente
Maior padronização do trabalho B52
Melhora o relacionamento entre a equipe B15
Melhoria na comunicação B2
Melhoria na estimativa B57
118
Métodos ágeis são fáceis de serem adotados
Mudanças são incorporadas mais facilmente B18
Redução de defeitos B13
Valor de negócio é demonstrado de forma mais eficiente B9
XP é adequado para diversos tipos de ambientes
Limitações
A principal limitação identificada por esta revisão foi a Falta de estudos
empíricos com as metodologias ágeis (L1), principalmente com relação ao uso
destas metodologias no Desenvolvimento Distribuído de Software. Tal limitação
foi a principal razão de condução da revisão realizada por Dybå e Dingsøyr
(2008), o que nos leva a interpretar que este problema continuou a existir
mesmo depois da revisão desses autores.
Dybå e Dingsøyr (2008) identificaram que o XP é difícil de ser
introduzido em organizações complexas, afirmando de que é mais adequado
para equipes pequenas. Esta limitação também foi identificada por esta
revisão, sendo relatada por quatro estudos. Entre estes estudos, dois foram
utilizando uma abordagem híbrida de Scrum e XP, um individualmente com o
uso do XP e o outro com uma abordagem misturada de diversas metodologias
ágeis.
Outras limitações identificadas por esta revisão também foram
identificadas por Dybå e Dingsøyr (2008), como a Dificuldade de Programação
em Par (L8), o que para esta revisão, grande parte da dificuldade está
relacionada não a diferença de habilidades como informado por Dybå e
Dingsøyr (2008), mas, sim, devido aos conflitos de personalidade entre os
pares, estando intimamente relacionada a limitação identificada pela revisão,
que são os Aspectos Culturais (L3), sejam eles organizacionais ou pessoais.
Devido ao fato desta revisão sistemática ser uma extensão da revisão
conduzida por Dybå e Dingsøyr (2008), um mapeamento entre os resultados
destas revisões foi realizado. Dybå e Dingsøyr (2008) apresentaram 09
limitações, entre as quais 06 são correspondentes a esta revisão. A Tabela 10
apresenta as limitações correspondentes entre as pesquisas.
119
Tabela 10 – Mapeamento entre as limitações identificadas por Dybå e Dingsøyr (2008)
e esta revisão
Limitações identificadas por Dybå e Dingsøyr (2008) Mapeamento
com a SLR
deste trabalho
Dificuldade de implantar o XP em projetos complexos L39
Mais adequado para equipes menores do que projetos grandes L13
Lean não funcionou bem
Programação em par foi ineficiente
XP funciona melhor com equipes de desenvolvimento
L28
experientes
Falta de atenção a arquitetura do projeto L19
Participação constante do cliente por um longo período causa
L27
stress
Programação em Par se torna desgastante, pois exige
L8
concentração
Dificuldade de mudar os membros das equipes
4.3 Síntese dos resultados dos Estudos de Caso

Esta seção apresenta os resultados e a análise dos estudos de caso em duas
empresas de desenvolvimento de software associadas ao Porto Digital de
Pernambuco. Com base nestes resultados, é possível responder a Q2 deste
trabalho: “O que atualmente se sabe sobre os benefícios e limitações das
Metodologias Ágeis em um determinado conjunto de empresas de
desenvolvimento de software do Porto Digital de Pernambuco?”. Os resultados
desses estudos são apresentados levando-se em consideração duas partes
distintas.
 Descrição dos estudos de caso – apresenta uma descrição de
dados gerais de cada um dos estudos de caso: tamanho da
empresa, quantidade de funcionários, quantidade de projetos,
contexto do projeto, tamanho da equipe, duração do projeto,
linguagem de programação utilizada, etc.
 Mapeamento das evidências – apresenta e descreve as evidências
identificadas nos estudos de caso para responder a segunda
questão de pesquisa (Q2) do trabalho;
120
4.3.1 Descrição dos estudos de caso
Esta seção apresenta as descrições e características dos estudos de caso
conduzidos em duas empresas de desenvolvimento de software do Porto
Digital de Pernambuco. Essas empresas foram selecionadas com base em
critérios definidos na Seção 3.2.1.3.
Ao total foram realizadas 22 entrevistas conduzidas durante o mês de
junho de 2012, totalizando 19 horas de áudio gravado; as entrevistas foram
transcritas, analisadas, categorizadas e sintetizadas de acordo com o objetivo
da pesquisa. Os entrevistados ocupavam os cargos de gerentes de projetos,
líderes técnicos, analistas, engenheiros de sistemas e de testes.
Por questões de confidencialidade, os nomes verdadeiros das
empresas, dos projetos e dos entrevistados serão omitidos, sendo utilizados
codinomes de empresa ALFA (menor tempo de uso de uma metodologia ágil) e
BETA (maior tempo de uso de uma metodologia ágil). A Tabela 11 apresenta
algumas características das empresas dos projetos investigados.
Tabela 11 – Características das empresas

Empresa Tamanho Quantidade média Qtd de Projetos Quantidade
da Empresa de pessoas por que utilizam de projetos
projeto Metodologias
Ágeis
ALFA ~ 60 ~ 06 pessoas Mais de 05 projetos Mais de 05
funcionários projetos
BETA ~ 700 ~ 08 pessoas Mais de 05 projetos Mais de 05
funcionários projetos
4.3.1.1 Estudo de Caso ALFA

A empresa ALFA está localizada na cidade do Recife-PE, atuando no mercado
há quase sete anos. Possui um programa de qualidade e trabalha como uma
fábrica de software especializada no desenvolvimento de sistemas para
clientes externos, principalmente com órgãos públicos.
Possui cerca de 60 funcionários, dos quais aproximadamente trinta
121
pertencem à área de desenvolvimento e manutenção de sistemas, distribuídos
entre os 18 projetos em que a empresa atua. Os membros da fábrica de
software estão divididos entre: gerentes de projetos, gerente de TI, um analista
da qualidade, analistas de sistemas, engenheiros de sistemas, engenheiros de
testes e um designer gráfico.
O Scrum foi implantado na empresa ALFA através de uma empresa de
consultoria, sendo realizados treinamentos e acompanhamento da execução
do Scrum nos projetos. Todos os projetos da empresa são gerenciados
utilizando o Scrum apenas em nível de fábrica, pois para os clientes isto não é
transparente. Desse modo, os analistas de requisitos que estavam em contato
com os clientes eram os responsáveis pelo papel de Product Owner dentro da
fábrica. As Sprints de todos os projetos possuíam duração de duas semanas.
As equipes dos projetos estão alocadas em um mesmo ambiente físico,
de modo que os membros das equipes fiquem todos juntos. Cada equipe
possui o seu quadro de tarefas, onde são colocadas as histórias e tarefas.
Além do quadro, as equipes utilizam uma ferramenta web de gerenciamento de
projetos, o Redmine4, que é observado pelo diretor da empresa e pelos clientes
para saberem o andamento dos projetos.
Ao projeto investigado no estudo de caso foi atribuído o nome
ALFA_P1. Este projeto estava sendo desenvolvido há pouco mais de um ano
utilizando a linguagem Java para plataforma Web, os frameworks JSF,
Demoiselle e os bancos de dados Oracle e SQL Server. Foi considerado de
complexidade média pelos envolvidos. O objetivo do projeto era desenvolver
um sistema de controle financeiro para acompanhar e monitorar despesas e
receitas governamentais.
O projeto ALFA_P1 possuía nove membros; destes, 07 foram
entrevistados. Algumas características dos membros entrevistados estão
descritas na Tabela 12.
4
www.redmine.org
122
Tabela 12 – Características dos entrevistados do projeto ALFA_P1
Experiência c/ Experiência c/
Entrevistado Função Idade desenvolviment Metodologias
o de software Ágeis
ALFA_P1_E1 Analista/Scrum Master 28 04 anos 1,5 anos
ALFA_P1_E2 Gerente de Projeto 27 06 anos 2,5 anos
ALFA_P1_E3 Analista/Product
26 05 anos 03 anos
Owner
ALFA_P1_E4 Engenheiro de Testes 22 03 anos 1,5 anos
ALFA_P1_E5 Engenheiro de
32 05 anos 04 anos
Sistemas
ALFA_P1_E6 Gerente de TI 26 06 anos 03 anos
ALFA_P1_E7 Engenheiro de 01 ano e 04
27 02 anos
Sistemas meses
4.3.1.2 Estudo de Caso BETA

A empresa BETA tem sua matriz localizada na cidade Recife-PE e tem
escritórios em outros estados brasileiros, atuando no mercado há mais de 15
anos. Possui um programa de qualidade e oferece serviços de criação de
produtos, pesquisa e desenvolvimento de sistemas com tecnologias voltados
para hardware, web, softwares embarcados, mobile, entre diversos outros
nichos tecnológicos.
A empresa possui cerca de 700 funcionários que trabalham em áreas
que vão desde as administrativas até as voltadas para tecnologia da
informação. Dois projetos foram investigados na empresa BETA, aos quais
foram atribuídos os nomes BETA_P1 e BETA_P2.
O projeto BETA_P1 estava sendo desenvolvido há 06 meses,
utilizando linguagem C e Java, para o desenvolvimento de protocolos e
sistemas de gerenciamento de redes, sem interface gráfica. O projeto foi
considerado de complexidade média pelos membros.
O cliente do projeto atuava na área de Tecnologia da Informação (TI) e
partiu dele a solicitação para o uso do Scrum no projeto. A implantação do
Scrum no projeto iniciou com um treinamento promovido pelo gerente do
123
projeto, pois a maioria dos membros da equipe não possuía experiência no
framework.
O projeto utilizou Sprints com durações de três semanas. O cliente
participava ativamente do projeto, desde o planejamento das Sprints, durante
sua execução, até o seu encerramento. A comunicação ocorria, em sua
maioria, por meio de ferramentas de comunicação instantânea.
Na semana de realização das entrevistas com os membros desse
projeto, a equipe estava iniciando a experiência de não utilizar o quadro de
tarefas da Sprint, apenas utilizar a ferramenta Redmine.
O projeto possuía treze membros, dos quais 07 foram entrevistados.
Uma breve descrição dos entrevistados encontra-se na Tabela 13.
Tabela 13 – Características dos entrevistados do estudo de caso BETA_P1

Experiência c/
Experiência c/
desenvolvime
Entrevistado Função Idade Metodologias
nto de
Ágeis
software
BETA_P1_E1 Engenheiro de Sistemas 25 02 anos 08 meses
BETA_P1_E2 Engenheiro de Sistemas 27 08 meses 08 meses
BETA_P1_E3 Líder de Equipe/Scrum
34 13 anos 03 anos
Master
BETA_P1_E5 Engenheiro de Sistemas 30 08 meses 08 meses
O projeto BETA_P2 iniciou a pouco mais de 03 anos, utilizando a

linguagem Java Web e Flex para o desenvolvimento de aplicações de SaaS
(Software as a Service) para uma empresa de telecomunicação. O projeto foi
considerado de complexidade alta por todos os membros do projeto.
O Scrum foi utilizado no projeto desde o seu início, e na época não foi
necessário um treinamento, visto que a maioria dos membros possuía
experiência prévia com o método. As Sprints do projeto possuíam duração de
04 semanas e eram gerenciadas com o auxílio do quadro de tarefas da equipe
124
e uma planilha.
O cliente do projeto atua na área de Tecnologia da Informação (TI) e
participava ativamente do projeto, estando sempre disponível, por email ou por
uma ferramenta de comunicação instantânea. O papel do Product Owner (PO)
estava dividido entre o PO interno, representado por uma engenheira de testes
do projeto e o externo sendo o próprio cliente.
O projeto possuía nove membros, dos quais 08 foram entrevistados.
Uma breve descrição dos entrevistados encontra-se na Tabela 14.
Tabela 14 – Características dos entrevistados do estudo de caso BETA_P2

Experiência c/
Experiência c/
desenvolvime
Entrevistado Função Idade Metodologias
nto de
Ágeis
software
BETA_P2_E1 Engenheiro de Sistemas 27 04 anos 04 anos
BETA_P2_E2 Líder Técnico /
30 09 anos 04 anos
Engenheiro de Sistemas
BETA_P2_E3 Engenheira de Testes /
28 07 anos 02 anos
Product Owner
BETA_P2_E6 Engenheiro de Sistemas 38 18 anos 01 ano
BETA_P2_E7 Engenheiro de Testes 29 07 anos 03 anos
BETA_P2_E8 Gerente de
28 08 anos 06 anos
Projetos/Scrum Master
4.3.2 Mapeamento das Evidências

Esta seção apresenta os resultados da condução das 22 entrevistas nos
estudos de caso selecionados que permitem responder à Q2 desta pesquisa:
“O que atualmente se sabe sobre os benefícios e limitações das Metodologias
Ágeis em um determinado conjunto de empresas de desenvolvimento de
software do Porto Digital de Pernambuco?”.
Os resultados apresentados nesta seção foram obtidos com base nos
aplicação dos métodos da Teoria Fundamentada em Dados (Grounded Theory)
125
e da Meta-etnografia sobre a leitura e análise das transcrições das entrevistas.
Na Seção 0 são descritos os principais benefícios e na Seção 0 são
apresentadas as principais limitações das Metodologias Ágeis identificadas nos
estudos de caso.
4.3.2.1 Benefícios
Foram identificados 52 benefícios nos estudos de caso; a lista completa e o
mapeamento destes com cada caso encontram-se no APÊNDICE K. Nos
próximos tópicos desta seção, são discutidos os 10 benefícios que mais foram
identificados nos estudos de caso (Tabela 15). Os benefícios receberam um
identificador único, para se diferenciarem uns dos outros.
Tabela 15 – Dez principais benefícios identificados nos estudos de caso

% Total de
ID Descrição do Benefício
entrevistados
B1_EC Facilita o acompanhamento e monitoramento do projeto 95,45%
B2_EC Facilita o compartilhamento do conhecimento entre a equipe 68,18%
B3_EC Melhora o entendimento das histórias de usuários 63,64%
B4_EC Facilita a interação entre a equipe 63,64%
B5_EC Facilita a resolução de problemas 59,09%

B6_EC Melhora a comunicação da equipe 45,45%
B7_EC Permite uma maior colaboração entre a equipe 45,45%
Melhora a comunicação entre o cliente (ou representante) e
B8_EC 40,91%
a equipe
B9_EC Melhora a qualidade do código 40,91%
B10_EC Feedback rápido/frequente 40,91%
B1_EC. Facilita o acompanhamento e monitoramento do

projeto
O principal benefício identificado nas entrevistas apontou que o uso do Scrum
facilitou o acompanhamento e o monitoramento do projeto, devido a algumas
de suas práticas e artefatos utilizados (Figura 34). Entre as práticas, as
reuniões diárias (Daily Scrum Meetings) foram as que mais proveram tal
benefício. Entre os artefatos, foi o uso do quadro de tarefas (Task Board).
126
Figura 34 – B1_EC. Facilita o acompanhamento e monitoramento do projeto

identificadas para o benefício em questão e o mapeamento destas com
algumas entrevistas.
Daily Scrum Meetings

As reuniões diárias (Daily Scrum Meetings) foram mencionadas por treze
entrevistados, em sua maioria, engenheiros de sistema dos projetos P1 e P2
da empresa BETA. Também foram citadas por analistas, gerentes, um líder
técnico e um Scrum Master.
De acordo com um engenheiro de sistemas [BETA_P1_E6], essas
reuniões permitem compartilhar informações com todos do projeto,
possibilitando ter uma noção sobre o seu andamento. Outro engenheiro
[BETA_P1_E1] afirmou que as reuniões diárias e as Sprints Reviews são uns
dos grandes benefícios do Scrum, pois através destas é possível obter
informações válidas sobre o andamento do projeto, permitindo que as pessoas
fiquem contextualizadas sobre as atividades e dificuldades de cada membro no
projeto. Essas mesmas opiniões foram identificadas nas entrevistas de
([BETA_P1_E2], [BETA_P1_E4], [BETA_P1_E7], [ALFA_P1_E1] e
[ALFA_P1_E3]).
Outro engenheiro [BETA_P2_E4] afirmou que as reuniões diárias e as
Sprints permitem acompanhar o que cada membro está fazendo ou ainda irá
fazer, evitando assim a escolha de atividades que outra pessoa estava
pensando em desenvolver. Essas afirmações também são compartilhadas pelo
engenheiro [BETA_P2_E6].
127
Task Board
O quadro de tarefas utilizado nos projetos (Task Board) foi mencionado por
dezessete entrevistados (engenheiro de sistemas, de testes, analista de
sistemas/Product Owner, líder de equipe/Scrum Master), sendo este o artefato
mais foi citado por prover o benefício de permitir acompanhar e monitorar os
projetos.
Na empresa ALFA, apenas duas pessoas afirmaram a utilidade do
quadro para este benefício. Uma delas foi o engenheiro de sistemas e também
Scrum Master [ALFA_P1_E5] do projeto; em sua opinião, a partir do quadro ele
consegue perceber se a equipe está indo bem ou mal na Sprint, o que permite
sinalizar ao gerente de projetos se está ocorrendo algum problema ou se está
tudo tranquilo. A mesma visão é compartilhada por um engenheiro de sistemas
do mesmo projeto, que alega que o fato de o quadro estar localizado na
mesma sala da equipe torna-o de fácil visualização.
O projeto P1 da empresa BETA realizou a experiência de retirar o
quadro de tarefas de sua equipe, devido à falta de espaço no ambiente de
trabalho para o qual haviam mudado recentemente. Substituíram-no por uma
ferramenta web, o Redmine. No entanto, de acordo com o engenheiro de
sistemas [BETA_P1_E1], o quadro dava uma visão geral do status do sistema,
enquanto para outro engenheiro de sistema do mesmo projeto [BETA_P1_E2],
o quadro permitia a visualização rápida do que cada membro da equipe estava
fazendo. Essas mesmas opiniões foram compartilhadas por ([BETA_P1_E5],
[BETA_P1_E6], [BETA_P1_E7], [BETA_P2_E4] e [BETA_P2_E6]).
Para o engenheiro de sistemas [BETA_P2_E1] o uso do quadro é
fundamental para determinados tipos de atividades, principalmente aquelas
que possuem atividades dependentes. O engenheiro afirmou que houve uma
situação em que estava desenvolvendo uma atividade de Script (shell) que
dependia de outra atividade. A partir do quadro, ele conseguiu facilmente
visualizar quem era o responsável pela atividade, ou seja, o uso do quadro
permitiu um retorno rápido e prático de informação.
O engenheiro de sistemas [BETA_P2_E5] alegou que o quadro é
importantíssimo para orientar tanto a equipe quanto o gerente do projeto em
relação ao status do projeto.
128
Transcrições das entrevistas
A seguir, seguem algumas transcrições extraídas durante a análise das
entrevistas que justificam o benefício em questão.
"... eu acho interessante, muito bom pra a gente ter uma noção
de como ta o andamento, se alguém ta com algum
problema, com algum impedimento, a gente compartilha.” –
Engenheiro de Sistemas, BETA_P1_E6
“... eu achei que foi um benefício grande e gostei da

metodologia do Scrum e gostei de... do... a parte das reuniões
diárias, do Review, achei muito importante. Você consegue
muitas informações válidas através de ambos.” – Engenheiro
de Sistemas, BETA_P1_E1
“É bom porque você diz a todo mundo o que é que ta fazendo

e você vai saber o que todo mundo ta fazendo... o que ta
fazendo, o que vai fazer e o que fez, né? Porque daí, por
exemplo, se você ta pensando em pegar alguma atividade,
mas uma pessoa da equipe ta querendo pegar a mesma
atividade que você. Você tem que ver que a atividade que vai
pegar pra ele vai ser mais importante do que pra mim, pra
agregar valor ao que já ta fazendo. Aí essa reunião é muito
importante.” – Engenheiro de Sistemas, BETA_P2_E4
“O que eu consigo ver quando eu olho para o quadro? Eu

consigo saber se a gente está indo bem ou mal na Sprint, e
se por acaso, estivermos indo mal, eu já consigo levantar uma
bandeira para o gerente, para dizer que, como as nossas
entregas para o cliente são menores também, então a gente
tem esse problema. Se uma Sprint atrasar, uma entrega para o
cliente pode atrasar. Então eu já consigo levantar algum tipo
de bandeira para dizer “olha, vai ter problema” ou “está
tranquilo”, tenho essa visão...” – Engenheiro de Sistemas /
Scrum Master, ALFA_P1_E5
129
“O quadro dava uma visão... ele dava uma visão geral do
status do seu... do... do... do sistema que ta sendo feito.” –
B2_EC. Facilita o compartilhamento do conhecimento entre a

equipe
A facilidade de compartilhamento de conhecimento provido pelo ambiente de
trabalho com o Scrum e outras práticas ágeis foi um dos benefícios mais
relatado nas entrevistas. A programação em par (Pair Programming) foi a
prática que mais proveu tal benefício, seguido da cerimônia de Sprint Planning
do Scrum. A Figura 35 apresenta todas as práticas identificadas que
Figura 35 – B2_EC. Facilita o compartilhamento do conhecimento entre a equipe


Pair Programming
A prática da programação em par foi relatada em diversas entrevistas,
principalmente entrevistas com engenheiros de sistemas.
Na empresa ALFA, o benefício foi relatado em três entrevistas. Um
engenheiro de sistemas que também exerce o papel de Scrum Master
[ALFA_P1_E5], ao ser perguntado sobre como funciona a programação em par
na equipe em que trabalha, respondeu que esta ocorre em algumas situações:
130
em atividades complexas ou quando há a necessidade de dependência de
outro desenvolvedor; quando se precisa terminar uma atividade o mais rápido
possível ou quando se precisa juntar dois desenvolvedores para que discutam
e assim juntem os conhecimentos a fim de escolherem a melhor solução para
um determinado problema.
Ainda na empresa ALFA, um analista/Scrum Master [ALFA_P1_E1]
afirmou que todos os dias membros da equipe sentam juntos para disseminar o
conhecimento sobre o que estão desenvolvendo. Sobre este acontecimento,
um Product Owner [ALFA_P1_E3] afirmou que sua equipe utiliza esta prática e
ao ser questionado quanto a sua visão sobre a prática, afirmou que acha
importante, tanto para nivelar o conhecimento da equipe quanto para a
resolução de problemas mais críticos.
Na empresa BETA, o benefício foi relatado em seis entrevistas, sendo
cinco relatos de engenheiros de sistemas e um do líder da equipe que também
atua como Scrum Master. Este último [BETA_P1_E3] afirmou que a prática
permite o compartilhamento do conhecimento e que normalmente ocorre entre
pessoas com níveis diferentes de experiência, o que permite uma revisão do
código, provendo uma melhor qualidade a este.
O engenheiro de software [BETA_P2_E1] afirmou que esta prática é
utilizada em atividades complexas ou quando se tem a necessidade de passar
o conhecimento para outra pessoa. Outro engenheiro [BETA_P1_E5] do
mesmo projeto afirma gostar da prática, pois aprende a implementar o código
de maneiras diferentes, além de ajudar a corrigir os erros que normalmente
uma única pessoa não perceberia.
Sprint Planning
A cerimônia de Sprint Planning do Scrum, realizada no início de toda Sprint, foi
relatada em dois projetos. No projeto P1 da empresa ALFA e no projeto P2 da
empresa BETA.
Na empresa ALFA o benefício foi relatado por três pessoas. Um
analista, que também atua como Scrum Master, [ALFA_P1_E1], afirmou que a
discussão da segunda etapa da Sprint Planning entre todos os membros da
equipe permite que cada um compartilhe a sua visão sobre uma determinada
história, unindo, assim, o conhecimento de todos para entender e subdividir a
131
história em tarefas. Para o Product Owner da equipe [ALFA_P1_E3], a
discussão desta reunião permite expor pontos de vista diferentes, dúvidas
diferentes e maneiras diferentes para uma determinada solução. Essa
discussão, de acordo com um engenheiro de sistemas [ALFA_P1_E5], nivela o
conhecimento na estimativa da história.
Na empresa BETA, o benefício proveniente das cerimônias de Sprint
Planning foi observado por quatro pessoas do projeto. O engenheiro de
sistemas [BETA_P2_E1] afirmou que no projeto P2, durante as reuniões, na
etapa que ocorre apenas com os membros da equipe, os que mais entendem
sobre o assunto da história explicam com detalhes o que deve ser feito e como
deve ser feita a história. Esta situação é compartilhada pelo engenheiro
[BETA_P2_E6], que afirmou que esta mistura de diferentes níveis de
experiência no planejamento acelera o conhecimento dos menos inexperientes,
pois há a troca do conhecimento, principalmente sobre sistemas mais antigos.
As cerimônias de Sprint Planning, de acordo com a Engenheira de
Testes [BETA_P2_E3], que também atua como Product Owner interno do
projeto (pois também existe um Product Owner do próprio cliente) afirmou que,
é bom que todos participem desta reunião, pois isto permite nivelar o
conhecimento de todos sobre as histórias, já que as dúvidas são tiradas na
hora com o cliente.

As reuniões diárias do Scrum foram identificadas em três entrevistas como
prática importante para disseminar o conhecimento entre a equipe. Os
entrevistados pertenciam a dois projetos, o P1 da empresa ALFA e o P2 da
empresa BETA.
No projeto P1 da empresa ALFA, o benefício foi identificado por um
engenheiro de testes [ALFA_P1_E4] que afirmou que essas reuniões permitem
promover a conversa entre a equipe, tirar as dúvidas e entender novas técnicas
para solucionar um problema.
No projeto P2 da empresa BETA, de acordo com o engenheiro de
sistemas [BETA_P2_E6], essas reuniões são válidas, visto que não é uma
reunião gerencial e sim da equipe, sem pressão, onde trocam informações e
distribuem o conhecimento sobre suas atividades.
132
“Quando a gente tem uma história que ela é muito complexa,

é... Ela é em par mesmo. Você chegava lá e duas pessoas iam
desenvolver aquela história por N motivos. Ou porque uma
dependia da outra e você botava dois para trabalhar numa
história [Pair Programming] para terminar mais rápido para
liberar outras.
Ou pela qualidade mesmo, ninguém da equipe tem aquele
nível de conhecimento, por exemplo, aí vamos os dois cair
em cima da história aqui, estudar, coisa e tal, que eu posso ter
uma visão, tu pode ter outra visão, ou o conjunto das duas,
ou um viu alguma coisa que o outro não viu e á descarta
uma coisa que poderia ser um caminho errado para seguir.” –
Engenheiro de Sistemas/Scrum Master, ALFA_P1_E5
“[...] E é muito bom, porque o contato que você tem com outra
pessoa desenvolvendo, você vê ela fazendo coisas que:
[“_Poxa, isso é interessante. Eu nunca tinha atentado pra
isso!”], até pra ajudar na utilização da ferramenta em si, da
ferramenta, da IDE. Você vai fazer uma coisa: [“_Poxa, eu não
sabia, não conhecia esse atalho?]. Ou então, você vê a
pessoa utilizando o código de uma forma que você
utilizaria de outra: [“_Poxa, se for interessante ou não”].
Então, é muito bom. E você vai conversando e vai ajudando,
mesmo, né, corrigindo, se a pessoa errar alguma coisa.” –
“Quando o PO apresenta a história eles [membros da equipe]

têm uma visão meio macro ali, cada um tem sua visão
daquela história e quando paramos para se reunir para estimar
e delegar as tarefas, unimos cada conhecimento, cada visão
que cada um está tendo daquela história e consegue
133
colocar, subdividir em tarefas e fazer com que o outro
enxergue...” – Analista/Scrum Master, ALFA_P1_E1
“[Questionado sobre o que ele acha de no Planning envolver

todos do projeto, com diferentes níveis de experiência]
Eu acho porque a gente mistura um pouco conhecimento e
quer queira quer não acelera um pouco o aprendizado do
júnior. Porque você termina passando um pouco o
conhecimento, principalmente nessas trocas de informação
sobre sistemas, comportamento, vamo achar isso, vamo
corrigir isso, enfim, isso acelera essa distribuição do
conhecimento pro desenvolvimento mais rápido pro júnior.
Se deixasse ele só sem essas reuniões, esses encontros, acho
que a curva seria maior de aprendizado. Acho que acelera um
pouco.” – Engenheiro de Sistemas, BETA_P2_E6
“[Questionado se as reuniões ajudam a entender melhor o

problema]
Ajuda porque a gente consegue conversar, tirar dúvidas
com o Scrum Master, que muitas vezes nos explica alguma
técnica mais fácil para você utilizar.” – Engenheiro de Testes,
ALFA_P1_E4
“E é uma coisa sem pressão [Reunião diária]. Não é uma

reunião gerencial estratégica, é uma reunião da própria equipe,
entre parceiros, enfim, que ficam trocando informação pra
distribuir conhecimento e dar essa noção de
acompanhamento e distribuição das próximas tarefas. Eu acho
isso super válido.” – Engenheiro de Sistemas, BETA_P2_E6
B3_EC. Facilita a interação entre a equipe

Devido à ênfase dada pelo Manifesto Ágil para as interações entre os
indivíduos e a comunicação entre eles, foi possível identificar nas entrevistas
que uso de algumas práticas ágeis facilita a interação entre as equipes. Entre
as principais está a prática de colocar as equipes colocalizadas e realizar as
reuniões diárias do Scrum (Daily Scrum Meetings). Outras práticas foram
134
identificadas em menor grau. A Figura 36 apresenta todas as práticas
identificadas que permitiram o benefício.
Figura 36 – B3_EC. Facilita a interação entre a equipe


Co-location team
A adoção da prática de colocar os membros da equipe juntos em um mesmo
local foi percebida como um benefício nos três projetos estudados. No projeto
da empresa ALFA três relatos foram identificados e na empresa BETA um
relato para cada projeto.
Na empresa ALFA foi perguntado ao gerente de projetos
[ALFA_P1_E2] quanto a sua visão sobre a comunicação e a interação entre os
membros da equipe; este afirmou que ambas funcionam bem, pelo motivo de
todos estarem juntos e próximos uns os outros. Essa mesma visão foi
apresentada pelo engenheiro de testes da empresa [ALFA_P1_E4].
Um engenheiro de sistemas do projeto P1 da empresa BETA
[BETA_P1_E1] afirmou que devido ao fato de estarem em um ambiente onde
todos da equipe estão muito próximos, a interação e a comunicação entre eles
acaba fluindo bem. Um engenheiro de teste também da empresa BETA, sendo
que do projeto P2 [BETA_P2_E7], afirmou que a interação entre a equipe de
teste e de desenvolvimento é boa devido à proximidade das equipes, alocadas
em uma mesma sala. O engenheiro ainda afirmou que esta proximidade ajuda
a resolver as dúvidas sobre os testes, pois a comunicação está mais próxima.
135
As reuniões diárias das equipes Scrum também foram percebidas em todos os
projetos estudados como uma prática que permite melhorar a interação entre
os membros da equipe.
Na empresa ALFA, um analista que também atua como Product Owner
do projeto [ALFA_P1_E3] afirmou que a prática da reunião diária tem um
impacto cultural positivo sobre os membros da equipe, de modo que uma
pessoa que não gosta de se comunicar acaba se comunicando mais com os
demais membros devido à reunião.
Na empresa BETA, um engenheiro de sistemas do projeto P1
[BETA_P1_E1] afirmou que as reuniões diárias aproximam os membros da
equipe, permitindo uma interação maior entre eles. Essa mesma visão foi
afirmada pelo líder técnico [BETA_P2_E2] do projeto P2.

“Entre si eles participam bastante porque sentam juntos,

estão todos assim... O mesmo time sempre perto. Entre
eles acho que é boa a interação.” – Gerente de Projetos,
ALFA_P1_E2
“Flui, a gente sempre fica sentado numa parte, a parte da

empresa. Todo mundo junto, interagindo bastante, aí a
comunicação é bem tranquila.” – Engenheiro de Testes,
ALFA_P1_E4
“Como a gente ta muito próximo, mesmo, fisicamente um

do outro, éhh... De vez em quando vai até o computador um
do outro, debate alguma coisa, depois volta.” – Engenheiro
“[Questionado sobre a interação entre a equipe de

desenvolvimento e de testes]
136
É uma interação boa pela proximidade que a gente tem lá
no... ficamos bem próximos da equipe de desenvolvimento.
Uma diferença que eu notei também de outros projetos foi que
quando ta mais próximo, às vezes, assim, uma dúvida que eu
tenha sobre algum teste algum resultado esperado eu já posso
tirar do lado, não esperar ou mandar um e-mail ou pro cara do
outro lado que demora muito pra poder chegar nele.” –
Engenheiro de Testes, BETA_P2_E7
“É, cultural eu acho legal pelo fato da comunicação ser mais

constante, mesmo que uma pessoa, um desenvolvedor, ela
não fale durante o dia, digamos assim, ela pelo menos na
reunião diária ela vai ter que falar... Acho que isso motiva e
ajuda a pessoa a se soltar um pouco mais, interagir um
pouco mais. Tem mais interação com a equipe.” – Analista /
Product Owner, ALFA_P1_E3
B4_EC. Melhora o entendimento das histórias de usuários

Entender as necessidades do projeto de maneira simples é o que propõe as
histórias de usuário, no entanto, às vezes, estas ainda ficam obscuras para a
equipe de desenvolvimento. Para reduzir esta obscuridade e facilitar o
entendimento das histórias, diversas práticas ágeis estão sendo utilizadas e as
que foram relatadas nas entrevistas que mais proveram tal benefício foram as
cerimônias de planejamento da Sprint (Sprint Planning) e a prática de ter o
cliente ou o seu representante sempre presente no projeto. Outras práticas
foram identificadas em menor grau. A Figura 37 apresenta todas as práticas
identificadas que permitiram ao benefício.
Figura 37 – B4_EC. Melhora o entendimento das histórias de usuários

137
Sprint Planning
A cerimônia de Sprint Planning do Scrum, realizada no início de toda Sprint, foi
relatada em dois projetos. No projeto P1 da empresa ALFA e no projeto P2 da
empresa BETA.
Na empresa ALFA, a participação direta do Product Owner na Sprint
Planning, de acordo com o gerente de TI [ALFA_P1_E6], torna o entendimento
das histórias de usuário mais simples, pois nem sempre é possível entender
tudo o que está escrito na documentação. O gerente de projetos
[ALFA_P1_E2] afirmou que as reuniões são importantes para permitir que
todos os desenvolvedores entendam as histórias. Além disso, de acordo com
um Analista/Product Owner [ALFA_P1_E3], as dúvidas que vão surgindo
durante a reunião, são esclarecidas com base nas necessidades do cliente.
Na empresa BETA, um engenheiro de sistemas [BETA_P2_E4]
afirmou que essas reuniões são boas porque facilitam o entendimento e
permitem que o PO faça os devidos ajustes nas histórias. Outro engenheiro do
mesmo projeto [BETA_P2_E5] afirmou que às vezes abrem o código e quem já
trabalhou com algo parecido antes explica para todos.
Customer Involvement
Ter o cliente presente no projeto de forma presencial ou através da constante
comunicação, seja com o próprio ou com seu representante, facilitou o
entendimento das histórias de usuário nos três projetos.
Na empresa ALFA, um engenheiro de sistemas [ALFA_P1_E7] afirmou
que o Product Owner estava sempre presente nas reuniões de Sprint Planning
e Review. Estava ainda alocado bem próximo da equipe, o que facilitava para
tirar as dúvidas.
[BETA_P1_E7] afirmou que o cliente participa ativamente do projeto, validando
até mesmo o código que foi desenvolvido pela equipe. Assim, a constante
presença do cliente no projeto facilitou a resolução das dúvidas. No projeto P2,
138
um engenheiro de sistemas [BETA_P2_E1] disse que o cliente estava sempre
próximo da equipe, inspecionando e validando sempre o que estava sendo
desenvolvido, fazendo com que a equipe não fugisse do escopo do projeto.

entrevistas que justificam tal benefício.
“[Sobre a Sprint Planning] O importante é que todos os

desenvolvedores, todas as pessoas da equipe ficam a par
dos requisitos” – Gerente de Projetos, ALFA_P1_E2
“Então, o PO ta lá pra ta ajustando aquilo, né? A gente vai

estimar alguma Sprint, alguma história, e chega e: [“_Oh, dá
tantos pontos e a gente teja imaginando X, mas o que o cliente
quer é X+Y...”]. Então, o PO ta lá pra sempre ajustar do jeito
que o cliente quer.” – Engenheiro de Sistemas, BETA_P2_E4
“Na, na hora, nas reuniões de Scrum ele [Product Owner]

sempre estava, né? No Planning e na Review.
É... A gente falava assim também que a gente tinha um certo
privilégio que era ter os POs dentro da Empresa, né? E aí,
qualquer dúvida, a gente... A gente trabalhava aqui em
cima e eles lá embaixo, a gente subia, perguntava e
voltava... Ao meu ver, isso era bom...” – Engenheiro de
Sistemas, ALFA_P1_E7
“Está, ele [Cliente] tá constantemente perto da gente. Sempre

que a gente tem alguma dúvida, ele ta lá disponível pra
tirar as dúvidas da gente.” – Engenheiro de Sistemas,
BETA_P1_E7
B5_EC. Facilita a resolução de problemas

Durante a investigação dos projetos, foi percebido que algumas práticas
utilizadas nestes facilitaram a resolução dos diversos tipos de problemas que
139
surgiram. Entre as principais práticas está, primeiramente, a programação em
par (Pair Programming), seguida das reuniões diárias (Daily Scrum Meetings) e
do papel de atuação do Scrum Master. Outras práticas foram identificadas em
menor grau. A Figura 38 apresenta todas as práticas identificadas que
Figura 38 – B5_EC. Facilita a resolução de problemas


Pair Programming
A prática da programação em par foi vista como benéfica para resolver alguns
problemas dos projetos, de acordo com cinco entrevistados, englobando todas
as empresas estudadas.
De acordo com o gerente de projetos [ALFA_P1_E2] da empresa
ALFA, a prática da programação em par é bem vista no projeto quando se tem
alguma atividade mais complexa em uma história, facilitando assim seu o
desenvolvimento. O analista/Product Owner do projeto [ALFA_P1_E3] acha
importante a prática; no entanto, ela só é utilizada para atividades realmente
complexas, pois como a empresa se trata de uma fábrica de software, a prática
acaba deslocando um recurso que poderia estar trabalhando em outra
funcionalidade.
afirmou que a prática é boa para as atividades que exigem mais atenção. Para
140
outro engenheiro de sistemas desse mesmo projeto [BETA_P1_E2], a prática
ajuda a resolver problemas, porque só o fato de ter uma pessoa ao lado
discutindo, analisando e criticando facilita a resolução do problema e melhora a
qualidade do código. Essa mesma opinião é compartilhada pelo engenheiro de
sistemas [BETA_P2_E4] do projeto P2.

“[Questionado sobre como funciona a programação em par na

equipe]
Flui bem e, às vezes, se tem alguma coisa mais complicada
eles fazem alguma história em par para sair mais fácil.
Entre eles é mais fácil.” – Gerente de Projetos, ALFA_P1_E2
“[...] se for algo mais de criação, mesmo, que exige um

raciocínio maior, eu acho que o Pair Programming seria...
seria bom porque duas pessoas pensam melhor do que
uma.” – Engenheiro de Sistemas, BETA_P1_E1
“Eu acho uma coisa legal, porque aí você divide

conhecimento, né? E tanto que quando gera algum problema,
às vezes só do fato da pessoa ta do seu lado e dizer: [“_Oh, o
problema é esse, esse e esse”], você já tem uma sacada pra
tentar resolver.
...então, ajuda muito. Quando você não ta... [“_Pô, tem
determinado erro ali que eu não to conseguindo resolver”], mas
ao seu lado tem outra opinião pra chegar e dizer: [“_Oh, por
que tu não faz desse jeito? _É, vamo testar”], porque duas
cabeça pensa melhor do que uma, né?” – Engenheiro de
Sistemas, BETA_P2_E4
141
B6_EC. Melhora a comunicação da equipe
As Metodologias Ágeis enfatizam a importância da comunicação entre todos os
envolvidos nos projetos, por isso o Scrum possui diversas práticas e cerimônias
que permitem que a comunicação flua nos projetos. Durante a investigação dos
estudos de caso, a melhoria da comunicação devido ao uso do Scrum e de
outras práticas foi identificada em todos os projetos investigados. As práticas
que mais permitiram esse benefício foram, em primeiro lugar, as reuniões
diárias (Daily Scrum Meetings), e em segundo a prática de dispor as equipes
colocalizadas. A Figura 39 apresenta todas as práticas identificadas que
Figura 39 – B6_EC. Melhora a comunicação da equipe



As reuniões diárias do Scrum foram declaradas em seis entrevistas como
prática importante para melhorar a comunicação da equipe. Os entrevistados
pertenciam aos três projetos investigados.
No projeto P1 da empresa ALFA, o benefício foi identificado por um
engenheiro de testes [ALFA_P1_E4] que afirmou que essas reuniões permitem
que a equipe se comunique mais, sendo muito bem vista por um analista do
projeto/Product Owner [ALFA_P1_E3]. Um engenheiro de sistemas
[ALFA_P1_E7] alegou que, antes do uso do Scrum, às vezes sentiam a
necessidade de se comunicarem mais, e que após a implantação do Scrum, as
reuniões diárias permitiram que a cultura da equipe passasse a ser mais
142
voltada para a comunicação e a cooperação.
Nos projetos da empresa BETA, o benefício devido à prática das
reuniões diárias foi identificado por uma pessoa de cada projeto investigado.
Um engenheiro de sistemas do projeto P1 [BETA_P1_E4] afirmou que as
reuniões diárias tornam as pessoas mais comunicativas.
Co-location team
A adoção da prática de colocar os membros da equipe juntos em um mesmo
local foi percebida como um benefício em dois projetos estudados, sendo
relatada por quatro membros, dois da empresa ALFA e dois do projeto P2 da
empresa BETA.
Um analista/Product Owner do projeto da empresa ALFA
[ALFA_P1_E3] afirmou que a comunicação do time é muito direta, pois todos
os membros estão em um mesmo ambiente, o que facilita o esclarecimento de
dúvidas entre eles. Um engenheiro de sistemas do projeto P2 da empresa
BETA [BETA_P2_E4] também afirmou que a comunicação da equipe é boa,
pois estão todos sentados próximos uns aos outros. O mesmo benefício foi
identificado pelo líder técnico do projeto P2 [BETA_P2_E2].

“É importante [reunião diária] porque a gente se comunica

mais, e porque a gente discute erros que foram
encontrados, que possivelmente podem acontecer em outras
histórias, problemas que a gente está tendo em relação às
histórias ou baixa no trabalho.” – Engenheiro de Testes,
ALFA_P1_E4
“E a nível de fábrica, eu acho que é a questão da

comunicação, eu acho que é super importante a equipe estar
envolvida ali, todo mundo tentando um ajudar o outro, a
questão das reuniões diárias e tudo o mais. Então, eu acho
que o Scrum influencia nessa questão da comunicação de
143
maneira muito positiva.” – Analista/Product Owner,
ALFA_P1_E3
“É... Isso ocorria muito [falta de comunicação]. O que está

evitando muito disso... que tão ajudando muito são as
reuniões diárias.” – Engenheiro de Sistemas, ALFA_P1_E7
“Talvez por ter essa reunião diária, você vai criando esse
canal com as pessoas, e as pessoas terminam, através desse
canal, sendo mais comunicativas, digamos assim” –
“[Questionado sobre o que acha da comunicação da equipe]

Tá, hoje os times, eles trabalham no mesmo ambiente,
então... acredito que a comunicação do time funciona assim,
é muito direta, se o cara tem uma dúvida, ele vai lá, chega
para alguém do time e pergunta se alguém pode ajudar, se
alguém já resolveu e passou por aquele tipo de problema, se
ele tiver mais dificuldade, ele chega para o líder da equipe” –
Analista/Product Owner, ALFA_P1_E3
“Ah, a interação da gente ta boa, porque todo senta um do

lado do outro, né? Então a gente sempre fica se
comunicando...” – Engenheiro de Sistemas, BETA_P2_E4
B7_EC. Permite uma maior colaboração entre a equipe

Devido à ênfase das Metodologias Ágeis na interação e na comunicação entre
os membros da equipe, diversas práticas ágeis foram propostas, o que
permitiu, como consequência, a colaboração entre a equipe. As reuniões
diárias e o uso de metas e problemas compartilhados nos projetos foram as
práticas mais identificadas nos estudos de caso. A Figura 41 apresenta todas
as práticas identificadas que permitiram o benefício.
144
Figura 40 – B7_EC. Permite uma maior colaboração entre a equipe


As reuniões diárias do Scrum foram identificadas em três entrevistas como
prática importante que permite melhor colaboração entre a equipe. Os
entrevistados pertenciam aos projetos P1 da empresa ALFA e P1 da empresa
BETA.
Na empresa ALFA, um engenheiro de sistemas [ALFA_P1_E7] afirmou
que devido às reuniões diárias, a cultura da equipe passou a ser de mais
comunicação e cooperação, o que permitiu a identificação e a resolução dos
problemas mais facilmente.
Na empresa BETA, o líder da equipe do projeto P1 [BETA_P1_E3]
afirmou que as reuniões permitem falar das dificuldades e receber ajuda de
outros membros para resolvê-las.
Metas e Problemas compartilhados

Nos projetos que usam o Scrum, a meta de entrega das Sprints é
compartilhada e não individual o que, de acordo com as entrevistas, permite
uma maior colaboração entre a equipe. Esse benefício, resultante desta
prática, foi identificado apenas nos projetos da empresa BETA.
De acordo com a entrevista do engenheiro de sistemas
[BETA_P1_E4], percebe-se que sua fala foca bastante em “a gente”, pois ele
145
afirmou que o trabalho é colaborativo, sendo esta a meta das Sprints
compartilhadas. Por isso, quando algum membro da equipe está com alguma
dificuldade, outro membro para a sua atividade para ajudá-lo.
A visão colaborativa também é perceptível na entrevista de outro
engenheiro de sistemas [BETA_P1_E7], afirmando que a entrega da Sprint tem
que ser tudo o que foi planejado, e não apenas parte dela. Assim, estão
sempre ajudando uns aos outros para atingir a meta.

“[...] eu acho que a cultura do time ela passa também mais

voltada pra comunicação e pra cooperação, a partir do
momento que você tem isso, oh, a gente todo dia vai se reunir
pra cada um dizer o que fez o que ta fazendo e par sugerir aí
como isso vai ser resolvido.” – Engenheiro de Sistemas,
ALFA_P1_E7.
“As reuniões diárias também, que quebra esse gelo, né? Eu

falo das minhas dificuldades: [“_To tendo dificuldade, preciso
de ajuda”], aí a pessoa do lado: [“Ah, ta precisando de
ajuda?”]...” – Líder de Equipe/Scrum Master, BETA_P1_E3
“[O entrevistado afirmou que o ambiente com o Scrum é mais

colaborativo, então foi solicitada a sua opinião sobre o quê
influencia essa colaboração]
Tem influência por conta das reuniões, que um ajuda o outro,
que um ta cobrando ao outro da tarefa, quem ta dividindo tarefa
com cada um, tem um dono da tarefa... colabora, sim.” –
“É muito comum você ver uma pessoa que está com a

atividade, mas está com a sua atividade no seu tempo correto,
vai conseguir entregar no prazo ou até mais rápido, aí para o
que está fazendo e vai ajudar outras pessoas.” –
146
“É tudo ou nada, oito ou oitenta, acho que a ideia de... a visão

que a equipe tem realmente é “só a gente entrega”, a gente
tem esse problema para resolver, nessa Sprint, então a
gente vai resolver isso e entregar isso.” – Engenheiro de
Sistemas, BETA_P1_E4
“Uma coisa que é bem legal na nossa equipe é isso: a gente

tem uma tarefa, só que às vezes uma pessoa pode ter um
domínio melhor ou já fez alguma coisa parecida com aquilo.
Então, a gente tem muito isso: ta fazendo a tarefa, alguém
precisa, ajuda, para um pouquinho, ajuda e volta. Isso não
atrapalha nada, só ajuda a equipe, assim, pensando no todo,
né? Porque no todo... não adianta de nada você terminar
uma tarefa sem o outro não ter terminado, porque aquilo
faz parte da entrega, né?” – Engenheiro de Sistemas,
BETA_P1_E7
B8_EC. Melhora a comunicação entre o cliente (ou

representante) e a equipe
As Metodologias Ágeis enfatizam a comunicação constante e a colaboração
com o cliente, através de diversas práticas. Com base na análise das
entrevistas, foi identificado que houve melhoria na comunicação entre o cliente
e a equipe em três projetos investigados.
As práticas ágeis e as cerimônias do Scrum foram identificadas por
proverem este benefício; entre elas, a principal foi a prática de incentivar a
participação do cliente para que este esteja sempre presente no projeto. Em
segundo lugar está a cerimônia de planejamento da Sprint (Sprint Planning). A
Figura 41 apresenta todas as práticas identificadas que permitiram o benefício.
147
Figura 41 – B8_EC. Melhora a comunicação entre o cliente (ou representante) e a
equipe

Customer Involvement
A constante presença (ou o envolvimento do cliente) nos projetos foi vista como
benéfica para três entrevistados dos projetos P1 e P2 da empresa BETA.
De acordo com o engenheiro de sistemas [BETA_P1_E2] o cliente está
sempre que pode presente nas reuniões, considerando essa participação muito
benigna ao projeto. Para o engenheiro [BETA_P1_E1], o forte envolvimento do
cliente no processo, proveu abertura para que a equipe pudesse falar
diretamente com o mesmo. De acordo com o líder da equipe [BETA_P1_E3],
quando o cliente não pode estar presente em um planejamento da Sprint,
reúnem-se antes e discutem todas as questões.
No projeto P2, uma engenheira de testes que também atua como
Product Owner interno [BETA_P2_E3] afirmou que o cliente está sempre
presente e ajuda a manter o contato com a equipe, pois entende o
funcionamento do Scrum porque o utilizam em sua empresa.
Sprint Planning
O planejamento da Sprint do projeto da empresa ALFA sempre contou com a
presença do Product Owner, o que, de acordo com o analista/Scrum Master
[ALFA_P1_E1], é importante, pois permite um canal aberto de comunicação
148
entre o PO e a equipe.
No projeto P2 da empresa BETA, o cliente não estava presente
fisicamente, mas em constante comunicação com a equipe, o que facilitava a
execução do planejamento, pois de acordo com o líder técnico, o feedback do
cliente era instantâneo.

entrevistas que o benefício em questão.
“[...] O cliente ta sempre presente nas reuniões que são

agendadas, de acordo com a Sprint. E o contato é super...
benigno pro projeto e só tenho a dizer que funciona muito
bem.” – Engenheiro de sistemas, BETA_P1_E2
“O cliente ta muito envolvido no processo... qualquer coisa,

a gente tem autonomia de falar com ele diretamente.” –
Engenheiro de sistemas, BETA_P1_E1
“[...] então, no planejamento ele ta presente

constantemente, mesmo quando... quando ele não está a
gente agenda as reuniões, né, ele discute todas as questões.
Ele sempre que pode ta presente.” – Líder de equipe,
BETA_P1_E3
“Então, assim, a gente tem contato e todos eles também

trabalham com Scrum lá. Então, eles tão bem treinados
também, têm experiências. [...] Então, assim, eles são bem
proativos. Eles ajudam, tentam a ajudar a manter contato...”
– Engenheira de Testes/Product Owner, BETA_P2_E3
“Participava completamente dessa parte até porque teria que

dizer ao cliente como entregaria e de que forma iria entregar a
ele. E... Essa participação é importante para nós e para ele
também né? Pois fica um canal aberto pra gente se
comunicar” – Analista/Scrum Master, ALFA_P1_E1
149
“E, aí, de repente, se eles quiserem fazer alguma alteração
antes, aí, eles dizem: [“_Tira essa, bota outra”]. Essa alteração
ocorre na hora, porque eles sabem o dia e hora do planning, aí
ficam sempre online. Isso é era ótimo, feedback
instantâneo...” – Líder técnico, BETA_P2_E2
B9_EC. Melhora o processo de desenvolvimento

O Scrum possui três pilares, sendo um deles, adaptar o que não está bom, ou
que pode ser melhorado. Por isso, todos os projetos investigados
apresentaram indícios de que o uso do Scrum tem permitido a melhoria do
processo, devido às reuniões de retrospectiva (Sprint Retrospective) que
ocorrem ao final das Sprints.
De acordo com o analista/Scrum Master [ALFA_P1_E1] do projeto da
empresa ALFA, os problemas identificados nas reuniões de retrospectiva têm
sido entregues aos responsáveis e algumas melhorias têm sido percebidas. E o
analista/Product Owner [ALFA_P1_E3] do mesmo projeto afirmou que isso é
bom porque se tem a opinião de várias pessoas. Essa mesma opinião é
compartilhada por um engenheiro de sistemas [BETA_P1_E1].

“Eu acho que está melhorando porque conseguimos apresentar

às pessoas que são responsáveis por resolver aquele
problema a questão em si que ocasionou para que aquele
Sprint não tivesse sucesso pleno, completo. Então podemos
apresentar às pessoas e essas podem tomar suas atitudes e
decisões para tentar resolver isso. Nem sempre é possível,
mas às vezes isso tem trazido melhorias.” – Analista/Scrum
Master, ALFA_P1_E1
150
B10_EC. Melhora a qualidade do código
Diversas são as práticas que permitem melhorar a qualidade de código de um
projeto ágil. Nos projetos investigados, a programação em par (Pair
Programming) foi a principal prática, por prover o benefício em questão.
Algumas práticas, tanto de XP quanto do Scrum foram identificadas. A
Figura 42 apresenta todas as práticas identificadas que permitiram o benefício.
Figura 42 – B10_EC. Melhora a qualidade do código

A programação em par (Pair Programming) foi identificada em seis

entrevistas. Na empresa ALFA, o engenheiro de sistemas/Scrum Master
[ALFA_P1_E5] afirmou que gosta de código limpo e bem escrito, e ao fazer a
programação em par, isso se torna possível porque permite uma revisão de
código. Um engenheiro de sistemas [ALFA_P1_E7] afirmou que gosta da
prática, pois a discussão entre duas pessoas permite dar uma clareza melhor
ao código.

entrevistas que o benefício em questão.
“Eu gosto muito de código limpo, código bem escrito e às vezes

nós não vemos isso, seja pelo programador mesmo que não
tem esse costume, ou seja por prazo apertado, aí o cara faz de
qualquer jeito só para: rodou, tá beleza. Então, quando a
gente trabalha em par, a gente também faz uma revisão de
código.” – Engenheiro de Sistemas/Scrum Master,
151
ALFA_P1_E5
“Eu gosto muito [pair programming]. É, é às vezes só, às

vezes só de uma pessoa está do seu lado olhando parece que
já lhe dar uma clareza maior porque você vai explicando as
coisas enquanto vai fazendo. [...] Como também é tem certas
coisas que você tá já com a linha de raciocínio e o cara
costuma pensar de uma forma diferente então na hora ele já
diz porque que não faz assim.” – Engenheiro de Sistemas,
ALFA_P1_E7
4.3.2.2 Limitações
Foram identificadas 40 limitações nos estudos de caso; a lista completa e o
mapeamento destas com cada caso encontram-se no APÊNDICE L. Nos
próximos tópicos desta seção, são discutidas as 10 limitações que mais foram
identificados nos estudos de caso (Tabela 16). As limitações receberam um
identificador único, para se diferenciarem umas das outras.
Tabela 16 – Dez principais limitações identificadas nos estudos de caso

% Total de
ID Descrição da Limitação
entrevistados
L1_EC Dificuldade de trabalhar com equipes grandes 40,91%
L2_EC Dificuldade de estimar histórias 36,36%
Interferência do Product Owner com habilidades técnicas

L3_EC 31,82%
no planejamento da equipe
L4_EC Aspectos culturais 27,27%
L5_EC Dificuldade de se adaptar a constantes mudanças 13,64%

Dificuldade de trabalhar com individualismo e
L6_EC 13,64%
especializações
L7_EC Aumenta o tempo de desenvolvimento das atividades 13,64%
Dificuldade de apresentar algo funcional em projetos que
L8_EC 13,64%
não possuem interface gráfica
L9_EC Falta de identificação das contribuições individuais 9,09%
Necessita de Maturidade, Comprometimento e Pro
L10_EC 9,09%
atividade das pessoas
152
L1_EC. Dificuldade para se trabalhar com equipes grandes
A principal limitação identificada foi a dificuldade em utilizar as metodologias
ágeis em equipes grandes (acima de oito integrantes), sendo relatada por dez
entrevistados, de todos os projetos. A reunião diária do Scrum (Daily Scrum
Meetings) foi a prática mais identificada como sendo prejudicada quando se
tem muitas pessoas na equipe. Em seguida foi a reunião de planejamento do
Scrum (Sprint Planning). Outras práticas também foram citadas, como
apresenta a Figura 43.
Figura 43 – L1_EC. Dificuldade para se trabalhar com equipes grandes


identificadas para a limitação em questão e o mapeamento destas com

Na empresa ALFA, um analista/Scrum Master [ALFA_P1_E1] afirmou que não
se pode ter uma equipe muita grande porque as reuniões diárias (Daily Scrum
Meetings) e as de planejamento (Sprint Planning) não conseguem fluir bem.
Um gerente de projetos e também Scrum Master da empresa BETA
[BETA_P2_E8] do projeto P2 também fez a mesma afirmação a respeito das
reuniões diárias.
O analista/Product Owner [ALFA_P1_E3] da empresa ALFA acredita
que com uma equipe de cinco pessoas, no máximo seis, consegue-se fazer
funcionar as reuniões diárias e a comunicação do dia a dia bem. Essa mesma
opinião é compartilhada por um engenheiro de testes [ALFA_P1_E4].
153
Sprint Planning
Na empresa ALFA, um gerente de projetos [ALFA_P1_E2] afirmou que em
reuniões de planejamento com uma equipe grande perde-se muito o foco. E
para o gerente de TI [ALFA_P1_E6] do mesmo projeto, além das reuniões de
planejamento, as reuniões diárias também são prejudicadas, pois com muitas
pessoas essas reuniões podem se tornar dispersas.
[BETA_P1_E1] afirmou que trabalhar com muitas pessoas em uma reunião de
planejamento torna-se difícil, principalmente na hora de dividir as histórias em
tarefas, pois são muitas opiniões.

entrevistas que justificam a limitação em questão.
“Deixe-me ver outra limitação do Scrum... A quantidade de

pessoas. Não podemos ter um time de muitas pessoas. [...]
porque as reuniões não conseguem fluir bem, as
discussões se tornam... É.. tomam muito tempo!” –
Analista/Scrum Master, ALFA_P1_E1
“Eu acredito que hoje a literatura diz de quatro a nove pessoas,

mas eu acho que uma equipe de cinco, no máximo seis
pessoas é o que está funcionando mais legal, pelo menos aqui
na empresa. [...] Funciona mais legal por causa da
comunicação no dia a dia e nas reuniões diárias que ficam
melhor” – Analista/Product Owner, ALFA_P1_E3
“É muita gente. É aqueles quinze minutos, só que com uma

quantidade grande de pessoas, acho que pode ser um
tempo perdido.” – Engenheiro de Testes, ALFA_P1_E4
“Eu acho que quando você faz um planning com uma

equipe muito grande perde muito o foco. Eu acho que o
154
ideal é ser uma equipe pequena.” – Gerente de Projetos,
ALFA_P1_E2
“Até que um pouco mais pra frente a gente teve um novo

treinamento, o consultor deu um treinamento pra todo o
pessoal novo que entrou, e aí alinhou mais algumas coisas,
mas, como era muita gente, aí já foi um pouco mais difícil o
Scrum funcionar como a gente vinha funcionando desde o
início [menos pessoas]. [...] É... porque muita gente as reuniões
ficam muito, muito... Como posso dizer? Ficam é... acabam
dispersando ou... é muita gente falando. Imagina em uma
reunião diária ou no planning” – Gerente de TI, ALFA_P1_E6
“A gente... Houve uma época que teve nove pessoas... nove ou

dez... dez pessoas e, aí, sei lá, é muita gente. [..] Tipo... éhh...
até pra, sei lá, quebrar em nove ou dez vertentes fica
complicado [Sprint Planning 2]. Eu achei dez pessoas um
número grande de se trabalhar.” – Engenheiro de Sistemas,
BETA_P1_E1
L2_EC. Dificuldade de estimar histórias

O uso de histórias em equipes Scrum é muito comum; no entanto, de acordo
com os três projetos investigados, não tem sido uma tarefa fácil realizar a
estimativa das histórias, disseram os entrevistados.
Para um gerente de projetos [ALFA_P1_E2] da empresa ALFA, a
estimativa em pontos para as histórias não funcionam, pois não é uma medida
exata e varia muito de pessoa para pessoa. Completou ainda que, por ser
abstrata, torna-se difícil para estimar os custos e o tempo para cada história.
Um analista de sistemas/Product Owner [ALFA_P1_E3] alegou que as
estimativas tem sido um grande problema, pois a pontuação entregue por uma
mesma equipe tem variado muito entre as Sprints.
Para o engenheiro de sistemas [BETA_P1_E5] torna-se difícil estimar
em pontos quando não se conhece a tecnologia. Uma engenheira de
testes/Product Owner da mesma empresa, mas do projeto P2, afirmou que se
torna difícil estimar, devido à rotatividade das pessoas nos projetos e, ainda, às
155
pessoas que estão entrando com pouca experiência.

entrevistas que justificam tal limitação.
“Planning Poker? A minha visão é meio furada (risos) eu prefiro

estimar em horas. Por mais que seja uma estimativa, trabalhar
com pontos não funciona bem, pois varia de pessoa para
pessoa. Para mim, X pontos pode ser que eu faça tal coisa, e
para você, os mesmos X pontos, talvez você faça menos
coisas. Ao contrário das horas... é uma medida mais exata,
porque, a hora é uma unidade universal, não varia.” – Gerente
de projetos, ALFA_P1_E2
“Porque às vezes fica muito abstrato. É meio complicado

para você que é um gerente de projetos fazer uma estimativa
de custo e de tempo baseado em pontos, entendeu? [...] Você
precisa saber é em horas, em quanto tempo de trabalho será
necessário para fazer aquilo.” – Gerente de projetos,
ALFA_P1_E2
Hoje a gente tem um grande, eu diria que é um grande

problema assim, da prática que a gente está adotando, do
Scrum como um todo, que é na questão das estimativas. Os
pontos entregues variam muito de Sprint para Sprint. E
olhe que é a mesma equipe... E quando perguntamos o que
está havendo para a equipe, sempre a mesma resposta
"Erramos na estimativa da história X e Y". – Analista de
Sistemas/Product Owner, ALFA_P1_E3
“Só que no início era muito difícil definir o valor de cada

tarefa porque a gente não tinha conhecimento do que a gente
ia... a gente ia estudar uma tecnologia, era muito obscura
ainda.” – Engenheiro de sistemas, BETA_P1_E5
156
“Dando minha opinião pessoal, assim, eu to achando
desvantagem [estimar em pontos na Sprint Planning]. [...]
Porque o problema é que a gente ta mudado muito. Ta
entrando com frequência, assim, muita gente nova, sabe,
porque... devido... não sei se é coisa do [nome empresa], mas
ta saindo pessoas, entrando, então, assim, a gente tem
mudado a equipe um pouco constante, sabe? E pessoas cada
vez mais com menos experiência no projeto da gente ta
entrando e ta influenciando também, entendeu? Por exemplo,
na hora de pontuar e quebrar as atividades sempre gera muita
dúvida e tal, entendeu? [...]” – Engenheira de Testes/Product
Owner, BETA_P1_E5
L3_EC. Interferência do Product Owner com habilidades

técnicas no planejamento da equipe
As metodologias ágeis valorizam a participação do cliente ou de seu
representante durante todas as etapas do projeto. O método XP, por exemplo,
possui a prática de colocar o cliente dentro do ambiente de trabalho da equipe
(Customer Onsite). Para o Scrum, foi definido o papel do Product Owner, que
pode ser o próprio cliente ou o seu representante, que deve ter participação
ativa no projeto. No entanto, às vezes essa participação atrapalha o
desenvolvimento das atividades da equipe, como foi percebido em algumas
entrevistas.
identificadas para a limitação em questão e o mapeamento destas com
Sprint Planning
Um analista de sistemas/Scrum Master [ALFA_P1_E1] alegou que devido ao
fato de o Product Owner possuir domínios técnicos, este fazia interferências na
estimativa da equipe, atrapalhando muitas vezes o planejamento da equipe,
que demorava mais do que o necessário.
No projeto P2 da empresa BETA, o cliente possuía conhecimentos
técnicos e tinha uma participação muito ativa no projeto, interferindo algumas
157
vezes na estimativa da equipe, de acordo com a Engenheira de Testes/Product
Owner [BETA_P2_E3].

“Algumas vezes ele interferiu, mas não a fundo até porque o

próprio time consegue dizer o que tem capacidade de entregar
e não teria como ser redutível isso aí. Mas ainda assim, ficava
uma discussão entre o PO e a equipe, pois ele [PO] ficava
tentando convencer a equipe a mudar a estimativa. E às
vezes, infelizmente conseguia.” – Analista de sistemas/Scrum
Master, ALFA_P1_E1
“Às vezes ele questiona, assim... questiona: [“_Ah, não sei, a

pontuação ta muito alta, pode melhorar...”]...” – Engenheira
de Testes/Product Owner, BETA_P2_E3
L4_EC. Aspectos culturais

As metodologias ágeis enfatizam a comunicação, a colaboração entre a equipe
e entre o cliente. Para isso, possuem algumas práticas e atitudes que exigem
mudanças comportamentais dos indivíduos e das organizações, podendo então
existir resistências ou outras barreiras culturais que limitam o uso destas
metodologias nos projetos. Nos estudos de caso investigados, todas as
limitações relacionadas aos aspectos culturais foram identificadas devido a
aspectos individuais.
No projeto ALFA, um analista de sistemas/Scrum Master
[ALFA_P1_E1] afirmou que pelo fato de o Scrum ser uma metodologia
baseada na colaboração, torna difícil e às vezes até atrapalha o andamento do
projeto, quando existem pessoas que tem receio de conversas, colaboração ou
disseminação do conhecimento.
O líder do projeto P1 [BETA_P1_E3] da mesma empresa afirmou que
havia um engenheiro de sistemas que era muito bom tecnicamente, mas que
158
não gostava de participar das reuniões. De acordo com o entrevistado, isso
atrapalhava os outros em relação a saberem sobre o andamento de suas
atividades. Um engenheiro de sistemas do mesmo projeto [BETA_P2_E5] falou
sobre essa mesma pessoa, afirmando que não se sentia à vontade para tirar
dúvida com ela, por ser muito fechada.

“Por ser uma metodologia baseada em colaboração eu acho

que interfere sim. Interfere naquele tipo de pessoa que tem
certo tipo de receio em conversar, em colaborar, em
disseminar o conhecimento. E se isso realmente ocorrer, ou
melhor, já ocorreu né? Muitas vezes atrapalha todo o time. E...
o projeto, claro!” – Analista/Scrum Master, ALFA_P1_E1
“[...] ele é um cara muito técnico. Então, ele... essas coisas

[reuniões] que perde tempo, que não seja desenvolvimento,
pra ele é perda de tempo. Não gostava de jeito nenhum em
participar. Chegava atrasado nas reuniões e sempre bem
calado. Mas ele é muito bom tecnicamente.” – Líder de
Equipe/Scrum Master, BETA_P1_E3
“O Scrum não trabalha com aquela pessoa que é fechada:

[“_Oh, me dá o que tem que fazer aí, que eu faço sozinho!”].
Não é assim. [...] Tinha uma pessoa, que era meio
complicado... ele era bem fechadão, assim. Ele tinha um
conhecimento técnico bom, mas era complicado. Tinha
uma atividade que a gente não tinha noção, aí: [“_pergunta a
fulano!”]. Aí a gente já ficava meio assim, né, pra perguntar a
ele. Eu não me sentia à vontade pra perguntar...” –
159
L5_EC. Dificuldade de se adaptar a constantes mudanças
O Manifesto Ágil (AGILE MANIFESTO, 2001), em um de seus princípios, afirma
que as mudanças de requisitos devem ser aceitas no projeto, até mesmo em
sua fase final. No entanto, de acordo com os relatos dos entrevistados,
observa-se que eles têm dificuldades em seus projetos para se adaptarem a
essas mudanças, principalmente quando são constantes ou quando envolvem
custos adicionais para algumas das partes.
afirmou que no início do projeto o cliente mudava muito o direcionamento
deste, refletindo no Backlog. Isso dificultou o inicio do desenvolvimento do
projeto. No projeto P2 da mesma empresa, um engenheiro de sistemas
[BETA_P2_E5] afirmou que as mudanças vindas do cliente ocorriam quando
eram feitas as reuniões de planejamento (Sprint Planning), tendo que refazer o
planejamento, tornando isso cansativo.
A empresa ALFA, de acordo com o engenheiro de sistemas
[ALFA_P1_E7], teve problemas devido às mudanças de requisitos, pois estas
alteraram praticamente toda a especificação inicial, acarretando em prejuízo
para a empresa.

“[...] o cliente às vezes muda muito de direcionamento em

alguns momentos, isso reflete no... Digamos assim, o único
contra tempo que nós tivemos até hoje no Scrum, era ficar
sempre refletindo isso em nosso Backlog... Ás vezes não
sabíamos o que fazer, o que iniciar, porque o backlog estava
muito instável. Tão instável, e com poucos requisitos. Então foi
difícil no início...” – Engenheiro de Sistemas, BETA_P1_E4
“Agora, só na hora de planejar mesmo, porque, planeja uma

vez, manda: [“_Não, mas eu quero aquele requisito”], aí lá
vai a gente planejar de novo. Aí fica um fluxo... Tem vez que a
160
gente fica três vezes na semana direto nessa agonia, aí se
torna o negócio maçante.” – Engenheiro de Sistemas,
BETA_P2_E5
“Agora validamos os requisitos, e assinar fazemos o cliente

assinar [documento]. Até porque a gente já teve alguns
problemas com mudanças que... não tavam documentadas,
então, não tinha como dizer: "Não, isso aí... foi uma alteração
de requisito", e cobrar mais do cliente... Aí né, acabou ficando
um clima chato. E a mudança foi bem radical, praticamente
mudou tudo. E como a empresa aqui recebe por pontos de
função, que... que no final é pago por hora, aí complicou. A
gente disse que essas horas das alterações teriam que ser
cobradas, e o cliente não aceitou! Resultado? Prejuízo né?” –
Engenheiro de Sistemas, ALFA_P1_E7
L6_EC. Dificuldade de trabalhar com individualismo e

especializações
Com base na análise das entrevistas dos estudos de caso, foi constatada a
dificuldade das equipes ágeis de lidarem com individualismo e equipes que
possuem diversas especializações, principalmente durante as cerimônias de
Sprint Planning e Sprint Review.
As limitações foram identificadas nas entrevistas de três funcionários
da empresa ALFA. O gerente de projetos [ALFA_P1_E2], ao ser indagado
sobre como estão funcionando as reuniões diárias e as de Review, se todos
participavam e se estavam adequadas, informou que os engenheiros de testes
e de sistemas participam juntos das reuniões, informando que existem
momentos da reunião em que pessoas de uma determinada especialidade
ficam dispersas por não se interessarem pelo que o outro está dizendo.
Outra limitação foi identificada por um engenheiro de teste
[ALFA_P1_E4], que informou que durante as reuniões de planejamento (Sprint
Planning) os testadores e os desenvolvedores participavam todos juntos, sendo
que isto gerava muita divergência na pontuação.
A empresa ALFA resolveu começar atribuir um dono para cada história,
de modo que a pessoa se responsabilizasse por finalizá-la; no entanto, a
161
escolha fica a critério de cada um. Isso foi percebido pelo engenheiro de
sistemas [ALFA_P1_E5] como um dos problemas da dispersão das reuniões
diárias, informando que, se as histórias fossem compartilhadas, esse problema
poderia não existir.

“Realmente fica disperso porque o cara sabe que aquela

história é uma parte do sistema que quem mexe naquilo é o
desenvolvedor e aí ele meio que fica... Não interessa para
ele. Entendeu?” – Gerente de Projetos, ALFA_P1_E2
“A gente [desenvolvedores e testadores] estimava, mas

estava dando muita divergência. [...] São duas áreas
diferentes, não tem como você estimar junto a história,
sabe?” – Engenheiro de Testes, ALFA_P1_E4
“[...] Mas na reunião diária, como tem esse problema de

dispersão, às vezes, se fossem compartilhadas as histórias
ainda, se aquele cara está falando, eu posso ir trabalhar
naquela história junto com ele, então é bom eu estar
escutando o que ele fala.” – Engenheiro de Sistemas,
ALFA_P1_E5
L7_EC. Aumenta o tempo de desenvolvimento das atividades

O método XP possui práticas que permitem obter uma melhor qualidade do
código. No entanto, as práticas do TDD e de Refactoring não foram bem vistas
no projeto P2 da empresa BETA.
O TDD foi utilizado no início do projeto P2, no entanto logo foi
abandonado, pois segundo o engenheiro de sistemas [BETA_P2_E1], a prática
impactou um “pouquinho” positivamente na qualidade do projeto. Contudo, o
impacto negativo nas estimativas iniciais do projeto foi superior, interrompendo
o uso da prática. Outro engenheiro de sistemas [BETA_P2_E6] do mesmo
162
projeto afirmou que o TDD é muito bom, mas apresenta problema de aumento
do tempo de desenvolvimento devido ao fato de seu uso ter sido identificado.
A prática de Refactoring também foi utilizada por um engenheiro de
sistemas [BETA_P1_E7]; no entanto, segundo o engenheiro, a prática estava
aumentando o tempo para desenvolver as histórias.

“Ele [TDD] impactou um pouquinho no projeto [qualidade], mas

nas estimativas iniciais do projeto, negativamente. Ele
impactou negativamente na questão de tempo, até porque a
gente só passava pra próxima atividade, quando essa atividade
tivesse 100% no teste. E aí isso impactou o projeto em
aproximadamente 15% do tempo estimado.” – Engenheiro
“Muito bom o TDD, mas o custo é alto de manutenção,

porque você ta evoluindo sempre, então o tempo dobra.” –
“No início, a gente pensou assim: [“_Não, a gente faz e

refatora”]. Mas às vezes estava demorando muito tempo e
não dava tempo de você fazer aquilo tudo dentro da Sprint.” –
L8_EC. Falta de identificação das contribuições individuais

O Scrum define que a meta da Sprint deve ser para toda a equipe, valorizando
assim a meta compartilhada do projeto, ao invés da meta individual, de modo a
assegurar o comprometimento de todos da equipe para a entrega de software
funcional ao fim da Sprint.
O uso da meta compartilhada foi percebido nas entrevistas dos
gestores da empresa ALFA como um problema para o projeto, pois não permite
identificar as contribuições ou falhas individuais de cada membro da equipe, de
163
acordo com o gerente de TI [ALFA_P1_E6] e o gerente de projetos
[ALFA_P1_E2], fazendo com que algumas pessoas não trabalhem
adequadamente.

“Estou aqui com quatro pessoas, três estão trabalhando bem

e entregando as coisas e uma está parada não entregando
nada. Aí acaba que é o time todo [que não fez a entrega].” –
Gerente de projetos, ALFA_P1_E2
“[...] eu disse [na Sprint Planning] que eram treze pontos, a

galera concordou que era isso, aí vai lá uma pessoa que faz
corpo mole, pega o código, aí de repente acha uma solução
que era... faria isso em dois minutos, e como não mostra
[“_não isso daqui é treze pontos, eu vou ficar
confortavelmente uma semana, tranquilo_”]. E fica lá
fazendo migué, e não entrega.” – Gerente de TI,
ALFA_P1_E6
“É, de fato muita gente acha que: ah, não, eu vou... é aquela
história, planejou cinquenta pontos um time. Aí o time vai e
entrega trinta. Mas o Scrum prega o quê? O time falhou, o
time. Mas as vezes esses vinte pontos que não foram
entregues foi um escrotão que não fez, que não trabalhou bem,
e aí como é um time, o time é responsabilizado. A vista lá de
cima, da diretoria ou da gerência é dizer o quê? [“_O time não
entregou, o time vai ser punido_”], se fosse de fato punido, vai
ser cobrado.” – Gerente de TI, ALFA_P1_E6
L9_EC. Dificuldade de apresentar algo funcional em projetos

que não possuem interface gráfica
O Manifesto Ágil (AGILE MANIFESTO, 2001) possui, como um de seus
princípios, a entrega frequente de software funcional, na escala de semanas ou
164
meses, mas com preferência para intervalos mais curtos. No entanto, foi
identificada através das entrevistas a dificuldade de entregar algo funcional no
caso de projetos que não possuem uma interface gráfica.
O projeto P1 da empresa BETA foi o único identificado com este
problema. Isso se deve ao fato de que o projeto é escrito na linguagem C,
sendo um pouco mais complicado entregar algo em uma ou duas semanas,
como afirmou o engenheiro de sistemas [BETA_P1_E2]. Essa mesma visão é
compartilhada pelo líder de equipe [BETA_P1_E3].

“Talvez por trabalhar com linguagem C, entregar algo

funcional com uma semaninha só, em C é complicado. C é
mais... a gente rala mais pra fazer as coisas...” – Engenheiro
“[...] é bastante difícil a gente conseguir ter algo funcional pela

própria natureza do projeto, né? [...] Por saber que não teria
como uma Sprint entregar algo funcional, o cliente lá optou por
não usar Sprint Review pra não dar essa ideia de não ter algo
funcional. A gente chama de Check Point. Dá na mesma coisa.
São agendamentos, né, são entregas agendadas...” – Líder de
equipe, BETA_P1_E3
L10_EC. Necessita de Maturidade, Comprometimento e Pro

Para que as práticas ágeis de XP ou as cerimônias do Scrum funcionem,
devem ser seguidas com seriedade, exigindo assim indivíduos motivados,
capacitados e comprometidos com a entrega, como descreve o Manifesto Ágil
(AGILE MANIFESTO, 2001). No entanto, mesmo com o uso das metodologias
ágeis nos projetos, os estudos de caso apresentaram dificuldades quando se
trata dessas questões, dificultando assim o uso da metodologia por completo
165
nos projetos.
O gerente de projetos [ALFA_P1_E2] da empresa ALFA afirmou que é
difícil conseguir entregar sempre algo funcional ao cliente a cada Sprint, pois
nem sempre estão conseguindo entregar todas as funcionalidades planejadas.
Ele acredita que isso se deve ao fato de que muitas vezes as pessoas não
possuem o comprometimento e a maturidade suficientes, limitando assim o
autogerenciamento da equipe.
A necessidade de maturidade e comprometimento da equipe para o
Scrum funcionar corretamente e permitir o autogerenciamento foi bastante
enfatizada pelo gerente [ALFA_P1_E2] ao longo da entrevista. Ele acredita que
muitos de sua equipe ainda não os possuem. A mesma visão foi compartilhada
pelo gerente de TI desta mesma empresa [ALFA_P1_E6], afirmando que o
autogerenciamento não funciona 100% em todas as equipes, alegando que
muitas pessoas só trabalham sob pressão.

“Para o Scrum realmente funcionar e a equipe ser

autogerenciarável... O ideal é que você não tenha nem gerente,
se a equipe é autogerenciável você não precisa de um gerente
de projetos. E o que acontece é que as pessoas às vezes não
estão preocupadas. Ela assumiu que vai entregar dez
histórias naquele Sprint, ela sabe que naquela Sprint tem que
entregar dez histórias, tem que trabalhar, fazer uma força para
entregar aquelas dez histórias, mas o que acontece é que, às
vezes se você não tiver uma pessoa lá: E aí terminou? Está
pronto, não está pronto? Entrega tal dia! A pessoa não faz! [...]
Tem que ter maturidade grande para poder utilizar o Scrum
e realmente ser autogerenciável, se a equipe não for
madura não funciona.” – Gerente de projetos, ALFA_P1_E2
“Infelizmente eu acredito que tenha algumas pessoas que

ainda só funcionam se for assim. [...] Só trabalham sob
166
pressão. E o fato hoje é que a gente não tem, não vou mentir,
hoje a gente não tem um time, os times daqui não são
totalmente auto gerenciados.” – Gerente de TI, ALFA_P1_E6

obtidos com esta etapa da pesquisa, que objetivou responder à Q2.
Características das empresas, dos projetos e dos entrevistados

Com base na análise da Tabela 11, é possível perceber que existe uma grande
diferença de porte das empresas dos projetos investigados.
De acordo com a Tabela 12, 13 e 14, percebe-se que o projeto P2 da
empresa BETA possuía um nível de experiência maior com relação ao
desenvolvimento de software, em comparação aos outros projetos. Com
relação ao tempo de experiência com as metodologias ágeis, o projeto P2 da
empresa BETA possuía a equipe mais experiente, depois vem a equipe da
empresa ALFA e, por último, o projeto P1 da empresa BETA, onde a maioria
dos integrantes trabalhava há pouco tempo com estas metodologias.
Os projetos possuíam características diferentes. O projeto da empresa
ALFA e o projeto P1 da empresa BETA foram considerados de complexidade
média, enquanto todos os integrantes consideram bastante complexo o projeto
P2 da empresa BETA, devido à complexidade do negócio e ao tempo
existência do projeto.
Benefícios
Foram identificados 52 benefícios a partir das entrevistas e os vinte primeiros
foram citados por pelo menos um entrevistado de cada projeto.
Com base na análise das sete entrevistas conduzidas na empresa
ALFA, 34 dos 52 benefícios foram identificados pelos entrevistados. Para o
projeto P1 da empresa BETA esse número caiu para 31 e, para o projeto P2,
foram identificados 40 benefícios. Esse resultado pode ter sido reflexo da
experiência dos entrevistados com essas metodologias.
Diversos benefícios identificados com a condução dos estudos de caso
também foram identificados por Begel e Nagappan (2007), Dybå e Dingsøyr
167
(2008) e Petersen e Wohlin (2009).
O principal benefício relatado por 21/22 entrevistados (95,45%) foi a
facilidade de acompanhar e monitorar o projeto, principalmente devido ao uso
do quadro de tarefas (Task Board).
Limitações
Foram identificadas 40 limitações a partir das entrevistas e as cinco primeiras
foram citadas por pelo menos um entrevistado de cada projeto.
Com base na análise das entrevistas conduzidas na empresa ALFA, 27
das 40 limitações foram identificadas pelos entrevistados. Para o projeto P1 da
empresa BETA esse número caiu para 14 e para o projeto P2, foram
identificadas 18 limitações.
A principal limitação identificada nos estudos de caso foi a dificuldade
de utilizar as metodologias ágeis em projetos com equipes grandes. Este
também foi o principal problema relatado na pesquisa conduzida por Begel e
Nagappan (2007). A questão dos aspectos culturais dos indivíduos e da
organização também foi percebida como uma limitação.
Outras limitações identificadas também foram constatadas em outros
estudos, como o aumento no tempo das reuniões, identificada por Petersen e
Wohlin (2009).
4.4 Síntese da comparação: Revisão Sistemática da

Literatura versus Estudos de Caso
Esta seção apresenta discussões sobre os resultados obtidos para responder
Q3: “Quais são as similaridades e diferenças entre os benefícios e as
limitações das Metodologias Ágeis reportados na literatura, com relação aos
resultados obtidos com um conjunto de empresas de desenvolvimento de
software do Porto Digital de Pernambuco que utilizam tais metodologias?” de
pesquisa deste trabalho. A seção está dividida em duas partes:
 Mapeamentos das evidências – apresenta e descreve as evidências
obtidas por meio das entrevistas conduzidas nos estudos de caso para
responder questão de pesquisa (Q3);
168
4.4.1 Mapeamento das Evidências

A terceira questão (Q3) de pesquisa deste trabalho objetivou responder: “Quais
são as similaridades e diferenças entre os benefícios e as limitações das
Metodologias Ágeis reportados na literatura, com relação aos resultados
obtidos com um conjunto de empresas de desenvolvimento de software do
Porto Digital de Pernambuco que utilizam tais metodologias?”.
Para responder a esta questão, primeiramente foi conduzida uma
Revisão Sistemática da Literatura, onde foram identificados 79 benefícios e 63
limitações devido ao uso das Metodologias Ágeis no desenvolvimento de
software; e estudos de casos múltiplos em três projetos que utilizavam o
Scrum, sendo identificados 52 benefícios e 40 limitações.
Um mapeamento entre os resultados das pesquisas foi realizado,
obtendo-se 45 benefícios correspondentes. Apenas 07 benefícios identificados
nos estudos de caso não se aplicam aos resultados da literatura. A Tabela 17
mostra os benefícios correspondentes entre as pesquisas.
Tabela 17 – Mapeamento entre os benefícios dos estudos de caso e da literatura

ID Estudo de Mapeamento com
Descrição do Benefício
Caso a SLR
Facilita o acompanhamento e monitoramento
B1_EC B3
do projeto
Facilita o compartilhamento do conhecimento
B2_EC B1
entre a equipe
Melhora o entendimento das histórias de
B3_EC B31
usuários
B4_EC Facilita a interação entre a equipe B15
B5_EC Facilita a resolução de problemas B16
B6_EC Melhora a comunicação da equipe B2
B7_EC Permite uma maior colaboração entre a equipe B6
Melhora a comunicação entre o cliente (ou
B8_EC B8
representante) e a equipe
169
B9_EC Melhora a qualidade do código B5
B10_EC Feedback rápido/frequente B4
B11_EC Melhora o processo de desenvolvimento B19
B12_EC Entrega frequente de software funcional B9
B13_EC Melhora o entendimento sobre o projeto B14
B14_EC Aumenta a autonomia da equipe B43
Facilita o desenvolvimento de atividades

B15_EC B69
complexas
B16_EC Permite uma maior discussão sobre o projeto B46
Reduz a quantidade de defeitos/erros no

B17_EC B13
projeto
B18_EC Problemas são descobertos mais cedo B22
B19_EC Permite a identificação rápida de defeitos/erros B40
B20_EC Torna o ambiente mais agradável B27
B21_EC Melhora a priorização dos requisitos B25
B22_EC Aumenta o envolvimento da equipe no projeto B17
B23_EC Melhora a estimativa de esforço do projeto B57
B24_EC Melhora a qualidade do projeto B10
B25_EC Permite a correção rápida dos defeitos/erros B35
B26_EC Aumenta a satisfação do cliente B26
B27_EC Reduz o retrabalho B44
B28_EC Reduz a interferência externa B34
B29_EC Reduz a documentação B11
B30_EC Entrega de software no prazo B58
Melhora o planejamento e gerenciamento do

B31_EC B24
projeto
B33_EC Aumenta a coesão da equipe B28
B34_EC Aumenta a produtividade da equipe B7
170
B35_EC Reduz a complexidade do código/projeto B12
B36_EC Permite a revisão contínua do código B36
B38_EC Metas e Problemas compartilhados B38
B40_EC Reduz os custos do projeto B45
B41_EC Reduz o impacto de riscos no projeto B71
B42_EC Aumenta a motivação da equipe B21
B45_EC Facilita a estimativa das tarefas B49

B46_EC Facilita o desenvolvimento das atividades B54
B47_EC Aumenta as chances de sucesso do projeto B32
Aumenta o comprometimento da equipe com o
B48_EC B60
projeto
Torna eficiente a resposta às mudanças de
B49_EC B18
requisitos
B52_EC Permite uma maior adaptabilidade B63
Um mapeamento com as limitações identificadas em ambas as

pesquisas também foi realizado, obtendo-se 25 limitações correspondentes e
15 limitações identificadas nos estudos de caso não se aplicam aos resultados
da literatura. A Tabela 18 mostra as limitações correspondentes entre as
pesquisas.
Tabela 18 – Mapeamento entre as limitações dos estudos de caso e da literatura

ID Estudo Mapeamento
Descrição da Limitação
de Caso com a SLR
L1_EC Dificuldade de trabalhar com equipes grandes L13
L2_EC Dificuldade de estimar histórias L44
L4_EC Aspectos culturais L3
L5_EC Dificuldade de se adaptar a constantes mudanças L12
L6_EC Dificuldade de trabalhar com individualismo e L2
especializações
L7_EC Aumenta o tempo de desenvolvimento das atividades L16
L8_EC Dificuldade de apresentar algo funcional em projetos L42
que não possuem interface gráfica
L9_EC Falta de identificação das contribuições individuais L55
171
L10_EC Necessita de Maturidade, Comprometimento e Pro L30
L11_EC Histórias e tarefas são poucas especificadas L26
L12_EC Pouca documentação L15
L14_EC Aumenta o tempo das reuniões L38
L15_EC Possuir mais de um interessado com poder de decisão L31
sobre os requisitos e prioridades
L18_EC Dificuldade de se concentrar com equipes L45
colocalizadas
L20_EC Aumenta os custos do projeto L11
L22_EC Dificuldade em lidar com os clientes que gostam de L48
documentação abrangente
L23_EC Pouco foco sobre a arquitetura de software L19
L25_EC Dificuldade em implementar a técnica de TDD L22
L27_EC Dificuldade de gerenciar requisitos dependentes L20
utilizando apenas o quadro
L28_EC Aumenta a pressão para entrega do trabalho L10
L32_EC Exige mudança de mentalidade/comportamento L18
L36_EC Dificuldade de programação em par L8
L37_EC Sobrecarga de gerenciamento (muitas reuniões) L63
L39_EC Muito formalismo nas reuniões pode inibir uma boa L59
comunicação
L40_EC Difícil de ser utilizado em projetos complexos L39

Benefícios
A quantidade de benefícios identificados na literatura foi maior devido à busca
ampla pelos estudos de qualquer tipo de metodologia ágil, ao contrário dos
estudos de caso que focaram especificamente em projetos que utilizavam o
Scrum. No entanto, dos 52 benefícios identificados nos estudos de caso, 45
172
também são similares aos da literatura. Os cinco principais benefícios da
literatura também estavam entre os principais dos estudos de caso.
Limitações
Os resultados apresentados mostram que houve semelhanças nos resultados
dos estudos, não com a mesma proporção dos benefícios, mas ainda assim,
62,5% dos resultados obtidos com os estudos de caso se assemelham aos
resultados da literatura.
4.5 Resumo
Este capítulo apresentou os resultados obtidos com a condução da pesquisa,
obtidos através dos métodos de coleta utilizados.
Um questionário foi aplicado com as empresas de desenvolvimento de
software do Porto Digital de Pernambuco, objetivando identificar as empresas
que utilizavam uma metodologia ágil. Foram obtidas 44 respostas válidas, entre
estas, 30 empresas utilizavam uma metodologia ágil, sendo o Scrum a
metodologia ágil utilizada por todas as trinta. A maioria das empresas utilizava
a metodologia ágil há menos de seis meses, seguido pelo uso de um a dois
anos.
Uma Revisão Sistemática da Literatura (SLR) foi conduzida,
objetivando identificar os estudos empíricos sobre as Metodologias Ágeis que
apresentam os benefícios e as limitações destas metodologias. A pesquisa
envolveu nove pesquisadores, sendo sete alunos da pós-graduação e dois
professores.
Na condução da SLR foram utilizadas diversas fontes de busca
automática e manual, sendo identificados 6.856 estudos. Entre estes, 125
foram selecionados para serem avaliados criticamente e seus dados serem
extraídos para responderem às questões de pesquisa. Foram identificados 79
benefícios e 63 limitações, providos principalmente de estudos que abordaram
o uso do XP ou do Scrum.
Os estudos de caso foram conduzidos em empresas do Porto Digital de
Pernambuco, sendo selecionadas duas: a que possuía menor e a que possuía
maior tempo de uso de uma Metodologia Ágil. Foram investigados três
173
projetos, sendo realizadas 22 entrevistas. Foram identificados 45 benefícios e
25 limitações a partir dos estudos de caso.
174
5 CONSIDERAÇÕES FINAIS
5.1 Limitações e Ameaças à Validade

Apesar da preocupação em utilizar um quadro metodológico rigoroso nas
diversas etapas deste trabalho, o mesmo ainda possui algumas limitações que
são descritas a seguir.
Aplicação de Questionários (Survey)

Foram obtidas 44 respostas válidas para a pesquisa, representando uma
minoria da população. Esse problema já foi identificado por Easterbrook et al.
(2008) que afirmaram ser difícil obter altas taxas de respostas com aplicação
de questionários. No entanto, alguns dos resultados encontrados nesta etapa
mostram-se compatíveis com as pesquisas da VersionOne (2011) e de Melo e
Santos et al. (2012).
Revisão Sistemática da Literatura

Uma limitação comum em revisões sistemáticas e mapeamentos sistemáticos é
encontrar todos os artigos relevantes existentes. Neste trabalho, foi realizada a
busca automática em 08 engenhos de busca, número considerado suficiente
para garantir uma cobertura aceitável (KITCHENHAM, 2007). Para aumentar a
cobertura da revisão e reduzir a possibilidade de algum estudo potencialmente
relevante não ter sido retornado na condução da busca automática, foi
realizada a busca manual nos periódicos e nos anais dos principais periódicos
e conferências de Engenharia de Software e de Metodologias Ágeis.
A busca automática foi conduzida a partir de uma String de busca
formada por diversas palavras, o que pode ser possível, que alguma palavra
importante não ter sido incluída neste termo. No entanto, o termo escolhido foi
bem abrangente para evitar este problema.
Entre os critérios de inclusão dos estudos, o ano de publicação dos
estudos foi limitado até o ano de 2010. Isso ocorreu pelo fato da pesquisa ter
sido iniciada em 2011. Outro critério incluído foi selecionar apenas estudos
empíricos. No entanto, muitos estudos não definiam explicitamente que um
estudo era empírico, tendo dessa maneira, que a análise para esta definição foi
175
realizada pelos pesquisadores envolvidos, com base na definição dos métodos
de pesquisa utilizados.
Para evitar viés na seleção dos estudos, testes pilotos foram
conduzidos em cada etapa da pesquisa e estas foram conduzidas por mais de
um pesquisador. Quando houve divergências de opiniões entre os
pesquisadores, estas foram confrontadas e resolvidas com a participação de
terceiro pesquisador. A extração de dados foi a única etapa que foi conduzida
por um único pesquisador, e auxiliada pelos orientadores do trabalho. Essa
limitação é prevista por Kitchenham (2007) para alunos de PhD (nada foi dito
sobre alunos de mestrado). Segundo a autora, basta que o orientador da tese,
participe da revisão do protocolo e revise partes da execução da revisão, o que
ocorreu neste trabalho.
Estudos de caso
Apesar de alguns estudiosos afirmarem que estudos de caso com amostra
pequena da população não permitir a generalização dos resultados, essa
problemática foi debatida por Flyvbjerg (2006), apresentando diversos
argumentos contrariando essas afirmações.
Os objetivos dos estudos de caso e os critérios de seleção das
empresas foram bem definidos de modo que o resultado incluísse tipos de
empresas diferentes (tamanho da empresa, quantidade de projetos,
experiência com as Metodologias Ágeis e contexto dos projetos).
Para condução desta etapa, os entrevistados participaram
voluntariamente da pesquisa, sendo entregues termos de sigilosidade a cada
um, onde foi garantido o sigilo de suas informações, de modo a evitar que o
entrevistado sinta-se inibido em expressar seus pensamentos. A função
desempenhada por cada entrevistado foi bem diversificada, no entanto, ficou
faltando realizar entrevistas com os diretores das empresas e os clientes dos
projetos, de modo a obter resultados mais amplos.
Problemas na análise e interpretação dos dados podem ter ocorrido
devido ter sido realizada por um único pesquisador. No entanto, os resultados
são bastante consistentes com os resultados apresentado pela revisão
sistemática, e por outros estudos. Ainda, para evitar o viés do pesquisador na
análise e interpretação de cada uma das entrevistas, os resultados foram
176
encaminhados a cada entrevistado, para que o mesmo validasse ou corrigisse
as interpretações equivocadas.
5.2 Implicações para a pesquisa e prática

Os resultados apresentados por este trabalho possuem implicações tanto para
a pesquisa quanto para a prática.
Para a pesquisa, os resultados mostram o aumento na quantidade de
estudos publicados sobre as metodologias ágeis, sendo possível identificar
diversos benefícios que estas metodologias provêem, que em sua maioria
foram confirmados nos resultados obtidos com os estudos de caso. Diversas
limitações foram identificadas e a principal da SLR também foi identificada por
Dyba et al. (2008), onde percebe-se a necessidade de mais estudos empíricos
com as metodologias ágeis, principalmente com relação ao uso destas em
ambiente de desenvolvimento distribuído de software.
Os estudos identificados na revisão sistemática, em sua maioria
apresentaram resultados da aplicação de survey e estudos de caso. Isso
mostra que existem oportunidades para pesquisas com aplicação de outros
métodos científicos, como a pesquisa-ação e os experimentos, cujos quais
foram os menos identificados.
Com relação à qualidade dos estudos, observou-se que são poucos os
que justificaram a escolha do método de pesquisa utilizado e apresentaram
posicionamentos críticos com relação a sua própria pesquisa, explicando
possíveis vieses ou ameaças à validade.
Para os praticantes, os resultados podem ajudar a entender melhor o
uso das metodologias ágeis, permitindo saber os benefícios que podem ser
obtidos, bem como as limitações, ajudando assim, na seleção de cada
metodologia para ser utilizada nos projetos.
5.3 Lições aprendidas

A condução desta pesquisa possibilitou que algumas lições fossem aprendidas
pelos pesquisadores:
177
 Gerenciar o fluxo de dados obtidos e as atividades desenvolvidas pelo
grupo de pesquisadores foi fundamental para garantir o sucesso da
pesquisa;
 Dividir o trabalho em ciclos iterativos foi importante devido ao tamanho
da pesquisa;
 Utilizar uma única planilha para registrar as informações dos estudos
identificados na busca manual e automática da SLR e os resultados
identificados nas diversas etapas facilita a condução da revisão;
 É importante incluir nos critérios de inclusão da SLR que os estudos
devem apresentar informações que respondam à questão principal de
pesquisa (Q1), evitando em etapas posteriores o trabalho de analisar
estudos que poderiam ter sido excluídos anteriormente;
 Realizar testes pilotos em todas as etapas da SLR foi importante para
permitir um conhecimento padrão sobre a pesquisa e evitar possíveis
desacordos;
 É importante que a coleta de dados para os estudos de casos sejam
agendadas em locais adequados (sem interrupção).
5.4 Recomendações para Trabalhos Futuros

A partir da condução deste trabalho, são propostos direcionamentos para
novas pesquisas, que são descritas a seguir:
 Atualizar os dados da revisão sistemática com a inclusão dos anos
seguintes a que a pesquisa foi limitada (2010), procurando relacionar
os benefícios e as limitações aos contextos dos projetos;
 Ampliar a amostra dos estudos de caso para incluir empresas de
desenvolvimento de software de outros Estados brasileiros;
 Diversificar os papéis na amostra dos entrevistados, abrangendo
diretores das empresas e clientes, de modo entender se esses
papéis conseguem perceber os benefícios e limitações das
metodologias ágeis;
 Para a coleta de dados nos estudos de caso, além da condução de
entrevistas, pretende-se utilizar outras fontes de evidência, de modo
permitir uma triangulação dos dados como sugerido por Yin (2005).
178
5.5 Conclusões
As Metodologias Ágeis estão sendo bastante utilizadas no mercado de acordo
com as pesquisas apresentadas no trabalho e com base nos resultados
apresentados pela Revisão Sistemática da Literatura, que mostrou um aumento
de publicações relacionadas a estas metodologias nos últimos cinco anos.
O objetivo principal desta pesquisa foi identificar de maneira
sistemática na literatura e em estudos de caso, os benefícios e as limitações
das Metodologias Ágeis no desenvolvimento de software. Para tanto, foi
realizada uma revisão sistemática da literatura que retornou 6.856 estudos,
destes, 125 foram incluídos na pesquisa. Uma pesquisa de campo também foi
realizada, aplicando-se questionários com empresas de desenvolvimento de
software do Porto Digital de Pernambuco. Foram obtidas 44 respostas válidas e
com base nestas, foi identificado que 30 empresas utilizam uma metodologia
ágil, sendo o Scrum adotado por todas, individualmente ou com uma
abordagem híbrida com outra metodologia. Duas empresas foram selecionadas
e foram conduzidos 03 estudos de caso, sendo os dados coletados com base
na realização de 23 entrevistas.
Na literatura foram identificados 79 benefícios e 63 limitações, providos
principalmente de estudos que abordaram o uso do XP ou do Scrum. Nos
estudos de caso, todos os projetos investigados utilizavam o Scrum e algumas
práticas de XP, sendo identificados 52 benefícios e 40 limitações. Um
mapeamento entre os resultados destas duas etapas da pesquisa foi realizado,
mostrando que 45 benefícios e 25 limitações obtidos nas pesquisas são
correspondentes.
Os resultados da pesquisa mostram que as Metodologias Ágeis estão
em ascensão no mercado e estas têm provido diversos benefícios para os
projetos, sendo os principais, a facilidade de compartilhamento do
conhecimento entre a equipe e a facilidade de acompanhamento e
monitoramento dos projetos. No entanto, diversas limitações também foram
identificadas, sendo a principal, a falta de estudos empíricos que apresentem
resultados sobre as mesmas e a dificuldade de utilizar estas metodologias em
equipes grandes.
179
REFERÊNCIAS
ABRAHAMSSON, P. et al. Agile software development methods - Review and

analysis. VTT Publications. Oulu, Finland. 2002. (478).
AGILE MANIFESTO. Manifesto for Agile Software Development, 17 February

2001. Disponivel em: <http://www.agilemanifesto.org/>. Acesso em: 10 maio
2012.
AMBLER, S. Agile Adoption Rate Survey Results: March 2006. AmbySoft,

2006. Disponivel em:
<http://www.ambysoft.com/surveys/agileMarch2006.html>. Acesso em: 10 julho
2012.
AMBLER, S. Agile Adoption Rate Survey Results: March 2007. AmbySoft,

<http://www.ambysoft.com/surveys/agileMarch2007.html>. Acesso em: 10 jul.
2012.
AMBLER, S. Agile Adoption Rate Survey Results: February 2008. AmbySoft,

<http://www.ambysoft.com/surveys/agileFebruary2008.html>. Acesso em: 12
jul. 2012.
ANPROTEC. Vencedores 2011 - Prêmio Nacional de Empreendedorismo

Inovador. Anprotec, 26 out. 2011. Disponivel em:
<http://www.anprotec.org.br/publicacaopremio.php?idpublicacao=41>. Acesso
em: 09 ago. 2012.
BECK, K. Extreme Programming Explained: Embrace Change. [S.l.]: Addison-

Wesley, 1999.
BECK, K. Extreme Programming Explained: Embrace Chage. 2. ed. [S.l.]:

Addison-Wesley, 2004.
BEGEL, A.; NAGAPPAN, N. Usage and Perceptions of Agile Software

Development in an Industrial Context: An Exploratory Study. ACM-IEEE
International Symposium on Empirical Software Engineering and Measurement
(ESEM). [S.l.]: [s.n.]. 2007. p. 255-264.
BELBIN, M. Management Teams: Why they succeed or Fail. [S.l.]: Butterworth-

Heinemann Ltd, 1981.
BOEHM, B. A View of 20th and 21st Century Software Engineering. 28th

International Conference on Software Engineering, ICSE’06. New York, NY:
[s.n.]. 2006. p. 12-29.
180
CARDOZO, E. S. D. F. Mapeamento Sistemático sobre o uso do
Autogerenciamento em Equipes de Desenvolvimento de Software. Dissertação
de Mestrado. Universidade Federal de Pernambuco. Recife, PE, Brasil. 2012.
CHOW, T.; CAO, D.-B. A survey study of critical success factors in agile
software projects. The Journal of Systems and Software, New York, NY, USA,
v. 81, n. 6, p. 961–971, June 2008.
COCKBURN, A. Crystal Clear: A Human-Powered Methodology for Small

Teams. [S.l.]: Addison-Wesley Professional, 2004. ISBN 0-201-69947-8.
COOPER, H. M. Organizing knowledge syntheses: A taxonomy of literature

reviews. Knowledge, Technology & Policy, 1, n. 1, 1988. 104-126.
DIGITAL FOCUS. Agile 2006 Survey: Results and Analysis, 2006. Digital Focus
was bought by Command Information.
DYBÅ, T.; DINGSøYR, T. Empirical studies of agile software development: A

systematic review. Information and Software Technology, Butterworth-
Heinemann Newton, MA, USA, v. 50, n. 9, p. 833-859, August 2008.
DYBÅ, T.; DINGSøYR, T. Strength of Evidence in Systematic Reviews in

Software Engineering. ACM-IEEE International Symposium on Empirical
Software Engineering and Measurement (ESEM). Kaiserslautern, Germany:
[s.n.]. 2008b. p. 178-187.
EASTERBROOK, S. et al. Selecting Empirical Methods for Software

Engineering Research. In: SHULL, F.; SINGER, J.; SJøBERG, D. I. K. Guide to
advanced empirical software engineering. [S.l.]: Springer-Verlag London, 2008.
p. 285-311.
FERREIRA, C.; COHEN, J. Agile systems development and stakeholder

satisfaction: a South African empirical study. South African Institute of
Computer Scientists e Information Technologists on IT. SAUCSIT. [S.l.]: [s.n.].
2008. p. 48-55.
FLICK, U. Introdução à pesquisa qualitativa. Tradução de Joice Elias Costa.

Porto Alegre: Artmed, 2009.
FLYVBJERG, B. Five Misunderstandings About Case-Study Research. In:

DENZIN, N. K.; LINCOLN, Y. S. Qualitative Inquiry. 2. ed. [S.l.]: The Sage
Handbook of Qualitative Research, v. 12, 2006. p. 219-245.
FOWLER, M. The New Methodology. Martin Fowler, 2005. Disponivel em:

<www.martinfowler.com/articles/newMethodology.html>. Acesso em: 21 jul.
2012.
181
GLASER, B. G.; STRAUSS, A. L. The Discovery of Grounded Theory:
Strategies for Qualitative Research. Chicago: Aldine Transaction, 1967.
GRAY, D. E. Pesquisa no mundo real. Tradução de Roberto Cataldo Costa. 2a.

ed. Porto Alegre: Penso, 2012.
GROUP, G. W. Grading Quality of Evidence and Strength of

Recommendations. BMJ Publishing Group. London. 2004. (328:1490).
HIGGINS, J. P. T.; GREEN, S. Cochrane Handbook for Systematic Reviews of

Interventions. The Cochrane Collaboration, 2008. Disponivel em:
<www.cochrane-handbook.org>. Acesso em: 2011 abr. 01.
HIGHSMITH, J. A. Adaptive software development: a collaborative approach to

managing complex systems. New York, NY, USA: Dorset House Publishing
Co., Inc., 2000.
HO, C.-W. et al. On Agile Performance Requirements Specification and Testing.

Agile 2006. Washington, USA: IEEE Computer Society. 2006. p. 47-52.
JUSTUS, J. R. A Guide to Writing the Dissertation Literature Review. Practical

Assessment, Research & Evaluation, v. 14, n. 13, June 2009.
KITCHENHAM, B. Guidelines for performing Systematic Literature Reviews in

Software Engineering. Software Engineering Group, School of Computer
Sciences and Mathematics, Keele University, and Department of Computer
Science, University of Durham. [S.l.]. 2007.
KNIBERG, H. Scrum and XP from the Trenches. [S.l.]: C4Media, InfoQ.com,

2007.
LAANTI, M.; SALO, O.; ABRAHAMSSON, P. Agile methods rapidly replacing

traditional methods at Nokia: A survey of opinions on agile transformation.
Information and Software Technology, v. 53, n. 3, p. 276–290, 2011.
LANDIS, J. R.; KOCH, G. G. The measurement of observer agreement for

categorical data. Biometrics, v. 33, n. 1, p. 159-174, March 1977.
LUTTERS, W. G.; SEAMAN, C. B. The Value of War Stories in Debunking the

Myths of Documentation in Software Maintenance. Information and Software
Technology, v. 49, n. 6, p. 576–587, January 2007.
MARCONI, M. A.; LAKATOS, E. M. Metodologia Científica. 6a. ed. São Paulo:

Atlas, 2008.
MELO, C. D. O. et al. Métodos ágeis no Brasil: estado da prática em times e

organizações. IME-‐USP. [S.l.]. 2012.
MENAND, L. Pragmatism: A Reader. New York: Vintage, 1997.
182
MONTEIRO, C. V. F. Impacto do uso de ferramentas de software nas fases
iniciais do processo de inovação. Dissertação de Mestrado. Universidade
Federal de Pernambuco. Recife, PE, Brasil. 2010.
NOBLIT, G. W.; HARE, R. D. Meta-Ethnography: Synthesizing Qualitative

Studies. Newbury Park, CA: Sage Publications, 1988.
PALMER, S. R.; FELSING, J. M. A Practical Guide to Feature-driven

Development. Upper Saddle River: Prentice Hall, 2002. ISBN 0-13-067615-2.
PETERSEN, K.; WOHLIN, C. A Comparison of Issues and Advantages in Agile

and Incremental Development Between State of the Art and an Industrial Case.
Journal of Systems and Software, v. 82, n. 9, p. 1479-1490, 2009.
PETTICREW, M.; ROBERTS, H. Systematic Reviews in the Social Sciences: a

practical guide. Oxford: Blackwell Publishing, 2006.
POPPENDIECK, M.; POPPENDIECK, T. Lean Software Development – An

Agile Toolkit. Boston, MA, USA: Addison-Wesley Professional, 2003. ISBN 0-
321-15078-3.
RACHEVA, Z.; DANEVA, M.; HERRMANN, A. A Conceptual Model of Client-

driven Agile Requirements Prioritization: Results of a Case Study. International
Symposion on Empirical Software Engineering and Measurement (ESEM '10).
New York, NY, USA: ACM. 2010. p. 15-17.
SCHWABER, K. SCRUM Development Process. OOPSLA'95 Workshop on

Business Object Design and Implementation. Austin, Texas, USA: Springer-
Verlag. 1995.
SCHWABER, K. Agile Project Management with Scrum. [S.l.]: Microsof Press,

2004.
SCHWABER, K.; BEEDLE, M. Agile Software Development with Scrum. 1. ed.

[S.l.]: Prentice Hall, 2001.
SEAMAN, C. B. Qualitative methods in empirical studies of Software

Engineering. IEEE Transactions on Software Engineering, v. 25, n. 4, p. 557–
572, 1999.
SEAMAN, C. B. Qualitative Methods. In: SHULL, F.; SINGER, J.; SJøBERG, D.

I. K. Guide to Advanced Empirical Software Engineering. [S.l.]: Springer-Verlag
London, 2008. Cap. 2, p. 35-62.
SHINE TECHNOLOGIES. Agile Methodologies - Survey Results. Shine

Technologies, 2003. Disponivel em:
<http://www.shinetech.com/attachments/104_ShineTechAgileSurvey2003-01-
17.pdf>. Acesso em: 17 jul. 2012.
183
SHORE, J.; WARDEN, S. The Art of Agile Development. Sebastopol, CA:
O’Reilly Media, 2007.
SOMMERVILLE, I. Engenharia de Software. Tradução de Ivan Bosnic e Kalinka

G. de O. Gonçalves. 9a. ed. São Paulo: Pearson Addison-Wesley, 2011.
Revisão técnica: Hirama, K.
STAPLETON, J. DSDM: Business Focused Development. 2. ed. [S.l.]: Pearson

Education, 2003. ISBN 978-0321112248.
STRAUSS, A.; CORBIN, J. Pesquisa qualitativa: técnicas e procedimentos para

o desenvolvimento de teoria fundamentada. Tradução de Luciane de Oliveira
da Rocha. 2a. ed. Porto Alegre: Artmed, 2008.
STRODE, D. E.; HUFF, S. L.; TRETIAKOV, A. The Impact of Organizational

Culture on Agile Method Use. 42nd Hawaii international Conference on System
Sciences, HICSS’09. Washington, DC: IEEE Computer Society. 2009. p. 1-9.
TAKEUCHI, H.; NONAKA, I. The New Product Development Game. Harvard

Business Review, v. 64(1), p. 137-146, February 1986.
TEIXEIRA, V. S.; DELAMARO, M. E. Geração de metadados para o apoio ao

teste estrutural de componentes. VII Simpósio Brasileiro de Qualidade de
Software. Florianópolis, SC, Brasil: [s.n.]. 2008. p. 406-419.
TELES, V. M. Um Estudo de Caso da Adoção das Práticas e Valores do

Extreme Programming. Universidade Federal do Rio de Janeiro. Rio de
Janeiro, RJ, Brasil. 2005.
VERSIONONE. Survey: "The State of Agile Development". The State

of Agile Development Survey Results, 2007a. Disponivel em:
<http://www.versionone.com/pdf/StateofAgileDevelopmentSurvey.pdf>. Acesso
em: 10 jul. 2012.
VERSIONONE. 2nd Annual Survey: "The State of Agile Development". The

State of Agile Development Survey Results, 2007b. Disponivel em:
<http://www.versionone.com/pdf/StateOfAgileDevelopmet2_FullDataReport.pdf
>. Acesso em: 10 jul. 2012.
VERSIONONE. 3rd Annual Survey: "The State of Agile Development". The

State of Agile Development Survey Results, 2008. Disponivel em:
<http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf>.
Acesso em: 10 jul. 2012.
VERSIONONE. 4th Annual State of Agile Development Survey Results. The

<http://www.versionone.com/state_of_agile_development_survey/09/>. Acesso
em: 10 jul. 2012.
184
VERSIONONE. 5th Annual Survey: "The State of Agile Development". The
em: 10 jul. 2012.
VERSIONONE. 6th Annual State of Agile Development Survey Results. The

em: 10 jul. 2012.
VIJAYASARATHY, L. R.; TURK, D. Agile Software Development: a survey of

early adopters. Journal of Information Technology Management, v. XIX, n. 2,
2008. ISSN 1042-1319.
YIN, R. K. Applications of Case Study Research. Newbury Park, CA.: Sage,

1993.
YIN, R. K. Estudo de caso: planejamento e métodos. Tradução de Daniel

Grassi. 3a. ed. Porto Alegre: Bookman, 2005.
185
APÊNDICE A – Questionário para mapeamento
das empresas do Porto Digital
Sobre o questionário
Esta pesquisa é direcionada as empresas de desenvolvimento de software
associadas ao Porto Digital de Pernambuco, cujo objetivo é identificar as
empresas que utilizam as Metodologias Ágeis no desenvolvimento de seus
projetos.
Quanto à finalidade
Esta pesquisa tem caráter acadêmico, onde os dados das empresas e dos
respondentes serão utilizados para dissertação de mestrado.
Sigilo das informações

As informações pessoais dos respondentes e das empresas serão sigilosas, e
não serão divulgadas sem a prévia autorização dos envolvidos.
Envolvidos na pesquisa
Aluno do mestrado: Fernando Kenji Kamei.
Prof. Orientador: Alexandre Marcos Lins de Vasconcelos.
Prof. Coorientador: Fabio Queda Bueno da Silva
Informações de contato
Nome da Empresa:
Nome completo do respondente:
E-mail para contato:
186
Função ocupada na empresa
Questionário
1. A empresa trabalha com desenvolvimento de software?
2. Utilizam ou utilizaram alguma metodologia ágil no desenvolvimento de

software?
3. Se a empresa não utiliza nenhuma metodologia ágil responda:
4. Quais são as metodologias ágeis utilizadas pela empresa?

eXtreme Programming (XP)
Scrum
Feature Driven Development (FDD)
DSDM
Crystal (Clear, Orange, Blue)
Adaptive Software Development
Outras
187
5. Quais são as práticas das metodologias ágeis utilizadas na empresa?
Cliente sempre presente
Código Coletivo
Comunicação face a face
Desenvolvimento Iterativo e Incremental
Design Simples (Simple Design)
Equipes Auto-gerenciáveis
Integração Contínua (Continuous Integration)
Metáforas
Programação em Par (Pair Programming)
Planning Poker
Reuniões diárias
Desenvolvimento Orientado a Testes (TDD)
Reuniões da Sprint (Planning, Review, Retrospective)
Outras
6. Há quanto tempo a empresa tem utilizado metodologias ágeis?
7. Qual a quantidade de projetos que a organização possui em

desenvolvimento?
188
8. Qual a quantidade de projetos que utilizam atualmente metodologias
ágeis?
9. Quantos projetos foram finalizados utilizando alguma metodologia ágil?
10. Qual a quantidade média de pessoas por projeto?
189
APÊNDICE B – Protocolo da Revisão Sistemática
da Literatura
Este apêndice contém o protocolo da Revisão Sistemática conduzida neste

trabalho, que foi desenvolvido por uma equipe de oito pessoas: dois alunos do
doutorado, Fernando Selleri Silva, Kellyton dos Santos Brito; quatro alunos do
mestrado, Dhiego Abrantes de Oliveira Martins, Fernanda Nóbrega de
Medeiros Martins, Fernando Kenji Kamei, Ivanildo Monteiro de Azevedo; e
pelos professores Fábio Queda Bueno da Silva, e Alexandre Marcos Lins de
Vasconcelos.
A elaboração da versão final foi elaborada pelo aluno do mestrado Fernando

Kenji Kamei, sob a orientação dos professores Fabio Queda Bueno da Silva e
Alexandre Marcos Lins de Vasconcelos.
Pelo motivo desta revisão ser uma extensão de um trabalho escrito em inglês,
este protocolo e a condução da pesquisa foi conduzida nessa mesma língua,
com intuito de manter a similaridade entre os trabalhos.
190
FEDERAL UNIVERSITY OF PERNAMBUCO
COMPUTER SCIENCE GRADUATE PROGRAM
CENTER OF INFORMATICS
PROTOCOL OF SYSTEMATIC LITERATURE REVIEW
Empirical studies of agile software development:

A systematic review extension
Dhiego Abrantes de Oliveira Martins

Fernanda Nóbrega de Medeiros Martins
Fernando Kenji Kamei
Fernando Selleri Silva
Ivanildo Monteiro de Azevedo
Kellyton dos Santos Brito
April 2011
Recife - PE
191
TEAM
Name Affiliation Role

Dhiego Abrantes de Oliveira CIn – Universidade
Author
Martins Federal de Pernambuco
Fernanda Nóbrega de Medeiros CIn – Universidade
Author
Martins Federal de Pernambuco
CIn – Universidade
Fernando Kenji Kamei Author
Federal de Pernambuco
Fernando Selleri Silva Author
Ivanildo Monteiro de Azevedo Author
Kellyton dos Santos Brito Author
Alexandre Marcos Lins de CIn – Universidade Co-author e
Vasconcelos Federal de Pernambuco Reviser
CIn – Universidade Co-author e
Fábio Queda Bueno da Silva
Federal de Pernambuco Reviser
192
1. Introduction
1.1 Context
Due to the fast growth of the global software industry, coupled with an
increasing demand for more robust solutions and also with changing
requirements, the quest for excellence and continuous improvement of software
quality has been improved over time (CHOW and CHAO, 2008).
Several methods, techniques and tools have been proposed and used,
aiming to increase the productivity in software development (TEIXEIRA and
DELAMARO, 2008). The search for better processes aiming to increase
software quality and customer satisfaction has brought about the Agile
Methodologies, with the dynamics of flexible and adaptive processes, adopting
changes as an inseparable part of their process.
According to Ferreira and Cohen (2008), the Agile Methodologies have
great support in the literature arguing that these methodologies reduce the
failure rate in software development. However, Strode et al. (2009) argue that a
rigorous empirical research study with agile methods is important in order to
assess their effectiveness.
1.2 Problem
Recently, many of the suggestions for improvement have come from
experienced practitioners who have labeled their methods agile software
development. This movement has had a huge impact on how software is
developed worldwide. However, although there are many agile methodologies,
little is known about how these methods are carried out in practice and what
their effects are (DYBÅ AND DINGSØYR, 2008).
1.3 Goals
This systematic review seeks to evaluate, synthesize and present the empirical
findings on agile software development between (and included) 2006 and 2010,
because this review is an extension of Dybå and Dingsøyr’s (2008) review,
performed until 2005. Then, provide an overview of topics researched, their
findings, strength of the findings and implications for research and practice.
193
2. Protocol
According to Kitchenham et al. (2007), a definition of protocol is important and
necessary in order to reduce the possible biases in research, because the
protocol specifies the methods that will be used to guide the systematic review.
This protocol must include all elements of review and some additional
information on planning. These elements are presented in the following
sections.
Differently from Dybå and Dingsøyr (2008), who developed the protocol
following the guideline named Cochrane Handbook for Systematic Reviews of
Interventions (HIGGINS and GREEN, 2008), our protocol was developed
following the guidelines and procedures suggested by Kitchenham et al. (2007)
because these are widely used in Software Engineering.
2.1 Background
2.1.1 Systematic Literature Review
A systematic literature review (often referred to as a systematic review) is a
means of identifying, evaluating and interpreting all available research relevant
to a particular research question, topic area or phenomenon of interest.
Individual studies contributing to a systematic review are called primary studies;
a systematic review is a form of secondary study (KITCHENHAM et al., 2007).
According to Biolchini et al. (2005), a Systematic Review should be developed
formally and systematically.
2.1.2 Research Questions

This systematic review aims to answer 03 research questions, the same
questions used by Dybå and Dingsøyr (2008), as following:
 RQ1: What is currently known about the benefits and limitations of
agile software development?
 RQ2: What is the strength of the evidence in support of the claims
regarding agile software development?
194
 RQ3: What are the implications of these studies for the software
industry and the research community?
The RQ1 is the main question of this research, thus the others are
secondary, because they only answered for the studies that showed responses
for the first question.
2.1.3 Search Strategy

According to Kitchenham (2007), a strategy should be used for the search of
primary studies, with the definition of key words, digital libraries, journals and
conferences. The strategy used in this research is presented in the following
sections.
This review will be developed in stages and search strategies distinct of
which was followed by Dybå and Dingsøyr (2008). Our strategies are presented
below.
2.1.4 Search Terms

Dybå and Dingsøyr (2008) included electronic database and conference
proceedings to finding the articles using the follow search terms: (1) agile AND
software; (2) extreme programming; (3) xp AND software; (4) scrum AND
software; (5) crystal AND software AND (clear OR orange OR red OR blue); (6)
dsdm AND software; (7) fdd AND software; (8) feature AND driven AND
development AND software; (9) lean AND software AND development.
However, in our extension review we decided to include some
synonyms or related words for these terms and to eliminate some repetitions
such as software, but maintaining a certain correspondence with the terms
defined in the previous review. Our related words were obtained from previews
studies in the area.
According to Dybå and Dingsøyr (2008), the search terms were derived
from keywords of RQ1 and are as comprehensive as possible to be able
included the most studies and only during the reading to identify the possible
benefits and limitations.
The keywords and their synonym or related words that correspond to
195
search terms are presented in Table 1.
Table 1 – Keywords
Keyword Synonym or Related Words
agility, scrum, extreme programming, XP, dynamic system

development, DSDM, crystal clear, crystal orange, crystal
agile red, crystal blue, feature driven development, FDD, lean
software development, adaptive software development,
ASD, test driven development, TDD
software development, software engineering, information

software development system development, information system engineering,
software production
Search String:
The strategy used to construct the search string was:

1. Derive keywords from the research questions;
2. Identify synonyms or related words for the search terms;
3. Group synonymous and related words with the identifier "OR";
4. Group each set of terms with the identifier "AND";
Steps 1 and 2 were executed as described in Table 1. After steps 3 and

4, it becomes the following result for the search string:
("agile" OR "agility" OR "scrum" OR "extreme programming" OR "XP" OR

"dynamic system development" OR "DSDM" OR "crystal clear" OR
"crystal orange" OR "crystal red" OR "crystal blue" OR "feature driven
development" OR "FDD" OR "lean software development" OR "adaptive
software development" OR "ASD" OR "test driven development" OR
"TDD") AND ("software development" OR "software engineering" OR
"information system development" OR "information system engineering"
OR "software production")
Note: It is important to observe that we conducted a test with our
196
search string and it was verified that all studies included by Dybå and Dingsøyr
(2008) were listed in our automatic search in electronic databases.
2.1.5 Data Sources

The search strategy included electronic databases and manual search of
conference proceedings. We maintained the electronic databases used by Dybå
and Dingsøyr (2008) with minor changes: Kluwer Online was integrated in
SpringerLink database and we included Scopus, which is one of most traditional
scientific databases nowadays and integrates several other databases. So, the
following electronic databases will be searched:
Table 2 – Eletronic databases

Eletronic databases Website
1 ACM Digital Library http://portal.acm.org/dl.cfm
2 El Compendex http://www.engineeringvillage.com
3 IEEE Xplore http://ieeexplore.ieee.org/
4 ISI Web of Science http://apps.isiknowledge.com/
5 ScienceDirect – Elsevier http://www.sciencedirect.com/
6 Scopus http://www.scopus.com/
7 SpringerLink http://www.springerlink.com/
8 Wiley Inter Science Journal http://onlinelibrary.wiley.com/
Finder
In addition, we selected some conferences and journals to perform

manual search. Initially, we maintained the conference proceedings listed by
Dybå and Dingsøyr (2008). The International Symposium on Empirical Software
Engineering (ISESE) was referenced, but it joined the International Symposium
on Empirical Software Engineering and Measurement (ESEM) from 2007, and
ESEM will be used instead of ISESE. The Agile Universe Conference was
joined the XP Conference.
Nevertheless, that study did not included scientific journals, so we
added some important journals of software engineering. For that, we performed
a search by category “Computer Science, Software Engineering” in the Journal
197
Citation Reports website5, sorted by “5-year Impact Factor” criteria and got the
five best ranked, after eliminating the ones that clearly are not about software
development, such as ACM Transactions on Graphics (the best ranked) and
IEEE Transactions on Dependable and Secure Computing. In addition, we
included the Empirical Software Engineering Journal, which is the best-ranked
journal focused on empirical data, and the Agile Journal, which according to
Racheva (2009) is the most popular practitioner-centric online publication venue
of the agile community, but during the analyzing this source, it was found that
your context don’t have scientific rigor to publication the articles.
Thus, the list of conference proceedings and journals that we have
hand searched is:
 Conferences:
- Agile Development Conference;
- XP Conference;
 Journals:
- ACM Transactions on Software Engineering and Methodology;
- Empirical Software Engineering;
- IEEE Software;
- IEEE Transactions on Software Engineering;
- Journal of the ACM;
2.1.6 Study Selection Criteria

The studies of this review were selected according to the inclusion and
exclusion criteria, as following in this section.
2.1.6.1 Criteria of Inclusion

1. Only primary studies;
2. Studies that present empirical data;
3. Academic and industry studies are include;
4. Only studies that presented empirical data on agile software development;
5
http://admin-apps.isiknowledge.com/JCR/JCR?RQ=HOME
198
5. Qualitative and quantitative research studies;
6. Studies that present data in scientific format;
7. Only studies written in English;
8. Studies published between (and included) 2006 and 2010;
9. Full papers, published in a peer-reviewed journal or conference.
2.1.6.2 Criteria of Exclusion

1. Studies whose focus was not agile software development;
2. Studies that did not present empirical data;
3. Studies that focused on single techniques or practices, such as pair
programming, unit testing or refactoring;
4. Studies with just lessons learned (papers without a research question and
research design);
5. Papers merely based on expert opinion;
6. Editorials, prefaces, article summaries, interviews, news, reviews,
correspondence, discussions, comments, reader’s letters and summaries of
tutorials, workshops, panels, and poster sessions;
7. Academic studies that focus on teaching agile methods;
8. Studies that did not answer our first research questions;
9. Duplicated study report, with no extra information.
The empirical studies will be considered according to Easterbrook et al.

(2008), which presented the main methods applicable and most relevant to
empirical software engineering: controlled experiments (including quasi-
experiments), case studies (both exploratory and confirmatory), survey
research, ethnographies, and action research.
The second criteria of exclusion was listed because, according to
Williams et al., (2010) some agile practices are often associated with agile
software development, although these practices could be used by plan driven
teams.
199
2.1.7 Study Selection Procedures
The selection of studies was conducted according to four stages, always
conducted by a pair of researchers to identify potential primary studies. Each
stage was explained as following and is presented in
Figure 1 – Stages of the study selection process
Stage 1: Each pair of researchers will be responsible for conducting the

manual and automatic search, in order to identify potential primary studies.
200
Duplicated studies will be discarded. All studies identified at this stage should
be named by a unique ID and stored in a web repository shared with all
researchers.
Stage 2: Each selected study in prior stage should be analyzed by a
pair of researchers, based on analysis of the title and abstract, discarding
studies that are clearly irrelevant for the search. When the researchers were in
doubt whether to include a study or not, it should be included for consideration
at a later stage.
Stage 3: Once the studies are selected in the prior stage, they will be
reviewed by a pair of researchers, applying the inclusion and exclusion criteria
presented in Section 2.1.6. In case of disagreement over the inclusion /
exclusion of a certain paper, we stress again to discuss if the study should be
included or not. However, if they do not come to an agreement, the opinion of a
third researcher should be considered.
Stage 4: Thus, a list of primary papers was obtained for critical
appraise according to criteria defined in Section 2.1.8.
Stage 5: The data obtained from the studies were extracted to answer
the RQ1 and were synthesized.
2.1.8 Quality Assessment

The analysis of quality in our extension removed only the first question of quality
assessment established by Dybå and Dingsøyr (2008), because this question is
guaranteed in the criteria of inclusion, when all studies to be included must
present empirical data. These criteria are listed below:
1. Is there a clear statement of the aims of the research?
2. Is there an adequate description of the context in which the research
was carried out?
3. Was the research design appropriate to address the aims of the
research?
4. Was the recruitment strategy appropriate to the aims of the research?
5. Was there a control group with which to compare treatments?
6. Was the data collected in a way that addressed the research issue?
7. Was the data analysis sufficiently rigorous?
201
8. Has the relationship between researcher and participants been
considered to an adequate degree?
9. Is there a clear statement of findings?
10. Is the study of value for research or practice?
According to Dybå and Dingsøyr (2008), these criteria include three

important issues that are related with the quality and they were considered for
our extension. They are:
 Rigor: Has a thorough and appropriate approach been applied to key
research methods in the study?
 Credibility: Are the findings well-presented and meaningful?
 Relevance: How useful are the findings to the software industry and
the research community?
From the assessment, each of the 11 criteria was graded on a

dichotomous (‘‘yes” or ‘‘no”) scale and received a score according to Table 3.
Table 3 – Score of quality assessment

Value Score
Yes 1
No 0
The studies are divided into 03 groups; each group is composed by two
reviewers. Each reviewer should evaluate the quality of each study. In case of
disagreement regarding the assessment, a third reviewer will be convoked to
solve the conflict. The Quality Assessment Form would be used by each
researcher to evaluate the quality of each study.
The studies evaluated will be classified into 04 ranges of quality: low,
medium, high and very high. The table has been made as the score distribution
between the established ranges.
Table 4 – Distribution of scores for Quality Range

Low Medium High Very high
0≤N≤2 3≤N≤5 6≤N≤8 9 ≤ N ≤ 10
202
During the quality assessment, some studies may be excluded in two
situations: (1) only this decision was approved by two reviewers. Or in case of
disagreement, a third reviewer will be convoked to solve the conflict; (2) studies
in which the quality assessment score is classified in the low range.
The use of criteria exclusion according to quality assessment of study is
commented by Kitchenham (2007), where the quality data can be used to
construct detailed inclusion/exclusion criteria.
Quality Assessment Form
FORM TO QUALITY ASSESSMENT
ID: Researcher: Date of Assessment:
Screening questions
1. Is there a clear statement of the aims of the research?
Consider:
– Is there a rationale for why the study was undertaken?
–Is the study’s focus or main focus on Agile Software
Yes No
Development?
–Does the study present empirical data?
–Is there a clear statement of the study’s primary outcome (i.e.
time-to-market, cost, or product or process quality)?
2. Is there an adequate description of the context in which
the research was carried out?
Consider whether the researcher has identified:
–The industry in which products are used (e.g. banking,
telecommunications, consumer goods, travel, etc)
–The nature of the software development organization (e.g. in-
house department or independent software supplier)
Yes No
–The skills and experience of software staff (e.g. with a
language, a method, a tool, an application domain)
–The type of software products used (e.g. a design tool, a
compiler)
–The software processes being used (e.g. a company standard
process, the quality assurance procedures, the configuration
management process)
203
Research design
3. Was the research design appropriate to address the aims
of the research?
Yes No
Consider:
– Has the researcher justified the research design (e.g. have
they discussed how they decided which methods to use)?
Sampling
4. Was the recruitment strategy appropriate to the aims of the
research?
Consider:
–Has the researcher explained how the participants or cases
were identified and selected?
Yes No
–Are the cases defined and described precisely?
– Were the cases representative of a defined population?
–Have the researchers explained why the participants or cases
they selected were the most appropriate to provide access to
the type of knowledge sought by the study?
–Was the sample size sufficiently large?
Control group
5. Was there a control group with which to compare
treatments?
Consider:
–How were the controls selected? Yes No
–Were they representative of a defined population?
–Was there anything special about the controls?
–Was the no n-response high? Could non-respondents be
different in any way?
Data collection
6. Was the data collected in a way that addressed the
research issue?
Consider:
–Were all measures clearly defined (e.g. unit and counting Yes No
rules)?
–Is it clear how data was collected (e.g. semi-structured
interviews, focus group etc.)?
–Has the researcher justified the methods that were chosen?
204
–Has the researcher made the methods explicit (e.g. is there
an indication of how interviews were conducted, did they use
an interview guide)?
–If the methods were modified during the study, has the
researcher explained how and why?
–Whether the form of the data is clear (e.g. tape recording,
video material, notes etc.)
–Whether quality control methods were used to ensure
completeness and accuracy of data collection
Data analysis
7. Was the data analysis sufficiently rigorous?
Consider:
–Was there an in-depth description of the analysis process?
–If thematic analysis was used, is it clear how the categories/
themes were derived from the data? Yes No
–Has sufficient data been presented to support the findings?
–To what extent has contradictory data been taken into
account?
–Whether quality control methods were used to verify the
results
Reflexivity (research partnership relations/recognition of

researcher bias)
8. Has the relationship between researcher and participants
been considered adequately?
Consider:
–Did the researcher critically examine their own role, potential
Yes No
bias and influence during the formulation of research
questions, sample recruitment, data collection, and analysis
and selection of data for presentation?
–How the researcher responded to events during the study and
whether they considered the implications of any changes in the
research design.
205
Findings
9. Is there a clear statement of findings?
Consider:
–Are the findings explicit (e.g. magnitude of effect)?
–Has an adequate discussion of the evidence, both for and
against the researcher’s arguments, been demonstrated?
–Has the researcher discussed the credibility of their findings Yes No
(e.g. triangulation, respondent validation, more than one
analyst)?
–Are limitations of the study discussed explicitly?
–Are the findings discussed in relation to the original research
questions?
–Are the conclusions justified by the results?
Value of the research
10. Is the study of value for research or practice?
Consider:
–Does the researcher discuss the contribution the study makes
to existing knowledge or understanding (e.g. do they consider
the findings in relation to current practice or relevant research-
Yes No
based literature)?
–Does the research identify new areas in which research is
necessary?
–Does the researcher discuss whether or how the findings can
be transferred to other populations, or consider other ways in
which the research can be used?
2.1.9 Data Extraction and Analysis

According to Kitchenham (2007) the objective of this stage is to design data
extraction forms to accurately record the information researchers obtain from
the primary studies. The data extraction forms must be designed to collect all
the information needed to address the review questions.
Data extraction will be performed by a single researcher and reviewed by
one of the advisors’ research. The strategy used in extracting data consists in
using spreadsheets of Microsoft Excel™, where all relevant information about
each study which will be useful at the moment of extraction and synthesis will
206
be recorded in two forms to collect the data: Studies description (Section 0) and
Findings of the studies (Section 0).
The method of extraction and synthesis will occur in parallel. The data
will be collected from open and axial coding were performed in parallel as data
were gathered, analyzed, and reanalyzed in light of the emerging theory or
concepts to answer our main research question (RQ1).
Data analysis will be guided the Grounded Theory (GT) method
according to Glaser and Strauss (1967). GT is exploratory and well suited for
situations where the researcher does not have pre-conceived ideas, and
instead is driven by the desire to capture all facets of the collected data and to
allow the theory to emerge from the data, using constant comparison from the
data already collected from previously studies (RACHEVA et al. 2010).
Note: the studies that do not present data to answer our main research
question (RQ1) will be deleted.
Data Extraction Form (Studies Description)
EXTRACTION FORM (STUDIES DESCRIPTION)
Items
1 Study identifier Unique id for the study
2 Date of data extraction
3 Bibliographic reference Title, year, author biography, source
4 Type of article Journal article, conference paper, book section
5 Study aims What were the aims of the study?
Qualitative, quantitative (experiment, survey,
6 Design of study case study, action research)
7 Agile method What kind of Agile Method is used in the study?
8 Agile practices
Size, students, professionals (age, education,
9 Sample description experience)
Industry, in-house/supplier, products and
10 Setting of study processes used
11 Control group Yes, no (number of groups, sample size)
207
How was the data obtained? (questionnaires,
12 Data collection interviews, forms)
How was the data analyzed? (qualitative,
13 Data analysis quantitative)
14 Findings and Conclusions What were the findings and conclusions?
Data Extraction Form (Findings of the studies)
EXTRACTION FORM (FINDINGS OF THE STUDIES)
Items
1 Study identifier Unique id for the study
2 Benefits Unique id for each benefits for each study
Role of person in the project that related the
3 Vision benefit
4 Agile Method Agile method in which the benefit was found
5 Agile practice Agile practice in which the benefit was found
6 Category of benefit Category of benefit reported
7 Subcategory of benefit Subcategory of benefit reported
8 Annotations General annotations about the benefit
9 Limitations Unique id for each limitation for each study
Role of person in the project that related the
10 Vision limitation
11 Agile Method Agile method in which the limitation was found
12 Agile practice Agile practice in which the limitation was found
13 Category of limitation Category of limitation reported
14 Subcategory of limitation Subcategory of limitation reported
15 Annotations General annotations about the limitation
2.1.10 Synthesis of Data

All data extracted in the studies will be recorded in Microsoft Excel™ to facilitate
the synthesis of data. These synthesis aims to group the findings in the studies
according to: the identification of the main concepts (organized in tabular form);
comparative analysis about different agile methods or characteristics of the
208
study; data demographics; answers to the Research Questions; temporal
distribution; type of agile methodology; region of authors. Other kids of
information will be synthesized if necessary.
Meta-ethnographic methods were used to synthesize the data extracted
from the primary studies. This method is recommended to integrate concepts
only when the synthesis of data were conducted, therefore, considered an
interpretative synthesis from the data related of primary studies. This approach
is one form of systematic comparison; it involves the translation of studies into
each other. The collection of the translation constitutes a meta-ethnographic
synthesis (NOBLIT AND HARE, 1988). According to the authors, this approach
is better conducted in seven steps that overlap and repeat as the synthesis
proceeds. The Table 5 shows Noblit and Hare’s seven-step:
Table 5 – Seven phases of meta-ethnography

Step Description step
1 Getting start
2 Deciding what is relevant to the initial interest
3 Reading the studies
4 Determining how the studies are related
5 Translating the studies into one another
6 Synthesizing translations
7 Expressing the synthesis
This process will be conducted to answering our first research question

about the benefits and limitations of agile software development, where the
themes identified will recurred by across interpretation reading of studies.
References of Protocol
BIOLCHINI, J.; MIAN, P. G.; NATALI, A. C. C.; Travassos, G. H. Systematic
review in software engineering, System Engineering and Computer Science
Department COPPE/UFRJ, Technical Report ES, vol. 679, 2005.
CHOW, T.; CAO, D. A survey study of critical success factors in agile

software projects. Journal of Systems and Software, vol. 81, Jun. 2008, pp.
961-971.
Dybå, T.; Dingsøyr, T. Empirical studies of agile software development: A

systematic review. Information and Software Technology, Butterworth-
209
Heinemann Newton, MA, USA, v. 50, n. 9, p. 833-859, August 2008.
EASTERBROOK, S. et al. Selecting Empirical Methods for Software

Engineering Research. In: SHULL, F.; SINGER, J.; SJøBERG, D. I. K. Guide
to advanced empirical software engineering. [S.l.]: Springer-Verlag London,
2008. p. 285-311.
FERREIRA, C.; COHEN, J. Agile systems development and stakeholder

satisfaction: a South African empirical study. SAICSIT '08 Proceedings of
the 2008 annual research conference of the South African Institute of Computer
Scientists and Information Technologists on IT research in developing
countries: riding the wave of technology. 2008.
GLASER, B.; STRAUSS, A. L. The Discovery of Grounded Theory. Aldine,

Chicago, 1967.
HIGGINS, J. P. T.; GREEN, S. Cochrane Handbook for Systematic Reviews

of Interventions, Version 5.0.0 (updated February 2008). The Cochrane
Collaboration, 2008. Available from: <www.cochrane-handbook.org>.
KITCHENHAM, B.; CHARTERS, S. Guidelines for performing systematic

literature reviews in software engineering. Engineering, vol. 2, 2007.
NOBLIT, G. W.; HARE, R. D. Meta-Ethnography: Synthesizing Qualitative

Studies. Sage Publications, London, 1988.
RACHEVA, Z.; DANEVA, M.; SIKKEL, K. Value Creation by Agile Projects:

Methodology or Mystery?. 10th International Conference on Product-Focused
Software Process Improvement (FROFES ’09), Oulu, Finland, 2009.
RACHEVA, Z.; DANEVA, M.; HERRMANN, A. A conceptual model of client-

driven agile requirements prioritization: results of a case study.
In Proceedings of the 2010 ACM-IEEE International Symposium on Empirical
Software Engineering and Measurement (ESEM '10). ACM, New York, NY,
USA, 2010, 15-17.
STRODE, D. E.; HUFF, S. L.; TRETIAKOV, A. The Impact of Organizational

Culture on Agile Method Use. 42nd Hawaii international Conference on
System Sciences, HICSS’09. IEEE Computer Society, Washington, DC, 2009,
pp.1-9.
TEIXEIRA, V. S.; DELAMARO, M. E. Geração de Metadados para o Apoio ao

Teste Estrutural de Componentes. VII Simpósio Brasileiro de Qualidade de
Software, SBQS’08, Florianópolis, SC, Brasil, 2008, pp.406-419.
WILLIAMS, LAURIE.; RUBIN, KENNY.; COHN, MIKE. Driving Process

Improvement via Comparative Agility Assessment. Agile Conference
(AGILE), 2010 , vol., no., pp.3-10, 9-13 Aug. 2010.
210
APÊNDICE C – Roteiro das Entrevistas
Este apêndice contém o roteiro utilizado para condução da entrevista

semiestruturada para realizar a coleta de dados para os estudos de caso.
ROTEIRO
OBJETIVO
 Identificar os Benefícios e as Limitações das Metodologias Ágeis
 Apresentar o termo de sigilosidade
PARTE I – DADOS DO ENTREVISTADO

 Desde quando você trabalha nessa empresa?
 E neste projeto?
 Qual a função que você exerce?
PARTE II – PARTICIPAÇÃO DO ENTREVISTADO NO PROJETO

A. Você chegou a participar da implantação do Scrum neste projeto?
o Se sim
 Poderia me falar como foi que ocorreu a implantação?
 O que você acha que foi bom e ruim no processo de
implantação?
 De quem foi a ideia?
o Se não
 Foi o seu primeiro contato com o Scrum?
B. PLANEJAMENTO DO PROJETO / SPRINT

I. Cliente
o Como funciona a participação do cliente nesta fase do projeto?
 O que ele tem gostado?
 E o que ele não tem gostado?
II. Levantamento de Requisitos
o Como é que os requisitos são levantados?
o Estão sendo adequadas ou não ao projeto?
211
III. Ferramenta de Gestão
IV. Documentação
o Como é feita a documentação do projeto?
o O que você acha da maneira que estão documentando?
V. Sprint Planning
o Participação do Cliente:
 O cliente ou o seu representante participa dessa etapa?
 Como está a interação entre o cliente e a equipe nesta
etapa?
o Participação da Equipe
 Qual a técnica de estimativa da equipe?
 Se for Planning Poker
o O que você acha desta técnica
colaborativa?
o As estimativas estão ou não precisas com
a realidade?
 Como está sendo a participação da equipe no Sprint
Planning?
C. EXECUÇÃO DO PROJETO
o Sprint
 Qual o tempo de duração de um Sprint?
 O tempo está ou não sendo adequado?
 O que você acha de ao final de cada Sprint deve entregar
ao funcional?
o Papéis do Scrum
o Comunicação da Equipe
 Interação entre a equipe
 Reuniões diárias (tempo, eficácia)
o Comunicação com o Cliente ou representante
 Como foi a comunicação com o cliente durante a Sprint?
 Essa comunicação ajudou ou atrapalhou o andamento das
atividades?
212
o Quadro (Task Board)
 Vocês utilizam o quadro com frequência para atualizarem
suas atividades?
 Quais informações importantes o quadro traz para você e a
equipe?
 Existe algo que você não gosta do quadro?
o Desenvolvimento das atividades
o Como funciona o trabalho da equipe?
 O trabalho é mais colaborativo ou individual?
o Práticas de XP
 Programação em Pares,
 TDD
 Refactoring
 Código Coletivo
o Alguma prática ágil adotada no projeto tem ajudado a equipe na
sua visão?
o E ao contrário? Alguma prática de tem prejudicado?
D. ENCERRAMENTO DO PROJETO
o Sprint Review
 Como ocorrem as Reviews?
 O que você acha bom dessas reuniões de Revisão?
 O que você acha que não está ou não foi bom que poderia
ser melhorado?
 Como funciona a participação do Cliente/Representante
nessas reuniões?
 Como estão as entregas das atividades planejadas?
o Sprint Retrospective
 Como ocorrem as reuniões de Retrospectiva do projeto?
 O que você acha bom dessas reuniões?
 O que você acha que não está ou não foi bom que poderia
ou foi melhorado?
 Influência sobre o processo
213
PARTE III – VISÃO GERAL DA EXPERIÊNCIA COM O SCRUM
A. Ambiente
o O que você acha do ambiente de trabalho com o Scrum?
B. Tamanho da equipe
o Qual o tamanho atual da equipe?
o Você acha que o Scrum foi ideal para o tamanho da equipe?
C. Complexidade do projeto
o Como você considera a complexidade do projeto?
 Você acha o Scrum adequado para este grau de
complexidade?
D. Custo, esforço e tempo do projeto.
E. Qualidade do projeto (erros, defeitos, reuso).
F. Aspecto cultural ou social

o Você acha que o uso do Scrum teve algum impacto positivo ou
negativo nos aspectos culturais ou sociais da equipe?
o E na empresa como um todo? Como essa abordagem de trabalho
é vista?
G. Aceitação do Scrum pela Equipe e Organização
H. Aprendizado
 Como você poderia classificar o aprendizado no Scrum? Foi fácil ou
difícil de aprender?
o Se foi FÁCIL
 O que facilitou esse aprendizado?
o Se NÃO foi fácil

 O que dificultou?
214
PARTE IV – BENEFÍCIOS DAS METODOLOGIAS ÁGEIS
A. Mencione por favor, os 05 maiores benefícios que ocorreram no projeto
em virtude do uso do Scrum.
PARTE V – LIMITAÇÕES DAS METODOLOGIAS ÁGEIS

A. Mencione por favor, os 05 maiores limitações que ocorreram no projeto
em virtude do uso do Scrum.
FINAL
A. Você tem mais alguma coisa a falar? Complementar alguma resposta?
AGRADECIMENTO
215
APÊNDICE D – Termo de Sigilosidade da
Empresa
Nome da empresa:
Representante:
Entrevistador:
SOBRE A ENTREVISTA
Esta entrevista é direcionada aos profissionais envolvidos na área de
desenvolvimento de software. O seu objetivo é coletar de forma estruturada
informações sobre a opinião dos profissionais em relação a sua experiência
com o uso das diversas práticas e Metodologias Ágeis adotadas nos projetos
de desenvolvimento de software da empresa.
A entrevista é estruturada em seis partes:
● Parte I – Dados do Entrevistado: informações gerais sobre o profissional

entrevistado.
● Parte II – Informações sobre os projetos: tamanho da equipe, definição
dos papéis da equipe, nível de maturidade da equipe, contexto dos projetos,
linguagem de programação utilizada, tempo de vida do projeto.
● Parte III – Participação do entrevistado no projeto: informações sobre as
atividades desenvolvidas (nível de práticas de engenharia) pelo entrevistado e
sua equipe (concepção, análise, planejamento, execução e encerramento do
projeto).
● Parte IV – Visão geral da experiência com o Scrum: percepção do
entrevistado quanto ao uso, sua experiência e opinião.
● Parte V – Benefícios das Metodologias Ágeis: percepção do entrevistado
quanto aos benefícios que as Metodologias Ágeis propuseram aos projetos.
● Parte VI – Limitações das Metodologias Ágeis: percepção do entrevistado
quanto as limitações que as Metodologias Ágeis propuseram aos projetos.
216
SIGILO DAS INFORMAÇÕES
As informações pessoais da identificação do entrevistado não serão reveladas
sem a autorização do mesmo. Os dados referentes aos projetos que
comprometam o planejamento estratégico da empresa não serão publicados.
As Informações das Partes II, III, IV, V e VI serão coletadas e analisadas como
parte da pesquisa intitulada "Benefícios e Limitações das Metodologias Ágeis"
e podem vir a ser publicadas em artigos científicos.
CITAÇÕES DOS ENTREVISTADOS

Os dados dos entrevistados não serão citados em nenhuma circunstância,
garantindo total confidencialidade sobre o seu nome e as respostas individuais
preenchidas nesta entrevista. Porém, a participação será devidamente
agradecida de forma conjunta em artigos científicos.
AGRADECIMENTOS
O orientador da pesquisa, Prof. Alexandre Marcos Lins de Vasconcelos, o
coorientador, Prof. Fabio Queda Bueno da Silva, e o aluno do mestrado
Fernando Kenji Kamei agradecem antecipadamente a disponibilidade, e
informam que os resultados desta atividade da pesquisa serão divulgados a
todos os entrevistados.
Recife, ____ de junho de 2012.
______________________________________________
Assinatura do representante da organização
______________________________________________
Assinatura do entrevistador
217
APÊNDICE E – Termo de Sigilosidade do
Entrevistado
Nome da empresa:
Entrevistado:
Entrevistador:
SOBRE A ENTREVISTA
Esta entrevista é direcionada aos profissionais envolvidos na área de
desenvolvimento de software. O seu objetivo é coletar de forma estruturada
informações sobre a opinião dos profissionais em relação a sua experiência
com o uso das diversas práticas e Metodologias Ágeis adotadas nos projetos
de desenvolvimento de software da empresa.
A entrevista é estruturada em cinco partes:
● Parte I – Dados do Entrevistado: informações gerais sobre o profissional

entrevistado.
● Parte II – Participação do entrevistado no projeto: informações sobre as
atividades desenvolvidas (nível de práticas de engenharia) pelo entrevistado e
sua equipe (concepção, análise, planejamento, execução e encerramento do
projeto).
● Parte III – Visão geral da experiência com o Scrum: percepção do
entrevistado quanto ao uso, sua experiência e opinião.
● Parte IV – Benefícios das Metodologias Ágeis: percepção do entrevistado
quanto aos benefícios que as Metodologias Ágeis propuseram aos projetos.
● Parte V – Limitações das Metodologias Ágeis: percepção do entrevistado
quanto as limitações que as Metodologias Ágeis propuseram aos projetos.
218
CITAÇÕES DOS ENTREVISTADOS
Os dados dos entrevistados não serão citados em nenhuma circunstância,
garantindo total confidencialidade sobre o seu nome e as respostas individuais
preenchidas nesta entrevista. Porém, a participação será devidamente
agradecida de forma conjunta em artigos científicos.
AGRADECIMENTOS
O orientador da pesquisa, Prof. Alexandre Marcos Lins de Vasconcelos, o
coorientador, Prof. Fabio Queda Bueno da Silva, e o aluno do mestrado
Fernando Kenji Kamei agradecem antecipadamente a disponibilidade, e
informam que os resultados desta atividade da pesquisa serão divulgados a
todos os entrevistados.
Recife, ____ de junho de 2012.
______________________________________________
Assinatura do representante da organização
______________________________________________
Assinatura do entrevistador
219
APÊNDICE F – Estudos primários da Revisão
Sistemática da Literatura
A Tabela 19 apresenta o detalhamento bibliográfico, o ano de publicação, e

a(s) fonte(s) de dados onde foi identificado cada um dos 125 estudos incluídos
na Revisão Sistemática da Literatura.
Tabela 19 – Referência bibliográfica dos estudos primários

ID Ano Fonte Referência
HOLE, S.; MOE, B. N. A Case Study
of Coordination in Distributed Agile
Software Development.
prs12 2008 SpringerLink Communications in Computer and
Information Science, 2008, Volume
16, Software Process Improvement,
Part 5, 189-200.
MOSER, R.; ABRAHAMSSON, P.;
PEDRYCZ, W.; SILLITTI, A.; SUCCI,
G. A Case Study on the Impact of
Refactoring on Quality and
prs17 2008 El Compendex Productivity in an Agile Team.
Balancing Agility and Formalism in
Software Engineering, 2008, 252-
266.
FRUHLING A.; MCDONALD P.;
DUNBAR C. A Case Study:
Introducing eXtreme Programming in
El Compendex, IEEE, a US Government System
prs18 2008
Scopus Development Project. Hawaii
International Conference on System
Sciences. HICSS, 2008, 465.
PETERSEN, K.; WOHLIN, C. A

Comparison of Issues and
Advantages in Agile and Incremental
prs27 2009 ISI, Science Direct Development Between State of the
Art and an Industrial Case. Journal of
Systems and Software, 2009, Volume
82, Issue 9, 1479-1490.
MARUPING L. M.; VENKATESH, V.;

AGARWAL R. A Control Theory
Perspective on Agile Methodology
prs35 2009 ISI, Scopus
Use and Changing User
Requirements. Journal of Information
Systems Research, 2009, Volume
220
20, Issue 3, 377-399.
SHARP, H.; ROBINSON, H. A
Distributed Cognition Account of
El Compendex, XP Mature XP Teams.CLecture Notes In
prs44 2006
Conference Computer Science, 2006, Volume
4044, 1-10.
CAO, L.; MOHAN K.; XU, P.;
RAMESH, B. A Framework for
Adapting Agile Development
prs49 2009 ISI, Scopus Methodologies. European Journal of
Information Systems, 2009, Volume
18, No. 4, 332-343.
QUMER, A; HENDERSON-
SELLERS, B. A Framework to
Support the Evaluation, Adoption and
El Compendex, ISI, Improvement of Agile Methods in
prs56 2008
Science Direct, Scopus Practice. Journal of Systems and
Software, 2008, Volume 81, 1899-
1919.
COYLE, S.; CONBOY, K. A Study of

Risk Management in DSDM. Agile
Processes in Software Engineering
prs123 2009 El Compendex, Scopus and Extreme Programming. Lecture
Notes in Business Information
Processing, 2009, Volume 31, Part 3,
Part 4, 142-148.
CHOW, T.; CAO, D. A Survey Study

of Critical Success Factors in Agile
El Compendex, ISI, Software Projects. Journal of
prs129 2008
Science Direct, Scopus Systems and Software, 2008, Volume
81, Issue 6, 961-971.
MOE, N. B.; DINGSØYR, T.; DYBÅ,

T. A Teamwork Model for
Understanding an Agile Team: A
El Compendex, ISI, Case Study of a Scrum Project.
prs135 2010
Science Direct, Scopus Information and Software
Technology, 2010, Volume 52, no. 5,
480-491.
NOËL, R.; VALDES, G.; VISCONTI,
M.; ASTUDILLO, H. Adding Planned
Design to XP Might Help Novices'
Productivity (or ight not): Two
ACM, El Compendex,
prs162 2008 Controlled Experiments. ACM-IEEE
ESEM
International Symposium on
Empirical Software Engineering and
Measurement. ESEM, 2008, 285-
287.
221
SURESHCHANDRA, K.;
SHRINIVASAVADHANI, J. Adopting
El Compendex, IEEE, Agile in Distributed Development.
prs171 2008 IEEE International Conference Global
Scopus
Software Engineering. ICGSE, 2008,
217-221.
FÆGRI, T. E. Adoption of Team

Estimation in a Specialist
Organizational Environment. Agile
prs182 2010 XP Conference and Extreme Programming. Lecture
28-42.
MAZNI, O.; SHARIFAH-LAILEE, S.-

A.; AZMAN, Y. Agile Documents:
Toward Successful Creation of
Effective Documentation. Agile
SpringerLink, XP Processes in Software Engineering
prs230 2010
Conference and Extreme Programming. Lecture
196-201.
RUDZKI, J.; HAMMOUDA, I.;
MIKKOLA, T. Agile Experiences in a
Software Service Company.
prs236 2009 El Compendex, IEEE Euromicro Conference on Software
Engineering and Advanced
Applications. SEAA, 2009, 224-228.
TOLFO, C.; WAZLAWICK, R. S.;
FERREIRA, M. G. G.; FORCELLINI,
F. A. Agile Methods and
Organizational Culture: Reflections
prs258 2010 Wiley About Cultural Levels. Journal of
Software Maintenance and Evolution:
Research and Practice, 2011,
Volume 23, Issue 6, 423-441.
SEGER, T.; HAZZAN, O.; BAR-

NAHOR, R. Agile Orientation and
El Compendex, IEEE, Psychological Needs, Self-Efficacy,
prs275 2008 and Perceived Support: A Two Job-
Scopus
Level Comparison. Agile Conference.
AGILE, 2008, 3-14.
222
SCHINDLER, C. Agile Software
Development Methods and Practices
in Austrian IT-Industry: Results of an
El Compendex, IEEE, Empirical Study. International
prs322 2008
Scopus Conference on Computational
Intelligence for Modelling Control and
Automation. CIMCA, 2008, 321-326.
AHMED, A.; AHMAD, S.; EHSAN, N.;

MIRZA, E.; SARWAR, S. Z. Agile
software development: Impact on
El Compendex, IEEE,
prs331 2010 productivity and quality. International
Scopus
Conference on Management of
Innovation and Technology. ICMIT,
2010, 287-291.
FERREIRA, C.; COHEN, J. Agile
Systems Development and
Stakeholder Satisfaction: A South
African Empirical Study. Annual
ACM, El Compendex, research conference of the South
prs346 2008
Scopus African Institute of Computer
Scientists e Information
Technologists on IT. SAUCSIT, 2008,
48-55.
SHATIL, A.; HAZZAN, O.;
DUBINSKY, Y. Agility in a Large-
Scale System Engineering Project: A
El Compendex, IEEE, Case-Study of an Advanced
prs371 2010 Communication System Project.
Scopus
IEEE International Conference on
Software Science, Technology &
Engineering. SWSTE, 2010, 47-54.
CAPILUPPI, A.; FERNANDEZ-

RAMIL, J.; HIGMAN, J.; SHARP, H.
C. ; SMITH, N. An Empirical Study of
ACM, El Compendex, the Evolution of an Agile-Developed
prs428 2007
IEEE, Scopus Software System. International
Conference on Software Engineering.
ICSE, 2007, 511-518.
HAUGEN, N. C. An Empirical Study

Agile Conference, El of Using Planning Poker for User
prs430 2006 Compendex, IEEE, Story Estimation. Agile Conference.
Scopus AGILE, 2006, 23-34.
223
FRANÇA, A. C. C.; da SILVA, F. Q.
B.; de SOUZA MARIZ, L. M. R. An
Empirical Study on the Relationship
Between the use of Agile Practices
ACM, El Compendex, and the Success of Scrum Projects.
prs434 2010
ESEM, Scopus ACM-IEEE International Symposium
on Empirical Software Engineering
and Measurement. ESEM, 2010,
2010, Article No. 37.
BABAR, M. A. An Exploratory Study

of Architectural Practices and
Challenges in Using Agile Software
El Compendex, IEEE, Development Approaches.
prs448 2009 Conference on Software Architecture
Scopus
e European Conference on Software
Architecture. WICSA/ECSA, 2009,
81-90.
SALO, O.; ABRAHAMSSON, P. An
Iterative Improvement Process for
El Compendex, Agile Software Development.
prs462 2007 Software Process: Improvement and
Scopus, Wiley
Practice, 2007, Volume 12, Issue 1,
81–100.
KOBAYASHI, O.; KAWABATA, M.;
SAKAI, M.; PARKINSON, E. Analysis
ACM, El of the Interaction Between Practices
prs466 2006 for Introducing XP Effectively.
Compendex,Scopus
International Conference on Software
Engineering. ICSE, 2006, 544-550.
BHALERAO, S.; INGLE, M.

Analyzing the Modes of
El Compendex, IEEE, Communication in Agile Practices.
prs469 2010 International Conference on
Scopus
Computer Science and Information
Technology. ICCSIT, 2010, 391-395.
TAYLOR, P. S.; GREER, D.; SAGE,
P.; COLEMAN, G.; MCDAID, K.;
LAWTHERS, I.; CORR, R. Applying
an Agility/Discipline Assessment for a
El Compendex, ISI, Small Software Organisation.
prs487 2006
Scopus, SpringerLink Product-Focused Software Process
Improvement. Lecture Notes in
Computer Science, 2006, Volume
4034, 290-304.
224
LAVAZZA, L.; MORASCA, S.; TAIBI,
D.; DAVIDE, T. Applying SCRUM in
an OSS Development Process: An
Empirical Evaluation. Agile
prs490 2010
147-159.
HODA, R.; NOBLE, J.; MARSHALL,
ACM, El Compendex, S. Balancing Acts: Walking the Agile
prs535 2010
Scopus Tightrope. CHASE’10, p. 5-12.
KARHATSU, H.; IKONEN, M.;

KETTUNEN, P.; FAGERHOLM, F.;
ABRAHAMSSON, P. Building Blocks
for Self-Organizing Software
El Compendex, IEEE, Development Teams - A Framework
prs564 2010
Scopus Model and Empirical Pilot Study.
International Conference on Software
Technology and Engineering. ICSTE,
2010, 297-304.
MADEYSKI, L.; BIELA, W. Capable
Leader and Skilled and Motivated
Team Practices to Introduce eXtreme
El Compendex, Programming. Balancing Agility and
prs571 2006
Scopus, SpringerLink Formalism in Software Engineering.
Lecture Notes in Computer Science,
2008, Volume 5082, 96-102.
VIDGEN, R.; WANG, X. Coevolving

Systems and the Organization of
prs591 2009 ISI, Scopus Agile Software Development.
Information Systems Research, 2009,
Volume 20, No. 3, 355-376.
SHARP, H.; ROBINSON, H.
Collaboration and Co-ordination in
El Compendex, ISI, Mature eXtreme Programming
prs593 2008 Teams. International Journal of
Science Direct, Scopus
Human-Computer Studies, 2008,
Volume 66, Issue 7, 506-518.
KORKALA M.; PIKKARAINEN, M.;
CONBOY, K. Combining Agile and
Traditional: Customer
prs597 2010 SpringerLink Communication in Distributed
Environment. Agility Across Time and
Space, 2010, Part 3, 201-216.
225
PARK, S.; MAURER, F.
Communicating Domain Knowledge
in Executable Acceptance Test
El Compendex, Driven Development. Agile
prs604 2009 Scopus, SpringerLink, Processes in Software Engineering
XP Conference and Extreme Programming. Lecture
Processing, 2009, 23-32.
GREEN, R.; MAZZUCHI, T.;

SARKANI, S. Communication and
Quality in Distributed Agile
Development: An Empirical Case
prs606 2010 El Compendex, Scopus Study. International Journal of
Information and Communication
Engineering, 2010, Volume 6, No. 3,
144-150.
KORKALA, M.; ABRAHAMSSON, P.
Communication in Distributed Agile
El Compendex, IEEE, Development: A Case Study.
prs608 2007 Euromicro Conference on Software
Scopus
MELNIK G.; MAURER, F.

Comparative Analysis of Job
Satisfaction in Agile and Non-Agile
El Compendex, ISI, Software Development Teams. Agile
prs610 2006 Scopus, SpringerLink, Processes in Software Engineering
Notes in Computer Science, 2006,
Volume 4044, 32-42.
ZANNIER, C.; MAURER, F.

Comparing Decision Making in Agile
ACM, El Compendex, and Non-Agile Software
prs612 2007 Scopus, SpringerLink, Organizations. Agile Processes in
XP Conference Software Engineering and Extreme
Programming. Lecture Notes in
Computer Science, 2007, 1-8.
QUMER, ASIF; HENDERSON-

SELLERS, B. Construction of an
Agile Software Product-Enhancement
Process by Using an Agile Software
El Compendex, IEEE, Solution Framework (ASSF) and
prs628 2007
Scopus Situational Method Engineering. 31st
Annual International Computer
Software and Applications
Conference (COMPSAC 2007), 2007.
226
CHENG, T-H; JANSEN, S.;
REMMERS, M. Controlling and
monitoring agile software
ACM, El Compendex, development in three dutch product
prs636 2009
IEEE, Scopus software companies. 2009 ICSE
Workshop on Software Development
Governance. SDG, 2009, 29-35.
FITZGERALD, B.; HARTNETT, G.;
CONBOY, K. Customising Agile
Methods to Software Practices at
prs651 2006 ISI, Scopus Intel Shannon. European Journal of
15, Issue 2, 200-213.
HONG, N.; YOO, J.; CHA, S.

Customization of Scrum Methodology
El Compendex, IEEE, for Outsourced E-commerce Projects.
prs652 2010
Scopus Asia-Pacific Software Engineering
Conference. ASPEC, 2010, 310-315.
SENA J.; COGET, J.-F.; SHANI, A.
B. Designing for Agility as an
Organizational Capability: Learning
prs670 2009 Scopus from a Software Development Firm.
International Journal of Knowledge,
Culture and Change Management,
Volume 9, Issue 5, 17-36.
KORKALA, M.; PIKKARAINEN, M.;

CONBOY, K. Distributed Agile
Development: A Case Study of
Customer Communication
El Compendex, Challenges. Agile Processes in
prs687 2009 Software Engineering and Extreme
Scopus, SpringerLink
Business Information Processing,
2009, Volume 31, Part 3, Part 5, 161-
167.
PAASIVAARA, M.; DURASIEWICZ,
S.; LASSENIUS, C. Distributed Agile
Development: Using Scrum in a
El Compendex, IEEE,
prs688 2008 Large Project. International
Scopus
Conference on Global Software
Engineering. ICGSE, 2008, 87-95.
LEE, S.; YONG, H-S. Distributed

Agile: Project Management in a
El Compendex, ISI, Global Environment. Empirical
prs689 2010
Scopus, SpringerLink Software Engineering, 2010, Volume
15, No. 2, 204-217.
227
SUTHERLAND, J.; VIKTOROV, A.;
BLOUNT, J.; PUNTIKOV, N.
Distributed Scrum: Agile Project
prs694 2007 IEEE Management with Outsourced
Development Teams. Hawaii
Sciences. HICSS, 2007. 247a.
RACHEVA, Z.; DANEVA, M.;

SIKKEL, K.; WIERINGA, R.;
HERRMANN, A. Do We Know
Enough about Requirements
El Compendex, IEEE,
prs700 2010 Prioritization in Agile Projects:
Scopus
Insights from a Case Study.
International Requirements
Engineering Conference. RE, 2010,
147-156.
MOSER, R.; SILLITTI, A.;
ABRAHAMSSON, P.; SUCCI, G.
Does Refactoring Improve
Reusability? International Conference
El Compendex, ISI,
prs702 2006 on Reuse of Off-the-Shelf
SpringerLink, Scopus
Components. Lecture Notes in
Computer Science, Volume 4039,
287–297.
SINIAALTO, M.; ABRAHAMSSON, P.

Does Test-Driven Development
Improve the Program Code?
Alarming Results from a Comparative
El Compendex,
prs703 2008 Case Study. Balancing Agility and
Formalism in Software Engineering.
2008, Volume 5082, 143-156.
BEECHAM, S.; SHARP, H.;

BADDOO, N.; HALL, T.; ROBINSON,
Agile Conference, El H. Does the XP Environment Meet
prs705 2007 Compendex, IEEE, the Motivational Needs of the
Scopus Software Developer? An Empirical
Study. Agile Conference. AGILE,
2007, 37-49.
MOSER, R.; SCOTTO, M.; SILLITTI,

A.; SUCCI, G. Does XP Deliver
Quality and Maintainable Code? Agile
ACM, El Compendex, Processes in Software Engineering
prs706 2007
Volume 4536, 105-114.
228
WILLIAMS, L.; RUBIN, K,; COHN, M.
Driving Process Improvement via
El Compendex, IEEE, Comparative Agility Assessment.
prs710 2010
Scopus Agile Conference. AGILE, 2010, 3-
10.
AHMAD, E.; RAZA, B.; FELDT, R.;
NORDEBÄCK, T. ECSS Standard
Compliant Agile Software
prs716 2010 ACM Development - An Industrial Case
Study. National Conference for
Software Engineering. NSEC, 2010,
Article No. 6.
MISHRA, D.; MISHRA, A. Effective

Communication, Collaboration, and
Coordination in eXtreme
El Compendex, ISI, Programming: Human-Centric
prs719 2009 Perspective in a Small Organization.
Scopus, Wiley
Human Factors and Ergonomics In
Manufacturing, 2009, Volume 9, 438–
456.
RICO, D. F. Effects of Agile Methods
on Website Quality for Electronic
prs723 2008 IEEE Commerce. Hawaii International
Conference on System Sciences.
HICSS, 2008, 463.
ABRAHAMSSON, P.; MOSER, R.;
PEDRYCZ, W.; SILLITTI, A.; SUCCI,
G. Effort Prediction in Iterative
Software Development Processes -
El Compendex, ESEM, Incremental Versus Global Prediction
prs726 2007
IEEE, Scopus Models. International Symposium on
353.
LAYMAN, L.; WILLIAMS, L.;

DAMIAN, D.; BURES, H. Essential
Communication Practices for
El Compendex, ISI, Extreme Programming in a Global
prs767 2006 Software Development Team.
Scopus, Science Direct
Information and Software
Technology, 2006, Volume 48, Issue
9, 781–794.
KORHONEN, K. Evaluating the Effect

of Agile Methods on Software Defect
Data and Defect Reporting Practices
El Compendex, IEEE, - A Case Study. International
prs779 2010
Scopus Conference on the Quality of
Information and Communications
Technology. QUATIC, 2010, 35-43.
229
WHITWORTH, E. Experience Report:
El Compendex, IEEE, The Social Nature of Agile Teams.
prs793 2008 Agile Conference. AGIEL, 2008, 429-
Scopus
435.
VANHANEN, J.; KORPI, H.

Experiences of Using Pair
Programming in an Agile Project.
El Compendex, IEEE,
prs796 2007 Hawaii International Conference on
Scopus
System Sciences. HICSS, 2007,
274b.
SATO, D.; BASSI, D.; BRAVO, M.;

GOLDMAN, A.; KON, F. Experiences
Tracking Agile Projects: an Empirical
prs797 2006 SpringerLink Study. Journal of the Brazilian
Computer Society, 2006, Volume 12,
Issue 3, 45-64.
WOJCIECHOWSKI, A.;
WESOLOWSKI, M.; COMPLAK, W.
Experimental Evaluation of ’On-Site
Customer’ XP Practice on Quality of
El Compendex, Software and Team Effectiveness.
prs804 2010
Scopus, SpringerLink On The Move To Meaningful Internet
Systems: OTM 2010 WORKSHOPS.
2010, Volume 6428, 269-278.
MAHER, P.E.; KOURIK, J.L.;
CHOOKITTIKUL, W. Exploratory
Study of Agile Methods in the
prs809 2010 IEEE Vietnamese Software Industry.
International Multi-Conference on
Computing in the Global Information
Technology. ICCGI, 2010, 300-304.
SARKER, S.; SARKER, S. Exploring

Agility in Distributed Information
Systems Development Teams: An
prs813 2009 ISI, Scopus Interpretive Study in an Offshoring
Context. Information Systems
Research, 2009, Volume 20, Issue 3,
440-461.
KORHONEN, K. Exploring Defect

Data, Quality and Engagement during
Agile Transformation at a Large
Multisite Organization. Agile
prs814 2010 XP Conference Processes in Software Engineering
and Extreme Programming. Lecture
88-102.
230
LIVERMORE, J. A. Factors that
Impact Implementing an Agile
El Compendex, IEEE,
prs848 2007 Software Development Methodology.
Scopus
SoutheastCon, 2007, 82-86.
SUTHERLAND, J.; SCHOONHEIM,

G.; KUMAR, N.; PANDEY, V.;
VISHAL, S. Fully Distributed Scrum:
El Compendex, IEEE, Linear Scalability of Production
prs879 2009
Scopus between San Francisco and India.
Agile Conference. AGILE, 2009, 277-
282.
BASKERVILLE, R.; RAMESH, B.;

LEVINE, L.; PRIES-HEJE, J. High-
El Compendex, IEEE, Speed Software Development
prs909 2006 Practices: What Works, What
Scopus
Doesn't. IT Professional, 2006,
Volume 8, Issue 4, 29-36.
NIKITINA, N.; KAJKO-MATTSSON,

M. Historical Perspective of Two
prs910 2009 IEEE Process Transitions. International
Conference on Software Engineering
Advances. ICSEA, 2009, 289-298.
HOSSAIN, E.; BABAR, M. A.;
VERNER, J. How Can Agile
Practices Minimize Global Software
El Compendex, Development Co-ordination Risks?
prs918 2009 Software Process Improvement.
Communications in Computer and
Information Science, 2009, Volume
42, Part 3, 81-92.
KARLSTROM, D.; RUNESON, P.

Integrating Agile Software
El Compendex, ISI, Development into Stage-Gate
prs980 2006 Managed Product Development.
Empirical Software Engineering,
2006, Volume 11, Issue 2, 203-225.
GIBLIN, M.; BRENNAN, P.; EXTON,
C. Introducing Agile Methods in a
Large Software Development Team:
The Developers Changing
prs1001 2010 XP Conference Perspective. Agile Processes in
Software Engineering and Extreme
2010, Volume 48, Part 2, 184-189.
231
GIBLIN, M.; BRENNAN, P.; EXTON,
C. Introducing Agile Methods in a
Large Software Development Team:
The Impact on the Code. Agile
prs1002 2010
58-72.
HUSSAIN, Z.; WOLFGANG, S.;
HOLZINGER, A. Investigating Agile
El Compendex, User-Centered Design in Practice: A
prs1016 2009 Grounded Theory Perspective.
2009, Volume 5889, 279-289.
SFETSOS, P.; ANGELIS, L.;

STAMELOS, I. Investigating the
El Compendex, ISI, Extreme Programming System - An
prs1019 2006 Empirical Study. Empirical Software
SpringerLink, Scopus
Engineering, 2006, Volume 11, No. 2,
269-301.
PETRILLO, F.; PIMENTA, M. Is

Agility Out There?: Agile Practices in
ACM, El Compendex, Game Development. ACM
prs1023 2010 International Conference on Design
Scopus
of Communication. SIGDOC, 2010,
9-15.
TESSEM, B.; MAURER, F. Job
Satisfaction and Motivation in a Large
ACM, El Compendex, Agile Team. Agile Processes in
prs1037 2007 Scopus, SpringerLink, Software Engineering and Extreme
XP Conference Programming. Lecture Notes In
KAUTZ, K.; ZUMPE, S. Just Enough

Structure at the Edge of Chaos: Agile
Information System Development in
Practice. Agile Processes in Software
prs1039 2008 XP Conference Engineering and Extreme
2008, Volume 9, 137–146.
MURPHY, P.; DONNELLAN, B.

Lesson learnt from an agile
implementation project. Agile
prs1069 2009 El Compendex, Scopus and Extreme Programming. Lecture
Part 4, 136-141.
232
JOHANNESSEN, L. K.; ELLINGSEN,
G. Lightweight Methods in
prs1075 2008 ACM Heavyweight Organizations.
Participatory Design Conference.
PDC, 2008, 11-20.
MARCHENKO, A.; ABRAHAMSSON,
P.; IHME, T. Long-Term Effects of
Test-Driven Development A Case
Scopus, El Study. Agile Processes in Software
prs1078 2009 Compendex, XP Engineering and Extreme
Conference Programming. Lecture Notes in
2009, Volume 31, Part 2, Part 1, 13-
22.
KORHONEN, K. Migrating Defect
Management From Waterfall to Agile
Software Development in a Large-
scale Multi-site Organization: A Case
El Compendex,
Study. Agile Processes in Software
prs1112 2009 Scopus, SpringerLink,
Engineering and Extreme
XP Conference
Programming.Lecture Notes in
2009, Volume 31, Part 2, 73-82.
HOSBOND, J. H.; NIELSEN, P. A.

Misfit or Misuse? Lessons from
Implementation of Scrum in Radical
Product Innovation. Agile Processes
prs1114 2008 XP Conference in Software Engineering and Extreme
2008, Volume 9, Part 1, 21-31.
WHIWORTH, E.; BIDDLE, R.

Motivation and Cohesion in Agile
ACM, El Compendex, Teams. Agile Processes in Software
prs1132 2007 Scopus, SpringerLink, Engineering and Extreme
XP Conference Programming. Lecture Notes In
LAYMAN, L.; WILLIAMS, L.;

CUNNIGHAM, L. Motivations and
Measurements in an Agile Case
Study. Journal of Systems
El Compendex, ISI, Architecture: the EUROMICRO
prs1133 2006
Science Direct, Scopus Journal - Special issue: AGILE
Methodologies for Software
Production, 2006, Volume 52, Issue
11, 654-667.
233
MELNIK, G.; MAURER, F. Multiple
Perspectives on Executable
Acceptance Test-Driven
ACM, El Compendex, Development. Agile Processes in
prs1136 2006 Scopus, SpringerLink, Software Engineering and Extreme
XP Conference Programming. Lecture Notes in
Computer Science, 2007, Volume
4536, 245-249.
SRINIVASAN, J; LUNDQVIST, K.
Organizational Enablers for Agile
Adoption: Learning from
GameDevCo. Agile Processes in
El Compendex, XP
prs1166 2009 Software Engineering and Extreme
Conference
2009, Volume 31, Part 2, 63-72.
NYFJORD, J.; KAJKO-MATTSSON,

M. Outlining a Model Integrating Risk
Management and Agile Software
prs1170 2008 Scopus Development. Euromicro Conference
Software Engineering and Advanced

T. Overcoming Barriers to Self-
Scopus, ISI, IEEE, Management in Software Teams.
prs1173 2009
IEEE Software IEEE Software, 2009, Volume 26
Issue 6, 20-26.
PATEL, C.; LYCETT, M.;
MACREDIE, R.; DE CESARE, S.
Perceptions of Agility and
Scopus, IEEE, Collaboration in Software
prs1193 2006 Development Practice. Hawaii
compendex
Sciences. HICSS, 2006, Volume 1,
10.3.
HEARTY, P.; FENTON, N.;
MARQUEZ, D.; NEIL, M. Predicting
IEEE, IEEE Project Velocity in XP Using a
prs1208 2009 Transactions on Learning Dynamic Bayesian Network
Software Engineering Model. IEEE Transactions on
Software Engineering, 2009, Volume
35, Issue 1, 124-137.
234
TAYLOR, P. S.; GREER, D.;
COLEMAN, G.; MCDAID, K.;
KEENAN, F. Preparing Small
El Compendex, Software Companies for Tailored
prs1212 2008 Agile Method Adoption: Minimally
Scopus, Wiley
Intrusive Risk Assessment. Software
Process: Improvement and Practice,
2008, Volume 13, Issue 5, 421-437.
MOE, N. B.; DINGSØYR, T.;

RØYRVIK, E. A. Putting Agile
Teamwork to the Test – An
Preliminary Instrument for Empirically
Assessing and Improving Agile
Scopus, XP Software Development. Agile
prs1238 2009
Conference Processes in Software Engineering
Part 3, 114-123.
TALBY, D.; HAZZAN, O.;

Scopus, Agile DUBINSKY, Y.; KEREN, A.
prs1256 2006 Development Reflections on Reflection in Agile
Conference Software Development. Agile
Conference. AGILE, 2006, 100-112.
MAIERHOFER S.; STELZMANN, E.;
KOHLBACHER, M.; FELLNER, B.
Requirement Changes and Project
Success: The Moderating Effects of
El Compendex, Agile Approaches in System
prs1260 2010 Engineering Projects. Systems,
Software and Services Process
Improvement. Communications in
Computer and Information Science,
2010, Volume 99, 60-70.
MARUPING, L. M.; ZHANG, X.;
VENKATESH, V. Role of Collective
Ownership and Coding Standards in
prs1271 2009 ISI, Scopus Coordinating Expertise in Software
Project Teams. European Journal of
18, No. 4, 355-371.
MOE, N. B.; DINGSØYR, T. Scrum

and Team Effectiveness: Theory and
Practice. Agile Processes in Software
SpringerLink, XP Engineering and Extreme
prs1296 2008
Conference Programming.Lecture Notes in
2008, Volume 9, Part 1, 11-20.
235
HAYES, S.; RICHARDSON, I. Scrum
Implementation Using Kotter’s
Change Model. Agile Processes in
SpringerLink, XP Software Engineering and Extreme
prs1300 2008
Conference Programming. Lecture Notes in
2008, Volume 9, Part 6, 161-171.
MARCHENKO, A.; ABRAHAMSSON,

P. Scrum in a Multiproject
Agile Conference, Environment: An Ethnographically-
prs1301 2008 Inspired Case Study on the Adoption
IEEE
Challenges. Agile Conference.
AGILE, 2008, 15-26.
LEHTO, I.; RAUTIAINEN, K.
Software Development Governance
Challenges of a Middle-Sized
ACM, El Compendex, Company in Agile Transition. 2009
prs1335 2009
IEEE, Scopus ICSE Workshop on Software
Development Governance. SDG,
2009, 36-39.
HASHMI, S. I.; JONGMOON, B.

Software Quality Assurance in XP
El Compendex, IEEE, and Spiral - A Comparative Study.
prs1352 2007 International Conference
Scopus
Computational Science and its
Applications. ICCSA, 2007, 367-374.
ENGUM, E. A.; RACHEVA, Z.;

DANEVA, M. Sprint Planning with a
Digital Aid Tool: Lessons Learnt.
prs1363 2006 IEEE, El Compendex Euromicro Conference on Software
DOWNS, J.; HOSKING, J.;

PLIMMER, B. Status Communication
El Compendex, IEEE, in Agile Software Teams: A Case
prs1371 2010 Study. International Conference on
Scopus
Software Engineering Advances,
2010, 82-87.
DUBINSKY, Y.; HAZZAN, O.;
TALBY, D.; KEREN, A. International
prs1398 2006 El Compendex, Scopus Conference on Enterprise Information
Systems, 2006, 11-18.
LARUSDOTTIR, M. K.;
BJARNADOTTIR, E. M.;
GULLIKSEN, J. Human-Computer
prs1491 2010 SpringerLink Interaction. IFIP Advances in
Information and Communication
Technology, 2010, Volume 332/2010,
98-109.
236
PIKKARAINEN, M.; HAIKARA, J.;
SALO, O.; ABRAHAMSSON, P.;
El Compendex, ISI, STILL, J. Empirical Software
prs1497 2008
Scopus, SpringerLink Engineering, 2008, Volume 13, No. 3,
303-337.
SYED-ABDULLAH S.; HOLCOMBE,
M.; GHEORGE, M. The Impact of an
El Compendex, ISI, Agile Methodology on the Well Being
prs1500 2006 of Development Teams. Empirical
Software Engineering, 2006, Volume
11, Issue 1, 143-167.
TOLFO, C.; WAZWICK, R. S. The
Influence of Organizational Culture
Scopus, ISI, Science, on the Adoption of Extreme
prs1510 2008 Programming. Journal of Systems
El Compendex
and Software, 2008, Volume 81,
Issue 11, 1955-1967.
NAWAZ, A. I.; ZUALKERNAN, I. A.

The Role of Agile Practices in
Disaster Management and Recovery:
prs1525 2009 ACM A Case Study. Conference of the
Center for Advanced Studies on
Collaborative Research. CASCON,
2009, 164-173.
SHARP, H.; ROBINSON, H.; SEGAL,

J.; FURNISS, D. The Role of Story
Cards and the Wall in XP teams: A
prs1530 2006 IEEE Distributed Cognition Perspective.
Agile Conference. AGILE, 2006, 65-
75.
CHAMBERLAIN, S.; SHARP, H.;

MAIDEN, N. Towards a Framework
for Integrating Agile Development
and User-Centred Design. Agile
Scopus, ISI, El
prs1562 2006 Processes in Software Engineering
Compendex
Volume 4044, 143-153.
HOSSAIN, E.; BABAR, M. A.;

VERNER, J. Towards a Framework
for Using Agile Approaches in Global
Scopus, SpringerLink, Software Development. Product-
prs1564 2009 Focused Software Process
El Compendex
Improvement. Lecture Notes in
2009, Volume 32, Part 4, 126-140.
237
LI, J.; MOE, N. B.; DYBÅ, T.
Transition from a Plan-Driven
Process to Scrum – A Longitudinal
ACM, El Compendex, Case Study on Software Quality.
prs1583 2010 ACM-IEEE International Symposium
ESEM, Scopus
on Empirical Software Engineering
and Measurement. ESEM, 2010,
Article No. 13.
MOE, N. B.; AURUM, A.

Understanding Decision-Making in
Scopus, IEEE, El Agile Software Development: a Case-
prs1594 2008 study. Euromicro Conference
Compendex
Software Engineering and Advanced

T. Understanding Self-organizing
El Compendex, IEEE, Teams in Agile Software
prs1595 2008 Development. Australian Conference
Scopus
on Software Engineering. ASWEC,
2008, 76-85.
MOE, N. B.; DINGSØYR, T.;

KVANGARDSNES, Ø. Understanding
El Compendex, IEEE, Shared Leadership in Agile
prs1596 2009 Development: A Case Study. Hawaii
Scopus
Sciences. HICSS, 2009, 1-10.
BEGEL A.; NAGAPPAN, N. Usage

and Perceptions of Agile Software
Development in an Industrial Context:
El Compendex, ESEM, An Exploratory Study. ACM-IEEE
prs1607 2007 International Symposium on
IEEE, Scopus
264.
SISON R.; YANG, T. Use of Agile

Methods and Practices in the
El Compendex, IEEE, Philippines. Asia-Pacific Software
prs1610 2007
Scopus Engineering Conference. APSEC,
2007, 462-469.
ABBAS, N.; GRAVELL, A. M.;
WILLS, G. B. Using Factor Analysis
El Compendex, IEEE, to Generate Clusters of Agile
prs1625 2010 Practices (a Guide for Agile Process
Scopus
Improvement). Agile Conference.
AGILE, 2010, 11-20.
238
COHN, M. L.; SIM, S. E.; LEE, C. P.
What Counts as Software Process?
Negotiating the Boundary of Software
El Compendex, ISI, Work Through Artifacts and
prs1665 2009
Scopus, SpringerLink Conversation. Computer Supported
Cooperative Work, 2009, Volume 18,
Issue 5-6, 401-443.
239
APÊNDICE G – Características dos estudos primários
Tabela 20 – Características dos estudos primários da revisão

Configuração Método de Análise dos Tamanho da amostra
ID Coleta de Dados Método Ágil
do Estudo Pesquisa Dados envolvida
Entrevistas
prs12 Indústria Estudo de caso Qualitativa 03 projetos Scrum
semiestruturadas
Próximo da Estudo de caso, Código fonte do
prs17 Quantitativa - XP
indústria experimento projeto
Entrevistas, Questionário: 08
prs18 Governo Estudo de caso observações e Qualitativa respondentes XP
questionários Entrevistas: não definido
Entrevistas
semiestruturadas e
prs27 Indústria Estudo de caso Qualitativa 33 entrevistas Scrum, XP
estudos empíricos da
literatura
151 equipes de
Aplicação de
prs35 Indústria Survey Qualitativa desenvolvimento de General
questionários
software
Estudo de caso
prs44 Indústria Observações Etnografia 04 equipes XP
exploratório
Observação
participante,
Estudo de caso Análise
prs49 Indústria entrevistas 08 entrevistados Scrum, XP
exploratório Hermenêutica
semiestruturadas e
discussões informais
240
P1: Agile
Software
prs56 Indústria Estudo de caso - - 02 projetos investigados Solution
Framework
P2: XP
Entrevistas
prs123 Indústria Estudo de caso - - DSDM
semiestruturadas
XP
408 respondentes de 109 Scrum
prs129 Indústria Survey Questionário - projetos ágeis de 25 Feature driven
países development
Crystal
60 observações e 17
Documentos, entrevistas (quatorze
prs135 Indústria Estudo de caso entrevistas e - desenvolvedores, dois Scrum
observações Scrum Masters e um
Product Owner)
Métricas de
avaliação de
02 experimentos com 22
prs162 Acadêmico Experimento, survey Código fonte OO, análise XP
participantes
qualitativa dos
dados
Dados históricos do
prs171 Indústria Estudo de caso Quantitativa - Scrum
projeto
prs182 Indústria Pesquisa-ação Observações Qualitativa - Scrum
Entrevistas,
prs230 Acadêmico Pesquisa-ação Qualitativa - XP
observações
Qualitativa,
prs236 Indústria Estudo de caso Entrevistas 18 projetos comerciais Scrum
quantitativa
241
03 projetos:
Questionários, Qualitativa,
prs258 Indústria Estudo de caso desenvolvedores e Scrum, XP
entrevistas quantitativa
gerentes
Aplicação de 376 desenvolvedores
prs275 Indústria Survey Qualitativa General
questionários respondentes
P1: XP (3
Estudo de caso, meses)
prs322 Indústria Questionários - -
survey P2: XP (3
meses)
prs331 Indústria Survey Questionário online Quantitativa - General
59 respondentes: 10
analistas, 11
desenvolvedores, 09
gerentes de projetos, 09
prs346 Indústria Survey Questionário online - gerentes de TI, 06 General
arquitetos de software, 11
clientes, 03 diversos
(testadores, especialistas,
etc.)
prs371 Indústria Estudo de caso Qualitativa - Scrum
projeto
Qualitativo,
prs428 Indústria Estudo de caso Observações - XP
Quantitativo
Qualitativo,
prs430 Indústria Estudo de caso Observação - XP
Quantitativo
10 diferentes empresas de
Aplicação de
prs434 Indústria Survey Quantitativa desenvolvimento de Scrum
questionário
software
242
02 grupos focais: (1)
Grupos focais,
quatro arquitetos de
prs448 Indústria Estudo de caso entrevistas Qualitativa Scrum
software e (2) três
semiestruturadas
gerentes de projetos
05 projetos
Dados históricos do Qualitativo,
prs462 Indústria Estudo de caso XP
projeto Quantitativo 19 sessões de workshop
após as iterações
P1: arquiteto sênior,
desenvolvedor
P2: líder técnico,

desenvolvedores seniores,
Estudos de caso Entrevistas Teoria garantia da qualidade,
prs466 Indústria XP
múltiplos semiestruturadas Fundamentada gerente de projeto
P3: CIO, gerente sênior,

gerente de projeto,
arquiteto, desenvolvedor
sênior, desenvolvedor web
50 pessoas distribuídas
entre os cargos de: líderes
de projetos (20%),
desenvolvedores (37%),
Aplicação de profissionais da garantia
prs469 Indústria Survey - Scrum, XP
questionários da qualidade (10%),
analistas de negócio (6%),
mantenedores de software
(10%) e demais
interessados (17%)
243
Observações e
prs487 Indústria Estudo de caso Qualitativa - XP
entrevistas
prs490 Indústria Estudo de caso Código fonte Quantitativa - Scrum
P1-P7: Scrum
P8: Scrum e XP
P9-P15: Scrum
e XP
P16: Scrum e
XP
P17: Scrum e
XP
P18: Scrum
P19: Scrum e
XP
p20: Scrum e
XP
Entrevistas P21-P27:
Estudo de caso Teoria 40 praticantes ágeis de 16
prs535 Indústria semiestruturadas e Scrum e XP
exploratório Fundamentada organizações de software
observações P28-P31:
Scrum e XP
P32: Scrum e
XP
P33-P36:
Scrum e XP
P37: Scrum e
XP
P38: Scrum e
XP
P39: Scrum e
XP
P40: Scrum e
XP
244
10 membros da equipe e
Entrevistas e
prs564 Acadêmico Estudo de caso Qualitativa 02 representantes do Scrum, Kanban
observações
cliente
prs571 Indústria Estudo de caso - - - XP
Entrevistas 02 equipes
semiestruturadas e P1: XP
prs591 Indústria Estudo de caso Qualitativa
análise de P1: 10 entrevistados P2: tradicional
documentos P2: 04 entrevistados
P1: 23 desenvolvedores
P2: 08 desenvolvedores,
01 designer e 01
Observações,
responsável pela
Estudo de caso anotações, fotos do
prs593 Indústria Etnografia infraestrutura XP
exploratório ambiente e artefatos
do trabalho
P3: 05 desenvolvedores,
um gerente de projetos,
dois analistas de negócios
e um DBA
prs597 Indústria Estudo de caso Entrevistas - 02 organizações Scrum, XP
Entrevistas e 03 desenvolvedores e 01
prs604 Indústria Estudo de caso - Scrum
observações gerente de projeto
Entrevistas, análise de
documentação e Qualitativo e
dados históricos dos Quantitativo
projetos
245
P1: um desenvolvedor, e
Entrevistas três estudantes
prs608 Indústria Estudo de caso semiestruturadas e - Mobile-D
observações P2: duas equipes (4-7
desenvolvedores)
prs610 Indústria Survey Questionário web Quantitativa - Scrum
03 empresas E1: não ágil
E2: XP
Estudo de caso
prs612 Indústria Observação - P1: 03 pessoas E3: se
múltiplo
P2: 7 pessoas consideram
P3: 4 pessoas ágeis
Agile Software
Entrevistas e
prs628 Indústria Estudo de caso - - Solution
observações
Framework
P1: Scrum
P2: Scrum
Entrevistas e análise
prs636 Indústria Estudo de caso - - P3: métodos
de documentos
ágeis
misturados
Entrevistas formais e
prs651 Indústria Estudo de caso - - Scrum, XP
informais
Dados do projeto e
Estudo de caso, Qualitativa,
prs652 Indústria aplicação de 18 respondentes Scrum
survey quantitativa
questionários
Entrevistas e
prs670 Indústria Estudo de caso - - XP
observações
Entrevistas 02 unidades
semiestruturadas organizacionais
246
Entrevistas 07 entrevistas: P1 - 4
semiestruturadas pessoas, P2 - 3 pessoas
Dados históricos dos

prs689 Indústria Estudo de caso projetos e conversas - - Scrum, XP
informais

prs694 Indústria Estudo de caso projetos e - - Scrum, XP
observações
Estudo de caso Entrevistas Teoria
prs700 Indústria 08 empresas Scrum
exploratório semiestruturadas Fundamentada
Acadêmico,
prs702 Estudo de caso Código fonte - 04 desenvolvedores XP
Indústria
Ckmetrics,
análise da
complexidade
Acadêmico, ciclomática, e o
prs703 Estudo de caso Código fonte - Mobile-D
Indústria uso da métrica
para avaliar o
acoplamento
das classes
E1: Entrevistas
semiestruturadas E1: 09 desenvolvedores
E2: todas as
tradicionais
prs705 Indústria Estudo de caso - equipes usam
E2: observações,
XP
anotações, fotos, e E2: 05 equipes ágeis
gravações de áudio
247
Ckmetrics,
análise da
complexidade
Acadêmico, ciclomática, e o
prs706 Estudo de caso Código fonte 04 desenvolvedores XP
Indústria uso da métrica
para avaliar o
acoplamento
das classes
1235 respondentes do
Survey (equipes ágeis e
desejam ser ágeis)
---------------
Análise do
resultado do 119 entrevistados de 04
survey com a equipes da empresa
aplicação do USbase Empresa:
Questionário,
prs710 Indústria Survey Comparative Scrum
entrevistas
Agility (CA), e Equipe 1: 09 pessoas (adaptado)
com a
aplicação e Equipe 2: (1) 12 pessoas
observação survey; (2) 63 pessoas
Equipe 3: 20 pessoas
Equipe 4: 27 pessoas
248
Documentos,
18 respondentes do
entrevistas
prs716 Indústria Estudo de caso - questionário e 09 Scrum
semiestruturadas e
entrevistados
questionários online
15 respondentes do
prs719 Indústria Estudo de caso Questionários - questionário de 02 XP
equipes de pequeno porte
250 profissionais de
Aplicação de software, divididos entre:
prs723 Indústria Survey questionários e - 33% de engenheiros de General
entrevistas software, 38% de
gerentes.
Acadêmico, Dados históricos dos
prs726 Estudo de caso - - XP
Indústria projetos
Questionário, Teoria
entrevistas, Fundamentada,
prs767 Indústria Estudo de caso - XP
observações e código qualitativa e
fonte do projeto quantitativa
Questionário e dados
Estudo de caso,
prs779 Indústria históricos sobre os - - Scrum, XP
survey
defeitos dos projetos
Estudo de caso Entrevistas Teoria

prs793 Indústria 22 pessoas Scrum, XP
exploratório semiestruturadas Fundamentada
249
Entrevistas
semiestruturadas,
prs796 Indústria Estudo de caso questionários, dados - 04 desenvolvedores General
histórico do projeto e
observações
7 projetos: 5 acadêmicos,
2 de instituições
Acadêmico, Entrevistas, Código
prs797 Survey - governamentais XP
Governo fonte e questionários
Total de respostas: 48
Análise do código e
prs804 Acadêmico Experimento Qualitativa 13 equipes de software XP
observações
Menos de 30
desenvolvedores e
Estudo de caso Entrevistas
prs809 Indústria - gerentes General
exploratório estruturadas
10 empresas
Entrevistas face a
face, por telefone,
observações das Teoria
prs813 Indústria Estudo de caso 25 funcionários Scrum, XP
conversas informais e Fundamentada
análise de
documentos
Estatística de defeitos
78 respondentes
dos projetos e Qualitativa e
prs814 Indústria Survey Scrum
aplicação de Quantitativa
3 projetos
questionários
250
prs848 Indústria Survey Questionários online Quantitativa 112 respondentes General
prs879 Indústria Estudo de caso - - Scrum
projeto
Entrevistas Teoria 35 participantes de 10
prs909 Indústria Estudo de caso General
semiestruturadas Fundamentada empresas
Entrevistas
semiestruturadas e
estruturadas, Análise
observações Hermenêutica
participante e análise
de documentos
Entrevistas
semiestruturadas,
prs918 Indústria Estudo de Caso documentação do Qualitativa - Scrum, XP
projeto e conversas
informais
02 projetos: 09
entrevistados
Empresa 01: gerente de

Entrevistas
departamento, gerente de
Estudo de Caso, semiestruturadas,
prs980 Indústria Análise indutiva projeto e 03 XP
Survey questionários e
desenvolvedores
observações
Empresa 02: gerente de
departamento e 03
desenvolvedores
251
Entrevistas Teoria
prs1001 Indústria Estudo de caso 18 entrevistados Scrum, XP
semiestruturadas Fundamentada
Métricas de
Entrevistas
avaliação de
semiestruturadas e
prs1002 Indústria Estudo de caso OO, análise - Scrum, XP
código fonte dos
qualitativa dos
projetos
dados
P1: XP
05 entrevistados: um P2: XP and

especialista em Scrum
Entrevistas
usabilidade, dois
semiestruturadas, Teoria
prs1016 Acadêmico Estudo de caso desenvolvedores, um P3: Scrum
observações e análise Fundamentada
desenvolvedor e gerente
de documentos
de projeto, um gerente de P4: Scrum
projeto
P5: XP and
Scrum
Questionários e Análise
15 desenvolvedores, 15
prs1019 Indústria Survey entrevistas estatística XP
gerentes de 15 empresas
semiestruturadas descritiva
Estudo de caso Análise de 20 postmortems foram
prs1023 Indústria Qualitativa Scrum, XP
múltiplo documentos examinados
03 desenvolvedores, 01
Entrevistas pessoa da avaliação da
prs1037 Indústria Estudo de caso Qualitativa Scrum, XP
semiestruturadas qualidade foram
entrevistadas
252
Entrevistas
semiestruturadas, 12 entrevistas: 11
Governo,
prs1039 Estudo de caso entrevistas abertas e Qualitativa entrevistados (o gerente XP
Indústria
análise de foi entrevistado 02 vezes)
documentos
55 pessoas: arquitetos,
desenvolvedores,
prs1069 Indústria Estudo de caso Questionários Qualitativa XP
gerentes de projeto,
gerentes de produto
Entrevistas
semiestruturadas, 03 desenvolvedores
prs1075 Indústria Estudo de caso - Scrum, XP
observações e entrevistados
conversas informais.
Entrevistas 09 entrevistas, envolvendo

prs1078 Indústria Estudo de caso Qualitativa Scrum
semiestruturadas 08 pessoas
Qualitativo,
Entrevistas
Estudo de caso Quantitativo,
prs1112 Indústria semiestruturadas e - Scrum
múltiplo Análise de
documentos
documentos
Entrevistas 20 entrevistados: Scrum
semiestruturadas, Masters, Product Owners,
prs1114 Indústria Estudo de caso dados histórico do Qualitativa gerentes de Projetos, Scrum
projeto e conversas desenvolvedores, líderes
informais técnicos
Entrevistas Teoria
prs1132 Indústria Estudo de caso 22 entrevistados XP
semiestruturadas Fundamentada
253
Documentos,
prs1133 Indústria Estudo de caso questionários e Qualitativa 02 equipes XP
observações
Entrevistas 03 entrevistados: cliente,
prs1136 Indústria Estudo de caso Qualitativa XP
estruturadas desenvolvedor, testador
22 pessoas de quatro
empresas: três gerentes
de negócio, um arquiteto
de software, um líder de
Entrevistas,
teste, cinco Scrum
prs1166 Acadêmico Estudo de caso observações, dados Qualitativa Scrum
Masters, dois designers,
históricos dos projetos
um Product Owner, quatro
desenvolvedores, dois
avaliadores da qualidade e
dois designers gráficos.
10 entrevistados: quatro
consultores, dois
prs1170 Indústria Estudo de caso Entrevistas Qualitativa desenvolvedores, Scrum, XP
dois Scrum Master, um
Product Owner e um CEO
Empresa A1: 12
entrevistados, 75
observações
Empresa A2: 12
Entrevistas,
entrevistados, 45
observações e
prs1173 Indústria Estudo de caso Meta-etnografia observações Scrum
documentos do
Empresa B: 13
projeto
entrevistados, 09
observações
Empresa C1: 11
entrevistados, 10
254
observações
Empresa C2: 10
entrevistados, 10
observações
Aplicação de
prs1193 Indústria Survey Qualitativa 62 empresas General
Questionários online

prs1208 Indústria Estudo de caso - 01 projeto XP
projetos
Estudo de caso,
prs1212 Indústria Observações - - General
Pesquisa-ação
Acadêmico,
prs1238 Pesquisa-ação Entrevistas - 17 entrevistados Scrum
Indústria
15 pessoas respondentes,
Aplicação de entre eles:
prs1256 Governo Estudo de caso Qualitativa XP
questionários programadores, analistas,
testadores, e gerentes
Aplicação de
questionários,
prs1260 Indústria Survey entrevistas pelo - 72 entrevistas General
telefone e dados
histórico dos projetos
56 projetos de software:
prs1271 Indústria Survey Questionário - XP
509 desenvolvedores
255
60 observações (Daily
meetings, Sprint Planning,
Review, Retrospective) e
Entrevistas,
prs1296 Indústria Estudo de caso Etnografia 22 entrevistas (vinte Scrum
Observações
desenvolvedores, um
Scrum Master e um
Product Owner)
Entrevistas
semiestruturadas,
observações
prs1300 Indústria Estudo de caso - - Scrum
participantes,
questionários e dados
históricos do projeto
Observações e
prs1301 Indústria Estudo de caso Etnografia - Scrum
registro diário
05 equipes co-alocadas,
Estudo de caso, Entrevistas e Extensão do
prs1335 Indústria - com a média de 09
pesquisa-ação observações Scrum
integrantes por equipe
Questionário e dados
prs1352 Acadêmico Estudo de caso histórico sobre dos - - XP
projetos
Observações e coleta
Estudo de caso Teoria
prs1363 Indústria de dados histórico dos - Scrum
exploratório Fundamentada
projetos
Entrevistas e 10 desenvolvedores de
observações software
03 entrevistas (analista de
prs1398 Indústria Estudo de caso Entrevistas - XP
sistemas)
256
Survey: 25 respostas de
18 empresas
Questionários
prs1491 Indústria Survey - Scrum
entrevistas Entrevistas: 03 Scrum
Masters/desenvolvedores
e 03 testadores
Entrevistas 06 entrevistas: dois

semiestruturadas, desenvolvedores, dois P1: Scrum, XP
prs1497 Indústria Estudo de caso Qualitativa
observações e análise líderes de projetos e dois P2: Scrum, XP
de documentos engenheiros da qualidade
Entrevistas,
Acadêmico, Quantitativa e 17 equipes de
prs1500 Experimento observações e XP
Indústria Qualitativa desenvolvimento
questionários
06 empresas de
Entrevistas, desenvolvimento de
Estudo de caso
prs1510 Indústria observações e - software XP
exploratório
questionários
E1: 10 desenvolvedores
prs1525 Indústria Estudo de caso Observação Qualitativa - Scrum
prs1530 Indústria Estudo de caso Observações Qualitativa - XP
Observações, 14 observações, 10
prs1562 Indústria Estudo de Caso Qualitativa Scrum, XP
entrevistas entrevistas
Entrevistas,
documentação do
prs1564 Indústria Estudo de caso Qualitativa - Scrum
projeto e conversas
informais
257
09 entrevistas: quatro
Entrevistas
vezes com o mesmo
semiestruturadas,
Quantitativa e gerente de projeto e cinco
prs1583 Indústria Estudo de caso observações Scrum
Qualitativa entrevistas com cada um
participante e análise
dos desenvolvedores da
de documentos
equipe
Observação
Estudo de caso participante e
prs1594 Indústria Qualitativa 02 empresas Scrum
múltiplo entrevistas
semiestruturadas
prs1595 Indústria Pesquisa-ação Etnografia - Scrum

Observações
Observações,
entrevistas 04 entrevistas: três
prs1596 Indústria Estudo de caso semiestruturada e Etnografia desenvolvedores e um Scrum
análise de Scrum Master
documentos
492 respondentes:
prs1607 Indústria Survey Questionários online Quantitativa desenvolvedores, Scrum, XP
testadores e gerentes
Questionários,
51 empresas, entre as Case 1: XP
entrevistas e
prs1610 Indústria Survey Qualitativa quais 02 utilizavam um
documentos históricos
método ágil. Case 2: Scrum
do projeto
prs1625 Indústria Survey Questionários online Quantitativa 781 respondentes General
258
02 empresas
15 entrevistas: presidente
Entrevistas e da empresa,
prs1665 Indústria Estudo de caso Qualitativa Scrum
observações administrador, treinador,
pessoal de marketing,
desenvolvedores, Product
Owners e Scrum Masters
259
APÊNDICE H – Resultado da Avaliação da Qualidade dos Estudos Primários
Tabela 21 – Resultado da Avaliação da Qualidade dos Estudos Primários

ID do paper Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Pontuação Resultado
Total
prs12 1 1 1 1 0 1 1 0 1 1 8 Alta
prs17 1 1 0 0 0 1 1 1 1 1 7 Alta
prs18 1 0 1 0 0 1 1 0 1 0 5 Média
prs27 1 1 1 1 0 1 1 1 1 1 9 Muito Alta
prs35 1 1 0 1 0 1 1 0 1 1 7 Alta
prs44 1 1 0 1 0 1 0 0 0 1 5 Média
prs49 1 1 1 1 0 1 1 0 1 1 8 Alta
prs56 1 1 0 1 0 1 1 0 0 1 6 Alta
prs123 1 1 0 0 0 1 1 0 1 0 5 Média
prs129 1 1 0 0 0 1 1 0 1 1 6 Alta
prs135 1 1 1 1 0 1 1 1 1 1 9 Muito Alta
prs162 1 0 0 0 1 1 1 0 1 0 5 Média
prs171 1 1 0 0 0 0 0 0 1 1 4 Média
prs182 1 1 1 0 0 1 1 0 1 1 7 Alta
prs230 1 1 1 0 0 1 1 0 0 1 6 Alta
prs236 1 1 1 0 0 1 1 0 1 1 7 Alta
prs258 1 1 0 0 0 1 0 0 1 0 4 Média
prs275 1 1 0 0 0 1 1 0 1 1 6 Alta
prs322 1 1 1 1 1 1 1 0 0 1 8 Alta
prs331 1 0 0 1 0 1 1 0 0 1 5 Média
prs346 1 1 1 1 1 1 0 0 1 1 8 Alta
260
prs371 1 1 0 0 0 0 1 0 0 1 4 Média
prs428 1 1 1 0 0 1 1 0 0 1 6 Alta
prs430 1 1 0 0 1 0 1 0 1 1 6 Alta
prs434 1 1 0 1 0 1 1 0 1 1 7 Alta
prs448 1 1 1 0 0 1 1 0 1 1 7 Alta
prs462 1 0 1 0 1 1 1 0 1 1 7 Alta
prs466 1 1 0 0 0 1 0 0 1 1 5 Média
prs469 1 0 0 0 0 1 0 0 1 1 4 Média
prs487 1 1 0 0 0 0 0 0 0 1 3 Média
prs490 1 1 0 0 1 1 0 0 0 1 5 Média
prs535 1 1 1 1 0 1 1 1 1 1 9 Muito Alta
prs564 1 1 0 0 0 1 0 0 1 0 4 Média
prs571 1 1 0 0 0 0 0 0 0 1 3 Média
prs591 1 1 1 1 1 1 1 0 1 1 9 Muito Alta
prs593 1 1 1 0 0 1 1 0 0 1 6 Alta
prs597 1 1 0 1 0 1 1 0 1 0 6 Alta
prs604 1 1 1 0 0 1 1 0 1 1 7 Alta
prs606 1 1 0 1 0 1 1 0 1 0 6 Alta
prs608 1 1 0 0 0 1 1 0 1 1 6 Alta
prs610 1 1 0 1 1 1 1 1 1 1 9 Muito Alta
prs612 1 1 0 0 1 1 1 0 1 1 7 Alta
prs628 1 1 0 0 0 1 1 0 0 1 5 Média
prs636 1 0 0 0 1 1 0 0 1 1 5 Média
prs651 1 1 1 1 0 1 1 0 1 1 8 Alta
prs652 1 1 0 0 0 0 1 0 0 1 4 Média
prs670 1 0 0 0 0 1 0 0 0 1 3 Média
prs687 1 1 0 0 0 1 1 0 1 1 6 Alta
261
prs688 1 1 0 0 0 1 1 0 1 1 6 Alta
prs689 1 1 0 0 1 1 1 0 0 1 6 Alta
prs694 1 1 0 0 0 0 1 0 0 1 4 Média
prs700 1 1 0 1 0 1 1 1 1 1 8 Alta
prs702 1 1 1 1 1 1 1 0 1 1 9 Muito Alta
prs703 1 1 1 0 1 1 1 0 1 1 8 Alta
prs705 1 0 0 0 1 1 1 0 1 1 6 Alta
prs706 1 1 0 0 0 1 1 0 1 1 6 Alta
prs710 1 1 0 0 0 1 1 0 0 1 5 Média
prs716 1 1 0 0 0 1 1 0 0 1 5 Média
prs719 1 1 0 0 0 1 1 0 0 1 5 Média
prs723 1 0 1 0 0 1 1 0 1 1 6 Alta
prs726 1 1 0 0 0 1 1 0 1 1 6 Alta
prs767 1 1 1 0 0 1 1 0 1 1 7 Alta
prs779 1 1 0 0 1 1 1 0 1 1 7 Alta
prs793 1 0 0 0 0 0 1 0 0 1 3 Média
prs796 1 1 0 1 0 1 1 1 1 1 8 Alta
prs797 1 1 0 0 0 1 1 0 0 1 5 Média
prs804 1 1 1 1 1 1 0 0 1 0 7 Alta
prs809 1 1 1 0 0 1 0 0 1 1 6 Alta
prs813 1 1 1 0 0 1 1 0 1 1 7 Alta
prs814 1 1 0 1 1 1 1 0 0 1 7 Alta
prs848 1 1 0 1 0 1 0 0 0 1 5 Média
prs879 1 1 0 0 0 0 0 0 1 0 3 Média
prs909 1 1 0 0 0 1 1 0 1 1 6 Alta
prs910 1 1 0 0 1 1 1 0 0 1 6 Alta
prs918 1 1 1 0 0 1 0 0 1 1 6 Alta
262
prs980 1 1 1 0 0 1 1 1 1 1 8 Alta
prs1001 1 1 1 0 0 1 1 0 1 0 6 Alta
prs1002 1 1 0 0 1 1 1 0 1 0 6 Alta
prs1016 1 1 1 1 0 1 1 0 1 1 8 Alta
prs1019 1 1 1 0 0 1 1 0 1 1 7 Alta
prs1023 1 1 1 1 0 1 1 0 1 1 8 Alta
prs1037 1 1 0 0 0 1 1 0 1 1 6 Alta
prs1039 1 1 0 1 0 1 1 0 0 0 5 Média
prs1069 1 1 0 0 0 1 0 0 1 0 4 Média
prs1075 1 1 0 0 0 1 0 0 1 0 4 Média
prs1078 1 1 1 1 0 1 1 1 1 1 9 Muito Alta
prs1112 1 1 0 0 0 1 1 0 0 1 5 Média
prs1114 1 1 0 0 0 1 1 0 1 1 6 Alta
prs1132 1 0 1 1 0 1 1 0 1 1 7 Alta
prs1133 1 1 1 1 0 1 1 0 1 1 8 Alta
prs1136 1 1 0 0 0 1 0 0 0 0 3 Média
prs1166 1 1 0 0 0 1 1 0 1 1 6 Alta
prs1170 1 1 0 0 0 1 0 0 1 0 4 Média
prs1173 1 1 1 0 0 1 1 0 1 1 7 Alta
prs1193 1 1 1 0 0 1 1 0 1 1 7 Alta
prs1208 1 1 0 0 0 0 1 0 1 1 5 Média
prs1212 1 1 1 0 0 0 1 0 1 1 6 Alta
prs1238 1 1 0 0 0 1 0 0 1 1 5 Média
prs1256 1 1 1 0 0 1 1 0 1 0 6 Alta
prs1260 1 1 0 0 0 1 1 0 1 1 6 Alta
prs1271 1 1 0 0 0 1 1 0 1 1 6 Alta
prs1296 1 1 0 0 0 1 1 0 1 1 6 Alta
263
prs1300 1 1 1 0 0 1 0 0 1 1 6 Alta
prs1301 1 1 0 0 0 1 1 1 1 1 7 Alta
prs1335 1 1 1 1 0 1 0 0 1 1 7 Alta
prs1352 1 1 0 0 1 0 1 0 0 1 5 Média
prs1363 1 1 1 0 0 0 0 0 1 1 5 Média
prs1371 1 1 0 0 0 1 0 0 1 1 5 Média
prs1398 1 0 0 0 1 1 1 0 1 0 5 Média
prs1491 1 1 1 0 1 1 0 0 1 0 6 Alta
prs1497 1 1 1 0 0 1 1 1 1 1 8 Alta
prs1500 1 1 0 0 1 1 1 0 1 1 7 Alta
prs1510 1 1 0 0 0 1 1 0 1 1 6 Alta
prs1525 1 1 0 0 0 0 1 0 1 1 5 Média
prs1530 1 1 0 0 0 1 1 0 1 1 6 Alta
prs1562 1 1 1 1 0 1 1 0 1 1 8 Alta
prs1564 1 1 1 1 0 1 1 0 1 1 8 Alta
prs1583 1 1 1 1 1 1 1 0 1 1 9 Muito Alta
prs1594 1 1 1 1 0 1 1 0 1 1 8 Alta
prs1595 1 1 0 0 0 1 1 0 1 1 6 Alta
prs1596 1 0 0 0 0 1 1 0 1 1 5 Média
prs1607 1 1 0 0 1 1 0 1 1 1 7 Alta
prs1610 1 1 0 0 0 1 1 0 1 1 6 Alta
prs1625 1 0 0 0 0 0 1 0 1 0 3 Média
prs1665 1 1 0 1 0 1 1 0 1 1 7 Alta
264
APÊNDICE I – Benefícios identificados nos
estudos primários
Tabela 22 – Benefícios identificados nos estudos primários
Quanti
dade %
ID Descrição Benefício Estudos primários
estudo Total
s
prs27, prs44, prs49, prs56,
prs182, prs322, prs331, prs466,
prs535, prs564, prs571, prs591,
Facilita o
prs593, prs604, prs606, prs651,
compartilhamento do
B1 prs670, prs689, prs694, prs705, 32 25,60%
conhecimento entre a
prs710, prs719, prs796, prs879,
equipe
prs1001, prs1019, prs1039,
prs1075, prs1497, prs1530,
prs1583, prs1610
prs428, prs448, prs469, prs490,
prs591, prs608, prs612, prs651,
prs652, prs688, prs694, prs719,
Melhora a comunicação
B2 prs796, prs910, prs918, prs980, 31 24,80%
da equipe
prs1001, prs1019, prs1037,
prs1136, prs1296, prs1491,
prs1497, prs1525, prs1583,
prs1607, prs1665
prs466, prs564, prs591, prs593,
prs636, prs651, prs652, prs705,
Facilita o prs710, prs716, prs719, prs767,
acompanhamento e prs793, prs797, prs879, prs910,
B3 26 20,80%
monitoramento do prs918, prs980, prs1019,
projeto prs1039, prs1133, prs1300,
prs1371, prs1497, prs1530,
prs1607
prs591, prs670, prs689, prs793,
prs879, prs980, prs1001,
Feedback
B4 prs1016, prs1019, prs1023, 23 18,40%
rápido/frequente
prs1037, prs1038, prs1039,
prs1133, prs1136, prs1256,
prs1583, prs1607, prs1610
prs331, prs448, prs466, prs571,
Melhora a qualidade do
B5 prs651, prs702, prs703, prs706, 22 17,60%
código
prs796, prs1001, prs1002,
prs1019, prs1037, prs1038,
265
prs1075, prs1078, prs1136,
prs1607

Permite uma maior prs591, prs593, prs597, prs651,
B6 colaboração entre a prs716, prs719, prs793, prs879, 17 13,60%
equipe prs918, prs1037, prs1132,
prs1596, prs1610

Aumenta a prs689, prs710, prs716, prs797,
B7 14 11,20%
produtividade da equipe prs910, prs1037, prs1038,
prs1491, prs1607, prs1610
Melhora a comunicação prs18, prs49, prs448, prs593,

entre o cliente (ou prs606, prs767, prs918, prs980,
B8 14 11,20%
representante) e a prs1136, prs1491, prs1497,
equipe prs1562, prs1594, prs1625

Entrega frequente de prs331, prs434, prs628, prs909,
B9 14 11,20%
software funcional prs1016, prs1039, prs1132,
prs1133, prs1491, prs1610

Melhora a qualidade do prs688, prs689, prs723, prs980,
B10 13 10,40%
projeto prs1193, prs1564, prs1583,
prs1607, prs1610

prs466, prs612, prs1001,
B11 Reduz a documentação 13 10,40%
prs1039, prs1078, prs1114,
prs1497, prs1530, prs1665

Reduz a complexidade prs651, prs702, prs703, prs918,
B12 13 10,40%
do código/projeto prs1002, prs1019, prs1078,
prs1133, prs1398

Reduz a quantidade de prs651, prs779, prs796, prs814,
B13 13 10,40%
defeitos/erros no projeto prs1002, prs1078, prs1271,
prs1352, prs1583
Melhora o entendimento prs767, prs918, prs980,
B14 11 8,80%
sobre o projeto prs1132, prs1136, prs1583,
prs1594
prs462, prs612, prs535, prs793,
Facilita a interação entre
B15 prs918, prs1039, prs1132, 10 8,00%
a equipe
prs1136, prs1525, prs1610
266
Facilita a resolução de
B16 prs689, prs716, prs1132, 10 8,00%
problemas
prs1371, prs1497, prs1525
prs182, prs331, prs535, prs716,
Aumenta o envolvimento
B17 prs793, prs1038, prs1132, 10 8,00%
da equipe no projeto
prs1398, prs1594, prs1665
Torna eficiente a prs56, prs428, prs490, prs628,
B18 resposta às mudanças prs910, prs1078, prs1491, 9 7,20%
de requisitos prs1607, prs1665
prs462, prs535, prs564, prs716,
Melhora o processo de
B19 prs793, prs797, prs1023, 9 7,20%
desenvolvimento
prs1363, prs1564
Permite uma maior
B20 prs918, prs1136, prs1497, 8 6,40%
transparência do projeto
prs1530
prs129, prs135, prs628, prs651,
Aumenta a motivação da
B21 prs688, prs1038, prs1132, 8 6,40%
equipe
prs1500
prs182, prs466, prs636, prs716,
Problemas são
B22 prs918, prs980, prs1594, 8 6,40%
descobertos mais cedo
prs1607
prs135, prs462, prs610, prs652,
Aumenta a satisfação da
B23 prs1038, prs1132, prs1500, 8 6,40%
equipe
prs1594
Melhora o planejamento prs27, prs591, prs670, prs689,
B24 e gerenciamento do prs793, prs918, prs1019, 8 6,40%
projeto prs1594
prs129, prs434, prs710, prs910,
Melhora a priorização
B25 prs1016, prs1114, prs1594, 8 6,40%
dos requisitos
prs1607
Aumenta a satisfação do prs236, prs346, prs466, prs689,

B26 7 5,60%
cliente prs723, prs1016, prs1019
Torna o ambiente mais prs535, prs628, prs651, prs793,

B27 7 5,60%
agradável prs1001, prs1132, prs1607
Aumenta a coesão da prs44, prs171, prs535, prs918,
B28 6 4,80%
equipe prs1132, prs1371
Aumenta a confiança da prs793, prs918, prs980,
B29 6 4,80%
equipe prs1037, prs1398, prs1607
Reduz o tempo de
B30 desenvolvimento do 6 4,80%
prs571, prs1019
projeto
Melhora o entendimento prs129, prs462, prs767,

B31 6 4,80%
das histórias de usuários prs1037, prs1497, prs1594
Aumenta as chances de prs18, prs129, prs628, prs1260,

B32 5 4,00%
sucesso do projeto prs1625
267
Melhora a cobertura de prs1001, prs1002, prs1136,
B33 5 4,00%
testes prs1491, prs1607
Reduz a interferência prs135, prs1491, prs1583,
B34 5 4,00%
externa prs1594, prs1595
Permite a correção prs688, prs779, prs814,
B35 5 4,00%
rápida dos defeitos/erros prs1078, prs1583
Permite a revisão prs322, prs1001, prs1019,
B36 4 3,20%
contínua do código prs1497
Melhora as habilidades prs980, prs1019, prs1023,
B37 4 3,20%
técnicas prs1037
Metas e Problemas
B38 prs44, prs135, prs710, prs1491 4 3,20%
compartilhados
Aplicável a diferentes
B39 prs56, prs236, prs628, prs688 4 3,20%
contextos de projetos
Permite a identificação prs779, prs1133, prs1136,
B40 4 3,20%
rápida de defeitos/erros prs1583
Aumenta a moral da prs651, prs716, prs1491,
B41 4 3,20%
equipe prs1607
Aumenta a visibilidade
B42 prs535, prs564, prs716, prs918 4 3,20%
do projeto
Aumenta a autonomia
B43 prs49, prs564, prs1037, prs1038 4 3,20%
da equipe
B44 Reduz o retrabalho prs18, prs27, prs466 3 2,40%
Reduz os custos do
B45 prs56, prs1019, prs1607 3 2,40%
projeto
Permite uma maior
B46 discussão sobre o prs688, prs716, prs1530 3 2,40%
projeto
B47 Processo menos formal prs652, prs1001, prs1607 3 2,40%
Aumenta a
B48 prs716, prs723, prs1078 3 2,40%
confiabilidade do projeto
Facilita a estimativa das
B49 prs27, prs591, prs1497 3 2,40%
tarefas
Melhora a capacidade
B50 de coordenação da prs719, prs1594, prs1607 3 2,40%
equipe
Melhora a sinergia entre
B51 prs1019, prs1398, prs1564 3 2,40%
os envolvidos no projeto
Permite a padronização
B52 prs466, prs918 2 1,60%
do código
Enfatiza informações
B53 importantes sobre o prs564, prs705 2 1,60%
projeto
Facilita o
B54 desenvolvimento das prs628, prs1497 2 1,60%
atividades
Melhora a identificação
B55 prs123, prs1352 2 1,60%
e gerenciamento dos
268
riscos
Melhora a compreensão
B56 prs171, prs797 2 1,60%
sobre o processo
Melhora a estimativa de
B57 prs430, prs726 2 1,60%
esforço do projeto
Entrega de software no
B58 prs651, prs652 2 1,60%
prazo
Aumenta a pró-atividade
B59 prs793, prs1525 2 1,60%
da equipe
Aumenta o
B60 comprometimento da prs56, prs535 2 1,60%
equipe com o projeto
Torna as reuniões
B61 prs44, prs651 2 1,60%
produtivas
Facilita a entrada de
B62 novos membros no prs571, prs651 2 1,60%
projeto
Permite uma maior
B63 prs716, prs1665 2 1,60%
adaptabilidade
Aumenta a
B64 responsabilidade da prs135, prs628 2 1,60%
equipe
Simplicidade em manter
B65 prs1019 1 0,80%
histórias de usuários
B66 Flexibilidade do Design prs1607 1 0,80%
B67 Estimula a criatividade prs1023 1 0,80%
Facilita a definição das
B68 prs462 1 0,80%
tarefas
Facilita o
B69 desenvolvimento de prs796 1 0,80%
atividades complexas
Reduz a volatilidade dos
B70 prs27 1 0,80%
requisitos
Reduz o impacto de
B71 prs652 1 0,80%
riscos no projeto
B72 Foco sobre o produto prs1023 1 0,80%
Reduz o nível de
B73 prs1500 1 0,80%
ansiedade
Boas práticas de
B74 prs1023 1 0,80%
gerenciamento
Melhora o retorno sobre
B75 prs236 1 0,80%
o investimento
Alto nível de controle de
B76 prs428 1 0,80%
complexidade
Provê melhorias nas
B77 tomadas de decisões do prs612 1 0,80%
projeto
269
Reduz os custos das
B78 prs469 1 0,80%
mudanças
Reduz o desperdício de
B79 prs27 1 0,80%
trabalho não utilizado
270
APÊNDICE J – Limitações identificadas nos
estudos primários
Tabela 23 – Limitações identificadas nos estudos primários

Quantida
ID Descrição Limitação Estudos primários de % Total
estudos
prs17, prs123, prs129,
prs236, prs322, prs346,
prs428, prs434, prs448,
prs452, prs462, prs535,
prs591, prs597, prs608,
prs610, prs612, prs651,
prs687, prs688, prs689,
Falta de estudos empíricos prs700, prs703, prs723,
L1 38 29,92%
com os métodos ágeis
prs767, prs793, prs809,
prs1019, prs1112,
prs1296, prs1301,
prs1335, prs1363,
prs1497, prs1583,
prs1607, prs1610,
prs1625
prs236, prs652, prs1173,
Dificuldade de trabalhar
prs1296, prs1301,
L2 com individualismo e 13 10,24%
prs1335, prs1497,
especializações
prs1595, prs1607,
prs1665
prs612, prs628, prs688,
L3 Aspectos culturais prs689, prs793, prs1069, 12 9,45%
prs1596, prs1607,
prs1665
Dificuldade em aplicar prs16, prs18, prs448,
práticas ágeis com equipes prs462, prs767, prs813,
L4 9 7,09%
inexperientes em Métodos prs1002,
Ágeis prs1019, prs1607
prs346, prs371, prs597,
Dificuldade de se trabalhar
L5 prs687, prs980, prs1212, 8 6,30%
com equipes não ágeis
prs1497, prs1607
Falta de informações
prs135, prs230, prs813,
históricas, relatórios e
L6 prs910, prs1069, 7 5,51%
métricas para apoiar o
prs1112, prs1607
gerenciamento
Dificuldade de
comunicação / prs12, prs129, prs571,
L7 5 3,94%
coordenação entre equipes prs689, prs1019, prs1112
distribuídas
L8 Dificuldade de prs49, prs651, prs705, 5 3,94%
271
programação em par prs1001, prs1019
Dificuldade em trabalhar prs12, prs448, prs1301,
L9 5 3,94%
com limite de tempo prs1497, prs1583
Aumenta a pressão para prs710, prs813, prs1037,
L10 4 3,15%
entrega do trabalho prs1583
Aumenta os custos do prs571, prs809, prs1001,
L11 4 3,15%
projeto prs1625
Dificuldade de se adaptar prs35, prs135, prs1238,
L12 4 3,15%
a constantes mudanças prs1260
Dificuldade para se
prs27, prs1037, prs1133,
L13 trabalhar com equipes 4 3,15%
prs1607
grandes
Falta de planejamento de prs652, prs910, prs980,
L14 4 3,15%
longo prazo prs1595
L15 Pouca documentação 3 2,36%
prs1665
Aumenta o tempo de
L16 desenvolvimento das prs322, prs1002, prs1078 3 2,36%
atividades
Encontrar apoio da gestão
L17 para utilizar as práticas prs371, prs809, prs980 3 2,36%
ágeis
Exige mudança de
L18 prs1001, prs322, prs809 3 2,36%
mentalidade
Pouco foco sobre a
L19 prs27, prs716, prs910 3 2,36%
arquitetura de software
Dificuldade de gerenciar
L20 requisitos dependentes prs1363, prs1497 2 1,57%
utilizando apenas o quadro
L21 prs1607, prs1665 2 1,57%
com código legado
Dificuldade em
L22 implementar a técnica de prs1019, prs1078 2 1,57%
TDD
Dificuldade em reduzir a
L23 Documentação com o uso prs1114, prs1610 2 1,57%
de Modelos de Maturidade
Dificuldade para definir
L24 prs1596, prs371 2 1,57%
uma tarefa como Pronta
Falta de planejamento
L25 mais abrangente no início prs1607, prs462 2 1,57%
do projeto/iteração
Histórias e tarefas são
L26 prs1166, prs1363 2 1,57%
poucas especificadas
Insatisfação do cliente com
L27 o constante envolvimento prs236, prs346 2 1,57%
dele no projeto
Necessidade de
L28 experiência e habilidade prs1019, prs1078 2 1,57%
técnica
Necessidade de maior
L29 performance nos prs1001, prs371 2 1,57%
computadores
Necessita de Maturidade e
L30 prs535, prs705 2 1,57%
pro-atividade
272
Possuir mais de um
interessado com poder de
L31 prs1075, prs910 2 1,57%
decisão sobre os requisitos
e prioridades
Adaptar os métodos ágeis
para projetos em tempo
real, softwares
L32 prs371 1 0,79%
embarcados, ou que
envolvam
hardware/firmware
Aumenta o esforço da
L33 prs27 1 0,79%
gerência de configuração
Aumenta o acoplamento
L34 prs703 1 0,79%
entre as classes
Aumenta o erro de
L35 estimativa em tarefas prs430 1 0,79%
maiores
Aumenta o número de
L36 prs1002 1 0,79%
classes
Aumenta o número de
L37 prs428 1 0,79%
linhas de código
Aumenta o tempo das
L38 prs12 1 0,79%
reuniões
Difícil de ser utilizado em
L39 prs49 1 0,79%
projetos complexos
Dificuldade de adoção da
L40 programação em par para prs1019 1 0,79%
empresas pequenas
Dificuldade de adoção de
L41 prs1133 1 0,79%
Testes Unitários
Dificuldade de apresentar
algo funcional em projetos
L42 prs1238 1 0,79%
que não possuem interface
gráfica
Dificuldade de estimar
L43 atividades de domínio prs767 1 0,79%
desconhecido
Dificuldade de estimar
L44 histórias que possuem prs448 1 0,79%
dependências
Dificuldade de se
L45 concentrar com equipes prs1497 1 0,79%
colocalizadas
Dificuldade em apresentar
a review com enormes
L46 prs1497 1 0,79%
quantidades de
funcionalidades prontas
Dificuldade em escrever
L47 prs135 1 0,79%
histórias de usuário
Dificuldade em lidar com
L48 os clientes que gostam de prs1665 1 0,79%
documentação abrangente
Dificuldade em realizar
L49 constantes commit's em prs1301 1 0,79%
iterações curtas
273
Dificuldade em trabalhar
L50 em domínios prs448 1 0,79%
desconhecidos
Falta a definição do que é
L51 o Valor de Negócio em prs700 1 0,79%
projetos Ágeis
Falta de ferramentas
L52 eficazes (TDD, prs1019 1 0,79%
refatoração)
Falta de Gerenciamento de
L53 prs1170 1 0,79%
Riscos
Falta de identificação das
L54 prs705 1 0,79%
contribuições individuais
Falta de um guia detalhado
explicando com detalhes
L55 prs1019 1 0,79%
uma refatoração de
sucesso
Falta ênfase na
L56 prs1625 1 0,79%
comunicação com o cliente
Fazer o mais simples pode
L57 levar a códigos de difícil prs705 1 0,79%
leitura
Ineficiente para corrigir
L58 erros que são difíceis de prs1078 1 0,79%
reproduzir
Muito formalismo nas
L59 reuniões pode inibir uma prs1166 1 0,79%
boa comunicação
Necessidade de apoio do
cliente para apoiar a
L60 prs1208 1 0,79%
implantação do método
ágil
Necessita de muito esforço
L61 para realizar a integração prs27 1 0,79%
contínua
Necessita de um ambiente
L62 bastante adequado para o prs1069 1 0,79%
time
Sobrecarga de
L63 gerenciamento (muitas prs27 1 0,79%
reuniões)
274
APÊNDICE K – Benefícios identificados nos
estudos de caso
Tabela 24 – Benefícios identificados nos estudos de caso
Qtd
Descrição do %
ID Entrevistado / Projeto entrevistad
Benefício Total
os
ALFA_P1_E1, ALFA_P1_E2,
BETA_P1_E1, BETA_P1_E2,
Facilita o
acompanhamento e
B1_EC BETA_P1_E5, BETA_P1_E6, 21 95,45%
monitoramento do
projeto
BETA_P2_E8
Facilita o ALFA_P1_E5, BETA_P1_E1,
compartilhamento do BETA_P1_E3, BETA_P1_E4,
B2_EC 15 68,18%
conhecimento entre BETA_P1_E5, BETA_P1_E6,
a equipe BETA_P1_E7, BETA_P2_E4,
BETA_P2_E7
Melhora o ALFA_P1_E6, BETA_P1_E6,
B3_EC entendimento das BETA_P1_E7, BETA_P2_E1, 14 63,64%
histórias de usuários BETA_P2_E2, BETA_P2_E3,
BETA_P2_E7, BETA_P2_E8
ALFA_P1_E7, BETA_P1_E3,
Facilita a interação
entre a equipe
275
Facilita a resolução
de problemas
BETA_P2_E6
Melhora a ALFA_P1_E4, ALFA_P1_E7,
B6_EC comunicação da BETA_P1_E4, BETA_P2_E2, 10 45,45%
equipe BETA_P2_E3, BETA_P2_E4,
Permite uma maior BETA_P1_E3, BETA_P1_E4,
B7_EC colaboração entre a BETA_P1_E5, BETA_P1_E6, 10 45,45%
equipe BETA_P1_E7, BETA_P2_E1,
Melhora a ALFA_P1_E1, ALFA_P1_E5,
comunicação entre o ALFA_P1_E6, BETA_P1_E1,
B8_EC cliente (ou BETA_P1_E2, BETA_P1_E3, 9 40,91%
representante) e a BETA_P2_E2, BETA_P2_E3,
equipe BETA_P2_E6
Melhora a qualidade
do código
BETA_P2_E5
Feedback
rápido/frequente
BETA_P2_E1
Melhora o processo BETA_P1_E1, BETA_P1_E2,
B11_EC 8 36,36%
de desenvolvimento BETA_P1_E6, BETA_P2_E2,
Entrega frequente de BETA_P1_E3, BETA_P1_E6,
B12_EC 7 31,82%
software funcional BETA_P2_E1, BETA_P2_E2,
BETA_P2_E4
Melhora o ALFA_P1_E1, ALFA_P1_E4,
B13_EC entendimento sobre ALFA_P1_E6, BETA_P2_E1, 6 27,27%
o projeto BETA_P2_E4, BETA_P2_E8
Aumenta a
autonomia da equipe
276
Facilita o ALFA_P1_E1, ALFA_P1_E3,
B15_EC desenvolvimento de ALFA_P1_E7, BETA_P2_E1, 6 27,27%
atividades complexas BETA_P2_E2, BETA_P2_E3
Permite uma maior ALFA_P1_E3, ALFA_P1_E7,
B16_EC discussão sobre o BETA_P1_E1, BETA_P1_E7, 6 27,27%
projeto BETA_P2_E3, BETA_P2_E4
Reduz a quantidade ALFA_P1_E5, BETA_P1_E5,
B17_EC de defeitos/erros no BETA_P1_E6, BETA_P1_E7, 6 27,27%
projeto BETA_P2_E4, BETA_P2_E6
Problemas são ALFA_P1_E3, ALFA_P1_E5,
B18_EC descobertos mais BETA_P1_E1, BETA_P1_E6, 6 27,27%
cedo BETA_P1_E7, BETA_P2_E3
Permite a ALFA_P1_E1, ALFA_P1_E7,
B19_EC identificação rápida BETA_P2_E2, BETA_P2_E3, 6 27,27%
de defeitos/erros BETA_P2_E4, BETA_P2_E7
Torna o ambiente
mais agradável
Melhora a BETA_P1_E7, BETA_P2_E1,
B21_EC priorização dos BETA_P2_E3, BETA_P2_E4, 5 22,73%
requisitos BETA_P2_E5
Aumenta o ALFA_P1_E7, BETA_P1_E4,
B22_EC envolvimento da BETA_P2_E2, BETA_P2_E5, 5 22,73%
equipe no projeto BETA_P2_E8
Melhora a estimativa
de esforço do projeto
BETA_P2_E2
Melhora a qualidade ALFA_P1_E5, ALFA_P1_E7,
B24_EC 4 18,18%
do projeto BETA_P2_E1, BETA_P2_E2
Permite a correção
B25_EC rápida dos 4 18,18%
defeitos/erros
Aumenta a ALFA_P1_E1, ALFA_P1_E7,
B26_EC 4 18,18%
satisfação do cliente BETA_P2_E2, BETA_P2_E6
B27_EC Reduz o retrabalho 4 18,18%
Reduz a interferência ALFA_P1_E1, BETA_P2_E2,
B28_EC 3 13,64%
externa BETA_P2_E8
Reduz a ALFA_P1_E4, ALFA_P1_E7,
B29_EC 3 13,64%
documentação BETA_P2_E2
Entrega de software ALFA_P1_E1, BETA_P2_E1,
B30_EC 3 13,64%
no prazo BETA_P2_E3
Melhora o
planejamento e
B31_EC BETA_P1_E1, BETA_P1_E6 2 9,09%
gerenciamento do
projeto
B32_EC Permite uma maior ALFA_P1_E5, ALFA_P1_E6 2 9,09%
277
interação entre a
equipe e o cliente
Aumenta a coesão
B33_EC ALFA_P1_E1, BETA_P2_E6 2 9,09%
da equipe
Aumenta a
B34_EC produtividade da BETA_P1_E4, BETA_P2_E5 2 9,09%
equipe
Reduz a
B35_EC complexidade do ALFA_P1_E1, ALFA_P1_E3 2 9,09%
código/projeto
Permite a revisão
B36_EC BETA_P1_E3, BETA_P2_E2 2 9,09%
contínua do código
Aumenta a
B37_EC participação do BETA_P1_E3, BETA_P2_E1 2 9,09%
cliente no projeto
Metas e Problemas
B38_EC BETA_P2_E6 1 4,55%
compartilhados
Adequado para
B39_EC ALFA_P1_E1 1 4,55%
projetos complexos
Reduz os custos do
B40_EC BETA_P2_E2 1 4,55%
projeto
Reduz o impacto de
B41_EC BETA_P1_E1 1 4,55%
riscos no projeto
Aumenta a
B42_EC BETA_P1_E6 1 4,55%
motivação da equipe
Facilita a
B43_EC manutenção do BETA_P2_E4 1 4,55%
projeto
Facilita o
B44_EC entendimento do BETA_P1_E5 1 4,55%
código
Facilita a estimativa
B45_EC BETA_P2_E4 1 4,55%
das tarefas
Facilita o
B46_EC desenvolvimento das ALFA_P1_E7 1 4,55%
atividades
Aumenta as chances
B47_EC de sucesso do BETA_P1_E1 1 4,55%
projeto
Aumenta o
B48_EC comprometimento da BETA_P1_E1 1 4,55%
equipe com o projeto
Torna eficiente a
resposta às
B49_EC BETA_P2_E4 1 4,55%
mudanças de
requisitos
B50_EC Metodologia flexível ALFA_P1_E1 1 4,55%
Não necessita de
B51_EC BETA_P1_E3 1 4,55%
formalismo das
278
reuniões
Permite uma maior
B52_EC BETA_P2_E3 1 4,55%
adaptabilidade
279
APÊNDICE L – Limitações identificadas nos
estudos de caso
Tabela 25 – Limitações identificadas nos estudos de caso

Qtd
Descrição da
ID Entrevistado / Projeto entrevista % Total
Limitação
dos
ALFA_P1_E1,
ALFA_P1_E2,
ALFA_P1_E3,
ALFA_P1_E4,
L1_EC ALFA_P1_E7, 9 40,91%
com equipes grandes
BETA_P1_E1,
BETA_P1_E3,
BETA_P2_E3,
BETA_P2_E8
ALFA_P1_E2,
ALFA_P1_E3,
ALFA_P1_E4,
Dificuldade de estimar ALFA_P1_E5,
L2_EC 8 36,36%
histórias ALFA_P1_E7,
BETA_P1_E1,
BETA_P1_E5,
BETA_P2_E3
ALFA_P1_E1,
ALFA_P1_E7,
Interferência do Product
BETA_P1_E1,
Owner com habilidades
L3_EC BETA_P1_E3, 7 31,82%
técnicas no planejamento
BETA_P2_E2,
da equipe
BETA_P2_E3,
BETA_P2_E5
ALFA_P1_E1,
ALFA_P1_E5,
BETA_P1_E3,
L4_EC Aspectos culturais 6 27,27%
BETA_P2_E1,
BETA_P2_E3,
BETA_P2_E5
ALFA_P1_E7,
Dificuldade de se adaptar
L5_EC BETA_P2_E5, 3 13,64%
a constantes mudanças
BETA_P1_E4
Dificuldade de trabalhar ALFA_P1_E2,
L6_EC com individualismo e ALFA_P1_E4, 3 13,64%
especializações ALFA_P1_E5
Aumenta o tempo de BETA_P1_E7,
L7_EC desenvolvimento das BETA_P2_E1, 3 13,64%
atividades BETA_P2_E6
Dificuldade de
apresentar algo funcional BETA_P1_E2,
L8_EC em projetos que não BETA_P1_E3, 3 13,64%
possuem interface BETA_P1_E4
gráfica
L9_EC Falta de identificação das ALFA_P1_E2, 2 9,09%
280
contribuições individuais ALFA_P1_E6
Necessita de Maturidade,
ALFA_P1_E2,
L10_EC Comprometimento e Pro 2 9,09%
ALFA_P1_E6
Histórias e tarefas são ALFA_P1_E7,
L11_EC 2 9,09%
poucas especificadas BETA_P2_E7
BETA_P2_E3,
L12_EC Pouca documentação 2 9,09%
BETA_P2_E6
Dificuldade de trabalhar ALFA_P1_E1,
L13_EC 2 9,09%
com clientes tradicionais ALFA_P1_E7
Aumenta o tempo das ALFA_P1_E4,
L14_EC 2 9,09%
reuniões BETA_P2_E4
Possuir mais de um
interessado com poder ALFA_P1_E7,
L15_EC 2 9,09%
de decisão sobre os BETA_P2_E2
requisitos e prioridades
ALFA_P1_E2,
L16_EC Multitarefa 2 9,09%
BETA_P2_E3
Dificuldade de identificar
ALFA_P1_E2,
L17_EC as contribuições 2 9,09%
ALFA_P1_E5
individuais dos membros
Dificuldade de se
ALFA_P1_E3,
L18_EC concentrar com equipes 2 9,09%
BETA_P1_E5
colocalizadas
Dificuldade de dividir as BETA_P1_E6,
L19_EC 2 9,09%
histórias em tarefas BETA_P2_E4
Aumenta os custos do ALFA_P1_E2,
L20_EC 2 9,09%
projeto BETA_P2_E6
ALFA_P1_E5,
L21_EC com Contrato de Escopo 2 9,09%
ALFA_P1_E6
Aberto
Dificuldade em lidar com
os clientes que gostam
L22_EC ALFA_P1_E6 1 4,55%
de documentação
abrangente
Pouco foco sobre a
L23_EC BETA_P2_E6 1 4,55%
arquitetura de software
Dificuldade de adaptação
L24_EC ALFA_P1_E3 1 4,55%
da metodologia
Dificuldade em
L25_EC implementar a técnica de ALFA_P1_E3 1 4,55%
TDD
L26_EC Difícil de ser aplicado ALFA_P1_E1 1 4,55%
Dificuldade de gerenciar
requisitos dependentes
L27_EC BETA_P2_E3 1 4,55%
utilizando apenas o
quadro
Aumenta a pressão para
L28_EC BETA_P2_E2 1 4,55%
entrega do trabalho
L29_EC ALFA_P1_E1 1 4,55%
com pessoas não ágeis
Dispersão durante as
L30_EC ALFA_P1_E2 1 4,55%
reuniões
Não permite
L31_EC BETA_P1_E4 1 4,55%
acompanhamento para
281
projetos distribuídos
Exige mudança de
L32_EC mentalidade/comportame BETA_P1_E6 1 4,55%
nto
Autogerenciamento pode
L33_EC formar ilhas de BETA_P1_E1 1 4,55%
conhecimento
Dificuldade de adaptar a
L34_EC metodologia ágil para ALFA_P1_E2 1 4,55%
equipes ágeis
Aumento o tempo das
L35_EC ALFA_P1_E1 1 4,55%
reuniões
Dificuldade de
L36_EC BETA_P1_E4 1 4,55%
programação em par
Sobrecarga de
L37_EC gerenciamento (muitas BETA_P2_E1 1 4,55%
reuniões)
Aumenta a
especialização dos
L38_EC BETA_P2_E3 1 4,55%
membros em atividades
específicas
Muito formalismo nas
L39_EC reuniões pode inibir uma ALFA_P1_E7 1 4,55%
boa comunicação
Difícil de ser utilizado em
L40_EC ALFA_P1_E2 1 4,55%
projetos complexos
282

Dissertação - Benefícios e Limitações Das Metodologias Ágeis No Desenvolvimento de Software

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

Dissertação - Benefícios e Limitações Das Metodologias Ágeis No Desenvolvimento de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Pós-Graduação em Ciência da Computação

“Benefícios e Limitações das Metodologias

Fernando Kenji Kamei

Universidade Federal de Pernambuco

FERNANDO KENJI KAMEI

“BENEFÍCIOS E LIMITAÇÕES DAS METODOLOGIAS ÁGEIS NO

ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO

ORIENTADOR: PROF. ALEXANDRE MARCOS LINS DE

CO-ORIENTADOR: PROF. FÁBIO QUEDA BUENO DA SILVA

Kamei, Fernando Kenji

Orientador: Alexandre Marcos Lins de Vasconcelos.

Inclui bibliografia e apêndice.

1. Engenharia de software. 2. Metodologias ágeis. I. Vasconcelos,

005.1 CDD (23. ed.) MEI2012 – 149

Visto e permitida a impressão.

Coordenador da Pós-Graduação em Ciência da Computação do

Centro de Informática da Universidade Federal de Pernambuco.

Ao professor Alexandre Marcos Lins de Vasconcelos por todo o seu apoio,

Aos amigos da pós-graduação: Fernando Selleri, Ivanildo Monteiro e Elisa

Aos amigos do Agilidade na Prática por todo aprendizado adquirido e amizade:

Aos amigos do IF-Sertão (Ouricuri) por todo apoio e compreensão: Maílson

As Metodologias Ágeis emergiram nos últimos anos em busca de melhor

Palavras-Chave: Metodologias Ágeis, Revisão Sistemática da Literatura,

Agile methodologies have emerged in recent years in search of better quality in

Keywords: Agile Methodologies, Systematic Literature Review, Case Studies.

Figura 1 – Ciclo da pesquisa ............................................................................ 23

Quadro 1 – Diferenças entre este trabalho e o de Dybå e Dingsøyr (2008) ..... 16

Tabela 1 – Valores de Concordância do índice Kappa (LANDS e KOCH, 1977)

ASD – Adaptative Software Development

1.1 Definição do problema

1.3 Questões de pesquisa

1.4 Objetivo Geral

1.4.1 Objetivos Específicos

1.6 Contribuições e Resultados esperados

1.7 Estrutura do trabalho

 Capítulo 3 (Metodologia da Pesquisa):

 Capítulo 5 (Considerações Finais):

 Apêndices: apresenta os modelos dos instrumentos de coleta que

2.1 Referencial teórico

2.1.3 Extreme Programming (XP)

2.2 Soluções alternativas

2.2.1 Agile methods rapidly replacing traditional

2.2.2 Usage and Perceptions of Agile Software

2.3 Trabalhos Relacionados

A busca pelos estudos resultou na identificação de 1.996 estudos

3.1 Quadro metodológico

Método de abordagem Indutivo

Este trabalho optou pela abordagem indutiva, que, segundo Marconi e

3.2 Ciclo da pesquisa

Figura 1 – Ciclo da pesquisa

(2) Com a base teórica adquirida na etapa anterior, deu-se o início do

3.2.1 Procedimento de coleta dos dados

3.2.1.1 Aplicação de Questionários (survey)

3.2.1.2 Revisão Sistemática da Literatura

Esta SLR é uma extensão da revisão conduzida por Dybå e Dingsøyr

Característica Categoria da revisão

Quadro 4 – Classificação da revisão da literatura

Para permitir que uma revisão seja auditável, Kitchenham (2007)

3.2.1.2.1 Protocolo da pesquisa

A primeira questão de pesquisa é a principal, sendo as outras duas

Seleção dos estudos

Extração e Análise dos dados

Síntese dos dados