Kann Scrum technische Spezifikationen im Product Backlog anstelle von User Stories verwenden?

In der Firma, für die ich gerade arbeite, haben wir begonnen, Scrum-Projekte zu realisieren. Es war nicht so schwer, die Manager davon zu überzeugen, vom Wasserfall nach Scrum zu ziehen. Wir machen ein Projekt, bei dem wir unsere Plattform von Grund auf neu aufbauen. Die (meisten) Funktionen sind bekannt und die meisten Verbesserungen sind eher technisch.

Hier könnte es gerechtfertigt sein, eher technische Aufgaben als User Stories zu haben. Unser Auftragsbestand hat alle Arten von technischen Aufgaben wie:

• Schreiben Sie die DB-Klasse von MySQL nach PostgreSQL um.
• Implementieren Sie die Systemprotokollierung.
• Schreiben Sie den Objekt-Cache neu.

Dinge, die während der Stand-ups auftauchen, beinhalten, dass lange "Forschungsaufgaben" gewünscht werden, aber sie werden nie erledigt. Außerdem behaupten die Teammitglieder mitten im Sprint, dass ungeplante Aufgaben hinzugefügt werden müssen.

Wie soll ein Scrum Master damit umgehen? Könnte es sein, dass für diese Art von Projekt Scrum NICHT der richtige Weg ist?

TL; DR

Scrum schreibt die Verwendung von User Stories nicht vor. Sie sind einfach eine nützliche agile Praxis. Während der Product Owner mit Sicherheit technische Spezifikationen anstelle von User Stories verwenden könnte, um das Product Backlog zu erstellen, sind die meisten Ihrer anderen Prozessprobleme darauf zurückzuführen, dass keine effektiven Scrum- und agilen Praktiken angewendet werden.

Verschiedene Probleme mit Ihrem Prozess

Ihr Scrum scheint in vielerlei Hinsicht kaputt zu sein, darunter:

1. Ihren Angaben fehlt eine explizite Sichtweise oder ein Wertversprechen.
2. Ihre Rückstandselemente werden nicht an Sprintziele gebunden.
3. Ihr Backlog-Aufbereitungsprozess fehlt entweder vollständig oder es können keine Story-Spikes für das Product Backlog erstellt werden.
4. Ihr Sprint Planning-Prozess zerlegt Product Backlog-Elemente nicht angemessen in Sprint Backlog-Elemente.
5. Ihr Team berücksichtigt Unsicherheiten in Bezug auf Rückstandselemente nicht ordnungsgemäß in seinen Sprint-Planungsschätzungen.
6. Ihr Team respektiert weder die Grundlagen des Zeitboxens noch die Integrität des Sprints.

Während Scrum nicht immer für jedes Projekt geeignet ist, wäre es in diesem Fall genauer zu sagen, dass Scrum nicht funktioniert, weil das Team Scrum nicht wirklich ausführt. Ihre Frage zu User Stories ist nur ein kleiner Teil der größeren Prozessprobleme, mit denen Ihr Team konfrontiert ist.

Warum agile Programmierer User Stories aufnehmen

Technische Spezifikationen sind ein grundlegend fehlerhafter Weg, um Anforderungen zu kommunizieren. Anforderungen, die aus einer Sicht nicht festgemacht sind, bieten Entwicklern keine nützliche Anleitung. Verwenden Sie Ihre geposteten Beispiele:

• Schreiben Sie den Objekt-Cache neu. Warum? Was ist das Ziel? Wer erhält die Leistung? Wer kann die Aufgabe klären? Wenn dies mit einer nicht funktionalen Anforderung verbunden ist, welches Projektziel wird mit dieser Anforderung angesprochen?
• Implementieren Sie die Systemprotokollierung. Warum? Wer wird die Protokolle lesen? Welche Informationen müssen die Protokolle enthalten? Woher wissen Sie, ob das Protokollformat oder die Protokolldaten nützlich sind?

Aus Entwicklersicht führt die Nichtbeantwortung derartiger Fragen zu genau den von Ihnen beschriebenen Prozessproblemen. Dies ist die Aufgabe von User Stories: Sie bieten den dringend benötigten Kontext und dienen als Platzhalter für zusätzliche Gespräche mit Interessengruppen oder Endbenutzern über bestimmte Funktionen.

Sie sollten User Stories nicht verwenden, weil Sie der Meinung sind, dass dies eine Rahmenbedingung ist, oder weil es sich um eine allgemein akzeptierte agile Praxis handelt. Stattdessen sollten Sie daran arbeiten, sie effektiv zu erstellen und zu verwenden, da dies Programmieraufgaben erleichtert und dem Programmierer mehr Spaß macht. Ihr Kilometerstand kann natürlich variieren.

Ich glaube nicht, dass das Problem hier Scrum als solches ist. Ich denke, das Problem ist, dass es kein klar definiertes Projekt gibt und (das habe ich schon oft erlebt) keine klare Richtung.

Ich denke, Ihre technischen Aufgaben sind in Ordnung, möglicherweise groß, aber messbar und definierbar, also absolut in Ordnung für eine Geschichte.

