BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Uma Introdução ao Pensamento Lean para Software

Uma Introdução ao Pensamento Lean para Software

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.

 

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT