Ich habe gerade in einem neuen Unternehmen angefangen, das sich entschlossen hat, agiler zu werden. Sie haben sich entschieden, die Anforderungsspezifikation in Jira zu erstellen. Als UX-/Interaction-Designer finde ich es schwierig, das große Ganze zu sehen, wenn ich die Liste der Epics und Aufgaben in Jira sehe.
Ich bin es gewohnt, Anforderungen pro Seite und pro Funktion zu haben, da sie die Anforderungen in einen Kontext setzen.
1) Wie sollte ich eine Art agile Anforderungsspezifikation in Confluence strukturieren?
2) Kann ein Epic zB Startseite oder Profilseite sein?
Das ist schwer zu beantworten. Auf den ersten Blick stellen Sie die Art von Frage, bei der ein agiler Praktiker zusammenzucken würde. Ihre Argumentation liest sich auch so, als würden Sie Ihrem persönlichen Komfort („der wenigen“) Vorrang vor dem Erfolg des Teams („der vielen“) geben.
Abgesehen davon, einige Fragen.
Wenn Sie sagen "sie haben entschieden", wer sind sie? Verwaltung? Das Entwicklungsteam? Welche Rolle spielen diese Anforderungen in Ihrem Projekt? Wann werden sie im Verhältnis zum Rest des Projektzyklus geschrieben, wer schreibt und pflegt sie und wer ist ihre Zielgruppe? Von wo aus arbeitet das Publikum?
Wenn das Team diese Entscheidung getroffen hat, bedeutet das einseitige Herunterfahren, dass Sie nicht agil sind, bitte sammeln Sie Ihre Sachen. Wenn das Management diese Entscheidung getroffen hat, sprechen Sie zunächst mit Ihrem Team.
Wenn Sie die vollständigen Anforderungen im Voraus definieren (dies ist der Teil, der dazu neigt, zusammenzucken), dann ist das kritischste Publikum das Entwicklungsteam, und sie beginnen hoffentlich mit JIRA oder einem anderen aufgabenorientierten Tool (Freunde lassen es nicht zu Freunde verwenden Confluence als Task-Manager).
In diesem Fall ist das Layout des Dokuments viel weniger wichtig als die Verknüpfung der Inhalte mit den JIRA-Aufgaben für die Implementierung. Wenn Ihr Team Storys verwendet, sollte jede Story in JIRA ein Hub und eine Homepage für alle Informationen sein, die Ihr Team benötigt, um sie von Anfang bis Ende zu erstellen. Wenn Ihr Team weiß, dass es mit der Story beginnen und einen klaren Pfad zur Confluence-Seite finden kann, spielt es keine Rolle, wo sich diese Seite befindet.
Wenn Sie an einigen Ideen für das Dokumentationslayout interessiert sind und Dinge wie Stories und Epics verwenden, sollten Sie sich mit User Story Mapping befassen , um eine zweidimensionale Sichtweise auf das Gesamtbild zu erhalten und daraus ein Dokumentationsschema zu erstellen. Es funktioniert sehr gut mit Initiative > Epic > Story-Hierarchie zusammen mit Freiform-Theme-Tagging (falls Sie sich jemals für das Portfolio-Produkt von Atlassian entscheiden). Diese Art von Hierarchie + Tags-Schema wird einem Confluence-Seitenbaum + Seitenlabels-Ansatz ziemlich schmerzlos zugeordnet.
Es stimmt auch mit der nativen Vorschrift von JIRA und Confluence überein. Die sofort einsatzbereiten Anforderungsvorlagen von Confluence verhalten sich wie Epic-Seiten mit Story-Tabellen, und das Epic-Management von JIRA Agile ist mit Confluence-Seitenverlinkungen versehen. Atlassian möchte , dass Sie Epics zur kleinsten „Seite“-Einheit in Confluence machen, also machen Sie es.
Denken Sie nur daran, dass Anforderungen im Vorfeld selbst sehr stark ein Produkt sind, und wie ein Produkt haben sie ihre eigenen Anforderungen und Kunden, die ein Mitspracherecht haben. Stellen Sie sicher, dass derjenige, der Ihre Anforderungen tatsächlich verwendet, eine aktive Rolle bei der Entscheidung spielt, wie sie bereitgestellt werden.
Denken Sie daran, dass sich der agile Ansatz darauf konzentriert , auf Veränderungen zu reagieren .
Um dies zu erreichen, ist es sinnvoll, sich nicht frühzeitig auf detaillierte, schriftliche Anforderungen festzulegen. Daraus entstand das Konzept der User Stories . Eine User Story ist keine detaillierte Anforderung, sondern eine Einladung zu einem Gespräch . Es ist das Gespräch, das die Details kommuniziert.
Nun, wie Sie betonen, kann dieser Ansatz es schwierig machen, das große Ganze zu sehen. Mein Vorschlag wäre also, gerade genug Details in Confluence zu haben, um Ihrem Team einen Überblick über das Design zu geben. Was „gerade genug“ ist, wird von Team zu Team und von Projekt zu Projekt unterschiedlich sein. Versuchen Sie, einen guten Mittelweg zwischen vielen Details und viel Flexibilität zu finden.
Kann ein Epic eine Startseite oder Profilseite sein? User Stories und Epics sind in erster Linie zum Nutzen des Product Owners und der Stakeholder da. Sie konzentrieren sich darauf, dem Laien zu erklären, was geliefert wird, anstatt eine Hilfe bei der Implementierung zu sein.
Die Antwort auf Ihre Frage ist also, dass ein Epic eine Startseite oder eine Profilseite sein kann, wenn dieser Ansatz sowohl für den Product Owner und die Stakeholder als auch für das Entwicklungsteam nützlich ist. Ich kann mich sicherlich an Projekte erinnern, bei denen das zutraf, aber es wird nicht immer zutreffen.
Stefan