Metodologia de Gerenciamento de Projetos Ágil – MGP Ágil – Parte 1

MGP - Agil - Capa - 000

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.

 

Uma metodologia possui uma estrutura básica, sendo direto, um sumário de uma MGP conterá:

  1. Apresentação
  2. Conceitos
  3. Quais são os artefatos
    • Modelos de documentos
  4. Papel e responsabilidade
    • Atores de um projeto
    • RACI
  5. Técnicas para o Gerenciamento Ágil
    • Melhores Práticas para ajudar um profissional a planejar, executar, monitorar e encerrar um projeto
    • Técnicas
    • Ferramentas
  6. Planejamento
    • Seja com canvas ou outras técnicas de planejamento
    • Criando a Visão do Produto
    • Backlog do Produto/Serviço com Épicos, temas e Histórias de Usuário
  7. Priorizando Itens
  8. Medindo o Esforço
  9. Delegando e Controlando a Execução
    • Fluxo contínuo de demandas com Kanban
  10. Monitorando com o Gráfico Burndown
  11. Processos da Metodologia de Gerenciamento de Projetos Ágil
    • Iniciação
    • Planejamento
    • Execução
    • Monitoramento e Controle
    • Encerramento

Essa lista não é exaustiva. Outros tópicos podem ser adicionados na Metodologia de Gerenciamento de Projetos (MGP), ou pode ser criado um outro documento, complementar e que irá anteceder a MGP que é a Metodologia de Gerenciamento do Portfólio de Projetos (MGPP). Se serão dois documentos ou um documento mais robusto, vai depender da necessidade da sua organização.

 

Alguns dos tópicos de uma  Metodologia de Gerenciamento do Portfólio de Projetos (MGPP), que também será tema de outro artigo, são:

  1. Introdução
  2. Conceitos
    • Gerenciamento de Portfólio
    • Escritório de Gerenciamento de Projetos
  3. Papéis e Responsabilidades (muitos dos atores são diferentes da MGP)
    • Matriz de Responsabilidade – RACI
  4. Indicadores de Desempenho do Escritório de Projetos
  5. Critérios para categorização de projetos
  6. Critérios para priorização de projetos
  7. Processo da Metodologia de Gerenciamento de Demandas, Portfólio e Projetos
    • Identificar Projetos
    • Categorizar e Priorizar Projetos
    • Controlar portfólio de projetos
    • Executar Demanda
    • Executar Projeto Tradicional (Preditivo)
    • Executar Projeto Ágil
    • Executar Projeto Híbrido
  8. Glossário e Acrônimos
  9. Referências Bibliográficas
  10. Modelos de Documentos (fundamental para uma organização ter uma padronização dos documentos)

 


Metodologia de Gerenciamento de

Projetos Ágil (MGP)

 

1.       Apresentação

A Metodologia de Gerenciamento de Projetos Ágil do Escritório de Gestão Integrada 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.

 

2.       Conceitos

2.1.      O que é um Sprint

Uma Sprint é um ciclo de trabalho. Cada Sprint possui um conjunto de requisitos que deve ser implementado e entregue, incrementando o produto ou serviço que está sendo desenvolvido. A duração desse ciclo será definida em comum acordo entre o Cliente (Demandante), Dono do Produto (Analista/Especialista de Negócio), Líder do Projeto (Scrum Master ou GP) e Equipe do Projeto.

Recomendações:

  • Uma Sprint não ultrapassar o período de duas semanas para realizar uma entrega.
  • Manter as Sprints com a mesma duração dentro do mesmo projeto.

 

2.2.      Quais são os artefatos

  • Backlog do produto/serviço – É uma lista priorizada de tudo que pode ser necessário no produto/serviço e para desenvolvê-lo. Ela é elaborada no início dos trabalhos do projeto, assemelhando-se a uma lista de escopo a ser cumprido pelo produto/serviço do projeto. O Backlog é um artefato vivo, cujos principais objetivos podem ser alterados ou descartados conforme o interesse do Cliente (Demandante) e Dono do Produto (Analista/Especialista de Negócio).
    Características do Backlog:

    1. Sua versão inicial nunca é completa;
    2. Contempla os itens iniciais e os com melhores entendimentos;
    3. Evolui à medida que o produto e o ambiente no qual será utilizado evolui;
    4. É dinâmico;
    5. Contém características, funções, tecnologias, melhorias e correções de defeitos;
    6. A lista do Backlog sempre possui:
      • Nome;
      • Descrição;
      • Prioridade (determinada pelo risco, valor funcional, necessidade e interesse do Cliente);
  • Sprints relacionadas a cada atividade.
  • Backlog da Sprint É uma lista de tarefas para transformar um ou mais itens do Backlog em um incremento potencialmente entregável.
  • Gráfico Burndown do produto/serviço – Permite uma visão geral do andamento do projeto.
  • Gráfico Burndown de Sprint Mede os itens do Backlog da Sprint restantes ao longo do tempo de uma Sprint.

 

2.3.      Eventos de Planejamento e Monitoramento

Para uma boa gestão dos projetos é importante existir momentos rotineiros de planejamento, monitoramento e controle do. É fundamental que o Líder do Projeto (Scrum Master ou GP) garanta que esses eventos ocorram dentro do planejado.

