it-swarm.dev

Was ist die beste Erklärung dafür, was Story Points sind?

Wir beginnen hier, Story Points für unsere agile Entwicklung zu verwenden, aber ich finde es schwierig zu erklären und kann auch keine endgültige Antwort darauf finden, was sie sind. Das Beste, was ich tun kann, ist, auf andere Websites zu verweisen (wie http://blog.mountaingoatsoftware.com/tag/story-points ) und eine vage Verallgemeinerung dessen zu geben, was sie sind. Ich suche nach einer guten Erklärung mit einigen Anwendungsbeispielen, die für andere hilfreich wären. Gibt es gute Ressourcen, um Story Points zu erklären?

36
six8

Dies kann als Starter helfen: Mike Cohn über Story Points . Aber dieser ist weitaus besser: Agile Entwicklungsteams: Scope and Scale mit Mike Cohn

Mikes Lösung für Software-Schätzmetriken ist einfach und effektiv. Biologische Fakten:

  • Das menschliche Gehirn kann die Zeit einfach nicht richtig einschätzen. Besonders wenn mehr als ein paar Stunden.
  • Dies wird durch die Unsicherheiten bei Softwareentwicklern, den psychologischen Druck des Managements (wenn Sie schätzen, verpflichten Sie sich ...) und die unterschiedlichen Fähigkeiten im Team erheblich verstärkt.
  • Wir sind jedoch ziemlich gut darin, Dinge zu vergleichen. Wir sind dort ziemlich genau.

Die Idee ist, eine Referenz-User-Story zu nehmen und ihr dann eine beliebige Anzahl von (Story-) Punkten zu geben. Dann erhalten andere Storys Punkte, die sich auf diese Referenz beziehen .

Wenn Ihre Referenzgeschichte 100 Punkte und eine andere Geschichte dreimal größer ist, sind es 300 Punkte.

Um Story-Punkte in Zeit für Ihre Planung umzuwandeln, müssen Sie Ihre Geschwindigkeit kennen.

Um eine genaue Geschwindigkeit zu erhalten, müssen Sie einige Iterationen durchführen und berechnen, wie viele Punkte Ihr Team in einer bestimmten Zeitspanne erreicht hat.

Es funktioniert.

36
user2567

Ich bin mit allem einverstanden @Pierre 303: oben gesagt : (abgesehen von den 100 Referenzpunkten).

Das einzige, was ich hinzufügen möchte (Hervorhebung), ist, dass wir Aufgaben nicht gut einschätzen können. Wir können Aufgaben relativ zu anderen Aufgaben schätzen, solange sie ungefähr gleich groß sind. Je größer der Unterschied zwischen den Aufgaben ist, desto schlimmer werden wir.

Daher bin ich nicht damit einverstanden, einen Startpunkt von 100 zu verwenden.

Es ist nicht so, als würden Sie die nächste Aufgabe als 42% der Referenzaufgabe schätzen. Es ist entweder die gleiche Hälfte der Arbeit, die doppelte Arbeit, die dreifache Arbeit usw.

Unser Team verwendet Planing Poker : Hier haben wir eine Referenzaufgabe von 2 Story Points. Wir verwenden dann die Fibonacci-Reihe, um Aufgaben zu schätzen: 1,2,3,5,8,13,21, Riesig? relativ zur Referenzaufgabe (Anstelle der Fibonacci habe ich gesehen, dass andere Teams Potenzen von 2 verwenden. 1,2,4,8,16,32, Riesig?) Ich habe gesehen, dass andere Teams (klein (1), mittel () verwendet haben. 2), groß (3), XLarge (4), als sie die Geschwindigkeit berechneten, funktionierte es immer noch.).

Der Punkt ist, dass wir mit zunehmender Größe der Aufgabe im Verhältnis zur Referenzaufgabe weniger in der Lage sind, ihre Kosten genau abzuschätzen. Es macht also keinen Sinn, es zu versuchen. Dies spiegelt sich in dem größeren Gradienten am Ende des Schätzpfads wider.

Wenn Ihre Referenzaufgabe also 2SP ist. Dann ist es relativ einfach, eine Schätzung von 1/2/3/5 vorzunehmen, da die Aufgaben ähnlich groß sind. Sobald Sie dreimal so groß wie die Referenzaufgabe (5SP) sind, wird die Schätzung schwieriger (Ist 8/9/10SP wichtig)? Alles, was Sie sagen können, ist, dass es größer als 5SP und kleiner als 13SP ist, dann passt 8SP in die Rechnung.

Alles mit einem SP -Wert von 13/21/Huge ist zu groß für den Sprint-Rückstand. Dies sind Schätzungen für Dinge, an denen Sie noch nicht bereit sind, tatsächlich zu arbeiten (und die daher noch nicht unterteilt wurden) kleinere Aufgaben (teilen Sie sie erst auf, wenn Sie sie auch benötigen). Sie geben Ihnen jedoch eine Schätzung für die Größe einer Aufgabe im Product Backlog (was eine zukünftige Planung ermöglicht). Bis Sie den Punkt erreicht haben, an dem Wenn Sie daran arbeiten möchten, sollten Sie über genügend Wissen verfügen, um sie in kleinere Aufgaben für den Sprint-Rückstand aufzuteilen und sie einzeln neu zu schätzen (Hinweis: Es ist ein weit verbreitetes Missverständnis, dass die Summe der Teile dem Original entspricht).

  • Alles, was Sie als riesig einschätzen, muss in kleinere Aufgaben unterteilt werden.
  • Etwas, das als geschätzt wird? bedeutet, dass es nicht gut genug definiert ist, um zu schätzen
    Sie müssen eine Aufgabe speziell hinzufügen, um die Aufgabe zu definieren
    (d. h. eine Dokumentation oder Präsentation schreiben).
