Discussion :

[CaféFort]

Bonjour,

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

La deuxième ligne du manifeste agile est : "Des logiciels opérationnels plus qu’une documentation exhaustive".

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 ?

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é. C'est ce qui permet de gagner en fiabilité et en sécurité. 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 ? C'est un peu l'inverse de l'industrialisation non ? Donc selon le manifeste, soit elle fonctionne, soit elle est documentée de manière exhaustive ... et il serait donc impensable que l'un apporterait naturellement l'autre.

Pourquoi en serait-il autrement dans le développement de logiciels ?

[Luckyluke34]

A question provocatrice, réponse provocatrice

On ne peut pas avoir les deux car l'être humain est un animal paresseux et étourdi par nature et on ne peut pas lui faire confiance à 100% pour qu'il maintienne le code en permanence synchronisé avec la documentation et vice versa. Il est aussi subjectif et capable d'intérpréter une spec complètement différemment de son voisin (cf le serious game "Spécifieurs & Artistes"). C'est déjà très compliqué quand c'est le même individu qui maintient le code et la documentation, ça l'est encore plus quand ce sont deux personnes différentes. Et ça devient un cauchemar quand la documentation en question est un diagramme représentant les 658 classes de l'application et qui tient en 20 pages.

Du coup, on essaie de faire basculer autant de spécification que possible du domaine du document écrit (fichier Word, cahier des charges papier, plan de test manuel sous Excel...) vers le royaume de l'exécutable, du code. Des mouvements comme Behavior Driven Development traduisent cette démarche. L'idée est de coupler fortement les attendus et la solution (le code) afin que toute disparité entre les deux soit immédiatement repérée. Une des solutions qu'on a trouvées pour cela est que la spécification devienne elle-même du code.

Par ailleurs, tu n'as pas tort d'opposer industrialisation et agilité. Tout un pan de la communauté agile (et en particulier en France) se revendique de l'artisanat plutôt que de l'industrie, du spécifique "fait main" plutôt que de l'idée que tous les projets de développement peuvent rentrer dans le même moule et que les solutions, les contraintes et les clés de succès sont reproductibles de cas en cas. Ce mouvement se base sur le constat d'échec d'un certain nombre de projets informatiques sur lesquels on a essayé de calquer un processus issu de l'industrie traditionnelle et qui ont échoué.

Cela ne veut évidemment pas dire que les domaines métier couverts deviennent artisanaux. L'industrie aéronautique reste l'industrie aéronautique, avec tout ce que cela implique en termes de validité et de robustesse des applications que l'on développe pour elle. Mais mener un projet de logiciel embarqué dans un avion exactement de la même manière qu'on mène le projet de l'avion lui-même n'est pas forcément une bonne idée. Ce sont deux choses différentes.

[CaféFort]

Merci Luckyluke34 !

On ne peut pas avoir les deux car l'être humain est un animal paresseux et étourdi par nature

Pour cela, je suis d’accord et c’est vrai qu’écrire la doc d’un programme est on ne peut plus ch… heu disons rébarbatif !

maintienne le code en permanence synchronisé avec la documentation et vice versa

Mais il y a des méthodes et des outils très efficaces pour cela (par exemple Unified Process et ses dérivés), la doc technique est par nature toujours synchronisée et cela, sans travail ! La prise de connaissance d’un projet s’en trouve facilitée d’autant et le travail des développeurs aussi.

intérpréter une spec complètement différemment de son voisin

Effectivement, il y a plein d’exemples mais ce n’est que l’étude des besoins qui est en défaut, pas la suite (analyse, codage). Malheureusement ce sont toujours les développeurs qui doivent rattraper les erreurs faites en amont (les specs) … et bien sûr tout en gardant les mêmes deadline !!

Par ailleurs, tu n'as pas tort d'opposer industrialisation et agilité.

Non, je n’oppose pas les deux concepts. Mais les ardents défenseurs des méthodes agiles les opposent. En même temps, ils semblent aussi se bouffer le nez entre eux, par exemple entre Scrum et XP. Je trouve assez surprenant de voir des personnes n’ayant eu aucune formation en génie logiciel faire du management de projet informatique, par exemple avec Scrum. Je pense qu’il est beaucoup plus rare de les voir manager les ingénieurs des autres secteurs ! Pourquoi est-ce possible en informatique, mystère !

plutôt que de l'idée que tous les projets de développement peuvent rentrer dans le même moule

Pourtant, c’est ce qui existe dans les autres domaines. Les normes n’ont jamais empêché la créativité. Les normes facilitent le travail, la communication, … que ce soit dans le bâtiment, l’industrie, … Schématiquement, ça permet juste de s’y retrouver quel que soit le sujet. Ça aide beaucoup car lire le code de quelqu’un d’autre, c’est rarement cool.

on a essayé de calquer un processus issu de l'industrie traditionnelle et qui ont échoué

Tout dépend ce qu’on appelle échouer. Mais il est vrai que l’industrialisation du logiciel peut paraître ardue et on peut se demander si les éditeurs d’outils et les SSII (celles qui vendent de la régie) y ont intérêt. En même temps, en « Agile », comme on ne peut pas fixer de deadline, on ne risque donc pas d’échouer au moins au niveau des délais. Trop cool l’Agile !!

Mon exemple « aéronautique » était « exagéré » puisque dans les environnements à risques, non seulement on n’est pas dans des méthodes agiles, mais en plus, les programmes sont vérifiés par « preuve de programme » et non par tests.

[Laurent 1973]

La phrase parle aussi d'elle même: "Des logiciels opérationnels plus qu’une documentation exhaustive"

Cela ne veux pas dire qu'il n'y aura pas de documentation, mais juste que l'on considère qu'il vaux mieux avoir un "code qui marche" plutôt que 500 pages de spécifications mais rien de "codé".

