Re: Oui, mais non

Je vais profiter de ton commentaire pour rebondir sur celui-ci quelques autres ainsi que sur une remarque de l'auteur :)

donner des clef sur comment se débrouiller sans documentation

Même si tu donnes quelques éléments pour étayer, on peut pas laisser passer çà :)

L'agilité n'a jamais prétendu qu'il fallait se "passer" de la documentation, bien au contraire.
Le principe, comme pour le reste, est de faire ce qui est suffisant au bon moment çar le changement peut, enfin non, va, arriver. Tout comme on n'se fait pas plaisir avec une archi géniale qui servira jamais (overdesign) et qu'on fait "juste ce qu'il faut".

En effet, une carte sur un Trello n'a jamais constitué une spécification pour moi. A la limite, si le manager/client avait su étoffer ces cartes

Voilà, ca tombe bien, pour l'agilité non plus. Si tu as des contraintes réglementaires, on ne va pas te dissuader d'en faire.
Une US c'est juste morceau de fonctionnalité dont on peut mesurer la valeur ajoutée et qu'on peut livrer à temps pour plaire à celui qui paye, le métier. Point barre
Qu'on en fasse une unité de tâche n'empêche pas qu'on puisse la découper en sous-tâches ou même qu'on la retravaille.
https://www.youtube.com/watch?v=rP9AlpFwvSM

A mon avis c'est comme ça pour plus de la moitié des boites qui disent être agiles : pour elles lorsqu'elles ontpassé le délai de mise à disposition d'une nouvelle appli de 6 mois à 4 mis, elles peuvent se prétendre agile.

Petit "test":
- On est super agile, on a des sprints de 2 semaines
- Vous avez des tests ?
- Bin non tu rigoles avec le pressing de l'AMO , on n'a pas le temps
- J'ai une bonne nouvelle comme vous êtes agile, on va se lancer dans un petit refactoring des familles, parce que là ça pue le syndrome du copier-coller
- OMG!

Nous l’avons peut-être déjà tous constaté, l’utilisateur final ne sait pas vraiment ce qu’il veut, et a beaucoup de difficulté à exprimer clairement par écrit ses attentes.
Un intermédiaire (MOA, MOE, BA, PO, Archi) est nécessaire pour lui permettre de prendre du recul
et pour traduire une demande fonctionnelle en exigence technique.
Mais l’intermédiaire rajoute une couche intermédiaire !
C’est humain, l’intermédiaire aura tendance à se rendre indispensable.

Allez, on reprend les bases: le manoifesto
Working software (削除) without (削除ここまで)over comprehensive documentation
Customer collaboration over contract negotiation

Voilà, on privilégie ce qui marche plutôt que la paperasse inutile: un doc de spec de 500 pages que l'AMO n'ose pas tamponner de peur de s'être planté ou à balancer parce que le business a déjà changé. Un modèle UML aux petits oignons que le métier pige pas et qui sera complètement obsolète au moment de la livraison.

Si documentation il y a, il faut qu'elle reflète l'état du projet à l'instant t, bref qu'elle soit "vivante" ET qu'elle serve. Quoi de mieux qu'un exemple élaboré avec toutes les parties prenantes pour être sûr qu'on a tous pigé le même truc sans "intermédiaire". S'autoriser à challenger le PO sur cette base pour être sûr qu'il sait ce qu'il veut ou lui montrer que ça tient pas debout.

Allez un petit rituel pour bien s'accorder sur les règles métier avant de valider que la US est "Ready" et s'assurer qu'on va pas (moins) se planter sur le planning (la "cistomer collaboration"):
https://www.youtube.com/watch?v=gID0boETxJQ
https://cucumber.io/blog/example-mapping-introduction/

Le PO/AMO est pas jouasse ? Et bin on se protège:
https://www.youtube.com/watch?v=C9XoZQdnKbA&list=PLxTb_ZC4kmrSBKSyz3N4rtYjdE7EaI0Uu

Et comment qu'on fait pour s'assurer que ces règles sont bien respectées ?
Et bin on les teste (non la vocation du BDD Bevaviour Driven Design n'est pas le test mais bien piger ce que veut le client), on les rend "executables". La voilà la living documentation:
https://www.youtube.com/watch?v=p1Tl8kfkjGM

Et ca veut pas dire qu'il faut "tout" tester en Cucumber et écrire des tests d'IHM en Ghekin, hein

Allez, on pousse encore un peu le truc avec l'archi. Un peu de sketch modeling pour le début du sprint (ton exemple est quand même très orienté EDA ca correspond pas à tout les projets)

Et puis pour le newbie, quoi de mieux que de lire les TUs pour se mettre dans le code ? En voilà une autre de belle "living documentation" à base d'exemples pour peu qu'on soigne un peu le présentation (Clean code, domain driven). Oui on soigne ses tests et on les refactore avec le même soin que le code.
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Le "Done Done", c'est pas pour la déco, ...

Voilà le truc, c'est de faire du bottom-up et plus du top-down (on oublie le MDA)

Ca tombe bien, un petit français nous a fait un super talk dessus:
https://www.youtube.com/watch?v=Tw-wcps7WqU&list=PLTbQvx84FrAS5clN9i8_LFUQxcMY7qXAO&index=118

et a même pondu un bouquin au financement libre:
https://leanpub.com/livingdocumentation
A consommer sans modération, avec par exemple comment rétrogénerer de la doc d'archi avec un bon framework des famille et quelques annotations, DDD, Documenation by convention, ...
Une mine d'or.

Alors c'est sûr la 1ere fois si on fait l'impasse sur tout ça, l'AMO, le PO, il s'habitue: "Vous avez pulsé , les gars!" et on ne pourra pas revenir dessus. Les bugs tombent, la dette technique s'accumule on fait l'impasse sur la doc en crachant sur la méthode et l'agilité Ultime et Universelle se met en place aka:
http://www.la-rache.com/