Este projeto é um resumo dos cursos de Projetos ágeis com Scrum realizado na Digital Innovation One, ministrado por Thiago Sano e Diego Pereira e na Voitto, ministrado por Thiago Coutinho. Um conjunto de conceitos, idéias e anotações sobre a teoria e o uso do Scrum no dia a dia.
Framework Scrum by Voitto. Fonte: RUBIN, Kenneth S. Scrum essencial: um guia prático para o mais popular processo ágil. Rio de Janeiro: Alta Books, 2017
Framework ágil para gestão de projetos, extremamente prescritivo, suas principais recomendações devem ser seguidas à risca. Scrum é um framework ágil iterativo e incremental porque seus projetos são desenvolvidos com várias atividades em paralelo, que são integradas quando estão finalizadas. E iterativo porque é desenvolvido em um ciclo de vida de várias iterações. O Scrum é mantido e regulamentado pelas instituições: Scrum Alliance e Scrum.org.
Segundo o Scrum Guide, Scrum é:
- Leve
- Simples de atender
- Difícil de dominar
- Individuos e interações em vez de processos
- Produtos que funcionam em vez de documentação que informa sobre como o produto deve funcionar
- Colaboração com o cliente, em vez de negociação com ele.
- Reponder a mudanças
Planejar é útil, seguir cegamente um plano é burrice, um planejamento deve ser feito no ínicio da Sprint, e a consciência de que "há um novo jogo para o desenvolvimento de novos produtos" deve estar no sangue da equipe.
- Autônomia
- Times multifuncionais
- Autoridade para tomar as próprias decisões
- Hiper produtividade
- Flexibilidade
- Objetivo de negócio
- requisitos
- processo de desenvolvimento
- software
- concepção
- analise/design
- testes
- implantação
- 45 % nunca é usado
- 19 % raramente
- 16 % as vezes
- 7 % sempre
- 13 % frequente
Só permite que o projeto avance quando uma fase esta interiamente completa.
Fases:
- requirement
- design
- implementation
- verification
- maintenance
O Escopo é definido na fase inicial do projeto (preditivo)
- Projeto é controlado por fases e marcos
- Cliente só vê o software funcionando na fase final do projeto
- Resistência a mudanças
- "N" meses, se tiver algo de errado no projeto, corre o risco de descobrir depois de meses.
Software construido por partes (incremental) e cada parte executada em um ciclo (iterativo) com entrega de uma funcionalidade. Focado no minimo produto viável (MVP) e responde mais rápido para o negócio.
Partes
- requisitos
- análise
- construção
- testes
- liberação
O Escopo definido ao longo do projeto (adaptativo)
- Projeto é controlado por funcionalidades entregues
- Cliente pode ver parte do software funcionando na parte inicial do projeto
- Mudanças constantes de acordo com o feedbacks contínuos
- A "cada" mês, se tiver algo de errado, descobre-se que estava errado em no máximo 30 dias.
Ser ágil é diferente de rápido.
- É ser rápido na mudança e desembaraço.
- Fazer coisas complexas de forma simples.
- Equipe comprometida com os objetivos.
- Entregar o de maior valor para o cliente.
Resumo é ter a capacidade de responder rapidamente a mudanças, é priorizar as coisas mais importantes.
Muito iguinorado, porém um dos fatores de maiores ganhos no desenvolvimento de sistemas
Itens que podem afetar o prazo, custo e escopo de um projeto de maneira que pode acabar inviabilizando-o
Scrum cria intervalos regulares de tempo para verificar o Ciclo de inspeção e adaptação.
- Estamos na direção certa?
- É exatamente isso o que o cliente quer?
- O que podemos melhorar
Scrum é utilizado em cenários caóticos. Projetos usando equipes pequenas e multidisciplinares, produzem os melhores resultados. As pessoas não sabem de fato o que querem até experimentar o produto
Scrum- Framework de gerenciamento de projeto ágeis.Time Box- Tempo máximo para fazer uma cerimônias ou Sprint (reuniões).Sprint- Principal evento do Scrum (Corrida , Arancada)Duração de 1 Sprint- 30 dias corridos (ou menos)- Entrega evolutiva
Meios pelos quais o Scrum passa a sensação de felicidade
- Autonomia
- Domínio
- Propósito
Transparência:
- Conversar mais e escrever menos.
- Todos tem conhecimento dos processos e requisitos
- Como está o andamento do projeto
Inspeção:
- Aprender progressivamente com uso do software.
- O que esta sendo feito no projeto, visível no Sprint Review e nas Daily
Adaptação:
- Requisitos mudam ao longo do tempo.
- Demonstrar o software constantemente aos usuários e obter feedbacks constantes.
- O uso de Scrum alcança a hiperprodutividade de 300% a 800%
- Uma pessoa ou Grupo que legitima as ações de uma organização
- Tem papel direto ou indireto na gestão de resultados da organização
- Pode ser afetado positivamente ou negativamente, dependendo das usa politicas e forma de atuação
- O PO se relaciona com os Stakeholders
- O relacionamento é a principal ferramenta do PO
Exemplo de stakeholders
- Funcionários
- Gestores
- Clientes
- Proprietários
- Fornecedores
- Concorrentes
- ONGs
- Estado, sindicato etc..que estejam relacionadas com uma determinada ação ou projeto.
- Épico é objetivo macro que deve ser atingido, e deve ser quebrado em objetivos menores.
- As Estórias são um conjunto de Épicos as tarefas um conjunto de estórias.
- Tarefas é um conjunto de atividades que o time de desenvolvimento deve desempenhar para entregar a estória.
- Uma tarefa é descrita em nível de negócio.
Um exemplo, Levando em conta que as peças já estão prontas vamos ver Épicos do projeto de uma bicicleta e suas estórias e tarefas: Legenda (é)Epicos, (e)estorias, (t)tarefas.
- Quadro (é)
- Garfo (é)
- guidão (e)
- montar guidão (t)
- montar o garfo (t)
- montar o garfo no quadro (t)
- montar a roda no garfo (t)
- montar o sistema de freio na roda (t)
- amortecedores (e)
- guidão (e)
- Celin (é)
- Sistema de freios (é)
- manopla de freios (e)
- Rodas (é)
- Sistema de tração (é)
- pedal (e)
Todas as dependências de tarefas entre outras estórias devem ser mapeadas. Após a priorização do projeto as estórias devem ser quebradas, sendo que os Épicos podem ser quebrado em outros épicos e as Estórias escritas em nivel de negócio.
É uma lista de critérios que precisam ser alcançados para que a User Story atenda os requisitos do cliente e seja aceita pelo Product Owner. Tem o objetivo de definir limites para as User Stories, e ajudar o PO a detalhar em alto nivel o que é necessário para entregar valor ao cliente. Se não tem critério de aceite o PO não entendeu a demanda. Demandantes costumam ocultar o real objetivo da demanda
A técnica mais utilizada para estimativa é o Plannig Poker, feita pelo timeDev, que é de fato um jogo de cartas com as sequência de fibonaci (começa por 0 e 1, o termo subsequente corresponde à soma dos dois anteriores no caso 0,1,1,2,3...), onde as tarefas são lidas e posteriormente as tarefas são criadas. O time vota e é levado em conta o trabalho manual em si o tempo que tarefa leva pra ser concluida.
- Tarefa simples: Voto 1
- Tarefa dificil: voto 13
- Tarefa com nota 20: deve ser quebrada em outras tarefas
- Os membros que derem a maior e menor nota, devem justificar suas pontuações, pois pode ser que tenham pensado alguma coisa que os outros membros não pensaram.
Outra Técnica de estimativa: Modelo de tamanho de camisas
- Os projetos são desenvolvidos e entregue em partes menores de 2 a 4 semanas, com constantes feedback
- Melhor gerenciamento de riscos (redução de incertezas)
- Comprometimento, motivação e transparência da equipe (Daily meeting)
- Maior valor para o negócio (priorização do backlog)
- Usuários envolvidos durante todo o ciclo
- Aplicações das lições apreendidas(melhoria contínua)
- Product Owner
- Scrum Master
- Dev Team
- Sprint (Principal evento do SCRUM)
- Planejamento da Sprint (Sprint Planning)
- Reunião Diária (Daily Scrum)
- Revisão da Sprint (Sprint Review)
- Retrospectiva da Sprint (Sprint Retrospective)
- Product Backlog
- Sprint Backlog
- Incremento/Entrega
A dinâmica do Scrum começa com a visão do produto, sendo o PO o responsável por essa visão - O que ele quer e onde quer chegar. Na release planing de projeto, logo no inicio o PO tem uma demanda muito grande, onde as estórias serão quebradas e ele deve ter o entendimento das funcionaliades de maior valor primeiro.
Visão do produto
Créditos: Eduardo Borges
O Product Owner representa a área de negócios (não é um comitê), Tem poderes de liderança sobre o produto e as responsabilidades de:
- Tomar decisões, sobre data da primeira versão, quais funcionalidades ela vai ter.
- Ficar atento aos feedback dos usuários
- Define as funcionalidades do software (Product Backlog).
- Prioriza as funcionalidades de acordo com o valor do negócio.
- Garante que o time de desenvolvimento entenda os itens do backlog no nível necessário para implementação.
- Tem a visão do que será desenvolvido
- Sabe as necessidades a serem atendidas
- Conhece o público que utiliza os serviços
- Conhece os objetivos a serem alcançados
- Quem visualiza valor que será agregado
- Define a ordem das atividades
- Define as funcionalidades do software
- Responsável por cancelar a Sprint
- Responsável pelo estudo para priorizar caso nenhuma atividade seja possível ser executada.
- Não é chefe do Time de desenvolvimento nem do SM
A principal caracteristica do PO é entender a demanda e extrair o maior valor possível
- Trazer o máximo de valor possível para o produto
- Entender o objetivo do produto e o que ele quer alcançar
- Quem vai utilizar
- Em qual circuntâncias o produto será usado?
- Validar se o produto faz sentido ou não
- Não é obrigado estar nas Daily
- Melhorar as estórias em função do feedback do time de Dev
- Tem a visão se a Sprint está de pé
- Entender o desenpenho da equipe
- O PO é responsável por ficar atento aos prazos
Garante o uso correto do SCRUM (para que a equipe fique autogerenciável) e:
- Garantir que as reuniões sejam feitas
- Não é o gerente de projeto
- Age como facilitador
- Auxilia o Product Owner no planejamento e estimativas do backlog
- Auxilia a equipe a remover impedimentos
- Treina o time em autogerenciamento e interdisciplinas
- O SM é quem faz as 3 perguntas basica O que fez ontem? O que fará hoje? Existe algum impedimento?
- Possui habilidades suficientes para desenvolver, testar, criar e desenhar, tudo o que for necessário para entregar o software funcionando.
- Transcendência
- Equipes capazes de se auto-organizarem
- As tarefas são do time e todos são responsáveis
- Forte comprometimento com os resultados
- Autônomia
- Startups utilizam o framework ágil Scrum
- Faz uso do MVP (Mínimum Viable Product).
- Ter iniciativa
- Ajudar o PO a escrever melhor as estórias
- O time que anda sozinho
- Possue Transparência sobre as demandas que estão por vir
- Inspeciona e questina o PO nas suas estórias
- Se adapta aos novo cenários com facilidade
Time Box - 8 Horas é o tempo máximo para se fazer uma cerimônia.
- Planejamento da Sprint (Sprint Planning)
- Reunião Diária (Daily Scrum)
- Revisão da Sprint (Sprint Review)
- Retrospectiva da Sprint (Sprint Retrospective)
Time-Box: No máximo 8 horas. A Sprint é o principal evento do SCRUM, um periodo de tempo onde as atividades para fazer o produto são executadas, Sprint siguinifica (Corrida, arrancada) e dura até 30 dias corridos ou menos.
Primeira Reunião Refining Time-Box: No máximo 8 horas.
Nas primeiras 4 horas
-
O PO apresenta as funcionalidades e explica os porquês. Refining é a primeira reunião, e participa o PO o SM e Devtime. a Refining não faz parte do Scrum mas aumenta a qualidade da planning, tem o objetivo de informar ao time previamente o que vai ser desenvolvido e tirar dúvidas.
-
A partir do Product BackLog priorizado o PO apresenta ao time o que fazer na Sprint, as estórias que serão implementadas na Sprint que podem ser alteradas, pelo time time que lê, tira dúvidas e confere as estórias.
É uma reunião que envolve o planejamento da Sprint, tem como objetivo revisar o Product Backlog e definir todo trabalho que deve ser executado na próxima Sprint. No final dessa reunião a equipe deve definir:
Nas próximas 4 horas
- Outra reunião é feita, onde participa o SM e Devtime (O PO não deve participar dessa reunião) onde os devs pegam as estórias para analizar a complexidade
- Usam o Planning Poker(ou outra técnica), para estimar tempo das atividades e verificam se todos os pedidos do PO foram atendidos.
- O time de dev pega cada estória para ver qual parte vai ser desenvolvida
- Podem quebrar estórias complexa em outras estórias
- Devolvem ao PO a estimativa, para analise e rearranjo das prioridades
- Para o PO iniciar a criação do Sprint backlog.
O método mais indicado é enterder o ganho primerio e depois definir o escopo.
Forma eficiente de definir o escopo, é inverter a ordem pra entender o objetivo e valor que quer atingir, antes mesmo de definir o como, mais possibilidade irão aparecer e caminhos pra atingir o objetivo. Um caminho a trilhar até o objetivo, usando os feedback do cliente desde o começo e criando um MVP.
Deve-se:
- Inspecionar cada entrega
- Validar com os cliente se o produto esta correto e dentro das espectativas
- Realizar as alterações necessárias mais adequada ao clinte
Time box: 8h Composto por épicos e estórias. E cada produto tem seu backlog. O PO deve dominar o backlog.
- Épicos - incremento sem muito detalhamento, ajuda a te direcionar os caminhos que deve seguir.
- Estórias - Detalhamento dos épicos, um épico normalmente se divide em várias estórias, onde ficam descritos o que deve acontecer e sua regras de negocio.
Nota:
- Tasks - as atividades são definidas no Sprint BackLog pelo time de desenvolvimento e pode haver "n" tasks para uma estórias.
- O PO apresenta as prioridades das funcionalidade a serem implementadas ao time.
- O quê fazer?
- Como fazer?
- Nome da estória
- Descrição da estória ( Eu, como, quero, quando)
- Regras de negocio (Separar regras de front-end e back-end)
- Tela (Link ou imagem das telas a serem desenvolvidas)
- KPI (Quais os objetivos/valor a estória precisa atingir)
- Tagueamento (como a estória será tagueada para poder mensurar os KPI )
- Critérios de aceite (Qual o Passo a Passo de todos os caminhos felizes possiveis a estória deve cumprir para que ela seja considerada aceita)
- Com o Sprint Backlog, o PO devéra validar a prioridade e que considerado o objetivo principal da Sprint
- Estórias mapeadas e atividades escritas
- Quais atividades serão desenvolvidas primeiro
- Quantas funcionalidades cabe na Sprint
- O principal objetivo da Sprint
- O que será entregue no final da Sprint
Reuniões com Time-Box: 15 minutos.
- Somente o timeDev tem obrigação de estar nessa reunião
- Com o objetivo de saber o que falta pra terminar a Sprint e não um status report
- Executada diariamente dentro da Sprint, no mesmo local
- Deve ocorrer sempre no mesmo lugar e no mesmo horário
- Serve para o time saber o que cada um esta fazendo
- O PO e o SM não tem obrigatoriedade de estar nessa reunião
- Presença de todo time de desenvolvimento
3 perguntas básicas:
- O que fiz ontem
- O que farei hoje
- Se tenho algum impedimento É permitido falar qualquer assunto na Daily (sobre o projeto)
Participantes
- PO
- Time desenvolvimento(responde)
- o que fez no dia anterior?
- o que esta programado para o dia?
- tem algum impedimento?
- Scrum Master
-
É
observadoe discutido o que foibomeruimna SprintO que deve ser melhoradoO que não se deve fazer
-
Quais
açõesa seram tomadas- o que
Fazer menos - o que
Fazer mais
- o que
-
Time Dev apresenta para o PO o trabalho feito
-
Uma Retrospectiva da Sprint
- Transparência (comprometimento)
- Reunião da equipe para lições aprendidas
-
Time-Box: 3h - Sprint 30 dias Realizada no último dia da Sprint, tem o objetivo de verificar se a demanda agregou valor ao negócio, sendo apresentada pelo time de desenvolvimento. O Scrum master e o PO devem estar presentes nessa reunião. Cada um pode mostrar o que foi resolvido na Sprint anterior e dúvidas de negócio devem ser tiradas pelo PO.
-
BackLog deve ser atualizado
-
Todos os interesados nas entregas devem estar presentes e validar se esta de acordo ou se houve mudança de fluxo
-
É obrigatório a presença do SM e do time de desenvolvimento
-
Focada na Sprint como um todo
-
Executada uma única vez dentro da Sprint, sempre após a conclusão da Sprint.
Pode ser separada em duas partes(Não obrigatório)
- 1 parte sem o PO
- 2 parte com o PO
- Cerimônia não oficial do Scrum
- Um passo antes da Planing, no final da Sprint anterior
- Objetivo de aumentar o entedimento da demanda
- Como será a próxima Sprint
- Do que se trata a demanda
- Facilitar o planejamento
- Todos devem estar presente
- A estória ja deve ter sido escrita
- Ajuda a facilitar a planing
Liberação ou lançamento de software, um nova versão a cada vez que é criado ou modificado o software, o fabricante e os seus desenvolvedores distribuem os produto as pessoas que o utilizam. Pode acumular várias Sprint pra uma release (não recomendado), mas cuidado muitas Sprint para uma release pode ficar complexa
Obrigações do PO nessa fase:
- Gerência a espectativas do stakeholders
- Definir as maiores entregas de valor
- Organizar as Sprint trazendo mais valor
- Organizar as Release trazendo mais valor ainda
- Quebrar estórias com estregas de valor primeiro
- PO deve acompanhar Deploy e testes
- PO não é gerente de projeto
- PO tira todas dúvidas do time
Squad é o nome dado ao time que roda no método ágil com framework Scrum, e contém de 3 a 9 membros.
- Vários times de desenvolvimento, em uma única release.
- Entregas distintas e times distintos
O gráfico de Burndown junto com o gráfico Burnup, na metodologia Scrum mostra como está a produtividade da sua equipe em relação aos prazos determinados durante a fase de planejamento do seu projeto. Sendo que Burndown mostra o que falta para concluir o projeto.
O Gráfico Burnup mostra a quantidade de trabalho concluída.
Transformação digital:
- é um processo de fazer uso da tecnologia, para melhorar o desempenho, aumentar alcance e garantir resultados melhores.
- Mudança estrutural nas organizações dando um papel essencial para a tecnologia
- Está no objetivo das empresas
- Como o as pessoas podem usar as tecnologias
- Como as pessoas agem e pensam sobre a tecnologias
- Papel do PO é como o conhecimento é dissiminado nas organizações entre os elementos do time
- Orquestrador de comunicação
- Juntar as pequenas partes do produto
- Tem um papel estrátegico dentro das empresas
- É trabalhar junto com o cliente
- Ter a mente focada em atender o cliente da melhor forma possivel
- PO é quem entende a necessidade do cliente
O uso do Kanban Board no Scrum
Créditos: Jorgeaudy.com
O Kanban é um Sistema de gerenciamento de fluxo de trabalho, que controla as tarefas e atualização do status da Sprint Funciona com um facilitador visual das tarefas da Sprint que precisam ser executadas.
Possibilita que o time de trabalho execute suas tarefas com mais clareza e colaboração.
- Facilita a visualização dos riscos do projeto;
- Permite que o Product Owner e o Time de Desenvolvimento visualizem possíveis gargalos.
- Indica produtividade individual de cada membro.
Status Padrão do Kanban
- a fazer
- fazendo
- concluído
Um possível Status para desenvolvimento de software com Kanban
- Solicitado
- Design
- Em desenvolvimento
- Revisão de código
- Pronto para teste
- Em teste
- Aguardando deploy
- Em deploy
- Concluído
Créditos: Site RGV Web
- Escolha um dono do produto
- Selecione o time
- Escolha o ScrumMaster
- Crie e ordene, de acordo com as prioridades, o backlog do produto
- Refine e estime o backlog
- Faça o planejamento do Sprint
- Torne o trabalho visível
- Realize a reunião diária
- Faça a Revisão da Sprint
- Faça a retrospectiva da Sprint
- Comece de imediato o sprint seguinte, levando em consideração as experiências od time na sprint anterior e tudo aquilo que precisa ser melhorado no próximo ciclo.