InfoQ

InfoQ

Artigos

Meus Favoritos

Faça oLogin ou Cadastre-se para ativar o recurso de favoritos por tempo ilimitado.

O conteúdo foi adicionado aos favoritos!

Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.

Uma Introdução ao Pensamento Lean para Software

Postado por Jacky Li , traduzido por Wagner R. Santos em 30 Out 2008

Seções
Processos e Práticas,
Arquitetura e Design
Tópicos
Metodologias ,
Entregando Valor ,
Agile
Tags
Melhoria Contínua ,
Lean

Para os desenvolvedores e líderes que estão chegando em Agile através de Scrum ou XP, todo este assunto em torno de Lean pode ser um pouco misterioso. Aqui esta uma introdução ao Pensamento Lean e como ele é aplicado ao desenvolvimento de software, do Editor de Agile da InfoQ China, Jacky Li. Ning Lu, da ThoughtWorks chinesa, cuja conversa é resumida aqui, enfatizou o maior obstáculo para Lean ou Agile, como sendo: o preconceito que se formou durante o período de produção em larga escala.

No inicio deste ano, a InfoQ da China promoveu uma Open Party em conjunto com a Matrix, ThoughtWorks da China, Java User Group da Beijing<;a>, Google Group AgileChina e Python User Group de Beijing, etc. A Open Party, realizada seguindo os moldes das inconferências OpenSpace, aconteceu no escritório da ThoughWorks China, e contou com cerca de 30 congressistas. Ning Lu, um consultor da ThoughtWorks, fez um belo discurso: Pensamento Lean com Exemplos. Ele analisou o maior obstáculo sobre a adoção Lean ou Agile, e explicou como reconhecer e reduzir desperdícios. Este artigo vai resumir a palestra a partir da perspectiva de um desenvolvedor Ágil.

A atividade iniciada com uma simples reunião diária, seguida por uma votação em todos os tópicos – nós tivemos uma série de tópicos interessantes naquele dia, incluindo “O crescimento da comunidade de software livre”, “GPE”, “Mingle”, “Earlang”, etc. Os tópicos foram separados em 3 trilhas, e Ning Lu deu sua palestra em uma delas. Ele iniciou com o Sistema de Produção da Toyota e Manufatura Lean, depois abordou o maior obstáculo na adoção de Lean ou Agile: o preconceito que se formou durante o período de produção em larga escala. Ning Lu também falou a respeito de como a Toyota explorou o seu próprio sistema de produção. Ele comentou:

Lean é a tecnologia que pode reconhecer e eliminar os desperdícios – atividades que não produzem valor adicional.

Ele explicou como reconhecer e eliminar desperdícios com os 5 Princípios Lean* com exemplos, e listou diversos fenômenos típicos que geralmente acompanham estes desperdícios:

 

  • Estoque – enquanto controle de estoque pode evitar provisão ineficiente, isto também aumenta o custo, e torna a empresa insensível ao mercado. A Empresa pode se deparar com sobrecarga de estoque enquanto os requisitos do mercado mudam. Estoque está em todo o lugar. Pense a respeito de suas pratileiras, refrigeradores e no trabalho que termina sem nenhum resultado.
  • Lotes de Processos e espera em filas – assim como as intersecções que estão sempre congestionadas, em que a maioria dos motoristas têm que passar pela experiência do “aguarde”.
  • Desequilíbrio – exemplo: temporada de vendas e períodos de vendas fracas.
  • Complicação – se as coisas são muito mais complicadas do que você esperava, então deve haver algum desperdício. Por exemplo: um documento complicado ou processo.
  • Foco em "seguir os regulamentos" – nem todas as regras e regulamentações são sensatas e, além disso, elas não devem ser valiosas para os clientes.

Ning Lu enfatizou que:

Qualquer trabalho não finalizado é um tipo de desperdício. Lean ou Agile pode minimizar o trabalho não acabado.

Puxa, isso dá a entender que todo o código sendo feito também é um desperdício. Isto é loucura! Se nós seguirmos as palavras acima e tentarmos minimizar os desperdícios, então teremos a impressão que nós devemos parar de codificar! Como podemos entregar algo ao cliente então? E de onde é que vem o valor?

OK, vamos tentar analisar isto de outra maneira. Talvez você possa reconhecer estas palavras da “Preconstrução”:

Você consegue prever tudo? Não. As decisões que você toma hoje são as finais? Não. É praticamente impossível pensar em tudo ou saber tudo no início de um projeto.

