Ferramenta Planning Poker Scrum

UNIVERSIDADE FEDERAL DE PERNAMBUCO
GRADUAO EM CINCIA DA COMPUTAO

CENTRO DE INFORMTICA
2012.1
Ferramenta para apoio estimativa baseada em

Planning Poker utilizando a metodologia Scrum
TRABALHO DE GRADUAO
Dennis Williams Alves da Silveira
Recife
Julho de 2012
UNIVERSIDADE FEDERAL DE PERNAMBUCO

GRADUAO EM CINCIA DA COMPUTAO
CENTRO DE INFORMTICA
2012.1
Ferramenta para apoio estimativa baseada em

Planning Poker utilizando a metodologia Scrum
TRABALHO DE GRADUAO
Dennis Williams Alves da Silveira
Monografia apresentada junto ao curso de Cincia da

Computao do Centro de Informtica da
Universidade Federal de Pernambuco, na rea de
engenharia de software, sendo requisito parcial para
a obteno do ttulo de Bacharel.
Orientador: Alexandre Marcos Lins de Vasconcelos
Co-orientador: Sandro Ronaldo Bezerra Oliveira
Recife
Julho de 2012
A virtude est toda no esforo.

(Anatole France)
III
Agradecimentos
Primeiramente, gostaria de dedicar este trabalho aos meus pais, Fernando e Socorro,
pelo esforo e pela dedicao depositada em minha formao e pela forte influncia que
tiveram em minha vida. Foram eles quem sempre me incentivaram a seguir sempre em frente
e nunca cair diante das dificuldades. Tudo que conquistei at hoje eu devo isso a eles.
Um agradecimento muito especial ao meu irmo, Jnior, que sempre esteve junto nos
momentos de alegria e tristeza e pelas boas conversas que ns tivemos.
Quitria, que sempre ajudou a mim e minha famlia nos momentos que ns mais
precisvamos e como uma segunda me pra mim.
toda minha famlia pela grande amizade e por acreditarem em mim. Em especial aos
meus primos Bruno, Marcus, Rafa (que tambm aluno no CIn), Marina, Geny, Romero,
Thiago, Felipe e mais outros tantos primos.
Ao professor Alexandre Marcos Lins de Vasconcelos, pela oportunidade e orientao
neste trabalho. E tambm ao professor Sandro Ronaldo Bezerra Oliveira, do Centro de
Tecnologia de Informao e Comunicao da Universidade Federal do Par, pelas explicaes e
indicao de materiais valiosos para o desenvolvimento deste trabalho.
Aos amigos que fiz no CIn e em outros centros da UFPE, e ao pessoal que marcava as
peladas em Boa Viagem.
Aos professores do CIn pelo ensino de qualidade e a dedicao em passar os
conhecimentos durante o curso de graduao, fazendo com que este seja um centro de
excelncia em computao.
Enfim, a todas as pessoas com quem tive oportunidade de conversar e conhecer, pois
sempre aprendemos algo novo com a troca de conhecimentos e experincias.
IV
Resumo
Um projeto consiste de atividades realizadas por uma equipe de trabalho que atua em
busca de um objetivo comum. Para conduzir as atividades, existem diversas metodologias que
abordam uma prtica de gerenciamento de projeto, para avaliar fatores como o cronograma,
custos, qualidade e disponibilidade de recursos humanos. Dentro desse processo, pode-se
considerar que a atividade de estimar o esforo necessrio para o desenvolvimento de um
projeto um elemento fundamental para o sucesso do mesmo. Essa prtica usada tanto em
metodologias tradicionais e geis.
Dados mensurveis relevantes desses fatores so oriundos da utilizao de tcnicas de
estimativas sobre a mtrica do tamanho de um projeto, e que podem ser as mais diversas,
variando desde analogias entre projetos e baseadas na experincia do desenvolvedor, at
abordagens mais metdicas utilizando modelos matemticos.
Uma delas o Planning Poker, que uma tcnica de estimativa gil. A natureza
interativa e objetiva deste mtodo permite que equipes geis possam estimar seus requisitos
com uma velocidade impressionante e que possam ser bem assimiladas por todos os
envolvidos.
Apesar disso, o Planning Poker possui limitaes, como o fato de no funcionar bem
em equipes geograficamente distribudas, j que a prpria essncia dela a interao
presencial. Existem ferramentas disponveis para extrair estimativas nessa tcnica, cada uma
com caractersticas positivas e negativas.
Assim, o objetivo deste trabalho fazer um estudo das caractersticas dessa tcnica
juntamente com uma abordagem das ferramentas j existentes. A partir da, a ideia propor
uma ferramenta prtica e objetiva para estimar utilizando Planning Poker, com foco em
equipes Scrum, e que possa ser aplicada para o gerenciamento e acompanhamento da
evoluo do projeto.
Abstract
A project has activities carried out by a team of people who work for a common goal.
There are several methodologies for software development that are used to create a practical
approach to project management, to organize these activities and to assess factors such as
time, cost, quality and human resources. In this process, the effort estimation activity is a key
element for the success of the project. This practice has been used in both traditional and agile
methods.
Measurable data are derived from the use of estimation techniques on the project size
metric, ranging from analogies between projects based on developer experience to methodical
approaches using mathematical models.
One of these techniques is the Planning Poker, which is an agile estimation technique.
Due to the interactive and practical nature of it, agile teams can estimate and assimilate task
sizes very fast.
Nevertheless, the Planning Poker has some limitations, such as the fact that it doesnt
work well in distributed agile teams and the face-to-face interaction is the very essence of it.
There are some tools available to estimate by playing it, each one has positive and negative
features.
This final work presents a Planning Poker approach. From there, the main idea is to
propose a practical tool to estimate using this technique, focused on Scrum teams, and to be
applied to the project management and monitoring.
VI
Sumrio
1. Introduo ............................................................................................................................... 12
1.1. Objetivos .......................................................................................................................... 13
1.2. Estrutura do Documento .................................................................................................. 14
2. Metodologias geis ................................................................................................................. 15
2.1. Conceitos .......................................................................................................................... 16
2.2. Consideraes Finais ........................................................................................................ 19
3. Scrum....................................................................................................................................... 20
3.1. Ciclo de Desenvolvimento ................................................................................................ 21
3.2. Papis no Scrum ............................................................................................................... 22
Scrum Master ...................................................................................................................... 22
Product Owner .................................................................................................................... 23
Scrum Team......................................................................................................................... 23
3.3. Reunies ........................................................................................................................... 24
Sprint Planning Meeting ...................................................................................................... 24
Daily Scrum Meeting ........................................................................................................... 25
Sprint Review Meeting ........................................................................................................ 25
Sprint Retrospective Meeting ............................................................................................. 25
3.4. Artefatos........................................................................................................................... 26
Product Backlog................................................................................................................... 26
Estrias de Usurio.............................................................................................................. 26
Impediment Backlog ........................................................................................................... 29
Sprint Backlog ...................................................................................................................... 29
Burndown Chart .................................................................................................................. 29
3.5. Planejamento da Sprint .................................................................................................... 30
3.6. Scrum para Equipes Distribudas...................................................................................... 31
4. Estimativa de Software ........................................................................................................... 34
4.1. Anlise de Pontos de Funo ........................................................................................... 35
Determinar o tipo de contagem .......................................................................................... 36
Identificar a fronteira da aplicao ..................................................................................... 36
Contar as funes de dados ................................................................................................ 36
Contar as funes transacionais.......................................................................................... 37
Determinar o PF no ajustado ............................................................................................ 38
VII
Calcular Valor do Fator de Ajuste ........................................................................................ 39

Calcular os Pontos de Funo Ajustados............................................................................. 39
4.2. Anlise de Pontos de Casos de Uso .................................................................................. 39
Calculando o peso dos Atores do sistema........................................................................... 40
Calculando o Peso dos Casos de Uso .................................................................................. 40
Clculo dos Pontos de Casos de Uso no Ajustados ........................................................... 41
Clculo dos Fatores Tcnicos .............................................................................................. 41
Clculo dos Fatores Ambientais .......................................................................................... 42
Clculo dos Pontos de Caso de Uso ajustados .................................................................... 43
4.3. Planning Poker.................................................................................................................. 43
5. Ferramentas para Estimativas Usando o Planning Poker ....................................................... 49
5.1. Planning Poker.................................................................................................................. 49
5.2. FireScrum ......................................................................................................................... 51
5.3. Comparao das Ferramentas ......................................................................................... 53
6. A Ferramenta Proposta ........................................................................................................... 55
6.1. Diagrama de Casos de Uso ............................................................................................... 56
6.2. Diagrama de Classes ......................................................................................................... 60
6.3. Diagrama Entidade-Relacionamento ............................................................................... 61
6.4. Arquitetura do Sistema .................................................................................................... 62
6.5. Prottipo .......................................................................................................................... 65
7. Concluso ................................................................................................................................ 67
7.1. Trabalhos Futuros............................................................................................................. 68
Referncias Bibliogrficas ........................................................................................................... 69
Apndice A Product Backlog .................................................................................................... 73
Cadastrar Usurio.................................................................................................................... 73
Efetuar Login ........................................................................................................................... 74
Efetuar Logout ......................................................................................................................... 75
Listar Projetos.......................................................................................................................... 76
Alterar Usurio ........................................................................................................................ 77
Cadastrar Projeto .................................................................................................................... 78
Ver Projeto .............................................................................................................................. 79
VIII
Alterar Projeto ......................................................................................................................... 80

Manter Sprints ........................................................................................................................ 81
Enviar Convites ........................................................................................................................ 82
Aceitar Convites ...................................................................................................................... 83
Ver Participantes de um Projeto ............................................................................................. 84
Remover Projeto ..................................................................................................................... 84
Exibir Product Backlog ............................................................................................................. 85
Cadastrar Item......................................................................................................................... 86
Ver Item................................................................................................................................... 87
Alterar Item ............................................................................................................................. 88
Remover Item .......................................................................................................................... 89
Ver Grfico de Acompanhamento .......................................................................................... 90
Iniciar Sesso Planning Poker .................................................................................................. 91
Entrar numa Sesso Planning Poker........................................................................................ 92
Escolher Carta ......................................................................................................................... 93
Mostrar Cartas ........................................................................................................................ 94
Definir Estimativa para um Item ............................................................................................. 95
Realizar Nova Rodada ............................................................................................................. 96
Sair da Sesso .......................................................................................................................... 97
Finalizar Sesso ....................................................................................................................... 98
Chat da Sesso ........................................................................................................................ 99
Apndice B Backlog de Requisitos No Funcionais ................................................................ 100
Performance .......................................................................................................................... 100
Usabilidade ............................................................................................................................ 100
Disponibilidade...................................................................................................................... 100
Manual de Instalao ............................................................................................................ 100
Manual do Usurio ................................................................................................................ 101
Escalabilidade ........................................................................................................................ 101
Integridade ............................................................................................................................ 101
Privacidade ............................................................................................................................ 101
Legibilidade do Cdigo .......................................................................................................... 101
IX
Lista de Figuras
Figura 1. Metodologias geis nas empresas. .............................................................................. 19
Figura 2. Ciclo de Desenvolvimento do Scrum ............................................................................ 21
Figura 3. Exemplo de um carto de estria. ............................................................................... 28
Figura 4. Exemplo de testes de um carto de estria. ................................................................ 28
Figura 5. Exemplo de um Sprint Backlog. .................................................................................... 29
Figura 6. Grfico Burndown da Sprint. ........................................................................................ 30
Figura 7. Baralho de Planning Poker (Fonte: CRISP Konsulter) ................................................... 44
Figura 8. Coordenador solicita aos participantes a estimativa de uma determinada estria. ... 45
Figura 9. Integrantes da equipe tcnica escolhendo suas estimativas da estria. ..................... 46
Figura 10. Integrantes da equipe tcnica mostrando suas cartas. ............................................. 46
Figura 11. Integrantes da equipe tcnica refazendo suas escolhas para a estimativa. .............. 47
Figura 12. Tela de descrio de uma estria no Planning Poker................................................. 49
Figura 13. Tela para escolha de uma estimativa no Planning Poker. .......................................... 50
Figura 14. Tela para o moderador definir uma estimativa no Planning Poker. .......................... 50
Figura 15. Tela do mdulo de Planning Poker do FireScrum. ..................................................... 52
Figura 16. Diagrama de Casos de Uso da ferramenta. ................................................................ 56
Figura 17. Diagrama de Casos de Uso de relacionamento dos atores da ferramenta................ 57
Figura 18. Diagrama de Casos de Uso do ator Usurio. .............................................................. 57
Figura 19. Diagrama de Casos de Uso do ator Coordenador. ..................................................... 58
Figura 20. Diagrama de Casos de Uso do ator Participante. ....................................................... 59
Figura 21. Diagrama de Classes da ferramenta........................................................................... 60
Figura 22. Diagrama E-R da ferramenta. ..................................................................................... 62
Figura 23. Arquitetura da ferramenta. ........................................................................................ 63
Figura 24. Camada de apresentao. .......................................................................................... 63
Figura 25. Camada de controle. .................................................................................................. 64
Figura 26. Camada de negcio. ................................................................................................... 64
Figura 27. Camada de persistncia. ............................................................................................ 65
Lista de Tabelas
Tabela 1. Exemplo de um Product Backlog ................................................................................. 26
Tabela 2. Exemplos de estrias em um Product Backlog. ........................................................... 27
Tabela 3. Complexidade funcional para os ALI e AIE. ................................................................. 37
Tabela 4. Complexidade funcional para os EE............................................................................. 38
Tabela 5. Complexidade funcional para os SE e CE. .................................................................... 38
Tabela 6. Pesos de atores. ........................................................................................................... 40
Tabela 7. Pesos de Casos de Uso por nmero de transaes e classes. ..................................... 40
Tabela 8. Fatores e pesos de complexidade tcnica na PCU. ..................................................... 41
Tabela 9. Fatores e pesos de complexidade ambiental na PCU.................................................. 42
Tabela 10. Comparativo entre as ferramentas abordadas. ........................................................ 53
XI
Captulo 1
Introduo
A atividade de determinar o esforo necessrio para o desenvolvimento de um projeto
um elemento fundamental para o sucesso do mesmo. O esforo abrange diversos fatores
como o cronograma, o custo exigido para o desenvolvimento de produtos e os recursos
humanos do projeto e a capacidade de estimar com preciso esses elementos torna-se vital
para uma concluso efetiva. Dessa forma, pode-se dizer que estimar e planejar esto
correlacionados e que so atividades crticas em todas as abordagens de desenvolvimento de
software, inclusive em metodologias geis.
O Scrum, como uma dessas metodologias, baseada no controle de processos
empricos e emprega uma abordagem iterativa e incremental para melhorar a previsibilidade e
controlar riscos. Isso indica que as equipes Scrum no possuem tempo para formular teorias e
gerar documentos, to utilizados nas metodologias tradicionais. O foco est em ter as coisas
prontas [Kniberg 2007]. Portanto, para esta abordagem imprescindvel um modelo de
estimativas que seja rpido e eficiente.
Existe uma tcnica muito usada no Scrum, conhecida como Planning Poker, que
trabalha para estimar objetivamente. uma prtica que tem sido bem utilizada quando
equipes de trabalho se encontram num mesmo ambiente. No entanto, a dificuldade pela falta
de contato entre equipes geograficamente distantes pode atrapalhar na realizao das
estimativas. As prticas geis tm a abordagem baseada em interaes intensas entre pessoas,
portanto grande a colaborao e a comunicao informal. Infelizmente, uma das maiores
dificuldades do desenvolvimento distribudo o fato de no haver uma coordenao, controle
e comunicao constante pela ausncia de interaes presenciais [Huzita et al 2008] e isso
acarreta grandes dificuldades ao tentar interligar esses dois conceitos [Highsmith & Cockburn
2001]. Quando se encontram juntas, criam uma nova srie de desafios que precisam ser
trabalhados.
No entanto, existe um grande interesse em aplicar novas prticas que combinem as
caractersticas especficas das metodologias geis com as de desenvolvimento distribudo de
software [miteet al 2010], [Santos 2010]. Uma dessas prticas a utilizao de ferramentas
que contribuam para integrar os dois conceitos, pois elas oferecem um grande suporte de
comunicao e reduzem impactos provocados pela falta de interao direta [Santos 2010].
Alm disso, elas contribuem para a centralizao das informaes.
12
As ferramentas descritas tm a possibilidade de auxiliar projetos geis em alguns

pontos. A prtica do Planning Poker, por exemplo, seria facilitada atravs de uma ferramenta
na qual todos os membros da equipe pudessem interagir sobre ela. Na mesma, as estimativas
seriam realizadas sobre estrias de usurio (user stories) e o jogo realizado por todos os
membros, sob a orientao de um coordenador (ou Scrum Master, dentro do Scrum). No caso
de precisar debater elementos importantes de uma estria, os participantes podem debater
entre si em um espao disponibilizado na ferramenta para a comunicao entre eles.
Outro ponto, no menos importante, que as informaes do projeto so sempre
preenchidas aps cada reunio realizada pela equipe de trabalho. E esses dados costumam ser
armazenados em ferramentas parte para o controle interno. Esses documentos so
habilitados para que vrias pessoas possam edit-lo, pois muitas vezes, desenvolvedores
podem abrir o documento para alterar alguma informao vlida [Kniberg 2007].
Normalmente essas ferramentas funcionam bem com equipes locais e em pequenos grupos.
No entanto, para equipes maiores e geograficamente distantes, o compartilhamento dessas
informaes pode se tornar um problema maior. Portanto, percebe-se que a ferramenta
tambm atenda a necessidade de centralizar essas informaes para trabalhos que envolvam
equipes remotas.
1.1. Objetivos
O objetivo deste trabalho propor uma ferramenta de estimativas baseada em
Planning Poker para determinar e analisar as estimativas de esforo e custo para um projeto
de desenvolvimento de software utilizando a metodologia Scrum, contribuindo para o
acompanhamento e gerenciamento efetivo.
A proposta visa que seja possvel reduzir os impactos provocados pelo distanciamento
geogrfico entre membros de equipes de trabalho Scrum. Alm disso, a ideia principal criar
uma especificao para a ferramenta a partir do levantamento de funcionalidades. Isso vai
servir como base para que outros projetos, que tenham a inteno de estimar com Planning
Poker, possam desenvolver suas prprias aplicaes. Nesse sentido, vai ser necessrio um
estudo apropriado da tcnica de Planning Poker e da prpria metodologia Scrum, para
compreenso e utilizao de suas as prticas comuns, como por exemplo, a definio de um
Product Backlog ao invs dos tradicionais requisitos funcionais e no funcionais, visto que o
presente trabalho destina-se a equipes Scrum.
13
1.2. Estrutura do Documento

