it-swarm-eu.dev

Warum verwenden wir Story Points anstelle von Manntagen, wenn wir User Storys schätzen?

Bei agilen Methoden (z. B. SCRUM) wird die Komplexität/der Aufwand für User Stories in Story-Punkten gemessen. Story-Punkte werden verwendet, um zu berechnen, wie viele User-Storys ein Team in einer Iteration aufnehmen kann.

Was ist der Vorteil der Einführung eines abstrakten Konzepts (Story Points), bei dem wir nur eine konkrete Messung wie geschätzte Manntage verwenden können? Wir können auch die Geschwindigkeit berechnen, die Abdeckung einer Iteration usw. anhand der geschätzten Manntage schätzen.

Im Gegensatz dazu sind Story Points schwieriger zu verwenden (da das Konzept abstrakt ist) und den Stakeholdern auch schwerer zu erklären. Welchen Vorteil bietet es?

141
Louis Rhys

Ich denke, einer der Hauptvorteile ist, dass Menschen und Entwickler die Zeit ziemlich schlecht einschätzen können. Denken Sie auch an die Art der Entwicklung - es ist kein linearer Verlauf von Anfang bis Ende. Es ist oft "Schreiben Sie 90% des Codes in 10 Minuten und reißen Sie sich dann 17 Stunden lang die Haare aus dem Debugging." Das ist im Sinne der Taktung ziemlich schwer abzuschätzen.

Die Verwendung einer Abstraktion nimmt jedoch den Fokus von der tatsächlichen Zeit in Stunden oder Tagen und konzentriert sich stattdessen auf die Beschreibung der relativen Kosten und der Komplexität einer Aufgabe im Vergleich zu anderen Aufgaben. Menschen/Entwickler sind darin besser. Und sobald Sie mit diesen Punktschätzungen und einigen tatsächlichen Fortschritten summt haben, können Sie beginnen, die Zeit empirischer zu betrachten.

Ich vermute, dass es auch einen Beobachter-Effekt gibt, der bei Zeitschätzungen auftritt, der bei Punktschätzungen nicht auftreten würde. Zum Beispiel wird der Anreiz, eine Schätzung zu sanden und weit "vorzeitig" zu liefern, durch Indirektion in einem punktbasierten System gedämpft.

130
Erik Dietrich

Wenn Sie Fibonacci-Zahlen (oder ähnliches) verwenden, wird die Anzahl der Optionen beim Schätzen einer Story begrenzt. Ich habe mit einer Gruppe gearbeitet, die nur niedrige Zahlen verwendete: 1, 2, 3, 5, 8 und 13. Wir hatten eine Referenzgeschichte, die 5 war. Dies ermöglichte es uns, bei Planning Poker auf einfache Weise schnelle Entscheidungen über die Komplexität einer Geschichte zu treffen . Der andere Nebeneffekt war, dass alles, was mit 13 bewertet wurde, wahrscheinlich nicht genügend Informationen hatte und weiter aufgeschlüsselt werden musste. Ich bezweifle ernsthaft, dass es so einfach und unkompliziert gewesen wäre, wenn wir rohe Stunden verwendet hätten.

Ihr Product Owner spricht die Sprache Ihrer Stakeholder und sollte in der Lage sein, bei Bedarf zwischen Story Points und Arbeitsstunden (oder anderen Einheiten) zu übersetzen. Während meiner Zeit als PO hatte ich einige harte Daten, dass 1 Story Point = 4 Mannstunden, aber offensichtlich ist jedes Team anders.

Edit :

Mit dem Wissen, dass 1 Punkt = 4 Stunden ist, könnten Sie Ihr Planning Poker-Deck theoretisch auf 4, 8, 12, 20, 32 und 52 ändern. Es ist jedoch schwieriger, mit diesen Zahlen umzugehen. Ich denke, ich würde die Werte mental auf etwas Einfaches abstrahieren, z. B. "weniger als ein Tag", "mehr als eine Woche" usw. Und wenn ich das tun würde, könnte ich genauso gut bei der abstrakten Einheit bleiben -lose Story-Punkte.

60

Damit soll die Schätzung mit der Zeit besser werden, ohne dass die Schätzer ihre Schätzung anpassen müssen.

