Estratégias, dicas e metodologias

1. Desenvolvimento Ágil de
Software com Scrum
Fairus Manfroi

2. 1. OBJETIVO
2. VISÃO GERAL DO ÁGIL
3. VISÃO GERAL DO FRAMEWORK SCRUM
Agenda

3. Entender os conceitos envolvidos na
metodologia Ágil
Entender a cultura a ser construída
para alcançar o sucesso em projetos
Ágeis
Familiarizar-se com os conceitos
fundamentais do Scrum Framework
Preparar os participantes para
participarem efetivamente da Inception
objetivos

4. visão geral de metodologia Ágil

5. por que adotamos
metodologia ágil?

6. Standish Group. CHAOS report, 2015
Resolução dos projetos de software
Bem sucedido
O projeto é concluído dentro do prazo e orçamento planejados,
com todos os recursos e resultados originalmente especificados.
Deficitário
O projeto é concluído e operacionalizado, mas com atraso, acima
do custo estimado ou com menos recursos e resultados que o
especificado.
Mal sucedido
O projeto é cancelado antes de ser concluído ou nunca é
implementado.
Resolução dos projetos de software

7. Apoio da alta gestão ou patrocínio executivo.
Maturidade emocional, ou seja, como as pessoas
interagem, seu comportamento quando trabalham
juntas - a soma das suas habilidades e deficiências
determinarão a maturidade emocional dos envolvidos
no projeto.
Envolvimento efetivo e positivo dos usuários.
Otimização, consequência do bom gerenciamento de
escopo, alinhando-o com o valor de negócio.
Equipe capacitada fará diferença na execução do
projeto e na qualidade do produto entregue.
Arquitetura Padrão, com processos e práticas
consistentes e bem definidos.
Processos Ágeis com alinhamento dos envolvidos à
cultura (mindset) ágil.
Execução Modesta que otimiza o uso de recursos e de
ferramentas sem “engessar” sua execução.
Expertise em gerenciamento de projetos.
Objetivos de negócio claros, bem definidos.
Resolução dos projetos de software - Fatores de sucesso
Standish Group. CHAOS report, 2015

8. origens das respostas
Fonte: 11ª pesquisa anual sobre
o estado do ágil no mundo, 2017.
www.stateofagile.com
Aspectos benéficos da adoção do Ágil - visão das empresas

9. Fonte: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams.
Canada, 2006
Como os desenvolvedores se sentem com a adoção do ágil

10. A metodologia Ágil

11. abordagem iterativa e evolutiva
entrega contínua em iterações curtas
foco no valor para o usuário
produto entregue evolui em recursos e
complexidade
aceleração do time-to-market
feedback rápido
pressupõe colaboração e comunicação
transparência na gestão do projeto
flexibilidade para mudanças
agilidade nas decisões
melhoria da qualidade
aumento na produtividade
características da metodologia Ágil

12. escopo e objetivos claros e
priorizados
equipes auto-gerenciáveis, maior
motivação, autonomia, disciplina e
regularidade
maximização do comprometimento
melhoria na comunicação
inspeção e adaptação constantes do
processo em busca da melhoria
contínua e redução dos
desperdícios
antecipação dos problemas e maior
agilidade na tomada de ações
as vantagens para o time

13. a metodologia Ágil é...

14. os 4 valores ágeis

15. os 12 princípios do manifesto ágil

16. o mindset ágil

17. Fonte: The Agile Mindset. Zen Ex Machina (2017)
FAZER Ágil X SER Ágil

18. O processo ágil de software

19. Ágil é um conceito “guarda-chuva”

20. Fonte: 11ª pesquisa anual sobre o estado do ágil no mundo, 2017. www.stateofagile.com
principais métodos e práticas ágeis

21. visão geral do framework scrum

22. o que é o framework scrum
Scrum é uma estrutura (framework) de
processos pensada para apoiar o
desenvolvimento e manutenção de produtos
de software
é um framework ágil para gestão e
planejamento de projetos de software
permite manter o foco na entrega do maior
valor de negócio, no menor tempo possível,
primando pela rápida e contínua inspeção
de produto e processo
o Scrum consiste em times scrum, cujos
membros são associados a papéis,
participam dos eventos (cerimônias) scrum
e executam as iterações (sprints), durante
os quais produzem os artefatos scrum.
cada um dos componentes do framework tem
um propósito específico e é essencial para
o uso e o sucesso do Scrum.

