Wie verwaltet man den Umfang in JIRA?

Ich arbeite in einer Softwareentwicklungsfirma. Wir entwickeln mit Festpreisverträgen, daher gibt es viel BDUF (Big Design Up Front). Während der Anfangs-/Planungsphase erstellen wir sehr große monolithische Dokumente zum technischen Umfang in MSWord und holen die Genehmigung/Unterschrift vom Kunden ein. Bei der Entwicklung beziehen wir uns dann auf diese Dokumente: zB: „gemäß Seite XX“ oder „gemäß Abschnitt XX“ in unserer Arbeit in JIRA-Tickets. Änderungsanforderungen führen dazu, dass eine neue Version der Spezifikation aus dem MSWord neu erstellt wird und der geänderte Abschnitt oder Anhang am Ende neu signiert wird. Unsere Kunden müssen immer etwas unterschreiben, sie bevorzugen es so.

Ich frage mich, ob Sie mir bitte bei folgendem helfen können:

  • Gibt es eine Möglichkeit, den Umfang direkt in JIRA detaillierter einzugeben (z. B. eine Funktionalität pro JIRA) und automatisch ein großes Dokument zum "Signieren" zu generieren?
  • Wäre es möglich, Änderungen in JIRA nachzuverfolgen, nachdem die signierte Version fertig war?
  • Würden Sie ein anderes Tool verwenden, um diese Spezifikationen einzugeben? ZB: ein Tool, das sich irgendwie in JIRA integriert, und Sie haben den Umfang bereits in granularer Weise darin?

Dies würde die Autoren zwingen, den Geltungsbereich präziser und in sich geschlossener zu schreiben (und der gesamte Geltungsbereich wäre in JIRA, was die Kommunikation erleichtert). Bitte beachten Sie, dass es auch eine Option ist, den Bereich in MSWord einzugeben und dann in JIRA zu verschieben, aber viel Nacharbeit (~ 100 Seiten davon), daher suche ich nach einer Lösung, bei der ich dies nur einmal schreiben muss.

Jede Hilfe ist willkommen.

Vielen Dank!

Hallo und willkommen bei PMSE. Werfen Sie einen Blick auf die Tour -Seite, um zu sehen, wie diese Seite funktioniert.
Vielen Dank! Bitte lassen Sie mich wissen, ob ich meine Frage irgendwie klären kann.
Dió hast du Use-Cases, User-Stories oder ähnliches? Wie ist Ihr Dokument aufgebaut?
Wir haben eine Plattform mit gut dokumentierter „Standard“-Funktionalität. Dieses Standarddokument wird nie geändert. Wir beschreiben dann einfach mit Text oder Bildern die Anpassungen für bestimmte Abschnitte in der Software. Nur Use-Cases, keine User-Stories. Das Dokument ist in Abschnitte gegliedert, wobei jeder Abschnitt die Änderung eines bestimmten Teils der Software beschreibt. Jeder Abschnitt kann meistens zwischen 1 und 20 Seiten umfassen.
hast du auch confluence?
Ja, wir haben Konfluenz.
Ich verwende Jira gerne, aber ich befürchte, dass die Frage in ihrer jetzigen Form fast eine Einkaufsfrage ist .

Antworten (2)

Klingt, als ob Sie nach einem Anforderungsmanagement-Tool wie Doors suchen . Dies wäre eine nicht zum Thema gehörende Frage, und Sie finden möglicherweise bessere Antworten in Software Recommendation StackExchange.

Trotzdem stellen Sie eine projektbezogene Frage: Wie geht man mit Scope und Scope-Änderungen um?

Der allgemeine Mechanismus in Bezug auf Umfang und umfangsbezogene Änderungen sind Baselines und Change Requests .

Baselines frieren einen bestimmten Satz von z. B. Anforderungen z. B. in der Vertragsphase ein. Änderungen während der Entwicklung können über Change Requests nachverfolgt werden. Normalerweise ziehen Sie eine neue Baseline an einem Meilenstein, z. B. PDR oder CDR. Während der Sitzungen des Change Control Boards entscheiden Sie, wie Sie mit den verschiedenen CRs umgehen und ob Sie den Kunden irgendwie einbeziehen sollten.