Na verdade, nem mesmo o cliente terá certeza de que a função é exatamente o que ele precisa, antes que possa ser provado o valor a ele. Se nós tomarmos um trabalho não finalizado como forma de desperdício, então, estaremos dedicados a transformar código em software funcionando, e implantar este software em um ambiente de produção o mais rápido possível. Mais tarde recolheremos o feedback e os requisitos mais detalhados do cliente, e aí sim poderemos concluir se a funcionalidade requerida está finalizada(ou não). Quanto mais trabalho inacabado nós tivermos, maior será o risco.

Se comprarmos esta idéia, então vamos precisar encontrar uma solução para eliminar o desperdício, ex. trabalho inacabado. O que nós devemos fazer?

Os 5 Princípios Lean nos dão uma direção passo a passo bastante clara, e quando isto é aplicado ao desenvolvimento de software, temos uma caixa de ferramentas muito útil, composta de inúmeras práticas ágeis que podem nos ajudar a resolver qualquer problema concreto. Para reduzir o tempo entre o código ser finalizado, testado e integrado, nós precisamos tomar pequenos passos adiante, fazendo check-ins freqüentes e integração contínua. Para reduzir o tempo entre a funcionalidade ser finalizada e o tempo em que ela começa a gerar valor para o cliente, precisamos entregar freqüentemente. Como você pode ver, Lean e Desenvolvimento Ágil são integrados perfeitamente neste ponto!

Quatro meses atrás, Amr Elssamadisy sugeriu na notícia, "Opinião: Refactoring é um Desperdício Necessário”:

...existem dois tipos de desperdício em Lean: desperdício puro, e desperdício necessário. Desperdício puro é aquele que não tem valor tanto para a equipe que está construindo o software quanto para o cliente que está usando o software. Desperdício necessário, por outro lado, é a melhor maneira conhecida atualmente de como fazer o trabalho mesmo se ele não traz valor para o cliente.

Ning Lu também falou sobre os tipos de desperdícios definidos em Lean, especialmente o segundo tipo, chamado de "desperdício necessário". Em sua opinião, teste, integração, refactoring e gerenciamento se caracterizam como este tipo de desperdício. Ele listou diversos padrões interessantes que são utilizados normalmente para reduzir estas formas de desperdício:

  • Trate-o de forma positiva: reduza o numero de membros do time e aumente os requisitos para o recrutamento.
  • Mude as tarefas pessoais para "tarefas do time": o time todo em conjunto se responsabiliza pelo trabalho de design, testes, e parte da integração. O time é auto-organizável. A responsabilidade do código é compartilhada pelo próprio time.
  • Separe as responsabilidades entre pessoas e máquinas: torne todo tipo de trabalho possível automatizado.
  • Faça o trabalho sempre antes do tempo, e freqüentemente: introduza desenvolvimento orientado a testes(TDD), faça testes unitários com freqüência, refactoring e integração em estágios iniciais. Tenha certeza de que todos possam ter um entendimento claro dos objetivos do projeto o mais cedo possível, e tenha certeza de que o status do projeto esteja sempre visível.

Para os interessados em mais leituras relacionadas a este tópico, o website de Mary e Tom Poppendieck oferece diversos artigos. Também, Jeff Xiong e Ye Zheng, consultores da ThoughtWorks da China, tem escrito artigos úteis sobre a relação entre Lean, Agile e desperdício: Agile – Eliminando Desperdícios (em Chinês). Os slides desta apresentação, também em chinês, podem ser baixado.

 

Veja o artigo original da InfoQ em chinês aqui:路宁谈精益思想——2008北京Open Party摘录, e a história deste evento, com alguns vídeos.

 

Mais um pouco de Lean por Bruno Lima Enviado
  1. Voltar ao topo

    Mais um pouco de Lean

    por Bruno Lima

    Eu vi esse video no site em ingles da InfoQ. Vale a pena para complementar esta matéria..
    www.infoq.com/presentations/Lean-Agile-Alan-Sha...

Conteúdo Educacional

Formando equipes de alto desempenho, parte 1: Início e fases de evolução

Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.

Business Model Canvas, passo a passo

O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.

Google Apps Script, Parte 2: Google Docs, triggers e envio de emails

Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.

Serviços de cloud computing PaaS: um guia para desenvolvedores Java

Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.

Canvas de Modelo de Negócios: uma contribuição para o sucesso de Startups

O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.

Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.

Entrevista com Rebecca Parsons Parte 1: Agile nas Empresas e Arquitetura Evolucionária

Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.