Je suis dans une organisation qui cherche à faire un passage vers l’agilité parce que nous pensons réellement que ça serait la bonne solution, mais au final, nous avons vraiment beaucoup de contraintes qui nous empêchent de « tout casser » et de faire un passage drastique. Si bien que nous essayons plutôt la méthode douce et d’intégrer des éléments et des méthodes tranquillement, une à la fois et à notre rythme.
Enfin bref, nous en sommes à intégrer la fameuse définition de terminé ou fini (DoD) et je suis en charge de faire une première version, un point de départ, mais nous n’avons pas grand chose à l’interne sur quoi se baser. J’ai pas mal écouté toutes les vidéos de Scrum Life sur le dossier, j’ai aussi télécharger les DOD KARDS, mais même s’il est mieux de la « laisser émerger », ça serait quand même bien de profiter de l’expérience de la communauté. Et donc, j’aimerais avoir des exemples plus concrets des éléments qui sont vraiment essentiels à une bonne DoD.
Selon vous, quels sont vos incontournables de la définition de terminé (Definition of Done / DoD) ?
Bonjour,
est-ce que pour commencer, la DoD ne pourrait pas juste contenir les pratiques en place dans l’équipe ? Cela permettrait dans un premier temps d’apporter la transparence technique pour tous les équipiers.
Déjà que l’équipe s’aligne sur les pratiques des partenaires et que les gens en discutent est un point de départ.
Ensuite, vous verrez comment étoffer la DoD si nécessaire.
Vous avez déjà mis quoi en oeuvre comme pratiques agiles ?
Les incontournables de la D.O.D. sont ceux qui n’y sont pas
(Mince encore une réponse à la Moosh)
Les points d’attention de la DOD sont ceux qui ne sont pas encore ancrés dans les pratiques.
Ce qui ne vient pas encore naturellement, par réflexe, par habitude.
Le but de la DOD c’est de créer ce réflexe en martelant à chaque conclusion d’un item de backlog de sprint, des points d’attention qu’on risquerait d’oublier.
A la maison on a une checklist qu’on reprend à chaque départ en vacances.
la tente famillialle
le spot
la gazinière de camping
une cartouche de gaz
…
Sur cette liste, je n’ai pas écrit
la voiture
le coffre de toit
les enfants
ma chère et tendre épouse que j’aime de tout mon cœur
…
pourtant je vous assure que je les prends avec moi.
La DOD c’est ce qu’on a peur d’oublier, et les « incontournables » on ne les oublie pas.
Bon ok, c’est une façon d’insister sur l’idée qu’elle ne doit pas être exhaustive, mais courte et pratique.
Si elle est trop longue, c’est qu’il y a un autre problème.
Alors, on va dire qu’il y a des éléments qu’on retrouve souvent et que je suis un gros fainéant donc j’ai posé la question à chatGPT
Voici quelques incontournables à inclure dans la définition de terminé :
Les critères de qualité : il doit être précisé les normes de qualité requises pour le travail terminé. Les critères peuvent inclure des tests d’acceptation, des tests unitaires, la validation du client, la conformité aux normes de sécurité, etc.
Les critères de performance : la performance doit être mesurée et les objectifs de performance doivent être clairement définis. Les critères peuvent inclure des tests de performance, des temps de réponse, la résilience et la disponibilité.
Les critères de documentation : tous les documents pertinents doivent être créés et finalisés, y compris les spécifications, les manuels d’utilisation, les instructions d’installation et les rapports de tests.
Les critères de livraison : la livraison doit être planifiée et les modalités de livraison doivent être convenues, notamment les dates de livraison, les modalités de livraison, les processus de validation et les contrôles de qualité.
Les critères de validation : les tâches doivent être validées par les parties prenantes concernées et les résultats doivent être documentés.
Les critères de maintenance : les processus de maintenance et de support doivent être clairement définis pour garantir que le travail livré reste opérationnel et maintenu dans le temps.
Ca me fait d’ailleurs penser que parfois un élément de la dod devient une tâche de la story pour insister sur se prise en compte et pouvoir l’attribuer
Parfois une tâche qu’on retrouve dans toutes les story devient un élément de la DOD pour économiser de la logistique.
Nous avons implanté un Kanban correct qu’on supporte maintenant avec Jira comme canevas, ainsi que quelques rencontres récurrentes comme une session de planning en début de semaine et une rétro à toutes les 3 semaines. SCRUM est hors de question en raison du nombre de contraintes auxquelles nous faisons face.
Ça, c’est pour les méthodes, mais surtout, nous sommes en train de faire un changement de culture où on tente d’appliquer au maximum les 4 valeurs et 12 principes Agile en considérant l’existant et nos contraintes. Par exemple, nous produisons plus petit et beaucoup plus fréquemment. Notre principal défi en ce moment, c’est de fermer les tickets, car nos experts métiers ont beaucoup de difficultés à les reconnaitre comme terminés et la planif devient difficile, car n’importe quand, un vieux ticket qu’on croyait terminé peut nous revenir en urgence et on doit tout casser et replanifier pour inclure le vieux machin.
C’est pour ça que les DoR et DoD sont maintenant une priorité pour nous. Comme ça, on s’entendra sur celles-ci et dire: « Non, votre ticket est terminé selon notre DoD et pour votre demande, ça va, mais elle devra passer la DoR. Si vous voulez éviter cette situation à l’avenir, la DoR va vous aider avec ça, mais assurez-vous de mieux définir ce que vous voulez ».
Est ce que vous avez mis en place des reviews avec les parties prenantes afin de leur montrer comment vous en êtes arrivé à l’incrément ? que les éléments initiaux du ticket qui vous ont été fournis en entrant et qui fournisse pour eux une DoR tacite ont été respectés et confrontés à votre DoD ?
En mettant tout le monde autour d’une table ça permet que chacun débattre de ce qui était attendu et non demandé et ce que vous avez compris et validé.
Ainsi vous pourriez aussi itérer en améliorant la DoR avec eux afin qu’ils saisissent l’importance de bien expliquer leur besoin.
Vous avez un PO ou du moins quelqu’un qui accompagne les métiers ?
Tu tiens quel rôle dans l’organisation ?
Nous n’avons pas encore de DoD ni de DoR et nous voulons en faire une première version, d’où ma question. Je suis un analyste de profession et puisque nous sommes dans les débuts de la transition et je suis un peu celui qui mène le mouvement vers la transition Agile. L’équipe est super ouverte à me suivre dans ça et ils comprennent bien que le statu quo n’est pas envisageable, ce n’est pas le problème, mais je me trouve évidement à faire un peu le travail de Coach Agile (alors que n’ai pas vraiment vécu de transition par le passé), de SM et de Proxy PO pour lubrifier un peu tout ça.
En parallèle, je termine aussi un cours de gestion de projet Agile à l’université.
Malgré les défis, on constate déjà beaucoup de positif et clairement, nous avons un mouvement de rigueur au niveau des façons de faire qui se développe dans l’équipe. Bref, le monde commence à embarquer avec plus d’ardeur, car ils voient les effets, mais disons qu’ils ne sont pas encore rendu à faire leur veille eux-mêmes et ils attendent un peu de voir, c’est quoi la prochaine chose que je vais leurs amener. J’y vais donc en fonction de nos besoins les plus pressants et le projet sur lequel je suis embarqué sert un peu de laboratoire pour le reste de l’équipe.
En somme, disons que SCRUM Life et sa communauté est d’une très grande utilité dans les circonstances.
Le chemin vers l’état d’esprit Agile est inatteignable. Ce n’est pas un objectif, mais seulement un outil.
Le Graal c’est l’amélioration continue.
Votre mise en place des rétrospectives toutes les 3 semaines est un premier pas, bien joué.
À mon avis, 3 semaines c’est long. Sauf si le feedback sur les tâches de rétrospective prennent 3 semaines. Mon conseil, c’est de réduire progressivement cet intervalle. Jusqu’à ne plus avoir besoin d’un événement programmé, car quand un problème survient l’équipe n’attend pas pour se réunir et appliquer le PDCA pour essayer une solution.
Je focalise sur la problématique suivante.
Car créer une DoD est une solution parmi d’autres.
Indicateur de succès
Par exemple, il est très facile de savoir si un ticket est terminé.
Idée de solution : ATDD
Naïvement, j’inviterai à la mise en place de la pratique des « Tests d’acceptation (ATDD) ». À ne pas confondre avec les critères d’acceptation qui cible le besoin de l’utilisateur final.
ATDD produit des spécifications exécutable construit eetn collaboration avec le métier et à destination du métier.
Son prérequis est une proximité des experts dev avec les experts métier, sans aucun intermédiaire.
Idée de solution : DoD
Le fameux contrat de terminé : créer par les experts dev qui s’engagent à le respecter.
Inspiré des promesses de l’artisanat logiciel. Cette DoD demande une certaine maturité.
Le code ne nuit pas à la société, aux utilisateurs, à l’entreprise et à ses employés.
Il y a une preuve rapide, fiable et reproductible que le code fonctionne comme il ce doit.
La structure du code est améliorée. Le code est facile à tester, changer, réutiliser.
L’incrément est livré à l’utilisateur final.
À mon avis, les deux premiers points sont indispensables pour résoudre la problématique ciblée.
Le 3ème permet de conserver un code maléable. Ce qui permet de conserver une productivité constante.
Acceptance Test: A test written by the business for the purpose of ensuring that the production code does what the business expects it to do. The authors of these tests are business people, or technical people who represent the business. i.e. Business Analysts, and QA. source
En gros, nous développons des solutions BI pour notre PGI qui est en implantation. Aussi, nous sommes en transition Agile, donc, il y a du matériel développé de la vieille façon que nous devons maintenir et une lourde dette technique que nous tentons de corriger au passage. Ce qui fait qu’on manque de référence fiable pour valider les résultats de nos solutions.
Nous avons donc 2 problèmes principaux:
1- Les experts qui refusent d’apposer leur sceau sur les tickets parce qu’ils ne se sentent pas assez confiant dans leur propre révision
2- Des utilisateurs qui chargent des données n’importe comment et qui accusent ensuite les rapports d’être défectueux
Ça a donc pour effet que soit les tickets ne se ferment pas ou encore pire, qu’on tente de les rouvrir, car jugé défectueux. Cela nous plombe notre planif dans les 2 cas.
Nous pensons donc pouvoir mieux contrôler ces cas via une DoR pour nous permettre d’obtenir, avant de commencer, un engagement des parties prenantes qu’il sera possible de valider les résultats à la fin du développement et ensuite via la DoD qui va garantir qu’on ne changera pas les critères d’acceptation après la mise en production.
De cette façon, plutôt que de réagir à un fausse régression, nous pourrons prendre le temps d’identifier le besoin correctement, le planifier et le prioriser à la place qu’ils méritent dans le backlog.
En tant qu’expert, j’ai peur de modifier le code. En modifiant module A cela peut casser le module B.
Mon manager me met la pression pour livrer, donc je livre. À la fin de la journée de travail, j’ai du mal à me regarder dans le miroir.
Un peu plus tard, plusieurs utilisateurs remontent une série de régressions.
Je connais bien ce contexte de code legacy, adjoint à une pression continue de livrer.
Il y a une seule manière de répondre à cette problématique.
Faire face au problème et corriger petit à petit la structure du code.
Faire face au problème veut dire que le nombre d’évolutions va diminuer considérablement.
En passant de la course à la marche lente.
Et donc avancer à la vraie « vitesse ».
Je plonge dans mes archives de veille
Je trouve un épisode de ScrumLife
Toutes les réalisations d’aujourd’hui seront le legacy de demain.
Elles se transforment en pourriture, lorsque tu as peur d’y toucher.
Nettoyer cette pourriture, c’est plus compliqué que d’enlever de la poussière sur un meuble.
As-tu déjà travaillé sur une application dite « legacy » ?
A mon humble avis, le problème n’a rien à voir avec la qualité du code intrinsèquement. C’est surtout de la recherche utilisateur et de l’analyse systémique qui manquent dans ce que j’entends. Je vois nul part la mention de bugs ou de legacy ou autre.
