Emergente Softwareentwicklungsprozesse

[s***@little-idiot.de]

Emergente Softwareentwicklungsprozesse

(emergent software development processes)

© Oktober 2005, Guido Stepken

Dieser Beitrag beschreibt neuartige, aus der Kybernetik (Steuer-
mannslehre) stammende, Lösungsansätze derjeinigen Probleme, die
bei mittleren und großen Software - Projekten (C, C++, JAVA, .NET)
typischerweise auftreten. Gewünscht ist stets die schnelle, zeitge-
naue und preiswerte Lösung. Komplexe Software ist nicht nur
hochgradig fehlerbehaftet, sondern auch in der Herstellung oft
viel teurer, als kalkuliert, immer hinter dem Zeitplan zurück-
liegend. Stundenzettel, MS-Project, Groupware mit Todo-Listen,
Zielvereinbarungen, Motivations-Kurse, NLP, organisierendes Pro-
jektmanagement nach dem Harzburger Modell streng hierarchisch
geordnet, mit Kontrollstrukturen alleorts, Prinzipienreiterei,
unausgereifte Methoden, ... führen zumeist dazu, daß die Zahl der
Häuptlinge in Relation zu den Indianern ansteigt, oder kurz vor
Scheitern des Projektes zusätzliche Programmierer engangiert wer-
den, die die anderen nur von der Arbeit abhalten. Umso er-
staunlicher sind die Erfolge der freien Softwareentwicklung, wo
eine wilde Horde von Hackern ohne erkennbare Planung und kaum
erkennbarer Organisation es schafft, Softwareprojekte mit vielen
millionen Zeilen fertigzustellen, zu warten und weiterzuentwick-
eln, siehe z.B.
Loading Image... .
Wie gelingt es in freien Projekten, ohne autorisierte
Projektleitung, ohne Projektmanagement, hierarchische
Strukturen, Entscheidungen zu treffen, Aufgaben zu verteilen und
zu koordinieren? Keine Kaffeekränzchen, keine dauernden Be-
sprechungen, keine kontraproduktiven Bedenkenträger Habe ich
schon immer gesagt..., kaum innere Reibung ... Welche impliziten
Logiken sich hinter den verschiedenen Softwareentwicklungsmod-
ellen, also den prozessualen Abläufen verbergen, und wie diese
mit den psychologisch / menschlichen Verhaltensweisen wechsel-
wirken, sei hier anhand einiger Beispiele aus der Praxis
beleuchtet. Emergente Prozesse sind das Geheimnis hinter den aus-
gefeilten Softwareentwicklungsmodellen. Der Begriff Emergenz
stammt aus der Kybernetik und besagt folgendes: Das Ganze ist
mehr, als die Summe seiner Komponenten!. Der folgende Beitrag
beleuchtet moderne Softwareentwicklungsmodelle aus dem Blick-
winkel der Emergenz.

Zunächst ein Beispiel für Emergenz. Jeder hat schon einmal das
HTTPS Protokoll verwendet, bei welchem eine verschlüsselte
Verbindung zwischen Browser und Server (z.B. für Homebanking) zu-
stande kommt. Da fragt man sich doch gleich, wo die Passworte für
Ver-und Entschlüsselung ausgetauscht worden sind, ohne daß jemand
Drittes den Datenverkehr mitlesen kann. Die Antwort ist: Es wur-
den niemals Passworte ausgetauscht, dennoch kommt ein ver-
schlüsselter Krypto-Tunnel zustande. Wie kann das? Man stelle
sich eine Kiste vor, welche mit zwei Vorhängeschlössern ver-
schießbar ist. Nun lege man eine Nachricht in die Kiste, schließe
mit seinem eigenen Vorhängeschloß ab, den Schlüssel behalte man
für sich. Nun versendet man diese Kiste per Post. Niemand Drittes
kann den Inhalt lesen, da diese ja verschlossen ist. Nun bittet
man den Empfänger, sein eigenes Schloß als zweites Schloß
anzubringen, den Schlüssel für sich zu behalten, und die Kiste
zurückzusenden. Die Kiste wieder in Händen, entfernt man das
eigene Schloß, und sendet die Kiste abermals zurück. Der
Empfänger kann nun sein eigenes Schloß entfernen, den Inhalt
lesen. Zu keinem Zeitpunkt wurde ein Schlüssel ausgetauscht, und
zu keinem Zeitpunkt war die Kiste unverschlossen unterwegs. Die
Schlüssel, stellvertretend für Passworte oder Keys wurden nicht
übermittelt. Durch den emergenten Prozeß des dreimaligen Hin-und
Herschickens wurde die Übermittlung eines Schlüssels überflüssig.
Und wenn man nun sich das PGP Verfahren anschaut, welches auf
diesem emergenten Prinzip aufbaut, so steht hier stellvertretend
für die doppelt verschließbare Kiste eine Primfaktorzerlegung
eines zwei bzw. dreifachen Produktes von langen Primzahlen. Wo
nun liegt die Emergenz dieses Prozesses? Dieser Prozess erst
ermöglicht die täglichen, milliardenfachen, sicheren Daten-
verbindungen ohne riesigen Verwaltungsaufwand, wo Passworte oder
Schlüssel auf verschiedenen Wegen übermittelt werden müssen,
spart also immenses Geld ein. Dieser emergente Prozess ist unter
dem Namen Diffie Hellmann Key Exchange bekannt, jedoch ist das
Prinzip kaum wirklich verstanden.

Der Begriff Emergenz beschreibt also Prozesse, welche durch ihre
impliziten Logiken nachfolgende Prozesse erst ermöglichen, erhe-
blich beschleunigen oder Resourcen sparen.

Ein weiteres Beispiel betrifft Kontrollprozesse, die leider nicht
unabhängig vom Entwicklungsprozess selber sind. Wie messe ich die
Arbeitsleistung eines Programmierers mit möglichst geringem
Zusatzaufwand? Zahlreiche Softwarehersteller haben hier unter-
schiedliche Verfahren, welche allesamt einen riesigen Verwal-
tungsaufwand erfordern, also das Produkt enorm verteuern. lines
of code written ist ganz sicher kein Maßstab, an welchem man
einen Programmierer messen könnte. Es gibt für einen Programmier-
er immer Möglichkeiten, die Codebasis aufzublähen, durch Cut-und
Paste (Code-Reuse!-), wobei 3000 Zeilen auch durch wenige hundert
Zeilen hätten ersetzt werden können. Aufgeblähter Quellcode durch
Codegeneratoren, z.B. verteuert das Refactoring, sprich die Soft-
warewartung enorm. Statistiken bei großen Softwareprojekten haben
ergeben, daß ein Programmierer im Laufe von mehreren Jahren
täglich nur ca. 5 endgültige, bleibende Codezeilen zum Produkt
beiträgt. Ständige Strukturänderungen, das oft notwendige Verwer-
fen von Modulen sorgen dafür, daß die Arbeitsleistung enorm ab-
sinkt. Kriterium sollte also vielmehr sein: lines of software not
written - die Abgrenzung zum Nichtstun fällt hier schwer.... Ein
gutes Design Pattern, entworfen von einem erfahrenen Software-
Architekten, so die allgemeine Denkweise, sorgt dafür, daß im
Laufe der Entwicklung nur wenig Code verworfen werden muß. Gute
Design-Pattern sorgen gewöhnlich dafür, daß die Kosten der Soft-
wareentwicklung auf 1/3 bis ¼ reduziert werden kann. So effizient
nämlich war das Nachprogrammieren von SUN's J2EE. Die Progammier-
er des Clones von JBOSS hatten schließlich ein perfektes Design-
Pattern vorgegeben, das Nachprogrammieren der Routinen war nur
reine Fleißarbeit, mit minimalem Test-und Koordinationsaufwand.
Dasselbe gilt hier auch für den Windows Emulator WINE. Insbeson-
dere Frameworks, allen voran J2EE, .NET, QT4 (KDE), GTK+ (GNOME)
und zahlreiche RAD Werkzeuge enthalten implizite Design-Pat-
terns, an denen sich Programmierer orientieren können, um schnell
produktiv zu sein. Hierbei kann die Arbeitsleistung durchaus auf
durchschnittlich 200-500 Codezeilen je Tag ansteigen. Hierin
liegt also ein riesiges Potential für Emergenz, wo ein aus-
gereiftes Design-Pattern für überproportionale Leis-
tungssteigerung des gesamten Programmierer Teams sorgt. Hierbei
wird die unvermeidliche innere Reibung, der Verwaltungs, Test- ,
Kordinations und Kommunikationsaufwand stark reduziert und bei
weitem überkompensiert. Was aber, wenn einfach kein bewährtes De-
sign Pattern vorliegt, wie z.B. bei dem kürzlich eingestellten
Bundesprojektes FISCUS? Die Erfahrungen der hierfür engagierten
TOP-Software Architekten (J2EE) führten dazu, daß lange Zeit das
Projekt gut voranging, bis sich zu einem recht späten Projekt-
stand herausstellte, daß das Design doch nicht tauglich war. Wenn
ein Softwareprojekt gut vorangeht, ist dies noch lange keine
Garantie dafür, daß nicht kurz vor Schluß doch noch wegen
unlösbarer Probleme der Großteil des Codes neu entwickelt werden
muß. Beim Projekt FISCUS wurden viele hundert Mannjahre letz-
tendlich verschwendet, geschätzt etwas unter einer Milliarde Eu-
ro. Das Software-Design-Pattern von J2EE, die saubere Trennung
von Businness Logik, GUI und Workflow, die hin-und herflitzenden
Container, die sich mitsamt Daten und zugehörigen Programmen eine
CPU im SUN-Netzwerk suchen, stellte sich als Blödsinn heraus.
Aber das System skaliert ja laut Angaben von SUN, nur leider
nicht mit riesigen Datenbeständen ... Dementsprechend war jedes
Softwareentwicklungsmodell unter J2EE zum Scheitern verurteilt.
Das Design von J2EE ist nicht für diese Art von Anwendung gedacht
gewesen. Zurück zur Beurteilung der Programmierer Leistung
diese ist enorm Abhängig von einer Vielzahl von Faktoren - am
allerwenigsten haben in Großprojekten die individuellen
Fähigkeiten des einzelnen Programmierers damit zu tun, wennauch
oft Know-Know Unterschiede innerhalb des Teams bemängelt werden,
welche jedoch leicht durch regelmäßiges Pair-Programing beseitigt
werden können. Emergenz - Das Ganze ist mehr, als die Summe sein-
er Komponenten ist hier für die Leistung des Teams insgesamt ver-
antwortlich. Im Grunde liegt bei den erfahrenen Programmierern
eine große Chance sie können durch weitergabe ihre Wissens die
jungen Kollegen mitziehen und die Leistung des Teams erheblich
steigern. Eine einzige gute Idee, z.B. kann dem Team insgesamt
enorm Entwicklungszeit einsparen, wie z.B. die Erkenntnis, daß
komplexe Datenstrukturen und einfacher Code effizenter sind (auch
in der späteren Wartung des Codes), als einfache Datenstrukturen
und komplexer Code. Warum angesichts dieser Tatsache immer noch
Entscheider haufenweise auf SQL Datenbanken setzen, und nicht
auf OO-Datenbanken bzw. Postrelationale Datenbanken, allen voran
PostgreSQL (Kern ist OO!), GOODS, ZODB oder die kommerzielle
Datenbank CACHÉ von Intersystems, ist mir ein Rätsel. Persistenz,
hyperdimensionale Datenbankstrukturen, einfaches Datenbankdesign,
erheblich höhere Leistung gegenüber den SQL Marktführern Oracle,
MS SQL, ... sowie stark vereinfachte Programmierung sprechen klar
für OO-Datenbanken. SQL Datenbanken beherrschen leider nur ein-
fache Datenstrukturen, die Komplexität des Programmiercodes
verkompliziert sich daher enorm, damit steigen auch die
langfristigen Wartungskosten auf ein Vielfaches.

Kontrolle der Leistung

Die Messung der Leistung eines Programmierers kann also nur an-
ders erfolgen, hierzu möge folgendes im Alltag beobachtbares
Beispiel dienen: Wie kontrolliert ein Manager eines Restaurants
seine Angestellten, Kellner, Küche, ohne ständig mit seiner Nase
dabei zu sein? Er installiert Kontrollprozesse! Die Kellnerin
nimmt eine Bestellung für ein Essen auf, bongt in die Kasse,
diese druckt die Bestellung für die Küche aus. Die Küche stellt
bereitet das Essen zu, die Kellnerin liefert es und kassiert. Der
Manager habe z.B. 25 Steaks eingekauft, die Küche 25 zubereitet,
die Kellnerin jedoch nur 23 verkauft hier betrügt die Kellnerin.
Hat die Küche nur 23 zubereitet und die Kellnerin 23 verkauft, so
betrügt der Koch. Ein Einfacher Abgleich von Einkaufslisten,
Bestellungen und der Kasseneinnahmen zeigt sofort, ob jemand be-
trügt, wieviel Trinkgeld gegeben wurde, u.s.w. Dies sind Kon-
trollprozesse, genauer prozessuale Abläufe, die von dem Manage-
ment vorgegeben wurden, und welche eine perfekte Kontrolle
ergeben, ohne daß der Manager ständig anwesend sein muß. Eine
stichprobenartige Kontrolle der Vorräte schadet natürlich auch
nicht, schließlich könnten Kellnerin und Koch sich ja abge-
sprochen haben, nebenher privat einzukaufen und zu verkaufen.
Die implizite Logik der Kontrolle im Restaurant liegt einfach
darin, daß in einem geschlossenen Kreislauf bei den verschiedenen
Verarbeitungsprozessen die Stückzahlen unabhängig gemeldet/gebont
werden müssen. Toyota und Porsche haben z.B. Bei der Fließband-
Produktion eingeführt, daß der Nachfolgende die Arbeit des
Vorgängers kontrolliert, damit sich die Fehler im Laufe von 100
Arbeitsgängen nicht potenzieren, sondern gegenseitig aufheben.
Bevor nicht die Fehlerbehoben sind, läuft das Band nicht weiter.
Der Druck der Gruppe zwingt jeden Arbeiter, präzise und genau zu
arbeiten. Ford und Volkswagen (siehe Geländewagenproduktion in
Wolfsburg) haben gerade ein neues Akkord Modell eingeführt,
welches bei Fließbandarbeit nur die Stückzahlen der 100% perfekt
gefertigten Autos zählt, OK-Akkord genannt. Die impliziten
Logiken der psychologisch / menschlichen Eigenschaften von Mensch
wechselwirken hier mit den prozessualen Abläufen. Nur eine
einzige Regel sorgt dafür, daß sich das Verhalten von tausenden
Mitarbeiter verändert. Schlechte Manager haben jahrelang jedem
Mitarbeiter genauestens vorgeschrieben, welche Arbeiten/Hand-
griffe wie zu machen sind, moderne Manager gestalten Prozesse,
definieren nur wenige Regeln, genau wissend, daß die Mitarbeiter
als sog. eigenständige Agenten eigenständig und mit viel Begeis-
terung und Engagement alles notwendige koordinieren werden, um
ihr Einkommen zu optimieren.

Ein klares Beispiel für Emergenz kann man auch bei einem sehr
verblüffendem Experiment von Reynolds 1987 beobachten, welcher
die hochkomplexen Flugbewegungen eines Vogelschwarms beschreibt:

1.Kollisionsvermeidung: Vermeide Kollision mit Nachbarn oder an-
deren Hindernissen 2.Geschwindigkeitsanpassung: Passe deine
Geschwindigkeit der deiner Nachbarn an 3.Schwarmerhaltung: Ver-
suche, in der Nähe deiner Nachbarn zu bleiben

Diese 3 einfachen Regeln genügen bereits, um das komplexe Verhal-
ten eines fliegenden Vogelschwarms zu simulieren, der fliegend
Hindernissen ausweicht, sich in zwei Schwärme aufteilt, um ein
größeres Hindernis zu umfliegen, über Berge und durch Täler
fliegt. Ein deutscher Beamter oder Angestellter würde wohl eher
auf die Idee kommen, jedem einzelnen Vogel entsprechend seinen
Fähigkeiten eine genaue Flugbahn vorzuschreiben, und individuelle
Verhaltensvorschriften zu machen. Genaugenommen würde jede Biene
somit durch die Flugtauglichkeitsprüfung für Piloten fallen. Ein
Kybernetiker, der das Prinzip für Emergenz verstanden hat,
schreibt nur drei Regeln für prozessuale Abläufe vor, wohl wis-
send, daß jeder Vogel als Individuum als eigenständiger Agent
selber entscheiden kann, welche Flugbahn dieser einschlägt, und
nach welchen Kriterien er dies entscheidet.

Was lernt man hieraus für die Kontrolle von großen Software-
Teams? Analysiert man die impliziten Logiken des Restaurant-
Beispiels, so fällt auf, daß die Kontrolle nicht in der genauen
Messung der Arbeitsleistung des einzelnen besteht, also die Er-
fassung der Tätigkeiten eines Programmierers über Stundenzettel,
lines of code written/changed/deleted/refactored, sondern die
emergente Leistung des Teams insgesamt muß beurteilt und gemessen
werden. In einem Netzwerk von Programmierern ergibt sich ein eng-
maschiges Geflecht von Abhängigkeiten der verschiedenen Codemod-
ule untereinander, Programmier und Änderungswünsche an die Kol-
legen, die für die Nachbarmodule zuständig sind. Diese und nur
diese können korrekt die Leistung, Einsatzbereitsschaft, und
Qualität der Arbeit ihres Kollegen korrekt beurteilen. Ein ein-
facher Beurteilungsfragebogen, der nur abfragt, mit welchem Pro-
grammierer oder Gruppe der Programmierer zu tun hatte, wie er die
Leistung und Qualität seines Kollegen einschätzt, genügt. Die im-
pliziten Logiken des Extreme Programming, siehe auch
http://www.little-idiot.de/xp/ beinhalten eine vergleichbare Art
der mündlichen Beurteilung der Leistung der Kollegen, jeder muß
im Abstand von 1-2 Wochen regelmäßig die Resultate seiner Arbeit
vor dem Team vorstellen, wie weit er gekommen ist, welche Prob-
leme aufgetreten sind. Die impliziten Logiken der prozessualen
Abläufe von XP führen dazu, daß der Programmierer selber seine
Leistung korrekt einschätzen lernt, wodurch die Projektleitung
dann erst in der Lage ist, realistische Kosten und Termine nennen
zu können. Der Programmierer mag sich nur ungern die Blöße geben,
seine zugesagte Arbeitsleistung wiederholt nicht erreicht zu
haben.

Meta Prozesse

Agile Programming (AP) oder auch Agile Software Prozesse sind der
neueste Schrei in der Softwareentwicklung. Agile Software En-
twicklungsverfahren sind bewegliche, flinke Prozesse, die sich
explizit nicht gegen Änderungen der ursprünglichen Anforderungen
stellen. Am Projektanfang definierte Anforderungen stimmen zum
Projektende erfahrungsgemäß nicht mehr. Hierdurch entsteht ein
sog. moving target, also variable Zielstellung, die es gilt, so
gut wie möglich zu treffen. Der Erfinder Coldewey teilt die
Prozesse des AP daher in Meta-Prozesse (meta= (griech.) über)
auf, die nur die Rahmenbedingungen stellen, und die konkrete Pro-
grammierarbeit auf.

AP verfolgt vorrangig folgende vier Maximen:

