O evento de Inception para times ágeis

Fairus Manfroi
Agile Inception

1. Apresentações pessoais
2. Alinhamento da meta da semana
3. Estruturação do evento
a. Condução
b. Organização dos trabalhos
i. continuidade à pré-inception
ii. momentos individuais dos Times
1. distribuição entre as salas
2. materiais (folhas, post it, canetas, flipcharts...)
3. definir quem registra as discussões e decisões em cada time
4. lanche coletivo
iii. momentos coletivos para alinhamento
1. Daily (planejamento do dia)
2. Fechamento do dia (conquistas, impedimentos, socorro!, quadros)
c. Quadros (feedback, parking lot, nuvem de idéias)
4. Ajustes dos horários
abertura

agenda do dia
● manhã
○ vocabulário scrum
○ times: montar o mapa de funcionalidades
● tarde
○ hands-on: refinando as funcionalidades em histórias de
usuário
○ times: refinar as funcionalidades em histórias de usuário
terça-feira

mínimo produto viável (MVP)
um primeiro MVP contém as funcionalidades
mais prioritárias e que agregam mais
valor x risco ao produto.
o MVP é incrementado em ciclos sucessivos, os
quais adicionam valor às suas funcionalidades,
até que se torne o produto desejado pelo
usuário.

conhecemos algo que já foi MVP?

vocabulário scrum
● Product Owner (PO): pessoa responsável por dizer para o time de desenvolvimento
as necessidades de negócio (é um representante do cliente), além de manter as
histórias mantidas no backlog (incluir, excluir, alterar, priorizar e detalhar as
histórias).
● Scrum Master: apóia o PO na sua função, é um “escudo” contra interferências
externas para o time de desenvolvimento e guia o time na efetiva execução do
Scrum.
● Time de desenvolvimento: é quem implementa a solução; habilidades
especialista-generalista; tamanho ideal: entre 3 e 9 membros.

vocabulário scrum
● Backlog: lista de histórias de usuário que agregam valor em pequenos incrementos
ao sistema a ser produzido. A maioria das histórias do backlog é produzida na
inception, porém podem surgir a qualquer momento do projeto.
● Refinamento: evento em que PO e time se reúnem para definir quais histórias de
usuário serão tratadas na próxima sprint (dentre as priorizadas pelo PO).
○ refinar histórias envolve entender que recursos precisam ser desenvolvidos
pelo time para atendê-la, quebrar histórias grandes em outras menores e
atribuir/aferir a pontuação ágil que lhe tenha sido dada;
○ para cada história, o PO deve determinar os itens de verificação de “pronto”
(critérios de aceite) que irá validar no final da sprint para aceitá-la como
concluída;
○ acontece antes do início da sprint (normalmente na última semana da sprint
anterior);
○ timebox de 1 a 4 horas; participantes: PO, Scrum Master e, se não for
possível todo o time, pelo menos os mais experientes
desenvolvedores/testadores/analista de requisitos;

vocabulário scrum
● Sprint:
○ são os ciclos de trabalho em que os incrementos nas funcionalidades do
sistema (histórias) são detalhados, construídos, validados e entregues para o
cliente;
○ os pacotes de trabalho de cada sprint são definidos durante o evento de
planejamento da sprint, a partir dos itens de backlog com status “Preparado”;
○ têm duração pré-definida (time-boxed), entre 2 e 4 semanas e deve ter duração
igual em todos os ciclos de construção do sistema;

vocabulário scrum
● Cerimônias que ocorrem durante uma sprint:
○ Planejamento: as histórias priorizadas no refinamento são quebradas em
tarefas pelo time de desenvolvimento e, para cada tarefa o time estima o
tempo que será gasto na sua conclusão. Ocorre no primeiro dia da sprint.
Participantes: time de desenvolvimento, facilitada pelo Scrum master. O PO é
informado das histórias que o time planejou para a entrega da sprint e dá seu
aceite (ou não). Time-box: 1 a 4 horas.
○ Daily [inspect and adapt]: reuniões diárias do time e Scrum master,
geralmente pela manhã, em que cada membro do time planeja as atividades do
dia, atualiza os demais sobre os progressos do dia anterior e solicita ajuda
em impedimentos. Timebox: 15 minutos.
○ Revisão/validação: evento em que o time apresenta para o PO o resultado dos
trabalhos da sprint e o PO verifica se os critérios de aceite que especificou
para cada história foram ou não atendidos no incremento sendo validado. Time
box: até 1 hora.

