User Stories sind zu hoch und konzeptionell. Das Management erwartet von den Entwicklern, dass sie die Lücken füllen

10

Ich bin in einem sehr brillanten Unternehmen beschäftigt, mit der wahren Absicht, XP zu machen. Die Kommunikation ist gut und das Management ist offen für konstruktive Diskussionen, aber aufgrund dringender Zeitbeschränkungen werden einige bestimmte Dinge als zu RUP angesehen, um diskutiert zu werden.

Im Moment bin ich ein wenig besorgt über das Ausmaß der Veränderungen, die bei der Umsetzung der Geschichten notwendig werden. Ich glaube, dass viele dieser Entdeckungen (die natürlich Zeit und Mühe kosten) in der Verantwortung der Storywriter (Kunden, Endbenutzer und Produktbesitzer) und nicht der Entwickler liegen. Kurz gesagt, User-Storys sind zu konzeptionell und vermitteln nur die zugrunde liegende Absicht, aber es fehlen genügend Details (insbesondere Vor- und Nachbedingungen, Relevanz für andere Storys, Abhängigkeiten und dergleichen). Es wird erwartet, dass der Entwickler die Lücken nach eigenem Ermessen ausfüllt, da XP-Entwickler gleichzeitig Designer und Analysten sind. Das Problem ist, dass viele dieser Leerzeichen entdeckt werden, nachdem einige falsche Annahmen in die Auswertungszeit und den Code eingedrungen sind, da festgestellt wird, dass zusätzliche Komplexitäten auftreten, als ursprünglich angenommen. Selbst dann braucht es Zeit, um das Richtige auszufüllen, was - in unterschiedlichem Maße - als Abweichung von den ursprünglichen Schätzungen angesehen wird.

Ich suche nach einer konstruktiven Möglichkeit, diese Implikationen dem Management so zu vermitteln, dass ich nicht als jemand auftreten kann, der versucht, die Dinge unnötig zu komplizieren. Ich bin neu und habe noch nicht viel Glaubwürdigkeit aufgebaut.

Ihre Erkenntnisse sind herzlich willkommen.

Eng verwandt und gibt irgendwie eine Antwort: Wie viele Details über eine User Story kann ein Entwickler erwarten?

Ashkan Kh. Nazary
quelle
4
Nun, ich bin kein XP-Experte, aber wenn das Team Annahmen trifft, dann machen sie XP falsch.
Songo
4
Wenn das Team falsche Annahmen trifft, die vermieden werden könnten, indem einfach mehr Fragen an die Endbenutzer gestellt werden, dann geht in der Methodik etwas sehr Falsches schief.
Doc Brown
Um die Lücken zu füllen, aber diese Annahmen und Risiken müssen Sie zu den Geschäftsleuten / Kunden mit einem Datum zurückkehren, bis zu dem Sie Antworten erwarten, damit Sie das Projekt auf Kurs halten können.
Tgkprog
4
Willkommen in der realen Welt der Softwareentwicklung. JEDE Softwareentwicklungsmethode funktioniert, wenn der gesamte Prozess befolgt wird, jeder engagiert ist und die Entwickler über ausreichende Fähigkeiten verfügen. Das Problem ist, dass selten alle auftreten. Was mich über all die Leute zum Lachen bringt, die sagen, dass du XP falsch machst. Wenn immer alles ideal wäre, brauchen Sie nicht nur kein XP, sondern wahrscheinlich auch keine Methodik. Die Stärke eines Prozesses liegt darin, wie gut er funktioniert, wenn er nicht einem T folgt. Wenn XP aufgrund von Abweichungen kaputt geht, gibt es ein Problem mit XP, nicht mit denjenigen, die versuchen, es zu üben.
Dunk
2
Wenn Sie nicht genügend detaillierte User Stories vom Kunden erhalten. Das wird erwartet. Bei den meisten Projekten, an denen ich arbeite, gibt es normalerweise mindestens zwei Ebenen von Geschichten. Das hohe Niveau (von dem die Systemanforderungen abgeleitet werden) und detailliertere Geschichten, die die Entwickler benötigen, erstellt von den Entwicklern. Diese detaillierten Geschichten helfen dabei, die fehlenden Anforderungen zu entdecken, die die hochrangigen Geschichten übersehen haben. Und normalerweise gibt es viel. Sie können dem Kunden dann spezifische Fragen stellen. In der Zwischenzeit raten Sie nach besten Kräften und hoffen, dass der Kunde rechtzeitig reagiert.
Dunk

Antworten:

26

Der Trick besteht nicht darin, Leerzeichen zu vermeiden. Der Trick besteht darin, diese Lücken so früh wie möglich im Entwicklungsprozess auszufüllen.

