Desenvolvimento lean de software: conceitos e aplicaes

Ivan Bosnic (NeoGrid) ivan.bosnic @neogrid.com

Mehran Misaghi (Sociesc) mehran@sociesc.org.br
Resumo: Este artigo traz uma reviso bibliogrfica cujo propsito identificar as principais
caractersticas de desenvolvimento lean de software e as suas semelhanas e diferenas com
as metodologias geis! "o apresentadas as metodologias de desenvolvimento de software
mais comuns# onde uma ateno maior foi dedicada ao desenvolvimento lean de software!
Em seguida so apresentados dois estudos de casos com o objetivo de mostrar $uais foram os
benefcios alcanados nas empresas e nos projetos $ue resolveram adotar a abordagem lean
para desenvolvimento de software! %onstatou&se ao final deste trabalho $ue as metodologias
geis e lean t'm vrios itens em comum# porm o conceito lean mais abrangente por$ue
afeta no apenas o processo de desenvolvimento de software# mas a empresa como todo!
(alavras chaves: )ean* +etodologias geis* "crum* "oftware
! Introd"#o
As sociedades modernas dependem cada dia mais de diversos tipos de programas
computacionais. Tais programas (softwares) gerenciam as nossas contas bancrias, controlam
o fornecimento de gua e energia eltrica, monitoram a nossa sade uando internados em
hospitais acuados por doen!as, divertem"nos uando brincamos de #ogos eletr$nicos, e
fornecem tantos outros servi!os cr%ticos para a comunidade. &ra de se esperar ue, ao se tratar
de pe!as t'o fundamentais para a nossa vida, os pro#etos de software estivessem em um n%vel
de sucesso bastante elevado.
(o entanto, segundo )ibbs, *ewett e +ullivan (,--.), a prtica de desenvolvimento de
software tem sido atormentada com ta/as de sucesso criticamente bai/as durante dcadas.
&nuanto isso, as demandas por servi!os e produtos de informtica n'o param de crescer e a
situa!'o parece entrar em uma situa!'o ca0tica, sem solu!'o. 1 ue tem tra2ido certo
otimismo o surgimento de metodologias geis, as uais t3m demonstrado ue poss%vel
obter ta/as de sucesso melhores. (o trabalho de 4assi (,--5) observado ue e/iste uma
tend3ncia de melhoria na ualidade dos pro#etos, mas ainda assim a situa!'o reuer aten!'o,
porue o percentual de pro#etos ue ultrapassam os custos ou o pra2o continua uase t'o
elevado uanto antes.
)ibbs, *ewett e +ullivan (,--.) destacam ainda ue as tcnicas lean t3m sido cada ve2
mais aplicadas ao desenvolvimento de software. A ideologia e as tcnicas lean 6s uais os
autores se referem s'o as mesmas utili2adas no +istema To7ota de 8rodu!'o e +istema To7ota
de 9esenvolvimento de 8roduto. +egundo 8oppendiec: e 8oppendiec: (,-;;), o primeiro
passo na implementa!'o do desenvolvimento lean de software compreender esses
;
princ%pios, porue o desenvolvimento de software uma forma de desenvolvimento de
produto.
Aplicar os conceitos de lean manufacturing, usados h bastante tempo na indstria
tradicional e principalmente na automobil%stica, ao processo de desenvolvimento de software
o desafio por trs do desenvolvimento lean de software. <esmo ue a sua defini!'o n'o
imponha tal regra, uase sempre encontramos desenvolvimento lean de software interligado
com as metodologias geis. =sso se deve ao fato de vrios conceitos serem compartilhados por
ambas as metodologias. 1s mtodos geis obt3m sucessos organi2acionais ao focar na entrega
de valor e na diminui!'o de custos (+)1>&? @A>9&(, ,--5).
Ao longo deste trabalho ser demonstrado ue n'o se trata de conceitos concorrentes,
e sim complementares.
$! Metodologias de desenvolvimento de software
9iversas divisAes de metodologias de desenvolvimento de software podem ser
encontradas na literatura. 1 presente trabalho divide os tipos de desenvolvimento de software
em tr3s grupos, conforme 8etersen (,-;-), sendo elesB desenvolvimento de software dirigido a
planos, desenvolvimento gil de software e desenvolvimento lean de software.
$! Desenvolvimento de software dirigido a planos
Como o pr0prio nome sugere, o desenvolvimento de software dirigido a planos est
focado em plane#ar tudo desde o in%cio do pro#eto (8&T&>+&(, ,-;-). 8ara ue esse
plane#amento se#a poss%vel, esta abordagem se apoia em uma srie de documentos (artefatos)
ue s'o gerados na fase inicial do pro#eto e ue acompanham o mesmo durante todo o seu
ciclo de vida.
Alm disso, ao final de cada fase s'o produ2idos alguns artefatos cu#a fun!'o
comprovar ue a mesma foi finali2ada. +omente ent'o ue deve ser iniciado o trabalho da
pr0/ima fase do processo.
1 modelo em cascata um e/emplo de um processo dirigido a planos
(+1<<&>D=EE&, ,-;;). &sse processo e/ecutado de forma seuencial, segundo os passos
ue representam as diferentes disciplinas de desenvolvimento de software (8&T&>+&(,
,-;-). A Figura ; tra2 uma representa!'o grfica do modelo em cascata e de suas fases.
,
Figura ; G 1 modelo em cascata
FonteB Adapta!'o de +ommerville (,-;-)
1 principal ob#etivo desta abordagem prover uma estrutura para e/ecu!'o do
processo de desenvolvimento de software. (o entanto, o processo n'o ocorre de forma linear,
mas sim envolve a realimenta!'o de uma fase para outra, (+1<<&>D=EE&, ,-;;). 8resman
(,--H) define ainda ue em cada uma das fases reali2ado um con#unto predefinido de
atividades. &ssas atividades produ2em artefatos ue servem de entrada para a atividade
seguinte.
+egundo 8etersen (,-;-), outro e/emplo de processo dirigido a planos >I8
(Rational ,nified (rocess). &ste processo mais fle/%vel uando se trata da seu3ncia em ue
as disciplinas s'o e/ecutadas. =sso significa ue as atividades de engenharia de software
definidas pelo processo s'o e/ecutadas durante todo o ciclo de vida do mesmo.
$!! %&'
>I8 possui uatro fasesB concep!'o, elabora!'o, constru!'o e transi!'o. A Figura ,
ilustra as disciplinas e as fases ue fa2em parte do >I8.
9e acordo com a Figura ,, poss%vel observar ue todas as disciplinas de engenharia
de software propostas por >I8 participam de uase todas as fases, porm com uma
intensidade diferenciada.
J
Figura ,B As fases do >I8 e a distribui!'o do volume de atividades em cada uma delas
FonteB 4assi (,--5)
$!$ Desenvolvimento (gil de software
9e acordo com 97ba e 9ingso7r (,--5), o desenvolvimento gil de software
representa o maior avan!o na engenharia de software uando comparado 6s abordagens
dirigidas a planos.
+egundo 4assi (,-;-), a indstria de software se baseou, durante muito tempo, em
mtodos tradicionais de desenvolvimento de software. &sses mtodos vinham apresentando
um grande nmero de fracassos, o ue levou alguns l%deres e/perientes a adotarem modos de
trabalho ue se opunham a esses conceitos.
(o ano de ,--;, esse grupo escreveu um documento chamado +anifesto for -gile
"oftware .evelopment, cu#o ob#etivo era identificar os valores ue tra2iam mais benef%cios
para o processo de desenvolvimento de software (+<=T)? +=9KL, ,--.). &sse documento
est dispon%vel na =nternet atravs do endere!o httpBMMagilemanifesto.orgM. As uatro premissas
do manifesto s'oB
Indiv)d"os e iteraes s'o mais importantes do ue processos e ferramentas.
Software f"ncionando mais importante do ue documenta!'o completa.
*ola+ora#o com o cliente mais importante do ue negocia!'o de contratos.
,dapta#o a m"danas mais importante do ue seguir o plano inicial.
1s itens do lado esuerdo (destacados em negrito) s'o os ue representam mais
importNncia para um processo gil, porm os itens do lado direito n'o podem ser ignorados.
Ao contrrio, eles devem ser levados em considera!'o e valori2ados, sendo ue o seu valor
menor uando comparados com os itens do lado esuerdo (+<=T)? +=9KL, ,--.).
H
A partir das defini!Aes do manifesto, surgiram diversas metodologias de
desenvolvimento de software, entre as uais destacamos O8 e +crum.
$!$! -'
+egundo +ommerville (,-;;), E/treme (rogramming (O8) um dos mtodos geis
mais utili2ados. &sta abordagem foi desenvolvida para levar em considera!'o as melhores
prticas de desenvolvimento de software, como o desenvolvimento iterativo. +egundo +mith e
+id:7 (,--.), em compara!'o com outras tcnicas geis, O8 focado mais na aplica!'o de
conceitos tcnicos. Ainda de acordo com os autores, n'o poss%vel definir uma tcnica gil
como sendo a melhor, tudo depende do ue funciona melhor no ambiente da empresa e dentro
de suas restri!Aes.
Ima das principais caracter%sticas de O8 o fato de os testes serem criados antes
mesmo de se escrever o c0digo fonte na linguagem de programa!'o. A codifica!'o, por sua
ve2, feita em duplas, tcnica chamada de pair programming.
$!$!$ Scr"m
Figura J G Ciclo de desenvolvimento do "crum
FonteB 4assi (,--5)
1 mtodo +crum foi proposto em ;..P por Ken +chwaber (DEAA(9&>&( &T al.,
,-;-). Como todos os processos geis, +crum uma abordagem iterativa e incremental para
desenvolvimento de software (C1)(, ,-;-). 9esenvolvimento incremental subentende a
constru!'o de um sistema peda!o por peda!o, ou se#a, primeiro um peda!o desenvolvido,
depois outro adicionado a ele, e assim por diante.
P
A parte mais importante do +crum bac0log do produto, isto , uma lista com todos os
reuisitos ue devem ser implementados para ue o software funcione da forma correta
(K(=4&>Q, ,--R). 1ac0log dinNmico e pode ser alterado eMou priori2ado conforme as
necessidades do cliente.
1 desenvolvimento em si ocorre em itera!Aes chamadas sprints e ue normalmente
duram de uma a uatro semanas. Antes de iniciar uma sprint, a euipe se rene, elenca os
reuisitos ue ser'o trabalhados (reuisitos s'o escolhidos de acordo com as prioridades de
neg0cio estabelecidas) e depois esses itens s'o uebrados em tarefas de implementa!'o de
menor comple/idade (4A++=, ,--5). A Figura J demonstra todo o ciclo de desenvolvimento
do "crum.
$!. Desenvolvimento lean de software
9e acordo com +hore e @arden (,--5), as ideias nas uais se baseia o
desenvolvimento lean de software t3m a sua origem na manufatura en/uta e no
desenvolvimento lean de produto. &sses conceitos, por sua ve2, tiveram as suas origens no
+istema To7ota de 8rodu!'o e no +istema To7ota de 9esenvolvimento de 8roduto.
+egundo 8oppendiec: e 8oppendiec: (,-;;), o desenvolvimento de software uma
forma de desenvolvimento de produto. Foram os pr0prios autores ue, em ,--J, introdu2iram
pela primeira ve2 o conceito de desenvolvimento lean de software. 1 seu trabalho teve como
um dos focos principais identificar os conceitos lean e de ue forma os mesmos poderiam ser
aplicados ao desenvolvimento de software.
&mbora o desenvolvimento gil e o desenvolvimento lean de software ambos tenham
sido inspirados no conceitos lean, Qustavsson (,-;;) destaca ue mtodos geis s'o aplicados
apenas ao desenvolvimento de software, enuanto lean um conceito muito mais abrangente.
+egundo o autor, a filosofia lean n'o apenas um con#unto de ferramentas. &la afeta todos os
setores da empresa, desde os recursos humanos at o mar:eting.
A partir desse trabalho foram estabelecidos os sete princ%pios do desenvolvimento
lean de software (8188&(9=&CK? 8188&(9=&CK, ,-;;).
$!.! 'rinc)pio "m: /liminar o desperd)cio
9e acordo com 1hno (;.55), o +istema To7ota de 8rodu!'o tem como um dos seus
focos a elimina!'o total do desperd%cio. 1 autor afirma ue tudo o ue n'o agrega valor para
o cliente deve ser removido do processo. +egundo )ibbs, *ewett e +ullivan (,--.), esta
categoria abrange uma srie de conceitos ue devem ser analisados para ue se#a poss%vel
compreender de ue forma os desperd%cios apontados no +istema To7ota de 8rodu!'o podem
ser identificados no processo de desenvolvimento de software.
Defeitos: s'o representados pelos defeitos em si. 9efeitos causam o retrabalho
custoso, o ual n'o agrega valor ao produto. 1 desenvolvimento lean de software tem
como um dos seus ob#etivos prevenir os defeitos.
S"perprod"#o: funcionalidades desnecessrias. 1 custo de um software n'o est
ligado apenas a escrever o c0digo fonte. &sse c0digo precisa ser mantido,
documentado, ensinado a novos membros da euipe, etc. 8or esse motivo, todas as
funcionalidades inseridas no software devem provir das necessidades reais do usurio,
S
ou se#a, funcionalidades ue agregam valor ao produto final. 9e acordo com )ibbs,
*ewett e +ullivan (,--.), o estudo TC)A1+ stud7T de +tandish Qroup mostrou ue
SHU de todas as funcionalidades n'o s'o usadas ou s'o usadas raramente (ve#a Figura
H). =sso constitui um grande desperd%cio de recursos ao longo do tempo.
Figura HB 8ercentagem de funcionalidades de softwares utili2adas na prtica
FonteB Adapta!'o de )ibbs, *ewett e +ullivan (,--.)
/sto0"e: tarefas conclu%das parcialmente. Aui podemos considerar reuisitos
analisados, mas ainda n'o implementados, c0digo ue ainda n'o foi testado ou erros
ue ainda n'o foram corrigidos. 9entro da filosofia lean n'o se admite o acmulo de
tarefas n'o conclu%das. &m ve2 disso, procura"se adotar o flu/o unitrio ue fa2 com
ue a tarefa se#a conclu%da o uanto antes.
Movimenta#o: alternar entre tarefas. As interrup!Aes e o trabalho alternado entre
diferentes atividades pre#udicam muito a produtividade. Antes de iniciar o trabalho em
uma tarefa, as pessoas precisam de um tempo para se ambientar ao problema e para
compreender os reuisitos passados. Vualuer interrup!'o fa2 com ue esse processo
se#a reiniciado. &ste um dos motivos por ue o flu/o unitrio t'o produtivo.
'rocessamento adicional: processos desnecessrios. &sse tipo de processo constitui o
mais puro desperd%cio. &le atrapalha a produtividade sem agregar valor algum ao
produto final. Im e/emplo deste tipo de processo a cria!'o de documenta!'o ue
n'o utili2ada por ningum, ou at e/ecu!'o manual de tarefas ue poderiam ser
automati2adas.
/spera: atrasos. 9urante o processo de desenvolvimento de software os
programadores freuentemente precisam se comunicar com outros participantes do
pro#eto para tirar dvidas e esclarecer alguns reuisitos. +e esses participantes n'o
R
estiverem dispon%veis, haver atrasos na entrega, ou a implementa!'o ser feita sem os
devidos esclarecimentos, o ue na maioria das ve2es gerar retrabalho. &sse retrabalho
uma das formas mais comuns de desperd%cio no processo de desenvolvimento de
software e deve ser evitado a ualuer custo.
$!.!$ 'rinc)pio dois: Integrar 0"alidade
1hno (;.55) afirma ue n'o poss%vel inspecionar a ualidade de um produto ao fim
da linha de produ!'o. +egundo )ibbs, *ewett e +ullivan (,--.), as metodologias tradicionais
de desenvolvimento cometem e/atamente esse erroB permitir ue os defeitos se#am detectados
tardiamente pela euipe de garantia de ualidade.
9esenvolvimento lean de software, por outro lado, propAe uma filosofia diferente. Ao
invs 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 conseuente
elimina!'o de filas de controle (8188&(9=&CK? 8188&(9=&CK, ,-;;). Alcan!ar tal grau
de maturidade no processo s0 poss%vel com a utili2a!'o de recursos como testes unitrios e
integra!'o cont%nua, entre outros.
$!.!. 'rinc)pio tr1s: *riar conhecimento
+egundo 8oppendiec: e 8oppendiec: (,-;;), uma das grandes falhas do
desenvolvimento de software dirigido a planos a ideia de ue o conhecimento na forma de
reuisitos e/iste separadamente da codifica!'o. Autores destacam ue o desenvolvimento de
software um processo de cria!'o de conhecimento e ue o pro#eto detalhado, embora deva
ser esbo!ado antes, se firma apenas durante a implementa!'o do c0digo.
4assi (,--5) aponta ue as li!Aes devem ser e/tra%das das e/peri3ncias vividas pela
euipe. )ibbs, *ewett e +ullivan (,--.) colocam ainda ue o conhecimento deve ser
arma2enado de tal forma ue possa ser facilmente locali2ado na pr0/ima ve2 ue se tornar
necessrio. As pessoas n'o devem perder tempo aprendendo algo ue # foi estudado e
colocado em prtica por outros membros da euipe.
$!.!2 'rinc)pio 0"atro: ,diar comprometimentos
)ibbs, *ewett e +ullivan (,--.) afirmam ue as melhores decisAes s'o tomadas
uando dispomos de maior uantidade de informa!'o poss%vel. +e uma determinada decis'o
n'o precisa ser tomada imediatamente, deve"se aguardar at ue se tenha mais conhecimento
a respeito do assunto. +egundo 8oppendiec: e 8oppendiec: (,-;;), este item se aplica
principalmente 6 tomada de decisAes irrevers%veis. As decisAes revers%veis devem ser tomadas
antes, porue elas podem ser facilmente modificadas.
$!.!3 'rinc)pio cinco: /ntregar r(pido
Kniberg (,-;;) ensina ue devemos come!ar com um profundo conhecimento dauilo
ue agrega valor ao cliente. Ima ve2 compreendidas as necessidades do cliente, criado um
flu/o de trabalho ue procura fa2er entregas rpidas e freuentes de software funcionando. 9e
acordo com )ibbs, *ewett e +ullivan (,--.), a importNncia de entregar rpido est em obter o
retorno do cliente o uanto antes. 9essa forma evitamos ue os reuisitos mudem apenas por
terem demorado tempo demais para serem entregues.
5
$!.!4 'rinc)pio seis: %espeitar as pessoas
+egundo 8oppendiec: e 8oppendiec: (,-;;), pessoas pensadoras e enga#adas no
pro#eto s'o a maior e a mais sustentvel vantagem competitiva ue uma empresa pode ter.
&ste pensamento define bem o ue as pessoas representam dentro de uma filosofia lean.
>espeitar as pessoas significa confiar ue elas sabem a melhor forma de e/ercer um trabalho e
tambm permitir ue elas possam encontrar maneiras de melhorar os processos.
$!.!5 'rinc)pio sete: 6timi7ar o todo
Aperfei!oar um processo local uase sempre feito 6 custa do flu/o de valor no
processo como todo. =sso ocorre uando as mudan!as s'o feitas sem levar em considera!'o o
todo. =sso conhecido como subotimi2a!'o, e uma organi2a!'o ue implementa conceitos
lean sempre tenta evit"la.
.! /st"dos de caso
1 trabalho de <urra7 (,--5) tra2 dois estudos de caso onde o autor analisou o
processo de transi!'o de uma metodologia dirigida a planos para uma metodologia gilMlean.
As empresas escolhidas, =4< e Kronos, estiveram presas aos seus mtodos tradicionais
durante anos e foram escolhidas propositalmente, para ue as implica!Aes culturais tambm
pudessem ser avaliadas.
.! IBM
(a =4<, o estudo de caso foi condu2ido no produto Eotus 9omino, uando o mesmo
passou de um mtodo tradicional em cascata para um mtodo gil de desenvolvimento de
software. Eotus 9omino um produto corporativo de sucesso ue est no mercado h mais de
uin2e anos.
(os primeiros dias, uando a vers'o ;.- ainda estava sendo desenvolvida, o processo
de compila!'o e empacotamento do software levava um dia inteiro. (a poca, o software
tinha ;5- mil linhas de c0digo. A lentid'o do processo se devia, entre outras coisas, 6 bai/a
capacidade computacional do hardware dauela poca.
9urante o tempo, a base de c0digo fonte cresceu significativamente, em tamanho e em
comple/idade. Atualmente o software possui mais de ,, milhAes de linhas de c0digo fonte. 1
time de desenvolvimento dedicado cresceu de ;- pessoas em ;..R para H- em ,--R. 1 tempo
mdio para o lan!amento de uma nova vers'o do produto era de um ano e meio. &mbora a
ualidade do produto fosse satisfat0ria, havia uma preocupa!'o de ue a empresa n'o era
suficientemente responsiva 6s necessidades dos clientes e ue alguns dos recursos do software
n'o atendiam 6s suas e/pectativas.
8ara lidar com esses problemas, o aruiteto responsvel sugeriu a ado!'o de mtodos
geis de desenvolvimento de software, incluindo lean. 1s ob#etivos principais da transi!'o
eramB
>espostas rpidas 6s necessidades dos clientes.
>edu2ir desperd%cio no produto.
Qerar versAes de software de alta ualidade para obter o retorno rpido do cliente.
.
1 time de desenvolvimento do Eotus conseguiu resultados bastante positivos, entre os
uais podemos destacarB
>apide2 na publica!'o de versAes beta do software. Vuatro versAes beta foram
lan!adas em um per%odo de tempo em ue, com a utili2a!'o do modelo em cascata,
apenas uma ou duas versAes teriam sido liberadas.
A ualidade das versAes melhorou, embora essa melhoria de ualidade n'o tenha
mtricas precisas para fa2er as devidas compara!Aes. (o entanto, a percep!'o da
melhoria se deve principalmente aos retornos positivos vindos dos clientes ue
utili2am as versAes beta.
1s times come!aram a trabalhar de forma mais integrada, o ue os tornou mais fortes
e coesos.
Testes automati2ados tiveram uma melhoria significativa, por causa da filosofia das
metodologias geis. &m torno de S-U de novos recursos do software tinham os seus
testes completamente automati2ados.
)ouve um aumento de produtividade percebido por todos os membros da euipe.
.!$ 8ronos
Kronos uma empresa de desenvolvimento de software bem sucedida e ue
desenvolve sistema para gerenciamento de recursos humanos. Assim como a =4<, eles
tinham uma forte defini!'o de desenvolvimento dirigido a planos dentro da sua cultura
organi2acional durante ,- anos.
A iniciativa para a ado!'o de metodologias geis veio a partir do diretor de tecnologia
da empresa. 8ara ele, simplesmente havia algo de errado no processo de desenvolvimento de
software da empresa. 1 ciclo de desenvolvimento de uma vers'o nova do produto levava um
ano, onde seis meses eram gastos em desenvolvimento propriamente dito e outros seis meses
em testes.
1s principais resultados obtidos pela empresa foramB
A uantidade de novos recursos adicionados ao produto superou as e/pectativas. (a
maior parte isso se deve ao fortalecimento dos empregados conuistado durante a
ado!'o de metodologias geis.
A empresa consegue responder 6s necessidades dos clientes de maneira mais
responsiva durante a fase de desenvolvimento, porue constantemente obtm o seu
retorno.
1 tempo gastou com testes foi redu2ido significativamente, sem afetar a ualidade do
produto.
)ouve menos n'o conformidades detectadas depois da publica!'o oficial do software.
=sso foi poss%vel gra!as 6s mudan!as no processo de desenvolvimento. Testes s'o
feitos antes com utili2a!'o de versAes beta publicadas internamente.
;-
2! *oncl"s#o
Tanto desenvolvimento gil como desenvolvimento lean de software ob#etiva melhorar
a ualidade do software e aumentar a produtividade do processo ()=44+? *&@&TT?
+IEE=DA(, ,--.). As duas metodologias aceitam muito bem as mudan!as nos reuisitos, as
uais comumente ocorrem em algum ponto do pro#eto.
8or outro lado, os conceitos lean podem ser aplicados a ualuer atividade dentro de
uma empresa, desde o desenvolvimento de software at a empresa como todo. ('o raro em
empresas ue adotam lean transpor as fronteiras da empresa e levar os conceitos at os seus
fornecedores.
1 principal foco de metodologias geis est em uma colabora!'o muito pr0/ima com
o cliente. A metodologia lean tambm valori2a essa rela!'o, porm valori2a ainda mais a
elimina!'o do desperd%cio.
+egundo <urra7 (,--5), a partir dos estudos de casos apresentados poss%vel concluir
ue implementar prticas lean e geis pode fa2er com ue as empresas e seus produtos
ganhem vantagem competitiva aoB
ter respostas mais rpidas 6s necessidades dos clientes.
redu2ir os custos do desenvolvimento de produto.
fornecer software de alta ualidade, o ue se tradu2 em custos mais bai/os de
manuten!'o.
%efer1ncias
4A++= F=E)1, 9airton Eui2. /9peri1ncias com desenvolvimento (gil! ,--5. ;R- f. 9isserta!'o (<estrado) "
9epartamento de =nstituto de <atemtica e &stat%stica, Iniversidade de +'o 8aulo, +'o 8aulo, ,--5.
C1)(, <i:e. S"cceeding with agile: +oftware development using scrum. 4ostonB Addison"@esle7, ,-;-. HR;
p.
9L4A, Tore? 9=(Q+1L>, Torgeir. &mpirical studies of agile software developmentB A s7stematic review.
Information ,nd Software :echnolog;, (ova =orue, n. P-, p.5JJ"5P., ,--5.
QI+TAD++1(, )W:an. <ean thin=ing applied to s;stem architecting! ,-;;. R, f. Tese (9outorado) "
9epartamento de +chool 1f =nnovation, 9esign And &ngineering, <Xlardalen Iniversit7, DXsterWs, ,-;;.
)=44+, Curt? *&@&TT, +teve? +IEE=DA(, <i:e. :he art of lean software development! +ebastopolB
1T>eill7 <edia, =nc., ,--.. ;HH p.
K(=4&>Q, ). <ean from the :renches: <anaging Earge"+cale 8ro#ects with Kanban. 9allasB The 8ragmatic
4oo:shelf, ,-;;. ;SP p.
<I>>AL, Collin. <ean and ,gile Software Development: A Case +tud7. ,--5. .- f. 9isserta!'o (<estrado) "
Curso de <anagement And &ngineering, 9epartamento de +7stem 9esign And <anagement, <assachusetts
=nstitute 1f Technolog7, <assachusetts, ,--5.
;;
1)(1, T. :o;ota 'rod"ction Software: 4e7ond Earge +cale 8roduction. 8roductivit7 8ress, ;.55.
8&T&>+&(, Kai. Implementing <ean and ,gile Software Development in Ind"str;! ,-;-. J-. f. Tese
(9outorado) " 9epartamento de +chool 1f Computing, 4le:inge =nstitute 1f Technolog7, Karls:rona, ,-;-.
8188&(9=&CK, <ar7? 8188&(9=&CK, Tom. Implementando o desenvolvimento lean de software: 9o
conceito ao dinheiro. 8orto AlegreB 4oo:man, ,-;;. ,5- p.
8>&+<A(, >. +. Software /ngineering: a 8ractitionerTs Approach. S. ed. <cQraw")ill, ,--H.
+)1>&, *ames? @A>9&(, +hane. :he ,rt of ,gile Development! +ebastopolB 1Y>eill7 <edia, =nc., ,--5.
+<=T), Qreg? +=9KL, Ahmed. Becoming ,gile: =n an imperfect world. QreenwichB <anning 8ublications Co,
,--.. H;- p.
+1<<&>D=EE&, =an. /ngenharia de software! .. ed. +'o 8auloB 8earson &ducation do 4rasil, ,-;;. P,. p.
DEAA(9&>&(, Kevin et al. The agile reuirements refiner7B Appl7ing +C>I< principles to software product
management. Information ,nd Software :echnolog;, Amsterdam, n. PJ, p.P5"R-, ,-;-.
;,