Frage:
Wie kann vermieden werden, dass sich selbst und der ehemalige Mitarbeiter schlecht aussehen, wenn über die Reparatur der Arbeit des ehemaligen Mitarbeiters berichtet wird?
user1821961
2019-05-07 18:40:28 UTC
view on stackexchange narkive permalink

Ein ehemaliger Angestellter mit gutem Ruf hat seinen Arbeitsplatz gewechselt. Leider erfüllte ein Großteil ihrer Arbeit kurz vor der Abreise einige von der Qualitätssicherung festgestellte Akzeptanzkriterien nicht und wies andere Fehler auf. Ich nehme die Lücke auf, um sie zu reparieren. Ich erwarte, dass ein Teil davon für mich nicht trivial ist, um mit dem Reparieren zu beginnen (da meine Fähigkeiten / Kenntnisse geringer sind) und dies eine Weile durcharbeiten muss, und wie ich am besten im täglichen Stand darüber sprechen sollte UPS?

Meine Ziele sind

  1. , damit es nicht so klingt, als würde ich schlecht über den Code oder den ehemaligen Mitarbeiter sprechen, der gegangen ist und dessen Arbeit ich repariere.
  2. um 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, bei denen beim Testen Probleme auftreten), z Zumindest ein einziger Sprint, bei dem ich möglicherweise nicht so viel zu der neuen Arbeit beitrage, die wir eingebracht haben.
    • Es hört sich nicht so an, als würde ich versuchen, die Verantwortung für die Reparatur abzulenken, aber ich würde es auf keinen Fall tun. Ich möchte nicht mit der Ursache dieser Probleme verwechselt werden.
  3. ol>

    Bearbeiten: Um die Tickets zu klären, wurde unser QS-Prozess unterbrochen, da sie nicht die gesamte Akzeptanz erfüllten Es wurden Kriterien in ihnen und einige andere Fehler gefunden. Vielleicht ist es nicht präzise zu sagen, dass sie nur Fehler hatten. (Der Code ist jedoch bereits hinter einem Feature-Flag eingefügt.)

Haben Sie eine Idee, warum ein Großteil ihres Codes kurz vor dem Verlassen fehlerhaft war?"vernünftige Erklärungen" können hier sehr hilfreich sein.Wenn sie zum Beispiel eilten, um zu versuchen, vor der Abreise einen großen Teil ihrer Arbeit zu erledigen, würde dies eine ganze Menge Erklärungen liefern.
@BenBarden, der vor der Abreise ins Ziel eilt, ist eine faire Annahme, obwohl ich ihre Fortschritte nicht so genau beobachtet habe
Wurden Sie beauftragt, die Fehler / die Gesamtqualität zu beheben, oder übernehmen Sie diese selbst?Wenn Sie zugewiesen wurden, weiß vermutlich Ihr Manager (der wirklich die einzige Person ist, die zählt) bereits, woher die Fehler stammen und warum Sie daran arbeiten.
@GreySage Ich habe angenommen, ich würde mich darum kümmern, da wir kleine Teams haben.
Fünf antworten:
#1
+133
gnasher729
2019-05-07 18:58:34 UTC
view on stackexchange narkive permalink

Sie machen sich 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 Fehlerverfolger, beheben ihn, dann den nächsten und so weiter, bis Sie fertig sind.

Es ist nicht erforderlich zu erwähnen, woher dieser Fehler stammt. Niemanden interessierts. Wenn Sie jemand fragt, warum es so viele Fehler gibt, sagen Sie "weil die Qualitätssicherung einen guten Job macht". Wenn sich jemand tatsächlich beschwert, fragen Sie hier noch einmal und teilen Sie uns seine Beschwerde mit.

