O documento discute o desenvolvimento ágil de software, destacando a filosofia do Manifesto Ágil e o uso do método Scrum para gerenciar projetos de forma flexível e colaborativa. Ele aborda as responsabilidades do Product Owner, a definição de uma visão de produto e a importância de um backlog bem organizado para atender às necessidades dos clientes. A descrição das práticas de Scrum enfatiza a criação de valor rapidamente e a adaptação às mudanças de requisitos durante o processo de desenvolvimento.

1. Workshop Desenvolvimento Ágil
O que podemos aprender com Scrum
nov/2012

2. Projetos Falham!

3. PROJETO DE SOFTWARE
• A experiência de décadas seguindo pesadas práticas prescritivas tornou evidente que:
• Os detalhes são complexos para as pessoas
• Os clientes ou usuários não tem certeza do que eles querem
• Eles tem dificuldade de expressar tudo que querem e sentem
• Muitos detalhes do que eles querem só serão revelados durante o desenvolvimento
• Na medida em que elas vêem o produto ser construído, elas mudam de ideia
• Forças externas (como um produto ou serviço da concorrência) trazem mudanças ou melhorias nos requisitos.
Fonte: Agile and Iterative Development: A Manager’s Guide - Craig Larman

4. Cascata X Ágil

5. O MANIFESTO ÁGIL
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo.
Através deste trabalho, passamos a valorizar:
1. Indivíduos e interação entre eles mais que processos e ferramentas
2. Software em funcionamento mais que documentação abrangente
3. Colaboração com o cliente mais que negociação de contratos
4. Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
http://agilemanifesto.org/

6. O QUE É SCRUM?
Scrum é um método ágil para gerenciamento de projetos baseado em times pequenos e auto-organizados; forte
visibilidade; e rápida adptação. Jeff Sutherland e Ken Schwaber desenvolveram algumas das práticas originais do Scrum na
Easel em 1994, no entanto suas características tem sido utilizadas em diversos projetos desde 1990. Após isto, Scrum foi
formalizado e apresentado oficialmente na OOPLSA’96 (Object-Oriented Programming, Systems, Languages, and
Applications). Desde então, Sutherland, Schwaber e outros tem estendido e aplicado Scrum em diversas organizações por
todo o mundo, principalmente de TI (Tecnologia da Informação) AdaptWorks

7. O QUE É O SCRUM?
• Processo iterativo e incremental para desenvolvimento de qualquer produto e
gerenciamento de qualquer trabalho.
• Provê agilidade para responder rapidamente às mudanças de requisitos.
• Processo ágil com foco na entrega de valor para o negócio no menor tempo.
• Não tem nada a ver com engenharia.
• É um framework

9. FRAMEWORK
Ferramentas
Papéis Reuniões Product Backlog
Sprint Planning Sprint Backlog
Product Owner
Sprint Review Roadmap
Scrum Master
Sprint Retrospective Burndown Charts
Time de Desenvolvimento
Daily Scrum meeting Elevator Statement
Product Vision Box

10. PRODUCT OWNER
“O Product Owner lidera o esforço de desenvolvimento para criar um produto
que gere os benefícios desejados. Isto frequentemente inclui criar a visão do
produto; refinar o Product Backlog; planejar Releases; envolver os clientes, usuários
e outros stakeholders; gerenciar o budget; preparar o lançamento do produto;
participar das reuniões do Scrum; e colaborar com o time.”
Roman Pichler em “Agile Product Management with Scrum”

11. As responsabilidades
do Product Owner

12. Ser a Voz do cliente

13. Definir as funcionalidades
essenciais do produto

14. Descrever, priorizar e refinar
requisitos continuamente

15. Ser responsável pelo sucesso
do produto e pelo ROI...
ou pelo seu fracasso

16. Definir datas de Releases;
criar e atualizar Plano de Releases
e reports

17. Gerenciar de forma pró-ativa
stakeholders e chickens

19. Definir metas

20. Dar direcionamento ao trabalho

21. Responder diariamente às
questões relacionadas ao projeto