vocabulário scrum
● Cerimônias que ocorrem durante uma sprint (cont.):
○ Retrospectiva [inspect and adapt]: ao final de cada Sprint a equipe se reúne
para avaliar seus resultados, as dificuldades superadas e levanta ações que
serão aplicadas nas próximas sprints visando a melhoria contínua no processo
Ágil e no Scrum. Time box: 1 hora.
○ Pontos de controle [inspect and adapt][prática recomendada]: eventos semanais
entre time e PO. O time apresenta o progresso das atividades até o momento e
esclarece dúvidas. O PO, quando é o caso, tem oportunidade de identificar
ajustes necessários às histórias em tempo de minimizar o prejuízo de se
continuar o desenvolvimento de uma história que não agrega o valor necessário
ao produto. Quando o time avaliar que o impacto do ajuste é grande demais
para absorver na sprint, um replanejamento da história será necessário. Time
box: 30 minutos.

refinando o
entendimento das
funcionalidades

por que refinar as funcionalidades em histórias de
usuários?
é importante obtermos histórias mais
granulares porque:
● saberemos se podemos concluir seu
desenvolvimento em uma sprint
● evidenciaremos melhor o conhecimento que
temos sobre ela
● obteremos estimativas mais acuradas do
esforço requerido em seu desenvolvimento.

histórias de usuário funcionam como um
lembrete de “coisas” (incrementos de valor)
que devem ser construídos para que uma
funcionalidade evolua até que oferecer
todos os recursos que satisfaçam a
necessidade do usuário.
histórias de usuário não são especificações
de requisitos: elas contêm somente as
informações suficientes para servir de meio
para relembrar itens que o usuário
necessita na funcionalidade, e para guiar
as conversas entre time e PO em que será
refinado o entendimento da necessidade.
os documentos de requisitos são
especificados ao longo de todo o projeto,
pois, assim como o entendimento do produto,
estarão em constante evolução.
histórias de usuário: um modo de melhorar o
entendimento das funcionalidades

os 3Cs que estruturam uma história de usuário
Cards
escrita em um cartão ou
post-it
Conversation
um texto curto que serve de
lembrete para discussão e
refinamento
Confirmation
os critérios a serem
avaliados pelo PO antes de
ele decidir se aceita ou não
a entrega do incremento ao
sistema

3Ws guiam a composição de histórias de usuário
como um/a
[WHO?]
[papel de usuário, ator ou persona]
eu quero/posso/devo
[WHAT?]
[ação ou tarefa que quero realizar
ou funcionalidade/recurso do sistema
que desejo acionar]
para
[WHY?]
[motivo pelo qual quero usar a
funcionalidade, realizar a ação e/ou
o resultado que devo obter a partir
da ação que quero realizar]
como um
product owner do PUCOMEX
eu quero
aprender a escrever histórias de
usuário granulares e com a lista
das condições que precisam ser
satisfeitas pelo time
para
que o time seja capaz de entender
minha necessidade e fazer
questionamentos que adicionem os
detalhes necessários para que a
história possa ser planejada e
desenvolvida na próxima sprint.

exemplo: uma história de usuário refinada
conversation (a história): confirmation (critérios de aceite):

I
N
V
E
S
T
INVESTing in good user stories
testável
contém lista de resultados esperados e
critérios de aceitação
independente
são auto-contidas e podem ser concluídas
em qualquer ordem
negociável
sem excesso de detalhes, dão margem à
criatividade e à inovação
valiosa
geram valor para o trabalho do usuário
estimável
contêm detalhes suficientes para estimar
o tempo de implementação e testes
small (pequena)
tamanho tal para ser terminadas em uma
sprint
1
2
3
4
5
6

histórias de usuários
o livro “Agile Software Requirements”
recomenda uma série de técnicas para análise
e separação de funcionalidades ou histórias
em outras mais granulares.
Mapa: como quebrar histórias

exercício: quais histórias podem surgir do
refinamento da funcionalidade de login?
Como um usuário
Eu posso logar no sistema
Para acessar suas funcionalidades

hands-on: produzindo
histórias de usuário em
times

o mapa de histórias
o mapa de histórias provê uma forma de organizar e
priorizar as funcionalidades requeridas para o
sistema, bem como evidenciar os incrementos de valor
(representados pelas histórias) planejados para cada
funcionalidade.
na primeira linha da tabela ficam os grandes
objetivos do sistema e na segunda linha ficam as
funcionalidades, ambos em ordem de valor para o
negócio, da esquerda para a direita.
abaixo de cada funcionalidade são posicionadas as
histórias de usuário, em ordem de prioridade de cima
para baixo.

priorizando as histórias
com a lista das histórias de cada
funcionalidade já refinada, é
necessário classificá-las.
a classificação das histórias é
realizada numa dinâmica que envolve
analisar, para cada uma delas:
● valor para o negócio;
● tamanho (custo de desenvolvimento);
● nível de certeza associado à sua
construção (negócio - what; e
tecnológico - how);

