scrum product owner v3

8/9/2019 SCRUM Product Owner v3

1/[email protected] 2 Plus

p

Workshop

SCRUM Product Owner

Rildo F [email protected]@companyweb.com.br

Twitter: @rildosanBlog: http://rildosan.blogspot.com/



p

Rildo F. Santos, CSM, CSPO

Tem mais de 10.000 horas de experincia em Gesto de Negcios, Governana eEngenharia de Software.Formado em Administrao de Empresas, Ps-Graduado Didtica do Ensino Superior

e Mestre em Engenharia de Software pela Universidade Mackenzie.

Atua em Gesto de Negcio (Inovao, Processos e GRC) e em projetos deEngenharia de Software utilizando mtodos Agile (SCRUM, Lean, XP e FDD) AgileCoach.

Foi instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java na SunMicrosystems e da IBM.

Conhece Arquitetura de Software, SOA (Arquitetura Orientado a Servio), RUP/UP -Processo Unificado, Business Intelligence, Gesto de Risco de TI entre outrastecnologias.

Professor de curso de MBA da Fiap e foi professor de ps-graduao da Fasp e IBTA.

Tem forte conhecimentos de Gesto de Negcio (Inteligncia de Negcio, Gesto porProcesso, Inovao, Gesto de Projetos e GRC - Governance, Risk and Compliance),SOX, Basel II e PCI;

Tem vivncia na implementao de Governana de TI e Gerenciamento de Serviosde TI, Conhecimento dos principais frameworks e padres: ITIL, Cobit, ISO 27001 eISO 15999;

Desempenhou diversos papis como: Estrategista de Negcio, Gerente de Negcio,Gerente de Projeto, Arquiteto de Software, Projetista de Software e Analista deSistema em diversos projetos em empresas como: Bradesco, Editora Abril, Scopus,Porto Seguro, Certagy, Secretria da Fazenda SP, Sonagol (Angola),Honda, Dix-Amico, Bank Tokyo-Mitsubishi, Vivo, Hospital das Clinicas, Aos Villares,

Novabase do Brasil, Policia Militar do Estado de So Paulo entre outras.

Possui as certificaes: CSM - Certified SCRUM Master, CSPO - Certified SCRUMProduct Owner ,SUN Java Certified Instrutor , ITIL Foundation e Instrutor Oficial deCobit Foundation e Cobit Games;

membro: IIBA-International Institute of Business Analysis (Canada)

Twitter: @rildosan

Blog: http://rildosan.blogspot.com/
http://twitter.com/rildosanhttp://twitter.com/rildosanhttp://twitter.com/rildosan



p

Introduo:

Workshop Scrum Product OwnerComo garantir o ROI em projetos geis

Em projetos geis o Scrum Master responsvel por garantir o

processo e que as prticas Scrum sejam seguidas. J o ProductOwner (PO) responsvel pelo produto e pelo ROI do projeto, istofaz que o papel de PO seja um fator critico de sucesso.O PO deve trabalhar totalmente alinhado e integrado com o timepara que o ROI seja alcanado. Este eBook tem como objetivo fazeruma introduo sobre o tema Product Owner e apresenta uma visoprtica e prover conhecimentos bsicos sobre o papel de Product

Owner (PO) e sua atuao nos projetos geis.

Ser demonstrado como PO pode otimizar os resultados do projetoe gerar valor para o cliente.

Tambm apresentado as principais tcnicas e ferramentas queajudam PO a criar um Plano de Release realista. Elaborar,

gerenciar e priorizar o Product Backlog, e desenvolver o ReleaseBurndown para acompanhar o progresso do projeto.

Depois de lido este eBook os leitores entenderam qual o o realpapel do PO em Projetos geis e estaro preparados paradesempenhar ou ajudar o PO em suas atividades.

Este material parte dWorkshop SCRU

Product Ow



p

Desafios doDesenvolvimento

de Software



p

Quanto custar ?O cliente quer saber quanto custar o software...

Quanto estar pronto ?O cliente quer saber quanto o software estar prontopara ele usar...

O cliente QUER respostas ?



p

Falha na Comunicao. A eterna fonte de problema

Dificuldade para entender as necessidades dosstakeholders (clientes)



p

Por que os projetos falham:

37% das falhasestorelacionadascom requisitos

Craig Larman,Agile and Iterative Development: A Managers Guide, AddisonWesley Professional (2004)

7

Informaoerrada

13%Requisitosincompletos

12%

Mudana de

Requisitos

12%Falta de

conhecimentotcnico

7%Falta de

competncia

6%

Outros

50%

Sempre

7% Freqentemente

13%

As vezes

16%

Raramente19%

Nunca

45%

Contudo, amaioria dasfuncionalidades nuncaso usadaspelosusurios

Uso de funcionalidades do Software



p

Como aumentar a produtividade da equipe

de desenvolvimento de software ?

Produtividade da Equipe:

Satisfao dos Clientes



p

Qual a soluo ?

Contratar maisdesenvolvedores...

Mas, ser que acontrataode novas pessoasgaranteo aumento deprodutividade ?

A falta de produtividade pode afetar o negcio

The Mythical Man Month by Frederick Brooks, 1975*.

Quando um projeto est atrasado, contratar novas pessoas para ajudar noprojeto pode servir apenas para atras-lo ainda mais.

Pois, as novas pessoas precisam primeiro entender o que projeto, objetivosescopo, funcionalidades e etc, para depois comear a produzir, ou seja, temosque considerar o tempo que ser gasto com explicaes, orientaes,comunicao e treinamento das novas pessoas, devemos considerar oesforo da gesto de projetos que aumentar

Ao calcular o tempo que ser necessrio para desenvolver um software, temo

que adicionar um tempo extra, pois os desenvolvedores precisam de "tempopara pensar, tempo para pesquisar alm do "tempo para desenvolver"

"Adicionar novas pessoas a um projeto de software atrasado sadiar a sua entrega." - A Lei de Brooks



p

Por que precisamos dos Mtodos geis ?

Para enfrentar estesdesafios:

Utilizao de mtodosgeis, como SCRUM,

podem ser a amenizarestes problemas.

Problemas clssicos (ou tradicionais):Stakeholders (Clientes):- Tm dificuldades em externar suasnecessidades- Geralmente fazem mudanas de requisitos- Precisam do software funcionando paraontem

