O product backlog

1.091 visualizações

Publicada em

0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.091
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
18
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

O product backlog

  1. 1.  O produt backlog é uma lista de todas as funcionalidades desejáveis num Sistema, que não se encontram ainda em Produtivo. Deve ser mantido pelo product owner , de acordo com uma ordem de prioridades. É muito dinâmico : são adicionados, apagados e reprioritizados items em cada sprint.
  2. 2. Detalhado de As user stories com prioridade mais elevada têm queforma ser suficientemente claras para poderem serapropriada desenvolvidas na sprint seguinte. As user stories que serão feitas mais tarde deverão ser descritas com menos detalhes.Estimado O product backlog é uma lista de todo o trabalho que terá que ser feito, constituindo assim uma ferramenta de planeamento útil.Emergente Muda ao longo do tempo. À medida que se vai(Actualizado) sabendo mais sobre o produto que se pretende, vão- se adicionando, eliminando e reprioritizando user stories.Prioritizado Deve ser ordenado por ordem de importância dos items. Trabalhando sempre de acordo com as prioridades definidas, a equipa pode maximizar o valor do produto ou do sistema que está a ser desenvolvido.
  3. 3.  Os documentos escritos podem ◦ limitar o sentido crítico ◦ e diminuir a responsabilidade da equipa como um todo;Assim, devem-se equilibrar duas necessidades: a de documentar um projecto para a posteridade, a da conversa e discussão que potencia o enriquecimento do projecto.
  4. 4.  As user stories constituem a melhor forma de mudar o enfoque daquilo que está escrito sobre as funcionalidades, para a conversa sobre as funcionalidades. Umauser story é umauma descrição simples e curta Uma user story é descrição simples e curta de uma funcionalidade, vista da perspectiva da pessoa que necessita de mesma, normalmente um utilizador ou um cliente do da uma funcionalidade, vista da perspectiva da Sistema. pessoa que necessita da mesma, normalmente um utilizador ou um cliente do Sistema.
  5. 5. O formato de uma user story é oseguinte :Como um<tipo de utilizador>,eu pretendo<o objectivo> ,de forma a que <razão invocada>.
  6. 6.  As user stories podem ser escritas em cartões de 3”x5” . Um cartão contendo uma user story funciona como uma promessa de dois sentidos: ◦ Os membros da equipa prometem que falarão com o product owner antes de começarem a trabalhar na história; ◦ O product owner promete que estará disponível quando a equipa estiver pronta para falar.
  7. 7.  A elaboração de casos de uso constitui um método alternativo para expressar as funcionalidades de um Sistema. Devem ser utilizados casos de uso breves, poque as equipas de scrum funcionam melhor com unidades de trabalho que sejam mais curtas e concisas que o caso de uso típico.
  8. 8.  Há sempre requisitos supervenientes – funcionalidades ou características que não era possível identificar com antecedência. Numa equipa de scrum, estes requisitos são recebidos com naturalidade, aceitando-se que não se consegue pensar em tudo, ao mesmo tempo.
  9. 9.  O iceberg do Product BacklogPrincípio: Manter as tarefas mais curtas, no topo.
  10. 10.  Uma equipa deve “tomar conta” do seu Product Backlog. Cerca de 10% do esforço de cada sprint deve ser gasto na preparação do Product Backlog para as próximas sprints.
  11. 11. Vantagens de refinar progressivamente os requisitos: Não há uma necessidade real de saber todos os detalhes de algo que não vai ser feito já… Porque, as coisas vão mudar… E o tempo para começar a apresentar resultados, não é muito !
  12. 12.  Épicos são user stories grandes, que levam mais do que uma ou duas sprints para serem desenvolvidas. Um épico deve ser dividido em user stories menores, porque uma equipa deve poder terminar uma user story durante uma só sprint. Alguns épicos são tão grandes que se dividem ainda em épicos.
  13. 13. Como um utilizador, eu posso credenciar-me Épico: com o meu login e password de forma a que que possa confiar no Sistema. Como umutilizador, deveser-me pedidacredenciação Como um novo utilizador, eu quero registar-para aceder ao me utilizando login e passwordSistema, de forma a que o Sistema possa guardar ade forma a que a minha infomação pessoal.informação queme dizrespeito, seja Como um utilizador registado, eu possovista apenas por alterar a minha passwordmim. de forma a torná-la mais segura ou mais fácil de recordar.
  14. 14. Como um utilizador registado, eu quero que o Épico: Sistema me avise se a minha password é fácil de adivinhar de forma a que Como um seja fácil aceder à minha conta.utilizador, deveser-me pedidacredenciação Como um utilizador esquecido, eu queropara aceder ao poder pedir uma nova password de forma queSistema, eu não fique permanentemente bloqueado sede forma a que a esquecer a password actual.informação queme dizrespeito, seja Como um utilizador registado, eu serei notificado se ocorrerem três tentativas falhadasvista apenas por de acesso à minha conta, de forma a que eumim. saiba se alguém tentou aceder à minha conta.
  15. 15. Podemos refinar requisitos, adicionandocondições de satisfação a uma userstory. Uma condição de satisfaçãocorresponde a um teste de aceitação dealto nível, que, deverá ser bem sucedidoquando a user story estiver completa.
  16. 16. Assegurar que funciona com os dias mais significativos para vendas: Como vice Natal, Páscoa, dia de Ano Novo, dia do Paipresidente da área e dia da Mãe. de marketing, quero poder seleccionar certas épocas de férias, Suportar féria que abranjam quando fizer a dois anos de calendário. revisão de performance dasacções publicitárias da empresa, de forma a identificar Seleccionar um período entre dois as mais lucrativas feriados significativos, como o tempo que medeia entre o dia de Acção de Graças e o dia de Natal.
  17. 17. Numa equipa scrum os programadores e os técnicos encarregados dos testes trabalham em conjunto. Um tester deve fazer parte das discussões.Por outro lado, aqueles que beneficiam da documentação devem ser os que a produzem.Assim, os testers tornam-se responsáveis pela produção e manutenção das especificações detalhadas, em termos de cenários testáveis, no início de cada iteração..
  18. 18. Succeding with Agile from Mike Cohn Tradução e adaptação: Maria João Costa Mjoao.gehl.costa@gmail.com

×