Agile Schätzung in Scrum? Story Point und Planungspoker

Für den Eigentümer des Projekts oder Produkts ist dies eine sehr wichtige Information für die Messung von Projektressourcen und Zeitplänen, aber in der Praxis hat dies viele Probleme verursacht.

Viele Entwickler haben immer das Gefühl, dass PM die Frist nutzt, um hin und her zu schieben. Es ist ihnen egal, ob das Feature qualitativ fertig gestellt werden kann.

„Erst machen, dann besser suchen“ kursiert daher schon lange in der Softwarebranche.

Viele PMs haben immer das Gefühl, dass Entwickler am ehesten zum „Übertreiben“ neigen, wenn sie ihre Arbeit einschätzen. Anscheinend verwenden sie alle die typische Arbeitsschätzungsmethode: „Schätzen Sie das Dreifache der tatsächlichen Zeit als Puffer“ “

Tatsächlich können Arbeitszeiten nicht „absolut genau“ geschätzt werden, aber es gibt einige Möglichkeiten, „relativ objektiv“ zu schätzen. Aufgrund der Komplexität der Arbeitszeiten und Anforderungen besteht häufig ein positiver Zusammenhang. Daher werden in diesem Artikel zunächst die allgemeinen Probleme in Reaktion auf die Komplexität der Anforderungen erläutert, ein Lösungsvorschlag vorgeschlagen und der Zweck vieler Entwürfe in der Lösung erläutert.

Probleme

Mine des Entwicklers

„Es ist sehr einfach. Es sollte nicht zu lange dauern, es zu machen?“
PM hat heute zu Ihnen gesagt: „Ich muss es vor morgen abgeben. „Erledigen Sie es, bevor Sie nach Qualität suchen“
PM hat übermorgen zu Ihnen gesagt: „Warum ist die Qualität des Programms so schlecht?“
Wenn es sich verzögert, andere Kollegen: „Wie können Sie sich so lange aufhalten? Dies hat einen vorgefertigten Code als Referenz. Dies hat eine gute untere Schicht zu verwenden. Warum hast du mich nicht gefragt?“
Andere Kollegen: „Ich brauche nur einen Tag, warum hast du so viele Tage verbracht?“
„Das ist gesunder Menschenverstand! Wenn wir die Anforderung nicht erwähnen, sollten Sie wissen, was zu tun ist.“

PM/PO ist meins

„Warum ist es so einfach? Es dauert so lange?“
„Warum siehst du, dass du Facebook besuchst, aber keine Zeit dafür hast?“
„Warum ist die Qualität der Dinge, die hergestellt werden, so schlecht?“
„Warum hat er es das letzte Mal geschafft, wie viele Tage musst du schaffen?“
Da die Spezifikationen oder Anforderungen nicht klar geschrieben sind, wird der Entwickler als Anforderungsänderung bezeichnet.

Ergebnis

Rollenfeindlichkeit: Die Nachfrageeinheit und die Entwicklungseinheit sollen nicht mehr ein Produkt liefern, das dem Anwender Nutzen bringen kann, sondern sich gegenseitig für ihre eigenen Zwecke angreifen, um keine zusätzliche Verantwortung tragen zu müssen. Daher die Situation, dass die Nachfrageeinheit und die Entwicklungseinheit überhaupt kein einzelnes Team sind.
Verantwortung: Das Team denkt, dass „ich mich nicht irre, also liegt die Verzögerung nicht in meiner Verantwortung“, anstatt die Bedürfnisse der Benutzer zu priorisieren.
Demand-Freeze: Entwickler sind aufgrund von Termindruck gezwungen, ihre Anforderungen zu ändern, sonst verzögern sie sich und die Verantwortung wird dem Entwickler zugerechnet. Folglich müssen entweder Überstunden gemacht werden, um etwas zu produzieren, das viele Fehler verbirgt, oder um eine Art Funktion zu erstellen, die nicht den Anforderungen der Benutzer entspricht; und beides wird die Benutzerzufriedenheit verringern.
Niedrige Qualität: Der Status von PM ist oft höher als der von Entwicklern. Um die Vertragsfrist einzuhalten oder Strafen usw. zu vermeiden, wird das Team daher aufgefordert, „erst fertig zu werden, dann besser zu suchen“, aber schließlich heißt es oft „zuerst ist keine Zeit, um Gutes zu suchen .“ Die Anhäufung technischer Schulden nimmt zu, und das Ergebnis ist das reale Modell der Verantwortungskette, bei dem die größte Verantwortung und die größten Kosten ganz am Ende der Kette liegen. Das Team ist also wie ein Stack-Pop, Entwickler können nicht einen nach dem anderen aufrechterhalten, was einer der Faktoren ist, warum Ingenieure in Projektunternehmen oft hohe Fluktuationsraten haben.
Gewichtung des Codes erhöhen: Um die Effizienz zu optimieren, wird immer die Position der vertrautesten Person zur Schätzung der Arbeitsstunden verwendet, sodass sich immer die Person, die mit dem Modul und dem Prozess am besten vertraut ist, mit den relevanten Anforderungen befasst . Am Ende können nur diese Leute ihren eigenen Code pflegen, es ist wie bei einer Büchse der Pandora, man weiß nie, welche Kühe und Gespenster nach dem Öffnen auslaufen. Denn die Black Box ist oft dreckig, aber das Unternehmen hatte keine Ahnung, wie man dieses Problem lösen könnte. Sie hoffen auch, dass er nicht geht, sonst wird ein Teil des Codes nicht verstanden.

Lösungen

Die hier vorgeschlagene Lösung ist ein gängiger Weg, um die Komplexität von Anforderungen in Scrum einzuschätzen, aber selbst wenn es sich nicht um ein Scrum-Team handelt, wird empfohlen, dass die Leser in der Lage sind, den besten Weg zu finden, um Ihr Team basierend auf den Prinzipien und Designzielen einzuschätzen .

Denken Sie daran, dass ohne Patentrezepte die Best Practice von jemand anderem nicht unbedingt auf Ihr Team zutrifft. Verstehen Sie also zuerst, welches Problem Ihr Team derzeit hat, und finden Sie dann heraus, was für Sie das Richtige ist, um das Problem aus der Praxis eines anderen zu lösen , sofern dadurch keine neuen Probleme entstehen oder das Kostenrisiko eines neuen Problems vertretbar ist.

Die hier verwendete Einheit zur Abschätzung der Komplexität von Anforderungen ist Story Point (relative Einheit), nicht Arbeitszeit (absolute Einheiten).

Die Einheit zur Abschätzung der Komplexität der Nachfrage ist hier der Story Point (relative Einheit), nicht die Arbeitszeit (absolute Einheit). Dafür gibt es mehrere Gründe:

1. Vergleiche unterscheiden sich nicht von Person zu Stelle: Die Komplexität der Anforderung variiert oft nicht von Person zu Person, und die Zeit, die zum Üben benötigt wird, ist von Person zu Person unterschiedlich.

2. „Relativ“ ist einfacher zu bewerten als „absolut“: Wenn Sie sich die Arbeitszeiten ansehen, müssen Sie die absolute Zahl schätzen und bei der Schätzung über die Details der Umsetzung nachdenken. Um den Story Point zur Abschätzung der Komplexität zu nutzen, müssen Sie lediglich die Größe mit anderen Anforderungen vergleichen.

Zum Beispiel ist es schwer klar zu sagen, dass „ein Turm ein paar Meter hoch ist“, aber es ist einfacher darauf hinzuweisen, dass „dieser Turm etwa zweimal höher ist als dieses Gebäude“.

3. Der Druck, den Story Point einer User Story abzuschätzen, ist geringer als die Abschätzung ihrer Arbeitszeit: Konzentrieren Sie sich auf die Anforderung selbst, ohne sich Gedanken über die eigenen Ressourcen und Projektressourcen zu machen, bewerten Sie einfach die Komplexität der Anforderung. Während des Schätzprozesses sind die Teammitglieder weniger gestresst und nehmen wie ein Spiel an der Softwareentwicklung teil.

Obwohl die Komplexität der Nachfrage oft positiv mit den Arbeitszeiten zusammenhängt, ist es aufgrund der unterschiedlichen Implementierungsbedingungen dennoch möglich, ein Feature mit einem hohen Story Point zu haben, und die Nachfrage nach Arbeitszeit ist niedriger als der Story Point. Aber in Scrum können Sie den Iterationssprint verwenden, um auszuwerten, wie viel Komplexität jedes Sprintteam verdauen kann. Für PO/PM ist es besser, anstatt einen erfolglosen Zeitverlauf zu schätzen, einen genaueren und objektiveren Zeitverlauf zu schätzen, damit sie zum ersten Mal verstehen, wie weit sie vom erwarteten Zeitverlauf des Projekts entfernt sind. Wenn die Ressourcen begrenzt sind, wie Sie Anforderungen priorisieren oder andere Unterstützung suchen.

Erklären Sie als Nächstes die verschiedenen Aspekte der Lösung.

Wann

Führen Sie eine Bewertung durch, bevor Sie entscheiden, wer sie durchführen muss: Der Vorteil besteht darin, die persönlichen Faktoren des Entwicklers zu minimieren. Da Sie nicht wissen, wer es tun wird, müssen Sie das Hinzufügen von Puffer aufgrund Ihrer eigenen Aufgabe oder Frist nicht überschätzen.

WHO

Nur die Leute, die Dinge tun, um gemeinsam zu evaluieren: zwei wichtige Punkte:

Nur Menschen, die Dinge tun, können geschätzt werden. Die von der Anforderungseinheit geschätzte Zeit oder Komplexität ist nicht objektiv, da sie nicht die tatsächliche Person ist, die die Arbeit erledigt, und es keine Befugnis gibt, die Schätzung des Entwicklungsteams basierend auf der Bewertung des Arbeitsaufwands zu beeinflussen. Dies erleichtert auch die Vermeidung der Bewertung der Komplexität der Anforderungen von Deadline.
Menschen, die Dinge gemeinsam tun, schätzen. Da Sie nicht wissen, wer es tun wird, lassen sich die Zahlen, die jede Person gemeinsam schätzt, nach Diskussion und Neuschätzung leicht konsensieren. Jeder hat die Teilnahme, er wird ein Gefühl der Teilnahme haben, und weil jeder die Teilnahme hat, wird das Schätzergebnis von allen entschieden, also wer es in Zukunft tun wird, wird sich nicht beschweren.

Was

Verwenden Sie den Planungspoker, um den Story Point abzuschätzen.

Pokerkarte und Fibonacci-Folge

Die Fischer-Reihe hat ein interessantes Merkmal, und jede Zahl sind die ersten beiden addierten Zahlen. Andererseits gilt: Je größer der Unterschied zwischen der Zahl und der nächsten, desto größer der Unterschied.

Wie oben gezeigt, beträgt der Abstand zwischen 8 und 13 5 und der Unterschied zwischen 13 und 20 7. Wie hängt dies jedoch mit der Schätzung der Komplexität der Nachfrage zusammen? Wir sind nicht im Matheunterricht.

Merkmale der Schätzung in Bezug auf die Fibonacci-Folge

Schätzungen haben auch eine Eigenschaft, das heißt, je größer desto genauer, je größer der Bedarf oder die Aufgabe auf eine feinere Granularität geschnitten wird, desto genauer wird oft geschätzt. Genau wie wenn ein großes unregelmäßiges Steinstück in eine Tasse eingebaut wird, gibt es in der Mitte mehr Lücken, das ist der Teil, der nicht ausgerichtet oder verschwendet ist. Wenn Sie einen Stein mit einer feineren Größe und der gleichen Unregelmäßigkeit installieren, ist der Spalt relativ klein und lässt sich leicht einstellen und kann den Spalt bequemer füllen.