Desenvolvedores:- No sabem ou no querem elicitar requisitos- Dificilmente conseguem atender todas asdemandas de negcio

- Tem dificuldade em comunicar e entenderos clientes



p

Entendendo o SCRUM



p

O que o SCRUM ?

Ken Schwaber

O que o SCRUM ?SCRUM um processo iterativo eincremental para desenvolvimento dequalquer produto ou gerenciamento

de qualquer trabalho...

SCRUM :Processo emprico de gerenciamentoe controle.- Faz a inspeo e adaptao emloops de feedback

- Faz entrega de valor ao cliente emat 30 dias;- Escalvel para suportar grandesprojetos- Compatvel com CMM3 e ISO9001- Extremamente simples, mas muitoresistente...

Valores do Scrum::- Transparncia-Integridade: assim que perceberalgo, faa algo

- Ser emprico- Auto-organizao

- Entrega de valor

As origens

SCRUM um Mtodo GIL para desenvolvimento de software

The New, NewProduct

DevelopmentGame

TimeBoxes

Iterative,Incremental

Development

SmallTalkEngineering Tools



p

No existe a Bala de Prata:

SCRUM no a Bala de Prata:

O SCRUM no a soluo completa para os problemas de produtividade,complexidade, custo, prazo e qualidade do processo de desenvolvimento desoftware.

No existe soluo mgica para problemas complexos

Contudo, voc pode utilizar o SCRUM para:

- SCRUM ideal para desenvolvimento de software complexos onde os requisitosmudam rapidamente;

- SCRUM processo gil para gerenciar e controlar desenvolvimento de trabalho;

- SCRUM possibilita que voc utilize as praticas de engenharia existentes e que jso conhecidas;

- SCRUM baseado na abordagem de equipe auto-gerencivel e multifuncional;

SCRUM trabalha com conceito iterativo e incremental desenvolver software e/ouprodutos;

- SCRUM o caminho para detectar e causa raiz e a remoo de qualquer coisaque esteja impedindo o desenvolvimento e/ou entrega de software/produtos;

- SCRUM o caminho para maximizar a produtividade;

- SCRUM um forma para desenvolvimento de equipes e de indivduos

Veja Lei F. Brooks,No existe bala de prat



p

A ALMA do SCRUM:

artefatos

SprintBacklog

Produto

Planejamentoda Sprint

Reuniodiria

2-4 Semanas

24 horas

Revisoda Sprint

Retrospectivada Sprint

Viso

Cerimnias

Burndown

ProdutoBacklog

Product Owner (PO) ScrumMaster (SM) Equipe Scrum

Planejamento da Sprint Reunio Diria Reviso da Sprint

Retrospectiva da Sprint

Product Backlog Sprint Backlog Burndown (grfico)

Papis Cerimnias Artefatos

Legenda:



p

Planejar ou no Planejar ?

Planejamen

togil

Os 4 Nveis do Planejamento:

1 2 3 4 5 6

Plano de Release (do Produto)

Sprint #

Release #1 Release #2 Release #3

Tarefas

Verso 0.5 Verso 0.8 Verso 1.0

Sprint Burn Down

Reunio diria

Release Burn Down

Viso doPlanejamentoRelease #

Tempo



p

Desenvolvimento Iterativo e Incremental:

Devido a complexidade, tamanho,mudanas de requisitos, urgncia enecessidade de demonstrar valor maisrpido, fica quase inconcebveldesenvolver software utilizado o modelocascata, ou seja desenvolvertodo o software de uma nica vez.

Desenvolvimento Iterativo e incremental uma estratgia de planejamento (quesegue a linha dividir para conquistar ),onde o software construdo em partes,ou seja, em ciclos (iteraes), a cadaiterao feito um novo incremento (partedo software funcional) at completar o

software.

Incremental

Entrega 1 Entrega 2 Entrega 3

Iterativo



p

TimeBox e Sprint

O que Timebox ? um conceito diz que a quantidade de tempo (horasou dias) imutvel, ou seja, a quantidade de horasno poder aumentar. Assim, evita-se atraso no

prazo de entrega e facilita o planejamento.

Entretanto, quanto se erra a estimativa de tempo(leia-se: horas ou dias) de uma Sprint (leia-se:iterao), neste caso recomendvel reduzir oescopo da Sprint, desde que no afete a meta daSprint (isto discutido um mais a frente) ao invs deaumentar a quantidade de horas/dias.

Timebox = Um prazo ou tempo (dias/horas porexemplo) bem definido e imutvel.

O que uma Sprint ? uma iterao (que pode ser parte de uma release)que deve ser realizada de 2 a 4 semanas, no qual aequipe do projeto dever produzir um entregvel de

valor para o cliente (lembre-se que isto dosPrincpios do Manifesto gil).

A entrega de valor a meta da Sprint que deveresta bem definida e combinada com o cliente, antesdo comeo da execuo da Sprint.

O conceito de Timebox aplicado a Sprint.

O conceito de timebox aplicado as cerimnias (reunies) doScrum. Todas as reunies so Timeboxed:- Reunio de Planejamento da Sprint (8 horas)- Reunio Diria (15 minutos)- Reunio de Reviso da Sprint (4 horas*)- Reunio de Retrospectiva da Sprint (3 horas*)

Nota: * A quantidade de horas pode variar de acordo com a necessidade (por exemplo, apresentao do que serentregue ao cliente) ou aquilo que ser discutido/debatido, neste caso a Retrospectiva ela poder variar entre 1 a 3 hora



p

SCRUM: Papis e Responsabilidades:

Equipe SCRUM responsvel por:

- Fazer estimativa;- Definir as tarefas;- Desenvolver o produto;- Garantir a qualidade do produto;- Apresentar o produto ao clienteEquipe: auto-gerencivel e multifuncional

SCRUM Master responsvel por:

- Ser um lder (servidor);- Remover impedimentos;- Proteger a equipe;- Ajudar o PO (com Product Backlog);- Ser o facilitador da equipe;- Garantir as prticas SCRUM.

O SCRUM tem trs papis: Product Onwer (PO), SCRUM Master(SM) e a equipe SCRUM.



p

Responsabilidades do PO:

Principais responsabilidades PO:

Criar, Manter, Priorizaro Product Backlog

Representar a voz do cliente

Garantir o ROI

Criar, manter ecomunicar aviso do produto

Aceitar ou rejeitar entregas

Ajudar no entendimentodo qu deve ser feito.Definir metas e objetivodas Sprints.

(Reunio de Planejamen



p

Ferramentas do PO:

Principais responsabilidades PO:

Product Backlog

Release Burn down

Plano de Release



p

Caractersticas do PO:

Principais caractersticas desejveis e as indesejveis:

Desejveis (obrigatrias)

- Saber entender a necessidade do cliente e

usurios;

- Ter habilidade para criar, manter ecomunicar a viso do produto;

- Entender o que valor para o cliente;

- Ser Lder e Facilitador;

- Ter poder deciso sobre o projeto;

- Ser comprometimento com cliente, projetoe com a equipe;

- Manter um bom relacionamento comstakeholder

Indesejveis:

- Ser uma pessoa sem tempo;

- Ser adepto do micro-gerenciamento(comando controle);

- No conhecer o produto ou negcio;

- Falta de coragem para tomar decisosobre o projeto;

- Ser (ou agir como) o Dart Vader;

- Inabilidade tcnica:- Falta de conhecimento do SCRUM- Viso mal definida ou incompleta

- Product Backlog mal priorizado



p

A Equipe e Comprometimento e FCS:

Product Onwer

Equipe SCRUM Master

ComprometidosEnvolvidos

Stakeholders(clientes e usuriosfinais)

A equipe Scrum formado por pessoas comprometidas em realizar as tarefas

da Sprint Backlog. As pessoas da equipe devero possuir habilidades suficientespara desenvolver, testar, criar/desenhar interfaces grficas e etc, ou seja, tudoque que realmente preciso para entregar o software funcionando.

Fatores Crticos de Sucesso:

- A correta definio do tamanho da equipe muito importante, pois, o SCRUMrecomenda que equipe tenha de 6 a 9 pessoas. Entretanto, podemos ter equipemenores. Geralmente uma equipe muito grande no funciona bem devidoproblemas de integrao, relacionamento e outros conflitos que podem afetarde forma significativa o desempenho.

- Assim como tamanho correto da equipe, a escolha do PO e do SCRUMMasterso criticas, pois, eles so responsveis produto que ser entrega ao cliente epelo processo (prticas SCRUM). Devemos escolher a pessoa certa.



p

Cerimnias que o PO deve participar:

Reunio de Planejamento da Sprint (8 horas)

Reunio Diria (15 minutos)

Reviso da Sprint (4 horas*)

Retrospectiva da Sprint (3 horas*)

Participantes: PO, Equipe e SCRUM MASTER

Participantes: Equipe e SCRUM MASTER

Participantes: PO, Equipe e SCRUM MASTER

Participantes: Equipe e SCRUM MASTER

Nesta reunio somente membros da equipe devem

participar. A durao dela de 15 minutos. As pessoasfazem a reunio de p. O objetivo desta reunio fazerque as pessoas respondam 3 questes:- O que eu fiz ontem ?- O que vou fazer hoje ?- Encontrei algum impedimento ?

Esta reunio acontece no final da Sprint, opcionalmente outraspessoas podem ser convidadas (se necessrio).O objetivo da reunio apresentar o que a equipe fez durante aSprint e fazer a entrega do produto (software funcionando) para oPO. (Normalmente apresentado uma demo do software).Geralmente ela feita em um auditrio ou em uma sala de reunio

Esta reunio acontece logo aps a Reviso da Sprint.O objetivo dela avaliar o que deu certo e que deu erradodurante a Sprint, e fazer os ajustes possveis para a prximaSprint, ou seja, o ciclo de melhoria contnua.

Esta reunio primeira reunio, seu objetivo fazero planejamento da Sprint. Ela dividida em duas partes.Na

primeira parte o PO definir prioridade, seleo dos itens dobacklog e meta da Sprint.Na segunda parte a equipe definir a Sprint Backlog (que soas tarefas necessrias para cumprir a meta).

Nota: * A quantidade de horas pode variar de acordo com a necessidade (por exemplo, apresentao do que serentregue ao cliente) ou aquilo que ser discutido/debatido, neste caso a Retrospectiva ela poder variar entre 1 a 3 hora



p

Definido a Viso do Produto:

Viso do Produto:

Product Owner

Product Owner (PO), responsvel por definir, mantere comunicar a Viso do Produto para todos osstakeholders.

PO deve compartilhar e refinar a viso com a equipe.

Declarao do Elevador (Elevator Statement) uma tcnica queajuda o PO a escrever a Viso do Produto.

Tcnica: Declarao do Elevador (Elevator Statement)

Exemplo de Viso do Produto:Para empresas mdias de marketing e departamento de vendasque necessitam de um sistema de CRM, o EeaseCRM umsoftware baseado na web, intuitivo e fcil de usar que fornece apossibilidade fazer a rastreabilidade de vendas, gerao de leadse possibilita o estreitamento do relacionamento com o cliente.Diferente de outros servios ou produtos, nosso produto oferecea melhor relao custo beneficio.

For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category)

That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation)

A declarao de Viso do Produto deve ser simples, consistente,objetiva e fcil entendimento, que tem informaes sobre a

necessidade do cliente, o que produto esperado e quais sos osseus principais benefcios.A declarao ainda deve descrever a motivao e o diferencial doproduto em relao aos outros.



p

Definido a Viso do Produto:

Viso do Produto:

Product Owner

Product Owner (PO), pode utilizar fazer este exercciopara compartilhar a viso com a equipe.

Product Vision Box

Informaes sobre o produto:

- Nome do Produto:

- Logotipo ou desenho querepresente o produto

- Principais benefcos que ajuda avender o produto

- Principais caractersticas e/oufuncionalidades do produto

- Principais requisitos tcnicos

Product Vision Box uma tcnica que ajuda no entendimentoda Viso do Produto, pois, quando fazemos uma representaovisual do produto (embalagem, por exemplo) isto auxilia na reduodo nvel de abstrao.

Fonte:

Agile Project Management: Creating Innovative Products -Jim HighsmithCap. 5 - Practice: Product Vision Box and Elevator Test - Pg. 93



p

Elaborar o Plano de Release:

Plano de Release um viso do produto em relao a linha dotempo. Inicialmente este plano divido em releases, sendo que nofinal de cada release dever ser entregue um produto (softwarefuncionando) e na ltima release dever ser entregue o produto

completo com todas as funcionalidades. As releases so dividasem iteraes (Sprints)

