O que é Scrum?

Este é mais um post básico e seu objetivo é conceituar um pouco o que é Scrum.
Scrum é um framework para gerenciamento de projetos de software. Note que Scrum pode ser utilizado por outras áreas e não somente em desenvolvimento de software, mas daremos maior foco para sua utilização na área de TI.
Falamos framework porque Scrum por si só não é um paradigma de gerenciamento. Ele é baseado num modelo chamado de Modelo Ágil de desenvolvimento de software. Quando falamos de agilidade estamos falando de vários outros pontos que se somam ao Scrum, como: Extreme Programing (XP) , por exemplo.

O nome Scrum vem de uma jogada ou formação do Rugby, onde 8 jogadores de cada time devem se encaixar para formar uma muralha. É muito importante que seja realizado um trabalho de equipe, pois se um dos jogadores na formação falhar, toda a jogada é comprometida.

Percebeu onde já entra a primeira grande questão num modelo ágil? O trabalho em equipe é o ponto principal e talvez o mais importante. É crucial que se tenha um olhar de time para entender o que é ser ágil e praticar no dia-a-dia. O processo Scrum foi estabelecido por Ken Schwaber e Jeff Sutherland e está baseado no manifesto ágil, que defende os seguintes pontos:

• Pessoas e suas interações mais importante do que processos e ferramentas;
• Software funcionando mais importante do que documentação abrangente;
• Colaborar com o cliente mais importante do que negociar contratos;
• Responder as mudanças mais importante do que seguir um plano.

A idéia não é de que os itens do lado direito não sejam importantes, mas se eu tiver que escolher entre um deles vou sempre priorizar os do lado esquerdo.
Algumas pessoas de fora, que estão acostumadas a trabalhar em processos tradicionais, muitas vezes apresentam uma visão equivocada a respeito de Scrum. Abaixo temos algumas lendas que você poderá ouvir por aí:

• É um processo que não possui documentação nenhuma;
• Os "caras" gerenciam projetos com um monte de post-its;
• Jogam baralho durante o trabalho;
• É um processo que não possui gerente de projetos, logo, foi uma metodologia criada por programadores que tinham problemas com autoridade;
• Não possui cronograma. COMO GERENCIAR SEM PROJECT ?
• Precisa de um time muito especialista pra funcionar direito;
• Não dá para estimar e metrificar, logo é impossível de vender;
• Meu cliente nunca irá aceitar esse negócio de ?escopo variável?;
• É feito para atender projetos pequenos e não complexos;

Importante saber que essas "afirmações" acima não passam mesmo de lendas. É preciso somente um pouco mais de conhecimento sobre Scrum ou Agilidade para ver que elas não tem fundamento algum.
Acima de tudo o Scrum é uma maneira de evidenciar problemas que acontecem no desenvolvimento de projetos de software. Ele não vai resolver seus problemas de engenharia ou de qualidade no software, mas vai oferecer mecanismos para que a equipe vá atrás de soluções para esses problemas.

Os papéis no Scrum

• Product Owner (P.O) é o dono do produto. Ele possui a visão do retorno que o projeto trará para a empresa e para os envolvidos, logo sua missão é cuidar do Product Backlog, planejar releases, priorizar requisitos e passar ao time uma visão clara sobre os objetivos do projeto. É muito indicado então que o P.O seja alguém do lado do cliente.
• ScrumMaster (S.M) exerce um papel de liderança no processo, mas ele não é um gerente de projetos. O papel de S.M não possui autoridade alguma perante o P.O ou o Time. A responsabilidade do Scrum Master é manter o foco no processo, remover impedimentos da equipe e auxiliar na comunicação entre equipe e P.O.
• O Time é o conjunto de pessoas que implementará o projeto. É composto por uma equipe multidisciplinar que tem a característica da auto-gestão. A responsabilidade do Time é manter a auto-gestão de suas atividades, planejar as Sprints, assumir metas com o P.O e dar feedback sobre os impedimentos para o S.M.

Então vejamos:

• O Product Owner gerencia: Escopo, prazo (datas de entregas) e acompanha o ROI (medição e análise);
• O ScrumMaster gerencia: Processo, risco (impedimentos) e planejamento (atingir metas);
• Os Membros do Time gerenciam: Configuração, riscos, requisitos e planejamento.

Neste momento, o leitor deve estar eufórico se perguntando: Onde está o Gerente de Projetos? Pois é, lamento dizer que este papel não existe no Scrum. Pelo menos, não como definido pelo mercado hoje, certo?



