
O nome “Pensamento Lean” nasceu nos 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, just-in-time, qualidade total, 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
O Lean Software Development provê uma série de princípios sobre a aplicação de um conjunto de técnicas oriundas da indústria e aplicadas em desenvolvimento de software. Esses princípios foram amplamente adotados na manufatura japonesa onde vieram a ser conhecidos como “Lean Production“.
Nesse contexto, Mary e Tom Poppendieck identificaram sete princípios fundamentais denominados “Lean Principles” e mostraram como eles podem ser aplicados em abordagens de desenvolvimento de software ágil. Ao longo dos princípios, eles introduziram também e vinte e dois “thinking tools” para traduzir cada princípio em práticas ágeis, em particular eles apresentaram um toolkit para gerentes, lideres técnicos e gerentes de tecnologia que esperam adicionar valor ao invés de criarem barreiras para suas equipes de projetos, como os a seguir:
- Melhoria contínua em direção à excelência: desenvolvimento de software é como um exercício de descoberta.
- Gerenciando incertezas: “decidir o mais tardio possível” para adicionar mudanças dentro do sistema.
- Reduzindo o fluxo de valor: desenvolvimento rápido, feedback, e melhorias contínua.
- Dê autonomia ao time e ao indivíduo sem coordenação e comando-controle.
- Software com qualidade: promovendo coerência, usabilidade, alta coesão, manutenabilidade e adaptabilidade.
Princípio 1: Elimine o Desperdício
Elimine qualquer coisa que não agrega valor ao produto e que não são percebidos pelo cliente. No pensamento Lean, o conceito de desperdício é um grande obstáculo. Se um programador implementa mais funcionalidades do que o necessário de imediato, isso é um desperdício. Se a equipe produz documentação de análise apenas para estar em concordância com o processo, isso é um desperdício. Se o time entrega funcionalidades incompletas, isso é um desperdício. O ideal é perceber o que os clientes precisam para então fazer ou desenvolver e entregar exatamente o que eles querem, o mais rápido possível. Qualquer outra coisa que fica que não satisfaça as necessidades do cliente é um desperdício.
Princípio 2: Amplifique o Aprendizado
Desenvolvimento é um exercício de descoberta, enquanto produção é um exercício de redução de variações, e por essa razão, aprender a abordagem de desenvolvimento resultam em práticas que são bastante diferentes do que aprender abordagens de práticas de produção.
Desenvolvimento é como fazer uma nova receita, enquanto produção é como fazer um prato. Receitas são formuladas a partir da experiência de chefes de cozinha. Desenvolver uma receita é um processo de descoberta, onde o chefe utilizando de toda sua experiência e dos ingredientes a sua disposição faz iterações, experimentações, até encontrar a melhor combinação de ingrediente para o melhor sabor. Não se espera que os chefes obtenham uma receita perfeita na primeira tentativa; espera-se produzir diversas variações como parte do processo de aprendizagem. Desenvolvimento de software é concebido de forma melhor com um processo de aprendizado similar ao de criar uma nova receita. A melhor abordagem para melhorar o ambiente de desenvolvimento de software é pelo conhecimento amplificado, em um espiral de criação do conhecimento.
Princípio 3: Decida o Mais Tarde Possível
Práticas de desenvolvimento que assegurem a tomada de decisão tardia são mais eficazes em domínios que envolvem incertezas. Decidir o mais tarde possível significa manter suas opções aberta o maior tempo possível. 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. A principal estratégia de atrasar as decisões em um desenvolvimento de um sistema complexo é construí-lo com a capacidade de suportar mudanças.
Princípio 4: Entregue o Mais Rápido Possível
Sem entregas rápidas é impossível haver decisões tardias durante o desenvolvimento. Sem entregas rápidas não haverá feedbacks confiáveis no curto prazo. No desenvolvimento o ciclo de descoberta é fundamental para a aprendizagem: estórias, implementação, feedback e melhorias. Quanto menor esse ciclo, mais pode ser aprendido.
Uma vez que os clientes decidam o que querem, seu objetivo deve ser para criar esse valor tão rapidamente quanto possível. Entregas rápidas garante que o cliente vai ter o que ele precisa hoje, e não o que ele precisa amanhã.
Em uma organização madura em desenvolvimento de software, tudo isso acontece em um fluxo rápido em resposta a uma necessidade dos clientes.
Princípio 5: Dê autonomia à Equipe
“Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.” Esse já é um dos doze princípios por atrás do manifesto ágil. A equipe de trabalho deve ter autonomia para adequar seus próprios processos de engenharia, fazer os seus próprios compromissos e reunir as informações necessárias para alcançar seus objetivos e cumprir as suas metas. Equipes autônomas são multidisciplinares, possuem indivíduos multidisciplinares, trabalham bem com a interdisciplinaridade e promovem a autor organização. Nesse tipo de equipe mais um princípio ágil é adicionado: “em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.”
Nesse ambiente, a equipe de desenvolvimento está em melhor posição para saber responder a problemas difíceis e a pedidos urgentes. A melhor maneira de ter certeza de estar fazendo as coisas corretas é trabalhar diretamente com o cliente para entender suas necessidades, colaborar com os colegas para descobrir como satisfazer essas necessidades, e, frequentemente apresentar os resultados aos interessados para ter certeza de que estamos no caminho certo.
Princípio 6: Construa com Integridade
Qualidade é inegociável. Entregue qualidade intrínseca e explícita aos seus cliente, se eles perceberem isso, significa que foi uma entrega de qualidade. Mary e tom Poppendieck em seu livro identificaram duas dimensões de integridade: integridade percebida e integridade conceitual. A integridade percebida significa que a totalidade do produto alcança um equilíbrio entre as funções, usabilidade, confiabilidade, economia e isso encanta o cliente. A integridade conceitual significa que os conceitos centrais do sistema de trabalho em conjunto são facilitados e coeso. Ela é fator crítico de sucesso para a integridade percebida.
Um produto é considerado ter integridade percebida quando o cliente experimenta o produto e diz: Isso! Era exatamente isso que eu queria! Esse exemplo acontece com frequencia em aplicações do google. Eu particularmente senti isso quando experimentei o novo recurso de caixa prioritária do gmail.
Um produto de software deve estar sempre adicionando integridade. Isso prolonga o seu ciclo de vida operacional. Software com integridade possuem 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.
Princípio 7: Visualize o Todo
Integridade em sistemas complexo exigem um conhecimento holístico e profundo em diversas áreas. Um dos problemas mais intratáveis com o desenvolvimento do produto é que especialistas em qualquer área (por exemplo, banco de dados ou design) têm uma tendência natural em maximizar o desempenho da parte do produto que representa a sua própria especialidade, ao invés de focar no desempenho do sistema como um todo. Muitas vezes, a integridade do produto como um todo pode ser prejudicado se as pessoas atenderem aos seus próprios interesses especializados em primeiro lugar.
Tradução do inglês para português
práticas de desenvolvimento que assegurem a tomada de decisão tardia são eficazes em domínios que envolvem incerteza




