Boas práticas para implementação Mps.br utilizando a ferramenta Channel

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