Desvantagens de histórias verticais de usuários

A abordagem ágil é estruturar o trabalho em histórias verticais do usuário e fornecer uma parte do aplicativo focada, mas totalmente funcional, de ponta a ponta . Como essa é a nova abordagem para a construção de software, li muita literatura sobre por que isso é melhor do que as histórias horizontais, mas não encontro muita coisa sobre as desvantagens dessa abordagem.

Eu já bebi o auxílio ágil e também concordo que cortar o bolo verticalmente tem muitas vantagens sobre o fatiamento horizontal. Aqui está uma pequena lista de desvantagens que eu poderia apresentar:

• Inicialmente, um desenvolvedor pode ser mais lento na implementação de um recurso, pois precisa entender todas as tecnologias necessárias para desenvolver a história (UI + camada de serviço + acesso a dados + rede, etc ...)
• O design geral da arquitetura (criar a espinha dorsal do aplicativo) não se encaixa realmente nesse mantra (no entanto, alguns podem argumentar que faz parte da história do usuário desenvolver / alterar a arquitetura geral)

Quais são as desvantagens de fatiar verticalmente as histórias de usuários?

Nota: A razão pela qual estou fazendo essa pergunta agora é porque vou tentar convencer uma equipe a começar a escrever histórias da 'maneira vertical' e quero poder apresentar as possíveis compensações antes do tempo, para que elas sejam vencidas. considere a abordagem um fracasso quando enfrentar as desvantagens.

Não conheço nenhuma desvantagem a longo prazo. No curto prazo, e para uma equipe nova nesse tipo de desenvolvimento, a principal desvantagem é que é preciso algum tempo para se acostumar e aprender.

A maneira mais eficiente de trabalhar verticalmente é ter desenvolvedores de pilha completa: dessa forma, uma história pode ser tipicamente executada por uma pessoa (ou mais de uma, mas sem tarefas de pipelining ). Claramente, isso requer que os desenvolvedores trabalhem verticalmente na pilha (do html ao banco de dados no caso de um aplicativo Web).

Se sua equipe não está acostumada a trabalhar em histórias verticais, é provável que elas estejam fazendo o oposto: cada pessoa terá conhecimento de apenas uma camada / camada do aplicativo. Ao introduzir histórias verticais, você pode esperar que a equipe as divida em tarefas correspondentes a camadas e depois distribua as tarefas para pessoas diferentes. Isso será muito ineficiente.

A melhor abordagem que posso dar a esse respeito é tolerar esse pipelining inicialmente, deixando claro que o objetivo de longo prazo é completamente diferente. Peça aos membros da equipe através do programa de pareamento de camadas, para criar confiança e, eventualmente, permitir que as pessoas sejam completamente independentes.

Não concordo com a outra resposta de que essa abordagem gera dívida técnica. Pode, mas também qualquer outra abordagem.

Eu estive pensando muito sobre essa pergunta exata.

Eu acho que é importante distinguir entre fatiar por responsabilidades individuais e fatiar por responsabilidades da equipe. Vou focar essa resposta principalmente nas equipes de fatiamento.

Para algumas informações: trabalhei em projetos com desenvolvedores de pilha completa, desenvolvedores de camada única, equipes verticais (pilha completa), equipes horizontais (camada única) e equipes diagonais. Por equipe diagonal, quero dizer, conter todas as camadas necessárias para uma história, mas não necessariamente todas as camadas do sistema, e também possivelmente conter vários desenvolvedores focados nas mesmas camadas; em outras palavras, de espírito vertical, mas talvez um pouco horizontal na aparência ou nos detalhes da implementação.

Recentemente, trabalhei em um grupo que passou de equipes horizontais para equipes diagonais (quase verticais). Foi particularmente instrutivo ver o mesmo grupo de pessoas alinhadas de duas maneiras diferentes. Isso deixa bem claras algumas vantagens e desvantagens.

Até agora, arredondarei minha opinião com a seguinte comparação resumida:

Equipas horizontais

Vantagens:

• Promove uma boa separação de preocupações e níveis pouco acoplados
• Gerenciamento de distribuição de carga de trabalho muito mais fácil
• Fácil para o líder técnico especializado gerenciar
• Promove a colaboração entre níveis, melhores práticas, orgulho e uma cultura de excelência
• Alinha com padrões de comunicação naturais / emergentes

Desvantagens:

• Pode levar ao isolamento de camadas e, assim, dificultar a comunicação entre camadas
• Ativa a cultura de "bolha" da camada se não mitigada
• Difícil tirar vantagem da liderança generalista
• Impede generalistas

Equipas Verticais / Diagonais

Vantagens:

• Todas as partes de uma história de usuário em uma equipe ("balcão único")
• Auxilia especificamente na entrega de histórias de n camadas em um único sprint (embora você realmente precise disso?)
• Promove a colaboração entre níveis e o crescimento de habilidades generalistas
• Suporta generalistas

Desvantagens:

• Gerenciamento de distribuição de carga de trabalho muito mais difícil
• Permite uma má separação de preocupações e camadas fortemente acopladas
• Impede a especialização, restringindo a comunicação entre níveis; é difícil ver como uma cultura de excelência poderia surgir dessa estrutura sem adicionar comportamentos horizontais / especializados atenuantes

