Planning Poker

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 3

Olá, bem-vindo à Semana 3 do Curso 4 – Princípios de Desenvolvimento Ágil de Software. Neste módulo você aprofundará seus conhecimentos sobre os papeis do Scrum; terá aprendido como quebrar user stories em tarefas; e terá seus primeiros contatos com o planejamento de um sprint/iteração, com um hands-on interessante sobre o uso do Planning Poker para estimar o esforço/tamanho de user stories.

Erros em Planejamento de Software13:03

Priorizando User Stories7:07

Estimando User Stories e Tarefas8:44

Planning Poker8:35

Hands-on - Cartas do Planning Poker7:07

Dinâmica de uma Iteração10:40

Conheça os instrutores

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

[MÚSICA] Olá a todos!

Meu nome é Eduardo Guerra.

Esse é o curso Princípios de Desenvolvimento Ágil de Software.

Nessa aula vamos falar sobre o Planning Poker, que é uma ferramenta muito legal

que o pessoal da comunidade ágil utiliza pra ajudar nas

estimativas e também as vezes pra fazer avaliação de risco,

estimativas tanto de user story como de tarefa.

Vamos ver aí como que funciona.

Imagina o seguinte: o cara chega lá, o cliente escreveu lá as user stories,

vocês estão vendo aí com o Professor Clovis vários detalhes, e aí pega uma user

story e pergunta: Quanto tempo que você demora pra estimar essa user story?

Quanto tempo você demoraria para desenvolver essa user story?

Aí vai o nosso amigo ali de azul e pensa, acho que três horas,

o da gravata, 12, o da camisa preta de cavanhaque,

24, o outro ali está pensando na cerveja,

no happy hour que vai ter mais tarde, o outro está meio com sono,

não está nem pensando nada, está meio quase dormindo ali.

E aí o que acontece?

Vai o cara que pensou três horas,

e fala assim, olha eu acho que dá pra fazer três horas.

E aí, não se você lembra, mas tinha pensando 12 e 24.

O cara me vem com três?!

E aí os caras se assustam.

Falam: Poxa eu tinha pensado muito mais.

Por que será que o cara falou três?

Aí o cara que tava alí pensando no chopp: é, três.

E o outro que estava dormindo continuou dormindo, ele continua alí tranquilão.

E aí quando o cara fala três o que o resto do pessoal vai fazer?

O que estava pensando mais, 12, 24,

ele vira e fala assim: Não vou falar três,

mas também não vou falar 12 né, vou falar que cinco, o outro vai falar sete.

Então de uma certa forma ele acaba diminuindo aquilo que ele estava

pensando influenciado por aquele primeiro que falou três.

Os outros dois de baixo, o que estava pensado no chopp,

o que estava meio dormindo, como eles não estão pensando nada mesmo,

eles vão concordar com o primeiro que falou.

Não, beleza, acho que é três mesmo.

E isso daí vai criar uma falsa sensação de que parecia ter consenso na equipe,

ou que a maioria das pessoas da equipe achava que dava pra fazer três,

enquanto era só, e os outros estavam pensando muito mais.

Então a ideia do planning poker é você ter

cartas onde você escolhe qual é o tempo que você quer,

observa que tem uma sequência baseada no Fibonacci, pelo menos até o 20 ali.

A partir dessas cartas cada vai lá e escolhe quanto que,

qual o valor, e eles mostram ao mesmo tempo.

Então a grande sacada do planning poker está nessa questão de você escolher e

todo mundo revelar ao mesmo tempo.

Então dessa forma a estimativa que faz não influencia na do outro.

Vamos ver exemplo de como que seria isso daí.

Imagina o seguinte, aquela mesma situação,

aí o cara que estava pensando no chopp, ele que parar e escolher uma carta,

ele não vai mais poder ficar ali pensando outras coisas,

ou no filme que ele assistiu, etc.

O outro que estava dormindo, também não pode ficar dormindo,

porque ele também tem que dar uma carta com a opinião dele.

E ele sabe que a equipe inteira vai ver aquilo ali.

Então todo mundo vai lá e escolhe as suas cartas.

Note que o que estava pensado 12, 24, agora eles já estão 13 e 20, que é o quê?

São os números do Fibonacci, das cartinhas.

Então cada escolhe a sua carta e todos revelam ao mesmo tempo.

Aí ele fala: Opa, pera aí!

A gente tem três e tem 20 aqui, tem uma grande diferença entre essas cartas.

Normalmente quando a diferença é grande significa que não houve

entendimento muito bom da equipe relação aquela estória.

Ou seja,

alguém está achando que é muito difícil e o outro está achando que é muito fácil.

Talvez o que está achando muito difícil está com medo de alguma coisa

que os outros já tenham maior conhecimento.

Ou talvez quem está achando muito fácil esqueceu de alguma coisa que seria

necessária.

Então isso é sinal que a equipe não está alinhada relação.

Então é aí que eles vão discutir.

A ideia é que tanto quem colocou o número mais alto e o mais baixo

coloquem as suas opiniões e aí eles jogam de novo.

Não tem essa de fazer uma média, a ideia é que se chegue a consenso.

Eles vão jogando até que eles cheguem a consenso.

Nessa segunda rodada três colocaram cinco, colocou a mais que foi oito,

outro colocou a menos, que foi três.

Então a equipe vira e: olha, e aí?

Você aceitaria cinco como estimativa?

Lá pro cara que colocou oito, ou três: Você acha que a gente pode fazer cinco,

talvez a gente não tenha a mesma experiência.

Então a galera chega num consenso e cinco fica, por exemplo, como a estimativa.

Se o cara de oito falou: Não não concordo,

ainda acho que tem que ser mais por causa disso e disso.

Aí ele explica, vamos jogar de novo.

E aí eles jogam outra vez e veem no que que dá, até que se chegue no consenso.

E aí é aquela coisa.

Muitas vezes tem-se ideias, ou as pessoas acabam tendo que aumentar

ou diminuir a sua estimativa pra chegar nesse consenso.

E aí nesses casos a gente considera que existe certo risco.

Eu já chego lá.

O que são esses números altos?

A ideia é o seguinte,

quanto mais alto a gente estima, com menos precisão a gente estima.

Então, por exemplo, normalmente a partir de 20, quando chega no 20 ou pra cima,

significa que aquela estória é muito grande, com 100 já vira épico.

Então a gente tem que, realmente, tentar quebrar aquela estória, ou aquela tarefa,

pra poder estimar melhor qual que é o tempo, ou story points ou horas ideais,

daquilo que está sendo feita a estimativa.

O zero, se achar que alguma coisa é tão rápida que não vale a pena,

você coloca ela ali como uma tarefa que tem que ser feita e, de repente,

ela vai usar aqueles restinhos de tempo de outras tarefas.

E a interrogação é quando você não entendeu alguma coisa.

Muitas vezes, na discussão,

quem é mais tímido não consegue colocar sua opinião, coloca a interrogação e aí

ele pode fazer a pergunta e depois as pessoas vão jogar de novo.

Quanto maior a dificuldade fazer a estimativa, maiores as discussões,

maior o risco daquela estória.

Quanto mais preciso você consegue estimar, quanto mais fácil de chegar num consenso,

quer dizer que aquilo ali está bem compreendido pela equipe.

Então o risco de se fazer aquilo é menor.

Quando tem muita dúvida, muita questão, muita coisa incerta,

você tem que ter uma estimativa.

Afinal, não é, você não tem que dar a resposta com certeza, é uma estimativa.

Só que quando demora você diz que aquilo tem risco maior.

Então isso é uma coisa interessante também de ser registrada,

pra que ela possa ser incluída no começo da iteração, pra tratar aquele risco logo.

Ou deixada pro final, com a possibilidade de, talvez,

ser jogada pra próxima iteração.

Então, essa informação, essa dificuldade também

pode ser uma informação relevante a ser usada pela equipe.

Tá certo?

Essa foi a ideia do planning poker.

Eu fiz aí hand zone entre aspas, com algumas cartas, pode olhar lá,

eu acho que vai ficar pouquinho mais claro como que funciona a dinâmica.

Certo?

Muito obrigado, até a próxima.

[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