Discussion :

[grunk]

Comment être crédible si on ne sait pas estimé son temps de réalisation ?

Sommes nous plus crédible quand on annonce un délais de X semaines et qu'au final on livre en X+n semaines parce que comme à chaque fois on ne peut pas prévoir l’imprévisible.
Perso je suis pas capable d'annoncer un délai réaliste avant d'avoir les mains dans le code depuis un petit moment tout simplement parce que avant je n'ai pas une connaissance suffisante du projet, de sa courbe d'évolution, etc ...
C'est encore plus vrai quand on reprend de l'existant et qu'on va de surprise en surprise au fur et à mesure qu'on s'enfonce dans le code.

Un meilleur équipement est l'investissement le moins cher à la productivité

Un simple SSD pour compiler ca change tout. Sur certains projet c'est pas loin de 5min par compilation. Multiplié par les 10 ou 20 compilation que tu fais par jour ...

[landry161]

Sommes nous plus crédible quand on annonce un délais de X semaines et qu'au final on livre en X+n semaines parce que comme à chaque fois on ne peut pas prévoir l’imprévisible.
Perso je suis pas capable d'annoncer un délai réaliste avant d'avoir les mains dans le code depuis un petit moment tout simplement parce que avant je n'ai pas une connaissance suffisante du projet, de sa courbe d'évolution, etc ...
C'est encore plus vrai quand on reprend de l'existant et qu'on va de surprise en surprise au fur et à mesure qu'on s'enfonce dans le code.

Très juste.

[Luckyluke34]

Comment être crédible si on ne sait pas estimé son temps de réalisation ?
Personnellement, ça me renvoie une image de quelqu'un qui ne maîtrise pas ce qu'il fait.

Je préfère de très loin un développeur moyen mais qui sait me fixer une date de réalisation et la tenir (ou encore anticiper un retard et le remonter à temps) plutôt qu'un cador qui livre ses dev de manière erratique.

Mais tu connais beaucoup de projets dont la date de livraison estimée n'a pas dérivé ? Pas moi.

Selon certaines études, le dépassement de délai moyen pour les projets software était de 74% en 2012. Il y a des précédents absolument désastreux comme healthcare.gov ou ONP en France. Qu'est-ce qui est plus crédible et professionnel ? De donner une date dont on sait qu'elle a de fortes chances d'être complètement fantaisiste, ou de dire "je ne peux pas dire quand le gros problème sera résolu, mais je peux le découper en petits sous-problèmes qui deviendront estimables au fur et à mesure de la réalisation des précédents" ?

Ce que dit l'auteur du post, c'est que c'est impossible d'estimer de manière fiable toute tâche de développement dépassant quelques heures. C'est inhérent à la nature de ce qu'on produit. On prend donc le problème par le mauvais bout en forçant les développeurs et chefs de projet à donner des estimations à échéance longue pour satisfaire le client. Un logiciel est un type de produit à part, incomparable à tout ce qu'on a connu jusque là. Il faut inventer de nouvelles façons de le vendre au client.

[Laurent 1973]

Ce que dit l'auteur du post, c'est que c'est impossible d'estimer de manière fiable toute tâche de développement dépassant quelques heures. C'est inhérent à la nature de ce qu'on produit. On prend donc le problème par le mauvais bout en forçant les développeurs et chefs de projet à donner des estimations à échéance longue pour satisfaire le client. Un logiciel est un type de produit à part, incomparable à tout ce qu'on a connu jusque là. Il faut inventer de nouvelles façons de le vendre au client.

Oui, on travail sur des produits qui finalement ne seront jamais fini.
On le livre à un moment donné au client, mais on sait que:

• il reste quelques bugs
• il manque quelques fonctionnalités
• tels ou tels interfaces serait à refaire
• il y a un peu de lenteur dans tels ou tels traitements
• ...

Contrairement à d'autre industrie, le produit que l'on livre n'est pas fini.
Je dis pas qu'une voiture ou une machine à laver n'a pas de défauts, mais une fois livré, le produit répond correctement à un cahier des charges.
Chez nous ce n'est pas le cas, parce qu'un cahier des charges d'un produit informatique est forcément incomplet et donc sans sens.

Et donc, c'est logique que l'on puisse pas assurer une date de fin d'un produit jamais fini.
Mais on continu de vouloir avoir a tout pris un cahier des charges précis dès le début et une estimation précise pour tous ce rassurer.
Ben ça marche pas en informatique parce que nous ne sommes pas une industrie de production (avec une chaîne de fabrication) mais une industrie de conception (avec des cerveaux)

