Der Projektmanager bittet jedes Mal, wenn er Code festschreibt, um absolutes 100-prozentiges Vertrauen

Wie soll ich in diesem Fall auf seine Frage antworten, ohne inkompetent zu wirken? Ehrlich gesagt habe ich nie 100% Vertrauen auf die gesamte Website, aber ich habe Vertrauen in meine Testmethoden. Und als Entwickler weiß ich auch, dass es nicht ungewöhnlich ist, dass später durch diese Kernänderungen unerwartete Fehler auftreten.

Der Projektmanager versteht Software nicht gut genug und schon gar nicht gut genug Testen. Vielleicht muss er erzogen werden.

Wenn Sie eine professionelle QA-Abteilung haben, würde ich Ihnen raten, die Unterstützung des QA-Managers in Anspruch zu nehmen, um diesem Projektmanager die Natur der Software, die Natur der Fehler und die Natur des Testens zu erklären. Ich würde den QA-Manager bitten, anzugeben, warum es einfach nicht möglich ist, jede Bedingung zu testen, und dass das Freigeben/Nicht-Freigeben eine Geschäftstätigkeit ist, die durch die Erkenntnisse aus dem Testen unterstützt wird, aber niemals durch perfekte Informationen.

Vielleicht möchten Sie sich ein Exemplar von Gerald Weinbergs ausgezeichnetem Buch „ Perfekte Software und andere Illusionen über das Testen “ besorgen. In Kapitel 3 („Warum nicht einfach alles testen?“) hat Weinberg einen Abschnitt mit dem Titel „Es gibt unendlich viele mögliche Tests“.

Er spricht von einer Hintertür, die in ein hochsicheres Programm eingebaut wurde, wodurch der gewöhnliche Passwortschutz umgangen werden konnte, indem man W gefolgt von drei Leerzeichen, dann M gefolgt von drei Leerzeichen, dann J gefolgt von genau 168 weiteren Tastendrücken eintippte, ohne ein einziges Mal den Buchstaben L zu verwenden.

Dann schreibt er: „Haben Sie den Sinn inzwischen verstanden? Wenn Sie nicht erraten haben, dass die Anzahl der Tests, die erforderlich sind, um Software umfassend zu testen, unendlich ist, oder zumindest „eine Anzahl größer ist, als ich in meinem Leben ausführen könnte“, haben Sie es getan Ich verstehe den Sinn dieses Kapitels nicht. Jetzt tust du es.“

Erklären Sie Ihrem Projektmanager, dass jeder zusätzliche Testtag Ihr Vertrauen in Ihren Code etwas verbessert, aber niemals 100 % erreichen kann. Sagen Sie ihm, dass Sie das Testen gerne auf Kosten Ihrer anderen produktiven Arbeit fortsetzen würden. Fragen Sie ihn dann, wie viele Tage Sie noch mit dem Testen verbringen möchten und welche Ihrer anderen Arbeiten zurückgestellt werden sollen.

Wenn Ihr Projektmanager es immer noch nicht versteht und Sie sich etwas leichtsinnig fühlen, fragen Sie ihn, ob er zu 100 % davon überzeugt ist, dass jeder von ihm veröffentlichte Kostenvoranschlag genau richtig ist und keine Fristen überschritten werden. Fragen Sie ihn, ob er sich zu 100 % sicher ist, dass keine E-Mail, die er schreibt, jemals einen Tippfehler enthalten wird. Fragen Sie ihn, ob er sich zu 100 % sicher ist, dass er niemals einen Fehler machen wird – jetzt und in Zukunft.

Boss: Sind Sie zu 100 % davon überzeugt, dass dieser Fix keine bestehenden Funktionen beschädigt oder negative Auswirkungen auf die Benutzererfahrung hat?

Ich: Nein. Da wir keine Testsuite mit 100 % Abdeckung haben, gibt es keine Möglichkeit zu überprüfen, ob eine Codeänderung einen Anwendungsbruch oder nachteilige Auswirkungen verhindert. Ich habe jedoch die folgenden Aktionen durchgeführt, um sicherzustellen, dass es unwahrscheinlich ist, dass es auf unbeabsichtigte Weise ausgeführt wird:

