• Like
Netshoes metodologia
Upcoming SlideShare
Loading in...5
×

Netshoes metodologia

  • 150 views
Uploaded on

 

  • 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
150
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
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

Transcript

  • 1. Metodologia Netshoes
  • 2. 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
  • 3. Funcionalidades de um projeto "cascata" e escopo fechado: Fonte: Standish Group de 2002
  • 4. 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
  • 5. 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
  • 6. Comprometidos × Envolvidos
  • 7. 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/
  • 8. Metodologia Ágil● Métodos ágeis são mais adaptativos que preditivos● Métodos ágeis são orientados a pessoas, não orientados a processos
  • 9. 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
  • 10. Metodologias● Metodologia Ágil ○ Scrum ○ Kanban ○ XP ○ Lean
  • 11. Scrum
  • 12. Scrum
  • 13. 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
  • 14. Scrum● Papéis: ○ Scrum Master ○ Product Owner ○ Team
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. Scrum
  • 21. 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
  • 22. Scrum
  • 23. 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
  • 24. Scrum
  • 25. Estimativa - PlanningPoker
  • 26. 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
  • 27. Scrum
  • 28. 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
  • 29. Scrum - Tarefas● Todas devem estar relacionadas a um ou mais itens do backlog selecionado
  • 30. Kanban Board
  • 31. 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
  • 32. Scrum
  • 33. 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
  • 34. Scrum
  • 35. 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
  • 36. 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
  • 37. Scrum
  • 38. 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)
  • 39. 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
  • 40. 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?
  • 41. Lean
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. 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
  • 46. 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çãoObs: Cuidado com o Débito Técnico
  • 47. 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...
  • 48. 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
  • 49. SoluçãoKanban
  • 50. KanbanDefinition of Done:Tarefa funcionando, testado e validado (poroutra pessoa da equipe)WIP3 tarefas por pessoa
  • 51. 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
  • 52. 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