Scrum BTD

2010
Metodologia e
Documentação do Sistema
Scrum BTD
Benedito Germano Neponuceno

Luis Eduardo Xavier Alves
Tânia Braga Almeida
__________________________________
www.bgnweb.com.br
25/12/2010
Benedito Germano Neponuceno
Luis Eduardo Xavier Alves
Tânia Braga Almeida
Metodologia e
Documentação do Sistema
Scrum BTD
Especificações do Sistema Scrum

BTD, desenvolvido para o controle do
desenvolvimento de softwares
tomando como base as metodologias
Scrum e Extreme Programming
Brasília, dezembro 2010

Histórico de Revisão
Data Vers Descrição Autor
ão
08/10/20 0.1 Criação do documento inicial com Benedito Germano
10 a modelagem do processo de Neponuceno
negócio
11/10/20 0.1.1 Inclusão da visão geral do Benedito Germano
10 sistema e pequenas correções na Neponuceno
modelagem do processo de
negócio, adicionado formulários
anexos.
15/10/20 0.1.2 Inclusão do Caso de Uso Luis Eduardo
10 Cadastrar Equipes de Xavier Alves
Desenvolvedores
15/10/20 0.1.3 Inclusão dos Casos de Uso: Tânia Braga
10 • Cadastrar Product Backlog Almeida
• Cadastrar Usuário
25/10/20 0.1.4 Revisão do Documento; Luis Eduardo
10 Inclusão dos Casos de Uso: Xavier Alves
• Cadastrar Sprint
• Cadastrar Equipe
• Histórico da Sprint
Dedicamos a Deus e a todos os nossos amigos
que nos ajudaram na construção desta ferramenta
e principalmente a todos que dela fazerem uso

Agradecimentos
Agradecemos a todos que nos ajudaram
na elaboração deste trabalho,
principalmente ao Prof. Ricardo Santana.
“Comece fazendo o que é necessário,
depois o que é possível,
e de repente você estará fazendo o impossível.”
São Francisco de Assis

Resumo
Este trabalho descreve um conjunto de requisitos utilizados no

desenvolvimento do sistema “Scrum BTD”. Ele foi desenvolvido para auxiliar
no controle do desenvolvimento de softwares utilizando-se de duas
metodologias: Scrum e XP (Extreme Programming). O resultado é um
sistema que abrange os dois métodos de desenvolvimento ágil de softwares
de forma customizada para ser utilizada junto com ele.
Palavras-chave: Scrum, XP (Extreme Programming), metodologia,

software, sistema, Scrum BTD.
Abstract
This paper describes a set of requirements used in the development

of "Scrum BTD. It was developed to assist in the control of software
development using two methodologies: Scrum and XP (Extreme
Programming). The result is a system that embraces both agile
development methods of software customized form to be used along with it.
Keywords: Scrum, XP (Extreme Programming), methodology, Scrum,

software, BTD system.
Lista de ilustrações
Figura 1 - Diagrama do processo de desenvolvimento de software utilizando
Scrum e XP.....................................................................................................5
Lista de tabelas
Tabela 1 Referências do capítulo Visão........................................................17
Tabela 2 Resumo dos usuários.....................................................................18
Lista de Abreviaturas e Siglas
XP – “Extreme Programming”
TI – Tecnologia da Informação
BPM – “Business Process Management”
RUP – “Rational Unified Process”
LHS – Limite de Horas da Sprint.
PMBOK – “Project Management Body of Knowledge”

Sumário
1 Introdução...................................................................................................1
2 Modelagem de Negócio...............................................................................3
2.1 Diagrama do processo .........................................................................5
2.1.1 Demanda de desenvolvimento recebida.........................................6
2.1.2 Listar requisitos (Product Backlog)..................................................6
2.1.3 Listar impedimentos dos requisitos (Impediment Backlog).............7
2.1.4 Estimar prazo para itens da lista de requisitos (Product Backlog). .7
2.1.5 Priorizar lista de requisitos (Product Backlog).................................8
2.1.6 Lista de requisitos levantada, priorizada e estimada (Product
Backlog)...................................................................................................8
2.1.7 Fim dos itens do Product Backlog?..................................................8
2.1.8 Realizar planejamento do desenvolvimento (Sprint Planning
Meeting)...................................................................................................9
2.1.9 Detalhar atividades de cada item da Sprint....................................9
2.1.10 Calcular o Tamanho da Sprint.....................................................10
2.1.11 Executar e Controlar a Sprint......................................................10
2.1.12 Realizar reunião de revisão.........................................................11
2.1.13 Realizar testes finais...................................................................12
2.1.14 Erros encontrados?.....................................................................12
2.1.15 Aceite final do produto................................................................12
2.2 Participantes.......................................................................................13
2.2.1 Proprietário do Produto (Product Owner) (Função).......................13
2.2.2 Líder da Equipe de Desenvolvimento (Scrum Master) (Função)....14
2.2.3 Equipe de Desenvolvimento (Team) (Função)..............................16
3 Visão.........................................................................................................17
3.1 Referências.........................................................................................17
3.2 Posicionamento...................................................................................18
3.2.1 Descrição do problema.................................................................18
3.2.2 Sentença de posição do produto ..................................................18
3.2.3 Resumo dos usuários....................................................................18
3.2.4 Ambiente do usuário.....................................................................20
4 Casos de Uso.............................................................................................22
4.1 Caso de Uso Cadastrar Equipes de desenvolvimento
..................................................................................................................22
4.1.1 Breve Descrição ...........................................................................22
4.1.2 Fluxo de Eventos ..........................................................................22
4.1.3 Condições Prévias ........................................................................23
4.2 Caso de Uso Cadastrar Product Backlog
..................................................................................................................24
4.2.1 Breve Descrição ...........................................................................24
4.2.2 Fluxo de Eventos .........................................................................24
4.2.3 Requisitos Especiais .....................................................................25
4.3 Caso de Uso Cadastrar Usuário
..................................................................................................................26
4.3.1 Breve Descrição ...........................................................................26
4.3.2 Fluxo de Eventos .........................................................................26
4.4 Caso de Uso Cadastrar Sprint
..................................................................................................................28
4.4.1 Breve Descrição ...........................................................................28
4.4.2 Fluxo de Eventos ..........................................................................28
4.5 Caso de Uso Cadastrar Histórico da Sprint..........................................30
4.5.1 Breve Descrição ...........................................................................30
4.5.2 Fluxo de Eventos ..........................................................................30
5 Bibliografia................................................................................................32
6 Anexos...................................................................................................... 33
6.1 Documento de Iniciação do Projeto - DIP ...................................33
6.2 Relatório de Progresso - REP...............................................................38
6.3 Registro de Lições Aprendidas - RLA...................................................42
6.4 Enunciado do Escopo do Projeto - ENE................................................44
6.5 Formulário de Solicitação de Mudança – FSM - nº xxxx.......................48
6.6 Formulário de Levantamento de Processo - FLP..................................51
1
1 Introdução
Este trabalho contém todos os documentos e metodologias utilizadas na

construção do Sistema “Scrum BTD” e as adaptações e customizações de algumas,
necessárias para a boa utilização do sistema.
Segundo o seu autor, Ken Shwaber (SCHWABER, 2004), o Scrum não é um

processo previsível, ele não define o que fazer em toda circunstância. Ele é usado em
trabalhos complexos nos quais não é possível prever tudo o que irá ocorrer e oferece
um framework e um conjunto de práticas que torna tudo visível. Isso permite aos
praticantes do Scrum saber exatamente o que está acontecendo ao longo do projeto e
fazer os devidos ajustes para manter o projeto se movendo ao longo do tempo visando
alcançar os seus objetivos.
Segundo a Wikipédia (2010), Programação Extrema (do inglês eXtreme

Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas a
médias e que irão desenvolver software com requisitos vagos e em constante
mudança. Para isso, adota a estratégia de constante acompanhamento e realização de
vários pequenos ajustes durante o desenvolvimento de software.
Os quatro valores fundamentais da metodologia XP são: comunicação,

simplicidade, feedback e coragem. A partir desses valores, possui como princípios
básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar
mudanças e trabalho de qualidade.
Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo),

há um foco explícito em escopo. Para isso, recomenda-se a priorização de
funcionalidades que representem maior valor possível para o negócio. Desta forma,
caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão
adiadas ou canceladas.
A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno

ganho de curto prazo na produtividade, ao diminuir qualidade, não é compensado por
perdas (ou até impedimentos) a médio e longo prazo.
Segundo a Wikipédia (2010), o Guia PMBOK é o guia que identifica um

subconjunto de conhecimentos em gerenciamento de projetos, que é amplamente
reconhecido como boa prática, sendo em razão disso, utilizado como base pelo Project
Management Institute (PMI). Uma boa conduta não significa que o conhecimento e as
práticas devem ser aplicadas uniformemente a todos os projetos, sem considerar se
são, ou não, apropriados.
A parte de gerenciamento do projeto deve seguir uma documentação mínima

para manter o projeto gerenciável sem sacrificar a agilidade do desenvolvimento.
Seguindo algumas práticas do Guia PMBOK, recomendamos que todas as demandas
sejam iniciadas somente depois da assinatura do DIP – Documento de Iniciação de
Projeto (Modelo nos anexos), após sua assinatura o preencher o ENE – Enunciado de
Escopo (modelo em anexo). Qualquer alteração no escopo, um formulário de
2
solicitação de mudanças deverá ser preenchido e assinado pelos envolvidos (modelo

em anexo) dentre outros formulários.
A junção e customização destas metodologias possibilitam o desenvolvimento

de sistemas de forma ágil com uma documentação mínima e com um controle do
projeto por parte de seus gerentes.
3
2 Modelagem de Negócio
Antes de se desenvolver qualquer sistema, há de se mapear seus processos de

negócio e proceder às devidas melhorias do mesmo para não se correr o risco de
automatizar um processo de negócio falho ou desalinhado com as estratégias da
organização. Neste trabalho iremos apresentar o mapeamento de processo, validado
pelo cliente, para automação do processo de desenvolvimento de software, o qual foi
denominado de “Scrum BTD” usando a notação BPM. Qualquer notação pode ser
unitizada, deis de que o processo tenha sua representação gráfica.
A automação de um processo de negócio falho gera um sistema falho e

