Archiv für den Monat: November 2007

SEE 2008 auf der Suche nach agilen Beiträgen!

Veröffentlicht am von

Ende April 2008 findet in Bern die SEE 2008 statt, eine Konferenz über die „Software Engineering Essentials“. Ziel der Konferenz ist es, ein „Forum für den Austausch zwischen dem Lager der leichtgewichtigen, agilen Entwicklungsprozesse und den Vertretern reichhaltiger Vorgehensmodelle“ zu schaffen, so der Initiator der Konferenz, Andreas Rausch. Um dieses Ziel zu unterstützen, haben sowohl Jutta Eckstein als auch ich unsere Mitarbeit im Programmkomittee zugesagt. Aber das reicht natürlich noch nicht: Um nicht (wie letztes Jahr in München) in die Verlegenheit zu geraten, dass Agilität nur ein Nischenthema zwischen V-Modell XT, SPICE und CMMI bleibt, sondern seine Gegenposition auch klar beziehen kann, brauchen wir von Agilisten Beiträge, Beiträge, Beiträge!

Die Erfahrungen im letzten Jahr haben gezeigt, dass die wenigen Beiträge, die zum Thema Agilität eingericht wurden, recht hohes Niveau hatten und auch die Diskussion im Programm Kommitee habe ich als durchaus fair empfunden. Also: Einreichungsfirst ist der 3. Januar 2008, näheres dazu im offiziellen Aufruf. Wir sollten die Gelegenheit nicht verpassen, auch die Diskussion mit jenen zu suchen, die (noch) nicht von Agilität überzeugt sind!

Agile Entwicklung bei Google

Veröffentlicht am von

Ich bin gerade in Stefan Hagen’s PM-Blog über einen ganz interessanten Beitrag zum Thema „Wie entwickelt Google“ gestolpert. Das spannendste waren für mich die Projektgrößen: Google rechnet in „Units“, das sind Teams mit drei Personen, die Projektdauer beträgt drei bis vier Monate. „Große“ Projekte bestehen zum Beispiel aus vier Units, also zwölf Personen. Da hat jemand wirklich verstanden, wie man Projekte klein macht.

Wer meint, solche Projekte seien nicht ernst zu nehmen, werfe noch kurz einen Blick auf den Aktienkurs und die wirtschaftliche und gesellschaftliche Bedeutung von Google weltweit.

Über meine Signatur

Veröffentlicht am von

Nachdem ich immer wieder auf das Michael Stipe Zitat in meiner E-Mail Signatur angesprochen werde („I don’t believe and never did, that two wrongs make a right“), hier ein paar Hintergründe über das Zitat und warum ich es verwende: Die Zeile stammt aus dem Lied „The Final Straw“ von der CD „Around the Sun“ (2004). Der Song wurde wenige Tage nach dem Beginn des zweiten Golfkriegs von R.E.M. im eigenen Studio aufgenommen und sofort auf die Homepage gestellt – als Protest gegen den Krieg und gegen Bush. Den vollständigen Text findet man z.B. unter http://www.azlyrics.com/lyrics/rem/finalstraw.html.

Ich habe mich damals spontan entschieden, die Zeile in meine Signatur zu übernehmen. Neben dem Protest war mir wichtig, eine amerikanische Stimme sprechen zu lassen, stellvertretend für all meine Freunde und Kollegen in den USA, die ähnlich denken, wie Stipe. Und die wie die meisten Deutschen die Tage zählen, bis der Spuk vorbei ist.

„Damit sind nicht alle unter Dampf“ – Übergang zu agiler Planung

Veröffentlicht am von

„Die Planung ist ja ganz nett, aber einige hier sind jetzt überlastet und andere haben nichts zu tun.“ Diese Aussage hört man mit Sicherheit irgendwann, wenn man ein Team auf agile Planung umstellt. Zur Erinnerung: Bei agiler Planung versucht man nicht, sämtliche „Ressourcen“ voraus zu planen, sondern sammelt Arbeitspakete mit direktem Geschäftsnutzen (in der Regel in Form sogenannter Anwender Geschichten oder User Stories) und priorisiert sie vollständig. Die Pakete werden geschätzt und der Umfang abgeschöpft, der in dem Monat geleistet werden kann. So wird immer an den wichtigsten Aufgaben gearbeitet.

In der besten aller agilen Welten funktioniert das auch: Wenn das Team von Anfang an konsequent die Entscheidungen im Team getroffen hat und immer in Paaren gearbeitet hat, ist das Wissen über das System ungefähr gleich verteilt und jeder kann jede Aufgabe übernehmen. Wenn man allerdings ein bestehendes Vorhaben (oder Produkt) auf Agilität umstellt oder die Entstehung von Kopfmonopolen toleriert hat, wird man die daraus entstehenden Probleme spätestens bei der Planung bemerken.

Zunächst möchte ich betonen, dass dies kein Problem der Planung ist, sondern Symptom für ein anderes Problem: Wenn man einmal voraussetzt, dass die Prioritäten richtig gesetzt sind, ist das Grundproblem hier die mangelnde Flexibilität im Team. Oft haben sich Kopfmonopole gebildet, die von den einzelnen Entwicklern nur ungern verlassen werden – Schließlich sichert einem das Kopfmonopol Bedeutung und Anerkennung. Es kann aber auch inhaltliche Gründe geben, solche Kopfmonopole zu erzeugen. Zum Beispiel kann es aus Sicherheitsgründen sinnvoll sein, wenn nur wenige Entwickler über bestimmte Kernkonzepte informiert sind. Und auch im Kundenkontakt sind viele Kunden (mich eingeschlossen!) dankbar, wenn sie feste Ansprechpartner haben und nicht wie im Call-Center von Pontius zu Pilatus weiter gereicht werden. Aber abgesehen von solchen Spezialfällen sind Kopfmonopole ineffizient und sollten abgebaut werden.
Weiterlesen →

Refactoring von C++

Veröffentlicht am von

Programmiersprachen spielen keine wesentliche Rolle habe ich einst gelernt, es kommt vor allem auf die Qualität der Entwickler an. Diese Aussage stammt aus den frühen 80er Jahren, als Barry Boehm sein „Software Engineering Economics“ veröffentlicht hat. Und tatsächlich kann die beste Programmiersprache der Welt wenig ausrichten, wenn das Team inkompetent ist – und ein kompetentes Team wird auch mit altertümlichen Programmiersprachen noch etwas ausrichten können. Also alles in Butter? Gebt mir eine turingvollständige Sprache und ich wuppe Euch das Projekt? Wohl kaum.

Nur in wenigen Bereichen hat sich so viel in den letzten 25 Jahren verändert, wie bei Programmiersprachen und ihren Entwicklungsumgebungen. In den frühen 80ern hatte man im Wesentlichen noch die Auswahl zwischen C, COBOL, Pascal, PL/I und Assembler und bei den Entwicklungsumgebungen die Wahl zwischen vi, emacs und dem Host-Editor. Heute führen die Unterschiede zwischen den verschiedenen Sprachen und Umgebungen durchaus zu Produktivitätsunterschieden von einer Größenordnung, also um den Faktor 10; beim gleichen Team, wohlgemerkt.

Besonders fallen mir diese Unterschiede auf, wenn ich – wie heute einmal wieder – einem Kunden beim Umbauen einer C++ Anwendung helfe. Zur Erinnerung: C++ war der Versuch, dem guten alten C einige Konzepte überzustülpen, die bei flüchtiger Betrachtung als objektorientiert verkauft werden konnten. „Die C-Programmierer müssen dann nicht umlernen“ war die häufigste Begründung für diese Sprache. Ohne das belegen zu können, vermute ich, dass genau dieser Umstand – unreflektierter Einsatz objektorientierter Techniken von Programmierern, die nur in prozeduraler Programmierung ausgebildet sind – zu den häufigsten technischen Gründen für gescheiterte Projekte zählt.
Weiterlesen →

Daten sammeln und Daten verlieren

Veröffentlicht am von

Gestern ging die Meldung durch die Zeitungen, den britischen Steuerbehörden seien wieder einmal sechs CDs mit persönlichen Daten von Steuerpflichtigen abhanden gekommen. Schon letzte Woche war gemeldet worden, dass zwei CDs mit den persönlichen Daten aller Kindergeldempfänger in Großbritannien verloren gegangen sind – inklusive Bankverbindungen und der Social Security Number, der in angelsächsischen Ländern allgegenwärtigen Identifikationsnummer. Betrüger und Kriminelle können mit diesen Daten weitreichenden Schaden anrichten, vermutlich bis hin zu unberechtigten Zugriffen auf die Konten der Betroffenen.

