Agile/Extreme Programming (XP) and User Interfaces
Die Basis - das agile Manifest
2001 haben sich eine Gruppe von Softwareentwicklern während eines gemeinsamen Skiwochenendes zur sogenannten "Agile Alliance" zusammengeschlossen. Während dieses Wochenendes entstand das Agile Manifest, das Grundlage für viele Methodenansätze unter anderem auch dem Extreme Programming (XP) ist. Im Folgenden sind einige Prinzipien aus dem Manifest zitiert, die die Idee dahiner in Kürze beschreiben sowie ihren Bezug zur heutigen Situation in der Arbeitswelt aufzeigen:
"Unsere höchste Priorität ist es den Kunden durch frühe und kontinuierliche Herausgabe von nutzbarer Software zufrieden zu stellen." Ein großes Problem vieler Softwarehersteller ist es im Moment die gewünschte Software in den ausgemachten Zeitrahmen tatsächlich fertig zu stellen. Dies führt zu vielen Problemen zwischen Kunde und Hersteller, aber auch innerhalb der Herstellerfirma.
"Änderungen in den Anforderungen, auch gegen Ende des Projekts, willkommen zu heißen." Gerade gegen Ende eine Projekts ist der Stresslevel und der Zeitdruck meist sehr hoch, so dass zu diesem Zeitpunkt auftauchende Änderungen aus Zeitmangel ignoriert werden müssen.
"Ökonomen und Entwickler müssen während eines Projekts täglich zusammenarbeiten." Oft haben die verschiedenen Abteilungen vor allem in größeren Firmen keinen Einblick in die Arbeit außerhalb ihres Bereiches.
"Baue Projekte auf motivierte Individuen auf. Gib ihnen die Umgebung und Unterstützung, die sie brauchen und vertraue ihnen." Vertrauen in die Arbeit anderer ist selten. Oft findet man viele Kontrollmechanismen vor, die den Mitarbeiter eigentverantworliches Arbeiten verwehren.
"Einfachheit, das heißt Konzentration auf das Wesentliche, ist essentiell." Es passiert schnell, dass noch zusätzliche Features ins Software integriert werden, die zwar nicht bestellt waren, aber eben einfach möglich.
"In regelmäßigen Intervallen soll das Team darüber nachdenken, wie es effektiver arbeiten kann und dann sein Verhalten dementsprechend anpassen." Oft haben sich bestimmte Abläufe und Verhaltensmuster eingebürgert, die nicht unbedingt effizient sind, aber nie hinterfragt werden.
Einiges davon klingt als wäre die agile Bewegung gegen Methodik und für freie Entfaltung (Chaos) in der Softwareentwicklung. Das stimmt so nicht. Sie wollen lediglich erreichen, dass im Softwareentwicklungsprozess wieder Balance zwischen Planung, Dokumentation und der eigentlichen Hauptaufgabe, funktionierenden Code zu erstellen, herrscht. Dazu setzen sie den Schwerpunkt auf die Programmierung in kurzen Iterationszyklen mit bereits verwendbaren Ergebnissen, auf gut dokumentierten Code statt einer zusätzlichen Dokumentation, auf die Annerkennung von Planungsgrenzen und den damit einhergehenden Änderunen und der engen Zusammenarbeit zwischen Kunden, Ökonomen und Entwicklern.
Extreme Programming (XP) - was ist das?
Überblick
XP ist ein agiler Softwareentwicklungsprozess bzw. ein Vorgehensmodell für die Softwareentwicklung, das auch menschliche Aspekte wie der Wunsch nach Sicherheit, Vollendung, Identifikation mit der Gruppe, Perspektive und Verständnis mit einbezieht, da es Menschen sind, die die Software entwickeln. Extrem ist es in dem Sinne, dass es 12 bekannte "best practices" aus der Softwareentwicklung nimmt und aus ihnen ihre logischen Extreme zieht und diese in XP verwendet. Es eignet sich besonders für kleine bis mittlere Teams. Entwickelt wurde XP von Ward Cunningham und Kent Beck, beide Mitglieder der Agile Alliance, die vertieft im Bereich objektorientierter Systementwicklung arbeiten. Ziel von XP ist es alle beteiligten Gruppen im Team, das heißt Kunden, Programmieren und Ökonomen zufrieden zustellen. Dies soll durch eine hohe Produktqualität, frühzeitiges Feedback, effizienten Wissenstransfer im Team sowie Flexibilität und Änderbarkeit der erstellten Systeme erreicht werden. Dafür müssen sich alle Beteiligten diszipliniert an die Vorgaben aus den einzelnen Planungs- und Entwicklungsaktivitäten halten. Für einen reibungslosen Ablauf sind folgende Eigenschaften im Team wichtig: eine gute Kommunikation, Mut, Konzentration auf das Wesentliche, Bereitschaft zu lernen und Respekt untereinander.
Die 12 Basispraktiken von XP
1. Das Planungspiel: es wird immer wieder ausgeführt und läuft jedes mal in folgenden Schritten ab: zuerst bestimmt der Kunde ein gewünschtes Feature, dass er üblicherweise auf einer DinA 6 Karteikarte als Benutzergeschichte beschreibt. Dann schätzen die Entwickler den benötigten Aufwand ab und legen fest, wie viel man bis zur nächsten Freigabe realisieren kann. Zuletzt entscheidet der Kunde welche Features implementiert werden sollen und wann und wie oft es Produktivfreigaben gibt.
2. Kleine Freigabesets: für die erste Freigabe strebt man das kleinstmögliche sinnvolle Featurepaket an. In den weiteren Freigaben werden in kleinen Schritten weitere Features hinzugefügt.
3. Systemmetapher: um eine einheitliche Benennung zu erleichtern, sucht man sich zu Beginn jedes Projekts eine Metapher für die entstehende Software. So haben alle das gleiche Bild vor Augen.
4. Einfaches Design: bei der Implementierung soll man sich auf die einfachste Möglichkeit, die die momentanen Erfordernisse erfüllt, konzentrieren.
5. Beständiges Testen: bevor man das Feature implementiert, schreibt man den passenden Test dazu. Tests gibt es in zwei Formen: zum einen den Unittest, der meist nur eine oder eine kleine Gruppe von Klassen testet. Zum anderen den Acceptance- oder auch Functionaltest, der alles testet, was der Kunde in seiner User Story wünscht.
6. Refactoring: dabei geht es darum jeglichen Code, der doppelt vorkommt, zu kompliziert oder unnötig erscheint, zu entfernen oder zu verbessern. Mit Hilfe der Tests wird überprüfen, ob man das Richtige gelöscht oder richtig verbessert hat.
7. Programmierung in Paaren: die gesamte Implementierung erfolgt mit Paaren von Programmieren an einem Rechner. So kann einer schreiben während der andere Korrektur liest und Zeit hat sich den weiteren Verlauf zu überlegen.
8. Gemeinsamer Codebesitz: von jedem Programmierer wird erwartet, dass er sich in allen Programmteilen auskennt und überall weiterarbeiten kann.
9. Kontinuierliche Integration: das heißt, dass alle Änderungen mindestens auf täglicher Basis in den Gesamtcode eingefügt werden müssen. Dabei muss gewährleistet sein, dass die Tests sowohl vorher als auch nachher 100% korrekt laufen.
10. 40-Stunden Woche: jeder Programmierer kann zu normalen Zeiten nach Hause gehen. Maximal eine Woche mit Überstunden ist erlaubt. Sollte mehr nötig sein, muss die Projektplanung überarbeitet werden.
11. Vor Ort Kunde: der Kunde ist Bestandteil des Teams und steht somit für Rücksprachen zur Verfügung. Bei mehreren Kunden gibt es einen Ansprechpartner, der alle vertritt.
12. Programmierstandards: alle sollen denselben Standard verwenden, so dass beim Lesen des Codes nicht mehr zu sehen ist, wer was geschrieben hat.
Weiterentwicklung: Evolutionäre Praktiken = Hauptpraktiken und ergänzende Begleitpraktiken
Die Evolutionären Praktiken kamen fünf Jahre nach den Basispraktiken raus. Sie sind im Grunde inhaltlich den Basispraktiken entsprechend geblieben. Sie wurden nur feiner unterteilt und die Systemmetapher (sie war schlecht umzusetzen) sowie die Programmierstandars (werden jetzt einfach vorausgesetzt) sind gestrichen worden. Zu den Hauptpraktiken zählen: "Räumlich zusammen sitzen", "Informativer Arbeitsplatz", "Team", "Pair Programming", "Energievolle Arbeit", "Entspannte Arbeit", "Benutzergeschichten", "wöchentlicher Zyklus", "Quartalsweiser Zyklus", "10-Minuten Build", "Kontinuierliche Integration", "Test-First Programmierung" und "Inkrementelles Design". Räumliches zusammen arbeiten und informativer Arbeitsplatz bedeuten, dass das Team nach Möglichkeit gemeinsam in einem Raum arbeitet, in dem alle wichtigen Informationen für alle sichtbar sind. Dafür kann man zum Beispiel die Benutzergeschichten übersichtlich an eine Wand heften. Energievolles und entspanntes Arbeiten kommt durch die geregelten Arbeitszeiten (40-Stunden Woche) und die Pufferzonen, die in die Projektplanung von Anfang mit einkalkuliert werden. 10-Minuten Build steht dafür, dass alle Tests nicht länger als 10 Minuten dauern und Änderungen zeitnah (spätestens alle zwei Stunden) ins System eingefügt werden sollen.
Zu den ergänzenden Begleitpraktiken gehören: "richtige Kundeneinbeziehung", "Inkrementelles Deployment", "Teamkonstanz", "Schrumpfende Teams", "Ursächliche Analysen", "geteilter Code", "Codierung und Testen", "Zentrale Codebasis", "Tägliches Deployment", "Verhandelbarer, vertraglicher Funktionsumfang" und "Zahlen pro Nutzung". In der Umsetzung bedeutet das, dass der Kunde aktiv an der Entwicklung teilnimmt. Durch dieses aktive Einbeziehung ist es leicht den Funktionsumfang flexibel zu halten. Wichtig um ein gutes Team zu bekommen, ist es, das Team über mehrere Projekte in seiner Zusammensetzung konstant zu halten. Dabei kann das Team gegebenenfalls verkleinert werden, wenn sich seine Effizienz stark steigert. Von der zu erstellenden Software existiert nur eine offizielle Version, die Codebasis. Aus dieser und den Tests entsteht auch die Dokumentation des Systems. Um von Anfang an Schwierigkeiten bei der Überführung der Software auf ihr Zielsystem (Deployment) zu vermeiden, wird die neue Software in kleinen Teilen inkrementell auf das Zielsystem überführt. So steht täglich eine neue Version zur Verfügung. Das minimiert das Risiko und die Kosten für die Systemumstellung.
Vorgehen für ein XP-Team
Zu Beginn jedes Projekts und jedes neuen Iterationszyklus (in der Regel ein bis drei Wochen pro Zyklus) gibt es ein Planungstreffen, in dem das bereits beschriebene Planungspiel durchlaufen wird. Die Benutzergeschichten für den aktuellen Iterationszyklus werden vom Team in kleine in sich geschlossene Aufgaben für die einzelnen Programmiererpaare zerlegt. Diese Aufgaben sollen innerhalb von Stunden erledigt werden können, wobei immer zuerst der zugehörige Test geschrieben wird. Während eines Iterationszyklus gibt es tägliche Stand-Up Treffen, die die meisten Teams stehend (um sie kurz zu halten) vor ihrer Aufgabenübersicht abhalten. In diesen Treffen gibt jeder den aktuellen Stand seiner Arbeit an und es werden eventuell enstandene Probleme angesprochen. Deren Lösung (sofern sie nicht sofort benötigt wird) wird bis zum Endmeeting des Interationszyklus bzw. den Extrateammeetings, die circa zweimal jährlich außer Haus stattfinden sollen, aufgeschoben. Bei den Endmeetings wird dem Kunden die fehlerfrei laufende Version der Software für diesen Iterationszyklus übergeben und im Team rückblickend der vergangene Zyklus betrachtet und eine Bilanz gezogen, was gut war und was verbessert werden muss.
User Interface
Paul Kahn und Krzysztof Lenk definieren den Begriff User Interface bzw. Benutzerschnittstelle in ihrem Buch "Websites visualisieren" wie folgt: "Punkt der Interaktion oder Kommunikation zwischen dem Computer und dem Benutzer. Gewöhnlich sind damit der Bildschirm sowie die Informationen und Graphiken, die auf ihm dargestellt werden, gemeint." Mark Guzdial stellt in seinem Buch Squeak (2000) im Text Designing UI zu diesem Thema folgendes fest: "Auf Konferenzen zum User Interface Design kann man Leute beobachten, die Plaketten mit der Aufschrift: "Kenne Deinen User, denn er ist nicht Du." bei sich tragen. Dies ist eine der wichtigsten Maxime für UI Designer und wahrscheinlich die härteste Lektion, die man in diesem Bereich lernen muss."
Die Benutzerschnittstelle ist der Zugang des Endnutzers zum System und ihr Design bestimmt dadurch wie viel Aufwand ein Nutzer verwenden muss um das System zu verstehen, dem System die richtigen Eingaben zu liefern und die Ausgabe richtig zu interpretieren. Um ein für den Nutzer effizient zu gebrauchendes System zu liefern, muss schon in frühen Phasen des Entstehungsprozesses das Design der Benutzerschnittstelle miteinbezogen werden und auf seine tatsächliche Nutzbarkeit für den Enduser überprüft werden. Es ist nicht immer leicht für einen Entwickler das passende Design zu finden, da die Software immer häufiger für User geschrieben wird, die mit dem Computer und seinen internen Vorgängen nicht vertraut sind.
XP und User Interfaces
Das Verfahren XP bietet speziell für die Entwicklung von Benutzerschnittstellen einige Vorteile. Zum einen die starke Einbindung des Kunden und die intensive Kommunikation (gefördert durch tägliche Treffen und das Arbeiten in einem Raum) helfen, die Wünsche und Anforderungen des Endnutzers immer vor Augen zu haben und gegebenenfalls schnell auf nötige Anpassungen oder enstandene Probleme reagieren zu können. Die frühen und häufigen Produktivfreigaben sowie die vielen Tests ermöglichen eine ständige Kontrolle über die tatsächliche Nutzbarkeit des User Interface für den Kunden. Sollten im Laufe des Entstehungsprozesses einer Benutzerschnittstelle Änderungen nötig werden, ist dies kein Problem, da XP Änderungen in seinen Prinzipien integriert hat. Dadurch macht es XP den Entwicklern leicht, jederzeit Änderungen ohne großen Aufwand auszuführen. Im Rahmen der Applicationtests am Ende jeden Iterationszyklus können Usabilitytests der Benutzerschnittstelle mit einer kleinen Gruppe repräsentativer Testnutzer durchgeführt werden und so leicht Abweichungen vom idealen Design der Benutzerschnittstelle für die entstehende Software entdeckt werden.
Verwendete Literatur:[1] Agile Alliance: Manifesto for Agile Software Development, 2001
[2] SOPHIST GROUP, accessed Februar, 1st, 2007
[3] Extreme Programming (XP) FAQ accessed Februar, 1st, 2007
[4] Extreme Programming Frank Westphal (26.08.2001), accessed Februar, 1st, 2007
[5] Extreme Programming Wikipedia, accessed Februar, 1st, 2007
[6] Kahn, Paul und Krzysztof Lenk: Websites visualisieren. Entwerfen, analysieren und steuern mit Plänen , Karten und Diagrammen. Erschienen: Reinbek: Rowohlt 2001.
[7] User interface Wikipedia, accessed Februar, 1st, 2007
[8] Mark Guzdial: Squeak. Object Oriented Design with Multimedia Applications. Erschienen: Prentice Hall 2000