Alm do captulo de introduo, este trabalho conta com a seguinte estrutura:
O Captulo 2 vai apresentar conceitos de metodologias geis para melhor
entendimento de suas prticas.
O Captulo 3 vai apresentar a metodologia Scrum, por possuir as prticas necessrias
para o desenvolvimento da ferramenta em questo. Vo ser abordados conceitos importantes
como o ciclo de vida, os papis, artefatos, reunies e tambm vai ser introduzida uma viso de
como o Scrum trabalha com equipes remotas.
O Captulo 4 vai mostrar conceitos sobre estimativas de software e sua importncia
para o processo de desenvolvimento. Ser feita um estudo de algumas tcnicas j existentes
em metodologias tradicionais e tambm a principal tcnica gil, o Planning Poker, objeto de
estudo deste trabalho.
O Captulo 5 apresentar algumas das ferramentas j existentes que trabalham com
estimativas em Planning Poker e sero apontadas algumas das vantagens e desvantagens.
O Captulo 6 tratar da proposta de ferramenta para estimar com Planning Poker,
destacando a estrutura da mesma e alguns diagramas elaborados. Tambm vai ser explanado
o contexto do desenvolvimento do prottipo.
Por fim, o Captulo 7 ser composto da concluso do trabalho. Nele ser feita a
concluso sobre o presente trabalho e como poder ser aplicado em trabalhos futuros.
14
Captulo 2
Metodologias geis
Na era da informao, visvel a necessidade de sistemas de software como
ferramentas de trabalho para as diversas organizaes. A crescente demanda por sistemas de
qualidade e que atendam a um mercado competitivo muito grande, fez surgir uma variedade
de estratgias para o desenvolvimento de software. Estas tm como objetivo de planejar e
organizar um projeto e uma equipe de trabalho, aumentando a eficcia e diminuindo os prazos
e custos.
Ao longo do tempo, foram apresentadas vrias metodologias de desenvolvimento.
Dentre elas, existem as metodologias tradicionais, cujo foco voltado para a documentao e
surgiram em um contexto muito diferente do atual, baseado apenas em um mainframe e em
terminais burros [Royce 1970]. Devido ao fato de que alterar um sistema era muito custoso,
ele era planejado e documentado antes de seu desenvolvimento, permanecendo inalterados
ao longo do desenvolvimento. Nestes tipos de metodologias, [Clifton & Dunlap 2003] apontam
os maiores problemas encontrados no processo de desenvolvimento de software:
1. Complicaes que surgem pela mudana constante de requisitos: normalmente,
os requisitos de um projeto costumam mudar drasticamente desde sua concepo
at a sua implantao. Em grande parte dos mtodos de produo de software, o
projeto feito no incio, ento no so permitidas alteraes quando os requisitos
mudam (modelo cascata).
2. Estimativas de tempo, custo e qualidade do produto que no condizem com a
realidade: apesar do fato de no ser possvel prever o cronograma e os recursos
despendidos a um projeto, existe uma tendncia da equipe de projeto em
subestimar estes fatores.
3. Os desenvolvedores so forados a no dizer a verdade acerca do andamento do
projeto: quando a gesto subestima o tempo e o custo necessrio para atingir
certo grau de maturidade, os desenvolvedores normalmente mentem sobre
quanto progresso foi feito sobre o projeto. isso ou enfrentar a indignao do
gerente.
Estes pontos aumentam a complexidade e a imprevisibilidade do processo de
desenvolvimento de software. Um sistema nunca construdo da mesma forma, com a mesma
equipe sob as mesmas condies. Uma das mais importantes caractersticas do processo na
construo de software a mudana constante. preciso apresentar uma abordagem
emprica que v a mudana como uma situao que irremediavelmente que vai acontecer e
15
aceit-la ao invs de tentar prever o futuro, e a partir disso isso saber avaliar e responder a
essas mudanas [Soares 2004].
Nesse contexto, as chamadas metodologias geis surgiram como alternativa aos
mtodos de desenvolvimento tradicionais, considerados burocrticos e lentos devido ao foco
excessivo na gerao de documentos e o cumprimento pontual dos processos. Por outro lado,
a proposta gil concentra as atenes no desenvolvimento e na relao entre os envolvidos
[Mundin et al 2002].
2.1. Conceitos
A popularidade das metodologias geis comeou em 2001, quando 17 especialistas em
processo de desenvolvimento de software estabeleceram princpios utilizados por mtodos de
natureza similar. O resultado foi a criao do The Agile Manifesto no qual abordaram o nome
Metodologia gil e estabeleceu uma unio entre diferentes metodologias geis [Agile 2012].
As metodologias geis possuem seus prprios procedimentos e prticas. No entanto,
elas possuem alguns fundamentos em comum. [Soares 2009] cita caractersticas como
desenvolvimento iterativo e incremental, comunicao e a reduo de artefatos, como a
documentao extensa.
A abordagem gil tem como principais conceitos a colaborao e integrao entre os
membros da equipe. As metodologias geis se caracterizam por um gerenciamento de projeto
em que um lder da equipe esteja organizando, apoiando, inspecionando e garantindo o bemestar da equipe de desenvolvimento, ao mesmo tempo em que os resultados do projeto vo
atendendo as solicitaes do cliente. Segundo [Highsmith & Cockburn 2001], no existe
novidade alguma relacionada a aplicao das prticas usadas pelos mtodos geis. O
diferencial est em considerar o fator humano como o principal responsvel pelo sucesso do
projeto, focando na eficcia e na capacidade de gerenciar. Esta ideologia produz uma nova
combinao de valores e princpios que definem uma viso do mundo gil.
A participao do cliente torna-se fundamental nesse contexto para determinar as
tarefas que so realmente importantes para o desenvolvimento do projeto, no
desperdiando os recursos em funcionalidades pouco relevantes. E diferentemente das
metodologias tradicionais, nas quais o cliente tem pouco conhecimento sobre o andamento do
projeto, nos mtodos geis existe uma grande interao com os desenvolvedores durante o
processo de desenvolvimento do sistema [Pereira et al 2007]. Alm de contribuir para
16
aprimor-lo, poder facilitar a compreenso de todos os envolvidos no entendimento do

negcio.
As metodologias geis permitem que a natureza de desenvolvimento seja adaptativa e
flexvel. Elas so indicadas para cenrios onde a mudana de requisitos constante e os
resultados precisam ser entregues ao cliente em curtos espaos de tempo. Por trabalhar com
desenvolvimento iterativo e incremental, metodologias geis realizam pequenas verses de
um produto a cada iterao para valid-lo junto ao cliente. Este, por sua vez, pode exigir
modificaes nos requisitos, seja pelas variaes no mercado ou para atender a necessidade
de modificar o negcio e seus processos. A proposta quebrar o desenvolvimento do projeto
em pequenas interaes, de modo que, ao final de cada etapa, o cliente possua uma verso
que agregue valor ao seu negcio [Dantas 2003]. A integrao e o teste contnuo tambm
possibilitam a melhora na qualidade do software, devido ao fato de serem realizados
continuamente a cada ciclo. Assim, os eventuais problemas so resolvidos constantemente.
Segundo [Ambler 2009] e [Clifton & Dunlap 2003], as bases do Manifesto gil so:
1. Indivduos e interaes ao invs de processos e ferramentas: os sistemas so
desenvolvidos por pessoas que compem uma equipe. A comunicao entre os
mesmos fundamental para que possam trabalhar juntas. E para auxiliar isso,
que processos e ferramentas so importantes.
2. Software executvel ao invs de documentao: a documentao importante
para o entendimento do sistema. Mas mais intuitivo entende-lo atravs do
funcionamento. E para isso ele deve ser construdo.
3. Colaborao do cliente ao invs de negociao de contratos: o objetivo
entender as necessidades que um cliente tem. Deve-se resolver um problema que
ele normalmente nem sabe descrev-lo exatamente e que pode mudar ao longo
do tempo medida que vm o sistema funcional. O contrato deve ser importante
apenas para estabelecer responsabilidades e compromissos, mas no substituir a
comunicao com o cliente.
4. Respostas rpidas a mudanas ao invs de seguir planos: mudanas ocorrem
naturalmente num ambiente de desenvolvimento e o sistema em questo precisa
produzir uma resposta a essas mudanas. Um plano de software deve ser flexvel o
suficiente para receber as mudanas, seno ele dispensvel.
A agilidade pode ser alcanada atravs de 12 princpios apresentados pela Aliana gil,
que so descritos como [Agile 2012]:
17
1. A maior prioridade satisfazer ao cliente desde o incio por meio de entrega

contnua de software o mais cedo possvel.
2. As modificaes de requisitos so bem-vindas. Mesmo que tardias, as
modificaes devem ser aproveitadas como vantagens para a competitividade
do cliente.
3. A entrega de software funcionando deve ser frequente, a cada duas semanas
at dois meses, de preferncia no menor espao de tempo.
4. O pessoal de negcio e os desenvolvedores devem trabalhar juntos
diariamente durante todo o projeto.
5. Os projetos devem ser construdos em torno de pessoas motivadas.
6. Encontros presenciais o modo mais eficiente de levar informao para
dentro da equipe.
7. A entrega de software funcional deve ser considerada a principal medida de
progresso.
8. Os processos geis promovem o desenvolvimento sustentvel, buscando um
ritmo constante, indefinidamente.
9. A ateno a excelncia tcnica e ao bom projeto deve ser contnua.
10. A busca pela simplicidade essencial, maximizando a no realizao de
trabalho que no seja til.
11. Os melhores trabalhos surgem de equipes auto-organizadas.
12. Em intervalos regulares, a equipe deve refletir regularmente sobre como se
tornar mais efetiva, ajustando adequadamente seu comportamento.
Existem algumas abordagens geis de processo utilizadas no mercado, que seguem
estes conceitos. Dentre as mais conhecidas, podem ser citados: XP (Extreme Programming),
Scrum, FDD (Feature Driven Development), DSDM (Dynamic Systems Development Method),
Lean Development e Crystal. A Figura 1 mostra a relao das metodologias geis mais
utilizadas pelas empresas:
18
Figura 1. Metodologias geis nas empresas. Fonte: http://www.versionone.com (2011)
Como visto, a metodologia Scrum a que est sendo mais difundida, assim como a sua
variante a ScrumXP, que se trata de uma verso hbrida. O presente trabalho de graduao
tem como objeto de anlise os conceitos utilizados por esta metodologia.
2.2. Consideraes Finais

Este captulo abordou uma breve introduo sobre as metodologias geis, revelando
suas origens e apontando caractersticas que so comuns a todas as prticas, listando algumas
de suas bases e princpios. Partindo do conhecimento adquirido aqui, torna-se fica mais fcil
compreender os fundamentos da abordagem Scrum, que ser o assunto do prximo captulo.
19
Captulo 3
Scrum
O Scrum, cujo nome se origina de uma formao clssica de uma partida de rgbi,
um modelo gil de processo que foi desenvolvido por Jeff Sutherland, Ken Schwaber e sua
equipe no incio da dcada de 1990 [Schwaber 2004]. Sua criao foi baseada num artigo que
introduz as 10 melhores prticas em empresas, escrito pelos japoneses Hirotaka Takeuchi e
Ikujiro Nonaka, cujo ttulo "O jogo do desenvolvimento de novos produtos" que foi publicado
na Harvard Business Review em janeiro de 1986. Na concepo original, o Scrum foi projetado
para ser utilizado por equipes de produo de consumo. Porm, pode ser aplicada em
qualquer empresa que trabalhe com processos de software [Schwaber 1995].
[Zanatta 2004] considera que o Scrum um mtodo para gerenciar o processo de
desenvolvimento de software definindo como as equipes devem trabalhar em ambientes onde
requisitos mudam constantemente, sofrendo alteraes constantes. Em contrapartida ao que
ocorre normalmente em uma indstria de manufatura qualquer, onde os processos so
repetveis e muitas vezes bem definidos.
Segundo [Schwaber 2004], o Scrum no um processo previsvel. Ele usado em
trabalhos complexos nos quais no possvel prever tudo o que ir ocorrer e oferece um
framework com um conjunto de prticas que torna tudo visvel. Assim, os praticantes do
Scrum acompanham o que acontece e podem fazer os devidos ajustes para dar sequncia ao
projeto. O Scrum adequado para identificar problemas com mais facilidade, mas sua
proposta no vai dizer quais so os problemas ou como resolv-los. Ele servir como um guia
de boas prticas para alcanar o sucesso. Entretanto, as decises de quando e como usar,
quais tticas e estratgias seguir para obter produtividade e realizar as entregas fica por conta
de quem aplicar. O conhecimento das suas prticas permite a aplicao das mesmas de forma
variada, fazendo com que a adaptabilidade seja um dos aspectos positivos do Scrum.
O Scrum possui seis caractersticas bsicas: flexibilidade dos resultados, flexibilidade
dos prazos, times pequenos, revises frequentes, colaborao e orientao a objetos
[Schwaber 1995]. uma metodologia que no requer ou fornece qualquer tcnica especfica
para a fase de desenvolvimento, apenas estabelece conjuntos de regras e prticas gerenciais
que devem ser adotadas para o sucesso de um projeto [Carvalho & Mello 2009].
20
3.1. Ciclo de Desenvolvimento

O Scrum composto basicamente por trs fases durante o desenvolvimento do
software. Nesse processo est includa a criao do Product Backlog, Planejamento da Sprint e
a entrega de uma verso. As fases do ciclo de vida so abordadas a seguir.
Figura 2. Ciclo de Desenvolvimento do Scrum
A primeira fase do Scrum o pr-planejamento (pre-game), na qual um projeto se

inicia com uma viso de alto nvel do produto que ser desenvolvido, normalmente muito
abstrata a princpio e que vai se tornando mais esclarecida a medida que vai sendo
desenvolvido o produto [Clifton & Dunlap 2003], [Schwaber 1995]. O responsvel pelo projeto
(Product Owner) quem vai transformar os elementos dessa viso em uma lista de requisitos
que reflitam as funcionalidades do projeto. Essa lista chamada de Product Backlog,
priorizada pelo Product Owner de forma que os itens que gerem maior valor ao produto
tenham maior prioridade. Inicialmente deve-se dividir o Product Backlog em releases e
esperado que o contedo, a prioridade e o conjunto sofram mudanas, que sero refletidas
nas regras e requisitos de negcios a partir do momento que o projeto comea [Pereira et al
2007].
O planejamento inclui tambm, entre outras atividades, a definio da equipe de
desenvolvimento, identificao de possveis alteraes no Product Backlog, avaliao e
controle dos riscos e uma proposta de arquitetura de desenvolvimento [Schwaber 1995].
A prxima fase a de desenvolvimento (mid-game), na qual ocorre execuo da Sprint
e a equipe determina como as tarefas devem ser executadas. O ciclo do Scrum tem o seu
21
progresso baseado em Sprints, que so iteraes bem definidas, cada uma com duraes de 2
a 4 semanas. Cada uma delas iniciada com uma Reunio de Planejamento (Sprint Planning
Meeting) onde a equipe de desenvolvimento entra em contato com o Product Owner para
priorizar o trabalho que precisa ser feito e estimar o esforo para o desenvolvimento de cada
tarefa [Pereira et al 2007].
Todos os dias so realizadas reunies rpidas (Daily Meeting) e no devem passar mais
do que 15 minutos. Qualquer problema encontrado durante essas reunies deve ser tratado
em outra reunio, apenas com os envolvidos. Durante a execuo da Sprint, a alocao de
recursos para cada tarefa realizada pela prpria equipe. Cada membro seleciona as tarefas
que podem realizar e o grupo estabelece a ordem e dependncia entre elas. Todos os
participantes devem reportar o tempo gasto em tarefas para que o valor de horas restantes
seja calculado corretamente e a equipe possa verificar o seu progresso. Para o
acompanhamento, usado um grfico chamado de Sprint Burndown, que mostra o progresso
dirio em funo do total de horas estabelecido pela soma de horas das tarefas dos itens do
Product Backlog selecionados [Pereira et al 2007].
Ao final da Sprint, deve ser realizada uma Reunio de Reviso (Sprint Review Meeting),
na qual a equipe de desenvolvimento apresenta ao Product Owner o que foi desenvolvido
durante a Sprint e este avalia se o objetivo foi atingido. Logo em seguida, feita a Reunio de
Retrospectiva (Sprint Retrospective) [Pereira et al 2007].
O ciclo do Scrum repetido at que todos os itens do Product Backlog tenham sido
finalizados e/ou o produto final tenha sido validado pelo cliente, sendo esta a fase de psplanejamento (post-game) [Clifton & Dunlap 2003].
3.2. Papis no Scrum

