O documento discute metodologias ágeis para gestão de projetos de software, comparando-as com metodologias tradicionais. Apresenta Scrum como uma metodologia ágil iterativa e incremental que valoriza entregas frequentes de software funcional, transparência e adaptabilidade.

1. Metodologia
Netshoes

4. Os projetos hoje:
● Analogia com engenharia, que tem ênfase em
projetar antes de construir
● UML, cronogramas, documentos (que
demandam grande parte do tempo)
● Estimativas sem embasamento
● Alterações nos requisitos (que são regras, e
não exceção)
● Projetos de software são intangíveis: Só se
sabe o que quer, depois de pronto.
● Projeto de software de sucesso é o que
termina dentro do prazo e orçamento

5. Funcionalidades de um projeto "cascata" e escopo fechado:
Fonte: Standish Group de 2002

6. O que queremos:
● Cliente satisfeito
● Ganhar confiança do cliente
● Entregar projeto com qualidade
● Parar de "jogar os erros" entre TI e Cliente
● Dar prazos com "chutes"
● Ver mais um projeto estourar o orçamento
ou prazo
● Mostrar de forma efetiva o resultado e o
progresso real do projeto

8. Desafios
● Nova cultura (tanto para a equipe como para
o cliente)
● "Trazer" o cliente para o projeto, ficar mais
perto
● Fazer com que o cliente sinta que ele é parte
do projeto
● Equipe auto gerenciável

9. Comprometidos × Envolvidos

10. Metodologias
● Manifesto Ágil
○ Indivíduos e interações mais do que processos e
ferramentas;
○ Software funcional mais do que documentação
extensa;
○ Colaboração com clientes mais do que negociação
de contratos;
○ Responder a mudanças mais do que seguir um
plano.
Apesar de valorizar os itens da direita, o da esquerda é
mais valorizado
Fonte: http://agilemanifesto.org/

11. Metodologia Ágil
● Métodos ágeis são mais adaptativos que
preditivos
● Métodos ágeis são orientados a pessoas, não
orientados a processos

12. Metodologia Ágil
● Projeto de Software é criativo, requer
pesquisa, criatividade, raciocínio
● Mudanças nos requisitos são bem vindas
● Estimativas são revistas e refinadas o tempo
todo
● Projeto de sucesso é o que agrega valor ao
negócio

13. Metodologias
● Metodologia Ágil
○ Scrum
○ Kanban
○ XP
○ Lean

14. Scrum

15. Scrum

16. Scrum
● Entregar projeto de software funcional (não
é demo) e freqüente
● Mudanças "tardias" são bem vindas
● Cliente faz parte do projeto
● Discussão diária com status da equipe
● Transparência no projeto e desenvolvimento
● Processo iterativo, incremental, com times
auto-gerenciados e multi-funcionais

17. Scrum
● Papéis:
○ Scrum Master
○ Product Owner
○ Team

18. Product Owner - Responsabilidades
● Definir a visão e os recursos do produto
● Priorizar e gerenciar o backlog do produto
● Monitorar a rentabilidade(ROI) do produto
● Aceitar ou rejeitar os resultados dos
trabalhos

19. Scrum Master - Responsabilidades
● Orientar o time
● Garantir que o time esteja funcional e
produtivo
● Proteger o time de influências externas
● Remover impedimentos
● Fazer com que o processo seja seguido
● Divulgar o Scrum na organização

20. Team - Responsabilidades
● Estimar o tamanho dos itens do backlog
● Comprometer-se com incrementos do
produto
● Entregar o comprometido
● Monitorar seu próprio desempenho
● Organizar a si mesmo e seu trabalho

21. Scrum - Sprints
● Sprints - iterações (2 a 4 semanas)
○ Corresponde a uma iteração do desenvolvimento
○ Tem como objetivo entregar software funcional
○ É marcado por reuniões e outros eventos
recorrentes,que dão a sensação de continuidade
■ Planning Poker,
■ Sprint Backlog,
■ Daily Scrum Meeting,
■ Retrospective

22. Scrum - Sprints
● Sprints - iterações (2 a 4 semanas)
○ Tem duração fixa, pré-definida (timeboxed)
○ Inicia com um backlog priorizado (e estimado)
○ Fecha com uma retrospectiva do que ocorreu

23. Scrum

24. Scrum - Product Backlog
● Lista de funcionalidades desejadas para o
produto
● Deve estar ordenada por prioridade - A
ordenação pode ser parcial: ao menos os
itens mais prioritários devem ser definidos
● Deve conter estimativas de esforço - Basta
detalhar e estimar os itens mais prioritários
● Não é uma lista completa de todos os
requisitos – O backlog vai mudar e crescer à
medida que se aprende mais sobre o produto
e os clientes

25. Scrum

26. Scrum - Sprint Backlog
● Reunião de planejamento do Sprint,
envolvendo:– Product Owner– Scrum
Master– Time de desenvolvimento– Outros
envolvidos e interessados no produto
● O que acontece nesta primeira reunião:– O
PO descreve os itens de maior prioridade no
backlog– O time faz perguntas e conversa
para decidir quais tarefas ele se compromete
a entregar
● Podem ocorrer re-estimativas de esforço de
tarefas – As tarefas comprometidas são o
Backlog Selecionado

27. Scrum

28. Estimativa - Planning
Poker

29. Scrum - Pull Principle
● O time só se compromete com aquilo que
acha que consegue entregar ao final do
Sprint
● Não há (ou não deve haver) pressão da
hierarquia para compromissos irreais
● Leva a muito mais responsabilidade, pois o
time precisa entregar aquilo que disse que
entregaria
● Exige maturidade e auto-gerenciamento

30. Scrum

