Benutzer:Andizo/Politische Softwareentwicklung
Liquid Democracy - wenn Softwareentwicklung politisch wird
Softwaredesign hat einen unmittelbaren und starken Einfluss darauf, wie wir heute arbeiten, wie wir kommunizieren und uns amüsieren.
Viele Beispiele aus der Praxis (Mautsystem, Ticketingsysteme etc.) zeigen immer wieder, dass gerade "politische" Projekte sich nur mit sehr großem Aufwand verwirklichen lassen und daher fast regelmäßig "überziehen" und finanziell aus dem Ruder laufen. Die Ursache dafür ist (eigentlich immer) mangelhafte Kommunikation. Den Entwicklern bleiben die Anforderungen unklar, die Auftraggeber fühlen sich technisch überfordert.
Im freien Markt wurden für dieses Problem bereits effiziente und flexible Lösungen gefunden. Diese agilen Softwareentwicklungsmodelle nennen sich z.B. XP (eXtreme Programming) oder Scrum (dt. Gedränge) und sorgen von Ihrem Wesen her für regen Austausch aller Beteiligten.
Die Kernprinzipien agiler Softwareentwicklung:
- Kurze Entwicklungsintervalle von 2-3 Wochen (Iterationen/Sprint) mit klar definierten Aufgaben.
- Diese Aufgaben können sowohl technischer Natur sein, oder aber auch User-Stories aus Benutzersicht sein.
- Am Anfang jeder Iteration setzen sich alle Beteiligten an einen Tisch (Kick-off) und verhandeln nach einem Verfahren über die Priorität (bereits vorab grob ausgearbeiteter) neuer Aufgaben, die bis zum Ende der jeweiligen Iteration fertig sein sollen. Die Softwareentwickler dürfen gleichberechtigt eigene Vorschläge (technischer Natur) einbringen. Aufgaben, die innerhalb des Intervalls nicht zu erledigen sind, müssen in Einzelaufgaben unterteilt werden.
- Am Ende jeder Iteration (Closure) stellen die Entwickler die erledigten Aufgaben z.B. in Form von Demonstrationen vor.
Aus eigener Erfahrung kann ich sagen, dass diese Art der Softwareentwicklung wesentlich harmonischer und effizienter ist. Der Kunde weiss was er bekommt und der Entwickler, was er zu tun hat.
Mit der Einführung von Liquid Democracy Systemen wie Adhocracy oder Liquid Feedback stellt sich für die Piratenpartei ganz aktuell die Frage, wie und ob sie diesen Softwareprozess gestalten soll.
Ich glaube, es ist keine gute Idee, dies alleine den Softwareentwicklern zu überlassen. Sehr schnell wäre Softwareentwicklung politisch, sehr schnell gibt es Streit und Zank und das ganze schöne Projekt geht den Bach runter.
Deswegen mein Appell: Die Softwareentwicklung für Liquid Democracy muss selbst demokratisch gesteuert werdem.
Dafür geben uns diese System schon gleich die Hilfsmittel selbst mit an die Hand. Über neue Features und Changerequests kann man - gerade mit einem Delegiertensystem - hervorragend diskutieren und abstimmen!
Allerdings gleich eine Warnung: Wir dürfen dabei nicht übersehen, den Softwareentwicklern genügend Spielraum zu lassen eigene Ideen einzubringen. Wir können ja nicht über jede Zeile Code abstimmen.
Zudem scheint es mir angebracht, den Rahmen der Kick-offs und Closures von der Personenzahl zu begrenzen. Hier könnte uns das Delegiertensystem zuhilfe kommen.
Ein solcher SE-Modellprozess wäre nicht nur wegweisend sondern könnte weit über die Piratenpartei hinaus bei vielen Aufträgen aus öffentlicher Hand angewendet werden.
Die Piratenpartei würde damit einen Schritt gehen, den bisher noch keiner gewagt hat: Rekursive Demokratie!
Ein guter Appell, den ich jedoch nur teilweise unterstützen kann. Erstens: es geht bei Agile nicht unbedingt demokratisch zu. Ein Product Owner priorisiert das Backlog und setzt damit die Agenda für die Entwicklung (das von Dir beschriebene Verhandeln der Prio habe ich noch nirgendwo aufgeführt gesehen, verhandelt werden doch Story pts, oder?).
Ich bin mir einfach nicht sicher, inwiefern Engineering dadurch verbessert wird, dass man alle zu den Aufgaben und Zielen abstimmen lässt. Letztlich führt das entweder zu Pony-Treffen oder zu fehlplatzierten Agenden. User wissen nicht, was sie wollen. Demokratie ist hier vielleicht fehl am Platze, es bedarf der Meritokratie.
Eine (wichtige!) Ausnahme stellen hier vermutlich grundlegende Entscheidungen zu Abstimm- und Beschlussmethode in LD-Tools dar: diese müssen offen verhandelt werden, m.E. insbesondere auch ohne Delegation!
Noch eine Anmerkung: ich bin mir nicht sicher, ob die Piratenpartei an sich Software entwickeln sollte. Bisher findet diese Entwicklung in angelagerten Vereinen statt - und das ist auch gut so. Denn in der Machtstruktur und vor allem der Groupthink-Wolke einer Partei (grade der Piraten, mit extrem computergeprägten Vorstellungen von Politik!) entsteht vermutlich eigenartige Software.
Viel spannender ist übrigens die umgekehrte Überlegung zu Deinem Vorschlag: Was wäre, wenn wir agile Politikentwicklung erfinden? Der Gedanke treibt mich seid einer Weile um und scheint mir extrem attraktiv: Politische Lösungen brauchen Testfälle (die Idee habe ich mal hier zusammengefasst), Akzeptanztests, Sprints, inkrementelle Verbesserung usw. Lean Law, Agile Anträge -- das wäre wirklich interessant. Entwickelst Du mit?
Lg, Friedrich --Pudo 09:39, 27. Apr. 2010 (CEST)
