Scrum - Desenvolvimento Ágil

Scrum – Desenvolvimento Ágil

Problemas Manifesto Ágil Origens do Scrum O que é o Scrum Processo do Scrum Resultados

PROBLEMAS Com desenvolvimento tradicional de software

Resultado dos projetos (2004): CHAOS Report 18% 29% 53% com problemas sucesso falham

CHAOS Report 1994 2004 Projetos não concluídos ------------ 31% Proj etos bem sucedidos ----- 16% Estouro médio de custo ------------> 180% Estouro médio de prazo ------------ 164% Proje tos não concluídos ------- 18% Projetos bem sucedidos ----------- 29% Estouro méd io de custo ------ 56% Estouro médio de prazo -------- 84%

Qual software? 64% Funcionalidades nunca ou raramente utilizadas Jim Johnson, 2000

O que aprendemos ? Jim Johnson Chairman of Standish Group 5 Principais razões para o sucesso Envolvimento do usuário Suporte da gerência executiva Objetivos de negócios claros Escopo otimizado Métodos ágeis Sources: http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS ” My Life is Failure”, Jim Johnson’s book “ Fazer projetos com processos iterativos , em oposição ao método waterfall (cascata), que prega que todos os requisitos precisam ser definidos primeiro, foi um grande passo a frente.” “ Não há bala de prata, mas os métodos ágeis chegam muito perto"

O Manifesto Ágil www.agilemanifesto.org “ Nós estamos descobrindo novas maneiras de desenvolver software fazendo e ajudando outros a fazê-lo Feb 11-13, 2001 Snowbird ski resort, Utah 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

O Manifesto Ágil “ Nós estamos descobrindo novas maneiras de desenvolver software fazendo e ajudando outros a fazê-lo. Através deste trabalho nós valorizamos: Indivíduos e interações mais que processos e ferramentas Software funcionando mais que documentação compreensiva Colaboração do cliente mais que negociação de contrato Responder à mudança mais que seguir um plano Isto é, muito embora valorizemos os itens da direita, valorizamos mais os da esquerda!”

O Manifesto Ágil “ Nós estamos descobrindo novas maneiras de desenvolver software fazendo e ajudando outros a fazê-lo. Através deste trabalho nós valorizamos: Indivíduos e interações mais que processos e ferramentas Software funcionando mais que documentação compreensiva Colaboração do cliente mais que negociação de contrato Responder à mudança mais que seguir um plano Isto é, muito embora valorizemos os itens da direita, valorizamos mais os da esquerda!” Note que o manifesto prega mudança de ênfase - e não ruptura...

O Manifesto Ágil Além dos quatro valores, os seus doze princípios serão discutidos ao final do curso (melhor compreendidos com a prática): A mais alta prioridade é a satisfação do cliente através da liberação mais rápida e contínua de software de valor! Receba bem as mudanças de requerimentos, mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente. Libere software com a freqüência de um par de semanas até um par de meses, com preferência para a escala de tempo mais curta. Mantenha as pessoas dos negócios e os desenvolvedores trabalhando juntos a maior parte do tempo do projeto. Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado. O método mais eficiente e efetivo de repassar informação entre uma equipe de desenvolvimento é através de conversação cara-a-cara.

O Manifesto Ágil Além dos quatro valores, os seus doze princípios serão discutidos ao final do curso (melhor compreendidos com a prática): Software funcionando é a principal medida de progresso. Processos ágeis promovem desenvolvimento sustentado. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente. A atenção contínua para a excelência técnica e um bom projeto aprimora a agilidade. Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial. As melhores arquiteturas, requerimentos e projetos emergem de equipes auto-organizadas. Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento de acordo.

Origem do Scrum Desenvolvimento iterativo e incremental Jeff Sutherland, PhD Ken Schwaber SCRUM XP Smalltalk Engineering Tools

