Wie kann ich Informationen von einem Wasserfallkunden in ein agiles Projekt integrieren?

Wir machen gerade ein agiles Projekt, bei dem der Kunde weniger agil ist als wir eigentlich gehofft hatten (er bleibt bei Wasserfall). Auch wenn eine offizielle Anforderungsspezifikation existiert, wird sie leider nicht vom Kunden aktualisiert (Timing-Probleme, was auch immer), also sieht unser aktueller Prozess, um die benötigten Informationen zu erhalten, wie folgt aus:

  • Um die Anforderungen richtig zu erfüllen, sammeln wir Fragen zu den „Epics“, die wir in einem Wiki (Confluence) identifiziert haben.
  • Für jedes Epic exportieren wir diese Fragen in eine Word-Datei und senden sie an den Kunden
  • Der Kunde kommentiert diese Fragen und sendet sie zurück
  • Wir kopieren die Kommentare aus der Word-Datei zurück in das Wiki und kommentieren sie weiter oder schließen die Fragen, schließlich senden wir aktualisierte Epic-Exporte zurück an den Client

Der Grund, warum wir versuchen, diese Informationen im Wiki zu halten, ist, dass wir einen zentralen, durchsuchbaren Ort haben möchten, an dem alle Projektanforderungen geklärt und detailliert beschrieben werden (keine Word-Dokumentenhölle). Darüber hinaus schreiben wir derzeit auch unsere Systemspezifikation im selben Wiki, was uns die Möglichkeit gibt, Kundenantworten / -anforderungen auf die von uns definierten funktionalen Anforderungen zu beziehen und vieles mehr.

Offensichtlich gibt es bei diesem Ansatz jedoch mindestens ein Problem: Das händische Abschreiben von Antworten und das immer wieder Exportieren von Fragenkatalogen. Dies, gepaart mit dem Problem, dass immer eine Art "externes" vereinbartes Dokument vorhanden sein muss, auf das später verwiesen werden kann, falls etwas schief geht, bereitet uns große Kopfschmerzen.

Ich weiß, dass Leute in der Vergangenheit Aktionspunktlisten für solche Dinge verwendet haben, aber das entspricht überhaupt nicht unseren Erwartungen an das Finden von Informationen. Andererseits wird ein Wiki, das seiner Natur nach jederzeit editierbar ist, sicherlich auch nicht der Anforderung „vereinbartes Dokument“ entsprechen.

Also, was sind einige gültige Techniken, um diese Dinge besser zu machen (sogar richtige Werkzeugunterstützung?!) Oder sind Sie bereits weggelaufen, nachdem Sie den ersten Absatz dieser Frage gelesen haben?

Die Frage, wie sie derzeit geschrieben ist, klingt so, als würden Sie um Dienstleistungen bitten. könnten Sie die Frage expliziter stellen? Könnten Sie das Koordinationsdokument an die Wiki-Seite anhängen (oder explizit importieren)?
Nein, ich bitte nicht um Dienstleistungen; Ich suche nach Best Practices von anderen Leuten, die mit ähnlichen Problemen bei der Verwaltung von Anforderungen mit „Wasserfall“-Kunden und agilen Workflows konfrontiert waren.
Relevant, aber keine Antwort: Sie können innerhalb des Wasserfalls nicht agil arbeiten, da es keinen Sinn macht, Änderungen in einem Rahmen zuzulassen/zu erwarten, der dies nicht zulässt. Ich vermute, dass die Probleme, mit denen Sie jetzt konfrontiert sind, nur die Spitze des Eisbergs sind.
@Sklivvz Ja, ich weiß, es stehen weitere Probleme bevor. Wir arbeiten grundsätzlich agil in einem ummauerten Garten, um unsere eigenen Planungsbedürfnisse zu befriedigen. Ich bin ein überzeugter Anhänger von Agilität, aber manche Kunden lassen sich einfach nicht davon überzeugen, dem Beispiel zu folgen.
Einfach gesagt, Sie tun es nicht. Es geht nicht darum, der Spur zu folgen – manchmal ist der Kunde gewohnt / muss Wasserfall verwenden (wie große Unternehmen, die Tonnen von Bürokratie erfordern). Denken Sie andersherum: Klingt vernünftig, wenn jemand versucht, Ihre agilen Projekte in ein Wasserfallmodell zu überführen? Ich glaube, beide Modelle haben Vor- und Nachteile ... es hat keinen großen Wert, ein Einheitsmodell zu haben.
Wann ist in Ihrem bestehenden Plan die früheste Gelegenheit für Ihren Kunden, ein Mockup, eine Demo oder eine Betaversion zu sehen?

Antworten (2)

Dies ist ein häufiges Problem bei den meisten Methoden. Sich ändernde Anforderungen nachzuverfolgen und zu dokumentieren ist schwierig. Änderungen an den Anforderungen müssen sowohl dem Kunden als auch dem Entwicklungsteam zugesprochen werden. Und beide werden wahrscheinlich Änderungen an den Anforderungen vorantreiben. Wenn der Kunde Big Upfront Design anstelle von Waterfall durchgeführt hat, ist es weniger wahrscheinlich, dass er Änderungen vorantreibt.

Wie Sie feststellen, generiert das Entwicklungsteam Anfragen zur Klärung der Anforderungen. Der Kunde kann auch wechselnde Anforderungen haben. Dies wird üblicherweise durch einen Änderungskontrollprozess behandelt.

Sie werden vielleicht feststellen, dass es besser funktioniert, den Dokumentenfluss zwischen dem Team und dem Kunden in einem Textformat zu halten. Die Kommunikation über E-Mail-Nachrichten kann den Informationsfluss erleichtern. Abhängig von den erhaltenen Antworten kann es angebracht sein, die Antwort auszuschneiden und in das Anforderungsdokument einzufügen. Andere Änderungen können zu Änderungen der Anforderungen führen. In jedem Fall sollten Sie in der Lage sein, die aktuellen Anforderungen zu den ursprünglichen Anforderungen und allen genehmigten Änderungen zurückzuverfolgen.

