Scrum - Desenvolvimento Ágil

55
1 Scrum – Desenvolvimento Scrum – Desenvolvimento Ágil Ágil

description

Desenvolvimento Ágil com Scrum

Transcript of Scrum - Desenvolvimento Ágil

Page 1: Scrum - Desenvolvimento Ágil

1

Scrum – Desenvolvimento Scrum – Desenvolvimento Ágil Ágil

Page 2: Scrum - Desenvolvimento Ágil

2

ProblemasManifesto Ágil

Origens do ScrumO que é o Scrum

Processo do Scrum

Resultados

2

Page 3: Scrum - Desenvolvimento Ágil

3

PROBLEMASPROBLEMASCom desenvolvimento tradicional de

softwareCom desenvolvimento tradicional de

software

3

Page 4: Scrum - Desenvolvimento Ágil

4

Resultado dos projetos (2004):

CHAOS ReportCHAOS Report

18%

29%53%com

problemas

sucesso

falham

Page 5: Scrum - Desenvolvimento Ágil

5

CHAOS ReportCHAOS Report

1994 2004

Projetos não concluídos------------ 31%

Projetos bem sucedidos----- 16%

Estouro médio de custo------------> 180%

Estouro médio de prazo------------ 164%

Projetos não concluídos------- 18%

Projetos bem sucedidos----------- 29%

Estouro médio de custo------ 56%

Estouro médio de prazo-------- 84%

Page 6: Scrum - Desenvolvimento Ágil

6

Qual software?Qual software?

64%Funcionalidades

nunca ou

raramenteutilizadas

Jim Johnson, 2000

Page 7: Scrum - Desenvolvimento Ágil

7

Em função deste cenário...Em função deste cenário...

Page 8: Scrum - Desenvolvimento Ágil

8

O que aprendemos ?O que aprendemos ?

“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.”

Jim JohnsonChairman 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 otimizado1.Métodos ágeis

Sources:http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standishhttp://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS”My Life is Failure”, Jim Johnson’s book

“Não há bala de prata, mas os métodos ágeis chegam muito perto"

Page 9: Scrum - Desenvolvimento Ágil

99

O Manifesto ÁgilO Manifesto Ágil

www.agilemanifesto.org“Nós estamos descobrindo novas maneiras de

desenvolver software fazendo e ajudando outros a fazê-lo

Feb 11-13, 2001Snowbird ski resort, Utah

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas

Page 10: Scrum - Desenvolvimento Ágil

1010

O Manifesto ÁgilO 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!”

Page 11: Scrum - Desenvolvimento Ágil

1111

O Manifesto ÁgilO 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...

Note que o manifesto prega mudança de ênfase - e não ruptura...

Page 12: Scrum - Desenvolvimento Ágil

1212

O Manifesto ÁgilO Manifesto ÁgilAlé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.

1. O método mais eficiente e efetivo de repassar informação entre uma equipe de desenvolvimento é através de conversação cara-a-cara.

Page 13: Scrum - Desenvolvimento Ágil

1313

O Manifesto ÁgilO Manifesto ÁgilAlé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.

7. Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento de acordo.

Page 14: Scrum - Desenvolvimento Ágil

14

Page 15: Scrum - Desenvolvimento Ágil

15

Origem do ScrumOrigem do Scrum

Desenvolvimento iterativo e incremental

SCRUM

Jeff Sutherland, PhD

Ken Schwaber

XPSmalltalk

Engineering Tools

Page 16: Scrum - Desenvolvimento Ágil

16

Origem do ScrumOrigem 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.

Page 17: Scrum - Desenvolvimento Ágil

17

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 ScrumOrigem do Scrum

Page 18: Scrum - Desenvolvimento Ágil

18

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

Page 19: Scrum - Desenvolvimento Ágil

19

Termo ScrumTermo 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.

Page 20: Scrum - Desenvolvimento Ágil

20

Algumas empresas que Algumas empresas que estão utilizando:estão utilizando:

Page 21: Scrum - Desenvolvimento Ágil

21

O processo do ScrumO processo do ScrumO Scrum define um framework de processo leve para gerenciamento de

projetos segundo os valores e princípios ágeis.

Page 22: Scrum - Desenvolvimento Ágil

22

O processo do ScrumO processo do Scrum1. Plano Inicial Leve (Visionário)2. Requisitos Priorizados e

Detalhados com Paretto (mais importantes com maior precisão)

3. Planejamento Mensal com Seleção dos Requisitos Prioritários

4. Estimativa e Planejamento de Atividades pelo Time

5. Iteração de Entrega de 30 dias (Sprint)

6. Iteração de Acompanhamento Diária (Daily Scrum - 15 minutos)

7. Liberação Parcial de Software Útil

Page 23: Scrum - Desenvolvimento Ágil

23

Entendendo o Scrum – Entendendo o Scrum – PapéisPapéis

Page 24: Scrum - Desenvolvimento Ágil

24

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

Product Owner

Page 25: Scrum - Desenvolvimento Ágil

25

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 Master

Page 26: Scrum - Desenvolvimento Ágil

26

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.

Scrum Team

Page 27: Scrum - Desenvolvimento Ágil

27

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.

Stackholders (partes interessadas)

Page 28: Scrum - Desenvolvimento Ágil

28

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)

Management

Page 29: Scrum - Desenvolvimento Ágil

29

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

Page 30: Scrum - Desenvolvimento Ágil

30

Entendendo o Scrum – Entendendo o Scrum – CerimôniasCerimônias

Page 31: Scrum - Desenvolvimento Ágil

31

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

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 – Entendendo o Scrum – CerimôniasCerimônias

Page 32: Scrum - Desenvolvimento Ágil

32

Entendendo o Scrum – Entendendo o Scrum – CerimôniasCerimôniasDaily 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)

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.

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

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

Page 33: Scrum - Desenvolvimento Ágil

33

Daily ScrumDaily Scrum

Page 34: Scrum - Desenvolvimento Ágil

34

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

Suportar funcionalidades necessárias para estudos genéticos

Fazer a aplicação funcionar em MS SQL Server além do Oracle

Fazer a aplicação funcionar em MS SQL Server além do Oracle

Funcionalidades que provam o conceito do que foi liberado pelos

arquitetos

Funcionalidades que provam o conceito do que foi liberado pelos

arquitetos

Page 35: Scrum - Desenvolvimento Ágil

35

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

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!

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!

SprintBacklog•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)

SprintBacklog•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 – Entendendo o Scrum – ArtefatosArtefatos

Page 36: Scrum - Desenvolvimento Ágil

36

Product backlogProduct backlog

Page 37: Scrum - Desenvolvimento Ágil

37

Sprint backlogSprint backlog

Page 38: Scrum - Desenvolvimento Ágil

38

Entendendo o Scrum – Entendendo o Scrum – ArtefatosArtefatosImpedimentBacklog• 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.

ImpedimentBacklog• 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.RetrospectiveItens• 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".

RetrospectiveItens• 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".

SprintBurndown•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.

SprintBurndown•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.

Page 39: Scrum - Desenvolvimento Ágil

39

HH Restantes

Sprint Burndown

Page 40: Scrum - Desenvolvimento Ágil

40

Sprint Burndown

Page 41: Scrum - Desenvolvimento Ágil

41

Entendendo o Scrum – Entendendo o Scrum – ArtefatosArtefatosReleaseBurndown•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.

ReleaseBurndown•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.

AgileRadiator• També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’.

AgileRadiator• També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’.

Page 42: Scrum - Desenvolvimento Ágil

42

Agile Radiator

Page 43: Scrum - Desenvolvimento Ágil

43

Release Burndown

Page 44: Scrum - Desenvolvimento Ágil

44

Término Anormal de Término Anormal de SprintSprintSprints 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.

Page 45: Scrum - Desenvolvimento Ágil

45

Exemplos ReaisExemplos Reais

Page 46: Scrum - Desenvolvimento Ágil

46

Por que o Scrum funcionaPor 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

Page 47: Scrum - Desenvolvimento Ágil

47

Por que o Scrum funcionaPor que o Scrum funcionaFortemente IterativoFortemente Iterativo

Page 48: Scrum - Desenvolvimento Ágil

48

Objetivos SMARTObjetivos 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 funcionaPor que o Scrum funciona

Page 49: Scrum - Desenvolvimento Ágil

49

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 funcionaPor que o Scrum funciona

Sprint Planning

Atividades do time

Sprint review e daily scruns

Retrospective meeting

Page 50: Scrum - Desenvolvimento Ágil

50

Peopleware e SustentabilidadePeopleware 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 funcionaPor que o Scrum funciona

Page 51: Scrum - Desenvolvimento Ágil

51

ResultadosResultadosFator Melhorou Não mudou Piorou

Produtividade 82% 13% 5%

Qualidade 77% 14% 9%

Satisfação 78% 15% 7%

Custo 37% 40% 23%

Referência: Pesquisa realizada pela InfoQ.com com 642 empresas

Page 52: Scrum - Desenvolvimento Ágil

52

O Scrum não falha... Será ?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!

Page 53: Scrum - Desenvolvimento Ágil

53

Alguns livros...Alguns livros...

Page 54: Scrum - Desenvolvimento Ágil

54

Dúvidas?Dúvidas?

Page 55: Scrum - Desenvolvimento Ágil

55

ReferênciasReferências1. Agile Manifesto, Manifesto for Agile Software Development, 2001. Disponível

em http://agilemanifesto.org/ [Novembro, 2005]. 2. ANDERSON, D. J., Agile Management for Software Engineering, Applying the

Theory of Constraints for Business Results, Prentice Hall, 2003. 3. BOEHM, B., A View of 20th and 21st Century Software Engineering, ICSE

2006. 4. BOEHM, B. and Turner, R., Balancing Agility and Discipline A Guide for the

Perplexed, AddisonWesley, 2003. 5. COHN, Mike, Agile Estimating and Planning, Prentice Hall, 2006, 330 p. 6. HIGHSMITH, J., Agile Project Management, Creating innovative products,

AddisonWesley, 2004. 7. KNIBERG, Henrik., Scrum and XP from the Trenches, How we do Scrum, Nov.,

2006, 90 p. 8. MOUNTAIN Goat Software, The Scrum Development Process, Disponível em

http://www.mountaingoatsoftware.com/Scrum [Junho, 2006]. 9. SCHWABER, K., and Beedle, M., Agile Software Development With Scrum,

Prentice Hall, 2002. 10. SCHWABER K., Agile Project Management With Scrum, Microsoft, 2004.