Fase 1 do Sprint Planning – Parte 1

Loading...

Do curso por Instituto Tecnológico de Aeronáutica

Princípios de Desenvolvimento Ágil de Software

131 classificação

Instituto Tecnológico de Aeronáutica

Princípios de Desenvolvimento Ágil de Software

131 classificação

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

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