Percepções do Agile 2009 (Chicago, USA)

Caros amigos, retornei do Agile 2009 (Chicago) com algumas considerações sobre o que está acontecendo no mercado internacional de desenvolvimento de software. Dentre elas, gostaria de relatar nove que me deixaram mais frustrado do que empolgado quando comparo os fatos identificados e a situação brasileira do mercado de métodos ágeis ... Confira!

1. No exterior, "métodos ágeis é coisa para gente experiente"! Enquanto por aqui falam que isso é coisa de "gurizada", por lá muitos dos palestrantes tinham cabelo branco ... sem contar que a maioria foi ou é líder de grandes empresas. Tive o prazer de conhecer pessoalmente um dos ex-engenheiros de software do projeto Apolo (NASA, anos 60), Mr. Jim Highsmith (atual diretor do Cutter Consortium). Sem contar com os demais gurus que lá estavam presentes ...
   
2. Enquanto no Brasil quem vai nesses eventos são alunos e pessoas sem muito poder de decisão, por lá tivemos a oportunidade de sentar à mesa com gerentes e diretores da Microsoft, HP, Motorola, American Airlines, Disney, Amazon.com, ThoughtWorks, governo americano e muitas outras grandes empresas ...
   
3. Enquanto no Brasil a grande maioria ainda está pensando se as metodologias ágeis realmente funcionam, por lá o que mais ouvimos foram relatos de projetos com equipes distribuídas em diversos continentes, todos com milhares de profissionais alocados nas mais diferentes partes e culturas do planeta. Ouvimos relatos de um projeto de "agilização" de uma empresa asiática com aproximadamente 40.000 profissionais ... não conheço empresa brasileira que tenha tudo isso!
   
4. O modelo de gestão da Toyota (Lean) é a tendência para a grande maioria das organizações que adotam agile. Scrum e XP continuam em alta, mas é muito mais fácil adotar as práticas de gestão de times do Scrum num primeiro momento do que toda a disciplina de engenharia de software demandada pela XP. O que tem que ficar claro é que as práticas da XP acabam se tornando um caminho natural quando um time Scrum atinge seu máximo de desempenho e Lean tem que estar no sangue dos gestores e cultura da empresa ...
   
5. Grandes empresas de fornecimento de serviços de software, totalmente baseadas nos princípios e práticas ágeis, já estão recusando projetos de milhões de dólares quando os mesmos estão sendo demandados com a utilização de metodologias tradicionais. O sucesso do projeto e a satisfação de todos os seus integrantes é mais importante do que a receita obtida associado ao risco do fracasso, pois o desenvolvimento ágil está mostrando maior lucratividade e fidelidade do cliente.
   
6. "Coaching" é assunto sério! Assim como não é comum vermos atletas profissionais de elite treinando sem a supervisão de um excelente técnico (somente amadores treinam sem supervisão técnica), empresas de alto desempenho fazem uso indiscriminado de profissionais experientes estimulando o aprimoramento técnico de novas equipes.
   
7. Não conseguimos falar de planejamento desacoplado da análise de requisitos. Além disso, como o foco das metodologias ágeis sempre foi a agregação de valor ao negócio do cliente, cada vez mais é demandada uma competência em análise de negócios para todos os integrantes da equipe de desenvolvimento envolvidos no desenvolvimento de requisitos.
   
8. Representantes do PMI internacional estavam em peso no congresso, uma vez que a estratégia internacional é orientar os PMPs a aderirem a práticas que realmente funcionam em projetos de software: processo criativo e desenvolvimento orientado a auto-gestão da equipe de desenvolvimento (comunicação e liderança). Nossos PMPs terão que "se puxar" para encarar essa ...
   
9. Agile 2009 (Chicago): US$ 1.800,00 de inscrição, recursos da ordem dos US$ 1,5 milhões, 1.500 participantes ... Agiles 2009 (Florianópolis): muitos dos palestrantes nacionais e internacionais do Agile Chicago, R$ 100,00 de inscrição, recursos da ordem dos R$ 100K, e se der 400 participantes é muito! Realmente, a nossa realidade é outra ... ;-(
   
10. Quanto aos brasileiros falando em Chicago? Nos saimos muito bem (eu, Rafael, Alexandre, Danilo e Francisco) com nossas palestras e workshops! Ficou claro que estamos fazendo muito bem nosso dever de casa (como consultores e instrutores) e estamos cada vez mais sendo respeitados pela comunidade internacional ... só falta nosso mercado nacional perceber que "santos de casa podem fazer milagres" ... ;-)

