Casos Métodos Ágeis em Desenvolvimento de Software

Prévia do material em texto

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/299482818
Implantação de Métodos Ágeis em Empresa de Desenvolvimento de Software:
um Estudo de Caso
Conference Paper · January 2015
CITATIONS
0
READS
1,060
6 authors, including:
Some of the authors of this publication are also working on these related projects:
Scientific Writing and Research Methods View project
Artigo Dissertação mestrado View project
Mauricio Rotta
Federal University of Santa Catarina
16 PUBLICATIONS   18 CITATIONS   
SEE PROFILE
Andréa Cristina Trierweiller
Federal University of Santa Catarina
66 PUBLICATIONS   115 CITATIONS   
SEE PROFILE
Solange Maria Silva
Federal University of Santa Catarina
6 PUBLICATIONS   4 CITATIONS   
SEE PROFILE
Paulo Cesar Esteves
Federal University of Santa Catarina
12 PUBLICATIONS   3 CITATIONS   
SEE PROFILE
All content following this page was uploaded by Helio Aisenberg Ferenhof on 29 March 2016.
The user has requested enhancement of the downloaded file.
https://www.researchgate.net/publication/299482818_Implantacao_de_Metodos_Ageis_em_Empresa_de_Desenvolvimento_de_Software_um_Estudo_de_Caso?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_2&_esc=publicationCoverPdf
https://www.researchgate.net/publication/299482818_Implantacao_de_Metodos_Ageis_em_Empresa_de_Desenvolvimento_de_Software_um_Estudo_de_Caso?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_3&_esc=publicationCoverPdf
https://www.researchgate.net/project/Scientific-Writing-and-Research-Methods?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_9&_esc=publicationCoverPdf
https://www.researchgate.net/project/Artigo-Dissertacao-mestrado?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_9&_esc=publicationCoverPdf
https://www.researchgate.net/?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_1&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Mauricio_Rotta?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_4&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Mauricio_Rotta?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_5&_esc=publicationCoverPdf
https://www.researchgate.net/institution/Federal_University_of_Santa_Catarina2?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_6&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Mauricio_Rotta?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_7&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Andrea_Trierweiller?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_4&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Andrea_Trierweiller?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_5&_esc=publicationCoverPdf
https://www.researchgate.net/institution/Federal_University_of_Santa_Catarina2?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_6&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Andrea_Trierweiller?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_7&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Solange_Silva5?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_4&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Solange_Silva5?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_5&_esc=publicationCoverPdf
https://www.researchgate.net/institution/Federal_University_of_Santa_Catarina2?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_6&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Solange_Silva5?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_7&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Paulo_Cesar_Esteves?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_4&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Paulo_Cesar_Esteves?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_5&_esc=publicationCoverPdf
https://www.researchgate.net/institution/Federal_University_of_Santa_Catarina2?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_6&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Paulo_Cesar_Esteves?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_7&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Helio_Ferenhof?enrichId=rgreq-390c1b1cff5e6c9e87479c2d93472092-XXX&enrichSource=Y292ZXJQYWdlOzI5OTQ4MjgxODtBUzozNDQ5OTY2NTQ5Mjc4NzZAMTQ1OTI2NTAyMTAyMA%3D%3D&el=1_x_10&_esc=publicationCoverPdf
	
	
																																																														
	
																																																														
																																											
	
	
	
1 
Implantação de Métodos Ágeis em Empresa de Desenvolvimento de Software: um 
Estudo de Caso 
 
Maurício José Ribeiro Rotta 
Mestre, Universidade Federal de Santa Catarina – maurotta@gmail.com (Brasil) 
Rod. Amaro Antônio Vieira, 2155, D/501, Florianópolis, SC. 
 
Gregório Jean Varvakis Rados 
Prof. Doutor, Universidade Federal de Santa Catarina – grego@deps.ufsc.br (Brasil) 
 
Andréa Cristina Trierweiller 
Profa. Doutora, Universidade Federal de Santa Catarina–andreatri@gmail.com (Brasil) 
 
Solange Maria da Silva 
Profa. Doutora, Universidade Federal de Santa Catarina – solange.silva@ufsc.br (Brasil) 
 
Paulo Cesar Leite Esteves 
Prof. Doutor, Universidade Federal de Santa Catarina – paulo.esteves@ufsc.br (Brasil) 
 
Helio Ferenhof 
Prof. Doutor, Universidade Federal de Santa Catarina – dm@gotroot.com.br (Brasil) 
 
Resumo 
Assim como os métodos lean aumentaram a eficiência operacional e reduziram custos nos 
processos de manufatura da indústria, alterando o trade-off entre a produtividade e qualidade, 
a indústria de software segue na mesma direção, por meio de métodos de desenvolvimento ditos 
ágeis, compreendendo a disponibilidade contínua para criar, aceitar e aprender com a mudança, 
visando aumentar o valor percebido pelo cliente. Porém, a aplicação e institucionalização em 
grande escala das práticas ágeis, dentro de empresas que desenvolvem software, são 
desafiadoras: a alta direção, os gestores, aoperação e a cultura da empresa precisam mudar, 
abandonando práticas tradicionais, com foco na ampliação e adoção dos métodos ágeis em toda 
a empresa, alinhado aos processos de negócio e ao planejamento estratégico. Para apoiar as 
empresas no processo de mudança, existem diversas alternativas, destacam-se três modelos: 
Disciplined Agile Delivery (DAD), Large-Scale Scrum (LeSS) e Scaled Agile Framework 
(SAFe). Cada modelo foi desenvolvido considerando uma grande variedade de práticas ágeis e 
	
	
																																																														
	
																																																														
																																											
	
	
	
2 
enxutas (lean). O contexto da organização determinará a decisão em investir em um framework 
particular ou na seleção de um conjunto de práticas para se obter os resultados desejados. O 
objetivo deste artigo é discutir a aplicação em larga escala de princípios e metodologias ágeis 
com base em um estudo de caso, realizado na empresa Alfa, que está passando por um processo 
de implantação de tais metodologias a cerca de cinco anos. 
Palavras-chave: Lean, Desenvolvimento ágil, Scrum, Kanban, Desenvolvimento de software. 
 
Abstract 
As well as lean methods increased the operational efficiency and reduced the costs in the 
industry of manufacturing processes, changing the trade-off between productivity and quality, 
the software industry follows in the same direction, through so-called agile development 
methods, including the continued availability to create, accept and learn from change, to 
increase the value perceived by the customer. However, the implementation and 
institutionalization of agile practices on a large scale in software development organizations 
are challenging, senior management, managers, operation and corporate culture must change, 
abandoning traditional practices, focusing on the expansion and adoption of the agile methods 
enterprise-wide, aligned to business processes and strategic planning. To support companies in 
the process of change, we highlight three models: Disciplined Agile Delivery (DAD), Large-
Scale Scrum (Less) and Scaled Agile Framework (SAFe). Each model was developed 
considering a wide range of agile and lean practices. The organization's context will determine 
the decision to invest in a particular framework or selection of a set of practices to obtain the 
desired results. The purpose of this article is to discuss the large-scale application of principles 
and agile methodologies based on a case study conducted at Alfa Company, which is 
undergoing on a process of deploying such methodologies to about five years. 
Keywords: Lean, Agile development, Scrum, Kanban, Software development 
 
Área Temática: Tecnologias da informação e GC 
 
	
	
																																																														
	
																																																														
																																											
	
	
	
3 
Implantação de Métodos Ágeis em Empresa de Desenvolvimento de Software: um 
Estudo de Caso 
 
 
Introdução 
 
A eficiência operacional e a redução de custos são temas muito estudados e 
desenvolvidos na indústria, tendo inclusive derivado para métodos lean ou de produção enxuta. 
De acordo com Holweg (2006), a produção enxuta não só desafiou com sucesso as práticas de 
produção em massa, aceitas na indústria automotiva, alterando de forma significativa o trade-
off entre produtividade e qualidade, mas também levou o repensar das operações de manufatura 
e de serviços, para além do alto volume de produção repetitiva. A indústria de manufatura de 
software seguiu na mesma esteira, por meio de métodos de desenvolvimento ditos ágeis, 
inspirados na produção enxuta, segundo Reinertsen (2009), além de outros autores. 
O desenvolvimento ágil é resultado de discussões e encontros realizados, de forma 
independente, por profissionais renomados na área de engenharia de software, visando 
minimizar os riscos associados ao desenvolvimento de software, pensando e agindo de forma 
muito diferente do que tradicionalmente está nos livros. O principal marco relacionado ao 
desenvolvimento ágil, ocorreu no início de 2001 durante um workshop realizado em Snowbird, 
Utah, EUA (Highsmith, 2001). Embora muitos profissionais e consultores de desenvolvimento 
de software tivessem suas próprias práticas e teorias preferidas, todos concordavam que, com 
base em experiências anteriores, projetos de sucesso tem em comum um pequeno conjunto de 
princípios. Assim, nasceu o Manifesto for Agile Software Development (2001), também 
conhecido por Manifesto Ágil. Ou seja, o termo Desenvolvimento Ágil identifica metodologias 
de desenvolvimento que adotam os princípios do Manifesto Ágil. 
Conboy (2009) define o desenvolvimento ágil de software como a disponibilidade 
contínua para criar rapidamente a mudança, aceita-la de forma proativa ou reativa, e aprender 
com ela, contribuindo para o valor percebido pelo cliente (economia, qualidade e simplicidade). 
A aplicação e institucionalização em grande escala das práticas ágeis dentro de empresas que 
	
	
																																																														
	
																																																														
																																											
	
	
	
4 
desenvolvem software se mostram desafiadoras, uma vez que a resistência à mudança e o 
desconhecimento de muitos profissionais se apresentam como barreiras para a implantação 
bem-sucedida de uma nova forma de trabalhar. De acordo com Dingsøyr e Moe (2014), o 
desenvolvimento ágil em grande escala significa a aplicação de práticas em grandes equipes, 
grandes projetos, fazendo uso dos princípios em toda a organização. 
O planejamento estratégico da deve refletir tal decisão. Muitas instituições que 
desenvolvem sistemas de informação, aplicando os princípios ágeis em nível de equipes, têm o 
desafio da ampliação e adoção dessas práticas em toda a empresa, alinhadas aos processos de 
negócio e ao planejamento estratégico. Este desafio pode ter sua origem na expansão de um 
projeto piloto, inicialmente envolvendo poucas equipes, ou um conjunto de equipes ágeis, 
juntamente com equipes ditas “tradicionais” de desenvolvimento. Gerando algum nível de 
confusão, já que equipes distintas aplicam métodos de desenvolvimento diferentes entre si. 
A introdução de práticas ágeis desafia as estruturas e práticas existentes, e traz à tona 
questões relacionadas aos papéis tradicionais, responsabilidades e expectativas. Algumas 
decisões precisam ser tomadas, referentes à estratégia de implantação das metodologias ágeis: 
a organização deve continuar aprimorando as práticas em nível de equipes, ou deve tentar 
expandir o uso das práticas ágeis para outras áreas? Assim, uma organização pode ficar densa 
em termos de processos de negócios e arriscar a transição para práticas ágeis? 
Visando responder estes questionamentos, há basicamente três modelos de escala que 
buscam estruturar as práticas ágeis nas organizações: Disciplined Agile Delivery (DAD), Large-
Scale Scrum (LeSS), e Scaled Agile Framework (SAFe). Cada um desses frameworks foi 
desenvolvido considerando uma grande variedade de práticas ágeis e enxutas (lean). O contexto 
de uma organização irá determinar a decisão em investir em um framework particular, ou na 
seleção de um conjunto de práticas para se obter os resultados desejados. 
Neste artigo, o tema da aplicação em larga escala de princípios e metodologias ágeis é 
discutido em conjunto com um estudo de caso, realizado na empresa Alfa (denominação 
fictícia), com um processo de implantação de tais metodologias há cerca de cinco anos. Por 
meio desta abordagem, é possível averiguar os benefícios e dificuldades encontradas pela 
empresa, em comparação com as principais abordagens para a implantação das práticas ágeis.5 
Em Busca de Metodologias para o Desenvolvimento Ágil de software 
 
Scrum 
De acordo com Pressman (2006), Scrum é uma metodologia ágil de desenvolvimento 
para gestão e planejamento de projetos de software. Foi elaborada por Jeff Sutherland e por sua 
equipe, no começo da década de 90, e teve como base o processo de produção de automóveis 
das indústrias japonesas. 
Conforme Kninberg (2007), os processos do Scrum compreendem as seguintes 
atividades: requisitos, análise, projeto, evolução e entrega. Em cada atividade, as tarefas 
ocorrem dentro de um padrão de processo chamado de Sprint. A Sprint representa um timebox 
(intervalo de tempo com duração definida) no qual um conjunto de atividades deve ser 
executado, de forma interativa, dentro de um intervalo predefinido (normalmente, de 2 a 4 
semanas). A Figura 1 representa o ciclo de vida do desenvolvimento de software com o Scrum: 
 
Figura 1. Framework Scrum. 
Fonte: Scrum Alliance (2014) 
	
Conforme o Scrum Alliance (2014), o Scrum é um dos métodos ágeis mais conhecido e 
utilizados na indústria de Tecnologia da Informação e Comunicação (TIC), e especifica um 
conjunto mínimo de práticas, definindo três papéis em uma equipe: 
Product Owner (PO): é a pessoa mais próxima da parte de negócio do projeto, e é 
cobrado pela organização pela entrega do produto, visando a satisfação dos stakeholders, 
	
	
																																																														
	
																																																														
																																											
	
	
	
6 
assegurando a visibilidade do Product Backlog e o progresso do trabalho sobre este. 
ScrumMaster (SM): líder do time de desenvolvimento, deve ter um bom conhecimento 
do framework Scrum e a habilidade de treinar outras pessoas. É responsável por apoiar o PO na 
criação e manutenção do Product Backlog, e auxiliar o time de desenvolvimento na execução 
de cada Sprint, atuando como um coach. 
Membro do time de desenvolvimento: responsável pela entrega do Incremento do 
Produto (desenvolvimento de funcionalidades previstas e priorizadas no Product Backlog). 
De acordo com o Scrum Alliance (2014), ao aplicar as práticas do Scrum, cada time ou 
equipe deve gerenciar suas atividades através de artefatos: 
1. Product Backlog: trata-se de uma lista ordenada de ideias para o produto, mantida na 
ordem em que se deseja executá-las, da qual todos os requisitos fluem. Logo, todo o trabalho 
do time de desenvolvimento é originado no Product Backlog - funcionalidades, melhorias, 
correções de problemas e documentação, com a respectiva descrição e estimativa. 
2. Sprint Backlog: é a lista de itens refinados do Product Backlog, os quais foram 
escolhidos para o desenvolvimento na Sprint atual, acompanhados do plano do time para 
completar o trabalho. 
3. Incremento de produto: É o mais importante do Scrum. Cada Sprint produz um 
Incremento do Produto, o qual deve apresentar qualidade suficientemente alta para entrega aos 
usuários, satisfazendo à Definição de Pronto atual da equipe Scrum, e cada um de seus 
componentes deve ser aceitável para o Product Owner. 
4. Definição de Pronto: Quando o Incremento do Produto é entregue, deve estar 
“pronto”, conforme a compreensão compartilhada do que “pronto” significa. Essa definição 
pode ser diferente para cada equipe Scrum. 
Segundo o Scrum Alliance (2014), para atingir seus objetivos, o Scrum especifica cinco 
atividades para as equipes: 
1. Refinamento do Backlog: trata-se de uma atividade contínua ao longo do projeto 
Scrum, visando: Manter o Product Backlog ordenado; Remover ou postergar o 
desenvolvimento de itens que não são mais importantes; Adicionar ou adiantar 
desenvolvimento de novos itens ou se tornem mais importantes; Dividir itens em itens menores; 
	
	
																																																														
	
																																																														
																																											
	
	
	
7 
Fundir itens em itens maiores; Estimar itens. 
2. Planejamento das Sprints: Cada Sprint se inicia com uma reunião de planejamento, 
em que toda a equipe Scrum seleciona o trabalho a ser realizado na Sprint que se inicia. 
Trabalhando a partir da ordenação do Product Backlog, o Product Owner e os membros da 
equipe de desenvolvimento discutem cada item, e chegam a um entendimento compartilhado 
do item e o que é necessário para completá-lo de forma consistente com a Definição de Pronto 
atual. 
3. Daily Scrum (Scrum diário): A equipe de desenvolvimento realiza uma reunião 
Scrum diariamente, visando assegurar que o grupo está no caminho certo para alcançar a meta 
da Sprint. Essa reunião deve ocorrer no mesmo horário e local todos os dias, sendo que cada 
membro da equipe de desenvolvimento apresenta três breves informações: O que terminei desde 
a última Daily Scrum; O que pretendo terminar até a próxima Daily Scrum; O que está 
impedindo meu progresso. O timebox (tempo de reunião) recomendado para a Daily Scrum é 
de não mais que quinze minutos. 
4. Sprint Review: Ao final da Sprint, o time de Scrum e stakeholders revisam as saídas 
da Sprint, e o ponto central para discussão é o Incremento do Produto completado durante a 
Sprint. Cada equipe encontra sua própria maneira de conduzir a Sprint Review. 
5. Sprint Retrospective: Ao final de cada Sprint, o time de Scrum se encontra para a 
Sprint Retrospective, revisa o emprego dos processos, relações entre as pessoas e as ferramentas 
utilizadas. O time identifica aspectos positivos e negativos da Sprint, e melhorias para o futuro. 
Além desses papéis, artefatos e atividades, as práticas do Scrum não trazem 
recomendações para o desenvolvimento em escala, para além do nível da equipe. De acordo 
com as práticas Scrum, é responsabilidade da liderança fornecer visão e objetivos mais amplo, 
e também capacitar e desenvolver equipes ágeis auto organizadas. Ainda, de acordo com o 
Scrum, à medida que as equipes vão se tornando mais experientes e maduras, naturalmente 
surgem práticas que irão apoiar a organização na jornada rumo a uma melhor agilidade. 
 
Kanban 
Conforme Ahmad, Markkula e Oivo (2013), a abordagem Kanban foi introduzida na 
	
	
																																																														
	
																																																														
																																											
	
	
	
8 
indústria de manufatura japonesa na década de 1950 – desenvolvido por Taiichi Ohno, usado 
na fabricação como um sistema de agendamento e sequenciamento de atividades. É um 
mecanismo de controle de fluxo para a produção Just-In-Time, empregado pela Toyota. 
Segundo Carvalho e Mello (2012), as técnicas de desenvolvimento ágil de produtos de 
software foram fortemente influenciadas pelas melhores práticas da indústria japonesa, 
especialmente, pelos princípios da manufatura enxuta praticados pela Honda e Toyota e, pelas 
estratégias de gestão do conhecimento de Takeuchi e Nonaka (2004) e Senge (1990). 
O método Kanban em desenvolvimento de software teve origem em 2004, quando 
David J. Anderson auxiliou uma pequena equipe de TI da Microsoft, que apresentava baixo 
desempenho. Conforme Reinertsen (2009), este método visa impulsionar as equipes de 
desenvolvimento, por meio da visualização do fluxo de trabalho em um quadro, e também por 
limitar o trabalho em andamento – work in progress (WIP) – em cada etapa do fluxo de trabalho, 
medindo o tempo de cada ciclo. O quadro Kanban (Figura 2) fornece visibilidade ao processo 
de software, apresentando o trabalho atribuído para cada colaborador. 
 
Figura 2. Quadro Kanban. 
Fonte: Cavalcante (2013) 
De acordo com Ahmad, Markkula e Oivo (2014), o Kanban não é específico na 
definição de suas práticas, sendo que, geralmente duas práticas são empregadas: 
a. Visualização do fluxo de trabalho, por meio de um quadro Kanban, e 
b. Definição do limite de work-in-progress para cada etapado fluxo de trabalho. 
	
	
																																																														
	
																																																														
																																											
	
	
	
9 
Conforme Anderson (2010), ainda podem ser acrescentadas três outras práticas: 
a. Medição e gestão do fluxo de trabalho, 
b. Explicitar as políticas do processo de desenvolvimento e 
c. Utilização de modelos para reconhecer oportunidades de melhoria. 
Assim como o Scrum, Kanban depende de equipes auto organizadas e de líderes 
envolvidos na elaboração de outras práticas que apoia a adoção de métodos ágeis na 
organização. 
O esforço para a mudança do SDLC mobilizou as principais áreas produtivas da Alfa, 
visando à implantação das práticas ágeis na organização. Parte do esforço envolveu não apenas 
abordar práticas do nível das equipes, mas alinhar mais de 20 equipes ágeis para trabalhar em 
conjunto com o restante da organização, que ainda utilizava métodos tradicionais. No momento, 
o modelo de referência da Alfa para desenvolvimento em escala é o SAFe. Além deste modelo 
de referência, também podem ser consideradas duas outras metodologias de escala – 
Disciplined Agile Framework (DAD) e Large Scale Scrum (LeSS). Estes frameworks propõem 
práticas para além do nível da equipe, empregando uma combinação baseadas em conceitos 
Agile e Lean. A Alfa está utilizando uma abordagem pragmática para a implantação dos 
conceitos Agile e Lean, combinando e modificando as práticas que atendem e apoiam o 
cumprimento de seus objetivos de negócio. 
 
Disciplined Agile Framework (DAD) 
O Disciplined Agile Framework (DAD) foi desenvolvido por Scott Ambler e é uma 
tentativa de "preencher as lacunas do processo que o Scrum ignora propositadamente" (Ambler; 
Lines, 2012). O DAD é uma "abordagem híbrida que estende o Scrum com estratégias de Preven 
Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, lean 
Software Development, Outside In Development (OID) e vários outros métodos" (Ambler, 
2013). As equipes DAD tem seu "foco na produção de resultados repetitivos, como a entrega 
de software de alta qualidade... [mas] não se esforçam para seguir processos repetitivos" 
(Ambler, 2012). 
 
	
	
																																																														
	
																																																														
																																											
	
	
	
10 
Large Scale Scrum (LeSS) 
Conforme Larman e Vodde (2013), a metodologia Large Scale Scrum (LeSS) foi 
desenvolvida para aplicar o Scrum em grandes projetos de software, em vários locais ou 
offshore. Recomendam a aplicação da LeSS para projetos que envolvam cerca de 800 pessoas 
em 5 locais distintos, com cerca de 15 milhões de linhas de código-fonte. O framework LeSS 
especifica as mudanças organizacionais que devem ser encaminhadas (as quais não são 
diretamente abordadas no padrão tradicional do Scrum), e determina a criação de equipes cross-
funcionais por meio da eliminação de papéis tradicionais, tais como líderes de equipe e gerente 
de projetos. Em um artigo descrevendo um estudo de caso do J.P, Morgan, Larman e Winn 
(2014) relatam que, com o emprego da metodologia LeSS, as equipes de desenvolvimento 
apresentavam uma "combinação de domínio, técnica e habilidades funcionais”, ou seja: 
características de equipes cross-funcional. 
Segundo Larman e Vodde (2013), a metologia LeSS recomenda duas abordagens: a 
primeira cobre até dez equipes Scrum (chamada de LeSS framework-1) e outra para os casos 
em que mais de dez equipes trabalham no mesmo projeto (chamado de LeSS framework-2). 
Logo, equipes com até 100 pessoas devem empregar o LeSS framework-1, uma vez que a 
metodologia LeSS recomenda que o tamanho da equipe tenha até dez membros. No LeSS 
framework-2, a escalabilidade das equipes é realizada utilizando em conjunto, grupos de LeSS 
framework-1. 
 
Scaled Agile Framework (SAFe) 
O SAFe estrutura 3 níveis de organização: Team, Program e Portfolio. Cada nível tem 
suas próprias atividades, todos são integrados. O SAFe incorpora práticas ágeis e enxutas nos 3 
níveis, fornecendo padrões para o tamanho das equipes e do programa, que podem ser 
empregados em escala (Leffingwell, 2011). O framework é apresentado na Figura 3. 
	
	
																																																														
	
																																																														
																																											
	
	
	
11 
 
Figura 3. Scaled Agile Framework. 
Fonte: Leffingwell (2011) 
	
O SAFe emprega o tamanho padrão de uma equipe Scrum, que consiste entre 5 a 9 
membros da equipe. Um programa, por sua vez, é definido como um conjunto de 5 a 12 equipes 
ágeis ou 50 a 125 indivíduos que se dedicam permanentemente ao programa. 
 
Papéis 
De acordo com Leffingwell (2011), em nível de equipe, uma equipe ágil continua a se 
assemelhar a uma equipe típica Scrum com algumas variações. A equipe tem um ScrumMaster, 
o qual pode ser um papel desempenhado em tempo parcial por um membro da equipe (25-50%), 
ou um único ScrumMaster pode ser compartilhado entre 2-3 equipes. A equipe, chamada de 
ScrumXP, continua a ter um Product Owner e uma equipe de 5-9 membros, assim como no 
padrão tradicional do Scrum. Uma equipe ScrumXP poderá ser uma equipe muito especializada, 
não sendo necessariamente cross-functional. As equipes ScrumXP devem operar de forma 
coordenada e coesa entre si para desenvolver e entregar valor para o usuário final. Além disso, 
uma equipe ScrumXP deve ter capacidade para projetar, construir e testar o seu próprio trabalho. 
Em nível de Programa, vários papéis e equipes foram criados (Leffingwell, 2011): 
	
	
																																																														
	
																																																														
																																											
	
	
	
12 
a. Gerente de Produto: "autoridade de conteúdo” para o Agile Release Train e é 
responsável pela definição das prioridades do Backlog de Programa, e também por trabalhar 
com os Product Owners para otimizar a distribuição de recursos. O Gerente de Produto realiza 
a gestão do trabalho dos Product Owners em nível de equipe. 
b. System Architect: voltado para desenvolver a arquitetura up-front e orientar o 
desenvolvimento da arquitetura entre todas as demais equipes do Programa. 
c. Release Train Engineer: Assim como um gerente de produto é um "Product Owner 
Chief" para o Programa, o papel de Release Train Engineer opera como um "ScrumMaster 
Chief". O Release Train Engineer facilita os processos de nível de programa e execução do 
programa, resolve impedimentos, realiza a gestão de riscos, e apoia na melhoria contínua. 
d. User Experience ou UX Designer: fornece orientações de modo a proporcionar uma 
experiência de usuário consistente entre os componentes e sistemas da solução maior. 
Conforme Leffingwell (2011), o desenvolvimento de funcionalidades do sistema é 
realizado de forma sincronizada por meio de várias equipes em um Agile Release Train (ART), 
de forma cadenciada em interações em timebox, com data e qualidade fixos, mas de escopo 
variável. Cada ART produz lançamentos ou incrementos (PSIs) numa frequência de 60 a 120 
dias. A metodologia SAFe estruturou equipes de nível de programa adicionais, além dos papéis 
individuais já mencionados, considerando o seguinte: 
a. Business Owner Team: composta de três a cinco stakeholders, tem a responsabilidade 
final sobre a governança, eficácia e ROI do valor entregue por um release train específico. 
b. Release Management Team: responsável pela programação, governança e gestão de 
uma ou muitas linhas de produtos. 
c. DevOps Team: responsável por proporcionar maior integração entre as equipes de 
desenvolvimento e operação, e por manter a prontidão para a implantação do Programa. 
d. System Team: responsável pela prestação de assistência na construção e utilizaçãoda 
infraestrutura do ambiente de desenvolvimento - incluindo Integração contínua, construção de 
ambientes, homologação das plataformas e estruturas de automação de teste, bem como a 
integração de código entre as equipes ágeis, realizando testes dos sistemas, e pela demonstração 
de soluções para os stakeholders em cada iteração. 
	
	
																																																														
	
																																																														
																																											
	
	
	
