Wie soll ich meine Arbeit präsentieren, wenn ich immer wieder auf unerwartete Hindernisse stoße?

Ich denke, das Hauptproblem besteht oft darin, dieselbe Verlobung mehrmals hintereinander zu brechen. Fast jeder weiß, dass fast alle Entwickler ihr Bestes geben, daher ist es Teil der Entwicklung, blockiert zu werden, aber täglich jemanden zu hören, der sagt, dass eine bestimmte Aufgabe morgen erledigt wird, und dann zu hören, wie dieselbe Person am nächsten Tag dasselbe wiederholt Eine bestimmte Aufgabe wird morgen erledigt, und das Nichterfüllen dieser Aufgabe ruiniert die Glaubwürdigkeit dieser Person und unterstreicht das Scheitern.

Wenn Menschen in unseren Teams mit Hindernissen konfrontiert sind, ermutigen wir sie normalerweise, kleine Siege oder das, was sie am Vortag gelernt haben, zu teilen und einen Fortschritt zu spüren, und betonen den Erwerb neuen Wissens.

Beispiel:

Gestern stand ich vor diesem Hindernis im Zusammenhang mit diesem technischen Thema.

Ich lerne das, das und das.

Heute werde ich diese Funktion weiter implementieren.

Wir versuchen, uns nicht rechtzeitig festzulegen, indem wir einfach sagen: „Ich arbeite an diesem Feature“ statt „Diese Aufgabe wird morgen erledigt“.

Dies macht Sie auch zum Referenten dieses technischen Themas. Sobald eine andere Person auf dasselbe Hindernis trifft, besteht eine hohe Wahrscheinlichkeit, dass sie zu Ihnen kommt.

Darüber hinaus warnt derjenige, der die führende Rolle hat, den Product Owner, dass möglicherweise nicht alle Aufgaben während des aktuellen Sprints abgeschlossen werden, sodass sie möglicherweise erneut priorisiert werden müssen.

Der Zweck von Standup-Meetings (aus einem Lehrbuch der agilen SW-Entwicklung) besteht darin, dem Team zu helfen, besser zu kommunizieren. Manager im Raum können eine offene Kommunikation behindern, nur weil jemand Angst hat, Probleme und vielleicht seine eigenen Mängel offen zu diskutieren.

Eine Lösung hierfür ist die getrennte Berichterstattung an Management- und Teambesprechungen. Angenommen, Sie verwenden Sprints, beziehen Sie Manager in die Sprint-Planung und die Überprüfung der Sprint-Ergebnisse ein. Was innerhalb des Sprints passiert, bleibt beim Team.

So bekommt man etwas Puffer für Aufgaben, die länger dauern als gedacht und man muss sich nicht jeden Tag erklären. Wenn eine Aufgabe nicht in einen Sprint passt, sollte sie vielleicht aufgeschlüsselt werden. Wenn die Hindernisse von oben kommen, ist die Sprint-Überprüfung ein guter Moment, um das Problem zu eskalieren.

Wenn Sie einen Ruf als „unzuverlässig“ entwickeln, liegt dies wahrscheinlich nicht daran, dass immer wieder Hindernisse auftauchen (wie alle Entwickler wissen, dass dies geschieht), sondern daran, dass Sie sie wirklich schlecht berücksichtigen Ihre Einschätzung der Schwierigkeit oder Vollständigkeit, insbesondere bei dieser speziellen Aufgabe, die sich als schwer einzuschätzen erwiesen hat.

Sie erwähnen nicht, wie erfahren Sie sind, aber ein Teil des Reifeprozesses eines Entwicklers besteht darin, ein Gespür dafür zu entwickeln, welche Projekte oder Aufgaben viele bekannte und unbekannte Risiken bergen, und Strategien zu entwickeln, um diese zu mindern. Natürlich können Sie sich irren, aber wenn Sie dies wiederholt tun, könnte Ihr Team sehr wohl anfangen zu denken, dass Sie in Ihrer Fähigkeit, die Schwierigkeit eines Projekts einzuschätzen, „unzuverlässig“ sind.

Dieses Projekt hat bereits gezeigt, dass Ihr schwieriger Schätzer verstimmt ist; Wenn Sie das nächste Mal um eine solche Schätzung gebeten werden, nehmen Sie sich ein wenig Zeit, um wirklich darüber nachzudenken, wo die „Fallstricke“ liegen könnten, und versuchen Sie, einige Strategien zu entwickeln, um die bevorstehende Arbeit besser einzuschätzen.

Erwähnen Sie einige Details darüber, worüber Sie stolpern.

Diese Treffen sollen sagen, was Sie gestern getan haben und was Sie heute versuchen werden. Also mach es - auch wenn das Nettoergebnis nichts war. Sprechen Sie so detailliert wie möglich, ohne die Besprechungsfristen zu beeinträchtigen, z. B.:

Ich konnte die Daten nicht richtig laden, ich habe die Threadpool-Bibliothek auseinandergerissen, einen Fehler darin gefunden - leider hat das nicht geholfen. Hat auch mit Sam zusammengearbeitet, seit er diesen Code vor ein paar Wochen berührt hat. Nirgendwo angekommen. Es wurde auch versucht, die Socket-Lesefunktion neu zu schreiben, die Beschädigung wurde immer noch nicht behoben.

Heute denke ich, dass meine nächste beste Vermutung darin besteht, stärkere Debugging-Prüfungen für die Serialisierungsbibliothek hinzuzufügen und zu sehen, ob das hilft.

Wenn Sie nichts versprechen, beginnen Ihre Kollegen und Ihr Vorgesetzter zu verstehen, dass Sie tatsächlich viel tun, und sie bekommen ein Gefühl für die Schwierigkeit, und ich finde, dass dieses kleine Detail bei Ihren Kollegen etwas auslösen kann.

