Transferir como PDF, PPTX
![Metodologias Ágeis e o
SCRUM
[“Thinking Different”]
Paulo Igor
piagodinho@gmail.com
@pigodinho
hDp://blog.pigor.net](https://image.slidesharecdn.com/palestra-scrum-100522222331-phpapp01/85/Palestra-scrum-1-320.jpg)
![?
Obrigado!!!
[piagodinho@gmail.com]](https://image.slidesharecdn.com/palestra-scrum-100522222331-phpapp01/85/Palestra-scrum-101-320.jpg)
Carregado porPaulo Igor Alves Godinho
Palestra scrum
O documento apresenta uma introdução ao Scrum e metodologias ágeis, descrevendo: 1) Os princípios do Scrum como um framework ágil para gestão de projetos de software através de ciclos iterativos e entrega contínua de valor; 2) As diferenças entre metodologias tradicionais e ágeis, enfatizando a colaboração, adaptabilidade e valor dado ao cliente nas ágeis; 3) Os papéis e práticas do Scrum como Sprints, Daily Scrum e Retrospectivas.
Mais conteúdo relacionado
![[Webinar] Scrum - Você está fazendo do jeito certo?](https://cdn.slidesharecdn.com/ss_thumbnails/webinar-scrumdojeitocerto-targettrust-180417193100-thumbnail.jpg?width=640&height=640&fit=bounds)
![[c7s] Palestra para pais do Fundamental I 2011 - Quem me educa](https://cdn.slidesharecdn.com/ss_thumbnails/quemmeeduca-110303115427-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Palestra scrum
- 1. Metodologias Ágeis e o SCRUM [“Thinking Different”] Paulo Igor piagodinho@gmail.com @pigodinho hDp://blog.pigor.net
- 2. Um pouco sobre mim... • Bacharel em Sistemas de Informação pelo CESUPA • Mestre em Ciência da Computação pela UFPA • ScrumMaster CerPfied (2008) • Analista Especialista e Arquiteto de SoXware – Cobra Tecnologia S.A. (ScrumMaster ‐ Piloto) – Pródiga Sistemas (Líder Técnico / ScrumMaster) • Professor de Pós‐graduação do CESUPA • Membro aPvo de comunidades regionais e nacionais – Beljug, TáSafo, Dojo‐Pa (Fundador), Scrum‐PA, ...
- 3. Meus Contatos • piagodinho@gmail.com • pigodinho (TwiDer) • hDp://blog.pigor.net
- 4. A essência dos Projetos Conceitos
- 5.
- 6. ...projeto é um esforço temporário para criar um serviço, ou produto, ou resultado exclusivo.
- 7.
- 8.
- 9.
- 10.
- 11. Entregam produto, serviço, ou resultado exclusivo
- 12. Desenvolvido em etapas
- 13.
- 14.
- 15.
- 16.
- 17.
- 18. Chaos Report • Segundo o Standish Group os principais fatores são: – Falta de clareza sobre funções pessoais, responsabilidades e requisitos. – Falta de habilidade para acompanhar os passos do ciclo de vida da aplicação.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25. Resumindo... • A comunicação entre as partes envolvidas nos projetos é muito fraca; • A visibilidade do andamento real e dos problemas existentes nos projetos é muito fraca; • Clientes pedem sempre mais do que realmente precisam; • Os projetos são caros e, ainda em sua maioria, não alcançam sucesso; • Os conflitos existentes entre TI e negócios durante os projetos são muitos;
- 26. O Problema do Cliente • Clientes sabem que fornecedores odeiam mudanças de requisitos; • Clientes são “forçados” a definir tudo que precisam na fase inicial do projeto; • Clientes no início de um projeto estão inseguros quanto ao que precisam;
- 27. A solução do Cliente • Colocar o máximo possível de requisitos na lista inicial; • Entende‐se por “o máximo possível” tudo que lhe vier à cabeça naquele momento; • Desta forma a possibilidade de “faltar” requisitos no produto final é menor;
- 28. O Problema do Fornecedor • Fornecedores sabem que os requisitos fornecidos pelo cliente são vagos; • Fornecedores sabem que no decorrer do projeto o cliente precisará mudar os requisitos; • Fornecedores sabem que sempre ao validar o produto o cliente surgirão novas idéias para o produto;
- 29. A solução do Fornecedor • Documentar ao máximo tudo que foi passado pelo cliente para que o fornecedor possa estar protegido; • Colocar margens de tempo por todo o projeto; • Entregar o produto para o cliente apenas no final do projeto;
- 30. Resultado Quem mais perde? Conflito entre as partes! A EMPRESA
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40. Tradicional (Cascata) • Orientado a documentação • Feedback no final do projeto • Mudanças são prejudiciais
- 41. Ágil • Desenvolve‐se em ciclos pequenos – Aprende‐se do negócio e da solução iteraPvamente • Ataca os riscos do projeto mais rapidamente • As mudanças não são tão problemáPcas • O cliente da feedback durante todo o projeto
- 42.
- 43.
- 44.
- 45. Manifesto Ágil • “Estamos descobrindo maneiras melhores de desenvolver soXware fazendo‐o nós mesmos e ajudando outros a fazê‐lo. Através desse trabalho, passamos a valorizar: – Indivíduos e interações entre eles mais que processos e ferramentas – Produto em funcionamento mais que documentação abrangente – Colaboração com o cliente mais que negociação de contratos – Responder a mudanças mais que seguir um plano • Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda”. Fonte: hDp://agilemanifesto.org
- 48.
- 49.
- 50.
- 51.
- 52. Quem adota métodos ágeis? MicrosoB Sea Tecnologia (Brasil) Yahoo Nielsen Media Google ThoughtWorks Electronic Arts BMC SoXware Stefanini IT SoluIons (Brasil) Serpro (Brasil) Philips Lexis Nexis Siemens Sabre Nokia Salesforce.com Alterdata (Brasil) Time Warner BBC Globo.com (Brasil)
- 53.
- 54. Scrum é... • Um processo iteraPvo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto; • É mais um framework que uma metodologia, mais aPtude que um processo;
- 55. Scrum também é... • Processo empírico de gerenciamento e controle • Inspeção e adaptação em ciclos e feedback • Usado para gerenciar projetos desde 1990 • Entrega frequente de funcionalidade com valor para o cliente (ROI) • Escalável a projetos distribuídos, grandes e largos • Processos compa{veis com CMMI nível 3 e ISO9001 • Extremamente simples, mas resistente
- 56. A Origem do Scrum Jeff Sutherland, PhD Desenvolvimento IteraPvo e Incremental SCRUM Ken Schwaber
- 57.
- 58. Processos Ágeis e Scrum XP Crystal FDD SCRUM DSDM
- 59. Mapeando algumas caracterísPcas Processos: Reunião Diária, Reunião de Planejamento, Review, RetrospecPva, Planejamento de Release, ... Ferramentas: Quadro Kanban, Post‐ it, Burndown, ... Pessoas: Líder de equipe, Cliente ou representante do produto, Time, ... Cultura: Time mulP‐disciplinar, auto‐ gerenciamente, valores, envolvimento do cliente, entrega frequente, liderança‐colaboraPva, RESPEITO, ...
- 60. Scrum é... Empresa A Empresa B Empresa C
- 61. “Simples de entender, mas di~cil de adotar e praPcar”
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69. A cada iteração é entregue um incremento do soXware
- 70. Itens técnicos, arquitetura, infra‐estrutura, ... Sempre entregar valor! Itens com RoI visível
- 71.
- 72. Planejamento de Releases 2 semanas cada 8 semanas para o primeiro release
- 73. Product Owner Papéis no Scrum ScrumMaster Time
- 74.
- 76. Comando‐Controle X Auto‐Gerenciamento
- 77. Comando‐Controle não! ApáIco: “Não tenho nada pra fazer hoje, ninguém me passou nada e nem sei também o por que eu faço essas coisas!” Pró‐aIvo: “Quando o chefe voltar eu vejo o que ele tem pra me passar, estou sem nada pra fazer” Auto‐gerenciado: “Quando terminar essa aPvidade vou aproveitar o tempo restante pra discuPr melhorias no projeto com a equipe, para atender melhor as necessidades”
- 78.
- 79.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93.
- 94.
- 95.
- 96.
- 97.
- 98.
- 99.
- 100.
- 101. ? Obrigado!!! [piagodinho@gmail.com]