Anforderungsverfolgung in Agile?

Wenn eine Organisation reguliert ist, hat sie das Audit bestanden und gezeigt, dass sie eine „Anforderungsverfolgbarkeit“ implementiert hat. Das heißt, es hat den Weg von der spezifischen Anforderung über eine Codeänderung bis hin zu einem funktionierenden Produkt in der Produktion dokumentiert. So verstehe ich es zumindest.

Wie funktioniert das in Agile/Scrum? Derzeit ist die einzige Möglichkeit, wie ich gesehen habe, dass dies implementiert ist, wie folgt:

  1. Jede Änderung, egal wie groß oder klein, muss ein Ticket in einem Tracker wie Jira haben.
  2. Dieses Ticket muss alle Anforderungen einer Spezifikation erfüllen, bevor es implementiert wird.
    • Das bedeutet Dinge wie detaillierte Akzeptanzkriterien und Zeitschätzungen.
  3. Bei der Implementierung müssen Änderungen am Code die Tracker-ID der Anforderung enthalten. Entweder im Commit selbst oder im überprüften Pull-Request.
  4. Das Ticket im Tracker muss einem vordefinierten Prozess von Schritten von Grooming, In Dev, In QA bis hin zu Done folgen.

Als XP-Person finde ich das extrem erstickend. Wenn ich einen Ort finden würde, an dem ich eine Verbesserung vornehmen könnte, müsste ich diesen ganzen Prozess durchlaufen, um ihn umzusetzen. Dieser Prozess kann leicht Tage oder sogar Wochen dauern (ich meine in Echtzeit, nicht Aufwandszeit, viel Wartezeit zwischen Pflege, Planung und Umsetzung). Auch wenn der Wechsel selbst vielleicht 30 Minuten dauert. Ich verstehe die Notwendigkeit dieser Art von Dokumentation, aber ich kenne mich mit diesem speziellen Gesetz nicht gut genug aus, um herauszufinden, ob dies akzeptabel ist oder nicht.

Ist mein Verständnis dieses Problems richtig? Gibt es andere Möglichkeiten, die Rückverfolgbarkeit von Anforderungen für regulierte Organisationen zu implementieren, die keinen so großen Overhead haben? Oder sollte ich damit leben lernen?

Antworten (2)

Ihr Verständnis von Rückverfolgbarkeit ist richtig. Die Idee besteht darin, die Funktionalität von der Quelle bis zur Implementierung und Bereitstellung zu verfolgen, um festzustellen, ob das System die erforderliche Funktionalität implementiert.

Jede Änderung, egal wie groß oder klein, muss ein Ticket in einem Tracker wie Jira haben.

Das ist einigermaßen richtig. Tools wie Jira, die mit Versionskontrollsystemen und Dokumentationstools integriert sind, erleichtern die Rückverfolgbarkeit aufgrund dieser Integrationen, aber die Rückverfolgbarkeit erfordert keine speziellen Tools. Es ist denkbar, dass Sie Anforderungen in einem Dokument oder einer Tabelle aufbewahren und eindeutige IDs verwenden, um Commits und Pull-Requests nachzuverfolgen.

Dieses Ticket muss alle Anforderungen einer Spezifikation erfüllen, bevor es implementiert wird. Das bedeutet Dinge wie detaillierte Akzeptanzkriterien und Zeitschätzungen.

Die Spezifikationsebene in der Arbeitsaufgabe variiert. Für die Rückverfolgbarkeit von Anforderungen sind Schätzungen überhaupt nicht erforderlich. Ich würde erwarten, dass das Problem im Problemverfolgungssystem in sich geschlossen ist und einen einfachen Zugang zu Dingen wie den Akzeptanzkriterien bietet, entweder durch Aufnahme oder Bezugnahme. Ich würde die Merkmale guter Anforderungen und die INVEST-Kriterien berücksichtigen .

Bei der Implementierung müssen alle Änderungen am Code die Tracker-ID der Anforderung enthalten.

Dies ist normalerweise keine Anforderung. Beispielsweise weist Jira jedem Vorgang eine eindeutige ID zu. Jira ermöglicht auch das Verknüpfen des Vorgangs mit dem Pull-Request und den Pull-Request zurück mit dem/den Vorgang(en). Wichtig ist die Verknüpfung. Wenn Sie sich eine Codezeile ansehen können, finden Sie den Commit, der sie eingeführt hat, gehen Sie zu dem Commit oder der Pull-Anfrage, wo sie hinzugefügt wurde, und finden Sie das Problem, das die Anforderung für diese Arbeit darstellt (und umgekehrt, von Anforderung zu Zeilen des Codes), Rückverfolgbarkeit erfüllt ist.

Das Ticket im Tracker muss einem vordefinierten Prozess von Schritten von Grooming, In Dev, In QA bis hin zu Done folgen.

