Fase 1 do Sprint Planning – Parte 2

Loading...

Do curso por Instituto Tecnológico de Aeronáutica

Princípios de Desenvolvimento Ágil de Software

128 ratings

Instituto Tecnológico de Aeronáutica

Princípios de Desenvolvimento Ágil de Software

128 ratings

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

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