Please enable JavaScript.
Coggle requires JavaScript to display documents.
Técnicas Complementares de Scrum - Coggle Diagram
Técnicas Complementares de Scrum
Scrum pocker
História
O Planning Poker surgiu em 2002, quando a metodologia
Scrum já existia. Este método possibilitou que o time de desenvolvimento atingisse mais facilmente o consenso de esforço de estimativas sobre cada item.
O que é
O Planning Poker é uma técnica utilizada na reunião de planejamento da Sprint que tem como objetivo realizar a estimativa de esforço sobre as tarfeas do backlog do produto. Dessa forma, a ferramenta possibilita pontuar e classificar as tarefas com um sistema de números utilizando o conceito de escala Fibonacci por meio de um baralho. A estimativa é realizada de forma consensual entre os membros do time de desenvolvimento.
Product Owner / Dono do produto: esse é o principal responsável por ser o canal de comunicação entre os interessados na criação do produto e o time que irá desenvolver o produto. O Product Owner (PO) levanta as necessidades do negócio e cria as histórias de usuário (descrições das funcionalidades listadas do backlog do produto). Além disso, o PO é responsável por conduzir as cerimônias mais importantes do Scrum junto com o Dev Team e o Scrum Master. Dentre essas cerimônias, o PO conduz a Sprint Planning, apresentado os itens prorizados do backlog do produto para que os desenvolvedores possam utilizar o Planning Poker.
Dev Team/ Desenvolvedores: responsáveis pelo desenvolvimento dos itens do backlog.Esses são os profissionais que realizam de fato a estimativa de esforço nos itens apresentados pelo Product Owner na reunião de planejamento (com o Planning Poker).
Scrum Master: estabelece o Scrum conforme definido no Guia do Scrum.Esse profissional ajuda todos a enteder a terioa e a prática do Scrum, tanto no Scrum Team quanto na organização. Normalmente a participação do Scrum Master em estimativas não e obrigatória é, quando participa, fica mais com o papel de ouvinte.
Moscow
Caracteristicas
Tenho que fazer (Must have) Essa classificação compreende
os requisitos que são indispensáveis para a entrega. Elas são
aquelas tarefas que vão agregar valor ao produto final, ao
atendimento de requisitos, ou ainda, garantir o compliance da
empresa. Ainda, esses itens são os que, se forem atrasados,
todo o produto final atrasará em consequência disso.
Devo fazer (Should have) Os itens que recebem esse rótulo
são os que são importantes, mas não são vitais do ponto de vista estratégico para o produto final. Isso significa dizer que
eles não são críticos e que as necessidades do cliente podem ser atendidas de outra maneira, ou ainda, que se pode
esperar um pouco mais para fazer essa entrega.
Poderia fazer (Could have) As tarefas desse tipo são as
desejáveis, mas também não são essenciais do ponto de vista estratégico da entrega e da satisfação do cliente. Então,
essas tarefas são as que podem ser atendidas quando houver tempo e também quando houver recursos disponíveis para
poder finalizá-la.
Não será feito (por enquanto) (Wouldn’t have) Os itens que
recebem essa classificação são aqueles que ficam acordados
entre o time e os stakeholders que são do tipo menos críticos,
com menor retorno do investimento do produto final. Além disso, podem ser também vistas como não sendo adequadas
para serem realizadas por algum tempo. Por meio dessa
classificação, é possível evitar o crescimento desorganizado
do escopo do projeto, o que confunde os desenvolvedores
O que é
O Método MoSCoW é uma técnica usada em gestão, análise
de negócios, desenvolvimento de software e gerenciamentosde projetos. Ela é utilizada para definir a prioridade e a
importância das tarefas que compõem um projeto.
Kanbam
O kanban é uma palavra de origem japonesa que significa
“cartão” ou “sinalização”. Permite um controle detalhado de produção com informações de quando, quanto e o que
produzir. Indica o andamento dos fluxos de produção em empresas de fabricação em série.
História
O kanban foi criado pelo engenheiro japonês Taiichi Ohno em
Ohno, quando era diretor da Toyota, foi até os Estados Unidos para fazer um benchmark com a Ford e conhecer o
sistema de produção em massa mundialmente conhecido como Fordismo.
Caracteristicas
Comece com o que você já faz hoje. O método Kanban não
prega revolução, e sim evolução. Então mapeie o seu fluxo de
valor atual. Não existe certo ou errado, tudo depende do
contexto. Seu contexto dirá se o processo funciona em sua organização ou não.
Busque mudanças evolucionárias e incrementais. Após trabalhar
um período com seu fluxo de valor mapeado, busque pequenas mudanças. Seja curioso e faça experimentos com base em
hipóteses formuladas através da observação do comportamentodo sistema. A prática do Kaizen incentiva a busca da melhoria
contínua. É um processo sem fim, no qual sempre estamos melhorando de alguma forma.
Respeite a estrutura atual, seus papéis, responsabilidades e
cargo. Não mude drasticamente a forma como sua organizaçãoestá estruturada, mesmo que você ache que essa estrutura
esteja atrapalhando o fluxo de valor. É muito provável que boa parte dos processos atuais simplesmente funcione. Lembre-se:
faça melhorias evolutivas e não seja disruptivo.
Incentive atos de liderança em todos os níveis. Algumas das
melhores lideranças vêm de atos cotidianos de pessoas na linha de frente de seus times. É importante que todos promovam uma
mentalidade de melhoria contínua, a fim de atingir o desempenho ideal em um nível de time, departamento ou
empresa.