Bei der derzeitigen Datensammelwut der Behörden möchte man sich gar nicht ausmalen, wie solche Meldungen in Zukunft aussehen: „DVDs mit sämtlichen Surfdaten der Stadt verloren gegangen“ – „Richter wegen Seitensprungs erpresst – gestohlene Handydaten wurden ihm zum Verhängnis“ – „Ausländischer Geheimdienst erpresst Politiker nach Besuch auf schwulen Webseiten“.

Eine Grundregel des Datenschutzes besagt, sowenig Daten zu erfassen, wie möglich. Die aktuellen Pläne von Bundesregierung und EU Kommission sprechen dieser Regel Hohn. Die Rundumerfassung des elektronischen Kommunikationsverhaltens (Vorratsdatenspeicherung für 6 Monate), des Reiseverhaltens (Flugdatenerfassung von Reisen in und aus der EU für voraussichtlich 12 Jahre) und möglicherweise auch des Straßenverkehrs (elektronische Erfassung der Fahrzeugkennzeichen) gefährden unseren Rechtsstaat, unsere Demokratie und letztlich unsere Gesellschaftsordnung. Sie vollendet das, was weder die RAF noch islamistische Terroristen vermocht haben: Die Errungenschaften der letzten 60 Jahre zu zerstören. Daher schließe ich mich auch der Verfassungsbeschwerde des Arbeitskreises Vorratsdatenspeicherung an.

Agilität und Werte

Veröffentlicht am von

Wenn ich schon über Agilität und Religion philosophiere (und mich damit weit außerhalb meines Kompetenzgebietes wage), noch ein paar Gedanken zum Wertesystem agiler Entwicklung. Manch ein Manager und auch Beobachter empfindet die Festlegung eines „Agiles Wertesystems“ als befremdlich. Warum muss man zunächst ein „Agiles Manifest“ aufsetzen? Ist das nicht doch nur Marketing? Oder gar Religion?

Ein Kerngedanke agiler Verfahren ist ihre Adaption, also die Möglichkeit und Notwendigkeit, sie anzupassen. Diese Anpassung führt immer wieder zu Konflikten. Das agile Manifest gibt eine Grundlage, um bei Konflikten entscheiden zu können. Es fasst sozusagen die „Essenz“ aller agilen Verfahren zusammen. Und es hilft, die unvermeidlichen Trittbrettfahrer von denen zu unterscheiden, die wirklich neue Ideen und Ansätze beizutragen haben.

Das agile Manifest ist mehr als nur Philosophie. Es stellt Grundlage und „Leitplanken“ für die Anpassung dar. Übrigens lohnt es sich, auch mal eine Seite weiter zu klicken, zu den „Prinzipien agiler Software Entwicklung„.

Veröffentlicht unter Agilit

Agilität und Religion

Veröffentlicht am von

Bei einer Vortragsveranstaltung äußerte neulich ein Vertreter traditioneller Methoden, der Streit um agile Entwicklung (welcher Streit eigentlich?) erinnere ihn an Religionsstreitigkeiten. Nun, Erinnerungen und Asoziationen sind sehr persönlich und widersetzen sich einer Bewertung.

Ein kleiner Gedanke sei mir aber erlaubt: Das schöne an Agilität – verglichen mit Religion und Esoterik – ist der Umstand, dass man nicht an sie glauben muss, damit sie funktioniert. Man braucht sie einfach nur zu betreiben.

Veröffentlicht unter Agilit

XPDays 2007 – Eindrücke

Veröffentlicht am von

Im Zug von Karlsruhe nach München scheint mir eine gute Gelegenheit, meine Eindrücke von den gerade beendeten XPDays 2007 in Karlsruhe aufzuschreiben. Ich bin da sicher nicht neutral – schließlich war ich im Programm Komitee nicht völlig unbeteiligt an der Struktur der Konferenz. Dennoch freue ich mich über das gute Gelingen, an dem neben dem diesjährigen Ausrichter andrena sicher auch Johannes Link die „Hauptschuld“ trägt. Bei der Qualität des Programms und sympatischen Durchführung ist es kein Wunder, dass sich die XPDays im vierten Jahr zu der agilen Konforenz in Deutschland gemausert haben. Zu Recht.
Weiterlesen →