Discussion :

[Luckyluke34]

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

On te l'a donnée 2 posts plus haut, pas de notre faute si tu refuses de la prendre... Crois moi, tu peux lire 20 bouquins sur l'agilité, tu auras la même. C'est aussi ton problème, tu t'en tiens au manifeste agile sans t'intéresser à la littérature autour du sujet ou aux méthodes bien concrètes qui implémentent le manifeste agile.

Quand au fait qu'il puisse exister, en matière de gestion de projet logiciel (puisqu'il s'agit quand même de ça), une quelconque définition "universelle" qui n'ait pas été énoncée par un individu ou un groupe, je n'y crois pas. Ou sinon, comment fais-tu pour consulter cette définition ? Tu la demandes au premier pékin que tu croises dans la rue et puisqu'elle est universelle, ça sera la bonne ?

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 …

Soit, faisons l'exercice.

La négation de "Nous accordons plus de valeur à un logiciel qui fonctionne qu'à une documentation exhaustive" est :

"Nous accordons autant ou moins de valeur à un logiciel qui fonctionne qu'à une documentation exhaustive".

Ce n'est ni absurde ni faux, cela mène simplement, selon les signataires du manifeste agile, à un taux de succès dégradé (ou un taux d'échec plus important si tu préfères), en termes de respect des délais, des coûts et des fonctionnalités des projets informatiques où l'équipe a adopté cette approche.

En effet, dans chaque phase du développement, on va privilégier l'exhaustivité de la documentation au bon fonctionnement du code qu'on écrit. En cas de délai trop serré pour effectuer les deux activités (et cela arrive souvent dans les projets puisque les estimations de délais effectuées au départ ne sont... que des estimations, voir cette étude), notre principe nous dit qu'on doit écrire la documentation la plus exhaustive possible, quitte à faire des sacrifices sur le périmètre ou la qualité du code. D'où, en sortie, soit des fonctionnalités au rabais ou buggées, soit un non respect des délais ou des coûts si on veut quand même assurer exhaustivité de la doc ET fonctionnalité du code.

Dire qu'on veut un logiciel qui fonctionne ET une documentation exhaustive serait une approche valable si les prévisions de coûts et délais faits en début de projet étaient fiables, or ce n'est pas le cas. Donner la priorité à une tâche plutôt qu'une autre permet d'obtenir ce qui importe le plus au demandeur en cas de retard, d'imprévu technique ou fonctionnel en cours de route et cela arrive très souvent.

[CaféFort]

« La négation de "Nous accordons plus de valeur à un logiciel qui fonctionne qu'à une documentation exhaustive" est :
"Nous accordons autant ou moins de valeur à un logiciel qui fonctionne qu'à une documentation exhaustive".

Je ne suis pas d’accord avec la négation de l’expression que tu as écrite. Tu vas peut-être encore me demander la solution ? (comme pour les tests de non régression).

« Ce n'est ni absurde ni faux, cela mène simplement … »

Je ne comprends rien à toute la suite.
Toutefois, tu arrives à la conclusion que la négation de l’expression n’est ni fausse ni absurde, c’est donc que tu écris que l’expression et sa négation sont valables.
Une expression qui est vraie et dont la négation est aussi vrai (c’est ce que tu écris) => l’expression elle-même est alors absurde !!! Merci !!

Tu écris donc que « Nous accordons autant ou moins de valeur à un logiciel qui fonctionne qu'à une documentation exhaustive" est absurde. Merci pour la démonstration.

[CaféFort]

« L'idée de base, c'est justement que les specs parfaites exactes - comme ce que tu exiges du manifeste »

Non je demande seulement que tout le monde puisse comprendre le manifeste et pour le comprendre il faut avoir le sens des expressions comme « documentation exhaustive ».

« Et par récursion, ça s'applique aussi au manifeste lui-même »

Tu essaies de devenir un peu formel là .
Dans ce cas, il faudrait avoir le cas de base pour débuter la récursivité (ou la terminer selon le type de récursivité ).
Ex de la factorielle : pour factorielle(n), pour n = 1, n! = 1 permet de lancer la mécanique.
Malheureusement dans ce que tu écris pour « s’appliquer aussi au manifeste », ça ne marche pas. Pas de cas de base. Ça a du bon le raisonnement, à condition qu’il soit correct !

« Et ton exemple était pourri jusqu'à la moelle de mauvaise foi. Pourri jusqu'à la moelle, … »

Il te dérange autant ? Il a donc fait mouche ! Yes !

