Halten Sie Ihre Fristen ein: Methoden, mit denen Entwickler den Aufwand abschätzen

Hallo an alle! Es gibt eine Menge Theorie, die Sie kennen müssen, um mit der Softwareentwicklung beginnen zu können. Einige Spezialisten (z. B. Backend-Entwickler, die Java und andere Sprachen verwenden) wissen mehr darüber, während andere (z. B. Frontend-Entwickler, die JavaScript und React Native verwenden) möglicherweise etwas weniger wissen. Allerdings müssen beide Gruppen nicht nur über umfangreiches technisches, sondern auch „organisatorisches“ Wissen verfügen. Dieses „organisatorische“ Wissen ist ein Bereich, in dem sich Frontend- und Backend-Entwickler überschneiden. Heute möchte ich über einen Aspekt dieses nichttechnischen, organisatorischen Wissens sprechen. Heute werden wir über Aufwandsschätzung sprechen . Weil ich nur Erfahrung mit der agilen Methodik habe(das als das beliebteste gilt), genauer gesagt das Scrum-Framework, werde ich die Aufwandsschätzung im Kontext von Scrum betrachten . Gleich zu Beginn muss ich sagen, dass die Aufwandsschätzung schwierig ist. Für mich ist es einer der herausforderndsten/unangenehmsten Aspekte meines Jobs als Entwickler. Es sind viele verschiedene Faktoren zu berücksichtigen, die Ihre Einschätzung des für eine Aufgabe erforderlichen Aufwands beeinflussen können. Darüber hinaus basieren zukünftige Entwicklungspläne auf Ihren Schätzungen.

Was passiert, wenn Sie einen schlechten Kostenvoranschlag abgeben?

Wenn ein Entwickler weitaus mehr Stunden für eine Aufgabe veranschlagt, als letztendlich für die Aufgabe aufgewendet werden, kann sein Fachwissen in Frage gestellt werden, da die Schätzung so ungenau war. Mit anderen Worten, es war eine wilde Vermutung. Wenn ein Entwickler seine Arbeit nicht in der vorgesehenen Zeit erledigt, gefährdet er gleichzeitig die Pläne des Kunden, das Produkt oder die neue Funktion zu veröffentlichen. Das ist Geschäft, und Geschäft ist Geld. Nur wenige Kunden werden mit einem solchen Slip zufrieden sein. Genau aus diesem Grund mag ich Schätzungen nicht – weil es manchmal sehr schwierig ist, die für die Erledigung einer Aufgabe erforderliche Zeit genau zu bestimmen.

So erstellen Sie eine Zeitschätzung

Schätzungen erfolgen in der Regel in Stunden oder Story Points. Meine persönliche Präferenz ist es, den Schätzprozess mithilfe von Story Points durchzuführen . Es ist schwer, sich bei konkreten physischen Objekten zu irren, aber die Handlungspunkte sind etwas abstrakter. Softwareentwicklungsteams geben in der Regel Schätzungen in Form von Zeitangaben ab: Stunden, Tage, Wochen, Monate. Diese Zeitschätzungen basieren in erster Linie auf persönlicher Erfahrung, Vermutungen und/oder Intuition. In diesem Fall schauen sich die Entwickler einfach die Aufgabe an und äußern ihre Vermutung darüber, wie viel Zeit sie dafür benötigen werden. Daher sind diese Schätzungen nur sehr selten genau, da es zu viele Faktoren gibt, die die Dauer der Arbeiten beeinflussen können. Aus diesem Grund verwenden viele Teams, die die agile Methodik anwenden, auch Story Points. Lass uns eintauchen!

Was sind Story Points?

Ein Story Point ist eine Maßeinheit, die eine Schätzung des Gesamtaufwands ausdrückt, der erforderlich ist, um eine bestimmte Funktionalität vollständig zu implementieren. Das heißt, wir sprechen von relativKomplexität. Die Teams legen eine Schätzung in Form von Story Points fest, die auf der Komplexität der Arbeit, dem Arbeitsvolumen und dem Risiko bzw. der Unsicherheit basiert. Diese Werte werden normalerweise zugewiesen, um die Arbeit effizienter in kleinere Teile zu unterteilen und so Mehrdeutigkeiten zu vermeiden. Dies hilft den Teams im Laufe der Zeit zu verstehen, was sie in einem bestimmten Zeitraum erreichen können, und hilft ihnen, nachfolgende Arbeitsschritte genauer zu planen. Für Sie mag das völlig kontraintuitiv klingen, aber diese Abstraktion ist in der Tat praktisch: Sie drängt das Team dazu, schwierige Entscheidungen über die Komplexität der Arbeit zu treffen. Werfen wir einen Blick auf einige Gründe für die Verwendung von Story Points bei der Planung:

• Sie können ungenaue Zeitschätzungen vermeiden.
• Im Gegensatz zu Schätzungen, die in Zeiteinheiten vorgenommen werden, können Sie mit Story Points Gemeinkosten berücksichtigen: Kommunikation zwischen Teammitgliedern und dem Kunden, verschiedene Teamdiskussionen und Planungsaktivitäten sowie unvorhergesehene Situationen.
• Jedes Team wird seine Arbeit anhand unterschiedlicher Skalen bewerten, was bedeutet, dass seine Kapazität (gemessen in Punkten) unterschiedlich sein wird.
• Indem Sie eine Skala für die Zuweisung jedes Story Points definieren, können Sie Punkte schnell und ohne große Kontroversen zuweisen.

Wie man Story Points NICHT verwendet

Leider werden Story Points oft missbraucht. Story Points können irreführend sein, wenn sie zur Beurteilung von Personen, zur Definition detaillierter Fristen und Ressourcen verwendet werden und wenn sie mit einer Leistungsmessung verwechselt werden. Stattdessen sollten Teams sie nutzen, um den Umfang/die Komplexität jeder Aufgabe zu verstehen und Prioritäten zu setzen. Vielleicht sollten die Teile, die als schwieriger gelten, zuerst in Angriff genommen werden, damit sie vor dem Ende des Sprints erledigt werden können , und einfachere Aufgaben möglicherweise auf später verschoben werden. Ich möchte Sie daran erinnern, was ein Sprint im Kontext der Scrum -Methodik ist: Die Länge dieses Zeitraums wird zu Beginn der Entwicklung festgelegt und zwischen dem Team und dem Kunden vereinbart. Dies kann ein Zeitraum von zwei Wochen oder einem Monat oder jeder andere Zeitraum sein. In der Regel werden die Aufwandsschätzungen zu Beginn jedes Sprints erstellt, um zu planen, welche Arbeiten bis zum Ende des Sprints erledigt werden können, wenn die fertigen Arbeiten an den Kunden geliefert werden. Die Demo hilft Ihnen, Ihren Fortschritt bei der Produktentwicklung zu sehen, Feedback vom Kunden zu erhalten und den Projektverlauf entsprechend der Vision des Kunden anzupassen. Aber wir schweifen ein wenig ab. Kommen wir zurück zu den Schätzungen. Es wäre zu subjektiv, wenn nur ein Entwickler Schätzungen für alle Aufgaben abgeben würde. Daher ist dieser Prozess normalerweise eine Teamleistung. Es gibt eine ganze Reihe von Techniken, mit denen Teams Schätzungen erstellen können. Heute werfen wir einen Blick auf die beliebteste Technik: Scrum Poker . Diese Technik erfordert einen Manager, der als Moderator für das Scrum-Poker fungiert . Dies kann jemand sein, der ein Scrum Master oder möglicherweise ein PM ist .

Was ist Scrum-Poker?

Scrum Poker oder Planungspoker ist eine Schätztechnik, die auf dem Erreichen einer Einigung basiert. Es wird hauptsächlich verwendet, um die Komplexität der bevorstehenden Arbeit oder den relativen Umfang von Softwareentwicklungsaufgaben abzuschätzen. Ich sage gleich: Scrum Pokerist eine gängige Softwareentwicklungspraxis, und Sie müssen wissen, worum es geht. Dabei handelt es sich in der Regel um eine App oder Website, die einem Team die gemeinsame Erstellung eines Kostenvoranschlags für eine bestimmte Aufgabe erleichtert. Wie kommt es dazu? Das Team nimmt etwas aus dem Backlog (eine neue Aufgabe, einige Funktionen) und bespricht kurz mögliche Fallstricke und andere damit verbundene Nuancen. Dann wählt jeder Teilnehmer eine Karte mit einer Zahl, die seine Komplexitätseinschätzung widerspiegelt. Oh, noch etwas: Bei diesen Schätzungen verwenden wir Zahlen in der Fibonacci-Folge und nicht gewöhnliche Zahlen. Fibonacci-Zahlen sind beim Scrum-Poker beliebt, weil zwischen ihnen ein immer größerer Abstand besteht (ähnlich den Ebenen einer Pyramide). Einige Aufgaben werden sehr komplex sein und wir werden mit einer geringen Anzahl an Story Points nicht durchkommen. Es gibt einige ungewöhnliche Karten, die folgende Bedeutung haben:

Unbekannte Anzahl von Endpunkten

Unendlich lange Aufgabe

Brauche eine Pause

Weniger verbreitete Schätzmethoden verwenden:

• T-Shirt-Größen: S, M, L, XL
• Hunderassen – Chihuahua, Mops, Dackel, Bulldogge und so weiter (ich persönlich finde, dass dies die seltsamste Maßeinheit für die Aufwandsschätzung ist =D)

Anschließend vergleicht das Team die Schätzungen verschiedener Entwickler für dieselbe Aufgabe. Wenn sie einverstanden sind, dann großartig! Wenn nicht, müssen die Gründe (Argumente) für die unterschiedlichen Schätzungen diskutiert werden. Danach arbeitet das Team zusammen, um einen einzigen Kostenvoranschlag zu erstellen, den alle mehr oder weniger akzeptieren. Warum wird Poker überhaupt zur Planung ernsthafter Softwareprojekte eingesetzt? Sie müssen zugeben, dass das seltsam ist. Tatsache ist, dass diese Art der Gamifizierung die Teammitglieder zum eigenständigen Denken anregt und sie dazu einlädt, ihre Einschätzungen gleichzeitig mit ihren Teamkollegen preiszugeben. Dadurch wird wiederum vermieden, dass einige Teammitglieder von der Meinung anderer abhängig sind. Wenn dies nicht auf diese Weise geschehen würde, würden weniger erfahrene Entwickler die Schätzungen erfahrenerer Teammitglieder prüfen und sich darauf konzentrieren. und das würde ihre eigenen Schätzungen weniger nützlich machen. Aber die gleichzeitige Darstellung der Schätzungen macht dies praktisch unmöglich. Atlassian-Angeboteeine Scrum-Poker-App zur Verwendung im Planungsprozess.

Beispiel einer Aufwandsschätzung

Angenommen, Ihr Team hat die folgende Skala für die Zuweisung von Story Points zu Schätzungen erstellt: Für jede Aufgabe wird Scrum-Poker gespielt und Sie geben wie folgt eine Schätzung ab:

• Sie haben noch nie zuvor eine ähnliche Funktionalität implementiert: +3
• Die Funktionalität ist durchschnittlich groß: +2
• Die Umsetzung wird sehr komplex sein: +3
• Das Schreiben von Tests für die Funktionalität wird sehr komplex sein: +3

Wenn man jede Komponente addiert, erhält man insgesamt 11 Story Points, aber es gibt keine solche Karte, also schlagen Sie 13 vor. Ein Kollege schlägt für die Aufgabe die folgende Schätzung vor:

• Er hat schon einmal mit einer ähnlichen Aufgabe gearbeitet: +1
• Die Funktionalität ist durchschnittlich groß: +2
• Die Implementierung wird von durchschnittlicher Komplexität sein: +2
• Das Schreiben von Tests für die Funktionalität wird von durchschnittlicher Komplexität sein: +2

Sein Zwischenergebnis sind 7 Story Points, aber diese Zahl gibt es in der Fibonacci-Reihe nicht, also reicht er die Karte mit der ungefähresten Zahl ein – 8. Auch andere Teammitglieder treffen ihre Schätzungen auf der Grundlage ihrer subjektiven Ansichten. Dann zeigen alle ihre Karten und Sie stellen fest, dass fast alle Ihrer Kollegen eine Schätzung von 13 abgegeben haben, bis auf den einen Entwickler, der eine 8 vorgeschlagen hat. In diesem Fall darf er zu Wort kommen und Gründe für seine niedrigere Schätzung nennen. Nehmen wir an, er bietet diese Begründung an: Er habe zuvor an derselben Aufgabe gearbeitet, und es sei nicht so schwierig, wie es scheinen mag. Letztendlich überzeugt er den Rest des Teams, seine Meinung von 13 auf 8 Story Points zu ändern, und sagt, dass er jedem helfen wird, der diese Aufgabe letztendlich übernimmt. Oder vielleicht macht er es selbst. Auf jeden Fall ist das nicht der Fall. Es spielt keine Rolle, ob die anderen seine Argumente akzeptieren oder nicht, denn auf die eine oder andere Weise wird der Aufgabe ein Kostenvoranschlag zugewiesen, und das Team wird mit der Prüfung der nächsten fortfahren. Anfänglich sind die Schätzungen ungenau, ebenso wie die Schätzungen des Arbeitsumfangs, den Sie im nächsten Zeitraum (Sprint) erledigen möchten. Schließlich handelt es sich bei diesen Schätzungen um Schätzungen. Nach einiger Zeit, vielleicht drei Monate später, wird das Team beginnen, den Zeitbedarf für Aufgaben genauer einzuschätzen, und es wird ersichtlich, wie viel Arbeit das Team durchschnittlich in einem Sprint leisten kann. Dies ist jedoch ein Prozess zur Erstellung eines allgemeinen Plans für den Arbeitsumfang. Es konzentriert sich hauptsächlich auf die Zeit, aber in diesem Fall können viele verschiedene relevante Faktoren eine Rolle spielen. Angenommen, ein Entwickler ist zwei Wochen lang im Urlaub. Sie müssen einen bestimmten Umfang der geplanten Arbeit (geplante Funktionalität) einsparen. Oder nehmen wir an, eine neue Entwicklerin ist dem Team beigetreten, aber noch nicht ganz auf dem neuesten Stand. Sie müssen ihr also Zeit geben, sich durch ein Projekt mit dem Projekt vertraut zu machenOnboarding- Prozess. Dies kann je nach Komplexität des Projekts zwei Wochen dauern, mehr oder weniger eine Woche. Das ist alles für heute! Ich hoffe, dass ich Ihr Wissen über Aufwandsschätzung, einen notwendigen nichttechnischen Aspekt der Softwareentwicklung, etwas verbessert habe. Wenn Sie tiefer in dieses Thema und in die Details von Scrum einsteigen möchten, empfehle ich Ihnen dringend, das Buch „SCRUM“ von Jeff Sutherland zu lesen. Zu den Konsequenzen kann ich keine Versprechungen machen, da man nach der Lektüre den nervigen Wunsch verspürt, Scrum Master zu werden =D