Faux. Le manifeste parle d'avoir une documentation exhaustive (comprehensive). Ce qu'on t'a répété un bon nombre de fois, c'est qu'une bonne documentation au sens du manifeste, c'est juste ce qu'il faut de documentation.
D'autre part, effectivement il y a une hiérarchie naturelle entre le fait d'avoir une documentation exhaustive et celui d'avoir un logiciel qui marche, parce que concrètement, livrer seulement la documentation n'aura aucune valeur pour l'utilisateur final. De plus, une documentation exhaustive prend du temps à écrire et elle est fragile, c'est à dire facilement désynchronisée avec le code. En revanche, livrer d'abord un binaire qui marche et quelque temps après, éventuellement de la doc, ça a de la valeur.
On doit se focaliser en premier lieu sur la fourniture d'une application qui marche et qui répond aux besoins, car c'est notre métier, notre raison d'exister, ce qu'on attend d'abord de nous, ce pour quoi on est payés, ce sur quoi on juge la réussite d'un projet même s'il est arrêté en pleine course. On doit se focaliser en second lieu sur l'écriture de la bonne quantité de documentation.
Dans l'énoncé du problème, tu fais exprès d'assimiler quantité de documentation et qualité de la conception interne. Ton armoire A est comme par hasard mal conçue ET pauvre en documentation. L'armoire B est bien entendu bien conçue ET bien documentée...- une armoire A qui contient plein de fils dans tous les sens, qui se croisent, des soudures sauvages. La peinture de l’armoire est nickel. Par contre on voit l’énorme sac de nœuds (spaghettis) quand on l’ouvre. Le point positif, c’est qu’elle marche. Je n’ai rien de plus que cette armoire, pas de documentation technique. Je sais par ailleurs qu'il est impossible de tester tous les cas de figures.
- Une armoire B qui visiblement ne fonctionne pas dans certains cas. Par contre, elle est structurée et cette structure est parfaitement documentée : les fils sont numérotés, assemblés … On comprend très vite comment fonctionne cette armoire et le contenu est complet.
Le manifeste agile fait l'inverse de ce parallèle. Il constate qu'une application peut être documentée sous toutes ses coutures mais pour autant ne pas marcher ou être mal designée, justement parce que tout l'effort a été mis sur la documentation au lieu de la priorité numéro 1 qui est un logiciel de qualité qui fonctionne.
Le mouvement agile ne s'arrête pas à ce constat. Il propose des solutions pour lier intimement à nouveau la description lisible par un humain d'un système, et son fonctionnement concret.
Ces solutions, c'est le code auto-documenté. Ce sont les spécifications exécutables.
Donc ma réponse, c'est la fonctionnalité de l'armoire A, le design de l'armoire B et au lieu de petites étiquettes sur les câbles, un moniteur de contrôle synchronisé avec le système qui permet d'avoir des informations fiables en temps réel sur un câble et sur l'état général du système
Partager