1. Overview
  2. Estrutura
  3. Equipes de Funcionalidades

Equipes de Funcionalidades

Uma equipe de funcionliddes, mostrada na Figura 1, é uma equipe de longa duração, multifuncional, de componentes cruzados quem completam muitas funcionalidades de ponta a ponta, uma a uma.

As características de uma equipe de funcionalidades estão listadas abaixo:

  • Duradoura - a equipe permanece junto para que ela possa amadurecer para ter um maior desempenho; Ela assume novas funcionalidades ao longo do tempo
  • multifuncional e multicomponente
  • Idealmente, co-localizada
  • Trabalhar em uma completa funcionalidade centrada no cliente, através de todos os componentes e disciplinas (análise, programação, testes, …)
  • Composta de especialistas generalistas
  • No Scrum, tipicamente 7 ± 2 pessoas

Aplicar as modernas práticas de engenharia - especialmente a integração contínua - é essencial ao adotar equipes de funcionalidades. A integração contínua facilita a propriedade compartilhada do código, o que é uma necessidade quando várias equipes trabalham ao mesmo tempo nos mesmos componentes.

Um mal-entendido comum: cada membro de uma equipe de funcionalidade precisa conhecer todo o sistema. Não é assim, porque

  • A equipe como um todo - e não cada membro individual - requer as habilidades para implementar toda a funcionalidade centrada no cliente. Estas incluem conhecimento de componentes e habilidades funcionais como teste, design de interação ou programação. Mas dentro da equipe, as pessoas ainda se especializam … preferencialmente em várias áreas.
  • As funcionalidades não são distribuídas aleatoriamente entre as equipes de funcionalidades. O conhecimento e as habilidades atuais de uma equipe são fatorados na decisão de qual equipe trabalha em quais funcionalidades.

Dentro de uma organização com equipe de funcionalidades, quando a especialização se torna uma restrição … o aprendizado acontece.

Uma organização de equipe de funcionalidades explora os benefícios de velocidade da especialização, desde que os requisitos mapeiem as habilidades das equipes.
Mas quando os requisitos não mapeiam as habilidades das equipes, o aprendizado é “forçado”, rompendo a restrição de superespecialização.
As equipes de funcionalidades equilibram a especialização e flexibilidade.

Equipes de componente vs. equipes de funcionalidades

A tabela abaixo e a Figura 2 mostram as diferenças entre equipes de funcionalidades e equipes de componentes mais tradicionais.

equipe de componente equipe de funcionalidade
Otimizada para fornecer o número máximo de linhas de código Otimizada para fornecer o valor máximo do cliente
Foco no aumento da produtividade individual através da implementação de funcionalidades “fáceis” de baixo valor Foco em funcionalidades de alto valor e produtividade do sistema
Responsável por apenas parte de um funcionalidade centrada no cliente Responsável pela funcionalidade completa centrada no cliente
Maneira tradicional de organizar equipes - segue a lei de Conway Maneira “moderna” de organizar equipes - evita a lei de Conway
Conduz a um trabalho “inventado” e a uma organização que cresce para sempre Leva ao foco no cliente, à visibilidade e às organizações menores
Dependências entre equipes leva a um planejamento adicional Minimiza dependências entre equipes para aumentar a flexibilidade
Foco em especialização única Foco em múltiplas especializações
Propriedade de código individual / equipe Propriedade do código do produto compartilhado
Responsabilidades individuais claras Responsabilidades compartilhadas da equipe
Resulta em desenvolvimento “cascata” Suporta desenvolvimento iterativo
Explora as competências existentes; Nível mais baixo de aprendizado de novas competências Aproveita a flexibilidade; Aprendizado contínuo e abrangente
Funciona com práticas de engenharia desleixadas - os efeitos são localizados Requer práticas de engenharia qualificadas - os efeitos são amplamente visíveis
Ao contrário do que se acredita, muitas vezes leva a código de baixa qualidade no componente Fornece uma motivação para tornar o código fácil de manter e testar
Aparentemente fácil de implementar Aparentemente difícil de implementar

A tabela abaixo resume as diferenças entre as equipes de funcionalidades e os grupos convencionais de projetos ou funcionalidades.

equipe de funcionalidade gruposde projetos ou funcionalidades
Equipe estável que permanece junta por anos e trabalha em muitas funcionalidades Grupo temporário de pessoas criado para uma funcionalidade ou projeto
Responsabilidade compartilhada da equipe para todo o trabalho Responsabilidade individual pela “sua” parte baseada na especialização
Equipa de auto-organização Controlado por um gestor de projeto
Resulta em uma organização simples de uma única linha (sem matriz!) Resulta em uma organização matriz com pools de recursos
Os membros da equipe são dedicados - 100% alocados - para a equipe Membros são part-time em muitos projetos por causa de especialização

A maior parte dos inconvenientes das equipes de componentes é explorada no capítulo “Equipes de Funcionalidades” do Scaling Lean & Agile Development, a Figura 3 resume algumas delas.

component_teams_waterfall.png
Figure 3. Some Drawbacks of Component Teams.

O que às vezes não é visto é que uma estrutura de equipe de componentes reforça o desenvolvimento sequencial (em cascata ou modelo V), com muitas filas com pacotes de trabalho de tamanhos variados, altos níveis de WIP, muitas transferências e aumento da multitarefa e alocação parcial.

Escolhendo equipes de componentes ou equipes de recursos?

Uma organização de equipe de funcionalidades pura é o ideal sob a perspectiva de entrega de valor e flexibilidade organizacional. Valor e flexibilidade, no entanto, não são os únicos critérios para a estrutura organizacional, e muitas organizações, portanto, acabam com um híbrido, especialmente durante uma transição de componente para equipes de funcionalidades. Cuidado: modelos híbridos têm as desvantagens de ambos os mundos e pode ser … doloroso.

Uma razão frequentemente expressa em favor de uma organização híbrida é a necessidade de construir infraestrutura, construir componentes reutilizáveis ​​ou limpar o código -trabalho tradicionalmente feito dentro de equipes de componentes. Mas essas atividades também podem ser feitas em uma organização de equipe de funcionalidades pura - sem estabelecer equipes permanentes de componentes. Como? Adicionando infraestrutura, componentes reutilizáveis ​​ou trabalho de limpeza ao Product Backlog e fornecendo-o a uma equipe de funcionalidades existente, como se fosse uma funcionalidade centrada no cliente. A equipe de funcionalidades temporariamente - enquanto o Product Owner desejar - faz esse trabalho e, em seguida, retorna à construção de funcionalidades centradas no cliente.

Transição para equipes de funcionalidades

Diferentes organizações requerem diferentes estratégias de transição ao mudar de equipes de componentes para equipes de funcionalidades. Temos experiência com muitas estratégias que funcionaram … e falharam em contextos diferentes. Uma estratégia segura, mas de transição lenta, é estabelecer uma equipe de funcionalidades dentro da organização em uma equipe de componentes existente. Depois que esta equipe executa bem, uma segunda equipe de funcionalidade é formada. Isso continua gradualmente na velocidade com a qual a organização se sente confortável. Isso é mostrado na Figura 4.

Leitura Recomendada