N'oublions pas la dernière phrase de ce manifeste: "Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers."
C'est bien un priorisation, nullement une opposition.

Donc, en Agilité, on a de la documentation mais on a surtout un logiciel qui fonctionne

[CaféFort]

N'oublions pas la dernière phrase de ce manifeste: "Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers."

Oui, j'avais bien compris. En même temps, il aurait été difficile d'écrire autrement.

C'est bien un priorisation, nullement une opposition.

Donc, en Agilité, on a de la documentation mais on a surtout un logiciel qui fonctionne

Mais un logiciel à maintenir, c'est mieux avec un "plan". Car c'est simple, tous les intervenants vont devoir explorer le code. C'est en général plus long d'explorer que de faire quelques schémas. La galère est pour ceux qui récupèrent l'ensemble.

[el_slapper]

(.../...)Mais un logiciel à maintenir, c'est mieux avec un "plan". Car c'est simple, tous les intervenants vont devoir explorer le code. C'est en général plus long d'explorer que de faire quelques schémas. La galère est pour ceux qui récupèrent l'ensemble.

C'est plus compliqué que celà.

Aucun plan de bataille ne survit au premier contact avec l'ennemi. Adapté à l'informatique, ça veut dire que dans tout projet non trivial, la spec ne survit pas à l'implémentation. Nous sommes des êtres imparfaits, et le spécificateur ne peut pas penser à tout. C'est confronté à la réalité du code, spécialement si celui-ci doit se fixer sur un existant, que le programmeur va trouver, bien malgré lui, les faiblesses de la spécifications.

Conclusion : si on passe trop de temps à faire un mégaplan gigadétaillé, on met pas mal de ressources en l'air pour rien. Un plan plus léger, que le programmeur doit adapter lui-même à ce qu'il rencontre dans la réalité, est donc une proposition plus réaliste.

Ce qui va avec ça, c'est que l'on assume que le programmeur n'est pas un simple exécutant, mais qu'il est capable de décision. Dans les méthode "traditionnelles" avec méga-gigaplan, il est perçu comme un bête exécutant. Et en fait, non. Même dans les méthodes traditionnelles, le développeur doit s'adapter à ce qu'il rencontre, faire remonter les bizarreries...mais nage dans un process qui n'est pas fait pour ça. Souvent, ça passe quand même, parce qu'on a des développeurs de qualité. Mais leur impact est le même en traditionnel ou en agile. Simplement, en agile, on ne se voile pas la face, et on sait pourquoi on a besoin de gens compétents.

Après, oui, un plan peut être utile. Mais une application bien conçue doit se comprendre au premier coup d'œil. Là aussi, la qualité des gens qui interviennent est essentielle. Et surtout, la démarche agile vient de la constatation que les gens rangent les choses en petit paquet. Un petit paquet pour les notes médicales, un petit paquet pour les impôts, un petit paquet pour la scolarité du petit..... Mais à l'intérieur des petits paquets, le cerveau humain n'a besoin d'un rangement plus précis. Il lui suffit de savoir ou est le paquet des impôts pour retrouver son avis d'imposition. Pas d'avoir rangé tous ses avis dans le bon ordre.

L'agile n'est pas une méthode miracle. Ca permet juste d'éviter certains efforts inutiles. Et seulement quand les gens savent ce qu'ils font. Mais rien que ça, c'est toujours bon à prendre.

[AdmChiMay]

Les différents avis éclairent le problème, ou au moins ce que je pourrai étayer.
Juste pour rire (quoi que) : si l'on parle de pilote d'avion de ligne, voir de chasse (voir seulement de train), on sait ce qu'est l'humain et on en tient compte. La place à l'imperfection est réduite au minimum.
Ceci pour dire que pour la conception ou en cours de développement on peut avoir une marge de manœuvre ou d'incertitude, mais à moment donné, il faut l'évacuer autant que faire se peut. Le "autant que" dépend du contexte.

[CaféFort]

« Aucun plan de bataille ne survit au premier contact avec l'ennemi. Adapté à l'informatique, ça veut dire que dans tout projet non trivial, la spec ne survit pas à l'implémentation. »

C’est un décret ? Bien sûr, cette phrase ne prouve rien. Moi il me faut du concret, du raisonnement.

« C'est confronté à la réalité du code, spécialement si celui-ci doit se fixer sur un existant, que le programmeur va trouver, bien malgré lui, les faiblesses de la spécifications. »

Tout dépend des spécifications, il n’y a pas de règle.

« Conclusion : si on passe trop de temps à faire un mégaplan gigadétaillé, on met pas mal de ressources en l'air pour rien. Un plan plus léger, que le programmeur doit adapter lui-même à ce qu'il rencontre dans la réalité, est donc une proposition plus réaliste. »

« pas mal de ressources en l’air pour rien » : pourtant tout le monde sait qu’une modification tardive coûte 10 à 100 fois plus cher. C’est une bonne raison pour fignoler les specs, non ?
« que le programmeur doit adapter lui-même » : ça, justement, c’est exactement la cause de la majorité des échecs des projets. Le programmeur invente ce qui n’a pas été décrit ! Surtout ne jamais faire cela !!!

« Ce qui va avec ça, c'est que l'on assume que le programmeur n'est pas un simple exécutant, mais qu'il est capable de décision. »

Des décisions, oui, mais dans son domaine uniquement, c’est déjà assez de problèmes non ? C’est pas facile la programmation !

« nage dans un process qui n'est pas fait pour ça »

Pourtant la majorité des processus de développement sont itératifs.

« une application bien conçue doit se comprendre au premier coup d'œil. »

Je connais des projets de plusieurs centaines de milliers de lignes qui sont super bien foutu et totalement bugfree, mais si on n'a que le code source, bonjour l’investissement en temps pour comprendre le fonctionnement.
Même dans un projet simple, la documentation fait gagner beaucoup de temps. C’est assez naturel non ?

