Metodologia de Gerenciamento de Projetos Ágil (Fluxo do Processo) – MGP Ágil – Parte 2

Capa - MGP Ágil - Parte 2 - BPMN

Prezado leitor.

O texto da metodologia descrito a seguir é um norteador para um profissional de gestão poder criar a sua metodologia de gerenciamento de projetos ágil baseado na maturidade de sua organização e na sua necessidade. Aqui temos alguns tópicos, montando uma estrutura básica para que você crie a sua metodologia de gerenciamento de projetos ágil. Nesta primeira parte, será mostrado a parte teórica, com conceitos, na segunda parte da MGP Ágil, mostrarei um fluxo de processo em notação BPMN, com a descrição dos processos, subprocessos, atividades, artefatos, entradas e saídas.

 

Apresentação

A Metodologia de Gerenciamento de Projetos Ágil do Escritório de Gestão Integrada (Value Management Office – VMO) da Atomtech é um conjunto de boas práticas e definições de processos com o objetivo de agilizar, facilitar e otimizar o controle sobre os projetos.
Os conceitos de agilidade utilizados pela Atomtech e descritos neste guia são baseados nas necessidades e vivências do VMO da organização. Profissionais que já estudaram métodos ágeis encontrarão similaridades com modelos de mercado e, como consequência, facilidade em sua aplicação. Contudo, o guia da Atomtech não segue na integra um único modelo e foi construído utilizando técnicas e ferramentas de Canvas, Lean, Design Thinking e muito mais.
Em sua essência o Guia Gerenciamento de Projetos Ágil da Atomtech, procura trazer velocidade e agregação de valor o mais cedo possível para o Cliente.

Processos da Metodologia de Gerenciamento de Projetos Ágil

O fluxo ágil é especialmente útil para os projetos que costumam sofrer um número maior de mudanças de escopo devido à existência de um ambiente instável e dinâmico. Através de um alinhamento das melhores práticas de desenvolvimento Ágil de projetos, neste processo o Scrum Master reunirá com a Equipe do Projeto (sua equipe técnica do projeto) e com o Cliente (Demandante do projeto e quem domina a regra do negócio). Juntos construirão o quadro Project Kanvas, o Kanban, entre outras técnicas, e executarão as atividades alinhadas à Metodologia Ágil.

Veja o fluxo do processo em BPMN navegável clicando no link abaixo:
Fluxo de gerenciamento de projetos ágil da Atomtech em formato HTML navegável (Bizagi)

Clique na imagem para ampliar do fluxo de processo ágil da Atomtech:

Fluxo de processo ágil da Atomtech

Fluxo de processo ágil da Atomtech

Descrição Fluxos e Atividades

Iniciação

Elaborar Termo de Abertura do Projeto

Objetivo:

Alinhar as expectativas entre a área demandante e executora, agilizando o entendimento da demanda e tirar as primeiras dúvidas do projeto de forma rápida e objetiva.
Responsável:

  • Scrum Master
Envolvidos:

  • Demandante
  • Equipe do Projeto
Entradas:

  • Documentação existente da demanda;
  • Partes interessadas;
  • Partes interessadas.
Saída:

  • Project Kanvas (Kanvas Cards).
Descrição da atividade:
O Scrum Master deve avaliar o TAP e a documentação existente recebida pelo VMO (Escritório de Gestão Integrado).Em seguida marcar uma reunião a criação de Project Kanvas, sendo obrigatório a participação da:
  • Área demandante: pessoas que entendem a necessidade da demanda de projeto (dores da área), as regras de negócio, e as expectativas de prazo e orçamento para o projeto.
  • Equipe Técnica: O time que executará o projeto, sabe as limitações tecnológicas, e conhecimento técnico sobre as possíveis soluções, estimativas macro de esforço.
  • Scrum Master: Será o facilitador da reunião, ajudará no alinhamento das expectativas, questionará os envolvidos extraindo o máximo de informação.

Atenção: A descrição de como elaborar um Project Kanvas pode ser lida no link “MGP Ágil – Parte 1”.
https://gestaodeprojetos.com.br/metodologia-de-gerenciamento-de-projetos-agil/

 

Planejamento

