Ein Autor ist berechtigt, neue Seiten im Wiki anzulegen oder bestehende Seiten zu ändern. Seine Aufgabe ist es, gemäß der Methode CARDS+ Seiten im Wiki inkrementell mit Inhalt zu füllen. Er nutzt dabei die vorgefertigten Bausteine, folgt den Prinzipien und Praktiken beim Erfassen von fachlichem und technischem Wissen über das Produkt.

Ein Autor ist verantwortlich für die Qualität seiner Seiten.

ktip Jede Seite im Wiki hat einen Autor. Im Regelfall gilt die Person, die eine Seite zuletzt geändert hat, als aktueller Autor und damit verantwortlich für den Inhalt der Seite. Das ist ein pragmatischer Ansatz, der von jedem Wiki gut unterstützt wird.

Ein Autor ist auch Moderator der Kommentare seiner Seiten im Wiki. Er darf eigene Kommentare und die der Leser entfernen, wenn sie seiner Einschätzung nach erledigt sind. Autoren benötigen und schätzen Feedback der Leser, egal, ob es Kommentare oder Gespräche sind.

Der Product-Owner ist Autor

Der Product-Owner ist bei agiler Software-Entwicklung mit Scrum naturgemäß der wichtigste Autor. Er trägt die Verantwortung für das Produkt, inhaltlich und wirtschaftlich. Die Produktdokumentation und damit auch das Wiki ist ein Teil des Produktes. Für das Backlog-Management nutzt er vor allem die Bausteine Epic und Case, für Benutzeroberflächen den Baustein Layout.

Scrum sagt nichts darüber aus, was ein einzelner Product-Owner machen soll, wenn er seine Aufgaben trotz Vollzeit nicht zeitgerecht oder in ausreichender Qualität schafft. In einem komplexen Projektumfeld oder bei “jungen” Projekten mit großen Veränderungen besteht schnell die Notwendigkeit, dass er Unterstützung benötigt. Besonders bei technischen Grundsatzfragen muss er Software-Experten einbeziehen. Für eine gute Nutzererfahrung (englisch: user experience) ist ein guter UX-Spezialist notwendig. Im Zusammenhang mit scrum-basierten Frameworks wie Nexus, Less oder Safe gibt es Konstruktionen, die Aufgaben bei der Integration übernehmen. So ein Spezial-Team” kann die notwendige Unterstützung für den Product-Owner geben.

In kleinen oder “reifen” Projekten übernehmen Mitglieder des Teams die Aufgaben des UX-Spezialisten und des Software-Experten zur Unterstützung des Product-Owners.

Der Business-Analyst ist Autor

Ein Business-Analyst unterstützt den Product-Owner in der Anforderungsanalyse vor allem als Autor der Bausteine Epic und Case.

Der Software-Experte ist Autor

Ein Software-Experte koordiniert und sichert das Wissen über die Software-Architektur, ganz nach dem Motto “eine Software-Architektur ist die Summe fundamentaler Entscheidungen”. Mit dem Baustein Decision hält er Randbedingungen, Qualitätsanforderungen und andere zentrale Einflüsse fest. Die Systemstruktur dokumentiert er in Abstimmung mit den Entwicklern mit den Bausteinen Domain, Service, Entity und Event.

Der UX-Spezialist ist Autor

Bei der Definition einer Benutzeroberfläche und der Nutzererfahrung (englisch: user experience) ist ein UX-Spezialist unverzichtbar als Autor für alle Varianten des Bausteins Layout.

Ein Entwickler ist Autor

Eine Lösung im Case bezieht sich auf die Systemstruktur, die Entwickler im Team zusammen mit Software-Experten entwerfen und mit den Bausteinen Domain, Service, Entity und Event beschreiben. Mit dem Fortschritt der Realisierung vervollständigen sie diese Bausteine. Ganz wesentlich ist, dass sie dort Besonderheiten und wichtige Erkenntnisse zu jeder Komponente festhalten kann.

Ein Tester ist Autor

Eine Lösung im Case wird u.a. durch Akzeptanztests abgesichert. Diese Testart ist Teil der Produktdokumentation. Die Mitarbeit der Tester im Team als Autoren im Wiki beschränkt sich normalerweise auf die Bausteine Case und Service, weil sich Akzeptanztests auf diese Bausteine beziehen.