Kann Fristen nicht einhalten, weil das Entwicklerteam mich durch den Spießrutenlauf führt, bevor meine Arbeit angenommen werden kann

Ich habe vor etwa 2 Monaten einen neuen Job angefangen. Ich habe viel Arbeit und wenig bis gar keine Anleitung zur inneren Funktionsweise einer sehr komplexen Webanwendung erhalten, die auch an mehrere IoT-Geräte gebunden ist, die über mehrere Hardware- und Softwareschichten verfügen, mit denen ich nicht vertraut bin. Abgesehen von den üblichen Problemen, dass das Unternehmen den Umfang nicht gut verwaltet und ich zurückdrängen muss, werde ich einer Code-Überprüfung meiner Arbeit unterzogen, bevor sie als erledigt akzeptiert wird.

Nun, ich habe viele Jahre Erfahrung damit, Feedback von Code-Reviews zu nehmen, aber diese Leute sind unerbittlich. Sie nennen meinungsbasierte Dinge wie Variablennamen, fügen etwas in ein vorhandenes Modul ein oder erstellen ein neues oder zwingen mich, zusätzlichen Funktionsumfang hinzuzufügen, der nicht in den ursprünglichen Akzeptanzkriterien enthalten ist, bevor sie die Zusammenführung "unterzeichnen".

Anstatt kleine iterative Änderungen zu sein, ziehen sich Pull-Requests wochenlang hin, während Scope Creeps einsetzen und mobbende Entwickler immer wieder neue und pikantere Probleme mit dem Code in ihrem Echoraum finden. Dies führt dazu, dass ich wenig oder gar keine Fortschritte bei Tickets mache und in den Augen meines Teams und meines Managers schlecht dastehen.

Ich habe mit meiner Managerin darüber gesprochen und sie war sehr defensiv gegenüber ihrem bestehenden Prozess und sagte, dass ich die Zustimmung der anderen Entwickler brauche, bevor ich etwas einbinden könnte.

Mache ich etwas falsch oder ist das nur ein beschissenes Team mit schlechtem Management?

Ich sage, stehen Sie für sich selbst ein und schlagen Sie zurück, wenn sie versuchen, etwas für etwas wie einen Variablennamen zurückzuschlagen. Wenn es sich um ein Feature-Creep handelt, schieben Sie es zurück und fragen Sie nach einem neuen Problem, in das der neue Bereich eingearbeitet werden kann.
Also, was denkst du, würde dein Team auf Workplace über dich posten? Ich bin nicht abfällig – ich schlage nur ernsthaft vor, dass Sie darüber nachdenken, wie sie Sie wahrnehmen. Würde ihr Beitrag so lauten wie „Wie bringen wir den Neuen dazu, nicht mehr zu denken, dass wir ihn ärgern, wenn wir nur versuchen, ihn dazu zu bringen, unserem Prozess zu folgen, der für uns seit Jahren funktioniert …“? Du machst vielleicht nichts falsch, aber es ist immer hilfreich, darüber nachzudenken, wie das, was du tust, zu einer Situation beitragen kann.
Variablennamen basieren nicht immer auf Meinungen und sind ein gültiges Thema, das während einer Codeüberprüfung diskutiert werden kann. Klingt für mich so, als sollten Sie sich mehr über die Anleitung beschweren, die Sie für das Projekt benötigen, als dass die Code-Reviews zu hart sind.
"Mache ich irgendetwas falsch oder ist das nur ein beschissenes Team mit schlechtem Management?" Toxisches Team. Entscheiden Sie, ob Sie glauben, dass dies ein Übergangsritus ist und verschwinden wird, oder ob diese Art von Mobbing bestehen bleibt; wenn letzteres, gehen.
Das ist ohne weitere Details wirklich schwer zu beantworten. Wählen sie beispielsweise Variablennamen aus, die auf ihren Codierungsrichtlinien / -konventionen basieren, oder solche, die dies nicht tun? Wenn Sie der Konvention folgen, ist es Spitzfindigkeit und "ihre" Schuld. Wenn Sie dies nicht tun, sind Sie nicht dem Prozess gefolgt und „Ihr“ Fehler.
@ColleenV: Die Sache ist, es scheint nicht zu funktionieren. Das Unternehmen hatte eine Menge Probleme und war bisher erfolglos, selbst eine tatsächliche Produktionssoftware auf den Markt zu bringen. Ich hingegen habe in den letzten 3 Jahren 2 verschiedene einjährige Projekte auf den Markt gebracht.
@Robert Glaubst du nicht, dass es ein Problem ist, wenn du nach nur zwei Monaten reinkommst und dem gesamten Team erzählst, dass du weißt, wie man seine Arbeit besser macht als sie? Ich weiß, das klingt hart, aber wahrscheinlich kommt es ihnen so vor. Sie haben ganze zwei Projekte auf den Markt gebracht? Ich hatte das Zehnfache und würde niemals in ein Team gehen und versuchen, Dinge nach nur zwei Monaten zu ändern. Selbst wenn Sie wissen, wie Sie es besser machen können, ist die Art und Weise, wie Sie es angehen, kontraproduktiv.
@ColleenV: Das sind nur 2 Projekte in den letzten 3 Jahren . Wie auch immer, ich habe einen Artikel gelesen, in dem es heißt, wenn Menschen gemobbt werden, ist der effektivste Weg, mit ihnen umzugehen, es gleich zurückzugeben. Was sie tun, ist gut etabliert antipatterns. Der Handschuh: daedtech.com/manual-code-review-anti-patterns
@Robert Es liegt an dir, damit umzugehen, aber du denkst, dass es dazu führen wird, dass du am glücklichsten bist, also mache ich einen weiteren Versuch und dann werde ich die Klappe halten. Was ist, wenn sie es dir „zurückwerfen“, weil sie denken , dass du der hartnäckige Tyrann bist, der nicht einmal einen Variablennamen ändert, um mit dem Team zurechtzukommen? Ich habe viel Erfahrung mit Konfrontationen wie dieser (hauptsächlich, weil ich IMMER Recht habe, lol) und so gut zu geben, wie Sie (scheinbar) bekommen, ist nicht der beste Ansatz, es sei denn, Sie möchten Ihre Zeit bei der Arbeit gestresst verbringen raus und genervt/wütend.