1.Einzelpersonen und Interaktionen sind wichtiger als Prozesse
und Werkzeuge 2.Laufende Systeme sind wichtiger als umfangreiche
Dokumentation 3.Zusammenarbeit mit dem Kunden ist wichtiger als
Vertragsverhandlungen 4.Reagieren können auf Veränderung ist
wichtiger als Pläne zu verfolgen In Deutschland ist der Glaube an
das Funktionieren von strengen Vorgaben für die Softwareentwick-
lung noch vorherrschend, begründet in der preußischen Tradition,
welche das Harzburger Modell des hierarchischen, industriellen
Führungsstils begründet: Befehl Ausführung Rückmeldung Kon-
trolle. In der Softwareentwicklung ist das phasenorientierte V-
Modell XP vorherrschendes Modell, welches allerdings stark unter
Druck geraten ist. Diese schwergewichtigen Software Entwick-
lungsprozesse, wie auch dem Wasserfall-Modell, dem alten V-Mod-
ell, oder dem Spiralmodell, konzentrieren sich sehr stark auf den
einmaligen Durchlauf der Phasen Analyse, Design, Implementierung,
Test und Auslieferung. Dies deutet darauf hin, dass die softwa-
reerstellende Industrie in ihrem Denken mehr den Projektgedanken
als dem Produktgedanken behaftet ist. Auch der Gedanke, daß Soft-
ware - Wartung nach der Fertigstellung erst beginnt, ist fehler-
haft, man könnte den Prozess der Softwarewartung bereits nach der
Fertigstellung der minimalen Basisversion der Software ansetzen.
Die Prozesse der Softwarentwicklung sind untrennbar mit dem
Prozess der Wartung verbunden. Warum der Glaube an das V-Modell
vorherrschend ist, obwohl in diesem die sich ständig verändernden
Anforderungen an die Software nicht berücksichtigt sind, ist mir
ein Rätsel. Der beste Prozess wiegt einen chaotischen Haufen von
Anfängern, die kein professionelles Team bilden, nicht auf, wie
die Open-Source Szene eindrucksvoll zeigt. Da professionelle
Teams einen sehr hohen Grad an Selbstorganisation aufweisen, ist
eine kleine Zahl an Methoden ausreichend. Zwölf auf einer Seite
definierte Methoden bringen mehr als tausend Seiten An-
forderungsprofile an die Software-Eigenschaften der beiden vor-
angegangen Jahrzehnten, die eh nur von wenigen Experten
überblickt und verstanden wurden. Man verabschiedet sich immer
mehr von der Vorstellung, dass einheitliche wiederholbare
Prozesse und detailliert planbare Projekte möglich sind. Auch die
Vorstellung, durch klare Anweisungen und Kontrolle ein Projekt
steuern zu können, schwindet, da die Erfahrung zeigt, daß
kreative Prozesse sich nur schlecht befehlen und kontrollieren
lassen. Wichtig ist es, ein Team mit kompetenten Mitgliedern zu
haben! Man findet die Spezifikationen des V-Modells hier:
http://www.kbst.bund.de/doc,-307632/V-Modell-XT-Dokumentation.htm
Beim Durchlesen kommt einem der Gedanke, daß hierbei Abteilungs-
und Schubladendenken sowie der Projektgedanke vorherrschend ist,
weit und breit kein prozessuales Denken, sprich emergente
Prozesse in Sicht. Hierbei schaffen sich Bürokraten (Häuptlinge)
erst ihre Existenzberechtigung, indem sie mit dem V-Modell XP
äußerst aufwändige Vorarbeiten vorschreiben, die eh allesamt für
die Katze sind, weil sich die Anforderungsprofile im Laufe der
Softwareentwicklung erfahrungsgemäß noch gewaltig ändern. Nicht
aufwändige Beschreibungen der Anforderungsprofile sorgen für gute
Software, sondern nur wenige Handvoll einfacher Regeln führen zu
sog. emergenten Prozessen, wie das Beispiel der Kontrollprozesse
im Restaurant und das HTTPS-Protokoll zeigt. Äußerst wichtig bei
Agiler Softwareentwicklung sind die sog. Metaprozesse, z.B. das
bewußte und disziplinerte Reflektieren über die Prozesse selber
gehört dazu. Keine Regel ist unveränderbar, alles darf umgestal-
tet werden. Dieser Maxime folgt auch eXtreme Programming (XP).
Ein weiteres Beispiel für den kybernetischen Regeln folgende,
emergente Softwareentwicklung ist Adaptive Software Development
(ASD) . Jim Highsmith hat sich für seinen Prozess Anregungen aus
dem Bereich der Biologie bei komplexen adaptiven Systemen geholt,
genauer bei Umberto Maturana und seiner Erfindung Autopoiese,
siehe Baum der Erkenntnis Unter autopoietischen Systemen versteht
man ein Zusammenspiel von Agenten, die mittels einfachen Regeln
kommunizieren. Das dabei entstehende, emergente Verhalten zeigt
folgende Eigenschaft: Einfache Regeln, gepaart mit komplexen
Beziehungen, führen zu erfolgreichen Ergebnissen, während kom-
plexe Regeln, gepaart mit wenigen Beziehungen, zum Scheitern
führt. Zum weiteren Verständnigs der dynamischen Wechselwirkungen
innerhalb von großen Netzwerken, siehe hierzu auch
http://www.little-idiot.de/teambuilding/GesetzeNetzwerke.pdf .
Bei der Entwicklung von Software betrachtet man nun Teammit-
glieder, Auftraggeber und Organisationen als Agenten. Die Regeln
für die Zusammenarbeit bildet dabei das Softwareentwicklungsver-
fahren. Somit entspricht ein Projekt einem komplexen System. Jim
Highsmith hat folgendes Regelwerk erstellt: 1.Entwicklungsteam
und Kunde starten gemeinsam mit dem Entwurf einer Vision 2.Team
versucht innerhalb von vier Wochen mglichst viele Punkte der Pri-
oritätenliste des Kunden zu erfüllen. Am Ende der vierwöchigen
Iteration erhält das Team Feedback vom Kunden. 3.Während der It-
eration wird dem Team vertraut - wenn der Plan nicht erfüllt wer-
den konnte, geht man von einer Fehlplanung aus 4.Am Itera-
tionsende überprüft das Team seine Leistung und verbessert den
Prozeß. 5.Team plant nächste Iterationsrunde aufgrund vorange-
gangener Erfahrungen. 6.Management unterstützt das Team auf
allen Ebenen. 7.Man überlässt die Auswahl der Arbeitstechniken
dem Team. Diese kleine Anzahl von Regeln führt zu äußerst flexi-
blen Projekten. Der ASD Lebenszyklus ist eine kurze Abfolge aus
Spekulation, Kollaboration und Lernen. Worin liegt hier die
Emergenz? Diese Vorgehensweise sorgt dafür, daß z.B. vom Kunden
im Laufe der Projektentwicklung gewünschten, besonderen Features,
welche nicht elementar notwendig, und gleichzeitig komplex zu im-
plementieren sind, also das Produkt unnötig verteuern würden, au-
tomatisch wegfallen. Kunde und Team können somit nach ein-
facheren, preiswerteren Alternativen suchen. Oftmals wird ver-
sucht, umständliche Prozesse der Verwaltung in der Software abzu-
bilden. Analysiert man diese Prozessketten, bzw. deren mögliche
Implementierung in die Software, so stellt sich oft heraus, daß
hier in der Verwaltung durchaus noch einige Prozessketten ges-
trafft werden könnten, weswegen sich dann deren Implementierung
in Software erübrigt. Prozessuales Denken soll über Abteilungs-
und Schubladendenken herrschen, nicht umgekehrt. 95% der im V-
Modell XP enthaltenen Prüfspezifikationen, Berichte, u.s.w.
könnten ersatzlos entfallen, das Projekt würde erheblich billiger
werden, man kommt mit weniger Planung, Vorbereitung aus. Was
dringend elementar benötigt wird, muß eh fertiggestellt werden,
egal zu welchen Kosten. Es macht auch daher keinen Sinn, 30% der
Gesamtkosten für überflüssige Planung bei sich ständig verändern-
den Anforderungen und Prozessmanagement aufzuwenden. Je nach Pro-
jektgröße schätzt man zwischen 15%-5% der Gesamtkosten für das
Projektmanagement, leider wird nicht mitgerechnet, daß inzwischen
auch die Programmierer mit erheblichem Verwaltungsblödsinn von
ihrer Arbeit abgehalten werden. Hier sei ein sehr wertvolles Ex-
periment erwähnt Distrust The hidden cost of control von Armin
Falk und Michael Kosfeld, siehe http://www.little-idiot.de/team-
building/TheHiddenCostOfControl.pdf Scrum ist ein weiterer, dem
ASD verwandter, emergenter Prozess. Ken Schwaber und Jeff Suther-
land holten sich für ihren Prozess Anregungen aus dem Bereich
Verfahrenstechnik (Process Engineering). Die Idee ist, daß man
zwischen wiederholbaren und empirischen Prozessen unterscheidet.
Wiederholbare Prozesse sind solche, die vollständig verstanden
sind, und deren Anwendung erfahrungsgemäß zu akzeptablen Ergeb-
nissen führen, wohingegen empirische Prozesse chaotisch, sehr
komplex, also nicht steuerbar sind. Das Hauptargument von
Schwaber und Sutherland hierfür ist, daß Softwareentwicklung kein
streng wiederholbarer Prozeß ist, da die Endprodukte immer ver-
schieden sind. Empirische Prozesse müssen fortlaufend überwacht
und angepasst werden, um das erwünschte, emergente Verhalten zu
erzielen. Zur Steuerung ihres Prozesses verwenden sie den Produk-
trückstand, womit die offenen Punkte der Prioritätenliste gemeint
sind. Alle 30 Tage setzen sich Auftraggeber und Team zusammen und
entscheiden, welche Punkte der Prioritätenliste in den folgenden
30 Tagen abgearbeitet werden soll. Das Team versucht nun, in
diesen 30 Tagen, die als Sprint bezeichnet werden, möglichst alle
Aufgaben zu erfüllen. Aufgaben die nicht erfüllt werden konnten,
bilden den Sprint Rückstand. Während des Sprints kann das Team
völlig unabhängig und ungestört arbeiten. Gegen Ende des Sprints
erfolgt ein Sprint Review, wobei die nicht erfüllten Aufgaben
wieder auf den Produktrückstand wandern. Nach einem Kaf-
feekränzchen, bei welchem Feedback und Erfahrungen ausgetauscht
werden, beginnt wieder alles von vorne. Das Team hält täglich,
immer zur gleichen Zeit, das sogenannte Scrum Meeting ab. Die
groben Richtlinien für Scrum Meetings sind folgende: 1.Kurze
Dauer von 15-30 Minuten 2.Was hat jeder seit dem letzten Meeting
getan? 3.Was wird man bis zum nächsten Meeting tun? 4.Was hat
bei der Arbeit behindert? 5.Lösungen werden nicht während eines
Scrum Meeting gesucht oder diskutiert 6.Zu offenen Fragen werden
kleine Teams gebildet, diese arbeiten nach Abschluss des Scrum
Meetings weiter. 7.Scrum Meetings sind der Pulsschlag des Pro-
jektes 30 Tage hat der Auftraggeber die Möglichkeit, sich neue
Anforderungen zu überlegen, die dann Teil des neuen Produktrück-
standes werden. Der Vorteil dieses Prozesses ist, dass das Team
30 Tage ungestört arbeiten kann. Die Durchführung der Aufgaben
ist Teamsache, somit ist Scrum ein reiner Metaprozess. Scrum
enthält keine Richtlinien für Programmierung. Worin liegt hier
die Emergenz? Scrum dient ausschließlich der Teambildung. Jeder
erfährt, woran der andere arbeitet, was seine Probleme sind, und
fühlt in den Meetings die Stimmung seiner Kollegen. Man beginnt
sich für die Arbeit des anderen zu interessieren, nimmt Anteil,
sucht und gibt Ratschläge Teambuilding. Scrum kann als psycholo-
gische Vorbereitung zu Pair Programming verwendet werden, ein As-
pekt des eXtreme Programming (XP).

Vollständige Entwicklungsprozesse eXtreme Programming, entwickelt
von Kent Beck , Martin Fowler, Ward Cunningham und Ron Jeffries
ist voll von emergenten Prozessen, welche differenzierte Methoden
für die vier sich bis zur endgültigen Fertigstellung der Software
ständig schnell wiederholenden, Entwicklungs-Zyklen (Interatio-
nen) darstellen: 1. Planung, 2. Design, 3. Programmierung, 4.
Test, 1. Planung, 2. Design .... Dieses etwas merkwürdige,
scheinbar uneffektive und aufwändige Prozedere begründet sich aus
der Praxiserfahrung heraus: Ein Programmierer trägt täglich nur
wenige, dauerhaft und korrekt geschriebene Codezeilen bei. Nicht
selten beträgt die Produktivität eines Programmierers gemittelt
nur ganz 5! Codezeilen je Arbeitstag. Nichts ist beständiger, als
die Veränderung - XP ist ein bewußter Prozess von Experimentieren
und ständiger Verbesserung des Codes, wobei XP bewährte Methoden
liefert, daß automatisch gute Software automatisch entsteht.
Während in vielen Programmierer - Teams der innige Wunsch nach
fehlerfreier, perfekter Software gepflegt wird, oder wie ein
Damokles-Schwert über den Köpfen der Programmierer hängt, so
berücksichtigt XP direkt von Anfang an, daß nichts und niemand
perfekt ist, und Perfektion nur durch einen kontinuierlichen
Verbesserungsprozess (KVP) entstehen kann. Diese neue Denke, bzw.
das Bewußtsein in ein Team hinein zu tragen, ist ebenfalls ein
Prozeß, der nicht von heute auf morgen passiert. Übrigends ist XP
exakt die Implementierung / Umsetzung von KAIZEN, einem bei in
Japan erfundenem "KVP" (Kontinuierlicher Verbesserungs -
Prozess), der zur Sicherung der Qualität im Fertigungsprozess und
zur Optimierung der Fertigungs und Managementkosten (lean produc-
tion, lean management, lean thinking) in der japanischen Autoin-
dustrie, aber auch bei Boeing und bei Porsche angewendet wird.
Mehr hierzu siehe http://www.little-idiot.de/teambuild-
ing/KaizenI.pdf . Der Begriff TQM (Total Quality Management, To-
tal=Allumfassend), in Japan geprägt, ist ein umfassendes Konzept,
welches sich z.B. auch in der DIN/ISO Norm 8402 wiederfindet. XP
ist ein sehr raffiniertes Kaizen - Konzept, wobei jeder Punkt in
den 4 verschiedenen Phasen, die zyklisch immer wieder durchlaufen
werden, einen tieferen Hintersinn hat, also implizite Logiken
enthält, die nicht direkt durchschaubar sind, weil die Effekte
erst in der Dynamik sichtbar werden. Es ist für einen Teammit-
glied nur schwer zu verstehen, daß Prozesse, bei welchem jedes
Teammitglied individuelle Nachteile hat, diese für das Team ins-
gesamt jedoch von Vorteil sind. (emergente Effekte in kursiv...)
1. Planungsphase: User - Stories: Der Anwender beschreibt,
basierend auf dem aktuellsten Zwischenrelease die Dinge, die er
weiterhin benötigt, skizziert (anfangs laienhaft) ggf. weitere
Arbeitsabläufe, ein verändertes Benutzer - Interface und sonstige
Ideen frei auf Papier. Diese dienen immer wieder der weiteren Ab-
schätzung des Projekt - Umfanges, und der Festsetzung der weit-
eren Entwicklungs-Zyklen. Während der Implementierungsphase
verändern sich stets die ursprünglichen Anforderungen, fehler-
hafte Prozesse, oder Prozessketten, die gestrafft werden können,
werden folglich auch nicht in Software übertragen. Die Entwick-
lungs-Zyklen sind stets so kurz wie möglich zu halten. Software -
Releases werden mit ihren Eigenschaften immer wieder aufs Neue
beschrieben und dies wird auch schriftlich festgelegt. Heraklit
von Ephesos: Nichts ist beständiger, als die Veränderung Die
Geschwindigkeit der Projektentwicklung wird in jedem Entwick-
lungs-Zyklus erneut abgeschätzt. Hierbei fällt direkt auf, welche
gewünschten, evtl. überflüssigen oder anders zu lösenden Features
die Softwareentwicklung unnötig verteuern würden. Die Entwick-
lungszyklen werden alle 1-3 Wochen, aufgrund der sich ständig
ändernden Anforderungen und Kundenwünsche, wieder und wieder
erneut definiert. Die Anforderungen verändern sich ständig, da
der Kunde seine eigenen Prozesse im Unternehmen/Organisation
während der Implementierung besser kennenlernt und parallel mit
optimiert. Die Planung der Entwicklungs-Zyklen findet immer
wieder erneut statt. Hierbei werden ca. 15-20% der Gesamtzeit der
Zyklen auf deren Planung verwendet. "Unit testing" und "Refactor-
ing" werden ebenfalls mit eingeplant. Die Qualität steht bei XP
an alleroberster Stelle, je weniger Quellcode dabei entsteht,
desto einfacher die Fehlerbeseitigung. Refactoring ist fester Be-
standteil dieses Prozesses, Programmierer sind ständig damit
beschäftigt, Code kürzer, effizienter und lesbarer zu gestalten.
Programmierer werden ständig getauscht (Rotationsprinzip). Dies
verhindert einen häufig auftretenden Effekt, daß aufgrund des
Ausfalles einer Person im Team die gesamte Entwicklung zum Still-
stand kommt. Dies trifft insbesondere auf Projekte mit hoher Kom-
plexität und starker Koppelung der Module zu. Jeder kennt sich
dann mit jedem Teil der Software aus und kann ggf. einspringen.
Ggf. sollte Pair Programming eingesetzt werden, womit dann keine
Verzögerungen bei Ausfällen mehr auftreten. Programmierer können
flexibel dann dort eingesetzt werden, wo es am meisten brennt.
Höchste Priorität hat daher immer die Vermeidung von Wissens-In-
seln im Team. Gerade an diesem Punkt gibt es die größten Wider-
stände, weil - jeder möchte sich unentbehrlich machen - aus Angst
vor Jobverlust. Das Gegenteil jedoch ist der Fall: Wer die
Denkweise von XP verinnerlicht hat, passt in jedes neue Program-
mierer-Team ... findet also immer einen Job. Auf flexible und er-
fahrene Programmierer mag und kann eh niemand verzichten.
Tägliche, kurze Meetings zum Arbeitsbeginn vermeiden längere
Teamsitzungen bei Problemen. Die täglichen Aufgaben werden zuge-
ordnet, Arbeitskapazitäten neu aufgeteilt. Hierbei kann es
passieren, daß Programmierer die Arbeit ihres Kollegen fortsetzen
müssen. Dies ist nur möglich, wenn sich jeder Programmierer im
Gesamtquellcode genau auskennt. Bei Teamgrößen von bis zu 20-30
Programmieren ist dies noch machbar. XP - Regeln dürfen bei
Auftreten von Problemen gebrochen werden. XP ist kein fest-
gelegtes Prozedere, sondern darf, den Anforderungen und den
Umständen entsprechend wohl begründet, abgeändert werden. Die
ständige Reflektion im Team darüber, ob entsprechend der Team-
größe oder Eigenschaften bestimmte Regeln noch sinnvoll sind,
oder vorübergehend aufgehoben oder abgeändert werden, ist eben-
falls emergent. Heraklit von Ephesos: Panta Rhei! - Alles fließt!
2. Designphase: Einfachheit, KISS - Prinzip (Keep It Simple,
Stupid!). Alles und jedes muß einfach durchschaubar sein, gut
dokumentiert, dort, wo nötig. Der Hauptaspekt liegt stets auf der
Austauschbarkeit des Programmierers. Jeder Programmierer muß sich
sofort in der Arbeit eines anderen zurechtfinden können, und nach
kurzer Einarbeitungszeit produktiv mitwirken können. Namen - das
Schaffen von Bezeichnern für Code - Abschnitte oder Program-
men/Unterprogrammen erleichtert die Kommunikation im Team. CRC -
Karten (Class, Responsibilities, Collaboration) dienen dem Design
des Systems als Team. Hier sitzen alle Programmierer in einer
Runde und halten Karten in der Hand (einer bedient die Mindmap
Software am Beamer, siehe Data Beckers MindManager, 49 Euro!,
DoxyGen geht aber auch). Jede Karte repräsentiert ein Objekt mit
Abhängigkeiten, zu anderen Klassen. Hierbei beginnt jemand in der
Gruppe von Programmierern über seine Klassen und Abhängigkeiten
zu reden, welches Objekt welche Nachrichten wohin sendet, u.s.w.
Je mehr Personen bei diesem Prozess anwesend sind, umso besser.
Existieren zuviele Karten und Klassen, so wird die Zahl auf
wenige je Person begrenzt. Hierbei werden in kurzer Zeit durch
das gemeinschaftliche Denken Schwächen im Design entdeckt und ko-
rrigiert. Bei technischen oder Design - Problemen programmiere
ein einfaches Programm, welches das Problem unter Nichtberück-
sichtigung aller anderen Probleme löst. Da es nur Testzwecken di-
ent, wird es später eh weggeworfen. Das Ziel dieses Vorgehens ist
es, das Risiko eines Fehldesigns zu reduzieren, und die Zu-
verlässigkeit der User - Story zu erhöhen. Wenn das Problem evtl.
die Gesamtentwicklung verlangsamen könnte, so sollte Pair Pro-
gramming eingesetzt werden, wobei zwei separate Entwickler sich
eine oder zwei Wochen nur dieses Problems annehmen. Füge niemals
unnötig Funktionalität hinzu. Wir kennen alle das Problem, der
Versuchung zu widerstehen, Dinge hinzuzufügen, weil sie das Sys-
tem verbessern würden. Wir müssen uns hierbei dauernd daran erin-
nern, bzw. selber disziplinieren, nichts zu programmieren, was
nicht unbedingt benötigt wird. Wenn nur ca. 10% allen Codes bei
XP tatsächlich überlebt, so verschwendet man 90% der Arbeitszeit.
Man spart umso mehr Entwicklungszeit ein, je weniger Code für die
Lösung der Aufgabe benötigt wird. Das höchste Prinzip, welches
hier gilt, sind die "Number of Lines Not Written". Im Design je-
doch berücksichtige stets die Möglichkeit, diese Funktionalitäten
später hinzufügen zu *können*. Konzentriere Dich auf die mor-
gendlichen Besprechungen und dein Tagespensum. Refactoring, also
der Prozess der dauernden Verbesserung der Code-Struktur muß im-
mer höchste Priorität haben. Code muß einfach in seiner Struktur
sein, leicht zu verstehen, zu modifizieren, und zu erweitern. Re-
dundanzen sind aufzulösen, überflüssige Funktionen zu elim-
inieren, evtl. verworfene Designs können wieder verwendet werden.
Jede Funktionalität darf nur einmal im Code vorkommen, doppelte
oder ähnliche Funktionalitäten in ähnlichem Code werden zusam-
mengefasst. Der Abschied von seinem eigenen, bevorzugten Design
zugunsten des aus Gründen der Praktikabilität durch Refactoring
entstandenen, gemeinschaftlich entwickelten Designs fällt immer
schwer. Manchmal muß man halt einsehen, daß das Ursprungsdesign
ein guter Beginn war, aber nun obsolet ist. 3. Programmieren,
codieren: Der Kunde ist immer anwesend - elementarer Bestandteil
des XP ist - er ist für die User - Stories verantwortlich, mit
welcher die GUI ständig angepasst und verbessert wird - Er allein
bestimmt das Aussehen und die Funktionalität der Software. Auf-
grund der User Stories wird auch in jedem Entwicklungs-Zyklus im-
mer wieder der Zeit-und Kostenrahmen erneut abgeschätzt. Dies ist
insbesondere wichtig, wenn der Kunde neue Funktionalitäten
einführen will, dereren Notwendigkeit sich erst im Laufe des Pro-
jektes ergeben. Er bestimmt, wie das nächste, funktionierende Re-
lease aussehen soll. Er ist auch der einzige, der über Details
Auskunft geben kann, die vergessen oder übersehen wurden.
Desweiteren wird der Kunde immer bei Funktionalitätstests und
Unit-Tests benötigt. Interessant hierbei ist auch, daß direkt
erkennbar ist, was Sonderwünsche kosten, und ob hierbei evtl. ein
scheinbar "winziges" Feature so aufwändig ist, daß der Etat
gesprengt wird. Es gibt für jede Programmiersprache im Internet
sog. "Styleguides", die festlegen, was wie bezeichnet wird, z.B.
Pointer..., wie Code formatiert wird, sodaß die Lesbarkeit im
Team erleichtert wird. Ziel ist es ja, daß jeder leicht den Code
aller im Team lesen und verstehen kann, die Einarbeitungszeit
gering wird. Refactoring muß erleichtert werden. Unter dem Stich-
wort "best practice patterns" finden sich sog. bewährte "Design
Patterns", die viel überflüssige Restrukturierung während der En-
twicklungsphase vermeiden. Unit Tests - Bevor auch nur eine
einzige Zeile Code geschrieben wird, ist es unter XP Pflicht,
zuerst eine Testroutine zu schreiben, die genau die Erwartung an
ein Programm überprüft. Unit Tests für einfache Funktionen,
Prozeduren oder Klassen zu schreiben, ist recht einfach.
Schwieriger ist dies schon für Datenbankanwendungen, da Test-
datensätze definiert werden müssen, noch schwieriger für GUIs mit
Ein-und Ausgabe sowie Benutzerinteraktion. Die Ursprungsidee ein-
er Qualitätssicherung hat jedoch noch mehrere positive Nebenef-
fekte. Sie hilft dem Programmierer, sich bei dem Schreiben des
Codes für die Unit sich nur auf das Wesentliche zu konzentrieren,
sodaß nur so wenig Code geschrieben wird, wie benötigt wird,
damit der Test erfüllt ist. Andererseits zeigt es anderen Team-
mitgliedern, wie eine Funktion, Prozedur oder Klasse verwendet
wird, bzw. wofür diese da ist, ähnlich einem kleinen Programmier-
beispiel oder Tutorial, wie man es aus dem Internet kennt. Pair
Programming - Jeder Code, der in ein Zwischenrelease oder
endgültiges Release (production release) einfließt, wird von zwei
Programmierern programmiert, die gemeinsam vor einem Computer
sitzen und wechselweise programmieren. Dies ist zu Beginn sehr
gewöhnungsbedürftig, jedoch ist das Programmieren überhaupt ein
schöpferischer Prozess, in welchem jeder stets seine Ruhepausen
zum Nachdenken benötigt. Die Zeit des Nachdenkens darüber, wie
nun etwas kodiert wird, sind oft viel länger, als die eigentliche
Eingabe. So ähnlich, wie man während eines Gespräches Wortfind-
ungsprobleme hat, hat jeder während des Programmierens auch mal
ein "Brett vor dem Kopf". Derjenige, der dem anderen zuschaut,
ist erst einmal aus der Verantwortung, kann dem Partner entspannt
zuschauen, und sich dabei stressfrei auf den Code konzentrieren,
der gerade geschrieben wird. Das Resultat ist, daß die Code-
qualität sehr viel besser wird, und im Endeffekt viel weniger
Refactoring stattfinden muß. Es hat sich herausgestellt, daß Pair
- Programming im Endeffekt die Kosten nicht erhöht. Integration
von Code - der Reihe nach, niemals parallel. Das unter sequential
integration bekannte Einflechten von Code-Fragmenten in den
entgültigen Code (production code) sollte nur wenigen Mitgliedern
im Team der Programmierer vorbehalten sein. Gerade dann, wenn von
mehreren Entwicklern Code integriert werden soll, stellt man
gewöhnlich fest, daß Code - Abhängigkeiten zu veralteten oder
überflüssigen Codefragmenten existieren. Die Ursache liegt darin,
daß alle Entwickler ja stets nie die neueste Codebasis kennen
können, für welche sie Routinen entwickeln. Die hohe Abhängigkeit
von Code untereinander, gerade in der frühen Phase der Entwick-
lung, macht die Sache sehr aufwändig. Je besser die Planung von
Anfang an ist, je weniger Änderungen in der Struktur des Codes
später stattfinden müssen, umso geringer ist die Wahrschein-
lichkeit, daß Code verworfen werden muß, und mit ihm der davon
abhängige Code. Schlechte Planung, Organisation und vor allem
schlechtes Software - Design führen dazu, daß oft, obwohl die
Zahl der Programmierer vergrößert wird, die Entwickung noch mehr
stagniert. Änderungen an Klassen, von denen viele andere Klassen
abhängig sind, sind z.B. sehr aufwändig. Dies kann die Program-
mierleistung des Teams insgesamt dramatisch verschlechtern.
Häufige Integration und schnelle Veröffentlichung im Team sind
daher enorm wichtig. Definitionen von Schnittstellen zwischen
Klassen und Reduktion der Codeabhängigkeit durch Schaffung von
möglichst vielen, unabhängigen Modulen hat ebenfalls höchste Pri-
orität. Das gesamte Konzept von J2EE / JBOSS basiert auf dieser
Erkenntnis. Gemeinsame Eignerschaft am Code (collective code
ownership) bedeutet, daß jeder Programmierer zu jeder Zeit Code
anderer Team-Mitglieder korrigieren, verändern, erweitern oder
bereinigen darf. Nur so wird verhindert, daß eine Einzelperson zu
einer Art Nadelöhr für Veränderungen wird. Oft ist es so, daß
eine kleine Verbesserung am Code eines anderen Team-Mitgliedes
aufwändige Programmierung eines "Workarounds" im eigenen Code
einspart. Es gibt daher bei XP keinen Chef-Designer. Kein Mensch
kann bei hochkomplexen Projekten alle Details im Kopf behalten.
Außerdem, wenn das Team insgesamt für das Gesamtdesign des Codes
verantwortlich ist, sollte jedes Mitglied auch das Recht haben,
an jeder Stelle im Code Veränderungen oder Verbesserungen
vorzunehmen. Höchste Instanz sind eh die Unit - Tests. Code, der
diese Tests nicht erfolgreich durchläuft, darf eh nicht im pro-
duction code eingeflochten werden. Umfangreiche Änderungen am De-
sign erfordern automatisch Änderungen in den Test - Units, und
man kann recht schnell entdecken, welche anderen Codefragmente
plötzlich Test - Units nicht mehr bestehen. Da jeder im Team sich
im Code anderer Team - Mitglieder auskennt, fällt auch das Auss-
cheiden eines Teammitgliedes kaum negativ auf. Daß jemand anderes
in dem eigenen Code "herumpfuschen" darf, ist zunächst jedem Pro-
grammierer höchst zuwieder. Einerseits macht es auch Spaß, einem
Kollegen "mal eben" zu zeigen, wie es einfacher oder effektiver
geht, und andererseits lernt man selber ja sehr viel dazu. Gerade
junge Kollegen sollten diese Art von "Belehrungen" als fre-
undliche Geste auffassen, und sich für die Mühe ihres Kollegen
bedanken - "nobody is perfect!". Es wird die Zeit kommen, wo man
auch einem "alten Hasen" mal neue Dinge zeigen kann ;-) So kommt
auch Spaß am Lernen und somit viel Dynamik in die Bude. Oft wird
auf große Unterschiede bei der Fachkenntnis oder im Niveau der
Programmierer im Team hingewiesen. Diese Wahrnehmung mag ja dur-
chaus korrekt sein, jedoch ist hierbei zu bedenken, daß nicht
jeder Mensch das große Glück hatte, gute Lehrer gehabt zu haben.
Das, was wir sind, unsere Persönlichkeit, unsere Fähigkeiten
haben wir nicht schon von Geburt an, sondern wir sind die Summe
aller Einflüsse der Eltern, Familie und auch, ab dem Kindesalter
beginnend, fremder Menschen in unserem Leben. Unsere Identität -
auch Selbstbewußtsein genannt - ist die Summe aller Erfahrungen
im Leben. Leider leben wir in einem Land, in welchem in preußis-
cher Tradition Streitkultur und Demütigungskultur gepflegt wurde.
In China hingegen herrscht z.B. eine "Konsenskultur", mehr hierzu
siehe auch http://www.little-idiot.de/teambuilding/DualistischAm-
bivalentDialektisch.pdf http://www.little-idiot.de/teambuild-
ing/VonChinaLernen.pdf Durch die Anwendung von Pair-Programming
und ständig neue Paarungen im Team lernen alle in sehr kurzer
Zeit noch sehr viel hinzu, sodaß bald ein einheitliches Niveau im
Team erreicht ist, wovon alle im Team profitieren, nicht nur
fachlich, sondern insbesondere auch emotional. Unerfahrene Pro-
grammierer lernen dabei hauptsächlich Fachkenntnisse, die er-
fahrenen Programmierer lernen, wie man komplizierte Dinge mit
einfachen Worten erkärt. Dies ist eine sehr hohe Kunst und stets
eine Herausforderung auch für absolute Cracks. Die menschliche
Biochemie ist so gestaltet, daß sowohl neue Erkenntnisse im Ver-
stehen einer Tatsache, als auch das erfolgreiche Vermitteln mit
Endorphin - Ausschüttung, also Glücksgefühlen "belohnt" wird. Die
Arbeit macht dann allen im Team sehr viel mehr Spaß, neue Poten-
tiale werden entdeckt und freigesetzt. Hierbei kann jeder an sich
selber beobachten, wie er an seinen Aufgaben im Team nicht nur
fachlich, sondern auch von seinen persönlichen, menschlichen
Qualitäten wächst. Dies gibt Freude im Leben, schafft Begeis-
terung, die ansteckend ist. Optimiere niemals während der En-
twicklungsphase. Erst muß Code funktionsfähig sein, später dann
können Nadelöhre beseitigt werden. Versuche niemals, zu erraten,
wie groß die Verbesserung der Performance sein könnte, sondern
messe sie. Aus der Kybernetik ist bekannt, daß komplexe, dynamis-
che Systeme niemals lineares Verhalten zeigen. Siehe auch die 10
Netzgesetze: http://beat.doebe.li/bibliothek/b00926.html
Überstunden zerstören den Mannschaftsgeist und die Motivation im
Team. Kann ein Termin nicht gehalten werden, so helfen auch keine
Überstunden, oder die Vergrößerung des Teams. Die Ursache liegt
darin, daß Programmiertätigkeit ein schöpferischer Akt ist, und
ein Programmierer sehr viel mehr nachdenkt, als tatsächlich am
Computer Code eingibt. Das Gehirn arbeitet hochgradig parallel,
es denkt sogar im Schlaf weiter über Probleme nach. Nicht selten
kennen wir Menschen die Lösung erst, nachdem wir eine Nacht
drüber geschlafen haben. "Operative Hektik ersetzt geistige Wind-
stille" - dieser Spruch besagt, daß man durch Verbreitung von Un-
ruhe im Team die Entwicklung insgesamt nicht beschleunigt, weil
die Zahl der Fehler sich stark erhöht. Fehlersuche ist aber sehr
viel aufwändiger und anstrengender, als wenn man Zeit und Ruhe
hat, vorher genauer nachzudenken, und dann fehlerfrei codiert.
Jeder Fehler potenziert sich aufgrund der hohen Abhängigkeiten im
Code, gerade in großen Teams. Stattdessen korrigiert man bei den
release planning meetings die Zielvorgaben, indem man sehr
aufwändige Teile vereinfacht oder wegfallen läßt. XP ist so
konzipiert, daß ständig Planung, Design, Codieren und Testen in
kleinen Entwicklungs-Zyklen interativ im Wechsel stattfindet. Hi-
erdurch werden frühzeitig unrealistische Ziele erkannt und kor-
rigiert, oder es werden andere Wege gefunden. Oft nämlich ist es
einfacher, Arbeitsabläufe zu verändern, als umfangreich Software
anzupassen. 4. Testphase: Jede Implementierung von Code wird
durch Unit Tests geprüft. (Eigentlich ist Unit Testing eine Un-
termenge des "Test Driven Development = TDD). XP ist extrem
abhängig von Unit - Tests. Es gibt für verschiedenste Program-
miersprachen ein sog. "unit test framework", mit welchem man au-
tomatisierte Test Suites generieren kann. Code, der die Tests
nicht erfolgreich durchlaufen hat, darf grundsätzlich nicht ver-
wendet werden. Fehlt ein Test, so ist dieser unverzüglich zu er-
stellen. Der größte Widerstand gegen saubere Erstellung von Unit
Tests ist stets gegen Ende der Entwicklung, kurz vor der Fertig-
stellung. Hier zu schlampen, wäre ein elementarer Fehler. Ohne
vollständige Unit Tests dauert die Fehlersuche oft 100x so lange,
wie sie eigentlich müßte, und außerdem muß die Software nach fer-
tigstellung des ersten Release ja auch weiter gewartet werden. UT
zahlen sich immer aus, und zwar vielfach gegenüber dem
Mehraufwand der Erstellung. Debugger finden nur einfache Program-
mierfehler, aber keine Logikfehler in den Abläufen bzw. dem
Zusammenspiel der Klassen/Objekte. Unit Tests aber prüfen genau
dieses Zusammenspiel. Je härter es ist, einen Unit Test zu
schreiben, umso mehr wird er auch tatsächlich benötigt, und umso
größer wird die Zeitersparnis bei evtl. Fehlersuche sein.. Unit
Tests sind noch wichtiger beim Refactoring. Nur so kann
sichergestellt werden, daß Änderungen in der Code - Struktur
zwecks Lesbarkeit und Wiederverwendbarkeit keine Änderungen in
der Funktionalität bewirkt haben. Das frühzeitige Korrigieren von
kleinen Fehlern in kurzen Intervallen spart viel mehr Zeit ein,
als die Korrektur vieler Fehler kurz vor der Fertigstellung.
Fehler potenzieren sich im Code, ebenso, wie der Aufwand ihrer
Korrektur. Wird ein Fehler entdeckt, so muß ein Test sicher-
stellen, daß dieser nicht noch einmal passiert. Der Unit Test muß
dementsprechend angepasst werden. Akzeptanz - Tests (AT, früher
Funktionalitäts - Tests genannt) sind das zweite Standbein von
XP. Dies werden aus den user stories heraus geschaffen. Der Kunde
beschreibt Szenarios, wie getestet werden soll, damit
sichergestellt ist, daß die Funktionalität und Bedienbarkeit
genau so ist, wie gewünscht. Jeder AT repräsentiert ein er-
wartetes Verhalten vom System. Der Kunde ist verantwortlich für
Erstellung, Überprüfung und Einhaltung der Anforderungen an das
System. Sobald mehrere Akzeptanz - Tests nicht erfolgreich been-
det wurden, muß entschieden werden, welcher Tests hohe, und
welche niedrige Priorität haben. Eine user story filt als nicht
vollständig, wenn diese nicht alle Akzeptanz - Tests bestanden
hat. das bedeutet, daß neue Akzeptanz - Tests geschrieben werden
müssen, sobald bei einem Entwicklungs - Zyklus kein Fortschritt
erzielt wurde. Qualitätssicherung (QA) ist ein wesentlicher Teil
des XP Prozesses. Dieser kann durch eine unabhängige Gruppe
durchgeführt werden, kann aber auch durch Mitglieder des Entwick-
lungsteams durchgeführt werden. Die zweite Lösung reduziert
natürlich stark den Kommunikationsaufwand, weil Fehler nicht erst
analysiert, dann niedergeschrieben und vermittelt werden müssen,
sondern direkter Eingriff im Code das Problem dann egalisieren
kann. Die Ergebnisse der Akzeptanz - Tests werden allen Team -
Mitgliedern regelmäßig bekannt gemacht. Nachdem dies erst einmal
gesackt ist, so ging es mir, habe ich wieder von vorne angefangen
zu lesen, und so langsam dann erst verstanden, wie diese selb-
stkorrigierenden, dynamischen Prozesse eigentlich funktionieren,
welche impliziten Logiken der Wechswirkung der menschlischen Psy-
che und den prozessualen Abläufen hinter jedem einzelnen Punkt
verborgen sind. Häufig wird die Frage nach "Kontrolle,
Überprüfbarkeit" der Leistung gestellt. Hierzu ist zu sagen, daß
allein die Tatsache, in einem solchen "Extreme Programming" Team
mitzuarbeiten, und die Dynamik täglich beobachten zu können, mit
welcher Vehemenz, Intensität, Geschwindigkeit hier programmiert
wird, sehr viel Freude macht, sprich Endorphine freisetzt. Beim
Menschen sorgt allein der Prozess der Erkenntnis für Endorphin-
ausschüttung, siehe das Buch Körpereigene Drogen. Nicht selten
sieht das Großraumbüro, in welchem 1-2 Dutzend Programmierer
wirken, wie ein Schlachtfeld aus, Papier, Diagramme allerorten,
die Relikte intensiver Kommunikation. Durch Pair - Programming
und ständigen Wechsel sind nach wenigen Monaten alle Teammit-
glieder wissensmäßig auf demselben Stand, die Unterschiede in der
Leistung nur noch marginal. Software - Entwicklung im OpenSource
- Bereich, also der Linux Kernel, die GNU Toolkits, allen voran
der GCC C-Compilier, die grafischen Benutzeroberflächen, der
Apache Webserver, tausende von Anwendungswerkzeugen werden alle-
samt nach den Kriterien von XP entwickelt. Ein kleiner Unter-
schied jedoch besteht. Die Unit - Tests werden nicht von Program-
men durchgeführt, sondern die gigantische Anwendergemeinde von
vielen millionen Usern, darunter viele hunderttausende
Neugierige, die sich gerne eine Beta - Version von Linux (Man-
drake Cooker, Debian Testing, ...) herunterladen, führen die
Tests durch und melden, ob und wann ein Modul nicht funktioniert.
Das "Release early" Prinzip der OpenSouce Gemeinde sorgt dafür,
daß frühzeitig Fehler bekannt werden. ZopeX3, z.B. verwendet Unit
Testing. Extreme Programming ist kein Meta-Modell, sondern ein
ganz ausgefuchstes Prozedere, welches voller emergenter Prozesse
ist, die dafür sorgen, daß die typische, innere Reibung durch
Kommunikation und Abstimmungsaufwand überkompensiert wird. Fast
alle Open-Source Projekte werden (nicht vollständig) nach diesem
Modell programmiert. eXtreme Programming versucht auch einen
Paradigmenwechsel herbeizuführen. Je früher ein Fehler im Phasen-
verlauf Analyse, Design, Implementierung, Test entdeckt wird, und
je früher der Fehler im Phasenverlauf gemacht wurde, umso
geringer sind die Fehlerbeseitigungskosten, und umso weniger Code
muß verworfen werden. Dies ist letzendlich, über einen längeren
Zeitraum betrachtet, Emergenz. Es wird viel weniger sinnlos an
Konzepten weiterprogrammiert, die viel später verworfen werden
müssen. Vertreter der Phasenmodelle Wasserfall, V-Modell oder
Spiralmodell versuchten deshalb, Entscheidungen möglichst früh zu
treffen, Analyse und Design möglichst ausführlich und detailliert
zu machen. Das Festhalten an früh getroffenen Entscheidungen
führte bei diesen Modellen zu einem riesigen Berg an Dokumenta-
tion der einzelnen Phasen, die selten mit dem tatsächlichen
Quellcode konsistent war. XP Vertreter versuchen die Kosten der
Fehlerbeseitigung durch ein Bündel an Maßnahmen in den Griff zu
bekommen. Dazu zählen die Praktiken einfaches Design, automa-
tisierte Testfälle und Refaktoring. XP Vertreter wehren sich
nicht gegen Veränderung, sondern nehmen diese offen an. XP
Vertreter sehen den Quellcode als zentrales Produkt und halten
die Dokumentation aus den verschiedenen Phasen gering. Dies re-
duziert auch das Problem mit inkonsistenter Dokumentation. XP
Vertreter behaupten, dass durch das Maßnahmenbündel die Kosten
für Änderungen und Fehlerbeseitigung sich in engen Grenzen hält,
im Vergleich zu allen anderen Softwareentwicklungsmodellen.

Viele der Softwareentwicklungsmodelle sind aus der Automobilin-
dustrie übernommene, bewährte Methoden des Kaizen Optimierungs
Gurus Taiichi Ohno, der das Toyota Production System TPS erfun-
den, und das Unternehmen zu einem der lukrativsten Unternehmen
überhaupt gemacht hat. Sein Motto: Mein Leben ist der ständige
Versuch, gegen den gesunden Menschenverstand anzukämpfen - Sprich
für einen einzelnen Mitarbeiter ist kaum einzusehen, daß
Prozesse, die für ihn selber einen Mehraufwand bedeuten, für das
Team insgesamt sehr viel mehr Effizienz bedeuten.

Zunächst ein Beispiel aus der Automobil - Produktion, welches
hoffentlich die emergenten Prozesse erleuchtet, obwohl dies mit
Softwareproduktion direkt nichts zu tun hat. Die Produktion eines
hochkomplexen Automobils sehr vergleichbar mit der Produktion von
Software, angefangen von Schnittstellen-Definitionen der hun-
derten logischen Einheiten, bis hin zu Baugruppen, die modular
dezentral gefertigt, und auf einem Endmontageband nur noch zusam-
mengesteckt werden müssen. Schaut man sich die Zahlen von z.B. VW
und Porsche an, so fällt auf, daß bei VW jeder Mitarbeiter in
einem Jahr durchschnittlich 15 Auto's baut, Porsche jedoch nur 5
Auto's. Obwohl Porsche 3x soviel Mitarbeiter für ein Auto
benötigt, erwirtschaftet Porsche einen 30x höheren Gewinn je Au-
to. Folge Porsche kauft langsam VW auf 20% der Anteile nun im
Besitz von Porsche. Das kleine Familienunternehmen Toyota hat
letztes Jahr 10 Mrd. Gewinn eingefahren, soviel, wie die Top3
Automobilhersteller zusammen. Renault bietet den Logan handgefer-
tigt aus den Produktionsstätten der tschechischen Firma Dacia,
für einen Neupreis von 5000 an, einem Preis, zu welchem VW mit
Robotern noch nicht einmal einen einfachen Golf produzieren kann.
Die impliziten Logiken völlig neuer Produktionstechniken der Au-
tomobilproduktion sorgen für eine Effizienz, welche beweist, daß
die althergebrachten Denkweisen und Methoden völlig überholt
sind.

Ursache für diese Gewinnexplosion bei Porsche und Toyota war das
TPS (Toyota Production System), welches dafür sorgte, daß alle
Auto's fehlerfrei vom Band liefen. Porsche gelang es erst 1994,
also nach über 60 Jahren Automobilproduktion, den ersten fehler-
frei produzierten Porsche vom Band laufen zu lassen. Bei etwa 100
Arbeitsschritten, jeder zu 99% fehlerfrei ausgeführt, ergibt dies
- bei einer Potenzierung der Fehler - über 60% Ausschuß am Ende
des Bandes, was umfangreiche Nachbesserungsarbeiten zur Folge
hatte. Taiichi Ohno hat hier eine Methode eingeführt, wo jeder
nachfolgende Arbeitsschritt den vorhergehenden auf Fehlerfreiheit
kontrolliert, bzw. diesen korrigiert. Genau diese implizite Logik
der Qualitätskontrolle findet sich in den Methoden des XP (Ex-
treme Programing) wieder, siehe oben, oder auch http://www.lit-
tle-idiot.de/xp/ .

Die Methode des Aufspürens von Fehlern ist in der Software Pro-
duktion als Unit-Test bzw. TDD (Test Driven Development) bekannt.
Bevor nicht alle Module erfolgreich die Tests durchlaufen haben,
darf nicht weiter programmiert werden. Die Parallele zur
Qualitätskontrolle in der Automobilindustrie ist offensichtlich.
Unit Tests erscheinen auf den ersten Blick recht aufwändig, je-
doch werden sie umso dringender benötigt, je komplexer das Pro-
gramm-Modul ist. Weil durch moderne OO Programmierung (Objekt -
Orientierte Programmierung) mit Vererbung, Delegation, Polymor-
phie, Aspektorientierte Programmierung (AP) eine hohe
Abhängigkeit des Codes untereinander (Code Hierarchien) geschaf-
fen wurde, sind elemantare Änderungen an den Basisklassen fatal.
Kleine Änderungen dort ziehen umfangreiche Änderungen an den
abhängigen Klassen nach sich. Vergleicht man dies mit der Kon-
struktion eines Autos, so fällt z.B. bei einem VW-Bulli auf, daß
nur zum Tausch einer einfachen Kupplungsscheibe der komplette Mo-
tor samt Vorderachse ausgebaut werden muß (VR6). Dieses Auto,
z.B., ist aufgrund hoher Abhängigkeiten der Baueinheiten untere-
inander extrem wartungsfeindlich. Übertragen auf Software Pro-
grammierung bedeutet dies, daß der Ehrgeiz der Programmierer,
saubere Klassenhierarchien haben zu wollen, zwar für sauber
aufgeräumten Quellcode sorgt, jedoch Änderungen der Codestruk-
turen grundsätzlich sehr aufwändig sind. Als Beispiel möge hier
die grafische Benutzeroberfläche KDE von Linux dienen, welche
bislang auf QT3 aufgebaut ist. Die Entwickler haben es nicht
geschafft, QT3 sanft zu QT4 zu migrieren, stattdessen haben sie
QT4 von Grund auf neu programmiert und strukturiert.

Refactoring ist insbesondere dann, wenn die Codestrukturen zu hi-
erarchisch, sprich zu wenig chaotisch sind, oft unmöglich. Genau
dieser Punkt ist ein häufiger Streitpunkt bei Software Architek-
ten viele vertreten den Standpunkt, daß von Anfang an saubere
Design Pattern für ein perfektes Design sorgen müßten. Wohin das
geführt hat, kann man z.B. Beim Projekt FISCUS der Bun-
desregierung sehen, wo 130 hochkarätige Programmierer mit modern-
sten UML Werkzeugen (ROSE) und TOP Software Architekten eine
von Grund auf gute Software Struktur geschaffen haben, mit
sauberen Klassen-Hierarchien. Leider nur ist bei einem solchen
Mammut Projekt kein bewährtes Design Pattern verfügbar gewesen.
Der von Kent Beck in Extreme Programming vorgeschlagene Ansatz,
Pattern langsam sich entwickeln zu lassen, wobei von Zeit zu Zeit
bewußt der gesamte Quellcode eingestampft und von Grund auf neu
progammiert wird, wäre hier sicher erfolgreicher gewesen. Nach
mehrmaligem Neuprogrammieren des Codes zu Beginn des Projektes
hätte das Projekt FISCUS sicher schnell eine Codestruktur erhal-
ten, welche dauerhaft brauchbar und wartbar gewesen wäre. Der
Apache Webserver, die Portal Software PHP-Nuke, das CMS System
Zope, die Groupware E-Groupware, PHProject und viele andere Open-
Source Software Projekte zeigen klar, daß sogar sehr viel ein-
fachere Software mehrfach neu programmiert wurde, weil Er-
weiterungen und Änderungen unmöglich wurden. Als einziges Projekt
ist Zope vollständig nach den Methoden des XP programmiert wur-
den, inclusive umfangreichen UNIT-TESTS.

Analyse und Beurteilung von Softwarestrukturen

Wie analysiert und beurteilt man vorhandene Code Strukturen?
Jesús M. Gonzáles-Barahona et al. haben ein Programm geschaffen,
welches aus einem CVS Baum heraus mit Hilfe des genetischen Gir-
van Newman - Algorithmus die Codestrukturen visualisieren kann.
Anhand des COCOMO Modells wurden z.B. die geschätzten Kosten ein-
er Neuentwicklung der Debian Linux 2.2 Distribution auf 1.9 Bil-
lionen US$ geschätzt. IBM hat schon lange verstanden, und jede
weitere Entwicklung eigener Betriebssysteme eingestellt. Siehe
auch http://www.little-idiot.de/teambuilding/apache-structure.pdf
. Von den Entwicklern der QT3 und QT4 Libraries wissen wir, daß
die komplette Neuentwicklung von QT4 unter Berücksichtigung des
Wissens um die Strukturfehler der neuen Version QT4 nur etwa 1/3
der Kosten von QT3 gekostet hat. Mit Stolz verweisen die Entwick-
ler darauf, daß QT4 nun erheblich wartungsfreundlicher ist, bzw.
auch viel einfacher zu erweitern bzw. zu ergänzen ist. Software-
Entwickler, die Software Cross-Platform - Entwickeln wollen, sei
QT4 empfohlen sie steht für Windows, MAC OS X, Linux, UNIX zur
Verfügung. Man muß hierbei allerdings berücksichtigen, daß die
Entwicklung einer GUI sehr saubere Klassen - Hierarchien er-
fordert, da die Einarbeitungszeit für Entwickler recht hoch ist.
Die Entwicklung einer GUI ist nicht vergleichbar mit dem Projekt
FISCUS z.B. Vergleicht man z.B. Mit den Methoden des XP, so fällt
auf, daß XP alle vier Entwicklungszyklen 1. Planung 2. Design, 3.
Codieren, 4. Testen in schneller Folge von ca. 1-2 Wochen immer
wieder erneut durchlaufen werden, interativ. Die Folge dieser
Vorgehensweise ist, daß Designfehler absolut konsequent frühzeit-
ig entdeckt und radikal korrigiert werden, egal, ob der Code kom-
plett neu geschrieben werden muß. Ich vermute mal, daß seit Ent-
deckung der Tatsache, daß etwas mit dem Design des FISCUS - Pro-
jekt nicht stimmte, und dessen Einstellung - viele hundert Mann-
jahre unsinnig verballert wurden. Niemand der Entscheider hatte
den Mut, den Code nach 5 Jahren sang und klanglos einzustampfen,
und von vorne zu beginnen. Bei OpenSource Projekten, wie z.B. PH-
PNuke kann man in Google nachlesen, daß recht frühzeitig schon
eine Abspaltung des Codes in Postnuke stattgefunden hat, aufgrund
der mangenden Modularität und Sprachanpassungsmöglichkeiten.
Recht viele Projekte in der Open-Source Szene wurden einfach
eingestampft, und neu begonnen, wie Eric Raymond beschrieben hat:
http://www.little-idiot.de/xp/opensourceentwicklung.htm Dafür be-
sitzen die erfolgreichen Open-Source Programme ein glänzendes De-
sign, sind modular aufgebaut, einfach zu erweitern und zu
verändern.

Die Grenzen des Refactoring sind recht schnell erreicht, wenn die
Codestrukturen bzw. das Design nicht stimmt. Nirgendwo kann man
mehr über Komplexitätstheorie in der Softwareentwicklung lernen,
als in der Open-Source Szene und dort vor allem bei den beson-
ders großen Softwarepaketen, wie z.B. dem Linux Kernel, dem
Free/NetBSD Kernel, dem Apache Webserver mitsamt seinen unzähli-
gen Modulen, dem Office Paket OpenOffice 2.0, und einigen Group-
ware Produkten, darunter z.B. auch Compière, einem ERP / CRM
Programm.

So haben z.B. die Besitzer der kommerziellen Closed Source -
Software CYCOS, siehe http://www.cycos.de , nach sorgfältiger
Analyse der Code - und Programmierer Strukturen, verteilt über
mehrere Länder, darunter auch Frankreich und U.S.A. - schnell und
schmerzlos entschlossen, ihren Laden an Siemens zu verkaufen.
Ende, Schluß, AusDieMaus. Refactoring, so ergab die Analyse, war
aufwändiger, als eine komplette Neuprogrammierung. Neuprogram-
mierung war leider auch nicht mehr möglich, weil das Wissen um
die Kommunikations - Protokolle durch den Wechsel und Ausscheiden
von Programmierern in der Firma nicht mehr vorhanden war. Niemand
weiß nun mehr genau, wie die Software insgesamt funktioniert, wie
und wo welche Kommunikationsprotokolle was bewirken. Auch ein aus
den U.S.A. eingeflogener Guru für SCUM, XP, Agile Programming
kann an dieser Tatsache nichts ändern. Ein ähnliches Schicksal
hatte auch die U.S.A. getroffen es gibt inzwischen niemanden
mehr, der das Ingenieurswissen der Gruppe um Werner von Braun
herum festgehalten hätte aus der Raumfahrer-Nation, welche einst
zum Mond flog, ist ein teurer Papiertiger namens NASA ohne eine
wirklich sinnvolle Aufgabe geworden. Russische und europäische
Raketen bringen Satelliten viel preiswerter und sicherer ins All,
eine Raumstation ISS benötigt niemand.

Eine Programmierer Gruppe, welche für ein Modul bei Toll-Collect
zuständig war, hatte ein Problem dem zuständigen Projektleiter
lief das Projekt aus dem Ruder, er wußte nicht mehr, welcher Pro-
grammierer woran genau arbeitete, diese kamen und gingen, wann
sie wollten. Ein auf die Schnelle angeordnetes Kommunikation-
straining nach dem Modell von Friedemann Schulz von Thun schaffte
auch keine dauerhafte Verbesserung, weil Mensch stets dazu neigt,
nach erfolgreichem Training in die alten Verhaltensmustern
zurückzufallen, insbesondere im Team. Die tatsächliche Ursache
lag wo ganz anders die Programmierer arbeiteten für private Pro-
jekte unbemerkt vom Management Mangelhafte Kontrollprozesse
waren die Kernursache. Insgesamt kann man sehr viel von der En-
twicklung erfolgreicher Open-Source Projekte lernen, eXtreme
Programming ist genaugenommen, eine Sammlung von emergenten
Prozessen, wobei sehr viele aus der Prozessoptimierung des Toyota
Produktions Systems entnommen sind. Wer sich für diese Denkweisen
interessiert, dem sei das Buch Lean Thinking von Womack/Jones,
ISBN 3-593-37561-3

Je nach menschlich / psychologischen Eigenschaften ist ein Pro-
jektleiter/Manager gut beraten, sich in einem Team die psycholo-
gisch/menschlichen Eigenschaften seiner Mitarbeiter individuell
genau anzusehen. Nichts spricht dagegen, einen Teil der Mitar-
beiter nach dem eXterme Programming Modell arbeiten zu lassen,
andere nach agilen Methoden, oder auch wiederum andere Mitarbeit-
er Pair-Programming oder sogar gänzlich alleine wurschteln zu
lassen. Wer die impliziten Logiken hinter den Modellen verstanden
hat, ist in der Lage, sich aus den verschiedensten Softwareen-
twicklungsmodellen diejenigen Prozesse herauszusuchen, die auf
die psychologisch/menschlichen Eigenschaften der Individuen im
Team genau passen. Wer Individuen über einen Kamm schert, also
allen gemeinsam z.B. XP aufzwingt, riskiert die innere Kündigung
von äußerst produktiven und wertvollen Mitarbeitern. Als sehr
wirksam hat sich nach meiner Erfahrung erwiesen, das Wissen um
die emergenten Prozesse in das Team hineinzutragen, und die Mi-
tarbeiter selber entscheiden zu lassen, wie diese sich organ-
isieren wollen. In der Kunst hat Lois Sullivan bzw. in Deutsch-
land erstmals das Bauhaus einen Slogan geprägt: Form folgt Funk-
tion oder darf es nicht auch heißen: Funktion folgt Form? Kann
ich eine Tasse zum Trinken von heißem Tee evtl. nicht verwenden,
wenn sie nicht eine bestimmte Form hat? Ebenso verhält es sich
mit den bestehenden Strukturen innerhalb der Software. Struktur
der Zusammenarbeit der Programmierer und Struktur der Software
müssen übereinstimmen, unabhängig von den Software-Entwick-
lungsprozessen, wie man z.B. bei der Analyse der Apache Soft-
ware-Struktur sehen kann. Zur Visualisierung eines CVS (Root) -
Baumes stehen mächtige, kostenlose Werkzeuge bereit, mit denen
z.B. die Strukturen des Apache Webservers visualisiert wurden,
siehe
http://www.little-idiot.de/teambuilding/apacheentwicklung.gif
Die Essenz dieser Alchemie, des Wissens über diese emergenten
Prozesse und deren Wechselwirkung mit den psychologisch
/ menschlichen Eigenschaften läßt sich im Grunde auch auf andere
Bereiche anwenden. Hat das Team es einmal verstanden, wie
man mit wenigen Regeln Arbeits - Prozesse so gestaltet, daß Emer-
genz auftritt, so führt das dazu, daß Mitarbeiter in einem Team
ständig gedanklich auf die Suche nach besseren, prozessualen
Abläufen gehen, also ständig die Abläufe der täglichen Zusamme-
narbeit optimieren. Das Management gibt hierzu eigentlich nur die
Meta-Prozesse vor, die eigentliche Optimierung der Arbeit-
sprozesse bzw. Programmieraufträge abliegt dann den Mitarbeitern
selber. Erfahrungsgemäß steigt die Begeisterung bei den Mitar-
beitern stark an als Glücklich empfindet sich stets ein Mensch,
der eine Vielzahl von Handlungs- und Gestaltungsmöglichkeiten
hat. Geld ist in unserer Zeit ein Mittel, um mehr Gestal-
tungsmöglichkeiten zu haben. Interessanterweise ergeben Umfragen
bei hochbezahlten Programmierern, daß Geld nicht glücklich macht,
wenn Gestaltungsmöglichkeiten fehlen. Die OpenSource Szene be-
weist, daß Programmierer auch völlig ohne Entlohnung freiwillig
in ihrer Freizeit arbeiten, sofern sie die Welt mitgestalten
können. Leider verstehen es bislang kaum hochkarätige Manager
oder Projektleiter, warum manche niedrig bezahlte Mitarbeiter mit
viel Begeisterung mehr leisten, als andere, hochbezahlte Mitar-
beiter. Im übrigen ist das Prinzip uralt: Das Rote Kreuz mit
seinen hunderttausenden, ehrenamtlichen Helfern nutzt schon seit
Jahrzehnten dieses emergente Prinzip, welches dann von Richard
Stallmann für die Softwareentwicklung unter dem Namen GNU neu er-
funden wurde. Wer einmal die GNU Prozesse analysiert, findet
dort schnell die emergenten Prozesse wieder, die in diesem
Beitrag ansatzweise beschrieben wurden. Nichts spricht daher auch
dagegen, für ein kommerzielles Programmier-Projekt - eine
riesige Heerschar von freiwilligen Programmieren als Helfer zu
gewinnen, um somit die Entwicklungskosten gewaltig zu reduzieren.
IBM hat dies schon lange verstanden, siehe das Eclipse und Linux
Projekt. Eine riesige Schar von professionellen Programmieren
(mehrere Mrd. US$ Volumen jährlich) arbeiten für eine Vielzahl
von Open-Source Projekten, allen voran natürlich LINUX, welches
komplett alle alten Betriebssysteme von IBM ersetzen soll (OS/2,
OS/390, MVS ...) Ob und wie die Intergration funktionieren kann,
läßt sich erst nach einer genauen Analyse der Interessen der
Open-Source Community entscheiden. Wer ein noch tieferes
Verständnis von Emergenz bzw. emergenten Prozessen bekommen
möchte, dem seien die Kybernetik Bücher von Heinz von Förster Der
Anfang von Himmel und Erde hat keinen Namen oder meine Überset-
zung von SunTse's Kriegsstrategien lesen, welche den Grund für
den durchschlagenden Erfolg von alten, chinesischen Generalen,
Napoleon und auch der Wehrmacht anschaulich darstellen, siehe:
http://www.little-idiot.de/teambuilding/SunTsuKunstDesKrieges.pdf

Regelmäßige, 3-tägige Seminare "Emergente Software-Entwicklungs-
Prozesse" finden monatlich in Aachen statt, nächste Termine
18.-20. und 25.-28. Oktober 2005. Anmeldung bitte an

mailto:***@web.de

Dieser Beitrag ist unter:
http://www.little-idiot.de/teambuilding/EmergenteSoftwareEntwicklungsProzesse.pdf

zu finden.

"Was nicht auf einer einzigen Manuskriptseite zusammengefaßt wer-
den kann, ist weder durchdacht, noch entscheidungsreif" (Dwight
David Eisenhower, 34. Präsident der USA 1953-1961; *14.10.1890)











