Nach den ersten drei Entwicklungssprints nähern wir uns nun dem ersten Meilenstein – der Evaluierung des Prototypen bei den Pilotanwendern.
Im sprintDoc Projektprozess haben wir eine frühe Evaluierung des Demonstrators bei den Pilotanwendern vorgesehen. Konkret bedeutet das, dass wir jetzt – nach den ersten Entwicklungssprints – bereits eine Inbetriebnahme des Demonstrators bei den Pilotanwendern vornehmen werden.
Der aktuelle Entwicklungsstand des Demonstrators beinhaltet eine intelligente Verknüpfung zwischen Jira, Dokuwiki und gitlab.
Source Code Commits in git werden automatisch im Jira Issue als Links hinzugefügt. Im Wiki bekommt man Vorschläge für Dokumente, die zu den aktuellen Commits passen. Das Vorschlagssystem soll dabei den Entwickler unterstützen, die passenden Dokumente zu finden.
Die Motivation für dieses Vorschlagssystem besteht darin, dass es häufig schwierig ist, die richtige Stelle für die Dokumentation zu finden – wodurch die Gefahr besteht, dass mehrfach dokumentiert wird, anstelle dass Dokumentationsorte aktualisiert werden. Mit dem Vorhandensein von mehrfachen, inkonsistenten Fundstellen jedoch schwindet der Nutzen einer Dokumentationsplattform.
Wir haben uns für die Integration des Wikis in den Entwicklungsalltag als Ziel gesetzt, möglichst nahtlos aus dem Ticketsystem Jira in das Wiki wechseln zu können. Hierzu wurden in die Issueansicht im Jira direkt Links zum Wiki integriert, die auf das Vorschlagssystem zeigen.
Dokumentationsausfgaben im Wiki werden hierbei immer im Kontext des Jira Issues durchgeführt; die für ein Issue bearbeiteten Wiki-Dokumente werden automatisch in der Jira Issue Ansicht aufgelistet. Die Transparenz, welche Wiki-Dokumente mit welchen Issues verbunden sind, hilft nicht nur dem Entwickler, sondern auch anderen Projektbeteiligten wie dem Scrum Master, der Akzeptanztests nun nicht nur für die Softwareartefakte, sondern auch für die Dokumentationen durchführen kann.
Ebenfalls in den Entwicklungssprints erarbeitet wurden grundlegende Strukturen für Dokumentationssysteme – basierend auf der Erkenntnis, dass man häufig nicht ein Dokumentationssystem zu pflegen hat, sondern mehrere:
- Projekthandbücher mit Meetingprotokollen
- Lessons Learned Handbücher mit (projektübergreifendem) Erfahrungswissen
- Requirements-Handbücher zur Ablage von Spezifikationen der Softwarebausteine, die im agilen Prozess sukzessive verfeinert werden.
Die Erfahrungen aus der ersten Nutzung bei den Pilotanwendern werden zusammen mit den Ergebnissen der Befragung in neue Anforderungen überführt und in die nächsten Sprints einfließen. Parallel wird das Werkzeugkonzept daher stetig weiter entwickelt und ganz im Sinne der Agilität stets den Anforderungen aus Theorie und Praxis entsprechend angepasst. Sobald ein veröffentlichungswürdiger Stand besteht, werden wir diesen auf passenden Veranstaltungen der Öffentlichkeit präsentieren und an dieser Stelle darauf hinweisen.