A propos de Cockburn : Dans son livre sur les cas d’utilisation, il y a des erreurs monumentales. Le type a écrit des choses sensées, mais le contenu est assez pauvre, beaucoup de banalités. Par contre, et c’est beaucoup plus gênant, son livre contient beaucoup de choses inexactes. A chaque fois qu’il écrit sur UML, il commet des erreurs. Le type semble vraiment faché avec l’analyse. Il aurait dû éviter d’en parler et de s’y opposer puisque ce qu’il écrit est totalement erroné. (par exemples les pages 32 et 33 sont du grand n'importe quoi)

[el_slapper]

C’est un décret ? Bien sûr, cette phrase ne prouve rien. Moi il me faut du concret, du raisonnement.

C'est un retour d'expérience.

Tout dépend des spécifications, il n’y a pas de règle.

Non. En effet. On ne sait jamais sur quoi on va tomber. Raison de plus pour ne pas s'imaginer à l'avance que la spec est sans erreurs.

« pas mal de ressources en l’air pour rien » : pourtant tout le monde sait qu’une modification tardive coûte 10 à 100 fois plus cher. C’est une bonne raison pour fignoler les specs, non ?
« que le programmeur doit adapter lui-même » : ça, justement, c’est exactement la cause de la majorité des échecs des projets. Le programmeur invente ce qui n’a pas été décrit ! Surtout ne jamais faire cela !!!

Il y a deux sources d'erreurs : le spécificateur se plante, ou le programmeur se plante. Si le programmeur se plante, le spécificateur n'y peut rien. Si le spécificateur se plante, le programmeur peut se poser des questions. Dans un monde idéal(que j'ai connu une fois), au moindre doute, il traverse le couloir et va poser la question. Dans un cas moins idéal, ou le spécificateur est injoignable, il faut bien prendre un décision. Dans tous les cas, se contenter de suivre la spec à l'aveugle, c'est aller au massacre.

Des décisions, oui, mais dans son domaine uniquement, c’est déjà assez de problèmes non ? C’est pas facile la programmation !

Certes, non. Mais c'est du travail d'équipe. Le spécificateur, dans un monde idéal, va remarquer quand le programmeur fait des erreurs(c'est fréquent). Et le programmeur va remarquer quand le spécificateur fait des erreurs(c'est fréquent aussi).

Pourtant la majorité des processus de développement sont itératifs.

C'est bien mieux comme ça. Parce que ça donne des occasions supplémentaires de trouver des erreurs.

Je connais des projets de plusieurs centaines de milliers de lignes qui sont super bien foutu et totalement bugfree, mais si on n'a que le code source, bonjour l’investissement en temps pour comprendre le fonctionnement.
Même dans un projet simple, la documentation fait gagner beaucoup de temps. C’est assez naturel non ?

Le bon niveau de documentation. Si tu as un pseudocode qui reprend chaque boucle, chaque assignation, ça ne va rien t'apporter. Si tu as une documentation macro, qui te dis "tiens, les taxes d'assurances sont calculées dans tel module, sauf pour l'automobile qui a sont propre module ici", c'est largement suffisant. Si tu as le détail du calcul dans ta doc, tu vas te perdre autant que dans le code. Et surtout, à la première modification du calcul de taxe, tu peux être sur que la doc détaillé va être fausse. Alors que la doc générique, qui te dis "va regarder là", elle, sera toujours juste.

Ce cas précis, je l'ai connu. Il y avait 36 ans(oui, oui, de 1972 à 2008) entre la création de l'appli et la refonte que j'ai du faire. Il ne restait rien, ni sachants, ni doc. Que le code brut. Et, avec 36 ans de maintenances mensuelles, fatalement, c'était illisible. J'ai laissé 2 docs sur ma nouvelle version : un dessin de chaine détaillé, et une liste complète de toutes les variables garnies par l'appli, avec l'endroit dans la chaine ou le garnissage se faisait(j'ai évidemment éradiqué les innombrables doublons que le temps avait inséré dans l'ancienne appli).

4 ans plus tard, ils ont calculé que ça leur a fait économiser un peu plus d'un temps plein en maintenance. Pourtant, rien des algorithmes n'est documenté. Juste : "tu cherches ça? C'est là, à tel endroit de la chaine".

Je n'avais AUCUNE spec, que le code existant, avec juste pour consignes "on change le format de sortie, profites-en pour refaire un truc maintenable". 170 jours budgetisés, 172 jours consommés. Quand on bosse chez des gens sérieux, qui répondent aux questions quand on en pose(et pour certaines, ils ont creusé, creusé, creusé pendant des semaines pour trouver pourquoi), qui demandent le juste niveau de specs(je n'ai pas dit qui n'en demandent pas du tout, sans les 2 petites specs que j'ai faites, ils auraient été au casse-croute), on peut faire des miracles.

Il est arrivé que je me fade des specs d'algorithmes dans des cas particuliers(un algo particulièrement compliqué, qui méritait sa propre description, d'ailleurs, j'ai fait une version "texte" et une version "graphique" pour mes successeurs). Mais, la plupart du temps, le code se suffit à lui-même, pour ce niveau de détail. L'important, c'est le niveau "juste de specs". Après, si tu a rencontré des gens qui se prétendent agiles, mais sont en fait des cowboys qui ne documentent rien, évidemment, c'est différent.

A propos de Cockburn : Dans son livre sur les cas d’utilisation, il y a des erreurs monumentales. Le type a écrit des choses sensées, mais le contenu est assez pauvre, beaucoup de banalités. Par contre, et c’est beaucoup plus gênant, son livre contient beaucoup de choses inexactes. A chaque fois qu’il écrit sur UML, il commet des erreurs. Le type semble vraiment faché avec l’analyse. Il aurait dû éviter d’en parler et de s’y opposer puisque ce qu’il écrit est totalement erroné. (par exemples les pages 32 et 33 sont du grand n'importe quoi)

Pourquoi tu me parles de Cockburn? Ou l'ai-je évoqué à ce sujet? Et franchement, l'UML, ce n'est pas le sujet. C'est juste une manière parmi d'autres d'écrire des specs.

[CaféFort]

Les différents avis éclairent le problème, ou au moins ce que je pourrai étayer.
Juste pour rire (quoi que) : si l'on parle de pilote d'avion de ligne, voir de chasse (voir seulement de train), on sait ce qu'est l'humain et on en tient compte. La place à l'imperfection est réduite au minimum.
Ceci pour dire que pour la conception ou en cours de développement on peut avoir une marge de manœuvre ou d'incertitude, mais à moment donné, il faut l'évacuer autant que faire se peut. Le "autant que" dépend du contexte.

Je pense que tu veux dire que selon le contexte, le taux d'erreur admissible ne sera pas le même car les conséquences sont différentes ?

[CaféFort]

Merci el_slapper. Je trouve tes infos très intéressantes.

« Aucun plan de bataille ne survit au premier contact avec l'ennemi. Adapté à l'informatique, ça veut dire que dans tout projet non trivial, la spec ne survit pas à l'implémentation. »

C’est donc que la spec a été mal faite. Malheureusement c’est souvent le cas et c’est d’ailleurs une activité qui peut se révéler très difficile.

« Dans tous les cas, se contenter de suivre la spec à l'aveugle, c'est aller au massacre. »

On se rejoint. Le développeur se débrouille comme il peut, sous la pression et en se basant la plupart du temps sur des specs incomplètes pour ne pas dire mauvaises. En même temps, le développeur est peu souvent écouté, surtout s’il remet en question le travail fait en amont. D’où (je pense) la naissances des méthodes agiles. Ce qui est très naturel dans ce contexte.

« Certes, non. Mais c'est du travail d'équipe. Le spécificateur, dans un monde idéal, va remarquer quand le programmeur fait des erreurs(c'est fréquent). Et le programmeur va remarquer quand le spécificateur fait des erreurs(c'est fréquent aussi). »

Oui !! Le programmeur et le spécificateur se renvoient la balle. C'est pas toujours cool ça.

« J'ai laissé 2 docs sur ma nouvelle version : un dessin de chaine détaillé, et une liste complète de toutes les variables garnies par l'appli, avec l'endroit dans la chaine ou le garnissage se faisait(j'ai évidemment éradiqué les innombrables doublons que le temps avait inséré dans l'ancienne appli). »

Je trouve que tu as eu une démarche très constructive. Avec cela, déjà on limite les dégâts et on va droit au but.
Pour la documentation, je ne suis pas pour une documentation (complète) du code mais pour au moins une documentation du fonctionnement général du programme, c'est-à-dire au moins les classes principales et leurs relations et aussi les classes statiques pour tout ce qui sera global au projet (la normalisation du code permet d’identifier facilement ce qui sera global).

« Après, si tu a rencontré des gens qui se prétendent agiles, mais sont en fait des cowboys qui ne documentent rien, évidemment, c'est différent. »

Bravo pour l’image !! C’est effectivement l’impression que j’ai.

« Pourquoi tu me parles de Cockburn? Ou l'ai-je évoqué à ce sujet? »

En fait, c’est au sujet des 7 lignes de ton pied de message. Le lien pointe vers Cockburn. Au sujet d’UML, je pense qu’il est très mal compris et extrêmement mal utilisé la plupart du temps. Ce n’est qu’un langage, et comme tout langage il permet de faire le meilleur comme le pire. De mon point de vue, bien utilisé, c’est un outil formidable. Il n'a pas l'air d'être très apprécié des méthodes agiles (?)

[Luckyluke34]

C’est donc que la spec a été mal faite. Malheureusement c’est souvent le cas et c’est d’ailleurs une activité qui peut se révéler très difficile.

Du coup on fait quoi ? On cherche l'animal rare qui a un talent inné pour rédiger des specs et on prie bien fort pour qu'il soit dans un p**** de bon jour quand il les écrit car on n'a le droit qu'à une seule chance en tout début de projet ?

Ou on admet que ce n'est pas une science exacte et on fait des versions successives qui s'améliorent au fil du temps en tirant les leçons des erreurs commises et des découvertes fonctionnelles faites en cours de route ?

En fait, c’est au sujet des 7 lignes de ton pied de message. Le lien pointe vers Cockburn. Au sujet d’UML, je pense qu’il est très mal compris et extrêmement mal utilisé la plupart du temps. Ce n’est qu’un langage, et comme tout langage il permet de faire le meilleur comme le pire. De mon point de vue, bien utilisé, c’est un outil formidable. Il n'a pas l'air d'être très apprécié des méthodes agiles (?)

C'est intéressant, qu'est-ce qui est faux à ton avis dans ce que dit Cockburn et qu'est-ce qui manque pour qu'on fasse une bonne utilisation d'UML ?

UML est traditionnellement critiqué quand il s'inscrit dans une démarche de Big Design Upfront où chaque bloc de code est fixé dans un diagramme en début de projet, avec un effort rédhibitoire requis pour changer ces modèles ensuite si on s'aperçoit que ça ne correspond pas à ce qu'il fallait faire. Personnellement j'utilise plus UML comme un outil de communication entre développeurs mais les modèles qu'on fait dans notre équipe sont clairement jetables car plus valables au bout de quelques jours. Donc ce n'est pas le mal, mais il souvent utilisé de façon contre-productive.

[CaféFort]

Du coup on fait quoi ? On cherche l'animal rare qui a un talent inné pour rédiger des specs et on prie bien fort pour qu'il soit dans un p**** de bon jour quand il les écrit car on n'a le droit qu'à une seule chance en tout début de projet ?

Bah non. On prend juste un type qui a une démarche structurée et qui ne se laisse pas embobiner ni par les utilisateurs, ni par ses supérieurs . C'est vrai que c'est rare.

Ou on admet que ce n'est pas une science exacte et on fait des versions successives qui s'améliorent au fil du temps en tirant les leçons des erreurs commises et des découvertes fonctionnelles faites en cours de route ?

Faux !! Justement, le développement est une science exacte. La démarche existe. On n'est pas en biologie !! Et les méthodes Agiles nous feraient croire qu'on ne serait pas dans une science exacte !!

C'est intéressant, qu'est-ce qui est faux à ton avis dans ce que dit Cockburn et qu'est-ce qui manque pour qu'on fasse une bonne utilisation d'UML ?

Cockburn est un bon exemple de personne opposée à UML et aux méthodologies à bse d'UML. Son livre contient très peu de choses utiles et qui sont en plus évidentes (à peine 10% d'utile). A chaque fois qu'il mentionne UML c'est faux (diagrammes faux donc analyse fausse), critiques infondées ...

UML est traditionnellement critiqué quand il s'inscrit dans une démarche de Big Design Upfront où chaque bloc de code est fixé dans un diagramme en début de projet, avec un effort rédhibitoire requis pour changer ces modèles ensuite si on s'aperçoit que ça ne correspond pas à ce qu'il fallait faire. Personnellement j'utilise plus UML comme un outil de communication entre développeurs mais les modèles qu'on fait dans notre équipe sont clairement jetables car plus valables au bout de quelques jours. Donc ce n'est pas le mal, mais il souvent utilisé de façon contre-productive.

Effectivement, cela confirme ce que je pense au niveau de sa mauvaise utilisation. Tu utilisais quel modeleur ?
Pourtant UML permet de structure et capitaliser le savoir-faire de l'entreprise (les specs), il permet de les relier à la conception, il permet de synchroniser l'ensemble, de comprendre vite la structure de base du logiciel.
Si on ne comprend pas la structure d'un logiciel avec UML, c'est qu'on la comprendra encore moins avec uniquement le code.
Bien utilisé, UML permet d'accéder au code en démarrant l'exploration du projet par les spec (les cas d'utilisation) et en explorant uniquement les classes concernée par ces cas d'utilisation, ...
Dans l'autre sens c'est aussi possible : partir du code pour voir les specs qui sont concernées (en passant par la conception par traçabilité).

A la louche : 100 000 lignes de code, 200 classes => 30 diagrammes de classes + les autres diagrammes qui facilitent la compréhension. Agile à côté, ça me semble malheureusement un peu vide.

[el_slapper]

C’est donc que la spec a été mal faite. Malheureusement c’est souvent le cas et c’est d’ailleurs une activité qui peut se révéler très difficile.

Ben oui. Justement. Les gens sérieux partent du principe que c'est difficille, et qu'il y aura sans doute des erreurs. Si l'entraineur avait une confiance totale dans son milieu de terrain pour garder la balle, il n'aurait besoin ni de défenseurs, ni de gardien de but. Pourtant, les meilleures équipes cherchent aussi des défenseurs et des gardiens de but. Parcequ'ils savent que même le meilleur milieu de terrain au monde va laisser passer des trucs.

On est dans le monde réel. Dans le monde réel, les gens font des erreurs. Et les gens sérieux le prennent en compte.

On se rejoint. Le développeur se débrouille comme il peut, sous la pression et en se basant la plupart du temps sur des specs incomplètes pour ne pas dire mauvaises. En même temps, le développeur est peu souvent écouté, surtout s’il remet en question le travail fait en amont. D’où (je pense) la naissances des méthodes agiles. Ce qui est très naturel dans ce contexte.

Contexte qui est inévitable.

Je trouve que tu as eu une démarche très constructive. Avec cela, déjà on limite les dégâts et on va droit au but.
Pour la documentation, je ne suis pas pour une documentation (complète) du code mais pour au moins une documentation du fonctionnement général du programme, c'est-à-dire au moins les classes principales et leurs relations et aussi les classes statiques pour tout ce qui sera global au projet (la normalisation du code permet d’identifier facilement ce qui sera global).

Bon, c'était du Cobol, alors les classes..... Non, j'avais des procédures(qui ne sont jamais que des méthodes hors classe), ce qui est une autre manière de structurer le code. Avec ses avantages et ses inconvénients. Mais ce n'est pas important.

Mais au final, une classe, c'est quoi? C'est une structure de données, PLUS le code tapant sur ces données. Les données en sortie, j'avais documenté ou elles étaient garnies (TX-TAXE-ASSURANCE dans le module bidule, sauf si c'est de l'automobile, auquel cas c'est dans le module truc). Les données en entrée étaient un standard boite. Quand aux relations entre modules, eh bien tout était dans le dessin de chaine. Peut-être la différence de vocabulaire(liée à la différence de paradigme, mais faire de l'objet en cobol, ce n'est pas raisonnable, d'ailleurs le compilateur les désactive souvent, et ce n'est pas un hasard) explique-t-elle notre différence. Mes deux feuilles décrivaient, au final, tout ce que tu sembles évoquer : les relations entre les composants, et ou chercher l'information.

Documenter que le calcul de TX-TAXE-ASSURANCE se fait dans la procedure CALCUL-TX-TAXE-ASSURANCE ne me parait pas d'une priorité absolue..... Par contre, dire dans quel fichier source on peut trouver ce calcul, oui, c'est fondamental. Ne serait-ce que parceque ça dissuade de refaire le calcul ailleurs.....

En fait, c’est au sujet des 7 lignes de ton pied de message. Le lien pointe vers Cockburn. Au sujet d’UML, je pense qu’il est très mal compris et extrêmement mal utilisé la plupart du temps. Ce n’est qu’un langage, et comme tout langage il permet de faire le meilleur comme le pire. De mon point de vue, bien utilisé, c’est un outil formidable. Il n'a pas l'air d'être très apprécié des méthodes agiles (?)

Ah, ma signature? Oui, je navigue signatures désactivées, alors j'ai tendance à l'oublier. Ce qu'il dit sur l'UML, je n'en ai rien à péter. Ce qui m'intéresse chez lui, c'est son approche de l'humain. L'humain est une composante fondamentale du projet, et qui est souvent oubliée.

Bah non. On prend juste un type qui a une démarche structurée et qui ne se laisse pas embobiner ni par les utilisateurs, ni par ses supérieurs . C'est vrai que c'est rare.

Non, ça n'existe pas. en tous cas, pas tout le temps. Les êtres humains ont des modes d'echec(et c'est là que je trouve Cockburn fondamental, les détails de sa méthodologie à lui je m'en fous), et il faut les gérer. Et on les gère mieux si on ne s'amuse pas à trop détailler. Le juste niveau de détail est celui qui permet aux humains du projet d'être le plus efficace.

Exiger la perfection, c'est juste inhumain, dans le sens ou on attend d'un être humain des qualités non humaines. Même Lionel Messi rate des penalties. Et on a rarement un Lionel Messi de la spec dans son équipe. C'est là que l'idée de la spec absolue est ridicule : ça demande au spécificateur d'être sans erreurs.

Pour moi, une bonne spec fonctionnelle, ça aurait été "voici le mode de calcul de la taxe d'assurance - pour l'automobile, et pour le reste". Bon, je n'avais pas ça, je n'avais qu'un très vieux code bourré de modifications, mais dont tout le monde s'accordait à dire qu'il était juste. Parceque ça faisait des années que personne n'avait relevé de bug. Alors j'avais 2 solutions :

(1) faire une analyse algorithmique complète de l'existant, faire une spec parfaite, et en déduire un code facile.
(2) essayer de simplifier le code, et voir si, sur une année complète de volumétrie réelle de production, j'avais des écarts(j'ai déjà dit que ce client était sérieux?)