Woher weißt du, dass du "fertig" bist?
@Gherman Sie sind fertig, wenn die Qualitätssicherung entweder keine (seltenen) Fehler findet oder wenn die gefundenen Fehler nicht dringend / groß genug sind, um eine Behebung "jetzt" 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, dem Softwaretyp usw. ab).
> Sie müssen nicht 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 Domain-Verständnis, fehlende Erkundungstests usw.)?Einige Organisationen kümmern sich sehr darum, woher die Fehler stammen (manchmal mehr als der Fehler selbst).
@Gherman Wenn Sie den Job verlassen oder das Produkt das Ende seiner Lebensdauer erreicht.Aber dann fängst du wieder mit dem nächsten an.
@user2152081, Dies ist die Grenze 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 Zeit für die Entwicklung neuer Funktionen, die Ihrer Organisation helfen.Mehr.Der Versuch, perfekt zu sein, verursacht Probleme und ist normalerweise eher schädlich als nützlich.
@user2152081 Sie interessieren sich für dieses Zeug, selbst für die aktive Entwicklung neuer Funktionen?Das scheint extrem und möglicherweise wasserfallartig?
Wenn es einen Mitarbeiter gibt, der viele Fehler verursacht, kann dies den Entwicklungsprozess beeinträchtigen, und dies sollte vom Management behandelt werden.Aber wenn die Fehler von einem ehemaligen Mitarbeiter stammen, kann nicht viel dagegen getan werden, außer zu versuchen, sie zu beheben.
Ich bin mit dieser Antwort etwas nicht einverstanden.Wenn Sie von Zeit zu Zeit sagen: "Ja, das ist schwierig, weil der Code nicht optimal ist", denken sie möglicherweise, dass dies das Ergebnis der aktuellen Mitarbeiter ist.
OP scheint ein bisschen besorgt zu sein, weil er nicht möchte, dass andere denken, er sei die Person, die die Fehler verursacht hat.In dieser Hinsicht denke ich, dass eine Antwort mit der Aufschrift "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, dies festzustellenEs gibt eine Teilmenge dieser Fehler, die nicht durch OP verursacht wurden.
@computercarguy Die Organisation leidet unter ziemlich schwerwiegenden Qualitätsproblemen, die das Vertrauen der Kunden untergraben.Einverstanden ist es ein Gleichgewicht, aber das Beheben von Fehlern verbessert die Qualität auf lange Sicht nicht wesentlich - der Prozess muss verbessert werden, damit die Fehler überhaupt nicht existieren.Buggy neue Funktionen enttäuschen die Leute, auch wenn die Fehler irgendwann behoben sind.Nein, neue Funktionen helfen der Organisation unter diesen Umständen nicht mehr, 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, aus der neue Fehler stammen?Anders ausgedrückt: Wenn Sie einen Fehler beheben, beheben Sie einen Fehler. Wenn Sie die Grundursache beheben, beheben Sie möglicherweise viele Fehler.Ja, die Organisation (und ich) kümmern sich um die Grundursache für Fehler, die durch neue Arbeiten verursacht wurden.Das aktive Analysieren von Problemen und das Ändern des Prozesses, um diese Probleme zu vermeiden, klingt wie ein Wasserfall?Agil bedeutet nicht "Schiffswanzen", es gibt einen Platz in Agilität für solide MVPs, deren Umfang begrenzt ist, deren Robustheit jedoch nicht.
@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 bringen".Wenn die Org.Ich versuche, Perfektionist zu sein, mein Kommentar trifft zu, aber ich habe auch an Orten mit extrem fehlerhaftem Legacy-Code gearbeitet, der wenig bis gar keine vorherige Qualitätssicherung, halbfertige Funktionen und noch schlimmer hatte.In diesem Fall ist es auf jeden Fall nützlich, die Hauptursache für Fehler zu finden, kann aber dennoch wertvolle Zeit damit verschwenden, Probleme zu beheben, wenn die Ursache "gefunden" werden muss, bevor der Fehler behoben ist.
@user2152081 Ich würde keine Fehler versenden, aber wenn ich an einer neuen Funktion arbeite, codiere ich sie und die Qualitätssicherung findet einen Fehler im neuen Code. Ich behebe ihn, bevor er dem Kunden vorgeführt wird, oder wenn es sich um einen Fehler handeltGrundlegender Fehler bei der Funktion, wir besprechen sie mit dem Kunden, aber es scheint mir seltsam, sich mehr darum zu kümmern, * warum * es einen Fehler gibt, als dass * ein * Fehler vorliegt.
@DavidRice definitiv war ich ein bisschen hyperbolisch, es gibt sehr wichtige Fehler.Wir haben diese Trennung zwischen Entwickler und Qualitätssicherung nicht, wir arbeiten Hand in Hand und im Allgemeinen ist die Qualitätssicherung mehr für Erkundungs- / Regressionstests als für die Überprüfung von Merkmalen vorgesehen.Kleinere Fehler verschwinden nie, aber sie zeigen normalerweise in die Richtung von z.Mangel an Domänenmodellierung, Komplexität der Architektur usw. Der aktuelle Status Quo besteht darin, dass Fehler in neuen Funktionen im Allgemeinen unerwartete Interaktionen sind. Sobald die Entwicklung abgeschlossen ist, gibt es "keine Fehler" in dem relativ kleinen Bereich, der die Bemühungen unterstützt.Dev macht QA.
@DavidRice Das Verständnis * warum * ein Fehler aufgetreten ist, ist entscheidend, um die Gesamtrate der von einer Organisation generierten Fehler zu verringern.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 umgestaltet werden muss.Vielleicht gibt es einen Entwickler im Team, der inkompetent ist.Sobald die Hauptursachen bekannt sind, können Maßnahmen ergriffen werden, um die Fehlerraten zu senken, die Codequalität zu verbessern und die Markteinführungszeit für neue Funktionen zu verkürzen.
#2
+32
Philip Kendall
2019-05-07 18:56:57 UTC
view on stackexchange narkive permalink