[Schwaber 2004] afirma que a estrutura de um projeto desenvolvido atravs do Scrum
de responsabilidade de trs papis fundamentais: o Scrum Master, o Product Owner e o
Scrum Team.
Scrum Master
O Scrum Master atua como um lder que gerencia os interesses do Product Owner. o
responsvel pelo sucesso do projeto e por garantir que todos os envolvidos estejam aderindo
aos valores e regras do Scrum. Atua como um facilitador, ajudando a equipe e o Product
Owner em todos os processos envolvidos e estimulando a criatividade e o conhecimento da
22
equipe, a fim de maximizar os resultados do projeto [Yoshima 2007]. O Scrum Master tambm
o responsvel por atualizar o Sprint Burndown durante a execuo de uma Sprint.
O papel do Scrum Master fundamental, sendo durante a fase inicial de implantao
uma funo extremamente desafiadora. A funo de evitar impedimentos na equipe e de
proteger o time de interferncias externas ou na prpria empresa faz com que seja revisto at
o processo organizacional da mesma [Varaschim 2009].
No necessrio um conhecimento tcnico por parte do Scrum Master, pois sua
principal funo compreender as dificuldades da equipe e garantir a boa comunicao.
Product Owner
O Product Owner o responsvel pelo gerenciamento do Product Backlog, mantendoo atualizado e visvel a todos os membros da equipe. Responsvel pela definio das
prioridades das estrias dos itens a serem desenvolvidos junto equipe e tambm por garantir
o retorno de investimento do trabalho realizado [Yoshima 2007]. importante salientar que
sugestes de estrias podem ser feitas por qualquer pessoa, mas a incluso destas no Product
Backlog de gerncia do Product Owner [Varaschim 2009].
Para [Reis 2010], o Product Owner quem faz a ligao entre o cliente e a equipe, sob
a perspectiva de negcios. Ele deve avaliar a entrega de seu produto para os clientes e rever
funcionalidades. O Product Owner tem o poder para interromper uma Sprint em caso de
urgncia e at mesmo de suspender um projeto caso detecte que seu retorno no ser o
esperado pela empresa. Portanto, ele deve inteirar-se sobre o impacto tcnico e
organizacional de suas decises [Varaschim 2009].
O perfil de um Product Owner est relacionado rea de produto, sendo necessrio
que o mesmo consiga compartilhar os objetivos do produto que est sendo construdo pela
equipe. Ele deve ser visto como um lder pela equipe deve ser o principal motivador e ter bom
relacionamento com a equipe [Varaschim 2009].
Scrum Team
A equipe (Scrum Team) a responsvel pelo desenvolvimento dos itens que compem
o produto, de acordo com as prioridades definidas pelo Product Owner no Product Backlog. O
conhecimento da equipe deve ser englobado para que possa realizar a implementao do
trabalho [Varaschim 2009].
Alm disso, a equipe tem o dever de verificar se suas prticas de desenvolvimento so
compatveis com as necessidades de qualidade e disponibilidade da aplicao. Se a equipe
23
necessitar de refazer o seu cdigo ou elaborar testes automatizados, ela deve alterar estrias e
demonstrar esta necessidade ao Product Owner para que as mesmas sejam priorizadas e
desenvolvidas pela equipe. Ela deve ser autnoma e ter controle sobre o seu processo de
desenvolvimento, sendo de sua responsabilidade ao final de cada Sprint mostrar os resultados
do trabalho para o cliente [Varaschim 2009].
Para [Libardi & Barbosa 2010], as equipes Scrum so compostas de seis a dez pessoas
autogerenciveis e multifuncionais. Todos trabalham em conjunto para entregar um produto
completo e confivel. Sua composio pode mudar ao final da Sprint, mas h de se levar em
considerao que haver uma perda de rendimento inicial caso ocorra.
3.3. Reunies
Sprint Planning Meeting
De acordo com [Libardi & Barbosa 2010], A Sprint Planning Meeting uma reunio
realizada como primeira atividade de uma Sprint. Nela, esto presentes o Product Owner, o
Scrum Master e o Scrum Team e so realizadas as selees das estrias que sero
implementadas durante aquele ciclo. Durante esta reunio o Product Owner descreve as
funcionalidades de maior prioridade para a equipe. Esta reunio leva cerca de 8 horas.
Nas primeiras 4 horas, o Product Owner apresenta os itens por prioridade do Product
Backlog para a equipe. Esta, por sua vez, faz perguntas para compreender as funcionalidades e
ser capaz de dividir em tarefas tcnicas, que iro dar origem ao Sprint Backlog e ento, o
Product Owner decide o que poder entrar no desenvolvimento do prximo Sprint. Para isso,
ele deve considerar o tamanho e produtividade da equipe e a quantidade de horas disponveis
[Libardi & Barbosa 2010].
Nas prximas 4 horas, a equipe planeja seu trabalho definindo o Sprint Backlog. A
equipe deve realizar um detalhamento de todas as necessidades para desenvolver uma estria
e verificar se a estimativa inicial dada est de acordo com todas as atividades existentes. Para
isto necessrio que eles faam o seguinte [Varaschim 2009]:
1. Para cada item, o time descreve as atividades e estima o tempo necessrio para o
desenvolvimento de cada uma delas. As tarefas devem demandar at um dia de
trabalho para que possam ser acompanhadas no Daily Meeting. Este processo
pode ser definido pela empresa.
24
2. Ao finalizar as estimativas verificado se o tempo do Sprint suficiente para a

realizao das tarefas. Caso contrrio, preciso comunicar ao Product Owner para
rever as histrias que compem o Sprint.
Daily Scrum Meeting

A cada dia do Sprint, o Scrum Master realiza uma reunio de 15 minutos com a equipe.
Essa reunio, chamada Daily Scrum Meeting, tem como objetivo discutir sobre o estado do
projeto, o que pode ser feito at a prxima reunio. [Libardi & Barbosa 2010] afirma que no
caso de identificar dificuldades e obstculos, eles devem ser tratados pelo Scrum Master o
mais rpido possvel.
As Daily Scrum Meetings devem ser realizadas no mesmo lugar e na mesma hora do
dia. Idealmente so feitas pela manh, para ajudar a estabelecer as prioridades do novo dia de
trabalho. Embora qualquer pessoa possa participar da reunio, somente os membros do Scrum
Team esto autorizados a falar [Libardi & Barbosa 2010].
Essas reunies tm o intuito auxiliar o Scrum Master na melhoria a comunicao com
os membros da equipe, remover impedimentos para que as metas sejam alcanadas, alm de
promover e melhorar o nvel do conhecimento acerca do projeto.
Sprint Review Meeting

No final do Sprint, a Sprint Review Meeting realizada. Essa reunio planejada para
ser realizada em no mximo 4 horas [Libardi & Barbosa 2010], [DIVUS 2012]. Nesta reunio o
Scrum Team mostra o que foi desenvolvido durante o Sprint, discute o que no foi concludo e
o que ser feito nas prximas Sprints.
Durante a Sprint Review Meeting, o projeto avaliado em relao aos objetivos do
Sprint. Nesta reunio, a equipe discute como ela foi conduzida, aponta as dificuldades e os
itens realizados. O resultado da Sprint apresentado ao Product Owner, que estabelece a
situao do Product Backlog e faz as projees de datas de entrega dos prximos itens [Libardi
& Barbosa 2010], [DIVUS 2012].
No caso de estrias no finalizadas a equipe deve discutir os motivos com o Product
Owner, para se levantar um balano dos problemas [Libardi & Barbosa 2010].
Sprint Retrospective Meeting

A Sprint Retrospective Meeting uma reunio de 3 horas que ocorre ao final de um
Sprint, logo aps a Sprint Review Meeting e serve para identificar o que funcionou bem, o que
25
pode ser melhorado e que aes podem ser tomadas. Este o momento em que o Scrum
Master tem o trabalho de ajudar o time a encontrar seus verdadeiros problemas [DIVUS 2012].
3.4. Artefatos
Product Backlog
O Product Backlog uma lista contendo todas as funcionalidades desejadas para um
produto. O contedo desta lista definido e priorizado pelo Product Owner. Oficialmente ele
o dono do documento, mas outras pessoas podem abri-lo, como algum componente do Scrum
Team que deseja esclarecer ou atualizar algo [Kniberg 2007]. Normalmente as equipes Scrum
organizam as informaes dos itens de um Product Backlog em um documento do Excel, com
disponibilidade para compartilhamento. Para [Libardi & Barbosa 2010], o Product Backlog
bem dinmico, sempre modificado quando se identifica algo que o produto precisa para ser
mais adequado ao negcio.
Os itens do Product Backlog possuem os atributos de descrio, estimativa e
prioridade. Eles so definidos pelo Product Owner, e apresentados equipe no Sprint Planning
Meeting. Esta, por sua vez, determina quais funcionalidades do sistema so possveis de
realizar em uma Sprint, sendo estas transferidas para o Sprint Backlog. Os itens so divididos
em vrias tarefas para ser distribudo entre as pessoas da equipe [Reis 2010].
[Schwaber 2004] afirma que este documento costuma sofrer alteraes, como
mudanas nos requisitos do negcio, custos, alteraes no mercado externo, tecnologia entre
outros; devendo ser atualizado.
Tabela 1. Exemplo de um Product Backlog
Backlog item
Estimativa
Como um visitante do site eu gostaria de mandar um e-mail de contato
Como um cliente eu gostaria de buscar por um produto
13
Como um cliente eu gostaria de colocar um produto no carrinho de compras
13
Como um cliente eu gostaria de pagar a compra com o carto de crdito
40
Estrias de Usurio
O Product Backlog composto por itens que possuem descries prprias. Eles so
denominados de estrias de usurio (user stories), que comumente contm os seguintes
campos [Kniberg 2007]:
26
ID: uma identificao nica, normalmente um nmero com autoincremento, com

o objetivo de evitar a perda do controle sobre as estrias, caso estas mudem os
nomes.
Nome: um nome curto e descritivo para a estria, como: Ver o histrico de

transaes. Deve ser objetivo para que os desenvolvedores e o Product Owner
compreendam o contexto, alm de distingui-la de outras estrias.
Prioridade: a pontuao de importncia dessa estria para o Product Owner.
Estimativa: a estimativa inicial da equipe sobre o esforo necessrio para

implementar uma estria, se comparada a outras. A unidade pontos por estria
(Story Points) e geralmente corresponde mais ou menos a relao homem/dias
ideal.
Descrio: uma descrio em alto nvel de como a estria ser demonstrada na

apresentao do Sprint. As descries podem seguir um padro, que normalmente
feito da seguinte forma. como um <sujeito> eu gostaria de <ao>.
Notas: quaisquer outras informaes adicionais.

Tabela 2. Exemplos de estrias em um Product Backlog.
ID
Nome
Prior.
Est.
Descrio
Notas
Depsito
30
Como um cliente eu gostaria de
No necessrio se
abrir a pgina de depsito,
preocupar com criptografia
depositar R$ 10,00, ir para a
por enquanto.
pgina do meu saldo e verificar

que este aumentou em R$
10,00.
2
Verificar
10
Como um cliente eu gostaria de
Usar paginao para evitar
histrico de
fazer um depsito e verificar se
consultas muito grandes ao
transaes
o novo depsito listado.
banco de dados. Projetar de

forma similar pgina de
visualizao de usurios.
Estrias podem ser representadas por cartes. Essa uma tcnica de captura de
requisitos de sistemas e surgiu junto com XP (extreme programming), mas ela pode ser
utilizada em qualquer metodologia de desenvolvimento de sistemas geis. Esses cartes se
concentram em informaes do tipo quem, o qu e porqu de um recurso, e no como vai
ser feito [Abu 2010].
27
O carto de histria feito a partir da viso do usurio. Assim, ele no possui detalhes
tcnicos do desenvolvimento, mas apenas informaes das regras de negcio, para que possa
ser compreendido por todos [Abu 2010].
A Figura 3 apresenta um exemplo de carto de estria. Alm de alguns dos campos
descritos anteriormente, o carto pode conter um esboo de como deve funcionar a tela e
anotaes do comportamento esperado.
Figura 3. Exemplo de um carto de estria.
Confirmaes (Testes) so os casos de testes no verso do carto. Os testes facilitam o

entendimento do carto, ajuda na visualizao dos cenrios por parte dos envolvidos [Abu
2010]. A Figura 4 mostra as informaes dos testes, com os possveis cenrios.
Figura 4. Exemplo de testes de um carto de estria.
28
Impediment Backlog
Segundo [Schwaber 2004], o Impediment Backlog contm todos os itens que impedem
o progresso do projeto e que esto associados a riscos. Eles no possuem uma priorizao,
mas esto vinculados a um Product Backlog ou a tarefas dos itens. Dada a importncia desses
itens, o Scrum Master deve ser o responsvel pela eliminao dos impedimentos, para que a
equipe de desenvolvimento possa executar as tarefas sem maiores problemas.
Sprint Backlog
O Sprint Backlog uma lista que contm as tarefas que a equipe vai trabalhar durante
a Sprint. Essas tarefas surgem dos itens do Product Backlog. A equipe escolhe estes itens
analisando o grau de dificuldade, a prioridade e o tempo que ser necessrio. Uma vez
definido, o Sprint Backlog no pode ser alterado.
Para [Reis 2010], a elaborao do Sprint Backlog pode ser feita atravs de uma planilha
Excel, da mesma forma que o Product Backlog, embora existam sistemas apropriados para o
gerenciamento em Scrum que inclusive suportem Sprint Backlog.
O Sprint Backlog costuma ser representado pelo Sprint Burndown Chart, que
determina a quantidade restante do trabalho ao longo do tempo. Ao Scrum Master cabe a
responsabilidade de acompanhar, atualizar e anlisar da situao das tarefas deste artefato.
Figura 5. Exemplo de um Sprint Backlog.
Burndown Chart
O monitoramento do progresso do projeto realizado atravs de dois grficos
principais: Product Burndown Chart e Sprint Burndown Chart. Estes grficos refletem o
progresso da equipe de projeto ao longo do tempo de acordo com a quantidade de trabalho
restante [Cohn 2005] e essa informao pode ser mensurada em quantidade de horas para
concluso do projeto, como mostra a Figura 6, ou por pontos de estimativa. A atualizao do
Burndown deve ser diria, pois facilita a tomada de deciso para melhorar a produtividade da
equipe.
29
Figura 6. Grfico Burndown da Sprint. Fonte: http://epf.eclipse.org/wikis/scrumpt/Scrum/
3.5. Planejamento da Sprint

A primeira atividade para iniciar uma Sprint a Reunio de Planejamento (Sprint
Planning Meetinq). Essa atividade muito importante e por isso necessita de preparao
prvia. No planejamento da Sprint, o Product Backlog deve estar pronto antes de cada reunio.
Isso significa que necessrio estabelecer os seguintes pontos [Pereira et al 2007]:
Existncia do Product Backlog e que cada item esteja estimado.
Deve existir apenas um Product Backlog e um Product Owner.
Todos os itens devem ter uma escala em funo de sua importncia para
organiz-los.
O Product Owner deve entender todos os itens do Product Backlog, mas em

alguns casos outras pessoas podem ter colocado itens nele;
Ele no precisa saber como cada item dever ser feito, mas precisa saber o
motivo de estar l.
Apenas o Product Owner pode atribuir a nota de importncia aos itens do

Product Backlog.
Tendo em vista que os itens acima foram atendidos, pode-se iniciar a reunio de
planejamento. Ela tem a finalidade de priorizar os itens que sero executados na Sprint, alm
de dar informao suficiente equipe para que possa validar e estimar o esforo em horas
para cada item. Esta reunio muito crtica para o sucesso do projeto e que o mal
30
planejamento pode afetar o andamento da Sprint e causar impactos ao cronograma do projeto

[Schwaber 2004].
Com o Product Backlog priorizado, a equipe seleciona os itens podem ser executados
durante a Sprint. As dvidas do time so esclarecidas e ao final temos ento o Sprint Backlog.
Para cada item, a equipe inicia o detalhamento de suas atividades, estimando em horas, a
durao de cada uma delas. Uma vez que todas as tarefas foram estimadas, a equipe verifica
se consegue assumir o compromisso de realizar as tarefas dentro da Sprint [Schwaber 2004].
Esse processo continua at que todos os itens do Sprint Backlog sejam validados. Aps
a estimativa refinada, possvel calcular e obter o total de horas necessrio para realizao
das tarefas [Pereira et al 2009].
O prximo passo iniciar a execuo da Sprint. Ela possui um limite de horas
disponvel, que conhecido por LHS (Limite de Horas da Sprint). O valor deste limite possvel
ser medido utilizando uma frmula simples [Pereira et al 2009]:
LHS = (R x H) x D
Onde, R o total de recursos (membros) da equipe, H o total de horas disponveis
para cada recurso e D o total de dias teis da Sprint.
importante considerar na frmula que o valor de H costuma variar para diferentes
recursos. Alm disso, deve-se avaliar apenas o tempo produtivo para cada Sprint. Por
exemplo: considerar 6 horas efetivas para um recurso que normalmente trabalha 8 horas
dirias. Esta sobra importante para dar uma ideia mais realista da produtividade de cada
recurso e tambm garante uma margem de segurana para imprevistos [Pereira et al 2009].
Esses so clculos bem simples e preciso us-los antes de cada planejamento da
Sprint, pois o LHS o que vai indicar se as horas esto sendo alocadas corretamente para a
equipe [Schwaber 2004].
3.6. Scrum para Equipes Distribudas

O Scrum utiliza um enfoque de trabalho com um conjunto de pessoas compartilhando
o mesmo ambiente, pois facilita a comunicao frequente, alm de aumentara interao da
equipe [Kniberg 2007]. No entanto, a abordagem do Scrum deve sofrer adaptaes quando se
trata de equipes geograficamente distantes, devido a uma maior dificuldade em conseguir
realizar reunies dirias.
31
De acordo com [Sutherland 2007], existem trs tipos de equipes distribudas com
Scrum:
Equipes Isoladas: H uma independncia dentre os membros geograficamente

separados, sendo que, alguns integrantes trabalham de maneira distribuda e cada
equipe possui seu prprio Product Owner.
Scrum Distribudo de Scrums: Cada local possui uma equipe multidisciplinar e as

equipes realizam reunies de Scrum of Scrums (reunio de vrias equipes Scrums)
peridicas. Um Product Owner coordena o trabalho de mltiplas equipes.
Scrums Integrados: Cada equipe possui integrantes em diversos locais. As reunies

ajudam a romper as barreiras culturais e as disparidades de estilos de trabalho.
A estratgia mais comum para diminuir os impactos causados pelo inconveniente da

distncia a utilizao de ferramentas para aumentar a comunicao entre os membros
separados.
Normalmente,
se
utilizam
canais
de
comunicao
para
isso,
como
videoconferncia, audioconferncia, salas de chat ou software de compartilhamento de

desktop.
Muitos so os motivos para que existam equipes distribudas: reduo dos custos,
ganhos de escala, acesso aos recursos especializados, acesso a novos mercados e outros
[Santos 2010]. Sabe-se que equipes distribudas por atuar em diferentes culturas e pontos de
vista, ampliam horizontes e garantem novas experincias, o que contribui para o aprendizado
e a criatividade geral. No entanto, importante ressaltar que esse processo tambm acarreta
em dificuldades, pois preciso tratar com cuidado questes como: barreiras naturais da
lngua, tradies, crenas e princpios diferentes [Lima & Reis 2008].
Outra dificuldade que normalmente acontece se refere ao controle e planejamento de
projetos que envolvem equipes geograficamente separadas. Neste caso, existem algumas
estratgias para solucionar o problema. Alguns trabalhos expem que a alocao de membros
temporariamente pode facilitar a comunicao e a sincronizao das atividades [Huzita et al
2008], [Bavani 2009]. Outra estratgia inclui a atribuio de um local fsico para definir os
processos a serem aplicados no projeto [Bavani 2009]. Por fim, a soluo mais comum a
utilizao de um sistema de gerenciamento de projetos como ferramenta de apoio s boas
prticas de gesto, incluindo um repositrio para os artefatos do projeto e ferramentas que
facilitem a comunicao instantnea [Santos 2010], [Woodward et al 2010].
32