consequentemente ineficaz. Sistemas de informações devem estar alinhados aos
processos que por sua vez devem estar alinhados a estratégia das organizações. Por
esta razão decidimos utilizar a notação BPM para mapear os processos pertinentes ao
sistema em questão. Sugerimos a adoção do formulário de levantamento de processos
(modelo anexo) para facilitar esta etapa.
Segundo a Wikipédia (2010), o Gerenciamento de Processos de Negócio

(português brasileiro) ou Gestão de Processos de Negócio (português europeu) (em
inglês Business Process Management ou BPM) é um conceito que une gestão de
negócios e tecnologia da informação com foco na otimização dos resultados das
organizações através da melhoria dos processos de negócio. São utilizados métodos,
técnicas e ferramentas para analisar, modelar, publicar, otimizar e controlar processos
envolvendo recursos humanos, aplicações, documentos e outras fontes de informação.
O Business Process Management (BPM), ou Gerenciamento de Processos de

Negócios, tem como objetivo prover o alinhamento dos processos de negócios com a
estratégia (os processos são a execução da estratégia), os objetivos e a cadeia de
valor das organizações.
O Gerenciamento de Processos de Negócios utiliza as melhores práticas de

gestão, tais como: o mapeamento dos processos, a modelagem, a definição do nível
de maturidade, a documentação, o plano de comunicação, a automação, o
monitoramento através de indicadores de desempenho e o ciclo de melhoria contínua.
O objetivo é a melhoria contínua dos processos para se atingir os resultados
esperados.
Essas práticas aplicadas ajudam a maximizar os resultados e o desempenho dos

processos, e assim fazer com que as organizações tenham melhores resultados
financeiros, vantagem competitiva, redução de custos, otimização de recursos,
aumento da satisfação dos clientes através de produtos e serviços com um nível
superior de qualidade.
Por este motivo, recomendamos que antes que se inicie a construção do novo
sistema aja a modelagem de negócio e a construção de um diagrama do processo. O
processo abaixo já está modelado e pode ser considerado um resultado final de uma
modelagem que é um ciclo com três fases distintas (Situação Atual- “As Is” onde se
tirar uma “fotografia” do processo e o mapeia, tal como ele está, diagnóstico onde se
4
analisa criticamente o processo e se propõe melhorias, e a Situação Futura – “To Be”

onde se redesenha o processo visando sua melhoria e implementa-se o desenho). O
sistema “Scrum BTD” não gerência a modelagem do processo. Esta fase é
considerada predecessora do inicio da demanda.
5
2.1Diagrama do processo
Figura 1 - Diagrama do processo de desenvolvimento de software utilizando Scrum e XP

6
O diagrama acima (Figura 1) é uma representação gráfica do processo de

negócio “desenvolvimento de software utilizando-se Scrum e XP” customizada e
adaptada para o software “Scrum BTD”. Para um melhor entendimento o mesmo foi
dividido em duas fases, o de Levantamento de Requisitos (Product Backlogs) e o de
Desenvolvimento (Sprint). Cada atividade do fluxo será detalhada nesta parte do
trabalho. (KNIBERG, 2007) e (PEREIRA & PAULA TORREÃO, 2007) com adaptações.
2.1.1 Demanda de desenvolvimento recebida

Descrição
O processo inicia com o recebimento de uma demanda de desenvolvimento de
software. O “Proprietário do Produto (Product Owner)” demanda o desenvolvimento de
um produto para o “Líder da Equipe de Desenvolvimento (Scrum Master)”.
Recomendamos que uma prévia modelagem do processo de negócio ao qual a

demanda vai automatizar seja realizada. Não modelar o processo de negócio não
impede prosseguir com a demanda, mas esta é fortemente recomendada pelos
motivos expostos no início deste capítulo.
2.1.2 Listar requisitos (Product Backlog)

Descrição
O Proprietário do Produto (Product Owner) deverá fazer um levantamento de
tudo o que deseja desenvolver utilizando a terminologia do cliente, produzindo uma
lista de requisitos, ou "Product Backlog", que contém todos os itens que precisam ser
realizados, que possam ser associados com valor de negócio e para a finalização do
projeto, sejam eles requisitos funcionais ou não.
É importante ressaltar que cada item no Backlog do produto deve ter um valor
de negócio associado (Business Value), onde podemos medir o retorno do projeto e
priorizar a realização dos itens. A lista de requisitos ou "Product Backlog" não precisa
estar completa no início de um projeto. Pode-se começar com tudo aquilo que é mais
óbvio em um primeiro momento. Com o tempo, o “Product Backlog” cresce e muda à
medida que se aprende mais sobre o produto e seus usuários.
Se o Proprietário do Produto (Product Owner) tem uma formação técnica, ele

pode listar algo como “Adicionar índice na tabela de eventos”. Neste caso o “Líder da
Equipe de Desenvolvimento (Scrum Master)” pode auxiliar fazendo a seguinte
pergunta: Mas por quê? A idéia é encontrar o objetivo subjacente. Então se reformula o
item nos termos já citados (“acelerar o formulário de pesquisa de eventos no back
office”). A descrição técnica original acaba virando uma nota (“Indexar a tabela de
eventos poderia resolver isso”). O Proprietário do Produto (Product Owner) deve focar-
se nos objetivos de negócio, objetivos estes que devem estar descritos utilizando-se a
terminologia do cliente.
Executantes
Proprietário do Produto (Product Owner).
Insumos
7
Demanda de desenvolvimento recebida.
Produtos
Lista de requisitos inicial ou "Product Backlog".
2.1.3 Listar impedimentos dos requisitos (Impediment

Backlog)
Descrição
O Impediment Backlog contém todos os itens que impedem o progresso do
projeto e geralmente estão associados a riscos. Estes itens não possuem uma
priorização, mas estão geralmente associados a algum item de Backlog do produto ou
a tarefas do item, por exemplo, “instalar ambiente para desenvolvedores”, “Instalação
de banco de dados do projeto”, etc. O controle desses itens é muito importante e o
Scrum Master é o grande responsável pela liberação desses impedimentos, abrindo
caminho para o time de desenvolvimento executar a realização dos itens do Backlog
do produto.
Executantes
Líder da equipe de desenvolvimento (Scrum Master).
Insumos
Lista de requisitos (Product Backlog).
Produtos
Lista de impedimentos ao desenvolvimento dos requisitos (Impediment
Backlog).
2.1.4 Estimar prazo para itens da lista de requisitos

(Product Backlog)
Descrição
O Líder da equipe de desenvolvimento (Scrum Master) juntamente com a Equipe
de Desenvolvimento (Team) devem estimar o tempo necessário para implementar
cada item da lista. A unidade é pontos por item e geralmente corresponde a mais ou
menos a “relação homem/dias” ideal. Exemplo: “três pessoas trancadas em uma sala
levaram aproximadamente 4 dias” então a estimativa inicial é de 12 pontos para o
item (ou seja, 3 x 4 = 12). O importante não é ter estimativas absolutamente precisas
(por exemplo, dizer que um item com dois pontos deverá gastar dois dias), mas sim
obter estimativas relativas corretas (por exemplo, dizer que um item com dois pontos
gastará cerca da metade de um item com quatro pontos).
Executantes
Líder da equipe de desenvolvimento (Scrum Master) e Equipe de
Desenvolvimento (Team).
Insumos
8
Lista priorizada de requisitos (Product Backlog).
Produtos
Lista priorizada e estimada de requisitos (Product Backlog).
2.1.5 Priorizar lista de requisitos (Product Backlog)

Descrição
Uma vez de posse da lista de requisitos (Product Backlog), deve-se priorizar
cada item. O Proprietário do Produto (Product Owner) deve atribuir uma pontuação de
importância para cada item da Lista de Requisitos (Product Backlog). Por exemplo, 10
ou 150. Maior pontuação é igual a mais importante. Esta nota deve ser única, não se
pode ter dois itens com a mesma nota de importância dentro da lista. Deve-se evitar o
termo “prioridade” já que 1 é tipicamente interpretado como prioridade mais alta”, o
que dificulta a mudança de número caso a se decida que algo é ainda mais
importante.
Executantes
Proprietário do Produto (Product Owner).
Insumos
Lista de Requisitos (Product Backlog).
Produtos
Lista priorizada de requisitos (Product Backlog).
2.1.6 Lista de requisitos levantada, priorizada e estimada

(Product Backlog)
Neste ponto a lista de requisitos está levantada, estimada e priorizada, dar-se-á
inicio as Sprint’s.
2.1.7 Fim dos itens do Product Backlog?

Descrição
Este é um loop para a realização das Sprint’s ele vai se repetir até o fim da
“Lista priorizada e estimada de requisitos (Product Backlog)”.
Caminhos possíveis:
Não
O fluxos do processo segue para reuniões de planejamento do desenvolvimento

ou “Sprint Planning Meeting”.
Sim
9
O fluxo do processo segue para a realização testes finais para se certificar a

qualidade do produto.
2.1.8 Realizar planejamento do desenvolvimento (Sprint

Planning Meeting)
Descrição
O objetivo da reunião é priorizar os itens que serão executados na Sprint, além
de dar ao time informação suficiente para que o mesmo possa validar e estimar o
esforço em horas para cada item. Vale lembrar que esta reunião é muito crítica para o
sucesso do projeto e que uma reunião mal planejada pode afetar e muito o andamento
da Sprint e causar danos grandes ao prazo do projeto. Com o Product Backlog
priorizado o time seleciona os itens que acham possíveis de serem executados durante
a Sprint. As dúvidas do time são esclarecidas e ao final temos então o Sprint Backlog,
que são os itens do Backlog priorizados para a Sprint.
Executantes
Líder da Equipe de Desenvolvimento (Scrum Master), Equipe de
Desenvolvimento (Team) e Proprietário do Produto (Product Owner).
Insumos
Lista priorizada e estimada de requisitos (Product Backlog).
Produtos
Itens do Backlog priorizados para a Sprint (Sprint Backlog).
2.1.9 Detalhar atividades de cada item da Sprint

Descrição
Para cada item, o time inicia o detalhamento de suas atividades, estimando em
horas, a duração de cada uma delas. Não é mandatório, mas é sugerido que cada
tarefa não ultrapasse a duração de 16h, se for necessário, deve-se quebrar a tarefa até
que individualmente todas as tarefas estejam dentro do limite de 16h. Uma vez que
todas as tarefas foram estimativas, o time questiona se realmente consegue assumir o
compromisso de realizar a tarefas dentro da Sprint e finalizar o item selecionado. Uma
vez decidido o item, o time passa para o próximo e esse processo continua até que
todos os itens do Sprint Backlog sejam validados. Nesse momento não são alocados os
recursos para as tarefas; apenas se estabelece as estimativas em horas para cada
uma. Após a estimativa refinada, pode-se calcular o total de horas necessário para
realizar todas as tarefas. É importante deixar sempre uma folga, já que mesmo
detalhando a estimativa sempre podem aparecer surpresas.
Executantes
Equipe de Desenvolvimento (Team) e Líder da Equipe de Desenvolvimento
(Scrum Master).
10
2.1.10 Calcular o Tamanho da Sprint

