Wie viele Details zu einer User Story kann ein Entwickler erwarten?

Der größte Nachteil der agilen Entwicklung, den ich erlebt habe, ist, dass sich Leute, die nicht an der Entwicklung beteiligt sind, auf das Mantra konzentrieren, dass eine User Story (3-10 ideale Personentage) nicht mehr als 1-3 Sätze enthalten sollte, wie:

Als Kunde kann ich die Freitextsuche verwenden, um die gewünschten Produkte zu finden.

Nach diesem Satz erwarten die Projektmanager von mir als Entwickler, dass ich mich auf eine Schätzung einlasse und die Geschichte entwickle. Sie gehen davon aus, dass eine agile Entwicklung bedeutet, dass solche Sätze für Entwickler alles sind, was sie zu bieten haben.

Ich werde ihnen keine Vorwürfe machen, da die bekannte Literatur über agile Entwicklung den Eindruck erweckt, dass dies tatsächlich funktionieren würde. Ich habe in "Planning XP" 2 Seiten in natürlicher Sprache pro Geschichte gelesen, aber das war's. Da "funktionierende Software" der "umfassenden Dokumentation" vorgezogen wird, scheint dieses Thema generell vermieden zu werden.

Die Realität ist natürlich, dass, wenn der Entwickler die Möglichkeit dazu hat, ein Interview mit dem Kunden eine lange Liste von Anforderungen aufwirft, die der Kunde an die Story hat:

• Wir brauchen boolesche Operatoren wie AND und OR.
• Wir brauchen eine Fuzzy-Suche und alle Begriffe.
• Wir müssen sowohl nach einzelnen Wörtern als auch nach Phrasen suchen.
• Wir möchten keine Produkte finden, die die Kriterien X, Y und Z erfüllen.
• Wir wollen das Ergebnis sortieren. Übrigens kann der Benutzer die Sortierkriterien in einem Kombinationsfeld mit den Optionen a, b und c auswählen.

Sie sehen also, dass ich nicht über technische Details oder Software-Design oder gar Implementierungsdetails spreche. Es sind reine Anforderungen. Je länger wir reden, desto mehr merkt der Kunde, dass es tatsächlich eine Menge zu sagen gibt, was er will.

Aber oft genug finde ich mich in der Situation wieder, dass solche Informationen nicht oder nur sehr mangelhaft zur Verfügung gestellt werden. Es ist weder möglich, dass ich das Interview mache, noch gibt mir die Person, die in der Lage wäre, das Interview zu führen, ein Ergebnis davon.

Manchmal kommen Manager sogar auf technische Details wie "Wir wollen Lucene-Suche", aber sie möchten nicht darüber nachdenken, ob sie nur Produktnamen oder auch Produktbeschreibungen finden möchten. Manchmal denke ich, dass sie nur faul sind;)

Für mich ist dies das Hauptproblem in Projekten, in denen ich arbeite (E-Business-Webanwendung, 500-2000 Personentage pro Projekt). Ich habe dieses Problem oft genug angesprochen und Manager sind sich bewusst, dass die meisten Entwickler ein Problem mit der Situation haben. Aber sie glauben, dass Entwickler einfach zu viel "Perfektionisten" sind. Sie scheinen sich zu ärgern, dass Entwickler "immer alles spezifizieren wollen".

Aufgrund des Mangels an allgemein anerkannten Zahlen ist es schwer zu streiten. Jeder weiß, wie lange eine Iteration dauern sollte. Aber niemand kann sagen, wie viele Anforderungen erforderlich sind, um eine Geschichte abzuschätzen und zu entwickeln.

Haben Sie eine Referenz?

Sie vermissen den Punkt der Agilität ein wenig. Was Sie als User Story bezeichnen, sehe ich als mindestens sechs: eine Bare-Bones-Suche und eine für jeden Ihrer Aufzählungspunkte. Machen Sie auf jeden Fall genügend Pläne, um nicht in eine Ecke zu malen, deren Rauskommen teuer wird, aber die ganze Idee ist, dass Sie das Minimum bereitstellen, das erforderlich ist, um einen Wert zu liefern, und dies schnell genug, um schnelles Feedback zu erhalten.

Wenn Sie eine Geschichte wie diese aufteilen, wird die Schätzung dadurch nicht nur einfacher, sondern der Product Owner kann feiner Prioritäten setzen. Sicherlich mögen sie die Möglichkeit, die Suchergebnisse zu sortieren, aber vielleicht ist es nicht so wichtig wie ein anderes Element im Backlog, das absolut nichts mit der Suche zu tun hat.

