Embed Size (px)
Citation preview
O Product Backlog
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.
Product Backlog
Detalhado de forma apropriada
As user stories com prioridade mais elevada têm que ser suficientemente claras para poderem ser 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 (Actualizado)
Muda ao longo do tempo. À medida que se vai 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.
Atributos do Product Backlog - DEEP
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.
Documentar ou discutir ?
As user stories constituem a melhor forma de mudar o enfoque daquilo que está escrito sobre as funcionalidades, para a conversa sobre as funcionalidades.
Uma user story é uma descrição simples e curta de uma funcionalidade, vista da perspectiva da pessoa que necessita da mesma, normalmente um utilizador ou um cliente do Sistema.
Documentar ou discutir ?
Uma user story é uma descrição simples e curta de uma funcionalidade, vista da perspectiva da pessoa que necessita da mesma, normalmente um utilizador ou um cliente do Sistema.
Documentar ou discutir ?
O formato de uma user story é o seguinte :Como um<tipo de utilizador>, eu pretendo<o objectivo> ,de forma a que <razão invocada>.
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.
Documentar ou discutir ?
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.
Documentar ou discutir ?
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.
Refinar progressivamente os requisitos
O iceberg do Product Backlog
Princípio: Manter as tarefas mais curtas, no topo.
Refinar progressivamente os requisitos
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.
Refinar progressivamente os requisitos
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 !
Refinar progressivamente os requisitos
É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.
Refinar progressivamente os requisitos
Dividindo um Épico em user stories menores
Épico:
Como um utilizador, deve ser-me pedida credenciação para aceder ao Sistema, de forma a que a informação que me diz respeito, seja vista apenas por mim.
Como um utilizador, eu posso credenciar-me com o meu login e password
de forma a que que possa confiar no Sistema.
Como um novo utilizador, eu quero registar-me utilizando login e password de forma a que o Sistema possa guardar a
minha infomação pessoal.
Como um utilizador registado, eu posso alterar a minha password
de forma a torná-la mais segura ou mais fácil de recordar.
Dividindo um Épico em user stories menores
Épico:
Como um utilizador, deve ser-me pedida credenciação para aceder ao Sistema, de forma a que a informação que me diz respeito, seja vista apenas por mim.
Como um utilizador registado, eu quero que o Sistema me avise se a minha password é fácil
de adivinhar de forma a que seja fácil aceder à minha conta.
Como um utilizador esquecido, eu quero poder pedir uma nova password de forma
que eu não fique permanentemente
bloqueado se esquecer a password actual.
Como um utilizador registado, eu serei notificado se ocorrerem três tentativas
falhadas de acesso à minha conta, de forma a que eu saiba se alguém tentou aceder à
minha conta.
Podemos refinar requisitos, adicionando condições de satisfação a uma user story. Uma condição de satisfação corresponde a um teste de aceitação de alto nível, que, deverá ser bem sucedido quando a user story estiver completa.
Condições de Satisfação
Condições de Satisfação
Como vice presidente da
área de marketing, quero poder seleccionar
certas épocas de férias,
quando fizer a revisão de
performance das acções
publicitárias da empresa, de
forma a identificar as
mais lucrativas
Suportar féria que abranjam dois anos de calendário.
Seleccionar um período entre dois feriados significativos, como o
tempo que medeia entre o dia de Acção de Graças e o dia de Natal.
Assegurar que funciona com os dias mais significativos para vendas: Natal, Páscoa, dia de Ano Novo, dia do Pai e dia da Mãe.
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.
.
Reduzir a necessidade de documentação
Como trabalhar a informação que temos
Succeding with Agile from Mike Cohn
Tradução e adaptação: Maria João Costa
Referência Bibliográfica