• Ich habe den Umfang der Änderung auf das betroffene Modul beschränkt
• Ich habe die Dokumentation gelesen und entsprechend aktualisiert
• Ich habe die Komponententests für dieses Modul und die betroffenen Module ausgeführt
• Ich habe Einheitentests erstellt, um neu hinzugefügte Funktionen zu überprüfen, und veraltete Tests, die aufgrund der Änderung nicht mehr relevant sind

Obwohl ich Ihnen keine hundertprozentige Sicherheit geben kann, habe ich so viel Sicherheit wie möglich innerhalb des Zeitrahmens gegeben, der meiner Meinung nach für die Implementierung dieser Funktionalität angemessen ist. Tatsächlich habe ich bereits den Punkt der abnehmenden Erträge erreicht. Ich kann weitere 5 Stunden aufwenden, um Ihnen weitere 0,1% Sicherheit zu geben, aber es ist bereits eine so geringe Chance, dass ein solcher Aufwand nicht gerechtfertigt ist. Sie sind jedoch für das Projekt und den Zeitrahmen verantwortlich, also lassen Sie mich wissen, wie viel mehr Zeit ich für diese Funktion aufwenden soll.

Jetzt liegt der Ball bei ihm. Wenn er wirklich will, dass ich meine persönliche Einschätzung von, sagen wir, 95 % sicher auf 95,1 % sicher ändere, um ein paar Stunden mehr zu arbeiten, dann hey – das kann ich tun.

Wenn er weiterhin unausstehlich darüber ist, werde ich eine E-Mail-Konversation mit ihm und dem „Eigentümer“ des Projekts über diese „100 % getestet“-Anforderung führen und darüber, welche Ressourcen meines Erachtens erforderlich sind, um sie zu erfüllen.

Als Entwickler testen Sie UNIT die Änderungen an Ihrem Code. Meiner Meinung nach (als Entwickler) heißt das, zu überprüfen, ob es keine offensichtlichen Fehler gibt, alles kompiliert, alle Fehler abgefangen werden. Sie haben keine Möglichkeit zu wissen, welche Szenarien auftreten werden, sobald der Code live geht (schlechte Daten, unerwartete Eingaben, Änderungen in der Client-Software, die Liste ist endlos).

Um hundertprozentig darauf vertrauen zu können, dass eine Änderung nichts beeinflusst, benötigen Sie eine Testumgebung, die die Live-Umgebung EXAKT widerspiegelt (Daten, Hardware, Berechtigungen, Konnektivität) und eine Reihe von Testskripten, die jedes einzelne Szenario abdecken. Dies ist bekanntlich aus verschiedenen Gründen eine praktisch unmöglich zu schaffende Umgebung

Wenn er 100 % Vertrauen erwartet, muss er das Umfeld und die Arbeitskraft bereitstellen, um seine Erwartungen zu untermauern

Es ist ein bisschen so, als würden Projektmanager und Kunden zukunftssichere Sachen fordern!

Es klingt, als wäre er einer schlechten Angewohnheit verfallen. Er stellt eine Frage, von der er weiß, dass sie auf einer gewissen Ebene albern ist. Aber es gibt ein bisschen ein zwanghaftes Element. Ich vermute, dass er aufgrund einer zugrunde liegenden Angst handelt, und wenn er eine unvernünftige Frage stellt, fühlt er sich besser unter Kontrolle.

In solchen Situationen versuche ich, die Dynamik zu zerstreuen, indem ich selbstbewusst bin und ein wenig Humor einbringe. Wenn Sie verstehen, dass seine Frage nicht aus Vernunft, sondern aus Angst kommt, dann können Sie das besser indirekt als direkt ansprechen.

In solchen Situationen nehme ich den Führungskräften meist die Angst, indem ich alle Maßnahmen präsentiere, die ich zur Qualitätssicherung getroffen habe. Er ist schließlich der Kunde und muss wissen, dass Ihre Prioritäten mit seinen übereinstimmen. Sehen Sie sich diese Unit-Tests an. Sehen Sie sich diese Überwachung an. Sehen Sie sich an, wie der Code strukturiert ist, um Änderungen lokal und modular zu halten. usw. Wenn Sie ein Gefühl von Selbstvertrauen und Kontrolle vermitteln, wird dies seine Angst lindern und Sie werden wahrscheinlich in der Lage sein, ein vernünftigeres Gespräch zu führen.

