Escolar Documentos
Profissional Documentos
Cultura Documentos
Apostila Scrum
Apostila Scrum
- Pgina: 1
Contents
Autores ......................................................................................................................... 4
Nelson Abu Samra Rahal Junior................................................................................ 4
Neilza Andrea Abu Samra Rahal............................................................................... 4
Scrum ........................................................................................................................... 5
Voc sabe o que Scrum?......................................................................................... 5
Framework Scrum..................................................................................................... 7
Papis no Scrum........................................................................................................ 8
Product Owner (PO).............................................................................................. 8
Scrum Mster (SM)............................................................................................... 8
Equipe (EQ) .......................................................................................................... 9
Viso do Produto .................................................................................................... 11
Executando a Viso do Produto........................................................................... 11
Exemplo de Viso do Produto ............................................................................. 12
Product Backlog...................................................................................................... 13
Exemplo de Product Backlog .............................................................................. 13
Estimativas, Velocidade da Equipe, Quantidade de Sprints e Product Burndown
Chart....................................................................................................................... 15
Contando os Pontos............................................................................................. 16
Exemplo de Pontos Contados .............................................................................. 17
Determinando o Tempo do Projeto...................................................................... 17
Product Burndown Chart..................................................................................... 18
Priorizao e Distribuio de Requisitos por Sprints .............................................. 20
Executando a Priorizao .................................................................................... 20
Sprint, Planejamento da Sprint #1, Planejamento da Sprint #2, Sprint Burndown
Chart e Execuo da Sprint ..................................................................................... 22
Planejamento da Sprint #1................................................................................... 23
Planejamento da Sprint #2................................................................................... 24
Sprint Burndown Chart ....................................................................................... 24
Calculo de Velocidade da Sprint.......................................................................... 25
Exemplo de Tarefas na Sprint.............................................................................. 25
Exemplo de Ciclo de Vida de Uma Sprint ........................................................... 26
Executando a Sprint ............................................................................................ 28
Desenvolvimento e Reunies Dirias ...................................................................... 30
Sete Fundamentos para reunies dirias eficazes ................................................. 30
Impedimentos...................................................................................................... 31
Dia a Dia da Reunio Diria................................................................................ 31
Review.................................................................................................................... 32
Retrospectiva .......................................................................................................... 33
Linha do Tempo (Timeline)................................................................................. 33
Retrospectiva Rpida........................................................................................... 37
Dia a Dia Aps a Retrospectiva ........................................................................... 38
Release (Verses).................................................................................................... 39
Scrum de Scrum...................................................................................................... 41
Potencializando Scrum............................................................................................ 43
picos, Temas e Historias ........................................................................................... 45
Carto de Historia ................................................................................................... 45
Exemplo de Carto de Historia ............................................................................ 45
Template de Carto de Historia ........................................................................... 45
Organizando Cartes de Historia ......................................................................... 46
Nelson Abu Samra Rahal Junior (abuzitos@gmail.com)
- Pgina: 2
- Pgina: 3
Autores
Nelson Abu Samra Rahal Junior
Paulista de Assis
Certificado ScrumMaster
Paranaense de Arapongas
- Pgina: 4
Scrum
Voc sabe o que Scrum?
* Escrito em parceria com Marcelo dos Santos
Scrum um processo de gerenciamento de projetos geis, adaptado
para a rea de desenvolvimento de software, pelo especialista Ken Schwaber.
Ken define Scrum, em um de seus livros, como: um processo gil ou ainda um
framework para gerenciamento de projetos geis. um processo de gerncia
de projetos, certamente no uma metodologia, pois isto seria pesado
demais.
A primeira experincia com o Scrum ocorreu em uma fbrica de
automveis, onde se constatou que a utilizao de equipes pequenas e
multidisciplinares produzia melhores resultados. Em analogia a essas equipes,
associou-se a formao do Scrum a de um jogo de Rugby. A partir de 1995,
Ken Schwaber formalizou a definio de Scrum e ajudou a implant-lo em
desenvolvimento de software em todo o mundo.
- Pgina: 5
- Pgina: 6
Framework Scrum
- Pgina: 7
Papis no Scrum
Scrum possui apenas trs papeis, sendo eles: Product Owner, Scrum
Master e a Equipe.
- Pgina: 8
Equipe (EQ)
a responsvel pela execuo do projeto, sendo protegida pelo Scrum
Master e tendo como foco o atendimento das necessidades do Product Owner.
Uma equipe em Scrum constituda de no mnimo 2 pessoas e no
maximo de 7 pessoas. As equipes so menores para potencializar uma das
maiores armas do Scrum, a comunicao entre a equipe.
Trs pessoas nos temos uma comunicao direta entre cada integrante
da equipe, conforme a equipe vai aumentando a complexidade de
comunicao entre todos os integrantes vai aumentando.
Equipes enxutas chegam a ter a sua capacidade de produo melhor
que equipes grandes. Este aumento de velocidade ocorre em virtude da
potencializao da comunicao entre os integrantes da equipe.
- Pgina: 9
- Pgina: 10
Viso do Produto
- Pgina: 11
- Pgina: 12
Criar Backlog
Product Backlog
PO
2
Uma vez realizada a apresentao da Viso do Produto para os
envolvidos no projeto uma relao de requisitos deve ser elaborada para que o
sistema possa ser desenvolvido. Est relao de requisitos nos chamamos de
Product Backlog.
Podemos organizar a nossa lista de requisitos de varias maneiras, sendo
uma organizao apenas por requisitos referentes ao negocio a ser
desenvolvido, ou uma lista com a relao de requisitos envolvendo o negocio a
ser desenvolvido mais os requisitos no funcionais do sistema.
A estimativa do tamanho do projeto realizada sobre os requisitos
existentes na nossa lista de Product Backlog, mas para a realizao desta
estimativa nos utilizamos os requisitos em auto-nvel chamados de Temas.
Um Tema um requisito que tem contido dentro dele requisitos menores. Ns
vamos ver melhor a parte de requisitos no universo gil no tpico denominado
de historias.
Todos os envolvidos no projeto podem adicionar requisitos a nossa lista
de requisitos do sistema, mas apenas o Product Owner pode priorizar os
requisitos.
A priorizao destes requisitos contidos no Product Backlog permite uma
viso temporal de quando uma determinada funcionalidade vai ser realizada no
projeto. A principio pode ser considerado um desperdcio de tempo, pois no
decorrer do projeto est priorizao ir ser mudada conforme a necessidade do
Product Owner, mas ela ajuda a todos os envolvidos a terem a viso de como o
projeto vai ser executado j no incio do mesmo, mesmo sabendo que
podemos ter mudanas de prioridade.
- Pgina: 13
- Pgina: 14
Equipe
identifica a qtd
de pontos de
esforo para
cada Item do
Backlog
SM
SM
EQ
Montar
Product
Burndown
Chart
Definir a qtd
de Sprints
SM
EQ
Calcular a
Velocidade da
equipe
SM
- Pgina: 15
Contando os Pontos
O cliente solicitou uma data de termino da entrega do projeto, para que
ele possa realizar uma analise de riscos com relao a data limite da entrega
do projeto e o inicio do perodo de vendas de material escolar.
A equipe se rene com o Product Owner para realizar as estimativas
necessrias. Os requisitos utilizados so os de tamanho de Temas.
Com cada um dos requisitos escritos em papeis e colocados sobre a
mesa a equipe busca os de menos esforo de trabalho. Est busca tem o
objetivo de escolher um requisito que vai ser utilizado como ponto de
referencia, uma ancora em relao aos demais.
A participao do Product Owner fundamental, pois a cada requisito
em tamanho igual a um Tema a equipe pode solicitar maiores informaes e
o Product Owner passa a responder estas informaes. Est reunio inclusive
um timo momento de anotarmos mais requisitos contidos num Tema, para
atualizao do nosso Product Backlog.
A equipe por consenso identifica o requisito de tamanho menor, este
requisito o de Categoria de Produtos. Para facilitar o processo de contagem
de pontos buscamos os requisitos que so um pouco maior que o menor, pois
sempre aparecem requisitos menores ao que nos estamos utilizando como
base, isto , ancora.
Por consenso a equipe escolhe o Cadastro de Clientes e este recebe o
valor igual a dois pontos. Dois pontos neste momento da tcnica de estimativa
no tem nenhuma correlao com o tempo necessrio para a relao do
projeto, apenas representa o tamanho do esforo necessrio para a construo
deste Tema.
Com o requisito de tamanho igual a dois passamos a comparar este
requisito com os demais e atribuir aos demais os valores em pontos
correspondentes. A escala de pontos utilizado a de Fibonacci, 1, 1, 2, 3, 5, 8,
13, 21, 34, ?.
O processo de contagem de pontos, ns utilizamos o Planning Poker,
baralhos com os pontos de Fibonacci, para que ningum da equipe influencie o
outro. Jogamos as cartas viradas para baixo e todos ao mesmo tempo viraram
as cartas para cima, onde podemos realizar a analise dos pontos jogados.
Quando as cartas possuem valores iguais significa que a equipe
chegou a um consenso do tamanho do esforo, mas quando as cartas
possuem valores diferentes sinal que a equipe no esta fechada em um
consenso. Neste momento entra o Scrum Mster como um facilitador
perguntando a cada pessoa da equipe o porqu dos valores de suas cartas, o
que cada pessoa est identificando de esforo a mais do que o outro colega de
trabalho.
As duvidas, incertezas, requisitos que nos acreditamos ser verdadeiros e
contidos no requisito de tamanho igual a Temas do requisito que est sendo
estimado, nos devemos perguntar ao Product Owner, para que ele valide e
deixe claro para a equipe a abrangncia do esforo necessrio.
- Pgina: 16
Pontos
2
Cadastro de Clientes
Cadastro de Produtos
13
Carrinho de Compras
Busca de Produtos
Categoria de Produtos
Histrico de Compras
8
8
13
13
67
- Pgina: 17
- Pgina: 18
- Pgina: 19
Executando a Priorizao
Uma boa tcnica a MoSCoW, onde os requisitos so distribudos por
Sprint respeitando a priorizao.
- Pgina: 20
- Pgina: 21
SM
EQ
11
Montar Sprint
Burndown
Chart
SM
12
A execuo do projeto realizado em perodos de tempo que ns
denominamos de Sprint. Uma Sprint tem perodo maximo de tempo igual a 30
dias e o perodo menor de tempo igual a uma semana.
Dentro de uma Sprint nos temos que executar o Framework do Scrum,
com o planejamento da Sprint, as reunies dirias, a entrega do que foi
realizado no final da Sprint e a Retrospectiva, que uma reunio de melhoria
do processo pela equipe.
Devemos respeitar o perodo de tempo da Sprint como uma regra
inegocivel, onde mesmo no tendo realizado todas as atividades necessrias
da Sprint nos terminamos a mesma, para que mesmo com uma entrega parcial
dos resultados obtidos, seja realizada a entrega.
importante sempre entregarmos o servio realizado na Sprint, mesmo
que este servio no tenha sido concludo em sua totalidade.
A quantidade de servios, isto , requisitos que vamos implementar
dentro de uma Sprint determinada pela equipe e nunca pelo Product Owner.
Quem vai realizar o trabalho deve se comprometer com a quantidade de
servio que vai realizar e nunca se comprometer com o servio que foi
determinado por outra pessoa.
- Pgina: 22
Planejamento da Sprint #1
A reunio de planejamento da Sprint realizada com a Equipe e o
Product Owner e tem o objetivo do Product Owner apresentar a equipe os
requisitos que vo ser desenvolvidos na Sprint.
Este planejamento realizado com todos os integrantes da equipe de
desenvolvimento do projeto, onde passamos a ter analistas de sistemas,
desenvolvedores, testadores, DBA, web-design e quem mais for necessrio.
Com a unio de todas estas especialidades passamos a ter um ganho
melhor de analise de sistemas e uma viso mais critica de como devemos
solucionar os requisitos com a unio de todas ests especialidades. O
conhecimento tambm passa a ser compartilhado o que reduz os riscos da
perda de uma pessoa na equipe, independente do motivo. Tambm nesta
unio de profissionais passamos a distribuidor e potencializar habilidades a
todos, onde a ao de analise de sistemas passa a ser aprendida e realizada
por todos os profissionais.
Um dos grandes segredos desta reunio o Product Owner j vir com
os requisitos bem definidos, para que a equipe tenha uma compreenso bem
abrangente do que deve ser feito com o requisito.
o que eu chamo de requisitos quadrados e requisitos redondos, onde
um requisito quadrado aquele que no tem uma clareza na sua definio e
faz com que a equipe tenha dificuldade de achar as tarefas necessrias para a
sua implementao e durante a execuo do requisito ele gera vrios
impedimentos. Estes impedimentos podem levar a equipe inclusive a uma
implementao parcial do requisito o que leva a uma no entrega do mesmo.
J os requisitos redondos a equipe consegue no planejamento um
entendimento claro do seu objetivo, o que leva a uma definio muito boa das
tarefas a serem realizadas e permite um desenvolvimento sem duvidas. Os
requisitos redondos aumentam a velocidade de desenvolvimento do sistema
pela equipe, isto , ao invs de pressionarmos a equipe para uma velocidade
- Pgina: 23
Planejamento da Sprint #2
O planejamento da Sprint #2 passa a ser realizado apenas pela equipe,
sem a necessidade do Product Owner. Este planejamento tem o objetivo de
determinar como vamos realizar os requisitos, isto , como vamos transformar
o que foi recebido em forma de requisitos em software.
Nesta reunio definimos de maneira rpido como pode ser a tela de um
sistema, o modelo de dados em auto-nvel, as classes necessrias a serem
desenvolvidas, as regras de negocio, etc.
Cada item identificado como sendo parte da soluo do requisito passa
a ser chamado de tarefas e estas tarefas recebem uma estimativa de horas.
Uma boa pratica e ter tarefas com o tempo de no mnimo de 1 hora e de
no maximo um dia de trabalho. Se tivermos tarefas menores de uma hora elas
podem ser agrupadas, para chegarem ao tempo de 1 hora. Uma boa dica
tambm agrupar as tarefas para meio perodo de trabalho, isto , em um dia
de 8 horas meio perodo seria de 4 horas. Desta maneira no perdemos tempo
com estimativas de tarefas pequenas, deixando elas agrupadas e rotuladas
com um conjunto de horas. Tambm ter agrupamento de tarefas faz com que
os integrantes da equipe peguem trabalho sempre para um perodo de tempo
ou um dia inteiro, no sendo necessrio o seu deslocamento para pegar
trabalhos durante o seu dia de trabalho.
Um requisito passa a ter varias tarefas e cada tarefa passa a receber o
tempo necessrio para o seu desenvolvimento. A totalizao das horas
necessrias para a completude dos requisitos selecionados para o
desenvolvimento da Sprint faz com que a equipe saiba se os itens
selecionados para trabalho so suficientes para o tempo existe ou maior,
menor que o tempo que temos de trabalho.
- Pgina: 24
Requisitos em Historias
Endereo do Cliente
campos
- Pgina: 25
Copiar o endereo do
cliente;
Validar CEP;
Validar
obrigatrios;
campos
Histrico de Compras
- Pgina: 26
- Pgina: 27
Executando a Sprint
Aps o planejamento da Sprint #1 e #2 a equipe pode iniciar o processo
de execuo da Sprint. Os requisitos e suas respectivas tarefas so colocados
no quadro de Taskboar, tambm chamado de quadro de Kanban.
Todo dia realizada uma reunio de alinhamento da Sprint, que vai ser
vista no tpico Reunio Diria. A execuo dos Requisitos deve ser realizada
com o conceito Todos Contra Um, onde a equipe inteira ataca o primeiro
requisito, isto , suas tarefas.
Caso no tenha servio para todos, o segundo requisito aberto e os
integrantes da equipe que no estavam trabalhando no primeiro requisito vo
para o segundo. Caso no tenha servio para todos, o terceiro requisito
aberto e assim por diante.
Quando um requisito terminado ou no existe tarefa para todos, o
processo de ajudar no prximo requisito ou abrir um novo requisito deve ser
seguido.
A tcnica de Todos Contra Um faz com que tenhamos ao termino da
Sprint sempre requisitos prontos para serem entregues. Quando colocamos
uma pessoa em cada requisito, isto , Cada um por si ao termino da Sprint
corremos o risco de termos todos os requisitos 90% pronto, mas nenhum
realmente pronto.
Um ponto importante do Todos Contra Um que a equipe em Scrum
realmente uma equipe, no buscamos mais o individualismo e sim o coletivo.
No existe mais o melhor desenvolvedor, o melhor arquiteto, o melhor testador,
existe a equipe, que vai ser forte ou fraca pela unio do grupo.
- Pgina: 28
- Pgina: 29
- Pgina: 30
Impedimentos
Impedimento qualquer coisa que atrapalhe um membro da equipe de
executar o trabalho. Os impedimentos podem ser identificados nas reunies
dirias, onde cada membro da equipe tem a oportunidade de comunicar o
ScrumMaster do impedimento existente. O ScrumMaster responsvel pela
soluo dos impedimentos. O ScrumMaster pode realizar reunies
complementares para solucionar os impedimentos identificados quando as
reunies dirias no permitirem a soluo.
Um dos fatores de potencializao da equipe Scrum est na ao de
retirar da equipe de execuo do projeto a responsabilidade de resolver um
impedimento. Se deixarmos a equipe de execuo do projeto focado apenas na
execuo e passarmos todos os impedimentos ao Scrum Mster vamos ter um
ganho de velocidade e qualidade na execuo dos trabalhos.
- Pgina: 31
Sprint Review
Review
PO
SM
EQ
16
- Pgina: 32
Sprint
Retrospective
PO
SM
EQ
Retrospectiva
17
- Pgina: 33
Descreva o processo.
- Pgina: 34
Voc pode escolher o seu prprio esquema de cores com base nos
cartes e post-its disponveis para voc.
Materiais e Preparao
Quadro branco, papel de parede, fitas, canetas coloridas, post-its
coloridos, etc
- Pgina: 35
Evento
Sentimento
Emocional
Organizao
Produtividade
Processo (Scrum)
Riscos
Tecnologia
Resumo do Abu
Material
o Quadro
- Pgina: 36
Execuo
o Dividir as pessoas em equipes
o Definir legenda dos cartes
o Executar a atividade de criar os cartes
o Criar uma coluna para todos os post-its e colar todos os post-its
nesta coluna
o Reviso da equipe para identificar se no falta nenhum evento ou
sentimento
o Dividir os post-its em colunas que representam as Sprints /
Iteraes / Meses, etc
o Criar um espao abaixo das colunas para a adio de um grfico
emocional
o Cada integrante da equipe desenha uma linha que represente o
seu estado emocional no perodo (sprint)
Legenda
o Verde = Tecnolgico
o Amarelo = Emocional
o Salmo = Organizao
o Rosa = Produtividade
o Azul = Processual
o Roxo = Riscos
Retrospectiva Rpida
Est a segunda tcnica de retrospectiva que vou apresentar, mais
simples e mais rpido de ser executado.
A tcnica simples, colocamos trs colunas na parede, contendo as
palavras Continuar, Melhorar e Parar e todos da equipe escrevem os postits contendo apenas um Evento e o Evento escrito deve ser colocada na
coluna correspondente.
As colunas podem ser preenchidas simultaneamente ou coluna a coluna,
conforme a conduo do Scrum Mster.
Continuar o que nos fizemos na Sprint e que vale a pena ser repetido
para as demais Sprint, at o momento que continue agregando valor ao
processo.
Melhorar o que no est bom, mas importante para o processo e
desta maneira no pode ser removido das atividades que realizamos nas
nossas prximas Sprints.
- Pgina: 37
- Pgina: 38
Montar
Release
Burndown
Chart
PO
Release (Verses)
SM
8
Release ou verso de software o nosso planejamento de entregas de
funcionalidades. Em Scrum para a equipe de desenvolvimento do sistema o
que nos buscamos so metas pequenas e possveis de serem exeqveis.
Porem para o Product Owner o que nos planejamentos so alocaes de
requisitos distribudos ao longo do projeto, para que o Product Owner saiba
quando ele vai ter disponvel a funcionalidade desejada.
Planejamento em Camadas
Estratgia
Portflio
Produto
Release
Sprint
Dia
- Pgina: 39
- Pgina: 40
Scrum de Scrum
Scrum de Scrum a ferramenta que nos temos de realizar um
alinhamento, sincronismo entre projetos.
Se voc perguntar a um integrante de um projeto A qual o projeto mais
importante na empresa ele ir responder que o projeto dele. Se voc
perguntar a um integrante de um projeto B, ele tambm ir responder que o
projeto mais importante o dele.
No tem nada de errado com as respostas obtidas, muito pelo contrario,
cada integrante de um projeto tem que ter a convico que o seu projeto o
mais importante para a empresa.
comum durante a execuo de projetos termos a necessidade de
ajuda para que o nosso projeto continue atendendo as expectativas do Product
Owner. Existem impedimentos que dentro de uma estrutura funcional de uma
empresa o Scrum Mster no ter condies de resolver e ele necessita
escalar o problema para uma hierarquia funcional. Um bom exemplo a
necessidade de recursos externos, pessoas de outras equipes ou um recurso
que dever ser terceirizado. neste momento que o Scrum de Scrum vem
ajudar.
Scrum de Scrum funciona com a reunio de Scrum Mster para
alinhamento dos projetos, solicitaes de ajuda, visibilidade do caminho que a
empresa est seguindo, remoo de impedimentos que o Scrum Mster no
consegue resolver sozinho e o que mais for necessrio.
O Scrum de Scrum tambm permite a troca de experincias, isto , o
que uma equipe est fazendo que est dando certo ou errado, para que
modelos possam ser seguidos pelas demais equipes ou evitados por elas.
A execuo do Scrum de Scrum pode ser realizada todos os dias como
uma reunio diria ou por perodos de tempo.
Tem empresas que preferem realizar no primeiro momento do dia a
reunio de Scrum de Scrum e depois desta reunio realizar as demais reunies
dirias das equipes, para que as informaes possam ser transmitidas a todos.
Isso permite um alinhamento da empresa em um curto perodo de tempo.
J tem empresas que preferem aps a reunio diria das equipes, para
que os problemas sejam passados e o processo de soluo seja iniciado no
mesmo dia.
Um Scrum de Scrum utiliza todas as ferramentas do Framework do
Scrum para gerenciar os projetos que esto nas equipes, uma tima maneira
de gerar informao para levar as pessoas interessadas, que podemos
materializar como exemplo: gerentes funcionais das mais diversas reas da
empresa, diretrios, presidentes, clientes, etc.
- Pgina: 41
- Pgina: 42
Potencializando Scrum
A potencializao do processo Scrum j foi comentada neste material,
mas no custa enfatizarmos mais um pouco sobre o assunto.
Jeff Sutherland um dos criados do Scrum, escreveu um artigo fantstico
sobre a unio de Scrum e CMMI nvel 5, onde o artigo traz uma serie de
procedimentos necessrios para que este casamento seja possvel. Estes
procedimentos para atendimento do CMMI nvel 5 no fazem parte do escopo
deste material.
Mas um destes procedimentos est a potencializao do Scrum para o
que ele chamou de Entendendo o Sucesso do Scrum.
Jeff traz o conceito de Pronto e Feito, onde Pronto so requisitos
possveis de serem implementados e Feito o requisito desenvolvido
conforme os critrios de aceitao do Product Owner.
O Feito a nossa coluna de Done de um quadro de Kanban (tambm
chamado de Taskboard), que definido entre a equipe e o Product Owner.
Para aumentar a velocidade da equipe com os requisitos Prontos, os
mesmos so escritos pelo Product Owner com o auxilio do Scrum Mster, eles
juntos realizam um trabalho de preparao do material da prxima Sprint e
quando este material chega ao planejamento da Sprint ele possui um nvel de
maturidade maior, para que a equipe possa realizar a analise de sistemas do
mesmo e o seu planejamento de execuo.
Jeff faz a observao que: Pronto e Feito so simples de entender, mas
difcil de ser realizado e O segredo est no balanceamento apropriado entre o
planejamento e a execuo de atividades.
O link do material :
http://jeffsutherland.com/scrum/PracticalRoadmapMunich20091020.pdf
Os requisitos Prontos o que eu chamei neste material de requisitos
quadrados e redondos. Onde um requisito quadrado traz problemas na analise
de sistema, planejamento e execuo. J os requisitos redondos permitem a
sua analise, planejamento e execuo em velocidade e qualidade pela equipe
de desenvolvimento do projeto. Toda vez que um requisito quadrado entra na
execuo da Sprint ele um candidato a gerar impedimentos e
conseqentemente trazer problemas na execuo da Sprint, trazendo impacto
na velocidade de produo da equipe.
- Pgina: 43
- Pgina: 44
- Pgina: 45
- Pgina: 46
Fonte:
http://kw-agiledevelopment.blogspot.com/2008/01/example-of-userstory.html
Observe que o desenho que representa a frente do carto tem os dados
de identificao do carto de histria. Estes dados so: o numero (0001), o
titulo (User Login), a histria do carto (As a [register user]...) e ainda dados
das conversas com o usurio, onde temos um esboo de como deve funcionar
a tela e anotaes do comportamento esperado.
Na segunda imagem ns temos as informaes dos testes
(confirmao), mostrando os cenrios possveis e esperados pelo usurio.
- Pgina: 47
Como um cliente, quero ter acesso a uma rea privada, para que nesta
rea eu possa acompanhar a situao do meu pedido.
Como um cliente, quero ter acesso a uma rea privada, para que eu
possa atualizar os meus dados pessoais
Como um cliente, quero ter acesso a uma rea privada, para que eu
possa ter acesso as informaes de minhas compras anteriores
- Pgina: 48
Administrador do Sistema
Mdulo administrativo
Escopo do Projeto
Vamos fazer a definio das Categorias dos Cartes de Histria. Um
projeto possui um escopo e dentro deste escopo ns temos requisitos do
tamanho de um pico, Tema ou Carto de Histria.
- Pgina: 49
- Pgina: 50
Uma boa pratica sempre buscar o equilbrio das coisas, neste carto
podemos executar 2 tcnicas, onde a primeira gerar vrios cartes menores.
Exemplo:
Como um cliente, quero consultar os livros por titulo, para que eu possa
encontrar o produto que desejo comprar.
Como um cliente, quero consultar livros por ISBN, para que eu possa
encontrar o produto que desejo comprar.
- Pgina: 51
Validar valor do produto maior que zero para evitar produtos sem preo
de venda
- Pgina: 52
- Pgina: 53
- Pgina: 54
Templates de Documentos
Vou apresentar alguns documentos que eu criei para serem utilizados no
nosso dia a dia de Viso do Produto, Planejamento de Sprint, Retrospectiva e
Review.
Estes documentos devem ser adaptados realidade de cada projeto,
apenas uma sugesto de uso.
Embora estes documentos no agreguem valor direto ao produto que
est sendo desenvolvido, eles garantem uma comunicao e um certo
oficialismo na gesto do projeto. Termos o projeto bem documentado traz
confiana entre as partes. A documentao deve deixar claro o escopo, o que
foi acordado por Sprint, as entregas realizadas, as melhorias do processo de
desenvolvimento da equipe, as alteraes de escopo e requisitos e o que for
necessrio. A questo no deixar de documentar ou documentar ao extremo
e sim a busca do ponto de equilbrio que permite o projeto fluir e ao mesmo
tempo termos os registros de como ele esta sendo executado.
Talvez alguns neste momento estejam achando este tpico deste
material inapropriado, mas eu como Gerente de Projetos e j tendo gerenciado
vrios projetos como Gestor utilizando tcnicas do PMBOK ou como um Scrum
Mster de equipe, tenho a convico que melhor documentarmos do que
deixar de lado a documentao. No ter documentao mais cedo ou mais
tarde nos iremos nos arrepender de ter deixado de documentar e quando mais
necessitarmos no ter como recuperar os fatores histricos do nosso projeto.
Viso do Produto
Ata de Viso do Produto
Reunio: __/__/____
Participantes: ________, ________, ________, ________, ________,
Datas Importantes do Projeto
Final do Projeto: __/__/____
Release 1: __/__/____, Release 2: __/__/____, Release 3: __/__/____
Temas Apresentados
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Expectativa de Temas por Release
- Pgina: 55
Participantes
Pessoas
reunio.
Final do Projeto
Release
Temas Apresentados
Identificao de expectativas do
Product Owner. Um bom item para
identificao de critrios de qualidade
do produto.
Riscos Identificados
Alinhamento de Tarefas
que
participaram
da
para o
- Pgina: 56
Planejamento da Sprint #1
Ata: Planejamento da Sprint XX
Data: __/__/____ __:__ / __:__
Participantes: ________, ________, ________, ________, ________,
Release __/__/____
Temas do Release
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Dados da Sprint
Data de Inicio: __/__/____ - Data de Termino: __/__/____
Tamanho da Sprint: __ semanas
TimeBox:
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Capacidade da Equipe: ____ hrs / sprint
Temas / Historias da Sprint
Tema: _______________________________________________
Historia: _______________________________________________
Conversas:
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Tema: _______________________________________________
Historia: _______________________________________________
Conversas:
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
- Pgina: 57
Numero da Sprint
Data
Participantes
Pessoas
reunio.
Release
Temas do Release
Dados da Sprint
que
participaram
da
Planejamento da Sprint #2
No existe necessidade de um documento de registro da Sprint Planning #2.
Caso o desenvolvimento do sistema no seja junto do Product Owner,
softwares podem ser utilizados para mostrar o andamento da execuo do
Sprint Planning #2.
- Pgina: 58
Review
Ata: Review da Sprint XX
Data: __/__/____ __:__ / __:__
Participantes: ________, ________, ________, ________, ________,
Entregas
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
No Aceito ou Observaes
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Review da Sprint XX
Numero da Sprint
Data
Participantes
Pessoas
reunio.
Entregas
No Aceito ou Observaes
que
ter
participaram
entregas
da
no
Retrospectiva
Ata: Retrospectiva da Sprint XX
Data: __/__/____ __:__ / __:__
Participantes: ________, ________, ________, ________, ________,
- Pgina: 59
No Continua
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Melhorar
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Continuar
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Retrospectiva da Sprint XX
Numero da Sprint
Data
Participantes
Pessoas
reunio.
No Continua
Melhorar
Continuar
que
participaram
da
- Pgina: 60
- Pgina: 61