Apresentação Scrum DotNetArchitects

Post on 18-Jun-2015

1.993 views 6 download

description

Apresentação feita por mim a respeito de Scrum na segunda reunião (22/11/2008) do grupo DotNetArchitects.

Transcript of Apresentação Scrum DotNetArchitects

Metodologias “Tradicionais”Baseado na engenharia tradicionalFoco em atividadeOrientada por documentosDificuldade de lidar com mudançasSegregação da equipeFalsa percepção de % concluído do projetoBig Modeling Up Front (BMUF)

Modelo Cascata

ValoresIndividuals and interactions over processes and toolsWorking software over comprehensive

documentation Customer collaboration over contract negotiation Responding to change over following a plan

Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick

Benefícios da AgilidadeCliente

Antecipar expectativasEntregar valor real ao clienteEvitar desperdícioEvitar o efeito da “pseudo previsibilidade”Evitar/Reduzir retrabalhoProduzir software com mais qualidade (- Bugs)

EquipeElevar o nível da equipeObter feedback imediatamenteEquipes multidisciplinaresPercepção de trabalho bem feito

PrincípiosFoco em objetivosHonestidade acima de tudo (open

conversation)Trabalho com qualidadeComprometimento de toda a equipe em

maximizar o ROI do clienteCódigo pertencente a toda equipe Travel Light (somente o necessário)Modelar com um propósitoSimplicidade

Modelo Empírico

PapeisProduct Owner

$$$Scrum Master

FacilitadorTeam

Business SpecialistsSystem AnalystsDevelopersDesigners

Principais ArtefatosUser Story

Acceptance CriteriaProduct Backlog

All User StoriesSprint Backlog

Specifics User StoriesBurn Down Chart

Management

Principais AtividadesPlanning

Planning PokerDaily Meeting

15 MinutosO que você fez hoje?O que você vai fazer amanhã?O que esta impedindo você?

Sprint ReviewFeedback do cliente

Retrospective

EncontrosIntegração freqüenteMelhoria na comunicação e entrosamentoVisibilidade das falhasCrescimento acelerados dos membros do

timeDocumentações atualizadasEliminação das dependências de softwareMelhoria no design da aplicação

DesencontrosTime “mau” treinado

Ferrmenta automatizando o erroCliente “preguiçoso”

Falta de feedbackCliente não participativo

Dificuldade em lidar com as falhasNem todos estão preparadosMuito over-time

Imposição de ritmoFalta de definição de “Done”

Referênciashttp://www.guj.com.br – Grupo de Usuários Javahttp://www.agilemodeling.com - Agile Modelinghttp://www.agilemanifesto.org – Manifesto Ágilhttp://www.extremeprogramming.org - XPhttp://www.improveit.com.br/xp - Consultoria

especializada em metodologias Agéishttp://www.improveit.com.br/scrum - Consultoria

especializada em metodologias Agéis

Referências (cont.)http://delvar.wordpress.com/2006/05/03/o-jogo-

do-planejamento-parte-i/ - Jogo do Planejamento

http://delvar.wordpress.com/2006/05/03/o-jogo-do-planejamento-parte-ii/ - Jogo do Planejamento

http://delvar.wordpress.com/2006/05/03/o-jogo-do-planejamento-parte-iii/ - Jogo do Planejamento

http://www.ayende.com/projects/rhino-mocks/downloads.aspx - Rhino Mocks

Obrigado!

Antonio Carlos Zegunis Filhohttp://blog.tucaz.net