Please enable JavaScript.
Coggle requires JavaScript to display documents.
Papéis do Scrum, istockphoto-538335180-170667a, 7f78e3127f, Product…
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Ele carrega toda a visão do negócio, regras, expectativas que o cliente espera do produto
-
Ter habilidade com pessoas, resolver conflitos, intermediador
A responsabilidade de construir o produto, mesmo ele não construindo mais ele tem a responsabilidade de entregar o produto, ele fez o acordo com o cliente, ele assumiu expectativa do cliente, por isso assume essa responsabilidade
Definir com o cliente o escopo, não deixar o cliente viajar, para que seja possível fazer a entrega do produto para o cliente
Planejar possíveis entregas, prazos...
-
Ajudando a empresa entender o projeto, se é lucrativo para empresa, prazos...
-
Treinador, evitando falhas da equipe, orientando os integrantes, evitando que seja burlado a metodologia
-
Scrum master não é chefe, ele serve para ajudar os integrantes da equipe
Ele conhece todos os processos do scrum, ele é referencia máxima de scrum
Mantem a moral e animo da equipe sempre alta, evitando problemas como corporativos
Limpa a bagunça, de algo que possa não dar certo para concluir o projeto
Entendendo novas metodologias, para integrar a equipe, pois tech muda e precisa se atualizar para melhorar a equipe
-
-
-
-
-
-
Back, front, qualidade, testes, mobile, designer, prototipagem
Total liberdade para se organizar, a equipe decide como vai trabalhar
-
-
-
-
-
-
-
-
-
-
Product Owner entra em contato com o Stakeholders para fazer as reuniões entender o que o cliente quer e precisa para dai gerar a lista de requisitos
-
-
-
Definir a lista de requisitos e quais precisam ser entregues com prioridades assim visto com o cliente
Gerar visão geral do produto, é passado para equipe de dev gerar o produto
-
O PO apresenta para o Dev Team todo o product backlog todas as funcionalidades, todos os requisitos, mostrar todo o sistema
-
-
Supervisionando para evitar ocorra algo errado, e prestar ajuda e que o fluxo não seja interrompida
-
-
Uma analise mais técnica, como vamos desenvolver isso?, qual tecnologia?, quem vai ficar com tal coisa
-
Definir quais funcionalidades serão feitas na sprint vigente, próximas sprints
-
-
É uma lista das funcionalidades de uma forma ja mais detalhada e priorizada que será desenvolvida na sprint
Story (descrição), Estimativa (pode ser dias, horas...) e Prioridade (prioridade para o cliente)
-
-
-
-
-
-
Precisa entregar para o cliente algo usável em até 4 semanas por isso pegar funcionalidades que são prioridades e que faça sentido para construir algo usável nesse tempo
-
Divide o a sprint, por exemplo se o projeto vai durar 4 meses divide em 4 sprint
-
-
-
-
-
Reunião para o Dev Team, onde a equipe de dev se encontra para traçar estratégias para construção do software dentro da sprint - analisar o projeto diário
-
-
-
Que se faça em pé em caso presencial, para não se acomodar a ideia é ser rápido
-
-
Quais obstáculos estão em seu caminho, falar se houve alguma dificuldade
-
3 PILARES - Inspeção, transparência e adaptação
Evitar devs falando que um está fazendo mais que o outro, assim sabendo o que o outro está fazendo evita de acontecer desmotivação da equipe
-
-
-
-
-
-
O Dev Team vai apresentar para o PO o novo incremento para que ele possa analisar e ver se está de acordo com o que o cliente espera
Após PO analisar o projeto, ele vai apresentar para o cliente e se o cliente falar OK então esse incremento pode subir para produção
Algumas literaturas diz para apresentar diretamente para o PO e cliente porem acredito não ser a melhor estratégia. Pois podemos analisar internamente primeiro e levar para o cliente algo concreto de aceitação
-
Proporcional ao tempo da Sprint de Dev, então supondo que durou 4 semanas pode ser 4h de apresentação pois tem bastante coisa para apresentar, se foi duas semanas 2h....
-
-
Fazer uma retrospectiva de tudo o que aconteceu no clico onde tudo vai ser pontuado, se alguma cosia falhou, se alguma cosia deu errado e o que pode ser melhorado
-
-
-
-
-
-
Em cada sprint do projeto ir criando um produto mínimo em que o usuário já possa ir usando e ir incrementando de sprint a sprint até que o produto final sejá entregue
-
É uma maneira mais humana, mais fácil de definir a lista de requisitos, as funcionalidades que o Product Backlog garante
-
-
Como um vendedor, gostaria de consultar o estoque de um determinado produto para oferecer a um cliente
Como um Diretor, gostaria de obter o volume de vendas do mês para acompanhar o atingimento de metas
-
É focado na ação, na necessidade do usuário
-
É técnica de estimativa de tempo de funcionalidades para ser utilizada na sprint planning para ver se aquela funcionalidade cabe dentro da sprint e se o responsável vai conseguir dar conta
É uma estratégia gameficada para não ficar uma reunião muito maçante, cansativa
De maneira resumida, no planning poker cada membro da equipe recebe um conjunto de cartas, com os valores de uma determinada sequência.
Em seguida, a cada estória de usuário analisada, cada membro da equipe joga uma carta com a face para baixo sobre a mesa, nela estará contido o valor numérico de pontos que o mesmo considera justo para que a estória seja concluída.
Caso haja grandes diferenças entre as cartas jogadas, os membros que jogaram as cartas de maior e menor valor explicarão suas razões e, então, com base em suas explicações, as cartas são jogadas novamente até que um consenso seja encontrado e uma estimativa seja definida.
-
Assim sendo que uma carta de valor 8 jogada em uma funcionalidade X quer dizer que ela é mais demorada de ser desenvolvida em uma funcionalidade com a carta do valor 3 por exemplo
-
Onde o café é para ser pensado melhor onde talvez surja uma duvida alguma variável que deve ser pensada pois não tem certeza de fazer uma estimativa para aquela funcionalidade
Exemplo na construção de uma casa onde um como é mais difícil de construir do que o outro então vai se dando pontos para qual é mais fácil e mais difícil
-
Um quadro para controlar se as funcionalidades estão sendo feitas dentro do prazo de entra da sprint
-
Primeiro precisa passar pela separação do Product Backlog e priorizar as funcionalidades que serão desenvolvidas primeiro
-
-
-
-
É dividido em duas partes, linha vertical são os pontos, linha horizontal são os dias da sprint, tem duas linhas a estimativa e o real que esta acontecendo que vai ser desenhada conforme os dias for se passando
Então imagina que se tem 6 funcionalidades e cada uma tem uma pontuação, então faz a soma de todos os pontos das funcionalidades e divide conforme os dias da sprint e vai diminuindo os pontos conforme a funcionalidade, então imagina que deu 70 pontos e a primeira funcionalidade tem 15 pontos a partir do momento que foi feito ela o gráfico cai para 55 pontos e assim vai até zerar
-
Quando mais a linha real estiver abaixo da estimado melhor a equipe de desenvolvimento está trabalhando
-
-
-
-
-
-
-
-
Esse quadro ajuda a saber se tem muitos cartões em uma determinada coluna para saber se está havendo gargalo ali para poder melhorar
-
-
Dividir tarefas que tem dependências de outra tarefa, por exemplo você quer cadastrar um usuário no banco porem o banco ainda não está pronto
Dividir tarefas que podem ser feitas sem dependência, e as que dependem de alguma outra, então para tal tarefa ser feita precisa ser feita alguma outra primeiro assim pode saber quais tarefas vão ser construídos primeiros
Para não ocorrer problema de fazer uma funcionalidade e não ter como seguir com ela pois ela depende de outra para continuar assim ficando ocioso aquela funcionalidade tempo perdido
