• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Scrum com Equipes Distribuidas
 

Scrum com Equipes Distribuidas

on

  • 3,483 views

 

Statistics

Views

Total Views
3,483
Views on SlideShare
3,482
Embed Views
1

Actions

Likes
10
Downloads
0
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • NZ: financial hub bc of time zone: every day begins in NZ first! Indian software community has accepted, unquestioning, the myth that time zone differences are a huge advantage for India… … even as they stay very late at work to call USA

Scrum com Equipes Distribuidas Scrum com Equipes Distribuidas Presentation Transcript

  • Scrum com Equipes Distribuídas Rafael Prikladnicki [email_address] twitter.com/rafaelpri www.inf.pucrs.br/~rafael
  • Rafael Prikladnicki www.inf.pucrs.br/~rafael Professor da FACIN/PUCRS desde 2004 Coordenador do GUMA (Sucesu-RS) Mestre em Ciência da Computação – PUCRS (2003) Doutor em Ciência da Computação – PUCRS (2009) Coordenador da Agile Brazil 2010 Áreas de atuação acadêmica e profissional: Desenvolvimento Distribuído de Software Gerência de Projetos Melhoria de Processo de Software Engenharia de Software Experimental Lean e Métodos Ágeis para Desenvolvimento de Software
  • “ Trabalhamos enquanto você trabalha” “ Trabalhamos enquanto você está dormindo” ?
  • Contexto www.inf.pucrs.br/munddos Implantação de práticas de DDS nas empresas Desenvolvimento de ferramentas para apoiar DDS Integração de DDS com métodos ágeis Estudo de maneiras de usar Follow-the-Sun (FTS) Formação de profissionais e alunos em DDS Estudo do papel do Brasil no mercado global de TI
  •  
  • Não use metodologias ágeis!
  • Não use Scrum
  • Não trabalhe com equipes distribuídas
  • Apenas se você tiver um motivo !
  • O que estes videos têm em comum ?
  • Interesse por Scrum
  • Interesse por Scrum EUA BR 2 anos!
  • Interesse por Scrum
  • Interesse por Scrum
  • Offshore services no Brasil Fonte: BRASSCOM/IDC (2009)
  • Por que DDS? Por que métodos ágeis Por que Scrum?
  • Métodos Ágeis É uma febre passageira ? É o início de uma mudança na forma de trabalho
  • DDS é um modelo que se paga? Se as empresas souberem usar
  • Globalização Desenvolvimento de software
    • Crescimento acentuado desde a década de 90
    • Oportunidades de negócio
      • Recursos globais disponíveis (habilidades e custo)
      • Proximidade ao mercado local e aos clientes
      • Benefícios a partir das oportunidades globais de mercado
      • Exploração do desenvolvimento “round-the-clock”
    • Inovação!
  • Desenvolvimento Distribuído de Software
    • Não é um fenômeno novo
    • Outras áreas do conhecimento já se envolvem em atividades com equipes distribuídas há muito tempo
      • Em desenvolvimento de software é recente
  • Desenvolvimento Distribuído de Software Offshore insourcing International sourcing Offshore outsourcing Offshore sourcing Onshore Onsite Offshoring Nearshore Dedicated captive centers Wholly-owned subsidiary Farshore Bestshore
  • Outsourcing Atividade desenvolvida e gerenciada por um terceiro dentro ou fora das instalações do contratante
  • Onsite No local do contratante Onshore No país do contratante Offshore Fora do país do contratante
  • Offshore outsourcing Outsourcing em outro país Offshore insourcing Outsourcing em outro país desenvolvimento interno
  • Motivação para DDS ??? China Japão Índia Singapura Austrália “… Logo após nós tivemos que integrar as pessoas em uma equipe única. Neste momento, identificamos fatores de risco e desenvolvemos estratégias para reduzí-los”. 100% 20% Engenheiros de software dos centros de desenvolvimento de software da Motorola Equipe nos EUA Novo Projeto [Robert D. Battin et al., 2001] – IEEE Software, Case da Motorola
  • Motivação para DDS EUA BRASIL RÚSSIA ÍNDIA
  • Separação física desafios
      • Grande parte do desenvolvimento é baseado em comunicação entre pessoas (Philippe Kruchten)
      • Dificuldades em comunicação, coordenação e gerenciamento
      • Questões estratégicas
      • Questões culturais
      • Comunicação inadequada
      • Gestão do conhecimento
      • Gestão do projeto e do processo
      • Dificuldades técnicas
    • Por que DDS é importante para o Brasil?
    • O Brasil está entre os principais países de Up and Comming no que diz respeito ao DDS
    • Por que DDS é importante para outros países?
    • As empresas estão cada vez mais buscando alternativas em outros países, com custos menores e vantagens competitivas (empresas dos EUA e Europa principalmente)
    Importância
  • Características
    • Área recente
    • Conversão de mercados nacionais em mercados globais
      • Necessidade de ter recursos globais
      • Vantagens de estar perto do mercado local
    • Demanda e custos
    • Sinergia cultural
    • Mercado global
    • Time-to-market
    • Rigor e experiência
    • Escala
  • Mudança de contexto Gestor Mesma localização física
  • Mudança de contexto Gerente de Projeto Mesma localização física Gestor Matriz Outro país Outra cidade
  • Forças centrífugas e centrípetas
  • Dimensões do DDS Projetos Distribuídos Confiança Distância Percebida Nível de Dispersão Sincronização Tipo de Atores Stakeholders Complexidade Cultura Tipo de Projeto Processo de Desenvolvimento Procedimentos e Padrões
  • Principais desafios
      • Aspectos técnicos
      • Aspectos comportamentais
      • Aspectos linguísticos
      • Aspectos culturais
      • Aspectos políticos
      • Aspectos geográficos
      • Aspectos financeiros
    F2F ou falar ao telefone? Rica comunicação F2F
  • Principais desafios Gerenciar diversidade cultural, diferenças e conflitos Lidar com distância geográfica e dispersão Lidar com problemas de coordenação e controle Manter a riqueza da comunicação através da distância Desenvolver e manter espítiro de equipe
  • Questões estratégicas Recursos disponíveis Nível de conhecimento técnico Comunicação Infra-estrutura existente Postura da gerência e da organização como um todo Suporte da organização Decidir como dividir o trabalho em diversas equipes ou centros distribuídos geograficamente
  • Questões culturais
    • Princípios
    • Valores
    • Crenças
    • Comportamentos
    • Ética
    • Maneiras
    • Ideologias
    • Bom vs. Mau
    • Folclore
    • Gestos
    • Palavras
    • Tons de voz
    • Contato
    Cultura nacional/étnica/regional Cultura organizacional Cultura profissional Cultura tecnológica Cultura funcional Cultura de equipe Sopa de cultura “ Cultura é o que acontece sem dizer” PORTA Imperativo no BR “ por favor” EUA Noruega Aperto de mão Confiança!!!
  • Comunicação inadequada Atividades tais como engenharia de requisitos, análise e projeto requerem uma comunicação intensa Não existe a “conversa de corredor” ou a “conversa no café” Falta de sensibilidade para o progresso do trabalho (habilidade relevante, mas difícil de se trabalhar) Pequenas dificuldades podem se transformar em grandes problemas
  • Gestão do conhecimento
    • Compartilhar informação entre os projetos
    • Abordagem de Evaristo
      • Conhecimento from , about , e in projects
    • Prioridades, mudanças, decisões, falhas
    • Dificuldade de manter a documentação do projeto atualizada, causando desconforto e falta de informação (colaboração ineficiente)
    • Sensação de perda da possibilidade de incentivar a reutilização (de código, de planejamento, etc.)
  • Gestão do projeto e do processo Diferentes processos em cada local Especificações intermináveis Diferentes entendimentos sobre responsabilidades entre diferentes organizações Problemas que aparecem apenas no momento da integração
  • Dificuldades técnicas [Damian et al., 2002]
  • Dificuldades técnicas [Karolak, 1998]
  • E o Scrum?
  • E o Scrum?
  • Níveis de distribuição
  • Níveis de distribuição
    • Collocated
      • Todos os integrantes da equipe estão no mesmo local
      • Este tipo de equipe tem se tornado cada vez mais raro no desenvolvimento de software
    • Collocated part-time
      • Os integrantes geralmente estão no mesmo local, com alguns integrantes ocasionalmente trabalhando de forma distribuída
      • Vivenciam alguns desafios das equipes distribuídas
      • Geralmente estão no mesmo fuso-horário
      • Fácil de se reunir se for necessário
      • Scrum meetings and daily scrums são mais difíceis dependendo de onde estão os colaboradores distribuídos
      • Alguns desafios já começam a surgir ( daily meeting executado com teleconferência)
  • Níveis de distribuição
    • Distributed with overlapping hours
      • Os colaboradores distribuídos possuem algumas horas do dia para interagir
      • Exemplo: 5 pessoas na Europa e 3 na Índia (3,5 horas em comum)
      • Daily scrum é mais difícil
      • Sprint planning é ainda mais difícil (qual é o melhor horário?)
    • Distributed with no overlapping hours
      • Colaboradores não interagem durante o horário de trabalho
      • Exemplo: parte da equipe na Califórnia, parte no Texas, parte em Pequim (China). Quando for 6 da manhã na Califórnia, será 8 da manhã no Texas e 9 da noite em Pequim
      • As empresas evitam este tipo de organização, principalmente para equipes de alto desempenho
      • Manter a dinâmica de equipe é chave para o uso do Scrum com sucesso
      • É difícil trabalhar com Scrum neste cenário, mas não impossível
    • Se é tão difícil, por que trabalhar com equipes distribuídas ?
  • Por que DDS e Scrum
    • Os métodos ágeis surgiram na década de 1990
    • Deste então o négocio envolvendo desenvolvimento de software mudou radicalmente
    • O desenvolvimento de software se tornou uma atividade distribuída
    • Não existem fronteiras para as empresas
    • Internet e tecnologia de comunicação reduzem distâncias
    • Redução de custos
    • Follow the sun
    • Acesso à novos mercados
    • Aquisição de empresas
    • Inovação global
    • Ferramentas de colaboração
      • IBM Rational Team Concert – Jazz
  • Isolated Scrum
    • Cada local possui uma equipe Scrum multidisciplinar
    • As equipes são independentes
    • Não há necessidade de colaboração
    • Cenário ideal, pois as equipes trabalham nos dois primeiros níveis de distribuição
    • Quanto mais a equipe conseguir ficar nos dois primeiros níveis, maior será a chance de sucesso
    • Equipes em 5 países? Tentar criar equipes independentes em cada local
    • E se não existirem as habilidades necessárias para formar a equipe em um único local ? Distribuir as equipes
  • Distributed Scrum of Scrums
    • Cada local possui uma equipe Scrum multidisciplinar
    • Reuniões de Scrum of Scrums de forma periódica para coordenar esforços entre as equipes
    • Adaptação da reunião para Scrum of Scrums
      • O que sua equipe fez no período anterior?
      • O que sua equipe vai fazer no próximo período?
      • Quais são os impedimentos da equipe?
      • Quais são os impedimentos da tua equipe que podem comprometer outra equipe?
    • O dono do produto precisa coordenar o trabalho de múltiplas equipes (no cenário anterior cada equipe possuia um dono de produto)
  • Totally integrated Scrums
    • Cada equipe possui integrantes em diversos locais
    • Este cenário geralmente entra no terceiro e quarto níveis de distribuição
    • Geralmente o idioma nativo de um local não é o idioma da equipe
    • Mais dificuldades em todos os sentidos
    • Adaptação da reunião para Scrum of Scrums
  • Planejamento e preparação
    • Product Owner e Cliente
    • Visão do produto
    • Criação do product backlog, user stories
    • Surveys, reuniões
    • Uso de ferramentas colaborativas
  • Quantos product owners
    • Como coordenar diversos Product Owners
      • Trabalhar com hierarquia
  • Quantos product backlogs
    • Equipes Scrum tradicionais geralmente possuem um backlog
    • Para equipes distribuídas é necessário avaliar os desafios
      • Avaliar se é possível ter uma reunião de sprint planning com a equipe inteira participando
      • Avaliar a possibilidade de dividir uma parte do backlog para cada equipe distribuída
  • Quantos product backlogs
  • Quantos product backlogs
  • Quantos product backlogs
  • Quantos product backlogs
  • Desenvolvimento
    • Product Owner , ScrumMaster e Equipe
    • Análise e organização do Product Backlog
      • Refinamento das funcionalidades
      • Estimativas
      • Escolha das funcionalidades para o sprint
      • Formalização do sprint backlog
      • Identificação das tarefas
      • Organização da taskboard
  • Desenvolvimento
    • Como priorizar os itens do backlog?
    • Como estimar tamanho das user stories ?
      • Usar ferramentas de bate-papo
      • Usar ferramentas web do tipo www.planningpoker.com
    • Como definir o que será desenvolvido em cada sprint ?
      • O planejamento dos primeiros sprints geralmente demoram mais
      • Usar a técnica do “ lookahead” planning, do Mike Cohn
      • Considerar feriados locais, horário de trabalho em cada país
  • Desenvolvimento
    • Planejar para que as equipes fiquem no nível de distribuição mais simples possível
    • Tentar sempre criar equipes collocated e multidisciplinares
    • Se não for possível, criar equipes multidisciplinares, no mesmo fuso horário
    • Somente se isto não for possível, aceitar que a única solução é criar equipes distribuídas e com diversos fusos-horários
  • Desenvolvimento
    • Como fazer o planejamento das sprints
      • Abordagem Full team
      • Abordagem Preplanning team
      • Abordagem Balanced team
      • Ter todos os integrantes de uma equipe distribuída em uma reunião de planejamento de sprint é irreal
      • As abordagens devem ser combinadas
      • Abordagens Preplanning e Balanced são adequadas para equipes distribuídas
  • Desenvolvimento
    • ScrumMaster e Equipe
    • Dia-a-dia do SCRUM
      • Sprint
        • 2 semanas a 4 semanas
      • Daily meetings (Daily Scrum)
      • Impedimentos
        • Obstáculos ao trabalho da equipe
      • Manter a taskboard
        • Burndown
        • Tarefas e estimativas
        • Tarefas não-planejadas
  • Desenvolvimento
    • E quando não houver horário em comum?
      • 1. Daily Scrum através de documentação
      • 2. Ter um liaison
      • 3. Alternar horários das reuniões
      • 4. Compartilhar as dificuldades
      • 5. Usar ferramentas de bate-papo
        • Esta geralmente é utilizada quando existe intersecção de horários
  • Desenvolvimento
    • Daily meetings (Daily Scrum)
      • 1. Daily Scrum através de documentação
        • Menos efetivo
        • Responder as três perguntas em um e-mail, wiki, etc
  • Desenvolvimento
    • Daily meetings (Daily Scrum)
      • 2. Ter um liaison
        • Planejar duas reuniões tendo uma pessoa em comum participando das duas
  • Desenvolvimento
    • Daily meetings (Daily Scrum)
      • 3. Alternar horários das reuniões
        • As reuniões ocorrem em horários alternados de trabalho de cada equipe
  • Desenvolvimento
    • Daily meetings (Daily Scrum)
      • 4. Compartilhar as dificuldades
        • Escolher o melhor horário de forma democrática, respondendo 3 perguntas:
          • Quais são os melhores horários para você se reunir com a equipe?
          • Quais são os horários em que você se reuniria com a equipe?
          • Quais são os horário em que você não se reuniria com a equipe?
        • Espírito de equipe
        • Transparência e confiança
        • Nem todos consideram esta possibilidade
      • 5. Usar ferramentas de bate-papo
        • Funciona com todos os tipos de distribuição, exceto quando não existe intersecção de horários
        • Pode ser caótico se não houver uma boa condução da reunião
        • Mesmas dificuldades enfrentadas em qualquer configuração de equipe
  • Desenvolvimento
  • Sprint review e retrospectiva
    • Discussão
      • Como fazer sprint review com equipes distribuídas?
      • Como conduzir sessões de retrospectiva com equipes distribuídas?
  • DDS é uma realidade Assim como métodos ágeis Conclusões Assim como Scrum
  • Conclusões Scrum é um dos métodos ágeis mais utilizados atualmente
  • Conclusões Equipes distribuídas possuem diversas dificuldades. e desafios
  • Conclusões O senso comum é de pensar que Scrum se torna impraticável neste cenário
  • Conclusões Scrum é centrado na comunicação Espírito de equipe Confiança Transparência
  • Tudo que uma equipe distribuída PRECISA Transparência Confiança Espírito de equipe Comunicação
  • Rafael Prikladnicki [email_address] twitter.com/rafaelpri www.inf.pucrs.br/~rafael Muito obrigado!