Re: [Ag Meinungsfindungstool] Könnte man das Thema nicht bitte etwas aufgeräumter angehen? / war: Dudel

[Rolle <rolle AT rolandschmitt.info>]

Hi,

On 07.01.2012 19:54, Dirk H. wrote: Dromedar schrieb:
>> Ich habe eine Umfrage 'bist du dafür, Dudle als Plattform für
>> die Debatte über die MFT-Anforderungen einzusetzen?' erstellt.
> War meine erste Dudle-Umfrage und ist zu kompliziert ausgefallen -
> hier KISS-able Version https://dudle.inf.tu-dresden.de/MFT-Anforderungen2/ ;-) .
> Wenn das Gesamtergebnis positiv ausfällt, dann wird eine nummerierte Liste
> der Anforderungen in der AG verabschiedet. Einzelne Spalten dieser Liste
> werden dann in Dudle mit grün, rot oder gelb abgestimmt.


Hi Gustav,
hi AG,

bisher habe ich mich nicht zu Wort gemeldet, weil ich dachte, es rüttelt sich nach den vielen Mails auf der Liste schon noch ein. Aber jetzt muss ich doch mal was sagen:

Irgendwie fehlt mir bei der momentanen Vorgehensweise die Nachvollziehbarkeit. Ich hätte jetzt spontan erwartet, dass wir zuerst einmal

1. zusammentragen, wo und für welchen Zweck in der PIRATENPARTEI welche Tools für Meinungsfindung/-bildung und Konsens/t-Findung eingesetzt werden.

Aufsetzend auf diesem Wissen könnten wir dann in Brainstorming-Modus

2. eine Analyse der Stärken und der Schwachstellen der Verwendung gerade dieser Tools für gerade diese Zwecke

anschließen. insbesondere bei den Schwachstellen müsste detailliert dargelegt werden, für welche Anwendung (Diskussion, Meinungsbild, Abstimmung etc.) konkret welche Eigenschaft der kritisierten Verfahrens genau welchen Nachteil bedeutet. Beispiel: "Datenschutz" hilft als Schwachstelle nicht wirklich weiter. Eine Aussage wie "Verfahren xy erlaubt über Ctrl-Alt-mittlereMaustatste auf einem geheimen Abstimmungsergebnis die Anzeige einer Liste der Nein-Stimmen" lässt sich in etwas konkretes umsetzen.

Die als Zwischenergebnis entstandene Liste müsste dann für alle nachlesbar, d.h. z.B. im Wiki aufgeschrieben, vorliegen. Wenn bei einem Punkt nicht klar ist, was gemeint ist, kann das dann direkt dort nachgefragt und beantwortet werden. Sobald eine gewisse Volständigkeit eintritt, könnten wir
Da das ursprünglich aus RLP initiiert wurde, war die Antwort einfach: kein Tool. Daher wurde das wohl noch nicht angeschnitten.
3. in einem Ranking-Verfahren (meinetwegen auch mit Dudel) die Schwachstellen bezüglich ihrer Relevanz ordnen und auch die erhaltenswertesten Stärken definieren.

Das Ergebnis dieser Schritte wäre eine systematisch gewonnene und von der AG gerankte Liste von Anforderungen, an das/die gewünschte(n) Tool(s).

Vorteile:

• Das methodisch sauber hergeleitete Arbeitsergebnis ist im Nachinein nachvollziehbar und der konkrete Ursprung der einzelnen Anforderungen (die sog. Erfahrung) gerät nicht in Vergessenheit.
• Tauchen im Nachhinein neue Aspekte auf, können sie leicht in das Ergebnis einsortiert werden.
• Bei allen Anforderungen bleibt stets klar, aus welchem Anwendungsbereich sie kommen und für welchen Anwendungsbereich sie relevant sind.
• Wenn neue Piraten zur Diskussion stoßen, können sie sich leichter einarbeiten und auch für einen potentiellen Abnehmer unserer Arbeitsergebnisse wird es leichter, die Stichhaltigkeit nachzuvollziehen.