Este captulo abordou os conceitos elementares sobre o Scrum, apontando um breve
histrico, as principais caractersticas e os fundamentos mais importantes como todo o ciclo de
desenvolvimento, os principais papis, artefatos produzidos, reunies realizadas, o
planejamento de uma Sprint.
Tambm foi realizada uma breve anlise de como equipes distribudas podem
trabalhar em projetos Scrum, que como visto, possui srias diferenas com as prticas de um
projeto distribudo, como a falta de comunicao e de controle. necessrio que solues
sejam estabelecidas para reduzir os impactos de se trabalhar com as duas abordagens. Uma
das solues apontadas o desenvolvimento de ferramentas que facilitem o controle e
gerenciamento de projetos, mas de uma maneira que seja estabelecida a comunicao entre
os componentes da equipe.
O conhecimento do Scrum ser til para entender melhor a aplicao da tcnica de
estimativa Planning Poker, que um dos temas deste trabalho de graduao e cujo contedo
ser visto no prximo captulo, que tambm abordar alguns dos principais modelos para
estimativas de projetos de software.
33
Capitulo 4
Estimativa de Software
As empresas de TI tm a produo de projetos de software com qualidade como um
dos maiores entraves a ser enfrentados, a partir de um planejamento determinado. Diversos
trabalhos apontam que a falta de uma estimativa precisa dos processos para o
desenvolvimento de software tem sido uma das maiores causas de problemas enfrentados.
Quanto maior a preciso necessria para estimar, maior ser a complexidade para obt-la.
De acordo com [DeMarco 1991], a necessidade de facilitar o planejamento e o controle
um projeto de software, com o objetivo de torna-lo o mais correto possvel, faz da atividade de
estimar uma das tarefas mais crticas e de fundamental importncia dentro do ciclo de vida de
desenvolvimento do projeto. Para [Florac et al 1997], a medio de produtos e processos, se
feitas da maneira correta, podem fornecer um apoio efetivo para a iniciao e gerncia de
atividades de melhoria de processos.
A estimativa de software uma atividade de processo contnuo que pode ser aplicado
em todas as etapas do ciclo de vida do projeto. Com a estimativa, possvel determinar
mtricas que impactam diretamente na execuo do projeto. [Magela 2006] afirma que a
palavra estimativa utilizada quando se tem a proposta de aplicar um modelo a um problema
que contenha um conjunto mnimo de dados quantitativos e qualitativos, para prever seu
comportamento. A obteno da estimativa consiste em presumir que o modelo no tem
condies de determinar precisamente o resultado desejado ou no possui dados suficientes
para faz-lo.
As principais tcnicas de estimativa de projetos de desenvolvimento de software
trabalham com o princpio de que o tamanho de um software uma mtrica decisiva para a
determinao do esforo para sua construo. Alm disso, essa uma variante importante
para determinar a execuo, o custo e tempo de desenvolvimento do projeto [Hazan 2008].
Com essas informaes bem definidas, possvel garantir um melhor gerenciamento do projeto
pela organizao, obtendo-se assim maior exatido no processo.
Para estimar um projeto, preciso que o responsvel pela atividade seja capaz de
garantir a qualidade do produto atravs da anlise dos requisitos. A estimativa pode ser feita
por um engenheiro de software ou algum especialista capaz de analisar os requisitos. Em caso
de mudanas nos requisitos pode ser necessrio re-estimar [Hazan 2008].
De acordo com [Pressman 2011], as estimativas poder ser confiavelmente
determinadas atravs de vrias maneiras. Uma delas seria obt-las ao final do projeto. No
34
entanto, essa prtica no vlida, pois as estimativas precisam ser obtidas no incio do projeto
para dar sequncia s atividades de planejamento e controle. Outra forma se basear em
estimativas de projetos antigos para estimar o projeto atual. E tambm existe o uso de
tcnicas de decomposio ou modelos empricos para gerar estimativas de custo, esforo e
tempo de projeto.
Existem diversas tcnicas para a obteno de estimativas. [Conte & Shen 1985] afirma
que os mtodos mais conhecidos so: o Modelo de Alocao de Recursos; a Anlise de Pontos
de Funo (APF), que mede o tamanho do software pela quantificao de sua funcionalidade
externa, baseada no projeto lgico ou a partir do modelo de dados; o Modelo RCA PRICE S2; e
o COCOMO (Constructive Cost Model), que um modelo voltado para a produo, e que
atualmente est na est na sua segunda fase de desenvolvimento, conhecida como COCOMO
II. Com o advento da tecnologia de orientao a objeto no desenvolvimento de projetos e que
adotada por boa parte dos sistemas, a estimativa passou a ser realizada tambm atravs de
Anlise de Pontos de Casos de Uso (UCP). Esta abordagem explora conceitos dos casos de uso
e substitui algumas caractersticas do modelo APF.
Em metodologias geis tambm existem modelos para estimativas, com a finalidade
de obter rapidamente estimativas sobre os requisitos (ou estrias) sem perder muito tempo
com mtodos mais burocrticos e permitindo a interao entre os membros da equipe. A mais
conhecida a tcnica de Planning Poker, o modelo de estimativa que ser objeto de estudo
deste trabalho de graduao.
Este captulo foca o estudo a trs dessas tcnicas. Para efeitos de comparao,
inicialmente vo ser abordadas duas das principais estimativas usadas por metodologias
tradicionais: a Anlise de Pontos de Funo e a Anlise de Pontos de Casos de Uso. E por fim,
vai ser realizada uma anlise dos conceitos da principal tcnica de estimativa para
metodologias geis, que o Planning Poker, objeto de estudo deste trabalho de graduao e
vai comparar com os modelos dos mtodos tradicionais.
4.1. Anlise de Pontos de Funo

A Anlise de Ponto de Funo (APF) uma tcnica de medio de estimativa das
funcionalidades de um determinado projeto, sendo estas avaliadas por um ponto de vista de
seu usurio. Surgiu em 1977, quando foi elaborada por Alan Albrecht [Albrecht 1979]. Ponto
de funo a unidade de medida desta tcnica, cujo propsito fazer com que o valor de uma
estimativa obtida no esteja interligado com quaisquer tecnologias utilizado para a construo
35
da aplicao, ou seja, esta unidade deve avaliar o que o produto faz desconsiderando os meios
necessrios para constru-lo [Vazquez et al 2010].
A ideia da APF medir as funcionalidades do sistema, identificar uma forma para
medir a produtividade e qualidade na rea de sistemas e fornecer uma soluo para obter
estimativas para o desenvolvimento de software. Com ela, possvel dimensionar os sistemas
que estejam em produo ou em desenvolvimento, possibilitando assim extrair informaes
mensurveis que sejam teis para estimativa de custos e recursos requeridos para o
desenvolvimento e manuteno de software [CTIS Informtica 2004].
[Albrecht 1979], [CTIS Informtica 2004], [Vazquez et al 2010] apontam que o processo
de contagem dos pontos de funo pode ser dividido em algumas etapas, que sero mostradas
nas subsees a seguir.
Determinar o tipo de contagem

Essa etapa consiste na identificao do objeto a ser medido. Existem trs tipos de
contagem: a de projeto em desenvolvimento, a de projeto de melhoria e a de aplicao. Na
contagem de projeto de desenvolvimento, so medidas todas as funcionalidades fornecidas ao
usurio desde sua primeira instalao. Na contagem de projeto de melhoria, so medidas as
funcionalidades que foram adicionadas, modificadas, ou removidas do sistema. Na contagem
de aplicao, so medidas as funcionalidades informadas pelos usurios existentes na
aplicao atual instalada. Esse ltimo tipo feito ao final da contagem de projeto de
desenvolvimento.
Identificar a fronteira da aplicao

Indica o que faz parte do projeto que est sendo medido, distingue os processos dele
das aplicaes externas ao domnio e tambm o relacionamento entre o projeto. Ela
determina quais funcionalidades sero includas no processo de contagem dos pontos de
funo.
Contar as funes de dados

Aqui as funcionalidades da aplicao so identificadas e contadas. As funes de dados
consistem de:
1. Arquivos Lgicos Internos (ALI), que so grupos relacionados de dados que so
alterados na prpria aplicao. Como por exemplo: tabelas de um banco de dados
mantidas no prprio sistema.
36
2. Arquivos de Interface Externa (AIE), que so grupos logicamente relacionados de

dados que so alterados fora da aplicao. Como por exemplo: tabelas de um
banco de dados mantidas num sistema fora da aplicao.
Cada ALI e AIE possuem dois tipos de elementos que devem ser contados para cada
funo identificada:
1. Itens de Dados: campo nico, que reconhecido pelo usurio e no repetido,
como os campos das tabelas.
2. Registros Internos: subgrupo de dados, reconhecido pelo usurio. Por exemplo:
generalizao/especializao de classes.
Baseado no nmero de itens de dados e registros possvel classificar a complexidade
do ALI e AIE, conforme a Tabela 3. So atribudos os pesos de 7, 10 ou 15 PF para os ALIs e os
pesos de 5, 7 e 10 para os AIE respectivamente complexidade baixa, mdia ou alta [IFPUG
2000].
Tabela 3. Complexidade funcional para os ALI e AIE.
Itens de Dados
Registros Lgicos
1 a 19
20 a 50
51 ou mais
Simples
Simples
Mdia
2a5
Simples
Mdia
Alta
6 ou mais
Mdia
Alta
Alta
Contar as funes transacionais

As funes transacionais representam as funcionalidades de processamento dos dados
fornecidas pelo sistema ao usurio. Podem ser:
1. Entrada Externa (EE): funes da aplicao que processa dados que vm de fora da
aplicao.
2. Sada Externa (SE): funes da aplicao que gera dados que so enviados para
fora da fronteira da aplicao.
3. Consulta Externa (CE): funes da aplicao que representam solicitaes enviadas
para a aplicao, a qual gera uma consulta correspondente e a posterior exibio
de dados.
Cada EE, SE e CE possuem dois tipos de elementos que devem ser contados para cada
funo identificada:
37
1. Itens de Dados: campo nico, que reconhecido pelo usurio e no repetido,

como os campos das tabelas.
2. Arquivos Referenciados: arquivos lgicos utilizados para processar a entrada e/ou
sada. o total de ALI e AIE utilizados pela transao.
Baseado no nmero de itens de dados e arquivos referenciados possvel classificar a
complexidade do EE, conforme a Tabela 4. So atribudos os pesos de 3, 4 ou 6 PF
respectivamente complexidade baixa, mdia ou alta [IFPUG 2000].
Tabela 4. Complexidade funcional para os EE.
Itens de Dados
Arquivos Referenciados
1a4
5 a 15
16 ou mais
0a1
Simples
Simples
Mdia
Simples
Mdia
Alta
3 ou mais
Mdia
Alta
Alta
Baseado no nmero de itens de dados e arquivos referenciados possvel classificar a

complexidade do EE, conforme a Tabela 5. So atribudos os pesos de 3, 4 ou 6 PF para o CE e
os pesos de 4, 5 ou 7 PF para o SE respectivamente complexidade baixa, mdia ou alta
[IFPUG 2000].
Tabela 5. Complexidade funcional para os SE e CE.
Itens de Dados
Arquivos Referenciados
1a5
6 a 19
20 ou mais
0a1
Simples
Simples
Mdia
2a3
Simples
Mdia
Alta
4 ou mais
Mdia
Alta
Alta
Determinar o PF no ajustado
Aps identificar as funes de dados e transacionais, deve-se multiplicar o total de ALI,
AIE, EE, SE e CE pela respectiva complexidade para determinar o valor de PF no ajustado
(PNFA). Aps a determinao dos valores para cada tipo de funo, a equao final para os
pontos de funo no ajustados :
PFNA = (funes de dados) + (funes transacionais)
38
Onde funes de dados a multiplicao da quantidade de ALI e AIE pelas

respectivas complexidades, e funes transacionais a multiplicao da quantidade de EE,
SE e CE pelas respectivas complexidades.
Calcular Valor do Fator de Ajuste

O nmero de pontos de funo no ajustados reflete a funcionalidade que o sistema
fornecer ao usurio, sem considerar que outros fatores, como os requisitos no funcionais,
tambm afetam o tamanho do sistema.
O fator de ajuste tem como finalidade corrigir as distores da etapa anterior em 35%,
baseadas na influncia de 14 caractersticas gerais, que sero analisadas e fornecero o valor
do fator de ajuste. So elas: Comunicao de Dados, Processamento Distribudo, Performance,
Configurao Altamente Utilizada, Taxa de Transaes, Entrada de Dados On-Line, Eficincia
do Usurio Final, Atualizao On-Line, Processamento Complexo, Reutilizao, Facilidade de
Operao, Facilidade de Instalao, Mltiplos Locais e Modificaes Facilitadas.
Para cada caracterstica deve ser atribudo um nvel de influncia numa escala de 0
(nenhuma influncia) a 5 (grande influncia). O valor do fator de ajuste deve-se segue a
seguinte equao:
VFA = (GIT * 0,01) + 0,65
Onde VFA o valor do fator de ajuste e GIT o grau de influncia total (soma de todos
os valores dos nveis de influncia).
Atualmente, a IFPUG considera essa uma etapa opcional do processo de contagem,
para se adequar a norma ISO/IEC 20296:2002 de medio funcional. Isso porque algumas das
caractersticas so consideradas no aderentes pelo padro da ISO. Assim, muitas organizaes
usam apenas a medio dos pontos de funo no ajustados [Vazquez et al 2010].
Calcular os Pontos de Funo Ajustados

Depois de calcular o valor do fator de ajuste, os pontos de funo so ajustados,
multiplicando-se o mesmo pelo valor dos pontos de funo no ajustados (PFNA):
APF = VFA x PFNA
4.2. Anlise de Pontos de Casos de Uso

A tcnica de Pontos de Casos de Uso uma mtrica para o clculo do tamanho de
software orientado a objetos. Tem a sua origem em 1993, quando foram criados numa tese de
39
doutorado de Gustav Karner, da Rational Software [Karner 1993] e sua natureza baseada na
tcnica de Anlise de Pontos por Funo (APF) e em uma metodologia conhecida como Mark II
[Albrecht 1979]. Suas determinaes so realizadas de acordo com um diagrama de Casos de
Uso (UC). Assim, podem ser feitas estimativas com mais antecedncias, apesar da tcnica de
Pontos de Funo (PF) ser mais precisa.
Este mtodo visa estimar o tamanho de um sistema de acordo com a maneira como os
usurios o utilizam, em uma anlise de alto nvel dos passos necessrios para a realizao de
cada tarefa em um nvel mais abstrato. A contagem dos Pontos de Caso de Uso (PCU)
realizada atravs de seis atividades:
Calculando o peso dos Atores do sistema

Essa etapa envolve identificar os atores, quais possuem um nvel de complexidade. Os
atores podem ser classificados em simples, mdio e complexo, com pesos 1, 2 e 3,
respectivamente, conforme demonstrado na Tabela 6.
Tabela 6. Pesos de atores.
Tipo de Ator
Peso
Descrio
Ator Simples
Outro sistema acessado atravs de uma API de programao
Ator Mdio
Outro sistema interagindo atravs de um protocolo de comunicao ou

interao de usurio atravs de linhas de comando.
Ator Complexo
Um usurio interagindo atravs de uma interface grfica.
Calculando o Peso dos Casos de Uso

Essa etapa objetiva o clculo do peso bruto dos casos de uso. Para obteno de
valores, os casos de uso so divididos em trs nveis de complexidade, baseadas no nmero de
transaes envolvidas em seu processamento. A transao uma srie de atividades que
podem ser realizados em conjunto. Tambm se deve considerar a complexidade atravs da
quantidade de classes de anlise por caso de uso. A Tabela 7 mostra o peso para cada um dos
tipos de caso de uso classificados.
Tabela 7. Pesos de Casos de Uso por nmero de transaes e classes.
Tipo de Caso de Uso
Descrio
Peso
Simples
At 3 transaes e at de 4 classes de anlise
Mdio
De 4 a 7 transaes e de 5 a 10 classes de anlise
10
Complexo
Mais de 7 transaes e mais de 10 classes de anlise
15
40
Clculo dos Pontos de Casos de Uso no Ajustados

Este clculo considera a soma do peso total dos atores com o peso total dos casos de
uso para obteno dos pontos de casos de uso no ajustados (PCUNA). Logo,
PCUNA = (pesos dos atores) + (pesos dos casos de uso)
Clculo dos Fatores Tcnicos

Assim como na tcnica de Pontos de Funo, este mtodo tem um ajuste bastante
similar e composta por duas partes. A primeira delas considera um clculo de fatores
tcnicos, que abrange uma srie de requisitos funcionais do sistema. Ela basicamente prev o
nvel tcnico do sistema e dificuldade para desenvolv-lo.
O objetivo determinar o Fator de Complexidade Tcnica (FCT), a partir do
conhecimento tcnico do sistema em relao a algumas caractersticas, conforme a Tabela 8.
Cada uma delas classificada por uma escala de 0 a 5, que varia de acordo com o grau a
influncia na complexidade da aplicao a ser construda.
Tabela 8. Fatores e pesos de complexidade tcnica na PCU.
Descrio
Peso
Sistemas Distribudos
2,0
Desempenho da Aplicao
1,0
Eficincia do Usurio Final
1,0
Processamento Interno Complexo
1,0
Reusabilidade de Cdigo em outras aplicaes
1,0
Facilidade de Instalao
0,5
Usabilidade
0,5
Portabilidade
2,0
Facilidade de Manuteno
1,0
Concorrncia
1,0
Caractersticas Especiais de Segurana
1,0
Acesso Direto para Terceiros
1,0
Facilidades Especiais de Treinamento
1,0
Aps a determinar os valores para cada fator, o resultado dos Fatores Tcnicos (FT)
calculado pela soma dos produtos de cada peso multiplicado por seu respectivo valor na escala
41
de 0 a 5. A partir do valor dos Fatores Tcnicos obtido o Fator de Complexidade Tcnica

(FCT), conforme frmula abaixo:
FCT = 0.6 + (0.01*FT)
Clculo dos Fatores Ambientais

A segunda parte da tcnica do ajuste dos Pontos de Casos de Uso consiste em
determinar o clculo de fatores de ambiente, considerando aspectos no funcionais
relacionados ao processo de desenvolvimento, tais como experincia da equipe e estabilidade
do projeto.
O objetivo determinar o Fator de Complexidade Ambiental (FCA), a partir do
conhecimento do ambiente do sistema em relao a algumas caractersticas, conforme a
Tabela 9. Elas so obtidas seguindo a mesma lgica dos fatores tcnicos, com pesos prdeterminados.
Tabela 9. Fatores e pesos de complexidade ambiental na PCU.
Fator
Regra de Definio
Peso
F1
Familiaridade com o processo de desenvolvimento de software
1,5
F2
Experincia na aplicao
-1
F3
Experincia em OO, na linguagem e na tcnica de desenvolvimento
0,5
F4
Capacidade do lder de anlise
0,5
F5
Motivao
F6
Requisitos estveis
F7
Trabalhadores com dedicao parcial
-1
F8
Dificuldade da linguagem de programao
Aps a determinar os valores para cada fator, o resultado dos Fatores Ambientais (FA)
calculado pela soma dos produtos de cada peso multiplicado por seu respectivo valor na
escala de 0 a 5. A partir do valor dos Fatores Ambientais obtido o Fator de Complexidade
Ambiental (FCA), conforme a frmula a seguir:
FCA = 1.4 - (0.03*FA)
42
Clculo dos Pontos de Caso de Uso ajustados

Finalmente, o clculo do valor total do sistema em Pontos de Caso de Uso Ajustados
(PCUA) representa a estimativa de tamanho do projeto em Pontos de Casos de Uso. Ele
determinado assim:
PCUA = PCUNA x FCT x FCA
4.3. Planning Poker

