See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/266169136

Desenvolvimento lean de software: estudo de caso em uma empresa de

Article · July 2013

DOI: 10.14521/P2237-5163.2013.0003.0003

CITATIONS READS

0 141

2 authors:

Ivan Bosnic Mehran Misaghi

2 PUBLICATIONS   3 CITATIONS    Sociedade Educacional de Santa Catarina (SOCIESC)
73 PUBLICATIONS   20 CITATIONS   
SEE PROFILE
SEE PROFILE

Some of the authors of this publication are also working on these related projects:

TeamWork View project

Redes Sociais na Internet View project

All content following this page was uploaded by Mehran Misaghi on 29 September 2014.

The user has requested enhancement of the downloaded file.

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

Desenvolvimento lean de software: estudo de caso em uma empresa de

porte médio no norte catarinense

Lean software development: a case study in a medium-sized company in northern

Santa Catarina

Ivan Bosnic (ivan.bosnic@neogrid.com, Instituto Superior Tupy/SOCIESC, Santa Catarina, Brasil)

• Rui Barbosa, 1431, APTO 402C, 89220-100, Costa e Silva. NeoGrid, Joinville, SC, Brasil
Mehran Misaghi (mehran@sociesc.org.br, Instituto Superior Tupy/SOCIESC, Santa Catarina, Brasil)

Resumo: Este artigo traz uma revisão bibliográfica cujo propósito é identificar as principais
características de desenvolvimento lean de software e as suas semelhanças e diferenças com
as metodologias ágeis. São apresentadas as metodologias de desenvolvimento de software
mais comuns, onde uma atenção maior foi dedicada ao desenvolvimento lean de software. Em
seguida é apresentado um estudo de caso conduzido em uma equipe de desenvolvimento de
software onde foram aplicados os conceitos lean dentro do processo atual, o qual era
baseado em metodologias ágeis. Constatou-se ao final deste trabalho que o indicador usado
pela equipe, percentual de tempo investido em melhorias e novas funcionalidades, teve um
aumento significativo, fazendo com que a equipe conseguisse agregar mais valor ao produto
desenvolvido, aumentando inclusive o nível de qualidade.
Palavras-chave: Lean; Metodologias ágeis; Scrum; Software

Abstract: This article presents a literature review whose purpose is to identify the key
characteristics of lean software development and its similarities and differences with agile
methodologies. The most common software development methodologies are explained, where
greater attention was devoted to the lean software development. A case study conducted in a
team of software developers is presented, where lean concepts were applied within the current
process, which was based on agile methodologies. It was found at the end of this work that the
indicator used by the team, percentage of time spent on improvements and new features, had a
significant increase, causing the team being able to add more value to the product, including
increasing the level of quality.
Keywords: Lean; Agile methodologies; Scrum; Software

1. Introdução
As sociedades modernas dependem cada dia mais de diversos tipos de programas
computacionais. Tais programas (softwares) gerenciam as nossas contas bancárias, controlam
o fornecimento de água e energia elétrica, monitoram a nossa saúde quando internados em

Recebido 27/08/2012; Aceito 14/12/2012 59

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

hospitais acuados por doenças, divertem-nos quando brincamos de jogos eletrônicos, e

fornecem tantos outros serviços críticos para a comunidade. Era de se esperar que, ao se tratar
de peças tão fundamentais para a nossa vida, os projetos de software estivessem em um nível
de sucesso bastante elevado.

No entanto, segundo Hibbs, Jewett e Sullivan (2009), a prática de desenvolvimento de

software tem sido atormentada com taxas de sucesso criticamente baixas durante décadas.
Enquanto isso, as demandas por serviços e produtos de informática não param de crescer e a
situação parece entrar em uma situação caótica, sem solução. O que tem trazido certo
otimismo é o surgimento de metodologias ágeis, as quais têm demonstrado que é possível
obter taxas de sucesso melhores. No trabalho de Bassi (2008) é observado que existe uma
tendência de melhoria na qualidade dos projetos, mas ainda assim a situação requer atenção,
porque o percentual de projetos que ultrapassam os custos ou o prazo continua quase tão
elevado quanto antes.

Hibbs, Jewett e Sullivan (2009) destacam ainda que as técnicas lean têm sido cada vez
mais aplicadas ao desenvolvimento de software. A ideologia e as técnicas lean às quais os
autores se referem são as mesmas utilizadas no Sistema Toyota de Produção e Sistema Toyota
de Desenvolvimento de Produto. Segundo Poppendieck e Poppendieck (2011), o primeiro
passo na implementação do desenvolvimento lean de software é compreender esses
princípios, porque o desenvolvimento de software é uma forma de desenvolvimento de
produto.

Aplicar os conceitos de lean manufacturing, usados há bastante tempo na indústria

tradicional e principalmente na automobilística, ao processo de desenvolvimento de software
é o desafio por trás do desenvolvimento lean de software. Mesmo que a sua definição não
imponha tal regra, quase sempre encontramos desenvolvimento lean de software interligado
com as metodologias ágeis. Isso se deve ao fato de vários conceitos serem compartilhados por
ambas as metodologias. Os métodos ágeis obtêm sucessos organizacionais ao focar na entrega
de valor e na diminuição de custos (SHORE; WARDEN, 2008).

Recebido 27/08/2012; Aceito 14/12/2012 60

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

Este trabalho traz um estudo de caso conduzido dentro de uma equipe de

desenvolvimento de software experiente e que tem utilizado as metodologias ágeis na última
década com bastante sucesso. Desde o início de 2012 a equipe tem investido na implantação
de conceitos lean dentro do seu processo de desenvolvimento de software, o que tem tido
reflexos positivos nos indicadores apresentados mensalmente à gerência da empresa.

2. Metodologias de desenvolvimento de software

Diversas divisões de metodologias de desenvolvimento de software podem ser

encontradas na literatura. O presente trabalho divide os tipos de desenvolvimento de software
em três grupos, conforme Petersen (2010), sendo eles: desenvolvimento de software dirigido a
planos, desenvolvimento ágil de software e desenvolvimento lean de software.

2.1 Desenvolvimento de software dirigido a planos

Como o próprio nome sugere, o desenvolvimento de software dirigido a planos está

focado em planejar tudo desde o início do projeto (PETERSEN, 2010). Para que esse
planejamento seja possível, esta abordagem se apoia em uma série de documentos (artefatos)
que são gerados na fase inicial do projeto e que acompanham o mesmo durante todo o seu
ciclo de vida.

Além disso, ao final de cada fase são produzidos alguns artefatos cuja função é
comprovar que a mesma foi finalizada. Somente então é que deve ser iniciado o trabalho da
próxima fase do processo.

2.1.1 Cascata

O modelo em cascata é um exemplo de um processo dirigido a planos

(SOMMERVILLE, 2011). Esse processo é executado de forma sequencial, segundo os passos
que representam as diferentes disciplinas de desenvolvimento de software (PETERSEN,
2010). A Figura 1 traz uma representação gráfica do modelo em cascata e de suas fases.

Recebido 27/08/2012; Aceito 14/12/2012 61

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

Figura 1 – O modelo em cascata

Fonte: Adaptação de Sommerville (2010)
O principal objetivo desta abordagem é prover uma estrutura para execução do
processo de desenvolvimento de software. No entanto, o processo não ocorre de forma linear,
mas sim envolve a realimentação de uma fase para outra (SOMMERVILLE, 2011).

Presman (2004) define ainda que em cada uma das fases é realizado um conjunto
predefinido de atividades. Essas atividades produzem artefatos que servem de entrada para a
atividade seguinte.

Para Pries e Quigley (2011), a principal vantagem do modelo em cascata, senão a

única, é ser de fácil entendimento. No entanto, essa facilidade de entendimento nem sempre
significa a facilidade de implementação.

2.1.2 RUP

Segundo Petersen (2010), outro exemplo de processo dirigido a planos é RUP

(Rational Unified Process). Este processo é mais flexível quando se trata da sequência em que
as disciplinas são executadas. Isso significa que as atividades de engenharia de software
definidas pelo processo são executadas durante todo o ciclo de vida do mesmo.

De acordo com Arked (2003), RUP é uma metodologia flexível para desenvolvimento
de projetos de software que promove uma abordagem iterativa, assim como um conjunto de
melhores práticas. Além da abordagem iterativa, o processo se apoia fortemente na gestão de

Recebido 27/08/2012; Aceito 14/12/2012 62

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

risco. A metodologia foi criada pela empresa Rational Software Corporation, uma divisão da
IBM desde 2003.

As práticas propostas por RUP são:

• desenvolvimento iterativo, onde o foco principal está no risco;

• gerenciamento de requisitos;

• adoção de uma arquitetura baseada em componentes;

• modelagem visual de software;

• verificação contínua de qualidade;

• controle de mudanças.

Segundo Arked (2003), RUP possui quatro fases: concepção, elaboração, construção e
transição. A Figura 2 ilustra as disciplinas e as fases que fazem parte do RUP.

De acordo com a Figura 2, é possível observar que todas as disciplinas de engenharia

de software propostas por RUP participam de quase todas as fases, porém com uma
intensidade diferenciada.

Figura 2: As fases do RUP e a distribuição do volume de atividades em cada uma delas

Recebido 27/08/2012; Aceito 14/12/2012 63

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

Fonte: Bassi (2008)

2.2 Desenvolvimento ágil de software

De acordo com Dyba e Dingsoyr (2008), o desenvolvimento ágil de software

representa o maior avanço na engenharia de software quando comparado às abordagens
dirigidas a planos.

Segundo Bassi (2010), a indústria de software se baseou, durante muito tempo, em

métodos tradicionais de desenvolvimento de software. Esses métodos vinham apresentando
um grande número de fracassos, o que levou alguns líderes experientes a adotarem modos de
trabalho que se opunham a esses conceitos.

No ano de 2001, esse grupo escreveu um documento chamado Manifesto for Agile
Software Development, cujo objetivo era identificar os valores que traziam mais benefícios
para o processo de desenvolvimento de software (SMITH; SIDKY, 2009). Esse documento
está disponível na Internet através do endereço http://agilemanifesto.org/. As quatro premissas
do manifesto são:

• indivíduos e iterações são mais importantes do que processos e ferramentas;

• software funcionando é mais importante do que documentação completa;

• colaboração com o cliente é mais importante do que negociação de contratos;

• adaptação a mudanças é mais importante do que seguir o plano inicial.

Os itens do lado esquerdo (destacados em negrito) são os que representam mais

importância para um processo ágil, porém os itens do lado direito não podem ser ignorados.
Ao contrário, eles devem ser levados em consideração e valorizados, sendo que o seu valor é
menor quando comparados com os itens do lado esquerdo (SMITH; SIDKY, 2009).

A partir das definições do manifesto, surgiram diversas metodologias de

desenvolvimento de software, entre as quais destacamos XP e Scrum.

Recebido 27/08/2012; Aceito 14/12/2012 64

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

2.2.1 XP

Segundo Sommerville (2011), Extreme Programming (XP) é um dos métodos ágeis

mais utilizados. Esta abordagem foi desenvolvida para levar em consideração as melhores
práticas de desenvolvimento de software, como o desenvolvimento iterativo. Segundo Smith e
Sidky (2009), em comparação com outras técnicas ágeis, XP é focado mais na aplicação de
conceitos técnicos. Ainda de acordo com os autores, não é possível definir uma técnica ágil
como sendo a melhor, tudo depende do que funciona melhor no ambiente da empresa e dentro
de suas restrições.

Uma das principais características de XP é o fato de os testes serem criados antes

mesmo de se escrever o código fonte na linguagem de programação. A codificação, por sua
vez, é feita em duplas, técnica chamada de pair programming.

2.2.2 Scrum

O método Scrum foi proposto em 1995 por Ken Schwaber (VLAANDEREN ET al.,
2010). Como todos os processos ágeis, Scrum é uma abordagem iterativa e incremental para
desenvolvimento de software (COHN, 2010). Desenvolvimento incremental subentende a
construção de um sistema pedaço por pedaço, ou seja, primeiro um pedaço é desenvolvido,
depois outro é adicionado a ele, e assim por diante.

A parte mais importante do Scrum é backlog do produto, isto é, uma lista com todos os
requisitos que devem ser implementados para que o software funcione da forma correta
(KNIBERG, 2007). Backlog é dinâmico e pode ser alterado e/ou priorizado conforme as
necessidades do cliente.

O desenvolvimento em si ocorre em iterações chamadas sprints e que normalmente

duram de uma a quatro semanas. Antes de iniciar uma sprint, a equipe se reúne, elenca os
requisitos que serão trabalhados (requisitos são escolhidos de acordo com as prioridades de
negócio estabelecidas) e depois esses itens são quebrados em tarefas de implementação de
menor complexidade (BASSI, 2008). A Figura 3 demonstra todo o ciclo de desenvolvimento
do Scrum.

Recebido 27/08/2012; Aceito 14/12/2012 65

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

Figura 3 – Ciclo de desenvolvimento do Scrum

Fonte: Adaptação de Bassi (2008)

2.3 Desenvolvimento lean de software

De acordo com Shore e Warden (2008), as ideias nas quais se baseia o

desenvolvimento lean de software têm a sua origem na manufatura enxuta e no
desenvolvimento lean de produto. Esses conceitos, por sua vez, tiveram as suas origens no
Sistema Toyota de Produção e no Sistema Toyota de Desenvolvimento de Produto.

Segundo Poppendieck e Poppendieck (2011), o desenvolvimento de software é uma

forma de desenvolvimento de produto. Foram os próprios autores que, em 2003, introduziram
pela primeira vez o conceito de desenvolvimento lean de software. O seu trabalho teve como
um dos focos principais identificar os conceitos lean e de que forma os mesmos poderiam ser
aplicados ao desenvolvimento de software.

Embora o desenvolvimento ágil e o desenvolvimento lean de software ambos tenham

sido inspirados nos conceitos lean, Gustavsson (2011) destaca que métodos ágeis são
aplicados apenas ao desenvolvimento de software, enquanto lean é um conceito muito mais
abrangente. Segundo o autor, a filosofia lean não é apenas um conjunto de ferramentas. Ela
afeta todos os setores da empresa, desde os recursos humanos até o marketing.

Recebido 27/08/2012; Aceito 14/12/2012 66

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

A partir desse trabalho foram estabelecidos os sete princípios do desenvolvimento

lean de software (POPPENDIECK; POPPENDIECK, 2011).

2.3.1 Princípio um: Eliminar o desperdício

De acordo com Ohno (1988), o Sistema Toyota de Produção tem como um dos seus
focos a eliminação total do desperdício. O autor afirma que tudo o que não agrega valor para
o cliente deve ser removido do processo. Segundo Hibbs, Jewett e Sullivan (2009), esta
categoria abrange uma série de conceitos que devem ser analisados para que seja possível
compreender de que forma os desperdícios apontados no Sistema Toyota de Produção podem
ser identificados no processo de desenvolvimento de software.

• defeitos: são representados pelos defeitos em si. Defeitos causam o retrabalho custoso,
o qual não agrega valor ao produto. O desenvolvimento lean de software tem como
um dos seus objetivos prevenir os defeitos;

• superprodução: funcionalidades desnecessárias. O custo de um software não está

ligado apenas a escrever o código fonte. Esse código precisa ser mantido,
documentado, ensinado a novos membros da equipe, etc. Por esse motivo, todas as
funcionalidades inseridas no software devem provir das necessidades reais do usuário,
ou seja, funcionalidades que agregam valor ao produto final. De acordo com Hibbs,
Jewett e Sullivan (2009), o estudo ’CHAOS study’ de Standish Group mostrou que
64% de todas as funcionalidades não são usadas ou são usadas raramente (veja Figura
4). Isso constitui um grande desperdício de recursos ao longo do tempo;

• estoque: tarefas concluídas parcialmente. Aqui podemos considerar requisitos

analisados, mas ainda não implementados, código que ainda não foi testado ou erros
que ainda não foram corrigidos. Dentro da filosofia lean não se admite o acúmulo de
tarefas não concluídas. Em vez disso, procura-se adotar o fluxo unitário que faz com
que a tarefa seja concluída o quanto antes;

• movimentação: alternar entre tarefas. As interrupções e o trabalho alternado entre

diferentes atividades prejudicam muito a produtividade. Antes de iniciar o trabalho em

Recebido 27/08/2012; Aceito 14/12/2012 67

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

uma tarefa, as pessoas precisam de um tempo para se ambientar ao problema e para

compreender os requisitos passados. Qualquer interrupção faz com que esse processo
seja reiniciado. Este é um dos motivos por que o fluxo unitário é tão produtivo.

• processamento adicional: processos desnecessários. Esse tipo de processo constitui o

mais puro desperdício. Ele atrapalha a produtividade sem agregar valor algum ao
produto final. Um exemplo deste tipo de processo é a criação de documentação que
não é utilizada por ninguém, ou até execução manual de tarefas que poderiam ser
automatizadas;

• espera: atrasos. Durante o processo de desenvolvimento de software os

programadores frequentemente precisam se comunicar com outros participantes do
projeto para tirar dúvidas e esclarecer alguns requisitos. Se esses participantes não
estiverem disponíveis, haverá atrasos na entrega, ou a implementação será feita sem os
devidos esclarecimentos, o que na maioria das vezes gerará retrabalho. Esse retrabalho
é uma das formas mais comuns de desperdício no processo de desenvolvimento de
software e deve ser evitado a qualquer custo.

Figura 4: Percentagem de funcionalidades de softwares utilizadas na prática

Recebido 27/08/2012; Aceito 14/12/2012 68

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

Fonte: Adaptação de Hibbs, Jewett e Sullivan (2009)

2.3.2 Princípio dois: Integrar qualidade

Ohno (1988) afirma que não é possível inspecionar a qualidade de um produto ao fim
da linha de produção. Segundo Hibbs, Jewett e Sullivan (2009), as metodologias tradicionais
de desenvolvimento cometem exatamente esse erro: permitir que os defeitos sejam detectados
tardiamente pela equipe de garantia de qualidade.

Desenvolvimento lean de software, por outro lado, propõe uma filosofia diferente. Ao
invés de criar sistemas para controlar os defeitos (filas de não conformidades a serem
solucionadas), o processo deve ser focado na eliminação total de defeitos e na consequente
eliminação de filas de controle (POPPENDIECK; POPPENDIECK, 2011). Alcançar tal grau
de maturidade no processo só é possível com a utilização de recursos como testes unitários e
integração contínua, entre outros.

2.3.3 Princípio três: Criar conhecimento

Segundo Poppendieck e Poppendieck (2011), uma das grandes falhas do

desenvolvimento de software dirigido a planos é a ideia de que o conhecimento na forma de
requisitos existe separadamente da codificação. Autores destacam que o desenvolvimento de
software é um processo de criação de conhecimento e que o projeto detalhado, embora deva
ser esboçado antes, se firma apenas durante a implementação do código.

Bassi (2008) aponta que as lições devem ser extraídas das experiências vividas pela
equipe. Hibbs, Jewett e Sullivan (2009) colocam ainda que o conhecimento deve ser
armazenado de tal forma que possa ser facilmente localizado na próxima vez que se tornar
necessário. As pessoas não devem perder tempo aprendendo algo que já foi estudado e
colocado em prática por outros membros da equipe.

2.3.4 Princípio quatro: Adiar comprometimentos

Hibbs, Jewett e Sullivan (2009) afirmam que as melhores decisões são tomadas
quando dispomos de maior quantidade de informação possível. Se uma determinada decisão
não precisa ser tomada imediatamente, deve-se aguardar até que se tenha mais conhecimento

Recebido 27/08/2012; Aceito 14/12/2012 69

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

a respeito do assunto. Segundo Poppendieck e Poppendieck (2011), este item se aplica

principalmente à tomada de decisões irreversíveis. As decisões reversíveis devem ser tomadas
antes, porque elas podem ser facilmente modificadas.

2.3.5 Princípio cinco: Entregar rápido

Kniberg (2011) ensina que devemos começar com um profundo conhecimento daquilo
que agrega valor ao cliente. Uma vez compreendidas as necessidades do cliente, é criado um
fluxo de trabalho que procura fazer entregas rápidas e frequentes de software funcionando. De
acordo com Hibbs, Jewett e Sullivan (2009), a importância de entregar rápido está em obter o
retorno do cliente o quanto antes. Dessa forma evitamos que os requisitos mudem apenas por
terem demorado tempo demais para serem entregues.

2.3.6 Princípio seis: Respeitar as pessoas

Segundo Poppendieck e Poppendieck (2011), pessoas pensadoras e engajadas no

projeto são a maior e a mais sustentável vantagem competitiva que uma empresa pode ter.
Este pensamento define bem o que as pessoas representam dentro de uma filosofia lean.
Respeitar as pessoas significa confiar que elas sabem a melhor forma de exercer um trabalho e
também permitir que elas possam encontrar maneiras de melhorar os processos.

2.3.7 Princípio sete: Otimizar o todo

Segundo Poppendieck e Poppendieck (2011), aperfeiçoar um processo local quase

sempre é feito à custa do fluxo de valor no processo como todo. Isso ocorre quando as
mudanças são feitas sem levar em consideração o todo. Isso é conhecido como subotimização,
e uma organização que implementa conceitos lean sempre tenta evitá-la.

3. Estudo de caso

A empresa escolhida para este estudo de caso possui uma longa experiência no ramo
de desenvolvimento de software. Atualmente, é classificada como a principal fornecedora de
sistemas para a cadeia de suprimentos no Brasil. Além disso, a mesma tem implementado com
sucesso as metodologias ágeis de desenvolvimento de software, Scrum e XP, durante a última

Recebido 27/08/2012; Aceito 14/12/2012 70

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

década. Nos últimos cinco anos a empresa tem aumentado o seu interesse pelos conceitos de
desenvolvimento lean de software, com a intenção de melhorar a produtividade de suas
equipes.

3.1 Conceitos lean na prática

Diversos indicadores têm sido usados para acompanhar a produtividade dessas

equipes, e metas têm sido estabelecidas para avaliar o seu progresso. Um dos principais
indicadores acompanhados avalia o tempo que a equipe investe, em cada versão de software,
nas melhorias e nas novas funcionalidades. Estas tarefas agregam valor ao produto e o
aumento deste indicador tem sido um dos objetivos da empresa.

Todas as outras atividades desempenhadas pela equipe são consideradas desperdício,

mesmo que algumas sejam necessárias para que o processo possa ser administrado
corretamente. Exemplos de algumas atividades desempenhadas pela equipe são: correção de
não conformidades, participação em reuniões, planejamento e outros. Quando o tempo
investido em correção de não conformidades (erros causados durante a execução do software)
aumenta, é um indicativo de que a qualidade do produto tem piorado. Consequentemente, a
equipe disporá de menos tempo para investir em melhorias e novas funcionalidades.

Na tentativa de melhorar os indicadores avaliados e aumentar a qualidade do produto,

a equipe que foi acompanhada neste estudo de caso optou por adotar os conceitos de
desenvolvimento lean de software. Cada um dos sete conceitos explicados na seção 2.3 deste
artigo teve uma ação correspondente.

3.1.1 Eliminar o desperdício

O problema de multitarefa foi identificado como um dos principais motivos da

diminuição da produtividade. As pessoas eram constantemente envolvidas em mais de uma
atividade, o que tirava a sua concentração das tarefas principais (implementar melhorias e
novas funcionalidades). Algumas multitarefas surgiam pela constante necessidade de se
prestar suporte às outras equipes a respeito do funcionamento do software, porém outras eram
causadas pelo comportamento da equipe em si. Ou seja, os desenvolvedores eram envolvidos

Recebido 27/08/2012; Aceito 14/12/2012 71

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

em mais de uma tarefa ao mesmo tempo, porque não havia regras claras dentro do processo
sobre qual deveria ser o comportamento correto nestes casos.

Para lidar com o problema da multitarefa foram definidas duas diretrizes novas no
processo de desenvolvimento de software:

1. a cada versão do software, uma pessoa da equipe seria elencada para tratar as tarefas
de suporte solicitadas por outras equipes. Desta forma, o restante da equipe ficaria
livre para se dedicar ao desenvolvimento de melhorias e novas funcionalidades;

2. nenhum desenvolvedor se envolveria com mais de um requisito ao mesmo tempo. O

objetivo era implementar o fluxo unitário (contínuo). Apenas após terminada por
completo uma atividade, desenvolvedor se dedicaria a uma outra, mesmo que isso
significasse às vezes algum tempo ocioso.

3.1.2 Integrar qualidade

A prática de testes automatizados, isto é, os testes que não dependem da interação

humana e garantem o correto funcionamento de uma ou mais funcionalidades de software,
seria integrada ao processo desde o seu começo. A experiência havia mostrado que deixar o
desenvolvimento de testes para uma fase posterior causava desperdício, porque criava um
estoque de tarefas que dificilmente era baixado.

3.1.3 Criar conhecimento

Todo o conhecimento a respeito do produto deveria estar ao alcance de todos os

membros da equipe. Para alcançar tal objetivo, foi implementada uma ferramenta colaborativa
de gestão de conhecimento, onde todos poderiam contribuir documentando os processos nos
quais estavam trabalhando. O conhecimento não poderia estar restrito apenas a um grupo de
desenvolvedores mais experientes.

3.1.4 Adiar comprometimentos

Decisões importantes, principalmente as que envolviam alterações na arquitetura do

sistema, eram postergadas até o momento em que a equipe tivesse mais conhecimento sobre o

Recebido 27/08/2012; Aceito 14/12/2012 72

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

assunto e, consequentemente, mais segurança no processo de tomada de decisão. Esta prática

mostrou-se bastante eficaz, porque evitou decisões precipitadas.

3.1.5 Entregar rápido

Dividir o projeto em iterações menores, entre três a quatro semanas, possibilitou a

entrega rápida das funcionalidades, mesmo que parcialmente terminadas. Dessa forma foi
possível obter o retorno do cliente mais rapidamente, e fazer com que o mesmo tenha um
nível de envolvimento maior na evolução do produto. Essa prática é muito usada na
metodologia Scrum, uma das metodologias ágeis adotadas pela equipe.

3.1.6 Respeitar as pessoas

Em todas as reuniões de planejamento das próximas versões do software todos os

membros da equipe são ouvidos. As decisões finais levam em consideração a opinião de todos
e fazem com que a equipe se comprometa com as estimativas.

3.1.7 Otimizar o todo

Foi destacada dentro da equipe a importância de se conhecer o processo da empresa

como todo, não levando em consideração apenas as atividades de desenvolvimento de
software. Foram feitos workshops com outras equipes que esclareceram diversas dúvidas
sobre como o software era usado na prática.

Esse conhecimento adquirido fez com que a equipe tivesse como um dos seus
objetivos avaliar sempre durante o desenvolvimento de uma funcionalidade de que forma a
mesma iria impactar o trabalho dos clientes internos e externos. O resultado final desta
abordagem foi uma melhoria na usabilidade e uma melhor aceitação por parte dos clientes.

3.2 Coleta de dados

A empresa onde foi conduzido o estudo de caso possui diversas ferramentas para
gerenciar o processo de desenvolvimento de software. Todos os requisitos desenvolvidos são
registrados, assim como as tarefas e as correções de não conformidades.

Recebido 27/08/2012; Aceito 14/12/2012 73

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

Diariamente, os membros da equipe fazem os registros de horas trabalhadas. Cada

registro de horas é, obrigatoriamente, vinculado a uma tarefa, a qual pode ser uma melhoria,
uma correção de não conformidade, uma reunião, etc. Cada uma dessas tarefas por sua vez é
vinculada a um determinado componente. Atualmente os componentes são divididos em:

1. produto: agrupa todas as horas investidas em tarefas que agregam valor ao produto,
tais como melhorias e novas funcionalidades, desenvolvimento de testes
automatizados, etc.;

2. não conformidade: o tempo gasto em correção de não conformidades;

3. suporte: horas que são registradas em atividades de suporte prestado às outras

equipes;

4. acompanhamento: todas as tarefas relativas ao gerenciamento do projeto: reuniões,

planejamentos, reuniões diárias de acompanhamento, etc.

Além da ferramenta de controle de requisitos, a empresa possui um sistema de BI

(Business Intelligence) através do qual é possível acompanhar, versão a versão, as horas
investidas pela equipe em cada um dos componentes relacionados anteriormente. Os dados
fornecidos por essa ferramenta foram utilizados neste estudo de caso para avaliar os impactos
que a implementação de desenvolvimento lean de software teve nos indicadores
acompanhados pela equipe.

3.3 Análise dos resultados

Para a análise dos resultados, utilizou-se o período de um ano, de setembro de 2011 até
agosto de 2012. As ações tomadas pela equipe e que foram explanadas nas seções anteriores
tiveram a sua implementação no mês de fevereiro de 2012. Desta forma faz-se possível
observar a evolução do indicador de tempo investido no desenvolvimento de melhorias e
novas funcionalidades, abrangendo as fases anterior e posterior às mudanças implementadas.

Os dados foram obtidos a partir da ferramenta de BI fornecida pela equipe de

qualidade de software da empresa. O percentual de horas investido foi acompanhado

Recebido 27/08/2012; Aceito 14/12/2012 74

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

mensalmente, e a informação foi dividida em dois grupos. O grupo “produto” abrange todas
as horas gastas em melhorias e novas funcionalidades, enquanto no grupo “outros” foram
inseridas todas as outras atividades desempenhadas pela equipe.

A Tabela 1 mostra o histórico do percentual extraído da ferramenta de BI. É possível

observar a partir dos dados coletados que, a partir de fevereiro de 2012, o percentual de horas
investido em produto teve um aumento aproximado de 16%, exatamente no mês em que os
conceitos relacionados anteriormente foram aplicados.

A partir do mês de fevereiro, com exceção do mês de março, o indicador se manteve

acima dos 60%, chegando a atingir o seu pico de 65% no mês de maio.

Tabela 1: Coleta de dados de tempo investido por componente

Mês 9/12 10/12 11/11 12/11 1/12 2/12 3/12 4/12 5/12 6/12 7/12 8/12

Produto 50% 54,2% 51,82% 54,4% 51,65% 60,02% 57,37% 61,3% 65,1% 64,21% 60,5% 61%

Outros 50% 45,8% 48,18% 45,6% 48,35% 39,98% 42,63% 38,7% 34,9% 35,79% 39,5% 39%

Fonte: Os Autores (2012)

Através do gráfico apresentado na Figura 5 é possível verificar de forma mais clara o

aumento do tempo investido em produto em relação a outros componentes. Enquanto que no
ano 2011 o indicador se mantinha em torno de 50%, a partir das mudanças implementadas o
mesmo passa a se manter na faixa de 60%.

Recebido 27/08/2012; Aceito 14/12/2012 75

Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

70

60

50

40
Produto
30 Outros

20

10

0
Novembro 2011 Março 2012 Julho 2012
Setembro 2011 Janeiro 2012 Maio 2012

Figura 5: Evolução do percentual de tempo investido por componente

Fonte: Os Autores (2012)

4. Conclusão

Com base nos resultados analisados, é possível concluir que os conceitos de

desenvolvimento lean de software adotados pela equipe alvo deste estudo de caso tiveram um
impacto positivo em um dos principais indicadores usados para avaliar a produtividade do
processo de desenvolvimento de software.

É importante observar que apenas o tempo investido em produto não garante a

produtividade da equipe, tampouco pode ser considerado um indicador de qualidade. Para que
seja possível obter uma avaliação mais precisa, outros indicadores também devem ser levados
em consideração, como por exemplo, o número de não conformidades, estabilidade do
sistema em ambientes de produção, percentual de código fonte coberto por testes
automatizados, etc.

Recebido 27/08/2012; Aceito 14/12/2012 76

 Centro Universitário Tupy – UNISOCIESC
Joinville, Santa Catarina, Brasil
ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013
DOI: 10.14521/P2237-5163.2013.0003.0003

No entanto, a adoção de técnicas e diretrizes que possibilitam que uma equipe de

desenvolvimento de software invista cada vez mais tempo no desenvolvimento de melhorias e
novas funcionalidades pode ser considerada um importante avanço na melhoria do processo
como todo.

Referências

ARKED, M. Risk reduction with the RUP phase plan. nov. 2003. Disponível em:
<http://www.ibm.com/developerworks/rational/library/1826.html>.
BASSI FILHO, Dairton Luiz. Experiências com desenvolvimento ágil. 2008. 170 f. Dissertação (Mestrado) -
Departamento de Instituto de Matemática e Estatística, Universidade de São Paulo, São Paulo, 2008.
COHN, Mike. Succeeding with agile: Software development using scrum. Boston: Addison-Wesley, 2010. 471
p.
DYBA, Tore; DINGSOYR, Torgeir. Empirical studies of agile software development: A systematic review.
Information and Software Technology, Nova Iorque, n. 50, p.833-859, 2008.
GUSTAVSSON, Håkan. Lean thinking applied to system architecting. 2011. 72 f. Tese (Doutorado) -
Departamento de School of Innovation, Design and Engineering, Mälardalen University, Västerås, 2011.
HIBBS, Curt; JEWETT, Steve; SULLIVAN, Mike. The art of lean software development. Sebastopol:
O’Reilly Media, Inc., 2009. 144 p.
KNIBERG, H. Lean from the Trenches: Managing Large-Scale Projects with Kanban. Dallas: The Pragmatic
Bookshelf, 2011. 165 p.
OHNO, T. Toyota Production Software: Beyond Large Scale Production. Productivity Press, 1988.
PETERSEN, Kai. Implementing Lean and Agile Software Development in Industry. 2010. 309 f. Tese
(Doutorado) - Departamento de School of Computing, Blekinge Institute of Technology, Karlskrona, 2010.
POPPENDIECK, Mary; POPPENDIECK, Tom. Implementando o desenvolvimento lean de software: Do
conceito ao dinheiro. Porto Alegre: Bookman, 2011. 280 p.
PRESMAN, R. S. Software Engineering: a Practitioner’s Approach. 6. ed. McGraw-Hill, 2004.
PRIES, K. H.; QUIGLEY, J. M. Scrum Project Management. Boca Raton: CRC Press, 2011. 170 p.
SHORE, James; WARDEN, Shane. The Art of Agile Development. Sebastopol: O´Reilly Media, Inc., 2008.
SMITH, Greg; SIDKY, Ahmed. Becoming Agile: In an imperfect world. Greenwich: Manning Publications Co,
2009. 410 p.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson Education do Brasil, 2011. 529 p.
VLAANDEREN, Kevin et al. The agile requirements refinery: Applying SCRUM principles to software product
management. Information and Software Technology, Amsterdam, n. 53, p.58-70, 2010.

Recebido 27/08/2012; Aceito 14/12/2012 77

View publication stats