priorizando histórias, na prática
Para cada história:
● um membro do time de desenvolvimento
○ pega um post-it de história;
○ explica para os demais o que entendeu
da necessidade representada;
○ no quadro de riscos:
■ o desenvolvedor classifica a
história em termos de
entendimento de negócio x riscos
tecnológicos;
■ os demais, junto com PO, discutem
e entram em consenso sobre a
classificação.
○ no quadro de tamanho:
■ o desenvolvedor classifica a
mesma história em termos de
tamanho (custo);
■ os demais, junto com PO,
discutem e entram em consenso
sobre a classificação.
● o PO classifica a mesma história em termos
de valor de negócio.

priorizando histórias - valor final
atribui-se à história uma marcação (post-it
menor) com os resultados da análise obtida
1. valor agregado: melhor relação entre:
- valor de negócio: $$$, $$, $
- tamanho: P, M, G
2. risco: Alto, Médio, Baixo
são priorizadas as histórias que representem:
● 1º maior valor agregado e maior risco
● 2º maior valor agregado e baixo risco
● 3º baixo valor agregado e baixo risco
histórias de baixo valor agregado porém de
alto risco é melhor não serem priorizadas.

priorizando histórias - valor final
a prioridade da história é indicada
por meio de um post-it
correspondente à cor da prioridade
atribuída:
● prioridade alta: vermelho/rosa
● prioridade média: amarelo
● prioridade baixa: verde

hands-on: priorizando
as histórias

estimando histórias
de usuários

estimando as histórias de usuários
as estimativas tentam responder (ou
dar uma ideia) sobre o tempo que se
deve gastar na história, do momento
que ela entra na sprint até que ela
esteja pronta.
a análise leva em conta os fatores
de risco e de tamanho atribuídos às
histórias pelo time, durante a
priorização.

o esforço necessário para
implementar as histórias de usuário
é estimado em pontos ágeis.
o significado de um ponto ágil é
específico para cada time.
o parâmetro usado para definir o
significado de um ponto ágil pode
ser:
● a velocidade daquele time
específico em outros projetos
(dado histórico)
● ou a experiência do time com a
implementação de histórias
semelhantes
● ou um “educated guess”

por convenção, se adotam na
pontuação os valores até 13 da
sequência de Fibonacci, e os
números 20 e 40.
alguns times incluem o 0 (zero) no
conjunto de pontos possíveis,
geralmente para indicar que a
história não tem condições de ser
estimada.
histórias de 20 e 40 pontos
representam épicos e sagas,
respectivamente.
o time escolhe uma história que
considere ser de 5 pontos e a
utiliza como referência para
atribuir a pontuação das demais
histórias.
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).

na dinâmica de estimativa, o
mais comum é que, para cada
história:
● um membro do time atribua
uma pontuação inicial à
história e justifica para
os demais sua atribuição;
● o time discute e entra em
acordo sobre a pontuação
que acha mais adequada.
a dinâmica pode ser apoiada
pelo planning poker, um game
que oferece uma maneira
enriquecedora de se aprender
mais sobre a história enquanto
se obtém um consenso.

o mapa de histórias
quando tivermos
obtido as histórias
ordenadas embaixo das
respectivas
funcionalidades e com
sua pontuação
definida, será
possível demarcar as
releases (ou seja, os
momentos em que os
incrementos no MVP
serão construídos e
disponibilizados).

hands-on: estimando
as histórias de
usuários

definição de “preparado”
● O que uma boa história de usuário não
deve ser:
○ um telegrama de tão econômicas em
detalhes
■ O CUSTO DA HISTÓRIA NÃO É
MEDIDO PELO NÚMERO DE PALAVRAS
○ uma especificação técnica de tão
detalhadas
■ NÃO É PAPEL DO PO FAZER
ESPECIFICAÇÃO TÉCNICA
(DIAGRAMAS UML, MODELO DE
DADOS,…)
● A literatura (ex,: Mike Cohn, um dos
pais do Scrum) recomenda como critério
para de boas histórias o INVEST
○ guia para o PO escrever as
histórias
○ guia para o time avaliar e aceitar
a história no backlog da sprint

I
N
V
E
S
T
INVESTing in good user stories (guia para o ready)
testável
independente
em qualquer ordem
negociável
sem excesso de detalhes (técnicos, p.ex.) -
o time tem liberdade de propor soluções
valiosa
agregam valor para as atividades do
usuário
estimável
small (pequena)
são de tamanho adequado para serem
terminadas em uma sprint
1
2
3
4
5
6

