UNIVERSIDADE FEDERAL FLUMINENSE

RMULO ROCHA

METODOLOGIA GIL - SCRUM

Niteri
2013

RMULO ROCHA

METODOLOGIA GIL - SCRUM

Trabalho de Concluso de Curso submetido ao Curso de Tecnologia em Sistemas de Computao da Universidade

Federal Fluminense como requisito parcial para obteno do Tecnlogo em Sistemas de Computao.

Orientador:
Leandro Soares de Sousa,
Talita de Oliveira Ferreira,
Alexandre Domingues Gonalves ou
Cristiano Grij Pitangui

NITERI
2013

RMULO ROCHA

METOLOGIA GIL
SCRUM
Trabalho de Concluso de Curso submetido ao Curso de Tecnologia em Sistemas de Computao da Universidade
Federal Fluminense como requisito parcial para obteno do Tecnlogo em Sistemas de Computao.

Niteri, 21 de Janeiro de 2013.

Banca Examinadora (provisrio):

_________________________________________
Prof. Leandro Soares de Sousa, Msc. Avaliador
UFF - Universidade Federal Fluminense
_________________________________________
Profa. Talita de Oliveira Ferreira, Msc. Avaliador
UFRJ Universidade Federal do Rio de Janeiro

_________________________________________
Prof. Alexandre Domingues Gonalves, Msc. Avaliador
UFF - Universidade Federal Fluminense

_________________________________________
Prof. Cristiano Grij Pitangui, Msc. Avaliador
UFRJ Universidade Federal do Rio de Janeiro

Dedico este trabalho aos meus familiares e

amigos que trilham a estrada da vida junto
comigo apoiando meus esforos e dedicao na minha carreira profissional.

AGRADECIMENTOS

A Deus, responsvel por todas as ddivas

que temos.

A minha orientadora Juliana Mendes pelo estmulo e ateno que me concedeu durante o
curso.

Aos Colegas de curso pelo incentivo e troca

de experincias.

A todos os meus familiares e amigos pelo apoio e colaborao.

Com organizao e tempo, acha-se o segredo de fazer tudo e bem feito.

Pitagoras

RESUMO

O SCRUM um framework gil que atua no gerenciamento de projetos. O amadurecimento do desenvolvimento de software tem levado o mercado a atuar com o foco
voltado para o resultado. s metodologias geis se prope a dar o resultado necessrio solicitada pelo mercado cada vez mais exigente e competitivo. De modo que
precisamos estudar, usar, divulgar e amadurecer os princpios geis visto que muito
pouco existe disponvel sobre o assunto. Assim, meu objetivo expor como surgiram s metodologias geis, seus benefcios e problemas, bem como a melhor forma
de implant-la usando experincias reais e tcnicas j aplicadas. O material usado
baseado nos mais conceituados autores do Scrum como o Ken Schwaber e Alex
Armstrong e na minha experincia na aplicao do Scrum. Portanto apresento os
princpios geis, o framework SCRUM e tcnicas j aplicadas para implantao desse framework gil.
Palavras-chaves: SCRUM, metodologia gil e implantao.

ABSTRACT

The Scrum is an agile framework that operates in the management of projects. The
maturation of software development is making the market acting with focus turned to
result. The agile methodology is proposed to give the market required result, each
time more increasingly demanding and competitive. Then, we need study, use, share
and mature the agile principles, because there is no enough material available about
this subject. So, my target is expose how agile methodology arose, its benefits and
problems, as well as the best way to implant it using real experiences and techniques
already applied. The material used is based on the most respected SCRUM authors
as Ken Schwaber and Alex Armstrong and in my own experience in applying
SCRUM. Therefore, I present the agile principles, the SCRUM framework and the
techniques already applied to implant SCRUM.

Key words: SCRUM, agile methodology and implantation.

LISTA DE ILUSTRAES

Ilustrao 1 - Modelo de Desenvolvimento em Cascata .........................................18

Ilustrao 2 Modelo de Desenvolvimento Iterativo e Incremental ........................20
Ilustrao 3 Eventos do Scrum.............................................................................29
Ilustrao 4 - Modelo de User Story ........................................................................33
Ilustrao 5 - Quadro basedo no Kanbam com burndown chart .............................35
Ilustrao 6 - Processo de Integrao Contnua .....................................................41
Ilustrao 7 - Procedimento para Contagem de Ponto de Funo ..........................44
Ilustrao 8 - Mind Map ...........................................................................................46
Ilustrao 9 - Plano de Teste...................................................................................47
Ilustrao 10 - Story Test ........................................................................................48
Ilustrao 11 - Tipos de Testes ...............................................................................49
Ilustrao 12 Certificaes Scrum da Scrum Alliance ..........................................55

LISTA DE TABELAS

Tabela 1 - Modelo de Desenvolvimento em Iterativo e Incremental ........................22

Tabela 2 - Exemplo de Product Backlog .................................................................34

LISTA DE ABREVIATURAS E SIGLAS

CMMI

- Capability Maturity Model Integration

MPS.BR - Melhoria de Processos do Software Brasileiro

RUP

- Processo Unificado da Rational

PMBOK

- Project Management Body of Knowledge

SCRUM

- Framework gil de desenvolvimento

KANBAN - Controle de fluxo de produo

FDD

- Feature-Driven Development

IC

- Integrao Contnua.

XP

- Extreme programming.

PF

- Ponto de Funo.

SUMRIO

INTRODUO ................................................................................................... 15

MODELOS DE DESENVOLVIMENTO............................................................... 16

2.1

MODELO EM CASCATA .......................................................................... 16

2.2

ITERATIVO E INCREMENTAL................................................................. 18

2.3

DESENVOLVIMENTO INCREMENTAL ................................................... 19

2.4

DESENVOLVIMENTO ITERATIVO .......................................................... 19

METODOLOGIAS GEIS .................................................................................. 21

3.1

MANIFESTO GIL ................................................................................... 22

3.1.1
3.2
4

METODOLOGIAS GEIS EXISTENTES ................................................. 23

SCRUM .............................................................................................................. 24
4.1

TIME DO SCRUM .................................................................................... 25

4.1.1

Product Owner (PO) ............................................................................. 25

4.1.2

Scrum Master ....................................................................................... 26

4.1.3

Equipe de Desenvolvimento ................................................................. 26

4.2

EVENTOS DO SCRUM ............................................................................ 27

4.2.1

Sprint .................................................................................................... 28

4.2.1.1

Reunio de Planejamento ................................................................ 28

4.2.1.2

Reunies Dirias .............................................................................. 29

4.2.1.3

Reunio de Reviso ......................................................................... 30

4.2.1.4

Reunio de Retrospectiva ................................................................ 30

4.3

PRINCIPAIS CONCEITOS E PRINCPIOS DO MANIFESTO GIL .... 22

ARTEFATOS DO SCRUM ....................................................................... 31

4.3.1

User Stories ......................................................................................... 31

4.3.2

Product Backlog ................................................................................... 32

4.3.3

Sprint Backlog ...................................................................................... 33

Como implantar o framework SCRUM ............................................................... 34

5.1

ADAPT ..................................................................................................... 35

5.2

Treinamento ............................................................................................. 36

5.3

Equipes MULTIFUNCIONAIS ................................................................... 36

5.4

Utilizando tcnicas geis para desenvolvimento ...................................... 37

5.4.1

Design Simples e Padronizao de Cdigo ......................................... 37

5.4.1.1
5.4.2

Integrao Contnua ............................................................................. 38

5.4.3

Pair Programming ................................................................................ 40

5.5

Medindo produtividades com o Scrum ..................................................... 41

5.5.1

Planning Poker ..................................................................................... 41

5.5.2

Ideal Day .............................................................................................. 42

5.5.3

Pontos de Funo ................................................................................ 43

5.6

TESTES DE SOFTWARE e o SCRUM ................................................... 45

5.6.1

Artefatos ............................................................................................... 45

5.6.1.1

Mind Map ......................................................................................... 45

5.6.1.2

Plano de Teste ................................................................................. 46

5.6.1.3

Story Test ......................................................................................... 48

5.6.2

Tipos de Testes .................................................................................... 49

5.6.2.1

Testes Unitrios ............................................................................... 49

5.6.2.2

Testes Funcionais ............................................................................ 50

5.6.2.3

Testes Exploratrios ........................................................................ 50

5.6.2.4

Testes de Performance e Carga ...................................................... 51

5.6.3
6

Geradores de Cdigo ....................................................................... 38

