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

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?

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."

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.

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.

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.

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).

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.

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.

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.

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.

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.