J’ai rejoins un nouveau projet, l’agilité est respectée dans les grandes lignes mais certaines choses me chagrines.
Parmis elles, je dois consacrer du temps a creer des solutions techniques pour les US de futures sprint. Visiblement ca fonctionnait comme ca avant.
J’y vois plusieurs soucis :
1 - J’ai l’impression de perdre mon temps
2 - Ca ne fait pas partie de mon sprint goal
3 - Certaines solutions techniques prévues des mois à l’avance sont obsolètes
4 - Le dev avec qui je bosse n’en tient pas vraiment compte et se focus sur le besoin métier sans lire la solution technique le plus souvent
5 - De mon point de vue c’est anti agile
Est ce que j’ai tort d’être contre cette methode de validation des US ?
Y a t’il d’autres éléments a prendre en compte ?
Merci à tous d’avance pour vos retour d’expériences !
Quand je lis ça, j’ai plusieurs questions qui me viennent:
Pourquoi l’équipe fonctionnait comme ça avant ? Qu’est ce qu’elle en retirait ?
Sur quels points ? Qu’est ce qui te dérange ?
As-tu un exemple en tête ?
Quel en est le résultat au final ? La solution fonctionne et répond-elle au besoin ? Détruit elle l’architecture du programme ? Pourquoi faites vous des prévisions plusieurs mois à l’avance ?
Pourquoi parles-tu de validation d’US ici ? C’est le seul moment où tu parles de ça de tout ton post, du coup je ne suis pas sûr de à quoi ça se rapporte.
Salut ! Pour une bonne compréhension de tes questions, je pense qu’il serait utile de savoir quel est ton rôle dans l’équipe : Product Owner ? Business Analyst ? Tech Lead ? Etc.
Merci pour vos réponses J’ai une position de tech lead
Je ne sais pas si il y avait un benefice avant.
J’ai l’impression de perdre mon temps parceque je réfléchis à des US pour des sprints pas encore lancés.
J’ai une maniere de fonctionner trés séquentielle, un problème après l’autre. Le fait de devoir analyser une US de manière technique me demande parfois beaucoup de temps que je ne passe pas sur le sprint en cours.
C’est notre second sprint je ne saurais pas dire pourquoi on fait cela et si c’est utile. Je ne comprend pas ta question dans le sens ou une US n’a jamais eu nécessité a prèsenter une solution technique mais plutot refleter un besoin métier.
Ce qui compte pour moi c’est que le dev évolue et corrige ses erreurs lorsqu’il y en a il s’ameliore a force d’essais erreures, je vérifie lors des pull request son travail en suivant scrupuleusement le besoin métier et je l’aide lorsqu’il est dans le besoin.
En revanche je ne souhaite pas figer une solution technique qui ne laisse pas de place à la creativité ou la réflexion.
En faite je dis validation mais c’est en réalité une sorte de definition d’US prête a être embarquée.
A vous lire il semble que ce soit commun de faire ce genre de chose, en 10 ans je n’avais jamais vu cela dans aucun projet scrum.
Ma question concerne plutôt le code écrit et la solution implémentée derrière. Si le code est de qualité convenable et que le besoin est couvert, peut etre que le travail en amont était au final inutile ?
Si tu veux mon humble avis, on est très peu ici à avoir vu de vrai équipe Scrum. Mais c’est ni une fatalité ni un absolu. Pour ce qui est de la ‹ Définition de Prêt ›, il y a un sujet un peu plus bas.
Par contre je suis toujours curieux des réponses que tu peux avoir à mes autres questions.
A vrai dire la qualité du code d’un dev Junior laisse à désirer peu importe que la solution technique soit apportée ou non, il y a toujours un delta entre ce qu’on veut, ce que l’on note, ce que l’autre dev comprend et ce qu’il crée (Je parle juste de technique ici pas de fonctionnel). Et c’est tout à fait normal je suis la pour cadré un peu ce qui est fait et faire évoluer dans le bon sens le développeur. De ce point de vue la je suis d’ailleurs hyper satisfait car en deux sprint on à fait de grandes avancées.
Je pense que niveau compréhension métier ils sont satisfait, c’est plus dans les estimations qu’on est pas bon pour le moment, et pour ce qui est de la qualité du code ca va aller de mieux en mieux à chaque sprint.
Pourquoi ne pourrait-on pas traiter d’US techniques ?
L’équipe Dev peut sensibiliser le PO des différents besoins techniques sur lesquels il y a besoin de consacrer du temps (montée de version de framework, changement d’hébergeur, modification d’infra …)
Le PO arbitre la priorisation entre ses besoins métiers et les besoins tech … tant que le sprint goal est tenu, tout le monde est content.
Je suis toujours un peu circonspect sur ce type de sujet, quand il est abordé sous l’angle général.
Tous les projets n’ont pas la même exigence en terme de qualité du code.
La qualité du code n’est pas en elle même un objectif. C’est un moyen d’atteindre les objectifs métier/fonctionnels.
Il m’est arrivé de croiser quelques tech lead obnubilés par « la qualité du code », cette posture presque intégriste était à mon sens une façon d’occulter des carences sur d’autres points …
En élargissant la question, j’aurai tendance à considérer que la « solution » technique n’est pas forcément à choisir au sein de l’équipe de Dev. Les Dev peuvent faire des propositions / suggestions mais qui sont arbitrées par une entité Archi qui connait les contraintes / exigences transverses, … mais évidemment, tout dépend de la taille du projet, de la structure, de l’écosystème
Ici je ne parle pas d’US technique mais de solution technique
Exemple : US 981 :
En tant qu’utilisateur avec le role Y je souhaite acceder à la page X cliquer sur scanner mes composant
Si le scan est 100% complet rediriger utilisateur vers … etc
Solution technique :
Verification d’acces a la page Y via authguard
Creation de l’appel api pour lancer les scans
Création d’un objet de type scanResults
Etc… etc…
Ce n’est pas forcement coherent c’est juste pour illustrer ce qu’on me demande.
Je comprend ce point de vue, je ne pense pas etre un tyran dans ce domaine par exemple mon cooequipier ne connaissait pas les usages de git, ce qui a causé des petits désagrément au premier sprint, on a bosser sur la factorisation du code, 1 composant avec les mêmes fonctions dupliquées rendant la maintenabilité du code plus complexe.
On me demande aussi de tester unitairement a hauteur de 75% de couverture. Faire baisser les alertes sonar etc…
Mon exigeance c’est de créer un code maintenable qui respecte l’exigeance du client autant sur le fonctionnel que sur le visuel
En cela je trouve que décider d’une solution technique en amont n’est pas optimal et ne me permet pas de gagner du temps au contraire, j’ai le sentiment inverse.
Je recherche donc un avis contradictoire ou non pour echanger sur ce genre d’expériences.
Dans le cadre de Scrum ? Si ! Pas d’archi, de lead, d’ops, de sénior. C’est l’essence même du fait qu’on ne parle que d’une équipe de dev. Le but c’est l’amélioration continue de tout le monde, pas d’une chasse gardée. Et tant pis si ça demande plus de temps.
Le but de scrum est l’efficience, un des éléments pour améliorer cette efficience est de réduire l’incertitude.
Le travail que tu réalises va dans le sens de la réduction de l’incertitude c’est donc louable, mais va a l’encontre de l’efficience, il faut donc remettre en cause ce processus.
Pour moi le travail que tu réalises n’est pas fait au bon moment et avec les bons interlocuteurs. Comme tu le dis parfois c’est fais trop tôt et la solution a changée et comme ça n’est pas toi qui réalise le sujet la solution n’est parfois pas adaptée au développeur.
Le travail que tu réalises, s’il ne correspond pas à la description d’enablers technique, doit être réalisé au sprint planning lors du découpage des US avec l’ensemble de l’équipe de dev.
Car se découpage réduit l’incertitude vous êtes donc plus a même de traiter le sujet dans le sprint et avec la bonne qualité.
Car cette description de solution est faite avec l’ensemble de l’équipe peu importe qui fera le développement, il y aura un consensus sur la solution choisie et ça sera donc la solution qui sera implémentée sauf cas exceptionnel où on découvre un problème lors de la réalisation.
Ça n’enlève en rien l’intérêt de ton rôle de tech lead, car tu participera à la conception, tu auras sûrement une meilleure analyse et si problème il y a tu seras là pour trancher et faire avancer le sujet si il faut avancer pour respecter les time box fixées.
Dans mon équipe Scrum actuelle, j’ai deux cérémonies additionnelles qui permettent à l’équipe de réaliser ce travail ensemble, et bien sûr le TechLead est un élément essentiel.
Nous sommes en Sprint de 3 semaines.
La semaine 2 & 3 du Sprint en cours, nous réalisons des séances de :
Backlog Refinement
3 Amigos (nous réalisons également ces séances pour les sujets du Sprint en cours si nécessaire)
Pour les sujets du(des) Sprint(s) suivant(s).
Pendant les réunions d’affinage surtout, la précision des US, leur redécoupage, les solutions techniques d’implémentation y sont définies par tout le monde.
Ces réunions étant préparées par chacun des participants, nous en sortons souvent avec une bonne idée de la solution finale.
Les réunions de Sprint Planning sont ainsi plus efficaces et non chronophages.
Effectivement il serait plus logique d’en parler au refinement ou sprint planning.
On fait aussi un refinement semaine 2 & 3 comme l’a indiqué plus haut Mohamed.
Le tout serait de trouver la manière la plus efficace pour écrire une solution technique viable mais pas trop restrictive pour ne pas perdre trop de temps. Lors de cet évènement le PO est présent et n’a pas de compréhension technique très pointue.
Je remet une pièce, mais un outil efficace pour désépaissir le mammouth, ça reste les use-cases. On dégage de la spécification fonctionnel sans énoncer de solution technique, et on s’inquiète des cas à la marge et cas d’erreurs en analysant le système dans son ensemble.
Ca c’est la théologie Scrum. On le fonctionnement dans une start-up de 10 personnes.
Mais il y a d’autres contextes : quand il y a plusieurs équipes Scrum affectées à des périmètres différents au sein d’un écosystème ? Chacune bosse dans son coin, drapée dans son « autonomie » ? Non. Pour que tout le monde atteigne l’amélioration continue souhaitée, tu es obligé de mettre en place des instance transverses.
Les Tech Lead se parlent régulièrement, font leur propositions avec l’Architecte technique qui seul dispose de la vision technique transverse nécessaire pour que tout fonctionne au mieux
Tout comme les PO se parlent chaque semaine, sous l’égide d’un Archi fonctionnel qui seul a la vision fonctionnelle globale de l’écosystème
Non.
A ma décharge, je suis Scrum Master pas CTO.
Et c’est le CTO qui est en charge de définir l’orga dans laquelle évoluent ses équipes.
Et il se trouve qu’il a instauré ce type d’instances transverses pour optimiser le fonctionnement des équipes au sein d’un écosystème d’applications…
Ceci dit, chaque orga / entreprise a ses spécificités, histoire, contraintes et la vérité de l’un n’est pas forcément la vérité de l’autre.
Ok. Ce que tu décris comme des instances transverses est couvert dans ce bouquin là et c’est l’un des ouvrages les plus important en terme d’organisation social sur le sujet. La théorie est étayé par de nombreuses études dans le domaine de l’anthropologie et de la sociologie. Tu as des « enabling team » dans lesquelles ce genre de compétences peuvent se retrouver, mais elle ne sont pas des postes à part entière. Le but est avant tout que les équipes communiquent entre elles leurs API, et que tout le monde ait un model mental aligné, parce que c’est l’un des premiers facteurs identifié et reconnu de performance des équipes. Et c’est bien toute la difficulté du travail de développeur: faire vivre la technique et le business dans un seul cerveau, de manière unifié à travers toute l’équipe. En déversant tout dans la tête d’un architecte « centralisateur », tu te crées un point critique qui, si tu le perds, rend la vie de ton organisation infernale d’une part, et d’autre part, refait apparaître les problèmes inhérent à la loi de Conway.
J’ai une position de tech lead
par exemple mon cooequipier ne connaissait pas les usages de git, ce qui a causé des petits désagrément au premier sprint, on a bosser sur la factorisation du code, 1 composant avec les mêmes fonctions dupliquées rendant la maintenabilité du code plus complexe.