Scrum com Equipes Distribuidas

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

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?

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)

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

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
1. Daily Scrum através de documentação
Menos efetivo
Responder as três perguntas em um e-mail, wiki, etc

Desenvolvimento
2. Ter um liaison
Planejar duas reuniões tendo uma pessoa em comum participando das duas

Desenvolvimento
3. Alternar horários das reuniões
As reuniões ocorrem em horários alternados de trabalho de cada equipe

Desenvolvimento
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!

Scrum com Equipes Distribuidas

by rafapri on Jul 01, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 1

Statistics

Scrum com Equipes Distribuidas — Presentation Transcript