SCRUM - METODOLOGIA DE DESENVOLVIMENTO GIL

A metodologia SCRUM assume-se como uma metodologia extremamente

gil e flexvel. Tem por objetivo definir um processo de desenvolvimento
iterativo e incremental que pode ser aplicado a qualquer produto ou no
gerenciamento de qualquer atividade complexa, proporcionando um
excelente entrosamento entre as equipes de desenvolvimento. Com todo
esse entrosamento e com a participao ativa dos clientes, o rendimento do
projeto aumenta e os requisitos e solicitao de alterao passa a ser
entendido mais rapidamente. As metodologias de desenvolvimento gil vem
se destacando a cada dia, porm essas ainda so pouco difundidas no meio
acadmico. O objetivo deste artigo, alm de difundir esse assunto e servir
de apoio para futuras pesquisas, demonstrar de maneira simples e
objetiva, o funcionamento, as caractersticas, o vocabulrio e a aplicao da
metodologia SCRUM em um ambiente de trabalho.

INTRODUO

Jeff Sutherland aplicou a primeira concepo do Scrum na Easel

Corporation em 1993, mais tarde, por volta de 1995, Ken Schwaber refinou
essa metodologia baseando-se em sua prpria experincia no
desenvolvimento de sistemas e processos. O SRUM assume-se como uma
metodologia extremamente gil e flexvel, que tem por objetivo definir um
processo de desenvolvimento interativo e incremental podendo ser aplicado
a qualquer produto ou no gerenciamento de qualquer atividade complexa.
Esta metodologia baseia-se no desenvolvimento incremental das aplicaes
centrado na equipe com ciclos de iterao curto.

SCRUM aplica-se a projetos tanto pequenos como grandes. Esforando-se

para liberar o processo de quaisquer barreiras, o seu principal objetivo
conseguir uma avaliao correto do ambiente em evoluo, adaptando-se
constantemente ao caos de interesses e necessidades, indicado e
utilizado para o desenvolvimento de softwares em ambiesntes complexos,
onde os requisitos mudam com certa frequncia, sendo o caminho utilizado
para aumentar produtividade nesses tipos de sistemas.

A Metodologia SCRUM apenas estabelece conjuntos de regras e prticas

de gesto que devem ser adotadas para garantir o sucesso de um projeto.
Centrado no trabalho em equipe, melhora a comunicao e maximiza a
cooperao, permitindo que cada um faa o seu melhor e se sinta bem com
o que faz o que mais tarde se reflete num aumento de produtividade.
Englobando processos de engenharia, este mtodo no requer nem fornece
qualquer tcnica ou mtodo especfico para a fase de desenvolvimento de
software.
Segundo (FERREIRA, 2005), as principais caractersticas do SCRUM so:

um processo gil para gerenciar e controlar o desenvolvimento de

projetos;
um wrapper para outras prticas de engenharia de software;
um processo que controla o caos resultante de necessidades e
interesses conflitantes;
uma forma de aumentar a comunicao e maximizar a cooperao;
uma forma de detectar e remover qualquer impedimento que atrapalhe
o desenvolvimento de um produto;
escalvel desde projetos pequenos at grandes projetos em toda
empresa.

Vocabulrio utilizado no SCRUM:

Backlog: Lista de todas as funcionalidades a serem desenvolvidas durante

o projeto ompleto, sendo bem definido e detalhado no inicio do trabalho,
deve ser listado e ordenado por prioridade de execuo;
Sprint: Perodo no superior a 30 dias, onde o projeto (ou apenas algumas
funcionalidades) desenvolvido;
Sprint Planning Meeting: Reunio de planejamento;
Sprint Goal: Disparo dos objetivos/metas;
Sprint Review Meeting: Reviso da
reunio;

 Sprint Backlog: Trabalho a ser desenvolvido num Sprint de modo a criar

um produto a apresentar ao cliente. Deve ser desenvolvido de forma
incremental, relativa ao Backlog anterior (se existir);
Dayling SCRUM: Reunio diria;
Scrum: Reunio diria onde so avaliados os progressos do projeto e as
barreiras encontradas durante o desenvolvimento;
Scrum Meeting: Protocolo a seguir de modo a realizar uma reunio Scrum;
Scrum Team: A equipe de desenvolvimento de um Sprint;
Scrum Master: Elemento da equipe responsvel pela gesto do projeto e
liderar as Scrum Meetings, so normalmente engenheiros de software ou da
rea de sistemas. Apesar de ser gestor no tem propriamente autoridade
sobre os demais membros da equipe.
Product Backlog: Produo do trabalho executado.
Product Owner: Proprietrio do produto.