13 
No nível do Portfolio, a metodologia SAFe define as seguintes equipes: 
Program Portfolio Management Team: representa o mais alto nível de gestão e controle 
de investimento e retorno, e de autoridade de conteúdo (o que está sendo desenvolvido). Esta 
equipe é composta por gerentes de negócios e executivos com conhecimento da estratégia de 
negócios da empresa, tecnologia, e restrições financeiras, com responsabilidade pelo 
fornecimento da visão do portfólio, bem como dos investimentos e financiamentos estratégicos 
e da governança global do porfolio. 
	
Práticas 
De acordo com as orientações de Leffingwell (2011), em nível de equipes, a 
metodologia SAFe emprega uma combinação do Scrum e Extreme Programming (XP), 
relacionadas a garantia de qualidade de código e práticas de engenharia de software ágil. Estas 
práticas incluem Arquitetura Ágil, Integração Contínua, Test-First, Refactoração de Código, 
Trabalho em Pares, e Collective Ownership Code. Além disso, o SAFe considera que as equipes 
irão produzir um Incremento Potencialmente Utilizável (PSI) a cada trimestre, e não a cada 
Sprint. 
Em nível do programa fornece os requisitos de sistema, os quais serão analisados e 
programados em função de seu tamanho para incluir nas iterações de produto. 
Também emprega o Agile Release Train (ART), voltado para o desenvolvimento de 
sistemas em larga escala, o qual é composto por quatro interações de duas semanas, seguidas 
de uma interação de três semanas, chamada de HIP (Hardening, Innovation and Planning). As 
equipes devem se dedicar ao ART, desenvolvendo e lançando de forma síncrona o PSI na 
mesma cadência trimestral. 
Um System Team geralmente atua na retaguarda das equipes ART. O System Team 
integra o código de várias equipes ART e executa testes de desempenho do sistema, de forma 
manual ou por meio de testes automatizados. O System Team também ajuda a organizar um 
System Sprint Demo, onde as equipes apresentam o sistema para os stakeholders. 
No final de cada trimestre, durante a interação HIP, todas as equipes participantes do 
ART planejam o próximo PSI durante uma reunião all-hands Release Planning. Durante a 
	
	
																																																														
	
																																																														
																																											
	
	
	
14 
execução de um PSI, é realizado duas vezes por semana o Scrum de Scrum para todas as equipes 
ART. 
Em nível Portfolio, o SAFe introduz conceitos sobre “temas de investimento” e “fluxo 
de valor” para o alinhamento dos ARTs em nível do programa. Um fluxo de valor é definido 
como séries de longa duração de definição do sistema, desenvolvimento e etapas do processo 
de implementação utilizados para construir e implantar sistemas que fornecem um fluxo 
contínuo de valor para o negócio, cliente ou usuário final. No jargão SAFe, um fluxo de valor 
é realizado por meio de um ART em nível de programa. Por sua vez, temas de investimento 
devem refletir como o Portfolio aloca orçamento para os ARTs que implementam a estratégia 
de negócios. Estes temas, por sua vez, funcionam como um funil, semeando o backlog do 
portfólio com épicos de negócios ou técnicos. Existem dois tipos de épicos no SAFe – Negócio 
e Arquitetura. Épicos de negócios são tipicamente grandes iniciativas voltadas para o cliente 
que englobam o esforço necessário para desenvolver certos benefícios de negócio, e os Épicos 
de Arquitetura são iniciativas tecnológicas necessárias para evoluir as soluções de Portfolio, 
atendendo necessidades de negócios. 
 
Práticas em nível de Programa e Portfolio 
Os métodos ágeis, como Scrum, Extreme Programming (XP), Kanban, oferecem 
práticas que geralmente começam com as equipes. Muitos dos métodos ágeis supõem que, por 
meio da auto-organização, equipes verdadeiramente cross-functional serão capazes de realizar 
entregas com rapidez e cadência, com alta qualidade, e que serão capazes de responder às 
mudanças e trabalhar em um ritmo sustentável durante um longo período. Empresas que fizeram 
a transição para a aplicação de práticas ágeis em sua SDLC, mas ainda empregam técnicas de 
gestão de portfólio e ciclo de desenvolvimento de vida de produto (Product Development Life 
Cycle - PDLC) tradicionais, não obtém muita orientação concreta de métodos ágeis. Em 
organizações menores, em que as estruturas e os processos formais não existem, ou onde são 
menos hierárquicas, a adoção de práticas ágeis pode ocorrer de forma rápida e com relativa 
facilidade.. Para transformar grandes organizações, as práticas ágeis em níveis de equipe geram 
questões mais amplas sobre: (1) Projeto organizacional, (b) Gestão hierárquica nos moldes 
	
	
																																																														
	
																																																														
																																											
	
	
	
15 
comando e controle, (c) Práticas de gestão e Recursos Humanos, e (d) Cultura geral da empresa 
(Vaidya, 2014). 
Os três frameworks de escala – DAD, LeSS e SAFe, fornecem abordagens para algumas 
dos desafios que a organização irá enfrentar, e as respectivas soluções. Contudo, é importante 
considerar que cada framework tem qualidades e falhas (Vaidya, 2014). 
Como regra geral, não é recomendado adotar um framework de escala sem a devida 
customização para as necessidades da empresa. De acordo com Seethamraju e Marjanovic 
(2009), muito provavelmente, nenhum framework estará completamente alinhado e uma 
abordagem mais segura é buscar algumas práticas que possam auxiliar na definição das 
necessidades da empresa, e procurar realizar ajustes contínuos. Vários projetos e equipes estão 
alinhados e coordenados com o planejamento trimestral sincronizado e a programação das 
Sprints (Figura 4). 
	
Figura 4. Representação visual do processo. 
Fonte: dos autores 
	
	
																																																														
	
																																																														
																																											
	
	
	
16 
Método 
 
