Das kurzfristige Anforderungsmanagement für agile Projekte scheint mir ein gelöstes Problem zu sein.
Aus der Perspektive von Scrum werden neue Anforderungen oder Änderungen an vorhandenen Anforderungen durch User Stories bereitgestellt. Und User Stories, die unter einem Epos oder Feature zusammengefasst sind, erleichtern die Bereitstellung komplexerer Anforderungen.
Natürlich ist eine User Story technisch gesehen kein Anforderungsdokument. Es handelt sich um eine überschaubare Gruppierung von Arbeiten, die dem entspricht, was häufig als vertikaler Funktionsbereich bezeichnet wird. Der Umfang dieser Geschichten kann durch die Verwendung von Akzeptanzkriterien (AC) eindeutig definiert werden.
Obwohl User Stories keine formalen Anforderungen sind, können Sie durch Durchsuchen der User Stories eine ziemlich klare Vorstellung von den zugrunde liegenden Anforderungen erhalten. Kurzfristig.
Ich sage kurzfristig, weil mit fortschreitendem Projekt die Anzahl der User Stories zunimmt. Daher wird das Durchsuchen einer ständig wachsenden Liste von Geschichten, um eine Anforderung zu finden, mit der Zeit immer weniger effizient.
Dieses Problem wird noch verstärkt, wenn Sie User Stories berücksichtigen, die frühere Stories erweitern, ersetzen oder sogar negieren.
Stellen Sie sich nun eine 2-jährige Pause zwischen den Entwicklungsiterationen eines Projekts vor (produktionsstabil). Das ursprüngliche Team ist weg und so ist all ihr Wissen.
Wenn das ursprüngliche Team wüsste, dass dies passieren würde (z. B. aufgrund der Art des Geschäfts), welche Maßnahmen könnten sie ergreifen, um nachfolgenden Teams zu helfen?
Sicher, der Backlog wird einige Informationen liefern, aber es ist kaum in einer leicht durchsuchbaren Form.
Was kann also getan werden, damit nachfolgende Teams den Stand des Projekts verstehen, einschließlich warum und wie es dort ankam?
Nach meiner Erfahrung funktionieren die folgenden Dinge nicht:
- Backlog-Optimierung zum Löschen oder Aktualisieren früherer User Stories, sodass das Backlog als Anforderungsdokument gelesen werden kann.
- Dokumentation Sprints, in denen Teammitglieder den aktuellen Status des Systems dokumentieren müssen.
- Dokumentation durch Verhaltenstests . Dieser Ansatz ist der einzige, der meiner Arbeit sehr nahe gekommen ist. Coded Behaviour Tests sind leider Opfer des Namensproblems. Obwohl die Tests das System möglicherweise ordnungsgemäß dokumentieren, ist es fast unmöglich, ein fluktuierendes Entwicklerteam dazu zu bringen, ihre Tests nach derselben Domain-Terminologie, demselben Domain-Wortlaut und demselben Domain-Stil zu schreiben.
Also, um es noch einmal zu wiederholen:
Wie managt man Agile Projektanforderungen langfristig?
quelle
Antworten:
Dies scheint mir der unausgesprochene Elefant im Raum mit agilen Projekten zu sein: Wie verhindern Sie, dass sie sich in Chaos verwandeln?
Schauen wir uns das Agile Manifest für einen Moment an. Agile Wünsche:
Ich habe die letzten vier hervorgehoben. Warum? Weil sie verhindern, dass das Projekt unter seinem eigenen Gewicht zusammenbricht.
Nachhaltige Entwicklung bedeutet, dass Sie (hoffentlich) jemanden haben, der den gesamten Entwicklungsprozess überwacht, der das Schiff steuern kann, ohne die Software ein wenig zu erweitern, der eine übergeordnete Vision des gesamten Projekts hat, der über fundierte Kenntnisse verfügt von Softwarearchitektur, Systemdesign, Prinzipien der Geschäftslogik und Ergonomie der Benutzeroberfläche. Also ein Architekt.
Der Architekt sagt: "Ich weiß, dass Sie danach gefragt haben, aber wenn wir dieses andere Ding bauen, können wir diese anderen drei verwirrenden Merkmale vermeiden und uns auf die Kernanforderung konzentrieren." Er ist derjenige, der dem Team Zeit lässt, technische Schulden abzubauen. Er ist derjenige, der dem Projekt eine übergreifende Struktur und Organisation verleiht. Er ist derjenige, der Meetings einberuft, bei denen das Team zusammenkommt und fragt: "Wie können wir es besser machen?"
Und er ist derjenige, der das Master-Anforderungsdokument verwaltet.
In dem Buch Mastering the Requirements Process behaupten die Autoren, dass es drei Arten von Kunden und drei Arten von Softwareprojekten gibt: Kaninchen, Pferde und Elefanten. Kaninchen sind die kleinen Softwareprojekte, die nur informelle Anforderungen benötigen; Sie arbeiten direkt mit dem Kunden in kleinen Sprints, der Umfang des Projekts ist einigermaßen eingeschränkt, und die Software wird innerhalb eines relativ kurzen Zeitrahmens erstellt. Elefanten sind solche Mammutprojekte, die viel Vorausplanung, eine enorme Menge an Dokumentation und einen langen Zeithorizont erfordern. Sie sind wahrscheinlich nicht agil, obwohl Sie sie in kleinere Projekte aufteilen können, die mit agil erstellt werden können.
Es sind die Pferdeprojekte, die aus einer agilen Perspektive etwas verwirrend sind. Sie können immer noch iterativ erstellt werden, Sie können immer noch kurze Sprints verwenden, aber ohne eine gewisse Disziplin in den Prozessen der Anforderungserfassung und -planung können sie leicht von der Strecke laufen. Dies sind die Projekte, die von einem disziplinierten Anforderungserfassungsprozess und einer sorgfältigen Anpassung und Modifikation dieser Anforderungen profitieren können, wenn das Projekt wächst, wobei eine übergeordnete Vision für das gesamte Projekt beibehalten wird.
Aus persönlicher Sicht arbeite ich mit einem kleinen Team von etwa einem Dutzend Entwicklern. Zu einem bestimmten Zeitpunkt arbeiten wir möglicherweise gleichzeitig an drei Softwareprojekten, die von einigen tausend Codezeilen bis zu über 100.000 reichen. Unser Kunde hält sie für ein Kaninchen, aber für ein Pferd. Der Kunde ist engagiert, aber nicht täglich.
Unser mit Abstand schwächster Bereich ist es, spezifische, überprüfbare und messbare Anforderungen zu erfassen und die Erwartungen des Kunden in Bezug auf den Projektumfang zu verwalten. Aber wir arbeiten daran.
quelle
Die Frage ist nicht ganz klar, aber es hört sich so an, als ob Sie sich mit der Rückverfolgbarkeit von Anforderungen befassen . Eine Idee, die meiner Erfahrung nach in Agile verloren geht, ist, dass die Geschäftsanforderungen genau die sind, die der Kunde vom System verlangt , während User Stories wirklich funktionale Anforderungen sind , die die Funktionsweise des Systems angeben. "Als Benutzer möchte ich X können." Dies geschieht jedoch, um eine Anforderung zu erfüllen, die in der User Story möglicherweise verloren geht.
Was meiner Erfahrung nach gut funktioniert, ist die Verknüpfung der Geschäftsanforderungen und User Stories in beide Richtungen. BR # 1 kann durch die Geschichten A und B realisiert werden. Die Geschichte C könnte die BRs # 2 und # 3 abdecken. Fügen Sie dies in Ihren Projekt-Tracker oder Ihre Tabelle ein, ganz gleich, was Sie verwenden.
Langfristig hilft dies dabei, das, wonach der Kunde fragt, mit dem zu verknüpfen, was das System tut, um diese Anforderungen zu erfüllen. Dies sollte eine ziemlich minimale Dokumentation sein, die nicht lästig zu warten ist. Dies entspricht der agilen Denkweise, keine Dokumentation zu erstellen, die niemand benötigt, und ist eine lästige Aufgabe, um auf dem neuesten Stand zu bleiben.
Es bietet auch eine Möglichkeit für neue Projektmitglieder, sich zu beschleunigen, da sie etwas zu überprüfen haben, um den Verlauf zu ermitteln, warum die Software das tut, was sie tut.
quelle
Ich arbeite gerade in einem Kanban-Wartungsprojekt eines großen Webshops, in dem die ursprünglichen Entwickler nicht mehr verfügbar sind.
Jede UserStory / Requirement / Bugfix hat eine Ticketnummer und jede Sourcecode-Änderung ist mit einer Ticketnummer im Sourcecontrol-Kommentar-Feld verknüpft.
sourcecontrol-checkin-s (svn) aktualisiert das entsprechende Ticket automatisch, sodass ich im Ticket einen Link zu allen sourceconrtol-changesets habe.
Wenn ein Modul / eine Funktion neu implementiert wird, enthält der Quellcode auch Ticketnummern.
Im Ticket-System (redmine) sind die Tickets untereinander verknüpft als (ist doppelt, ist fehlerhaft, ist Verfeinerung von, ....)
So können Sie die Tickets verfolgen und Änderungen der Anforderungen im Laufe der Zeit beobachten.
Beispiel: Ich muss etwas in die "orderConfirmation-Web-Seite" tippen. Im Quellcode der Seite sehe ich einen Kommentar: 'Erstellt für "# 4711"', damit ich mein neues Ticket mit dem alten Ticket "4711" oder einem seiner Nachfolger verknüpfen kann.
quelle
Persönlich verwerfe ich die User Stories als Dokumentationsquelle darüber, was das System tun kann. Sofern keine aktiven Schritte unternommen wurden, um eine Dokumentation zu erstellen (die wir für einige unserer traditionelleren Kunden durchgeführt haben), ist die Anwendungsbasis wirklich die beste Dokumentation, die es gibt.
Das ist aber nichts Neues.
Wenn Sie eine skaliertere Version von Agile (wie SAFe ) verwenden, haben Sie andere Backlogs, die nicht das Implementierungs-Backlog sind. Es sieht im Grunde so aus:
Ich würde nicht empfehlen, auf Team Backlog-Ebene zu dokumentieren. Es ist zu detailliert und selten möchte jemand auf diese Detailebene gehen. Ganz zu schweigen davon, dass es in einem Release möglicherweise Storys gibt, die im Widerspruch zu früheren Storys im Team-Backlog stehen.
Stattdessen würde ich empfehlen, auf der Ebene Ihres Release-Backlogs zu arbeiten, um Dokumentation auf Release-Ebene bereitzustellen. Diese Storys werden nur selten ausgeblasen, wenn sie einer bestimmten Version zugewiesen wurden. Sie bieten eine stabile und schnelle Möglichkeit, zu überprüfen, an was in einer bestimmten Version gearbeitet wird.
quelle