Product Owner

Product Owner (PO), responsvel por criar, manter oPlano de Release

1 2 3 4 5 6


Sprint #



Sprint Burn Down

Release Burn Down


Tempo

Viso do Produto

Product Backlog

TaskBoard



p

Elaborar o Plano de Release:

Plano de Release um viso do produto em relao a linha dotempo. Inicialmente este plano divido em releases, sendo que nofinal de cada release dever ser entregue um produto (softwarefuncionando) e na ltima release dever ser entregue o produto

completo com todas as funcionalidades. As releases so dividasem iteraes (Sprints)

Product Owner

Product Owner (PO), responsvel por criar, manter oPlano de Release

1 2 3 4 5 6


Sprint #


TaskBoard


Sprint Burn Down

Release Burn Down


Tempo

Viso do Produto

Product Backlog



p

Criando: Product Backlog

O que Product Backlog ? uma lista contendo todas as funcionalidades desejadas para umproduto.O produto deve ter somente um Product Backlog (PB)

independente nmero de equipes que est trabalhando no projeto.PB poder ser criado de diversas maneiras:- Com Estrias de usurio- Com Casos de Uso- Com features (funcionalidades de produto)

Product Owner

Product Owner (PO), responsvel por elaborar e manterProduct Backlog atualizado, bem como priorizar seus itens.

Exemplo de Product Backlog: Sistema de Reserva On-Line

release



p

A priorizao do Product Backlog deve ser por tema (categoria), jque a priorizar por estria, nem sempre possvel, pois, poder existirgrau de dependncias entre estrias.Fatores de Priorizao:- Valor- Custo- Risco

Tcnicas:- Kano: Composta por entrevistas com os usurios e opinies deespecialistas.- Theme Screening: Composta por opinies de especialistas baseadas

em comparao realizadas com um tema importante.

Product Owner

Product Owner (PO), responsvel por priorizar seus

itens do Product Backlog

Exemplo de Product Backlog: Sistema de Reserva On-Line

Product Backlog. Priorizao:



p

Modelo Kano: um modelo desenvolvido por Noriaki Kano que usado paracompreender as preferncias do cliente (ou usurio).

O modelo Kano tem 3 tipos de funcionalidades:- Desejadas: So aquelas funcionalidades que o usurio deseja, masno tem plena certeza;

- Linear: Quantas mais destas tiver melhor

- Mandatrio: Deve estar presente para que o cliente esteja satisfeito.

Para saber qual o tipo de cada funcionalidade, podemos fazer oseguinte:- Fazer as perguntas direcionadas para um grupo de no mximo 20usurios com perfis diferentes;

- Realizar uma pergunta funcional:

Se na prxima release incluir a emisso da Ordem de Servio (OS),como voc se sentira?[ X ] Eu vou gostar[ ] Eu acho que deveria incluir[ ] Indiferente[ ] Posso tolerar[ ] Eu no gostaria disto

- Fazer uma pergunta disfuncional:Se na prxima release NO incluir a emisso da Ordem de Servio(OS), como voc se sentira?[ ] Eu vou gostar[ X ] Eu acho que deveria incluir[ ] Indiferente[ ] Posso tolerar

[ ] Eu no gostaria disto




p

Modelo Kano: Como Priorizar


Funcio

nal

Disfuncional

M MandatrioL LinearD DesejadoQ QuestionvelR ReversoI IndiferenteNo gostaria

indiferente

Gostaria

Posso tolerar

(acho ) deveria

Gostaria

(acho)

deveria

indiferente

Possotole

rar

Nogosta

ria

Q

R

R

R

R R R R

D D D

Mandatrio

Linear

Desejada

Indiferente

Reserva

Questionvel

Temas

Emisso de Ordem de Servio

Cadastro de Cliente

Cadastro de Produto

13 11 41 3 2

422 9 14 5 1 3

2120

1 06

Legenda:

O que incluir na Sprint ?

- Todas as funcionalidades Mandatrias- Algumas funcionalidades Lineares- Mas deixe um espao para as funcionalidades desejadas



p

Estimar Difcil ?

Agile Story points Ideal days

SeqencialLinhas de Cdigo Pontos de Funo

Story Points: Valores relativos Mais abstrato

Ideal Days Mais fcil para iniciantes Fcil de explicar

Estimativa (Mundo real) = Valor aproximado

Estimativa (TI) = Valor exato

Tamanho Durao



p

Ideal Days (Dias Ideais)

Baseado na durao de tarefas

- Dias ou horas unidade bem definida,contudo o tempo ideal quase nunca igual

ao tempo real...

- mais fcil de estimar, mas pode sertornar difcil de estimar se consideramostodas as interrupes e variaes

Baseia-se no tamanho da estria influenciadopela:- Nvel de dificuldade, complexidade e experincia( emprico);

Foco nas funcionalidades;O importante so os valores relativos;Pontos so medidas sem unidade;Equipe diferentes podem ter pontos diferentes paraestrias.

Story Points (Pontos)

Estimativa

Principais tcnicas: Opinio de especialista; Analogia; Decomposio (Dividir para conquistar).



p

3

Estria do Usurio (User Story):

O que uma estria (user story) ? uma pequena descrio, que detalha um itemdo Product Backlog.

Para que serve a Estria:

Uma estria ajuda no entendimento e tambm ,utilizada como lembrete e para as atividades deplanejamento. Ele tambm permite fazer a estimativade velocidade da equipe e a durao da Sprint.Geralmente a estimativa feita em pontos (storypoints) ou horas/dias (dias ideais).

Como escrever uma estria:

Conversaes sobre a estria, entre os usurios edesenvolvedores, de modo a detalhar o item eesclarecer todas as dvidas sobre o que deve ser feito.

Exemplos de Estrias do Usurio:

Titulo: Pagamento com Carto de Crdito Prioridade: 1-Alta

Por que ?Com objetivo de facilitar o pagamento das despesas dos clientes,

Quem ?

como um desenvolvedor

O que ?

devo implementar uma interface para pagamentos por carto de

crdito que seja intuitiva e fcil de usar.

Obs: Os carto aceitos so: Visa, Master e Amex.

Titulo: Exibir preo do produto Prioridade: 3-Baixa

Quando um cliente passar um produto pelo leitor do scanner e ocdigo de barra (cdigo do produto) for vlido o sistema deverbuscar o preo do produto e exibi-lo na tela do scanner

