Archiv der Kategorie: Agilit

Refactoring-Seminar in München am 21./22.7.

Veröffentlicht am von

Die Aufbauarbeiten am OBJEKTspektrum haben ihre Spuren hinterlassen: Der Blog musste ein wenig ruhen und wird erst jetzt wieder langsam aufgeweckt:

Am 21./22. Juli (Mo/Di) halte ich in München gemeinsam mit SIGS Datacom das Seminar „Refactoring in der Praxis oder Die Kunst schmerzfreier Änderungen„. Die Teilnehmer werden in dem Seminar ein Stück völlig unlesbaren Codes Schritt für Schritt so weit refaktorisieren, dass eine erste Architektur entsteht. Die dabei angewendeten Strategien arbeiten wir natürlich auch sauber auf und unterfüttern sie mit allem, was man braucht, um sie im Projekt anzuwenden und um sich selbst weiter einzuarbeiten.

Technisch arbeiten wir in Java auf Eclipse, es sind aber keine tiefen Java-Kenntnisse erforderlich. Die Strategien lassen sich ohne weiteres auch auf C# oder C++ abbilden – allerdings leider mit unterschiedlich großem manuellem Aufwand. Bei Bedarf sprechen wir auch über die spezifischen Probleme in diesen beiden Sprachen.

Die Teilnehmer des letzten Durchgangs haben den Kurs mit einer glatten Eins bewertet.

Anmelden können Sie sich über http://www.sigs-datacom.de/sd/seminare/evt_seminar_show.htm?&TABLE=sd_product&PID=1087

Kommen Projekte ohne Architektur aus?

Veröffentlicht am von

Ich höre immer wieder den Vorwurf an Teams, die mit XP arbeiten, sie hätten „keine Architektur“. Das halte ich für eine fundamentale Fehlinterpretation des Begriffs „Architektur“. Jedes Programm hat eine Architektur. Die mag adäquat sein, oder nicht, sie mag explizit dokumentiert sein, durch Tests abgesichert sein, oder unbewusst entstanden. Aber immer gibt es eine Architektur.

Die Vorstellung, man müsse eine Architektur explizit vor Beginn der Realisierung dokumentieren, damit sie kontrollierbar bleibe, halte ich ebenfalls für falsch. Ich habe viele Architekturdokumentationen erlebt, die zwar nett aussahen, mit der realen Architektur aber höchstens noch rudimentäre Ähnlichkeit besaßen. Umgekehrt habe ich exzellente Architekturen erlebt, die nirgends explizit dokumentiert waren. Sie waren höchstens durch Unit Tests und Mockobjekte abgesichert.

Wenn es um den wirtschaftlichen Nutzen einer Architektur geht, zählt die reale Architektur im Code. „Architekturen“, die nur auf der virtuellen Powerpointmaschine existieren und nichts mit dem real existierenden Code zu tun haben, sind wertlos. Ich habe eindrucksvolle und gut funktionierende Architekturen gesehen, die in traditioneller Technik zu Projektbeginn entworfen wurden. Gerade in XP Projekten entstehen aber auch immer wieder ausgezeichnete Architekturen ohne den großen ersten Wurf.

Architektur und Agilität

Veröffentlicht am von

Will man einmal richtig Spaß haben, so werfe man in eine Gruppe von „Agilisten“ und „Traditionalisten“ das Stichwort „Architektur“: Als hätte man ein Zündholz in einen Strohhaufen geworfen entflammt sofort eine äußerst emotionale Diskussion, deren Randbereiche zwei Statements markieren: „Ohne eine saubere Anfangsanalyse und solide Anfangsarchitektur kommt kein ernsthaftes Projekt aus“ und „Wir brauchen keinen Architekten, die Architektur entsteht beim Programmieren“. Zwischen diesen beiden Extremen findet man fast jede denkbare Zwischenposition.

Ich habe viele dieser Diskussionen verfolgt und bin mittlerweile zu dem Schluss gelangt, dass hier mindestens drei verschiedene Themen munter durchmischt werden:

  • Wann wird die Architektur erstellt? Ist die Architektur eine eigene Phase zu Projektbeginn, wird sie zu Beginn jeder Iteration erstellt, oder entsteht Sie während des Programmierens durch Refaktorisieren?
  • Wie wird die Architektur repräsentiert? Existiert ein eigenes Dokument oder repräsentiert der Code die Architektur — wobei dann oft Werkzeuge eingesetzt werden, um grafische Darstellungen aus dem Code zu extrahieren und wichtige Eigenschaften zu prüfen, zum Beispiel automatisierte Test, um Abhängigkeiten zu prüfen.
  • Wer ist für die Architektur verantwortlich? Gibt einen oder mehrere Architekten? Als Entscheider oder als Moderatoren? Oder ist das Entwicklungsteam gemeinsam verantwortlich?

