Fase 2 do Sprint Planning

Loading...

Do curso por Instituto Tecnológico de Aeronáutica

Princípios de Desenvolvimento Ágil de Software

132 classificações

Instituto Tecnológico de Aeronáutica

Princípios de Desenvolvimento Ágil de Software

132 classificações

Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, graças às boas práticas e princípios orientados a objetos, TDD e conceitos avançados de Java aplicados à Web e banco de dados exercitados nos cursos anteriores; mas você talvez não se sinta ainda confortável em planejar e gerenciar o desenvolvimento das aplicações com base em modernas práticas de modelagem ágil. O objetivo deste curso é expor você às principais técnicas e princípios de desenvolvimento ágil, em especial aos que se popularizaram pela sua utilização no framework Scrum e na metodologia XP (Extreme Programming). Apresentamos o Scrum&XP, uma combinação apropriada do framework Scrum com a metodologia XP – Extreme Programming, sem no entanto afirmar que você estará aprendendo tudo sobre Scrum ou sobre XP. Os conceitos apresentados neste curso incluem o seguinte: * Manifesto ágil e princípios de desenvolvimento ágil * Requisitos de software na forma de user stories e backlog de produto * Eventos e reuniões do Scrum&XP: Sprint, Sprint Planning, Planning Poker, Daily Scrum, Sprint Review e Sprint Retrospective, TDD e Programação em Pares * Papéis do Scrum: Product Owner, Time de Desenvolvedores e Scrum Master * Tarefas, Sprint Backlog, Quadro de Tarefas e Diagrama Burndown Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar de modo ágil um sistema que incorpora um componente de gamificação constante do Trabalho de Conclusão do Programa de Cursos Integrados, com base nas boas práticas ágeis exercitadas neste curso com o Scrum&XP apresentado. Obs.: Embora o Programa de Cursos Integrados (descrito abaixo) seja sobre a linguagem Java no contexto de desenvolvimento ágil, neste curso em especial você poderá empregar a linguagem que desejar, embora incentivemos que os alunos dos cursos anteriores do programa faça uso do Java, pois será uma oportunidade muito enriquecedora de praticar TDD com Java da maneira que se faz na indústria de software. -- --- ---- coursera.org: ITA Programa de Cursos Integrados: Programação Java e Modelagem Ágil Curso 1: Orientação a Objetos com Java Curso 2: TDD – Desenvolvimento de Software Guiado por Testes Curso 3: Desenvolvimento Ágil com Java Avançado Curso 4: Princípios de Desenvolvimento Ágil de Software Curso 5: Desenvolvimento Ágil com Padrões de Projeto Curso 6: Técnicas Avançadas para Projeto de Software Curso 7: Arquitetura de Software em Projetos Ágeis Projeto Final: Aplicativo para Web com Componente Gamificado

Na lição

Semana 4

Olá, bem-vindo à Semana 4 do Curso 4 – Princípios de Desenvolvimento Ágil de Software. Ao final deste módulo, você terá aprendido a usar de forma pensada diagramas apropriados na modelagem ágil; terá aprendido também princípios de modelagem ágil e como integrar o TDD no sprint do Scrum. Adicionalmente, você será exposto ao processo adotado, Scrum&XP, na preparação ágil do projeto por meio de um Sprint Zero e a uma forma mais detalhada sobre o Sprint Planning. Você também irá exercitar todo o conhecimento aprendido neste curso e no passado ao desenvolver uma pequena aplicação com gamificação!

O Processo Proposto7:16

Planejamento Inicial: Sprint Zero10:16

Estrutura de Eventos de um Sprint9:23

Fase 1 do Sprint Planning – Parte 18:29

Fase 1 do Sprint Planning – Parte 210:00

Fase 2 do Sprint Planning10:34

Conheça os instrutores

Clovis Fernandes
Professor Titular in Portuguese
Ciência da Computação
Eduardo Guerra
Professor Colaborador

[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]

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2018 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play