22. Participar das reuniões do Scrum

23. Gerenciar o budget

24. Aceitar ou rejeitar entregas

25. CARACTERÍSTICAS DESEJADAS
• Entender necessidades do cliente
• Tomar decisões e saber quando dizer não
• Ter habilidade para comunicar a visão do produto
• Entender o valor do processo criativo
• Líder / Facilitador
• Possuir bom relacionamento com stakeholders

26. Definir a visão do produto

27. VISÃO DO PRODUTO
UMA VISÃO É UMA CLARA IMAGEM QUE GERA UMA ATRAÇÃO EMOCIONAL ENTRE PESSOAS E PRODUTO
• O Product Owner é o responsável pela criação da Visão
• Ele compartilha essa visão com o time
• Ele refina essa visão com o time

28. VISÃO DO PRODUTO
UMA VISÃO EFETIVA DEVE RESPONDER ÀS SEGUINTES PERGUNTAS:
• Quem irá comprar este produto? Quem é o cliente alvo?
Quem irá usar o produto? Quem são os usuários alvo?
• Quais “dores do cliente (ou usuários) o produto pretende aliviar? Qual valor o produto adicionará?”
• Quais atributos o produto precisa possuir para aliviar estas “dores” e quais garantirão o sucesso do produto?
• Como o produto pode ser comparado a produtos ou alternativas existentes? Quais são os pontos diferenciais deste
produto?
• (se aplicável) Qual será o preço alvo do produto? Como a empresa pretende ganhar dinheiro com este produto? Quais
serão as fontes de faturamento e qual seu modelo de negócios?

29. Uma boa visão de produto permanece
relativamente constante, ao passo que o
caminho para implementação da
visão é frequentemente adaptado.

30. Vamos praticar?

31. Elevator Satement
Para cliente / público-alvo que necessidade do cliente / público ou
oportunidade, o nome do produto é um categoria do produto que
principal benefício ou razão para comprar o produto.
Diferentemente do principal competidor ou alternativa nosso
produto principal diferenciação.

32. Product Vision Box
. Nome do Produto
. Gráficos (Logo, Símbolo, etc)
. Três ou quatro pontos chave para “vender” o
produto
. Principais features no verso
. Principais requisitos operacionais

33. Roadmap

34. Roadmap é uma linha do Tempo, onde podemos
visualizar graficamente todos os passos que serão necessários,
desde o ponto em que estamos, até alcançar o objetivo
desejado.
Ele pode ser simples, representado apenas por uma linha, ou mais complexo,
representado como um fluxograma detalhado de cada passo apresentado.
Remember the future
fonte: http://coachingsp.wordpress.com

35. Product Backlog

36. PRODUCT BACKLOG
• Lista de funcionalidades, necessidades, desejos, ...
Emergentes, priorizados e estimados
• Uma única lista para múltiplos times
• Product Owner é o responsável por sua priorização
• Todos podem contribuir
• Mantido e postado visivelmente
• Derivado de uma visão de produto
• Pode ser escrito no formato de sua preferência: user stories, use cases, features...

37. User Stories

38. Como um <PERFIL> eu posso/gostaria/devo Quem?
<FUNCTION> para <VALOR AO
NEGÓCIO>
O que?
Como um CSPO eu devo REVISAR
OS CONCEITOS DE SCRUM para
FACILITAR O APRENDIZADO DE
TÓPICOS AVANÇADOS
Por que?

39. Como o propósito de <VALOR AO
NEGÓCIO>, como um <PERFIL> , eu posso/
gostaria/devo <FUNCTION>
Por que?
Como o propósito de FACILITAR O Quem?
APRENDIZADO DE TÓPICOS
AVANÇADOS, como um CSPO eu
devo REVISAR OS CONCEITOS DE
SCRUM
O que?

40. Story-Writing Workshop

41. OBRIGADO!
Contato:
ricardo@sthouse.com.br
55 11 984.443.334
http://br.linkedin.com/in/ricardoinfante
http://www.startuphouse.com.br/