Sie haben Recht, dass Entwickler, wenn sie Annahmen treffen, ausnahmslos falsch liegen und die spätere Neuentwicklung der Software Zeit kostet. Aber auch, wenn von Geschäftsleuten erwartet wird, dass sie ein komplettes Vorab-Design erstellen, wenn sie nicht wirklich wissen, was sie wollen, wird dasselbe passieren.

Es ist ein großer Teil der Aufgabe eines Entwicklers, herauszufinden, was der Kunde will, wenn er es oft nicht wirklich weiß.

Stellen Sie zuerst Fragen. Wenn die Antworten unbefriedigend erscheinen, erstellen Sie einen Prototyp. Zeigen Sie dem Kunden, wonach er fragt, und lassen Sie sich von ihm sagen, dass es nicht das ist, was er wirklich will. Beginnen Sie mit einem Papierprototyp und wechseln Sie dann zu einem HTML-basierten Prototyp ohne Code. Führen Sie dann die kleinste Menge an Entwicklung durch, die Sie benötigen, um ein nahezu funktionsfähiges Produkt herzustellen, und zeigen Sie ihnen dies. Lassen Sie die kniffligen Teile so spät wie möglich im Prozess.

Dies mag an sich zeitaufwändig klingen, ist es aber im Vergleich zur Neuentwicklung eines vermeintlich fertigen Produkts nicht.

Halten Sie die Geschichten auch so klein wie möglich. Ausnahmslos will das Unternehmen ein Epos, das in viele Ergebnisse unterteilt werden kann. Das ist besser, weil Sie sich nicht zu sehr entwickelt haben, wenn sie sich den endgültigen Release-Kandidaten ansehen und schreien: "Oh nein, das ist wirklich nicht das, wonach wir gesucht haben."

pdr
quelle
Ich kann diese Antwort momentan nicht positiv bewerten (Limit erreicht), aber dies ist die beste von allen. Darüber hinaus werden die meisten Kunden Sie nach ein- oder zweimaliger Iteration dafür mögen.
KK.
In diese Richtung. Wenn es viele Leerzeichen gibt, ist die User Story wahrscheinlich zu hoch, um ohnehin nützlich zu sein, und sollte angezeigt werden, um in kleinere, leichter definierbare Storys unterteilt zu werden.
Seth M.
7

Selbst dann braucht es Zeit, um das Richtige auszufüllen, was - in unterschiedlichem Maße - als Abweichung von den ursprünglichen Schätzungen angesehen wird.

Das klingt für mich nicht sehr "XP".

Ich bin in keiner Weise ein XP-Experte, aber AFAIK die XP-Idee ist es, Ihre Spezifikationen und Ihre Schätzung kontinuierlich anzupassen, wenn Sie Feedback vom Prozess erhalten. Und der Prozess ist "ein wenig analysieren - ein wenig entwerfen - ein wenig Code - ein wenig testen - und dann Benutzerfeedback erhalten , um Ihre falschen Annahmen so früh wie möglich zu korrigieren. Sie können beispielsweise auch versuchen, Benutzerfeedback noch früher zu erhalten Nachdem Sie einige Teile Ihrer Software (wie die Benutzeroberfläche) auf einem Blatt Papier oder einem Whiteboard entworfen und mit einem Benutzer oder Kunden besprochen haben, glaube ich nicht, dass der "XP-Weg" einen solchen Ansatz nur deshalb verbietet, weil er " benutzergeschichten".

Hier ist ein schöner Artikel darüber, wie Sie mithilfe von Spezifikationen früher Feedback erhalten können. Ich denke, diese Art des Denkens ist "methodikunabhängig", und die dort vorgebrachten Argumente werden Ihnen bei Ihrer Debatte mit dem Management helfen.

Doc Brown
quelle
4

Zusammenfassend befinden Sie sich in der folgenden Situation:

  1. Du bist neu.
  2. Das Projekt (ich nehme an, Sie sprechen von einem laufenden Projekt) unterliegt dringenden zeitlichen Einschränkungen.
  3. Es wird erwartet, dass der Entwickler die Lücken nach eigenem Ermessen ausfüllt.
  4. Das Unternehmen, in dem Sie arbeiten, beabsichtigt, XP zu üben. User Stories scheinen jedoch nicht in einer Weise angewendet zu werden, die in die XP-Methodik passt. Auf der anderen Seite " Es wird erwartet, dass der Entwickler die Lücken nach eigenem Ermessen ausfüllt ".

Denken Sie an Punkt 4: Meiner Meinung nach sollten agile Praktiken an die Bedürfnisse und die Kultur eines Unternehmens / Teams angepasst werden (nicht umgekehrt). Identifizieren Sie, wo das Unternehmen an der XP-Methodik festhält und wo es abweicht. Dies ist die Grundlage für eine konstruktive Herangehensweise an Ihre Anliegen.