Anstatt dass alle an der Schätzung Beteiligten denken müssen: "OK ... sieht aus wie 2 Manntage ... aber beim letzten Sprint haben wir alles unterschätzt, also sind es vielleicht wirklich 2,5 Manntage. Oder 3?", Machen sie weiter wie immer. "5 Story Points!"

Anschließend passen Sie Ihre Schätzung an, wie viele Story-Punkte das Team in einem Sprint erreichen kann, basierend auf der tatsächlich gemessenen Leistung in früheren Sprints. "Wir haben zuvor 90-110 Story Points pro Sprint gemacht!"

Ich würde sagen, die Theorie dahinter ist, dass Entwickler relativ Komplexität verschiedener Entwicklungsaufgaben besser einschätzen können als absolut. Insbesondere, wenn mehrere Personen eine Aufgabe schätzen, die von einem von ihnen erledigt werden könnte (und nicht jeder mit der gleichen Geschwindigkeit arbeitet wie alle anderen).

Zynische Alternative : Ich habe gesehen, dass Entwickler niemals unter Zeitschätzungen geraten. Wenn etwas länger dauert als geschätzt, sind Sie durchgegangen. Aber wenn etwas weniger Zeit in Anspruch nimmt als geschätzt, können Entwickler damit herumspielen, vergolden oder einfach langsamer werden und es ruhig angehen lassen, da sie einen bequemen Auftrag erhalten haben. Das Herausnehmen der realen Zeiteinheiten aus einer Schätzung kann diese Tendenzen eindämmen. Zynische Alternative beenden.

25
Carson63000

Manntage oder Mannstunden sind, wie Sie sagen, konkret. Wenn eine Aufgabe auf 5 Stunden geschätzt wird und 6 Stunden dauert, ist sie jetzt eine späte Aufgabe.

Wenn Sie eine Geschichte haben, die 3 Punkte hat und 6 Stunden dauert, hat es 6 Stunden gedauert, es ist nicht spät, es hat nur sechs Stunden gedauert. Die Geschwindigkeitsmessung ist eher ein Faktor dafür, wie viele dieser Punkte Sie in einem Sprint erzielen, und diese Zahl kann schwanken, da sie nicht konkret ist. Sie messen auch nicht jede Aufgabe, sondern die Summe aller Aufgaben. Wenn Sie Stunden für jede Aufgabe haben, besteht die Versuchung, jede Aufgabe zu messen. In diesem Fall erhält der Sprint keinen Vorteil, wenn er unter der Zeit beendet wird, und dies ist eine Konsequenz für das Beenden über die Zeit einer bestimmten Aufgabe.

Es kann ein Übergang zum punktuellen Denken sein. Ein Ort, an dem ich gearbeitet habe, bevor wir überhaupt agile gebrauchte T-Shirt-Größen eingeführt haben, um eine Vorstellung vom Aufwand zu bekommen. Punkte sind nur eine Erweiterung davon.

Das heißt nicht, dass es keine Kontroversen oder eine willkürliche Zuordnung zu den Punkten gibt. Wir haben Mitglieder unseres Teams, die fast immer die niedrigste Zahl wählen und sich beschweren, wenn sie denken, dass eine Aufgabe eine 1 ist und wir denken, dass es eine 3 ist, unter der wir unter Punktinflation leiden.

18
Bill Leeper

Die Abstraktion ist eine Art Punkt. Die Verwendung des "Man Day" als Maß hat eine Reihe von Fallstricken, darunter:

  1. Wenn das Team nicht mit der Technologie vertraut ist, die es verwenden wird, kann es sehr schwierig sein, in Echtzeit Schätzungen darüber abzugeben, wie lange eine Aufgabe dauern könnte. Es ist viel wahrscheinlicher, dass sie gute relative Schätzungen abgeben können - z. "Aufgabe A wird wahrscheinlich doppelt so lange dauern wie Aufgabe B".
  2. Unterschiedliche Menschen arbeiten unterschiedlich schnell! Wenn Sie "Manntage" verwenden, müssen Sie die Zeitschätzung so ziemlich ändern, wenn eine Aufgabe von einem Entwickler an einen anderen übergeben wird. Wer definiert, wie viel Arbeit überhaupt einen „Männertag“ ausmacht?

Wenn Sie Manntage schätzen möchten, ist dies eine einfache Berechnung:

user points in story / average user points per developer per day = estimated man days
14
vaughandroid