Garantir que PO prepare os Itens do Backlog do Produto  “Planejamento da Versão para entrega”

Objetivo:

Garantir que Dono do Produto realmente pense na demanda da sua área, crie uma lista de demandas (backlog do produto ou da release). Que de fato se prepare para a reunião de planejamento da sprint.

Responsável:

  • Scrum Master
Envolvidos:

  • Dono do Produto
  • Analista de negócio
Entradas:

  • Project Kanvas;
  • Documentos.
Saída:

  • Apoio realizado.
Descrição da atividade:

O Scrum Master deve utilizar os seus conhecimentos sobre agilidade e gestão de projetos para garantir que o PO leve para a reunião de Planejamento da Sprint as informações necessárias e priorizadas (que irão entregar maior valor para a área demandante).
Caso o PO nunca tenha participado de um projeto, ministrar um treinamento rápido com os conceitos, técnicas e ferramentas pode será muito útil para o sucesso do projeto.

 

Planejar Backlog do Produto/Serviço

Objetivo:

Definir o escopo do produto/serviço/resultado de forma intuitiva e visual. Criar a descrição épicos e histórias de usuário, de modo a orientar a Equipe do Projeto a realizar as atividades necessárias e estimar os pontos de cada item.

Responsável:

  • Dono do Produto.
Envolvidos:

  • Scrum Master.
  • Analista de Negócio;
  • Outros funcionários da área demandante.
Entradas:

  • Project Kanvas.
  • Outros documentos que subsidiem o conhecimento acerca do Projeto (opcional).
Saída:

  • Backlog do produto/serviço atualizada.
Descrição da atividade:

O Backlog do produto/serviço é dinâmico, ou seja, novos itens, requisitos, podem ser adicionados pelo PO na lista do Backlog à medida que se aprende mais sobre o produto em desenvolvimento.

O Dono do Produto deve revisar o Backlog e priorizar os itens que entregarão maior valor ao produto.

A melhor pessoa para poder descrever as necessidades do produto/serviço é o próprio Dono do Produto e o Cliente.

O Scrum Master deverá interagir com eles, garantindo a criação do Backlog do Produto/Serviço de acordo com os princípios ágeis. Os itens do Backlog devem possuir detalhes suficientes para a equipe poder entender a necessidade, estivar o esforço, complexidade e risco necessário para a produção do item.

O PO, com a ajuda do Scrum Master e quem mais o PO achar necessário participar da reunião, deverão realizar técnicas de elicitação de conhecimento para criar uma lista contendo as funcionalidades desejadas para o produto do projeto.

Técnicas como o questionamento “Como podemos transformar a visão em um produto da melhor maneira possível?” pode ser empregada para definir um requisito do produto/serviço.
O Dono do Produto deve revisar o Backlog e priorizar os itens que entregarão maior valor ao produto.

  • Estabelecer a meta da versão.
  • Definir as maiores prioridades do Backlog do Produto.
  • Definir os principais riscos.
  • Definir as características gerais e funcionalidades que estarão contidas na versão.
  • Estabelecer uma data de entrega.
  • Estabelecer um custo.

 

Monitorar o Gráfico BurnDown do Produto/Serviço

Objetivo:

Criar um gráfico para monitorar o progresso do Projeto como um todo, rastreando a quantidade de esforço restante para terminar o Produto/Serviço. Com este gráfico é possível identificar se o cronograma da Projetos e das Sprints estão sendo executado conforme o planejado.

Responsável:

  • Dono do Produto
Envolvidos:

  • Scrum Master.
Entradas:

  • Project Kanvas
  • Documentos pertinentes (normas, guias técnicos, processos).
Saída:

  • Gráfico Burndown do Produto atualizado.
Descrição da atividade:

Utilizando o modelo de gráfico Burndown, o gráfico demonstrará a seguinte informação:

  • Adicionar no eixo Y (vertical) a quantidade de trabalho, que ainda falta para concluir o projeto;
  • Adicionar no eixo X (horizontal) o tempo estimado realizar a entrega final do projeto.
  • A unidade de trabalho deverá ser definida de acordo com o produto, podendo ser determinada por horas de trabalho, pontos de esforço, ou outra métrica definida pela VMO.
  • A unidade de tempo deverá ser definida pelos envolvidos no projeto, como padrão, cada Sprint terá a duração de 2 semanas, preferencialmente começando na segunda e terminando na sexta.

 

 

Criar Backlog da Sprint

Objetivo:
Reunião para definir os itens e metas da Sprint que a Equipe implementará e entregará ao seu final. A Sprint é uma iteração com período determinado.
Responsável:

  • Equipe do Projeto.
Envolvidos:

  • Dono do Produto;
  • Scrum Master;
  • Analista de negócio.

Entradas:

  • Project Kanvas;
  • O que é mais prioritário no Backlog;
  • O incremento mais recente do produto/serviço (opcional);
  • Capacidade da Equipe (opcional);
  • Histórico de Desempenho da Equipe (opcional);
  • Lições aprendidas (opcional).

Saída:

  • Backlog da Sprint.
Descrição da atividade:

O Scrum Masterdeverá interagir com o Dono do Produto e com a Equipe, garantindo que este crie o Backlog da Sprint de acordo com os princípios do Scrum e facilitar a retirada dos impedimentos que possam afetar o planejamento.

O Scrum Masterdeverá garantir que o Dono do Produto entre na reunião de Planejamento da Sprint com todos os itens necessários priorizados e detalhados com profundidade suficiente para a Equipe entender o que deve ser feito, criando atividades e definindo o esforço necessário.

Algumas das técnicas que o Scrum Masterpoderá utilizar nesta atividade são: Formação de times; Gerenciamento de Conflitos; poder de influência; motivação; negociação e tomada de decisão sempre orientada aos resultados.

A Equipe perguntará ao Cliente “O que deve ser feito?”. Em seguida, a Equipe deverá definir o “Como deve ser feito?”.

  • O que deve ser feito?

A Equipe deverá decidir o quanto do Backlog do produto/serviço é passível de ser feito na Sprint, uma das técnicas que podem ser utilizadas é o “Planning Poker”, que pode ser lido no “Capítulo 2 – Técnicas em Gerenciamento de Projetos Ágil”;
Limitar a Meta da Sprint, baseando-se na capacidade de execução da Equipe;
A saída desta parte da reunião é a definição da meta da Sprint, através da seleção dos itens do Backlog do produto/serviço que serão executados dentro da Sprint.

  • Como deve ser feito?

Decompor os itens selecionados do Backlog do produto/serviço e criar o Backlog da Sprint, ou seja, o que deve ser feito para entregar cada item do Backlog do produto/serviço selecionado;
Projetar o trabalho;

A Equipe deverá organizar-se e responsabilizar-se para garantir a entrega do trabalho.

 

Monitorar o Gráfico Burndown da Sprint

Objetivo:

Criar um gráfico para monitorar o progresso da Equipe, rastreando a quantidade de esforço restante para terminar a Sprint. Com este gráfico é possível identificar se o cronograma da Sprint está sendo executado conforme o planejado.

Responsável:

  • Equipe do Projeto.
Envolvidos:

  • Dono do Produto;
  • Scrum Master;
  • Analista de negócio.

Entradas:

  • Backlog da Sprint;
  • Quadro Kanban.

Saída:

  • Gráfico Burndown da Sprint atualizado.
Descrição da atividade:

O modelo de gráfico Burndown, é lido da seguinte forma:

  • Adicionar no eixo Y (vertical) a quantidade de trabalho, esforço, que ainda precisa ser empregada;
  • Adicionar no eixo X (horizontal) o tempo estimado.

A unidade de tempo deverá ser definida de acordo com o produto/serviço, podendo ser determinada por dias, semanas ou meses.

Observação: Essa atividade é semelhante à realizada pelo Cliente em “Criar gráfico Burndown do produto/serviço”, no entanto, quem é o responsável por criar o gráfico da Sprint é apenas a Equipe.

 

Criar/Atualizar Gráfico Burndown da Sprint

Objetivo:

Criar um gráfico para monitorar o progresso do Equipe do Projeto, rastreando a quantidade de esforço restante para terminar a Sprint. Com este gráfico é possível identificar se o cronograma da Sprint está sendo executado conforme o planejado.

