O documento discute uma nova abordagem para o desenvolvimento de software diante da demanda competitiva atual. Apresenta o cenário atual e as limitações das metodologias tradicionais, introduzindo os métodos ágeis como possível solução. Realiza um estudo de caso da adoção do Scrum na Globo.com, mostrando melhorias na produtividade, qualidade e satisfação do cliente em comparação ao modelo cascata.

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

14. Scrum em Desenvolvimento
de Software

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

19. Papéis

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.

23. Artefatos

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.

27. Cerimônias

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.

29. História

30. História

31. Planning Poker

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

36. Fluxograma geral do Scrum

37. Empresas que usam Scrum

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

54. Questionários - Time

55. Avaliação dos Resultados

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)

68. Conclusão!