Versuchen Sie, die Idee, dass Programmierer alles Spezifizierte benötigen, aus Sicht des Kunden zu betrachten. Oft ist es so, als würden Sie ein Auto kaufen, und der Verkäufer fragt, welche Farbe Sie für den Scheibenwischerknopf wünschen. Viele Details, die wir für wichtig halten, sind aus Kundensicht völlig irrelevant. Ich habe dort gearbeitet, wo die Anforderungen zu hoch sind, und vertraue mir, es macht keinen großen Spaß. Die Art von Spielraum, über den Sie sich beschweren, würden viele Programmierer gerne haben.

Klingt wie das erste Problem ist, dass Sie keine Zeitschätzungen auf User Stories anwenden sollen. Sie sollten eine Geschichte aufnehmen und "Geschichtenpunkte" anwenden, die eine allgemeine Schätzung der Komplexität von 1 bis INFINITY darstellen. Story Points werden oft wie folgt geschrieben: 1,2,3,5,8,13,20 ... (Jede Organisation hat ihre eigenen Regeln.) Sie wenden im Allgemeinen Folgendes an:

1 - Sie können es im Schlaf tun und es lohnt sich kaum zu implementieren. 2 - Sie verstehen das und können es schnell erledigen, ohne dass die Gefahr eines Überlaufs besteht. 3 - Sie verstehen das, aber es könnte eine oder zwei Überraschungen geben. 5 - Dies ist ein wenig recherchiert und birgt ein geringes Risiko. 8 - Dies ist eine große Aufgabe, die viel Forschung erfordert und möglicherweise nicht in einen Sprint passt. 13 - Das ist riesig und passt definitiv nicht in einen Sprint. Es gibt ein massives Risiko. etc.

Im Allgemeinen muss jede User Story, die eine 8 oder höher ist, in kleinere Storys unterteilt werden.

Wenn Sie nicht über die erforderlichen Informationen verfügen, sollten Sie diese unbedingt an den Projektmanager zurückgeben und angeben, dass Sie weitere Informationen benötigen.

Sie sollten die Zeit wirklich erst abschätzen, wenn Sie die Geschichte in den Sprint aufgenommen haben, aber selbst dann wird darauf weniger Wert gelegt. Die Idee ist, dass Sie, sobald sich Ihr Team an den Zeigevorgang gewöhnt hat, die grobe Leistung pro Sprint in Story-Punkten messen und auf diese Weise planen können. Sie möchten keine kürzere Zeit als den Sprint einplanen. Die Idee dabei ist, dass, wenn Sie die Aufgaben richtig aufteilen, sodass die mehreren Storys in einen Sprint passen und sich im Bereich von 1 bis 5 Story Points befinden, dies bedeutet, dass sie gut genug definiert sind.

Es hört sich auch so an, als ob die PMs in Ihrem Unternehmen nicht verstehen, was eine "Geschichte" ist. Ein kritischer Teil einer "User Story" sind die Exit-Kriterien. Das Beendigungskriterium ist ein oder zwei kurze Sätze, die eindeutig beschreiben, wie gezeigt werden kann, dass diese Speicherung abgeschlossen ist. Im Idealfall haben Ihre QA-Mitarbeiter gesagt: "Ja, das können wir testen." Das Wichtige ist, dass die PMs verstehen müssen, dass eine User Story vollständig ist, wenn die Software die "Exit-Kriterien" erfüllt. "Aber das wollten wir nicht" macht es nicht. Wenn sie nicht wollten, was geliefert wurde, aber es den Austrittskriterien entsprach, müssen sie eine neue Geschichte eingeben.

Hier gibt es sicherlich ein Element des "Trainings der PMs". Sie müssen lernen, dass vage Geschichten zu großen Handlungspunkten führen und dass sie es erneut tun müssen, wenn sie die Geschichte zweideutig definieren, um das zu bekommen, was sie wollen.

Wenn die Stakeholder nicht genügend Informationen sammeln, müssen Sie natürlich viel mehr arbeiten, oder? Lange vor meinen beweglichen Tagen hatte ich Erfolg, indem ich sehr große Schätzungen gab und ausdrücklich sagte, dass die Schätzungen so groß waren, dass das durch den Mangel an Informationen verursachte Risiko berücksichtigt wurde. Ich musste für alle Fragen den schlechtesten Fall annehmen und schätzte auf der Grundlage dieses schlechtesten Falls. Ich stellte fest, dass die Manager eher bereit waren, weitere Details anzugeben, als sie sahen, dass die Schätzungen sanken.

Dies ist kein Spiel für das System ... dies ist absolut gültig. Wenn Sie nicht wissen, ob es "A" oder "B" ist, schätzen Sie basierend darauf, welche die größte Schätzung gibt, um Ihren Arsch zu bedecken.

