Discussion :

[Logan Mauzaize]

Toujours des liens intéressant mais en anglais, du coup au revoir la lecture en diagonale ... Mais j’essaierai de prendre un peu le temps de lire cette fois-ci.

Néanmoins concernant ton exemple, il est triviale et relativement propre au départ. Même si pas optimale à lire.

J'ai déjà refait un programme COBOL codé dans les années 60 avec un odieux mélange de GOTO et de PERFORM. Impossible de dérouler le programme à la main. Alors qu'il s'agissait d'un bête appareillage à 4 entrées. Le refaire était une nécessité pour son avenir. Pour ajouter une simple alimentation dans une des sorties dans certains cas, c'était un vrai calvaire. Plus de 2 jours d'analyse sans arriver à une solution qui fonctionne dans tous les cas.
Après l'avoir refait avec une structure propre pour un appareillage (1 paragraphe pour chaque entrée à faire avancer, 2-3 paragraphe de contrôles génériques, 2-3 paragrahe de traitement spécifique, 1 paragraphe d'écriture pour chaque sortie), la modification a été effectuée et testée en moins de 2H.

Bien sûr j'avais bien blinder ma vérification avant de faire ma refonte. Idem en gestion de conf, on a d'abord sauvegarder la version refondue, puis celle corrigée.

Et encore dans nos deux cas, on parle de problème isolé. Quand on commence à toucher à des applications bien plus enchevêtrées qu'un unique batch COBOL au sein d'une grande chaîne de calcul, la refonte est peut-être nécessaire voir vitale.

Comme dit dans le bouqin :

La seule manière de respecter le planning, ou d'aller vite, est de garder en permanence le code aussi propre que possible.

[el_slapper]

La seule manière de respecter le planning, ou d'aller vite, est de garder en permanence le code aussi propre que possible

I am el_slapper & I approve this message.

Je ne connaissais pas, mais c'est mon expérience aussi. Faire "propre", c'est très vite rentable. Même un programme "jetable"; désormais, je prends le temps de le faire propre. Le temps de le mettre au point pous sa seule et unique utilisation, ça a déjà été rentabilisé.

[souviron34]

La seule manière de respecter le planning, ou d'aller vite, est de garder en permanence le code aussi propre que possible.

Bof..

Je suis d'accord avec la seconde partie ("d'aller vite")

Par contre, qu'est-ce que ça veut dire "La seule manière de respecter le planning" ???

Qu'est-ce qu'un planning ? Comment a-t-il été établi ? par qui ? qu'a-t-il pris ou pas pris en compte ? sur quelles personnes s'est-il basé ??


De plus, ce n'est pas "la seule manière". ça n'est que "une condition nécessaire".. Mais il y en a plein d'autres, des conditions...

Le fond, c'est que la seule manière de respecter un planning c'est que ce planning ait été correctement établi... Rien à voir avec le reste.. : gestion des hommes, identification des points dificiles, gestion des finances, prévision, etc etc...

[el_slapper]

(.../...)Le fond, c'est que la seule manière de respecter un planning c'est que ce planning ait été correctement établi... Rien à voir avec le reste.. : gestion des hommes, identification des points dificiles, gestion des finances, prévision, etc etc...

C'est moi ou tu chipotes?

[souviron34]

C'est moi ou tu chipotes?

non, je ne chipote pas du tout .. C'est du français, de la signification des mots, et de la logique (philosophique et mathématique)..

La manière de dire de la citation est que il suffit d'avoir du code propre pour respecter un planning..

Ce n'est en rien une condition suffisante, c'est tout... Avoir un code propre ne garantit en rien qu'on respectera un planning...

C'est une condition nécessaire, mais pas suffisante (tes souvenirs de maths et de logique devraient te dire que cette distinction n'est pas du chipotage...)

[Logan Mauzaize]

Je le vois pas de la même manière.

