Wie kann man vermeiden, sich selbst und ehemalige Mitarbeiter schlecht aussehen zu lassen, wenn man über die Reparatur der Arbeit ehemaliger Mitarbeiter berichtet?

Ein ehemaliger unbescholtener Mitarbeiter hat die Stelle gewechselt. Leider erfüllte ein Großteil ihrer Arbeit kurz vor dem Verlassen einige von der QA gefundene Akzeptanzkriterien nicht und hatte andere Fehler. Ich nehme den Durchhang auf, um sie zu reparieren. Ich gehe davon aus, dass es für mich nicht trivial ist, mit dem Reparieren zu beginnen (aufgrund meiner geringeren Fähigkeiten / Kenntnisse), und mich eine Weile durcharbeiten muss, und wie ich am besten während des täglichen Stands darüber sprechen kann UPS?

Meine Ziele sind

  1. Damit es nicht so klingt, als würde ich schlecht über den Kodex oder den ehemaligen Mitarbeiter sprechen, der gegangen ist und dessen Arbeit ich repariere.
  2. zu versuchen, mich nicht schlecht aussehen zu lassen, da ich damit beschäftigt sein werde, etwas zu reparieren, das die Musterung nicht bestanden hat (ich denke, es sieht schlecht aus, wenn Sie Dinge pushen, die beim Testen Probleme haben), für mindestens einen einzigen Sprint , wobei ich möglicherweise nicht so viel zu der neuen Arbeit beitrage, die wir eingebracht haben.
    • Das soll nicht so klingen, als würde ich versuchen, die Verantwortung für die Behebung des Problems abzulenken, aber ich möchte sicherlich nicht mit der Ursache dieser Probleme verwechselt werden.

Bearbeiten: Zur Klarstellung, dass die Tickets unseren QA-Prozess zurückgewiesen haben, da sie nicht alle Akzeptanzkriterien in ihnen erfüllten und einige andere Fehler gefunden wurden, also ist es vielleicht nicht präzise zu sagen, dass sie nur Fehler hatten. (Der Code ist jedoch bereits hinter einem Feature-Flag eingebunden.)

Haben Sie eine Ahnung, warum ein Großteil ihres Codes kurz vor der Abreise fehlerhaft war? "Vernünftige Erklärungen" können hier viel helfen. Wenn sie zum Beispiel versuchen würden, vor dem Abflug mit einem großen Teil der Arbeit fertig zu werden, dann würde das eine Menge Erklärung liefern.
@BenBarden, dass er vor der Abreise ins Ziel eilt, ist eine faire Annahme, obwohl ich ihren Fortschritt nicht so genau im Auge behalten habe
Wurden Sie beauftragt, die Fehler/Gesamtqualität zu beheben, oder übernehmen Sie das selbst? Wenn Sie zugewiesen wurden, weiß vermutlich Ihr Vorgesetzter (der wirklich die einzige Person ist, die zählt) bereits, woher die Fehler stammen und warum Sie daran arbeiten.
@GreySage Ich bin davon ausgegangen, dass ich mich darum kümmern würde, da wir kleine Teams haben.

Antworten (5)

Du machst dir um nichts Sorgen. Software hat Fehler, das ist unvermeidlich, und jeder weiß es. QA findet Fehler, fügt sie hoffentlich in ein Fehlerverfolgungssystem ein, und Sie nehmen einen Fehler aus dem Fehlerverfolgungssystem, beheben ihn, dann den nächsten und so weiter, bis Sie fertig sind.

Woher dieser Fehler kommt, muss nicht erwähnt werden. Niemanden interessierts. Wenn Sie jemand fragt, warum es so viele Fehler gibt, sagen Sie „weil QA gute Arbeit leistet“. Wenn sich tatsächlich jemand beschwert, fragen Sie hier noch einmal nach und schildern Sie uns seine Beschwerde.

Woher weißt du, dass du „fertig“ bist?
@Gherman Sie sind fertig, wenn QA entweder keine Fehler findet (selten) oder wenn gefundene Fehler nicht dringend/groß genug sind, um eine "jetzt" Behebung zu rechtfertigen. Fertig bedeutet normalerweise, dass die Software alle Anforderungen erfüllt und funktionsfähig genug ist, um ein gewisses Maß an Qualitätstests zu bestehen (das Qualitätsniveau hängt von der Zielgruppe, der Art der Software usw. ab).
> keine Notwendigkeit zu erwähnen, woher dieser Fehler kommt. Niemanden interessierts. Die Organisation, mit der ich zusammenarbeite, kümmert sich mehr als alles andere darum - warum gibt es überhaupt Fehler (fehlende Feature-Definition, mangelndes Domänenverständnis, fehlende explorative Tests usw.) Ich fand es nur erwähnenswert, dass es von der Organisation abhängig ist - Einige Organisationen kümmern sich sehr darum, woher die Fehler stammen (manchmal mehr als was der Fehler selbst war).
@Gherman Wenn Sie den Job verlassen oder das Produkt das Ende seiner Lebensdauer erreicht. Aber dann fängst du mit dem nächsten wieder von vorne an.
@ user2152081, dies bewegt sich auf dem schmalen Grat zwischen dem Versuch, ihren Prozess zu verbessern, und der einfachen Suche nach Sündenböcken. Wenn Sie mehr Zeit damit verbringen, die Fehlerquelle zu ermitteln, nehmen Sie sich diese Zeit für die Entwicklung neuer Funktionen, was Ihrer Organisation zugute kommt. mehr. Der Versuch, perfekt zu sein, verursacht Probleme und ist normalerweise eher schädlich als nützlich.
@ user2152081 Interessieren sie sich für dieses Zeug, sogar für die aktive Entwicklung neuer Funktionen? Das scheint extrem und möglicherweise wasserfallartig zu sein?
Wenn es einen Mitarbeiter gibt, der viele Fehler erstellt, beeinträchtigt er möglicherweise den Entwicklungsprozess, und das sollte vom Management gehandhabt werden. Aber wenn die Fehler von einem ehemaligen Mitarbeiter stammen, kann man nicht viel dagegen tun, außer zu versuchen, sie zu beheben.
Ich bin mit dieser Antwort etwas nicht einverstanden. Wenn Sie hin und wieder sagen "Ja, das ist schwierig, weil der Code nicht optimal ist", könnten sie anfangen zu denken, dass dies das Ergebnis der aktuellen Mitarbeiter ist.
OP scheint ein bisschen besorgt zu sein, weil er nicht möchte, dass andere denken, dass er die Person ist, die die Fehler verursacht hat. In dieser Hinsicht denke ich, dass eine Antwort, die besagt : „Entschuldigung, dieser Code war bereits vorhanden, als ich anfing, daran zu arbeiten, und ich mache mich immer noch mit der Codebasis vertraut“, eine vernünftige Antwort wäre, die OP dabei helfen kann, festzustellen, dass es einen gibt Teilmenge dieser Fehler, die nicht von OP verursacht wurden.
@computercarguy Das Unternehmen leidet unter ziemlich schwerwiegenden Qualitätsproblemen, die das Vertrauen der Kunden untergraben. Einverstanden, es ist ein Gleichgewicht, aber das Beheben von Fehlern verbessert die Qualität langfristig nicht wesentlich - der Prozess muss verbessert werden, damit die Fehler überhaupt nicht existieren. Fehlerhafte neue Funktionen enttäuschen die Leute, selbst wenn die Fehler schließlich behoben werden. Also nein, neue Funktionen werden der Organisation unter diesen Umständen nicht mehr helfen, wenn diese neuen Funktionen die Benutzer mit ihrer Fehlerhaftigkeit zu sehr frustrieren. Ich wollte nur darauf hinweisen, dass diese Antwort nicht meine Erfahrung mit großen Unternehmensprojekten widerspiegelt.
@DavidRice Sie sind überrascht, dass es für eine Organisation interessant ist, woher neue Fehler kommen? Anders ausgedrückt: Wenn Sie einen Fehler beheben, beheben Sie einen Fehler, wenn Sie die Grundursache angehen, beheben Sie möglicherweise viele Fehler. Ja, die Organisation (und ich selbst) kümmern uns um die Grundursache für Fehler, die durch neue Arbeit eingeführt werden. Probleme aktiv zu analysieren und den Prozess zu ändern, um diese Probleme zu vermeiden, klingt nach einem Wasserfall? Agile bedeutet nicht „Schiffsfehler“, es gibt einen Platz in Agile für felsenfeste MVPs, die im Umfang begrenzt, aber nicht robust sind.
@ user2152081, also ja, es gibt einen Unterschied zwischen "wir sind bereits zu 99 % perfekt, aber wir wollen 100 % sein" und "wir müssen dieses Monster unter Kontrolle bekommen". Wenn die org. versucht, perfektionistisch zu sein, trifft mein Kommentar zu, aber ich habe auch an Stellen mit extrem fehlerhaftem Legacy-Code gearbeitet, der wenig bis gar keine vorherige QA, halbfertige Funktionen und Schlimmeres hatte. In diesem Fall ist es definitiv nützlich, die Ursache von Fehlern zu finden, kann aber dennoch wertvolle Zeit verschwenden, um Dinge zu beheben, wenn die Ursache gefunden werden "muss", bevor der Fehler behoben wird.
@user2152081 Ich würde keine Fehler ausliefern, aber wenn ich an einer neuen Funktion arbeite, codiere ich sie und die Qualitätssicherung findet einen Fehler im neuen Code, behebe ich ihn, bevor er dem Kunden vorgeführt wird, oder wenn es sich um einen handelt Wenn es einen grundlegenderen Fehler in der Funktion gibt, besprechen wir ihn mit dem Kunden, aber mich mehr darum zu kümmern, warum es einen Fehler gibt, als darum, dass es einen Fehler gibt, erscheint mir seltsam.
@DavidRice definitiv, ich war ein bisschen übertrieben, es gibt sehr wichtige Fehler. Wir haben diese Trennung zwischen Entwickler und QA nicht, wir arbeiten Hand in Hand und im Allgemeinen ist QA mehr für explorative/Regressionstests als für die Funktionsüberprüfung da. Kleinere Fehler verschwinden nie, aber sie weisen normalerweise auf fehlende Domänenmodellierung, architektonische Komplexität usw. hin. Der aktuelle Status quo ist, dass Fehler, die in neuen Funktionen gefunden werden, im Allgemeinen unvorhergesehene Interaktionen sind, sobald die Entwicklung abgeschlossen ist, gibt es „keine Fehler " in dem relativ kleinen Umfang, der den Aufwand unterstützt. Dev führt QA durch.
@DavidRice Zu verstehen, warum ein Fehler aufgetreten ist, ist entscheidend, um die Gesamtrate der von einer Organisation generierten Fehler zu reduzieren. Es kann sein, dass die meisten Fehler aufgrund unvollständiger oder falscher Spezifikationen entstehen. Oder vielleicht ist es eine Codebasis von schlechter Qualität, die dringend überarbeitet werden muss. Vielleicht gibt es einen Entwickler im Team, der inkompetent ist. Sobald die Ursachen bekannt sind, können Maßnahmen ergriffen werden, um Fehlerraten zu reduzieren, die Codequalität zu verbessern und die Markteinführungszeit für neue Funktionen zu verkürzen.

