Inconvénients des user stories verticales

L' approche agile consiste à structurer le travail en histoires d'utilisateurs verticales et à fournir un élément ciblé mais pleinement fonctionnel de l'application de bout en bout . Parce que c'est la nouvelle approche de la construction de logiciels, j'ai lu beaucoup de littérature sur pourquoi c'est mieux que les histoires horizontales mais je ne trouve pas grand-chose sur les inconvénients de cette approche.

J'ai déjà bu le cool-aid agile et je suis également d'accord pour dire que le tranchage vertical du gâteau présente de nombreux avantages par rapport au tranchage horizontal. Voici une courte liste des inconvénients que je pourrais trouver:

• Un développeur peut initialement être plus lent à implémenter une fonctionnalité car il doit comprendre toutes les technologies nécessaires pour développer l'histoire (UI + couche de service + accès aux données + mise en réseau, etc ...)
• La conception globale de l'architecture (création de l'épine dorsale de l'application) ne correspond pas vraiment à ce mantra (cependant, certains pourraient affirmer que le développement / changement de l'architecture globale fait partie d'une histoire d'utilisateur)

Quels sont les autres inconvénients des tranches d'utilisateurs à découpage vertical?

Remarque: La raison pour laquelle je pose cette question maintenant, c'est parce que je vais essayer de convaincre une équipe de commencer à écrire des histoires de la `` manière verticale '' et je veux être en mesure de proposer à l'avance les compromis possibles afin qu'ils gagnent 't considérer l'approche comme un échec quand ils sont confrontés aux inconvénients.

Je ne connais aucun inconvénient à long terme. À court terme, et pour une équipe nouvelle dans ce type de développement, le principal inconvénient est qu'il faut un certain temps pour s'y habituer et un peu d'apprentissage.

La façon la plus efficace de travailler verticalement est d'avoir des développeurs full-stack: de cette façon, une histoire peut être typiquement exécutée par une seule personne (ou plus mais sans tâches de pipeline ). De toute évidence, cela nécessite que les développeurs travaillent verticalement sur la pile (du HTML à la base de données dans le cas d'une application Web).

Si votre équipe n'est pas habituée à travailler sur des histoires verticales, alors elles sont très susceptibles de faire le contraire: chaque personne n'aura connaissance que d'une couche / niveau de l'application. Lorsque vous introduisez des histoires verticales, vous pouvez vous attendre à ce que l'équipe les divise en tâches correspondant aux couches, puis distribue les tâches à différentes personnes. Ce sera très inefficace.

La meilleure approche que je puisse donner à ce sujet est de tolérer ce pipeline au départ tout en précisant que l'objectif à long terme est complètement différent. Demandez aux membres de l'équipe à travers le programme de paires de couches afin de bâtir la confiance et éventuellement permettre aux gens d'être complètement indépendants.

Je ne suis pas d'accord avec l'autre réponse selon laquelle cette approche engendre une dette technique. C'est possible, mais il en va de même pour toute autre approche.

J'ai beaucoup réfléchi à cette question.

Je pense qu'il est important de faire la distinction entre le découpage par responsabilités individuelles et le découpage par responsabilités d'équipe. Je vais concentrer cette réponse principalement sur les équipes de découpe.

Pour certains antécédents: J'ai travaillé dans des projets avec des développeurs full-stack, des développeurs single-tier, des équipes verticales (full-stack), des équipes horizontales (single-tier) et des équipes diagonales. Par équipe diagonale, je veux dire contenant tous les niveaux nécessaires pour une histoire, mais pas nécessairement tous les niveaux du système, et éventuellement contenant plusieurs développeurs se concentrant sur les mêmes niveaux; en d'autres termes, d'esprit vertical mais peut-être quelque peu horizontal en apparence ou en détail de mise en œuvre.

Récemment, j'ai travaillé dans un groupe qui est passé d'équipes horizontales à des équipes diagonales (presque verticales). Il a été particulièrement instructif de voir le même groupe de personnes aligné de deux manières différentes. Cela rend certains avantages et inconvénients assez clairs.

Je vais arrondir mon opinion jusqu'à présent avec la comparaison récapitulative suivante:

Équipes horizontales

Avantages:

• Favorise une bonne séparation des préoccupations et des niveaux faiblement couplés
• Gestion beaucoup plus simple de la répartition de la charge de travail
• Gestion facile par un responsable technique spécialisé
• Favorise la collaboration intra-niveau, les meilleures pratiques, la fierté et une culture d'excellence
• Aligne avec les modèles de communication naturels / émergents

Désavantages:

• Peut conduire à l'isolement des niveaux et donc entraver la communication entre les niveaux
• Active la culture de «bulle» de niveau si elle n'est pas atténuée
• Difficile de profiter du leadership généraliste
• Entrave les généralistes

Équipes verticales / diagonales

Avantages:

• Toutes les parties d'une user story en une seule équipe ("one stop shop")
• Aide spécifiquement à fournir des histoires à n niveaux en un seul sprint (bien que vous en ayez vraiment besoin?)
• Favorise la collaboration entre les niveaux et la croissance des compétences généralistes
• Soutient les généralistes

Désavantages:

• Gestion de la distribution de la charge de travail beaucoup plus difficile
• Permet une mauvaise séparation des préoccupations et des niveaux étroitement couplés
• Entrave la spécialisation en réduisant la communication intra-niveau; il est difficile de voir comment une culture de l'excellence pourrait naître de cette structure sans ajouter des comportements atténuants horizontaux / spécialisés

Je ne pense pas que l'appartenance à une équipe ait une solution unique. Il semble cependant assez simple que l'équipe verticale s'aligne mieux pour les organisations nécessitant une généralisation. Si vos ingénieurs sont généralistes et aiment travailler en full stack, c'est une très bonne raison de considérer les équipes verticales. L'équipe horizontale s'aligne mieux pour les organisations nécessitant des spécialistes. Si vos ingénieurs sont des spécialistes, c'est une très bonne raison d'envisager des équipes horizontales.

