Get best of the week

Aufgaben an Story-Punkten bewerten

Fast jeder, der auf Softwareentwicklung gestoßen ist, weiß, was die Bewertung von Story Points (SP) -Aufgaben ist. Ich sage jedoch gelegentlich Kollegen aus anderen Abteilungen oder Neulingen im Team, die noch nie auf einen solchen Ansatz gestoßen sind, warum wir SP verwenden und warum es für das Team bequem und für das Unternehmen effektiv ist.

Der Zweck dieses Textes ist es zu beschreiben, was SP ist, wie man sie verwendet, um Probleme zu bewerten und warum diese Technik so weit verbreitet ist.

Problem


Die Berechnung der für die Ausführung einer Aufgabe erforderlichen Zeit ist sowohl eine sehr einfache als auch eine sehr riskante Aufgabe für Entwicklungsteams.

Eine falsche Bewertung wird zu einem der ersten Gründe für die Aufschlüsselung von Zeitplänen oder sogar für das Scheitern des Projekts.
Das Problem ist, dass das Unternehmen Bewertungen als Verbindlichkeiten betrachtet. Entwickler betrachten Bewertungen als Annahmen.

Zur Veranschaulichung werde ich ein Beispiel eines fiktiven Dialogs aus Robert Martins Buch The Ideal Programmer anführen.

Mike (Manager): Wie hoch ist die Wahrscheinlichkeit, dass Sie in drei Tagen zurechtkommen?

Peter (Entwickler): Ich kann damit umgehen.

Mike: Kannst du eine Nummer nennen?

Peter: Fünfzig oder sechzig Prozent.

Mike: Es besteht also eine ziemlich hohe Wahrscheinlichkeit, dass Sie vier Tage brauchen werden?

Peter: Ja. sogar fünf oder sechs können benötigt werden, obwohl ich es bezweifle.

Mike: Inwieweit bezweifeln Sie das?

Peter: Oh, ich weiß nicht ... Ich bin zu fünfundneunzig Prozent sicher, dass die Arbeit in weniger als sechs Tagen erledigt sein wird.

Mike: Also vielleicht sieben?

Peter:Nun, wenn alles schief geht ... Verdammt, wenn ALLES schief geht, vielleicht zehn oder sogar elf Tage. Aber die Wahrscheinlichkeit eines solchen Zufalls ist sehr gering, oder?
Ich denke, der obige Dialog kommt jedem Entwickler oder Projektmanager ziemlich bekannt vor.

Leider enden die Probleme mit den Noten hier nicht. Andere Fallstricke sollten ebenfalls berücksichtigt werden:

Korrelation von Note und Note


Die angegebene Bewertung ist nur gültig, wenn der Autor der Bewertung die Aufgabe ausführt. Schließlich ist es offensichtlich, dass die Zeit, die der leitende Entwickler und der Praktikant für die Aufgabe aufwenden, unterschiedlich sein wird.

Eine ideale Einschätzung in einer unvollkommenen Welt


Dringende Besprechungen, Arbeitsbriefe, Boten und ein gefallener Task-Manager erschweren den bereits komplexen Entwicklungsprozess weiter. Dies macht die idealen Stunden, die wir uns bei der Bewertung als schlecht nützlich für einen Projektmanager vorstellen, der versucht, ein schnell alterndes Gantt-Diagramm zusammenzustellen.

Als nächstes werden wir den Ansatz zur Bewertung von Aufgaben in SP betrachten und wie er alle oben beschriebenen Schwierigkeiten angeht.

Alternativlösungen


Natürlich ist der Ansatz mit SP nicht der erste Versuch, die angesprochenen Probleme zu lösen, obwohl er wahrscheinlich der beliebteste ist.

In diesem Block werde ich über ein anderes Programm sprechen, das ein Aufgabenbewertungsschema enthält. Das Programm heißt PERT und es ist nicht erforderlich, mit dem Programm vertraut zu sein, um das Ziel der Texte zu erreichen, sodass Sie sicher mit dem nächsten Block fortfahren können.

Programmevaluierungs- und Überprüfungstechnik
PERT Program Evaluation and Review Technique 50- XX .

:

O: . .

N: .

P: , , .

:

μ=O+4N+P6



, :

σ=P−O6



, :

1+12+126±12−16



, . , , .

Story-Punkte


Was sind Story Points und wie helfen sie bei der Bewertung von Aufgaben? Mike Cohn, Agile Evangelist und CEO von Mountain Goat Software, spricht sehr kurz und klar über diese Technik.