Auch wenn der Unterschied zu den vorherigen Zahlen relativ gering ist, spielt dies keine Rolle, da die Anzahl klein ist, was bedeutet, dass die Bewegung flexibel und das Risiko gering ist. Wenn die Zeitschätzung aufgrund bestimmter Faktoren ungenau ist, beträgt die Aufgabe der kleinen Zahl vorne etwa 20 Minuten Überstunden. Anstatt 2 oder 5 Tage Überstunden zu machen.

Da die große digitale Lücke groß ist (das Differenzverhältnis der beiden vorderen und hinteren Werte der Fermi-Reihe liegt nahe bei 1,618), kann die Abschätzung „ob diese Komplexität 20 oder 21 beträgt“ vermieden werden. „Wenn du 13 willst, willst du 20, du willst 40.

Eine solche Lücke kann den Unterschied in den Schätzungen derselben Anforderung hervorheben, da fast alle mehr als 1,5-mal schlechter sind. Dieses Verhältnis ist für den Menschen relativ einfach zu beurteilen und kann daher viele Nuancen reduzieren und unnötige Prozesskosten neu einschätzen.

Spezielle Zahlen in der Pokerkarte

Darüber hinaus ist das obige Bild mit einigen Sonderzahlen zu sehen, nämlich 0, unendlich und Fragezeichen.

0 kann bedeuten, dass diese Anforderung gar nicht oder bereits erledigt werden muss.
Unendlich bedeutet, dass der Bedarf klar ist, aber derjenige, der die maximale Anzahl überschreitet, zeigt an, dass der Bedarf in mehrere kleinere Anforderungen unterteilt werden muss.
Das Fragezeichen zeigt an, dass die Nachfrage nicht klar ist und PO/PM zur Erklärung oder Klärung benötigt.

Wie

1. Definieren Sie zunächst die Einheit der Komplexität 1 , beispielsweise die Funktion einer eine einzelne Tabelle umfassenden Abfrage. Da unser Schätzprozess auf der relativen Größe basiert, definieren wir zunächst die Einheit der Vergleichsbenchmark, und nach den Schätzungen des Teams gibt es eine Vergleichsbasis.

2. Der Moderator spricht die Anforderungen (z. B. die User Story Card) laut aus, um sicherzustellen, dass jeder die Anforderungen versteht und jede Person ihre eigene geschätzte Komplexität darstellt. Der Grund für die Verwendung von Planungspoker liegt darin, dass die von Ihnen bewerteten Zahlen gleichzeitig präsentiert werden können, anstatt die von Ihnen bewerteten Zahlen zu rotieren. Es ist leicht, die Zahlen aus den Augen zu verlieren und die Ergebnisse der Menschen dahinter durch die vorherigen Zahlen zu beeinflussen.

3. Wenn es im Team unterschiedliche Schätzungen gibt, werden die beiden als die kleinste und die größte geschätzt und sie werden beurteilen, warum sie kompliziert oder einfach sind. Wenn im obigen Beispiel im Schätzungsprozess eine Person den Story Point auf 13 schätzt, schätzen die meisten Personen 20 und eine andere Person 40. 13 und 40 sind fast dreimal schlechter, also müssen im Grunde einige wichtige Informationen vorhanden sein nicht synchronisiert worden.

Beispielsweise denken Personen, die 13 schätzen, dass diese Anforderung fast dieselbe ist wie eine Anforderung in der Vergangenheit, und diese Anforderung ist nicht so kompliziert wie gedacht. Die Person, die 40 schätzt, fühlt sich möglicherweise relativ kompliziert, weil sie mit dieser Anforderung oder diesem Prozess nicht genug vertraut ist.

