[MÚSICA] Olá! Bem-vindo ao curso Princípios de Desenvolvimento Ágil de Software. Eu sou Clovis Fernandes e na aula de hoje iremos dar continuidade a fase do Sprint Planning, o planejamento do sprint. Nessa parte dois nós vamos mostrar as outras atividades. Na aula anterior nós mostramos procedimentos que nós devemos fazer quando alguma user story nova aparece. Ao final nós ficamos com objetivo preliminar que é aquele topo, que o PO deseja que seja implementado. A próxima fase é tratar user stories que são grandes, a gente chama de epics, isso varia de time pra time o que considera como epics, e que nós vamos pegar essas consideradas epics e vamos quebrar user stories menores. Nem sempre só epics vão ser quebradas, outras user stories podem ser quebradas porque elas poderiam ser quebradas por outros motivos. No nosso caso específico, nós temos essa user story dois, vamos lembrar que as user stories dois e três são meros nomes, elas estão escritas naquele formato de user story que nós estamos acostumados. Cada uma delas tem valor de negócio, BV, e o seu tamanho de esforço. Olhem a user story dois. A user story dois, ela tem valor de esforço que eu estou colocando aqui como 21. Na aula anterior eu tinha mostrado como 20. Por que? Muitas empresas não seguem estritamente o Fibonacci, que seria 21, porque já considera que a user story é grande demais. Outros colocam uma interrogação pra caracterizar que ela é uma epic. Outros, por definição, com 20, 21 é considerado uma epic e vai ser obrigatóriamente quebrado. Eu queria que vocês prestassem atenção no valor que a gente está colocando ali, que é 21. Mais pra frente nós vamos saber por que eu quero que vocês guardem esse valor. Nós iremos então quebrar essa epic user stories que são menores. O que vai acontecer? Vamos lembrar do Livros a Jato. Nós tínhamos lá uma user story que era o admin, ele gerencia, na parte what dele, o admin gerencia o acervo de e-books. Gerenciar o acervo pode ser muitas coisas. Então normalmente eu teria que quebrar essa admin gerencia o acervo de e-books outras user stories menores, e que espelham melhor as ações. Por exemplo, eu podia quebrar quatro user stories, o admin adiciona novos livros ao e-book, o admin retira livros que o site não deseja mais disponibilizar, o admin seleciona os livros, eventualmente, dez livros que serão oferecidos gratuitamente para usuários cadastrados como do tipo standard, e o admin retira ou troca esses livros regularmente. Esses dois últimos seriam feitos semanalmente e o introdução e remoção à medida que aparecem novos e-books, ou novos e-books vão sendo retirado. Então vocês percebam que eu posso fazer algo agora, vou quebrar minha user story dois três user stories, que estou referenciando aqui como a dois ponto dois ponto dois, e dois ponto três. O que acontece? Elas não têm valor de negócio ainda e elas também não têm o tamanho do esforço para implementá-las. O que vai acontecer com elas então? Eu poderia fazer como a gente fez com a user story nove, podia colocar no topo temporariamente também. Mas o que se faz normalmente é substituir a user story que eu acabei de quebrar pelo conjunto das novas user stories que foram produzidas nesse processo. Então o que eu posso fazer é incluir ali mesmo, no mesmo lugar. Mas tanto faz, porque depois nós vamos trabalhar isso termos de valor de negócio e podia estar qualquer lugar, mas usualmente é isso que vai acontecer. Bom, a próxima etapa é: o PO vai olhar agora essas user stories novas e essas que foram fruto da divisão de epics ou de user stories maiores, e ele vai ver o valor de negócio de cada uma delas. Eu vou exemplificar aqui extremo, só pra mostrar as possibilidades. Nesse exemplo a user story continua no topo, ela tem maior prioridade pro product owner. A user story dois ponto agora é a que está segundo lugar na prioridade. A user story nova ele colocou terceiro. A user story dois ponto três ficou quarto lugar. Aquela user story três, que estava terceiro, agora ela está quinto lugar. E a user story dois ponto dois ele colocou lá último lugar, demonstrando que ela tem pouco valor de negócio. Ou seja, se algum momento o sistema for interrompido ela dificilmente terá sido implementada no sistema. Chamo a atenção de vocês então agora que essas quatro user stories novas que foram introduzidas e agora estão priorizadas termos de valor de negócios, falta ainda definir o tamanho do esforço pra se produzir cada uma delas. Como é que a gente faz isso? Planning poker. A ideia é fazer o planning poker para estimar junto com o PO, porque ele que entende do contexto de cada user story, estimar o tamanho do esforço. No nosso exemplo são valores que exemplificam apenas. A user story dois ponto foi estimado que ela teria cinco pontos de estória, user story nova teria 13 pontos de estória, a user story dois ponto três teria cinco pontos, e a user story dois ponto dois também cinco pontos. Com isso nós acabamos concluindo essa parte de priorizar e estimar. Vamos chamar a atenção para detalhe apenas. Vocês lembram que eu tinha pedido pra guardar qual era o número da epic, eram 21 pontos de estória. Ao quebrar as user stories três novas user stories daquela epic, ao estimar cada uma dessas user stories o que acabamos tendo? Uma com o valor cinco, outra com o valor oito e outra com o valor cinco também. Acabamos então totalizando 18 pontos nessas três novas user stories. A epic original tinha quanto? 21. O que aconteceu? Ao tomar mais conhecimento sobre o que era pra ser feito foi possível ter uma precisão maior na definição dos pontos de estória. Mas atenção, pode acontecer o contrário. Eu posso passar a conhecer melhor e também colocar valor maior. Ou seja, por conhecer agora eu vejo que são user stories mais difíceis de implementar. Pode ocorrer as duas coisas, mas no final o que a gente tem é uma maior precisão. Com isso eu tenho o PBL atualizado agora. Todas as user stories estão com seu valor de negócio, o valor BV, business value, e todos os tamanhos dos esforços foram estimados. Com isso nós concluímos a fase. Ou seja, nós fizemos uma avaliação naquele momento, de como estava o PBL, o product backlog, incluímos novas user stories, quebramos user stories, eventualmente, pode não ocorrer nada disso, repriorizamos, fizemos a priorização novamente e atribuição de estimativas para as user stories que não tinham o tamanho do esforço. Obrigado. [MÚSICA] [MÚSICA]