Emergente Softwareentwicklungsprozesse

(emergent software development processes)

© Oktober 2005, Guido Stepken

Dieser Beitrag beschreibt neuartige, aus der Kybernetik (Steuer-
mannslehre) stammende, Lösungsansätze derjeinigen Probleme, die
bei mittleren und großen Software - Projekten (C, C++, JAVA) typ-
ischerweise auftreten. Gewünscht ist stets die schnelle, zeitge-
naue und preiswerte Lösung. Komplexe Software ist nicht nur
hochgradig fehlerbehaftet, sondern auch in der Herstellung oft
viel teurer, als kalkuliert, immer hinter dem Zeitplan zurück-
liegend. Stundenzettel, MS-Project, Groupware mit Todo-Listen,
Zielvereinbarungen, Motivations-Kurse, NLP, organisierendes Pro-
jektmanagement nach dem Harzburger Modell streng hierarchisch
geordnet, mit Kontrollstrukturen alleorts, Prinzipienreiterei,
unausgereifte Methoden, ... führen zumeist dazu, daß die Zahl der
Häuptlinge in Relation zu den Indianern ansteigt, oder kurz vor
Scheitern des Projektes zusätzliche Programmierer engangiert wer-
den, die die anderen nur von der Arbeit abhalten. Umso er-
staunlicher sind die Erfolge der freien Softwareentwicklung, wo
eine wilde Horde von Hackern ohne erkennbare Planung und kaum
erkennbarer Organisation es schafft, Softwareprojekte mit vielen
millionen Zeilen fertigzustellen, zu warten und weiterzuentwick-
eln, siehe z.B. http://www.little-idiot.de/teambuilding/apacheen-
twicklung.gif . Wie gelingt es in freien Projekten, ohne au-
torisierte Projektleitung, ohne Projektmanagement, hierarchische
Strukturen, Entscheidungen zu treffen, Aufgaben zu verteilen und
zu koordinieren? Keine Kaffeekränzchen, keine dauernden Be-
sprechungen, keine kontraproduktiven Bedenkenträger Habe ich
schon immer gesagt..., kaum innere Reibung ... Welche impliziten
Logiken sich hinter den verschiedenen Softwareentwicklungsmod-
ellen, also den prozessualen Abläufen verbergen, und wie diese
mit den psychologisch / menschlichen Verhaltensweisen wechsel-
wirken, sei hier anhand einiger Beispiele aus der Praxis
beleuchtet. Emergente Prozesse sind das Geheimnis hinter den aus-
gefeilten Softwareentwicklungsmodellen. Der Begriff Emergenz
stammt aus der Kybernetik und besagt folgendes: Das Ganze ist
mehr, als die Summe seiner Komponenten!. Der folgende Beitrag
beleuchtet moderne Softwareentwicklungsmodelle aus dem Blick-
winkel der Emergenz.

Zunächst ein Beispiel für Emergenz. Jeder hat schon einmal das
HTTPS Protokoll verwendet, bei welchem eine verschlüsselte
Verbindung zwischen Browser und Server (z.B. für Homebanking) zu-
stande kommt. Da fragt man sich doch gleich, wo die Passworte für
Ver-und Entschlüsselung ausgetauscht worden sind, ohne daß jemand
Drittes den Datenverkehr mitlesen kann. Die Antwort ist: Es wur-
den niemals Passworte ausgetauscht, dennoch kommt ein ver-
schlüsselter Krypto-Tunnel zustande. Wie kann das? Man stelle
sich eine Kiste vor, welche mit zwei Vorhängeschlössern ver-
schießbar ist. Nun lege man eine Nachricht in die Kiste, schließe
mit seinem eigenen Vorhängeschloß ab, den Schlüssel behalte man
für sich. Nun versendet man diese Kiste per Post. Niemand Drittes
kann den Inhalt lesen, da diese ja verschlossen ist. Nun bittet
man den Empfänger, sein eigenes Schloß als zweites Schloß
anzubringen, den Schlüssel für sich zu behalten, und die Kiste
zurückzusenden. Die Kiste wieder in Händen, entfernt man das
eigene Schloß, und sendet die Kiste abermals zurück. Der
Empfänger kann nun sein eigenes Schloß entfernen, den Inhalt
lesen. Zu keinem Zeitpunkt wurde ein Schlüssel ausgetauscht, und
zu keinem Zeitpunkt war die Kiste unverschlossen unterwegs. Die
Schlüssel, stellvertretend für Passworte oder Keys wurden nicht
übermittelt. Durch den emergenten Prozeß des dreimaligen Hin-und
Herschickens wurde die Übermittlung eines Schlüssels überflüssig.
Und wenn man nun sich das PGP Verfahren anschaut, welches auf
diesem emergenten Prinzip aufbaut, so steht hier stellvertretend
für die doppelt verschließbare Kiste eine Primfaktorzerlegung
eines zwei bzw. dreifachen Produktes von langen Primzahlen. Wo
nun liegt die Emergenz dieses Prozesses? Dieser Prozess erst
ermöglicht die täglichen, milliardenfachen, sicheren Daten-
verbindungen ohne riesigen Verwaltungsaufwand, wo Passworte oder
Schlüssel auf verschiedenen Wegen übermittelt werden müssen,
spart also immenses Geld ein. Dieser emergente Prozess ist unter
dem Namen Diffie Hellmann Key Exchange bekannt, jedoch ist das
Prinzip kaum wirklich verstanden.

Der Begriff Emergenz beschreibt also Prozesse, welche durch ihre
impliziten Logiken nachfolgende Prozesse erst ermöglichen, erhe-
blich beschleunigen oder Resourcen sparen.

Ein weiteres Beispiel betrifft Kontrollprozesse, die leider nicht
unabhängig vom Entwicklungsprozess selber sind. Wie messe ich die
Arbeitsleistung eines Programmierers mit möglichst geringem
Zusatzaufwand? Zahlreiche Softwarehersteller haben hier unter-
schiedliche Verfahren, welche allesamt einen riesigen Verwal-
tungsaufwand erfordern, also das Produkt enorm verteuern. lines
of code written ist ganz sicher kein Maßstab, an welchem man
einen Programmierer messen könnte. Es gibt für einen Programmier-
er immer Möglichkeiten, die Codebasis aufzublähen, durch Cut-und
Paste (Code-Reuse!-), wobei 3000 Zeilen auch durch wenige hundert
Zeilen hätten ersetzt werden können. Aufgeblähter Quellcode durch
Codegeneratoren, z.B. verteuert das Refactoring, sprich die Soft-
warewartung enorm. Statistiken bei großen Softwareprojekten haben
ergeben, daß ein Programmierer im Laufe von mehreren Jahren
täglich nur ca. 5 endgültige, bleibende Codezeilen zum Produkt
beiträgt. Ständige Strukturänderungen, das oft notwendige Verwer-
fen von Modulen sorgen dafür, daß die Arbeitsleistung enorm ab-
sinkt. Kriterium sollte also vielmehr sein: lines of software not
written - die Abgrenzung zum Nichtstun fällt hier schwer.... Ein
gutes Design Pattern, entworfen von einem erfahrenen Software-
Architekten, so die allgemeine Denkweise, sorgt dafür, daß im
Laufe der Entwicklung nur wenig Code verworfen werden muß. Gute
Design-Pattern sorgen gewöhnlich dafür, daß die Kosten der Soft-
wareentwicklung auf 1/3 bis ¼ reduziert werden kann. So effizient
nämlich war das Nachprogrammieren von SUN's J2EE. Die Progammier-
er des Clones von JBOSS hatten schließlich ein perfektes Design-
Pattern vorgegeben, das Nachprogrammieren der Routinen war nur
reine Fleißarbeit, mit minimalem Test-und Koordinationsaufwand.
Dasselbe gilt hier auch für den Windows Emulator WINE. Insbeson-
dere Frameworks, allen voran J2EE, .NET, QT4 (KDE), GTK+ (GNOME)
und zahlreiche RAD Werkzeuge enthalten implizite Design-Pat-
terns, an denen sich Programmierer orientieren können, um schnell
produktiv zu sein. Hierbei kann die Arbeitsleistung durchaus auf
durchschnittlich 200-500 Codezeilen je Tag ansteigen. Hierin
liegt also ein riesiges Potential für Emergenz, wo ein aus-
gereiftes Design-Pattern für überproportionale Leis-
tungssteigerung des gesamten Programmierer Teams sorgt. Hierbei
wird die unvermeidliche innere Reibung, der Verwaltungs, Test- ,
Kordinations und Kommunikationsaufwand stark reduziert und bei
weitem überkompensiert. Was aber, wenn einfach kein bewährtes De-
sign Pattern vorliegt, wie z.B. bei dem kürzlich eingestellten
Bundesprojektes FISCUS? Die Erfahrungen der hierfür engagierten
TOP-Software Architekten (J2EE) führten dazu, daß lange Zeit das
Projekt gut voranging, bis sich zu einem recht späten Projekt-
stand herausstellte, daß das Design doch nicht tauglich war. Wenn
ein Softwareprojekt gut vorangeht, ist dies noch lange keine
Garantie dafür, daß nicht kurz vor Schluß doch noch wegen
unlösbarer Probleme der Großteil des Codes neu entwickelt werden
muß. Beim Projekt FISCUS wurden viele hundert Mannjahre letz-
tendlich verschwendet, geschätzt etwas unter einer Milliarde Eu-
ro. Das Software-Design-Pattern von J2EE, die saubere Trennung
von Businness Logik, GUI und Workflow, die hin-und herflitzenden
Container, die sich mitsamt Daten und zugehörigen Programmen eine
CPU im SUN-Netzwerk suchen, stellte sich als Blödsinn heraus.
Aber das System skaliert ja laut Angaben von SUN, nur leider
nicht mit riesigen Datenbeständen ... Dementsprechend war jedes
Softwareentwicklungsmodell unter J2EE zum Scheitern verurteilt.
Das Design von J2EE ist nicht für diese Art von Anwendung gedacht
gewesen. Zurück zur Beurteilung der Programmierer Leistung
diese ist enorm Abhängig von einer Vielzahl von Faktoren - am
allerwenigsten haben in Großprojekten die individuellen
Fähigkeiten des einzelnen Programmierers damit zu tun, wennauch
oft Know-Know Unterschiede innerhalb des Teams bemängelt werden,
welche jedoch leicht durch regelmäßiges Pair-Programing beseitigt
werden können. Emergenz - Das Ganze ist mehr, als die Summe sein-
er Komponenten ist hier für die Leistung des Teams insgesamt ver-
antwortlich. Im Grunde liegt bei den erfahrenen Programmierern
eine große Chance sie können durch weitergabe ihre Wissens die
jungen Kollegen mitziehen und die Leistung des Teams erheblich
steigern. Eine einzige gute Idee, z.B. kann dem Team insgesamt
enorm Entwicklungszeit einsparen, wie z.B. die Erkenntnis, daß
komplexe Datenstrukturen und einfacher Code effizenter sind (auch
in der späteren Wartung des Codes), als einfache Datenstrukturen
und komplexer Code. Warum angesichts dieser Tatsache immer noch
Entscheider haufenweise auf SQL Datenbanken setzen, und nicht
auf OO-Datenbanken bzw. Postrelationale Datenbanken, allen voran
PostgreSQL (Kern ist OO!), GOODS, ZODB oder die kommerzielle
Datenbank CACHÉ von Intersystems, ist mir ein Rätsel. Persistenz,
hyperdimensionale Datenbankstrukturen, einfaches Datenbankdesign,
erheblich höhere Leistung gegenüber den SQL Marktführern Oracle,
MS SQL, ... sowie stark vereinfachte Programmierung sprechen klar
für OO-Datenbanken. SQL Datenbanken beherrschen leider nur ein-
fache Datenstrukturen, die Komplexität des Programmiercodes
verkompliziert sich daher enorm, damit steigen auch die
langfristigen Wartungskosten auf ein Vielfaches.

Kontrolle der Leistung

Die Messung der Leistung eines Programmierers kann also nur an-
ders erfolgen, hierzu möge folgendes im Alltag beobachtbares
Beispiel dienen: Wie kontrolliert ein Manager eines Restaurants
seine Angestellten, Kellner, Küche, ohne ständig mit seiner Nase
dabei zu sein? Er installiert Kontrollprozesse! Die Kellnerin
nimmt eine Bestellung für ein Essen auf, bongt in die Kasse,
diese druckt die Bestellung für die Küche aus. Die Küche stellt
bereitet das Essen zu, die Kellnerin liefert es und kassiert. Der
Manager habe z.B. 25 Steaks eingekauft, die Küche 25 zubereitet,
die Kellnerin jedoch nur 23 verkauft hier betrügt die Kellnerin.
Hat die Küche nur 23 zubereitet und die Kellnerin 23 verkauft, so
betrügt der Koch. Ein Einfacher Abgleich von Einkaufslisten,
Bestellungen und der Kasseneinnahmen zeigt sofort, ob jemand be-
trügt, wieviel Trinkgeld gegeben wurde, u.s.w. Dies sind Kon-
trollprozesse, genauer prozessuale Abläufe, die von dem Manage-
ment vorgegeben wurden, und welche eine perfekte Kontrolle
ergeben, ohne daß der Manager ständig anwesend sein muß. Eine
stichprobenartige Kontrolle der Vorräte schadet natürlich auch
nicht, schließlich könnten Kellnerin und Koch sich ja abge-
sprochen haben, nebenher privat einzukaufen und zu verkaufen.
Die implizite Logik der Kontrolle im Restaurant liegt einfach
darin, daß in einem geschlossenen Kreislauf bei den verschiedenen
Verarbeitungsprozessen die Stückzahlen unabhängig gemeldet/gebont
werden müssen. Toyota und Porsche haben z.B. Bei der Fließband-
Produktion eingeführt, daß der Nachfolgende die Arbeit des
Vorgängers kontrolliert, damit sich die Fehler im Laufe von 100
Arbeitsgängen nicht potenzieren, sondern gegenseitig aufheben.
Bevor nicht die Fehlerbehoben sind, läuft das Band nicht weiter.
Der Druck der Gruppe zwingt jeden Arbeiter, präzise und genau zu
arbeiten. Ford und Volkswagen (siehe Geländewagenproduktion in
Wolfsburg) haben gerade ein neues Akkord Modell eingeführt,
welches bei Fließbandarbeit nur die Stückzahlen der 100% perfekt
gefertigten Autos zählt, OK-Akkord genannt. Die impliziten
Logiken der psychologisch / menschlichen Eigenschaften von Mensch
wechselwirken hier mit den prozessualen Abläufen. Nur eine
einzige Regel sorgt dafür, daß sich das Verhalten von tausenden
Mitarbeiter verändert. Schlechte Manager haben jahrelang jedem
Mitarbeiter genauestens vorgeschrieben, welche Arbeiten/Hand-
griffe wie zu machen sind, moderne Manager gestalten Prozesse,
definieren nur wenige Regeln, genau wissend, daß die Mitarbeiter
als sog. eigenständige Agenten eigenständig und mit viel Begeis-
terung und Engagement alles notwendige koordinieren werden, um
ihr Einkommen zu optimieren.

Ein klares Beispiel für Emergenz kann man auch bei einem sehr
verblüffendem Experiment von Reynolds 1987 beobachten, welcher
die hochkomplexen Flugbewegungen eines Vogelschwarms beschreibt:

1.Kollisionsvermeidung: Vermeide Kollision mit Nachbarn oder an-
deren Hindernissen 2.Geschwindigkeitsanpassung: Passe deine
Geschwindigkeit der deiner Nachbarn an 3.Schwarmerhaltung: Ver-
suche, in der Nähe deiner Nachbarn zu bleiben

Diese 3 einfachen Regeln genügen bereits, um das komplexe Verhal-
ten eines fliegenden Vogelschwarms zu simulieren, der fliegend
Hindernissen ausweicht, sich in zwei Schwärme aufteilt, um ein
größeres Hindernis zu umfliegen, über Berge und durch Täler
fliegt. Ein deutscher Beamter oder Angestellter würde wohl eher
auf die Idee kommen, jedem einzelnen Vogel entsprechend seinen
Fähigkeiten eine genaue Flugbahn vorzuschreiben, und individuelle
Verhaltensvorschriften zu machen. Genaugenommen würde jede Biene
somit durch die Flugtauglichkeitsprüfung für Piloten fallen. Ein
Kybernetiker, der das Prinzip für Emergenz verstanden hat,
schreibt nur drei Regeln für prozessuale Abläufe vor, wohl wis-
send, daß jeder Vogel als Individuum als eigenständiger Agent
selber entscheiden kann, welche Flugbahn dieser einschlägt, und
nach welchen Kriterien er dies entscheidet.

Was lernt man hieraus für die Kontrolle von großen Software-
Teams? Analysiert man die impliziten Logiken des Restaurant-
Beispiels, so fällt auf, daß die Kontrolle nicht in der genauen
Messung der Arbeitsleistung des einzelnen besteht, also die Er-
fassung der Tätigkeiten eines Programmierers über Stundenzettel,
lines of code written/changed/deleted/refactored, sondern die
emergente Leistung des Teams insgesamt muß beurteilt und gemessen
werden. In einem Netzwerk von Programmierern ergibt sich ein eng-
maschiges Geflecht von Abhängigkeiten der verschiedenen Codemod-
ule untereinander, Programmier und Änderungswünsche an die Kol-
legen, die für die Nachbarmodule zuständig sind. Diese und nur
diese können korrekt die Leistung, Einsatzbereitsschaft, und
Qualität der Arbeit ihres Kollegen korrekt beurteilen. Ein ein-
facher Beurteilungsfragebogen, der nur abfragt, mit welchem Pro-
grammierer oder Gruppe der Programmierer zu tun hatte, wie er die
Leistung und Qualität seines Kollegen einschätzt, genügt. Die im-
pliziten Logiken des Extreme Programming, siehe auch
http://www.little-idiot.de/xp/ beinhalten eine vergleichbare Art
der mündlichen Beurteilung der Leistung der Kollegen, jeder muß
im Abstand von 1-2 Wochen regelmäßig die Resultate seiner Arbeit
vor dem Team vorstellen, wie weit er gekommen ist, welche Prob-
leme aufgetreten sind. Die impliziten Logiken der prozessualen
Abläufe von XP führen dazu, daß der Programmierer selber seine
Leistung korrekt einschätzen lernt, wodurch die Projektleitung
dann erst in der Lage ist, realistische Kosten und Termine nennen
zu können. Der Programmierer mag sich nur ungern die Blöße geben,
seine zugesagte Arbeitsleistung wiederholt nicht erreicht zu
haben.

Meta Prozesse

Agile Programming (AP) oder auch Agile Software Prozesse sind der
neueste Schrei in der Softwareentwicklung. Agile Software En-
twicklungsverfahren sind bewegliche, flinke Prozesse, die sich
explizit nicht gegen Änderungen der ursprünglichen Anforderungen
stellen. Am Projektanfang definierte Anforderungen stimmen zum
Projektende erfahrungsgemäß nicht mehr. Hierdurch entsteht ein
sog. moving target, also variable Zielstellung, die es gilt, so
gut wie möglich zu treffen. Der Erfinder Coldewey teilt die
Prozesse des AP daher in Meta-Prozesse (meta= (griech.) über)
auf, die nur die Rahmenbedingungen stellen, und die konkrete Pro-
grammierarbeit auf.

AP verfolgt vorrangig folgende vier Maximen:

1.Einzelpersonen und Interaktionen sind wichtiger als Prozesse
und Werkzeuge 2.Laufende Systeme sind wichtiger als umfangreiche
Dokumentation 3.Zusammenarbeit mit dem Kunden ist wichtiger als
Vertragsverhandlungen 4.Reagieren können auf Veränderung ist
wichtiger als Pläne zu verfolgen In Deutschland ist der Glaube an
das Funktionieren von strengen Vorgaben für die Softwareentwick-
lung noch vorherrschend, begründet in der preußischen Tradition,
welche das Harzburger Modell des hierarchischen, industriellen
Führungsstils begründet: Befehl Ausführung Rückmeldung Kon-
trolle. In der Softwareentwicklung ist das phasenorientierte V-
Modell XP vorherrschendes Modell, welches allerdings stark unter
Druck geraten ist. Diese schwergewichtigen Software Entwick-
lungsprozesse, wie auch dem Wasserfall-Modell, dem alten V-Mod-
ell, oder dem Spiralmodell, konzentrieren sich sehr stark auf den
einmaligen Durchlauf der Phasen Analyse, Design, Implementierung,
Test und Auslieferung. Dies deutet darauf hin, dass die softwa-
reerstellende Industrie in ihrem Denken mehr den Projektgedanken
als dem Produktgedanken behaftet ist. Auch der Gedanke, daß Soft-
ware - Wartung nach der Fertigstellung erst beginnt, ist fehler-
haft, man könnte den Prozess der Softwarewartung bereits nach der
Fertigstellung der minimalen Basisversion der Software ansetzen.
Die Prozesse der Softwarentwicklung sind untrennbar mit dem
Prozess der Wartung verbunden. Warum der Glaube an das V-Modell
vorherrschend ist, obwohl in diesem die sich ständig verändernden
Anforderungen an die Software nicht berücksichtigt sind, ist mir
ein Rätsel. Der beste Prozess wiegt einen chaotischen Haufen von
Anfängern, die kein professionelles Team bilden, nicht auf, wie
die Open-Source Szene eindrucksvoll zeigt. Da professionelle
Teams einen sehr hohen Grad an Selbstorganisation aufweisen, ist
eine kleine Zahl an Methoden ausreichend. Zwölf auf einer Seite
definierte Methoden bringen mehr als tausend Seiten An-
forderungsprofile an die Software-Eigenschaften der beiden vor-
angegangen Jahrzehnten, die eh nur von wenigen Experten
überblickt und verstanden wurden. Man verabschiedet sich immer
mehr von der Vorstellung, dass einheitliche wiederholbare
Prozesse und detailliert planbare Projekte möglich sind. Auch die
Vorstellung, durch klare Anweisungen und Kontrolle ein Projekt
steuern zu können, schwindet, da die Erfahrung zeigt, daß
kreative Prozesse sich nur schlecht befehlen und kontrollieren
lassen. Wichtig ist es, ein Team mit kompetenten Mitgliedern zu
haben! Man findet die Spezifikationen des V-Modells hier:
http://www.kbst.bund.de/doc,-307632/V-Modell-XT-Dokumentation.htm
Beim Durchlesen kommt einem der Gedanke, daß hierbei Abteilungs-
und Schubladendenken sowie der Projektgedanke vorherrschend ist,
weit und breit kein prozessuales Denken, sprich emergente
Prozesse in Sicht. Hierbei schaffen sich Bürokraten (Häuptlinge)
erst ihre Existenzberechtigung, indem sie mit dem V-Modell XP
äußerst aufwändige Vorarbeiten vorschreiben, die eh allesamt für
die Katze sind, weil sich die Anforderungsprofile im Laufe der
Softwareentwicklung erfahrungsgemäß noch gewaltig ändern. Nicht
aufwändige Beschreibungen der Anforderungsprofile sorgen für gute
Software, sondern nur wenige Handvoll einfacher Regeln führen zu
sog. emergenten Prozessen, wie das Beispiel der Kontrollprozesse
im Restaurant und das HTTPS-Protokoll zeigt. Äußerst wichtig bei
Agiler Softwareentwicklung sind die sog. Metaprozesse, z.B. das
bewußte und disziplinerte Reflektieren über die Prozesse selber
gehört dazu. Keine Regel ist unveränderbar, alles darf umgestal-
tet werden. Dieser Maxime folgt auch eXtreme Programming (XP).
Ein weiteres Beispiel für den kybernetischen Regeln folgende,
emergente Softwareentwicklung ist Adaptive Software Development
(ASD) . Jim Highsmith hat sich für seinen Prozess Anregungen aus
dem Bereich der Biologie bei komplexen adaptiven Systemen geholt,
genauer bei Umberto Maturana und seiner Erfindung Autopoiese,
siehe Baum der Erkenntnis Unter autopoietischen Systemen versteht
man ein Zusammenspiel von Agenten, die mittels einfachen Regeln
kommunizieren. Das dabei entstehende, emergente Verhalten zeigt
folgende Eigenschaft: Einfache Regeln, gepaart mit komplexen
Beziehungen, führen zu erfolgreichen Ergebnissen, während kom-
plexe Regeln, gepaart mit wenigen Beziehungen, zum Scheitern
führt. Zum weiteren Verständnigs der dynamischen Wechselwirkungen
innerhalb von großen Netzwerken, siehe hierzu auch
http://www.little-idiot.de/teambuilding/GesetzeNetzwerke.pdf .
Bei der Entwicklung von Software betrachtet man nun Teammit-
glieder, Auftraggeber und Organisationen als Agenten. Die Regeln
für die Zusammenarbeit bildet dabei das Softwareentwicklungsver-
fahren. Somit entspricht ein Projekt einem komplexen System. Jim
Highsmith hat folgendes Regelwerk erstellt: 1.Entwicklungsteam
und Kunde starten gemeinsam mit dem Entwurf einer Vision 2.Team
versucht innerhalb von vier Wochen mglichst viele Punkte der Pri-
oritätenliste des Kunden zu erfüllen. Am Ende der vierwöchigen
Iteration erhält das Team Feedback vom Kunden. 3.Während der It-
eration wird dem Team vertraut - wenn der Plan nicht erfüllt wer-
den konnte, geht man von einer Fehlplanung aus 4.Am Itera-
tionsende überprüft das Team seine Leistung und verbessert den
Prozeß. 5.Team plant nächste Iterationsrunde aufgrund vorange-
gangener Erfahrungen. 6.Management unterstützt das Team auf
allen Ebenen. 7.Man überlässt die Auswahl der Arbeitstechniken
dem Team. Diese kleine Anzahl von Regeln führt zu äußerst flexi-
blen Projekten. Der ASD Lebenszyklus ist eine kurze Abfolge aus
Spekulation, Kollaboration und Lernen. Worin liegt hier die
Emergenz? Diese Vorgehensweise sorgt dafür, daß z.B. vom Kunden
im Laufe der Projektentwicklung gewünschten, besonderen Features,
welche nicht elementar notwendig, und gleichzeitig komplex zu im-
plementieren sind, also das Produkt unnötig verteuern würden, au-
tomatisch wegfallen. Kunde und Team können somit nach ein-
facheren, preiswerteren Alternativen suchen. Oftmals wird ver-
sucht, umständliche Prozesse der Verwaltung in der Software abzu-
bilden. Analysiert man diese Prozessketten, bzw. deren mögliche
Implementierung in die Software, so stellt sich oft heraus, daß
hier in der Verwaltung durchaus noch einige Prozessketten ges-
trafft werden könnten, weswegen sich dann deren Implementierung
in Software erübrigt. Prozessuales Denken soll über Abteilungs-
und Schubladendenken herrschen, nicht umgekehrt. 95% der im V-
Modell XP enthaltenen Prüfspezifikationen, Berichte, u.s.w.
könnten ersatzlos entfallen, das Projekt würde erheblich billiger
werden, man kommt mit weniger Planung, Vorbereitung aus. Was
dringend elementar benötigt wird, muß eh fertiggestellt werden,
egal zu welchen Kosten. Es macht auch daher keinen Sinn, 30% der
Gesamtkosten für überflüssige Planung bei sich ständig verändern-
den Anforderungen und Prozessmanagement aufzuwenden. Je nach Pro-
jektgröße schätzt man zwischen 15%-5% der Gesamtkosten für das
Projektmanagement, leider wird nicht mitgerechnet, daß inzwischen
auch die Programmierer mit erheblichem Verwaltungsblödsinn von
ihrer Arbeit abgehalten werden. Hier sei ein sehr wertvolles Ex-
periment erwähnt Distrust The hidden cost of control von Armin
Falk und Michael Kosfeld, siehe http://www.little-idiot.de/team-
building/TheHiddenCostOfControl.pdf Scrum ist ein weiterer, dem
ASD verwandter, emergenter Prozess. Ken Schwaber und Jeff Suther-
land holten sich für ihren Prozess Anregungen aus dem Bereich
Verfahrenstechnik (Process Engineering). Die Idee ist, daß man
zwischen wiederholbaren und empirischen Prozessen unterscheidet.
Wiederholbare Prozesse sind solche, die vollständig verstanden
sind, und deren Anwendung erfahrungsgemäß zu akzeptablen Ergeb-
nissen führen, wohingegen empirische Prozesse chaotisch, sehr
komplex, also nicht steuerbar sind. Das Hauptargument von
Schwaber und Sutherland hierfür ist, daß Softwareentwicklung kein
streng wiederholbarer Prozeß ist, da die Endprodukte immer ver-
schieden sind. Empirische Prozesse müssen fortlaufend überwacht
und angepasst werden, um das erwünschte, emergente Verhalten zu
erzielen. Zur Steuerung ihres Prozesses verwenden sie den Produk-
trückstand, womit die offenen Punkte der Prioritätenliste gemeint
sind. Alle 30 Tage setzen sich Auftraggeber und Team zusammen und
entscheiden, welche Punkte der Prioritätenliste in den folgenden
30 Tagen abgearbeitet werden soll. Das Team versucht nun, in
diesen 30 Tagen, die als Sprint bezeichnet werden, möglichst alle
Aufgaben zu erfüllen. Aufgaben die nicht erfüllt werden konnten,
bilden den Sprint Rückstand. Während des Sprints kann das Team
völlig unabhängig und ungestört arbeiten. Gegen Ende des Sprints
erfolgt ein Sprint Review, wobei die nicht erfüllten Aufgaben
wieder auf den Produktrückstand wandern. Nach einem Kaf-
feekränzchen, bei welchem Feedback und Erfahrungen ausgetauscht
werden, beginnt wieder alles von vorne. Das Team hält täglich,
immer zur gleichen Zeit, das sogenannte Scrum Meeting ab. Die
groben Richtlinien für Scrum Meetings sind folgende: 1.Kurze
Dauer von 15-30 Minuten 2.Was hat jeder seit dem letzten Meeting
getan? 3.Was wird man bis zum nächsten Meeting tun? 4.Was hat
bei der Arbeit behindert? 5.Lösungen werden nicht während eines
Scrum Meeting gesucht oder diskutiert 6.Zu offenen Fragen werden
kleine Teams gebildet, diese arbeiten nach Abschluss des Scrum
Meetings weiter. 7.Scrum Meetings sind der Pulsschlag des Pro-
jektes 30 Tage hat der Auftraggeber die Möglichkeit, sich neue
Anforderungen zu überlegen, die dann Teil des neuen Produktrück-
standes werden. Der Vorteil dieses Prozesses ist, dass das Team
30 Tage ungestört arbeiten kann. Die Durchführung der Aufgaben
ist Teamsache, somit ist Scrum ein reiner Metaprozess. Scrum
enthält keine Richtlinien für Programmierung. Worin liegt hier
die Emergenz? Scrum dient ausschließlich der Teambildung. Jeder
erfährt, woran der andere arbeitet, was seine Probleme sind, und
fühlt in den Meetings die Stimmung seiner Kollegen. Man beginnt
sich für die Arbeit des anderen zu interessieren, nimmt Anteil,
sucht und gibt Ratschläge Teambuilding. Scrum kann als psycholo-
gische Vorbereitung zu Pair Programming verwendet werden, ein As-
pekt des eXtreme Programming (XP).

Vollständige Entwicklungsprozesse eXtreme Programming, entwickelt
von Kent Beck , Martin Fowler, Ward Cunningham und Ron Jeffries
ist voll von emergenten Prozessen, welche differenzierte Methoden
für die vier sich bis zur endgültigen Fertigstellung der Software
ständig schnell wiederholenden, Entwicklungs-Zyklen (Interatio-
nen) darstellen: 1. Planung, 2. Design, 3. Programmierung, 4.
Test, 1. Planung, 2. Design .... Dieses etwas merkwürdige,
scheinbar uneffektive und aufwändige Prozedere begründet sich aus
der Praxiserfahrung heraus: Ein Programmierer trägt täglich nur
wenige, dauerhaft und korrekt geschriebene Codezeilen bei. Nicht
selten beträgt die Produktivität eines Programmierers gemittelt
nur ganz 5! Codezeilen je Arbeitstag. Nichts ist beständiger, als
die Veränderung - XP ist ein bewußter Prozess von Experimentieren
und ständiger Verbesserung des Codes, wobei XP bewährte Methoden
liefert, daß automatisch gute Software automatisch entsteht.
Während in vielen Programmierer - Teams der innige Wunsch nach
fehlerfreier, perfekter Software gepflegt wird, oder wie ein
Damokles-Schwert über den Köpfen der Programmierer hängt, so
berücksichtigt XP direkt von Anfang an, daß nichts und niemand
perfekt ist, und Perfektion nur durch einen kontinuierlichen
Verbesserungsprozess (KVP) entstehen kann. Diese neue Denke, bzw.
das Bewußtsein in ein Team hinein zu tragen, ist ebenfalls ein
Prozeß, der nicht von heute auf morgen passiert. Übrigends ist XP
exakt die Implementierung / Umsetzung von KAIZEN, einem bei in
Japan erfundenem "KVP" (Kontinuierlicher Verbesserungs -
Prozess), der zur Sicherung der Qualität im Fertigungsprozess und
zur Optimierung der Fertigungs und Managementkosten (lean produc-
tion, lean management, lean thinking) in der japanischen Autoin-
dustrie, aber auch bei Boeing und bei Porsche angewendet wird.
Mehr hierzu siehe http://www.little-idiot.de/teambuild-
ing/KaizenI.pdf . Der Begriff TQM (Total Quality Management, To-
tal=Allumfassend), in Japan geprägt, ist ein umfassendes Konzept,
welches sich z.B. auch in der DIN/ISO Norm 8402 wiederfindet. XP
ist ein sehr raffiniertes Kaizen - Konzept, wobei jeder Punkt in
den 4 verschiedenen Phasen, die zyklisch immer wieder durchlaufen
werden, einen tieferen Hintersinn hat, also implizite Logiken
enthält, die nicht direkt durchschaubar sind, weil die Effekte
erst in der Dynamik sichtbar werden. Es ist für einen Teammit-
glied nur schwer zu verstehen, daß Prozesse, bei welchem jedes
Teammitglied individuelle Nachteile hat, diese für das Team ins-
gesamt jedoch von Vorteil sind. (emergente Effekte in kursiv...)
1. Planungsphase: User - Stories: Der Anwender beschreibt,
basierend auf dem aktuellsten Zwischenrelease die Dinge, die er
weiterhin benötigt, skizziert (anfangs laienhaft) ggf. weitere
Arbeitsabläufe, ein verändertes Benutzer - Interface und sonstige
Ideen frei auf Papier. Diese dienen immer wieder der weiteren Ab-
schätzung des Projekt - Umfanges, und der Festsetzung der weit-
eren Entwicklungs-Zyklen. Während der Implementierungsphase
verändern sich stets die ursprünglichen Anforderungen, fehler-
hafte Prozesse, oder Prozessketten, die gestrafft werden können,
werden folglich auch nicht in Software übertragen. Die Entwick-
lungs-Zyklen sind stets so kurz wie möglich zu halten. Software -
Releases werden mit ihren Eigenschaften immer wieder aufs Neue
beschrieben und dies wird auch schriftlich festgelegt. Heraklit
von Ephesos: Nichts ist beständiger, als die Veränderung Die
Geschwindigkeit der Projektentwicklung wird in jedem Entwick-
lungs-Zyklus erneut abgeschätzt. Hierbei fällt direkt auf, welche
gewünschten, evtl. überflüssigen oder anders zu lösenden Features
die Softwareentwicklung unnötig verteuern würden. Die Entwick-
lungszyklen werden alle 1-3 Wochen, aufgrund der sich ständig
ändernden Anforderungen und Kundenwünsche, wieder und wieder
erneut definiert. Die Anforderungen verändern sich ständig, da
der Kunde seine eigenen Prozesse im Unternehmen/Organisation
während der Implementierung besser kennenlernt und parallel mit
optimiert. Die Planung der Entwicklungs-Zyklen findet immer
wieder erneut statt. Hierbei werden ca. 15-20% der Gesamtzeit der
Zyklen auf deren Planung verwendet. "Unit testing" und "Refactor-
ing" werden ebenfalls mit eingeplant. Die Qualität steht bei XP
an alleroberster Stelle, je weniger Quellcode dabei entsteht,
desto einfacher die Fehlerbeseitigung. Refactoring ist fester Be-
standteil dieses Prozesses, Programmierer sind ständig damit
beschäftigt, Code kürzer, effizienter und lesbarer zu gestalten.
Programmierer werden ständig getauscht (Rotationsprinzip). Dies
verhindert einen häufig auftretenden Effekt, daß aufgrund des
Ausfalles einer Person im Team die gesamte Entwicklung zum Still-
stand kommt. Dies trifft insbesondere auf Projekte mit hoher Kom-
plexität und starker Koppelung der Module zu. Jeder kennt sich
dann mit jedem Teil der Software aus und kann ggf. einspringen.
Ggf. sollte Pair Programming eingesetzt werden, womit dann keine
Verzögerungen bei Ausfällen mehr auftreten. Programmierer können
flexibel dann dort eingesetzt werden, wo es am meisten brennt.
Höchste Priorität hat daher immer die Vermeidung von Wissens-In-
seln im Team. Gerade an diesem Punkt gibt es die größten Wider-
stände, weil - jeder möchte sich unentbehrlich machen - aus Angst
vor Jobverlust. Das Gegenteil jedoch ist der Fall: Wer die
Denkweise von XP verinnerlicht hat, passt in jedes neue Program-
mierer-Team ... findet also immer einen Job. Auf flexible und er-
fahrene Programmierer mag und kann eh niemand verzichten.
Tägliche, kurze Meetings zum Arbeitsbeginn vermeiden längere
Teamsitzungen bei Problemen. Die täglichen Aufgaben werden zuge-
ordnet, Arbeitskapazitäten neu aufgeteilt. Hierbei kann es
passieren, daß Programmierer die Arbeit ihres Kollegen fortsetzen
müssen. Dies ist nur möglich, wenn sich jeder Programmierer im
Gesamtquellcode genau auskennt. Bei Teamgrößen von bis zu 20-30
Programmieren ist dies noch machbar. XP - Regeln dürfen bei
Auftreten von Problemen gebrochen werden. XP ist kein fest-
gelegtes Prozedere, sondern darf, den Anforderungen und den
Umständen entsprechend wohl begründet, abgeändert werden. Die
ständige Reflektion im Team darüber, ob entsprechend der Team-
größe oder Eigenschaften bestimmte Regeln noch sinnvoll sind,
oder vorübergehend aufgehoben oder abgeändert werden, ist eben-
falls emergent. Heraklit von Ephesos: Panta Rhei! - Alles fließt!
2. Designphase: Einfachheit, KISS - Prinzip (Keep It Simple,
Stupid!). Alles und jedes muß einfach durchschaubar sein, gut
dokumentiert, dort, wo nötig. Der Hauptaspekt liegt stets auf der
Austauschbarkeit des Programmierers. Jeder Programmierer muß sich
sofort in der Arbeit eines anderen zurechtfinden können, und nach
kurzer Einarbeitungszeit produktiv mitwirken können. Namen - das
Schaffen von Bezeichnern für Code - Abschnitte oder Program-
men/Unterprogrammen erleichtert die Kommunikation im Team. CRC -
Karten (Class, Responsibilities, Collaboration) dienen dem Design
des Systems als Team. Hier sitzen alle Programmierer in einer
Runde und halten Karten in der Hand (einer bedient die Mindmap
Software am Beamer, siehe Data Beckers MindManager, 49 Euro!,
DoxyGen geht aber auch). Jede Karte repräsentiert ein Objekt mit
Abhängigkeiten, zu anderen Klassen. Hierbei beginnt jemand in der
Gruppe von Programmierern über seine Klassen und Abhängigkeiten
zu reden, welches Objekt welche Nachrichten wohin sendet, u.s.w.
Je mehr Personen bei diesem Prozess anwesend sind, umso besser.
Existieren zuviele Karten und Klassen, so wird die Zahl auf
wenige je Person begrenzt. Hierbei werden in kurzer Zeit durch
das gemeinschaftliche Denken Schwächen im Design entdeckt und ko-
rrigiert. Bei technischen oder Design - Problemen programmiere
ein einfaches Programm, welches das Problem unter Nichtberück-
sichtigung aller anderen Probleme löst. Da es nur Testzwecken di-
ent, wird es später eh weggeworfen. Das Ziel dieses Vorgehens ist
es, das Risiko eines Fehldesigns zu reduzieren, und die Zu-
verlässigkeit der User - Story zu erhöhen. Wenn das Problem evtl.
die Gesamtentwicklung verlangsamen könnte, so sollte Pair Pro-
gramming eingesetzt werden, wobei zwei separate Entwickler sich
eine oder zwei Wochen nur dieses Problems annehmen. Füge niemals
unnötig Funktionalität hinzu. Wir kennen alle das Problem, der
Versuchung zu widerstehen, Dinge hinzuzufügen, weil sie das Sys-
tem verbessern würden. Wir müssen uns hierbei dauernd daran erin-
nern, bzw. selber disziplinieren, nichts zu programmieren, was
nicht unbedingt benötigt wird. Wenn nur ca. 10% allen Codes bei
XP tatsächlich überlebt, so verschwendet man 90% der Arbeitszeit.
Man spart umso mehr Entwicklungszeit ein, je weniger Code für die
Lösung der Aufgabe benötigt wird. Das höchste Prinzip, welches
hier gilt, sind die "Number of Lines Not Written". Im Design je-
doch berücksichtige stets die Möglichkeit, diese Funktionalitäten
später hinzufügen zu *können*. Konzentriere Dich auf die mor-
gendlichen Besprechungen und dein Tagespensum. Refactoring, also
der Prozess der dauernden Verbesserung der Code-Struktur muß im-
mer höchste Priorität haben. Code muß einfach in seiner Struktur
sein, leicht zu verstehen, zu modifizieren, und zu erweitern. Re-
dundanzen sind aufzulösen, überflüssige Funktionen zu elim-
inieren, evtl. verworfene Designs können wieder verwendet werden.
Jede Funktionalität darf nur einmal im Code vorkommen, doppelte
oder ähnliche Funktionalitäten in ähnlichem Code werden zusam-
mengefasst. Der Abschied von seinem eigenen, bevorzugten Design
zugunsten des aus Gründen der Praktikabilität durch Refactoring
entstandenen, gemeinschaftlich entwickelten Designs fällt immer
schwer. Manchmal muß man halt einsehen, daß das Ursprungsdesign
ein guter Beginn war, aber nun obsolet ist. 3. Programmieren,
codieren: Der Kunde ist immer anwesend - elementarer Bestandteil
des XP ist - er ist für die User - Stories verantwortlich, mit
welcher die GUI ständig angepasst und verbessert wird - Er allein
bestimmt das Aussehen und die Funktionalität der Software. Auf-
grund der User Stories wird auch in jedem Entwicklungs-Zyklus im-
mer wieder der Zeit-und Kostenrahmen erneut abgeschätzt. Dies ist
insbesondere wichtig, wenn der Kunde neue Funktionalitäten
einführen will, dereren Notwendigkeit sich erst im Laufe des Pro-
jektes ergeben. Er bestimmt, wie das nächste, funktionierende Re-
lease aussehen soll. Er ist auch der einzige, der über Details
Auskunft geben kann, die vergessen oder übersehen wurden.
Desweiteren wird der Kunde immer bei Funktionalitätstests und
Unit-Tests benötigt. Interessant hierbei ist auch, daß direkt
erkennbar ist, was Sonderwünsche kosten, und ob hierbei evtl. ein
scheinbar "winziges" Feature so aufwändig ist, daß der Etat
gesprengt wird. Es gibt für jede Programmiersprache im Internet
sog. "Styleguides", die festlegen, was wie bezeichnet wird, z.B.
Pointer..., wie Code formatiert wird, sodaß die Lesbarkeit im
Team erleichtert wird. Ziel ist es ja, daß jeder leicht den Code
aller im Team lesen und verstehen kann, die Einarbeitungszeit
gering wird. Refactoring muß erleichtert werden. Unter dem Stich-
wort "best practice patterns" finden sich sog. bewährte "Design
Patterns", die viel überflüssige Restrukturierung während der En-
twicklungsphase vermeiden. Unit Tests - Bevor auch nur eine
einzige Zeile Code geschrieben wird, ist es unter XP Pflicht,
zuerst eine Testroutine zu schreiben, die genau die Erwartung an
ein Programm überprüft. Unit Tests für einfache Funktionen,
Prozeduren oder Klassen zu schreiben, ist recht einfach.
Schwieriger ist dies schon für Datenbankanwendungen, da Test-
datensätze definiert werden müssen, noch schwieriger für GUIs mit
Ein-und Ausgabe sowie Benutzerinteraktion. Die Ursprungsidee ein-
er Qualitätssicherung hat jedoch noch mehrere positive Nebenef-
fekte. Sie hilft dem Programmierer, sich bei dem Schreiben des
Codes für die Unit sich nur auf das Wesentliche zu konzentrieren,
sodaß nur so wenig Code geschrieben wird, wie benötigt wird,
damit der Test erfüllt ist. Andererseits zeigt es anderen Team-
mitgliedern, wie eine Funktion, Prozedur oder Klasse verwendet
wird, bzw. wofür diese da ist, ähnlich einem kleinen Programmier-
beispiel oder Tutorial, wie man es aus dem Internet kennt. Pair
Programming - Jeder Code, der in ein Zwischenrelease oder
endgültiges Release (production release) einfließt, wird von zwei
Programmierern programmiert, die gemeinsam vor einem Computer
sitzen und wechselweise programmieren. Dies ist zu Beginn sehr
gewöhnungsbedürftig, jedoch ist das Programmieren überhaupt ein
schöpferischer Prozess, in welchem jeder stets seine Ruhepausen
zum Nachdenken benötigt. Die Zeit des Nachdenkens darüber, wie
nun etwas kodiert wird, sind oft viel länger, als die eigentliche
Eingabe. So ähnlich, wie man während eines Gespräches Wortfind-
ungsprobleme hat, hat jeder während des Programmierens auch mal
ein "Brett vor dem Kopf". Derjenige, der dem anderen zuschaut,
ist erst einmal aus der Verantwortung, kann dem Partner entspannt
zuschauen, und sich dabei stressfrei auf den Code konzentrieren,
der gerade geschrieben wird. Das Resultat ist, daß die Code-
qualität sehr viel besser wird, und im Endeffekt viel weniger
Refactoring stattfinden muß. Es hat sich herausgestellt, daß Pair
- Programming im Endeffekt die Kosten nicht erhöht. Integration
von Code - der Reihe nach, niemals parallel. Das unter sequential
integration bekannte Einflechten von Code-Fragmenten in den
entgültigen Code (production code) sollte nur wenigen Mitgliedern
im Team der Programmierer vorbehalten sein. Gerade dann, wenn von
mehreren Entwicklern Code integriert werden soll, stellt man
gewöhnlich fest, daß Code - Abhängigkeiten zu veralteten oder
überflüssigen Codefragmenten existieren. Die Ursache liegt darin,
daß alle Entwickler ja stets nie die neueste Codebasis kennen
können, für welche sie Routinen entwickeln. Die hohe Abhängigkeit
von Code untereinander, gerade in der frühen Phase der Entwick-
lung, macht die Sache sehr aufwändig. Je besser die Planung von
Anfang an ist, je weniger Änderungen in der Struktur des Codes
später stattfinden müssen, umso geringer ist die Wahrschein-
lichkeit, daß Code verworfen werden muß, und mit ihm der davon
abhängige Code. Schlechte Planung, Organisation und vor allem
schlechtes Software - Design führen dazu, daß oft, obwohl die
Zahl der Programmierer vergrößert wird, die Entwickung noch mehr
stagniert. Änderungen an Klassen, von denen viele andere Klassen
abhängig sind, sind z.B. sehr aufwändig. Dies kann die Program-
mierleistung des Teams insgesamt dramatisch verschlechtern.
Häufige Integration und schnelle Veröffentlichung im Team sind
daher enorm wichtig. Definitionen von Schnittstellen zwischen
Klassen und Reduktion der Codeabhängigkeit durch Schaffung von
möglichst vielen, unabhängigen Modulen hat ebenfalls höchste Pri-
orität. Das gesamte Konzept von J2EE / JBOSS basiert auf dieser
Erkenntnis. Gemeinsame Eignerschaft am Code (collective code
ownership) bedeutet, daß jeder Programmierer zu jeder Zeit Code
anderer Team-Mitglieder korrigieren, verändern, erweitern oder
bereinigen darf. Nur so wird verhindert, daß eine Einzelperson zu
einer Art Nadelöhr für Veränderungen wird. Oft ist es so, daß
eine kleine Verbesserung am Code eines anderen Team-Mitgliedes
aufwändige Programmierung eines "Workarounds" im eigenen Code
einspart. Es gibt daher bei XP keinen Chef-Designer. Kein Mensch
kann bei hochkomplexen Projekten alle Details im Kopf behalten.
Außerdem, wenn das Team insgesamt für das Gesamtdesign des Codes
verantwortlich ist, sollte jedes Mitglied auch das Recht haben,
an jeder Stelle im Code Veränderungen oder Verbesserungen
vorzunehmen. Höchste Instanz sind eh die Unit - Tests. Code, der
diese Tests nicht erfolgreich durchläuft, darf eh nicht im pro-
duction code eingeflochten werden. Umfangreiche Änderungen am De-
sign erfordern automatisch Änderungen in den Test - Units, und
man kann recht schnell entdecken, welche anderen Codefragmente
plötzlich Test - Units nicht mehr bestehen. Da jeder im Team sich
im Code anderer Team - Mitglieder auskennt, fällt auch das Auss-
cheiden eines Teammitgliedes kaum negativ auf. Daß jemand anderes
in dem eigenen Code "herumpfuschen" darf, ist zunächst jedem Pro-
grammierer höchst zuwieder. Einerseits macht es auch Spaß, einem
Kollegen "mal eben" zu zeigen, wie es einfacher oder effektiver
geht, und andererseits lernt man selber ja sehr viel dazu. Gerade
junge Kollegen sollten diese Art von "Belehrungen" als fre-
undliche Geste auffassen, und sich für die Mühe ihres Kollegen
bedanken - "nobody is perfect!". Es wird die Zeit kommen, wo man
auch einem "alten Hasen" mal neue Dinge zeigen kann ;-) So kommt
auch Spaß am Lernen und somit viel Dynamik in die Bude. Oft wird
auf große Unterschiede bei der Fachkenntnis oder im Niveau der
Programmierer im Team hingewiesen. Diese Wahrnehmung mag ja dur-
chaus korrekt sein, jedoch ist hierbei zu bedenken, daß nicht
jeder Mensch das große Glück hatte, gute Lehrer gehabt zu haben.
Das, was wir sind, unsere Persönlichkeit, unsere Fähigkeiten
haben wir nicht schon von Geburt an, sondern wir sind die Summe
aller Einflüsse der Eltern, Familie und auch, ab dem Kindesalter
beginnend, fremder Menschen in unserem Leben. Unsere Identität -
auch Selbstbewußtsein genannt - ist die Summe aller Erfahrungen
im Leben. Leider leben wir in einem Land, in welchem in preußis-
cher Tradition Streitkultur und Demütigungskultur gepflegt wurde.
In China hingegen herrscht z.B. eine "Konsenskultur", mehr hierzu
siehe auch http://www.little-idiot.de/teambuilding/DualistischAm-
bivalentDialektisch.pdf http://www.little-idiot.de/teambuild-
ing/VonChinaLernen.pdf Durch die Anwendung von Pair-Programming
und ständig neue Paarungen im Team lernen alle in sehr kurzer
Zeit noch sehr viel hinzu, sodaß bald ein einheitliches Niveau im
Team erreicht ist, wovon alle im Team profitieren, nicht nur
fachlich, sondern insbesondere auch emotional. Unerfahrene Pro-
grammierer lernen dabei hauptsächlich Fachkenntnisse, die er-
fahrenen Programmierer lernen, wie man komplizierte Dinge mit
einfachen Worten erkärt. Dies ist eine sehr hohe Kunst und stets
eine Herausforderung auch für absolute Cracks. Die menschliche
Biochemie ist so gestaltet, daß sowohl neue Erkenntnisse im Ver-
stehen einer Tatsache, als auch das erfolgreiche Vermitteln mit
Endorphin - Ausschüttung, also Glücksgefühlen "belohnt" wird. Die
Arbeit macht dann allen im Team sehr viel mehr Spaß, neue Poten-
tiale werden entdeckt und freigesetzt. Hierbei kann jeder an sich
selber beobachten, wie er an seinen Aufgaben im Team nicht nur
fachlich, sondern auch von seinen persönlichen, menschlichen
Qualitäten wächst. Dies gibt Freude im Leben, schafft Begeis-
terung, die ansteckend ist. Optimiere niemals während der En-
twicklungsphase. Erst muß Code funktionsfähig sein, später dann
können Nadelöhre beseitigt werden. Versuche niemals, zu erraten,
wie groß die Verbesserung der Performance sein könnte, sondern
messe sie. Aus der Kybernetik ist bekannt, daß komplexe, dynamis-
che Systeme niemals lineares Verhalten zeigen. Siehe auch die 10
Netzgesetze: http://beat.doebe.li/bibliothek/b00926.html
Überstunden zerstören den Mannschaftsgeist und die Motivation im
Team. Kann ein Termin nicht gehalten werden, so helfen auch keine
Überstunden, oder die Vergrößerung des Teams. Die Ursache liegt
darin, daß Programmiertätigkeit ein schöpferischer Akt ist, und
ein Programmierer sehr viel mehr nachdenkt, als tatsächlich am
Computer Code eingibt. Das Gehirn arbeitet hochgradig parallel,
es denkt sogar im Schlaf weiter über Probleme nach. Nicht selten
kennen wir Menschen die Lösung erst, nachdem wir eine Nacht
drüber geschlafen haben. "Operative Hektik ersetzt geistige Wind-
stille" - dieser Spruch besagt, daß man durch Verbreitung von Un-
ruhe im Team die Entwicklung insgesamt nicht beschleunigt, weil
die Zahl der Fehler sich stark erhöht. Fehlersuche ist aber sehr
viel aufwändiger und anstrengender, als wenn man Zeit und Ruhe
hat, vorher genauer nachzudenken, und dann fehlerfrei codiert.
Jeder Fehler potenziert sich aufgrund der hohen Abhängigkeiten im
Code, gerade in großen Teams. Stattdessen korrigiert man bei den
release planning meetings die Zielvorgaben, indem man sehr
aufwändige Teile vereinfacht oder wegfallen läßt. XP ist so
konzipiert, daß ständig Planung, Design, Codieren und Testen in
kleinen Entwicklungs-Zyklen interativ im Wechsel stattfindet. Hi-
erdurch werden frühzeitig unrealistische Ziele erkannt und kor-
rigiert, oder es werden andere Wege gefunden. Oft nämlich ist es
einfacher, Arbeitsabläufe zu verändern, als umfangreich Software
anzupassen. 4. Testphase: Jede Implementierung von Code wird
durch Unit Tests geprüft. (Eigentlich ist Unit Testing eine Un-
termenge des "Test Driven Development = TDD). XP ist extrem
abhängig von Unit - Tests. Es gibt für verschiedenste Program-
miersprachen ein sog. "unit test framework", mit welchem man au-
tomatisierte Test Suites generieren kann. Code, der die Tests
nicht erfolgreich durchlaufen hat, darf grundsätzlich nicht ver-
wendet werden. Fehlt ein Test, so ist dieser unverzüglich zu er-
stellen. Der größte Widerstand gegen saubere Erstellung von Unit
Tests ist stets gegen Ende der Entwicklung, kurz vor der Fertig-
stellung. Hier zu schlampen, wäre ein elementarer Fehler. Ohne
vollständige Unit Tests dauert die Fehlersuche oft 100x so lange,
wie sie eigentlich müßte, und außerdem muß die Software nach fer-
tigstellung des ersten Release ja auch weiter gewartet werden. UT
zahlen sich immer aus, und zwar vielfach gegenüber dem
Mehraufwand der Erstellung. Debugger finden nur einfache Program-
mierfehler, aber keine Logikfehler in den Abläufen bzw. dem
Zusammenspiel der Klassen/Objekte. Unit Tests aber prüfen genau
dieses Zusammenspiel. Je härter es ist, einen Unit Test zu
schreiben, umso mehr wird er auch tatsächlich benötigt, und umso
größer wird die Zeitersparnis bei evtl. Fehlersuche sein.. Unit
Tests sind noch wichtiger beim Refactoring. Nur so kann
sichergestellt werden, daß Änderungen in der Code - Struktur
zwecks Lesbarkeit und Wiederverwendbarkeit keine Änderungen in
der Funktionalität bewirkt haben. Das frühzeitige Korrigieren von
kleinen Fehlern in kurzen Intervallen spart viel mehr Zeit ein,
als die Korrektur vieler Fehler kurz vor der Fertigstellung.
Fehler potenzieren sich im Code, ebenso, wie der Aufwand ihrer
Korrektur. Wird ein Fehler entdeckt, so muß ein Test sicher-
stellen, daß dieser nicht noch einmal passiert. Der Unit Test muß
dementsprechend angepasst werden. Akzeptanz - Tests (AT, früher
Funktionalitäts - Tests genannt) sind das zweite Standbein von
XP. Dies werden aus den user stories heraus geschaffen. Der Kunde
beschreibt Szenarios, wie getestet werden soll, damit
sichergestellt ist, daß die Funktionalität und Bedienbarkeit
genau so ist, wie gewünscht. Jeder AT repräsentiert ein er-
wartetes Verhalten vom System. Der Kunde ist verantwortlich für
Erstellung, Überprüfung und Einhaltung der Anforderungen an das
System. Sobald mehrere Akzeptanz - Tests nicht erfolgreich been-
det wurden, muß entschieden werden, welcher Tests hohe, und
welche niedrige Priorität haben. Eine user story filt als nicht
vollständig, wenn diese nicht alle Akzeptanz - Tests bestanden
hat. das bedeutet, daß neue Akzeptanz - Tests geschrieben werden
müssen, sobald bei einem Entwicklungs - Zyklus kein Fortschritt
erzielt wurde. Qualitätssicherung (QA) ist ein wesentlicher Teil
des XP Prozesses. Dieser kann durch eine unabhängige Gruppe
durchgeführt werden, kann aber auch durch Mitglieder des Entwick-
lungsteams durchgeführt werden. Die zweite Lösung reduziert
natürlich stark den Kommunikationsaufwand, weil Fehler nicht erst
analysiert, dann niedergeschrieben und vermittelt werden müssen,
sondern direkter Eingriff im Code das Problem dann egalisieren
kann. Die Ergebnisse der Akzeptanz - Tests werden allen Team -
Mitgliedern regelmäßig bekannt gemacht. Nachdem dies erst einmal
gesackt ist, so ging es mir, habe ich wieder von vorne angefangen
zu lesen, und so langsam dann erst verstanden, wie diese selb-
stkorrigierenden, dynamischen Prozesse eigentlich funktionieren,
welche impliziten Logiken der Wechswirkung der menschlischen Psy-
che und den prozessualen Abläufen hinter jedem einzelnen Punkt
verborgen sind. Häufig wird die Frage nach "Kontrolle,
Überprüfbarkeit" der Leistung gestellt. Hierzu ist zu sagen, daß
allein die Tatsache, in einem solchen "Extreme Programming" Team
mitzuarbeiten, und die Dynamik täglich beobachten zu können, mit
welcher Vehemenz, Intensität, Geschwindigkeit hier programmiert
wird, sehr viel Freude macht, sprich Endorphine freisetzt. Beim
Menschen sorgt allein der Prozess der Erkenntnis für Endorphin-
ausschüttung, siehe das Buch Körpereigene Drogen. Nicht selten
sieht das Großraumbüro, in welchem 1-2 Dutzend Programmierer
wirken, wie ein Schlachtfeld aus, Papier, Diagramme allerorten,
die Relikte intensiver Kommunikation. Durch Pair - Programming
und ständigen Wechsel sind nach wenigen Monaten alle Teammit-
glieder wissensmäßig auf demselben Stand, die Unterschiede in der
Leistung nur noch marginal. Software - Entwicklung im OpenSource
- Bereich, also der Linux Kernel, die GNU Toolkits, allen voran
der GCC C-Compilier, die grafischen Benutzeroberflächen, der
Apache Webserver, tausende von Anwendungswerkzeugen werden alle-
samt nach den Kriterien von XP entwickelt. Ein kleiner Unter-
schied jedoch besteht. Die Unit - Tests werden nicht von Program-
men durchgeführt, sondern die gigantische Anwendergemeinde von
vielen millionen Usern, darunter viele hunderttausende
Neugierige, die sich gerne eine Beta - Version von Linux (Man-
drake Cooker, Debian Testing, ...) herunterladen, führen die
Tests durch und melden, ob und wann ein Modul nicht funktioniert.
Das "Release early" Prinzip der OpenSouce Gemeinde sorgt dafür,
daß frühzeitig Fehler bekannt werden. ZopeX3, z.B. verwendet Unit
Testing. Extreme Programming ist kein Meta-Modell, sondern ein
ganz ausgefuchstes Prozedere, welches voller emergenter Prozesse
ist, die dafür sorgen, daß die typische, innere Reibung durch
Kommunikation und Abstimmungsaufwand überkompensiert wird. Fast
alle Open-Source Projekte werden (nicht vollständig) nach diesem
Modell programmiert. eXtreme Programming versucht auch einen
Paradigmenwechsel herbeizuführen. Je früher ein Fehler im Phasen-
verlauf Analyse, Design, Implementierung, Test entdeckt wird, und
je früher der Fehler im Phasenverlauf gemacht wurde, umso
geringer sind die Fehlerbeseitigungskosten, und umso weniger Code
muß verworfen werden. Dies ist letzendlich, über einen längeren
Zeitraum betrachtet, Emergenz. Es wird viel weniger sinnlos an
Konzepten weiterprogrammiert, die viel später verworfen werden
müssen. Vertreter der Phasenmodelle Wasserfall, V-Modell oder
Spiralmodell versuchten deshalb, Entscheidungen möglichst früh zu
treffen, Analyse und Design möglichst ausführlich und detailliert
zu machen. Das Festhalten an früh getroffenen Entscheidungen
führte bei diesen Modellen zu einem riesigen Berg an Dokumenta-
tion der einzelnen Phasen, die selten mit dem tatsächlichen
Quellcode konsistent war. XP Vertreter versuchen die Kosten der
Fehlerbeseitigung durch ein Bündel an Maßnahmen in den Griff zu
bekommen. Dazu zählen die Praktiken einfaches Design, automa-
tisierte Testfälle und Refaktoring. XP Vertreter wehren sich
nicht gegen Veränderung, sondern nehmen diese offen an. XP
Vertreter sehen den Quellcode als zentrales Produkt und halten
die Dokumentation aus den verschiedenen Phasen gering. Dies re-
duziert auch das Problem mit inkonsistenter Dokumentation. XP
Vertreter behaupten, dass durch das Maßnahmenbündel die Kosten
für Änderungen und Fehlerbeseitigung sich in engen Grenzen hält,
im Vergleich zu allen anderen Softwareentwicklungsmodellen.

Viele der Softwareentwicklungsmodelle sind aus der Automobilin-
dustrie übernommene, bewährte Methoden des Kaizen Optimierungs
Gurus Taiichi Ohno, der das Toyota Production System TPS erfun-
den, und das Unternehmen zu einem der lukrativsten Unternehmen
überhaupt gemacht hat. Sein Motto: Mein Leben ist der ständige
Versuch, gegen den gesunden Menschenverstand anzukämpfen - Sprich
für einen einzelnen Mitarbeiter ist kaum einzusehen, daß
Prozesse, die für ihn selber einen Mehraufwand bedeuten, für das
Team insgesamt sehr viel mehr Effizienz bedeuten.

Zunächst ein Beispiel aus der Automobil - Produktion, welches
hoffentlich die emergenten Prozesse erleuchtet, obwohl dies mit
Softwareproduktion direkt nichts zu tun hat. Die Produktion eines
hochkomplexen Automobils sehr vergleichbar mit der Produktion von
Software, angefangen von Schnittstellen-Definitionen der hun-
derten logischen Einheiten, bis hin zu Baugruppen, die modular
dezentral gefertigt, und auf einem Endmontageband nur noch zusam-
mengesteckt werden müssen. Schaut man sich die Zahlen von z.B. VW
und Porsche an, so fällt auf, daß bei VW jeder Mitarbeiter in
einem Jahr durchschnittlich 15 Auto's baut, Porsche jedoch nur 5
Auto's. Obwohl Porsche 3x soviel Mitarbeiter für ein Auto
benötigt, erwirtschaftet Porsche einen 30x höheren Gewinn je Au-
to. Folge Porsche kauft langsam VW auf 20% der Anteile nun im
Besitz von Porsche. Das kleine Familienunternehmen Toyota hat
letztes Jahr 10 Mrd. Gewinn eingefahren, soviel, wie die Top3
Automobilhersteller zusammen. Renault bietet den Logan handgefer-
tigt aus den Produktionsstätten der tschechischen Firma Dacia,
für einen Neupreis von 5000 an, einem Preis, zu welchem VW mit
Robotern noch nicht einmal einen einfachen Golf produzieren kann.
Die impliziten Logiken völlig neuer Produktionstechniken der Au-
tomobilproduktion sorgen für eine Effizienz, welche beweist, daß
die althergebrachten Denkweisen und Methoden völlig überholt
sind.

Ursache für diese Gewinnexplosion bei Porsche und Toyota war das
TPS (Toyota Production System), welches dafür sorgte, daß alle
Auto's fehlerfrei vom Band liefen. Porsche gelang es erst 1994,
also nach über 60 Jahren Automobilproduktion, den ersten fehler-
frei produzierten Porsche vom Band laufen zu lassen. Bei etwa 100
Arbeitsschritten, jeder zu 99% fehlerfrei ausgeführt, ergibt dies
- bei einer Potenzierung der Fehler - über 60% Ausschuß am Ende
des Bandes, was umfangreiche Nachbesserungsarbeiten zur Folge
hatte. Taiichi Ohno hat hier eine Methode eingeführt, wo jeder
nachfolgende Arbeitsschritt den vorhergehenden auf Fehlerfreiheit
kontrolliert, bzw. diesen korrigiert. Genau diese implizite Logik
der Qualitätskontrolle findet sich in den Methoden des XP (Ex-
treme Programing) wieder, siehe oben, oder auch http://www.lit-
tle-idiot.de/xp/ .

Die Methode des Aufspürens von Fehlern ist in der Software Pro-
duktion als Unit-Test bzw. TDD (Test Driven Development) bekannt.
Bevor nicht alle Module erfolgreich die Tests durchlaufen haben,
darf nicht weiter programmiert werden. Die Parallele zur
Qualitätskontrolle in der Automobilindustrie ist offensichtlich.
Unit Tests erscheinen auf den ersten Blick recht aufwändig, je-
doch werden sie umso dringender benötigt, je komplexer das Pro-
gramm-Modul ist. Weil durch moderne OO Programmierung (Objekt -
Orientierte Programmierung) mit Vererbung, Delegation, Polymor-
phie, Aspektorientierte Programmierung (AP) eine hohe
Abhängigkeit des Codes untereinander (Code Hierarchien) geschaf-
fen wurde, sind elemantare Änderungen an den Basisklassen fatal.
Kleine Änderungen dort ziehen umfangreiche Änderungen an den
abhängigen Klassen nach sich. Vergleicht man dies mit der Kon-
struktion eines Autos, so fällt z.B. bei einem VW-Bulli auf, daß
nur zum Tausch einer einfachen Kupplungsscheibe der komplette Mo-
tor samt Vorderachse ausgebaut werden muß (VR6). Dieses Auto,
z.B., ist aufgrund hoher Abhängigkeiten der Baueinheiten untere-
inander extrem wartungsfeindlich. Übertragen auf Software Pro-
grammierung bedeutet dies, daß der Ehrgeiz der Programmierer,
saubere Klassenhierarchien haben zu wollen, zwar für sauber
aufgeräumten Quellcode sorgt, jedoch Änderungen der Codestruk-
turen grundsätzlich sehr aufwändig sind. Als Beispiel möge hier
die grafische Benutzeroberfläche KDE von Linux dienen, welche
bislang auf QT3 aufgebaut ist. Die Entwickler haben es nicht
geschafft, QT3 sanft zu QT4 zu migrieren, stattdessen haben sie
QT4 von Grund auf neu programmiert und strukturiert.

Refactoring ist insbesondere dann, wenn die Codestrukturen zu hi-
erarchisch, sprich zu wenig chaotisch sind, oft unmöglich. Genau
dieser Punkt ist ein häufiger Streitpunkt bei Software Architek-
ten viele vertreten den Standpunkt, daß von Anfang an saubere
Design Pattern für ein perfektes Design sorgen müßten. Wohin das
geführt hat, kann man z.B. Beim Projekt FISCUS der Bun-
desregierung sehen, wo 130 hochkarätige Programmierer mit modern-
sten UML Werkzeugen (ROSE) und TOP Software Architekten eine
von Grund auf gute Software Struktur geschaffen haben, mit
sauberen Klassen-Hierarchien. Leider nur ist bei einem solchen
Mammut Projekt kein bewährtes Design Pattern verfügbar gewesen.
Der von Kent Beck in Extreme Programming vorgeschlagene Ansatz,
Pattern langsam sich entwickeln zu lassen, wobei von Zeit zu Zeit
bewußt der gesamte Quellcode eingestampft und von Grund auf neu
progammiert wird, wäre hier sicher erfolgreicher gewesen. Nach
mehrmaligem Neuprogrammieren des Codes zu Beginn des Projektes
hätte das Projekt FISCUS sicher schnell eine Codestruktur erhal-
ten, welche dauerhaft brauchbar und wartbar gewesen wäre. Der
Apache Webserver, die Portal Software PHP-Nuke, das CMS System
Zope, die Groupware E-Groupware, PHProject und viele andere Open-
Source Software Projekte zeigen klar, daß sogar sehr viel ein-
fachere Software mehrfach neu programmiert wurde, weil Er-
weiterungen und Änderungen unmöglich wurden. Als einziges Projekt
ist Zope vollständig nach den Methoden des XP programmiert wur-
den, inclusive umfangreichen UNIT-TESTS.

Analyse und Beurteilung von Softwarestrukturen

Wie analysiert und beurteilt man vorhandene Code Strukturen?
Jesús M. Gonzáles-Barahona et al. haben ein Programm geschaffen,
welches aus einem CVS Baum heraus mit Hilfe des genetischen Gir-
van Newman - Algorithmus die Codestrukturen visualisieren kann.
Anhand des COCOMO Modells wurden z.B. die geschätzten Kosten ein-
er Neuentwicklung der Debian Linux 2.2 Distribution auf 1.9 Bil-
lionen US$ geschätzt. IBM hat schon lange verstanden, und jede
weitere Entwicklung eigener Betriebssysteme eingestellt. Siehe
auch http://www.little-idiot.de/teambuilding/apache-structure.pdf
. Von den Entwicklern der QT3 und QT4 Libraries wissen wir, daß
die komplette Neuentwicklung von QT4 unter Berücksichtigung des
Wissens um die Strukturfehler der neuen Version QT4 nur etwa 1/3
der Kosten von QT3 gekostet hat. Mit Stolz verweisen die Entwick-
ler darauf, daß QT4 nun erheblich wartungsfreundlicher ist, bzw.
auch viel einfacher zu erweitern bzw. zu ergänzen ist. Software-
Entwickler, die Software Cross-Platform - Entwickeln wollen, sei
QT4 empfohlen sie steht für Windows, MAC OS X, Linux, UNIX zur
Verfügung. Man muß hierbei allerdings berücksichtigen, daß die
Entwicklung einer GUI sehr saubere Klassen - Hierarchien er-
fordert, da die Einarbeitungszeit für Entwickler recht hoch ist.
Die Entwicklung einer GUI ist nicht vergleichbar mit dem Projekt
FISCUS z.B. Vergleicht man z.B. Mit den Methoden des XP, so fällt
auf, daß XP alle vier Entwicklungszyklen 1. Planung 2. Design, 3.
Codieren, 4. Testen in schneller Folge von ca. 1-2 Wochen immer
wieder erneut durchlaufen werden, interativ. Die Folge dieser
Vorgehensweise ist, daß Designfehler absolut konsequent frühzeit-
ig entdeckt und radikal korrigiert werden, egal, ob der Code kom-
plett neu geschrieben werden muß. Ich vermute mal, daß seit Ent-
deckung der Tatsache, daß etwas mit dem Design des FISCUS - Pro-
jekt nicht stimmte, und dessen Einstellung - viele hundert Mann-
jahre unsinnig verballert wurden. Niemand der Entscheider hatte
den Mut, den Code nach 5 Jahren sang und klanglos einzustampfen,
und von vorne zu beginnen. Bei OpenSource Projekten, wie z.B. PH-
PNuke kann man in Google nachlesen, daß recht frühzeitig schon
eine Abspaltung des Codes in Postnuke stattgefunden hat, aufgrund
der mangenden Modularität und Sprachanpassungsmöglichkeiten.
Recht viele Projekte in der Open-Source Szene wurden einfach
eingestampft, und neu begonnen, wie Eric Raymond beschrieben hat:
http://www.little-idiot.de/xp/opensourceentwicklung.htm Dafür be-
sitzen die erfolgreichen Open-Source Programme ein glänzendes De-
sign, sind modular aufgebaut, einfach zu erweitern und zu
verändern.

Die Grenzen des Refactoring sind recht schnell erreicht, wenn die
Codestrukturen bzw. das Design nicht stimmt. Nirgendwo kann man
mehr über Komplexitätstheorie in der Softwareentwicklung lernen,
als in der Open-Source Szene und dort vor allem bei den beson-
ders großen Softwarepaketen, wie z.B. dem Linux Kernel, dem
Free/NetBSD Kernel, dem Apache Webserver mitsamt seinen unzähli-
gen Modulen, dem Office Paket OpenOffice 2.0, und einigen Group-
ware Produkten, darunter z.B. auch Compière, einem ERP / CRM
Programm.

So haben z.B. die Besitzer der kommerziellen Closed Source -
Software CYCOS, siehe http://www.cycos.de , nach sorgfältiger
Analyse der Code - und Programmierer Strukturen, verteilt über
mehrere Länder, darunter auch Frankreich und U.S.A. - schnell und
schmerzlos entschlossen, ihren Laden an Siemens zu verkaufen.
Ende, Schluß, AusDieMaus. Refactoring, so ergab die Analyse, war
aufwändiger, als eine komplette Neuprogrammierung. Neuprogram-
mierung war leider auch nicht mehr möglich, weil das Wissen um
die Kommunikations - Protokolle durch den Wechsel und Ausscheiden
von Programmierern in der Firma nicht mehr vorhanden war. Niemand
weiß nun mehr genau, wie die Software insgesamt funktioniert, wie
und wo welche Kommunikationsprotokolle was bewirken. Auch ein aus
den U.S.A. eingeflogener Guru für SCUM, XP, Agile Programming
kann an dieser Tatsache nichts ändern. Ein ähnliches Schicksal
hatte auch die U.S.A. getroffen es gibt inzwischen niemanden
mehr, der das Ingenieurswissen der Gruppe um Werner von Braun
herum festgehalten hätte aus der Raumfahrer-Nation, welche einst
zum Mond flog, ist ein teurer Papiertiger namens NASA ohne eine
wirklich sinnvolle Aufgabe geworden. Russische und europäische
Raketen bringen Satelliten viel preiswerter und sicherer ins All,
eine Raumstation ISS benötigt niemand.

Eine Programmierer Gruppe, welche für ein Modul bei Toll-Collect
zuständig war, hatte ein Problem dem zuständigen Projektleiter
lief das Projekt aus dem Ruder, er wußte nicht mehr, welcher Pro-
grammierer woran genau arbeitete, diese kamen und gingen, wann
sie wollten. Ein auf die Schnelle angeordnetes Kommunikation-
straining nach dem Modell von Friedemann Schulz von Thun schaffte
auch keine dauerhafte Verbesserung, weil Mensch stets dazu neigt,
nach erfolgreichem Training in die alten Verhaltensmustern
zurückzufallen, insbesondere im Team. Die tatsächliche Ursache
lag wo ganz anders die Programmierer arbeiteten für private Pro-
jekte unbemerkt vom Management Mangelhafte Kontrollprozesse
waren die Kernursache. Insgesamt kann man sehr viel von der En-
twicklung erfolgreicher Open-Source Projekte lernen, eXtreme
Programming ist genaugenommen, eine Sammlung von emergenten
Prozessen, wobei sehr viele aus der Prozessoptimierung des Toyota
Produktions Systems entnommen sind. Wer sich für diese Denkweisen
interessiert, dem sei das Buch Lean Thinking von Womack/Jones,
ISBN 3-593-37561-3

Je nach menschlich / psychologischen Eigenschaften ist ein Pro-
jektleiter/Manager gut beraten, sich in einem Team die psycholo-
gisch/menschlichen Eigenschaften seiner Mitarbeiter individuell
genau anzusehen. Nichts spricht dagegen, einen Teil der Mitar-
beiter nach dem eXterme Programming Modell arbeiten zu lassen,
andere nach agilen Methoden, oder auch wiederum andere Mitarbeit-
er Pair-Programming oder sogar gänzlich alleine wurschteln zu
lassen. Wer die impliziten Logiken hinter den Modellen verstanden
hat, ist in der Lage, sich aus den verschiedensten Softwareen-
twicklungsmodellen diejenigen Prozesse herauszusuchen, die auf
die psychologisch/menschlichen Eigenschaften der Individuen im
Team genau passen. Wer Individuen über einen Kamm schert, also
allen gemeinsam z.B. XP aufzwingt, riskiert die innere Kündigung
von äußerst produktiven und wertvollen Mitarbeitern. Als sehr
wirksam hat sich nach meiner Erfahrung erwiesen, das Wissen um
die emergenten Prozesse in das Team hineinzutragen, und die Mi-
tarbeiter selber entscheiden zu lassen, wie diese sich organ-
isieren wollen. In der Kunst hat Lois Sullivan bzw. in Deutsch-
land erstmals das Bauhaus einen Slogan geprägt Form folgt Funk-
tion oder darf es nicht auch heißen: Funktion folgt Form? Kann
ich eine Tasse zum Trinken von heißem Tee evtl. nicht verwenden,
wenn sie nicht eine bestimmte Form hat? Ebenso verhält es sich
mit den bestehenden Strukturen innerhalb der Software. Struktur
der Zusammenarbeit der Programmierer und Struktur der Software
müssen übereinstimmen, unabhängig von den Software-Entwick-
lungsprozessen, wie man z.B. bei der Analyse der Apache Soft-
ware-Struktur sehen kann. Zur Visualisierung eines CVS (Root) -
Baumes stehen mächtige, kostenlose Werkzeuge bereit, mit denen
z.B. die Strukturen des Apache Webservers visualisiert wurden,
siehe http://www.little-idiot.de/teambuilding/apacheentwick-
lung.gif . Die Essenz dieser Alchemie, den Wissens über die emer-
genten Prozesse und deren Wechselwirkung mit den psycholo-
gisch/menschlichen Eigenschaften läßt sich im Grunde auch auf an-
dere Bereiche anwenden. Hat das Team es einmal verstanden, wie
man mit wenigen Regeln Arbeits - Prozesse so gestaltet, daß Emer-
genz auftritt, so führt das dazu, daß Mitarbeiter in einem Team
ständig gedanklich auf die Suche nach besseren, prozessualen
Abläufen gehen, also ständig die Abläufe der täglichen Zusamme-
narbeit optimieren. Das Management gibt hierzu eigentlich nur die
Meta-Prozesse vor, die eigentliche Optimierung der Arbeit-
sprozesse bzw. Programmieraufträge abliegt dann den Mitarbeitern
selber. Erfahrungsgemäß steigt die Begeisterung bei den Mitar-
beitern stark an als Glücklich empfindet sich stets ein Mensch,
der eine Vielzahl von Handlungs- und Gestaltungsmöglichkeiten
hat. Geld ist in unserer Zeit ein Mittel, um mehr Gestal-
tungsmöglichkeiten zu haben. Interessanterweise ergeben Umfragen
bei hochbezahlten Programmierern, daß Geld nicht glücklich macht,
wenn Gestaltungsmöglichkeiten fehlen. Die OpenSource Szene be-
weist, daß Programmierer auch völlig ohne Entlohnung freiwillig
in ihrer Freizeit arbeiten, sofern sie die Welt mitgestalten
können. Leider verstehen es bislang kaum hochkarätige Manager
oder Projektleiter, warum manche niedrig bezahlte Mitarbeiter mit
viel Begeisterung mehr leisten, als andere, hochbezahlte Mitar-
beiter. Im übrigen ist das Prinzip uralt: Das Rote Kreuz mit
seinen hunderttausenden, ehrenamtlichen Helfern nutzt schon seit
Jahrzehnten dieses emergente Prinzip, welches dann von Richard
Stallmann für die Softwareentwicklung unter dem Namen GNU neu er-
funden wurde. Wer einmal die GNU Prozesse analysiert, findet
dort schnell die emergenten Prozesse wieder, die in diesem
Beitrag ansatzweise beschrieben wurden. Nichts spricht daher auch
dagegen, für ein kommerzielles Programmier-Projekt - eine
riesige Heerschar von freiwilligen Programmieren als Helfer zu
gewinnen, um somit die Entwicklungskosten gewaltig zu reduzieren.
IBM hat dies schon lange verstanden, siehe das Eclipse und Linux
Projekt. Eine riesige Schar von professionellen Programmieren
(mehrere Mrd. US$ Volumen jährlich) arbeiten für eine Vielzahl
von Open-Source Projekten, allen voran natürlich LINUX, welches
komplett alle alten Betriebssysteme von IBM ersetzen soll (OS/2,
OS/390, MVS ...) Ob und wie die Intergration funktionieren kann,
läßt sich erst nach einer genauen Analyse der Interessen der
Open-Source Community entscheiden. Wer ein noch tieferes
Verständnis von Emergenz bzw. emergenten Prozessen bekommen
möchte, dem seien die Kybernetik Bücher von Heinz von Förster Der
Anfang von Himmel und Erde hat keinen Namen oder meine Überset-
zung von SunTse's Kriegsstrategien lesen, welche den Grund für
den durchschlagenden Erfolg von alten, chinesischen Generalen,
Napoleon und auch der Wehrmacht anschaulich darstellen, siehe:
http://www.little-idiot.de/teambuilding/SunTsuKunstDesKrieges.pdf

Regelmäßige, 3-tägige Seminare Emergente Software-Entwicklungs-
Prozesse finden monatlich in Aachen statt, nächste Termine
18.-20. und 25.-28. Oktober 2005. Anmeldung bitte an:

mailto:***@little-idiot.de

Dieser Beitrag ist unter:

http://www.little-idiot.de/teambuilding/EmergenteSoftwareEntwicklungsProzesse.pdf
zu finden.

"Was nicht auf einer einzigen Manuskriptseite zusammengefaßt wer-
den kann, ist weder durchdacht, noch entscheidungsreif" (Dwight
David Eisenhower, 34. Präsident der USA 1953-1961; *14.10.1890)

