Bitte um Feedback für Moderationskonzept des Schulserver-Entwicklertreffens in Karlsruhe
Hallo,
bekanntlich soll auf dem Linuxtag in Karlsruhe ein Treffen der Entwickler von
Schulservern stattfinden, um Möglichkeiten zur Vermeidung von Doppelarbeiten
und zur Kooperation zu finden.
Dies ist der Stand meiner Vorüberlegungen für die Moderation des
Entwicklertreffens, die ich hiermit zur Diskussion stelle.
Feedback im Vorfeld wird helfen, die Moderation optimaler an die Wünsche der
Teilnehmer auszurichten.
Antworten je nach Gusto bitte an mich direkt oder auf dieser Liste.
Wer potentielle Teilnehmer kennt, möge Ihnen bitte einem Link oder eine Kopie
zumailen.
Gruß
Peter Voigt
----------------------------------------------------------------------------------------
Moderations-Konzept
Stand 04. Juni 2004
Thema
--------
Möglichkeiten, bei der Entwicklung von Schulservern Kooperationen einzugehen
und Doppelentwicklungen zu vermeiden
Zielgruppe
-------------
Personen mit
- Kenntnissen über die Arbeitsweisen und -wege von OpenSource-Projekten
- Mindest-Kenntnissen von mindestens einem Schulserver
- gegenwärtiger oder beabsichtigter Mitwirkung bei der Schulserver-Entwicklung
Dauer
-------
geplant sind 2 Stunden
Gesprächsphasen
-----------------------
1. Features der Schulserver auflisten
2. Stand der jeweiligen Entwicklungen abfragen
3. Zwischenergebnis feststellen
4. Implementierungswege vergleichen
5. Ausblick für Kooperationen
6. Abschluß-Papier
Pausen nach Wunsch, Vorschlag: vor/nach Punkt 3.
1. Features der Schulserver auflisten
----------------------------------------------
Ausgangspunkt könnte das Lastenheft sein, das unter Mitwirkung etlicher Lehrer
im deutschen Ableger des Skolelinux-Projektes erarbeitet wurde.
http://developer.skolelinux.no/qualityManagement/DQ/
requirementsSpecification.html.de
Dieses Lastenheft listet gewünschte Funktionalitäten, ohne Vorgaben für die
Implementierung zu machen. Das Lastenheft ist daher "schulserverneutral",
d.h. nicht besonders auf skolelinux ausgerichtet.
Gesprächsgegenstand ist nicht das Lastenheft. Es dient nur dazu, dem Gespräch
eine gewisse Gliederung vorzugeben. Eine Diskussion darüber, ob bestimmte
Features fehlen oder überflüssigerweise aufgenommen worden sind, sollte
vermieden werden.
Wenn von Gesprächsteilnehmern gewünscht wird, weitere Features in den
Vergleich aufzunehmen, sollte das einfach gemacht werden, ohne zu
hinterfragen, ob jenes Feature für Schulden bedeutsam ist.
Sinn und Zweck soll sein, die Eigenschaften vorhandener Schulserver zu
vergleichen, nicht aber, zu bewerten, welche Funktionalitäten "gut" sind oder
nicht.
Wenn jemand berichtet, ein Schulserver habe die Eigenschaft X, die jenen
Schulserver charakterisiert, sollte die in Frage stehende Eigenschaft
zwangslos in den Vergleich einbezogen werden.
Die Gefahr, sich an dieser Stelle zu verzetteln, sehe ich nicht. Denn es geht
an dieser Stelle nur um Funktionalitäten, nicht um technische Umsetzungen.
Das Thema Funktionalitäten läßt sich schnell abhandeln. Das spürt man, wenn
man das Lastenheft durchsieht.
Als Ergebnis könnte eine vergleichende Übersicht zustande kommen, etwa in Form
einer Tabelle (Flipchart/Moderationswand?).
2. Stand der jeweiligen Entwicklungen abfragen
----------------------------------------------------------
In einem zweiten Schritt könnten die jeweiligen Entwickler berichten, wie sie
bezogen auf die einzelnen Features den Stand ihrer Entwicklung einschätzen,
beispielsweise nicht geplant, wird noch in Angriff genommen, Vorstellungen
über die Art und Weise der Implementierung sind abgeschlossen, Codierung
läuft, Test läuft, Beta läuft, bereits veröffentlicht, wird nur noch gepflegt
etc.
Es empfiehlt sich, zu Beginn dieser Gesprächsrunde eine Verständigung zu
finden, welche Stufen zu unterscheiden sind.
Augenmerk sollte darauf gelegt werden, diese Stufen so zu definieren, dass der
Zweck des Treffens, nämlich Kooperationsfelder auszuleuchten und Doppelarbeit
zu vermeiden, erreicht werden kann.
An dieser Stelle habe ich noch nicht zu Ende gedacht. Am interessantesten
werden für Kooperationen wohl die Entwicklungen sein, die noch nicht in
Angriff genommen wurden bzw. noch nicht fertig sind. Hier sollte man die
Stufen vielleicht feiner untergliedern oder den jeweiligen Stand individuell
beschreiben.
Dass sich OpenSource-Entwicklungen in einem ständigen Fluß befinden, weis
jeder Beteiligter. Dennoch wäre es wünschenswert, anzugeben, wer an der
Entwicklung der jeweiligen Entwicklung beteiligt ist (z.B.
Einzel-Entwicklung, 2-Mann-Team ....), soweit das im Einzelfall festzumachen
ist.
Aus meiner Sicht müssen dabei keine konkreten Namen genannt werden, weil es ja
zunächst nur darum geht, Möglichkeiten auszuleuchten. Es würde allerdings
auch nicht schaden, wenn Ansprechpartner benannt würden.
Auflisten könnte man auch, wie der jeweilige Entwicklungsprozeß organisiert
ist. Womöglich gibt es beispielsweise ein definiertes Entwicklungsverfahren,
Qualitäts- und Sicherheitsbeauftragte, Entwickler für eventuelle
Sonderfunktionen wie Sprachanpassungen oder Layout-Dinge etc.
(Ich bin mir völlig darüber im Klaren, wie die Wirklichkeit im
OpenSource-Umfeld aussieht).
Ich halte es für sinnvoll, schon auf in dieser Gesprächsphase danach zu
unterscheiden, welche Zielsetzungen der jeweilige Schulserver verfolgt. Ich
halte es für wichtig, sich bewußt zu sein, dass die Schulserver
unterschiedliche Zwecksetzungen verfolgen und daher ihre jeweiligen Features
aus unterschiedlichen Perspektiven betrachtet werden müssen.
3. Zwischenergebnis feststellen
---------------------------------------
Die Teilnehmer können bis hierhin einen Einblick in die Entwicklerszene
gewinnen, der ihnen ansonsten vielleicht verborgen bleibt.
Je mehr Entwickler unterschiedlicher Schulserver teilnehmen, umso gehaltvoller
wird der Einblick ausfallen.
Es wird sich an dieser Stelle bereits abzeichnen, welches Potential für
Kooperationen und Vermeidung von Doppelarbeiten vorhanden ist.
4. Implementierungswege vergleichen
------------------------------------------------
Jetzt kommt der schwierigste Schritt, der bei jedem Beteiligten Disziplin
erfordert.
Anfangs sollte eine Auswahl getroffen werden, mit welchen Features man sich im
zweiten Teil des Treffens näher beschäftigen will.
Es lohnt nicht, Zeit auf Features zu verwenden, bei denen von vornherein kein
Potential für Kooperation etc denkbar ist.
Hier gilt es, die Gratwanderung zu bewältigen, um keine Ideen, Potentiale und
Beiträge abzuwürgen.
Für die näher in Betracht zu ziehenden Features könnten die Entwickler, die
solche Features bereits verwirklicht haben, berichten, welchen Weg sie
gegangen sind und wie sie den Weg aus der Erfahrung heraus bewerten.
Erwähnenswerte Punkte wären beispielsweise:
- eingesetzte Software
- Aufwand, diese Software zu installieren bzw. anzupassen
- Aufwand, diese Software im Schulbetrieb zu handhaben
- Grad der Zweckerreichung
An dieser Stelle habe ich noch nicht zu Ende gedacht. welche Punkte
aufzulisten sind. Es liegt mir daran, den Teilnehmer leicht faßbare Kriterien
vorzuschlagen, die schnell und einfach abgehakt werden können.
Der 4. Punkt ist schwerer abzuhandeln, als die früheren. Hier können
technische Vorgaben, beispielsweise die Wahl der Basis-Distribution oder eine
Festlegung auf bestimmte Software-Pakete, eine große Rolle spielen.
Nicht von Bedeutung ist an dieser Stelle, _warum_ eine bestimmte Software
ausgewählt wurde. Das könnte in eine Diskussion münden, wer den "besten"
Schulserver hat. Das führt zu nichts.
Es sollte vermieden werden, in ein Gespräch einzutreten, welcher Weg der
bessere ist. Das birgt die Gefahr abzugleiten auf eine Ebene a la "Mein Auto
hat breitere Reifen".
Ein Gespräch darüber, ob die jeweils getroffenen Entscheidungen von anderen
Entwicklern gutgeheißen werden, sollte vermieden werden. Das führt zu nichts.
Jeder, der sich mit Open Source Entwicklung beschäftigt, weiß, welche
Zufälligkeiten (vorhandene Vorkenntnisse des Entwicklers, verfügbare Zeit,
verfügbare Technik, Anknüpfen an vorhandene Lösungen etc etc) solche
Entscheidungsprozesse beeinflussen können. Nicht jeder hat das Glück, in
einer optimalen Entscheidungssituation zu stehen, deshalb sollten die
jeweiligen Entscheidungen einfach respektiert werden.
Je nachdem, woran die Anwesenden Interesse haben, sollten einzelne Features
vertieft oder der Überblick über mehrere Features im Auge behalten werden.
Am Ende der vierten Gesprächsrunde ist es zu einem zwangslosen
Erfahrungsaustausch gekommen. Die Gesprächsteilnehmer werden in die Lage
versetzt sein, den Aufwand für die Entwicklung einzelner Features zu erkennen
und ihre eigenen Möglichkeiten und Reichweiten bei Entwicklungen im
Schulserverbereich klarer einzuschätzen.
5. Ausblick für Kooperationen
-------------------------------------
Je nachdem, wie die allgemeine Einschätzung der Teilnehmer ausfällt, könnten
potentielle Arbeitsfelder für Kooperationen oder für die Vermeidung von
Doppelarbeiten identifiziert und benannt werden.
Falls gewünscht, können Kooperationsformen und -wege an Ort und Stelle für die
jeweils Interessierten nach ihren jeweiligen Vorstellungen angedacht werden.
Die Moderation dieser Gesprächsphase hängt ganz von den Wünschen der
Teilnehmer ab.
6. Abschluß-Papier
-------------------------
Optimal wäre ein abschliessendes Papier, das selbstverständlich nicht an Ort
und Stelle ausformuliert werden muß.
Ich bin bereit einen Vorschlag vorzulegen, den Teilnehmern als Entwurf
zuzuschicken, Änderungswünsche aufzunehmen und das "offizielle" Papier zu
veröffentlichen.
Das Papier sollte aus zwei Teilen bestehen. Der erste Teil beinhaltet einen
vergleichenden Überblick über die Schulserver.
Der zweite Teil könnte die Erwartungen, Wünsche und Vorstellungen der
Gesprächsteilnehmer enthalten, wenn sie von den Teilnehmern zur
Veröffentlichtung freigegeben werden.
Aus meiner Sicht ist es kein Problem, ggfs. abweichende individuelle
Standpunkte einzuarbeiten, falls es in der Sache notwendig ist oder von
Teilnehmern gewünscht wird.
Zeigt sich gar kein Konsens, wäre dieser Umstand festzuhalten, möglichst mit
einer Darstellung der unterschiedlichen sachlichen Positionen. Auch das wäre
ein konkretes Ergebnis des Entwicklertreffens.
Namensnennungen würden selbstverständlich nur mit Zustimmung der Betroffenen
erfolgen.
Peter Voigt
Reply to: