SlideShare uma empresa Scribd logo
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
Product Owner
Scrum Master
Team
 Possui três papeis bem definidos:
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.
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.
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
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!
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda Competitiva Do Cenário Atual

Mais conteúdo relacionado

Mais procurados

Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Software
alexandre_malaquias
 
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Keila Freitas
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
Ricardo Bánffy
 
Apresentando Extreme Programming
Apresentando Extreme ProgrammingApresentando Extreme Programming
Apresentando Extreme Programming
Milfont Consulting
 
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - KanbanMetodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Matheus Costa
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
Adriano Bertucci
 
Caminhos do Scrum
Caminhos do ScrumCaminhos do Scrum
Caminhos do Scrum
jrompkovski
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalho
Ruan Pozzebon
 
Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento
Paulo Ricardo Dalmagro Vinck
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
Milfont Consulting
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
Adriano Bertucci
 
Gestao agil de projetos com Scrum
Gestao agil de projetos com ScrumGestao agil de projetos com Scrum
Gestao agil de projetos com Scrum
Igor Macaubas
 
Seminário - Scrum , Kaban e XP
Seminário - Scrum , Kaban e XPSeminário - Scrum , Kaban e XP
Seminário - Scrum , Kaban e XP
Lays Lopes
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
Daniel Brandão
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
Adolfo Neto
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com Scrum
Marcos Garrido
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em Juazeiro
Paulo Furtado
 
Uma introdução ao SCRUM
Uma introdução ao SCRUMUma introdução ao SCRUM
Uma introdução ao SCRUM
elliando dias
 

Mais procurados (18)

Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Software
 
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Apresentando Extreme Programming
Apresentando Extreme ProgrammingApresentando Extreme Programming
Apresentando Extreme Programming
 
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - KanbanMetodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
Caminhos do Scrum
Caminhos do ScrumCaminhos do Scrum
Caminhos do Scrum
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalho
 
Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
 
Gestao agil de projetos com Scrum
Gestao agil de projetos com ScrumGestao agil de projetos com Scrum
Gestao agil de projetos com Scrum
 
Seminário - Scrum , Kaban e XP
Seminário - Scrum , Kaban e XPSeminário - Scrum , Kaban e XP
Seminário - Scrum , Kaban e XP
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com Scrum
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em Juazeiro
 
Uma introdução ao SCRUM
Uma introdução ao SCRUMUma introdução ao SCRUM
Uma introdução ao SCRUM
 

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

Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To Scrum
Juan Bernabó
 
Apresentação Scrum 2012
Apresentação Scrum 2012Apresentação Scrum 2012
Apresentação Scrum 2012
Libia Boss
 
Scrum
ScrumScrum
Portuguese Scrum
Portuguese ScrumPortuguese Scrum
Portuguese Scrum
Humberto Bruno Pontes Silva
 
Gestão Ágil de Projetos
Gestão Ágil de ProjetosGestão Ágil de Projetos
Gestão Ágil de Projetos
InaniaVerba
 
Gerenciamento de projetos de TI
Gerenciamento de projetos de TIGerenciamento de projetos de TI
Gerenciamento de projetos de TI
Centro Universitário de João Pessoa (UNIPÊ)
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
Rennan Martini
 
Gestao Agil de Projetos com Scrum
Gestao Agil de Projetos com ScrumGestao Agil de Projetos com Scrum
Gestao Agil de Projetos com Scrum
Rafael Ramos
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de software
Roberto Brandini
 
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixModelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Cris Fidelix
 
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
André Dias
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUM
Lucas Vinícius
 
Portuguese scrum
Portuguese scrumPortuguese scrum
Portuguese scrum
Denise Vieira
 
Scrum - Metodologia Ágil
Scrum - Metodologia ÁgilScrum - Metodologia Ágil
Scrum - Metodologia Ágil
Biblioteca Etec de Rgs
 
Scrum Overview - uma introdução ao Scrum
Scrum Overview - uma introdução ao ScrumScrum Overview - uma introdução ao Scrum
Scrum Overview - uma introdução ao Scrum
CompanyWeb
 
Scrum - Profº James Moreira Jr.
Scrum - Profº James Moreira Jr.Scrum - Profº James Moreira Jr.
Scrum - Profº James Moreira Jr.
James Moreira
 
Metodologias Ágeis
Metodologias ÁgeisMetodologias Ágeis
Metodologias Ágeis
Profa Karen Borges
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
Rudson Kiyoshi Souza Carvalho
 
Introdução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com ScrumIntrodução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com Scrum
Juan Bernabó
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
William Lima
 

Semelhante a Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda Competitiva Do Cenário Atual (20)

Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To Scrum
 
Apresentação Scrum 2012
Apresentação Scrum 2012Apresentação Scrum 2012
Apresentação Scrum 2012
 
Scrum
ScrumScrum
Scrum
 
Portuguese Scrum
Portuguese ScrumPortuguese Scrum
Portuguese Scrum
 
Gestão Ágil de Projetos
Gestão Ágil de ProjetosGestão Ágil de Projetos
Gestão Ágil de Projetos
 
Gerenciamento de projetos de TI
Gerenciamento de projetos de TIGerenciamento de projetos de TI
Gerenciamento de projetos de TI
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
 
Gestao Agil de Projetos com Scrum
Gestao Agil de Projetos com ScrumGestao Agil de Projetos com Scrum
Gestao Agil de Projetos com Scrum
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de software
 
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixModelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
 
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUM
 
Portuguese scrum
Portuguese scrumPortuguese scrum
Portuguese scrum
 
Scrum - Metodologia Ágil
Scrum - Metodologia ÁgilScrum - Metodologia Ágil
Scrum - Metodologia Ágil
 
Scrum Overview - uma introdução ao Scrum
Scrum Overview - uma introdução ao ScrumScrum Overview - uma introdução ao Scrum
Scrum Overview - uma introdução ao Scrum
 
Scrum - Profº James Moreira Jr.
Scrum - Profº James Moreira Jr.Scrum - Profº James Moreira Jr.
Scrum - Profº James Moreira Jr.
 
Metodologias Ágeis
Metodologias ÁgeisMetodologias Ágeis
Metodologias Ágeis
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Introdução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com ScrumIntrodução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com Scrum
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 

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

  • 1. 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
  • 2. 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)”
  • 3. Cenário atual do desenvolvimento de software  Metodologias de Engenharia
  • 4. 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.
  • 5. 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
  • 6. Possibilidade de melhoria O Scrum pode contrubuir para a redução desses problemas?Isso tem solução?
  • 7. Projetos complexos e incertezas O Desenvolvimento é uma atividade complexa a qual não se adapta a um processo definido.
  • 8. 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.
  • 9. 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
  • 10. 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
  • 11. 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.
  • 12. Métodos Ágeis  XP  Scrum  Feature Driven Development  Adaptive Software Development  Crystal  Pragmatic Programming  Etc…
  • 13. 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
  • 15. 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.
  • 16. Scrum Product Owner Scrum Master Team  Possui três papeis bem definidos:
  • 17. Scrum  Possui três reuniões bem definidas: Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting
  • 18. Scrum  Possui três instrumentos bem definidos: Product Backlog Sprint Backlog Burndown Chart
  • 20. 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.
  • 21. 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
  • 22. 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.
  • 24. 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.
  • 25. Sprint Backlog  Renovado a cada iteração  Requisitos tornam-se estórias  Estimado pelo time
  • 26. 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.
  • 28. 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.
  • 32. Sprint Planning  Planning 2 Momento o qual o Team se organiza e planeja como serão colocadas as Histórias em prática.
  • 33. 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
  • 34. 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?
  • 35. 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
  • 38. 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
  • 39. Critérios de Análise  3 Entrevistas e 17 Questionários  Product Owner  Scrum Master  Membros do Time
  • 40. 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
  • 41. 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
  • 42. 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.
  • 43. 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
  • 44. 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
  • 45. 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
  • 46. 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
  • 47. 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
  • 48. Entrevista – Scrum Master  Reflexos do Scrum Melhora da Produtividade (2x) Mais qualidade no produto final Motivação Produz-se mais, trabalha-se menos
  • 49. Questionários - Time  Profissionais Designers Desenvolvedores DBAs Arquitetos de Informação  Atuação nas Áreas Esportes Entretenimento Jornalismo Mídias móveis
  • 50. Questionários - Time  Antes Trabalho Mecanizado e Isolado  Migração Inicialmente sem treinamentos Receio devido à quebra de paradigma
  • 51. Questionários - Time  Scrum na prática A cada Sprint ○ Estimativas mais precisas ○ Mais agilidade ○ Mais organização Engenharias Ágeis
  • 52. Questionários - Time  Reflexos do Scrum Fiscalização do Desenvolvimento Maior envolvimento com o Produto Motivação Aumento da produção final
  • 53. Questionários - Time  Pontos Negativos Diminuição de ritmo individual Imaturidade individual na execução do processo
  • 56. 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
  • 57. 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
  • 58. Scrum x Waterfall  3º ponto Problema: Excesso de trabalho. Apontado por: SM Solução com Scrum: - Consequência: Aumento da produtividade
  • 59. 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
  • 60. 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.
  • 61. 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
  • 62. 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.
  • 63. Scrum x Waterfall  8º ponto Problema: Qualidade do produto. Apontado por: SM Solução com Scrum: - Consequência: A qualidade do produto aumentou significativamente.
  • 64. 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
  • 65. 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
  • 66. 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.
  • 67. 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)

Notas do Editor

  1. - 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.
  2. 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.
  3. Dentre muitas metodologias de desenvolvimento, destaca-se, a Waterfall e suas evoluções.
  4. Essas práticas influenciam no desempenho de quem as aplica e nos resultados obtidos. Que de acordo com pesquisas, não se mostram eficazes.
  5. Ao final do prazo, momento considerado mais crítico do desenvolvento, as equipes se deparam com os seguintes problemas: …
  6. Resposta para o bonequinho : “É oq iremos apresentar”
  7. Apresentar dados estatísticos! Por que que essas metodologias nao administram bem essas incertezas?
  8. Tem etapas totalmente definidas. Quando ha garantia de que nao haverá qq mudanca Se nao ha garantia: gerencia de riscos.
  9. 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
  10. 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
  11. Possui três papeis bem definidos:
  12. Representa a figura do cliente. Participação intensa no projeto, sempre presente. Principal responsável pelo valor de negocio a ser entregue.