Métodos Ágeis 2

Métodos Ágeis 2

1. 4 - Scrum Princípios Básicos

   • Metodologia que foca em analisar a melhor estratégia para execução, documentação e entrega para alcançar um objetivo
   • Sprint
     • Consiste em intervalos fixos de tempo, em que todo o trabalho é realizado
     • Um Sprint tem duração aproximada de trinta dias
     • Durante um Sprint a equipe Scrum se organiza para produzir um incremento do produto
     • O trabalho conduzido dentro de um Sprint é adaptado ao problema em mãos e é definido e, frequentemente, modificado em tempo real pela equipe Scrum
     • A quantidade de Sprints varia dependendo da complexidade e do tamanho do produto
   • Princípios
     • Pequenas equipes são organizadas de modo a maximizar a comunicação e compartilhamento de conhecimento tácito e minimizar supervisão
     • O processo precisa ser adaptável e produz frequentes incrementos de software que podem ser inspecionados, ajustados, testados, documentados e expandidos
     • O desenvolvimento é dividido em partições claras, de baixo acoplamento ou em pacotes
     • Testes e documentação constantes são realizados à medida que o produto é construído
     • O processo fornece a habilidade de declarar o produto “pronto” sempre que necessário
   • Ciclo de Vida
     • Pre-Game
       • Estabelecer a visão
       • Alinhar expectativas
       • Product Backlog inicial
       • Estimativa inicial dos itens
       • Protótipos
     • Desenvolvimento
       • Implementar o sistema através de uma série de Sprints
       • Número de sprints depende do tamanho do projeto
       • Recomendação é padronizar o tamanho das Sprints
     • Pos-Game
       • Implantação
       • Operação
       • Documentação
       • Treinamento

2. 5 - Papeis, Cerimônias e Artefatos

   • Papéis
     • Product Owner
       • Define os itens que compõe a “lista de pendências” - Product Backlog – e define as prioridades
       • Define os objetivos para o próximo Sprint
       • Revê o produto ao final de cada Sprint
     • Scrum Master
       • Gerencia o processo do Scrum. Ensina o Scrum a todos os envolvidos no projeto
       • Implementa o Scrum de modo que esteja adequado à cultura da organização e que todos sigam as regras e práticas do Scrum
       • É responsável por remover os impedimentos do projeto
     • Scrum Team
       • É a equipe de desenvolvimento
       • Não existe necessariamente uma divisão funcional através de papéis como: programador, designer, analista de testes ou arquiteto
       • Todos trabalham para completar o trabalho com o qual se comprometeram para um Sprint
   • Cerimônias
     • Scrum Planning Meeting
       • Reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog
       • A equipe seleciona as atividades que ela será capaz de implementar durante o Sprint
       • As tarefas de um Sprint são transferidas do Product Backlog para o Sprint Backlog
     • Daily Scrum
       • Breve reunião de 15 minutos de pé
       • O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia
     • Scrum Review Meeting
       • Valida os objetivos da iteração e a finalização das estórias
     • Scrum Retrospective Meeting
       • Reunião de retrospectiva para levantar todo conhecimento e experiências da iteração que se encerra
   • Artefatos
     • Product Backlog
       • Lista priorizada de requisitos ou características do projeto que fornecem valor de negócio para o cliente. Não precisa estar completo no início do projeto
       • Itens podem ser adicionados à pendência a qualquer momento (modificações introduzidas)
     • Sprint Backlog
       • Lista das estórias mais relevantes quebrada em tarefas com suas respectivas estimativas de duração do presente momento
       • Definida pelo time e negociada com o Product Owner
       • Deve ser mantida sempre atualizada
     • Lista de impedimentos
       • Lista que contém os impedimentos para o time alcançar os objetivos
       • Tais impedimentos devem ser resolvidos pelo Scrum Master
     • Relatórios
       • São relatórios capazes de mostrar o andamento do projeto. Importantes para controle e tomada de decisão dentro do projeto
       • Relatório de burndown – acompanhamento do tempo restante para concluir as tarefas

3. 6 - Estórias de Usuário

   • Caracteristicas
     • Inicialmente, unidade de funcionalidade no XP
     • Sentença curta de intenção que descreve algo que o sistema deve fazer para o usuário
     • No XP estórias são escritas pelo usuário
     • No Scrum, Product Owner geralmente escreve (aceita e prioriza) estórias, apoiado pelos clientes, partes interessadas e equipe
     • Na prática, qualquer membro da equipe com conhecimento de domínio pode escrever estórias
     • Devem ser escritas de maneira a serem compreendidas por usuários e desenvolvedores
     • Focam no valor definido pelo usuário em vez de uma decomposição hierárquica funcional
     • Podem ser escritas em cartões ou ferramentas
     • Detalhes não aparecem na estória
   • Estórias x Requisitos
     • Não são especificações detalhadas de requisitos, mas expressões de intenção negociáveis
     • São curtas, fáceis de ler e compreensíveis a desenvolvedores, partes interessadas e usuários
     • Representam incrementos de funcionalidade
     • Relativamente fáceis de se estimar esforço
     • Não são registradas em documentos longos mas em listas organizadas
     • Não são detalhadas no início do projeto
     • Necessitam de pouca ou nenhuma manutenção
     • Servem de entrada para qualquer documentação posterior necessária
   • Como escrever estórias
     • Tem formato específico de escrita geralmente Como um <papel>, eu posso/devo <ação> para que <valor para o negócio>
     • Foco: Papel do usuário e Valor para o negócio
     • Papel: permite uma segmentação da funcionalidade. Identifica necessidades de papéis
     • Atividade: Representa “requisito do sistema”
     • Valor para o negócio: Comunica porque a atividade é necessária. Atividades alternativas podem ser discutidas
   • Processo completo
     • Defina uma estória de valor para o usuário
     • Implemente e teste em uma iteração curta
     • Demostre ou entregue para o usuário
   • Representação das Estórias
     • Cartão
       • Representa duas ou três frases usadas para descrever a intenção da estória
       • Detalhe ainda será determinado
       • Promessa de conversa
     • Conversa
       • Discussão entre equipe, cliente e product owner para determinar comportamento detalhado
     • Confirmação
       • Representa o teste de aceitação
       • Representa condições de satisfação