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.

O risco do excesso de babagem

Sexta-feira, 24 de outubro de 2008, 16h. Estou no saguão do hotel aguardando o táxi que me levará para o aeroporto de Ezeiza, em Buenos Aires. Seria o encerramento de um feliz período nesta cidade, que iniciou com um romântico fim de semana acompanhado de minha esposa e terminou com uma excelente conferência denominada Ágiles 2008 (http://agiles2008.org/). Digo seria pois o roubo de meus pertences na abertura do evento realmente não fazia parte de meus planos ...

Quanto ao roubo, só posso dizer que, se afastar da cadeira por um instante, para cumprimentar o palestrante, e não encontrar mais sua pasta no minuto seguinte de seu retorno provoca sensações muito desagradáveis de vazio e desespero, principalmente quando dentro desta pasta se encontram notebook, celular, câmera digital, óculos, agenda, etc. Sei que este problema tem sido vivenciado cada vez mais por pessoas das mais diferentes partes do mundo, mas sei também que esse cenário, infelizmente, só tende a piorar em todos os lugares ... Então por que estou escrevendo sobre este assunto num blog dedicado a Metodologias Ágeis? É que, depois do incidente, me deparei com alguns pensamentos que me remetaram a associar o fato a uma das principais fontes de problemas que encontramos diariamente em nossos projetos de software: o excesso de bagagem ao qual são submetidos toda a equipe de desenvolvimento!

Pensem à respeito: qual o custo que irei pagar por não ter tirado da pasta coisas que eu certamente não utilizaria durante a abertura do evento? Além da perda de meus pertences (que terei de comprar novamente), existe o desgaste físico de carregar o excesso antes do incidente, existirá o tempo de reinstalar todas as aplicações que tinha no computador, tem o tempo de recuperar o backup que fiz antes de viajar (pelo menos eu tinha um plano de contingência para esses tipos de problemas), e ainda tentar lembrar das atividades de consultoria que fiz durante o mês pois todos os registros de trabalho estavam em minha agenda.

Dado que sempre na abertura de eventos ganhamos pastas e material promocional (é o que se espera, não é?), por que diabos eu havia levado minha pasta até com um modem 3G que eu não iria utilizar na Argentina? Será por que todas essas coisas já estavam ali dentro mesmo? Faziam parte do meu "toolbox" padrão associado à uma pasta de trabalho?

Mesmo continuando com o backup diário ou semanal, levar somente o que é necessário para nossas atividades diárias e manter todas as coisas sob nossa permanente atenção não seria uma forma mais efetiva de reduzirmos os riscos de um roubo nos dias de hoje? Pois bem! Faço-vos algumas perguntas para que pensem sobre suas estratégias de mitigação de riscos utilizadas em seus projetos de software:

1. Nos dias de hoje, com a alta volatilidade que apresentam os processos de negócio, por que ainda queremos levar conosco todos os requisitos de sistema capturados de forma detalhada, meses de antecedência da real utilização dos mesmos? Como poderemos calcular o risco de não utilizarmos aquilo que foi analisado e também os custos das futuras mudanças?
2. Por que continuamos gastando um enorme tempo planejando interrelações entre tarefas num plano de projeto se já sabemos antecipadamente estará desatualizado na próxima semana? Qual o risco de perdermos todas as horas trabalhadas em previsões feitas sobre eventos de baixa probabilidade de realização na ordem prevista?
3. Por que continuamos levando conosco artefatos de projeto (registros, documentos, indicadores, etc.) que definitivamente não agregam valor ao produto final de nosso trabalho (identifique quantas vezes você realmente fez uso das diversas informações coletadas durante o projeto ou dos documentos elaborados sem a solicitação do cliente)?
4. Quantas vezes investimos na sofisticação de produtos ou processos quando uma simples solução não glamourosa resolveria o problema de uma forma perfeitamente aceitável?

Eu poderia continuar enumerando uma infinidade de perguntas relacionadas às nossas atividades diárias em projetos de software, tendo sempre como base os sete desperdícios do Sistema Toyota de Produção: Defeitos, Excesso de Produção, Estoque, Excesso de Movimento, Excesso de Processamento, Transporte e Espera. Porém, acredito que a essência da resposta que surgirá para todas essas perguntas está no MEDO! O medo de faltar algo durante qualquer momento de nossas vidas! O medo de não ter o computador para demonstrar nossos resultados a um colega (mesmo sem ter planejado que eu o faria durante o evento). O medo de não ter meu telefone para receber uma ligação de minha esposa (mesmo que eu tenha planejado ligar para ela do hotel, após o evento), e assim por diante.

Tente entender o paradoxo da situação: "Por medo da falta, levei tudo! Por ter perdido tudo, agora tudo falta!". Para quem ainda não entendeu a relação desse evento de minha vida com os eventos cotidianos de um projeto de software, faça para si uma última pergunta: "É mais fácil eu calcular o risco do excesso de bagagem do meu projeto de software ou reduzir o risco do projeto diminuindo o tamanho da bagagem que temos que carregar ao longo do mesmo?"

Pelo menos eu já estou publicando este post de meu novo notebook! Um modelo bem barato para diminuir as perdas de um possível novo incidente! Hehehe!

O mapa não é o território!

"Até onde as leis da matemática se refiram à realidade, elas estão
longe de constituir algo certo, e na medida em que constituam
algo certo, não se referem à realidade." Albert Einstein

"O mapa não é o território" é uma expressão que aprendi durante minha formação em Programação Neurolingüística (PNL), e que é atribuída a Alfred Korzybski, um engenheiro, filósofo e matemático polonês que publicou esse conceito num encontro da American Mathematical Society em 1931. É uma expressão que se refere à forma como o ser humano interage com a realidade na qual ele se encontra. Ela representa o fato de que não temos acesso direto à realidade em si, mas sim às percepções da realidade em que vivemos.

Enquanto a realidade é representada pelo "território" na expressão de Korzybsky, a nossa percepção da realidade é o "mapa mental" que construímos para descrever o território em que vivemos. Algo semelhante ao pensamento budista, existente há mais de 2500 anos, que diz que você vê mas não consegue perceber a realidade subjacente. Os mapas mentais do mundo não são o mundo em si, mas nossas representações desse mundo. É por isso que fazemos parte de um número ilimitado de "mundos" criados por todas aquelas pessoas ou seres que interagem diariamente conosco. Para cada um desses mundos, nosso comportamento poderá ser aceitável ou inaceitável. Tudo dependerá das sensações e interpretações que causamos naqueles que interagem conosco.

Pois bem, compreender isso no universo do desenvolvimento de software faz com que percebamos que os requisitos de produto e de projeto são reflexos das crenças e valores daqueles que os criam e os defendem. Um requisito passa a ser visto como fruto de reflexões baseadas em mapas mentais sustentados por critérios objetivos e subjetivos de negócio, tecnologia, metodologia, qualidade, tempo, esforço, recursos, entre outros fatores. Ou seja, tudo aquilo que é dito por clientes, usuários, analistas de negócio, analistas de sistemas, gerentes de projeto, programadores, testadores e demais integrantes de um projeto pode estar associado a uma visão parcial ou distorcida do problema, reflexo de um mapa mental limitado pelas percepções de seu dono. É por isso que muitos requisitos podem fazer sentido para uns e nenhum sentido para outros, principalmente quando não há uniformidade de conhecimento e experiência entre os mapas mentais dos membros da equipe.

Nos últimos anos, tenho observado que é possível aumentar a qualidade dos requisitos de produto e de projeto utilizando técnicas especiais de captação e análise baseadas neste conceito de mapa mental. Essas técnicas permitem investigar a consistência das informações captadas com um aumento considerável do desempenho e da eficácia do analista durante momentos de comunicação interativa com as partes interessadas. Dentre as mais importantes para esta finalidade, destaco a prática de "rapport", a "estrutura da mudança" e o "metamodelo" criado por Richard Bandler e John Grinder (discutirei as três em posts futuros). Somente com estas três técnicas fui capaz de diminuir significativamente o tempo de captação de requisitos (de dias para horas) e conquistar a total satisfação do meu interlocutor em praticamente 100% das reuniões.

Ok, mas o que você pode fazer a curto prazo para minimizar os efeitos da incompatibilidade de mapas mentais num projeto de software?

1. Conscientizar os membros da equipe sobre os modelos mentais, representacionais e de tomadas de decisão debatidos na PNL, bem como em técnicas de investigação de modelos mentais baseadas na estrutura da linguagem (dê preferência para um Trainer Certificado);
2. Definir claramente o contexto para o qual será desenvolvido o produto de software utilizando modelos de processo (aqui utilizo a notação IDEFO) e da estrutura da mudança (estado presente x estado desejado);
3. Definir claramente o escopo de produto necessário para realizar a transformação do contexto (aqui um modelo simples e eficaz é o de User Stories - Título, Descrição, Critérios de Aceitação, Tamaho e Prioridade);
4. Estimular a comunicação direta entre os membros da equipe de desenvolvimento e as partes interessadas no produto (cliente e usuários).

Entender esta forma de pensar e saber lidar com suas implicações sobre nossas vidas faz com que saibamos tratar das fragilidades da comunicação caricaturizada pela imagem da figura 1, em que o analista, o projetista, o consultor, o líder de projeto e os desenvolvedores entendem e constroem algo bem diferente daquilo que é desejado pelo cliente.

Figura 1: Fragilidades da comunicação.

Captar rapidamente o que o cliente deseja como produto e entregar o pedido no prazo e com qualidade é algo que não tem preço! Para mim, este novo cenário só se tornará efetivo na área de software quando passarmos a repetir continuamente o novo cenário da figura 2 ...

Figura 2: Excelência na comunicação.

Saí da casca!

É com grande prazer que publico o primeiro texto de uma série de pensamentos e reflexões sobre desenvolvimento de software, métodos ágeis, pensamento enxuto (Lean Thinking), teoria das restrições (TOC), gerenciamento de projetos, programação neurolingüística, entre outros tantos assuntos que têm me fascinado nos últimos anos.

Pretendo utilizar este espaço para compartilhar com vocês minhas experiências e reflexões sobre aquilo que leio, aplico, observo, aprendo e ensino sobre os mais diferentes assuntos relacionados ao desenvolvimento de software. É claro que, para quem me conhece, pretendo manter sempre aquele posicionamento crítico e desafiador que apresento em todos os treinamentos que ministro pelo mundo afora.

Espero que o material a ser divulgado neste blog seja de grande utilidade para muitos, seja para contribuir na mudança de crenças e valores como para fortalecer idéias totalmente contrárias aquelas que eu apresentei neste veículo! A única coisa que eu espero é que você seja capaz de retribuir ao meu esforço enviando comentários sobre aquilo que escrevo. Adoro feedback!

Até breve!

[]´s

Luiz Parzianello