SPRINT PLANNING

Se você perguntar a 100 gerentes de projetos qual o maior desafio que eles encontram em seu trabalho, 76 irão responder falando sobre os obstáculos que encontram ao comunicar com o time. Gerenciar a comunicação envolve engajar seus stakeholders, e envolve também manter a sinergia dos envolvidos. Uma boa comunicação pode ser a diferença entre o sucesso ou o fracasso de um projeto.



Nos métodos preditivos ficava a cargo do gerente de projetos identificar quais seriam os marcos do projeto, e o quais eventos o time deveria performar ao longo do projeto para garantir um bom desenvolvimento da equipe. Os métodos ágeis jogam mais luz nessa interação - o próprio manifesto ágil reforça a ideia de indivíduos e interações mais do que processos e ferramentas - e por coloca em sua base 5 grandes eventos, que formam os pilares da interação no scrum, são eles:


  1. Sprint Planning

  2. Daily Stand Up Meeting

  3. Sprint Review

  4. Sprint Retrospect

  5. Project Retrospect

Sprint Planning é o primeiro dos eventos do scrum, e também é utilizado em outras metodologias ágeis, sua principal função é a de ajudar ao time a entender o trabalho que deve ser realizado, seu esforço, e mais do que isso: uma estimativa mais assertiva das tarefas a serem realizadas


O planejamento começa com o time escolhendo as histórias que gostariam de trabalhar naquele período de tempo, seguindo a ordem de priorização definida previamente pelo PO no processo de priorização do Backlog. As estórias já foram estimadas, de modo que tenta-se trabalhar sempre com a mesma quantidade de esforço. É responsabilidade do PO definir junto com o time o período de sprint, de forma a cumprir o cronograma de entregas. Ao selecionar as histórias o time também deve olhar se há entre elas qualquer tipo de dependência, ou outros requisitos posterguem sua execução.


Tento escolhido as histórias a se trabalhar o time passa então a entender quais são as tarefas que devem ser realizadas para executar cada história. É comum que em equipe de desenvolvimento o time busque entender quais são os requisitos funcionais ( o que o sistema deve faze), não funcionais ( como o sistema deve ser: seguro, fácil de usar) e as regras de negócio (ex: Deploy as terças, autorizar uso apenas após identificação federal do usuário), para conseguir entender quais tarefas devem ser desempenhadas em sua execução. Dentro da Engenharia de software fala-se muito de requisitos funcionais e não funcionais, deixando-se os as regras de negócio fora, acontece que no dia a dia percebe-se não considerar as regras de negócio pode significar um grande empecilho para o projeto, e muitas vezes resulta em retrabalho.


Tendo identificado as tarefas o time passa então a estimar as tarefas a serem realizadas, para tal o time pode tanto voltar a utilizar estimation points, com técnicas como o poker planning, quanto pode utilizar o Tempo Ideal, que nada mais é do que o tempo Ideal para se realizar uma tarefa caso não houve qualquer tipo de interrupção.


O último processo desse ritual é da criação própria do Sprint, isso significa identificar quando serão realizadas cada uma das entregas, quais papéis devem ser desempenhados durante o sprint, quais estórias serão trabalhadas e identificar as áreas a serem abordadas pelo time do projeto. É também interessante que o time tenha um objetivo claro estabelecido para aquele sprint, e que na medida do possível o sprint seja capaz de entregar um Mínimo Produto Viável, de forma a garantir que o valor do projeto comece a ser realizado já nas primeiras entregas.


56 visualizações0 comentário

Posts recentes

Ver tudo