J'ai choisi le point (2). Parceque le (1) semblait hors de portée de ma petite tête. D'ailleurs, au final, vu les couches de correction qui s'étaient entassées, mes prédécesseurs avaient fait pareil : partis d'une idée, puis affinée quand certains résultats paraissent faux. Le tout, sur des décennies. D'ailleurs, rien ne prouve que mon algo final - qui était redoutablement simple - aie été conceptuellement juste. Simplement, il marchait dans tous les cas connus. Aucune erreur n'avait pu être détectée. Et il a du me couter 2 jours, pas plus. combien aurait-il fallu pour eplucher les textes de lois et en trouver un algorithme dont on puisse prouver qu'il était toujours juste? Ou pour faire une analyse formelle exhaustive du code? Bien plus. Et avec un risque d'erreur bien plus fort.

C'est la vraie force des démarches agiles(quand elles ne sont pas cowboy) : elles partent de la réalité pour s'améliorer. Pas de l'idée qu'on se fait de la réalité. Le cerveau humain est bien plus puissant pour travailler sur du concret(alors, je suis bon dans tous les cas sauf pour le yachting, tiens, quelle est la particularité du yachting.....ooooh, il me manque juste tel truc et ça colle!) que sur de l'abstrait(la loi sur les taxes d'assurances concernant les bateaux de plaisance). J'aurais pu(ou les gens du métier, qui étaient des bons, auraient pu, mais ils ont déclaré forfait, demande-toi pourquoi) me masturber le cerveau pendant des semaines sur les spécificités des bateaux de plaisance, mais non, j'ai fait un truc, et là ou il était faux, j'ai corrigé. Et ça marche. 4 ans plus tard, ça marchait toujours "comme du papier à musique" (je cite).