« une fois mis en place, ça ne bouge plus. » (l’armoire téléphonique)

Tu n’as jamais vu intervenir les techniciens qui installent de nouvelles lignes, multiplexages, etc … ? Si si ! Elle a besoin d’évoluer l’armoire !! Tu vois peut-être le technicien en téléphonie comme un déménageur d’armoire. Ce n’est pas le cas et le contenu est structuré.

C’est bien gentil tout ça … mais je me permets d’insister.

C’est quoi la définition dans l’absolu d’une « documentation exhaustive », comme c’est indiqué par le manifeste ? Tout le monde en a grand besoin.

Un grand merci à Luckyluke qui nous a donné le résultat au message précédent .

Les logiciens comprendront.

[el_slapper]

(.../...)C’est quoi la définition dans l’absolu d’une « documentation exhaustive », comme c’est indiqué par le manifeste ? Tout le monde en a grand besoin.
(.../...)

Bon, puisque tu veux jouer au con, jouons au con, et ouvrons le wiktionnaire :

Documentation : Ensemble de documents recueillis sur une question.
Exhaustif : Qui inclut tous les éléments possibles d’une liste, qui traite totalement un sujet.

La question en question étant un ensemble logiciel, la documentation exhaustive est donc un ensemble de documents relatif à cet ensemble logiciel, couvrant l'intégralité de cet ensemble logiciel, listant la totalité des cas possibles couverts par cet ensemble logiciel.

et à part tourner dans le vide, ça t'amène ou?

[CaféFort]

Documentation : Ensemble de documents recueillis sur une question.
Exhaustif : Qui inclut tous les éléments possibles d’une liste, qui traite totalement un sujet.

La question en question étant un ensemble logiciel, la documentation exhaustive est donc un ensemble de documents relatif à cet ensemble logiciel, couvrant l'intégralité de cet ensemble logiciel, listant la totalité des cas possibles couverts par cet ensemble logiciel.

et à part tourner dans le vide, ça t'amène ou?

Cela m'amène à constater que le manifeste énonce quelque chose qu'il est impossible de réaliser. Le manifeste parle de qque chose d'impossible à définir et à faire (je reprends tes lignes : lister tous les cas possibles couverts par un logiciel est impossible à faire étant donnée la combinatoire d'un logiciel).

Et comme une documentation exhaustive ne peut pas exister, cette ligne du manifeste a le même sens que "valoriser un logiciel qui fonctionne" (un point c'est tout, sans la suite) puisque toutes les documentations sont forcément partielles. (je l'écris depuis un moment).

D'où le titre de cette discussion.

Est-ce que les auteurs ont réfléchi 2 minutes ? Ça frise l'absurde.

Je crois qu'on a fait le tour de la question.

[el_slapper]

Cela m'amène à constater que le manifeste énonce quelque chose qu'il est impossible de réaliser. Le manifeste parle de qque chose d'impossible à définir et à faire (je reprends tes lignes : lister tous les cas possibles couverts par un logiciel est impossible à faire étant donnée la combinatoire d'un logiciel)..

Mais c'est justement ce à quoi ils sont confrontés : on leur demande une documentation exhaustive, et ils répondent que ce n'est pas la priorité.

Et comme une documentation exhaustive ne peut pas exister, cette ligne du manifeste a le même sens que "valoriser un logiciel qui fonctionne" (un point c'est tout, sans la suite) puisque toutes les documentations sont forcément partielles. (je l'écris depuis un moment)..

Non, tu tournes autour de ce teste pour essayer de le démolir par tous les moyens possibles. Et tu fais fi du contexte. Le contexte, ce sont des grands comptes(banques, armées, états, industries...) qui exigent de documentations exhaustives(exemple caricatural : le F35) - ce qui n'a aucun sens, tu viens de le dire. Cette phrase, signifie donc simplement "arrêtez de nous faire chier avec vos exigences irréalistes en termes de documentation". Tu l'as dit toi même, une documentation exhaustive, ça n'est pas réaliste.

Donc, en fait, ils sont d'accord avec toi.

D'où le titre de cette discussion. .

Qui me fait douter que tu est sérieux, puisqu'en fait, tu dis la même chose qu'eux. De manière beaucoup plus formelle, mais ça revient au même.

Est-ce que les auteurs ont réfléchi 2 minutes ? Ça frise l'absurde..

Je crois qu'on a fait le tour de la question.

En effet, tu est d'accord avec eux, et tu leur craches dessus. Il n'y a plus rien à dire.

[Luckyluke34]

Je ne suis pas d’accord avec la négation de l’expression que tu as écrite.

