Mit welchen Methoden evaluieren Entwickler Aufgaben?

Hallo an alle! Die für den Beginn der Entwicklung erforderliche Theorie ist sehr umfangreich. Einige Spezialisten (Backend-Entwickler in Java und anderen Sprachen) haben mehr davon, während andere (zum Beispiel Frontend-Entwickler in JavaScript – React Native) etwas weniger haben. Allerdings müssen beide über einen großen Vorrat an nicht nur technischem, sondern auch „organisatorischem“ Wissen verfügen. Dieses „organisatorische“ Wissen ist einer der Schnittpunkte für Frontend- und Backend-Entwickler. Heute möchte ich über einen Aspekt dieses nichttechnischen, organisatorischen Wissens sprechen – über die Aufgabenbewertung (Schätzung). Und da ich nur mit der Agile- Methodik gearbeitet habe (die tatsächlich als die beliebteste gilt), werde ich in ihrem Unterabschnitt Scrum die Aufgabenbewertung im Kontext von Scrum betrachten . Ich muss gleich sagen, dass die Beurteilung, auch Schätzung genannt, schwierig ist. Für mich persönlich als Entwickler ist dies einer der schwierigsten/unerwünschtesten Aspekte des Jobs. Es sind viele verschiedene Faktoren zu berücksichtigen, die die Bewertung einer Aufgabe beeinflussen können. Gleichzeitig basieren die Planungen zur Weiterentwicklung auf Ihren Prognosen.

Was passiert, wenn die Bewertung nicht richtig ist?

Wenn ein Entwickler viel mehr Stunden für eine Aufgabe aufwendet, als am Ende aufgewendet wird, kann es den Anschein haben, dass er nicht der beste Spezialist ist, da die Schätzung sehr ungenau war. Sozusagen ein Finger am Himmel. Wenn der Entwickler gleichzeitig nicht in der prognostizierten Zeit investiert, gefährdet er gleichzeitig die Pläne des Kunden, das Produkt/die neue Funktion zu veröffentlichen. Dies ist ein Geschäft, und Geschäft bedeutet Geld, und nur wenige Kunden werden eine solche Reifenpanne mögen. Das ist eigentlich der Grund, warum ich Schätzungen nicht mag, weil es manchmal so schwierig ist, den genauen Zeitpunkt für die Erledigung einer Aufgabe zu bestimmen.

Wie wird die Zeit bewertet?

Die Schätzung erfolgt in der Regel in Stunden oder Story Points. Persönlich bin ich dem Bewertungsprozess in Story Points viel näher . Wenn eine Uhr etwas Physisches ist, dann etwas, das verwechselt werden kann, geht es bei den Story Points ein wenig um etwas anderes, Abstrakteres. Typischerweise geben Softwareentwicklungsteams Schätzungen im Zeitformat ab: Stunden, Tage, Wochen, Monate. Solche Zeitschätzungen basieren in erster Linie auf persönlicher Erfahrung, Vermutungen oder Intuition. In diesem Fall schauen sich die Entwickler einfach die Aufgabe an und äußern eine Schätzung, wie lange sie dafür brauchen würden. Daher sind sie nur sehr selten genau, da es zu viele Faktoren gibt, die die Frist für die Fertigstellung der Arbeiten beeinflussen können. Daher verwenden viele Teams, die nach der agilen Methodik arbeiten, Story Points. Lass es uns herausfinden.

Was sind Story Points?

Ein Story Point ist eine Maßeinheit, die eine Einschätzung des Gesamtaufwands ausdrückt, der notwendig ist, um einen bestimmten Arbeitsbereich (Funktionalität) vollständig umzusetzen. Das heißt, dies ist eine solche relative Komplexität . Teams weisen Story Points basierend auf der Komplexität der Arbeit, dem Umfang der Arbeit und dem Risiko oder der Unsicherheit zu. In der Regel werden diese Werte zugewiesen, um die Arbeit effizienter in kleinere Teile aufzuteilen und so Unsicherheiten zu beseitigen. Dies hilft den Teams im Laufe der Zeit zu verstehen, was sie in einem bestimmten Zeitraum erreichen können, und hilft ihnen, die nächsten Arbeitsbereiche genauer zu planen. Das mag für Sie völlig kontraintuitiv erscheinen, aber diese Abstraktion ist tatsächlich sehr nützlich: Sie drängt das Team dazu, schwierigere Entscheidungen über die Komplexität der Arbeit zu treffen. Schauen wir uns einige Gründe an, Story Points bei der Planung zu verwenden:

• Schätzungenauigkeiten in Zeitintervallen können vermieden werden;
• Im Gegensatz zur Schätzung über einen längeren Zeitraum können Gemeinkosten besser berücksichtigt werden: Kommunikation zwischen Teammitgliedern und dem Kunden, verschiedene Teambesprechungen und -planungen sowie unvorhergesehene Situationen;
• Jedes Team bewertet die Arbeit auf einer anderen Skala, was bedeutet, dass ihre Geschwindigkeit (gemessen in Punkten) unterschiedlich ist.
• Indem Sie eine Skala für die Zuweisung jedes Story Points definieren, können Sie Punkte schnell und ohne große Kontroversen verteilen.

