Instituto Modal

Categorias

1. PMGP-a: Processo Modal de Gestão de Projetos – Agile

Você está aqui:
  • Principal
  • PMGP
  • 1. PMGP-a: Processo Modal de Gestão de Projetos - Agile

 

Visão Geral

O Processo Modal de Gestão de Projetos – Agile (PMGP-a) é um processo de gerenciamento de projetos composto por ferramentas, modelos e práticas recomendadas que permite que seus usuários sejam mais eficientes e eficazes na entrega do projeto, independentemente do tamanho ou da complexidade.

O conteúdo deste documento é baseado no PMI (Project Management Institutes) Um guia para o Conhecimento em Gerenciamento de Projetos (PMBOK)

A Diretoria Técnica do Instituto Modal criou o PMGP-a para ajudar as equipes de trabalho a realizar suas missões principais por meio da entrega bem-sucedida do projeto. O uso dessas ferramentas e modelos pode ajudar a obter consistência, padronização e sucesso do projeto.

Revisões

[su_table responsive=”yes”]

DataVersãoDescrição
2020.02.221.0Criação da versão inicial. Elaboração dos primeiros modelos de artefatos.
2020.02.271.0Inclusão de conceitos iniciais. Revisão de artefatos.

[/su_table]

Conceitos Iniciais

Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos.

Um projeto é composto de fases ou etapas. Cada fase possui entregas específicas.

Entrega é qualquer resultado concreto — seja produto ou serviço — gerado pelo projeto e que seja verificável e atenda aos critérios de aceitação previamente estabelecidos.

Estrutura analítica do projeto / Work Breakdown Structure (WBS) é a decomposição hierárquica orientada à entrega do trabalho a ser executado pela equipe do projeto para atingir os seus objetivos e criar as entregas necessárias. Ela organiza e define o escopo total do projeto.

Processo de Gestão de Projetos é o conjunto ordenado de etapas, procedimentos, artefatos e metodologia utilizados para gerenciar um ou mais projetos, conforme as diretrizes e modelos de gestão adotados pela empresa.

Modelos de Documentos

[su_table responsive=”yes”]

ModeloDescrição
Justificativa de NegócioO documento Justificativa de Negócio define a necessidade do negócio, juntamente com as informações necessárias, do ponto de vista comercial, para determinar se o projeto vale ou não o investimento necessário. Ele demonstra o alinhamento aos objetivos estratégicos e de negócios e é usado para priorizar o projeto entre outras demandas do projeto.
Termo de Abertura do ProjetoO Termo de Abertura do Projeto (ou Carta do Projeto ou Project Charter, em inglês) autoriza oficialmente o projeto e aloca recursos, iniciando oficialmente o trabalho.
Plano de Gerenciamento do ProjetoO Plano de Gerenciamento do Projeto define “como” o projeto é executado, monitorado, controlado e fechado.
Cronograma do ProjetoO Cronograma do Projeto ajuda a planejar e rastrear datas importantes no projeto. O Instituto Modal utiliza o OpenProject ou o GitHub para gerenciar o cronograma do projeto.
Documento de RequisitosO Documento de Requisitos detalha os requisitos específicos do projeto e do produto que devem ser atendidos para satisfazer os objetivos de negócios. Os primeiros levantamentos poderão ser feitos mediante planilha específica, mas imediatamente após o início da execução do projeto todos os requisitos deverão ser transportados para o OpenProject ou para o GitHub, dependendo das características do projeto.
Registro do ProjetoO Registro do Projeto é uma ferramenta que pode ser usada para capturar e rastrear as principais informações do projeto, facilitando o monitoramento e o controle dos detalhes do projeto durante toda a sua vida útil. O Instituto Modal utiliza o OpenProject ou o GitHub para fazer o registro do projeto.
Notas de Reuniões do ProjetoO modelo de Notas de Reuniões do Projeto é usado para documentar e comunicar anotações para todas as reuniões do projeto. Opcionalmente, as anotações podem ser feitas no OpenProject ou o GitHub e vinculadas a fases e/ou tarefas do projeto.
Relatório de AtividadesO Relatório de Atividades é utilizado pelos colaboradores do projeto para comunicar periodicamente (a cada sprint ou outro intervalo de tempo definido pelo Gerente do Projeto) a situação das atividades sob sua responsabilidade. O conjunto dos Relatórios de Atividades de todos os colaboradores poderá ser anexado ao Relatório de Status do Projeto.
Relatório de Status do ProjetoO Relatório de Status do Projeto (ou Relatório Gerencial) é utilizado para comunicar a integridade geral do projeto à equipe principal e às principais partes interessadas, para manter todos informados sobre o andamento do projeto. O Relatório de Status do Projeto é feito em LaTeX e adaptado para a necessidade de cada cliente.
Ordem de ServiçoA Ordem de Serviço (OS) é usada pelo Cliente para formalizar a solicitação de uma demanda adicional a uma tarefa ou fase do projeto sem que isso implique alteração significativa de escopo / cronograma / custos. A OS precisa ser aprovada tanto pelo Cliente quanto pelo Gerente do Projeto.
Solicitação de Mudança no ProjetoA Solicitação de Mudança no Projeto (SMP) é usada pelo Cliente e/ou pelo Gerente de Projeto para solicitar uma alteração no escopo, cronograma, custos, marcos e / ou entregas do projeto. A SMP precisa ser aprovada tanto pelo Cliente quanto pelo Gerente do Projeto.
Lições AprendidasO documento Lições Aprendidas é usado para identificar e preservar as lições aprendidas em cada projeto. O objetivo deste documento é ajudar a equipe do projeto a compartilhar o conhecimento obtido com a experiência. Um programa bem-sucedido de lições aprendidas ajudará as equipes de projeto a repetir resultados desejáveis e evitar resultados indesejáveis. Usualmente, o Registro do Projeto é utilizado para colecionar as lições aprendidas e, ao final do projeto, essa coleção é transformada em um arquivo compilado com todas as anotações.
Termo de Encerramento do ProjetoO documento Termo de Encerramento do Projeto formaliza a conclusão do projeto.

