abordagem lean no desenvolvimento de software Ágil: um estudo de … · ix congresso nacional de...
TRANSCRIPT
ABORDAGEM LEAN NO
DESENVOLVIMENTO DE SOFTWARE
ÁGIL: UM ESTUDO DE CASO EM UMA
EDITORA
Ricardo Patricio Kiste
(Escola Poltécnica da USP)
Dario Ikuo Miyake
(Escola Poltécnica da USP)
Resumo Na última década, novos métodos de desenvolvimento de software,
conhecidos como métodos ágeis, surgiram com a proposta de melhorar
essa atividade. Nesse contexto, embora o termo lean tenha passado a
ser frequentemente usado para caracterizaar práticas destinadas a
tornar mais ágil o processo de desenvolvimento de software, e
promover sua disseminação, nota-se ainda uma falta de consenso
sobre a forma como os elementos da abordagem lean podem ser
aplicados com este propósito. Com base em uma revisão da literatura,
este artigo discute os diferentes modos de aproveitamento da
abordagem lean na área de software. Além disso, se propõe a examinar
como iniciativas nesta direção têm sido conduzidas por profissionais
desta área por meio de um estudo de caso sobre o processo de
desenvolvimento de software de uma empresa brasileira. Os resultados
mostram que as fronteiras conceituais das abordagens lean e ágil
podem se sobrepor e que as práticas lean são mais usadas para
aprimorar ou reforçar os métodos de desenvolvimento ágil.
Palavras-chaves: desenvolvimento ágil de software, desenvolvimento
de software lean, scrum, software
20, 21 e 22 de junho de 2013
ISSN 1984-9354
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
2
1. INTRODUÇÃO
O desenvolvimento de software por muitos anos foi marcado como uma prática com
baixa taxa de sucesso. Em 1994 o relatório técnico intitulado “Chaos” do Standish Group
mostrou que apenas 16% dos projetos eram bem sucedidos (THE STANDISH GROUP
INTERNATIONAL INC, 1994). Ao mesmo tempo a demanda por desenvolvimentos cresceu
muito nas últimas décadas pressionado por métodos de desenvolvimento melhores e mais
ágeis.
Em 2001, em resposta à ineficiência dos métodos tradicionais de desenvolvimento,
surgiu o chamado “Manifesto Ágil” no qual um grupo de 17 profissionais da área introduzia
um conjunto de valores e princípios para a prática de desenvolvimento de software. Os
métodos baseados nesses princípios ficaram conhecidos como métodos “ágeis”, e entre eles
estão métodos que se tornaram consagrados como o Scrum (SCHWABER; BEEDLE, 2002) e
o eXtreme Programming (BECK, 1999).
Dois anos mais tarde Mary e Tom Poppendieck identificaram alguns princípios e
práticas atrelados à abordagem lean (“enxuta”) de melhoria do desempenho operacional, que
foi inicialmente disseminada no contexto de manufatura, como base para os métodos de
desenvolvimento ágeis de software (POPPENDIECK; POPPENDIECK, 2003). Assim, foi
introduzido o conceito de desenvolvimento de software lean e desde então, a comunidade ágil
tem cada vez mais olhado em sua direção (WANG; CONBOY; CAWLEY, 2012).
Originalmente o desenvolvimento de software lean foi visto como mais um método ágil
por muitos autores (DYBA; DINGSOYR, 2009). Poppendieck e Poppendieck (2003)
consideram que a abordagem lean fornece uma base teórica para os métodos ágeis, porém
tornam-se cada vez mais frequentes os estudos que consideram o método de desenvolvimento
lean independente e diferente dos métodos ágeis (HIBBS; JEWETT; SULLIVAN, 2009;
MIDDLETON; JOYCE, 2012; PETERSEN; WOHLIN, 2010). Vale salientar que também
existe a vertente de explorar a lógica do uso de práticas de produção lean para a melhoria dos
métodos de desenvolvimento ágil, como o exemplo do método chamado “Scrumban” que usa
o método ágil scrum com o método kanban da abordagem lean (NIKITINA; KAJKO-
MATTSSON; STRALE, 2012).
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
3
Assim, enquanto alguns autores entendem que os métodos ágeis podem ser reforçados
pelo aproveitamento de práticas lean, outros advogam que o desenvolvimento lean representa
a evolução do desenvolvimento ágil no contexto do desenvolvimento de software.
Nota-se portanto que há perspectivas diferentes sobre a relação entre as duas abordagens
aqui consideradas e sobre o escopo de cada uma o que dificulta a visão do posicionamento
mais claro de uma em relação à outra. A falta de estudos empíricos dificulta ainda mais a
compreensão de como as propostas destas abordagens têm influenciado a trajetória de
evolução das metodologias voltadas ao desenvolvimento de software.
Esse artigo tem o objetivo de buscar um melhor entendimento de como os princípios e
práticas lean são tratados no contexto do desenvolvimento ágil de software e assim contribuir
para elucidar a relação existente entre as abordagens lean e ágil na área de desenvolvimento
de software. Como estas abordagens tratam de conceitos e métodos direcionados a processos
bastante dinâmicos e em constante evolução, pretende-se também buscar este entendimento à
luz de subsídios empíricos do ambiente prático dos desenvolvedores de software.
O artigo inicia com uma revisão bibliográfica onde serão abordados os temas do
desenvolvimento ágil, desenvolvimento lean e a abordagem lean no contexto do
desenvolvimento ágil. Nessa seção, é traçado um panorama evolutivo sobre o tema de modo a
caracterizar o problema da pesquisa. Em seguida é apresentado o método de pesquisa adotado
que se apoiou no desenvolvimento de um estudo de caso simples na área de desenvolvimento
de software de uma empresa brasileira. O estudo de caso é apresentado em duas partes, sendo
a primeira dedicada à apresentação de forma descritiva do processo de desenvolvimento de
software ágil na unidade objeto de estudo e a segunda, à análise do caso para identificar a
forma como princípios e práticas lean são considerados no processo focado. Finalmente, é
apresentada uma síntese das principais conclusões e uma avaliação da perspectiva empírica
levantada por meio do estudo de caso.
2. REFERENCIAL TEÓRICO
2.1. A evolução para o desenvolvimento ágil
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
4
Conforme explicita o relatório Chaos, o desenvolvimento
de software foi marcado por uma alta taxa de insucessos.
Neste relatório, foram considerados projetos bem sucedidos
aqueles que foram completados no tempo, dentro do
orçamento e com todas as características e funcionalidades
inicialmente especificadas. Dos mais de 8000 projetos
estudados, apenas 16% obtiveram sucesso (THE STANDISH
GROUP INTERNATIONAL INC, 1994). Até a época de sua
publicação em meados da década de 1990, o método
amplamente adotado para desenvolvimento de software era
chamado Waterfall (cascata).
O método de desenvolvimento de software waterfall
consiste em dividir o projeto de desenvolvimento em fases
bem separadas e sequenciais, sendo que a fase seguinte só
deve ser iniciada quando a anterior estiver completa. Esse
caminho é sempre para baixo (ver Figura 1) e nunca para
cima, daí o codinome de cascata.
O método de desenvolvimento de software em cascata se
mostrou simples, porém ineficiente para a maioria dos casos.
Segundo Boehm (1988), uma das dificuldades de sua adoção é
causada pela sua ênfase à elaboração de documentos nos
estágios iniciais dos projetos quando usuários e
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
5
desenvolvedores ainda não têm todo o entendimento do
projeto. No desenvolvimento de software as necessidades de
mudanças são inevitáveis, portanto estabelecer todas as
decisões no início do desenvolvimento pode levar a falhas
graves no projeto ou até inviabilizá-lo.
A necessidade de buscar alternativas aos métodos pesados
em documentação como o modelo waterfall fez surgir os
chamados métodos leves como o scrum e o XP. Devido à
similaridade entre esses e outros métodos leves, em fevereiro
de 2001, um grupo de 17 pensadores e profissionais da área de
desenvolvimento de software decidiu se reunir para definir
uma base comum para todos esses métodos emergentes. O
primeiro resultado dessa reunião foi a definição do termo
“ágil” para caracterizar estes métodos. Outra iniciativa foi a
fundação da Aliança Ágil uma organização sem fins lucrativos
para a disseminação de processos de desenvolvimento ágeis
(http://www.agilealliance.org).
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
6
Figura 1 – Modelo Waterfall
adaptada de Boehm (1988)
Também foi elaborado o Manifesto Ágil que estabelece os
principais valores por trás do desenvolvimento de software
ágil. Os quatro valores fundamentais são:
Indivíduos e interações são mais importantes que
processos e ferramentas;
Software funcionando é mais importante que
documentação compreensiva;
Colaboração com o cliente é mais importante que
negociação contratual;
Responder a mudanças é mais importante que seguir
um plano.
Balizado nesses valores os autores propuseram um
conjunto de princípios para promover a agilidade no
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
7
desenvolvimento de software que pode ser resumidos em:
motivar e delegar aos desenvolvedores, confiar na excelência
técnica e em design simples, e criar valor ao negócio através
de entregas do software funcionado em pequenos intervalos de
tempo (DINGSØYR et al., 2012).
Tais princípios estimulam práticas de manter times auto-
organizados com poder de decisão e de criação. O processo
também permite acomodar mudanças ao longo do processo de
desenvolvimento mesmo que ocorram próximo de sua fase
final. Além disso, os clientes assumem um papel fundamental
no desenvolvimento, sendo convidados a participar do
processo constantemente através de feedbacks para que o
resultado seja capaz de satisfazer melhor suas expectativas.
Um dos métodos ágeis mais usados e conhecidos é o
Scrum, introduzido por Schwaber e Beedle (2002) no livro
“Agile software development with Scrum”. Esse é um método
de fácil entendimento, portanto ideal para entender melhor a
aplicação dos princípios publicados no Manifesto.
A palavra Scrum vem de uma situação que ocorre
frequentemente numa partida de rugby, quando cada equipe
forma um bloco de jogadores para confrontar o bloco da outra
no momento da reposição da bola em jogo após uma
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
8
interrupção. A ideia é associar o trabalho em equipe à força no
desenvolvimento de software. Além do time de
desenvolvedores o Scrum apresenta mais duas figuras
importantes, quais sejam: o dono do produto, geralmente
representado pelo cliente ou um representante do mesmo; e o
scrum master, que é o contato direto com o dono do produto e
o coordenador da equipe.
O princípio do método é dividir os requisitos do cliente em
pequenas partes que possam ser operacionalizadas em pouco
tempo para que o cliente receba um software que funcione em
um curto espaço de tempo. Pelos métodos antigos o software
só seria entregue quando todas as características estivessem
completas.
A Figura 2 representa processo típico de Scrum. Os
requisitos são representados por uma pilha chamada de
backlog, ou seja, uma lista de requisitos do cliente, os
requisitos são chamados de user stories (estórias do usuário).
O primeiro trabalho é priorizar esses requisitos de forma que
as principais características sejam completadas primeiro,
assim o cliente pode começar a usar e ter ganho com o
software. Cada conjunto de requisitos deve ser desenvolvido
dentro de um ciclo com prazo pré-definido, esses ciclos são
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
9
chamados de sprints. Um sprint dura, normalmente, entre duas
e quatro semanas sendo que ao final, um produto ou uma
melhoria do produto é entregue ao cliente. O processo se
repete até que o cliente esteja satisfeito.
Outro ponto importante são as reuniões diárias em que são
discutidas as atividades de cada membro da equipe, incluindo
o que foi feito no dia anterior e o que será feito no dia. As
reuniões também são oportunidades valiosas para discutir
pontos de bloqueio ou dificuldades permitindo que
diariamente correções sejam feitas.
Com a adoção desse método, é possível verificar que o
cliente consegue receber rapidamente o produto e participar da
sua melhoria, que desenvolvimentos de características
desnecessárias são evitados, e que se torna mais fácil
identificar e corrigir erros.
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
10
Figura 2 – Típico Método Scrum
adaptada de Schwaber e Beedle (2002)
2.2. Difusão da abordagem Lean: da manufatura ao desenvolvimento de
software
Para competir com os fabricantes de carros americanos, em meados da década de 1940,
a Toyota começou a desenvolver um sistema de produção que a permitiu crescer solidamente
valendo-se de uma contínua melhoria de seu desempenho competitivo. Este sistema,
conhecido como “Sistema de Produção Toyota” (TPS), tem como um de seus principais
pilares o conceito e as técnicas de produção just-in-time (JIT). A ideia do JIT é que os bens e
serviços devem ser produzidos com qualidade, sem desperdícios e no momento exato que são
necessários. Produzir antes significa gerar estoque e produzir depois significa deixar o cliente
esperando (SLACK et al., 1997). Embora haja uma evidente associação do JIT com o TPS
que se tornou bastante popular, este sistema também se destaca pela ênfase que dedica à
racionalização e padronização de processos produtivos (HOPP; SPEARMAN, 2004).
Além disso, vale observar que filosofia gerencial na qual se baseia o TPS é tida como
tão importante quanto este sistema em si. De acordo com SLACK et. al (1997), as bases dessa
filosofia são: a eliminação de desperdícios, o envolvimento dos funcionários e a melhoria
contínua. Mais especificamente, a conceituação estabelecida pela Toyota de que os
desperdícios existentes na produção podem ser classificados em desperdícios por
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
11
superprodução, tempo de espera, transporte, processo (ou superprocessamento), estoque,
movimentação e defeitos, também se tornou célebre.
Tais conceitos se disseminaram pelo mundo na década de 1980, mas ainda muito
relacionadas com a particular experiência e cultura da Toyota. No decorrer da década de
1990, a abordagem do TPS passou a ser mais amplamente reconhecida com o nome de Lean
Manufacturing (HOPP; SPEARMAN, 2004). Para isso, foi notória a contribuição de Womack
e Jones (2003) que sintetizaram a essência do pensamento enxuto desta abordagem em 5
princípios da filosofia Lean, quais sejam:
Especificar o valor na perspectiva do cliente.
Identificar a cadeia de valor e remover as etapas que geram desperdícios
Fazer com que as etapas que criam valor fluam
Fazer com que a produção seja puxada pela demanda
Gerenciar para se buscar a perfeição através da melhoria contínua.
Em 2003, quando as práticas lean já estavam sendo bastante disseminadas nas indústrias
de manufatura, Mary e Tom Poppendieck publicaram o livro “Lean Software Development:
An Agile Toolkit” relacionando as práticas de desenvolvimento de software ágil com os
princípios e práticas de lean manufacturing.
É importante diferenciar principios e práticas lean. Os principios são ideias e reflexões
guias sobre um determinado assunto, enquanto as práticas são as ações realizadas para
concretizar a aplicação dos principios (POPPENDIECK; POPPENDIECK, 2003).
Para Poppendieck e Poppendieck (2003), os princípios lean podem ser convertidos em
práticas de desenvolvimento ágil. Nesse livro, cada capítulo é dedicado à discussão de um
princípio lean com as devidas adaptações ao contexto de desenvolvimento de software,
incluindo as práticas ou ferramentas que lhe dão forma.
Mais tarde os princípios foram revisados (POPPENDIECK; CUSUMANO, 2012;
POPPENDIECK; POPPENDIECK, 2006) e foram apresentados conforme seguem:
Eliminar desperdícios – De forma análoga à classificação de desperdícios que podem
ser identificados no fluxo de valor em ambiente de manufatura, foram identificados
os sete desperdícios no desenvolvimento de software. O Quadro 1 relaciona os
desperdícios na manufatura com os desperdícios no desenvolvimento de software.
Aprender constantemente – Como o ambiente muda constantemente, é preciso evitar
tomadas de decisões precipitadas ou apressadas que podem causar desperdícios ou
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
12
fracassos. Postergar decisões dá a oportunidade de aprender mais para poder
selecionar as melhores ações. Desenvolver e fazer pequenas entregas em frequentes
ciclos com feedback permite oferecer ao cliente produtos que agregam mais valor.
Melhorar continuamente – Não importa quão bem certas práticas pareçam funcionar,
pois sempre é possível melhorar qualquer sistema de trabalho.
Entregar continuamente – Pensar no desenvolvimento de software não como um
grande e longo projeto, mas como um constante fluxo de pequenas mudanças ou
atualizações que são liberadas com rapidez e incrementadas de pouco em pouco.
Envolver todos – No desenvolvimento de software, o valor também é construído ao
longo de um fluxo que transcende os limites departamentais da TI e, portanto é
preciso engajar todas as funções organizacionais envolvidas da concepção à entrega.
Embutir qualidade – Desenvolver software em módulos que são integrados ao
sistema fim assim que são escritos é uma maneira de evitar problemas de qualidade.
Otimizar o todo – O valor do software começa do entendimento da necessidade do
cliente e não é gerado somente na fase de desenvolvimento.
Os princípios assim definidos foram pouco alterados por outros autores. Mas dada a
existência de um repertório mais amplo de conceitos gerenciais abarcado pela literatura sobre
aplicações da abordagem lean no contexto de manufatura, alguns autores da área de
desenvolvimento de software propuseram adaptar alguns destes elementos e caracterizá-los
como princípios que ajudam a promover o desenvolvimento de software lean. Alguns desses
princípios são enumerados a seguir: a gestão visual de qualidade (MIDDLETON, 2001), o
gerenciamento de fluxo (NIKITINA; KAJKO-MATTSSON; STRALE, 2012) e decisões
dirigidas por dados (LANE; FITZGERALD; AGERFALK, 2012).
Quadro 1 – Os sete desperdícios na manufatura e no desenvolvimento de software
adaptado de Hibbs et al. (2009)
Desperdícios na
manufatura
Desperdícios no
desenvolvimento de software Problemas
Defeitos Defeito Falta de testes automáticos.
Superprodução Características extras 80% da necessidade do cliente são atendidas por 20%
das características.
Transporte Entregar tarefa ao outro Falta de comunicação e entendimento entre os
processos.
Tempo de espera Atraso Espera por uma resposta.
Estoque Trabalho parcialmente
completo
Diversas tarefas realizadas em uma etapa do processo
que não passaram pelos demais processos.
Movimentação Troca de tarefas Deixar uma tarefa incompleta para começar outra leva
tempo diminuindo a produtividade.
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
13
Processo Processo desnecessário Processos que não agregam valor ao cliente.
Em relação às práticas, Poppendieck e Poppendieck (2003) listam vinte e duas práticas
lean que chamam de ferramentas a serem usadas no desenvolvimento de software. Hibbs et
al. (2009) resumem as práticas em cinco fundamentais, as quais são enumeradas a seguir:
Testes automáticos – eliminam desperdícios, agilizam a entrega e ajudam a embutir
qualidade.
Integração contínua – minimiza os erros, minimiza a complexidade da integração,
mais feedbacks, menor propagação de erros e menos estoque em processo ou WIP
(work-in-process).
Menos códigos – menor tempo de escrita, menos componentes e menos esforço de
integração, menos erros, mais fácil de assimilar, mais fácil de reagir às mudanças.
Deve-se priorizar os códigos mais importantes no início. É provável que após
algumas iterações o cliente entenda que o software já está bom e que muitos
requisitos se tornem desnecessários. Na priorização dos requisitos é importante
considerar cada um individualmente em relação ao quanto agregam valor ao cliente.
Também se recomenda o reuso de códigos.
Iterações curtas – prática que elimina desperdícios, facilita entrega rápida, promove
feedback e cria valor ao cliente. Elimina a lacuna entre a interpretação do
desenvolvedor e a necessidade do cliente, além de manter a flexibilidade necessária
para mudanças nos planos dos clientes. Deve-se tomar cuidado para não confundir
com a realização de uma sucessão de pequenas “cascatas”.
Participação do cliente – é importante que haja participação de um representante do
cliente com conhecimento técnico e organizacional em atividades de
desenvolvimento como seleção de estórias e fornecimento de feedback sobre a
funcionalidade do software.
Muitas outras práticas podem ser atribuídas ao desenvolvimento de software lean, o
Quadro 2 lista algumas dessas práticas encontradas na literatura.
2.3. Abordagem lean no desenvolvimento de software ágil
Para Poppendieck e Poppendieck (2003, 2006) a
associação do termo lean ao desenvolvimento de software
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
14
servia para expressar a ideia de que os princípios lean
forneciam as premissas teóricas que estavam por trás do
desenvolvimento ágil e de que as práticas lean possibilitariam
reforçar as práticas de desenvolvimento ágil ou ampliá-las.
Quadro 2 – Práticas de desenvolvimento de software lean
Práticas Lean Poppendieck; Poppendieck,
2003
Cook et al., 2004
Middleton; Flaxel;
Cookson, 2005
Hibbs; Jewett; Sullivan,
2009
Petersen; Wohlin,
2010
Middleton; Joyce,
2012
Identificar desperdícios
Value Stream Mapping (VSM)
Teoria das restrições (TOC)
Teoria das filas
Feedback
Iterações curtas
Desenvolvimento com o cliente
Manter mais opções
Adiar tomada de decisões.
Sistema puxado / kanban
Delegar responsabilidade ao time
Kaizen / Melhoria continua
Testes automáticos
Realizar medições / Coletar dados.
Integração contínua
Seleção de requisitos
Manter distancia curta entre os
colaboradores
Educar desenvolvedores / Times
multifuncionais
Parar para resolver problemas
Gestão visual
Padronizar os processos
Com o tempo novos autores passaram a explorar a ideia de
tornar a forma de planejar e conduzir o processo de
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
15
desenvolvimento de software lean e certas divergências
ficaram evidentes quanto à maneira de fazer isso no contexto
do desenvolvimento ágil. Dyba e Dyngsoyr (2009) tratam a
metodologia lean como uma metodologia ágil, sem
diferenciação alguma. Por outro lado, alguns autores fazem
clara diferenciação entre os métodos. Middleton e Joyce
(2012), por exemplo, apontam que existem diferenças entre o
método ágil scrum e os métodos lean como as seguintes:
Push x Pull – o scrum, devido aos prazos de término dos sprints, é um método em
que a produção é empurrada (push), enquanto no método kanban ela é puxada (pull).
Uso dos dados – no scrum os dados são mais explorados como um meio de controle
de gerenciamento, as reuniões diárias são mais focadas nas pessoas do que no
trabalho, já nos times lean cada um usa os dados do trabalho para melhorá-lo e os
dados são direcionadores do trabalho. Por exemplo, são usados os painéis do método
kanban para identificar problemas.
Melhoria contínua – o scrum foca a medição do número de estórias entregues por
iterações (medir velocidade) e não se apoia no controle estatístico de processo. A
abordagem lean foca o lead time e promove a identificação de bloqueios e sua
eliminação.
Multi habilidades / Colaboração – no scrum a lista de impedimentos gerenciada pelo
scrum master é uma maneira difusa de lidar com os impedimentos. A abordagem
lean usa o fluxo para identificar os gargalos e faz com que estes sejam enfrentados
como uma equipe.
Hibbs et al. (2009) advogam que o escopo da abordagem
lean é muito mais amplo, sendo o desenvolvimento ágil válido
apenas para uma parte do desenvolvimento lean.
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
16
É também comum que o desenvolvimento lean seja
tratado como uma melhoria ao desenvolvimento ágil. Autores
como Hiranabe (2008) vão além dizendo que a abordagem
lean representa a evolução da abordagem de desenvolvimento
ágil, ou seja, que os métodos ágeis serão substituídos por
métodos lean de desenvolvimento de software. Numa linha de
argumentação semelhante, Petersen (2010) afirma que as
práticas ágeis podem ser melhoradas por práticas lean. Já
Nikitina et al. (2012) consideram, mais especificamente, a
alternativa de combinar os métodos scrum e kanban para criar
um novo método denominado “scrumban”.
Vilkki (2010) considera que os métodos ágeis fornecem
um bom meio de melhorar o desenvolvimento de software,
mas que não seriam suficientes para promover uma melhoria
mais incisiva na maneira em que a empresa como um todo
funciona ou para assegurar benefícios significativos ao
negócio.
Wang et al. (2012) examinaram 30 trabalhos publicados
em conferências de desenvolvimento ágil que reportam
experiências do uso de práticas e princípios lean. Este estudo
identificou seis modos de aplicação da abordagem lean em
iniciativas de busca de maior agilidade no desenvolvimento de
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
17
software, mostrando que eles variam de acordo com o
propósito. O Quadro 3 lista os seis modos básicos de
aplicação. Nesse estudo ficou claro que é mais comum
observar casos de empresas em que o desenvolvimento de
software se baseia na abordagem ágil, mas que para a melhoria
contínua dos processos recorrem à aplicação dos princípios e
práticas lean.
Quadro 3 – Modos de aplicação da abordagem lean no desenvolvimento de software ágil
adaptado de Wang et al. (2012)
Modos de aplicação da abordagem Lean no processo de desenvolvimento ágil Casos
A: Combinação não intencional de Ágil e Lean em processos de desenvolvimento de software
Uso tanto de práticas lean, como de práticas ágeis sem clara distinção da abordagem assumida.
1
B: Ágil dentro, Lean para fora
Uso da abordagem lean para interagir com agentes externos ao ambiente de desenvolvimento (e.g.
olhar para a necessidade do cliente com pensamento lean para entender como entregar o que o
cliente precisa) enquanto, internamente, se mantém o processo de desenvolvimento ágil.
5
C: Lean facilitando a adoção de Ágil
A aplicação de conceitos, princípios e práticas lean pode facilitar o processo de transição de uma
organização para a adoção de preceitos da mentalidade e comportamento ágeis.
6
D: Lean dentro de Ágil
Inserir o uso de elementos lean para direcionar e conduzir iniciativas de melhoria contínua em
processos de desenvolvimento mantendo a abordagem ágil como plataforma
13
E: De Ágil para Lean
Aplicação compreensiva de elementos da abordagem lean para aprimorar os processos de
desenvolvimento ágil, o que pode culminar com a abordagem lean tornando-se a dominante.
4
F: Sincronizando Ágil e Lean
Times que aplicam métodos ágeis trabalham em paralelo e de forma sincronizada com times que
aplicam métodos lean para tratar de diferentes aspectos de um mesmo processo em desenvolvimento
1
3. MÉTODO DE PESQUISA
O método utilizado para o desenvolvimento desse trabalho foi o estudo de caso simples.
Um estudo de caso é uma investigação empírica de um fenômeno contemporâneo no contexto
da vida real (YIN, 2008). O desenvolvimento de um estudo de caso simples, mas focado,
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
18
possibilita analisar de maneira aprofundada o fenômeno objeto de estudo o que permite sua
descrição detalhada e seu entendimento no contexto da realidade em que está inserido.
A unidade de análise considerada é o departamento de projetos e desenvolvimento de TI
de uma das principais editoras do Brasil, que é líder de mercado em muitos segmentos onde
atua e parte de um dos maiores grupos de comunicação e educação da América Latina. A
empresa trabalha há 30 anos com desenvolvimento de software e atualmente o departamento é
responsável por grande parte do faturamento já que a prática de assinaturas de revista via web
está cada vez mais comum. Dentre suas atividades, vale destacar os projetos de portais de
internet, hotsites, serviços web e sistemas baseados em browsers. Os principais clientes são o
departamento de assinaturas da editora e o website de venda de revistas digitais do próprio
grupo.
Há cerca de quatro anos o departamento adotou o método ágil Scrum e hoje realiza em
média 4 sprints por mês com cerca de 20 estórias cada, com uma equipe de 35 pessoas. O
organograma é composto por um gerente geral, três gerentes de desenvolvimento, dois
arquitetos de sistemas, dois analistas de qualidade e vinte e sete desenvolvedores.
A coleta de dados foi realizada através de visita ao local para a observação de suas
atividades pelo pesquisador e realização de entrevistas semiestruturadas com o gerente do
departamento e alguns membros da equipe de desenvolvimento. Também foram realizadas
consultas ao gerente do departamento por contato telefônico e por correio eletrônico para a
elucidação de questões complementares. Por motivos de confidencialidade, neste trabalho
será adotado o nome fictício de EDBrasil para se referir à empresa.
4. O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE DA
EDBRASIL
O processo de desenvolvimento de software no departamento de TI da EDBrasil se
inicia com uma reunião de negócios para a concepção de estórias em que participam o cliente
na figura do product owner (PO), além do gerente geral, do gerente de desenvolvimento e do
scrum master (SM). Após esta etapa, as estórias são inseridas pelo cliente (PO) e pelo SM em
um software de gerenciamento do processo de desenvolvimento pelo método Scrum. Então é
realizada uma reunião de planejamento para priorizar as estórias que serão tratadas e a equipe
parte para o processo de desenvolvimento das estórias num sprint, que é acompanhado pelo
PO e SM. As estórias desenvolvidas são testadas e ao concluir-se a homologação de todas
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
19
elas, a entrega do sprint é aceita pelo PO e SM. Em seguida o SM e o arquiteto de sistemas da
equipe programam a implantação/produção. Após a implantação, é realizada uma reunião de
encerramento do sprint com a participação do SM e todos os membros da equipe.
Cada equipe realiza reuniões diárias para verificar o andamento de suas atividades.
Nestas reuniões, cada membro da equipe reporta a situação das atividades do dia anterior e as
atividades a serem realizadas no dia. Em geral, em cada sprint, a equipe é composta por
quatro desenvolvedores, dois analistas de qualidade e um arquiteto, que trabalham com um
bom nível de autonomia tomando a maioria das decisões em sua alçada. Cada pessoa participa
de um sprint por vez, porém pode haver uma pequena sobreposição entre as etapas de
implantação do sprint anterior e o desenvolvimento do próximo. Nestes casos, o SM, o
arquiteto e os analistas de qualidade podem estar momentaneamente atuando em dois sprints.
A quantidade de estórias, definidas durante o processo de planejamento, segue de
acordo com a capacidade da equipe. Caso novas estórias sejam inseridas, o processo segue a
programação do sprint em curso, porém existe a possibilidade de remoção de outra estória
para que o prazo seja mantido. Para definição da capacidade de cada recurso, a gerência
considera a quantidade de horas disponíveis do recurso subtraído de vinte por cento. Esse
subdimensionamento visa reservar uma folga para absorver possíveis novas estórias que
venham a ser inseridas no sprint durante o processo por necessidade do cliente.
Figura 3 – Representação adaptada do quadro virtual de kanban de um sprint
na empresa EDBrasil
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
20
O controle do fluxo do processo é realizado pelo software de gerenciamento que exibe
um painel chamado de quadro kanban que informa o status em que se encontra o tratamento
de cada estória, considerando que deve avançar na seguinte ordem: defined, in-progress,
completed, e accepted (definidas, em processo, completas e aceitas). Todas as pessoas da
equipe podem visualizar o quadro a qualquer momento. A Figura 3 mostra uma ilustração do
quadro kanban sobre o qual as estórias são representadas por cartões que contêm informações
chave como uma descrição da estória, o responsável (owner) e o número de tarefas cumpridas
no seu desenvolvimento. Nas colunas “em processo” e “completas”, é também apontado o
tempo de permanência acumulado (medido em dias) de cada estória.
Um quadro físico também é utilizado no departamento para o controle visual de cada
sprint. Esse quadro físico é uma simplificação do quadro apresentado pelo software excluindo
a coluna das estórias aceitas, ou seja, nele são postadas as tarefas a fazer (to do), em execução
(doing) e feitas (done).
Sempre que houver impedimentos dificultando o processo de desenvolvimento, as
estórias afetadas são marcadas em vermelho para que toda a equipe visualize no quadro.
Como o desenvolvimento dessas estórias pode ficar bloqueado e interromper o fluxo de
trabalho, é preciso dedicar grande atenção ao tratamento de impedimentos. Se o problema
estiver relacionado ao sistema ou à tecnologia, toda a equipe pode ajudar na solução de forma
autônoma, no entanto, se a solução requer a negociação com o cliente é necessária a
intervenção do SM.
Durante o processo, testes automáticos, unitários e de navegação, são realizados.
Sempre que um problema é identificado, a continuidade é interrompida até que o erro seja
corrigido. Os analistas de qualidade são responsáveis pelos testes finais, incluindo os testes de
integração que são realizados na fase de implantação do software. Alguns defeitos podem ser
encontrados após o encerramento do sprint, com o produto já lançado, nesse caso é aberta
uma notificação de defeito, como se fosse uma nova estória, que é priorizado no sprint em
execução.
Todos os sprints são monitorados em tempo real com a ajuda dos relatórios fornecidos
pelo software de gerenciamento. Dentre os muitos indicadores apontados, os mais usados
pelas equipes são: número de estórias incompletas no sprint atual, número de estórias
completas a serem aceitas, a quantidade de estórias a serem completadas por sprint (mostrada
num gráfico chamado burndown chart atualizado diariamente), e o número de defeitos por
sprint. Fica a cargo do gerente geral realizar uma análise consolidada das equipes. Para isso,
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
21
além dos indicadores por projeto, são monitorados indicadores gerais, como a quantidade de
defeitos e o tempo de correção, que são medidos, analisados e tomados como base no
delineamento de planos e metas de melhoria. Os atrasos são tratados de forma análoga tanto
no âmbito de um sprint conduzido por uma equipe como no âmbito geral do departamento.
O processo de desenvolvimento encerra-se com a etapa de implantação. Assim que as
estórias do sprint sejam aceitas, é necessário finalmente avançar a etapa formal de “promoção
à produção”. Esta etapa do processo depende da disponibilidade de capacidade para colocar o
sistema em produção e pode gerar atrasos que vão de um a vários dias. Embora esta etapa
esteja fora do escopo do método scrum, existe uma discussão em andamento sobre a
possibilidade desse processo ser também ser revisto para que fique melhor alinhado aos
princípios de desenvolvimento ágil.
5. ANÁLISE DO CASO
A observação e análise do processo de desenvolvimento de software ágil na EDBrasil
revelou a existência de um grande conjunto de práticas que consubstanciam a aplicação da
abordagem ágil. Parte significativa de tais práticas é consonante com a abordagem de
desenvolvimento lean e pode ser relacionada com práticas lean enumeradas no Quadro 2. Por
outro lado, constatou-se que certas práticas adotadas com o pretexto de incutir maior agilidade
no processo de desenvolvimento, divergem dos princípios de desenvolvimento lean.
O Quadro 5 lista as principais práticas lean identificadas no caso estudado relacionando-
as com o princípio lean que ajuda a sustentar.
Quadro 5 – Princípios e práticas lean adotados no processo de desenvolvimento de software da
empresa EDBrasil
Princípios lean Práticas lean
Eliminar desperdícios Testes automáticos
Menos códigos
Uso de software de gerenciamento
Reconhecimento de desperdícios
Aprender constantemente Adiar tomada de decisões, para aprender mais e tomar decisões mais corretas
Entregar continuamente Iterações curtas
Padronização de processos
Gestão visual do fluxo
Times multifuncionais para enfrentar gargalos
Embutir qualidade Testes automáticos
Parar para resolver problemas de qualidade
Melhorar continuamente Medições e coleta de dados
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
22
Ciclo PDCA
Envolver todos Participação ativa do cliente
Colaboração das pessoas envolvidas na resolução de impedimentos
Otimizar o todo (não identificada)
No processo de desenvolvimento da EDBrasil foi possível perceber que a equipe
entende a conceituação dos sete desperdícios do processo tal como definidos por Hibbs et al.
(2009), e sabe reconhecê-los quando existentes no processo evidenciando um aspecto
primário da mentalidade lean. Consonante com o princípio de eliminação de desperdícios, a
gerência demonstra forte preocupação com a redução de defeitos e os atrasos causados por
eles. A automatização da maioria dos testes é uma prática lean fundamental para eliminar tais
desperdícios. Nas reuniões de planejamento as características necessárias são bem discutidas
com o cliente e com a equipe para que menos códigos sejam necessários diminuindo a
complexidade e o desperdício de tempo de desenvolvimento. O uso de um software para o
gerenciamento dos desenvolvimentos tem contribuído para minimizar a distância entre os
processos e os problemas de comunicação. Vale salientar que empresa admite conviver com
certas situações como a realização de testes finais e a espera de condições para poder
implantar sistemas concluídos, que são reconhecidas como não agregadoras de valor ao
cliente e que poderiam ser eliminadas ou reduzidas.
Na condução do desenvolvimento, decisões sobre pontos relevantes ainda indefinidos
que requerem um claro entendimento, são adiadas para que a equipe possa aprender mais
sobre os mesmos a fim de buscar e selecionar as melhores alternativas de ação.
Em relação ao fluxo do processo de desenvolvimento, percebe-se que é direcionado
pelo objetivo de incorporar um grupo de estórias a serem tratadas numa sucessão de iterações
curtas que são conduzidas de uma forma padronizada em tempos bem definidos (sprints)
sendo que a integração de todas elas ao software é conduzida de uma vez somente ao final de
um ciclo deste processo. O quadro kanban tem sido usado como um instrumento bastante
prático de gerenciamento visual do fluxo do processo. Quando surgem gargalos no fluxo do
processo, alguns arquitetos ou analistas de qualidade podem assumir outras funções dentro e
fora do seu sprint e esta multifuncionalidade tem facilitado o ajuste da capacidade da equipe
embora necessite ser ainda aprimorada.
Como práticas que promovem o princípio de embutir a qualidade ao produto, são
adotados os testes automáticos e o método de parar o trabalho cada vez que ocorre um erro
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
23
para focar na sua resolução. No entanto, algumas falhas continuam sendo detectadas após a
implantação do sistema atrasando processos interno e do cliente.
No que tange a melhoria contínua, o uso do software de gerenciamento ajuda a manter
os dados referentes ao andamento dos projetos do departamento que são medidos e coletados
sistematicamente, e como toda a equipe tem acesso aos relatórios de desempenho, isso
assegura ampla visibilidade às oportunidades de melhoria. O método utilizado para a melhoria
contínua é o do ciclo PDCA (plan, do, check, act). No estudo foi possível verificar que
algumas iniciativas de melhoria contínua, são realizadas para melhorar o todo, ou seja,
desvinculadas de projetos específicos, contribuindo para aprimorar estruturalmente as bases
do processo de desenvolvimento ágil.
Em relação ao princípio de buscar o envolvimento de todos, já está consagrada a prática
de envolver os clientes de modo que eles tenham ativa participação no processo de
desenvolvimento. Além disso, tem sido estimulada maior colaboração entre as pessoas
envolvidas na resolução de impedimentos.
Embora as evidências mencionadas no Quadro 5 indiquem que a EDBrasil tenha
avançado firmemente na assimilação da mentalidade de desenvolvimento ágil, apoiando-se no
uso de conceitos e práticas lean, a gerência admite que será necessário envolver mais os
processos que se situam fora no escopo de aplicação dos métodos de desenvolvimento ágil
para poder avançar mais no aperfeiçoamento do todo. Ficou evidente que existe um
descompasso com os demais sistemas de produção da organização que operam
independentemente dos processos de desenvolvimento gerando atrasos na implantação. Esse é
um dos temas de melhoria que está sendo tratado atualmente.
Quadro 6 – Práticas não consonantes com a abordagem lean no processo de desenvolvimento de
software da empresa EDBrasil
Práticas não lean
Troca de tarefas causadas pela inserção de novas estórias não planejadas
Ausência da noção e visão do fluxo de valor
Desenvolver estórias em lotes e integrá-las somente ao final do sprint
Sistema empurrado para programação e controle do fluxo de trabalho
Kanban não é usado para balancear o fluxo e controlar WIP
Não usa análise estatística
A análise das práticas adotadas nas quais o processo de desenvolvimento ágil tem se
apoiado revelou que também são aplicadas práticas que não são consonantes com os
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
24
princípios lean. Algumas das principais práticas de desenvolvimento ágil que divergem da
abordagem lean são apresentadas a seguir e se encontram sintetizadas no Quadro 6.
O método de admitir que uma nova estória seja inserida no decorrer de um sprint sem
ter sido planejada favorece a agilidade, mas as trocas de tarefas causadas prejudicam o
desempenho da equipe e constituem desperdícios.
No que tange à programação e controle do fluxo dos trabalhos, a lógica do método ágil
contrasta com a do método lean, já que a primeira é empurrada (push) e a do lean é puxada
(pull). Além disso, no caso estudado o kanban não é usado para controlar o estoque de
trabalho em processo (WIP), balancear o fluxo e visualizar gargalos, servindo basicamente
como uma ferramenta de controle visual do fluxo de desenvolvimento das estórias. Em
relação à prática de dividir todo o desenvolvimento de um projeto em pequenos lotes de
estórias e de programar o tratamento de cada lote a um sprint ajuda a viabilizar a ideia da
abordagem ágil de fazer pequenas entregas gradualmente. Contudo, a lógica de programar o
tratamento de um certo número de estórias a um sprint e de integrar ao software o lote de
características homologadas somente ao final do sprint não é consonante com o princípio de
construir um fluxo contínuo e também pode provocar ociosidade de recursos que concluem
suas tarefas antes. Segundo a abordagem lean, o ideal seria buscar o one-piece-flow, ou seja,
ir desenvolvendo e entregando as estórias unitariamente.
Embora enfatizado por proponentes da abordagem lean, também não se observou maior
cuidado com a visualização do fluxo de valor pela aplicação de técnicas como mapeamento
do fluxo de valor, nem com o controle de variação e análise de dados por meio de métodos
estatísticos.
6. CONCLUSÕES
A tendência de evolução dos métodos de desenvolvimento de software nos últimos anos
tem atraído a atenção tanto de acadêmicos quanto de praticantes. Especificamente, as relações
entre os métodos ágeis e lean é um tema sobre o qual ainda há visões e posições muito
divergentes e um reflexo disso é o fato de não encontrarmos na literatura uma direção clara
para a conceituação e disseminação da simbiose entre as abordagens lean e ágil. O objetivo
deste estudo foi de buscar um melhor entendimento sobre os diferentes modos de
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
25
aproveitamento da abordagem lean na área de software, com base numa revisão da literatura e
à luz de dados empíricos obtidos por meio de um estudo de caso.
O estudo da experiência da empresa EDBrasil na promoção da agilidade no
desenvolvimento de software, possibilitou observar que, em certos aspectos, as abordagens de
desenvolvimento ágil e lean se sobrepõem e são de difícil diferenciação. De fato, nesse estudo
de caso foi possível perceber que, muitas vezes, a equipe confunde o escopo das abordagens
lean e ágil. Muitos conceitos como o de qualidade embutida e eliminar desperdícios são
entendidos como princípios ágeis. Também se observou que a lógica ou os métodos
preconizados por estas duas abordagens, em certas circunstâncias, podem ser até antagônicos,
o que suscita o debate sobre a melhor forma de buscar a combinação de tais elementos para
fomentar a agilidade no processo de desenvolvimento de software no contexto atual.
Tomando como base a classificação dos modos de aplicação de princípios e práticas
lean no processo de desenvolvimento ágil apresentada no Quadro 3, foi constatado que o caso
de desenvolvimento de software da empresa EDBrasil se enquadra como o de uma
organização que está recorrendo ao uso de diversas práticas lean para conduzir os processos
de desenvolvimento de uma forma mais ágil (Lean dentro de Ágil), assim como na maioria
das experiências de empresas analisadas por Wang et al. (2012).
Outra observação interessante é que naturalmente a equipe percebe a necessidade de
introduzir novas práticas lean para melhorar os processos ágeis, como nos casos de usar
métodos estatísticos para melhorar as análises de dados e a ampliação do escopo ágil para
incluir o processo seguinte.
Uma das limitações desse estudo é ter estudado apenas um caso em um segmento
específico. Outras empresas brasileiras de desenvolvimento de software com uma gama maior
de produtos podem ser objetos de futuros estudos e devem contribuir muito com o
desenvolvimento do tema.
REFERÊNCIAS
AGILE MANIFESTO. Manifesto for Agile Software Development. Disponível em:
<http://agilemanifesto.org/>. Acesso em: 19 out. 2012.
BECK, K. Embracing change with extreme programming. Computer, v. 32, n. 10, p. 70-77, 1999.
BOEHM, B. A spiral model of software development and enhancement. Computer, 1988.
COOK, J. et al. Lean Object-Oriented Software Development. SAM Advanced Management
Journal, v. 69, n. 2, p. 435-474, 2004.
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
26
DINGSØYR, T. et al. A decade of agile methodologies: Towards explaining agile software
development. Journal of Systems and Software, v. 85, n. 6, p. 1213-1221, jun. 2012.
DYBA, T.; DINGSOYR, T. What Do We Know about Agile Software Development? IEEE
Software, v. 26, n. 5, p. 6-9, set. 2009.
HIBBS, C.; JEWETT, S.; SULLIVAN, M. The Art of Lean Software Development. Sebastopol:
O’Reilly Media, 2009.
HIRANABE, K. Kanban Applied to Software Development: from Agile to Lean. Disponível em:
<http://www.infoq.com/articles/hiranabe-lean-agile-kanban>.
HOPP, W. J.; SPEARMAN, M. L. To Pull or Not to Pull: What Is the Question? Manufacturing
Service Operations Management, v. 6, n. 2, p. 133-148, mar. 2004.
LANE, M.; FITZGERALD, B.; AGERFALK, P. Identifying lean software development values. 2012.
MIDDLETON, P. Lean software development: two case studies. Software Quality Journal, p. 241-
252, 2001.
MIDDLETON, P.; FLAXEL, A.; COOKSON, A. Lean Software Management Case Study:
Timberline Inc. In: BAUMEISTER, H.; MARCHESI, M.; HOLCOMBE, M. (Eds.). Extreme
Programming and Agile Processes in Software Engineering. [S.l.] Springer Berlin
Heidelberg, 2005. v. 3556p. 1-9.
MIDDLETON, P.; JOYCE, D. Lean Software Management: BBC Worldwide Case Study. IEEE
Transactions on Engineering Management, v. 59, n. 1, p. 20-32, fev. 2012.
NIKITINA, N.; KAJKO-MATTSSON, M.; STRALE, M. From scrum to scrumban: A case study of a
process transition. 2012 International Conference on Software and System Process (ICSSP),
p. 140-149, jun. 2012.
PETERSEN, K.; WOHLIN, C. Measuring the flow in lean software development. Software: Practice
and Experience, n. April 2010, p. 975-996, 2010.
POPPENDIECK, M.; CUSUMANO, M. Lean Software Development: A Tutorial. Software, IEEE,
p. 26-32, 2012.
POPPENDIECK, M.; POPPENDIECK, T. Lean Software Development: An Agile Toolkit. [S.l.]
Addison-Wesley Professional, 2003. p. 203
POPPENDIECK, M.; POPPENDIECK, T. Implementing Lean Software Development: From
Concept to Cash. [S.l.] Addison-Wesley Professional, 2006.
SCHWABER, K.; BEEDLE, M. Agile software development with Scrum. Upper Saddle River, NJ:
Prentice-Hall, 2002.
SLACK, N. et al. Administração da Produção. São Paulo: Atlas, 1997.
THE STANDISH GROUP INTERNATIONAL INC. Chaos. Technical ReportThe Standish Group
International Inc, , 1994.
IX CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 20, 21 e 22 de junho de 2013
27
VILKKI, K. When Agile Is Not Enough. In: ABRAHAMSSON, P.; OZA, N. (Eds.). Lean Enterprise
Software and Systems. [S.l.] Springer Berlin Heidelberg, 2010. v. 65p. 44-47.
WANG, X.; CONBOY, K.; CAWLEY, O. “Leagile” software development: An experience report
analysis of the application of lean approaches in agile software development. Journal of
Systems and Software, v. 85, n. 6, p. 1287-1299, jun. 2012.
WOMACK, J. P.; JONES, D. T. Lean Thinking: Banish Waste and Create Wealth in Your
Corporation, Revised and Updated. [S.l.] Simon and Schuster, 2003.
YIN, R. K. Case Study Research: Design and Methods. 2nd. ed. Thousand Oaks, CA: Sage
Publications, 2008.