View
114
Download
2
Category
Preview:
Citation preview
www.scrumhalf.com.br
Times Scrum – Scrum Guide
O Time Scrum é composto pelo Product Owner, o Time de Desenvolvimento e o Scrum Master.
Times Scrum são auto-organizáveis e multifuncionais.
www.scrumhalf.com.br
Papéis – By the Book • P.O.
– Responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos.
• Scrum Master – O Scrum Master é responsável por garantir que o Scrum seja entendido e
aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o Time Scrum.
• Dev Team – Consiste de profissionais que realizam o trabalho de entregar uma versão
usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.
www.scrumhalf.com.br
Times – Uma Visão Qualitativa• Times auto-organizáveis escolhem qual a melhor
forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora do Time.
• Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe.
• O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade.
www.scrumhalf.com.br
Times – Uma Visão Quantitativa
• “O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da Sprint. “
• Número Mágico
www.scrumhalf.com.br
• Dono do Produto ( P.O. –Product Owner) – Define o que deve ser feito
• Scrum Master – Garante o funcionamento
do SCRUM
• Equipe (Dev Team)– Multidisciplinar
– Trabalha no desenvolvimento do produto
SCRUM – Participantes
www.scrumhalf.com.br
Times – Uma Taxonomia
• Times de Backlog
• Times de Componentes
• Times de Features
www.scrumhalf.com.br
Times de Backlog• Principal foco é “matar”o Sprint Backlog • Processo fica mecânico, automatizado• Sprint planning é um resultado da última Sprint
somente• Falta visão do produto e um plano estratégico de
entregas• Atingem rapidamente um teto de velocidade e
estabilizam• Not fun…
www.scrumhalf.com.br
Time de Componente• Times muito direcionados para o lado técnico• Operam sob a influência de líderes técnicos• Foco é em um componente da solução• Tudo fica orientado ao conhecimento e a expertise
sobre o componente e a tecnologia• Sprint Planning dominado por um membro “senior”
ou expert da equipe• Velocidade do time cai e o entusiasmo acaba• Membros do time aguardam definições ao invés de
colaborarem – falta empoderamento
www.scrumhalf.com.br
Time de Features
• Preocupação do time é com as característicasdo produto
• Visão do Produto e Planejamento Estratégicode Releases orientam o Backlog
• Todos os membros do time colaboram –motivados
• O foco é sempre adicionar valor às features
www.scrumhalf.com.br
Sugestões
• Retrospectivas são uma oportunidade para entender o seu time
• Pense em usar ferramentas visuais para osplanejamentos de nível mais alto
• Busque sempre a melhoria continua. Evite a estabilidade
• Crie a cultura de Features. Assim deve serorientado o pensamento do time.
www.scrumhalf.com.br
• Estudantes
universitários
• Equipes completando
tarefas diversas
• Melhor aceitação 4-5
ASA Study
www.scrumhalf.com.br
• 35K-90K SLOC
• Projetos agrupados portamanho das equipes
• Distribuição uniforme de tamanho equipe x tamanho de projetos
• Em media, gruposmenores gastaram menostempo (12 meses x 17 meses)
Small is Beatiful
www.scrumhalf.com.br
• Estudo de Larry
Macherone
• Dados de softwares de
gestão ágil
Agile Performance
www.scrumhalf.com.br
Sugestões• Realmente Small is Beatiful… Mas não muito small…
• Número mágico ainda vale
• Maior, mais problemas de comunicação e coordenação
• Menor, sujeito a intempéries. Melhor sempre mais de um cobrindo algo.
• Invista na formação do time – atividades extra também são importantes
• Estabeleça metas claras
www.scrumhalf.com.br
Caindo na Real…
• Nossos times costumam ser pequenos
• Multifuncional nem sempre é real
• Domínio do Scrum não é absoluto
• Complexidade da coordenação diminui a agilidade
• Leva tempo formar time de alta performance – mínimo 6 meses
www.scrumhalf.com.br
Referências • What Type of Scrum Teams Do You Have? - Greg Tutunjian -
https://www.linkedin.com/pulse/what-type-scrum-teams-do-you-have-greg em 13/09/2016
• Choosing the Team Size in Scrum – Mark Levison –https://agilepainrelief.com/notesfromatooluser/2016/10/choosing-the-team-size-in-scrum.html - 10/10/2016
• Familiar Metric Management - Small is Beautiful-Once Again –Lawrence H. Putnam and Ware Myers -http://www.qsm.com/fmm_28.pdf
• Five Steps for Creating High Performance Teams – Ben Waber -https://agilepainrelief.com/high-performance-teams
• ScrumHalf Agile Manager – http://www.scrumhalf.com.br
Recommended