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

Instituto Superior Tupy – IST/SOCIESC Joinville, Santa Catarina, Brasil ISSN 2237-5163 / v. 03, n. 01: p. 59-77, ano 2013

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

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 ([email protected], Instituto Superior Tupy/SOCIESC, Santa Catarina, Brasil) • Rui Barbosa, 1431, APTO 402C, 89220-100, Costa e Silva. NeoGrid, Joinville, SC, Brasil

Mehran Misaghi ([email protected], 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 60

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 61

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 62

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 63

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 Fonte: Bassi (2008)


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

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 65

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 66

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 67

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 68

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 Fonte: Adaptação de Hibbs, Jewett e Sullivan (2009)


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

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

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


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

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

década. Nos últimos cinco anos a empresa tem aumentado o seu interesse pelos conceitos de


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

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 72

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 73

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 74

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 75

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 76

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.

Setembro 2011Novembro 2011

Janeiro 2012Março 2012

Maio 2012Julho 2012

0

10

20

30

40

50

60

70

ProdutoOutros


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

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.

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

Documents

Transcript of Desenvolvimento lean de software: estudo de caso em uma...