Tickets présentés en démo appartiennent à des Sprints antérieurs/terminés

[Charlotte (Charlotte HALPERN)]

Bonjour,

Mon équipe a considéré qu’un ticket n’était démontrable, pendant la Sprint review, que s’il est déployé en préprod (ce qui se tient, puisqu’on n’est pas censé pouvoir présenter un ticket qui n’est pas « fini » (DOD), et un incrément n’est pas considéré comme tel, s’il n’est pas « usable »)

Sauf que nos tickets ne sont jamais déployés en préprod avant la fin du Sprint…

On se trouve donc à faire la démo de tickets de Sprints antérieurs à celui qu’on est censé « review ».

Vous faites comment, vous?

Merci d’avance pour vos témoignages et conseils concrets!

[Samuel_Abiassi]

Posez vous peut être la question de pourquoi vous faites ce que vous faites ? (dit sans animosité ni cynisme)

[Charlotte (Charlotte HALPERN)]

« Témoignages et conseils concrets », c’était ma demande…

Je ne refuse pas de me poser des questions, mais encore faudrait-il qu’elles soient claires.
Là, vous ajoutez de la confusion à la confusion.

Merci de votre compréhension.

[Laurea (Anne-Laure Jean)]

Bonjour.
Le déploiement intervient combien de temps après la fin du sprint ? Est ce possible de décaler cette fin de sprint après le déploiement ?
Autre solution à chaud : revoir la Dod !

[jgranier (Jonathan Granier)]

Bonjour,

Parfois on démontrait l’increment sur l’env de recette, la actuellement on le fait sur l’env de dev car on a plus de contraintes.
Le but est d’avoir cet incrément ou tous les éléments sont assemblés ensemble. Le fait de le mettre sur un environnement autre que local, permet de s’approcher des conditions de l’environnement de prod.

Il y a toujours une approche devops, qui permet aux dev de déployer simplement sur un env pour tester/démontrer.

En l’absence de process devops efficace et d’environnement disponible, il est aussi possible de démontrer sur un poste de dev ou celui du Po. Tant qu’il s’agit de l’increment qui est potentiellement livrable.

[nicobiot (Nicolas BIOT)]

Bonjour Charlotte,

La DoD définit ce qui vous permet, de manière univoque, de considérer que le travail est fait. Si vous considérez de manière univoque que le travail fait est opérationnel en pré-prod, alors vous devez anticiper dès le sprint planning cette exigence :

Prenez moins d’items en sprint planning afin de garantir que le travail effectué sera fini.

[Samuel_Abiassi]

Oh… le conseil était concret.

Mais je vais aller plus loin (et être un poil plus cynique pour le coup, désolé ^^') :

Dans ton post de départ, le seul point que je « lis » comme étant un problème, c’est que vous « [faites] la démo de tickets de Sprints antérieurs à celui qu’on est censé « review »… ».

Du coup, je me pose plusieurs questions :

Pourquoi vous ne faites que la démo de ce qui est « fini » (selon votre DOD) ? Si c’est simplement pour faire de la présentation avant la mise en prod’ sans prendre de feedback, je n’ai pas de problèmes avec ça. Au pire, ça tiens les parties prenantes informés de ce qui arrive.

Pourquoi vous ne mettez en préprod qu’à la fin du sprint ? Si c’est pour des soucis d’infrastructure, de process vis à vis d’un prestataire ou autre, je n’ai pas de problèmes avec ça. Au pire, ça permet d’être sûr qu’on ne gaspille pas du temps à repackager à la main pour rien.

Pourquoi vous ne démontrez que sur l’environnement de préprod ? Si c’est pour vous assurer que « ça marche » avant de livrer, je n’ai pas de problèmes avec ça. Au pire, ça fait une repasse sur la QA devant tout le monde.

Je grossi le trait, mais mon propos est le suivant:

Il y a ce qu’il y a marqué dans le scrum guide, et il y a le « pourquoi » caché derrière. Si votre process fait que vous ne reviewez que le sprint précédant, je me poserais déjà clairement la question de pourquoi le process actuel est tel qu’il est. Si le scrum guide demande que ce soit l’analyse du sprint actuel qui soit faites, je me poserais la question de pourquoi le process actuel « permet » de s’en absoudre et de pourquoi ce n’est apparemment pas un problème pour les parties prenantes.

[Charlotte (Charlotte HALPERN)]

Je ne suis pas sûre de maîtriser toutes les raisons qui font que les dév décident de déployer à tel moment plutôt qu’à tel autre, mais au minimum, c’est quand la QC (testeuse en titre) a fini de vérifier que tout fonctionne toujours bien, après que les codes des différents tickets aient été fusionnés (‹ merged ›).
Et selon mes observations, c’est souvent plusieurs semaines après la fin du Sprint.

Concernant la DOD, à vrai dire, actuellement, la nôtre est incohérente (elle mentionne qu’un incrément est fini quand son code est déployé en Production. Si l’on part du principe Scrum que « If a Product Backlog item does not meet the Definition of Done, it cannot be released », on a là un serpent qui se mord la queue).

J’ai prévu une réunion pour en parler et qu’on arrive à considérer l’incrément comme ‹ done › quand il est accepté par la Product Owner (qui teste elle-même les tickets, sur un environnement dédié à cela).

[Charlotte (Charlotte HALPERN)]

Si je te suis bien (c’est là qu’on voit que mon absence de background technique est un problème…), dès lors qu’on peut merger les codes des différents tickets du Sprint sur un environnement (même si ça n’est « que » notre environnement Develop, par exemple), on pourrait très bien présenter notre travail?

[Charlotte (Charlotte HALPERN)]

Merci pour le conseil.

Je crois comprendre, notamment grâce à ta réponse, que notre souci vient du fait qu’il y a une longue phase de test après les développements.
La QC, puis la P.O. font des tests sur des environnements dédiés, après que les dév aient fini leurs développements.

Si on minimise le nb d’items à développer dans un Sprint, les dév risquent de se tourner les pouces en attendant que les testeuses aient fini.
Peut-être pourraient-ils occuper leur fin de Sprint en se chargeant des tickets de bug, du coup?
Mais parfois, on n’a pas le choix du moment, quand il s’agit de bugs urgents…

Comme on n’a pas de vrai « démo » (ni de vraie Review!) parce que les stakeholders ne viennent pas, (et que personne ne semble souhaiter qu’ils viennent!), on enregistre une démo d’un ticket déjà déployé en Preprod, et la vidéo sert de démo ET de tuto!

Je suis assez découragée de ces process que je n’arrive pas à faire évoluer, et que j’ai même du mal à comprendre, j’avoue…

[Charlotte (Charlotte HALPERN)]

Merci!

Si c’est simplement pour faire de la présentation avant la mise en prod’ sans prendre de feedback

Mais, c’est exactement ça, hélas : on n’a pas de vraie Sp. Review, on n’a pas de vraie « demo ». On fait la Review sans stakeholders (raisons « historiques » d’une Review qui a fait mal aux dév, parce que les stakeholders étaient indisciplinés, réprobateurs, etc. + réticence de la P.O. pour je -ne-sais-quelle raison + stakeholders surchargés qui n’auraient pas le temps).
Bref: on débriefe sur le Sprint passé, ce qu’on a atteint, pas atteint (encore puis-je me targuer d’avoir fait adopter la coutume de définir un Spring Goal!), mais pour la démo et les feedback, ça tient en l’enregistrement d’une vidéo de démo d’un des tickets, déjà déployé en Préprod.
Cette vidéo sera visionnée par la P.O., qui la validera (ou pas), puis devrait la proposer aux Stkh, qui pourraient, théoriquement nous faire des retours dessus.

Pourquoi vous ne mettez en préprod qu’à la fin du sprint ?

Ce que je comprends du process, c’est que ça semble plus économique pour l’équipe de rassembler les tickets, et de les déployer par paquets.
Mais je n’en sais pas plus… (j’ai du mal à me faire expliquer clairement les raisons de tel ou tel process, et comme je subis une certaine hostilité d’une des membres de l’équipe, je n’ose pas toujours insister pour avoir mes réponses…)

Pourquoi vous ne démontrez que sur l’environnement de préprod ? Si c’est pour vous assurer que « ça marche » avant de livrer,

Oui, c’est au moins l’un des arguments avancés par l’équipe.

Si le scrum guide demande que ce soit l’analyse du sprint actuel qui soit faites, je me poserais la question de pourquoi le process actuel « permet » de s’en absoudre et de pourquoi ce n’est apparemment pas un problème pour les parties prenantes.

D’accord, je vais me poser ces questions alors, que, cette fois-ci, j’ai comprises!
(et je vais aller interviewer le manager-Scrum Master précédent, qui saura peut-être m’expliquer comment/pourquoi on en est arrivés là)

Merci encore!

[jgranier (Jonathan Granier)]

On merge des branches qui possède du code dans d’autres branches. Il y aura une branche qui aura tous le code correspondant à tous les items de l’increment.

C’est cette branche (cet incrément) qui sera déployé sur un environnement.

Par exemple quand on merge sur la branche « principal e » si tous les build/test/etc sont ok ça peut déployer automatiquement sur un environnement. A ce moment là on ne se pose plus de question, c’est automatique. C’est tout l’intérêt du devops.
On a plus qu’à utiliser l’appli sur l’environnement en question.

[nicobiot (Nicolas BIOT)]

J’avais commencé à répondre à ton thread d’il y a une semaine, mais au final je ne l’avais pas fini, mais vous êtes sur un vrai problème d’engagement dans votre équipe, du moins c’est ce que je ressens, et excuses-moi d’être aussi direct…
Il semble qu’il y ait 2 ou 3 camps dans cette « équipe » : PO et PPO d’un côté, les devs de l’autre et toi au milieu
L’engagement de l’équipe est primordial, tu ne pourras pas instaurer des pratiques agiles si les membres de votre équipes manquent autant de confiance les uns les autres

Dans l’idéal la PO doit tester plus tôt, les développeurs doivent tester aussi, ils doivent améliorer leur flux, favoriser les petites tâches et les livraisons « au fil de l’eau » pour espérer atteindre les objectifs

Mais si tout le monde est en méfiance, ben chacun reste sur son pré carré pour ne pas se découvrir et se mette à la faute

IL y a surement à mettre en place des initiatives comme le delegation board par exemple (management 3.0) afin que les équipiers gagnent en responsabilité et autonomie

[Charlotte (Charlotte HALPERN)]

Eh bien, il me semble que c’est comme ça que ça se passe, oui.

Selon un schéma de notre process, fait par le dév senior lui-même, les déploiements sur Develop, d’une part, et sur Master, d’autre part, se font automatiquement, à partir des branches Git concernées.

Mais il semblerait qu’il y ait une manoeuvre à faire entre Develop et Master (la « Release ») qui nécessite d’écrire un Tag, et de faire je-ne-sais-quoi, manuellement, pour que le code passe de Develop à Master (Préprod).

Je crois que je vais re-demander à l’un des dév de me faire une petite leçon sur tout cela, parce que je n’y vois pas clair du tout!

[Charlotte (Charlotte HALPERN)]

Merci Nicolas,

Tu vois juste quant aux « camps », oui!

C’est ainsi, en effet : notre propre management nous enjoint à ne pas être transparent-es avec notre commanditaire. Nous savons que la P.O., la PPO et les nouveaux responsables chez le commanditaire, sont méfiants à l’égard de notre boîte, pensant être en présence d’arnaqueurs (pour faire court), pinaillent sur le moindre centime, etc. = ambiance pourrie, qui empêche la transparence, notamment, mais aussi la collaboration directe (on ne doit rien déclarer, rien dire, sans avoir fait vérifier par le management que c’est dicible! => on marche sur des oeufs continuellement).

Bref.

Mais je n’ai pas compris en quoi ce problème de confiance pouvait expliquer la réticence de l’équipe à livrer « au fil de l’eau », par exemple.

Et qu’appelles-tu des « petites tâches »?

Merci!

[nicobiot (Nicolas BIOT)]

Des employés qui n’ont pas confiance vont limiter le risques dans leurs actions quotidiennes. Dans le cadre de développeurs ça peut se traduire par :

• se référer systématiquement à la spec et à ce qui a été écrit ou dit par le PO
• attendre les consignes
• livrer le plus tard possible pour s’assurer que tous les cas de tests prévus par le PO sont testés et éviter les reproches
• livrer le plus tard possible pour repousser le contrôle du PO et bloquer le PO dans le temps qu’il aura pour tester et faire remonter des défauts
• etc.

Des petites tâches j’entends le résultat du découpage des US en petites parties, livrables au PO ou son acolyte, pour obtenir rapidement du feedback et non pas des reproches
Il faut accepter que plus il y a de feedbacks pendant la durée du sprint, plus la qualité sera probablement meilleure

Donc j’en reviens à tester des sprints avec un objectif atteignable, qui regroupe un certain nombre d’US ou item de backlog de manière plus générale, qui pourront être bien découpée pour pouvoir être livrées tout au long du sprint et obtenir le feedback des PO:PPO:StakeHolder
Une option peut aussi être de tester la réduction du sprint à 1 semaine, pour garantir un focus très fort sur un petit objectif et commencer à prendre des bonnes habitudes.

[Charlotte (Charlotte HALPERN)]

OK, merci!

Entre temps, j’ai pu avoir des éclaircissements sur les raisons pour lesquelles on procède comme on procède actuellement, qui fait qu’on ne présente que de « vieux » tickets à nos Sprint Reviews (« vieux » du précédent Sprint voire de l’avant-dernier).

L’organisation actuelle fait que les tâches des dév et de la QC sont très distinctes : le dév dans le Sprint en cours, les tests finaux (sur Preprod) dans le suivant.
Il est difficile d’envisager des livraisons « au fil de l’eau ».

Il y a au moins deux raisons :

• la mise en production est manuelle sur chacun des 6 serveurs concernés = elle prend du temps, et il est plus économique de grouper les tickets
• les tests sur la Préprod (tests de charge/régression ) prennent 3 jours au minimum à la QC que ce soit pour 1 ou 10 tickets = idem que ci-dessus, il est plus cohérent de grouper les tickets.

Et, un peu à l’image de ce que suggère @Samuel_Abiassi, si je me pose la question de savoir en quoi c’est problématique (notamment de présenter des « vieux » tickets), il ne me vient que deux arguments mollassons :

• Quand on aura une « vraie » Sprint Review, avec des parties prenantes, on risque d’avoir une Review scindée en deux avec des échanges qui porteront sur le déroulement du Sprint passé, d’une part, et des échanges sur des tickets/features qui n’en faisaient pas partie, d’autre part.
  Ca semble bizarre, mais concrètement, je ne suis pas sûre que ça serait problématique…

• Il se passe 6 semaines environ entre l’entrée d’un ticket dans le Sprint backlog et le moment où il est livré. Ce qui ne semble pas très « agile ».

Quoiqu’il en soit, j’ai commencé à suggérer à un des dév (celui que je comprends le mieux) qu’on pourrait peut-être organiser nos Sprints de 3 semaines en 2 semaines de dév + 1 semaine de tests. Sur la dernière semaine, les dév feraient de la update de documentation, du support, de la formation, etc. pendant que la QC ferait son job.

On aurait alors peut-être la chance, non seulement d’avoir des Sprint Review « carrées » (les tickets seraient déployés en Préprod pendant le Sprint => présentables pendant la Review du Sprint concerné) mais aussi de pouvoir livrer les tickets en Prod au moins une fois par Sprint, à la fin, après les tests de la QC.
On livrerait moins en quantité, puisqu’on mettrait moins d’items dans le Sprint backlog, mais de façon cohérente avec le Sprint en cours ET possiblement avec un résultat de meilleur qualité (doc mise à jour, dév formés, etc.).

Est ce que ça vous inspire quelque chose? @Laurea, @jgranier et toute autre personne qui aurait eu le courage de me lire?

Merci encore à tous-tes pour vos interventions en tout cas, ça m’a aidée à y voir plus clair !

[Laurea (Anne-Laure Jean)]

Bonjour @Charlotte, j’ai envie de te dire : à tester sur quelques sprints!

[jgranier (Jonathan Granier)]

Je me suis souvent poser la question de faire comme vous faites, intégrer la QC dans le sprint. Car j’ai toujours fonctionné autrement.

De mon expérience j’ai testé 2 cas :

• 1: On fait la revue avec l’increment qui sort du dev. Ensuite, hors sprint du coup, il y a une recette, qualification, tir de perf, etc… Suite a tous ce QC ils décident si oui ou non ils mettent en prod
• 2 : la recette est intégrée au sprint et ils testent dès qu’un sujet sort du dev. On a arrêté ça car la fin de sprint était compliqué a gérer pour la recette. Il y avait des régressions qui poussait a refaire la recette du début…

De mon point de vue le cas 1 permet d’être assez flexible. Pourquoi attendre une semaine de test, pour se rendre compte qu’en fait ce qui a été dev n’est pas ce qu’on souhaite?
Autre point, je trouve plus optimale de faire la doc, en même temps que l’implémentation. Autrement on a le temps d’oublier et il faudrait revenir dessus. Cette semaine que tu décrit me fait penser à la période d’IP dans SAFe, qui fait un peu « zone tampon/fourre tout si on se plante avant » qui risque d’être peut optimisée.