Gemeinsame Entwicklungsaufgaben für agile User Stories

Mein Team wird Visual Studio Team Services für ein bevorstehendes Projekt verwenden. Mit den Agile-Tools kann ich User Stories und Aufgaben hierarchisch wie folgt organisieren:

Episch> Feature> User Story> Aufgabe / Fehler

Nehmen wir an, ich entwerfe ein Student Org (Club) -Managementsystem für Schüler und Berater. Studenten und Berater können Clubs beitreten, Offiziere sein, Veranstaltungen organisieren, Ankündigungen senden usw.

Nehmen wir als Beispiel die Funktion Ankündigungen:

Benutzergeschichten:

• Als Student möchte ich Ankündigungen für die Clubs lesen, in denen ich Mitglied bin, damit ich über Änderungen des Zeitplans informiert bin.
• Als Berater möchte ich Ankündigungen für die Clubs lesen, in denen ich Mitglied bin, damit ich über Änderungen des Zeitplans informiert bin.
• Als Berater möchte ich Ankündigungen für die Clubs senden, in denen ich Mitglied bin, damit meine Schüler über Änderungen des Zeitplans informiert werden
• Als Administrator möchte ich Ankündigungen an ALLE Schulklubs senden, damit ich sie auf Planungskonflikte aufmerksam machen kann.
• usw

Wenn wir davon ausgehen, dass es sich um gut geschriebene User Stories handelt (was möglicherweise nicht der Fall ist), bin ich verwirrt, wenn mein Entwicklungsteam und ich uns hinsetzen, um diese Elemente in Entwicklungsaufgaben aufzuteilen. Wir können Teile mehrerer User Stories mit einzelnen Entwicklungsaufgaben abdecken. Zum Beispiel haben wir ein Tool, das CRUD-Aktionen für alle Ebenen von der Benutzeroberfläche bis zur Datenbank generiert, indem einfach die Eigenschaften einer Ankündigung definiert werden. Die Teile mehrerer User Stories zum Senden und Lesen werden also in einem einzigen Entwicklungsschritt abgeschlossen.

Nach allem, was ich gelesen habe, sollte jede User Story unabhängig von den anderen sein, und das macht Sinn. Jede unserer User Stories teilt jedoch die Aufgabe "Benutzeroberfläche und Datenbank generieren", da wir auf diese Weise unsere Benutzeroberfläche auf Basisebene erstellen (bevor wir sie anpassen). Ich sollte nicht für jede User Story eine Aufgabe "Benutzeroberfläche und Datenbank generieren" schreiben. Das ist zu viel Redundanz. Ich weiß jedoch nicht, wie ich eine Aufgabe "Benutzeroberfläche und Datenbank generieren" schreiben soll, die abgeschlossen sein muss, bevor eine der User Stories gestartet werden kann.

Ich habe ähnliche Verwirrung mit unserem Berechtigungssystem. Wir haben verschiedene Kontotypen wie Student, Berater und Administrator, die alle Zugriff auf die Seite Ankündigungen haben, aber unterschiedliche Funktionen auf der Seite haben (ich habe diese Idee mit den obigen Benutzergeschichten erfasst). Wir können das Berechtigungssystem modular schreiben, damit es für andere Funktionen verwendet werden kann, aber ich weiß nicht, wo ich die Aufgabe schreiben soll, um ein "modulares Berechtigungssystem" zu erstellen.

Ich denke, diese ganze User Story-Sache hat mich verwirrt. Ja, es ist großartig, um die Funktionalität eines Systems zu erfassen, aber wenn es darum geht, Entwicklungsaufgaben zu durchdenken, kann ich mich nicht darum kümmern. Jeder Rat wäre toll.

TL; DR: Ein Teil der Programmierung, die ich für eine User Story mache, kann an anderer Stelle in unserem Projekt für andere User Stories (Berechtigungssystem usw.) verwendet werden. Wie schreibe / organisiere ich Aufgaben für User Stories, um diese Möglichkeit zu veranschaulichen?

Ich sollte nicht für jede User Story eine Aufgabe "Benutzeroberfläche und Datenbank generieren" schreiben. Das ist zu viel Redundanz. Ich weiß jedoch nicht, wie ich eine "Generate UI and DB" -Aufgabe schreiben soll, die abgeschlossen sein muss, bevor eine der User Stories gestartet werden kann.

