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

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

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

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

4. ROI não é apenas retorno em dinheiro

5. ROI também é:
SaOsfação do cliente
Audiência
Fidelidade
Menos mudanças

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

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

8. Quem é o Analista de Negócios?

9. Problema ( AN ) Solução

10. Problema ( AN ) Solução

11. Problema ( AN ) Produto

12. Problema ( AN ) SoWware

13. Problema ( AN ) Site

14. Problema ( AN ) Projeto

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

16. Levantando requisitos?

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

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

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

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

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

22. Conhecer o cliente e o usuário.

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

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

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

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

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

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

29. Scrum
Product Backlog
Users stories
Simplicidade

30. O Product Backlog é a
lista de requisitos priorizada

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

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. No Scrum o Analista de Negócios assume o
papel de Product Owner

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

35. Resumo do processo

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

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. Product Owner
É a voz do cliente dentro de projeto

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

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

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

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

43. Product Owner
Cria um plano de entregas

44. Product Owner
Gera visibilidade do projeto
ao cliente e aos usuários

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

46. Product Owner
ParOcipa do processo e
das reuniões do Scrum

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

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. CaracterísOcas desejadas em um
Product Owner

50. Habilidade para se comunicar
com diferentes públicos

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

52. Entender as necessidades do cliente

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

54. Ser compromeOdo com o projeto
e com o Ome

55. Ter visão das oportunidades
do negócio

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

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

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

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

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. “Há uma forte relação entre um Product
Owner com poder e bem treinado e
um projeto Scrum de sucesso.”
Alexandre Magno, CST

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

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