PROCESSO E FUNCIONAMENTO SCRUM

As fases de desenvolvimento SCRUM podem ser divididas basicamente

em trs, so elas:
Planejamento: Definio de uma nova funcionalidade requerida pelo
sistema baseado no conhecimento do sistema como um todo;
Desenvolvimento: Desenvolvimento dessa nova funcionalidade
respeitando o tempo previsto, requisitos exigidos e qualidade. Esses itens
definem o fim do ciclo de desenvolvimento;
Encerramento: Preparao para a entrega do produto persistindo as
atividades:
Teste Caixa Branca, Teste Caixa Preta, Documentao do Usurio,
Treinamento e Marketing.
Segundo CRUZ (2006), existem dois tipos de processos: Definidos e
Empricos. Processos definidos so aqueles que determinam o que deve ser
feito, quando e como. Para um mesmo conjunto de variveis de entrada,

pode-se esperar o mesmo resultado sempre. Um exemplo bem conhecido de

processo definido o RUP (Rational Unified Process) da IBM (Rational).
Os processos empricos devem ser utilizados sempre que os processos
definidos no forem adequados devido complexidade do projeto, ou seja,
sempre que no se conheam todas as variveis de entrada para que possa
estabelecer um processo repetvel (com a mesma sada sempre), o Scrum
um exemplo deste. Para iniciar o processo Scrum, a primeira coisa a ser
definida quais pessoas sero designadas para trabalhar e que iro compor
a equipe Scrum. Esta equipe deve ser composta de 6 a 9 membros. Se
houver mais membros do que possvel gerir, separam-se vrias equipes
Scrum e cada equipe focar-se- numa rea especfica do trabalho. A
prxima etapa a fazer apontar o Scrum Master, uma vez que essa
pessoa que conduz as Scrum Meetings, mede o progresso empiricamente,
toma decises e remove os obstculos do caminho para no desacelerar ou
mesmo parar o trabalho em pontos crticos. O Scrum Master fica
encarregado de gerenciar e transmitir as informaes do projeto a todos os
membros da equipe, ele deve ser capaz de tomar decises imediatas e
resolver todos os impedimentos rapidamente, de modo a no estender o
tempo da reunio
ele que identifica o backlog inicial, que todo o trabalho proeminente
para uma rea do produto, tanto imediato e bem definido, como a longo
prazo e indefinido. Para identificar o backlog, a primeira coisa a fazer listar
todo o trabalho conhecido necessrio fazer e agrup-lo em incrementos que
no devem ter durao superior a 30 dias. Se houver reas de trabalho
volteis ou que no possam ser completamente definidas para 30 dias, deve
ser estabelecido um incremento para um tempo conhecido. Depois disto,
preciso listar todo o trabalho proeminente a fazer e definir prioridades para
todos os elementos listados. Uma vez terminado, o backlog deve ser
assinado pelos membros das equipes e a partir da, s o que foi definido
neste documento dever ser cumprido durante o Sprint para cada rea.
vital para que o processo funcione cumprir com os trabalhos rigorosamente
com base nos pontos restantes do Sprint Backlog. Para isso, preciso
estabelecer e conduzir as reunies dirias Scrum onde s equipes se
encontra e se atualizam sobre o que se vai fazendo. Isto fornece um foco
dirio no trabalho em desenvolvimento. Antes de mais nada, certifique-se
de que as reunies se realizem sempre na mesma hora e no mesmo local,
evitando gastos na procura diria de um lugar, cada reunio no deve
ultrapassar os 30 minutos. Durante este tempo o Scrum Master cumpre o
seu papel em colocar as referidas questes e em resolver todas as decises
necessrias. Qualquer questo no resolvida dever ser adiada para
posteriores reunies. No fim de cada Sprint, deve ser feita uma reunio para
reviso e demonstrao do Sprint. Para conduzir estas reunies deve ser
eleito um porta-voz que ir redigir algumas questes. Estas questes devem
ser resolvidas e registradas nessas reunies, gerando um histrico do grupo
no Sprint. Exemplo de questes que podem ser levantadas:

1. Qual o valor acrescentado neste incremento (Demonstrao)?

