Re: [Ag Meinungsfindungstool] Ag-meinungsfindungstool Nachrichtensammlung, Band 1, Eintrag 11

[allusion AT gmx.de]

Hallo liebe Listenteilnehmer,

ich wollte mit dem Doodle keine Verwirrung stiften. Wenn Ihr vereinbart habt, daß der nächste Termin erst 2 Wochen später ist, dann ist es halt so. Dann müssen eben die Termine der kommenden Woche aus dem Doodle gelöscht werden und der meistgewählte Termin der darauffolgenden Woche gewinnt.
Ich persönlich habe allerdings die Erfahrung gemacht (ich arbeite in einem Umfeld, wo Software-/Hardware-Projekte über mehrere Standorte hinweg realisiert werden), daß gerade am Anfang eines Projektes sehr viel Kommunikationsbedarf besteht. Da hier eine Telefonkonferenz viel schneller und unkomplizierter ist und man sich nicht so schnell mißverstehen kann (das kann bis zu ernsten persönlichen Konflikten reichen !), würde ich eher vorschlagen, gerade am Anfang viele Telcos (bzw. Mumbles) zu machen und eher in den ruhigen Phasen auf Email-Listen oder Foren zu setzen. Die Telcos müssen selbstverständlich aufgezeichnet und protokolliert (bzw. inhaltlich zusammengefaßt) werden, damit die Abwesenden auf dem Laufenden sind.

Zum Herangehen insgesamt würde ich folgende Ansätze aus dem Software Engineering und Projektmanagement vorschlagen. Zuerst werden Ziele bzw. Anforderungen ("Requirements") formuliert, um eine Vision zu bekommen, wo man mal (irgendwann) hinkommen möchte. Für den ersten Durchlauf werden dann erstmal nur die hochprioren Anforderungen herausgesucht, damit wir Rom nicht in einem Tag erbauen müssen. Parallel dazu können von den "Praktikern" ruhig schon vorhandene Tools auf Anforderungen und vorhandene Eigenschaften ("Features") getestet / untersucht werden. 
Besonders wichtig ist hier meines Achtens, daß der Code dieser Tools unbedingt offen (mit Public-Lizenz) sein muß, damit man nicht auf ein kleines überfordertes Team von Berufsprogrammierern oder Freaks warten muß. Der Code sollte außerdem unbedingt portierbar (auf andere Plattformen übertragbar) und wartbar sein (lesbar, gut kommentiert und dokumentiert).
Während dann die "Theoriegruppe" das zu entwerfende System mit Hilfe der Reihenfolge beim V-Modell (Abbildung 6 auf folgender Webseite : http://www-cg-hci.informatik.uni-oldenburg.de/~da/eden/Inhalt/Kapitel_2/2.2.1klassische_phasenmodelle.htm) bearbeitet und dabei die Entwurfsmodelle von "Fusion" bzw. "UML" (http://wwwmath.uni-muenster.de/u/heisel/oose/ooa.pdf) benutzt (zunehmende Verfeinerung des Konzeptes), könnte die "Praktikergruppe" bereits daran arbeiten, die schwierigsten Knackpunkte zu finden (z.B. Probleme bei der Integration von fertigen Tools oder Tool-Komponenten in die neue einheitliche Umgebung) und erste grundlegende (Test-)implementierungen zu entwerfen. 
Nachdem das Konzept fertig ist, steigen die restlichen Software-Leute in die Programmierung ("Implementierung") ein und die Nicht-Softwerker erstellen schon die Dokumentation (Handbuch, Videos, etc.) für den ungeübten User bzw. überlegen ein Konzept, wie das neue Tool leichte und schnelle Verbreitung innerhalb und außerhalb der Partei findet. Es könnte dann nach außen schon mal über das in Arbeit befindliche Programm informiert und erste Meinungen eingeholt werden, ob denn die Features des ersten Schusses überhaupt ausreichen (Ggf. ist noch mal ein neuer Entwurfszyklus notwendig).
Aus Zeitgründen gilt für das ganze : Es wird nichts selber programmiert, was schon vorhanden und sinnvoll nutzbar ist (siehe "portierbar" und "wartbar").

Beim Thema "Anforderungen" kann ich auch schon einiges beisteuern, da ich mich damit in anderen Zusammenhängen bereits intensiv beschäftigt habe. Außerdem ist es meiner Meinung nach wichtig zu ermitteln, wer auf der Liste welche Stärken hat und dadurch am besten in einen bestimmten Bereich paßt. Darüberhinaus sollte die Arbeit in kleinere Häppchen aufgeteilt werden, deren Schnittstellen nach außen und innere Eigenschaften vorher festgelegt werden, damit wir uns in kleinere (flexiblere) Teams aufteilen können und damit schneller vorankommen. Natürlich stehen die fertigen Ergebnisse der Teams für alle zur Diskussion und können nachträglich durch die anderen Listenmitglieder kritisiert und verändert werden, aber das Herunterbrechen auf kleinere Gruppen schafft ein überschaubares Arbeitspensum und vor allem Parallelität.

Klingt das für alle Beteiligten akzeptabel oder hat jemand Gegenvorschläge ?

Viele Grüße, Bye Thomas

--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de