Im Stand-up sollten Sie nur die Fakten angeben:

  • Gestern habe ich an Fehler Nr. 532 gearbeitet, bei dem es darum ging, dass die Widgets die falsche Farbe hatten. Abgeschlossen und es ist bereit für den nächsten Einsatz.
  • Heute werde ich an Bug #536 über den Absturz beim Versuch, mehr Widgets zu bestellen, arbeiten.
  • Möglicherweise blockiert, weil ich die Interaktionen mit dem Back-End-Bestelldienst nicht verstehe. Mit wem kann ich darüber reden?

Alles andere ist für das Aufstehen nicht möglich. Darüber hinaus hat Sie jemand (Ihr Teamleiter, Ihr Manager, wer auch immer Ihnen Arbeit zuweist) gebeten, an diesen Problemen zu arbeiten, damit sie bereits wissen, woher sie kommen und warum Sie keine neuen Funktionen zum Sprint beitragen. Lass sie sich darum kümmern.

Das ist ausgezeichnet, lassen Sie das Team / den Manager seine eigenen Schlussfolgerungen ziehen. Es wird nicht auf dich zurückfallen, weil du darauf gekommen bist, nachdem es bereits „kodiert“ war, und es beschleunigen musst.

  • 1) Lassen Sie es nicht so klingen, als würde ich schlecht über den Kodex oder den ehemaligen Mitarbeiter sprechen, der gegangen ist und dessen Arbeit ich repariere.

    Nun, Sie sprechen über die Probleme im Code, ohne den Warum (oder Wen)-Teil zu erwähnen, Fehler sind da und sie müssen behoben werden - das war's.

  • 2) Versuchen Sie, mich nicht schlecht aussehen zu lassen, da ich damit beschäftigt sein werde, etwas zu reparieren, das die Musterung nicht bestanden hat (ich denke, es sieht schlecht aus, wenn Sie Dinge pushen, die beim Testen Probleme haben), für mindestens eine Sprint, wobei ich vielleicht nicht so viel zu der neuen Arbeit beitrage, die wir hereingeholt haben.

    Es ist nicht Ihre Aufgabe, sich um den Auftrag zu kümmern. Sobald Ihnen etwas zugewiesen wurde, sollten Sie sich nur darum kümmern, ob Sie Ihre Aufgaben wie erwartet erledigen (oder zumindest Fortschritte machen) oder nicht. Warum Sie an etwas arbeiten, liegt fast immer über Ihrer Gehaltsstufe.

  • 2.5) Klingt nicht so, als würde ich versuchen, die Verantwortung für die Behebung abzulenken, aber ich möchte sicherlich nicht mit der Ursache dieser Probleme verwechselt werden.

    Warum denkst du so? Der Code wurde von jemand anderem geschrieben, die QA-Prüfung wurde von jemand anderem durchgeführt, Sie sind derjenige, der ihn repariert. Niemand wird Sie hier für die Ursache des Problems halten.

Also, um abschließend zu antworten:

Wie sollte ich am besten bei täglichen Stand-Ups darüber sprechen?

Genauso, wenn die Fehler im Code eines anderen gefunden worden wären, der noch im Team arbeitet. Ein Fehler wird gefunden, Sie werden beauftragt, ihn zu beheben, den Fortschritt zu nennen, den Sie gestern gemacht haben, und den Plan für heute anzugeben; Erwähnen Sie auch, ob Sie Hilfe vom Team benötigen, um ein Hindernis zu überwinden. Du bist fertig.

Ich mag dieses, rede einfach über den Code und die Fehler, beschuldige den Code „Ich fand, dass er das nicht getan hat“ „Ich verbessere das …“
„Warum denkst du so? Code wurde von jemand anderem geschrieben, QA-Check wurde von jemand anderem durchgeführt, du bist derjenige, der es repariert. Niemand wird dich hier für die Ursache des Problems halten.“ Wenn sie jetzt für Feature X verantwortlich sind und es Probleme mit Feature X gibt, dann könnten die Leute ganz leicht annehmen, dass sie der Grund für die Probleme mit Feature X sind. Sie wissen vielleicht nicht oder erinnern sich nicht, dass jemand anderes vorher war verantwortlich für Feature X, und sie wissen möglicherweise nicht, wann die Probleme in den Code eingeführt wurden.
@AnthonyGrist Dann brauchen Sie einen besseren Manager. Ich möchte auf keinen Fall, dass mein Vorgesetzter es „vergisst“. Beachten Sie auch, dass dies im Zusammenhang mit einem Stand-up-Meeting steht, sodass das Team (agile) klein (idealerweise 2 bis 7) und kohärent ist.

Es gibt einige zugrunde liegende Konzepte von Scrum, die in der von Ihnen beschriebenen Situation nicht effektiv berücksichtigt werden und zu Ihren Bedenken führen.

1) Das gesamte Team soll für die Fertigstellung der Arbeit verantwortlich sein. Ein bestimmtes Feature wird erst dann ausgeführt, wenn es implementiert, getestet und möglicherweise gemäß dem Standard der Definition of Done veröffentlicht werden kann. Sie erwähnen alte Arbeit vs. neu zugesagte Arbeit, aber dies ist zugesagte Arbeit, die das Team noch nicht beendet hat. Sie helfen dem Team, diese Arbeit abzuschließen. Dies sollte definitiv kein schlechtes Licht auf Sie werfen oder als alte Arbeit angesehen werden.

2) Die Entwicklung in Scrum ist adaptiv. Oftmals müssen wir Dinge umgestalten oder "reparieren", nicht weil wir vorher Fehler gemacht haben, sondern weil sich die Dinge seitdem geändert haben. Das ist normal.

3) Wir sind Menschen und die perfekte Beherrschung irgendeiner Fähigkeit ist unmöglich. Scrum verlangt von uns, dass wir danach streben, ein Team zu sein, das Fehler erkennen und unsere Arbeitsweise verbessern kann, ohne dass es ein persönlicher Angriff ist, und kein Team, das diese Gespräche vermeidet. Wenn Sie sagen möchten, dass Sie einen Fehler beheben, den jemand gemacht hat, gilt dies als schlimm, das ist wirklich eine tiefe psychologische Sicherheitsherausforderung im Team, die unbedingt angegangen werden muss.

Ich sehe in der Frage keine ausdrückliche Erwähnung von Scrum. Die Punkte, die Sie machen, sollten jedoch auf jeden agilen Prozess anwendbar sein. Und Nr. 3 (nicht auf den Boten schießen) ist besonders wichtig für jede Organisation / jedes Team / was auch immer, das danach strebt, mehr als nur dysfunktional zu sein.
Es war nicht. Es wurde nur aus den Tags gefolgert.

Melden Sie einfach dem Bugtracker des Unternehmens und Ihrem Vorgesetzten, was der aktuelle Status des Codes ist, indem Sie die einfache Wahrheit sagen und nichts verschweigen.

Versuchen Sie beim Ausfüllen des Bugtrackers, den Namen des ehemaligen Entwicklers so weit wie möglich zu vermeiden, und vermeiden Sie auch Adjektive (schlecht, arm, beschissen ...). Konzentrieren Sie sich einfach auf Fakten.

Treffen Sie sich mit Ihrem Vorgesetzten und/oder dem Team, um die Situation und die erforderlichen Ressourcen zu erklären, um die gesamte Reparatur durchzuführen: Vielleicht brauchen Sie noch ein paar Wochen, vielleicht wird ein anderer Entwickler benötigt, vielleicht eine Schulung für Sie usw. Ihr Vorgesetzter kennt Sie und Ihre Stärken, wenn also ein Käfer Wissen braucht, das Sie nicht haben, sollte er Sie nicht beschuldigen.

Wie kann man vermeiden, sich selbst und ehemalige Mitarbeiter schlecht aussehen zu lassen, wenn man über die Reparatur der Arbeit ehemaliger Mitarbeiter berichtet?
AntwortenHierDatenschutz-Bestimmungen1y, 0v