Por que reduzir desperdícios, concentrar-se no essencial, limitar o trabalho inacabado e criar valor em pequenos ciclos de aprendizagem importa mais do que simplesmente maximizar a atividade
Tempo estimado de leitura: 20 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender as ideias básicas do , como o desperdício e o trabalho desnecessário reduzem o valor, por que ciclos pequenos e foco aprimoram a aprendizagem, como o se relaciona com o e por que fazer mais trabalho não é o mesmo que produzir mais valor.
Introdução: a armadilha da produtividade - quando mais trabalho produz menos valor
Uma equipe pode estar completamente ocupada, cada especialista pode estar plenamente utilizado, cada backlog pode estar transbordando e, ainda assim, os clientes podem receber valor lentamente.
Essa aparente contradição é uma das ideias mais importantes por trás do . A gestão tradicional frequentemente trata produtividade como a quantidade de atividade realizada: mais tarefas iniciadas, mais pessoas utilizadas, mais projetos executados em paralelo, mais funcionalidades solicitadas, mais reuniões realizadas e mais entregas produzidas. O faz uma pergunta diferente: quanto dessa atividade realmente ajuda a criar o valor de que o cliente precisa?
A distinção é crucial no desenvolvimento de software e de produtos. Escrever código tem um custo, mas o código não possui valor inerente apenas porque existe. Uma funcionalidade de que nenhum cliente precisa pode ser implementada com perfeição e ainda assim representar desperdício. Um relatório pode ser produzido toda semana e nunca influenciar uma decisão. Uma equipe pode iniciar vinte itens do , gerar métricas de utilização impressionantes e ainda assim não entregar nenhum utilizável porque o trabalho está disperso demais. A organização parece ocupada enquanto o valor espera em filas.
O surgiu de décadas de aprendizado sobre fluxo, qualidade, desperdício e valor para o cliente em sistemas industriais, especialmente no Toyota Production System. O termo "lean production" ganhou ampla notoriedade com pesquisas publicadas por volta de 1990, e James Womack e Daniel Jones posteriormente formularam uma estrutura amplamente utilizada de baseada em valor, ,, puxar o trabalho e busca contínua por melhoria. A lição importante para o não é copiar práticas de fábrica para o trabalho do conhecimento. Software não é uma linha de montagem. A lição útil é observar criticamente como o trabalho flui, onde tempo e esforço são perdidos e se o sistema está otimizado para valor ou para atividade local.
O Scrum Guide torna essa relação explícita. O é fundamentado no e no . O nos orienta a aprender com a experiência e a tomar decisões com base no que é observado. O reduz desperdícios e concentra-se no essencial. Juntas, essas ideias explicam muito da forma do : uma equipe pequena e , um único ordenado, uma focado, uma curta, um utilizável, uma estrutura formal limitada e oportunidades frequentes de inspeção e adaptação.
Este capítulo desenvolve essa conexão cuidadosamente. Lean e não são o mesmo framework. O não exige um mapa de , um , um sistema de manufatura just-in-time ou uma transformação Lean formal. No entanto, o oferece uma lente valiosa para compreender por que o evita deliberadamente estruturas desnecessárias, por que o trabalho inacabado é perigoso, por que o foco importa e por que uma quantidade menor de trabalho valioso concluído pode ser economicamente superior a uma quantidade maior de atividade parcialmente concluída.
O que é ?
O é uma forma de raciocinar sobre como uma organização cria valor utilizando menos recursos, atrasos, transferências, defeitos, estoques e atividades desnecessários. Ele começa pela perspectiva do cliente ou beneficiário: qual problema estamos tentando resolver e qual resultado é realmente valioso? A partir daí, o Lean convida as organizações a examinar todo o caminho pelo qual o valor é criado, em vez de otimizar cada departamento ou especialista isoladamente.
Uma formulação clássica do Lean identifica cinco ideias relacionadas: especificar o valor a partir da perspectiva do cliente; compreender o que produz esse valor; melhorar o fluxo para que o valor avance com menos interrupções; utilizar o princípio de puxar para que o trabalho seja criado em resposta a uma necessidade real, em vez de ser empurrado prematuramente para o sistema; e melhorar continuamente em direção a um estado com menos desperdício e melhor criação de valor. Na prática Lean moderna, a linguagem pode variar, mas a lógica central permanece reconhecível: valor, fluxo, aprendizagem, pessoas, qualidade e .
Isso é mais do que uma filosofia de redução de custos. Reduzir o quadro de pessoas enquanto se mantém o mesmo sistema de trabalho disfuncional não é . Tampouco é obrigar as pessoas a trabalhar mais rápido. A verdadeira melhoria Lean observa o trabalho em si: aprovações desnecessárias, longas filas, informações duplicadas, defeitos, lotes excessivamente grandes, retrabalho, prioridades pouco claras, espera por especialistas, excesso de trabalho em andamento e funcionalidades de que ninguém precisa.
O Lean também possui uma forte dimensão de aprendizagem. A experimentação contínua importa porque a organização raramente conhece antecipadamente o processo ou o produto perfeito. As equipes melhoram tornando os problemas visíveis, experimentando mudanças, observando os resultados e preservando aquilo que produz melhor valor e fluxo. Esse é um dos pontos de contato mais claros com a natureza empírica do .
Lean em uma frase
Crie o valor de que as pessoas realmente precisam enquanto reduz sistematicamente o trabalho, os atrasos, a complexidade e os desperdícios que não contribuem para esse valor.
Uma breve história: da Toyota ao trabalho do conhecimento
As raízes históricas do Lean estão fortemente associadas ao Toyota Production System (TPS), desenvolvido ao longo de décadas no Japão. A Toyota enfrentava condições econômicas e operacionais que dificultavam copiar diretamente o modelo dominante de produção em massa. Em vez de depender de enormes estoques e longos ciclos de produção, a Toyota desenvolveu abordagens centradas em qualidade na origem, fluxo mais suave, produção just-in-time, visibilidade dos problemas e .
Taiichi Ohno é estreitamente associado ao desenvolvimento do TPS no período pós-guerra, enquanto ideias como jidoka e just-in-time possuem raízes anteriores na organização Toyoda. Com o tempo, pesquisadores que estudavam a Toyota perceberam que o sistema representava mais do que um conjunto de truques de manufatura. Era uma lógica de gestão diferente - uma lógica atenta ao fluxo total, à demanda do cliente, à qualidade, à aprendizagem e à eliminação de desperdícios.
O termo "lean production" ganhou visibilidade global por meio das pesquisas sintetizadas em The Machine That Changed the World, de 1990. Womack e Jones posteriormente popularizaram o como uma abordagem de gestão mais ampla. Desde então, ideias Lean vêm sendo aplicadas muito além das fábricas: saúde, construção, serviços, desenvolvimento de produtos, administração e software.
Essa expansão exige cautela. Uma funcionalidade de software não é um componente físico deslocando-se por uma linha de produção. Requisitos podem emergir, o conhecimento é distribuído entre pessoas e o produto muitas vezes pode ser alterado repetidamente com custo físico relativamente baixo. Ainda assim, o desenvolvimento de software contém filas, estoques, defeitos, retrabalho, espera, superprodução e gargalos. O ajuda a enxergar esses problemas como problemas do sistema, em vez de simplesmente pedir que indivíduos trabalhem mais.
Desperdício: atividade que consome capacidade sem criar valor suficiente
Desperdício é um dos conceitos Lean mais reconhecidos. De forma simples, desperdício é trabalho que consome tempo, dinheiro, atenção ou capacidade sem criar valor a partir da perspectiva do cliente. Alguns trabalhos que não criam valor diretamente ainda podem ser necessários - controles jurídicos, evidências de segurança, relatórios financeiros ou verificações regulatórias, por exemplo. O Lean não presume que toda atividade invisível ao cliente possa ser removida. O objetivo é distinguir o suporte necessário do desperdício evitável.
No trabalho do conhecimento, o desperdício frequentemente fica oculto porque não possui forma física. Um depósito cheio de estoque sem uso é visível. Um backlog cheio de iniciativas parcialmente analisadas, funcionalidades parcialmente codificadas, pull requests não revisados, testes bloqueados, dependências não resolvidas e experimentos abandonados pode ser igualmente caro, mas menos evidente. Cada item inacabado carrega informações, contexto, necessidades de coordenação e risco.
Desperdício em software/produto
Manifestação típica
Superprodução
Construir funcionalidades, relatórios, integrações ou infraestrutura antes de haver evidências de que são necessários.
Espera
Trabalho bloqueado por aprovações, ambientes, decisões, especialistas, revisões, equipes externas ou requisitos pouco claros.
Handoffs
Conhecimento transferido entre departamentos, tickets, documentos ou filas, aumentando o atraso e a perda de interpretação.
Estoque /
Grandes quantidades de trabalho iniciado, mas não concluído: branches, tickets, designs, requisitos ou projetos.
Defeitos e retrabalho
Corrigir erros, mal-entendidos, falhas de integração ou problemas de qualidade que poderiam ter sido detectados antes.
Processamento excessivo
Mais análise, documentação, controles, reuniões ou sofisticação técnica do que a decisão ou o produto necessita.
Movimentação desnecessária / troca de contexto
Pessoas alternando repetidamente entre ferramentas, projetos, prioridades, ambientes ou contextos mentais.
Conhecimento não utilizado
Decisões tomadas longe das pessoas que possuem conhecimento técnico, de cliente, operacional ou de domínio relevante.
Uma pergunta Lean para equipes de software
Se esta atividade desaparecesse amanhã, o resultado para o cliente ou para o produto pioraria? Se não, por que estamos fazendo isso?
Valor: a pergunta essencial vem antes do trabalho
O Lean começa pelo valor porque o desperdício não pode ser identificado de maneira inteligente sem que se saiba o que a organização está tentando alcançar. Uma equipe pode considerar uma atividade desnecessária enquanto outra, corretamente, a vê como essencial para segurança, confiabilidade ou conformidade. O valor fornece o ponto de referência.
No desenvolvimento de produtos, valor não é sinônimo de quantidade de funcionalidades. Uma pequena mudança que elimina uma grande frustração do cliente pode gerar mais valor do que um grande release contendo dez funcionalidades de baixo impacto. Uma melhoria técnica que reduz o risco de indisponibilidade pode criar valor mesmo que os clientes nunca a percebam diretamente. Um controle de segurança pode proteger a confiança e a viabilidade regulatória. O desafio do , portanto, não é maximizar o output, mas maximizar o valor do produto resultante do trabalho da .
É aqui que o muda a economia de um backlog. Um backlog não é uma promessa de concluir tudo o que contém. A presença de um item não prova que ele merece ser implementado. Toda funcionalidade possui custo de oportunidade: enquanto a equipe a constrói, outra coisa deixa de ser construída. O foco Lean incentiva as equipes a perguntar continuamente qual trabalho é essencial agora, qual pode esperar e qual jamais deveria ser realizado.
A mesma lógica se aplica dentro de uma . A ajuda a criar foco. Em vez de tratar uma como um contêiner que precisa ser preenchido com o maior número possível de tarefas desconectadas, a equipe trabalha em direção a um objetivo coerente. Quando surge novo conhecimento, o escopo detalhado pode mudar enquanto o objetivo permanece como uma âncora útil. Isso reduz o desperdício decorrente de esforço fragmentado.
Ciclos pequenos, lotes pequenos e aprendizagem mais rápida
Um dos insights mais fortes do Lean é que grandes lotes criam atrasos e riscos ocultos. Quando o trabalho se acumula por muito tempo antes de chegar à etapa seguinte, os problemas permanecem sem ser descobertos. Um grande pacote de requisitos pode esconder mal-entendidos por meses. Uma branch extensa pode ocultar conflitos de integração. Um grande release pode combinar tantas mudanças que o diagnóstico se torna difícil. Um grande portfólio de projetos simultâneos pode espalhar a atenção de especialistas por dezenas de prioridades concorrentes.
Lotes menores reduzem a distância entre causa e efeito. Uma pequena fatia de funcionalidade pode ser implementada, integrada, inspecionada e discutida mais cedo. Os problemas são expostos enquanto o contexto ao redor ainda está fresco. A equipe recebe evidências antes que trabalho adicional demais passe a depender da suposição original.
Isso não equivale a dizer "torne tudo minúsculo". O ainda precisa fazer sentido economicamente. Dividir o trabalho em partes que não conseguem produzir evidências úteis gera fragmentação administrativa. O objetivo é encontrar Increments pequenos o suficiente para avançar e aprender rapidamente, mas completos o bastante para produzir um resultado valioso ou inspecionável.
As Sprints do são um forte exemplo de ciclos de aprendizagem delimitados. Uma dura no máximo um mês, e Sprints mais curtas geram mais ciclos de aprendizagem ao mesmo tempo em que limitam o risco. A equipe cria um utilizável que atende à , inspeciona progresso e resultados e se adapta. A estrutura impede que o trabalho desapareça em uma fase de projeto indefinida.
Ciclos pequenos também melhoram a qualidade das decisões porque o planejamento ocorre mais próximo da execução. Em vez de tomar todas as decisões detalhadas com meses de antecedência, o pode evoluir à medida que a equipe aprende. A fornece direção de prazo mais longo, enquanto Goals e Backlogs operam em um horizonte mais curto. O foco Lean e o do se reforçam mutuamente.
Por que fazer mais trabalho não significa produzir mais valor
A ilusão de produtividade mais perigosa no trabalho do conhecimento é equiparar utilização a valor. Se um especialista fica ocioso por dez minutos, a gestão pode enxergar desperdício. Como consequência, as organizações preenchem a agenda de todas as pessoas, iniciam mais projetos e empurram mais trabalho para o sistema. A utilização local aumenta. O fluxo de ponta a ponta, porém, frequentemente piora.
Imagine cinco equipes que dependem do mesmo especialista de segurança. Para garantir que esse especialista esteja sempre ocupado, a organização inicia iniciativas suficientes para manter uma fila permanente. O especialista atinge 100% de utilização, mas todas as equipes esperam. O aumenta. O trabalho envelhece. A troca de contexto cresce. As equipes fazem suposições enquanto aguardam. O retrabalho aumenta. O especialista parece eficiente enquanto o sistema se torna mais lento.
O , portanto, distingue eficiência de recursos de . Eficiência de recursos pergunta se cada pessoa ou máquina está sendo utilizada. pergunta quão rapidamente o trabalho valioso se move da necessidade até a conclusão. No desenvolvimento complexo de produtos, alguma capacidade disponível pode ser economicamente útil porque permite que as pessoas respondam a problemas, colaborem, revisem trabalho, melhorem automações, aprendam e removam gargalos.
Outra armadilha de produtividade é maximizar o número de funcionalidades construídas. Suponha que a Equipe A inicie doze funcionalidades e conclua quatro. A Equipe B inicia seis e conclui cinco, incluindo aquela que os clientes mais valorizam. A Equipe A tem mais atividade. A Equipe B tem mais valor utilizável e menos estoque inacabado.
É por isso que a expressão "pare de começar, comece a terminar" combina com o . Trabalho inacabado já consumiu capacidade, mas ainda não pode produzir o benefício pretendido. Além disso, ele cria carga cognitiva e custo de coordenação. Limitar o () não é preguiça. É um método para proteger o fluxo e aumentar a probabilidade de que o esforço se transforme em valor concluído.
Uma distinção econômica simples
Output é aquilo que a equipe produz. Outcome é aquilo que muda em razão desse output. O pergunta continuamente se mais output está realmente melhorando o outcome.
Como o se relaciona com o
O Scrum Guide afirma diretamente que o é fundamentado no e no . Ele resume a contribuição Lean em uma frase concisa: o reduz desperdícios e concentra-se no essencial. O não fornece, em seguida, um kit de ferramentas Lean separado. Em vez disso, muitos elementos do framework criam condições nas quais trabalho, atraso e complexidade desnecessários se tornam mais fáceis de enxergar e reduzir.
Elemento do
Interpretação Lean
Um
Cria uma única visão ordenada do trabalho do produto, em vez de múltiplas filas concorrentes de requisitos.
Fornece um objetivo de prazo mais longo que ajuda a distinguir trabalho essencial de oportunidades que desviam o foco.
Cria foco durante a e reduz a tentação de maximizar o de tarefas desconectadas.
Sprints curtas
Limitam o horizonte de planejamento e de risco e criam oportunidades frequentes de aprendizagem.
utilizável
Incentiva a conclusão de trabalho valioso em vez do acúmulo de grandes estoques de trabalho parcialmente concluído.
Torna a qualidade visível e reduz retrabalho oculto e falso progresso.
Reduz handoffs desnecessários de e aproxima as decisões do conhecimento relevante.
Inspeciona outcomes e mudanças no ambiente para que o trabalho futuro possa ser reordenado com base em evidências.
Fornece um ciclo formal para melhorar qualidade e eficácia e eliminar atritos recorrentes.
Framework mínimo
O define apenas os elementos essenciais, deixando as equipes livres para adicionar práticas úteis ao seu contexto.
Distinção importante para a
não é manufatura Lean implementada em software. O faz parte da base teórica do , enquanto o possui suas próprias accountabilities, eventos, artefatos, commitments, valores e pilares empíricos.
Foco no essencial: por que o é intencionalmente minimalista
O minimalismo do é fácil de interpretar incorretamente. Como o framework contém relativamente poucos elementos definidos, algumas organizações concluem que ele está incompleto e imediatamente adicionam camadas de papéis, documentos, gates, reuniões, comitês de aprovação e mecanismos de status. Algumas adições podem ser necessárias. Outras recriam exatamente o desperdício que um framework leve torna visível.
O Scrum Guide descreve o como propositalmente incompleto. Isso significa que ele define apenas o necessário para implementar a e permite que muitos processos, técnicas e métodos sejam utilizados dentro do framework. As equipes podem usar user stories, story maps, práticas ,,,, architecture decision records, verificações automatizadas de segurança e muitas outras técnicas. Nenhuma delas se torna um requisito do apenas por ser útil.
Uma interpretação Lean é adicionar estrutura somente quando essa estrutura resolve um problema real. Se um relatório diário duplica informações que já estão visíveis no e não apoia nenhuma decisão, ele pode ser desperdício. Se uma revisão de arquitetura previne um risco regulatório ou de segurança grave, ela pode ser essencial. A resposta depende de valor e evidência, não de ideologia.
Essa mentalidade protege o da inflação processual. Com o tempo, organizações tendem a acumular processos. Cada incidente cria uma nova aprovação. Cada mal-entendido cria um novo formulário. Cada falha cria outra reunião. A menos que o sistema remova periodicamente controles obsoletos, o custo de coordenação continuará crescendo. O dá à e à organização permissão para perguntar quais mecanismos ainda justificam seu custo.
Exemplo prático - funcionalidades demais, valor de menos
Considere uma empresa desenvolvendo um portal de autoatendimento para clientes de uma operadora de telecomunicações. A liderança aprovou trinta funcionalidades para o próximo trimestre: exportação de faturas, personalização de perfil, modo escuro, banners promocionais, histórico de endereços, upgrades de serviço, chat de suporte, alertas de uso, download de contratos, métodos de pagamento e muitas outras. Várias equipes iniciam o trabalho simultaneamente para que "nada fique esperando".
Após quatro semanas, dezenove funcionalidades estão em andamento. Designers aguardam feedback sobre alguns itens. aguardam mudanças de API em outros. Os ambientes de teste contêm diversas branches incompatíveis. Revisores de segurança possuem uma fila de oito revisões pendentes. Product Managers gastam grande parte do tempo coordenando dependências. Os dashboards de utilização parecem excelentes porque todos estão ocupados. Os clientes não receberam nada.
Uma resposta orientada pelo Lean começa restaurando o foco. O analisa as evidências e descobre que a maior fonte de contatos de clientes é a confusão sobre faturas e status de pagamento. Em vez de otimizar igualmente todas as trinta funcionalidades, o é reordenado em torno de uma relacionado ao autoatendimento de cobrança.
A cria uma focado em permitir que os clientes compreendam uma fatura e confirmem se o pagamento foi recebido. A equipe conclui um pequeno de ponta a ponta, em vez de iniciar muitos componentes. A exige testes automatizados, observabilidade, verificações de segurança e prontidão para deployment, reduzindo trabalho de qualidade oculto.
Na , representantes do atendimento ao cliente e stakeholders inspecionam a nova capacidade. O feedback mostra que a terminologia da fatura, e não a função de exportação, é a principal fonte de confusão. O altera as prioridades futuras. Uma funcionalidade planejada de personalização de PDF é adiada. Uma melhoria menor de linguagem e uma explicação do status de pagamento avançam na prioridade.
Na , a equipe identifica outra fonte de desperdício: as revisões de segurança acontecem tarde demais. O ajuda a organização e a equipe a experimentar o envolvimento antecipado de especialistas de segurança e a automatização de verificações repetíveis. A espera diminui nas Sprints seguintes.
Observe o que melhorou. A equipe não simplesmente "trabalhou mais rápido". Ela reduziu o trabalho simultâneo, concluiu uma proporção maior do que começou, levou evidências de alto valor aos clientes mais cedo, removeu escopo de baixo valor, expôs um gargalo de qualidade e encurtou o feedback. A quantidade de atividade pode até ter diminuído, mas a quantidade de valor útil aumentou. Isso é em um contexto .
Interpretações equivocadas comuns
Interpretação equivocada
Interpretação mais adequada
Lean significa cortar pessoas.
Lean concentra-se em melhorar o sistema de trabalho e eliminar desperdícios, não em tratar as próprias pessoas como desperdício.
Lean significa que todos devem estar 100% utilizados.
Maximizar a utilização local pode criar filas e tornar mais lento o fluxo de ponta a ponta.
Desperdício é tudo aquilo que o cliente não vê.
Alguns trabalhos invisíveis ao cliente são essenciais para segurança, confiabilidade, conformidade, manutenibilidade ou valor futuro.
Lotes pequenos significam dividir tudo em tarefas minúsculas.
O objetivo são unidades pequenas e significativas de valor ou aprendizagem, e não fragmentação administrativa.
exige ou limites de .
Essas práticas podem complementar o , mas não são exigidas pelo Scrum Guide.
Lean significa construir menos funcionalidades independentemente do contexto.
Lean significa maximizar valor enquanto minimiza trabalho desnecessário; às vezes, uma quantidade significativa de trabalho é necessária.
Mais velocity significa mais valor.
Uma métrica de entrega pode descrever output ou capacidade, mas valor depende de outcomes e impacto no produto.
Um backlog cheio é saudável.
Um backlog grande pode conter incertezas, suposições obsoletas e estoque que talvez jamais mereça implementação.
Como o ajuda no raciocínio para a
O aparece explicitamente na , mas questões da frequentemente testam a ideia de forma indireta. O exame pode descrever uma equipe sobrecarregada de trabalho, um tratando o como um compromisso fixo, um adicionando relatórios desnecessários, uma equipe carregando itens incompletos entre Sprints ou stakeholders medindo sucesso apenas por output. O raciocínio correto frequentemente envolve foco, transparência, valor, qualidade, autogerenciamento e redução de trabalho desnecessário.
Um hábito útil para o exame é perguntar se uma resposta aumenta valor e aprendizagem ou apenas aumenta atividade e controle. Outro é perguntar se uma prática proposta é realmente exigida pelo . Uma técnica sofisticada pode ser útil e, ainda assim, opcional. A natureza leve do significa que a equipe não deve confundir processo local com definição do framework.
Lembre-se também de que o não substitui as . O continua accountable por maximizar valor e gerenciar o de forma eficaz. continuam accountable por criar um utilizável e adaptar seu plano. O continua accountable por estabelecer o e melhorar a eficácia. Eventos, artefatos, commitments, pilares e valores continuam fazendo parte do mesmo que alguém acredite que removê-los seria "mais lean". Remover feedback ou transparência necessários não é redução de desperdício; é enfraquecimento do sistema de controle empírico.
Modelo mental para a
O pergunta: o que é essencial, o que cria valor e o que é desperdício? O responde a essas perguntas dentro de um framework empírico com accountabilities claras, eventos, artefatos, commitments e ciclos curtos de aprendizagem.
Um mapa mental compacto do Lean para o
Lente Lean
Conexão com o
Valor
, accountability do , ordenação do
Reduzir desperdício
Foco, estrutura leve, remoção de trabalho e coordenação desnecessários
Fluxo
Concluir trabalho utilizável, reduzir filas e dependências ocultas
Foco em concluir trabalho Done em vez de maximizar inícios
Qualidade na origem
e accountability de qualidade dos
Aprendizagem contínua
,,
Pessoas e conhecimento
e
Inspeção e adaptação do produto e da forma de trabalhar
Conclusão: otimize o , não a ocupação
O muda a pergunta de "Como podemos fazer todos produzirem mais?" para "Como o valor pode fluir pelo sistema com menos desperdício, atraso, incerteza e esforço desnecessário?" Essa mudança é especialmente importante no desenvolvimento de produtos porque atividade é fácil de gerar, enquanto valor é difícil de provar.
Os conceitos básicos do Lean são simples, mas exigentes na prática. Comece pelo valor de que um cliente ou stakeholder realmente precisa. Examine o caminho pelo qual esse valor é criado. Remova trabalho que pouco contribui. Reduza espera e handoffs. Evite trabalho inacabado em excesso. Use ciclos menores para expor problemas mais cedo. Mantenha a qualidade para que mudanças futuras continuem economicamente viáveis. Melhore continuamente o sistema em vez de compensar um sistema ruim com esforços heroicos.
O incorpora esse pensamento sem se tornar uma metodologia Lean. Sua estrutura empírica e leve cria um ambiente disciplinado para concentrar-se no essencial: uma , um , objetivos significativos, Sprints curtas, Increments Done, inspeção frequente e adaptação contínua. O framework é pequeno porque o trabalho em si é complexo; prescrições desnecessárias reduziriam, em vez de aumentar, a de responder de forma inteligente.
A lição prática mais importante é que mais trabalho não significa automaticamente mais valor. Mais funcionalidades podem criar mais complexidade. Mais projetos simultâneos podem criar filas maiores. Mais processos podem tornar as decisões mais lentas. Mais utilização pode gerar menor capacidade de resposta. Mais documentação pode criar menos clareza se ninguém a mantiver ou utilizar. O ensina a julgar o trabalho por sua contribuição para valor e fluxo, e não por seu volume visível.
Na minha visão, essa é uma das ideias mais úteis para um futuro . Equipes raramente sofrem porque as pessoas não estão ocupadas o suficiente. Elas sofrem porque os objetivos são pouco claros, as prioridades competem, o trabalho é grande demais, o feedback é lento demais, problemas de qualidade geram retrabalho, dependências geram espera e sistemas organizacionais recompensam iniciar em vez de concluir. Um que compreende o aprende a olhar além do esforço individual e a melhorar o sistema no qual o valor é criado.
Principais aprendizados
O concentra-se em criar o valor necessário com menos desperdício e esforço desnecessário.
As raízes históricas do Lean estão fortemente associadas ao Toyota Production System, mas ideias Lean hoje se aplicam a muitas formas de trabalho do conhecimento.
Valor é definido pelo problema e pelo outcome que importam, não pelo volume de funcionalidades ou tarefas concluídas.
Desperdício em software pode incluir espera, handoffs, superprodução, defeitos, retrabalho, excesso de , processamento excessivo e conhecimento não utilizado.
Lotes pequenos e ciclos curtos reduzem o tempo entre uma suposição e a evidência.
Alta utilização pode criar filas; o importa mais do que manter todos os recursos constantemente ocupados.
Trabalho inacabado consome capacidade sem ainda produzir o benefício pretendido.
O é fundamentado no e no ; o Scrum Guide afirma explicitamente que o reduz desperdícios e concentra-se no essencial.
O é intencionalmente leve e pode incorporar muitas práticas complementares sem exigi-las.
Remover elementos necessários do em nome de "ser lean" enfraquece transparência, inspeção, adaptação e entrega de valor.
