A dinâmica consiste na apresentação de um canvas com uma árvore desenhada e a facilitação do exercício. É interessante escolher um tipo de árvore que mais se assemelhe a metáfora do sistema em questão (prática de eXtreme programming) em que o time trabalha. Cada galho da árvore, deve representar uma funcionalidade ou um conjunto de funcionalidades de uma aplicação.
As folhas mais próximas do caule representam as funcionalidades atuais do sistema (último release/estado atual do repositório e/ou tag/versão de produção).
As folhas nas pontas dos galhos representam funcionalidades que ainda não foram desenvolvidas, que estão no backlog e/ou roadmap a curto prazo.
Novas funcionalidades, devem ser escritas em post-its. Os usuários e clientes, podem priorizar nos galhos as funcionalidades que imaginam serem entregues em um futuro próximo.
O caule da árvore pode representar as práticas de engenharia utilizadas pelo time (Peer review, pair programming, CI..) ou as premissas que aquele time precisa, ou seja, o que habilita aquela equipe a entregar aquela visão de produto.
A primeira análise que pode ser feita é se a árvore está crescendo organicamente.
- Existe algum galho que está crescendo muito mais que o outro? No exemplo que eu tentei utilizar para ilustrar, parece que as funcionalidades X, Y e Z dos módulos C e B, tendem a crescer mais que outras. Existe alguma mudança arquitetural necessária?
- Existe algum galho que deixa de ser utilizado com o nascimento/crescimento de outro?
- Existe um planejamento para continuidade da plataforma? Exemplos: investimentos em infraestrutura, automação e eventuais adequações..
A base da árvore, ou seja, as raízes são compostas por outras dependências do sistema, serviços, atividades de suporte e operações (caso existam), infraestrutura, e outros.
Uma vantagem desta dinâmica é a possibilidade de poder ter uma visão mais sistêmica ao invés do usuário/cliente apenas dar feedback sobre uma única funcionalidade de forma isolada.
É comum equipes de desenvolvimento de software se preocupar com as funcionalidades mais importantes, que geram mais valor (geralmente financeiro). Em contra partida, como consequência deste comportamento, deixamos de lado investimentos importantes para funcionalidades que suportam e melhoram o produto. Algumas vezes, os requisitos não funcionais como segurança e performance acabam sendo sacrificados (mesmo comportamento que se tinha com teste de software há alguns anos atrás..).
Caso você esteja passando por um período de experimentação e validação do seu produto, você pode criar uma árvore para cada MVP.
Participantes:
Time de desenvolvimento (incluindo PO, SM), usuários, clientes com expertise sobre o uso do sistema e as funcionalidades atuais e futuras, stakeholders/patrocinadores do produto/projeto. (Até 10 participantes é um número interessante para a dinâmica).
Créditos:
O texto acima, é uma tradução com adaptações de uma das dinâmicas do livro “Innovation Games” de Luke Hohmann.
Exemplo de uma adaptação:
A foto abaixo, representa a aplicação da dinâmica com o objetivo de se ter uma visão sobre conhecimentos que são interessantes para profissionais que trabalham com desenvolvimento de software ágil. Foi feito por um grupo que dividiu entre conhecimentos básicos (raiz), conhecimentos utilizados no dia-adia (caule) e assuntos para desenvolver no futuro (folhas).
Agile Coach .Ninja 