Aula05 - Metodologias Ágeis

GERÊNCIA DE
PROJETOS
GESTÃO DE PROJETOS DE
SOFTWARE e as
METODOLOGIAS ÁGEIS
UNIVERSIDADE FEDERAL DE PELOTAS
DANIELA F. BRAUNER
DANI@INF.UFPEL.EDU.BR

Sumário
1. Gerenciamento de projetos
2. PMBOK e Metodologias Ágeis
3. Introdução às Metodologias Ágeis
4. O uso de Metodologias Ágeis
5. SCRUM
5.1. O que é?
5.2. Os papéis
5.3. O processo
5.4. Práticas e artefatos
5.4.1. User stories
5.4.2. Priorização de user stories
5.4.3. Planning Poker
5.4.4. Gráfico Burndown
5.4.5. Kanban
5.5. Certificação

“O gerenciamento de projetos é a aplicação
de conhecimento, habilidades, ferramentas
e técnicas às atividades do projeto a fim de
atender aos seus requisitos.”
PMBOK, 4a
edição.
Revisando...

PMBOK
✓ Planejamento
completo e
abrangente;
✓ Ideal para projetos
onde se vislumbra que
o planejado será
seguido até o final do
projeto;
✓ Áreas do
conhecimento do
PMBOK apoiam o
gerente;
Metodologia Ágil
✓ Planejamento interativo
e incremental;
✓ Ideal para projetos com
alto grau de incertezas;
✓ MUDANÇAS previstas;
✓ Não perder tempo com
documentação;
✓ Aproximar as
expectativas do cliente;

PMBOK
Áreas de conhecimento:
– Gerenciamento da Integração
– Gerenciamento de Escopo
– Gerenciamento de Tempo
– Gerenciamento de Custos
– Gerenciamento de Qualidade
– Gerenciamento das Aquisições
– Gerenciamento de Recursos Humanos
– Gerenciamento das Comunicações
– Gerenciamento de Risco
– Gerenciamento das Partes Interessadas
Mais informações: http://brasil.pmi.org

Metodologias Ágeis
• Processos iterativos e incrementais para
gerenciamento de projetos e desenvolvimento
de software;
• É indicado para projetos com altos graus de
incertezas;
PMBOK + Metodologias ágeis = complementares

Requisitos
Tecnologia
Metodologias
Ágeis

THE CHAOS REPORT
FONTE: CHAOS Report 1995. Standish Group. https://www.projectsmart.co.
uk/white-papers/chaos-report.pdf
Standish Group: uma organização de pesquisa com foco em
desempenho de projetos de software, criada em 1985.
• Os motivos de falhas em projetos de
software.
• Os ingredientes para reduzir falhas.

CONSTRUÇÃO DE
PONTES X SOFTWARE
• Feitas no tempo
• Feitas no orçamento
• Não são feitas para cair
• Projetos com planejamentos
extremamente detalhados
• O projeto tem pouca flexibilidade
para sofrer mudanças de
especificação
• Quando uma ponte cai, é
realizada uma investigação e um
relatório é escrito sobre as
causas da falha (se aprende
com os erros)
• Raramente são feitos no tempo
• Raramente são feitos no
orçamento
• Sempre apresentam falhas
• Nem sempre há planejamento
• O projeto deve ter flexibilidade
para acomodar mudanças
• Nem sempre se aprende com os
erros… então continuamos
cometendo os mesmo erros de
sempre
FONTE: CHAOS Report 1995. Standish Group. https://www.
projectsmart.co.uk/white-papers/chaos-report.pdf

RESULTADOS DO
THE CHAOS REPORT
• 52.7% dos projetos custarão 189% do estimado.
• 31.1% dos projetos são cancelados.
• 16,2% dos projetos são finalizados no tempo e no
orçamento planejado.
• 9% dos projetos de grandes empresas são finalizados no
tempo e no orçamento planejado.
• Projetos finalizados, em grandes empresas, atendem em
média 42% das características inicialmente planejadas.
• Projetos finalizados, em pequenas empresas, atendem
74,2% das características inicialmente planejadas.

FATORES QUE DESAFIAM
OS PROJETOS DE SOFTWARE

FATORES QUE COMPROMETEM
OS PROJETOS DE SOFTWARE

FATORES DE SUCESSO DOS
PROJETOS DE SOFTWARE

COMO…
…flexibilizar o desenvolvimento em
•Projetos plurianuais
•Projetos envolvendo múltiplas tecnologias
•Projetos de pesquisa
Com:
•Alta incerteza e ambientes dinâmicos
•Problema: mudanças significativas ocorrem nas
necessidades que um produto deve endereçar e
nas tecnologias que ele deve utilizar
?

LIDANDO COM
INCERTEZAS
Em 2001, o prof. Alan MacCormack estudou abordagens
da época e sugeriu novas abordagens e práticas que
poderiam começar a substituir o ciclo de vida de
desenvolvimento de software:
• Entrega antecipada da arquitetura
• Compilação diária de código
• Retorno rápido quanto às alterações
• Equipes capacitadas
MacCormack, A.: Why Evolutionary Software Development Works, Harvard Business School,
2001.

O MANIFESTO ÁGIL
http://www.manifestoagil.com.br

PRINCÍPIOS
DO MANIFESTO ÁGIL (1 DE 2)
1. Nossa maior prioridade é satisfazer o cliente, através da entrega
adiantada e contínua de software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.
Processos ágeis se adequam a mudanças, para que o cliente possa
tirar vantagens competitivas.
3. Entregar software funcionando com freqüencia, na escala de
semanas até meses, com preferência aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar
em conjunto e diáriamente, durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o
ambiente e suporte necessário, e confiar que farão seu trabalho.
6. O Método mais eficiente e eficaz de transmitir informações para, e por
dentro de um time de desenvolvimento, é através de uma conversa
cara a cara.

PRINCÍPIOS
DO MANIFESTO ÁGIL (2 DE 2)
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser capazes de
manter indefinidamente, passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta a
agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não
precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times
auto-organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais efetivo,
então, se ajustam e otimizam seu comportamento de acordo.

STATUS DE ADOÇÃO
DE MÉTODOS ÁGEIS
9th
annual State of Agile Survey, 2015. VersionOne.https://www.versionone.com/pdf/state-of-agile-
development-survey-ninth.pdf

TIPOSDE
FERRAMENTAS
PARAPROJETOSÁGEIS

FERRAMENTAS
GESTÃODEPROJETOSÁGEIS

USO DE METODOLOGIAS
ÁGEIS
As mais usadas:
• Scrum
• Scrum/XP Hybrid
• Custom Hybrid
• Scrumban
• Kanban
• ...

USO DE METODOLOGIAS
ÁGEIS
FONTE: The 2015 State of Scrum Report, ScrumAlliance, 2015.
https://www.scrumalliance.org/why-scrum/state-of-scrum-report/2015-state-of-scrum

SCRUM – Um Framework Ágil
O scrum é o meio de reiniciar o jogo após uma interrupção que tenha sido causada por uma infração. A bola é
passada entre os membros do time conforme eles se movem pelo campo como uma unidade.
Sobre o esporte: http://www.bcrugby.com.br/portal/wp-content/uploads/2012/05/IRB_PTBR.pdf
Leitura interessante: Why is Agile/Scrum compared to Rugby?
https://www.captechconsulting.com/blogs/why-is-agilescrum-compared-to-rugby

Scrum é um framework para desenvolvimento ágil
usado para construir produtos incrementalmente
em ambientes complexos, onde os requisitos não
são claros ou mudam com muita freqüência.
Foi publicado em 1986 por Takeuchi e Nonaka: https://hbr.
org/1986/01/the-new-new-product-development-game

• Metodologia interativa e incremental;
• Os projetos são divididos em ciclos (tipicamente
mensais) chamados de Sprints;
• Um Sprint representa um tempo definido dentro do
qual um conjunto de atividades deve ser executado;
• As atividades do projeto são mantidas em uma lista que
é conhecida como Backlog;

Resultado
Entendendo o SCRUM
O Processo:

SCRUM
Product Backlog:
• Contém a lista de desejos, com todas as
histórias de usuário que devem ser
implementadas para criar o produto dos
sonhos do Product Owner;
• As funcionalidades são descritas como
histórias de usuário, da perspectiva do
usuário final;
• O Product Owner, que representa o
usuário/cliente, é quem decide quais
histórias devem fazer parte do Product
Backlog.

SCRUM
Release e Sprint Backlog:
• Um subconjunto de histórias de
usuário é selecionado para compôr
uma release do produto;
• O time prioriza as atividades e
estima o esforço, criando o
Release Backlog;
• Cada Sprint pode ser criado a partir
de atividades selecionadas do
Release Backlog;
• Inclua testes, a cada Sprint. A equipe deve ser multidisciplinar com
desenvolvedores, designers e testadores.
• Tente não planejar Sprints mais longos do que 2 semanas, i.e., onde
o total de horas não ultrapasse a capacidade da equipe:
Ex: 3 pessoas = 240hs (2 semanas a 8h por dia).

Alguns artefatos
SCRUM
● user stories
● priorização de user stories
● planning poker
● burndown chart
● Kanban

SCRUM - User Stories
Histórias de usuário (User stories):
- Artefato de desenvolvimento que apoiam a definição do
produto:
- Casos de Uso: descrever ações de interação (entre o
usuário e o sistema);
- User Stories: o foco é no objetivos do usuário e qual a
funcionalidade esperada.
- Primeiro pense nos casos de uso e depois os quebre em user
stories.
FONTE:
http://www.martinfowler.com/bliki/UseCasesAndStories.html
http://blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/

SCRUM - User Stories
[ator] é o usuário daquela funcionalidade;
[ação] é o que o ator quer fazer. Utilizando aquela ação ele
espera alcançar seu objetivo dentro do sistema.
[funcionalidade] é o que o ator espera que aconteça ao realizar a
ação. Ou seja, é o resultado de executar a ação segundo a
ótica do ator. Também pode ser visto como justificativa.

SCRUM - Exemplos de
User Stories
1. Como Cliente, eu gostaria de buscar livros por palavra-chave do título, para
filtrar os mais relevantes para selecionar produtos para compra.
2. Como Gerente eu quero poder escolher vouchers de desconto para aplicar
um desconto à venda de um vendedor.
3. Como Vendedor eu devo passar meu dedo num leitor biométrico, para me
autenticar antes de realizar uma venda.
4. Como Caixa eu gostaria de passar o código de barras de um livro para
registrar uma venda.
5. Como Cliente eu gostaria de visualizar sugestões de livros relacionados ao
meu perfil de consumo no site para selecionar produtos para compra.

Priorize as user stories usando as seguintes regras:
- MUST have: DEVEM ser implementadas.
- SHOULD have: DEVERIAM ser consideradas ao máximo,
mas não impactam tanto no sucesso do projeto;
- COULD have: PODERIAM ser feitas, caso não impactem
negativamente no andamento do projeto;
- WOULD have: PODEM ser incluídas, se houver tempo
sobrando;
Análise

- O Planning Poker é uma técnica que auxília na
estimativa de histórias e tarefas baseada no consenso;
- As cartas podem representar Story Points (Pontos por
História) ou horas;
- O Product Owner ou um membro do Time apresenta a
hitória ou tarefa ao Time, tirando dúvidas;
- Cada um escolhe uma carta e a coloca virada sobre uma
mesa. Quando todos colocarem as suas cartas, elas são
viradas e caso não haja consenso entre os valores das
cartas escolhidas pelo time as diferenças são discutidas
de forma breve, e uma nova rodada acontece até que
haja convergência e consenso entre todo o Time.
SCRUM
Planning Poker

● 0 (zero): Representa uma estória ou tarefa já concluída, ou com um tempo
muito curto para conclusão, que não vale a pena ser mensurado, como por
exemplo alguns poucos minutos.
● 100 (cem): Representa que uma história ou tarefa está muito grande, e o ideal é
que seja quebrada em mais histórias ou tarefas, pois inclusive, o risco de
estimar errado se torna alto.
● ? (interrogação): Representa que a estória ou tarefa está indefinda, e que além
de não ser possível entender o seu tamanho, não se consegue nem dizer se é
muito pequena ou muito grande;
● “xicará de café“: Representa que o integrante do Time está sugerindo uma
pausa para um café, uma água, ou simples descanso, devido ao tempo da
reunião estar muito longa e estar gerando cansaço.
SCRUM
Planning Poker (Cartas especiais)

● Se “?” ou 100 (cem) ganharem uma estimativa,
significa que o Product Owner deve quebrar a
história/atividade em mais de uma ou descrevê-la
melhor;
● O número de rodadas deve ser limitado (em geral 4),
e caso o limite seja atingido sem o acordo, o Time
deve optar pela estimativa mais alta (do
desenvolvedor mais lento);
SCRUM
Planning Poker (Dicas)

VÍDEO EXEMPLIFICANDO UMA REUNIÃO DE PLANNING POKER: https:
//www.youtube.com/watch?v=UJ-NnDficnE
SCRUM
Planning Poker

Como medir
produtividade
e visualizar o
andamento?

SCRUM - Gráfico Burndown
• Utilizado para monitorar o progresso de um time ágil;
• Diariamente apresenta a porção de trabalho finalizada em
comparação com o trabalho total planejado;
• O gráfico representa a quantidade de trabalho que falta ser
feito e permite analisar a produtividade do time e se a
composição dos sprints foi feita de forma adequada.
-Eixo y: esforço
do projeto (em hs
ou pontos por
história);
-Eixo x: tempo.
_ ideal
_ realizado

• Termo de origem japonesa que significa “cartão” ou
“sinalização”;
• Uso de cartões (post-its são exemplos) para indicar o
andamento do fluxo de produção em empresas de
fabricação em série;
• Nesses cartões são colocadas indicações sobre uma
determinada tarefa, por exemplo, “para executar”, “em
andamento” ou “finalizado”;
• Usado também para controle de estoque.
• Gestão visual do trabalho (produção/estoque);
Sobre a origem do Kanban (Toyota): https://www.youtube.com/watch?
v=SH8IItbvH_0
KANBAN

• Usado para apoiar o acompanhamento/gerenciamento das
atividades em desenvolvimento de software;
• O time pode manter um quadro de trabalho para controle
de atividades:
KANBAN

PRINCÍPIOS DO KANBAN
simples
visível
acessível
sempre atualizado
padronizado

Scrum Alliance
- https://www.scrumalliance.org
- Organização mundial, sem fins lucrativos, que
encoraja a adoção e a prática efetiva de Scrum;
- Se organiza em comunidade regionais para
descentralizar a realização de reuniões e
dicussões:
RS: http://members.scrumalliance.org/user_groups/21
http://www.guma-rs.org

Certificações
FONTE: https://www.scrumalliance.org/certifications

Relatório Anual
Dados:
- 4.452 pessoas, de 108 países, +14 empresas
- 42% usam Scrum exclusivamente;
- 87% disseram que aprimorou a qualidade;
- 81% acreditam que a certificação aprimora prática;
- Na média, Scrum é bem sucedido
em 62% das vezes;
- 95% continuarão usando Scrum;
Grandes desafios:
- Medir o sucesso;
- Transicionar de metodologias em
cascata para Scrum;
- Escalar Scrum em grandes equipes/empresas;
Em média:
- Times de 7
pessoas;
- Sprints de 2
semanas;

Membros/Usuários
-

Aula05 - Metodologias Ágeis

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Aula05 - Metodologias Ágeis

Mais de Daniela Brauner

Aula05 - Metodologias Ágeis