Realizando Testes geis ...................................................................... 51

Certificaes ...................................................................................................... 52
6.1

SCRUM.ORG ........................................................................................... 53

6.1.1

Professional Scrum Master (PSM) ....................................................... 53

6.1.2

Professional Scrum Developer (PSD) .................................................. 53

6.1.3

Professional Scrum Product Owner (PSPO) ........................................ 54

6.2

SCRUM ALLIANCE .................................................................................. 54

6.2.1

Certified Scrum Master (CSM) ............................................................. 55

6.2.2

Certified Scrum Product Owner (CSPO) .............................................. 55

6.2.3

Certified Scrum Developer (CSD) ........................................................ 55

6.2.4

Certified Scrum Professional (CSP) ..................................................... 56

6.2.5

Certified Scrum Trainer (CST) .............................................................. 56

6.2.6

Certified Scrum Coach (CSC) .............................................................. 56

CONCLUSES PROVISRIAS................................................................................ 58
REFERNCIAS BIBLIOGRFICAS .......................................................................... 59

15

1 INTRODUO

A aplicao de processos como o CMMI e MPS.BR, de metodologias como o

RUP e das boas prticas de gerenciamento de projeto incentivadas pelo PMBOK
so muito importantes, pois, amadureceram

o processo de desenvolvimento de

software proporcionando mais controle, detalhamento e mais qualidade no desenvolvimento de software. No entanto, ainda existe a possibilidade de evoluir e melhorar os processos e metodologias existentes, bem como a criao de novas abordagens para o desenvolvimento de software.
Assim, esse trabalho apresenta um estudo terico dos modelos de desenvolvimento de software mais conhecido, ou seja, o modelo cascata e o modelo iterativo e
incremental. Alm disso, apresentar um framework conhecido como SCRUM, que
tem como objetivo promover a unio e cooperao mtua dos envolvidos em um
projeto para executarem a planejamento do projeto corretamente e da maneira mais
gil possvel.
O captulo 1 a introduo do trabalho. No captulo 2 sero abordados os modelos de desenvolvimento mais utilizados e como o modelo iterativo e incremental
serve como base para as metodologias geis. O captulo 3 falar sobre a necessidade das metodologias geis e seus princpios. O capitulo 4 destacar o SCRUM
como metodologia gil explicando as regras, papis, eventos e artefatos. O captulo
5 explicar como implantar a metodologia. O captulo 6 destacar brevemente quais
so as certificaes existentes hoje em dia. E o captulo 6 ser a concluso do trabalho.

16

2 MODELOS DE DESENVOLVIMENTO

Um modelo um algo que serve para ser reproduzido, no caso do desenvolvimento de software, modelo um conjunto de processos e aes que so utilizados
no desenvolvimento de software. Os modelos de desenvolvimento de software so
importantes para orientar, controlar e organizar as atividades necessrias para desenvolver um software.
Entre os modelos de desenvolvimento de software conhecidos, o Modelo em
Cascata, e o Iterativo e Incremental se destacam por proporcionarem maior controle
das atividades do projeto. O Modelo em Cascata o mais tradicional por parecer
mais simples e organizado, alm de ser citado na maioria dos livros de engenharia
de software desde da dcada de 70 , porm o modelo Iterativo e Incremental veio
para substitu-lo porque esse modelo no linear, rgido e monoltico como o Modelo em Cascata. As metodologias geis so baseadas no modelo Iterativo e Incremental.

2.1

MODELO EM CASCATA

Com surgimento na dcada de 70, o Modelo em Cascata tornou-se o mais aceito e usado at o aparecimento do modelo Iterativo e Incremental. No Modelo em
Cascata as atividades so estruturadas de uma forma que cada fase tenha entradas,
ou seja, informaes como requisitos, regras de negcios, especificaes e necessidades provenientes do cliente e sadas que so novas informaes aperfeioadas
durante a fase atual que sero utilizadas na prxima fase do projeto ou simplesmente armazenadas ao final do projeto. A Ilustrao 1 mostra um exemplo do Modelo em
Cascata com fases distintas e onde cada fase produz informaes para a prxima
at o final do projeto.

17

Ilustrao 1: Modelo de Desenvolvimento em Cascata

Fonte: WIKIPEDIA

No modelo em cascata existe um fluxo seqencial das atividades e a codificao s acontece depois de um estudo detalhado dos requisitos e da sua especificao.
Conforme Pressman (2001, p 30) o problema do Modelo em Cascata que ele
linear, ou seja, cada atividade somente ser executada quando a outra tiver sido
terminada e avaliada. Os projetos raramente seguem o fluxo seqencial. difcil para os clientes afirmarem explicitamente todos os requisitos e o cliente precisa ter pacincia para receber a verso do software funcionando porque o processo desde a
anlise at a construo de todo o software demorado. Um erro maior pode ser
detectado somente na homologao do sistema, causando um prejuzo muito grande.
Ainda em seu texto Preesman (2001 p 30) cita um problema comum encontrado nesse modelo, o blocking states, que ocorre quando membros de um time so
obrigado a esperar outros membros desse time terminarem suas tarefas dependentes para continuarem as suas. Esse tempo de espera pode exceder o tempo gasto
com o trabalho.
Embora o modelo em cascata tenha seus pontos fracos, continua sendo melhor utiliz-lo do que no ter um modelo de desenvolvimento de software.

18
2.2

ITERATIVO E INCREMENTAL

O modelo Iterativo e Incremental surgiu para tentar solucionar os problemas

provenientes do modelo em Cascata, como por exemplo: falta de acompanhamento
do cliente durante o projeto, entrega do produto somente no final do projeto, atividades no so paralelizadas, tempo de espera excessivo, entre outros. Os padres
mais conhecidos que tomam como base o modelo Iterativo e Incremental so o RUP
(Processo Unificado da Rational) e o desenvolvimento gil. Por esse motivo o modelo iterativo e incremental tambm uma base para o SCRUM .
Como podemos ver na Ilustrao 2, o modelo Iterativo e Incremental dividido
em fases com menor durao e com uma entrega de software funcionando ao final
de um ciclo e a fases so reiniciadas seguindo esse fluxo at o fim do projeto.

Ilustrao 2: Modelo de Desenvolvimento em Iterativo e Incremental

Fonte: Segundo IBM 2005

19
2.3

DESENVOLVIMENTO INCREMENTAL

A estratgia do desenvolvimento Incremental fornecer ao cliente o projeto em

partes para que possa ser analisado durante todo o processo de levantamento e desenvolvimento antecipando assim, problemas que no foram detectados durante o
detalhamento dos requisitos e sua especificao. Tambm so realizadas muitas
atividades em paralelo, como levantamento de novos requisitos, desenvolvimento de
partes do software, testes, entre outros antecipando os prazos para concluso do
sistema.
O desenvolvimento Incremental embora resolva uma srie de problemas encontrados no modelo em Cascata, exige que seja feito um controle muito maior nas
atividades realizadas bem como dos requisitos que esto evoluindo para que o escopo do projeto no ultrapasse o planejado inicialmente.
Conforme Pressman (2011, p 780) outro ponto de ateno relacionado arquitetura do sistema. Como o projeto Incremental nem todas as situaes so previstas inicialmente sendo necessrio evolues na arquitetura o que aumenta o risco
de atraso do projeto.

2.4

DESENVOLVIMENTO ITERATIVO

Desenvolvimento iterativo envolve melhorar o sistema progressivamente aumentando os seus detalhes a cada iterao existe mais detalhamento que leva o
produto aos poucos ficar encorpado.
Existem muitas vantagens nessa abordagem, pois o cliente est mais prximo
do desenvolvimento verificando o que est sendo produzido em intervalos mais curtos do que os praticados no modelo em cascata, possibilitando correes mais rpidas caso exista desvio no planejamento. Tanto a equipe de desenvolvimento quanto
os usurios do sistema amadurecem os seus conceitos e idias sobre o negcio, arquitetura e requisitos do sistema durante o projeto. Utilizando esse modelo altera-

20
es podem ser acrescentadas mais facilmente. Porm nesta forma de trabalho
necessrio maior controle do escopo, prazo e custo do projeto.

21

3 METODOLOGIAS GEIS

