Scrum: A Arte de Criar Valor
Este framework foi desenvolvido em 1990 por Jeff Sutherland e Ken Schwaber e teve suas raízes em um ambiente de extrema incerteza e desperdício num projeto de desenvolvimento de sistema para o FBI, onde milhões de dólares haviam sido dispendidos ao projeto, porém não havia sido entregue o que realmente era necessário com a estrutura gestão de projetos utilizada na época, conforme citado no livro (Scrum, 2019). O objetivo do Scrum é ajudar pessoas a solucionar problemas complexos por meio de soluções adaptativas, tendo como foco pessoas, ambiente frequentado pelo time e busca da satisfação do cliente.
Segundo Schwaber (2020), neste framework somente são fornecidas recomendações sobre relacionamentos e interações, podendo ser empregado em diferentes times ferramentas e técnicas que complementem a filosofia ágil e ajudem no desenvolvimento do projeto.
O Scrum tem como base o empirismo (o conhecimento dos membros do time surge com base em suas experiências) e o lean thinking (redução de desperdícios e foco na real necessidade do projeto) e em seus quatro eventos dentro de seu framework emprega seus pilares de (transparência, inspeção e adaptação). (SCHWABER, 2020). Em cada evento do Scrum tem-se como prática possibilitar que o projeto seja o mais transparente possível fazendo com que todos do time e o cliente saibam onde o projeto se encontra, quais são suas barreiras e descobertas que foram feitas, também se tem como prática a inspeção do trabalho que vem sendo mostrado, para que seja possível identificar potenciais pontos de melhoria e assim adaptar métodos e processos utilizados.
A estrutura de operação do Scrum bem como um exemplo de seus time boxes pode ser analisada na figura 1.Figura 1 – Framework Scrum.
Fonte: Elaborada pelo autor (2021).
Conforme apresentado na figura 1, o Scrum possui 4 eventos formais, que são:
Sprint planning: Este é o evento de início da sprint, onde são definidas as tarefas que serão realizadas e é entendido o objetivo, definindo qual será a meta da sprint. Neste evento podem ser convidados apoiadores de fora do projeto para compartilharem suas experiências e aconselhar o time de desenvolvimento. Na sprint planning é procurado entender o motivo das entregas gerarem valor ao cliente, o que e como pode ser feito o trabalho para tornar a meta real, dentro do timebox definido para este evento, durando no máximo 8 horas para sprints de 4 semanas.
Daily Scrum: Este é o evento mais rápido da sprint, porém é executado todos os dias de trabalho, tendo um timebox máximo de 15 minutos. Na daily Scrum tem-se o propósito de inspecionar o progresso para atingir a meta da sprint, neste encontro é desenvolvido um plano de ação para o próximo dia de trabalho e são identificados os impedimentos para o dia de trabalho atual, criando foco e incentivando o autogerenciamento do time de projetos.
Sprint review: Neste evento são inspecionados os resultados atingidos dentro da sprint dando visibilidade para o time identificar a necessidade de adaptações futuras. Durante este evento o time Scrum e o cliente analisam o que foi construído e as mudanças que foram realizadas. Este evento tem um timebox de 4 horas para sprints de um mês de duração.
Sprint retrospective: Esta reunião é realizada apenas com os membros do time de projeto, possui um timebox máximo de 3 horas para sprints de 4 semanas e tem como objetivo entender como melhorar a qualidade do produto e a eficiência do trabalho do time. São inspecionadas as iterações, processos e ferramentas utilizadas e é suposto o que pode ter desviado o foco do time, entendido quais melhorias deram certo e que irão continuar sendo aplicadas nas próximas sprints.
Na figura 1 também podem ser analisados os artefatos do Scrum que simbolizam o trabalho/valor agregado ao produto, sendo:
Product backlog: O objetivo do product backlog é atingir a meta da sprint. Este artefato é uma lista ordenada com as atividades que serão executadas dentro da sprint, sendo a única fonte de trabalho. As atividades no topo do product backlog são as que já passaram por um refinamento tornando pequena e precisa cada entrega a ser realizada. O time de desenvolvimento é o responsável pelo dimensionamento do tamanho das atividades e o product owner é incumbido a ajudar e entender os trade-off’s (troca de itens) quando necessário.
Sprint backlog: Este artefato é definido a cada início de sprint no evento sprint planning. Os desenvolvedores analisam o backlog do produto e selecionam quais atividades dentro de uma “história de usuário” serão realizadas dentro da sprint atual. Com o sprint backlog é dada uma imagem do andamento da sprint, servindo como base para implementação de indicadores como gráfico burndown e burnup.
Incremento de produto: São as entregas potencialmente utilizáveis realizadas dentro da sprint. Diversos incrementos são realizados durante a sprint e no evento sprint review são apresentados ao cliente para a obtenção de feedback. Caso um incremento não atinja a definição de pronto o mesmo não é apresentado ao cliente e retorna ao product backlog para que seja retomado em outra sprint.
Segundo Schwaber (2020) o sucesso do Scrum está diretamente relacionado aos seus 5 valores (compromisso, foco, abertura, respeito e coragem). O time de projeto deve se comprometer com estes valores e suportar uns aos outros durante o andamento do projeto para que possam tomar as melhores decisões possíveis sob uma visão holística. No Scrum tem-se 3 papéis conforme apresentado na figura 1, que são:
Time de desenvolvimento: São as pessoas que são responsáveis pela construção do projeto (programação, estruturação, prototipagem). Cada membro do time possui diferentes habilidades e conhecimentos técnicos que se complementam para possibilitar a construção e idealização do projeto.
Product owner: É o responsável por fazer com o que o produto tenha o máximo de valor possível para o cliente e para a empresa, trabalhando com a satisfação de cliente e o retorno financeiro para a empresa, utilizando por exemplo indicadores como o ROI (return on investiment). Este membro do time faz a interface de comunicação entre cliente e time de desenvolvimento, apresentando ao time as necessidades do cliente por meio das histórias de usuário.
Scrum master: É o membro responsável pelo conhecimento técnico do framework Scrum, fazendo com que o time e toda a organização entendam e sigam cada etapa da metodologia. É o responsável pela eficácia do time Scrum, podendo realizar treinamentos ao time, remoção de impedimentos do andamento do projeto e garantindo que os eventos sejam positivos, produtivos e dentro de seus respectivos timeboxes.
Apesar do Scrum possuir eventos predefinidos, este framework procura ser o menos prescritivo possível, para que diferentes times de projeto tenham abertura para adotar práticas e ferramentas que se encaixem ao produto que estão desenvolvendo. (SCHWABER, 2020). O Scrum tem foco total no produto, para atender aos requisitos informados pelo cliente, cada membro tem a liberdade para criar, se auto organizar e auto gerenciar em direção a meta do produto e em suas últimas atualizações do guia Scrum tem sido removida as linguagens técnicas focadas a TI, dando abertura para implementação em diversas áreas de atuação.