Teoria das Restrições: UltraFast + Exercício

1 Comentário

Brevíssimo Histórico

A Teoria das Restrições ou Theory Of Constraints (TOC), vem do pensamento de Eliyahu Goldratt ao tentar otimizar suas linhas de produção, após ler e refletir muito sobre Lean Manufacturing, teorema de pareto, entre muitas outras idéias.

Ao invés de ver a cadeia da produção como uma junção de vários processos, ele vê toda ela interligada e interdependente, direcionada e definida pela “meta” da empresa (nome do livro que divulgou sua teoria mundo afora), tornando possível traduzir todos os processos em função desta meta comum e assim encontrar onde estão as “restrições” da cadeia produtiva e otimiza-la como um todo.

A Meta e suas restrições

Antes de seguirmos para o processo de otimização, é essencial identificarmos qual a meta global do sistema a ser otimizado e quais serão as medidas para verificarmos como as mudanças ou ações nos subsistemas afetam esta meta global.

Então as restrições do sistema são as coisas que impedem um sistema de atingir um desempenho maior em relação à sua meta. Qualquer sistema tem bem poucas restrições, porém tem que ter pelo menos uma restrição senão seus lucros seriam infinitos.

5 regras para Otimização

1. Identificar a(s) restrição(s) do sistema.

2. Decidir como explorar a(s) restrição(s) do sistema.

3. Subordinar tudo o mais à decisão acima.

4. Elevar a(s) restrição(s) do sistema.

5. Se num passo anterior uma restrição foi quebrada, volte à primeira etapa, mas não deixe que a inércia cause uma restrição no sistema.

1. Identificar a restrição do sistema.

Numa fábrica haverá sempre um recurso que limita o seu fluxo máximo , assim como numa corrente há sempre um elo mais fraco. Para poder aumentar o desempenho do sistema ou a resistência da corrente, é necessário identificar o elo mais fraco. Numa fábrica, o recurso que estabelece o fluxo máximo é chamado de Recurso com Restrição de Capacidade (RRC) .

2. Decidir como explorar a restrição do sistema.

O recurso que limita o desempenho da fábrica já foi identificado. Agora precisamos tirar o máximo possível dele. Qualquer minuto perdido nesse recurso é um minuto a menos no nível de produção de todo o sistema, então precisamos garantir que sempre haja um estoque de segurança na frente da restrição para que ela não pare.

3. Subordinar tudo o mais à decisão acima.

Os outros recursos devem trabalhar ao passo da restrição, e não mais rápido ou mais devagar. Eles não podem deixar faltar material para a restrição trabalhar, pois assim ela pararia e o desempenho do sistema seria afetado negativamente. Por outro lado, os recursos não-restrição não devem trabalhar mais rápido que a restrição, pois não estariam aumentando o nível de produção da linha, estariam apenas aumentando o nível do estoque em processo.

4. Elevar a Restrição do Sistema.

No segundo passo nós tentamos tirar o máximo da restrição. Nesta etapa consideramos as várias alternativas para investir mais na restrição: mais turnos, mais um recurso idêntico em paralelo, bom isto não tem fim… certamente irá ocorrer é que resolvendo uma retrições novas restrições irão surgir, sim é isto mesmo, portanto chegamos ao próximo passo.

5. Se num passo anterior uma restrição foi quebrada, volte à primeira etapa, mas não deixe que a inércia cause uma restrição no sistema.

A preocupação aqui é com toda a cultura e política empresarial, pois o mais comum é que, mesmo que intuitivamente, das restrições derive várias das políticas empresariais. Quando uma restrição é quebrada temos que revisar as regras e processo, inclusive políticos dos nossos sistemas.

Com este processo fixamos o foco e esforços nos poucos pontos de um sistema que determinam seu desempenho (nas suas restrições), e assim podemos melhorar significativamente seu desempenho no curto prazo.

Aprenda praticando: PQ Game

Quer realmente aprender sobre TOC?

  • The Goal” – Eliyahu Goldratt
  • What is this thing called Theory of Constraints, and how can it be implemented?” – Eliyahu Goldratt
  • Breaking the Constraints to World Class Improvement” – Dettmer
  • Manual da Teoria das Restrições” – Cox e Spencer
  • Introduction to The Theory of Constraints.” – McMullen
  • KANBAN prático e eficaz!

    Deixe um comentário

    Apresentação de Rodrigo Yoshima (blog dele aqui), muito boa sobre práticas de Kanban.

    Para quem está vendo Lean e TOC, a identificação com os conceitos é imediata… aliás é tudo farinha da mesma fungada!!rsrrs!!

    Uma rapidinha sobre as práticas de LEAN

    1 Comentário

    Este tutorial do slide-share ficou muito bom, bem didático e direto em 23 slides!

    Mapeando o SCRUM no CMMI

    Deixe um comentário

    A demanda de documentação requerida pelo modelo CMMI com certeza faz frente a idéia da agilidade adquirida do Scrum quando tratando-se da gestão do desenvolvimento de software.

    As críticas feitas entre os dois posicionamentos são normalmente que:

    • Abordagens ágeis são criticadas devido ao fato de apresentarem muito pouco design de arquitetura e pouca documentação.
    • Abordagens rigorosas são criticadas por serem burocráticas e serem de difícil adaptação à mudança.

    Devemos sempre ter em mente que o modelo CMMI descreve “o que fazer”, enquanto a práticas de gestão ágil, como o Scrum, descrevem “o como fazer”.

    Deixando de lado as entrelinhas temos os 2 contra-pontos:

    Modelo de Maturidade e Excelência (CMMI): enxerga todo e qualquer processo dentro da empresa como sendo capaz de evoluir (amadurecer) de forma que a organização aprenda com seus próprios erros e acertos, para isso é necessário seguir uma série de práticas, normas e regras para alcançar os níveis de excelência estabelecidos através de métricas bem definidas, isto não leva em consideração o tempo nem os recursos gastos para o preenchimento, análise e gerenciamento destes documentos.

    Prática de Gestão Ágil (Scrum): viabiliza técnicas e processos de gerenciamento para que seja cumprido o objeto do projeto de maneira mais eficiente possível atingindo o máximo de expectativas do cliente com relação ao atendimento de requisitos. Na maioria das vezes os projetos são tão velozes que não há tempo hábil entre um projeto e outro para que haja o aprendizado da organização.

    Isso não quer dizer que seja impossível adotá-las em conjunto. Simplesmente é uma questão de adaptar as necessidades estabelecidas pelo CMMI (ações e documentação) de modo que não interfiram no modo como deveremos executá-las (práticas doScrum).

    Não estamos apenas focados no Scrum, outras metodologias ágeis como o TDD, FDD e XP podem ser conectadas aos processos do CMMI. Segue abaixo uma tabela comparativa das áreas de processo do CMMI e quais são satisfeitas por cada uma dessas metodologias.

    Artigo original em Inovatividade

    Tutorial Instantâneo de SCRUM

    Deixe um comentário

    Nada melhor do que explicar uma abordagem ágil de gestão de formal ágil… então iremos do vocabulário básico para dinâmica  e logo depois a aplicação. Assim rapidamente você poderá experimentar o uso prático do Scrum em seus projetos.

    Vocabulário Básico Scrum

    Antes de ser capaz de implementar Scrum, é importante estar familiarizado com algumas palavras-chave no vocabulário do Scrum.

    • SPRINT: esforço concentrado de aproximadamente 15~30 dias (a ser ajustado de acordo com o projeto) com a equipe focado na resolução das metas fixadas.
    • PRODUCT BACKLOG: lista de tarefas com prioridades constantemente revisadas.
    • SPRINT BACKLOG: lista dos itens de mais alta prioridade proveniente do product backlog, a serem realizados durante 1 sprint
    • SCRUM MASTER: é o mantenedor da dinâmica scrum na equipe e responsável por garantir a realização dos objetivos do sprint através da remoção de obstáculos que estejam impedindo o avanço da equipe.
    • PRODUCT OWNER: é a personificação do cliente e é responsável por priorizar o product backlog.
    • SCRUM TEAM: um grupo de 09/05 pessoas que se auto-organizam e têm uma responsabilidade conjunta para as tarefas concluídas.

    O Processo Scrum

    Esta é a figura típica que representa o processo Scrum:


    Agora vamos detalhar o processo básico passo-a-passo.

    1. Criar o Product Backlog - O Product Owner forma a visão do produto, gerando uma lista de tarefas macro que juntamento com o Scrum Team são mapeadas e priorizadas de acordo com a importância de cada funcionalidade para o product owner.

    2. Sprint Planning Meeting – após a criação do backlog, faz-se a primeira Sprint Planning Meeting, para realizar o planejamento do sprint. Na primeira fase da reunião, o owner descreve os objetivos do projeto e junto com a equipe seleciona do Product Backlog as tarefas macro que irão fazer parte do Sprint e quanto tempo este deverá durar.

    3. Criar Sprint Backlog – Uma vez que os itens a serem trabalhados foram selecionadas, uma programação Sprint potencial é construída, tendo em conta a disponibilidade dos membros da equipe para dedicar seu tempo ao projeto. As tarefas macro são decompostas em tarefas técnicas realizáveis e individuais, este é o Sprint Backlog.

    4. Início do Sprint – o sprint começa hoje e dura entre 15~30 dias, de acordo com o programado no sprint planning. Durante o Sprint, outras tarefas são adicionados ao backlog do sprint de acordo com a necessidade.

    5. Executa-se o Daily Scrum – após o início da corrida, a cada dia teremos o Daily Scrum, é uma reunião de 15 minutos em pé no meio da equipe (stand-up meeting), onde cada membro da equipe dá um breve relatório para todos os outros sobre:

    1. O que realizou desde o DailyScrum passado
    2. O que eles esperam realizar
    3. Problemas encontrados

    O Scrum Master fará nota das questões e tentará remover os obstáculos encontrados, após a reunião.

    6. Sprint Review – uma vez que a Sprint termina, todos se reunem para compartilhar o que foi realizado durante o sprint.

    7. Retornar ao Sprint Planning até o fim – O processo começa novamente com uma nova lista de tarefas priorizadas, ainda não realizadas vinda do Product Backlog, faz-se o novo Sprint Planning Meeting e continua até o fim de todo o product backlog, isto é, retorne ao passo 2.

    Este breve resumo do processo de Scrum é suficiente para começar a aplicar Scrum.

    São necessários poucos templates de documentos para a execução dos projetos, como Scrum Product Backlog, Sprint Backlog,  Você pode planejar recursos, tempo e as estimativas de itens individuais do Product Backlog com o Microsoft Project ou outro instrumento de planeamento.

    Ah… Preguiça Produtiva… Foco no que importa!

    Deixe um comentário

    Acho que sempre valorizei o poder do foco, o da total atenção com o que importa. Sem medo de descartar (temporariamente ou não) o que não agrega à tarefa em mãos.

    Sempre tentando fazer meu trabalho direito e com muita vontade de ficar em casa no resto do dia, meus esforços tem surtido efeito: estou chegando em casa no horário e sem levar o trabalho para casa! Ainda não tinha me tocado exatamente como, mas eu estava fazendo. Em meados de 2009, ao participar do Seminário de Gerenciamento de Projetos do PMI em São Paulo, vi uma apresentação de um tal de Peter Taylor, entitulada: “The Lazy Project Manager”, era aquilo, havia encontrado o elo perdido!! O cara colocou em palavras e práticas aquilo tudo.

    Bom, vamos ao que interessa… mas para manter a tradição irei fazer por partes, para não saturar ninguém…(ou por preguiça mesmo, rsrsrs).

    O Princípio da Preguiça Produtiva

    Adaptado do original de Peter Taylor “Productive Laziness

    A muito tempo atrás num reino muito, muito distante (de fato era na Suíça), um homen chamado Vilfredo Pareto havia detectado em 1906 que 80% das propriedades na Itália pertenciam a apenas 20% da população. Esta simples observação foi generalizada por Joseph M. Juran e transformou-se no “Princípio de Pareto”, o qual dizia que:

    “Na maioria dos fenômenos, 80% das consequências são produzidas por 20% das causas”

    Muitos utilizam este princípio (também conhecido como regra do 80/20) dizendo que uma solução está dentro da regra dos ’80/20′ só porquê ela resolve 80% dos problemas, porém para isto estar realmente correto a solução que resolve 80% dos problemas deverá gastar 20% dos recursos, aí sim estaremos condizentes com o princípio de pareto.Então 20% dos clientes são responsáveis por 80% do volume de vendas? Pode ser uma aproximação, mas deve estar perto e este tipo de aproximação ajuda enormemente em futuras tomadas de decisão. A regra do 80/20 se aplica a uma diversidade de coisas mundanas: provavelmente vc veste 20% das suas roupas 80% do tempo ou passa 80% do tempo com 20% dos seus conhecidos e por aí vai.

    Provavelmente a regra do 80/20 deve ser usada por toda preguiçosa, mas esperta, pessoa em sua vida cotidiana. O valor do princípio de Pareto para o Gerente de Projeto é lembrar-se de FOCAR seus esforços nos 20% que importam ao projeto. Aqueles 20% que produzem 80% dos seus resultados.

    Então, este é o real esforço: identificar e focar nestes assuntos durante seu dia de trabalho, dizendo “não” (respeitosamente, por favor) ao resto.

    Pode parecer simples, mas não é! Exige paciência, comprometimento, ousadia, uma boa dose de experiência (para evitar armadilhas) e ler a teoria do nosso amigo Peter Taylor!! (detalhe para a música Lazy do Deep Purple que toca ao fundo do site…!!)

    Com calma e exercitando o foco, você com certeza (assim como eu) irá desfrutar das inúmeras vantagens e do valor agregado da Preguiça Produtiva

    Abraços e depois tem mais…

    Seguir

    Obtenha todo post novo entregue na sua caixa de entrada.