O quadro Kanban é um sistema ágil e visual utilizado para gerenciar a produção e/ou executar tarefas. ... Como citado anteriormente, foi desenvolvido pela Toyota para utilização em linhas de produção.
A técnica Kanban tem como princípio básico o conceito Just in Time. Em resumo, corresponde ao conceito da eliminação de estoques através da solicitação de quantidades exatas de materiais no momento exato de sua produção ou fabricação.
Backlog: Essa lista é onde as tarefas de projetos são alocadas em cartões individuais. A lista também reúne tarefas que o time pode querer trabalhar ou nas quais precisará trabalhar no futuro, mas que ainda estão sendo avaliadas e não devem ser movida para a lista "A Fazer".
Como foi dito, backlog, também conhecido como backlog de produto ou “product backlog”, é uma lista que contém breves descrições de todas as funcionalidades desejadas para um produto específico ainda não atribuídas a um responsável.
O backlog é uma lista de tarefas que tem um determinado prazo para ser entregue. Simples assim. É possível acompanhar de perto o andamento de cada projeto, fazendo com que o trabalho seja organizado por etapas, como um fluxograma de processo.
Se temos um backlog crescente, tendendo ao infinito, temos duas situações típicas: Houve um crescimento na demanda de serviços. Podendo ser oriundo de um alto número de solicitações de manutenção sendo aprovadas ou da falta de confiabilidade de alguns equipamentos.
A grosso modo, Backlog é uma “pilha de pedidos” em espera. Backlog também pode ser uma medida de tempo (dias, horas etc) que representa o período em que uma determinada força de trabalho (equipe) pode finalizar uma determinada carteira acumulada de serviços.
Como fazer o Product Backlog
O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. ... Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog.
Normalmente, a equipe e o Product Owner (dono do produto) escrevem e priorizam os itens iniciais do Product Backlog, sendo esses itens suficientes para que a equipe inicie a primeira iteração. O Product Backlog irá crescer e mudar à medida em que se aprende mais sobre o produto e sobre o cliente.
Basicamente, o Sprint backlog é uma lista de atividades que precisam ser feitas durante uma sprint. No início de cada Sprint, olha-se para o Product Backlog e “puxa-se” o que será feito no Sprint. Essas “histórias” do Product Backlog, são agora desmembradas em atividades para serem executadas no Sprint (Sprint Tasks).
Quando e como? O Sprint Backlog é criado durante a Reunião de Planejamento, onde os três papéis do Scrum estão envolvidos. Nesse momento, os itens de Backlog que serão considerados já devem estar preparados, e deixá-los preparados é tarefa do Product Owner.
O sprint é uma ferramenta para atingir objetivos em um determinado período de tempo – de preferência, em ritmo acelerado. Para isso, ele ajuda a organizar o desenvolvimento de um projeto ou de um problema ao dividi-lo em tarefas menores que devem ser cumpridas normalmente ao longo de uma, duas ou três semanas.
O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.
Modificação no Backlog é prerrogativa do Scrum Master, quando achar necessário, em qualquer momento no decorrer do Sprint. Não é possível dissolver um Sprint. Se houver algum risco de ele tomar um rumo não desejável, novas funcionalidades devem ser implementadas para garantir o prazo do projeto.
Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master. A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto.
Além desse reforço no papel do líder servidor, na parte que descreve os serviços que o Scrum Master presta ao Product Owner, foi adicionado o item: “Assegurar que metas, escopo e domínio de produto sejam entendidos por todos na Equipe Scrum, tanto quanto possível” [3].
O Product Owner. Que frase melhor descreve a principal responsabilidade do Product Owner? Gerenciar o projeto garantindo que o trabalho esteja de acordo com os compromissos estabelecidos com os clientes do projeto. Otimizar o retorno sobre o investimento do trabalho realizado pelo Time de Desenvolvimento.
ScrumMaster eficaz. O ScrumMaster pode ser a diferença entre o sucesso e o fracasso de uma iteração ou de um projeto como um todo.
Product Backlog - Oferecer o máximo valor comercial em um período de tempo mínimo é uma ideia que já está arraigada no Scrum.
O Scrum tem três papéis: proprietário do produto, mestre do Scrum e membros da equipe de desenvolvimento. Embora esses papéis sejam bastante claros, o que fazer com os cargos já existentes pode ser um pouco confuso. Muitas equipes perguntam se precisam mudar os cargos quando estão adotando o Scrum.
Ele age como um coach para o Time Scrum, tirando qualquer dúvida e ajudando a resolver problemas que podem aparecer, e também para o Product Owner, para que ele consiga ter uma boa visão do objetivo e como priorizar certas informações no Scrum Backlog de acordo com sua importância.
O Scrum Master atua como facilitador do Daily Scrum (reunião diária da equipe) e torna-se responsável por tirar as dúvidas que sejam levantadas pela equipe durante essas reuniões.
Para que serve o planning meeting e qual a duração dessa reunião, assumindo um Sprint de uma semana? No Scrum, toda Sprint começa com uma reunião para entendermos os itens a serem feitos, planejarmos o que cabe no tempo disponível e definirmos a meta para o time nessa Sprint.
Visão geral. A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.
Até mesmo a reunião diária possui o "Time Box" de 15 minutos, não importando o tamanho da sprint. É importante respeitar cada janela de tempo para que o avançar de tempo de um não interfira no andamento do outro.
O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da Sprint. Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade.
Isso otimiza a colaboração e a performance do time através da inspeção do trabalho desde a última Reunião Diária, e da previsão do próximo trabalho da Sprint. ... Essa reunião serve principalmente ao Time de Desenvolvimento entender o que precisa ser resolvido para atingir o objetivo da Sprint.