cards-rolle-autor

Mein Name ist Robert Bruckbauer. Ich bin Mitarbeiter der eMundo GmbH in der Niederlassung Frankfurt. Seit 1990 bin ich leidenschaftlicher Software-Entwickler, mein Hobby ist Beruf. Mit Basic habe ich als Jugendlicher experimentiert. Beruflich startete ich mit Fortran, C und C++. Mittlerweile verfüge ich über viele Jahre Erfahrung in der Programmierung mit Java und JEE. Ich besitze fundierte Kenntnisse über verteilte event-basierte Systeme und Technologien zur Verarbeitung großer Datenmengen (Stichwort “Big Data”). Der Schwerpunkt meiner Tätigkeiten in den Projekten ist der Entwurf und die Umsetzung großer Software-Systeme und das Coaching der Entwicklerteams. Meine Rollen waren Entwickler, Produkt-Manager (lange her), Projekt-Manager, Software-Experte und Product-Owner.

Mit der Einführung agiler Vorgehensmodelle – allen voran Scrum – hat sich für mich vieles geändert. Ich habe festgestellt, dass eine gute Dokumentation sich positiv auf die Qualität eines Software-Produktes ist auswirkt. Ich beschäftige mich schon länger mit dem Versuch, agile Projekte in die Lage zu versetzen, inkrementell zu dokumentieren. Aus dem Versuch habe ich über persönliche Erfahrungen in Projekten eine eigene Methode mit dem Namen CARDS+ entwickelt. Diese Methode unterstützt die Erstellung und Pflege einer Produktdokumentation bereits bei der Projektinitialisierung und begleitet Anforderungsanalyse, Entwicklung und Test. Mein Ansatz für agiles Wissensmanagement lässt sich gut mit anderen agilen Methoden und Vorgehensmodellen der Software-Entwicklung verbinden.

Mit  CARDS+ wird schrittweises Dokumentieren eine kontinuierliche Tätigkeit der ganzen Projektorganisation.

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.