Por Sergio Crespo
crespo@dcc.ufmg.br

 A filosofia "Lean Thinking" (ou
"Pensamento Enxuto") nasceu em
meados dos anos 90 com o
lançamento do best seller "The
Machine That Changed the World :
The Story of Lean Production". Os
princípios de demanda puxada (pull
systems), just-in-time, qualidade
total, teoria das restrições, melhoria
contínua e flexibilidade aplicados
na indústria japonesa, mais
precisamente na Toyota e
conhecidos como Toyota Way
inspiraram também a indústria de
software e fez surgir a abordagem
do Lean Software Development.

 Mary e Tom Poppendieck (gurus de Lean
voltado a TI, defensores do agile e autores do
livro: "Lean Software Development - An Agile
Toolkit" que mostra como os princípios Lean
podem ser aplicados em abordagens de
desenvolvimento de software ágil), definiram
assim o Lean:

 “Entregar, aumentando continuamente valor para
o cliente;
 Continuamente diminuir o esforço gasto;
 No prazo mais curto possível;
 Com a melhor qualidade possível a jornada, não
um destino. “
 De forma mais concisa, o Lean Manufacturing é
“uma filosofia que quando implementada reduz o
tempo desde o pedido até à entrega ao cliente
eliminando fontes de desperdício no fluxo de
produção” (Liker, 1996).
Liker, J. (1996). Becoming Lean. New York:Free Press

 Podemos ainda definir desperdício (Guedes,
2011) como “alguma interrupção
desnecessária, falta de coordenação, trabalho
desnecessário, ou redundâncias que não
adicionam qualquer valor ao cliente” (Kleiner,
2005).
Jorge F. Guedes, Introdução de conceitos Lean às Tecnologias de
Informação: um caso de estudo em Banca, dissertação de mestrado,
Faculdade de Engenharia da Universidade do Porto , 2011
Kleiner, A. (2005). Leaning toward utopia.

 Segundo o estudo CHAOS, conduzido pelo
“Standish Group” em 1995, apenas 29% dos
projectos de IT conseguem ser bem
sucedidos, sendo que 53% conseguem ser
completados com atrasos ou aumentos de
orçamento e 18% simplesmente falham. Estes
valores são já muito superiores aos 16% de
sucesso em 1994, com 53% de deslizes e 31%
de falhas.

 O fraco planejamento das aplicações deve
também ser considerado visto que, segundo o
mesmo estudo (Standish Group, 2004), 64% das
aplicações desenvolvidas não são usadas ou são
usadas raramente.
 Um outro estudo publicado em 2001 indica que
apenas 5% do código era útil ou até mesmo
usado (Cohen, Larson and Ware, 2001). Pensando
que cada linha de código desenvolvida tem um
custo, somado ao custo do desenho,
implementação e manutenção do mesmo,
tornando estes dados realmente preocupantes.
Cohen, D., Larson, G. & Ware, B. (2001). Improving Software Investments
through Requirements Validation

Tentando resumir em uma frase, Lean é um princípio
ágil cujo foco é cortar a "gordura" do processo de
software, focando na eliminação de desperdícios.
Princípios Lean aplicados ao
software:
1. Elimine Desperdícios
2. Inclua a Qualidade no Processo
3. Crie Conhecimento
4. Adie Decisões e Comprometimentos
5. Entregue o quanto antes
6. Respeite as Pessoas e "Empower" a equipe
7. Otimize o Todo
http://goo.gl/od1q

 Princípio #1 – Eliminar desperdícios
 Desperdícios: tudo aquilo que não agrega valor
para cliente final e que não são percebidos pelo
cliente.
 Exemplo: passos extras, processo pesado e
rígido, burocracia, documentação que nunca vai
ser lida, que está na prateleira juntando poeira -
não necessária, etc. Outro tipo de desperdício
são trabalhos parcialmente prontos, tudo que
começa e não termina, funcionalidades extras
que não serão utilizadas, etc.
http://goo.gl/od1q

http://goo.gl/od1q

 Requisitos, especificados muito cedo que
perdem sua credibilidade, eficácia e
compromete a usabilidade do sistema.
 Trabalho incompleto (“em-progresso”) -