Para mim, as metodologias ágeis serão disseminadas em nosso país quando ensinarmos nossos clientes (compradores de projetos de software), a questionarem os desperdícios existentes nos processos de seus fornecedores e avaliarem de forma objetiva a qualidade dos produtos a eles fornecidos.

Para quem não pode comparecer, confira uma matéria bem legal em vídeo feita pelo pessoal da Agile Journal.

Compreender a natureza dos requisitos pode estimular a adoção de metodologias ágeis

Na semana passada (quinta e sexta-feira), tive a oportunidade de conhecer a bela cidade de La Plata, na Argentina, graças ao convite que recebi do Centro Superior para el Procesamiento de la Información (CeSPI) da Universidade Nacional de La Plata (UNLP) para realizar uma edição "in company" do curso Requisitos de Software: Princípios e Práticas para Equipes Ágeis.

Foram dois dias muito agradáveis de teoria e prática garantidos por uma equipe bem participativa formada por 30 profissionais pertencentes ao CeSPI e ao Laboratório de Investigación en Nuevas Tecnologías Informáticas (LINTI). A turma era formada basicamente por gerentes de projeto, analistas de negócio e de sistemas, desenvolvedores e testadores, sendo que somente 20% dos participantes demonstrou conhecimento prévio dos princípios e práticas ágeis (um dos grupos está iniciando a adoção de Scrum).

Antes de continuar com o post, vou aproveitar a oportunidade para registrar meus cordiais agradecimentos a todo o pessoal da UNLP que esteve envolvido na realização do curso, em especial Alejandra, Christian e Juan, pois não economizaram cordialidade e atenção durante o período em que lá estive. ¡Muchas gracias por todo!

Pois bem, nesta última edição, tive a oportunidade de comprovar uma idéia que vinha se formando em minha mente nos últimos eventos - a de que o despertar do interesse pelas metodologias ágeis pode ser feito mediante o correto ensino da verdadeira origem dos requisitos de software: a mente humana!

"Me pareció muy inovador pensar los temas
desde el ser humano y no desde la tecnología."

Dalila, CESPI/UNLP

Todos sabem que os requisitos de negócio, de processo, de sistema e de projeto iniciam nas necessidades e desejos da mente humana. Porém, o que a maioria não sabe é como explorar esse fato com modelos objetivos de percepção, informação, decisão e atitude, gerando resultados ainda mais positivos em seus ambientes de negócio. As metodologias ágeis seguem um manifesto que fortalece os indivíduos e suas interações mais que processos e ferramentas, motivo pelo qual todo e qualquer profissional que atue na promoção ou implantação dessas metodologias deve entender alguns princípios básicos da natureza humana a fim de fortalecer a adoção dessa nova cultura e a percepção das verdadeiras necessidades dos projetos de software.

Minhas duas últimas turmas de requisitos de software realizadas na Argentina (Buenos Aires, com 39 alunos, e La Plata, com 30) eram formadas, em sua maioria (> 75%), por pessoas que desconheciam os princípios e práticas das Metodologias Ágeis, mesmo com o título do curso remetendo o foco para o treinamento de "equipes ágeis". Diante desse resultado, o que pude observar é que aqueles que adotam as práticas ágeis no seu dia-a-dia recorrem ao curso para conhecer novas técnicas, questionar dúvidas e aprimorar suas competências, enquanto que aqueles que desconhecem as metodologias recorrem ao curso para saber como nossas equipes ágeis tratam dos diversos aspectos da Engenharia de Requisitos, procurando respostas para a necessidade de simplificação de seus atuais ambientes de trabalho.

"El instructor mostró una versión distinta en muchos aspectos
muy interesante para ser aplicada en el trabajo diário."

Alejandra, CESPI/UNLP

A estratégia que adotei para ensinar requisitos de software à equipes ágeis, e que está provocando mudanças até mesmo na mente daqueles que adotam outras metodologias, pode ser resumida nos seguintes pontos:

1. Apresentar estatísticas que evidenciem que o principal problema no processo de desenvolvimento de software ainda está relacionado com a forma como são tratados os diversos aspectos dos requisitos de software;
   