Comme d'autres l'ont mentionné, les structures / comportements secondaires qui tranchent dans l'autre sens peuvent aider à atténuer les inconvénients de l'un ou l'autre système. Un facteur atténuant intéressant est la durée du sprint. Les sprints courts rendent certains des inconvénients des équipes horizontales plus tolérables. Si vous pouvez construire le backend cette semaine et le frontend la semaine prochaine, cela pourrait être assez rapide?

Pour appliquer certains de ces principes proposés à un problème réel ... Je dirai que les tranches horizontales ont très bien fonctionné pour une équipe de développement SaaS très réelle sur laquelle j'ai travaillé et qui résolvait des problèmes techniques très difficiles à tous les niveaux ( où la spécialisation était à mon avis extrêmement importante), où la fréquence de livraison (et la fiabilité à une granularité / fréquence élevée) était essentielle au succès de l'entreprise. Veuillez noter que cette conclusion est pour une équipe très particulière du monde réel, et non une déclaration générale de supériorité du découpage horizontal.

Une mise en garde: je suis probablement partisan de ne pas croire aux prétentions de capacités généralistes de toute personne dans le monde du développement logiciel moderne sans preuve significative, bien que j'aie connu quelques rares généralistes exceptionnels. Je pense que la généralité est un ordre élevé (vertical?) En effet, d'autant plus que chaque niveau croît en complexité et avec la prolifération de langages / plateformes / frameworks / déploiements alternatifs, chacun répondant à des besoins différents. De nos jours en particulier, un cric de tous les métiers peut très facilement être un maître de rien. De plus, de façon anecdotique, je trouve que la plupart des individus veulent se spécialiser un peu, encore une fois à quelques exceptions près.

Le gros inconvénient que j'ai constaté est qu'il est difficile pour une équipe de construire l'application suivant une approche architecturale unifiée.

Au début du projet, tout le monde écrira ses couches isolément. Les histoires (et les couches impliquées) fonctionneront, mais en regardant le produit livré à la fin du sprint, il sera facile de voir les légères différences entre les idées architecturales de chaque développeur.

Ce genre de chose est inévitable, mais pas un bloqueur. J'ai essayé de lutter contre cela de deux manières:

1. Avoir de longues discussions sur la conception avec l'équipe avant de mettre en œuvre chaque histoire
   • Cela devient vite fatigant. Il est souvent trop tôt pour que quiconque prenne une décision éclairée, puis vous finissez par vous disputer sur des choses qui devront certainement changer de toute façon.
2. Allez-y et développez-vous dans un isolement relatif, en gardant à l'esprit que vous accumulez une dette technique .
   • La clé ici est de consigner la dette technique (architecturale) comme un problème. C'est quelque chose qui devra être remboursé.
   • Après quelques sprints, il sera plus facile de décider d'une architecture cohérente et unifiée. C'est à ce moment que vous devez demander un sprint de durcissement pour rembourser une partie de votre dette technique (refactoriser le code existant). Alternativement, vous pouvez le rembourser au coup par coup au cours des prochaines itérations du projet.

Le seul autre problème auquel je peux penser à part cela est qu'il y a généralement beaucoup de code passe-partout à ajouter au début d'un projet. Écrire des histoires de tranches verticales signifie que la vitesse de l'équipe sur les premières histoires sera artificiellement faible en raison de ce passe-partout prérequis ... mais tant que tout le monde est conscient que cela ne devrait affecter que les deux premiers sprints, alors tout va bien.

Je ne connais aucun inconvénient non plus, mais les histoires verticales peuvent être mal mises en œuvre.

Quand j'ai commencé ma carrière, j'ai rejoint une équipe qui était désireuse de faire de l'XP mais ils n'avaient aucune expérience avec cela. Nous avons commis un certain nombre d'erreurs lors de l'utilisation des user stories verticales.

L'un des problèmes que nous avons rencontrés lors d'un travail horizontal était que les fonctionnalités ne s'intégraient pas bien entre les couches. Les API ne correspondaient souvent pas aux spécifications, aux fonctionnalités manquantes et à de nombreux autres problèmes. Souvent, parce que le développeur de l 'était passé à autre chose, vous deviez soit les attendre, soit le faire vous-même.

Passer à la réalisation d'histoires verticales a résolu ces problèmes et réduit / éliminé le gaspillage de retravailler pour s'intégrer.

Il existe un certain nombre de pratiques XP qui prennent en charge cette façon de travailler. Tout le monde doit pouvoir travailler sur n'importe quel domaine et tout le monde est censé corriger les bugs qu'il trouve ( propriété du code collectif ).

Lorsque vous modifiez des histoires verticales, il peut être difficile de travailler dans des domaines que vous ne connaissez pas. La programmation en binôme peut aider, si vous n'êtes pas sûr de prendre quelqu'un dans l'équipe qui est en binôme avec eux. J'ai trouvé que la programmation par paire était le moyen le plus rapide de se mettre à jour avec une nouvelle base de code.

Sans propriétaires forts sur les couches, nous avons constaté qu'il y avait une certaine duplication émergente. Bien que ce ne soit pas un gros problème, nous devions nous assurer que nous pratiquions Refactor Impitoyablement (avec des tests appropriés à l'appui).

Bien que je mentionne un certain nombre de problèmes, je ne pense pas que les histoires d'utilisateurs verticales en soient la cause. En fait, cela a rendu les problèmes plus apparents. Après avoir effectué le changement, les problèmes n'étaient plus masqués entre les équipes ou les couches d'application.