Planejamento Ágil - P3PRAXIS
Preparando o Planejamento. Fomente ao máximo a interação entre o time e o cliente, mas avalie se vale a pena que todo o time participe da reunião de planejamento com o cliente. Explique ao time o que acontecerá durante a reunião, que serão basicamente 3 passos: entender as prioridades, dimensionar o trabalho e gerar consenso entorno do plano.
Entendendo as prioridades. Recomende que o cliente abra a reunião explicando seu objetivo para a próxima entrega (software release). Assumindo que você seguiu opasso 3 da nossa série Agile Coaching, peça que a cliente coloque sobre a mesa os cartões com as histórias numa ordem de priopridade. Deixe claro que todos são importantes, mas que nem todos serão incluídos na próxima entrega. Estimule o time a perguntar qualquer coisa que ajude a quebrar as histórias em histórias mais específicas (quanto menor, mais fácil de estimar).
Dimensionando o trabalho. Neste momento sugira que a cliente não participe mais da reunião, jé que agora precisamos que o time discuta alguns aspectos técnicos. O time tem que discutir elementos técnicos (como de programação e teste) que ajudem a dimensionar o volume de trabalho por complexidade. Utilize um quadro branco para escrever o que surgir. Só tome cuidado para não definir aqui toda a parte técnica, já que os desenvolvedores precisam certa magem de liberdade para trabalhar. Para as histórias que ainda ficaram grandes, peça que o time decomponha em tarefas menores. Mas se o time tem claro como seguir, detalhar demais pode matar a produtividade da reunião. Se o time ficar travado, pergunte coisa como "alguma mudança no banco de dados?" como vamos testar isso?" e coisas do tipo.
Para gerar uma estimativa de trabalho que permita decidir quantas histórias podem entrar na próxima entrega, o time pode discutir e incluir o número no cartão da história, organizando todas elas numa Story Card Matrix: agrupar histórias similares or coluna e ordenar as colunas em ordem crescente.
Se o time tiver dificuldade em chegar num consenso ou se alguns participantes não estiverem contribuindo, você pode usar o Planning Poker. Para usar essa técnica, também chamada de Scrum Poker, cada participante recebe um conjunto de cartas (você pode fazer e imprimir) com os números 0,1,2,3,5,8,13 e 21. Use também uma carta para identificar histórias grandes demais para dimensionar, como um Joker ou um número 99. Quando uma história é lida:
Cada participante faz uma estimativa escolhendo a carta e colocado em cima da mesa virada para baixo. É importante que o número seja revelado todo de uma vez para que um nãi influencie o outro.
Depois que todo mundo jogar, as cartas são viradas e comparadas.
Se todos os números são os mesmos, ótimo. Se não, o time discute para ver se alguém muda de ideia e joga outra vez.
Se alguém não tem ideia, pode incluir uma carta com interrogação.
Se alguém jogar a carta que indica que a história é grande demais, a história deve ser decomposta para facilitar o dimensionamento da complexidade.
A escala indica é a mais comum de complexidade. Os números não representam tempo, nem dias. Eles servem para definir quem é mais complexo e assim facilitar a definição, de acordo com a prioridade da cliente, quem entra na próxima entrega. Existem outras escalas, mas qualquer uma pode se usada com a mesma lógica. Algumas equipes usam Apps no smartphone para votar no Poker ou um Poker online para equipes dispersas fisicamente. Eu já usei esse aqui que é gratuito.
Avaliando a capacidade da Equipe. Com as estimativas de complexidade feitas, é hora do time avaliar sua capacidade de entregar cada história nas releases. Isso vai depender da disponibilidade dos membros do time e da capacidade técnica deles. É o time quem define realisticamente o que pode ser feito. Pode ser que exista pressão da cliente ou da própria empresa sobre histórias em releases. Mas o líder do time deve cuidar para que essa pressão não gere uma entrega insatisfatória e que prejudique o time. Nesse momento, reorganize seu Story Card Matrix colocando as histórias debaixo de cada entrega/release. Antes de seguir, valide essa definição com a cliente e chegue num consenso com a equipe.
Monitorando. Após o planejamento, é importante que você defina um Tracker, que será o responsável dentro da equipe em atualizar o quadro do time usando o Kanban (veja aqui como usar o Kanban). É importante que esse primeiro quadro seja registrado com uma foto para que se compare no final s evolução entre a release planejada e a real.
Só planeje se valer a pena! Antes de cada planejamento de cada release, avalie se vale a pena sentar-se para planejar. Em alguns projetos, especialmente em desenvolvimento de software, as histórias são apenas algumas mudanças simples que podem ser feitas sem um plano como descrevemos até aqui. E sempre tome cuidado para não desgastar sua equipe com reuniões desnecessárias.