Upload
ale-uehara
View
1.364
Download
3
Embed Size (px)
DESCRIPTION
Treinamento de Scrum/ Kanban (Metodologia Ágil)
Citation preview
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
Scrum
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
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
Scrum
● 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
Scrum
● 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
Scrum
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
Scrum
● 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
Scrum
● 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
Scrum
● 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
Scrum
● 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
Lean
● Método ágil adptado do Sistema de Produc ̧ã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 ̧ã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 ̧ã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 ̧ã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
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
XP - Extreme Programming
● Práticas Primárias:○ Sentar Junto○ Ambiente Informativo○ Programac ̧ão Pareada○ Integrac ̧ão Contínua○ Histórias do Usuário ○ Programac ̧ão Test-First○ etc...
XP - Extreme Programming
● 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?