Ich meine, dass man gerade an https://meinungsfindungstool.piratenpad.de/6 gut erkennen kann, wie ein sicherlich mit viel Sachkenntnis und Arbeitsaufwand zusammengetragenes Ergebnis für denjenigen, der nicht direkt an der Erarbeitung beteiligt war, zur a) nicht nachvollziehbaren b) bloßen Buzzword-Sammlung wird.
Es kann nicht jedes Pad so geschrieben sein, das ein Quereinsteiger alles sofort versteht, das ist auch nicht Sinn und Zweck von diesem Pad. Wenn du Fragen hast, dann schreibe sie doch dazu. Wenn etwas unklar ist, formuliere es so um, wie du es verstehst.

In Kenntnis dieser für ein Verfahren notwendigen Eigenschaften könnte man dann

4. eine architektonische Vision und ein Konzept für eine geeignete Software ausarbeiten

um dann

5. dieses Konzept mit vorhandenen Implementierungen, z.B. LiquidFeedback, zu vergleichen und den konkreten jeweiligen Entwicklungsantrag überhaupt zu formulieren.

Hat man sich dann einen Überblick verschafft, kann man schauen, ob es Sinn macht, Tool xy in der gewünschten Richtung weiterzuentwickeln oder das Risiko (und das Zeitgrab) einer Neuentwicklung anzugehen.

In Ansicht einer solchen Vorgehensweise möchte ich nun anregen, nicht irgendwo mitten in Schritt 3 zu beginnen. Denn es ist absehbar, dass sich ohne saubere und nachvollziehbare Analyse vorhandener Verfahren auch keine gemeinsame Sprechwese herausbilden kann, die dann ein von allen gleich verstandenes und auch für Aussenstehende nachvollziehbares Zwischenergebnis sicherstellt. Und nur ein Zwischenergebnis mit diesen Eingenschaften eignet sich als Grundlage für die Schritte 4 und 5.

An denen ich nun aber sehr interessiert bin, denn wenn wir an dieser Stelle nichts belastbares rausbekommen, dann kann ich meinen Wunsch nach gelebter LD, gerade bei den zur Zeit (an)laufenden Tendenzen in der PIRATENPARTEI, gleich wieder begraben...

Und deswegen stimme ich bei Deiner Umfrage zum jetzigen Zeitpunkt mit Nein (wenn Interessierte überhaupt mit abstimmen dürfen).

So und jetzt genug geredet.
Hi,

On 07.01.2012 01:56, allusion AT gmx.de wrote:

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.

Da ich nicht die Zeit haben werde, an sovielen Konferenzen etc. teilzunehmen, wo kann ich deine Aufzeichnung bzw. Protokolle finden?

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.

Sorry, für mich klingt das arg nach dem "Idealzustand" wie man ihn an der Uni beigebracht bekommt. Bisher gibt es hier vielleicht 5 Leute, die was substantielles, sprich lesbares beigetragen haben.
Wir können natürlich jetzt erstmal anfangen, Pflichtenhefte, Fachkonzepte, UML-Diagramme usw zu erstellen. Das ist meiner Meinung nach der falsche Ansatz. V-Modell, Wasserfallmodell usw. sind aus Grossprojekten mit entsprechenden Ressourcen entstanden und spiegeln die Verhältnisse von vor 20 Jahren wieder.

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).

Dafür haben wir doch viel zuwenig Ressourcen. Wer sollte hier den irgendwas implementieren? Für das von dir beschriebene Szenario brauchst du doch mindestens 5-8 Leute (Vollzeit), das will ich garnicht auf uns "Freizeitarbeiter" hochrechnen.

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.

Das wäre super, ist gibt ja bereits einige Pads oder leg was Neues an.

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.

Wir haben hier kein Projektteam aus dem man auch noch Gruppen bilden könnte. Momentan sehe ich hier vielleicht 5 Leute, die was sichtbares beigetragen haben.

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.

Gruss
Rolle