Conforme Steffen (2012, p1), os profissionais da rea de TI esto cometendo erros ao planejar um projeto e ao executar o planejamento. De acordo com a
Tabela 1, em 2009 apenas 32% dos projetos entregues so considerados sucesso,
24% so puro fracasso (cancelados, ou engavetados - nunca colocados em produo ou utilizados pelo cliente), 44% so desafiados (sofreram atrasos, estouraram o
oramento, no atendem as necessidades, esto cheios de defeitos). Esses dados
estatsticos mostram que necessrio a busca de solues para os problemas encontrados nos modelos de desenvolvimento de software mais utilizados como o
Cascata e o Iterativo e Incremental.
1994

1996

1998

2000

2002

2004

2006

2009

Bem sucedido

16%

27%

26%

28%

34%

29%

35%

32%

Desafiado

53%

33%

46%

49%

51%

53%

46%

44%

Falho

31%

40%

28%

23%

15%

18%

19%

24%

Tabela 1: Modelo de Desenvolvimento em Iterativo e Incremental

Fonte: Standish Group (2011)

Conforme (HIGHSMITH, 2004) ser gil em TI significa a habilidade de criar e

responder a mudanas, buscando a obteno de lucro em um ambiente de negcios
turbulento ou ainda a capacidade de balancear a flexibilidade e a estabilidade. (HIGHSMITH, 2004) mostra que a tanto a falta de estrutura ou estabilidade pode levar a
problemas, mas que a estruturao demasiada gera rigidez que impede o progresso
conforme desejado.

Todo esse cenrio abriu caminho para o nascimento das metodologias que
so denominadas geis. Entretanto, antes das afirmaes realizadas por HIGHSMITH em (HIGHSMITH, 2004) especialistas em processos de desenvolvimento de

22
software se reuniram em 2001 com o objetivo de evoluir e amadurecer processos
em busca do que HIGHSMITH falou anos depois, o equilbrio entre flexibilidade e
estabilidade. Assim foi criada a Aliana gil e estabelecido o Manifesto gil.
Diante disso, este captulo descreve estas metodologias geis e como utilizlas no desenvolvimento de software.

3.1

MANIFESTO GIL

Com o objetivo de discutir maneiras de melhorar as prticas de desenvolvimento de software, 17 profissionais experientes na rea de software se reuniram nos
EUA, em 2001 e criaram o Manifesto gil, que um grupo de princpios que devem
reger o desenvolvimento de software. As prximas subsees apresentam os conceitos e princpios que so a base para as metodologias geis.

3.1.1 PRINCIPAIS CONCEITOS E PRINCPIOS DO MANIFESTO GIL

O manifesto gil composto por conceitos e princpios que guiam o desenvolvimento de software.
Segundo AGILEMANIFESTO.ORG (2001) os conceitos so:

1) Pessoas e interaes, ao contrrio de processos e ferramentas.

2) Software executvel, ao contrrio de documentao extensa e confuso.
3) Colaborao do cliente, ao contrrio de constantes negociaes de contratos.
4) Respostas rpidas para as mudanas, ao contrrio de seguir planos previamente definidos.

23
Conforme AGILEMANIFESTO.ORG (2001) alguns princpios geis so:

Priorizar a entra de software em um curto perodo de tempo, como por exemplo poucas semanas a poucos meses.

Tratar mudanas de requisito imediatamente.

As equipes de negcio e desenvolvimento trabalharem juntas. Conversas face a face.

3.2

Motivar todos os participantes.

Primar pela simplicidade.

Vistoriar regularmente o processo de trabalho e aprimor-lo.

METODOLOGIAS GEIS EXISTENTES

Algumas metodologias geis foram criadas antes do manifesto gil e outras foram surgindo com conceitos e tcnicas baseadas nos princpios do manifesto gil.
As metodologias geis mais empregadas so: Extreme Programming (XP), SCRUM,
Lean Development, Feature-Driven Development (FDD), Kanban, RUP e OpenUp.

Conforme Steffen (2012) as pesquisas mostram que o SCRUM o framework

mais utilizado por ser o mais simples e de fcil adoo e adaptao. Cada framework gil tem suas caractersticas e prticas sugeridas, porm a aplicao de um
framework gil amadurece conforme a necessidade das corporaes, ou seja, um
processo customizado conforme as caractersticas e necessidades corporativas.

A simples aplicao de um framework gil como o SCRUM no resolve todos

os problemas da corporao. O SCRUM com suas prticas geis evidenciam os
pontos fracos para que sejam tomadas medidas para soluo. Ser necessria atuao pr-ativa para que os benefcios possam aparecer.

24

4 SCRUM

Esse captulo ir descrever o framework SCRUM, como os eventos necessrios para o seu funcionamento, as caractersticas do time do SCRUM e os artefatos
utilizados.
Um framework dentro do qual pessoas podem tratar e resolver
problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possvel. (S-

CHWABER E SUTHERLAND, 2011, p 3)

Conforme Sutherland e Schwaber (2011), autores do guia do Scrum, o Scrum

no um processo ou tcnica, mas um framework com papis, eventos, artefatos e
regras que tem como objetivo aprimorar o processo de desenvolvimento de software. Assim, necessrio um ou mais processos e tcnicas j existentes seja usado
em conjunto com o framework do Scrum. comum utilizar o Scrum juntamente com
o RUP e as boas prticas estipuladas no PMBOK.
O Scrum baseado no empirismo. O empirismo se prope a aprimorar baseado na experincia. Fundamentado nesse conceito pode-se dizer que o Scrum utiliza
o modelo iterativo e incremental para prever e controlar riscos durante o desenvolvimento de um sistema.
Segundo Sutherland e Schwaber (2011) existem trs caractersticas que suportam a implantao do Scrum, so eles: transparncia, inspeo e adaptao.
A transparncia necessria para que os principais stakeholders, ou seja,
principais interessados do projeto, tenham a visibilidade correta do que est acontecendo. E para isso necessrio haver uma linguagem nica e bem divulgada entre
todos os envolvidos alm de um conceito nico do que est pronto.
A inspeo feita com freqncia para verificao de desvios no planejamento
previamente estabelecido. recomendado que um especialista que domine o ambiente de trabalho com seus conceitos e linguagens padronizadas atue na inspeo
para que a avaliao seja a melhor possvel.

25
A adaptao necessria para concertar qualquer desvio que esteja acontecendo e tenha sido detectado pelo especialista que far a inspeo. Com os ajustes
realizados imediatamente aps serem detectados so minimizados os riscos de entregar de um produto que est fora dos padres acordados.

4.1

TIME DO SCRUM

De acordo com Sutherland e Schwaber (2011) o SCRUM utiliza os seguinte papis para compor a equipe: Product Owner, Scrum Master e a equipe de desenvolvimento. Essa equipe multifuncional e auto-organizvel, ou seja, so capacitados
para decidir como produzir o trabalho e resolver os problemas da melhor forma possvel sem interveno externa.

4.1.1 Product Owner (PO)

O Product Owner (PO) representado por uma pessoa e no por um grupo. O

PO o principal responsvel pelo produto que est sendo criado. O PO faz o gerenciamento do escopo do projeto e a priorizao das atividades do time do SCRUM.
Entre suas atribuies encontra-se a responsabilidade de clarificar os requisitos do
sistema, ou seja, tirar todas as dvidas sobre os requisitos e avaliar se o produto foi
entregue com o valor necessrio e dentro das especificaes.
Para cumprir com suas atribuies o PO cria uma lista de requisitos do sistema, conhecido como Product Backlog. O PO faz verificaes constantes no Product
Backlog e prioriza quais itens sero abordados em cada Sprint ou iterao, criando o
Sprint Backlog.
Segundo Sutherland e Schwaber (2011) ningum pode direcionar a equipe de
desenvolvimento, acrescentar ou retirar itens do produck backlog seno o PO. Mesmo que um comit seja utilizado para definies do sistema e suas regras de neg-

26
cio, dever existir uma nica pessoa fazendo o papel do PO e somente essa pessoa
poder interagir com a equipe de desenvolvimento e alterar o product backlog.

4.1.2 Scrum Master

O Scrum Master desenvolve um papel gerencial e tem como objetivo garantir

que as regras do SCRUM sejam entendidas e aplicadas. O Scrum Master atua como
um facilitador para a equipe de desenvolvimento retirando qualquer impedimento
que exista que atrapalhe o trabalho da equipe de desenvolvimento.
Entre suas atribuies esto: divulgar e treinar equipe de desenvolvimento e
stakeholders nas prticas do framework, ajudar a equipe de desenvolvimento a ser
auto-gerencivel e multidisciplinar, aplicar os eventos do SCRUM e gerenciar qualquer impedimento que exista para no atrapalhar a equipe de desenvolvimento.

