O Lean Software Development (LSD) é uma filosofia de gestão ágil que transcende a mera gestão de projetos e atua como uma abordagem de gestão de valor. Formalizado por Mary e Tom Poppendieck (um casal muito bacana que já esteve no Brasil algumas vezes, pela no momento estão gozando de merecidas aposentadorias) em 2003, o LSD adapta os princípios do Sistema Toyota de Produção (TPS – Toyota Production System) para o desenvolvimento de software. Seu objetivo é maximizar o valor para o cliente por meio da eliminação sistemática de desperdícios e da otimização do fluxo de trabalho. Por isso, o casamento com o Kanban é tão forte.
Os Sete Princípios Fundamentais do Lean Software Development
O LSD é guiado por sete princípios interconectados que servem de base para a tomada de decisões e para a cultura do trabalho. Para cada princípio, o casal Poppendieck apresenta algumas ferramentas para aplicá-lo.
P1. Eliminar Desperdício
O princípio central do Lean é identificar e remover qualquer atividade que não adicione valor ao produto final do ponto de vista do cliente. E, infelizmente, nós adoramos inserir um monte de penduricalhos em nossos produtos. Sejam funcionalidades que ninguém pediu, seja uma arquitetura de arranha-céu que dá suporte a um casebre.
No desenvolvimento de software, os Poppendieck identificaram nove tipos de desperdício, que incluem:
- Trabalho parcialmente concluído: grandes backlogs e itens pendentes.
- Burocracia: Processos excessivamente complexos que atrasam a entrega.
- Funcionalidades (e códigos) desnecessários: construir algo de que o cliente não precisa ou uma arquitetura aperfeiçoada prematuramente.
- Troca de tarefas (Task Switching): perda de foco e de tempo ao alternar entre diferentes projetos ou tarefas.
- Atrasos e esperas: tempo ocioso entre as etapas do processo (ex.: espera por aprovação ou por teste).
- Movimentação: Quanta movimentação é necessária para desenvolver um produto? Por exemplo, se uma pessoa tem uma dúvida que precisa ser esclarecida pelo cliente. Com quantas pessoas ele precisa falar até chegar ao cliente?
- Defeitos: O retrabalho necessário para corrigir bugs.
- Atividades de Gestão: eu sou gerente, mas tenho plena consciência de que a gestão pura e simples não gera valor. Ela ajuda a agregar valor. Se você está perdendo muito tempo e acrescentando atividades de gestão às atividades propriamente ditas, saiba que está gerando desperdício.
Particularmente, acredito que 2, 5 e 4 são os piores e os que mais atrapalham os times. Empresas gigantes e a administração pública exageram no 8, criando o plano do plano do plano para algo que ninguém verá.
As ferramentas recomendadas são:
Ferramenta 1: Ver o desperdício
Uma abordagem para reconhecer e categorizar os oito tipos de desperdício no contexto do desenvolvimento de software, incentivando equipes a questionar processos ineficientes.
Ferramenta 2: Value Stream Mapping (Mapeamento do Fluxo de Valor)
Uma técnica visual para mapear todo o ciclo de vida de um produto, desde a ideia até a entrega, identificando etapas que não agregam valor e oportunidades de melhoria. Literalmente é o seu quadro Kanban com gestão visual.
P2. Ampliar o Aprendizado
O desenvolvimento de software é, fundamentalmente, um processo de aprendizado contínuo. Você aprende sobre as ferramentas, o cliente, o mercado, como ganhar dinheiro etc. Este princípio incentiva a documentação, o compartilhamento de conhecimento e a retenção dos aprendizados. Isso é alcançado por meio de revisões de código, documentação viva (na época da escrita do livro, 2003, era muito comum a atualização de wikis) e sessões de treinamento que garantem que o conhecimento não fique restrito a indivíduos, mas se torne um ativo da equipe.
As ferramentas aqui são:
Ferramenta 3: Feedback
Cria loops de feedback rápidos e frequentes em todos os níveis (desenvolvedores, usuários, testes) para reduzir incertezas e aprimorar soluções por meio de iterações. O que, aliás, é a próxima ferramenta.
Ferramenta 4: Iterações
Entrega pequenos incrementos do software em ciclos curtos, para proporcionar aprendizado contínuo e entrega de valor constante. Isso auxilia muito a adaptação do produto quando necessária.
Ferramenta 5: Sincronização
Usar entrega contínua, testes automatizados e design de interfaces para alinhar múltiplas equipes. Não posso estressar o quão importante é integrar o trabalho com frequência e evitar surpresas tardias.
Ferramenta 6: Set-Based Development (Desenvolvimento Baseado em Conjuntos)
É uma forma de desenvolver soluções explorando várias opções ao mesmo tempo, em vez de escolher uma única ideia logo no início. Logo, em vez de decidir cedo e seguir apenas um caminho, o time trabalha com um conjunto de possibilidades. À medida que aprende mais com testes, dados e restrições reais, vai eliminando as opções menos viáveis até chegar à melhor solução.
É uma boa ideia, porém nem sempre é factível, dados os prazos que você terá disponíveis.
P3. Decidir o mais tarde possível
Também conhecido como Adiar Comprometimento (Defer Commitment). Este princípio defende a tomada de decisões importantes o mais tarde possível, mantendo as opções abertas até que se tenha o máximo de informações disponíveis. Afinal, em um ambiente de requisitos voláteis, adiar o comprometimento minimiza o risco de ter de refazer o trabalho devido a mudanças de mercado ou de requisitos.
Ferramenta 7: Options Thinking (Pensamento em Opções)
Trata decisões como opções financeiras, o que, de fato, é verdade. Você deve adiar compromissos para reduzir riscos e explorar todas as alternativas até que a incerteza diminua. Está profundamente ligada ao Set-Based Development. Mais uma vez, nem sempre será factível.
Ferramenta 8: The Last Responsible Moment – LRM (O Último Momento Responsável)
Identifica o ponto ideal para decidir antes que as opções sejam perdidas. Escrevi o artigo “Como Lidar com Demandas com Prazo: Uma Abordagem Baseada em Dados e Kanban” que aborda o LRM e como decidir quando ele ocorre.
Ferramenta 9: Tomada de Decisões
Combina abordagens breadth-first (exploração ampla de opções) e depth-first (foco profundo), promovendo decisões intuitivas baseadas em experiência e em padrões e regras simples para guiar equipes em contextos incertos.
P4. Entregar Rápido (Deliver Fast)
A velocidade de entrega é crucial, pois permite que o produto chegue mais rapidamente às mãos do cliente, gerando feedback e valor. A entrega rápida não significa trabalhar mais horas, e sim otimizar o fluxo de trabalho, eliminando os desperdícios que causam lentidão. Esse princípio é inspirado em conceitos do TPS, como o just-in-time (JiT).
Aqui entram conceitos importantes como Teoria das Filas, Sistema Puxado e Limitação de WIP.
As ferramentas deste princípio lean são:
Ferramenta 10: Sistemas Puxados (Pull Systems)
Implementa mecanismos, como Kanban, para que o trabalho seja “puxado” pela demanda e pela capacidade do fluxo, evitando acúmulos e promovendo um fluxo contínuo, sem planejamento excessivo.
Ferramenta 11: Teoria das Filas
Analisa como as filas se formam em processos e como reduzi-las por meio de limitação de WIP, balanceamento de carga e foco na variabilidade, para otimizar o throughput e reduzir atrasos.
Poucos sabem, mas uma das figuras mais lendárias da história da agilidade está exatamente nesta parte do livro, na página 80.
Mostra o efeito de sair utilizando a capacidade do time sem limites. O tempo de construção passa a aumentar exponencialmente. Isso se torna ainda pior se o item de trabalho (história de usuário, por exemplo) for grande.
Ferramenta 12: Cost of Delay (Custo do Atraso)
Calcula o impacto econômico de atrasar features ou projetos, priorizando itens de alto valor ou de alta urgência para maximizar o retorno e alinhar as decisões aos objetivos de negócio. Nós temos um artigo que explica em detalhes o que é o Cost of Delay.
P5. Empoderar o Time
Este é frequentemente considerado o pilar mais importante do Lean. O princípio do respeito às pessoas envolve empoderar a equipe para que ela possa tomar decisões técnicas e gerenciar seu próprio trabalho. Isso cria um ambiente de confiança, incentiva a proatividade e a responsabilidade e reconhece que os desenvolvedores são a fonte primária de valor e melhoria.
Esse princípio aqui me pega bastante. Na minha carreira já tive que escrever centenas (talvez milhares) de documentos, planos, planos de ação que não faziam sentido e só existiam porque alguma cabeça brilhante que não estava envolvida no trabalho pensou que seria uma boa ideia. A quantidade de linhas que escrevi que serviram apenas para o lixo é absurda. A pior coisa é alguém que não coloca a mão na massa, pensando em como melhorá-la com base em achismos.
Aqui as ferramentas são:
Ferramenta 13: Autodeterminação
O time é dono do seu trabalho, respeitando sua capacidade de melhorar processos e decidir como o trabalho é feito, promovendo responsabilidade e autonomia em vez de imposições externas.
Ferramenta 14: Motivação
O time tem um propósito claro e não é só o pessoal que entrega, entrega e entrega. Eles devem ter o senso de pertencimento, segurança, competência e progresso.
Ferramenta 15: Liderança
Substituir o comando e controle tradicional por liderança emergente que inspire, direcione e apoie equipes sem fazer a microgestão delas.
Ferramenta 16: Expertise
Fomenta que pessoas mais experientes compartilhem o conhecimento com os demais membros do time. Além disso, eles podem desenvolver padrões para uma construção mais eficaz.
P6. Construir com Integridade (Build Integrity In)
O nome não é muito claro; creio que “qualidade” seria melhor, mas o conceito é bem interessante e o casal Poppendieck o divide em duas perspectivas: integridade percebida e integridade conceitual.
As integridades
Refere-se à experiência total do usuário com o produto. Um produto com alta integridade percebida equilibra bem funcionalidade, usabilidade, confiabilidade e custo, a ponto de encantar o cliente. Esse julgamento envolve tudo o que o usuário vivencia, como facilidade de uso, desempenho, adaptação às necessidades reais, ausência de incômodos e utilidade no dia a dia.
A medida prática dessa integridade é o quanto o produto é lembrado, usado e considerado indispensável, algo próximo da participação de mercado ou da “participação na mente” do usuário.
A integridade conceitual diz respeito à coerência interna do sistema. Ela existe quando os conceitos centrais do produto funcionam como um todo harmonioso, com componentes bem integrados e uma arquitetura equilibrada. A conceitual é fundamental para a percebida.
As ferramentas para adaptar o princípio são:
Ferramenta 17: Integridade Percebida
A integridade percebida de um sistema surge quando as decisões técnicas do dia a dia refletem continuamente o que o cliente valoriza, algo que modelos baseados em documentos não conseguem garantir, pois afastam os desenvolvedores da percepção real do cliente e perdem informações a cada repasse (movimentação).
Aqui, os autores defendem o uso de práticas como o Model-Driven Design (Design baseado em modelo). Isso, em 2003, estava muito em voga, mas sempre faltou uma ferramenta que tornasse essa abordagem útil.
Ferramenta 18: Integridade Conceitual
Em software, essa integridade é apoiada por uma arquitetura em camadas bem definidas, alta coesão e separação de responsabilidades, atenção especial à interface com o usuário e decisões que agrupam o que muda juntos e reduzem a variabilidade. Em vez de tentar prever o futuro, o texto do livro defende acertar os fundamentos, permitir que os detalhes emerjam com o uso e manter a arquitetura saudável por meio de evolução contínua e refatoração.
Ferramenta 19: Refactoring (refatoração)
Bons projetos não nascem prontos; evoluem por meio de tentativas, aprendizado e melhoria contínua. À medida que o sistema cresce, novas funcionalidades revelam padrões ocultos e exigem ajustes arquiteturais para evitar duplicações, fragilidades e perda de coesão. Refatorar regularmente mantém o sistema saudável, simples, claro e adequado ao uso, evitando o acúmulo de “dívida técnica”.
Os sinais de que é hora de refatorar incluem perda de simplicidade, falta de clareza, inadequação ao uso e repetição de código ou de conhecimento, pois a duplicação é um dos maiores inimigos da flexibilidade e da evolução sustentável do software.
Ferramenta 20: Teste
Testes automatizados por script foram criados na década de 90. O livro foi escrito em 2003, quando isso ainda poderia ter sido uma novidade. Se hoje você não tem automação de testes, está mais de 30 anos atrasado em termos de integridade conceitual. Ferramentas existem em excesso e, se você não souber fazer, peça a uma IA que faça por você. Não faz sentido criar software sem testes, pois é como entrar em um carro que nunca foi testado.
Os testes automatizados garantem que o software faça exatamente o que clientes e desenvolvedores esperam, além de sustentar o desenvolvimento iterativo, o aprendizado e a refatoração contínua. Não adianta achar que, na Sprint 123, alguém ficará testando manualmente o que foi entregue na Sprint 1.
Os testes cumprem múltiplos papéis fundamentais:
- funcionam como meio de comunicação entre clientes e desenvolvedores, substituindo ou complementando documentos escritos;
- fornecem feedback imediato sobre a qualidade do código;
- atuam como scaffolding (andaimes), permitindo mudanças seguras em sistemas complexos; e
- Tornam-se a melhor forma de documentação “as-built”, refletindo fielmente o comportamento real do sistema.
A qualidade deve ser incorporada ao processo e não verificada apenas no final. Isso significa que a prevenção de defeitos é mais importante do que a detecção. Práticas como Test-Driven Development (TDD), Pair Programming e Integração Contínua (CI) são ferramentas essenciais para garantir que o código seja bem estruturado desde o início.
A automação remove 100% da necessidade de humanos nos testes?
Não. O conceito de Jidoka (automação com toque humano) da Toyota é traduzido para o software como a capacidade de interromper o trabalho imediatamente ao identificar um defeito para corrigir a causa raiz.
P7. Ver o Todo (See the Whole)
Aqui, o casal introduz o pensamento sistêmico, defendendo que uma organização ou sistema não pode ser compreendido pela soma de suas partes, mas sim pelas interações entre elas. Muitos problemas em desenvolvimento de software surgem quando se tenta corrigir dificuldades locais (otimização local) com mais controle, processos rígidos ou pressão por prazos, o que frequentemente gera efeitos colaterais e espirais de deterioração.
Eles alertam para dois padrões que surgem quando tentamos resolver problemas locais sem considerar o todo. São eles os “limits to growth” e “shifting the burden”.
Limits to Growth (Limites ao Crescimento)
Esse padrão ocorre quando uma ação inicialmente gera crescimento ou melhoria, mas há um limite oculto no sistema que, ao ser alcançado, impede a continuidade desse crescimento. No início, os resultados são positivos, o que incentiva a intensificação da mesma ação. Porém, em vez de remover o fator limitante, a organização tenta “forçar mais do mesmo”, o que acaba piorando a situação.
Um bom exemplo poderia ser aumentar a velocidade de entrega, pressionando o time. Isso funciona no curto prazo, mas o crescimento para quando surgem gargalos, como dívida técnica, retrabalho e desgaste das pessoas. Se o limite real (integridade, arquitetura, capacidade do time) não for tratado, mais pressão só acelera a queda de desempenho.
Shifting the Burden (Deslocamento do Problema)
Esse padrão ocorre quando um problema tem uma causa estrutural, mas a organização aplica uma solução rápida e paliativa que alivia o sintoma no curto prazo. Com o tempo, essa solução temporária se torna um hábito, enquanto a causa real permanece ou até se agrava. O sistema passa a depender da solução superficial.
Aqui temos um caso clássico de criação de burocracia desnecessária. Por exemplo, quando um produto apresenta muitos defeitos, em vez de automação ou aperfeiçoamento real da qualidade (integridade), a resposta é criar mais etapas de aprovação, mais testes manuais ou mais controle. Isso reduz o problema momentaneamente, mas não ataca a raiz, como o código mal estruturado, a ausência de testes automatizados ou a falta de colaboração. Aos poucos, o processo se torna pesado, lento e menos eficaz.
A abordagem Lean enfatiza remover restrições reais, entender os feedbacks e evitar respostas simplistas a sistemas complexos.
Ferramenta 21: Métricas
Os autores também alertam para o perigo da subotimização, especialmente por meio de métricas locais. Exemplos como medir os testadores pela quantidade de erros encontrados, ou a quantidade de linhas de código para premiar desenvolvedores, times compostos por uma especialidade.
O casal mostra que otimizar partes isoladas frequentemente piora o desempenho global. Medidas mal escolhidas incentivam comportamentos disfuncionais por superstição ou por hábito. Já contei algumas vezes sobre o caos causado por uma premiação ao time que entregou mais sprints.
Em vez disso, eles defendem medições agregadas e informacionais, focadas no fluxo de valor e nos objetivos do negócio, não no desempenho individual. Medir tudo o que é fácil, mas não o que realmente importa, leva à perda de visão do todo. Ver o todo implica alinhar decisões, métricas e incentivos ao desempenho global do sistema e à entrega de valor real ao cliente.
Ferramentas 22: Contratos
Mary e Tom discutem como contratos tradicionais, especialmente os de escopo fixo e preço fixo, dificultam a colaboração, reduzem a confiança e frequentemente aumentam o custo, o prazo e o risco no desenvolvimento de software. Diferentemente da manufatura repetitiva, o software é complexo, muda constantemente e só pode ser aprendido durante o desenvolvimento.
Contratos rígidos incentivam comportamento defensivo de ambas as partes: o cliente busca extrair o máximo valor possível e o fornecedor busca proteger-se contra mudanças, resultando em excesso de controle, comunicação limitada e perda de integridade do sistema.
Como alternativa, eles apresentam contratos compatíveis com a agilidade, cujo princípio central é o escopo flexível, não fixo. Exemplos incluem contratos por tempo, por meio de iterações curtas, contratos multiestágio, contratos de custo-alvo, contratos de prazo-alvo e contratos de benefício compartilhado. Esses modelos distribuem riscos de forma mais justa, incentivam a colaboração contínua e permitem que as decisões sejam tomadas à medida que o conhecimento emerge. O objetivo do contrato deixa de prever tudo antecipadamente e passa a criar um ambiente que favoreça o aprendizado, a adaptação e a entrega de valor, preservando a confiança entre as partes, mesmo diante da incerteza inevitável do desenvolvimento de software.
Conclusão
Como vimos no texto, o Lean Software Development é uma forma de pensar no desenvolvimento de produtos. Não chega a descrever papéis nem reuniões, porém, os pontos que ele apresenta ainda são muito relevantes até hoje. Além disso, você pode incluir essa forma de pensar no método que utiliza hoje, como Scrum, Kanban, Scrumban, entre outros.
Espero que tenha gostado e até a próxima.