Pas parceque je suis parfait. Mais parceque des gens comme Alistair Cockburn m'ont enseigné à gérer mes propres faiblesses. A systématiquement contrôler mes sorties. J'ai passé 6 semaines à comparer mes données avec les vraies, et à corriger mes erreurs. Si il avait fallu tout documenter, il aurait fallu 60 semaines...et ça aurait été bourré d'erreurs. Que ça soit moi ou le meilleur spécificateur du monde.

[Laurent 1973]

Faux !! Justement, le développement est une science exacte. La démarche existe. On n'est pas en biologie !! Et les méthodes Agiles nous feraient croire qu'on ne serait pas dans une science exacte !!

En fait, l'informatique est plutôt du domaine du système complexe voir qui s'approche de la théorie du chaos
Prenons un peut exercice "chaotique" à résoudre: "On veux s'assurer qu'au cours d'une réunion, la température de la salle soit constante à 22°C"

Solution prévisible:
- On analyse les caractéristiques thermodynamiques de la salle.
- On recherche les prévisions météo du moment pour savoir la température extérieur, le niveau d'ensoleillement, ...
- On vérifie qui sera présent à cette réunion et on détermine leur pouvoir calorifique en fonction de leur masse corporel
- On identifie les appareils électrique présent (machine à café, PC, éclairage, ...) pour connaitre leurs effet de "chauffe"
Avec toutes ces données, en bon scientifique, on détermine à l'avance la position de tout les radiateurs de la salle et éventuellement les moments précis où il faudrait les baisser ou les monter.
Par contre, on imposera à tout les participants de ne pas prendre ou perdre de poids avant la réunion et de venir avec le matériel informatique qu'ils ont bien déclaré.

