Introdução ao SCRUM

Este é o primeiro artigo de uma série sobre o Scrum, um framework ágil para gerenciamente de projetos de software. O intuito é passar por todos os itens do Scrum, tentar dar detalhes diretos e simples sobre esse framework. A princípio falarei dos conceitos e terminologias do Scrum nesse primeiro artigo.

Um pouquinho de história

O Scrum foi criado inicialmente como um framework para gerenciamento projetos na indústria convencional, em 1995, Ken Schwaber formalizou o Scrum para projetos de desenvolvimento de software. Scrum foi fortemente baseado no processo Lean da Toyota.

Conceitos básicos

O Scrum é baseado em ciclos de 2 a 4 semanas, chamados de Sprints. A cada sprint o esforço é para se entregar itens com o maior valor de negócio (e prioridade) ao cliente, dando a ele algo real e de valor para o negócio.

Product Backlog

É a lista de tudo que se deseja para o software, de uma maneira enxuta, sem detalhamento. O grande diferencial é que essa lista não precisa estar completa logo no inicío, não precisa ter 100% do itens possíveis e imagináveis. O Product Owner define essa lista, que pode ir ganhando outros itens ao decorrer do desenvolvimento das Sprints, ele também detalha os itens em cada planejamento de sprint, e prioriza os itens, a equipe define quais itens cabem ou não dentro da Sprint, essa lista gerada tem o nome de Sprint Backlog. O processo se repete a cada ciclo de desenvolvimento.

Reunião Diária (Scrum Daily Meeting)

A reunião diária serve para a equipe se alinhar em relação ao desenvolvimento dos itens do Sprint Backlog. Esta reunião deve durar no máximo 15 minutos, seu conteúdo é exposto pela equipe basicamente respondendo 3 perguntas:

• O que eu fiz ontem?
• O que farei hoje?
• Quais impedimentos eu tive?

Essas são as perguntas que compõem o conteúdo da reunião, que é voltada para o time, cada membro dirige suas respostas para o time todo e não direcionada para o Scrum Master, não é uma forma de cobrança vindo de um gerente de projetos, é a maneira onde toda a equipe se sincroniza em relação às tarefas e relatam os impedimentos que possam estar interferindo no bom andamento do Sprint.

Revisão (Sprint Review)

Está é uam reunião muito importante do ponto de vista do cliente, nela, tudo o que foi desenvolvido durante a Sprintserá apresentada para os responsáveis pelo projeto, o cliente em si, ou as pessoas que o represente. Cada história (user stories) é apresentada de acordo com a ordem de prioridade definida no Sprint Backlog, e o cliente dá o aceite final a história e indica se a Sprint atingiu a meta proposta.

Retrospectiva (Sprint Retrospective)

Ao término de cada Sprint, a equipe se reúne para analisar a Sprint que encerrou, com o propósito de um constante aperfeiçoamento.

Nessa reunião serão debatidos o que funcionou bem na Sprint, o que precisa ser melhorado e quais ações serão tomadas para colocar essas melhorias em prática. Geralmente o Sprint Retrospective tem um timebox de 4hs de duração.

Product Owner

Este é o cara que representa o cliente, que conhece o negócio e as regras do funcionamento dele, se tem alguém no projeto que tem todo interesse pelo ROI (Return of investment) tem que ser o Product Owner.

O Product Owner é responsável por criar o Product Backlog e priorizá-lo. Como ele é quem sabe o que é mais importante pro negócio, ele também fará as alterações dos itens, seja prioridade ou remoção e adição de novos.

Em algumas empresas esse papel é conhecido como Gerente de Produto, e também outros nomes semelhantes. O que importa é que como já disse meu amigo Rodrigo Yoshima no blog dele, esse cara é um desgraçado ganancioso que tem todo interesse no sucesso do projeto, e acredite, ele é fundamental para que isto aconteça.

Esse papel (role) gera muitas discussões entre os agilistas mundo à fora, o que se deve ter em mente não é se esse papel será composto por um representante do cliente dentro da equipe ou por uma pessoa da própria empresa prestadora do serviço, o importante é que seja uma pessoa capacitada a sanar as dúvidas que surjam no dia-a-dia, pois ele faz parte da equipe também e deve ter todo o comprometimento do mundo com o projeto.  O que acontece muito é colocarem pessoas que se acham o Gerente do Projeto, ou que não tem conhecimento do real papel do Product Owner dentro do Scrum e essas pessoas acabam dificultando muitos mais o trabalho do que ajudando.

Scrum Master

O Scrum Master é o papel responsável por fazer o ambiente Scrum funcionar, verificando se time esta respeitando e cumprindo os valores e práticas do Scrum.

Ele também orienta o time no Daily Meeting corretamente e é o responsável por remover todos os impedimentos apontados.

Ele protege a equipe de interferências externas, assegura que os Sprints não contenham itens além do que pode ser realmente entregue. Em alguns lugares se tem a visão de que o Scrum Master é um Gerente de Projetos, e não é! O Scrum Master é um facilitador, alguém que tem a missão de fazer o time funcionar e aplicar corretamente o Scrum.

O Time (team)

O Time é responsável por transformar itens do Product Backlog em itens do Sprint Backlog e transformar esses itens em software pronto para ser entregue.

As equipes de Scrum contém geralmente entre 5 e 9 pessoas, não mais do que 10, isso é essencial para a boa prática do Scrum. Os membros são multifuncionais, podendo conter desenvolvedores, designers, arquitetos da informação, etc.

Outra característica importante é que os times são auto-gerenciáveis, sendo eles responsáveis por controlar as tarefas do desenvolvimento da Sprint.

Esses são os principais conceitos do Scrum, dados aqui de uma maneira bem simples sem fazer uma ligação lógica e prática do funcionamento de todos esses itens e papeis do Scrum. No próximo artigo, vou falar como isso tudo se interliga e funciona na prática, no dia-a-dia de uma empresa.

Até breve!