Überlegungen zur Dekonstruktion des rational-antizipativen Planens in der (alt-)europäischen Tradition

Der folgende Blogpost geht auf ein Thema ein, das mich im IT-Kontext mit Blick auf sog. “agile” Entwicklungsmethoden (Extreme Programming, Crystal, Scrum, etc.) schon seit langem interessiert: die Dekonstruktion des rational-antizipativen Planens in der alteuropäischen Tradition (und ihre Fortschreibung bis heute) sowie die Suche nach “funktionalen Äquivalenten” zu dieser Herangehensweise.
Die nachfolgenden Überlegungen können als einen ersten Einstieg in dieses Thema angesehen werden. Eine IT-relevante Tieferlegung ist dann für das folgende Blogprojekt geplant, das mangels Zeit im Moment noch eine Baustelle darstellt: http://peteroncomplexity.wordpress.com/. Ich hoffe, daß sich dieser Zustand in Zukunft ändern wird. Und vielleicht finden hier auch Nicht-IT-affine Zeitgenossen  die eine oder andere interessante Information zu Fragen des Organisierens und des Managens (über die IT hinaus).

Bezugsproblem: The (wo)man with the plan
Wenn wir etwas organisieren oder (z.B. technisch) produzieren wollen, dann liegt es in der (alt-)europäisch-westlichen Tradition nahe, zu planen, zu planen und nochmals zu planen. Hierbei erfolgt ein Management von Komplexität, bei dem in den Sach-, Zeit- und Sozialdimensionen des Sinns Erkennen und Handeln, Zwecke und Mittel, Soll- und Ist-Werte, zeitliche Vorgaben (Beginn, milestones, deadlines, Verlängerungen, etc.), Personen, Rollen und Verantwortlichkeiten, usf. in bestimmte Zusammenhänge gebracht werden sollen.
Die Crux ist freilich, daß “antizipierendes Planen”, das in der Folge realisiert werden soll (= Umsetzung in Handlungen, Texte, Produkte aller Art), primär in stabilen Kontexten und bei einfachen bzw. bei komplizierten Problemstellungen, die sich elegant auf Einfaches zurückführen lassen, funktioniert. Sobald die Kontexte dynamisch sind (Beispiel im IT-Bereich: ständig wechselnde Anforderungen an ein zu erstellendes Softwareprodukt) und das spätere Produkt nicht antizipiert werden kann, weil niemand vorab weiß, wie das Endresultat aussehen kann (Motto: “I know it when I work with it), läuft ein antizipativer Planungsansatz tendenziell ins Leere:
* Es besteht die Gefahr der “analysis paralysis”.
* Pläne werden rasch zur Makulatur.
* Pläne sind ständig anzupassen im Sinne einer rollierenden Planung.
* Es werden Berge an Dokumenten (und Modellen) produziert, die ihrerseits nachzupflegen sind.
* Produkte und ihre Dokumentation divergieren zunehmend.
* Die Dokumentenexplosion führt zu einer Komplexität, die ihrerseits kognitiv / kommunikativ kaum zu verarbeiten ist.

Woher stammt dieser antizipative Planungsansatz?
Die antizipativ-planungsbasierte Weise des Komplexitätsmanagements kann in der europäischen Tradition bis zur griechischen Antike zurückverfolgt werden. Das zugrunde liegende Prozedere, das mutatis mu­tandis bis heute gilt und sich u.a. auf die Leitunterscheidung von “Erkennen / Handeln” bezieht, läßt sich dabei im Anschluß an Jullien(1999) wie folgt zusammenfassen [nachfolgende Zitate aus Bormann (2003), S. 4ff.]:
* Den Ausgangspunkt bildet eine “ideale Zwecksetzung” (traditionell: die Abstrak­tion von einer ontologischen Idealform (eîdos), heute: eine Soll-Vorgabe) die als Mo­dell oder (Handlungs-)Plan ausgearbeitet wird.
* Diese “Logik” der Modellierung, bei der ein Modell / Plan zu entwickeln und in die Zukunft zu projizieren ist, bzw. diese “Logik” der Inkarnation, bei der sich eine Pro­­jekt-Idee in der Zeit konkretisieren soll, ist erkenntnis- und theoriegeleitet. Die Hand­lungen sollen also nicht einfach spontan (ohne Theorie, ohne Plan, ohne klare Bestimmung der Ziele und der Mittel, etc.) erfolgen.
* Zwecksetzung, Modellierungs- und Planungstätigkeit weisen Entscheidungscharakter auf: Die Entscheidung betrifft die Selektion der Soll- und Ist-Vorgaben, die Ausarbeitung der Modelle und Pläne, die Wahl der geeigneten Mittel und generell: die Entscheidung, via Handeln in der Wirklichkeit zu intervenieren.
*   Die Entscheidung geht einher mit der Notwendigkeit, Handeln zuschreiben zu können. Daher ist eine Instanz vorauszusetzen, die frei ist, zu entscheiden, so daß Verantwortung und Schuld für das Handeln “dem Individuum” an­ge­rechnet wer­den kön­nen. Diese Instanz wird in der alteuropäischen Tradition “Wille” genannt.
  *   Der Wille setzt das Modell / den Plan als Ziel (télos). Der Wille war seit Aristoteles aber nicht nur die (Entscheidungs-)Fähigkeit, das gewünschte Ziel zu erreichen, son­dern zugleich und vor allem die Fähigkeit, das Gute zu wollen (boulesis) [Jullien (1999), S. 56]. Die Zweck- bzw. Ziel-Beschaffenheit war in der griechischen An­tike also mo­ralisch eingehegt, was wiederum der selbstverständlichen Wahrheits­geltung der Zwecke zuarbeitete.
*    Ein zweiter Aspekt der Entscheidungsfähigkeit bezieht sich auf die moralisch neutrale, rein technische Dimension der Auswahl und des Einsatzes der geeigneten Mit­tel. Diese mittelbezogene Entscheidungsfähigkeit wurde bei Aristoteles als proairesis bezeichnet.
Die Kopplung der Leitunterscheidungen Erkennen / Handeln und Medium (Sprache)/ Welt (Wirklichkeit) verweist nun auf eine “Kluft”, die sich zwischen Erkennen (Setzen der Soll-Vorgabe, Modellieren, Planen) bzw. Theorie und Wirklichkeit bzw. Praxis auf­tut. “Die” Wirklichkeit im Sinne von natürlichem Objektpol als auch von sozialem Gegenhandeln wird dann als dem voluntaristischen, erkenntnis- und theoriegeleiteten Handeln Widerständiges angesehen. Das hat verschiedene Konsequenzen:
Erstens wird die Erkenntnis- und Theoriekomponente betont. Die Planungs-, Modellierungs- und Prognoseaktivitäten werden vielfältiger, gerade weil Blockaden, Widerstände, das mögliche Scheitern, Situationsveränderungen, etc. antizipativ berücksichtigt wer­­­den sol­len. Das bedeutet, nicht nur Ersatz- und Notfall-Pläne, best– und worst-case-Sze­na­rien, u.ä. zu entwickeln, sondern auch die Pläne, Modelle und Prognosen rasch an neue Gegebenheiten anzupassen. Insgesamt gesehen liegt der Akzent also auf Proaktivi­tät.
Zweitens wird der Voluntarismus forciert. Sich gegen das Widerständige zu behaupten bzw. es zu bezwingen verlangt verstärkte Willensanstrengung, persönliche Initiative, die Aufbietung aller geistigen und körperlichen Kräfte, etc.
Drittens wird beim Handeln selbst angesetzt, so daß es zu einem permanenten Aktivismus kommen kann.
Gleichwohl ist im (alt-)europäisch-westlichen Kategorien”system” die besagte Kluft nicht wirklich zu beseitigen. Bestimmte “Residual”begriffe können dann nur ihrer Bear­­beitung bzw. Reduzierung dienen.
Hierzu gehört seit Aristoteles ein “praktisches Vernunftvermögen” (die phrónesis), das sich am situativen Einzelfall, an günstigen Gelegenheiten, an der passenden Zweck-Mit­tel-Abstimmung, etc. orientiert. Diese praktische “Klugheit” sollte als spezielle In­tel­li­genz der kontingenten (= zufällig-wahrschein­lichen), situativ-variablen und riskanten Hand­lungsdimension entsprechen. Allerdings ohne in amoralische, rein am persönlichen Erfolg und Vorteil orientierte “Gerissenheit” (im Sinne der metis) abzudriften. Der in der griechischen Antike einsetzende Moralisierungsschub beinhaltete daher eine Aus­­gren­­zungs­ar­beit gegenüber der metis einerseits, gegenüber den sich an der metis ori­en­tierenden So­phi­sten andererseits.
Den Hauch des Amoralischen, des Ruchlosen und der malicia konnte diese radikal erfolgs­­orientierte, flexibel-listig-wendige Intelligenzform in der (alt-)europäisch-west­li­chen Tradition nicht mehr ablegen. Durch eine moralische Diskreditierungs- und Margi­na­lisierungsarbeit wurde sie daher in der Folge   zum (macht-)politischenArkanum,          in das kriminelle Milieu von Gaunern, Trickbetrügern, etc. verlegt,  oder existenziellenAusnahmesituationen, in denen moralische Bedenken zurückgestellt werden, vorbehalten.
[…]
Abgesehen von der “praktischen Rationalität” kamen noch weitere Residualkonzepte zum Einsatz, um die Kluft zwischen Erkennen und Handeln, Theorie und Praxis, Spra­che und Welt / Wirklichkeit zu verringern: Zum einen am Individuum fest­zuma­chen­­­­de Qualitäten wie Erfahrung / Routine, Charakter, Talent oder Genialität; zum anderen Unvorhersehbarkeiten wie Zufall, (Un-)Glück oder kairós (die auf die Handlungssphäre bezogene Zeit der günstigen und flüchtigen Gelegenheiten). Diese Unvorhersehbarkei­ten wurden als nicht zu beseitigende (“irrationale”) Störgrößen mit Ereignischarakter angesehen, die über das gesamte Wohl oder Wehe einer Unternehmung entscheiden konn­­ten. Aus diesem Grunde mußte letztlich auf das Schicksal bzw. den göttlichen Beistand, der sich auch in Gestalt von Wittgensteins “Engel” manifestieren konnte, vertraut wer­den.
Wille und Handeln müssen sich aber nicht nur gegen die natürlich-soziale Wirklichkeit als Widerständiges behaupten und durchsetzen. Sie fungieren auch selbst als Widerstands­erzeuger. Denn die Entscheidung, in die Wirklichkeit einzugreifen bzw. die Initiative zu ergreifen, schlägt sich in einem sichtbaren Handeln nieder, durch das eine Situation explizit bestätigt oder umgestaltet werden soll. Dieses Handeln kann nicht nur einem Individuum als Ursache, Verantwortung und Schuld zugeschrieben werden, es ist auch “auf­dringlich”: kühn bis riskant, zwingend bis gewaltsam, mitunter spektakulär, heroisch bis tragisch, etc.
Solch ein sichtbares und explizites Handeln, zumal wenn es mit einer entsprechenden Selbststilisierung einhergeht, zieht Aufmerksamkeit auf sich. Es beschwört bestimmte so­­ziale Erfahrungen wie Neid, Rivalität, Konkurrenz, etc. und damit alle möglichen Ar­ten des Widerstands (Blockieren, Obstruieren, Verschleppen, usf.) her­auf. Das kann wie­­­­­derum den Voluntarismus, den sich selbst verausgabenden Aktivismus und bestimm­­­­­­te Selbst-Erfahrungen (die Lust am Abenteuer oder am Risiko, die Freu­de am Un­bekannten, usw.) nähren, die noch mehr Widerstand erzeugen.
Aus der Sicht der altchinesischen Strategietradition kann das nur bedeuten, daß es letzten Endes im Westen nicht unbedingt auf radikale strategische Wirksamkeit als vielmehr auch (und vor allem?) darauf ankam, sich als besonderes Individuum in dieser Wi­derstands- und Selbststilisierungsarbeit zu konstituieren bzw. als “lebendig” zu erfah­ren [vgl. Jullien (1999), S. 262].
[Zitat-Ende].