Solution adaptative.
On place un thermomètre dans la pièce
Régulièrement, en fonction de la température, on baisse ou on augmente les radiateurs.

En informatique, on essaye de résoudre des problème du même ordre.
Dans le cas de la température de ma salle, je pense pas que beaucoup chercherons à utiliser une méthode prévisionniste.
Alors, pourquoi le faire pour résoudre des problèmes informatiques via des spécifications aussi rigoureuses où tellement de paramètres nous échappe?

[Luckyluke34]

Bah non. On prend juste un type qui a une démarche structurée et qui ne se laisse pas embobiner ni par les utilisateurs, ni par ses supérieurs .

Faux !! Justement, le développement est une science exacte. La démarche existe. On n'est pas en biologie !! Et les méthodes Agiles nous feraient croire qu'on ne serait pas dans une science exacte !!

1/ Quand je dis que ce n'est pas une science exacte, je ne parle pas du développement mais de la rédaction de specs et de la conduite de projets. Si ça l'était, on aurait des projets toujours livrés à l'heure sans dépassement de budget et qui satisfont pleinement les utilisateurs de la même manière qu'on a des avions qui volent à tous les coups grâce à la science. Or, ce n'est pas le cas.

2/ Même sur le développement, on a un désaccord fondamental. Tu penses que le développement et la science informatique (computer science) sont une seule et même chose. Moi, je pense que l'activité professionnelle de développement d'applications est autant faite de matière humaine que de science. On se base sur la science des ordinateurs mais c'est appliqué à des domaines à composante humaine essentielle puisqu'il s'agit très souvent de rendre la vie des gens meilleure et plus productive dans les entreprises.