[Ralf Mimoun]

Moin!

***@little-idiot.de wrote:
[jede Menge gelöscht]

Und was soll dieser Spam bitte hier? Geh weg und verkauf Deine Seminare
woanders. Buzzword Bullshit Bingo können wir selbst programmieren.

Bye, Ralf

[Marian Aldenhövel]

Post by s***@little-idiot.de
"Was nicht auf einer einzigen Manuskriptseite zusammengefaßt wer-
den kann, ist weder durchdacht, noch entscheidungsreif"

Und Tschüss.

Ciao, MM

[Stefan M. Huber]

On Thu, 06 Oct 2005 00:57:18 +0200, Marian Aldenhövel

Post by Marian Aldenhövel

Post by s***@little-idiot.de
"Was nicht auf einer einzigen Manuskriptseite zusammengefaßt wer-
den kann, ist weder durchdacht, noch entscheidungsreif"

Und Tschüss.

Hui, auf den Punkt gebracht! Andererseits, wenn man sich die 151KB auf
Winzigschriftart ausdruckt oder einen A0 Bogen verwendet...

Stefan

[Marian Aldenhövel]

Hallo,

Andererseits, wenn man sich die 151KB auf Winzigschriftart ausdruckt
oder einen A0 Bogen verwendet...

Als ich noch Rundfunk-Artikel abgetippt habe war eine Manuskriptseite
genau definiert und da passte gar nicht viel drauf. Ich glaube es waren
irgendwie 50 Anschläge 1 1/2 zeilig auf A4. Die Faustregel war: Eine
Seite eine Sendeminute.