O gerenciamento é dividido entre os membros do Time, ScrumMaster e Product Owner. Este é um ponto muito forte e é requisito para buscar a agilidade: O auto-gerenciamento.
Ao contrário das chamadas metodologias tradicionais, que seguem um modelo definido de desenvolvimento de software baseado em fases e atividades, o Scrum é um processo empírico, ou seja, você não me diz como eu devo fazer, mas somente o que quer como resultado. Depois disso, nós aprendemos durante o processo e evoluímos com este aprendizado, buscando juntos o objetivo a ser alcançado.

Um processo padrão orientado por fases e atividades pode ser parecido com o modelo abaixo:



Fala a verdade, tá acostumado com ele né? Claro, é o modelo utilizado na grande maioria dos projetos hoje em dia.
Ao invés de etapas e atividades definidas no início do projeto, o ciclo de vida de um projeto Scrum é composto por iterações de software funcionando. O ciclo de vida é representado pela figura abaixo:

Os Artefatos:

Bom, o Scrum não oferece listas de templates ou modelos de documentos para que você possa sair usando. No entanto existem alguns artefatos que fazem parte do dia-a-dia, vamos falar dos principais:

• Product Backlog é a lista que contém os requisitos do projeto. Aqui temos todas as necessidades e/ou vontades do Product Owner para o projeto. Este é um artefato "vivo", pois será priorizado e re-priorizado ao longo do projeto de acordo com a visão do P.O. Uma forma ágil de gerenciar e manter seu Product Backlog é por meio das user stories. Utilizando essa abordagem você verá muitos resultados interessantes em seu processo de engenharia. Mas, como já dissemos o Scrum não é um processo de engenharia então você pode utilizar o que quiser pra manter seu Product Backlog (Casos de Uso, Requisitos, Especificação, etc), desde é claro que o P.O reconheça valor nesses documentos e que eles sejam claros para o time.
• Impediment List é a lista com os impedimentos do Time, na qual o S.M deverá trabalhar.
• Sprint Backlog possui as atividades nas quais o Time vai atuar dentro de uma Sprint. Essas atividades são planejadas pelo Time durante a reunião de planejamento da Sprint. Este também é conhecido por ser representado pela Kanban, provavelmente um dos símbolos mais associados ao Scrum.

Product e Sprint Burndown são gráficos que mostram a tendência planejada para atendimento da Sprint / Product Backlog e como o time está evoluindo diariamente no caso da Sprint e a cada Sprint no caso do projeto.

Cerimônias:

Existem também algumas cerimônias no Scrum, que marcam cada etapa no ciclo de vida. As principais:

• Sprint Planning Meeting é a reunião de planejamento da Sprint. Nela o Time discutirá com o P.O sobre a meta a ser alcançada naquela Sprint e fará o planejamento de todo o trabalho que será realizado dentro da Sprint.
• Daily Meeting é a reunião diária que ocorre com todos os membros do Time, S.M e P.O. Preferencialmente deve ter 15 minutos e os integrantes do Time respondem a perguntas como:
• O que fiz desde a última reunião diária;
• O que planejo fazer até a próxima;
• O que está me impedindo?
• Sprint Review é a reunião de prestação de contas na finalização da Sprint. Nela todos os membros do Time apresentarão o resultado atingido na Sprint ao P.O e outros envolvidos.
• Sprint Retrospective é a reunião de "lições aprendidas" que ocorre ao final de cada Sprint. Nela os membros do time respondem a perguntas como:
• O que fizemos de bom e temos que continuar fazendo?
• O que temos que mudar ou começar a fazer?
• Quem está no controle?

O Scrum não é um termo novo, ele já vem sendo utilizado para gerenciar projetos desde 1990. Então porque somente agora estamos ouvindo falar dele no mercado corporativo? Na minha opinião, a resposta mais correta é:
Porque agora as empresas estão abrindo seus cases e experiência com métodos ágeis e isso está atraindo a atenção de desenvolvedores, gerentes e executivos. Todos querem conhecer o tal método dos ?post-its?.

O que temos que levar em conta é que Scrum ou práticas ágeis em geral não se resumem apenas na utilização de Kanbans ou na realização de reuniões diárias. O mais importante não está em evidência e tem a ver com mudança cultural. É imprescindível que se tenha o foco sempre na mudança cultural e não somente nas práticas. É preciso olhar para os itens do manifesto, entendê-los e praticá-los para conseguir resultados com o processo.



É claro que este post é apenas um resumo para tentar ?clarear? um pouco o assunto para aqueles que ainda não tiveram contato com Scrum. Se você tem interesse em aprofundar seus conhecimentos sobre práticas ágeis ou Scrum ou sobre seu uso no mercado, entre em contato. Existem muitas pessoas no mercado que podem te ajudar.