Aufgrund von 1 und 2 sind Sie derzeit nicht in der Lage zu hinterfragen, ob das Unternehmen XP in angemessener Weise anwendet. Wenn Sie eine Diskussion mit dem Management beginnen, werden Sie höchstwahrscheinlich als jemand auftreten, der " die Dinge kompliziert ". Sie können jedoch beginnen, Ihre Bedenken mit Ihren Mitentwicklern zu besprechen. Vielleicht finden Sie einige Entwickler, die so denken, wie Sie es tun. Vielleicht gibt es einen leitenden Entwickler, der Ihre Bedenken dann an das Management weiterleitet. Erwarten Sie jedoch nicht, dass sich die Dinge schnell ändern werden, insbesondere nicht im aktuellen Projekt. Das Projekt bietet Ihnen jedoch eine gute Gelegenheit, mehr Daten zu sammeln, was einem konstruktiven Ansatz mehr Substanz verleiht.

Nun zu Punkt 3: Ich denke, dass gute User Stories von Kunden / Endbenutzern / Produktbesitzern und Entwicklern gemeinsam geschrieben werden . Zeigen Sie eine Initiative: Suchen Sie nach einer Möglichkeit, die Autoren der User Stories direkt zu fragen. Wenn dies nicht möglich ist, fragen Sie einen leitenden Entwickler oder das Management, wie mit offenen Fragen umzugehen ist, die von den Autoren der User Stories beantwortet werden müssen. Vielleicht können Sie zumindest eine schriftliche Korrespondenz führen. Da Sie die Lücken nach eigenem Ermessen ausfüllen müssen, sollten Sie die Kunden / Endbenutzer / Produktbesitzer aktiv einbeziehen.

Irgendwann haben Sie genug Gedanken und Beobachtungen darüber gemacht, wie Ihr Unternehmen XP (oder agile Praktiken im Allgemeinen) anwendet. Vielleicht ist schon einige Zeit vergangen und Sie werden nicht mehr als Greenhorn wahrgenommen. Vielleicht hat Ihre aktive Zusammenarbeit mit dem Kunden einige positive Auswirkungen gezeigt. Vielleicht startet das nächste Projekt bereits. Vielleicht haben Sie auch schon ein Backup von anderen Entwicklern. Vielleicht stellen Sie fest, dass die Funktionsweise überhaupt nicht schlecht ist. Der Punkt ist, dass Sie dann genügend Ideen haben, um Ihre Bedenken an das Management zu übermitteln, basierend auf realen Erfahrungen und Daten in Ihrem Unternehmen.

Theo Lenndorff
quelle
+1, um den Fokus auf den Teil "Jemand, der die Dinge kompliziert macht" zurückzubringen.
Ashkan Kh. Nazary
@ ashy_32bit: Um nicht wählerisch zu sein, aber wenn Sie dort den Fokus der Antworten haben wollten, hätten Sie das zum Fokus der Frage machen sollen. (dh den größten Teil des zweiten Absatzes entfernt)
pdr
3

Ehrlich gesagt sollten User Stories nicht viele Details enthalten. "Ich möchte, dass die Software X ausführt, um die geschäftlichen Anforderungen von Y zu erfüllen" sollte ausreichen. Schließlich möchten Sie nicht, dass Geschäftsleute vorschreiben, wie das geht - Sie sind der Experte für die Software und die darin enthaltenen Best Practices.

Allerdings müssen die Entwickler auch fragen : "Wie soll das funktionieren?", "Was passiert, wenn das mit Feature Z interagiert?". Entwickler stellen keine Anforderungen, sie implementieren.

Es klingt auch so, als ob zwischen Implementierung und Evaluierung eine zu große Lücke besteht. Die Interessengruppen sollten sich alle paar Tage Prototypen und halbfertigen Code ansehen. So können Sie Feedback erhalten, bevor Sie zu weit ins Unkraut vordringen.

Telastyn
quelle
2

Wenn Sie gebeten werden, eine Geschichte zu schätzen, die Ihnen unvollständig erscheint, teilen Sie uns mit, dass Sie Fragen zur Geschichte haben und dass Sie keine richtige Schätzung abgeben können, bevor diese Fragen beantwortet werden.

Stellen Sie dann Ihre Fragen und stellen Sie sicher, dass die Antworten Teil der Geschichte werden.

Wenn Sie gezwungen sind, eine Schätzung abzugeben, auch wenn Ihre Fragen nicht (alle) beantwortet wurden, können Sie entweder eine Schätzung ablehnen oder klar angeben, dass Sie die schlechtesten Ergebnisse für die verbleibenden Lücken in Ihrer Schätzung annehmen (welche) wird wahrscheinlich Ihre Einschätzung zu einem hohen Ausreißer machen).

