Discussion :

[Luckyluke34]

Pourquoi établir une priorité entre avec un logiciel qui marche et avoir la documentation de ce logiciel en priorisant le logiciel qui marche ? C’est ce que dit le manifeste.

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.

- 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.

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...

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

[CaféFort]

Très juste, mais tu ne vas pas au bout de ton raisonnement : les choix humains, ils sont faits dans un contexte donné, et le contexte peut changer. (ça va de "on fait fausse route" à "la loi a changé")

Merci d’avoir commencé à restreindre la source des changements. De plus les changements ne représentent qu’une infime partie du logiciel. Faut-il les considérer comme une règle ? Comme s'ils étaient ingérables comme une tempête ? Je ne crois pas.
Par ailleurs, si tout change tout le temps, alors pourquoi automatiser ? Mieux vaut utiliser Excel et Word ! La volonté d’automatiser serait alors aussi une erreur humaine … de management.

L’automatisation là où elle n’a pas lieu d’être est un véritable enfer !

Tout ne change pas si souvent que cela !! Et ces changements ne viennent pas des éléments extérieurs (exemple de météo, avaries comme j’ai pu lire) mais d’un choix humain. Appelons un chat, un chat c’est mieux.

tu as une couverture complète de tests, que tu n'as plus qu'à faire évoluer en même temps que les composants.