Im Stand-up sollten Sie nur die Fakten angeben:

  • Gestern habe ich an Fehler Nr. 532 gearbeitet, bei dem die Widgets die falsche Farbe haben . Das ist abgeschlossen und es ist bereit für die nächste Bereitstellung.
  • Heute werde ich an Fehler Nr. 536 über den Absturz arbeiten, wenn ich versuche, mehr Widgets zu bestellen.
  • Möglicherweise blockiert, weil ich Ich verstehe die Wechselwirkungen mit dem Back-End-Bestellservice nicht. Mit wem kann ich darüber sprechen?
/ blockquote>

Alles andere ist für das Aufstehen nicht möglich. Darüber hinaus hat Sie jemand (Ihr Teamleiter, Ihr Manager, wer auch immer Ihnen die Arbeit zuweist) gebeten, an diesen Problemen zu arbeiten, damit er bereits weiß, woher sie kommen und warum Sie keine neuen Funktionen zum Sprint beitragen. Lassen Sie sie sich darüber Sorgen machen.

Das ist ausgezeichnet, lassen Sie das Team / den Manager ihre eigenen Schlussfolgerungen ziehen.Es reflektiert dich nicht, weil du darauf gekommen bist, nachdem es bereits "codiert" wurde, und hochfahren musst.
#3
+18
Sourav Ghosh
2019-05-07 18:58:43 UTC
view on stackexchange narkive permalink
    • 1) Lassen Sie es nicht so klingen, als würde ich schlecht über den Code oder den ehemaligen Mitarbeiter sprechen, der gegangen ist und dessen Arbeit ich repariere.

      Nun, Sie sprechen über die Probleme im Code, ohne zu erwähnen, warum (oder wen), Fehler vorhanden sind und behoben werden müssen - 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 vorantreiben Es wurde festgestellt, dass beim Testen Probleme auftreten), zumindest für einen einzelnen Sprint, bei dem ich möglicherweise nicht so viel zu der neuen Arbeit beitrage, die wir eingebracht haben.

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

    • 2.5) Klingt nicht so wie ich ' Ich versuche, die Verantwortung für die Behebung abzulenken, aber ich möchte sicher nicht mit der Ursache dieser Probleme verwechselt werden.

      Warum denken Sie so? Der Code wurde von jemand anderem geschrieben. Die Qualitätssicherung wurde von einem anderen durchgeführt. Sie sind derjenige, der ihn repariert. Niemand wird Sie hier als Problemquelle betrachten.

    Um schließlich zu antworten:

    was ist das? Am besten sollte ich im täglichen Stand-up darüber sprechen?

    Genauso, wenn die Fehler aus dem Code eines anderen gefunden worden wären, der noch im Team arbeitet. Es wurde ein Fehler gefunden. Sie müssen ihn beheben, den Fortschritt angeben, den Sie gestern erzielt haben, und den Plan für heute angeben. Erwähnen Sie auch, ob Sie Hilfe vom Team benötigen, um Hindernisse zu überwinden. Du bist fertig.