4.1.3 Equipe de Desenvolvimento

O tamanho ideal da Equipe de Desenvolvimento pequeno

o suficiente para se manter gil e grande o suficiente para
completar uma parcela significativa do trabalho. (SCHWABER E SUTHERLAND, 2011, p 3)

Segundo o conceito de Sutherland e Schwaber (2011) a equipe de desenvolvimento no pode ser menor que trs e maior que nove havendo em ambos os casos perda de produtividade ou devido a falta de habilidades necessrias ou devido a
grande necessidade de coordenao de um grande grupo.
A equipe de desenvolvimento deve ser multidisciplinar e no pode depender de
recursos externos para finalizar o trabalhado designado para o Sprint como tambm
no deve ter subreas dentro dessa equipe que cuidam apenas do teste ou do ne-

27
gcio. Essa equipe auto-gerenciveis, assim ela tem capacidade para dizer como
o trabalho ser feito para alcanar o seu objetivo.

4.2

EVENTOS DO SCRUM

Os eventos do SCRUM so ocasies pr-estabelecidas com um objetivo e

tempo mximo definido. Esses eventos so indispensveis para ser criada uma rotina de inspeo e minimizar o nmero de reunies quem podem tomar tempo desnecessrio e energia que deve ser voltado para a construo do produto de valor
que ser entregue ao cliente.
As regras do SCRUM estabelecem os seguintes eventos:

Sprint.

Reunio de Planejamento.

Reunies dirias.

Reunio de Reviso.

Reunio de Retrospectiva.

Ilustrao 3: Eventos do Scrum.

Fonte: Capgemini (2011)

28
4.2.1 Sprint

Um Sprint tem durao de um ms ou menos e no fim desse perodo um produto de valor dentro das especificaes anteriormente combinadas deve ser entregue. Esse produto entregue um incremento do produto final. O objetivo de manter
o tamanho de uma Sprint em um ms minimizar o risco de mudana e ajuda o processo emprico de aprendizagem. Aps o trmino do Sprint um novo deve comear
imediatamente.
Cada Sprint composto pelos seguintes eventos: reunio de planejamento, reunies dirias, reunies de reviso e retrospectiva. Durante o Sprint deve ser objetivo geral no mudar o escopo, no mudar a equipe, no diminuir a qualidade esperada.
A Sprint no deve ser cancelada a menos que o seu objetivo j no faa mais
parte da estratgia da corporao, embora isso dificilmente acontece devido a durao de no mximo um ms de cada Sprint.

4.2.1.1 Reunio de Planejamento

A reunio de planejamento um evento que tem durao de no mximo oito

horas para um Sprint de um ms. Quando a Sprint tem durao menor que um ms
a tendncia que a reunio de planejamento seja menor. Alm disso, a experincia
da equipe usando o SCRUM um fator que influencia na durao da reunio, pois
equipes mais experientes no uso do SCRUM tendem a ter mais agilidade no planejamento.
A reunio dividida em duas partes, a primeira cuidar em definir o que ser
feito e a segunda parte como ser feito. Na primeira parte o PO prioriza quais itens
do Product Backlog so indicados para construo e ajuda a equipe de desenvolvimento a entender o que ser feito. Para definio do nmero de itens que sero
construdos ser levado em conta a produtividade histrica da equipe nas Sprints
anteriores e a capacidade estimada da equipe. Somente a equipe de desenvolvi-

29
mento pode determinar o que realmente ser completado ao final da Sprint. Assim
fica definido o objetivo da Sprint.
Na segunda parte da reunio a equipe de desenvolvimento divide os itens em
tarefas de oito horas de durao que podem ser feitas por recursos diferentes da
equipe. Essas tarefas sero realizadas e inspecionadas diariamente para controle da
Sprint e adaptao quando necessrio. Se aps a diviso dos itens se perceber que
o trabalho menor ou maior do que suportado durante a Sprint os itens do backlog
podem ser rearranjados. Nessa reunio importante o PO participar para clarificar
questes necessrias. Outras pessoas podem ser convidadas para fornecer ajudar
tcnica em domnios especficos.

4.2.1.2 Reunies Dirias

O framework SCRUM utiliza reunies dirias do time de desenvolvimento no

seu processo para facilitar a comunicao entre o time e a soluo de problemas
que possam surgir, alm de possibilitar a reavaliao do plano de execuo das atividades submetendo-o a algum ajuste se necessrio.

A Reunio Diria do Scrum um evento time-boxed de 15

minutos, para que a Equipe de Desenvolvimento possa sincronizar as atividades e criar um plano para as prximas 24
horas. (SCHWABER E SUTHERLAND, 2011, p 10)

A reunio diria deve ser feita no mesmo horrio todos os dias. Durante essa
reunio devem ser respondidas por cada membro da equipe as seguintes trs perguntas:
1) O que foi feito desde a ltima reunio?
2) O que ser feito agora?
3) Quais problemas foram encontrados?.

30
Durante essa reunio a equipe de desenvolvimento inspeciona o que foi feito e
avalia o progresso em direo do objetivo da Sprint. A equipe deve ser capaz em
explicar claramente o que est sendo feito. Embora o Scrum Master assegure que
se realizem as reunies dirias a responsabilidade da conduo dela da equipe.

4.2.1.3 Reunio de Reviso

Esse evento realizado ao final de cada Sprint. Essa reunio utilizada para
inspeo dos principais stackholders do projeto no produto entregue. Durante essa
reunio todos podem dar sua opinio e colaborar para o prximo incremento de
software. Essa reunio deve ter durao de quatro horas para uma Sprint de um
ms.

4.2.1.4 Reunio de Retrospectiva

Essa reunio ocorre logo aps a reunio de reviso. Os participantes dessa reunio devem ser a equipe de desenvolvimento, o PO e o Scrum Master. uma ocasio para equipe de desenvolvimento, analisar o que deu certo e o que deu errado.
Aps essa anlise, deve ser feito um planejamento para que os problemas no ocorram novamente.
Melhorias devem ser identificadas e um plano de ao deve ser feito para a
prxima Sprint. O Scrum Master pode orientar a equipe nas melhores prticas do
SCRUM para que maximize seu desempenho na Sprint seguinte. Fica claro que esas reunio um momento para inspeo e adaptao.

31
4.3

ARTEFATOS DO SCRUM

O framework do SCRUM no tem muitos artefatos. Por esse motivo necessrio utilizar um processo bem conhecido como o RUP que foi desenvolvido pela
Rational Software e atualmente propriedade da IBM, para apoiar o desenvolvimento de sistema principalmente porque os clientes de fbricas de software exigem em
seus contratos especificaes detalhadas, evidncias de teste e qualidade, artefatos
de gerenciamento entre outros.

4.3.1 User Stories

User Stories so utilizadas para organizar requisitos assim como os Casos de

Uso, porm, segundo MARTIN FOWLER User Stories focalizam as necessidades do
usurio e como o sistema atende essas necessidades e os Casos de Uso descrevem aes de iterao segundo uma narrativa impessoal entre o usurio e o sistema.
As User Stories devem fracionar os requisitos para estimar o esforo para atender as necessidades dos usurios, ou seja, devem ser descries simples da
funcionalidade, curtas e claras.
De acordo com a Ilustrao 3, pode-se escrever uma User Story especificando
o Ator, a Ao e a Funcionalidade. O Ator o proprietrio da User Story, ou seja, o
usurio ou o principal interessado nela. A Ao o que o ator deseja que o sistema
faa. A Funcionalidade o que o ator espera que acontea ao realizar a ao, ou
seja, o resultado esperado.

32

Ilustrao 4: Modelo de Use Story.

Fonte: Blog MyScrumHalf.

4.3.2 Product Backlog

O Product Backlog uma lista dos itens do produto que sero implementados,
ou seja, a lista de requisitos desse produto. O PO o principal responsvel por essa
lista, bem como por sua priorizao.
Essa lista nunca est fechada totalmente, mas os itens so aqueles que so inicialmente conhecidos. O Product Backlog deve evoluir juntamente com o conhecimento sobre o que ser feito. Essa prtica no comum para projetos com escopo
fechado que tentam utilizar o SCRUM.

33

Tabela 2: Exemplo de Product Backlog.

Fonte: ScrumAlliance (2005)

4.3.3 Sprint Backlog

O Sprint Backlog so os itens que foram selecionados para uma determinada

Sprint. Essa lista criada mediante a priorizao do PO e a avaliao da equipe de
desenvolvido do que possvel ser feito baseado no desempenho histrico da equipe e na sua capacidade produtiva.
O Sprint Backlog pode ser alterado ao passo que atividades vo surgindo durante a Sprint para que exista controle do que est sendo feito. Cada item do Sprint
backlog foi dividido anteriormente em atividades de oito horas e ao passo que o conjunto de atividades que compe um item do backlog terminada a estimativa de trabalho restante reavaliada.
Para melhor controle do itens que esto sendo feitos em geral utilizado o
quadro do Kanbam, como mostra a Ilustrao 3, como apoio para realizar as atividades bem como um burndown chart que aponta visualmente o desempenho da equipe.

34

Ilustrao 5: Quadro basedo no Kanbam com burndown chart.

Fonte: Rafael Donato (2000)

5 COMO IMPLANTAR O FRAMEWORK SCRUM

Fazer a implantao de uma nova metodologia envolve muito trabalho e dedicao. necessrio uma mudana de viso e comportamento em toda a instituio,
promoo dos benefcios proporcionados pela mudana, treinamento dos indivduos,
acompanhamento e suporte na aplicao da nova metodologia.

35
5.1

ADAPT

Conforme COHN afirma, para introduzir Scrum na sua organizao necessrio seguir algumas etapas que correspondem a sigla ADAPT, que significa em portugus:

Conscincia (Awareness).

Desejo (Desire).

Competncia (Ability).

Promoo (Promotion).

Transferncia (Transfer).

Conscincia (Awareness) - Nessa etapa a organizao entende que o processo que est sendo usando no traz os resultados pretendidos.

Desejo (Desire) - A organizao passa a desejar aplicar o Scrum como uma

forma de resolver os problemas detectados. Nessa etapa os benefcios do Scrum
devem ser apresentados pelos promotores do Scrum na organizao para os principais Stakeholds e fazer uma prova de conceito aplicando as novas prticas durante um perodo pequeno, como por exemplo trs meses.

Competncia (Ability) - Equipes so capacitadas durante essa fase para que

tenham a competncia necessria para utilizar o Scrum.

Promoo (Promotion) - Deve ser publicado na organizao as histrias de

sucesso da aplicao do Scrum. Tambm possvel atrair a ateno e interesse em
reunies ou eventos.

Transferncia (Transfer) - Ser necessrio transferir o conhecimento adquirido para outros departamentos da empresa, como recursos humanos, logstica, marketing, recursos financeiros entre outros, pois esses departamentos embora no

36
precisem utilizar o Scrum, precisaro se adaptar um pouco para potencializar as
vantagens da utilizao do Scrum.

O processo ADAPT iterativo, ou seja, ele deve ser aplicado sucessivamente

para consolidar a adoo do Scrum na organizao.

5.2

TREINAMENTO

O principal responsvel em treinar e promover o Scrum na organizao o Scrum Master ou um grupo de Scrum Masters. Por meio de palestras educativas, treinamento tcnico de profissionais, acompanhamento e suporte aos profissionais o(s)
Scrum Master(s) se certifica(m) que as pessoas envolvidas tenham competncia necessria para utilizar o Scrum.
Durante o projeto so realizadas reunies dirias e reunies ao final de cada
Sprint. Essas reunies so ocasies que o Scrum Master deve utilizar para inspecionar a aplicao do Scrum pela equipe e caso a equipe ou algum membro dela ainda precise de treinamento, o Scrum Master deve providenci-lo.

5.3

EQUIPES MULTIFUNCIONAIS

Uma equipe multifuncional uma equipe onde os seus membros tem caractersticas diversificadas para lidar com todas as fases de um projeto. Os membros
dessa equipe deve estar habilitados levantar requisitos, entender do negcio,
construir a aplicao e test-la. No existem sub-equipes no Scrum, como por exemplo: Equipe de negcio ou equipe de testes.
Essas equipes so auto-organizadas. Nem mesmo o Scrum Master pode dizer
a equipe como realizar o seu trabalho. Essa equipe responsvel por traar o plano
de execuo do trabalho e diariamente inspecionar o progresso do seu prprio trabalho. Nessas equipes no existem ttulos a no ser o de Desenvolvedor.

37
Embora individualmente os integrantes da equipe possam ter habilidades especializadas, a equipe responsvel pela entrega do incremento de produto ao fim
de cada Sprint.
Segundo Suderland e Schwaber, o tamanho da equipe de desenvolvimento
deve ser pequeno suficiente para se manter gil e grande o suficiente para completar uma parcela significativa de trabalho, ou seja, no deve ser menor, que trs integrantes e maior que nove. Se a equipe tiver menos de trs integrantes o resultado
ser um menor ganho de produtividade e se for maior que nove ser necessrio
muita coordenao e equipes muito grandes trazem complexidade para um processo emprico gerenciar.
Os papis do Product Owner e do Scrum Master no devem ser includos na
equipe de desenvolvimento, a menos que eles executem algum trabalho do Backlog
do Sprint.

5.4

UTILIZANDO TCNICAS GEIS PARA DESENVOLVIMENTO

Existem tcnicas de desenvolvimento gil que podem ser aplicadas no dia

dia para ajudar a equipe de desenvolvimento entregar o produto dentro do prazo e
qualidade estipulados no planejamento do projeto. Essas tcnicas de desenvolvimento gil abrangem reas como arquitetura de software, planejamento e gerenciamento de atividades, soluo de problemas e utiliza ferramentas que automatizam
tarefas repetitivas.

5.4.1 Design Simples e Padronizao de Cdigo

Um design simples, ou seja, uma arquitetura de software simples porm adequada a necessidade importante para que se ganhe agilidade no desenvolvimento
de software. Quanto mais complexa e quanto mais componentes um arquitetura ti-

38
ver, mais demorado ser o desenvolvimento do produto. Alguns desenvolvedores
podem no estar familiarizados com os muitos componentes diferentes ou com o
ambiente tecnolgico muito complexo, resultando em mais tempo gasto no estudo
do novo componente ou da arquitetura complexa.
A padronizao de cdigo tambm importante para que os desenvolvedores
tenham mais agilidade para criar e resolver problemas inerentes ao desenvolvimento
de software. Caso um projeto tenha padronizaes de cdigo diferentes, os desenvolvedores gastaro tempo valioso tentando entender o novo padro de cdigo antes de atuar na concluso de uma atividade. Tambm quando existe padronizao
de cdigo, um desenvolvedor pode herdar uma atividade que estava sendo feita por
um outro desenvolvedor com mais facilidade.
O arquiteto o responsvel pelo design simples da aplicao e pela padronizao de cdigo. O arquiteto deve treinar a equipe e dar suporte durante o desenvolvimento do produto.

5.4.1.1 Geradores de Cdigo

Quando o design da aplicao simples e existe padronizao de cdigo,

possvel construir geradores de cdigo que otimizam o trabalho por gerar cdigo padro e repetitivo. Existem ferramentas como o Velocity do Apache Jakarta Project, o
Transformica ou CodeFSW que geram cdigo a partir de templates e parmetros de
entrada como nome da funcionalidade, conexo com banco de dados entre outros.
Caso seja utilizado uma ferramenta de gerao de cdigo o tempo de desenvolvimento pode ser diminudo.

5.4.2 Integrao Contnua

Integrao Contnua uma pratica de desenvolvimento

de software onde os membros de um time integram seu

39
trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente podendo haver mltiplas integraes por dia. Cada integrao verificada
por um build automatizado (incluindo testes) para detectar erros de integrao o mais rpido possvel. Muitos times acham que essa abordagem leva a uma significante reduo nos problemas de integrao e permite
que um time desenvolva software coeso mais rapidamente. (MARTIN FOWLER, 2006)

Conforme exemplificado na Ilustrao 4, os passo do processo de integrao

contnua so: 1) O Desenvolvedor comita o cdigo no repositrio do cdigo fonte. 2)
O servidor da IC detecta que ocorreram algumas alteraes no cdigo fonte e executa o script de compilao da aplicao, o que envolve compilar os fontes, fazer
testes automatizados, gerar relatrios de qualidade e mtricas e disponibilizar a verso. 3) O Servidor retorna por email ou de outra forma o resultado da compilao,
tenha ela sucesso ou no para a equipe responsvel pelo projeto. 4) O Servidor continua vasculhando o repositrio do cdigo fonte para ver se encontra novas alteraes.
Os benefcios da integrao contnua so reduo do risco de termos problemas na integrao do sistema, ganho de agilidade por reduo de processos repetitivos, melhor visibilidade do projeto baseado nos relatrios e mtricas emitidos e um
produto mais confivel.
As ferramentas de IC mais conhecidas atualmente so: Hudson, Criuse Control, Continuum e o Tem City.