Intéressant les tests de non régression avec couverture complète !!! (merci de l'avoir évoqué)

- J’ai une application pour laquelle je dois développer des tests de non régression.
- Je créée un jeu d’essais pour avoir une couverture complète (comme tu le mentionnes)
- Quelqu’un modifie l’application
- Je lance ma batterie de tests de non régression
- Les résultats sont OK !

Est-ce que j’ai la garantie que mon application est toujours correcte ? NON !

Les tests de non-régression ont une valeur, certes, mais ne procurent aucune garantie. Pourtant c’est ce qu’ils sont sensées apporter, on parle bien de "tests".
Si on me le demande (si vous ne trouvez pas par vous-même) je donnerai un exemple extrêmement simple qui porte sur 3 lignes ... alors dans une vraie application, des exemples, il n’y a que cela. Les tests apportent des tests, c'est bien, mais ils n'apportent pas une garantie. Il ne faut donc pas surestimer leur valeur, en tout cas ils apportent une fausse sécurité (que certains voudraient nous faire croire).

Cela dit, ils sont très utiles ... mais en connaissance de causes.

[Luckyluke34]

Les tests de non-régression ont une valeur, certes, mais ne procurent aucune garantie. Pourtant c’est ce qu’ils sont sensées apporter, on parle bien de "tests".
Si on me le demande (si vous ne trouvez pas par vous-même) je donnerai un exemple extrêmement simple qui porte sur 3 lignes ... alors dans une vraie application, des exemples, il n’y a que cela. Les tests apportent des tests, c'est bien, mais ils n'apportent pas une garantie. Il ne faut donc pas surestimer leur valeur, en tout cas ils apportent une fausse sécurité (que certains voudraient nous faire croire).

Pourquoi tu ne donnes pas tout de suite ton exemple - au lieu de tourner autour du pot et d'insinuer que si on n'est pas capables d'imaginer tout seuls ce que tu as en tête, c'est qu'on n'est pas doués ?

Les tests de non-régression ont une valeur, certes, mais ne procurent aucune garantie

Que veux-tu dire par "aucune garantie" ? Garantie de quoi ? Même pas la garantie que ce qui est testé avec le jeu de données utilisé dans le test fonctionne ?

Cela dit, ils sont très utiles ...

Très utiles, mais pourtant ils ne procurent aucune garantie. Pourquoi tester dans ce cas-là ?

[Luckyluke34]

Tout ne change pas si souvent que cela !! Et ces changements ne viennent pas des éléments extérieurs (exemple de météo, avaries comme j’ai pu lire) mais d’un choix humain.

De choix humains contre lesquels on ne peut bien souvent rien. Et c'est bien normal. Tu vas t'opposer à un changement dans la loi ? A un client qui te dit que la fonctionnalité X est une grosse erreur stratégique métier qui lui fait perdre des milliers d'euros par jour ou rend les utilisateurs mécontents ? Ou que la fonctionnalité Y proposée par un concurrent doit absolument être ajoutée sous peine d'une émigration massive des utilisateurs vers le concurrent ? A un client qui te dit que la fonctionnalité Z non encore développée n'est plus pertinente et qu'il faut la remplacer par la fonctionnalité Z' sous peine de gaspiller des milliers d'euros de budget ?

Les méthodes agiles, c'est prendre en compte ces changements au lieu de les nier. Ne pas les considérer comme ingérables tels des catastrophes naturelles comme tu le dis, mais justement se donner tous les moyens de les gérer.

[ZenZiTone]

Je pense que beaucoup se méprennent sur ce qu'est le manifeste Agile. Il ne décrit pas "comment faire", mais quelle philosophie on doit avoir lorsque l'on s'oriente vers la gestion de projet typée l'Agile. C'est d'autant plus vrais que le manifeste est volontairement composé de phrase simple mais dont le sens est très large.

"Des logiciels opérationnels plus qu’une documentation exhaustive" ne décrit pas une façon de faire, mais une façon de penser le projet. Et de ce même manifeste, plusieurs méthodes se sont mises en avant, dont Scrum, Xp et autres.

[el_slapper]

[QUOTE=CaféFort;8604272]Merci d’avoir commencé à restreindre la source des changements. De plus les changements ne représentent qu’une infime partie du logiciel. Faut-il les considérer comme une règle ? Comme s'ils étaient ingérables comme une tempête ? Je ne crois pas.
Par ailleurs, si tout change tout le temps, alors pourquoi automatiser ? Mieux vaut utiliser Excel et Word ! La volonté d’automatiser serait alors aussi une erreur humaine … de management.

L’automatisation là où elle n’a pas lieu d’être est un véritable enfer !

Si tu attends d'avoir un univers stable, tu n'automatises jamais rien. Je parle du monde réel : il change sans cesse, mais a besoin d'automatisation quand même. Faire une fiche de paye, de nos jours, c'est devenu tellement compliqué que sans automates, personne(à part quelques spécialistes) n'y arriverait. Pourtant, c'est un domaine ou le réglementaire change fréquemment. Pareil dans mon domaine actuelle : la facturation hospitalière. L'automatisation est effectivement un enfer, au vu de l'instabilité réglementaire chronique..... mais son absence serait pire encore, et les frais administratifs des hôpitaux exploseraient.

Tout ne change pas si souvent que cela !! Et ces changements ne viennent pas des éléments extérieurs (exemple de météo, avaries comme j’ai pu lire) mais d’un choix humain. Appelons un chat, un chat c’est mieux.

D'autres ont répondu mieux que moi, mais les humains sont des créatures faillibles. Autant prendre en compte cette faiblesse.

Intéressant les tests de non régression avec couverture complète !!! (merci de l'avoir évoqué)

- J’ai une application pour laquelle je dois développer des tests de non régression.
- Je créée un jeu d’essais pour avoir une couverture complète (comme tu le mentionnes)
- Quelqu’un modifie l’application
- Je lance ma batterie de tests de non régression
- Les résultats sont OK !

Est-ce que j’ai la garantie que mon application est toujours correcte ? NON !

Même avant la modification, tu n'as pas la certitude que tout est bon. Avec aucune méthode, d'ailleurs. Nous êtres humains, sommes faillibles, et la conception parfaite n'existe pas. Il y a TOUJOURS des bugs.

Mais tu as, avec ce genre de méthodes, un taux de fiabilité nettement meilleur. Tout simplement parceque les choses standard sont déjà bien couvertes. Alors qu'une doc, ben, comment dire, si ton code ne correspond plus, elle ne va rien te dire.....

[CaféFort]

L'automatisation est effectivement un enfer, au vu de l'instabilité réglementaire chronique..... mais son absence serait pire encore, et les frais administratifs des hôpitaux exploseraient.

Effectivement et oui, parfois on n’a pas le choix. Il faut informatiser.

sans automates, personne(à part quelques spécialistes) n'y arriverait

Oui, Yes !!! J’espère qu’on parle bien de la même chose : les automates d’états finis (et son pendant plus rare l’automate à pile d’états).
Personnellement je trouve que l’automate logiciel est une (LA) super technique quand les règles sont compliquées et se « chevauchent » les unes et les autres. Je les utilise souvent et avec eux un problème hyper compliqué devient hyper-simple. Mais personnellement, je vois mal faire des automates non documentés : un petit schéma et tout est limpide. Par contre sans schéma, c’est l’enfer.

Même avant la modification, tu n'as pas la certitude que tout est bon. Avec aucune méthode, d'ailleurs. Nous êtres humains, sommes faillibles, et la conception parfaite n'existe pas. Il y a TOUJOURS des bugs.

Mais tu as, avec ce genre de méthodes, un taux de fiabilité nettement meilleur. Tout simplement parceque les choses standard sont déjà bien couvertes. Alors qu'une doc, ben, comment dire, si ton code ne correspond plus, elle ne va rien te dire.....

Je suis totalement d’accord. Car contrairement à ce qu’on pourrait croire les tests de non-régression avec une couverture de 100% ne garantissent rien. C’est une aide très efficace quand même. Entièrement d’accord avec toi.

Un doc qui n’est pas à jour … on est d’accord aussi, c’est comme ne rien avoir.

Mais pour moi, ce qui est pire encore car je l’ai vécu maintes fois dans des interventions de style « pompier » (sauver la situation), c’est un prog qui tourne (ou semble tourner), qu’on veuille le faire évoluer, il n’y a aucune documentation (même pas les composants), beaucoup de code, beaucoup de variables globales ou d’objets globaux et des délais courts. Même pour un changement mineur, c’est x jours de travail pour commencer par refaire la doc et surtout ne rien pouvoir produire de visible pendant tout ce temps, c'est-à-dire l’exact contraire de l’agilité (qui préconise d’avoir souvent des livrables). Je trouve que parfois l’agilité reporte à demain des choses qui sont fondamentales et laisse ainsi une situation grave, qui n’est pas clairement visible … pour les suivants.
Personnellement, je ne leur dit pas merci . D’où ce principe que je ne trouve pas sérieux pour des investissements importants et des logiciels pérennes.

[Luckyluke34]

Même pour un changement mineur, c’est x jours de travail pour commencer par refaire la doc et surtout ne rien pouvoir produire de visible pendant tout ce temps, c'est-à-dire l’exact contraire de l’agilité

Encore une fois, idées préconçues et conclusions inexactes car tu n'a pas pris la peine de t'informer sur ce que tu critiques.

• Rien dans les méthodes agiles ne dit qu'un livrable ne peut pas être une documentation. Pour la 340 000ème fois, on préfère se donner comme but une appli qui marche plutôt qu'une documentation exhaustive. Mais dans le cas précis d'un système inconnu dont on hérite, on a déjà l'application !
  
  Et il est bien évident qu'on ne va pas livrer de nouvelles fonctionnalités dès les premières semaines sans avoir analysé l'existant et, si c'est nécessaire, restitué une certaine quantité de cette connaissance sous forme écrite. Néanmoins c'est une bonne idée de livrer le maximum de documentation technique sous forme de tests automatisés qui prouvent que telle ou telle fonctionnalité marche ou ne marche pas dans l'application. Ces tests serviront de filet de sécurité de non-régression lorsqu'on va vraiment commencer à modifier le code legacy pour ajouter des fonctionnalités ou corriger des bugs.

• Les méthodes agiles fonctionnent par itérations de une, deux semaines voire un mois. Pendant une itération, aucun livrable n'est exigible, on ne peut pas ajouter du travail en plus à l'équipe de développement et on fait en sorte qu'elle travaille de manière focalisée en subissant le moins d'influences extérieures. Ce n'est en aucun cas le règne de l'instantanéité et du changement permanent. Ca me parait réaliste de dire que dans ce cadre, en un mois une équipe peut produire au moins une partie de la documentation d'un système existant, non ?

Je trouve que parfois l’agilité reporte à demain des choses qui sont fondamentales et laisse ainsi une situation grave, qui n’est pas clairement visible … pour les suivants. Personnellement, je ne leur dit pas merci . D’où ce principe que je ne trouve pas sérieux pour des investissements importants et des logiciels pérennes.

Tu fais un lien qui n'a pas lieu d'être entre l'emploi d'une méthodologie et le manque de professionnalisme et de rigueur des développeurs.

Si quelqu'un n'est pas capable de comprendre qu'il faut léguer à ses successeurs une base de code la plus intelligible possible (que ça soit par n'importe quel moyen : doc, tests basés sur des exemples, schémas, vidéos, etc.), aucune méthodologie au monde ne pourra le sauver.

Je préfère un développeur responsabilisé, qui sait avec discernement produire la bonne quantité de doc, qu'un développeur qui suit des règles rigides sans savoir pourquoi et pisse des pages entières de documentation exhaustive paraphrasant le code et qui vont s'avérer fausses à très court terme.

[souviron34]

D’où ce principe que je ne trouve pas sérieux pour des investissements importants et des logiciels pérennes.

Les cas que j'ai vu d'échecs flagrants de la méthode "doc first" et où il a fallu que j'intervienne en mode pompier c'était :

• 1 :
  
  • 15 ans d'investissements des contribuables
  • 82 millions de dollars
  • durée de vie prévue du logiciel 20 ans au moins
  
  
  
  
• 2 :
  
  • 12 ans d'investissements des contribuables
  • 120 millions d'euros
  • durée de vie prévue du logiciel 20 ans au moins
  
  
  
  
• 3 :
  
  • 12 ans d'investissement des contribuables
  • 100 millions de dollars
  • durée de vie prévue du logiciel 20 ans au moins
  
  
  
  
• et, le meilleur pour la fin (mais je ne suis pas (encore) intervenu dessus)... La fameuse "carte vitale ameliorée" de Douste-Blazy :
  
  
  • déjà 12 ans d'investissement des contribuables (au bas mot, parce qu'en fait ça a commencé en 1984!!!)
  • environ 4 milliards d'euros (au bas mot, juste depuis 2004, car si on compte depuis 1984 c'est plus proche des 12 à 20 milliards)
  • durée de vie prévue du logiciel : ??
    
    Le CP a demissioné au bout de 10 ans faute d'avancées, immense consortium de boites, etc etc... et les régions se débrouillent seules, sachant que ça ne marchera jamais, et préfèrent développer leurs petits systèmes à leur niveau, en intégrant petit à petit les systèmes dispos dans leurs régions suivant les professions...