23. pilares, valores e princípios do scrum

24. A matriz Stacey foi desenvolvida para ajudar
os gestores a determinarem a complexidade de
seus ambientes, de modo a que adaptem a eles
seu estilo de tomada de decisão.
Foi adaptada para o desenvolvimento de
software, onde é plotada com os eixos
Requisitos (What) X Implementação/tecnologia
(How):
Requisitos (What?): o quanto sabemos sobre o
produto desejado e quais funcionalidades e
recursos precisam ser desenvolvidas
Implementação/tecnologia (How?): o quanto
sabemos sobre a construção do produto em
termos de implementação/tecnologia
Scrum é adequado para projetos complexos

25. ágil/scrum e
ciclos PDCA
os processos ágeis
são processos
empíricos
o conhecimento é obtido por
meio da experiência, o
conhecimento é incompleto e
probabilístico e, portanto,
está sujeito à revisão
contínua e a falseamento
erre rápido,
aprenda rápido e
melhore rápido!

26. o framework Scrum

27. scrum framework

28. práticas do scrum

29. Papéis scrum
(roles)

30. O time Scrum

31. o que faz o time scrum?

32. componentes do time scrum

33. product owner
é visionário e realizador
participa do time scrum
representa os clientes
tem domínio do negócio
é comprometido com o
projeto
é disponível
escreve as histórias de
usuários
tem visão do todo
sabe priorizar (tudo é
importante mas nem tudo
precisa ser feito agora)

34. o que faz um product owner?
Um excelente Product Owner vai:
➔ manter vivo o Product Backlog
➔ identificar e entender o que é valor
para o cliente
➔ priorizar os itens no Product Backlog
➔ auxiliar o cliente na tomada de
decisões e a entender o mindset ágil
➔ trabalhar junto com o time
➔ saber otimizar (usar da melhor forma
possível) a produtividade do time,
seja priorizando corretamente os
itens de backlog ou não pedindo
soluções mirabolantes/de baixo valor
➔ saber falar não
➔ saber falar SIM e saber escutar o
time
➔ saber separar sua função da de gestor
de projetos
➔ ser dono do produto, não do processo

35. scrum master
auxilia o time e o product
owner
mentor dos processos scrum
escudo contra interferências
externas ao time
é um líder servidor
colabora na construção de um
time auto-organizado
removedor de impedimentos
agente de mudanças
é o herói do feedback
colaborativo
comunicativo

36. o que faz um scrum master?

37. o que NÃO faz um Scrum Master?
Scrum master NÃO é o líder técnico.
Scrum master NÃO é o product owner.
Scrum master NÃO gerencia o time ou projeto.
Scrum master NÃO toma decisões pelo time.
IMPORTANTE LEMBRAR

38. time de desenvolvimento
valoriza entregas com qualidade
intensamente comunicativo e
colaborativo
mantém visibilidade do trabalho
auto-organizado
habilidades t-shapped
(especialista-generalista)
de longa duração
adequado número de
integrantes
focado e comprometido
trabalha em ritmo
sustentável

39. o que faz o time de desenvolvimento?

40. scrum em grandes projetos
Scrum tem mais condições de sucesso em projetos com times
pequenos (3 a 9 pessoas)
E se o projeto precisar envolver muitas pessoas?

41. artefatos scrum

42. backlog do produto

43. backlog do produto
É uma lista priorizada de
funcionalidades (ou itens de
backlog do produto - PBIs)
desejadas para o produto.
Provê entendimento
compartilhado do que será
construído e em que ordem.
É acessível a todos os
participantes do projeto.
Enquanto houver um produto
sendo construído ou evoluído,
o backlog é constantemente
atualizado.

44. o backlog do produto é como um iceberg...
história
● uma necessidade do
usuário no modelo
INVEST
funcionalidade (features)
● um conjunto de
requisitos agrupados
por afinidade
● que entregam valor a
um grupo de usuários
épico
● identifica requisitos
grandes e pouco claros
● de baixa prioridade
● e podem vir a ser
quebrados em várias
funcionalidades