2. Apresentar o modelo tradicional da Engenharia de Requisitos (captação, análise, especificação, validação e gerência) e questionar como e quando essas atividades são realizadas durante a história do projeto;
3. Apresentar modelos de percepção e tomadas de decisão da mente humana e demonstrar como tudo o que percebemos da realidade depende da forma como as informações chegam e são armazendas em nossa mente (já discuti que o "Mapa Não é o Território" num post anterior);
4. Apresentar conceitos e práticas que comprovam que a comunicação escrita pode ser utilizada de forma eficaz quando se tem consciência de que ela é um mapa que orienta a navegação durante nossa jornada (requisitos, por exemplo) e não o objetivo da jornada em si (o software, por exemplo);
5. Demonstrar que a origem de muitos requisitos de produto e projeto de software pode estar associada a riscos quando sua essência está relacionada a necessidades básicas de segurança e reconhecimento do ser humano (pirâmide de Maslow) e não a melhoria do processo de negócio em si;
6. Demonstrar que a origem de muitos requisitos de produto e projeto de software pode estar associada a riscos devido a crenças e valores limitantes que sustentam incapacidades e comportamentos indevidos do ser humano;
7. Demonstrar que, em ambientes empresariais, todo e qualquer projeto faz parte da realização de uma estratégia de transformação de um processo organizacional, e que um produto de software deve sustentar essa transformação, motivo pelo qual os profissionais que atuam com requisitos devem conhecer os elementos do processo de negócio;
8. Demonstrar como a transformação do processo de negócio pode ser descrita de forma sintetizada, utilizando um modelo de raciocínio baseado na resolução de problemas (Project Story);
9. Demonstrar como as atividades do processo de negócio (Temas) podem ser alvo de análise na decomposição do problema, simplificando o cálculo do retorno de investimento em projetos de software;
10. Demonstrar como o entendimento dos cinco princípios do pensamento enxuto (Valor, Fluxo de Valor, Fluxo Contínuo, Produção Puxada e Perfeição) pode mudar completamente a forma como desenvolvemos e gerenciamos os requisitos de software e justificar a utilização das User Stories;
11. Apresentar as User Stories como um modelo de informações que permite o registro dos requisitos de software de forma aderente ao pensamento enxuto, garantindo a criação de mapas simplificados que nos conduzem ao verdadeiro destino de forma objetiva e segura (planejamento quantitativo e validação objetiva do trabalho realizado);
12. Demosntrar como esse modelo de informações pode ser utilizado de forma efetiva em atividades de planejamento e controle de projetos de software;
13. Demonstrar como podemos nos beneficiar da mudança de percepção sobre as atividades de gerenciamento de requisitos, passando a atuar no controle de estoques e na eliminação do trabalho inacabado em todas as fases de desenvolvimento de produto.
    

Ou seja, adotei uma estratégia top-down que inicia na mente humana, passa pela compreensão dos elementos do processo de negócio, avalia as necessidades de transformação dos resultados organizacionais, ressalta a importância da criação de anticorpos em nosso organismo para atuarem contra requisitos descabidos, e simplifica a compreensão do que deve ser documentado e mantido em nossos estoques de requisitos. O resultado tem sido o reconhecimento de que a cultura ágil tem fundamentos fortes e deve ser adotada por qualquer organização que almeje níveis superiores de qualidade e produtividade em suas equipes de software.

Para aqueles que gostam de metáforas, gostaria de fazer uma analogia entre os requisitos de software e a filosofia zen-budista (originada aproximadamente em 500 d.C., 1.000 anos depois da morte de Buda), que enfatiza permanentemente que "as palavras são um meio e não o fim em si (a iluminação)", motivo pelo qual muitos mestres preferem a prática na compreensão da verdade (aprender fazendo) e criticam os debates filosóficos na transmissão dos ensinamentos. Leia a história abaixo (clique para ampliar a figura) e descubra porque os requisitos nada mais são que o dedo que aponta para a lua!

Jornada T@rgetTrust de Metodologias Ágeis

Caro(a) amigo(a),

Se você é daquelas pessoas que ainda não ouviu falar de métodos ágeis ou gostaria de esclarecer diversas dúvidas que ainda pairam sobre sua cabeça sobre esse assunto que virou febre nas últimas conferências, revistas e listas de discussão, se inscreva na I Jornada T@rgetTrust de Metodologias Ágeis. Este evento será realizado no dia 9 de Junho, terça-feira, no Auditório da Assespro, localizado no Tecnopuc, o maior Parque Científico e Tecnológico da América Latina.

Neste evento, Daniel Wildt, Guilherme Lacerda e eu, apresentaremos um "pout-pourri" de diversos temas, estimulando a participação de todos e desafiando as crenças arraigadas das abordagens tradicionais de desenvolvimento de software.

