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. So 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 quais foram os benefcios alcanados nas empresas e nos projetos que resolveram adotar a abordagem lean para desenvolvimento de software. Constatou-se ao final deste trabalho que as metodologias geis e lean tm vrios itens em comum, porm o conceito lean mais abrangente porque afeta no apenas o processo de desenvolvimento de software, mas a empresa como todo. Palavras chaves: Lean; Metodologias geis; Scrum; Software

1.

Introduo

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 quando internados em hospitais acuados por doenas, divertem-nos quando brincamos de jogos eletrnicos, e fornecem tantos outros servios crticos para a comunidade. Era de se esperar que, ao se tratar de peas to fundamentais para a nossa vida, os projetos de software estivessem em um nvel de sucesso bastante elevado. No entanto, segundo Hibbs, Jewett e Sullivan (2009), a prtica de desenvolvimento de software tem sido atormentada com taxas de sucesso criticamente baixas durante dcadas. Enquanto isso, as demandas por servios e produtos de informtica no param de crescer e a situao parece entrar em uma situao catica, sem soluo. O que tem trazido certo otimismo o surgimento de metodologias geis, as quais tm demonstrado que possvel obter taxas de sucesso melhores. No trabalho de Bassi (2008) observado que existe uma tendncia de melhoria na qualidade dos projetos, mas ainda assim a situao requer ateno, porque o percentual de projetos que ultrapassam os custos ou o prazo continua quase to elevado quanto antes. Hibbs, Jewett e Sullivan (2009) destacam ainda que as tcnicas lean tm sido cada vez mais aplicadas ao desenvolvimento de software. A ideologia e as tcnicas lean s quais os autores se referem so as mesmas utilizadas no Sistema Toyota de Produo e Sistema Toyota de Desenvolvimento de Produto. Segundo Poppendieck e Poppendieck (2011), o primeiro passo na implementao do desenvolvimento lean de software compreender esses

princpios, porque 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 automobilstica, ao processo de desenvolvimento de software o desafio por trs do desenvolvimento lean de software. Mesmo que a sua definio no imponha tal regra, quase sempre encontramos desenvolvimento lean de software interligado com as metodologias geis. Isso se deve ao fato de vrios conceitos serem compartilhados por ambas as metodologias. Os mtodos geis obtm sucessos organizacionais ao focar na entrega de valor e na diminuio de custos (SHORE; WARDEN, 2008). Ao longo deste trabalho ser demonstrado que no se trata de conceitos concorrentes, e sim complementares. 2. Metodologias de desenvolvimento de software

Diversas divises de metodologias de desenvolvimento de software podem ser encontradas na literatura. O presente trabalho divide os tipos de desenvolvimento de software em trs 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 prprio nome sugere, o desenvolvimento de software dirigido a planos est focado em planejar tudo desde o incio do projeto (PETERSEN, 2010). Para que esse planejamento seja possvel, esta abordagem se apoia em uma srie de documentos (artefatos) que so gerados na fase inicial do projeto e que acompanham o mesmo durante todo o seu ciclo de vida. Alm disso, ao final de cada fase so produzidos alguns artefatos cuja funo comprovar que a mesma foi finalizada. Somente ento que deve ser iniciado o trabalho da prxima fase do processo. 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 representao grfica do modelo em cascata e de suas fases.

Figura 1 O modelo em cascata Fonte: Adaptao de Sommerville (2010)

O principal objetivo desta abordagem prover uma estrutura para execuo do processo de desenvolvimento de software. No entanto, o processo no ocorre de forma linear, mas sim envolve a realimentao 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. Segundo Petersen (2010), outro exemplo de processo dirigido a planos RUP (Rational Unified Process). Este processo mais flexvel quando se trata da sequncia em que as disciplinas so executadas. Isso significa que as atividades de engenharia de software definidas pelo processo so executadas durante todo o ciclo de vida do mesmo. 2.1.1 RUP

RUP possui quatro fases: concepo, elaborao, construo e transio. A Figura 2 ilustra as disciplinas e as fases que fazem parte do RUP. De acordo com a Figura 2, possvel observar que todas as disciplinas de engenharia de software propostas por RUP participam de quase todas as fases, porm com uma intensidade diferenciada.

Figura 2: As fases do RUP e a distribuio do volume de atividades em cada uma delas Fonte: Bassi (2008)

2.2

Desenvolvimento gil de software

De acordo com Dyba e Dingsoyr (2008), o desenvolvimento gil de software representa o maior avano na engenharia de software quando comparado s abordagens dirigidas a planos. Segundo Bassi (2010), a indstria de software se baseou, durante muito tempo, em mtodos tradicionais de desenvolvimento de software. Esses mtodos vinham apresentando um grande nmero de fracassos, o que levou alguns lderes 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 benefcios para o processo de desenvolvimento de software (SMITH; SIDKY, 2009). Esse documento est disponvel na Internet atravs do endereo http://agilemanifesto.org/. As quatro premissas do manifesto so: Indivduos e iteraes so mais importantes do que processos e ferramentas. Software funcionando mais importante do que documentao completa. Colaborao com o cliente mais importante do que negociao de contratos. Adaptao a mudanas mais importante do que seguir o plano inicial. Os itens do lado esquerdo (destacados em negrito) so os que representam mais importncia para um processo gil, porm os itens do lado direito no podem ser ignorados. Ao contrrio, eles devem ser levados em considerao e valorizados, sendo que o seu valor menor quando comparados com os itens do lado esquerdo (SMITH; SIDKY, 2009).

A partir das definies do manifesto, surgiram diversas metodologias de desenvolvimento de software, entre as quais destacamos XP e Scrum. 2.2.1 XP

Segundo Sommerville (2011), Extreme Programming (XP) um dos mtodos geis mais utilizados. Esta abordagem foi desenvolvida para levar em considerao as melhores prticas de desenvolvimento de software, como o desenvolvimento iterativo. Segundo Smith e Sidky (2009), em comparao com outras tcnicas geis, XP focado mais na aplicao de conceitos tcnicos. Ainda de acordo com os autores, no possvel definir uma tcnica gil como sendo a melhor, tudo depende do que funciona melhor no ambiente da empresa e dentro de suas restries. Uma das principais caractersticas de XP o fato de os testes serem criados antes mesmo de se escrever o cdigo fonte na linguagem de programao. A codificao, por sua vez, feita em duplas, tcnica chamada de pair programming. 2.2.2 Scrum

Figura 3 Ciclo de desenvolvimento do Scrum Fonte: Bassi (2008)

O mtodo 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 construo de um sistema pedao por pedao, ou seja, primeiro um pedao 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 dinmico e pode ser alterado e/ou priorizado conforme as necessidades do cliente. O desenvolvimento em si ocorre em iteraes chamadas sprints e que normalmente duram de uma a quatro semanas. Antes de iniciar uma sprint, a equipe se rene, elenca os requisitos que sero trabalhados (requisitos so escolhidos de acordo com as prioridades de negcio estabelecidas) e depois esses itens so quebrados em tarefas de implementao de menor complexidade (BASSI, 2008). A Figura 3 demonstra todo o ciclo de desenvolvimento do Scrum. 2.3 Desenvolvimento lean de software

De acordo com Shore e Warden (2008), as ideias nas quais se baseia o desenvolvimento lean de software tm 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 Produo 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 prprios 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 no conceitos lean, Gustavsson (2011) destaca que mtodos geis so aplicados apenas ao desenvolvimento de software, enquanto lean um conceito muito mais abrangente. Segundo o autor, a filosofia lean no apenas um conjunto de ferramentas. Ela afeta todos os setores da empresa, desde os recursos humanos at o marketing. A partir desse trabalho foram estabelecidos os sete princpios do desenvolvimento lean de software (POPPENDIECK; POPPENDIECK, 2011). 2.3.1 Princpio um: Eliminar o desperdcio

De acordo com Ohno (1988), o Sistema Toyota de Produo tem como um dos seus focos a eliminao total do desperdcio. O autor afirma que tudo o que no agrega valor para o cliente deve ser removido do processo. Segundo Hibbs, Jewett e Sullivan (2009), esta categoria abrange uma srie de conceitos que devem ser analisados para que seja possvel compreender de que forma os desperdcios apontados no Sistema Toyota de Produo podem ser identificados no processo de desenvolvimento de software. Defeitos: so representados pelos defeitos em si. Defeitos causam o retrabalho custoso, o qual no agrega valor ao produto. O desenvolvimento lean de software tem como um dos seus objetivos prevenir os defeitos. Superproduo: funcionalidades desnecessrias. O custo de um software no est ligado apenas a escrever o cdigo fonte. Esse cdigo 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 usurio,

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 no so usadas ou so usadas raramente (veja Figura 4). Isso constitui um grande desperdcio de recursos ao longo do tempo.

Figura 4: Percentagem de funcionalidades de softwares utilizadas na prtica Fonte: Adaptao de Hibbs, Jewett e Sullivan (2009)

