Quando as equipes de componentes são uma opção melhor que as equipes de recursos no desenvolvimento ágil?

5

Quando se trata de estrutura organizacional em um contexto ágil, muitas pessoas afirmam que as equipes de recursos geralmente são uma escolha melhor do que as equipes de componentes. Pelo menos é o que encontro quando converso com colegas, tanto na minha posição atual quanto na anterior. Além disso, Larman e Vodde argumentam veementemente contra as equipes de componentes (Práticas para escalar o Lean e o desenvolvimento ágil) e também trouxeram essa posição para o Scrum Primer ( link ).

Existem, no entanto, fontes que indicam que a escolha entre equipes de recursos e componentes não é uma decisão de "tudo ou nada" e que existem critérios que podem fazer com que (pelo menos algumas) equipes de componentes sejam uma escolha sábia. Por exemplo, no link , os autores indicam que um alto grau de reutilização e alto grau de especialização tecnológica são critérios que tornam as equipes de componentes para a respectiva parte do sistema favoráveis. Mike Cohn e Ken Rubin em seus livros também têm uma visão mais equilibrada.

No meu ambiente profissional (fornecedores automotivos) há tradicionalmente muitas equipes de componentes. Ao fazer a transição para uma maneira ágil de trabalhar, muitos colegas acham que, ao permanecer com uma estrutura de equipe de componentes, a gerência estaria fazendo algo fundamentalmente errado. Não vejo assim por vários motivos:

  • Primeiro, o que um fornecedor automotivo fornece como produto é, do ponto de vista do veículo, apenas um componente. As características reais do cliente estão no nível do veículo. Assim, consequentemente e idealmente, as equipes de recursos teriam que trabalhar com veículos cruzados (através dos limites de fornecedor e OEM). Isso, no entanto, nunca é sequer discutido como uma maneira possível de trabalhar.
  • Existem lotes de componentes em uso, como sistemas operacionais (Linux, QNX, AutoSar, ...), bibliotecas padrão, bibliotecas de terceiros (navegação, reconhecimento de fala), bibliotecas de código aberto ... E, para a maioria dessas bibliotecas, ninguém tem o conhecimento necessário para melhorar internamente a biblioteca. Falar um pouco sarcasticamente: ter outras equipes desenvolvendo componentes para usar é útil, mas o desenvolvimento de componentes na própria organização ágil é uma má escolha?
  • E, certamente, há muitas áreas em que pessoas e equipes desenvolveram uma profunda especialização ao longo de anos e, onde essa especialização é realmente essencial para evitar retornos de campo dispendiosos. Desenvolver uma estratégia de atualização de software que funcione em todas as circunstâncias no campo com quedas de energia acontecendo em momentos arbitrários é algo que poucos podem fazer. Portanto, há um alto risco se todos em um projeto maior puderem fazer modificações nessa árvore de origem. Da mesma forma, os recursos de segurança estão em toda parte, mas poucos entendem os detalhes, também os protocolos de comunicação específicos do veículo, etc.

Agora, minha pergunta: Quais outros critérios (exceto para o grau de reutilização e especialização técnica) você vê que poderiam tornar as equipes de componentes em determinados cenários de desenvolvimento de software favoráveis ao trabalhar em um contexto ágil?

    
por Dirk Herrmann 12.12.2018 / 00:51
fonte

2 respostas

6

Um ponto-chave do trabalho "Ágil" significa que a equipe produz resultados em pequenos ciclos (chamados "Sprints" no discurso do Scrum). Então, IMHO, a única coisa que realmente importa neste contexto é: os componentes de um sistema maior podem ter ciclos de lançamento independentes , para que possam ser desenvolvidos em Sprints individuais?

Se a resposta for sim, não há razão IMHO que proíbe trabalhar "Agile" em equipes de componentes. Cada componente precisa ser um "produto de entrega por conta própria", com interfaces claramente definidas, controle de versão próprio, testes próprios, documentação própria e um planejamento da Sprint que não comprometa o desenvolvimento de componentes diferentes juntos.

Você já deu alguns exemplos onde isso funciona bem: componentes como o sistema operacional ou outras bibliotecas especializadas de terceiros: o desenvolvimento de componentes que dependem do primeiro é planejado sobre os recursos já disponíveis no início de cada sprint (por exemplo, do sistema Linux ou do sistema de reconhecimento de fala ou qualquer outro). Portanto, se sua equipe desenvolve o novo centro multimídia utilizando algum sistema de reconhecimento de fala no Linux V123.4, não importa o seu planejamento de sprint quando a "nova versão 4.0 do componente de reconhecimento de fala com maior taxa de detecção" estará disponível ou não, ou se o Linux V123.5 estará disponível ou não - sua equipe pode trabalhar nos próximos dez sprints do centro multimídia com ou sem essa nova versão.

Para dar um contra-exemplo: uma aplicação web multicamadas onde o desenvolvimento de cada nova funcionalidade requer sempre mudanças no "frontend" assim como no "backend" em paralelo. Quando você não pode planejar Sprints para a equipe de frontend independentemente da equipe de back-end, trabalhar em sprints produzirá atrito entre as equipes, porque uma delas sempre terá que esperar pela outra. Portanto, esse tipo de desenvolvimento provavelmente funcionará melhor com uma equipe multifuncional, porque se as atividades do frontend forem concluídas antes do final do sprint planejado (ou vice-versa), os desenvolvedores disponíveis que trabalharam no frontend podem ajudar a finalizar o backend atividades para o sprint (ou vice-versa).

    
por 12.12.2018 / 06:08
fonte
1

Você pode ser ágil em cada equipe de componentes existente, se necessário. E veja onde isso vai. No entanto, a imposição de nível ágil no nível superior de uma organização de produção multidisciplinada aprimorada será destrutiva, destrutiva, levará ao caos e interromperá a operação.

Ágil mata a propriedade

Isso não é necessariamente ruim em todas as situações, pode ser o caminho a percorrer para abordar um único ponto de falha. A pergunta a ser feita sempre deve ser: podemos nos dar ao luxo de fazer isso e podemos nos dar ao luxo de fazê-lo abruptamente?

Haverá conseqüências não apenas imediatas em relação à qualidade, mas socialmente também. Como você acha que John vai gostar que o componente em que ele trabalhou por anos, que ele se sente responsável, de que ele é orgulhoso, que seja seu bebê, de repente esteja lá fora para todo mundo mexer e fazer xixi? Como ele vai lidar com a mensagem "Bem John, você pode sentir que trabalhou duro e acumular algum conhecimento, mas, ei, temos novidades para você: não acreditamos nisso, achamos que qualquer um pode fazer o seu trabalho! Então, Fique de costas e observe como seus colegas de trabalho, com quem você se deu bem até agora, vão arruinar tudo o que você fez. " John provavelmente terá alguns problemas de fidelidade.

Ser enviado em todo o lugar para extinguir pequenos incêndios em partes com as quais você não está familiarizado é desgratificante, as pessoas mais capazes acabarão por sair. E é isso que o agile / scrum geralmente se deteriora quando implementado de maneira descuidada: ninguém é dono de nada e, portanto, ninguém se sente responsável por nada, se preocupa com qualquer coisa ou fica bom em qualquer coisa.

Agile / scrum é ótimo se você não tiver nenhum processo. Se você tem um sistema com algum histórico que funcionou, você deve ter muito cuidado para não perder mais do que ganha.

    
por 15.12.2018 / 09:49
fonte