Wie man Story Points NICHT verwendet

Leider werden Story Points oft für andere Zwecke verwendet. Story Points können fehlerhaft sein, wenn sie zur Bewertung von Personen, zur Definition detaillierter Fristen und Ressourcen verwendet werden und wenn sie fälschlicherweise als Maß für die Leistung angesehen werden. Stattdessen müssen Teams sie nutzen, um den Umfang/die Komplexität der Arbeit in jeder Aufgabe zu verstehen und Prioritäten zu setzen. Es ist möglich, dass die als schwieriger eingestuften Teile zuerst erledigt werden sollten, damit sie vor dem Ende des Sprints abgeschlossen werden können , die einfacheren Teile jedoch auf einen späteren Zeitpunkt verschoben werden können. Ich möchte Sie daran erinnern, was ein Sprint im Kontext der Scrum -Methodik ist: Wie lange dieser Zeitraum beträgt, wird zu Beginn der Entwicklung durch Vereinbarung zwischen Team und Kunde festgelegt. Dies kann ein Zeitraum von zwei Wochen oder einem Monat oder jeder andere Zeitraum sein. In der Regel wird zu Beginn des Sprints eine Aufgabenschätzung durchgeführt, um den möglichen Arbeitsumfang bis zum Ende des Sprints zu planen, wenn die fertigen Arbeiten an den Kunden geliefert werden. Es hilft Ihnen, Ihre Fortschritte in der Produktentwicklung zu sehen, Feedback vom Kunden zu erhalten und die Entwicklung des Projekts entsprechend der Vision des Kunden anzupassen. Dennoch schweifen wir ein wenig ab: Kommen wir zurück zur Schätzung. Die Bewertung von Aufgaben nur eines Entwicklers wäre zu subjektiv. Daher handelt es sich in der Regel um Teamarbeit. Es gibt eine ganze Reihe von Techniken zur Teambewertung. Heute werden wir uns die am häufigsten verwendeten davon ansehen – Scrum Poker . Diese Technik erfordert einen Manager, der jemand wie der Anführer dieses Scrum-Pokers sein wird . Dies könnte eine Person sein, die sich auf Scrum Master oder PM spezialisiert hat .

Was ist Scrum Poker?

Scrum Poker – oder Planungspoker – ist eine Bewertungstechnik, die auf dem Erreichen einer Einigung basiert. Wird hauptsächlich verwendet, um die Komplexität der bevorstehenden Arbeit oder den relativen Umfang der zu lösenden Aufgaben während der Softwareentwicklung einzuschätzen. Ich stelle sofort fest, dass Scrum-Poker eine gängige Praxis in der Entwicklung ist und man unbedingt wissen muss, um was für ein Biest es sich handelt. Für diesen Prozess verwenden wir normalerweise eine Anwendung oder Website, die es uns ermöglicht, eine Teambewertung einer bestimmten Aufgabe zu organisieren. Wie kommt es dazu? Das Team nimmt einen Backlog-Eintrag (neue Aufgabe, Funktionalität) und bespricht kurz mögliche Fallstricke und andere damit verbundene Nuancen. Anschließend wählt jeder Teilnehmer eine Karte mit einer Zahl aus, die seinen Schwierigkeitsgrad darstellt. Ach ja, und beim Schätzen werden nicht die üblichen Reihen verwendet, sondern Fibonacci-Zahlen . Fibonacci-Zahlen sind beim Scrum-Poker so beliebt , weil der Abstand zwischen ihnen mit der Zeit größer wird (erinnert an Pyramidenebenen). Es gibt Aufgaben, die eine enorme Komplexität haben und eine kleine Anzahl von Story Points nicht erreichen können. Erklärung für ungewöhnliche Karten:

unbekannte Anzahl von Endpunkten

eine unendlich lange Aufgabe

brauche eine Pause

Seltenere Schätzmethoden:

• in den T-Shirt-Größen S, M, L, XL
• oder bei Hunden - Chihuahua, Mops, Dackel, Bulldogge usw. (meiner Meinung nach ist dies die seltsamste Einheit zur Bewertung von Aufgaben =D)

Das Team vergleicht dann die Schätzungen, die verschiedene Entwickler für dasselbe Problem abgegeben haben, und wenn sie übereinstimmen, ist das großartig! Falls nicht, müssen die Gründe für die unterschiedlichen Beurteilungen (Argumente) erörtert werden. Danach können wir gemeinsam zu einem einheitlichen Kostenvoranschlag kommen, mit dem alle, ob Plus oder Minus, einverstanden sind. Warum wird Poker überhaupt zur Planung eines ernsthaften Softwareprojekts eingesetzt? Immerhin ist das irgendwie seltsam. Tatsächlich regt eine solche Gamifizierung die Teammitglieder zum unabhängigen Denken an und fordert sie auf, ihre Ergebnisse gleichzeitig mit ihren Teamkollegen zu präsentieren. Dies wiederum vermeidet die Abhängigkeit von den Ansichten anderer Teammitglieder. Andernfalls werden weniger erfahrene Entwickler auf die Einschätzungen erfahrenerer Teammitglieder vertrauen und sich auf diese verlassen, was den Nutzen ihrer eigenen Einschätzung zunichte macht. Bei gleichzeitiger Öffnung der Ergebnisse ist dies jedoch grundsätzlich unmöglich. Ein Beispiel für eine Scrum Poker-Planungs-App stammt von Atlassian .

Beispiel einer Aufgabenbewertung

Stellen wir uns vor, Ihr Team hat eine bestimmte Skala zur Bewertung in Story Points identifiziert: Scrum Poker beginnt mit einer Aufgabe, die Sie wie folgt bewerten:

• Sie haben noch nie zuvor mit der Implementierung einer ähnlichen Funktionalität gearbeitet - +3
• Funktionalität einer mittelgroßen Aufgabe - +2
• Die Umsetzung der Aufgabe hat eine hohe Komplexität - +3
• hohe Komplexität beim Schreiben von Tests für diese Funktionalität - +3

Als Ergebnis erhalten Sie 11 Story-Punkte, aber da es keine solche Karte gibt, bieten Sie 13 an. Ein anderer Kollege von Ihnen bewertet die Aufgabe:

• habe schon einmal mit einem ähnlichen Problem gearbeitet - +1
• Funktionalität einer mittelgroßen Aufgabe - +2
• Die Umsetzung der Aufgabe hat eine durchschnittliche Komplexität von +2
• durchschnittliche Komplexität beim Schreiben von Tests für diese Funktionalität - +2

Als Ergebnis erhält er 7 Story-Punkte, aber in den Fibonacci-Zahlen gibt es so etwas nicht, und er legt eine Karte mit der nächstmöglichen Zahl – 8. Andere Teammitglieder geben dementsprechend Schätzungen auf der Grundlage ihrer subjektiven Ansichten ab. Als nächstes zeigen Sie Ihre Ergebnisse und stellen fest, dass fast alle Ihrer Kollegen die Schätzung mit 13 bewertet haben, mit Ausnahme eines Entwicklers, der sie mit 8 bewertet hat. In diesem Fall erhält er das Wort und gibt Gründe an. Und sie sind zum Beispiel so: Er hat zuvor mit demselben Problem gearbeitet, und es ist nicht so schwierig, wie es scheinen mag, und am Ende überzeugt er die übrigen Teammitglieder, ihre Lösung von 13 auf 8 Stockwerke zu ändern Punkte und sagt, dass er jedem helfen wird, der diese Aufgabe übernimmt, er wird es herausfinden. Oder am Ende wird er es selbst tun. Und im Allgemeinen spielt es keine Rolle, ob andere auf seine Argumente hören oder nicht, denn auf die eine oder andere Weise wird dieser Aufgabe eine Bewertung zugewiesen und das Team macht sich mit der nächsten vertraut. Beim ersten Mal werden die Schätzungen ungenau sein, ebenso wie die Schätzungen des Arbeitsumfangs, den Sie im nächsten Zeitraum (Sprint) planen. Schließlich basieren diese Schätzungen präzise auf Schätzungen. Nach einiger Zeit, etwa drei Monaten, wird das Team beginnen, die Aufgaben genauer abzuschätzen, und es wird sichtbar, wie viel Arbeit das Team durchschnittlich pro Sprint erledigen kann. Dabei handelt es sich jedoch um eine allgemeine Planung des Arbeitsumfangs, es geht vielmehr um die Zeit, und in diesem Fall können viele verschiedene Faktoren einen Einfluss haben. Einer der Entwickler ging beispielsweise für zwei Wochen in den Urlaub. Das heißt, Sie müssen einen bestimmten Umfang der geplanten Arbeit (geplante Funktionalität) streichen. Oder es ist ein neuer Entwickler zum Team gekommen, aber Sie müssen sich nicht vollständig auf ihn verlassen, weil... Sie müssen die Zeit berücksichtigen, die zur Anpassung an das Projekt erforderlich ist und als Onboarding bezeichnet wird . Dies kann je nach Komplexität des Projekts zwei Wochen plus oder minus eine Woche dauern. Das ist alles für heute. Ich hoffe, ich habe Ihr Wissen in einem so nichttechnischen Teil des Wissens wie der Problemschätzung leicht verbessert. Wenn Sie tiefer in dieses Thema sowie in die Details von Scrum einsteigen möchten, empfehle ich Ihnen dringend, das Buch „SCRUM“ von Jeff Sutherland zu lesen. Für die Konsequenzen kann ich nicht bürgen, denn vielleicht verspüren Sie danach den lästigen Wunsch, Scrum Master zu werden =D