Wie bereits erwähnt, sind Story Points ein relatives Maß für die Komplexität. Man kann die Potenz von 2 Reihen (1,2,4,8,16 ...) oder eine Fibonacci-Skala (1,2,3,5,8,13,20 ...) zur Schätzung verwenden. Als unterstützte Entwickler sind sie ziemlich geschickt darin, so etwas zu sagen:

Merkmal A ist fast doppelt so schwer wie Merkmal B.

Es ist jedoch sehr schwierig zu sagen, wie lange diese Funktion für die Implementierung benötigt. Sie lassen das durch Geschwindigkeit ausgleichen. Wenn also etwas als 5 geschätzt wurde, sich aber als 13 herausstellte, würde eine langsamere Geschwindigkeit das für die Iteration normalisieren (oder Sie könnten es neu schätzen).

Nun gibt es eine andere Alternative, die als "ideale Tage" bezeichnet wird (einige ähneln den Manntagen, aber ich bin mir nicht sicher, ob Sie das gemeint haben), und ich kenne einige Teams, die das bevorzugen. Ideale Tage sind zu interpretieren als:

Wenn das alles ist, was ich mache, nachdem ich ins Büro gekommen bin und nur die notwendigen Pausen eingelegt habe, keine Unterbrechungen habe und alles habe, was ich brauche, um die Geschichte umzusetzen, d. H. Keine peripheren Aktivitäten wie Besprechungen, Antworten auf E-Mails usw.

Mike Cohn, einer der vielen bekannten agilen Evangelisten, bietet den folgenden Vergleich zwischen Story Points und idealen Tagen

Story Points

  • Hilft dabei, funktionsübergreifendes Verhalten zu fördern, d. H. Teams schätzen Geschichten w.r.t. Gesamtkomplexität der Implementierung von der Benutzeroberfläche bis zur Datenbank und zurück.
  • SP-Schätzungen verfallen nicht, d. H. In einigen Monaten beträgt eine 5-Punkte-Story wahrscheinlich immer noch 5 Punkte, aber eine ideale Tagesschätzung kann sich abhängig von den erworbenen Entwicklungsfähigkeiten/-geschwindigkeiten des jeweiligen Programmierers ändern
  • SP sind ein reines Maß für die Größe, d. H. Sie spiegeln nur die Größe w.r.t. Komplexität. Zeitraum. Keine Dauer etc., warf es. Das ist die Aufgabe der Geschwindigkeit. Nicht so bei idealen Tagen. Tatsächlich besteht bei idealen Tagen die Tendenz, es mit Kalendertagen zu verwechseln. Wenn Sie es abstrakt halten, während SPs die Versuchung bekämpfen, sich mit der Realität zu vergleichen. Nur ein Maß für die Größe. Kein Unsinn.
  • Ist in der Regel schneller als ideale Tage. Es mag für die ersten paar Geschichten schwierig sein, aber sobald Sie den Dreh raus haben, ist es schneller.
  • Verschiedene Entwickler können ihre ideale Tagesschätzung für die Fertigstellung einer Story unterschiedlich festlegen. Ich könnte das gleiche in 3 tun und Sie könnten in 5. SPs sind auf der ganzen Linie mehr oder weniger einheitlich. Sie gleichen sozusagen das Spielfeld aus.

Ideale Tage

  • Einfacher außerhalb des Teams zu erklären; aus offensichtlichen Gründen :)
  • Zunächst einfacher zu schätzen, wie oben erwähnt. Aber sobald Sie den Dreh raus haben, ist es ganz natürlich

Nun liegt es am Team, welche zu wählen ist. Da die meisten Antworten hier und meine persönlichen Erfahrungen vorliegen, bevorzuge ich jedoch Story Points. Ideale Tage haben gegenüber SPs nicht wirklich einen großen Vorteil (und Mike Cohn befürwortet auch SP zusammen mit vielen anderen agilen Evangelisten).

7
PhD

Story Points helfen Ihnen auch dabei, die Leistungsverbesserung des Teams im Laufe der Zeit zu messen. Darüber hinaus müssen Sie nicht alles neu schätzen, wenn sich die Leistung verbessert.

Nehmen Sie dieses Beispiel, das Manntage verwendet :

