Upload
paulo-igor-godinho
View
931
Download
10
Embed Size (px)
DESCRIPTION
Palestra sobre Metodologias Ágeis focado em Scrum no evento do Prodap de Macapá - AP.
Citation preview
Metodologias Ágeis e o SCRUM
[“Thinking Different”]
Paulo Igor [email protected]
@pigodinho hDp://blog.pigor.net
Um pouco sobre mim...
• Bacharel em Sistemas de Informação pelo CESUPA • Mestre em Ciência da Computação pela UFPA • ScrumMaster CerPfied (2008)
• Analista Especialista e Arquiteto de SoXware – Cobra Tecnologia S.A. (ScrumMaster ‐ Piloto)
– Pródiga Sistemas (Líder Técnico / ScrumMaster)
• Professor de Pós‐graduação do CESUPA • Membro aPvo de comunidades regionais e nacionais
– Beljug, TáSafo, Dojo‐Pa (Fundador), Scrum‐PA, ...
Meus Contatos
• [email protected] • pigodinho (TwiDer) • hDp://blog.pigor.net
A essência dos Projetos
Conceitos
O que é um projeto?
Quais são as suas caracterísicas?
...projeto é um esforço temporário para criar um serviço, ou produto,
ou resultado exclusivo.
Projetos são...
Temporários
Temporários
Planejados, Executados e Controlados
Entregam produto, serviço, ou resultado exclusivo
Desenvolvido em etapas
Realizado por pessoas
Com recursos limitados
Metodologias Ágeis
Scrum, XP, FDD, Lean, ...
Já ouviu falar?
Chaos Report
Chaos Report
• Segundo o Standish Group os principais fatores são: – Falta de clareza sobre funções pessoais, responsabilidades e requisitos.
– Falta de habilidade para acompanhar os passos do ciclo de vida da aplicação.
Uso das funcionalidades
80% das funcionalidades desenvolvidas NÃO serão usadas
80% de DESPERDÍCIO
O cliente fica saPsfeito?
Início dos conflitos...
Falhas na Comunicação
Resumindo...
• A comunicação entre as partes envolvidas nos projetos é muito fraca;
• A visibilidade do andamento real e dos problemas existentes nos projetos é muito fraca;
• Clientes pedem sempre mais do que realmente precisam;
• Os projetos são caros e, ainda em sua maioria, não alcançam sucesso;
• Os conflitos existentes entre TI e negócios durante os projetos são muitos;
O Problema do Cliente
• Clientes sabem que fornecedores odeiam mudanças de requisitos;
• Clientes são “forçados” a definir tudo que precisam na fase inicial do projeto;
• Clientes no início de um projeto estão inseguros quanto ao que precisam;
A solução do Cliente
• Colocar o máximo possível de requisitos na lista inicial;
• Entende‐se por “o máximo possível” tudo que lhe vier à cabeça naquele momento;
• Desta forma a possibilidade de “faltar” requisitos no produto final é menor;
O Problema do Fornecedor
• Fornecedores sabem que os requisitos fornecidos pelo cliente são vagos;
• Fornecedores sabem que no decorrer do projeto o cliente precisará mudar os requisitos;
• Fornecedores sabem que sempre ao validar o produto o cliente surgirão novas idéias para o produto;
A solução do Fornecedor
• Documentar ao máximo tudo que foi passado pelo cliente para que o fornecedor possa estar protegido;
• Colocar margens de tempo por todo o projeto;
• Entregar o produto para o cliente apenas no final do projeto;
Resultado
Conflito entre as partes! Quem mais perde?
A EMPRESA
A “solução”
Pessoas
Qualidade e ProduPvidade
...ignorou a cultura!
Tradicional X Ágil
Análise Tradicional
Big Design Up Front
Cascata
Pobre Winston Royce!!!
Por que não da certo?
Por que não se faz soXware assim!!!
Tradicional (Cascata)
• Orientado a documentação
• Feedback no final do projeto
• Mudanças são prejudiciais
Ágil
• Desenvolve‐se em ciclos pequenos – Aprende‐se do negócio e da solução iteraPvamente
• Ataca os riscos do projeto mais rapidamente
• As mudanças não são tão problemáPcas
• O cliente da feedback durante todo o projeto
Mundo Real ≠ Mundo Digital
Pede pra fazer uma alteração brusca no meio da construção de um prédio
Manifesto Ágil
hDp://agilemanifesto.org/
Manifesto Ágil
• “Estamos descobrindo maneiras melhores de desenvolver soXware fazendo‐o nós mesmos e ajudando outros a fazê‐lo. Através desse trabalho, passamos a valorizar:
– Indivíduos e interações entre eles mais que processos e ferramentas
– Produto em funcionamento mais que documentação abrangente
– Colaboração com o cliente mais que negociação de contratos
– Responder a mudanças mais que seguir um plano
• Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda”.
Fonte: hDp://agilemanifesto.org
Você conseguiria comer???
Incremental X InteraPvo
IteraPvo e Incremental
Ciclo PDCA
Quem adota métodos ágeis? MicrosoB
Yahoo
Electronic Arts
Stefanini IT SoluIons (Brasil)
Philips
Siemens
Nokia
Alterdata (Brasil)
BBC
Sea Tecnologia (Brasil)
Nielsen Media
ThoughtWorks
BMC SoXware
Serpro (Brasil)
Lexis Nexis
Sabre
Salesforce.com
Time Warner
Globo.com (Brasil)
E o SCRUM????
Scrum é...
• Um processo iteraPvo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto;
• É mais um framework que uma metodologia, mais aPtude que um processo;
Scrum também é...
• Processo empírico de gerenciamento e controle • Inspeção e adaptação em ciclos e feedback • Usado para gerenciar projetos desde 1990 • Entrega frequente de funcionalidade com valor para o cliente (ROI)
• Escalável a projetos distribuídos, grandes e largos • Processos compa{veis com CMMI nível 3 e ISO9001
• Extremamente simples, mas resistente
A Origem do Scrum
Jeff Sutherland, PhD
Ken Schwaber
Desenvolvimento IteraPvo e Incremental
SCRUM
hDp://www.infoq.com/presentaPons/The‐Roots‐of‐Scrum
Processos Ágeis e Scrum
XP
SCRUM
Crystal
DSDM
FDD
Mapeando algumas caracterísPcas Processos: Reunião Diária, Reunião de Planejamento, Review, RetrospecPva, Planejamento de Release, ...
Ferramentas: Quadro Kanban, Post‐it, Burndown, ... Pessoas: Líder de equipe, Cliente ou representante do produto, Time, ...
Cultura: Time mulP‐disciplinar, auto‐gerenciamente, valores, envolvimento do cliente, entrega frequente, liderança‐colaboraPva, RESPEITO, ...
Scrum é...
Empresa A Empresa B Empresa C
“Simples de entender, mas di~cil de adotar e praPcar”
“Modelo Empírico”
“Altamente Ajustável”
“Esse modelo trata de pessoas”
O SCRUM é assim...
ParPcipação do Cliente
Planejamento Ágil
Planejamento Constante
A cada iteração é entregue um incremento do soXware
Sempre entregar valor! Iten
s técnicos, arquitetura, infra‐estrutura, ...
Itens com RoI visível
Planejamento de Releases
Planejamento de Releases
2 semanas cada
8 semanas para o primeiro release
Papéis no Scrum
Product Owner
Time ScrumMaster
Envolvidos X CompromePdos
Comando‐Controle X
Auto‐Gerenciamento
Comando‐Controle não!
ApáIco: “Não tenho nada pra fazer hoje, ninguém me passou nada e nem sei também o por que eu faço essas coisas!”
Pró‐aIvo: “Quando o chefe voltar eu vejo o que ele tem pra me passar, estou sem nada pra fazer”
Auto‐gerenciado: “Quando terminar essa aPvidade vou aproveitar o tempo restante pra discuPr melhorias no projeto com a equipe, para atender melhor as necessidades”
Ciclo SCRUM
Ciclo SCRUM
Manutenção do Product Backlog
Quais seriam as suas prioridades?
O que pode influenciar a sua decisão?
Time EsPma...
Cliente Prioriza!
Planeja a Sprint
Hora de executar
Reunião Diária
Ambiente ColaboraPvo
Hora da Review
RetrospecPva
RetrospecPva
...e começa tudo de novo!!!
Valore Ágeis
Melhoria Con{nua
Adaptabilidade
CompromePmento e Confiança
HonesPdade
Respeito
Coragem
Sucesso será o Resultado!
Times que aPngem meta devem celebrar!
? Obrigado!!!