Quand on fait un macro chiffrage (plusieurs modules sans aller analysé chacun en profondeur), on estime assez bien les charges de base : analyse détaillée, développement, test unitaire, intégration etc. On rajoute un peu de marge car il y a toujours son lot d'imprévu. Finalement on empile tout les chiffrages, on saupoudre de priorité/dépendance. On fait chauffer l'affectations des ressources. Et on démoule un joli Gantt avec les différents jalons : le planning.

Seulement voilà, quid des gros problèmes de restructuration du code mal conçu, du déchiffrage de code illisible et de la divination du synoptic de certains morceaux de code ? Après tu te retrouves, comme dans mon cas, à passer deux jours d'analyse (à mettre à la poubelle) pour une tâche de deux heures.

[souviron34]

Seulement voilà, quid des gros problèmes de restructuration du code mal conçu, du déchiffrage de code illisible et de la divination du synoptic de certains morceaux de code ? .

ça ça aurait dû être pris en compte dan le planning

Contrairement à ce qui semble être répandu, établir un vrai planning sérieux est complexe et demande du temps, de savoir à quoi on a affaire, et d'avoir regardé (ou fait regarder), si on part de code existant, pour avoir une vraie impression et estimation...

Faire un "planning" en dehors de ça c'est de la construction intellectuelle pure... Et c'est forcément en dehors de la réalité pour la plupart des projets..

Normalement, le chiffrage et planning, si il est fait sérieusement, n'est pas fait par une seule personne dans son coin : cette personne délègue puis rassemble les évlauations/planning des différents spécilaistes sur leur partie..

Surtout si le projet est gros et comporte plusieurs modules...

[Logan Mauzaize]

[IRONIE=ON]

ça ça aurait dû être pris en compte dan le planning

Si tout était parfait on serait pas la en train de parler mais à pointer au chomage ^^

Contrairement à ce qui semble être répandu, établir un vrai planning sérieux est complexe et demande du temps, de savoir à quoi on a affaire, et d'avoir regardé (ou fait regarder), si on part de code existant, pour avoir une vraie impression et estimation...

Parles-t-on encore d' "estimation" ?

Faire un "planning" en dehors de ça c'est de la construction intellectuelle pure... Et c'est forcément en dehors de la réalité pour la plupart des projets..

Pour certains projets, savoir qui va travailler dessus est déjà un miracle !

Normalement, le chiffrage et planning, si il est fait sérieusement, n'est pas fait par une seule personne dans son coin : cette personne délègue puis rassemble les évlauations/planning des différents spécilaistes sur leur partie..

Quand tu parles de spécialistes, tu parles du jeune embauché qui vient de débarquer ou le responsable technique fraîchement extirpé de son dernier projet mais qui passe tout son temps en support sur ce dernier projet ?
[/IRONIE=OFF]

Plus sérieusement, même si les réponses représentent sûrement la grande réalité des projets, sur une base de code de plusieurs (dizaines ?) milliers lignes (utiles), tu peux pas demander même au plus grand spécialiste de connaître l'état de toutes les fonctions, surtout celle qui n'ont pas été touché depuis plus de 5 ans (ou 30-40 ans dans mon exemple).

[souviron34]

Parles-t-on encore d' "estimation" ?

Absolument , oui...

Plus sérieusement, même si les réponses représentent sûrement la grande réalité des projets, sur une base de code de plusieurs (dizaines ?) milliers lignes (utiles), tu peux pas demander même au plus grand spécialiste de connaître l'état de toutes les fonctions, surtout celle qui n'ont pas été touché depuis plus de 5 ans (ou 30-40 ans dans mon exemple).

Euh bien sûr que si... Les projets sur lesquels j'ai travaillé, de 700000 à 5 millions de lignes, normalement toute personne censée ayant travaillé depuis 1 an dessus a une bonne idée du tout...

En particulier si c'est de grandes parties, et qu'il y a un "responsable" par équipe..


Justement, c'est là où ça me fait rigoler les "formations CP" et autres..

Outre les qualités nécessaires à être chef, connaitre le code, et sélectionner des gens qui le connaisse suffisamment bien fait partie du boulot.. Et, dans ce cas, tu délégues à ceux qui connaissent l'estimation.. et tu rassembles et pondère ensuite..


Le gros projet (+700 000 lignes) dont je me suis occupé quasi-seul, je peux en 5 minutes te dire à peu près où sont telle ou telle fonction, même si ça fait presque 10 ans que je n'y ai pas touché. Le dernier gros projet, de 3 millions de lignes, en 8 mois je savais à peu près où était situé à peu près tout, et quelles parties étaient difficiles... Bon, c'était mon rôle, OK.. Mais c'est justement le boulot d'un CP de s'entourer des gens compétents Et d'avoir de la mémoire.. tout comme ses responsables d'équipes.

Une grande partie du boulot consiste à mémoriser, et justement savoir et connaître un max ce sur quoi on bosse..

Enfin, c'est comme ça que je conçois le boulot...

[Logan Mauzaize]

Euh bien sûr que si... Les projets sur lesquels j'ai travaillé, de 700000 à 5 millions de lignes, normalement toute personne censée ayant travaillé depuis 1 an dessus a une bonne idée du tout...

Chaque ligne de code de chaque fonction ? En moins d'un an ? Y compris les choses qui n'ont pas été touchées depuis plusieurs années ?

Outre les qualités nécessaires à être chef, connaitre le code, et sélectionner des gens qui le connaisse suffisamment bien fait partie du boulot.. Et, dans ce cas, tu délégues à ceux qui connaissent l'estimation.. et tu rassembles et pondère ensuite..

Aucun soucis là dessus, on est entièrement d'accord. Sauf que bon des fois, ces personnes sont pas mal occupées.

Le gros projet (+700 000 lignes) dont je me suis occupé quasi-seul, je peux en 5 minutes te dire à peu près où sont telle ou telle fonction, même si ça fait presque 10 ans que je n'y ai pas touché. Le dernier gros projet, de 3 millions de lignes, en 8 mois je savais à peu près où était situé à peu près tout, et quelles parties étaient difficiles... Bon, c'était mon rôle, OK.. Mais c'est justement le boulot d'un CP de s'entourer des gens compétents Et d'avoir de la mémoire.. tout comme ses responsables d'équipes.

Savoir où sont les choses et leurs éventuelles complexités n'est pas le problème. C'est surtout l'état, un peu comme tu sais ou se trouve le moteur dans une voiture et à quoi il sert. Par contre tu sais que vaguement à quoi ca ressemble à l'intérieur. Surtout après le passage de plusieurs litres d'huile et d'essence.

Tu soulignes également un point important :

même si ça fait presque 10 ans que je n'y ai pas touché

Aujourd'hui il est très rare d'avoir la même personne disponible 10 ans après. J'en connais que 2 sur plus de 200 personnes.

Enfin, c'est comme ça que je conçois le boulot...

Pour ma part c'est comme ça que je l'idéalise. T'aurais pas un petit boulot pour moi sur Toulouse ?

[souviron34]

Chaque ligne de code de chaque fonction ? En moins d'un an ? Y compris les choses qui n'ont pas été touchées depuis plusieurs années ?
..
Savoir où sont les choses et leurs éventuelles complexités n'est pas le problème. C'est surtout l'état, un peu comme tu sais ou se trouve le moteur dans une voiture et à quoi il sert. Par contre tu sais que vaguement à quoi ca ressemble à l'intérieur. Surtout après le passage de plusieurs litres d'huile et d'essence.

Pas chaque ligne de code, non.. Simplement pratiquement de mémoire d'une part l'endroit où ça se trouve, l'état du code (propre./ pas propre. - clair / peu clair - complexe / simple. / très complexe - final / à améliorer / à optimiser)

Ce qui est correct et suffisant pour faire une estimation, ce qui était ce dont on parlait..

Aucun soucis là dessus, on est entièrement d'accord. Sauf que bon des fois, ces personnes sont pas mal occupées.