Ich mag dieses, rede einfach über den Code und die Fehler, beschuldige den Code "Ich habe festgestellt, dass es das nicht getan hat" "Ich verbessere das ..."
"Warum denkst du so? Code wurde von jemand anderem geschrieben, die Qualitätssicherung wurde von einem anderen durchgeführt, du bist derjenige, der das Problem behebt. Niemand wird dich hier als Problemquelle betrachten."Wenn sie jetzt für Feature X verantwortlich sind und es Probleme mit Feature X gibt, können die Leute leicht annehmen, dass sie der Grund sind, warum es Probleme mit Feature X gibt. Sie wissen möglicherweise nicht oder erinnern sich nicht daran, dass es zuvor jemand anderes warSie sind für Feature X verantwortlich und wissen möglicherweise nicht, wann die Probleme in den Code eingeführt wurden.
@AnthonyGrist Dann brauchen Sie einen besseren Manager.Ich möchte sicher nicht, dass mein Manager es "vergisst".Beachten Sie auch, dass dies im Zusammenhang mit einem Stand-up-Meeting geschieht, sodass das Team (agil) klein (idealerweise 2 bis 7) und kohärent ist.
#4
+4
Daniel
2019-05-08 21:36:28 UTC
view on stackexchange narkive permalink

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

1) Das gesamte Team soll den Abschluss der Arbeit besitzen . Eine bestimmte Funktion wird erst ausgeführt, wenn sie implementiert, getestet und möglicherweise gemäß dem Standard der Definition von erledigt freigegeben wurde. Sie erwähnen alte Arbeit gegenüber neu engagierter Arbeit, aber dies ist engagierte Arbeit, die das Team noch nicht beendet hat. Sie helfen dem Team, diese Arbeit abzuschließen. Dies sollte sich definitiv nicht schlecht auf Sie auswirken und auch nicht als alte Arbeit angesehen werden.

2) Die Entwicklung in Scrum ist anpassungsfähig. Oft müssen wir Dinge umgestalten oder "reparieren", nicht weil wir es vorher vermasselt haben, sondern weil sich die Dinge seitdem geändert haben. Dies ist normal.

3) Wir sind Menschen und eine perfekte Beherrschung jeder Fähigkeit ist unmöglich. Scrum verlangt von uns, dass wir uns bemühen, ein Team zu sein, das Fehler erkennen und unsere Arbeitsweise verbessern kann, ohne dass es sich um einen persönlichen Angriff handelt, und kein Team, das diese Gespräche vermeidet. Wenn Sie sagen möchten, dass Sie einen Fehler beheben, den jemand gemacht hat, wird dies als schlecht angesehen. Dies ist wirklich eine tiefe psychologische Sicherheitsherausforderung im Team, die dringend angegangen werden muss.

Ich sehe keine Erwähnung von Scrum speziell in der Frage.Die Punkte, die Sie ansprechen, sollten jedoch auf jeden agilen Prozess anwendbar sein.Und # 3 (nicht auf den Messenger schießen) ist besonders wichtig für jede Organisation / jedes Team / was auch immer, das etwas mehr als dysfunktional sein möchte.
Es war nicht.Es wurde nur aus den Tags abgeleitet.
#5
+3
Bebs
2019-05-07 18:59:32 UTC
view on stackexchange narkive permalink

Melden Sie dem Bug-Tracker des Unternehmens und Ihrem Vorgesetzten einfach den aktuellen Status des Codes, indem Sie die einfache Wahrheit sagen und nichts verbergen.

Vermeiden Sie beim Befüllen des Bug-Trackers, den ersteren zu erwähnen Entwickle so viel wie möglich und vermeide auch Adjektive (schlecht, arm, beschissen ...). Konzentrieren Sie sich nur auf Fakten.

Treffen Sie sich mit Ihrem Vorgesetzten und / oder dem Team, um die Situation und die erforderlichen Ressourcen zu erläutern, um die gesamte Korrektur durchzuführen: Vielleicht brauchen Sie noch ein paar Wochen, vielleicht wird ein anderer Entwickler benötigt. Vielleicht ein Training für Sie usw. Ihr Vorgesetzter kennt Sie und Ihre Stärken. Wenn ein Fehler also Wissen benötigt, das Sie nicht haben, sollte er Ihnen keine Vorwürfe machen.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...