Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Slides da Aula de Gestão de Projetos Digitais

2,595 views

Published on

Videos em http://marcio.oya.net.br

Published in: Education
  • Be the first to comment

Slides da Aula de Gestão de Projetos Digitais

  1. 1. GESTÃO DE PROJETOS
  2. 2. O que é?• Gerência• Projeto
  3. 3. Para que?• Indivíduos• Equipe• Empresa• Sociedade
  4. 4. Realidade• Como você faz?
  5. 5. Na realidade usam para...
  6. 6. Princípios• Princípios são atemporais• Práticas são aplicações dos princípios em uma situação
  7. 7. Natureza das tarefas• Tarefas repetitivas• Tarefas criativas
  8. 8. Natureza dos Processos• Modelo teórico ou prescritivo (pmbok)• Modelo empírico ou adaptativo (pdca)
  9. 9. PMBOK 4ª Edição• 5 grupos de processos• 42 processos• 9 áreas de conhecimento
  10. 10. Comunicação• O problema da comunicação• A maldição do conhecimento
  11. 11. Prioridades• Visão e Objetivos do projeto• Para quem tem valor?• O que tem valor? KISS• Envolvimento do Cliente
  12. 12. Auto-organização• Comando e controle• Federação x União• Poder x Escolhas = satisfação
  13. 13. Cenouras e Chicotes
  14. 14. Cenouras e Chicotes
  15. 15. Racionalidade x Automatismo
  16. 16. Racionalidade x Automatismo
  17. 17. Honestidade x Conformidade
  18. 18. Honestidade x Conformidade
  19. 19. Honestidade x Autoridade
  20. 20. Honestidade x Autoridade
  21. 21. Controle Sutil• Republica Democrática• Facilitador
  22. 22. Timebox• Escopo x qualidade+tempo x custo• Espirito da quinta série• Instabilidade constante
  23. 23. Estimativas• Velocidade• Custo
  24. 24. Mais Comunicação• Alinhamento• Removendo impedimentos• Entregando Valor
  25. 25. Aprendendo• Retrospectiva• 5xPorque• Espinha de Peixe - problema e causas• NF
  26. 26. Agile
  27. 27. The New New Product Development Game
  28. 28. The New New Product Development Game Instabilidade built-in (forma integral da estrutura)
  29. 29. The New New Product Development Game Instabilidade built-in (forma integral da estrutura)• Grupo de projeto auto organizado
  30. 30. The New New Product Development Game Instabilidade built-in (forma integral da estrutura)• Grupo de projeto auto organizado • Autonomia
  31. 31. The New New Product Development Game Instabilidade built-in (forma integral da estrutura)• Grupo de projeto auto organizado • Autonomia • Auto Superação
  32. 32. The New New Product Development Game Instabilidade built-in (forma integral da estrutura)• Grupo de projeto auto organizado • Autonomia • Auto Superação • Troca de idéias
  33. 33. The New New Product Development Game Instabilidade built-in (forma integral da estrutura)• Grupo de projeto auto organizado • Autonomia • Auto Superação • Troca de idéias• Desenvolvimento de fases sobrepostas
  34. 34. The New New Product Development Game Instabilidade built-in (forma integral da estrutura)• Grupo de projeto auto organizado • Autonomia • Auto Superação • Troca de idéias• Desenvolvimento de fases sobrepostas• Multi Aprendizagem
  35. 35. The New New Product Development Game Instabilidade built-in (forma integral da estrutura)• Grupo de projeto auto organizado • Autonomia • Auto Superação • Troca de idéias• Desenvolvimento de fases sobrepostas• Multi Aprendizagem• Controle Sutil
  36. 36. The New New Product Development Game Instabilidade built-in (forma integral da estrutura)• Grupo de projeto auto organizado • Autonomia • Auto Superação • Troca de idéias• Desenvolvimento de fases sobrepostas• Multi Aprendizagem• Controle Sutil• Transferência de aprendizagem organizacional
  37. 37. Lean• Eliminar desperdício (o que não gera valor)• Construa com qualidade (sem falhas)• Crie conhecimento• Adie compromissos (procrastinação)• Entregue rapidamente• Respeite as pessoas (escolhas)• Otimize o todo (união, visão)
  38. 38. Kanban• Visualisar o fluxo de trabalho• Limitar o trabalho em progresso (WIP)• Medir e gerenciar o fluxo
  39. 39. Manifesto ÁgilEstamos descobrindo maneiras melhores de desenvolversoftware, fazendo-o nós mesmos e ajudando outros afazerem o mesmo. Através deste trabalho, passamos a valorizar:Indivíduos e interações mais que processos e ferramentasSoftware em funcionamento mais que documentação abrangenteColaboração com o cliente mais que negociação de contratosResponder a mudanças mais que seguir um planoOu seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens àesquerda.
  40. 40. Princípios1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.3. Entregar freqüentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.7. Software funcionando é a medida primária de progresso.8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.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 não realizado--é essencial.11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.12. Em intervalos regulares, a equipe reflete sobe como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
  41. 41. SCRUM
  42. 42. O que é SCRUM?• Um framework com o qual as pessoas podem atender problemas complexos e adaptativos• Feito de um conjunto simples de regras e garante que todos os membros da equipe sintam a responsabilidade de um projeto• Inspeção e adaptação com base em feedback• Usado para gerenciar projetos complexos desde 1990• Entrega de funcionalidades de negócio em até 30 dias• Escalabilidade na distribuição de projetos grandes e longos• Compatível com CMM Level 3 e ISO 9001• Extremamente simples mas de difícil implementação
  43. 43. SCRUM
  44. 44. PrincípiosTime
responsável
e
comprome/doHones/dadeTransparênciaPartes
potencialmente
entregáveisTimebox
  45. 45. TeoriaBaseado no Processo Empírico: • Transparência • Inspeção • Adaptação
  46. 46. Scrum Team• Product Owner• Development Team• Scrum Master
  47. 47. Product Owner
  48. 48. Development Team
  49. 49. Scrum Master
  50. 50. Papéis no SCRUM Atividade Papel Responsabilidade Gerencia a Product O Product Owner estabelece, mantem viva e comunica a visão do produto. Ele demonstra que o visão Owner projeto é alcançável e o financia criando a visão dos releases e do Product Backlog inicial. Product O Product Owner monitora o projeto, mantém de acordo com o ROI estabelecido. Ele atualiza as Gerencia o prioridade do Product Backlog para assegurar-se que as tarefas de maior valor funcional sejam Owner ROI produzidas primeiro. Ele prioriza o Product Backlog and mede o sucesso para assegurar que o projeto está no caminho certo.Gerencia as Team Durante uma iteração o time seleciona e desenvolve os requisitos de maior prioridade do Productiterações de Backlog. Coletivamente, o time expande os itens do Product Backlog para tarefas mais explícitas no Sprint Backlog e gerenciam o trabalho e a sua própria organização para entregar os itens desejadosdesenvolvimento naquela iteração. O time se gerencia para cumprir o compromissos. Scrum Master O Scrum Master é responsável por ajustar a equipe acima tentando assegurar o sucesso do projeto Gerencia o e otimizar a cultura organizacional para encontrar os objetivos no projeto. Isto envolve organizar a processo Sprint Planning Meeting, a Sprint Review Meeting, protegendo a equipe dos distúrbios externos, realizando as Daily Scrum Meetings, e removendo impedimentos para o progresso do projeto. Product Owner O Product Owner toma decisões sobre quando criar um release oficial. Por uma série de razões não Gerencia os é desejável liberar um realease a cada incremento. O Product Owner toma esta decisões de releases maneira consistente com base na visão de investimento que foi estabelecida para o projeto.
  51. 51. Fases do SCRUM
  52. 52. Fluxo do SCRUM
  53. 53. Product Backlog• Lista de funcionalidades, tecnologia a ser aplicada, issues• Issues são situações/assuntos do projeto que terão o trabalho definido mais tarde• Itens priorizados e estimados• Maior detalhamento sobre os itens de maior prioridade• O Product Owner é responsável pela priorização• Qualquer um da equipe pode contribuir• Mantido e fixado em local visível• Derivado do plano de negócio e da visão estabelecida, que tem que ser criada em conjunto com o cliente• Estimation Meeting
  54. 54. O que é um Backlog Item?Como <papel do usuário> eu quero<funcionalidade> para que <valor de negócio>
  55. 55. Planning Poker• Chile• Argentina• Venezuela• Brasil• Uruguai• Paraguai• Egito• Itália1, 2, 3, 5, 8, 13, 21
  56. 56. ImpedimentosQue
