Métodos Ágeis de Gerência de Desenvolvimento de Software Rodrigo de Toledo CCE / PUC-Rio 10-17 abril 2010 gmail: rodrigodetoledo 1
Plano Introdução: Motivação Histórico Princípios XP Scrum: Fluxo Scrum (Scrum Flow) Personagens, artefatos e meetings Prática: Velocidade, Sprint, Review Aplicações, mitos e restrições Exemplos Conclusão: Metodologias ágeis no mundo Scrum e CMMI Pontos fortes e pontos frágeis Como introduzir metodologias ágeis Por onde começar? Contratos Dicas 2
Informações Gerais! Assunto apaixonante Assunto polêmico Quebra de paradigmas Depende é sempre a melhor resposta Uso excessivo do inglês Termos Dificuldades de tradução (ex: meetings cerimônias) Não se desespere Métodos Ágeis não servem para tudo Arrogância x Respeito Perguntas a vontade (mas respostas só no momento certo) Horário intervalo? 3
Introdução 4
Motivação Métodos Ágeis Metodologias apropriadas a essa nova ciência: a engenharia de software O que tem de tão interessante: Processos iterativos, Orientado a pessoas, Times multidisciplinares, Inspeção/adaptação, Time-box Alta produtividade (4 a 10 vezes maior) Satisfação de todos: clientes, usuários, gerentes e desenvolvedores 5
Motivação Métodos Ágeis Mudanças de paradigma 6
Motivação Quais são os problemas mais freqüentes em projetos de TI? Responder interativamente Lembrar dos diferentes pontos de vista: Desenvolvedor Gerente de TI Cliente Usuário 7
O que é Método Ágil? É um processo? Não É um novo modelo mental? Talvez É um nome-guarda-chuva para diversos métodos? Sim É uma jogada de marketing? Provavelmente 8
Motivação Auto-ajuda 1. Independente da situação, você sempre pode melhorar. 2. Você sempre pode começar a melhorar por você mesmo. 3. Você sempre pode começar hoje. X Kent Beck (XP) 9
Termos Métodos Ágeis: Se contrapõem às metodologias de engenharia clássica, usualmente aplicados ao desenvolvimento de software. Ex: XP, Scrum, Crystal, Lean, (RUP?), DSDM, FDD, Evo... Iteração: Etapas curtas (1 a 4 semanas) de planejamento/desenvolvimento. Se contrapõem ao processo em cascata. Adaptação: Opção verdadeira à natureza imprevisível do desenvolvimento de software. Troca-se o par planejamento/controle por inspeção/adaptação. Auto-organização: As pessoas são responsáveis pelo seu próprio trabalho. (orientado a pessoas X orientado a processos). Time-box: Todas as etapas devem estar contidas no seu tempo. Isso é mais importante que a completude do escopo. Prazo fixo, escopo variável. 10
Um pouco de história do desenvolvimento de software 11
Motivação Caos Desenvolvimento caótico Code and fix ou Quick and dirty Um cara só faz tudo - generalista Pode funcionar para aplicações pequenas Pontos negativos: Imprevisível Dono do código Baixo reuso Dificuldade de manutenção... 12
Motivação - Engenharia Metodologias de engenharias Eng. de sw é muito nova comparada com as demais Por que não usar outras metodologias clássicas? Engenharia civil, mecânica... Planejamento Implementação Linha de montagem (cascata) Cada etapa tem um responsável diferente - especialistas Benefícios: Gerenciamento facilitado (pessoas são peças) Reuso possível Mais formalidade no relacionamento com o cliente 13
Motivação - Engenharia Metodologias de engenharias Questionamentos: Esforço no planejamento é muito maior que nas outras engenharias É previsível? Desenvolvimento de sw é considerado a atividade mais complexa do ser humano. Pontos negativos: Software não é prédio Perda de flexibilidade Falsas verdades 14
Motivação - Engenharia Construir software NÃO É igual a construir prédio Metáforas são perigosas (mas quase inevitáveis) Nosso peão é um arquiteto (criativo, artista) Desde a primeira prova de programação Peão feliz/infeliz (muro/igreja) Se derrubar uma parede errada, basta fazer um ctrl+z Falta um tijolo no prédio falta um ; no código? Não estamos presos a leis físicas Ex: gravidade, replicação... Mudanças tecnológicas maiores em impacto e freqüência. 15
Motivação - Engenharia Perda de Flexibilidade Mudanças externas constantes Decorrentes da imprecisão dos requisitos Falha de quem está levantando Incapacidade do cliente em detalhar (ex: construção customizada de um carro) Frase comum: o problema deste projeto é que os requisitos vivem mudando Mudança de tecnologia Decorrentes das mudanças de necessidades do negócio 16
Motivação - Engenharia Perda de Flexibilidade - The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process (Jeff Sutherland et al. 08) Incerteza é inerente e inevitável em desenvolvimento de software, processos e produtos Hadar Ziv The Uncertainty Principle in Software Engineering Em um novo sistema, os requisitos não serão completamente conhecidos até que os usuários o tenham usado Watts Humphrey A Discipline for Software Engineering Não é possível especificar completamente um sistema interativo Peter Wegner Why Interaction is More Powerful than Algorithms17
BDUF Big Design Up Front Projetos de TI: 1993, Caper Jones Grandes sistemas: 65% de fracasso 1999, Jarzombek DOD: 75% de fracasso 2001, Thomas Sistemas em UK: 87% de fracasso 18
Motivação - Engenharia Mitos sobre as metodologias de engenharia: Esforço maior apenas no início do projeto Pessoas são apenas peças do processo Quanto mais informação escrita melhor Previsibilidade Processos criativos não são fáceis de planejar ((A engenharia de software é ao mesmo tempo uma ciência precisa/matemática e um exercício criativo/humano)) Pior ainda: Fingir que é previsível Documentos que não são lidos Documentos para descrever como algo será feito escritos depois desse algo feito Fim do projeto! Bom projeto tem fim? O que é um produto de sucesso? No prazo, no custo e de acordo com o plano Não! Maior valor agregado (business value) no menor custo 19
Video 20
Histórico Métodos Ágeis Anos 80 (qualidade) Nonaka e Takeuchi: Knowledge Management (gestão do conhecimento) Papers: The New New Product Development Game, 1986 The knowledge-creating company Toyota, Xerox, 3M, Fujifilm... Lenda ou fato? Qualidade começou nos anos 70 com um americano * SmallTalk (Xerox, 1980) OO, metaclasses, dev. Environment. 1983: virtual machine e unit test * http://en.wikipedia.org/wiki/w._edwards_deming http://en.wikipedia.org/wiki/joseph_m._juran 21
Histórico Métodos Ágeis Anos 90 XP (Kent Beck e Ron Jeffries, ~97) 5 valores, 14 princípios, 24 práticas Outra lenda: Kent Beck desafia QA s (GQS) em 2001 TDD (Test Driven Development) Scrum (Jeff Sutherland, Ken Schwaber, Mike Beedle 93~95~99) Mais gerencial que XP Crystal (Alistair Cockburn) FDD Lean / Kanban (Toyota) 22
Histórico Métodos Ágeis Influência do Scrum no XP Tem como pegar umas cópias do artigo sobre SCRUM do HBR? Tenho escrito alguns patterns para algo bem similar e gostaria de ter certeza que estou roubando o máximo de idéias possíveis. Kent 23
Histórico Métodos Ágeis Anos 2000 Grande divulgação Diversos exemplos de uso 2001 Agile Manifesto Agile Alliance Últimos anos Google, Yahoo, Borland, Sega (todas as grandes empresas de jogos), MS 24
Agile Manifesto over over over over (A) Documentação compreensiva (B) Negociação contratual (C) Colaboração com o cliente (D) Seguir um plano (E) Indivíduos e interações (F) Processos e ferramentas (G) Responder a mudanças (H) Software funcionando 25
Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas 26
Principles behind the Agile Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from selforganizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 27
Alguns destaques dos princípios Ágeis Nossa maior prioridade é satisfazer o cliente através de entrega contínua e antecipada de software que agregue valor (valuable software) Receber bem as mudanças de requisitos (welcome), mesmo que sejam tardias no processo de desenvolvimento. Entregar software funcional com freqüência Pessoas motivadas Simplicidade a arte de maximizar o trabalho não feito Em intervalos regulares, o time reflete em como ser mais eficiente Conversar cara-a-cara 28
Comunicação face-a-face Comunicação Interativa Chat Wiki? 29
Video Mr. Walter Falls and A. Giles 30
Mudanças de paradigma Modelo cascata Modelo iterativo Escopo fixo Tempo fixo (qualidade fixa) Planejamento/controle Inspeção/adaptação Orientado a processo Orientado a pessoas Times multidisciplinares e auto-organizados Mudanças de requisitos são bem vindas Melhoria contínua Desenvolvimento: orientado a camadas orientado a fatias 31
Camadas x Fatias A cada ciclo de desenvolvimento (iteração) termina-se uma nova fatia e não uma camada X 32
XP extreme Programming 33
XP extreme Programming 5 Valores ~14 Princípios ~24 Práticas VALUES VALUES PRACTICES PRINCIPLES Comunicação Feedback Simplicidade Coragem Respeito 34
XP Valores (1/2) Comunicação: Compreensão do projeto Reaproveitamento de soluções Noção de time Simplicidade: Valor de maior esforço intelectual Qual a coisa mais simples que poderia funcionar? Respeito: Aos indivíduos (profissional e pessoalmente) Aos objetivos do projeto/empresa 35
XP Valores (2/2) Feedback: Essencial a um processo iterativo sujeito a mudanças Seria melhor se fosse possível acertar de primeira, mas... Pode ser impossível prever a melhor maneira O melhor hoje pode ser ruim amanhã Planejar o melhor possível pode ser tão custoso (ou demorado) que inviabilize o projeto Atenção, o feedback não pode ser maior que a capacidade de processá-lo Coragem: Coragem para jogar fora soluções ruins Coragem para quebrar paradigmas Encorajar o time Atenção, coragem sozinha pode ser bem perigoso 36
XP Princípios Alguns dos princípios: Melhoria contínua (improvement) Diversidade equipes multidisciplinares Fluxo contínuo oposto ao método cascata Falhar não ter medo de errar se isso trouxer aprendizado às vezes é a única maneira de acertar... Qualidade (robustez) não pode ser uma variável faça o melhor possível dentro do contexto Outros: Economics; Self-similarity; Baby steps; Accepted responsibility 37
XP Práticas Segundo Kent Beck: São práticas que objetivam a melhora Motivar a busca pela perfeição Divididas em dois grupos: Primárias Úteis independentemente das outras Melhoria imediata Derivadas (corolárias) ((antes ou depois do Scrum?)) 38
XP Práticas (primárias) Sentar juntos / time completo Quase sempre os problemas são peopleware Times Cross-functional (SCRUM dá mais ênfase nisto) Espaço de trabalho informativo (como SCRUM) Trabalho energizado O que é mais produtivo, 40h ou 80h semanais? Comprometimento (Slack) Evitar overcommitting Evitar underdelivering 39
XP Práticas (primárias) Story Diferente de requisito Estimativa do esforço Ciclo semanal Stories selecionadas devem acabar na sexta Psicologicamente bom terminar para sexta Deployable version ao final do ciclo Ciclo quinzenal Planejar as próximas 2 semanas Impedimentos Momento para dar atenção ao projeto como um todo 40
XP Práticas (primárias) Integração contínua / Ten-minute Build Programação é um problema de dividir para conquistar e integrar Test-first Programming (TDD) Proporciona coesão e confiança (inclusive para refactoring) Ritmo: test, code, refactor, test, code, refactor... 1:2 linhas de código para linhas de teste Design Incremental Diário (para aquele dia) Estratégia mais ecônomica: Grandes decisões no início Decisões pequenas progressivamente Diferente da teoria do Barry Boehm 1960 s Adaptação 41
Pair programming Esclarecer pequenas dúvidas de concepção Motivação mútua (+ foco, - interrupções) Padronização codificação, design, testes, comportamentos Nivela por cima Aprendizado (inclusive de detalhes), cross-training Aprimoração de quem ensina Maior compreensão coletiva da solução ((cross-functional)) Redução de bugs (um é debugger do outro) (escalas ) Laurie Williams, "Pair Programming Illuminated", 2003 15% menos bug, 15% mais lento Atenção: trocar pares, variando (experiente-inexperiente; exp-exp; inexp-inexp) cuidado com a invasão de espaço (cultural: bubble space) Não faz sentindo para trabalhos braçais Dicas: Ping-pong programming (test and code) No Scrum, acontece naturalmente, mas deve ser induzido 42
XP Práticas (Corollary) Envolvimento do cliente No Scrum é um pouco diferente Deployment incremental (e diário) Como alternativa às super-releases Continuidade do time Evitar desmembrar o time Redução do time (Shrinking Teams) Toyota Production System Tentar deixar todo mundo ocupado pode ocultar o fato do time estar com folga nos seus recursos Análise de causa raiz Bug Teste Correção Entender motivo Ação Five Whys (5 porquês) Quase sempre o problema é de pessoal Código compartilhado / Base única de código Codificação e teste (não documentação) 43
Terminologia SCRUM Sprint Done Product Backlog Selected Backlog Visibility Story Points Sprint Backlog Stand-up Meeting Retrospectives Burn-down Chart Task Board Product Owner Planning POKER Scrum Master Time Box Team 44
SCRUM 45
Scrum Metaprocesso (framework) Metodologia que diz que metodologias não são tão importantes Adaptável 1ª regra: as regras podem ser alteradas* Promete alta qualidade Software robusto Promete alta produtividade 4 a 10 vezes mais produtivo Mais business value ou valor agregado * Existem algumas pré-condições 46
Scrum Vamos ver: Primeiros conceitos Personagens Artefatos Meetings (cerimônias) Diferença entre estratégia e tática: 47
Planejamento Iceberg Tarefas Stories Épicos t 48
Scrum Primeiros Conceitos Sprint: Iteração (i, i+1, i+2,...) Período de 2 a 4 semanas de trabalho da equipe Sprint diário: 1 dia de trabalho da equipe Product backlog: Lista de requisitos em formato user-story Ordenada por prioridade Selected backlog: Lista de stories a serem realizadas durante a sprint Baseada nas maiores prioridades do product backlog De acordo com a capacidade da equipe em uma sprint 49
Scrum 50
Scrum - Personagens 51
Scrum - Personagens Apenas três Não têm relação direta com cargos e hierarquias Product Owner Time Scrum Master 52
Scrum - Personagens Product Owner Fornece a visão do negócio Mantém os itens do product backlog atualizados e priorizados A cada início de sprint participa da elaboração do selected backlog Maximiza ROI ("valor agregado") Aceita ou rejeita o que foi produzido Alta participação em início e fim de sprints Disponível para esclarecer dúvidas 53
Scrum - Personagens Scrum Master Facilitador Não tem autoridade (lidera) Conduz reuniões e eventos Mantém o Scrum funcionando Remove empecilhos e obstáculos Presta serviço ao time Protege o time Ajuda o time nas suas tarefas Ajuda o product owner nas suas tarefas De olho na próxima sprint 54
Scrum - Personagens Time Multidisciplinar sem papéis específicos Auto-gerenciado De 5 a 9 pessoas Comprometido com o objetivo e consigo mesmo esforçado, pontual, focado etc. Autoridade para fazer o que for necessário para atingir o objetivo Comunicação constante transparência e diálogo 55
56
57
Scrum - Comprometimento Comprometimento x Envolvimento Porcos e galinhas - Porco, estava pensando que poderíamos abrir um restaurante juntos. E qual seria o nome? Que tal Presunto com ovos? Então não, porque eu estaria comprometido e você apenas envolvido! Às vezes somos porcos, às vezes galinhas 58
Scrum - Artefatos 59
Scrum Artefatos User Story (backlog items) User stories são os itens do Product e Selected Backlogs. Campos: ID, Título (ou descrição sucinta) Valor Valor medido pelo product owner (business value) e / ou valores relativos sem significado absoluto (apenas para priorizar) Story points Esforço medido pelo time Descrição mais detalhada Suficiente para compreensão de time Pode conter uma descrição da interação com o usuário ou uma prévia da lista de tarefas ou... Me <name>, as <user role>, would like to <feature>, so that <value> Teste de aceitação Outros possíveis campos: Número da sprint de realização Roteiro de demonstração INVEST 60
Scrum Artefatos Exemplo de Selected Backlog Siviep (Excel) 61
Scrum Artefatos Story Points Medida de esforço de implementação Associado a cada story Valores concretos ou relativos? Pode ser associado a uma referência concreta ex: Homem-dia de trabalho Pode ser simplesmente um valor relativo Ex: Escolhe-se a story mais simples e pontua com valor 2 Usa-se uma série adaptada de Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40 e 100 Medida para determinar a Velocidade da equipe 62
Por que usar pontos (e não tempo)? Foco em estimativa relativa Foco em tamanho/esforço e não duração Usar Homem-dia sempre leva a um fator de ajuste Performances individuais diferentes Com HDia a aceleração da equipe pode ficar mascarada Tarefas similares tendem a diminuir HDia com o tempo Ao entrar mais um membro na equipe: Em pontos, é esperado uma queda de produtividade do time Com HDia há um aumento irreal de produtividade Obs: 3 sprints para estabilizar a velocidade da equipe Cria-se uma noção intuitiva de pontos Evita pressão externa sobre as estimativas Síndrome do estudante e lei de Parkinson Mas pode atrapalhar ao juntar grupos diferentes A aritmética é fácil (comparada a horas e minutos) http://visaoagil.wordpress.com/2008/12/08/por-que-usar-story-points/ 63
Scrum Artefatos Tarefas Cada story deverá ser quebrada em tarefas São a menor unidade de divisão Idealmente, tarefas correspondem a no máximo 1 dia de trabalho Cada tarefa vira um Post-it As atribuições das tarefas às pessoas ocorre diariamente Sprint Backlog Conjunto de tarefas de cada uma das stories da sprint atual 64
Scrum Artefatos Task Board 65
Scrum Artefatos Task Board To do, doing, done Conceito de DONE Pode ter outras colunas, exemplos: Commited Reviewed Burn-down chart Outros conteúdos: Post-it chart Limbo Impediments Notícias Mesa retrátil 66
Scrum Artefatos Burn-down Chart São dois: Por sprint Produto completo / Release Contagem de pontos Pontos parciais das stories Total de pontos da story Video Sw House paulista (BlueSoft): http://bluesoft.wordpress.com/2008/09/17/como-montamos-oquadro-do-scrum/ Outro (Sovis): http://www.youtube.com/v/apqwn9is--o&hl=pt-br&fs=1 67
Scrum Artefatos Burn-down Chart da release ou do produto: Normalmente segue um padrão Tem que pontuar tudo no Prod. Backlog Mais stories novas do que realizadas Stories removidas Burn-up Chart Linha de escopo e linha de realizado Desacopla I/O de stories da realização Funciona em projetos sem prazo fixo Ex: manutenção, desenvolvimento interno 68
Scrum Artefatos Burn-up Chart da release ou do produto: Previsão de término: Projetar horizontalmente a linha do escopo Projetar linha de realização segundo histórico Data de fim provável no cruzamento Projeção da linha de realização: Média geral, média das 3 últimas sprints, médias sem extremos, média exceto as 3 primeiras, etc... (vide Mike Cohn) Projetos sem prazo fixo: A distância entre as linhas indica o horizonte do product backlog 69
Scrum Artefatos - O projeto está indo ladeira abaixo!!! - Não foi isso o que eu quis dizer sobre burn-down correction! 70
Scrum Artefatos Quebrando Stories: Diferença entre stories e tarefas: Story: sempre agrega algum valor Tarefa: atividade sem importância ao PO Propriedades das stories: I N V E S T Independente Negociável Valorável Estimável Small (pequena) Testável 71
Scrum - Meetings 72
Scrum - Meetings São 6 diferentes meetings MEETINGS... Daily meetings Daily meetings Sprint i Sprint i +1 Estimation (planning poker) Review Retrospective... Estimation (planning poker) Sprint Planning 2 Sprint Planning 1 Obs: São permitidos observadores externos (mas galinhas não tem voz). Exceção: Retrospective (existe exceção da exceção) 73
Scrum - Meetings Planning Poker ou Estimation meeting Envolvidos: time (+ product owner) Material: cartas do planning poker com os valores: 0 ½ 1 2 3 5 8 13 20 40 100 200 Freqüência: poucas vezes ao longo da sprint inevitavelmente junto com a sprint planning 1 74
Scrum Meetings: Planning Poker Procedimento (exemplo): 1. Identificar no product backlog o item que o time julga ser o de menor esforço e determinar como 2 pontos. Para cada item (ou story): 2. 3. 4. Verificamos se a story está bem compreendida por todos. Fazemos uma rodada de PP entre os membros do time. Os membros que tiverem dado menor e maior valores fazem uma breve defesa do porquê. Repetimos itens 3 e 4 até convergir Obs: Por que Fibonacci? 75
Pontuação:C omplexidade E s forço Incerteza Story 1 Story 2 13 C omplexidade E s forço E s forço Incerteza C omplexidade C omplexidade E s forço Incerteza 5 Story 3 5 Incerteza http://event.on24.com/event/15/97/99/rt/1/documents/slidepdf/releaseplanningwebinar_wnotes.pdf 76
Scrum - Meetings Sprint Planning 1 Material: Product backlog atualizado, priorizado e estimado Informações práticas sobre próxima sprint pessoas, tempo de sprint, etc Product owner + time + scrum master Objetivo: definir selected backlog e sprint goal Quando: todo início de sprint 77
Scrum - Meetings Sprint Planning 1 Procedimento: Selected backlog é preenchido com os itens de maior prioridade do product backlog até completar o número de story points correspondente à velocidade do time. O product owner poderá então propor alterações para incluir, excluir e alterar o escopo das stories. Sprint goal: frase curta com o objetivo da sprint. Serve para uniformizar a escolha das stories. http://visaoagil.wordpress.com/2009/02/20/negociando-o-sprint-goal/ 78
Scrum - Meetings Sprint Planning 2 Material: Selected backlog priorizado Time + scrum master Objetivo: (+ product owner) Definir tarefas de cada story da sprint (criar post-it) Quando: todo início de sprint 79
Scrum - Meetings Sprint Planning 2 Procedimento: Divisão das stories em tarefas de 1 dia, criando postits para a coluna to do (painel de tarefas). Lembrar que as tarefas devem incluir: Redesign (arquitetura) Aprendizado de tecnologia desconhecida Codificação Teste Code review Done! Documentação Infra 80
Scrum - Meetings Daily meetings ou Stand-up meetings ou Scrum meetings Participantes: time (+SM) Material: Painel de tarefas; post-it; canetas Freqüência: diária Objetivo: Comunicar progresso (status diário) Identificar obstáculos Manter foco Noção de time Comprometimento individual 81
Scrum - Meetings Stand-up meetings Procedimento: De pé, máximo de 15 minutos, não é para discutir problemas 3 perguntas atualizando o Task Board: O que eu fiz ontem? O que vou fazer hoje? Tenho algum obstáculo? 1 2 3 Sincronização de conhecimento Atualização do burn-down SM deve observar as mensagens indiretas Pode-se propor uma penalidade para os atrasados às reuniões Não é para discutir problemas técnicos http://martinfowler.com/articles/itsnotjuststandingup.html 82
Scrum - Meetings w e i v Re Review Burn Down Material: Informações do painel de tarefas + SW Participantes: Product owner + scrum master + time Objetivo: Revisar último sprint e andamento global do projeto Freqüência: A cada fim de sprint 83
Scrum - Meetings w e i v Re Burn Down Review Procedimento: Revisar detalhes da última sprint: objetivo, stories, burndown chart etc. Demo do último incremento do projeto. Pode incluir a demonstração de documentos e outros. w e i v Re clap clap clap 84
Scrum - Meetings Retrospective Material: Informações do painel de tarefas já organizados. Post-its e flip-chart Ambiente seguro Participantes: Time, scrum master Objetivo: Rediscutir o processo de desenvolvimento (visando a sua melhora) MELHORIA CONTÍNUA Freqüência: a cada fim de sprint 85
Scrum - Meetings Retrospective Procedimento: Repassar a sprint cronologicamente 5 min de WWWs em post-it What Went Well? (o que aconteceu de bom?) What Went Wrong? (e de ruim? What can be improved? ) Discutir os itens organizando um impediment backlog Quem é responsável por cada item? Quase sempre o SM Lista de compromissos assumidos pela equipe Hansei / Kaizen Fechamento http://visaoagil.wordpress.com/2009/01/06/melhoria-continua-e-efetiva-atraves-do-hansei-e-kaizen 86
Scrum - Meetings Retrospective Minha experiência: PPT para conduzir reunião Começando por: Independente do que será discutido, nós entendemos e acreditamos que todos fizeram o seu melhor, dado o que sabiam naquele momento, suas habilidades e competências, os recursos disponíveis e as circunstâncias da situação (*) Ou seja, vamos evitar acusações: no names Slide com resumo da sprint (goal, stories, pontos, burn-down) WWWs Levantamento das infos práticas para a próxima sprint (pessoas ) (*) Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. 87
Scrum - Meetings Nas 4 reuniões maiores: Planning 1 Planning 2 Retrospective Review não se esqueçam que é bom um lanchinho 88
Scrum Flow +Review 89
Etapas SCRUM Meetings Daily meetings 1 day 1 day Sprint i... Planning Poker Review Retrospective Adaptações SIVIEP Meetings Daily meetings Sprint i 1 day Daily meetings Sprint i +1 Planning Poker Review Retrospective Planning 2 Planning 1 Daily meetings Sprint i +1... Planning Poker Sprint Planning 2 Sprint Planning 1 Pontos positivos: Participação do Prod. Owner em 1 único dia Apenas 1 dia sem produção Pode-se preparar a review com o time Pode-se discutir impedimentos Apresentar melhorias do processo Ponto negativo: Retrospective sem informações da review
Jogo das bolas Um único time As bolas devem passar por todos Bolas devem ser passadas ficando um tempo no ar Não podem ser passadas ao vizinho lateral Mesmo ponto de início e fim 90 segundos por sprint Mais próximo possível de Bug-free 1 minuto para retrospectiva/review 4 iterações Você tem certeza que é isso que ele quis dizer sobre a nossa velocidade máxima? 10 30 50 70 90 20 40 60 80 0 1 2 3 4 5 91
Dinâmica Quem faz o que Quais são os três personagens do Scrum? SM, PO, time Quem é? 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Responsável por proteger o time: Responsável pelo design: Atribuidor de tarefas: Participa como galinha na sprint-planning 2: Não deve estar na retrospectiva: Responsável por manter Scrum funcionando: Responsável pelo Product Backlog: Atribui pontos às stories (planning poker): Aceita ou rejeita o que foi produzido: Participam do stand-up meeting: 92
Scrum - Princípios 93
Scrum - Princípios Processo iterativo e incremental (1/6) Modelo Tradicional NA TEORIA NA PRÁTICA Modelo Ágil 94
Scrum - Princípios Processo iterativo e incremental (1/6) Benefícios: Confiabilidade do software Aumento de confiança do cliente Motivação do time Melhoria contínua Antecipação de valor agregado Manifesto Ágil: devemos valorizar mais SOFTWARE FUNCIONAIS do que documentações extensas. 95
Scrum - Princípios Auto-organização (2/6) Acreditar na competência das pessoas O time tem capacidade de se autoorganizar Tarefas não devem ser atribuídas autoritariamente, mas voluntariamente pull tasks, not push atribuições ocorrem diariamente Manifesto Ágil: devemos valorizar mais INDIVÍDUOS e INTERAÇÕES que processos e ferramentas 96
Scrum - Princípios Exemplo de auto-atribuição de tarefas... - Eu auto-seleciono o porco para ir - Você não pode auto-selecionar outra pessoa, repare o auto na sua frase - Ok, então eu me auto-seleciono o ser supremo e seleciono vocês como escravos para irem 97
Scrum - Princípios Comunicação (transparência) (3/6) Através de reuniões diárias a comunicação é feita pessoalmente Controles visuais Reuniões regulares de retrospectiva A cada mudança de sprint Verificação de obstáculos Melhora contínua Problemas vêm rapidamente à superfície Group programming (collective code ownership) Resultado das atribuições diárias e Equipes cross-functional (especialista-generalista) Evitar 65% de Funcionalidade não utilizadas Motivação/Confiança do Product Owner 98
Scrum - Princípios Time-box (4/6) O tempo da sprint é mandatório (assim como qualidade) Qualidade Todos os meetings têm tempo fixo: Único que pode alterar Fixos custo/esforço Tempo Escopo Daily-meeting Sprint Planning Etc... 99
Scrum - Princípios Menos planejamento, mais ação (5/6) Retardar decisões Por causa da complexidade Não há conflito com: Não deixe para amanhã o que pode ser feito hoje" Um é ação e outro é planejamento Retardar uma decisão e retomá-la apenas no momento apropriado: Cenário mais atualizado Novas prioridades Mais conhecimento sobre as condições Último momento responsável (Last responsible moment) Manifesto Ágil: devemos valorizar mais REAGIR A MUDANÇAS do que seguir um plano. 100
Scrum - Princípios Menos planejamento, mais ação (5/6) Planejamento Iceberg Escala progressiva Detalhes do planejamento devem ser inversamente proporcionais à distância no tempo Scrum tem 3 escalas: projeto/release, sprint, dia Não discutir muito o processo: Tentar primeiro e melhorar para a próxima sprint 101
Scrum - Princípios Cliente é um parceiro (6/6) Participação ao longo do projeto Acompanhamento mensal Disponibilidade para dúvidas Mudanças de requisitos são bem-vindas a qualquer momento Manifesto Ágil: devemos valorizar mais COLABORAÇÃO COM O CLIENTE do que negociação contratual. 102
Scrum - Princípios Observação, os 6 princípios descritos aqui foram minha interpretação pessoal Existem 5 valores do Scrum (by Ken) (não tão divulgados como XP) Foco Abertura ((de espírito)) Comprometimento Respeito Coragem 103
Ainda sobre SCRUM Sprint, um resumo Done, Velocidade Infraestrutura Escalabilidade Aprendizado Exemplo Prático 104
Scrum - Sprint Sprint, um resumo Iteração de 2 a 4 semanas Termina com uma deployable version Não pode ter sua data postergada O que fazer se o time atrasar? O que fazer se o time se adiantar? O que fazer com stories parcialmente feitas? A descrição da sprint deve conter: Data de início e fim Pessoas comprometidas (time) Objetivo Total de pontos Selected backlog Botão Vermelho 105
Scrum - DONE Design Codificação Teste unitário Revisão de código Refactoring Comentado Comitado (integração, testes ) Documentado Deve estar bem acordado com o time 106
Scrum - DONE Entrando em acordo sobre done - Este projeto é meu e não está pronto (done) enquanto eu não estiver pronto - Agora podemos dizer que a galinha está pronta Jeff Sutherland Done Done, done Done, done, done 107
Scrum Suporte Tecnológico Integração Contínua Hudson (outras: CruiseControl, Bamboo, Continuum) C++: Scons Cmake Wiki (Visibilidade) Confluence, MediaWiki, TWiki Versionamento TortoiseSVN, Subversion, ClearCase, GIT Teste Unitário J-Unit, Cpp-Unit, NUnit, DBunit, MStest, Google test Revisão automática de código (padrões, otimização, etc...) Together, Codelogic, Findbugs, Fortify, Checkstyle/PMD Acompanhamento de issues Jira, Mantis, Trac, Bugzila, Assembla Scrum Tools TinyPM, ScrumFire, TargetProcess, Mingle, VersionOne, SylverCatalist http://www.implementingscrum.com/2007/03/05/crack-cocaine-first-scrum-is-free/ 108
Sistema Siviep 109
110