Trata-se de um estudo de caso de natureza exploratória-descritiva em empresa de 
desenvolvimento de software. O estudo de caso se caracteriza por sua grande flexibilidade, 
sendo impossível estabelecer um roteiro rígido que determine com exatidão como deverá ser 
executada a pesquisa. No entanto, segundo o autor, geralmente, este tipo de pesquisa segue 
quatro fases: a delimitação da unidade-caso a ser estudada, o levantamento, análise e 
interpretação dos dados e por fim, a redação do relatório. O estudo de caso é caracterizado pela 
investigação profunda e exaustivo de um ou de poucos objetos, permitindo um conhecimento 
detalhado e amplo, o que é praticamente impossível com outros tipos de delineamentos de 
pesquisa (GIL, 2008). 
A Alfa adotou o Scrum (Agile Scaling Frameworks) como sua metodologia principal, 
ao modificar o SDLC para o emprego de abordagens ágeis. Muitos métodos ágeis oferecem 
práticas específicas para orientação no nível das equipes. Entretanto, conforme Kniberg e 
Ivarsson (2012) e Ambler (2013), os métodos ágeis em geral não foram desenhados para 
orientar práticas organizacionais mais amplas, como os processos de front end de 
desenvolvimento de software, tais como a aprovação de requisitos de sistema, estimativas de 
custo/esforço, integração entre projetos ou processos de back end – interação comparceiros e 
fornecedores, preparação do sistema para implantação, e a contabilização dos benefícios 
obtidos, após a implantação. 
Há quase cinco anos, a Alfa Sistemas vem realizando uma evolução no seu ciclo de 
desenvolvimento de vida de software (Software Development Life Cycle – SDLC), partindo de 
métodos tradicionais (cascata – waterfall), para a adoção de práticas ágeis de desenvolvimento. 
A Alfa é uma empresa desenvolvedora de soluções de Tecnologia de Informação e 
Comunicação (TIC), voltada para atendimento ao mercado de sistemas corporativos. 
Assim como diversas empresas desenvolvedoras de soluções de TIC, a Alfa vem 
enfrentando rápidas mudanças nas forças de mercado, refletindo diretamente nos custos 
operacionais para a manutenção e o desenvolvimento dos principais processos de trabalho da 
empresa, bem como para recrutar, capacitar e reter a mão-de-obra, uma vez que o conhecimento 
	
	
																																																														
	
																																																														
																																											
	
	
	
17 
é o principal ativo da empresa, sendo responsável pela força competitiva das instituições, de 
acordo com Araújo, Inomata e Varvakis (2014) e Santos, Leocádio e Varvakis (2010). 
Conforme Trierweiller et al. (2012), necessidades organizacionais para a sobrevivência 
e/ou crescimento - seja por meio da globalização, a inspiração de um empreendedor, ou mesmo 
através das necessidades das partes interessadas – são preocupações frequentemente 
mencionados dentro da literatura organizacional e prática. Afinal, em um ambiente 
extremamente competitivo, não é suficiente demonstrar eficiência dos processos e em alcançar 
resultados. As organizações devem demonstrar eficácia na análise de contingências, definição 
de estratégias e estruturas para atingir seus objetivos, e consistência ao longo do tempo, na 
busca contínua para garantir a existência de negócios e crescimento. 
A adoção de práticas ágeis foi a principal resposta para a empresa enfrentar os desafios 
do mercado e atingir seus objetivos de negócios. Todas as equipes de desenvolvimento da Alfa 
adotaram o Scrum e Kanban, além de outras práticas que vão além das equipes, ajudando na 
execução de projetos de desenvolvimento de software maiores e mais complexos. 
 
 
	
	
																																																														
	
																																																														
																																											
	
	
	
18 
Resultados 
 
Programação Sincronizada das Sprints da Empresa 
Com a mudança no SDLC para abordagens ágeis, a Alfa quebrou o paradigma dos silos 
funcionais da TI tradicional, e organizou-se em equipes ágeis multifuncionais, com 
profissionais das áreas de desenvolvimento, ensaio e análise. A predominância de times 
multifuncionais denota que a maior parte das equipes têm interdependências e precisam de 
coordenação e sincronização. Para tanto, se faz necessário empregar um cronograma 
sincronizado de Sprints em toda a empresa. Desde a transição da Alfa, adotou-se a duração de 
Sprint de 45 dias para todas as equipes. 
As metodologias SAFe e LeSS recomendam Sprints sincronizadas como padrão de 
escala. Cohn (2009), considera a sincronização de Sprints como uma maneira eficaz para 
coordenar e sincronizar várias equipes. Cada equipe precisa ter a mesma duração de Sprint. 
Na Alfa, as Sprints sincronizadas apoiam a coordenação continuada das equipes, em 
atividades que requerem a participação de vários times. Uma vez que todas as equipes estão na 
Sprint Planning no mesmo dia, os POs são capazes de coordenar as dependências e, se 
necessário, reordenar seus respectivos Sprint Backlogs. Além disso, as Sprints sincronizadas 
apoiam na redução de riscos de código sem testes ou não integrado, por períodos mais longos. 
Este, por sua vez ajuda a reduzir o tempo de desenvolvimento antes da implantação dos 
produtos. 
 
Reuniões de Scrum de Scrums 
As Sprints sincronizadas permitem as equipes ágeis coordenar e sincronizar suas 
atividades durante o planejamento da Sprint. No entanto, a Alfa buscou maneiras para as 
equipes estar alinhadas durante as Sprints, bem como acompanhar e monitorar o progresso do 
projeto. A fim de resolver esta questão, a empresa emprega reuniões de Projeto de Scrum de 
Scrums. Esta prática é recomendada pelo SAFe, bem como no LeSS. 
A frequência destas reuniões varia. Normalmente, cada projeto Scrum de Scrums se 
reúne pelo menos duas vezes por semana. A prática de Projeto de Scrum de Scrums melhora a 
	
	
																																																														
	
																																																														
																																											
	
	
	
19 
interação entre equipes ágeis, equipes de operações e outras unidades de negócio. Com o uso 
de Project Dashboards, a maioria dos projetos também utiliza a reunião de Scrum de Scrums 
para monitorar o progresso do desenvolvimento, verificar questões sobre a integração de código 
e a prontidão das entregas, para a coordenação entre fornecedores e parceiros e outras 
necessidades decorrentes da interação entre equipes. 
Outro grande benefício de reuniões de Scrum de Scrums, é a redução do esforço por 
parte do Escritório de Projetos (PMO) na coleta de status do projeto em cada equipe individual, 
bem como menos sobrecarga e distrações para as equipes ágeis. 
 
Reunião de Planejamento 
Como o Scrum especifica apenas dois níveis de planejamento - Sprint e Daily Scrums, 
a utilização de Scrum por si só não foi suficiente para a Alfa acompanhar e monitorar o 
progresso global da implementação do Portfolio no decorrer do ano. Devido a várias restrições 
de ordem contratual, o planejamento just-in-time nem sempre é suficiente. Para atender aos 
projetos do portfólio que precisam cumprir prazos de forma mais rigorosa junto aos clientes 
(prazos contratualmente definidos), a Alfa desenvolveu uma maneira de prever a demanda de 
trabalho e entender a capacidade dos recursos disponíveis. 
Neste sentido, a Alfa começou a organizar reuniões para o planejamento trimestral, 
visando definir a previsão da demanda de trabalho e o dimensionamento dos recursos. Assim, 
a cada trimestre, são realizadas reuniões com diversas equipes e projetos, para alinhar as 
atividades ao longo de um horizonte de médio prazo, e para obter insights sobre potenciais 
contenções de recursos e deadlines. 
Para as reuniões de planejamento trimestral, as equipes definem: (a) Backlog e os 
resultados específicos do projeto a serem atingidos, (b) Itens de backlog que não pertencem ao 
projeto, (c) Suporte aos produtos; (d) Outras atividades de manutenção. 
Muitas equipes também diminuem a capacidade de entrega para a participação ou 
execução de treinamentos, ou para o desenvolvimento de melhoria contínua em itens 
específicos, embora muitos considerem complexo alcançar um equilíbrio saudável entre todas 
as prioridades concorrentes do projeto e as necessárias melhorias contínuas. 
	
	
																																																														
	
																																																														
																																											
	
	
	
