L'équipe Scrum ne suit pas le principe de Yagni
Lors d'une réunion de Scrum, l'équipe du produit débattait sur une fonctionnalité sur une API qui sera consommée par une application mobile. Nous avons eu une maquette qui a montré comment l'écran devrait ressembler et quels éléments clés doivent contenir (une "mise en page").
Sur la base de cela et de la discussion avec le propriétaire du produit, j'ai créé un prototype pour une réponse API (Hal + Json). C'était très simple, Json conforme à Hal qui n'a rien fait de plus que de représenter les choses qui étaient sur les maquettes. Je n'ai pas été influencé par les idées futures prévues par des hommes d'affaires, car ils ont tendance à changer leurs idées souvent et j'ai décidé de prendre l'approche minimaliste. Ma proposition a été rejetée par l'équipe et j'ai été survécu de 7 à 1.
L'équipe a décidé d'utiliser une structure JSON abstraite non sémantique plus complexe, qui permet une plus grande flexibilité dans l'organisation de la mise en page. L'inconvénient de cette approche est terminé avec un ensemble d'objets uniformes pouvant avoir des propriétés nulles et vides par design. Ils pensaient également que ce serait bien de faire des tests A/B possibles, mais il était basé sur leurs prédictions que comme nous n'avions aucune exigence de ce type.
La plupart du temps, nous débattons de choses qui ne faisaient pas partie du sprint ni de la masse de maquettes. Les problèmes décrits étaient "Et si le marketing dans le futur veut ...", "Et si l'entreprise voudra peut-être que nous ...".
I et le propriétaire du produit sont des programmeurs expérimentés et nous avons vu ce type de problèmes dans le passé. Nous essayons de suivre le YAGNI et BAISER Principes. Le reste de l'équipe est un peu moins expérimenté et bien qu'ils connaissent ces principes, ils semblent ne pas les comprendre.
Nous avons convenu de leur solution lorsque l'équipe dans son ensemble est plus importante pour nous et nous ne voulions pas nous battre sur quelque chose qui n'est pas si important. Mais je crains que si de telles choses puissent devenir un précédent pour faire venir des débats plus compliqués? Comment traiter de ce comportement? Y a-t-il quelque chose que je, en tant que chef d'équipe, peut faire mieux?
Il vaut la peine de mentionner que le produit est un MVP à la première étape.
Je sens ta douleur, j'y suis allé. IMHO Ces types de problèmes sont causés par le fait que vous avez une équipe de 8 personnes, qui est déjà trop grosse pour vous permettre toujours de prendre les meilleures décisions stratégiques.
Dans une équipe de 8 ans ou plus, le nombre de programmeurs médiocres est élevé que le nombre de personnes expérimentées. Cela conduira souvent à des situations où les meilleures décisions sont évitées par les médiocres. Cela ne semble pas satisfaisant, surtout lorsque vous êtes (ou pensez-vous) l'un des gars les plus expérimentés, mais au moins la même chose est souvent vrai pour de très mauvaises décisions.
Fait, c'est, Il n'y a pas grand chose à faire à ce sujet tant que l'équipe ne change pas, au moins si les choses resteront démocratiques, donc soit
- apprendre à vivre avec elle
- travaillez avec l'équipe pendant une ou deux ans, partagez votre propre expertise et j'espère qu'ils apprennent la valeur de Yagni et KISS au fil du temps
- travailler sur vos propres compétences de la "vente" des conceptions ou des décisions stratégiques à l'équipe
- essayez de passer à une autre équipe (peut-être plus petite) où votre propre niveau d'expertise est plus proche de la moyenne de toute l'équipe
Je pense que le seul moyen d'apprendre et de comprendre la valeur réelle d'une approche minimaliste et de Yagni consiste à faire des expériences de première main. Par exemple, en s'impliquant dans la maintenance d'un système hérité avec beaucoup de mauvaises prédictions "si" des prédictions de conception, de mauvaises décisions de conception motivées par des arguments "juste au cas", ou contenant beaucoup de code-cadre surgénéralisé qui n'était effectivement jamais nécessaire. Mais ce n'est rien que vous puissiez enseigner aux membres de votre équipe dans deux jours, certaines expériences des personnes doivent se faire par eux-mêmes.
La compatibilité avant est une préoccupation légitime
Si l'un des sept développeurs qui vous a survécu est l'architecte, c'est son droit d'introduire NFRS au besoin, et l'une de ces NFRS pourrait être "Compatibilité avant", surtout lorsque vous soutiendrez un système distant. composant qui pourraient avoir un horaire de libération plus rare. Vous ne voulez pas que les utilisateurs aient à installer une nouvelle version d'une application car vous n'avez pas pensé à venir.
Comme d'autres exigences, vous avez besoin de critères d'acceptation
Cela étant dit, des NFRS doivent être documentées comme des exigences et doivent avoir défini critères d'acceptation . De plus, vous devez trouver un moyen de les tester . C'est pourquoi Yagni est important ... Vous ne voulez pas écrire de code qui ne peut pas être testé et si le seul but du code est de prendre en charge une fonctionnalité que personne n'utilise, il est difficile de tester.
Ça ne devrait pas être un appel de jugement
Je vous suggérerais que l'équipe soit d'accord sur l'exigence tacite que vous avez apparemment manquée et que vous l'avez écrite. Une fois que vous avez défini un moyen de tester, votre mise en œuvre devrait échouer au moins un test et il ne devrait donc pas s'agir de vote.
Le problème avec Yagni et KISS est qu'ils sont complètement subjectifs et vagues.
json ?? Yagni! Envoyez simplement une chaîne CSV!
objets?? Kisstupid !!! il suffit d'utiliser gotos !!
Le rôle du "chef d'équipe" n'est pas bien défini, mais je vous suggère de vous distancer d'exprimer des opinions subjectives sur les choix techniques de vos équipes. Même si vous sentez qu'ils ont tort. Coller à une courte liste d'exigences bien définies.
- tests unitaires pour le code
- tests d'intégration pour les API
- tests d'interface utilisateur automatisée pour le produit final
- exigences de performance et d'échelle
si l'équipe peut effectuer des tests de passage pour toutes les exigences de l'entreprise et la performance de base à l'échelle des exigences techniques, vous avez un produit de travail.
Après cela, il suffit de pousser pour faire la même chose mais plus rapide
Eh bien, mon opinion est la démocratie ne fonctionne pas correctement - ni dans le système politique, ni dans une équipe où la plupart des programmeurs sont juniors ou médiocre.
Votre mot, en tant que chef d'équipe, et l'une des personnes les plus expérimentées d'une équipe, devrait avoir un impact plus élevé que le reste de l'équipe. Si Yagni est important pour vous, alors vous devriez faire une présentation à ce sujet. En discuter à ce sujet, et montrez-leur pourquoi est-ce bon.
Après tout, votre responsabilité est plus élevée pour d'autres personnes. Ce n'est pas seulement d'écrire du code, mais aussi de guider les gens.
Il pense qu'il y a une petite confusion sur Yagni.
Les développeurs pensent souvent qu'ils suivent Yagni lorsqu'ils omettent des abstractions qui conserveront le système "fermé pour la modification et l'ouverture de l'extension".
À moins que vous n'ayez pas "étendre" le système avec une fonctionnalité "évidemment" non demandée que vous ne traitez pas avec Yagni. L'introduction des abstractions lorsque l'extension pourrait survenir est la "compatibilité directe" déjà mentionnée.
Mon opinion personnelle est que seules une connaissance approfondie du domaine aideront à prendre des décisions de l'abstraction et de la localiser.
Ma première pensée à ce sujet est ... Pourquoi l'équipe est-elle préoccupée par les changements? Ont-ils une compréhension historique du propriétaire du produit qui leur permet d'avoir besoin de construire la première solution pour être un peu plus configurable pour faciliter les améliorations futures? Si votre solution prendrait 2 jours et leur 5 jours, oui, c'est plus de deux fois plus longtemps. Mais si l'altération de votre plan prendrait 2 jours à chaque fois, mais une amélioration de leur allouation prendrait 1 jour, leur plan semble plus efficace sur le long terme. Je ne pense pas qu'il y ait une bonne ou une bonne décision dans cette question. Cela dépend d'autres facteurs, IMHO. Cependant, vous avez raison à propos de cet état d'esprit si sur d'autres solutions, ils doublent la LOE sans aucune orientation directe pour le faire (certaines preuves que la complexité supplémentaire est nécessaire pour l'évolutivité, la robustesse, etc.). Ma suggestion serait d'amener le propriétaire du produit à ces conversations, car ils doivent aider à la priorité. Si votre solution est de 5 points, et cela répondrait à la nécessité de la nécessité, mais ce qu'ils veulent faire de 50 points et deux sprints ou plus, le PO peut dire "HOLD ON, nous avons une libération prioritaire élevée de ce MVP prévu et Je ne peux pas dépenser 2 semaines de construire des fonctionnalités qui ne sont pas sur la feuille de route! "
Tout le monde de l'équipe doit d'accord sur la Définition de FAIT . Sans cela, vous êtes sujet à des quantités massives de fluage de portée, de points de vue et de stockage des exigences essentielles.
Tout ce qui est livré au-dessus et au-dessus de cela doit être sur l'arriéré, ce qui sera également sa propre définition de la part de la tâche.
En ce qui concerne les priorités, la méthode Mosco nous a toujours servi bien - YMMV.