Salut, Voici ce que l'on a sur notre équipe : 1. Création / Mise à jour de la documentation 2. Faire tester ou présenter la fonctionnalité à au moins un autre membre de l'équipe
Le plus beau, c'est quand le DoD est structurel et qu'on a plus besoin d'y penser. Si un incrément est déployé en production, c'est qu'il a passé le DoD. Là, encore, quand on bosse en lean, il y a plein d'astuces pour tester le DoD sur la chaine de production. En logiciel, le CI/CD est notre ami. De notre côté, > tests en dev avec coverage "suffisant" (e.g. test de comportements resistant aux changements), premier test du déploiement en env test, puis envoyé en preprod. > déploiement en env de preprod, test d'intégration avec des data très proches de ce qu'on a en production (pour l'instant c'est hyper basique de notre côté mais cela permet de vérifier les configurations). > en production, c'est la seule phase dans lequel on a une validation manuelle (cliquer "déployer"). Pour nous, c'est la où le "Acceptance Criteria" est vraiment vérifié car on essaye de minimiser la friction et accélérer la mise en prod. Le tout peut prendre moins de 15 minutes et est automatisé au maximum pour éviter les erreurs humaines. Les choses qu'on aimerait ajouté : - DevSecOps : des tests de sécurité automatique - benchmarker de la performance de chaque release - mettre à jour nos KPI et notre performance selon accelerate (deployment frequency, lead time, change failure rate, time to restore) Qu'en pensez vous ?
C'est super ! Merci beaucoup pour ce partage. Est-ce que de passer les tests d'acceptation juste avant la mise en prod ce n'est pas un peu tard ? Ou alors redondant, car je m'attends à ce qu'un développeur les ai vérifiés avant de dire qu'il a fini. À défaut, avez-vous envisagé d'automatiser les tests d'acceptation ? -- JP
Qu'en est il de l'observation des utilisateurs et des changements de comportement, autant du process que des acteurs ? Plus loin que l'aspect technique et l'automatisation, se pencher sur ce qui est exogène à l'équipe peut être un bon début... =)
Petite suggestion, quand vous mentionnez une vidéo 3 fois, ce serait sympa de mettre le lien dans la description pour qu'on puisse aller instantanément la regarder avant de continuer à voir celle ci ;) Sinon merci pour le super boulot !
Salut, je vois ce que tu veux dire ! On va voir ce qu'on peut faire 👍 Sinon, qu'as-tu pensé de cette vidéo ? Que retiens-tu en particulier ? Merci et à bientôt ! -- JP
Bonjour et merci pour cette vidéo très instructive. Un point d'éclaircissement : qu'est-ce que cela veut dire " demander à voir à quoi ressemble la Dod de l'équipe que l'on va rejoindre ? "
Salut, et bien par exemple en entretien d'embauche, peut-être lorsque tu es face à un des membres de la future équipe, tu demandes à voir leur Definition of Done. Ils peuvent te montrer sur leur ordinateur, ou dans leur open-space (ou partager leur écran s'ils sont à distance). Ou botter en touche s'ils n'en ont pas... Dans tous les cas leur réponse (ou non-réponse) est éclairante pour toi en tant que future embaucher. Tu peux aussi demander aux autres intervenants du cycle de recrutement, par contre ils n'auront peut-être pas la réponse directement, mais ils doivent pouvoir aller chercher ça et revenir vers toi après l'entretien. Est-ce que j'ai répondu à ta question ? -- JP
@@ScrumLife En tout sincérité, c'est un tout. Expliquer facilement et rapidement des termes complexes pour de nombreuses personnes. J'organise des Hackathons et c'est tout à fait dans l'esprit de ce qu'on attend d'une explication ou Pitch :-). Continuez c'est top. On apprend tout en s'amusant. Au top les gars.
La DoD pour que le gamin fasse sa chambre correctement! Merci Constantin! Et sinon une question. Que pensez-vous des DoD qui s'appliquent sur plusieurs niveaux? Dod pour une story, une feature, une relase?
Pour moi, j’y vois un danger : le silotage et l’effet tunnel. Qu’en dis-tu ? - Constantin
2 ปีที่แล้ว +1
Une approche que j'ai pour donner une première explication de la DOD (avec les défauts que cette explication comporte) c'est de dire: "C'est la liste des tâches qu'on devrait retrouver dans toutes les stories parce que pas encore un réflexe."
Bonjour Nicolas, cela existe déjà dans l'approche Kanban, avec un autre nom : les critères de sortie. Cela représente une checklist sous la forme de critères qu'un "ticket" doit remplir pour sortir de la colonne et passer à la suivante. Tu peux aussi avoir des critères d'entrée, qui liste là les critères que doit remplir un ticket pour entrer dans une colonne. -- Constantin
J'arrive avec mes gros sabots et ma casquette de metaphysicien : ça veux dire quoi 'Fini' si on considère que le produit est un organisme qui évolue relativement vis à vis des besoins de son public et des connaissances de l'équipe ? Et est-ce que, parce qu'une US est 'Fini', elle ne fait plus partie du périmètre d'inspection de l'équipe ? Pour en venir à ce que je veux dire, pour moi, une DoD s'apparente plutôt à une Definition of Deliverable: si l'incrément respecte tous les critères, il est livrable. Mais ce n'est que le début du chemin...
Remarque très pertinente. J’ai tendance à penser comme toi du coup on pourrait que c’est la réalisation d’un increment qui est finie ? T’en dis quoi ? - Constantin
@@ScrumLife Je persiste et signe sur ma notion de "livrable". La vie et l'observation d'un incrément continue même après la livraison, et la DOD ne se focalise que sur l'aspect "production/livraison". Je ne trouve pas ça satisfaisant d'utiliser une terminologie comme "fini" dans ce cas et je trouve qu'en terme de modèle mental, cela renvoie une notion qui n'est pas la bonne; "c'est livré, c'est plus de notre ressort, on a 'fini' le boulot".
Pour moi, une story finie et qui passe la DoD, ça veut dire qu'on livre et qu'on ne revient pas dessus. Ce qui n'empêche pas de récolter les feedbacks des utilisateurs/clients et de modifier le backlog en conséquence pour améliorer la fonctionnalité qui a été livrée précédement.
Je reformule : je sais ce que veux dire en termes de process 'livrer quelque chose'. Je ne sais pas et je ne vois pas l'utilité de me dire que j'en ai 'fini' avec quelque chose alors que je ne sais pas si des bugs ne vont pas apparaître après coup ou autre...
Qu'y-a-t-il dans votre Definition of Done ? C'est quoi votre DoD ?
Salut,
Voici ce que l'on a sur notre équipe :
1. Création / Mise à jour de la documentation
2. Faire tester ou présenter la fonctionnalité à au moins un autre membre de l'équipe
Le plus beau, c'est quand le DoD est structurel et qu'on a plus besoin d'y penser. Si un incrément est déployé en production, c'est qu'il a passé le DoD.
Là, encore, quand on bosse en lean, il y a plein d'astuces pour tester le DoD sur la chaine de production. En logiciel, le CI/CD est notre ami.
De notre côté,
> tests en dev avec coverage "suffisant" (e.g. test de comportements resistant aux changements), premier test du déploiement en env test, puis envoyé en preprod.
> déploiement en env de preprod, test d'intégration avec des data très proches de ce qu'on a en production (pour l'instant c'est hyper basique de notre côté mais cela permet de vérifier les configurations).
> en production, c'est la seule phase dans lequel on a une validation manuelle (cliquer "déployer"). Pour nous, c'est la où le "Acceptance Criteria" est vraiment vérifié car on essaye de minimiser la friction et accélérer la mise en prod.
Le tout peut prendre moins de 15 minutes et est automatisé au maximum pour éviter les erreurs humaines.
Les choses qu'on aimerait ajouté :
- DevSecOps : des tests de sécurité automatique
- benchmarker de la performance de chaque release
- mettre à jour nos KPI et notre performance selon accelerate (deployment frequency, lead time, change failure rate, time to restore)
Qu'en pensez vous ?
C'est super ! Merci beaucoup pour ce partage.
Est-ce que de passer les tests d'acceptation juste avant la mise en prod ce n'est pas un peu tard ? Ou alors redondant, car je m'attends à ce qu'un développeur les ai vérifiés avant de dire qu'il a fini.
À défaut, avez-vous envisagé d'automatiser les tests d'acceptation ?
-- JP
Qu'en est il de l'observation des utilisateurs et des changements de comportement, autant du process que des acteurs ? Plus loin que l'aspect technique et l'automatisation, se pencher sur ce qui est exogène à l'équipe peut être un bon début... =)
Petite suggestion, quand vous mentionnez une vidéo 3 fois, ce serait sympa de mettre le lien dans la description pour qu'on puisse aller instantanément la regarder avant de continuer à voir celle ci ;)
Sinon merci pour le super boulot !
Salut, je vois ce que tu veux dire ! On va voir ce qu'on peut faire 👍
Sinon, qu'as-tu pensé de cette vidéo ? Que retiens-tu en particulier ?
Merci et à bientôt !
-- JP
Bonjour et merci pour cette vidéo très instructive. Un point d'éclaircissement : qu'est-ce que cela veut dire " demander à voir à quoi ressemble la Dod de l'équipe que l'on va rejoindre ? "
Salut, et bien par exemple en entretien d'embauche, peut-être lorsque tu es face à un des membres de la future équipe, tu demandes à voir leur Definition of Done. Ils peuvent te montrer sur leur ordinateur, ou dans leur open-space (ou partager leur écran s'ils sont à distance). Ou botter en touche s'ils n'en ont pas... Dans tous les cas leur réponse (ou non-réponse) est éclairante pour toi en tant que future embaucher.
Tu peux aussi demander aux autres intervenants du cycle de recrutement, par contre ils n'auront peut-être pas la réponse directement, mais ils doivent pouvoir aller chercher ça et revenir vers toi après l'entretien.
Est-ce que j'ai répondu à ta question ?
-- JP
Très bonne vidéo ;-) à plus
Merci ! Qu'est-ce qui t'a le plus marqué dans cette vidéo ?
-- Jp
@@ScrumLife En tout sincérité, c'est un tout. Expliquer facilement et rapidement des termes complexes pour de nombreuses personnes. J'organise des Hackathons et c'est tout à fait dans l'esprit de ce qu'on attend d'une explication ou Pitch :-). Continuez c'est top. On apprend tout en s'amusant. Au top les gars.
La DoD pour que le gamin fasse sa chambre correctement! Merci Constantin! Et sinon une question. Que pensez-vous des DoD qui s'appliquent sur plusieurs niveaux? Dod pour une story, une feature, une relase?
Pour moi, j’y vois un danger : le silotage et l’effet tunnel.
Qu’en dis-tu ?
- Constantin
Une approche que j'ai pour donner une première explication de la DOD (avec les défauts que cette explication comporte) c'est de dire: "C'est la liste des tâches qu'on devrait retrouver dans toutes les stories parce que pas encore un réflexe."
Ce qui est pas mal dans cette définition c'est qu'elle intègre "l'informalisation" des process !
-- JP
peux-t-on avoir une DOD/DOR en flux kanban ? merci
Bonjour Nicolas, cela existe déjà dans l'approche Kanban, avec un autre nom : les critères de sortie.
Cela représente une checklist sous la forme de critères qu'un "ticket" doit remplir pour sortir de la colonne et passer à la suivante. Tu peux aussi avoir des critères d'entrée, qui liste là les critères que doit remplir un ticket pour entrer dans une colonne.
-- Constantin
J'arrive avec mes gros sabots et ma casquette de metaphysicien : ça veux dire quoi 'Fini' si on considère que le produit est un organisme qui évolue relativement vis à vis des besoins de son public et des connaissances de l'équipe ? Et est-ce que, parce qu'une US est 'Fini', elle ne fait plus partie du périmètre d'inspection de l'équipe ?
Pour en venir à ce que je veux dire, pour moi, une DoD s'apparente plutôt à une Definition of Deliverable: si l'incrément respecte tous les critères, il est livrable. Mais ce n'est que le début du chemin...
Remarque très pertinente. J’ai tendance à penser comme toi du coup on pourrait que c’est la réalisation d’un increment qui est finie ? T’en dis quoi ?
- Constantin
@@ScrumLife Je persiste et signe sur ma notion de "livrable". La vie et l'observation d'un incrément continue même après la livraison, et la DOD ne se focalise que sur l'aspect "production/livraison". Je ne trouve pas ça satisfaisant d'utiliser une terminologie comme "fini" dans ce cas et je trouve qu'en terme de modèle mental, cela renvoie une notion qui n'est pas la bonne; "c'est livré, c'est plus de notre ressort, on a 'fini' le boulot".
Pour moi, une story finie et qui passe la DoD, ça veut dire qu'on livre et qu'on ne revient pas dessus. Ce qui n'empêche pas de récolter les feedbacks des utilisateurs/clients et de modifier le backlog en conséquence pour améliorer la fonctionnalité qui a été livrée précédement.
Donc ça vient à revenir dessus non ? Ou alors j'ai pas compris.
Je reformule : je sais ce que veux dire en termes de process 'livrer quelque chose'. Je ne sais pas et je ne vois pas l'utilité de me dire que j'en ai 'fini' avec quelque chose alors que je ne sais pas si des bugs ne vont pas apparaître après coup ou autre...