############ Organisation ############ Da sich die Organsiation des Projekts in den zuvor besprochenen Werkzeugen und Workflows wiederspiegelt, wird diese erst an an dieser Stelle besprochen. Der organisatorische Aufbau von Projekten kann sehr unterschiedlich sein, jedes Projekt sollte daher sein eigenes Projektstatut oder Readaktionsstatut, bzw. eine eigene Projektdokumentation besitzen, in welcher die Abweichungen und Besonderheiten im Vergleich zu einem Standardpublikationsprojekt beschrieben sind. .. index:: single: Projektleiter single: Redaktion single: Chefredakteur ************************************************* Projektleiter, Redaktion, Chefredakteur ************************************************* Jedes Projekt hat einen primären Projektverantwortlichen. Für Projekte mit mehreren Beitragenden bzw. mit einer komplexeren Organisationsstruktur kann eine Redaktion gemäß der Statuten des CCCA mit eigenem Redaktionsstatut eingerichtet werden. Einer Redaktion steht ein Chefredakteur vor. Der Projektverantwortliche oder Chefredakteur ist der primäre Ansprechpartner für alle Projektdetails. Er ist die höchste Instanz für inhaltliche und oraganisatorische Entscheidungen. ******** Workflow ******** .. image:: /Bilder/Cover/AASS-Cover-3.0.0.var-1.pdf.png :width: 50% :align: right Die :ref:`Arbeits- und Ausbildungsstandards für den Sanitätsdienst `, später fortgeführt als Kompendium des CCCA, werden seit 2008 von der ARGE AASS bzw. dem CCCA als Gemeinschaftsprojekt entwickelt und herausgegeben. Dementsprechend ist die Organisation der Entwicklung und Wartung von entscheidender Wichtigkeit. Bis zur Version 3 erfolgte die Entwicklung in Anlehnung an das agile Projektmanagement-Modell `Scrum `_. Dabei erfolgt die Arbeit in *Entwicklungszyklen*, sogenannten *Sprints*, welche i. d. R. *3 Monate* dauern. Am Anfang jedes Sprints werden Entwicklungsziele für den jeweiligen Zyklus vereinbart, diese werden dann innerhalb des Sprints umgesetzt und am Ende findet ein gemeinsames Review statt, bei welchem die Entwicklungen des Sprints vorgestellt, begutachtet und diskutiert, sowie anschließend entweder angenommen oder verworfen werden. .. figure:: /Bilder/Cc-BySa-4.0/Scrum_Framework.png :width: 100% Das Schema des Scrum-Prozesses Ⓒ Dr. Ian Mitchell, https://en.wikipedia.org/wiki/File:Scrum_Framework.png :term:`ℓ CC BY-SA 4.0` Dies ermöglicht ein hohes Maß an gegenseitiger Abstimmung und Qualitätssicherung, und war insbesonders im ersten Entwicklungsprozess ideal. Andererseits erfordert dieses Modell allerdings einen festen Zeitplan und viele Präsenzzeiten für das Herausgeber-Team und ist daher dauerhaft in dieser Form schwer zu bewerkstelligen. Daher, und durch die zunehmende Perfektionierung von Teleworking-Tools, sowie aufgrund der Neuausrichtung der :ref:`AASS ` zu dem designierten Nachfolgeprojekt "\ :ref:`Kompendium des CCCA `\ , welches die bisherigen AASS auf ein neues Fundament heben soll, ist die Entwicklungsarbeit des Projekts einem radikalem Umbau zu einem :ref:`digitalen, kontinuierlichen Workflow ` unterworfen. Zusammenarbeit ======================================================================== Die Organisation der Arbeit am Projekt ist eine große Herausforderung. Bei der Entwicklung der AASS geschah vieles in "physischer Präsenzform" im Sinne von regelmäßiger Treffen als Beteiligter und Stakeholder. Dabei war von Vorteil, dass die AASS im Grunde eine zielgerichtete Entwicklungsstrategie verfolgte: Das Werk sollte in den Rettungssanitäterkursen des ASB Floridsdorf-Donaustadt eingesetzt werden. Dadurch ergaben sich viele Entwicklungsziele und die Motivation der Beteiligten, die in Personalunion diese Kurse durchführten bzw. an ihnen beteiligt waren. Auch richteten sich die Zeitvorgaben nach den Terminen der Kurse. Das Kompendium ist jedoch von diesen äußeren Vorgaben entkoppelt, und auch das persönliche Ziel der einzelnen Mitwirkenden und die Bereitschaft, Zeit zu investieren, ist viel individueller. Dem muss die Projektorganisation Rechnung tragen und dies in die Entwicklungsstrategie einbeziehen. Ein fixes Entwicklungszyklus-Modell mit abschließendem Review für alle Bereiche erscheint in diesem Kontext als *nicht* sinnvoll. Eine vordefinierte *Best-Practice-Lösung* kann es derzeit auch noch nicht geben, da die Evaluation der Bedürfnisse und Erwartungen der Mitwirkenden noch nicht erfolgt ist (was wesentlich daran liegt, dass es noch keinen soliden Grundstock an Mitwirkenden bzw. Anzahl von regelmäßigen Mitarbeitern, gibt und dieser derzeit erst angeworben wird). Somit bleibt festzuhalten dass die zukünftige Redaktions- und Reviewstruktur noch nicht feststeht und im Team diskutiert und *gemeinsam festgelegt werden wird*. Einige Grundideen seien aber hier angeführt: .. _digitalerworkflow: Digitaler, Internet-basierter Workflow ======================================================================== Viele Arbeiten bzw. Abläufe sollen ortsunabhängig gestaltet werden, sodass sie nach Möglichkeit auch von weit entfernten Teilnehmern problemlos und mit hoher Qualität durchgeführt werden können. Präsenzzeiten, also "echte, physische" Treffen sollen grundsätzlich **weiterhin stattfinden**, sollen aber möglichst **Zeit-effizient** organisiert sein, sodass sie den einzelnen Teilnehmern einen **Mehrwert** (in- und außerhalb des Projekts) bringen (fachlicher Austausch, Brainstorming, Besprechung von Themen die von Angesicht zu Angesicht einfacher zu bereden sind, Socialisen und Networking). Analog zum Konzept des "Home Office", welches – zumindest theoretisch – ähnliche Ideen und Strategien verfolgt, liegt der Aufbau einer entsprechenden **digitalen, Internet-basierten, Infrastruktur** zur Zusammenarbeit (Kollaboration) nahe. Da es sicher nicht in unseren Bereich fällt, eigene Technologien oder Software zu entwickeln, ist es ratsam, bereits in der Industrie bewährte Lösungen an unsere Bedürfnisse anzupassen. Im Speziellen hat die Softwareentwicklung ähnliche Herausforderungen zu bewältigen (verteilte Teams, Notwendigkeit für Reviews, Qualitätssicherung, Projektmanagement). Besonders die Community-basierte Entwicklung von freier Software, bei welcher Programmierer ehrenamtlich und geographisch oft weit verteilt sind, weist große Parallelen zu unserer Situation auf. Lösungen wie verteilte Versionsverwaltungssysteme und Kollaborations-Web-Plattformen mit Diskussions- und Projektmanagementfunktionen sind seit Jahren in diesen Bereichen populär und werden steig weiterentwickelt. Einige dieser Techniken, z. B. das verteilte *Versionsverwaltungssystem Git*, wurden schon seit über 10 Jahren bei der Entwicklung der AASS eingesetzt. Auch das mittlerweile zur Erzeugung des Kompendiums eingesetzte System der *Sphinx-Toolchain* war ursprünglich eigentlich als Dokumentationssystem der Programmiersprache Python gedacht und hat sich mittlerweile in vielen anderen Publikationsprojekten bewährt. Es erschient somit logisch, die vorhandenen Werkzeuge zu nutzen und Tätigkeiten bzw. Anforderungen wie Diskussionen, Arbeitspläne, Review u. ä. zumindest teilweise über solche Kollaborationsplattformen zu realisieren. Problematisch kann sein, dass deren Bedienung sich vor allem an den Bedürfnissen von Entwicklern orientiert und damit unerfahrene Mitarbeiter oft ein gewisses *Verständnisproblem* haben. Das wird sicher dadurch verstärkt, dass wir gegenwärtig noch keinen vorgegebenen Workflow haben wie Standardaufgaben (Review, Zweige in der Versionsverwaltung etc.) zu erledigen sind – wir sind generell noch in einem *Ausprobierstadium*. Essentiell ist es somit einen gewissen Grundstock an technisch versierten Mitarbeitern zu haben, die den weniger Technik-affinen **Hilfestellung** geben bzw. diesen derzeit noch komplizierte Arbeitsschritte abnehmen, Bedienungsprobleme identifizieren können und **Vorschläge** für **gute Standard-Workflows** machen. Digitaler Workflow auf GitLab --------------------------------- **Gitlab** ist eine Web-basierte Plattform, welche einerseits einen relativ bequemen Zugriff auf die Versionsverwaltung (Git) ermöglicht, andererseits aber wesentliche Möglichkeiten für das **Projektmanagement** bietet (virtuelle Whiteboards, Ticket-System, Wiki, Diskussionsfunktionen, …). Außerdem erlaubt es die **Bearbeitung** von Textdateien **direkt im Webbrowser**, ohne dass sonst irgendwelche Software installiert werden muss. Aktuell sind neben dem derzeit in Überarbeitung befindlichen Kompendium auch die im Entwurf befindlichen neuen Statuten des CCCA als Projekt auf Gitlab zu finden. Mitarbeiter können sich somit einen Benutzer auf Gitlab erstellen, dem Projektleiter diesen nennen, damit dieser den Benutzer in das Projekt aufnimmt und den Zugriff ermöglicht, und dann z. B. direkt den Entwurf der neuen Statuten bearbeiten und Vorschläge einbringen. Die Webseite von Gitlab lautet https://gitlab.com.