Estoque: tarefas concludas parcialmente. Aqui podemos considerar requisitos analisados, mas ainda no implementados, cdigo que ainda no foi testado ou erros que ainda no foram corrigidos. Dentro da filosofia lean no se admite o acmulo de tarefas no concludas. Em vez disso, procura-se adotar o fluxo unitrio que faz com que a tarefa seja concluda o quanto antes. Movimentao: alternar entre tarefas. As interrupes e o trabalho alternado entre diferentes atividades prejudicam 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 requisitos passados. Qualquer interrupo faz com que esse processo seja reiniciado. Este um dos motivos por que o fluxo unitrio to produtivo. Processamento adicional: processos desnecessrios. Esse tipo de processo constitui o mais puro desperdcio. Ele atrapalha a produtividade sem agregar valor algum ao produto final. Um exemplo deste tipo de processo a criao de documentao que no utilizada por ningum, ou at execuo 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 dvidas e esclarecer alguns requisitos. Se esses participantes no

estiverem disponveis, haver atrasos na entrega, ou a implementao ser feita sem os devidos esclarecimentos, o que na maioria das vezes gerar retrabalho. Esse retrabalho uma das formas mais comuns de desperdcio no processo de desenvolvimento de software e deve ser evitado a qualquer custo. 2.3.2 Princpio dois: Integrar qualidade

Ohno (1988) afirma que no possvel inspecionar a qualidade de um produto ao fim da linha de produo. 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, prope uma filosofia diferente. Ao invs de criar sistemas para controlar os defeitos (filas de no conformidades a serem solucionadas), o processo deve ser focado na eliminao total de defeitos e na consequente eliminao de filas de controle (POPPENDIECK; POPPENDIECK, 2011). Alcanar tal grau de maturidade no processo s possvel com a utilizao de recursos como testes unitrios e integrao contnua, entre outros. 2.3.3 Princpio trs: 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 codificao. Autores destacam que o desenvolvimento de software um processo de criao de conhecimento e que o projeto detalhado, embora deva ser esboado antes, se firma apenas durante a implementao do cdigo. Bassi (2008) aponta que as lies devem ser extradas das experincias 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 prxima vez que se tornar necessrio. As pessoas no devem perder tempo aprendendo algo que j foi estudado e colocado em prtica por outros membros da equipe. 2.3.4 Princpio quatro: Adiar comprometimentos

Hibbs, Jewett e Sullivan (2009) afirmam que as melhores decises so tomadas quando dispomos de maior quantidade de informao possvel. Se uma determinada deciso no 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 principalmente tomada de decises irreversveis. As decises reversveis devem ser tomadas antes, porque elas podem ser facilmente modificadas. 2.3.5 Princpio cinco: Entregar rpido

Kniberg (2011) ensina que devemos comear 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 rpidas e frequentes de software funcionando. De acordo com Hibbs, Jewett e Sullivan (2009), a importncia de entregar rpido 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

Princpio seis: Respeitar as pessoas

Segundo Poppendieck e Poppendieck (2011), pessoas pensadoras e engajadas no projeto so a maior e a mais sustentvel 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 tambm permitir que elas possam encontrar maneiras de melhorar os processos. 2.3.7 Princpio sete: Otimizar o todo

Aperfeioar um processo local quase sempre feito custa do fluxo de valor no processo como todo. Isso ocorre quando as mudanas so feitas sem levar em considerao o todo. Isso conhecido como subotimizao, e uma organizao que implementa conceitos lean sempre tenta evit-la. 3. Estudos de caso

O trabalho de Murray (2008) traz dois estudos de caso onde o autor analisou o processo de transio de uma metodologia dirigida a planos para uma metodologia gil/ lean. As empresas escolhidas, IBM e Kronos, estiveram presas aos seus mtodos tradicionais durante anos e foram escolhidas propositalmente, para que as implicaes culturais tambm pudessem ser avaliadas. 3.1 IBM

Na IBM, o estudo de caso foi conduzido no produto Lotus Domino, quando o mesmo passou de um mtodo tradicional em cascata para um mtodo gil de desenvolvimento de software. Lotus Domino um produto corporativo de sucesso que est no mercado h mais de quinze anos. Nos primeiros dias, quando a verso 1.0 ainda estava sendo desenvolvida, o processo de compilao e empacotamento do software levava um dia inteiro. Na poca, o software tinha 180 mil linhas de cdigo. A lentido do processo se devia, entre outras coisas, baixa capacidade computacional do hardware daquela poca. Durante o tempo, a base de cdigo fonte cresceu significativamente, em tamanho e em complexidade. Atualmente o software possui mais de 22 milhes de linhas de cdigo fonte. O time de desenvolvimento dedicado cresceu de 10 pessoas em 1997 para 40 em 2007. O tempo mdio para o lanamento de uma nova verso do produto era de um ano e meio. Embora a qualidade do produto fosse satisfatria, havia uma preocupao de que a empresa no era suficientemente responsiva s necessidades dos clientes e que alguns dos recursos do software no atendiam s suas expectativas. Para lidar com esses problemas, o arquiteto responsvel sugeriu a adoo de mtodos geis de desenvolvimento de software, incluindo lean. Os objetivos principais da transio eram: Respostas rpidas s necessidades dos clientes. Reduzir desperdcio no produto. Gerar verses de software de alta qualidade para obter o retorno rpido do cliente.

