Reduzindo o desperdício na sua TI com o Pensamento Lean

O pensamento Lean, que foca na redução do desperdício na produção de produtos, foi popularizado a partir dos seus resultados práticos no Japão a partir dos anos 50 e em particular no sistema de produção da Toyota a partir do excepcional trabalho de Taiichi Ohno.

O desperdício é muitas vezes sutil e ocorre em escala quase imperceptível ao nosso redor. Por exemplo, uma torneira pingando uma gota a cada 5 segundos representa mais de 20 litros de água desperdiçados em apenas um dia, ou 600 litros de água por mês.

Pense Lean para Desenvolvimento de Software.

Este pensamento da redução do desperdício tem sido estudado e adaptado para o desenvolvimento de software há alguns anos já.

O livro emblemático nesta área é o “Lean Software Development” by Mary and Tom Poppendieck. Neste livro, os autores divulgam sete princípios básicos para a produção de software com foco naquilo que é realmente essencial.

Alguns destes pilares são citados abaixo através de pequenos exemplos.

1. Elimine gastos desnecessários

A tendência de gerar requisitos especulativos (“eu acredito que isso será interessante para o usuário”) é um excelente exemplo de gasto desnecessário. Pesquisas mostram que quase 50% das funcionalidades de sistemas de informação não são usadas ou são raramente usadas no dia a dia de sistemas.

Um outro exemplo de desperdício é o conceito de complexidade arquitetural acidental, que é a complexidade não inerente a um problema. Por exemplo, quando um arquiteto decide usar uma tecnologia mais complexa do que o problema requer ele introduz uma complexidade acidental no projeto, o que em última instância levará a desperdícios.

Dica: Atenha-se aos requisitos estritamente necessários e projete arquiteturas que gerem real valor de negócio.

2. Pratique qualidade contínua

Defeitos significam desperdícios. Aceitar defeitos como parte do processo é no, mínimo, gastar tempo e dinheiro do seu cliente e não respeitar o ambiente que você trabalha. Defeitos não devem ser tolerados em nenhum hipótese. Se você identificou um defeito, elimine-o o mais rápido possível.

Ainda melhor, trabalhe correto da primeira vez para evitar defeitos. O uso de práticas técnicas que eliminam defeitos deve ser um princípio orientador fundamental para toda a equipe técnica. Práticas como código limpo e metodologias como o TDD são bons exemplos nesta linha.

3. Crie conhecimento através da prática (e não nas torres de marfim)

Planos são bons, mas o conhecimento verdadeiro é obtido através de aprendizado que vem da experimentação e adaptação. Em termos práticos, devemos abolir as gerências que criam planos desconectados da realidade em torres de marfins.

Gerentes e arquitetos devem acompanhar o trabalho do time de desenvolvimento no dia a dia, aprender com os resultados e modificar o curso de ação em tempo real através da comunicação do conhecimento que funciona em campo.

4. Decida o mais tarde possível 

Detalhar requisitos e casos de testes em profundidade no começo do projeto é buscar tomar as decisões o mais cedo possível. Na prática, isso levar a um enorme retrabalho e desperdício, além de adiar a entrega dos elementos de maior valor do projeto.

A abordagem “primeiro em amplitude e depois em profundidade” é um exemplo de uma abordagem mais racional de montagem de requisitos. Ou seja, primeiro colete as histórias do usuário em amplitude. Você irá trabalhar nas regras de negócio e detalhes específicos da história apenas antes da mesma ser implementada, testada e implantada.

5. Entregue rapidamente

Um requisito deve ficar o menor tempo possível dentro da “esteira de produção” de um time de desenvolvimento. O acúmulo de requisitos que não são entregues gera filas, causa a alternância entre tarefas de implementação e testes e afeta a economia de projetos.

As práticas da integração diária, entrega diária, entrega continua e o uso de devops são instrumentos modernos que conspiram para promover esta prática.

6. Respeite pessoas

Steve McConnell e outros autores mostram que desenvolvedores sob pressão introduzem até 40% mais defeitos que desenvolvedores do mesmo nível em ambientes controlados. Defeitos são desperdícios, como dissemos anteriormente. Este é um exemplo prático de como desrespeitar pessoas por ser ruim do ponto de vista econômico.

Diversos outros estudos (Barry Boehm) mostram que pessoas são, isoladamente, o fator mais importante para a eficiência de projetos. Se você quer pessoas e projetos produtivos, portanto, crie um ambiente que permita que que pessoas estejam motivadas e felizes.

Custos não existem para serem calculados. Custos existem para serem reduzidos, Taiichi Ohno.

 


Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *