L'équipe Scrum ne suit pas le principe YAGNI

Lors d'une réunion SCRUM, l'équipe produit débattait d'une fonctionnalité d'une API qui serait utilisée par l'application mobile. Nous avons eu une maquette qui a montré à quoi devrait ressembler l'écran et quels éléments clés il devrait contenir (une "disposition").

Sur la base de cela et de la discussion que j'ai eue avec le propriétaire du produit, j'ai créé un prototype pour une réponse API (HAL + JSON). C'était un JSON très simple, conforme à HAL, qui ne faisait rien d'autre que représenter les choses qui étaient sur les maquettes. Je n'ai pas été influencé par les idées futures qui étaient prévues par les gens d'affaires car ils ont tendance à changer souvent d'idées et j'ai décidé d'adopter l'approche minimaliste. Ma proposition a été rejetée par l'équipe et j'ai été mis à l'écart 7 contre 1.

L'équipe a décidé d'utiliser une structure json abstraite non sémantique plus complexe, ce qui permet une plus grande flexibilité dans l'organisation de la mise en page. L'inconvénient de cette approche est que nous nous sommes retrouvés avec un ensemble d'objets uniformes qui peuvent avoir des propriétés nulles et vides par conception. Ils pensaient également qu'il serait bien de rendre possible les tests A / B, mais cela ne reposait que sur leurs prédictions car nous n'avions pas de telles exigences.

La plupart du temps, nous débattions de choses qui ne faisaient pas partie du sprint et qui n'étaient pas mentionnées sur les maquettes. Les problèmes décrits étaient «et si le marketing à l'avenir…», «et si l'entreprise voulait que nous…».

Moi et le propriétaire du produit sommes des programmeurs expérimentés et nous avons vu ce genre de problèmes dans le passé. Nous essayons de suivre les principes YAGNI et KISS . 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 nous sommes mis d'accord sur leur solution car l'équipe dans son ensemble est plus importante pour nous et nous ne voulions pas nous disputer pour quelque chose qui n'est pas si important. Mais j'ai peur si une telle chose peut devenir un précédent pour des débats à venir et plus compliqués? Comment faire face à un tel comportement? Y a-t-il quelque chose que je, en tant que chef d'équipe, puisse faire mieux?

Il convient de mentionner que le produit est un MVP à un stade précoce.

Je ressens ta douleur, j'ai été là. À mon humble avis, ce genre de problèmes est dû au fait que vous avez une équipe de 8 personnes, ce qui est déjà trop important pour vous permettre de toujours prendre les meilleures décisions stratégiques.

Dans une équipe de 8 personnes ou plus, les chances sont élevées, le nombre de programmeurs médiocres est supérieur au nombre de programmeurs expérimentés. Cela conduira souvent à des situations où les meilleures décisions sont mises en échec par des décisions médiocres. Cela ne semble pas satisfaisant, surtout lorsque vous êtes (ou pensez que vous êtes) l'un des gars les plus expérimentés, mais au moins la même chose est souvent vraie pour les très mauvaises décisions.

Le fait est que vous ne pouvez pas y faire grand-chose tant que l’équipe ne change pas , du moins si les choses restent démocratiques, alors soit

• apprendre à vivre avec
• travailler avec l'équipe pendant un ou deux ans, partager votre propre expertise et espérer qu'ils apprennent la valeur de YAGNI et KISS au fil du temps
• travailler sur vos propres compétences de «vente» de conception ou de décisions stratégiques à l'équipe
• essayez de passer à une équipe différente (peut-être plus petite) où votre propre niveau d'expertise est plus proche de la moyenne de toute l'équipe

Je pense que la seule façon d'apprendre et de comprendre la vraie valeur d'une approche minimaliste et YAGNI est de 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évisions "et si", de mauvaises décisions de conception motivées par des arguments "juste au cas où", ou contenant beaucoup de code-cadre trop généralisé qui n'était en fait jamais nécessaire. Mais ce n'est rien que vous puissiez enseigner aux membres de votre équipe en deux jours, quelques expériences que les gens doivent faire par eux-mêmes.

La compatibilité ascendante est une préoccupation légitime

Si l'un des sept développeurs qui vous a mis à l'écart est l'architecte, il a le droit d'introduire des NFR au besoin, et l'un de ces NFR pourrait être la "compatibilité ascendante", en particulier lorsque vous prenez en charge un composant de système distant qui pourrait avoir un plus rare calendrier de sortie. Vous ne voulez pas que les utilisateurs doivent installer une nouvelle version d'une application parce que vous n'avez pas anticipé.

Comme les autres exigences, vous avez besoin de critères d'acceptation

Cela étant dit, tous les NFR doivent être documentés comme des exigences et doivent avoir des critères d'acceptation définis . De plus, vous devez trouver un moyen de les tester . C'est pourquoi YAGNI est important - vous ne voulez pas écrire du 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 à tester.

Cela ne devrait pas être un jugement

Je vous suggère de faire en sorte que l'équipe se mette d'accord sur l'exigence tacite que vous avez apparemment manquée et de l'écrire. Une fois que vous avez défini un moyen de le tester, votre implémentation devrait échouer au moins un test et donc il ne devrait pas être question de voter.

Il semble que votre équipe de développement essaie de faciliter l'équipe produit en créant un cadre qui lui permet de faire des essais rapides, ce qui est apparemment ce que l'équipe produit aimerait vraiment avoir. Votre approche ressemble plus à "donnez-leur littéralement ce qu'ils demandent et ne pensez pas pour eux".

Si j'étais le propriétaire du produit, je parie que je serais beaucoup plus heureux avec une équipe de développement adoptant la première approche que cette dernière.

Eh bien, mon avis est que 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édiocres.

Votre parole, 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, vous devriez en faire une présentation. Discutez-en et montrez-leur pourquoi c'est bon.

Après tout, votre responsabilité est plus élevée que celle des autres. Ce n'est pas seulement pour écrire du code, mais aussi pour guider les gens.

Il pense qu'il y a une petite confusion au sujet de YAGNI.

Les développeurs pensent souvent qu'ils suivent YAGNI lorsqu'ils omettent des abstractions qui garderont le système "fermé pour modification et ouvert pour extension".

A moins que vous ne "prolongiez" le système avec une fonctionnalité "évidemment" non demandée, vous ne traitez pas avec YAGNI. L'introduction d'abstractions où l'extension peut se produire est la "compatibilité ascendante" déjà mentionnée.

Mon opinion personnelle est que seule une connaissance approfondie du domaine aidera à prendre des décisions d'abstraction et où le localiser.

Le problème avec YAGNI AND KISS, c'est qu'ils sont complètement subjectifs et vagues.

json ?? YAGNI! il suffit d'envoyer une chaîne csv!

objets?? KISSTUPID !!! utilisez simplement gotos !!

Le rôle de «chef d'équipe» n'est pas bien défini, mais je vous suggère de vous distancier de l'expression d'opinions subjectives sur les choix techniques de vos équipes. Même si vous sentez qu'ils ont tort. Tenez-vous à 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és pour le produit final
• exigences de performances et de mise à l'échelle

si l'équipe peut réussir les tests pour toutes les exigences commerciales et les performances techniques de base à l'échelle, vous avez un produit qui fonctionne.

Après ça, c'est juste pour faire la même chose mais plus vite

Tout le monde dans l'équipe doit se mettre d'accord sur la définition du fait . Sans cela, vous êtes sujet à des quantités massives de fluage de portée, de points de vue et de bastardisation des exigences de base.

Tout ce qui est livré en plus de cela doit être dans l'arriéré qui aura lui-même sa propre définition de fait.

En ce qui concerne les priorités, la méthode MoSCoW nous a toujours bien servi - YMMV.

Ma première réflexion à 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 donne l'impression de devoir créer la première solution pour être un peu plus configurable afin de faciliter les améliorations futures? Si votre solution prendrait 2 jours et la leur 5 jours, oui, c'est plus de deux fois plus longtemps. Mais si la modification de votre plan prendrait 2 jours à chaque fois, mais une amélioration de leur plan prendrait 1 jour, leur plan semble plus efficace à long terme. Je ne pense pas qu'il y ait une bonne ou une mauvaise décision dans cette question. Cela dépend d'autres facteurs, à mon humble avis. Cependant, vous avez raison sur cet état d'esprit si sur d'autres solutions, ils doublent la LOE sans aucune indication directe pour le faire (certaines preuves que la complexité supplémentaire est requise pour l'évolutivité, la robustesse, etc.). Ma suggestion serait de faire participer le propriétaire du produit à ces conversations, car il doit aider à établir les priorités. Si votre solution est de 5 points, et qu'elle répondrait au besoin maintenant, mais ce qu'ils veulent faire nécessiterait 50 points et deux sprints ou plus, le PO peut dire "attendez, nous avons une version hautement prioritaire de ce MVP prévue et ne peut pas passer 2 semaines à créer des fonctionnalités qui ne figurent pas sur la feuille de route! "