Obwohl dies hilfreich ist, sollte der Workflow im Issue-Tracking-System den tatsächlichen Prozess widerspiegeln und für das Team nützlich sein. Tools wie Jira pflegen einen Verlauf für jedes Problem – wer hat welche Felder, Kommentare und Diskussionen aktualisiert, Verknüpfungen zwischen verwandten Problemen, um Abhängigkeiten und Zerlegungen anzuzeigen.

Als XP-Person finde ich das extrem erstickend. Wenn ich einen Ort finden würde, an dem ich eine Verbesserung vornehmen könnte, müsste ich diesen ganzen Prozess durchlaufen, um ihn umzusetzen. Dieser Vorgang kann leicht Tage oder sogar Wochen dauern. Auch wenn der Wechsel selbst vielleicht 30 Minuten dauert. Ich verstehe die Notwendigkeit dieser Art von Dokumentation, aber ich kenne mich mit diesem speziellen Gesetz nicht gut genug aus, um herauszufinden, ob dies akzeptabel ist oder nicht.

Ist mein Verständnis dieses Problems richtig? Gibt es andere Möglichkeiten, die Rückverfolgbarkeit von Anforderungen für regulierte Organisationen zu implementieren, die keinen so großen Overhead haben? Oder sollte ich damit leben lernen?

Wenn Sie Tools verwenden, die angemessen und richtig konfiguriert sind und den Prozess erleichtern, sehe ich nicht ein, warum die Rückverfolgbarkeit von Anforderungen „Tage oder sogar Wochen“ dauern sollte. Abhängig von Ihrer Wahl der Tools können einige Aspekte der Rückverfolgbarkeit einfach aus der Art und Weise, wie Sie die Tools verwenden, „herausfallen“.

Der letzte Satz klingt für mich wie: "Wenn du Dinge effektiv machst, werden sie effektiv sein." Nicht sehr hilfreich. Aber danke für die Antwort. Sie scheinen meiner letzten Behauptung zuzustimmen, dass dies etwas ist, was notwendig ist und etwas, womit ich leben sollte, ja?
@Euphoric Es ist eher wie "Wenn Sie Ihre Tools effektiv konfigurieren, können sie Ihren Prozess unterstützen, anstatt ihn zu behindern". Rückverfolgbarkeit ist erforderlich, muss aber nicht schmerzhaft sein. Ich habe Schwierigkeiten, mir eine Situation vorzustellen, in der Sie Tage oder Wochen warten müssen, um die Rückverfolgbarkeit herzustellen. Scheint, als ob es sich um Verschwendung oder Ineffizienzen in anderen Prozessen handelt.
Ich sehe das Problem bei wünschenswerten Codeänderungen (Refactoring, Beseitigung technischer Schulden), die nicht durch Kundenanforderungen ausgelöst werden. Sie müssen mit dem Kunden vereinbaren, dass diese technischen Anforderungen im Rahmen der laufenden Codepflege auftauchen und wie Kundenanforderungen behandelt werden. Dies erfordert ein gewisses Maß an Vertrauen in das Entwicklerteam, dass sie keine unerwünschten Änderungen einschleusen, die als notwendige Refactorings getarnt sind ...
@Hans-MartinMosner Es gibt zwei Möglichkeiten, damit umzugehen. Eine davon ist, es als Standardgeschäft zu betrachten – wenn Sie neue Funktionen entwickeln, können Sie diese umgestalten. Natürlich möchten Sie sich auf die Bereiche konzentrieren, die von der gewünschten Änderung betroffen sind. Die andere wäre, ein Arbeitselement / Ticket / Problem einzugeben, um eine Reihe von Refactorings durchzuführen und dies genau wie eine Kundenanforderung zu behandeln, die unabhängig geliefert wird.
Gibt es eine Möglichkeit, die Confluence-Designdokumentation als Teil des Rückverfolgbarkeitsberichts zu haben?

Behavior Driven Development (BDD) kann eine gute Möglichkeit sein, den Aufwand für die Rückverfolgbarkeit von Anforderungen zu reduzieren.

Der Ansatz ist wie folgt:

  • Anforderungen werden von den Stakeholdern/Product Owner generiert
  • Die „drei Amigos“ (die Business, Entwicklung und Test repräsentieren) kommen zusammen und erstellen Features und Szenarien, die den Anforderungen entsprechen und diese konkretisieren
  • Typischerweise werden Tests geschrieben, um zu bestätigen, dass die Funktionalität implementiert wurde

Mit diesem Ansatz ist es relativ einfach, die Rückverfolgbarkeit von Anforderungen hinzuzufügen.

Sie können argumentieren, dass der selbstdokumentierende Charakter von BDD ausreichend ist, oder Sie müssen möglicherweise noch IDs hinzufügen, wenn Ihre Organisation dies erfordert.

Natürlich ist immer noch Aufwand damit verbunden, aber es ist ein nützlicher Aufwand, der dabei hilft, ausgearbeitete Anforderungen zu erstellen, gründliche Regressionstests zu ermöglichen und selbstdokumentierten Code zu erstellen, mit dem einfacher zu arbeiten ist.

Anforderungsverfolgung in Agile?
AntwortenHierDatenschutz-Bestimmungen1y, 0v