Ce n'est pourtant pas si sorcier.

¬(a > b) ≡ (a <= b)

Les logiciens comprendront.

Les logiciens ont surtout les oreilles qui sifflent quand on voit ce que tu écris.

Mais puisque tu sembles te réclamer de cette discipline, peut-être peux tu nous faire une démonstration logicienne de la vraie négation de la proposition "Nous accordons plus de valeur à un logiciel qui fonctionne qu'à une documentation exhaustive", puisque la mienne est erronée ?

[Logan Mauzaize]

Le titre du sujet est volontairement provocateur car j'aimerais avoir un maximum d'avis, des retours d'expériences sincères et objectifs, ...

Au fil de cette discussion, j'ai surtout l'impression que tu recherches un maximum de personnes à troller

Pourquoi dans le manifeste, a-t-on mis en opposition "logiciel opérationnel" et "documentation exhaustive", comme si on ne pouvait pas avoir les deux ?

Ce sont deux éléments produits durant la phase de réalisation. Il y a donc nécessairement besoin de ventiler le coût et temps sur ces deux items. Ici, il est question de prioriser l'un par rapport à l'autre et non de les opposer. S'il étaient opposés on ferait l'un ou l'autre. Or ici il est question de "finir" le logiciel plutôt que la documentation (si le choix doit être fait).

Quel que soit le domaine technique (aéronautique, énergie, médical, ...), la création d'un nouveau produit passe par des étapes de définition de plus en plus précises et laisse de moins en moins de place au hasard, jusqu'au produit terminé.

Oui et non. Cela dépend pas mal des aspects concernés. Les aspects physique/mathématiques ou de la sureté sont évidemment bien définis mais le reste beaucoup moins. Encore qu'aujourd'hui on travaille essentiellement avec des "modèles" (représentation abstraite qui omet certains degrés d'incertitude et d'aléas) donc pour la précision on repassera ...

Concernant le côté hasardeux, toute personne un tant soit peu professionnelle et quelque soit son domaine, cherchera à l'éviter. Après pour les autres, on ne répond de rien. Mais dans ce dernier cas, on ne peut rien en dire puisque plus rien n'est applicable.

C'est ce qui permet de gagner en fiabilité et en sécurité.

Je pose la question : "est-ce le seul moyen ? est-ce une garantie ?"

Votre voiture, vous voulez qu'elle soit créée de manière agile ? Donc aucun module décrit ou calculé au fur et à mesure et les caractéristiques constatées et non prévues ?

Le contraire de "exhaustif" (ie complet) ce n'est pas "inexistant" mais "incomplet". Et dans le cas présent, l'exhaustivité n'est pas non plus exclu ! Et l'absence ne veut pas dire non plus "non prévu" ...

C'est un peu l'inverse de l'industrialisation non ? Pourquoi en serait-il autrement dans le développement de logiciels ?

Premièrement la production logicielle n'a rien à voir avec une chaîne de production et donc de l'industrialisation. Les projets que tu mentionnes (aéronautique, énergie, médicale) ont toujours une phase initiale de "prototypages" ; dans l'aéronautique on parle d'IronBird, MSN-1 ou MSN 0. Ce n'est qu'après qu'intervient la production en chaîne.

D'ailleurs on ne "construit" pas une application, on la "conçoit" ou "développe" ! Au mieux on peut dire qu'on élabore des chaînes d'assemblage pour les données ...

Ensuite, les auteurs du manifeste agile revendique le côté "artisanat" et non "industriel" du développement logiciel. Il est donc normal que les principes d'industrialisation ne collent pas à leurs propos. C'est contraire à leurs points de vue.

[Luckyluke34]

Est-ce que les auteurs ont réfléchi 2 minutes ? Ça frise l'absurde.

Ce qui est absurde, c'est ton acharnement à plaquer une grille de lecture de logique formelle (mal maîtrisée, au passage) sur un manifeste qui ne cherche qu'à donner une direction, des recommandations générales, tirées de l'accumulation de constatations empiriques allant dans le même sens. On ne cherche pas à écrire un théorème mathématique, on cherche à ce que les projets informatiques réussissent mieux. Encore une fois, tu peux avoir le sentiment que tous les projets auxquels tu as participé ont merveilleusement fonctionné - parfait, personne ne te force à adopter une méthode agile si tu n'as pas les problèmes qu'elles sont censées résoudre.

Et tu tournes en rond encore et encore autour de ce seul argument de "logique" depuis le début sans nous répondre sur la mine d'éclaircissements qu'on t'a fournis : le taux d'échec des projets, le compromis à faire entre quantité de documentation et maintenabilité, la démarche de coupler davantage la documentation au code, la prévisibilité vs l'adaptabilité, etc, etc. (je ne vais pas paraphraser 4 pages de discussion)

[CaféFort]

« tu recherches un maximum de personnes à troller »

C’est surprenant comme réaction, mais bon, là j’ai eu de la chance car cette fois, médiateur (?) tu ne m’as pas insulté.

« Ce sont deux éléments produits durant la phase de réalisation. Il y a donc nécessairement besoin de ventiler le coût et temps sur ces deux items. Ici, il est question de prioriser l'un par rapport à l'autre et non de les opposer. S'il étaient opposés on ferait l'un ou l'autre. Or ici il est question de "finir" le logiciel plutôt que la documentation (si le choix doit être fait). »

Heu … Etablir une priorité, c’est pondérer une chose plutôt qu’une autre, donc faire un choix (de pondération) !!! Tu défends une chapelle peut-être ? En tout cas, tu nous éloignes encore une fois des vrais problèmes avec des remarques non pertinentes. C'est dommage.

« Oui et non. Cela dépend pas mal des aspects concernés. Les aspects physique/mathématiques ou de la sureté sont évidemment bien définis mais le reste beaucoup moins. Encore qu'aujourd'hui on travaille essentiellement avec des "modèles" (représentation abstraite qui omet certains degrés d'incertitude et d'aléas) donc pour la précision on repassera ... »

Bah oui ! Tu es bien d’accord avec moi bien sûr !! Tous les modèles apportent des informations complémentaires, c’est leur but. Un modèle (au sens large) est généralement employé quand il n’est pas possible de traiter un problème de manière analytique. Ce n’est pas pour s’amuser ou faire joli , mais pour « avancer sur un problème », donc apporter des « précisions » au sens d’informations complémentaires.

« Premièrement la production logicielle n'a rien à voir avec une chaîne de production et donc de l'industrialisation »

L’industrialisation, ce n’est pas que le travail à chaîne !!! C’est bien sûr beaucoup plus large que cela.

« Ensuite, les auteurs du manifeste agile revendique le côté "artisanat" et non "industriel" du développement logiciel. Il est donc normal que les principes d'industrialisation ne collent pas à leurs propos. C'est contraire à leurs points de vue. »

C’est un point de vue, avec ses avantages et ses inconvénients par exemple au niveau du coût, de la pérennité du résultat, … etc. Ce sont peut-être des éléments mineurs pour toi, mais pas pour tout le monde.
En plus pour ce qui est des méthodes agiles centrées sur les tests, comme on sait qu’un programme avec une couverture de test de 100 % ne garantit strictement rien (sauf que le même test donnera toujours le même résultat), on est bien avancé !! (attention, je préviens que je connais bien cette problématique, donc merci d'éviter d'écrire n'importe quoi siou plait ).
Il ne faudrait pas confondre agilité et « tourner en rond ».

[Luckyluke34]

comme on sait qu’un programme avec une couverture de test de 100 % ne garantit strictement rien (sauf que le même test donnera toujours le même résultat)

Il n'y a strictement aucun rapport entre le pourcentage de couverture de tests (20, 40 ou 100%) et le fait que le même test donnera toujours le même résultat. Je me demande bien pourquoi tu relies ces deux idées dans la même phrase avec un connecteur logique.

Puisque tu connais bien la problématique, je ne t'apprendrai rien en disant que l'objectif d'avoir 100% de couverture de tests est très controversé dans la communauté agile et chez les gens qui font des tests automatisés en général. Les 100% de couverture sont par ailleurs un homme de paille fréquemment utilisé par les opposants aux approches centrées sur les tests, pour polariser le débat sur un aspect extrême mais fallacieux du problème.

Maintenant si on regarde un test automatisé en particulier, il garantit bel et bien une chose : que ce qui est déclaré dans son assertion est vrai pour les données testées. C'est quand même une assurance très intéressante à avoir en complément avec d'autres : système de types/compilation, programmation par contrats, etc. etc. Il garantit aussi qu'une trace écrite d'une propriété du programme est conservée, sous forme d'exemple qui est un des types de formulation de problème les plus intuitivement comprises par les êtres humains.

[CaféFort]

Et tu tournes en rond encore et encore autour de ce seul argument de "logique" depuis le début sans nous répondre sur la mine d'éclaircissements qu'on t'a fournis : le taux d'échec des projets (...)

Bah, ça tombe bien que tu en parles Luckyluke !! Le taux d'échec des projets, c'est quelque chose qui doit être très formel puisque les méthodes agiles s'en servent comme élément de comparaison.
Pour pouvoir faire une comparaison, il est nécessaire de partir sur les mêmes bases.

Donc, je te l'avais déjà demandé, mais ni toi, ni personne ne m'a répondu (de manière formelle bien sûr).

On sait que les méthodes agiles ne définissent pas de but précis au départ.

Ma question est donc : c'est quoi la réussite ou l'échec d'un projet pour les méthodes agiles (sans but précisément défini ) ?

[Luckyluke34]

On sait que les méthodes agiles ne définissent pas de but précis au départ.

La phrase est tellement vague et vide de sens que je ne sais pas si je dois qualifier ça d'intox, de troll ou juste de poncif idiot. Que répondre à quelqu'un qui se félicite de son ignorance et se roule dans ses préjugés avec tant de délectation ? Pas grand-chose malheureusement à part "informe-toi", ce que tu ne feras probablement pas.

Ma question est donc : c'est quoi la réussite ou l'échec d'un projet pour les méthodes agiles (sans but précisément défini ) ?

3è ou 4è édition : c'est la satisfaction du commanditaire par rapport au produit fini en termes de coûts, délais, fonctionnalités ou tout autre critère important dans son domaine. Je répète encore ou tu vas me demander de pondre un théorème mathématique sur la question ?

[Luckyluke34]

Au passage, on attend toujours ta négation logique de

"Nous accordons plus de valeur à un logiciel qui fonctionne qu'à une documentation exhaustive"

puisque la mienne était fausse.

Et environ 463 autres de tes affirmations à l'emporte-pièce qu'on t'a demandé de préciser si tu relis la conversation... mais j'oubliais, un maître ne se rabaisse pas à "donner la solution" si facilement

[CaféFort]

La phrase est tellement vague et vide de sens que je ne sais pas si je dois qualifier ça d'intox, de troll ou juste de poncif idiot. Que répondre à quelqu'un qui se félicite de son ignorance et se roule dans ses préjugés avec tant de délectation ? Pas grand-chose malheureusement à part "informe-toi", ce que tu ne feras probablement pas.

3è ou 4è édition : c'est la satisfaction du commanditaire par rapport au produit fini en termes de coûts, délais, fonctionnalités ou tout autre critère important dans son domaine. Je répète encore ou tu vas me demander de pondre un théorème mathématique sur la question ?

Heu ... il me semble que le sujet est "les méthodes agiles" et non ceux sur lesquels vous voulez m'embarquer puisque personne ne semble avoir de vraie réponse.

"informe-toi", ce que tu ne feras probablement pas.

Il me semble que c'est ce que je fais là, non ? Vous donnez une bien mauvaise image des méthodes agiles !!!

C'est la satisfaction du commanditaire par rapport au produit fini en termes de coûts, délais, fonctionnalités ou tout autre critère important dans son domaine. Je répète encore ou tu vas me demander de pondre un théorème mathématique sur la question ?

Pourquoi tu n'aimes pas les maths ? Pourtant la logique c'est des maths !! Tu devrais adorer !
Une réponse plus précise et factuelle que celle-ci serait grandement préférable, sinon on va forcément finir par croire qu'il n'y a que des échecs déguisés en réussites !! Et ça, je ne le crois pas, quoique maintenant que je lis tout cela ... avec autant d'insultes !!

Comme il n'y a pas de but clairement défini ... sur quelle base un projet est-il qualifié de réussite ou d'échec avec les méthodes agiles siou plait ? du factuel svp !!! sinon, on va finir par tous penser comme l'autre discussion (une histoire de vaste arnaque je crois).

[ZenZiTone]

sur quelle base un projet est-il qualifié de réussite ou d'échec avec les méthodes agiles siou plait ? du factuel svp !!!

Qu'il ne te déplaise, il n'y a pas de factuel dans le manifeste agile. Et il ne sert à rien d'essayer d'aller plus loin pour une bonne raison : le manifeste agile ne décrit pas une méthode mais une sorte de philosophie que doit avoir le chef de projet ET son équipe.

Si tu veux en savoir plus sur l'agilité regarde à quoi ressemble les méthodes agiles. Mais là encore il ne faut pas oublier que : chaque projet est différent et nécessite d'adapter sa gestion de projet ! On ne cherche donc pas de méthode miracle, mais d'orientations, d'outils pour essayer de les aborder au mieux.