Machine Translated by Google
J Braz Comput Soc (2013) 19:523–552
DOI 10.1007/s13173-013-0114-x
PAPEL ORIGINAL
A evolução do desenvolvimento ágil de software no Brasil
Educação, pesquisa e o estado da prática
Claudia de O. Melo · Viviane Santos · Eduardo Katayama · Hugo Corbucci
· Rafael Prikladnicki · Alfredo Goldman · Fabio Kon
Recebido: 12 de outubro de 2012 / Aceito: 28 de maio de 2013 / Publicado online: 14 de julho de
2013 © Sociedade Brasileira de Computação 2013
Resumo Os métodos ágeis de desenvolvimento de software têm sido
cada vez mais adotados em todo o mundo e se tornaram uma das
principais abordagens de desenvolvimento de software. Os métodos
ágeis também tiveram impacto no ensino de engenharia de software,
com universidades adaptando seus cursos para acomodar essa nova
forma de desenvolvimento de software. A pesquisa em engenharia de
software tem procurado avaliar o impacto de métodos ágeis em projetos
industriais e descobrir em quais situações é benéfico aplicar tais
métodos. No entanto, quase não há estudos com foco no avanço do
movimento ágil no Brasil. Neste artigo, apresentamos um panorama da
evolução do movimento ágil no Brasil, traçando a história de seus
primeiros defensores na academia e na indústria. Descrevemos as
iniciativas educacionais existentes, discutimos o impacto do
desenvolvimento ágil na pesquisa nacional e apresentamos um relatório
sobre o estado da prática ágil na indústria brasileira de TI.
C. de O. Melo (B) · V. Santos · E. Katayama · H. Corbucci · A. Goldman
· F. Kon Department of Computer Science, University of São Paulo,
São Paulo, Brazil e-mail: claudia@ime.usp.br
V. Santos
e-mail: vsantos@ime.usp.br
E. Katayama e-
mail: eduardo@ime.usp.br
H. Corbucci e-
mail: corbucci@ime.usp.br
A. Goldman e-
mail: gold@ime.usp.br
F. Se e-
mail: fabio.kon@ime.usp.br
Escola de Ciência
da Computação R. Prikladnicki, Pontifícia Universidade Católica do Rio
Grande do Sul, Porto Alegre, Brasil e-mail: rafaelp@pucrs.br
Palavras -chave Desenvolvimento ágil de software ·
Iniciativas educacionais ágeis · Pesquisa ágil brasileira ·
Estado da prática ágil brasileiro ·
Programação orientada a objetos · História da computação
1. Introdução
O nascimento do movimento ágil por volta do ano 2000 tem fortes raízes
na história da engenharia de software. As ideias ágeis ecoaram trabalhos
anteriores como The Mythical Man-Month: Essays on Software
Engineering de Brooks [8] e o conceito de prototipagem rápida de
Naumann e Jenkins [45]. Eles foram uma consequência de uma
variedade de fatores, ideias e melhores práticas propostas que surgiram
principalmente no contexto da comunidade de programação orientada a
objetos.
Mesmo sendo uma mudança notável no pensamento de desenvolvimento
de software, essas ideias existem desde a década de 1970 ou mesmo
antes, como explicado por Abbas et al. [1]. Por não terem sido tratados
com seriedade suficiente, levou cerca de 30 anos para que fossem
reconhecidos como uma forma eficaz de desenvolver
porcelana.
Vários grupos de pesquisadores e profissionais se reuniram em
comunidades maiores, como a da ACM International Conference on
Object-Oriented Programming, Systems, Languages, and Applications
(OOPSLA), e produziram as ideias que levaram ao desenvolvimento do
conceito de desenvolvimento ágil de software. O papel da comunidade
linguística de programação Smalltalk também foi fundamental. Três
pontos importantes dessa comunidade levaram a mudanças. A primeira
foi a sintaxe mínima do Smalltalk que permitia aos programadores
escreverem códigos que pareciam frases de linguagem natural. A
primeira foi a sintaxe mínima do Smalltalk que permitia aos programadores
escreverem código que imitasse sentenças de linguagem natural [23].
Por exemplo, um código Smalltalk bem escrito pode parecer uma frase
123
Machine Translated by Google
524
em inglês, por exemplo, Clock display Time now. A segunda foi sua
tipagem dinâmica que proporcionou alta flexibilidade. Por fim, um
poderoso ambiente de programação centrado em torno de sua dinâmica
e navegador de classe flexível que influenciou IDEs modernos. Vencimento
a essas características, a Smalltalk fomentou o desenvolvimento
da tecnologia e do espírito que possibilitaram uma forma diferente
de desenvolvimento de software.
Durante a década de 1990, uma combinação de fatores produziu uma
terra fértil para o crescimento de ideias ágeis [1]. Primeiro, houve
uma reação a abordagens pesadas e prescritivas para o desenvolvimento
de software. Em segundo lugar, o crescente nível de mudança
no ambiente de negócios instou os profissionais a lidar com
requisitos complexos e imprevisíveis no desenvolvimento de sistemas.
Assim, os praticantes começaram a revisitar antigas formas alternativas
de desenvolvimento de software, como o iterativo e o
desenvolvimento incremental e envolvimento próximo do cliente
proposto por Winston [51], desenvolvimento de primeiro teste e integração
contínua usado pelo Projeto 1961-1963 da NASA
Mercúrio descrito por Larman e Basili [35], e prototipagem rápida definida
por Naumann e Jenkins [45].
Na segunda metade da década de 1990, pesquisas e resultados
práticos nas áreas de POO, padrões de projeto, automação
teste, refatoração e afins produziram uma mentalidade comum que
impulsionou a definição de vários métodos de desenvolvimento de
software que tinham os princípios ágeis centrais em comum.
[28,13]. Esses métodos incluem Extreme Programming (XP),
Scrum, Método de Desenvolvimento de Sistemas Dinâmicos, Adaptativo
Desenvolvimento de Software, Crystal, Feature-Driven Development,
Pragmatic Programming e outros.
No início de 2001, um grupo de profissionais independentes com
forte ligação com a indústria de software e uma mais fraca, mas ainda
relevante, vínculo com grupos de pesquisa da academia, decidiu
unir forças e fundar o que mais tarde foi chamado de Agile
movimento. Para tornar essas ideias mais concretas, 17 softwares
especialistas se reuniram de 11 a 13 de fevereiro nas montanhas
de Utah, EUA, para elaborar coletivamente o manifesto ágil1. o
objetivo do manifesto era chamar a atenção para a ideia de que
produzir software valioso e de alta qualidade, equipes de desenvolvimento
deve se concentrar em valores e princípios como (1) indivíduos
e interações, (2) software em funcionamento, (3) colaboração com o
cliente e (4) resposta a mudanças. Esses pontos foram apresentados
como mais importantes do que enfatizar processos e
ferramentas, documentação abrangente, negociação de contratos,
e seguindo planos previamente definidos.
Os métodos ágeis são, portanto, abordagens concretas para
materializar os valores e princípios do manifesto em direção à agilidade.
A agilidade pode ser interpretada como a capacidade de “rapidamente ou
inerentemente criar mudanças, abraçar a mudança de forma proativa ou
reativa e aprender com a mudança enquanto contribui para
valor percebido pelo cliente (economia, qualidade e simplicidade),
1 Denver, Colorado. Em 2000, o 1º
http://www.agilemanifesto.org.
123
J Braz Comput Soc (2013) 19:523–552
por meio de seus componentes coletivos e das relações com seus
meio ambiente” [15].
Um ano antes do manifesto, algumas das ideias do
movimentos ágeis já estavam entrando no
Comunidade brasileira de desenvolvimento de software. Iniciativas em
São Paulo, Rio de Janeiro, and Curitiba appeared around
2001 e cresceu para uma conferência em 2002 (Extreme Pro gramming
Brasil'2002). Alguns anos depois, acadêmicos
cursos, conferências, bem como adoções da indústria, foram
começando a criar uma comunidade de praticantes ágeis. Hoje em dia,
essa comunidade se expandiu o suficiente para tornar ágil
métodos uma alternativa de engenharia de software amplamente aceita
no Brasil, com um forte mercado da indústria em treinamento
e uma demanda crescente tanto do setor privado quanto do público
setores.
Após mais de 10 anos da formalização do manifesto ágil, a relevância
e a comunidade dos métodos ágeis no Brasil
continuar a crescer. Em um estudo preliminar [18], apresentamos um
visão geral da evolução do Movimento Ágil no Brasil,
descreveu as iniciativas educacionais existentes e relatou a
estado da prática ágil na indústria brasileira de TI. No
artigo atual, estendemos e refinamos esse trabalho. Nosso estudo visa
agora para fornecer uma melhor compreensão do software ágil
evolução do desenvolvimento no país, particularmente na educação,
pesquisa e indústria. Esta pesquisa tem como foco o
seguintes questões de pesquisa:
• RQ1: Como a educação em métodos ágeis evoluiu em
Brasil?
• RQ2: Como a pesquisa de métodos ágeis evoluiu no Brasil?
• RQ3: Como a prática de métodos ágeis evoluiu no
indústria brasileira de TI?
O restante deste trabalho está organizado da seguinte forma. Seção 2
descreve os primeiros defensores dos métodos ágeis na academia e
indústria. A seção 3 descreve uma experiência relatada sobre
uma iniciativa pioneira de educação em métodos ágeis e também
dá uma visão geral de outros cursos realizados desde 2001.
A seção 4 apresenta o impacto do movimento ágil na
pesquisa, e Sec. 5 apresenta um estudo abrangente recente
do impacto dos métodos ágeis na indústria brasileira de TI.
A Seção 6 discute as principais descobertas e implicações para
pesquisa e prática, bem como as limitações da atual
trabalhar. A última seção conclui o artigo e descreve
trabalho futuro.
2 A gênese
Os métodos ágeis e o próprio movimento ágil tornaram-se conhecidos
em todo o mundo em 1999, ano em que o XP de Kent Beck
livro [4] foi publicado e lançado durante a conferência ACM OOP SLA em
Machine Translated by Google
J Braz Comput Soc (2013) 19:523–552
A Conferência Internacional sobre Programação eXtreme e Processos Ágeis
em Engenharia de Software (XP'2000) ocorreu na Sardenha, Itália. Nessa
época, alguns desenvolvedores de software brasileiros e pesquisadores da
academia e da indústria entraram em contato com o movimento. Algumas
dessas pessoas participaram do XP'2000 e conheceram figuras-chave do
movimento, como Kent Beck, Alistair Cockburn, Martin Fowler, Ron Jeffries e
Robert Martin. Outros estiveram na ACM OOPSLA em 1999
e 2000, participou das palestras de Beck e se envolveu com o grande frisson
que XP e métodos ágeis fizeram durante essas conferências.
No início de 2001, professores e praticantes brasileiros começaram a dar
palestras sobre programação extrema em universidades, departamentos de TI
do governo e em empresas ligadas à indústria de software. Naquele ano,
começaram a ser oferecidos os primeiros cursos universitários semestrais
sobre programação extrema. Nestes cursos, os alunos desenvolveriam projetos
reais de software usando todas as práticas de XP rigorosamente. Avaliações
feitas com os alunos mostraram que estas estavam entre as disciplinas eletivas
mais populares do currículo. Dezenas desses alunos saíram para trabalhar na
indústria de software logo após os cursos e muitas vezes começaram a
disseminar métodos ágeis em suas novas organizações. Alguns dos alunos
avançados com mais habilidades de liderança passaram a atuar, após a
graduação, como consultores e líderes de projetos e ajudaram a introduzir
métodos ágeis em ainda mais empresas de desenvolvimento de software.
Nos poucos anos após 2001, os membros dessa comunidade inicialmente
pequena de métodos ágeis (incluindo acadêmicos como Vinícius Teles, Fabio
Kon e Alfredo Goldman e praticantes como Klaus Wuestefeld) deram dezenas
de palestras e cursos de curta duração sobre programação extrema e métodos
ágeis métodos em todo o Brasil para o público acadêmico e industrial. Os
eventos de 2002 e 2003 em São Paulo, Rio de Janeiro, Recife, Florianópolis,
São Carlos e Brasília foram fundamentais para difundir o uso prático desses
métodos em projetos reais de desenvolvimento de software no Brasil.
Nessa época, a iniciativa privada organizou a Extreme Pro gramming
Brasil'2002, o primeiro evento ágil do Brasil, que contou com a primeira e única
visita de Kent Beck ao país. Foi realizado em São Paulo durante 3 dias no início
de dezembro e teve Scott Ambler e Rob Mee junto com Kent Beck como
convidados internacionais dando palestras para cerca de 200 participantes.
Professores brasileiros apresentaram sua experiência ensinando XP nas
universidades e praticantes descreveram suas primeiras experiências com os
novos métodos na indústria nacional de software.
Dois anos depois, o Extreme Programming Brasil'2004 contou com a
presença de 300 pessoas e trouxe o pêndice de Mary e Tom Pop com o apoio
de diversas empresas. Nos anos seguintes, eventos na Universidade de São
Paulo trouxeram palestrantes de classe mundial da área, como Fred
525
erick Brooks, Linda Rising, Richard Gabriel, Jutta Eckstein, Joe Yoer e Brian
Foote. Os métodos ágeis estavam começando a ganhar força tanto na
academia quanto na indústria.
Em 2010, estudantes de pós-graduação e profissionais do setor organizaram
a primeira edição do Agile Brazil na PUCRS, em Porto Alegre. Desde então, a
cada ano, a conferência atrai mais de 800 participantes de todo o país. Agile
Brazil tornou-se a mais importante conferência brasileira sobre desenvolvimento
ágil de software. Traz não apenas uma série de palestras e workshops para o
setor, mas também um workshop acadêmico, um encontro executivo e uma
maratona com treinamentos para disseminar o conhecimento sobre métodos
ágeis.
3 Educação em métodos ágeis
Houve várias iniciativas educacionais sobre a promoção de métodos ágeis no
Brasil dentro da Academia e Indústria. Para responder ao nosso RQ1: Como o
ensino de métodos ágeis evoluiu no Brasil? primeiro descrevemos uma
experiência relatada no curso “XP Laboratory”, o mais antigo curso sobre
desenvolvimento ágil de software em execução no país. Nosso relatório inclui
detalhes sobre o contexto, técnicas e desenvolvimento do curso ao longo dos
anos.
Ilustramos alguns resultados específicos consultando os artigos publicados
sobre os projetos. Em seguida, descrevemos algumas outras iniciativas
educacionais brasileiras com base no conhecimento do nosso grupo de
pesquisa. Apesar de nossa descrição não estar completa, pretendemos
contribuir acrescentando evidências anedóticas de alguns dos primeiros cursos
de educação ministrados no Brasil.
Laboratório XP do IME-USP. O curso de desenvolvimento ágil de software
mais antigo e ainda em andamento no Brasil é provavelmente o curso
Laboratório XP do IME-USP, que se tornou um espaço para o desenvolvimento
de diversos projetos reais. Ocorre uma vez por ano para alunos de graduação
e pós-graduação em Ciência da Computação, durante um semestre inteiro. A
primeira edição foi em 2001, quando três professores ensinaram uma dúzia de
alunos. Desde então, o curso evoluiu e se expandiu para mais de cinquenta
alunos em oito projetos e equipes simultâneas.
Para sustentar esse crescimento, além do papel do professor, existem
alguns alunos muito experientes que assumem funções de assistentes de
ensino e atuam como meta-treinadores durante os cursos.
Os meta-coaches devem servir como especialistas para todos os grupos,
fornecendo feedback, supervisionando as práticas e ajudando na adoção de
novas práticas. Além disso, ex-alunos ou alunos experientes são incentivados
a assumir uma função de coaching nas próximas edições, e os demais alunos
matriculados trabalham como desenvolvedores.
Para configurar um ambiente mais próximo do real, os clientes dos cursos
do IME-USP são escolhidos a partir de diversas solicitações de universidades ou
123
Machine Translated by Google
526
projetos de código aberto2. Todos os sistemas desenvolvidos estão disponíveis
como software livre. O curso começa com três semanas de
aulas teóricas, quando o básico de métodos ágeis e XP
são apresentados; então, os alunos podem escolher os projetos
eles estão dispostos a trabalhar. Normalmente, cada projeto recebe de
quatro a oito participantes. Se não houver aluno experiente
no grupo, um treinador é eleito entre os voluntários. o
grupos sem um treinador experiente recebem mais atenção
dos meta-treinadores.
O curso do IME-USP exige 8 horas semanais de dedicação dos
alunos. As práticas iniciais adotadas no início
dos projetos são os 12 da primeira edição do XP
livro; além disso, reuniões diárias em pé e espaços de trabalho informativos
também são usados. Todas as equipes devem realizar
retrospectivas ao final de cada iteração. Uma vez por semana,
há uma reunião envolvendo treinadores, meta-treinadores e
o professor para revisões de projetos, compartilhamento de problemas
ou soluções e solicitação de suporte. O professor e os meta-treinadores
monitorar as práticas ágeis das equipes, avaliar seus
espaços de trabalho e progresso, e também coletar feedback dos alunos
no curso para adaptá-lo de acordo com a aprendizagem dos alunos
precisa. Para avaliar os alunos, uma média de notas por frequência,
participação pró-ativa, acompanhamento, satisfação do cliente, juntamente
com avaliação pessoal, coach e meta-coach
é calculado.
A fim de acomodar toda a classe, física e
infra-estrutura tecnológica é fornecida. Assim, a corrente
ambiente de aprendizagem é composto por dois laboratórios como
áreas de trabalho para as equipes, material para confecção dos espaços
de trabalho informativos3 [4], planejamento de baralhos de pôquer para
estimativas [79], duas salas para planejamento, técnico e cliente
reuniões de aprovação e retrospectivas [20]. Desta forma, o
O curso de Laboratório XP do IME/USP replica um sistema semelhante
ao da indústria e é de grande valia para os alunos, como
aluno afirmou: “o curso me deu muita oportunidade de
aprender a gerenciar uma equipe e negociar projetos com um
cliente".
Em um esforço recente para melhorar continuamente o curso,
uma vez por semana há uma aula de 1h no horário de almoço com almoço
proporcionado pelo curso de escrutínio de tópicos XP por meio de
mini-palestras. Os temas são previamente escolhidos pelos alunos. e por
meio de outras práticas aplicadas para coletar feedback
no curso, e melhorar a interação entre os membros
do curso. As práticas aplicadas foram Coding Dojo [56],
retrospectivas de toda a classe e outras dinâmicas significativas
comumente usado em conferências de métodos ágeis, conhecidos como
2 Descrição dos projetos disponível em http://www.ime.usp.br/~xp/
projetos.php.
3
Isso inclui quadros brancos, post-its de todos os tamanhos e cores, canetas, lápis,
borrachas, cartões de histórias, cartazes, réguas, caixas, adesivos coloridos, adesivos
fitas e outros.
123
J Braz Comput Soc (2013) 19:523–552
Lightning talk4, Birds of a feather sessions5, Starfish diagrams6,
Brainwriting7 e workshops.
Considerando o sucesso das primeiras edições do laboratório IME
USP XP, foi feita uma apresentação sobre seu conceito
no Simpósio Brasileiro da Qualidade em 2002, fórum onde
boas ideias e técnicas de ensino são difundidas entre diferentes
Universidades, durante o congresso anual da Sociedade Brasileira de
Computação (SBC). Mais tarde, usando o curso
como banco de ensaio, foram produzidas várias publicações científicas,
abordando vários tópicos, desde software funcional como
Arquimedes [17], Mezuro [37,71] e Mico [66] para experimentar o ensino
de XP [28] ou técnicas relacionadas com XP [7].
Três estudos recentes sobre rastreamento [47], melhoria contínua [54] e
aprendizado organizacional [55] também usaram
o ambiente de laboratório XP.
Outros cursos acadêmicos. No segundo semestre de 2011,
um ambiente semi-presencial (no local) foi experimentado em um curso
de laboratório XP ministrado em outro estado brasileiro. Neste especial
edição, o curso foi ministrado a 15 doutorandos no período
de 2 meses. Após as palestras iniciais sobre as práticas de XP, o
A professora visitou os alunos duas vezes durante o processo de
desenvolvimento e uma última vez ao final do projeto. Para
superar os problemas de distância, algumas abordagens foram tomadas:
um ambiente foi configurado para permitir um rastreamento distribuído de
dos projetos, cada aluno ficou responsável pela leitura, e
possivelmente compartilhamento, algum material relacionado a métodos ágeis, e todos
as discussões foram feitas (ou comentadas no mailing
listas). O feedback fornecido pelos alunos foi muito positivo, conforme
relato de um aluno: “A estrutura geral do curso
foi muito bom: uma introdução teórica sobre XP,
pedidos de leitura sobre tópicos relacionados e muita prática
(...) aprendi muito nesses 2 meses, mas mesmo assim, aprendi mais
sobre minhas experiências pessoais e de equipe”. Também outro aluno
destacou: “A disciplina é muito prática, o que é muito
estimulante. Gostei de lidar com clientes e sistemas
que seria realmente usado”.
Uma iniciativa semelhante no ensino de XP foi realizada na
Federal University of Rio de Janeiro (UFRJ) starting in the
segundo semestre de 2002. A abordagem utilizada no Rio foi diferente.
Havia duas partes para cada aula: primeiro uma teórica em que os alunos
tinham que responder a perguntas
oralmente com base no material fornecido anteriormente. Na parte prática,
em vez de ter um projeto para cada equipe durante
todo o curso, vários exercícios curtos em cada prática
4
Apresentações curtas para compartilhar ideias. A seguir, se for o caso, pode ocorrer uma
breve discussão.
5
Grupo de discussão informal onde os participantes se agrupam com base
em interesses compartilhados.
6 Diagrama para obter feedback sobre o que parar ou começar a fazer e o que
tem mais ou menos, apresentado por Patrick Kua, http://www.thekua.
com/rant/2006/03/the-retrospective-starfish.
7
Uma atividade de brainstorming para incentivar a interação entre as equipes usando
cartões para propor soluções para os problemas dos projetos.
Machine Translated by Google
J Braz Comput Soc (2013) 19:523–552
foram propostos. A motivação foi reforçar o aprendizado
de cada prática, sempre praticando programação em pares. Cada
dia, os pares foram escolhidos aleatoriamente. As notas eram principalmente
dado com base na assiduidade e nas respostas.
É interessante observar que outro centro de destaque
em pesquisa ágil, Universidade Federal do Recife (UFPE),
uma abordagem diferente. Em vez de ter um foco inicial em
educação, eles começaram desde o início com a pesquisa. Dentro
2003, duas teses de mestrado relacionadas a métodos ágeis e uma
trabalho de graduação foram apresentados. Desde então, há
tem aumentado o número de pós-graduandos e graduandos
trabalhos, inclusive de outras universidades daquele estado,
como a Universidade Federal Rural do Recife (UFRPE).
Além das iniciativas descritas, também identificamos diversas outras
iniciativas de ensino de métodos ágeis que
foram desenvolvidos nos últimos 3 anos em muitas universidades
no brasil. Na PUCRS, por exemplo, no sul do país, existe um programa de
três cursos sobre métodos ágeis que é
oferecido todos os anos pela Escola de Ciência da Computação. o
os cursos envolvem um curso introdutório, gerenciamento ágil de projetos
com Scrum e análise ágil de negócios. Mais recentemente,
A PUCRS se engajou em outra iniciativa, que envolve a
criação de um laboratório ágil financiado pelo CNPq para desenvolvimento de
software de alta performance
equipes de desenvolvimento, com base em métodos ágeis.
No lado industrial, algumas empresas oferecem treinamento em
métodos ágeis. Por exemplo, a Caelum é uma empresa brasileira
cujo negócio inclui treinamento e desenvolvimento de software. Caelum tem
vários cursos de curta duração em Java e desenvolvimento orientado a
objetos. A empresa passou a oferecer cursos
em XP e Scrum em 2007. No entanto, o curso XP foi
pouco descontinuado, uma vez que a demanda industrial na época
não foi suficiente. Mais tarde, no início de 2010, o curso Scrum
foi reformulado para abordar os métodos ágeis em geral, focando
principalmente nas práticas de gestão. Até o final do
No mesmo ano, um novo curso foi criado para abranger práticas mais técnicas,
como testes unitários e de aceitação, test-driven
desenvolvimento e refatoração.
Em 2006, quando os métodos ágeis começaram a ganhar ampla aceitação,
alguns professores e alunos do IME-USP decidiram oferecer um
curso de verão para promover essas ideias além dos limites
a Universidade. Foi um curso teórico de 20 horas distribuído ao longo
5 dias com dois instrutores por dia. O resultado foi um sucesso
e todo o material didático foi publicado no site da Agilcoop8 para uso livre sob
licença Creative Commons. Dentro
nos 3 anos seguintes, a equipe de instrutores continuou a
oferecer o curso, agregando temas como Laboratório XP
oferecer uma abordagem mais prática e um curso de teste para estudar
esse assunto mais profundamente. Nesse período, mais de 200 pessoas
frequentaram o curso teórico, mais de 60 frequentaram o curso prático e cerca
de 50 frequentaram o curso de testes. O máximo de
8 12
http://ccsl.ime.usp.br/agilcoop/curso_de_verao_2007.
527
estes 300 participantes eram da indústria e ajudaram a
disseminar práticas ágeis em suas empresas.
Scrum [62] também foi um jogador muito importante no desenvolvimento ágil
crescimento dos métodos. Embora tenha suas origens anteriores a
XP, tornou-se amplamente conhecido apenas por volta de 2006, quando o
A Scrum Alliance9 (uma organização sem fins lucrativos) tornou-se uma
entidade corporativa e iniciou um processo de certificação para reunir
profissionais que atendiam aos seus critérios. A aliança oferece vários
selos de certificação que só podem ser dados por formadores certificados.
Inicialmente, todas as certificações dadas no Brasil eram oferecidas
por formadores estrangeiros em inglês. Desde agosto de 2008, porém,
os primeiros Certified Scrum Trainers brasileiros foram reconhecidos
pela Scrum Alliance e os cursos passaram a ser ministrados em
Português. A certificação preencheu uma importante lacuna para o
indústria, pois apresentou uma forma de comprovar o conhecimento
empresas em métodos ágeis. Desde então, outros brasileiros
obteve o certificado CST e a demanda por certificados
os cursos scrum nunca pararam de crescer. Recentemente, uma discussão
sobre a certificação levou à criação de outra fundação (Scrum.org10)
separando Ken Schwaber (Scrum.org)
e Jeff Sutherland (Scrum Alliance), e provocando uma ruptura na comunidade
Scrum. Esta nova associação também
oferece um programa de certificação sob um rótulo diferente (Professional
Scrum Certifications).
Mais recentemente, o Project Management Institute (PMI) também
lançou uma certificação ágil, denominada PMI-ACP (Agile Cer tified
Practitioner)11. O PMI-ACP reconhece o conhecimento
de princípios, práticas, ferramentas e técnicas ágeis em toda a
Metodologias ágeis. Conforme afirmado pelo PMI, “indivíduos com
experiência de trabalho em equipes de projetos ágeis pode ser aplicada”. o
piloto do PMI-ACP ocorreu de 15 de setembro de 2011 a 30 de novembro
2011, com mais de 500 testes. Até agora, 29 brasileiros
passou e agora ganha a certificação PMI-ACP. O fato
que os sistemas de certificação são um sucesso na indústria é inegável e
muitas pessoas entraram em contato com o ágil através desses
programas de certificação.
Mais uma iniciativa para fomentar a adoção de métodos ágeis
foi feito em várias edições da oficina Encontro Ágil12 .
Nas primeiras edições, o foco principal eram tutoriais e painéis
ensinar ou fornecer evidências de trabalho sobre métodos ágeis e
técnicas relacionadas. Para fornecer informações interessantes para um
público amplo, as oficinas foram divididas em três
categorias, as palestras são geralmente com um palestrante convidado,
há uma faixa avançada e uma faixa introdutória. No entanto, na última edição,
em 2010, houve uma grande mudança.
Em vez de fornecer palestras, uma ênfase maior em espaços abertos
9 http://www.scrumalliance.org.
10 http://www.scrum.org.
11
http://www.pmi.org/Certification/New-PMI-Agile-Certification.
aspx.
http://www.encontroagil.com.br.
123
Machine Translated by Google
528
e palestras relâmpago foram dadas enquanto apenas workshops com
possibilidades mais interativas foram permitidas como sessões longas.
Finalmente, em 2003, um tutorial sobre métodos ágeis e XP foi
apresentado no SBES. Este foi o antecessor de um novo tutorial
realizado no CBSOFT-SBES em 2011 sobre métodos ágeis. o
a principal motivação do novo tutorial foi apresentar evidências sobre
a eficácia dos métodos ágeis após 10 anos de uso
no Brasil e mostrar os desafios atuais.
Em todo o mundo, existem vários estudos apontando a
ajustes nos currículos do ensino de engenharia de software
para se adequar a este novo paradigma [9,30,38,44,49,76]. Esses
estudos propõem maneiras de fazer isso, mas a maioria deles
considerá-lo um empreendimento desafiador, pois requer teoria
e experiência prática, projetos reais, tempo para o trabalho de
desenvolvimento, um lugar para construir o ambiente ágil e
a presença de vários papéis (como cliente, coach, desenvolvedor,
e mentor).
4 Pesquisa de métodos ágeis
Até onde sabemos, foi publicada a primeira revisão de trabalhos acadêmicos
brasileiros sobre desenvolvimento ágil de software
no Workshop Brasileiro de Métodos Ágeis (WBMA'2011)
[27]. Aqui, estendemos esses resultados adicionando trabalhos de pesquisa
publicado até 8 de dezembro de 2011. Assim como no artigo original,
pretendemos responder a RQ2: Como a pesquisa de métodos ágeis tem
evoluiu no Brasil?
4.1 Processo de revisão
Para focar o desenho do processo de revisão, dividimos o
RQ2 em três subquestões:
• SQ1. Quantas teses e dissertações relacionadas ao ágil
desenvolvimento de software estão em andamento e foram concluídos
no Brasil?
• SQ2. Como é a colaboração e cooperação entre
pesquisadores do Brasil?
• SQ3. Quantas produções bibliográficas, técnicas
relacionadas ao desenvolvimento ágil de software foram elaboradas em
Brasil?
Nosso processo de revisão abrange quatro etapas:
Etapa 1. Identificar pesquisadores. A primeira parte da resenha
processo consistiu em identificar
pesquisadores que trabalham em áreas relacionadas a métodos
ágeis. A estratégia de busca incluiu uma lista de contatos de
pesquisadores e buscas manuais em sites nacionais.
anais de conferências como WBMA [60],
ESELAW [58], WDRA [61] e SBES [59], e
conferências internacionais como Agile [22] e XP
123
J Braz Comput Soc (2013) 19:523–552
[65]. Para cada pesquisador identificado, enviamos uma
comunicação pessoal por e-mail para validação dos dados.
Também pedimos que convidassem seus contatos de pesquisa
relacionados a métodos ágeis para ajudar a validar os dados.
Usando scriptLattes [42], um conhecimento de código aberto
sistema de extração para a plataforma Lattes, realizamos uma
pesquisa bibliográfica no Currículo Lattes13
em 8 de dezembro de 2011 para extrair produções científicas
e orientações de teses em andamento/concluídas.
Optamos por utilizar o Currículo Lattes porque
a maioria das publicações nacionais não foram indexadas
em outras bases de dados eletrônicas, como no ISI Web of
Ciência.
Etapa 2. Identifique o trabalho relevante. Os papéis foram incluídos em
a revisão se seu foco era o desenvolvimento ágil de software
ou se eles estavam focados em um único
técnicas ou práticas, por exemplo, programação em pares,
desenvolvimento orientado a testes ou refatoração. A inclusão
de artigos não se restringiu a nenhum
tipo de intervenção ou medida de resultado. Esse
a revisão incluiu artigos de pesquisa brasileiros qualitativos e
quantitativos. Para identificar os papéis a serem
incluído, fizemos uma pesquisa em bola de neve (recursiva)
dos artigos publicados por cada pesquisador que
encontrado na etapa anterior [31]. Para cada identificado
pesquisador, procuramos os seguintes tipos de
produções.
1. Artigos em revistas científicas;
2. Trabalhos completos publicados em anais de congressos;
3. Resumos expandidos publicados em anais de congressos;
4. Resumos publicados em anais de congressos;
5. Artigos de periódicos aceitos para publicação (no prelo).
Excluímos livros publicados ou organizados, livros
capítulos publicados, artigos em jornais ou revistas e outros
tipos de produção bibliográfica
da nossa busca. Essa estratégia de busca resultou em
um total de 2328 artigos únicos entre 1997 e
2011. Descrever quantas teses de doutorado e mestrado
dissertações relacionadas ao desenvolvimento ágil de software,
usamos a ferramenta scriptLattes [42] para extrair
supervisões em andamento/concluídas. Essa estratégia de
busca resultou em um total de 550 supervisões.
Etapa 3. Excluir estudos com base em títulos. Nós analisamos
os títulos de todos os estudos, incluindo teses e dissertações,
da etapa 2, para determinar sua relevância
13 O “Currículo Lattes” é considerado um padrão brasileiro de
informação sobre a produção científica e acadêmica de estudantes,
professores, pesquisadores e profissionais envolvidos em ciência e tecnologia
em geral.
Machine Translated by Google
J Braz Comput Soc (2013) 19:523–552
Fig. 1 Etapas do processo seletivo
à revisão. Nesta fase, excluímos os estudos que
claramente não estavam relacionados ao desenvolvimento ágil
de software. Por exemplo, como nossa estratégia de pesquisa incluía
todas as publicações do Currículo Lattes,
obteve vários “hits” em tópicos não relacionados, por exemplo,
Sistemas Distribuídos. Trabalhos com títulos que indicavam
claramente que o trabalho estava fora do escopo
esta revisão foram excluídos. No entanto, os títulos não são
sempre indicadores claros do que trata um artigo.
Nesses casos, os artigos foram incluídos para revisão
na próxima etapa. Nesta fase, 2.080 estudos foram
excluído.
Etapa 4. Excluir estudos com base em resumos e chaves
palavras. Os estudos foram excluídos se seu resumo
e/ou palavras-chave não estavam relacionadas ao
desenvolvimento ágil, o que deixou 128 publicações. Entre eles,
112 eram artigos em anais de conferências (87%)
e 16 eram artigos de periódicos (13%). Também foram
excluídas teses e dissertações utilizando os mesmos critérios,
resultando em 26 trabalhos de mestrado e doutorado sobre temas
relacionados a métodos ágeis.
A Figura 1 resume o processo de revisão, incluindo o
número de pesquisadores e trabalhos identificados em cada etapa.
4.2 Resultados
Descrevemos abaixo os resultados de nossa pesquisa na literatura, com
foco em responder RQ2 e todas as subquestões colocadas em
Seita 4.1.
4.2.1 Número de teses e dissertações relacionadas ao ágil
desenvolvimento de software
Identificamos 37 pesquisadores em desenvolvimento ágil de software.
De 1997 a 2011, eles orientaram 26 alunos de mestrado e doutorado
529
Tabela 1 Quantas teses e dissertações estão em andamento e têm
foi concluído?
Concluído Em andamento
Dissertações Tese Dissertações Tese
26 0 15 5
Fig. 2 Como é a colaboração/cooperação entre pesquisadores?
sobre temas relacionados. Como podemos ver na Tabela 1, parece haver
um aumento substancial no interesse dos estudantes de pós-graduação
no tópico de métodos ágeis.
Com relação aos subtópicos de métodos ágeis que foram
estudados pelos alunos de pós-graduação, vemos que a maioria dos
estudos identificados foi sobre agilidade em geral (12 de 26). Estudos sobre
XP vem em seguida, com sete trabalhos. A maioria dos estudos foi curta,
6 meses no máximo, completados em pequenas equipes, com até sete
membros da equipe e realizado em ambiente universitário. Quatro
temas foram recorrentes nos estudos: (1) como os métodos de
desenvolvimento ágil são introduzidos e adotados nas empresas,
(2) comparação do desenvolvimento ágil com uma alternativa,
(3) fatores humanos e sociais relacionados ao desenvolvimento ágil,
e (4) investigação de práticas ágeis específicas.
4.2.2 Colaboração e cooperação entre pesquisadores
Um exame do estado de origem das publicações
shows that most studies are from São Paulo and Pernam buco. The
University of São Paulo has the highest number
de publicações, seguido pela Universidade Federal de Pernambuco. A
Figura 2 apresenta as instituições que são mais
freqüentes na busca e sua coautoria.
As produções com títulos iguais ou semelhantes, dentro do mesmo
tipo e ano de publicação, são consideradas colaborações/cooperações
entre pesquisadores.
Outro achado interessante de nossa pesquisa bibliográfica é
os artigos mais citados sobre desenvolvimento ágil. Na Tabela 2 listamos
os quatro artigos mais citados de acordo com o Google Scholar
em 8 de dezembro de 2011.
123
Machine Translated by Google

530 J Braz Comput Soc (2013) 19:523–552

Tabela 2 Os quatro artigos brasileiros mais citados sobre software ágil Diários Conferências Total
desenvolvimento
20
Referências Citações 18
16
Goldman, A., Kon, F., Silva, PJSE, Yoder, JW 22 15 14
13
(2004) Sendo Extremo na Sala de Aula:
11
Experiências de Ensino XP, Revista do Brasileiro 10
10
Sociedade de Computadores, v. 10, págs. 5-21. [28] 8 8
7
Cagnin, M.I., Maldonado, J.C., Penteado, R.A.D., 16
Germano, FSR (2003) PERFEITO: Rumo a um 5 4
3 3
Processo de reengenharia ágil baseado em framework, 22 2
1 1
Anais da Conferência de Desenvolvimento Ágil, 000000
0000000000 0
págs. 22-31. [10]
0
Sato, D., Goldman, A., Kon, F. (2007) Tracking the 16 1998 2000 2002 2004 2006 2008 2010
Evolução das Métricas de Qualidade Orientadas a Objetos, Ano
Anais da VIII Conferência Internacional de
Programação Extrema e Processos Ágeis em Fig. 4 Publicações brasileiras em periódicos e congressos internacionais
Engenharia de Software, pág. 84-92. [57]
Silva, AF, Kon, F., Torteli, C. (2005) XP Sul de 12
Equador: Uma Experiência de Implementação do XP em
Brasil, Anais do VI International local14. Vemos que a Conferência Internacional sobre Agile
Conferência sobre eXtreme Programming e Agile
Software Development (XP), Conferência Latinoamericana
Processos em Engenharia de Software, pp. 1208-1211.
[67] de Informática (CLEI) e ESELAW têm o maior número
de papéis.
Para categorizar e analisar os estudos brasileiros, adotamos
um esquema de classificação semelhante ao de Dybÿa e Dingsøyr [24].
Os papéis caíram em três grupos principais:
WBMA WDRA ESELAW SBE Total

20 19
– Introdução e adoção: vários estudos abordaram como
métodos de desenvolvimento ágil são introduzidos e adotados em
15 14
empresas. A maioria dos estudos discutiu como o desenvolvimento
11 processo foi alterado e tratou o desenvolvimento ágil como
10 algo novo";
8 8
– Uso de ferramentas e práticas: vários estudos investigaram
5 44
ferramentas e práticas específicas de forma isolada, como par
3 3
2
11 1 programação ou desenvolvimento orientado a testes. A maioria dos
0 00000000000000000000000000000 0 0 000000 0 0
0 estudos relatou que as práticas de desenvolvimento ágil são fáceis
1995 2000 2005 2010 adotar e proporcionou bons resultados;
Ano – Percepções de métodos ágeis: vários estudos investigaram como os
métodos ágeis são percebidos por diferentes
Fig. 3 Publicações sobre Desenvolvimento de Software Ágil no WBMA,
ESELAW, WDRA e SBES grupos. Alguns abordaram como os clientes estão satisfeitos com
métodos ágeis e alguns focados na colaboração
entre um cliente e a equipe de desenvolvimento.

4.2.3 Pesquisa Brasileira em Desenvolvimento Ágil de Software
Encontramos 48 publicações científicas brasileiras sobre desenvolvimento
ágil de software publicadas em locais nacionais, como
SBES, WBMA, WDRA e ESELAW. A Figura 3 ilustra
a tendência das publicações entre 2003 e 2011.
O número de autores brasileiros e o número de Brasil
publicações internacionais na literatura científica internacional têm
cresceu substancialmente nos últimos 4 anos. A Figura 4 ilustra a
tendência das publicações internacionais entre 2003
e 2011. Antes de 2003, nenhuma publicação foi encontrada. Tabela 3
dá uma visão geral dos estudos de acordo com a publicação
Experiências do uso do desenvolvimento ágil de software
podem ser identificados principalmente em ambientes comerciais. Usando estes
como base, identificamos sérias limitações, por exemplo,
é difícil introduzir métodos ágeis em projetos com
grupos heterogêneos [67].
Esta revisão também mostra que muitos estudos promissores sobre o
uso de métodos ágeis foram relatados sugerindo que é
possível alcançar maior satisfação no trabalho, produtividade,
e aumento da satisfação do cliente [52,5,40].
14
Anteriormente conhecido pela Conferência Ibero-Americana de Engenharia
de Software (CIBSE).

123
Machine Translated by Google

J Braz Comput Soc (2013) 19:523–552 531

Tabela 3 Distribuição das publicações brasileiras por local de publicação e ocorrência

Canal de publicação Tipo Ocorrência Por cento

Conferência Internacional sobre Desenvolvimento Ágil de Software (XP) Conferência 14 18,7

Conferência Latino-Americana de Informática (CLEI) Conferência 7 9.3

Conferência de Desenvolvimento Ágil (AGILE) Conferência 5 6.7

Workshop Latino-Americano de Engenharia de Software Experimental (ESELAW) Conferência 4 5.3

Conferência Internacional de Engenharia de Software e Engenharia do Conhecimento (SEKE) Conferência 4 5.3

Conferência Ibero-Americana de Engenharia de Requisitos e Ambientes de Software (IDEAS) Conferência 4 5.3

Revista da Sociedade Brasileira de Computação (JBCS) Diário 3 4,0

Conferência Latino-Americana de Metodologias Ágeis (AGILES) Conferência 3 4,0

Inovações em Engenharia de Sistemas e Software (ISSE) Diário 2 2.7

Conferência Internacional de Manufatura Ágil (ICAM) Conferência 2 2.7

International Journal of Advanced Manufacturing Systems (JAMS) Diário 2 2.7

Workshop Internacional de Engenharia de Requisitos (WER) Conferência 2 2.7

Grupo de Trabalho Internacional de Pesquisa em Colaboração (CRIWG) Conferência 1 1.3

Conferência sobre Educação e Treinamento em Engenharia de Software (CSEE&T) Conferência 1 1.3

Conferência Europeia sobre Trabalho Cooperativo Apoiado por Computador (ECSCW) Conferência 1 1.3

Iadis International Conference Information Systems (IADIS) Conferência 1 1.3

Conferência Internacional da Information Resources Management Association (IRMA) Conferência 1 1.3

Conferência Internacional de Engenharia de Software Global (ICGSE) Conferência 1 1.3

Conferência Internacional sobre Avanços em Engenharia de Software (ICSEA) Conferência 1 1.3

Conferência Internacional sobre Teste, Verificação e Validação de Software (ICST) Conferência 1 1.3

Conferência Internacional sobre a Qualidade da Informação e das Comunicações Conferência 1 1.3

Tecnologia (QUÁTICA)
Conferência Internacional de Engenharia Web (ICWE) Conferência 1 1.3

Jornada Ibero-Americana de Engenharia de Software Conferência 1 1.3

e Engenharia do Conhecimento (JIISIC)
Jornal de Manutenção e Evolução de Software (JSME) Diário 1 1.3

Jornal de Sistemas e Software (JSS) Diário 1 1.3

Miniconferência Latino-Americana sobre Linguagens de Padrões de Programação (MINIPLoP) Conferência 1 1.3

Open Cirrus Summit Conferência 1 1.3

Portland International Center for Management of Engineering and Technology (PICMET) Conferência 1 1.3

Simpósio Internacional de Melhoria de Processo de Software e de Sistemas (SIMPROS) Conferência 1 1.3

Conferência de Qualidade de Software e Sistemas (SQS) Conferência 1 1.3

Workshop de Governança de Desenvolvimento de Software (SDG) Conferência 1 1.3

Software Engineering Process Group Latin America (SEPG) Conferência 1 1.3

Software, Experiência Prática (SPE) Diário 1 1.3

Workshop sobre Tratamento de Exceções em Sistemas de Software Contemporâneos (EHCoS) Conferência 1 1.3

Workshop sobre o Ensino de Teste de Software (WTST) Conferência 1 1.3

Também podemos notar uma crescente adoção de métodos de base
empírica na pesquisa brasileira em colaboração com
indústria, como pesquisas [2], teoria fundamentada [53] e
estudos de casos múltiplos [40].
O principal achado desta revisão é que parece haver
ser um interesse substancial no desenvolvimento ágil de software
entre os ambientes de pesquisa. A partir da apresentação de
dos artigos mais citados, podemos observar que a maioria
artigos altamente citados são publicados em conferências. Além disso,
verificamos que o número de autores brasileiros e
o número de publicações brasileiras na literatura científica internacional
cresceu substancialmente nos últimos
4 anos. Esses resultados são muito semelhantes a um estudo internacional
análise da literatura sobre desenvolvimento ágil de software feita por
Dingsøyr et al. [21]. Por exemplo, os quatro artigos brasileiros mais citados
apresentaram 22, 16, 16 e 12 citações, respectivamente. Na lista dos 20
artigos mais citados sobre desenvolvimento ágil de software em todo o
mundo, Dingsøyr et al. [21] encontrado
artigos cujo número de citações variou entre 61 e
14.

123
Machine Translated by Google

532 J Braz Comput Soc (2013) 19:523–552

5 métodos ágeis na indústria Tabela 4 Subquestões de pesquisa, variáveis de pesquisa e tipo de escala

Sub-pergunta Variável de pesquisa Tipo de escala

Apesar do fato de que os métodos ágeis têm sido cada vez mais
SQ1 Experiência pessoal com ágil Ordinal
adotaram e rapidamente aderiram ao mainstream das abordagens de
Posição atual Nominal
desenvolvimento [77], sua adoção na TI brasileira
indústria não tem sido muito estudada na literatura técnica. Nosso objetivo Exposição atual Nominal

é investigar o início, o crescimento e o estabelecimento de métodos ágeis SQ2 Tamanho da TI da empresa Ordinal

nesta comunidade por meio do RQ3: Experiência da empresa Ordinal

Como a prática de métodos ágeis evoluiu na TI brasileira Domínio comercial Nominal

indústria? Localização da empresa Nominal

Para tanto, realizamos uma pesquisa dividida em dois SQ3 Campeão Nominal

fases, adotando uma abordagem de método sequencial misto [19]. Preocupações Binário
Primeiro, realizamos uma pesquisa no Brasil para reunir dados quantitativos Motivos para adotar o Agile Ordinal
dados sobre o estado da prática ágil. Depois disso nós SQ4 Percentual de projetos usando Agile Ordinal
elaborou um estudo qualitativo com o objetivo não só de verificar se Porcentagem de equipes distribuídas Ordinal
nossos resultados da pesquisa foram válidos ou não, mas também para interpretar
Método ágil adotado Binário
melhor as relações estatísticas.
Práticas ágeis adotadas Binário

SQ5 Benefícios Ordinal

5.1 Projeto de pesquisa
Velocidade ágil do projeto Binário

SQ6 Causas do projeto Agile com falha Binário

5.1.1 Fase 1 - Estudo quantitativo
Barreiras para adoção adicional Binário

Nosso principal objetivo foi dar um passo inicial para entender o estado da
prática dos métodos ágeis na TI brasileira
indústria. Para melhor focar nossa coleta e análise de dados, técnicas de amostragem, como conveniência e bola de neve

dividiu o RQ3 em seis subquestões: métodos para atrair os participantes da nossa pesquisa. Por exemplo,
métodos de conveniência recrutam entrevistados de comunidades on-line

• SQ1. Quais são as características dos praticantes ágeis? e fóruns de discussão. A amostragem bola de neve é baseada

• SQ2. Quais são as características das empresas ágeis? sobre a prática de pedir aos participantes que encaminhem outra pessoa

• SQ3. Qual era o contexto das empresas quando para a pesquisa, e assim por diante.

adotado ágil? Testamos a pesquisa com cinco praticantes ágeis para

• SQ4. Como os métodos ágeis estão sendo adotados? verificando sua consistência e validade aparente [63]. Então nós

• SQ5. Quais são as percepções após a adoção ágil? extraiu possíveis participantes da pesquisa de vários bancos de dados,

• SQ6. Quais são os principais desafios ao adotar o ágil? como listas de discussão, participantes de conferências ágeis anteriores e
Contatos comerciais da AgilCoop16 . Enviamos a eles um convite por e-

Para responder a essas subquestões, desenvolvemos um mail para participar da pesquisa e também convidamos seus negócios

questionário15 composto por 19 perguntas, a maioria Contatos. Coletamos dados ao longo de um período de pesquisa de seis meses.

com base em uma pesquisa global anterior sobre métodos ágeis realizada Análise dos dados A análise dos dados da pesquisa foi realizada

pela VersionOne [73]. A Tabela 4 apresenta todas as 18 variáveis, tipos por dois pesquisadores e revisado por todos os coautores. Desde o

de escala e sua relação com a pesquisa amostra não é probabilística, não podemos generalizar estatisticamente

sub-questões. Cada variável está relacionada a uma questão da pesquisa os resultados. No entanto, podemos realizar análises estatísticas para

(Apêndice A), exceto a última questão referente ao explorar dados e gerar proposições. Assim, preparamos os dados para

contato do respondente. A pesquisa usa uma estrutura de escala Likert, realizar três análises estatísticas: descritiva

que requer escolhas entre valores na escala. análise de todas as variáveis, medidas de associação qui-quadrado

Coleta de dados Ao realizar pesquisas baseadas em pesquisas, a entre variáveis categóricas e tabelas de contingência, e

amostragem probabilística dos participantes permite fazer Correlação de Spearman's Rank Order entre as variáveis ordinais.

inferências sobre características da população com base em dados Adotamos as definições operacionais fornecidas por Cohen

amostrais. No entanto, a obtenção de uma amostra aleatória de Internet [14], uma das diretrizes mais conhecidas para interpretar a magnitude dos

usuários é problemático, se não impossível [63]. Assim, usamos coeficientes de correlação. Dados de pesquisa

técnicas de amostragem não probabilísticas, recomendadas para apoiou análises interessantes, como os participantes pro

pesquisa exploratória [69]. Combinamos não probabilísticas

16
Cooperativa de desenvolvimento ágil de software composta pelo IME-USP
15
https://www.surveymonkey.com/s/KX93PGZ. professores, alunos e ex-alunos.

123
Machine Translated by Google

J Braz Comput Soc (2013) 19:523–552 533

arquivo, os métodos e práticas ágeis mais adotados, os principais Tabela 5 Distribuição das empresas brasileiras de TI por região e distribuição
motivos e preocupações ao adotar métodos ágeis, que foram das regiões respondentes

os campeões, os desafios e benefícios mais importantes, Região Distribuição de PROFSS Nossa amostra
bem como barreiras e causas de projetos ágeis fracassados. por região* % de entrevistados
% profissionais de TI

5.1.2 Fase 2 - Estudo qualitativo Sudeste 56,6 58,8

Sul 13.6 10,4
As informações coletadas em estudos qualitativos podem auxiliar na Nordeste 15,3 13,7
análise, esclarecimento, validação e interpretação da pesquisa Norte 5.3 4,0
dados de várias maneiras [64]. O protocolo do estudo qualitativo foi,
Centro Oeste 9.2 11.6
portanto, projetado para explorar ainda mais as descobertas mais relevantes
* Softex [68], pág. 134
da pesquisa. Elas englobam: (1) principais razões para a agilidade
adoção de métodos por tamanho da empresa, (2) métodos ágeis mais adotados
práticas por experiência da empresa, (3) benefícios percebidos de
potencial para viés ou distorção, melhoramos a confiabilidade.
implementação de métodos ágeis e (4) barreiras ou desafios
Por fim, coletamos dados de várias fontes de evidência
para adoção de métodos ágeis por porte de empresa.
para aumentar a confirmabilidade.
Coleção de dados. Coletamos dados de sete semi

entrevistas estruturadas com perguntas abertas [36] em sete

5.2 Fase 1: resultados do estudo quantitativo
empresas brasileiras. Os critérios de seleção consideraram empresas no Brasil
com diferentes portes, áreas de negócios, localidades e experiência em
Descrevemos abaixo nossas principais descobertas quantitativas com base em
métodos ágeis como forma de aprimorar
os dados da pesquisa.
triangulação de dados. As Tabelas 10 e 11 descrevem empresas e
perfis dos entrevistados respectivamente. Preservamos sua identidade
5.2.1 Amostra de pesquisa
identificando as empresas e seus entrevistados com cartas. As entrevistas
duraram de 40 a 90 min e interessantes
Iniciamos a coleta de dados da pesquisa em maio de 2011 e terminamos em
expressões foram transcritas.
outubro de 2011. Nesse período, tivemos 471
Os resultados da Fase 1 (estudo quantitativo) destacaram aspectos
respostas. Para verificar a representatividade da nossa amostra, com
interessantes, como os quatro tópicos mencionados acima, para
em relação à distribuição geográfica, comparamos com a
explorar nas entrevistas. Isso nos ajudou a desenvolver o protocolo de
número de profissionais brasileiros de TI [68]. A Softex investigou a indústria
entrevista, que também incluiu um tópico sobre o futuro da
brasileira de TI, triangulando um grande corpo de
adoção ágil no Brasil, conforme descrito no Apêndice. Por isso,
informações e dados de diferentes órgãos governamentais17.
realizamos coleta de dados qualitativos para aprofundar o entendimento sobre
Com base neste mapeamento, a Softex propôs o PROFSS
as principais razões, barreiras ou desafios para
(software formal e profissionais de TI). PROFSS pode
adoção de métodos ágeis, práticas ágeis mais adotadas e
ser gerentes de TI; administradores de rede, sistemas e banco de dados;
benefícios percebidos da implementação de métodos ágeis.
projetistas e analistas de sistemas de computador; e relacionado
Análise dos dados Realizou-se a análise qualitativa dos dados
ocupações como assistentes de computador e operadores. Nós
através da identificação de expressões interessantes para cada
usou as estatísticas mais recentes do PROFSS para compará-lo com o nosso
entrevista transcrita pelo entrevistador. Depois disso, seguindo
amostra, como mostrado na Tabela 5. Nossa amostra cobre melhor o
[26], aplicamos o pluralismo na pesquisa qualitativa cruzando
Regiões Sudeste e Centro-Oeste. No entanto, consideramos a
as descobertas individuais de cada entrevistador com o outro
amostra representativa das demais regiões brasileiras, já que sua
entrevistadores para identificar significados que possam ser agrupados em
distribuição não estava longe da distribuição PROFSS.
conceitos temáticos. Nosso primeiro objetivo no processo de análise de dados
foi para confirmar ou refutar os resultados da nossa pesquisa. Em seguida, tentamos
5.2.2 Perfil dos participantes
reconhecer padrões para buscar aspectos particulares que possam
fornecer tendências ou explicações valiosas para a estatística
Para caracterizar os participantes da pesquisa, coletamos dados
relacionamentos.
sobre sua experiência com métodos ágeis, posição atual,
Critérios de rigor qualitativo. Seguimos os critérios de confiabilidade de
e exposição ao desenvolvimento ágil. A Figura 5 resume o
Guba e Lin para validade [29] critérios de confiabilidade para critérios de
validade. Tentamos fornecer um detalhamento
descrição e cotações relevantes para aumentar a transferibilidade. Para 17 As principais fontes foram o PAS (Pesquisa Anual de Serviços) e
Pesquisas da PINTEC (Pesquisa de Inovação Tecnológica), realizadas pela
fortalecer a credibilidade, verificamos e revisamos
IBGE-Brasil, o Cadastro Central de Empresas, também mantido pela
os dados coletados e os coautores discutiram a descoberta
IBGE, e a RAIS (Relação Anual de Informações Sociais), realizada
entre si. Ao apresentar nossos julgamentos sobre pelo Ministério do Trabalho.

123
Machine Translated by Google

534 J Braz Comput Soc (2013) 19:523–552

7% Gerente de produto 1,5%

> 5 anos
Presidente 1,7%
Consultor 4,2%
3 - 5 anos 29,5%
CIO/CTO 4,5%
Controle de qualidade/Testador 4,9%
1 - 2 anos 28,5%
Gerente de desenvolvimento 6,4%
Posição
atual
Arquiteto 6,8%
6 - 11 meses 15,1%
Gestor de projeto 11,5%
Outro 11,5%
< 6 meses 14% Líder da equipe 12,1%
Experiência
pessoal
Agile
com

Desenvolvedor sênior 16,6%

Nunca 5,9%
Desenvolvedor 18,5%

0 50 100 150 0 20 40 60 80 100

contar contar

Já ouvi falar - mas não em profundidade - aprendendo mais agora 5,3%

Considerando a introdução do Agile em uma equipe pela primeira vez 9,6%

Anteriormente um membro de uma equipe de desenvolvimento Agile 10,4%

Exposição
atual
Coach ou consultor ágil 11,7%

Atualmente liderando uma equipe de desenvolvimento ágil 27,8%

Atualmente membro de uma equipe de desenvolvimento Agile 35,2%

0 50 150 200
contagem de 100

Fig. 5 Perfil pessoal dos participantes

perfil dos participantes. A experiência dos participantes na prática de > 250 15,7%
101 - 250 7%
métodos de desenvolvimento ágil é principalmente entre três e 51 - 100 9,8%
21 - 50 13,8%
5 anos (29,5%), e depois entre 1 e 2 anos (28,5%).
Tamanho
empresa
da
TI

6 - 20 38,2%
Os resultados mostram que mais de 50% dos praticantes <5 15,5%

0 50 150 200
já migraram para métodos ágeis, com pelo menos 1 ano
contagem de 100
de experiência.
A posição atual dos participantes (Fig. 5) variou muito
> 5 anos 8,5%
de desenvolvedor a funções de gerente de produto, garantindo a diversidade 3 - 5 anos 24,8%
1 - 2 anos 31,4%
em nossa pesquisa. Conta de desenvolvedores e desenvolvedores seniores 6 - 11 meses 13,2%
< 6 meses 11,7%
para 35,1% dos participantes. Líderes de equipe e gerentes de projeto Experiência
empresa
da

Nunca 10,4%
respondem por 23,6%. Esse resultado aponta que
0 50 150
mais da metade dos entrevistados desempenha um papel de desenvolvedor contagem de 100

ou gerente. Na opção “Outros”, que representa 11,5%

de nossos entrevistados, existem funções como analista de sistemas, Fig. 6 Perfil das empresas do participante—tamanho de TI e experiência com
Métodos ágeis
analista de negócios, analista de requisitos, pesquisador e
treinador.

Finalmente, a Fig. 5 mostra o nível atual de Os resultados apontam que mais da metade das empresas
exposição ao desenvolvimento ágil. A maioria dos participantes são estão experimentando ou efetivamente usando ágil, tendo pelo menos
atualmente membros, líderes ou coaches de uma equipe ágil. 1 ano de experiência nesta empreitada.
A Figura 7 enquadra a atividade principal da organização. A maioria
deles estão relacionados com a Internet, Governo ou
5.2.3 Perfil das empresas participantes
Escritório/Empresa. Na opção “Outros”, muitos deles são

Caracterizamos o perfil das empresas participantes por associadas a fábricas de software, tecnologia da informação

descrevendo o tamanho da equipe de TI da empresa, sua experiência com (TI) em geral, e segmentos de pesquisa e desenvolvimento (P&D). A Figura

métodos ágeis, localização e área de negócios. Figuras 6 e 7 7 também apresenta a localização das organizações. São
ilustrar nossos resultados. Paulo, Rio de Janeiro, Distrito Federal and Minas Gerais host

A maioria das empresas participantes (Fig. 6) são pequenas ou muito maioria das empresas.

pequenas organizações, com um tamanho médio de departamento de TI

menor que 20 pessoas. No entanto, 23,6 % das empresas empregam 21 a
100 pessoas e 22,7 % empregam mais de
100 pessoas na área de TI. A experiência da empresa na prática de métodos
de desenvolvimento ágil é principalmente entre um e
2 anos (31,4 %), e depois entre 3 e 5 anos (24,8 %).
5.2.4 Adoção de métodos ágeis
Nossa pesquisa descreve o contexto das empresas ao adotar
métodos ágeis, com foco em quem foi o campeão, o principal
razões que consideram relevantes para adotar o desenvolvimento ágil

123
Machine Translated by Google

J Braz Comput Soc (2013) 19:523–552 535

Segurança 0,6% Sergipe ÿ SE 0,2%

Multimídia Alagoas ÿ AL 0,2%

0,6%
Mato Grosso - MT 0,4%
Jogos/Entretenimento 1,1%
Rio Grande do Norte ÿ RN 0,6%
Energia 1,1%
Paraiba ÿ PB 0,6%
ERP 1,1% Goias ÿ GO 0,6%
Óleo e gás 1,5% Mato Grosso do Sul - MS 0,8%

Sistemas incorporados 1,5% Piaui ÿ PI 1,1%

Móvel Espírito Santo - PT 1,3%

1,7%
Pará - PA 1,9%
Financeiro 2,8%
Amazonas ÿ AM
comercial
Domínio

Localização
empresa
da

2,1%
Saúde/bem-estar 3%
Santa Catarina – SC 2,5%
Comunicações 3,6% Paraná - PR 2,8%
Consultando serviços 5,3% Bahia – BA 3,2%

Científico/Engenharia 5,5% Cera - CE 4%

Educação Pernambuco – PE 4,9%

6,2%
Rio Grande do Sul ÿ RS 5,1%
Outro 7,2%
Minas Gerais ÿ MG 7,9%
Escritório/Empresa 12,5%
Distrito Federal ÿ DF 10%
Governo 20,8% Rio de Janeiro ÿ RJ 13,2%
Internet 24% Sao Paulo ÿ SP 36,5%

0 50 100 150 0 50 150 200

contar contagem de 100

Fig. 7 Perfil das empresas participantes – localização e área de negócios

Diretor de desenvolvimento 6,2% Incapacidade de escalar 11,9%

Sem preocupações 12,5%
Presidente 8,3% 21,2%
Qualidade de software reduzida
Conformidade regulatória 24,8%
CIO/CTO 10,4% Preocupações

Campeão Falta de disciplina de engenharia 25,7%

Gerente de desenvolvimento 11,5% Equipe de desenvolvimento contra a mudança 32,1%
Falta de treinamento da equipe 34,8%
Gestor de projeto 13,8%
Perda de controle de gestão 37,6%
Líder da equipe 23,6% Falta de planejamento antecipado 41%
Falta de previsibilidade 43,5%
Desenvolvedor 26,3% Falta de documentação 51%

0 50 100 150 0 50 100 150 200 250

contar contar

Simplifique o processo de desenvolvimento 80% 20%

Reduzir o risco 69% 31%
Reduzir o custo 47% 53%

Aumentar a produtividade 91% 9% Resposta

Melhorar o moral da equipe 64% 36%
Maior importância
Melhore a visibilidade do projeto 65% 35%

Melhorar a disciplina de engenharia 59% 41% Muito importante

Melhorar o alinhamento entre TI e negócios 72% 28%
um pouco importante
Motivos
adotar
Agile
para
o
Melhore a qualidade do software 83% 17%

Melhore a extensibilidade da manutenibilidade do software 66% 34% Nada importante

Melhorar a capacidade de gerenciar prioridades em mudança 86% 14%

Acelere o tempo de colocação no mercado 73% 27%

0 20 40 60 80 100

Percentagem

Fig. 8 Campeões, preocupações e razões para adotar o Agile

métodos, e quais preocupações as empresas têm naquele momento. líderes e gerentes de projeto, respondendo por 63,7% de nossos
A Figura 8 resume os principais achados. entrevistados. A iniciativa parece vir principalmente das equipes de
Nossos resultados apontam que os campeões mais frequentes desenvolvimento, não da alta administração, corrobo avaliando nossa
de métodos ágeis nas empresas foram Desenvolvedores, Equipe impressão de que, no Brasil, a grande maioria dos

123
Machine Translated by Google

536 J Braz Comput Soc (2013) 19:523–552

gerentes e CTOs não estão atualizados com os avanços no desenvolvimento
de software.
A Figura 8 ilustra os principais motivos que levaram as empresas a
adotar métodos ágeis. Nossos resultados mostram que o motivo mais
importante foi o aumento da produtividade (91%), seguido por
Gerenciar mudanças de prioridades (86%) e Melhorar a qualidade do
software (83%). Havia outras expectativas, como
como Simplificar o processo de desenvolvimento e Acelerar o tempo de
Também exploramos a distribuição geográfica de métodos ágeis
equipes. Apesar de a maioria das equipes não estar distribuída (68,8%),
uma parcela significativa dos respondentes
(31,2%) são experientes em ambientes distribuídos. Esse
resultado aponta que as equipes de desenvolvimento de software distribuído
pode ser ágil. No entanto, nesta fase de pesquisa, não
explorar os pontos fortes e fracos ágeis em sistemas distribuídos
equipes.

comercialização. As razões, portanto, estão alinhadas com as reivindicações
dos mentores ágeis [4,62]. Surpreendentemente, 53% dos entrevistados
não considera Reduzir custos como uma razão imperativa para adotar
ágil.
Ao adotar os métodos ágeis, as empresas também ficaram preocupadas
com a mudança, como mostra a Figura 8. As preocupações mais frequentes
foram Falta de documentação, previsibilidade,
planejamento inicial e controle de gestão. Alguns entrevistados (12,5%)
relataram não se preocupar com a adoção ágil
em suas empresas.
5.2.5 Práticas de métodos ágeis
Após a primeira análise dos perfis dos participantes e da empresa, e seu
contexto na adoção de métodos ágeis, investigamos
até que ponto as empresas adotam métodos ágeis. Figura 9
mostra o percentual de projetos de empresas que adotam métodos ágeis
métodos, e se as empresas estão usando métodos ágeis com
equipes. Muitos entrevistados (30,4%) indicaram que todos os
os projetos da empresa adotam o ágil. Isso provavelmente se deve ao
grande quantidade de pequenas empresas da amostra, onde
mais fácil de implantar novos métodos de desenvolvimento. Há também
empresas jovens que nasceram de forma ágil. No entanto,
resumindo as respostas, descobrimos que mais da metade dos
entrevistados (51%) estão usando métodos ágeis em menos de 50%
de seus projetos. Esse resultado mostra que as empresas brasileiras
ainda estão migrando para métodos ágeis, ou possivelmente usando
certos tipos de projetos.
Além disso, investigamos os métodos e práticas ágeis mais adotados
pelas empresas. Scrum foi considerado o método ágil mais seguido,
respondendo por 51,2%
de participantes (Fig. 10). Foi sucedido pela combinação de Scrum e XP,
respondendo por 22,5%. Híbrido
métodos, como híbrido personalizado e Scrumban, respondem por
12,1% dos participantes. Um pequeno grupo (4,2%) está empregando o
desenvolvimento Lean [48], uma adaptação dos princípios lean para o
mundo do desenvolvimento de software. Na opção
“Outro”, a maioria dos entrevistados afirmou Desenvolvimento Orientado a Testes
(TDD), FDD/Scrum Hybrid, e o uso de XP/Scrum com
PMBOK.
Para avaliar as práticas ágeis, tomamos emprestada uma lista de
práticas de pesquisas realizadas pela VersionOne [72,73] devido
ao seu grande impacto executando pesquisas ágeis em todo o mundo. A
Figura 10 mostra que Planejamento de Iteração, Retrospectivas, Unidade
Testing, Daily Standup e Refactoring são os cinco mais
práticas adotadas, segundo nossos entrevistados. Essas práticas
representam aspectos de gestão, melhoria contínua, qualidade e arquitetura
valorizada nas equipes. no entanto
não está claro se essas práticas são mais adotadas do que
outros ou se existe alguma relação entre práticas e
outras variáveis, como tamanho da empresa ou experiência. Esse
nos motivou a explorar em detalhes possíveis explicações,
mostrado nas seitas. 5.2.8 e 5.3.2. Na opção 'Outro', os respondentes
declararam práticas como Storymaps18, Niko-niko19, QA
checklists e quadro de “sensação de produtividade”.
5.2.6 Benefícios percebidos da adoção de métodos ágeis

300
250 Com a adoção ágil, as organizações podem se beneficiar de muitas
200 maneiras, a Fig. 11 revela os benefícios percebidos. O mapa de calor
150 30,4%
100 18,7% ilustra tendências sobre as percepções das empresas. Nosso resultado
11,3% 12,1%
50 7,2% 8,7% 11,7%
0
mostra que Produtividade (69,21 %), Capacidade de gerenciar mudanças
0% 5% 10% 25% 50% 75% 100% de prioridades ( 67,94 %), Moral da equipe (66,87 %), Simplificado
% de projetos usando Agile processo de desenvolvimento (60,93%) e Qualidade (60,29%)
melhorado ou significativamente melhorado após a adoção de métodos ágeis
350 68,8%
métodos. O benefício mais baixo foi a capacidade de Gerenciar equipes
300
250 distribuídas (24,84%). No entanto, a maioria dos entrevistados
200 31,2%
150
100
50
0
18
Não Sim Jeff Patton introduziu essa prática no artigo “Tudo depende de como você
Equipes distribuídas Slice It”, http://www.abstractics.com/papers/HowYouSliceIt.pdf.

19 Um calendário japonês de humor / moral da equipe introduzido por Akira

Fig. 9 Uso ágil nas empresas Sakata, http://www.geocities.jp/nikonikocalendar/index_en.html.

123
Machine Translated by Google

J Braz Comput Soc (2013) 19:523–552 537

250 51,2%
Outro 4%
200 13,8%
Desenvolvimento Orientado ao Comportamento (BDD)
150 19,3%
22,5% Teste de aceitação automatizado
100 Áreas de trabalho abertas 27,8%
50 8,1% 7,2% Implantação contínua 31,4%
4% 2,8%1,7%1,5%0,6%0,2%0,2% 32,1%
0 Quadro de tarefas digital
36,3%
D/
N
Cliente no local
39,5%
Outro
Scrum
Desenvolvimento Orientado a Testes (TDD)
Velocidade 40,3%
Scrumban

Não
sei
Programação em pares 43,1%
contar
Compilações automatizadas 45,6%
personalizado
Híbrido
Modelagem
Ágil
Kanban 46,9%
Scrum/
Híbrido
XP

Propriedade coletiva do código 48,8%

Desenvolvimento
Lean

Planejamento de lançamento 51,8%

Padrões de codificação 53,1%
Adotadas
Práticas
Ágeis Integração contínua 55%
Queimar 55,4%
Programação
Extrema
(XP)
Reestruturação 58,8%
Levantamento Diário 64,1%
Teste de unidade 66%
Retrospectivas 67,9%
Desenvolvimento
Orientado
Recursos
(FDD)
a
Planejamento de iteração 69,6%

0 100 200 300 400

Método ágil adotado contar

Fig. 10 Métodos e práticas ágeis mais adotados

Tempo de mercado 3,05 (1,9) 22,51% 32,91% 16,35% 0,64% 0,42% 27,18%

Moral da equipe 2,74 (1,9) 31,63% 35,24% 8,28% 1,06% 0,21% 23,57%

Manutenibilidade do software 3,08 (1,9) 20,17% 29,94% 22,93% 0,85% 0,64% 25,48%

Simplifique o processo de desenvolvimento 2,90 (1,9) 23,99% 36,94% 13,59% 0,85% 0,21% 24,42%

Redução de risco 3,16 (1,8) 13,80% 37,79% 19,11% 3,18% 0,42% 25,69%

Qualidade 2,86 (1,9) 25,90% 34,39% 14,44% 1,27% 0,64% 23,35%

Visibilidade do projeto 2,82 (1,9) 30,79% 32,06% 11,25% 0,85% 0,42% 24,63%

Produtividade 2,74 (1,9) 27,60% 41,61% 6,79% 0,42% 0,21% 23,35%

Gerenciar equipes distribuídas 4,07 (1,8) 6,37% 18,47% 26,96% 2,97% 0,21% 45,01%

Gerenciar mudanças de prioridades 2,69 (1,9) 33,97% 33,97% 8,07% 0,42% 0,21% 23,35%

Disciplina de engenharia 3,24 (1,8) 12,95% 32,91% 25,27% 2,12% 0,00% 26,75%

Redução de custos 3,41 (1,8) 10,62% 27,60% 30,57% 2,12% 0,00% 29,09%

Alinhamento TI - Negócios 3,06 (1,9) 19,96% 35,67% 16,56% 0,85% 0,42% 26,54%

Média (SD) Significativamente melhorada Melhorada Sem benefício Pior Muito pior N/D

Por cento
0 25 50 75 100

Fig. 11 Benefícios percebidos da implementação de práticas ágeis

não experimentam desenvolvimento distribuído, o que diminui a
relevância desse resultado.
Em relação à velocidade efetiva do projeto obtida com a
implementação de métodos ágeis, conforme mostrado na Figura 12, a
maioria dos entrevistados (67,1%) indicou que os projetos ágeis
proporcionam um tempo de conclusão mais rápido. Para 13,2% dos
entrevistados, os projetos ágeis têm o mesmo tempo de conclusão. Um
grupo menor (0,8%) achou os projetos ágeis mais lentos para serem concluídos. finalmente,
as causas
de projetos ágeis fracassados e barreiras significativas para
outros entrevistados (18,9%) ainda não concluíram um projeto ágil para
responder a essa pergunta. O resultado geral aponta que o ágil leva a
uma melhor velocidade do projeto.
5.2.7 Principais desafios da adoção de métodos ágeis
As últimas perguntas de nossa pesquisa tiveram como objetivo explorar
o

123
Machine Translated by Google

538 J Braz Comput Soc (2013) 19:523–552

Tempo mais lento para conclusão 0,8%
Mesmo tempo para conclusão
Projeto ainda não concluído e ágil
eram sobre adaptação aos processos institucionalizados na
organização (por exemplo, PMBOK, Mps.Br), falta de disciplina e
13,2%
crença em métodos ágeis, questões interpessoais e funcionários
18,9% volume de negócios.

Tempo mais rápido para conclusão 67,1%

O resultado geral aponta que capacidade de mudança de cultura
e aprendizado são, definitivamente, os principais players na transição
0 100 200 300 400 contagem
completa das empresas para métodos ágeis.

Fig. 12 Velocidade do projeto após a implementação de práticas ágeis

adoção nas empresas. A Figura 13 resume nossas principais
descobertas.
Um grupo expressivo de respondentes (36,3%) afirmou que seus
projetos ágeis não falharam. No entanto, os outros 63,7% dos
entrevistados indicaram algumas causas para o fracasso de projetos ágeis.
A falta de experiência com métodos ágeis foi a resposta mais
frequente, respondendo por 16,3% dos entrevistados. A filosofia/
cultura da empresa em desacordo com os valores centrais da agilidade
e a pressão externa para seguir as práticas tradicionais em cascata
também foram motivos importantes que levaram ao fracasso. Na
opção “Outros”, os respondentes indicaram falta de treinamento do
Product Owner e do cliente, má gestão de expectativas, falta de
controle de escopo e dificuldade para gerenciar dependências
externas, principalmente com equipes não ágeis que interferem nos
projetos, levando ao insucesso.
No momento, uma adoção ágil mais ampla é prejudicada pelas
barreiras apresentadas na Figura 13. As três barreiras mais frequentes
que limitam a adoção ágil foram a capacidade de mudar a cultura
organizacional (50,7%), a disponibilidade de pessoal com as
habilidades necessárias (43,3%) , e Resistência geral à mudança
(41,4%). Na opção “Outros”, as principais preocupações
5.2.8 Relacionamentos entre a experiência das empresas, tamanho
e fatores e percepções de adoção do Agile
Também analisamos associações e correlações entre todas as
variáveis da pesquisa. A seguir, descrevemos as relações mais
importantes que encontramos.
Relação entre experiência da empresa e adoção de práticas
ágeis. O valor Qui-Quadrado (ÿ2) para a associação entre as práticas
ágeis adotadas e a experiência da empresa variou para cada prática,
conforme mostrado na Tabela 6. A relação entre a maioria das práticas
e a experiência da empresa foi superior a 40 com cinco graus de
liberdade (df ) e uma probabilidade de significância (p) menor que
0,001—ou seja, um resultado muito significativo em níveis
convencionais. Na evidência desses dados, há uma associação entre
o grau de adoção das práticas e a experiência da empresa.
Portanto, podemos interpretar que empresas mais experientes
tendem a adotar práticas mais ágeis. No entanto, essa tendência
muda conforme a função de cada prática. Destacamos em negrito, na
Tabela 6, a faixa de experiência em que cada prática foi mais adotada.
Cada porcentagem representa a frequência relativa de adoção da
prática no intervalo. Podemos observar que, por um lado, existem
práticas mais

Falta de transição cultural 3,2%

Falta de suporte gerencial 3,6%
Falta de vontade da equipe 5,1%
Treinamento insuficiente 5,5%
Outro 6,6%
Pressão externa para seguir as práticas tradicionais em cascata 10,6%
Filosofia/cultura da empresa em desacordo com os valores centrais da agilidade 12,7%
Falta de experiência com métodos ágeis 16,3%
Isso não aconteceu na minha organização 36,3%

0 50 150 200
contagem de 100

Restrições de orçamento 8,1%

Outro 11,3%
Tempo percebido para a transição 14,9%
Confiança na capacidade de escalar ágil 15,3%
Complexidade ou tamanho do projeto 26,3%
Suporte de gestão 28,5%
Colaboração do cliente 38%
Resistência geral à mudança 41,4%
Disponibilidade de pessoal com as habilidades necessárias 43,3%
Capacidade de mudar a cultura organizacional 50,7%

0 50 100 150 200 250 300

contar

Fig. 13 Causas de projetos ágeis fracassados e barreiras para adoção posterior

123
Machine Translated by Google

J Braz Comput Soc (2013) 19:523–552 539

Tabela 6 Tabela de contingência mostrando o percentual de adoção de práticas ágeis por experiência da empresa

Práticas <6 meses 6-11 meses 1-2 anos 3-5 anos >5 anos Total ÿ2 df

n% n% n% n% n% n%

Planejamento de iteração 36 65,5 47 75,8 103 69,6 104 89,7 29 72,5 319 75,6 83,15*** 5

Retrospectivas 27 49,1 40 64,5 106 71,6 107 92,2 31 77,5 311 73,7 96,88*** 5

Standup diário 25 45,5 34 54,8 107 72,3 97 83,6 29 72,5 292 69,2 74,81*** 5

Teste de unidade 28 50,9 30 48,4 93 62,8 101 87,1 34 85,0 286 67,8 47,70*** 5

Queimar 25 45,5 35 56,5 98 66,2 79 68,1 18 45,0 255 60,4 54,88*** 5

Reestruturação 24 43,6 28 45,2 87 58,8 84 72,4 32 80,0 255 60,4 29,46*** 5

Integração contínua 23 41,8 23 37.1 86 58,1 86 74,1 30 75,0 248 58,8 56,09*** 5

Planejamento de lançamento 18 32,7 27 43,5 84 56,8 79 68,1 25 62,5 233 55,2 41,48*** 5

Padrões de codificação 22 40,0 32 51,6 68 45,9 77 66,4 30 75,0 229 54,3 24,24*** 5

Kanban 24 43,6 31 50,0 75 50,7 66 56,9 19 47,5 215 50,9 29,20*** 5

Propriedade de código coletivo 23 41,8 21 33,9 76 51,4 68 58,6 24 60,0 212 50,2 15,91** 5

Compilações automatizadas 16 29.1 12 19,4 64 43.2 86 74,1 27 67,5 205 48,6 80,57*** 5

Programação em pares 10 18.2 23 37.1 67 45,3 68 58,6 25 62,5 193 45,7 42,31*** 5

Velocidade 14 25,5 20 32,3 60 40,5 66 56,9 21 52,5 181 42,9 31,59*** 5

Desenvolvimento orientado a testes 13 23,6 14 22,6 52 35.1 68 58,6 25 62,5 172 40,8 42,67*** 5

Cliente no local 13 23,6 19 30,6 46 31,1 65 56,0 19 47,5 162 38,4 34,15*** 5

quadro de tarefas digital 12 21,8 18 29,0 55 37,2 44 37,9 16 40,0 145 34,4 16,32** 5

Implantação contínua 12 21,8 18 29,0 41 27,7 54 46,6 17 42,5 142 33,6 25,89*** 5

Espaços de trabalho abertos 11 20,0 13 21,0 37 25,0 46 39,7 20 50,0 127 30,1 30,64*** 5

ATDD 4 7,3 34,8 26 17,6 41 35,3 15 37,5 89 21,1 48,08*** 5

BDD 4 7.3 7 11,3 21 14.2 22 19,0 10 25,0 64 15,2 14,69* 5

Outro 1 1,8 11,6 32,0 32,6 7 17,5 15 3,6 24,72*** 5

N = 471
Níveis de significância: *** p < 0,001, ** p < 0,01, * p < 0,05

frequentemente adotado quando as empresas têm mais de 5 anos
de experiência ágil. Por outro lado, existem práticas
mais frequentemente adotado quando as empresas estão entre três
e 5 anos usando métodos ágeis, como Iteration Planning, Retrospectives,
Daily Standup, Unit testing, Burndown, Release planning, Kanban,
Automated builds, Velocity, On-site-customer,
e Implantação Contínua. Em alguns casos, a diferença
não foi significativo se compararmos as duas frequências entre
os intervalos. Por exemplo, a integração contínua é adotada
por 74,5 % das empresas entre três e 5 anos de experiência, e adotada
por 75 % das empresas com mais de
5 anos de experiência. No entanto, existem diferenças significativas em
alguns casos. Por que algumas empresas abandonaram
algumas práticas ágeis após 5 anos de experiência? Este resultado
nos intrigou e nos levou a projetar a terceira fase do nosso
pesquisa para melhor interpretar as relações estatísticas (ver
Seita 5.3.2).
A relação entre os fatores de adoção do Agile e a experiência e o
tamanho da empresa. Um teste Qui-Quadrado foi executado
determinar a associação entre velocidade do projeto, preocupações
ao adotar ágil, barreiras para adoção posterior, causas de
projetos ágeis fracassados e tamanho da empresa e experiência com
métodos ágeis. A Tabela 7 apresenta os resultados dos testes.
A relação entre a velocidade ágil do projeto e a experiência da
empresa foi de 118,16 (df = 15, p < 0,001), uma alta
Associação. Essa evidência aponta que as empresas com
mais experiência em métodos ágeis tendem a relatar projetos mais rápidos
velocidades. Também encontramos uma associação entre as preocupações em torno
Conformidade regulatória e tamanho da empresa (ÿ2 =32,86, df =
5, p < 0,001), indicando que empresas maiores apresentam
tendência a se preocupar mais com os regulamentos ao adotar
ágil. Por fim, encontramos uma associação entre a barreira de habilidades
gerenciais e a experiência na empresa (ÿ2 =22,93,
df = 5, p < 0,001). A tendência é que os ágeis mais experientes
as empresas percebem as habilidades de gestão como uma questão importante
para disseminar totalmente as práticas ágeis em toda a organização.
A relação entre as razões para a adoção do Agile, benefícios
percebidos e experiência e tamanho da empresa.

123
Machine Translated by Google

540 J Braz Comput Soc (2013) 19:523–552

Tabela 7 Associação Qui-quadrado

Fatores
uma

entre a adoção ágil e Tamanho da empresa Experiência da empresa ÿ2 df

experiência e tamanho da empresa
ÿ2

Velocidade ágil do projeto 16h35 118.16*** 15

Preocupação - falta de planejamento antecipado 7,73 7.01 5

Preocupação - perda de controle gerencial 2.03 4,95 5

Preocupação - falta de documentação 7,53 9,58 5

Preocupação - falta de previsibilidade 5,66 3,43 5

Preocupação - falta de disciplina de engenharia 8,28 3,50 5

Preocupação - incapacidade de escalar 11,64* 3,64 5

Preocupação - equipe oposta ao acaso 7,61 7,39 5

Preocupação - falta de treinamento da equipe 2,26 7,31 5

Preocupação - conformidade regulatória 32,86*** 16,87** 5

Preocupação - qualidade de software reduzida 2,74 7,49 5

Sem problemas 2,69 15.08** 5

Barreira - mudar a cultura organizacional 4.06 17,35** 5

Barreira - resistência à mudança 3,45 15,56** 5

Barreira - disponibilidade de habilidades necessárias 2,71 12.03* 5

N = 471 Barreira - habilidades de gerenciamento 9.08 22.93*** 5

Níveis de significância: Barreira - complexidade ou tamanho do projeto 11,62* 9h30 5

***
p < 0,001, ** p < 0,01, Barreira—colaboração do cliente 0,80 4,57 5
*
p < 0,05
uma
Barreira—capacidade de escalar 3,59 10,87 5
Graus de liberdade foram os
igual entre cada fator e Barreira - tempo para transição 4,43 9,99 5
o tamanho da empresa e 9,72 7.13 5
Barreira - restrições de orçamento
experiência, portanto, são
Causas de projetos ágeis fracassados 39,68 50,94 5
informado na mesma coluna

Uma correlação de ordem de classificação de Spearman foi executada
para determinar a relação entre as razões para métodos ágeis
adoção, os benefícios percebidos e o tamanho da empresa e
experiência, como mostrado nas Tabelas 8 e 9.
correlação muito fraca entre alguns motivos que levaram a
adoção ágil e o tamanho da empresa ou experiência com
ágil. Por exemplo, há uma relação muito fraca e negativa entre tamanho
da empresa e manutenibilidade (r =
-0,017, p < 0,001). O resultado geral denota que a
razões para a adoção ágil (como aumentar a produtividade ou melhorar o
moral da equipe, etc.)
o tamanho da empresa nem a experiência da empresa com métodos ágeis
métodos.
No entanto, houve uma correlação moderada e positiva
entre alguns benefícios percebidos, como visibilidade, qualidade, custo,
gerenciamento de mudanças, time-to-market, gerenciamento de riscos e
alinhamento entre negócios e TI e experiência da empresa, que foi
estatisticamente significativo (ver Tabela 9). Esse
evidências apontam que tais benefícios percebidos tendiam a
ser maior para empresas ágeis mais experientes. O mais
experiência de uma empresa ágil, maior a probabilidade de
perceber os benefícios mencionados. Nossos resultados também apontam
uma forte correlação entre os benefícios mais percebidos,
conforme mostrado na Tabela 9. Assim, os benefícios percebidos tendem a ser
alcançados em conjunto nas empresas, independentemente do porte da
empresa ou experiência com métodos ágeis.
5.3 Fase 2: resultados do estudo qualitativo
Nesta fase de pesquisa, buscamos confirmar, estender
ou refutar os resultados do estudo quantitativo.
Destacamos que, por se tratar de um estudo qualitativo, os resultados apresentados
nesta seção são baseados nas percepções dos entrevistados
para as relações estatísticas encontradas sobre o ágil
métodos estado da prática na indústria brasileira de TI. Para
caracterizar as empresas neste segundo estudo, coletamos
dados sobre o tamanho da empresa, área de negócios, localização,
experiência com métodos ágeis, bem como características dos
entrevistados, como experiência e funções. As Tabelas 10 e 11 descrevem
perfis das empresas e dos entrevistados.
5.3.1 Adoção de métodos ágeis
A principal razão para a adoção ágil foi cobrir o
noções básicas sobre desenvolvimento de software, como entrega de valor
com frequência e evitando retrabalhos investindo em qualidade técnica.

123
 123
Níveis
de
significância: N
=
471 Gestão
de
risco
[14] Moral
da
equipe
[13] Manutenibilidade
[12] Custo
[11] Disciplina
de
engenharia
[10] Simplifique
o
desenvolvimento
[9] Tempo
de
colocação
no
mercado
[8] Visibilidade
[7] Alinhamento
de
negócios
e
TI
[6] Qualidade
[5] Produtividade
[4] Gerenciando
prioridades
[3] Experiência
da
empresa
[2] Tamanho
da
empresa
[1] Tabela
8
Correlação
de
Spearman
entre
os
motivos
para
adoção
do
Agile,
tamanho
da
empresa
eexperiência
ÿÿÿ
p
<
0,001,
-0,02 -0,04 ÿ0,17*** ÿ0,10* -0,08 -0,04 -0,06 -0,04
ÿÿ 1
0,10* 0,07 0,10* 0,09 0,30***
p
<
0,01,
ÿ
p
<
0,05 -0,04 2
0,14** 0,04 0,02 0,05 0,07 0,13** 0,11* 0,11* 0,07 0,05 0,14**
0,29*** 0,16*** 0,19*** 0,12* 0,15*** 0,09* 0,19*** 0,21*** 0,31*** 0,16***
0,19*** 0,11* 3
0,11* 0,14** 0,19***
0,52***
0,25***
0,17***
0,09* 0,23***
0,20***
0,18***
0,25*** 0,15***
0,29***
0,13** 0,22***
0,23***
0,04 0,16*** 0,16*** 0,07 4
0,23***
0,30***
0,07 0,24***
0,20***
0,30***
0,11* 0,04 0,19*** 0,26*** 5
0,14** 0,32*** 6
0,24***
0,11* 0,08 0,23*** 7
0,21*** 8
0,17***
0,22***
0,29***
0,28***
0,43*** 0,22***
0,30***
0,17***
0,34*** 0,27***
0,36***
0,38*** 0,33*** 9
10
11
12
13
541 J Braz Comput Soc (2013) 19:523–552
Machine Translated by Google
 123
p
<
0,01,
*p
<
0,001,
**
N
=
471
Níveis
de
significância:
*** Manutenibilidade
[15] Alinhamento
de
negócios
e
TI
[14]
0,21***
0,35***
0,65***
0,67***
0,62***
0,65***
0,72***
0,67**
*0,72***
0,54*** Trabalho
em
equipe
distribuído
[13] Gestão
de
risco
[12] Tempo
de
colocação
no
mercado
[11] Gerenciamento
de
mudanças
[10] Moral
da
equipe
[9] Disciplina
de
engenharia
[8] Simplifique
o
desenvolvimento
[7] Custo
[6] Qualidade
[5] Produtividade
[4] Visibilidade
[3] Experiência
da
empresa
[2] Tamanho
da
empresa
[1] Tabela
9
Correlação
de
Spearman
entre
Benefícios
Percebidos
adotando
Agile,
Tamanho
da
Empresa
eExperiência
0,06 0,17***
0,27***
0,46***
0,44***
0,48***
0,56***
0,50***
0,46***
0,47***
0,49***
0,51*** 0,16***
0,33***
0,66***
0,69***
0,63***
0,66***
0,67***
0,69***
0,71***
0,66*** 0,16***
0,31***
0,65***
0,67***
0,60***
0,70***
0,67***
0,64***
0,68***
0,73*** 0,21***
0,35***
0,71***
0,69***
0,67***
0,65***
0,69***
0,66***
0,76*** 0,16***
0,28***
0,68***
0,72***
0,70***
0,61***
0,72*** 0,12* 0,12* 0,12** 0,11* 0,10* 0,21***
0,33*** 0,30*** 1
0,29***
0,64***
0,73***
0,78***
0,67***
0,70***
0,72***
0,68***
0,66***
0,62***
0,68***
0,53***
0,72*
** 0,27***
0,65***
0,68***
0,70***
0,62*** 0,29***
0,64***
0,72***
0,70***
0,68*** 0,31***
0,58***
0,71***
0,67*** 0,32***
0,68***
0,76*** 0,29***
0,67*** 2
p
<
0,05
3
4
5
6
7
8
9
10
11
12
13
J Braz Comput Soc (2013) 19:523–552 542
14
Machine Translated by Google
Machine Translated by Google

J Braz Comput Soc (2013) 19:523–552 543

Tabela 10 Perfil das empresas

Características Empresa A Empresa B Empresa C Empresa D Empresa E Empresa F Empresa G

Tamanho da TI da empresa 30 100 30 207 20 200 130

Ensino de negócios da empresa e Comércio eletrônico Desenvolvimento Programas Software para Software de Comunicação
Programas e infra de portlet para supermercado
estrutura governo Desenvolvimento e área desenvolvimento
desenvolvimento Serviços terceirização

Companhia São Paulo/SP São Paulo/SP Brasília/DF Fortaleza/CE São Paulo/SP Porto Alegre/RS Porto Alegre/RS
localização em
Brasil
Companhia 6 anos 6 anos 5 anos 2 anos 5 anos 4 meses 4 anos
experiência
em ágil
métodos

Tabela 11 Perfil dos entrevistados

Características Entrevistado A Entrevistado B Entrevistado C Entrevistado D Entrevistado E Entrevistado F Entrevistado G

Função Programas Programas Gestão de topo Projeto produtos Desenvolvimento Diretor

desenvolve desenvolve Gerente Proprietário/Principal Gerente
mento mento
Gerente Gerente gerenciamento

Experiência em >10 >10 >20 >10 >10 >20 >20

Programas

desenvolvimento (em
anos)
Experiência em >5 anos >10 anos >5 anos >5 anos 5 anos 4 meses 4 anos
ágil
métodos
Tamanho da equipe ágil Até 10 20 Até 6 5 Até 5 Até 10 Até 12

Então, as empresas começaram a perceber que os métodos ágeis também
podem ajudar no alinhamento estratégico, produtividade,
e sociais, como comunicação, clima e meio ambiente corporativo, nivelamento
técnico e motivação.
A Tabela 12 lista a intenção das empresas ao adotar métodos ágeis
métodos.
Esses achados estão de acordo com os resultados de nossa pesquisa sobre
razões para a adoção ágil, conforme apresentado na Fig. 8 (Seção 5.2.4).
Nossos resultados qualitativos confirmam que as razões para a adoção ágil
não estão relacionadas ao tamanho da empresa ou experiência com
métodos ágeis, mas pela necessidade essencial de melhorar a abordagem de
desenvolvimento de software.
Outro aspecto interessante que a maioria dos entrevistados relatou
foram as iniciativas de baixo para cima bem-sucedidas no início
da adoção de métodos ágeis. A maioria das empresas apresentou iniciativas
de baixo para cima na adoção de métodos ágeis que
foram criados por profissionais que atuam como campeões ágeis. Por
exemplo, um entrevistado afirmou “Em 2006, houve um piloto
caso usando XP em um sistema problemático. Este foi um dos
projetos mais bem-sucedidos da época, tínhamos um trabalho suave
ware com testes passando e a equipe conseguiu uma boa entrega
ritmo".
Depois de perceber os bons resultados das iniciativas preliminares, eles
relataram que a alta administração se engajou principalmente em
Scrum, como um entrevistado disse “A alta administração disse 'esta
piloto deu muito certo (...) então vamos tentar trazer agilidade
métodos para a empresa como um todo'. Então eles [a alta administração]
exigiram métodos ágeis de cima para baixo, com todos adotando o Scrum
oficialmente em 2007”.
Especialmente para grandes empresas, essa abordagem de cima para baixo
para a agilidade afetou a transição real para o ágil, que
deve estar enraizado no estabelecimento dos valores ágeis centrais e
princípios. Isso pode ser percebido na fala: “Nem todos entenderam exatamente
o que era, assim, depois de um tempo, muitos
as pessoas estavam fazendo isso apenas porque lhes foi dito para fazê-lo”.
Hoje, uma grande preocupação das empresas ágeis é empregar
a filosofia ágil para realmente tirar proveito do ágil
práticas. Após esta exploração, descobrimos que ainda é um
desafio para empresas que prosperam ao amadurecer em ágil
e é discutido na seção seguinte correspondente.

123
Machine Translated by Google
544
Tabela 12 Principais motivos para adoção de métodos ágeis
Razão Empresas
Entrega mais rápida de valor para o cliente A, B, C, D, E, F, G “Entregar valor em ciclos mais curtos, evitando antecipar detalhes que
Melhore a qualidade do software A, B, C, D, E
Melhore os aspectos sociais A, B, C, E, F
Melhorar o alinhamento entre TI e negócios ÁS
Aumentar a produtividade B, E, F
5.3.2 Práticas de métodos ágeis
Como visto na Fig. 10 (Secção 5.2.5), os resultados da nossa pesquisa apontam
uma ampla adoção do Scrum e do híbrido Scrum/XP.
Por outro lado, os entrevistados relataram uma fácil adaptação
Desenvolvimento de software XP, Scrum e Lean. Entrevistados
relataram que empregavam práticas como Kanban, Unit Testing, Test-Driven
Development (TDD), Open Work Area,
e toda a equipe (multifuncional e/ou multifuncional
equipes). No entanto, dado seu nível de maturidade em métodos ágeis e
tamanho, observamos diferentes tipos de compromissos com
outras práticas ágeis. Empresas com 5 anos de experiência
ou mais geralmente empregam práticas como refatoração, integração
contínua, implantação contínua e
constrói.
Uma abordagem comum relatada pelas empresas é adaptar
práticas ágeis de diferentes métodos ágeis de acordo com
seu contexto, especialmente após um nível de maturidade em ágil
adoção. As práticas adaptadas pelas empresas entrevistadas são
apresentadas na Tabela 13, que engloba técnicas,
gerenciamento e categorias de compartilhamento de conhecimento coletivo de
práticas. Na categoria técnica de práticas, identificamos
adaptações na adoção de Pair Programming, uso de ferramentas para
métricas e testes de aceitação automatizados. Da mesma forma, as práticas
para melhorar o compartilhamento de conhecimento também foram promovidos no
empresas, como mentoria, palestras/almoços técnicos,
Dojos e rotação de membros da equipe. Essas empresas empregam
essas práticas de compartilhamento de conhecimento por buscarem aprimorar
sua estratégia de negócios de longo prazo e seus profissionais
excelência técnica.
Comparando com os resultados da pesquisa, as práticas de gestão
(Fig. 10), como planejamento de iteração, retrospectivas e
reuniões em pé, foram adotadas em sua maioria por empresas consideradas
maduras em métodos ágeis. Como na pesquisa podemos
123
J Braz Comput Soc (2013) 19:523–552
Algumas declarações
teríamos que mudar de qualquer maneira no futuro, gerando resíduos”.
(Empresa G)
“Hoje, refatoração, integração contínua, implantação contínua,
testes, as métricas passaram a fazer parte do nosso DNA”. (Empresa A)
“Começamos a focar nas pessoas e no papel de cada pessoa dentro da
processo. Não é fácil ser transparente, é difícil mudar o
modelo mental, e é por isso que começamos com isso”. (Empresa F)
“Depois (implementando o XP) adotamos o Scrum (...) que incentivou
o estabelecimento de práticas de gestão e o foco na
estratégia da empresa”. (Empresa A)
“Desde que começamos com métodos ágeis, entregamos vários
produtos e não tivemos que passar a noite. Isso nunca
existia. No passado, cada projeto tinha pelo menos 4-6 pessoas trabalhando
até tarde da noite durante a última semana antes da entrega do projeto. Esse
não existem mais”. (Empresa F)
não sei se eles são adotados “pelo livro” ou adaptados, o
adaptação deve ser um aspecto importante a ser considerado.
Por exemplo, a Empresa A afirmou que não emprega
reuniões diárias em pé, devido à proximidade de
membros do time. As reuniões diárias não agregavam valor
para eles, então eles o empregam semanalmente e o substituíram
usando quadros Kanban e uma ferramenta de gerenciamento de tarefas. Quando
é preciso, eles marcam uma reunião.
Como forma de buscar melhorias na adoção ágil,
identificamos tentativas de aplicar o desenvolvimento de software Lean
práticas. Na empresa B, eles relataram o uso de história de usuário
mapas em vez de backlogs da Sprint para entender melhor o
sistema como um todo e diagrama de fluxo cumulativo para analisar
o fluxo Kanban. Na empresa G, a meta para 2012 foi
alavancar métodos ágeis para o nível organizacional, tendo
Desenvolvimento enxuto de software como principal orientação.
Por outro lado, a prática do cliente no local foi
levantada pelos entrevistados como logo adotada, e ocorre
principalmente para clientes internos. Presença de clientes externos
e o envolvimento não é totalmente fornecido, os proprietários do produto (PO)
acabam fazendo a ponte entre as necessidades do cliente e a equipe e vice
vice-versa.
Outra prática negligenciada por empresas experientes é
o uso de técnicas de estimativa, como o pôquer de planejamento.
Na verdade, muitas vezes eles simplesmente estabelecem uma estimativa de
tarefa de alto nível (por exemplo, pequena, média, grande), na qual grandes, ou mesmo
meio, implica que eles devem considerar quebrar a história
em menores.
O desenvolvimento orientado por comportamento (BDD) é outra prática
não totalmente implementado pelas equipes. Primeiro, porque o Produto
Os proprietários acham difícil escrever os scripts. Em segundo lugar, não foram
percebendo o valor de volta ao projeto, pois, dependendo
na história, o roteiro permaneceu quebrado por muito tempo,
um entrevistado explicou: “É um roteiro que você escreve no
Machine Translated by Google

J Braz Comput Soc (2013) 19:523–552 545

Tabela 13 Práticas ágeis adaptadas

Categoria Prática Empresas Adaptação

Técnico Programação em pares A, B, C, D, E, G Empregar quando necessário. Geralmente

em tarefas mais complexas ou em
tarefas de transferência de conhecimento. Nós

observou resistência pessoal a

Programação em pares. Desenvolvedores
reclamar de incompatibilidade
com alguns colegas, cansaço
e falta de privacidade para acessar
e-mail, sites de redes sociais,
e outros

Uso de ferramentas para coleta de métricas A, B, C, D, E, F Gráficos e equipe de burndown/burnup

velocidade são muitas vezes fornecidos por
ferramentas, mas eles brevemente se referem a
eles. Suas métricas são mais

relacionados à cobertura de teste e código

qualidade

Testes de aceitação automatizados A, C, D, E Agrupe-os por várias histórias

Gerenciamento Encontro diário A, C, D, E Devido à proximidade, os membros da equipe

saber o que está acontecendo no
projeto

Desenvolvimento de iteração B, D, F Algumas empresas não cancelam o

sprint se eles precisam mudar o
alcance. Devido à natureza do
negócio, adaptam-se e são mais
flexível neste caso

Planejamento de iteração/lançamento A, B, C, D, E, F Devido ao uso de tarefas contínuas

fluxo em projetos em andamento, a maioria

eles não planejam iteração.
No entanto, eles priorizam a iteração
planejamento em casos de novos projetos
ou projetos específicos
prazos ou área de negócios (como
governo)

Retrospectivas A, B, D, E, F A maioria não agenda

retrospectivas periodicamente
as pessoas levantam positivo e negativo
aspectos anteriores no informativo
espaço de trabalho ou outro
canais de comunicação.
Às vezes, os problemas são
resolvidos em reuniões stand-up ou
eles agendam uma retrospectiva para
discuti-los

Lista de verificação A, B, E Prática empregada em

tarefas, como escrever histórias,
evitar erros conhecidos

Reuniões um a um SER Pratique para dar ao indivíduo

comentários

Uso de timeboxes para envolver novos aprendizados A, B, E Especifique o tempo para as atividades de aprendizagem

Compartilhamento de conhecimento coletivo Mentoria A, B, D, E Ao juntar um especialista com um novato

Palestras/almoço técnico A, B, E Reserve um tempo para se preparar
apresentação sobre temas específicos

Dojos A, B, D, E, G Pratique para estimular o interesse em

aprendendo continuamente
Rotação de membros da equipe A, B, D, E Mova as pessoas para espalhar
conhecimento

123
Machine Translated by Google
546
começo, mas continua quebrado por muito tempo. Até você fazer o
model, o controller e a view, o script fica quebrado lá por dias, semanas”.
5.3.3 Benefícios percebidos da adoção de métodos ágeis
Embora a visibilidade dos benefícios seja diferente de equipe para equipe
dentro das empresas, a percepção geral é que os métodos ágeis
trouxeram diversas vantagens ao desenvolvimento de software nessas
empresas. Em primeiro lugar, os clientes ficaram mais satisfeitos com as
entregas frequentes de valor, como afirmou o entrevistado B: “Estamos
entregando o que o cliente precisa e reduzindo o ciclo de feedback”.
Esse benefício está em linha com o senso de time-to-market e
produtividade apontados nos resultados da pesquisa. Outro benefício é
a colaboração do cliente ao longo do processo de software como uma
responsabilidade compartilhada.
Sobre este aspecto, a empresa C destacou a má experiência de
colaboração do cliente no governo: “No final, a colaboração foi inútil e
todo escopo aparentemente flexível com o qual estávamos lidando. O
que valia para o governo era apenas o que estava determinado no
contrato”.
À medida que as empresas se tornam mais experientes em métodos
ágeis, os benefícios da qualidade do software, visibilidade do projeto e
moral da equipe foram confirmados pelos entrevistados como sendo
cada vez mais percebidos desde sua implementação. A busca pela
melhoria contínua aumentou a excelência técnica dos membros da
equipe. Como consequência, a qualidade do software melhorou na
percepção deles, como destacou o entrevistado A, “A questão da
qualidade: agora temos um ciclo definido e o sentimento de mais
propriedade coletiva e mais qualidade de código interno”. Além disso,
satisfação no trabalho e visibilidade são outros aspectos levantados
pelos entrevistados ao amadurecer em métodos ágeis. Por exemplo, o
entrevistado B afirmou: “As pessoas são mais felizes, as pessoas
entendem o que estão fazendo, o clima corporativo é mais legal”. Na
Empresa G, a percepção de benefício é semelhante. O projeto é de
propriedade da equipe. Algumas pessoas ficaram mais motivadas com
métodos ágeis. As pessoas são mais criativas e entregam o que faz a
diferença para o cliente. Esses
as evidências qualitativas refletem na forte correlação encontrada entre
os benefícios mais percebidos e a experiência da empresa levantada na
análise estatística (Tabela 9).
Na Empresa F, todos pensam que estão no caminho certo agora
usando métodos ágeis. A empresa tem 7.000 funcionários, e a alta
gestão diz que o próximo passo é influenciar toda a empresa com a
cultura e os benefícios dos métodos ágeis.
O entrevistado C relatou uma preocupação importante relacionada
ao crescimento da empresa: eles aprenderam diferentes benefícios
durante o tempo de implantação, “Os benefícios eram mais bem
percebidos quando éramos menores”. Após seu crescimento, escalar
ágil para a empresa se tornou um desafio, ''Agora estamos em um
momento de reflexão''.
123
J Braz Comput Soc (2013) 19:523–552
5.3.4 Desafios da adoção de métodos ágeis
Nossos resultados qualitativos confirmam os resultados da pesquisa
sobre os desafios para uma adoção ágil adicional apresentada na Fig.
13 (Seção 5.2.7). Os entrevistados revelaram limitações para uma
adoção ágil completa em seus contextos. Devido à abordagem centrada
no ser humano dos métodos ágeis, os aspectos sociais são considerados
o fator mais complicado para uma adoção mais ampla, especialmente
em ambientes dinâmicos e em crescimento. Essas descobertas estão
alinhadas com o que encontramos na análise estatística (Seção 5.2.8),
empresas experientes estão percebendo que as habilidades sociais e de
gestão realmente importam para disseminar totalmente o ágil em toda a
organização. Além disso, os entrevistados relataram a dificuldade em
empregar a mudança cultural de longo prazo e estão se questionando se
vale a pena investir. Alguns relatam que isso se deve à baixa maturidade
dos funcionários e ao processo de recrutamento precário. Outros afirmam
que isso se deve ao crescimento da empresa e à dificuldade de escalar
a agilidade.
Por exemplo, a empresa C está enfrentando problemas com o
comprometimento, responsabilidade e liberdade dos funcionários. Agora
eles estão refletindo sobre sua forma de lidar com as pessoas: “Não
verificamos de forma consistente os resultados positivos da liberdade de
longo prazo e de uma estrutura de rede. Percebemos que as pessoas
não estão dispostas a assumir uma cobrança proporcional às suas
atividades (...) Estou revendo muita coisa nesse sentido e estou
direcionando a energia de convencer as pessoas a estabelecer
mecanismos de controle dentro da empresa. É uma espécie de caminho
inverso, porque fomos para um extremo e agora está na direção oposta”.
Eles também relatam melhorias na comunicação após o emprego de
métodos ágeis, porém entendem que há um longo caminho para uma
comunicação eficiente; como o entrevistado B declarou: “Eu diria que a
comunicação é sempre a questão complicada. Investimos na criação de
um ambiente seguro onde as pessoas pudessem conversar. Mas sempre
tem gente que não acompanha, então acho que o mais difícil são as
pessoas e a comunicação entre elas”.
Na análise estatística da Sec. 5.2.8, foi apresentada a seguinte
questão: “Por que as empresas abandonaram algumas práticas ágeis
após cinco anos de experiência?”. Na exploração qualitativa, um achado
interessante foi destacado por algumas das empresas experientes. Eles
afirmam barreiras técnicas, como problemas tecnológicos dentro de
projetos, afetando uma adoção mais ampla de práticas ágeis, como
implantação contínua, construções automatizadas e integração contínua.
Assim, empresas experientes às vezes abandonam as práticas devido
às variáveis de contexto do projeto, não porque as práticas sejam inúteis.
Por outro lado, empresas com três anos ou menos de experiência têm
dificuldade em obter disciplina na adoção de práticas como refatoração.
Um entrevistado afirmou: “Integração Contínua, construção de 10
minutos, construções automatizadas não são praticadas hoje. Nós sabemos que
Machine Translated by Google
J Braz Comput Soc (2013) 19:523–552
deve fazê-lo. A refatoração é feita ocasionalmente. Deveria ser mais
frequente”.
No futuro, empresas focadas em inovação de produtos ou serviços
como A, B e C esperam investir mais em iniciativas Lean Startup [50] .
Lean Startup significa um conjunto de práticas para ajudar os
empreendedores a aumentar suas chances de construir uma startup de
sucesso, que é uma instituição humana projetada para criar um novo
produto ou serviço em condições de extrema incerteza. As referidas
empresas assumem que para estabelecer um raciocínio ágil para
inovação empresarial, como descreve o entrevistado B “Uma coisa que
estou achando muito legal é que com o surgimento dessa onda de
Lean Startup, as pessoas não estão apenas preocupadas em fazer um
produto que funciona, mas para fazer um produto que as pessoas
queiram usar. Não adianta ter um software perfeito que ninguém quer
usar. Acho que agrega outra dimensão às metodologias ágeis, o que
significa conhecer o cliente e não ter medo de mudar o rumo do
negócio. Isso é algo que deve amadurecer na próxima década”.
No entanto, após empregar vários testes e validações de hipóteses
para o processo de desenvolvimento do cliente, o entrevistado A criticou
o pensamento da Lean Startup de focar na criação de uma solução
global para os usuários: “A Lean Startup tenta pensar mais globalmente.
Nossa percepção é que o site não é bom para todos, é bom para uma
pessoa. Portanto, não queremos descobrir a melhor página para todos
os meus clientes, mas a melhor página para um cliente. O sistema deve
se adaptar dinamicamente para mostrar o que potencializa o uso do
produto para o meu cliente (...) fazendo métricas em tempo de execução
e fornecendo soluções customizadas”.
A empresa C, que desenvolve produtos principalmente para
governo, elogia o Lean Startup como a nova onda de desenvolvimento
de produtos inovadores com conceitos ágeis e enxutos, mas o
entrevistado C afirma que “Governo e startups não combinam”, por isso
estão fazendo seus testes em paralelo dentro de uma nova área de
negócios.
Outro desafio futuro fundamental que as empresas esperam é
envolver os principais valores e princípios ágeis em diferentes contextos
e implementar a agilidade empresarial para tirar vantagem real dos
métodos ágeis. Isso é ilustrado por uma citação da Empresa G, ao
dizer que “O uso de métodos ágeis é diferente entre todas as equipes.
Por isso, 2012 é o ano da cultura ágil. Trabalharemos com base nos
princípios lean e tentaremos implementar a agilidade empresarial em
toda a organização”. A entrega contínua também foi mencionada
durante as entrevistas como um desafio fundamental para o futuro.
Essa exploração qualitativa foi realizada para melhorar a validação,
interpretação e esclarecimento dos achados mais relevantes da
pesquisa. Isso foi alcançado pela profundidade e riqueza dos dados
fornecidos pelas empresas entrevistadas reforçadas com suas
declarações e histórias de guerra.
547
6 Discussão
Os resultados apresentados neste artigo mostram características
importantes de como os métodos ágeis estão sendo aplicados por
empresas, profissionais de TI e universidades no Brasil. Nesta seção,
discutimos nossas principais descobertas com base nas três
perspectivas apresentadas no artigo: educação, pesquisa e indústria.
Educação. Há um número crescente de iniciativas de educação ágil
no Brasil. Várias universidades e empresas estão oferecendo
treinamentos e aulas inovadoras para estudantes e profissionais de TI.
A necessidade de educação em desenvolvimento ágil de software é
corroborada pelos resultados empíricos (tanto da pesquisa quanto das
entrevistas), e a falta de treinamento é percebida pelas empresas como
uma das principais barreiras para a adoção ágil. As iniciativas de
formação também são muito importantes para os alunos. Em uma
recente revisão sistemática sobre desenvolvimento ágil de software,
Dybÿa e Dingsøyr [25] apresentaram experiências sobre as percepções
dos alunos sobre a educação ágil. Em um dos estudos relatados, os
alunos constataram que trabalhar em equipes ágeis os ajudou a
desenvolver habilidades profissionais como comunicação,
comprometimento, cooperação e adaptabilidade.
Os alunos também acreditavam que o XP melhora a produtividade de
pequenas equipes [39]. Além disso, conforme relatado por Goldman et
al. [28], os professores parecem ter a mesma percepção: “cada um de
nós tem experiência de desenvolvimento suficiente para acreditar
fortemente que produzimos código de produção de maior qualidade
neste ambiente do que o antigo estilo cubículo de desenvolvimento de
software”. A maioria das iniciativas de educação ágil são baseadas em
esforços individuais de vários grupos de pesquisa em todo o país e
empresas interessadas em aplicar métodos ágeis. Por isso, acreditamos
que há uma oportunidade para discutir como incluir métodos ágeis nos
currículos de Ciência da Computação no Brasil. Com base em nossos
resultados, isso significa oferecer cursos mais próximos do contexto do
mercado, para que os alunos possam vivenciar todas as questões
fundamentais do desenvolvimento ágil de software.
Pesquisar. Em relação à pesquisa científica, os resultados mostraram
que a pesquisa de métodos ágeis está crescendo no Brasil.
Mais artigos estão sendo publicados, tanto em conferências nacionais
quanto internacionais, também existem várias universidades e grupos
de pesquisa realizando pesquisas em diferentes tópicos.
Os tópicos investigados pelos grupos de pesquisa brasileiros estão
parcialmente alinhados ao que Dybÿa e Dingsøyr [25] encontraram em
sua revisão sistemática. Eles classificaram os estudos em quatro
grupos temáticos: introdução e adoção, fatores humanos e sociais,
percepções de métodos ágeis e estudos comparativos. A comunidade
brasileira de pesquisa concentrou a pesquisa em três grupos: introdução
e adoção, uso de ferramentas e práticas e percepções de métodos
ágeis.
Equipes de desenvolvimento de software ágil são sistemas
sociotécnicos adaptativos complexos [78], contando com membros de
equipe multifacetados equipados com uma gama mais ampla de
habilidades técnicas, sociais e de liderança [46]. Nossos achados confirmam anteriores
123
Machine Translated by Google
548
resultados que o lado técnico dos métodos ágeis ajuda o
equipes se tornando mais produtivas, aumentando a qualidade
o produto final. No entanto, descobrimos que lidar com questões sociais
fatores para construir equipes ágeis ainda é um desafio. Por exemplo: como
as pessoas podem ser efetivamente preparadas para trabalhar em métodos ágeis
equipes? Os métodos ágeis enfatizam a importância da maior autonomia,
trabalho em equipe e tomada de decisão dos desenvolvedores [46].
No entanto, formar tais equipes leva tempo e recursos [43],
e requer significativamente mais habilidades sociais [3,70] e experiência
[6]. Assim, nossos achados indicam que existe um caminho
para mais pesquisas sobre as habilidades e treinamento necessários para
equipes ágeis.
Outra questão muito importante é como nos adaptamos
métodos ágeis para diferentes contextos? Pesquisas recentes têm
lançar luz sobre modelos e métodos para a adaptação de métodos ágeis.
Kruchten [33] explora o tema apresentando uma
modelo contextual para desenvolvimento de sistemas intensivos de
software para orientar a adoção e adaptação de software ágil
práticas de desenvolvimento. Esses modelos podem ser investigados
e avaliados para diferentes contextos. Conboy e Fitzger ald [16]
entrevistaram 16 profissionais especialistas em XP para investigar a
eficácia dos métodos de adaptação de XP e fornecer um conjunto de
recomendações para profissionais de software
e pesquisadores sobre a adaptação do XP. Nossos achados indicam
que as empresas brasileiras também estão adaptando métodos ágeis
como XP, Scrum e Lean dentro de seus contextos à medida que
ficar mais maduro. Eles também estão usando novas práticas ágeis para
diferentes domínios, como Lean Startup. Por isso, pesquisas envolvendo
empresas de diferentes portes, áreas de negócios e experiência ágil
devem ser realizadas para
ajudar a compreender e evidenciar quais métodos ou práticas são mais
adequados para cada contexto diferente.
Há também uma oportunidade de estender a revisão sistemática da
literatura conduzida por Dybå e Dingsøyr [25] para
incluir evidências atualizadas da pesquisa que está sendo
desenvolvidos sobre métodos ágeis em todo o mundo. Como um exemplo,
a maioria dos estudos empíricos encontrados por Dybå e Dingsøyr
[25] estão relacionados ao XP (76%), enquanto nossa pesquisa indica
que a maioria das empresas da nossa amostra está usando Scrum
como o principal método ágil (51,2 % usam Scrum e 22,5 %
use o híbrido Scrum/XP). Esse resultado também é corroborado por
os resultados relatados no estado anual da pesquisa ágil [73].
Os dados da pesquisa incluem informações de 4.770 participantes de 91
países. Scrum também é o mais seguido
método ágil (58%), seguido de Scrum/XP Hybrid (17%).
Por esta razão, há uma diferença no que os acadêmicos são
pesquisando e o que muitas empresas estão fazendo em termos
de métodos ágeis e isso pode ser investigado no futuro.
O Lean Software Development também foi mencionado em nossas
entrevistas como um método ágil utilizado pelas empresas, e a
investigação de como esse método é aplicado é uma oportunidade para
pesquisa futura.
123
J Braz Comput Soc (2013) 19:523–552
Indústria. Métodos ágeis estão sendo amplamente adotados por
empresas em todo o mundo [73]. Os principais motivos dessa adoção
são: acelerar o time to market, aumentar a capacidade de
gerenciar mudanças de prioridades e aumentar a produtividade. Dentro
No Brasil, nossos resultados são muito semelhantes (Fig. 8). Quando
triangulamos os resultados da pesquisa e as entrevistas realizadas,
a mudança na cultura organizacional aparece como um elemento
importante para facilitar a adoção ágil dentro das empresas. Dentro
uma revisão das definições sobre cultura organizacional apresentada
por Cameron e Ettington [11], na maioria dos casos, tem
tem sido tratado como um conjunto duradouro de valores, crenças e
pressupostos que caracterizam as organizações e seus membros. Como
Cameron e Quinn [12] afirmam, mudar a cultura organizacional é um
desafio, pois requer a identificação e
estratégia de longo prazo para mudar os atributos subjacentes, incluindo
o estilo de gestão, planos estratégicos, clima, recompensa
sistema, meios de vínculo, liderança e valores básicos de
a organização.
Na maioria das entrevistas realizadas, o alinhamento
entre as empresas G valores, missão, com os princípios do manifesto ágil
foi o aspecto chave para facilitar a
mudança cultural organizacional. Mas a pergunta é: quantos
empresas estão prontas para esta mudança [75]? Mudar a cultura
organizacional é uma estratégia de longo prazo e certas empresas não
estão dispostas ou mesmo preparadas para lidar com essa profunda
mudança. Por esse motivo, algumas empresas podem não ver isso
estratégia tão lucrativa e desistir de envolver valores e princípios ágeis
essenciais para toda a empresa, como antes
acreditaram no início da implementação ágil. Algum
empresas investiram muito no processo de recrutamento e
treinamento interno para alcançar uma boa equipe. Portanto, a
compreensão dos fatores humanos e da mudança organizacional são
principais desafios para fortalecer e sustentar métodos ágeis em
indústria.
O estudo exploratório levantou o ponto de que as empresas geralmente
iniciam a adoção ágil dentro de um único projeto, e então
estendê-lo ao nível organizacional. Nos resultados da pesquisa,
os campeões iniciais de métodos ágeis são desenvolvedores e
Líderes de torcida. No entanto, a maioria das empresas em todo o mundo
têm líderes seniores (VP/Diretor de desenvolvimento e gerente de
desenvolvimento) como os campeões dos métodos ágeis [73].
Enquanto no Brasil temos uma estratégia de baixo para cima, parece que
existe uma estratégia de cima para baixo em todo o mundo. Esta é uma
oportunidade a ser investigada no futuro.
Quando comparamos os resultados entre brasileiros e
pesquisas mundiais [73,74], encontramos resultados muito semelhantes
sobre os benefícios da implementação de métodos ágeis,
os métodos ágeis mais seguidos, e quatro dos principais
cinco práticas mais adotadas. Mas diferentes práticas são usadas
com base no tamanho da empresa e maturidade em métodos ágeis.
Empresas com mais de 5 anos de experiência usam práticas
como refatoração, o que não é o caso de empresas com
menos de 3 anos de experiência. Uma adoção linear de técnicas
Machine Translated by Google
J Braz Comput Soc (2013) 19:523–552
práticas ágeis focadas em melhorar a qualidade de software, como TDD,
refatoração, integração contínua e outras, têm sido aplicadas com rigor em
empresas mais experientes em métodos ágeis. No entanto, as práticas de
gestão são o subconjunto das práticas ágeis que estão passando por grandes
ajustes e até mesmo sendo abandonadas, como as técnicas de estimativa.
Isso pode indicar um campo importante para iniciar a pesquisa, como forma
de construir um corpo de conhecimento sobre a adaptação de práticas ágeis.
6.1 Limitações
Em relação à revisão de literatura desenvolvida sobre pesquisas sobre
desenvolvimento ágil de software no Brasil, não seguimos todos os passos
recomendados para realizar revisões sistemáticas de literatura, devido à
estratégia adotada para identificar a literatura relevante. Para trabalhos
futuros, planejamos realizar uma revisão sistemática sobre métodos ágeis,
estendendo a revisão relatada por Dybÿa e Dingsøyr [25], e comparando-a
com o que encontramos sobre as pesquisas sobre métodos ágeis no Brasil.
Neste estudo, nosso principal objetivo foi apresentar um panorama geral
do movimento ágil no Brasil, analisado de diferentes ângulos.
Os resultados encontrados são válidos no contexto de nossa amostra e não
podem ser generalizados neste momento. Acreditamos que nossos resultados
possam ser usados no futuro para comparação com outros países.
Também temos limitações relacionadas ao viés dos pesquisadores.
Nossa principal ação para reduzir a limitação do
O resultado foi triangular todos os dados, analisando dados quantitativos e
qualitativos em uma abordagem de método misto. Também implementamos
a revisão por pares entre todos os pesquisadores envolvidos neste estudo.
Por fim, embora os resultados de nossa pesquisa sejam de dezembro/
2011, ainda lançam luz sobre questões pouco pesquisadas sobre o estado
da prática ágil no Brasil. Como responder a esse tipo de pesquisa exige um
tempo significativo dos entrevistados, planejamos realizar a pesquisa a cada
2 anos e relatar os resultados à comunidade ágil, como fizemos nesta
iniciativa pioneira [41].
7. Conclusão
Nos primeiros anos dos métodos ágeis no Brasil, no início dos anos 2000, as
palestras sobre o assunto foram recebidas com grande ceticismo tanto por
pesquisadores da academia quanto por gestores da indústria. Melhor
aceitação foi encontrada com desenvolvedores experientes, que muitas vezes
ficaram entusiasmados com a nova visão e perspectiva da produção de
software. Muitas vezes, alguns membros da platéia em uma palestra sobre
XP se tornavam agressivos contra as ideias apresentadas pelo palestrante.
Hoje em dia, esse cenário mudou completamente. A maioria das empresas
envolvidas no desenvolvimento de software afirma seguir pelo menos algumas
das recomendações do Manifesto Ágil.
549
Jovens desenvolvedores agora são educados com algum contato com práticas
ágeis, como testes automatizados e integração contínua. Alguns até dizem
que os métodos ágeis se tornaram o fluxo principal [32].
No entanto, a cultura e tradição de desenvolvimento baseado em planos
e avaliação de progresso baseada em documentação ainda é muito forte nas
universidades e empresas brasileiras.
Assim, ainda há um longo caminho a percorrer para que os métodos ágeis se
tornem, de fato, predominantes no Brasil. Educadores podem ajudar nessa
direção modernizando currículos universitários e pesquisadores podem ajudar
realizando experimentos e avaliações da qualidade e produtividade de
softwares desenvolvidos com métodos ágeis. No entanto, como Thomas Kuhn
afirma em The Structure of Scientific Revolutions [34], pode ser necessário
que toda uma geração de gerentes e líderes se aposente antes que o novo
paradigma de desenvolvimento ágil se torne, de fato, amplamente utilizado e
mainstream.
Agradecimentos Gostaríamos de agradecer a todos os participantes
que contribuíram para a pesquisa. Esta pesquisa é apoiada pela
FAPESP, Brasil, proc. 2009/10338-3, proc. 2009/16354-0, CNPq, Brasil, proc.
76661/2010-2, CNPq (483125/2010-5, 560037/2010-4, 550130/2011-0
e 309000/2012-2), e o programa PDTI, financiado pela Dell
Computadores do Brasil Ltda. (Lei 8.248/91).
Apêndice A
Protocolo de pesquisa
• Qual função abaixo melhor descreve sua posição atual em sua empresa?
• Há quanto tempo você pratica métodos de desenvolvimento ágil? •
Qual situação abaixo melhor descreve seu nível atual de
exposição ao desenvolvimento ágil?
• Qual é o tamanho total de sua organização de software? •
Qual é a principal atividade da sua organização? • Onde sua
empresa está localizada? • Quais foram os motivos para adotar
o ágil em sua equipe ou organização? • Há quanto tempo sua empresa
pratica métodos de desenvolvimento ágil? • Qual método ágil você segue
mais de perto? • Qual porcentagem (%) dos projetos de software da sua
empresa
usar um método ágil? •
Qual é/foi o campeão da adoção ágil em seu com
companhia?
• Você trabalha em uma empresa com desenvolvimento distribuído
equipes?
• Qual é o método ágil mais seguido em seu com
companhia?
• Que valor você realmente percebeu com a implementação
práticas ágeis?
123
Machine Translated by Google
550
• Qual é a sua percepção sobre a adoção do ágil em
sua empresa/equipe?
• Quais são as barreiras para uma maior adoção do ágil em sua
organização atual? • Quais são as práticas ágeis adotadas em sua
empresa? • Quais foram as principais razões para projetos ágeis
fracassados (se
algum)?
Barreiras, desafios e futuro da adoção de métodos ágeis
Apêndice B
Guia de entrevista—Perfil pessoal e empresarial das empresas
brasileiras
• Qual é a sua função atual na equipe ágil? • Há quanto
tempo você tem experiência com métodos ágeis? • Qual é o
tamanho de TI da sua empresa? • Qual é a área de negócios da
sua empresa? • Conte-nos brevemente sobre o contexto da sua
empresa (estrutura,
estratégia, cultura, etc). •
Qual é o tamanho de sua equipe ágil? • Por
Referências
quanto tempo a equipe ágil foi composta? • Conte-nos
sobre sua experiência em desenvolvimento de software. • Quais foram
seus projetos recentes em engenharia de software? • Conte-nos sobre seu
primeiro contato com métodos ágeis.
Razões para a adoção de métodos ágeis
• Quais foram os motivos pelos quais sua empresa decidiu adotar métodos
ágeis? • Na sua opinião, qual o nível de suporte da empresa na adoção
de métodos ágeis?
• Como a alta direção e os membros da equipe começaram a adotar ou
concordar com a adoção de métodos ágeis?
Práticas ágeis adotadas
• Quais métodos ágeis sua equipe implementa? • Quais práticas
ágeis sua equipe adota? • Existe alguma prática ágil que você
precisou adaptar? Se sim, qual e como você se adaptou? • Existe alguma
prática ágil que você adotou e desistiu de adotar até agora? Se sim,
quais são os motivos? • Existe alguma prática ágil que cause opiniões
divergentes sobre a adoção na empresa? • É alguma prática ágil que a
equipe pretende adotar em
o futuro?
Benefícios obtidos com a implementação de métodos ágeis
10. Cagnin MI, Maldonado JC, Germano FSR, Penteado RD (2003)
• Você pode nos contar sobre um problema que não existe mais
depois de adotar métodos ágeis?
123
J Braz Comput Soc (2013) 19:523–552
• Qual a sua percepção sobre os principais benefícios trazidos pela
o(s) método(s) ágil(is) adotado(s)?
• Ao longo do tempo de adoção, como você percebeu esses
benefícios?
• Na sua opinião, a visibilidade dos benefícios é a mesma no nível das
equipes e no nível organizacional?
• Você pode nos contar um episódio em que uma prática ágil
mais do que ajudou no projeto?
• Na sua opinião, o que foi mais desafiador no projeto ágil do qual você
está participando? • Você percebe limitações para uma adoção mais
profunda de métodos ágeis em sua equipe e/ou em sua empresa? Que? •
Quais perspectivas para a adoção e evolução dos métodos ágeis você
pode apontar para as empresas nos próximos 10 anos?
1. Abbas N, Gravell AM, Wills GB (2008) Raízes históricas dos métodos ágeis:
de onde veio o pensamento ágil? In: Processos ágeis em engenharia de
software e programação extrema. Notas de aula em processamento de
informações de negócios, vol 9. Springer, Berlim, pp 94–103
2. Aniche M, Gerosa M (2010) Erros mais comuns na prática de desenvolvimento
orientado a testes: resultados de uma pesquisa online com desenvolvedores.
In: 2010 terceira conferência internacional sobre oficinas de teste,
verificação e validação de software (ICSTW), IEEE, pp 469–478
3. Balijepally V, Mahapatra R, Nerur SP (2006) Avaliando perfis de
personalidade de desenvolvedores de software em equipes de desenvolvimento ágil.
Commun Assoc Inf Syst 18:55–75
4. Beck K (1999) Extreme Programming Explained:brace change, 1999.
Addison-Wesley, Reading 5. Bernardo P, Kon F (2007) Desenvolvendo
com agilidade: experiências na reimplementação de um sistema de grande
porte. In: Anais do 1º workshop sobre desenvolvimento rápido de
aplicativos (WDRA2007) no simpósio brasileiro de software, qualidade
(SBQS2007), pp 1–4
6. Boehm B, Turner R (2005) Desafios gerenciais para implementação de
processos ágeis em organizações tradicionais de desenvolvimento. IEEE
Softw 22(5):30–39 7. Bravo M, Goldman A (2010) Reforçando o
aprendizado de práticas ágeis usando dojos de codificação. In: Aalst W,
Mylopoulos J, Sadeh NM, Shaw MJ, Szyperski C, Sillitti A, Martin A, Wang
X, Whitworth E (eds) Processos ágeis em engenharia de software e
programação extrema. Notas de aula sobre processamento de informações
de negócios vol 48. Springer, Berlin, pp 379–380.
8. Brooks FP (1975) O mítico homem-mês: ensaios sobre software
Engenharia. Addison-Wesley, Reading 9.
Bunse C, Feldmann RL, Dörr J (2004) Métodos ágeis no ensino de engenharia
de software. In: Programação extrema e processos ágeis em engenharia
de software. Notas de aula em ciência da computação, vol 3092. Springer,
Berlim, pp 284–293
Parfait: rumo a um processo de reengenharia ágil baseado em framework.
In: Conferência de desenvolvimento ágil, pp 22–31
Machine Translated by Google
J Braz Comput Soc (2013) 19:523–552
11. Cameron KS, Ettington DR (1988) Os fundamentos conceituais da cultura
organizacional. Ensino superior, vol 4. Kluwer, Dordrecht 12. Cameron KS, Quinn
RE (2011) Diagnosticando e mudando a cultura organizacional: com base na estrutura
de valores concorrentes. Jossey Bass, São Francisco
13. Cockburn A (2006) Desenvolvimento ágil de software: a cooperativa
jogos. Addison-Wesley Profissional, Leitura
14. Cohen J (1988) Análise do poder estatístico para as ciências comportamentais, 2ª
ed. Routledge Academic, Londres
15. Conboy K (2009) Agilidade desde os primeiros princípios: reconstruindo o conceito
de agilidade no desenvolvimento de sistemas de informação. Inf Syst Res 20:329–
354 16. Conboy K, Fitzgerald B (2010) Método e características do desenvolvedor
para adaptação eficaz de métodos ágeis: um estudo da opinião de especialistas em xp.
In: ACM Trans Softw Eng Methodol (TOSEM) 20:2:1–2:30 17. Corbucci H, Bravo M
(2007) Archimedes—o cad aberto: Uma aplicação para desenho técnico baseado
na plataforma do eclipse 18. Corbucci H, Goldman A, Katayama E, Kon F, Melo C,
Santos V (2011) Gênese e evolução do movimento ágil no Brasil – perspectiva da
academia e da indústria, 25º Simpósio Brasileiro de Engenharia de Software (SBES), pp
98–107
19. Creswell J (2009) Desenho de pesquisa: abordagens qualitativas, quantitativas e de
métodos mistos. Sage Publications, Londres 20. Derby E, Larsen D (2006)
Retrospectivas ágeis—tornando grandes equipes. Pragmatic Bookshelf, Carolina do
Norte 21. Dingsøyr T, Dybå T, Brede Moe N (2010) Desenvolvimento de software
ágil: uma introdução e visão geral. In: Desenvolvimento ágil de software: pesquisa atual
e direções futuras, 1ª ed. Springer, Berlim, pp 1–13
22. Dingsøyr T, Moe NB, Balijepally V, Nerur SP (eds) (2011)
Conferência Ágil 2011, Ágil. http://agile2011.agilealliance.org/.
Acessado em janeiro de 2012
23. Ducasse S (2005) Squeak: aprenda programação com robôs. Apress,
Nova Iorque
24. Dybå T, Dingsøyr T (2008a) Estudos empíricos de desenvolvimento ágil de software:
uma revisão sistemática. Inf Softw Technol 50:833–859 25. Dybå T, Dingsøyr T
(2008b) Estudos empíricos de desenvolvimento ágil de software: uma revisão sistemática.
Inf Softw Technol 50:833–859 26. Frost N, Nolas SM, Esin BBGC, Holt A,
Mehdizadeh L, Shinebourne P (2010) Pluralismo na pesquisa qualitativa: o impacto de
diferentes pesquisadores e abordagens qualitativas na análise de dados qualitativos.
Qual Res 10:441–460 27. Goldman A, Katayama E (2011) Retrato da comunidade
acadêmica de métodos ágeis no Brasil. In: Workshop Brasileiro de Métodos Ágeis
(WBMA 2011), pp 1–10 28. Goldman A, Kon F, Silva PJS, Yoder JW (2004) Ser extremo
em sala de aula: experiências de ensino xp. J Computação Brasileira Soc 10:5–21
29. Guba EG, Lincoln YS (1994) Competindo paradigmas em pesquisa qualitativa. In:
Pesquisa qualitativa. Sage, Londres, pp 105–117 30. Hazzan O, Dubinsky Y (2003)
Ensinando uma metodologia de desenvolvimento de software: o caso da programação
extrema. In: 16ª educação e treinamento em engenharia de software (CSEE&T),
IEEE, pp 176–184 31. Jalali S, Wohlin C (2012) Estudos sistemáticos de literatura:
pesquisas em banco de dados versus bola de neve para trás. In: ESEM, pp 29–38 32.
Krill P (2010) O desenvolvimento ágil de software é agora o fluxo principal.
InfoWorld, Pune 33. Kruchten P (2011) Contextualizando o desenvolvimento ágil de
software.
J Softw Evol Processo 25(4):351–361. doi:10.1002/smr.572 34. Kuhn TS
(1962) A estrutura das revoluções científicas. University of Chicago Press, Chicago 35.
Larman C, Basili VR (2003) Desenvolvimento iterativo e incremental: uma breve
história. IEEE Comput Soc 36:47–56 36. Lutters WG, Seaman CB (2007) Revelando o
uso real da documentação na manutenção de software através de histórias de
guerra. Inf Softw Tech nº 49:576–587
551
37. Meirelles P, Santos C, Miranda J, Kon F, Terceiro A, Chavez C (2010) Um estudo
das relações entre métricas de código fonte e atratividade em projetos de software
livre. In: 2010 Simpósio Brasileiro de Engenharia de Software (SBES), IEEE, pp 11–
20 38. Melnik G, Maurer F (2003) Introduzindo métodos ágeis em ambientes de
aprendizagem: lições aprendidas. In: Programação extrema e métodos ágeis. Notas de
aula em ciência da computação, vol 2753. Springer, Berlin, pp 172–184 39. Melnik
G, Maurer F (2005) Uma investigação entre programas das percepções dos alunos
sobre métodos ágeis. In: Anais do 27º Congresso Internacional de Engenharia de
Software. ACM, Nova York, pp 481–488 40. Melo CO, Cruzes D, Kon F, Conradi R
(2012a) Estudos de caso interpretativos sobre produtividade e gerenciamento de
equipes ágeis. Inf Softw Technol 55(2):412–427 41. Melo C, Santos VA, Corbucci
H, Katayama E, Goldman A, Kon F (2012b) Métodos ágeis no Brasil: estado da
prática em tempos e organizações. Parecer técnico 03, Departamento de Computação
(IME-USP). http://www.agilcoop.bg.br/MetodosAGE isBrasil2011. Acessado em
junho de 2013
42. Mena-Chalco JP, Cesar RM Jr (2009) Scriptlattes: um sistema de extração de
conhecimento de código aberto da plataforma lattes. J Brazilian Comput Soc 15:31–
39 43. Moe NB, Dingsoyr T, Dybå T (2010) Um modelo de trabalho em equipe para
entender uma equipe ágil: um estudo de caso de um projeto scrum. Inf Softw Technol
52:480–491
44. Muller MM, Link J, Sand R, Malpohl G (2004) Programação extrema no currículo:
experiências da academia e da indústria. In: Programação extrema e processos
ágeis em engenharia de software. Notas de palestra em ciência da computação,
vol 3092. Springer, Berlin, pp 294–302 45. Naumann JD, Jenkins AM (1982)
Prototipagem: o novo paradigma para o desenvolvimento de sistemas. MIS Q 6:29–
44 46. Nerur S, Cannon A, Balijepally V, Bond P (2010) Para uma compreensão dos
fundamentos conceituais das metodologias de desenvolvimento ágil. In: Dingsøyr
T, Dybå T, Moe N (eds) Desenvolvimento ágil de software. Springer, Berlin, pp 15–29 47.
Oliveira RdM, Goldman A, Melo C (2013) Projetando e gerenciando espaços de
trabalho informativos ágeis: descobrindo e explorando padrões. In: Proceedings of
the 46th Hawaii International Conference on Systems Science (HICSS-46). Grand
Wailea, Maui, pp 4790–4799
48. Poppendieck M, Poppendieck T (2003) Desenvolvimento de software enxuto: um kit
de ferramentas ágil. Addison-Wesley Longman Publishing Co., Inc., Boston 49.
Rico D, Sayani HH (2009) Uso de métodos ágeis no ensino de engenharia de
software. In: Agile 2009 conference, IEEE Computer Society, pp 174–179
50. Ries E (2011) A startup enxuta: como os empreendedores de hoje usam a inovação
contínua para criar negócios radicalmente bem-sucedidos.
Crown Business, New York 51.
Royce WW (1970) Managing the development of large software systems. In: Proceedings
of WESCON, pp 1–9. Also available in Proc. of ICSE 9, Computer Society Press,
1987 52. Sampaio A, Vasconcelos A, Sampaio P (2004) Assessing agile methods:
an empirical study. J Brazilian Comput Soc 10:22–41 53. Santos A, Martinez M, Kon F,
Gerosa M, Michalsky S, Rozestraten A (2011) Da coleta de dados ao conhecimento
obtido durante o desenvolvimento do projeto arquigrafia-Brasil. In: Congresso Inter
nacional de Design da Informação, pp 1–10
54. Santos V, Goldman A (2010) Aplicando técnicas de grounded the ory e retrospectiva
Ágil para buscar melhorias para o curso lab oratório xp (in Portuguese). In: VII
experimental software engi neering Latin America workshop (ESELAW). Goiânia,
Goiás, pp 60–69
123
Machine Translated by Google
552
55. Santos V, Goldman A (2011) Uma abordagem sobre a aplicação da
aprendizagem organizacional em organizações ágeis de software. In:
Processos ágeis em engenharia de software e programação extrema.
Notas de aula em processamento de informações de negócios, vol 77.
Springer, Berlim, pp 324–325
56. Sato DT, Corbucci H, Bravo MV (2008) Coding dojo: um ambiente para
aprender e compartilhar práticas ágeis. In: Proceedings agile 2008
conference, IEEE Computer Society, pp 459–464 57. Sato DT, Goldman
A, Kon F (2007) Acompanhando a evolução das métricas de qualidade
orientadas a objetos em projetos ágeis. In: XP, pp 84–92 58. SBC (ed)
(2011a) Workshop de engenharia de software experimental na América Latina,
ESELAW. http://cibse.inf.puc-rio.br/pt/program_eselaw.php . Acessado em
janeiro de 2012
59. SBC (ed) (2011b) Simpósio Brasileiro de Engenharia de Soft ware, SBES.
http://www.each.usp.br/cbsoft2011/portugues/sbes/ sbes_pt.html. Acessed
January 2012
60. SBC (ed) (2011c) Workshop Brasileiro de Métodos Ágeis, WBMA. http://
www.agilebrazil.com/2011/pt/wbma.php. Acessed January 2012
61. SBC (ed) (2011d) Workshop de Desenvolvimento Rápido de Apli cações,
WDRA. http://promise.cin.ufpe.br/wdra2011/index.html.
Acessado em janeiro de 2012
62. Schwaber K, Beedle M (2001) Desenvolvimento ágil de software com scrum,
1ª ed. Prentice Hall PTR, Upper Saddle River 63. Selm MV, Jankowski N
(2006) Realização de pesquisas online. Qual Quant 40:435–456 64. Sieber SD
(1973) A integração do trabalho de campo e métodos de pesquisa.
Am J Sociol 78:1335-1359
65. Sillitti A, Hazzan O, Bache E, Albaladejo X (eds) (2011) Anais dos processos
ágeis em engenharia de software e programação extrema - 12ª conferência
internacional, XP 2011. Notas de palestra em processamento de
informações de negócios, vol 77, Madrid , Espanha, 10–13 de maio de
2011. Springer, Berlim
66. Silva AF, Asmussen C, Kon F, Goldman A, Ferreira CE (2004)
Mico—planejador de horários universitários. In: 5º workshop sobre
software livre (WSL'2004), Porto Alegre, pp 147–150
123
J Braz Comput Soc (2013) 19:523–552
67. Silva AFd, Kon F, Torteli C (2005) XP ao sul do equador: uma experiência
de implementação do XP no Brasil. In: Anais da 6ª conferência internacional
sobre programação extrema e processos ágeis em engenharia de software
(XP2005). Springer, Berlim, pp 10-18
68. Softex (2010) Software e serviços de TI: a indústria brasileira em perspectiva,
vol 1. Observatório SOFTEX, Campinas 69. Sue VM, Ritter LA (2007)
Realização de pesquisas online. Sage Pub
lications, Inc., Londres
70. Tan CH, Teo HH (2007) Treinando futuros desenvolvedores de software
para adquirir habilidades de desenvolvimento ágil. Commun ACM 50:97–
98 71. Terceiro A, Costa J, Miranda J, Meirelles P, Rios LR, Almeida L, Chavez
C, Kon F (2010) Analizo: an extensible multi-language source analysis and
preview toolkit 72. VersionOne (2009) 4º estado anual de desenvolvimento
ágil. http://versionone.com/state_of_agile_development_survey/09 _ 73.
VersionOne (2010) 5º estado anual de desenvolvimento ágil. http://
versionone.com/state_of_agile_development_survey/10 _ 74. VersionOne
(2012) 7º estado anual de desenvolvimento ágil. http://www.versionone.com/
pdf/7th-Annual-state-of-Agile-Developm en- survey.pdf 75. Vinekar V, Slinkman
C, Nenu S (2006) As abordagens de desenvolvimento de sistemas ágil e
tradicional podem coexistir? Uma visão ambidestra.
Inform Syst Manag 23(3):31–42 76.
Wainer M (2003) Adaptações para o ensino de desenvolvimento de software
com programação extrema: um relato de experiência. In: Programação
extrema e métodos ágeis. Notas de aula em ciência da computação.
Springer, Berlin, vol 2753, pp 199–207 77.
West D, Grant T (2010) Desenvolvimento ágil: a adoção convencional mudou a
agilidade—tendências na adoção de métodos ágeis no mundo real.
Relatório técnico, Forrester Research 78. Whitworth E, Biddle R (2007) A
natureza social das equipes ágeis. In: Proceedings of the AGILE 2007. IEEE
Computer Society, Washington, pp 26–36 79. Williams L (2010)
Metodologias e práticas de desenvolvimento ágil de software. Computação
Adv 80:1–44