Parcialmente feitos Trabalhos parcialmente
iniciados / terminados tendem a se tornar
obsoletos.
http://goo.gl/od1q

 Burocracia, atividades, métricas, etc que não
geram valor e que diminui o tempo de
resposta.
 Você alguma vez já se perguntou, toda
aquela documentação e papelada é realmente
necessária?
http://goo.gl/od1q

 80% das funcionalidades implementadas não
são utilizadas.
 20% das funcionalidades é que são realmente
úteis.
 Código não-utilizado introduz complexidade
e a complexidade é um inimigo da
manutenção. Mais código para ser mantido.
Mais testes para serem realizados. Mais
documentos de especificação para serem
criados. Se o código não é necessário agora
colocá-lo no sistema é desperdício.
http://goo.gl/od1q

 Corrida de revezamento deve ser substituída
pela equipe multi-funcional.
 Quanto maior os handoff’s maior é a perda
de conhecimento. Organizar pessoas em
múltiplos projetos é outra forma de
desperdício.
 Quanto tempo se perde para parar uma
determinada atividade e iniciar outra,
relembrar onde parou, concentrar-se e
finalmente produzir algo?
http://goo.gl/od1q

 Atrasos na entrega, atrasos em geral são puro
desperdício e irão gerar aumento do custo do
projeto.
 Em muitos casos, atrasos são apenas a ponta do
iceberg para problemas muito maiores.
 Espera: Um dos maiores desperdícios no
desenvolvimento de Software é a espera para que
as coisas aconteçam. Espera para o início do
projeto, pela montagem da equipe, espera pela
produção de documentação extensa, espera por
processo de revisão ou aprovação, espera para
testar, etc. Veja, analise o que deve ser mantido,
o que agrega valor e o que é puro desperdício.
http://goo.gl/od1q

 Equipes ágeis se esforçam ao máximo para
evitar defeitos.
 “Inspecionar para prevenir defeitos é bom;
 Inspecionar para encontrar defeitos é
desperdício” -- Shigeo Shingo
 Defeitos (Bugs) não agregam valor, não
satisfazem o cliente, e custam muito muito
caro.
http://goo.gl/od1q

 Tempo e esforço gasto para encontrar
informações.
 Equipes ágeis valorizam a conversa e por isso
trazem o cliente para perto, não devemos
perder tempo lendo páginas e páginas de um
documento para encontrar uma informação
que ao mesmo tempo por estar na forma
escrita muitas vezes são imprecisas e pode
trazer mais dúvidas do que resolver o
problema.
http://goo.gl/od1q

 Qualidade é inegociável. Entregue qualidade
intrínseca e explícita aos seus clientes, se
eles perceberem isso, significa que foi uma
entrega de qualidade.
 Um produto possui integridade percebida
quando o cliente o experimenta e diz: Isso!
Era exatamente isso que eu queria!
 Software com integridade percebida possui
boas arquiteturas, possuem um alto nível de
usabilidade e facilidade de uso, são fáceis de
dar manutenção, de adaptar e de estender.
http://goo.gl/od1q

 Criar conhecimento e partilhá-lo sempre que há alguma “lição
aprendida”. Desta forma, não só a mesma pessoa não comete o
mesmo erro duas vezes, como há partilha dessa experiência para
outros não cometerem o mesmo erro. Desta forma é possível
evitar erros e defeitos, bem como contribuir para uma maior
formação dos colaboradores.
Práticas sugeridas para promover o conhecimento:
 Ciclos de feedback e inspeções e adaptações;
 Desenvolvimento iterativo;
 Equipes pequenas;
 Treinamentos e Mentoring;
 Criação e utilização de standards, guidelines e qualquer outro
artefato;
 Code Reviews;
 Meios de compartilhamento de informações como um Blog ou Wiki;
http://goo.gl/od1q
Jorge F. Guedes, Introdução de conceitos Lean às Tecnologias de Informação:
um caso de estudo em Banca, dissertação de mestrado, Faculdade de
Engenharia da Universidade do Porto , 2011

 O principal conceito deste princípio é
diminuir as incertezas retardando as decisões
até que possam serem feitas com base em
acontecimentos mais firmes, previsíveis e
conhecidos. Decisões tardias tendem a ser
mais acertadas porque as melhores decisões
são feitas baseadas em fatos, e não em
suposições ou especulações.
http://goo.gl/od1q

