Chaehan So vom Institut für Organisations- und Sozialpsychologie der Humboldt Universität Berlin sucht agile Teams für eine Teilnahme an einer Studie. Das Ziel der Studie lässt sich am besten in Chaehans eigenen Worten beschreiben: „The current study uses an organizational psychology lens to gain a fundamental understanding of how Agile Practices influence socio-psychological mechanisms leading to more effective projects“.
Wer an einer Teilnahme interessiert ist, findet weitere Informationen auf der Studienseite.
Archiv des Autors: Jens Coldewey
Hürden gegen Akzeptanztest-getriebene Entwicklung
Brian Marick fasst in seinem Blog-Eintrag „Barriers to acceptance-test driven design“ die wichtigsten Startprobleme gegen den Einsatz von Akzeptanztests zusammen.
Interessanterweise habe ich vor allem bei größeren Mengen alten Codes genau die umgekehrte Erfahrung gemacht: Teams waren eher bereit, Akzeptanttests als Grundlage für ihre Entwicklung zu nehmen, als Unit-Tests. Das liegt möglicherweise daran, dass Unittests gut funktionieren, wenn man auf der grünen Wiese startet. Sind erhebliche Mengen alten Codes vorhanden, ist der in der Regel so schlecht testbar, dass Akzeptanztests den leichteren Weg darstellen, schnell die Testabeckung zu erreichen, die man braucht, um das System sicher ändern zu können.
Agilität und Software-Engineering
Was hat Agilität mit Software-Engineering zu tun? Ist es ein Gegenkonzept oder alter Wein in neuen Schläuchen? In meinem aktuellen Posting auf dem Cutter Blog „An Agile View on Software Engineering“ habe ich eine Diskussion zu dem Thema gestartet.
Notizen von der OOPSLA – Refactoring Werkzeuge
Einmal im Jahr gönne ich mir den Besuch der OOPSLA. Zum einen, um Bekanntschaften und Freundschaften zu pflegen, aber auch, um einen Überblick zu bekommen, was derzeit an (wirklich) neuen Dingen aufkommt, abseits der aufgeregten Marketing-Hypes. Ich möchte hier über für mich interessante Erkenntnisse berichten.
Am ersten Tag entschloss ich mich kurzfristig, als Zuhörer am zweiten Workshop über Refactoringwerkzeuge teilzunehmen. Eine Entscheidung, die sich gelohnt hat, obwohl ich normalerweise „Präsentationsworkshops“ meide. Der Workshop hat einen guten Überblick über den aktuellen Stand der Forschung zum Thema Refactoring gegeben und deutlich gemacht, dass wir hier erst am Beginn einer Entwicklung stehen, die unsere Arbeit über die nächsten Jahre wesentlich beeinflussen wird.
Zu den Vorträgen:
Refactoring bei IntelliJ
Dimitri Jemerov von JetBrains (IntelliJ, Resharper) stellte die Mechanismen hinter den Refactoring Browser von IntelliJ IDEA vor. Er basiert auf einem gemeinsamen „Refactoring Workflow Framework“, mit dem sich die einzelnen Operationen relativ einfach implementieren lassen. Jemerov sprach von einer „Refactoring DSL“, die bei IntelliJ dafür entwickelt wurde.
Während die Grundlagen relativ gut standardisierbar sind (und die vorgestellten Ideen auch entsprechend wenig überraschend), liegt der Teufel und damit auch der Aufwand im Detail. Hier diktiert die Sprachkomplexität auch die Komplexität des Refactorings. Gerade bei Java mit seinen Einschränkungen was wo erlaubt ist, führt das beim Refactoring gelegentlich auch zu Ergebnissen, die nicht gerade schön sind. Die Begründung war pragmatisch: Normalerweise wird refaktorisierter Code nicht mehr überprüft. Daher muss er zu 100% korrekt sein, auch wenn das Ergebnis nicht gerade elegant ist.
Interessante Features von IntelliJ, die er vorstellte, waren:
- Extract Method bei mehreren Ergebniswerten: Hier werden komplette Klassen erzuegt und extrahiert.
- Refactorings über mehrere Sprachen: Während der aktuelle Stand (Rename, Move) noch nicht so aufregend ist, wird derzeit daran gearbeitet, die interne Darstellung sprachübergreifend zu gestalten, um auch komplexe Refactorings sprachübergreifend zu ermöglich. Geplant ist Unterstützung von Java, Ruby, Groovy, Python und XML (wenn ich keinen vergessen habe…)
- Veränderung von Typen: Als Beispiel ersetzte Dimitri ein Array durch eine Liste, ein Beispiel für ein ziemlich komplexes Refactoring, das auch nur teilautomatisiert möglich ist. Leider reichte die Zeit nicht aus, das im Detail darzustellen.
Die anschließende Diskussion kreiste vor allem um den Konflikt zwischen 100% korrektem Umbau des Codes, eleganten Ergebnissen und Unterstützung des Entwicklers. Es dürfte hier kaum möglich sein, den richtigen Weg zu finden.
Oberflächen für Refactoring Werkzeuge
Dustin Campbell, der vor wenigen Monaten von DevExpress (Refactor!) zu Microsoft wechselte, demonstrierte aktuelle Entwicklungen in der Oberfläche von Refactoring Werkzeugen am Beispiel von Refactor!. Der Trend geht dahin, den Browser nahtlos in den Editor zu integrieren: Keine Dialogboxen mehr, keine Sammlungen von Shortcuts, statt dessen kontext-sensitive Erweiterungen des Editors. Wer mit Eclipse arbeitet, kennt ähnliche Ansätze bereits vom Umbenennen eines Identifikators: Drückt man vor dem Editieren eines Identifikators eine bestimmte Tastenkombination, werden auch alle anderen Vorkommen umbenannt. Refactor! treibt diesen Ansatz wesentlich weiter: Das Werkzeug ist darauf optimiert, mit einem einzigen Shortcut kontextsensitiv zu arbeiten.
Die Demonstration war beeindruckend, hier wurde ziemlich sicher die derzeit beste Lösung für die Oberfläche des Werkzeugs präsentiert. Ob die dahinter liegenden Mechanismen mit den Anforderungen großer Systeme mithalten können, weiß ich nicht. Ebenso wenig ist mir klar, ob diese Art der Oberfläche für Umbauten an großen Systemen noch adäquat ist, insbesondere in Situationen, in denen bewusst nicht-vollständige Refactorings eingesetzt werden sollen. Das lässt sich sicherlich nur durch praktischen Einsatz herausfinden (Bekannt ist, dass Refactor! für C++ erhebliche Stabilitätsprobleme hat. Die Versionen für C# (und andere .NET Sprachen) scheinen nicht so extrem unter diesem Problem zu leiden). Unabhängig davon ist die enge Integration von Editor und Refactoring sehr interessant (sie war genau genommen bereits in John Grants und Don Roberts „Ur-Refactoring-Browser“ angelegt) und ich hoffe, dass sie sich auf breiter Basis durchsetzen.
Werkzeuge zur Entwicklung von Refactoring Werkzeugen
Dieser Teil des Workshops richtete sich naturgemäß eher an jene, die selbst Refactoring bauen, als an deren Anwender. Ich fand die Vorträge dennoch interessant, weil sie einen guten Eindruck liefern, mit welchen Problemen derzeit gekämpft wird und was uns die Zukunft hier bringen kann.
Verbesserung der Analyse
Max Schäfer von der Oxford University stellte eine Refactoring Engine vor, die sich vor allem um Namensprobleme kümmert, um sicher zu stellen, dass die verbreiteten Probleme, die Refactoringwerkzeuge mit Verschattung von Namen haben. Aus Anwendersicht war die Nachricht interessant, dass keines der marktüblichen Werkzeuge hier wirklich sauber arbeitet. Es lohnt sich also weiterhin, darauf zu achten, dass man die Verschattungsregeln der Sprachen nicht zu sehr ausreizt eine Regel, die schon im Interesse der Lesbarkeit von Programmen sinnvoll ist.
Framework für den Bau von Refactoring Werkzeugen
Jeffery Overbey, ein Diplomand von Ralph Johnson an der Univerity of Illinois, Urbana Champaign, demonstrierte einen Ansatz, die für brauchbares Refactoring notwendigen Syntaxbäume aus speziellen Grammatiken zu erzeugen. Sein Demonstrationsobjekt war ein Transformationswerkzeug für Fortran-Programme. Hier ging es eher im Detailprobleme, die eher für Werkzeugbauer von Interesse sind, wie zum Beispiel der Umgang mit Kommentaren und Einrückungen, Themen die im klassischen Compilerbau kaum eine Rolle spielen, für die Akzeptanz von Refactoring Werkzeugen aber entscheidend ist. Der Vortrag hat schön gezeigt, dass Refactoringwerkzeuge derzeit eine ähnliche Entwicklung durchmachen, wie Compiler in den 70er Jahren. Das halte ich durchaus für einen Grund, sich auf die Werkzeuge der nächsten zwanzig Jahre zu freuen 🙂
Refactoring auf höherer Ebene
Macneil Shonle von der University of San Diego stellte ein Plug-in für Eclipse vor, das versucht, Java Refactorings auf höherer Ebene umzusetzen (Arcum). Auch wenn sich der Vortrag eher um Grundlagenforschung drehte, zeigte er doch, dass zumindest die angelsächsischen Universitäten mittlerweile den Ball aufgenommen haben und an den komplexen Problemen wie Migrationen von Bibliotheken forschen. Sollten diese Arbeiten für den professionellen Einsatz reif werden womit ich nicht in den nächsten zehn Jahren rechne , könnte das den Umgang mit Architektur und Bibliotheken ähnlich revolutionieren, wie die derzeitigen Werkzeuge den Umgang mit Code und Design verändert haben.
Analyse des Refactoring von Entwicklern
Emerson Murphy-Hill von der Portland State University berichtete über Strategien, um herauszufinden, welche Refactorings an einer Codebasis durchgeführt wurden. Auch er stellte noch mehr Fragen vor, als Antworten. Ziel ist die Verbesserungen von Refactoringwerkzeugen, das Thema kann aber auch relevant werden, um Dokumentations- und Revisionsanforderungen zu erfüllen, oder in Wartungssituationen den Code zu verstehen. Zweifel sind aber angebracht: Murphy-Hill stellte fest, dass nur ca. 10% der Refactorings mit Werkzeugen durchgeführt werden und nur etwa ein Drittel sich überhaupt im Versionsmanagement niederschlagen. Sein Resümee: Wir kennen (noch) keine zuverlässige Methode, durchgeführte Refactorings zu ermitteln.
Zum Nachdenken hat auch eine Erkenntnis am Rande angeregt: Deutete ein Check-in in das Versionsmanagement einen Kommentar, der auf Refactoring hindeutet, war die Anzahl der darin enthaltenen Umbauten halb so groß [sic!], wie bei Check-ins ohne solche Kommentare. Es wäre interessant, ob sich das auf die Zuverlässigkeit von Check-in-Kommentaren verallgemeinern lässt.
Refactoring Lab
Josh Kerievsky, Autor des Buchs „Refactoring to Patterns“ und Gründer von „Industrial Logic„, zeigte den Einsatz seines „Refactoring Labs“, eines Trainingswerkzeugs für Refactoring. Die Studenten werden vor eine Refactoringaufgabe gestellt und das Lab analysiert den gewählten Lösungsweg und macht Verbesserungsvorschläge, z.B. dass bestimmte Schritte, die manuell gemacht wurden, einfacher im Refactoringbrowser durchgeführt werden können. Die Regeln sind als JUnit-Tests hinterlegt und überprüfen z.B. wie oft die Tests gestartet wurden und welche Optionen beim Umbau eingesetzt wurden. Ein sehr nettes Werkzeug für die Schulung.
Refactoring für Nebenläufigkeit
Der Organisator Danny Dig berichtete über seine Arbeiten am MIT, in denen er versuchte, sequenziell geschriebenen Code in Code umzustellen, der die Java 5 Unterstützung für Nebenläufigkeit nutzt. Das Werkzeug heißt Concurrencer und ist als Eclipse-Plugin verfügbar. Die Wirksamkeit des Tools wurde mit 6 Open Source Projekten überprüft. Die Ergebnisse waren zwar nicht perfekt, aber deutlich besser, als die manuellen Umstellungen der Entwickler, die die entsprechenden Werkzeuge betreuen. Immerhin machte das Werkzeug keine Fehler, die zu Fehlfunktionen der Software führen können im Gegensatz zu vier solchen Fehlern im offiziellen, manuell umgestellten Code. Als wichtige Richtung für die zukünftige Entwicklung wurde die Integration mit Analysewerkzeugen angesprochen: Deren Ergebnisse sollten die Entwickler durch die notwendigen Schritte leiten.
Wer vor dem Problem steht, Java Code threadsafe zu machen, sollte sich das Tool genauer ansehen.
Refactoring von Programmen zur Matrixmanipulation
Beverly Sanders von der University of Florida erzählte über den Einsatz von Refactoring in der algebraischen Chemie. Dabei werden chemische Reaktionen simuliert, was im Wesentlichen darauf hinausläuft, Lösungen für die Schrödingergleichungen zu finden. Die Programme laufen auf hoch-parallelen Supercomputern mit speziellen DSLs für Matrizenumformungen. Hier wird Refactoring nicht zur Verbesserung des Designs eingesetzt, sondern um die Performance und Ausführungskomplexität zu verbessern. Das geht oft nicht durch pures Ansehen, sondern auf der Basis von Messungen. Für mich war die Einsicht spannend, dass man Refactoring auch in zunächst anderen Domänen mit ganz anderen Zielen betreiben kann. Der Schluss liegt nahe, dass wir hier erst ganz am Anfang stehen.
Resümee
Refactoring steht erst am Anfang. Sowohl für die Werkzeuge im breiten Einsatz, als auch in Randthemen besteht noch erheblicher Forschungsbedarf, der zunehmend von den Universitäten auch angegangen wird. Aus Sicht des Praktikers kann man nur hoffen, dass sich diese Forschung so bald wie möglich in breit einsetzbaren Produkten niederschlägt. Das könnte die Art, wie wir programmieren weg vom Programme schreiben hin zu Software entwickeln revolutionieren — vorausgesetzt, die Ausbildung wird auch entsprechend angepasst.
Refactoringseminar in München
Es ist bald wieder so weit: Am 19. und 20. November gebe ich in Zusammenarbeit mit SIGS Datacom zum dritten Mal öffentlich das zweitägige Intensivseminar „Refactoring in der Praxis oder die Kunst schmerzfreier Änderungen„. In dem Seminar werden die Teilnehmer ausgehend von unlesbarem Code durch diszipliniertes Refactoring zunächst wartbaren Code erzeugen und dann daraus Ansätze für eine Architektur entwickeln. Neben der praktischen Arbeit gibt es natürlich auch Hintergrundinformationen und die notwendige Theorie. Der Kurs ist bisher von dem Teilnehmern mit der Note 1,6 benotet worden.
Weitere Informationen und die Anmeldeseite finden Sie hier.
Einführung agiler Entwicklung bei Yahoo International
Das schweizer Online-Magazin devagile berichtet über einen Vortrag über die Einführung agiler Techniken bei Yahoo International, die alle Yahoo-Aktivitäten außerhalb der USA bündelt. Spannend fand ich den Ansatz, den Teams freizustellen, ob sie weiterhin traditionell arbeiten wollen, oder mit einem agilen Ansatz. Alle europäischen Teams hatten sich darauf hin nach einem Jahr für agiles Arbeiten entschieden, während sich asiatische Teams deutlich schwerer taten. Ich interpretiere das als weiteres Indiz, wie eng agile Entwicklung und Kultur zusammen hängen.
Ist Agile Entwicklung billiger II
Felix Rüssel schreibt in seinem „Armer Kater“ Blog zu meinem Artikel „Ist Agile Entwicklung billiger?“:
Jens schreibt jedoch auch, dass Kundenzufriedenheit das Primärziel bei jedem Projekt sein sollte. Dem kann ich nicht zustimmen, da dies eine verkürzte Sicht darstellt, v.a. wenn es sich um Unternehmen handelt, die mit Projekten Geld verdienen müssen.
Primärziel einer Unternehmung ist es weiter zu existieren und dabei möglichst Gewinn zu erwirtschaften.
Die Kundenzufriedenheit ist in den meisten Fällen ein wichtiger Faktor, um diese Ziele in einem umkämpften Markt zu erreichen nicht jedoch das Primärziel!
Um diesen Widerspruch aufzulösen, könnte es helfen, drei Ebenen zu differenzieren:
- Das Ziel eines (Wirtschafts-)Unternehmens ist es natürlich, am Markt zu bleiben und möglichst auch noch Gewinn abzuwerfen (in dieser Reihenfolge! Wozu die umgekehrte Priorisierung führt, erleben wir gerade recht schmerzhaft). Es gibt natürlich auch noch Organisationen, die andere Ziele verfolgen, z.B. öffentlicher Dienst, gemeinnützige Organisationen, Parteien, usw.
- Der Existenzgrund einer Organisation muss aber deutlich spezifischer sein — ein Apsekt, den viele Unternehmensberater und Anleger und leider auch manche Manager gerne übersehen. Der Existenzgrund eines Unternehmens ist das, was in den USA gerne in möglichst blumige „Mission Statements“ gepackt wird. Wenn das nicht nur hohle Phrasen sind („Wir wollen unseren Kunden den besten Service liefern zwischen hier und und dem Neptun…“), drückt sich in ihm die Klammer über die langfrsitigen Strategien aus. Gute Existenzgründe beziehen das Zusammenspiel zwischen Kunden und Unternehmen mit ein. Schöne Beispiele für Existenzgründe sind „Wir wollen unsere Kunden mit Lebensmitteln versorgen, die so billig sind, wie möglich“ oder „Wir wollen eine Lebensmittelversorgung sicher stellen, die unserer Verantwortung gegenüber Kunden, Produzenten und Lieferanten gerecht wird.“ Wie man leicht sieht, sind das zwei völlig unterschiedliche, gegensätzliche Geschäftskonzepte, aus denen sich trotz Gewinnabsicht auf beiden Seiten völlig unterschiedliche Unternehmen und Kundenkreise ergeben.
- Das Projektziel, über das ich geschrieben habe, bezieht sich auf ein konkretes Vorhaben. Der Kunde kann hier ein Vertragspartner sein, wie bei Softwarehäusern, oder eine andere Abteilung, wie bei interner Entwicklung (auch beides gleichzeitig ist möglich, wenn auch oft nicht so wahnsinnig zielführend). Man kann jetzt den Projekterfolg sehr unterschiedlich sehen: „Umfang, Budget, Termin und Qualität erreicht“ ist die traditionelle Definition, „Kunde mit dem Ergebnis hochzufrieden“ ist die agile Definition. Dass die traditionelle Definition besser zu Werkverträgen passt und daher ungeachtet der Probleme mit ihr populär ist, ist schon häufig diskutiert worden.
Der von Felix angesprochene vermeintliche Widerspruch kommt als daher, dass wir über völlig unterschiedliche Ebenen gesprochen haben. Allerdings sind diese Ebenen natürlich gekoppelt. Wenn ich ausschließlich auf kurzfristige Gewinnmaximierung ziele, werde ich versuchen, aus einem Projekt so viel Geld herauszuschlagen, wie möglich, zum Beispiel indem ich es immer weiter aufblase, bis ich 200 billige „Juniorberater“ möglichst mit Tagessätzen erfahrener Leute beim Kunden im Einsatz habe. Für solche Organisationen ist Kundenzufriedenheit in der Tat sekundär, sie akquirieren dann oft eher über Beziehungen (sog. Alumni-Netzwerke, was nicht bedeutet, dass jede Firma, die ein solches Netzwerk betreibt, in diese Kategorie gehört!). Unternehmen, die langfristige Kundenbeziehungen aufbauen, werden allerdings den Kundenutzen sehr hoch priorisieren. „Mir ist relativ egal, ob wir in diesem Projekt rote oder grüne Zahlen schreiben, wenn wir hier erfolgreich sind, stehen wir im gesamten Marktsegment sehr gut da“ ist eine häufige Aussage von Managern, die so denken. Ich glaube, die zweite Sorte von Organisationen wird eher einen Vorteil aus agilen Verfahren ziehen.
Einer anderen Aussagen von Felix möchte ich aber ganz klar widersprechen:
Für die Erreichung der Primärziele Existenzsicherung/Rentabilität sind die Kosten der entscheidende Faktor
Das ist eine zwar sehr moderne aber dennoch fatale Einengung des unternehmerischen Handlungsspielraums. Eine rigide Kostenkontrolle ist dann sinnvoll und notwendig, wenn ich eine Kostenstrategie fahre. Wer eine Differenzierungsstrategie fährt, oder eine Nischenstrategie, kann oft mit seinen internen Kosten deutlich entspannter umgehen (siehe dazu Buchtipp unten). Gerade wegen der von Felix angesprochenen Probleme, Motivätion und Qualität in die Kostenrechnung zu integrieren, ist es bei solchen Unternehmen oftmals kontraproduktiv, zu sehr auf der Kostenbremse zu stehen. Tom DeMarco diskutiert das ausführlich in seinem „Peopleware“ und leitet die Diskussion ein mit einem Memo, das der Vizepräsident von Xerox einst an seine Mitarbeiter verschickte: „It has come to my attention, that some of you, when traveling on expenses, have been traveling economy class. This is a first-class organisation. When you fly on business from now on, you fly first class.“ (s. 153) Gut das war in den frühen Siebzigern. Andererseits war genau das die Zeit, in der Xerox die besten Beiträge zur Software geleistet hat (Smalltalk, Maus, Fensteroberfläche,…).
Ist das Zufall? Ich denke, es hat etwas mit Attitüde zu tun. Wer sich nur auf die Kosten konzentriert, bringt damit ein klares Wertesystem zum Ausdruck. Wer, wie der Chef bei Xerox, klar macht, dass ihm die Arbeitsbedingungen der Mitarbeiter so wichtig sind, dass er bereit ist, dafür Geld auszugeben, ebenfalls. Zur Kostenführerschaft passt das erste Wertesystem, zu den anderen Strategien eher das zweite. Leider sind viele erstklassige Unternehmen von ihrem Management in die Mittelmäßigkeit gedrängt worden, indem sie diesen Unterschied nicht beherzigt haben.
Auf die Gefahr hin, mit Standardlektüre zu langweilen, noch schnell die zwei Quellenangaben dazu:
- Michael Porter: Wettbewerbsvorteile, Campus 1996, ISBN 3-593-34144-1 gilt als das Standardwerk zu Marktstrategien
- Tom DeMarco, Timothy Lister: Peopleware, Dorset House 1987, ISBN 0-932633-05-6 sollte man zumindest einmal in seinem Leben gelesen haben
Nachruf auf eine Staatspartei
Nun ist er also da, der bayerische Weltuntergang, der nach Darstellung der wahlkämpfenden CSU-Mitglieder unmittelbar auf den Verlust der absoluten Mehrheit im bayerischen Landtag folgen würde. Wie wenig die CSU verstanden hat, was ihr da passiert ist, lässt sich wunderbar aus den Stellungnahmen der verschiedenen mehr oder weniger Spitzenpolitikern ablesen. Da überwog die „Analyse“ man habe die gute Regierungsarbeit nicht an die Wähler vermitteln können – ein üblicher Euphemismus dafür, dass die Wähler eigentlich zu dumm dafür sind, das segensreiche Wirken der Staatspartei zu bewerten. Und der Vizechef der „Christlich Sozialen Arbeitnehmer“, Konrad Kobler, versteigt sich laut Süddeutscher Zeitung sogar zu der Feststellung „Die CDU-Chefin [Angela Merkel] habe die Landtagswahl mit ihrem Nein zu einer Rückkehr zur alten Pendlerpauschle ‚vermasselt'“. So einfach ist das: Wenn die CSU nur ein paar Milliarden Steuergelder mehr hätte verschenken dürfen, hätte die Wähler schon wieder fleißig gewählt, wie „man“ das halt von „anständigen Bayern“ erwartet, nämlich CSU.
Man scheint noch nicht auf die Idee gekommen zu sein, dass die Wähler die Nase schlichtweg davon voll hatten, für dämliches Stimmvieh gehalten zu werden, dass man die Zukunft der Kinder nicht weiter einem erstarrten bürokratischen Schulsystem opfern wollte und dass der an Missachtung des Parlaments grenzende Umgang mit der Opposition nur noch von Arroganz und Abgehobenheit zeugte. Wie wichtig der CSU der einzelne Wähler war, konnte ich selbst feststellen: Auf meine Anfrage an den örtlichen CSU Kandidaten Markus Blume, wie er denn als Landtagsabgeordneter seinen Einfluss auf Bundeszuständigkeiten auszuüben gedenke, um sein „Steuerkonzept“ umzusetzen („Volle Pendlerpauschale, mehr Kindergeld, niedrigere Steuern — Dafür setze ich mich ein.“), welche landespolitischen Position er denn vertrete und auf welche Art die unter dem Slogan „Mehr Netto für Alle“ angekündigten Steuergeschenke denn gegenfinanziert werden sollten, warte ich noch heute auf Antwort…
Man darf aber das Ergebnis auch nicht überinterpretieren: Vom Zusammenbruch des CSU-Nimbus haben fast ausschließlich Freie Wähler und FDP profitiert, die Stimmen sind also innerhalb des sog. „bürgerlichen Lagers“ geblieben. Bayern ist und bleibt strukturkonservativ. Eine von den Grünen in die Diskussion geworfene Viererkoalition aus Parteien und Gruppen, die durch kaum mehr zusammen zusammen gehalten wird, als dem Wunsch nach dem Ende der CSU Alleinherrschaft, hätte kaum eine Chance eine Legislaturperiode zu überleben. Und man sollte auch nicht aus den Augen verlieren, dass die Landtagsmehrheit nur eine von mehreren Stützen der CSU Herrschaft in Bayern war, wenn auch eine meistens recht bequeme. Die Durchwirkung von Verwaltung und Wirtschaft wird die CSU über viele Jahre hinaus noch zur führenden politischen Kraft in Bayern machen. Und auch die an die Grenze seriösen Journalismus‘ reichende Willfährigkeit des Bayerischen Fernsehens, die in der gestrigen Wahlberichterstattung einmal wieder zur Schau gestellt wurde, wird uns noch lange erhalten bleiben. Aber die Demokratisierung Bayerns und hoffentlich auch die der CSU hat ja gerade erst begonnen.
Übrigens lässt sich der Weltuntergang zumindest in München ganz gut an: Strahlender Sonnenschein lässt an der bisher nie hinterfragten Höchsten Unterstützung für die Staatspartei zweifeln. Kann es sein, dass der Weltuntergang nur für jene stattfindet, deren Horizont nur bis zu den Grenzen ihrer Partei geht?
Ist agile Entwicklung billiger?
Eine der Standardfragen zu agiler Entwickung lautet: „Können Sie denn nachweisen, dass das billiger ist, als traditionelle Vorgehensweise?“
Der Frage liegt ein interessantes Bild zugrunde, nämlich dass es auf der einen Seite ein Projekt gäbe, also ein definiertes Ergebnis, auf der anderen Seite einen Prozess, der auf einer völlig anderen Dimension steht und das Ergebnis nicht beeinflusst.
Dieses Bild spiegelt die Realität der Softwareentwicklung leider nicht so ganz vollständig wider: Agile Teams entwickeln die fachliche Lösung in enger Zusammenarbeit mit den Fachexperten. Das tun sie nicht, weil sie zu faul oder unfähig wären, Pflichtenhefte, Lastenhefte und Spezifikationen zu schreiben (die meisten Agilisten, die ich kenne, können das deutlich besser, als der Durchschnitt), sondern weil sie überzeugt sind, auf diese Weise ein fachlich und wirtschaftlich besseres Ergebnis zu erhalten.
Das bedeutet auf jeden Fall, dass das Ergebnis anders sein wird, als mit traditioneller Vorgehensweise. Nur die Kosten zu vergleichen, vergleicht also Äpfel mit Birnen. Wer noch dazu Schätzungen vergleicht, statt der Gesamtkosten über die Lebenszeit des Softwaresystems, vergleicht auch noch mit Birnen, deren Bäume noch nicht einmal gepflanzt sind — in der Regel auf Böden, von denen man nicht einmal weiß, ob da Obstbäume überhaupt gedeihen.
Ist das jetzt der Versuch, sich einem „objektiven“ Vergleich zu entziehen? Ganz im Gegenteil, wir sollten nur die richtigen Parameter vergleichen: Kundenzufriedenheit, weil das das Primärziel jedes Projekts sein sollte, und Motivation des Teams, weil damit die Investition in Ausbildung und Aufbau des Teams, der Kundenbeziehung und des Wissens geschützt wird. Bei beiden Kriterien schneidet agile Entwicklung in allen mir bekannten Untersuchungen signifikant besser ab, als traditionelle Verfahren (auch wenn es natürlich Ausreißer gibt).
Wem das zu „unwissenschaftlich“ ist, der wird nicht um die Mühe herum kommen, zwei Teams an die gleiche Aufgabe zu setzen und unter wirklich vergleichbaren Bedingungen Kosten und Nutzen zu vergleichen. Leider habe ich bisher noch niemanden gefunden, der es dann doch so genau wissen wollte und bereit gewesen wäre, das Geld dafür in die Hand zu nehmen. Und das wäre natürlich auch nur ein einzelnes Projekt, das nicht repräsentativ wäre, und keinerlei „wissenschaftlich fundierte“ Aussage zulassen würde…
Gunter Dueck zur Konstruktion von Prozessleichen
Auch auf die Gefahr hin, dass mein Blog zu einer Dueck-Fanseite verkommt: Der aktuelle Daily Dueck ist einfach zu gut! Gunter Dueck vergleicht die Konstruktion eines neues Geschäftprozesses mit dem Zusammenbau von Leichen in Frankensteins Labor — und kann die Metapher erschreckend weit treiben!
Lasst Prozesse wachsen und konstruiert sie nicht an der virtuellen Powerpointmaschine, ist seine Nachricht. Und dass das Zeit und Geduld erfordert, wie das Aufwachsen von Kindern.
Richtig verstandene Agilität nutzt dazu Retrospektiven. Leider gibt es immer mehr falsch verstandene „Agile Prozesse“, die genau diesen Aspekt vergessen und eben einen „agilen“ Prozess konstruieren wollen. Die Versuchung ist enfach zu groß. Gunter Duecks Polemik verdeutlicht sehr schön, wo das endet:
Gunter Dueck: „Konstruktion von Prozessleichen und das Fehlen von Blut und Atem„