Umgang mit Schätzungen als Junior-Programmierer

Ich arbeite jetzt seit ein paar Monaten in einem Unternehmen, das Aufgaben schätzt (für die allgemeine Bevölkerung, nicht speziell für Junioren), und dann bekommen wir die Aufgabe, lösen sie, durchlaufen zwei Tests und am Ende sollte die Schätzung sein etwas erfüllt.

Ich bin nicht gestresst, weil einige der Schätzungen für mich einfach unmöglich sind. Ich kenne immer noch nicht das gesamte System (weil es ziemlich umfangreich ist), so dass manchmal die Hälfte der Zeit damit verbracht wird, herauszufinden, was ich tun muss und wo und bis ich fertig bin, ist die Schätzung manchmal vorbei und es gibt immer noch Tests getan (und etwaige Fehler korrigiert).

Das zweite Mal, wenn ich mich mit einer ähnlichen Funktionalität befasse, funktioniert alles viel schneller, aber bisher habe ich das Gefühl, dass ich nur schlecht programmieren kann.

Gibt es irgendetwas, das Sie getan haben, als Sie gerade angefangen haben, das Ihnen geholfen hat, diese Etappe zu überwinden? Ich werde so gestresst, wenn ich sehe, wie wenig Zeit für das Codieren bleibt, dass ich mich manchmal nicht einmal richtig auf das konzentrieren kann, was es noch schlimmer macht.

• Viele Entwickler mit wenig Managementerfahrung schätzen Aufgaben anhand ihrer eigenen Geschwindigkeit oder der Geschwindigkeit eines "besten" Entwicklers in einem Team.

• Die Geschwindigkeit variiert mit der Erfahrung. Es kann 3 Stunden dauern, bis ein Senior-Entwickler das Problem gelöst hat. In 2 Arbeitstagen können Sie das gleiche Problem lösen.

• Stress kann selten vermieden werden, wenn Sie eine neue Arbeit aufnehmen. Nach ein paar Monaten wird es normalerweise besser, vorausgesetzt, Sie geben genug Arbeit und stellen viele relevante Fragen.

• Ihre Senioren wissen möglicherweise nicht, wie Sie sich zu Schätzungen fühlen. Deshalb ist es wichtig, dass Sie sie fragen, was sie von Ihnen erwarten.

Meiner Erfahrung nach:

• Ich denke, dass ein leitender Entwickler oder Manager in der Lage sein sollte, eine User Story (Geschäftsanforderung) in Bezug auf T-Shirt-Größen (XL, L, M, S, XS) einzuschätzen.

• Es ist Aufgabe der Entwickler, die User Story in kleinere Aufgaben zu unterteilen und diese einzuschätzen. Die Lösung einer großen Aufgabe kann einen Tag in Anspruch nehmen, während Sie eine ganze Woche benötigen.

• Es ist sehr wichtig zu notieren, wie lange Sie tatsächlich gebraucht haben, um die Aufgabe abzuschließen.

• Ein guter Projektmanager oder leitender Entwickler würde diese Statistiken ständig sammeln. Wenn sich Ihre Produktivität verbessert, werden sie es bemerken und mehr Arbeit auf Ihre Weise schicken.

Dies wird nicht nur Ihr Leben weniger stressig machen, sondern es wird auch die Abteilung in die Lage versetzen, ihre Ressourcen effektiv zu verwalten.

Wenden Sie sich hierzu an Ihren Teamleiter, Projektmanager und / oder denjenigen, der Ihre Einschätzung vornimmt. nicht wir. Die Leute verstehen, dass die Dinge nicht für alle gleich viel Aufwand bedeuten, und sie können entweder die Schätzungen anpassen, wenn die Aufgabe zugewiesen wird, oder zumindest Ihre Befürchtungen hinsichtlich des Überprüfungszeitraums zerstreuen.

Dies ist meiner Meinung nach der Grund, warum Schätzungen von den Personen vorgenommen werden sollten, denen die Aufgabe zugewiesen wurde (mit Input / Mitwirkung der Lead / Peers). Sie erhalten genauere Schätzungen, wie lange die Arbeit tatsächlich dauern wird.

Ich kann mir keine schlechtere Position für einen Junior-Entwickler vorstellen, als eine Erwartung, die er nicht einhalten kann, es sei denn, er tut dies, um Sie herauszufordern. Hatten Sie echte Auswirkungen darauf, dass Sie die Schätzungen nicht eingehalten haben?

Ich würde zuerst sagen, es ist wichtig, dass Sie gelernt haben, selbst zu schätzen. Wenn Sie eine Aufgabe erhalten haben, schätzen Sie sie sofort nach Ihren Vorstellungen ein und beginnen Sie dann, das Delta zwischen den beiden zu finden. Ich kann fast wetten, dass die Qualität in der ersten kurzen Schätzung geopfert wird. Wenn sie einfach erwarten, dass Sie Elemente schneller als möglich entwerfen und entwickeln, müssen Sie möglicherweise mit jemandem chatten, um das Problem zu beheben.

Zweitens sollten Sie verstehen, dass Qualität ein Merkmal ist, für das sich die Stakeholder, Ihr Chef, entscheiden müssen. Es kann etwas sein, das Sie entweder opfern müssen, um die Anforderungen in der Zeit zu erfüllen, die Sie haben.

So oder so, beseitigen Sie den Stress, es macht keinen Spaß, sich weiterhin so zu fühlen, als ob Sie immer hinter dem Schreiben von schlechtem Code stecken. Hoffe das hilft.

Das ist üblich.

Im Allgemeinen ist es besser, größere Schätzungen als kleinere anzugeben (die meiste Zeit werden Sie die Schätzung sowieso übergehen). Ich würde Ihnen raten, die Aufgabe in kleinstmögliche Unteraufgaben zu unterteilen und diese mit jeder Aufgabe nicht länger als 4 Stunden abzuschätzen.

Wenn eine Aufgabe länger als 4 Stunden dauert, unterteilen Sie sie in eine andere Gruppe von Unteraufgaben. Fügen Sie außerdem einen prozentualen Puffer für Aufgaben hinzu, die Sie derzeit nicht vorhersehen können (meine persönliche Präferenz ist 1 unerwartete Aufgabe für 2 geschätzte Aufgaben, wobei jede unerwartete Aufgabe 2 bis 4 Stunden in Anspruch nimmt, je nachdem, mit welchem ​​System Sie arbeiten).

Fügen Sie danach die Zeit hinzu, die Sie für Tests, Kommunikation, Analyse usw. benötigen.

Erstens: Wenn Sie bei jedem Versuch, ein Problem zu lösen, schneller werden, sind Sie wahrscheinlich kein schlechter Programmierer. Also lasst uns diesen Gedanken aus dem Weg räumen.

Ich würde vorschlagen, dass dies das Versagen Ihrer Manager ist, aber es ist und bleibt Ihre Aufgabe, die Erwartungen zu managen.

Anstatt sich zu verprügeln, weil Sie unrealistische Fristen nicht einhalten können, messen Sie, wie viele Arbeitstage Sie tatsächlich in einer Woche leisten können. Erklären Sie dann Ihrem Teamleiter, dass Sie neu in der Geschäfts- und Softwareentwicklung sind und dass Sie in einer Standardwoche nur n Tage für Senior-Entwickler arbeiten dürfen. Sie sollten das zumindest verstehen, auch wenn sie es nicht mögen.

Sagen Sie ihnen, dass Sie eine weitere Verbesserung erwarten, und zeigen Sie ihnen, wie Sie diese Verbesserung messen können. Und stimmen Sie ihnen zu, dass Sie erst dann mit einem Seniorenlohn rechnen, wenn Sie in einer Woche 5 Tage Senior-Entwickler-Arbeit leisten können. Aber Sie erwarten auch nicht die gleichen Aufgaben wie ein Senior, wenn Sie nicht annähernd so viel verdienen.

Deshalb bin ich ein starker Befürworter der Verwendung von Story Points anstelle von Stunden zur Schätzung. dh Jeder Auftrag erhält eine Anzahl von Punkten, und das Team schätzt, wie viele Punkte es in einem bestimmten Zeitraum erzielen kann. In der folgenden Periode entspricht die Schätzung der tatsächlichen Schätzung aus der vorherigen Periode, bereinigt um bekannte Faktoren wie einen schweren Urlaubsmonat oder einen Entwicklerausstieg.

Wenn als Manager ein neuer Entwickler hinzukommt (Junior oder Senior), mache ich dem Unternehmen klar, dass wir die Schätzung zunächst nicht erhöhen werden. Es wird erwartet, dass dieser Entwickler von anderen Entwicklern so viel Zeit in Anspruch nimmt, wie sie sparen. Der neue Entwickler wird wahrscheinlich besser abschneiden, aber unterversprechend und übertrieben ist das Mantra.

Der Entwickler wird sich mit der Zeit verbessern, ein Senior schneller als ein Junior, und die "Geschwindigkeit" des Teams - die Schätzung von Monat zu Monat - wird sich zusammen mit dieser verbessern.

Bleib ruhig und mach weiter. Wenn das Problem, dass Sie die Schätzungen nicht einhalten, jemals auftaucht, teilen Sie ihnen einfach die gleichen Dinge mit, die Sie in Ihrem Post geschrieben haben, oder wenn Sie sich unsicher fühlen, sprechen Sie selbst mit Ihrem Mentor / Teamleiter darüber.

Schätzungen sind genau das, Schätzungen. Sie können und werden ausgeschaltet sein, umso mehr, wenn Sie die Seile lernen. Und als Junior lernst du wahrscheinlich als Teammitglied in diesem speziellen Projekt, als Programmierer mit der von dir verwendeten Technologie und als Angestellter in deinem Unternehmen die Seile. Und wenn Sie mit vernünftigen Leuten arbeiten, erwarten sie, dass Sie mit den Schätzungen nicht mithalten können.

Sie schauen sich wahrscheinlich die Aufgaben an, die Sie "von unten nach oben" bekommen. Ihre Aufgaben sind Ihnen wichtiger als das Gesamtbild des Projekts, an dem Sie arbeiten - das ist verständlich. Sie sehen die Schätzungen als Ihnen auferlegte Einschränkungen und sind offensichtlich besorgt, wenn Sie diese nicht einhalten.

Wenn Sie sich jedoch das Gesamtbild anschauen, werden Sie feststellen, dass Schätzungen, die für Entwickler noch mehr als "Ziele" sind, "Signale" für Leads / Projektmanager sind. Die Aufteilung der Arbeit in Aufgaben und deren Schätzung ist eine Möglichkeit, die Komplexität der Verwaltung und Schätzung des gesamten Projekts zu verringern. Die Verfolgung der tatsächlich geleisteten Arbeit im Vergleich zu den Schätzungen ist ein Mittel, um zu verfolgen, wie das Projekt abläuft, aber es ist nur eine der Metriken, die angewendet werden können. Wenn Schätzungen nicht regelmäßig eingehalten werden, ist dies ein Signal für den Manager, dass mit dem Projekt etwas nicht stimmt. Aber in jedem vernünftigen Projekt wird es nicht die Tatsache sein, dass ein Junior-Entwickler im Team die Schätzungen nicht erfüllt.

Lassen Sie mich Ihnen meine beiden Freunde WAG und SWAG vorstellen

Dh die 'Wild Assed Guess' und die 'Scientific Wild Assed Guess'

Ob Sie es glauben oder nicht, ich habe diese nicht erfunden. Sie sind eigentlich ziemlich häufig in der Wirtschaft. Schauen Sie sich diesen Artikel an, um zu sehen, was ich meine.

Idealerweise ist es am besten, eine feste Schätzung zu erstellen. Wenn dies nicht möglich ist, ist es besser, anzugeben, dass die Schätzung aufgrund unvollständiger Daten grob ist als zu lügen.

Der Schlüssel ist, Geschäft ist nicht Computerprogrammierung. Das Managen von Erwartungen ist wichtiger als Präzision. Es ist wichtig, die Zeit einzuschätzen, die Ihrer Meinung nach plus 10% benötigt wird, um unvorhersehbare Probleme auszugleichen.

Wenn Sie überschätzen, werden sie glücklich sein, wenn Sie mit der Zeit fertig sind. Wenn Sie unterschätzen, werden sie entweder nicht enttäuscht, wenn Sie die Frist einhalten, oder äußerst enttäuscht, wenn etwas schief geht.

Unternehmen sind eine Grauzone, in der manche Menschen im Laufe der Zeit ein intuitives Gefühl entwickeln. Die Tatsache, dass sie einen Nachwuchsentwickler bitten, diese Art von Entscheidungen unabhängig zu treffen, sagt eine Sache aus. Entweder haben sie niemanden zur Verfügung, der in der Lage ist, solche Entscheidungen zu treffen, oder die Manager möchten keine Verantwortung für Fehler übernehmen.

Ich würde mein Geld in letzteres stecken, wenn Sie für eine große Organisation arbeiten. Wenn ein hierarchisches Geschäftsmodell groß genug wird, ist die Oberseite so weit von der Unterseite entfernt, dass die höheren Ebenen den Fortschritt nur daran messen können, was sie auf dem Papier erhalten. Es ist eine schreckliche Umgebung, weil Promotionen im Allgemeinen dafür gegeben werden, keine Fehler zu machen. Aber die Leute, die die Beförderungen erhalten, vermeiden Misserfolge, indem sie ihre Verantwortung auf andere übertragen (dh blinde Inkompetenz) und die Erfolge von Leuten in der Kette anerkennen.

Leider sind Programmierer leichte Ziele, die man "unter den Bus" werfen kann, denn egal wie groß das Problem ist, wir werden versuchen, eine Lösung zu finden. Der Schlüssel ist, dass Sie nicht mehr Zeit darauf verwenden, das Problem einzuschätzen, als die Lösung zu implementieren.

Das ist ein schwieriger Ort. Klingt so, als ob Sie in der Phase stecken, in der Sie nur noch liefern müssen.

Im Laufe der Jahre ist mir Folgendes zum Thema Schätzung aufgefallen: Die Qualität einer Schätzung kann durch Beantwortung der folgenden drei Fragen (mit einem richtigen Namen) ermittelt werden.

• Wer hat das Design gemacht?
• Wer hat die Schätzung gemacht?
• Wer führt die Implementierung durch?

Die Qualität der Schätzung ist umgekehrt proportional zur Anzahl der genannten Personen. Beispiel: Die beste Schätzung ist, wenn dieselbe Person alle drei der oben genannten Aufgaben erledigt hat, eine schwache Schätzung ist, wenn eine Person die Planung / Schätzung durchgeführt hat und eine andere die Implementierung durchführt, und die schlechteste Schätzung ist eine, bei der alle drei Fragen beantwortet werden ein eindeutiger Name.