Os eventos são:

  • Planejamento do Canvas do Projeto – Reunião para o planejamento do projeto, alinhamento das expectativas, definição do escopo, não escopo, qualidade e marcos de entregas.
  • Planejamento do Backlog do Produto/Serviço – Reunião na qual o Cliente e o Dono do Produto definam as características do produto/serviço, o que deve ser entregue e a prioridade;
  • Planejamento da Sprint (Fase) – Reunião na qual é definido o que será entregue e como o trabalho será realizado. A Sprint deve ser planejada com a equipe do projeto, onde o Dono do Produto irá detalhar os itens que devem ser desenvolvidos e a equipe definirá como será desenvolvido, a estimativa de esforço, complexidade e riscos.
  • Reunião Diária/Semanal – Para uma reunião diária, a duração deve ser a menor possível, como sugestão, o tempo máximo é de 15 (quinze) minutos. Para reuniões semanais o tempo máximo é de 45 minutos, na qual todo a Equipe responde ao Líder do Projeto (Scrum Master ou GP) perguntas como: “O que foi feito ontem/semana passada?”; “O que será feito hoje/próxima semana?”; “Quais são os impedimentos?”;
  • Validação da Entrega – Reunião executada no final da Sprint na qual o Dono do Produto e o Cliente identificam o que foi feito. Essa reunião permite que os envolvidos obtenham uma melhor visão do produto/serviço o que auxilia no refinamento do backlog do produto/serviço do projeto.

 

3.       Atores de um projeto ágil

Para cada ator no fluxo do processo da metodologia é definido um papel (função desempenhada por uma pessoa), uma responsabilidade (obrigação assumida pela pessoa ao exercer um determinado papel) e uma competência (capacidade, habilidade que ela precisa possuir para executar uma determinada atividade).

3.1.      Escritório de Gestão Integrada da Atomtech (VMO)

Centralizar, avaliar e coordenar projetos, prover a visibilidade da situação do Portfólio de Projetos sob sua responsabilidade. Atuar no suporte aos Líderes dos Projetos, na administração de expectativas das partes interessadas e no fornecimento de informações ao planejamento estratégico da organização. O responsável por coordenar as ações do VMO é o Gerente do Escritório de Gestão.

Reponsabilidades

  • Prover informações à Diretoria;
  • Apoiar o Líder de Projetos;
  • Manter as Metodologias de Projeto;
  • Gerir o Portfólio de Projetos;
  • Liderar a equipe do VMO;
  • Promover treinamentos;
  • Reunir com os Líderes dos Projetos;
  • Validar os documentos dos projetos;
  • Verificar o alinhamento dos projetos às estratégias do Sistema Indústria.

Competências

  • Conhecimento da Metodologia de Gerenciamento de Projetos da Atomtech;
  • Conhecimento e boa aplicação dos conceitos de Gestão de Projetos;
  • Formação de equipes;
  • Liderança;
  • Percepção do Planejamento Estratégico Integrado (PEI Atomtech);
  • Relacionamento interpessoal.

3.2.      Gerente da Unidade

Apoiar a execução dos seus projetos. Fornecer os recursos humanos, materiais e financeiros necessários para alcançar o objetivo do projeto. O Gerente da Unidade é o patrocinador e tem interesse genuíno no sucesso do projeto, ou seja, possui grande influência, agrega valor e conhecimento acerca do negócio.

Reponsabilidades

  • Acompanhar o andamento e os resultados;
  • Retirar os impedimentos da sua equipe;
  • Avaliar e aprovar artefatos;
  • Fornecer o apoio institucional;
  • Gerenciar as expectativas;
  • Gerenciar conflitos;
  • Intermediar com a Alta Administração em defesa do projeto;
  • Negociar a liberação de recursos humanos, financeiros e materiais para o projeto.

Competências

  • Conhecimento aprofundado do negócio;
  • Orientação a resultados;
  • Percepção da estratégia, da política e da cultura da organização;
  • Possuir poder de decisão;
  • Ter influência com a Alta Administração.

3.3.      Dono do Produto (Analista/Especialista de Negócio)

Prover informações acerca dos requisitos do produto/serviço do projeto. O Dono do Produto é o responsável pelos aspectos funcionais da solução. Deve fazer parte da equipe do projeto e estar disponível para reuniões de levantamento de requisitos e homologações das entregas.

Reponsabilidades

  • Acompanhar os processos de controle e validação dos artefatos do projeto;
  • Fornecer conhecimentos e instruções acerca da visão, regras e requisitos do negócio, bem como os aspectos funcionais da solução;
  • Fornecer informações legais;
  • Homologar as entregas dos produtos do projeto.

Competências

  • Comunicação efetiva com habilidades na escolha dos meios, feedback, escuta ativa, empatia, confiança, clareza, concisão, comunicação não-verbal;
  • Conhecimento aprofundado do negócio;
  • Percepção da estratégia, da política e da cultura da organização;
  • Tomada de decisão.

3.4.      Partes Interessadas

Interagir com a equipe do projeto, podendo exercer influência positiva ou negativa sobre os objetivos e resultados do projeto. Exemplos de partes interessadas são: Patrocinadores, Cliente, Líder do Projeto (Scrum Master ou GP), Equipe do Projeto, VMO, usuários do produto/serviço do projeto, etc.

O engajamento de cada parte interessada, sua influência, responsabilidade e competência no projeto variam de acordo com o papel assumido.

Reponsabilidades

  • Realizar a interação e a comunicação com a Equipe do Projeto;
  • Detectar necessidade de mudança no projeto.

Competências

  • Entendimento do objetivo do projeto.

3.5.      Líder do Projeto (Scrum Master ou GP)

Gerenciar as ações necessárias à realização dos projetos. Coordenar e liderar a sua equipe do projeto para garantir a entrega do produto/serviço do projeto dentro do prazo, custo e escopo acordados com as partes envolvidas.