De francs succès

[souviron34]

D’où ce principe que je ne trouve pas sérieux pour des investissements importants et des logiciels pérennes.

Tiens, un nouveau cas :

Is the $400 billion F-35's 'brain' broken? (CNN)

Almost 2,500 of the world's most advanced warplanes, with a total price tag of $400 billion, and they may not have a "brain" in the bunch?
That's the fear of federal watchdogs who say problems with the F-35 Joint Strike Fighter's complex logistics software system could lead to a grounding of the entire fleet, not to mention future cost increases and schedule delays

The Marine Corps declared the first squadron of its F-35 variant ready for combat in July 2015, with the intention of upgrading and resolving the software issues before its first planned deployment in 2017

C'est vrai que 400 milliards de dollars, et un nouvel avion de combat, c'est bien un investissement important et un logiciel pérenne, non ??

Pourtant, si il y a bien un domaine où le cycle en V est appliqué, c'est bien le militaire américain et la norme du DoD...

[CaféFort]

Le manifeste dit : "valoriser des logiciels opérationnels plus qu’une documentation exhaustive."

J’aurais peut-être dû commencer par cette question.

Il y a une expression dans le manifeste, qui est « documentation exhaustive ».

Il y a peut-être des endroits où ça existe, mais personnellement, je n’ai jamais vu de documentation exhaustive, à moins que je me trompe au niveau du sens de cette expression.