/po
de
impedimentos
você
consegue
pensar?
  57. 57. Sprint Planning 1Definir o Sprint Goal e o Selected Product Backlog
  58. 58. Sprint Planning 2Define as tarefas para realizar o Sprint Backlog e alinha aoSprint GoalJunta a estimativa com a realidade da equipe e do projetoDesign é detalhado nesta sessãoVamos ao quadro!
  59. 59. KANBAN
  60. 60. Burndown• Sprint Burndown• Product Burndown• Velocity per Sprint• Business Value Evolution
  61. 61. Daily Meeting• Objetivo: Sincronizar a equipe - Quais as tarefas foram realizadas ontem? - Quais as tarefas serão desempenhadas hoje? - Quais os impedimentos encontrados durante o seu trabalho?• Mover as tarefas dentro do quadro de acordo com a sua execução• Resultados - Atualização do Impediment Backlog - Atualização do Sprint Backlog - Atualização dos gráficos Burndown• Novas funcionalidades que surgirem serão armazenadas para avaliação ao final do Sprint
  62. 62. Sprint Review• O team deve apresentar os resultados do Sprint e as novas funcionalidades desenvolvidas• Se surgirem novas funcionalidades ou alteração, os novos itens irão para o Backlog para serem estimados e priorizados• O team deve reportar os impedimentos durante o desenvolvimento• Ao final todos envolvidos no projeto devem entender a evolução do projeto e os impedimentos
  63. 63. Sprint Retrospective• O processo é aprimorado ao final de cada Sprint• Facilitado pelo ScrumMaster• O que aconteceu de bom que nós podemos utilizar como melhoria?• ScrumMaster basea a prioridade de acordo com o team• A equipe planeja a solução dos problemas de sua responsabilidade
  64. 64. Retrospectiva“Independente do que nós descubramos, nóscompreendemos e acreditamosverdadeiramente que todos fizeram omelhor trabalho que poderiam, deram o quesabiam naquele momento, seusconhecimentos e suas habilidades, osrecursos disponíveis, e a situação disponível.”
  65. 65. Escalabilidade
  66. 66. Resumo• Roles: Product Owner, Team, ScrumMaster• Artifacts: Product Backlog, Selected Product Backlog, Sprint Backlog, Impediment Backlog• Scrum Meetings: Daily Scrum Meeting, Estimation Meeting, Retrospective, Sprint Planning 1, Sprint Planning 2, Sprint Review Meeting
  67. 67. Dicas para Começar• Ensine os conceitos, teoria e práticas do SCRUM• Apresente a Visão do Projeto, Objetivos e timelines• Ensine o Sprint Planning• Defina o Product Backlog para pelo menos 3 sprints• Faça um brainstorm dos possíveis impedimentos• Faça um brainstorm sobre o próximo Sprint - a equipe aceita• A equipe define o Sprint Backlog• Ensine Daily Meeting, Sprint Review e auto-organização• Discuta sobre ferramentas, práticas e arquiteturas.
  68. 68. Dia-a-dia do Scrum Master• Garantaque todos estejam fazendo o que eles concordaram em fazer• Trabalhe no Product Backlog• Usetodo os seus sentidos, incluindo o senso comum, e lembre-se que você não tem autoridade.
  69. 69. Instabilidade Constante• A maioria dos projetos fazem entregas a cada 6 ou 18 meses. Scrum reduz isso para menos de 1 mês para aumentar o controle através de inspeção e adaptação.• Isto cria stress no time e na organização, expondo os problemas e limitações.• O trabalho do Scrum Master é priorizar estes problemas e ajudar a organização a superá-los para melhorar sua produtividade, investimentos e se tornar uma comunidade para se trabalhar.
  70. 70. Responsabilidades• Remover as barreiras entre o desenvolvimento e o cliente para que o cliente diretamente direcione o desenvolvimento.• Ensinar o cliente a maximizar o ROI e encontrar seus objetivos através do Scrum.• Melhorar a vida do time facilitando a criatividade e a auto- organização.• Melhorar a produtividade do time de qualquer forma possível• Melhorar as práticas de engenharia e ferramentas para que cada incremento na funcionalidade seja potencialmente entregue. Líder e Facilitador “Sheepdog”
  71. 71. Scrum e o Scrum Master• Scrum é um simples, iterativo, incremental esqueleto com algumas regras.• Equipado com um Scrum Master resoluto e paciente, Scrum pode ser usado para transformar trabalho em profissão, projetos em esforços valiosos, e organizações em comunidades onde as pessoas queiram trabalhar nelas.• Scrum é somente um framework. Ele não falha. Às vezes, as pessoas não entendem o que está exposto. Scrum Masters são a chave para o grau de sucesso na transformação das organizações.

×