Das Team schätzt verschiedene Aufgaben mit Manntagen. Es funktioniert eine Weile, aber nach einiger Zeit sieht man, dass das Team mit vielen Aufgaben schneller fertig ist als ursprünglich angenommen. Also das Team schätzt ne die Aufgaben. Es funktioniert für eine Weile und nach einiger Zeit sehen Sie wieder dasselbe: Das Team ist mit vielen Aufgaben wieder schneller erledigt. Also Sie neu schätzen wieder, und diese Geschichte wiederholt sich immer wieder und immer wieder ...

Warum? Weil die Leistung Ihres Teams gestiegen ist. Aber du weißt nichts davon.

Das gleiche Beispiel mit Story Points :

Das Team schätzt die Größe der User Stories. Nach einigen Sprints sehen Sie, dass das Team ungefähr 60 Story-Punkte pro Sprint erzielen kann. Später sehen Sie, dass das Team mehr als 60 Story-Punkte erreicht hat, vielleicht 70. Und das Team fährt so fort und zieht mehr User-Storys für die nächsten Sprints und liefert sie aus.

Warum? Weil die Leistung gestiegen ist. nd Sie können es messen. Und Sie müssen nicht alles neu schätzen, nachdem die Leistung Ihres Teams gestiegen ist.

4
Uooo

Erstens sind Menschen bei relativen Schätzungen besser als bei absoluten Schätzungen. Die Babylonier, die die relative Helligkeit von Sternen abbilden und bewerten, sind ein gutes Beispiel. Sie haben die absoluten Zahlen nicht richtig verstanden, aber die Reihenfolge war selbst bei sehr ähnlichen Intensitäten meistens genau richtig.

Der zweite Vorteil ist, dass ein Hauptgrund für diese Übung darin besteht, die Konversation zu fördern. Wenn Sie in genauen Tagen mit der Diskussion beginnen, kann die Konversation schnell zum Erliegen kommen.

Wie Napoleon sagte: Der Plan ist wertlos, Planung ist von unschätzbarem Wert.

Drittens muss der Projektmanager nicht alle Schätzungen bearbeiten, nur weil sich herausstellt, dass die Schätzungen um einen Faktor von z. B. 130% abweichen.

3
Tormod

Manntage Schätzen Sie die Zeit, die benötigt wird, um etwas zu tun. Sie werden am besten verwendet, wenn die von Ihnen geschätzten Elemente sehr genau und messbar sind. Spezifische, bekannte, wiederholbare Aufgaben können in Manntagen geschätzt werden.

Wenn ein Verkäufer beispielsweise durchschnittlich 20 Kundenanrufe pro Tag tätigen kann, können wir berechnen, wie viel Zeit jeder Anruf benötigt, und daraus abschätzen, wie viele Manntage für 1000 Anrufe erforderlich sind.

In diesem Beispiel kann man konkret statistisch über die mittlere Länge eines Anrufs nachdenken, da davon ausgegangen werden kann, dass alle Anrufe tatsächlich dasselbe sind.

Story-Punkte Bestimmen Sie, welche Kombination von Storys in einer Iteration ausgeführt werden kann. Sie werden verwendet, um heterogene Ziele mit unscharfen Grenzen zu kombinieren und um zu messen, wie viele Ziele in einem festgelegten Zeitrahmen erreicht werden können. Sie schätzen die Komplexität von Arbeitsblöcken im Vergleich zueinander , um sie addieren zu können.

Zum Beispiel hat Ihr Team 5 Geschichten für insgesamt 23 Punkte in Iteration 1 und 8 Geschichten für 20 Punkte in Iteration 2 entwickelt. Daraus können Sie abschätzen, dass Ihr Team in Iteration 2 einige Geschichten mit insgesamt 20 Punkten erstellt in Iteration 3.

Beachten Sie, dass wir nicht die Größe eines Punktes bestimmen müssen und insbesondere nicht davon ausgegangen werden kann, dass die Entwicklung jeder Geschichte derselben Größe dieselbe Zeit in Anspruch nimmt! Wir arbeiten nur an Summen und Punkten pro Iteration. Ich habe nicht einmal erwähnt, wie lange die Iteration dauert.

0
Sklivvz

Ich bin überrascht, dass noch niemand Parkinson-Gesetz erwähnt hat.

Die Arbeit wird erweitert, um die für ihre Fertigstellung verfügbare Zeit zu füllen.

Wenn Sie für große Aufgaben in einer beliebigen Zeiteinheit schätzen, nehmen sich Entwickler in der Regel die Zeit, die sie für die Fertigstellung oder das Durchgehen veranschlagt haben. Wenn Sie in einer nebulösen Zeit wie Story Points oder Shirt Sizes schätzen, vermeiden Sie diese Gefahr.

0
Vadim

Story Points spiegeln die Komplexität des Problems wider und spiegeln daher das Vertrauen (oder Risiko) in die Genauigkeit der Schätzung wider.

Eine Story mit einem hohen Story-Punkt sagt mir, dass mit der User Story viel los ist, was nicht konkret ist.

Die Idee ist zu sehen, was eine gute Balance zwischen verschiedenen Story-Punkten ist. Wenn mir ein Iterationsplan mit Storys mit allen hohen Story-Punkten angezeigt wird, gibt mir dies wenig Sicherheit, dass die Iteration wie erwartet ausgeführt wird und dass wir uns andere Storys für die Iteration ansehen oder anfangen müssen, Storys aufzuschlüsseln.

Bei der Kommunikation mit einem Manager oder Product Owner bedeuten hohe Story-Punkte, dass es äußerst unklar ist, wann sie eine bestimmte Funktion erhalten. Eine der Lösungen hierfür besteht darin, die Story aufzuschlüsseln. Hoffentlich können Sie mit einer Kombination aus niedrigen und hohen Story-Punkten arbeiten, damit Sie dem Product Owner iterativ den Fortschritt demonstrieren können.

0
grumpasaurus

Wenn Sie auf der Straße zu einem Menschen gehen und fragen: "Wie groß war ein T-Rex?" Die Antworten würden schwanken, obwohl die Mehrheit der Menschen weiß, was ein T-Rex ist, wie groß er war, aber niemand weiß es wirklich genau - weil wir KEINE relative Skala zur Basislinie haben.

Das ist das kognitive Verhalten, das Sie mit Prognosen herausfinden möchten, und viele Methoden drehen Zyklen mit " Ich habe es! .. Ich habe das Geheimnis einer genauen Prognose! "Schlangenöl zu den Massen. Wenn Sie tatsächlich eine Vorhersage machen, sagen Sie tatsächlich laut " Ich werde x Tage/Stunden/Punkte ERLAUBEN, damit dies abgeschlossen wird " - es ist in gewissem Sinne Erstellen einer "Zeitbox" für dieses Ereignis, das innerhalb ausgeführt werden soll.

Für mich verschiebt Points am Ende des Tages nur die Grenzen, es sei denn, Sie gehören zu einem Team, das gerne sagt: "* Nun, wir haben 3 Wochen pro Sprint und Daumen saugen ... ich denke, wir sollten 30 Punkte schießen, um in diesem Zyklus abzuschließen! Wer ist bei mir! * "und das ist so tief wie Sie in der Prognosemodellierung gehen - gut! ..als realistisch setzen Sie nur ein willkürliches Budget und das war's. Sie sehen sich dann auch im Nachhinein die Arbeit an, die mit dem Gefühl abgeschlossen wurde, "Heiliger Mist, wir haben 33 Punkte im Sprint gemacht, das war ziemlich cool", und dagegen kann nicht viel getan werden. Sie können die Geschwindigkeit verwenden, um zu bestimmen, dass Sie während des Sprints für Ihr Budget Geld verdienen, indem Sie laut fragen: " Haben wir schon 15 Punkte erreicht? Werden wir", aber dann kehren Sie zurück, um die relative Zeit hinzuzufügen zur Gleichung, nicht wahr? ", aber die Gefahr hier ist, dass Sie jetzt Velocity verwenden, um die Produktivität und nicht die Kapazität zu messen, was meines Wissens das Reactive Release Management (Story Points) in den Kopf tritt ..

Das Punktesystem ist fast zu clever, um nicht zu bemerken, dass Sie der Gleichung immer noch relative Zeit hinzufügen, von Ihren vereinbarten "Sprintzyklen" bis zu Ihren täglichen Stand-ups, in denen Sie eine versteckte Regel bezüglich Dauer + Komplexität festlegen = " Max braucht zu lange mit dieser Aufgabe "angeborener Bauchgefühl Teamcode roter Moment?

