Service-desk em metodologia Scrum

...

Estratégia de Comunicação

[pic 2]

Gestão de mudança de Escopo

Toda mudança no projeto, poderá ser solicitada por qualquer usuário, mas antes de encaminhar para o superior, deverá ser preenchido o formulário, e duas pessoas deveram acordar com a mudança, para assim. Ter a análise da supervisão, para aprovação ou não. Caso seja aprovado/ou não, a resposta será respondida por e-mail com o formulário preenchido. Assinatura de mudança datada.

[pic 3]

Aprovações

Participante

Assinatura

Ano

Gestor – Controle total de mudanças

Ricardo Silva

2016/2017

Coordenador – Alteração de campos para inserção

Elias Lima

2016/2017

Monitoração – Design do projeto

Eduardo Rocha

2016/2017

Objetivos deste documento

Devido o controle ser realizado atualmente apenas por acompanhamentos em planilhas e anotações, se faz necessário à implementação de um sistema que realize o controle de ocorrências, sendo distribuído por usuários/gestores separando os níveis de acontecimentos.

Com isso, será possível realizar todo acompanhamento necessário, de forma simples, sem realizar um estudo de todas as planilhas de como é feito hoje.

Situação atual e justificativa do projeto

Devido o controle ser realizado atualmente apenas por acompanhamentos em planilhas e anotações, se faz necessário à implementação de um sistema que realize o controle de ocorrências, sendo distribuído por usuários/gestores separando os níveis de acontecimentos.

Com isso, será possível realizar todo acompanhamento necessário, de forma simples, sem realizar um estudo de todas as planilhas de como é feito hoje.

Objetivos SMART e critérios de sucesso do projeto

Devido o controle ser realizado atualmente apenas por acompanhamentos em planilhas e anotações, se faz necessário à implementação de um sistema que realize o controle de ocorrências, sendo distribuído por usuários/gestores separando os níveis de acontecimentos.

Com isso, será possível realizar todo acompanhamento necessário, de forma simples, sem realizar um estudo de todas as planilhas de como é feito hoje.

Produtos e principais requisitos

REQUISITOS MINIMOS DO USUÁRIO

- Sistema operacional: Windows XP ou superior, Linux, MAC OS

- Hardware: 512 RAM

- Software: Navegadores de internet compatível conforme abaixo

- Processador: Pentium 4 1,0GHz

- NAVEGADORES COMPATÍVEIS

- Google Chrome (Versão 45)

- Internet Explorer (Versão 10 ou superior)

- Opera (31.0.1889.174)

- Mozilla Firefox (40.0)

- Safari (5.1.10)

Marcos

Marcos

Previsão

Entrega do projeto para o usuário (homologação)

Premissas

- BANCO DE DADOS/LINGUAGEM DE PROGRAMAÇÃO

- SQL Server

- HTML

- CADASTRO

- Funcionário

- Cliente

- Departamento

- Ocorrências

- Nível de SLA

- RELATÓRIOS

- Quantidade de Chamados - Anual, Mensal e Semanal.

- Ocorrências- Mensal

- Funcionários

- Departamentos

- CONTROLE DE SLA

- Feedback do usuário

Restrições

O projeto só poderá ser realizado se houver a compra do servidor, pois iremos trabalhar em cima dele.

O ambiente será instalado em cima do sistema operacional Windows Server 2008 R2.

Orçamento do Projeto

Aprovações

Participante

Assinatura

Ano

Remuneração dos colaboradores

Gestor

2016/2017

Horas adicionais

Gerente do Projeto

2016/2017

PRODUCT BACKLOG

O product backlog é uma compilação de tudo o que o seu cliente gostaria de realizar no projeto. Pense com uma grande wishlist com todos os recursos e funcionalidades que os usuários gostariam de ver presentes no trabalho final. Esta lista deve ser organizada pelo Product Owner de acordo com valor, risco, prioridade e necessidade. Por natureza o backlog é algo dinâmico e muda constantemente para incluir as novas solicitações dos clientes, usuários e do mercado em si. Desta forma os produtos são sempre aperfeiçoados em cada Sprint.

[pic 4]

Plano Gerenciamento

Requisitos