O que é o scran final scran é um Framework simples para gerenciar projetos complexos ficou complexo isso né ok Deixa eu te explicar melhor então como eu posso saber se o meu projeto é complexo bastante para usar scran esse gráfico mostra uma relação entre o conhecimento dos requisitos e das tecnologias envolvidas no projeto quanto mais conhecemos os requisitos e a tecnologia usada mais previsíveis são as atividades necessárias para realizar o projeto então quando temos domínio da tecnologia e temos um bom conhecimento dos requisitos podemos usar metodologias com processos bem definidos como por exemplo as metodologias
em Cascata onde uma fase é iniciada após a outra agora conforme a gente conhece menos os requisitos ou conforme a tecnologia vai sendo mais complexa o que dificulta o domínio da mesma temos um cenário caótico e é neste cenário caótico que o scrum é melhor aplicado agora se você não conhece os requisitos tampouco a tecnologia temos uma Total anarquia e aqui é impossível realizar projeto o scram possui três pilares fundamentais primeira a transparência a transparência no scran é muito Evidente todos T conhecimento dos requisitos dos processos e do andamento dos projetos o segundo Pilar é
a inspeção o tempo todo é inspecionado que está sendo feito no projeto seja nas reuniões diárias ou no Sprint review e por fim a adaptação você vê a adaptação no scran de duas formas primeiro o produto que está sendo construído no projeto sofre adaptação constante conforme as mudanças vão acontecendo segundo desde que preservados os valores e práticas Você pode adaptar o acesso do scram pra realidade da sua empresa além dos três pilares temos as práticas fundamentais para adoção do scram primeiro os três papéis básicos product owner scrum Master e Dev team se não tiver esses
três papéis não tem scram depois os eventos básicos planejamento do Sprint a execução do Sprint as reuniões diárias a revisão do Sprint e a retrospectiva e por fim estes são os artefatos gerados o prod backlog o Sprint backlog e a entrega parcial do produto vamos entender melhor o que é cada um desses itens primeiros papéis o product honer é o Ponto Central com poderes de liderança sobre o produto Ele é o único responsável por decidir quais recursos e funcionalidades serão construídos e qual a ordem que eles devem ser feitos é responsabilidade dele manter e comunicar
a todos os outros participantes uma visão Clara do que a equipe scram está buscando alcançar no projeto é ele quem prioriza os itens do Product backlog o scrum Master é o responsável por ajudar a todos os envolvidos a entender e abraçar os valores princípios e práticas do scram ele tem que conhecer muito bem o scram o papel dele é agir como um Coach executando a liderança do processo E ajudando a equipe a desenvolver sua própria abordagem do scrum o scrum Master também tem um papel de facilitador ele não é chefe de ninguém por fim o
Dev team o Dev team são as pessoas que de fato vão construir o projeto no scram quem decide como fazer as coisas é o time e não o gerente ou qualquer outra pessoa a ideia principal é que a equipe equipe se auto Organize para determinar a melhor maneira de realizar o trabalho para atingir a meta estabelecida pelo produ owner e como funciona a dinâmica do scrum tudo deve começar com a visão do produto o produ honer é o responsável por prover esta visão que pode ser um Business case e um blueprint de projeto ou qualquer
outro tipo de macr planejamento o importante é que Descreva o que ele quer e Onde quer chegar em seguida deve-se desmembrar esta Visão em todas as funcionalidades que são necessárias esta lista de funcionalidad é chamada de product backlog o scrm atuando como Coach axilia o produ owner nessa tarefa estas funcionalidades são ordenadas por prioridade entenda aqui prioridade como aquilo que agrega mais valor ao negócio Essa priorização é responsabilidade do Product owner para fazer isso novamente não tem um template um modelo ou qualquer definição específica de como fazer algumas pessoas fazem isso no Excel outras usam
sistemas específicos e resumo faa do jeito que for melhor para você o importante é ter de alguma forma uma lista de requisitos priorizada o projeto é planejado em sprints que são períodos de tempo Onde alguns itens selecionados do prod backlog Serão construídos e entregues para planejar os sprints devemos obedecer uma outra regra básica do scrum que são os eventos de duração fixa também chamados de Time Box o que isso quer dizer que o ideal é que todos os sprints tenham uma duração fixa e que tenham a mesma duração normalmente os sprints TM duração entre duas
e 4 Semanas antes de cada Sprint começar é feita uma reunião de planejamento dos sprints também chamada de Sprint planning onde é criado o backlog da Sprint com base na capacidade e velocidade da equipe scrum é definido quantas funcionalidades podem ser completamente construídas no tempo do Sprint vamos entender então como funciona essa dinâmica primeiro o backlog priorizado é selecionad as funcionalidades que serão feitas durante o Sprint depois do término do Sprint é esperado que um incremento do produto seja entregue se for um sistema uma parte funcionando do sistema deve ser entregue neste momento é importante
notar que os próximos itens a serem desenvolvidos não foram escolhidos de forma aleatória e sim seguindo a ordem de importância definida pelo produt oner conforme os incrementos de produto vão sendo entregues o produt owner pode verificar necessidades de mudanças essas mudanças devem ser inseridas também no backlog em sua devida prioridade esse processo então será repetido até que todo o backlog seja construído e o produto final esteja pronto contemplando todas as mudanças solicitadas todo dia é feito uma reunião de 15 minutos onde cada membro do time deve responder a três perguntas básicas o que eu fiz
ontem que ajudou o time a atingir a meta do Sprint o que eu vou fazer hoje para ajudar o time a atingir a meta do Sprint e Existe algum impedimento que não permita a mim ou a Time atingir a meta do Sprint ao responder essas três questões todos conseguem visualizar de uma maneira geral como está progredindo o trabalho do Sprint uma ferramenta muito útil que não faz parte do sprun mas é usado em 90% dos projetos é o Burn Down chart esse gráfico funciona assim ele relaciona os itens que você tem a fazer com o
tempo que vai demorar para fazer tudo neste exemplo vamos simular o Burn Down de um sprint com 17 histórias ou funcionalidades o caminho ideal é que no decorrer do tempo até o final do Sprint todas as histórias tenham sido entregues restando zero histórias a fazer esta é a linha de progresso ideal no qual devemos comparar o realizado para saber se o Sprint está caminhando bem ou não vamos simular agora as 17 histórias e traçar a linha real do projeto Imagine que conforme os dias vão passando você consegue entregar seis histórias e ficar com 11 histórias
restantes neste exemplo como a linha está abaixo da linha ideal significa que neste momento o seu Sprint está adiantado Ou seja entregou mais do que era esperado para este momento Se continuar assim terminaria antes da data planejada porém imagine agora que no passar dos próximos dias você consegue terminar mais uma história somente ficando com 10 restantes e acima da linha ideal Isso significa que você está atrasado Ou seja não conseguirá terminar tudo a tempo se continuar neste ritmo mas com base nesta informação a equipe acelera no final e consegue entregar tudo até um pouco antes
do tempo outra ferramenta muito útil é o canan board canan também não faz parte do scrum mas o scram pode se beneficiar muito do quadro de kamban para promover a gestão à vista e a transparência A ideia é que se possa visualizar aqui o fluxo de trabalho que está sendo feito Este quadro pode ser feito tanto usando softwares próprios para isso como até mesmo uma lousa ou parede onde se possa colar os postites que representam cada uma das funcionalidades do backlog no final do Sprint Existem duas atividades adicionais que são fundamentais uma delas é chamada
de Sprint review o objetivo desta atividade é validar e adaptar o produto que está sendo construído é verificar se o que está sendo feito está de acordo com o esperado é a apresentação daquilo que foi feito no Sprint e é aqui que surgem as mudanças e é aqui que o product backlog é atualizado enquanto o objetivo do Sprint review é verificar necessidades de adaptação no produto a retrospectiva tem como objetivo verificar necessidades de adaptação no processo é aqui que a gente vai ver o que foi feito que foi positivo e o que que foi feito
que foi negativo o que devemos melhorar e o que devemos parar de fazer para entender o fluxo todo temos essa figura que é bem conhecida Tudo começa com a visão ou esboça Inicial isso se desdobra em um prod backlog esse backlog sofre grooming que é a sua priorização ou Estimativa de tamanhos depois durante o planejamento do sprints cria-se o Sprint backlog que é a lista de histórias que serão criadas durante o Sprint o Sprint tem entre duas e quatro semanas e todos os dias no mesmo lugar e horário o Daily screen acontece com as suas
três famosas perguntas e ao final do Sprint temos o produto ou funcionalidade concluída É isso aí se você se interessou e quer saber mais sobre scram acesse www.mindmaster.com.br Obrigado e seja ágil
