ABORDAGEM LEAN NO DESENVOLVIMENTO DE SOFTWARE ÁGIL: UM ESTUDO DE … · IX CONGRESSO NACIONAL DE...

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


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


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


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


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


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


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


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.


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


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


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.


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


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


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.


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


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,


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


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


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,


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


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


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


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


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.


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.


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.

ABORDAGEM LEAN NO DESENVOLVIMENTO DE SOFTWARE ÁGIL: UM ESTUDO DE … · IX CONGRESSO NACIONAL DE...

Documents

Transcript of ABORDAGEM LEAN NO DESENVOLVIMENTO DE SOFTWARE ÁGIL: UM ESTUDO DE … · IX CONGRESSO NACIONAL DE...