O Planning Poker uma tcnica de estimativa voltada para as metodologias geis,
inclusive o Scrum, diferentemente dos mtodos de estimativas anteriores, cujo foco para
abordagens mais tradicionais. Algumas denominaes apresentadas aqui faro parte do
contexto do Scrum, portanto exigir um conhecimento bsico do mesmo, que foi abordado no
Captulo 3.
[Grenning 2002] afirma que esta a melhor ferramenta encontrada para estimar
tamanho de projetos em metodologias geis. O Planning Poker pode ser considerado a
combinao de trs tcnicas menos comuns de mtodos de estimativas geis: opinio de
especialista, analogia e desagregao [Cohn 2005], o que a torna uma prtica bastante
interativa e prtica.
O Planning Poker consiste na obteno de estimativa atravs de um jogo de cartas. A
ideia principal por trs dele permitir que todos os membros da equipe de desenvolvimento
(programadores, testadores, design, analistas, etc.) participem colocando a sua viso de
complexidade para que juntos possam chegar a um denominador comum para a equipe. Nas
metodologias geis, as estimativas de esforo e tempo so aplicadas a estrias e essa
atividade de responsabilidade da equipe tcnica por alguns motivos [CTIC-UFPA 2011]:
1. Quando se planeja, normalmente no se sabe exatamente quem vai implementar
quais partes de quais estrias;
2. Estrias normalmente envolvem diversas pessoas com diferentes conhecimentos
(design de interface de usurio, codificao, teste, etc.);
3. Para prover uma estimativa, os membros da equipe precisa de algum tipo de
compreenso da natureza de cada estria. Um maior entendimento do contexto
aumenta a probabilidade de que os membros se ajudaro durante a iterao. Isso
tambm aumenta a probabilidade de que questes importantes sobre a estria
surjam cedo;
43
4. Quando todos estimam uma estria, frequentemente descobrem-se desconexes

onde duas pessoas da equipe tm estimativas bastante diferentes para a mesma
estria. preciso descobrir e discutir essas questes antes de se iniciar a iterao.
No Scrum, o Planning Poker realizado durante o Sprint Planning Metting [Pereira et
al 2007]. O objetivo atribuir uma complexidade em comum a todos os membros da equipe
para as estrias de cada item do Product Backlog de uma forma mais dinmica. Estes,
portanto, so os principais responsveis pelas estimativas das estrias.
No Planning Poker, cada integrante tem a sua disposio um baralho de 13 cartas,
numeradas numa sequncia similar a encontrada nos nmeros de Fibonacci, conforme mostra
a Figura 7. De acordo com [CTIC-UFPA 2011], existe um propsito ao utilizar uma sequncia
no linear determinao de estimativas. O objetivo de utilizar estes nmeros que o intervalo
entre os valores permite visualizar melhor as diferenas de complexidade entre as
funcionalidades. Essa ideia diminui a granularidade das estrias, o que evita uma falsa ideia de
preciso de estimativas. Ento se para um item foi dada uma estimativa de 20 pontos, no faz
muita diferena se pudesse ser dado um valor prximo. Portanto, este valor trata-se de um
palpite aproximado.
Figura 7. Baralho de Planning Poker (Fonte: CRISP Konsulter)
Valores acima de 20 so considerados altos e, portanto trata-se de uma estria grande,

que podem no ser completamente finalizadas numa nica iterao. Uma ideia seria tentar
entrar em maiores detalhes, quebrando a estria maior em menores, com reduo em suas
complexidades. O recomendvel que ao final do Planning Poker, se consiga fazer com que as
estrias da iterao possuam algum valor do intervalo de 12 a 13. No entanto, necessrio
evitar outro problema que deixar que as estrias tornarem-se muito pequenas, pois isso
provavelmente tornar a equipe vtima do microgerenciamento [Kniberg 2007].
O baralho do Planning Poker ainda pode conter algumas cartas com propsitos
especiais. A carta com valor 0 (zero) indica que uma estria est finalizada ou to pequena
que pode ser resolvida em questo de minutos [Kniberg 2007]. A carta com ? (interrogao)
44
indica que o participante no tem o conhecimento apropriado para estimar o esforo

necessrio para a estria. No frequentemente utilizada, mas se for, a equipe precisa
trabalhar a respeito da estria para tentar chegar a um melhor consenso entre os membros da
equipe. Por ltimo, a carta com xcara de caf indica que o participante no est em condies
de pensar sobre a estria e necessita de uma pausa para refletir sobre a mesma [CTIC-UFPA
2011].
Durante o Planning Poker, devem ser realizadas rodadas para obter a estimativa da
estria, com base nestes valores. As diferenas que surgirem durante estas rodadas devero
ser mediadas por um coordenador. No Scrum, este papel de responsabilidade do Scrum
Master. O Product Owner, por sua vez, ser responsvel por explicar as estrias, sendo
importante para retirar as possveis dvidas que surgirem a respeito destas estrias. No
intervm na estimativa [CTIC-UFPA 2011].
Os seguintes procedimentos que devem ser tomados ao se estimar uma estria,
quando realizado por uma equipe Scrum [CTIC-UFPA 2011], [Haugen 2006], [Cohn 2005]:
1. Inicialmente pontua-se a estria que mais se aproxima do valor 3 (trs), pois
servir como referncia para as demais.
2. As estrias so apresentadas por vez. O Product Owner descreve para a equipe
Scrum a estria e fornece informaes a respeito do seu valor de negcio. A
seguir, o coordenador vai perguntar o esforo necessrio para concluir a histria
aos membros da equipe, conforme a Figura 8.
Figura 8. Coordenador solicita aos participantes a estimativa de uma determinada estria.
3. Cada membro da equipe deve pensar a respeito do tempo e esforo necessrio

para se implementar a estria lida, conforme a Figura 9. Os membros da equipe
devem estimar considerando todas as tarefas envolvidas pelos responsveis em
desenvolver, testar, criar design, etc. Ento, deve escolher uma carta no baralho
correspondente ao valor desta estimativa e coloca-a virada para baixo.
45
Figura 9. Integrantes da equipe tcnica escolhendo suas estimativas da estria.
4. Quando todos os membros fizerem o procedimento acima, ento devem revelar as

cartas escolhidas simultaneamente, conforme a Figura 10. Isso faz com que cada
membro da equipe pense por si prprio na hora de uma deciso de estimativa.
Figura 10. Integrantes da equipe tcnica mostrando suas cartas.
5. Todos avaliam os resultados e verificam se houve convergncia entre as cartas

mostradas, ou seja, todas as estimativas possuam valores aproximados para a
mesma estria.
6. Caso contrrio, o Scrum Master solicita aos membros, que mostraram o menor e o
maior valor estimado, que expliquem o motivo que os levaram a tal estimativa.
Isto faz com que os integrantes reflitam sobre alguns pontos da estria, o que
pode fazer com que mudem os valores propostos para as estimativas. Ento, uma
nova rodada realizada at que as estimativas de esforo cheguem a uma
convergncia, conforme a Figura 11.
46
Figura 11. Integrantes da equipe tcnica refazendo suas escolhas para a estimativa.
7. A estimativa final da estria ser o valor que tiver maior ocorrncia ou a mdia
entre as estimativas informadas. Ento comea uma nova rodada com a leitura da
prxima estria pelo Product Owner. O processo se repete at que tenha sido
concluda a estimativa das estrias dos itens do Product Backlog.
Alguns trabalhos [Haugen 2006] afirmam haver uma melhora na eficincia das
estimativas com pontos por estrias quando utilizada esta tcnica para atribuio dos pontos.
No entanto, um ponto a se levantar que na utilizao dessas tcnicas no estruturadas,
algumas pessoas com melhor entendimento do contexto da estria podem influenciar no
resultado proposto pelo restante da equipe. Ou seja, vai provavelmente fazer com que os
outros membros sigam o raciocnio apresentado.
Conforme visto, o Planning Poker uma alternativa muito satisfatria para realizao
de estimativas na metodologia Scrum. No entanto, este jogo torna-se invivel de ser realizado
em equipes geograficamente distantes, pois estas no compartilham um mesmo espao fsico
e um mesmo baralho de cartas [Kniberg 2007].

Este captulo abordou os conceitos de estimativas de software, realizou um estudo das
principais tcnicas usadas por metodologias tradicionais e por fim foi visto uma tcnica de
estimativa gil, que o Planning Poker.
O estudo desses modelos foi importante para avaliar as vantagens de se aplicar uma
modelo de estimativas dentro de prticas geis. A natureza interativa do Planning Poker
possibilita que as equipes tenham melhor acompanhamento do esforo necessrio para se
desenvolver um requisito. Isso feito dentro de um prazo muito curto, diferente dos modelos
47
utilizados nas metodologias tradicionais, que costumam aplicar frmulas matemticas para
extrair uma estimativa de uma funcionalidade. Normalmente estes so modelos mais precisos,
mas tambm so mais burocrticos e metdicos.
O Planning Poker, apesar de ser uma excelente tcnica para estimativa, no boa o
suficiente quando se considera equipes Scrum distribudas geograficamente, devido falta de
comunicao entre os membros. Sem o auxlio de uma ferramenta que possa proporcionar a
prtica desse jogo, dificilmente essa tcnica seria realizada por essas equipes. O prximo
captulo vai apontar algumas das ferramentas j existentes e que tratam desse inconveniente
do Planning Poker.
48
Captulo 5
Ferramentas para Estimativas Usando o Planning
Poker
Este captulo aborda algumas das principais ferramentas j disponveis que trabalham
com estimativas usando Planning Poker, ou seja, possuem uma finalidade semelhante ao da
ferramenta proposta neste trabalho. Foram identificadas duas ferramentas de relevante
importncia: o Planning Poker e o FireScrum. A seguir, ser realizada uma anlise mais
aprofundada delas.
5.1. Planning Poker

O Planning Poker uma ferramenta web gratuita e desenvolvida pela Mountain Goat
Software, cuja finalidade permitir que equipes geis utilizem-na sem necessitar de um
software especfico.
Para utilizar a ferramenta, basta que o usurio realize um cadastro no site e fornea o
link para acesso a sesso da(s) partida(s), aos demais componentes da equipe atravs do email. As partidas funcionam avaliando-se cada item de um Product Backlog (no h este termo
na ferramenta), cada um com sua estria e o usurio deve descrev-las. Dentro da ferramenta,
o usurio que inicia a sesso o moderador das partidas, possivelmente o Scrum Master.
Figura 12. Tela de descrio de uma estria no Planning Poker.
49
Nesta ferramenta, o usurio possui a sua disposio um baralho e pode selecionar uma
das cartas dela. Cada uma corresponde a um valor diferente de estimativa para a estria. A
seleo feita atravs do mouse de maneira bastante intuitiva.
O usurio pode iniciar uma nova rodada, caso exista uma grande divergncia de
valores. possvel visualizar as rodadas que foram realizadas e quais as cartas definidas por
cada usurio. Enquanto ela segue, possvel visualizar quais os participantes at o momento j
escolheram suas cartas, conforme a Figura 13. Se algum ainda no escolheu, todas as cartas
so dispostas de modo que ningum veja qual o seu valor. Ao final quando todos escolherem
suas cartas da rodada, s ento todas as cartas so mostradas a todos.
Figura 13. Tela para escolha de uma estimativa no Planning Poker.
O usurio que inicia a sesso tem a opo de definir um valor para o esforo estimado
para a estria, para isso basta inserir um valor que ele acha coerente, e se necessrio, os
membros podem discutir ela. Ao final, o usurio pode estimar uma nova estria ou ento
encerrar a partida, caso todas as estrias do Product Backlog j tenham sido estimadas.
Figura 14. Tela para o moderador definir uma estimativa no Planning Poker.
50
De modo geral, a ferramenta Planning Poker se mostrou bastante prtica e intuitiva,

mas carece de vrios aspectos que seriam importantes para uma ferramenta que estima com a
tcnica que leva o nome na ferramenta. Por exemplo, a ferramenta no disponibiliza uma
visualizao adequada para listar os componentes do Product Backlog. Dentro dessa lista, as
informaes das estrias so exibidas nessa lista, de modo que se uma estria descrita for
muito grande, a tendncia que ocupe a tela com informao desnecessria, podendo
simplesmente exibir o contedo da estria em outro lugar na sua totalidade.
Outro ponto que no existem maiores detalhes de um item avaliado que v alm das
estrias. Elas no podem ser alteradas por nenhum membro, nem mesmo o prprio
moderador. Alm disso, no existe um meio de comunicao entre os membros da equipe
dentro da ferramenta. Provavelmente, a comunicao realizada atravs de uma ferramenta a
parte. Para finalizar, a ferramenta limita-se a disponibilizar apenas o resultado da estimativa,
mas no trabalha com esta informao de modo que possa ser aproveitada para anlise pela
equipe de trabalho, como por exemplo, a gerao de grficos para acompanhar o
desenvolvimento do projeto.
Apesar de grandes limitaes, uma ferramenta que dentro da finalidade intrnseca
de estimar, atende bem ao seu papel na tentativa de objetivar informaes mensurveis a
partir da avaliao das funcionalidades de um sistema.
5.2. FireScrum
O FireScrum uma ferramenta open source de gerenciamento de equipes de projeto
Scrum. Ela contm aplicaes integradas para suportar essas equipes no desenvolvimento de
seus projetos, contribuindo para equipes que trabalham remotamente. Ele teve incio a partir
de um trabalho de concluso de curso e sua ideia foi evoluda em um mestrado. O sistema foi
desenvolvido por um grupo de cerca de 60 estudantes de ps-graduao da Universidade
Federal de Pernambuco [Cavalcanti 2009].
O FireScrum utiliza abordagens da Web 2.0 e de RIA (Rich Internet Applications)
[Cavalcanti 2009]. uma aplicao web que pode ser acessvel atravs de um ambiente de
Internet ou Intranet. Apesar disso, sua configurao exige aplicativos de terceiros para que
seja possvel instalar o aplicativo. A estrutura do FireScrum foi desenvolvida para possuir
funcionalidades modularizadas e integradas, porm independentes entre si.
Dentre os principais mdulos da ferramenta, o Core mais elementar deles, sendo
capaz de abranger todo o ciclo de um projeto Scrum. As principais funcionalidades incluem:
51
controle de acesso; cadastro de usurios, projetos, itens de Backlog, estrias, Sprints, tarefas;
priorizao de itens de Backlog; gerao do Burndown Chart.
Existem outros mdulos do FireScrum, que so considerados de apoio. So eles:
TaskBoard, Test Management, Bug Tracking, Desktop Agent e Planning Poker. Esta seo vai
focar apenas neste ltimo mdulo.
Figura 15. Tela do mdulo de Planning Poker do FireScrum.
O Planning Poker do FireScrum possui muitos recursos de apoio s equipes de projetos

Scrum. Ele contm dispositivos de multimdia para realizao de reunies de estimativas
utilizando comunicao atravs de troca de mensagens ou por videoconferncia.
A ferramenta permite a visualizao dos itens do Product Backlog a serem estimados, e
tambm permite definio dos valores das estimativas. Os itens possuem informaes
adicionais como o valor de negcio e um valor para expressar o esforo em desenvolv-lo.
Cada participante deve entrar numa sesso definida por um usurio, e atravs dela, os
mesmos iro realizar uma partida de Planning Poker no intuito de obter uma estimativa
desejada para a estria do item avaliado.
Cada participante tem um baralho a sua disposio, do qual possvel escolher uma
carta para afirmar a estimativa desejada para a estria e aguardam at que todos faam o
mesmo. Os participantes podem discutir sobre ela, e uma nova rodada pode ser realizada. No
final, o lder registra o valor da estimativa para a estria.
O FireScrum parece atender a vrios dos requisitos para estimar utilizando o Planning
Poker, mas existem algumas dificuldades. Uma delas a necessidade de vrias aplicaes
externas para o funcionamento do sistema. Some-se isso ao fato de que a configurao e
instalao destes componentes so um tanto difceis, exigindo alguns passos trabalhosos para
ver o FireScrum rodar. Outro ponto que apesar do fato de ser open source, a falta de uma
52
documentao ou manual apropriado para uso e instalao da ferramenta pode se tornar um

problema ao usurio, visto que pode exigir do mesmo um desperdcio de tempo no
entendimento de funcionalidades que no so to intuitivas ou que aparentemente so mais
complexas do que realmente .
Como abordado, as equipes de projeto podem requerer o desenvolvimento de
ferramentas prprias para estimar em Planning Poker. Por ser open source, o FireScrum uma
ferramenta em potencial para servir como referncia para o desenvolvimento de aplicaes
prprias por essas equipes. No entanto, alguns pontos podem dificultar e inviabilizar a
compreenso da estrutura da ferramenta por parte um analista de sistema. Um deles a
complexidade do cdigo, pois se trata de uma ferramenta de grande porte e com integrao a
ferramentas de terceiros; e tambm a indisponibilidade de uma documentao dos requisitos
e da arquitetura do sistema pode ser considerada um contraponto.
5.3. Comparao das Ferramentas

A seguir, ser realizado um comparativo entre as ferramentas encontradas e a
ferramenta proposta. A ideia facilitar visualizao das caractersticas de ambas; verificar os
pontos fortes e fracos; e comparar estes elementos com o que vai existir na ferramenta
proposta.
Tabela 10. Comparativo entre as ferramentas abordadas.
Planning Poker
FireScrum
A Ferramenta Proposta
Sim
No
Sim
Razovel
Razovel
Boa
Edita Product Backlog
No
Sim
Sim
Promove comunicao entre os usurios
No
Sim
Sim
Grfico de acompanhamento com base nas
No
Sim
Sim
No
No
Sim
No
No
Sim
No disponvel
Alta
Mdia ou Baixa
Facilidade de instalao e configurao

Visualizao das informaes na tela
estimativas obtidas
Disponibilidade da documentao da
ferramenta
Manual do usurio e de instalao
Complexidade do cdigo-fonte
53