I
independente
em qualquer ordem
4
histórias são mais facilmente trabalhadas
quando são independentes - podemos
implementá-las em qualquer ordem, já que não
são intimamente ligadas, gerando uma cascata
(que pode virar gargalo) de implementação.
talvez essa seja a característica mais difícil
de alcançar totalmente.

N
negociável
sem excesso de detalhes (técnicos, p.ex.) -
o time tem liberdade de propor soluções
5
histórias não são contratos (com todos os
detalhes técnicos e de negócio) para
implementar features: boas histórias captam as
informações essenciais necessárias para
entender a necessidade de negócio, mas não
inclui todos os detalhes para a implementação
de uma feature - deixa margem para negociação.
Definida a essência, os detalhes são NEGOCIADOS
entre o time de desenvolvimento e o Product
Owner: em vez de serem definidos por ele.

V
valiosa
agregam valor para as atividades do
usuário
1
a premissa básica de uma história é que ela
agregue valor ao produto para o cliente.
ao decompor as histórias maiores em histórias
mais granulares, temos de ter o cuidado de não
transformá-las em algo que não agregue valor à
feature e não possa ser avaliado pelo PO
conforme os critérios de done negociados.

E
estimável
6
a estimativa, por definição, não será exata: o
time não precisa acertar sempre, mas precisa
ser capaz de estimar uma user story.
a qualidade da estimativa do time está
diretamente relacionada ao seu entendimento
quanto às necessidades representadas pela
história em seus aspectos de complexidade,
tamanho, necessidade de negócio, riscos
arquiteturais e técnicos, interface, etc.

S
small (pequena)
são de tamanho adequado para serem
terminadas em uma sprint
3
time e PO estabelecem um acordo sobre o
significado de “pequena” para o tamanho máximo
da história.
histórias pequenas fazem com que as estimativas
sejam mais precisas.
se, durante a planning, o time joga a
estimativa da história “pra cima”, por não
saber o que implicaria sua implementação e não
conseguir um consenso, é um sinal de que que a
história deve ser revista.

T
testável
2
boas histórias, assim como bons requisitos,
devem ser testáveis
se o cliente não sabe como testar algo,
significa que ou a user story não está clara o
bastante ou que ela não contém algo que
acrescente valor do ponto de vista do cliente
a testabilidade é conseguida por meio dos
critérios de aceite ou cenários, que devem ser
o mais completos possíveis, para o escopo da
história

ready & done
as histórias de usuário devem passar por
um processo de refinamento do
entendimento antes de serem incluídas no
backlog de uma sprint.
após o refinamento, o time de
desenvolvimento avalia se inclui a
história no backlog da sprint utilizando
como guia os critérios de preparado
(ready).
durante a execução da sprint, o time
transforma a história em um produto
entregável que será aceito ou não pelo
PO.
para avaliar se aceita os itens sendo
entregues pelo time, o PO utiliza os
critérios de pronto (done) como guia.
critérios de ready e done são negociados
entre o time de desenvolvimento e o PO e
devem estar adequados à realidade de cada
projeto e time, passando por revisões e
evoluções periódicas para se ajustarem às
evoluções no projeto.

definição de “preparado”
Exemplo:
● estão claros Ter definidos os papéis: PERFIL
(quem usa), FUNÇÃO (o que deve fazer) e
OBJETIVO (para que serve);
● foram listados critérios de aceite ou BDDs
cobrindo o maior número possível de cenários?
● pode ser implementada na sprint?
● é independente?
● os cenários são testáveis?
● existe protótipo de tela ou layout de
referência (se for o caso)?
● as integrações necessárias foram identificadas
e negociadas com o time fornecedor?
● os dados de entrada/saída são conhecidos?

definição de “pronto”
Critérios de Pronto
critérios de pronto são exigências que
condicionam o aceite ou não da entrega pelo
PO, e também são critérios que o time
estabelece a fim de garantir a qualidade do
produto construído; são verificados por item
entregável ou por pacote de entrega, no
final da sprint ou da release.
Exemplo de definição de pronto de uma sprint:
● todas as necessidades declaradas na história foram
codificadas?
● todas as evoluções feitas nas funcionalidades estão
disponíveis para o PO testar?
● os testes unitários, funcionais, de integração e
automatizados estão passando?
● métricas de qualidade foram atendidas?
● requisitos não funcionais foram atendidos?
● PO validou e aprovou a entrega?

http://www.fabiocruz.com.br/inception-meeting/
http://panthersoftware.com/2014/11/20/mvp-for-stakeholders-project-managers-and-architects/
https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/

O evento de Inception para times ágeis

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a O evento de Inception para times ágeis

Semelhante a O evento de Inception para times ágeis (20)

O evento de Inception para times ágeis