O conceito “Lean Production” surgiu com
o lançamento do livro “The Machine That Changed the World” em 1990 quando
a Toyota era da metade do tamanho da GM (General Motors). Hoje em dia a Toyota
está passando a GM como maior montadora do mundo e se posiciona no mercado como
a empresa mais bem sucedida nos últimos cinquenta anos. O livro trata de um sistema
de produção enxuta (Lean Production System) com conceitos que tornaram-se a
base para esse sucesso duradouro.
Esse
modelo de produção enxuta (Lean production) vai além da indústria automotiva,
os princípios do pensamento enxuto são universais e têm sido aplicados com
sucesso em muitas áreas; na indústria de software esse modelo é chamado Lean
Software Development, onde seus criadores Mary e Tom Poppendieck (defensores de
agile e maiores autores de livros de Lean Software) apresentam essa abordagem
voltada para o processo desenvolvimento de software, detalhado a seguir.
O
desenvolvimento de software lean é baseado em sete princípios, nos quais nem os
próprios autores entram em um concenso. Em cada novo livro publicado os
princípios são ligeiramente modificados, podendo ser novos princípios e/ou em
alguns casos apenas alteração dos nomes e descrição dos detalhes. Embora a base
do processo lean seja os sete princípios, (analogia ao número mágico: The Magic
Number Seven), atualmente na página oficial de Tom e Mary são apresentados oito
princípios. No entanto vou detalhar aqui apenas os sete princípios apresentados
em seu primeiro livro: “Lean Software Development: An Agile Toolkit.
1. Elimine
desperdícios (Eliminate waste): O
objetivo é entregar exatamente aquilo que o cliente quer, nem mais nem menos do
que exatamente o que o cliente quer. Para isso são apresentados alguns pontos
nos quais ensinam a identificar esses desperdícios (Learning to see
waste). Abaixo são mostrados esses
pontos usando como exemplo as práticas de XP (Extreme Programming).
o Funcionalidades extras: Desenvolva apenas as estórias
de hoje;
o Requisitos: Estórias são detalhadas somente na iteração
atual (não detalhar estórias antes de entrarem no planejamento da iteração);
o Passos extras: Codifique diretamente das estórias;
esclareça as dúvidas diretamente com clientes (stakeholder);
o Encontrar informação: Acomode todos do projeto na
mesma sala, incluindo clientes (stakeholder);
o Defeitos não encontrados por testes: Teste primeiro,
ambos desenvolvedores e clientes testam;
o Espere, inclua clientes (stakeholder): Faça pequenas
entregas;
o Troca de tarefas: Desenvolvedores trabalham
diretamente com clientes(stakeholder)
2. Crie conhecimento (Amplify learning/ Learn first/ Create Knowledge): Consiste
em criar o máximo de conhecimento sobre o que está sendo desenvolvido, não só
em suas fases iniciais, como é sugerido em cascata(requisitos definidos), mas o
aprendizado deve ser constante, sendo ele antes, durante e depois do desenvolvimento.
Esse princípio visa trazer à tona todo conhecimento absorvido pelos integrantes
do projeto, o conhecimento tácito deve se tornar explicíto e fazer parte da
organização como um todo. O ponto principal por parte das empresas, seria entender que aprender sobre o produto em
desenvolvimento é importante mas codificar conhecimento para uso futuro é
essencial.
3. Adie decisões (Delay/Defer commitment): Adiar decisões importantes
para o mais tarde possível no projeto. Com essa prática, toda decisão que tem
impacto irreversível no projeto é feita
com muito mais maturidade, dentro do processo como um todo. Uma decisão de
arquitetura por exemplo, pode mudar todo comportamento do sistema, quanto mais
distante decisões importantes de arquiteturas forem tomadas mais assertivas
elas serão. Isso não significa não ter comprometimento com o projeto, essas
decisões devem ser tomadas por time e/ou pessoas experientes, com domínio tanto
na tecnologia que está sendo usada quanto no produto e/ou área de negócio do sistema
que está sendo desenvolvido; Esse time experiente e comprometido, saberá até
quando manter uma decisão importante em aberto. Um mito conhecido é afirmar que
seguir a risca um planejamento é ter comprometimento. O planejamento deve ser
aberto a mudanças, pode-se criar um plano de alto nível e deixar os detalhes em
aberto, para que as decisões importantes sejam tomadas na hora certa, isso é, planejar cuidadosamente e o comprometer-se com
moderação.
4. Entregue rapidamente (Deliver
fast): Esse princípio significa fazer
entregas o mais rápido possível, como exemplificado nessa frase do livro
“Implementing Lean”: “The moral of this
story is that we need to figure out how to deliver software so fast that our
customers don’t have time to change their minds.” Nós precisamos entregar software tão rápido que nossos
clientes não tenham tempo para mudar de opinião (mudanças durante o projeto). No
entanto fazer entregas rápidas não significa baixa qualidade, é possível fazer
rápidas entregas com excelente qualidade. Segundo os autores existem 2 maneiras
de fazer entregas com qualidade, lenta com máximo de cuidado e atenção aos
mínimos detalhes ou rápida onde as pessoas têm autonomia para aplicar melhorias
em seus processos. Empresas com pensamento lean trabalham com padrões de
qualidade, mas essas normas existem porque eles incorporam as melhores práticas
em como fazer com excelência seus respectivos trabalhos.
5. Dê poder ao time(Empower the team/ Respect People/ Energize Workers): Esse
princípio nada mais é do que dar importância a quem está fazendo o trabalho em
si. Essas são as melhores pessoas para sugerir melhorias que resulta no aumento
de produtividade e excelência do time. Investir no conhecimento para o
desenvolvimento profissional do time também é uma prática importante nesse
princípio, quanto mais as pessoas obtiverem conhecimentos que agreguem valor ao
processo, maior será o retorno pra empresa. Criar maturidade do time é confiar
em sua capacidade de ser auto-gerenciável. Confiar na opinião do profissional
que está na linha de frente do trabalho, é dar ferramentas para que ele próprio
encontre maneiras de colocar em prática essas melhorias, pois não existe nenhum
processo tão bom, que não possa ser melhorado.
6. Inclua integridade (Build Integrity In/ quality in): Um mito existente é
que teste é feito para encontrar defeitos, sendo que na verdade teste é para
prevenir defeito. Quando o conceito de construir o software com integridade e
qualidade desde o início é aplicado, testar entra em primeiro plano (test
first). Hoje em dia, existem metodologias de desenvolvimento orientada a testes,
como o TDD que tem como objetivo diminuir o número de defeitos inseridos
durante a fase de desenvolvimento. Construir com qualidade desde o início não
exclui a necessidade de testes, até mesmo em fases finais do desenvolvimento,
mas simplesmente oferece meios de diminuir drasticamente os defeitos
encontrados em fases finais do projeto. Desenvolver com foco total em qualidade
é absorver a cultura de que tudo deve ser feito para prevenir defeitos e não
para encontrá-los.
7. Otimize o todo (See the Whole/ Optimize the Whole): Otimizar o todo
é olhar para toda organização quando uma decisão de negócio for tomada. Essas
decisões abrangem sistemas que serão desenvolvidos e/ou atualizados. Um exemplo
real de um estudo de caso aconteceu na Fujitsu, que recebia muitas ligações da BMI
em seu help desk, para manutenção e suporte às suas impressoras. Após um estudo
interno foi descoberto que grande parte das ligações eram relacionadas a
impressoras de modelos antigos e convenceram a BMI a trocar para novos modelos
de impressoras. Após as novas impressoras serem colocadas em uso, o número de
ligações caiu em 40%, seria um caso de sucesso se a Fujitsu tivesse se atentado
ao fato de que a sua receita também era composta
pela quantidade de ligações recebidas em
seu help desk; Com a queda de ligações a receita foi igualmente reduzida. Esse fato está relacionado
ao mito de otimizar pela decomposição, onde os departamentos trabalham de
maneira completamente independente, essa prática tende a tomada decisões como
essa feita na Fujitsu, onde o lucro da área de vendas aumentou mas o rendimento
que deixou de entrar pelo help desk teve impacto significativo na receita de
toda compania.
Do meu ponto de vista, o maior problema que vem acontecendo hoje em dia
é que muitas pessoas confundem os conceitos de ágil com o seu real significado. Já ouvi empresas falando que
aplicam “técnicas ágeis” com paradgmias antigos e outras com bastante desleixo em
relação a padrões e normas de qualidade. Como afirmado pelos autores, mas que
ao meu ver se aplica todas as metodologias ágeis, “Lean Software Development is very
disciplined. It’s just that you
look at discipline a bit differently.” O Desenvolvimento de software lean (ágil) é sim
bastante disciplinado, mas é apenas uma forma um pouco diferente de disciplina.
Ø Poppendieck,
Tom/ Mary , Implementing Lean Software Development, 1ª edição, Addison-Wesley
Professional , Setembro 2006
Ø Poppendieck,
Tom/ Mary , Lean Software Development - An Agile Toolkit, 1ª edição,
Addison-Wesley Professional , Maio 2003