2. O que foi completado do nosso Sprint Backlog?
3. Qual o feedback por parte do Cliente do produto?
4. O que se aconteceu de relevante no grupo durante o Sprint?
5. Como que cada um se sentiu?
6. O que podemos concluir disso?
7. O que pode ser aplicado para melhorar o prximo processo Sprint?

Explicar perfeitamente as regras para que o processo corra melhor, de

como a equipe deve trabalhar em conjunto, e toda a equipe tem que
trabalhar no Sprint. Cada equipe deve demonstrar algo no fim de cada
Sprint, uma vez que o objetivo que sigam regras de auto-organizao.

Empresas procuram mtodos geis

As metodologias geis esto disponveis desde a dcada passada, porm
foi no ano de 2001 que houve a formalizao com a assinatura do manifesto
gil (Manifesto for Agile Software Development - http://agilemanifesto.org/).
Inicialmente houve uma desconfiana geral por parte da indstria de
software, certamente impulsionada pelas diferenas aos mtodos
tradicionais e as questes das dificuldades de quebra de paradigmas por
parte das pessoas. Nesta poca tornou-se bastante famosa a metodologia
XP (eXtreme Programming), pois propunha sem hipocrisia uma srie de
mtodos polmicos, muitos deles questionveis at hoje como por exemplo
a programao em pares e o cliente ao lado do desenvolvedor durante o
projeto.
Lentamente, a indstria de software impulsionada pela necessidade de
obter resultados diferentes dos obtidos pelos mtodos tradicionais, verificou
que pessoas vlidas estavam propondo mtodos srios e factveis. Desta
forma, determinadas prticas geis comearam a ser utilizadas em projetos
de software sem a agressividade2 pela adoo plena de uma metodologia
gil.
Alguns destes mtodos, compreendidos de forma inadequada, causavam
uma dificuldade de percepo dos resultados. Um timo exemplo disto a
iterao. Iterao (iteration), que em traduo simples quer dizer repetio,
confundido com "interao" ou compreendido como processos repetveis.

Na verdadeira definio gil, iterao est mais para processos confiveis

do que processos repetveis. Na lingua inglesa tambm verificamos este
desentendimento quando estudamos em textos geis as palavras
"repeatable" e "reliable".
A confuso entre confivel e repetvel acontece porque muitos gestores
de empresas gostam de formalizar processos muito estruturados e precisos
(repetveis) no lugar de formalizar processos suficientemente estruturados e
flexveis (confiveis). Processos repetveis focam na entrada das atividades,
processos confiveis focam no resultado das atividades.
Outros mtodos, por oferecerem propostas mais simples de compreenso
e apurao de resultado, comearam a chamar a ateno positivamente da
indstria de software. Face a isso, iniciou-se um movimento liderado pelas
universidades no Brasil (hoje sou consultor de metodologias geis da USP)
que objetiva esclarecer os mtodos e gerar contedos prticos que facilitem
a implantao de tais propostas metodolgicas.
Certificadas de que estes mtodos funcionam, as empresas de software
comearam a estudar uma proposta de metodologia classificada como gil,
que prope novos mtodos em substituio aos mtodos praticados
tradicionalmente. Este critrio de escolha, que em minha opinio est
suficientemente maduro, buscou primeiramente resolver as questes acerca
da organizao, distribuio e controle das atividades de um projeto de
software. Eis a explicao da escolha da metodologia SCRUM pelo mercado
de empresas desenvolvedoras de software.

CONCLUSO

Tem-se usado o SCRUM, atualmente, por fornecer um mecanismo de

informaes devidamente atualizado, utilizando a diviso explcita de
tarefas dentro da equipe, sendo que qualquer metodologia de processo
pode utilizar a filosofia do SCRUM para garantir boas prticas sobre os
projetos. Esses so alguns dos benefcios obtidos com o uso da metodologia
SCRUM:
diminuio dos riscos;
maior integrao entre os membros das equipes;
rpida soluo de problemas;
progresso medido continuamente;
os clientes se tornam parte da equipe de desenvolvimento;

 entregas freqentes de funcionalidades funcionando;

discusses dirias de status com a equipe;
os profissionais de negcios e tecnologias trabalham juntos. Com todo
esse entrosamento entre a equipe de desenvolvimento e com a participao
ativa dos clientes o rendimento do projeto aumenta e os requisitos e
solicitao de alterao passa a ser entendido mais rapidamente, devido ao
explcito entrosamento de todos os participantes do desenvolvimento.