Your SlideShare is downloading. ×
  • Like
Gerenciamento e desenvolvimento ágil de software
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Gerenciamento e desenvolvimento ágil de software

  • 848 views
Published

 

Published in Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
848
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
46
Comments
0
Likes
0

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
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10

Transcript

  • 1. Erick Herdy SCRUM M étodo ágil para gestão de projetos
  • 2. Criação do modelo SCRUM
    • Janeiro-Fevereiro de 1986;
    • Takeuchi e Nokana lançam “The New Product development Game”
    • Inicialmente, concebido para fábricas de autos e bens de consumo;
    • Equipes cross-functional ;
    • Scrum no Rugby;
    • Onze anos depois, Ken Schwaber formalizou a definição de Scrum e ajudou a implementá-lo em desenvolvimento de software em todo o mundo.
  • 3. Introdução
    • O que é metodologia?
  • 4. Introdução
    • Metodologia , é o estudo dos métodos ou os passos em um determinado processo .
    • A finalidade de uma metodologia, é captar e analisa r as características dos vários métodos disponíveis, avaliar suas capacidades , potencialidades , limitações , distorções e criticar os pressupostos ou limitações das mesmas.
    • Além de ser uma disciplina que estuda métodos, a metodologia é também considerada uma forma de conduzir a pesquisa. (pesquisa acadêmica)
  • 5. Porque estudar métodos?
    • Pesquisas indicam pouca ou quase nenhuma qualidade em softwares desenvolvidos;
      • Cronogramas estourados, custos nas alturas....prejuizo...e prejuizo...
      • A necessidade dos clientes não são alcançadas ;
      • Má , péssima ou nenhuma comunicação com o cliente;
    • A procura pela “ bala de prata ” (BROOKS – 1987)
      • Problemas citados : Complexidade , Conformidade , Mutabilidade e Invisibilidade ;
      • Soluções : Linguagens de alto-nivel, Prototipação, Desenvolvimento incremental, bons desenvolvedores, bons projetistas ......
  • 6. Heavyweight vs Ligthweight
    • Heavyweigth (Plan-driven)
      • Planejamento extensivo, processos bem definidos, reuso, visando produção eficiente e previsvel;
      • Aos poucos atingir a perfeição.
    • Ligthweight (Agile Metods)
      • Planeje , documente somente o suficiente ;
      • Individualidade e satisfação momentânea do cliente;
      • Ser bom o suficiente ;
  • 7. Valores e Diferenciais
    • Nós estamos descobrindo melhores maneiras de desenvolver software, criando-o e ajudando outros a criar. Através desse trabalho, passamos a valorizar:
      • Individuos e interações vs processos e ferramentas ;
      • Software operante mais do que documentações completas ;
      • Colaboração do cliente vs negociações contratuais ;
      • Responder e estar aptos a mudanças do que seguir um planejamento
  • 8. O que são metodologias ágeis?
    • Desenvolvimento ágil de software (do inglês Agile software development ) ou Método ágil é um conjunto de metodologias de desenvolvimento de software . O desenvolvimento ágil, tal como qualquer metodologia de software , providencia uma estrutura conceitual para reger projetos de engenharia de software .
  • 9. Para que? Qual a motivação?
    • Minimizar o risco de desenvolvimento de software em prazos muito curtos;
    • Prover uma melhor comunicação entre os integrantes do projeto;
    • Entregar partes funcionais;
    • Alcançar o “suficiente”
  • 10. Características de um AM (Agile model)
    • É um modelo bom o suficiente, nada mais que isso, e que exibe as seguintes características:
      • Atende ao seu propósito;
      • É inteligível;
      • É suficientemente preciso;
      • É suficientemente detalhado;
      • É suficientemente consistente;
      • Provê um valor positivo;
      • É tão simples quando possível.
  • 11.
    • Pensem em AM não como ciência, mas sim como arte.
  • 12. O que é uma AM ?
    • Atitude, não processo prescritivo;
    • Suplemento aos métodos existentes. Ele não é uma metodologia completa;
    • É uma forma efetiva de se trabalhar em conjunto para atingir as necessidades dos stakeholders do projeto;
    • É efetivo e é sobre ser efetivo;
    • É uma coisa que funciona na prática, não é uma teoria acadêmica;
    • É para desenvolvedores médios, mas não substitui pessoas competentes.
  • 13. O que não é uma AM ?
    • Não é uma bala de prata;
    • Não é um ataque à documentação, pelo contrário, AM aconselha a criação de documentos de valor para o projeto;
    • Não é um ataque as ferramentas CASE;
    • Não é para todo mundo.
  • 14. Objetivos / Funções do SCRUM
    • A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software.
    • Teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum ;
    • Iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.
  • 15. Características do SCRUM
    • Backlog vivo e ativo de todas as tarefas a serem feitas;
    • Sprint é a entrega de um conjunto fixo de itens em um determinado período de tempo.
    • Backlog de produto é mantido pelo “Product Owner” e é uma lista de requisitos que vêm do cliente;
    • Backlog de sprint é uma interpretação do backlog do produto e contém tarefas que serão realizadas durante o próximo sprint para implementar os principais itens no backlog do produto.
  • 16. Como funciona?
  • 17. Integrantes
    • O SCRUM possui três figuras:
      • Product Owner;
      • SCRUM Master;
      • SCRUM TEAM;
  • 18. Product Owner
    • Define as funcionalidades do produto;
    • Decide sobre as entregas e o conteúdo;
    • É responsável pelo ROI (lucratividade);
    • Prioriza as funcionalidades de acordo com o mercado;
    • Ajusta as funcionalidades e prioridades com cada iteração, conforme necessário;
    • Aceita ou rejeita o entregável;
  • 19. SCRUM TEAM
    • Basicamente, consiste em uma equipe de 5 a 12 pessoas;
    • Durante a discução com o Product Owner, o objetivo do sprint é determinado e priorizado, e explorado minuciosamente, determinando pequenas tarefas;
    • O time se auto-organiza e os membros trabalham juntos para a entrega do delivery, sendo todos responsáveis pelo resultado;
    • É quem decide qual trabalho será feito e quais serão as responsabilidades atribuidas. Não existe uma pré-definição de responsabilidades: Todos devem estar aptos a trocar de papel com outro membro do time;
  • 20. SCRUM MASTER
    • Coach do scrum team;
    • Remove todos os impedimentos para que uma determinada tarefa seja realizada;
    • Trabalha constantemente procurando maximizar toda a eficiencia do time, e da condições que eles deem o melhor de si;
    • Esta sempre atento para as tarefas que deverão ser entregues no final de cada sprint;
    • Treinador, fixer e gatekeeper. Ele é o responsável por organizar as reuniões diárias;
    • Isola a equipe de interferências externas;
    • Sempre adota o “aqui-agora”;
    • Ele fica responsável por administrar as reuniões de retrospectiva do projeto, onde todas as decisões são revistas;
  • 21. Iniciando um processo:Sprint Planning
    • Product owner cria a lista com todas as requisições e especificações do produto;
    • SCRUM TEAM seleciona itens a partir do Product backlog que eles possam se comprometer a entregar;
    • Tarefas são identificadas;
    • É feito por toda equipe, e não apenas pelo SCRUM Master;
  • 22. Reunião diária
    • Todos os dias, no mesmo horário, o Scrum Master se reúne com todos os membros do time, e faz três perguntas básicas:
      • O que eu fiz desde ontem?
      • O que eu irei fazer até amanhã?
      • O que me impede de ir adiante?
    • Reuniões duram no máximo 15 minutos;
    • Preferencialmente, de pé =)
  • 23. Sprint review
    • A equipe apresenta o que atingiu durante o sprint
    • Tipicamente, toma forma de apresentação de um demo do produto funcional;
    • Informal;
    • Sem powerpoint;
    • A equipe inteira participa.
  • 24. Entrega / Delivery´s
    • Após a fase do sprint, cada entregável é entregue ao cliente, para ser testado e analisado;
    • Após o cliente validar os entregáveis, é criado um novo sprint backlog;
    • Uma nova fase se inicia, novos entregáveis a caminho.
  • 25. Sprint Retrospective
    • Periodicamente olhar o que funciona e o que não funciona;
    • Tipicamente de 15 a 30 minutos;
    • Feito no final de cada Sprint;
    • A equipe inteira participa e discute o que gostariam de: Começar / Parar / Continuar
  • 26. Conclusões
    • SCRUM pode ser aplicado em qualquer situação;
    • Metodologias ágeis tendem a se aproximar da realidade dos times de trabalho;
    • Não existe solução mágica, apenas times bem organizados e sincronizado;
    • Um time é diferente de uma equipe. No time, todos tem o mesmo objetivo final, todos são responsáveis
  • 27. Riscos e Mitos no Desenvolvimento de soluções Web
    • Riscos
      • Atraso no cronograma;
      • Cancelamento do projeto;
      • Entropia de sistemas de produção;
      • Taxa de defeitos;
      • Incompreensão dos requisitos de negócios e sistemas;
      • Mudanças Constantes;
      • “ Scoope Scrip” (Invasão de requisitos)
      • Alta taxa de evasão de desenvolvedores.
    • Mitos :
      • Podemos coletar todos os requisitos de uma vez só;
      • Podemos antecipar todas as mudanças;
      • Podemos controlar completamente todo o projeto do software;
      • Custo de mudança é por natureza, maior a medida que o projeto avança;
  • 28. Exemplo
    • A ponte mais alta do mundo
  • 29. Obrigado
    • Dúvidas?
    • Perguntas ?
    • [email_address]