4. Mindest- und Höchstzahlen Die Begründung der Bewertung wird vervollständigt und es findet eine weitere Abstimmung statt. Wenn es immer noch unterschiedliche Stimmenzahlen gibt und die überwiegende Mehrheit der Menschen einen Konsens hat und kein Konsens darüber besteht, dass die geschätzte Komplexität nur eine Ebene von der Konsenskomplexität entfernt ist, können Sie die Mitglieder fragen, die die unterschiedlichen Zahlen schätzen, ob sie es tun kann die von Ihnen ermittelten Zahlen übernehmen.

5. Wenn die Zahl immer noch eine Lücke über einem Niveau hat oder wenn kein Konsens erzielt werden kann, wiederholen Sie die Schritte 3 bis 5, bis ein Konsens erreicht ist.

Auch hier können nur diejenigen am Abstimmungsprozess teilnehmen, die tatsächlich Aufgaben ausführen oder die Anforderungen erfüllen, und PO/PM kann sich nicht einmischen.

Warum

Diese Art der Schätzung hat mehrere Vorteile:

Die Person, die zusammenarbeitet, entscheidet sich für ein vernünftiges und objektives Bewertungsergebnis, hat ein Gefühl der Beteiligung und hat keine Beschwerden.
Das Ergebnis der Entscheidung ist der Konsens zwischen PO und Team, der das Auftreten von Ti-for-Tat-Situationen in Zukunft reduzieren wird.
Jeder kann die Anforderung verstehen. Künftig kann jeder als Erfüller der Anforderung fungieren. Wenn Unterstützungsbedarf besteht, können sich die Menschen auch gegenseitig helfen oder unterstützen.
Bevor Sie dies getan haben, können Sie den unklaren und den zweifelhaften Teil der Anforderung klären.
Bevor Sie es tun können, können Sie die beste und effizienteste Art finden, im Team zu arbeiten.
Sofern das gesamte Team keine unzuverlässige Person ist, spiegelt diese Zahl die Tatsache wider, dass die Schätzung vom Team geteilt wird und PO die Lücke zwischen Bedarf und Bewertung verstehen kann.
Durch den Vergleich der relativen Größe der Komplexität zwischen den Anforderungen kann die zukünftige PO versprechen, wie viel Arbeit in einer Iteration erfüllt werden kann, und es wird eine Vergleichsbasis geben.

Fazit

Durch den obigen Bewertungsprozess ist eine solche Entscheidung offen, transparent, objektiv und einvernehmlich. Für zwei Rollen:

Für Bestellung/PM:

Machen Sie sich keine Sorgen, dass bestimmte Mitglieder eine Aufgabe für einen Puffer überschätzen.
Verständnis der zugrunde liegenden Schwierigkeit bei der Umsetzung von Anforderungen oder Aufgaben im Bewertungsprozess.
Verstehen Sie, ob es Teile der Anforderung gibt, die klar angegeben oder missverstanden werden müssen.

Für Mannschaft:

Personen, die etwas nicht mehr tun, wird eine unangemessene Frist gemäß Fristsetzung gesetzt.
Wissensaustausch zwischen Entwicklern, bevor sie mit der Arbeit an der Aufgabe beginnen. Unabhängig davon, ob die geschätzte Anzahl erhöht oder verringert wird, ist die Nachfrage klarer und die Schätzung objektiver.
Da Sie noch nicht wissen, wer diese Aufgabe beansprucht, damit der Schätzprozess objektiv und im Teamkonsens erreicht werden kann, wissen Sie durch den Prozess, wer mit dieser Aufgabe vertraut ist. Wenn Sie es tatsächlich tun, können Sie die Programmierung koppeln oder wissen, wen Sie um Hilfe bitten müssen.

Die in diesem Dokument vorgeschlagene Lösung ist eine gängige Lösung. Der Fokus liegt nicht auf der Form, sondern auf dem Gestaltungszweck jedes Glieds im agilen Schätzprozess, um welche Art von Problem zu lösen.