Seguindoum padro

Estilo livre

Pontos: 7

Pontos: 5



p

Escrevendo estrias:

INVEST significa:

Indepent (Independente): Mesmo sendo impossvel para alguns sistemas,

tenha em mente que uma User Story deve ser Independente

Negotiable (Negocivel): Uma User Story no um contrato. No umaespecificao detalhada. apenas uma introduo s funcionalidades paraque a equipe possa discutir e colaborar para esclarecer os detalhes prximoao momento de desenvolver a funcionalidade.

Valuable (Valiosa): Uma User Story deve ser valiosa para o cliente. Deve

ser escrita em linguagemde negcio. Deve ser descrio de uma funcionalidade, no uma tarefa.

Estimatable (Estimvel): User stories devem ser passveis de seremestimadas. Devem prover informao suficiente para serem estimadas, semserem muito detalhadas.

Small (Pequena): Nem pequena demais, nem grande demais. User Stories

devem ser do tamanho suficiente para entendimento do a funcionalidade;

Testable (Testvel): User Stories devem ser claras o suficiente para seremtestveis.

Kelly Waters tem escrito h muito tempo sobre User Stories, introduzindo oconceito deINVESTcomo uma definio clara sobre como trabalhar com esta ferramenta.Segundo ele uma boa estria deve ter seis atributos (INVEST*):



p

Estimativa* e o Planning Poker:

Geralmente o Planning Poker usa uma escala depontos, que pode ser baseada no Fibonacci:(1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala.Jogando o Planning Poker:Antes de comear o jogo, ou seja, definir os pontos paraas estrias, importante definir um valor dereferncia. Exemplo: Identificar a estria que pode seratribudo dois pontos, ento ela ser utilizada comoreferncia para pontuao das demais estrias.

Para fazer estimativa de velocidade da equipe ou de durao da Sprint, antes preciso o escrever as estrias do usurio.O Planning Poker a prtica que ajuda na estimativa de uma estria oude uma tarefa.

Pessoal, qualestimativa paraessa estria...

Product Owner Equipe

85

8

Equipe

8 5 ?

8 8

Na reunio de Planejamento da Sprint, a equipe joga o Planning Poker edefine a estimava de velocidade da equipe e a durao da Sprint.

Nota 1 Estimativa*Para fazer as estimativa, voc deve levar em considerao outros aspectos alm da codificao, como por exemplo: test

de aceitao, teste unitrios preparao do ambiente de teste e outras coisas que so necessrio e importantes (mesmoque de baixo valor) para que voc entregue o software funcionando.



p

Definio de Feito (DoD):

Definir claramente quando o produtoestar Feito:

Feito, para desenvolvedor:- Encerrou a codificao...

Feito, para Analista de Teste (Q&A):- Quando ele encerrou o teste e noencontrou nenhum bug...

Feito, para PO:- Quando foi entregue...

Feito, para os usurios finais e/ouclientes:- Quando o software comeou afuncionar em ambiente de produo...

Ao final de cada Sprint a equipe dever fazer uma entrega de valor para ocliente (PO e demais Stakeholders).Segundo Manifesto gil, valor para o cliente igual a Softwarefuncionando.Logo para fazer tal entrega, na reunio de Planejamento da Sprint, ser

imprescindvel definir a Definio de Feito.Isto evitar problemas e frustraes futuras nas reunies de Reviso eRetrospectiva da Sprint.

Evite: A sndrome dos 90% feito (pronto).

Na reunio de Planejamento da Sprint, o PO e a equipe devemdefinir a definio de pronto para Sprint



p

Artefato: Sprint Backlog

Dicas para montar um bom Sprint Backlog:

1 Toda a equipe deve participar da elaborao da Sprint Backlog;2 Faa uma definio de feito (DoD), veja o prximo slide;3Tente identificar todas as tarefas, lembre-se que algumas tarefas so puramente tcnicas, porexemplo: realizao de Teste Unitrio.

4 Respeite o tempo para realizao desta atividade, pois a Reunio de Planejamento um timebox.

O Sprint Backlog uma lista de tarefas que equipe se compromete a fazerem uma Sprint. A Sprint Backlog elaborada na segunda parte dareunio de Planejamento da Sprint.

Para atingir a meta da Sprint a equipe dever fazer as tarefas da Sprint

Backlog.

Tarefa:

Cadastrode Cliente

Incluir novocliente

alterarcliente

consultarcliente

Titulo: Precisamos registrar os dados dos clientes Prioridade: 1-Alta

Todos os dados do cliente dever ser registrado. A busca de clientedever ser fcil e intuitiva.

EstriadoUsurio:

Quando os clientes esto registrado, ser possvel alterar os dadosse necessrio.

O cliente dever ter um status para que se possa definir quaisso os clientes ativos e os inativos

Pontos: 8

Sprint Backlog

Selected Product Backlog (itens selecionados do Product Backlog)

tarefas



p

Quebrando estria em tarefas:

Na reunio de Planejamento da Sprint, a equipequebra as estrias em tarefas, o foco deve sernaquilo que precisa ser feito.

Cadastrode Cliente

Incluir novo

cliente

alterarcliente

consultarcliente

Fazer TestesUnitrios

Exemplos de tarefas necessrias concluir a Sprint, mas que no soprogramao:

- Preparar um ambiente de teste;- Realizar testes;- Esclarecimento de dvidas;- Discutir detalhes de como ser feito odeploy com a equipe de rollout;

- Escrever documentos de deploy (Requisio de Mudana);- Melhorar os scripts de build.

Para fazer as estimativa, voc deve levar em considerao outros aspectosalm da codificao, como por exemplo: testes de aceitao, testeunitrios, preparao do ambiente de teste e outras coisas que sonecessrio e importantes (mesmo que de baixo valor) para que vocentregue o software funcionando.

Sprint Backlo

tarefas



p

Artefato: Burndown

Pontos

Tempo (dias)

Exemplos de Sprint Burndown

O grfico Burndown a principalferramenta de gerenciamento doprocesso de desenvolvimento desoftware.

Sprint Burndown:

uma ferramenta para equipegerenciar trabalho restante versustempo, ou seja, ele permite visualizar oprogresso e/ou a evoluo do trabalhoexecutado pela a equipe, o trabalho e

tempo (pontos) que ainda faltam paracompletar a Sprint.Atualizao da Sprint Burndown diria, isto facilita a tomada de deciso,podemos decidir como melhorar aprodutividade da equipe e/ou paramitigar o risco da Sprint.

Release Burndown:

uma ferramenta para POgerenciar trabalho restante versustempo restante.PO acompanha o progresso do projetoatravs da entregas feitas (no final decada Sprint).PO deve comparar as entregas feitas como planejamento, Plano de Release e fazerajustar os necessrios para que o Planode Release seja seguido.

Exemplos de Release Burndown



pTask Board (Quadro de Tarefas) quadro que exibe o statusatual da Sprint.

Gesto Vista e Task Board

Burn DownEstrias Para Fazer Em Execuo Feitas (Prontas)

TaskBoard:O Taskboard (tambm chamada do Kanban) d visibilidade e comunica o o

progresso da Sprint.

uma sistema de gesto que uma forte ferramentade comunicao organizacional, pois transmite amensagem muitas vezes sem a necessidade depalavras, somente com a utilizao de smbolos e cores,de modo que todos conseguem receber a mensagem,muitas vezes de uma forma ldica.

A Gesto Vista tem como objetivo disponibilizar asinformaes necessrias de uma forma simples e de

fcil assimilao, buscando tornar mais fcil o trabalhodirio e tambm a busca pela melhoria da qualidade.

Ela torna possvel a divulgao de informaes paraum maior nmero de pessoas simultaneamente eajuda a estabelecer a prtica de compartilhamento doconhecimento como parte da cultura organizacional.

Gesto Vista: D visibilidade e transparncia ao projeto dedesenvolvimento de software.



p

Estudo de Caso

baseado em fatos reais



p

Viso do Produto: Sistema de Reserva On-Line

Viso do Produto:

Para Hotel que necessitam de um Sistema de Reserva On-Line,o ReservaOn um software baseado na web, intuitivo e fcil de usar que

fornece a possibilidade fazer a reserva de apartamentos, consulta dedisponibilidade de apartamentos e possibilita o estreitamento dorelacionamento com o cliente.Diferente de outros servios ou produtos, nosso produto oferece a melhorrelao custo beneficio.

Product Owner

PO responsvel por definir, manter e comunicar aViso do Produto. E por criar, manter e priorizar o

Product Backlog

Product Backlog: Sistema de Reserva On-Line



p


Nvel dePrioridade

Categoria Descrio do Item Backlog

2 Reserva Os clientes podero fazer reserva deapartamento

2 Reserva Os clientes podero cancelar a reserva

2 Reserva Os clientes podero fazer alteraes dedata da reserva

2 Reserva Os cliente podero fazer consulta de

reservas

3 Reserva Criao de o Book de Reserva

2 Pagamento O meio de pagamento da reserva sero porcarto de crdito

1 Apartament

o

Os apartamentos devero ser cadastros

1 Apartamento

Os apartamentos so classificados porcategoria

1 Cliente Precisamos registrar os dados dos clientes

Product Owner define os itens da Product Backlog e o nvelde prioridade de cada item.

Scrum Master pode ajudar o Product Owner na elaboraodo Product Backlog.



p

Plano de Release:

B

R P

Cliente

Produto

Apartamento

Reserva Pagamento

Book deReserva

Sprint #1

Sprint #2

Sprint #3

A C

R P

A C

Entrega 1

R P

Entrega 2

B B

Entrega 3

A C

PO (reforando) responsvel por criar, manter o Planode Release.Este Plano pode ser apresentado, compartilhado erefinado pela equipe

Sprint #3

Release #1

Release #2

Release #3

Te

mpo

Verso 0.5

Verso 0.8

Verso 1.0



p


Reunio de Planejamento da Sprint (1a. Parte):Participantes: PO, Equipe e SCRUM Master (facilitador)

Se for a primeira reunio o PO dever apresentar a viso

do produto, expectativa e prioridades.Nesta reunio, PO dever definir uma meta para Sprint e falarsobre quais so os itens so mais prioritrios do ProductBacklog.A equipe realizar o planejamento do que dever ser entregueno final da Sprint (de 2 a 4 semanas).

A equipe dever selecionar quais os itens sero feitos na

Sprint, resultando na Selected Product Backlog.

Nvel dePrioridade

Categoria Descrio do Item Backlog Estimativaem pontos

2 Reserva Os clientes podero fazer reserva deapartamento -

2 Reserva Os clientes podero cancelar a reserva -


-

2 Reserva Os cliente podero fazer consulta dereservas

-

3 Reserva Criao de o Book de Reserva -

2 Pagamento O meio de pagamento da reserva sero porcarto de crdito

-

1 Apartamento Os apartamentos devero ser cadastros -

1 Apartamento Os apartamentos so classificados porcategoria

-

1 Cliente Precisamos registrar os dados dos clientes -

Reunio de Planejamento da Sprint
http://egemsource.com/images/pic/main_column/check_mark.jpghttp://egemsource.com/images/pic/main_column/check_mark.jpghttp://egemsource.com/images/pic/main_column/check_mark.jpghttp://egemsource.com/images/pic/main_column/check_mark.jpg



p


Nvel dePrioridade

Categoria Descrio do Item Backlog Estimativaem pontos

2 Reserva Os clientes podero fazer reserva de

apartamento

-

2 Reserva Os clientes podero cancelar a reserva -


-

2 Reserva Os cliente podero fazer consulta dereservas

-

3 Reserva Criao de o Book de Reserva -2 Pagamento O meio de pagamento da reserva sero

por carto de crdito-

1 Apartamento Os apartamentos devero ser cadastros 8

1 Apartamento Os apartamentos so classificados porcategoria

2

1 Cliente Precisamos registrar os dados dos

clientes

13

Itens

selecionados

Continuao (da 1. parte da reunio)A equipe dever se preocupar em levantar mais detalhes dos itensselecionados do Selected Product Backlog , escrever estriaspodem ser uma tcnica til para melhorar entendimento dos itensselecionados (a).Para estimar a velocidade da equipe, que necessria paraimplementar os itens selecionados e durao da Sprint, serutilizadas as estrias para fazer as estimativas em pontos (ouhoras/dias) , atravs do Planning Poker. (b)

Reunio de Planejamento da Sprint: (2a. Parte)Participante: Equipe (e SCRUM Master - opcional)E por fim as estrias sero divididas em tarefas, gerando o SprintBacklog. (c)Decidindo que executar as Tarefas: Cada pessoa da equipe deve

escolher as tarefas da Sprint Backlog que deseja fazer.

Reunio de Planejamento da Sprint

Legenda:(a) pg: 31(b) pg: 31(c) pg: 32
http://egemsource.com/images/pic/main_column/check_mark.jpghttp://egemsource.com/images/pic/main_column/check_mark.jpghttp://egemsource.com/images/pic/main_column/check_mark.jpghttp://egemsource.com/images/pic/main_column/check_mark.jpg



p

Fazendo Estimativa com Planning Poker:

Product Owner

Equipe

138

13

Equipe

8?

13

Estria do Usurio:

Pessoal, qualestimativa paraessa estria...





Na reunio de Planejamento da Sprint, a equipe joga o Planning Pokere define a estimava de velocidade da equipe, necessria para

implementas as estrias (na verdade as tarefas)..

13

13



p

Tarefas, quebrando a Estria...

As estrias so divididas (quebradas) em tarefas.

As tarefas devem compor a Sprint Backlog...

Tarefa:

Cadastrode Cliente

Incluir novocliente

alterarcliente

consultarcliente



Estria do Usurio:



Pontos: 8

Sprint Backlog

Selected Product Backlog (itens selecionados do Product Backlog)



p

Check List do Planejamento da Sprint:

Primeira parte da reunio:1.1 A viso do produto foi completamenteentendida;1.2 Prioridade dos itens do Product Backlogdefinida;1.3 Os itens do backlog que sero feito na Sprintso escolhidos;1.4 A meta da Sprint (o que deve ser entregue nofinal da Sprint) foi estabelecida;1.5 A definio de pronto (DoD) foi estabelecidaformalmente.

Segunda parte da reunio:2.1 Os itens so detalhados atravs da escrita deestrias;2.2 Estimativa em Pontos estabelecida. (asestrias so utilizadas para fazer as estimadas2.3 - As estrias so quebradas em tarefas;2.4 - Sprint Backlog definido;2.5 As pessoas da equipe definem entre elas quemvai fazer as tarefas do Sprint Backlog.

Outros itens (fora da reunio do planejamento,mas necessrios para comear a Sprint):3.1- Preparar o Task Board quadro de tarefas(tambm chamado de quadro de Kanban)3.2 - Preparar o grfico Burndown3.3 - Fazer o Kick-off (Sprint #0)



p

Task Board: Sprint #1 - Dia 0:

Sprint Backlog* Em Execuo Concludo BurnDown

Cadastro deApartamentos

Cadastro deCategoria deApartamentos

Cadastro deClientes

Nota:Optamos por apresentar somente as atividades e no as tarefas, somente por questo de facilitar a apresentao.



p

Burndown. Sprint #1 - Dia 0:

Tempo

1 dia 2dia

3 dia

10

20

30

Pontos

Estimado

Real

23

Por que 3 dias ?

a primeira vez que a equipe utiliza o SCRUM para odesenvolver um software, logo ela no tem nenhum

histrico de desenvolvimento, que possa ser usado paradefinir a quantidade de tempo que ela levar para fazer 23pontos.

Contudo, a equipe, depois de muita discusso, chegou aoentendimento que seria preciso de 3 dias para fazer todasas tarefas do Sprint Backlog.



p

[Kick-off] Sprint #1 - Dia 0:

Cadastro deCategoria deApartamentosCadastro de

Clientes

Equipe

?

Sprint Backlog



Cadastro deClientes

SCRUM Master
http://egemsource.com/images/pic/main_column/check_mark.jpg



p

Sprint Backlog Em Execuo Concludo BurnDown



Cadastro deClientes

Task Board da Sprint #1: Dia 1 (aps o Kick-off):



p

Tempo

1 dia 2dia

3 dia

10

20

30

Pontos

Estimado

Real

23

Burndown da Sprint: #1 Final do Dia 1:

10 pontos

13



p

A Primeira Reunio Diria:

Equipe

Sprint Backlog

OK


Problemas noServidor deTeste

Check List Responder 3 questes:

O que foi feito ontem?O que voc planeja fazer hoje?Voc tem algum impedimento?

15minutos



Cadastro deClientes

SCRUM Master



p

Task Board da Sprint: #1 Aps primeira reunio




Problemas no

Servidor deTeste

Cadastro deClientes

SCRUM Masterdever resolver(remover) esteimpedimento



p

Task Board da Sprint: #1 Impedimento





Cadastro deClientes SCRUM Master

dever resolver(remover) esteimpedimento

Cabe ao SCRUM Master remover todos os impedimentos,identificados e demonstrados no Task Board (quadro de tarefas), paraque estes no afetem o desempenho da equipe. Caso contrrio, o

impedimento poder comprometer a meta e a entrega de valor que deveocorrer no final da Sprint.

SCRUM Master


Aps remoo do impedimento o SCRUM podemos registrarem base deconhecimento a causa raiz do impedimento, esta informao dever serutilizada para melhorar o processo, logo ser discutida na Retrospectivada Sprint.

O que um impedimento ?

Impedimento tudo aquilo que impede a equipe de realizarseu trabalho e atingir a meta da Sprint.Um impedimento pode ser um problema de rede, falhas noservidor, falta de servidor para testes, a lentido do bancode dados do ambiente de teste ou falta de informao

para implementao de uma tarefa.



p

Tempo

1 dia 2dia

3 dia

10

20

30

Pontos

Estimado

Real

23

Burndown da Sprint: #1 2. Dia:

10 pontos

13

8pontos

5



p

A Segunda Reunio Diria

Equipe

Sprint Backlog



Cadastro deClientes

OK


OK

OK

Cadastro deClientes

15minutos



SCRUM Master



p




Cadastro deClientes

Task Board da Sprint #1 - 2. Dia:



p

Tempo

1 dia 2dia

3 dia

10

20

30

Pontos

Estimado

Real

23

10 pontos

13

8pontos

5

5pontos

0

Burndown da Sprint #1 - 3. Dia



p

A Terceira Reunio Diria:

Equipe

Sprint Backlog



Cadastro de

Clientes

OK

OK

Cadastro deClientes

OK

OK

?

15minutos



SCRUM Master



p

Task Board da Sprint #1 - 3. Dia:




Cadastro deClientes



p

Reviso da Sprint:

Equipe apresenta que foi produzido e faz entrega para PO, que avalia ovalor da entrega. PO pode aceitar ou rejeitar a entrega do produto.

Reunio da Reviso da Sprint

Equipe

ProductOwner

SCRUM Master

4horas



p

Plano de Release:

B

R P

Cliente

Viso doProduto

Apartamento

Reserva Pagamento

Book deReserva

Sprint #1

Sprint #2

Sprint #3

A C

R P

A C

Entrega 1

R P

Entrega 2

B B

Entrega 3

A C

PO (reforando) pode ACEITAR ou REJEITAR a entrega.Se entrega aceita, o PO atualiza o Plano de Release eRelease Burn donw.Se a entrega rejeitada, as estrias (itens) devem voltarpara o Product Backlog

Sprint #3

Release #1

Release #2

Release #3

Te

mpo

Verso 0.5

Verso 0.8

Verso 1.0



p


Equipe discute o que deu errado e que deu certo... O que precisa sermelhorado para a prxima Sprint


impedimentos

Reunio Retrospectiva da Sprint

As retrospectivas so a essncia do conceito deInspeo e Adaptao.

Equipe

????

Velocidadeda equipe...

=

SCRUM Master

3horas



p


OK Pontos deAteno O Que DeveSer Melhorado



Cadastro deClientes


=

Planejamento:Prestar ateno na horado planejamento daSprint, para identificarse todos os recursosnecessrio estodisponveis

Impedimentos:

Atitude:

Para uma equipe (time)SCRUM funcionar sernecessrio mudana deatitude, caso contrrioisto poder afetaro desempenho da equipe

Velocidade daequipe

Ser necessriomais ateno nahora de estimaras estrias

Lies Aprendidas, o que deve melhorado para a prxima Sprint



p

SCRUM to SCRUM. Escalabilidade

Scrum Masters Scrum Masters

Equipes

Equipes

Product Onwers

Equipe de 7 2 pessoas:- Escalabilidade atravs de equipes de equipesFatores de escala:

- Tipo de aplicao- Tamanho da equipe- Disperso da equipe- Durao do projetoScrum usado em projetos envolvendo mais de 500 pessoas



p

Mini-Vocabulrio

Sprint = iterao

Product Backlog = Lista de requisitos funcionaisde um produto (com o nvel de prioridade definido)

Product Owner = Analista de Negcio ou Especialista de Negcio

SCRUM Master = Lder servidor, se papel muito prximo de tcnico defutebol ele trabalha para que a equipe produza resultado, mas no entraem campo para jogar.

Task board = Quadro de tarefas

Impedimento = tudo aquilo que pode impedir a equipe derealizar seu trabalho, seja falta de informao ou falta de recursos de infra-estrutura.

Execuo das prticas do SCRUM = muito parecido com o velho einfalvel PDCA.

Timebox = tempo (horas/ias) bem definido e imutvel, sonho de todo

gestor de projeto.Burndown = um grfico que ele representa o trabalho restante sobretempo

Equipe SCRUM = Equipe engajada, auto-gesto

e multifuncional (pig dream team).



p

Referncias

Agile Project Management with ScrumKen Schwaber

The Enterprise and Scrum

Ken SchwaberAgile Retrospectives: Making Good Teams Great -Esther Derby, Diana Larsen e Ken Schwaber

Jeff Suttherland:http://jeffsutherland.com

Ken Schwaber:http://www.controlchaos.com

Mike Cohn:www.mountaingoatsoftware.com/

Agile Project Management: Creating Innovative ProductsJim HighsmithCap. 5 - Practice: Product Vision Box and Elevator Test - Pg. 93

Succeeding with Agile: Software Development using ScrumMike Cohn

Agile Estimating and PlanningMike Cohn

Agile Software Development Book: User Stories Applied: For AgileSoftware Development

Mike Cohn
http://jeffsutherland.com/http://www.controlchaos.com/http://www.mountaingoatsoftware.com/http://www.mountaingoatsoftware.com/http://www.mountaingoatsoftware.com/http://www.controlchaos.com/http://www.controlchaos.com/http://jeffsutherland.com/http://jeffsutherland.com/http://jeffsutherland.com/



p

Quer Mais

http://etecnologia.ning.com/

Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema enovas verses deste material...Envie um e-mail para com subject: Quero entrar na comunidade [email protected] que te enviaremos um convite para participada nossa comunidade



p

Nossos Servios de Consultoria:

Servios de Consultoria:

- Implementao de Fbrica de Software gil

- Implementao de SCRUM

- Agile Coach

- Avaliao de Maturidade do processo de desenvolvimento desoftware (Mps.br e CMMI) para Fbricas geis

- Desenvolvimento de software para dispositivos mveis (Celulares)

SustentabilidadeAmbiental

Gesto deInovao

ProcessosAgile

TeamProjectAgileGesto de Projetos geis

Ferramenta de apoio a Projeto geis, ela temsuporte integral ao SCRUM e aos recursos daWeb 2.0.

Ferramenta:



p

Cursos e Formao Profissional:

- Workshop SCRUM (8 horas)

- Workshop SCRUM Product Owner (8 horas)- Gerenciamento de Projetos geis com SCRUM (16 horas)

- Formao Engenharia de Software gil (36 horas)

Nossos Treinamentos:

Ficou interessado ?Entre em contato: Rildo Santos, email: [email protected].

Estes treinamentos tambm podem ser personalizados para sua empresa.



p

Notas:

Marcas Registradas:

Todos os termos mencionados e reconhecidos como MarcaRegistrada e/ou comercial so de responsabilidade de seus

proprietrios. O autor informa no estar associada a nenhum produtoe/ou fornecedor apresentado neste material. No decorrer deste,imagens, nomes de produtos e fabricantes podem ter sido utilizados,e desde j o autor informa que o uso apenas ilustrativo e/oueducativo, no visando ao lucro, favorecimento ou desmerecimentodo produto/fabricante.

Melhoria e Reviso:

Este material esta em processo constante de reviso e melhoria, sevoc encontrou algum problema ou erro envie um e-mail ns.

Criticas e Sugestes:

Ns estamos abertos para receber criticas e sugestes que possammelhorar o material, por favor envie um e-mail para ns.

Rildo F dos Santos ([email protected])

Imagens:

Google, Flickr e Banco de Imagem.



p

Licena:


77/77

p

Workshop

SCRUM Product Owner

scrum product owner v3

Documents