Die Größe spielt eine Rolle! Achten Sie darauf, die Geschwindigkeit als Maßstab für Verbesserungen zu verwenden

Stellen Sie sich vor, Sie spielen ein Rugbyspiel gegen ein paar schwarz gekleidete Jungs, die ein paar seltsame Tanz- und Schreiübungen machen, bevor Sie endlich mit dem Spiel beginnen. Sie gewinnen das Spiel mit 27 - 3. Sie können sich vorstellen, dass es nicht nur bei einem Bier auf der großen Party nach dem Spiel geblieben ist und Sie erst am frühen Morgen wieder zu Hause waren. Ein Jahr später findet sich Ihre Mannschaft im selben Stadion gegen dieselben Jungs wieder und tanzt dasselbe Stückchen Volkstanz, nur etwas lauter als im letzten Jahr. Dieses Mal gewinnen Sie nur 27 - 6. Der Trainer und die Zuschauer sind außer sich: Ihre Mannschaft hat in nur einem Jahr die Hälfte ihrer Leistung verloren! Sie duschen, trinken kein Bier, gehen nach Hause und gehen früh ins Bett. Die Messung der Leistungssteigerung ist einfach! Beschleunigung ist ein Muss Scrum befürwortet die Verwendung von Pokerkarten, die die Schätzung von Arbeitselementen in Story Points angeben. Velocity ist die Gesamtzahl der Story Points, die ein Team in einem Sprint bewältigen kann. Neben der Verwendung von Velocity für die Planung wird Velocity oft als Maß für Verbesserungen propagiert. Lernen, das Lösen von Hindernissen, die Umsetzung von Verbesserungen, mehr Spaß und ein besseres Zusammenspiel im Team - all das sollte zu einer höheren Velocity über Sprints hinweg führen. Eine gleichbleibende oder sogar sinkende Velocity ist ein Zeichen für ein mittelmäßiges, sich nicht verbesserndes Team. Die Theorie und die tatsächliche Praxis der Schätzungen in Story Points gehen auseinander, was es schwierig macht, aus den Velocity-Aufzeichnungen Rückschlüsse auf die Leistung zu ziehen. Es stellt sich die Frage, ob Velocity überhaupt als Maß für Verbesserungen verwendet werden sollte. In diesem Blog wird erklärt, warum Sie das nicht tun sollten, oder dass dies zumindest "nur geschulten Fachleuten" vorbehalten sein sollte. Wie mögen Sie Ihre Story Points? In einem Blog vom letzten Sommer (21. Juni 2010, its-effort-not-complexity) qualifiziert Mike Cohn die Umbenennung von Story Points in Komplexitätspunkte als 'falsch'. Er erklärt: "Bei Story Points geht es nicht um die Komplexität der Entwicklung einer Funktion, sondern um den Aufwand, der für die Entwicklung einer Funktion erforderlich ist." Wenn wir Mike folgen, sind Story Points eine Funktion der Komplexität, des Arbeitsaufwands ('schieres Arbeitsvolumen') und der Expertise (des Teams auf dem Gebiet). Vielleicht sollte auch die Unsicherheit in die Formel einfließen. Die Konsequenz dieser Definition ist, dass der Arbeitsaufwand abnimmt, wenn das Team mehr Fachwissen erlangt, intelligentere Lösungen einsetzt oder von strukturellen Verbesserungen profitieren kann. Um es mit Frey in seinem ersten Kommentar zu Mikes Blog zu sagen: "Eine Story, die letztes Jahr eine 5 war, hat jetzt einige Prozessverbesserungen und ist dieses Jahr eine 2. Die Geschwindigkeit des Teams bleibt gleich, die Story-Punkte pro Story nehmen ab." Nennen wir diese Methode A. Diese Methode zur Bestimmung der Story-Punkte unterscheidet sich von der Methode, mit der ich aufgewachsen bin: User Stories werden relativ zu einer festen (Reihe von) Referenz-User Stories geschätzt. Eine Story von 5 im letzten Jahr ist immer noch eine 5. Umgesetzte Verbesserungen (ob technisch oder in Bezug auf Teamarbeit, Fähigkeiten, Wissen oder Kompetenzen) sollten zu einer höheren Leistung führen, so dass wir mehr solcher Storys in einem Sprint erledigen können. Die Geschwindigkeit nimmt zu, die Story Points pro Story bleiben konstant. Lassen Sie uns diese Methode B nennen. Zählen Sie bei der Planung auf Story Points In Scrum werden Schätzungen und Velocity-Aufzeichnungen in erster Linie zu Planungszwecken verwendet. User Stories werden in Story Points geschätzt, und die Anzahl der im Sprint geplanten Stories hängt von der Summe der Story Points dieser Stories und der Velocity des letzten Sprints oder der letzten zwei Sprints ab. Darüber hinaus können Story Points und Geschwindigkeitsaufzeichnungen auch für die Release-Planung verwendet werden.Egal, ob Sie Methode A oder B verwenden, ein Team kann das Ergebnis eines Sprints richtig vorhersagen. Und in beiden Fällen kann man die Anzahl der Sprints berechnen und vorhersagen, die benötigt werden, um eine ausgewählte Gruppe von User Stories in einem Release fertigzustellen. Bei Methode A muss sich das Team jedoch mit neuen Kompetenzen auseinandersetzen, die zu niedrigeren Schätzungen führen, selbst für User Stories, die in der Vergangenheit geschätzt wurden. Bei der Verwendung von Methode B muss das Team bei der Vorhersage der Anzahl der Sprints, die für ein bestimmtes Release benötigt werden, eine höhere Geschwindigkeit berücksichtigen. Die Messung der Verbesserung ist eine andere Geschichte Scrum verspricht eine Steigerung der Produktivität/Leistung. Oft wird ein Wachstumsfaktor von 4 oder sogar bis zu 10 genannt. Schon bald nach der Einführung von Scrum verlangt das Management einen Beweis für dieses Wachstum, vor allem, nachdem sie über alle zuvor verborgenen Hindernisse in ihrer Organisation verblüfft waren: Scrum löst Ihre Probleme nicht, sondern deckt sie auf! Die Überzeugung, die versprochenen Vorteile zu erreichen, ist eine schwere Bürde.Sehr oft wird die Geschwindigkeit (Velocity) verwendet, um diese Verbesserung zu messen. Das gilt aber nur, wenn wir die Story Points für dieselbe Art von Storys konstant halten, wie in Methode B gezeigt. Dies wird durch ein Beispiel von Jose in einem anderen Kommentar auf Mikes Blog gezeigt: Stellen Sie sich vor, wir haben ein Team von Malern, deren Aufgabe es ist, Wände zu streichen. Das Team sieht Bilder der Wände und schätzt die zu streichende Wandfläche. Es gibt kleine Wände, mittlere Wände und einige wirklich große Wände. Das Team schätzt jede Fläche anhand von relativen Punkten. Sie fangen an, die Wände zu streichen, und nach einiger Zeit können sie berechnen, wie viele Punkte sie in jedem Sprint schaffen können, also die Geschwindigkeit. Jetzt kann der Kunde anhand der Velocity und des Product Backlogs berechnen, wie lange das Projekt dauern wird. Das Problem ist, dass die Bestimmung der Größe eine der schwierigsten Herausforderungen auf dem Gebiet der Softwareentwicklung ist. Es gibt sicherlich Umgebungen, in denen dies gut funktioniert. Kürzlich haben wir ein Team in einer Business Intelligence-Umgebung gecoacht, das in der Lage war, seine Arbeitspositionen in vordefinierten Schritten zu definieren, und das aus Erfahrung Formeln abgeleitet hatte, um den Arbeitsumfang für jeden Schritt zu berechnen. Sobald die Maler bessere Werkzeuge und Farben bekommen oder an Erfahrung und Konzentration gewinnen, werden sie in der Lage sein, größere Wände in der gleichen Zeit zu streichen. Für die meisten anderen Teams kommt die Funktionspunktanalyse dem am nächsten, was alles andere als einfach ist und nicht zu den üblichen Fähigkeiten von Entwicklungsteams gehört. Fast jedes andere Team, das wir gesehen haben, schätzt den Aufwand. Bessere Werkzeuge, ein höherer Automatisierungsgrad, mehr Kompetenzen - all das führt zu weniger Aufwand und wird in den endgültigen Story Points nicht berücksichtigt. Für die Planung ist das in Ordnung, aber die Verwendung von Geschwindigkeitstrends auf der Grundlage dieser Story Points ist eine sehr heikle Angelegenheit und wird das von den Teams erzielte Wachstum nicht in dem Maße widerspiegeln, wie es ihnen zusteht. Die Pointe dieser Geschichte: Größe ist wichtig Story-Punkte werden mit unterschiedlichen Methoden und Formeln berechnet. Wenn Ihre Formel nicht nur der schieren Größe entspricht, sollten Sie Ihre Geschwindigkeitsmessungen nicht als Indikator für Leistungswachstum verwenden. Genauso wie Sie Ihre Leistungsentwicklung nicht einfach durch den Vergleich der Ergebnisse zweier Rugbyspiele ermitteln können. Wenn es noch viele andere Faktoren gibt, die die Ergebnisse beeinflussen, tun Sie dem Team Unrecht und sollten sich daran halten, diese Rekorde nur zu verwenden, um 'ein Gespräch zu beginnen'. Die Messung der Leistungsverbesserung ist nicht einfach.