Antworten (4)

Sie müssen das System zuerst eingeben, um es zu ändern. Wenn dein Weg nicht akzeptiert oder gar fair bewertet wird, dann wird es so sein. Mit der Zeit werden Sie Ihre Autorität etablieren, aufhören, der Neue zu sein, und Ihrer Meinung mehr Gehör verschaffen.

Ihr Manager sagte, Sie brauchen das Buy-In anderer Entwickler, was bedeutet, dass Sie vom Pack akzeptiert werden müssen. Es ist, was es ist.

Nun zu einigen praktischen Ratschlägen: Mögen sie Ihre Variablennamen nicht? Große Sache, ändern Sie sie. Ja, es ist kleinlich, aber es hält sie vom Rücken, und Sie haben im Moment nicht viel politisches Kapital. Oder wenn Sie sich mit ihnen anlegen wollen, setzen Sie eine Ente ein .

Was mir Sorgen machen würde, ist der Scope Creep. Haben die anderen Entwickler die Befugnis, den Umfang zu erweitern? In jedem Fall informieren Sie Ihren Vorgesetzten jedes Mal, wenn dies geschieht, per E-Mail (stellen Sie sicher, dass Sie Links oder IDs oder was auch immer Ihr CR-System verwendet, angeben). Der Punkt hier ist, eine Papierspur zu erhalten, die Ihre Verzögerungen erklärt.

+1 für die Papierspur. Es ist wirklich wichtig zu zeigen, dass die Verzögerung nicht (ausschließlich) Ihre Schuld ist.
@rath: Etwas könnte als "Scope Creep" missverstanden werden, wenn es sich um Dinge handelt, von denen bekannt sein sollte, dass sie erforderlich sind. Wenn Sie beispielsweise aufgefordert werden, ein Kreditkarten-Eingabeformular zu erstellen, sollte nicht angegeben werden müssen, dass der CVV-Code erforderlich ist oder dass die Kartennummer, Datumsfelder, Name auf der Karte usw. vor der Übermittlung validiert werden sollten zum eigentlichen Kartenprozessor. Es ist unmöglich zu sagen, ob die anderen Entwickler sich wirklich mit Scope Creep beschäftigt haben oder ob sie nur auf all die anderen Dinge hinweisen, die dieser Entwickler in seinem Code berücksichtigen sollte, bevor er es erledigt nennt.

Haftungsausschluss: Ich bin Software-Ingenieur, mache Code-Reviews und bin so pingelig. Deshalb.

