Equipe Scrum que não segue o princípio YAGNI

Em uma reunião do SCRUM, a equipe do produto estava debatendo sobre um recurso em uma API que será consumida pelo aplicativo móvel. Tivemos uma simulação que mostrou como a tela deveria ser e quais os principais elementos que ela deveria conter (um "layout").

Com base nisso e na discussão que tive com o proprietário do produto, criei um protótipo para uma resposta de API (HAL + JSON). Era muito simples, o JSON compatível com HAL, que nada mais fazia do que representar o que estava nas maquetes. Não fui influenciado pelas idéias futuras previstas pelos empresários, pois elas tendem a mudar suas idéias com frequência e decidi adotar uma abordagem minimalista. Minha proposta foi rejeitada pela equipe e fui derrotado por 7 a 1.

A equipe decidiu usar uma estrutura json abstrata não-semântica mais complexa, que permite mais flexibilidade na organização do layout. A desvantagem dessa abordagem é que acabamos com um conjunto de objetos uniformes que podem ter propriedades nulas e vazias por design. Eles também pensaram que seria bom tornar possível o teste A / B, mas foi baseado em suas previsões apenas porque não tínhamos esse requisito.

Na maioria das vezes, estávamos debatendo sobre coisas que não faziam parte do sprint nem eram mencionadas nos modelos. Os problemas descritos foram "e se o marketing no futuro ...", "e se a empresa quiser que nós ...".

Eu e o proprietário do produto somos programadores experientes e vimos esse tipo de problema no passado. Tentamos seguir os princípios YAGNI e KISS . O restante da equipe é um pouco menos experiente e, embora conheça esses princípios, parece que não os entende.

Concordamos em sua solução, pois a equipe como um todo é mais importante para nós e não queríamos brigar por algo que não é tão importante. Mas receio que tal coisa possa se tornar um precedente para debates futuros e mais complicados? Como lidar com esse comportamento? Existe algo que eu, como líder de equipe, possa fazer melhor?

Vale ressaltar que o produto é um MVP em estágio inicial.

Eu sinto sua dor, já estive lá. IMHO, esse tipo de problema é causado pelo fato de você ter uma equipe de 8 pessoas, que já é grande demais para permitir que você sempre tome as melhores decisões estratégicas.

Em uma equipe de tamanho 8 ou mais, as chances são altas, o número de programadores medíocres é superior ao número de programadores experientes. Isso geralmente leva a situações em que as melhores decisões são superadas por medíocres. Isso não parece satisfatório, especialmente quando você é (ou pensa que é) um dos caras mais experientes, mas pelo menos o mesmo acontece com as decisões realmente ruins.

O fato é que não há muito que você possa fazer a respeito, contanto que a equipe não mude , pelo menos se as coisas permanecerem democráticas;

• Aprenda a viver com isso
• trabalhe com a equipe por um ou dois anos, compartilhe sua própria experiência e espere que eles aprendam o valor do YAGNI e do KISS ao longo do tempo
• trabalhe com suas próprias habilidades de "vender" o design ou decisões estratégicas para a equipe
• tente mudar para uma equipe diferente (talvez menor), onde seu próprio nível de conhecimento esteja mais próximo da média de toda a equipe

Eu acho que a única maneira de aprender e entender o valor real de uma abordagem minimalista e o YAGNI é fazendo algumas experiências em primeira mão. Por exemplo, envolvendo-se na manutenção de um sistema legado com muitas previsões "e se" erradas, decisões erradas de design motivadas por argumentos "just in case" ou contendo muitos códigos de estrutura super-generalizados que na verdade nunca eram necessários. Mas isso não é nada que você possa ensinar aos membros da sua equipe em dois dias, algumas experiências que as pessoas precisam fazer sozinhas.

A compatibilidade direta é uma preocupação legítima

Se um dos sete desenvolvedores que superou você é o arquiteto, é seu direito introduzir NFRs conforme necessário, e um desses NFRs pode ser "compatibilidade direta", especialmente quando você oferece suporte a um componente de sistema remoto que pode ter uma dispersão mais esparsa. cronograma de lançamento. Você não deseja que os usuários tenham que instalar uma nova versão de um aplicativo porque não pensou no futuro.

Como outros requisitos, você precisa de critérios de aceitação

Dito isto, quaisquer NFRs devem ser documentados como requisitos e devem ter critérios de aceitação definidos . Além disso, você deve apresentar um meio de testá-los . É por isso que o YAGNI é importante - você não deseja escrever um código que não possa ser testado e, se o único objetivo do código é oferecer suporte a um recurso que ninguém está usando, é difícil testá-lo.