Too bad.... Faut alors pas s'attendre à avoir un planning correct...

Sauf que si tu es le chef, TU décides de rendre la personne dispo pour ça....
Or le planning est de la responsabilité du chef.. Donc....

La propreté du code ne changera rien au respect ou non du planning si il n' a pas été établi avec sérieux..

Tu soulignes également un point important :
Aujourd'hui il est très rare d'avoir la même personne disponible 10 ans après. J'en connais que 2 sur plus de 200 personnes.

Sans doute parce que nous n'avons pas travaillé dans les mêmes environnements.. Je n'ai que très peu bossé en SSII, mais plutôt chz des "producteurs" de soft, industriels ou purement soft.. D'où notre discussion sur "éditeur" ou pas..

Mais de toutes façons, ça ne change pas... A part si tu es embauché "programmeur de base" (et encore, un peu de curiosité devrait t'amener à fureter) , toute personne ayant un cetain niveau de responsabilité devrait, au bout d'un an, à peu près avoir fait le tour de ce sur quoi il bosse...

Pour ma part c'est comme ça que je l'idéalise. T'aurais pas un petit boulot pour moi sur Toulouse ?

Ce serait très certainement pas en France, trop compliqué...

[Logan Mauzaize]

Too bad.... Faut alors pas s'attendre à avoir un planning correct...
Sauf que si tu es le chef, TU décides de rendre la personne dispo pour ça....
Or le planning est de la responsabilité du chef.. Donc....
La propreté du code ne changera rien au respect ou non du planning si il n' a pas été établi avec sérieux..

Faut aussi se battre avec les autres chefs Pour avoir autant de précisions, il faut également avoir tout son temps pour les analyses. Ce qui n'est pas toujours le cas.

Mais de toutes façons, ça ne change pas... A part si tu es embauché "programmeur de base" (et encore, un peu de curiosité devrait t'amener à fureter) , toute personne ayant un cetain niveau de responsabilité devrait, au bout d'un an, à peu près avoir fait le tour de ce sur quoi il bosse...

Si en Java ca m'arrive de fureter dans certaines classes que je suis pas censé regarder pour comprendre certains comportements et débugger, sur une chaîne de calcul ca m'arrive rarement d'ouvrir chacun des fichiers en me disant, au tiens le 21e programme de tel branche de la chaîne me fait bien envie aujourd'hui, rien que le nom P87368 me donne plus envie que son précédecesseur le P87367 ...
Et j'aurais de sérieux doutes sur la personne qui passerait son temps à faire ça.

[el_slapper]

(.../...)
Si en Java ca m'arrive de fureter dans certaines classes que je suis pas censé regarder pour comprendre certains comportements et débugger, sur une chaîne de calcul ca m'arrive rarement d'ouvrir chacun des fichiers en me disant, au tiens le 21e programme de tel branche de la chaîne me fait bien envie aujourd'hui, rien que le nom P87368 me donne plus envie que son précédecesseur le P87367 ...
Et j'aurais de sérieux doutes sur la personne qui passerait son temps à faire ça.

+1

J'ai quelques millions de lignes dans mon périmètre depuis 3 ans, je n'en connais pas la moitié(c'est-à-dire que je ne sais ni à quoi ça sert ni ou c'est). 5 millions de lignes en un an, ça me parait de la science fiction. J'en ai maitrisé parfaitement 120 000 en un peu plus d'un an, il y a longtemps.

Mais bon, ça dépend aussi des priorités. La chaine de rentabilité que personne ne comprend et qui ne plante jamais, y'a des gens qui sont là depuis 8 ans, ils ne connaissent même pas le nom des livrables. Et, quand elle a planté le mois dernier, nous avons pleuré. Tous.

[souviron34]

Je me permet de réitérer que c'est sans doute parce que vous bossez soit dans SSII soit dans des "services infos" de grosses grosses boites..

Cette situation est relativement inconnue chez ce que vous appelez des "éditeurs", c'est à dire des boites faisant leur propre soft, que ce soit en tant que soft ou en tant qu'élément d'un plus gros tout..

Bien entendu, un "débutant" n'aura ni le temps ni l'esprit ni l'intérêt pour le faire. Par contre, quelqu'un d'assez expérimenté et/ou avec des reponsabilités oui...

Et c'est d'autant plus valable que les équipes sont "petites" (< 15-20 personnes)... quelle que soit la taille du projet... (y compris > 3 millions de lignes)

[SpiceGuid]

Il y aura toujours du code.

Pas plus tard qu'hier je viens d'écrire du code en C avec de l'asm (si vous avez une solution plus portable pour lire le TSC dites-le moi).

EDIT: Ok, désolé, je débute en C, on en apprend un peu tous les jours.

[rimram31]

...Concernant l' "agilité" qui je suis convaincu que c'est un remède aux méthodes que je cotoie actuellement...

Méfie toi l'agilité peut être un mirage aux alouettes ... elle apporte son lot de défauts a commencer par celui de supprimer la pression d'une livraison sur l'équipe de développement et d'entendre un sempiternel "au prochain run".

[souviron34]

Méfie toi l'agilité peut être un mirage aux alouettes ... elle apporte son lot de défauts a commencer par celui de supprimer la pression d'une livraison sur l'équipe de développement et d'entendre un sempiternel "au prochain run".

mouais...

Disons que c'est très certainement l'agilité telle qu'elle est mise en pratique depuis que c'est à la mode... avec des soi-disants "méthodologies"... des rôles attribués par personne quel que soit le projet (ça c'est très français, le "statut"), et enfin des grosses SSII ou des grosses boites qui recrutent des quasi-débutants en les plaçant à des responabilités qu'ils ne devraient pas, pour ce genre de chose..

Comme j'ai déjà eu l'occasion de le dire, tous ces trucs sont "de la foutiase"..

Il faut savoir comment faire proprement un cycle en V, et se baser sur les gens de l'équipe (des bons évidemment) afin de "shunter" les passages...

C'est évidemment pas ce qui se fait depuis que c'est à la mode... Et c'est pourtant ce qui était préconisé dans le Manifeste (qui était écrit par des gens très expérimentés, qui n'en déduisaient en rien une méthodologie)..

On ne peut "contourrner" ou "se passer" des règles que quand on maitrise bien et le code et les règles, ainsi que leurs conséquences..


Mais entre les problèmes de diplômés en masse, les problèmes de grosses boites, et les problèmes de non-connaissance (ou maitrise) des cycles traditionnels, on ne peut que aller dans le mur... Sans doute plus rapidement


(c'est pareil que un pilote d'avion : le faire atterir sans pilote auto, ou lui faire gérer des situatons d'urgence, et donner des ordes à son copilote, faut qu'il soit chevronné et qu'il n'ait pas à se référer à son manuel... En gros, qu'il sache très bien voler normalement... Là il peut se passer des "sécurités" et autres truc mis pour les moins expérimentés...)

[rimram31]

mouais...

Ma remarque valait dans le sens de se méfier du "l'herbe est plus verte ailleurs" en réponse a Nemek Pour ce qui est phénomènes de mode, malheureusement les années passent et on y a toujours droit ... comme aux SSII qui nous présente leurs fameux "experts"

Les méthodes, les technologies passent, on réécrit n fois une application et au final on a les mêmes problèmes a résoudre, on peut comprendre que nos "décideurs" soient parfois sceptiques a nos arguments pour justifier un budget

On ne peut "contourrner" ou "se passer" des règles que quand on maitrise bien et le code et les règles, ainsi que leurs conséquences..

Gros +1

[el_slapper]

(.../...)
Mais entre les problèmes de diplômés en masse,

le problème n'est pas le nombre. Le problème est la qualité. Je suis sur que si on savait filtrer, dès l'entrée des écoles, des gens sur les qualités spécifiques de l'informaticien(qui n'ont rien à voir avec celles de l'ingénieur), on pourrait former autant de gens, et nettement meilleurs.

les problèmes de grosses boites,

Qui se résument à des problèmes politiques. Ici, on a eu un migration massive, qui a fait semblant de bien marcher, qui a été en fait catastrophique parceque le coordinateur a salopé le boulot, on a passé deux mois à ramasser les morceaux, et le coordinateur qui a réussi à faire croire le jour J que tout allait bien a été promu.

Et je ne sais pas comment empêcher ça.

et les problèmes de non-connaissance (ou maitrise) des cycles traditionnels,
(.../...)

Parcequ'ils ont été maitrisés un jour???

Pour moi, la démarche(et pas la méthode) agile a pour principal avantage d'accepter le fait qu'on ne maitrise pas tout. On ne maitrise pas la méthode(on passe son temps à l'améliorer), on ne maitrise pas le métier(on découvre à chaque itération de nouvelles subtilités), et on ne maitrise pas la technique(mais quand on fait fausse route, on s'en rend compte plus vite). Malgré ce manque évident de maitrise, on peut quand même fournir du logiciel utile et pas trop cher.

[souviron34]

le problème n'est pas le nombre. Le problème est la qualité.

ça va ensemble

C'est la même chose que le tourisme, la culture, la chanson, le BAC, la malbouffe, ou n'importe quoi..

Si on augmente le nombre, on diminue la qualité. ..

Forcément...

Et des deux côtés : la qualité des "encadrants" et la qualité des "encadrés"..

Qui se résument à des problèmes politiques
..
Et je ne sais pas comment empêcher ça.

Non, je ne suis pas d'accord.. ça se résume à des problèmes d'argent...

Entre les "aides à l'embauche", les "aides aux stages", et la notion de "chaine de production", tu as tous les ingrédients..

Dans une grosse boite, un employé est un pion - quel que soit son niveau -

Puisque c'est un pion, d'une part on doit gagner de l'argent dessus, et d'autre part on doit raisonner comme si c'était quelqu'un d'autre..

Donc forcément, ça va dans le sens contraire de l'esprit de l'agilité.... Même si on se prétend "agile"...


Tu ne peux pas empêcher, mais tu peux lutter contre : d'une part en ne courbant pas l'échine et en ne ratant pas une occasion de mettre le nez dans leur c.c. aux chefs, et d'autre part, si cela ne marche pas, en allant choisir une meilleure boite (ou, mais là il faut être vraiment motivé, et éventuellement avoir les moyens, en faisant le même projet en // en suivant ce que tu crois)

Parcequ'ils ont été maitrisés un jour???

Pour moi, la démarche(et pas la méthode) agile a pour principal avantage d'accepter le fait qu'on ne maitrise pas tout. On ne maitrise pas la méthode(on passe son temps à l'améliorer), on ne maitrise pas le métier(on découvre à chaque itération de nouvelles subtilités), et on ne maitrise pas la technique(mais quand on fait fausse route, on s'en rend compte plus vite). Malgré ce manque évident de maitrise, on peut quand même fournir du logiciel utile et pas trop cher.

Je suis d'accord, mais cependant les exigences pour être architecte ou CP dans le cadre d'un cycle en V demand(ai)ent une rigueur dans les formulations / délimitation de périmètre / hiérarchie de la pensée / découpage des éléments ...

La mode "agile" a remplacé ça par des termes comme "sprint" et autres "Scrum Master", qui du coup ont le privilège d'avoir des formations spécialisées, mais en dehors de la base de l'architecture de la pensée et de l'analyse..

Comme "cycle en V"" ou "Waterfall" c'est devenu ringard, on a "oublié" la base..

C'est comme si en maths (ce qu'on voit d'ailleurs malheureusement) on ne formait qu'à Matlab sans former au maths.. Résultat : des gens ne sachant ni ce qu'ils font ni ce qu'ils manipulent ni comment c'est manipulé...

Ou comme si il suffisait de savoir utiliser un traitement de texte pour être écrivain...