Origem do Scrum Dr. Jeff Sutherland é um dos inventores do Scrum. Juntamente com Ken Schwaber, ele criou o Scrum como um processo de desenvolvimento de software foram no OOPSLA'95. Desde então, juntos eles têem extendido e aprimorado o Scrum em muitas empresas e organizações de TI. Jeff é um Graduado Distinto da U.S. Military Academy, com extensões diversas pela Stanford University e Ph.D pela University of Colorado School of Medicine. Ele é atualmente o CTO (Chief Technical Officer) da empresa PatientKeeper, Inc in Newton, MA.

Ken Schwaber , além de ser um dos criadores do Scrum, é fundador da Agile Alliance e da Scrum Alliance, além de signatário do Manifesto Ágil. Ken desenvolve software há mais de 30 anos, tendo trabalhado formatando MDS para grandes empresas tais como IBM, desde a década de 80. Atualmente,promove ativamente processos ágeis de desenvolvimento de software por todo o mundo, como consultor. Origem do Scrum

O que é o Scrum ? Framework de Gerenciamento e Controle Empírico Ciclos de Feedback para "Inspeção e Adaptação" Usado para Gerenciar Projetos Complexos de Software desde 1990 Libera funcionalidade a cada 30 dias (2 a 4 semanas) Escalável para projetos longos, grandes e distribuídos Compatível com ISO 9001 e CMMI-3 (MPS.BR C!) Bastante Simples de Entender, mas Difícil de Aplicar

Termo Scrum O Scrum é uma jogada do Rugby que envolve oito jogadores de cada time, onde eles se "encaixam", para se tornar uma muralha. O grande ponto dessa jogada é a vital importância do trabalho em equipe. Se um membro falhar na formação, já era, o outro time se sobressai.

Algumas empresas que estão utilizando:

O processo do Scrum O Scrum define um framework de processo leve para gerenciamento de projetos segundo os valores e princípios ágeis.

O processo do Scrum Plano Inicial Leve (Visionário) Requisitos Priorizados e Detalhados com Paretto (mais importantes com maior precisão) Planejamento Mensal com Seleção dos Requisitos Prioritários Estimativa e Planejamento de Atividades pelo Time Iteração de Entrega de 30 dias (Sprint) Iteração de Acompanhamento Diária (Daily Scrum - 15 minutos) Liberação Parcial de Software Útil

Entendendo o Scrum – Papéis

Product Owner Product Owner É um especialista do negócio, representante de todos os Stackholders Estabelece e comunica a visão do produto Administra fundos para o projeto Cria o Release Plan e Product Backlog Iniciais Monitora o projeto contra suas metas de ROI Atualiza e prioriza continuamente o Product Backlog (Planning) para assegurar que as funcionalidades mais valiosas serão produzidas primeiro Responde e apoia o Scrum Team para sanear dúvidas sobre os requisitos Está disponível sempre que o Scrum Team necessita de informações do negócio Decide quando serão liberadas as versões oficiais do produto Pode ser entendido como o "Gerente do Produto", assumindo parcela das atividades habituais do Gerente de Projetos tradicional

Scrum Master Scrum Master É responsável por liderar o time ao sucesso, removendo obstáculos ao seu progresso (Impedimentos), evitando interrupções externas, garantindo a execução da reunião de Daily Scrum e tudo o mais que se fizer necessário É o guardião do processo, assegurando que as práticas do Scrum sejam utilizadas com a disciplina necessária Assegura que o projeto e a cultura organizacional estejam ajustados para que as metas (Goal) e o ROI desejados sejam alcançados, a cada Sprint Organiza as reuniões de Sprint Planning 1 e Sprint Planning 2, Sprint Review e Retrospective Meeting Responde pelo Scrum Team perante o Product Owner, Stackholders e Management (alta direção) Faz um papel de gerenciamento tipo "Coach", atuando ao lado dos membros do Scrum Team para treiná-los em situações de adaptação constante. Acompanha o progresso do trabalho diariamente, inspecionando a evolução das implementações Pode ser entendido como o "Gerente de Desenvolvimento", assumindo parcela das atividades habituais de um Gerente de Projetos tradicional

