Discussion :

[Logan Mauzaize]

Si, ça peut suffir à ce que tu travailles en bonne intelligence avec cette personne et qu'il ne fasse plus redescendre cette pression négative sur toi.

Aucun discours n'effacera son budget et délai limités dans lesquels le client voudra que tu rentres tout ce que l'on lui a demandé de mettre.

Tout de suite les gros mots .... "process" .
Non c'est au feeling en fonction des gens.

Faut bien que je les places

Détrompes toi, depuis que je travaille exclusivement dans le décisionnel je côtoie par moment des gens haut placés. Il s'avère que ce genre de personne est beaucoup plus facile à gérer que l'armée de "p'tits chefs hargneux" qui grouillent dans les bas fonds des sociétés

J'avoue que ces derniers sont les pires Cependant tu as quelques beaux spécimens entre ceux-ci et les DSIs !
De toutes façons, cela suppose que la communication soit bidirectionnelle et/ou directe.
J'ai déjà vu des gens se prendre des tirs par "comité de pilotage" interposé. Tu fais un truc (comme envoyer un mail), ça remonte une chaîne invisible. Deux mois (et n "comité") plus tard, t'as ton supérieur l'air renfrogné/agité/etc. qui vient te dire avec (plus ou moins de) tact que tu as fais une boulette et que le n+18 du client final n'est pas content.

Malheureusement, je ne peux parler que de cas personnels et donc limités.
Les seules personnes que j'ai croisé qui avait besoin de beaucoup de docs s'avéraient être des personnes soit :
- peu compétentes. Et ce n'est pas la doc qui arrangeait les choses. Du coup j'en reviens sur mon fameux choix d'équipe
- pour se rassurer. Donc en fait la doc ne servait pas à améliorer leur productivité.