Obige Weichenstellungen haben dann entsprechende Folgen für die Ausarbeitung der (alt-)europäischen Konzeptionen von Strategie (Wirksamkeit, Listigkeit, Gerissenheit, etc.), Macht / Einfluß und Moral gezeitigt [für Details siehe Bormann (2003).  Zur altchinesischen Alternativkonzeption siehe vor allem Jullien (1999)].  Sie haben aber in der Folge generell auch das antizipierende, an Zwecken und Mitteln orientierte Planen, Modellieren und Managen in der Wirtschaft, in der Politik, in der Technik, im Krieg, etc. beeinflußt.
Das berühmte Bienen-Baumeister-Beispiel von Karl Marx kann nun als Fortschreibung dieser (alt-)europäischen Traditionslinie angesehen werden:
“[…] eine Biene beschämt durch den Bau ihrer Wachszellen manchen menschlichen Baumeister. Was aber von vornherein den schlechtesten Baumeister vor der besten Biene auszeichnet, ist, dass er die Zelle in seinem Kopf gebaut hat, bevor er sie in Wachs baut. Am Ende des Arbeitsprozesses kommt ein Resultat heraus, das beim Beginn desselben schon in der Vorstellung des Arbeiters, also schon ideell vorhanden war.” – Karl Marx, Das Kapital. Band 1, MEW 23, S. 193 [http://de.wikiquote.org/wiki/Biene].
Das heißt, die “Materialisierung des Ideellen” als Realisierung der Vorstellung einer “Wachszelle” umfaßt:
* Eine ideale Zwecksetzung = Sollvorgabe in Form eines (u.U. nur gedachten) Modells oder Plans der Wachszelle.
* Die Realisierung des entsprechenden Plans / Modells erfolgt theorie- und erkenntnisgeleitet, also nicht irgendwie zufällig-spontan und beliebig.
* Es sind Entscheidungen notwendig (Soll-Ist-Vorgaben, Zweck-Mittel-Setzungen, etc.).
* Es wird ein “Wille” zur intentionalen Zielerreichung zugeschrieben.
* Die Realität (hier: das “Wachs”) wird als Widerständiges angesehen, gegen das gehandelt wird (Einprägung einer Wachszelle).
In dieser (alt-)europäischen Traditionslinie kommt es also auf Rationalität, Intentionalität, Antizipation / Proaktivität, Dezision, Voluntarismus und Handeln / Handlungsfähigkeit an, wobei im vormodernen Kontext eine an stabilen Identitäten orientierte, ontologische Beobachtungsweise dominierte.Was in dieser antizipativ-planenden Weise des Komplexitätsmanagements dann systematisch marginalisiert wurde, waren u.a.:
* Prozessuales, v.a. als dynamische und hochvariable Änderungen, z.B. in den Planungsanforderungen, oder im strategisch-taktischen Gegenhandeln durch andere,
* situationsspezifische Eigenheiten, die sich dem Allgemeinen entziehen,
* “information overload” / “analysis paralysis” durch zu viel (kognitive) Komplexität,
* Zufällig-Spontanes.
Hierbei mußte sich  an der “Kluft” zwischen Soll und Ist, Erkennen und Handeln, Theorie und Praxis, Medium und Welt  systematisch und planungsbasiert abgearbeitet werden  Planen hatte vor diesem Hintergrund zentrale latente Funktionen:
* Erstens als Mittel, um sich mit einer bestimmten thematischen Komplexität vertraut zu machen (= Informationssammlung, u.ä.).
* Zweitens als Mittel, um sich für Nicht-Planbares zu “sensibilisieren” (= Abweichungssensibilität entwickeln und steigern, so daß ein Nachjustieren permanent möglich wird).
* Drittens als Legimationsgrundlage, z.B. im Falle des Scheiterns eines Projekts.

Funktionale Äquivalente zur antizipativen Planung
Es zeigt sich heute zunehmend, daß für komplexe, explorative und dynamisch variable Projekte ein antizipativ-planungsbasiertes Vorgehen im traditionellen Sinne wohl inadäquat ist. Das Scheitern größerer Projekte gerade in der IT ist daher m.E. kein Zufall und nicht einfach nur auf individuelle Fehler, Inkompetenzen, u.ä. zurückzuführen, sondern hängt grundlegend mit dem antizipativ-planungsbasierten Management von Komplexität in solchen Projekten zusammen. Das ist zumindest die These.

Welche Alternativen existieren nun für das Management obiger Projektvarianten?
Eine interessante Frage ist, ob die alt-chinesische Wirksamkeitstradition à la Jullien, die sich primär auf Prozessualitätsaspekte im Sinne einer Transformationsdynamik, einer sich invisibilisierenden Transformationsarbeit (“Nicht-Handeln”), etc. fokussiert, auch für Software-Entwicklung und (Projekt-)Management fruchtbar gemacht werden kann. Das ist dann ein Themenstrang, der im eingangs erwähnten Peteroncomplexity-Blogprojekt weiter verfolgt werden soll.
Konkretere Alternativen wurden seit vielen Jahren im IT-(nahen) Umfeld durch sog. agile Ansätze wie Extreme Programming (XP) ausgearbeitet und auch konkret erprobt [siehe http://de.wikipedia.org/wiki/Agile_Softwareentwicklung].  Der Schwerpunkt wird hier verlagert weg von der antizipativen Planung und der zugehörigen Dokumentenexplosion hin zur Prozessualität im Sinne
* von oraler Kommunikation als Paar-Programmierung unter Entwicklern und als direkte Einbindung von Kundenvertretern in ein konkretes IT-Projekt,
* von Benutzer-Stories [siehe http://de.wikipedia.org/wiki/Story-Card], die die Anforderungen erfassen, die in der Software realisiert werden sollen – ohne daß hier eine vollständige Antizipation im Vorfeld angestrebt wird,
* von schneller Erstellung eines funktionsfähigen Programms, bei der ein test-first / code-later-Ansatz mit zugehörigen Code-Umbauarbeiten (sog. “Refactorings”) und kontinuierlicher Integration (als ständiger Erstellung einer ablauffähigen Testversion eines Programms) im Sinne der testgetriebenen Entwicklung verfolgt wird, so daß schnell und flexibel auf Kundenfeedback und Änderungswünsche eingegangen werden kann.
Graduell wird hierbei die Komplexität eines Softwareprodukts aufgebaut, ohne daß diese Komplexität antizipativ analysierend und planend vorab zu kalkulieren gewesen wäre.
Mit anderen Worten: In agilen Ansätze wie XP wird die  Zeitdimension (als milestones / deadlines) wie in planungsbasierten Ansätzen möglichst konstant gehalten, aber die Sozialdimension als oral-interaktionale Feedback-Dynamik wird gegenüber der früheren Dokumentenzentrierung aufgewertet. In der Sachdimension kommen zugleich inkremementelle Redeskriptionprozesse im Sinne testbasierter Refactorings plus ständiger Integrationen mit Blick auf die Erstellung abläufiger Programme zum Tragen.

Ein Beispiel zur Veranschaulichung:
Ein Sachtext kann geschrieben werden, indem zu einem Thema möglichst viel Informationsmaterial gesammelt, eine erste Gliederung und ein Zeitplan aufgestellt werden. Im Laufe der Zeit kommt neues Informationsmaterial hinzu, anderes wird verworfen, die Gliederung und der Zeitplan müssen überarbeitet werden. Ganz am Ende steht ein Text, der dann von Betreuern / Lektoren begutachtet werden soll. Bevor mit dem konkreten Schreiben begonnen wird, wird also zuerst extrem viel Informationsmaterial verarbeitet, ohne daß dessen Relevanz vorab vollständig klar sein wird.
Ein agile Schreibvariante würde zwar auch einen Zeitplan aufstellen, aber mit dem Schreiben sofort beginnen. Das heißt, eine Gliederung wird an verschiedenen Stellen rasch ausformuliert. Betreuer / Lektoren erhalten nun frühzeitig Kurzfassungen zugesandt mit Bitte um Feedback. Diese Feedbackwünsche und die graduelle Erarbeitung weiteren Informationsmaterials werden danach in die textuelle Überarbeitung integriert. Der Text entsteht dabei durch mehrere (überschaubare) Zyklen der  Lektüre, der Redeskription und des Feedbacks bis schließlich eine Schlußfassung vorliegt, die als (provisorisch) endgültig angesehen wird.
Vorteile dieses agilen Vorgehens:
* Die Komplexität des Themas kann so bearbeitet werden, daß frühzeitig konkrete Textpassagen vorliegen, was der eigenen Motivation und der kognitiv-gedächtnismäßigen Entlastung zugute kommt.
* Feedback kann frühzeitig eingebaut werden.
* Die Durststrecke “zuerst extrem viel lesen und dann spät etwas schreiben” wird ersetzt durch eine Vielzahl kürzerer Lesen-Schreiben-Feedback-Zyklen.
* Thematische Komplexität wird nicht antizipativ aufgebaut, sondern beruht auf den Erfahrungen aus Schreib-, Lese- und Feedback-Zyklen, wobei es zu ständigen Transformationen kommt.

Marxens Baumeister verwandelt sich vor diesem Hintergrund von einem ab einem gewissen Komplexitäts- und Prozessualitätsgrad zum Scheitern verurteilten Informationsprozessor zu einem prozessual orientierten, zufalls- bzw. überraschungssensiblen, graduell-inkrementell die Komplexität steigernden Umschreiber (Redeskriptor).

Referenzen:
Bormann, P. (2003), Über Strategie. Die Wirksamkeitstraditionen Alteuropas und Altchinas im systemtheoretischen Vergleich, URL:  http://www.fen.ch/texte/gast_bormann_strategie.pdf

Jullien, F. (1999, frz. 1996), Über die Wirksamkeit, Berlin: Merve..

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • kybernetiks  On May 13, 2012 at 11:49 AM

    hmmmm… Das ist ziemlich viel Material auf einem Haufen. So wird die Sache komplex und jetzt wäre die Frage nach der Selbstanwendung …

    oder wir picken in Blog-Manier einfach raus, was gerade so kommt:
    Deine Leseweise von Marxs Bienenbeispiel finde ich sehr alteuropäisch. Ich kann bei Marx an den Stellen, wo das Bienenbeispiel steht nichts davon finden, absolut gar nichts. Das heisst, Du verwendest das Beispiel kontextfrei oder in einem völlig eigenen (alteuropäischen) Kontext.

    Bei Marx würde ich lesen, dass menschliche Arbeit einer Zwecksetzung folgt, die in kapitalistischer Form ausschliesslich “Kapitalverwertung” heisst, aber immer auch Gebrauchswerte vorstellen muss. Während die Biene einfach tut, was sie tut, verfolgt der Mensch einen Zweck – ob er dabei plant und plant oder nicht spielt an besagter Stelle bei Marx nicht im leisesten eine Rolle.

    Nun wäre die Frage, ob ich ein zufälliges Nebenargument von Dir aufgepickt habe.

    Auch ganz herausgepickt will ich etwas zur Wahl Deines Beispiels sagen: Textproduktion in einer Verlagsindustrie. Das scheint mir nicht gerade von zentralem Belang, wenn wir über Informatik und Technik nachdenken. Oder genauer gesagt: Alle Inhalte des Textes haben hier keinerlei Bedeutung (C. Shannon). Interessant wäre unter technischen Gesichtspunkten lediglich die materielle Produktion des Artikels beispielsweise in einem Buch. Welche Werkzeuge werden eingesetzt? Die Binnedifferenzierung des Schreibens (Autor/Lektor) schaft zwar Komplexität und erfordert Organisation, aber sie ist gerade keine Technik, sondern setzt allenfalls Technik voraus.
    Das Herstellen eines Textes setzt aber unabhängig von allem Planen einen Zweck voraus – wenigstens wenn der Text nicht von einer Biene geschrieben wird.

    Fazit: Du vermischst in alt/neu-europäischer Tradition Zweck und Plan. Kybernetisch – was man ohne weiteres auch als alt-irgendetwas bezeichnen kann – würde die Zwecksetzung mal aussen vor gelassen und der Mechanismus beschrieben. Das Planen würde sich dann allenfalls in der von Dir beschriebenen Art des Planens zeigen – die ich ziemlich normal finde: kleine Einheiten werden fixer geplant, grössere Zusammenhänge rollender.

  • PB  On May 13, 2012 at 12:33 PM

    > Bei Marx würde ich lesen, dass menschliche Arbeit einer Zwecksetzung folgt,
    > die in kapitalistischer Form ausschliesslich “Kapitalverwertung” heisst, aber
    > immer auch Gebrauchswerte vorstellen muss. Während die Biene einfach tut, > was sie tut, verfolgt der Mensch einen Zweck – ob er dabei plant und plant
    > oder nicht spielt an besagter Stelle bei Marx nicht im leisesten eine Rolle.
    Das sehe ich etwas anders. Die Zweck-Mittel-Unterscheidung wurde anscheinend ursprünglich im griechisch-antiken Kontext dazu genutzt, Handeln in eine Seinsorientierung integrieren zu können. In der Folge wurde diese Unterscheidung dann (in anderen Kontexten) fortgeschrieben. Aber sie ist
    weder universell noch selbstverständlich, sondern entstammt spezifischen Traditionslinien. Iim alten China scheint diese Unterscheidung unbekannt gewesen zu sein, siehe Jullien 1999, weil hier ganz anders angesetzt wurde.
    Ich kann freilich nicht erkennen, daß in der marxistischen Tradition eine Dekonstruktion der Zweck-Mittel-Unterscheidung und allem, was im Umkreis dazu gehört (Soll-Ist-Werte, Planung, etc.), je vorgenommen wurde. Die sozialistische “Plan-Wirtschaft” mit ihren Kontroll- und Steuerungsillusionen war daher “kein” historischer Zufall…

    “Textproduktion in einer Verlagsindustrie. Das scheint mir nicht gerade von zentralem Belang, wenn wir über Informatik und Technik nachdenken.”
    Das Beispiel ist “kontingent” und nur gewählt worden, weil es Programmieren als eine spezifische Art der Textproduktion veranschaulichen kann. Zentral ist hierbei, in welcher Art und Weise die dabei anfallende “Komplexität gemanagt” werden kann.

    “Das Herstellen eines Textes setzt aber unabhängig von allem Planen einen Zweck voraus – wenigstens wenn der Text nicht von einer Biene geschrieben wird.”
    Du unterstellst das bei jedem Herstellen / Organisieren vorab ein Zweck voraus-gesetzt werden muß. Das kann sein – muß aber nicht sein. Wie der Organisationstheoretiker Weick `mal schrieb, man kann auch s0 vorgehen: “action comes first und dann wird überlegt, wozu das taugen könnte…”.

    Eine Universalität und Unumgänglichkeit der Zweck-Mittel-Geltung ist jedenfalls nicht gegeben – siehe Jullien 1999.

    > Planen würde sich dann allenfalls in der von Dir beschriebenen Art des
    > Planens zeigen – die ich ziemlich normal finde: kleine Einheiten werden fixer > geplant, grössere Zusammenhänge rollender.
    Nein, der Witz bei agilen Methoden in der Software-Entwicklung ist gerade: es gibt keine Pläne und kein antizipatives Planen mehr, sondern es wird mit funktionalen Äquivalenten gearbeitet. Und das ist ein “großer” Unterschied zum dokumentenzentrierten Wasserfall-Modell und Konsorten.

  • kybernetiks  On May 13, 2012 at 4:18 PM

    hmmm … Du hast ja auf Marx’s Textstelle mit der Biene verlinkt. Dort kann man doch nachschauen. Aber jetzt bringst Du die sozialistische Planwirtschaft ins Spiel. Was hat das eine mit dem andern zu tun? Ich glaube, dass Du da Dein Zweck-Mittels schlicht hinprojektierst. Aber ok, wenn das in Deiner Theorie wichtig ist …

    Mich würde interessieren, wie ich mir die agile Methode mit funktionalen Aequivalenten vorstellen sollte. Hast Du dazu ein Beispiel dafür, was Programmierer tun, wenn sie dieser Methode folgen. Oder betrifft das nicht das Programmieren?

  • PB  On May 13, 2012 at 7:20 PM

    “Aber jetzt bringst Du die sozialistische Planwirtschaft ins Spiel. Was hat das eine mit dem andern zu tun? ”
    Die These ist: Marx und die marxistischen, sozialistisch-kommunistischen Varianten (wobei ich nicht von einer einfachen Kontinuität zwischen Marxens Werk und den sozialistisch-kommunistischen Planwirtschaftsvarianten ausgehe) haben die skizzierte alteuropäische Tradition, mutatis mutandis, fortgeschrieben. D.h. die basalen Leitunterscheidungen (Erkennen-Handeln, Zweck-Mittel, etc.) sowie die antizipative Planungsorientierung wurden beibehalten.
    Das gilt freilich auch mehr oder weniger für marktwirtschaftliche Spielarten.

    Du solltest wirklich `mal Jullien lesen: das ist definitiv interessant!

    > Mich würde interessieren, wie ich mir die agile Methode mit funktionalen
    > Aequivalenten vorstellen sollte.
    Seltsam. Das steht eigentlich im obigen Text. Statt antizipativ orientierten Planungen werden verwandt: user stories, oral-interaktionale Feedbackstrukturen, testgetriebene Entwicklung mit ständigen Refactorings und Integration, etc. (je nach agilen Varianten gibt`s aber Unterschiede).

    Die Gemeinsamkeit agiler Methoden ist wohl die Absage an antizipativ-, planungsorientierte und dokumentenzentrierte Vorgehen à la Wasserfallmodell. Siehe hierzu auch: http://agilemanifesto.org/

  • Rolf Todesco  On May 13, 2012 at 8:05 PM

    ah, das ist mir etwas abstrakt, ich kann mir nicht vorstellen, was das am Arbeitsplatz konkret bedeutet. Aber gut, hier ist vermutlich nicht der Ort für eine praktische Darstellung. Im hergebrachten Fall würde ich aber mit wenigen Worten sagen können:
    Ein Kunde will ein Fakturierungsprogramm, das ein paar Bedngungen erfüllt, die im Pflichtenheft stehen. Der Programmierer hockt sich hin und schreibt den Code. Dann schauen der Kunde und der Programmierer obs passt.
    Ich kann mir schlecht vorstellen, was ein Programmierer sonst tun könnte (auch wenn ich mir leicht vorstellen kann, dass er sich selbst einen Auftrag gibt, also auch die Kundenrolle spielt).

    äähhh .. das Manifest spricht Hohn. Da steht kein Satz drin, der nicht aufgezählt wurde seit es Softwarehäuser gibt. Es ist das Leitbild, das wir in den 80erJahren des letzten Jhd hatten

    • Peter Bormann  On May 13, 2012 at 8:34 PM

      > Ein Kunde will ein Fakturierungsprogramm, das ein paar Bedngungen erfüllt, die im Pflichtenheft stehen. Der Programmierer hockt sich hin und schreibt den
      > Code. Dann schauen der Kunde und der Programmierer obs passt.
      So, so :-)
      Der Kunde “weiß” am Anfang oft gar nicht, was er in einer gegebenen Zeit, mit Blick auf ein gegebenes Budget und bestimmte Qualitätsanforderungen alles will. Und die Programmierer wissen das auch nicht. Und wenn sie die Anforderungen erfassen und umzusetzen beginnen, dann fallen dem Kunden noch neue oder andere Anforderungen ein. Und wenn das Produkt erst vollständig entwickelt (wenn das Projekt nicht vorher scheitert) und dann erst dem Kunden gezeigt wird, dann kann es sein, daß das einfach abgelehnt wird.

      Wenn alles so “simpel” ware, wie Du schreibst, dann bräuchten wir weder agile / nicht agile Methoden – noch überhaupt Software Engineering. Sowohl das Engineering i.a. als auch die agilen Ansätze haben sich entwickelt, weil weder chaotisches Vorgehen noch Planungswahn (bei mittleren und größeren Projekten) Erfolg gezeitigt haben. Wir reden hier über “professionelle Software-Entwicklung” und nicht irgend ein wildes Herumgehacke in Mami`s Keller.

  • Cosmo  On May 14, 2012 at 9:56 AM

    “Eine IT-relevante Tieferlegung [der Dekontruktion des Planens?] ist dann für das folgende Blogprojekt geplant”

    Das Planen zu dekonstruieren ist langfristig gesehen ein guter Plan, den man im Auge behalten sollte!:) Wenigstens ist bereits ein Ziel anvisiert!

  • Rolf Todesco  On May 14, 2012 at 10:22 AM

    ähhhh … profesionell tönt gut, wie agile Methode. Können wir dann bitte doch mal auf ein konkretes Projekt schauen?

    Ich kann aus meiner etwas weiter zurückliegenden Erfahrung berichten. Und Du kannst ja dann sagen, wie professionell und agil meine Erfahrungen im Vergleicht zu einem aktuellen Projekt von Dir – oder das Du als Beispiel siehst – sind.

    Ich habe eine sogenannte Standard-Lösung für Schweizer Tourismus-Operater (Charterbusiness) betreut.
    Am Anfang hat niemand von Standards gesprochen. Der Kunde wollte sich mit EDV einen Vorteil schaffen. Also ein normales Projekt (nicht im Keller, sondern in einer Software-Firma mit etwa 20 Mitarbeitern, Professionalität war das Hauptwort des Firmeninhabers ;-)

    Der Kunde sagte also, was er mindestens braucht. Wir haben dann programmiert, was wir davon verstanden haben. Bevor die Software benutzbar war, war sie schon viel zu teuer. Dann waren wir agil und suchten einen zweiten Kunden mit vergleichbarem Geschäft. Nun waren zwei Kunden da, die laufend neue Ideen hatten.

    Ich erzähle gerne weiter – aber vielleicht meinst Du ja etwas gaaanz anderes.

    • PB  On May 14, 2012 at 6:03 PM

      @Cosmo:
      > Das Planen zu dekonstruieren ist langfristig gesehen ein guter Plan, den
      > man im Auge behalten sollte!:) Wenigstens ist bereits ein Ziel anvisiert!
      Nicht jeder “Plan” ist schon ein “Planen”. “Plan” war hier eher gemeint als: “ein mögliches Thema” (neben anderen Themen, denn letztlich interessiert mich die Anwendung von diversen soziologischen Ansätzen auf Fragen der Software-Entwicklung und des IT-Projektmanagements generell).
      Das erinnert dann eher an das Jazz-Orchester von Weick in “Der Prozeß des Organisierens”: Es werden Töne angestimmt und dann improvisierend weitergearbeitet – bis eine entsprechende Komplexität aufgebaut wird, ohne daß vorab ein zu erreichendes Ziel = Song fixiert worden wäre.
      Das Vorgehen muß daher nicht (unbedingt) antizipativ-planend und entsprechend der Ziel-Zweck-Mittel-Relation erfolgen.

      @Rolf:
      Die Thematisierung von agilen Methoden in der Software-Entwicklung / im IT(Projekt-)Management ist (neben model-driven und service-orientierter Anwendungsentwicklung mit Blick auf BP-Modeling / Automatisierung) ein Hauptfokus des besagten IT-Blogs. Ich würde das gerne “dort” in Blogposts entfalten und dann hierher verlinken.

      > Der Kunde sagte also, was er mindestens braucht. Wir haben dann
      > programmiert, was wir davon verstanden haben. Bevor die Software
      > benutzbar war, war sie schon viel zu teuer.
      Klingt völlig “klassisch”.

      > Dann waren wir agil und suchten einen zweiten Kunden mit vergleichbarem
      > Geschäft.
      Ich weiß überhaupt nicht, was “agil” hier meint: eine agile Kundensuche? Was hat das mit Software-Entwicklung und IT-Projektmanagement zu tun?
      Ich meine mit “agil” bspw. “Extreme Programming” als Ansatz [Details in: http://de.wikipedia.org/wiki/Extreme_Programming%5D: über user stories (quasi: abgespeckte use cases) werden in Kombination von Paarprogrammierung, TDD (test-driven development), refactoring und continuous integration und einigen anderen Prinzipien [siehe den XP-Link]) immer neue Software-Releases herausgebracht, um Kundenfeedback frühzeitig (!) und permanent (!) zu integrieren.
      Das heißt auch: Tests erfolgen nicht einfach am Ende eines Zyklus, sondern es werden Unit Tests formuliert und “dann” der zugehörige Code geschrieben (= test-first-Approach: test – code – refactor – test…). Zudem gibt es dann noch ständige Integrationstests (im Sinne der continuous integration).
      “Das” meine ich mit “agil” (also: kein Anspruch, möglichst viele requirements vorab und fix zu erheben, kein detailliertes Vorab-Planen, keine Dokumentenzentrierung, keine separate Testphase, etc.).

      * Hier eine berühmte Fallstudie dazu, die das wohl weitaus besser darstellen kann, als es mir hier in einem kurzen Kommentar möglich ist: http://www.xprogramming.com/publications/dc9810cs.pdf
      * Das XP-Problem: Eine Studie macht noch keinen Sommer. Das heißt in diesem Fall: ursprünglich hing die XP-Glaubwürdigkeit wohl an dieser einen Fallstudie (wie das mittlerweile ausschaut, kann ich nicht sagen), was man auch unter “anecdotal evidence” verbuchen kann.
      * Hinzukommt: “Extreme Programming wurde von Kent Beck, Ward Cunningham und Ron Jeffries während ihrer Arbeit im Projekt Comprehensive Compensation System bei Chrysler zur Erstellung von Software entwickelt.” (aus obigem Wikipedia-Artikel zu XP).
      Die drei Personen gehören wohl zur OO-crème de la crème. Wie mein Informatik-Prüfer meinte: Solche Leute können vermutlich mit “irgend einem” Ansatz ein Projekt erfolgreich durchziehen (= “a few good men-Approach”). Die Frage ist dann: Ist das so (und mit Blick auf welche Projekte bzw. Projektgrößen)?
      * Ferner: “Extreme Programming” (und andere agile Varianten wie Scrum, Kanban, Crystal, etc.) sind nicht unumstritten. Auch hier scheitern Projekte wie in klassischen = dokumentenzentrierten Projekten.
      * Mich interessiert freilich ganz konkret: Was kann ich von den agilen Methoden mit modell-getriebenen und serviceorientierten Ansätzen im Enterprise-Bereich (mit Blick auf BPMN, BPEL; SOA/SCA, Java EE) mixen?

      Kurzum: Wenn Du und Deine Leute “agil” gearbeitet haben, dann wären m.E.:
      1) schnell Prototypen entwickelt (z.B. für GUIs)
      und
      2) User stories verwendet worden (aber das ist m.E. eine Schwachstelle – hier können Ansätze wohl ein verbessertes Requirements Engineering vertragen mit Toolunterstützung bzgl. Use Cases und Business Process-Modellen à la BPMN), aber keine
      3) Refactorings durch Unittests [im Test1st- bzw. TDD-Sinne: http://en.wikipedia.org/wiki/Test-driven_development%5D und ständige Integrationen abgesichert worden [http://en.wikipedia.org/wiki/Continuous_integration]
      etc.

      Habt Ihr so etwas gemacht? Dann würde ich das “agil” nennen. Falls nicht, dann nicht. Da´ß das alles schon in den 1980er Jahren (Refactorings plus TDD, continuous integration, etc.) der Fall gewesen sein soll, kann ich nicht nachvollziehen.
      Du willst mir dann sicher auch erzählen, daß Ihr vielleicht in C schon durch und durch OO-mäßig oder serviceorientiert vor Euch hingewerkelt habt, oder?
      Schon die Tools (IDEs, version control systems, Unit-Test-Frameworks, http://en.wikipedia.org/wiki/Continuous_integration, etc.) haben in den achtziger Jahren so noch gar nicht existiert.
      Ich weiß daher überhaupt “nicht”, was das heißen soll: “Wir hätten quasi schon immer – zumindest in den 1980er Jahren – in der Softwareentwicklung agil operiert.”
      Daß hierbei manche Kontinuitätslinien vorliegen, ist freilich unbestritten. Die XP-Jungs haben also nicht einfach alles “neu” erfunden, quasi: alles neu macht der Mai, äh: XP :-)
      Aber ein schwergewichtiger Wasserfallprozeß (oder spätere Weiterentwicklungen) ist nicht identisch mit leichtgewichtigen Prozessen à la XP, Scrum, etc.
      * Hier noch einige Detailinfos dazu (vielleicht interessiert das ja jemanden): http://www.torsten-horn.de/techdocs/sw-dev-process.htm#SoftwarearchitekturrelevanteAufgabenRupXpVmodell

      ~Peter

      • kybernetiks  On May 14, 2012 at 7:12 PM

        Also Peter, lassen wir mal grosse Namen (few men) und schlaue Abküzungen xxpp und ganze Bücher für akademischen Segen aussen vor. Was bleibt dann?

        Wir haben 1980 mit Cobol programmiert. Wir haten kein eigentliches Dokumentationssystem, sondern eine Programmierumgebung von Data General, deren Hardware wir benutzten und verkauften. Wöter wie GUI gabs damals an der Universität. Bei uns wurde (ganz grossartig, weil revolutionär neu) von echten Dialogsystemen gesprochen. Die Bildschirme wurden als Masken mit Eingabefeldern aufgebaut.

        >> 1) schnell Prototypen entwickelt (z.B. für GUIs)

        ja, sehr schnell Dialogfenster mit den verlangten Eingabe Daten (Name, Datum, Flugnr, ..)
        ohne Verarbeitung im Hintergrund, nur zum zeigen wies aussieht !!!

        Und seeeehr extrem sind wir auf den Kunden eingegangen (was die Sache teuer machte und nach agilem Management rief. 1980 war das alles ganz normal. Das mag mit dem beschränkten Projektumfang zusammenhängen. Von den Uni-Informatikern wurde das als Spaghetti-Programmierung bezeichnet – was ursprünglich auf die Code-Ebene, bezogen war, weil der Code einfach immer noch länger gemacht wurde, aber dann vor allem auch in Bezug auf das Projektmanagement, das ohne Userrequierments einfach (quasi planlos) drauflos arbeitete.

        >> 2) User stories verwendet worden (aber das ist m.E. eine Schwachstelle – hier können Ansätze wohl ein verbessertes Requirements Engineering vertragen mit Toolunterstützung bzgl. Use Cases und Business Process-Modellen à la BPMN), aber keine

        wir sind öfters beim Kunden vor Ort gewesen und haben uns die Arbeit jenseits von Computern erklären lassen

        3) Refactorings durch Unittests [im TDD-Sinne: http://en.wikipedia.org/wiki/Test-driven_development abgesichert worden

        In den 80er Jahren gabs die ersten Strukturierungs-Ansätze, beispielsweise Schleifen statt goto.
        Das kann man als Refactoring bezeichnen, wir überarbeiteten von Zeit zu Zeit die Programm mit “neuen Methoden” – Programmbibliotheken ..

        4) ständige Integrationen vorgenommen worden [http://en.wikipedia.org/wiki/Continuous_integration]
        etc.

        Die Integration ist natürlich bei Projekten ohne grosse Vernetzung kein so grosses Problem, wir hatten einen Chef, der das ganze Projekt im Griff hatte.

        Allerdings wenn wir später die Funktionen auf der Benutzerebene erweiterten und veränderten, war es oft schwierig mit der Integration.

        Aber alles, was da als toll und neu steht, war am Anfang sowieso so und wurde als planlos kritisiert. Ich finde Deinen moderne Approach sehr lustig.

        Unsere Software haben wir übrigens etwa 30 verschiedenen Unternehmen verkauft und deshalb als Branchenstandardsoftwarepaket bezeichnet. Das Paket hiess Tourdata und hat später der Firma den Namen gegeben
        http://www.tourdata.ch
        http://www.tourdata.ch/ueber_uns_geschichte.html

        • Peter Bormann  On May 14, 2012 at 8:13 PM

          Nun mit TDD, Refactorings, etc. gerade im OO-Bereich ist doch etwas anderes gemeint:
          * Prozedural ist nicht objektorientiert.
          * Test-first ist nicht irgendwann `mal das Produkt testen
          * Refactoring ist nicht einfach nur >wir überarbeiteten von Zeit zu Zeit die Programm mit “neuen Methoden” – Programmbibliotheken< [goto-Ersetzung wäre freilich refaktorisieren]
          * Die Tools und die Komplexität, mit denen Ihr 1980 zu tun hattet, sind wohl auch kein Vergleich zu
          heute (allein wenn Du Dir DOS und heutige Windows-Systeme von der Codebasis her anschaust: DOS ursprgl. ca. 65000 Codezeilen, heutige Windowsversion mehrere zehn Millionen Codezeilen. Aber ich nehme an, Komplexität ist für Dich auch kein Problem. Ob ein Programm 100 oder mehrere Millionen Zeilen an Code hat, ist für IT-Veteranen wohl "kein" Unterschied).

          Das Problem: Ihr Veteranen kennt einfach "schon alles" unter der IT-Sonne. Also: Ihr wart schon immer in der Zukunft, bevor die Zukunft überhaupt begonnen hat
          – und schreibt dann Spaghetticode. Gaaaanz toll! Es sei denn, die Wartungsprogrammierer hatten Lust, Leute wie Euch mit der Axt zu verfolgen.
          Dann macht eine Flucht auf einen entlegenen Bauernhof in der Schweiz auch Sinn :-o

          • kybernetiks  On May 15, 2012 at 10:46 AM

            hmmm.. Veteranen ist ein gutes Wort für mich.
            Ich selbst würde eher von “noch-nicht-entwickelter-Technik” sprechen. Die Anzahl Code-“Zeichen” in einem Programm verbuche ich als Wachstumsentwicklung. Dabei wird ausdifferenziert und es entsteht Integrationsbedarf. Genau dieser Prozess wurde in den 70-Jahren von den Veteranan E. Dijkstra, N. Wirth und Konsorten begründete und in den 80-Jahren in die Produktion getragen.
            Die zentrale Idee war immer und ausschliesslich, die Komplexität handhabbar zu halten. Die Strategie war immer Sichtbarkeitsgrenzen zu produzieren.
            Als die Programme noch 60000 Zeilen enthielten, kannte der Programmierer noch die meisten Zeilen persönlich. Später kamen mehr Zeilen dazu, ohne dass der Programmierer mehr Zeilen kennen konnte.

            Aber vielleicht konzipierst Du ja die Entwicklung der Technik anders – falls Dich das – etwa als Geschichte der Programmierung – überhaupt interessiert, was ja augenfällig gar nichts mit Enterpris-Zeugs zu tun hat, sondern an technischen Hochschulen (zb. an “meiner” ETH) betrieben wurde und wird.

            Übrigens das Programmieren mit Pascal habe ich an der Wirtschaftsabteilung der Universität gelernt, wo Technik überhaupt keine Rolle spielte, (weil das die anderen machen). Da herrschte schon in den 70-er Jahren die Vorstellung, dass man im Bankenbusiness arbeite und Organisationsanlalyse mache.

Feedback ist erwünscht!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: