26 de nov de 2008

Jogos Estatísticos: Lotes de Produção x Produtividade

A expressão "Dinâmica de Grupo" surgiu pela primeira vez num artigo publicado por Kurt Lewin, em 1944, quando o pesquisador discutia a relação entre os resultados da aplicação de teoria e prática no ensino da Psicologia Social. Naquela época, Lewin utilizou essa expressão (originada da palavra grega "dynamis", que significa força, energia, ação) com o objetivo de ensinar às pessoas novos comportamentos mediante a realização de exercícios denominados "dinâmicas de grupo". Essas dinâmicas de grupo eram, e ainda são, atividades realizadas com o objetivo de estimular a discussão e a tomada de decisão em grupo, substituindo os métodos tradicionais de transmissão do conhecimento pela simples exposição de conteúdo por parte do comunicador (ou instrutor).

Quem trabalha ou estuda metodologias ágeis sabe que diversas dinâmicas de grupo foram criadas com o intuito de facilitar a adoção de seus conceitos e práticas com a exploração de temas como: os benefícios do cliente estar sempre presente (James Shore), simulações da metodologia Scrum (Jean Tabaka), simulações da metodologia XP (Peeters & Cauwenberghe), Extreme Hour (Peter Merel), Planning Poker (James Grenning), Jogos de Programação (William C. Wake), entre outros. No entanto, o que muitos de seus praticantes não observam é que a maioria dessas dinâmicas (ou de seus realizadores) aborda a essência dos princípios ágeis de uma forma metafórica distante do modelo mental analítico predominante nos profissionais da área de software. Como resultado, conquistam-se momentos de diversão em alguns participantes, momentos de perpexlidade em outros, e insights sobre a verdadeira natureza do problema somente em poucos indivíduos.

Páre e pense, quem já conduziu algum tipo de dinâmica desta natureza ou já participou como colaborador de uma equipe de simulação de projetos ágeis: que tipo de novo comportamento foi introduzido nos indivíduos ou nas equipes de software após a realização de uma dinâmica baseada em metáforas distantes do trabalho cotidiano daqueles profissionais? Quem ainda não ouviu um aluno ou participante dizer: "Legal essa prática! Só que ainda não entendi como aplicar isso no desenvolvimento de software ..."?

Pois bem, o que quero salientar neste post é que a mudança comportamental de um indivíduo, conforme estudos feitos em psicologia cognitiva, não se dá tão facilmente trabalhando-se somente em seu nível comportamental. Para que ela seja efetiva, precisamos trabalhar nos níveis lógicos de capacidade (competência) e percepção de crenças e valores, principalmente no que diz respeito ao conceito de indentidade do indivíduo. Os antigos paradigmas devem ser desafiados por fatos e as metáforas utilizadas com cautela, pois múltiplas interpretações podem surgir quando as mesmas são apresentadas num mesmo contexto para múltiplos indivíduos.

Pense no poder de uma atividade que permite instalar na mente de seu executor o seguinte tipo de pensamento: "Puxa vida! Nunca havia me dado conta de como minha equipe é muito lenta diante do que posso fazer com essa nova metodologia!". A menos que ele aceite conviver daqui para a frente com o fato de fazer parte de uma equipe muito lenta (identidade), de baixa produtividade, talvez ele venha a promover a mudança de processo (ou de equipe) devido a uma nova experiência que realmente provou matematicamente o aumento de seu desempenho e que pode vir a contribuir com a diminuição da pressão de seus clientes sob suas atividades.

O que venho praticando nos últimos tempos, em dinâmicas de grupo realizadas de forma efetiva em turmas de Engenharia de Requisitos e em atividades de consultoria focadas na mudança da cultura organizacional em empresas tradicionais de software, são demonstrações matemáticas (mais especificamente estatísticas) dos resultados que podem ser obtidos utilizando-se novos arranjos produtivos para as práticas tradicionais do desenvolvimento de software (análise, desenho, programação e testes). Com elas, tenho podido explorar a natureza analítica digital do profissional de software e propor novas crenças em substituição daquelas limitantes (paradigmas do pensamento ortodoxo tradicional) com desafios de raciocínio diretamente ligados à natureza de suas atividades (lógica matemática).

Passei a chamar essas dinâmicas de "Jogos Estatísticos para a Promoção de Práticas Ágeis" e as tenho realizado em workshops de 90 minutos, como foi o caso da participação no evento Ágiles 2008. Até o momento, tenho utilizado três jogos baseados em modelos de produção Just-in-Time (Lotes de Produção x Produtividade), Teoria das Restrições (Eventos Dependentes x Produtividade) e Teoria das Filas (Fluxo de Produção x Planejamento). Pretendo continuar na sistematização de mais jogos sob esta óptica e a publicação dos seus princípios, técnicas, resultados e discussões aqui neste blog.

