preciso explicá-las à equipe. Nesse momento é importante que o PO ou pessoas de
negócio possa estar presentes para que possam esclarecer aos desenvolvedores suas
dúvidas de negócio, permitindo que ao final da reunião os desenvolvedores estejam
preparados para implementar estas histórias.
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 determi-
nada 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 cli-
ente 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 anda-
mento 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 disci-
plina 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.