Universidade Federal Fluminense
Superintendência de Tecnologia da Informação
Processo de Gerenciamento de Projetos
Escritório de Projetos – STI/UFF
Versão 2.0 Niterói, Março de 2016
Índice
1 ESCRITÓRIO DE PROJETOS ... 14
1.1
P
ROCESSO PRINCIPAL... 15
1.1.1
Elementos do processo ... 15
1.1.1.1
4. Controle da Qualidade ... 15
1.1.1.2
3. Scrum... 15
1.1.1.3
1. Projetos de Desenvolvimento de Sistemas ... 15
1.1.1.4
5. Processo de Liberação ... 15
1.1.1.5
2. Projetos Internos ... 16
1.1.1.6
... 16
2 1. PROJETOS DE DESENVOLVIMENTO DE SISTEMAS... 17
2.1
1.
P
ROJETOS DED
ESENVOLVIMENTO DES
ISTEMAS... 18
2.1.1
Elementos do processo ... 18
2.1.1.1
Início de projeto autorizado ... 18
2.1.1.2
1.1 Iniciação do Projeto ... 18
2.1.1.3
1.3 Planejamento de Sprint ... 18
2.1.1.4
1.4 Execução do Sprint ... 19
2.1.1.5
1.7 Encerramento do Projeto ... 19
2.1.1.6
Entrega... 19
2.1.1.7
O projeto está pronto?... 20
2.1.1.8
1.5 Controle do Sprint... 20
2.1.1.9
Termo de Abertura... 20
2.1.1.10
Plano do Projeto... 21
2.1.1.11
Relatório de Acompanhamento ... 21
2.1.1.14
Resumo de Sprint Review ... 22
2.1.1.15
1.2 Planejamento Geral... 22
2.1.1.16
1.6 Acompanhamento de Projeto... 23
2.1.1.17
Gerencial... 23
2.1.1.18
Desenvolvimento ... 23
2.1.1.19
Iniciação... 23
2.1.1.20
Planejamento... 23
2.1.1.21
Execução... 23
2.1.1.22
Controle e Encerramento ... 23
3 ESPECIFICAR REQUISITOS ... 25
3.1
P
ROCESSO PRINCIPAL... 26
3.1.1
Elementos do processo ... 26
3.1.1.1
Atividade Gerencial ... 26
3.1.1.2
Atividade Técnica... 26
4 1.2 PLANEJAMENTO GERAL... 27
4.1
1.2
P
LANEJAMENTOG
ERAL... 28
4.1.1
Elementos do processo ... 28
4.1.1.1
Especificar requisitos... 28
4.1.1.2
Criar FBS... 30
4.1.1.3
Criar matriz de dependências... 30
4.1.1.4
Estimar Requisitos ... 30
4.1.1.5
Definir equipe ... 31
4.1.1.6
Estimar velocidade do time ... 31
4.1.1.7
Estimar infraestrutura ... 32
4.1.1.9
Estimar custo ... 33
4.1.1.10
Determinar orçamento ... 34
4.1.1.11
Definir a qualidade ... 34
4.1.1.12
Planejar Comunicação ... 35
4.1.1.13
Criar o Plano do Projeto ... 35
4.1.1.14
Plano do Projeto... 35
4.1.1.15
Event... 36
4.1.1.16
Vai gerar receita?... 36
4.1.1.17
Planejar riscos... 36
4.1.1.18
Avaliar a viabilidade do projeto... 36
4.1.1.19
Assinar o plano de projeto ... 36
4.1.1.20
Obter comprometimento da equipe... 37
4.1.1.21
Fim da fase de planejamento ... 37
4.1.1.22
Gerente do Projeto + PMO ... 37
5 1.3 PLANEJAMENTO DE SPRINT... 38
5.1
P
ROCESSO PRINCIPAL... 39
5.1.1
Elementos do processo ... 39
5.1.1.1
Atividade Técnica... 39
5.1.1.2
Atividade Gerencial ... 39
6 1.4 EXECUÇÃO DO SPRINT ... 40
6.1
1.4
E
XECUÇÃO DOS
PRINT... 41
6.1.1
Elementos do processo ... 41
6.1.1.1
Event... 41
6.1.1.2
Buscar tarefa ... 41
6.1.1.4
Desenhar solução (código e teste) ... 41
6.1.1.5
Implementar solução... 42
6.1.1.6
Implementar testes ... 42
6.1.1.7
A solução está suficiente?... 43
6.1.1.8
Publicar solução... 43
6.1.1.9
Executar testes automatizados ... 43
6.1.1.10
Há tarefas abertas no backlog sprint? ... 43
6.1.1.11 ………43
6.1.1.12
Event... 44
6.1.1.13
Realizar Reunião diária... 44
6.1.1.14
Event... 44
6.1.1.15
No horário combinado ... 44
6.1.1.16
Atividade Gerencial ... 44
6.1.1.17
Atividade Técnica... 44
7 1.5 CONTROLE DO SPRINT... 45
7.1
P
ROCESSO PRINCIPAL... 46
7.1.1
Elementos do processo ... 46
7.1.1.1
Atividade Gerencial ... 46
7.1.1.2
Atividade Técnica... 46
8 1.6 ACOMPANHAMENTO DE PROJETO ... 47
8.1.1
Elementos do processo ... 48
8.1.1.1
Fim do Sprint ... 48
8.1.1.2
Preparar RA ... 48
8.1.1.3
Envia ao PMO... 48
8.1.1.5
Divulgar notícias... 48
8.1.1.6
Email com notícia dos projetos... 49
8.1.1.7
Relatório de Acompanhamento ... 49
8.1.1.8
Atualizar o Redmine com o review ... 49
8.1.1.9
Extrair e armazenar resumo de review ... 49
8.1.1.10
Atualizar Cronograma do projeto do PMO... 49
8.1.1.11
Atualizar o Redmine com o planning ... 50
8.1.1.12
Extrair e armazenar resumo de planning e cronograma... 50
8.1.1.13
Reunião de acompanhamento ... 50
8.1.1.14
Gerar Resumo de Acompanhamento ... 50
8.1.1.15
Realizar avaliação do Acompanhamento... 50
8.1.1.16
Resumo de Acompanhamento ... 50
8.1.1.17
PMO... 51
8.1.1.18
Gerente... 51
8.1.1.19
Pré-acompanhamento ... 51
8.1.1.20
Acompanhamento ... 51
8.1.1.21
Pós-acompanhamento ... 51
8.2
P
ROCESSO PRINCIPAL... 51
8.2.1
Elementos do processo ... 51
8.2.1.1
Atividade Técnica... 51
8.2.1.2
Atividade Gerencial ... 51
9 1.7 ENCERRAMENTO DO PROJETO... 52
9.1
1.7
E
NCERRAMENTO DOP
ROJETO... 53
9.1.1
Elementos do processo ... 53
9.1.1.2
Termo de encerramento do projeto assinado ... 53
9.1.1.3
Confeccionar Termo de Encerramento ... 53
9.1.1.4
Fechar o projeto no Redmine... 53
9.1.1.5
Criar a operação no Redmine se necessário... 54
9.1.1.6
Event... 54
9.1.1.7
Notificação do término do projeto ao PMO... 54
9.1.1.8
Verificar Não Conformidades... 54
9.1.1.9
Há NC pendente?... 54
9.1.1.10
Validar termo de encerramento... 55
9.1.1.11
Armazenar documento de encerramento ... 55
9.1.1.12
Elaborar resumo de encerramento ... 55
9.1.1.13
Enviar questionário de satisfação ao Cliente/PO... 55
9.1.1.14
Event... 55
9.1.1.15
Analisar Não Conformidades... 55
9.1.1.16
Modelo de Termo de Encerramento ... 55
9.1.1.17
Modelo de Resumo de Encerramento... 56
9.1.1.18
Formulário de satisfação do cliente ... 56
9.1.1.19
Gerente... 56
9.1.1.20
Escritório de Projetos... 56
10
3. SCRUM... 57
10.1
3.
S
CRUM... 58
10.1.1
Elementos do processo ... 58
10.1.1.1
Sprint Planning ... 58
10.1.1.2
Desenvolvimento diário... 58
10.1.1.3
Reunião diária... 58
10.1.1.4
Review ... 58
10.1.1.5
Retrospectiva ... 58
10.1.1.6
Event... 58
10.1.1.7
Gateway ... 58
10.1.1.8
Gateway ... 58
10.1.1.9
Product Backlog completo?... 58
10.1.1.10
Event... 58
10.1.1.11
Planejamento... 58
10.1.1.12
Execução... 59
10.1.1.13
Controle ... 59
11
CADASTRAR RISCOS... 60
11.1
C
ADASTRO DE RISCOR
EDMINE... 61
11.1.1
Elementos do processo ... 61
11.1.1.1
Event... 61
11.1.1.2
Verificar se o risco já está cadastrado... 61
11.1.1.3
Risco cadastrado? ... 61
11.1.1.4
Incluir um novo risco... 61
11.1.1.5
Avaliar o risco... 61
11.1.1.6
Aprovado?... 61
11.1.1.7
Cadastrar risco na Base de Conhecimento... 61
11.1.1.8
Event... 62
11.1.1.11
Associar os riscos ... 62
11.1.1.12
Gerente... 62
11.1.1.13
Escritório de Projetos... 62
12
5. PROCESSO DE LIBERAÇÃO... 63
12.1
5.
P
ROCESSO DEL
IBERAÇÃO... 64
12.1.1
Elementos do processo ... 64
12.1.1.1
Event... 64
12.1.1.2
5.1 Realizar auditoria pre-liberação... 64
12.1.1.3
Aprovada?... 64
12.1.1.4
5.2 Realizar liberação ... 64
12.1.1.5
5.3 Realizar auditoria pos-liberação ... 65
12.1.1.6
Event... 65
12.1.1.7
Realizar ajustes ... 65
12.1.1.8
Informar liberação ... 65
12.1.1.9
Gerente... 65
12.1.1.10
PMO... 65
13
4. ANALISAR NÃO CONFORMIDADES... 66
13.1
4.
A
NALISAR NÃO CONFORMIDADES... 67
13.1.1
Elementos do processo ... 67
13.1.1.1
Event... 67
13.1.1.2
Identificar a NC ... 67
13.1.1.3
Cadastrar NC ... 67
13.1.1.4
Analisar NC ... 67
13.1.1.5
Ação corretiva necessária ?... 67
13.1.1.7
Event... 68
13.1.1.8
Definir ação corretiva ... 68
13.1.1.9
Cadastrar Ação corretiva ... 68
13.1.1.10
Definir responsável pela Ação Corretiva... 68
13.1.1.11
Monitorar a implementação... 68
13.1.1.12
Analisar eficácia ... 68
13.1.1.13
Foi eficaz?... 68
13.1.1.14
Finalizar ação corretiva... 68
13.1.1.15
Finalizar não conformidade ... 69
13.1.1.16
Event... 69
14
GERAR RESUMO DE ACOMPANHAMENTO... 70
14.1
G
ERARR
ESUMO DEA
COMPANHAMENTO... 71
14.1.1
Elementos do processo ... 71
14.1.1.1
Event... 71
14.1.1.2
Avaliar progresso e qualidade do projeto ... 71
14.1.1.3
Analisar Não Conformidades... 71
14.1.1.4
Analisar Riscos ... 71
14.1.1.5
Analisar impedimentos ... 71
14.1.1.6
Analisar Desvios... 71
14.1.1.7
Gerar gráficos e preenher resumo... 72
14.1.1.8
Event... 72
14.1.1.9
Resumo de Acompanhamento ... 72
15
5.3 REALIZAR AUDITORIA POS-LIBERAÇÃO... 73
15.1.1.1
Event... 74
15.1.1.2
Verificar se a baseline de produção foi gerada ... 74
15.1.1.3
Verificar a criação da documentação... 74
15.1.1.4
Certificar a ocorrência da liberação... 74
15.1.1.5
Certificar que os interessados foram comunicados... 74
15.1.1.6
Event... 74
16
5.2 REALIZAR LIBERAÇÃO ... 75
16.1
5.2
R
EALIZAR LIBERAÇÃO... 76
16.1.1
Elementos do processo ... 76
16.1.1.1
Event... 76
16.1.1.2
Gerar Baseline de produção... 76
16.1.1.3
Gerar documentação da versão liberada ... 76
16.1.1.4
Realizar deploy em produção ... 76
16.1.1.5
Comunicar a todos os interessados ... 76
16.1.1.6
Event... 76
17
ANALISAR IMPEDIMENTOS... 77
17.1
A
NALISAR IMPEDIMENTOS... 78
17.1.1
Elementos do processo ... 78
17.1.1.1
Event... 78
17.1.1.2
Consultar impedimentos do projeto... 78
17.1.1.3
Definir criticidade dos impedimentos... 78
17.1.1.4
Buscar soluções e comunicar aos interessados ... 78
17.1.1.5
Event... 78
18
ANALISAR RISCOS... 79
18.1
A
NALISARR
ISCOS... 80
18.1.1
Elementos do processo ... 80
18.1.1.2
Confirmar alterações no Redmine ... 80
18.1.1.3
É inclusão de Novo Risco? ... 80
18.1.1.4
Validar risco... 80
18.1.1.5
Risco genérico cadastrado na BC?... 80
18.1.1.6
Criar Risco genérico na BC ... 80
18.1.1.7
Associar ao risco da BC ao risco do projeto... 80
18.1.1.8
Event... 80
18.1.1.9
Validar alterações ... 81
19
PLANEJAR RISCOS ... 82
19.1
P
LANEJARR
ISCOS... 83
19.1.1
Elementos do processo ... 83
19.1.1.1
Identificar os riscos... 83
19.1.1.2
Fazer análise qualitativa dos riscos... 83
19.1.1.3
Planejar resposta aos riscos ... 83
19.1.1.4
Cadastrar riscos... 84
20
5.1 REALIZAR AUDITORIA PRE-LIBERAÇÃO... 85
20.1
5.1
R
EALIZAR AUDITORIA PRE-
LIBERAÇÃO... 86
20.1.1
Elementos do processo ... 86
20.1.1.1
Event... 86
20.1.1.2
Verificar a cobertura de testes ... 86
20.1.1.3
Verificar o parecer do líder técnico ... 86
20.1.1.4
Verificar a rastreabilidade... 86
20.1.1.5
Verificar baseline para liberação ... 86
20.1.1.8
Verificar se o PO aprovou a liberação... 87
20.1.1.9
Event... 87
21
ANALISAR DESVIOS... 88
21.1
A
NALISARD
ESVIOS... 89
21.1.1
Elementos do processo ... 89
21.1.1.1
Event... 89
21.1.1.2
Registrar o desvio do projeto... 89
21.1.1.3
Analisar soluções para desvio... 89
21.1.1.4
Há ação corretiva? ... 89
21.1.1.5
Aceitar Desvio ... 89
21.1.1.6
Event... 89
Versão: 2.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
Descrição
O Escritório de Projetos é o responsável pelo acompanhamento e gerenciamento dos projetos da STI.
1.1
Processo principal
1.1.1
Elementos do processo
1.1.1.1
4. Controle da Qualidade
Processo
4. Analisar não conformidades - 4. Analisar não conformidades
1.1.1.2
3. Scrum
Processo
3. Scrum - 3. Scrum
1.1.1.3
1. Projetos de Desenvolvimento de Sistemas
Descrição
Processo
1. Projetos de Desenvolvimento de Sistemas - 1. Projetos de Desenvolvimento de Sistemas
1.1.1.4
5. Processo de Liberação
Processo
1.1.1.5
2. Projetos Internos
1.1.1.6Versão: 1.1
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
DescriçãoEste diagrama descreve o processo de desenvolvimento de sistemas/soluções da STI.
2.1
1. Projetos de Desenvolvimento de Sistemas
Descrição
Este processo descreve a produção de um projeto de software da STI
2.1.1
Elementos do processo
2.1.1.1
Início de projeto autorizado
Descrição
A Coordenação Desenvolvimento de Sistemas inicia um projeto quando seu início receber autorização da direção da STI.
2.1.1.2
1.1 Iniciação do Projeto
Descrição
Neste processo serão identificadas as partes interessadas, objetivo e limitações do projeto. Ao término deste processo, o projeto efetivamente será iniciado.
Se o projeto é componente de um programa cujas informações obtidas na fase de Iniciação são compartilhadas, não há a necessidade de haver um Termo de Abertura para cada projeto, mas apenas para o primeiro. Os demais projetos iniciam na fase de planejamento. Neste caso, apenas verifica-se as informações contidas no Termo de Abertura anterior e, caso estejam coerentes, passa-se à fase seguinte.
Processo
1.1 Iniciação de Projeto - Processo principal
2.1.1.3
1.3 Planejamento de Sprint
Descrição
No processo "Planejamento de Sprint", o sprint será planejado, identificando quais requisitos devem ser entregues ao final dele. Neste processo os requisitos serão desenvolvidos e esmiuçados em tarefas, com suas respectivas estimativas. Além disso, define-se o objetivo do Sprint e toda a equipe compromete-se a trabalhar em prol dele.
O Planejamento de Sprint é dividido em duas reuniões: planejamento I e planejamento II. No primeiro planejamento, o cliente deve identificar, dentro os itens do Product Backlog, quais têm mais prioridade e devem ser desenvolvidos no próximo Sprint. O segundo planejamento é uma reunião técnica, no qual a equipe irá criar tarefas para que os requisitos escolhidos possam ser entregues.
Processo
1.3 Planejamento de Sprint - Processo principal
2.1.1.4
1.4 Execução do Sprint
Descrição
Durante este processo a equipe efetivamente desenvolve o que foi definido no Planejamento do Sprint, ou seja, implementa cada funcionalidade para agregar valor ao produto do projeto e entregar uma parte dele ao cliente ao final de cada Sprint.
Processo
1.4 Execução do Sprint - Processo principal
2.1.1.5
1.7 Encerramento do Projeto
Descrição
Uma vez que o que foi planejado seja plenamente implementado e entregue pela equipe ao cliente, o processo de finalização tem por finalidade averiguar se o produto do projeto atende ao escopo e qualidade definidos e tomar medidas necessárias para possíveis adequações que ainda sejam necessárias. A principal saída deste processo é o Termo de Entrega do Projeto.
Processo
1.7 Encerramento do Projeto - 1.7 Encerramento do Projeto
2.1.1.6
Entrega
Descrição
A entrega é o momento onde recebe o produto final do projeto como sendo o que efetivamente foi solicitado e planejado. O Termo de Entrega do Projeto é assinado e o projeto termina. A partir disto, apenas a manutenção
corretiva é realizada. Novas funcionalidades não são mais desenvolvidas e aguardam a iniciação de um novo projeto caso sejam necessárias.
2.1.1.7
O projeto está pronto?
Descrição
O projeto é considerado pronto quando uma das condições é satisfeita: - O objetivo identificado no termo de abertura foi alcançado; - O Product Backlog foi entregue;
2.1.1.8
1.5 Controle do Sprint
Descrição
É o processo de, entrega e homologação dos requisitos desenvolvidos ao cliente e melhoria contínua dos processos e equipe. Os objetivos deste processo são controlar a qualidade e conformidade do que foi desenvolvido, e melhorar o processo de desenvolvimento e a capacidade técnica da equipe.
Processo
1.5 Controle do Sprint - Processo principal
2.1.1.9
Termo de Abertura
Descrição
O Termo de Abertura possui as seguintes seções:
• Informações gerais • Partes interessadas • Justificativa e motivação • Objetivos e metas • Produtos do projeto • Restrições • Riscos • Assinaturas URL
2.1.1.10
Plano do Projeto
Descrição
O plano de projeto é o documento que registra o único marco formal do processo de desenvolvimento. URL
Modelo de Plano de Projeto
2.1.1.11
Relatório de Acompanhamento
Descrição
Possui as seguintes seções:
• Dados do projeto • Atividades • Qualidade e Indicadores: o Código; o Aderência ao Processo; o Reuniões. • Controle • Riscos • Avaliação da STI • Cliente • Observações URL https://sistemas.uff.br/redmine/documents/107
2.1.1.12
Resumo de Sprint Plannig
Descrição
Documento extraído diretamente do Redmine do projeto, através do relatório "SCRUM: Sprint Planning/Review".
2.1.1.13
Termo de Encerramento do Projeto
Descrição
Modelo do Termo de Encerramento de Projeto da STI. Possui as seguintes seções:
• Informações gerais • Produtos finais do projeto
• Motivos para encerramento do projeto • Aceite do Patrocinador do Projeto • Assinaturas
URL
Modelo de Termo de Encerramento
2.1.1.14
Resumo de Sprint Review
Descrição
Documento extraído diretamente do Redmine do projeto, através do relatório "SCRUM: Sprint Planning/Review".
2.1.1.15
1.2 Planejamento Geral
Descrição
Neste processo, é feito um planejamento inicial do projeto, no qual os requisitos são analisados de forma geral e superficial.
O foco deste processo é entender mais sobre o projeto com a finalidade de estimar o tamanho, custo, cronograma, equipe, Product Owner e Gerente do Projeto, e os recursos disponíveis para a sua execução. O entendimento dos requisitos deve ser suficiente apenas para estimar um cronograma básico e os definir de forma a evitar ambiguidades e futuros desentendimentos.
O principal resultado deste processo é o Plano de Gerenciamento do Projeto. Processo
2.1.1.16
1.6 Acompanhamento de Projeto
Descrição
É o processo de acompanhamento dos resultados do trabalho da equipe. São aferidas quatro tipos de métricas: de qualidade, do produto, de comprometimento, e de produtividade da equipe. O resultado do Sprint de cada projeto é coletado e divulgado para que todos tenham uma visão geral do andamento dos projetos.
Processo
1.6 Acompanhamento de Projeto - 1.6 Acompanhamento de Projeto
2.1.1.17
Gerencial
2.1.1.18
Desenvolvimento
2.1.1.19
Iniciação
Descrição
Grupo de Processo de Iniciação: São os processos realizados para definir um novo projeto ou uma nova fase de um projeto existente através da obtenção de autorização para inciar o projeto ou fase. [Ref: PMBOK 2008]
2.1.1.20
Planejamento
Descrição
Grupo de processos de planejamento: Os processos realizados para definir o escopo do projeto, refinar os objetivos e desenvolver o curso de ação necessário para alcançar os objetivos para os quais o projeto foi criado. [Ref: PMBOK 2008]
2.1.1.21
Execução
Descrição
Grupo de processos de execução: Os processos realizados para executar o trabalho definido no plano de gerenciamento do projeto para satisfazer as especificações do mesmo. [Ref: PMBOK 2008]
2.1.1.22
Controle e Encerramento
Grupo de processos de monitoramento e controle: Os processos necessários para acompanhar, revisar e regular o progresso e o desempenho do projeto, identificar todas as áreas nas quais serão necessárias mudanças no plano e iniciar as mudanças correspondentes.
Grupo de processos de encerramento: Os processos executados para finalizar todas as atividades de todos os grupos de processos, visando encerrar formalmente o projeto ou a fase. [Ref: PMBOK 2008]
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
3.1
Processo principal
3.1.1
Elementos do processo
3.1.1.1
Atividade Gerencial
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
4.1
1.2 Planejamento Geral
4.1.1
Elementos do processo
4.1.1.1
Especificar requisitos
Descrição
Entradas:
- Relatório de Análise de Demandas; - Termo de abertura.
Ferramentas:
- Reunião de especificação de requisitos Saídas:
- Product Backlog, ordenado de acordo com a importância definida pelo cliente e dependências funcionais já conhecidas.
Descrição:
Um requisito deve ser escrito em linguagem de negócios e não tecnicamente, o que significa dizer, que deve conter um valor que será incorporado ao projeto ou ao produto. Além disso, deve ser entregável em no máximo um Sprint. Desta forma, a cada sprint o projeto gera valor para o cliente e este valor pode ser mensurado e avaliado pelo P.O.
Sugere-se que todos os requisitos priorizem uma redação padrão, no seguinte esquema:
Os três elementos: ATOR, AÇÃO e VALOR devem sempre que possível compor a redação dos requisitos. O item a abaixo contém alguns exemplos disto.
Um bom requisito precisa atender às seguintes diretrizes INVEST: I = Independente: não depende de outra história para ser concluída
E = Estimável: precisa estar minimamente detalhada e entendida a ponto da equipe conseguir realizar uma estimativa de esforço para sua conclusão;
S = Pequena (Small): precisa possuir um tamanho máximo, onde o esforço para a conclusão seja de até um Sprint;
T = Testável: precisa dizer, claramente, qual a condição para sua aceitação pelo P.O. A coleta de requisitos é feita usualmente em dois momentos:
Reunião de levantamento de requisitos: realizada entre Product Owner (PO) e Equipe do Projeto após a assinatura do termo de abertura, esta reunião abre a fase de planejamento do projeto, e é exclusivamente destinada à coleta de requisitos. De posse do Termo de Abertura, o PO expõe mais detalhadamente suas necessidades específicas (o que chamamos histórias) e a Equipe do Projeto identifica as demandas e, lapida a informação com o PO para gerar os requisitos do projeto e do produto que devem ser contemplados na execução. Por exemplo:
- O Product Owner diz: preciso que o sistema controle a entrada e saída de materiais do estoque.
- O gerente identifica: registrar entrada de materiais, registrar a saída de materiais, gerar relatórios sobre a movimentação.
Lapidação da informação: Quem é o funcionário responsável pelo controle de entrada e saída de materiais? É o mesmo para os dois? O que ele faz efetivamente? Que tipo de registro ele precisa gerar? Como os gestores devem consultar estes registros?
Identificação de requisitos:
O estoquista deve poder cadastrar a materiais no estoque para registrar a entrada dos mesmos no patrimônio O estoquista deve poder dar baixa em materiais no estoque para registrar a saída dos mesmos no patrimônio. O gerente deve poder gerar relatório de entrada de materiais em estoque em um período de tempo à sua escolha para conhecer as alterações de patrimônio.
Sprint Plannings: durante as reuniões de planejamento de cada sprint o Product Owner deve definir a ordem de desenvolvimento do produto. Dado que a cada sprint um ou mais requisitos são entregues, é comum o
Product Owner apresentar outros requisitos que não havia imaginado antes.
Processo
4.1.1.2
Criar FBS
Descrição Entradas: - Product Baklog; Ferramentas:
- Redmine, relatório "FBS" da seção "Tarefas" do projeto; Saídas:
- FBS;
- Plano de projeto, seção "Estrutura analítica do projeto" Descrição:
O formato de estrutura analítica de projeto utilizado pela STI está orientado a funcionalidades (FBS -
Features Breakdown Structure), uma vez que é mais simples para o entendimento da equipe do projeto e do
próprio P.O.(cliente).
A FBS deve ser gerada através do Redmine e para que ela esteja correta é fundamental cadastrar com precisão os requisitos. Uma vez que eles estejam corretamente cadastrados, basta utilizar a consulta personalizada FBS na guia de Tarefas do seu projeto. Ela agrupa os requisitos por categoria, gerando assim a FBS adequada.
4.1.1.3
Criar matriz de dependências
Descrição
Entradas: - Product Backlog
Ferramentas: - Avaliação técnica e das regras de negócio discutidas no processo de coleta de requisitos; Saídas: - Matriz de dependências - Plano de projeto, seção "Matriz de dependências"
Descrição: A matriz de dependências relaciona requisitos entre si de modo que se identifique que requisitos dependem de outros para serem implementados.
4.1.1.4
Estimar Requisitos
Descrição: A estimativa deve ser feita em pontos de história e em alto nível, sem muitos detalhes. Apenas o necessário para estimar o tamanho do projeto.
4.1.1.5
Definir equipe
Descrição Entradas:
- Product Backlog estimado; - Termo de abertura; - Proposta de Projeto. Ferramentas:
- Avaliação técnico-gerencial
- Reunião de alocação de recursos humanos, entre PMO e RH. Saídas:
- Plano de projeto, seção "Recursos Humanos" Descrição:
A estimativa de equipe define qual o número ideal e a capacidade das pessoas que trabalharão no projeto, considerando seu perfil e disponibilidade de tempo. Se necessário o RH executar a seleção de novos recursos humanos.
Somente são definidos dois papéis na equipe:
Gerente - responsável pela execução do processo dentro da equipe, comunicação com o Product Owner, geração e atualização das informações do projeto no Redmine e nos documentos definidos pelo processo. Atua também como Scrum Master, zelando pela plena realização do Scrum conforme definido pelo processo e removendo os impedimentos que surjam ao longo do Sprint.
Desenvolvedor - todos os demais membros fixos da equipe, independente das tarefas que desempenhem ou das habilidades com que contribuam para a execução do projeto. Conforme definido pelo Scrum, todos da equipe são igualmente responsáveis pelo desenvolvimento das soluções às quais o projeto se destina.
4.1.1.6
Estimar velocidade do time
Descrição Entradas:
- Plano de projeto, seção "Recursos Humanos"; - Dados históricos;
- Proposta de Projeto.
Ferramentas:
- Avaliação técnico-gerencial
- Estimativa baseada em dados históricos
Saídas:
- Estimativa inicial de velocidade do time; - Plano de projeto, seção "Velocidade do time" Descrição:
A estimativa do time é feita levando em conta o número de pessoas do time e a capacidade técnica dos membros, com base em dados históricos ou em referências técnicas.
4.1.1.7
Estimar infraestrutura
Descrição Entradas:
- Product Backlog estimado;
- Plano de projeto, seção "Recursos Humanos" Ferramentas:
- Avaliação técnico-gerencial; Saídas:
avaliação serão identificadas necessidades como espaço de trabalho, máquinas, ferramentas, tecnologias, mobiliário, espaço de disco, capacidade de processamento e memória dos servidores, sistema de controle de versões e tudo o mais que for preciso para garantir à equipe as condições de desenvolvimento do projeto.
4.1.1.8
Criar cronograma
Descrição Entradas:
- Plano de projeto, seção "Product Backlog"; - Plano de projeto, seção "Velocidade do time"; - Plano de projeto, seção "Matriz de dependências"; - Proposta de Projeto.
Ferramentas:
- Estimativa com fator de foco/produtividade; - Divisão de tempo em Sprints
Saídas:
- Cronograma baseado em sprints; - Plano de projeto, seção "Cronograma". Descrição:
Distribuir os itens do Backlog em Sprints, de acordo com a velocidade do time, respeitando a ordem de importância dos requisitos definida pelo cliente e possíveis dependências entre eles.
4.1.1.9
Estimar custo
Descrição
Entradas: - Plano de projeto, seção "Recursos Humanos"; - Plano de projeto, seção "Cronograma"; - Plano de projeto, seção "Infraestrutura".
Ferramentas: - Avaliação financeira - Planilha de estimativas Saídas: - Planilha de estimativa de custos do projeto
Descrição: A partir da análise das estimativas de recursos humanos, da infraestrutura e do tempo necessários ao desenvolvimento do projeto, estima-se o custo total do mesmo em uma planilha de estimativa. Isto pode não ser necessário em virtude da possibilidade de o projeto ser executado sem recursos financeiros.
4.1.1.10
Determinar orçamento
Descrição Entradas: - Estimativa de custo; Ferramentas: - Avaliação gerencial Saídas: - Orçamento do projeto Descrição:Se o projeto for gerar receita, é necessário definir um preço com base no custo estimado.
4.1.1.11
Definir a qualidade
Descrição
Entradas: Termo de Abertura do Projeto e Product Backlog Estimado Ferramentas: Avaliação técnico-gerencial
Saídas: Indicadores e metas de qualidade
Descrição: Alguns indicadores de qualidade técnica são padronizados, independente do projeto. São eles: * 80% de cobertura mínima de código;
* 100% de testes passando.
4.1.1.12
Planejar Comunicação
Descrição
Definir como será realizada a comunicação entre os interessados. * Comunicação interna a Equipe
* Comunicação com o Cliente e PO * E-mail oficial do projeto
* Telefones para contato.
4.1.1.13
Criar o Plano do Projeto
Descrição Entradas:
- Termo de abertura;
- Template de plano de projeto; - Tabela de riscos planejados; - Cronograma; - Product Backlog; - FBS; - Matriz de Dependências; - Cronograma; Ferramentas: - Avaliação técnico-gerencial; - Preenchimento do modelo; Saídas: - Plano de Projeto Descrição:
Com base nas saídas de cada atividade deste processo, o plano de projeto é apenas organizado utilizando o template padrão de plano de projeto, fornecido pelo Escritório de Projetos.
4.1.1.14
Plano do Projeto
Descrição
O plano de projeto satisfaz às seguintes evidencias do MPS.BR nível G: - GPR 4 (parcialmente): Seções "Velocidade do time" e "Cronograma"; - GPR 6: Seção "Tabela de riscos" - GPR 7: Seção "Recursos Humanos" - GPR 9 (parcialmente): Todo o Plano; - GPR 10: todo o Plano; - GPR 11: Seção "Avaliação de Viabilidade"; - GPR 12: Seção "Assinaturas"; - GPR 13: todo o plano atualizado; - RAP 5: Seção "Recursos Humanos"; - RAP 6: Seção "Recursos Humanos".
URL
https://sistemas.uff.br/sti/redmine/documents/48
4.1.1.15
Event
4.1.1.16
Vai gerar receita?
4.1.1.17
Planejar riscos
Processo
Planejar Riscos - Processo principal
4.1.1.18
Avaliar a viabilidade do projeto
Descrição Entradas:
- Plano de Projeto e seus anexos; Ferramentas: - Avaliação técnico-gerencial; - Avaliação de negócio; Saídas:
- Aprovação da viabilidade do projeto e assinatura da respectiva seção do Plano de Projeto;
Descrição:
Este é o único marco formal do processo. Com base nos resultados de planejamento e no alinhamento com a organização, o Escritório de Projetos atesta a viabilidade ou não do projeto. Se necessário, pode-se solicitar alterações no planejamento para torná-lo viável.
4.1.1.19
Assinar o plano de projeto
Descrição
O Plano de Projeto deve ser assinado por: - Cliente
4.1.1.20
Obter comprometimento da equipe
Descrição
Os membros do projeto devem assinar um termo de comprometimento, no Redmine, declarando estar de acordo com os critérios definidos no Plano do Projeto e comprometendo-se com a sua execução.
4.1.1.21
Fim da fase de planejamento
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
5.1
Processo principal
5.1.1
Elementos do processo
5.1.1.1
Atividade Técnica
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
6.1
1.4 Execução do Sprint
6.1.1
Elementos do processo
6.1.1.1
Event
Descrição
Neste processo, as ferramentas adequadas devem ser utilizadas para o desenvolvimento e implementação dos requisitos acordados na reunião de planejamento. A equipe do projeto e somente ela é responsável pela implementação dos requisitos. Caso surja algum impedimento à execução destas tarefas, ele deve ser reportado na reunião diária ou o mais breve possível ao líder do projeto.
6.1.1.2
Buscar tarefa
Descrição
O desenvolvedor deve acessar o Redmine em busca de tarefas. Devem ser realizadas as tarefas do requisito mais importante (prioritário).
6.1.1.3
Atualizar espaço de trabalho
Descrição
O desenvolvedor deve atualizar sua área de trabalho com o projeto, de acordo com a ferramenta de controle de versão utilizada. Ver Plano de Gerência de Configuração.
6.1.1.4
Desenhar solução (código e teste)
Descrição
Partindo da especificação do requisito e dos critérios de aceitação, deve-se desenhar a solução, que envolve a arquitetura e os testes.
A arquitetura deve seguir as seguintes diretrizes: a) Minimizar o acoplamento entre as classes.
b) Maximizar a coesão dos componentes. c) Maximizar o reuso:
- pode-se utilizar alguma parte já existente do sistema? - pode-se utilizar alguma biblioteca já existente?
- pode-se utilizar um serviço e dados já existentes de outro sistema? d) Manter a documentação atualizada (Wiki do projeto no redmine) - Diagrama de classes
- Processo de negócios (Bizagi ou diagrama de atividades) - Prototipação das telas
- Manual de uso
Os testes devem seguir as seguintes diretrizes:
a) Deve existir um teste de aceitação para cada cenário (principal ou alternativo) ou comportamento do requisito.
b) Deve existir um teste unitário para cada regra do requisito.
6.1.1.5
Implementar solução
Descrição
Nesta atividade será realizada a implementação da solução para que a tarefa seja concluída e o requisito possa ser entregue. Caso o desenvolvedor precise de ajuda, por não saber como alcançar uma solução, os seguintes passos podem ser seguidos:
1. Buscar soluções na base de conhecimento; 2. Pesquisar soluções;
3. Perguntar aos outros desenvolvedores e/ou líderes técnicos;
4. Avisar do impedimento ao Líder Técnico, Scrum Master ou Gerente do Projeto; 5. Apresentar impedimento na reunião diária.
6.1.1.7
A solução está suficiente?
Descrição
A solução é suficiente quando: - Os testes estão passando; - A cobertura de testes segue o definido para o projeto; - O padrão de codificação foi seguido; - A documentação (técnica e de uso) está atualizada; - A funcionalidade desenvolvida atende ao requisito correspondente.
6.1.1.8
Publicar solução
Descrição
As diretrizes para a publicação das soluções produzidas estão definidas pelo Plano de Gerência de Configuração da STI. É importante considerar o fim a que se propõe solução em cada estágio da execução do projeto, podendo ser:
- apenas uma versão prévia de software não-habilitado a operar em produção, chamada "Preview"
- uma candidata a liberação, pronta para validação pelo Cliente e, se aprovada, capaz de operar em produção. É chamada "Release Candidate"
- uma versão estável aprovada pelo cliente do projeto e que será disponibilizada em produção, chamada "Release"
Além disso, deve-se documentar as atividades realizadas por meio das tarefas e requisitos registrados no Redmine.
6.1.1.9
Executar testes automatizados
Descrição
Esta tarefa é executada pelo Jenkins todas as vezes que um código é armazenado no repositório central do projeto. Os testes automatizados são executados e seu resultado é coletado. Além disso, são extraídas duas métricas: testes executados com sucesso, e percentual de cobertura de código.
Implementação Serviço Web
6.1.1.10
Há tarefas abertas no backlog sprint?
6.1.1.11
Ao finalizar uma tarefa o desenvolvedor deve verificar se ainda há tarefas a serem executadas no Backlog do Sprint, consultando-o no Redmine.
6.1.1.12
Event
6.1.1.13
Realizar Reunião diária
Descrição
A reunião diária é realizada no mesmo horário em cada dia e seu objetivo é acompanhar e controlar o andamento do Sprint. Nesta reunião são identificados ou reportados os impedimentos que não permitem a implementação dos requisitos ou atrapalham a produtividade da equipe de desenvolvimento. Esta reunião deve durar no máximo 15 minutos, independente do número de membros participantes da mesma. Nela, cada membro do time de desenvolvimento deve responder a três perguntas: 1. O que foi feito desde a última reunião de acompanhamento ou planejamento de sprint, caso seja a primeira reunião; 2. O que será feito até a próxima reunião de acompanhamento ou término do sprint, caso seja a última reunião; 3. Quais problemas ou impedimentos estão atrapalhando o time a implementar os requisitos. Esta reunião deve ser realizada em pé ao lado do quadro SCRUM ou monitor com Redmine (quando o time não estiver usando um quadro SCRUM ainda). As perguntas devem ser respondidas para o time e não para o líder do projeto apenas, afinal todo o time está comprometido com os objetivos e requisitos definidos no início do Sprint. Durante a reunião diária, cada membro deve atualizar a situação das suas tarefas no quadro SCRUM. E ao final dela, o líder do projeto deve atualizar no Redmine a situação das tarefas. Todos os membros devem ajudar o líder do projeto a manter o Redmine atualizado, com as situações das suas tarefas.
6.1.1.14
Event
6.1.1.15
No horário combinado
6.1.1.16
Atividade Gerencial
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
7.1
Processo principal
7.1.1
Elementos do processo
7.1.1.1
Atividade Gerencial
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
1.6 Acompanhamento de Projeto
8.1.1
Elementos do processo
8.1.1.1
Fim do Sprint
Descrição
Este processo é executado a cada 15 dias (período de um Sprint) ou quando terminar o Sprint (no final do ano, normalmente, temos um Sprint de uma ou três semanas).
8.1.1.2
Preparar RA
Descrição
O gerente do projeto deve preencher o Relatório de Acompanhamento, com base no template disponibilizado pelo PMO.
8.1.1.3
Envia ao PMO
Descrição
Importante: o RA deve ser enviado antes da Reunião de Acompanhamento. Cada gerente possui sua agenda de reuniões com o PMO.
8.1.1.4
Enviar Resumo de Acompanhamento e Gantt ao Diretor e Equipe
Descrição
O PMO relata o progresso dos projetos para o Diretor da CDS e para Equipe do Projeto através do Resumo de acompanhamento e o cronograma do projeto atualizado.
As notícias coletadas nas reuniões de acompanhamento passam por uma triagem do PMO e são divulgadas apenas internamente ou interna e externamente, pela equipe de mídia e supervisionadas pelo PMO.
8.1.1.6
Email com notícia dos projetos
Descrição
Equipe de Comunicação envia e-mail interno com notícias dos projetos.
8.1.1.7
Relatório de Acompanhamento
URL
Relatório de Acompanhamento
8.1.1.8
Atualizar o Redmine com o review
Descrição
A atividade de atualização do Redmine com o review envolve um esforço do gerente para conferir os status, estimativas e possíveis notas dos tickets, de modo a deixá-los conforme a realidade do projeto.
Observação: requisitos que não foram concluídos devem seguir no Sprint, de modo a possibilitar um acompanhamento mais real possível por parte do PMO.
8.1.1.9
Extrair e armazenar resumo de review
Descrição
Essa atividade consiste na extração do relatório "Sprint Review" do Redmine do projeto e no devido armazenamento no repositório do Escritório de Projetos.
- Resumo de Review -> "SCRUM: Sprint Review"
Os documentos são armazenados no repositório do Escritório do PMO.
8.1.1.10
Atualizar Cronograma do projeto do PMO
Descrição
A equipe do PMO deve atualizar o quadro de cronogramas e o Gantt de projetos, levando em consideração o progresso em requisitos (requisitos entregues / requisitos totais).
Gantt
Gantt
8.1.1.11
Atualizar o Redmine com o planning
Descrição
Após (ou durante) o Sprint Planning com o cliente, o Redmine deve ser atualizado, principalmente no que concerne ao cronograma. Ou seja, é revisto o planejamento do projeto.
8.1.1.12
Extrair e armazenar resumo de planning e cronograma
Descrição
Essa atividade consiste na extração do relatório "Sprint Planning" do Redmine do projeto e no devido armazenamento no repositório do Escritório de Projetos.
8.1.1.13
Reunião de acompanhamento
Descrição
A Reunião de Acompanhamento é realizada entre PMO e gerente do projeto, orientada pela discussão de cada item do relatório de acompanhamento. É um ponto importante de checagem do cumprimento do processo e de identificação de demandas que precisem do apoio direto do PMO na sua solução.
8.1.1.14
Gerar Resumo de Acompanhamento
Processo
Gerar Resumo de Acompanhamento - Processo principal
8.1.1.15
Realizar avaliação do Acompanhamento
Descrição
O PMO realizar uma reunião de avaliação para validar os resultados do Resumo de acompanhamento para divulgação das métricas.
Template do Resumo de Acompanhamento. Este documento está dividido pelas seguintes seções:
• Informações gerais
• Qualidade e indicadores (produtividade, situação e velocidade do time) • Não conformidades
• Progresso
• Evolução do projeto • Riscos
o Riscos críticos para Direção o Impedimentos
• Escopo
O documento pode ser acessado em: https://sistemas.uff.br/sti/redmine/documents/144
8.1.1.17
PMO
8.1.1.18Gerente
8.1.1.19Pré-acompanhamento
8.1.1.20Acompanhamento
8.1.1.21Pós-acompanhamento
8.2
Processo principal
8.2.1
Elementos do processo
8.2.1.1Atividade Técnica
8.2.1.2Atividade Gerencial
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
9.1
1.7 Encerramento do Projeto
9.1.1
Elementos do processo
9.1.1.1
Realizar reunião de encerramento do projeto
Descrição
A reunião de encerramento de projeto tem presença das partes interessadas (Escritório de Projetos, Diretor da CDS, cliente, PO, gerente do projeto, equipe do projeto e equipe de comunicação).
Este evento ocorre para que se formalize o término do projeto e seja assinado o Termo de Encerramento.
9.1.1.2
Termo de encerramento do projeto assinado
Descrição
Modelo do Termo de Encerramento de Projeto da STI. Possui as seguintes seções:
• Informações gerais • Produtos finais do projeto
• Motivos para encerramento do projeto • Aceite do Patrocinador do Projeto • Assinaturas
Pode ser acessado em: https://sistemas.uff.br/sti/redmine/documents/128
9.1.1.3
Confeccionar Termo de Encerramento
Descrição
O gerente deve confeccionar o termo de encerramento do projeto com base no modelo definido pelo Escritório de Projetos.
9.1.1.4
Fechar o projeto no Redmine
Descrição
Deve-se fechar o projeto no Redmine, o que o torna inacessível para alterações e edições, mas ainda disponível para leitura.
9.1.1.5
Criar a operação no Redmine se necessário
Descrição
A operação do Redmine é a área de gestão da manutenção do código e é nela que devem ser registrados bugs, pequenas melhorias e inconformidades.
Após a solução estar finalizada e em produção, deve-se criar uma área interna à "Operações" do modo "Operação:".
Caso o projeto tenha sido foco apenas de refatorações e/ou melhorias, ou seja, refino de uma solução já existente, a nova área não deve ser criada.
9.1.1.6
Event
9.1.1.7
Notificação do término do projeto ao PMO
Descrição
Esta comunicação pode ocorrer durante o acompanhamento de projetos ou não. O gerente apenas deve informar o término do projeto para que o Escritório de Projetos inicie as verificações necessárias ao encerramento formal o mesmo.
9.1.1.8
Verificar Não Conformidades
Descrição
Esta atividade consiste na verificação dos itens auditáveis da fase de encerramento e da revisão dos demais itens auditáveis, já verificados ao longo projeto.
9.1.1.9
Há NC pendente?
Descrição
9.1.1.10
Validar termo de encerramento
Descrição
O Escritório de Projetos revisa o termo de encerramento antes de sua assinatura.
9.1.1.11
Armazenar documento de encerramento
Descrição
O PMO armazena o documento digitalizado no repositório de documentos.
9.1.1.12
Elaborar resumo de encerramento
Descrição
Após o encerramento do projeto o Escritório de Projetos elabora o Resumo de Encerramento do Projeto, que consolida as informações acerca do mesmo com base nos indicadores definidos no Plano de Medição. Este resumo é enviado à alta gestão da STI.
9.1.1.13
Enviar questionário de satisfação ao Cliente/PO
Descrição
O PMO deve enviar ao cliente e PO o questionário de satisfação. Uma vez respondido, é armazenado no repositório de documentos.
9.1.1.14
Event
9.1.1.15
Analisar Não Conformidades
Processo
4. Analisar não conformidades - Processo principal
9.1.1.16
Modelo de Termo de Encerramento
URL
9.1.1.17
Modelo de Resumo de Encerramento
URL
Modelo de Resumo de Encerramento
9.1.1.18
Formulário de satisfação do cliente
URL
Formulário de satisfação do cliente
9.1.1.19
Gerente
9.1.1.20
Escritório de Projetos
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
10.1
3. Scrum
10.1.1
Elementos do processo
10.1.1.1Sprint Planning
10.1.1.2Desenvolvimento diário
10.1.1.3Reunião diária
10.1.1.4Review
10.1.1.5Retrospectiva
10.1.1.6Event
10.1.1.7Gateway
10.1.1.8Gateway
10.1.1.9
Product Backlog completo?
10.1.1.12
Execução
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
11.1
Cadastro de risco Redmine
11.1.1
Elementos do processo
11.1.1.1
Event
11.1.1.2
Verificar se o risco já está cadastrado
Descrição
Essa etapa consiste em pesquisar na Base de Conhecimento (BC) se o risco identificado já está cadastrado.
11.1.1.3
Risco cadastrado?
11.1.1.4
Incluir um novo risco
Descrição
O gerente criará um ticket em seu projeto do Tipo "Risco", adicionando as informações pertinentes (probabilidade, impacto, categoria, etc.)
11.1.1.5
Avaliar o risco
Descrição
O Escritório de Projetos avalia o risco cadastrado para verificar a coerência da categorização, as ações de resposta e a exposição.
11.1.1.6
Aprovado?
11.1.1.7
Cadastrar risco na Base de Conhecimento
Descrição
A partir de um risco já identificado por um gerente, o Escritório de Projetos o copia para a Base de Conhecimento e associa ao risco do projeto, excluindo informações específicas do mesmo. Este novo risco estará disponível para ser utilizado por outros projetos.
Esse risco deve ser preenchido na BC da seguinte forma: Tipo: Risco
Título, Descrição, Situação: A fazer, Prioridade: Normal, Impacto: Característico de cada projeto, Probabilidade: Característico de cada projeto, Contenção: ---, Contingência: ---, Categoria: preencher de acordo com a EAR (por exemplo, Pessoal), Subcategoria: preencher de acordo com a EAR (por exemplo, Rotatividade), Exposição: 0
11.1.1.8
Event
11.1.1.9
Rejeitar o risco
Descrição
Um risco só é rejeitado caso não deva ser considerado como tal, por não corresponder ao conceito de risco.
11.1.1.10
Copiar o risco
Descrição
Copiar o risco cadastrado na Base de Conhecimento para o projeto. Preencher todos os campos do risco. Não modificar sua categoria e subcategoria.
11.1.1.11
Associar os riscos
Descrição
Após copiar o risco para o projeto, é necessário associá-lo ao que está na Base de Conhecimento, por meio da adição de uma "tarefa relacionada".
11.1.1.12
Gerente
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
12.1
5. Processo de Liberação
12.1.1
Elementos do processo
12.1.1.1
Event
Descrição
O gerente informa a data prevista para liberação.
12.1.1.2
5.1 Realizar auditoria pre-liberação
Descrição
O PMO realiza uma auditoria de pré-liberação na Baseline gerada. Na auditoria verifica-se se as atividades realizadas estão de acordo com as diretrizes do Plano de GC.
Processo
5.1 Realizar auditoria pre-liberação - Processo principal
12.1.1.3
Aprovada?
Descrição
A gerência técnica emite um parecer sobre a auditoria.
12.1.1.4
5.2 Realizar liberação
Descrição
Quando aprovada, a baseline pode ser liberada. O gerente realiza o deploy em produção, disponibilizando o sistema para o cliente.
12.1.1.5
5.3 Realizar auditoria pos-liberação
Descrição
Após a liberação, o PMO realiza uma auditoria para verificar se as atividades foram realizadas de acordo com as diretrizes do plano de GC.
Processo
5.3 Realizar auditoria pos-liberação - Processo principal
12.1.1.6
Event
12.1.1.7
Realizar ajustes
Descrição
Quando a baseline for reprovada para liberação, o gerente deve realizar os ajustes necessários de acordo com as recomendações da auditoria.
12.1.1.8
Informar liberação
Descrição
Após a realização dos ajustes, o gerente informa a previsão de liberação.
12.1.1.9
Gerente
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
13.1
4. Analisar não conformidades
13.1.1
Elementos do processo
13.1.1.1
Event
13.1.1.2
Identificar a NC
Descrição
As Não Conformidades serão identificadas através do relatório e reunião de acompanhamento.
13.1.1.3
Cadastrar NC
Descrição
Cadastrar no Redmine uma tarefa do tipo "Não Conformidade" no determinado projeto.
13.1.1.4
Analisar NC
Descrição
Identificar o código, critério e categoria de acordo com o Plano de Qualidade.
13.1.1.5
Ação corretiva necessária ?
13.1.1.6
Registrar motivação da decisão tomada
Descrição
13.1.1.7
Event
13.1.1.8
Definir ação corretiva
Descrição
Definir que ações corretivas são necessárias para a solução da não conformidade associada.
13.1.1.9
Cadastrar Ação corretiva
Descrição
Criar uma tarefa no Redmine do tipo Ação Corretiva. Filiar essa tarefa com o número do ticket da não conformidade.
13.1.1.10
Definir responsável pela Ação Corretiva
Descrição
Cada tipo de não conformidade possui um responsável pela solução.
13.1.1.11
Monitorar a implementação
Descrição
A cada Sprint as não conformidades são monitoradas para acompanhar suas soluções.
13.1.1.12
Analisar eficácia
Descrição
Analisar se as ações corretivas foram suficientes para solucionar a não conformidade.
13.1.1.13
Foi eficaz?
13.1.1.15
Finalizar não conformidade
Descrição
O Escritório de Projetos verifica a solução das ações corretivas e atualiza o ticket da não conformidade no Redmine como "Pronto".
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
14.1
Gerar Resumo de Acompanhamento
14.1.1
Elementos do processo
14.1.1.1
Event
14.1.1.2
Avaliar progresso e qualidade do projeto
14.1.1.3
Analisar Não Conformidades
Processo
4. Analisar não conformidades - Processo principal
14.1.1.4
Analisar Riscos
Processo
Analisar Riscos - Processo principal
14.1.1.5
Analisar impedimentos
Processo
Analisar impedimentos - Processo principal
14.1.1.6
Analisar Desvios
Processo
14.1.1.7
Gerar gráficos e preenher resumo
Descrição
Com base nas informações do acompanhamento, gerar os gráficos de indicadores e preencher o resumo de acompanhamento.
14.1.1.8
Event
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
15.1
5.3 Realizar auditoria pos-liberação
15.1.1
Elementos do processo
15.1.1.1
Event
15.1.1.2
Verificar se a baseline de produção foi gerada
Descrição
O PMO verifica se a Baseline foi gerada no branch Produção, seguindo o padrão de numeração de versão definido no plano de GC.
15.1.1.3
Verificar a criação da documentação
15.1.1.4
Certificar a ocorrência da liberação
Descrição
O PMO deve verificar se o Sistema foi liberado em produção.
15.1.1.5
Certificar que os interessados foram comunicados
Versão: 1.0
Autor: Escritório de Gerenciamento de Projetos - STI - UFF
16.1
5.2 Realizar liberação
16.1.1
Elementos do processo
16.1.1.1
Event
16.1.1.2
Gerar Baseline de produção
Descrição
O Gerente deve gerar uma Baseline, branch Produção, seguindo o padrão de numeração de versão definido no plano de GC.
16.1.1.3
Gerar documentação da versão liberada
Descrição
A documentação referente à versão liberada (Data, Versão, Funcionalidades) deve ser registrada na Wiki do Projeto.
16.1.1.4
Realizar deploy em produção
Descrição
O gerente deve realizar deploy no ambiente de produção, disponibilizando o sistema para uso pelo Cliente.
16.1.1.5
Comunicar a todos os interessados
Descrição
O gerente deve comunicar a liberação a todos os interessados.
