[MÚSICA] Olá! Bem-vindo ao curso Princípios de Desenvolvimento Ágil de Software. Eu sou Clovis Fernandes e hoje estaremos falando de Sprint Planning. O Sprint Planning, o Planejamento do Sprint é uma das partes principais do desenvolvimento ágil, no nosso caso, o Scrum e XP, porque nós estaremos preparando exatamente o que a equipe pode desenvolver com sustentabilidade durante o período do sprint. Nós iremos trabalhar três videoaulas pra mostrar o sprint planning. A ideia é que ao final dessas três videoaulas o aluno saiba que consiste o planejamento do sprint no contexto do nosso Scrum com XP. O sprint planning nós estaremos estruturando duas fases. Começaremos a fase na parte de avaliação do backlog de produto nesta parte. Na parte dois completaremos a fase. E depois na fase dois iremos falar sobre a escolha final de que user stories vão fazer parte do que a gente chama de sprint backlog, o backlog do sprint, ou seja, o conjunto de user stories daquele sprint. Nós havíamos começado a mostrar exemplo de sprint de duas semanas e nós identificamos que logo no começo, nesse exemplo de duas semanas, as quatro primeiras aulas na parte da manha num dia de oito horas seria dedicada a esse planejamento do sprint. No sprint planning apenas o PO, o product owner, o scrum master, e o time de desenvolvimento é que fazem parte. O scrum master tem papel essencial todos os tipos de reuniões, ou cerimonias, ou eventos como o sprint planning. É ele que vai comandar, ver a aderência dos membros que estão participando da reunião relação ao Scrum e XP, toda essa, os rituais, os eventos todos, se estamos cumprindo corretamente. E vai gerenciar principalmente o tempo. Ele que vai abrir e vai no final garantir que as coisa estão sendo feitas dentro do tempo. No nosso caso do sprint planning de duas semanas ela vai ter uma duração de quatro horas. Normalmente são duas horas por semana do sprint. Então se o sprint tem uma semana o sprint planning, o planejamento, vai ser de duas horas, se tem três semanas vai ser de seis, se tem quatro semanas vão ser oito horas. O product backlog, o PBL, também chamado de PBL, quem é dono dele? Quem é o proprietário dele? É o PO, ele, o PO, o product owner, é o responsável pelo product backlog. Que nada mais consiste do que ter todas as user stories que foram definidas lá no sprint zero, e depois, ao longo dos sprints, todas as user stories que ainda não foram implementadas. É papel muito importante de gerenciar isso. O product backlog é muito dinâmico, vão entrando e saindo estórias. Algumas estórias saem porque vão ser desenvolvidas, implementadas, outras estórias saem porque o product owner diz que não faz sentido mais ter aquele tipo de user story, e novas estórias vão entrando, novas estórias vão entrando. O sprint planning nós estamos estruturando aqui, para efeitos didáticos, duas fases. A fase é de avaliação do PBL. Vai haver uma conversa entre todos os envolvidos sobre as user stories do PBL, que nós vamos trabalhar isso seguindo aquele princípio que a gente falou, da conversação. Tudo na nossa modelagem ágil se resolve com a conversação. A fase dois é quando eu já tenho o product backlog organizado, priorizado, atualizado, e eu consigo então permitir a continuidade dessa conversa para que o time de desenvolvimento possa dizer que estórias eles são capazes de desenvolver. com base no esforço, no tamanho de esforço de cada user story e da velocidade do time. O que é a velocidade do time? É a capacidade de número de pontos de estória que o time é capaz de produzir. Começando a fase a primeira atividade, e que ela é, vamos dizer assim, é o papel do PO, ele que é o proprietário do PBL, é o de adicionar novas estórias. Se o sprint que vai ser feito é o logo após o sprint zero dificilmente vão existir estórias novas. Porque é atrás do outro, a gente acabou de estruturar o PBL no sprint zero, mas pode acontecer também. As estórias novas vão aparecer principalmente nos novos sprints, porque o stakeholder pode apresentar a qualquer momento novas estórias. O time, ao começar desenvolver, vai conhecendo mais o produto, e ele também vai verificando a necessidade de novas estórias. E vai propôr sempre pro PO, porque é ele que gerencia, é o responsável pelo PBL, é ele que vai no final decidir se vai colocar ou não. Se aquilo tem algum valor de negócio ou não. A user story nova, normalmente, uma ou mais, elas vão sendo colocadas temporáriamente no topo dessa pilha de user stories, que o topo está mostrando que têm maior valor de negócio, o BV é maior valor de negócio e também tem a informação sobre o tamanho do esforço que isso foi estimado pelo time anteriormente. O que acontece com essa user story nova? Ela não tem business value nem tem esforço ainda, então ela fica ali temporariamente. Com isso a gente consegue com que o PO defina que aquele conjunto de user stories que estão no topo vão ser o meu objetivo pro próximo sprint. Se o PO não estivesse satisfeito com alguma estória que esteja lá priorizada anteriormente naquele momento ele pode rebaixar, trazer estórias de baixo e colocar ali cima. Tudo de acordo com o objetivo de negócio dele, ou de possívelmente lançar releases com alguma característica que ele ache importante colocar. Esse objetivo agora é objetivo perliminar, que no decorrer das fases e dois vai ser melhorado. E com isso agente consegue fazer planejamento melhor do que deve ser desenvolvido. Com isso nós completamos essa primeira videoaula e na próxima nós continuaremos com outras atividades da fase. Obrigado. [MÚSICA]