Your SlideShare is downloading. ×

Curso Scrum

2,059

Published on

Published in: Technology, Business
1 Comment
8 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,059
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
231
Comments
1
Likes
8
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Paulo Roberto Furtado Serra, CSM 2009
  • 2. 1. Introdução 2. Gerenciamento 4. SCRUM de Projetos: Problemas 3. Metodologias Ágeis de Desenvolvimento
  • 3. 1. Introdução 2. Gerenciamento 4. SCRUM de Projetos: Problemas 3. Metodologias Ágeis de Desenvolvimento
  • 4. 1. Apresentação do Instrutor 2. Objetivos do Curso
  • 5.  Paulo Furtado Serra trabalha a mais de 10 anos na área de desenvolvimento de Software  A 3 anos vem se especializando em Metodologias de Gerenciamento e Desenvolvimento Ágeis  Mestre em Engenharia de Teleinformática pela Universidade Federal do Ceará  É Certified Scrum Master (CSM) pela Scrum Alliance
  • 6.  Repassar os princípios que rodeiam as Metodologias Ágeis  Introduzir os principais conceitos do Scrum, bem como seus principais artefatos, papéis e cerimônias (reuniões)  Exemplificar o uso do Scrum com outras metodologias ágeis, como a eXtreme Programming (XP)  Preparar equipe da ETICE para utilizar Scrum no S2GPR
  • 7. 1. Introdução 2. Gerenciamento 4. SCRUM de Projetos: Problemas 3. Metodologias Ágeis de Desenvolvimento
  • 8. 2.1. O que é Projeto? 2.2. Exemplos 2.5. Problemas de Projeto 2.3. Projetos 2.4. Estatísticas de Software
  • 9. 2.1. O que é Projeto? 2.2. Exemplos 2.5. Problemas de Projeto 2.3. Projetos 2.4. Estatísticas de Software
  • 10.  Esforço empreendido para algo exclusivo  É temporário, possui um início e um fim;  Possui restrições em custo, prazo, qualidade e recursos;  Exige coordenação;  Conduzido por pessoas;
  • 11. 2.1. O que é Projeto? 2.2. Exemplos 2.5. Problemas de Projeto 2.3. Projetos 2.4. Estatísticas de Software
  • 12. - Quem já participou de algum projeto de software do Início ao Fim... ... que tenha terminado no prazo? - Quem participa de algum projeto de software hoje? Se sim, esse projeto já têm algo em produção? - Quem já participou de algum projeto de software onde os requisitos não mudaram? Se sim, então NÃO era um projeto de Software !
  • 13. - Construir um software não é o mesmo que construir um prédio - Existe projeto de Software com escopo fixo? - Na Grande maioria dos casos, o usuário não sabe o que quer, ele sabe o que sente - Ponha isso na sua mente: Em Projetos de Software, sempre haverá mudanças !
  • 14. 100% 90% 80% 70% 60% Falhou 50% Desafiado 40% Sucesso 30% 20% 10% 0% 2000 2002 2004 2007 2009 Fonte: The Standish Group http://www.infoq.com/articles/chaos-1998-failure-stats
  • 15. Média de uso de funcionalidades de sistemas 7% 13% 45% 16% Sempre Frequentemente Às vezes Raramente 19% Nunca Standish Group, 2002
  • 16.  Doenças do Gerenciamento de Projetos  Nível de Ruído em Projetos  Muita gente envolvida e pouca gente comprometida  Muitas barreiras de comunicação entre cliente e desenvolvedor
  • 17.  Multi-tarefa nociva  Equipes enfrentam constantemente prioridades que mudam, fazendo com que interrompam uma tarefa e trabalhem em outra  Lei de Parkinson  Mais tempo de segurança, mais tempo de projeto  Síndrome do Estudante  O trabalho quase sempre é adiado  Dependência entre tarefas  O atraso é passado adiante, mas o adiantamento não
  • 18. Longe de acordo Requerimentos Anarquia Complexo Perto de Simples Acordo Perto da Tecnologia Longe da certeza certeza Fonte: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.
  • 19. O porco está COMPROMETIDO A galinha está apenas ENVOLVIDA
  • 20. Continua fazendo sentido?
  • 21.  Em 2001, um grupo de profissionais veteranos na área de software decidiu se reunir em uma estação de esqui, nos EUA.  O objetivo seria discutir formas de melhorar o desempenho de seus projetos.  Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo;  O grupo era composto de grandes nomes do mundo do software, tais como: Kent Beck, Jim Highsmith, Alistair Cockburn, Martin Fowler, Ken Shwaber e Jeff Sutherland; O encontro deu origem ao MANIFESTO ÁGIL
  • 22. 1. Introdução 2. Gerenciamento 4. SCRUM de Projetos: Problemas 3. Metodologias Ágeis de Desenvolvimento
  • 23. O Manifesto Ágil Metodologias Ágeis Premissas das de Desenvolvimento Metodologias Ágeis / Gerenciamento Paradigmas
  • 24. 50 50 50 80 80 50 50 80 80 80 80 50 50 50 50
  • 25. “Estamos descobrindo melhores maneiras de desenvolver software, fazendo software e ajudando outros a fazê-lo. Através deste trabalho passamos a valorizar: Indivíduos e interações Processos e ferramentas Software que funciona Documentação abrangente Mais que Colaboração do cliente Negociação de contrato Resposta à mudanças Seguir um plano Isto é, embora haja valor nos itens do lado direito, nós valorizamos mais os do lado esquerdo.” http://www.agilemanifesto.org
  • 26.  O que é “ser ágil”?  Desenvolvimento incremental e iterativo  Cooperação e colaboração  Processo Empírico de Desenvolvimento  Documentação Útil  Simplicidade  Comunicação
  • 27.  Segundo James Shore & Shane Warden “A resposta é mais complicada do que se pode pensar. O Desenvolvimento ágil não é um processo específico que pode ser seguido. Nenhuma equipe pratica o método Ágil.” “O desenvolvimento ágil é uma filosofia. É uma maneira de pensar sobre desenvolvimento de software. Isso pode ser visto no Manifesto Ágil.”
  • 28. Jim Highsmith For many people the appeal of these agile methodologies is their reaction to the bureaucracy of the engineering methodologies. These new methods attempt a useful compromise between no process and too much process, providing just Martin Fowler enough process to gain a reasonable payoff.
  • 29. Requisitos Especific. Desenvolv Testes Produção Isso não é do jeito que eu queria !!! Iteração 1 Iteração 2 Iteração N ...
  • 30. Quantas salas eu tenho Quantas salas eu tenho Desmontadas ? montadas ?
  • 31. Quantas salas eu tenho Quantas salas eu tenho Desmontadas ? montadas ?
  • 32.  Um estado mental, não um conjunto de documentos, passos ou técnicas;  É mais atitude do que um processo, mais ambiente que uma metodologia;  Entregar produto com valor para o negócio, mais rápido e continuamente;  Garantir progresso real;  Abraçar mudanças;  Qualidade desde o início;
  • 33. Scrum: É uma abordagem ágil para o gerenciamento de projetos. Fornece práticas que ajudam gerentes a tornar mais dinâmico e gerenciável o ambiente de desenvolvimento de software. XP (eXtreme Programming): É uma abordagem ágil para a engenharia de projetos de software. Como o próprio nome diz, é extremamente focada no desenvolvimento, e tem como principal característica a programação em par. FDD (Feature-Driven Development): É uma abordagem ágil para a engenharia de projetos de software. Defende o desenvolvimento de um modelo abrangente no início do projeto pelo qual as funcionalidades do sistema serão descobertas e desenvolvidas..
  • 34. 1. Introdução 2. Gerenciamento 4. SCRUM de Projetos: Problemas 3. Metodologias Ágeis de Desenvolvimento
  • 35.  Scrum é um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer trabalho.  Scrum é um processo ágil para o gerenciamento e controle de projetos;  Scrum é uma abordagem para desenvolvimento de sistemas e produtos onde os requisitos sofrem constantes mudanças;  Scrum é um processo que controla o caos dos conflitos de interesses;
  • 36.  Scrum é uma forma de otimizar a comunicação do time e favorecer a cooperação;  Scrum é uma forma de otimizar a produtividade;  Scrum é uma forma de todos se sentirem bem com seu trabalho, suas contribuições, e faz com que todos dêem o melhor de si para o sucesso do projeto.  É um processo EMPÍRICO e não um PROCESSO DEFINIDO.  Ao contrário do que muitos pensam, o SCRUM se baseia no RUP, pois ambos são iterativos e incrementais
  • 37.  Criado a partir de uma Visão do Projeto  Lista de funcionalidades priorizadas Maior prioridade Funcionalidade Prioridade Func. A 10 Func. B 20 Func. C 30 Func. D 40 Func. E 50 Func. F 60 Menor Prioridade Func. N 70
  • 38.  Parte do Product Backlog que vai ser feita numa iteração (Sprint)  Montado a partir das funcionalidade que estão no topo do Product Backlog Maior prioridade Funcionalidade Prioridade Func. A 10 Func. B 20 Sprint Backlog Func. C 30 Func. D 40 Func. E 50 Func. F 60 Menor Prioridade Func. N 70
  • 39.  Um período de Tempo entre 2 a 4 semanas  Sempre deve ter um objetivo a ser atingidao pela equipe  É normal que o tempo de duração dos Sprints possam variar no início do projeto, mas o ideal é que se chegue num tempo único para todos os sprints  Todos os Sprints devem pessuir uma estrutura exatamente igual
  • 40. Planejamento – Sprint X+1 Apresentação – Sprint X Planejamento – Sprint X Reunião Reunião Reunião Reunião Reunião Reunião Reunião Reunião diária diária diária diária diária diária diária diária
  • 41. Histórias A Alta B O que está dentro do Sprint C Não pode ser alterado. D Prioridade E - O que está fora do Sprint pode F Ser alterado de acordo com a G necessidade do cliente. H - Ele pode alterar prioridades, I inserir novas tarefas ou retirar tarefas existentes. Baixa - Algumas tarefas podem ser inseridas pela equipe. Ex: Montar ambiente para Integração contínua
  • 42.  Define as funcionalidades do produto  Decide datas de lançamento e conteúdo  Responsável pela rentabilidade (ROI) $$$$$  Prioriza funcionalidades de acordo $$$$$ com seu valor para o negócio  Gerencia a entrada de novos requisitos e suas prioridades  Aceita ou rejeita o resultado dos trabalhos
  • 43.  Representa a gerência para o projeto  Responsável pela aplicação dos valores e práticas do Scrum  Remove obstáculos  Garante a plena funcionalidade e produtividade da equipe  Garante a colaboração entre os diversos papéis e funções  Escudo para interferências externas
  • 44.  Tamanho variável , é aconcelhável não mais que 9 pessoas e não menos que 4  Multi-funcional ▪ Programadores, testadores, desenvolvedores...  Aconcelhável trocas só na mudança de Sprints  Faz o que for preciso para alcançar a Meta do Sprint, uma vez que se compromete com o que vai ser entregue  Apresenta aos interessados o resultado do Sprint
  • 45.  Reunião que define  O objetivo (meta) do Sprint  Uma lista dos membros da equipe que estarão comprometidos com a meta  Um Sprint Backlog (lista com todas as funcionalidades incluídas no sprint)  Uma Data para demonstrar que foi produzido durante o sprint  Hora e lugar definido para acontecerem as reuniões diárias  Dependendo do projeto, esta reunião pode durar de 4 a 16 horas
  • 46.  Como estimar?  Story Points  Um “peso” dado para cada história  Indica quanto uma história é maior ou mais complexa que outra  Horas  Tempo estimado por cada tarefa
  • 47.  Planning Poker
  • 48. Livro Características Livro Características -Manual CMMI - 80 páginas -899 páginas - Em português -Inglês - Fofocas -Informática - 1300 páginas -- 120 páginas -Português - Em português - Religião - Humor
  • 49.  Objetivo  Cada membro deve responder as seguintes perguntas: 1. O que você fez desde a última reunião diária? 2. O que você pretende fazer até a próxima reunião diária? 3. Existe algum problema que o impeça de realizar suas atividades?  Duração  15 minutos (não mais que isso)  Todos em Pé  Qualquer pessoa pode participar, mas apenas o Scrum Master e os Membros da Equipe pedem falar
  • 50.  Objetivo  Mostrar o que foi produzido no Sprint  Duração  30 a 60 minutos  Participantes  Product Owner, Scrum Master, membros do time, clientes, Usuários, Stakeholders e qualquer pessoa que esteja interessada no resultado da Sprint  Qualquer participante pode falar, fazer perguntas ou observações
  • 51.  Objetivo  Enumerar o que funcionou e o que não funcionou durante o Sprint  Duração  30 a 60 minutos  Participantes  Product Owner, Scrum Master e os membros do time  Esta reunião pode ser feita à frente de um quadro branco onde membro cola post its dizendo o que funcionou e o que não funcionou  Feita após cada Sprint
  • 52. O que Funcionou O que não funcionou Testes Comunicação entre os membros Reuniões Faltou Diárias Usuário melhor Distante planejamento do Sprint Alguns membros chegam tarde
  • 53.  Principais práticas  Programação em Par  Integração Contínua  Test Driven Development  Refatoração Contínua  Iterações de uma semana
  • 54.  Equipes auto-gerenciáveis  Equipes multi-disciplinares  Até onde a documentação é último  Comunicação  Referência  Desenvolvimento por iterações  Zonas de conforto
  • 55.  Nome do Hotel: Rede de Hotéis McTreffe  Endereço:  Rua 30 de Fevereiro, S/N – Bairro Canela Seca – Fortaleza-Ceará – Brasil  Instalações ▪ Quarto equipado com moderno sistema de ventilação natural; ▪ Cama de solteiro (traga o colchão); ▪ Direito a cafezinho da manhã (só o café); ▪ Avançada TV de 7” equipada com antena UHF/VHF ▪ Banheiro com balde de 10 litros para um belo banho morno ▪ Internet 56kb 2horas por dia (obs: Link compatilhado com todo o hotel)
  • 56.  Principais Atrações ▪ Mergulho na lagoa de Messejana ▪ Valor(R$ 1500,00) por 30min ▪ Passeio turístico pela região central do Lagamar ▪ Valor(R$ 500,00) por 1h ▪ Explorar o túnel do Metrofor por 1 dia ▪ Valor: 1 kg de cimento não pereível + R$ 5000,00 para ajudar na construção ▪ Banho de Mar na Praia da Leste-Oeste com direito a pomada pra micose ▪ Valor: R$ 200,00  Obs: Translado gratuito para todos as atrações disponíveis
  • 57.  Desenvolver uma logomarca para o Hotel  Criar um slogan que represente a qualidade do hotel  Criar um folder que contenha endereço, logomarca, slogan, instalações, principais atrações  Criar um Jingle para divulgar o Hotel nas rádios  Criar um panfleto resumindo as principais características do Hotel  Elaborar uma folha de sugestões/críticas
  • 58.  www.mountaingoatsoftware.com/scrum  www.scrumalliance.org  www.controlchaos.com  scrumdevelopment@yahoogroups.com  Agile Software Development with Scrum by Ken Schwaber and Mike Beedle  Agile Project Management with Scrum by Ken Schwaber  Scrum and the Enterprise by Ken Schwaber  Scrum and XP from the trenches

×