Palestra EDTED: Análise de Negócios e Scrum

1,920 views
1,884 views

Published on

Palestra do EDTED Floripa sobre Análise de Negócios, Scrum e em especial sobre o papel do Product Owner.

Published in: Technology
1 Comment
9 Likes
Statistics
Notes
No Downloads
Views
Total views
1,920
On SlideShare
0
From Embeds
0
Number of Embeds
272
Actions
Shares
0
Downloads
0
Comments
1
Likes
9
Embeds 0
No embeds

No notes for slide

Palestra EDTED: Análise de Negócios e Scrum

  1. 1. Análise
de
Negócios
e
Scrum
 Guilherme
Tossulino
 EDTED
Floripa
 Maio/2009

  2. 2. O
que
é
Análise
de
Negócios?

  3. 3. Olho
e
foco
no
problema
 
sem
esquecer
do
ROI*
e
do
cliente.
 *
ROI
–
Return
of
Investment

  4. 4. ROI
não
é
apenas
retorno
em
dinheiro

  5. 5. ROI
também
é:

 SaOsfação
do
cliente
 Audiência
 Fidelidade
 Menos
mudanças

  6. 6. Entender
o
problema
para
enxergar
a
 solução.

  7. 7. Para
entender
o
problema
é
preciso
 conhecer
o
negócio.

  8. 8. Quem
é
o
Analista
de
Negócios?

  9. 9. Problema
(
AN
)
Solução

  10. 10. Problema
(
AN
)
Solução

  11. 11. Problema
(
AN
)
Produto

  12. 12. Problema
(
AN
)
SoWware

  13. 13. Problema
(
AN
)
Site

  14. 14. Problema
(
AN
)
Projeto

  15. 15. Como
o
AN
procura
a
solução?

  16. 16. Levantando
requisitos?

  17. 17. Uso
de
funcionalidades
solicitadas
 7%
 13%
 Nunca
 Raramente
 45%
 Algumas
vezes
 Frequentemente
 16%
 Sempre
 19%
 Fonte:
Standish
Group

  18. 18. Uso
de
funcionalidades
solicitadas
 Nunca
 46%
 Raramente
 45%
 Algumas
vezes
 Frequentemente
 Sempre
 19%
 64%
são
desperdício
 Fonte:
Standish
Group

  19. 19. Uso
de
funcionalidades
solicitadas
 7%
 13%
 Nunca
 Raramente
 Algumas
vezes
 Frequentemente
 Sempre
 80%
 Apenas
20%
são
realmente
uOlizadas
 Fonte:
Standish
Group

  20. 20. DESAFIO:
Descobrir
os
20%
que
 realmente
geram
valor
para
o
produto

  21. 21. É
preciso
conhecer
a
estratégia
e
a
 essência
do
negócio.

  22. 22. Conhecer
o
cliente
e
o
usuário.

  23. 23. Perguntar
 }
O
NEGÓCIO
 Entender
 Estudar
 Ler
 Respirar

  24. 24. Visão,
missão,
valores
e
 estratégias
dão
rumo
desenvolvimento
 do
produto.

  25. 25. Mas
o
que
Análise
de
Negócios
tem
 a
ver
com
SCRUM?

  26. 26. Análise
de
Negócios
 ObjeOvos
visam
resolver
o
problema
com
o
 olho
de
ROI.

  27. 27. Scrum
 ObjeOvos
visam
resolver
o
problema
com
o
 máximo
de
ROI
da
maneira
mais
 simples
possível.


  28. 28. Análise
de
Negócios
 Engenharia
de
Requisitos
 Mapeamento
de
processos
 Documentos
 Detalhes

  29. 29. Scrum
 Product
Backlog
 Users
stories
 Simplicidade

  30. 30. O
Product
Backlog
é
a
 lista
de
requisitos
priorizada

  31. 31. Os
requisitos
geralmente
são
demonstrados
 através
de
user
stories.

  32. 32. Template
para
user
stories
 Como
<PERFIL>
eu
 desejo/quero/devo
<FUNCIONALIDADE>
 porque
<VALOR
DE
NEGÓCIO>
 No
verso
vão
os
critérios
de
aceitação

  33. 33. No
Scrum
o
Analista
de
Negócios
assume
o
 papel
