Comment dois-je répondre à sa question dans ce cas, sans paraître incompétent? Honnêtement, je n'ai jamais 100% de confiance sur tout le site, mais j'ai confiance en mes méthodes de test. Et, en tant que développeur, je sais aussi qu'il n'est pas rare que des bogues inattendus émergent plus tard de ces changements fondamentaux.

Le chef de projet ne comprend pas assez bien les logiciels, et ne comprend certainement pas Je ne comprends pas assez bien les tests. Peut-être qu'il a besoin d'être éduqué.

Si vous aviez un service QA professionnel, je vous dirais de faire appel au support du QA Manager pour expliquer à ce chef de projet la nature des logiciels, la nature des bogues et la nature des tests. Je demanderais au QA Manager d’indiquer pourquoi il n’est tout simplement pas possible de tester chaque condition, et en quoi la libération / la non-libération est une activité commerciale facilitée par les résultats des tests, mais jamais par des informations parfaites.

Vous souhaitera peut-être obtenir une copie de l'excellent livre de Gerald Weinberg " Perfect Software and other illusions about testing ". Dans le chapitre 3 («Pourquoi ne pas simplement tout tester?»), Weinberg a une section intitulée «Il existe un nombre infini de tests possibles».

Il parle d'une porte dérobée placée dans un programme hautement sécurisé par lequel la protection par mot de passe ordinaire pourrait être contournée en tapant W suivi de trois espaces, puis M suivi de trois espaces, puis J suivi d'exactement 168 autres frappes sans une fois en utilisant la lettre L.

Puis il écrit: "Avez-vous compris maintenant? Si vous ne deviniez pas que le nombre de tests requis pour tester de manière exhaustive le logiciel est infini, ou du moins" a nombre supérieur à ce que je pourrais exécuter dans ma vie ", vous n'avez pas compris le but de ce chapitre. Maintenant vous le faites."

Expliquez à votre chef de projet que chaque jour de tests supplémentaires améliorera quelque peu votre confiance en votre code, mais qu'il ne pourra jamais atteindre 100%. Dites-lui que vous seriez heureux de continuer à tester au détriment de votre autre travail productif. Ensuite, demandez-lui combien de jours il aimerait que vous consacriez aux tests et lequel de vos autres travaux devrait être reporté.

Si votre chef de projet ne comprend toujours pas et que vous vous sentez un peu désinvolte , demandez-lui s'il est sûr à 100% que chaque estimation qu'il publie est exactement correcte et que les délais ne seront jamais manqués. Demandez-lui s'il est sûr à 100% qu'aucun e-mail qu'il rédigera à partir de maintenant pour toujours n'aura jamais de faute de frappe. Demandez-lui s'il est sûr à 100% qu'il ne fera jamais d'erreur - maintenant et à l'avenir.

Patron: Êtes-vous sûr à 100% que ce correctif n'interrompra aucune fonctionnalité existante ou n'entraînera aucun effet indésirable sur l'expérience utilisateur?

Moi: Non. Puisque nous ne disposons pas d'une suite de tests de couverture à 100%, il n'y a aucun moyen de vérifier que tout changement de code évitera la rupture de l'application ou des effets indésirables. Cependant, j'ai effectué les actions suivantes pour m'assurer qu'il est peu probable qu'il s'exécute de manière involontaire:

• J'ai limité la portée de la modification au seul module qu'elle affecte
• J'ai lu et mis à jour la documentation en conséquence
• J'ai exécuté les tests unitaires pour ce module et les modules concernés
• J'ai créé des tests unitaires pour vérifier les nouveaux fonctionnalité ajoutée, et les tests obsolètes ne sont plus pertinents en raison du changement

