XPManager - The Planning Game
É o coração do planejamento e acompanhamento de projetos na XP. No planning game o software é efetivamente planejado pela equipe de desenvolvimento e pela equipe do cliente. Nesta atividade, cada equipe tem o seu papel bem claro e definido: a equipe do cliente é responsável por definir escopo e prioridades; e a equipe de desenvolvimento por fornecer estimativas.
Muitas vezes é difícil manter as equipes focadas exclusivamente no seu papel. Por isto, cabe ao coach da equipe de desenvolvimento ficar alertando sobre possíveis desvios. Os desenvolvedores normalmente gostam de novos desafios e tendem a tentar “puxar” as tarefas mais desafiadoras ou interessantes para o começo. Mas, esta decisão deve ser apenas da equipe do cliente, não cabe ao desenvolvimento. Por outro lado, é muito comum o cliente querer fazer as estimativas pela equipe de desenvolvimento. É comum a frase “preciso desta funcionalidade em tantos dias”. Acontece que o cliente não tem o conhecimento técnico necessário para fornecer estimativas de desenvolvimento.
Este é um ponto que deve estar presente a todo o momento na cabeça do coach, que deve guiar com segurança a sua equipe e, por outro lado, não deve aceitar tudo que venha do cliente para não comprometer a credibilidade do projeto com constantes atrasos. Muitas tarefas não podem ser feitas mais rápido apenas colocando mais desenvolvedores no projeto. Inclusive, esta abordagem, normalmente, tem efeito contrário, pois estes novos membros precisam de tempo para ser treinados e se interarem do sistema sendo desenvolvido. “Uma a mulher leva nove meses para gerar uma criança. Não adianta pegar nove mulheres que elas não vão gerar uma criança em um mês” (BECK, 2000).
Estando os papéis das duas equipes bem claros, pode-se entender o que efetivamente ocorre no planning game. O cliente deve ter as stories já definidas, pois é sobre elas que está baseada esta atividade. A figura a seguir mostra um exemplo de cartão de User Story, que é utilizado nesta tarefa para que se faça o planejamento.
Baseados em sua experiência ou conhecimentos anteriores, os desenvolvedores devem fornecer estimativas de desenvolvimento para cada story. Se uma story for muito grande para entrar em uma iteração ou não puder ser estimada adequadamente, significa que a mesma está muito complexa e deve ser segmentada em stories menores. Por outro lado, se for muito pequena, deve ser agregada a outras para formar uma story de tamanho adequado. Normalmente, entende-se por adequadas stories que possam ser desenvolvidas em dois ou três dias ideais de programação. A relação entre as funcionalidades entregues e as funcionalidades solicitadas por um cliente para uma iteração é chamada de velocity (velocidade) da equipe de desenvolvimento.
De posse dos cartões com as user stories e das estimativas da equipe de desenvolvimento, os clientes devem definir o escopo da próxima iteração, selecionando aquelas que desejam que sejam implementadas. Para tanto, devem levar em consideração o princípio de que devem receber antes o que vai gerar mais retorno para o negócio. Desta forma, busca-se que o retorno sobre o investimento comece a vir já nas primeiras releases.
Deve-se planejar no máximo duas iterações para que se evite muito retrabalho, uma vez que o feedback que o cliente vai passando em relação as iterações entregues pode vir a gerar novas stories que precisarão ser estimadas, e entrar no planejamento da próxima iteração, e assim sucessivamente.
Durante o desenvolvimento, as dúvidas dos desenvolvedores podem vir a gerar novas stories. Além disto, podem surgir necessidades técnicas, como por exemplo a criação de uma interface para banco de dados, que podem vir a gerar tarefas de engenharia, que devem ser levadas em conta na próximas iterações.
Nas reuniões do planning game também são repassadas para o cliente: as informações sobre o andamento da release atual e informações sobre eventuais atrasos no andamento do desenvolvimento, para que o cliente possa tomar a decisão sobre que funcionalidades devem ser deixadas para a próxima release, ou para que os desenvolvedores possam fornecer novas estimativas para as stories ainda não implementadas.
Este é um ponto importante: caso não seja possível cumprir tudo o que havia sido prometido para a data de entrega de cada iteração, deve-se negociar com o cliente quais stories devem ficar para a próxima, e não atrasada a data de entrega da iteração.
Na XP o planejamento é um processo contínuo, e o mesmo é constantemente refinado pelo cliente e pela equipe de desenvolvimento, deixando assim a metodologia bastante flexível e entregando para o cliente sempre o máximo valor pelo investimento dele. A figura abaixo mostra um resumo desta importante tarefa de planejamento.