Das tust du nicht .

Sie schreiben Ihre User Stories als hochrangige Benutzeranforderungen - so weit sind Sie gekommen.

Dann wählen Sie die User Story (Feature) aus, die Sie zuerst angehen möchten. An diesem Punkt entscheiden Sie - angesichts des aktuellen Status des Produkts -, wie diese Funktion am besten implementiert werden soll. Dann erledigen Sie die minimale technische Arbeit, die zur Implementierung der Funktion erforderlich ist. Dann fahren Sie mit der nächsten User Story fort.

Dies könnte wie folgt funktionieren:

• Wir setzen uns, um User Story 1 zu machen und festzustellen, dass eine Datenbank erforderlich ist. Also implementieren wir die Datenbank und dann die Funktion.
• Wir setzen uns, um User Story 2 zu machen und festzustellen, dass wir die Datenbank bereits haben. Jetzt müssen wir nur noch die Benutzeroberfläche erweitern.

Oder in Ihrem Beispiel könnte es sogar wie folgt funktionieren:

• Wir setzen uns, um das Senden einer Ankündigung umzusetzen. Wir erstellen eine Benutzeroberfläche mit einem Textfeld und einer Schaltfläche zum Senden, mit der ein Formular veröffentlicht wird. Backend passiert nichts. Cool. User Story abgeschlossen.
• Jetzt setzen wir uns, um den Empfang von Ankündigungen zu implementieren. Es ist wohl an der Zeit, etwas mit ihnen zu tun, wenn sie gesendet werden.

Der gesamte Zweck dieses Prozesses besteht darin, Sie daran zu hindern, das Ganze im Voraus zu entwerfen, und Ihnen zu ermöglichen, fundierte Entscheidungen darüber zu treffen, wie das nächste Ding angesichts des aktuellen Status der Software implementiert werden soll . Das ist direkt unvereinbar mit dem Versuch, alle Geschichten in technische Aufgaben zu zerlegen, bevor eine von ihnen gestartet wird.

Sie entwerfen die Lösung also erst, wenn Sie die Geschichte aufgegriffen und Ihr Design einzeln weiterentwickelt haben. Wie (und sogar ob) Sie Ihr technisches Design dokumentieren, sobald Sie mit der Arbeit an einer Geschichte beginnen, liegt bei Ihnen.

Wenn zwei Entwickler zwei Storys gleichzeitig aufgreifen und beide technische Anforderungen teilen, bedeutet dies, dass Sie diese Arbeiten nicht parallel ausführen können. Wählen Sie also eine aus und lassen Sie den anderen Entwickler etwas anderes tun.

Hier geht es darum, einfache Lösungen zu implementieren und Ihr Design zu überarbeiten, wenn neue Anforderungen entstehen.

Und denken Sie vor allem daran: Dies ist keine Wissenschaft .

Da Sie jeden Sprint mit einer priorisierten Liste von Storys eingeben und jede Story in separate technische Aufgaben unterteilt ist, sollten alle Entwickler an Aufgaben für die Story mit der höchsten Priorität arbeiten, bevor Sie mit der Arbeit an der Story mit der zweithöchsten Priorität beginnen. Aus diesem Grund sollte die Aufgabe "Benutzeroberfläche und Datenbank generieren" zu dem Zeitpunkt, an dem Sie mit der Arbeit an der Story mit der zweiten Priorität beginnen, bereits als Teil der ersten Story abgeschlossen sein. Wenn Sie also während der Sprintplanung feststellen, dass eine technische Aufgabe über mehrere Storys hinweg dupliziert wird, ordnen Sie diese Aufgabe der Story mit der höchsten Priorität zu, damit sie zuerst abgeschlossen wird.

Wenn Ihr Team die Gewohnheit hat, die Prioritäten der Story nach dem Start des Sprints neu zu ordnen, kann es von Vorteil sein, doppelte technische Aufgaben in jede Story aufzunehmen und zu notieren, welche Aufgabe andere Storys verwenden.

Es kann hilfreich sein, anhand einer Liste technischer Aufgaben anstelle einer Liste von Geschichten in die Denkweise des Arbeitens einzusteigen.