Scrum Team Scrum Team É um time multi-funcional que reúne todas as especializações necessárias para implementar segmentos completos do software, a cada Sprint Estima o esforço necessário para implementar os itens de Product Backlog selecionados para o próximo Sprint (Select Backlog) Expande cada item de Selected Backlog ("requisito") em itens de Sprint Backlog ("atividades") e baseado nelas gerencia seu próprio trabalho diariamente, até completar a iteração (Sprint). Realiza a reunião diária de Daily Scrum para garantir comunicação plena do time e sincronismo de tarefas, conferindo os Selected Backlogs realizados e atualizando o Agile Radiator e o Burndown Chart. Identifica impedimentos (itens que impedem o progresso pleno) e reporta ao Scrum Master Desenvolve de forma iterativa, realizando projeto, codificação, testes de unidade, de aceitação e até documentação (JIT), para cada Selected Backlog, antes de passar para o próximo. Desenvolve os itens de Selected Backlog rigorosamente em sistema de pilha (LSD -"pull"), do mais importante (>ROI) para o menos importante, reforçando diariamente a formação para que cada um seja capaz de fazer qualquer item da pilha (multi-aprendizado). Pode lançar mão de quaisquer recursos disponíveis para se adaptarem a circunstancias não previstas, com a finalidade de atingirem a meta de cada Sprint (Sprint Goal) e maximizarem o ROI.

Stackholders (partes interessadas) Stackholders São todos os interessados no software em desenvolvimento, a começar por clientes (contratantes), usuários finais, equipe de marketing e vendas, Scrum Team, Scrum Master, Management e outros. São representados pelo Product Owner, que deve conhecer o interesse e coletar idéias de todos para constituir o Product Backlog e priorizá-los constantemente. Idealmente, devem poder consultar o Product Backlog pora manterem-se atualizados sobre o progresso do software e aprimorar suas sugestões.

Management Management Corresponde ao grupo diretor, que provê fundos para o projeto ou responsável em última instância Não é um papel formal do Scrum básico, mas é citado em situações de crise ou na fundamentação do projeto (Pre-Game)

Durante um Sprint, o Scrum Team está comprometido com a construção e liberação de software útil, que atenda ao Sprint Goal. Todos os demais estão apenas envolvidos . Portanto, durante um Sprint o Scrum Team é "porco" e todos os demais são "galinha" Esta metáfora valoriza quem efetivamente "faz" o trabalho, evidenciando a necessidade de evitar interrupções externas durante um Sprint Porcos e Galinhas

Entendendo o Scrum – Cerimônias

Entendendo o Scrum – Cerimônias Sprint Planning 1 Realizada todo início de Sprint , com duração de 4 (quatro) horas Participação do Product Owner (PO), Scrum Master(SM) e Scrum Team (Stackholders convidados como "galinha"). Passagem de entendimento sobre o Selected Backlog "pré-selecionado", do PO para o Scrum Team O Scrum Team realiza a estimativa inicial de tamanho, para o Selected Backlog O PO estabelece o Sprint Goal (meta "visionária" do Sprint) Sprint Planning 2 Realizada após o Sprint Planning 1, com duração de 4 (quatro) horas, sem a participação do PO e Stackholders Planejamento do Scrum Team para seu próprio trabalho: ele refina a análise do Selected Backlog, criando a lista de Sprint Backlog O time finaliza a estimativa iniciada no SP1, reportando ao PO o resultado para confirmação ou pequenos ajustes

Entendendo o Scrum – Cerimônias Daily Scrum Realizada diariamente, no início ou no final do dia. Duração de 15 minutos Participação do Scrum Team e Scrum Master (Stackholders convidados como "galinha") 3 perguntas: "O que você fez hoje?", "O que o atrapalhou?" e "O que você fará amanhã?" Atualização do Agile Raditor (movimentação do Sprint e Selected Backlog e atualização do Agile Radiator) Sprint Review Realizada após cada Sprint, com duração de 4 (quatro) horas e participação do PO (Stackholders convidados como "galinha") O Scrum Team demonstra o trabalho realizado no Sprint e é avaliado pelo PO com relação ao Sprint Goal e ROI produzido. A demonstração deve ser "de produto funcionando" e comprovar que os itens de Selected Backlogs prioritários foram realizados com objetivo de maximizar o ROI. Retrospective Meeting Realizada após o Sprint Review, com duração de 1-2 horas, com a participação de todos Alinhamento (Timeline) em grupo 2 perguntas: "O que foi bem?" (WWW-What Went Well?) e "O que pode ser melhorado? (WCBI - What Can Be Improved?). Separação de responsabilidades pelo WCBI e exibição no Agile Radiator

Sprint Goal O Sprint Goal é um objetivo "visionário" no escopo do Sprint, para orientar a adaptação do time, reforçando seu norte estratégico É um parágrafo, preferencialmente de uma frase, estabelecido pelo Product Owner ao final do Sprint Planning 1 É sempre verificado no Sprint Review, confrontado com a demonstração do Scrum Team Suportar funcionalidades necessárias para estudos genéticos Fazer a aplicação funcionar em MS SQL Server além do Oracle Funcionalidades que provam o conceito do que foi liberado pelos arquitetos

Entendendo o Scrum – Artefatos Product Backlog Pilha de requisitos contendo demandas de todos os Stackholders, preferencialmente descrita em linguagem do usuário (User Stories). Mantida pelo Product Owner, que deve acatar todas as idéias e reclamações que façam sentido para o produto, por parte de qualquer Stackholder Deve estar ordenada do mais importante (topo da pilha) para o menos, com base em seu valor para o negócio da empresa, estipulado pelo PO em "Business Value" (BV) É atualizada continuamente, devendo os itens de Product Backlog estarem tão mais detalhados quanto mais prioritários estiverem na lista (20-60-20)\ Obs.: Para o Sprint Planning, é incumbência do PO chegar com os principais itens da pilha apropriadamente detalhados Selected Backlog Trata-se apenas de um nome distinto para uma seleção de itens de Product Backlog feita para um Sprint. Não consiste em uma nova pilha! Sprint Backlog Pilha de tarefas (atividades), definida pelo time e para o time, contendo detalhamento em 2-3 itens de Sprint Backlog, do que deve ser feito em um Sprint para cada item de Selected Backlog. É utilizada para o Sprint Burndow Chart e não deve ser utilizada para gerenciamento externo (realizado por resultados)

Entendendo o Scrum – Artefatos Impediment Backlog Pilha de impedimentos, sendo estes quaisquer eventos que impeçam o progresso do Scrum Team Ordenado por criticidade, com os itens que bloqueiam o trabalho no topo da pilha Mantido pelo Scrum Master, responsável por agir e remover cada impedimento dentro de uma meta da 24 horas O SM pode, para remover impedimentos, pedir auxílio ao PO e/ou levar o problema ao gerenciamento (Management) da empresa. Retrospective Itens Lista de WWW e WCBI, separadas por responsabilidade, podendo ser "organizacional" ou "time" O PO é responsável por agir para a lista organizacional e o Scrum Team pela lista "time". Sprint Burndown Gráfico de "trabalho restante" dentro de um Sprint, baseado na pilha de Sprint Backlog. É atualizado diariamente após o Dailly Scrum, pelo Scrum Master, para refletir o progresso do Scrum Team naquele dia.

Entendendo o Scrum – Artefatos Release Burndown Em um projeto Scrum, o time acompanha o progresso comparado ao planejamento da Release, atualizando um Release Burndown Chart (gráfico) ao final de cada Sprint. O eixo horizontal representa os Sprints; o eixo vertical apresenta o total de trabalho restante no início de cada Sprint. Agile Radiator T ambém conhecido como ‘Big Visible Charts’, são bastante úteis simplesmente porque eles oferecem uma maneira eficaz de comunicar o status do projeto, questões, ou métricas, sem um grande esforço da equipe. ‘Gestão a Vista’.