Was ist, wenn wir anstelle der Zeit, die zur Erledigung einer Aufgabe benötigt wird, den Aufwand bewerten, der zur Lösung dieses Problems erforderlich ist? Dazu nehmen wir die Bewertungsskala und legen Aufgaben an, die einer Bewertung bedürfen.

Gleichzeitig sollten alle Faktoren, die sich darauf auswirken können, in die Bewertung der Bemühungen einbezogen werden:

  • Der Arbeitsaufwand;
  • Die technische Komplexität der Aufgabe;
  • Mögliche Risiken und Unsicherheiten bei den Anforderungen;

Es klingt nicht einfach, aber denken wir daran, dass wir nicht jeder Aufgabe eine eindeutige Bewertung geben müssen, sondern nur ihren Platz auf der Bewertungsskala zwischen anderen zu bewertenden Aufgaben finden müssen.

Ich möchte zwei wichtige Aspekte der Story Points-Methode hervorheben, mit denen die auf der vorherigen Seite diskutierten Probleme gelöst werden können:

Relative Bewertung


Die Aufgaben werden relativ zueinander bewertet, so dass eine universelle Bewertungsskala entsteht, die nicht von der Erfahrung des Bewerters abhängt. Auch wenn die Aufgabe durch die verantwortliche ersetzt wird - ihre Bewertung bleibt unverändert -, bewerten Sie relativ neue Aufgaben in Bezug auf diese Skala.

Uhren durch abstrakte Punkte ersetzen


Daher entfernen wir aus dem Evaluator die Notwendigkeit, die Aufgabe in Stunden zu evaluieren. Stattdessen bewertet er es in Punkten, sodass wir die Widersprüche in der Wahrnehmung der Bewertung durch den Entwickler und Manager beseitigen. Darüber hinaus werden Ablenkungen und Umstände höherer Gewalt die Bewertung in keiner Weise beeinflussen, da sie die zur Lösung des Problems erforderlichen Anstrengungen nicht ändern!

Fibonacci-Nummern, T-Shirts und Hunde


Ja, ja T-Shirts und Hunde. Sie können eine beliebige Skala verwenden, um Aufgaben zu bewerten. Am häufigsten sind Fibonacci-Zahlen, dies sind klare Zahlenwerte und auch mit einem schönen Bonus: Die Elemente dieser Sequenz spiegeln gut das Wachstum der Unsicherheit wider, das mit der Komplexität des geschätzten Problems entsteht.

Einige Teams verwenden jedoch eine alternative Bewertungsskala. Am häufigsten ist eine Beurteilung bei T-Shirts und Hunden, wenn die Komplexität der Aufgabe in der Größe des T-Shirts (S, M, L, XL) oder in der Hunderasse (Chihuahua, Mops, Hund) angegeben ist. Dadurch werden die Teams noch stärker von der numerischen Darstellung der Bewertung abstrahiert, was in einigen Fällen sogar die Übertragung auf eine vorübergehende Bewertung untergräbt.
BildBild

Mannschaftswertung


Was ist der Unterschied zwischen Teambewertung und Einzelbewertung?
Warum ist es wichtig, das gesamte Team in die Bewertung einzubeziehen?

Einer der größten Fehler, der bei der Bewertung von Aufgaben gemacht werden kann, besteht darin, sie selbst zu erstellen und nicht die Meinung der Teammitglieder einzuholen. Vielleicht haben sie eine Meinung dazu? Möchten Sie neue Browserunterstützung hinzufügen? Was denken QS darüber?

Menschen sind die wichtigste Bewertungsressource. Sie können sehen, was Sie nicht sehen.

Aber wie führt man eine Teambewertung durch? Nur Noten zu schreien ist nicht sehr effektiv, außerdem kann ein anderes Teammitglied, nachdem es Ihre Note gehört hat, seine Meinung ändern und wird seine eigene nicht äußern.

Pokerplanung


Im Jahr 2002 beschrieb James Granning eine Methode, die später so populär wurde, dass Sie jetzt sogar echte Kartenspiele für die Pokerplanung kaufen können. Oder nutzen Sie einen der Onlinedienste für die Sitzung.

Das Wesentliche der Methode ist: Alle Teilnehmer des Teams erhalten Karten mit Zahlen aus der Bewertungsskala. Anschließend wird eine Aufgabe ausgewählt und ihre Anforderungen besprochen. Nach der Diskussion bittet der Moderator alle Mitglieder des Teams, eine Karte auszuwählen und auf den Kopf zu stellen. Dann gibt der Moderator ein Signal, um die Karten zu zeigen.

Wenn die Bewertungen der Teilnehmer konsistent sind, wird die Bewertung festgelegt, andernfalls werden die Karten auf die Hand zurückgegeben und die Teammitglieder diskutieren das Problem weiter. Es ist eine gute Idee, diejenigen mit unterschiedlichen Noten zu fragen: "Welche Schwierigkeiten sehen Sie bei dieser Aufgabe?" oder "Warum wird es Ihrer Meinung nach während der Implementierung keine Probleme geben?".

Es ist erwähnenswert, dass die Zustimmung nicht absolut sein sollte. Sie können zustimmen, dass eine Reihe benachbarter Bewertungen auch als Zustimmung betrachtet wird.

Alternativen


Wie die Bewertungsmethode selbst hat auch die Pokerplanung Alternativen. Ich werde kurz über einen von ihnen sprechen.

Sie können diesen Block überspringen und direkt zur nächsten Seite wechseln.

Affine Bewertung
« . , . , . — . , , , .

, . , . .

, , .

, „“ .

image


Projektplanung


Wie viele Stunden gibt es bei Story Point'e und wie erstelle ich ein Gantt-Diagramm?

Wir haben unseren Aufgabenstau sehr geschätzt, aber Sie können keinen Projektplan für Story Point'ah erstellen. Oft hat der Projektmanager eine Frage: „Wie übersetzt man SP in Stunden?“.

Die kurze Antwort auf diese Frage lautet: "Auf keinen Fall."

Natürlich können Sie den Entwicklern mit einer Stoppuhr folgen und die Zeit aufzeichnen, die sie zur Lösung des Problems benötigt haben, und diese Informationen dann in einem Diagramm anzeigen. Dann erhalten Sie die klassische „Glocke“, wie im Beispiel im folgenden Block. Wie wir in der ersten Abbildung sehen, dauern einige Aufgaben etwas länger, andere etwas weniger, aber im Allgemeinen entspricht der gesamte Wert einer Normalverteilung.

Gleiches gilt für Aufgaben in 2 SP. Dies ist in der zweiten Abbildung dargestellt. Haben Sie bemerkt, dass sich die „Schwänze“ der Diagramme schneiden? Ja, einige Aufgaben mit 1 SP erfordern möglicherweise mehr Aufwand als die einfachsten Aufgaben mit 2 SP. Am Ende hat noch kein Team gelernt, perfekt zu bewerten. Wenn wir den SP in Stunden übersetzen, kehren wir zum alten Rechen zurück. Wie viel Zeit der Entwickler benötigt, um ein bestimmtes Problem zu lösen, hängt stark vom Entwickler ab.
BildBild

Aber was zu tun ist, wir können die Planung nicht vollständig aufgeben. Glücklicherweise müssen wir dafür nicht jeden Story Point in Stunden übersetzen. Was wirklich zählt, ist, wie viel SP das Entwicklungsteam für den Sprint „schließen“ kann (Iteration, Release).

Durch das Sammeln von Daten zur Teamgeschwindigkeit erhalten Sie ausreichend genaue Daten für eine langfristige Projektplanung. Vergessen Sie außerdem nicht das Gesetz der großen Zahlen, die Schätzfehler werden gegenseitig kompensiert, dies gilt sowohl für Aufgaben als auch für Iterationen. Es ist erwähnenswert, dass dies ein wenig optimistisch ist, weil Ungenauigkeiten sind in der Regel eher mit einer Unterschätzung als mit einer Neubewertung verbunden. Aber nichts ist perfekt.

Geschwindigkeit (oder Geschwindigkeit) ist ein leistungsstarkes Planungswerkzeug und die Hauptmetrik des Entwicklungsteams. Das Team muss an einer kontinuierlichen Verbesserung arbeiten, um die Geschwindigkeit zu erhöhen. Vergessen Sie nicht, dass die Geschwindigkeit eine Ableitung von SP und daher auch relativ ist. Sie können nicht zwei Teams miteinander vergleichen, das Team konkurriert mit sich selbst.

Bild

Trainieren


Welche Nuancen müssen Sie kennen?
Welche Fehler können vermieden werden?

Abschließend möchte ich einige Tipps für diejenigen sammeln, die sich zum ersten Mal entschlossen haben, die beschriebenen Techniken in ihrer Arbeit auszuprobieren.

Wo soll ich anfangen?

