O documento fornece uma introdução sobre Scrum e gestão de produtos, resumindo:
1) Os papéis, eventos e artefatos de Scrum como Product Owner, Time de Desenvolvimento e Scrum Master, Sprints, Product Backlog e Sprint Backlog;
2) Conceitos como Minimum Viable Product (MVP), métricas, user stories e técnicas de priorização para gestão de produtos;
3) As responsabilidades do Product Owner em definir o escopo, priorizar o backlog e aceitar as entregas.
3. Quem veio antes, o Scrum ou o Ágil?
• 1986 – “The New Product Develpment
Game” - Hirotaka Takeuchi e Ikujiro Nonaka.
• 1993 – Easel Corporation - Jeff Sutherland,
John Scumniotales e Jeff McKenna.
• 1995 – Formalização a definição do Scrum -
Ken Schwaber.
• 2001 – Manifesto ágil - Kent Beck, Mike Beedle, Arie van Bennekum,
Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning,
Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert
C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas.
5. Pilares do Scrum
Transparência:
Exposição clara e direta do dia a dia ao time e aos responsáveis pelos
resultados.
Inspeção e Adaptação:
Ajuste do que está sendo produzido, caso esteja se desviando e
tornando o resultado inaceitável.
6. Valores do Scrum
• Comprometimento com os objetivos do Time.
• Coragem para fazer a coisa certa e trabalhar em problemas difíceis.
• Foco no trabalho da Sprint e nos objetivos do Time.
• Transparência de todo o trabalho e desafios com da execução.
• Respeito com os outros membros do Time.
8. O Scrum não é
• Um processo ou uma técnica para construir produtos.
• Uma metodologia de Gestão de Projetos.
• Qualquer implementação de apenas parte(s) do Scrum.
• Qualquer implementação sem algum componente do Scrum.
• Qualquer implementação com alterações nos papéis, artefatos,
eventos ou regras do Scrum.
9. O Scrum é
• Um framework para tratar de problemas complexos e adaptativos.
• Um container para outras técnicas, metodologias e práticas.
• Leve e simples de entender, mas extremamente difícil de dominar.
• Para ajudar times a entregarem produtos com o mais alto valor
possível de maneira produtiva e criativa.
• Baseado no Empirismo.
• Interativo e Incremental.
15. Papeis do Scrum
Product Owner
• O Product Owner define e ajusta
as features do produto, decide
quando serão disponibilizadas ao
usuário, prioriza o backlog e
aceita ou rejeita as entregas do
time.
• Como isso é feito, pode variar de
empresa para empresa e até
mesmo de time para time.
16. Papeis do Scrum
Scrum Master
• O Scrum Master é responsável por
garantir que o Scrum seja
entendido e aplicado.
• O Scrum Master trabalha para
garantir que o Time Scrum esteja
aderente à teoria, práticas e
regras do Scrum e ajuda o P.O. a
trabalhar com o time.
17. Papeis do Scrum
Dev Team
• As pessoas que trabalham para
entregar uma versão usável que
potencialmente incrementa o
produto “Pronto” ao final de cada
Sprint.
• Somente integrantes do Time de
Desenvolvimento criam
incrementos.
18. Papeis do Scrum
Scrum Team
• O Time Scrum é composto pelo
Product Owner, o Time de
Desenvolvimento e o Scrum
Master.
20. Anatomia do Scrum - foco no Product Owner
O Framework tem componentes com propósitos específicos. Reconhecê-los
e utilizá-los adequadamente é essencial para o sucesso.
• 3 Papeis: Product Ownet, Scrum Master e Time.
• 4 Eventos: Sprint Planning, Daily, Sprint Review e Retrospective.
• 3 Artefatos: Product Backlog, Sprint Backlog e as Entregas.
• Os artefatos do Scrum representam o trabalho ou o valor a ser entregue e fornecem
a transparência, para as oportunidades de inspeção e adaptação.
22. O Sprint
• As Sprints são compostas por uma reunião Planning, Dailies, o
trabalho de desenvolvimento, uma Review e uma Retrospectiva da
Sprint – é onde “acontece todo o Scrum”.
• No final, cada Sprint tem que ter entregas de funcionalidades
potencialmente utilizáveis e aderentes à definição de DONE do Time.
• O Product Owner escolhe se libera ou não a entrega imediatamente
aos usuários no final de cada Sprint.
23. Durante o Sprint
• Não são feitas mudanças que possam comprometer a entrega de
valor comprometida para aquele time frame.
• As metas de qualidade não diminuem.
• O escopo pode ser clarificado e até renegociado entre o Product
Owner e o Time de Desenvolvimento, quanto mais for aprendido
sobre o que se está construindo.
24. O Product Backlog
• É uma lista ordenada de tudo que deve ser necessário no produto.
• É uma origem única de requisitos para qualquer mudança a ser feita
no produto.
• O Product Owner é responsável pelo Backlog do Produto, incluindo
seu conteúdo, disponibilidade e priorização.
25. O Product Backlog Item (PBI)
• É um item qualquer do Product Backlog.
• Pode ser uma Funcionalidade, um Bug, Épico ou qualquer outra coisa
que o produto precise ter.
26. Sprint Planning
• Onde o Product Owner apresenta e clarifica os itens com o time.
• Participa o Time todo e pode ter stakeholders convidados pelo P.O.
• Define o plano de trabalho para o próximo time-frame.
• Tem um time box.
• O Scrum Master é o facilitador da reunião.
• Os inputs para essa reunião
• o Product Backlog já priorizado.
• a última entrega do time.
• a capacidade do time projetada para o Sprint que está começando.
• a performance passada do time.
27. Planning dividido em “1” e “2”
• A divisão do Planning em duas partes é recomendada como boas práticas.
• No planning 1 o foco é no que será feito. O time e o P.O. contribuem no
esclarecimento do requisito de negócio e técnico, o suficiente para que
seja dada uma estimativa do Dev Team sobre o esforço para conclusão da
entrega. Participam todos, Scrum Team e Stakeholders convidados.
• No planning 2 o foco é no como será feito e acontece a quebra das
atividades em tarefas (tasks) necessárias, para acontecer a entrega.
Participam essencialmente o Dev Team e o Scrum Master.
28. O Sprint Backlog
• O Sprint Backlog é um conjunto de
itens do Product Backlog
selecionados para a Sprint,
juntamente com o plano para
entregar o incremento do produto
e atingir o objetivo do Sprint.
29. O Daily
• Time-box de 15 minutos.
• Criar um plano para as próximas 24 horas.
• Inspecionar o trabalho desde o último Daily.
• Prever o trabalho que deverá ser feito antes do próximo Daily.
• Perguntas para ajudar a direcionar o evento:
• O que eu fiz ontem que ajudou o Dev Team a cumprir o compromisso?
• O que eu farei hoje para ajudar o o Dev Team a cumprir o compromisso?
• Vejo algo que impeça a mim ou o Dev Team de cumprir o compromisso?
30. As Entregas
• A entrega é a soma de todos os itens do Backlog do Produto
completados durante o Sprint e o valor dos incrementos de todos os
Sprints anteriores.
• Deve estar na condição utilizável, independente do Product Owner
decidir por liberá-lo realmente e atender a definição de “Pronto” do
Time Scrum.
31. A Sprint Review
• A Review é executada no final do Sprint, para inspecionar as entregas
e adaptar o Backlog do Produto se necessário.
• Participam o Time Scrum e os Stakeholders chaves convidados pelo
Product Owner.
• O Dev Team demonstra o trabalho Done e responde questões sobre.
• O Product Owner esclarece quais itens do Sprint Backlog
apresentados estão aceitáveis.
32. Retrospective
O propósito da Retrospectiva do Sprint é:
• Inspecionar como o último Sprint foi em relação às pessoas,
relacionamentos, processos e ferramentas.
• Identificar e ordenar os principais itens que foram bem e as
potenciais melhorias.
• Planejar para implementar as melhorias no trabalho do Scrum Team.
• Adaptar a definição de “Pronto” quando necessário, buscando
aumentar a qualidade da entrega.
34. Definition of Done (DoD) - Pronto
• Todos devem entender o que o significa o DONE.
• Varia de Time para Time.
• Com um Time mais maduro, é esperado que a definição de DONE seja
expandida para incluir mais critérios sobre a qualidade da entrega.
37. O que é um Produto?
Segundo Philip Kotler,
“valor é o que o cliente
recebe em troca daquilo
que dá. Alguns
consumidores consideram
todos os benefícios que
recebem assim como todos
os componentes de
sacrifício (dinheiro, tempo,
esforço)”.
38. Visão do Produto
• Breve descrição de para onde você quer levar sua ideia de produto.
• Pode ser criada usando Stakeholders, Time ou consultoria.
Elevator Statement:
Para <público alvo>
Que tem dificuldade <necessidade que você quer atender>
O <seu produto>
É um <definição do seu produto>
Que <como seu produto atende à necessidade>
Diferentemente de <solução concorrente>
O Nosso produto <diferencial do seu produto>
41. Features
Feature
• A cohesive bundle of externally visible
functionality that should align with
business goals and objectives. Each
feature is a logically related grouping of
functional requirements or non-
functional requirements described in
broad strokes.
– BABOK (http://www.iiba.org/)
43. Jornada do Cliente
• Percurso ou
sequência de passos
dados, para alcançar
um objetivo.
• Alguns desses
passos representam
os diferentes pontos
de contato com o
produto, criando as
interações com ele.
44. User Story
• Formato mais popular usado para definição de incrementos de
produto com valor e foco em quem usa.
• Serve para criar os PBIs – Product Backlog Itens (features ou épicos).
• É breve e os detalhes são escritos como critérios de aceite/satisfação.
• Qualquer membro do time pode escrever.
• Eu, como <um usuário do produto>, quero <um
desejo/meta/solução>, para <motivação/justificativa para a
funcionalidade>.
49. MVP - Minimun Viable Product
• A versão maios simples de
um produto que pode ser
disponibilizada para o
usuário e representa uma
hipótese, para o negócio
aprender com ela.
51. O Grooming
• É o refinamento do Backlog do Produto.
• Ações para adicionar detalhes, estimativas e ordem aos itens no
Backlog do Produto.
• Este é um processo contínuo onde o Product Owner e o Time de
Desenvolvimento colaboram nos detalhes dos itens do Backlog do
Produto (PBI).
53. Técnicas de Priorização
MoSCoW
• Must – Contém tudo o que um Release “precisa ter”, para não ser
considerado um fracasso.
• Should – Itens que são importantes, mas não são críticos para o Release.
Aquilo que geralmente consideramos ser “legal ter”.
• Could – São desejados, mas não são necessários. Incrementos menores e
de baixo custo podem entrar aqui.
• Won’t – Itens de pouca importância ou que ainda não foram alinhados com
a estratégia do produto. Podem entrar em Releases futuros ou até serem
descartados.
54. Técnicas de Priorização
Valor X Esforço
Combina o valor para o negócio com o esforço de desenvolvimento da
feature. O que tiver valor mais alto e esforço mais baixo, vem na frente
do que tem valor mais baixo e esforço mais alto.
01) Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
02) Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
03) Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
04) Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
05) Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
06) O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
07) Software funcional é a medida primária de progresso.
08) Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
09) Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
10) Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11) As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
12) Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.