ALUNO : INACIO CARVALHO DE OLIVEIRA

PRONTUÁRIO : GU3015076

ENTENDIMENTO SOBRE SCRUM :

Papel do PO:
O Product Owner(Dono do Produto) ou PO trata diretamente com o cliente sobre
as funcionalidades que serão Implementadas ao Produto(o Produto também pode ser
chamado de : Projeto/Software/Serviço), o PO tem o conhecimento das funcionalidades e
restrições do Produto em questão, ou seja, ele dá suporte ao cliente informando o que
pode ou não ser desenvolvido dentro das limitações do Software é também responsável
por escrever a história do usuário, coordenar o desenvolvimento dos projetos e
acompanhar tarefas x prazos junto com o Team, ele deve agregar valor ao produto. Sua
atuação vai depender do campo em que o projeto está é claro, Green Field, Brown Field
ou Grey Field.

Papel do Team:
O Team(Time) são os principais responsáveis pelo Desenvolvimento,
Implantação,Ajuste,Manutenção Do Produto em questão, possuem total influência
também sobre o que dá ou não e como deverá ser feito o desenvolvimento da
funcionalidade solicitada pois estão mais próximos dá tecnologia, algorítimo e
conhecimento técnico do Serviço/Software, estando cientes das restrições e
possibilidades do Produto.

Papel do Scrum Master:

O Scrum Master(sinônimo de Facilitador do Projeto), conforme seu sinônimo, o
Scrum Master tem a responsabilidade de facilitar ou Desimpedir problemas que surgem
ao longo do caminho ou seja tanto com a interação com o cliente/desenvolvimento da
tarefa. Scrum Master torna-se um dos papéis fundamentais do Scrum, tendo a
responsabilidade de garantir que o processo seja realizado corretamente, existindo ainda
uma gama muito grande de tarefas atreladas. Scrum Master é como um treinador, sendo
responsável por incentivar toda a equipe, tornando-se o seu guia e assegurando que as
regras sejam seguidas.
Cerimônias:
Daily Scrum:
é uma curta reunião com o time que ocorre todos os dias para alinhar o andamento
das tarefas que foram atribuídas a cada Colaborador a fim de atualizar todos o progresso
da Demanda e identificar se há obstáculos que irão causar impacto na entrega da
atividade, Geralmente leva de 15 a 25 minutos de duração.
Sprint Planning:
É uma reunião que ocorre de 1 vez a cada 1 ou 2 semanas para a organização e
planejamento da semana iniciada para informar e planejar as novas atividades a serem
desenvolvidas juntamente com o alinhamento do tempo que será empregado a cada
demanda.
Review Sprint:
A Review Sprint é realizada ao final de cada Sprint( A Sprint é definida com um
tempo “limite” que visa o recebimento das atividades concluídas das quais foram
alinhadas na Sprint Planning), Nesta reunião o time demonstra tudo que foi desenvolvido.
Normalmente estão na Sprint Review o Product Owner, Scrum Master e Stakeholders do
cliente. No Scrum ao final de cada Sprint é necessário que seja entregue um incremento
de software funcionando.
Retrospective Sprint:
Ao final Da Review Sprint onde já foi entregue tudo o que foi planejado funcionando
ao cliente é feita A Reunião de Retrospectiva, esta reunião é apresentada geralmente
pelo Scrum Master a fim de relatar pontos que poderiam ser melhorados em relação a
Sprint(envolve melhoria no geral, tanto no alinhamento com o cliente/desenvolvimento das
tarefas/entrega no cliente) finalizada. As soluções das possíveis melhorias é dada por
todos do time envolvido a fim de que deem sua visibilidade de como melhorar o processo,
sendo assim, transformando suas visões de otimização do processo em Resultados para
a próxima Sprint.
Artefatos:
Product Backlog:
Se trata propriamente de uma Lista de Log( Log pode ser entendido como um
relatório/lista de atividades que ocorreram ou deverão acontecer ao longo do processo),
ou seja, Product Backlog se trata das atividades que foram atribuídas a cada colaborador
ao longo da Sprint.
Sprint Backlog:
É a lista de Atividades que é atribuída a cada colaborador das quais já foram
alinhadas na Sprint Planning.
Incremento do Produto:
Planning Poker:
O Planning Poker consiste-se em obter a estimativa de tempo por atividade por
meio de um jogo de cartas, onde todos os membros da equipe de desenvolvimento
(programadores, testadores, design e analistas) participem colocando a sua visão de
complexidade, levando em consideração o fator tempo e esforço para pontuar um cartão
e após juntos chegar a um denominador comum na equipe através de consenso. No Jogo
há 13 cartas( 0, ½ ,2 a 21 seguindo a lógica de Fibonacci, e 2 cartas diferenciadas, uma
com o símbolo de Interrogação e outra com o símbolo de uma xícara de café). Pode ser
feita a dinâmica tanto com cartas reais como por plataforma digital.

Burdown Chart:
No contexto de projetos, um Gráfico de Burndown mostra a relação de trabalho a
ser realizado versus o tempo que você possui para fazê-lo. Ele pode ser tão macro a
ponto de englobar todo o ciclo de desenvolvimento de uma release do produto (chamado
neste caso de Release Burndown) ou tão micro a ponto de englobar apenas o trabalho de
uma pessoa, sendo incomum este uso, mas é possível para metas pessoais.
De qualquer forma, o Burndown Chart sempre será um diagrama que deve estar sempre
visível ao time onde o eixo vertical representa o montante de trabalho a ser realizado (que
pode ser o total de horas estimadas ou Story Points) e o eixo horizontal o tempo que
temos para trabalhar (geralmente a duração da Sprint).
Abaixo segue um exemplo onde a Linha traçada Verde é a angulação perfeita entre
Dias/Tempo e a Linha vermelha é a jornada do Team ou Somente o Colaborador no
desenvolvimento das tarefas :