Reponsabilidades

  • Planejar e gerenciar o projeto;
  • Definir estratégias de entregas;
  • Monitorar a execução do projeto;
  • Relacionar-se com as partes interessadas;
  • Fazer o replanejamento necessário
  • Agir para mitigar riscos;
  • Gerenciar conflito com partes interessadas;
  • Reportar a situação do projeto;
  • Manter os documentos atualizados;
  • Responder pelas ações e resultados do projeto.

Competências

  • Conhecer a Metodologia de Projetos da Atomtech;
  • Conhecer conceitos de Gestão de Projetos;
  • Formação de equipes;
  • Liderança;
  • Percepção do Planejamento Estratégico Integrado (PEI Atomtech);
  • Relacionamento interpessoal.

3.6.      Equipe do Projeto

Executar as ações necessárias para a entrega do projeto. São pessoas ou grupo de pessoas que contribuem no planejamento e execução do projeto.

Reponsabilidades

  • Executar as atividades delegadas;
  • Oferecer a sua expertise técnica;
  • Reportar a situação das tarefas sob sua responsabilidade;
  • Manter a documentação sob sua responsabilidade atualizada.

Competências

  • Capacidade de resolução de problemas;
  • Capacidade e habilidades técnicas para desenvolver as tarefas assumidas.

 

4.       Técnicas para o Gerenciamento Ágil

Com a finalidade de nortear os interessados em gerenciamento de projetos, a Atomtech listou algumas técnicas e ferramentas que apoiarão o planejamento, execução e monitoramento do projeto. Essas técnicas não são únicas. O Líder do Projeto (Scrum Master ou GP) e sua equipe, poderão utilizar e sugerir novas técnicas à Atomtech.

4.1.      Planejamento com Canvas

Um Canas de Projeto é a representação visual do Plano do Projeto, construído com a participação das diversas partes interessadas. Nesta técnica, três papeis devem participar da reunião, o Líder do Projeto (Scrum Master ou GP), a área Cliente (que entende das dores e problemas do setor), e a equipe executora do projeto (que tem conhecimento técnico sobre a execução do produto/serviço, serviço ou resultado do projeto). Essas três figuras fazem o protótipo do modelo mental do Projeto em um quadro físico, com divisões e suas tarefas inseridas ao longo do desenvolvimento do Canvas.

O Canvas tem pouquíssimas exigências (um bloco de post-it e uma folha A1) e seu objetivo é estabelecer um método intuitivo e simples para que as partes interessadas concebam a lógica do Projeto. Uma versão on-line, interativa e gratuita do Kanvas de Projeto pode ser acessada em https://kanvas.cards

O principal segredo de um Canvas é o seu poder de síntese, em que as principais características do Projeto são descritas de forma clara e objetiva. Suas características são:

  • Simplicidade: Apresenta os dados necessários de forma simples e intuitiva.
  • Agrupamentos: Reúne uma série de itens por suas afinidades.
  • Visual Limpo: Transmite todas as informações e características do Projeto em uma única visão no quadro.
  • Sequência Lógica: Apresenta uma ordem de execução clara e objetiva.
  • Interação entre Stakeholders: Promove a comunicação entre as diversas partes interessadas, assim como um melhor nível de entendimento, comunicação e expectativas acerca do Projeto.

 

Etapas do Canvas

Para o seu preenchimento devemos seguir 3 (três) etapas:

  1. Criar: Onde são respondidas algumas perguntas essências.
  2. Consolidar: Garantir a consistência. Corrigir os pontos falhos ou inconsistentes.
  3. Publicar: Exportar o painel, se necessário, para o modelo de documento, exemplo o “Plano de Gerenciamento de Projetos – PGP”, ou outro documento necessário para dar continuidade ao projeto.

 

4.1.1.     Etapa 1 – Criar

Em uma sequência lógica, a equipe irá responder as seguintes perguntas:

Por que? – O Que? – E se? – Quem? /Para quem? – Como? /Quando? /Quanto?

Essas cinco perguntas são feitas ao longo do desenvolvimento do Canvas de forma direcionada e objetiva. As respostas são colocadas através de post-its em cada componente formando assim o mapa mental do Projeto.

Lembrando: Na realidade, não existe uma sequência rígida. Apenas uma sugestão de preenchimento.  Durante o brainstorm, surgiu a ideia, anota no post-it e cola no quadro

A primeira ação é preencher o cabeçalho do Canvas:

Projeto: Frase que resume a essência do Projeto;

GP: Nome do Líder do Projeto (Scrum Master ou GP);

Data: A data de realização do Canvas.

Exemplo:

GP: José da Silva;

Projeto: Mapear os Processos dos Departamentos RH e Financeiro.

Data: 15/06

 

Responder às perguntas básicas conforme os itens:

4.1.1.1.          Por que?

O “por que?” compreende as questões que deram origem e razão ao Projeto. Os problemas, objetivos, resultados esperados do Projeto são todos respondidos nesse grupo. Aqui encontramos os seguintes componentes:

 

Passo 1 – Objetivo:

É o objetivo do Projeto, que será realizado para resolver os problemas. É utilizado apenas um post-it grande para descrever, de forma específica, realista, passível de medição e limitada ao tempo (SMART*).

Exemplo:

Mapear os Processos dos Departamentos RH e Financeiro (Cenário, Macroprocesso e Processos nível 1) da Empresa XYZ, com um custo de R$ 20.000,00 até o dia 30/09.

*Definição de SMART:

    • S – Específicos (Specific): Devem ser escritos de forma objetiva e precisa;
    • M – Mensuráveis (Measurable): Devem ser medidos e analisados em termos de valores ou quantidades;
    • A – Acordado: O objetivo deve ser acordado, aceito, pela parte Cliente e executora;
    • R – Realistas (Realistic): Os objetivos são alcançáveis, é possível de fazer considerando as limitações do projeto;
    • T – Tempo (Time-bound): Devem ser limitados no tempo, ter uma duração.

 