5
Martin York

Sie sind Zeitverschwendung.

enter image description here

http://www.Amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

Interessant, dass diese Meinung jetzt von dem Typ stammt, der Scrum und XP aus den Gräben geschrieben hat und dessen Firmenname ( Crisp ) kann auf so vielen Kartenspielen gefunden werden, die von so vielen Teams auf der ganzen Welt verwendet werden.

Der letzte Satz des OP: "Gibt es gute Ressourcen, um Story Points zu erklären?" Ja, dieses Buch ist eine gute Ressource. Denkanstöße.

2
azheglov

Story Points sind ein relatives Maß dafür, wie schwierig eine Aufgabe ist. Dies liegt daran, dass Menschen relative Schätzungen tatsächlich besser können als präzise Messungen.

Bei der Verwendung von Story Points übernehmen Sie ungefähr zwei Aufgaben im Projekt und weisen ihnen zwei verschiedene Story Point-Werte zu. Anschließend schätzen Sie die anderen Aufgaben anhand dieser beiden Story-Point-Näherungen als Grundlage für Ihre Schätzung. Das heißt, Aufgabe C ist nicht viel schwieriger als Aufgabe A, aber unglaublich einfacher als Aufgabe B, sodass nur 2 Story Points mehr Arbeit als Aufgabe A sind.

Wenn Sie alle Anforderungen, die Sie bisher haben, geschätzt haben, schätzen Sie, wie viele Sie in einem Sprint erledigen können. In den nächsten Sprints schätzen Sie, wie viele Sie absolviert haben. Die Story-Punkte einer Anforderung gelten nur dann als abgeschlossen, wenn die Anforderung erfüllt ist. In Scrum gibt es keine "80% vollständig". Dies liegt daran, dass Menschen die Vollständigkeit tatsächlich schlecht einschätzen können. Nach einigen Sprints sollten Sie eine Vorstellung davon haben, wie viele Story-Punkte Sie pro Sprint erzielen können.

Wie schätzen Sie ein? Mit Planen von Poker können Sie bestimmen, wie viel Arbeit Ihre Entwickler im Verhältnis zu Ihren Basisanforderungen für eine Anforderung benötigen.

Ich würde auch empfehlen, The Agile Samurai zu lesen. Es macht einen guten Job, diese und andere agile Konzepte meiner Meinung nach zu erklären.

Hier ist ein Link mit mehr zu Story-Punkten.

Hier ist ein weiterer Link.

2
indyK1ng

Wie andere bereits erwähnt haben, sind Story Points ein relatives Maß für die Komplexität einer User Story. Der wahre Nutzen von Story Points wird erkannt, wenn

  1. Die Punkte werden von der für die Implementierung zuständigen Einheit (entweder einer Einzelperson oder dem Team) gemessen.
  2. Es werden Metriken für die Anzahl der Aggregatpunkte beibehalten, die von derselben Einheit innerhalb einer konstanten Dauer (Geschwindigkeit) ausgeführt werden.

Nach einigen Iterationen des Messens in Story-Punkten und der Verfolgung der Geschwindigkeit sollten Sie in der Lage sein, genau abzuschätzen, wie viele Story-Punkte in einen bestimmten Zeitblock passen (Iteration oder Sprint bei Verwendung von Scrum). Beachten Sie, dass das Anwenden dieser Technik auf eine Gruppe und der Versuch, diese Metriken für ein anderes Team zu verwenden, nicht gut funktioniert. Das heißt, wenn Team a in einem zweiwöchigen Sprint 120 Story-Punkte erreichen kann, ist es unrealistisch, zu erwarten, dass Team b die gleichen Ergebnisse erzielt.

Wie bereits erwähnt, ist die Planung von Poker eine große Hilfe bei der Verwendung dieser Methode, da sie dazu beiträgt, Geschichten zu identifizieren, die weiter verfeinert werden müssen (wenn es eine Diskrepanz zwischen den Stimmen gibt, bedeutet dies, dass die Anforderungen unsicher sind).

0
Michael Brown

Die einfachste Erklärung, die ich finden kann, ist die Verwendung eines Objekts, das greifbar ist und ein konkretes Beispiel liefern kann.

Nehmen Sie ein Mobilheim. Wenn ich im Mobilheimgeschäft tätig wäre, würde ich wissen, dass das Erstellen einer einzelnen Breite normalerweise 5 (Punkte, Frösche, Widgets ... die Messform ist willkürlich) erfordert und daher das Erstellen einer doppelten Breite etwa den doppelten Aufwand oder 10 (Punkte) erfordern sollte , Frösche, Widgets).

Die Denkweise des Programmierers wird an diesem Punkt einspringen und über einen optimierten Ansatz sprechen. Es dauert nicht doppelt so lange, da die Infrastruktur den größten Teil der Zeit in Anspruch nimmt und andere ähnliche Beispiele. Das ist unvermeidlich. Harfe auf die Tatsache, dass dies eine Schätzung in (Punkte, Frösche, Widgets) ist, da wir NIEMALS zeitlich genau schätzen können und somit eine Schätzung in (Punkte, Frösche, Widgets) den Glauben beseitigt, dass wir es können.

Um zu wissen, wie lange es dauern wird, bis etwas aufgebaut ist, werden wir unsere Trends im Laufe der Zeit nutzen. Daher werden unsere Schätzungen im Laufe der Zeit immer genauer.

Vergiss nicht Poker planen wenn das Team bereit ist zu gehen.

0
Aaron McIver