Hier kommt die Kunst dieses Geschäfts ins Spiel. Nicht nur „funktioniert“, sondern der Kunde hat ein gutes Gefühl dabei.

Letztlich ist es aber eine Geschäftsbeziehung. Wenn das Contracting für Sie bequem und rentabel ist, dann lohnt es sich, diese Marotte in Kauf zu nehmen. Es klingt nicht so, als würde er es ernst meinen, nur irgendwie hartnäckig. Wie ich schon sagte, er hat eine lästige Angewohnheit entwickelt. Wenn er anfängt, negativ zu reagieren und der Ton feindseliger wird, dann lohnt es sich aufgrund der Ausgewogenheit der Geschäftsvereinbarung möglicherweise nicht mehr für Sie. Aber nach Ihrer kurzen Beschreibung klingt es für mich so, als könnten Sie die Beziehung immer noch effektiv verwalten.

Viele Leute haben dies als Bildungsproblem beschrieben, und ich sage nicht, dass sie falsch liegen.

Es ist auch möglich, dass es ein politisches Problem ist. Was die Frage eigentlich bedeuten könnte, ist, dass der Projektleiter von der Verantwortung für eventuelle Fehler freigestellt werden möchte. Er bekommt eine eidesstattliche Erklärung von Ihnen, auf die er sich "vernünftigerweise" verlassen kann. Wenn also etwas schief geht, sagt er, dass er alles getan hat, um es zu verhindern, aber Sie haben versagt.

Das ist kein gutes Management und es ist auch nicht zu 100 % garantiert, dass es ihn in Sicherheit bringt, wenn es zu Problemen kommt.

Ich gebe zu, das ist Spekulation meinerseits, aber Po-Bedeckungsübungen sind im Berufsleben gar keine Seltenheit und man muss sich damit auseinandersetzen. Wenn dies also zutrifft, müssen Sie zur Lösung des Problems nicht nur den Manager darüber aufklären, dass 100%iges Vertrauen unmöglich ist. Sie müssen ihn auch davon überzeugen, dass ein Fehler keine Katastrophe ist – weder für ihn persönlich noch für das Unternehmen.

Dies kann zum Beispiel bedeuten, dass Beispiele für Fehler bereitgestellt werden, die zu angemessenen Kosten und ohne herumfliegende Schuld behoben werden. Es könnte bedeuten, dass er sich seine eigene Unternehmenskultur ansieht, ob es jemanden im Unternehmen gibt, der sich darauf vorbereitet, ihm ungerechterweise die Schuld zu geben, wenn etwas schief geht. Es könnte auch bedeuten, Verfahren einzuführen, um zukünftige Fehler so schnell und kostengünstig wie möglich zu beheben. Wenn das Unternehmen wirklich hundertprozentiges Vertrauen in den Code hätte, wären solche Verfahren sinnlos, weil es bereit wäre, beliebig viel Geld darauf zu setzen, dass es in Zukunft keine Fehler mehr gibt!

Als ultimative Sanktion, wenn er (der Arbeitgeber) Sie (den Auftragnehmer) bittet, ihm eine Zusicherung zu verkaufen, die Sie nicht über Ihre Arbeit geben können, und nichts seine Meinung in diesem Punkt ändern wird, dann können Sie dies nur klar sagen Sie können diese Zusicherung nicht geben, und er kann gerne jemand anderen einstellen, wenn er glaubt, dass es jemanden gibt, der dies kann. Natürlich ist das ein langer Weg, aber Sie sollten Ihre BATNA genauso gut kennen, bevor Sie beginnen.

Genau genommen kann man nie 100% sicher sein, dass ein Commit kein Programm kaputt macht.

Sogar mit allen Arten von Tests möglich (Unit-Tests, Integration, Komponenten, System, Handbuch, UI, Fuzz, Sicherheit, Penetration ... was auch immer). Dies ist auf ein Halteproblem zurückzuführen . Nachfolgend ein relevanter Auszug aus der Wikipedia:

