Se a equipe conseguir entregar todas as histórias antes do fim da iteração, é pre-
ciso solicitar ao cliente mais histórias. Então, o cliente escolhe quais deverão ser adicionadas à iteração considerando o tempo restante e sua prioridade. Na próxima
iteração o cliente poderá incluir um número maior de pontos, considerando que a
velocidade da equipe melhorou. Isso geralmente acontece à medida que a equipe vai
amadurecendo e ganhando mais domínio sobre a tecnologia utilizada no projeto e
nos conceitos de negócio.
Um problema muito comum que pode afetar a ordem de desenvolvimento das
histórias são as dependências técnicas entre elas. É possível que o cliente determine que uma história específica tenha prioridade em relação à outra, porém, tecnicamente pode ser mais viável fazer o contrário. Nesses casos é importante que a equipe seja sincera com o cliente em relação às dificuldades técnicas e apresente a ele os benefícios de implementar as histórias na ordem inversa. Entretanto, é sempre reco-
mendado que a equipe permita que o cliente escolha o que ele quer que seja entregue primeiro e se esforce ao máximo para entregar de acordo com a prioridade determinada por ele.
Em se falando de XP e Scrum, não é recomendado adicionar novas histórias a
uma iteração que já tenha sido iniciada. É comum que ao longo de uma iteração o cliente solicite que alguma nova história seja adicionada com urgência. Atender a este tipo de solicitação emergente e não planejada pode impactar negativamente no andamento do trabalho da equipe e, como mencionado anteriormente, pela mesma razão,
não é recomendado alterar as histórias de uma iteração em andamento. Se houver
muitos casos de mudanças de escopo dentro de uma iteração, e isso, realmente, for
importante para o negócio, talvez seja o caso de avaliar utilizar um método ágil de fluxo contínuo ao invés de iterativo, como Kanban, por exemplo.
Alterar uma iteração em andamento pode significar trabalho perdido, desgaste,
39
3.4. A Reunião Diária
Casa do Código
perda da concentração e atrasos. No entanto, responder rapidamente às necessi-
dades de negócio do cliente é um valor ágil e algo que deve ser sempre levado em
consideração.
Em casos como este, é possível negociar com o cliente, e depois de conscientizá-
lo da problemática de alterar iterações em andamento, incluir a história emergente
com a condição de retirar da iteração outra história com um valor de estimativa de
esforço igual ou próximo. Deve-se evitar, é claro, retirar histórias que já tenham seu desenvolvimento iniciado.
O cliente, provavelmente, ficará contente por sua solicitação emergente ter sido
atendida e mais valor ter sido agregado ao seu negócio. Porém,
é preciso ter cuidado para que essas emergências não se tornem algo constante e prejudicial. Solicitações emergentes devem ser esporádicas. É preciso insistir para que o cliente tenha disciplina e respeite as iterações para que as coisas possam caminhar conforme o plane-
jamento.
Outros tipos de demandas não planejadas podem surgir ao longo da iteração.
Um exemplo muito comum são os indesejáveis defeitos. Por maiores que sejam as
atitudes preventivas da equipe para manter a qualidade do software com testes e in-
tegração contínua, é comum que defeitos se apresentem aqui ou ali. Nesses casos
pode ser necessário que a equipe pare o trabalho e tome providências para sanar o
problema.
A lógica é simples: se uma determinada funcionalidade já está em produção,
significa que ela era mais importante do que as outras que ficaram pendentes, por
isso foi priorizada e desenvolvida antes das outras. Caso um defeito surja e e essa pare de funcionar, provavelmente, será mais importante corrigir o defeito, do que
entregar algo que tinha menos prioridade.
Vale a pena acompanhar as demandas de trabalho não planejado que surgem
durante uma iteração. Se for muito frequentes fique atento: algo provavelmente está errado ou talvez seja mais interessante avaliar trabalhar com fluxo contínuo em vez de iterações.
3.4
A Reunião Diária
Estabelecer uma comunicação eficiente entre os membros da equipe é extremamente
importante. As reuniões diárias, conhecidas no XP como Stand Up Mettings (Reu-
niões em Pé) e no Scrum como Daily Scrum (Scrum Diário) são práticas muito efi-
cazes para que todos estejam sempre a par do status atual do projeto.
40
Casa do Código
Capítulo 3. Foco em Valor para o Negócio
Todos os dias em um horário preestabelecido, geralmente no início do dia, a
equipe se reúne por mais ou menos 15 minutos para sincronizar o estado do projeto
e manter todos informados sobre os últimos acontecimentos e como as coisas estão
ou não evoluindo.
Através da reunião diária todos os membros da equipe ficam cientes do anda-
mento do projeto e podem aproveitar a oportunidade para apresentar suas dificul-
dades e pedir ajuda aos outros membros.
No Scrum, por exemplo, cada membro do time responde a três perguntas na
reunião diária:
1) O que eu fiz desde a última reunião (ontem)?