Confira a programação abaixo e venha tomar um café conosco naquela tarde!

[]´s

Parzianello

Jornada T@rgetTrust de Metodologias Ágeis

Venha compreender a origem, os princípios e as práticas da mais nova
tendência mundial do mercado de software!

Data, Horário e Local

9 de Junho de 2009
Horário: das 13h30min às 18h30min
Tecnopuc - Auditório Assespro

Investimento

R$ 120,00 por pessoa até 29/05/09
Acima de 3 inscrições 10% de descontoINTRODUÇÃO

Apresentação

As Metodologias Ágeis deixaram de ser apenas o sonho de muitos gurus da Engenharia de Software e passaram a ser a realidade de muitas empresas que adotaram seus princípios e valores como estratégia de sobrevivência diante da crise econômica mundial. As Metodologias Ágeis procuram garantir a satisfação do cliente mediante a entrega rápida e contínua de software em funcionamento, promovendo a cooperação entre os profissionais de negócio (equipe do cliente) e de produto (equipe de software), a excelência técnica em todos os níveis e a rápida adaptação às mudanças do ambiente de trabalho.

As Metodologias Ágeis exigem dos profissionais de software uma grande maturidade para lidar com a formação de times auto-gerenciáveis e a busca contínua da perfeição de pessoas, ferramentas e métodos. Por tratar diretamente dos aspectos humanos do desenvolvimento de software, são incompreendidas e alvo de críticas infundadas de profissionais que desconhecem a evolução dos modelos de gestão organizacional.

Quem deve participar

As empresas e profissionais da área de software que procuram orientação sobre como aderir aos conceitos e práticas das principais Metodologias Ágeis existentes no mercado.

O que iremos apresentar

Programamos para você uma tarde repleta de informações e debates com a participação dos principais expoentes da comunidade gaúcha de Métodos Ágeis. Serão abordados os seguintes temas que compõem a essência da mudança cultural exigida para o novo profissional que desenvolve software:

• História, Princípios e Valores das Metodologias Ágeis
• O Pensamento Enxuto (Lean) como Base para a Cultura Ágil
• O Gerenciamento de Projetos com Scrum
• A Engenharia de Software com Extreme Programming
• A Engenharia de Requisitos em Ambientes Ágeis

Como vamos realizar

13:00 - 13:30 Recepção
13:30 - 13:45 Abertura T@rgetTrust
13:45 - 14:30 Introdução
14:30 - 15:15 Pensamento Enxuto
15:15 - 16:00 Scrum
16:00 - 16:30 Coffee-Break
16:30 - 17:15 Extreme Programming
17:15 - 18:00 Requisitos de Software
18:00 - 18:30 Debates e Encerramento

O que você irá ganhar

• 5 horas de atividades, incluindo coffee-break
• Material didático
• Material de apoio
• Certificado de Participação

Facilitadores