Ohne genau zu wissen, welche Probleme Sie haben, sind viele dieser Kommentare für mich aus Sicht der Codeüberprüfung sinnvoll. Gute, aussagekräftige Variablennamen sind wichtig für die Lesbarkeit des Codes. Wenn ich eine Variable namens x habe, haben Sie keine Ahnung, was sie tut. Wenn ich eine Variable namens myApiResponse habe, sagt Ihnen das:

1) Es ist ein Objekt.
2) Es ist eine Antwort von einer API
3) Die API heißt (wahrscheinlich) MyApi

Dies sind gute Dinge, die Sie beim Lesen und Befolgen des Codeflusses wissen sollten, und sind wichtig für die Codewartung. Wenn Ihre Variablennamen aufgerufen werden, liegt das wahrscheinlich daran, dass sie nicht zur Lesbarkeit des Codes beitragen und in Zukunft Probleme bei der Wartung verursachen werden. Diese Dinge sind wichtig.

Ebenso ist es wichtig, die Dinge dorthin zu bringen, wo sie hingehören. Angenommen, Sie haben eine große Anwendung, von der ein Teil Bestellungen Ihrer Kunden verarbeitet. Sie haben also einen CustomerService, der Kundendaten verarbeitet, und einen OrderService, der Bestellungen verarbeitet. Angenommen, Sie benötigen die Kreditkarteninformationen eines Kunden (aus welchen Gründen auch immer Sie diese in Ihrem Datensatz speichern). Aber Sie legen Ihre Methode, um auf diese Informationen zuzugreifen, in Ihrem Bestellservice ab, weil der Bestellservice sie "schließlich" benötigt. Aber dann haben Sie einen anderen Service, sagen wir Ihr Kundenservice-Dashboard, das ebenfalls Kreditkarteninformationen von Kunden benötigt. Aber die Person, die das Kundenservice-Dashboard erstellt, weiß nicht, dass der Bestellservice diese Funktion bereits implementiert hat, Also überprüfen sie den Kundenservice (wo es erwartet werden sollte) und sehen es nicht und sie machen weiter und implementieren es. Jetzt haben Sie 2 Implementierungen desselben Codes, die gewartet werden müssen. Plötzlich haben Sie die Code-Wartungslast Ihrer Funktion verdoppelt, um Kunden-Kreditkarteninformationen zu erhalten, was Sie hätten vermeiden können, wenn Sie die Funktionalität einfach an der richtigen Stelle platziert hätten, wo sie hingehört.

Dies sind wichtige Dinge, die bei der Codeüberprüfung genannt werden müssen, damit sie behoben werden können, bevor der Code zusammengeführt wird, denn wenn sie dies nicht tun, werden Sie später viele Probleme haben.

Denken Sie daran: Der Code-Review-Prozess ist Ihr Freund. Es gibt einen Grund, warum Code-Reviews durchgeführt werden, und es gibt einen Grund, warum Code-Reviews Torwächter sind, um Ihren Code zusammenzuführen, weil niemand sich mit schlechtem Code befassen möchte. Tun Sie also, was die Kritiker Ihnen sagen, und beschweren Sie sich nicht.

Eine Anmerkung zum Scope Creep: Drücken Sie hart zurück. Wenn das Gefragte nicht im Ticket enthalten ist, sollte Ihre Antwort lauten, dass die Arbeit für das Ticket abgegrenzt und verwiesen wurde (vorausgesetzt, Sie verwenden Agile/Scrum) und nicht geändert werden sollte. Wenn sie darauf bestehen, es zu ändern, sagen Sie, dass das Ticket neu geschätzt werden muss und es die Scrum-Pläne für das Team durcheinander bringen könnte, und erwähnen Sie dies Ihrem Scrum-Leader und Ihrem Manager. Das Hinzufügen von Dingen zu Tickets, die ursprünglich nicht geschätzt wurden, ist sehr schlecht und sollte überhaupt nicht gemacht werden.

