Benötigen Sie Hilfe – Dokumentation für nicht-technische Personen, die Agile verwenden

TL;DR

Es gibt keine Wunderwaffe. Es ist jedoch wahrscheinlich, dass Ihr Unternehmen einen umfassenderen Satz agiler Tools und Praktiken einführen muss, um unnötige oder aufwändige Dokumentation zu reduzieren.

Agile Praktiken liefern oft eine bessere Dokumentation

Ihre Frage ist möglicherweise zu weit gefasst, um sie zu beantworten, aber ich werde mich auf den Weg machen und vermuten, dass Ihre Organisation kürzlich zu „Agil“ (was auch immer die Organisation meint, das bedeutet) übergegangen ist, ohne das vollständige Framework tatsächlich übernommen zu haben oder ohne Implementierung gängiger agiler Praktiken wie Test-Driven Design (TDD) oder Behavior-Driven Development (BDD). Dies ist wahrscheinlich die Ursache Ihres Problems.

Agile Frameworks schätzen funktionierende Produkte gegenüber umfangreicher Dokumentation. Das Agile Manifest sagt:

Funktionierende Software statt umfassender Dokumentation...[T]hier ist Wert in den Elementen rechts, [aber] wir schätzen die Elemente links mehr.

Das bedeutet nicht, dass agile Teams nichts dokumentieren. Tatsächlich erstellen leistungsstarke Agile- und DevOps-Teams oft nützlichere Dokumentationen als vor der Einführung agiler Praktiken. Dies liegt im Allgemeinen daran, dass:

1. „Lebende Dokumentation“, wie gut kommentierter und häufig umgestalteter Code, ist oft genauer als tote Baumhieroglyphen aus der nebligen Morgendämmerung der Zeit, als die ursprünglichen Anforderungen höchstwahrscheinlich generiert wurden.
2. Wenn sie richtig geschrieben sind, lesen sich TDD/BDD/ATDD-Tests wie eine Dokumentation in natürlicher Sprache und enthalten oft Begriffe und Konzepte aus der Geschäftsdomäne des Produkts und aus der Sicht eines Benutzers.
3. Kontinuierliche Integration mit guten Tests stellt sicher, dass Ihre Dokumentation sowohl aktuell als auch genau bleibt , was etwas ist, an dem die meisten traditionellen Projekte kläglich scheitern.
4. Endbenutzer- oder Systemdokumentation (sofern tatsächlich benötigt) wird häufig programmgesteuert aus Codekommentaren, ausführbaren Tests, API-Signaturen usw. kompiliert. Hinweis: Dies erfordert sowohl bewährte Praktiken als auch gute Tools.
5. Jede notwendige Dokumentation, die nicht selbst generiert wird, sollte Teil der Definition of Done für jedes Product Backlog Item (PBI) und das Inkrement der Iteration sein.

In Scrum sollten Sie bei jeder Iteration nachweisbare Arbeitsinkremente haben. Dies ist oft wertvoller als tote Bäume, da es ein potenziell lieferfähiges Inkrement darstellt und etwas, das die Beteiligten sehen (und oft berühren) können.

Maximieren Sie den Arbeitsaufwand , indem Sie unnötige Dokumentation eliminieren, und konzentrieren Sie sich auf die Implementierung von Praktiken, die wirklich wesentliche Dokumentationsaufgaben auf ein überschaubares Maß reduzieren.

FRD ist eine Möglichkeit, (in einem Wasserfallverfahren) zu dokumentieren, was die beabsichtigten funktionalen Anforderungen sind. Dies dokumentiert normalerweise nicht die tatsächliche Implementierung. Mit agilen Methoden können Sie nicht-technischen Mitarbeitern besser vermitteln, was tatsächlich geliefert wird. Hier sind einige Vorschläge, um eine umfassende Dokumentation zu ermöglichen und gleichzeitig agil und produktiv zu bleiben:

1. Lassen Sie die technischen Redakteure Teil des Projektteams sein und iterativ technische und nichttechnische Produktdokumentationen erstellen. Sie können „Produktdokumentation abgeschlossen“ als Akzeptanzkriterium für Ihre User Stories hinzufügen. Die offizielle Produktdokumentation kann Ihr lebendes Dokument sein.
2. Halten Sie vor der Markteinführung eine High-Level-Demo ab (über Ihren Produktmanager). Diese High-Level-Demo kann Marketing-, Vertriebs- und Abteilungsleitern helfen, zu verstehen, was geliefert wird. Sie könnten dies zu Ihren Sprint-Review-Prozessen hinzufügen.
3. Fügen Sie Ihrer Checkliste für die Bereitstellung von Launches eingehendere interne Schulungsüberlegungen hinzu, damit Sie sie für jeden Sprint oder jede Version berücksichtigen können. Sie können Epics oder Storys kennzeichnen, die internes Training erfordern und wer für die Durchführung des Trainings verantwortlich sein sollte.
4. Veranstalten Sie detailliertere interne Schulungen (z. B. „Train the Trainer“) für interessierte interne Stakeholder (z. B. Kundensupport und Trainer). Nehmen Sie diese auf und halten Sie das Video für Interessierte bereit. Fügen Sie einen Link des Videos zu Ihrer Projektreferenzdokumentation hinzu. Die interne Schulung kann sehr hilfreich sein, um Trends in Fragen zu erkennen, die Sie möglicherweise in der offiziellen Produktdokumentation beantworten möchten.

Mir fallen auf Anhieb 3 Möglichkeiten ein, Ergebnisse und Anforderungen zu kommunizieren:

1. Laden Sie Stakeholder zum Sprint Review oder vielleicht zum Daily Stand Up ein
2. Zeigen Sie Interessenvertretern die Informationen zu Ihrem Produkt Strahler

3. Aktualisieren Sie den Wiki- /Slack-Kanal des Produkts:

   • Einen Überblick über die Ergebnisse/KPI/Anforderungen des Produkts haben, die von Anfang an bekannt sind (mit Folien oder anderer Dokumentation)

   • Konzentrieren Sie Übersichten auf die Bereitstellung von Wert (gewinnen Sie: $ / Benutzerinformationen / usw. und reduzieren Sie: Kosten) und teilen Sie sie nach Bedarf

   • Lassen Sie Teammitglieder zusätzliche Details und Übersichten der Funktionen hinzufügen, wenn sich das Produkt weiterentwickelt und neue Informationen auftauchen

Wenn Agilität neu in Ihrer Kultur ist, stellen Sie sicher, dass die Kommunikation mit den Stakeholdern über den Product Owner und/oder den Scrum Master läuft . Diese beiden Rollen stellen sicher, dass das Entwicklerteam nicht von Außenstehenden entgleist wird.

Viel Glück!