Dicas valiosas para sprints
Olá. Bem, é como dizem por ai: “Life got real!”. Mas, enfim, estou aqui de volta.
Ainda tratando de sprints. Seguindo na mesma linha do post anterior. Acho que ficou claro que não é sensato abraçar cegamente o que é sugerido pela literatura, e sim saber reconhecer a essência do que é proposto e conseguir adaptar e aplicar à sua realidade. E além do mais, saber aplicar tais conceitos a cada caso é o tipo de tarefa que só se consegue realizar com a prática do dia-a-dia. E foi justamente com a prática do dia-a-dia que eu percebi alguns detalhes nos meus projetos. Seguinte:
- Fixe os dias da semana para marcar suas reuniões de planejamento e retrospectiva (sprint planning e review). Por exemplo, todos os plannings acontecem na segunda-feira e todos os reviews na sexta-feira. Dessa forma você acaba criando um vínculo e fica mais fácil de todos se organizarem e dificilmente alguém vai esquecer da reunião;
- Certifique-se que os dias dos sprints planning e reviews estão “funcionando” pra você. O que eu quero dizer com funcionando, é se estão sendo reuniões produtivas. Nos meus primeiros projetos eu reservava a segunda-feira para o planejamento e a sexta-feira (da outra semana) para as retrospectivas. Tiro no pé! Ninguém, nem a equipe, nem o Product Owner estavam motivados para começar a semana com uma reunião. Estas sempre começavam atrasadas e era nítido que o pessoal ainda estava “regulando a marcha lenta”. Muito menos encarar uma retrospectiva de 4 horas em plena sexta-feira! Bastou trocar os dias e a coisa começou a funcionar;
- Lançar novas versões do produto na sexta-feira pode não ser uma boa idéia. Ninguém quer voltar para casa, muito menos correr o risco de perder o final de semana com aquela preocupação de que algo pode dar errado. Uma coisa que funcionou comigo foi definir um deadline na quinta-feira. E deixar a sexta-feira apenas para algumas tarefas administrativas e reviews;
- Crie tags no seu sistema de controle versão para cada sprint. Isso se você estiver utilizando controle de versão, pois se não estiver, você definitivamente deveria!
- Evite entregar tudo o que foi produzido apenas ao final da iteração. A medida que as tarefas forem sendo finalizadas, disponibilize para o cliente. Agilidade está diretamente relacionada a feedback. Se você deixar para entregar tudo que foi feito ao final do sprint, você só tera o feedback do cliente no próximo sprint, o que pode acabar atrasando as coisas, haja vista já existem tarefas definidas para esse (próximo) sprint. Esse assunto também foi abordado neste excelente artigo do Alisson Vale, inclusive batizado com um nome bastente adequado: “Síndrome da Iteração Inacabada”.
Bem, por hora é isso. Como cada empresa ou projeto, cada situação tem suas peculiaridades, eu gostaria que vocês compartilhassem suas experiências com relação a esse assunto. Os comentário estão abertos. Caso você não tenha passado por isso ainda, espero que esses tópicos possam te poupar algum tempo.
Sem mais.