In der Berechenbarkeitstheorie kann das Halteproblem wie folgt formuliert werden: "Entscheiden Sie bei einer Beschreibung eines beliebigen Computerprogramms, ob das Programm die Ausführung beendet oder für immer weiterläuft". Dies entspricht dem Problem, bei einem gegebenen Programm und einer Eingabe zu entscheiden, ob das Programm schließlich anhält, wenn es mit dieser Eingabe ausgeführt wird, oder für immer läuft.

Alan Turing bewies 1936, dass es keinen allgemeinen Algorithmus zur Lösung des Halteproblems für alle möglichen Programm-Eingabe-Paare geben kann. Ein wichtiger Teil des Beweises war eine mathematische Definition eines Computers und Programms, die als Turing-Maschine bekannt wurde; das Halteproblem ist über Turingmaschinen unentscheidbar.

Wenn Ihr PM Wert auf Wert und stabile, vorhersehbare Lieferung legt, können Sie ihn vielleicht davon überzeugen, sich das SCRUM-Framework anzusehen .

Andere haben viele interessante Ratschläge gegeben, wie Sie mit Ihrem PM interagieren können. Persönlich würde ich raten, ein Treffen mit Ihrem PM und dem Team zu vereinbaren, bei dem Sie Ihre Prozesse besprechen können. Ich bin ein starker Befürworter von SCRUM, daher würde dies weitgehend mit SCRUM zusammenhängen.

Ich würde versuchen zu erklären, dass ein Ziel von 100 % schwer fassbar ist. Es kann nicht erreicht werden. Niemals. Im ganzen Universum. Die Geschichte hat viele solcher Beispiele gesehen, zum Beispiel die Demo der Veröffentlichung von Windows 95 . Vor langer Zeit? Nun, sehen Sie, wie viele Red-Builds auf einem öffentlichen CI-Server für Open-Source-Projekte; Melden Sie sich als Gast an, wenn Sie dort kein Konto haben. Ein Ergebnis davon - Software wird fehlschlagen.

Zweitens würde ich raten, eine Praxis zu übernehmen, bei der Sie Wert liefern können , anstatt das Vertrauen einer Verpflichtung zu haben. Etwas, das den Kunden am Herzen liegt. Iterativ, immer wieder und zuverlässig. Jetzt können Sie die Perspektive Ihres PM von der 100%-Zusicherung auf etwas verschieben, das wirklich wichtig ist. Das heißt: Software ist im Einsatz, Ihr Produkt verbessert sich und das Team liefert dem Kunden einen Mehrwert.

Drittens sollte das eine Definition of Done sein. Etwas, das sich ein Entwicklungsteam einfallen lässt. Dazu können gehören: Dokumentation, Implementierung, Tests, Quality Gates usw. Dies ist sehr wichtig, da Sie jetzt die Subjektivität (das heißt „sind Sie sich 100% sicher?“) in die Objektivität (das sind alle Aufzählungspunkte der Definition von) verschieben können fertig sind abgeschlossen).

Es gibt andere sehr wichtige Schritte, die SCRUM fördert. Aber alle von ihnen würden es Entwicklern ermöglichen, solche Frustrationen zu mildern und es ihnen ermöglichen, im Vergleich zu subjektiven Zusicherungen objektiv quantifizierbare Ergebnisse zu liefern.

Die übliche Antwort für diese Art von Ziel sind Peer-Review und Regressionstests.

1) Übertragen Sie nichts in den Produktionscode-Stream, bis nicht nur der Autor, sondern ein oder mehrere andere Programmierer ihn auf Plausibilität geprüft haben, um sicherzustellen, dass er nur das ändert, was notwendig ist, dass er alle vereinbarten Kriterien erfüllt gute Codierungspraxis, dass es einen Test gibt, der Ihnen gute Chancen gibt, festzustellen, ob eine spätere Änderung die Logik erneut bricht, und so weiter.

2) Übergeben Sie nichts an den Produktionscode-Stream, bis ALLE Regressionstests erneut ausgeführt wurden und nachgewiesen wurde, dass nichts beschädigt wird, was der Test betrifft. Wenn während dieses Tests ein Fehler auftritt, muss die Änderung zurückgenommen werden, bis eindeutig festgestellt werden kann, dass sie das Problem nicht verursacht hat.

3) Alpha- und Beta-Tests früh und oft mit realen Kundenszenarien. Kunden werden Dinge mit Ihrem Code tun, die Sie nie erwartet hätten.

Keines davon ist 100%ig, noch ist es ihre Kombination. Aber sie bringen dich erheblich näher. Sie erfordern eine nicht unerhebliche Investition zusätzlicher Ressourcen. Sie verlangsamen die Entwicklung im Vergleich zu skunkworks-Codierungspraktiken „mach es einfach und wir beheben es, wenn es kaputt geht“. Aber wenn Sie wirklich fehlerfreien Code wollen, kann es diese Kosten mehr als wert sein, zu erkennen, dass Menschen fehlbar sind, und Praktiken einzuführen, die helfen, Fehler zu erkennen, bevor sie die Kunden erreichen.

Mir wurde gesagt, dass in dem Code, den IBM für die NASA geschrieben hat, nie ein Fehler gemeldet wurde – weil er während des Entwurfs, während der Entwicklung und vor der Veröffentlichung von Experten begutachtet und auf Herz und Nieren getestet wurde.

Wenn Sie etwas Lebenswichtiges tun, ist es diese Investition offensichtlich wert. Wenn Sie etwas tun, das Infrastruktur für große Unternehmen ist, ist es diese Investition wert; Sie wollen nicht derjenige sein, dessen Fehler die Geschäftsprozesse eines milliardenschweren Unternehmens lahmlegt.

Ja, es treibt gute Programmierer in den Wahnsinn. Bis zum ersten Mal rettet es ihren Hintern.

Die Wahrheit ist, dass es schlechte Tests sind. Die Realität ist, dass ein Unternehmen, das nicht bereit ist, in ein QA-Team zu investieren, schlechte Tests haben wird. Gute Tests sind teuer und brauchen Zeit. Das Unternehmen hat das Risiko in Kauf genommen, indem es die Zeit und das Geld nicht genehmigt hat.

Selbst ein QA-Team kann nicht garantieren, dass jede Möglichkeit getestet wird, da die möglichen Pfade durch ein komplexes Programm im Grunde unendlich sind. Sie werden Sie jedoch viel näher bringen, als Sie es jetzt gerade sind. Ein Grund dafür ist, dass es für einen Entwickler unmöglich ist, seinen eigenen Code angemessen zu testen. Sie wissen, was es tut, also neigen sie dazu, Tests um das herum zu entwerfen, was sie ihrer Meinung nach tun sollen. Sie übersehen Grenzfälle, sie übersehen dumme Dinge, die Benutzer tun, die ein Entwickler niemals tun würde, weil sie wissen, wie es funktioniert, sie interpretieren die Anforderung manchmal falsch, aber alle ihre Tests spiegeln ihre ursprüngliche falsche Interpretation wider. Sie übersehen oft Fehler in der Anforderung und tun das, worum sie gebeten werden, nicht das, was sie hätten tun sollen (dies ist die Ursache für eine große Anzahl von Fehlern, die erst nach den tatsächlichen Benutzern gefunden werden [die allzu oft nicht bei der Definition konsultiert werden die Anforderung] versuchen, die Software zu verwenden). Sie vermissen Auswirkungen auf Teile der Anwendung, für die sie nie einen Grund hatten, daran zu arbeiten, insbesondere an Teilen, die von Spezialisten durchgeführt werden (z. B. eine Tabellenänderung, die für die Anwendung sinnvoll ist, aber einen automatisierten Importprozess oder einen Bericht unterbricht).

Wenn er eine höhere Qualität will, muss er dafür sowohl Zeit als auch Geld bezahlen. Selbst mit vollständiger Qualitätssicherung können Sie nicht 100 % erreichen, obwohl die NASA und ihre Auftragnehmer sicherlich nahe dran sind. Sie geben auch viel mehr Geld aus, als Ihr Unternehmen ausgibt. Schon damals gelang es ihnen, den MARS einmal komplett zu verfehlen.

Wenn er die Gewissheit haben möchte, dass Probleme ihm bei den Kunden keinen Schaden zufügen, dann sprechen Sie über Ihren Testprozess (zeigen Sie ihm die Liste der von Ihnen durchgeführten Tests), was Ihrer Meinung nach betroffen wäre und wie Sie dies überprüft haben , Ihren Prozess, wie Sie einen fehlerhaften Push rückgängig machen würden, und Ihren Prozess zum Protokollieren von Fehlern, damit Sie sie sehen, bevor die meisten Clients sie bemerken. Geben Sie ihm das Vertrauen, dass selbst wenn es ein Problem gibt, es behoben werden kann. Sprechen Sie über den Wert, den Code (neues Feature oder Fix) schnell herauszubringen, im Gegensatz zu der zusätzlichen Zeit, die für gründlichere Tests erforderlich wäre. Sprechen Sie über die Risiken, wenn Sie es nicht schnell herausbekommen.

Sie können ihn auch bitten, jedes Mal, wenn Sie eine Änderung vornehmen, den gründlichen Regressionstest des Systems durchzuführen, da es einem Entwickler nicht möglich ist, seine eigene Arbeit vollständig zu testen (Sie wissen, was Ihre Annahmen waren, wenn sie nicht richtig sind, würden Sie es tun niemals darauf testen.) Stellen Sie sicher, dass er weiß, dass er jede einzelne Seite der Anwendung und jede einzelne Sache, die auf einer Seite getan werden könnte, in jeder möglichen Reihenfolge testen muss. Oh ja, testen Sie auch alle Importe/Exporte, Berichte und automatisierten Jobs. Und alle zugehörigen Anwendungen, die betroffen sein könnten. Wenn er einmal versucht hat, das System gründlich auszuprobieren, wird er erkennen, warum Sie diese Zusicherung nicht geben können.

Eine andere Sache, die Sie versuchen sollten, ist, ihm im Voraus zu sagen, dass Sie diese Garantie nicht geben können, aber wenn er X Teststunden autorisiert, können Sie dieser Garantie näher kommen. Geben Sie ihm eine detaillierte Liste der zusätzlichen Tests und der Stunden, die es dauern würde, jeden einzelnen zu entwerfen und auszuführen. Sagen Sie ihm, wie viel Prozent Vertrauen Sie nach der Durchführung all dieser Tests haben würden und wie viel Prozent Vertrauen Sie jetzt haben.

Teilen Sie ihm außerdem mit, wie lange es dauern würde, alle aktuellen Komponententests auszuführen, die Sie haben, unabhängig davon, ob sie mit diesem Problem zusammenhängen oder nicht. Wenn Sie also derzeit 1000 Unit-Tests haben und jeder fünf Minuten benötigt, um die Ergebnisse einzurichten, auszuführen und auszuwerten, wären das 83 Stunden. Bitten Sie ihn um die Genehmigung, weiterzumachen und diese Zeit zu verbringen.

Das Produkt besteht durchgehend aus vielen miteinander vermischten Teilen (nicht nur in sich geschlossenen Seiten), etwa 40.000 Codezeilen, die über 4 Jahre geschrieben wurden, und manchmal passieren unerwartete Dinge, die uns nicht einmal bewusst waren. Ich spüre, dass er dies als schlechtes Testen ansieht.

Das ist Ihr Problem, aber bis jetzt ist es nicht Ihre Schuld. Wenn Sie es nicht beheben, müssen Sie irgendwann die Verantwortung übernehmen. Sprechen Sie mit Ihrem Chef darüber, dass Sie niemals 100 % sein werden, bis dies behoben ist. Refactoring vorschlagen. Außerdem ist 100 % im Kopf von Laien nicht dasselbe wie bei einem Programmierer. Vielleicht sollten Sie angeben, dass Sie „zu 100 % sicher sind, dass der Kunde es wahrscheinlich nicht bemerkt“.

Es gibt kein QA-Team Dies ist ein Luxus, den sich Ihr Unternehmen nicht leisten kann, also sind Sie es. Stellen Sie sich vor, es gäbe ein QA-Team (Sie) und bestimmen Sie, wie lange sie brauchen würden, um Ihren Code zu testen, und setzen Sie das dann in Ihre Schätzung ein. Es gibt keine Möglichkeit, gleichzeitig zu codieren und QA zu machen, also geht das nicht parallel.

Hören Sie auf, so darauf bedacht zu sein, Code einzuchecken und scheinbar unvernünftige Forderungen zu erfüllen. Gib ihnen, was sie wollen. Sobald sie die Kosten (übermäßige Codierungszeit) herausgefunden haben, kann er seine Meinung ändern.

Wenn er Sie tatsächlich mikromanagt und Ihnen während des gesamten Prozesses des Aufbaus des Projekts über die Schulter schaut, gibt es einen einfachen Weg, um sicherzustellen, dass Sie 100% Vertrauen „garantieren“ können, ohne dass er Sie später darauf ansprechen muss.

Bringen Sie ihn dazu, es selbst zu genehmigen

Um es klar zu sagen, Sie sollten dies nicht als Forderung, sondern eher als Vorschlag machen, dass, wenn er wirklich 100% perfekten Code will, er sich ansehen sollte, was Sie tun, und jede Änderung genehmigen sollte, die Sie auf dem Weg machen. Das soll nicht heißen, dass er den Code buchstäblich lesen sollte, sondern ihn in Aktion sehen und bestätigen „Ja, so sollte er funktionieren“.

Wenn Sie der einzige Tester Ihres eigenen Codes sind, ist dies nicht unangemessen - Sie konzentrieren sich bereits vollständig auf das Projekt, und wenn er Perfektion will, sollte er selbst die Verantwortung dafür übernehmen, diese Perfektion sicherzustellen.

Machen Sie sich auch Notizen zu allem, was er genehmigt, damit Sie später, wenn es unweigerlich kaputt geht, auf Ihre Dokumentation verweisen können, die zeigt, dass er es genehmigt hat.

Wenn Sie aus irgendeinem Grund glauben, dass dies nicht gut ankommen würde (wenn Sie beispielsweise bereits wissen, dass es katastrophal wäre, ihn zu bitten, mehr Arbeit zu erledigen), können Sie nur so viele harte Fehlertests durchführen wie Sie kann, in Ihre Berichte alles schreiben, was Sie wissen, dass es richtig funktioniert, und ihm zu 100 % versichern, dass „ich im Rahmen meiner Tests zu 100 % von diesen Änderungen überzeugt bin“.

Leider sind Sie möglicherweise in der Lage, einen „Chef“ zu haben, der Ihre Arbeit nur begrenzt versteht, was immer mühsam ist, wenn Sie versuchen zu erklären, warum die Fehlerkorrektur nicht mit 100%iger Sicherheit aufrechterhalten werden kann. Zusammenfassend lässt sich sagen, dass Sie am besten einfach Ihr Bestes geben, alles aufzeichnen und verständlich machen, dass Sie tun, was Sie innerhalb Ihrer eigenen Grenzen tun können.

Hier gibt es einige nette Antworten, der PM muss definitiv geschult werden und ein wenig darüber lernen, was es bedeutet, Software zu schreiben.

Ich möchte nichts davon wiederholen, aber eine andere, eher ungewöhnliche Idee einwerfen. Diese Methode ist ziemlich riskant und hängt sehr stark davon ab, wie hoch Ihr Ruf ist, wie gut Ihre Fähigkeiten sind (oder besser gesagt, wie sie wahrgenommen werden) und sowohl von Ihrer Persönlichkeit als auch von der Ihres PM. Ich gehe davon aus, dass Sie ihn nicht missverstanden haben, und er meint wirklich 100% (ich sehe oft Leute, die 100% sagen, aber wirklich "tun Sie das Beste, was Sie können")

Es hat einmal bei mir funktioniert, und das ist der einzige Grund, warum ich es hier erwähne. Du wurdest gewarnt. Dies ist meistens eine Möglichkeit, einen PM aufzuklären, wenn alle anderen Mittel versagen.

Manchmal will ein PM (oder ein anderer Manager) einfach nicht zuhören, also müssen Sie ihn (oder das Team) irgendwo dazu bringen, gegen eine Wand zu schlagen, damit er einen Moment innehält und nachdenkt. In diesem Szenario heißt es: Arbeite so gut du kannst, versuche so gut du kannst zu testen. Geben Sie Ihr Bestes und sagen Sie dann „Ja, ich bin mir zu 100 % sicher, dass das funktioniert“.