Das menschliche Gehirn kann keine Prognose abgeben, da es viel Arbeitsgedächtnis mit langem/kurzfristigem Rückruf vermischt. Es ist also so, als würde man einen unerfahrenen Mathematikstudenten bitten, Bruchteile in seinem Kopf zu machen, nicht auf Papier. Deshalb einigen sich andere Branchen nie auf eine Prognose und Überprüfen Sie die Prognosen ständig in relativer Zeit (z. B. hört der Geologe die Prognosemodellierung erst auf, wenn dieser Kubikmeter aus dem Boden gegraben und dann "erledigt" wurde).

Ich würde sagen, das Punktesystem funktioniert, wenn Sie prognostizieren nicht. Sie stimmen einem Teil der Arbeit zu, der auf einem Sub-Chunking-Algorithmus basiert, aber das ist wirklich Ihr engster Ansatz für die Prognose. Tatsächlich würde Ihr Release-Management nach natürlichen Unterbrechungen in der "Backlog" -Warteschlange suchen, die zu Themen passen (dh in Silverlight würden wir Produktmanager warten, bis sie ihren Rückstand abgeschlossen haben und die von uns ursprünglich festgelegten Themen zusammenfügen. Wir Ich wusste nie, was das Engineering-Team speziell tat. Wir hatten nur einen Grundriss. Wir nahmen dann diese Arbeit und bauten unser Marketing-Event darauf auf (Microsoft Mix).

Wenn Sie anfangen, Geschwindigkeitserwartungen innerhalb von Sprintzyklen zu sperren, die von Geschwindigkeit + Zeit abhängen, kehren Sie wieder zu Prognoseschätzungen zurück, nur diesmal sind Sie schlechter dran, weil Sie das "es hängt vom Spiel ab" spielen ... Noch wichtiger Sie Wir töten auch das Potenzial für Teamwachstum/Karrierewachstum.

Die Steuer, die Sie für Punkte gegen Zeit zahlen, bezieht sich auf Punkte, die Sie benötigen, um nach alternativen Messformeln zu suchen, um die Entwicklung/Betreuung von Onjob-Fähigkeiten oder das Verhalten von Entwicklern zu verfolgen.

Da Sie immer noch einen "Median-Entwickler" als Ihre ideale Person betrachten müssen, mit der Sie Fähigkeiten/Anstrengungen verbinden können, können Sie dann andere Entwickler mit dieser Person in Verbindung bringen, um zu bestimmen, wie sie sich in ihrem kontinuierlichen Wachstum in Ihrem Team verhalten. Es werden auch Situationen hervorgehoben, in denen die "schnellen" Entwickler den größten Teil des Wassers tragen, sich aber langweilen oder schlimmer noch, sie arbeiten länger und ohne Anerkennung/Belohnung aufgrund konkurrierender Fristen usw. Stand-ups entdecken dies in Wirklichkeit nicht, sie sind es wirklich dort, um schlechte Gerüche innerhalb des Teams per say zu erkennen, wie in "diese Person kämpft, lassen Sie uns helfen"

Als nächstes kommen auch die "Carry-Over" -Geschichten, Geschichten, die nicht in diesen Sprintzyklus eingeteilt werden, sondern dann in den nächsten Sprintzyklus übergehen. Was dann leicht einen Anstoßeffekt erzeugen kann, wenn Sie die Zeit berücksichtigen, aber in dem Moment, in dem Sie die relative Zeit berücksichtigen, sind Sie einfach auf "zeitbasierte Prognose/Schätzung" zurückgegangen, und wieder ist das Punktesystem gerecht das Wasser trüben.

Wenn Sie Punkte sammeln, ignorieren Sie die Zeit vollständig und ich meine vollständig, sobald Sie die Zeit einschleichen lassen, spielen Sie die Idee/Methodik.

Nachdem ich als Evangelist um die Welt gereist war, sah ich viele Teams, die ihre Hand auf alles schworen, was ihnen am Herzen liegt, dass sie den Agile Forecast-Code geknackt haben ... aber ich klickte immer mit der Zunge, lächelte und ging mit dem Gedanken weg "- ja ... du hast es fast getan, aber diese Geliebte, die wir 'Zeit' nennen ... sie ist einfach grausam ... "

0
Scott Barnes