Bien que je ne puisse pas vous donner une assurance exacte à 100%, j'ai fourni autant d'assurance que possible dans les délais que je crois est raisonnable pour la mise en œuvre de cette fonctionnalité. En fait, j'ai déjà atteint le point des rendements décroissants. Je peux passer encore 5 heures pour vous donner une autre assurance de 0,1%, mais il est déjà si faible qu'un tel effort ne soit pas justifié. Cependant, vous êtes en charge du projet et du calendrier, alors faites-moi savoir combien de temps je devrais consacrer à cette fonction.

La balle est maintenant dans son camp. S'il veut vraiment que je fasse passer mon estimation personnelle de, disons, 95% sûr à 95,1% sûr pour quelques heures de travail de plus, alors hé - je peux le faire.

S'il continue à être désagréable à propos de , j'aurai une conversation par e-mail avec lui et le «propriétaire» du projet au sujet de cette exigence «testée à 100%» et des ressources qui, selon moi, sont nécessaires pour y répondre.

En tant que développeur, vous testez UNIT les modifications apportées à votre code. À mon avis (en tant que développeur), c'est pour vérifier qu'il n'y a pas d'erreurs évidentes, tout compile, toutes les erreurs sont piégées. Vous n'avez aucun moyen de savoir quels scénarios seront rencontrés une fois le code mis en ligne (mauvaises données, saisie inattendue, changement dans le logiciel client, la liste est interminable)

Pour avoir 100% de confiance qu'un changement ne sera pas n'importe quoi, vous auriez besoin d'un environnement de test qui reflète EXACTEMENT l'environnement en direct (données, matériel, autorisations, connectivité) et une suite de scripts de test couvrant chaque scénario. Ceci, comme on le sait, est un environnement pratiquement impossible à créer pour diverses raisons

S'il s'attend à une confiance à 100%, alors il doit fournir l'environnement et la main-d'œuvre pour soutenir ses attentes

C'est un peu comme quand les chefs de projet et les clients demandent que les choses soient à l'épreuve du temps!

On dirait qu'il est tombé dans une mauvaise habitude. Il pose une question qui, à un certain niveau, est ridicule. Mais il y a un peu un élément compulsif à cela. Je suppose qu'il agit sur une anxiété sous-jacente, et poser une question déraisonnable le fait se sentir plus en contrôle.

Dans ce genre de situations, j'essaie de diffuser la dynamique en étant confiant et en injectant un peu d'humour. Si vous comprenez que sa question ne vient pas du raisonnement, mais de l'anxiété, vous pouvez y répondre mieux indirectement que directement.

Dans des situations comme celle-ci, je dissipe généralement les craintes de la direction en présentant toutes les mesures que j'ai prises pour assurer la qualité. Il est, après tout, le client, et il a besoin de savoir que vos priorités correspondent aux siennes. Regardez ces tests unitaires. Regardez cette surveillance. Regardez comment le code est structuré pour garder les changements locaux et modulaires. etc. Si vous transmettez un sentiment de confiance et de contrôle, cela apaisera son anxiété et vous serez probablement en mesure d'avoir une conversation plus rationnelle.

C'est là que l'art de cette entreprise entre en jeu. Non seulement "ça marche", mais le client se sent bien.

En fin de compte, c'est une relation d'affaires. Si l'accord contractuel est confortable et rentable pour vous, alors il vaut la peine de supporter cette bizarrerie. Il ne semble pas qu'il soit si sérieux à ce sujet, juste un peu persistant. Comme je l'ai dit, il a développé une habitude ennuyeuse. S'il commence à réagir négativement et que le ton devient plus hostile, l'équilibre de l'arrangement commercial peut le rendre inutile pour vous. Mais d'après votre courte description, il me semble que vous pouvez toujours gérer efficacement la relation.

Beaucoup de gens ont décrit cela comme un problème d'éducation, et je ne dis pas qu'ils ont tort.

Il est également possible que ce soit un problème politique. Ce que la question pourrait réellement signifier, c'est que le chef de projet veut être dégagé de toute responsabilité pour toute erreur. Il reçoit une déclaration sous serment de votre part sur laquelle il pense pouvoir compter "raisonnablement", donc si quelque chose ne va pas, il dit qu'il a fait tout ce qu'il pouvait pour l'empêcher mais que vous avez échoué.

Ce n'est pas une bonne gestion et ce n'est pas non plus garanti à 100% de le mettre au clair en cas de problème.

J'admets que c'est de la spéculation de ma part, mais les exercices de couverture des fesses ne sont pas du tout rares dans la vie professionnelle et vous avez pour y faire face. Donc, si cela sonne vrai, alors ce que vous devez faire pour résoudre le problème n'est pas seulement d'éduquer le gestionnaire qu'une confiance à 100% est impossible. Vous devez également le convaincre qu'un bug n'est pas un désastre - pour lui personnellement ou pour l'entreprise.

Cela peut signifier par exemple fournir des exemples de bugs traités à un coût raisonnable et sans aucun blâme. environ. Cela peut vouloir dire regarder sa propre culture d'entreprise, s'il y a quelqu'un d'autre dans l'entreprise qui se prépare à lui imputer un blâme injuste si quelque chose ne va pas. Cela peut également signifier la mise en place de procédures pour traiter les bogues futurs aussi rapidement et à moindre coût que possible. Si l'entreprise avait vraiment confiance à 100% dans le code, de telles procédures seraient inutiles car elle serait prête à parier arbitrairement de grosses sommes d'argent sur l'absence de bogues futurs!

En tant que sanction ultime, s'il (l'employeur) vous demande (à l'entrepreneur) de lui vendre une assurance que vous ne pouvez pas donner sur votre travail, et que rien ne changera d'avis sur ce point, alors tout ce que vous pouvez faire est indiquez clairement que vous n'êtes pas en mesure de fournir cette assurance et qu'il est le bienvenu pour employer quelqu'un d'autre s'il pense que quelqu'un le peut. Bien sûr, c'est un long chemin à parcourir, mais vous pourriez aussi bien connaître votre BATNA avant de commencer.

À proprement parler, on ne peut jamais être sûr à 100% qu’un commit ne casse pas un programme.

Même avec toutes sortes de tests possibles (tests unitaires, intégration, composant, système, manuel, interface utilisateur, fuzz, sécurité, pénétration .. vous l'appelez). Cela est dû à un problème d'arrêt. Un extrait pertinent de Wikipédia suit ci-dessous:

Dans la théorie de la calculabilité, le problème d'arrêt peut être énoncé comme suit: "Étant donné la description d'un programme informatique arbitraire, décidez si le programme se termine ou continue pour courir pour toujours ". Cela équivaut au problème de décider, étant donné un programme et une entrée, si le programme s'arrêtera finalement lorsqu'il sera exécuté avec cette entrée, ou s'il fonctionnera pour toujours. résoudre le problème d'arrêt car toutes les paires d'entrée de programme possibles ne peuvent pas exister. Un élément clé de la preuve était une définition mathématique d'un ordinateur et d'un programme, qui est devenu connu comme une machine de Turing; le problème de l'arrêt est indécidable sur les machines de Turing.

Si votre PM se soucie de la valeur et d'une livraison prévisible stable, vous pouvez peut-être le convaincre de jeter un coup d'œil au framework SCRUM.

D'autres ont donné de nombreux conseils intéressants sur la façon d'interagir avec votre PM. Personnellement, je conseillerais d'organiser une réunion avec votre PM et l'équipe où vous pourrez discuter de vos processus. Je suis fortement en faveur de SCRUM, donc cela serait en grande partie lié au SCRUM.

J'essaierais d'expliquer qu'un objectif de 100% est insaisissable. Il ne peut pas être atteint. Jamais. Dans tout l'univers. L'histoire a vu de nombreux exemples de ce type, une démonstration de la sortie de Windows 95 par exemple. Il y a longtemps? Eh bien, voyez combien de versions rouges sur un serveur CI public pour les projets open source; connectez-vous en tant qu'invité si vous n'y avez pas de compte. Donc, un résultat de ceci - le logiciel échouera.

Deuxièmement, je vous conseillerais d'adopter une pratique, dans laquelle vous pouvez apporter de la valeur , au lieu de la confiance d'un commit. Quelque chose dont les clients se soucient. De manière itérative, répétée et fiable. Maintenant, vous pouvez changer la perspective de votre PM de l'assurance à 100% à quelque chose qui compte réellement. C'est-à-dire: le logiciel est en cours d'utilisation, votre produit s'améliore et l'équipe apporte de la valeur au client.

Troisièmement, le devrait être une définition de fait. Quelque chose, qu'une équipe de développement propose. Cela peut inclure: la documentation, la mise en œuvre, les tests, les critères de qualité, etc. Ceci est très important, car vous pouvez maintenant déplacer la subjectivité (c'est-à-dire "êtes-vous sûr à 100%?") En objectivité (c'est-à-dire que toutes les puces de la définition de done sont complétées).

Il y a d'autres étapes très importantes que SCRUM promeut. Mais tous permettraient aux développeurs d'atténuer cette frustration et leur permettraient de fournir des résultats objectivement quantifiables, par rapport à une assurance subjective.

La réponse habituelle pour ce type d'objectif est la revue par les pairs et les tests de régression.

1) Ne pas valider quoi que ce soit dans le flux de code de production tant que non seulement l'auteur, mais un ou plusieurs autres programmeurs, faites-le vérifier pour vous assurer qu'il ne change que ce qui est nécessaire, qu'il répond à tous les critères convenus pour les bonnes pratiques de codage, qu'il est livré avec un test qui vous donne des chances décentes de détecter si un changement ultérieur brise la logique encore une fois, et ainsi de suite.

2) Ne commettez rien dans le flux de code de production tant que TOUS les tests de régression n'ont pas été réexécutés et qu'il n'a pas été prouvé qu'il ne cassait rien pour lequel le test. Si un échec se produit pendant ce test, le changement doit être annulé jusqu'à ce qu'il puisse être clairement établi qu'il n'a pas causé le problème.

3) Des tests alpha et bêta précoces et souvent avec le monde réel scénarios clients. Les clients feront des choses avec votre code auxquelles vous ne vous attendiez pas.

Aucune de ces choses n'est à 100%, ni leur combinaison. Mais ils vous rapprochent considérablement. Ils nécessitent un investissement non trivial de ressources supplémentaires. Ils ralentissent le développement par rapport à skunkworks "faites-le simplement et nous le réparerons quand ça casse" la pratique de codage. Mais si vous voulez vraiment un code sans bogue, reconnaître que les humains sont faillibles et mettre en place des pratiques pour aider à détecter les échecs avant qu'ils n'atteignent les clients peut valoir plus que ces coûts.

On me dit que là n'était jamais un bogue signalé dans le code qu'IBM a écrit pour la NASA - parce qu'il a été revu par des pairs et testé à mort pendant la conception, pendant le développement et avant d'être publié.

Si vous faites quelque chose de vital, cela vaut évidemment cet investissement. Si vous faites quelque chose qui est une infrastructure pour les grandes entreprises, cet investissement en vaut la peine; vous ne voulez pas être celui dont le bogue détruit les processus métier d'une entreprise d'un milliard de dollars.

Oui, cela rend les bons codeurs fous. Jusqu'à la première fois qu'il sauve leurs fesses.

La vérité est que les tests sont médiocres. La réalité est qu'une entreprise qui ne souhaite pas investir dans une équipe d'assurance qualité va subir de mauvais tests. Un bon test coûte cher et prend du temps. L'entreprise a accepté le risque en n'autorisant ni le temps ni l'argent.

Même une équipe d'AQ ne peut garantir que toutes les possibilités sont testées car les chemins possibles à travers un programme complexe sont fondamentalement infinis. Cependant, ils vous rapprocheront beaucoup plus que vous ne l'êtes actuellement. Une des raisons est qu'il est impossible pour un développeur de tester correctement son propre code. Ils savent ce que cela fait, alors ils ont tendance à concevoir des tests autour de ce qu'ils pensent être censé faire. Ils manquent des cas extrêmes, ils manquent des choses stupides que les utilisateurs font qu'un développeur ne ferait jamais parce qu'ils savent comment cela fonctionne, ils interprètent parfois les exigences de manière incorrecte, mais tous leurs tests refléteront leur interprétation incorrecte d'origine. Ils manquent souvent des erreurs dans l'exigence et font ce qu'on leur demande de ne pas faire ce qu'ils auraient dû faire (c'est la cause d'un grand nombre de bogues qui ne se trouvent qu'après les utilisateurs réels [qui ne sont trop souvent pas consultés pour définir l'exigence] essayez d'utiliser le logiciel). Ils manquent d'effets sur des parties de l'application dans lesquelles ils n'ont jamais eu de raison de travailler, en particulier sur des parties qui sont effectuées par des spécialistes (comme un changement de table qui a du sens pour l'application mais interrompt un processus d'importation automatisé ou un rapport.)

S'il veut une meilleure qualité, il devra la payer en temps et en argent. Même avec un contrôle qualité complet, vous ne pouvez pas atteindre 100%, bien que la NASA et ses sous-traitants se rapprochent certainement. Ils dépensent également beaucoup plus d'argent que votre entreprise ne dépense. Même alors, ils ont réussi à manquer complètement MARS une fois.

Si ce qu'il veut, c'est l'assurance qu'aucun problème ne lui causera de tort aux clients, parlez de votre processus de test (montrez-lui la liste des tests que vous avez exécutés.), ce que vous pensez qui serait affecté et comment vous avez vérifié cela, votre processus pour savoir comment inverser une mauvaise impulsion et votre processus de journalisation des erreurs afin que vous les voyiez avant que la plupart des clients ne les remarquent. Donnez-lui l'assurance que même s'il y a un problème, il peut être résolu. Parlez de la valeur de la sortie rapide du code (nouvelle fonctionnalité ou correctif) et le temps supplémentaire nécessaire pour un test plus approfondi. Parlez des risques de ne pas le sortir rapidement.

Vous pouvez également lui demander de fournir le test de régression approfondi du système chaque fois que vous apportez un changement car il n'est pas possible pour un développeur de tester complètement son votre propre travail (vous savez quelles étaient vos hypothèses, si elles ne sont pas correctes, vous ne testeriez jamais cela.) Assurez-vous qu'il sait qu'il devra tester chaque page de l'application et chaque chose qui pourrait être faite sur un page dans tous les ordres possibles. Oh oui, testez également les importations / exportations, les rapports, les travaux automatisés. Et toutes les applications associées qui pourraient être affectées. Une fois qu'il a essayé une fois d'exercer complètement le système, il comprendra pourquoi vous ne pouvez pas donner cette assurance.

Une autre chose à essayer est de lui dire d'emblée que non, vous ne pouvez pas faire cette garantie, mais s'il autorise X heures de test, vous pouvez vous rapprocher de cette garantie. Donnez-lui une liste détaillée des tests supplémentaires et des heures qu'il faudrait pour concevoir et exécuter chacun d'eux. Dites-lui quel pourcentage de confiance vous auriez après avoir exécuté tous ces tests et quel pourcentage de confiance vous avez en ce moment.

D'ailleurs, dites-lui combien de temps il faudrait juste pour exécuter tous les tests unitaires actuels que vous avez, qu'ils soient ou non liés à ce problème. Donc, si vous avez actuellement 1000 tests unitaires et que chacun prend cinq minutes pour configurer et exécuter et évaluer les résultats, ce serait 83 heures. Demandez-lui l'autorisation d'aller de l'avant et de dépenser ce temps.

Le produit contient de nombreuses parties entremêlées (pas seulement des pages autonomes), quelque 40 000 lignes de code écrites sur 4 ans, et parfois des choses inattendues se produisent dont nous n'étions même pas au courant. J'ai l'impression qu'il considère cela comme de mauvais tests.

C'est votre problème, mais jusqu'à présent, ce n'est pas votre faute. Si vous ne le résolvez pas, vous devrez assumer la responsabilité à un moment donné. Discutez avec votre patron du fait que tant que ce n'est pas réglé, vous ne serez jamais à 100%. Suggérer une refactorisation. De plus, 100% dans l'esprit des non-techniciens n'est pas la même chose qu'un programmeur. Vous devriez peut-être indiquer que vous êtes "sûr à 100% que le client ne le remarquera probablement pas."

Il n'y a pas d'équipe QA C'est un luxe que votre entreprise ne peut pas se permettre, donc c'est toi. Imaginez qu'il y avait une équipe QA (vous) et déterminez combien de temps il faudrait pour tester votre code, puis mettez cela dans votre estimation. Vous ne pouvez pas coder et QA simultanément, vous ne pouvez donc pas le faire en parallèle.

Arrêtez d'être si impatient d'enregistrer le code et de répondre à ce qui semble être des demandes déraisonnables. Donnez-leur ce qu'ils veulent. Une fois qu'ils ont découvert le coût (temps de codage excessif), il peut changer d'avis.

S'il vous micro-gère en fait et regarde par-dessus votre épaule tout au long du processus de construction du projet, il existe un moyen simple de vous assurer que vous pouvez «garantir» une confiance à 100% sans qu'il vous en parle plus tard.

Faites-lui approuver lui-même

Pour être clair, vous ne devriez pas faire cela comme une demande, mais plutôt comme une suggestion, que s'il veut un code 100% parfait, alors il devrait regarder ce que vous faites lui-même et approuver chaque changement que vous faites en cours de route. Cela ne veut pas dire qu'il devrait littéralement lire le code, mais plutôt le voir en action et confirmer «oui, c'est ainsi qu'il doit agir».

Si vous êtes le seul testeur de votre propre code, ce n'est pas déraisonnable - vous êtes déjà entièrement concentré sur le projet, et s'il veut la perfection, il devrait prendre la responsabilité d'assurer lui-même cette perfection.

De plus, prenez des notes sur tout ce qu'il approuve, de sorte que plus tard, quand il se rompt inévitablement, vous pouvez pointer vers votre documentation montrant qu'il l'a approuvé.

Si, pour une raison quelconque, vous ne pensez pas que cela se passerait bien (par exemple, si lui demander de faire plus de travail est quelque chose que vous savez déjà être désastreux), tout ce que vous pouvez vraiment faire est autant de tests d'erreur difficiles que vous pouvez, écrivez dans vos rapports tout ce que vous savez fonctionne correctement et donnez-lui l'assurance à 100% que «dans les limites de mes tests, je suis confiant à 100% dans ces changements».

Malheureusement, vous pouvez être dans la position d'avoir un «patron» dont la compréhension de votre travail est limitée, ce qui est toujours pénible lorsque vous essayez d'expliquer comment la correction d'erreurs est impossible à maintenir avec une confiance à 100%. Donc, pour résumer, votre meilleur pari pourrait être de faire de votre mieux, de tout enregistrer et de faire comprendre que vous faites ce que vous pouvez dans vos propres limites.

Quelques bonnes réponses ici, le PM a définitivement besoin d'être éduqué et d'en apprendre un peu plus sur ce que signifie écrire un logiciel.

Je ne veux rien répéter de cela, mais en ajouter un autre, idée plutôt inhabituelle. Cette méthode est plutôt risquée et dépend beaucoup de votre réputation, de la qualité de vos compétences (ou plus de la façon dont elles sont perçues), de votre personnalité et de celle de votre PM. Je suppose que vous ne l'avez pas mal compris, et il veut vraiment dire 100% (je vois souvent des gens dire 100%, mais qui signifie vraiment "faites de votre mieux")

Cela a fonctionné pour moi une fois, et c'est la seule raison dont je parle ici. Tu étais prévenu. C'est la plupart du temps une manière possible d'éduquer un PM si tous les autres moyens échouent.

Parfois, un PM (ou tout autre manager) ne veut tout simplement pas écouter, donc vous devez quelque part le faire (ou le équipe) a heurté un mur pour s'arrêter un instant et réfléchir. Dans ce scénario, cela signifie: Travaillez aussi bien que vous le pouvez, essayez de tester aussi bien que vous le pouvez. Donnez le meilleur de vous-même, puis dites "Oui, je suis sûr à 100% que cela fonctionnera".

Si vous êtes extrêmement chanceux, aucun bug ne se produira jamais et tout le monde est content; mais en réalité, ce qui va se passer est: il y a un bug. Que devez-vous faire maintenant? Vous admettez que vous avez fait une erreur. Faites un lien avec les bugs et l'erreur d'être sûr à 100%. Les humains sont imparfaits et peuvent créer des bogues dans les logiciels. Les humains sont imparfaits et créent des bogues dans les tests. Par conséquent, les humains sont imparfaits et peuvent "créer des bugs" dans leur perception d'être sûr à 100% qu'il n'y a pas de bogue.

Présentez-le bien, et 100% étanche (haha, j / k, le 100% encore). Assurez-vous qu'après tout cela, le message qui est passé est "Je ne peux pas être sûr à 100% de mes tests". Si le PM ne peut alors pas faire l'étape logique de "Ce sera la même chose pour tous les développeurs" alors tout espoir est probablement perdu ...

Mais s'il vous plaît, essayez d'abord d'autres choses!

Je répondrais de la manière la plus mathématique, considérant qu'il demande une probabilité avec 100% de confiance, et ignorant complètement l'effet que les distributions statistiques auraient sur un tel nombre: vous devriez lui donner 2 ou 3 nombres, avec confiance associée: 1 semaine à 90%, 2 semaines à 95%, 6 mois à 100%. Le dernier chiffre était exagéré, mais je suis sûr que vous avez compris.

Voir l'article de Wikipedia sur les intervalles de confiance pour en savoir plus.

L'indicateur clé est qu'il s'agit d'un changement récent. Quelque chose (ou quelqu'un) a probablement donné une mauvaise expérience à votre PM, et maintenant il est à bout à chaque fois que quelque chose change. Ou peut-être a-t-il lu quelque chose dans un livre ou un magazine.

Si vous pouvez amener le Premier ministre à vous raconter son histoire (peut-être sur la boisson de son choix), alors vous pouvez sympathiser et il peut devenir réceptif à "l'innovation "aka une pratique solide en génie logiciel.

Voici votre chance de parler de l'erreur humaine et des moyens que cette industrie a trouvés pour augmenter le niveau de confiance dans nos conceptions et notre code. Pour parler des compromis en matière de confiance, de qualité, de ressources et de calendrier qui découlent de différentes approches de test, de révision du code par les pairs, de méthodes formelles (alias correction par construction).

Parlez son langage: Utilisez une métaphore pour illustrer l'ampleur du problème. S'agit-il de 40 000 lignes de code? Dites-lui que c'est comme un mystère de meurtre de 600 pages dans une langue étrangère. Si vous voulez changer quelque chose au milieu du chapitre 12, comment vous assurer que cela n'entraîne pas de rupture de continuité avec le reste de l'histoire?

Recherchez l'adhésion sur les moyens d'augmenter confiance envers un objectif acceptable dans des limites économiques raisonnables. Vous ne pourrez pas mettre en œuvre le modèle de maturité de capacité SEI niveau 5 du jour au lendemain. Mais vous pourrez peut-être passer de la question actuelle à "la suite de tests de régression automatisée réussit-elle?" et "comment exprimer cette nouvelle exigence dans le système de test de régression?"