Discussion :

[Michael Guilloux]

Programmation : 7 choses que votre patron est censé savoir à propos du développement de logiciel
selon un bloggeur

Si le programmeur est au centre du développement de logiciel, le projet peut toutefois faire intervenir d’autres métiers qui doivent collaborer pour sa réussite. Malheureusement, de tous les acteurs qui interviennent dans le projet, excepté le développeur lui-même, personne ne connaît vraiment les réalités du terrain. Chaque décision prise à quelque niveau que ce soit et chaque acteur intervenant dans le projet peuvent avoir un impact majeur sur la qualité du produit final. Pour éviter ce problème, un bloggeur du nom de John Sonmez a dressé une liste de sept réalités que tout superviseur de développeur est censé savoir à propos du développement de logiciel. Le premier point concerne la dette technique.

La dette technique est le premier facteur de ralentissement du projet

Dans un projet, un développeur peut être poussé à coder de manière non optimale (non-respect de la conception logicielle, non-respect des règles de codage, etc.) pour aller plus vite, à la demande de son patron ou pour respecter un planning trop serré. Cela induit des coûts supplémentaires dans le futur (un peu comme des intérêts). En voulant aller vite, les développeurs contractent en effet une dette technique qu’ils doivent rembourser tout au long de la vie du projet sous forme de temps de développement de plus en plus long et de bugs de plus en plus fréquents. Au final, la contrainte d'aller vite n'a réussi qu'à ralentir le projet.

Soit on fait de la qualité, soit on va vite ; on ne peut pas poursuivre les deux objectifs à la fois

Cette deuxième réalité a un point commun avec la première. Sonmez estime que le développeur n’a pas le choix lorsqu’on lui demande d’accomplir dans un bref délai une certaine tâche. Lorsqu’il est sous pression, le développeur utilise certains raccourcis et le résultat est un travail bâclé, un grand désordre parfois. Il laisse en plus une dette technique pour tous ceux qui devront poursuivre le projet. Pour éviter ce problème, le bloggeur suggère de montrer au patron que « vous pouvez le faire soit bien, soit rapidement », avec par exemple des statistiques ou études officielles à l’appui.

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

Le matériel est l’un des meilleurs investissements pour le programmeur, même si cela lui permet de gagner seulement une demi-heure de travail par jour. Malheureusement, beaucoup de patrons négligent encore cela selon Sonmez. Pour ne pas que sa productivité soit remise en cause, le bloggeur estime que le développeur doit insister sur la nécessité d’avoir du matériel performant, ou si possible chercher un autre emploi où son manager sera plus avisé à ce sujet.

Les nouvelles technologies ne sont en général pas aussi risquées que certains le pensent

De nombreuses entreprises restent attachées à leurs vieilles technologies estimant qu’il est risqué d’adopter les plus récentes, mais elles n’ont pas toujours raison. Dans le cas d’un framework ou d’une bibliothèque par exemple, une ancienne version peut introduire certaines vulnérabilités. Passer aux nouvelles technologies peut donc être le choix le plus judicieux.

« Certains développeurs peuvent réellement produire moins que 0 code »

Dans une équipe, les compétences varient d’un développeur à l’autre, mais les membres de l’équipe doivent se compléter et faire en sorte que chaque ligne de code écrite par chacun d’entre eux puisse permettre de résoudre un problème, pas d’en créer un autre de plus. Certains développeurs peuvent être d’une incompétence qui saute aux yeux. Dans ce cas, notre bloggeur suggère qu’il faut le faire savoir au patron, sinon l’incompétence du collègue pourrait être considérée comme la vôtre également.

Les estimations sont inutiles

Une chose que Sonmez croit et qu’il estime que même les meilleurs managers pourraient ne pas savoir, c’est que les estimations qui se projettent au-delà de deux heures dans le futur sont sans valeur. Il explique cela par le fait que presque chaque projet représente un territoire pratiquement inexploré, et que l'imprévu peut se produire à tout moment. Si les superviseurs veulent toutefois faire des estimations, les développeurs devraient soit tenter de les convaincre que cela n’est pas utile, soit insister sur un découpage très fin des tâches de sorte que les estimations ne couvrent que de courtes périodes.

Les analystes d’affaires et les chefs de projet ont-ils encore leur place dans un projet de développement de logiciel ?

Là où le bloggeur s’est montré radical, c’est au sujet de la place qu’occupent les analystes d’affaires et les chefs de projet dans le développement de logiciel. Sonmez reconnaît avant tout qu’il y a absolument des analystes et chefs de projet efficaces, mais il estime que dans la plupart des cas, ils ne sont pas vraiment utiles. Il voit plutôt ces métiers dans un contexte où « tout le monde faisait du développement en cascade et les développeurs ne parlaient pas aux clients directement » et en plus où on avait « besoin de quelqu'un pour créer un énorme diagramme de Gantt », explique le bloggeur.

Il croit que le métier de business analyst est superflu, dans la mesure où les développeurs devraient parler directement aux clients. Il estime qu'il serait plus avantageux pour le client comme pour le développeur, s'il n'y avait aucun intermédiaire entre les deux parties. Il considère le métier d’analyste comme un métier boiteux qui fait une moitié du travail du développeur, mais qui ne peut pas faire l’autre moitié. En ce qui concerne les chefs de projet, Sonmez pense que les patrons devraient savoir que ceux-ci n’ont pas leur place dans un monde Agile, parce qu’au final, ils finissent par se mettre sur le chemin de tout le monde en voulant se montrer importants.

Source : Simple Programmer

Et vous ?

Que pensez-vous de 7 réalités que les patrons devraient savoir selon le bloggeur ?

[Jarodd]

C'est plein de bon sens. Mais c'est utile de répéter ce qui paraît évident car quand on a la tête dans le guidon, on oublie l'essentiel.
J'envoie de suite ce billet à mon chef de projet qui fait l'inverse de tous ces conseils

Pour éviter ce problème, le bloggeur suggère de montrer au patron que « vous pouvez le faire soit bien, soit rapidement », avec par exemple des statistiques ou études officielles à l’appui.

Ca aurait été sympa de sa part de nous donner des statistiques ou des études officielles. Ce blogueur nous rappelle l'évident et nous laisse chercher ce qui est difficile à trouver...

[NSKis]

Le patron sait une seule chose et cela lui suffit amplement:

Tu peux disposer de développeurs en Roumanie, Pologne, Ukraine et Macédoine (pour parler du continent européen) pour un salaire minimalesque et je ne parle pas des nombreuses sociétés européennes qui ont délocalisé leur développement info en Inde ou au Vietnam (en comparaison le smicard passe pour un roi du pétrole!!!)

Les autres points, il s'en balance...

[Kearz]

Dans ce cas, notre bloggeur suggère qu’il faut le faire savoir au patron, sinon l’incompétence du collègue pourrait être considérée comme la vôtre également.

C'est surement pas au collègue de juger ça. Potentiellement un audit, un N+1 (CP technique, lead dev) mais surement pas un collègue.

Le patron sait une seule chose et cela lui suffit amplement:

Tu peux disposer de développeurs en Roumanie, Pologne, [...]

S'il le savait vraiment et savait vraiment mettre au point ce genre d'offshore, on serait tous au chômage ou presque.
C'est comme la fabrication en chine, beaucoup d'entreprise on fait marche arrière avec les sur-coûts (transport, etc) et délais. C'est pareil, faire du offshore, même en informatique, il y a de coût caché.

S'il voulait vraiment réduire les coûts par le changement de la main d'oeuvre, ils commenceraient par offrir plus de poste de développeur au bac+3.

[DarkBakura]

Dans une équipe, les compétences varient d’un développeur à l’autre, mais les membres de l’équipe doivent se compléter et faire en sorte que chaque ligne de code écrite par chacun d’entre eux puisse permettre de résoudre un problème, pas d’en créer un autre de plus. Certains développeurs peuvent être d’une incompétence qui saute aux yeux. Dans ce cas, notre bloggeur suggère qu’il faut le faire savoir au patron, sinon l’incompétence du collègue pourrait être considérée comme la vôtre également.

Bien sûr, oui. Encourageons la "délation", surtout si il y a de la diffamation dans le lot. Si X n'aime pas son collègue Y, qu'est-ce qui l'empêcherait, en raisonnant ainsi, d'aller voir le boss pour lui dire "Y est mauvais, il fout la merde dans le code" ? Même si prouver l'inverse n'est pas si compliqué, bonjour l'ambiance et la collaboration au sein de l'équipe et du management après ça.

Bref, tout ça pour dire que ce genre de conseil est assez idiot, et en dehors de la réalité. Un mauvais développeur n'a pas à être balancé par ses collègues. C'est son supérieur qui s'en rendra compte par lui-même.

Pour le reste, c'est assez logique, sans doute évident pour beaucoup d'ailleurs. Mais j'aime particulièrement le point sur les estimations, qui est malheureusement aussi juste qu'ignoré par la grande majorité des managers (du moins, pour ce que j'ai pu voir évidemment, je ne prétends pas que c'est une vérité absolue).

Par contre :

Situation vécue récemment. C'est à la limite du supportable parfois. Autant le CP est utile pour centraliser les demandes du client, autant en réunion ou en démo, il veut trop "se montrer", coupe la parole, alors que souvent il ne connait pas mieux la demande du client que toi (car entre le temps où il te la transmise et le moment où tu l'a concrétisée tu as contacté le client pour avoir plus d'infos)

Je te comprends parfaitement si tu as dû supporter un chef de projet qui voulait se faire saucer au détriment du bon déroulement de vos réunions, mais il est par contre anormal que ce soit à toi (puisque je suppose que tu es développeur) ou à tes collègues de contacter le client. Comme tu l'as justement souligné, c'est le rôle du chef de projet que de centraliser les questions de son équipe pour les soumettre au client, dont il retournera les réponses. En théorie (même si je suis conscient que dans la pratique il peut y avoir des exceptions), le développeur n'a pas à contacter le client, et doit justement laisser le soin au chef de projet de faire passer ses questions quel que soit le moment du projet. S'il ne le fait pas, alors ce n'est pas "vraiment" un chef de projet, d'où les autres problèmes que tu as dû rencontrer.

[Laurent 1973]

Comme tu l'as justement souligné, c'est le rôle du chef de projet que de centraliser les questions de son équipe pour les soumettre au client, dont il retournera les réponses. En théorie (même si je suis conscient que dans la pratique il peut y avoir des exceptions), le développeur n'a pas à contacter le client, et doit justement laisser le soin au chef de projet de faire passer ses questions quel que soit le moment du projet. S'il ne le fait pas, alors ce n'est pas "vraiment" un chef de projet, d'où les autres problèmes que tu as dû rencontrer.

Je suis pas tout a fait d'accord avec toi.

Pourquoi avoir un intermédiaire entre le développeur et l'utilisateur quand on a une question pointu?
Si au contraire ces 2 personnes se parlent (voir même se rencontre sur le lieu d'utilisation) les différents détails ou flou de spécification peuvent être levé bien plus rapidement.

D'avoir un CP ou un responsable quelconque qui face ce travail va forcement filtrer, épurer, simplifier l'information nécessaire (le plus souvent de façon involontaire, un CP est aussi un humain).
Rien ne remplacera le contact direct.

Par contre, là où je te rejoins, les développeurs ne doivent pas être dérangé par le client qui va vouloir tel ou tel correctif/amélioration pour hier ou utiliser le développeur comme hotline de support.

[smarties]

S'il voulait vraiment réduire les coûts par le changement de la main d'oeuvre, ils commenceraient par offrir plus de poste de développeur au bac+3.

Même un bac+2 sortant d'IUT suffirait. Il faudrait juste quelques développeurs expérimentés dans l'équipe pour guider le nouveau venu.

[phanpile]

Moi même ex développeur, analyste, CDP, etc, je m’apprêtais à poster une réponse aux développeurs sur la nécessité d'une structure car je n'avais lu que les premiers commentaires de développeurs disons ... libertaires ...

Il me semble que réponse leur a été donnée sur ce point car il est nécessaire de centraliser la connaissance, le planning, l'organisation et les décisions, de prévoir et de capitaliser (voir en particulier les réponses de Saverok et _skip). Ceci ne peut être fait que par un CP (ou une équipe dédiée selon la taille du projet).

Pour répondre à Laurent_1973 au sujet de la connaissance du métier du client, les développeurs n'ont pas forcément à être laissés dans l'ignorance, mais dès que l'on a une équipe de plus de 3 personnes, si tout le monde doit être au courant de tout, plus personne n'a le temps de travailler.

Concernant le rôle centralisateur de connaissance du CP : il est effectivement dilué dans le cas des méthodes agiles, mais pas supprimé pour autant : quelqu'un doit faire l'inventaire, le suivi et garder vivant l'ensemble des décisions prises.

Enfin, pour tous les développeurs incompris et brimés, ils pourraient peut être tenter de raisonner par l'absurde :
Supposons 10 développeurs dans une pièce travaillant sur un projet pour un client sans structure au dessus : que se passerait il lorsque le client appellerait pour connaitre sa date de livraison, pour demander une modification non pas dans un écran ou une règle de gestion précise mais dans l'organisation d'un processus transverses ? Que se passerait il lorsque le client demanderait : combien cela me couterait-il de passer mon produit de SQL Server à Oracle ? (ou l'inverse), etc. etc.
Dans tous ces cas et bien d'autres, le développeur est bien heureux de pouvoir "renvoyer au dessus", et éventuellement montrer du doigt ensuite quel chef d'équipe, architecte, scrum master, cp, commercial, patron ... a fait une mauvaise réponse ou une mauvaise évaluation ...


Je ferais toutefois deux remarques complémentaires :
Concernant la qualité : ce qui est dit au départ n'est pas faux : on ne peut pas faire bien et vite et si on fait mal au départ, ce sera plus cher ensuite. Ceci est vrai mais se heurte à une réalité que l'industrie informatique, ses RH et les développeurs eux-même ont du mal à gérer : cela dépend de la capacité du développeur à produire du code de qualité (il existe aussi des développeurs qui font lentement et mal - si, si, je vous assure, j'en ai rencontré) et ouvre donc à ma réflexion sur le statut du développeur.

Concernant le statut du développeur, il y d'abord un aspect culturel : au moins en France (il me semble que c'est moins vrai par exemple aux Etats-Unis), rien ne ressemble plus à un programmeur qu'un autre programmeur. Et un programmeur de 45 ans est souvent vu comme un informaticien qui n'a pas réussi à devenir CP.

Toutefois, les services RH (qui eux non plus ne sont pas forcément des fainéants incompétents), s'ingénient dans toutes les grandes boîtes à inventer des notations et classements pour les collaborateurs afin de mieux les employer et/ou les faire progresser (parfois de les punir). Les notions retenues dans ce cadre sont en général les capacités d'organisation pour soi ou les autres, le suivi des consignes, le sérieux, la motivation, la capacité de négociation, de management, etc.

Lorsque l'on cible plus précisément l'activité de développement, on peut au mieux parler :
- d'expertises (Formations, parfois certifications ...)
- d'expériences (Pratiques et durées)
Et des notions suivantes, qui remontent rarement en l'état du CP au RH :
- la tenue des délais (qui n'a pas forcément de sens suivant la complexité cachée ou la qualité produite)
- le taux de retour d'anomalies (dans certains cas)
- l'estimation des CP (il est bon, il va vite, ou l'inverse)
Mais pas grand chose - toujours à ma connaissance - permettant de mesurer réellement la qualité de programmation d'un développeur par rapport à un autre, soit dans une même société, soit même world-wide et il est certain que l'expérience ne fait pas tout.

Toutes les inventions des 20 dernières années que ce soit pour la réalisation (L4G, frameworks divers), ou en évaluation (analyse de code style CAST, méthodes ISO, CMMI, outils de tests ...) s'inquiètent de la qualité d'un développement logiciel global (même si par la bande, on peut parfois relier la qualité de réalisation d'un module à son programmeur).

Il me semble que si l'on voulait promouvoir la qualité logicielle au niveau le plus bas (forcément nécessaire), il faudrait pouvoir évaluer sérieusement la capacité d'un programmeur à un instant t à produire du code de qualité - soit au niveau algorithmique soit en lien avec un ensemble de technologies.

Il me semble que les encadrants seraient ainsi aidés dans leur boulot d'affectation de tâches, et que les programmeurs eux-même y gagneraient eu leur permettant de se positionner par rapport à leurs collègues (je suis très bon ici, je dois me former ou faire des efforts là, je ne souhaite pas intervenir dans ce domaine ...). Une telle évaluation leur permettrait aussi de pouvoir se positionner dans une grille de rémunération et de capacité d'intervention qui se fait beaucoup "au jugé" à l'heure actuelle, que ce soit dans l'entreprise, le service ou sur le marché free-lance.

Les autres métiers sont notés sur des ressentis mais aussi sur des grandeurs mesurables (pour un commercial par exemple : nombre de prospects, de signatures, CA généré, etc). Pourquoi ne pourrait on pas faire de même avec un programmeur ? La tenue des délais et le taux de retour d'anomalies ne sont à mon avis clairement pas suffisants, il faut aller voir "ce qu'il y a dans la boite".

Ceci se heurte à une problématique pratique d'évaluation : la qualité d'écriture d'un composant logiciel est parmi les plus difficile à évaluer (encore plus qu'un composant électronique ou qu'une pièce manufacturée, de qualité mesurable, pouvant parfois même être perçue à l'oeil nu), et ce en particulier parcequ'en dépit des myriades de frameworks ou méthodes disponibles, chaque module de code est une pièce unique. Je n'ai pas trouvé mieux que la relecture de code pour ça, mais c'est irréalisable de façon industrielle et unifiée.

Peut être, parallèlement à la formation pourrait-on organiser dans chaque domaine des sessions d'évaluations annuelles par exemple. Les éditeurs de solutions de formation en ligne pourraient peut être proposer des outils adaptés aux entreprises ou aux programmeurs eux-mêmes. J'ai rapidement vu des outils, mais - toujous à ma connaissance, car je ne passe pas mon temps là dessus - encore rien auquel un programmeur puisse se référer auprès d'un client ou d'un employeur comme un niveau TOEIC d'anglais par exemple.

Enfin, je parie sur le fait qu'un programmeur capable de produire du code de qualité lors d'un examen, en produira aussi en développement. Mais comme cela va en général de pair avec un moindre effort et une satisfaction personnelle supérieure, je pense que c'est raisonnable.

Sur ce, bon développement à tous ...

[Anne Au Nîmes]

Soit on fait de la qualité, soit on va vite ; on ne peut pas poursuivre les deux objectifs à la fois

C'est malheureusement partout pareil, pas que dans le monde de la programmation. Et comme partout, pleins de patrons ne l'ont pas assimilé, surtout ceux qui ne connaissent pas le produit qu'ils vendent et qui sont juste des gestionnaires ou des vendeurs.

Tu peux disposer de développeurs en Roumanie, Pologne, Ukraine et Macédoine (pour parler du continent européen) pour un salaire minimalesque et je ne parle pas des nombreuses sociétés européennes qui ont délocalisé leur développement info en Inde ou au Vietnam (en comparaison le smicard passe pour un roi du pétrole!!!)

Hors Europe, il y a quelques années, c'était Madagascar, également pour d'autres activités commme le SEO. Aujourd'hui, les Tunisiens "arrivent en force".
Moi j'aime bien dire à ces patrons "Vous voulez du pas cher? Aucun problème, vous en aurez pour votre argent!".

Blague à part, cela a aussi un effet pervers : tirer les prix vers le bas, ce qui implique des grosses incompréhensions quand des boîtes qui refusent de s'aligner sortent des prix que ces patrons jugent pharaoniques. Tu as beau leur vendre l'expérience, les méthodes AGILE, les tests, la doc, le suivi... Ils s'en foutent, ils veulent juste "un truc qui marche".

Les estimations sont inutiles [...] les meilleurs managers pourraient ne pas savoir, c’est que les estimations qui se projettent au-delà de deux heures dans le futur sont sans valeur [...] les développeurs devraient soit tenter de les convaincre que cela n’est pas utile, soit insister sur un découpage très fin des tâches de sorte que les estimations ne couvrent que de courtes périodes.

Amen

Les analystes d’affaires et les chefs de projet ont-ils encore leur place dans un projet de développement de logiciel ?
[...] Sonmez pense que les patrons devraient savoir que ceux-ci n’ont pas leur place dans un monde Agile, parce qu’au final, ils finissent par se mettre sur le chemin de tout le monde en voulant se montrer importants.

Situation vécue récemment. C'est à la limite du supportable parfois. Autant le CP est utile pour centraliser les demandes du client, autant en réunion ou en démo, il veut trop "se montrer", coupe la parole, alors que souvent il ne connait pas mieux la demande du client que toi (car entre le temps où il te la transmise et le moment où tu l'a concrétisée tu as contacté le client pour avoir plus d'infos), sans parler souvent du volet technique, où les CP sont souvent à la rue (bien que j'en ai vu qui étaient meilleurs que les membres de leur équipe).

[midonet7]

Situation vécue récemment. C'est à la limite du supportable parfois. Autant le CP est utile pour centraliser les demandes du client, autant en réunion ou en démo, il veut trop "se montrer", coupe la parole, alors que souvent il ne connait pas mieux la demande du client que toi (car entre le temps où il te la transmise et le moment où tu l'a concrétisée tu as contacté le client pour avoir plus d'infos), sans parler souvent du volet technique, où les CP sont souvent à la rue (bien que j'en ai vu qui étaient meilleurs que les membres de leur équipe).

Le mieu c'est que le CP soit un ancien développeur afin de bien jouer le rôle d'intermédiaire entre le client et ses développeurs

[SaiRictus]

C'est marrant ...

J'aurai clairement pu écrire cet article tellement tout ce qui y est dit est vrai !
Dette technique, défauts de conceptions, demandes "pour l'avant veille", ...

J'étais le "techos à la grande gueule" parce que j'étais toujours celui qui disait "non ... pour bien faire les choses et qu'elles soient pérennes il faut un certain temps", ce qui m'a valu "quelques désagréments" (pour rester poli).

Je me souviens notamment d'une modification qu'il fallait faire "de toute urgence" afin d'historiser les actions faites par un utilisateur dans un processus. En fait l'idée était d'enregistrer des dates pour chaque étape du processus et j'essayais d'expliquer au chef produit que c'est une modification qui, pour être bien faite, demandait du temps (ajout d'une table d'étape, ajout d'une table d'historisation) et que même si la solution simple (ajouter autant de champs date -dans la table des processus- qu'il y a d'étapes) serait plus rapide à mettre en place, elle ne serait pas viable sur le long terme (si on décide de rajouter une étape à un processus.

Mais je pourrais citer d'autres exemples.

Le matériel est l’un des meilleurs investissements pour le programmeur, même si cela lui permet de gagner seulement une demi-heure de travail par jour. Malheureusement, beaucoup de patrons négligent encore cela selon Sonmez. Pour ne pas que sa productivité soit remise en cause, le bloggeur estime que le développeur doit insister sur la nécessité d’avoir du matériel performant, ou si possible chercher un autre emploi où son manager sera plus avisé à ce sujet.

où quand ton boss refuse d'acheter une licence ReSharper alors qu'on développe avec Visual Studio et qu'on est plus de 20 développeurs (c'est pas comme ci on est une société d'édition de logiciels)

[el_slapper]

Je ne suis pas totalement convaincu par le "toujours la nouvelle techno". à l'interieur d'une techno, essayer de passer à la dernière version est généralement un bon cas(mais on a connu une exception ici, avec un fournisseur qui lors d'une version, a mis à la benne la fonctionnalité qui rendait son truc tellement utile pour nous. 8 ans plus tard, il l'a remis, mais on a sauté quelques versions). Par contre, sur le choix de la techno proprement dite, c'est plus compliqué. Du vieux qui suffit(suivant ce que l'on fait, hein), ça peut être un choix stratégique futé. A condition d'avoir la dernière version de ce vieux.

Je me souviens d'avoir développé, en 2009, un outillage de lecture-écriture de XML pour COBOL, alors que dans la version la plus récente(qui avait déjà quelques années), ça existait déjà en natif. Là, on était clairement dans du déni de réalité. Le conseil est souvent juste. Mais pas toujours.




Pour le reste, je suis 100% d'accord. Enfin, un bon chef, c'est utile, mais on en trouve pas tant que ça.

[Gunny]

Mouais... Du bon et du moins bon dans cet article. Je passe sur les pubs énormes et le style clickbait.

1. Technical debt slows down a project more than anything else

C'est vrai, mais c'est plus facile à dire qu'à faire... Et ça dépend beaucoup des situations.

2. Estimates are mostly bullshit

C'est plutôt vrai aussi, en général les estimations tiennent plus du voeu pieux que de la prédiction scientifique. Le problème étant que plus on veut estimer précisément, plus on doit se plonger dans la tâche à faire. Ca prend du temps, et au bout d'un moment on finit par commencer à déjà résoudre le problème... Donner une fourchette est un peu plus réaliste
Et c'est sans compter la règle 90-90 : https://en.wikipedia.org/wiki/Ninety-ninety_rule

3. It can be done right or fast

Oui, si on veut un truc bien fait, il faut y mettre le temps et l'argent.

4. Some developers can actually produce less than 0 code

Pas trop d'accord. D'une part, dans mon expérience je n'ai pas rencontré beaucoup de devs réellement incompétents à ce point. De plus je ne pense pas que ce soit une bonne idée qu'un dev aille voir le boss pour dire que tel autre dev est trop nul. Non seulement ça crée des tensions qui ne sont pas nécessaires mais en plus c'est pour ça que l'on a des code reviews et ce genre de chose...

5. Better equipment is one of the cheapest productivity investments you can make

100% d'adccord par contre. Incroyable le nombre d'endroits où on n'a que du matériel pourri pour travailler, avec des écrans minuscules, des machines asthmatiques, un duo clavier/souris en carton-pâte, un bureau Playschool et une chaise inconfortable. Remplacer tout ça par du matériel de qualité coûte relativement peu et augmente dramatiquement la productivité : machine plus répondante, confort de pouvoir afficher plus d'informations à l'écran, moins de problèmes de santé, moins de stress... J'ai vraiment du mal à comprendre que pour autant d'employeurs la question du matos est totalement élaguée.

6. New technologies are usually not as risky as you think

Euh, oui et non. Rester à la pointe de la technologie, c'est très bien et ça évite que le projet reste encroûté et devienne obsolète, et ça permet de pouvoir évoluer rapidement (beaucoup de nouvelles technos apprtent un gain de productivité). Par contre ça a un coût (d'apprentissage, de refactoring, etc.) et un risque : difficile de voir comment une techno bourgeonnante va évoluer. De plus il faut évaluer si on a vraiment besoin du tout dernier framework javascript à la mode... et de choisir le bon, car on a un choix assez monumental sur les nouvelles technos maintenant. Pas toujours évident de s'y retrouver et faire le bon choix.

7. Business analysts and project managers don’t do shit

De mon expérience, ce n'est pas que les chefs de projet ne servent à rien, c'est que beaucoup d'entre eux sont incompétents et/ou n'ont aucune véritable formation. Chef de projet c'est difficile. Bosser avec un vrai bon chef de projet, ça change la vie : ça permet de se concentrer sur le boulot à faire plutôt que de perdre 50% ou plus de son temps à aller à la pêche aux infos et à faire des aller-retours entre 15 personnes différentes. Je n'ai pas envie de gérer des ressources, de faire des réunions d'une demi-journée, de remplir des fichiers excel, de revoir des specs 20 fois jusqu'à ce qu'elles soient finalement correctes, etc. Je suis un dev, mon boulot c'est de faire du dev ! Un bon chef de projet va se charger de tout ça pour que je puisse me concentrer sur les infos vraiment importantes pour bien faire mon travail et produire plus de code, et de meilleure qualité. Je ne demande pas à n'être qu'un pisseur de code et n'avoir aucun contact avec l'utilisateur, bien sûr, mais à avoir le moins de friction possible pour pouvoir faire mon vrai boulot (ce pour quoi je suis payé et qui est décrit dans mon contrat de travail) correctement. Une organisation agile peut évidemment être une autre solution à ce problème, mais c'est pas toujours évident à mettre en place non plus.

[_skip]

Je vais me faire l'avocat du diable parce que pour être moi-même développeur et chef d'équipe, le râbachage de généralités et de stéréotypes sur le développement chez les bloggers me gonfle un peu

J'ai l'impression de relire encore et encore un énième concentré de lieux communs sur la profession. Le développeur, ce grand incompris qui se retrouve à assumer les décisions de supérieurs bornés et incompétents qui se croient à tort plus malins que lui. Ca tourne toujours autour de la même idée, les chefs c'est mal, la hiérarchie c'est mal, <mais insérer une recommandation agile ici> c'est bien... Généralement quand on voit ce genre de pavé, y'a une petite note en bas de page: "Ah et au fait pour savoir comment faut bosser oubliez pas notre super service de coaching Agile à seulement 250$ la demi journée".

Enfin là le profil du mec c'est autre chose

John Sonmez is the founder of Simple Programmer and a life coach for software developers

Ok c'est un coach et il vend des bouquins... A peine différent. Franchement j'aimerais bien que les gars de son genre, les baratineurs et autre consultants agiles laissent un peu les développeurs tranquilles et aillent casser les pieds au monde dans une autre industrie.
Et puis il y a cette remarque :

Il croit que le métier de business analyst est superflu, dans la mesure où les développeurs devraient parler directement aux clients. Il estime qu'il serait plus avantageux pour le client comme pour le développeur, s'il n'y avait aucun intermédiaire entre les deux parties. Il considère le métier d’analyste comme un métier boiteux qui fait une moitié du travail du développeur, mais qui ne peut pas faire l’autre moitié. En ce qui concerne les chefs de projet, Sonmez pense que les patrons devraient savoir que ceux-ci n’ont pas leur place dans un monde Agile, parce qu’au final, ils finissent par se mettre sur le chemin de tout le monde en voulant se montrer importants.

Maaaaiis bien sûr, inutiles car forcément des incapables qui se la jouent ... Même si je suis d'accord qu'on peut trouver des cas de chefs de projets ou d'analystes métier complètement nuls et les monter en épingle. Avoir un projet bien dirigé et une bonne analyse des besoins c'est juste au moins aussi important qu'avoir des bons développeurs pour le réaliser. Si on veut faire des généralités on peut aussi ironiser sur le développeur qui écarte toutes les solutions non-code et qui fait passer la technique (code, framework, etc...) au détriment du fonctionnel.

Pour l'avoir vécu, je suis au contraire intimement convaincu que l'accès direct aux développeurs c'est une erreur. Déjà parce que ces derniers ne peuvent pas être tout le temps interrompus par des demandes clients et du support, faut clairement un filtrage en aval et parce que passé le stade de la start up avec 3 clients et 2 développeurs, on sait plus du tout qui fait quoi. Les interlocuteurs se multiplient, se contredisent, plus personne sait ce qui se passe et on perd en visibilité et en productivité. Clairement pour chaque projet, faut une personne qui a la vue d'ensemble, l'historique, qui connaît les contrats et accords passés avec le client sinon on s'en sort plus.
Ca empêche absolument pas le responsable de projet de consulter les développeurs, de prendre renseignements avant d'engager l'équipe. Il peut y avoir des différences de point de vue mais au bout d'un moment si les développeurs veulent absolument tout faire à leur guise parce qu'ils pensent tout mieux savoir et avoir de mauvais dirigeants, ils ont qu'à monter leur propre entreprise et ils comprendront mieux le problème. J'aime pas cette vision du monde victimaire et stéréotypée qui fait penser à la lutte des classes.

Je passe les autres trucs du style, "les estimations c'est de la connerie (bullshit, c'est dans l'article)". C'est clair qu'on préférerait tous avoir des deadlines infinies et ne s'arrêter que quand on a atteint la perfection, seulement les estimations sont nécessaires pour chiffrer les coûts et organiser les ressources et font partie essentielle de la phase de marchandage avec le client. Sans ça point de début, point de fin, c'est moche mais rien ne peut se substituer à cela, tout le monde ne veut pas travailler sur un modèle "pay per use", on doit forcément pouvoir mettre un ordre de grandeur sur ce qu'on investit. Il y a quasiment aucun projet qui peut se faire sans une estimation, ni construction d'immeuble, route, ligne de chemin de fer. Donc c'est pas de la connerie dont on choisit de se passer ou non, c'est un problème.

[DonQuiche]

Je vais me faire l'avocat du diable parce que pour être moi-même développeur et chef d'équipe, le râbachage de généralités et de stéréotypes sur le développement chez les bloggers me gonfle un peu

J'ai l'impression de relire encore et encore un énième concentré de lieux communs sur la profession. Le développeur, ce grand incompris qui se retrouve à assumer les décisions de supérieurs bornés et incompétents qui se croient à tort plus malins que lui. Ca tourne toujours autour de la même idée, les chefs c'est mal, la hiérarchie c'est mal, <mais insérer une recommandation agile ici> c'est bien... Généralement quand on voit ce genre de pavé, y'a une petite note en bas de page: "Ah et au fait pour savoir comment faut bosser oubliez pas notre super service de coaching Agile à seulement 250$ la demi journée".

Je partage ton sentiment.

Voici un article très divertissant que j'avais lu il y a quelques temps, qui tente d'expliquer le développement logiciel à des exécutifs à travers le point de vue de l'un d'entre eux au fil d'un projet qui déraille. Cela permettra peut-être à certains de se projeter...


What is code ?

For your entire working memory, some Internet thing has come along every two years and suddenly hundreds of thousands of dollars (inevitably millions) must be poured into amorphous projects with variable deadlines. Content management projects, customer relationship management integration projects, mobile apps, paperless office things, global enterprise resource planning initiatives—no matter how tightly you clutch the purse strings, software finds a way to pry open your fingers.

Here we go again. On the other side of your (well-organized) desk sits this guy in his mid-30s with a computer in his lap. He’s wearing a taupe blazer. He’s come to discuss spending large sums to create intangible abstractions on a “website re-architecture project.” He needs money, support for his team, new hires, external resources. It’s preordained that you’ll give these things to him, because the CEO signed off on the initiative—and yet should it all go pear-shaped, you will be responsible. Coders are insanely expensive, and projects that start with uncomfortably large budgets have an ugly tendency to grow from there. You need to understand where the hours will go.

[Luckyluke34]

Ok c'est un coach et il vend des bouquins... A peine différent. Franchement j'aimerais bien que les gars de son genre, les baratineurs et autre consultants agiles laissent un peu les développeurs tranquilles et aillent casser les pieds au monde dans une autre industrie.

Honnêtement, je trouve l'article plutôt dangereux pour son business et d'autant plus courageux de sa part. Un coach/consultant soucieux de ménager ses clients ne dirait pas "les analystes métier et chefs de projet ne branlent rien" dans un article ou shit et bullshit apparaissent tous les 3 mots.

Je passe les autres trucs du style, "les estimations c'est de la connerie (bullshit, c'est dans l'article)". C'est clair qu'on préférerait tous avoir des deadlines infinies et ne s'arrêter que quand on a atteint la perfection, seulement les estimations sont nécessaires pour chiffrer les coûts et organiser les ressources et font partie essentielle de la phase de marchandage avec le client.

Le truc, c'est pour quel résultat au final ? J'ai l'impression que tout le monde fait comme si les projets de dev se terminaient merveilleusement bien avec un client satisfait, mais dans mon expérience c'est vrai dans, peut-être, 10% des cas et encore.

Le dépassement de délai et de budget fait partie des fléaux qui ridiculisent la profession, renforcent la réputation d'escrocs finis des SSII s'il en était besoin, et exaspèrent les donneurs d'ordre, et ça arrive même (surtout ?) quand on a tout estimé au cordeau depuis le départ. Donc on continue avec les mêmes vieilles recettes, c'est à dire échouer et échouer encore dans nos tentatives de donner la juste estimation et au passage flouer le client, ou on essaie de trouver une autre approche ?

Il y a quasiment aucun projet qui peut se faire sans une estimation, ni construction d'immeuble, route, ligne de chemin de fer. Donc c'est pas de la connerie dont on choisit de se passer ou non, c'est un problème.

La construction est une discipline vieille de dizaines de milliers d'années, les routes plusieurs milliers, les chemins de fer 170 ans. On est aux balbutiements du développement de logiciels, qui en plus a la particularité de manier de l'immatériel. Pourquoi s'acharner à vouloir appliquer des méthodes anciennes à une profession aussi radicalement différente ?

[el_slapper]

(.../...)
Le truc, c'est pour quel résultat au final ? J'ai l'impression que tout le monde fait comme si les projets de dev se terminaient merveilleusement bien avec un client satisfait, mais dans mon expérience c'est vrai dans, peut-être, 10% des cas et encore.

J'en ai eu bien plus que ça. Mais avec pas mal de casse quand même. J'ai quand même l'impression que plus un projet est gros, plus sa probabilité de plantage est importante. Tu as cité l'ONP, et je crois qu'on a là l'exemple typique d'un projet qui s'est écrasé sous son propre poids.

Le dépassement de délai et de budget fait partie des fléaux qui ridiculisent la profession, renforcent la réputation d'escrocs finis des SSII s'il en était besoin, et exaspèrent les donneurs d'ordre, et ça arrive même (surtout ?) quand on a tout estimé au cordeau depuis le départ. Donc on continue avec les mêmes vieilles recettes, c'est à dire échouer et échouer encore dans nos tentatives de donner la juste estimation et au passage flouer le client, ou on essaie de trouver une autre approche ?

Mais dans les pays sans SSII, c'est pareil. Des projets internes de grosses boites, Françaises ou étrangères, qui vont dans le décor, j'en ai vu quelques uns. Et aussi des cas ou le client final plantait la SSII par des exigences impossibles("il y a une erreur dans la spec? C'est pas possible, je l'ai validée, elle ne bougera plus d'un iota").

La construction est une discipline vieille de dizaines de milliers d'années, les routes plusieurs milliers, les chemins de fer 170 ans. On est aux balbutiements du développement de logiciels, qui en plus a la particularité de manier de l'immatériel. Pourquoi s'acharner à vouloir appliquer des méthodes anciennes à une profession aussi radicalement différente ?

...et on a encore pas mal de surprises sur pas mal de chantiers. Pas de l'ampleur ou de la fréquence du logiciel, mais quand même.

[_skip]

Honnêtement, je trouve l'article plutôt dangereux pour son business et d'autant plus courageux de sa part. Un coach/consultant soucieux de ménager ses clients ne dirait pas "les analystes métier et chefs de projet ne branlent rien" dans un article ou shit et bullshit apparaissent tous les 3 mots.

Franchement pourquoi pas? Dans beaucoup de pays du monde, les chefs de projets et les analystes métiers sont des employés comme les autres, en plus souvent des employés à plus haut salaire. Du coup un patron est tout content d'entendre qu'il peut se passer d'eux. En plus, ça assure un capital sympathie auprès des exécutants du stage, soit l'équipe de projet en leur disant "On sait ce que vous ressentez, vous avez pas besoin de ces gens qui vous cassent les couilles, émancipez-vous!*. Ceux qui sont visés sont les décideurs qui ont des soucis avec leurs projets informatiques et qui pourraient voir des solutions miracles au niveau de la simple organisation. Donc non il ne scie pas la branche sur laquelle il est assis, sa clientèle type ce sont pas les chefs de projets ou les entreprise où tout se passe bien, mais celles où il y a de l'eau dans le gaz et dont les patrons doutent et s'interrogent sur l'efficacité de leur service IT.

Le truc, c'est pour quel résultat au final ? J'ai l'impression que tout le monde fait comme si les projets de dev se terminaient merveilleusement bien avec un client satisfait, mais dans mon expérience c'est vrai dans, peut-être, 10% des cas et encore.

Le dépassement de délai et de budget fait partie des fléaux qui ridiculisent la profession, renforcent la réputation d'escrocs finis des SSII s'il en était besoin, et exaspèrent les donneurs d'ordre, et ça arrive même (surtout ?) quand on a tout estimé au cordeau depuis le départ. Donc on continue avec les mêmes vieilles recettes, c'est à dire échouer et échouer encore dans nos tentatives de donner la juste estimation et au passage flouer le client, ou on essaie de trouver une autre approche?

La construction est une discipline vieille de dizaines de milliers d'années, les routes plusieurs milliers, les chemins de fer 170 ans. On est aux balbutiements du développement de logiciels, qui en plus a la particularité de manier de l'immatériel. Pourquoi s'acharner à vouloir appliquer des méthodes anciennes à une profession aussi radicalement différente ?

Si tu te plantes sur le délai c'est une chose et ce n'est pas forcément synonyme d'échec, si tu te plantes sur la satisfaction tu as un autre problème bien plus grave. Les estimations sont un problème mais la solution n'est en aucun cas de répondre "Ca prend le temps que ça prend" et donc par extension "ça coûte le prix que ça coûte". Car ça c'est ne prendre aucun engagement ni sur l'aspect financier, ni sur les délais et donc virtuellement ne fournir aucune garantie de résultat. C'est pas acceptable dans le monde de l'industrie.

Si tu as des travaux à faire faire chez toi, tu demandes un devis, tu demandes combien ça coûte.
Tu te renseignes sur le prix, si le mec te répond "c'est 100 euros de l'heure", ta prochaine question c'est "ok vous pensez que ça vous prendra combien de temps", s'il dit qu'il peut pas trop savoir à vue de nez, tu l'invites à venir constater. Et là le type se rend sur place, constate ce qu'il y a à faire, il te donne un estimation du style : "c'est fini quand ce sera fini puis ça prend le temps que ça prendra" ta réponse logique c'est "Ok merci au revoir".
C'est légitime, tu as besoin de savoir quel est ton budget ou du moins d'y mettre un ordre de grandeur, et niveau délai tu as peut être besoin de coordonner diverses entreprises qui ont elles aussi un agenda à tenir?

C'est clair qu'il est difficile de dire, "c'est fini le vendredi 30 juin l'année prochaine", c'est rarement ce qu'on nous demande, à l'impossible nul n'est tenu. Mais définir un semblant de calendrier et donner un ordre de grandeur, on y est tenu. La marge d'erreur est grande mais il existe des solutions pour amortir les chocs, et je ne parle pas seulement de faire des points réguliers et de conserver une bonne communication. Commencer par une bonne analyse est déjà un début et les bloqueurs potentiels devraient apparaître pour la plupart, même s'il reste souvent des doutes. Pour cela il y a une arme sans faille, c'est la réalisation de POCs payantes, les clients sont généralement tout à fait disposés à les accepter, en principe ils savent qu'un projet comporte des risques, il est facile de leur faire comprendre que c'est aussi dans leur intérêt avant d'investir des sommes colossales dans le vide.

Quand dans un projet de construction on a des doutes sur ce sur quoi on va tomber, on fait des études géologiques (payantes) et tout le monde trouve ça normal. Personne ne va dire "les délais et les dépassements nous font chier, on donne pas de délai comme ça on est sûr de les dépasser". C'est aussi ridicule que de dire "je casse le thermomètre puis il fera toujours 20 degrés".

[midonet7]

Certains développeurs peuvent être d’une incompétence qui saute aux yeux.
Dans ce cas, notre bloggeur suggère qu’il faut le faire savoir au patron,
sinon l’incompétence du collègue pourrait être considérée comme la vôtre également.

C'est vrai qu'on trouve dans chaque équipe au sien des entreprises ce genre de développeurs mais les patrons
ne sont pas assez stipudes de ne pas remarquer ces personnes, je pense que tant que le projet
marche bien et que les bons développeurs travail avec 150% pour corriger les erreurs des autres les patrons seront
toujours satisfaits.

[Saverok]

Les estimations sont inutiles

Une chose que Sonmez croit et qu’il estime que même les meilleurs managers pourraient ne pas savoir, c’est que les estimations qui se projettent au-delà de deux heures dans le futur sont sans valeur. Il explique cela par le fait que presque chaque projet représente un territoire pratiquement inexploré, et que l'imprévu peut se produire à tout moment. Si les superviseurs veulent toutefois faire des estimations, les développeurs devraient soit tenter de les convaincre que cela n’est pas utile, soit insister sur un découpage très fin des tâches de sorte que les estimations ne couvrent que de courtes périodes.

Il y a beaucoup à dire sur cet article mais ce point là en particulier me fait bondir !
Quand on travaille en équipe, savoir se synchroniser est indispensable tant sur les interfaces que sur le temps.

Je dirai même que savoir estimer correctement son RAF est un élément déterminant de la qualité d'un développeur.
Il est indispensable de savoir communiquer ce que l'on fait, surtout dans un métier aussi technique que le notre.
Balancé des phrases du genre "ça sera fait quand ça sera fait" est totalement absurde et désastreux en terme d'image sans parler de la planif (qui fait intervenir potentiellement énormément de monde sans parler, dans certains cas, de campagne marketing, d'envoie de courriers par milliers, de formation de plusieurs centaines d'utilisateurs, etc, etc, etc qui ont besoin d'être synchronisés et planifiés de longues dates).

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.