Responsável:

  • Equipe do Projeto (Time)
Envolvidos:

  • Scrum Master.
Entradas:

  • Project Kanvas;
  • Kanban da Sprint.
Saída:

  • Gráfico Burndown do Produto atualizado.
Descrição da atividade:

Utilizando o modelo de gráfico Burndown, o gráfico demonstrará a seguinte informação:

  • Adicionar no eixo Y (vertical) a quantidade de trabalho, que ainda falta para concluir o projeto;
  • Adicionar no eixo X (horizontal) o tempo estimado realizar a entrega final do projeto.
  • A unidade de trabalho deverá ser definida de acordo com o produto, podendo ser determinada por horas de trabalho, pontos de esforço, ou outra métrica definida pela VMO.
  • A unidade de tempo deverá ser definida pelos envolvidos no projeto, como padrão, cada Sprint terá a duração de 2 semanas, preferencialmente começando na segunda e terminando na sexta.

Observação: Essa atividade é semelhante à realizada pelo PO em “Criar gráfico Burndown do Produto”, no entanto, quem é o responsável por criar o gráfico da Sprint é apenas o Time.

 

 

Execução

Executar Atividades da Sprint

Objetivo:

A Equipe do Projeto deverá executar as atividades comprometidas na reunião de planejamento da Sprint.

Responsável:

  • Equipe do Projeto.
Envolvidos:

  • Dono do Produto
  • Scrum Master

Entradas:

  • Backlog da Sprint;
  • Quadro Kanban;
  • Outros documentos que subsidiem o conhecimento acerca do Projeto (opcional).

Saída:

  • Atividades diárias concluídas.
Descrição da atividade:

Os membros da Equipe do Projeto deverão executar as atividades comprometidas.
As técnicas e ferramentas utilizadas são inerentes às atividades comprometidas. Não existe uma técnica ou ferramenta padrão.

Exemplo:
Caso seja um projeto de desenvolvimento de software:

  1. Fluxo do processo: mapeamento do fluxo do processo deve ser realizado em todos os softwares desenvolvidos utilizando notação BPMN. Se será um mapa ou modelo de processo vai depender da complexidade e do tipo do desenvolvimento.
  2. Protótipo de tela: como o objetivo facilitar o entendimento dos requisitos da demanda, a prototipação apresentar conceitos e funcionalidades do software de modo simplificado, rápido e fácil, diminuindo os riscos de retrabalho e como consequência economia no custo e prazo do projeto. Na Atomtech é obrigatório a pelo menos o desenvolvimento de wireframes com baixo nível de fidelidade, mas que podem ser criados ou modificados rapidamente, ajudando no alinhamento das necessidades entre a área demandante e a equipe de desenvolvimento.
  3. Modelagem de banco de dados: o Administrador de Dados (AD) é o responsável pela sua execução e deverá utilizar os recursos tecnológicos disponíveis. Um programador só pode modelar informações de banco se autorizado ou acompanhado pelo AD.
  4. Desenvolvimento: O desenvolvedor pode desenvolver usando sua IDE preferida, contando que consiga realizar uma inspeção contínua da qualidade do código com o SonarQube. As soluções devem ser componentizadas, e utiliza RESTful, Angular, HTML5 e CSS3, e sempre que possível utilizando as melhores práticas do mercado para  facilidade de uso para pessoa com deficiência (PcD).
  5. Orquestração de contêineres: O desenvolvimento deve ser realizado utilizando contêineres Kubernetes para automatizar a implantação e gestão da aplicação.
  6. Versionamento do código: Deverá ser realizado pelo GitLab de forma a permitir pipeline de CI/CD (Continuous Integration/Continuous Deployment – Integração contínua / Implantação contínua).
  7. Teste de qualidade: O teste deve ser realizado com Katalon (gravação de scripts de testes automatizados); TestLink (planejamento e gerenciamento das execuções dos roteiros de testes); TestLink (Planejamento e gerenciamento das execuções dos roteiros de testes); Mantis (Bugtracker para registro de defeitos detectados); JMeter (testes de carga e de estresse).
  8. Teste de segurança: A equipe de infraestrutura deverá realizar testes de segurança utilizando Fortify, antes da homologação (aconselhável) e obrigatoriamente antes do deploy em  produção devem. Teste periódico de segurança deve ser feito conforme atualizações em versões do PHP, Nginx ou frameworks, módulos ou aplicações.

 

 

