Eliminação de "Waste"
Um dos princípios Lean é eliminar o "Waste" (desperdício). Este conceito foi criado no final dos anos 1940 na indústria automobilística pela Toyota. Naquela época, produzir veículos era muito custoso, e as empresas precisavam cobrar preços muito altos dos clientes. A única forma da Toyota reduzir os preços dos carros era diminuir os custos de produção.
O que significa "Waste" em Lean?
„Waste" ou „Desperdício" é basicamente o oposto de „Value", ou seja, „Valor" (uma capacidade entregue ao cliente que lhe proporciona uma vantagem direta ou indireta). Por exemplo, uma reunião de equipe sem um motivo concreto é puro desperdício de tempo.
Aqui estão os sete tipos de desperdício identificados por Shigeo Shingo no Sistema Toyota de Produção (TPS):
Estoques: produtos inacabados (WIP: work in progress)
Superprodução: produzir mais do que a demanda exige
Processamento: etapas adicionais no processo que não são necessárias
Transporte: transportar mercadorias de um lugar para outro
Tempos de espera: intervalos entre as etapas individuais de processamento
Movimentação: movimentos desnecessários no processo
Defeitos: erros nos produtos que afetam suas características e funções
Quais são os tipos de desperdício no desenvolvimento de software?
Com base nos sete tipos de desperdício na indústria de manufatura, Mary e Tom Poppendiek definiram os sete tipos de desperdício no desenvolvimento de software:
Trabalho inacabado: Em cada Sprint os membros da equipe são responsáveis por um número definido de User Stories. No entanto, às vezes não conseguem concluir todas as stories. Então precisam descobrir por que não conseguiram, para que possam reduzir esse tipo de desperdício.
Features adicionais: Logo no início, o Product Owner criou uma visão e depois elaborou um Product Backlog com features priorizadas que agregam valor ao produto. No entanto, o Princípio de Pareto diz que muitas vezes não é necessário desenvolver todas as features, porque muitas delas são inúteis.
Reaprendizado: Em cada Sprint você acumula cada vez mais conhecimento que pode usar para não reinventar a roda constantemente.
Handover: Aqui o trabalho é passado para outra pessoa assim que a primeira termina. Como você pode combater isso? O melhor é eliminar as dependências entre as User Stories (e features) ou entregar todas as User Stories com dependências a uma única equipe para mitigar o risco.
Atrasos: É tudo aquilo que atrasa a entrega ou o início de uma atividade que agrega valor. Como você pode prevenir isso? Você precisa eliminar os gargalos e redesenhar qualquer processo lento para alinhar ambos.
Troca de tarefas: Isso acontece quando o Product Owner muda suas prioridades e os membros da equipe precisam mudar de uma User Story para outra sem poder concluí-la antes. A principal razão para isso geralmente é que o Product Owner não tem uma visão clara do produto ou que um concorrente lançou um novo produto no mercado e você quer adaptar e lançar seu próprio produto o mais rápido possível.
Defeitos: Este é um dos maiores problemas no desenvolvimento de software. Depois de um certo tempo, você gerou uma enorme montanha de dívida técnica e, a partir daí, precisa investir muito tempo e esforço para reduzi-la lentamente, Sprint após Sprint.
Para concluir, posso dizer que muitas pessoas acreditam que Lean não é uma boa abordagem para uma equipe que trabalha com Agile. Mas estão enganadas. Na verdade, toda empresa deveria aplicar Lean primeiro e depois passar para o Agile!!!
Este texto é do blog do Mario Lucero e foi traduzido por nós para o português.
Product Backlog Refinement
=> É assim que funciona um Backlog Refinement em equipes Scrum.
Como funciona uma Sprint Review em equipes ágeis?
=> Aqui você descobre como uma Sprint Review ideal pode acontecer.
