no assunto Ele deve conhecer o domínio do negócio o suficiente para criar a visão do produto Responder a questões técnicas no domínio daqueles que estão criando o produto Defensor do usuário final Descrever o produto com conhecimento de usuários e de uso e que o produto atenda a ambos Defensor do cliente (stakeholders) Entender a necessidade do negócio selecionando um mix de funcionalidades que adicionarão valor ao cliente Defensor do negócio Entender a necessidade da organização que está financiando a construção do produto e selecionar um conjunto de funcionalidades que irá servir aos seus propósitos Comunicador Capaz de comunicar a visão e a intenção – oferecendo especificação detalhada da funcionalidade e decisões de design Tomador de decisões Dada a variedade de objetivos e opiniões conflitantes, é necessário colocar um ponto final quando se trata de uma decisão de produto difícil
(ou interação) Priorizar e manter o Product Backlog List Participar da reunião de planejamento da sprint Elaborar US “just- in-time” quando necessário com o time Aceitar/Rejeitar US entregues Aceitar/Rejeitar a entrega da sprint Conduzir e planejar os releases
diversas fases de uma iteração? Pré-Reunião de Planejamento • Maior elaboração de uma história de alta prioridade • Coordenar qualquer objetivo em comum e dependências com outros POs ou stakeholders • Revisar e repriorizar o Product Backlog. Isso inclui: 1. Itens que já estavam no Product Backlog 2. Itens que tiveram falhas nos critérios de aceitação da iteração passada 3. Itens que foram gerados por defeitos ou Bugs • Considerar refactoring necessários, Bugs e dependências • Ter conhecimento da velocidade do time para a próxima iteração
diversas fases de uma iteração? Reunião de Planejamento • O PO apresenta os items do Product Backlog para discussão • O time discute cada item até que esteja claro o que deve ser feito e qual o objetivo de cada item para que ele possa quebrar e estimar as tarefas necessárias para implementar essa história Durante a execução da iteração • O PO deve trabalhar com o time para elaborar novas histórias “just-in-time” caso seja necessário • Modificar o escopo onde for necessário para cumprir os objetivos da Sprint • Participar das Daily Meetings • Homologar as histórias que já estão disponibilizadas para tal • Aceitar/ Recusar histórias que tiveram/não tiveram seus critérios de aceitação satisfeitos
diversas fases de uma iteração? Reunião de Revisão • Apresentar cada item da iteração em funcionamento • Discussão e feedback de todos os envolvidos • Mudar o estado de uma história para “Aceito” (se já não foi feito) ou deixa-la caso esteja incompleta • Ao final revisar se o objetivo da Sprint foi alcançado e aceitar a iteração com base no trabalho que o time todo fez (incluindo o próprio PO) Reunião de Retrospectiva • Há uma discussão entre autores e processos com relação à essa parte • Alguns defendem que o PO não participa dessa reunião. Já outros que ele pode participar como qualquer outro membro do time
de comunicação O PO é a “cola” que gruda os stakeholders com o time de desenvolvimento. Sendo assim é necessário boas habilidades de comunicação pois ele deve traduzir os objetivos de negócio e de usuários para um nível de detalhamento específico para o desenvolvimento.
senso de negócio O foco do Agile é entregar valor. Isso demanda que o PO tenha um bom conhecimento no domínio do negócio. Nesse sentido ele consegue entender e elaborar US de maneira que possa entregar real valor ao usuário. Ele também deve ser capaz de estabelecer prioridades e negociar funcionalidades do sistema e de performance. Ele deve ser capaz de balancear as necessidades do usuário com o do negócio.
técnico Se o PO possui conhecimentos técnicos, mesmo que básicos, ele consegue avaliar melhor certas requisições. A habilidade de priorizar (de forma inteligente) refactors, Bugs e débitos técnicos versus histórias que irão agregar um novo valor requer compreensão e respeito pelos desafios técnicos que o time enfrenta.
Com a velocidade que o desenvolvimento ágil proporciona, “sem decisão” é pior do que qualquer decisão. O PO deve ser capaz de tomar decisões, todos os dias, mesmo estando longe do conhecimento perfeito. Isso requer coragem e habilidade de reconhecer quando errou. Mas isso é Agile apesar de tudo – aprendemos mais com os erros do que com os acertos.
Uma vez que a priorização e gerenciamento do que deve ou não deve ser feito está sob a guarda desse papel, a característica mais importante é a confiança. O time deve confiar no PO que ele será capaz de fazer decisões difíceis como defender a qualidade técnica e funcionalidade quando for necessário; e os stakeholders devem confiar no PO para representar fielmente as prioridades para o time.
Part-Time POs Priorizar e gerenciar o backlog, especificar histórias, participar ativamente da Sprint esclarecendo dúvidas, adicionar histórias “just-in time”, aceitar histórias, entender necessidades, calcular valor de negócio das funcionalidades, etc... Há inúmeras tarefas que o PO deve desempenhar e é muito difícil uma pessoa dividir seu tempo em PO e uma outra função sem que nenhuma delas saia prejudicada. PO Proxies Um PO mais de um time. Se fazer tudo o que foi descrito para um único time imagine para 3 ou 4 times? PO quase não toma decisão sempre tem que perguntar para outra pessoa. PO Teams “The product owner is one person, not a committee” [Schwaber and Beedle , 2002]. “Each teams needs exactly one product owner” [Cohn, 2010]
você fez desde que acordou até chegar ao trabalho. Transcreva cada tarefa em um post-it 2) Dividam-se em grupos de 4 pessoas. Tentem agrupar essas tarefas e dar um nome à esse agrupamento. Eliminem tarefas iguais. Ordene-as da esquerda para a direita de uma maneira que faça sentido para o time 4) Quais itens eram comuns daqueles que você escreveu? Quais eram diferentes? Os modelos criados pelos grupos variaram muito do que o seu grupo criou? 3) Dêem uma olhada nos modelos criados pelos outros grupos.
ou a cadeia de valor Mostrar o relacionamento entre user stories maiores com suas filhas Ajudar a confirmar o cumprimento do seu backlog Oferecer um contexto útil para a priorização Ajudar a planejar releases completos e/ou incrementos de funcionalidades que adicionam valor
Tarefas requerem ação intencional em nome de usuário • Tarefas têm um objetivo que pode ser alcançado • Tarefas podem ser decompostas em tarefas menores • Tarefas muitas vezes podem ser agrupadas em atividades de tarefas relacionadas • User tasks fazem as melhores User stories “Ler um email” é uma tarefa. “Gerenciar email” é uma atividade Gerenciar email Ler email Enviar email Deletar email Criar pastas Colocar email na pasta
ou “Sea level” Eu razoavelmente espero concluir isso em uma única sessão. SubFuncionalidade ou “Fish level” Pequenas tarefas que, por si só, não significam muito. Vou fazer várias destas antes de eu chegar a um objetivo nível funcional Atividade ou “Kite level” Metas de longo prazo, muitas vezes sem fim preciso. Vou executar várias tarefas funcionais, no contexto de uma atividade. Muito abstrato Muito detalhado Pense na experiência de usuário nesse nível * from Cockburn’s Writing Effective Use Cases
de um usuário Descrição de um produto Item de planejamento Lembrete de discussão * Kent Beck coined the term user stories in Extreme Programming Explained 1st Edition, 1999
2) Adicione uma descrição concisa, você pode utilizar o famoso template: “Como [usuário] Gostaria de [ação] Para que [alcançar um objetivo]” 4) Adicione outras notas relevantes, especificações, imagens, rascunhos, wireframes 3) Escreva os critérios de aceitação de uma forma objetiva. (Como sabemos que terminamos?)
iremos criar um sistema para streaming de programas de tv e filmes. 2) Pensem em todas as atividades (kite level) que um usuário pode realizar no sistema. Utilizem um post-it grande (ou de uma única cor) para sinalizar essas atividades. 3) Desenhem uma linha com sentido da esquerda para a direita e organizem os post-it das atividades em uma ordem de maneira que responda a pergunta “O que a pessoa faz com o sistema?” time
user tasks de cada uma dessas atividades. Escreva cada uma delas em post-it de outra cor (ou tamanho menor) e coloque-as abaixo de cada atividade. Uma user task deve ter um título bem visível e objetivo. Utilizem apenas o verbo principal da tarefa para o título time
tarefas verticalmente se o usuário pudesse fazer várias tarefas ao mesmo tempo e horizontalmente caso seja uma consequência • Se contando a história eu digo que o usuário do sistema poderia fazer isso “ou” aquilo os “ou” devem ficar vertical. • Caso seja “e então” tal coisa, a tarefa deve ser colocada horizontalmente. time Abaixo de cada atividade estão as tarefas que fazem aquela atividade acontecer
eixo y no Story Mapping que indica Necessidade e mova as tarefas pra cima ou pra baixo de acordo com “quão necessário aquilo é para alcançar o objetivo da atividade” • Para que o usuário alcance o objetivo da atividade, é necessário que ele faça essa tarefa? Se não é absolutamente necessário, o quão crítico ela é? time necessity
Map tentando contar a história por ela • Escolha uma atividade para começar • Quando ler da esquerda para direita use “e então” para conectar os post-its na história • Para post-its na mesma coluna utilize “ou” para conectá-los • Para post-its no topo do eixo y (necessidade) utilize “absolutamente necessário” e utilize “opcionalmente” para mostrar opção • Escolha um nome concreto para o usuário para ajudar na história time necessity “Sansa Stark faz o login e então na busca pesquisa pelo título do filme . Opcionalmente, ela pode pesquisar pelo diretor ou pelos atores. E então, após ver os títulos retornados da busca, Sansa Stark vê os detalhes, e então, ela assiste o filme ou adiciona aos favoritos.”
all rights reserved, www.AgileProductDesign.com O backbone da aplicação é a lista de atividades essenciais que a aplicação deve suportar O walking skeleton é o software que construímos que suporta o menor número de tarefas necessárias em toda a extensão da experiência do usuário time necessity The backbone The walking skeleton
O que mais usuários do Sistema podem fazer que não apareceu nos cenários? Encontre exceções O que poderia dar errado e o que o usuário poderia fazer para se resolver? Considere outros usuários Que outros tipos de usuários fazem para alcançar seus objetivos?
produto irá preencher? Product Goals, User Personas Release Como iremos adicionar valor incrementalmente? Quais subsets de objetivos de negócio iremos alcançar com cada release? Quais capacidades (Epics/Atividades) a release irá oferecer? Release RoadMap Sprint O que especificamente iremos construir? (User Stories) Como essa interação irá nos levar para o objetivo do release? Interation Goal Desenvolvimento das tarefas US (Backlog Item) A US vai de encontro com o que os stakeholders precisam? Quais comportamentos, especificamente, isso irá ter? O que determina que isso foi alcançado (completado)? US Scenaries, Acceptance Criteria, Acceptance Tests Produto Release Sprint User Story Portifólio do produto Estratégia de Negócio
consideram a extensão da funcionalidade de negócios e atividades do usuário Apoiar todas as atividades necessárias com o primeiro lançamento Melhorar o apoio à atividade e adicionar atividades adicionais com versões posteriores tempo necessidade necessário Menos opcional Mais opcional primeira release segunda release terceira release
vez • A utilização incremental pode ser usada quando há uma total ideia do que deve ser feito. • Então, fazer isso no tempo exato requer uma estimativa muito afiada 1 2 3 4 5
Iterativo constrói uma versão mínima, que depois é validada e, então, pouco a pouco melhorada • A utilização iterativa permite que você se mova da vaga ideia para a concretização fazendo ajustes no caminho “on the fly”
transmission suspension brakes exterior body Interior seating tires sprint 1 2 3 4 Imaginem que vamos montar um ônibus de maneira incremental em apenas 4 sprints. ?
su pp ort release D D D D D I I B- C C- D D D D A- B B- B B B B- A- A B A A- A- B- sprint 1 2 3 4 Nós sabemos que cada história pode ser dividida em pelo menos 4 partes As primeiras iterações são para construir as necessidades básicas, depois disso vai aumentando o valor da funcionalidade
reicamargo
lambda
gakumura
diggymo
ymd65536
suzuki_tada
recruitengineers
skrb
pei0804
techtekt
asahihidehiko
riz3f7
kurochan
kneath
colly
swwweet
tammielis
jakevdp
rmw
sergeychernyshev
lara
philnash
danielanewman
mza
csswizardry