As ferramentas explicadas aqui trabalham bem quando o objetivo estimar em
Planning Poker, apesar de possurem algumas limitaes prprias. A ferramenta proposta
deste trabalho de graduao visa trabalhar em cima de alguns dos problemas encontrados,
para que novos projetos possam ser desenvolvidos utilizando como base o trabalho da
documentao a ser realizada. O captulo a seguir vai tratar da estrutura dessa nova proposta
de ferramenta, que tem como base todo o conhecimento adquirido at aqui.
54
Captulo 6
A Ferramenta Proposta
Este captulo apresenta a proposta de ferramenta deste trabalho. Aps identificar as
caractersticas positivas e limitaes das ferramentas similares apresentadas no Captulo 5, o
objetivo ser combinar esses elementos, simplific-los da melhor forma possvel e determinar
uma lista de funcionalidades que possam ser utilizadas em trabalhos futuros de
desenvolvimento.
Aps entender o funcionamento destas ferramentas e combinando os conceitos de
Planning Poker e da metodologia Scrum, o primeiro passo foi elicitar os requisitos funcionais e
as principais regras de negcio que vo ser aplicadas na ferramenta.
Os requisitos funcionais aqui apresentados seguem o padro da metodologia Scrum.
Ou seja, eles foram definidos atravs de estrias de usurio, que servem para descrever as
funcionalidades. Portanto, este trabalho realizou um levantamento de um Product Backlog,
conforme visto nos conceitos de Scrum. De acordo com [Mike 2008], os requisitos no
funcionais podem ser expressos atravs de estrias dos usurios, que seguem o padro
descrito no Captulo 3. O resultado deste esforo encontra-se no Apndice A para os requisitos
funcionais e no Apndice B para os requisitos no funcionais.
Para cada estria do Product Backlog referente aos requisitos funcionais, foi
apresentado um prottipo de tela que representa a navegao visual do usurio quando
utilizar tal funcionalidade. Alm disso, foram apresentados comportamentos de sucesso e erro
para cada uma delas, indicando um fluxo de eventos at a ocorrncia do fato. Tambm foi
destinado um espao para notas, que so informaes adicionais acerca das estrias.
Por hora, no vo ser definidas prioridades ou estimativas aqui. Essa atividade de
responsabilidade da equipe de desenvolvimento que utilizar as informaes levantadas neste
trabalho e ento vo definir essas informaes para cada estria, de acordo com as Sprints,
prazos, custos, riscos e outros fatores relevantes ao projeto de desenvolvimento. A finalidade
deste trabalho definir uma estrutura de anlise e projeto da ferramenta proposta.
Foram utilizados neste trabalho alguns dos diagramas UML, que so comuns em
metodologias tradicionais, tais como o diagrama de classes e o diagrama de casos de uso.
Apesar de ambas no serem comumente utilizadas em metodologias geis, o presente
trabalho abordou recursos visuais, para uma maior compreenso do sistema. Ou seja, a ideia
utilizar as vantagens de cada metodologia para o maior entendimento do domnio por parte de
todos os envolvidos. Isso vai exigir um conhecimento mnimo sobre UML por parte das equipes
55
de projetos, o suficiente para compreender os diagramas e o que se passa dentro da

ferramenta proposta. Tambm foi utilizado um diagrama entidade-relacionamento das tabelas
do banco de dados usado e uma representao da arquitetura do sistema.
Por fim, foi desenvolvido um prottipo visual do sistema, com alguns aspectos
funcionais, que vai servir como referncia para implementaes em projetos futuros.
6.1. Diagrama de Casos de Uso

O diagrama de casos de uso uma representao do que cada usurio (ator) do
sistema pode fazer dentro dele. Embora a representao de diagramas de casos de uso no
seja comum no Scrum, possvel realizar um mapeamento com os itens do Product Backlog da
ferramenta, que representam as funcionalidades da mesma. Este mapeamento feito
intuitivamente, visto que o nome descrito em cada caso de uso o mesmo dado ao item do
Product Backlog (ver Apndice A).
A Figura 16 representa o diagrama de casos de uso completo da ferramenta. Devido
resoluo muito pequena da figura, ser realizada a seguir a diviso do diagrama em outros
diagramas menores para anlise.
Figura 16. Diagrama de Casos de Uso da ferramenta.
O diagrama da Figura 17 representa os atores envolvidos na ferramenta. O usurio o

ator principal e possui duas especializaes. Ele pode ser um coordenador de projetos (Scrum
Master) ou ento um participante (membro do Scrum Team). Vale lembrar que para cada
56
projeto, o usurio no pode ser atribudo aos dois papis, ele s pode ter uma
responsabilidade ou outra. No entanto, ele pode assumir os dois papis em projetos
diferentes.
Figura 17. Diagrama de Casos de Uso de relacionamento dos atores da ferramenta.
O diagrama da Figura 18 representa os itens do Product Backlog que esto

relacionados ao ator Usurio. Como descrito anteriormente, este ator uma generalizao dos
demais papis. Isso implica que os outros atores utilizaro as funcionalidades do usurio.
Figura 18. Diagrama de Casos de Uso do ator Usurio.
Algumas atividades so importantes destacar. Uma delas o Cadastrar Projeto, que

pode ser realizada por qualquer usurio, e uma vez executada, automaticamente o sistema vai
57
considerar que ele ser um Coordenador (Scrum Master) daquele projeto, e assim executar as
funcionalidades especficas, conforme mostra a Figura 19.
J a atividade de Aceitar Convites, a aceitao por parte de um usurio para
participar de um projeto. Uma vez realizada, deve considerar que o usurio se torne um
participante daquele projeto, e assim, ele ser capaz de executar as tambm funcionalidades
especficas (ver Figura 20). J a atividade de Chat da Sesso, possui uma dependncia da
funcionalidade Iniciar Sesso Planning Poker, realizada pelo coordenador (ver Figura 19).
Outra atividade importante a de Alterar Item. Ela pode ser feita por qualquer
usurio, visto que as prticas do Scrum estabelecem que no s o coordenador possa editar
informaes de um item, mas o participante tambm possa faz-lo. Na realidade, essa funo
no do Scrum Master, mas sim do Product Owner, no entanto este trabalho assume que as
atividades deste ltimo sejam de responsabilidade do coordenador do projeto na ferramenta.
Ou seja, ambos os papis sero considerados coordenadores.
A seguir, o diagrama da Figura 19 representa os itens do Product Backlog que esto
relacionados ao ator Coordenador. Essas funcionalidades so especficas dele. Assim sendo,
outros atores no possuem autorizao suficiente no sistema para execut-las.
Figura 19. Diagrama de Casos de Uso do ator Coordenador.
58
As seguintes atividades so exclusivas de um Scrum Master: Remover Projeto;

Alterar Projeto; Criar Sprints, para estabelecer o intervalo das iteraes do projeto; Enviar
Convites para convidar participantes para estimar em um projeto; Iniciar Sesso Planning
Poker; Realizar Nova Rodada; Finalizar Sesso; Mostrar Cartas; e Definir Estimativa
para um Item. Dentre as atividades do Product Owner, que so includas como sendo as de
um coordenador, tem: Cadastrar Item, para ser adicionado ao Product Backlog do projeto; e
Remover Item, para retir-lo do Product Backlog.
Observe que todas as atividades exigem que o coordenador deva ter efetuado o login
antes. Esta uma atividade do ator Usurio, portanto tambm deve ser executada pelo
coordenador. As atividades envolvendo a obteno de estimativas no Planning Poker tambm
precisam da atividade de iniciar a sesso. Essas funcionalidades
A seguir, o diagrama da Figura 20 representa os itens do Product Backlog que esto
relacionados ao ator Participante.
Figura 20. Diagrama de Casos de Uso do ator Participante.
As atividades especficas do ator Participante so: Entrar numa Sesso Planning

Poker, que s pode ser feita aps o participante efetuar login, haver aceitado um convite (que
fora enviado por um coordenador) e a sesso do jogo ser iniciado pelo ator Coordenador;
Escolher Carta, que s pode ser realizada aps efetuar o login e ter realizado a atividade
anterior; e Sair da Sesso, que s pode ser realizada aps o participante entrar nela.
59
6.2. Diagrama de Classes

O diagrama de classes uma representao da estrutura e das relaes entre as
classes que modelam um objeto. A figura 21 representa o diagrama de classes da ferramenta.
Figura 21. Diagrama de Classes da ferramenta.
A seguir, uma descrio de cada uma das classes do diagrama:
60
1. Usurio: contm informaes referentes aos usurios do sistema. Isso inclui os

coordenadores e participantes. Pode estar vinculado a vrios projetos.
2. Projeto: possui informaes referentes aos projetos do sistema. Possui um
responsvel, que o coordenador (Scrum Master), do tipo Usurio e vrios
membros. Tambm pode possuir vrios itens e Sprints associados.
3. Membro: classe associativa entre as classes Usurio e Projeto. Ou seja, vincula um
usurio a um projeto. Tambm armazena outros dados, como o tipo do
participante do Projeto (se coordenador ou participante) e tambm a
confirmao da aceitao desses elementos na participao do projeto.
4. Sprint: possui informaes referentes s Sprints (iteraes) de um projeto. Cada
Sprint vinculada a um projeto e pode estar (ou no) presente em itens do
Product Backlog.
5. Item: possui informaes referentes ao item de um Product Backlog. Ele deve
estar sempre vinculado a um projeto e no mximo a uma Sprint. Alm disso, o item
pode conter vrias estimativas realizadas nos jogos de Planning Poker.
6. SessaoMembro: classe responsvel por manter a informao da sesso de um
participante num jogo de Planning Poker. Verifica o nome da sesso ao qual ele
pertence e se est dentro dela ou no. Vale lembrar que numa mesma sesso
podem participar vrios membros. Isso se todos compartilharem o mesmo nome
de sesso, o que ocorre para aqueles que esto no mesmo projeto.
7. Estimativa: armazena informaes das estimativas, como a rodada dela e o valor
informado da carta. Esses dados so vinculados a uma sesso de um membro.
8. Chat: armazena informaes de uma mensagem enviada por uma sesso de um
membro. Ou seja, as informaes das mensagens de chat so modeladas nessa
classe e depois disponibilizadas aos usurios que compartilham da mesma sesso
do membro em questo.
6.3. Diagrama Entidade-Relacionamento

O diagrama entidade-relacionamento uma representao para um modelo de dados
de um sistema num alto nvel de abstrao. Neste trabalho, a estrutura dele foi baseada no
diagrama de classes definido acima. A Figura 22 representa o diagrama E-R da ferramenta.
61
Figura 22. Diagrama E-R da ferramenta.
6.4. Arquitetura do Sistema

A arquitetura de um sistema consiste na definio dos componentes de software, suas
propriedades externas, e os relacionamentos com outros sistemas. A Figura 23 representa um
modelo da arquitetura da ferramenta.
A arquitetura totalmente dividida em camadas e isso foi necessrio ser feito para
organizar e separar os diferentes componentes e promovendo a coeso do sistema ao
compactar as partes semelhantes. Devido resoluo muito pequena da Figura 23, realizada
a seguir uma anlise por cada camada da arquitetura.
A estrutura baseada no padro MVC (Model-View-Controller), que se utiliza de trs
partes. A View a apresenta a interface visual do sistema que contm a sada de dados; o
Controller responsvel pela invocao de objetos ao Model e pelo controle da comunicao
62
que vem do usurio para o sistema e vice-versa; e o Model que define o contexto da aplicao,
regras de negcio e mudana sobre os dados.
Figura 23. Arquitetura da ferramenta.
A Figura 24 representa a camada de apresentao. Nela so includos todos os

artefatos relacionados com a interao direta do usurio com a aplicao (pginas PHP;
arquivos JavaScript e CSS; imagens). As telas do sistema esto nesta camada, incluindo as telas
do Planning Poker. Esta camada tem a responsabilidade de receber as informaes vindas dos
usurios e enviar para a linguagem do negcio.
Figura 24. Camada de apresentao.
A Figura 25 representa a camada de controle. Nela so includos todos os controles do

sistema. Existe um controlador principal, que valida a sesso de um usurio e redireciona para
controladores especficos, que por sua vez so responsveis por receber/enviar dados
particulares dependendo da funcionalidade executada pelo usurio.
63
Figura 25. Camada de controle.
A Figura 26 representa a camada de negcios. Nela est includa toda a lgica, regras,
validaes do negcio e responsvel por manipular os dados vindos das camadas anteriores,
e com o objetivo de expor as informaes para a camada de apresentao. Ela composta de
uma classe fachada, que baseada no padro de projeto Faade e cuja estrutura unifica as
interfaces do conjunto de subsistemas, simplificando a utilizao dos mesmos. As entidades
principais do diagrama de classes possuem em sua estrutura as prprias regras de negcio
(com exceo de SessaoMembro, cuja lgica est includa em MembroBO).
Figura 26. Camada de negcio.
64
A Figura 27 representa a camada de persistncia. Ela tem a responsabilidade de

armazenar as informaes geradas pela camada de negcio e ao mesmo tempo serve como
fonte de dados, pelo fato de ser integrada a um banco de dados.
As entidades principais do diagrama de classes possuem sua prpria estrutura para
integrao com o banco (com exceo de SessaoMembro, cujas funcionalidades de
persistncia esto includas em MembroDAO).
Figura 27. Camada de persistncia.
6.5. Prottipo
Para a elaborao desta ferramenta, foi desenvolvido um prottipo para melhor
compreenso do entendimento do negcio e para visualizar a navegao das telas. Num
primeiro momento, a proposta desse trabalho era criar um prottipo que fosse puramente
visual. No entanto, foi concebido o desenvolvimento de algumas funcionalidades, seguindo a
arquitetura e a lgica explanada nas sees anteriores deste captulo.
Para o desenvolvimento do prottipo foi escolhido um ambiente web, devido
portabilidade (independncia de plataforma) e maior disponibilidade do servio aos usurios. E
embora, tem sido planejado para este ambiente, o desenvolvimento da ferramenta no se
limita apenas neste tipo de tecnologias. Ela pode ser aplicvel a sistemas standalone ou que
utilizem plugins externos, como o caso de algumas aplicaes Java.
65
Sobre as tecnologias usadas no prottipo, como servidor web foi escolhido o Apache,
devido a sua robustez e segurana. Como linguagem de desenvolvimento, foi utilizado o PHP
(Hypertext Preprocessor) pela facilidade de implementao, flexibilidade, eficcia e fcil
integrao com vrias tecnologias. E por fim, o banco de dados utilizado foi o MySQL.
Para cada funcionalidade (item do Product Backlog) levantada deste trabalho, foi
elaborada uma tela correspondente funcionalidade descrita na estria. possvel visualizar a
figura do prottipo das telas de cada uma delas no Apndice A, separadas por item.
Quanto s estrias funcionais no prottipo, elas seguiram toda a arquitetura descrita
no documento, e assim como o diagrama de classes. A organizao das tabelas no banco de
dados foi baseada no diagrama E-R descrito. Dentre as estrias implementadas, podem ser
destacadas aquelas que envolvem cadastro e alterao de usurios; autenticao no sistema
(login e logout); cadastro, alterao, remoo e listagem de projetos; criao de Sprints;
cadastro, alterao, remoo e listagem de itens do Product Backlog; sistemas de convites
para participantes do projeto (envio e aceitao); troca de mensagem entre usurios numa
sesso de Planning Poker; e visualizao de um grfico de acompanhamento da evoluo do
projeto (Burndown Chart).
Embora a implementao do prottipo funcional fosse um requisito extra neste
trabalho, ela em geral foi bem realizada dentro do cronograma estabelecido para este trabalho
de graduao. O principal contraponto desta atividade que as estrias relacionadas sesso
e ao jogo do Planning Poker no foram desenvolvidas a tempo.

Esse captulo explicou uma proposta de ferramenta para se estimar com a tcnica de
Planning Poker. Devido falta de informaes apropriadas para o desenvolvimento de um
projeto com essa finalidade, a ideia desse trabalho foi realizar elaborar uma documentao
das funcionalidades necessrias para atender s caractersticas de uma tcnica de estimativa
de Planning Poker e que fosse aplicvel a projetos Scrum.
Para isso, foi feito um procedimento para concepo e elaborao de um projeto de
software, como elicitao dos requisitos, desenvolvimento dos diagramas fundamentais,
arquitetura do sistema, alm do desenvolvimento de um prottipo visual e parcialmente
funcional, para melhor visualizao e entendimento do contexto da ferramenta como um
todo.
66
Captulo 7
Concluso
Sabe-se que a estimativa a atividade que envolve mensurar uma observao sobre
determinado ponto. Dentro das prticas de desenvolvimento de software, a arte de estimar
fundamental para o gerenciamento de projetos, visto que atravs dela possvel obter
informaes relevantes sobre esforo, custos, cronograma, qualidade, riscos e outros. Para
isso, necessria alguma forma que possa avaliar do tamanho de um sistema, que a principal
mtrica responsvel para a elaborao e construo dele.
Dada a importncia do Scrum nos ltimos tempos e sua consolidao cada vez mais
notvel como uma metodologia de desenvolvimento de software, essencial utilizar um
recurso que se possa trabalhar com tcnicas estimativas geis que sejam compatveis com os
fundamentos dele.
O objetivo deste trabalho foi apresentar uma proposta de ferramenta para o apoio s
estimativas baseadas na tcnica de Planning Poker, que bastante comum em projetos geis,
utilizando os fundamentos da metodologia Scrum. A finalidade que equipes de projeto
possam compreender as funcionalidades por trs da elaborao deste trabalho e assim
desenvolver suas prprias ferramentas. Apesar de usar muitas das prticas geis, como o
levantamento de um Product Backlog, tambm foi utilizado recursos de metodologias
tradicionais como diagramas E-R e UML. A ideia era combinar as prticas das duas
metodologias para melhor compreenso do domnio, do contexto e da estrutura da
ferramenta.
Como abordado, o Planning Poker um modelo que atua de forma interativa e
colaborativa, o que exige a presena da equipe num mesmo local para poder realizar as
estimativas com sucesso. No entanto, existem muitas dificuldades para se trabalhar com
Planning Poker em equipes distribudas geograficamente, devido a falta de maior controle e
comunicao entre os membros. Um dos grandes pilares de motivao deste trabalho
justamente reduzir os impactos provocados pela falta de interaes presenciais.
A ferramenta apresentada de natureza multiusurio. A ideia foi elicitar os principais
requisitos dela, considerando todas as caractersticas abordadas, para que o trabalho possa ser
desenvolvido em projetos futuros. Inicialmente, a proposta deste trabalho que a aplicao
dessa ferramenta fosse voltada para a web, embora a estrutura planejada possa abranger
outras tecnologias.
67
Por fim, foi desenvolvido um pequeno prottipo visual para melhor entendimento das
funcionalidades descritas neste trabalho. A ideia compreender a navegao das telas e
visualizar o conjunto da obra de modo mais prximo de um sistema real em execuo. O
prottipo utilizado neste trabalho de cdigo aberto para que outros projetos possam
aproveit-lo e adapt-lo s prprias necessidades.
7.1. Trabalhos Futuros

Como trabalhos futuros, as funcionalidades da ferramenta proposta podem ser
colocadas como referncia para o desenvolvimento de projetos que tenham a finalidade de
estimar com Planning Poker. Mais do que isso, a ferramenta colabora para a aplicao dessa
tcnica de estimativa num projeto real que utiliza a metodologia Scrum, atravs do
acompanhamento da evoluo por grficos, com base na unidade de pontos de estria.
Alm disso, a ferramenta serve como um pequeno sistema de gerenciamento para
projetos Scrum, visto que sua elaborao foi pensada para que as equipes pudessem realizar
modificaes de dados do projeto e dos componentes do Product Backlog quando necessrios,
alm de trabalhar com Sprints. Portanto, uma proposta futura pode utilizar os requisitos
descritos neste trabalho como base para a criao de uma pequena ferramenta de
gerenciamento de projetos adaptvel para a empresa/organizao do interessado.
Por fim, pode ser concebido juntamente a essa ferramenta um pequeno sistema de
integrao com as ferramentas de gerenciamento de projetos j existentes no mercado, tais
como o TargetProcess ou o VersionOne, para facilitar o trabalho de equipes que j utilizam
esse tipo de ferramentas e que por ventura tenham a pretenso de migrar os dados de um
Backlog para o sistema proposto por este trabalho.
68
Referncias Bibliogrficas
Abu, Nelson S. R. J. (2010). "Blog do Abu - Material de Apoio". Verso 2.1. Disponvel:
<http://www.tavares.net.br/files/ebooks/SCRUM_BlogDoAbu_ApostilaDeApoio_v2_1.pdf>.
Acesso em 25 mai. 2012.
Agile Manifesto. (2011). "Manifesto for Agile Software Development". Agile Alliance.
Disponvel em: <http://www.agilemanifesto.org/>. Acesso em: 05 mai. 2012.
Albrecht, A. J. (1979). "Measuring Applications Development Productivity". IBM Applic.
Dev. Joint SHARE/GUIDE Symposium. Monterey: [s.n.].
Ambler, Scott W. (2009). "Examining the Agile Manifesto". Disponvel em:
<http://www.ambysoft.com/essays/agileManifesto.html>. Acesso em: 05 mai. 2012.
Bavani, Raja. (2009). "Critical Success Factors in Distributed Agile for Outsourced
Product
Development".
Computer
Society
of
India,
2009.
Disponvel
em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.167.430&rep=rep1&type=pdf>.
Acesso em 16. mai. 2012
Cavalcanti, E. de O. (2009). "FIRESCRUM: Ferramenta de Apoio Gesto gil de
Projetos Utilizando SCRUM". Dissertao (Mestrado) C.E.S.A.R - Centro de Estudos e
Sistemas Avanados do Recife, Recife.
Carvalho, B.V.; Mello, C.H.P. (2009). "Reviso, Anlise e Classificao da Literatura
sobre o Mtodo de Desenvolvimento de Produtos gil Scrum". XII Simpsio de Administrao
da Produo, Logstica e Operaes Internacionais (SIMPOI), So Paulo.
Clifton, Mark. Dunlap, J. (2003). "What is SCRUM?". 18 de Agosto. Disponvel em:
<http://www.codeproject.com/Articles/4798/What-is-SCRUM>. Acesso em: 05 mai. 2012.
Cohn, Mike. (2005) "Agile Estimating and Planning", Prentice Hall PTR. 368p.
Cohn, Mike. (2008) Non-functional Requirements as User Stories. Disponvel em:
<http://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories>.
Acesso em: 10 jul. 2012.
Conte, S.D.; Shen V.Y. (1985). "Software Engineering Metrics and Models". Menlo Park,
California: Benjamin/Cummings Publishing, 1985.
CTIC-UFPA. (2011). Procedimentos do Planning Poker, verso 1.3. Centro de
Tecnologia da Informao e Comunicao da Universidade Federal do Par.
69
CTIS Informtica. (2004). "Manual de Contagem de Ponto de Funo". Setembro.

Disponvel
em:
<http://sergiolaranja.net63.net/Blog/Livros/ManualdeContagemdePontosdeFuncao.pdf>
Dantas, V. F. (2003). "Uma Metodologia para o Desenvolvimento de Aplicaes Web
num Cenrio Global". Dissertao. Universidade Federal de Campina Grande. Campina Grande,
Julho.
DeMarco, T. (1991). "Controle de Projetos de Software". 9.ed. Rio de Janeiro: Editora
Campus.
DIVUS Tecnologia. (2012). "Gesto de Projetos com Scrum". Disponvel em:
<http://www.divus.com.br/bibliotecaVirtual/Apostila_Curso_GP_SCRUM_DIVUS-v1.1.pdf>.
Acesso em: 10 jun. 2012.
Florac, William A.; Park, Robert E.; Carleton, Anita D. (1997). "Practical software
measurement: measuring for process management and improvement" [S.l.], 1997. Disponvel
em: <http://www.sei.cmu.edu/pub/documents/97.reports/pdf/97hb003.pdf>. Acesso em: 20
mai. 2012.
Freire, Herval. (2003). "Calculando Estimativas: o Mtodo de Pontos de Caso de Uso".
Developers Magazine, nmero 78. Fevereiro.
Haugen, N. C. (2006). "An Empirical Study of Using Planning Poker for User Story
Estimation". Proceedings of the Conference on AGILE 2006 (pp. 23-34). Washington (DC): IEEE
Computer Society.
Hazan, Cludia. (2008) "Anlise de Pontos de Funo: Uma aplicao nas estimativas
de tamanho de Projetos de Software". Engenharia de Software, Rio de Janeiro, 01 de junho.
Highsmith, J., Cockburn A. (2001). "Agile Software Development: The Business of
Innovation". Pgs. 120-122. (2001)
Huzita, Elisa H. M.; da Silva, Csar A.; Wiese, Igor S.; Tait, Tania F. C., Quinaia, Marcos;
Schiavoni, Flvio L. (2008). "Um Conjunto de Solues para Apoiar o Desenvolvimento
Distribudo de Software". In: II Workshop de Desenvolvimento Distribudo de Software - WDDS,
Campinas,
SP.
Disponvel
em:
<http://www.lbd.dcc.ufmg.br:8080/colecoes/wdds/2008/011.pdf>. Acesso em: 16 mai. 2012.

IFPUG. (2000). "Function Point Counting Practices Manual: Release 4.3". International
Function Point Users Group. Jan.
70
Karner, G. (1993). "Metrics for Objectory". University of Linkping. Sweden. (LiTH-IDAEx-9344:21).

Kniberg, Henrik (2007). "Scrum and XP from the Trenches". Disponvel em:
<http://www.infoq.com/minibooks/scrum-xp-from-the-trenches>. Acesso em: 10 mai. 2012.
Lima, Adailton M.; Reis, Rodrigo Q. (2008) "Compartilhamento de Informaes sobre
Processos em Ambientes Descentralizados de Desenvolvimento de Software". In: II Workshop
de Desenvolvimento Distribudo de Software - WDDS, Campinas, SP.
Disponvel em:
<http://www.lbd.dcc.ufmg.br:8080/colecoes/wdds/2008/008.pdf>. Acesso em: 16 mai. 2012.

Martins, J. C. C. (2009). "Tcnicas para gerenciamento de projetos de software".
SoPaulo: Brasport.
Mountain
Goat
Software.
(2012).
"Planning
Poker".
Disponvel
em:
<http://www.planningpoker.com>. Acesso em: 10 mai. 2012.

Mundim, A. P. F.; Rozenfeld, H.; Amaral, D. C.; Silva, S. L.; Guerreiro, V.; Horta, L. C.
(2002). "Aplicando o cenrio de desenvolvimento de produtos em um caso prtico de
capacitao profissional". In: Gesto & Produo. v. 9, n. 1, p. 1-16, Abril.
Pereira, Paulo; Torreo, Paula; Maral, Ana Sofia. (2007). "Entendendo Scrum para
Gerenciar
Projetos
de
Forma
gil".
Disponvel
em:
<http://www.siq.com.br/DOCS/EntendendoScrumparaGerenciarProjetosdeFormaAgil.pdf>.
Acesso em: 06 mai. 2012.
Pressman, R. S. (2011). "Engenharia de Software". 7 ed. So Paulo: Ed. McGraw-Hill.
Reis, Helena M. (2010). "Scrum: Mtodo gil para Gesto de Projetos de Software". 09
out. Disponvel: <http://helenamcd.ueuo.com/images/artigos/gestaodeprojetos/scrum.pdf>.
Acesso em: 17 mai. 2012.
Royce, W. W. (1970). "Managing the development of large software systems: concepts
and techniques". Proc. IEEE Westcon, Los Angeles, CA.
Santos, Aline et al. (2010). "Experincia Acadmica de uma Fbrica de Software
utilizando Scrum no Desenvolvimento de Software". In: IV Workshop Brasileiro de Mtodos
geis
(Agile
Brazil),
PUC-RS,
Porto
Alegre,
RS.
p.
86-98.
Disponvel
em:
<http://www.agilebrazil.com/2010/pt/wbma2010.pdf>. Acesso em: 16 mai. 2012.

Schwaber, K. (1995). "Scrum Development Process". OOPSLA'95 Workshop on Business
Object Design and Implementation. Springer-Verlag.
71
Schwaber, K. (2004). "Agile Project Management with Scrum". Microsoft Press.

mite, D., Wohlin, C., Gorschek, T., and Feldt, R. (2010). "Empirical Evidence In Global
Software Engineering: A Systematic Review". Empirical Software Engineering, vol. 15, pp. 91
118.
Soares, Michel dos Santos. (2004). "Comparao entre Metodologias geis e
Tradicionais para o Desenvolvimento de Software". Unipac - Universidade Presidente Antnio
Carlos, Faculdade de Tecnologia e Cincias de Conselheiro Lafaiete.
Soares, M. D. S. (2009). "Metodologias geis Extreme Programming e Scrum para o
Desenvolvimento de Software". Revista Eletrnica de Sistemas de Informao, Conselheiro
Lafaiete, v. 3, n. 1, 2009. ISSN 1677-3071.
Sutherland, Jeff et al. (2007) "Distributed Scrum: Agile Project Management with
Outsourced Development Teams". In: Proceedings of the 40th Hawaii International Conference
on System Sciences, 40.
Varaschim, Jacques D. (2009). "Implantando o SCRUM em um Ambiente de
Desenvolvimento de Produtos para Internet". Departamento de Informtica da PUC. Rio de
Janeiro. Fev.
Vazquez, C. E.; Simes, G. S.; Albert, R. M.. (2010). "Anlise de Pontos por Funo:
Medio, Estimativas e Gerenciamento de Projetos de Software". 9a. Edio. rica. So Paulo:
2010.
Woodward, Elizabeth; Surdek, Steffan; Ganis, Matthew. (2010). "A Practical Guide to
Distributed Scrum". IBM. Disponvel em: <http://pt.scribd.com/doc/42021760/A-practicalguide-to-Distributed-Scrum>. Acesso em: 16 mai. 2012.
Yoshima, Rodrigo. (2007). "Gerenciamento de Projetos com Scrum". Aspercom. Abril.
Disponvel em: <http://www.aspercom.com.br/ead/mod/resource/view.php?id=245>. Acesso
em 15 mai. 2012.
Zanatta, Alexandre. (2004) "xScrum: uma proposta de extenso de um Mtodo gil
para Gerncia e Desenvolvimento de Requisitos visando adequao ao CMMI Florianpolis".
Dissertao (Mestrado em Cincia da Computao) - Curso de Ps-Graduao em Cincia da
Computao,
Universidade
Federal
de
Santa
Catarina.
Disponvel
em:
<www.tede.ufsc.br/teses/PGCC0651.pdf>. Acesso em: 12 mai. 2012.
72
Apndice A Product Backlog

Este apndice apresenta o Product Backlog da ferramenta. Ele contm as estrias que
descrevem o funcionamento do sistema e envolvem as tarefas a serem desenvolvidas e
posteriormente utilizadas pelos usurios. As estrias foram descritas na forma de cartes,
conforme mostrado nas Figuras 3 e 4 do Captulo 3 deste documento.
Na etapa de levantamento das estrias, as seguintes funcionalidades foram
identificadas:
Cadastrar Usurio
ID: 001
Nome: Cadastrar Usurio
Como um usurio, eu gostaria de poder cadastrar no sistema, para que eu possa ser identificado e ter
posterior acesso ao sistema.
Comportamento de Sucesso:
1.
Preencher corretamente todos os campos no formato indicado e clicar em "Cadastrar". Deve

retornar a tela principal do sistema e exibir uma mensagem de sucesso.
Comportamento de Erro:
1.
Preencher os campos num formato que no o indicado ou no preencher pelo menos um

deles e clicar em "Cadastrar". Deve exibir uma indicao de erro nos campos incorretos.
2.
Preencher a senha diferente da confirmao e clicar em "Cadastrar". Deve exibir uma

indicao de erro nos campos de senha.
3.
Preencher um e-mail que j existe no sistema e clicar em "Cadastrar". Deve exibir uma
mensagem de erro.
Notas:
1.
Os campos devem ser: nome, e-mail, senha e confirmar senha.
2.
Utilizar criptografia para a senha.
73
Efetuar Login
ID: 002
Nome: Efetuar Login
Como um usurio, eu gostaria de poder realizar o login no sistema, para que eu possa ter acesso ao
sistema.
1.
Preencher corretamente o e-mail e a senha informados no sistema e clicar em Login. Deve ter
acesso a pgina principal do usurio.
1.
No preencher pelo menos um dos campos e clicar em Login.. Deve exibir uma indicao de
erro nos campos no preenchidos.
2.
Preencher um e-mail ou senha incompatveis ou que no existam no sistema e clicar em

Login. Deve exibir uma mensagem de erro.
Notas:
1.
Os campos devem ser: e-mail e senha.
2.
74
Efetuar Logout
ID: 003
Nome: Efetuar Logout
Como um usurio, eu gostaria de poder realizar logout no sistema, para que eu possa sair do sistema e
minhas informaes no ficassem mantidas na sesso dele.
1.
Clicar no link "Sair" do menu do sistema. Deve sair do sistema e encerrar a sesso do usurio.
75
Listar Projetos
ID: 004
Nome: Listar Projetos
Como um usurio, eu gostaria listar os projetos separados por coordenador e por participante para que eu
possa ver em quais deles participo como as coes que eu possa realizar nele.
1.
Ao acessar o sistema, sero listados os projetos que o usurio participa como coordenador e
como participante.
Notas:
1.
Deve apresentar informaes essenciais como data inicial, data final, nmero de itens do
Product Backlog, estimativa total do projeto e nmero de Sprints.
2.
Para o coordenador, as aes que devem ser mostradas por projeto so: Ver Projeto, Alterar
Projeto, Ver Product Backlog, Manter Sprints, Ver Grfico de Acompanhamento, Enviar
Convite, Lista de Membros e Remover Projeto.
3.
Para o participante, as aes que devem ser mostradas por projeto so: Ver Projeto, Ver
Product Backlog, Ver Grfico de Acompanhamento e Lista de Membros.
76
Alterar Usurio
ID: 005
Nome: Alterar Usurio
Como um usurio, eu gostaria de poder alterar meu nome ou senha, para que eu possa ser identificado
de outra maneira no sistema.
Tela 1:
Tela 2:
1.
Clicar no link "Alterar Usurio" no menu principal. Preencher o nome e clicar em "Alterar".
Deve retornar a tela de acesso do usurio e exibir uma mensagem de sucesso.
2.
Clicar no link "Alterar Usurio" no menu principal. Preencher uma nova senha, a confirmao e
a senha atual e clicar em "Alterar". Deve retornar a tela principal do sistema e exibir uma
mensagem de sucesso.
1.
Preencher a senha diferente da confirmao e clicar em "Alterar". Deve exibir uma indicao
de erro nos campos de senha.
2.
Preencher a senha atual incorretamente e clicar em "Alterar". Deve exibir uma mensagem de
erro.
3.
No preencher pelo menos um dos campos e clicar em "Alterar". Deve exibir uma indicao de
erro nos campos no preenchidos.
Notas:
1.
Os campos devem ser: nome, e-mail (exibio), senha (nova), confirmar senha e senha atual.
2.
77
Cadastrar Projeto
ID: 006
Nome: Cadastrar Projeto
Como um usurio, eu gostaria de poder cadastrar projetos do qual fao parte, para que eu possa
coorden-los.
Tela 1:
Tela 2:
1.
Clicar no link "Novo Projeto" no menu principal. Preencher corretamente todos os campos no
formato indicado e clicar em "Cadastrar". Deve retornar a tela de acesso do usurio e exibir
uma mensagem de sucesso.
1.

deles e clicar em "Cadastrar". Deve exibir uma indicao de erro nos campos incorretos.
Notas:
1.
Os campos devem ser: nome, descrio, data inicial e data final.
78
Ver Projeto
ID: 007
Nome: Ver Projeto
Como um usurio, eu gostaria de poder ver detalhes de um projeto do qual fao parte, para que eu
possa ter maiores informaes sobre ele.
Tela 1:
Tela 2:
1.
Ao clicar no link "Ver Informaes do Projeto", ser possvel ver informaes mais especficas
de um projeto.
Notas:
1.
Os campos visualizados devem ser: nome, responsvel, e-mail do responsvel, descrio, data
inicial, data final, nmero de iteraes, estimativa e nmero de itens no Product Backlog.
79
Alterar Projeto
ID: 008
Nome: Alterar Projeto
Como um coordenador, eu gostaria de poder alterar projetos do qual fao parte, para que eu possa
modificar algumas informaes sobre ele.
Tela 1:
Tela 2:
1.
Clicar no link "Alterar Projeto" de um dos projetos. Preencher corretamente todos os campos
no formato indicado e clicar em "Alterar". Deve retornar a tela principal do sistema e exibir
1.

deles e clicar em "Alterar". Deve exibir uma indicao de erro nos campos incorretos.
Notas:
1.
Os campos devem ser: nome, descrio, data inicial e data final.
80
Manter Sprints
ID: 009
Nome: Manter Sprints
Como um coordenador, eu gostaria criar manter uma quantidade de Sprints definidas para os projetos,
cada uma com seus intervalos, para que eu possa definir seus prazos e associar itens a eles. Gostaria de
poder edit-las tambm, se necessrio.
Tela 1:
Tela 2:
1.
Clicar no link "Sprints" de um dos projetos. Preencher uma quantidade de Sprints desejadas.
Depois, devem-se preencher no formato correto todas as datas de incio e fim das Sprints e
clicar em "Alterar". Deve retornar a tela do usurio e exibir uma mensagem de sucesso.
1.
No preencher o campo da quantidade de Sprints ou preencher num formato que no o

indicado e clicar em "Ok". Deve exibir uma indicao de erro nesse campo.
2.
No preencher pelo menos um dos campos de Sprints ou preencher num formato que no o
indicado e clicar em "Alterar". Deve exibir uma indicao de erro nos campos no preenchidos.
Notas:
1.
Os campos devem ser: incio e final da Sprint na quantidade informada.
81
Enviar Convites
ID: 010
Nome: Enviar Convites
Como um coordenador, eu gostaria enviar convites a outros usurios do sistema para que eles possam
colaborar no projeto como participantes.
Tela 1:
Tela 2:
1.
Clicar no link "Enviar Convites" de um dos projetos. Preencher uma quantidade de convites.
Depois, devem-se preencher no formato correto os e-mails dos usurios que deseja convidar e
que estejam cadastrados no sistema e clicar em "Enviar". Deve retornar a tela de acesso do
usurio e exibir uma mensagem de sucesso.
1.
No preencher o campo da quantidade de convites ou preencher num formato que no o

indicado e clicar em "Ok". Deve exibir uma indicao de erro nesse campo.
2.
No preencher pelo menos um dos campos ou num formato que no o indicado e clicar em
"Enviar". Deve exibir uma indicao de erro nos campos no preenchidos.
3.
Preencher e-mails vlidos, mas que no so de usurios cadastrados no sistema. Deve exibir
uma mensagem de erro dos e-mails no cadastrados.
Notas:
1.
Os campos devem ser os e-mails dos convidados na quantidade informada.
82
Aceitar Convites
ID: 011
Nome: Aceitar Convites
Como um usurio, eu gostaria aceitar convites vindos de outros usurios do sistema para que eu possa
participar (ou no) do projeto deles.
Tela 1:
Tela 2:
1.
Clicar no link "Ver Convites" no menu principal. Ser exibida uma lista de convites para o
usurio, com o nome do projeto a ser convidado. Depois, deve-se escolher a opo para aceitar
participar do projeto. Deve retornar a tela de acesso do usurio e exibir uma mensagem de
sucesso na operao escolhida.
1.
Clicar no link "Ver Convites" no menu principal. Ser exibida uma lista de convites para o
usurio, com o nome do projeto a ser convidado. Depois, deve-se escolher a opo para
rejeitar participar do projeto. Deve retornar a tela de acesso do usurio e exibir uma
mensagem de sucesso na operao escolhida.
Notas:
1.
As aes que devem ser mostradas por convite so: Aceitar Participar e Rejeitar Participar.
83
Ver Participantes de um Projeto

ID: 012
Nome: Ver Participantes de um Projeto
Como um usurio, eu gostaria ver os participantes de um projeto que eu tambm participo/coordeno

para que eu possa ver quem so eles e verificar as funes de cada um.
Tela 1:
Tela 2:
1.
Clicar no link Listar Participantes de um dos projetos. Ser exibida uma lista de participantes
do projeto para o usurio.
Notas:
1.
Listar por nome, e-mail e tipo de participao do responsvel.
Remover Projeto
ID: 013
Nome: Remover Projeto
Como um coordenador, eu gostaria remover um projeto que no tenha mais finalidade em mant-lo.
1.
Clicar no link "Remover Projeto" de um dos projetos. Ser exibida uma tela pedindo
confirmao da operao. Ser exibida uma mensagem sobre a remoo.
84
Exibir Product Backlog

ID: 014
Nome: Exibir Product Backlog
Como um usurio, eu gostaria ver o Product Backlog de um dos projetos dos quais participo, seja como
coordenador ou como participante para que eu possa ver informaes dos itens/tarefas a serem
implementados nele.
Tela 1:
Tela 2:
1.
Clicar no link "Remover Projeto" de um dos projetos. Vo ser listados os itens que fazem parte
de um Product Backlog do projeto, com informaes bsicas como: nome do item, prioridade,
estimativa, data de concluso e iterao da qual o item participa.
Notas:
1.
As aes que devem ser mostradas por item do Product Backlog so: Ver Item, Alterar Item
e Remover Item.
85
Cadastrar Item
ID: 015
Nome: Cadastrar Item
Como um coordenador, eu gostaria de poder cadastrar itens de um projeto do qual fao parte, para que
eu possa acompanh-los e estim-los no sistema.
Tela 1:
Tela 2:
1.
Clicar no link "Novo Item" no menu principal. Preencher corretamente todos os campos no
formato indicado e clicar em "Cadastrar". Deve retornar a tela do Product Backlog do projeto e
exibir uma mensagem de sucesso.
1.
No preencher pelo menos um dos campos ou preencher num formato que no o indicado e
clicar em "Cadastrar". Deve exibir uma indicao de erro nos campos no preenchidos.
Notas:
1.
Os campos devem ser: ID, nome, prioridade, estria e notas.
86
Ver Item
ID: 016
Nome: Ver Item
Como um usurio, eu gostaria de poder ver detalhes de um item de um Product Backlog de um projeto
do qual fao parte, para que eu possa ter maiores informaes sobre ele.
Tela 1:
Tela 2:
1.
Ao clicar no link "Ver Informaes do Item" de algum item, ser possvel ver informaes mais
especficas de um item.
Notas:
1.
Os campos visualizados devem ser: ID, nome, prioridade, estimativa, estria, notas, concludo,
data de concluso (se j estiver concludo) e a Sprint (se houver alguma relacionada ao item).
87
Alterar Item
ID: 017
Nome: Alterar Item
Como um usurio, eu gostaria de poder alterar um item de algum projeto do qual fao parte, para que
eu possa modificar algumas informaes sobre ele.
Tela 1:
Tela 2:
1.
Clicar no link "Alterar Item" de algum item. Preencher corretamente todos os campos no
formato indicado e clicar em "Cadastrar". Deve retornar a tela de acesso do usurio e exibir
1.
No preencher pelo menos um dos campos (que no seja o "Concludo") ou preencher num
formato inadequado e clicar em "Alterar". Deve exibir uma indicao de erro nesses campos.
2.
Preencher o campo "Concludo" e no preencher o campo "Data de Concluso" ou preencher

no formato inadequado. Deve exibir uma indicao de erro nesse campo.
Notas:
1.
Os campos devem ser: ID, nome, prioridade, estria, notas, concludo, data de concluso e
Sprint (se houver alguma cadastrada no projeto).
88
Remover Item
ID: 018
Nome: Remover Item
Como um coordenador, eu gostaria remover um item que no tenha mais finalidade em mant-lo no
projeto.
1.
Clicar no link "Remover Item" de um dos itens do Product Backlog. Ser exibida uma tela
pedindo confirmao da operao. Ser exibida uma mensagem sobre a remoo.
89
Ver Grfico de Acompanhamento

ID: 019
Nome: Ver Grfico de Acompanhamento
Como um usurio, eu gostaria visualizar um grfico de acompanhamento (Burndown Chart) para que eu
verificasse a evoluo do projeto ao longo de semanas ou Sprints.
Tela 1:
Tela 2:
1.
Caso j os itens do Product Backlog do projeto j tenham sido estimados, clicar no link
"Visualizar Grfico de Acompanhamento" de um dos projetos. Ser exibida uma tela pedindo
para selecionar a evoluo em semanas ou Sprints.
1.
preciso haver estimado os itens do projeto para visualizar o grfico. Caso contrrio, isso no
ser possvel.
Notas:
1.
Necessrio o uso de uma biblioteca que gera grficos para poder desenh-los de acordo com os
parmetros inseridos, correspondentes aos valores das estimativas.
90
Iniciar Sesso Planning Poker

ID: 020
Nome: Iniciar Sesso Planning Poker
Como um coordenador, eu gostaria de iniciar uma sesso de um projeto para que os participantes
possam jogar Planning Poker.
Tela 1:
Tela 2:
1.
Clicar no boto Iniciar Planning Poker, que aparece no Product Backlog de um dos projetos.
Ser exibida uma tela com o incio da sesso, com as informaes da estria, a tela de
estimativas, a tela de configuraes do participante e o menu de chat para os participantes
trocarem informaes.
Notas:
1.
preciso elaborar uma sesso compartilhada, de modo que somente os usurios autorizados
vejam as mesmas informaes e esses dados sejam frequentemente atualizados.
2.
O boto Iniciar Planning Poker somente ser exibido ao coordenador do projeto.
3.
Vrias sesses podem ser criadas para o mesmo projeto, porm somente a ltima a que vai
prevalecer.
91
Entrar numa Sesso Planning Poker

ID: 021
Nome: Entrar numa Sesso Planning Poker
Como um participante, eu gostaria de entrar numa sesso de um projeto para que eu possa jogar
Planning Poker.
Tela 1:
Tela 2:
1.
Clicar no boto "Entrar no Planning Poker", que aparece no Product Backlog de um dos
projetos. Esse boto ser disponibilizado somente quando o coordenador iniciar uma sesso.
Ser exibida uma tela com o incio da sesso, com as informaes da estria, a tela de
estimativas, a tela de configuraes do participante (baralho e opo pra sair da sesso) e o
menu de chat para os participantes trocarem informaes.
92
Escolher Carta
ID: 022
Nome: Escolher Carta
Como um participante, eu gostaria escolher uma carta do meu baralho para que eu possa definir minha
estimativa para um item avaliado.
1.
Dentro da tela de configuraes do participante, ser possvel clicar numa das cartas com a
estimativa desejada e confirmar clicando no boto Escolher Carta. A escolha do participante
ser mostrada na tela das estimativas quando o coordenador autorizar.
Notas:
1.
As cartas do baralho do participante devem ter os 13 valores seguintes: 0, , 1, 2, 3, 5,

8, 13, 20, 40, 100, ? e a xcara de caf.
2.
O sistema deve armazenar um valor numrico para representar as cartas da xcara de caf e do
?.
93
Mostrar Cartas
ID: 023
Nome: Mostrar Cartas
Como um coordenador, eu gostaria de exibir as cartas dos participantes quando todos eles as
confirmarem.
1.
Dentro da tela de configuraes do coordenador, ser possvel visualizar o boto Mostrar

Cartas para exibir as estimativas. Ao clic-lo, sero viradas as cartas de cada usurio.
Notas:
1.
Habilitar o boto somente quando todos os jogadores escolherem suas cartas.
94
Definir Estimativa para um Item

ID: 024
Nome: Definir Estimativa para um Item
Como um coordenador, eu gostaria de definir uma estimativa para um item quando todos os
participantes confirmarem suas estimativas.
1.
Dentro da tela de configuraes do coordenador, ser possvel que ele estabelea um valor
para inserir a estimativa definitiva da estria. Deve preencher corretamente o campo no
formato de nmeros e clicar em "Definir Estimativa". Deve exibir uma mensagem de sucesso e
passar automaticamente ao prximo item. Aos participantes, ser exibida a escolha do
coordenador.
1.
Preencher incorretamente o campo no formato de nmeros e clicar em "Ok". Deve exibir uma
mensagem de erro.
2.
No preencher o campo e clicar em "Ok". Deve exibir uma mensagem de erro.
Notas:
1.
Habilitar os campos quando todos os jogadores exibirem suas cartas.
95
Realizar Nova Rodada

ID: 025
Nome: Realizar Nova Rodada
Como um coordenador, eu gostaria realizar uma nova rodada de estimativa para um item para o caso de
grande diferena de estimativas dos participantes at que estas tendam a um valor prximo.
Tela 1:
Tela 2:
1.
Quando todos os participantes exibirem suas estimativas, ser possvel visualizar um boto
para realizar uma nova rodada dentro da tela de configuraes do coordenador. Ao clic-lo, os
participantes vo realizar uma nova rodada de Planning Poker sobre o item estimado.
Notas:
1.
Habilitar o boto quando todos os jogadores exibirem suas cartas na rodada anterior.
96
Sair da Sesso
ID: 026
Nome: Sair da Sesso
Como um participante, eu gostaria sair de uma sesso no momento que eu achasse conveniente.
1.
Dentro da tela de configuraes do coordenador, ser possvel visualizar o boto Sair da

Sesso. Ao clicar nele, o usurio sa da sesso e retorna a tela principal do usurio com uma
mensagem de confirmao. Aos outros participantes, ser exibida uma mensagem informando
a sada do usurio.
97
Finalizar Sesso
ID: 027
Nome: Finalizar Sesso
Como um coordenador, eu gostaria finalizar uma sesso quando todos os itens do projeto forem
estimados.
2.
Quando forem definidas as estimativas de todos os itens, ser possvel visualizar um boto com
o nome "Finalizar Sesso" para o coordenador encerrar aquela sesso ao clic-lo.
Notas:
1.
Ao finalizar uma sesso, no se deve permitir o uso dela novamente por nenhum usurio.
2.
Todos os usurios sairo automaticamente dela.
98
Chat da Sesso
ID: 028
Nome: Chat da Sesso
Como um usurio, eu gostaria ter acesso a um chat numa sesso para que eu possa trocar informaes
com outros participantes do projeto enquanto realizamos as estimativas. Gostaria tambm de ver o
histrico de mensagens enviadas.
1.
Preencher o campo mensagem com alguma informao e clicar em Enter. A mensagem ser
exibida na lista para todos os outros usurios da sesso visualizar.
Notas:
1.
As mensagens s possuem validade para essa sesso. Mesmo se for criada uma nova sesso
para o projeto em questo, o histrico das mensagens da sesso anterior no aparece na nova.
99
Apndice B Backlog de Requisitos No Funcionais

Este apndice apresenta o Backlog de requisitos no funcionais da ferramenta. Ele
contm informaes sobre as caractersticas do sistema. Assim como as funcionalidades do
Product Backlog foram descritos anteriormente atravs de estrias, possvel fazer o mesmo
para descrever os requisitos funcionais. Assim, as estrias dos requisitos no funcionais foram
descritas na forma de cartes, conforme mostrado na Figura 3 do Captulo 3 deste documento.
Os requisitos no funcionais deste projeto so os seguintes:
Performance
ID: 001
Nome: Performance
Como um usurio, eu gostaria que o sistema apresentasse uma performance aceitvel, de modo que o
tempo de uma solicitao seja o mnimo possvel.
Usabilidade
ID: 002
Nome: Usabilidade
Como um usurio, eu gostaria que o sistema fosse intuitivo e fcil de usar com interface simples,
exibindo as informaes corretamente e com mensagens de erro claras e compreensveis.
Disponibilidade
ID: 003
Nome: Disponibilidade
Como um usurio, eu gostaria que o sistema permanecesse o maior tempo possvel disponvel para o
acesso e para execuo das operaes e que evitasse filas de espera pela indisponibilidade.
Manual de Instalao
ID: 004
Nome: Manual de Instalao
Como um usurio, eu gostaria que o sistema possusse um manual de instalao, para que eu
encontrasse todas as informaes necessrias, em caso de dvidas, no momento de instal-lo e
configur-lo.
100
Manual do Usurio
ID: 005
Nome: Manual do Usurio
Como um usurio, eu gostaria de um manual do usurio que fosse compressvel e objetivo, para que eu
possa encontrar nele todas as informaes necessrias sobre o uso do sistema.
Escalabilidade
ID: 006
Nome: Escalabilidade
Como um usurio, eu gostaria que o sistema fosse bom o suficiente para comportar uma razovel
quantidade de usurios simultaneamente que estejam executando as tarefas dele e ao mesmo tempo
fosse capaz de trabalhar de maneira uniforme.
Integridade
ID: 007
Nome: Integridade
Como um usurio, eu gostaria que as informaes que eu inserisse no sistema estejam corretas e que
quando eu realizasse consultas, esses dados estejam consistentes com o que eu havia inserido antes.
Privacidade
ID: 008
Nome: Privacidade
Como um usurio, eu gostaria que as informaes que eu inserisse no sistema fossem apenas
visualizadas ou alteradas por pessoas autorizadas por mim, como por exemplo, na edio de um dos
itens de um Product Backlog, ou no acesso a sesso do Planning Poker.
Legibilidade do Cdigo
ID: 009
Nome: Legibilidade do Cdigo
Como um desenvolvedor, eu gostaria o que o cdigo do sistema fosse o mais simples e legvel possvel
para que eu e outros desenvolvedores possamos compreend-lo, pois a proposta que este sistema
possa ser continuado no futuro. Para isso, importante colocar comentrios, dividir o sistema em
camadas e elaborar uma boa documentao.
101

Ferramenta Planning Poker Scrum

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Ferramenta Planning Poker Scrum

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDADE FEDERAL DE PERNAMBUCO

GRADUAO EM CINCIA DA COMPUTAO

Ferramenta para apoio estimativa baseada em

Dennis Williams Alves da Silveira

UNIVERSIDADE FEDERAL DE PERNAMBUCO

Ferramenta para apoio estimativa baseada em

Dennis Williams Alves da Silveira

Monografia apresentada junto ao curso de Cincia da

A virtude est toda no esforo.

Calcular Valor do Fator de Ajuste ........................................................................................ 39

Alterar Projeto ......................................................................................................................... 80

As ferramentas descritas tm a possibilidade de auxiliar projetos geis em alguns

1.2. Estrutura do Documento

aprimor-lo, poder facilitar a compreenso de todos os envolvidos no entendimento do

1. A maior prioridade satisfazer ao cliente desde o incio por meio de entrega

Figura 1. Metodologias geis nas empresas. Fonte: http://www.versionone.com (2011)

2.2. Consideraes Finais

3.1. Ciclo de Desenvolvimento

Figura 2. Ciclo de Desenvolvimento do Scrum

A primeira fase do Scrum o pr-planejamento (pre-game), na qual um projeto se

3.2. Papis no Scrum

2. Ao finalizar as estimativas verificado se o tempo do Sprint suficiente para a

Daily Scrum Meeting

Sprint Review Meeting

Sprint Retrospective Meeting

Como um visitante do site eu gostaria de mandar um e-mail de contato

Como um cliente eu gostaria de buscar por um produto

Como um cliente eu gostaria de colocar um produto no carrinho de compras

Como um cliente eu gostaria de pagar a compra com o carto de crdito

ID: uma identificao nica, normalmente um nmero com autoincremento, com

Nome: um nome curto e descritivo para a estria, como: Ver o histrico de

Prioridade: a pontuao de importncia dessa estria para o Product Owner.

Estimativa: a estimativa inicial da equipe sobre o esforo necessrio para

Descrio: uma descrio em alto nvel de como a estria ser demonstrada na

Notas: quaisquer outras informaes adicionais.

Como um cliente eu gostaria de

abrir a pgina de depsito,

preocupar com criptografia

depositar R$ 10,00, ir para a

pgina do meu saldo e verificar

Como um cliente eu gostaria de

Usar paginao para evitar

fazer um depsito e verificar se

consultas muito grandes ao

o novo depsito listado.

banco de dados. Projetar de

Figura 3. Exemplo de um carto de estria.

Confirmaes (Testes) so os casos de testes no verso do carto. Os testes facilitam o

Figura 4. Exemplo de testes de um carto de estria.

Figura 5. Exemplo de um Sprint Backlog.

Figura 6. Grfico Burndown da Sprint. Fonte: http://epf.eclipse.org/wikis/scrumpt/Scrum/

3.5. Planejamento da Sprint

Existncia do Product Backlog e que cada item esteja estimado.

Deve existir apenas um Product Backlog e um Product Owner.

O Product Owner deve entender todos os itens do Product Backlog, mas em

Apenas o Product Owner pode atribuir a nota de importncia aos itens do

planejamento pode afetar o andamento da Sprint e causar impactos ao cronograma do projeto

3.6. Scrum para Equipes Distribudas

Equipes Isoladas: H uma independncia dentre os membros geograficamente

Scrum Distribudo de Scrums: Cada local possui uma equipe multidisciplinar e as

Scrums Integrados: Cada equipe possui integrantes em diversos locais. As reunies

A estratgia mais comum para diminuir os impactos causados pelo inconveniente da