O planejamento começa com a escrita de User Stories (Histórias de Usuário). Para quem conhece UML, elas são uma espécie de Use Cases “diet”. O usuário ou cliente escreve histórias que representam o que o sistema deve fazer por ele, evitando usar qualquer terminologia técnica. Em conjunto com os programadores, é estimado o esforço necessário para o desenvolvimento de cada uma dessas histórias que, em conjunto, irão compor cada uma das versões do sistema a ser desenvolvido. Caso o esforço estimado para o desenvolvimento de uma determinada User Story seja muito grande, ela deve ser subdividida em outras.
A fase seguinte do Planejamento é a Release Planning, em que a equipe de negócios e a de desenvolvimento concordam com a ordem na qual os módulos do sistema serão desenvolvidos e entregues para a produção, quando os usuários se beneficiam do produto. É importante que a equipe de negócios esteja envolvida, pois nem sempre é possível, aos programadores, avaliar a importância da disponibilização de um determinado conjunto de histórias (ou módulo) do sistema, ao mesmo tempo que pode ser difícil para a equipe de negócios entender a dependência técnica entre esses módulos. Para um executivo pode ser crucial que um relatório financeiro possa estar disponível rapidamente, mas ele depende de módulos contábeis que devem ser escritos antes. Ao final do Release Planning, deve estar clara para todos a ordem na qual os módulos do sistema serão disponibilizados e todos devem se comprometer com isso. Para facilitar esse planejamento, a equipe deve procurar levar em conta apenas quatro variáveis: escopo, recursos, tempo e qualidade. Às vezes, pode ser possível adiantar o desenvolvimento de um módulo, por exemplo, se diminuirmos seu escopo, ou seja, a quantidade de coisas pela qual tal módulo é responsável. Sempre é possível também diminuir o tempo de realização de um projeto aumentando os recursos disponíveis para ele. Não é recomendável, porém, acelerar um projeto diminuindo os testes do sistema, comprometendo assim sua qualidade. Concentrando-se apenas nessas quatro variáveis, é possível acelerar as decisões sobre a sequência de desenvolvimento.
Uma regra do XP é Move People Around. O conhecimento não deve ser concentrado nas mãos de poucas pessoas. Envolva pessoas em diferentes projetos e troque-as de tempos em tempos.
A comunicação entre as pessoas e o envolvimento dos usuários (clientes) no desenvolvimento são fatores extremamente importantes. Não se deve, porém, perder mais tempo na comunicação dos resultados e na tomada de decisões do que no desenvolvimento em si. Por isso a XP propõe Stand-up Meetings, reuniões que devem acontecer todos os dias de manhã, preferencialmente no ambiente de desenvolvimento. Essas reuniões informais devem substituir, integralmente, quaisquer outras reuniões.
Uma das regras mais importantes do Planejamento em XP é Fix XP when it breaks, ou seja, se a metodologia não está funcionando, conserte a metodologia! Nem sempre pode ser possível seguir tudo o que uma determinada metodologia propõe e faz mais sentido mudar a metodologia do que querer adequar o desenvolvimento de um sistema a regras imutáveis.
Como você verá adiante, porém, o Scrum apresenta um conjunto muito pequeno e simples de papéis, ritos e artefatos. Esse conjunto já é pequeno o suficiente para que seja aplicado integralmente, sem mudanças.