Monitoramento e Controle

Reuniões Diárias 15min

Objetivo:

É a reunião fundamental que deverá inspecionar e adaptar o processo, ou seja, é o monitoramento e controle das atividades planejadas.

Responsável:

  • Scrum Master.
Envolvidos:

  • Dono do Produto
  • Equipe do Projeto

Entradas:

  • Backlog da Sprint;
  • Quadro Kanban;
  • Gráfico Burndown da Sprint.

Saída:

  • Ações definidas para o dia/semana:
  • Itens que a Equipe do Projeto desenvolverá no dia/semana; Itens de Impedimentos com os quais o Scrum Master deverá lidar.
  • Kanban e Burndown atualizados.
Descrição da atividade:

Em uma reunião rápida e objetiva, sempre no mesmo local e horário, inerente à Metodologia Ágil, o Scrum Master deverá garantir a execução de três perguntas e suas respostas para cada membro da Equipe:

  • O que fez ontem/semana?
  • O que fará hoje/próxima semana?
  • Quais são os impedimentos?

Se a Equipe concluir que sobrará tempo, ele poderá trabalhar junto ao Cliente para selecionar mais itens do Backlog do produto/serviço.
Sugestão de duração máxima para as reuniões:

  • Reunião Diária: 15 minutos e sempre no mesmo horário e local (podendo ser virtual).

Não recomendado, no entanto possível, devido a características de alguns projetos:

  • Reunião Semana: 45 minutos e sempre no mesmo horário e local (podendo ser virtual).

 

Retirar Impedimentos

Objetivo:

O Scrum Masterdeverá retirar os impedimentos relatados na reunião de forma a garantir a entrega ao final da Sprint.

Responsável:

  • Scrum Master.
Envolvidos:

Entradas:

  • Lista de Impedimentos.

Saída:

  • Impedimentos solucionados;
  • Lista de riscos atualizada.
Descrição da atividade:

O Scrum Master deverá buscar formas de retirar os impedimentos relatados pela Equipe, buscar apoio da VMO, patrocinadores e atores que possam solucionar os problemas.

 

Encerramento da Sprint

Revisão da Sprint

Objetivos:

Validação da entrega. Reunião realizada ao final de cada Sprint para inspecionar a entrega que foi pactuada no início da Sprint (caso essa possa ser visível ao demandante).
Fazer as adaptações que otimizem o valor da próxima Sprint.

Responsável:

  • Dono do Produto.
Envolvidos:

  • Cliente;
  • Scrum Master; Equipe do Projeto.

Entradas:

  • Plano de Projeto e/ou Project Kanvas.
  • Backlog da Sprint.

Saída:

  • Backlog do produto/serviço revisado;
  • TES – Termo de Entrega da Sprint;
  • Nova projeção das datas de conclusão.
Descrição da atividade:

Tempo Máximo:

  • 4 (quatro) horas para Sprint de 4 (quatro) semanas;
  • 2 (duas) horas para Sprint de 3 (três) semanas;
  • 1 (uma) hora para Sprint de 2 (duas) semanas;
  • 30 (trinta) minutos para Sprint de 1 (uma) semana.

Revisão da Sprint:

  • Apresentar a funcionalidade para o demandante.
  • PO deverá identificar o que foi feito e o que não foi feito de acordo com o pactuado.
  • O Time deverá discutir os problemas técnicos enfrentados e como foram resolvidos.
  • O Time deverá responder aos questionamentos do demandante.
  • Revisar o backlog do produto, debater projeção de futuras sprints e versões do produto.

Observação:
Em alguns projetos desenvolvidos de diversas naturezas foi constatado que foi mais proveitoso realizar a Retrospectiva da Sprint logo após a revisão da sprint, com as mesmas pessoas, sem nenhum intervalo e em alguns momentos até mesmo intercalando apresentação do produto com retrospectiva e lições aprendidas. Cabe aos envolvidos no projeto definir se as duas reuniões serão realizadas no mesmo momento ou em momentos distintos com pessoas específicas.

