Quelle documentation au quotidien ? La doc agile en Scrum

[@ScrumLife]

L'atelier qu'il te faut pour animer tes affinages : l'Example Mapping ! 👍💪🤩 kzbin.info/www/bejne/nXqnYZWlermrgLM

[@clarisse__]

Tu mets souvent en avant l'example mapping, peut-être qu'il serait temps que je m'y penche plus sérieusement dessus :p Jamais expérimentée et curieuse de le mettre en pratique

[@Abdelkarim-ou3hw]

Super vidéo , elle est explicite va droit au but

[@ScrumLife]

Merci @Abdelkarim-ou3hw pour ton retour positif, ça fait vraiment plaisir ! 🎉 Content de savoir que la vidéo t'a été utile et que tu as apprécié notre manière d'aborder le sujet. Y a-t-il un aspect particulier de l'agilité ou de Scrum que tu aimerais qu'on développe plus en détail dans une prochaine vidéo ? Ton avis compte beaucoup pour nous ! À bientôt, Robin 🔄

[@BlocheValentin]

Hello @ScrumLife et merci pour ce contenu toujours quali 👌 Dans l'équipe que j'ai accompagné dernièrement, on a intégré la doc à notre DoD après avoir trop longtemps souffert des famosos "Pourquoi on a fait comme ça déjà ? 🤔" ou "Comment ça marche déjà, marre du retro-engineering H24 🤯". L'important aura été que le sujet doc ne soit pas subi, mais adhéré et construit par toute l'équipe, en décidant collégialement du niveau d'exhaustivité et de l'architecture des dossiers de celle-ci. On a par la suite revu en rétro si la documentation était facilement exploitable pour tous les rôles de l'équipe (dev, test, PO), en terme de navigation dans les dossiers et de contenu, qui se veut principalement fonctionnel. Je me dis que ça pourrait être intéressant/ludique de tester l'ergonomie de la doc, en demandant à un nouvel arrivant de retrouver la justification d'une décision X dans les docs après lui en avoir présenté l'architecture.

[@clarisse__]

Merci encore pour le live. S'il y avait qu'une chose à retenir, c'est ce que Constantin disait sur l'important de rapprocher l'équipe support à celle de réalisation. Je le garde en tête ^^

[@ScrumLife]

Un bon point pour commencer dans cette direction c'est de schématiser la communication actuelle. Par quelles étapes passe un sujet entre l'utilisateur et l'équipe. T'as une idée de ce que ça donnerait dans ton entreprise ? -- Constantin

[@nicolasponcet8626]

Bonjour, Je pense que la documentation sert aussi à 'vulgariser' les points complexes, à aider à la prise de décision avec les stake-holders. Ce qui a contribué à prendre la décision reste, il y a une trace écrite, et elle devient une référence pour orienter les actions d'améliorations futures. Il peut donc y avoir plusieurs niveaux de détails selon les compétences et le domaine d'activité des personnes qui sont les cibles de la doc. La doc n'a pas besoin d'être exhaustive, nous portons plutôt nos efforts pour créer de la doc utile, claire et diffusable. Elle peut aussi servir à partager les informations avec les autres équipes, par exemple en terme de 'Retour d'Experience', de capitalisation du savoir. Nous avons pour habitude de créer des 'How to' pour les sujets qui demandent de la synchronisation avec d'autres équipes (Quel ticket créer, quel contenu, à qui) ou complexes techniquement pour qu'au fil du temps, le nombre de difficultés rencontrées par les équipe diminue régulièrement. Nicolas

[@valeriecriton135]

Cette vidéo tombe à point nommé pour une SM débutante car on m'a demandé si je pouvais m'occuper des comptes-rendus des événements Scrum ...Du coup, je saurais quoi répondre. Vous m'avez également donné l'idée de faire une petite introduction durant notre premier sprint planning (qui démarre dans deux jours) pour le leur expliquer et amorcer peut-être un travail sur la gestion de l'information à venir. Et puis, le passage sur le délai discussions /passages à l'acte m'a particulièrement intéressée, ça va m'aider pour le choix de mes supports. Super merci ! 👌

[@ScrumLife]

Génial ! Merci pour ton commentaire détaillé. Tu nous tiendras au courant de ce que ça donne ? -- JP

[@valeriecriton135]

@@ScrumLife Oui avec plaisir !

[@amegandjiakou]

Très intéressante cette video👍

[@ScrumLife]

Merci ! Si tu ne devais retenir qu'une seule chose de cette vidéo, ce serait quoi ? -- JP

[@clarisse__]

Merci pour ce contenu riche en informations. Je vais prendre le temps de revoir la vidéo je pense. D'ailleurs, ça me donne envie d'être présente au live de jeudi! J'ai déjà quelques questions en tête ^^

[@ScrumLife]

Carrément ! Viens au Live !!! C'est quoi t'a le plus titillé dans ce premier visionnage ? -- JP

[@clarisse__]

Mince, je n'ai pas envoyé ma réponse... Ce qui m'avait titillé rapidement à la première visualisation est le fait d'entendre qu'on a loupé quelque chose si on fait de la doc lors des cérémonies. Je pense principalement à la rétro ^^ A toute dans le live!

[@cecilevivant6351]

Super video, merci! Au delà des CR j'ai une question sur la doc fonctionnelle. Quand tout au long du projet, les règles de gestion ont été écrites, puis corrigées, amendées, dans des US stockées aux tréfonds d'un board, comment fait-on pour les retrouver? Faut il faire un doc fonctionnel qui regroupe ces règles ? Et la maintenance ?

[@ScrumLife]

Ben... Oui. Il faut une doc du produit. Ce qui marche bien c'est d'utiliser des approches et outils de type spécification exécutable (Cucumber, FitNesse...) qui lient la doc fonctionnelle avec des tests automatiques. - On oublie de mettre à jour la doc ? Ca se voit dans les tests qui échouent - "Est-ce que la doc est à jour ?" Oui c'est garanti tant que les tests sont exécutés Sinon, il faudra mettre la maintenance du référentiel dans la DoD !!! -- JP