Scrum o que realmente é

O Scrum é um processo de gestão e desenvolvimento ágil que se desenvolveu como uma abordagem iterativa e incremental para otimizar a previsibilidade e controle de riscos, fortemente sustentado por três pilares:

  • Transparência: garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados;
  • Inspeção: diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas;
  • Adaptação: se um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, o inspetor deverá ajustar o mais rápido possível o processo ou o material sendo processado.

A metodologia Scrum consiste em um conjunto formado por Times e seus papéis, Time-Boxes, Artefatos e Regras. Os Times de Scrum são projetados para otimizar flexibilidade e produtividade, são auto-organizáveis, multidisciplinares e trabalham com iterações. Um Time de Scrum conta com três papéis definidos:

  • o ScrumMaster: responsável por garantir que o processo seja seguido e compreendido por todos, trabalhando na remoção de impedimentos, incentivando e levando a equipe a ser mais produtiva e garantindo a qualidade do código gerado;
  • o Product Owner: é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time. Deve manter a lista de prioridades sempre atualizada com as tarefas de maior valor de negócio.
  • o Time: são os desenvolvedores que transformam o Product Backlog em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, etc. Cada membro do time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficiência e eficácia do time como um todo.

Reuniões de Planejamento da Release, a Sprint, Reuniões de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da Sprint e a Daily Scrum estão incluídos nos Time-Boxes da Scrum.

  • Reunião de Planejamento da Release: estabelece a meta da release, estimativas e as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na release. Estabelece também uma data de entrega e os custos prováveis se nada mudar. A organização pode inspecionar o progresso e fazer mudanças nesse plano a cada Sprint. Esse planejamento é inteiramente opcional, onde iniciando os trabalhos sem essa reunião, a ausência de seus artefatos aparecerá como um impedimento que deverá ser resolvido. Na maior parte dos caso o processo de planejamento é feito no início do trabalho da release e não é modificado com o passar do tempo. São definidos uma meta geral e resultados prováveis.
  • Sprint: é uma iteração de duração fixa. Durante um Sprint, o ScrumMaster garente que não será feita nenhuma alteração de escopo que possa afetar a Meta da Sprint. Uma Sprint consiste do Planejamento da Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após a outra, sem intervalos entre elas. Uma Sprint pode ser cancelada antes do prazo fixo, mas somente o Product Owner tem autoridade para isto. Uma Sprint pode ser cancelada se a Meta da Sprint se tornar oblsoleta, pela empresa mudar de direção ou se as condições do mercado ou tecnologia mudarem.
  • Reunião de Planejamento da Sprint: é o momento no qual a iteração é planejada. É fixada oito horas de duração para uma Sprint de um mês. Para Sprints mais curtas, deve-se alocar proporcionalmente ao tamanho total da Sprint para essa reunião. Ela consiste em duas partes, a primeira parte – o quê? – é o momento no qual é decidido o que será feito na Sprint e a segunda parte – como? – é o momento no qual o Time entende como desenvolverá as funcionalidades em um incremento do produto. Para a primeira parte o Product Owner apresenta ao Time o que é mais prioritário no Product Backlog. Cabe ao Time a decisão de avaliar quanto do Backlog deverá ser selecionado para a Sprint. Uma vez selecionada as atividades do Backlog, a Meta da Sprint é delineada, sendo ela o objetivo que será atingido no Sprint. Na segunda parte da reunião o Time geralmente começa projetando o trabalho, identificando tarefas. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas é chamada de Sprint Backlog. O Product Owner estará presente nesta segunda parte da reunião para esclarecer e ajudar a efetuar trocas de tarefas caso as estimativas excedam ao tempo da Sprint ou o haja algum impedimento ainda não resolvido para a execução daquela tarefa. Caso o Time finalize a Sprint antes do prazo, será negociado com o Product Owner uma nova tarefa que será adicionada ao atual Sprint Backlog.
  • Revisão da Sprint: ao final da Sprint, é feita uma reunião de Revisão, com duração proporcional à duração da Sprint – quatro horas para Sprints de um mês. Nesta reunião o time colabora sobre o que acabou de ser feito e baseado nisso eles colaboram sobre quais são as próximas tarefas que podem ser feitas. Trata-se de uma reunião informal, com a apresentação das funcionalidades. O Product Owner identifica o que foi feito e o que não foi feito. O Time discute sobre o que ocorreu bem e quais foram os problemas enfrentados, além de como esses problemas foram resolvidos. O Time demonstra o trabalho que está pronto e responde a questionamentos. O Product Owner faz projeções de datas prováveis a partir de várias hipóteses de velocidade. A Revisão de Sprint fornece entradas valiosas para as reuniões de Planejamento de Sprints seguintes.
  • Retrospectiva da Sprint: logo após a revisão da Sprint e antes da próxima reunião de Planejamento da Sprint o ScrumMaster encoraja o Time a revisar seu processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint. A finalidade é inspecionar como ocorreu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e ferramentas. Deve identificar e priorizar os principais itens que ocorreram bem e aqueles que, feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. No final desta reunião o time deve ter identificado medidas de factíveis melhoria que implementarão na próxima Sprint.
  • Daily Scrum: o Time se encontra diariamente para uma reunião de no máximo 15 minutos, sempre no mesmo horário e no mesmo local durante as Sprints. Durante a reunião cada membro explica:
    • O que ele realizou desde a última reunião;
    • O que ele vai fazer antes da próxima reunião;
    • Quais obstáculos estão em seu caminho.

As Daily Scrums melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto. É uma inspeção e adaptação do progresso na direção da Meta da Sprint. Os Artefatos do Scrum incluem o Product BackLog, o Burndown da Release, o Sprint Backlog e o Burndown da Sprint.

  • Product Backlog e Burndown da Release: os requisitos para o produto estão listados no Product Backlog, por seu conteúdo, por sua disponibilidade e por sua priorização. O Product Backlog evolui à medida que o produto e o ambiente em que ele será usa evoluem, ele é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil. O gráfico de Burndown da Release registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O Product Owner mantém o Product Backlog e o Burndown do Backlog da Release atualizados e publicados todo o tempo.
  • Sprint Backlog e Burndown da Sprint: o Sprint Backlog consite nas tarefas que o time executa para transformar itens do Product Backlog em incremento pronto. É todo trabalho que o Time identifica como necessário para alcançar a Meta da Sprint. Os itens do Sprint Backlog devem ser decompostos suficientemente para que mudanças no progresso possam ser entendidas na Daily Scrum. Um dia ou menos é um tamanho comum para um item do Sprint Backlog. O Sprint Backlog é um retrato em tempo real altamente visível do trabalho que o Time planeja efetuar durante a Sprint. O Burndown do Sprint Backlog é um gráfico da quantidade restante de trabalho do Sprint Backlog em uma determinada Sprint ao longo do tempo da Sprint.

O Scrum exige que os Times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente integrável, pois o Product Owner pode optar por implantar a funcionalidade imediatamente. Para isso ser possível, o incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.

Fonte: Elton Kuzniewski

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *