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

  • 341 views
Uploaded on

Utilizando o Software Channel, da Jexperts, você garante uma implementação 100% embasada nas melhores práticas de mercado para Mps.Br.

Utilizando o Software Channel, da Jexperts, você garante uma implementação 100% embasada nas melhores práticas de mercado para Mps.Br.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
341
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Boas práticas para implementação do MPS.Br níveis G e F utilizando a Plataforma Channel
  • 2. Boas Práticas – MPS.Br Níveis G e F • Nível G – Parcialmente Gerenciado o GPR – Gerência de projetos o GRE – Gerência de requisitos • Nível F – Gerenciado o AQU – Aquisição o GCO - Gerência de configuração o GQA – Garantia da qualidade o MED - Medição
  • 3. 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.
  • 4. 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
  • 5. Boa prática - GPR 1: Defina um processo e suas atividades
  • 6. 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
  • 7. 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.
  • 8. Boa prática - GPR 2
  • 9. 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.
  • 10. Boa prática - GPR 3
  • 11. 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
  • 12. Boa prática – GPR 4
  • 13. 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).
  • 14. Boa prática – GPR 5
  • 15. 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.
  • 16. Boa prática – GPR 6
  • 17. Boa prática – GPR 6
  • 18. 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.
  • 19. Boa prática – GPR 7
  • 20. Boa prática – GPR 7
  • 21. 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.
  • 22. Boa prática – GPR 8
  • 23. 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
  • 24. Boa prática – GPR 9
  • 25. 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.
  • 26. Boa prática – GPR 10
  • 27. Boa prática – GPR 10 IMPORTANTE: Garanta que todos os planos sejam criados durante a fase de planejamento e que suas evidências sejam armazenadas junto ao projeto
  • 28. 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.
  • 29. Boa prática – GPR 11
  • 30. 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.
  • 31. Boa prática – GPR 12 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)
  • 32. Boa prática – GPR 12
  • 33. 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)
  • 34. Boa prática – GPR 13
  • 35. Boa prática – GPR 13
  • 36. Boa prática – GPR 13
  • 37. 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).
  • 38. 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)
  • 39. Boa prática – GPR 14, 15, 16 e 17
  • 40. 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.
  • 41. Boa prática – GPR 18 e 19
  • 42. 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.
  • 43. 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
  • 44. Boa prática - GRE 1: Defina e explicite no projeto quem será o fornecedor de requisitos
  • 45. 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
  • 46. 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
  • 47. 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
  • 48. Boa prática - GRE 2: Reunião de apresentação de avaliação dos requisitos junto a equipe 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." É 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
  • 49. 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 Delphi, por exemplo http://pt.wikipedia.org/wiki/M%C3%A9todo_Delphi) método -
  • 50. 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).
  • 51. 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)
  • 52. Boa prática - GRE 2: Processo de Solicitação de Mudanças
  • 53. 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
  • 54. 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.
  • 55. Boa prática - GRE 2: Linha de base do projeto
  • 56. 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.
  • 57. Boa prática - GRE 3: Promovendo a rastreabilidade entre o registro da demanda e o código-fonte. 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” Os requisitos funcionais e os não Neste caso o código 001.1 indica que essa é uma funcionais atividade ligada ao requisito funcional 1 do gerados a partir dos requisitos de negócio podem requisito de Especificação dos ter o prefixo: RF.001.1 – Nome do requisito não negócio 001. requisitos funcional (RNF.001.1 para os requisitos não Processo de registro funcionais). Neste caso o código 001 indica que da nova demanda esse requisito funcional é um requisito derivado do A rastreabilidade entre o código-fonte e os requisito de negócio 001. requisito dar-se-á pelo nome Utilize um prefixo no nome do requisito de negócio da classe na ferramenta IDE (e: Eclipse) e o nome da classe no para que seja possível promover a rastreabilidade. modelo de classes da especificação do RN.001 – Nome do requisito de negócio Ex.: requisito na ferramenta case (e: EA) Projeto Código Fonte
  • 58. 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.
  • 59. 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.
  • 60. Boa prática – GRE 4:
  • 61. 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.
  • 62. Boa prática – GRE 5:
  • 63. 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).
  • 64. 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.
  • 65. 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.
  • 66. 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)
  • 67. 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.
  • 68. 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
  • 69. IMPORTANTE: Sobre RAP 5 • Todos os documentos institucionais criados para atender ao MPS.Br podem ser disponibilizados no Channel
  • 70. 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
  • 71. 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”
  • 72. 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.
  • 73. 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.
  • 74. 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
  • 75. 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
  • 76. OBRIGADO Tiago M. Fascin