Kurze Releasezyklen oder Releases-on-Demand? Der Usus in der technischen Entwicklung (Systems Engineering) geht eher in Richtung ein oder maximal zwei Releases pro Jahr. Ein häufiger Grund dafür, den wir in unseren Kundenprojekten beobachten, ist, dass die Dokumentation nicht auf dem aktuellen Stand ist und damit – zumindest in Bereichen, in denen die Dokumentation regulatorisch für ein Release erforderlich ist – kein Release stattfinden kann. Den ersten wichtigen Schritt, um dem entgegenzuwirken haben wir bereits im letzten Blogbeitrag unserer Serie zum agilen Systems Engineering beschrieben. Nämlich die systemische, gesamtheitliche Betrachtung dessen, was dazu erforderlich ist, um das Produkt auf den Markt zu bringen, z.B. eben die Dokumentation. Ein konkreter Ansatz, dem das Verständnis der Dokumentation als Teil des Produktes zu Grunde liegt, ist Continuous Documentation. Das Ziel: Die Dokumentation zu jedem Zeitpunkt der Entwicklung in einem potenziell releasebaren Stand zu halten, um dadurch den Gedanken des auslieferbaren Inkrements der agilen Softwareentwicklung auch im technischen Umfeld zu erfüllen.
Grundsätzlich sollten Sie sich jedoch ein paar Fragen stellen, bevor Sie mit Continuous Documentation loslegen:
- Ist ein solcher Ansatz in Ihrem Unternehmenskontext erforderlich (lesen Sie hierzu auch den ersten Blogbeitrag unserer Serie)? Muss jedes Inkrement potenziell auslieferbar sein?
- Welche Dokumentation ist in Ihrem Kontext regulatorisch gefordert, welche nicht?
- Welche Dokumentation ist zwar nicht regulatorisch erforderlich, unterstützt Sie aber in der Entwicklung?
Bei der ersten Frage sollten Sie sich die Frage nach der Zweckmäßigkeit der Dokumentation stellen. Nur allzu oft beobachten wir in unseren Kundenprojekten, dass Dokumente erzeugt werden, die keinerlei Mehrwert für die Entwicklung stiften und gleichzeitig auch nicht regulatorisch erforderlich sind. Investieren Sie daher keinen Aufwand in das Erstellen von Dokumentation, insofern diese keinem direkten Zweck dient oder kein konkret existierendes Problem löst.
Zur zweiten Frage sollten Sie sich intensiv mit den für Sie geltenden Gesetzen, Normen und Standards vertraut machen und herausfinden, was das geforderte Mindestmaß an Dokumentation ist, welches durch eben diese gefordert ist. In vielen Organisationen wird unter dem Vorwand, dass es regulatorisch gefordert sei und man sich nur absichern wolle ein unverhältnismäßig hohes Maß an Dokumentation erzeugt. Dabei ist das, was tatsächlich gefordert ist, nur ein Bruchteil dessen, was angenommen wird. Darüber hinaus wird in regulatorischen Vorgaben typischerweise keine konkrete Aussage darüber gegeben, wie die Dokumentation erfolgt, sondern lediglich, was Sie bei Bedarf nachweisen können müssen. Wie Sie diesen Nachweis erbringen möchten, ist Ihnen überlassen und die Entscheidung darüber letztendlich zum Teil auch Risikomanagement. Machen Sie sich also bewusst, was in Ihrem Kontext regulatorisch notwendig ist und definieren Sie das für Sie passende Vorgehen, um dies zu erfüllen.
Die dritte Frage adressiert die Dokumentation, die zwar nicht erforderlich ist, um ein Gesetz, einen Standard oder eine Norm zu erfüllen, aber einen Mehrwert für die Entwicklung schafft, indem z.B. die disziplinenübergreifende Kommunikation durch die gemeinsame Dokumentation unterstützt wird. Wichtig ist hier, dass Sie bewusst trennen zwischen dem, was regulatorisch relevant und damit zwingend erforderlich für ein Release ist und was nicht. So können Sie z.B. ein Release mit der release-notwendigen Dokumentation auf den Weg bringen und die nicht-release-relevante Dokumentation, falls notwendig, noch zu einem späteren Zeitpunkt ergänzen.
Sind Sie sich über die drei beschriebenen Fragen im Klaren, so ist der Continuous Documentation Ansatz vermeintlich einfach umzusetzen. Es gibt lediglich 4 Schritte, die sich für jedes Release wiederholen:
- Betroffene Dokumente identifizieren
- Änderungen durchführen/notwendige Änderungen kommunizieren
- Änderungen teamintern reviewen
- Review durch freigabe-relevante Stakeholder
Schritt 1 führen Sie auf Basis einer neuen oder geänderten Anforderung durch, die in die Umsetzung gehen soll, z.B. also ein Backlog-Item oder auch ein Change Request – abhängig davon, wie Sie in Ihrer Entwicklung arbeiten. Analysieren Sie, welche Dokumente, also beispielsweise Architekturdokumentation, Testspezifikationen, Risikoanalysen oder auch User/Operator/Service Manuals von der neuen bzw. geänderten Anforderung betroffen sind. In diesem Schritt ist es ausreichend zu identifizieren, welche Dokumente betroffen sind, nicht aber zwingend, welche konkrete Änderung notwendig ist. Idealerweise beziehen Sie die betroffenen Rollen bzw. die Rollen, die für eine Einschätzung der Auswirkungen der Anforderung relevant sind, möglichst frühzeitig mit ein und stellen ein gemeinsames Verständnis bzgl. der Anforderung her.
Im zweiten Schritt analysieren Sie dann, welche konkreten Anpassungen notwendig sind und führen diese durch bzw. kommunizieren die notwendigen Änderungen an die Verantwortlichen der Dokumente, die von der Anforderungsänderung betroffen sind, insofern die Verantwortung für das Dokument nicht in Ihrer eigenen Verantwortung liegt.
Nachdem Sie bzw. die Dokumentenverantwortlichen die Änderungen durchgeführt haben, reviewen Sie im Dritten Schritt die Änderungen zunächst „teamintern“. Das heißt, unter allen von der Änderung betroffenen Stakeholdern, um die inhaltliche Korrektheit und Konsistenz zwischen den Dokumenten sicherzustellen.
Im letzten Schritt führen Sie dann ein Review mit den Stakeholdern durch, deren Review Sie für eine potenzielle Freigabe des Dokuments benötigen, damit bei einem potenziellen Release ein Review auf Item-Ebene nichtmehr erforderlich ist, sondern lediglich ein Review des für die Freigabe relevanten Dokuments als Ganzes.
Sie sind interessiert an mehr Details und Good Practices zum Thema Continuous Documentation oder agilem Systems Engineering? Dann besuchen Sie einfach unser neues Training „Agiles Systems Engineering“, in dem Sie mehr zu möglichen Lösungsansätzen aus der Welt des agilen Systems Engineering erfahren und mit unseren Experten diskutieren können.
Weitere Beiträge aus dieser Blogserie finden Sie hier: