J’essaie de me préparer au passage de la certification PSPO 1 (Product Owner, niveau 1), et on m’a recommandé Volkerdon, qui est pas mal en effet.
Sauf que ça fait ré-émerger une question que je croyais avoir résolue !
Ca dit, en ligne 8 (voir capture d’écran + loin) : « Each increment is additive to all prior increments and thoroughly tested, ensuring that all increments work together ».
Yep, ça paraît en effet cohérent de s’assurer de cela, et c’est quasiment mot pour mot ce que le Scrum guide dit.
Mais le Scrum guide dit aussi : « If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. »
J’en déduis deux choses :
L’incrément ne peut pas être présenté en Sprint Review, ni « released » si il n’est pas testé dans un environnement où tout le code est mergé ensemble;
La DOD doit forcément contenir une partie « tests ».
Pourtant, j’ai plusieurs fois lu, ici et là, (en soulevant la question du « releasable » et « usable ») qu’un incrément pouvait très bien être présenté en Sprint Review, depuis le PC d’un dév, sur lequel un stakeholder pourrait tester l’item, isolément (sous-entendu « non mergé »).
Je me trompe certainement n’étant pas encore un véritable scrum master mais par experience :
en tant que développeur J2EE, nombreuses ont été fois où les développements distribués dépendaient fortement des socles architecture + librairies embarquées et donc demandaient un environnement stable inter libraires, testé de manière incrémentale auparavant.
Par ailleurs, nous avons rencontré des anomalies tordues qui suite à longues et fastidieuses analyses démontraient un comportement anormal provoqué par une version ou patch de l’OS en environnement prod différent du poste local.
Pour dire plus simplement, un test en environnement type Preprod est selon moi un pré requis.
Là où vous allez pouvoir compléter la réponse, c’est : Quand on parle DoD et surtout « Potentiellement livrable ». Quelle cible environnement est réellement attendue ?
La MOA, par exemple se contentait parfois d’exécuter la vérification en PreProd.
J’espère ne pas avoir embrouiller la question de départ Mais en tout cas votre réponse apportée à @Charlotte va fortement m’intéresser, surtout votre feedback d’expériences.
Dans l’idéal, en review on veut montrer le produit tel qu’il pourrait être shippé, voire tel qu’il a été shippé pendant le sprint. Et donc c’est pour ça qu’il faut viser une démo dans un environnement le plus proche de la réalité, le PC d’un dev étant l’environnement le plus éloigné de la réalité.
Si vous ne pouvez pas faire une démo autrement que sur le PC d’un dev, fondamentalement le boulot n’est pas terminé et donc l’item ne peut pas être présenté en review.
Maintenant, pour être pragmatique, le but de la sprint review reste quand même de collecter du feedback, et une démo même sur le PC d’un dev permet de collecter du feedback. Donc ça peut se défendre.
Il y a cependant un risque que les participants à la démo repartent en se disant « ah mais c’est bon ce truc on l’a vu en démo donc il est fini ».
Si vous présentez trop souvent des choses à moitié finies (ou « presque » finies), non seulement ça introduit de la confusion pour l’assistance, mais ça fait aussi penser à l’équipe que ce n’est pas super grave de ne pas avoir fini (« non mais ça va on fera une démo sur mon PC et on terminera au prochain sprint de toute façon »). Mais au-delà du fait que le statut « presque fini » est dangereux (un item peut y rester très longtemps…), il est possible que l’item « presque fini » ne cadre pas avec l’objectif du sprint suivant et que le PO décide de ne pas le finir.
Donc je dirais plutôt non pour présenter des trucs pas entièrement finis, sauf si les risques ci-dessus sont sous contrôle.
D’abord, j’ai un problème avec cette partie du Scrum Guide, parce que la DoD est contextuelle et très dépendante du flow de l’équipe. Je prend toujours le même exemple, mais une équipe qui considère que l’incrément est DONE quand les metrics en prod sont suffisamment en accord avec l’attendu ne montrera jamais rien en review.
Maintenant, et pour une vision plus « réaliste » de la chose, je propose un intermédiaire : Rien n’empêche de scinder le truc en deux. Ce qui est fini, puis après on parlera de ce sur quoi on a encore besoin de vos retours, a.k.a ce qui n’est pas fini mais ce serait dommage de pas prendre le feedback maintenant parce que sinon on l’aura que dans X semaines.
Ceci étant, tout ça n’est plus du tout une question si la prise de feedback est décorrélée de la review. Si vous présentez votre avancement en continu, prenez du feedback en continu, le besoin de « présenter le pas fini » en review commence tout d’un coup à ne plus avoir de sens.
Je viens un peu après la bagarre, mais si je reformule, le deuxième point indique qu’un item qui ne respecte pas la DOD n’est pas terminé, il ne peut pas être présenté en revue ni mis en production. Je pense qu’on est tous ok là dessus, c’est assez simple : si c’est pas fini, c’est pas fini !
Ce que le premier point dit concerne le cas où l’objectif du sprint prévoit l’intégration de plusieurs items. L’intégration d’un item peut en casser d’autres. C’est pourquoi on ne peut pas se contenter de tester les items séparément et puis intégrer en espérant que ça ne casse rien. On ne peut pas non plus intégrer tous les items d’un coup et faire un seul gros test final, car si un item a un problème c’est toute la version qui est rejetée. La stratégie recommandée est donc d’intégrer les items un-à-un, et à chaque fois de tester tous les items (sauf ceux qui n’ont pas encore été intégrés, évidemment) pour s’assurer que tout fonctionne correctement de manière incrémentale.
Si un item entraine des régressions ou des conflits, alors on rollback à l’étape précédente. De là, on peut continuer à intégrer d’autres items. Pendant ce temps, les développeurs qui travaillent sur cet item vont faire des adaptations pour résoudre les problèmes et présenter une nouvelle tentative plus tard.
Cette pratique s’appelle « intégration continue ».
L’intégration continue est en effet une procédure que j’ai pu vivre en tant que développeur (code) puis testeur recevabilité. Ce côté me plaisait ce regard sur l’intégration des évolutions ou corrections était prenante.
Par contre l’orientation bout en bout et évolution du métier de testeur m’a porté defaut (comble pour un testeur defauts / anomalies ) via les métiers de test tel Istqb.
En outre, je travaillais sur des projets waterfall, je n’ai pas eu la joie de connaître le test en approche Agile.
Je me dis que ça pourrait me plaire à nouveau mais l’automatisation de test à aussi pris le devant.
Quel métier considérerais tu pour se préoccuper de l’intégration comme énoncé ?
Hello, je ne suis pas certain de bien saisir la question. Il fut un temps où il y avait un rôle d’intégrateur au sein des équipes de développement, mais fort heureusement c’est derrière nous. L’intégration c’est le rôle des développeurs (sur le comment). C’est aussi - un peu - celui des SM / chef de projet puisque c’est aussi une question d’organisation (sur le quand).
N’hésite pas à donner des détails si ça ne répond pas à ta question
) via les métiers de test tel Istqb.