[/su_table]

Conforme a necessidade do projeto, alguns desses artefatos podem ser simplificados ou fundidos em um único documento.

Processo de Gestão

Para projetos gerenciados  de maneira ágil, as etapas do projeto não aderem às fases sequenciais da mesma maneira que uma abordagem em cascata tradicional. Ao contrário de uma abordagem em cascata, uma metodologia ágil se concentra no desenvolvimento e na implantação de soluções o mais rápido possível, fazendo ajustes à medida que o projeto avança.

O PMGP-a recomenda que o início de um projeto siga um processo semelhante a uma metodologia em cascata, em que informações sobre a Justificativa de Negócio são primeiramente compiladas e avaliadas para investir esforço e dinheiro em um projeto.

Uma vez que a visão para um projeto é estabelecida, o resultado final desejado é definido, a análise de custo-benefício foi realizada e a organização determinou que o investimento vale a pena, a execução real do projeto ocorre de maneira incremental / iterativa.

A função de um gerente de projeto em um projeto ágil

Projetos ágeis não apenas seguem um processo ligeiramente diferente de um projeto tradicional (em cascata), mas algumas das funções dentro da equipe do projeto também são um pouco diferentes. Em algumas metodologias ágeis, não há função específica para “Gerente de Projeto”. Em vez disso, termos como Scrum Master são usados, como é o caso na metodologia Scrum. Líder de equipe é outro termo frequentemente usado nas estruturas de equipe do projeto Agile.

Em projetos ágeis, os cronogramas (mais especificamente o conteúdo ou as entregas de um incremento ou “sprints“) são mais fluidos. Com o início de cada novo sprint, a meta e a saída esperada são determinadas pela análise de uma combinação dos requisitos do projeto, também chamados de backlog, feedback do cliente sobre o estado atual do desenvolvimento e qualquer reprioritização dos objetivos, necessidades, requisitos do projeto etc.

Embora seja importante entender os objetivos do projeto geral e ter uma ideia de alto nível em relação à saída de cada sprint, as equipes do projeto devem ser flexíveis e capazes de se adaptar às mudanças nos requisitos e/ou redefinição de prioridade.