C'est là qu'est le désaccord fondamental. Dans ta logique, c'est normal d'avoir un plan entièrement conçu à l'avance puisqu'on a affaire à une réalité idéale, entièrement logique et constante. Dans mon mode de pensée, le domaine métier est vivant, les experts business changent d'avis, oublient des pans entiers de fonctionnalités, se trompent sur leurs hypothèses, les acteurs du projet se comprennent mal, les applications produites ne passent parfois pas l'épreuve du terrain, le contexte métier change parfois en cours de route, etc. et c'est normal puisque nous sommes tous humains.

Tu utilisais quel modeleur ?

Dans les équipes où j'ai constaté la lourdeur de la démarche, ça devait être dans Enterprise Architect. A l'heure actuelle, plus d'outil particulier. On modélise avec ce qui nous tombe sous la main puisque les modèles n'ont pas vocation à rester.

Attention, je ne critique pas UML en tant que tel mais le mythe du plan ultime gravé dans le marbre en début de projet. Si tu as trouvé une façon de modéliser l'intégralité de ton système en UML d'une manière qui ne freine pas les modifications de design et d'architecture en cours de route, parfait, rien à redire.

[CaféFort]

Ben oui. Justement. Les gens sérieux partent du principe que c'est difficille, et qu'il y aura sans doute des erreurs. Si l'entraineur avait une confiance totale dans son milieu de terrain pour garder la balle, il n'aurait besoin ni de défenseurs, ni de gardien de but. Pourtant, les meilleures équipes cherchent aussi des défenseurs et des gardiens de but. Parcequ'ils savent que même le meilleur milieu de terrain au monde va laisser passer des trucs.

On est dans le monde réel. Dans le monde réel, les gens font des erreurs. Et les gens sérieux le prennent en compte.

Et c'est qui l'adversaire ?

Documenter que le calcul de TX-TAXE-ASSURANCE se fait dans la procedure CALCUL-TX-TAXE-ASSURANCE ne me parait pas d'une priorité absolue..... Par contre, dire dans quel fichier source on peut trouver ce calcul, oui, c'est fondamental. Ne serait-ce que parceque ça dissuade de refaire le calcul ailleurs.....

Totalement d'accord ! La "documentation" UML apporte cela de manière naturelle.

Ah, ma signature? Oui, je navigue signatures désactivées, alors j'ai tendance à l'oublier. Ce qu'il dit sur l'UML, je n'en ai rien à péter. Ce qui m'intéresse chez lui, c'est son approche de l'humain. L'humain est une composante fondamentale du projet, et qui est souvent oubliée.

Sauf qu'il écrit des énormités. Mais c'est exact qu'il y a des bonnes choses.

Non, ça n'existe pas. en tous cas, pas tout le temps. Les êtres humains ont des modes d'echec(et c'est là que je trouve Cockburn fondamental, les détails de sa méthodologie à lui je m'en fous), et il faut les gérer. Et on les gère mieux si on ne s'amuse pas à trop détailler. Le juste niveau de détail est celui qui permet aux humains du projet d'être le plus efficace.

C'est sûr que moins on détaille, moins on risque de se tromper.

Exiger la perfection, c'est juste inhumain, dans le sens ou on attend d'un être humain des qualités non humaines. Même Lionel Messi rate des penalties. Et on a rarement un Lionel Messi de la spec dans son équipe. C'est là que l'idée de la spec absolue est ridicule : ça demande au spécificateur d'être sans erreurs.

Pourtant on finit bien par y arriver, d'une manière ou d'une autre à ces specs parfaites. C'est donc humain.

C'est la vraie force des démarches agiles(quand elles ne sont pas cowboy) : elles partent de la réalité pour s'améliorer.
(...)
Pas parceque je suis parfait. Mais parceque des gens comme Alistair Cockburn m'ont enseigné à gérer mes propres faiblesses. A systématiquement contrôler mes sorties. J'ai passé 6 semaines à comparer mes données avec les vraies, et à corriger mes erreurs. Si il avait fallu tout documenter, il aurait fallu 60 semaines...et ça aurait été bourré d'erreurs. Que ça soit moi ou le meilleur spécificateur du monde.

De toutes façon, on est d'accord que l'itératif est bien une nécessité. C'est le dosage qui pose problème et le coût des changements tardifs (un peu comme la démarche "agile").
Pour la doc, UML l'apporte en 1 click. C'est dommage de s'en priver.

[CaféFort]

En fait, l'informatique est plutôt du domaine du système complexe voir qui s'approche de la théorie du chaos
(...)
Solution adaptative.
(...)
Alors, pourquoi le faire pour résoudre des problèmes informatiques via des spécifications aussi rigoureuses où tellement de paramètres nous échappe?

