Scrum

Scrum

1. Scrum

   • Nome deriva de uma jogada do Rugby
   • Definição
     • Framework leve e simples de entender
       • Agrega processos, métodos e técnicas
       • Quem usa tem a liberdade de usar o melhor dele de acordo com as necessidades
       • Pode-se fazer uso de "plug-ins"
         • Gráfico burndown
         • Documento de visão
     • Extremamente difícil de dominar
     • Desenvolve e mantem produtos complexos e adaptativos
       • Caraterísticas de um ambiente complexo
         • Sem muita definição
         • Não é muito acoplado
         • Há muitas mudanças
         • Muitas formas de se realizar um trabalho
     • Fundamento em teorias empíricas de controle de processo e emprega uma abordagem iterativa e incremental
       • Para o empirismo, o conhecimento vem da experiência e da tomada de decisões com base naquilo que é verdadeiro e conhecido
       • O empirismo possui 3 pilares
         • Transparência
           • Aspectos significativos devem estar visíveis aos responsáveis pelos resultados
           • Deve haver transparência dentro e fora da equipe
         • Inspeção
           • A ideia é identificar rapidamente qualquer desvio sobre a meta que deve ser atingida
         • Adaptação
           • Caso se constate desvio para limites fora dos aceitáveis, deve-se ajustar o produto
     • O scrum é utilizado no gerenciamento de projetos
   • Papéis
     • Scrum Team
       • Product Owner (PO)
         • Responsável pela macro-gestão e pela gestão do produto
           • Responsável por garantir o Return on Investment (ROI)
         • Responsável por maximizar o valor do produto e do trabalho da equipe de desenvolvimento
           • Único que pode gerenciar o Product Backlog
         • Pode delegar tarefas ao time de desenvolvimento, mas continua responsável pelos trabalhos
         • Responsável por garantir que o Backlog do produto seja visível, transparente, claro para todos
           • Mostra com o que o Time Scrum vai trabalhar a seguir
       • Development Team (DT)
         • Responsável pela micro-gestão e criação do produto
         • Eles são auto-organizáveis
           • Ninguém (nem mesmo o SM) diz ao time de desenvolvimento como transformar o PB em incrementos
           • São organizados e autorizados pela organização para gerenciar seu próprio trabalho
         • São multifuncionais possuindo todas as habilidades necessárias
           • Os integrantes podem ter habilidades individuais, mas a responsabilidade é conjunta
           • O time de desenvolvimento não possui subtimes para atividades como testes ou análise de negócio
           • O Scrum apenas reconhece o papel de Desenvolvedor dentro de um TD
         • Deve ter entre 3 a 9 integrantes (excluídos PO e SM, exceto se eles codificarem também)
       • Scrum Master
         • Responsável pela gestão de pessoas e gestão do processo
         • Ele deve garantir que o Scrum seja atendido e aplicado
         • Atua como um facilitador
           • Ele ajuda a remover os impedimentos sem uso de autoridade
           • Ajuda as pessoas de fora do Tim Scrum a interagir com este
           • Durante eventos, atua para que a reunião flua adequadamente, embora não seja o responsável por sua condução
     • Sobreposição de papéis
       • Um Scrum Master pode ser do DT
       • Um Product Owner pode ser do DT
       • Um Scrum Master jamais pode ser o Product Owner
   • Eventos ou cerimônias
     • Cerimônias não oficiais
       • Reunião de visão
         • Product Owner expõe os detalhes do produto a ser construído a todos stakeholders
         • PO pode usar a técnica do Elevator Pitch Sentence
           • Baseia-se na ideia de que se possa explicar o que é o produto durante a subida de um elevador
           • Usa uma sentença em uma estrutura pré-definida para explicar o produto
       • Release Planning Meeting
         • Reunião que planeja detalhes para colocar uma release em produção
           • Restrições e preocupações
           • Dependências, como datas importantes, itens contratuais e logística
     • Cerimônias oficiais
       • Características
         • Todos eventos são time-boxed, ou seja, com duração máxima predefinida
           • Criar uma rotina e minimizar a necessidade de reuniões não definidas pelo Scrum
         • Uma Sprint dura de 2 a 4 semanas
           • Ela se inicia imediatamente após a conclusão da sprint anterior
           • Pode ser cancelada apenas pelo PO antes e seu time-box terminar
       • Sprint Planning
         • Planeja o que será entregue como resultado do incremento da próxima Sprint
           • Dentro das estórias mais prioritárias do Product Backlog
           • Product Owner prioriza as estórias que entregam mais valor ao negócio do cliente
             • Uma estória muito grande é chamada de épico; uma estória maior ainda, de Saga
         • Determina como o trabalho necessário para entregar o incremento será realizado
           • O esforço de desenvolvimento de cada item do backlog é estimada através do Planning Poker
             • Planning Poker é uma técnica de estimativa por comparação
             • O desenvolvedor pontua as estórias usando alguma sequência como Fibonnacci
             • Todas as pontuações devem ser mostradas ao mesmo tempo para não ter influência
             • O Planning Poker não está no guia oficial do Scrum, mas tem sido usado com frequência
           • Após estimativa, o time de desenvolvimento escolhe as estorias que comporão o Sprint Backlog
             • Diferente do Product Backlog, que contém todas as estórias, o Sprint Backlog contém apenas as estórias escolhidas para a Sprint
         • Dura até no máximo 8 horas
       • Daily Scrum
         • Busca criar um plano para as próximas 24 horas
         • Inspeciona o trabalho desde a última reunião diária
           • Verifica o que fiz, o que farei e se há algum obstáculo para atingir a meta da Sprint
           • Pode contar com o PO e o SM, mas é uma reunião para o time de desenvolvimento
           • Ajuda a melhorar a comunicação entre os integrantes
         • Dura no máximo 15 minutos
       • Sprint Review
         • Ocorre no final da sprint
         • Inspeciona o que a equipe de desenvolvimento produziu e colher opiniões e impressões dos presentes
           • Momento em que o PO valida ou não o incremento entregue conforme a meta da Sprint
         • Tem duração proporcional a 4 horas
       • Sprint Retrospective
         • Momento do Scrum Team inspecionar a si próprio e criar um lano de melhorias para a próxima sprint
         • Foca em implementar um plano para melhorias no trabalho
         • Tem duração proporcional de 3 horas
   • Artefatos
     • Artefatos oficiais
       • Product Backlog
         • É uma lista ordenada (por valor, risco, prioridade, etc) criada pelo Time Scrum de requisitos que o produto deve conter
           • Apesar disso, apenas o PO pode priorizá-lo e manipular seus itens
         • É dinâmico nunca estando completo e sempre podendo ser evoluído
         • É descrito por estórias de usuário
           • Pode, porém, representar os elementos autrement
         • Contém diversos elementos
           • Itens de negócio (ou funcionais)
           • Itens não funcionais
           • Itens arquiteturais
           • Itens de infraestrutura
         • Trabalha com o conceito de Definition of Ready (DoR)
           • Determina quando uma estória possui informações suficientes para ser desenvolvida
           • Parâmetro usado pelos desenvolvedores aceitar desenvolver uma estória
       • Sprint Backlog
         • Itens selecionados para desenvolvimento em uma Sprint. Gera um incremento
           • Possui como objetivo atingir a meta da Sprint
           • As estórias são traduzidas em tarefas técnicas
         • Em qualquer ponto do tempo na sprint, o total do trabalho remanescente dos itens pode ser somado
         • Só pode ser modificado pelo time de desenvolvimento
       • Product Increment
         • Resultado do trabalho feito pela equipe de desenvolvimento em uma Sprint
         • Deve ser algo potencialmente entregável
           • O cliente pode colocá-lo de imediato em produção ou não
         • Trabalha com o conceito de Definition of Done (DoD)
           • E um checklist de critérios acordados apra que o Product Owner possa aceitar uma funcionalidade
           • Uma funcionalidade só é considerada pronta se tiver passado por todas as etapas definidas pela equipe de desenvolvimento
           • O amadurecimento organizacional e a habilidade do time de resolver impedimentos podem exigir ajustes nesta definição
           • Diferentemente do Definition of Ready, é imperativo haver um Definition of Done.
     • Artefato não oficial
       • Gráfico Burndown
         • Torna visível a evolução diária do trabalho da equipe de desenvolvimento
         • Compara o trabalho estimado inicialmente com a quantidade restante estimada de trabalho
         • Via de regra, s nidades utilizadas ão e esforço (em horas) planejado pelo tempo decorrido
   • Ciclo de vida do Scrum
     • Pré-Planejamento (Pre-game Phase)
       • Define o sistema sendo desenvolvido
       • Cria-se o Product Backlog
       • Cria-se também uma arquitetura de alto nível
     • Desenvolvimento (Game Phase)
       • O sistema é desenvolvido em sprints
         • Por meio de uma abordagem iterativa
       • A cada sprint, novas funcionalidades são adicionadas de modo tradicional
     • Pós-Planejamento (Post-game Phase)
       • Após o desenvolvimento são feitas reuniões para analisar o progresso do projeto e demonstrar o software atual para os clientes
       • Aqui são feitas as etapas de integração, testes finais e documentação