Wie würden Workitems im Zusammenhang mit der Unterstützung einer bereits in Produktion befindlichen Lösung aussehen?

Unser Shop wird die Wartung eines bereits in Produktion befindlichen Systems fortsetzen. Unser nächstes Update besteht darin, einen Fehler zu beheben und eine Dokumentation zu erstellen, damit neue Mitglieder, die unserem Team beitreten, das System verstehen können. Ich weiß nicht, was die Arbeitselemente sein sollten, da wir einen brandneuen Team Foundation Server (mit Scrum-Vorlage) haben und die Vorgesetzten möchten, dass alle Arbeiten darin nachverfolgt werden. Würde so etwas funktionieren?:

  • Epic: Kundenbeziehungsmanagement „Echo“-Systemsupport und -Updates.
  • Funktion: Systemaktualisierungen.
  • PBI: 1. Als Systemadministrator möchte ich das System vollständig verstehen, damit ich Innovationen und Support bieten kann.
  • Fehler: 2. Keine Rollenvalidierung während der Genehmigung eines Produkts.
  • Aufgabe: 1. Dokumentation mit Workflow-Prozess des „Echo“-Systems erstellen.
  • Aufgabe: 2. Refaktorieren Sie den Code, damit die Genehmigungsaktion validiert, ob die Rolle für die Validierung korrekt ist.
Ron Jeffries und Chet Hendrickson sprechen über User Stories. Ein Beitrag von Ron Jeffries aus dem Jahr 2001.
Ich habe Ihre Links gesehen und gelesen - es scheint die Idee zu untermauern, mit Geschichten flexibel zu sein, aber dennoch die Wer-, Was- und Warum-Fragen beantwortet zu halten. Er scherzte über das „As“-Format, aber am Ende bestätigte er immer noch, dass es notwendig war, um diese 3 Ws zu beantworten. Ich interessiere mich jedoch mehr dafür, wie Teams ihre Arbeit verfolgen, die nicht direkt mit einem Geschäftswert / Product Owner zusammenhängt, z. B. das Erstellen von Dokumenten, Schulungen, neue Mitarbeiter usw.
Im Tool sollten nur Arbeiten erfasst werden, die direkt mit dem Produkt in Zusammenhang stehen. Es ist nicht der Zweck, es als vollständige Arbeitszeiterfassungslösung für Arbeiter zu verwenden. Hüten Sie sich auch vor dem Trugschluss der 100-prozentigen Auslastung.

Antworten (2)

Sie haben nicht gesagt, wie lange Ihr Sprint dauert, und mit nur ein paar Aufgaben wird das Burndown-Diagramm Ihnen oder den Stakeholdern nicht viele Informationen liefern. Wenn Sie dies in ein paar Tagen im Rahmen eines technischen Schuldenbereinigungssprints tun können, denke ich, dass es wahrscheinlich in Ordnung ist. Wenn nicht, sehen Sie, ob Sie die Aufgaben in Arbeitspakete von 8 Stunden oder weniger aufteilen können.

Ich hoffe, das hilft

Die Sprints dauern 2 Wochen, das Programminkrement 2 Monate. Was die Arbeit betrifft, so war dieser Fehler in 2 Stunden erledigt - die Anforderungsdokumentation dauert etwa ein paar Werktage.
Ok, also bei weniger als einer Woche insgesamt war es wahrscheinlich nur ein Teil des Sprints. Ich denke, dann geht es dir gut.
OK, ich war besorgt, dass mein PBI keinen wirklichen "Geschäftswert" hinzufügt und daher nicht gut wäre, wie ich es angelegt hatte.

In Scrum ist es ein gängiger Ansatz, alles um User Stories zu wickeln.

Nimm deine Beispiele:

Als Systemadministrator möchte ich das System vollständig verstehen, damit ich Innovationen und Support bieten kann

Dies ist keine User Story, sondern eine Aufgabe, die in eine Story integriert werden könnte, die einen Geschäftswert liefert.

Ein eher Scrum-Ansatz wäre:

Als Benutzer möchte ich, dass die Genehmigungsaktion validiert, ob ich die korrekt validierte Rolle habe, damit ich alle erforderlichen Genehmigungen abschließen kann

Es könnte mehrere Unteraufgaben unter dieser Geschichte geben, darunter:

Gewinnen Sie ein Verständnis für das System

Erstellen Sie eine Dokumentation für das System

Die Idee ist, Ihren Rückstand auf die Bereitstellung von Geschäftswert zu konzentrieren, aber das bedeutet nicht, dass Sie die Aufgaben ignorieren, die erforderlich sind, um diese Arbeit zu liefern. Sie packen es einfach in die User Stories.

Danke Barnaby, anscheinend bekomme ich immer zwei sehr polare Antworten für Benutzergeschichten, einige sagen, es sei nur für den Geschäftswert, andere sind flexibler, indem sie alternative Geschichten wie "Als Systemadministrator, ..." verwenden. Selbst bei der Google-Suche bekomme ich unterschiedliche Antworten, es scheint nur ein Stilansatz zu sein.
Es ist wahrscheinlich am besten, das zu tun, womit sich das Team und der Product Owner am wohlsten fühlen. Es ist erwähnenswert, dass das Erstellen von Arbeitselementen zu Unteraufgaben von Storys sie nicht weniger wichtig macht. In gewisser Weise wird betont, wie wichtig sie sind: Wir MÜSSEN das System verstehen und dokumentieren, da es für die Bereitstellung von Geschäftsgeschichten von entscheidender Bedeutung ist. Es stoppt ein Gespräch, in dem vorgeschlagen wird, dass das Verstehen/Dokumentieren verzögert werden kann, während der Geschäftswert geliefert wird.
Wie würden Workitems im Zusammenhang mit der Unterstützung einer bereits in Produktion befindlichen Lösung aussehen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v