O time de desenvolvimento do Lotus conseguiu resultados bastante positivos, entre os quais podemos destacar: Rapidez na publicao de verses beta do software. Quatro verses beta foram lanadas em um perodo de tempo em que, com a utilizao do modelo em cascata, apenas uma ou duas verses teriam sido liberadas. A qualidade das verses melhorou, embora essa melhoria de qualidade no tenha mtricas precisas para fazer as devidas comparaes. No entanto, a percepo da melhoria se deve principalmente aos retornos positivos vindos dos clientes que utilizam as verses beta. Os times comearam a trabalhar de forma mais integrada, o que os tornou mais fortes e coesos. Testes automatizados tiveram uma melhoria significativa, por causa da filosofia das metodologias geis. Em torno de 60% de novos recursos do software tinham os seus testes completamente automatizados. Houve um aumento de produtividade percebido por todos os membros da equipe. 3.2 Kronos

Kronos uma empresa de desenvolvimento de software bem sucedida e que desenvolve sistema para gerenciamento de recursos humanos. Assim como a IBM, eles tinham uma forte definio de desenvolvimento dirigido a planos dentro da sua cultura organizacional durante 20 anos. A iniciativa para a adoo de metodologias geis veio a partir do diretor de tecnologia da empresa. Para ele, simplesmente havia algo de errado no processo de desenvolvimento de software da empresa. O ciclo de desenvolvimento de uma verso nova do produto levava um ano, onde seis meses eram gastos em desenvolvimento propriamente dito e outros seis meses em testes. Os principais resultados obtidos pela empresa foram: A quantidade de novos recursos adicionados ao produto superou as expectativas. Na maior parte isso se deve ao fortalecimento dos empregados conquistado durante a adoo de metodologias geis. A empresa consegue responder s necessidades dos clientes de maneira mais responsiva durante a fase de desenvolvimento, porque constantemente obtm o seu retorno. O tempo gastou com testes foi reduzido significativamente, sem afetar a qualidade do produto. Houve menos no conformidades detectadas depois da publicao oficial do software. Isso foi possvel graas s mudanas no processo de desenvolvimento. Testes so feitos antes com utilizao de verses beta publicadas internamente.

10

4.

Concluso

Tanto desenvolvimento gil como desenvolvimento lean de software objetiva melhorar a qualidade do software e aumentar a produtividade do processo (HIBBS; JEWETT; SULLIVAN, 2009). As duas metodologias aceitam muito bem as mudanas nos requisitos, as quais comumente ocorrem em algum ponto do projeto. Por outro lado, os conceitos lean podem ser aplicados a qualquer atividade dentro de uma empresa, desde o desenvolvimento de software at a empresa como todo. No raro em empresas que adotam lean transpor as fronteiras da empresa e levar os conceitos at os seus fornecedores. O principal foco de metodologias geis est em uma colaborao muito prxima com o cliente. A metodologia lean tambm valoriza essa relao, porm valoriza ainda mais a eliminao do desperdcio. Segundo Murray (2008), a partir dos estudos de casos apresentados possvel concluir que implementar prticas lean e geis pode fazer com que as empresas e seus produtos ganhem vantagem competitiva ao: ter respostas mais rpidas s necessidades dos clientes. reduzir os custos do desenvolvimento de produto. fornecer software de alta qualidade, o que se traduz em custos mais baixos de manuteno. Referncias
BASSI FILHO, Dairton Luiz. Experincias com desenvolvimento gil. 2008. 170 f. Dissertao (Mestrado) Departamento de Instituto de Matemtica e Estatstica, Universidade de So Paulo, So 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, Hkan. Lean thinking applied to system architecting. 2011. 72 f. Tese (Doutorado) -

Departamento de School Of Innovation, Design And Engineering, Mlardalen University, Vsters, 2011. HIBBS, Curt; JEWETT, Steve; SULLIVAN, Mike. The art of lean software development. OReilly Media, Inc., 2009. 144 p. KNIBERG, H. Lean from the Trenches: Managing Large-Scale Projects with Kanban. Dallas: The Pragmatic Bookshelf, 2011. 165 p. MURRAY, Collin. Lean and Agile Software Development: A Case Study. 2008. 90 f. Dissertao (Mestrado) Curso de Management And Engineering, Departamento de System Design And Management, Massachusetts Institute Of Technology, Massachusetts, 2008. Sebastopol:

11

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 Practitioners Approach. 6. ed. McGraw-Hill, 2004. SHORE, James; WARDEN, Shane. The Art of Agile Development. Sebastopol: OReilly 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. So 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.

12