Sondage Quel indicateur de performance pour le développement de logiciel ?

Posté par . Licence CC by-sa.
6
23
fév.
2020

Les démarches qualité (de type ISO 9001) demandent que l’organisation utilise des indicateurs, pour mesurer la performance et ainsi l’améliorer (ou détecter une dégradation).

Pour l’activité de développement de logiciel quel indicateur de performance préférez‑vous ?

  • le nombre de lignes de code modifiées par mois :
    56
    (4.8 %)
  • le rapport entre nombre de tickets traités et temps pour élaborer une version :
    166
    (14.2 %)
  • la complexité cyclomatique :
    78
    (6.7 %)
  • le rapport entre nombre de fonctionnalités testées et temps pour exécuter une campagne de test automatique :
    86
    (7.4 %)
  • le nombre de versions par an :
    38
    (3.3 %)
  • le nombre de commits par mois :
    84
    (7.2 %)
  • le nombre d’œufs de Pâques (easter eggs) dissimulés :
    239
    (20.5 %)
  • le nombre de personnes pour produire ce logiciel en une journée (approche dite neuf femmes pour un bébé dans un mois) :
    73
    (6.3 %)
  • l’évolution de l’écart entre l’existant et ce qui a déjà été vendu par le marketing :
    346
    (29.7 %)

Total : 1166 votes

La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # Le nombre d'œufs de Pâques

    Posté par (page perso) . Évalué à 10 (+17/-0).

    Parce qu'évidemment, si les équipes de développement ont du temps de développer ces genre de choses, c'est que le projet est impeccable, fini, et que tous les bugs ont été corrigés.

    OS préféré Mageia 7, CMS préféré SPIP, suite bureautique préférée LibreOffice, logiciel de dessin préféré Inkscape.

  • # Satisfaction client

    Posté par . Évalué à 9 (+8/-1).

    Car au final ce qui importe vraiment c'est que l'utilisateur soit content, le reste est totalement mineur comparé à cet indicateur.
    Certains appel ça «valeur métier».

    • [^] # Re: Satisfaction client

      Posté par . Évalué à 5 (+3/-0).

      Oui. Est-ce qu'on sait mesurer le contentement de l'utilisateur ? Et comment agréger le contentement de plusieurs utilisateurs (certains contents et d'autres moins) ?

      • [^] # Re: Satisfaction client

        Posté par . Évalué à 3 (+1/-0).

        À la largeur du sourire qui illumine leur visage ?

        Malheureusement il n'y a pas de métrique miracle, la «satisfaction» est un critère relatif, subjectif et complètement personnel. Le mieux est de faire des sondages/enquête de satisfaction, avant et après. S'il y a amélioration alors l'objectif est atteint, sinon …
        La technique de «l'A/B testing» est là pour ça. On test sur un petit groupe bien identifié une fonctionnalité. Si elle plaît on généralise, sinon retour arrière. Bien sûr ces changement doivent être atomique et les plus petits possible.

        Ensuite, on ne peux plaire a tous le monde. Donc les avis contraire il y en aura forcément. Le but du jeu est de jongler avec la chèvre et le chou pour satisfaire tout le monde sans mettre en péril le projet. Mais il arrive (très) souvent que des arbitrages soient fait dans un sens ou l'autre. Ensuite il faut assumer et rester cohérent. Il n'est pas rare que des projets changent 15 fois d'orientation et finisse par se perdre.

        • [^] # Re: Satisfaction client

          Posté par . Évalué à 2 (+0/-0).

          Mais là encore pour satisfaire ton indicateur tu vas rusher des fonctionnalités, laisser passer des trucs mal définis, qui dans le futur vont rendre l'application difficilement maintenable.

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Satisfaction client

      Posté par (page perso) . Évalué à 10 (+8/-0).

      ce qui importe vraiment c'est que l'utilisateur soit content…

      Je préfère cette phrase à "satisfaction du client".
      En effet le client, c'est celui qui passe la commande, éventuellement mon chef hiérarchique. Ce n'est généralement pas l'utilisateur…

      Je me suis toujours plus intéressé à celui qui était devant son écran de façon à simplifier sa tâche et lui rendre service. J'allais souvent et à l'improviste voir travailler les utilisateurs de mon logiciel. Si je voyais une amélioration possible qui me coûtait 2 heures de travail mais qui faisait gagner 5 min par jour à 10 personnes, c'était pour moi une tâche prioritaire car le retour sur investissement se comptait en jours.

      J'ai eu un directeur qui avait jugé essentiel de faire une usine à gaz (des mois de travail) pour éviter un travail d'un jour environ tous les 5 ans. C'est quelqu'un qui croyait bien faire mais sa connaissance du métier était très superficielle. Mais c'était lui le client.

      Le client n'est pas l'utilisateur. Il faut savoir cela si l'on veut éviter les naufrages de grands projets spécifiés par des "responsables" qui ne vont pas l'utiliser.

      • [^] # Re: Satisfaction client

        Posté par . Évalué à 3 (+1/-0).

        Tout a fait d'accord, la différence est souvent oublié en effet.

        On peux même pousser a distinguer le sponsor des autres, celui qui va payer (service achat, budget de la DSI, …). Même s'il est étranger au projet, parfois il y met son grain de sel car «il en veux pour son argent».

    • [^] # Re: Satisfaction client

      Posté par (page perso) . Évalué à 2 (+0/-0).

      Étonnamment au moment où j'écris tu t'es fait moinsser !
      Y en aurait-il pour qui la satisfaction client RÀB ? Nous sommes pourtant tous le client de quelqu'un d'autre !

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

  • # indicateurs de performance ?

    Posté par . Évalué à 10 (+16/-0).

    Beaucoup sont des indicateurs d'activité, et non de performance.

  • # Les ratio clés

    Posté par . Évalué à 6 (+4/-1).

    Il en existe plusieurs:
    -nombre de lignes de code / nombre de ligne de description dans les specs
    -nombre de lignes de code / (temps de réunion interne x temps de réunion avec le client)
    Et bien entendu le père de tous les ratios: nombre de ligne de code / litre de cafés bus

    ------> [ ]

  • # Récursion

    Posté par . Évalué à 10 (+11/-0).

    La somme des coûts marginaux, de mise en place et de suivi, de chaque nouvel indicateur réclamé par la hiérarchie.

  • # Nombre de ticket ouvert pour un véritable bug + nobre de ticket pour une difficulté d'utilisation

    Posté par . Évalué à 5 (+4/-0).

    La qualité d'un logiciel doit ête jugé à la vue des tickets ouverts:

    S'agit il de véritable dysfonctionnement ?
    S'agit il d'un problème d'utilisation ?
    S'agit il d'un problème de design ?

    Dans le monde pro, on peux juger cette qualité par le turn over chez les developpeurs et les consultants

  • # Aucun

    Posté par . Évalué à 8 (+6/-0).

    Aucun des indicateurs ne me semble pertinent à lui seul pour juger du développement. Chaque indicateur proposé ne valide qu'une chose précise. Il faudrait une combinaison des indicateurs proposés pour sortir quelque chose qui soit un minimum pertinent.

    S'il ne faut choisir qu'un seul indicateur, j'aurais choisi l'écart entre le travail planifié et le travail réalisé. Si l'organisation est capable de planifier les travaux à réaliser avec un certain réalisme avant de les réaliser, cela veut souvent dire qu'il y a une certaine maîtrise du travail. Bien évidemment, il y a de nombreux facteurs qui peuvent faire évoluer cette évaluation (ajout d'une fonctionnalité, changement de spécification…). Ce n'est pas spécifique au logiciel mais pourquoi faudrait-il que ça le soit ?

    • [^] # Re: Aucun

      Posté par . Évalué à 10 (+17/-0).

      Le problème des indicateurs c'est que lorsqu'on les met en place, on ne cherche plus à satisfaire les clients, mais les indicateurs.

      • écart temps réalisé, temps estimé ? => on triple tous les temps et on fait la révolution digitale (ie en bon français, se tourner les doigts)
      • Nombre de ligne de code ? => pas de factorisation et duplication de code
      • le rapport entre nombre de tickets traités et temps pour élaborer une version multiplication des tickets pour la moindre modif, correction de modif, analyse… on favorise les évolutions courte et simples
      • le rapport entre nombre de fonctionnalités testées et temps pour exécuter une campagne de test automatique, pareil on favorise certains types d'évols simple a faire/tester
      • le nombre de versions par an : une version par commit ?
      • le nombre de commits par mois : multiplication des commits avant test, puis commit de correction, puis commit post relecture, puis commit de correction post relecture, puis commit de merge/rebase parce qu'avec tout ce temps un collègue à pu faire passer son ticket du mois d'avant ;)
      • le nombre d’œufs de Pâques (easter eggs) dissimulés : perte de temps à développer des trucs inutile.

      Bref certains de ces indicateurs peuvent donner une idée, mais à partir du moment où ils deviennent des unités de mesures, ils deviennent un handicap.

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Aucun

        Posté par . Évalué à 4 (+2/-0).

        La critique est pertinente. Toutes les méthodes employées ont des inconvénients, les "indicateurs" ne sont pas différents. Les processus "qualité" (type ISO 9001) requièrent d'avoir des indicateurs. C'est dans ce contexte que la question du sondage a été posée.

        La critique qu'on pourrait faire serait justement la volonté de satisfaire ces indicateurs. Les indicateurs ne sont pas utilisés comme ils le devraient et c'est pour cela qu'ils peuvent être inutiles voire handicapants.

        • [^] # Re: Aucun

          Posté par . Évalué à 5 (+3/-0).

          D'ailleurs, c'est dans le nom. "Indicateur" ne donne que des indications.

          C'est pas parce que je vois un panneau "Rome" et je veux aller à Rome que je suis obligé de suivre ce panneau. Bon, mauvais exemple : toutes les routes mènent à Rome.

          • [^] # Re: Aucun

            Posté par (page perso) . Évalué à 7 (+5/-0).

            Les processus "qualité" (type ISO 9001) requièrent d'avoir des indicateurs. C'est dans ce contexte que la question du sondage a été posée.

            Et c’est bien le problème des démarches qualité, qui ne peuvent pas réellement mesurer la qualité du travail réalisé et se concentrent donc à l’excès sur la démarche, ce qui se traduit inexorablement par une clarification des processus au détriment de la qualité de la production, puisque le système perd en souplesse et une part considérable de son énergie à évaluer les processus plutôt que ce qui en sort. La consignation des démarches et leur contrôle ont un coût important, souvent largement surestimé car indirect, qui n’est plus utilisé pour la améliorer la qualité de la production.

            De plus, un indicateur, dans une démarche qualité, c’est une mesure intrusive. Dès lors qu’elle est utilisée pour évaluer le système (comme sa performance), elle modifie le système observé, pour lui faire optimiser l’indicateur. Toute personne qui a déjà dû faire des mesures dans sa vie devrait être franchement dubitative devant ces normes et ce démarches.

            Je ne connais pas d’exemple ni dans le public ni dans le privé où la mise en place d’une démarche qualité a fait progresser la qualité elle-même (sauf peut-être la qualité de vie des consultants en démarche qualité). Je suis certain que ça existe. Notamment si qualité de la production est vraiment mauvaise, une amélioration des processus peut potentiellement avoir comme effet de bord aussi une amélioration de la qualité de la production. Mais que ces exemples ne servent pas à justifier une approche qui ne fonctionne pas dans le cas général, et qui pourtant tend à se généraliser partout !

            • [^] # Re: Aucun

              Posté par (page perso) . Évalué à 4 (+1/-0).

              Je ne connais pas d’exemple ni dans le public ni dans le privé où la mise en place d’une démarche qualité a fait progresser la qualité elle-même (sauf peut-être la qualité de vie des consultants en démarche qualité).

              J'approuve. J'ai travaillé dans le secteur contrôle-qualité d'un grand groupe et j'ai pu voir des inepties. La plus grosse concerne un boitier électronique convertissant du 27V= en 5V=. Il y avait dans ce boitier un petit circuit imprimé dont le courant de sortie faisait fondre une piste. Comme il était impossible de faire une piste plus large, on soudait un fil par dessus le circuit juste avant de remplir le boitier de résine. Ainsi le contrôleur ne pouvait pas le voir. C'était le secret de polichinelle.
              Le département Qualité fait un dossier qualité (très épais) pour ce boitier et affiche sa satisfaction. Je demande alors au chef de la Qualité comment ils avaient traité le problème du fil indispensable mais absent du dossier de fabrication. Le chef de la Qualité m'a répondu que ce n'était pas son problème, il voulait juste montrer qu'il savait faire un dossier Qualité.

              J'en ai conclu que pour améliorer la Qualité, il fallait faire du papier en conséquence. Plus le dossier est épais, plus on est sûr que personne ne le lira.

              Il y a quelques bonnes choses dans la démarche qualité mais elle passe à côté de points importants. Par exemple faire juste ce qui est demandé sans se soucier de la suite, alors qu'un tout petit investissement de départ peut donner un logiciel bien structuré maintenable et évolutif.

            • [^] # Re: Aucun

              Posté par . Évalué à 2 (+0/-0).

              La consignation des démarches et leur contrôle ont un coût important, souvent largement surestimé car indirect, qui n’est plus utilisé pour la améliorer la qualité de la production.

              Tu veux dire sous-estimé ? Ou alors je comprends pas ta phrase.

              • [^] # Re: Aucun

                Posté par (page perso) . Évalué à 2 (+0/-0).

                Oui, j’ai reformulé ma phrase et ai gardé le mauvais mot. Je voulais bien dire "sous-estimé".

      • [^] # Re: Aucun

        Posté par (page perso) . Évalué à 3 (+1/-0).

        Un bouquin plutôt bien fait et assez drôle sur le manque d'efficience des indicateurs: "Les Stratégies Absurdes" de Maya Beauvallet ou comment faire pire en croyant faire mieux.
        https://sociocarnot.files.wordpress.com/2013/02/beauvallet-stratc3a9gies-absurdes.pdf

  • # En passant par la Belgique

    Posté par (page perso) . Évalué à 8 (+6/-0).

    Méfiez-vous des observables by Ploum
    Et un petit voyage en Observabilie.

    Un LUG en Lorraine : https://enunclic-cappel.fr

  • # La performance doit-elle être mesurée ?

    Posté par . Évalué à 7 (+9/-3). Dernière modification le 25/02/20 à 18:18.

    La démarche qualité est une fumisterie. Je ne parle pas de l'idée de faire la qualité qui est bien entendu bien plus que louable mais de la démarche qualité. Qu'est-ce que la qualité ? Sur quelle base on l'évalue ? Est-ce qu'un nombre (lignes, commits, personnes, etc.) peut vraiment refléter la qualité ? Bien sûr que non. La qualité est bien trop complexe pour qu'elle s'évalue, sinon sur le retour des utilisateurs (et encore, ça dépend des retours).

    Bref, ça n'est qu'un commentaire ici, ce serait long à détailler et expliquer. Et je rejoins le commentaire rappelant que des lors qu'on pose des indicateurs, on se retrouve à travailler sur ces indicateurs plutôt que sur quoi ils reposent. Je vis ce problème quotidiennement dans mon travail (comme beaucoup d'entre nous). Par ailleurs, il y a une logique derrière ces indicateurs de chiffres, de rentabilité et de profits (la notion de performance au travail se relie souvent à ça) et donc de néolibéralisme/capitalisme. Et à mon sens, l'esprit du libre est le contraire de tout ça.

    Pour la notion de démarche qualité, comment elle est utilisée, le problème et la contradiction même du terme, des indicateurs, sont très bien expliquées (et avec humour en plus) dans les excellentes conférences gesticulées de Franck Lepage (en particulier celle sur le travail qu'il coanime avec son acolyte Gaël Tanguy. Ici la conférence Inculture 5 : "travailler moins pour gagner plus". Elles sont sur Youtube. Je recommande.

    Il y a beaucoup trop d'endroits, d'exemples donc, de lieux où ces "démarches qualité" ont été mises en place, évaluées positivement (au regard des indicateurs) et où, pourtant, la très grande majorité des professionnels décrivent au contraire une dégradation de leur travail : différents services publics comme les hôpitaux, des entreprises…

    En bref, il manque une ligne essentielle sur ce vote : "aucun, ignorer ces normes ISO". Je n'ai donc pas voté.

    • [^] # Re: La performance doit-elle être mesurée ?

      Posté par (page perso) . Évalué à 10 (+7/-0).

      des lors qu'on pose des indicateurs, on se retrouve à travailler sur ces indicateurs plutôt que sur quoi ils reposent.

      Je trouve que c'est le cas si l'entreprise utilise les indicateurs comme des carottes ou sanctions : si tu respectes tel indicateur tu auras des félicitations, ou une prime, ou tu seras bien vu, etc.

      Si ça reste des indicateurs et rien d'autre, je trouve que les gens savent tout à fait s'en servir correctement.

      De toutes manières nous avons chacun nos « indicateurs internes ». Même s'ils ne sont pas clairement définis.
      Du genre « cette semaine j'ai bien tout testé ce que j'ai produit » est un indicateur personnel « interne ». Il est de qualité discutable, mais c'est réellement un indicateur.

      Les indicateurs sont utiles pour s'auto-évaluer, s'auto-corriger, et s'auto-améliorer.

      Exemple : j'ai travaillé dans la grande distribution. Pour diminuer les problèmes d'écarts de caisse (l'argent liquide dans le tiroir-caisse en fin de rotation n'est pas la somme attendue) les nanas avaient simplement accès à leurs stats personnelles (pas celles des autres, pas de compétition) sur les écarts de caisses (montant quotidien, glissant sur 5 jours, glissant sur 20 jours, glissant sur 1 an je crois). Zéro carotte ou sanction, juste les stats sous forme de graphiques.
      Les magasins qui faisaient cela avaient des montants d'écarts 9 fois inférieurs. 9 fois ! juste avec un indicateur « sans enjeu ».

      Exemple : j'ai un indicateur du nombre de contacts commerciaux que j'établis. Je n'ai vraiment pas la fibre commerciale. Cet indicateur m'amène zéro carotte ou sanction. Il me permet de savoir que je fais en général x contacts commerciaux sur 2 semaines, m'évitant de me mettre la pression par inadvertance au delà de cette quantité.
      Lorsque je fais moins ? Rien. Je suis juste au courant. Au pire je me dis que j'ai vraiment renâclé, mais avec ça je ne procrastine plus du tout sur ce sujet (donc je ne perds plus de temps à procrastiner, et je ne me mine pas l'esprit). Et si je fais plus ? Rien non plus. Je constate que telle occasion a permis de faire 3 actions à la suite et que c'est passé crème.

      Exemple : lorsque je fais du ski, si je ne me suis pas pris 4 bonnes grosses gamelles dans la journée, c'est que je n'ai pas assez tenté de trucs en dehors de ma zone de confort. J'adore tester, essayer, etc. Mais d'un autre côté je sais que je me croûte sévère, c'est très désagréable. Avec cette règle des 4 énormes plantages je suis généralement très satisfait de ma journée. C'est un indicateur, par contre il n'est pas neutre car il me « garanti » une journée sympa.

      • [^] # Re: La performance doit-elle être mesurée ?

        Posté par . Évalué à 1 (+1/-1).

        Les indicateurs sont utiles pour s'auto-évaluer, s'auto-corriger, et s'auto-améliorer.

        Non car s'ils y a une baisse de "qualité" il peux y avoir tellement de raison de contester a commencer par la mauvaise qualité des indicateurs. Et sans indicateurs de performances un employé motivé sera bien plus combatif. S'il y a des indicateurs de performances, l'employé est soit démotivé soit invité à tricher. Je n'ai pas connu un commercial intelligent qui ne trichait pas avec (parfois en dégradant sa performance pour ne pas augmenter trop vite sa performance qui pousserait à en demander plus après).

        Par contre il est utile pour les managers d'avoir des indicateurs simple pour détecter un problème. Je pense notamment aux nombres de lignes de codes modifiés. Ce n'est pas pour évaluer les développeurs, mais pour évaluer la complexité du projet ou l'ambiance général, la motivation général… Une variation ne traduit pas une baisse de productivité mais quelques chose a regarder. Seul l'oeil humain comprendra.

      • [^] # Re: La performance doit-elle être mesurée ?

        Posté par (page perso) . Évalué à 6 (+4/-0).

        juste avec un indicateur « sans enjeu ».

        C’est là toute la magie, pour qu’un indicateur donne une indication utile, il doit être non-intrusif, c’est à dire qu’il ne doit pas influencer sa mesure. Le problème des démarches qualité, c’est qu’en imposant des indicateurs, elles dessinent la grille de lecture à travers laquelle le système est évalué (indicateurs de « performance » par exemple), dès lors, le système tend à optimiser les indicateurs, notamment en exploitant leurs biais.

        Par exemple, on pourrait penser qu’une « bonne » méthode pour assurer une erreur de caisse nulle, c’est de systématiquement faire des erreurs positives (ne pas rendre assez de monnaie à un client) pendant la journée par sécurité, et de retirer tous les écarts le soir pour remettre l’erreur moyenne à 0 (ou de dire. Tant que l’indicateur n’est pas utilisé à des fins d’évaluation, personne ne mettrait cela en place (ou alors c’est vol pur et simple de la clientèle) car l’indicateur donne juste une indication (imparfaite mais utile) des erreurs de rendu de monnaie sur une journée. Utiliser un tel indicateur à des fins d’évaluation constitue de fait une incitation à voler, ce qu’on qualifiera difficilement d’amélioration de la qualité.

        • [^] # Re: La performance doit-elle être mesurée ?

          Posté par (page perso) . Évalué à 9 (+6/-0).

          une « bonne » méthode pour assurer une erreur de caisse nulle, c’est de systématiquement faire des erreurs positives (ne pas rendre assez de monnaie à un client) pendant la journée par sécurité, et de retirer tous les écarts le soir pour remettre l’erreur moyenne à 0

          Pour éviter cela, on peut faire compter la caisse par une autre personne, avec contrôle visuel d'un supérieur. Comme ça on limite considérablement la triche.
          Bon après on se rend compte que ça coûte plus cher que les écarts de caisses. Alors on met un indicateur sur la durée de comptage de la caisse, le tout filmé et stocké en cas de doute. Il faut une personne qui vérifie au hasard un comptage sur 10.
          L'investissement global et les réunions préparatoires coûtent environ 3 ans d'écarts de caisses. Bon ok, alors il faut un indicateur permettant de réduire le coût de la surveillance de la vérification.
          L'étape suivante amène donc une vérification de la surveillance de la vérification.

          Bon finalement la direction a décidé que les écarts de caisses n'est pas un sujet important.

    • [^] # Re: La performance doit-elle être mesurée ?

      Posté par . Évalué à 8 (+6/-0).

      Qu'est-ce que la qualité ? Sur quelle base on l'évalue ? Est-ce qu'un nombre (lignes, commits, personnes, etc.) peut vraiment refléter la qualité ? Bien sûr que non. La qualité est bien trop complexe pour qu'elle s'évalue

      Ce passage, c'est de la "fumisterie". Un indicateur n'est pas censé refléter LA qualité, c'est simplement un indicateur de quelque chose. Dire que quelque chose est trop complexe, c'est malhonnête parce que, comme dans tous les domaines, on divise le problème en problèmes plus petits pour qu'ils soient solvables.

      Si on parle d'un code, on peut avoir des indicateurs fiables sur la qualité de ce code : taille des fonctions, nombre de variables utilisés dans la fonction, taille des fichiers, pourcentage de commentaires, pourcentage de duplication, complexité cyclomatique, violations des règles de codage, couplage de données, …

      Aucun de ces indicateurs n'est suffisant à lui, les outils d'analyse statique rassemblent souvent ces "métriques" dans des catégories "testabilité", "maintenabilité", … Ces indicateurs ne sont pas forcément pour détecter un code de qualité, rien n'empêche de nommer toutes les fonctions et variables avec des noms abscons et dans ce cas, la maintenabilité en prend un sacré coup. On pourrait rajouter une démarche qualité selon laquelle tout code produit doit être relu. Ces indicateurs donnent des indications sur la qualité du code. La démarche "qualité" peut consister à formaliser l'utilisation de ces indicateurs.

      Juste pour être clair, je suis d'accord avec le commentaire sur le fond : très souvent, les démarches "qualité" servent surtout à remplir des cases et cela a parfois l'effet contraire de celui escompté.

      • [^] # Re: La performance doit-elle être mesurée ?

        Posté par . Évalué à 2 (+1/-0). Dernière modification le 04/03/20 à 19:10.

        De la fumisterie parce que visiblement tu n'a rien compris à mes propos sur ces questions. Ce que je décrit ici est que la démarche qualité est bien souvent associé à des indicateurs utilisés pour mesurer (donc refléter) cette démarche qualité, qui est considéré comme la qualité. La quantité s'évalue facilement, la qualité c'est autre chose puisque justement la plupart du temps des personnes différentes définiront des critères différents. Dans de nombreux cas, la qualité perçue ne sera pas la même d'une personne à une autre, etc. La complexité est là et la difficulté d'évaluation aussi. Après, je simplifie ici tout ça, on est sur du commentaire. Et je ne parle pas du fond des mots mais de comment s'est bien souvent pratiqué/utilisé, etc… La réalité, la vie, est complexe, donc c'est dire le contraire qui est malhonnête. Mais j'ai l'impression ici que tu confonds complexité et compliqué. Oui là ce serait malhonnête.

        Définir des critères n'est pas le problème mais de définir l'indicateur derrière (c'est-à-dire à quel niveau tu considères que la qualité est là). Pour tes exemples, à quel hauteur tu définis (ou comment tu définis) de tels critères ? Par exemple, quelle taille des fichiers, pourcentage de commentaires ou pourcentage de duplication est le bon ? Sur quelle base ? Ca va dépendre du programme bien sûr mais quelle est la bonne taille, le bon pourcentage ? Les développeurs ne mettront peut-être pas les mêmes critères que le dirigeant d'entreprises qui pense à son bilan comptable ou même les utilisateurs (selon les critères définis bien sûr).

        Ce que je trouve dommage sur ces passages de commentaire est que sur ta dernière phrase tu montres justement le fond de mon propos. Je ne critique pas la qualité ou la démarche qualité mais ce qu'elle est en réalité dans la très grande majorité des entreprises/institutions aujourd'hui. Où justement elle est dévoyée, mal utilisée, mal comprise, mal appliquée, etc… Pas forcément volontaire, juste parce qu'en réalité ça n'est pas si simple. Et ça ne veut pas dire que certains critères peuvent parfois l'être correctement. Tout ça est très bien étudié par nombre de chercheurs sur ces sujets.

  • # Je propose de meilleurs indicateurs

    Posté par (page perso) . Évalué à 3 (+2/-1). Dernière modification le 02/03/20 à 19:42.

    1. Design aussi simple que possible, mais qui rend facile le passage a` l'echelle.
    2. Couverture des tests aussi haute que possible / aussi basse que justifiable (e.g., pas la peine de tester le code Java genere' par Lombok.)
    3. Documentation decrivant le systeme tel qu'il est a` tout moment.
    4. Respect des regles de Clean Code.
    5. Facilite' pour toute personne nouvelle sur ce projet a` le modifier en respect les 4 points precedents.
  • # Audit et dialogue

    Posté par . Évalué à 2 (+1/-0).

    Rien ne vaut une bonne audit du code par des développeurs extérieurs au projet, en relisant ils pourront dire si le code est clair et pourquoi telle ou telle chose à été fait de telle ou telle manière et ainsi voir si le code est optimisé et les performances au rendez-vous. Et pour l'amélioration rien ne vaut le dialogue avec les utilisateurs concernés, pour qu'ils disent leur ressenti et s'ils ont des idées d'amélioration.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.