Para facilitar essa abordagem, uma pessoa que gerencia esses processos deve ser flexível e pronta para fazer ajustes rapidamente, em vez de se concentrar na adesão a um plano predefinido.

Outros Papéis / Membros da Equipe

  1. Cliente: O cliente é o principal interessado de um projeto. Parte das responsabilidades do cliente é ter uma visão do que ele ou ela deseja construir e transmitir essa visão à equipe. Isso é essencial para iniciar com êxito qualquer projeto ágil. Essa pessoa é, em última análise, responsável pela priorização de requisitos / resultados, bem como da redefinição de prioridades de requisitos e resultados ao longo da vida do projeto, especificamente no início de cada novo sprint.
  2. Membro da equipe: Essa função é responsável pela criação e entrega das tarefas de um projeto. Isso inclui atividades de pesquisa, modelagem, desenvolvimento, teste e liberação, além de outras.

Iniciando um projeto

Trata-se da revisão da ideia de negócio e a sua transformação em um projeto formal.

Atividades chave:

  • Identificar o problema que precisa ser resolvido
  • Identificar os benefícios de realizar o projeto, incluindo impactos financeiros, como retorno do investimento
  • Definir os resultados esperados e os principais marcos. No caso de projetos ágeis, é mais importante estimar o número de sprints que podem ser necessários e/ou a duração geral do trabalho, em vez de requisitos detalhados específicos que precisam ser atendidos.
  • Identificar riscos e restrições do projeto
  • Identificar as principais partes interessadas e os recursos necessários

Justificativa de Negócio

O patrocinador do projeto ou o proprietário da empresa é a pessoa mais indicada para preparar esse artefato. Este documento abordará o problema e o resultado esperado, bem como os principais recursos necessários para o projeto. Ele define como o projeto se alinhará aos objetivos da organização.

Termo de Abertura do Projeto

No Termo de Abertura do Projeto deve ser definido o escopo do projeto, bem como criada uma linha do tempo estimada e estabelecido o orçamento do projeto. Em uma abordagem em cascata, este documento é uma elaboração / complemento para a Justificativa de Negócio, mas, em uma abordagem ágil, pode fazer sentido combinar esses dois documentos. O fator importante a ser lembrado é que esses documentos, tradicionalmente resultando em planos relativamente detalhados, devem permanecer em ‘alto nível’. A ênfase deve estar em estabelecer e priorizar requisitos de alto nível (funções do produto que está sendo desenvolvido). Ao iniciar sprints, durante a execução do projeto, esses requisitos / funções serão desenvolvidos e liberados de forma incremental, com base na prioridade. E, essas prioridades podem mudar, e geralmente mudam, ao longo da vida do projeto, para que cada sprint precise de um “pontapé inicial”.

Documento de Requisitos

Este documento fornece um mecanismo para rastrear as entregas do produto / projeto em relação aos requisitos, para garantir que os requisitos de negócios e produtos sejam atendidos. Ao usar uma abordagem ágil, esses requisitos podem assumir a forma de funções de nível superior do produto que está sendo desenvolvido. Os requisitos / especificações detalhados definidos no início do projeto, ao alavancar uma abordagem em cascata, são aprimorados durante os sprints por meio da colaboração entre o cliente, usuários e a equipe de trabalho.

Ao desenvolver requisitos, deve ser considero o uso de imagens e/ou diagramas de processos de negócios e/ou interações do usuário com a solução que está sendo desenvolvida. Quadros de histórias, fluxos de processos e histórias de usuários são técnicas comuns para documentar requisitos em Projetos Agile.

Uma história de usuário é uma ferramenta usada no desenvolvimento de software Agile para capturar uma descrição de um recurso de software sob a perspectiva do usuário final. A história do usuário descreve o tipo de usuário, o que eles querem e por quê. Uma história de usuário ajuda a criar uma descrição simplificada de um requisito.

Execução do Projeto

Na execução, os projetos ágeis adotam uma abordagem incremental / iterativa. Isso significa que partes do produto geral são desenvolvidas e implantadas e, em seguida, a próxima parte do produto geral é desenvolvida e implantada, e assim por diante. É importante que, no início do projeto, o produto mínimo viável seja definido e que o plano de liberação descreva o que cada um dos incrementos (sprints) fornecerá. Durante toda a vida do projeto, o plano de liberação e a saída dos vários sprints são continuamente reavaliados e possivelmente re-priorizados, com base nas necessidades dos negócios e dos clientes.