Ich denke, auf welche „Seite“ man sich bei diesen drei Fragen schlägt, hängt entscheidend von der Frage ab, was man sich von der Architektur erwartet. Die Antwort darauf wird oft stillschweigend als „selbstverständlich“ vorausgesetzt, ohne zu sehen, dass dort der eigentliche Konflikt liegt:

In traditioneller Sicht soll die Architektur Änderungen an bestehendem Code vermeiden. Sie sollte also so flexibel sein, dass zukünftige oder absehbare Anforderungen möglichst schon abgedeckt sind und ohne Änderungen an bestehendem Code oder zumindest der Architektur implementiert werden können. Architektur versucht die zukünftige Entwicklung vorauszusehen.

In agiler Interpretation soll Architektur Änderungen des Codes und ihrer selbst ermöglichen. Eine gute Architektur kann schnell an neue funktionale und nicht-funktionale Anforderungen angepasst werden. Sie ermöglicht möglichst viele zukünftige Entwicklungen. Änderbarkeit ist daher das Leitmotiv agiler Praktiken wie einfaches Design, testgetriebene Entwicklung, Refaktorisieren und Redundanzvermeidung.

Steht man auf dem Standpunkt, Änderungen an der Architektur seien schlecht und zu vermeiden, so wird man fast zwangsläufig zu dem Ergebnis kommen, dass die Architektur vor der Realisierung von einem starken Architekten erstellt werden müsse und daher nicht im Code repräsentiert werden kann.

Sieht man Änderungen als willkommenes Designwerkzeug, kann man die drei Fragen deutlich entspannter angehen. Die Antworten können sich nach anderen Faktoren richten, wie Kritikalität, Team- und Führungskultur und Erfahrung in der Domäne. Fast alle Kombinationen sind hier möglich; viele von ihnen auch in bestimmten Situationen sinnvoll.

In meinen Projekten kamen einige Teams ohne Architekten aus, andere ernannten irgendwann ein Mitglied zum Hüter der Architektur. Immer waren durch Refaktorisieren entstehende Architekturen in fast allen Qualitätsmerkmalen den zu Beginn erstellten Architekturen deutlich überlegen — und dazu auch noch wesentlich billiger. Zudem halte ich mir gerne Optionen offen.

Cutter Report „Fostering Innovation on the Agile Frontier“

Veröffentlicht am von

Im letzten Jahr habe ich die Ausgaben Mai und Oktober des Cutter IT Journal als Gasteditor herausgegeben. Die Maiausgabe beschäftigte sich unter dem Titel „Exploring the Agile Frontier“ mit dem Einsatz agiler Verfahren außerhalb der „Standardprojekte“, also mit verteilten Teams, bei lebenserhaltenden Systemen und in nicht-agilen Organisationen.

Die Oktoberausgabe hatte den Titel „Fostering Innovation: What Role Does Agile Software Development Play?„. Sie enthielt fünf Beiträge zum Zusammenhang zwischen Innovation und Agilität. Die Thesen verliefen von „Agilität behindert Innovation“ bis zu „Agilität ist die Geburtshelferin der Innovation“.

Aufgrund der großen Nachfrage hat Cutter nun beide Ausgaben zu dem Report „Fostering Innovation on the Agile Frontier“ zusammengefasst.

7 Jahre Agiles Manifest im „Tonabnehmer“

Veröffentlicht am von

Frank Westphal hat in seinem Podcast „Tonabnehmer“ den fünfzehnten Beitrag dem siebenjährigen Jubiläum des Agilen Manifests gewidmet. In diesem einstündigen Beitrag diskutieren Jutta Eckstein, Johannes Link, Henning Wolf und ich über die Auswirkungen des agilen Manifests auf die Branche, auf uns persönlich und auf die Zukunft. Hören Sie den Beitrag unter http://www.frankwestphal.de/Tonabnehmer15-JuttaEckstein-JohannesLink-JensColdewey-HenningWolf-7JahreAgilesManifest.html.