DANIEL WILDT - É um profissional de tecnologia da informação com 10 anos de experiência profissional. Atua em uma empresa brasileira como CIO. Certificações: SCJP/SCEA Part 1, JBuilder, Delphi/Delphi.NET, ITIL V3 Foundations, Scrum Master (CSM). Atua como Coach para adoção de Metodologias Ágeis desde 2004, focando em Lean Development, Scrum, eXtreme Programming e Feature Driven Development. Ensina programação, Metodologias Ágeis e Qualidade de Software na FACENSA (http://www.facensa.com.br). Atividades em comunidades de prática com o Grupo de Usuários Delphi do RS (http://www.dug-rs.org), Grupo de Usuários de Metodologias Ágeis do RS ( http://www.guma-rs.org), Comunidade de Ensino e Aprendizado do portaljava.net (http://edu-gelc.dev.java.net) e projeto JEDI (Java Education and Development Initiative) como responsável na implantação e disseminação do mesmo no Rio Grande do Sul.

GUILHERME LACERDA - É Mestre em Sistemas de Informação, área de Engenharia de Software, pela UFRGS. Dedica-se atualmente em atividades de consultoria e treinamento em Engenharia de Software e Metodologias Ágeis. Coordenador do Curso de Sistemas de Informação da FACENSA. Professor Universitário de Graduação (FACENSA, UniRitter) e Pós-Graduação (UniRitter). Atuou como diretor de tecnologia de uma empresa do ramo de software livre e open source durante 9 anos. Pioneiro em Metodologias Ágeis no Brasil, onde atua desde 2001, com especial ênfase em Lean, SCRUM e eXtreme Programming. Palestrante em dezenas de eventos nacionais e internacionais sobre o tema. Participou da revisão técnica do livro "eXtreme Programming Explained", do Kent Beck, lançado em 2004 pela Bookman. Fundador do XP-RS/GUMA, onde atua na vice-coordenação. Editor do Portal InfoQ, edição Brasil.

LUIZ CLÁUDIO PARZIANELLO - Formado em Engenharia Eletrônica pela PUCRS e Mestre em Sistemas Eletrônicos pela POLI/USP. Possui 25 anos de experiência em informática, tendo dedicado os últimos 10 anos a atividades de treinamento e consultoria em Melhoria de Processos de Software. Estuda e implementa metodologias ágeis desde 2003, dando ênfase a Lean Management, Scrum, Extreme Programming e Engenharia de Requisitos. Tem atuado como consultor e instrutor para diversas organizações no Brasil e no Exterior. É vice-coordenador do Grupo de Usuários de Métodos Ágeis da SUCESU-RS e palestrante da Conferência Internacional Agile 2009, em Chicago.

Para mais informações, ligue para (51) 3325-2596 ou mande e-mail para atendimento@targettrust.com.br.

Deus era agilista?

Antes de iniciar meu texto, gostaria de comunicar que este post é resultado de uma leitura da introdução do livro “A Estratégia da Genialidade - Vol.1”, de Robert Dilts, que faz uma análise da estrutura lingüística utilizada no livro Gênesis da Bíblia Sagrada. O texto não possui nenhuma conotação religiosa e mantém total respeito ao referido texto.

“Quero saber como Deus criou o mundo. Não estou
interessado neste ou naquele fenômeno, ou no espectro
deste ou daquele elemento; quero conhecer os
seus pensamentos; o resto são detalhes.”
Albert Einstein

Na introdução do livro citado acima, Robert Dilts escreve:

As palavras poderosas e emocionantes do Gênesis nos contam a história da criação em vários níveis. Além de descrever o que foi criado, está descrito o processo de como foi criado. Ali vemos a descrição “dos pensamentos de Deus” sob a forma de uma estratégia criativa que possui uma estrutura específica. Trata-se de uma estratégia que inclui um certo número de etapas que se desenvolvem em um ciclo contínuo que se retroalimenta.

Interessante! Segundo as observações de Dilts, a criação do mundo, pelo o que está escrito na Bíblia Sagrada, foi feita por um processo iterativo incremental! E continua:

A criação começa a partir de uma distinção – da criação de uma diferença. Este primeiro ato leva a outro e em seguida a outro e depois a outro – cada idéia estabelecendo o potencial para a próxima. Cada ato de criação inclui a reiteração de um ciclo que compreende três processos fundamentais:

1) Conceitualização: “E disse Deus: Haja ...”
2) Implantação: “E Deus fez ...”
3) Avaliação: “E viu Deus que era bom.”

Ficou muito claro para mim que o processo de criação do mundo, segundo a Bíblia Sagrada, está baseado num processo semelhante ao Scrum, pois contempla: Sprints com prazo fixo de 1 dia de duração (cada ato de criação se passa em um dia), um Product Backlog priorizado no início de cada Sprint (conceitualização), a realização do Sprint Backlog em cada dia (implantação) e a revisão daquilo que foi feito num Sprint Review. Só que considerando a onipotência e a onipresença de Deus, ele atuou em seu projeto como Product Owner, Scrum Master e Team Member, simultaneamente. Outro detalhe é que não há um detalhamento de requisitos no começo do processo, o que implica um projeto de natureza Just-in-Time (estoque zero). Para completar, Dilts expõe sua visão final do processo, que ao meu ver serve para descrever a forma criativa que procuramos adotar nas metodologias ágeis:

Cada ciclo provoca uma sucessão de idéias cada vez mais pessoais e refinadas. Com cada um dos ciclos, a idéia assume cada vez mais vida própria – ela é capaz de criar, multiplicar e sustentar outras idéias. A expressão maior reflete o processo do Criador de tal maneira que é capaz de abastecer todas as outras criações enquanto se multiplica.

Uma bela descrição do desenvolvimento ágil! Não é verdade?
Criar todo o mundo em 6 dias e descansar no 7º realmente foi uma obra divina!

Para aqueles que ficaram curiosos sobre o que está escrito no Gênesis, este é um livro de autoria desconhecida, porém atribuída a Moisés na tradição judaico-cristã. Ele deve ter sido escrito por volta dos anos 1450-1410 a.C., para descrever o princípio de tudo. É o primeiro livro da Bíblia Sagrada. Transcrevo o texto do Gênesis extraído do site http://www.bibliaonline.com.br/, onde fica claro que, no momento da criação do homem à Sua imagem e semelhança, estavam sendo concebidos os verdadeiros Usuários de toda a criação! ;-)

