net/publication/266169136
CITATIONS READS
0 141
2 authors:
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Mehran Misaghi on 29 September 2014.
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
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.
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
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.
2.1.2 RUP
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
risco. A metodologia foi criada pela empresa Rational Software Corporation, uma divisão da
IBM desde 2003.
• gerenciamento de requisitos;
• 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.
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:
2.2.1 XP
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.
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;
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.
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.
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
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.
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
desenvolvimento lean de software, com a intenção de melhorar a produtividade de suas
equipes.
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;
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.
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.
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.;
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.
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.
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%
70
60
50
40
Produto
30 Outros
20
10
0
Novembro 2011 Março 2012 Julho 2012
Setembro 2011 Janeiro 2012 Maio 2012
4. Conclusão
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.