Scrum com Equipes Distribuidas

3,774 views

Published on

0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,774
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
12
Embeds 0
No embeds

No notes for slide
  • 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

    1. 1. Scrum com Equipes Distribuídas Rafael Prikladnicki [email_address] twitter.com/rafaelpri www.inf.pucrs.br/~rafael
    2. 2. 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
    3. 3. “ Trabalhamos enquanto você trabalha” “ Trabalhamos enquanto você está dormindo” ?
    4. 4. 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
    5. 6. Não use metodologias ágeis!
    6. 7. Não use Scrum
    7. 8. Não trabalhe com equipes distribuídas
    8. 9. Apenas se você tiver um motivo !
    9. 10. O que estes videos têm em comum ?
    10. 11. Interesse por Scrum
    11. 12. Interesse por Scrum EUA BR 2 anos!
    12. 13. Interesse por Scrum
    13. 14. Interesse por Scrum
    14. 15. Offshore services no Brasil Fonte: BRASSCOM/IDC (2009)
    15. 16. Por que DDS? Por que métodos ágeis Por que Scrum?
    16. 17. Métodos Ágeis É uma febre passageira ? É o início de uma mudança na forma de trabalho
    17. 18. DDS é um modelo que se paga? Se as empresas souberem usar
    18. 19. Globalização Desenvolvimento de software <ul><li>Crescimento acentuado desde a década de 90 </li></ul><ul><li>Oportunidades de negócio </li></ul><ul><ul><li>Recursos globais disponíveis (habilidades e custo) </li></ul></ul><ul><ul><li>Proximidade ao mercado local e aos clientes </li></ul></ul><ul><ul><li>Benefícios a partir das oportunidades globais de mercado </li></ul></ul><ul><ul><li>Exploração do desenvolvimento “round-the-clock” </li></ul></ul><ul><li>Inovação! </li></ul>
    19. 20. Desenvolvimento Distribuído de Software <ul><li>Não é um fenômeno novo </li></ul><ul><li>Outras áreas do conhecimento já se envolvem em atividades com equipes distribuídas há muito tempo </li></ul><ul><ul><li>Em desenvolvimento de software é recente </li></ul></ul>
    20. 21. 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
    21. 22. Outsourcing Atividade desenvolvida e gerenciada por um terceiro dentro ou fora das instalações do contratante
    22. 23. Onsite No local do contratante Onshore No país do contratante Offshore Fora do país do contratante
    23. 24. Offshore outsourcing Outsourcing em outro país Offshore insourcing Outsourcing em outro país desenvolvimento interno
    24. 25. 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
    25. 26. Motivação para DDS EUA BRASIL RÚSSIA ÍNDIA
    26. 27. Separação física desafios <ul><ul><li>Grande parte do desenvolvimento é baseado em comunicação entre pessoas (Philippe Kruchten) </li></ul></ul><ul><ul><li>Dificuldades em comunicação, coordenação e gerenciamento </li></ul></ul><ul><ul><li>Questões estratégicas </li></ul></ul><ul><ul><li>Questões culturais </li></ul></ul><ul><ul><li>Comunicação inadequada </li></ul></ul><ul><ul><li>Gestão do conhecimento </li></ul></ul><ul><ul><li>Gestão do projeto e do processo </li></ul></ul><ul><ul><li>Dificuldades técnicas </li></ul></ul>
    27. 28. <ul><li>Por que DDS é importante para o Brasil? </li></ul><ul><li>O Brasil está entre os principais países de Up and Comming no que diz respeito ao DDS </li></ul><ul><li>Por que DDS é importante para outros países? </li></ul><ul><li>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) </li></ul>Importância
    28. 29. Características <ul><li>Área recente </li></ul><ul><li>Conversão de mercados nacionais em mercados globais </li></ul><ul><ul><li>Necessidade de ter recursos globais </li></ul></ul><ul><ul><li>Vantagens de estar perto do mercado local </li></ul></ul><ul><li>Demanda e custos </li></ul><ul><li>Sinergia cultural </li></ul><ul><li>Mercado global </li></ul><ul><li>Time-to-market </li></ul><ul><li>Rigor e experiência </li></ul><ul><li>Escala </li></ul>
    29. 30. Mudança de contexto Gestor Mesma localização física
    30. 31. Mudança de contexto Gerente de Projeto Mesma localização física Gestor Matriz Outro país Outra cidade
    31. 32. Forças centrífugas e centrípetas
    32. 33. 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
    33. 34. Principais desafios <ul><ul><li>Aspectos técnicos </li></ul></ul><ul><ul><li>Aspectos comportamentais </li></ul></ul><ul><ul><li>Aspectos linguísticos </li></ul></ul><ul><ul><li>Aspectos culturais </li></ul></ul><ul><ul><li>Aspectos políticos </li></ul></ul><ul><ul><li>Aspectos geográficos </li></ul></ul><ul><ul><li>Aspectos financeiros </li></ul></ul>F2F ou falar ao telefone? Rica comunicação F2F
    34. 35. 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
    35. 36. 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
    36. 37. Questões culturais <ul><li>Princípios </li></ul><ul><li>Valores </li></ul><ul><li>Crenças </li></ul><ul><li>Comportamentos </li></ul><ul><li>Ética </li></ul><ul><li>Maneiras </li></ul><ul><li>Ideologias </li></ul><ul><li>Bom vs. Mau </li></ul><ul><li>Folclore </li></ul><ul><li>Gestos </li></ul><ul><li>Palavras </li></ul><ul><li>Tons de voz </li></ul><ul><li>Contato </li></ul>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!!!
    37. 38. 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
    38. 39. Gestão do conhecimento <ul><li>Compartilhar informação entre os projetos </li></ul><ul><li>Abordagem de Evaristo </li></ul><ul><ul><li>Conhecimento from , about , e in projects </li></ul></ul><ul><li>Prioridades, mudanças, decisões, falhas </li></ul><ul><li>Dificuldade de manter a documentação do projeto atualizada, causando desconforto e falta de informação (colaboração ineficiente) </li></ul><ul><li>Sensação de perda da possibilidade de incentivar a reutilização (de código, de planejamento, etc.) </li></ul>
    39. 40. 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
    40. 41. Dificuldades técnicas [Damian et al., 2002]
    41. 42. Dificuldades técnicas [Karolak, 1998]
    42. 43. E o Scrum?
    43. 44. E o Scrum?
    44. 45. Níveis de distribuição
    45. 46. Níveis de distribuição <ul><li>Collocated </li></ul><ul><ul><li>Todos os integrantes da equipe estão no mesmo local </li></ul></ul><ul><ul><li>Este tipo de equipe tem se tornado cada vez mais raro no desenvolvimento de software </li></ul></ul><ul><li>Collocated part-time </li></ul><ul><ul><li>Os integrantes geralmente estão no mesmo local, com alguns integrantes ocasionalmente trabalhando de forma distribuída </li></ul></ul><ul><ul><li>Vivenciam alguns desafios das equipes distribuídas </li></ul></ul><ul><ul><li>Geralmente estão no mesmo fuso-horário </li></ul></ul><ul><ul><li>Fácil de se reunir se for necessário </li></ul></ul><ul><ul><li>Scrum meetings and daily scrums são mais difíceis dependendo de onde estão os colaboradores distribuídos </li></ul></ul><ul><ul><li>Alguns desafios já começam a surgir ( daily meeting executado com teleconferência) </li></ul></ul>
    46. 47. Níveis de distribuição <ul><li>Distributed with overlapping hours </li></ul><ul><ul><li>Os colaboradores distribuídos possuem algumas horas do dia para interagir </li></ul></ul><ul><ul><li>Exemplo: 5 pessoas na Europa e 3 na Índia (3,5 horas em comum) </li></ul></ul><ul><ul><li>Daily scrum é mais difícil </li></ul></ul><ul><ul><li>Sprint planning é ainda mais difícil (qual é o melhor horário?) </li></ul></ul><ul><li>Distributed with no overlapping hours </li></ul><ul><ul><li>Colaboradores não interagem durante o horário de trabalho </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>As empresas evitam este tipo de organização, principalmente para equipes de alto desempenho </li></ul></ul><ul><ul><li>Manter a dinâmica de equipe é chave para o uso do Scrum com sucesso </li></ul></ul><ul><ul><li>É difícil trabalhar com Scrum neste cenário, mas não impossível </li></ul></ul>
    47. 48. <ul><li>Se é tão difícil, por que trabalhar com equipes distribuídas ? </li></ul>
    48. 49. Por que DDS e Scrum <ul><li>Os métodos ágeis surgiram na década de 1990 </li></ul><ul><li>Deste então o négocio envolvendo desenvolvimento de software mudou radicalmente </li></ul><ul><li>O desenvolvimento de software se tornou uma atividade distribuída </li></ul><ul><li>Não existem fronteiras para as empresas </li></ul><ul><li>Internet e tecnologia de comunicação reduzem distâncias </li></ul><ul><li>Redução de custos </li></ul><ul><li>Follow the sun </li></ul><ul><li>Acesso à novos mercados </li></ul><ul><li>Aquisição de empresas </li></ul><ul><li>Inovação global </li></ul><ul><li>Ferramentas de colaboração </li></ul><ul><ul><li>IBM Rational Team Concert – Jazz </li></ul></ul>
    49. 50. Isolated Scrum <ul><li>Cada local possui uma equipe Scrum multidisciplinar </li></ul><ul><li>As equipes são independentes </li></ul><ul><li>Não há necessidade de colaboração </li></ul><ul><li>Cenário ideal, pois as equipes trabalham nos dois primeiros níveis de distribuição </li></ul><ul><li>Quanto mais a equipe conseguir ficar nos dois primeiros níveis, maior será a chance de sucesso </li></ul><ul><li>Equipes em 5 países? Tentar criar equipes independentes em cada local </li></ul><ul><li>E se não existirem as habilidades necessárias para formar a equipe em um único local ? Distribuir as equipes </li></ul>
    50. 51. Distributed Scrum of Scrums <ul><li>Cada local possui uma equipe Scrum multidisciplinar </li></ul><ul><li>Reuniões de Scrum of Scrums de forma periódica para coordenar esforços entre as equipes </li></ul><ul><li>Adaptação da reunião para Scrum of Scrums </li></ul><ul><ul><li>O que sua equipe fez no período anterior? </li></ul></ul><ul><ul><li>O que sua equipe vai fazer no próximo período? </li></ul></ul><ul><ul><li>Quais são os impedimentos da equipe? </li></ul></ul><ul><ul><li>Quais são os impedimentos da tua equipe que podem comprometer outra equipe? </li></ul></ul><ul><li>O dono do produto precisa coordenar o trabalho de múltiplas equipes (no cenário anterior cada equipe possuia um dono de produto) </li></ul>
    51. 52. Totally integrated Scrums <ul><li>Cada equipe possui integrantes em diversos locais </li></ul><ul><li>Este cenário geralmente entra no terceiro e quarto níveis de distribuição </li></ul><ul><li>Geralmente o idioma nativo de um local não é o idioma da equipe </li></ul><ul><li>Mais dificuldades em todos os sentidos </li></ul><ul><li>Adaptação da reunião para Scrum of Scrums </li></ul>
    52. 53. Planejamento e preparação <ul><li>Product Owner e Cliente </li></ul><ul><li>Visão do produto </li></ul><ul><li>Criação do product backlog, user stories </li></ul><ul><li>Surveys, reuniões </li></ul><ul><li>Uso de ferramentas colaborativas </li></ul>
    53. 54. Quantos product owners <ul><li>Como coordenar diversos Product Owners </li></ul><ul><ul><li>Trabalhar com hierarquia </li></ul></ul>
    54. 55. Quantos product backlogs <ul><li>Equipes Scrum tradicionais geralmente possuem um backlog </li></ul><ul><li>Para equipes distribuídas é necessário avaliar os desafios </li></ul><ul><ul><li>Avaliar se é possível ter uma reunião de sprint planning com a equipe inteira participando </li></ul></ul><ul><ul><li>Avaliar a possibilidade de dividir uma parte do backlog para cada equipe distribuída </li></ul></ul>
    55. 56. Quantos product backlogs
    56. 57. Quantos product backlogs
    57. 58. Quantos product backlogs
    58. 59. Quantos product backlogs
    59. 60. Desenvolvimento <ul><li>Product Owner , ScrumMaster e Equipe </li></ul><ul><li>Análise e organização do Product Backlog </li></ul><ul><ul><li>Refinamento das funcionalidades </li></ul></ul><ul><ul><li>Estimativas </li></ul></ul><ul><ul><li>Escolha das funcionalidades para o sprint </li></ul></ul><ul><ul><li>Formalização do sprint backlog </li></ul></ul><ul><ul><li>Identificação das tarefas </li></ul></ul><ul><ul><li>Organização da taskboard </li></ul></ul>
    60. 61. Desenvolvimento <ul><li>Como priorizar os itens do backlog? </li></ul><ul><li>Como estimar tamanho das user stories ? </li></ul><ul><ul><li>Usar ferramentas de bate-papo </li></ul></ul><ul><ul><li>Usar ferramentas web do tipo www.planningpoker.com </li></ul></ul><ul><li>Como definir o que será desenvolvido em cada sprint ? </li></ul><ul><ul><li>O planejamento dos primeiros sprints geralmente demoram mais </li></ul></ul><ul><ul><li>Usar a técnica do “ lookahead” planning, do Mike Cohn </li></ul></ul><ul><ul><li>Considerar feriados locais, horário de trabalho em cada país </li></ul></ul>
    61. 62. Desenvolvimento <ul><li>Planejar para que as equipes fiquem no nível de distribuição mais simples possível </li></ul><ul><li>Tentar sempre criar equipes collocated e multidisciplinares </li></ul><ul><li>Se não for possível, criar equipes multidisciplinares, no mesmo fuso horário </li></ul><ul><li>Somente se isto não for possível, aceitar que a única solução é criar equipes distribuídas e com diversos fusos-horários </li></ul>
    62. 63. Desenvolvimento <ul><li>Como fazer o planejamento das sprints </li></ul><ul><ul><li>Abordagem Full team </li></ul></ul><ul><ul><li>Abordagem Preplanning team </li></ul></ul><ul><ul><li>Abordagem Balanced team </li></ul></ul><ul><ul><li>Ter todos os integrantes de uma equipe distribuída em uma reunião de planejamento de sprint é irreal </li></ul></ul><ul><ul><li>As abordagens devem ser combinadas </li></ul></ul><ul><ul><li>Abordagens Preplanning e Balanced são adequadas para equipes distribuídas </li></ul></ul>
    63. 64. Desenvolvimento <ul><li>ScrumMaster e Equipe </li></ul><ul><li>Dia-a-dia do SCRUM </li></ul><ul><ul><li>Sprint </li></ul></ul><ul><ul><ul><li>2 semanas a 4 semanas </li></ul></ul></ul><ul><ul><li>Daily meetings (Daily Scrum) </li></ul></ul><ul><ul><li>Impedimentos </li></ul></ul><ul><ul><ul><li>Obstáculos ao trabalho da equipe </li></ul></ul></ul><ul><ul><li>Manter a taskboard </li></ul></ul><ul><ul><ul><li>Burndown </li></ul></ul></ul><ul><ul><ul><li>Tarefas e estimativas </li></ul></ul></ul><ul><ul><ul><li>Tarefas não-planejadas </li></ul></ul></ul>
    64. 65. Desenvolvimento <ul><li>E quando não houver horário em comum? </li></ul><ul><ul><li>1. Daily Scrum através de documentação </li></ul></ul><ul><ul><li>2. Ter um liaison </li></ul></ul><ul><ul><li>3. Alternar horários das reuniões </li></ul></ul><ul><ul><li>4. Compartilhar as dificuldades </li></ul></ul><ul><ul><li>5. Usar ferramentas de bate-papo </li></ul></ul><ul><ul><ul><li>Esta geralmente é utilizada quando existe intersecção de horários </li></ul></ul></ul>
    65. 66. Desenvolvimento <ul><li>Daily meetings (Daily Scrum) </li></ul><ul><ul><li>1. Daily Scrum através de documentação </li></ul></ul><ul><ul><ul><li>Menos efetivo </li></ul></ul></ul><ul><ul><ul><li>Responder as três perguntas em um e-mail, wiki, etc </li></ul></ul></ul>
    66. 67. Desenvolvimento <ul><li>Daily meetings (Daily Scrum) </li></ul><ul><ul><li>2. Ter um liaison </li></ul></ul><ul><ul><ul><li>Planejar duas reuniões tendo uma pessoa em comum participando das duas </li></ul></ul></ul>
    67. 68. Desenvolvimento <ul><li>Daily meetings (Daily Scrum) </li></ul><ul><ul><li>3. Alternar horários das reuniões </li></ul></ul><ul><ul><ul><li>As reuniões ocorrem em horários alternados de trabalho de cada equipe </li></ul></ul></ul>
    68. 69. Desenvolvimento <ul><li>Daily meetings (Daily Scrum) </li></ul><ul><ul><li>4. Compartilhar as dificuldades </li></ul></ul><ul><ul><ul><li>Escolher o melhor horário de forma democrática, respondendo 3 perguntas: </li></ul></ul></ul><ul><ul><ul><ul><li>Quais são os melhores horários para você se reunir com a equipe? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Quais são os horários em que você se reuniria com a equipe? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Quais são os horário em que você não se reuniria com a equipe? </li></ul></ul></ul></ul><ul><ul><ul><li>Espírito de equipe </li></ul></ul></ul><ul><ul><ul><li>Transparência e confiança </li></ul></ul></ul><ul><ul><ul><li>Nem todos consideram esta possibilidade </li></ul></ul></ul><ul><ul><li>5. Usar ferramentas de bate-papo </li></ul></ul><ul><ul><ul><li>Funciona com todos os tipos de distribuição, exceto quando não existe intersecção de horários </li></ul></ul></ul><ul><ul><ul><li>Pode ser caótico se não houver uma boa condução da reunião </li></ul></ul></ul><ul><ul><ul><li>Mesmas dificuldades enfrentadas em qualquer configuração de equipe </li></ul></ul></ul>
    69. 70. Desenvolvimento
    70. 71. Sprint review e retrospectiva <ul><li>Discussão </li></ul><ul><ul><li>Como fazer sprint review com equipes distribuídas? </li></ul></ul><ul><ul><li>Como conduzir sessões de retrospectiva com equipes distribuídas? </li></ul></ul>
    71. 72. DDS é uma realidade Assim como métodos ágeis Conclusões Assim como Scrum
    72. 73. Conclusões Scrum é um dos métodos ágeis mais utilizados atualmente
    73. 74. Conclusões Equipes distribuídas possuem diversas dificuldades. e desafios
    74. 75. Conclusões O senso comum é de pensar que Scrum se torna impraticável neste cenário
    75. 76. Conclusões Scrum é centrado na comunicação Espírito de equipe Confiança Transparência
    76. 77. Tudo que uma equipe distribuída PRECISA Transparência Confiança Espírito de equipe Comunicação
    77. 78. Rafael Prikladnicki [email_address] twitter.com/rafaelpri www.inf.pucrs.br/~rafael Muito obrigado!

    ×