Descrição
É importante lembrar que a Sprint possui um limite de horas disponível. Este
limite é conhecido por LHS (Limite de Horas da Sprint). O LHS pode ser medido
utilizando uma fórmula simples: LHS = (R x H) x D, Onde: R = Total de recursos do
time, H = Total de horas disponível para cada recurso e D = Total de dias úteis da
Sprint.
Note que se você tiver o H variando para alguns recursos, é importante

considerar isso na fórmula. A relação de 01 homem/dia efetivo = 06 homens/hora
efetivas é mais real dependendo do tipo do projeto. Isso significa que se devem
considerar apenas seis horas efetivas de cada recurso das oito normalmente
trabalhadas, apenas 75% do tempo real do recurso é considerado produtivo para a
Sprint. Esta sobra é importante, pois fornece uma ideia mais realista da produtividade
de cada recurso e também garante uma margem de segurança para eventuais
imprevistos.
Com a simulação a seguir pode-se entender melhor como calcular o LHS: Para
uma Sprint com time-box padronizado em cinco dias e um time que possui cinco
recursos, onde três são de 8hs, um de 6hs e outro de 8hs, mas alocado apenas por
50% de seu tempo, temos o LHS diário, considerando a relação acima sugerida de: 8h
x 75% = 6h (3) 6h x 75% = 4,5h (1) 8h x 50% = 4h x 75% = 3h (1) Dias úteis da Sprint
= 5, logo, ((3x6) + (4,5) + (3)) = 31,50 (dia) LHS = 5 x 31,50 = 157,50.
Estes são cálculos bem simples e você vai precisar usá-los apenas antes de cada
planejamento da Sprint, pois o LHS é que vai indicar se você está alocando as horas
corretas para o seu time. É importante salientar que uma vez estabelecido a duração
da Sprint não se deve alterar sua data final, pois todo o projeto é guiado por essa
duração. Logo, adiantar ou atrasar não é interessante para ninguém.
Outro motivo importante para se manter o padrão de duração da Sprint é a

relação de produtividade do time dentro da Sprint. A métrica de esforço (velocity) para
o grupo de Itens que foram priorizados na Sprint é que vai dizer se conseguimos medir
para um mesmo time-box, o total de itens que foram finalizados por Sprint, e isso
comparado a um histórico. Esta métrica é muito importante, e apenas será real se as
Sprints forem de tamanhos iguais.
Executantes
Líder da Equipe de Desenvolvimento (Scrum Master).
2.1.11 Executar e Controlar a Sprint

Descrição
Durante a Sprint, o time, de forma organizada, controla como as tarefas devem
ser executadas. Durante a Sprint, a Equipe de Desenvolvimento não deve sofrer
interferência externa, esse é um dos principais papéis do Scrum Master, blindar o time
de qualquer desvio do objetivo traçado. O acompanhamento do progresso é feito
realizando reuniões diárias (Daily Meeting). Essas reuniões devem ser rápidas, não
mais que 15 minutos e objetivas. Todos participam, o Scrum Master e o time.
11
Visitantes são bem vindos, mas devem ser apenas ouvintes, pois o Daily Meeting
resume-se ao time.
No Daily Meeting a equipe trabalha apenas três perguntas, que são respondidas
por cada membro: 1) O que foi feito desde ontem? 2) O que você planeja fazer para
amanhã? 3) Você tem algum impedimento? Todo e qualquer problema encontrado
durante o Daily Meeting deve ser tratado em uma outra reunião, apenas com os
envolvidos.
Durante a execução da Sprint, a alocação de recursos para cada tarefa é dirigida

pelo próprio time, cada membro da equipe seleciona as tarefas que podem realizar e o
time estabelece a ordem e dependência entre elas. Um fator importante de sucesso
para o time com o uso do Scrum é o controle da disciplina. O time é considerado auto-
gerenciável e deve responder como tal. Para isto todos os membros do time devem
reportar as horas utilizadas em tarefas para que o valor de horas restantes seja
calculado corretamente e o time possa verificar o seu progresso.
Para esse acompanhamento o time usa um gráfico chamado de Sprint

Burndown. O Sprint Burndown exibe o progresso diário do time em função do total de
horas estabelecido pela soma de horas das tarefas dos itens do Product Backlog
selecionados. O Burndown é um gráfico muito simples que indica o consumo de horas
diárias. O eixo X indica a escala de horas totalizando o valor de horas estimado para a
Sprint, e o eixo Y os dias que representam o tamanho da Sprint de acordo com seu
time-box.
O time também possui um “quadro de trabalho” onde organiza as atividades,

dos itens de Backlog da Sprint, separando-as em basicamente em quatro estados: Para
fazer, Em andamento (inclui o nome do responsável por executar a tarefa), Para
Verificar e Concluído. Esse “quadro” é muito produtivo, pois basta olhar para ele para
realizar a leitura do progresso da Sprint, inclusive nele pode-se indicar se existe algum
impedimento para que as atividades sejam executadas conforme planejado.
Executantes
Líder da Equipe de Desenvolvimento (Scrum Master) e Equipe de
Desenvolvimento (Team).
2.1.12 Realizar reunião de revisão

Descrição
Ao final de cada Sprint, acontece a reunião de revisão. Nela o time entrega o
produto testado e revisado realizando uma demonstração prática. Este é o momento
do Product Owner inspecionar o produto final e verificar se o mesmo está como foi
pensando.
Após esta reunião, a reunião de retrospectiva é realizada, podendo ser chamada

também de “lições aprendidas”. Nesta, o time levanta tudo de bom e ruim que ocorreu
e procura estabelecer pontos de melhoria. Estas ações são levadas para a próxima
Sprint melhorando o processo e/ou produto. O ciclo do Scrum é repetido até que todos
12
os itens do Product Backlog tenham sido finalizados, atendidos e/ou o produto final
tenha sido aceito pelo cliente.
2.1.13 Realizar testes finais

Descrição
É nessa hora que testadores dedicados que não fazem parte da sua equipe
martelam o sistema com aqueles tipos de testes que a equipe Scrum não imaginou, ou
não teve tempo para fazer, ou não tiveram o hardware necessário para fazer. Estes
testadores acessam o sistema exatamente da mesma forma que os usuários finais, o
que significa que eles devem ser realizados manualmente (assumindo que seu sistema
seja feito para usuários humanos). Este é uma bateria de testes finais para pegar o
aceite final da demanda recebida.
Não confundir com os testes realizados dentro de cada ciclo de Sprint. Caso
sejam achados erros que comprometam a entrega do produto, outra Sprint deve ser
planejada para a correção de tais erros. Todos, incluindo o demandante, devem
participar dos testes.
Executantes
Proprietário do Produto (Product Owner), Líder da Equipe de Desenvolvimento
(Scrum Master) e Equipe de Desenvolvimento (Team).
2.1.14 Erros encontrados?

Descrição
Este é um loop no processo realizado até que todos os erros sejam corrigidos e o
produto aceito pelo demandante.
Caminhos possíveis
Não
Caso sejam encontrados erros que comprometa a entrega do produto, outra

Sprint deve ser planejada para a correção de tais erros. O fluxo do processo segue
para a atividade de planejamento da Sprint .
Sim
O fluxo do processo segue para se pegar o aceite final do demandante e o

termino da demanda.
2.1.15 Aceite final do produto.

Descrição
O demandante assina o aceite final da demanda.
13
2.2Participantes
Aqui são detalhados os papeis de cada ator dentro da modelagem do negócio.
2.2.1 Proprietário do Produto (Product Owner) (Função)
Segundo (EITCH), o Proprietário do Produto representa os interesses do cliente.

Ele tem que ser a interface entre o cliente e o time de desenvolvedores, ou seja, estar
sempre em contato com o cliente e saber exatamente o que o projeto tem que ser.
Ele tem as seguintes responsabilidades:
• Definir as características e conteúdos do produto;
• Decidir sobre a data de término;
• Ser responsável pela rentabilidade do produto;
• Priorizar as funções de acordo com o valor de mercado e com o cliente;
• Ajustar recursos e priorizar tarefas a cada 30 dias, como necessário; e
• Aceitar ou rejeitar o resultado do trabalho.
O trabalho mais árduo do Proprietário do Produto é definir o Product Backlog, um

dos dois artefatos do SCRUM.
• Também é conhecido por:
• Analista de Negócios;
• Analista de Sistemas; ou
• Em alguns casos pode ser o próprio Cliente.

14
2.2.2 Líder da Equipe de Desenvolvimento (Scrum

Master) (Função)
Segundo (EITCH) o Scrum Master é o líder da equipe de desenvolvimento e

durante o trabalho, fica mais em contato com o Proprietário do Produto. Ele gerencia e
repassa o trabalho que foi decidido durante o planejamento pelo Proprietário do
Produto.
Ele deve:
• Assegurar que a equipe de desenvolvimento funcione plenamente e seja

produtiva;
• Ajudar na cooperação entre todas as funções e papéis do time;
• Remover barreiras;
• Proteger a equipe de interferências externas;
• Assegurar-se de que a metodologia está sendo seguida, incluindo

chamadas para reuniões diárias (Daily Scrum Meetings), revisões de
atividade (Sprint Reviews) e reuniões de planejamento das atividades
(Sprint Planning).
Devido a todas estas responsabilidades, o Scrum Master é o que podemos

chamar de Coordenador do Projeto. Ele facilita a comunicação entre as pessoas e faz o
projeto andar de verdade.
Além de comandar as reuniões diárias, o Scrum Master tem três principais

responsabilidades:
1. Precisa saber quais atividades foram concluídas, quais foram iniciadas,

quaisquer novas tarefas que foram descobertas e qualquer estimativa que
possa ter mudado. Isto permite a ele atualizar sempre o Burndown Chart,
que mostra quanto trabalho falta para um Sprint acabar, dia por dia. Ele
também tem de estar sempre atento ao número de tarefas em aberto.
Esses trabalhos em aberto devem ser minimizados o mais rápido e o
máximo possível para garantir um trabalho sempre limpo e eficiente.
2. Deve avaliar as dependências superficiais e bloqueios que causam

prejuízos ao andamento do Projeto. Esses itens devem receber
prioridades e serem acompanhados. Um plano de solução deve ser
implementado, de acordo com a ordem de prioridade destes
impedimentos. Alguns podem ser resolvidos pelo time, outros podem ser
resolvidos através de vários times, e outros podem precisar de
envolvimento da gerência, pois podem ser problemas relacionados à
empresa que bloqueiam qualquer membro do time a fazer qualquer coisa.
Como exemplo deste tipo de impedimento externo, temos as questões
judiciais.
15
3. O Scrum Master deve perceber e resolver problemas pessoais ou conflitos

entre os integrantes da Equipe de Desenvolvimento. Este tipo de
problema deve ser clarificado pelo Scrum Master e resolvido por diálogo
com o time, ou então o Scrum Master terá que ter ajuda da gerência ou
do departamento de Recursos Humanos. Alguns estudos apontam que
50% dos problemas de desenvolvimento acontecem por razões pessoais.
O Scrum Master precisa estar sempre atento ao time para fazer com que
sejam totalmente funcionais e produtivos.
Também é conhecido por:
• Gerente de Projetos; ou
• Coordenador de Projetos.
16
2.2.3 Equipe de Desenvolvimento (Team) (Função)
Segundo (ALBINO) a equipe de desenvolvimento é quem vai colocar a mão na

massa para que o software comece a ter cara e funcionamento. Pode haver uma ou
mais equipes de desenvolvimento, dependendo da complexidade do software.
Algumas características das equipes de desenvolvimento:
• São pequenas e multidisciplinares, com em média 7 participantes;
• Definem as metas de cada Sprint, junto ao Scrum Master, e especificam

seus resultados de trabalho;
• Têm o direito de fazer tudo dentro dos limites das diretrizes do projeto
para atingir a meta de cada Sprint;
• Organizam os trabalhos para atingir os objetivos dos Sprints; e
• Trabalham para atingir todos os resultados definidos pelo Proprietário do

Produto.
Composta normalmente por:
• Designers;
• Desenvolvedores;
• Arquitetos de Informação; e
• Arquitetos de Sistema.
17
3 Visão
Nesta parte iremos definir, expor e analisar as necessidades e recursos de nível
superior do sistema “Scrum BTD”. Aqui iremos nos concentrar nos recursos
necessários aos envolvidos e aos usuários-alvo e nas razões que levam a essas
necessidades. Os detalhes de como o “Sistema Scrum BTD” satisfazem estas
necessidades são descritos no caso de uso. ( Rational Software Corporation (RUP),
1987 - 2001).
Para o sistema “Scrum BTD”, o documento de visão será elaborado juntamente

com o DIP – Documento de Iniciação de Projeto, pois o mesmo ajudará a “vender” e
“entender” o produto.
3.1Referências
Todos os documentos mencionados neste capitulo estão relacionados abaixo.
Tabela 1 Referências do capítulo Visão
N Titulo Data Fonte Descrição

º
1.
2.
18
3.2Posicionamento
3.2.1 Descrição do problema
Gerenciar o desenvolvimento em uma fabrica de software de forma ágil e
incremental, com uma documentação mínima do software e do gerenciamento do
projeto. O cliente deve visualizar facilmente o andamento do projeto, o gerente deve
ter o controle do projeto e a equipe de desenvolvimento do software deve ter o
controle da distribuição das tarefas dando informações que possibilitem um melhor
planejamento do desenvolvimento.
O “Scrum BTD” aliando boas práticas de desenvolvimento ágil com Scrum e XP a

boas práticas de processos de desenvolvimento de software como RUP e gerencia de
projeto com o Guia PMBOK sem sacrificar a agilidade do desenvolvimento, pretende
gerenciar uma fabrica de software solucionando os problemas listados.
3.2.2 Sentença de posição do produto

O “Scrum BTD” foi concebido para fábricas de softwares que queiram
desenvolver softwares de forma ágil e incremental mantendo uma documentação
mínima do software e do projeto. O “Scrum BTD” é um sistema que gerencia o
desenvolvimento dando algumas informações vitais para o gerente da equipe como,
por exemplo, a velocidade de desenvolvimento da equipe em tempo real. Além de
mostrar de forma clara para o cliente o desenvolvimento de sua demanda.
Hoje, no mercado, os softwares oferecidos não levam em consideração as boas

práticas das áreas abordadas pelo “Scrum BTD” como, por exemplo, a gerência de
projetos, mapeamento de processos, práticas de desenvolvimento ágil como Srum e
XP e documentação customizada RUP em um único sistema.
3.2.3 Resumo dos usuários
Tabela 2 Resumo dos usuários
Nome Descrição Responsabilidades Envolvimento

Proprietário do O Proprietário do • Definir as características e O trabalho mais
Produto Produto conteúdo do produto; árduo do
(Product representa os • Decidir sobre a data de Proprietário do
Owner) interesses do término; Produto é definir o
cliente. Ele deve • Ser responsável pela Product Backlog.
ser a interface rentabilidade do produto; Tem acesso ao
entre o cliente e o • Priorizar as funções de quadro de
time de acordo com o valor de andamento das
desenvolvedores, mercado e com o cliente; atividades apenas.
ou seja, estar
• Ajustar recursos e priorizar
sempre em
tarefas a cada 30 dias,
contato com o
como necessário; e
cliente e saber
• Aceitar ou rejeitar o
exatamente o que
resultado do trabalho.
o projeto tem que
ser.
Líder da equipe Scrum Master é o • Assegurar que a equipe de Devido a todas
19
de líder da equipe de desenvolvimento funcione estas

desenvolvimen desenvolvimento plenamente e seja produtiva; responsabilidades,
to (Scrum e durante o • Ajudar na cooperação entre o Scrum Master é o
Master) trabalho, fica mais todas as funções e papéis do que podemos
em contato com o time; chamar de
Proprietário do • Remover barreiras; Coordenador do
Produto. Ele • Proteger a equipe de Projeto. Ele facilita
gerencia e interferências externas; a comunicação
repassa o • Assegurar-se de que a entre as pessoas e
trabalho que foi metodologia está sendo faz o projeto andar
decidido durante seguida, incluindo chamadas de verdade. Tem
o planejamento para reuniões diárias (Daily acesso total e
pelo Proprietário Scrum Meetings), revisões de irrestrito ao
do Produto. atividade (Sprint Reviews) e sistema. A maioria
reuniões de planejamento dos cadastramentos
das atividades (Sprint serão efetuados por
Planning). ele.
• Precisa saber, quais
atividades foram concluídas,
quais foram iniciadas,
quaisquer novas tarefas que
foram descobertas e
qualquer estimativa que
possa ter mudado. Isto
permite que ele atualize o
Burndown Chart, que mostra
quanto trabalho falta para
um Sprint acabar, dia por
dia. Ele também tem de
estar sempre atento ao
número de tarefas em
aberto. Esses trabalhos em
aberto devem ser
minimizados o mais rápido e
o máximo possível para
garantir um trabalho sempre
limpo e eficiente.
• Deve avaliar as
dependências superficiais e
bloqueios que causam
prejuízos ao andamento do
Projeto. Estes itens devem
receber prioridades e serem
acompanhados. Um plano de
solução deve ser
implementado de acordo
com a ordem de prioridade
destes impedimentos. Alguns
podem ser resolvidos pelo
time, outros podem ser
resolvidos através de vários
times, e outros podem
precisar de envolvimento da
gerência, pois podem ser
problemas relacionados à
empresa, que bloqueiam
20
qualquer membro do time a

fazer qualquer coisa. Como
exemplo deste tipo de
impedimento externo, temos
as questões judiciais.
•O Scrum Master deve
perceber e resolver
problemas pessoais ou
conflitos entre os integrantes
do time de desenvolvimento
Scrum. Este tipo de problema
deve ser clarificado pelo
Scrum Master e resolvido por
diálogo com o time, ou então
o Scrum Master terá que ter
ajuda da gerência ou do
departamento de Recursos
Humanos. Alguns estudos
apontam que 50% dos
problemas de
desenvolvimento acontecem
por razões pessoais. O
Scrum Master precisa estar
sempre atento ao time para
fazer com que sejam
totalmente funcionais e
produtivos.
Equipe de A equipe de •Definem metas de cada Com as tarefas e

Desenvolvimen desenvolvimento Sprint, junto ao Scrum andamento das
to (Team) é quem vai Master, e especificam seus mesmas. Acesso ao
colocar a mão na resultados de trabalho; quadro de
massa para que o •Têm o direito de fazer tudo andamento e a
software comece dentro dos limites das atual velocidade da
a ter cara e diretrizes do projeto para equipe.
funcionamento. atingir a meta de cada Sprint;
Pode haver uma •Organizam os trabalhos para
ou mais equipes atingir os objetivos dos
de Sprints; e
desenvolvimentos •Trabalham para atingir todos
, dependendo da os resultados definidos pelo
complexidade do Proprietário do Produto.
software.
3.2.4 Ambiente do usuário
Os usuários do sistema serão todas as equipes envolvidas na fábrica de

softwares, incluindo o cliente, que deverá visualizar o andamento do desenvolvimento
por meio de um quadro contendo campos específicos. O sistema deverá ser
desenvolvido em plataforma JAVA com interface WEB e rodar em múltiplos sistemas
operacionais. Como terá uma interfase WEB, não poderá requerer muito do hardware e
nem da conexão, pois isso, sua interface necessariamente deverá ser limpa e clara.
21
O cliente passa a demanda para a fábrica, que cadastra a mesma no sistema e

separa em tarefas menores, estimando prazo de conclusão para o cliente. O cliente
tem acesso a um quadro que dá o andamento das atividades, em paralelo os
desenvolvedores têm o controle de histórico de cada tarefa cadastrada até o seu
termino em ciclos incrementais. O gerente da fábrica ou líder da equipe de
desenvolvimento tem acesso a todas as informações, incluindo dados da velocidade da
equipe de desenvolvimento.
22
4 Casos de Uso
Aqui listaremos e detalharemos todos os casos de uso utilizados no
desenvolvimento do sistema Scrum BTD.
4.1Caso de Uso Cadastrar Equipes de

desenvolvimento
4.1.1 Breve Descrição

Esse caso de uso permite que o Scrum Master (líder da equipe de
desenvolvimento do produto) mantenha informações sobre as Equipes/Usuário que
participarão do processo Scrum. Isso abrange a inclusão, a modificação e a exclusão
de equipes do processo sistema.
O agente desse caso de uso é o Scrum Master.
4.1.2 Fluxo de Eventos

O caso de uso inicia quando o Scrum Master seleciona a atividade "Cadastrar
Equipes" no formulário principal.
4.1.2.1Fluxo Básico - Cadastrar uma Equipe

1. O Scrum Master seleciona "Incluir uma Equipe".
2. O sistema exibe um formulário de cadastramento de equipes em
branco.
3. O Scrum Master digita as seguintes informações para o
cadastramento da equipe: ID, id_usuário, nome_usuário, status e
departamento.
4. O sistema valida os dados para assegurar o formato correto e
procura por uma Equipe/Usuário existente com o número ID
especificado. Se os dados forem válidos, o sistema criará uma nova
Equipe/Usuário e designará um número de ID exclusivo gerado pelo
sistema. Esse número é exibido, portanto pode ser utilizado para usos
subseqüentes do sistema.
5. As etapas 2 a 4 são repetidas para cada Equipe/Usuário incluído no
sistema. Quando o Scrum Master tiver concluído a inclusão das
Equipes/Usuário no sistema, o caso de uso será finalizado.
4.1.2.2Fluxos Alternativos
4.1.2.2.1 Modificar uma Equipe

1. O Scrum Master seleciona "Modificar uma Equipe".
2. O sistema exibe um formulário de Equipe com sua lida de Usuário
em branco.
3. O Scrum Master digita o número de ID da Equipe/Usuário que
deseja modificar
4. O sistema recupera as informações da Equipe/Usuário e as exibe na
tela
5. O Scrum Master modifica um ou mais campos de informações da
Equipe/Usuário: ID, id_usuário, nome_usuário, status e departamento.
Quando as alterações forem concluídas, o Ator seleciona "salvar".
23
6. O sistema atualiza as informações da Equipe/Usuário.

7. As etapas 2 a 7 são repetidas para cada Equipe/Usuário que o Ator
deseja modificar. Quando as edições forem concluídas, o caso de uso
termina.
4.1.2.2.2 Excluir uma Equipe

1. O Scrum Master seleciona "Excluir uma Equipe".
2. O sistema exibe um formulário de Equipe/Usuário em branco.
3. O Scrum Master digita o número de ID da Equipe/Usuário que está
sendo excluído.
4. O sistema recupera a Equipe/Usuário e exibe suas informações no
formulário.
5. O Scrum Master seleciona "excluir."
6. O sistema exibe um diálogo de verificação de exclusão confirmando
a exclusão.
7. O Scrum Master seleciona "sim."
8. A Equipe/Usuário é excluído do sistema.
9. As etapas 2 a 8 são repetidas para cada Equipe/Usuário que o ator
deseja modificar. Quando o Scrum Master tiver concluído a exclusão das
Equipes/Usuário do sistema, o caso de uso será finalizado.
4.1.2.2.3 Equipe/ Usuário Já Existe

Se no sub-fluxo "Incluir uma Equipe/Usuário", já existir uma Equipe/Usuário com
o número de id especificado, a mensagem de erro" usuário Já Existe" será exibida. O
Ator pode alterar o número, optar por criar outra Equipe/Usuário com o mesmo número
ou cancelar a operação, ponto no qual o caso de uso é finalizado.
4.1.2.2.4 Equipe/ Usuário Não Localizado

Se no sub-fluxo "Modificar uma Equipe/Usuário" ou "Excluir uma
Equipe/Usuário", não existir uma Equipe/Usuário com o número de ID especificado, o
sistema exibirá a mensagem de erro" usuário Não Localizado". Em seguida, o Scrum
Master pode digitar um número de ID diferente ou cancelar a operação, ponto no qual
o caso de uso é finalizado.
4.1.3 Condições Prévias

4.1.3.1 Login
Antes do início desse caso de uso, o Ator deve efetuar logon no sistema.
24
4.2Caso de Uso Cadastrar Product Backlog

desenvolvimento do produto) e/ou o Product Owner (quem define as características e
conteúdo do produto) cadastrem o Product Backlog contém uma lista de itens
priorizados que incluem tudo o que precisa ser realizado, que possa ser associado com
valor de negócio, para a finalização do projeto, sejam requisitos funcionais ou não.
Os agentes desse caso de uso são o Scrum Master e o Product Owner.
Perfis de usuários:
Product Owner -> Responsável por levantar os requisitos do produto. Negocia a

entrega com o time. Tem o respaldo de aceitar ou não os resultados do trabalho.
Scrum Master -> Orienta a equipe a trabalhar de forma auto-gerenciável.

Procura extrair o máximo da equipe a fim de melhorar a qualidade do produto.
Responsável por manter as boas práticas do Scrum e proteger a equipe de
interferências externas, resolvendo os impedimentos do projeto e mantendo a equipe
focada.
Equipe -> Responsáveis pela entrega dos requisitos testados. Um grupo

multidisciplinar, normalmente formado por Arquitetos de Informação,
Desenvolvedores, Designers, etc.

O caso de uso inicia quando o Scrum Master ou o Product Owner, doravante
denominados Ator, selecionam a atividade "Cadastrar Product Backlog" no formulário
principal.
4.2.2.1Fluxo Básico – Cadastrar Product Backlog

1. O Ator seleciona a opção "Criar novo Product Backlog".
2. O Ator fornece ao sistema o nome do Product Backlog.
3. O Ator seleciona a opção “Incluir Item”.
4. O sistema exibe um formulário de itens de Product Backlog em
branco.
5. O Ator digita as seguintes informações para o Product Backlog:
Nome, Importância, Estimativa Inicial e Notas.
6. O sistema valida os dados para assegurar o formato. Se os dados
forem válidos, o sistema criará um novo item e designará um número de
ID exclusivo gerado pelo sistema. Esse número é exibido, portanto pode
ser utilizado para usos subseqüentes do sistema.
7. O Ator seleciona o item “Salvar Item”.
8. As etapas 2 a 5 são repetidas para cada item de Product Backlog a
ser incluído no sistema. Quando o Ator tiver concluído a inclusão dos
Itens do Product Backlog no sistema, o caso de uso será finalizado.
25
4.2.2.2.1 Editar item de Product Backlog

1. O Ator seleciona "Editar Item".
2. O sistema exibe o formulário de itens de Product Backlog
selecionado para edição.
3. O Ator digita os dados que deseja alterar.
4. Quando as alterações forem concluídas, o Ator seleciona "Salvar
Item".
5. O sistema atualiza as informações do Product Backlog.
6. As etapas 1 a 5 são repetidas para cada item que o Ator desejar
modificar. Quando as edições forem concluídas, o caso de uso termina.
4.2.2.2.2 Product Backlog já existe

Se no sub-fluxo "Criar novo Product Backlog" já existir um Product Backlog com
o nome especificado, a mensagem de erro "Product Backlog já existe" será exibida. O
Ator pode alterar o nome ou cancelar a operação, ponto no qual o caso de uso é
finalizado.
4.2.2.2.3 Excluir item de Product Backlog

1. O Scrum Master seleciona "Excluir item de Product Backlog".
2. O sistema exibe o formulário de itens de Product Backlog.
3. O Scrum Master seleciona a opção “Excluir item”.
4. O sistema mostra a mensagem “Tem certeza que deseja excluir o
item selecionado?”.
5. O Scrum Master seleciona "Excluir".
excluir. Quando as exclusões forem concluídas, o caso de uso termina.
4.2.2.2.4 Excluir Product Backlog

1. O Scrum Master seleciona "Excluir Product Backlog".
2. O sistema exibe o formulário de Product Backlog’s cadastrados no
sistema.
3. O Scrum Master seleciona a opção “Excluir Product Backlog”.
Product Backlog?”.
5. O Scrum Master seleciona "Excluir".
7. As etapas 1 a 5 são repetidas para cada Product Backlog que o Ator
desejar excluir. Quando as exclusões forem concluídas, o caso de uso
termina.
4.2.3 Requisitos Especiais

Somente o Scrum Master pode Excluir o Item do Product Backlog ou o Product
Backlog.
4.1 Login
.
26
4.3Caso de Uso Cadastrar Usuário

desenvolvimento do produto) cadastre os usuários que farão parte das equipes que
participarão do processo Scrum. Isso abrange a inclusão, a modificação de usuários do
processo.
O agente desse caso de uso é o Scrum Master.
Product Owner -> Responsável por priorizar os requisitos de acordo com o valor
de cada um. Negocia a entrega com o time. Tem o respaldo de aceitar ou não os
resultados do trabalho.
Scrum Master -> Orienta o Team a trabalhar de forma auto-gerenciável. Procura

extrair o máximo do Team a fim de melhorar a qualidade do produto. Responsável por
manter as boas práticas do Scrum. É o protetor do Team, resolvendo os impedimentos
do projeto
Team -> Responsáveis pela entrega dos requisitos testados. Um grupo multi-
disciplinar. Arquitetos de informação, Desenvolvedores, Designers, etc.

O caso de uso inicia quando o Scrum Master seleciona a atividade "cadastrar
usuários" no formulário principal.
4.3.2.1Fluxo Básico – Cadastrar usuário

1. O Scrum Master seleciona "Incluir um Usuário".
2. O sistema exibe um formulário de usuário em branco.
3. O Scrum Master digita as seguintes informações para o usuário: Id,
nome, data nascimento, status, cargo, departamento.
4. O sistema valida os dados para assegurar o formato e procura por
um Usuário existente com o nome especificado. Se os dados forem
válidos, o sistema criará um novo cliente e designará um número de ID
exclusivo gerado pelo sistema. Esse número é exibido, portanto pode
5. As etapas 2 a 4 são repetidas para cada usuário incluído no
sistema. Quando o ator tiver concluído a inclusão de usuário no sistema,
o caso de uso será finalizado.
6. Product Owner, Scrum Master, Team, estes são os tipos de usuários
a serem cadastrados.
4.3.2.2.1 Modificar um Usuário

1. O Scrum Master seleciona "Modificar um usuário".
2. O sistema exibe um formulário de usuário em branco.
27
3. O Scrum Master digita o número de ID do usuário que deseja

modificar.
4. O sistema recupera as informações do usuário e as exibe na tela
5. O Scrum Master modifica um ou mais campos de informações do
usuário: nome, senha, status e cargo.
6. Quando as alterações forem concluídas, o ator seleciona "salvar."
7. O sistema atualiza as informações do usuário.
8. As etapas 2 a 7 são repetidas para cada usuário que o ator desejar
4.3.2.2.2 Usuário Já Existe

Se no sub-fluxo "Incluir um Usuário", já existir um usuário com o nome
especificado, a mensagem de erro "usuário Já Existe" será exibida. O Scrum Master
pode alterar o nome, optar por criar outro usuário com o mesmo nome ou cancelar a
operação, ponto no qual o caso de uso é finalizado.
4.3.2.2.3 Usuário Não Localizado

Se no sub-fluxo "Modificar um Usuário" ou "Excluir um Usuário", não existir um
usuário com o número de ID especificado, o sistema exibirá a mensagem de erro
"Usuário Não Localizado". Em seguida, o ator pode digitar um número de ID diferente
ou cancelar a operação, ponto no qual o caso de uso é finalizado.

4.3.3.1Login
28
4.4Caso de Uso Cadastrar Sprint

desenvolvimento do produto) e/ou o Product Owner (quem define as características e
conteúdo do produto) cadastrem o Sprint que são os itens da lista do Product
Backlog priorizados que incluem tudo o que precisa ser realizado, que possa ser
associado com valor de negócio, para a finalização do projeto, sejam requisitos
funcionais ou não.
O caso de uso inicia quando o Ator seleciona a atividade "Manter Sprint" no

formulário principal.
4.4.2.1 Fluxo Básico – Cadastrar Sprint

1. O Ator seleciona a opção "Criar novo Sprint".
2. O Ator fornece ao sistema o Nome do Sprint.
3. O Ator seleciona a opção “Incluir Item”.
4. O sistema exibe um formulário de itens de Sprint em branco.
5. O Ator digita as seguintes informações para o Sprint: número,
nome, Importância, Estimativa Inicial, Estimativa Término, Esforço e
Observações.
forem válidos, o sistema criará um novo item e designará um número de
ID exclusivo gerado pelo sistema. Esse número é exibido, portanto pode
7. O Ator seleciona o item “Salvar Item”.
8. As etapas 2 a 6 são repetidas para cada item do Sprint a ser
incluído no sistema.
9. Quando o Ator tiver concluído a inclusão dos Itens do Sprint no
sistema, deverá incluir o tempo e o esforço previsto para o Spirnt.
10. O Ator grava a operação e o caso de uso será finalizado.
4.4.2.2 Fluxos Alternativos
4.4.2.2.1 Editar item do Sprint

1. O Ator seleciona "Editar Item".
2. O sistema exibe o formulário com os itens de Sprint para edição.
3. O Ator seleciona o item desejado.
4. O sistema exibe um formulário na tela com o item selecionado
disponível para alterações.
Item".
7. O sistema atualiza as informações do Sprint.
29
4.4.2.2.2 Sprint já existe
Se no sub-fluxo "Criar novo Sprint" já existir um Sprint com o nome

especificado, a mensagem de erro "Sprint já existe" será exibida. O
Ator pode alterar o nome ou cancelar a operação, ponto no qual o
caso de uso é finalizado.
4.4.2.2.3 Excluir item de Sprint

1. O Ator seleciona "Excluir item de Sprint”.
2. O sistema exibe o formulário de itens de Sprint.
3. O Ator seleciona a opção “Excluir item”.
5. O Ator seleciona "Excluir".
4.4.2.2.4 Excluir Sprint

1. O Ator seleciona "Excluir Sprint".
2. O sistema exibe o formulário de Sprint cadastrados no sistema.
3. O Ator seleciona a opção “Excluir Sprint”.
Sprint?”.
7. As etapas 1 a 6 são repetidas para cada Sprint que o Ator desejar
Somente o Scrum Master pode Excluir o Item do Sprint ou o Sprint.

4.4.4.1 Login
30
4.5Caso de Uso Cadastrar Histórico da Sprint


desenvolvimento do produto) e/ou o Product Owner (quem define as
características e conteúdo do produto) cadastrem o histórico de uma Sprint, sejam
requisitos funcionais ou não.
Product Owner -> Responsável por levantar os requisitos do produto. Negocia a

entrega com o time. Tem o respaldo de aceitar ou não os resultados do trabalho.
Scrum Master -> Orienta a equipe a trabalhar de forma auto-gerenciável. Procura

extrair o máximo da equipe a fim de melhorar a qualidade do produto.
Responsável por manter as boas práticas do Scrum e proteger a equipe de
interferências externas, resolvendo os impedimentos do projeto e mantendo a
equipe focada.
Equipe -> Responsáveis pela entrega dos requisitos testados. Um grupo

multidisciplinar, normalmente formado por Arquitetos de Informação,
Desenvolvedores, Designers, etc.
O caso de uso inicia quando o Scrum Master ou o Product Owner, doravante

denominados Ator, selecionam a atividade "Cadastrar Histórico da Sprint" no
formulário principal.
4.5.2.1 Fluxo Básico – Manter Histórico da Sprint

1. O Ator seleciona a opção "Cadastrar Histórico na Sprint".
2. O Sistema exibe tela com Nome e o ID dos Product Backlog
cadastrados no sistema.
3. O Ator seleciona o Product Backlog desejado.
4. O Sistema então exibe novo formulário com as Sprint cadastradas
para o Product Backlog.
5. O Ator seleciona a Sprint onde deseja manter histórico.
6. O Ator seleciona a opção “Incluir Histórico”.
7. O sistema exibe um formulário branco para que seja cadastrado o
novo campo do histórico.
8. O Ator informa o novo histórico para a Sprint.
forem válidos, o sistema criará um novo campo de histórico.
10. O Ator seleciona o item “Salvar Histórico”.
11. As etapas 4 a 10 são repetidas para cada Sprint registrada para
aquele Product Backlog do sistema.
31
12. Quando o Ator tiver concluído o cadastramento do histórico para a

Sprint selecionada, ele seleciona “Salvar Histórico”.
13. O sistema retorna para a tela onde estão listadas as Sprint
pertencentes àquele Product Backlog, para a seleção de nova Sprint.
14. Junto com este formulário o sistema exibirá opções para encerrar a
operação de Manter Histórico ou voltar à tela para selecionar novo
Product Backlog.
15. Quando o Ator tiver concluído a inclusão dos históricos da Sprint
no sistema, o caso de uso será finalizado.
4.5.2.2 Fluxos Alternativos
4.5.2.2.1 Editar item de Histórico da Sprint

1. O Ator seleciona "Editar Histórico".
2. O sistema exibe o formulário de Sprint do Product Backlog
selecionado para edição.
histórico".
5. O sistema atualiza as informações da Sprint.
4.5.2.2.2 Excluir histórico da Sprint

1. O Ator seleciona "Excluir Histórico da Sprint".
2. O sistema exibe o formulário de itens da Sprint.
3. O Ator seleciona a opção “Excluir item”.
6. O sistema atualiza as informações da Sprint.
Somente o Scrum Master pode Excluir um histórico do Item do Product Backlog.

4.5.4.1 Login
32
5 Bibliografia
Rational Software Corporation (RUP). (1987 - 2001). RUP 2002.05.00 Portugues. Acesso
em 11 de Outubro de 2010, disponível em www.wthreex.com:
http://www.wthreex.com/rup/portugues/webtmpl/templates/req/rup_vision_sp.ht
m
(EITCH), H. C. (s.d.). Modelo de Desenvolvimento Ágil SCRUM. Acesso em 09 de

Outubro de 2010, disponível em Devin: http://www.devin.com.br/modelo-scrum/
ALBINO, R. D. (s.d.). Métodos Ágeis - SCRUM. Acesso em 09 de Outubro de 2010,

disponível em Scribd: http://www.scribd.com/doc/20947678/Metodos-Ageis-
SCRUM
KNIBERG, H. (2007). Scrum e XP direto das Trincheiras Como fazemos Scrum. EUA:
C4Media, Publisher of InfoQ.com.
PEREIRA, P., & PAULA TORREÃO, A. S. (2007). Entendendo Scrum para Gerenciar
Projetos de Forma Ágil. MundoPM.
SCHWABER, K. (2004). Agile Project Management with Scrum (Microsoft Professional) .

EUA - Washington: Microsoft Press.
Wikipédia. (08 de Outubro de 2010). Wikipédia - Gerenciamento de processos de

negócio. Acesso em 08 de Outubro de 2010, disponível em Wikipédia:
http://pt.wikipedia.org/wiki/Business_Process_Management
Wikipédia. (08 de Outubro de 2010). Wikipédia Programação Extrema. Acesso em 08

de Outubro de 2010, disponível em Wikipédia:
http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema
33
6 Anexos
6.1Documento de Iniciação do Projeto - DIP
IDENTIFICAÇÃO DO PROJETO
NOME DO PROJETO
ÁREA DEMANDANTE
ÁREA EXECUTORA
RESPONSÁVEL PELO
PROJETO
RESPONSÁVEL PELA
ELABORAÇÃO DO DIP
HISTÓRICO DAS ALTERAÇÕES DO DIP
DATA VERSÃO DESCRIÇÃO AUTOR/REVISOR
DOCUMENTOS REFERENCIADOS
Documento 1 Descrição sucinta do conteúdo do documento 1
Documento n Descrição sucinta do conteúdo do documento n
Os documentos referenciados tornam-se parte do Escopo do Projeto e devem ser mantidos na pasta em que
estiver este documento.
1. NECESSIDADE GERADORA DA DEMANDA

Descrever as justificativas que geraram a necessidade do projeto, especificando a conjuntura atual e a
descrição sucinta do problema que o projeto pretende solucionar, ou da oportunidade que deve ser
aproveitada. Esta descrição deve ser tão detalhada quanto seja necessário para convencer patrocinadores e
gestores a respeito da importância do projeto.
2. OBJETIVO GERAL
34
Descrever o que a área pretende alcançar, o que o projeto deve fazer para solucionar o problema
apresentado ou aproveitar a oportunidade levantada.
Usar verbos no infinitivo e descrever de forma clara e concisa.
3. OBJETIVOS ESPECÍFICOS
Os objetivos específicos do projeto são mais precisos e detalhados e devem manter a coerência com os
objetivos gerais. Compreende os demais objetivos que serão atingidos, decorrentes das atividades ou
ações desenvolvidas no projeto.
Usar verbos no infinitivo e descrever de forma clara e concisa.
4. ADERÊNCIA DO PROJETO À VISÃO ESTRATÉGICA DA ORGANIZAÇÃO

Os resultados a serem alcançados por este projeto estão vinculados ao seguinte recorte do mapa
“Mapa estratégico da organização” (caso não aja esta parte deve ser excluída):
Resultados para a
sociedade
Focos de atuação
Bases para o
desenvolvimento
externo
Bases de
desenvolvimento
interno
5. ESCOPO DO PROJETO - (Estrutura Analítica do Projeto – EAP)

A Estrutura Analítica do Projeto – EAP representa o nível mais geral do projeto, ou seja, apresenta um
primeiro esboço dos grupos de atividades que estarão presentes no projeto. Inserir a EAP.
Se necessário, incluir nesta seção um glossário resumido da EAP, permitindo que todos entendam
precisamente os produtos que serão esperados do projeto.
35
6. DURAÇÃO DO PROJETO
Descrever a duração estimada do projeto.
7. PREMISSAS
Descrever as premissas que devem orientar a realização do projeto. Premissas são suposições que
precisam ser consideradas verdadeiras (mesmo diante de um certo grau de incerteza) para que o projeto
possa ser planejado.
8. RESTRIÇÕES
Estabelecer os limites para o projeto que não poderão ser extrapolados. Restrições relacionadas ao
orçamento, a recursos, a tecnologias, etc.
9. ÁREAS IMPACTADAS
Identificar as pessoas que têm algum interesse no projeto (como aliadas ou opositoras), apontando a
natureza desse interesse. O objetivo é mapear as necessidades de fortalecimento de alianças e redução de
possíveis resistências à boa consecução do projeto.
Área Tipo de impacto

Área [ ] Impacto Positivo [ ] Impacto negativo
10. PERFIL DOS RECURSOS HUMANOS NECESSÁRIOS
Perfil QUANTIDADE
Perfil 1
...
Perfil n
11. RECURSOS MATERIAIS NECESSÁRIOS

ITEM QUANTIDADE
Recurso 1
...
Recurso n
12. ÁREAS ENVOLVIDAS
Identificar as áreas e nomes dos representantes das áreas que irão integrar o grupo gestor do projeto.
36
ÁREA NOME DO REPRESENTANTE TELEFONE E-MAIL

DA ÁREA
13. PAPÉIS E RESPONSABILIDADES
Identificar os papéis e as responsabilidades dos participantes do projeto (apagar isso aqui)
Papéis Responsabilidades
Principal interessado na realização do projeto (deverá ser um executivo com
Patrocinador
poderes suficientes para viabilizar a execução)
Gestor Técnico Responsável na área demandante pela execução do projeto
Gerente do Projeto Responsável pelo projeto
Responsável CGIG Responsável na CGIG pelo projeto
NOME DO
REPRESENTANTE DA ÁREA PAPEIS/RESPONSABILIDADES
ÁREA
14. DECISÃO SOBRE A REALIZAÇÃO DO PROJETO
[ ] ACEITAR [ ] REJEITAR [ ] COLOCAR EM ESPERA [ ] ESCLARECER
Brasília/DF, _____/______/______ Brasília/DF, _____/______/______
________________________________________ ________________________________________
Nome do Responsável pelo projeto no Coordenador Geral

Cliente/Demandante (patrocinador)
Área/Setor em que ele está lotado
________________________________________ ________________________________________
37
Gestor Técnico (Responsável pela Execução) Coordenador
________________________________________ ________________________________________
Responsável pelo projeto no Escritório de Gestão de Projeto

Escritório de Gestão de Projetos
38
6.2Relatório de Progresso - REP

Este documento é uma ferramenta usada durante todo o ciclo de vida do projeto para fornecer informações
sobre como o projeto está evoluindo. É vital para a co-gestão e patrocínio do projeto. A distribuição poderá
alcançar outros participantes do projeto e deve ser acompanhada por uma EAP que reflita os avanços do
projeto.
HISTÓRICO DE ALTERAÇÕES NO DOCUMENTO

Nome do Insira aqui o nome escolhido para o projeto e presente no Pré-
Projeto: projeto.
Preparado por: Nome do responsável pela preparação do Enunciado do Escopo

Alterações
Data Razão / Comentários / Responsável
Data de criação Nome do responsável pela criação do documento
Data da alteração1 Razão, comentários e responsável pela alteração 1
... ...
Data da alteração n Razão, comentários e responsável pela alteração n
CONTATOS
Nome Cargo/Função Telefone E-mail
1. PERÍODO ABRANGIDO PELO RELATÓRIO
De: ____/____/________ a ____/____/________
2. SUMÁRIO EXECUTIVO
Sob Requer
Crític
control cuidad RAZÕES PARA OS DESVIOS
o
e os
CRONOGRA
[ ] [ ] [ ]
MA
ESCOPO [ ] [ ] [ ]
QUALIDADE [ ] [ ] [ ]
Comentários
:
3. ÚLTIMO ANDAMENTO (POR MARCAR)

39
4. PENDÊNCIAS
5. AÇÕES PLANEJADAS PARA O PRÓXIMO PERÍODO

40
7. SITUAÇÃO DO CRONOGRAMA (PONTOS DE CONTROLE E PRODUTOS)
Apresente informações de acompanhamento dos pontos de controle e da entrega dos produtos do projeto.
Data de Data de
Razão para a Ações e
Ponto de Controle Produtos conclusão - conclusão -
variação resoluções
PREVISTA REALIZADA
8. IDENTIFICAÇÃO E TRATAMENTO DE PROBLEMAS

Nº Data Impact Problema Descrição Ação Responsáv Dt.Previs Situação
o el ta
3
41
À disposição para maiores informações.
___________________________________ ____________________________________
_____ ____

___________________________________ ____________________________________
_____ ____
Gestor Técnico (Responsável pelo Execução) Coordenador

Brasília/DF, _____/______/______
___________________________________
_____
Responsável pelo projeto no Escritório de Gestão

de Projetos
42
6.3Registro de Lições Aprendidas - RLA
Nome do
Insira aqui o nome escolhido para o projeto e presente no DIP.
Projeto:
Alterações
Data Razão / Comentários / Responsável
Data de criação Nome do responsável pela criação do documento
Data da alteração1 Razão, comentários e responsável pela alteração 1
... ...
Data da alteração n Razão, comentários e responsável pela alteração n
CONTATOS
Nome Cargo/Função Telefone E-mail
1. NOME DO PROJETO
O nome deve ser definido pelos Patrocinadores do projeto, ou pelo menos com a
participação destes. O intuito é aumentar o sentimento de propriedade deles com
relação ao projeto.
INSTRUÇÕES DE PREENCHIMENTO
Para cada bloco de comentário concluído, forneça as seguintes informações:
 Selecione a categoria
 Identifique a fase do projeto a que se refere a análise de lições aprendidas
 Identifique o processo em que se deu a percepção da lição aprendida
 Descreva o problema ou a ação bem-sucedida que deu origem ao registro
 Analise a causa do problema ou o elemento que ocasionou a ação bem-sucedida
 Apresente as recomendações de ação (se aplicável)
43
o Ações corretivas
o Ações preventivas
o Ações de melhoria
2. CATEGORIA
[ ] [ ] CLIENTE [ ] [ ] COMPONENTES DE
ORÇAMENTO COMUNICAÇÕES TI
[ ] ESCOPO
[ ] [ ] [ ] PLANO DE PROJETO
AQUISIÇÕES [ ] RISCOS CRONOGRAMA
[ ] RECURSOS [ ] OUTROS [ ] QUALIDADE
[ ]
TREINAMENTO
3. FASE DO PROJETO
[ ] [ ] [ ] [ ] [ ]
INICIAÇÃO PLANEJAMENTO EXECUÇÃO CONTROLE ENCERRAMENTO
4. TIPO DE EVENTO QUE DEU ORIGEM À LIÇÃO APRENDIDA
[ ] AÇÃO BEM- [ ] PROBLEMA [ ] OPORTUNIDADE DE

SUCEDIDA MELHORA
5. DESCRIÇÃO DA LIÇÃO APRENDIDA
Descreva aqui tão detalhadamente quando necessário para que a análise seja
realizada, a lição aprendida.
6. ANÁLISE
Descreva a forma pela qual se deu a análise e as conclusões a ela relacionadas.
7. RECOMENDAÇÕES
Apresente as recomendações de ação (se aplicável)
 Ações corretivas
 Ações preventivas
 Ações de melhoria.

44
___________________________________ ____________________________________
_____ ____

___________________________________ ____________________________________
_____ ____
Brasília/DF, _____/______/______
___________________________________
Responsável pelo projeto no

6.4Enunciado do Escopo do Projeto - ENE
Nome do Projeto: Insira aqui o nome escolhido para o projeto e presente no Pré-projeto.

45
Alterações
Código: Versão: versão
Data Versão Descrição Autor /

Revisor
Data Versão Descrição Autor
Observação: qualquer trabalho não incluído no Escopo do Projeto

é automaticamente considerado como estando fora do projeto.
1. DOCUMENTOS REFERENCIADOS
Documento
Breve descrição do conteúdo do documento 1
1(hyperlink)
… ...
Documento
Breve descrição do conteúdo do documento n
n(hyperlink)
Observação: todos os documentos aqui referenciados tornam-se parte do Escopo do Projeto e

devem ser mantidos na pasta em que estiver este documento e controlados continuamente.
2. SUMÁRIO EXECUTIVO
Informações gerais sobre o projeto baseadas no Pré-

Insira aqui um hiperlink
projeto e incluindo aspectos como propósito e
para o Pré-projeto
justificativas do projeto
Observação: se houver discrepâncias entre o Pré-projeto e o

Enunciado do Escopo, este último deverá ser considerado como correto.
4. DESCRIÇÃO DO PROJETO
4.1 INCLUI (RELAÇÃO DE Indicadores de conclusão Indicado res de Qualidade

SUBPRODUTOS) (critérios) (critérios)
Produto 1
...
Produto n
4.2 INCLUI (RELAÇÃO DE
SUBPRODUTOS)
Item 1
46
...
Item n
4.5 PREMISSAS DO PROJETO
Premissa 1
...
Premissa n
4.6 RESTRIÇÕES
Restrição 1
...
Restrição n
5. ABORDAGEM DO PROJETO
5.1 INSTRUMENTOS QUE SERÃO ELABORADOS PARA ESTE PROJETO
• EAP
• Cronograma
• Plano de Gerenciamento de Comunicações
• Plano de Gerenciamento de Mudanças
• Plano de Gerenciamento de Qualidade
• Plano de Gerenciamento de Recursos
• Lista de Verificação de Transição do Planejamento para a Execução
• Relatório de Progresso
• Memória de Reunião
• Registro de Lições Aprendidas
• Relatório Pós-Implementação
5.2 REUNIÕES DE CONTROLE
REUNIÃO PROPÓSITO FREQÜÊNCIA
Reunião de revisão do Avaliar o progresso do projeto

Semanal ou sob demanda
progresso no período pré-determinado
5.3 RELATÓRIOS DE STATUS QUE SERÃO USADOS PARA ESTE PROJETO
RELATÓRIO PROPÓSITO FREQÜÊNCIA
Apresentar o resultado da
avaliação do progresso do
Relatório de Progresso Semanal ou sob demanda
projeto obtido nas reuniões de
revisão
Apresentar uma visão sintética
Relatório Executivo da evolução e da situação do Mensal ou sob demanda
projeto no período
6. AUTORIZAÇÕES
O Enunciado do Escopo, a EAP, o cronograma do Projeto, o Plano de Gerenciamento de

47
Riscos e o Orçamento do Projeto são aprovados por:
Patrocinador do projeto: nome

Gerente do projeto: nome
Modificações na linha de base do projeto são aprovados por:
Patrocinador do projeto:
Indique aqui o nome do patrocinador do projeto
Gerente do projeto:
Indique aqui o nome do gerente do projeto
Produtos e subprodutos são aceitos e aprovados por:
Patrocinador do projeto: nome

Facilitadores: nomes
Observação: responsabilidades por tarefas específicas do projeto serão definidas

na Matriz de Responsabilidades e Atribuições
___________________________________ ____________________________________
_____ ____


48
___________________________________ ____________________________________
_____ ____
___________________________________ ____________________________________
____ ____
Responsável pelo projeto no Escritório de Projetos

As assinaturas acima indicam a compreensão do propósito e do conteúdo deste documento.

Assinando-o, estão concordando com ele como o documento formal de Enunciado do Escopo
do Projeto.
6.5Formulário de Solicitação de Mudança –

FSM - nº xxxx
Este documento é usado como instrumento de aprovação de mudanças com significado estratégico em um projeto.
Cumpre o papel de reconhecer, documentar e lidar apropriadamente com as mudanças ocorridas no projeto. Cada
mudança deve gerar um documento separado. As solicitações de mudança devem ser devidamente registradas e
assinadas (o que comprovará a ciência dos impactos delas decorrentes).
Nome do Insira aqui o nome escolhido para o projeto e presente no Pré-

Projeto: projeto.
Alterações
Código: versão
Data Versão Descrição Autor /

Revisor
Data Versão Descrição Autor
49
1. DESCRIÇÃO DA SOLICITAÇÃO DE MUDANÇA (E SUAS RAZÕES)
Descreva detalhadamente a mudança que está sendo pleiteada e os

argumentos que a justificam, incluindo resultados e benefícios.
2. MODIFICAÇÕES NAS ÁREAS DE CONHECIMENTO
Descreva a modificação associando-a à Área de Conhecimento apropriada.

Aponte os ajustes necessários decorrentes da implementação da
modificação.
Variação com relação Modificação proposta
Categoria
ao Plano de Projeto (referência ao Plano de Projeto)
3. ANÁLISE DE IMPACTOS (COMO FAZER)
Com relação aos elementos a serem avaliados para cada solicitação de

mudança, devem ser realizados os seguintes procedimentos:
1. Dê um duplo-clique sobre a matriz abaixo.

2. Na opção “Defina a pontuação de cada item abaixo”, selecione a pontuação
correspondente (de 0 a 5) a cada um dos elementos;
3. Para os itens “Impacto no orçamento do projeto” e “Impacto nos prazos do projeto” serão
usadas as seguintes faixas para definição dos valores:
4.
> 75% 50 ├─ 25 ├─ 10 ├─ 5├─

0 75%  50%  25%  10% 
1 2 3 4
5. Nas células à direita (onde aparece VLR.PONDERADO) surge a pontuação do item, a qual
toma por base as seguintes ponderações:
• Valores 0 e 1: usa-se o próprio valor
• Valores 2 e 3: usa-se o valor multiplicado por 3;
• Valores 4 e 5: usa-se o valor multiplicado por 6;
• O resultado indica o “valor” da mudança para o projeto e estará entre 0 e 90.
50
4. MATRIZ DE PONTUAÇÃO DAS SOLICITAÇÕES DE MUDANÇA
Pontuação
Item avaliado Defina a pontuação de
Valor Ponderado
cada item abaixo
Grau de importância 0 0
Impacto no orçamento do projeto 0 0
Impacto nos prazos do projeto 0 0
Riscos da implementação 0 0
Riscos da NÃO implementação 0 0
Valor final associado à mudança: 0
Sugestão: considerar esta mudança como sendo de:

Nenhuma importância, Nenhum impacto nos custos, Nenhum impacto nos prazos,
Nenhum risco de implementação, Nenhum risco de NÃO implementação
SUGESTÃO PARA AS AÇÕES:
5. INFORMAÇÕES DE ACOMPANHAMENTO DA SOLICITAÇÃO
Data da Aprova Razão para aprovação ou

Ação resultante
Decisão da? rejeição
__________________________________ __________________________________
______ ______

__________________________________ __________________________________
______ ______

51
_____
__________________________________ __________________________________
______ _
Responsável pelo projeto no Escritório de Projetos

6.6Formulário de Levantamento de Processo -

FLP
Identificação do Documento
Nome
do
Projeto
:
Prepar
ado
por:
Responsável pelas informações do processo: Data:

Processo:
Objetivo do processo:
Unidades Organizacionais executoras:
Quantitativo de Quantitativo de Média de tempo do
demandas recebidas: demandas atendidas: processo:
52
Quem
Du Executa
N Forne Insu Produ Clie
º cedor
Atividade e detalhamento raç (cargo/fu
mo to nte
ão nção/unid
ade)
Entradas: 1.
Atividade: Analisar a demanda
Procedimentos:
1
Instrumentos/Sistemas:
.
Legislação:
Técnicas:
Objetivo da atividade:
Atividade: C
Procedimentos:
2
.
Legislação:
Técnicas:
Atividade:
Procedimentos:
3
.
Legislação:
Técnicas:
Pontos de Alerta relacionados ao processo:

Problemas Causas Sugestão de Responsáv Prazo: Resultado
Soluções: el: s
Esperados
:
o
o

Scrum BTD

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Scrum BTD

Transféré par

Droits d'auteur :

Formats disponibles

2010

Benedito Germano Neponuceno

Especificações do Sistema Scrum

Brasília, dezembro 2010

que nos ajudaram na construção desta ferramenta

e principalmente a todos que dela fazerem uso

Agradecemos a todos que nos ajudaram

na elaboração deste trabalho,

principalmente ao Prof. Ricardo Santana.

“Comece fazendo o que é necessário,

depois o que é possível,

e de repente você estará fazendo o impossível.”

São Francisco de Assis

Este trabalho descreve um conjunto de requisitos utilizados no

Palavras-chave: Scrum, XP (Extreme Programming), metodologia,

This paper describes a set of requirements used in the development

Keywords: Scrum, XP (Extreme Programming), methodology, Scrum,

BPM – “Business Process Management”

RUP – “Rational Unified Process”

LHS – Limite de Horas da Sprint.

PMBOK – “Project Management Body of Knowledge”

Este trabalho contém todos os documentos e metodologias utilizadas na

Segundo o seu autor, Ken Shwaber (SCHWABER, 2004), o Scrum não é um

Segundo a Wikipédia (2010), Programação Extrema (do inglês eXtreme

Os quatro valores fundamentais da metodologia XP são: comunicação,

Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo),

A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno

Segundo a Wikipédia (2010), o Guia PMBOK é o guia que identifica um

A parte de gerenciamento do projeto deve seguir uma documentação mínima

solicitação de mudanças deverá ser preenchido e assinado pelos envolvidos (modelo

A junção e customização destas metodologias possibilitam o desenvolvimento

Antes de se desenvolver qualquer sistema, há de se mapear seus processos de

A automação de um processo de negócio falho gera um sistema falho e

Segundo a Wikipédia (2010), o Gerenciamento de Processos de Negócio

O Business Process Management (BPM), ou Gerenciamento de Processos de

O Gerenciamento de Processos de Negócios utiliza as melhores práticas de

Essas práticas aplicadas ajudam a maximizar os resultados e o desempenho dos

analisa criticamente o processo e se propõe melhorias, e a Situação Futura – “To Be”

Figura 1 - Diagrama do processo de desenvolvimento de software utilizando Scrum e XP

O diagrama acima (Figura 1) é uma representação gráfica do processo de

2.1.1 Demanda de desenvolvimento recebida

Recomendamos que uma prévia modelagem do processo de negócio ao qual a

2.1.2 Listar requisitos (Product Backlog)

Se o Proprietário do Produto (Product Owner) tem uma formação técnica, ele

Demanda de desenvolvimento recebida.

2.1.3 Listar impedimentos dos requisitos (Impediment

2.1.4 Estimar prazo para itens da lista de requisitos

Lista priorizada de requisitos (Product Backlog).

2.1.5 Priorizar lista de requisitos (Product Backlog)

2.1.6 Lista de requisitos levantada, priorizada e estimada

2.1.7 Fim dos itens do Product Backlog?

O fluxos do processo segue para reuniões de planejamento do desenvolvimento

O fluxo do processo segue para a realização testes finais para se certificar a

2.1.8 Realizar planejamento do desenvolvimento (Sprint

2.1.9 Detalhar atividades de cada item da Sprint

2.1.10 Calcular o Tamanho da Sprint

Note que se você tiver o H variando para alguns recursos, é importante

Outro motivo importante para se manter o padrão de duração da Sprint é a

2.1.11 Executar e Controlar a Sprint

Durante a execução da Sprint, a alocação de recursos para cada tarefa é dirigida

Para esse acompanhamento o time usa um gráfico chamado de Sprint

O time também possui um “quadro de trabalho” onde organiza as atividades,

2.1.12 Realizar reunião de revisão

Após esta reunião, a reunião de retrospectiva é realizada, podendo ser chamada