Você está na página 1de 37

Gestão Ágil de Projetos -

Modelo de Processos do
Planejamento
M.a. Érika Giulia Fragas Santana
A gestão ágil de projetos é baseada em
princípios e práticas que valorizam a
flexibilidade, a colaboração e a entrega
incremental de valor ao cliente. No contexto
da metodologia ágil, o planejamento é
contínuo e adaptativo, em contraste com
abordagens mais tradicionais que enfatizam
um plano detalhado no início do projeto.
TÓPICOS EM
PLANEJAMENTO ágil
1 Identificação de Objetivos e Requisitos:

Compreensão clara dos objetivos do projeto e das necessidades


dos stakeholders.
Definição de requisitos funcionais e não funcionais.
2 Criação do Backlog do Produto:

Desenvolvimento de uma lista priorizada de funcionalidades,


histórias de usuários ou itens de trabalho.
Priorização baseada no valor percebido pelo cliente.
3 Planejamento da Release:

Determinação do escopo da próxima entrega (release).


Estimativas de esforço e recursos necessários.
Definição de critérios de aceitação para as funcionalidades.
4 Planejamento da Sprint:

Seleção de itens do backlog para inclusão na próxima iteração


(sprint).
Definição de metas específicas para a sprint.
Estimativas de tempo para as tarefas selecionadas.
4 Planejamento da Sprint:

Seleção de itens do backlog …


O termo "backlog" é amplamente utilizado em contextos de gestão
de projetos, especialmente em metodologias ágeis como o Scrum.
O backlog refere-se a uma lista priorizada de itens, histórias de
usuários ou tarefas que aguardam implementação ou execução
em um projeto. Existem dois tipos principais de backlog: o Backlog
do Produto e o Backlog da Sprint.
5 Reunião de Planejamento da Sprint:

Discussão detalhada das tarefas e definição de como serão


implementadas.
Compromisso da equipe em relação às metas da sprint.
6 Desenvolvimento e Acompanhamento Diário:

Implementação das funcionalidades planejadas durante a sprint.


Reuniões diárias para acompanhar o progresso e ajustar planos
conforme necessário.
7 Revisão da Sprint:

Demonstrar as funcionalidades implementadas.


Obter feedback dos stakeholders.
Refletir sobre o que foi bem-sucedido e o que pode ser melhorado.
8 Retrospectiva da Sprint:

Avaliação do desempenho da equipe e identificação de melhorias.


Ajustes no processo para aumentar a eficiência.
9 Atualização do Backlog do Produto:

Revisão e atualização do backlog com base no feedback e nas


mudanças nas prioridades.
Iteração dos Passos 3 a 9:

Repetição dos passos de 3 Planejamento da Release;


planejamento, 4 planejamento da Sprint;
desenvolvimento, revisão e
retrospectiva em ciclos 5 Reunião de Planejamento da Sprint;
iterativos. 6 Desenvolvimento e
Acompanhamento Diário;
7 Revisão da Sprint;
8 Retrospectiva da Sprint;
9 Atualização do Backlog do Produto.
Exemplo de Projeto:
Desenvolvimento de
um Aplicativo de
Gerenciamento de
Tarefas
1 Identificação de Objetivos e Requisitos:

Compreensão clara dos O QUE SÃO REQUISITOS


objetivos do projeto e das FUNCIONAIS E NÃO
necessidades dos FUNCIONAIS?
stakeholders.
Definição de requisitos
funcionais e não funcionais.
1 Identificação de Objetivos e Requisitos:

O QUE SÃO REQUISITOS


FUNCIONAIS E NÃO
FUNCIONAIS? Os requisitos funcionais descrevem as
funcionalidades específicas e as operações que o
sistema deve realizar. Eles se concentram nas
ações que o sistema deve executar em resposta
a determinadas entradas ou condições. Os
requisitos funcionais geralmente respondem à
pergunta "O que o sistema deve fazer?" e são
essenciais para a construção de uma solução
que atenda às necessidades dos usuários.
1 Identificação de Objetivos e Requisitos:

EXEMPLO FUNCIONAIS

Adicionar Tarefa:
O sistema deve permitir que o usuário adicione uma nova tarefa, fornecendo
um título, descrição e data de vencimento.
Editar Tarefa:
O sistema deve permitir que o usuário edite uma tarefa existente,
modificando o título, a descrição ou a data de vencimento.
Excluir Tarefa:
O sistema deve permitir que o usuário exclua uma tarefa existente.
1 Identificação de Objetivos e Requisitos:

O QUE SÃO REQUISITOS


FUNCIONAIS E NÃO
FUNCIONAIS? Os requisitos não funcionais referem-se a atributos do
sistema que não estão relacionados diretamente com
as funcionalidades específicas, mas sim com as
características que afetam a qualidade e o
desempenho do sistema como um todo. Eles
geralmente respondem à pergunta "Como o sistema
deve operar?" e são cruciais para garantir que o
sistema atenda a padrões de desempenho,
segurança, usabilidade, entre outros.
1 Identificação de Objetivos e Requisitos:

EXEMPLO NÃO FUNCIONAIS

Desempenho: O sistema deve carregar a lista de tarefas em menos de 2


segundos, mesmo quando houver 1000 tarefas cadastradas.
Segurança: A autenticação de usuários deve ser realizada utilizando criptografia
SSL para garantir a segurança das informações.
Usabilidade: A interface do usuário deve ser intuitiva, permitindo que usuários
sem treinamento prévio consigam adicionar, editar e excluir tarefas facilmente.
Disponibilidade: O sistema deve estar disponível 99% do tempo durante o
horário comercial.
Manutenibilidade: O código-fonte deve ser documentado de forma clara,
facilitando futuras manutenções e atualizações.
1 Identificação de Objetivos e Requisitos:

Compreensão clara dos Objetivo do Projeto: Desenvolver


objetivos do projeto e das um aplicativo de gerenciamento
necessidades dos de tarefas para ajudar usuários a
stakeholders. organizar suas atividades diárias.
Definição de requisitos
Requisitos Iniciais: Interface
funcionais e não funcionais.
intuitiva, capacidade de adicionar,
editar e excluir tarefas,
notificações de lembrete.
2 Criação do Backlog do Produto:

Desenvolvimento de uma lista O Product Owner colabora com


priorizada de funcionalidades, stakeholders para criar um
histórias de usuários ou itens Backlog do Produto que inclui
de trabalho.
itens como "Criar Página
Priorização baseada no valor Inicial", "Implementar
percebido pelo cliente. Funcionalidade de Adicionar
Tarefa", etc.
Itens são priorizados com base
no valor para o usuário.
2 Criação do Backlog do Produto:
Itens são priorizados com base
no valor para o usuário. A priorização com base no valor para o
usuário é um princípio fundamental na
gestão ágil de projetos, especialmente
em metodologias como o Scrum. Essa
abordagem destaca a importância de
concentrar os esforços da equipe de
desenvolvimento nas funcionalidades
que proporcionarão o máximo valor para
os usuários finais ou stakeholders.
2 Criação do Backlog do Produto:
Itens são priorizados com base
no valor para o usuário.
Identificação do Valor:
A equipe e os stakeholders colaboram para identificar quais
funcionalidades ou requisitos são considerados mais valiosos do ponto de
vista do usuário ou do negócio.
Entendimento das Necessidades do Usuário:
É crucial compreender profundamente as necessidades, expectativas e
desejos dos usuários finais. Isso pode envolver entrevistas, pesquisas de
usuário, feedback contínuo e outras técnicas de coleta de informações.
2 Criação do Backlog do Produto:
Itens são priorizados com base no valor para o usuário.
Priorização Contínua:
O backlog do produto, que é a lista de funcionalidades a serem
desenvolvidas, é constantemente atualizado e repriorizado com base nas
mudanças nas necessidades do usuário, feedback e evolução do contexto
do projeto.
Métricas de Valor:
Métricas podem ser usadas para quantificar o valor percebido. Por
exemplo, a equipe pode considerar métricas como o impacto nas taxas de
conversão, na satisfação do cliente ou em outros indicadores-chave de
desempenho relevantes para o negócio.
2 Criação do Backlog do Produto:
Itens são priorizados com base no valor para o usuário.
MVP (Produto Mínimo Viável):
A ideia de MVP é desenvolver primeiro as funcionalidades
essenciais que entregam valor significativo aos usuários. Isso
permite uma entrega mais rápida e contínua de valor, enquanto
outras funcionalidades menos críticas podem ser adicionadas
posteriormente.
2 Criação do Backlog do Produto:
Itens são priorizados com base no valor para o usuário.
Adaptação Contínua:
A equipe deve estar disposta a se adaptar continuamente com
base no feedback e nas mudanças nas prioridades do usuário.
Isso significa que o plano do projeto pode ser ajustado a
qualquer momento para garantir que a equipe esteja sempre
focada nas atividades mais valiosas.
2 Criação do Backlog do Produto:
Itens são priorizados com base no valor para o usuário.
Envolvimento do Product Owner:

O Product Owner desempenha um papel-chave na priorização,


representando os interesses dos stakeholders e tomando
decisões informadas sobre o que deve ser desenvolvido em
cada iteração.
3 Planejamento da Release: (PRIMEIRA VERSÃO, BÁSICA)
Determinação do escopo Meta da Release 1.0: Desenvolver
da próxima entrega as funcionalidades básicas para o
(release). lançamento inicial.

Estimativas de esforço e Estimativas: A equipe estima que a


release levará 8 semanas.
recursos necessários.
Critérios de Aceitação: Interface
Definição de critérios de intuitiva, funcionalidades de
aceitação para as adicionar, editar e excluir tarefas
funcionalidades. implementadas.
4 Planejamento da Sprint:

Seleção de itens do Sprint 1: A equipe seleciona itens


backlog para inclusão na do topo do backlog para a primeira
próxima iteração (sprint). sprint, como "Criar Página Inicial"
Definição de metas e "Implementar Funcionalidade de
específicas para a sprint. Adicionar Tarefa".
Estimativas de tempo para As tarefas são definidas, como
as tarefas selecionadas. "Design da Página Inicial",
"Desenvolvimento do Frontend",
"Configurar Banco de Dados para
Tarefas", etc.
5 Reunião de Planejamento da Sprint:

Discussão detalhada das A equipe discute como


tarefas e definição de implementar cada tarefa e estima
como serão
o tempo necessário.
implementadas.
Compromisso da equipe Compromissos são feitos para
em relação às metas da concluir as tarefas durante a
sprint. sprint.
6 Desenvolvimento e Acompanhamento Diário:

Implementação das A equipe trabalha nas tarefas


funcionalidades planejadas diariamente, atualizando o
durante a sprint.
progresso nas reuniões diárias.
Reuniões diárias para
acompanhar o progresso e Se surgirem impedimentos, a
ajustar planos conforme equipe os discute para
necessário. resolvê-los rapidamente.
SPRINT

Uma "Sprint" é uma unidade de tempo fixa durante a qual um


conjunto específico de atividades ou incrementos de trabalho é
executado. Sprint é um conceito central em metodologias
ágeis, como o Scrum. No Scrum, uma Sprint tem uma duração
predefinida, comumente entre 1 e 4 semanas, sendo 2
semanas uma escolha bastante comum. Durante essa Sprint, a
equipe se concentra em entregar um conjunto de
funcionalidades ou incrementos que agregam valor ao produto.
7 Revisão da Sprint:

Demonstrar as Ao final da sprint, a equipe


funcionalidades
demonstra a funcionalidade
implementadas.
implementada.
Obter feedback dos
stakeholders. Feedback é coletado dos
Refletir sobre o que foi stakeholders, e ajustes no
bem-sucedido e o que backlog podem ser feitos.
pode ser melhorado.
8 Retrospectiva da Sprint:

Avaliação do desempenho A equipe revisa o desempenho


da equipe e identificação durante a sprint.
de melhorias. Identifica-se que as estimativas de
Ajustes no processo para tempo foram precisas, mas a
aumentar a eficiência. comunicação pode ser aprimorada.
A equipe decide ajustar as reuniões
diárias para melhorar a
comunicação.
9 Atualização do Backlog do Produto:

Revisão e atualização do O Product Owner atualiza o


backlog com base no backlog com base no feedback
feedback e nas mudanças da sprint e nas novas
nas prioridades. necessidades identificadas.
Novos itens são adicionados, e
as prioridades são ajustadas.
Iteração dos Passos 3 a 9:

Repetição dos passos de 3 Planejamento da Release;


planejamento, 4 planejamento da Sprint;
desenvolvimento, revisão e
retrospectiva em ciclos 5 Reunião de Planejamento da Sprint;
iterativos. 6 Desenvolvimento e
Acompanhamento Diário;
7 Revisão da Sprint;
8 Retrospectiva da Sprint;
9 Atualização do Backlog do Produto.

Você também pode gostar