
Olá colegas,
Vamos falar hoje um pouco sobre Agile, mais especificamente sobre o SCRUM.
Provavelmente você já deve ter escutado algo sobre o Scrum e metodologias ágeis, principalmente se tens alguma ligação com a área de desenvolvimento e projetos de software.
Como toda buzzwords das que surgem no dia-dia (e olha que hoje em dia isto não é privilégio somente da área de T.I.), muito se fala e admira-se mas em geral as explicações não consistentes o suficiente.
Este artigo (como outros ótimos exemplos que você pode encontrar mundo a fora) busca lhe mostrar o que é afinal o Scrum, suas vantagens e detalhes.
Vamos lá então...
Introdução - Conhecendo um pouco sobre as definições do SCRUM
Diferente do modelo de se conduzir projetos tradicional que possui uma série de áreas de conhecimento documentadas formalmente e um nível de análise e especificação enorme no início, buscando uma estrutura de conhecimento completa ou quase completa do produto final antes de seu desenvolvimento, o SCRUM fornecem algo mais prático e direto para colocar "as mãos na massa" de uma forma disciplinada e possibilitar uma enorme capacidade de adaptação às mudanças durante o ciclo de vida do projeto.
Mas afinal de contas o que é o SCRUM?
SCRUM
Visão geral e breve histórico:
O SCRUM é um framework (diga-se um arcabouço e/ou conjunto de ferramentas) utilizado para o desenvolvimento ágil de software de forma iterativa e incremental. As origens do SCRUM foram em 1986 quando Hirotaka Takeuchi e Ikujiro Nonaka descreveram uma nova abordagem veloz e flexível para os projetos de desenvolvimento fazendo analogia ao movimento no rugby (futebol americano) aonde a equipe tenta percorrer uma determinada distância como uma unidade (todo mundo junto) passando a bola entre eles (todos colocam a "mão na massa").
Quando diz-se incremental e iterativo significa que temos períodos definidos que se repetem até que o produto final fique pronto (iterativo) e que ao fim de cada período deste temos um bloco funcional do produto final (incremental).
Personagens principais (papéis) no SCRUM:
Vejamos quais são os papéis principais em um projeto Scrum, também conhecidos pelo apelido "brincalhão" de "Pig Roles" por serem aqueles que estão com "o 'bacon' na reta".
Product Owner:
É o representante do cliente que, sempre que possível deve ser um membro da empresa cliente e, que tem autoridade sobre o produto junto ao dever de fornecer todas a informações sobre o negócio e necessidades do cliente para o produto. Ele participa de todas as reuniões que acontecem antes de cada período fixo de trabalho (conhecido como "sprint"), ele que escreve todas as "user stories" (semelhante a casos de usos) do sistema, que define a importância de cada funcionalidade e que define as metas de negócio a serem cumpridas nos períodos de trabalho.
Este personagem além de conhecer o negócio e o que gera valor no projeto (perante a visão do cliente) irá impusionar o feedback e diálogo periódico com o cliente. No melhor caso este papel pode ser atribuído a alguém da própria empresa cliente ou, caso não seja possível, deve ser atribuído a alguém que abrace esta responsabilidade totalmente, pois ele será a via de conhecimento do negócio até a equipe, sendo assim um membro completamente comprometido (por isso é um "pig").
ScrumMaster (ou o facilitador):
O processo com o SCRUM é facilitado pelo ScrumMaster. A função principal do ScrumMaster é garantir a integridade do processo dentro dos moldes do Scrum e, utilizar os artifícios de suas habilidades técnicas e de liderança para remover impedimentos e fornecer meios para que a equipe chegue às metas de entregas.
Equipe:
A equipe é a responsável por botar a "mão na massa" e realizar as entregas dentro dos períodos definidos. As equipes para um processo ágil devem ser pequenas (no máximo 9 pessoas) e multi-disciplinares envolvendo as habilidades necessárias para fazer o projeto rodar plenamente (programadores, designers, testers, ...). Como já explicado deve ser auto-gerenciável o que possíbilita uma flexibilidade e velocidade de resposta às mudanças e desafios maior mas, também requer um nível elevado de responsabilidade, organização e comprometimento de todos
Ferramentas e artefatos do SCRUM
Product Backlog:
É o "coração" processo do SCRUM. Trata-se de um documento de alto-nível (que não se aprofunda no mínimos detalhes) que contém todas as funcionalidades do projeto através das "user stories", estimativas "cruas" de prazo e importância de cada (fora outros parametros que podem ser incluídos para uma melhor adaptção à realidade da empresa). Este documento é de propriedade do Product Owner (ele que descreve as "user stories" e dá a importância de cada uma) mas deve poder ser visto por todos os membros da equipe (normalmente está compartilhado em um local da rede interna ou em uma planilha online).
O formato visual do documento trata-se de uma simples planilha semelhante como no exemplo a seguir:
| ID | Título | Estimativa Inicial | Importância | História (Descrição) |
|---|---|---|---|---|
| 1 | cadastro de usuário | 8 (story points) | 120 | o usuário deve encontrar no site um formulário que perguntará se ele já tem cadastro para fazer compras. Se for cadastrado deve autenticar com seu e-mail e senha. Caso contrário deve aparecer um formulário com os seguintes dados... |
| 2 | ... | ... | ... | ... |
ID:
Trata-se de um código numérico sequêncial que serve para ajudar a identificar unicamente uma "user story".
Título:
Um nome ou frase que descreva claramente de qual "user story" está se falando. O nome deve estar na linguagem do negócio e não em linguagem e detalhes técnicos.
Estimativa inicial:
Como o nome já diz é uma estimativa inicial de quanto tempo a funcionalidade poderá levar. Note também que a unidade são "story points" que corresponde a dias de trabalho de um profissional. Exemplo: Se com 3 membros (vamos dizer 2 programadores e 1 designer) sem interrupções, em um bom ambiente uma funcionalidade deverá ficar pronta em 3 dias então temos 9 story points (3x3 = 9).
Tal abordagem oferece uma visão de impactos no prazo. Mas, lembre-se que trata-se de uma estimativa inicial e não deve ser encarada como uma verdade absoluta e, um outro fator a se citar é que antes de ocorrer uma "sprint" (um período fixo de trabalho da equipe), o tempo de desenvolvimento necessário para cada funcionalidade incluída se torna mais refinado e com adição de margens de risco de atraso.
Importância:
O nível de importância recebe números correspondentes ao o quanto aquela funcionalidade é crucial. Isso ajuda quais devem ser feitas logo nas primeiras sprints e a depender do ambiente na empresa aquelas que tem importância máxima podem se beneficiar de técnicas como a programação em par que aumenta o foco e reduz bastante a possibilidade de erros. Note também que os intervalos normalmente são dados de 10 em 10. Isso facilita a inserção de outras funcionalidades que são "um pouquinho" mais ou menos importantes. Exemplo: História A = 120; História B = 119.
História:
É aqui que o Product Owner descreve em alto nível como deve se comportar a funcionalidade. Note que quando se diz "alto nível" queremos dizer que deve estar na linguagem do Product Owner, ou seja, mais regra de negócio do que uma texto técnico para programadores.
Sprint Backlog:
Se o Product Backlog é considerado o "coração" de onde brota o projeto, o Sprint Backlog é de aonde brotam o movimento e detalhes para se percorrer uma jornada. Trata-se de uma saída detalhada aonde estão as "user stories" do Product Backlog que são escolhidas para desenvolver-se em uma sprint. As "user stories" escolhidas e quebradas em tarefas e as durações de cada uma são refinadas. Dentro deste documento também deve estar a meta da sprint. Exemplo: "Criar o mecanismo de vendas online beta". A criação deste documento tem a participação de toda a equipe e deve ser guiada pela conversa franca e crítica a fim de que se chegue ao que realmente é necessário.
O formato visual do documento que ficará visível para todos tanto deve ser em uma planilha ou documento de texto (que fique compartilhado na rede) como deve também estar disponível em um mural (task board ou kanban) na forma de "index cards". Um mecanismo visual chave que será explicado mais adiante mas, que podemos ver (só para adiantar) na imagem abaixo.

Burn Down Chart:
Trata-se de um gráfico que demonstra o andamento de uma sprint (período fixo de trabalho da equipe) ao longo do tempo definido para esta. Vejamos o exemplo na foto abaixo:

No eixo X temos os dias até o fim da sprint. Exemplo: Os dias úteis desde 01 de fevereiro até 15 de fevereiro (data quando o resultado da sprint deverá ser demonstrado ao Product Owner).
No eixo Y temos o quanto falta (seja em % ou story points) para que se completem todas as funcionalidades separadas para a sprint.
A cada reunião "relâmpago" diária da equipe (daily scrum meeting que veremos mais adiante) o gráfico é atualizado dando a visão de como está indo o trabalho.
Reuniões e eventos do SCRUM
Product Backlog Meeting:
É a reunião inicial do projeto que dá o "pontapé inicial" e fornece toda a informação de alto nível necessária para que seja confeccionado o documento "Product Backog".
Sprint:
A "sprint" que, citamos várias vezes até agora, trata-se de um período fixo de trabalho que a equipe irá percorrer. Essa quantidade de tempo é fixa (normalmente entre 1 a 4 semanas) e o resultado deste trabalho é um pacote de funcionalidades, testadas e prontas para o uso. Antes de uma sprint temos a reunião "sprint planning" que irá planejar e detalhar a sprint e ao fim temos a "sprint demo" aonde o resultado é testado pelo product owner.
Através desta característica fixa, iterativa e incremental aonde a equipe "abraça" o produto final aos poucos em partes iguais é que o SCRUM triunfa sobre uma metodologia tradicional onde de início (quando menos se conhece a mente do cliente) tenta-se "abraçar" tudo. Note também que através do SCRUM estamos sempre planejando junto ao cliente oque diminui os riscos de que a equipe não entenda o projeto. Chegando assim no final com algo que não gera valor e sim desgaste e retrabalho.
Sprint Planning:
Como o nome sugere, é nesta reunião periódica com todos os membros (equipe, ScrumMaster e product owner) em que definimos quais funcionalidades do "product backlog" vão ser escolhidas para que a equipe desenvolva em uma sprint. Aparentemente é simples mas, trata-se da reunião mais demorada e crucial em um projeto ágil com SCRUM.
Vejamos as atividades da reunião:
1. Definir a meta da sprint. Por exemplo: "criar a central de ajuda do site". Uma sprint não deve nunca começar sem uma meta definida em uma linguagem de alto nível.
2. As funcionalidades são escolhidas, divididas (as vezes é necessário dividir uma funcionalidade em duas ou mais para encaixar-se na sprint) discutidas e priorizadas o quanto for necessário para que as estimativas de tempo e importâncias se encaixem na sprint.
3. As "histórias" (funcionalidades) são quebradas em tarefas e o tempo para cada uma estimado. Essa informação sobre as tarefas não necessariamente precisa estar com o Product Owner pois, detalhes técnicos são de encargo da equipe, deixando o Product Owner preocupar-se com aquilo que é realmente importante para ele, ou seja, as funcionalidades.
Então, como funciona a reunião? Provavelmente a primeira coisa que vem a nossa mente é colocar todo o pessoal em volta de uma mesa de reunião com um projetor e alguém com uma planilha excel ou qualquer documento de texto. A planilha realmente ajuda pois realmente a reunião deverá ser documentada mas, se for somente por este caminho a reunião se tornará um marasmo de "tédio" pois esta não é, nem de longe, a melhor forma de estimular a participação de todos da equipe.
Veremos duas técnicas que ajudam muito a resolver este problema:
Index Cards:
Tratam-se de cartões ou post-its aonde colocamos o nome da história (funcionalidade), ou se necessário mais informações como descrição, estimativa, etc. Durante a reunião de sprint planning colocamos estes cartões sobre uma mesa ou quadro branco (de preferência) e ao longo da reunião vamos organizando-os de acordo com a importância que vai sendo atribuída a cada história pelo Product Owner. Veja o exemplo na figura a seguir:
Tal técnica é importante e melhor do que somente o conjunto "mesa+planilha+projetor" porque estimula às pessoas se levantarem e movimentarem-se. Se decide-se que alguma funcionalidade é mais importante do que a outra simplesmente alguém se levanta e muda a posição. Isso estimula o movimento e que as pessoas circulem mais pela sala criando um ambiente mais descontraído. Sendo assim teremos a ordem de importância pela qual a equipe terá um norte ao desenvolver as funcionalidades da sprint.
Planning Poker:
O que acontece quando temos uma funcionalidade e durante o "sprint planning" perguntamos o quanto tempo deve levar para que seja desenvolvida? Provavelmente aquele que sabe (ou acha que sabe) mais vai responder. Muitas vezes funciona mas em excesso isso pode ser altamente prejudicial pois não existe debate entre a equipe e ficamos presos à opinião de uma só pessoa. E se ela estiver errada ou se, aquela opinião aplique-se somente a ela sem levar em conta os outros membros da equipe? Para evitar isto, sempre que necessário utilizamos o "Planning Poker".

