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.
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.
Bonjour, et bonne année la communauté!
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.
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.
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).
Le sujet rejoint celui sur le silo dev/test à mon avis (par rapport à la partie mobile vs web).
Dans le fond, est-ce que vous faite un produit ou deux ?
Si la réponse n’est pas la même sur la plan technique et produit, alors il y a un problème. En application de la loi de Conway, si l’équipe est organisée d’une certaine manière, alors cette organisation finira inévitablement par s’appliquer à l’architecture technique de la solution. Si on fait 4 équipes, on fera un compilateur à 4 passes.
Donc si on fait un seul produit (approche back-for-front), on peut avoir une seule équipe, mais l’architecture technique devrait s’aligner. Il serait donc pertinent d’adopter une approche par un développement fullstack. Ainsi il n’y a pas lieu d’élaborer une boundary, le front et le back sont dans la même application et la modification des 2 aspects est atomique du point de vue organisationnel. En plus de résoudre le problème de la synchronisation des membres de l’équipe, ça simplifie la matrice de compétences et ça réduit la complexité technique du produit à fabriquer.
Mais l’inconvénient de l’approche fullstack, c’est qu’elle ferme des opportunités en terme d’intégration. Si on est partis sur une architecture client-serveur, c’est parce qu’on a la (secrète) intention que le back ne soit pas exclusivement appelé par le client. Ainsi, le back mérite son propre design, avec un PO et sa roadmap, et sa propre équipe de développement. Tôt ou tard, les besoins venant du client actuel finiront par devenir les besoins d’un client parmi tant d’autres et il faut s’organiser à l’échelle. En revanche, il faut être clair avec le fait que cette approche coûte beaucoup plus cher car on doit monter 2 équipes.
