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

13

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.

Jacek Kobus
fonte
11
I'm afraid if such thing can become a precedence for upcoming, more complicated debates?- Isso também viola YAGNI: se preocupar com um futuro que pode não acontecer. Se você estava indo para defender sua posição, você já deveria ter feito isso.
Robert Harvey
@gnat: Isso não parece ser sobre restrições de tempo.
Robert Harvey
Ser compatível com HAL não está sujeito ao YAGNI?
6177 Matthew
@ Matthew, a coisa toda levou uma semana e eu também preparei outro protótipo usando JSON simples apenas para se livrar do HAL, mas também foi rejeitado visto como "não é flexível o suficiente". A equipe o modificou e essa versão modificada foi finalmente usada. O HAL funciona para nós como um padrão, um conjunto de diretrizes, e é mais fácil para mim impor uma estrutura uniforme em todos os pontos de extremidade. A API anterior não estava usando nenhum padrão e não terminou bem.
Jacek Kobus
5
Flexibilidade acrescenta complexidade. Enquanto a equipe entender isso, pode-se avançar.
21416 Jon Jones

Respostas:

10

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.

Doc Brown
fonte
5
A maioria das pessoas precisa tocar no fogão para aprender que está quente e não tocá-lo. Software é praticamente o mesmo. ++
RubberDuck
2
Manter um diário / log do projeto é fundamental para esse tipo de coisa. Depois de registrar as várias discussões que ocorreram, elas são muito mais concretas do que as lembranças das conversas das pessoas meses ou anos depois. Há uma boa pergunta sobre a prática aqui .
Robbie Dee
@RobbieDee: claro, se isso ajudar a equipe a aprender sobre YAGNI e KISS.
Doc Brown
3
O terceiro item (trabalhando com suas próprias habilidades em "vender" um design) não recebe atenção suficiente. É por isso que os desenvolvedores ainda precisam ter (ou trabalhar) boas habilidades de comunicação.
Randall Stewart
@RandallStewart: absolutamente. Mas mesmo com as melhores habilidades de comunicação, pode ser difícil vender o YAGNI para pessoas que não fizeram algumas experiências sozinhas, ou confundi-las com "rápido e sujo", ou foram educadas que "a abstração é (sempre) boa" e, portanto, tente abstrair as coisas por uma questão de abstração, em vez de uma questão de simplificação. A comunicação precisa de dois lados - um que possa explicar bem as coisas e outro que esteja disposto a ouvir e entender.
Doc Brown
8

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.

John Wu
fonte
1
Onde na pergunta você leu que a equipe do OP deixou o caminho do YAGNI devido a um requisito de compatibilidade direta?
Doc Brown
Compatibilidade para a frente é o que o Content-Typecabeçalho é para
Jack
2
Estou disposto a chamá-lo de outra coisa, se quiser, talvez extensibilidade. O ponto é o mesmo; ainda é um NFR.
John Wu
1
Existem duas maneiras de tornar um sistema extensível. A maneira como se está tentando prever muitas possíveis alterações de requisitos e tornar as coisas altamente configuráveis ​​"por precaução". Estou certo de que se pode inventar muitos testes de aceitação para esse tipo de extensibilidade. Ou, mantendo as coisas o mais simples possível, para que a base de código permaneça pequena, fácil de entender e os pontos de extensão ou abstrações possam ser adicionados mais tarde, quando forem realmente necessários. O último não é nada para o qual você pode (ou precisa) escrever testes. Portanto, não creio que isso possa ser resolvido facilmente "escrevendo NFRs não ditas" ...
Doc Brown
... então isso é mais sobre como impedir uma equipe de desenvolvedores talvez criativos de fazer suposições sobre NFRs e inventar algumas.
Doc Brown
3

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.

Martin Maat
fonte
3
Antecipar e planejar a mudança com +1 não é a mesma coisa que levar astronauta com arquitetura completa e criar uma plataforma interna . Um pouco de trabalho de base agora pode impedir muito trabalho no futuro. Embora a equipe do OP esteja inclinando-se um pouco demais na direção dos hipotéticos, uma abordagem fundamentalista do YAGNI é certamente subótima.
amon
4
Parece mais que você superaria com satisfação o OP e cometeria os mesmos erros de planejamento para "o que acontecerá se o marketing no futuro .." do que o resto da equipe. Quando as pessoas começam a criar estruturas em vez de software aplicativo, quando a tarefa é criar software aplicativo, elas quase sempre fazem isso errado.
Doc Brown
@DocBrown Tecnicamente, eu concordo. Esse caso, no entanto, parece ter vontade de facilitar versus exigir respeito pessoal. Estar "certo", por um lado, e ser útil ou útil, por outro lado. O que eu li nas entrelinhas é que o OP está perdendo terreno e escolhe aumentar seu ego, enfatizando sua experiência para um público on-line em vez de contribuir em um ambiente em que não se sente mais à vontade. Essa dinâmica é típica da introdução do scrum.
Martin Maat
@MartinMaat Fiquei um pouco decepcionado com o fato de eles discordarem de mim. Eu não entendi por que isso aconteceu. Durante o trabalho diário, eu os ajudo com revisões de código etc. Geralmente discutimos, mas eu gosto, porque o resultado final é melhor; Eu sei que eles respeitam minha opinião; Eu sempre tento usar argumentos válidos que apóiam minhas teorias. No final, eles escolhem a melhor opção e também se responsabilizam por ela. A equipe fez o que deveria fazer - resolveu o problema. Foi um erro meu e do proprietário do produto, que o assunto fosse muito amplo e mal descrito desde o início.
Jacek Kobus
2

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.

BЈовић
fonte
3
A democracia é provavelmente a causa do problema aqui, mas não ser democrático não é solução, porque IMHO pode facilmente introduzir problemas maiores do que os descritos na pergunta - pode realmente arruinar a equipe.
Doc Brown
@DocBrown Você acabou de se contradizer na mesma frase. Na IMO, algumas decisões não dependem das pessoas decidirem. O que o OP explicou é um deles. Para citar Armstrong para as pessoas não usando YAGNI: Você queria uma banana, mas o que você conseguiu foi um gorila segurando a banana e toda a selva
BЈовић
2
Não, isso não é uma contradição (talvez eu não tenha expressado bem meu argumento). As coisas nem sempre são "preto e branco". Só porque a democracia não funciona bem em algumas situações, não ser democrático não é uma garantia para melhorar a situação e melhorar as coisas. Muitas vezes não é assim tão simples.
Doc Brown
1
Com a democracia, você não consegue, necessariamente, a coisa "certa", na qual a maioria das pessoas concorda. E isso pode ser falho. E muitas vezes a coisa "certa" tem um problema com a aceitação social. O YAGNI não deve ser uma algema que o impeça de introduzir abstrações apropriadas que permitirão adicionar facilmente o "gorila" ou a "selva inteira", se necessário.
Oopexpert
@oopexpert O problema é: você pode precisar deles. YAGNI fala contra o excesso de engenharia. Abstrações apropriadas são uma coisa, adicionar coisas que você pode não precisar são assuntos diferentes.
1313
2

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.

oopexpert
fonte
2

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

Ewan
fonte
1

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.

Robbie Dee
fonte
1

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! "

Curtis Reed
fonte