Forschungsaufgaben sind für mich in Scrum eine große rote Fahne, da sie wenig sichtbaren Nutzen bringen und zu einem enormen Umfangschleichen führen können. Ich befürworte, diese im Sprint im Voraus einzuschränken, sie sollten nicht hinzugefügt werden, und sie sollten sicherlich nicht auf Kosten von festgelegten Zielen hinzugefügt werden. Wenn sie benötigt werden, um eine vereinbarte Sprintaufgabe zu erledigen, sollte diese Abhängigkeit bei der Planung klar gewesen sein (ansonsten, was haben sie geschätzt?).

Nach meiner Erfahrung sind Projekte mit vielen "Untersuchungsspitzen" eine Deckung für Entwickler, die nicht wirklich viel tun und Zeit damit verbringen möchten, sich über die neue, glänzende, coole Sache zu informieren, anstatt geschäftlichen Wert zu schaffen. Ich schlage nicht vor, dass Ihr Team dies tut, aber ein Projekt muss klare Ziele haben. Wenn Entwicklern die Freiheit gegeben wird, "zu recherchieren", werden sie es tun und so lange weitermachen, wie Sie es zulassen.

Scrum sagt, dass Sie Ihrem Kunden besser ein lieferbares Produkt anbieten sollten. Der Punkt hier ist jedoch, dass es nicht das lieferbare Produkt und den Kunden spezifiziert .

Mit anderen Worten, in Ihrem speziellen Fall können Sie Ihr zu lieferndes Produkt als Codeverbesserungen, Plattformänderungen, Umschreibungen und Neugestaltungen usw. definieren und Ihren technischen Manager als Ihren Kunden betrachten.

Das macht für mich 100% Sinn. Sie erstellen ein Backlog, das die Geschichten der Benutzer Ihrer Produkte erzählt, und wer ist der Benutzer? Technischer Manager. So Artikel wie:

1. Als technischer Manager möchte ich, dass meine Datenbank von MySQL auf X wechselt, damit ich die Skalierbarkeit erhöhen kann
2. Als Entwickler möchte ich ein umfassendes Protokollierungssystem, damit ich effizienter diagnostizieren kann

Und was Sie an Ihren Kunden (technischen Manager) liefern, ist ein Protokollierungssystem.

In Bezug auf die F & E-Aufgaben, über die Sie gesprochen haben, empfehle ich jedoch, dass Sie sich mit Spikes in Scrum befassen. Es handelt sich im Wesentlichen um Mini-Aufgaben mit Zeitrahmen, mit deren Hilfe Sie die Zeit bestimmen können, die für die Ausführung größerer unbekannter Aufgaben erforderlich ist.

Als Scrum Master sollten Sie aufgrund der Art der Arbeit längere Sprints in Betracht ziehen. Dies gibt Ihnen ein wenig mehr Puffer für die "Forschungs" -Aufgaben. Ich denke jedoch, dass Sie sicherstellen müssen, dass die Aufgaben eine Art Arbeitsprodukt / Proof-of-Concept im Code erzeugen. Was erwarten Sie von einem Programmierer? Bitten Sie sie, etwas zum Arbeiten zu bringen, und verwenden Sie diese Informationen, um festzustellen, ob A: es das tut, was wir wollen. B: es funktioniert besser nimm etwas zu machen.

Wenn Sie feststellen, dass Sie nicht so viel über das aktuelle Umschreiben wissen, können Sie zu kürzeren Sprintzyklen wechseln. Haben Sie keine Angst, sie im Laufe der Zeit anzupassen. das ist es, was man unter agil versteht. Nach Ihrer Recherche können Sie sich auch für die neue Technologie entscheiden. Dies könnte ein weiterer Grund sein, die Sprints zu verkürzen, bevor sie zu weit außer Kontrolle geraten. Vielleicht stellen Sie mitten im Sprint fest, dass das neue Zeug nicht funktionieren wird. Stoppen Sie den Sprint und passen Sie ihn mit der alten Technologie an. Schließlich sollten Ihre Entwickler in der Lage sein, die alten und neuen Methoden zu vergleichen und gegenüberzustellen.

Sie jonglieren mit den Bedürfnissen Ihrer Entwickler und bekommen in diesem Fall die Anwendung neu geschrieben. Vermutlich gibt es Produktbesitzer, die dieses Projekt eher früher als später abschließen möchten und die Notwendigkeit von "Forschung" nicht als langfristige Entschuldigung akzeptieren.

Einige der folgenden Strategien können helfen,

1. Ja, mit Technical Stories können Sie einen Rückstand haben .

   Wie eine User Story sollte dies auch Technical Stories sein, wobei der Fokus auf den Vorteilen liegt, die es für den Endbenutzer bringt. Hier sind einige Tipps zum Schreiben. Dies sind Geschichten, die dem Produkt einen inneren Wert verleihen, als ob Sie zu einem besseren Back-End usw. wechseln möchten.

2. Verwenden Sie für Untersuchungsaufgaben Spike

   Ein Spike ist ein Experiment, mit dem Entwickler gerade genug über etwas Unbekanntes in einer User Story lernen können, z. B. eine neue Technologie, um diese User Story einschätzen zu können. Ein Spike muss mit einer Time-Box versehen sein. Dies definiert die maximale Lernzeit und legt die Schätzung für den Spitzenwert fest.