Häufiger um Klärung zu bitten, kann dazu beitragen, Reibungsverluste im Veränderungsprozess zu verringern. Das Hinzufügen der Änderungen und Antworten zu einem Fehler-/Problem-/Aufgabenverfolgungssystem kann ebenfalls auf verschiedene Weise hilfreich sein. Mit dem entsprechenden Arbeitsablauf können Sie die Änderungen über ihren Lebenszyklus hinweg verfolgen. Es kann einfacher sein, den Kunden dazu zu bringen, das Problemverfolgungstool zu verwenden, als das Wiki zu aktualisieren.

Das war auch hier eine meiner Optionen, wir haben einen Issue-Tracker (Jira) eingerichtet, der später bei der Entwicklung verwendet wird. Mein Gedanke war, dass vielleicht schon jemand versucht hat, Anforderungen mit Hilfe eines Issue-Trackers zu verhandeln / zu klären und mir sagen würde, ob das gut funktioniert (z sieht es nach einiger Zeit durch).
@ThomasKeller Der Workflow sollte darin bestehen, die Dokumentation basierend auf der Problemantwort zu aktualisieren, bevor das Problem geschlossen wird. Wenn Sie das Anforderungsdokument mit dem Problem verknüpfen können, können Sie möglicherweise feststellen, welche Anforderungsdokumente die meisten Änderungen aufweisen. Es wäre auch eine gute Idee, auf das Problem im Kommentar zur Aktualisierung der Anforderungen hinzuweisen.

Ich bin mir immer noch nicht sicher, ob ich die Frage/das Problem verstehe, und der Kommentar von @skilwz lässt mich glauben, dass dies ein X: Y-Problem sein könnte. Es wird Turbulenzen und Reibungen geben, wenn sich Ihr Kunde dem Wasserfall verschrieben hat und Sie sich der Agilität verschrieben haben. Das eigentliche Problem können unterschiedliche Vorstellungen davon sein, wie man mit Veränderungen und Umfang umgeht. Ich vermute auch, dass dies ein Verstoß gegen das Gesetz von CodeGnome ist - Sie maskieren eher die technologische Implementierung als das Kernproblem. (Keiner dieser Kommentare ist eine Kritik an Ihnen; die Situation ist, wie sie ist, und Sie versuchen, sich so gut wie möglich zurechtzufinden.)

Wie ich es verstehe, verwalten Sie Änderungen, aber Ihr Kunde nimmt nicht am Änderungsverwaltungsprozess teil. Da schrillen bei mir einige Alarmglocken, die nichts mit Agilität/Wasserfall/was auch immer zu tun haben. Die Loslösung des Kunden vom Change- und Scope-Management beschäftigt mich grundsätzlich. Wenn es möglich gewesen wäre, dieses Problem zu lösen, hätten Sie es sicher getan. Gehen wir also davon aus, dass Sie keine Möglichkeit haben, dieses Problem zu beheben.

Ausgehend von dieser Annahme haben Sie den defensiven Schritt unternommen, Ihren Kunden offiziell um die Teilnahme am Änderungsmanagement zu bitten und die Eingaben des Kunden offiziell aufzuzeichnen. Ich denke, es gibt zwei Ziele

  1. Integrieren Sie den Input des Kunden trotz der Zurückhaltung des Kunden effektiv in den Änderungskontrollprozess.
  2. Stellen Sie sicher, dass Sie eine formelle Rückverfolgbarkeit vom Kundeneingang bis zu den Anforderungen haben.

Der Wunsch nach formaler Rückverfolgbarkeit lässt die Alarmglocken laut werden, aber dagegen können wir nichts tun.

Meine erste Priorität wäre sicherzustellen, dass das Team das Problem und die Lösung versteht. Wenn das Team das Problem nicht versteht, spielt es keine Rolle, wie ausgeklügelt die technologische Umsetzung ist.

Dann würde ich das Antwortdokument des Kunden (was ich das "epische Word-Dokument" nennen würde) importieren oder an die Wiki-Seite anhängen. (je nachdem, was Ihr Wiki unterstützt) und bauen Sie Links von Ihren Anforderungen zu seinen Kommentaren auf.

Entschuldigen Sie die langatmige Antwort, aber die Randfragen beschäftigen mich mehr als die Kernfrage.

Ich würde hier nur eine winzige Änderung vornehmen: "Sie maskieren eher die technologische Umsetzung als das Kernproblem". +1!
Habe die vorgeschlagene Änderung vorgenommen.
Haha, Entschuldigung! Ich meinte, dass es aus meiner Sicht eine Maskierung wäre ... aber das war nur ich :D
Vielen Dank für Ihre Antwort, das war nicht das, was ich von meiner Frage erwartet hatte (und löst mein unmittelbares Problem nicht), aber es war sicherlich hilfreich, um einen zweiten Blick auf das Projekt zu werfen. Bei uns läuten unsere eigenen Glocken und wir haben uns vorerst mit dem Kunden auf eine formellere Art der Kommunikation geeinigt. Dies ist nicht ideal und zeitaufwändig, aber es funktioniert. Ich bin es in den letzten Jahren gewohnt, 100% agile Projekte zu machen (mit zufriedenen Kunden), also kam der Rückschlag zum Wasserfall auch für mich völlig unerwartet, also musste ich mich schnell anpassen.
Wie kann ich Informationen von einem Wasserfallkunden in ein agiles Projekt integrieren?
AntwortenHierDatenschutz-Bestimmungen1y, 0v