Dies ist Ihre erste Pokerplanung und das Team versteht nicht, was neue Aufgaben zu bewerten sind. Sammeln Sie einige bereits erledigte Aufgaben, die im Idealfall gut bekannt oder typisch sind, und bewerten Sie deren Komplexität im Verhältnis zueinander. Verwenden Sie diese Aufgaben, um neue zu bewerten.

Haben Sie ein neues Projekt und keine abgeschlossenen Aufgaben? Versuchen Sie es mit der oben beschriebenen affinen Bewertung und weisen Sie der Bewertungsskala Aufgaben zu.

Keine durchschnittlichen Bewertungen

Wenn zwei Teammitglieder die Aufgabe unterschiedlich bewertet haben, ist es manchmal verlockend, der Aufgabe die durchschnittliche Punktzahl zuzuweisen und fortzufahren. Geben Sie dieser Versuchung nicht nach, die Diskussion ist ein wichtiges Element der Bewertung, bei der das Team bisher unbekannte Merkmale bei der Umsetzung der Aufgabe aufdecken kann.

Wie oben erwähnt, können Sie jedoch jederzeit zustimmen, dass Schätzungen, die nahe beieinander liegen, kein Grund für weitere Diskussionen sind.

Ändern Sie die Bewertungen nicht.

Auch wenn Sie während der Implementierung festgestellt haben, dass Sie bei der Planung einen Fehler gemacht haben, lassen Sie die Bewertung unverändert. Sie werden sich in Zukunft irren und in beide Richtungen. Lassen Sie diese Fehler sich gegenseitig kompensieren, stören Sie den Prozess nicht.

Fehlerbewertung

Ich bin auf verschiedene Ansätze zur Bewertung von Fehlern gestoßen. Einige Teams bewerten alle Fehler mit Ausnahme derjenigen, die bei der Implementierung neuer Aufgaben in der Iteration aufgetreten sind. Einige bewerten Fehler nicht, was dies durch die Tatsache rechtfertigt, dass die Geschwindigkeit des Teams einen neuen Wert anzeigen sollte, der dem Produkt hinzugefügt wird, und das Beheben von Fehlern das Wachstum dieses Indikators nicht beeinflussen sollte.

Welchen Ansatz Sie auch wählen, bleiben Sie konsequent. Informationen über die historische Geschwindigkeit des Teams sollten nicht durch die Verwendung unterschiedlicher Bewertungsansätze beeinflusst werden.

Null-Bewertungen

Eine weitere Frage, die keine klare Antwort hat. Jemand glaubt, dass es keine Aufgaben gibt, die keinen Aufwand erfordern. Andere antworten ihnen, dass das Zuweisen von Punkten zu einfachen Aufgaben zu einer unangemessenen Erhöhung des Geschwindigkeitsdiagramms des Teams führt.

Sie können für solche Aufgaben eine Punktzahl von 1/2 eingeben und nachträglich überwachen, ob der Anteil solcher Aufgaben angemessene Grenzen überschreitet. Der wichtigste Rat ist jedoch der gleiche: Bleiben Sie bei Ihren Entscheidungen konsequent.

Neubewertung nicht abgeschlossener Aufgaben zwischen Iterationen

Es ist nicht immer möglich, eine Aufgabe in einer Iteration abzuschließen, selbst wenn sie ursprünglich geplant war. Sie sollten jedoch die Bewertung nicht ändern, wenn Sie die nächste Iteration basierend auf dem verbleibenden Arbeitsaufwand planen. Beachten Sie dies bei der Planung, aber lassen Sie die Schätzung für die Geschichte unverändert.

Rückblickende Bewertungen

Wenn Sie noch keine Rückblicke durchführen, ist es Zeit zu beginnen! Dies ist ein großartiges Team-Tool, um die Teamgeschwindigkeit und -kohärenz zu erhöhen. Dies ist jedoch ein separates Problem.

Gehen Sie im Verlauf Ihrer Rückblicke die Schätzungen durch, die während der Iterationsplanung vorgenommen wurden, und diskutieren Sie, ob es große Abweichungen zwischen den Erwartungen und der Realität gab.

Sie können auch mehrere Probleme aus der Historie mit denselben Bewertungen abrufen und diskutieren, ob all diese Geschichten wirklich den gleichen Aufwand erfordern.

Zeichnen Sie alles auf.

Wenn Ihr Aufgabenverwaltungssystem keine Bewertungen unterstützt und die Teamgeschwindigkeit nicht automatisch berechnet, müssen Sie dies manuell tun. Wie Sie wahrscheinlich bereits vermutet haben, sind historische Daten ein wichtiges Instrument zur Verbesserung Ihrer Noten.

More articles:


All Articles