Sie können für diesen Zweck jedes Tool verwenden, aber Sie finden es möglicherweise hilfreich, beim Ziehen von Baselines und beim Nachverfolgen von Änderungen unterstützt zu werden. Jira könnte nett sein, um den Fortschritt zu verfolgen, während einfache Textexporte (xml, csv) als Baselines in Kombination mit Git ein Werkzeug sein könnten, das diese Anforderungen erfüllt. Anforderungen werden oft hierarchisch aufgebaut. Ich denke, Jira bietet 3 Hierarchieebenen (zB Epic, Story, Task). Ich glaube nicht, dass das reicht.

Es gibt mehrere Tools, die auf das Anforderungsmanagement spezialisiert sind. Sie unterstützen normalerweise alles, was oben beschrieben wurde. Einfach ein bisschen googlen.

Danke für diese Antwort. Wie die Frage beschreibt, versuche ich, den möglichen Workflow innerhalb von JIRA / Confluence zu schließen: 1) Generieren Sie die erste "Baseline" -Version der technischen Spezifikation. 2) Generieren Sie Änderungsanfragen (oder sogar Verfeinerungen im Laufe des Projekts) in JIRA / Confluence. 3) Generieren Sie zu einem späteren Zeitpunkt (irgendwie ist dies der Punkt der Frage) eine konsolidierte Version der technischen Spezifikation einschließlich aller konsolidierten geänderten Anforderungen. Idealerweise enthält dieses Dokument eine Liste der Änderungen. Diese wird wieder abgemeldet.
Nochmals vielen Dank für die Antwort - nur zum Off-Topic-Bit: Ich bin sicher, dass es nicht viele PMs auf Software Recommendation StackExchange geben wird, da es sich um ein Allzweckforum handelt. Meine Frage gibt einen sehr spezifischen Projektmanagementprozess und Anwendungsfall an. Ich bin nicht der Meinung, dass die Frage nach Tools für das Projektmanagement hier nicht zum Thema gehört.
@testTester können Sie eine Liste von Meilensteinen in Jira definieren und diese als zu behebendes Datum in den Fehlern / Aufgaben referenzieren. Dies in Kombination mit Problemtypen wie Anforderungen , Änderungsanforderung , Problem könnte das sein, wonach Sie suchen.

Die Grundlagen zur Organisation eines Projekts wie diesem in Jira sind auf der Confluence-Website von well, Jira, gut dokumentiert , und Granularitätsprobleme werden direkt auf der Atlassian-Seite „Delivery Vehicle“ behandelt .

Eine sehr kurze destillierte Antwort lautet:

  • Erstellen Sie eine User Story, um die kleinste Einheit einer freizugebenden Funktion zu dokumentieren (etwas, das der Kunde überprüfen, testen und validieren kann).
  • User Stories in Epics gruppieren (zugehörige kleine Funktionseinheiten)
  • Wenn es für Sie sinnvoll ist, können Sie Epics optional in „Features“ oder übergeordnete Einheiten gruppieren, die für Ihr Projekt sinnvoll sind.

Letztendlich müssen Sie definieren, ob jedes „Signoff“-Ereignis, das bei Ihrem Kunden stattfindet, auf der Ebene einer User Story, eines Epos oder etwas anderem stattfindet. Diese Bestimmung kann auf der Grundlage dessen erfolgen, wie informell oder teuer eine „Abzeichnung“ ist – je teurer und formeller der Abzeichnungsprozess ist, desto höher ist die Gruppierung, die Sie verwenden möchten.

Ein Signoff ist ein Papier mit der vollständigen Beschreibung eines Projektumfangs (oder zumindest einem sehr großen Teil der Beschreibung), das unser Kunde vollständig liest und auf der letzten Seite unterschreibt.
Wie verwaltet man den Umfang in JIRA?
AntwortenHierDatenschutz-Bestimmungen1y, 0v