Funciona da seguinte forma:
1. O ScrumMaster pergunta à equipe quanto tempo ("story points") é necessário para desenvolver-se uma funcionalidade x.
2. Cada um pensa durante um tempo "quanto dias um profissional precisaria para desenvolver", escolhem o cartão com o número mais aproximado e quanto o tempo acaba colocam sobre a mesa.
3. Aqueles que colocam o maior e menor número devem explicar porque e com isso buscamos chegar a um consenso.
4. Existe também uma carta para dúvida e outra para sugerir uma pausa (o desenho de uma xícara de café).
Esta técnica faz com que todos participem e torna o ambiente mais leve e descontraído.
Sprint Demo:
Se antes de começar uma sprint temos a reunião de "Sprint Planning", ao finalizar temos uma "Sprint Demo".
Trata-se de um evento aonde o "Product Owner" (representante do cliente) se reune junto ao ScrumMaster e equipe para testar as funcionalidades que foram desenvolvidas durante a sprint e que já estão testadas internamente e prontas para o uso. Sempre que possível outras pessoas de outras áreas devem participar também.
Note que seguindo também um modelo de projetos metanóico este evento é uma ótima oportunidade para criar-se momentos memoráveis e deve ser tratado como um evento social. Isso agradará o cliente e deixará a equipe orgulhosa de seu trabalho.
Daily Scrum:
Trata-se de uma reunião relâmpago (aprox. 15 minutos ou menos) deve acontecer todo o dia em um horário e local fixos. Neste encontro todos devem estar em pé próximos ao quadro da sprint (task board ou kanban) e de um quadro branco (para possíveis explicações visuais). São tratados assunto como: "o que foi feito no dia anterior" e "o que será feito hoje" pela equipe. A cada informação que vai surgindo o quadro da sprint o gráfico "burdown chart" vão sendo atualizados por todos.