Aussi, j’aimerais qu’on me donne la définition précise de « documentation exhaustive ».

Bien sûr, si on ne peut pas donner une définition correcte, alors fatalement cette ligne n'a pas de sens (on fait de la logique quand même).

Et si on trouve que partout, la documentation n’est pas exhaustive, … la deuxième partie de la ligne du manifeste est alors toujours fausse (ou jamais vraie au choix), … etc. Il ne resterait alors plus que "valoriser des logiciels opérationnels". C’est de la logique.

Merci d'être rigoureux dans la réponse .

[souviron34]

Aussi, j’aimerais qu’on me donne la définition précise de « documentation exhaustive ».

Je n'ai plus mes docs sous la main (dans une chemise dans une malle à 6000 km d'ici ), mais les normes AFNOR sont assez claires (comme celles du Dod), alors juste de mémoire :

• cahier des charges (appel d'offres ou cahier des charges réel ou cahier des charges créé par CP/marketing)
• analyse globale (réponse de l'entreprise au cahier des charges ou appel d'offres)
• spécification système (en particulier limites matériels/logiciel)
• analyse système (en particulier API matériels/logiciel) + dictionnaire système
• spécification logicielle
• analyse logicielle + dictionnaire logiciel
• conception préliminaire (de l'ensemble du logiciel et de chaque fonction)
• conception détaillée (de chaque fonction de l'ensemble du logiciel)
• pseudo-code (de chaque fonction de l'ensemble du logiciel)
• tests unitaires
• tests logiciels
• tests système
• recette unitaire
• recette logicielle
• recette système

Avec définitions globales et fixes de tous les termes, API, conceptions, et algorithmes sous forme de pseudo-code, en dur, et une répartition des rôles de qui doit écrire quoi et du contenu exact de chaque document....

L'ensemble de cette documentation est à faire avant l'écriture de la moindre ligne de code (sauf les recettes bien entendu, qui doivent cependant être préparées à ce stade), et on doit pouvoir la fournir comme justification (par exemple pour l'approbation d'un logiciel par la Food and Drugs Administration) .

Il est de plus strictement impossible de revenir en arrière sur quoi que ce soit tant qu'on n'a pas fini le cycle complet, donc tant que la recette système n'a pas été signée par le client.






* et il y a des variantes avec plus : architecture organique et architecture fonctionnelle, tables de bd, relations et détails des données dans la BD pour chaque spécification fonctionnelle, estimation de la charge de travail en points de fonctions, etc etc....

** et en général dans les gros projets les spécifications fonctionelles, y compris les BD et les liens entre les données dans la BD, sont soumises et signées par les "utilisateurs" (qui n'y comprennent rien puisque c'est en langage par et pour des informaticiens), ce qui permet à l'entreprise de faire re-payer le client lorsque celui-ci découvre que il n'a pas ce qu'il souhaitait... à la fin

*** mais si tu veux, il suffit d'acheter la norme AFNOR pour avoir le détail exact, je n'aurais pas accès à mes docs avant 6 mois....

[CaféFort]

Définition de "documentation exhaustive" (manifeste agile)

Je n'ai plus mes docs sous la main (dans une chemise dans une malle à 6000 km d'ici ), mais les normes AFNOR sont assez claires (comme celles du Dod)

Merci pour cet exemple de contenu de documentation vu par l’AFNOR. Ce que tu cites est la vision de l’AFNOR concernant une documentation exhaustive.

Mais ce n’est pas ce qui est mentionné dans le manifeste. Le manifeste mentionne une « documentation exhaustive », et non une « documentation exhaustive selon l’AFNOR ».

Un verre plein : tout le monde sait ce que c’est. Il existe une définition. C’est universel. Tout le monde se comprend.

Une documentation exhaustive, personnellement je ne connais pas et s’il n’existe pas de définition universelle, alors cette ligne n’a aucun sens … ou au mieux, elle se résume à simplement « valoriser un logiciel opérationnel » et c’est tout (puisque la documentation ne serait jamais exhaustive, faute de définition de l'exhaustivité d'une documentation). Elle serait toujours partielle.

Je souhaite donc qu’un spécialiste agile me donne la définition (universelle bien sûr) pour que tout le monde comprenne. La demande est légitime, non ?
Sinon, on va inévitablement penser que cette ligne du manifeste n’est pas sérieuse (titre de la discussion).

Après on jettera un oeil sur les autres lignes du manifeste .

[Luckyluke34]

L'exhaustivité est un état qui n'est pas atteignable comme tu l'as justement souligné. Néanmoins, c'est un objectif qu'on peut se donner (et qu'en l'occurrence, le manifeste agile préconise de ne pas se donner).

Tendre vers une documentation exhaustive, c'est chercher à produire la description écrite la plus complète et détaillée possible tant des attendus métier que des aspects techniques d'une application. On entend "complet" en surface fonctionnelle (cela doit couvrir tous les modules du logiciel) et en profondeur technique (décrire toutes les couches en oeuvre).

La liste donnée par souviron34 est parfaitement représentative de ce qu'on entend par documentation exhaustive. Bien que l'AFNOR soit un organisme français, c'est clairement le type de documentation préconisée par les process dits "lourds" qui sont en partie remis en cause par le manifeste agile. Pour un exemple plus américain, on trouve page 6 du papier de Winston Royce de 1970 à l'origine de la méthode Waterfall une liste des documents attendus aux différentes étapes d'un process en cascade.

Il n'y a bien évidemment pas d'autorité suprême qui ait défini ce qu'est une "documentation exhaustive" en tous temps et tous lieux, tout simplement parce que ça dépend de la méthodologie employée et donc de facto il y en a une par approche méthodologique (du moins celles qui visent l'exhaustivité). Toutefois il y a un gros dénominateur commun entre ces méthodes traditionnelles ("lourdes"), et ces deux exemples sont assez évocateurs de ce que le manifeste agile qualifie d'exhaustif.

[CaféFort]

La liste donnée par souviron34 est parfaitement représentative de ce qu'on entend par documentation exhaustive.

Non, de ce que l’afnor entend comme documentation exhaustive.

Il n'y a bien évidemment pas d'autorité suprême qui ait défini ce qu'est une "documentation exhaustive" en tous temps et tous lieux

Une définition universelle n’est établie par aucune autorité. C’est pour cela justement qu’elle est universelle et qu’elle a dans ce cas autant de valeur. C'est bizarre d'avoir eu cette idée de parler d'autorité suprême !! (on est toujours dans l'obéissance du maître à penser ?)

ces deux exemples sont assez évocateurs de ce que le manifeste agile qualifie d'exhaustif.

Ha bon, j’en déduis donc par tes écrits que l’agilité serait le maître à penser ? Celui qui a le pouvoir de qualifier les autres de bons et mauvais.

(...) autorité suprême, (...) ce que le manifeste qualifie d'agile (...)

Merci pour cette parfaite démonstration de dogmatisme.

Sinon, une définition de documentation exhaustive admise par tous et non uniquement par les adeptes (de l’agilité), c’est quoi ? Ça existe ?

[souviron34]

Une définition universelle n’est établie par aucune autorité. C’est pour cela justement qu’elle est universelle et qu’elle a dans ce cas autant de valeur.
....
Merci pour cette parfaite démonstration de dogmatisme.

Tu en est un parfait exemple, et j'aurais tendance à commencer à perdre ma patience devant non seulement ta mauvaise volonté et foi, mais je dirais même plus : une provocation associée à un dogmatisme un mépris et une volonté de nuire..

Amuse-toi bien, tu n'auras plus aucune réponse de ma part..


(et je suis encore sympa.. Je te sens comme un troll qui simplement veut f'utre le bordel, ou sinon.. mais vaut mieux que j'arrête là, je vais commencer à être méchant)

[CaféFort]

Je ne demande qu'une définition énoncée de manière universelle et non par un "groupe", quel que soit ce groupe. C'est tout . C'est quand même pas grand chose.

Ensuite on regardera les autres lignes du manifeste.

Vivement la suite ... avec bonne humeur !!

[el_slapper]

Je ne demande qu'une définition énoncée de manière universelle et non par un "groupe", quel que soit ce groupe. C'est tout . C'est quand même pas grand chose.

Ensuite on regardera les autres lignes du manifeste.

Vivement la suite ... avec bonne humeur !!

C'est justement là que tu fais fausse route. Tu veux une méthode qui marche à tous les coups. Un principe universel qu'il suffirait de suivre aveuglément, et hop! tous les projets seraient des succès.

Ca se saurait si ça existait. Toutes les méthodologies connues ont connu au moins un exemple d'échec - et au moins un exemple de succès. Agile, Waterfall, trucs plus ou moins basés sur l'UML..... Parfois même, les raisons de l'échec sont totalement extérieures au projet. En 2002, je suis entré sur un forfait pour refaire le référentiel cartes bleues d'une grandes banques Française. Quinze jours plus tard, le grand patron décide de faire un cadeau aux actionnaires, et sabre le financement du projet, qui part à la poubelle. C'est bien un échec, pour autant, ni la méthodologie, ni les personnels impliqués ne sont en cause. Ce sont des choses qui arrivent. Plus généralement, toute technique qui a marché ici peut foirer là.

Un projet, c'est quelque chose de fluide, qui aura toujours un part de non contrôlé. Chercher une définition universelle, absolue, scientifique au sens de Popper, c'est perdre son temps. Les définitions sont écrites par des humains, en fonction de leurs expériences, et ces humains ne sont pas parfaits. Les définitions données par mes collègues ne sont ni parfaites ni universelles..... parceque ces définitions parfaites et universelles n'existent pas.

Ca n'empêche pas de comprendre le principe. Le principe d'une documentation exhaustive, c'est que tout est prédéfini à la virgule près. Le principe d'une documentation agile, c'est qu'on en donne assez au programmeur pour qu'il avance, mais surtout pas plus.

Après, je ne suis pas un intégriste de l'agile. Quand on a des projets réglementaires, ou de migration technique, une spécification intense me parait nécessaire.



Donc, au final, si tu cherches à attaquer le manifeste agile sur le plan de la logique formelle, ben, comment dire, tu te trompes de combat. Le manifeste agile n'est pas de la logique formelle, c'est un simple guide de base, qui donne des idées, à suivre ou pas. Tu arriveras forcément à tes fins, mais ça ne signifiera rien d'autre que celà : la logique formelle n'est pas la seule manière d'aborder les problèmes.

[CaféFort]

Merci el_slapper pour ta réponse.

« C'est justement là que tu fais fausse route. Tu veux une méthode qui marche à tous les coups. Un principe universel qu'il suffirait de suivre aveuglément, et hop! tous les projets seraient des succès. »

Jamais de la vie !! Bien au contraire !!
Je m’adapte complètement à la situation que je trouve. C’est la problématique du projet qui implique la démarche qui sera employée.
Je demande juste la définition de « documentation exhaustive » universelle puisque énoncée de manière universelle.

« Agile, Waterfall, trucs plus ou moins basés sur l'UML »

Attention !! UML n’est qu’un langage : Unified Modeling Langage. La confusion entre UML et méthode est hyper répandue.
Comme pour tout langage, avec UML, on peut faire tout et n’importe quoi ! Des spaghettis, du vrac, du clean aussi. C’est un langage, c’est tout, rien de plus.

« Chercher une définition universelle, absolue, scientifique au sens de Popper, c'est perdre son temps. »

Je cherche la définition de « documentation exhaustive » puisque c’est l’expression du manifeste.

« parceque ces définitions parfaites et universelles n'existent pas. »

Non, je ne suis pas du tout d'accord.
La définition est un des piliers de la communication. C’est ce qui permet aux gens de se comprendre.
Le manifeste commencerait son œuvre par employer une expression indéfinissable pour un sujet dont la finalité est … justement la communication (spécifications), hum … !!

« Le manifeste agile n'est pas de la logique formelle, c'est un simple guide de base, qui donne des idées, à suivre ou pas. »

Je suis d’accord sur ces nuances (mais guide de base : bof bof).
Malheureusement, il y a beaucoup de personnes (une majorité à mon avis chez les "agiles" !!) qui prennent tout à la lettre et l’appliquent avec force (il suffit de lire cette discussion, c’est édifiant) sans jamais adapter les principes au contexte du projet. C’est l’un des vrais dangers de ce manifeste. Son imprécision permet à quiconque de dire « j’ai raison parce que c’est écrit » ensuite cette personne cite sa propre interprétation et toutes les réussites de projets (que personne n’a vérifié), comme s’il s’agissait de preuves. Je ne connais que les agiles qui revendiquent autant de réussites pour nous convaincre (moi mes réussites, je ne les étale pas), à force de répétition, beaucoup suivront … cela durera un temps. En faisant cela, ils ont une démarche de parfait mouton, en tout cas sans réflexion personnelle.

Je dis simplement attention aux méthodes, aux croyances infondées, aux exemples à suivre (les cas sont toujours différents les uns des autres) … on arrive très vite à des formes d’intégrisme avec des personnes qui sont moutonniers et ne s’en rendent même pas compte (elles clament l’inverse bien sûr). C’est flagrant dans cette discussion.

Petit exercice :
Prenons la négation de chacune des lignes du manifeste et réfléchissons.

Si le manifeste possède une vraie valeur, un vrai exemple à suivre, on devrait arriver à quelque chose de totalement absurde ou faux, … Est-ce que le résultat est absurde et faux dans tous les cas ?
Ceux qui savent raisonner librement comprendront …

Est ce que mon exemple d’armoire téléphonique ne fait pas au moins hésiter les plus récalcitrants ? (à lire plus haut #39, attention à bien lire ma version car elle a été transformée par malhonnêteté intellectuelle ou par précipitation (réaction du parfait dogmatique à qui on a l’impression d’avoir touché son père ou sa mère ). J’ai même pénalisé le cas de l’armoire avec documentation en disant qu’elle ne fonctionne pas ! Alors que la comparaison ne l'imposait pas du tout.

Je cherche donc toujours la définition de « documentation exhaustive » ....

[el_slapper]

Jamais de la vie !! Bien au contraire !!
Je m’adapte complètement à la situation que je trouve. C’est la problématique du projet qui implique la démarche qui sera employée.
Je demande juste la définition de « documentation exhaustive » universelle puisque énoncée de manière universelle.

Tu réfléchis en termes de logique formelle. Le manifeste n'est pas de la logique formelle. La définition est par essence vague, et se doit d'être affinée au cas par cas.

Attention !! UML n’est qu’un langage : Unified Modeling Langage. La confusion entre UML et méthode est hyper répandue.
Comme pour tout langage, avec UML, on peut faire tout et n’importe quoi ! Des spaghettis, du vrac, du clean aussi. C’est un langage, c’est tout, rien de plus.

Tu crois que j'ai précisé "trucs basés sur" juste pour que tu fasse exprès de ne pas le lire? Non, je parle bien de gens qui vendent des méthodes basées là-dessus. J'en ai connu de fort compétents.

Je cherche la définition de « documentation exhaustive » puisque c’est l’expression du manifeste.

Tu cherches à démonter en logique formelle un manifeste basée sur de l'expérience et du vécu. Tu est à coté du sujet.

Non, je ne suis pas du tout d'accord.
La définition est un des piliers de la communication. C’est ce qui permet aux gens de se comprendre.
Le manifeste commencerait son œuvre par employer une expression indéfinissable pour un sujet dont la finalité est … justement la communication (spécifications), hum … !!

Parceque justement, la communication n'est pas de la logique formelle. En fonction du contexte, les mêmes mots peuvent prendre un sens différent. Documentation exhaustive, quand tu bosses pour le DOD, ça a la définition donnée par Lucky. Et rien d'autre. Dans d'autres contextes, ça sera celle de l'AFNOR, ou une autre.

Avec un truc en plus: le manifeste part du principe qu'il n'est pas raisonnable d'espérer faire une spec qui soit sans erreur, et que le dev n'ai plus qu'à suivre aveuglément. L'idée de base, c'est justement que les specs parfaites exactes - comme ce que tu exiges du manifeste - ne sont pas un objectif raisonnable. L'objectif raisonnable, c'est un niveau de spec qui permette de savoir ou on va. Le détail précis, il sera réglé au niveau de la spécification de bas niveau, aussi connue sous le nom de "code informatique".

Et par récursion, ça s'applique aussi au manifeste lui-même : il donne les grandes lignes, mais pour le détail exact, c'est aux gens du projet de mettre les mains dans le cambouis pour savoir quel est exactement le niveau de documentation dont ils ont besoin.

Je suis d’accord sur ces nuances (mais guide de base : bof bof).
Malheureusement, il y a beaucoup de personnes (une majorité à mon avis chez les "agiles" !!) qui prennent tout à la lettre et l’appliquent avec force (il suffit de lire cette discussion, c’est édifiant) sans jamais adapter les principes au contexte du projet. C’est l’un des vrais dangers de ce manifeste. Son imprécision permet à quiconque de dire « j’ai raison parce que c’est écrit » ensuite cette personne cite sa propre interprétation et toutes les réussites de projets (que personne n’a vérifié), comme s’il s’agissait de preuves. Je ne connais que les agiles qui revendiquent autant de réussites pour nous convaincre (moi mes réussites, je ne les étale pas), à force de répétition, beaucoup suivront … cela durera un temps. En faisant cela, ils ont une démarche de parfait mouton, en tout cas sans réflexion personnelle.

Ah, des gens qui suivent le petit manuel aveuglément, j'en connais un paquet. Il y en a partout. Ca ne préjuge en rien de la qualité des principes qu'ils dévoient.

Je dis simplement attention aux méthodes, aux croyances infondées, aux exemples à suivre (les cas sont toujours différents les uns des autres) … on arrive très vite à des formes d’intégrisme avec des personnes qui sont moutonniers et ne s’en rendent même pas compte (elles clament l’inverse bien sûr). C’est flagrant dans cette discussion.

Miroir, mon beau miroir.....

Petit exercice :
Prenons la négation de chacune des lignes du manifeste et réfléchissons.

Si le manifeste possède une vraie valeur, un vrai exemple à suivre, on devrait arriver à quelque chose de totalement absurde ou faux, … Est-ce que le résultat est absurde et faux dans tous les cas ?
Ceux qui savent raisonner librement comprendront …

Est ce que mon exemple d’armoire téléphonique ne fait pas au moins hésiter les plus récalcitrants ? (à lire plus haut #39, attention à bien lire ma version car elle a été transformée par malhonnêteté intellectuelle ou par précipitation (réaction du parfait dogmatique à qui on a l’impression d’avoir touché son père ou sa mère ). J’ai même pénalisé le cas de l’armoire avec documentation en disant qu’elle ne fonctionne pas ! Alors que la comparaison ne l'imposait pas du tout.

Je cherche donc toujours la définition de « documentation exhaustive » ....

Tu fais encore de la logique formelle.

Et ton exemple était pourri jusqu'à la moelle de mauvaise foi. Pourri jusqu'à la moelle, parce qu'il présupposait qu'une spécification totale et qu'une documentation totale n'avaient que des qualités, et qu'un développement plus itératif avec moins de préparation n'avait que des défauts. Pourri jusqu'à la moelle, parce qu'en plus, une armoire électrique, ça n'est pas une bonne analogie : une fois mis en place, ça ne bouge plus. Il y a des exceptions, mais la plupart des logiciels informatiques vivent, comme le monde qui les entourent, et doivent sans cesse évoluer pour faire face à un monde qui change. Le développement logiciel est une discipline beaucoup plus fluide que l'ingénierie électrique. Elle ne peut pas se permettre d'en suivre les principes. Su tu me parles d'exploitation, de chaines comptables à faire tourner tous les jours, là, oui, je serais d'accord. On est en production(de données, dans notre cas). Mais le logiciel qui tourne, lui, est une conception, pas une production. Et une conception qui est sans cesse mouvante, en raison d'un environnement mouvant(alors que le bâtiment alimenté par ton armoire, hein, il ne va pas changer des masses).

Dit autrement, tu appliques des grilles de lectures erronées au métier du développement informatique. Nous ne faisons pas de la science informatique ou de l'algorithmique pure(disciplibes fort utiles au demeurant, mais qui ne sont pas dans le périmètre du manifeste, qui lui parle quand même essentiellement d'informatique de gestion, il suffit de lire le pedigree de ses auteurs pour s'en rendre compte). Nous resolvons des problèmes mouvants pour des utilisateurs pressés.