45. refinamento dos PBIs
O backlog do produto é vivo e pode ser
constantemente atualizado.
Os PBIs listados no backlog do produto
possuem diferentes níveis de detalhamento e
prioridade.
Os PBIs mais prioritários estão no topo e
serão os primeiros a serem detalhados,
estimados e implementados.
PBIs que forem entrar na próxima sprint
devem possuir o status Preparado.
Para adquirirem o status preparado, os PBIs
passam por um processo de detalhamento
chamado de grooming.
O grooming é uma atividade colaborativa
liderada pelo product owner com participação
de todo o time.
No planejamento de um sprint, geralmente, o
time espera investir até 10% do tempo em
atividades de grooming.

46. refinamento dos PBIs

47. backlog da sprint
O grooming resulta em um conjunto de
PBIs priorizados (no topo do
backlog).
Para serem considerados preparados,
os PBIs são avaliados pelos
critérios de preparado, acordados
entre o PO e o time.
Quando os PIs preparados e
priorizados são selecionados para
desenvolvimento em uma sprint,
passam a compor o backlog da sprint.
quando o PBI for descrito como
pronto, todos devem entender o que o
“Pronto” significa, por meio dos
critérios de done, negociados entre
o time e o PO.
os incrementos prontos vão compor o
produto potencialmente entregável.

48. Critérios de Preparado
Exemplo:
● O PBI está escrito em
forma de história de
usuário INVEST?
● O PBI possui uma lista
completa dos critérios de
aceite?
● O PBI possui informações
dos dados processados e
resultados esperados?
Critérios de Pronto
Exemplo:
● checkin de todo o código
● testes unitários passando
● testes de stress passando
● testes de integração passando
● testes de aceitação
identificados, codificados e
passando
● incremento aprovado pelo PO
● métricas de qualidade
● requisitos não funcionais
verificar critérios de pronto é
tarefa que deve ser planejadas nas
sprints
backlog da sprint

49. ALM - ferramenta para gestão do backlog
Estado do
PBI no
backlog do
produto
Tamanho
estimado
pelo time
para o PBI
Valor
do PBI para
o negócio
Lista dos
itens de
backlog do
produto(PBI)
Prioridade
do
PBI para o
negócio

50. Quem decide quando o PBI está
Preparado?
R.: o time de desenvolvimento.
Quem prepara o PBI?
R.: o PO com o apoio do time
item de backlog preparado (ready)

51. cerimônias do scrum

52. definição do
produto

53. o produto a ser construído é definido
em um evento chamado “inception deck”
o evento de inception
elimina confusões e mal-entendidos,
estabelece expectativas,
esclarece sobre os desafios
e constrói alinhamento
ANTES que o projeto inicie.
ferramentas para definição do produto:
- por que estamos aqui?
- elevator pitch
- é/não é/faz/não faz)
- personas
- funcionalidades
definição do produto

54. por que estamos aqui?
na inception, o Product Owner
expõe para os participantes:
● contexto de negócio
● problema que o produto
visa a resolver
● usuários e suas angústias
por não tê-lo
● benefícios para os
usuários
● expectativas e desejos
quanto ao projeto.
segue uma sessão de perguntas
e respostas.
essa atividade finaliza
quando os participantes
concluírem que entenderam o
problema e a necessidade de
negócio.

55. visão do
produto
rumo a seguir
Uma visão do produto única e
compartilhada por todos os
envolvidos no processo de sua
criação é fundamental para projetos
com potencial de inovação e de
mudanças constantes.
A visão compartilhada oferece ao
time o rumo a seguir no processo de
construção do sistema e mantém a
flexibilidade necessária para se
adaptar às mudanças.

56. o discurso de elevador é uma ferramenta para elaboração
colaborativa da visão do produto
os participantes do evento de definição de produto (que
inclui o expert de negócio), em grupos, propõem uma
solução para o preenchimento das lacunas do template
cada grupo apresenta sua proposta e, junto com os demais
participantes, elas são discutidas, validadas e
refinadas
a atividade resulta numa descrição sucinta do produto
que será construído durante o projeto e servirá de guia
para o time
visão do produto
se você só tivesse o tempo de uma
viagem de elevador, o que você diria a um
investidor para convencê-lo a
investir no seu produto?