40

Ilustrao 6: Processo de Integrao Contnua.

Fonte: Paul Duvall (2007)

5.4.3 Pair Programming

O Pair Programming, ou seja, programao em pares, uma tcnica do Extreme Programming, porm, as equipes que trabalham com desenvolvimento gil frequentemente usam essa tcnica e no diferente com as equipes que usam SCRUM.
Segundo PRESMAN (20 , p 65) o XP recomenda duas pessoas trabalharem
juntas em uma estao de trabalho, pois, isso fornece um mecanismo de soluo de
problemas e garantia de qualidade. Na prtica, cada desenvolvedor deve assumir
um papel diferente. Por exemplo, um desenvolvedor est focado em pensar nos detalhes de cdigo de uma parte especfica do projeto enquanto o outro desenvolvedor

41
garante que as normas de codificao esto sendo seguidas e que essa parte do
cdigo se integrar com facilidade ao restante do projeto.
Os benefcios dessa prtica so cdigo com melhor qualidade e passagem de
conhecimento para o time de desenvolvimento. A passagem de conhecimento ajuda
outros desenvolvedores da equipe aumentarem suas habilidades e se tornarem mais
valiosos.

5.5

MEDINDO PRODUTIVIDADES COM O SCRUM

Produtividade significa capacidade de produzir, caracterstica do que produz

com abundncia ou lucratividade. Em outras palavras, produtividade obter a melhor relao entre volume produzido e recursos consumidos.
Medir a produtividade importante porque segundo Pressman (2006) para um
projeto ter maior probabilidade de ser bem sucedido necessrio aplicar mtricas
para entender, predizer e controlar o desenvolvimento, pois no h como ter uma
preciso ou controle naquilo que no se pode mensurar.
Para medir produtividade necessrio realizar estimativas. Por esse motivo,
abordaremos as principais tcnicas de estimativa e medio aplicadas ao desenvolvimento gil nesse subtpico, sendo elas Planning Poker, Ideal Day e Ponto de Funo.

5.5.1 Planning Poker

Todo projeto precisa ser estimado e depois sua execuo planejada. Segundo
GRENNING a melhor maneira de times geis estimarem o projeto usando a tcnica conhecida como Planning Poker. Planning Poker uma abordagem colaborativa
onde os componentes do team de desenvolvimento opinam sobre o tempo necessrio para concluir determinadas tarefas do projeto.

42
Todos os componentes da equipe participam do planejamento, o que inclui testadores, arquitetos, analistas designers entre outros. O Product Owner participa do
planejamento, mas no participa da estimativa.
Cada participante do Planning Poker recebe um conjunto de cartas com uma
numerao como 0,1,2,3,5,8,13,20,40 e 100. O Produtct Owner l, explica e tira dvidas da equipe a cerca de uma User Story. Aps isso, cada membro da equipe seleciona uma carta com o valor que acha apropriado para a estimativa de construo
dessa User Story e aps todos terem escolhido sua carta, elas so postas na mesa.
Caso haja divergncias significativas entre os componentes da equipe, cada um tem
a oportunidade de explicar o seu ponto de vista e feito uma nova rodada de Planning Poker com novas estimativas de todos os componentes da equipe. Novas rodadas podem ocorrer at que a equipe tenha convirja para uma nica estimativa ou
estimativas muito prximas.
Segundo FLOWER, o Planning Poker funciona, pois, primeiro ele usa mltiplas
opinies de especialistas em um time multifuncional. Segundo, existe um dilogo entre os especialistas para justificar suas estimativas e correes podem ser feitas com
base em opinies de outros. Em terceiro lugar, os estudos mostraram que a mdia
de estimativas individuais conduz a um melhor resultado (Hoest e Wohlin 1998), assim como discusses em grupo (Jrgensen e Molkken 2002). E quarto, Planning
Poker funciona porque divertido.

5.5.2 Ideal Day

Segundo F. Alves, M. Alves e Fonseca (2008) Ideal Day representa o total de

trabalho que um profissional capaz de realizar em um dia de trabalho.
Para se calcular a velocidade em que realizada o trabalho feito um calculo
a partir do nmero de horas que a equipe gasta para implementar um trabalho equivalente a um Ideal Day (Martins 2007). Caso o item passe um dia de trabalho, sugerido decompor esse item em itens menores que se consiga implementar em apenas um dia.

43
Segundo Martins (2007) a formula abaixo deve ser utilizada para calcular os dias estimados para realizar o trabalho:

Sendo:
DE: quantidade de dias estimado para concluir a tarefa;
IED: prazo necessrio para implementar o item, esse prazo definido pela
equipe;
IED_REAL%: percentual que indica a estimativa de quanto tempo do dia o desenvolvedor ficara dedicado a implantao do item.

5.5.3 Pontos de Funo

Conforme Hazan (2001), pontos de funo uma medida de dimensionamento

de software atravs da funcionalidade implementada em um sistema, sob o ponto de
vista do usurio.
A contagem por ponto de funo o mtodo mais maduro que existe e com
maior suporte, pois existem muitas organizao e profissionais habilitados para trabalho com esse mtodo. Alm disso, existe o IFPUG International Funcion Point
Users Group que responsvel pelo aprimoramento e evoluo da tcnica desde
1986.
Alguns benefcios de se utilizar o ponto de funo so:

1) Possibilidade de medir o tamanho funcional do software.

2) Controle das atividades do projeto.
3 ) Melhor acompanhamento na produtividade da equipe.

44
4) Controle da qualidade e custos de desenvolvimento.
5) Previso do projeto, pois realiza-se uma estimativa nas fases iniciais do
desenvolvimento do software.

Para a contagem do ponto de funo so realizadas sete etapas, como

representada na ilustrao abaixo:

Ilustrao 7: Procedimento para contagem de ponto de funo.

Fonte: HAZAN (2001)

45
5.6

TESTES DE SOFTWARE E O SCRUM

De acordo com Pressman, o principal objetivo dos testes de software localizar erros, falhas, defeitos e a verificao das funcionalidades do software em desenvolvimento ou finalizado. Assim possvel revelar problemas em um produto antes
de entreg-lo ao cliente, corrigindo esses defeitos e proporcionando uma melhor
qualidade ao produto.
O framework do Scrum no tem um papel fixo de analista de teste, mas sim
uma equipe capaz de realizar vrios tipos de tarefas e que est envolvida em todos
as fases do processo de desenvolvimento, desde a especificao at a entrega,
sendo toda a equipe responsvel pela qualidade do projeto. Por esse motivo, necessrio entender como os testes devem ser realizados e por quem. Assim, o trabalho apresentar a seguir quais os tipos de artefatos criados, os tipos de testes existentes e como realiz-los de maneira gil.

5.6.1 Artefatos

O framework do Scrum no determina artefatos especficos para os testes, porm incentiva que toda documentao seja o mais simples possvel, evitando desperdcio de tempo mantendo muita documentao.
Para realizar os teste pode ser utilizados artefatos como Plano de Teste, Story
Test e Mind Map, detalhados a seguir.

5.6.1.1 Mind Map

Segundo Crispin, Mind Maps so uteis para planejar o sistema, os testes, a criao das User Story e dos Story Test durante as reunies iniciais de brainstorm, ou

46
seja, nas reunies onde so expostos todos os objetivos e detalhes inicias sem uma
organizao prvia.
Durante a fase de levantamento e entendimento dos requisitos, o PO esclarece dvidas e ajuda a equipe montar uma interligao entre as funcionalidades e
saber os critrios de aceitao para cada User Story. Nesse caso o Mind Map ajudar a equipe de SCRUM a organizar as ideias iniciais e transform-las em artefatos
que sero utilizados nos Sprints.
Abaixo um exemplo de Mind Map.

Ilustrao 8: Mind Map.

Fonte: CRISPIN (2009).

5.6.1.2 Plano de Teste

Segundo Andrade o Plano de Teste o documento principal dos testes de

software, pois nele esto informaes importantes sobre as partes envolvidas no