Außerdem habe ich genau diesen Punkt in meinen Leistungsbeurteilungen angesprochen: "Ich fühle mich schlecht, wenn ich innerhalb eines Werktages nach meinem letzten Standup nichts zu zeigen habe." Einige von uns argumentierten, dass dies ein Hindernis für Forschung und Entwicklung sei, dass wir zu viel Angst hätten, ein paar Tage damit zu verbringen, sofort einsatzbereite Lösungen für ein Problem zu recherchieren, das Management hörte zu und Stand-up-Meetings wurden auf zweimal wöchentlich verschoben .

Zunächst einmal sind die Schätzungen, wie viel Arbeit es erfordern wird, um eine Geschichte fertigzustellen, genau das: Schätzungen . Es besteht immer ein gewisses Risiko, dass die Schätzung falsch war und mehr Arbeit erfordert.

Die Schätzungen basieren sowohl auf dem aktuellen Stand des Codes (soweit Ihr Team ihn am besten kennt) als auch auf dem Wissen des Teams darüber, wie die Story zu implementieren ist. (Aus diesem Grund kann dieselbe Geschichte von Iteration zu Iteration unterschiedliche Schätzungen haben: In einer späteren Iteration haben Sie möglicherweise neuen Code in der Codebasis oder kennen eine neue Technik oder Bibliothek, die verwendet werden könnte, um die Implementierungsarbeit zu reduzieren.)

In diesem speziellen Fall scheint es dem Team an Wissen über die Geschichte, an der Sie arbeiten, zu mangeln, und da es einige Probleme, die auftreten könnten, nicht kannte, hat es die Geschichte (im Nachhinein) falsch eingeschätzt.

Um den Anschein zu vermeiden, schwammig zu wirken, möchten Sie bei der Angabe des Status einer Geschichte, an der Sie arbeiten, nicht nur erklären, dass die Schätzung falsch war , sondern auch zeigen, dass Sie jetzt und für zukünftige Arbeiten Risikomanagement betreiben. Wenn Sie also auf ein Problem stoßen, das Ihren Arbeitsaufwand erhöht, führen Sie eine kleine Analyse durch, um herauszufinden, warum die Schätzung falsch war, welche Auswirkungen dieses neue Wissen auf Ihre aktuelle Schätzung für diese und andere Geschichten haben sollte, und welche Techniken verwendet werden sollten, um dieses Risiko zu mindern.

Wenn Sie beispielsweise auf Probleme stoßen, weil eine von Ihnen verwendete Bibliothek fehlerhaft ist, könnten Sie sagen:

Diese Geschichte hat ihre Schätzung nun mehrfach überschritten, aufgrund von Fehlern in Bibliothek X, die ich erst spät im Implementierungsprozess entdeckt habe. Es scheint klar, dass Bibliothek X nicht sehr vertrauenswürdig ist, und angesichts dessen sollten wir alle Schätzungen von Dingen, die sich darauf verlassen, revidieren. Außerdem spreche ich dies jetzt an, indem ich ein paar grundlegende Einheitentests schreibe, um das tatsächliche Verhalten der APIs zu zeigen, die ich in X verwende. Es wäre wahrscheinlich eine gute Idee, dasselbe für andere Geschichten zu tun, die sich auf X stützen, und wir sollten es wahrscheinlich in Betracht ziehen Schätzungen für Geschichten, die sich auf X stützen, sind ziemlich ungenau, bis die Tests geschrieben sind, die das erforderliche Verhalten von X bestätigen.

Dies zeigt, dass Sie trotz unvorhergesehener Probleme Maßnahmen ergreifen, um diese nicht nur jetzt zu lösen, sondern auch sicherzustellen, dass die neu entdeckten Risiken, die Sie gefunden haben, in Zukunft besser gehandhabt werden.

Noch etwas zu Stand-up-Meetings: Sie dienen nicht nur dazu, Status zu geben, sondern auch Informationen auszutauschen (wie die Probleme mit Bibliothek X oben) und Hilfe zu erbitten und anzubieten. Es lohnt sich zu sagen, wenn Sie auf Probleme stoßen: "Wenn jemand hier eine Idee hat, wie man besser damit umgehen kann, kontaktieren Sie mich bitte nach dem Treffen, damit wir die Details besprechen können." (Dies gilt insbesondere, wenn Sie mit Ihren Minderungstechniken nicht zufrieden sind; es kann schwierig sein, an gute zu denken, und andere in der Gruppe haben möglicherweise gute Ratschläge dazu oder sind sogar bereit, daran zu arbeiten.)

Ich bin nervös, wie das aussieht, wenn ich meine Updates während Standups gebe.

Sei nicht. Standup-Meetings sind keine Leistungsbeurteilungen. Sie sollen Status vermitteln.

Wie kommuniziere ich am besten meinen Fortschritt in solchen Situationen, in denen eine Aufgabe aus nicht vorhersehbaren Gründen immer wieder länger dauert als erwartet? Mein Ziel ist es, ehrlich zu den Projektmanagern zu sein, ihnen aber auch nützliche Informationen zu geben, anstatt ihre Zeit mit allzu technischen Details zu verschwenden, und mich nicht abgehackt zu präsentieren.

Sie übermitteln den Status nur kurz und für jeden verständlich.

Wenn jemand fragt oder weitere Details wünscht, laden Sie ihn zu einem Folgetreffen ein, bei dem Sie bei Bedarf auf die Gründe eingehen können. Auf diese Weise verschwenden Sie nicht die Zeit aller.