57. visão do produto
ELEVATOR PITCH DO WII
PARA pais com filhos pequenos
OS QUAIS/QUE/CUJO estão
assustados com os consoles de
games tradicionais
O Nintendo Wii
É UM sistema para entretenimento
familiar
QUE permite que as famílias
joguem juntas.
DIFERENTEMENTE DE XBox e PS3 que
possuem joystick e controles
complicados
NOSSO PRODUTO usa uma abordagem
natural, baseada em gestos, para
jogar que permite que toda a
família jogue (até mesmo a vovó).

58. objetivos do produto
para construir e consolidar o
entendimento dos participantes sobre os
objetivos do produto, usa-se uma
dinâmica chamada É – Não é – Faz – Não
faz.
cada membro do time compartilha (em um
post-it) o que entende que:
● É objetivo do produto ou que o
produto FAZ
● NÃO É objetivo do produto ou que o
produto NÃO FAZ
cada post-it apresentado é discutido,
avaliado e aprovados pelo POs
post-its com objetivos similares são
agrupados e consolidadas.

59. personas
persona é uma ferramenta
que descreve
características de pessoas
fictícias, para representar
usuários reais
aplica-se em projetos
centrados no usuário para
definir os objetivos e
desejos dos reais usuários
servem para orientar
decisões sobre tipo de
interface, navegação no
sistema, recursos e
funcionalidades
necessários, limitações
tecnológicas, performance
exigida, ...

60. descobrindo personas
durante a inception, os participantes são
divididos em times com a maior diversidade
possível.
cada grupo propõem um conjunto de personas
seguindo o template dado; posteriormente,
os times apresentam as personas
identificadas para os demais grupos e todos
discutem e fazem a consolidação e
refinamento das personas aprovadas.
o conjunto final de personas deve
corresponder ao grupo de usuários cujas
necessidades serão atendidas pelo sistema a
ser construído.

61. descobrindo personas

62. funcionalidades
após ter definido os objetivos do
produto e suas personas, é hora
de definir as suas
funcionalidades macro (épicos).
os participantes da inception
organizam as personas e os
objetivos em ordem de prioridade
(mais alta para menos alta) na
matriz de funcionalidades.
depois, cada participante escreve
as funcionalidades que acredita
serem necessárias em um post-it e
a apresenta para os demais.
todos discutem a necessidade
apresentada, refinam a ideia e
colam o post-it na posição
correta dentro da matriz.

63. funcionalidades
as funcionalidades são
identificadas com base nos passos
que o usuário (persona) executa
para atingir seu objetivo
cada funcionalidades recebe uma
identificação (p.ex. de no máximo o
tamanho de um post do twitter)
a identificação deve deixar clara a
necessidade a que a funcionalidade
se refere
o quadrante superior esquerdo da
matriz conterá as funcionalidades
por objetivo x persona mais
prioritárias.
a matriz de funcionalidades oferece
uma visão macro concreta do que vai
ser construído no sistema.

64. mínimo produto viável (MVP)
o conceito de MVP (originado no estilo
Toyota de manufatura enxuta) foi adaptado
para ser aplicado a projetos de software
ágeis
projetos ágeis são sujeitos a mudanças de
requisitos e seu desenvolvimento inicia
com base em suposições não integralmente
validadas.
o MVP é uma forma de mitigar os riscos
desse tipo de processo, por ajudará a
validar as suposições iniciais e gerar
aprendizado a cada iteração.
o aprendizado obtido em cada ciclo de
desenvolvimento servirá de base para a
evolução a ser dada ao produto no próximo
ciclo.

65. mínimo produto viável (MVP)
um MVP é a versão do produto que
possui o mais alto retorno de
investimento versus risco.
visa a evitar o investimento de
recursos na construção de um produto
que o cliente não quer.
o MVP inicial entrega uma quantidade mínima de
recursos que representam a ideia geral do
produto idealizado, ao mesmo tempo que são de
valor para o usuário desde a primeira entrega.
a cada ciclo de desenvolvimento, o MVP é
adicionado de valor para o usuário, até que se
torne o produto final desejado.

66. o que você querrecursos necessários O MVP
vem com
cinto de
utilidades!