Ich habe gerade eine sehr ähnliche Antwort geschrieben, aber deine gefällt mir besser, +1. Ich stimme zu, dass dies besonders bei neu hinzukommenden Entwicklern wichtig ist, um die Qualität einer Codebasis aufrechtzuerhalten. Ich würde mit dem Scope Creep etwas anders umgehen: Ich würde argumentieren, dass diese Anfragen neue Tickets sein sollten, die der Manager dann schließen oder genehmigen kann. Dies wird besser zeigen, wohin die Arbeit geht – und es einfacher machen, zumindest einige Fortschritte zu erzielen.
@bytepusher Zusätzlicher Umfang sollte natürlich ein neues Ticket sein. Das OP sagt, dass der Umfang für jedes Ticket zunimmt, und dazu sage ich, dass das nicht passieren sollte und er hart zurückdrängen sollte. Natürlich ist Scope Creep im Allgemeinen eine Frage des Managements.
ah fair genug. Naja, ich habe trotzdem hochgestimmt :)
In der Tat können diese Dinge von Bedeutung sein – und das nicht nur in der Sache. Was einzelne Entwickler oft übersehen, ist, dass Unterschiede in der Codebasis ihren Preis haben, und dass es eine wertvolle Fähigkeit ist, Ergänzungen oder Verbesserungen vorzunehmen, die sich nahtlos einfügen. Scope Creep kann eine schlechte Angewohnheit sein – oder es kann eine geschäftliche Notwendigkeit sein, aber wo es so ist, ist ein festes Sprint-Intervall nicht angemessen, da es nicht ausreichend agil ist, um einem Bewusstsein für sich täglich oder stündlich entwickelnde Bedürfnisse gerecht zu werden.
Ich stimme hier allem zu, außer zu sagen, dass ich denke, dass das OP sehr klar darüber sein sollte, was Scope Creep ist und was im richtigen Code erwartet wird. Zum Beispiel würde ich erwarten, dass jemand, der den OrderService codiert, Code einfügt, der die Bestellung validiert, bevor sie gespeichert wird, ohne ausdrücklich angeben zu müssen, dass dies geschehen muss. Grundsätzlich erwarte ich von den Entwicklern, die für mich arbeiten, dass sie ihr Gehirn für Aufgaben einsetzen. Vielleicht bedeutet dies, dass der Entwickler weitere Details über die Aufgabe einholen muss, wenn ja, dann stellen Sie diese Fragen.

Was auch immer die Gründe hinter diesem Prozess sind (und es könnten viele und gültige sein), es gibt eine unvermeidliche Verzögerung zwischen dem Schreiben des Codes und seiner Annahme. Daran können Sie kurz- und mittelfristig nicht viel ändern.

Wenn Sie etwas Einfluss auf Ihre Fristen haben, passen Sie Ihre Schätzungen entsprechend an. Wenn jemand dies in Frage stellt, weisen Sie einfach darauf hin, dass es länger dauert, bis Ihre Änderungen abgezeichnet werden, da Sie noch den Programmierstil des Teams lernen.

Wenn Sie keinen Einfluss auf die Fristen haben, sprechen Sie mit der Person, die Ihre Arbeit oder Fristen festlegt, und erklären Sie ihnen das oben Gesagte. Sie sollten den Verstand haben, ein wenig Spielraum einzuplanen, um Verzögerungen bei der Abmeldung zu mildern.

Sie haben noch nicht lange im Unternehmen gearbeitet und lernen immer noch die Prozesse und Standards eines neuen Teams kennen (und wie sie Anforderungen und Umfang verwalten). Einige Verzögerungen bei der Freigabe des Codes sind zunächst normal. Sie sollten feststellen, dass dies nachlässt, wenn Sie etwas Erfahrung mit dem Team sammeln und sie etwas Erfahrung mit Ihnen und Ihrem Programmierstil sammeln.

Code-Review-Kriterien und Entwicklungsstandards sollten dokumentiert und somit von jedem mit dem gleichen Ergebnis wiederholbar sein. Fordern Sie die dokumentierten Entwicklungsstandards an und halten Sie diese während der Entwicklung ein.

Wenn sie etwas mitbringen, das kein dokumentierter Standard für das Unternehmen ist, empfehlen Sie ihnen, es dem dokumentierten Standard hinzuzufügen.

In Bezug auf den Scope Creep sollte die Zeit, die zur Einhaltung von Standards erforderlich ist, in Ihre Schätzungen einbezogen werden – wenn dies nicht der Fall ist, ist dies ein Problem mit Ihrem Schätzungsprozess. Dokumentieren Sie immer alles, was den Entwicklungsumfang erhöht, nachdem Ihre Schätzungen in den Zeitplan aufgenommen wurden.

Kann Fristen nicht einhalten, weil das Entwicklerteam mich durch den Spießrutenlauf führt, bevor meine Arbeit angenommen werden kann
AntwortenHierDatenschutz-Bestimmungen1y, 0v