GERÊNCIA DE
PROJETOS
GESTÃO DE PROJETOS DE
SOFTWARE e as
METODOLOGIAS ÁGEIS
UNIVERSIDADE FEDERAL DE PELOTAS
DANIELA F. BRA...
Sumário
1. Gerenciamento de projetos
2. PMBOK e Metodologias Ágeis
3. Introdução às Metodologias Ágeis
4. O uso de Metodol...
“O gerenciamento de projetos é a aplicação
de conhecimento, habilidades, ferramentas
e técnicas às atividades do projeto a...
X
PMBOK
✓ Planejamento
completo e
abrangente;
✓ Ideal para projetos
onde se vislumbra que
o planejado será
seguido até o fin...
PMBOK
Áreas de conhecimento:
– Gerenciamento da Integração
– Gerenciamento de Escopo
– Gerenciamento de Tempo
– Gerenciame...
X
Metodologias Ágeis
• Processos iterativos e incrementais para
gerenciamento de projetos e desenvolvimento
de software;
• É...
Requisitos
Tecnologia
Metodologias
Ágeis
THE CHAOS REPORT
FONTE: CHAOS Report 1995. Standish Group. https://www.projectsmart.co.
uk/white-papers/chaos-report.pdf
S...
CONSTRUÇÃO DE
PONTES X SOFTWARE
• Feitas no tempo
• Feitas no orçamento
• Não são feitas para cair
• Projetos com planejam...
RESULTADOS DO
THE CHAOS REPORT
• 52.7% dos projetos custarão 189% do estimado.
• 31.1% dos projetos são cancelados.
• 16,2...
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 pes...
LIDANDO COM
INCERTEZAS
Em 2001, o prof. Alan MacCormack estudou abordagens
da época e sugeriu novas abordagens e práticas ...
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 con...
PRINCÍPIOS
DO MANIFESTO ÁGIL (2 DE 2)
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem ...
STATUS DE ADOÇÃO
DE MÉTODOS ÁGEIS
9th
annual State of Agile Survey, 2015. VersionOne.https://www.versionone.com/pdf/state-...
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-sc...
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çã...
Scrum é um framework para desenvolvimento ágil
usado para construir produtos incrementalmente
em ambientes complexos, onde...
SCRUM – Um Framework Ágil
• Metodologia interativa e incremental;
• Os projetos são divididos em ciclos (tipicamente
mensa...
Entendendo o SCRUM
Papéis:
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 cri...
SCRUM
Release e Sprint Backlog:
• Um subconjunto de histórias de
usuário é selecionado para compôr
uma release do produto;...
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:...
SCRUM - User Stories
[ator] é o usuário daquela funcionalidade;
[ação] é o que o ator quer fazer. Utilizando aquela ação e...
SCRUM - Exemplos de
User Stories
1. Como Cliente, eu gostaria de buscar livros por palavra-chave do título, para
filtrar o...
Como
priorizar
user stories?
Priorize as user stories usando as seguintes regras:
- MUST have: DEVEM ser implementadas.
- SHOULD have: DEVERIAM ser con...
Como
estimar
esforço?
- O Planning Poker é uma técnica que auxília na
estimativa de histórias e tarefas baseada no consenso;
- As cartas podem r...
● 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...
● Se “?” ou 100 (cem) ganharem uma estimativa,
significa que o Product Owner deve quebrar a
história/atividade em mais de ...
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 traba...
• Termo de origem japonesa que significa “cartão” ou
“sinalização”;
• Uso de cartões (post-its são exemplos) para indicar ...
• Usado para apoiar o acompanhamento/gerenciamento das
atividades em desenvolvimento de software;
• O time pode manter um ...
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áti...
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 ap...
Membros/Usuários
-
FONTE: The 2015 State of Scrum Report, ScrumAlliance, 2015.
https://www.scrumalliance.org/why-scrum/sta...
Aula05 - Metodologias Ágeis
Próximos SlideShares
Carregando em…5
×

Aula05 - Metodologias Ágeis

341 visualizações

Publicada em

SCRUM, KANBAN, user stories, Análise Moscow,Planning Poker, Burndown

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
341
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
10
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Aula05 - Metodologias Ágeis

  1. 1. 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
  2. 2. 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
  3. 3. “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...
  4. 4. X
  5. 5. 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;
  6. 6. 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
  7. 7. X
  8. 8. 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
  9. 9. Requisitos Tecnologia Metodologias Ágeis
  10. 10. 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.
  11. 11. 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
  12. 12. 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.
  13. 13. FATORES QUE DESAFIAM OS PROJETOS DE SOFTWARE
  14. 14. FATORES QUE COMPROMETEM OS PROJETOS DE SOFTWARE
  15. 15. FATORES DE SUCESSO DOS PROJETOS DE SOFTWARE
  16. 16. 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 ?
  17. 17. 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.
  18. 18. O MANIFESTO ÁGIL http://www.manifestoagil.com.br
  19. 19. 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.
  20. 20. 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.
  21. 21. 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
  22. 22. TIPOSDE FERRAMENTAS PARAPROJETOSÁGEIS
  23. 23. FERRAMENTAS GESTÃODEPROJETOSÁGEIS
  24. 24. USO DE METODOLOGIAS ÁGEIS As mais usadas: • Scrum • Scrum/XP Hybrid • Custom Hybrid • Scrumban • Kanban • ...
  25. 25. 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
  26. 26. SCRUM
  27. 27. 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
  28. 28. 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 SCRUM – Um Framework Ágil
  29. 29. SCRUM – Um Framework Ágil • 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;
  30. 30. Entendendo o SCRUM Papéis:
  31. 31. Resultado Entendendo o SCRUM O Processo:
  32. 32. 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.
  33. 33. 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).
  34. 34. Alguns artefatos SCRUM ● user stories ● priorização de user stories ● planning poker ● burndown chart ● Kanban
  35. 35. 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/
  36. 36. 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.
  37. 37. 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.
  38. 38. Como priorizar user stories?
  39. 39. 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
  40. 40. Como estimar esforço?
  41. 41. - 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
  42. 42. ● 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)
  43. 43. ● 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)
  44. 44. VÍDEO EXEMPLIFICANDO UMA REUNIÃO DE PLANNING POKER: https: //www.youtube.com/watch?v=UJ-NnDficnE SCRUM Planning Poker
  45. 45. Como medir produtividade e visualizar o andamento?
  46. 46. 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
  47. 47. • 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
  48. 48. • 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
  49. 49. PRINCÍPIOS DO KANBAN simples visível acessível sempre atualizado padronizado
  50. 50. 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
  51. 51. Certificações FONTE: https://www.scrumalliance.org/certifications
  52. 52. 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; FONTE: The 2015 State of Scrum Report, ScrumAlliance, 2015. https://www.scrumalliance.org/why-scrum/state-of-scrum-report/2015-state-of-scrum Em média: - Times de 7 pessoas; - Sprints de 2 semanas;
  53. 53. Membros/Usuários - FONTE: The 2015 State of Scrum Report, ScrumAlliance, 2015. https://www.scrumalliance.org/why-scrum/state-of-scrum-report/2015-state-of-scrum

×