Bart van Ingen Schenau
quelle
1

Was Sie tun, ist keine agile Art der Entwicklung. Stattdessen arbeiten Sie mit geringen Qualitätsanforderungen. Es ist falsch, dass eine agile Art der Entwicklung nicht darin besteht, Anforderungen zu spezifizieren.

Stattdessen müssen sie zunächst so viel wie möglich angeben und bei Bedarf später ändern. Dann teilen Sie Ihre Arbeit in Teile auf und implementieren sie in Iterationen. Nach jeder Iteration ist etwas fertig.

Der Unterschied zur Wasserfallentwicklung liegt in der Wasserfallentwicklung, alles wird mit anfänglichen Anforderungen umgesetzt und am Ende geändert.

BЈовић
quelle
0

Es hört sich so an, als wären die Entwickler vollständig von der Erstellung der User Stories entfernt. Erwarten Sie, dass Sie sie wie eine detaillierte Spezifikation lesen und gleich beim ersten Mal richtig erstellen können? Wenn Sie das könnten, würden Sie weder XP noch eine andere agile Methode benötigen.

Jemand sollte Fragen stellen, wenn die Geschichte zu vage ist. Wo finden Abnahmetests statt?

User Stories sollen sich ändern. Sie müssen damit umgehen.

JeffO
quelle
0

Obwohl ein Entwickler eine Geschichte / detaillierte Anforderungen schreiben könnte, habe ich nicht viele gesehen, die gut darin sind. Wir sind gut darin, auf Probleme hinzuweisen und bessere Abläufe vorzuschlagen, aber als Input für bereits gut geschriebene Fälle.

Ich habe an neuen und bestehenden Produkten gearbeitet und hatte in beiden Fällen Fälle, in denen die Anforderungen nur 5 Zeilen umfassten und von uns erwartet wurde, dass wir die Lücken füllen und ein „verständnisvolles“ oder ausführlicheres Dokument erstellen.

Die Projekte liefen viel besser als wir hatten unsere eigene professionelle Service-Person, die dabei half (oder in einem Fall einen VP, der einsprang, da sonst niemand verfügbar war). In jedem Fall ist es Zeitverschwendung, sich weiterzuentwickeln (es sei denn, es kommt kein Feedback zurück und die Frist hat sich nicht geändert). Mein Vorschlag: Fordern Sie weitere Details an, geben Sie mehr an, fordern Sie zeitgebundenes Feedback zu Ihren Annahmen und Unterlagen an und geben Sie an, dass das Risiko von Nacharbeiten und Verzögerungen besteht, wenn Sie diese Informationen nicht bis zum x-Datum erhalten.

tgkprog
quelle
0

Unabhängig von der Entwicklungsmethode muss der Entwickler, was auch immer Sie zur Definition von Anforderungen verwenden, Annahmen treffen, auf die Geschäftsseite zurückgreifen. Ich habe oft eine gute Vorstellung davon, welche Antwort ich bevorzugen würde, also lehne ich die Dinge so zurück:

XYZ ist mir unklar. Bedeutet das ABC? Oder fehlt mir etwas? (Angenommen, XYZ ist die Voraussetzung. Angenommen, ABC ist die Annahme, die ich als Entwickler machen möchte.)

Es dauert viel weniger Zeit, um die Dinge zu klären, bevor Sie schlechte Annahmen treffen, als um sie zu wiederholen. Entwickler, die Vermutungen über Anforderungen anstellen, ohne die Bestätigung zu erhalten, dass ihre Vermutung richtig ist, sind in der Regel schlechte Entwickler und kosten ihr Unternehmen viel Geld. Wenn ein schlechter Manager nicht zulässt, dass Sie sich zurücklehnen, erklären Sie ihm, wie viel Zeit und Geld es kostet, etwas falsch zu machen. Wenn er immer noch darauf besteht, dann tun Sie, was er sagt, und wenn UAT fehlschlägt, erinnern Sie ihn daran, wie kostspielig es war, wenn er Sie das nächste Mal nicht zurücklassen wollte. Wenn er immer noch nicht zuhört, finden Sie einen besseren Chef.

Der andere Wert des Zurückwerfens besteht darin, dass das Unternehmen nach und nach lernt, was Sie benötigen, und Ihnen bessere Anforderungen stellt.

HLGEM
quelle
0

Als ein Entwickler,

Ich muss die Besonderheiten einer User Story vollständig verstehen.

damit ich es sicher einschätzen und umsetzen kann.

Mit anderen Worten, Sie müssen Fragen stellen, bis Sie die Einzelheiten der Geschichte verstanden haben. Dies erfolgt in der Iterationsplanung und dient als Entscheidungspunkt: Wenn Sie es nicht schätzen können, können Sie es nicht erstellen.

Martin Wickman
quelle