Je ne parle pas de beaucoup de documentation (certes ce n'est pas exclu) mais d'un minimum de documentation.
Sinon c'est que tu supposes que tes produits/applications sont construits uniquement par assemblage de composants standards et de design patterns. Dans ce cas :

• C'est uniquement de l'intégration.
• Je vous retournes, à Slapper et toi, sur vos remarques comme quoi on allait finir comme des robots

De manière plus globale par rapport à ton message, tu fais ressortir que tous ces process servent à combler les "faiblesses humaines".

Tout à fait, c'est pourquoi j'insiste surtout sur le mot "assurance".

Ce que je dis : je n'aime pas les process lourd, je trouve que c'est une perte de temps et je préfère essayer de travailler en toute intelligence avec les personnes qui m'entourent. J'y suis parvenu jusqu'à présent.

Si tu as de bonnes méthodes de travail et que tu appliques généralement les mêmes, quelle différence cela fait de les rationaliser ?

Alors oui, je suis d'accord, ce n'est pas toujours possible et dans certains cas ta méthode est la seule possible pour que le projet survive mais dans ce cas là on est dans un environnement de travail dans lequel je refuserai de travailler.

Tu es donc de ces personnes qui rejettent les débutants ? Ne laisses jamais leur chance aux gens ?
Idem pour les environnements suivants :

• Entente "cordiale" avec le client.
• Gros projet/Grande équipe

Je dois avoir eu beaucoup de "chances" car je ne suis que rarement tombé dans des cas extrêmes de process lourd où j'ai du me démener pour changer les choses.

L'assurance qualité ne produit pas que des process lourd. Cela produit rarement des process transparents, mais ils devraient rester souples.
Cette souplesse reste modéré par la criticité. Cependant tout le monde devrait admettre que cela dépasse sa propre responsabilité (par humilité, conscience professionnelle, etc.)

[javamine]

Aucun discours n'effacera son budget et délai limités dans lesquels le client voudra que tu rentres tout ce que l'on lui a demandé de mettre.

Il faut savoir dire non, ça s'apprend. Je ne sais pas quoi te dire d'autres, c'est peut être mon "petit parcours" d'avant-vente en début de carrière qui m'a appris à bien gérer la relation client.

J'ai déjà vu des gens se prendre des tirs par "comité de pilotage" interposé. Tu fais un truc (comme envoyer un mail), ça remonte une chaîne invisible. Deux mois (et n "comité") plus tard, t'as ton supérieur l'air renfrogné/agité/etc. qui vient te dire avec (plus ou moins de) tact que tu as fais une boulette et que le n+18 du client final n'est pas content.

Là encore ce n'est qu'un problème de communication qui peut se régler. Il faut savoir pourquoi les personnes qui étaient au courant à l'instant T n'ont pas réagit alors que le N+XX à râler.

Je ne parle pas de beaucoup de documentation (certes ce n'est pas exclu) mais d'un minimum de documentation.

Je me répète : je n'ai rien contre un minimum de process. La seule chose que je critique c'est quand ils sont bien trop lourd ou que l'on rentre trop dans le détail.

Si tu as de bonnes méthodes de travail et que tu appliques généralement les mêmes, quelle différence cela fait de les rationaliser ?

Parce que j'insiste toujours sur les relations humaines. Et ça, ça ne se rationalise pas, nous ne sommes pas tous identiques.

Tu es donc de ces personnes qui rejettent les débutants ? Ne laisses jamais leur chance aux gens ?

Je me répète (une fois de plus...) : la majorité des gens sont très bien quand on les accompagne correctement. Un débutant, quand tu le suis correctement au lieu de lui refourguer le tas de paperasses indigeste d'un projet, progresse très vite.

Je t'ai pourtant également dit que j'avais récupéré des soit disant "boulets" sur mes projets avec qui ça s'était finalement bien passé.
De plus, je n'arrête pas de te dire que j'essaie toujours de travailler en bonne intelligence même avec des gens qui paraissent "difficile" au début. Toi, dans ces cas là, tu préfères aligner des process... et c'est moi qui ne laisse pas leur chance aux gens?

Idem pour les environnements suivants :

• Entente "cordiale" avec le client.
• Gros projet/Grande équipe

Je reviens sur mon choix des projets. Cela dit, et c'est un autre débat, beaucoup de projets avec de grosses équipes, donc lourd à gérer, pourraient se réaliser plus facilement avec une équipe réduite et par conséquent plus souple.

[el_slapper]

Il faut savoir dire non, ça s'apprend. Je ne sais pas quoi te dire d'autres, c'est peut être mon "petit parcours" d'avant-vente en début de carrière qui m'a appris à bien gérer la relation client.

C'est toujours compliqué, et nous autres techos ne sommes pas préparés à celà. Mais c'est effectivement quelquechose à travailler. Sans en abuser.

Je me répète : je n'ai rien contre un minimum de process. La seule chose que je critique c'est quand ils sont bien trop lourd ou que l'on rentre trop dans le détail.

+1. Le début du débat, c'est quand même quand on m'a dit que je ne respectais pas grand chose parceque j'avais pris une initiative hors process. Ca ne veut pas dire que globalement, le process est inutile. Juste, que le suivre sans se poser de questions, ça peut porter malheur.

Parce que j'insiste toujours sur les relations humaines. Et ça, ça ne se rationalise pas, nous ne sommes pas tous identiques.

C'est même la base des liens que j'ai posté.

Je me répète (une fois de plus...) : la majorité des gens sont très bien quand on les accompagne correctement. Un débutant, quand tu le suis correctement au lieu de lui refourguer le tas de paperasses indigeste d'un projet, progresse très vite.

Pas toujours quand même. Y'en a, ils mettent une semaine à coder un SQL de 3 lignes, et ne comprennent pas pourquoi c'est insuffisant, ni même que c'est insuffisant. Mais souvent, des "inadaptés" ont juste été lancés dans la fosse aux lions sans le répulsif qui va bien.....

Je t'ai pourtant également dit que j'avais récupéré des soit disant "boulets" sur mes projets avec qui ça s'était finalement bien passé.
De plus, je n'arrête pas de te dire que j'essaie toujours de travailler en bonne intelligence même avec des gens qui paraissent "difficile" au début. Toi, dans ces cas là, tu préfères aligner des process... et c'est moi qui ne laisse pas leur chance aux gens?

amen.

Je reviens sur mon choix des projets. Cela dit, et c'est un autre débat, beaucoup de projets avec de grosses équipes, donc lourd à gérer, pourraient se réaliser plus facilement avec une équipe réduite et par conséquent plus souple.

mon héros

Je vais paraitre prétentieux, mais il y a quelques années, j'ai brièvement travaillé comme homologateur sur un projet massif de migration. Il y avait des choix très lourds qui avaient été fait, et il fallait 12 programmeurs, 2 experts techniques, et quelques autres, pour un total de 25 personnes. Quand j'ai vu la spec que je devais homologuer, je me suis dit "en COBOL, je fais ça tout seul en trois mois"(et la source était du cobol, donc c'était techniquement possible). Aujourd'hui, je me dis que 5-6 mois auraient été plus réalistes - mais quand même. Les programmeurs se marchaient sur les pieds, et moi je me suis cassé. Le projet a coulé. Aucune initiative de ma part, aucune méthodologie non plus n'aurait pu sauver un tel monstre.

[Logan Mauzaize]

Il faut savoir dire non, ça s'apprend. Je ne sais pas quoi te dire d'autres, c'est peut être mon "petit parcours" d'avant-vente en début de carrière qui m'a appris à bien gérer la relation client.

Ce n'était qu'un exemple, je suis d'accord que sur le simple principe qu'à périmètre, délai et coût convenu, il y a toujours une négociation. Cependant c'est le genre de choses sur lesquelles tu as peu (ou pas) de levier. Et que tu le veuilles ou non, la négociation sera serrée.

Là encore ce n'est qu'un problème de communication qui peut se régler. Il faut savoir pourquoi les personnes qui étaient au courant à l'instant T n'ont pas réagit alors que le N+XX à râler.

C'est un exemple typique de cas dans lequel l'information qui ne devait pas remonter plus loin que 3 sauts de mail est pourtant arrivé dans la boîte aux lettres de la moitié de la Terre ... Donc le 3e chaînon à mal fait son boulot, cependant il y a deux intermédiaires entre lui et toi ...

Je me répète : je n'ai rien contre un minimum de process. La seule chose que je critique c'est quand ils sont bien trop lourd ou que l'on rentre trop dans le détail.

Ca rejoint ce que je disais sur le fait que l'assurance qualité n'est pas un mal en soi mais que ces applications sont en générales très douteuses d'où une grosse image négative ... Pour avoir connu un gros projets en CMMi niveau 3 et DO-178B (certifié niveau D, pas tellement critique), je peux dire que cela apporte réellement quelque chose. Et c'est un point de vue partagé par les gens qui ont participé au projet. Et pourtant on était loin de l'implémentation "idéale".

Parce que j'insiste toujours sur les relations humaines. Et ça, ça ne se rationalise pas, nous ne sommes pas tous identiques.

[IRONIE]C'est marrant parce que les cours de psychologie et gestion de ressources humaines commencent généralement par : Tout le monde est pareil, on cherche tous à satisfaire nos besoins.[/IRONIE]
Plus sérieusement, on retrouve assez souvent les mêmes problèmes ; en tout cas j'ai déjà vu des problèmes récurrents.

Sinon tout ne passe pas par les relations humaines, en particulier les méthodes de travail. La façon dont tu fais ton travail chaque jour ne requiert pas nécessairement d'échange avec les autres. Et si tu en arrives à savoir ou estimer qu'une méthode est bonne c'est que tu l'as éprouvée plusieurs fois. Tu peux donc rationaliser et en faire un "process".

Je me répète (une fois de plus...) : la majorité des gens sont très bien quand on les accompagne correctement. Un débutant, quand tu le suis correctement au lieu de lui refourguer le tas de paperasses indigeste d'un projet, progresse très vite.

Qu'il progresse, ce n'est pas un problème. Mais il fera statistiquement plus d'erreur que les autres. Donc pourquoi rechigner à mettre en place des relectures croisées ?

Je t'ai pourtant également dit que j'avais récupéré des soit disant "boulets" sur mes projets avec qui ça s'était finalement bien passé.
De plus, je n'arrête pas de te dire que j'essaie toujours de travailler en bonne intelligence même avec des gens qui paraissent "difficile" au début. Toi, dans ces cas là, tu préfères aligner des process... et c'est moi qui ne laisse pas leur chance aux gens?

J'ai pas dit que je préférai mais seulement indiqué les principes de l'assurance qualité. Autrement, je ne vois aucun process qui transformera un je-sais-tout (mais qui ne sait rien et qui en plus ne veut rien entendre) en quelqu'un d'"intégrer". Cependant, on peut combler/couvrir ses lacunes.
De manière générale, personne n'est parfait et chacun a ses travers. Certains défauts sont plus évidents que d'autres donc autant combler/couvrir toutes les petites faiblesses de chacun. Je vois ce qu'il y a de mal à vouloir "perfectionnié" le travail de chacun.

Concernant la question, oui la qualité laisse sa chance aux gens puisqu'aucun process ne peut faire leur travail à la place. La seule chose c'est qu'elle assure à chacun que les erreurs devraient être détecter au plus tôt et qu'elles ne peuvent passer le contrôle qu'en cas d'anomalies conjointes. Comme dans un avion par exemple, où la défaillance d'un seul élément n'est pas suffisante à causer un accident.

Je reviens sur mon choix des projets. Cela dit, et c'est un autre débat, beaucoup de projets avec de grosses équipes, donc lourd à gérer, pourraient se réaliser plus facilement avec une équipe réduite et par conséquent plus souple.

Ouais mais le délai serait beaucoup trop long !
Les gros projets que j'ai vu ont toujours été découpé en plus petites équipes.

+1. Le début du débat, c'est quand même quand on m'a dit que je ne respectais pas grand chose parceque j'avais pris une initiative hors process. Ca ne veut pas dire que globalement, le process est inutile. Juste, que le suivre sans se poser de questions, ça peut porter malheur.

Le fait d'avoir l'idée est une chose, le fait de s'appriorier le temps et l'argent du projet en est une autre.
Ensuite la seule chose que j'ai notée c'est qu'il faut tracer le changement quelques part, qu'il ait fait l'objet d'une discussion ou non.

Et j'ai déjà donner deux bons exemples :

1. Le cowboy qui croit bien faire et se plante. Que ce soit sur le plan fonctionnel ou technique. Si personne n'est au courant, personne ne teste et c'est le carnage en fonction de la criticité de la fonction.
2. Le début qui arrive, et s'aperçoit que les choses ne fonctionnent pas comme dans la spéc (ou description du besoin ou autre). S'il n'y a pas de traces, toutes les discutions vont se refaire et peut-être arrivée sur une conclusion contradictoire.

Et j'ose même pas pensé si on cumule les deux

C'est même la base des liens que j'ai posté.

Mea Culpa je n'ai toujours pas lu "Code as Design" ...

Ceci dit l'intro donne moyennement envie de lire la suite :

programming is fundamentally a design activity and that the only final and true representation of "the design" is the source code itself

Quoi ? Le produit est l'implémentation de sa conception ? Je sens qu'il y a beaucoup d'activité de "production" qui sont de la "conception". Le type aurait tout aussi bien pu écrire que la conception est la représentation d'un besoin ...
Je pense que c'est juste mal dit mais je n'ai pas pu m'empêcher Je lirai tout de même la suite !

Pas toujours quand même. Y'en a, ils mettent une semaine à coder un SQL de 3 lignes, et ne comprennent pas pourquoi c'est insuffisant, ni même que c'est insuffisant. Mais souvent, des "inadaptés" ont juste été lancés dans la fosse aux lions sans le répulsif qui va bien.....

Si seulement ca ne concernait que les débutants -_-'

Je vais paraitre prétentieux, mais il y a quelques années, j'ai brièvement travaillé comme homologateur sur un projet massif de migration. Il y avait des choix très lourds qui avaient été fait, et il fallait 12 programmeurs, 2 experts techniques, et quelques autres, pour un total de 25 personnes. Quand j'ai vu la spec que je devais homologuer, je me suis dit "en COBOL, je fais ça tout seul en trois mois"(et la source était du cobol, donc c'était techniquement possible). Aujourd'hui, je me dis que 5-6 mois auraient été plus réalistes - mais quand même. Les programmeurs se marchaient sur les pieds, et moi je me suis cassé. Le projet a coulé. Aucune initiative de ma part, aucune méthodologie non plus n'aurait pu sauver un tel monstre.

Plutôt que prétentieux, on aurait pu dire doué et éclairé/lucide.
Pour retomber sur mes pattes (je vais tout de même pas laisser passser un exemple si gentillement offert ), peut-être que s'il y avait eu un peu de contrôle sur l'architecture et la conception, ils auraient pas pondu un monstre à 18 yeux et 24 pattes ; et la chimère aurait pu être sauvé

[el_slapper]

(.../...)Ca rejoint ce que je disais sur le fait que l'assurance qualité n'est pas un mal en soi mais que ces applications sont en générales très douteuses d'où une grosse image négative ... Pour avoir connu un gros projets en CMMi niveau 3 et DO-178B (certifié niveau D, pas tellement critique), je peux dire que cela apporte réellement quelque chose. Et c'est un point de vue partagé par les gens qui ont participé au projet. Et pourtant on était loin de l'implémentation "idéale".

Peut-être justement qu'une implémentation moins idéale est plus efficace...

(.../...)Qu'il progresse, ce n'est pas un problème. Mais il fera statistiquement plus d'erreur que les autres. Donc pourquoi rechigner à mettre en place des relectures croisées ?

Ah, mais j'en ai souvent réclamé. Que mon code n'ai jamais été relu me semble complètement dingue. La seule mission ou j'ai vu une revue de code, j'étais homologateur..... Pas besoin, pour autant, de tracer chaque remarque. Les codeurs(java, en l'occurence) ont reçu le message, et remis de l'ordre dans leur code.

(.../...)Ouais mais le délai serait beaucoup trop long !
Les gros projets que j'ai vu ont toujours été découpé en plus petites équipes.

Sauf ceux qui sont allés dans le décor, tel mon exemple.

Le fait d'avoir l'idée est une chose, le fait de s'appriorier le temps et l'argent du projet en est une autre.
Ensuite la seule chose que j'ai notée c'est qu'il faut tracer le changement quelques part, qu'il ait fait l'objet d'une discussion ou non.

Nous l'avons traçé après, dans la "doc technique"(qui depuis prend la poussière). Nous(nous étions deux) avions un budget pour la fonction de reporting, j'ai développé le "bonus"(qui était avant tout destiné à me protéger une fois l'appli en prod, mais qui a beaucoup plu) à l'intérieur de ce budget.

Et j'ai déjà donner deux bons exemples :

1. Le cowboy qui croit bien faire et se plante. Que ce soit sur le plan fonctionnel ou technique. Si personne n'est au courant, personne ne teste et c'est le carnage en fonction de la criticité de la fonction.
2. Le début qui arrive, et s'aperçoit que les choses ne fonctionnent pas comme dans la spéc (ou description du besoin ou autre). S'il n'y a pas de traces, toutes les discutions vont se refaire et peut-être arrivée sur une conclusion contradictoire.

Et j'ose même pas pensé si on cumule les deux

Et il y a l'exemple contraire : le type qui suit aveuglément la spec sans en saisir toutes les subtilités.

Mea Culpa je n'ai toujours pas lu "Code as Design" ...

Ceci dit l'intro donne moyennement envie de lire la suite :
Quoi ? Le produit est l'implémentation de sa conception ? Je sens qu'il y a beaucoup d'activité de "production" qui sont de la "conception". Le type aurait tout aussi bien pu écrire que la conception est la représentation d'un besoin ...
Je pense que c'est juste mal dit mais je n'ai pas pu m'empêcher Je lirai tout de même la suite !

C'est exactement le point de Jack Reeves : on ne produit pas un code, on le conçoit. Chaque caractère du code(actif ou commentaire) fait partie de la conception. La "conception" telle qu'elle est habituellement définie(i.e. il faut faire ci et ça comme çi et comme ça) n'est qu'une partie de la conception, la partie "haute".

La "production" commence à partir du moment ou la conception, c'est-à-dire le code, est intégralement validé. Elle peut se présenter sous la forme de mise en ligne, de livraison, d'impression sur CD/DVD, etc..... Mais tant que le code n'est pas définitif, on en est encore au stade de la conception.

C'est pour ça que je parle de "conception de bas niveau" quand je parle de mon code.

Celà étant, pour la communication, je parlais surtout de Alistair cockburn(mais c'est aussi un morceau pas évident à lire, je le reconnais).

Si seulement ca ne concernait que les débutants -_-'

Il avait 3 ans d'éxpérience dont 2 chez Accenture(je n'avais pas été clair, on pouvait effectivement croire à un perdreau de l'année).

Plutôt que prétentieux, on aurait pu dire doué et éclairé/lucide.
Pour retomber sur mes pattes (je vais tout de même pas laisser passser un exemple si gentillement offert ), peut-être que s'il y avait eu un peu de contrôle sur l'architecture et la conception, ils auraient pas pondu un monstre à 18 yeux et 24 pattes ; et la chimère aurait pu être sauvé

Disons expérimenté (j'aime pas "doué", ça sous-entend qu'il suffit que je claque des doigts; si c'était si facile, je ferais moins d'erreurs), en tous cas sur ce sujet précis. Je venais de faire un truc à peine moins compliqué dans des délais bien plus serrés. Après, le délai augmentant exponentiellement avec la difficulté, je tiens à mon estimation de 5-6 mois.

Mais la vraie raison de ce monstre, est que c'était un forfait, et que l'interêt du vendeur est de vendre plein de gens, pas un truc rapide fait par un gugusse dans son coin.....

[javamine]

[IRONIE]C'est marrant parce que les cours de psychologie et gestion de ressources humaines commencent généralement par : Tout le monde est pareil, on cherche tous à satisfaire nos besoins.[/IRONIE]

Oui, mais on a pas tous les mêmes besoins et les moyens d'y arriver sont différents chez tout le monde
Bref, tu as agis comme on le fait avec trop de docs : on lit les titres, et ça nous ennuie de lire le détail

Sinon tout ne passe pas par les relations humaines, en particulier les méthodes de travail. La façon dont tu fais ton travail chaque jour ne requiert pas nécessairement d'échange avec les autres. Et si tu en arrives à savoir ou estimer qu'une méthode est bonne c'est que tu l'as éprouvée plusieurs fois. Tu peux donc rationaliser et en faire un "process".

C'est ça que tu ne comprends pas dans mon discours. "Une méthode" n'est pas forcément bonne, elle sera différente en fonction des gens sur le projet.

Qu'il progresse, ce n'est pas un problème. Mais il fera statistiquement plus d'erreur que les autres. Donc pourquoi rechigner à mettre en place des relectures croisées ?

Je ne rechignes pas, il m'arrive de faire la relecture. Mais inutile d'en faire un process hyper détaillé, ça se fait directement avec la personne concerné c'est tout.

Autrement, je ne vois aucun process qui transformera un je-sais-tout (mais qui ne sait rien et qui en plus ne veut rien entendre) en quelqu'un d'"intégrer".

C'est quand même incroyable cette manie de vouloir faire rentrer les gens dans des cases ou des process, en permanence.
C'est bien là ton problème, ou tout du moins, notre différence de point de vue. Tu as un problème avec un "humain", tu cherches un process tout fait pour t'en sortir...

Ouais mais le délai serait beaucoup trop long !

Alors ça, ça reste à prouver

Pas toujours quand même. Y'en a, ils mettent une semaine à coder un SQL de 3 lignes, et ne comprennent pas pourquoi c'est insuffisant, ni même que c'est insuffisant. Mais souvent, des "inadaptés" ont juste été lancés dans la fosse aux lions sans le répulsif qui va bien.....

En fait, j'ai vécu une situation qui me rend optimiste sur tout le monde maintenant. Pour faire court, une de mes 1ère discussion avec une personne :
-Moi : "Ouvre le dossier 'Projets'"
-Lui : "Comment je fais?"
-Moi : "Bah double clique dessus!"
-Lui : "Euh...ok"
-Moi : ".... non ... avec l'autre bouton de la souris."

Bref, un mec proche de la retraite qui avait toujours travaillé sur des vieux systèmes, qui se retrouvait d'un seul coup sur les nouvelles technos alors qu'il avait déjà du mal à maîtriser Windows...
En 1 mois, après plein d’anecdotes aussi surréaliste, il est devenu parfaitement opérationnel.

[el_slapper]

(.../...)
En fait, j'ai vécu une situation qui me rend optimiste sur tout le monde maintenant. Pour faire court, une de mes 1ère discussion avec une personne :
-Moi : "Ouvre le dossier 'Projets'"
-Lui : "Comment je fais?"
-Moi : "Bah double clique dessus!"
-Lui : "Euh...ok"
-Moi : ".... non ... avec l'autre bouton de la souris."

Bref, un mec proche de la retraite qui avait toujours travaillé sur des vieux systèmes, qui se retrouvait d'un seul coup sur les nouvelles technos alors qu'il avait déjà du mal à maîtriser Windows...
En 1 mois, après plein d’anecdotes aussi surréaliste, il est devenu parfaitement opérationnel.

C'est la majorité des cas.

Mais quand le gars t'explique que non, il est en avance, alors que manifestement non, qu'il passe sa journée à pianoter sur son smartphone; Quand il t'explique pourquoi il est meilleur que toi alors que dès que ça dépasse 10 lignes il t'appelle à l'aide(après une semaine à faire semblant de chercher), là, tu ne peux rien faire.

Heureusement, il y a aussi des gens qui progressent. A tout âge. Mais c'est une question de personne, encore une fois, ici les paramètres 2 et 3 : la motivation et la compétence(le deuxième tirant le troisième vers le haut). Ton "ancien" était motivé, et ça a tiré sa compétence vers le haut. Quand la motivation est feinte(indétectable à l'entretien, malheureusement), tu est chocolat.

[Logan Mauzaize]

Peut-être justement qu'une implémentation moins idéale est plus efficace...

Pour du CMMi niveau 3 (équivalent ISO 9001 mais pour le développement logiciel), je ne pense pas. En tout cas pas dans ce cas précis. D'ailleurs les problèmes étaient liés, comme je l'avais laissé entendre dans un de mes précédents messages, au fait que c'était la direction qui avait fait certains choix concernant les activités de développement ...

Ah, mais j'en ai souvent réclamé. Que mon code n'ai jamais été relu me semble complètement dingue. La seule mission ou j'ai vu une revue de code, j'étais homologateur..... Pas besoin, pour autant, de tracer chaque remarque. Les codeurs(java, en l'occurence) ont reçu le message, et remis de l'ordre dans leur code.

Tu balances tes remarques au fur et à mesure même si c'est 18 fois la même ? :s

Nous l'avons traçé après, dans la "doc technique"(qui depuis prend la poussière). Nous(nous étions deux) avions un budget pour la fonction de reporting, j'ai développé le "bonus"(qui était avant tout destiné à me protéger une fois l'appli en prod, mais qui a beaucoup plu) à l'intérieur de ce budget.

Le "bonus" aurait pu être transformée en marge nette... Je tourne la question autrement parce que malheureusement le temps qu'on fait gagner on le reçoit pas dans sa poche.
Si tu avais eu le choix entre développer le bonus ou avoir une grosse prime ?

Ta documentation prend peut-être la poussière mais le jour où un nouveau arrivera, il aura les informations et les détails de ces améliorations.

Et il y a l'exemple contraire : le type qui suit aveuglément la spec sans en saisir toutes les subtilités.

1. Les subtilités/ambiguités ont déjà été en partie levée dans la phase de relecture des spécifications
2. Rien n'empêche le développeur de lire la spécification de manière critique et de poser les bonnes questions/remarques.

C'est exactement le point de Jack Reeves : on ne produit pas un code, on le conçoit. Chaque caractère du code(actif ou commentaire) fait partie de la conception. La "conception" telle qu'elle est habituellement définie(i.e. il faut faire ci et ça comme çi et comme ça) n'est qu'une partie de la conception, la partie "haute".

La "production" commence à partir du moment ou la conception, c'est-à-dire le code, est intégralement validé. Elle peut se présenter sous la forme de mise en ligne, de livraison, d'impression sur CD/DVD, etc..... Mais tant que le code n'est pas définitif, on en est encore au stade de la conception.

C'est pour ça que je parle de "conception de bas niveau" quand je parle de mon code.

Un code en maintenance n'est donc que de la conception jusqu'à son redéploiement ?

Je ne parlerais que de l'avionique parce que c'est la seule activité de production que je connaisse. Et je peux te dire que la fabrication d'un avion, avant sa production en chaîne, suit exactement la même logique. La seule différence c'est qu'on ne fait quasiment pas de production en grande échelle.

Cependant c'est l'objectif de CMMi que d'industrialiser les développement logiciel. A l'heure d'aujourd'hui, compte tenu de la maturité du génie logiciel, c'est complétement débile. Mais je doute pas qu'un jour ce modèle soit efficace. En attendant, je te l'accorde c'est super utopique.

Celà étant, pour la communication, je parlais surtout de Alistair cockburn(mais c'est aussi un morceau pas évident à lire, je le reconnais).

Tu penses à une publication en particulier ? J'ai survolé l'entrée Wikipedia à son nom et celle de "Crystal Clear", ca semble être interressant tout ça !
Je classe ça à côté du "KISS"

Il avait 3 ans d'éxpérience dont 2 chez Accenture(je n'avais pas été clair, on pouvait effectivement croire à un perdreau de l'année).

S'il a passé 3 ans à faire de la merde, pas grand chose ou ne pas évoluer, ca n'en reste pas moins un débutant.
Quelque part je trouve aussi nul de baser le niveau de quelqu'un sur son nombre d'années d'expérience que de promovoir l'idée que pour avoir réussi sa carrière il faut être chef de projet à 30 ans.
Seul le nombre, la qualité et la diversité des expériences significatives sont déterminantes. C'est d'ailleurs à cause de cette méthode de calcul du niveau qu'on se retrouve avec des gars complétement largués parce qu'on nous a dit que la personne était expérimentée alors on l'a laissé faire un peu toute seule et on finit dans un mur.

Disons expérimenté (j'aime pas "doué", ça sous-entend qu'il suffit que je claque des doigts; si c'était si facile, je ferais moins d'erreurs), en tous cas sur ce sujet précis.

Désolé mais quelqu'un qui fait mieux, voir bien mais là je peux pas en juger, je pense qu'il est plus doué que ces compères. Et si en plus il faut bien mieux, je dis simplement qu'il est doué.
Doué ne veut pas dire que tu fais moins d'erreur mais que tu as de bonnes idées au bon moment.

Je venais de faire un truc à peine moins compliqué dans des délais bien plus serrés. Après, le délai augmentant exponentiellement avec la difficulté, je tiens à mon estimation de 5-6 mois.

Mais la vraie raison de ce monstre, est que c'était un forfait, et que l'interêt du vendeur est de vendre plein de gens, pas un truc rapide fait par un gugusse dans son coin.....

On peut vendre beaucoup de gens à rien faire sans produire un monstre J'ai connu ça ... Quand j'en ai eu marre (entre autre) de glander, je me suis barré.
D'ailleurs il y a des SSII spécialisées dans ce genre de projet !

Oui, mais on a pas tous les mêmes besoins et les moyens d'y arriver sont différents chez tout le monde
Bref, tu as agis comme on le fait avec trop de docs : on lit les titres, et ça nous ennuie de lire le détail

Belle pirouette
En tout cas je vois souvent le même décliné en trois modes : confort (argent, tranquillité, oisiveté).

C'est ça que tu ne comprends pas dans mon discours. "Une méthode" n'est pas forcément bonne, elle sera différente en fonction des gens sur le projet.

Les façons idéales de programmer, de mener une campagne de test, gérer les ressources techniques, etc. ne doivent pas différer de beaucoup d'un projet à l'autre. D'ailleurs je dis pas qu'il n'existe qu'une seule méthode ; mais que quand tu en tiens une efficace, on peut facilement l'appliquer à d'autres projets (surtout dans le même contexte/service !).
Les plans qualité ne sont pas globaux mais déclinés à chaque niveau jusqu'à un projet en particulier.

Je ne rechignes pas, il m'arrive de faire la relecture. Mais inutile d'en faire un process hyper détaillé, ça se fait directement avec la personne concerné c'est tout.

Si tu en as l'habitude, tu peux utiliser un outil.
Autrement tu retrouveras souvent les mêmes données : relecteur(s), auteur(s), document, criticité, description, réponse. Peu importe la forme.
Concernant la méthode : vérifier la conformité aux bonnes pratiques, aux "recommandations" de l'architecte, l'ingénieur qualité, le client, etc. ; vérifier l'absence de bug.

C'est quand même incroyable cette manie de vouloir faire rentrer les gens dans des cases ou des process, en permanence.
C'est bien là ton problème, ou tout du moins, notre différence de point de vue. Tu as un problème avec un "humain", tu cherches un process tout fait pour t'en sortir...

Si dans ta première phrase tu parles d'adjectif/qualificatif/description, je suis bien désolé d'employé de tels types de mots et constructions pour expliquer les choses.

Alors ça, ça reste à prouver

1000 jours/homme divisé par 10 hommes = 100 jours
1000 jours/homme divisé par 5 hommes = 200 jours
CQFD

En fait, j'ai vécu une situation qui me rend optimiste sur tout le monde maintenant. Pour faire court, une de mes 1ère discussion avec une personne :
-Moi : "Ouvre le dossier 'Projets'"
-Lui : "Comment je fais?"
-Moi : "Bah double clique dessus!"
-Lui : "Euh...ok"
-Moi : ".... non ... avec l'autre bouton de la souris."

Bref, un mec proche de la retraite qui avait toujours travaillé sur des vieux systèmes, qui se retrouvait d'un seul coup sur les nouvelles technos alors qu'il avait déjà du mal à maîtriser Windows...
En 1 mois, après plein d’anecdotes aussi surréaliste, il est devenu parfaitement opérationnel.

J'ai eu le droit à l'antithèse : un gars qui connait (enfin le croit), pense que les autres c'est de la merde et qui fait encore plus de merde que le pire des débutants ...

[javamine]

1000 jours/homme divisé par 10 hommes = 100 jours
1000 jours/homme divisé par 5 hommes = 200 jours
CQFD

Voilà bien une réponse d'un "spécialiste" de la qualité capable de réfléchir qu'avec des indicateurs/abaques tout droit sortie de sa bible CMMi.

Je te propose la résolution sous un autre angle :
1000 jours/homme divisé par 10 hommes = 100 jours
1000 jours/homme divisé par 5 hommes ...et ...ah bah "on est vraiment pas obligé de mettre en place tous ces process si lourd"; "on est plus souple et travaillons plus vite en étant moins nombreux"; "on choisit mieux son équipe"; "on met en place une bonne stratégie de communication"; ... ; et on divise le temps par 2 dis donc ! => 500 jours/homme divisé par 5 hommes = 100 jours

Je te l'accorde, ça demande un peu plus de réflexion que de simplement sortir sa check-list CMMi lors du lancement d'un projet.

J'ai eu le droit à l'antithèse : un gars qui connait (enfin le croit), pense que les autres c'est de la merde et qui fait encore plus de merde que le pire des débutants ...

Pareil, je l'ai fais dégager (c'était mon 2ème cas ). Du coup le projet s'est bien passé

[el_slapper]

Pour du CMMi niveau 3 (équivalent ISO 9001 mais pour le développement logiciel), je ne pense pas. En tout cas pas dans ce cas précis. D'ailleurs les problèmes étaient liés, comme je l'avais laissé entendre dans un de mes précédents messages, au fait que c'était la direction qui avait fait certains choix concernant les activités de développement ...

Si tu veux dire que les choix doivent être faits par ceux qui ont les mains dans le cambouis(numérique), alors je suis d'accord.

Tu balances tes remarques au fur et à mesure même si c'est 18 fois la même ? :s

Pourquoi pas? Ce que j'ai vu faire - et qui me semble pédagogique - c'est l'architecte qui prend le programmeur sur ses genoux, et qui dépile le code. Le même défaut peut apparaitre plusieurs fois de suite, en effet.

Le "bonus" aurait pu être transformée en marge nette... Je tourne la question autrement parce que malheureusement le temps qu'on fait gagner on le reçoit pas dans sa poche.
Si tu avais eu le choix entre développer le bonus ou avoir une grosse prime ?

Non, parceque ça n'aurait jamais été facturé.

Ta documentation prend peut-être la poussière mais le jour où un nouveau arrivera, il aura les informations et les détails de ces améliorations.

Tous les détails ne sont pas utiles dans la doc. Une bonne tracabilité des évolutions dans le code me parait suffisante.

1. Les subtilités/ambiguités ont déjà été en partie levée dans la phase de relecture des spécifications
2. Rien n'empêche le développeur de lire la spécification de manière critique et de poser les bonnes questions/remarques.

Cas 1 : le développeur remplit une feuille EXCEL avec ses questions. Il a ses réponses 3 jours plus tard. A coté de la plaque.
Cas 2 : le développeur traverse le couloir, pose des questions, et a des réponses précises 10 minutes plus tard.

Un code en maintenance n'est donc que de la conception jusqu'à son redéploiement ?

Oui. On conçoit la correction/évolution. C'est une modification du document de conception - qui doit être validée par une homologation.

(.../...)Cependant c'est l'objectif de CMMi que d'industrialiser les développement logiciel. A l'heure d'aujourd'hui, compte tenu de la maturité du génie logiciel, c'est complétement débile. Mais je doute pas qu'un jour ce modèle soit efficace. En attendant, je te l'accorde c'est super utopique.

Je n'y crois pas. ça n'avait aucun sens dans les années 80(les Japonais s'y sont cassé les dents), ça n'a aucun sens de nos jours, il me parait peu probable que ça en aie un dans 30 ans.

Tu penses à une publication en particulier ? J'ai survolé l'entrée Wikipedia à son nom et celle de "Crystal Clear", ca semble être interressant tout ça !
Je classe ça à côté du "KISS"

je pensais à ça.

S'il a passé 3 ans à faire de la merde, pas grand chose ou ne pas évoluer, ca n'en reste pas moins un débutant.
Quelque part je trouve aussi nul de baser le niveau de quelqu'un sur son nombre d'années d'expérience que de promovoir l'idée que pour avoir réussi sa carrière il faut être chef de projet à 30 ans.
Seul le nombre, la qualité et la diversité des expériences significatives sont déterminantes. C'est d'ailleurs à cause de cette méthode de calcul du niveau qu'on se retrouve avec des gars complétement largués parce qu'on nous a dit que la personne était expérimentée alors on l'a laissé faire un peu toute seule et on finit dans un mur.

Là, on est d'accord. Sauf pour ce gugusse, qui prétendait savoir faire.

Désolé mais quelqu'un qui fait mieux, voir bien mais là je peux pas en juger, je pense qu'il est plus doué que ces compères. Et si en plus il faut bien mieux, je dis simplement qu'il est doué.
Doué ne veut pas dire que tu fais moins d'erreur mais que tu as de bonnes idées au bon moment.

Bon, ça, ça m'arrive. Mais il faut toujours rester humble. Sinon, on arrête de progresser, et on est mort.

On peut vendre beaucoup de gens à rien faire sans produire un monstre J'ai connu ça ... Quand j'en ai eu marre (entre autre) de glander, je me suis barré.
D'ailleurs il y a des SSII spécialisées dans ce genre de projet !

hélas vrai.

Les façons idéales de programmer, de mener une campagne de test, gérer les ressources techniques, etc. ne doivent pas différer de beaucoup d'un projet à l'autre. D'ailleurs je dis pas qu'il n'existe qu'une seule méthode ; mais que quand tu en tiens une efficace, on peut facilement l'appliquer à d'autres projets (surtout dans le même contexte/service !).
Les plans qualité ne sont pas globaux mais déclinés à chaque niveau jusqu'à un projet en particulier.

Sauf que chaque projet est différent, et que si tu cesses d'adapter ton process, tu t'éloignes d'un système efficace.

(.../...)1000 jours/homme divisé par 10 hommes = 100 jours
1000 jours/homme divisé par 5 hommes = 200 jours
CQFD

Et là, c'est le drame. Martin Fowler estime que la productivité d'un groupe vaut à peu près la racine du nombre de travailleurs(deuxième paragraphe). Donc, si 5 gars le feront en 200 jours, 10 gars le feront en 200/racine(10/5). Donc 141 jours environ. Et ce, à compétence constante.

C'est évidemment une estimation au doigt mouillé. Le vrai facteur, ce sont les gens qui rentrent. Plus on en met, plus il est difficille de trouver des bons.

J'ai eu le droit à l'antithèse : un gars qui connait (enfin le croit), pense que les autres c'est de la merde et qui fait encore plus de merde que le pire des débutants ...

fréquent, hélas. . Et ils errent de SSII en SSII, de mission en mission, sans jamais qu'on parvienne à s'en débarasser. Je ne pense pas qu'ils soient nombreux, mais comme ils se font tout le temps virer, ils passent partout, et on a l'impression qu'ils sont partout.

[deathness]

Et là, c'est le drame. Martin Fowler estime que la productivité d'un groupe vaut à peu près la racine du nombre de travailleurs(deuxième paragraphe). Donc, si 5 gars le feront en 200 jours, 10 gars le feront en 200/racine(10/5). Donc 141 jours environ. Et ce, à compétence constante.

C'est évidemment une estimation au doigt mouillé. Le vrai facteur, ce sont les gens qui rentrent. Plus on en met, plus il est difficille de trouver des bons.

Je plussoie sur ce point. Doubler le nombre de personne veut pas dire diviser par deux le temps de projet. Surtout si l'on met des gens incompétent qui non seulement ne feront pas grand chose mais le feront mal. Et arrive après l'enfer, les personnes derrière qui ne refont pas mais s'adapte en faisant des choses encore plus affreuse. Et le cycle infernal est lancé

[Glutinus]

Si on pense que la relation est un réel produit, dans ce cas mettre 1200 développeurs une journée sur un projet à 1200jh permettrait de le terminer le soir-même. La vie est belle quand même !

[Nachalnikov]

Je plussoie sur ce point. Doubler le nombre de personne veut pas dire diviser par deux le temps de projet. Surtout si l'on met des gens incompétent qui non seulement ne feront pas grand chose mais le feront mal. Et arrive après l'enfer, les personnes derrière qui ne refont pas mais s'adapte en faisant des choses encore plus affreuse. Et le cycle infernal est lancé

Le problème est un peu plus complexe que l'incompétence des nouveaux venus. Fowler, dans son exposé, reprend des éléments de Brooks, notamment sur les temps de synchronisation (qui augmentent avec le nombre de personnes). Il faut y ajouter que toutes les tâches ne sont pas parallélisables. Et on arrive à la loi de Brooks "Neuf femmes ne font pas un enfant en un mois".
C'est d'ailleurs aussi une vieille loi économique qui dit que passé un certain seuil de travailleurs, la productivité marginale décroit. Mais tout ceci n'est qu'un zoom sur une partie négligeable des posts de Nemek (très intéressants par ailleurs), ce qui permet de clore le débat facilement

[SurferIX]

Mais mais... personne n'a lu "The mythical man-month" ?
Ce livre était parfaitement vrai il y a 20 ans, il a été ré-édité pour deux raisons :
- il a été tellement vendu qu'il y a eu rupture de stock
- il a été réactualisé.

Lisez les 160 commentaires sur amazon, c'est très instructif.

Le thème central de ce bouquin est la pure réalité, et explique tout, voire aide à réfléchir sur la plupart des projets, à savoir : ajouter de la main d'œuvre à un projet informatique en retard ne fait que le retarder encore plus.

Cela peut s'appliquer en fait dès le début d'un projet : trop de main d'œuvre tue la main d'œuvre .

[deathness]

Le thème central de ce bouquin est la pure réalité, et explique tout, voire aide à réfléchir sur la plupart des projets, à savoir : ajouter de la main d'œuvre à un projet informatique en retard ne fait que le retarder encore plus.

Et oui les nouveaux venu, ça se forme! Et bien souvent jusqu'à 6 mois pour être autonome. Difficile donc de rajouter des ressources sur les projets en fin de vie.

[el_slapper]

Mais mais... personne n'a lu "The mythical man-month" ?
Ce livre était parfaitement vrai il y a 20 ans, il a été ré-édité pour deux raisons :
- il a été tellement vendu qu'il y a eu rupture de stock
- il a été réactualisé.

Lisez les 160 commentaires sur amazon, c'est très instructif.

Le thème central de ce bouquin est la pure réalité, et explique tout, voire aide à réfléchir sur la plupart des projets, à savoir : ajouter de la main d'œuvre à un projet informatique en retard ne fait que le retarder encore plus.

Cela peut s'appliquer en fait dès le début d'un projet : trop de main d'œuvre tue la main d'œuvre .

Si seulement il existait une trad française..... lire l'anglais sur écran, ça va, mais un bouquin complet, c'est au-delà de mes forces.

EDIT : je rajoute une réponse à ceci :

Et oui les nouveaux venu, ça se forme! Et bien souvent jusqu'à 6 mois pour être autonome. Difficile donc de rajouter des ressources sur les projets en fin de vie.

ça m'est arrivé d'être positionné en fin de projet(à la place d'un type qui avait soudain arreté de bosser). Je n'ai pu faire que les "rogatons", les petits trucs annexes sans grande importance. Impossible pour moi d'entrer sur les parties principales du projet. Trop complexe. J'ai quand même été utile, mais juste parceque j'ai libéré les programmeurs principaux(i.e. ceux qui étaient sur le coeur de l'appli) de tâches emmerdantes et pas en rapport.

[Logan Mauzaize]

Voilà bien une réponse d'un "spécialiste" de la qualité capable de réfléchir qu'avec des indicateurs/abaques tout droit sortie de sa bible CMMi.

Je te propose la résolution sous un autre angle :
1000 jours/homme divisé par 10 hommes = 100 jours
1000 jours/homme divisé par 5 hommes ...et ...ah bah "on est vraiment pas obligé de mettre en place tous ces process si lourd"; "on est plus souple et travaillons plus vite en étant moins nombreux"; "on choisit mieux son équipe"; "on met en place une bonne stratégie de communication"; ... ; et on divise le temps par 2 dis donc ! => 500 jours/homme divisé par 5 hommes = 100 jours


Je te l'accorde, ça demande un peu plus de réflexion que de simplement sortir sa check-list CMMi lors du lancement d'un projet.

La réflexion c'est de se dire que dans 1000 jours on doit largement de quoi trouver quasi-constamment 10 tâches parallélisables. J'ai assez pesé mes chiffres avant de les donner pour trouver à la fois une adéquation réaliste entre le nombre de jours/hommes et le nombre d'hommes et la simplicité du calcul.
D'ailleurs ma vision d'un tel découpage sous-entendait de passer en mode bi-projet. J'ai donc réalisé de la planification ... J'avoue que ca demande un peu de rélfexion quand on préfère travailler en solo en pensant qu'on peut faire le même nombre de jours à 1, 5 ou 10 personnes.
Car si on suit ton raisonnement, je le fais tout seul en 100 jours à La RACHE© ... (Je m'économise en plus de la communication)

Pareil, je l'ai fais dégager (c'était mon 2ème cas ). Du coup le projet s'est bien passé

Le problème dans mon cas qu'on voulait le virer mais qu'il était plus en période d'essai. Cependant, pour notre plus grand bonheur, notre bon monsieur a souhaité aller chez le client qui l'a accepté. Depuis ils lui ont trouvé un placard bien confortable qui nécessite peu d'échange et sans trop d'impact sur les projets :p

[Logan Mauzaize]

Si tu veux dire que les choix doivent être faits par ceux qui ont les mains dans le cambouis(numérique), alors je suis d'accord.

Disons que globalement la manière de travailler d'une personne doit être jaugé à la fois par une personne qui fait le même travail, mais aussi par un supérieur et un subordonné. En bref tout ceux qui subissent le travail et son résultat.

Pourquoi pas? Ce que j'ai vu faire - et qui me semble pédagogique - c'est l'architecte qui prend le programmeur sur ses genoux, et qui dépile le code. Le même défaut peut apparaitre plusieurs fois de suite, en effet.

Quand on en arrive là, j'appelle plus ça de la relecture mais de la formation/tutorat.

Non, parceque ça n'aurait jamais été facturé.

Et alors ? Facturé ou pas, c'est consommé ...
Quand tu manges quelque chose, il y a forcément quelqu'un qui l'a payé : toi si tu l'as acheté, le commerçant si tu l'as volé !

Tous les détails ne sont pas utiles dans la doc. Une bonne tracabilité des évolutions dans le code me parait suffisante.

Tu ne synthétiseras pas les spécifications dans les commentaires du code.

Cas 1 : le développeur remplit une feuille EXCEL avec ses questions. Il a ses réponses 3 jours plus tard. A coté de la plaque.
Cas 2 : le développeur traverse le couloir, pose des questions, et a des réponses précises 10 minutes plus tard.

Pour être ironique mais vécu il y a 1 mois :
Cas 1 : le développeur téléphone au client pose des questions, et a des réponses erronées mais précises 10 minutes plus tard. Et éventuellement, le même laps de temps plus tard, le client rappelle pour dire le contraire.
Cas 2 : le développeur remplit une feuille EXCEL avec ses questions. Il a ses réponses bien réfléchies et justes 3 jours plus tard.

De plus dans TON cas 1, vu que ce n'est pas tracé les 4 autres développeurs font la même chose et c'est 50 minutes de perdus dans une seule semaine. Si le projet dure/vit plusieurs années ... En plus, si tu n'es plus là ... Qui va répondre au développeur ? Personne ...

Oui. On conçoit la correction/évolution. C'est une modification du document de conception - qui doit être validée par une homologation.

Ok !

Je n'y crois pas. ça n'avait aucun sens dans les années 80(les Japonais s'y sont cassé les dents), ça n'a aucun sens de nos jours, il me parait peu probable que ça en aie un dans 30 ans.

C'était vrai dans les années 80 (exemple le projet METEOR ), et de manière générale avec les méthodes B.

De plus MDA tent vers ce concept mais hélàs bien défini mais mal maîtrisé. D'un autre côté tout ce qui est matériel tend à être de moins en moins déterministe.

je pensais à ça.

Merci ! J'essairai de lire mais je suis pas certains que mon niveau d'anglais soit suffisant pour tout comprendre

Bon, ça, ça m'arrive. Mais il faut toujours rester humble. Sinon, on arrête de progresser, et on est mort.

Entièrement d'accord, d'ailleurs j'aime bien le terme anglais "keep in touch".

Sauf que chaque projet est différent, et que si tu cesses d'adapter ton process, tu t'éloignes d'un système efficace.

Enfin dans les grandes lignes, 80% sont contants : développement logiciel en Java avec un degré de qualité déterminé pour une équipe allant généralement de 3 à 7 personnes (CP inclus).
Je dirai que 80% de ces mêmes 80% doivent se faire selon un cycle en V, contre 20% selon une méthode plutôt agile.

Et là, c'est le drame. Martin Fowler estime que la productivité d'un groupe vaut à peu près la racine du nombre de travailleurs(deuxième paragraphe). Donc, si 5 gars le feront en 200 jours, 10 gars le feront en 200/racine(10/5). Donc 141 jours environ. Et ce, à compétence constante.

Tu supposes qu'on a augmenté l'équipe mais si on la réduit ? Je suis passé de 10 à 5, pas l'inverse !
De plus cela suppose que deux projets peuvent être faits en moins de temps s'ils sont fait de manière séquentielle par la même équipe.

De toutes façons même en acceptant ton nouveau chiffre, j'y gagne toujours 41 jours de planning. Sur 100 jours c'est plutôt pas mal ! Surtout quand on multiplie les projets qui dépendent les uns des autres.

C'est évidemment une estimation au doigt mouillé. Le vrai facteur, ce sont les gens qui rentrent. Plus on en met, plus il est difficille de trouver des bons.

Donc si j'enlève les 5 moins bons ...

fréquent, hélas. . Et ils errent de SSII en SSII, de mission en mission, sans jamais qu'on parvienne à s'en débarasser. Je ne pense pas qu'ils soient nombreux, mais comme ils se font tout le temps virer, ils passent partout, et on a l'impression qu'ils sont partout.

Heureusement pour moi j'ai pas encore cette impression, mais je suis jeune

Et on arrive à la loi de Brooks "Neuf femmes ne font pas un enfant en un mois".

A l'opposé, elles ne mettront pas non plus 81 mois pour le faire. De plus cela suppose que le chemin critique fait 1 mois Or dans mon cas le chemin critique ne fera sûrement pas 100 jours !

[el_slapper]

Bon, je sabre ce sur quoi je ne suis pas en désaccord fondamental.

(.../...)
Quand on en arrive là, j'appelle plus ça de la relecture mais de la formation/tutorat.

Et? C'est un souci? La compétence des gens est essentielle. Ce genre de pratique améliore, en 30 minutes, la compétence des gens(le relecteur aussi, peut voir des choses intéressantes).

Et alors ? Facturé ou pas, c'est consommé ...
Quand tu manges quelque chose, il y a forcément quelqu'un qui l'a payé : toi si tu l'as acheté, le commerçant si tu l'as volé !

Pour moi, ça fait partie du développement. De la même manière que je compte toujours le remplissage du suivi dans mes chiffrages(puisqu'ils ne sont pas comptabilisables directement).

Tu ne synthétiseras pas les spécifications dans les commentaires du code.

Ca dépend. Mais je n'ai pas dit qu'il ne fallait pas de doc générale. Juste, qu'on a pas besoin du moindre boulon dedans(contrairement à l'aviation, métier qui a d'autres contraintes).

Pour être ironique mais vécu il y a 1 mois :
Cas 1 : le développeur téléphone au client pose des questions, et a des réponses erronées mais précises 10 minutes plus tard. Et éventuellement, le même laps de temps plus tard, le client rappelle pour dire le contraire.
Cas 2 : le développeur remplit une feuille EXCEL avec ses questions. Il a ses réponses bien réfléchies et justes 3 jours plus tard.

De plus dans TON cas 1, vu que ce n'est pas tracé les 4 autres développeurs font la même chose et c'est 50 minutes de perdus dans une seule semaine. Si le projet dure/vit plusieurs années ... En plus, si tu n'es plus là ... Qui va répondre au développeur ? Personne ...

La réponse fausse.....est fausse. Ou veux-tu en venir?

Enfin dans les grandes lignes, 80% sont contants : développement logiciel en Java avec un degré de qualité déterminé pour une équipe allant généralement de 3 à 7 personnes (CP inclus).
Je dirai que 80% de ces mêmes 80% doivent se faire selon un cycle en V, contre 20% selon une méthode plutôt agile.

La variabilité sera moindre. Mais suivant qu'il s'agit de refondre un vieux batch en cobol ou de pondre une nouvelle transaction qui brille, les contraintes ne seront quand même pas identiques. Et des ajustements seront utiles.

Tu supposes qu'on a augmenté l'équipe mais si on la réduit ? Je suis passé de 10 à 5, pas l'inverse !
De plus cela suppose que deux projets peuvent être faits en moins de temps s'ils sont fait de manière séquentielle par la même équipe.

Avec une nuance de taille : si les gens ont travaillé ensemble, peu de savoir-faire sera perdu. Si chacun a été le nez dans ses specs - même exhaustives - on a perdu 50% du savoir faire. Le cout est bien supérieur.

De toutes façons même en acceptant ton nouveau chiffre, j'y gagne toujours 41 jours de planning. Sur 100 jours c'est plutôt pas mal ! Surtout quand on multiplie les projets qui dépendent les uns des autres.

A condition de les mettre dès le départ. Le même lien que je fournis précise qu'il faut entre 2 et 4 semaines avant que les nouveaux soient productifs.

Donc si j'enlève les 5 moins bons ...

A condition qu'ils n'aient pas acquis un savoir faire couteux à remplacer.

[Logan Mauzaize]

Bon, je sabre ce sur quoi je ne suis pas en désaccord fondamental.

N'hésites pas à compléter quand tu as plus de temps/envie

Et? C'est un souci? La compétence des gens est essentielle. Ce genre de pratique améliore, en 30 minutes, la compétence des gens(le relecteur aussi, peut voir des choses intéressantes).

Juste pour dire qu'on parlait de formaliser la relecture. Et que donc je suis d'accord qu'on ne formalise pas le processus de formation quoique ca existe mais que la grille de remarques n'est pas valable dans ce cas puisqu'on n'est passé sur un autre type d'activité.

Pour moi, ça fait partie du développement. De la même manière que je compte toujours le remplissage du suivi dans mes chiffrages(puisqu'ils ne sont pas comptabilisables directement).

Je ne suis pas sûr de comprendre donc je vais reformuler, puis tu me diras si cela change ta réponse :
Tu as passé du temps gratuitement (au compte du client) sur une activité, cependant tu as été payé pour ce travail (au compte de ta société). Donc tu as fait perdre de l'argent (ou grignoter la marge). Ma question était donc : est-ce que tu préfères te mettre la marge dans la poche (disons plutôt la marge non perdue) ou offrir du développement à ton client ?

Ca dépend. Mais je n'ai pas dit qu'il ne fallait pas de doc générale. Juste, qu'on a pas besoin du moindre boulon dedans(contrairement à l'aviation, métier qui a d'autres contraintes).

Ok alors
Personnellement je préfère une documentation centralisée plutôt qu'aller fouiller dans le code. Mais c'est aussi une façon valable de travailler.
D'un point de vue purement qualité, puisque c'est tout de même censé être le point de vue que je défends, c'est toujours valable tant que c'est marqué et que tout le monde sait où le trouver.

La réponse fausse.....est fausse. Ou veux-tu en venir?

Oui mais le principe c'était d'opposé l'échange verbal à celui écrit.
Ceci dit je t'accorde qu'une réponse fausse tracée c'est pire que de rien avoir. Cependant celui qui a posé la question doit au moins marqué que la réponse est foireuse.

La variabilité sera moindre. Mais suivant qu'il s'agit de refondre un vieux batch en cobol ou de pondre une nouvelle transaction qui brille, les contraintes ne seront quand même pas identiques. Et des ajustements seront utiles.

Pour rappel un process qualité se précise pour à chaque niveau d'application. Ainsi il existe un plan qualité client, un autre pour le contrat, un autre pour le projet etc. Ensuite rien n'empêche d'y mettre des paragraphes optionnels (tels des if dans un code).
Pour avoir travaillé également sur des batch, d'une manière process, je n'y vois pas énormément différence. D'autant plus que j'y travaillais en mode TMA et non en mode forfait (comme la plupart de mes expériences).
Je recois une spécification, j'analyse, j'attends ou pas l'acceptation, je recommence autant de fois que nécessaire, je code, je test, je recommence autant de fois que nécessaire, je test à plus grande échelle, je recommence à l'étape n-2 autant de fois que nécessaire, je recommence en agrandissant l'échelle autant de fois que nécessaire, je livre, et repars éventuellement sur des boucles à n'importe quelle étape précédente.
Un bon vieux cycle en V quoi ... Qu'est-ce qui change à travers mes différentes expériences ? Le codage, qui fait les tests, la taille et le temps des boucles ... Rarement ma façon de travailler (en mode forfait quand on a clôturer les consommations, on passe en mode à la RACHE, SSII oblige )

Avec une nuance de taille : si les gens ont travaillé ensemble, peu de savoir-faire sera perdu. Si chacun a été le nez dans ses specs - même exhaustives - on a perdu 50% du savoir faire. Le cout est bien supérieur.

A condition de les mettre dès le départ. Le même lien que je fournis précise qu'il faut entre 2 et 4 semaines avant que les nouveaux soient productifs.

A condition qu'ils n'aient pas acquis un savoir faire couteux à remplacer.

Je suppose qu'on démarre un projet avec 10 ou 5 personnes pas qu'on fasse partir les personnes en cours.

Je ne préfère pas traiter le problème de la variation des équipes au cours d'un projet tant les problématiques d'intégration, de nivélation des compétences, etc affectent énormément la variation du planning.

Le problème pour rappel était de pouvoir diminuer la durée d'un projet en modulant la taille de l'équipe.