Qual é a melhor maneira de escalar e dividir uma equipe ágil criando um aplicativo da web?

Recentemente, ingressei em uma empresa em que estou trabalhando como scrum master em um projeto de desenvolvimento ágil que cria um aplicativo da web.

A equipe está prestes a ter o tamanho máximo para uma equipe ágil (espera 9 na próxima semana). Falamos sobre potencialmente dividir a equipe em duas equipes, não tanto para encurtar os standups (que não são excessivos no momento), mas para impedir que as pessoas fiquem completamente entediadas nas sessões de planejamento de sprint (que também não são excessivamente longas).

Existem duas camadas muito distintas no projeto - alto desenvolvimento técnico de back-end (como seriamente complexo) e design / construção / integração da interface do usuário. Parece que quando os caras de back-end estão falando sobre técnicas, os caras da interface do usuário se afastam e vice-versa. Parece que é a maneira lógica de dividir a equipe apenas para ser mais eficiente em termos de tempo, mas eu tenho uma reserva enorme de que tudo o que realmente posso fazer é reduzir a colaboração e o compartilhamento de conhecimento. As duas equipes simplesmente não terão uma boa idéia sobre o que o resto da equipe está construindo.

Alguém tem alguma experiência em lidar com algo assim?

É lamentável que os caras da interface do usuário não se importem com os detalhes do complexo trabalho de back-end. Isso soa mais como um tópico de discussão para uma retrospectiva. Dividir a equipe ao longo da disciplina criaria um precedente perigoso, quanto tempo levaria antes que o pessoal dos Requisitos começasse a zonear e não se importasse com o que os caras da interface do usuário estão fazendo e pedisse sua própria equipe.

Eu sempre fui a favor de fatias verticais para minhas equipes. A interface do usuário deve ouvir o que as pessoas técnicas têm a dizer, pois elas são as pessoas que poderiam ajudar a facilitar seu trabalho (oh, esse widget fará com que você faça isso, e se usássemos esse widget).

Pessoalmente, eu me concentraria na questão do pessoal da interface do usuário que zoneava primeiro e, depois que a disfunção fosse resolvida, discutisse a melhor forma de dividir as equipes. Não estou tentando difamar os caras da interface do usuário, talvez o pessoal técnico também possa fazer mais para tornar suas discussões mais relacionáveis ​​para os caras da interface do usuário.

Como outros já disseram, a equipe deve se auto-organizar para determinar a nova estrutura. As experiências passadas me ensinaram que a auto-organização só pode realmente funcionar quando todos estão preocupados com a equipe, e não com sua própria disciplina ou interesses.

Felicidades!

É realmente uma boa ideia dividir as partes independentes da equipe em novas equipes. Em projetos maiores, é quase impossível que os desenvolvedores estejam familiarizados com todo o projeto, portanto a divisão ainda está presente formal ou informal.

Cada uma das novas equipes deve ter um líder técnico / gerente técnico, que tenha um conhecimento sólido sobre o escopo da equipe e que também esteja familiarizado com o trabalho de outras equipes.

Depois disso, cada equipe pode ter reuniões de scrum separadas e os líderes das outras equipes podem estar presentes. Dessa forma, você reduzirá o número de pessoas "entediadas", mas ainda assim as equipes saberão no que os outros estão trabalhando e poderão colaborar com êxito.

A colaboração se torna mais importante se os escopos das equipes estão se cruzando ou se uma equipe depende da outra. Porém, novamente, não há necessidade de toda a equipe estar presente - o líder da equipe pode coordenar a colaboração.

Um aspecto fundamental do Scrum é auto-organizado .

Sugiro que você discuta a questão com a equipe e deixe que eles a resolvam.

Suas preocupações são bem fundamentadas, mas lembre-se de que, como Scrum Master, seu trabalho é treinar e facilitar. Então, pergunte-lhes como eles resolverão esses problemas. Eles possuirão as soluções e a farão funcionar.

Eu acrescentaria: em geral, equipes multifuncionais são o caminho a percorrer.

Ao dividir equipes, estou sempre tentando ter em mente o fato de que uma equipe precisa ser capaz de agregar valor ao cliente. No seu caso, haveria desenvolvedores de back-end e front-end na equipe.

