netshoes metodologia

Metodologia

Netshoes

● 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

Os projetos hoje:

Funcionalidades de um projeto "cascata" e escopo fechado:

Fonte: Standish Group de 2002

● 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

O que queremos:

● 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

Desafios

Comprometidos × Envolvidos

● 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 valorizadoFonte: http://agilemanifesto.org/

Metodologias

● Métodos ágeis são mais adaptativos que preditivos

● Métodos ágeis são orientados a pessoas, não orientados a processos

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

Metodologia Ágil

● Metodologia Ágil

○ Scrum

○ Kanban

○ XP

○ Lean

Metodologias

● 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

Scrum

● Papéis:○ Scrum Master

○ Product Owner

○ Team

Scrum

● 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

Product Owner - 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

Scrum Master - 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

Team - Responsabilidades

● 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

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

Scrum - Sprints

● 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

Scrum - Product 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

Scrum - Sprint Backlog

Estimativa - Planning Poker

● 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

Scrum - Pull Principle

● 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

Scrum - Sprint Planning

● Todas devem estar relacionadas a um ou mais itens do backlog selecionado

Scrum - Tarefas

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

Kanban Board

● 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

Scrum - Daily Meeting

● 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

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

Scrum - Entrega

● 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)

Scrum - Retrospectiva

● 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

Scrum

● 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?

Scrum - Armadilhas e Riscos

● Método ágil adptado do Sistema de Produc ̧a ̃o da Toyota

● Procura-se examinar tudo o que é feito em um projeto e eliminar o que não é necessário

Lean

● Eliminar desperdícios○ Desperdícios comuns: documentac ̧a ̃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

Lean

● Uma disciplina de desenvolvimento de software

● Valores básicos, tais como: Comunicac ̧a ̃o, Simplicidade, Coragem

● Ciclos rápidos, concretos e contínuos de feedback

● Uma abordagem incremental para o planejamento

● Confianc ̧a em testes automatizados● Uso intensivo de comunicac ̧a ̃o oral no dia-a-

dia

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


● 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


● Práticas Primárias:○ Sentar Junto○ Ambiente Informativo○ Programac ̧a ̃o Pareada○ Integrac ̧a ̃o Contínua○ Histórias do Usuário ○ Programac ̧a ̃o Test-First○ etc...


● 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

Scrum Netshoes

Kanban

Solução

Kanban

Definition of Done:

Tarefa funcionando, testado e validado (por outra pessoa da equipe)

WIP3 tarefas por pessoa

● 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

O que o cliente ganha 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

O que ganhamos com isso?

netshoes metodologia

Documents