Wenn Sie sehr viel Glück haben, wird niemals ein Fehler auftreten und alle sind glücklich; aber in Wirklichkeit wird Folgendes passieren: Es gibt einen Fehler. Was sollst du jetzt tun? Sie geben zu, dass Sie einen Fehler gemacht haben. Stellen Sie eine Verbindung zu Fehlern und dem Fehler her, 100% sicher zu sein. Menschen sind unvollkommen und können Fehler in Software erzeugen. Menschen sind unvollkommen und erzeugen Fehler in Tests. Folglich sind Menschen unvollkommen und können in ihrer Wahrnehmung, dass sie zu 100 % sicher sind, dass es keinen Fehler gibt, „Fehler erzeugen“.

Präsentieren Sie dies gut und 100% wasserdicht (haha, j/k, die 100% wieder). Stellen Sie sicher, dass nach all dem die Nachricht lautet: „Ich kann meinen Tests nicht zu 100 % vertrauen“. Wenn der PM dann nicht den logischen Schritt "Das wird für alle Entwickler gleich sein" machen kann, dann ist wahrscheinlich alle Hoffnung verloren ...

Aber bitte versuchen Sie zuerst andere Dinge!

Der Schlüsselindikator ist, dass es sich um eine kürzlich erfolgte Änderung handelt. Irgendetwas (oder jemand) hat Ihrem PM wahrscheinlich eine schlechte Erfahrung beschert, und jetzt ist er jedes Mal nervös, wenn sich etwas ändert. Oder vielleicht hat er etwas in einem Buch oder einer Zeitschrift gelesen.

Wenn Sie den PM dazu bringen können, Ihnen seine Geschichte zu erzählen (vielleicht bei einem Getränk seiner Wahl), dann können Sie mitfühlen, und er wird möglicherweise empfänglich für "Innovation", auch bekannt als solide Software-Engineering-Praxis.

Dies ist Ihre Gelegenheit, über menschliches Versagen und die Möglichkeiten zu sprechen, die diese Branche gefunden hat, um das Vertrauen in unsere Designs und unseren Code zu erhöhen. Um über die Kompromisse in Bezug auf Vertrauen, Qualität, Ressourcen und Zeitplan zu sprechen, die sich aus unterschiedlichen Testansätzen, Peer-Code-Review und formalen Methoden (auch bekannt als Correctness-by-Construction) ergeben.

Sprechen Sie seine Sprache: Verwenden Sie Metaphern, um die Größe des Problems zu veranschaulichen. Sind es 40.000 Codezeilen? Sagen Sie ihm, es ist wie ein 600-seitiger Krimi in einer fremden Sprache. Wenn Sie mitten in Kapitel 12 etwas ändern möchten, wie stellen Sie sicher, dass die Kontinuität mit dem Rest der Geschichte nicht unterbrochen wird?

Suchen Sie nach Möglichkeiten, das Vertrauen in ein akzeptables Ziel innerhalb angemessener wirtschaftlicher Grenzen zu stärken. Sie werden das SEI Capability Maturity Model Level 5 nicht über Nacht implementieren können. Aber vielleicht können Sie von der aktuellen Frage zu "besteht die automatisierte Regressionstestsuite?" und "wie drücken wir diese neue Anforderung im Regressionstestsystem aus?"

Ich würde es auf mathematischste Weise beantworten, wenn man bedenkt, dass er mit 100%iger Sicherheit nach einer Wahrscheinlichkeit fragt und die Auswirkungen, die statistische Verteilungen auf eine solche Zahl haben würden, völlig ignoriert: Sie sollten ihm 2 oder 3 Zahlen mit zugehöriger Sicherheit geben : 1 Woche bei 90 %, 2 Wochen bei 95 %, 6 Monate bei 100 %. Die letzte Zahl war übertrieben, aber ich bin sicher, Sie haben es verstanden.

Weitere Informationen finden Sie im Wikipedia-Artikel über Konfidenzintervalle .