Na segunda parte deste artigo, apresento a estrutura de execução do primeiro jogo (Lotes de Produção x Produtividade), uma dinâmica que aprendi vendo instrutores de Lean Manufacturing demonstrarem os princípios fundamentais da produção Just-in-Time a profissionais de uma fábrica. Caso algum instrutor ou praticante de metodologias ágeis resolva aplicar o mesmo na forma como apresentei aqui neste post, peço a gentileza de me enviar os resultados a fim de que eu possa avaliar as dificuldades e melhorar a documentação da mesma para que outros se beneficiem da atividade.

Divirtam-se e tenham ótimos resultados!



Título do Jogo: LOTES DE PRODUÇÃO X PRODUTIVIDADE

Objetivo: Demonstrar a superioridade produtiva de um arranjo logístico baseado em pequenos lotes (iterações de curto prazo) contra um arranjo logístico baseado na produção de grandes lotes (Waterfall).
Duração aproximada: 20 minutos com debates sobre a prática.
Número de Participantes: Mínimo de 4 por grupo (ideal 5), máximo de 6 grupos (30 pessoas).

Resumo: "Lotes de Produção x Produtividade" é uma dinâmica que demonstra matematicamente como o desenvolvimento iterativo focado no fluxo unitário de requisitos funcionais (pequenos lotes) é superior ao tradicional desenvolvimento Waterfall baseado na conclusão de grandes fases de análise, desenho, programação e testes (grandes lotes).



PREPARAÇÃO:

  1. Forme grupos com 5 participantes cada (se não for possível, utilize 4 participantes por grupo);
  2. Atribua um dos seguintes papéis a cada membro da equipe: Analista, Projetista, Programador, Testador e Cliente (organize o layout das equipes de tal forma a permitir um rápido fluxo de cartões entre os papéis durante a dinâmica);
  3. Entregue o Product Backlog para o Analista (pilha com 10 cartões simulando os requisitos funcionais a serem produzidos pela equipe);
  4. Entregue o cartão de controle de produção para o Cliente ou Testador (no caso de uma equipe de 4 integrantes), solicitando que o mesmo disponha de um cronômetro digital para registro da duração das atividades (pode ser celular, relógio, etc.);
  5. Explique as regras do jogo para os participantes.


Figura 1: Ilustração representando uma disposição adequada para os membros de uma equipe.
Abaixo, um exemplo de cartão de produção, que deverá ser distribuído em lotes de 10 e dispor
de espaço para que cada integrante rubrique em sua respectiva atividade. Por fim,
um exemplo de cartão de controle de tempo.
Clique na imagem para ampliar.

DINÂMICA DO JOGO:

  1. O objetivo é entregar o mais rápido possível os dez cartões rubricados pelo Analista, Projetista, Programador e Testador, nesta seqüência, simulando a realização das respectivas atividades num projeto de software. Ou seja, o ato de rubricar um cartão numa respectiva atividade atribuída ao papel do membro da equipe significa que aquele requisito funcional foi contemplado por este trabalho durante o projeto;
  2. Cada equipe realizará duas rodadas de produção, sendo a primeira destinada ao fluxo de grandes lotes e a segunda ao fluxo de pequenos lotes (utilize as regras de produção abaixo para explicar para as equipes como funciona cada arranjo logístico);
  3. Discuta os resultados da dinâmica com os participantes.

REGRAS DE PRODUÇÃO PARA GRANDES LOTES:

  1. O Cliente ou Testador (no caso de uma equipe de 4 participantes) dispára o cronômetro e anuncia o início do projeto;
  2. O Analista deverá rubricar os dez cartões de requisitos na sua respectiva atividade e entregar todo o conjunto para o Projetista;
  3. Sempre que um membro da equipe receber um conjunto de cartões de seu colega predecessor, o mesmo deverá rubricar todos os requisitos na sua respectiva atividade e entregá-los imediatamente ao colega sucessor na cadeia logística;
  4. No final da rodada, o Cliente ou Testador deverá registrar no cartão de controle o tempo total necessário para concluir os dez requisitos;
  5. O cartão de controle deverá ser entregue ao instrutor ao final do jogo (segunda rodada).

REGRAS DE PRODUÇÃO PARA PEQUENOS LOTES:

  1. O Cliente ou Testador (no caso de uma equipe de 4 participantes) dispára o cronômetro e anuncia o início do projeto;
  2. O Analista deverá rubricar o primeiro cartão de requisito na sua respectiva atividade e entregar o mesmo para o Projetista, voltando a repetir este passo até concluir os 10 cartões que estão em seu poder;
  3. Sempre que um membro da equipe receber um cartão de seu colega predecessor, o mesmo deverá rubricá-lo na sua respectiva atividade e entregá-lo imediatamente ao colega sucessor na cadeia logística, mantendo este fluxo de produção até que os 10 cartões recebidos durante o projeto estejam rubricados;
  4. O Cliente ou Testador deverá registrar no cartão de controle o tempo parcial da conclusão do primeiro requisito funcional e o tempo total necessário para a conclusão dos dez requisitos;
  5. O cartão de controle deverá ser entregue ao instrutor ao final desta rodada.

CONSIDERAÇÕES DURANTE A EXECUÇÃO:

  1. Estimule os grupos a produzirem o mais rápido que puderem nos dois arranjos logísticos;
  2. Durante a produção em grandes lotes (Waterfall) pergunte aos integrantes ociosos o que os mesmos estariam fazendo naquele momento num projeto da vida real (provavelmente estariam trabalhando em suas respectivas atividades, só que alocados em outros projetos dado que ninguém costuma ficar ocioso em abientes sob pressão);
  3. Fique com a planilha de análise estatística pronta para receber as informações provenientes dos cartões de controle;
  4. Supervisione as equipes para ver se estão trabalhando conforme o esperado e para captar comportamentos interessantes de serem analisados na fase de debate (por exemplo, a formação de estoques intermediários pelas diferenças nas velocidades de trabalho, falta de entendimento da dinâmica e execução do projeto de forma anômala, etc.).

RESULTADOS:

  1. Tipicamente, as equipes concluirão a primeira rodada (grandes lotes) em até 2 minutos, sendo muito difícil concluirem a tarefa em menos de 1 minuto e meio;
  2. Tipicamente, as equipes concluirão a segunda rodada (pequenos lotes) em até 40 segundos, sendo muito difícil concluirem a tarefa em menos de 30 segundos (é possível em 20 segundos);
  3. Tipicamente, na segunda rodada, as equipes concluirão o primeiro requisito em até 10 segundos;
  4. Calcule a média das equipes para análise dos resultados (automaticamente por uma planilha);
  5. Descarte resultados espúrios provenientes da falta de entendimento da dinâmica.

PARA DEBATER COM OS PARTICIPANTES:

  1. Apresente os valores e gráficos obtidos durante a dinâmica (a imagem abaixo ilustra alguns resultados típicos) e pergunte as opiniões de cada integrante das equipes;
  2. Questione em qual arranjo logístico as equipes tiveram de investir um maior esforço para concluir todos os requisitos de projeto (devem observar que o esforço é igual nos dois casos);
  3. Questione qual a vantagem de se entregar um primeiro lote de funcionalidades para o cliente em 10% do tempo total gasto no arranjo de produção em grandes lotes (feedback para o cliente e para a equipe, correção da rota de projeto, retorno de investimento, etc.);
  4. Questione qual a vantagem de se concluir um projeto em 1/3 do tempo total previsto para um arranjo logístico tradicional de grandes lotes (note que é comum obter um fator de redução do tempo da ordem dos 2.5 : 1, ou seja, seria possível processar duas vezes o projeto em pequenos lotes e ainda sobraria tempo);
  5. Questione quais as dificuldades de gerenciar um arranjo logístico de pequenos lotes (disciplina na gerência de requisitos, sincronia entre os integrantes da equipe, balanceamento da produção - tão rápido quanto o mais lento da equipe, cliente disponível para entregas freqüentes, agendamento de um novo projeto somente após a conclusão do que está em execução, etc.);
  6. Observe que a base de realização do processo em pequenos lotes é o fluxo da produção em pipeline;
  7. Questione como a gestão do risco (focada na minimização das perdas diante da ocorrência de eventos que comprometam prazo, custo, qualidade e escopo de um projeto) trataria o fato de que a escolha de um arranjo logístico baseado na produção de grandes lotes já implica num atraso inicial de 200% quando comparado ao prazo necessário para sua realização em pequenos lotes (iterações de curto prazo);
  8. Faça os participantes terminarem a dinâmica com a consciência de que, sempre que estiverem trabalhando em projetos planejados com o modelo Waterfall, o prazo de execução será de até três vezes o tempo necessário para a realização do mesmo projeto sob uma logística ágil.


Figura 2: Planilha Excel utilizada para demonstrar os resultados estatísticos do experimento.
É de extrema importância utilizá-la no exercício, principalmente quando são utilizados diversos
grupos e a média dos dois arranjos mostra a superioridade do trabalho em pequenos lotes.
Clique na imagem para ampliar.

DIREITOS DE USO:

Publiquei este post com o intuito de divulgar esta dinâmica e facilitar a adoção da cultura ágil nas mais diferentes equipes de software. Caso você venha a utilizar este material em suas apresentações, cursos ou dinâmicas, por gentileza, não deixe de mencionar a fonte e referenciar o link deste blog! Agradeço a sua compreensão. Qualquer dúvida na realização desta prática, não exite em me contatar por e-mail.