Par contre, on peux annoncer : tel jours je vous livrerai.
Mais on ne peux pas annoncer précisément quoi.

[astyan42]

Il croit que le métier de business analyst est superflu, dans la mesure où les développeurs devraient parler directement aux clients

Pour être honnête, je suis pas tout à fait d'accord avec ça quand on parle d'une boite qui a une taille respectable. Une équipe, c'est pas que des developpeurs, on a beosin de l'équipe de produit qui saura nous synthétiser les besoins clients, nous définir les priorités en fonction des clients. Sinon tant qu'on y est, pourquoi le développeur ne serait pas aussi commercial ? Pour en revenir au sujet initial, je pense que c'est un métier à part et que a partir d'une certaine taille ce poste devient indispensable.

[hotcryx]

Un patron avec un téléphone, un email et un tableur est un patron heureux.
Si en plus il peut avoir un baton comme dans certains pays, là c'est le panard

Va lui expliquer que t'as appris du Jquery, bootstrap, ajax pour l'application mais que tu as probablement 2 semaines de retard, là il va te regarder comme ça

[landry161]

Chez nous il y a un proverbe qui dit un enfant au dos ne sait pas que la route est longue.

[bac_a_sable]

Il y a CP et CP; malheureusement bien souvent il y a aussi un CP chez le client; du coup la demande fait:
Moi->mon CP->CP client->Technicien client->CP client->mon CP->moi

Dans ce schéma, la réponse qui revient n'a bien souvent plus rien à voir avec la demande initiale et elle a mis deux jours à arriver.
Et on est reparti pour deux jours pour redemander la même information... et le délai n'a pas bougé

[hubertcharles]

Il y a différents niveaux de compétences tant pour les CP et les analystes que pour les programmeurs.
Si après quelques mois ou quelques années de maintenance un programmeur peut se débrouiller seul, c'est rarement vrai pour un nouveau projet, surtout si on travaille dans une SSII et qu'en changeant de client on change de domaine d'activité.
Le passage de programmeur à analyste ne va pas de soi, et j'en parle d'expérience.
Trop d'analystes ou prétendus tels n'approfondissent pas leur étude et le programmeur doit se débrouiller comme il peut.
Un analyste digne de ce nom doit être capable de poser les bonnes questions aux utilisateurs et faire un bon dossier sans tomber dans le travers de faire une analyse "technique" avant la lettre. Le document peut alors être programmer en Inde ou ailleurs sans problème. Personnellement j'ai eu le cas et ce fut même le meilleur projet de ma carrière parce que conscient de la difficulté, la hiérarchie nous a donné le temps nécessaire à un travail soigné.

[phanpile]

Tout d'abord je ne suis pas tellement d'accord sur le fait qu'une bonne note à un examen de test de compétences ne serait pas en rapport avec la capacité réelle sur le terrain. Si c'est le cas c'est l'examen qu'il faut revoir.

On ne va pas ici développer une théorie de ce qu'est une évaluation de compétences. Mais en résumé, si l'on souhaite mettre une note à quelque chose ou à quelqu'un au sein d'un groupe de choses ou de personnes comparables (les frigos, les services bancaires, les dentistes, les développeurs, les directeurs financiers, ...), on définit un contexte, des tests et une méthode d'évaluation ; on explique clairement tout ça et ensuite on applique.

Ce n'est pas nouveau. Les examens scolaires, les évaluations annuelles dans les sociétés, les tests de matériels ou même de services dans les magazines de consommateurs, tout est basé sur la même logique. Et effectivement, certaines entreprises l'ont mis en place en interne avec des tests techniques lors du recrutement. Ce qui prouve que ce n'est ni nouveau ni extravagant.

L'idée serait juste de le sortir de l'entreprise A ou B pour en faire quelque chose de plus universel. Du coup cela pourrait aider à la promotion des développeurs.

Plus facile à dire qu'à faire, bien sûr. Pas la peine de me lister tout ce qui pose problème là dedans ...

Toutefois, pour illustrer cela en reprenant l'exemple du TOEIC :
- Tout le monde a le même examen dans quasiment les mêmes conditions
- On s'abstrait des problématiques techniques (au téléphone, dans la rue, par écrit ...)
- On s'abstrait des problématiques métier (ce n'est pas de l'anglais technique par exemple)
- On s'abstrait des problématiques culturelles (ce n'est pas du Shakespeare, ni de l'argo New Yorkais)
- etc.
Et à la fin on a quand même quelque chose qui fait sens. Avec mes 780, je parle bien moins couramment que quelqu'un qui a 950. On peut le tourner dans tous les sens (oui, mais c'était la nuit, il y avait du bruit au téléphone, bla bla bla), à la fin cela reflète la réalité.

Le TOEIC est un exemple intéressant car il se trouve que les grandes entreprises ont souvent accepté de payer pour ce test au cours des dernières années au lieu de se baser (ou en complément de) sur des estimations ou impressions de RH, de supérieurs ou de collègues (plus ou moins doués en anglais eux-mêmes) et il est de ce fait devenu un standard.

De plus, un maçon ou un carreleur peuvent vous montrer les photos de leurs réalisations ou même vous faire visiter. Un fabricant de matériel peut se baser sur de multiples tests, avis et évaluations. Mais sauf évaluation personnelle et ciblée le talent ou les faiblesses d'un traducteur d'anglais ou d'un développeur sont invisibles.

Ceci hormis bien sûr quelques réalisations extraordinaires personnelles (d'accord Steve Wozniak et Mark Zuckerberg sont doués en programmation, pas besoin de test)

A suivre ...

[Laurent 1973]

Petite question sur l’évaluation (un peu taquine)

Comment évaluerais tu alors, dans ta logique, un artiste?
L'art est par définition assez relatif, or on a besoin d'artiste aussi dans les entreprises.

Déjà, pour rester dans nos domaines informatique, comme définir qu'un infographiste est bon?
Pourtant, la réussite de bon nombre de produit informatique (d'autant plus vrai dans les jeux) dépendant d'un bon graphiste.
"angry birds" aurait pu fait un gros flop si le graphiste n'avait pas été à la hauteur, parce que si on réfléchi bien, le jeu est un simple casse brique

Comment identifier la créativité? l'innovation.?
Est ce qu'un développeur n'est qu'un technicien de l'informatique?

[el_slapper]

+1 avec Laurent 1973, évaluer une compétence de suivi de process est faisable par un process. L'Anglais, après tout, n'est qu'un process de communication, que l'on connait, ou que l'on ne connait pas. On peut faire le score max au TOEIC, ça ne fait pas de nous des Shakespeare.(et pareil pour les autres langues, hein, je ne tape pas sur l'anglais).

Quand mon chef vient me voir en me disant "on a un problème, on a oublié de faire un programme, on avait compté 10 jours, tu en as 2", aucune compétence technique mesurable ne peut me permettre de m'en sortir. Par contre, en étant créatif, je peut trouver des chemins de traverse et faire une solution complète, modularisée, lisible et maintenable en 2 jours. Mais ça nécessite que je trouve tout de suite une solution pour faire autrement que ce qui est fait d'habitude - et qui avait été le prélude au chiffrage initial.

Aucun test ne peut mesurer ça.

On peut parfaitement mesurer mon degré de connaissance de la syntaxe COBOL(que nous utilisions sur ce sujet), mesurer ma capacité à comprendre les règles d'un langage que je ne connais pas encore(ce que ma boite actuelle m'a fait faire, vu qu'ils utilisent un langage exotique, ça se tient), ou encore mesurer ma résistance au stress. Mais pas ma capacité à trouver un moyen de résoudre un problème que l'auteur du test n'a jamais rencontré. Ça, c'est de l'art, et c'est forcément subjectif. Et c'est le quotidien d'un paquet de développeurs. J'ai du faire preuve de qualités artistiques(dans le sens "capacité de création novatrice") dans à peu près la moitié de mes missions en SSII, et chez mon éditeur de logiciel actuel. Je ne pense pas être un hasard, ou une exception. C'est la norme. Mes collègues, autour de moi, régulièrement, font face à des problèmes jamais défrichés, et ceux qui sont bons trouvent des solutions novatrices et efficaces. Et tant qu'on ne les a pas vu faire, on ne sais pas si ils sont bons. Et comme c'est de l'art, en plus, c'est un peu aléatoire - la créativité n'est pas quelque chose de systématique.

[Saverok]

On peut parfaitement mesurer mon degré de connaissance de la syntaxe COBOL(que nous utilisions sur ce sujet), mesurer ma capacité à comprendre les règles d'un langage que je ne connais pas encore(ce que ma boite actuelle m'a fait faire, vu qu'ils utilisent un langage exotique, ça se tient), ou encore mesurer ma résistance au stress. Mais pas ma capacité à trouver un moyen de résoudre un problème que l'auteur du test n'a jamais rencontré. Ça, c'est de l'art, et c'est forcément subjectif. Et c'est le quotidien d'un paquet de développeurs. J'ai du faire preuve de qualités artistiques(dans le sens "capacité de création novatrice") dans à peu près la moitié de mes missions en SSII, et chez mon éditeur de logiciel actuel. Je ne pense pas être un hasard, ou une exception. C'est la norme. Mes collègues, autour de moi, régulièrement, font face à des problèmes jamais défrichés, et ceux qui sont bons trouvent des solutions novatrices et efficaces. Et tant qu'on ne les a pas vu faire, on ne sais pas si ils sont bons. Et comme c'est de l'art, en plus, c'est un peu aléatoire - la créativité n'est pas quelque chose de systématique.

La capacité à résoudre un problème n'est pas de l'art, c'est de la logique.
La logique, ça se mesure également.
De même que la qualité du résultat obtenu (temps de réalisation + qualité du code + perf + robustesse + taux de couverture des besoins métier etc, etc, etc)

L'art est subjectif et ne se mesure pas.

Le job de développeur est un job technique mais s'il fait appel à énormément d'abstraction, cela reste technique.
Cela n'a rien de péjoratif tant il est de haute complexité.
On peut donc parler de haute technicité (mais technique tout de même ).

[el_slapper]

La capacité à résoudre un problème n'est pas de l'art, c'est de la logique.
La logique, ça se mesure également.
De même que la qualité du résultat obtenu (temps de réalisation + qualité du code + perf + robustesse + taux de couverture des besoins métier etc, etc, etc)

L'art est subjectif et ne se mesure pas.

Le job de développeur est un job technique mais s'il fait appel à énormément d'abstraction, cela reste technique.
Cela n'a rien de péjoratif tant il est de haute complexité.
On peut donc parler de haute technicité (mais technique tout de même ).

Pas d'accord. On a beaucoup de technique, certes, mais ça ne suffit pas. Je connais la technique pour mapper un fichier, bon, j'en ai 18 à mapper, j'en fait 18! En fait non, j'en reviens à mon exemple, j'ai créé ex-nihilo une structure complète, non répertoriée, qui encapsulait les 18 mappings en question. Ce n'est pas (enfin, pas seulement), de la technique. C'est de la création.

La capacité à résoudre un problème connu, ça se mesure. Construire un tunnel sous la manche, ça a été fait, on sait que c'est faisable, on sait comment les précédents on fait, donc si il faut le refaire, on pourra dire "c'est de la technique". Poser un composant de 40 tonnes sur Mars(nécessaire pour y poser des humains), on ne sait pas faire, et trouver un moyen de le faire, ça sera de la création.

Ma petite moulinette n'est évidemment que poussière en comparaison. Mais chaque jour, des milliers de collègues sont confrontés à des problèmes pour lesquels il n'existe pas de solution répertoriée, et il faut en créer une. Ou alors la solution répertoriée n'est pas satisfaisante, et il faut en trouver une autre. Ce n'est pas juste de la technique. ce sont rarement de grandes inventions(je n'en ai aucune à mon actif), mais ce sont des inventions quand même, et un collègue qui connait bien la technique, mais n'a aucune imagination, ne saura pas s'en sortir.

[DonQuiche]

Tout d'abord je ne suis pas tellement d'accord sur le fait qu'une bonne note à un examen de test de compétences ne serait pas en rapport avec la capacité réelle sur le terrain. Si c'est le cas c'est l'examen qu'il faut revoir.

Pour commencer tu pars du principe qu'il est possible de mettre au point un bon indicateur pour n'importe quoi. Ce qui est faux.

Ensuite partant du principe que toute quantification de ce genre est affectée d'une marge d'erreur tu dois vérifier si celle-ci est compatible avec l'usage qui en est fait et sinon reconsidérer le protocole qui requiert cette quantification.

Enfin tu peux éventuellement avoir recours au cerveau humain, c'est à dire à une machine capable d'analyser des milliers de paramètres flous pour en tirer une évaluation. Dans de nombreuses situations réelles cela reste pour l'instant une approche plus fiable que n'importe quel algorithme.