Atividades chave

  • Reuniões de kickoff do sprint;
  • Verificação diária nas reuniões de equipe, também conhecida como reuniões do Scrum;
  • Coletar / documentar requisitos e produtos não identificados nas etapas anteriores do projeto, para que possam ser incorporados nos próximos sprints;
  • Coletar / documentar lições aprendidas para que futuros sprints possam ser ajustados de acordo.

Registro do Projeto

O Registro do Projeto pode ser usado para rastrear itens de ação, decisões, entregas, riscos, problemas, informações de contato das partes interessadas e muito mais. Este documento / ferramenta pode ser crucial na atividades de iniciação de sprints / Kickoffs.

Notas de Reuniões do Projeto

As notas de reuniões devem ser utilizadas em todas as reuniões do projeto para documentar a agenda da reunião, itens de ação, decisões tomadas, quem participou e para quando foi agendada a próxima reunião.

Relatórios de Status do Projeto

O Relatório de Status do Projeto comunica os principais indicadores de desempenho (KPIs), as principais datas e os principais riscos / problemas relacionados ao projeto, a fim de manter todos os participantes igualmente informados.

Ordem de Serviço (OS)

A Ordem de Serviço (OS) é usada pelo Cliente para formalizar a solicitação de uma demanda adicional a uma tarefa ou fase do projeto sem que isso implique alteração significativa de escopo / cronograma / custos. A OS precisa ser aprovada tanto pelo Cliente quanto pelo Gerente do Projeto.

Solicitação de Mudança do Projeto (SMP)

Este documento deve ser utilizado para documentar as principais mudanças no projeto que afetam o escopo, o cronograma, os custos, a qualidade ou o desempenho e a saúde do projeto. Este formulário não deve ser usado para gerenciar atividades operacionais diárias, monitoramento e controle de projetos, pois isso adicionará uma sobrecarga significativa às atividades de gerenciamento de projetos.

Plano de Gerenciamento do Projeto (opcional)

Este modelo estabelece um plano e estratégia para “como” o projeto será executado. O termo de abertura do projeto define o “quê”, enquanto o plano de gerenciamento do projeto define o “como”.

Encerramento do Projeto

Na fase de encerramento do projeto, os artefatos do projeto são arquivados, as atividades do projeto são concluídas e o projeto passa para o status de “operacional”.

Atividades chave

  • Transição do projeto para “Operacional”
  • Arquivar artefatos do projeto em repositório
  • Documentar as lições aprendidas e realizar a reunião de revisão final do projeto
  • Planejar um post mortem para o projeto
  • Obter aprovação para o fechamento formal do projeto

Lições Aprendidas

O documento Lições Aprendidas deve ser preenchido usando as informações do Registro do Projeto e quaisquer outros artefatos pertinentes ao projeto, bem como o feedback da equipe obtido em qualquer etapa do projeto.

Termo de Encerramento do Projeto

O Termo de Encerramento do Projeto formaliza a confirmação de que todos os objetivos do escopo foram atendidos e os itens necessários foram finalizados. Isso inclui garantir que todas as entregas listadas foram concluídas e a documentação do projeto foi salva no repositório adequado. Este documento também permite formalizar como as ações / questões pendentes devem ser tratadas.

 

Sumário

Deixe uma resposta

Formulário de Solicitação de Bolsas

Informações Pessoais
Seu endereço residencial completo, incluindo CEP
Se não tiver Currículo cadastrado na Plataforma Lattes e nem no LinkedIn, anexe um PDF com o seu currículo no próximo campo.
Linha de Pesquisa
Para mais informações, consulte o Regulamento de Concessão de Bolsas.
Você deve vincular seu cadastro a um projeto ou linha de pesquisa específico.
Explique porque você acha que deve ser selecionado. Fale sobre sua experiencia, o que pretende fazer, suas motivações etc.
Declarações

Acessar a sua conta