Da fällt der kleine Idiot klar durch.

Ciao, MM

[Ralf Mimoun]

Moin!

Marian Aldenhövel wrote:
...

Post by Marian Aldenhövel
Als ich noch Rundfunk-Artikel abgetippt habe

Für Geld machst Du aber auch fast alles... ;-)

Bye, Ralf

[Marian Aldenhövel]

Hallo,

Post by Ralf Mimoun
Für Geld machst Du aber auch fast alles... ;-)

Da redet genau der richtige.

Ciao, MM

[Ralf Mimoun]

Moin!

Post by Marian Aldenhövel
Hallo,

Post by Ralf Mimoun
Für Geld machst Du aber auch fast alles... ;-)

Da redet genau der richtige.

Wieso? Ich schränke das bei mir nicht durch ein wabbeliges "fast" ein. On
olet, und wenn doch, gibts Nasenklammern.

Bye, Ralf

[s***@little-idiot.de]

Danke für die Blumen - ich wünsche, ihr würdet auch mal was
Sinnvolles zustandebringen ...

LG, Guido Stepken

[Bittner Jürgen]

Post by s***@little-idiot.de
Danke für die Blumen - ich wünsche, ihr würdet auch mal was
Sinnvolles zustandebringen ...
LG, Guido Stepken

Ach wir Dummchen. Aber wieso auch.
Jürgen

[Ralf Mimoun]

Hallo Klaus-Bärbel,

Post by s***@little-idiot.de
Danke für die Blumen - ich wünsche, ihr würdet auch mal was
Sinnvolles zustandebringen ...

Der war gut, wirklich :-) Dann wohlann, liste doch mal auf, was Du außer
triefender Eigenwerbung schon so "beigetragen" hast. Vielleicht in NGs,
vielleicht in Zeitschriften... was Du vielleicht sonst zur Community
beigetragen hast... wir sind gespannt!

Bye, Ralf (der das Gefühl nicht los wird, daß der kleine Idiot [_seine_
Wahl, nicht meine!] gerade den falschen Baum anpinkelt ;-)

[Jens Winter]

Post by s***@little-idiot.de
Danke für die Blumen - ich wünsche, ihr würdet auch mal was
Sinnvolles zustandebringen ...

Tsts.. Und da wollte ich mich gerade für Dein Seminar anmelden...

Ciao
JJ

[Marian Aldenhövel]

Hallo,

Sinn ist weit überbewertet.

Ciao, MM

[Thomas Zangl]

^^^^^^^^^^^^^^^

Sehr treffend.

SCNR,

[Hans-Peter Diettrich]

Post by s***@little-idiot.de
Emergente Softwareentwicklungsprozesse
Wie gelingt es in freien Projekten, ohne autorisierte
Projektleitung, ohne Projektmanagement, hierarchische
Strukturen, Entscheidungen zu treffen, Aufgaben zu verteilen und
zu koordinieren? Keine Kaffeekränzchen, keine dauernden Be-
sprechungen, keine kontraproduktiven Bedenkenträger Habe ich
schon immer gesagt..., kaum innere Reibung ...

Da würde ich einfach einmal die erfolgreichen kommerziellen Projekte in
Relation zur Anzahl der erfolgreichen freien Projekten setzen. Erst dann
läßt sich eine Aussage treffen, welche der dabei jeweils verwendeten
Management-Strategien am erfolgreichsten war. Kaffekränzchen und
totalitäre Chefs gibt es in beiden Bereichen, und inkompetente
Programmierer oder Manager können ein freies Projekt noch schneller
versauen als ein intensiver kontrolliertes kommerzielles Produkt
(Zeitdruck...).

...

Post by s***@little-idiot.de
Die Kiste wieder in Händen, entfernt man das
eigene Schloß, und sendet die Kiste abermals zurück. Der
Empfänger kann nun sein eigenes Schloß entfernen, den Inhalt
lesen. Zu keinem Zeitpunkt wurde ein Schlüssel ausgetauscht, und
zu keinem Zeitpunkt war die Kiste unverschlossen unterwegs.

Statt der Schlüssel waren eben Schlösser unterwegs, die sich mit
geeigneten Methoden auch knacken lassen. Die Schlüssellänge rennt ja
bekanntlich ständig der verfügbaren Rechenpower hinterher.

Post by s***@little-idiot.de
Der Begriff Emergenz beschreibt also Prozesse, welche durch ihre
impliziten Logiken nachfolgende Prozesse erst ermöglichen, erhe-
blich beschleunigen oder Resourcen sparen.
Wenn
ein Softwareprojekt gut vorangeht, ist dies noch lange keine
Garantie dafür, daß nicht kurz vor Schluß doch noch wegen
unlösbarer Probleme der Großteil des Codes neu entwickelt werden
muß.

Das kommt in den besten Familien vor :-(

...

Post by s***@little-idiot.de
Emergenz - Das Ganze ist mehr, als die Summe sein-
er Komponenten ist hier für die Leistung des Teams insgesamt ver-
antwortlich. Im Grunde liegt bei den erfahrenen Programmierern
eine große Chance sie können durch weitergabe ihre Wissens die
jungen Kollegen mitziehen und die Leistung des Teams erheblich
steigern. Eine einzige gute Idee, z.B. kann dem Team insgesamt
enorm Entwicklungszeit einsparen

Auf jeder Ebene können gute und schlechte Entscheidungen getroffen
werden. Ausschlaggebend dafür ist wohl Kompetenz (Erfahrung), die sich
aber nur schlecht erkennen und messen läßt. Im kommerziellen Bereich
führt das oft dazu, daß ein Top-Manager ganz schnell wieder einen
gutdotierten Posten findet, nachdem er eben ein Unternehmen ruiniert
hat. Oder umgekehrt, daß er das neue Unternehmen ruiniert, nachdem er
von einem gut florierenden Unternehmen abgeworben wurde.

...

Post by s***@little-idiot.de
Warum angesichts dieser Tatsache immer noch
Entscheider haufenweise auf SQL Datenbanken setzen, und nicht
auf OO-Datenbanken bzw. Postrelationale Datenbanken, ...
... ist mir ein Rätsel.

Genauso könnte man darüber rätseln, warum es noch keine OO-Hardware
gibt, wenn die doch aus ganz prinzipiellen Erwägungen deutlich besser
sein müßte als die aktuelle Hardware...
Es wird schon seine Gründe haben, über die ich mich aber hier nicht
weiter auslassen möchte ;-)

Post by s***@little-idiot.de
Die implizite Logik der Kontrolle im Restaurant liegt einfach
darin, daß in einem geschlossenen Kreislauf bei den verschiedenen
Verarbeitungsprozessen die Stückzahlen unabhängig gemeldet/gebont
werden müssen.

So einfach lassen sich Probleme bei der Programmentwicklung leider nicht
erfassen :-(

Post by s***@little-idiot.de
Toyota und Porsche haben z.B. Bei der Fließband-
Produktion eingeführt, daß der Nachfolgende die Arbeit des
Vorgängers kontrolliert, damit sich die Fehler im Laufe von 100
Arbeitsgängen nicht potenzieren, sondern gegenseitig aufheben.
Bevor nicht die Fehlerbehoben sind, läuft das Band nicht weiter.
Der Druck der Gruppe zwingt jeden Arbeiter, präzise und genau zu
arbeiten.

Damit werden aber nur bekannte bzw. leicht erkennbare
Fehlermöglichkeiten erfaßt, der Konstrukteur erfährt nicht notwendig
davon, was für Mist er gebaut hat, den nun die Arbeiter mühsam zum
Laufen bekommen müssen.

Post by s***@little-idiot.de
Ein klares Beispiel für Emergenz kann man auch bei einem sehr
verblüffendem Experiment von Reynolds 1987 beobachten, welcher
1.Kollisionsvermeidung: Vermeide Kollision mit Nachbarn oder an-
deren Hindernissen 2.Geschwindigkeitsanpassung: Passe deine
Geschwindigkeit der deiner Nachbarn an 3.Schwarmerhaltung: Ver-
suche, in der Nähe deiner Nachbarn zu bleiben

...

Post by s***@little-idiot.de
Ein
Kybernetiker, der das Prinzip für Emergenz verstanden hat,
schreibt nur drei Regeln für prozessuale Abläufe vor, wohl wis-
send, daß jeder Vogel als Individuum als eigenständiger Agent
selber entscheiden kann, welche Flugbahn dieser einschlägt, und
nach welchen Kriterien er dies entscheidet.

Das könnte man dann so formulieren:
1. Vermeide Kollissionen mit Deinen Kollegen (lasse sie in Ruhe).
2. Arbeite nicht schneller als Dein Nachbar (nicht langsamer kann nicht
vorgeschrieben werden ;-)
3. Versuche keine neuen Ideen einzubringen.

Ein durchaus gängiges Prinzip, in "gut funktionierenden" Betrieben.

Post by s***@little-idiot.de
1.Einzelpersonen und Interaktionen sind wichtiger als Prozesse
und Werkzeuge 2.Laufende Systeme sind wichtiger als umfangreiche
Dokumentation 3.Zusammenarbeit mit dem Kunden ist wichtiger als
Vertragsverhandlungen 4.Reagieren können auf Veränderung ist
wichtiger als Pläne zu verfolgen

Das kann man genausogut auch umgekehrt sehen. Auch hierzu keine
bitterbösen Kommentare ;-)

Post by s***@little-idiot.de
Die Prozesse der Softwarentwicklung sind untrennbar mit dem
Prozess der Wartung verbunden. Warum der Glaube an das V-Modell
vorherrschend ist, obwohl in diesem die sich ständig verändernden
Anforderungen an die Software nicht berücksichtigt sind, ist mir
ein Rätsel.

Dann würde ich erst einmal versuchen, dieses (wie die anderen) Rätsel zu
lösen, vielleicht gibt das ja neue Einsichten ;-)

Post by s***@little-idiot.de
Wichtig ist es, ein Team mit kompetenten Mitgliedern zu haben!

Ganz meine Meinung!

Post by s***@little-idiot.de
Worin liegt hier die
Emergenz? Diese Vorgehensweise sorgt dafür, daß z.B. vom Kunden
im Laufe der Projektentwicklung gewünschten, besonderen Features,
welche nicht elementar notwendig, und gleichzeitig komplex zu im-
plementieren sind, also das Produkt unnötig verteuern würden, au-
tomatisch wegfallen.

Das führt erfahrungsgemäß oft dazu, daß der Nutzen eines (vereinfachten)
Progamms von einem noch größeren Arbeitsaufwand beim Benutzer mindestens
zunichte gemacht wird. Nichts gegen Vereinfachungen, ganz im Gegenteil,
aber man kann nicht jede Vereinfachung zuerst einmal in der Praxis auf
ihre Brauchbarkeit prüfen.

[An dieser Stelle hat sich Netscape geweigert, mehr Text zu quoten. Ich
schließe mich dem an, und mache hier einfach mal Schluß. Ein
Patentrezept habe ich nicht anzubieten, und ein Glaubenskrieg führt auch
zu nichts.]

DoDi

[Andreas Mosmann]

***@little-idiot.de schrieb am 05.10.2005 in
<***@g43g2000cwa.googlegroups.com>:

Oh, wir haben einen neuen Troll?

Der mußte wohl aus
- de.sci.philosophie
- de.sci.psychologie
- de.sci.theologie
und weiteren flüchten?

Andreas