Supprimer les dépendances entre back et front

Cet article vous fournit des lignes directrices pour maximiser votre travail en équipe. Il explique les concepts les plus importants qui permettent d’éviter les dépendances au lieu de les gérer.

Un article est comme un flux de pensées attrapées en plein milieu de leur mise à jour. Ce flux de pensées peux évoluer avec vos retours.

  • Qu’en pensez-vous ?
  • Est-ce applicable dans votre contexte ?
  • Contribuera-t-il à résoudre les problèmes que vous rencontrez ?

PS : Cet article est un fragment de l’apprentissage de mes neuf années d’expériences en programmation logicielle dont la dernière a été très instructive.

cc @lprost @Rachel @jplambert

2 « J'aime »

Hello, excellent sujet. Ce qui me fait peur c’est comment faire casser les dependances sans connaitre les implémentations. Comment prioriser ton backlog sans savoir à l’avance que c’est du front du back ou autre.
En général, je vois ces decoupages dans des équipes qui font des userstory par stack technologique ce qui esr une aberration pour moi. Où est le débit où est la valeur metier, comment valider les US alors qu’elles sont bouchonnées et donc n’iront jamais en prod sans toutes leurs dépendances.
Une bonne pratique de Dev, oui ça l’est. Est ce qu’on doit le transposer sur le backlog, pour moi, et ça n’engage que moi, non, surtout pas.
Je préfère découper dans l’autre sens, en vertical, fonctionnel. Les US auront une partie back et front, oui, il y aura plusieurs technos et devs sur la carte mais elle apporte une vraie valeur fonctionnelle, valeur métier.

Ça n’enlève rien à ton article. Ce sont des concepts Craft et ils sont bons.

2 « J'aime »

Merci pour ton retour Emmanuel.

Les tâches sont des tâches techniques comme sous-tâches d’un élément du Sprint Backlog.

Je comprends l’amalgame, merci pour ta vigilance.

Afin d’éviter la confusion, est-ce que je devrais l’expliquer dans l’article ?

Bonjour, et bonne année la communauté! :slight_smile:
Merci Alexandre pour cet article, il est super et je vais l’utiliser pour faire réfléchir mes équipes.
je suis d’accord avec le point soulevé par Emmanuel. c’est vrais que plusieurs équipe s’oublient dans la techno et les concepts dev au détriment de la livraison de fonctionnalité, création de la valeur à chaque sprint pour assurer le retour sur expérience avec les utilisateurs et avec les membres de l’équipe.
à mon avis c’est une nuance importante qu’il faut souligner dans ton article.

Merci encore
A+

Merci pour ton retour @Karim,

Contribuera-t-il à créer de la valeur dans ton contexte ? Seul l’avenir nous le dira.

Je vais ajouter cette précision avec l’idée que j’avais abordé dans ce post.

La confusion serait bien trop grave, au final ces concepts sont des outils permettant la création de valeur.

EDIT : La précision sur le terme « tache »

1 « J'aime »

L’article est top, dans le sens Craftsmanship
Ta question etait de savoir si on peut l’utiliser dans le monde l’agile, je dis oui, mais…

Ça n’enlève en rien la qualité de l’article

1 « J'aime »

Dans la même idée, je ne peux que te conseiller ce ebook qui vient de sortir J'ai sorti un nouvel e-book offert ! - by Pierre Criulanscy

1 « J'aime »

Permets moi de prendre un risque en essayant de compléter ta phrase.

Mais … il est important et indispensable de l’englober avec l’état d’esprit ciblé (ex. Agile). L’utiliser brute sans ce contexte serait contre productif.

Dans le monde agile, il y a une variété de compétences tous ne comprendront pas les principes car ils sont expliqués de manière trop abstraite pour eux. Mais pourquoi ? À mon avis, il manque au moins un exemple vraiment concret.

1 « J'aime »

Je suis critique de la définition de Martin (pour lequel j’ai une profonde aversion) sur le sujet. Créer des « boundaries » est seulement une partie de l’histoire et comme le dit une fameuse citation, « si on supprime toutes les dépendances, on se retrouve avec un sac d’objets ».

Pour faire écho ce qui dit @TheLimande, ce sont bien des use-cases que l’on vend au client, pas des détails d’implémentation. Pour éliminer les dépendances, et comme l’article le propose, l’une des meilleures solutions est le pair/mob/swarm programming (empiriquement et scientifiquement prouvé par plusieurs études, mais pour plus d’info, Woody Zuill est un des meilleurs porte-drapeau sur le sujet).