31. Scrum - Sprint Planning
● O Scrum Master normalmente está presente
– O Product Owner está à disposição (para
dúvidas)
● O time discute as implicações técnicas de
cada um dos itens selecionados
● Cada item se desdobra em uma ou mais
tarefas
● Cada tarefa é escrita em um post-it
● Se o time concluir que se comprometeu além
da sua capacidade, ele chama o PO e negocia

32. Scrum - Tarefas
● Todas devem estar relacionadas a um ou
mais itens do backlog selecionado

33. Kanban Board

34. Kanban Board
● Quadro onde as tarefas do Sprint ficam
visíveis
● Usado pelo time para se orientar sobre
○ O que ainda não foi feito
○ O que está sendo feito
○ O que já foi feito
● Útil para todos:
○ Permite saber o andamento sem precisar perguntar
○ Ajuda a identificar problemas visualmente

35. Scrum

36. Scrum - Daily Meeting
● Ocorre com todos em pé, diante do quadro
de tarefas
● Duração: cerca de 15 minutos
● Cada membro do time fala sobre três coisas:
○ Que tarefas ele terminou desde a última reunião
○ Que tarefas ele prevê terminar até a próxima reunião
○ O que o está atrapalhando as suas atividades

37. Scrum

38. Scrum - Entrega
● Todo Sprint deve-se entregar software
funcional e que agregue valor para o seu
usuário
● A entrega é o evento que marca o fim do
Sprint
● Em condições normais, é feita no ambiente
de produção – Este é o local onde o usuário
final pode utilizar o sistema
● Importante que cada entrega seja validada
pelo Product Owner e todos os envolvidos no
projeto

39. Scrum - Entrega
● Situações que podem ocorrer:
○ Itens não entregues devem ser refeitos e
voltam para o backlog
○ Surgem novas idéias e melhorias, que vão
para o backlog
○ Descobre-se que o time entendeu algum
item de forma errada
○ Algumas funcionalidades precisam ser
desabilitadas na entrega

40. Scrum

41. Scrum - Retrospectiva
● Reunião que repassa por tudo o que
aconteceu durante o Sprint, com foco em
melhoria contínua– Participam dela todos os
envolvidos no projeto
● Todos conversam sobre o que foi exposto no
quadro (o que ocorreu bem e o que ocorreu
mal)

42. Scrum
● Método adaptativo e iterativo, com foco em
definir o protocolo a ser seguido no projeto
● Define poucos papéis (somente três)
● Não fala muito sobre técnicas de
programação
● Possui mecanismos de auto-avaliação e
melhoria
● Expõe os problemas do time e da empresa

43. Scrum - Armadilhas e Riscos
● Achar que basta fazer as reuniões previstas
pelo Scrum
● Desistir diante dos primeiros problemas e
conflitos
● Nestes momentos, pergunte-se: Este
problema está sendo criado pelo Scrum? Ou
o Scrum só está expondo este problema?

44. Lean

45. Lean
● Método ágil adptado do Sistema de Produção
da Toyota
● Procura-se examinar tudo o que é feito em
um projeto e eliminar o que não é necessário

46. Lean
● Eliminar desperdícios
○ Desperdícios comuns: documentação inútil, recursos
extra, troca de tarefas, espera por tarefas, bugs...
● Amplificar o aprendizado
● Postergar o comprometimento
○ Adiar decisões difíceis e permite ao cliente mudar de
idéia
● Entregar rápido
● Dar poder ao time
● Construir com integridade
● Ver o todo

48. XP - Extreme Programming
● Uma disciplina de desenvolvimento de
software
● Valores básicos, tais como: Comunicação,
Simplicidade, Coragem
● Ciclos rápidos, concretos e contínuos de
feedback
● Uma abordagem incremental para o
planejamento
● Confiança em testes automatizados
● Uso intensivo de comunicação oral no dia-a-
dia

49. XP - Extreme Programming
● Se entregas frequentes é uma boa prática,
vamos entregar software (projeto) o tempo
todo » iterações curtas
● Se testar é bom, vamos testar o tempo todo e
deixar o cliente testar » testes unitários e
de aceitação
● Se integrar o sistema é bom, vamos integrar
o sistema com a maior frequencia possível »
integração contínua

50. XP - Extreme Programming
● Se revisar código é bom, vamos revisar
código o tempo todo »programação
pareada
● Se desenho é bom, vamos torná-lo parte do
dia-a-dia do desenvolvedor » refatoração
Obs: Cuidado com o Débito Técnico

51. XP - Extreme Programming
● Práticas Primárias:
○ Sentar Junto
○ Ambiente Informativo
○ Programação Pareada
○ Integração Contínua
○ Histórias do Usuário
○ Programação Test-First
○ etc...

53. Scrum Netshoes
● Reunião Diária (Standup Meeting) - 15 min
○ O que você fez, e o que vai fazer hoje
○ 12:45h
● Retrospectiva + Reunião de equipe
○ Todo mês
○ Erros e Acertos (quadro)
● Prioridades
○ Projeto: definido com o cliente
○ Demandas: Cid
○ Obs: Não impede da conversa direta com o cliente

54. Solução
Kanban

55. Kanban
Definition of Done:
Tarefa funcionando, testado e validado (por
outra pessoa da equipe)
WIP
3 tarefas por pessoa

56. O que o cliente ganha com isso?
● Confiança na TI
● Mudanças (que sempre acontecem) sem
estresse
● Projetos de softwares de qualidade
● Softwares que agregam valor
● Softwares que realmente serão usados

57. O que ganhamos com isso?
● Equipe integrada
● Equipe motivada, mostrando resultados
● Confiança do cliente
● Visibilidade do projeto (tarefas em
andamento - não fica escondido no
"Project")
● Auto gerenciamento
● Introdução da metodologia na Netshoes
● Visibilidade na Netshoes