Apresentação Scrum DotNetArchitects
-
Upload
antonio-zegunis -
Category
Technology
-
view
1.993 -
download
6
description
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