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.
1 « J'aime »
system
(system)
Remonté automatiquement dans la liste ()
9
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).