Bah non. La demande (qui n'est pas encore écrite) elle est bien stable elle ! Elle n'a rien de chaotique.
On est d'accord que les itérations sont nécessaires. C'est la quantité d'itérations et leur étendue (de la spec jusqu'au code), le manque de doc technique, la dépendance par rapport aux développeurs, ... qui posent problèmes.

[CaféFort]

1/ Quand je dis que ce n'est pas une science exacte, je ne parle pas du développement mais de la rédaction de specs et de la conduite de projets. Si ça l'était, on aurait des projets toujours livrés à l'heure sans dépassement de budget et qui satisfont pleinement les utilisateurs de la même manière qu'on a des avions qui volent à tous les coups grâce à la science. Or, ce n'est pas le cas.

Aie ! Si ça l'était, on aurait des projets toujours livrés à l'heure sans dépassement de budget

Et si j'ai mon parapluie, c'est qu'il pleut ? Erreur de logique (modus ponens) !!

2/ Même sur le développement, on a un désaccord fondamental. Tu penses que le développement et la science informatique (computer science) sont une seule et même chose. Moi, je pense que l'activité professionnelle de développement d'applications est autant faite de matière humaine que de science. On se base sur la science des ordinateurs mais c'est appliqué à des domaines à composante humaine essentielle puisqu'il s'agit très souvent de rendre la vie des gens meilleure et plus productive dans les entreprises.

C'est là qu'est le désaccord fondamental. Dans ta logique, c'est normal d'avoir un plan entièrement conçu à l'avance puisqu'on a affaire à une réalité idéale, entièrement logique et constante. Dans mon mode de pensée, le domaine métier est vivant, les experts business changent d'avis, oublient des pans entiers de fonctionnalités, se trompent sur leurs hypothèses, les acteurs du projet se comprennent mal, les applications produites ne passent parfois pas l'épreuve du terrain, le contexte métier change parfois en cours de route, etc. et c'est normal puisque nous sommes tous humains.

Attention, le "Tu penses ..." n'est que le fruit de ton interprétation.
Je n'ai jamais évoqué une volonté que tout soit totalement défini à l'avance. Hé ho !!! C'est les méthodes agiles qui partent du précepte que (surtout) rien ne soit totalement défini à l'avance !!! C'est agile d'imposer cette idée ?

Si tu as trouvé une façon de modéliser l'intégralité de ton système en UML d'une manière qui ne freine pas les modifications de design et d'architecture en cours de route, parfait, rien à redire.

Ha bon ! parce que tu aurais qque chose à redire sinon ?

[el_slapper]

Et c'est qui l'adversaire ?

Le contexte

Totalement d'accord ! La "documentation" UML apporte cela de manière naturelle.

Mouarf. Jusque'au jour ou il faut changer un truc en catastrophe, et que dans la précipitation, on oublie de mettre à jour la doc.

C'est sûr que moins on détaille, moins on risque de se tromper.

Non, ça aussi ça a sa limite. Si on me dit, "fais moi un programme", je suis mal avançé. Si on me dit "fais pareil que l'existant, avec juste le format de sortie qui change", ou alors "corrige l'existant pour gérer un code contrat sur 9 caractères au lieu de 7", c'est quelques mots pour des mois de boulots. Mais c'est suffisant, dans ce cas précis, pour délimiter le périmètre exact des choses à faire. Parfois, il faut plus(surtout quand on part d'une feuille blanche).

Pourtant on finit bien par y arriver, d'une manière ou d'une autre à ces specs parfaites. C'est donc humain.

Non. Une spec parfaite, ça n'existe pas. Le temps de comprendre complètement le besoin, le besoin a changé.

De toutes façon, on est d'accord que l'itératif est bien une nécessité. C'est le dosage qui pose problème et le coût des changements tardifs (un peu comme la démarche "agile").

Non. La démarche agile part du constat que la demande peut changer tardivement. Partant de ce constat, elle met en place des méthodologies qui acceptent l'évolution.

Pour la doc, UML l'apporte en 1 click. C'est dommage de s'en priver.

Et après 36 ans de maintenances, bien sur, chacun des plusieurs centaines d'intervenants qui ont fait de la maintenance sur le projet ont tous, sans erreur, fait coller l'UML avec la moindre de leurs modifs.

Non, mais tu as travaillé sur autre chose que des pages blanches? Parceque tout ça, ça me parait bien naif et théorique.

80% du boulot, c'est de la maintenance, et souvent à chaud. Quand tu as l'inspecteur des impôts qui fait le pied de grue pour attendre la version corrigée de ta trésorerie(vécu), ou le PDG d'une grande banque Française qui fait le pied de grue derrière toi en attendant que tu aie déplombé le bug qui a bloqué ses 10 000 postes agents de France métropolitaine(vécu par un voisin de bureau), tu as autre chose à penser que ta doc exhaustive. Tu est un professionnel, et tu fais vite et bien. Et seulement l'indispensable. Tu ne passes pas deux plombes à te poser la question de savoir quelle est la phrase la plus précise pour avoir une spec parfaite. Tu fais ta modif, tu la fais propre, tu testes à minima, et tu livres.

Dans ce contexte, il est illusoire de croire qu'une documentation lourdingue va survivre très longtemps. Un truc comme JavaDoc, à la rigueur, directement importé du code, peut apporter des choses(avec des limites). Le code, c'est la vérité. La spec, ça devient assez vite obsolète.

Bah non. La demande (qui n'est pas encore écrite) elle est bien stable elle ! Elle n'a rien de chaotique.

Bien stable? Mais le contexte, lui, ne l'est pas! suivant qu'on est en hiver ou en été, qu'on a plus ou moins de monde dans la salle, le contexte change. Et pas de manière prévisible. Donc, autant partir sur de l'adaptatif. Et on sera toujours à 22°C.