Gênesis 1:1 – 2:3

No princípio criou Deus os céus e a terra. E a terra era sem forma e vazia; e havia trevas sobre a face do abismo; e o Espírito de Deus se movia sobre a face das águas. E disse Deus: Haja luz; e houve luz. E viu Deus que era boa a luz; e fez Deus separação entre a luz e as trevas. E Deus chamou à luz Dia; e às trevas chamou Noite. E foi a tarde e a manhã, o dia primeiro.

E disse Deus: Haja uma expansão no meio das águas, e haja separação entre águas e águas. E fez Deus a expansão, e fez separação entre as águas que estavam debaixo da expansão e as águas que estavam sobre a expansão; e assim foi. E chamou Deus à expansão Céus, e foi a tarde e a manhã, o dia segundo.

E disse Deus: Ajuntem-se as águas debaixo dos céus num lugar; e apareça a porção seca; e assim foi. E chamou Deus à porção seca Terra; e ao ajuntamento das águas chamou Mares; e viu Deus que era bom. E disse Deus: Produza a terra erva verde, erva que dê semente, árvore frutífera que dê fruto segundo a sua espécie, cuja semente está nela sobre a terra; e assim foi. E a terra produziu erva, erva dando semente conforme a sua espécie, e a árvore frutífera, cuja semente está nela conforme a sua espécie; e viu Deus que era bom. E foi a tarde e a manhã, o dia terceiro.

E disse Deus: Haja luminares na expansão dos céus, para haver separação entre o dia e a noite; e sejam eles para sinais e para tempos determinados e para dias e anos. E sejam para luminares na expansão dos céus, para iluminar a terra; e assim foi. E fez Deus os dois grandes luminares: o luminar maior para governar o dia, e o luminar menor para governar a noite; e fez as estrelas. E Deus os pôs na expansão dos céus para iluminar a terra, E para governar o dia e a noite, e para fazer separação entre a luz e as trevas; e viu Deus que era bom. E foi a tarde e a manhã, o dia quarto.

E disse Deus: Produzam as águas abundantemente répteis de alma vivente; e voem as aves sobre a face da expansão dos céus. E Deus criou as grandes baleias, e todo o réptil de alma vivente que as águas abundantemente produziram conforme as suas espécies; e toda a ave de asas conforme a sua espécie; e viu Deus que era bom. E Deus os abençoou, dizendo: Frutificai e multiplicai-vos, e enchei as águas nos mares; e as aves se multipliquem na terra. E foi a tarde e a manhã, o dia quinto.

E disse Deus: Produza a terra alma vivente conforme a sua espécie; gado, e répteis e feras da terra conforme a sua espécie; e assim foi. E fez Deus as feras da terra conforme a sua espécie, e o gado conforme a sua espécie, e todo o réptil da terra conforme a sua espécie; e viu Deus que era bom.

E disse Deus: Façamos o homem à nossa imagem, conforme a nossa semelhança; e domine sobre os peixes do mar, e sobre as aves dos céus, e sobre o gado, e sobre toda a terra, e sobre todo o réptil que se move sobre a terra. E criou Deus o homem à sua imagem: à imagem de Deus o criou; homem e mulher os criou. E Deus os abençoou, e Deus lhes disse: Frutificai e multiplicai-vos, e enchei a terra, e sujeitai-a; e dominai sobre os peixes do mar e sobre as aves dos céus, e sobre todo o animal que se move sobre a terra.

E disse Deus: Eis que vos tenho dado toda a erva que dê semente, que está sobre a face de toda a terra; e toda a árvore, em que há fruto que dê semente, ser-vos-á para mantimento. E a todo o animal da terra, e a toda a ave dos céus, e a todo o réptil da terra, em que há alma vivente, toda a erva verde será para mantimento; e assim foi. E viu Deus tudo quanto tinha feito, e eis que era muito bom; e foi a tarde e a manhã, o dia sexto.

Assim os céus, a terra e todo o seu exército foram acabados. E havendo Deus acabado no dia sétimo a obra que fizera, descansou no sétimo dia de toda a sua obra, que tinha feito. E abençoou Deus o dia sétimo, e o santificou; porque nele descansou de toda a sua obra que Deus criara e fizera.

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.