1 Scrum – Desenvolvimento Scrum – Desenvolvimento Ágil Ágil
Nov 01, 2014
1
Scrum – Desenvolvimento Scrum – Desenvolvimento Ágil Ágil
2
ProblemasManifesto Ágil
Origens do ScrumO que é o Scrum
Processo do Scrum
Resultados
2
3
PROBLEMASPROBLEMASCom desenvolvimento tradicional de
softwareCom desenvolvimento tradicional de
software
3
4
Resultado dos projetos (2004):
CHAOS ReportCHAOS Report
18%
29%53%com
problemas
sucesso
falham
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%
6
Qual software?Qual software?
64%Funcionalidades
nunca ou
raramenteutilizadas
Jim Johnson, 2000
7
Em função deste cenário...Em função deste cenário...
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"
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
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!”
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...
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.
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.
14
15
Origem do ScrumOrigem do Scrum
Desenvolvimento iterativo e incremental
SCRUM
Jeff Sutherland, PhD
Ken Schwaber
XPSmalltalk
Engineering Tools
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.
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
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
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.
20
Algumas empresas que Algumas empresas que estão utilizando:estão utilizando:
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.
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
23
Entendendo o Scrum – Entendendo o Scrum – PapéisPapéis
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
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
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
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)
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
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
30
Entendendo o Scrum – Entendendo o Scrum – CerimôniasCerimônias
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
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
33
Daily ScrumDaily Scrum
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
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
36
Product backlogProduct backlog
37
Sprint backlogSprint backlog
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.
39
HH Restantes
Sprint Burndown
40
Sprint Burndown
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’.
42
Agile Radiator
43
Release Burndown
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.
45
Exemplos ReaisExemplos Reais
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
47
Por que o Scrum funcionaPor que o Scrum funcionaFortemente IterativoFortemente Iterativo
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
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
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
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
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!
53
Alguns livros...Alguns livros...
54
Dúvidas?Dúvidas?
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.