Guia Scrum | 13. Equipe de Desenvolvimento em Scrum

Um Time de Desenvolvimento em Scrum é um grupo interdisciplinar formado por todas as pessoas envolvidas na criação de um Produto. No artigo de hoje, veremos quais características ele deve ter. Também consideraremos a composição e responsabilidades de uma Equipe de Desenvolvimento que seja capaz de atingir efetivamente seus Objetivos.

Equipe de Desenvolvimento em Scrum – índice:

1. Recursos da equipe de desenvolvimento
2. Equipe de desenvolvimento
3. Responsabilidades da equipe de desenvolvimento
4. Resumo

Recursos da equipe de desenvolvimento

A equipe de desenvolvimento trabalhando de acordo com os princípios do Scrum é um grupo independente de especialistas. Não conta com o apoio de especialistas externos ou subcontratados. Mas o que determina que a Equipe esteja bem ajustada para cumprir a Meta? E quais responsabilidades estão incluídas nas tarefas de um Time de Desenvolvimento – independentemente de sua especialização?

Para ser eficaz, uma Equipe de Desenvolvimento deve ter pelo menos três características: capacidade de auto-organização, vontade de crescer e interdisciplinaridade.

Auto-organização

Quando falamos do Time Scrum, do qual o Time de Desenvolvimento faz parte, usamos o termo “autogestão”. Significa autogestão no nível da organização. O Time Scrum como um todo decide não apenas quem fará o trabalho e como, mas também no que eles irão trabalhar. Em um Time Scrum, grande parte das tarefas de gerenciamento pertence ao Product Owner e ao Scrum Master.

Portanto, no caso de um Time de Desenvolvimento, a auto-organização é mais importante do que a autogestão. Refere-se a responsabilidades de planejamento, ou seja, decidir por si mesmo quem irá realizar determinadas tarefas, quando e como.

A busca pelo desenvolvimento

Uma característica fundamental de uma equipe eficaz é o impulso para o crescimento. A forma de completar as tarefas que lhe foram propostas deve ser ambiciosa. Isso resulta não apenas das predisposições e atitudes individuais de cada membro do Time de Desenvolvimento. O aumento da competência e do esforço também é incentivado pelo ambiente da Equipa, que a define como um todo.

Interdisciplinaridade

A interdisciplinaridade da equipe significa que seus membros juntos devem ter todas as habilidades necessárias para criar incrementos valiosos em cada Sprint. Isso também significa que cada membro do Time executa as tarefas necessárias para aquele Sprint. Todos fazem o que é necessário para atingir a Meta. Mesmo que isso signifique assumir novas tarefas além da experiência do Desenvolvedor. É um erro ater-se rigidamente às próprias competências ou funções profissionais.

Equipe de desenvolvimento

De acordo com o Scrum Guide, o número máximo de desenvolvedores é oito. Uma composição tão pequena incentiva a comunicação e a abertura, pois os membros da equipe têm a oportunidade de se conhecer. No entanto, a equipe não deve ser menor que três pessoas. Ele precisa ser grande o suficiente para tornar o progresso do negócio visível em cada Sprint.

Desenvolvedores dentro do Scrum são chamados de pessoas com uma ampla variedade de habilidades e responsabilidades. Em nenhum caso o nome é reservado para pessoas que fazem programação. Assim, a Equipe pode incluir programadores e designers, pesquisadores e analistas, testadores e cientistas, além de outros especialistas.

Não há hierarquia entre os Desenvolvedores. É por isso que eles não usam títulos profissionais ou científicos.

Uma suposição importante sobre a composição da equipe de Desenvolvimento é que ela é uma unidade. Portanto, equipes menores trabalhando em outros Objetivos não devem ser dissociadas.

Responsabilidades da equipe de desenvolvimento

As responsabilidades do Time de Desenvolvimento podem ser divididas em três áreas. Estes são:

• Tarefas de planejamento
• Trabalhando no produto
• Melhorar a colaboração dentro da equipe

Tarefas de planejamento

O agendamento de tarefas é uma obrigação que todas as equipes de desenvolvimento baseadas em Scrum têm que cumprir. Consiste em criar um plano de Sprint e colocá-lo em um Sprint Backlog, que descreveremos em um artigo separado. O mais significativo é que a equipe de desenvolvimento trabalha nisso em conjunto. Dessa forma, cada um dos Desenvolvedores poderá determinar de forma realista o número de tarefas a serem realizadas em um determinado Sprint. A longo prazo, isso permite que a equipe mantenha um ritmo constante e planeje com mais precisão.

É igualmente fundamental estar atento ao pulso, ou seja, ajustar o plano à realidade diariamente. Se surgirem problemas, pode ser necessário mudar: reorganizar as tarefas, distribuir o trabalho de forma diferente ou conversar com o Scrum Master sobre as dificuldades emergentes.

Trabalhando no produto

As formas de trabalhar em um Produto podem variar drasticamente dependendo da área em que uma determinada Equipe de Desenvolvimento atua. De um modo geral, o objetivo a ser alcançado em cada Sprint é criar um Incremento, ou seja, uma característica do Produto com valor para o negócio.

É útil aqui falar diretamente e aplicar a seguinte regra:

Quando você realiza um trabalho em um Produto, você deve deixá-lo em um estado que não seja apenas melhorado, mas não menos finalizado do que a versão anterior.

A aplicação deste princípio significa que a Equipe como um todo assume a responsabilidade pelo Incremento. Se um Desenvolvedor realizar tarefas de forma descuidada, causando a deterioração da qualidade do Produto, outra pessoa terá que fazer o trabalho por ele. Por outro lado, se algum Desenvolvedor encontrar bugs no Produto, ele mesmo deve corrigi-los ou passar as informações do bug para alguém que possa fazê-lo. Escreveremos mais sobre como trabalhar no incremento de produto em um Sprint em um artigo separado.

Melhorar a colaboração na equipe

Trabalhar na maneira como a equipe opera é melhorar constantemente a eficiência e a eficácia de cada Desenvolvedor.

No entanto, é também, ou talvez acima de tudo, um trabalho de comunicação entre Desenvolvedores. A melhoria consiste em elaborar soluções que possibilitem uma divisão de tarefas eficiente e precisa. E também praticando habilidades:

• criticar soluções, não pessoas – mudar a linguagem que usamos para descrever o trabalho leva a uma mudança de atitude e melhor colaboração
• distanciar-se de suas ideias – permite humor e feedback mais honesto
• construindo confiança – graças à confiança, pode haver muito mais ideias inovadoras propostas pelos Desenvolvedores sem medo da reação negativa do ambiente

A melhoria da colaboração da equipe é alcançada por meio da reflexão contínua sobre como a equipe funciona e do fornecimento de feedback durante os eventos Scrum descritos neste artigo.

Resumo

No artigo de hoje apresentamos as características, composição e responsabilidades de um Time de Desenvolvimento Scrum. A interdisciplinaridade, a auto-organização e o desejo de desenvolvimento caracterizam essa pequena equipe. E a melhoria contínua do trabalho em equipe e o trabalho efetivo no Produto – essas são as tarefas que toda Equipe de Desenvolvimento deve cumprir.

Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube.

Autor: Caroline Becker

Como Gerente de Projetos, Caroline é especialista em encontrar novos métodos para projetar os melhores fluxos de trabalho e otimizar processos. Suas habilidades organizacionais e capacidade de trabalhar sob pressão de tempo fazem dela a melhor pessoa para transformar projetos complicados em realidade.

Ver todas as postagens

Guia do Scrum:

1. Glossário de termos básicos, funções e noções
2. O que é Scrum?
3. Valores do Scrum
4. Como implementar o Scrum na sua empresa?
5. Time Scrum - o que é e como funciona?
6. Quem é um Product Owner?
7. Os erros mais comuns do Product Owner
8. Quem é o Scrum Master?
9. Características de um bom Scrum Master
10. Os erros mais comuns do Scrum Master
11. Quais estatísticas e métricas o Scrum Master deve acompanhar?
12. Cooperação entre Product Owner e Scrum Master
13. Equipe de Desenvolvimento em Scrum
14. Os erros mais comuns dos desenvolvedores
15. Artefatos do Scrum
16. Escalando Scrum
17. Backlog da Sprint
18. O que é o Backlog do Produto?
19. O que são histórias de usuários?
20. Criando a melhor história de usuário com INVEST
21. Os erros mais comuns da história do usuário
22. Critérios de aceitação da história do usuário
23. Estimativa e pontos de história no Scrum
24. Poker de Planejamento
25. Jogo de estimativa de equipe
26. Definindo Incremento
27. Eventos Scrum
28. O que é Sprint no Scrum?
29. Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
30. O que é um gráfico Burndown?
31. Como criar e interpretar um gráfico de burndown?
32. Vantagens e desvantagens do gráfico de burndown
33. Quadros Kanban em Scrum e Scrumban
34. Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
35. Reunião diária
36. Planejamento de Sprint
37. Revisão da Sprint
38. O que é uma Sprint Retrospective?
39. Erros comuns durante uma Sprint Retrospective
40. Nutrição do Backlog do Produto