Sem entregas rápidas não é possível colher
feedback.
Sem entregas rápidas não é possível aprender
com erros.
Velocidade na entrega garante que o cliente
receberá o que ele precisa hoje e não o que ele
precisava ontem.
http://goo.gl/od1q

 Envolver os desenvolvedores nos detalhes das
decisões técnicas é fundamental para o
atingimento da excelência.
 Práticas sugeridas para promover o
capacitação/agregação do time:
◦ Auto-gestão
◦ Trabalho em equipe
◦ feedback
http://goo.gl/od1q

Otimizar desde o começo até o final:
 Utilize Métricas
 Diminua o número de métricas de
desempenho individual mas valorize o
desempenho da equipe.
Meça :
 Tempo de ciclo +Mapa de Fluxo de Valor
 ROI + Modelo de Lucros e Perdas
 Satisfação do Cliente + Entendimento das
suas necessidades
http://goo.gl/od1q

 Segundo Fadel e Silveira (2010), a metodologia
Lean utiliza técnicas de produção puxada (pull)
para agendar o trabalho e são dotadas de
mecanismos com sinalizações locais, os quais
ajudam os outros desenvolvedores a identificarem
o trabalho que precisa ser realizado. A sinalização
local é feita através de gráficos visuais, reuniões
diárias, integrações frequentes e testes
automatizados.
 No desenvolvimento de software Lean, esta técnica
de produção puxada é correspondente à entrega
de versões refinadas e incrementais do software
em intervalos de tempo regulares.
FADEL, Aline Cristine. SILVEIRA, Henrique da Mota. Metodologias ágeis no contexto de
desenvolvimento de software: XP, Scrum e Lean. Limeira, 2010. Disponível
em:<http://www.ceset.unicamp.br/liag/Gerenciamento/monografias/Lean%20Agil_v8.pdf >
Acesso em: 18 jun 2012.

 Kanban é um termo de origem japonesa e significa
literalmente “cartão” ou “sinalização”. É um
conceito relacionado com a utilização de cartões
(post-it e outros) para indicar o andamento dos
fluxos de produção em empresas de fabricação em
série. Nesses cartões são colocadas indicações
sobre uma determinada tarefa, por exemplo, “para
executar”, “em andamento” ou “finalizado”.

 O Kanban é definido como um processo adaptativo
de produção, extremamente simples e altamente
eficiente. Essa definição é ótima pois sintetiza bem
o que ele é. Primeiro ele é um processo, podemos
entender processo como um conjunto de passos
que cooperam para um objetivo definido, segundo,
ele é adaptativo, quer dizer que ele foi feito para se
adaptar a qualquer realidade, qualquer tipo de
produção.

 A utilização de um sistema Kanban permite um controle
detalhado de produção com informações sobre quando,
quanto e o que produzir. O método Kanban foi
inicialmente aplicado em empresas japonesas de
fabricação em série e está estreitamente ligado ao
conceito de “just in time”.
 Just in time (JIT) significa “no momento certo”. É um
modelo japonês que procura eliminar estoques e
agilizar a produção. Armazena-se o mínimo de matéria
prima em estoque, apenas em quantidade que permita
manter o processo produtivo no momento. O número
de fornecedores também é reduzido para o modelo
funcionar de forma eficiente.

http://goo.gl/t8UMb

TargetProcess
Free License: Free for Teams of 5 Users or less
Commercial
: http://www.targetprocess.com/Buy_TargetProcess.aspx
View Video
LeanKit Kanban
Free License: Free for 5 Users/1Board
Commercial : http://leankitkanban.com/Home/PricingAndSignup
Hansoft
Free License: Free for 2 Users and unlimited projects
Commercial : http://www.hansoft.se/download/license-fees.html
View Video
Kanbanery
Free License: 1 Board, 2 Users, 1GB space
Commercial : http://kanbanery.com/pricing
View Video
AgileZen Free License: Free for 1 Project
Commercial : http://agilezen.com/pricing
View Video
JAM Circle Free License: Free Commercial : Free Download
(http://sourceforge.net/projects/jamcircle/)
Kanban tools