20 
O formato geral deste encontro é: 
a. Em nível de equipe, os membros da equipe refinam o backlog trimestral com o PO. 
b. Representantes das equipes participam da reunião de planejamento trimestral. 
Durante a primeira parte da reunião, as equipes se reúnem, discutem, e coordenam os trabalhos. 
Isso pode levar ao reordenamento de seus backlogs trimestrais, incluindo a identificação de 
trabalho adicional, ou de integração e testes de sistemas. 
c. As equipes identificam questões, impedimentos ou problemas que afetam a 
capacidade de comprometimento com um plano trimestral realizável. Isto inclui o planejamento 
de Hardening Sprints para as entregas do projeto. 
 
Benefícios 
Muitas daspráticas de nível de equipe e de empresa levaram a uma melhoria 
significativa nos resultados de entrega e qualidade da Alfa. Para realização das entregas, as 
equipes ágeis mantem um fluxo constante de valor de negócio, por meio de reuniões de 
planejamento trimestrais, as quais viabilizam a priorização de entregas, análise de riscos, 
questões e necessidades de capacidade, resultando em uma melhoria significativa na agilidade 
e adaptabilidade da empresa. 
Nos últimos anos, a Alfa recebeu muitas solicitações de alterações em requisitos 
funcionais estruturais de suas aplicações, envolvendo a integração com sistemas desenvolvidos 
por outros fornecedores. Estas solicitações incluem operar com parcerias desafiadoras, tais 
como Supremo Tribunal Federal e o Conselho Nacional de Justiça, os quais apresentaram 
problemas significativos para disponibilizar suas interfaces de integração, sem fornecer 
especificações e requisitos totalmente consistentes para a realização de testes de integração. 
Em grande parte, devido à implantação do Scrum, e as práticas de escala em nível 
empresarial, a Alfa alcançou nível de agilidade suficiente para atender a essas novas 
necessidades do mercado. No passado, este tipo de alteração introduzia estresse significativo na 
organização. 
Da mesma forma, a Alfa melhorou as práticas de qualidade, realizando mais cedo no 
ciclo do projeto, a integração de sistemas e testes de aceitação de usuário. 
	
	
																																																														
	
																																																														
																																											
	
	
	
21 
Desafios 
Como principais desafios para a implantação das metodologias ágeis na Alfa, pode-se 
destacar: 
(a) Disponibilidade de Product Owner em tempo integral em cada uma das equipes 
ágeis: A necessidade de um Product Owner é uma importante necessidade que continua a ser 
uma lacuna em algumas equipes. Muitas equipes ágeis representam várias áreas de negócio, e 
muitos POs estão disponíveis apenas em tempo parcial. Em muitos casos, um PO não está 
totalmente habilitado para representar determinadas áreas de negócio, mais específicas. 
(b) Organização de atividades por meio de práticas tradicionais de projeto: As 
atividades e orçamentos dos projetos são planejadas anualmente. Logo, dependendo do tipo de 
atividade, algumas equipes ágeis podem sofrer restrições de capacidade. Aumentar a capacidade 
das equipes existentes, ou criar novas equipes, requer tempo de espera, mesmo existindo 
orçamento disponível. A prática de adicionar ou alterar os membros de equipes existentes nem 
sempre é eficaz, pois pode gerar alguma desorganização. 
(c) Falta de uniformidade na adoção de práticas ágeis de engenharia: muitos 
esforços foram concentrados na inicialização das equipes ágeis, aclimatando os membros da 
equipe nos métodos ágeis, como Scrum ou Kanban. No entanto, a adoção de práticas de 
integração contínua, entrega contínua ou testes automatizados para diminuir a dependência de 
hardening Sprints, não foram uniformes. 
 
 
	
	
																																																														
	
																																																														
																																											
	
	
	
22 
Conclusões 
 
Conforme apontado por Vaidya, Row e Jackson (2012), cada um dos três frameworks 
de desenvolvimento Ágil tem seus prós e contras. Tem havido muita discussão na comunidade 
ágil, sobre a melhor maneira de escalar práticas ágeis em grandes organizações. Essas 
discussões geralmente derivam em dois lados. Um lado sustenta que as organizações devem 
aceitar mudanças (e às vezes radicais) em sua estrutura organizacional para alcançar a 
verdadeira agilidade. Isso significa mudanças no desenho organizacional, nas práticas de RH, 
se afastando da abordagem da administração científica tradicional (Taylor), da tomada de 
decisão estilo comando-e-controle, e de técnicas tradicionais de gestão de projetos, conforme 
Kniberg e Ivarsson (2012). O outro lado tende a defender uma abordagem mais gradual através 
da introdução de práticas transitórias, percebendo os benefícios de forma incremental e tangível, 
os quais podem gerar as mudanças necessárias. 
No entanto, Jeffries (2014), Vaidya (2014) e muitos outros “Agilistas”, através de sua 
crítica ao SAFe, advertem que estes frameworks de escala podem causar mais mal do que bem, 
podendo gerar uma falsa sensação de segurança. Com a aplicação destas práticas de escala, as 
empresas efetivamente transformam a maneira de fazer negócios, mas podem nunca alcançar a 
verdadeira agilidade, a hiper-produtividade, e uma força de trabalho mais inovadora e 
verdadeiramente engajada. Esta é uma crítica válida e representa um risco verdadeiro para uma 
organização, que pretende obter vantagem competitiva para enfrentar os desafios das rápidas 
mudanças nas condições de mercado. 
 
 
	
	
																																																														
	
																																																														
																																											
	
	
	
23 
Referências 
 
