[MÚSICA] Olá! Bem-vindo ao curso Princípios de Desenvolvimento Ágil de Software. Eu sou Clovis Fernandes e hoje iremos apresentar a fase 2 do Sprint Planning. Na fase 1 nós fizemos uma avaliação do Product Backlog. Nós temos agora nesse momento PBL atualizado, que todas as user stories novas têm seu valor de negócio atribuído e têm seu tamanho do esforço de desenvolvimento também estimado. Com isso, o PO, ele tem definido mais precisamente qual é o seu objetivo, está certo, que é aquele conjunto de user stories que estão no topo, está certo? E o papel dele agora é convencer a equipe, o time, a aceitar fazer esse topo. Será que ele consegue? Primeira tarefa do PO e do time é completar aquela parte Why das user stories que a gente disse que não era obrigatório no sprint 0, está certo? Mas algum momento elas têm que estar prontas, se for possível, elas não são obrigatórias. Então nesse momento isso ajuda a mais uma conversa, uma conversação, entre o PO e o time, para esclarecer as user stories de tal forma que seja possível definir essa parte Why. Outra coisa que também é fruto dessa conversação, e que também não era obrigatório definir anteriormente, eram os testes de aceitação, eu estou chamando de Acceptation Tests, ou ATs. Mas os testes de aceitação, lá no sprint 0, não era obrigatório fazer pra todas as user stories, por questões de tempo, ou porque estava difícil de definir. Mas agora é a hora. Agora é a hora de definir e complementar os testes de aceitação. É muito importante que os testes de aceitação sejam definidos porque eles é que vão guiar se eu completei a user story de acordo com o que o PO estava querendo, ou não, está certo? Então nessa hora você complementa colocando user stories, testes de aceitação user stories que não tinham nenhum teste de aceitação, ou pondo novos testes de aceitação user stories que já tinham testes de aceitação, ou trocando alguns testes anteriores por outros novos. É isso que a gente faz. Ao fazer isso se ganha conhecimento muito grande sobre as user stories, sobre os seus contextos e o que deve ser feito e o que vai ser cobrado, está certo? E isso vai facilitar a vida na hora do time desenvolver as user stories que eles escolheram, está certo? Com isso a gente fica com o PBL agora. Espera-se que com todos os testes de aceitação pras user stories, mas apenas para aquelas do topo. Eu não vou me preocupar com aquelas que eu não vou implementar agora. Por isso que eu não preciso ficar perdendo tempo com, por isso que a gente define, o PO define aquele objetivo do que ele quer tratar, pra que você se restrinja apenas a essa parte. É isso que está feito. Nós temos aqui então agora PBL atualizado, muito mais atualizado porque todas as partes Whys estão colocadas e todos os testes de aceitação também estão colocados. Agora é uma parte muito importante. Eu já disse pra vocês que quem facilita todas as reuniões é o scrum master, e nessa hora ele vai estar sempre perguntando: Time, essa user story do topo, vocês conseguem fazer, tem todas as condições para desenvolvê-la? Porque pode existir que alguma story esteja no topo, mas não exista ainda uma, vou dizer assim, uma disponibilidade técnica e ela não pode ser eventualmente ser feita naquele momento. Ou então, por isso que isso é uma negociação entre o PO e o time, ou então o time está querendo desenvolver alguma coisa mais técnica, como por exemplo, definir banco de dados, ou estruturar alguma coisa que tem a ver com arquitetura, está certo? Então é uma discussão que vai haver. Ao final dessa discussão, ou seja, a cada momento discutido, vai se confirmando as user stories que o time está disposto a fazer. Neste caso suponhamos que o time esteja disposto a fazer essas três user stories, que somam 26 pontos de estória. A velocidade do time, ou seja, a quantidade de pontos de estória que o time está acostumado a desenvolver é 25. Mas isso era no passado. Nesse momento, por exemplo, se for o sprint que esteja jogo, seria prudente não implementar tantos pontos de estória. Seria importante talvez quebrar a user story nova, que tem 13 pontos de estória, user stories menores e ficar com número menor, está certo? Eventualmente 18 pontos, 20 pontos, ou algo assim. Pontos menores. Pra você ter uma folga por causa que o primeiro sprint dá mais trabalho fazer. Se o sprint já está no fluxo normal, aí você pode aceitar fazer ponto a mais do que seria sua meta, não tem problema isso. A outra atividade que é muito importante também na fase dois é, dado que eu já defini que user stories eu estou disposto a fazer, eu vou pegar cada uma, agora é o time que vai fazer isso, eu vou pegar cada uma dessas user stories e vou quebrar tarefas, está certo? Eu já tinha dito anteriormente que existem grupos de desenvolvimento que não quebram tarefas. Eles são capazes de trabalhar a user story e já vão direto. A maioria dos grupos, mesmo os experientes, prefere quebrar tarefas. Porque isso acaba mostrando melhor o progresso, está certo, e faz também com que o time tenha uma precisão maior, entendimento maior sobre o que deva ser feito, está certo? Então por isso a ideia é quebrar tarefas, essa é uma atividade primordial. Como a gente já disse, tendo escolhido as user stories, tendo quebrado cada user story suas tarefas, agora chega ponto importante nesse ritual, nessa reunião, que a gente chama de Sprint Planning. E o scrum master, nessa hora ele vai reafirmar junto ao time o comprometimento que o time tem de desenvolvimento daquelas user stories que agora estão com as suas tarefas todas bem definidas, está certo? Concluído isso, ou seja, o time falando afirmativamente, sim, estamos comprometidos, está certo, o que vai acontecer? Esse conjunto de user story, as três user stories, e o seu conjunto de tarefas associadas a cada user story vai compor o que nós chamamos de o Sprint Backlog, está certo? Então vocês vejam que agora a gente tem 2 Backlogs. Que é durante o projeto inteiro, que é o Product Backlog, o PBL, está certo, e o que é válido apenas para o sprint, que é o sprint backlog, o backlog do sprint, ou seja, é o conjunto de user stories e respectivas tarefas que devem ser desenvolvidas naquele sprint. E obviamente essas user stories saem do PBL, está certo, ou seja, no nosso PBL momento, no topo está a user story 2.3. Com isso a gente conseguiu então produzir conjunto de user stories, que estamos chamando de sprint backlog, que vai nortear todo o desenvolvimento daquela equipe, e isso, ao longo do sprint, não muda, está certo? Pode ver que a priorização também foi colocada ali, porque a ideia é que você comece a desenvolver, dentro do sprint, as tarefas das user stories de maior prioridade, está certo, e nessa hora do desenvolvimento outra coisa importante é que os elementos do time, está certo, eles é que vão escolher que tarefa eles querem desenvolver. Chegam num acordo e vão desenvolvendo, está certo? Então se você tem 5 elementos, provavelmente 4 vão desenvolver as quatro tarefas da user story 1 e 1 vai começar já a desenvolver uma tarefa da user story dois, e assim o sprint continua. Com isso concluímos, com a fase dois, todas as atividades do sprint planning. Ou seja, ao final desse conjunto de 3 aulas você agora já sabe o que consiste o sprint planning no nosso contexto do Scrum e XP. Obrigado! [MÚSICA] [MÚSICA]
