Conheça essa filosofia originária da indústria automobilística do Japão que promete tazer mais eficiência para o desenvolvimento de software...
Lean, do inglês "enxuto", é uma filosofia de gestão focada em maximizar o valor entregue ao cliente enquanto minimiza qualquer forma de desperdício. Originada no Sistema Toyota de Produção (STP) nas décadas de 1940 a 1970, essa abordagem foi sistematizada no Ocidente principalmente pelo trabalho de Womack e Jones, que cunharam o termo "Lean Production" no livro The Machine That Changed the World (WOMACK; JONES; ROOS, 1990).
A ideia central é simples, mas poderosa: toda atividade que não agrega valor percebido pelo cliente final é considerada desperdício (muda, em japonês) e deve ser eliminada ou reduzida (OHNO, 1988). Quando essa mentalidade foi transportada para o desenvolvimento de software, Mary e Tom Poppendieck foram os pioneiros, publicando Lean Software Development (POPPENDIECK; POPPENDIECK, 2003), adaptando os princípios fabris para a realidade de equipes de tecnologia.
O Lean não surgiu da noite para o dia. Sua evolução reflete décadas de experimentação na Toyota Motor Corporation, sob a liderança de engenheiros como Taiichi Ohno e Shigeo Shingo (OHNO, 1988). Após a Segunda Guerra Mundial, o Japão não dispunha de recursos para produção em massa ao estilo fordista, o que obrigou a Toyota a desenvolver métodos que fizessem mais com menos.
- Década de 1930–1940: Kiichiro Toyoda estuda os métodos de produção de Ford nos EUA e percebe que é preciso adaptá-los à realidade japonesa de baixos volumes e alta variedade (LIKER, 2004).
- Década de 1950: Taiichi Ohno começa a desenvolver o sistema Just-in-Time (JIT) e o Kanban dentro das fábricas da Toyota (OHNO, 1988).
- Década de 1960–1970: O Sistema Toyota de Produção (TPS) amadurece. Shigeo Shingo desenvolve técnicas de troca rápida de ferramentas (SMED) e sistemas à prova de erro (Poka-Yoke) (SHINGO, 1985).
- 1988: John Krafcik publica artigo cunhando pela primeira vez o termo "Lean Production" (KRAFCIK, 1988).
- 1990: Womack, Jones e Roos publicam The Machine That Changed the World, popularizando o Lean no Ocidente (WOMACK; JONES; ROOS, 1990).
- 1996: Womack e Jones aprofundam os princípios no livro Lean Thinking (WOMACK; JONES, 1996).
- 2003: Mary e Tom Poppendieck lançam Lean Software Development, conectando Lean ao desenvolvimento ágil de software (POPPENDIECK; POPPENDIECK, 2003).
- 2011: Eric Ries publica The Lean Startup, aplicando princípios Lean ao empreendedorismo e inovação (RIES, 2011).
Womack e Jones definiram cinco princípios que servem como alicerce de toda implementação Lean (WOMACK; JONES, 1996). Eles formam um ciclo contínuo que deve ser repetido indefinidamente em busca da melhoria:
O ponto de partida de todo pensamento Lean é definir valor sob a perspectiva do cliente, não da empresa. Valor é aquilo pelo qual o cliente está disposto a pagar — uma funcionalidade, um serviço, uma experiência (WOMACK; JONES, 1996).
No software: uma funcionalidade que resolve um problema real do usuário agrega valor. Um relatório interno que ninguém lê, uma tela carregada de campos desnecessários ou uma reunião de alinhamento improdutiva são exemplos de desperdício (POPPENDIECK; POPPENDIECK, 2003).
Nos negócios: uma empresa que não sabe articular claramente o que é valor para seu cliente tende a investir recursos em atividades que não geram retorno. A definição de valor deve ser revisada continuamente, pois as necessidades do mercado mudam.
O fluxo de valor (Value Stream) é o conjunto de todas as ações necessárias para levar um produto ou serviço do conceito ao cliente. O exercício de Mapeamento do Fluxo de Valor (Value Stream Mapping, VSM) torna visíveis todas as etapas, permitindo identificar quais agregam valor, quais são necessárias mas não agregam valor e quais são puro desperdício (ROTHER; SHOOK, 2003).
Na prática de software: um VSM pode revelar que uma funcionalidade leva 30 dias da ideia à produção, mas apenas 5 dias são de trabalho efetivo — os outros 25 são filas de aprovação, espera por ambientes de teste ou handoffs entre equipes (POPPENDIECK; POPPENDIECK, 2003).
Uma vez eliminadas as etapas que não agregam valor, o objetivo é fazer com que as etapas remanescentes fluam de maneira contínua e ininterrupta. Em vez de processar grandes lotes de trabalho, o Lean favorece o fluxo de peça única (one-piece flow), reduzindo o tempo de ciclo e aumentando a previsibilidade (WOMACK; JONES, 1996).
No desenvolvimento de software: isso se traduz em limitar o trabalho em progresso (WIP — Work in Progress), integrar código continuamente (Continuous Integration) e entregar incrementos pequenos e frequentes ao invés de grandes lançamentos espaçados (ANDERSON, 2010).
O sistema puxado (pull) significa que nenhum item é produzido sem que haja demanda real. É o oposto do sistema push (empurrado), onde se produz com base em previsões. O mecanismo clássico é o Kanban: cartões que sinalizam quando uma etapa seguinte precisa de mais material (OHNO, 1988).
No software: a equipe não começa novas funcionalidades enquanto o trabalho atual não é concluído e entregue. Isso evita acúmulo de código não integrado, bugs escondidos e estoque de funcionalidades inacabadas. O quadro Kanban digital é uma implementação direta desse conceito (ANDERSON, 2010).
A perfeição não é um destino, mas um norte. O conceito japonês de Kaizen (改善, "mudança para melhor") prega que todas as pessoas da organização — do chão de fábrica à diretoria — devem continuamente buscar pequenas melhorias nos processos (IMAI, 1986).
No contexto ágil, as retrospectivas de sprint são uma manifestação direta do Kaizen: ao final de cada ciclo, a equipe reflete sobre o que funcionou, o que não funcionou e o que pode ser melhorado (POPPENDIECK; POPPENDIECK, 2003).
Womack e Jones advertem que, ao repetir o ciclo dos cinco princípios, cada iteração revela novas camadas de desperdício antes invisíveis, num processo virtualmente infinito de aprimoramento (WOMACK; JONES, 1996).
Os sete desperdícios (Muda)
Taiichi Ohno identificou originalmente sete tipos de desperdício na manufatura (OHNO, 1988). Mary e Tom Poppendieck os traduziram para o contexto do desenvolvimento de software (POPPENDIECK; POPPENDIECK, 2003):
| Manufatura | Desenvolvimento de software | Exemplo prático |
|---|---|---|
| Superprodução | Funcionalidades desnecessárias | Desenvolver módulos que nenhum usuário solicitou |
| Estoque | Trabalho parcialmente concluído | Código escrito mas não testado ou implantado |
| Espera | Atrasos e filas | Aguardar aprovação de merge request por dias |
| Transporte | Handoffs entre equipes | Repassar requisitos de analistas para devs para QA |
| Movimentação | Troca de tarefas (task switching) | Desenvolvedor alternando entre 4 projetos no mesmo dia |
| Processamento excessivo | Reaprendizado / burocracia | Documentação excessiva que ninguém consulta |
| Defeitos | Bugs e retrabalho | Correções urgentes em produção por falhas no teste |
Os sete princípios do Lean Software Development
Poppendieck e Poppendieck adaptaram a filosofia Lean em sete princípios específicos para desenvolvimento de software (POPPENDIECK; POPPENDIECK, 2003):
- Eliminar desperdícios: tudo que não contribui para o valor final deve ser removido. Inclui código desnecessário, processos burocráticos, funcionalidades não utilizadas e artefatos de documentação inúteis.
- Amplificar o aprendizado: o desenvolvimento de software é um processo de descoberta. Ciclos curtos de feedback, testes automatizados, revisões de código e prototipagem rápida aceleram o aprendizado da equipe.
- Decidir o mais tarde possível: em contextos de incerteza, adiar decisões irreversíveis até o último momento responsável permite que a equipe acumule mais informações antes de se comprometer.
- Entregar o mais rápido possível: entregas rápidas e frequentes reduzem o risco, geram feedback e permitem ajustes de rota. A velocidade de entrega é uma vantagem competitiva.
- Empoderar a equipe: quem faz o trabalho é quem melhor entende os detalhes. Decisões técnicas devem ser tomadas por quem executa, não por gestores distantes do código.
- Construir integridade: o software deve ter integridade perceptível (o usuário sente que "funciona bem") e integridade conceitual (a arquitetura é coerente e sustentável).
- Otimizar o todo: otimizações locais podem prejudicar o sistema global. É preciso ter visão sistêmica — melhorar o fluxo inteiro, não apenas uma etapa isolada.
Ferramentas e práticas Lean
O Lean dispõe de um arsenal de ferramentas práticas, tanto no chão de fábrica quanto em escritórios de software. Abaixo, detalhamos as principais:
O sistema Kanban foi originalmente desenvolvido por Taiichi Ohno na Toyota, inspirado nos supermercados americanos onde as prateleiras eram reabastecidas apenas quando esvaziavam (OHNO, 1988). David Anderson formalizou o Kanban para trabalho do conhecimento e desenvolvimento de software, definindo princípios como visualizar o fluxo, limitar o trabalho em progresso (WIP) e gerenciar o fluxo de forma explícita (ANDERSON, 2010).
Na prática, um quadro Kanban possui colunas representando os estágios do processo (ex.: "A Fazer", "Em Progresso", "Em Revisão", "Concluído"), com cartões representando itens de trabalho. Limites de WIP em cada coluna impedem sobrecarga e revelam gargalos no processo.
O Value Stream Mapping (VSM) é uma técnica visual que documenta todas as etapas — de informação e materiais — necessárias para entregar valor ao cliente (ROTHER; SHOOK, 2003). No desenvolvimento de software, o VSM pode mapear desde a solicitação do cliente até a funcionalidade em produção, revelando tempos de espera, gargalos e redundâncias.
O exercício envolve desenhar o estado atual (current state), identificar os desperdícios e projetar um estado futuro (future state) com tempos de ciclo reduzidos. É uma das ferramentas mais poderosas para transformações Lean.
O relatório A3 é uma ferramenta de resolução de problemas que condensa toda a análise em uma única folha de papel tamanho A3 (297 × 420 mm). Popularizado na Toyota, o A3 segue o ciclo PDCA (Planejar–Fazer–Checar–Agir) e inclui: contexto do problema, estado atual, análise de causa raiz, estado futuro desejado, plano de ação e acompanhamento (SOBEK; SMALLEY, 2008).
No ambiente de software, o A3 pode ser usado para analisar defeitos recorrentes, gargalos de entrega ou falhas de comunicação entre equipes.
O 5S é uma prática de organização originada no Japão, composta por cinco etapas cujos nomes em japonês começam com a letra "S" (LIKER, 2004):
- Seiri (Utilização): separar o necessário do desnecessário.
- Seiton (Organização): organizar para acesso fácil.
- Seiso (Limpeza): manter o ambiente limpo e inspecionado.
- Seiketsu (Padronização): criar padrões para manter os três primeiros S.
- Shitsuke (Disciplina): manter e melhorar os padrões continuamente.
Analogia no software: manter repositórios limpos, código bem organizado, convenções de nomenclatura padronizadas, e uma disciplina de refatoração contínua podem ser vistos como o 5S digital.
Poka-Yoke (ポカヨケ) são mecanismos que impedem ou detectam erros humanos antes que se tornem defeitos (SHINGO, 1985). Na manufatura, pode ser um encaixe que só permite a montagem na orientação correta.
No software: validações de formulário que impedem entrada de dados inválidos, testes automatizados que bloqueiam o deploy se falharem, linters que detectam erros de sintaxe antes do commit e sistemas de feature flags que permitem desfazer lançamentos problemáticos — todos são formas de Poka-Yoke digital.
Lean Startup — O Lean no empreendedorismo
Eric Ries expandiu os conceitos Lean para o universo das startups e inovação em seu livro The Lean Startup (RIES, 2011). A premissa é que startups operam em condições de extrema incerteza e, portanto, devem validar hipóteses de negócio o mais rápido e barato possível.
O pilar central do Lean Startup é o ciclo Construir–Medir–Aprender (Build–Measure–Learn):
O Produto Mínimo Viável (MVP — Minimum Viable Product) é a versão mais simples do produto que permite testar uma hipótese de valor junto a clientes reais. Não se trata de lançar algo ruim, mas de aprender o máximo com o mínimo de esforço (RIES, 2011).
Se os dados validam a hipótese, a startup persevera e refina o produto. Caso contrário, realiza um pivô — uma mudança estruturada de direção baseada no aprendizado obtido. Exemplos célebres de pivôs incluem empresas como a Slack (que nasceu como uma ferramenta interna de um jogo online) e o Instagram (originalmente um aplicativo de check-in chamado Burbn).
Para medir o progresso, Ries propõe a contabilidade de inovação (innovation accounting), que substitui métricas de vaidade (como número total de usuários registrados) por métricas acionáveis — aquelas que ajudam a tomar decisões reais, como taxa de retenção semanal ou receita por cohort (RIES, 2011).
Lean e os demais métodos ágeis
O Lean compartilha valores com outros métodos ágeis mas possui ênfases distintas. A tabela a seguir sintetiza as principais diferenças:
| Aspecto | Lean / Kanban | Scrum | XP (Extreme Programming) |
|---|---|---|---|
| Origem | Sistema Toyota de Produção | Gestão de projetos adaptativa | Práticas de engenharia de software |
| Cadência | Fluxo contínuo | Sprints de duração fixa | Iterações curtas (1–2 semanas) |
| Papéis definidos | Não prescritivo | Scrum Master, Product Owner, Devs | Coach, Cliente, Programadores |
| Foco principal | Eliminar desperdícios, fluxo | Entrega iterativa, transparência | Excelência técnica, feedback rápido |
| Gestão de trabalho | Limites de WIP | Backlog priorizado, sprint backlog | Histórias de usuário priorizadas |
| Métricas-chave | Lead time, throughput, WIP | Velocidade, burndown | Velocidade, cobertura de testes |
É importante notar que esses métodos não são mutuamente exclusivos. Muitas equipes adotam abordagens híbridas, como o Scrumban (Scrum + Kanban) ou incorporam práticas de XP dentro de um framework Lean (ANDERSON, 2010).
Lean em escala — SAFe e além
Quando uma organização com centenas ou milhares de desenvolvedores deseja adotar Lean, frameworks de escala como o SAFe (Scaled Agile Framework) incorporam princípios Lean como fundamento. O SAFe utiliza conceitos como fluxos de valor de desenvolvimento, cadência e sincronização, e a mentalidade Lean-Agile como pilares (LEFFINGWELL, 2011).
Além do SAFe, outras abordagens de escala com influência Lean incluem o LeSS (Large-Scale Scrum), que busca simplificar a escalada mantendo o foco em eliminar desperdícios organizacionais, e o Lean Enterprise, que estende os princípios Lean para toda a cadeia de valor corporativa — de portfólio a operações.
Críticas e limitações do Lean
Embora amplamente adotado, o Lean não é isento de críticas:
- Dificuldade de transposição cultural: o Lean nasceu em um contexto cultural japonês específico, com forte ênfase em respeito, consenso e emprego vitalício. Transplantá-lo sem adaptações para culturas organizacionais ocidentais individualistas pode gerar resistência (LIKER, 2004).
- Risco de pressão sobre trabalhadores: a obsessão com eliminação de desperdícios pode ser distorcida para intensificar o trabalho e reduzir buffers necessários à saúde organizacional, levando ao burnout.
- Falsa simplicidade: os princípios Lean parecem simples de entender, mas são profundamente difíceis de implementar corretamente. Muitas organizações adotam ferramentas (como Kanban) sem absorver a filosofia por trás delas.
- Menos prescritivo: diferente do Scrum, que fornece papéis, eventos e artefatos claros, o Lean é mais uma filosofia do que um framework passo a passo, o que pode desorientar equipes que buscam direcionamento concreto.
- Tensão entre eficiência e inovação: a eliminação radical de desperdícios pode, paradoxalmente, reduzir a folga organizacional (slack) necessária para experimentação e inovação disruptiva.
Como começar com Lean — Guia prático
Para quem deseja iniciar a jornada Lean, seja em um projeto de software ou em um processo de negócios, os seguintes passos oferecem uma trilha introdutória:
- Defina o valor: converse com seus clientes ou usuários e entenda o que realmente importa para eles.
- Mapeie o fluxo atual: desenhe todas as etapas do seu processo, da ideia à entrega. Use um mural ou ferramenta digital.
- Identifique desperdícios: marque cada etapa que não agrega valor direto ao cliente.
- Implemente um quadro Kanban: visualize o trabalho em andamento e limite o WIP para as capacidades reais da equipe.
- Estabeleça ciclos de feedback: faça retrospectivas regulares (semanal ou quinzenalmente).
- Meça e adapte: acompanhe métricas como lead time, throughput e taxa de defeitos. Tome decisões baseadas em dados.
Glossário essencial
| Termo | Definição |
|---|---|
| Muda (無駄) | Desperdício; qualquer atividade que consome recursos sem agregar valor. |
| Mura (斑) | Irregularidade; variação e inconsistência nos processos. |
| Muri (無理) | Sobrecarga; exigir mais do que a capacidade permite. |
| Kaizen (改善) | Melhoria contínua incremental. |
| Kanban (看板) | Sinal visual ("cartão") que controla a produção puxada. |
| Just-in-Time (JIT) | Produzir ou entregar somente o necessário, quando necessário, na quantidade necessária. |
| Jidoka (自働化) | Automação com toque humano; parar o processo ao detectar anomalia. |
| Genchi Genbutsu | "Vá e veja"; tomar decisões com base em observação direta, não em relatórios. |
| Heijunka (平準化) | Nivelamento da produção para suavizar variações de demanda. |
| Andon (行灯) | Sistema de sinalização visual que alerta sobre problemas na linha. |
| WIP | Work in Progress; quantidade de trabalho em andamento simultâneo. |
| Lead Time | Tempo total desde a solicitação até a entrega ao cliente. |
| Cycle Time | Tempo efetivo de trabalho em um item, excluindo filas e esperas. |
| Throughput | Número de itens concluídos por unidade de tempo. |
| MVP | Minimum Viable Product; versão mínima do produto para validação. |
Considerações finais
O modelo Lean, ao longo de quase oito décadas de evolução, demonstrou uma capacidade notável de adaptação — das linhas de montagem da Toyota aos sprints de equipes de software e às pivotagens de startups. Seus princípios de eliminação de desperdícios, fluxo contínuo e melhoria incessante permanecem relevantes em qualquer contexto onde se busque eficiência sem sacrifício de qualidade.
Para acadêmicos de computação e negócios, compreender o Lean é mais do que aprender uma metodologia: é adquirir uma mentalidade sistêmica que questiona continuamente o que agrega valor e o que é desperdício. Essa mentalidade, quando genuinamente incorporada, transforma não apenas processos, mas a cultura inteira de equipes e organizações.
ANDERSON, D. J. Kanban: successful evolutionary change for your technology business. Sequim: Blue Hole Press, 2010.
BECK, K.; ANDRES, C. Extreme Programming Explained: embrace change. 2. ed. Boston: Addison-Wesley, 2004.
IMAI, M. Kaizen: the key to Japan's competitive success. New York: McGraw-Hill, 1986.
KRAFCIK, J. F. Triumph of the Lean Production System. Sloan Management Review, v. 30, n. 1, p. 41–52, 1988.
LEFFINGWELL, D. Agile Software Requirements: lean requirements practices for teams, programs, and the enterprise. Boston: Addison-Wesley, 2011.
LIKER, J. K. The Toyota Way: 14 management principles from the world's greatest manufacturer. New York: McGraw-Hill, 2004.
OHNO, T. Toyota Production System: beyond large-scale production. Portland: Productivity Press, 1988.
POPPENDIECK, M.; POPPENDIECK, T. Lean Software Development: an agile toolkit. Boston: Addison-Wesley, 2003.
RIES, E. The Lean Startup: how today's entrepreneurs use continuous innovation to create radically successful businesses. New York: Crown Business, 2011.
ROTHER, M.; SHOOK, J. Learning to See: value stream mapping to add value and eliminate muda. Cambridge: Lean Enterprise Institute, 2003.
SCHWABER, K.; SUTHERLAND, J. The Scrum Guide. 2020. Disponível em: https://scrumguides.org. Acesso em: 22 mar. 2026.
SHINGO, S. A Revolution in Manufacturing: the SMED system. Portland: Productivity Press, 1985.
SOBEK, D. K.; SMALLEY, A. Understanding A3 Thinking: a critical component of Toyota's PDCA management system. Boca Raton: CRC Press, 2008.
WOMACK, J. P.; JONES, D. T.; ROOS, D. The Machine That Changed the World. New York: Free Press, 1990.
WOMACK, J. P.; JONES, D. T. Lean Thinking: banish waste and create wealth in your corporation. New York: Simon & Schuster, 1996.
Fonte:
Visto no Brasil Acadêmico
Comentários