Linha de Código - Uma metodologia ágil - SCRUM Page 1 of 3

segunda-feira, 4 de abril de 2011 Busca

Artigo

Uma metodologia ágil - SCRUM

Por: Fabio Camara

MVP VSTS, MCT, MCP, MCSD, MCTS, MCPITP, MCPD, MSF Practitioner, Certified SCRUM Master,
Certified ITIL Foundations. Escreveu mais de 15 livros nesta última década. Atua como consultor
de produtividade em desenvolvimento de projetos e professor de disciplinas ágeis de engenharia
de software. Pode ser localizado no site http://www.fcamara.com.br.

Feed de artigos.

Feed de artigos deste autor.

Gere seu feed personalizado Assunto

Uma metodologia ágil - SCRUM

Publicado em: 03/11/2008

Introdução

Das muitas definições sobre agilidade que podemos encontrar em livros, revistas e na internet,
uma das que mais gosto é: _ "Agilidade é a habilidade de criar e responder a mudanças com
respeito ao resultado financeiro do projeto em um turbulento ambiente de negócios. Agilidade é
a habilidade de balancear flexibilidade com estabilidade". (Highsmith, Jim. Agile Project
Management, 2002)

Agilidade é uma proposta de desenvolver projetos com uma estrutura e organização

"suficientes". Muita estrutura e organização reduz a criatividade e a flexibilidade de suportar
mudanças, pouca estrutura e organização permeia a ineficiência e resulta em esforços maiores
que os necessários.

A diferença entre caos e agilidade pode ser verificada nos produtos resultantes. Considerando o
mesmo cenário turbulento de negócios1, nas equipes que convivem com o caos verificamos
atrasos constantes, baixissíma qualidade dos sistemas, problemas com estimativas e estouro de
orçamento. Nas equipes que utilizam-se de métodos ágeis percebemos entregas parciais
constantes, interação com clientes para revisão de estimativas e orçamento conjuntamente com
antecedência salutar ao projeto e principalmente dois pontos fundamentais: compromisso com a
satisfação do cliente e responsabilidade com o resultado financeiro do projeto.

Empresas procuram métodos ágeis

