A prática é a melhor forma de demonstrar e criar conhecimento. Desenhar, refletir, discutir, concordar e discordar.

A primeira vez que participei de uma dinâmica da hora extrema (eXtreme hour), foi em 2004, e o exemplo utilizado foi a criação de um caixa eletrônico. Hardware e software. 🙂

Desde então, sempre que tenho a oportunidade, faço a dinâmica para poder ensinar um pouco sobre Agilidade e demonstrar disciplinas do eXtreme Programming aliadas a práticas que ajudam a maximizar comunicação e compreensão do que se quer alcançar no software.

Que materiais você precisa para fazer a eXtreme Hour?

Cartões para se poder escrever as histórias e brincar com o conceito 3C.
Folhas de papel brancas e coloridas
Canetas coloridas
Réguas
Tesouras
Fitas adesivas
Colas

Para que tudo isto? Para se poder montar telas, fazer mockups, e poder trabalhar com a prática do paper prototyping. Nesta uma hora, provaremos as histórias através da “execução” dos protótipos de papel.

E quanto tempo dura a dinâmica? A dinâmica deve durar 1 hora! O tempo total do evento pode ser mais de 1 hora, considerando uma ambientação com agilidade e eXtreme Programming, e depois um fechamento do evento.

Considere que você vai fazer de duas a três iterações, e que neste tempo está incluído o papo inicial do cliente, e também uma retrospectiva da dinâmica. O cliente segue disponível durante toda a dinâmica, a menos que você adicione uma restrição para ele “sumir” por alguns minutos. E assim o time poder ver como se comporta. Eu normalmente faço duas iterações. Elas já servem para demonstrar as ideias e surgem muitos pontos de discussão a partir disto. E normalmente crio restrições em alguma das iterações para ser mais difícil falar com o cliente.

Comentei que o exemplo usado é sobre construção de caixa eletrônico, com seu software e hardware. Aqui então mando uma lista que itens que você pode vir a requisitar para as equipes construírem:

• No hardware do caixa eletrônico, o seu formato. Pensar na forma da retirada de dinheiro, se tem leitor de código de barras, forma de entrada do cartão (chip, magnético ou se vai fazer leitura da digital). Se vai ter impressão de recibos ou envio dos mesmos por email?
• Tipos de uso pelo cliente, se vai fazer uso com o cartão do banco ou sem o cartão do banco. Exemplo, sem o cartão é possível fazer impressão de extrato ou saldo. Para fazer saque e pagamento, será necessário cartão do banco.
• Sobre funcionalidades do software, temos várias opções, com saque, consultas de conta, pagamentos com ou sem código de barras, transferências, doc e ted, e outras funções que um caixa eletrônico possui. Escolha um banco e pense nas funcionalidades que o caixa eletrônico oferece. Dica: ao pensar no saque, pense em limitações de valor e horário, para que os times possam exercitar situações de exceção e erro.

E sobre todas estas possibilidades, você deve indicar para as equipes coisas que quer ou que gostaria de ter. Não necessariamente precisa indicar o que é prioridade. 🙂 O que normalmente ajuda a gerar resultados bem diferentes e interessantes. A prioridade pode ficar como algo “não falado” nos primeiros minutos da explicação, para ver se as equipes vão fazer perguntas ao cliente ou se elas vão simplesmente executar o que o cliente falou, na ordem que ele falou. Que não necessariamente vai ser a ordem de importância. O ponto aqui é ver se as equipes estão buscando entrega de valor e comunicação com o cliente, aproveitando a presença do mesmo.

Costumo dividir as equipes em 7 pessoas. Evite muitas equipes, para que possa gerenciar tudo sendo apenas 1 cliente.

Quanto ao tempo, uma sugestão de uso pode ser a seguinte:

• 3 mins – As equipes se organizam e definem quem faz o que (quem faz design, escrita de histórias, validações, a criação dos protótipos, tira dúvidas com o cliente, manter o tempo, e por aí vai). Lembre que as equipes devem ser multidisciplinares. Então as pessoas podem se ajudar em atividades.
• 7 mins – Apresentação do problema. Aqui você como facilitador usa sua imaginação e pensa em funções que o caixa eletrônico vai ter, qual o público alvo e restrições do jogo, exemplo tempo disponível para tirar dúvidas, e outras questões neste sentido.
• 15 mins – Primeira iteração. Nesta iteração, o time deve fazer planning (2mins de sugestão), execução da iteração e retrospectiva. Na metade do tempo da iteração, deve fazer uma “diária”. Então considere que cada dia termina depois de 7mins. E neste momento existe 1 min de reunião diária para o time alinhar o que está ocorrendo. No décimo terceiro minuto, o time deve fazer sua retrospectiva da iteração, para entender o que pode ser melhorado para a próxima iteração.
• 5 mins – Tirar dúvidas com os times e mostrar insights que foram vistos durante a primeira iteração. Normalmente equipes focam demais em planejamento e não em execução. Outras equipes focam demais em execução. Outras equipes não se organizaram e todos fazem de tudo e não entregam nada. Aqui não se resolve nada muito profundo, o objetivo é dar pequenas dicas para deixar visível aos times oportunidades de melhoria na sua comunicação e tática.
• 15 mins – Segunda iteração. Mesmo ciclo da primeira iteração, os times tentam entregar mais um grupo de funcionalidades.
• 15mins – Retrospectiva do exercício, aqui serve como momento de reflexão e gerar uma discussão com os participantes sobre agilidade e metodologias ágeis.

E era isto! Espero que todos se divirtam!

Deixo algumas fotos da dinâmica que ocorreu no Agile Games Night, evento que ocorreu no UniRitter/Porto Alegre em junho de 2012.

E agradecimentos ao Thiago Esser! Ele ajudou a priorizar este post! Espero que possa ser útil!

Caso tenha interesse em levar esta dinâmica para sua empresa, ou evento, ou alguma palestra, faça! Só peço uma coisa em troca! Faça um post contando da experiência e comente por aqui fazendo uma referência! Quero saber quem anda brincando com a eXtreme hour por aí!

Update 24/set/2012 – Thiago Esser manda feedback da dinâmica que ele fez!