de
Product
Owner

  34. 34. Papéis
do
Scrum
 Scrum
 Analista
de
 Time
 Master
 Negócios
 Product
 Owner

  35. 35. Resumo
do
processo

  36. 36. Scrum
Master
 1.  Ajuda
o
Product
Owner
 2.  Protege
o
Time
 3.  Garante
a
aplicação
do
processo
do
Scrum

  37. 37. Time
 1.  EsOma
as
tarefas
da
sprint
(iteração)
 2.  Se
auto‐gerencia
e
organiza
 3.  Produz
o
que
o
Product
Owner
espera

  38. 38. Product
Owner
 É
a
voz
do
cliente
dentro
de
projeto

  39. 39. Product
Owner
 Define
as
funcionalidades
chave
 
(20%
+
uOlizadas)
do
produto


  40. 40. Product
Owner
 Cria,
dissemina,
relembra
e
trabalha
 a
visão
de
um
projeto

  41. 41. Product
Owner
 Escreve,
prioriza
e
re‐prioriza
 o
Product
Backlog,
não
esquecendo
 do
ROI
e
dos
20%.

  42. 42. Priorizando
 1
–
Maior
valor
 2
–
Menor
custo
 3
–
Novo
conhecimento
 4
–
Maior
Risco

  43. 43. Product
Owner
 Cria
um
plano
de
entregas


  44. 44. Product
Owner
 Gera
visibilidade
do
projeto

 ao
cliente
e
aos
usuários

  45. 45. Product
Owner
 Define
as
metas
do
projeto
 
e
de
cada
iteração

  46. 46. Product
Owner
 ParOcipa
do
processo
e

 das
reuniões
do
Scrum

  47. 47. Product
Owner
 Aceita
ou
não
o
que
o
Time
 entrega
no
fim
de
cada
sprint

  48. 48. “O
Product
Owner
obtém
o
financiamento
no
início
e
 durante
o
projeto,
criando
os
principais
requisitos
 iniciais,
os
objeOvos
de
retorno
sobre
invesOmento
 (ROI)
e
o
planejamento
dos
entregas
(releases).”

 ‐
Ken
Schwaber

  49. 49. CaracterísOcas
desejadas
em
um

 Product
Owner

  50. 50. Habilidade
para
se
comunicar
 
com
diferentes
públicos

  51. 51. Ter
espírito
de
liderança
e
ser
 
um
facilitador
do
projeto

  52. 52. Entender
as
necessidades
do
cliente

  53. 53. Tomar
decisões
e
saber
 
a
hora
de
dizer
NÃO

  54. 54. Ser
compromeOdo
com
o
projeto
 e
com
o
Ome

  55. 55. Ter
visão
das
oportunidades

 do
negócio

  56. 56. Time,
Scrum
Master
e
Product
Owner
 formam
uma
equipe
interdependente

  57. 57. NÃO
funciona:
 Product
Owner
sem
poder
de
decisão
 Product
Owner
com
baixa
disponibilidade
 Product
Owner
despreparado

  58. 58. NÃO
funciona:
 Projeto
sem
visão
 Projeto
sem
plano
de
entregas
 Projeto
sem
product
backlog
priorizado

  59. 59. Product
Backlog
MAL
manOdo:
 Problemas
nas
esOmaOvas
 Problemas
na
priorização
e
no
ROI
 Problemas
na
visibilidade
do
projeto

  60. 60. Resumindo
 A0vidade
 Responsável
 Gerenciar
a
Visão
 Product
Owner
 Gerenciar
o
ROI
 Product
Owner
 Gerenciar
a
Sprint
de
desenvolvimento
 Time
 Gerenciar
o
processo
 Scrum
Master
 Gerenciar
a
entrega
 Product
Owner

  61. 61. “Há
uma
forte
relação
entre
um
Product
 Owner
com
poder
e
bem
treinado
e
 um
projeto
Scrum
de
sucesso.”
 Alexandre
Magno,
CST

  62. 62. O
que
é
melhor?
 PO
técnico
ou
não
técnico?
 PO
do
fornecedor
ou
PO
do
cliente?

  63. 63. OBRIGADO!
 guilherme@tossulino.com
 Guilherme
Tossulino
 www.tossulino.com
 www.iea.org.br
 www.twi|er.com/tossulino


×