Passo 2 – Justificativas:

Problema que motiva uma solução e que deu origem à demanda do Projeto (passado problemático, por força da lei, alinhamento com o planejamento estratégico).  Aqui são inseridas as justificativas que deram causa ao Projeto. Deve ser utilizado um post-it pequeno para cada justificativa.

Exemplos:

    • Post-It 1 (pequeno): Excesso de documentos;
    • Post-It 2 (pequeno): Não Aderência a IN 01/2016 – GRC;
    • Post-It 3 (pequeno): Grande número erros e retrabalhos;
    • Post-It 4 (pequeno): Baixa maturidade em gestão de processos;
    • Post-It 5 (pequeno): Alinhamento com o Objetivo Estratégico 9.

 

Passo 3 – Benefícios:

São os benefícios esperados pelo Projeto. Meu futuro utilizando os benefícios gerados pelo projeto. Coisas boas, valores, positividade. São descritos em post-its pequenos, de forma que cada um represente um dos benefícios (o futuro após o termino do projeto).

Exemplos:

    • Post-It 1 (pequeno): Aderência a IN 01/2016;
    • Post-It 2 (pequeno): Maior eficiência dos Processos;
    • Post-It 3 (pequeno): Melhora nos Indicadores de Desempenho Estratégicos (KPI).

 

4.1.1.2.          O que?

Este grupo contém as informações daquilo que será feito para resolver os problemas. O produto final e os requisitos do produto/serviço fazem parte desse grupo. Eles possuem as seguintes características:

 

Passo 4 – Requisitos de Qualidade:

São as propriedades que o produto deve possuir, requisitos de aceite pelo Cliente, a definição de pronto do produto/serviço. São pedidos e acordados com o Cliente e com os executores. Define diversos aspectos do produto/serviço, tais como requisitos de aceitação (qualidade) e funções, promovendo o alinhamento das expectativas. O que eu vou verificar no produto para saber se me atende?

Deve ser utilizado um post-it pequeno para cada requisito, não sendo permitido utilizar mais de um post-it por requisito.

Quanto mais características melhor.

Exemplos:

    • Post-It 1 (pequeno): Aderente a notação BPMN v2;
    • Post-It 2 (pequeno): No mínimo 1 indicador de esforço de Processo (Driver);
    • Post-It 3 (pequeno): No mínimo 1 indicador de resultado de Processo (Outcome);
    • Post-It 4 (pequeno): Estar no formato BPM/Bizagi;
    • Post-It 5 (pequeno): Documento de detalhamento do processo com boa ortografia;

 

Passo 5 – Escopo:

Defini o que realmente será feito durante o projeto. O que será feito para atender os requisitos e gerar uma entrega.  Escopo mal definido causa um projeto mal feito.

Deve-se fazer perguntas, seguindo o nosso exemplo, do tipo:

    • O que será mapeado?
    • Qual nível de detalhe?

Exemplos:

  • Post-It 1 (pequeno): Mapeamento AS-IS;
  • Post-It 2 (pequeno): Definição de KPIs;
  • Post-It 3 (pequeno): Detalhamento dos Processos Mapeados;
  • Post-It 4 (pequeno): Entregas parciais;
  • Post-It 5 (pequeno): Desenho da Cadeia de Valor;
  • Post-It 6 (pequeno): Exportação para formato web e interativo;

 

Passo 6 – Não Escopo:

O que não faz parte e não será entregue. Deixar claro o que não será feito. Ajuda a definir as fronteiras do projeto e alinhar as expectativas.

Exemplos:

    • Post-It 1 (pequeno): Treinamento na Notação;
    • Post-It 2 (pequeno): Automação dos Processos;
    • Post-It 3 (pequeno): Mapeamento do TO-BE;
    • Post-It 4 (pequeno): Treinamento na Ferramenta;

 

4.1.1.3.          E se?

Aqui é definido os “E se…” algo acontecer no projeto, o que irá causar no projeto de bom ou ruim.  “E se…” um fato que eu considerava verdadeiro, não acontecer? “E se…” eu só tiver X dinheiros para fazer o meu projeto, como eu irei executar.

 

Passo 7 – Regras que limitam:

Premissas e Restrições. Para um canvas, não importa se é premissa ou restrição. Ambas, restringem as ações do GP, da equipe e do projeto.

As restrições geralmente são de Tempo/Custo/Escopo/Recurso Humano. Limita as ações da equipe e devem ser alguns dos limites utilizados pelo GP para o desenvolvimento do Projeto.

As premissas são suposições, hipóteses externas ao Projeto, dadas como verdadeiras para realizar o planejamento. Uma premissa não está sob o controle do Líder do Projeto (Scrum Master ou GP). Para cada premissa, o GP deve associar pelo menos um risco, que será descrito no próximo passo.

    • Limita as ações da Equipe.
    • Restrições de Tempo/Custo/Escopo
    • Suposições dadas como certas para planejamento.
    • Estou OU não estão sobre controle do GP.

Exemplos:

    • Post-It 1 (pequeno): Sobrecarga de demandas da equipe do projeto;
    • Post-It 2 (pequeno): Equipe 2 pessoas;
    • Post-It 3 (pequeno): Orçamento de R$ 20.000,00;
    • Post-It 4 (pequeno): Prazo final 31/08;
    • Post-It 5 (pequeno): Iniciar Projeto até 01/06;
    • Post-It 6 (pequeno): Disponibilidade de Usuários Chave.

 

Passo 8 – Riscos:

Identificar e escrever os riscos de forma a entender a causa e o efeito. O tamanho do post-it e a forma que ele é dividido dependerá do perfil do Projeto ou de seu líder.

O post-it pode ser simples, com apenas uma frase contendo o título do risco. Ou pode ser completo, por exemplo, escrevendo no canto superior esquerdo o “grau do impacto no Projeto”; no canto superior direito o “nome do responsável pela ação de contingência”; na metade superior do post-it o “nome do risco”; na metade inferior a “ação de contingência”.

Lembrando que para cada uma das “Premissas” elencadas no “Passo 7” deve haver, pelo menos, um risco associado.

Post-it Simples de Risco: Sobrecarga da equipe

Post-it Completo de Risco:

Sobrecarga da equipe/ Negociar o tempo do Recursos / Diretor / 4

Risco / Ação de Contingência / Pessoa Responsável / Grau de Impacto no Projeto

Exemplos:

    • Post-It 1: Sobrecarga da equipe/ Negociar o tempo do Recursos / Diretor / 4;
    • Post-It 2: Redução no orçamento / Negociar Escopo / Patrocinador / 5;
    • Post-It 3: Aumento de processos identificados / Negociar novo projeto* / Patrocinador / 3;
    • Post-It 4: Aumento de processos identificados / Negociar Escopo* / Patrocinador / 3
    • Post-It 5: Indisponibilidade de usuários / Negociar substituto / Diretor da área / 4

*Para um mesmo risco, posso adicionar várias ações de contingência.

Exemplo de um Post-It de Risco:

 

4.1.1.4.          Quem? Para quem?

Para quem estou fazendo esse projeto? Quem São os usuários do produto/serviço do projeto/serviço? Quem vai usufruir dos resultados do projeto? Quem são os envolvidos na criação do projeto (equipe)?

Passo 9 – Envolvidos:

Definir as partes interessadas (Cliente; Patrocinador; Cliente; Fatores Externos). Esses não trabalham diretamente no desenvolvimento do Projeto, mas são importantes de alguma maneira para o seu sucesso.

A equipe é formada por todos os servidores e terceirizados que trabalham no Projeto e produzem entregas nele.

Exemplos:

    • Post-It 1 (pequeno): Dono da Empresa (Patrocinador);
    • Post-It 2 (pequeno): Diretores das Áreas (Clientes);
    • Post-It 3 (pequeno): Colaboradores do RH/Financeiro (Usuários Chave);
    • Post-It 4 (pequeno): Demais colaboradores (Usuários).
    • Post-It 5 (pequeno): José (Analista de Processo).
    • Post-It 6 (pequeno): Maria (Analista de Processo).

 

4.1.1.5.          Como? Quando? Quanto?

Define como será feito o Projeto e seu planejamento, baseando-se nas premissas informadas pelos Stakeholders, pelas restrições de escopo, custo, prazo e equipe, finalizando-se com as entregas que podem ser tanto de fase como do Projeto.

 

Passo 10 – Entregas | Datas | Custos:

Entregas: São itens que serão entregues nas fases ou no Projeto. São tangíveis e concretas. Não é necessário que uma entrega de fase do Projeto seja visível para o Cliente, no entanto, deve agregar valor ao projeto com um todo.

Datas: Toda entrega definida obrigatoriamente deve ser associada a uma data limite.

Custos: Associado as Entregas e ao Cronograma. Quais são minhas estimativas de gasto (em trabalho ou dinheiro)? Em linhas gerais para cada entrega deve ser pago uma ordem de serviço ou uma nota fiscal, ou seja, tem um custo associado. Mesmo que seja um custo interno (a equipe do projeto já está na folha de pagamento da empresa), existe um custo em horas gastas com o projeto que deve ser negociado com o coordenador da área.

É uma boa prática, quando falamos de custos, reservar uma parcela do orçamento (reserva de contingência) para cobrir imprevistos no Projeto. Essa porcentagem é definida em cada Projeto. Como padrão, é assumido um valor de 10% (dez por cento) do orçamento total do Projeto.

Exemplos:

    • Post-It 1: Cadeia de Valor – Aprovada | 15/06 | R$ 3.000,00;
    • Post-It 2: Macroprocessos Financeiro – Identificados | 30/06 | R$ 1.000,00;
    • Post-It 3: Macroprocessos RH – Identificados | 30/06 | R$ 1.000,00;
    • Post-It 4: Processos Financeiro – Nível 1 – Mapeados | 30/07 | R$ 2.500,00;
    • Post-It 5: Processos RH – Nível 1 – Mapeados | 30/07 | R$ 2.500,00;
    • Post-It 6: Processos Financeiro – Nível 1 – Mapeados | 30/07 | R$ 2.500,00;
    • Post-It 7: Detalhamento dos Processos RH – Aprovados | 31/08 | R$ 5.000,00;
    • Post-It 8: Detalhamento dos Processos Financeiro – Aprovados | 31/08 | R$ 5.000,00;

 

4.1.2.     Etapa 2 – Consolidar

A etapa de consolidação é o momento em que todos os participantes da reunião reverão os post-its e identificarão falhas (gaps) no planejamento.

Com o Canvas todo montado e debatido, esse é o melhor momento para identificar erros e melhorias no planejamento, uma vez que a equipe já tem conhecimento do objetivo, dos requisitos, dos envolvidos, das entregas e demais itens relevantes ao Projeto.

Post-its podem ser retirados, adicionados e reescritos conforme necessário.

É possível que quando a equipe chega nessa etapa, já estão em vias de estarem fadigados mentalmente devido ao brainstorm de planejamento. Forçar uma solução quando a equipe já está cansada é uma ação improdutiva.

Caso a equipe entre em divergência acerca dos itens específicos do Planejamento do Projeto, e não exista consenso ou solução para o problema identificado, cada membro deve anotar os itens pendentes e deve pensar sobre uma possível solução em outro momento. Caso seja necessário, marcar uma reunião futura, ou apenas enviar a solução para o Líder do Projeto (Scrum Master ou GP) por e-mail.

 

4.1.3.     Etapa 3 – Publicar

Se para o tipo de Projeto, ou para o Sistema Indústria, for necessário criar um Plano de Gerenciamento de Projetos (PGP) formal, com assinatura digital ou outro rito processual inerente do órgão, o Líder do Projeto (Scrum Master ou GP) deverá consolidar as informações do Canvas no TA e/ou PGP e submetê-lo ao sistema de processo administrativo eletrônico do Sistema Indústria, conforme exigido pelo procedimento interno.

 

4.2.      Criando a Visão do Produto com o Product Vision Box

O principal objetivo da técnica Product Vision Box (Produto na Caixa) é extrair a visão de produto dos Clientes e Stakeholders

A dinâmica é simples: criar uma caixa que represente sua solução, com toda a riqueza de informações que fariam um cliente pegar seu produto na prateleira em vez de um concorrente.

Deve chamar a atenção dos potenciais clientes, exibindo de forma clara e objetiva quais são as principais características e benefícios e porque comprar a solução.

O exercício fará com que a sua equipe reflita e discuta quais são os atributos mais importantes do seu produto, uma vez que para montar uma caixa que chame a atenção na prateleira não podemos enchê-la de texto, e sim usar algumas poucas características principais para atrair o cliente.

A discussão em torno de quais atributos realmente são os mais evidentes do produto e quais chamam mais a atenção do público-alvo contribui bastante para que a equipe chegue a uma visão consensual do que é de fato esse produto, quais são os seus atributos chave e quem são os compradores que vão se interessar pelo produto quando estiverem passando pela prateleira.

Sugestão de campos:

  • Nome do produto
  • Nome do fabricante
  • Slogan
  • Ficha de informações “nutricionais” (características)
  • Benefícios e Diferenciais
  • Desenhos e símbolos relacionados ao seu produto
  • Bônus que vêm junto com a caixa
  • Tecnologia

 

 

4.3.      Planejando o Backlog do Produto/Serviço com Épicos e Histórias de Usuário

O conceito é dividir o seu produto/serviços em partes menores, visuais e agrupadas com o objetivo de facilitar o entendimento e a priorização.

O produto/serviço é dividido em três níveis principais:

Épicos

  • São histórias de usuários longas
  • Precisam ser quebradas
  • Muitas vezes não cabem numa sprint

Temas (fases)

  • Coleção de Histórias de Usuário
  • Objetivo de organizar as histórias
  • Agrupadas por afinidade, por tema

Histórias de Usuário

  • O que o cliente realmente quer
  • Curta e objetiva.

4.3.1.     Uma História de Usuário deve ser:

4.3.1.1.          Independentes

As histórias devem ser independentes para facilitar a priorização no Backlog.

Exemplo:

“Forma de pagamento de uma compra em minha loja virtual.”

Errado: (Não consigo priorizar qual forma de pagamento deve ser feito primeiro)

    • Pagamento com Dinheiro, Boleto e Cartão.

Certo: (Consigo priorizar qual forma deve ser feito primeiro)

    • 1º – Pagamento com PayPal
    • 2º – Pagamento com Boleto Bancário
    • 3º – Pagamento com Cartão de Débito
    • 4º – Pagamento com Cartão de Credito

 

4.3.1.2.          Negociável

Uma história não é um documento extenso e detalhista. Deve existir uma conversa entre o Dono do Produto e o Time.

Deve ser feita a seguinte pergunta: “Como eu sei que está Pronto (done)?”

Exemplo:

“Na minha loja virtual, deve ter um login para autenticar o usuário.”

O Time deve perguntar: “Como eu sei que está Pronto (done)?

O Dono do Produto deve responder:

    1. E-mail
    2. Senha
    3. 5 tentativas para bloquear
    4. Recuperar senha por e-mail

A mensagem de envio de senha é:
“Senha enviada para o e-mail meuemail@dominio.com.br

 

4.3.1.3.          Valiosa

A história deve gerar valor para o produto/negócio.

Deve ser feita a seguinte pergunta: “Para que estamos fazendo essa história?”

Exemplo:

“Forma de pagamento de uma compra em minha loja virtual.”

Errado: (texto muito técnico e sem valor para o cliente)

    • Minha loja virtual deve ter balanceamento de carga, alta disponibilidade e RAID 10 com disco SSD.

Certo:

    • Minha loja virtual deve ter disponibilidade de 99% para os meus clientes.

 

4.3.1.4.          Estimável

Uma história deve ser possível estimar para dimensionar o Tamanho, Tempo, Complexidade e Esforço

 

4.3.1.5.          Pequena

Cada história deve consumir pouco tempo, desde o começar até o “pronto”, deve ser Simples e Funcional (MVP – Mínimo Produto Viável)

Exemplo:

Errado:

    • Na minha loja virtual, o usuário pesquisa os produtos e pode ordenar com diversas opções, filtrar e adicionar no carrinho.

Certo:

    • O usuário Pesquisa;
    • O usuário ordena por ordem Alfabética;
    • O usuário ordena por ordem Numérica;
    • O usuário filtra por Preço;
    • O usuário adiciona item no carrinho de compras.

 

4.3.1.6.          Testável

Deve existir um Controle de Qualidade, ou seja, critérios de aceitação testáveis.

Exemplo:

Errado:

    • Na minha loja virtual, o sistema deve carregar a página rapidamente quando o usuário executar qualquer ação.

Certo:

    • Na minha loja virtual, o sistema deve carregar a página em até 10 segundos.

 

4.4.      Priorizando Itens

4.4.1.      MoSCoW

A técnica MoSCoW tem foco no Produto e é utilizada para gerenciar as expectativas do Cliente bem como a priorização de requisitos que irão entregar maior benefício.

    1. MUST: Deve ser implementado o requisito, ou seja, é vital. Caso contrário a release/sprint não irá entregar valor ao negócio.
    2. SHOULD: (Deveria) É muito importante, contudo não impactam no sucesso da release/sprint.
    3. COULD: (Poderia) É bom ter, contudo, será incluído apenas se não afetar no prazo da release/sprint
    4. WON’T (WOULD): Não será ou Não é necessário desenvolver ou Poderá ser implementado no futuro caso tenha tempo ou recurso disponível

4.4.2.     Early Victory – A Primeira Vitória o mais cedo.

Buscar a primeira vitória no projeto o mais cedo. A primeira entrega deve ser a que gera maior valor para o cliente.

A lógica é: Com o cliente feliz, você conquista o cliente.  Equipe ganha força e a Equipe se sente confiante.

 

4.4.3.     Quick Wins – Ganhos Rápidos

Caracterizam por serem de fácil implementação, curta duração para implementação, não exigirem muitos recursos, trazerem ganhos de curto prazo.

 

4.4.4.     Matriz de Valor x Risco e a Matriz Valor x Esforço

Essas duas matrizes seguem o mesmo raciocínio do Quick Wins de ter ganhos rápidos. Devemos distribuir as atividades em quadrantes facilitando a priorização, a visualização e o planejamento das próximas entregas.

 

 

4.4.5.     Pareto (80/20)

Uma regra simples que diz, em linhas gerais, que 80% das consequências provêm de 20% das causas. Ou seja, se priorizarmos e resolvermos 20% das causas raiz dos problemas, resolveremos 80% das dores de cabeça.

 

4.4.6.     Compre uma Funcionalidade (Buy a Feature)

4.4.6.1.          Como aplicar a dinâmica:

    1. Entregue uma quantidade de dinheiro de banco imobiliário para cada participante
    2. O Dono do Produto escreve as histórias dos itens em cartões. Esses cartões serão apenas dos itens mais próximos no roadmap e/ou são importantes ao projeto.
    3. O Dono do Produto lê o cartão e explica a funcionalidade. Opcionalmente, pode adicionar um preço para essa funcionalidade, que pode ser horas, complexidade ou outra métrica.
    4. Sem regras, cada participante deposita um pouco do dinheiro na linha do cartão que deseja sua implementação, priorizando. Como o dinheiro (verba) é limitado serão obrigados a trabalhar com esta limitação.
    5. No final, some quanto cada cartão recebeu. Os que receberam mais dinheiro são os mais prioritários.
    6. Crie um momento para uma pequena discussão sobre o resultado. Essa discussão poderá gerar algumas movimentações do dinheiro. Contudo ao final da sessão o que foi definido será o utilizado para montar o Backlog.

4.4.6.2.          Dicas:

    • Avise que o usuário só poderá usar uma funcionalidade se ele comprá-la.
    • Não adicione itens técnicos demais ou muito específicos.
    • Use dinheiro falso. Quando seguram o dinheiro, elas percebem mais valor nele e isso cria uma sensação de escassez. Assim, elas serão muito mais criteriosas na hora de investir.
      Atenção! Não permita a fabricação de dinheiro falso, lavagem de dinheiro aproveitado de outras dinâmicas ou trazendo de casa.
    • Avise que não necessariamente o item mais comprado será o próximo a ser produzido, uma vez que pode existir precedência de atividade.
    • Peça ajuda de alguém de fora do time para anotar os principais comentários dos participantes. E também tenha um moderador para ajudar a extrair novas ideias e informações durante a dinâmica. Ele também deverá controlar os debates intermináveis que surgirão.
    • Se existirem muitos itens para priorizar, envie com antecedência uma lista com os itens.

 

4.5.      Medindo o Esforço com o Planning Poker

O Planning Poker é uma técnica de estimativa da quantidade de esforço necessário para atingir um objetivo. Por meio de um jogo de cartas, permite que a Equipe exponha a sua visão de complexidade (tempo e esforço), pontuando, debatendo e, em consenso, chegar a um valor comum. Outro objetivo é o de colaborar com o entendimento que cada integrante tem sobre uma determinada funcionalidade.

No Planning Poker cada integrante tem a sua disposição um baralho de 13 cartas, numeradas em uma sequência similar a encontrada nos números de Fibonacci. As cartas contêm os tamanhos de 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 e 100 que serão atribuídos a um cartão, havendo ainda uma carta com o símbolo de interrogação, a qual representa que o estimador não está apto a estimar, e outra carta com a imagem de uma xícara de café que representa, por sua vez, a sugestão de uma pausa.

Durante a reunião de Planning Poker devem ser realizadas rodadas para obter a estimativa de esforço para uma determinada funcionalidade ser desenvolvida. As diferenças que surgirem durante as rodadas deverão ser mediadas pelo Líder do Projeto (Scrum Master ou GP). O Cliente é o responsável por explicar o que deverá ser desenvolvido, retirando dúvidas a respeito da funcionalidade, evitando assim o retrabalho.

