Post on 30-Jun-2015
description
INTRODUÇÃO AO DESENVOLVIMENTO ÁGILCOM SCRUM
TEORIA E PRÁTICAWelington Veiga / @welingtonveiga
SOBRE MIM...Graduado e mestrando em Ciência daComputação pela UFJFCoordenador de TI na AfferoLabCertified ScrumMaster pela ScrumAlliance.
E VOCÊ?Já trabalha no mercado de TI?Já conhece alguma coisa deDesenvolvimento Ágil?Alguém já sabe o que é SCRUM?
BEM VINDO A BORDO!
AGENDA:
PARTE 1 - ANTES DO MOVIMENTO ÁGIL
ENGENHARIA DE SOFTWARE "TRADICIONAL"Analogia com a Engenharia.Foco em Processos eFerramentas.Determinismo.
O MODELO CASCATA (WATERFALL)Engenharia de Sistemas.Análise de Requisitos.Projeto.Codificação.Testes e Integração.Operação e codificação.
DIFERENTES PAPÉIS DENTRO DO PROJETOGerente de ProjetoAnalista de SistemasArquiteto de SistemasProgramadorTesterImplantadorOperador de plataforma
PLANEJAMENTO DE TODO O SOFTWARE!
QUAL O PROBLEMA?
A NATUREZA DO TRABALHO NODESENVOLVIMENTO DE SOFTWARE NÃO É A
MESMA DO TRABALHO NA CONSTRUÇÃOCIVIL.
UM PLANEJAMENTO DETALHADO DE LONGO PRAZO EXIGE UMESCOPO BEM DEFINIDO E FIXO.
Dificuldade em levantar todos osrequisitos de uma vezO cliente não sabe de tudo o queele precisa a priori!O Mundo muda cada vez maisrápido!
PESADAS FERRAMENTAS DE PLANEJAMENTO,ACOMPANHAMENTO E CONTROLE.
Muitos documentos e artefatos.Estimativas complexas.Controle preciso das tarefas ecronogramasDiferentes papéis comatribuições específicas
QUAL É O CENÁRIO IDEAL EM UM PROCESSODETERMINÍSTICO?
“Dia 17 de Fevereiro de 2015, às 13h45, oProgramador I vai colocar o botão de
visualização de detalhes na tela de cadastro declientes, e vai gastar 15 minutos para terminar,com uma margem de erro de até 2 dias para o
início da tarefa.”
VAI DAR CERTO?
OS NÚMEROS RESPONDEM...
Taxa de sucesso e flha em projetos de software segundo TheStandish Group's industry survey (1994; 2012).
COMO RESOLVER?Mais processos!Mais ferramentas!Mais controle!Escopo ainda mais definido!
FRUSTRAÇÃO!Desenvolvedores desgastadosProjetos falhandoClientes frequentemente mal atendidos
DÚVIDAS?
PARTE 2 - MANIFESTO ÁGIL
UM POUCO DE HISTÓRIA...Reunião de 17 profissionais que já vinham praticando epublicando sobre metodologias mais "leves". Isso em 2001 nacidade de Utah, EUA.Definir pontos comuns entre o que eles acreditavam.Aí surgiu o termo Ágil (Agile)Foram definidos 4 valores e 12 princípios.
QUEM ERAM OS 17?Kent Beck @KentBeckMike Beedle@mikebeedl3Arie v. Bennekum@arievanbennekumAlistair Cockburn@TotherAlistairWard Cunningham@WardCunninghamMartin Fowler@martinfowler
James Grenning@jwgrenningJim Highsmith@jimhighsmithAndrew Hunt@PragmaticAndyRon Jeffries@RonJeffriesJon Kern@JonKernPABrian Marick@marick
Robert C. Martin@unclebobmartinSteve MellorKen Schwaber@kschwaberJeff Sutherland@jeffsutherlandDave Thomas@pragdave
MANIFESTO PARA DESENVOLVIMENTO ÁGILDE SOFTWARE
Estamos descobrindo maneiras melhores de desenvolversoftware, fazendo-o nós mesmos e ajudando outros a fazerem o
mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentasSoftware em funcionamento mais que documentaçãoabrangenteColaboração com o cliente mais que negociação de contratosResponder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamosmais os itens à esquerda.
INDIVÍDUOS E INTERAÇÕESMAIS QUE PROCESSOS E FERRAMENTAS
SOFTWARE EM FUNCIONAMENTOMAIS QUE DOCUMENTAÇÃO ABRANGENTE
COLABORAÇÃO COM O CLIENTEMAIS QUE NEGOCIAÇÃO DE CONTRATOS
RESPONDER A MUDANÇASMAIS QUE SEGUIR UM PLANO
ATENÇÃO!ISSO NÃO QUER DIZER QUE...
...não existem processos e ferramentas!
...não é necessário ter documentação.
...não precisamos de contrato.
...não seguimos um plano.
O QUE É O MANIFESTO ÁGIL?Conjunto de valores e princípios para desenvolvimento desoftware.Não é prescritivo, não define regras!É uma visão de desenvolvimento de software centrada empessoas.
DÚVIDAS?
PARTE 3 - AGILIDADE
PROCESSO DETERMINÍSTICOTRAJETO DE AVIÃO
PROCESSO EMPÍRICOTRAJETO DE CARRO
COM QUAL DESSES CENÁRIOS ODESENVOLVIMENTO DE SOFTWARE SE
PARECE?
AÇÃO, INSPEÇÃO E ADAPTAÇÃO!Definir um plano bom o bastante.Definir uma forma de avaliar o progresso.Adaptar o plano, as métricas e processo iterativamente.
FEEDBACK CONTÍNUO!
CUSTO PARA CORRIGIR UM PROBLEMA AOLONGO DO CICLO DE VIDA
PROBLEMA PODE SER UM BUG, UM TESTE NÃO REALIZADO, A FALHA NA ESPECIFICAÇÃO OU ONÃO ENTENDIMENTO DA NECESSIDADE DO CLIENTE.
NÃO QUEREMOS DESPERDÍCIO!
DESENVOLVIMENTO INCREMENTALDesenvolvimento preparado para a mudança!
ENTREGAS FREQUENTES:
INTEGRAÇÃO CONTÍNUA
ENTREGAS FREQUENTES:
TESTES AUTOMATIZADOS
ENTREGAS FREQUENTES:
CÓDIGO LIMPOREFACTORING(REDESENHO)
ENTREGAS FREQUENTES:
Excelência técnicaDevops...
PROCESSO SUSTENTÁVEL
FOCO NAS PESSOAS E INTERAÇÕES!Valorização das conversas face-a-faceAmbiente de trabalho adequado e com pessoas motivadasConfiança
MELHORIA CONTÍNUA!TÉCNICA, PROCESSOS, FERRAMENTAS E INTERAÇÕES.
DÚVIDAS?
PARTE 4 - SCRUM
SCRUM?
SCRUM EM ENGENHARIA DE SOFTWARE?Framework para gerenciamento de projetos de softwareO que isso quer dizer?
Não é uma metodologia de desenvolvimento.Não é um processo de desenvolvimento.Você vai ter que adaptá-lo.
UM FRAMEWORK É UM ARCABOUÇO A PARTIR DO QUAL VOCÊCONSTRÓI O QUE PRECISA.
1. PAPÉIS
PRODUCT OWNER (PO)QUEM É?
Pessoa que representa o produto.Responsável por definir a visão do produto e garantir, atravésdo trabalho da equipe, o maior retorno de investimentopossível para o cliente.
PRODUCT OWNER (PO)O QUE FAZ?
Define e prioriza o que deve ser desenvolvido pela equipe.Mantem a comunicação direta com os stakeholders.Define visão do produto junto com o cliente e garante que otrabalho segue em direção a ela.
TIMEQUEM É?
Grupo muldisciplinar de pessoas, responsável pelodesenvolvimento do produto.Auto-organizado.Pequeno.Motivado.
TIMEO QUE FAZ?
Planeja como vai executar o trabalho.Faz as tarefas necessárias.Interage com o PO sempre que necessário para esclarecerdúvidas.
SCRUM MASTERQUEM É?
Responsável por facilitar e potencializar o trabalho do time deSCRUM.Atua ajudando a manter e aperfeiçoar o uso do SCRUM portodos os envolvidos no projeto.Ajuda o Time e o PO a serem mais eficientes na realização deseu trabalho.
SCRUM MASTERO QUE FAZ?
Facilita o trabalho do Time.Resolve conflitosRetira impedimentos encontrados pelo Time.Promove as mudanças organizacionais necessárias para que oTime possa fazer seu trabalho.Assegura que o SCRUM seja corretamente entendido eutilizado pelo Time.
PRODUCT OWNER (PO)Define e apresenta para o Time o que deve ser desenvolvidoTira dúvidas do Time em relação ao que deve ser feito.Aceitar ou rejeitar o trabalho desenvolvido pelo Time.
TIMEPlaneja de forma vai executar o que é definido pelo PO.Executa todas as tarefas para que o trabalho seja feito.Recebe feedback do PO em relação ao trabalho desenvolvido.
SCRUM MASTERUtiliza técnicas de facilitação para auxiliar o Time.Remove impedimentos para a execução do trabalho.Garante que todos entendem e aplicam corretamente oSCRUM.
IMPORTANTE!NÃO BUSQUE CORRESPONDÊNCIAS COM OS PAPÉIS NA
ENGENHARIA DE SOFTWARE TRADICIONAL.
IMPORTANTE!O QUE OS PAPÉIS NÃO SÃO!!!
O PO...não define como o trabalho deve ser feito.
O Scrum Master...não é o "chefe" da equipe....não gerencia as tarefas do time.
PROCESSO ITERATIVOCada ciclo completo de planejamento, desenvolvimento eentrega é chamado SprintUm Sprint varia de 1 a 4 semanas.
SPRINT NO SCRUMTodo Sprint tem um período fixo e uma meta.O Time negocia com o PO o quanto de trabalho conseguerealizar nesse período.O Time se compromete com a entrega que será realizada.No fim do Sprint, o PO valida a meta.
REGRA DE OURO!TODO RESULTADO DE SPRINT DEVE SER UM INCREMENTO PRONTO PARA ENTREGA.
FEEDBACK!!!
Após aceitar uma entrega ao fim do Sprint o PO decide quandoentregá-la ao cliente.
2. ARTEFATOS
PRODUCT BACKLOGLista com os Itens que precisam ser desenvolvidos.Sempre ordenada de acordo com a prioridade dos Itens.Apenas o PO pode alterar o Product Backlog.O PO pode alterar o Product Backlog a qualquer momento.
EXEMPLO DE PRODUCT BACKLOG
SPRINT BACKLOGOs Itens selecionados para o desenvolvimento no SprintOrdenado de acordo com a Prioridade dos ItensO Sprint backlog está congeladostrong> até o final do Sprint
EXEMPLO DE SPRINT BACKLOG
SCRUM BOARDQuadro de tarefas do SCRUM (Quadro Kanbam).Controle e visibilidade das tarefas da equipe.Deve exibir sempre a realidade e o plano atual.Pode ser apenas eletrônico, mas o ideal é que seja físico.
EXEMPLO DE SCRUM BOARD
PRONTO SIGNIFICA PRONTO!DEFINIÇÃO DE PRONTO
BURNING DOWN CHARTGráfico pata acompanhamento do progresso do Sprint.Compara o progresso ideal com o real.Visibilidade.
BURNING DOWN CHART
ARTEFATOS DO SCRUM1. Product Backlog2. Sprint Backlog3. SCRUM Board Backlog4. Burning Down
É só isso???Depende.
3. EVENTOS
SPRINT:D
SPRINT PLANNINGPO, TIME E SCRUM MASTER
Detalhar e estimar os Items do topo do backlogNegociar com o PO o quanto de trabalho que cabe no Sprint.Estabelecer a meta do Sprint.Equipe vai "tarefar" os Itens do Sprint backlog.
LIMITE DE TEMPO!
DAILY SCRUMTIME E SCRUM MASTER
Reunião diária, sempre no mesmo horário.Feita em pé.Limite de tempo. 15 minutosObjetivo:
Entender o que foi feito dede o último Daily SCRUM.Identificar problemas e impedimentos.Comunicação!!!
SPRINT REVIEWPO, TIME E SCRUM MASTER
O Time apresenta os Itens desenvolvidos no Sprint.O PO aceita ou rejeita os items de acordo com o estabelecidono Sprint Planning.
RETROSPECTIVATIME, SCRUM MASTER (E PO)
Ação, Avaliação, Adaptação.Identificar eventos que atrapalharam a equipe ao longo doSprint.Identificar pontos positivos.Identificar pontos de melhoria.Propor ações e combinados para a melhoria da equipe,processos, produto, entrega...
RETROSPECTIVAATENÇÃO!!!
Não é lavação de roupa suja.Não é rasgação de seda.Ambiente seguro.
VISÃO GERAL DO SCRUM:
FALAMOS DE TUDO?Como são feitas as estimativas?Como é consuzida a retrospectiva?Como é feita a tarefação?
DÚVIDAS?
PARTE 5 - O DIA-A-DIA DE UM TIME ÁGIL
BUSCA PELA MELHORIA CONTÍNUA!Excelência técnica.Estar pronto para compartilhar conhecimento e aprender.
MULTIDISCIPLINARIDADETodo mundo sabe um pouco de tudo.
POSSE COLETIVATodo trabalho, tarefa, sucesso ou falha é divido pela equipe.
COMPROMETIMENTO
MOTIVAÇÃO
TODO MUNDO SE ADAPTA?NÃO.
PARTE 6 - CONSIDERAÇÕES FINAIS
DESENVOLVIMENTO ÁGIL É A SOLUÇÃO DE TODOS OSPROBLEMAS?
NÃO.
Escopo bem definido e imutável.Modelos de contrato inflexível.Clientes que não querem proximidade com a equipe dedesenvolvimento.Níveis de gestão não entendem ou não aceitam.
COMO EU COMEÇO?DEVAGAR!
Estude.Mude aos poucos.Ação, inspeção, adaptação.
CONTE COMIGO!WELINGTON VEIGA
welington.veiga@gmail.com@welingtonveigaLinkedin
OBRIGADO!