67. mínimo produto viável (MVP)
na matriz de
funcionalidades,
demarcamos aquelas que
irão compor nosso MVP
normalmente, o MVP
conterá funcionalidades
suficientes para o
trabalho de 1 a 2
releases
as funcionalidades fora
da marcação serão
evoluções de futuras
releases
MVP

68. histórias de usuários
a partir da matriz de funcionalidades,
inicia-se o processo de decomposição das
em histórias de usuários, as quais
formarão o backlog do produto.
uma funcionalidade poderá ser decomposta
em diversas histórias, escritas de forma
aderente ao padrão proposto.
o time apoia o PO na escrita e
identificação das histórias.
para cada história atribui-se uma
codificação que a identifica e também à
funcionalidade a partir da qual ela foi
derivada.

69. mapa de histórias de usuários
o mapa de histórias de usuário é uma
abordagem para organizar e priorizar as
histórias.
tornam visível o workflow ou cadeia de
valor
mostram os relacionamentos entre
histórias grandes e suas derivadas
ajudam a confirmar a completude do
backlog
provêem um contexto útil para a
priorização
ajudam a planejar as releases em fatias
de funcionalidades completas e valiosas.

70. avaliação de riscos e estimativa de tamanho
com a lista de histórias de usuário pronta,
é necessário avaliar o quanto entendemos da
necessidade e atribuir-lhes uma estimativa
de tamanho e os riscos envolvidos.
nesta etapa, para cada história:
● um membro do time de desenvolvimento
diz para os demais o que entendeu da
necessidade e, no quadro de
estimativas, a classifica em termos de
entendimento de negócio x riscos
tecnológicos e em termos de nível de
esforço exigido.
● o time e o PO discutem e alinham o
entendimento da história e a percepção
dos riscos e esforço
● o PO classifica a mesma história de
acordo com o valor de negócio que ela
representa.

71. avaliação de riscos e estimativa de tamanho
após a avaliação, cada história
recebe uma marcação identificando
o risco, tamanho e valor de
negócio que lhe foi atribuído
pelo time.

72. roadmap do produto
o conjunto das histórias
especificadas é organizado abaixo
das funcionalidades que lhe deram
origem e são dispostas em ordem de
prioridade, de cima para baixo.
o resultado final do trabalho
constitui o roadmap do produto, já
organizado em releases.
considerando a importância de
negócio e riscos da história, e
também critérios tais como
capacidade do time, o timebox da
sprint, critérios de pronto e a
quantidade de sprints por release,
o PO e o time delimitam as
histórias priorizadas que espera
serem entregues em cada release.
o grupo de funcionalidades
demarcado nas releases deve ser
coerente com a necessidade de
negócio a ser atendida.

73. planejamento
da release

74. estimando o tamanho das histórias
trata-se de uma ESTIMATIVA baseada nos
fatores de risco e de tamanho atribuídos
às histórias pelo time e na sua
experiência com histórias semelhantes.
o tamanho das histórias é estimado em
pontos ágeis, os quais correspondem aos
primeiros valores da sequência de
Fibonacci além dos números 20 e 40.
cada membro do time atribui uma pontuação
inicial à história e o time discute e
entra em acordo sobre a pontuação que
acha mais adequada
o tamanho da história
sugere o intervalo da sua
pontuação
o risco da história sugere sua
pontuação (que estará dentro
do intervalo do tamanho).

75. considerando critérios
tais como capacidade do
time, o timebox da sprint
e a pontuação ágil
atribuída, as histórias
priorizadas para a
primeira release são
distribuídas entre as
sprints planejadas.
desta forma, se constrói o
backlog da release.
o backlog da release

76. o mapa das
histórias

77. release em
execução

78. planejamento
da sprint

79. execução da
sprint

80. validação
da sprint

81. reunião
diária
(daily)

82. o quadro kanban da sprint

83. o burndown da sprint

84. o burnup da release

85. a velocidade do time
(esforço por sprint em pontos ágeis)

86. somos um time fine-tuned!
https://www.youtube.com/watch?v=hlZ5BlKTUOk&list=RDhlZ5BlKTUOk
obrigada!

89. http://www.fabiocruz.com.br/inception-meeting/
http://panthersoftware.com/2014/11/20/mvp-for-stakeholders-project-managers-and-architects/