Veröffentlicht unter Agilit

Workshop „Einführung in agile Entwicklung“ in Bern

Veröffentlicht am von

Vielleicht gehören Sie zu denen, die einiges zu agiler Entwicklung gelesen haben, die manches interessant finden, anderes eher skeptisch sehen und die im Großen und Ganzen noch nicht so recht wissen, was Sie davon halten sollen. Wenn Sie Lust haben, einen Tag dafür zu investieren, agile Entwicklung zu erleben, sollten Sie darüber nachdenken, am 28. April zur SEE 2008 in Bern zu kommen.

Sie haben dort Gelegenheit, agile Techniken zu erleben und zum Teil auch auszuprobieren. Gemeinsam mit Bernd Schiffer von it-agile werde ich die Grundlagen agiler Entwicklung vorstellen, Sie werden ein „Mini-Projekt“ selbst mit agilen Managementtechniken durchführen und können am praktischen Beispiel verfolgen, wie testgetriebene Entwicklung und Refaktorisieren in der täglichen Arbeit ablaufen.

Nähere Informationen finden Sie unter http://www.see-conf.de/workshop_agile.html

Gedanken zur Ressourcenplanung

Veröffentlicht am von

Gestern hat Siemens eine Gewinnwarnung über 900 Mio Euro veröffentlicht. „In der Vergangenheit habe man sich mit Großaufträgen übernommen und mehr Aufträge angenommen, als der Konzern abarbeiten konnte“ berichtet die Süddeutsche Zeitung in ihrer heutigen Ausgabe über ein wichtige Ursache für die Warnung (SZ vom 18.3.2008, S. 19). Sich mit Aufträgen zu übernehmen gehört sicher zu den häufigsten Managementfehlern in Unternehmen jeder Größe. „Droht“ ein Kunde mit einem Auftrag und stellt auch noch Bezahlung dafür in Aussicht, ist die Versuchung groß, sich die internen Kapazitäten und ihre Auslastung schön zu rechnen. Trifft das auf eine Kultur, in der Risikobewusstsein als mangelnde Einsatzbereitschaft fehlgedeutet wird („Das müssen Sie als Chance begreifen“) und wird der Vertrieb mit Provisionen „motiviert“, die ignorieren, ob das Verkaufte auch geliefert werden kann, ist die Katastrophe schon fast vorprogrammiert.

Wer Software erstellt, kann agile Planung einsetzen, um dieses Risiko zu vermindern: Weiterlesen →

Praktiken II: Automatisierte Akzeptanztests

Veröffentlicht am von

Nach längerer Zeit nun der zweite Teil meiner Serie über agile Prakitken. Bisher finden Sie in dieser Kategorie die folgenden Einträge:

Der zweite Teil beschäftigt sich mit automatisierten Akzeptanztests:

Auch agile Entwicklung startet mit den fachlichen Anforderungen. Allerdings werden sie direkt als Akzeptanztests aufgeschrieben, statt in Anforderungsdokumenten. Akzeptanztests sind fachliche Beschreibungen dessen, was das System können soll und zwar so, dass sie automatisch ausgeführt werden können. Automatisch ausführbare Tests steuern die Anwendung und überprüfen deren Ergebnisse ohne menschlichen Eingriff. Der Weg zu diesen Akzeptanztests ist noch eher uneinheitlich, man geht aber in der Regel von den geplanten geschäftlichen Abläufen aus (siehe dazu auch „Use Cases oder User Stories„).

Weiterlesen →

Ideen zu Mini-Retrospektiven

Veröffentlicht am von

Nicht immer ist eine vollständige Retrospektive das Mittel der Wahl: Der Aufwand ist beträchtlich und daher oft zu groß, um jeden Monat eine Retrospektive zu machen. Ilja Preuß stellt in seinem Blog-Eintrag A Lightweight Appreciative Retrospection eine Kurzvariante vor, die mit wenigen Stunden auskommt. Ich habe diese Variante selbst noch weder erlebt, noch ausprobiert, die Beschreibung klingt aber vielversprechend.

Natürlich ersetzt eine Mini-Retrospektive keine „große Retrospektive“ in regelmäßigen Abständen, aber für kleine Projekte, oder als „Zwischen-Retro“ ist sie durchaus eine Überlegung wert.