Término Anormal de Sprint Sprints podem ser canceladas antes que o prazo das Sprint tenha acabado. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possa faz ê -lo sob influencia das partes interessadas, do Time ou do ScrumMaster. Se o Sprint termina de forma anormal, o próximo passo é conduzir um novo Retrospective Meeting, onde a razão do término anormal é revista, e um Sprint Planning subsequente.

Por que o Scrum funciona “ Controle inteligente aparece como descontrole ou liberdade. E por esta razão é genuinamente controle inteligente. Controle burro aparece como dominação externa. E por esta razão é genuinamente um controle burro. Controle inteligente exerce influência sem parecer fazê-lo. Controle burro tenta influenciar fazendo uma demonstração de força.” Lao Tzu. Livro de Ética

Por que o Scrum funciona Fortemente Iterativo

Objetivos SMART S pecific (Específicos) M easurable (Mensuráveis) A achivable (Alcançáveis) R ealistic (Realísticos) T imed (Com Prazo Definido) Por que o Scrum funciona

Ciclo de Deming P lan (Planeje) D o (Execute) C ontrol (Controle) A djust (Ajuste) Processo "Enxuto" (Lean) “ W. Edwards Deming ensinou que a qualidade é conformidade ao processo em vez de conformidade à especificação” David J. Anderson Por que o Scrum funciona Sprint Planning Atividades do time Sprint review e daily scruns Retrospective meeting

Peopleware e Sustentabilidade O Scrum fortalece as pessoas contra: A Tirania do modelo "Cascata" A Ilusão do "Comando e Controle" A Era da Opacidade Por que o Scrum funciona

Resultados Referência: Pesquisa realizada pela InfoQ.com com 642 empresas Fator Melhorou Não mudou Piorou Produtividade 82% 13% 5% Qualidade 77% 14% 9% Satisfação 78% 15% 7% Custo 37% 40% 23%

O Scrum não falha... Será ? A maioria dos projetos liberam software a cada 6 ou 8 meses . O Scrum reduz isto para 1 mês para aumentar o controle via inspeção e adaptação. Isso coloca stress no time e na organização, expondo seus problemas e limitações Algumas vezes as pessoas ou empresas não querem encarar o que é exposto Não "mate o mensageiro": o Scrum é somente um framework de processos - ele não falha!

Referências Agile Manifesto, Manifesto for Agile Software Development, 2001. Disponível em http://agilemanifesto.org/ [Novembro, 2005]. ANDERSON, D. J., Agile Management for Software Engineering, Applying the Theory of Constraints for Business Results, Prentice Hall, 2003. BOEHM, B., A View of 20th and 21st Century Software Engineering, ICSE 2006. BOEHM, B. and Turner, R., Balancing Agility and Discipline A Guide for the Perplexed, AddisonWesley, 2003. COHN, Mike, Agile Estimating and Planning, Prentice Hall, 2006, 330 p. HIGHSMITH, J., Agile Project Management, Creating innovative products, AddisonWesley, 2004. KNIBERG, Henrik., Scrum and XP from the Trenches, How we do Scrum, Nov., 2006, 90 p. MOUNTAIN Goat Software, The Scrum Development Process, Disponível em http://www.mountaingoatsoftware.com/Scrum [Junho, 2006]. SCHWABER, K., and Beedle, M., Agile Software Development With Scrum, Prentice Hall, 2002. SCHWABER K., Agile Project Management With Scrum, Microsoft, 2004.

Scrum - Desenvolvimento Ágil

Mais conteúdo relacionado

Mais procurados (20)

Destaque (20)

Semelhante a Scrum - Desenvolvimento Ágil (20)

Último (19)

Scrum - Desenvolvimento Ágil

Notas do Editor