47
teste, os objetivos do teste, as funcionalidades a serem testadas, os critrios para
aceitao do produto e os passos que sero dados para executar os testes.
Cada plano de testes possui a descrio de um ou mais casos de teste. Um
caso de teste tambm um artefato que tem um conjunto de aes que devem ser
executadas e pelo menos um critrio de aceitao para servir como base para saber
se o teste foi bem sucedido ou no. Nesse trabalho adotaremos o termo Story Test
para se referir o um caso de teste, visto que a base para produo de caso de teste
ser uma User Story.
Embora o Scrum no cite o Plano de Teste entre os artefatos utilizados no framework, no existe objeo para o uso dele. Abaixo temos uma Ilustrao representando um Plano de Teste.

Ilustrao 9: Plano de Teste.

Fonte: ANDRADE.

48
5.6.1.3 Story Test

Segundo Andrade o Caso de Teste, ou seja, uma Story Test um artefato que
contm os procedimentos para teste. Esse artefato deve incluir descrio dos testes
e seus objetivos, pr e ps condies do teste e os inputs e outputs esperados.
Nos procedimento de teste utilizando SCRUM, segundo Crispin pode ser criado
um Story Test para cada User Story. Como a equipe de desenvolvimento multidisciplinar, todos os membros podem participar na confeco dos Story Test e executlos.
Abaixo na Ilustrao 9 temos um exemplo de Story Test.

Ilustrao 10: Story Test.

Fonte: CRISPIN (2009).

49
5.6.2 Tipos de Testes

Segundo Crispin, os testes que podem ser aplicados em um software podem

ser divididos em quatro quadrantes que servem para orientar as equipes no seu planejamento, sendo eles, testes unitrios, testes funcionais, testes exploratrios e tese
de performance e carga.
Abaixo a Ilustrao 11 mostra quatro quadrantes com os tipos de teste.

Ilustrao 11: Tipos de Teste.

Fonte: CRISPIN (2001)

5.6.2.1 Testes Unitrios

Testes unitrios so pequenos pedaos de cdigo feitos pela equipe para assegurar que os componentes do sistema iro funcionar. Os testes unitrios se estendem ao banco de dados, lgica de negcio, camada de apresentao, comunicao de rede, entre outros aspectos.

50
Os testes unitrios podem ser integrados com uma ferramenta de Integrao
Contnua que a cada atualizao do software executar os testes novamente para
fazer uma varredura em busca de um possvel erro.
Quando a equipe codifica e evolui os testes unitrios juntos com o sistema o
software ser entregue ao cliente com mais qualidade. Segundo Crispin, sem os testes do quadrante 1, os testes unitrios, os outros testes sero muito mais complicados, pois provavelmente se encontraro mais problemas.

5.6.2.2 Testes Funcionais

Testes funcionais so testes que avaliam o comportamento das funcionalidades criadas. Todo o time do SCRUM responsvel por realizar esse tipo de teste e
podem utilizar todos os artefatos disponveis para orient-los durante o teste, artefatos como Mind Maps, Plano de Teste, Story Test, Flow Diagrams, entre outros.
Segundo Crispin, os testes funcionais devem ser usados para orientar a fase
de desenvolvimento, garantindo assim que o software entregue ao cliente esteja atendendo todos os requisitos solicitados. Alm disso, nenhuma User Story deve ser
dada como finalizada at que sejam realizados os testes com sucesso.

5.6.2.3 Testes Exploratrios

Segundo Crispin, os testes exploratrios so uma avaliao do produto recriando as experincias atuais do cliente, um uso realstico do produto, expondo-o a
cenrios que o produto ser realmente submetido. Nessa etapa podem ser criados
demos, ou seja, verses ainda no finalizadas, para serem testadas com o cliente no
seu ambiente. Os testes exploratrios podem ser executados pelo cliente juntamente com PO ou outro membro da equipe que tenha conhecimento profundo sobre o
projeto.

51
Os testes exploratrios executados juntos com o cliente ajudaro a ambos aprenderem com a experincia e talvez detectar erros ou problemas que no foram
pensados na fase de prototipao do produto. Durante os testes exploratrios pode
ser feita uma observao cuidadosa e uma anlise crtica sobre o produto e melhorias podem ser apontadas.
Durante os testes exploratrios devem ser utilizados dados reais, o processo
real de execuo do produto e sua usabilidade deve ser testada.

5.6.2.4 Testes de Performance e Carga

O objetivo dos testes de performance e carga testar a performance, a estabilidade, a confiabilidade, a escalabilidade, a compatibilidade, entre outras caractersticas do produto. Tambm devem ser testados o gerenciamento de memria dos
servidores, rotinas de recuperao e migrao de dados caso exista.
Esses testes devem ser planejados por especialistas, porm todo o time do
SCRUM tem a responsabilidade de participar nesses testes, seja codificando rotinas
para facilitar o testes, seja para criar sobrecarga ou monitorar o uso do sistema.

5.6.3 Realizando Testes geis

Segundo Crispin o que faz um time gil focar continuamente em fazer o melhor trabalho e entregar o melhor produto possvel. Isso envolve disciplina, aprendizado, tempo, experincia e trabalho em equipe. De modo que, testadores geis esto continuamente procurando por meios na qual o time pode cada vez melhorar
mais seu trabalho, o que pode envolver conhecer os procedimentos de outros times,
testar novas ferramentas para especificar, executar e automatizar os testes.

52
Alem disso, segundo Crispin os componentes de uma equipe gil devem desejar aprender mais, desenvolver novas habilidades, aceitar novos desafios e no se
limitar a resolver os mesmos tipos de problemas.
Segundo Crispin, alguns princpios para realizar testes geis so:

1. Prover contnuo feedback.

2. Comunicao face a face.
3. Manter as coisas simples.
4. Praticar melhoria contnua.
5. Organizao pessoal.
6. Focar em pessoas.
7. Apreciar o trabalho.

6 CERTIFICAES

Certificar ato de declarar formalmente a veracidade de um fato. Um certificado emitido por uma fonte que tenha credibilidade ou autoridade para atestar um
fato. No mbito tecnolgico um certificado pode ser emitido garantido o conhecimento do profissional aps uma prova com contedo especfico e previamente designado para uma determinada certificao.
No caso do SCRUM as duas instituies mais acreditadas capazes de certificar
que um profissional est capacitado para trabalhar com SCRUM so a Scrum.org e
a Scrum Alliance.

Uma diferena bsica entre elas que para fazer as certifica-

es da Scrum Alliance o profissional tem que fazer um curso e depois um teste,

enquanto as certificaes da SCRUM.ORG o profissional no precisa fazer o curso,
apenas o teste. A seguir so explicados cada tipo de certificao feito por cada uma
dessas instituies.

53
6.1

SCRUM.ORG

A SCRUM.ORG foi fundada em 2009 por Ken Schwaber, um dos fundadores

do SCRUM. Desde ento a SCRUM.ORG se tornou referencia no mercado para
treinamento e certificao de profissionais com SCRUM.

6.1.1 Professional Scrum Master (PSM)

Segundo SCRUM.ORG, essa certificao permite que os profissionais validem

seu entendimento das prticas do framework e como elas podem ser aplicadas a situaes desafiadoras do dia a dia.
Existem duas opes de certificao para Scrum Master, a PSM I e a PSM II.
Essas certificaes so sequenciais, significando que obrigatoriamente o profissional
tem que passar na PSM I antes da PSM II. A PSM I atesta seu entendimento fundamental do SCRUM e a PSM II atesta um elevado conhecimento do framework do
SCRUM.

6.1.2 Professional Scrum Developer (PSD)

A certificao PSD I voltada para desenvolvedores de software e atesta o seu

conhecimento das prticas e tcnicas do framework do SCRUM que auxilia no desenvolvimento de software complexo.
Segundo a SCRUM.ORG o profissional que passe nesse teste demonstra conhecimento sobre desenvolvimento de software usando prticas de engenharia geis como Test-First Developement, Integrao Contnua e arquiteturas emergentes.

54
6.1.3 Professional Scrum Product Owner (PSPO)

De acordo com a SCRUM.ORG o Product Owner precisa ter uma profunda

compreenso sobre os direcionadores de valor para o seu produto, e um grande
senso de como usar prticas geis e Scrum para maximizar esse valor. Por isso, existem duas certificaes, a PSM I e PSM II. Elas tambm so sequenciais.
A certificao PSM I atesta o conhecimento fundamental do profissional do
framework do SCRUM e como aplica-lo a fim de maximizar o valor do produto. E a
certificao PSM II atesta um elevado conhecimento do framework e como aplica-lo
no dia a dia.

6.2

SCRUM ALLIANCE

A Scrum Alliance uma organizao no comercial que encoraja e suporta a