A Equipe deverá discutir os problemas técnicos enfrentados e como foram resolvidos. A Equipe deverá responder aos questionamentos do Dono do Produto.

Sendo necessário é possível redefinir os nomes, quantidade, cores e percentual de avanço de cada raia (coluna) do quadro Kanban.

 

Retrospectiva da Sprint

Objetivos:

Revisar a Sprint finalizada e definir que adaptações tornarão a próxima Sprint mais produtiva. Melhoria contínua e lições aprendidas.

Responsável:

  • Scrum Master;
  • Time Scrum.
Envolvidos:

  • Cliente;
  • Dono do Produto;
  • Outras partes pertinentes para a reunião.

Entradas:

  • Plano de Projeto e/ou Project Kanvas.
  • Backlog da Sprint.

Saída:

  • LAP – Lições Aprendidas do Projeto.
Descrição da atividade:

Tempo Máximo:

  • 3 (três) horas para Sprint de 4 (quatro) semanas;
  • 2 (duas) para Sprint de 3 (três) semanas;
  • 1 (uma) hora para Sprint de 2 (duas) semanas;
  • 30 (trinta) minutos para Sprint de 1 (uma) semana..

Retrospectiva da Sprint:

  • Listar e documentar as lições aprendidas durante a execução da Sprint (o que deu certo e o que deu errado).
  • Algumas outras partes podem ser envolvidas nessa reunião, principalmente quando uma melhoria depende de outras áreas. Neste caso, como exemplo, um diretor ou o VMO pode participar.
  • Verificar como foi a execução da última Sprint, identificando melhorias e definindo ações de como aperfeiçoar a forma que o Time executa o trabalho. Para essa verificação são consideradas, mas não se limitam, as formas de melhorar os seguintes itens:
    • O processo;
    • Composição do time;
    • Preparativos para as reuniões;
    • Ferramentas;
    • Definição de “Pronto”;
    • Métodos de comunicação.

Observação:
Em alguns projetos desenvolvidos de diversas naturezas foi constatado que foi mais proveitoso realizar a Retrospectiva da Sprint logo após a revisão da sprint, com as mesmas pessoas, sem nenhum intervalo e em alguns momentos até mesmo intercalando apresentação do produto com retrospectiva e lições aprendidas. Cabe aos envolvidos no projeto definir se as duas reuniões serão realizadas no mesmo momento ou em momentos distintos com pessoas específicas.

A Equipe deverá discutir os problemas técnicos enfrentados e como foram resolvidos. A Equipe deverá responder aos questionamentos do Dono do Produto.

Sendo necessário é possível redefinir os nomes, quantidade, cores e percentual de avanço de cada raia (coluna) do quadro Kanban.

 

Encerramento do Projeto

Realizar reunião  de encerramento do Projeto

Objetivo:

O Scrum Master deverá preencher a Termo de Encerramento do Projeto. O Patrocinador aprovar. O VMO encerrar o projeto.

Responsável:

  • Patrocinador.
Envolvidos:

  • Dono do Produto;
  • Cliente;
  • Scrum Master;
  • VMO.

Entradas:

  • Plano do Projeto/ Project Kanvas
  • Termo(s) de Entrega das Sprints.

Saída:

  • TEP – Termo de Encerramento do Projeto;
  • Projeto encerrado.
Descrição da atividade:

O Scrum Master escrever o Termo de Encerramento do Projeto contendo as seguintes informações:

  • A data do encerramento do projeto;
  • O tipo do encerramento: Concluído; Concluído parcialmente; Cancelado; Integrado com o projeto;
  • Justificativa objetiva e clara acerca do encerramento do projeto;
  • Lista dos produtos entregues ao Demandante.

O Scrum Master deverá encaminhar o TEP ao Patrocinador(es) para o conhecimento do término do projeto e coleta das assinaturas.

O Patrocinador deverá tomar ciência do término do projeto e de suas entregas.

Com o TEP aprovado, o VMO deve encerrar o projeto na ferramenta de gestão de projetos.

Email

Frederico Ribeiro Ramos

URL

Views:
88
Article Categories:
G.Projetos