As metodologias ágeis estão disponíveis desde a década passada, porém foi no ano de 2001 que
houve a formalização com a assinatura do manifesto ágil (Manifesto for Agile Software
Development - http://agilemanifesto.org/).

Inicialmente houve uma desconfiança geral por parte da indústria de software, certamente
impulsionada pelas diferenças aos métodos tradicionais e as questões 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 série de métodos
polêmicos, muitos deles questionáveis até hoje como por exemplo a programação em pares e o
cliente ao lado do desenvolvedor durante o projeto.

Lentamente, a indústria de software impulsionada pela necessidade de obter resultados

diferentes dos obtidos pelos métodos tradicionais, verificou que pessoas válidas estavam
propondo métodos sérios e factíveis. Desta forma, determinadas práticas ágeis começaram a
2
ser utilizadas em projetos de software sem a agressividade pela adoção plena de uma
metodologia ágil.

Alguns destes métodos, compreendidos de forma inadequada, causavam uma dificuldade de

percepção dos resultados. Um ótimo exemplo disto é a iteração. Iteração (iteration), que em
tradução simples quer dizer repetição, é confundido com "interação" ou compreendido como
processos repetíveis. Na verdadeira definição ágil, iteração está mais para processos confiáveis
do que processos repetíveis. Na lingua inglesa também verificamos este desentendimento
quando estudamos em textos ágeis as palavras "repeatable" e "reliable".

A confusão entre confiável e repetível acontece porque muitos gestores de empresas gostam de
formalizar processos muito estruturados e precisos (repetíveis) no lugar de formalizar processos
suficientemente estruturados e flexíveis (confiáveis). Processos repetíveis focam na entrada das
atividades, processos confiáveis focam no resultado das atividades.

Outros métodos, por oferecerem propostas mais simples de compreensão e apuração de

resultado, começaram a chamar a atenção positivamente da indústria 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 métodos e gerar conteúdos práticos que
facilitem a implantação de tais propostas metodológicas.

http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=2084 4/4/2011
Linha de Código - Uma metodologia ágil - SCRUM Page 2 of 3

Certificadas de que estes métodos funcionam, as empresas de software começaram a estudar

uma proposta de metodologia classificada como ágil, que propõe novos métodos em
substituição aos métodos praticados tradicionalmente. Este critério de escolha, que em minha
opinião está suficientemente maduro, buscou primeiramente resolver as questões acerca da
organização, distribuição e controle das atividades de um projeto de software. Eis a explicação
da escolha da metodologia SCRUM pelo mercado de empresas desenvolvedoras de software.

SCRUM, muito simples de usar

A metodologia SCRUM está entrando na moda aqui no Brasil, após já haver conquistados
inúmeras empresas da indústria de software na América do Norte.

Particularmente, eu considero o SCRUM uma proposta extremamente prática e honesta. Defino

por prática neste contexto a facilidade de compreensão e aplicação em nosso ambiente de
desenvolvimento de software. Defino por honesta a fidelidade entre a proposta do método e o
resultado que podemos obter após aplicá-lo.

SCRUM, nome utilizado inicialmente pelos japoneses Hirotaka Takeuchi e Ikujiro Nonaka,
descrevia um tipo de processo de desenvolvimento de produto utilizado no Japão.Também o
nome SCRUM foi escolhido pela similaridade entre o jogo de Rugby e o tipo de desenvolvimento
de produto comentado. Ambos são adaptativos, rápidos e promovem a auto-organização.

3
Para explicar SCRUM, utilizarei uma estratégia que foi usada pelo Ken Schwaber em seu livro
chamado Agile Project Development with SCRUM. Na minha leitura, este é o melhor livro
disponível lançado até a presente data.

Iniciando um projeto, há uma formalização de todas as coisas que se pretende fazer ou que se
precisar construir no projeto. Cada item desta lista representa um requisito funcional, ou
requisito não funcional, ou questão de tecnologia / infra-estrutura. Esta lista é denominada
Product Backlog.

Podemos traduzir Product Backlog como uma lista de todos os requisitos de um produto
priorizados, ou, em outras palavras, é qualquer coisa que represente um trabalho que precisa
ser feito para o produto. Os itens com maior prioridade nesta lista são os requisitos mais
desejados pelo produto. No projeto real, o Product Backlog nunca é finalizado. Existe uma
natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer,
requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se
permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner
pode priorizar o Backlog.

O Product Owner possui a responsabilidade de definir a ordem que os requisitos serão

produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e
capaz de desenvolver todos os requisitos. Esta equipe recebe o nome de SCRUM Teams. A
preparação dos trabalhos é denominada SPRINT Planning.

SPRINT Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de

desenvolvimento da equipe, as condições e exigências do negócio, as características da
tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. A
mistura são revisões, administração e organização. Os resultados são SPRINT Goal e SPRINT.

O SCRUM Team deve desenvolver os itens separados pelo Product Owner em um determinado
prazo previamente combinado. Este prazo é definido como Time Box e o trabalho de
desenvolver os itens separados neste time box é denominado SPRINT. Estes itens separados
do Product Backlog fazem parte de uma nova lista. Esta lista, chamada SPRINT Backlog, será
de total responsabilidade do SCRUM Team que deverá mantê-la e organizá-la de tal forma a
atender os objetivos do específico SPRINT.

É permitido ter mais de um SCRUM Team trabalhando no mesmo Product Backlog, por isso os
requisitos são devidamente separados em SPRINT Backlog distintos por equipe. Uma idéia deste
ciclo é verificada na imagem abaixo.

Figura 1 - Ciclo demonstrando SPRINT

A liderança destas equipes é exercida por um papel denominado SCRUM Master. O SCRUM
Master é um facilitador da gestão dos requisitos e direcionador da gestão das equipes. Este
papel deve garantir a correta utilização das práticas de SCRUM, deve ajudar a equipe a tomar
decisões e apoiar a equipe para adquirir os recursos necessários para o desenvolvimento do
produto.

Este método de liderança é exercido através de 3 recorrentes tipos de reunião: SCRUM Daily
Meeting, SPRINT Review e Retrospective. Começando pelo SPRINT Review que é a reunião
típica de final de SPRINT (alguns SCRUM Team também a fazem no meio do SPRINT) para
validar o produto executável que a equipe conseguiu incrementar.

Explicando a Retrospective, é uma reunião que também acontece ao final do SPRINT com o
objetivo de fortalecer a unidade de ação da equipe. Três perguntas deverão ser respondidas
com seriedade por todos os membros do SCRUM Team:

1- O que você fez e gostou neste SPRINT?

2- O que você fez e não gostou neste SPRINT?
3- O que você vai fazer diferente no próximo SPRINT?

http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=2084 4/4/2011
Linha de Código - Uma metodologia ágil - SCRUM Page 3 of 3

O desenvolvimento de projetos de software é um desafio constante, é uma atividade complexa.

Todo processo complexo exige uma intensa comunicação entre todos os membros do projeto.
SCRUM Daily Meeting é a resposta para promover a comunicação da equipe.

Todos os dias, obrigatoriamente, todo o SCRUM Team irá se reunir por 15 minutos
aproximadamente para responder a 3 importantes perguntas. Sugerimos que está reunião seja
de pé, pois temos verificado bons resultados em nossas práticas.

As perguntas são:

1- O que eu fiz desde a última SCRUM Daily Meeting até agora?

2- O que eu vou fazer hoje?
3- O que pode me impedir?

Adicionalmente as técnicas apresentadas neste artigo, temos observado que a utilização de

KANBAN (ver figura abaixo) ajuda a maximizar o compromentimento da equipe e a
comunicação de todos os comprometidos e envolvidos com o projeto.

Figura 2 - Nossa implementação de KANBAN na empresa REPOM dirigida pelo SCRUM Master Marcelo Martins. As
cores amarela e laranja representam diferentes complexidades das atividades. A cor pink representa atividades
não planejadas no SPRINT que foram incluídas por motivo de força maior.

Por se tratar de um extenso assunto, abordaremos detalhes explicativos sobre o que é KANBAN
e como se utiliza em projetos de software no nosso próximo artigo técnico.

Para saber mais recomendamos os livros:

• Agile Project Management by Jim Highsmith.

• Agile Software Development with SCRUM by Ken Schwaber e Mike Beedle.
• Agile Project Management with SCRUM by Ken Schwaber.
• Treinamento MSF Agile + SCRUM + Agile Methods em http://www.fcamara.com.br

Considerações Finais

Nós, praticantes das metodologias ágeis, acreditamos que todos os projetos são diferentes. A
tecnologia destes projetos são diferentes. As pessoas, os requisitos idem. Nós não queremos ser
indivíduos críticos do que existe há muito tempo na engenharia de software, nós queremos
sugerir, proporcionar e fundamentar alternativas novas para resolver problemas antigos.

Na grande maioria das consultorias que ministro sob a titulação de "coaching" para fins de
crescimento dos resultados qualitativos e produtivos de equipes de desenvolvimento de
software, encontro pessoas que utilizando-se de métodos tradicionais ou simplesmente de
improviso diário (também denominado "ausência de métodos") revelam-me uma estranha e
frustante sensação - A Síndrome do Trabalho Vazio.

A STV é a sensação que ocorre depois de um intenso dia de trabalho repleto de aborrecimentos
e de atividades urgentes, quando percebe-se que no final todas as atividades planejadas para
aquele dia não puderam ser implementadas. É uma constatação que se é uma espécie de
marionete do tempo, da empresa e dos clientes.

A utilização de métodos ágeis, com a adequação mental conforme os princípios estabelecidos

pelas metodologias ágeis, mudaram minha vida profissional perante o cenário anteriormente
descrito. Eu consigo fazer atividades planejadas, consigo priorizar atividades importantes e
tenho um pequeno índice de atividades urgentes no meu dia-a-dia. Eu me sinto protagonista do
meu dia.

As metodologias ágeis são uma positiva proposta para as empresas desgastadas com os
resultados proporcionados por "waterfall approach to software development" ou pela ausência
de métodos. Para iniciantes em metodologias ágeis, eu recomendo o SCRUM. Para praticantes
de métodos ágeis que não conhecem o SCRUM, permitam-se mais uma evolução.

Sucesso em seus projetos.

© Copyright 2011 - Todos os Direitos Reservados a DevMedia

www.devmedia.com.br | www.javafree.org | www.linhadecodigo.com.br

Política de privacidade e de uso | Anuncie | Fale conosco

http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=2084 4/4/2011