Não acho que a participação em equipes tenha uma solução única para todos. Parece bem claro, no entanto, que a equipe vertical se alinha melhor para organizações que exigem generalização. Se seus engenheiros são generalistas e gostam de trabalhar com uma pilha cheia, esse é um bom motivo para considerar equipes verticais. A equipe horizontal se alinha melhor para organizações que exigem especialistas. Se seus engenheiros são especialistas, esse é um bom motivo para considerar equipes horizontais.

Como outros já mencionaram, estruturas / comportamentos secundários que dividem a outra direção podem ajudar a mitigar os inconvenientes de qualquer sistema. Um fator atenuante interessante é a duração do sprint. Sprints curtos tornam algumas das desvantagens das equipes horizontais mais toleráveis. Se você pode criar o back-end esta semana e o front-end na próxima semana, isso pode ser rápido o suficiente?

Para aplicar alguns desses princípios propostos a um problema do mundo real ... direi que as fatias horizontais funcionaram muito bem para uma equipe de desenvolvimento SaaS muito real em que trabalhei, que resolvia problemas técnicos muito desafiadores em todos os níveis ( onde a especialização era, na minha opinião, incrivelmente importante), onde a frequência de entrega (e a confiabilidade com uma granularidade / frequência alta) eram essenciais para o sucesso dos negócios. Observe que esta conclusão é para uma equipe do mundo real muito particular, não para uma declaração geral de superioridade do fatiamento horizontal.

Uma ressalva: eu provavelmente sou tendencioso contra alegações de habilidades generalistas por qualquer indivíduo no mundo moderno de desenvolvimento de software sem provas significativas, embora eu tenha conhecido alguns generalistas excepcionais raros. Sinto que a generalidade é uma ordem alta (vertical?), De fato, especialmente à medida que cada camada cresce em complexidade e com a proliferação de idiomas / plataformas / estruturas / implantações alternativas, cada uma atendendo a diferentes necessidades. Hoje em dia, especialmente, um grande número de negócios pode facilmente ser um mestre de ninguém. Além disso, curiosamente, acho que a maioria das pessoas deseja se especializar um pouco, novamente com algumas exceções.

A grande desvantagem que encontrei é que torna difícil para uma equipe criar o aplicativo seguindo uma abordagem arquitetônica unificada.

Nos estágios iniciais do projeto, todos escreverão suas camadas isoladamente. As histórias (e as camadas envolvidas) funcionarão, mas, ao olhar para o produto entregue no final do sprint, será fácil ver as pequenas diferenças entre as idéias arquitetônicas de cada desenvolvedor.

Esse tipo de coisa é inevitável, mas não um bloqueador. Eu tentei combater isso de duas maneiras:

1. Tenha longas discussões de design com a equipe antes de implementar cada história
   • Isso fica cansativo rapidamente. Muitas vezes, é muito cedo para alguém tomar uma decisão informada e você acaba discutindo sobre coisas que definitivamente terão que mudar de qualquer maneira.
2. Vá em frente e desenvolva-se em relativo isolamento, tendo em mente que você está criando dívidas técnicas .
   • A chave aqui é registrar a dívida técnica (arquitetônica) como um problema. Isso é algo que precisará ser pago de volta.
   • Depois de algumas corridas, será mais fácil decidir sobre uma arquitetura coerente e unificada. É nesse momento que você deve solicitar um sprint de proteção para pagar parte de sua dívida técnica (refatorar o código existente). Como alternativa, você pode pagar aos poucos nas próximas iterações do projeto.

O único outro problema em que posso pensar além disso é que geralmente há muito código padrão para adicionar no início de um projeto. Escrever histórias em fatias verticais significa que a velocidade da equipe nas primeiras histórias será artificialmente baixa devido a esse pré-requisito - mas, desde que todos saibam que isso deve afetar apenas os primeiros sprints, tudo ficará bem.

Também não conheço desvantagens, no entanto, as histórias verticais podem ser mal implementadas.

Quando iniciei minha carreira, entrei para uma equipe interessada em fazer XP, mas eles não tinham experiência com isso. Cometemos vários erros ao usar histórias verticais do usuário.

Um dos problemas que encontramos ao realizar trabalhos horizontais foi o fato de os recursos não se integrarem bem nas camadas. As APIs geralmente não correspondem à especificação, recursos ausentes e inúmeros outros problemas. Muitas vezes, como o desenvolvedor do mudou para outra coisa, você teria que esperar por eles ou fazer você mesmo.

Mudar para o Vertical Stories resolveu esses problemas e reduziu / eliminou o desperdício de re-trabalhar para integrar.

Existem várias práticas de XP que suportam essa maneira de trabalhar. Qualquer pessoa precisa ser capaz de trabalhar em qualquer área e todos devem corrigir os erros que encontrarem ( propriedade do Código Coletivo ).

Quando você está alterando as histórias verticais, pode ser complicado trabalhar em áreas com as quais você não está familiarizado. A programação em pares pode ajudar, se você não estiver seguro, pegue alguém da equipe que esteja emparelhado com eles. Eu descobri que a programação em pares é a maneira mais rápida de atualizar com uma nova base de código.

Sem fortes proprietários sobre as camadas, descobrimos que havia alguma duplicação emergindo. Embora esse não fosse um grande problema, precisamos garantir que praticamos o Refatorar sem piedade (com testes apropriados para dar suporte).

Embora eu mencione vários problemas, não acho que a Vertical User Stories foi a causa. De fato, isso tornou os problemas mais aparentes. Depois que fizemos a troca, os problemas não eram mais ofuscados entre equipes ou camadas de aplicativos.