Passo a passo do Planning Poker:

  • As funcionalidades são apresentadas, uma a uma, e as dúvidas da Equipe são sanadas;
  • Atribui-se o peso 2 à menor funcionalidade, que servirá de comparativo para as demais;
  • Inicia-se com uma funcionalidade, podendo ser por ordem de prioridade, e todos jogam a carta ao mesmo tempo;
  • Deve-se discutir a variação de estimativa (porque um integrante estimou X e outro estimou Y);
  • No final, a Equipe chega a um consenso e define o peso da funcionalidade, partindo para a estimativa da próxima.

 

Não é recomendo que os integrantes falem os números em vez de exibirem uma carta, uma vez que o primeiro a falar poderá influenciar a pontuação dos próximos.

 

4.6.      Delegando e Controlando a Execução com o Kanban

O Kanban, assim como quase todas as técnicas ágeis permite uma flexibilização na sua estrutura para adaptar a necessidade do cliente, time ou projeto. O Kanban indica o andamento do fluxo de produção através de post-its. Não existe uma forma única de criar um Kanban, podendo ser tão simples ou tão complexo dependendo da sua necessidade. A cada X números de post-its na coluna “Entregue (Feito/Done)” realiza-se uma retrospectiva.

Veja alguns exemplos

 

4.6.1.     Kanban Tradicional

Seu funcionamento consiste no uso de post-its para tornar visual o acompanhamento da execução das tarefas e o andamento dos fluxos de produção do produto/serviço. O Kanban mais simples é constituído de 3 colunas divididas em “a fazer”, “fazendo” e “feito”, conforme o andamento do projeto o post-it muda de coluna representando o estágio atual da tarefa.

Com essa ferramenta, é possível compreender o fluxo de trabalho e identificar gargalos, filas e atrasos no desenvolvimento.

 

 

4.6.2.     Kanban em Flecha (Kanban Arrow)

O Kanban, pode ser simples ou complexo. O mais importante é a equipe saber explorar e adaptar os recursos a sua realidade.

4.6.2.1.          Triângulo de Prioridade do Backlog

A função do triângulo de prioridade é visualizar e ajudar com a priorização do backlog.

    • P1 adicionar os 3 itens com prioridade alta.
    • P2 adicionar os 6 itens com prioridade média.
    • P3 adicionar os 12 itens com prioridade baixa.

4.6.2.2.          Raias

A função da raia é limitar o trabalho em andamento, ou seja, impedir que as pessoas assumam mais atividades (itens) que elas realmente conseguirão cumprir. O número de raias depende do tamanho e eficiência da equipe.  Em uma equipe com várias pessoas, ter apenas uma raia poderá deixar algumas ociosas em momentos diferentes. Uma dica é, supondo que sua equipe tenha 6 pessoas, tenha 3 raias, ou seja duas pessoas por história, para os pares se ajudarem.

 

4.6.2.3.          Colunas (as etapas do processo)

As etapas (colunas) devem refletir as etapas que você tem em seu processo (ou seja, elas podem não ser as mesmas da foto).

4.6.2.4.          DoD

Cada coluna/etapa uma definição de pronto (DoD – Definition of Done). São os critérios, checklist, que deixam claro quando uma determinada atividade foi concluída.

4.6.2.5.          Pronto (Ponto da Flecha)

A finalidade de deixar uma quantidade de post-its é para a equipe ver suas conquistas por um período maior de tempo. Após um determinado número de post-its, exemplo 20, faça uma retrospectiva, o que deu certo ou errado. Após uns 50 post-its, comemore com a equipe, exemplo, com um bolo e remova os post-its da ponta da flecha.

4.6.2.6.          Objetivos

Na frente da seta, imprima os objetivos que devem alcançados com o projeto, isso irá ajudar a equipe a orientar-se no trabalho diário. Exemplo. ” Vamos resolver esse problema dessa maneira”.

4.6.2.7.          Classes de serviço (cores dos post-its)

O objetivo é categorizar o trabalho. No exemplo são usadas:

    • Verde – Nova funcionalidade
    • Azul – Melhoria em alguma entrega/funcionalidade
    • Amarelo – Correção em alguma funcionalidade (produto/serviço) já entregue.

4.6.2.8.          Acelerar (linha rápida)

Quando algo crítico, urgente, acontece e é necessário para alguma atividade para executar algo que não foi planejado. O Dono do produto e Cliente devem estar cientes de que colocar na linha rápida irá atrasará todos os outros trabalhos em andamento. Essa raia deve ser usada com cautela.

 

4.7.      Monitorando com o Gráfico Burndown

O Burndown é um tipo de gráfico que explicita o andamento do seu projeto.

  • No eixo vertical fica o somatório de pontos de esforço necessários para realizar as atividades do seu Backlog.
  • No eixo horizontal, os dias/semanas de trabalho da iteração.
  • A linha verde mostra andamento idealmente planejado pela equipe. Uma vez que, a mesma equipe seja mantida em trabalho durante toda a iteração, a produtividade deve se manter constante diariamente.
  • A linha azul mostra o trabalho realmente realizado pela equipe. Se a linha azul estiver acima da linha verde significa que a equipe está produzindo menos que o prometido.
  • A Linha pontilhada de tendência, trend line, simula, baseado no seu rendimento do trabalho da equipe, quando a equipe irá terminar o trabalho prometido.
  • A barra em laranja, indica o esforço realizado a cada medição da equipe.

 

 

4.8.      Monitorando as Partes Interessadas com a Matriz de Poder x Interesse x Influência

Para um projeto funcionar bem é importante o líder do projeto monitorar as partes interessadas no produto/serviço. O objetivo é criar uma lista de pessoas com interesse no seu projeto e definir a melhor forma de comunicar e influenciar. Obter o apoio ao seu projeto ou impedir que resistentes criem entraves.

Email

Frederico Ribeiro Ramos

URL

Views:
459
Article Tags:
· · · ·
Article Categories:
Projetos