• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda Competitiva Do Cenário Atual

on

  • 4,240 views

Apresentação ocorrida em 2008 na Universidade Federal Fluminense.

Apresentação ocorrida em 2008 na Universidade Federal Fluminense.

Statistics

Views

Total Views
4,240
Views on SlideShare
4,200
Embed Views
40

Actions

Likes
12
Downloads
0
Comments
1

4 Embeds 40

http://www.slideshare.net 24
http://juvenil.wordpress.com 13
https://juvenil.wordpress.com 2
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • - Nossa proposta é mostrar as contribuições que o Scrum pode trazer para o cenário atual de desenvolvimento de software. O qual é bastante afetado pelas constantes mudanças de requisitos. Mudanças que os modelos tradicionais não gerenciam de forma adequada.
  • Esse trabalho é centrado em Engenharia de Software das vertentes da vida de um software garantindo a satisfação das necessidades do cliente. A elaboração de um sistema se enquadra no ciclo de resolução de problemas constituído de quatro fases, status quo, definição do problema, desenvolvimento técnico e entrega, sendo tratadas de diferentes formas pelas metodologias.
  • Dentre muitas metodologias de desenvolvimento, destaca-se, a Waterfall e suas evoluções.
  • Essas práticas influenciam no desempenho de quem as aplica e nos resultados obtidos. Que de acordo com pesquisas, não se mostram eficazes.
  • Ao final do prazo, momento considerado mais crítico do desenvolvento, as equipes se deparam com os seguintes problemas: …
  • Resposta para o bonequinho : “É oq iremos apresentar”
  • Apresentar dados estatísticos! Por que que essas metodo logias nao administram bem essas incertezas?
  • Tem etapas totalmente definidas. Quando ha garantia de que nao haverá qq mudanca Se nao ha garantia: gerencia de riscos.
  • Qualquer forma de desenvolvimento empírico deve ser usada quando nao se sabe todo o domínio do problema. -Exemplo: projetos complexos e com muitas mudancas -Nesses processos, as equipes se adaptam e se preparam gradualmente às mudancas que vao ocorrendo
  • Produzem resultados mais significativos Conjunto de simples regras que possibilitam satisfação para os desenvolvedores e clientes. É um processo de desenvolvimento ágil de produtos ou administração de qualquer trabalho iterativo e incremental
  • Possui três papeis bem definidos:
  • Representa a figura do cliente. Participação intensa no projeto, sempre presente. Principal responsável pelo valor de negocio a ser entregue.

Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda Competitiva Do Cenário Atual Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda Competitiva Do Cenário Atual Presentation Transcript

  • UMA NOVA ABORDAGEM NO DESENVOLVIMENTO DE SOFTWARE FACE À DEMANDA COMPETITIVA DO CENÁRIO ATUAL. Autores: Luiz Antonio Rocha Lemos Junior Willen Jorge da Silva Orientador: José Raphael Bokehi
  • Engenharia de Software
    • “ Quando um programa de computador obtém sucesso - quando atinge as necessidades dos usuários , quando sobrevive por um longo período sem falhas , quando é de fácil modificação e mais fácil de usar - ele torna as coisas melhores . Mas quando um software falha em seu objetivo (...) o pior pode acontecer. Todos queremos desenvolver softwares que tornem as coisas melhores (...). (PRESSMAN, 2005) ”
  • Cenário atual do desenvolvimento de software
    • Metodologias de Engenharia
  • Cenário atual do desenvolvimento de software Metodologias com documentação excessiva e desnecessária tiram o foco da boa analise e do bom desenvolvimento, pois passamos a maior parte do tempo nos reportando sobre uma documentação burra e não sobra o mínimo de tempo pra um bom desenvolvimento. Geralmente o cliente não sabe o sistema que quer. Não conhece os requisitos, tem apenas uma idéia.
  • Cenário atual do desenvolvimento de software
    • No momento de entrega do Projeto…
      • Tentativa de prolongar prazo de entrega
      • Entregar com menos funcionalidades  
      • Entregar correndo e perder muito tempo com manutenção e correção de bugs
      • Cancelamento de projeto  
      • Cliente insatisfeito  
      • Desvalorização do software
      • Desvalorização profissionais
  • Possibilidade de melhoria O Scrum pode contrubuir para a redução desses problemas? Isso tem solução?
  • Projetos complexos e incertezas
      • O Desenvolvimento é uma atividade complexa a qual não se adapta a um processo definido.
  • Projetos complexos e incertezas
    • No início de um projeto, os clientes não têm certeza do que querem e os requisítos mudam no decorrer do projeto.
  • Processos Definidos
      • Waterfall , Espiral, Iterativo, etc
      • Determinam o que deve ser feito , quando e como
      • Funciona bem para problemas já conhecidos para um mesmo conjunto de variáveis de entrada
      • Necessitam de procedimentos de gerenciamento de riscos e mudanças
  • Processos Empíricos
      • Utilizados quando não se conheçem todas as variáveis de entrada
      • Equipes se preparam gradualmente
      • Recomendados para projetos complexos e de mudanças
      • Processos Empíricos + Desenvolvimento de Software = Métodos Ágeis
  • O que são Métodos Ágeis?
    • É ter resposta rápida e flexível à mudanças.
    • É ter desenvolvimento evolucionário e iterativo “timeboxed”.
    • Planejamento adaptativo.
    • Entrega evolucionária.
    • “ Lema”: Comportar mudanças.
    • “ Ponto estratégico”: Maneabilidade.
  • Métodos Ágeis
    • XP
    • Scrum
    • Feature Driven Development
    • Adaptive Software Development
    • Crystal
    • Pragmatic Programming
    • Etc…
  • Scrum, o conceito
    • TAKEUCHI e NONAKA ( 1986 )
      • Primeiros estudos
        • Times grande com tarefas específicas
        • Times pequenos multidisciplinares
    Termo Scrum é de origem do esporte Rugby
  • Scrum em Desenvolvimento de Software
  • Scrum
    • É constituído por uma série de regras elementares que certificam que todos os membros da equipe sintam responsabilidade no projeto.
    • Permite mudanças rápidas dos requisitos com flexibilidade enquanto fornecem o máximo de transparência para o cliente .
  • Scrum
    • Possui três papeis bem definidos:
    Product Owner Scrum Master Team
  • Scrum
    • Possui três reuniões bem definidas:
    Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting
  • Scrum
    • Possui três instrumentos bem definidos:
    Product Backlog Sprint Backlog Burndown Chart
  • Papéis
  • Product Owner
    • “ O negociador”
      • Junto ao cliente, tem a missão de promover o retorno do investimento .
      • Responsável por priorizar os requisitos de acordo com o valor de cada um.
      • Negocia a entrega com o time
      • Tem o respaldo de aceitar ou não os resultados do trabalho .
  • Scrum Master
    • “ O pastor”
      • Orienta o Team a trabalhar de forma auto-gerenciável .
      • Procura extrair o máximo do Team a fim de melhorar a qualidade do produto .
      • Responsável por manter as boas práticas do Scrum .
      • É o protetor do Team , resolvendo os impedimentos do projeto
  • Team
    • “ A banda”
      • Responsáveis pela entrega dos requisitos testados.
      • Um grupo multi-disciplinar.
          • Arquitetos de informação, Desenvolvedores, Desiners, etc.
      • Recomenda-se entre 5 e 9 componentes
      • Auto-gerenciável , dispensando hierarquias.
  • Artefatos
  • Product Backlog
    • Contém os requisítos definidos numa lista priorizada pelo Product Owner .
    • Lista contendo todo o conteúdo desejado para o projeto.
    • É tratado para que cada item possua valor de negócio para o cliente .
    • Requisitos podem ser repriorizados no decorrer do projeto .
  • Sprint Backlog
    • Renovado a cada iteração
    • Requisitos tornam-se estórias
    • Estimado pelo time
  • Burndown Chart
    • Forma simples e clara de representar o rítmo do desenvolvimento no decorrer de um Sprint
    • É um gráfico (tarefas feitas x dias) atualizado a cada Daily Scrum , projetando a conclusão das tarefas do Sprint Backlog.
  • Cerimônias
  • Sprint Planning
    • Planning 1
      • É apresentado o Backlog para que o PO e o Team possam decidir o foco do Sprint.
      • Os ítens com maior prioridade são colocados no formato de História para serem estimados .
    Planning 2
  • História
  • História
  • Planning Poker
  • Sprint Planning
    • Planning 2
      • Momento o qual o Team se organiza e planeja como serão colocadas as Histórias em prática.
    Planning 2
  • Sprint Planning
    • Planning 2
      • O Sprint Backlog é quebrado em tarefas a serem concluídas em um dia .
      • Obtem-se o Sprint Backlog que será o instrumento de orientação do Team no decorrer do Sprint
    Planning 2
  • Daily Scrum
    • Reuniões diárias com o objetivo de alinhar e integrar as iterações dentre os componentes
    • do time, respondendo as seguintes
    • perguntas:
      • O que fiz?
      • Houve algum impedimento?
      • O que irei fazer?
  • Product Review
    • É o momento em que são apresentados os resultados do Sprint .
    • O produto incremental pronto e testado é apresentado ao Product Owner e/ou aos clientes.
    • PO irá decidir se o Team atingiu o objetivo.
    • É feita um retrospectiva
  • Fluxograma geral do Scrum
  • Empresas que usam Scrum
  • Estudos de casos
    • Alvo do estudo
      • Globo.com
        • Empresa de Tecnologia em Internet
        • Portais (Jornalismo, Entretenimento Esportes e Vídeos )
        • Aplicativos (Cartola, 8p, Futpédia, Globoamazônia, etc)
        • Conteúdo em Mídias Móveis
        • Provisionamento de Internet
  • Critérios de Análise
    • 3 Entrevistas e 17 Questionários
        • Product Owner
        • Scrum Master
        • Membros do Time
  • Entrevista - Product Owner
    • Perfil do entrevistado
      • 13 anos de experiência com projetos de Internet
      • Sony BMG , Carvalho Rocha, GlaxoSmithKline e outras.
      • Foi Analísta de Produto , cargo semelhante ao Product Owner
  • Entrevista - Product Owner
    • Antes
      • Todos projetos apresentavam discrepâncias
      • Não correspondiam às expectativas do cliente
    • Migração
      • Treinamento Geral de Scrum
      • Apreensão
      • Novo Treinamento
  • Entrevista - Product Owner
    • Scrum na prática
      • Projeto Amazônia
        • Idéia Inicial
        • Mudança de Abordagem tranquila devido à Inspeção e Adaptação
        • Relação Cliente-PO e PO-Time sem ruídos.
  • Entrevista - Product Owner
    • Reflexos do Scrum
      • Uso de Sprints
      • Product Owner, o mediador
      • Participação da Equipe nas soluções
      • Motivação da Equipe
      • Estórias
    • Ponto Negativo
      • Scrum não prevê abordagem para manutenção de sistemas anteriores
  • Entrevista – Scrum Master
    • Perfil
      • Atual Gerente de Desenvolvimento de Aplicações Web
      • 10 anos de experiência com projetos de Internet
      • Produziu
        • Globo Vídeos
        • BBB
        • Copa do Mundo on-line
      • Precursor do Scrum na Globo.com
  • Entrevista – Scrum Master
    • Antes
      • Treinamentos RUP e Certificações PMI
      • PMO - Project Manager Office
      • Sem resultados
    • Migração
      • Scrum surgiu informalmente
      • Foi recusado
      • Treinamento independente
  • Entrevista – Scrum Master
    • Scrum na prática
      • Projeto BBB - prazo irreal
      • Autorização para uma nova abordagem
      • Criação de Equipe Multidisciplinar
      • Desorganização Inicial
      • 1ª Estória: Teste: 3 dias - Término: 1 dia
      • 1º Sprint: Apenas metade do planejado
        • Problemas de comunicação
  • Entrevista – Scrum Master
      • Redu ção da Equipe
        • Aumento da produtividade
        • Conclusão antes do prazo
      • Repercussão devido ao sucesso
      • Palestra para Diretoria sobre Scrum
  • Entrevista – Scrum Master
    • Reflexos do Scrum
      • Melhora da Produtividade ( 2x )
      • Mais qualidade no produto final
      • Motivação
      • Produz-se mais , trabalha-se menos
  • Questionários - Time
    • Profissionais
      • Designers
      • Desenvolvedores
      • DBAs
      • Arquitetos de Informação
    • Atuação nas Áreas
      • Esportes
      • Entretenimento
      • Jornalismo
      • Mídias móveis
  • Questionários - Time
    • Antes
      • Trabalho Mecanizado e Isolado
    • Migração
      • Inicialmente sem treinamentos
      • Receio devido à quebra de paradigma
  • Questionários - Time
    • Scrum na prática
      • A cada Sprint
        • Estimativas mais precisas
        • Mais agilidade
        • Mais organização
      • Engenharias Ágeis
  • Questionários - Time
    • Reflexos do Scrum
      • Fiscalização do Desenvolvimento
      • Maior envolvimento com o Produto
      • Motivação
      • Aumento da produção final
  • Questionários - Time
    • Pontos Negativos
      • Diminuição de ritmo individual
      • Imaturidade individual na execução do processo
  • Questionários - Time
  • Avaliação dos Resultados
  • Scrum x Waterfall
    • 1º ponto
      • Problema : Discrepância entre a expectativa do cliente e o produto entregue.
      • Apontado por : SM, PO, Time
      • Solução com Scrum :
        • Maximização da Interação Product Owner-Time através da convivência diária
      • Consequência : Inexistência de ruídos de comunicação
  • Scrum x Waterfall
    • 2º ponto
      • Problema : Falta de motivação.
      • Apontado por : SM, PO
      • Solução com Scrum :
        • Participação na solução de negócio.
      • Consequência : Ligação afetiva com o produto
  • Scrum x Waterfall
    • 3º ponto
      • Problema : Excesso de trabalho.
      • Apontado por : SM
      • Solução com Scrum : -
      • Consequência : Aumento da produtividade
  • Scrum x Waterfall
    • 4º ponto
      • Problema : Insegurança sobre a entrega do produto .
      • Apontado por : PO
      • Solução com Scrum :
        • Sprints, Sprint Review Meeting e Burndown Chart.
      • Consequência : O cliente tem contato com o produto desde os primórdios do desenvolvimento , avalia-o constantemente e tem conhecimento da velocidade de produção
  • Scrum x Waterfall
    • 5º ponto
      • Problema : Necessidade mudanças.
      • Apontado por : PO
      • Solução com Scrum :
        • Sprint Backlog aberto.
      • Consequência : mudança de rumo do sistema a qualquer altura do desenvolvimento.
  • Scrum x Waterfall
    • 6º ponto
      • Problema : Dificuldade na realização de testes
      • Apontado por : PO
      • Solução com Scrum :
        • Sprints
      • Consequência : Possibilidade de testar o sistema aos poucos
  • Scrum x Waterfall
    • 7º ponto
      • Problema : Controle da velociadade.
      • Apontado por : PO
      • Solução com Scrum:
        • Burndown Chart.
      • Consequência: Tem-se a noção diária se a velocidade da equipe é suficiente para se atingir o objetivo do Sprint.
  • Scrum x Waterfall
    • 8º ponto
      • Problema : Qualidade do produto.
      • Apontado por : SM
      • Solução com Scrum: -
      • Consequência: A qualidade do produto aumentou significativamente .
  • Scrum x Waterfall
    • 9º ponto
      • Problema : Exclusividade do time .
      • Apontado por : PO
      • Consequência: No Waterfall não há necessidade de exclusidade dos membros do time . A ausência ou mudança de membros pode ocorrer sem problemas
  • Scrum x Waterfall
    • 10º ponto
      • Problema : Manutenção de sistemas em produção.
      • Apontado por : PO
      • Consequência: No Waterfall não há necessidade de exclusidade dos membros do time . A ausência ou mudança de membros pode ocorrer sem problemas
  • Scrum x Waterfall
    • 11º ponto
      • Problema : Diminuíção da qualidade técnica do produto
      • Apontado por : Time
      • Consequência: No Waterfall , cada profissional pode se focar apenas em seu trabalho técnico e portanto produzir algo de boa qualidade técnica.
  • Por que usar Scrum?
    • Permite obter máximo valor de negócio no menor tempo possível.
    • Entrega peródica de software pronto para ser testado .
    • Cliente ativo no decorrer do processo inspecionando os incrementos de forma rápida e contínua. (Em intervalos regulares )
  • Conclusão!
  •