Wie erfasst man Kundenanforderungen?

Agile bietet 3 Möglichkeiten, diesen Fehler vor der Produktion abzufangen

1. Die Abhängigkeit hätte in den Akzeptanzkriterien erfasst werden sollen : Wenn Story B geschrieben ist, hätte sie mit Story A zurückverknüpft werden sollen. Und Akzeptanzkriterien hätten geschrieben werden sollen, um dies zu erfassen.

2. Unit-Test sollte brechen : Auch wenn nicht alle Agile-Teams Unit-Tests schreiben, versucht Agile, die Engineering-Praktiken zu verbessern. Test Driven Development (TDD) ist eine Schlüsselpraxis des Extreme Programming.

3. Agile Entwicklungsteams sind aktiv damit beschäftigt, zu verstehen, warum eine Geschichte benötigt wird : Ich bin mir nicht sicher, ob dies typisch ist. Einige der Waterfall-Entwicklerteams, die ich gesehen habe, konzentrieren sich jedoch mehr darauf, das auszuführen, was der Kunde verlangt. Der Ansatz scheint zu sein, dass der Kunde es haben kann, wenn er es will und bereit ist, dafür zu bezahlen. Auf der anderen Seite arbeiten agile Entwicklungsteams Hand in Hand mit dem Product Owner, um Benutzergeschichten und Akzeptanzkriterien zu schreiben, um gemeinsam vereinbarte Geschäftsziele zu erreichen. Daher neigen sie dazu, die Wünsche eines Product Owners in Frage zu stellen, wenn es keinen Sinn ergibt.

Im Allgemeinen gibt es bei Agile häufig Retrospektiven. Auch wenn sich einige dieser Fehlertypen in die Produktion eingeschlichen haben, sollten sie im Nachhinein aufgedeckt werden und es bieten sich Möglichkeiten für praktische Prozessverbesserungen.

Was Sie brauchen, ist eine formelle Änderungskontrolle.

Sie beginnen damit, die Anforderung in einer Änderungsanforderung zu erfassen. Darin sollte alles aufgeführt sein, was der Kunde ändern möchte. Wenn die Änderung erheblich ist, kann auch die Verwendung einer separaten Anforderungsspezifikation erforderlich sein, auf die jedoch in der Änderungsanforderung noch verwiesen wird.

Nach der Übermittlung an den Anbieter muss der Anbieter die Kosten und Auswirkungen der Änderung bewerten. Typischerweise würde die Änderungsanforderung die Runde in mehreren verbundenen Abteilungen/Teams machen, wie z. B. Entwicklung, Tests, Hardware/Infrastruktur, MI usw. Jedes Team ist in der Lage, die Auswirkungen der Änderung auf seinen Bereich einzuschätzen – Entwickler müssen die Änderung codieren , Tester müssen Testskripte schreiben und System- und Integrationstests durchführen, MI muss herausfinden, ob sich die Änderung auf einen Data Warehouse-Feed und nachfolgende Berichte auswirkt, und die Zeit zum Ändern der Feeds und Berichte abschätzen und so weiter.

Wenn jedes Team die Auswirkungen (die Entwickler würden die Regressionsprobleme aufgreifen) und die Kosten in Bezug auf den Bereitstellungsaufwand bewertet haben, werden die Kosten und Auswirkungen mit dem Kunden in einem Change Board besprochen. Wenn der Kunde die Kosten und Auswirkungen akzeptiert, darf die Änderung in ein Release eingeplant werden.

Wenn Sie einen agilen Entwicklungsprozess betreiben, bin ich mir nicht sicher, ob dies zutrifft, aber es ist sicherlich so, wie wir Dinge in einer kontrollierten Wasserfallumgebung tun.

Eine Möglichkeit, Anforderungen zu erfassen, besteht darin, sie mit so vielen Details wie möglich in ein Dokument (Word/PDF) zu schreiben. Erwähnen Sie die genannten Anforderungen, stellen Sie ggf. ein Drahtgitterdiagramm bereit und geben Sie auch Ihre Annahmen in den Anforderungen an. Und lassen Sie sich vom Benutzer/Kunden schriftlich abmelden.

Normalerweise sollten solche Anforderungsdokumente auf einem gemeinsamen Portal (Sharepoint, Jira) geteilt werden, auf das Ihr IT-Team und die Benutzer Zugriff haben.

Dieser Freigabe- und Freigabemechanismus stellt sicher, dass der Kunde der Anforderung zugestimmt hat, und Sie können für jede Änderung der Anforderungen zusätzliches Geld in Rechnung stellen

Im besten Fall haben Sie alle Geschäftsfähigkeiten dokumentiert, die der Kunde im Vertrag wünscht. Dies hat mehrere Vorteile für beide Seiten:

• Der Anbieter (Sie) hat eine klare Vorstellung davon, was der Kunde will, und kann entsprechende Ressourcen zuweisen, um es zu liefern.
• Der Kunde hat ein gewisses Maß an Vorhersehbarkeit in Bezug auf Kosten und Lieferzeitrahmen.
• Beide Parteien haben ein gemeinsames Verständnis darüber, was Endpunkte, Meilensteine ​​usw. sind.

Ausgehend von den im Vertrag dokumentierten Geschäftsfähigkeiten können Sie dann die Entwicklung von Anforderungsdokumenten gemäß ViSu durcharbeiten, aber Sie müssen zuerst den Vertrag in Kraft haben, um sich vor Scope Creep zu schützen.

Wir verwenden ein Formular mit dem Namen Änderungsanforderungsformular, um die Änderungsanforderung des Kunden zu verfolgen. Jeder Anfrage wird eine eindeutige Nummer, ein Änderungsbereich usw. zugewiesen.

Der Kunde füllt die Änderungsanforderung im Änderungsanforderungsformular aus. Wir bewerten die Änderungsanfrage, bereiten ein Verständnisdokument vor und leiten es zur Bestätigung an den Benutzer zurück. Nach Bestätigung des Benutzers leiten wir den Änderungsprozess ein.

Wir speichern diese Änderungsanforderung und das Verständnisdokument in einem intern entwickelten System und fügen dem Code eine eindeutige Änderungsanforderungsnummer hinzu, damit das Team später darauf zugreifen kann.

Die Änderungskontrolle hilft nicht, wenn Sie keine solide Dokumentation haben, mit der Sie beginnen können.

Ich würde vorschlagen, Business Requirements Documents (BRD) und Systems Requirements Specifications (SRS) als Referenz nachzuschlagen.

Ja, Kundenanforderungen sollten dokumentiert und nachverfolgt werden. Jede Änderungsanforderung oder Aktualisierung sollte dazu führen, dass die Originaldokumente geändert werden, damit sie den neuen Anforderungen entsprechen, und sicherstellen, dass alle Auswirkungen analysiert wurden.