Dans le cadre d'un examen de toutes les descriptions de poste, mon entreprise a décidé d'inclure les éléments suivants comme résultat clé:

développement du site Web terminé à temps, dans les spécifications et sans erreur

Étant donné que les spécifications changent régulièrement, il n'y a pas de processus formel de contrôle des changements et les environnements sont, disons, un peu imprévisibles, dans quelle mesure ce KPI est-il réaliste et raisonnable?

"Sans erreur" est beaucoup trop subjectif . La «demande de fonctionnalité non satisfaite» d'un homme est «l'erreur» d'un autre homme. Quelque chose comme «Devrait répondre sensiblement aux spécifications de conception» serait plus approprié. Je n'ai jamais vraiment vu ce que vous décrivez dans une description de poste. Je l'ai vu pour le travail à contrat , mais pas pour les employés.

Je prendrai une position opposée à la plupart des réponses et dirai que c'est absolument raisonnable et réaliste.

Est-ce que tout le développement sera terminé à temps? Bien sûr que non, pas toujours.

Est-ce que tout le développement sera terminé conformément aux spécifications? Vous souhaitez l'espérer, mais parfois cela ne sera tout simplement pas possible et vous devrez signaler une déviation par rapport à une spécification impossible ou contradictoire.

Et tout développement sera-t-il sans erreur? Jamais .

Mais c'est à cela que sert un KPI. C'est quelque chose qui peut être mesuré et par lequel vous pouvez suivre les performances et les progrès.

Si les spécifications changent régulièrement, il n'y a pas de processus formel de contrôle des modifications et les environnements sont imprévisibles, il sera difficile de garder ce chiffre proche de "sans erreur". Mais ce défi est votre travail , et c'est un travail que vous ferez, espérons-le, assez bien - et encore mieux l'année prochaine, à mesure que vous vous familiariserez avec la gestion de la saveur particulière du chaos de votre entreprise.

Contre question: quels KPI proposeriez- vous pour un programmeur? C'est difficile. Beaucoup de ce que nous faisons est difficile à mesurer.

S'il s'agit d'une description de travail, je ne m'inquiéterais pas trop à ce sujet car travailler vers un code sans erreur fait partie du travail d'un programmeur typique (même si nous ne pouvons jamais y parvenir).

Cependant, en tant qu'indicateur de performance clé, il va trop loin, mais ne blâmez pas la personne qui l'a suggéré si ce ne sont pas des programmeurs. Expliquez simplement que cette déclaration fixe un objectif qui pourrait être indésirable pour l'organisation. Autrement dit, "sans erreur" est un standard extrêmement élevé pour les logiciels qui coûteraient une fortune à livrer. Expliquez qu'un projet logiciel bien géré nécessite de prendre des décisions quant à savoir si chaque défaut vaut la peine de consacrer un temps précieux au développeur.

Voici un exemple qui fait bien le point.
Un programmeur découvre que notre logiciel a un bug "an 3000" et cessera de fonctionner après le 31 décembre 1999. Il faudra 6 à 8 mois pour résoudre le problème. Sur la base du KPI est encouragé à entreprendre ce projet bien qu'il n'ait pas de réelle valeur pour l'entreprise.

D'accord, cet exemple est donc un peu extrême, mais dans tout projet logiciel, il y aura littéralement des dizaines de petits défauts découverts qui, de la même manière, ne génèrent pas le retour sur investissement requis pour les corriger. Si le KPI était plutôt destiné à impliquer que le programmeur n'introduise jamais le défaut en premier lieu, est-il raisonnable pour TOUT employé d'être tenu à la norme de ne jamais commettre d'erreur dans l'exécution de son travail?

Non

Non seulement ce n'est pas approprié, c'est ridicule

Les tests ne peuvent que prouver l'existence d'erreurs, pas leur absence, donc chaque programme écrit dans le cadre de cet engagement devrait inclure une preuve d'exactitude rigoureuse ... et une couverture de test à 100%

"Méfiez-vous des bogues dans le code ci-dessus; je l'ai seulement prouvé correct, pas essayé." - D. Knuth

Bien sûr, c'est le travail et la responsabilité de chaque programmeur d'écrire du code sans erreur. C'est une attente parfaitement raisonnable. Comment pouvez-vous être un programmeur professionnel si vous publiez du code qui ne fonctionne pas? Comment pouvez-vous vous considérer comme un programmeur professionnel si vous publiez du code que vous ne connaissez pas ?

Si vous embauchez un peintre, vous vous attendez à ce qu'il fasse bien son travail. Vous vous attendez à ce que le résultat de son travail soit sans erreur. S'il y a des erreurs, vous vous attendez à ce qu'il assume la responsabilité de ces erreurs et les corrige gratuitement. De plus, si les erreurs vous coûtent de l'argent, vous vous attendez à ce qu'il vous rembourse. Pourquoi avez-vous ces attentes? Parce que le peintre est un professionnel.

Les programmeurs aiment blâmer tout le monde pour leurs erreurs. "Mon programme a des bugs à cause des exigences, ou à cause du calendrier, ou parce que la Lune est dans la 8ème maison" Mais il n'y a vraiment personne d'autre à blâmer. Si votre programme contient des erreurs, vous les mettez là.

Notre profession ne sera jamais être une profession jusqu'à ce que les programmeurs se rendent compte que l'argent cesse avec eux. Ce qu'ils sont responsables de la qualité de leurs programmes.

Savez-vous pourquoi les entreprises ont créé des départements Software QA? Parce que les programmeurs ne faisaient pas leur boulot! Les programmeurs libéraient tellement de conneries que les entreprises devaient former de nouveaux départements pour les vérifier.

Quelle est la longueur de la liste des bogues? Est-il professionnel d'avoir des milliers de bogues dans la base de données de bogues? Ce n'est clairement pas le cas. C'est le reflet d'un mauvais comportement, d'une mauvaise discipline et, franchement, d'un déshonneur.

Nous ne serons jamais une profession jusqu'à ce que nous réalisions que c'est notre travail de nous assurer que l'AQ ne trouve rien.

Malheureusement, cela semble être un moyen pour eux de "couvrir toutes les bases", et ce n'est clairement pas recommandé et est susceptible de provoquer une désillusion chez les développeurs.

Cela dit, cela n'a vraiment d'importance que lorsque vous voyez ce qu'ils font de ce texte pendant la période à l'examen. Donc, ne réagissez pas trop rapidement - il pourrait y avoir encore de la raison au bout du tunnel.

"Sans erreur" comme dans "parfait?" Comme dans "écrit par Dieu et les anges, pas les humains?" (nous parlons ici de logique de programme et peut-être d'erreurs de logique matérielle)

Je ne peux pas dire franchement qu'une seule ligne de code est sans erreur. C'est parce que nous, les humains, eh bien, nous ne pouvons prouver aucune hypothèse négative!

Le mieux que je puisse dire, c'est que la probabilité d'erreur est un nombre compris entre 0 et 1. J'atteins ce nombre par le biais de principes de développement et de test de logiciels bien ou mal définis et bien ou mal compris; par un décompte des lignes de logiciel source en question; en comprenant à quel point je me porte bien ou mal, pauvre candidat, applique ces principes pour produire ces lignes de code; et plus.

Et je ne peux exprimer cette compréhension que comme une probabilité. Le terme «sans erreur logique» signifie donc presque rien.

Si je voyais une annonce pour un ingénieur logiciel qui produisait du code "sans erreur", je l'appliquerais immédiatement ou je courrais tout de suite: l'entreprise n'a pas beaucoup réfléchi à la façon dont elle développe, teste et livre ses logiciels. . Ce sera donc soit une grande opportunité, soit un cauchemar sans fin.

De tout logiciel, cependant, je peux facilement - et je dois - dire que je m'attends à du code qui ne comporte pas d'erreurs qui tombent en dehors de ce truc de logique, sombre: du code qui compile et relie sans erreurs ni avertissements; c'est-à-dire "html valide" ou "css valide"; JavaScript (par exemple) qui ne génère aucun message d'erreur inexpliqué ou défaut de navigateur. Je peux mesurer cette partie directement et la marquer en noir et blanc sur un graphique.

Cette partie est simple comme bonjour. Tout le monde peut faire cela .

Hé, bonne chance dans votre recherche :-)

Suis-je stupide, ou "erreur" ne signifie-t-elle pas "message fatal du compilateur équivalent à du code non compilable"?

Selon cette définition, c'est une exigence très raisonnable ...