Não deve ser um julgamento

Eu sugiro que você peça à equipe que concorde com o requisito tácito de que você aparentemente não cumpriu e o anote. Depois de definir um meio de testá-lo, sua implementação deve falhar em pelo menos um teste e, portanto, não deve ser uma questão de votação.

Parece que sua equipe de desenvolvimento está tentando facilitar a equipe de produtos criando uma estrutura que permita que eles façam testes rápidos, o que aparentemente é o que a equipe de produtos realmente gostaria de ter. Sua abordagem é mais como "literalmente, dê a eles o que eles pedem e não pensem por eles".

Se eu fosse o proprietário do produto, aposto que ficaria muito mais feliz com uma equipe de desenvolvimento adotando a primeira abordagem do que a última.

Bem, minha opinião é que a democracia não está funcionando corretamente - nem no sistema político, nem em uma equipe onde a maioria dos programadores é iniciante ou medíocre.

Sua palavra, como líder de equipe e uma das pessoas mais experientes de uma equipe, deve ter um impacto maior que o restante da equipe. Se YAGNI é importante para você, faça uma apresentação sobre isso. Discuta sobre isso e mostre a eles por que é bom.

Afinal, sua responsabilidade é maior do que para outras pessoas. Não é apenas escrever código, mas também orientar as pessoas.

Acha que há um pouco de confusão sobre YAGNI.

Os desenvolvedores geralmente acham que seguem o YAGNI quando omitem abstrações que manterão o sistema "fechado para modificação e aberto para extensão".

A menos que você não "estenda" o sistema com uma funcionalidade "obviamente" não solicitada, você não lida com o YAGNI. Introduzir abstrações onde estender pode ocorrer é a já mencionada "compatibilidade futura".

Minha opinião pessoal é que apenas um conhecimento profundo do domínio ajudará a tomar decisões de abstração e onde localizá-lo.

O problema com YAGNI AND KISS é que eles são completamente subjetivos e vagos.

json ?? YAGNI! basta enviar uma string csv!

objetos ?? KISSTUPID !!! basta usar gotos !!

O papel de 'Líder da equipe' não está bem definido, mas eu sugiro que você se distancie de expressar opiniões subjetivas sobre as escolhas técnicas de suas equipes. Mesmo se você sentir que eles estão errados. Atenha-se a uma pequena lista de requisitos bem definidos.

• testes de unidade para código
• testes de integração para APIs
• testes automatizados de interface do usuário para o produto final
• requisitos de desempenho e dimensionamento

se a equipe conseguir passar nos testes para todos os requisitos de negócios e desempenho básico em escala de requisitos técnicos, você possui um produto em funcionamento.

Depois disso, basta pressionar para fazer o mesmo, mas mais rápido

Todos na equipe devem concordar com a definição de feito . Sem isso, você é propenso a grandes quantidades de oscilação de escopo, pontos de vista e bastardização dos principais requisitos.

Qualquer coisa entregue além disso deve estar no backlog, que também terá sua própria definição de done.

Quanto às prioridades, o método MoSCoW sempre nos serviu bem - YMMV.

Meu primeiro pensamento sobre isso é ... Por que a equipe está preocupada com as mudanças? Eles têm alguma compreensão histórica do Dono do Produto que os faz sentir que precisam criar a primeira solução para ser um pouco mais configurável para facilitar aprimoramentos futuros? Se a sua solução demorar 2 dias e os 5 dias, sim, será mais do que o dobro. Mas se a alteração do seu plano levasse 2 dias a cada vez, mas um aprimoramento ao seu levasse 1 dia, o plano parece mais eficiente a longo prazo. Eu não acho que haja uma decisão certa ou errada nesta questão. Depende de outros fatores, IMHO. No entanto, você está certo quanto a essa mentalidade se, em outras soluções, eles dobrarem o LOE sem nenhuma orientação direta para fazer isso (algumas evidências de que a complexidade adicional é necessária para escalabilidade, robustez, etc.). Minha sugestão seria trazer o proprietário do produto para essas conversas, porque eles precisam ajudar na priorização. Se sua solução é de 5 pontos e agora atende à necessidade, mas o que eles querem fazer exigiria 50 pontos e dois sprints ou mais, o PO pode dizer "espere, temos uma versão de alta prioridade desse MVP planejado e não pode gastar duas semanas criando funcionalidades que não estão no roteiro! "