Se está familiariazado(a) com a metodologia ágil, já deve conhecer o Scrum. Scrum é um framework para desenvolver e manter produtos complexos. Criado em 1993, por Jeff Sutherland, o processo foi formalizado para a indústria mundial de software no primeiro artigo sobre Scrum, publicado na conferência OOPSLA 1995(hoje chamada SPLASH), por Ken Schwaber.
O nome Scrum é uma analogia a um estudo conduzido em 1986 por Takeuchi e Nonaka, publicado na Harvard Business Review. No estudo, compararam equipes de alto desempenho e multi funcionais com a formação "scrum" existente nas equipes de Rugby em que todo o time está junto em um objetivo. Se a formação for quebrada, o time todo perde. Se atingem o objetivo, a equipe toda é responsável pelo sucesso.
De 1995, para cá, o Scrum deixou de ser um método e passou a ser um framework. Pois, ele apenas indica o que deve ser feito e emprega vários processos ou técnicas.
O time
O Product Owner
O Product Owner é a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings.
O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint (iteração). Estes itens transformam-se no Sprint Backlog.
A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos.
O Scrum Team
O Scrum Team é a equipe de desenvolvimento. Nela, não existe necessariamente uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.
Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. A principal abordagem para trabalhar com equipes grandes no Scrum é usando o conceito de "Scrum of Scrums". Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá freqüentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrums, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações.
O Scrum Master
O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.
O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.
O papel de Scrum Master é tipicamente exercido por um gerente de projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da equipe.
Eventos
Sprint
No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um tempo definido dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que no Scrum são chamadas de Sprints e geralmente duram de 2 a 4 semanas.
Sprint Planning Meeting
O Sprint Planning Meeting é uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.
Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.
O Product Owner não precisa descrever todos os itens que estão no Product Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para o próximo Sprint Planning Meeting.
Coletivamente, o Scrum Team e o Product Owner definem um objetivo para o Sprint, que é uma breve descrição daquilo que se tentará alcançar no Sprint. O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint.
Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. Em alguns casos, haverá negociação com o Product Owner, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer.
Daily Scrum
A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.
Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.
Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.
O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas:
O que você fez ontem?
O que você fará hoje?
Há algum impedimento no seu caminho?
Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem compromissos perante os demais.
Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível.
Sprint Review Meeting
Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.
Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master, gerência, clientes e engenheiros de outros projetos.
Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do Sprint.
Sprint Retrospective
O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.
Burn Down Chart
O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo Y os dias que representam o tamanho do Sprint.
Artefatos
Product Backlog
O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.
Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.
Sprint Backlog
O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.
Cabe a equipe determinar a quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá-los.
Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart.
Conclusão
Mesmo sendo possível implementar apenas partes do Scrum, não será Scrum, se não for aplicado em sua totalidade. Seja adepto das metodologias ágeis e vale a pena conhecer mais sobre o Scrum.
