Upload
giovana-unbehaun
View
460
Download
5
Embed Size (px)
DESCRIPTION
Utilizando o Software Channel, da Jexperts, você garante uma implementação 100% embasada nas melhores práticas de mercado para Mps.Br.
Citation preview
Boas práticas para implementação do MPS.Br níveis G e F utilizando a
Plataforma Channel
Boas Práticas – MPS.Br Níveis G e F
• Nível G – Parcialmente Gerenciadoo GPR – Gerência de projetoso GRE – Gerência de requisitos
• Nível F – Gerenciadoo AQU – Aquisiçãoo GCO - Gerência de configuraçãoo GQA – Garantia da qualidadeo MED - Medição
MPS.Br G – Gerência de Projetos - GPR
• Propósito:
o O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. O propósito deste processo evolui à medida que a organização cresce em maturidade.
GPR 1. O escopo do trabalho para o projeto está definido
• Estabeleça um processo que auxilie sua equipe na definição do escopo de trabalho para o projeto, identificando as necessidades do cliente e promovendo a rastreabilidade entre o requisito de negócio e o pacote de trabalho na EAP do projeto
Boa prática - GPR 1: Defina um processo e suas atividades
Boa prática - GPR 1: Para apoiar o processo, crie formulários para mapeamento das necessidades do cliente e definição do escopo do projeto
GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados
• Defina um método de estimativa objetivo e institucional. Estabeleça instrumentos para auxiliar sua equipe durante esta atividade de estimativa e garanta que esse método esteja mapeado em seu processo;
• É importante que o histórico de mudanças das estimativas bem como a rastreabilidade entre os R.N. e os produtos de trabalho seja garantido.
Boa prática - GPR 2
GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos
• Defina um template padrão de EAP para os projetos da sua empresa e certifique-se que ele contenha as fases do ciclo de vida definidas em seus processo institucional
• Sugestão: O processo de definição do escopo do projeto, apresentado anteriormente, pode fazer parte do ciclo de vida. Normalmente ele implementa as atividades contidas na fase de iniciação de um ciclo de vida tradicional de um projeto.
Boa prática - GPR 3
GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas
• Utilize um método baseado em dados históricos ou referências técnicas para estimar o esforço e o custo das atividades/tarefas do seu projeto. A base de cálculo deve ser anexada a atividade para análises futuras
Boa prática – GPR 4
GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos
• Defina o cronograma do projeto, evidenciando as fases, os marcos, os pacotes de trabalho, as atividades e tarefas com suas respectivas datas, duração e orçamento (valor planejado).
Boa prática – GPR 5
GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados
• Os riscos do projeto devem ser identificados e monitorados durante toda a execução do projeto. As ações para tratar o risco também deve ser mapeada e mantida.
Boa prática – GPR 6
Boa prática – GPR 6
GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo
• Defina um plano de gerenciamento de RH e garanta que este plano seja evidenciado no projeto e conhecido/seguido por todos da equipe.
Boa prática – GPR 7
Boa prática – GPR 7
GPR 8. Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados
• Defina um plano de gerenciamento dos recursos e do ambiente de trabalho e garanta que este plano seja evidenciado no projeto e conhecido/seguido por todos da equipe.
Boa prática – GPR 8
GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança
• Os dados relevantes do projeto devem ser organizados em um repositório de forma que fiquem disponíveis para as pessoas corretas obedecendo as políticas de privacidade e segurança
Boa prática – GPR 9
GPR 10. Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos
• Faça a geração do plano do projeto que integre todos os planos do projeto em um único plano. Além disso, sempre que uma nova linha de base é gerada, uma versão do plano do projeto é congelada e pode ser usada como referência para consulta posterior.
Boa prática – GPR 10
Boa prática – GPR 10IMPORTANTE: Garanta que todos os planos sejam criados durante a fase de planejamento e que suas evidências sejam armazenadas junto ao projeto
GPR 11. A viabilidade de atingir as metas do projeto é explicitamente avaliada considerando restrições e recursos disponíveis. Se necessário, ajustes são realizados
• A análise de viabilidade do projeto deve ser realizada e sua evidência anexada ao processo. Durante a execução do projeto a análise pode ser reavaliada e o histórico de reavaliação deve ser mantido.
Boa prática – GPR 11
GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido e mantido
• O plano do projeto deve ser revisado com toda equipe e o comprometimento da equipe com o projeto deve ser registrado. Faça uma reunião de kickoff do projeto e registre uma ata, tanto da revisão do planejamento do projeto, quanto do comprometimento da equipe com a execução do mesmo.
IMPORTANTE:
• (a) Como item da ata, deixe evidenciado claramente: “O plano do projeto foi revisado com todos os membros da equipe do projeto e os mesmos se comprometeram com o desenvolvimento do escopo do projeto e com os prazos apresentados”.
• (b) Todos os participantes da reunião devem apontar horas no respectivo item de escopo (ex. Reunião de kickoff do projeto)
Boa prática – GPR 12
Boa prática – GPR 12
GPR 13. O escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado
• O gerente do projeto deverá utilizar de relatórios e gráficos para auxiliá-lo no monitoramento do projeto (gráfico de gantt, relatórios previsto x real, relatório de status do projeto). Através desses relatórios é possível monitorar o planejado, o realizado e a variação entre ambos.
IMPORTANTE: O gerente do projeto deve evidenciar este monitoramento através de apontamentos de horas sobre um atividade do projeto (ex.: Monitoramento e controle do projeto)
Boa prática – GPR 13
Boa prática – GPR 13
Boa prática – GPR 13
GPR 14, 15, 16 e 17. Os recursos materiais e humanos bem como os dados relevantes do projeto são monitorados em relação ao planejado; Os riscos são monitorados em relação ao planejado; O envolvimento das partes interessadas no projeto é planejado, monitorado e mantido; Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento
• O monitoramento e controle de recursos, riscos, comunicação e revisões pode ser feito através de status report periódicos (semanal, quinzenal...). Outra prática é o registro e acompanhamento de problemas (issues).
Boa prática – GPR 14, 15, 16 e 17
Boa prática: Gere um status reporte semanal e armazene o mesmo na base de documentos do projeto. Desta forma é possível armazenar o histórico do projeto.
O gerente do projeto deve evidenciar este acompanhamento através de apontamentos de horas sobre um atividade do projeto (ex.: Monitoramento e controle do projeto ou geração de status report)
Boa prática – GPR 14, 15, 16 e 17
GPR 18 e 19. Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas; Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão
• Para estes dois itens, é necessário fazer o registro dos problemas das ações corretivas necessárias para a correção do problema.
Boa prática – GPR 18 e 19
MPS.Br G – Gerência de Requisitos - GRE
• Propósito:
o O propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.
GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos
• Utilize uma ferramenta case (ex.: Enterprise Architect) para especificação dos requisitos do projeto e encaminhe para seu cliente as referidas especificações para validação.
• Boa prática: Envie o documento de especificação através de um e-mail e obtenha, de maneira formal, a validação/entendimento dos requisitos por parte do fornecedor de requisitos
Boa prática - GRE 1: Defina e explicite no projeto quem será o fornecedor de requisitos
Boa prática - GRE 1: Encaminhe o documento de requisitos para o Fornecedor fazer a validação. Não esqueça de obter a validação formalizada em um e-mail
Boa prática - GRE 1: Anexe o documento de especificação e o e-mail de validação como uma evidencia do projeto na base de documentos
GRE 2. Os requisitos são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com estes requisitos é obtido
• Faça uma reunião entre o analista de requisitos e a equipe do projeto. Nesta reunião é feita a apresentação do documento de requisitos, a equipe faz o entendimento e se compromete formalmente com o desenvolvimento dos mesmos
• Anexe o conteúdo desta reunião junto ao projeto como uma evidência
Boa prática - GRE 2: Reunião de apresentação de avaliação dos requisitos junto a equipe do projeto
É importante registrar o entendimento e o comprometimento da equipe bem como garantir que todos os participantes da reunião façam o apontamento de horas sobre a atividade correspondente
no cronograma do projeto
Sugestão de texto para evidenciar o entendimento e o comprometimento da equipe: “A equipe do projeto fez o entendimento e a validação dos requisitos apresentados e se comprometeram com o desenvolvimento dos mesmos e com os prazos apresentados no cronograma."
Boa prática - GRE 2: Use critérios objetivos para avaliar os requisitos junto a equipe
• Critérios objetivos:• Checklist de validação
o O requisito está claro ?o O requisito é atômico ?o O requisito é contraditório ?
• Revisão aos pares• Análise de complexidade (usando método
Delphi, por exemplo - http://pt.wikipedia.org/wiki/M
%C3%A9todo_Delphi)
GRE 2 - IMPORTANTE: Solicitação de mudanças
• Sempre que uma mudança nos requisitos é feita pelo fornecedor de requisitos, um processo de solicitação de mudanças deve ser executado e as práticas do GRE 2 devem ser refeitas sobre aqueles requisitos que sofreram a mudança (ou sobre aqueles requisitos que foram adicionados no projeto).
Boa prática - GRE 2: Processo de Solicitação de Mudanças
• Estabeleça um processo que auxilie sua equipe na definição do escopo de trabalho para o projeto, identificando as necessidades do cliente e promovendo a rastreabilidade entre o requisito de negócio e o pacote de trabalho na EAP do projeto
• Garante que as horas investidas neste processo sejam devidamente registradas no cronograma do projeto em uma atividade correspondente (ex.: Gestão e controle de mudanças do projeto)
Boa prática - GRE 2: Processo de Solicitação de Mudanças
Boa prática - GRE 2: Para apoiar o processo, crie um formulário para registro das necessidades do cliente e definição da mudança
Boa prática - GRE 2: Linha de base do projeto
• Após a aprovação e a aplicação da mudança no projetos (atualização da especificação, atualização do cronograma, execução das devidas reuniões de apresentação da mudança para equipe), é fundamental que uma nova linha de base seja gerada para o projeto.
Boa prática - GRE 2: Linha de base do projeto
GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida
• Utilize uma ferramenta case (ex.: Enterprise Architect) que disponibilize algum instrumento de rastreabilidade entre os elementos utilizados para especificação dos requisitos (e: Matriz de rastreabilidade)
• A rastreabilidade deverá ser promovida desde o registro da nova demanda até o código gerado para desenvolvimento desta demanda.
Boa prática - GRE 3: Promovendo a rastreabilidade entre o registro da demanda e o código-fonte.
Processo de registroda nova demanda
Especificação dosrequisitos
Código FonteProjeto
Utilize um prefixo no nome do requisito de negócio para que seja possível promover a rastreabilidade.
Ex.: RN.001 – Nome do requisito de negócio
Os requisitos funcionais e os não funcionais gerados a partir dos requisitos de negócio podem ter o prefixo: RF.001.1 – Nome do requisito não funcional (RNF.001.1 para os requisitos não funcionais). Neste caso o código 001 indica que esse requisito funcional é um requisito derivado do requisito de negócio 001.
No cronograma do projeto, as atividades (e tarefas) também conterão um prefixo que promova a rastreabilidade: “AT.001.1.1 – Nome da atividade”Neste caso o código 001.1 indica que essa é uma atividade ligada ao requisito funcional 1 do requisito de negócio 001.
A rastreabilidade entre o código-fonte e os requisito dar-se-á pelo nome da classe na ferramenta IDE (e: Eclipse) e o nome da classe no modelo de classes da especificação do requisito na ferramenta case (e: EA)
GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos
• Garanta que os planos e produtos de trabalho do
projeto sejam revisados e quando alguma
inconsistência é encontrada, registre a mesma e
promova ações para resolver tais problemas.
Boa prática – GRE 4:
• Armazene a ata de reunião de kickoff do projeto, onde a
equipe validou os requisitos e se comprometeu com o
desenvolvimento dos mesmos
• Registre toda solicitação de mudança e garanta que o
projeto reflita essa mudança caso aprovada
• Registre no projeto todos os problemas e as ações para
resolver esses problemas (com datas e responsáveis)
• Garanta que os envolvidos, tanto na reunião de kickoff,
quanto no processo de mudança de requisitos façam os
apontamentos de horas nas respectivas atividades do
projeto.
Boa prática – GRE 4:
GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto
• Garanta que toda mudança siga o processo de solicitação
de mudanças e que, após a atualização do projeto em
função da mudança, uma nova linha de base seja gerada.
• É importante guardar a evidência que mostra a validação
e aceitação do fornecedor de requisitos para cada
solicitação de mudança realizada no projeto.
• Importante: Os envolvidos neste processo devem apontar
horas nas respectivas atividades do projeto.
Boa prática – GRE 5:
MPS.Br Nível G – Capacidade do Processo
• CAPACIDADE DO PROCESSO
o A capacidade do processo é representada por um conjunto de atributos de processo descrito em termos de resultados esperados;
o Os diferentes níveis de capacidade dos processos são descritos por nove atributos de processo (AP);
o O alcance de cada atributo de processo é avaliado utilizando os respectivos resultados esperados de atributo de processo (RAP).
MPS.Br Nível G – Capacidade do Processo
• AP 1.1 O processo é executado• Este atributo evidencia o quanto o processo atinge o
seu propósito.
• Resultado esperado:• RAP 1. O processo atinge seus resultados definidos.
Todas as evidências apresentadas anteriormente asseguram que o processo transforma produtos de trabalho de entrada identificáveis em produtos de trabalho de saída, também identificáveis.
MPS.Br Nível G – Capacidade do Processo
• AP 2.1 O processo é gerenciado• Este atributo evidencia o quanto a execução do
processo é gerenciada.
• Resultado esperado:• RAP 2. Existe uma política organizacional estabelecida
e mantida para o processo
A política organizacional deve ser definida, mantida e disponibilizada para todos da empresa. Crie um plano de comunicação da política para todos os colaboradores da empresa e evidencie que esse plano foi executado (crie um plano com ações no Channel, por exemplo) e garanta que todos apontaram horas para evidenciar sua participação neste plano.
MPS.Br Nível G – Capacidade do Processo
• AP 2.1 O processo é gerenciado• Este atributo evidencia o quanto a execução do
processo é gerenciada.
• Resultado esperado:• RAP 3. A execução do processo é planejada
Documente os processos organizacionais (nova demanda, solicitação de mudança, gestão de projetos...) e depois demostre que os processos são implementados e executados através dos artefatos produzidos no Channel (processos, formulários, cronograma do projeto, marcos de controle, planos e apontamentos de horas da equipe)
MPS.Br Nível G – Capacidade do Processo
• AP 2.1 O processo é gerenciado• Este atributo evidencia o quanto a execução do
processo é gerenciada.
• Resultado esperado:• RAP 4. A execução do processo é monitorada e ajustes
são realizados
Demostre, através dos status reports gerados e armazenados no projeto dentro do Channel, bem como o apontamento de horas na atividade de “Monitoramento e Controle do Projeto” que a execução do processo é monitorada. Os ajustes podem ser demonstrados através de questões pendentes e suas ações. Apresente também o cronograma com o número de horas realizadas e o percentual de conclusão do projeto.
MPS.Br Nível G – Capacidade do Processo
• AP 2.1 O processo é gerenciado• Este atributo evidencia o quanto a execução do
processo é gerenciada.
• Resultado esperado:• RAP 5. As informações e os recursos necessários para
a execução do processo são identificados e disponibilizados
• Crie um inventário de hardware e software institucional;
• Crie uma planilha com todos os papéis e competências disponíveis na empresa;
• Disponibilize esses documentos para todos da empresa e demostre, no cronograma do projeto, que os recursos contendo os papéis definidos nos documentos institucionais estão alocados no projeto
IMPORTANTE: Sobre RAP 5• Todos os documentos institucionais criados para atender
ao MPS.Br podem ser disponibilizados no Channel
IMPORTANTE: Sobre RAP 5• Garanta que todos os hardwares, softwares e os papéis e
competências utilizados nos projetos estão catalogados no documento institucional
MPS.Br Nível G – Capacidade do Processo
• AP 2.1 O processo é gerenciado• Este atributo evidencia o quanto a execução do
processo é gerenciada.
• Resultado esperado:• RAP 6. As responsabilidades e a autoridade para
executar o processo são definidas, atribuídas e comunicadas
Apresentar o termo de abertura do projeto, a relação dos papéis e atribuições do projeto e a ata da reunião de kickoff que poderá constar que “Todos os membros da equipe conhecem e concordam com o organograma do projeto, apresentado durante a reunião de kickoff”
MPS.Br Nível G – Capacidade do Processo
• AP 2.1 O processo é gerenciado• Este atributo evidencia o quanto a execução do
processo é gerenciada.
• Resultado esperado:• RAP 7. As pessoas que executam o processo são
competentes em termos de formação, treinamento e experiência
Crie um projeto no Channel para treinamento de todos os colaboradores a respeito dos processos institucionais relacionados ao MPS.Br. Todos devem apontar horas neste projeto para evidenciar a participação neste treinamento. Além disso, disponibilize o currículo de todos os colaboradores da base de documentos institucionais, dentro do Channel e certifique-se que os currículos dos colaboradores estejam alinhados aos seus papéis e suas competências do respectivo documento institucional.
MPS.Br Nível G – Capacidade do Processo
• AP 2.1 O processo é gerenciado• Este atributo evidencia o quanto a execução do
processo é gerenciada.
• Resultado esperado:• RAP 8. A comunicação entre as partes interessadas no
processo é planejada e executada de forma a garantir o seu envolvimento
Apresente o plano de comunicação do projeto, a evidência das trocas de e-mails com os fornecedores de requisitos e com demais stakeholders e os status reports.
MPS.Br Nível G – Capacidade do Processo
• AP 2.1 O processo é gerenciado• Este atributo evidencia o quanto a execução do
processo é gerenciada.
• Resultado esperado:• RAP 9. Os resultados do processo são revistos com a
gerência de alto nível para fornecer visibilidade sobre a sua situação na organização
Faça reuniões periódicas entre os gerentes de projetos e a direção da empresa para discutir melhorias e evoluções do processo. Registre as ações e decisões decorrentes destas reuniões e garanta que os participantes apontem horas para evidenciar a participação na reunião
Além disso, crie um projeto de implantação do MPS.Br no Channel e faça que todos os participantes apontem horas para evidenciar a execução do projeto
MPS.Br Nível G – Capacidade do Processo
• AP 2.1 O processo é gerenciado• Este atributo evidencia o quanto a execução do
processo é gerenciada.
• Resultado esperado:• RAP 10. O processo planejado para o projeto é
executado.
Apresente as atividades de Planejamento, Monitoramento e Controle do cronograma do projeto e seus respectivos apontamentos de horas (feito pelo gerente). Além dos apontamentos, apresente o número de horas realizadas e o percentual concluído do projeto
OBRIGADO
Tiago M. Fascin