Ahmad, M.O., Markkula, J., & Oivo, M. (2013). Kanban in software development: a systematic 
literature review. In Software Engineering and Advanced Applications (SEAA), 2013 39th 
EUROMICRO Conference on (pp. 9-16). IEEE. Disponível em: 
<https://www.researchgate.net/publication/260739586_Kanban_in_Software_Development_A
_Systematic_Literature_Review> Acesso em 22 ago. 2015. 
Ahmad, M.O., Markkula, J., Oivo, M., & Kuvaja, P. (2014). Usage of Kanban in Software Companies: 
an empirical study on motivation, benefits and challenges. Disponível em: 
<https://www.researchgate.net/publication/267515017_Usage_of_Kanban_in_Software_Comp
anies_An_empirical_study_on_motivation_benefits_and_challenges> Acesso em 11 nov. 
2014. 
Ambler, S. (2012). Repeatable results over repeatable processes. Disponível em 
<https://disciplinedagiledelivery.wordpress.com/2012/05/17/repeatable-results-over-
repeatable-processes-2/> Acesso em 03 ago. 2015. 
Ambler, S. (2013). Going Beyond Scrum Disciplined Agile Delivery. Disponível em 
<http://disciplinedagileconsortium.org/Resources/Documents/BeyondScrum.pdf> Acesso em 
03 nov. 2014. 
Ambler, S., & Lines, M. (2012). Disciplined Agile Delivery - A Practitioner’s Guide to Agile Software 
Delivery in the Enterprise. IBM Press. 
Anderson, D. (2010). Kanban – Successful Evolutionary Change for Your Technology Business. Blue 
Hole Press. Disponível em <http://www.Scrumsense.com/wp-
content/uploads/2010/02/KanbanManuscript-dja-rev1_07_2.pdf> Acesso em 12 nov. 2014. 
Araújo, W.; Inomata, D.; & Varvakis, G. (2014). Desenvolvimento sustentável empresarial: o uso da 
gestão da informação. RDBCI, v. 12, n. 3, p. 119-135. 
Carvalho, B.V. de; & Mello, C.H.P. (2012). Aplicação do método ágil Scrum no desenvolvimento de 
produtos de software em uma pequena empresa de base tecnológica. Gestão & Produção, São 
Carlos, v. 19, n. 3, 557-573. 
Cavalcante, S.M.B. (2013). Vai usar Scrum, o que é preciso saber? Fábrica de Software. Disponível 
em: <http://4.bp.blogspot.com/-Zqpc07XbdRk/UE-
blck6REI/AAAAAAAABEQ/TxMuC5a_bfU/s1600/QUADRO_Kanban_atividades.png>. 
Acesso em 12/11/2014. 
	
	
																																																														
	
																																																														
																																											
	
	
	
24 
Cohn, M. (2009). Synchronize, Rather Than Overlap Sprints. Disponível em 
<http://www.mountaingoatsoftware.com/blog/synchronize-rather-than-overlap-Sprints> 
Acesso em 02 nov. 2014. 
Conboy, K. (2009). Agility From First Principles: Reconstructing the Concept of Agility in 
Information Systems Development, Information Systems Research, vol. 20, pp. 329-354. 
Dingsøyr, T., & Moe, N. (2014). Towards Principles of Large-Scale Agile Development: A Summary 
of the workshop at XP2014 and a revised researchagenda. Disponível em 
<https://www.researchgate.net/publication/269706735_Towards_Principles_of_Large-
Scale_Agile_Development_A_Summary_of_the_workshop_at_XP2014_and_a_revised_resear
ch_agenda> Acesso em 29 out. 2014. 
Gil, A.C. (2008). Métodos e técnicas de pesquisa social. 6. ed. - São Paulo: Atlas. 
Highsmith, J. (2001). History: The Agile Manifesto. Disponível em 
<http://agilemanifesto.org/history.html> Acesso em 11 out. 2014. 
Holweg, M. (2006). The genealogy of lean production. Judge Business School, University of 
Cambridge, United Kingdom, Disponível em <https://docs.google.com/file/d/0B33fj-
F2tuV5ZV90azNLNW5JcU0/edit>. Acesso em 12 nov. 2014. 
Jeffries, R. (2014). SAFe – Good But Not Good Enough. Disponível em: 
<http://xprogramming.com/articles/safe-good-but-not-good-enough/> Acesso em 15 nov. 
2014. 
Kniberg, H., & Ivarsson, A. (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters and 
Guilds. Disponível em 
<https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf> Acesso em 10 
ago. 2015. 
Kninberg, H. (2007). Scrum e Xp direto das Trincheiras: Como nós fazemos Scrum. C4media. 
Disponível em: <http://www.infoq.com/resource/minibooks/Scrum-xp-from-the-
trenches/pt/pdf/ScrumeXPDiretodasTrincheiras.pdf >. Acesso em 11 ago. 2015. 
Larman, C., & Vodde, B. (2013). Large Scale Scrum – More with LeSS. Disponível em 
<http://agileatlas.org/articles/item/large-scale-Scrum-more-with-less> Acesso em 10 out. 2014. 
Larman, C., & Winn, M. (2014). Large Scale Scrum (LeSS) @ J.P. Morgan. Disponível em 
<http://www.infoq.com/articles/large-scale-Scrum-jomorgan> Acesso em 10 set. 2014 
Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, 
Programs, and the Enterprise. Kindle edition, Addison-Wesley Professional. 
	
	
																																																														
	
																																																														
																																											
	
	
	
25 
Lines, M. (2012). Introduction to DAD. Disponível em <http://wp.me/P1ODzT-dx> Acesso em 30 set. 
2014. 
Manifesto for Agile Software Development. (2001). Disponível em <http://agilemanifesto.org/>. 
Acesso em 11 ago. 2014. 
Pressman, R.S. (2006). Engenharia de software. 6. ed. Rio de Janeiro: McGraw-Hill. 
Reinertsen, D. (2009). The Principles of Product Development Flow: Second Generation Lean Product 
Development. Disponível em <http://www.leanproductflow.com/wp-
content/uploads/2013/02/ReinertsenFLOWChap1.pdf>. Acesso em 03 set. 2014. 
Santos, J. L.S.; Leocádio, L.; & Varvakis, G. (2014). Gestão do Conhecimento como Processo: relação 
com tecnologias da informação e comunicação (TIC) e estratégia organizacional. Disponível 
em <leoleocadio.googlepages.com/Artigo_Estrategia_Conhecimento_KM200.pdf>. Acesso 
em 15 nov. 2014. 
Scrum Alliance. (2014). Certifications in Scrum, the leading framework for Agile software 
development. Disponível em: <https://www.Scrumalliance.org/>. Aceo em 15 ago. 2015. 
Seethamraju, R.; & Marjanovic, O. (2009). Role of process knowledge in business process 
improvement methodology: a case study. Business Process Management Journal, v. 15, n. 6, 
p. 920-936. 
Senge. P. (1990). The fifth discipline: the art and practice of the learning organization. New York: 
Currency. 
Takeuchi H., & Nonaka I. (2004). Hitotsubashi on knowledge management. Singapore: John Wiley & 
Sons. 
Trierweiller, A.C., Peixe, B.C.S., Tezza, R., Pereira, V.L.D. do V., Pacheco Jr., W., Bornia, A. C., & 
Andrade, D.F. (2012). Measuring organizational effectiveness in information and 
communication technology companies using item response theory. Work (Reading, MA). v.41, 
2795-2802. 
Vaidya, A. (2014). Does DAD Know Best, Is it Better to do LeSS or Just be SAFe? Adapting Scaling 
Agile Practices into the Enterprise. PNSQC 2014 Proceedings. Disponível em: 
<http://www.uploads.pnsqc.org/2014/Papers/t-033_Vaidya_paper.pdf>.Acesso em 28 ago. 
2015. 
Vaidya, A., Row, C., & Jackson, M. (2012). On the Way to Meeting a Mandate: Transitioning to Large 
Scale Agile, PNSQC.org, 2012, Disponível em <http://www.uploads.pnsqc.org/2012/papers/t- 
50_Vaidya_paper.pdf> Acesso em 28 ago. 2015. 
View publication statsView publication stats
https://www.researchgate.net/publication/299482818