1. A que distância está o front-end do back-end? Previsivelmente, a divisão é um bom conselho apenas se a distância for muito longa.

   • Se o back-end falar sobre o esquema do banco de dados, isso é não muito longe . O front-end e o back-end precisam ouvir discussões sobre o esquema do banco de dados.

   • Se o back-end falar sobre sharding, caches de memória, latência do disco etc., isso é um pouco longe demais (onde o back-end se concentra na simpatia e otimização mecânicas, enquanto o front-end se concentra na estética humana).

2. Existe uma interface de programação estável e inequívoca entre o front-end e o back-end?

   • Por estável e inequívoco, significa que os usuários dessa interface de programação (os desenvolvedores de front-end) não ficarão atolados com as alterações e não precisarão ler paredes de texto para aprender como usá-la corretamente.

   • A equipe de back-end precisa fornecer uma boa API e uma implementação simulada desde o início e somente depois disso iniciar o desenvolvimento real.

   • Isso não quer dizer que a API deve ser definida. Isso é apenas uma atenuação da consequência de dividir uma equipe em duas.

3. Por que tantos artigos ágeis recomendam ter fatias verticais? Aqui estão algumas informações básicas:

   • Na maioria dos artigos, o Agile recomenda evitar o trabalho de back-end, de uma perspectiva de custo.

   • Além disso, não esqueça que uma fração de artigos ágeis tinha o viés implícito em relação às empresas iniciantes.

   • E não se esqueça da dura realidade do marketing - a maioria dos clientes paga apenas pelos front-ends.

   • O trabalho de back-end tende a ser caro e ter retorno lento. A menos que uma empresa já esteja estabelecida a longo prazo e gere um lucro decente, é melhor "terceirizar" o back-end adotando tecnologias prontas para uso e bibliotecas de código aberto.

   • A maioria dos artigos ágeis também recomenda a implementação do front-end para que ele possa sobreviver a uma opção de back-end. Esse conselho anda de mãos dadas com o anterior: se a tecnologia pronta para uso não atender a todos os requisitos, tente outro.

4. Práticas que podem mitigar as más conseqüências da divisão de uma equipe

   • Back-ends estáveis
   • API estável
   • Back-end com baixa taxa de defeitos
     • Razão: para evitar frustração
     • Como: teste de unidade
     • Não significa: desempenho ou otimização; só precisa estar funcionalmente correto.
   • Integração contínua
   • Transparência na comunicação, progresso e tomada de decisão
   • Incentivar discussões informais entre as duas equipes
   • Incentive os membros da equipe (aqueles que não se afastam) a participar das reuniões da outra equipe.
   • Organizar reuniões conjuntas ocasionais e retrospectivas conjuntas
   • Outras atividades de formação de equipes

Como outros, eu definitivamente sugeriria usar fatias verticais. Às vezes, eles são chamados de "equipes de recursos". Eu recomendaria a leitura dos prós / contras no site do Scaled Agile Framework: http://scaledagileframework.com/scaled-agile-framework/team/features-components/

Inicialmente, quando você divide, o Dono do produto e o SDF Master podem lidar com o Backlog de liberação de ambas as equipes, bem como com os backlogs individuais de cada equipe de recursos. À medida que você cresce, no entanto, você provavelmente precisará implementar uma lista de pendências de recursos do produto, que será alimentada em várias equipes ágeis. Depois de escalar para esse nível, você provavelmente precisará de uma equipe separada, gerenciando a lista de pendências de recursos e, em seguida, trazendo os recursos para as equipes individuais para implementação. Nessa estrutura, você pode ter algo parecido com isto:

1. Equipe ágil 1: SM, PO, equipe multifuncional. Possui backlog de equipe própria para suas histórias.
2. Equipe ágil 2: SM, PO, equipe multifuncional. Possui backlog de equipe própria para suas histórias.
3. Equipe de gerenciamento de programas: gerente de produto, gerentes de lançamento, arquitetos corporativos. Possui backlog de programa próprio de épicos e recursos de nível superior que serão organizados, analisados ​​e depois transmitidos para as equipes.

O site da SAFe tem muitas coisas interessantes para organizar equipes maiores, e algumas podem ser úteis para você, conforme você passa para uma escala maior de equipes de equipes.