Baixe artigo lean e outras Manuais, Projetos, Pesquisas em PDF para Análise de Sistemas de Engenharia, somente na Docsity!
Desenvolvimento lean de software: conceitos e aplicações
Ivan Bosnic (NeoGrid) ivan.bosnic@neogrid.com Mehran Misaghi (Sociesc) mehran@sociesc.org.br 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 são apresentados dois estudos de casos com o objetivo de mostrar quais foram os benefícios alcançados 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 têm vários itens em comum, porém o conceito lean é mais abrangente porque afeta não apenas o processo de desenvolvimento de software, mas a empresa como todo. Palavras chaves: Lean; Metodologias ágeis; 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 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). Ao longo deste trabalho será demonstrado que não se trata de conceitos concorrentes, e sim complementares.
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. 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.
Figura 2: As fases do RUP e a distribuição 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 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. 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 Figura 3 – Ciclo de desenvolvimento do Scrum Fonte: Bassi (2008) 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.
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. Figura 4: Percentagem de funcionalidades de softwares utilizadas na prática Fonte: Adaptação de Hibbs, Jewett e Sullivan (2009)
- 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 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. 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 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.
O time de desenvolvimento do Lotus conseguiu resultados bastante positivos, entre os quais podemos destacar:
- Rapidez na publicação de versões beta do software. Quatro versões beta foram lançadas em um período de tempo em que, com a utilização do modelo em cascata, apenas uma ou duas versões teriam sido liberadas.
- A qualidade das versões melhorou, embora essa melhoria de qualidade não tenha métricas precisas para fazer as devidas comparações. No entanto, a percepção da melhoria se deve principalmente aos retornos positivos vindos dos clientes que utilizam as versões beta.
- Os times começaram 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 definição de desenvolvimento dirigido a planos dentro da sua cultura organizacional durante 20 anos. A iniciativa para a adoção 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 versão 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 adoção de metodologias ágeis.
- A empresa consegue responder às necessidades dos clientes de maneira mais responsiva durante a fase de desenvolvimento, porque constantemente obtém o seu retorno.
- O tempo gastou com testes foi reduzido significativamente, sem afetar a qualidade do produto.
- Houve menos não conformidades detectadas depois da publicação oficial do software. Isso foi possível graças às mudanças no processo de desenvolvimento. Testes são feitos antes com utilização de versões beta publicadas internamente.
4. Conclusão 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 mudanças 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. Não é 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 colaboração muito próxima com o cliente. A metodologia lean também valoriza essa relação, porém valoriza ainda mais a eliminação do desperdício. Segundo Murray (2008), a partir dos estudos de casos apresentados é possível concluir que implementar práticas lean e ágeis pode fazer com que as empresas e seus produtos ganhem vantagem competitiva ao: - ter respostas mais rápidas à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 manutenção. Referências 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. MURRAY, Collin. Lean and Agile Software Development: A Case Study. 2008. 90 f. Dissertação (Mestrado) - Curso de Management And Engineering, Departamento de System Design And Management, Massachusetts Institute Of Technology, Massachusetts, 2008.