larga adoo e prtica do SCRUM. A Scrum Alliance foi fundada em 2002 e ela prov vrios servios e entre eles treinamentos e certificaes. A seguir ser detalhada
cada treinamento/certificao promovida pela Scrum Alliance.

Ilustrao 12: Treinamentos/Certificaes SCRUM da Scrum Alliance.

Fonte: Scrum Alliance (2014)

55
6.2.1 Certified Scrum Master (CSM)

Segundo a Scrum Alliance a certificao de Scrum Master atesta que o profissional entende os valores, as prticas e aplicaes do SCRUM. Habilita o Scrum
Master a ser um lder que ajuda o resto do time a trabalhar junto e aprender sobre o
framework do SCRUM. Qualifica o Scrum Master a proteger o time de distraes internas e externas.

6.2.2 Certified Scrum Product Owner (CSPO)

De acordo com a Scrum Alliance a certificao de Product Owner habilita o profissional na terminologia do Scrum, prticas, princpios que o ajudam a exercer esse
papel. Tambm como aplicar caractersticas como diligncia, pacincia e compromisso para alcanar a melhoria contnua nos projetos.

6.2.3 Certified Scrum Developer (CSD)

A certificao de Scrum Developer habilita o profissional a ter conhecimento

prtico dos princpios do SCRUM e desenvolver habilidades de engenharia gil especializada em desenvolvimento de software. O curso e a dedicao necessria para alcanar um CSD ajuda a aprimorar suas habilidades e a se tornar um melhor profissional de SCRUM.

56
6.2.4 Certified Scrum Professional (CSP)

Os profissionais Scrum certificados demonstraram experincia, formao acadmica e comprovado conhecimento na execuo de SCRUM. CSPs desafiar suas
equipes SCRUM para melhorar a forma como SCRUM e outros mtodos geis so
implementados para cada projeto. Para atingir essa certificao necessrio ter
uma das certificaes CSM, CSPO ou CSD e ter no mnimo de 36 meses aplicando
SCRUM nos ltimos cinco anos.

6.2.5 Certified Scrum Trainer (CST)

Para se tornar um CST, o profissional deve demonstrar um profundo conhecimento e compreenso dos conceitos do SCRUM, prticas e princpios. Ter uma certificao Certified Scrum Professional ativa do Scrum Alliance. Ter ampla experincia
na implementao de SCRUM dentro das organizaes como um membro da equipe, como o proprietrio do produto ou Scrum Master, ou como um mentor. J ter ensinado SCRUM em um contexto no certificado ou em parceria com a CST atual.

6.2.6 Certified Scrum Coach (CSC)

Treinadores SCRUM certificados so especialistas em SCRUM tanto na teoria

e quanto na prtica. Eles tm a compreenso profunda das prticas e princpios do
SCRUM e experincia no mundo real em projetos SCRUMs. CSCs guiam com xito
as organizaes atravs dos desafios de adoo SCRUM.

57
CSCs j ajudaram a uma ou mais organizaes efetivamente aplicar SCRUM.
Eles tm experincia diversificada em vrios sistemas organizacionais, tais como vrias equipes, produtos, ciclos de projetos, ambientes ou tecnologias.

58

CONCLUSES PROVISRIAS

Este trabalho se props a expor como surgiram s metodologias geis e seus

benefcios, bem como analisar o framework do SCRUM e a melhor forma de implant-lo. O trabalho esclarece que as metodologias geis podem fornecer a resposta
que

mercado

pede

com

respeito

ao

controle

das

atividades

preciso nas estimativas dos projetos com o objetivo de gerar mais valor aos produtos, ou seja, aos softwares.
O trabalho se desenvolveu apresentando os modelos de desenvolvimento existentes, como surgiram as metodologias geis, o manifesto gil e seus princpios. O
trabalho focou tambm em explicar como framework do SCRUM suporta o desenvolvimento gil. Detalhes do framework foram explicados, bem como o modo de aplic-lo nas atividades de planejamento, estimativa, controle, teste e exposio dos
resultados obtidos. Alm disso, o trabalho informou como implantar o framework e
qualificar profissionais para os diferentes papis existentes.
Diante do exposto possvel notar a utilidade da aplicao do framework do
SCRUM e dos princpios geis nas diversas fases do desenvolvimento de software e
nas tarefas inerentes a essas fases. Alm disso, o suporte de instituies internacionais para capacitar profissionais no uso do SCRUM reforam a estabilidade e praticidade da tcnica. Sendo o tema, as melhores tcnicas de capacitao e treinamento no uso das metodologias geis, um campo aberto para pesquisa e desenvolvimento.

59

REFERNCIAS BIBLIOGRFICAS

1. PRESSMAN, Roger S. Software Engineering, A Practitioner's approach

5th ed. Ph. D. Livro. Boston, EUA, Mc Graw Hill Editora, 2001.
2. PICHLER, Roman. Management with Scrum: creating products that customers love. Livro. EUA, Signature Book, 2010.
3. COHN, Mike. Succeeding with Agile: Software Development Using
Scrum. The Addison-Wesley Signature Series, 2009.
4. Rubin, Kenneth S. Essential Scrum. Livro, EUA, Mike Cohn Signature Book,
2012.
5. DUVALL, Paul. Continuous Integration - Improving Software Quality and
Reducing Risk. Livro. EUA. Martin Fowler Signature Book, 2007.
6. COHN, Mike. Agile Estimating and Planning. Livro. EUA. Prentice Hall,
2005.
7. FOWLER, Martin. Planning Extreme Programming. Livro. EUA. AddisonWesley Professional. 2000.
8. PRESSMAN, Roger S. Engenharia de Software: Uma abordagem Profissional. Livro. Porto Alegre, Brasil, AMH, 2011
9.

SCHWABER AND SUTHERLAND, Ken and Jeff. The Scrum Guide.

EUA. 2011.
10.

SCHWABER, K.; BEEDLE, M. Agile Software Development with

Scrum. New Jersey, Prentice Hall, 2002.

11.

SCHWABER, K. Agile Project Management with Scrum. Redmond: Mi-

crosoft Press, 2004.

12.

SCHWABER, K. The Enterprise and Scrum. Redmond: Microsoft Press,

2007.
13.

COHN, M.; FORD, D. Introducing an ADegile Process to an Organiza-

tion. Computer, v. 36,p. 74, 2003.

60
14.

AGILEMANIFESTO. Manifesto for Agile Development. Disponvel em:

http://www.agilemanifesto.org Acesso em: 30 jun.2008.

15.

CAPGEMINI. The Scrum Perspective to Agile. Disponvel em:

http://www.capgemini.com/blog/capping-it-off/2011/05/the-scrum-perspective-toagile. Acesso em: 15 mai 2011.

16.

Alves, Fernanda; Alves, Marcia; Fonseca, Isabella. Ideal Day e Prioriza-

o: Mtodos geis no Planejamento. Engenharia de Software, Rio de Janeiro, n., p.8-13, 01 nov. 2008.
17.

Hazan, Cludia. Anlise de Pontos de Funo: Uma aplicao nas esti-

mativas de tamanho de Projetos de Software. Engenharia de Software, Rio de

Janeiro, n. , p.25-30, 01 jun. 2008.
18.

Hazan, Cludia. Medio da Qualidade e Produtividade em Software.

In: WEBER,Kival Chaver; ROCHA, Ana Regina Cavalcanti; NASCIMENTO, Clia

Joseli.Qualidade e Produtividade em Software. 4. ed. So Paulo: Makron Books,
2001. p.25-41.
19.

Grenning, James. 2002, Planning Poker. Play. Estimate. Plan. Dis-

ponvel em: <http://www.planningpoker.com/>. Acesso em: 21 fev. 2014.

20.

Crispin, Lisa. 2009, Agile Testing: A Practical Guide For Testers and

Agile Teams. Addison-Wesley, Estados Unidos, 09 jan. 2009.

21.
re.

Andrade, Ana. IBM - Criao e Gerao de Planos de teste de SoftwaDisponvel em:

http://www.ibm.com/developerworks/br/local/rational/criac

ao_geracao_planos_testes_software/. Acesso em: 26/02/2014.

22.

Inthurn, Cndida. Qualidade & Teste de Software. 2. ed. Florianpolis:

Visual Books Editora, 2001. 108 p.

23.

IBM.

What

is

Disponvel

em:

https://www.ibm.com/developerworks/rational/library/apr05/bittner-spence/.

A-

cesso em: 14 abr 2005.

the

iterative

development?.