Por Sergio Crespo

(1)

Por Sergio Crespo crespo@dcc.ufmg.br

(2)

 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.

(3)

 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:

(4)

 “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).

(5)

 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

(6)

 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.

(7)

 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

(8)

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

(9)

 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.

(10)

(11)

(12)

 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.

(13)

 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?

(14)

 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.

(15)

 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?

(16)

 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.

(17)

 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.

(18)

 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.

(19)

 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.

(20)

 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/od1qw 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

(21)

 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.

(22)

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.

(23)

 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

(24)

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

(25)

 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.

(26)

 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”.

(27)

 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.

(28)

 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.

(29)

(30)

(31)

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/)

(32)