Nach meinen Erfahrungen befassen sich viele der Änderungen oder Projekte, an denen ich arbeite, mit genau dieser Sache. Custom X möchte etwas und sie haben eine Vorstellung davon, was sie wollen, aber sie geben Ihnen nur eine kleine E-Mail mit den Anforderungen. Das liegt hauptsächlich daran, dass der Kunde nicht genau weiß, was er will. Das ist der Grund, warum die meisten Aufgaben unserer Kundendienstabteilung darin bestehen, diese Kundenanforderungen zu konkretisieren und die benötigten Informationen zu filtern und gleichzeitig vorherzusagen, was der Kunde WIRKLICH möchte oder was er wirklich braucht.

Angenommen, ein Kunde (für mich) möchte, dass ein Abschnitt unserer Webanwendung ihm eine Liste aller Telefonnummern zurückgibt. Sie geben niemals an, ob es sich um physische, logische oder solche handelt, die einer Person oder einem Ort zugeordnet sind. Sie wollen einfach alle Telefonnummern. Als Entwickler kann ich da sitzen und mir ein Dutzend oder mehr Fragen überlegen, die ich dem Kunden stellen müsste, ähnlich wie Sie. Aber wie Sie sagen, das ist nicht möglich. Deshalb ist eine gute Kundendienstabteilung, die das Produkt und den Kunden kennt, von unschätzbarem Wert.

Wenn diese Art von Anruf bei unseren Kundenvertretern eingeht, können diese diese mit dem Kunden besprechen und wissen, was sie für die Beantwortung der richtigen Fragen benötigen. Sie haben auch die Voraussicht zu wissen, wonach der Kunde in der Vergangenheit gefragt hat, und sie wissen genug über die Systeme, die wir entwickeln, dass sie zu etwas Ja oder Nein sagen können, ohne den Kunden zu fragen.

Sicher, es gibt viele Fälle, in denen der Kunde noch etwas anderes benötigt, das sowohl Sie als auch der Kundenservice vermisst haben, aber das wird immer passieren. Ihr Ziel und das Ziel des Kundenservices sollte es sein, die Zeitverzögerung zwischen der Entwicklung und der Rückgabe von Änderungen durch den Kunden zu minimieren. Und das hängt nur von der Kommunikation und Schulung mit Ihren Kunden ab.

Vielleicht ist es für Sie nicht so machbar wie für mich, aber eine gute Kommunikation und ein vertrauensvolles Verhältnis zu Ihren Kundenvertretern helfen Ihnen fast immer nach und nach, und es verringert Ihre Frustration und erhöht die Zufriedenheit des Kunden. Sie können auch einfacher einen Zeitrahmen für Ihre Projekte festlegen, anstatt mit den Schultern zu zucken und zu sagen: "Ich kenne den gesamten Umfang des Projekts nicht, also weiß ich nicht, wie lange es dauern wird." Wir haben hier das gleiche Problem, und bessere Kommunikation und Schulung helfen uns, vernünftige Fristen zu schaffen und diese konsequent einzuhalten.

Kunde

Ich möchte Produkte suchen

Produktmanager Ich habe die Kundengeschichte analysiert und folgende Anforderungen gestellt. Jede Anforderung wurde als separate User Story aufgezeichnet.

• Suchen Sie nach Produkten
• Ergebnis sortieren
• Suchergebnisse filtern

Entwickler Ich habe User Stories von einem Produktmanager erhalten. Ich habe jede User Story analysiert und eine Liste mit Aufgaben für jede User Story erstellt.

• Suchen Sie nach Produkten
  1. Aufgabe 1: Datenbankänderungen
  2. Aufgabe 2: Serverseitige Änderungen
  3. Schritt 3: Änderungen am Frontend

Kunde, Produktmanager und Entwickler sind an diesem Prozess beteiligt. Sie alle müssen zum Analyseprozess beitragen, bevor die Arbeit beginnen kann. Bitte beachten Sie, dass dies ein sehr vereinfachtes Beispiel ist.

Unsere User Stories werden in der folgenden Reihenfolge analysiert und verfeinert (mit einigen Variationen natürlich):

Helpdesk -> Product Owner -> Product Manager -> Abteilungsleiter (leitende Entwickler, QA-Leads usw.) -> Entwickler

Sobald alle relevanten Stakeholder zum Analyseprozess beigetragen haben, können wir abschätzen, wie lange wir brauchen, um die Story zu liefern. Der von uns verfolgte Schätzungsprozess basiert auf der Geschwindigkeit und dem Fachwissen der einzelnen Entwickler.

Ich sage nicht, dass dies eine korrekte Vorgehensweise ist, aber sie funktioniert wirklich gut in unserer Organisation.