Extreme Programming und User Interfaces
von Andreas Werner, 9. Februar 2007
- Extreme Programming und User Interfaces
- 1 Einleitung
- 2 Extreme Programming (XP)
- 3. User Interfaces
- 4. Usability in XP
- 5. Ausblicke
1 Einleitung
Extrem programming und Usability Engineering sind beides Methodiken, deren Zielsetzung die leichtere Erstellung guter Software ist. Doch wird die Qualität von Software aus zwei völlig unterschiedlichen Richtungen betrachtet. Extreme Programming als eine Disziplin der Softwareentwicklung ist versteht unter guter Software in erster Linie ein Computersystem, das auf Grund der hohen Qualität des Programmcodes stabil und leicht wartbar ist. Im Usability Engineering hingegen versteht man unter guter Software ein Programm mit einem User Interface, das sich durch seine angenehme und effiziente Benutzbarkeit auszeichnet. Die sind ohne Frage beides erstrebenswerte Ziele.
Diese Arbeit Stellt Extreme Programming sowie User Interfaces und Usability Engineering vor und prüft am Ende ob sich die Methoden vereinbaren lassen.
2 Extreme Programming (XP)
Extreme Programming oder kurz XP ist eine Methode der Softwareentwicklung (Software Engineering). Unter den zahlreichen Formen der Agilen Methoden gilt XP als die populärste. XP ist eine so genannte leichtgewichtige Softwareentwicklungs-Methode. Der Programmcode steht im Mittelpunkt des Entwicklungsprozesses, seine Qualität ist oberstes Prinzip. Zeitaufwand und Funktionsumfang des Projektes werden hingegen nicht exakt festgelegt sondern während der Arbeit dynamisch erarbeitet und verändert. Schriftstücke neben dem Code, wie zum Beispiel Dokumentation oder Pflichtenhefte werden als Ballast betrachtet, auf den soweit als möglich zu verzichten ist.
2.1 Entstehung
Extreme Programming wurde von den Softwareengineering-Experten Kent Beck, Ron Jeffris und Ward Cunnigham für das Chrysler Comprehensive Compensation System Projekt (C3) entwickelt. Dieses Projekt wurde von 1995 bis 2000 entwickelt und sollte im Bereich der Lohnabrechnung mehrere verschiedene Systeme durch einen einheitlichen Ansatz ersetzen. Ironischer Weise kam es jedoch nie zum produktiven Einsatz, obwohl es durch die Entwickler erfolgreich abgeschlossen wurde. Über die Gründe dafür ranken sich mehrere Gerüchte. Eine Theorie besagt, dass das Projekt eingestellt wurde, weil es in der Programmiersprache Smalltalk geschrieben war. Genau in dieser Zeit erfuhr jedoch Java einen immensen Anstieg an Zuspruch. Die damalige Geschäftsleitung wollte kein Projekt vorantreiben, das in einer vermeintlich veralteten Sprache programmiert wurde. Offiziell wurde die erstellte Software nach der Fusion mit Daimler zu DaimlerChrysler nicht weiter benötigt. Nach einer anderen Geschichte wurde die Software für einen kurzen Zeitraum sehr wohl und auch erfolgreich eingesetzt. Das Projekt war von Chryslers Softwareabteilung als Testprojekt initiiert und finanziert worden. Nach Fertigstellung sollten die Kosten auf die Lohnabteilung übertragen werden. Dagegen streute sich diese jedoch, worauf hin das Projekt eingestellt wurde. Nach anderen Quellen wiederum war das C3-Projekt schlicht wegen Misserfolges eingestellt worden. Genauer soll die Software gravierende Performance-Probleme gehabt haben: So dauerte ein Lohn-Durchlauf bis zu 40 Stunden.
2.2 Der heutige Stand
Extreme Programming wird durch Kent Beck mit seinem Buch "Extreme Programming Explained" begründet, in dem er die revolutionäre Software Entwicklung vorstellt. Trotz des Misserfolges beim C3-Projekt erfreut sich XP einer wachsenden Beliebtheit. Bis heute sind mehrere Bücher erschienen bzw. in Vorbereitung. "Die Popularität von XP in der Praxis zeigt sich auch anhand zahlreicher Artikel in Computerzeitschriften (...)" [Rumpe] Obwohl wenig genaue Zahlen vorliegen, kann man davon ausgehen, dass XP heute vielen Softwareentwicklern ein Begriff ist.
2.3 Vorteile
Im Gegensatz zu den traditionellen Vorgehensmethoden ist XP eine so genannte "leichtgewichtige" Methode, die auf Overhead durch umfangreiche Pflichtenhefte oder Dokumentation verzichtet. Da z.B. im klassischen Wasserfallmodell die Anforderungen sehr früh definiert werden und fortan bindend für alle weiteren Phasen sind, hängt die Qualität des Ergebnisses sehr entscheidend von der Güte dieser Anforderungen ab. Änderungen in späteren Entwicklungsphasen sind nur schwer möglich bzw. sehr teuer. Da der Kunde die tatsächlichen Anforderungen zu Beginn eines Softwareprojektes häufig selbst nicht genau kennt oder im Sinne der Entwickler nicht konkret genug benennen kann, scheitern viele Projekte bereits in der Planungsphase. Dieses Scheitern zeigt sich jedoch erst nach Fertigstellung: Im Ergebnis erhält der Kunde eine Software, mit der er nicht zufrieden ist.
Passieren in der Planungsphase die Fehler nicht auf Seite des Kunden sondern oder auch beim Entwickler, schlagen sich diese Probleme unmittelbar auf die Codequalität nieder. Solche Fehler resultieren meist in einem erhöhten Implementierungsaufwand. Da die zeitliche und funktionale Zielsetzung vertraglich bindend und nahezu unabänderlich definiert wurde, ist die Qualität des Codes der erste skalierbare Faktor, bei dem Einsparungen gemacht werden. Dadurch wird die Software fehlerhaft und schlecht wartbar. Dies, so eine Theorie in der XP, verteuert das gesamte Softwareprojekt unverhältnismäßig.
2.4 Methodik
Die Methodik des Extreme Programming rückt hingegen nicht die zeitlichen und funktionalen Ziele, sondern den Code und dessen Qualität in den Mittelpunkt eines Projektes. Dabei bejaht sie gleichzeitig Fehler und Änderungen. Die Software wird in vielen kleine Iterationen Feature für Feature aufgebaut. Dabei bleibt das Programm durchgängig jederzeit lauffähig. Der Kunde hat hierdurch die Möglichkeit, seine Anforderungen während der Entwicklungsphase noch genauer zu spezifizieren und erhält schnelles Feedback durch den aktuellen Stand der Implementierung. Änderungen oder Erweiterungen seiner Anforderungen sollen ihm jederzeit möglich gemacht werden.
Zu Beginn einer Iteration bestimmt das Entwicklerteam zusammen mit dem Kunden, welche Features als nächstes in die Software implementiert werden.
Ist für eine Iteration eine Prioritätenliste der Funktion erstellt, werden diejenigen Funktionen mit der höchsten Priorität implementiert. Dabei wird für jede Funktion die einfachste Lösung, die das Geforderte erfüllt umgesetzt. Auf mögliche spätere Erweiterungen wird hier keine Rücksicht genommen. Laut XP-Philosophie ist es effizienter "heute etwas einfaches zu schreiben, was morgen vielleicht erweitert werden muss, als heute etwas aufwändiges, was eventuell nie gebraucht wird." [Rumpe] Dass dadurch der Code beim Hinzufügen neuer Features häufig verändert und umstrukturiert werden muss, ergibt sich unmittelbar. Dies gilt in XP jedoch nicht als Nachteil, bietet sich doch genau durch diesen Umstand die oben geforderte Möglichkeit, geänderte Kundenwünsche jederzeit in das System mit einfließen zu lassen.
2.5 Praktiken
XP ist durch eine Vielzahl an verschiedenen Praktiken charakterisiert. Alle diese Praktiken greifen ineinander. Doch drei dieser Praktiken scheinen für die oben beschriebene Zielsetzung von besonderer Bedeutung zu sein: Testgetriebene Entwicklung, Permanente Integration, und Refactoring, auf die im folgenden besonders eingegangen wird.
2.5.1 Testgetriebe Entwicklung:
Für jede Funktionalität existiert ein entsprechender automatisierter Test. Noch bevor die eigentliche Funktionalität programmiert wird, erstellt man einen geeigneten Modultest. Diese Tests überdecken sich mit der angestrebten Funktionalität zu 100 Prozent. Der Programmierer muss somit beim Erstellen des Tests eine genaue Spezifikation der zu programmierenden Funktion festlegen. Erst danach wird der eigentliche Programmcode erstellt. Dies bringt mehrere Vorteile: Zunächst mag als größter Vorteil erscheinen, dass sich ein Entwickler beim Erstellen eines Modultests weitaus mehr Gedanken über eventuelle Rand- bzw. Problemfälle macht, als wenn er sich als erstes mit der Kernfunktionalität beschäftigen würde. Beim anschließenden Ausformulieren des eigentlichen Programmes wird er somit auch diese Randfälle berücksichtigen, die er ansonsten leichter übersehen hätte. Durch diese Reihenfolge wird die Software von Anfang an deutlich stabiler geschrieben. Noch wichtiger ist jedoch, dass jeder Programmteil durch die Existenz eines automatisierten Tests nicht nur während oder unmittelbar nach der Erstellung getestet werden kann. Vielmehr kann zu jedem beliebigen Zeitpunkt während der gesamten Projektdauer jeder Programmteil und somit das gesamte Projekt auf Korrektheit getestet werden. "(...) Die Gesamtheit der Tests (kann) als ein Modell des Softwaresystems verstanden werden. Anders als explizite Modelle, die z.B. in UML repräsentiert werden, ist ein Test-Modell sehr implizit, hat aber den Vorteil der automatisierten und wiederholbaren Prüfbarkeit." [Rumpe] Diese Eigenschaft bildet die Grundlage für die beiden anderen erwähnten Praktiken des Extreme Programmings.
2.5.2 Permanente Integration.
Neue Komponenten werden permanent in das lauffähige Gesamtsystem integriert. Durch die dabei gewonnene Routine minimiert sich der Integrationsaufwand und Fehler im Zusammenspiel der Komponenten werden früh erkannt. Dies ist jedoch nur durch die automatisierte Testbarkeit des Systems gegeben, die die Testgetriebene Entwicklung mit sich bringt. Das permanente Integrieren von Features geht Hand in Hand mit der Forderung, dem Kunden laufend Änderungs- und Erweiterungswünsche zu gestatten.
2.5.3 Refactoring:
Wie bereits beschrieben, wird jede Funktion so implementiert, dass sie gerade den momentanen Anforderungen, nicht jedoch möglichen zukünftigen genügt. Das permanente Hinzufügen von Funktionalität zerhackt ursprünglich sauber formulierten Code in unübersichtliche Codefragmente. Es entsteht der so genannte "Spagetticode". Die Codebasis bedarf des Refactorings, dem Restrukturieren des Programmcodes und somit Verbessern der Codequalität unter Beibehaltung der bestehenden Funktionalität. "XP bejaht die Existenz von Code, der zu Anfang nicht perfekt ist. Stattdessen sind sämtliche Teile einem stetigen Review unterworfen." [WikipediaXP] Doch das permanente Refactoring wäre kaum richtig durchführbar, könnte man nicht auf die automatisierten Tests zurückgreifen, die auch nach der Reorganisation die Korrektheit des gesamten Systems bestätigen, bzw. Fehlerverhalten schnell aufzeigen.
2.6 User Stories und Akzeptanz Tests
Das permanente automatisierte Testen und Entwickeln solcher Tests stellt somit eine zentrale Tätigkeit eines Entwicklers im Extreme Programming dar. Aber auch für den Kunden spielen solche Tests eine entscheidende Rolle. Da er seine Wünsche bezüglich der zu implementierenden Funktionalität nicht wie bei traditionellen Entwicklungsprozessen durch ein ausführliches Lastenheft festlegt, benötigt er ein anderes Medium, seine Wünsche zu formalisieren. XP sieht hier so genannte User Stories vor. Aus diesen User Stories werden durch den Kunden Akzeptanz Tests konstruiert, die Geschäftsanwendungen nachbilden. Im Gegensatz zu den Modultests der Entwickler müssen die Akzeptanz Tests nicht die gesamte Funktionalität des Systems überdecken, wenngleich es dies anzustreben gilt. Mit den Akzeptanz Tests kann der Kunde jederzeit prüfen, ob die Software die von ihm geforderten Anforderungen erfüllt.
3. User Interfaces
"Das User Interface (Benutzerschnittstelle) ist der Teil eines Programms, das den Datenaustausch mit dem Benutzer durchführt." [WikipediaUI] Zwar existieren eine Vielzahl solcher User Interfaces, doch sind im Zusammenhang mit Software Entwicklung die Grafischen User Interfaces (GUI) von größtem Interesse. Im folgenden werde ich mich also auf diese Benutzerschnittstellen beschränken.
3.1 Entwicklung
Die ersten Grafischen User Interfaces wurden ab 1973 am Palo Alto Research Center (PARC) der Firma Xerox entwickelt und gelangten mit dem Xerox Star 1981 erstmals zur Marktreife. 1983 veröffentlichte Apple Lisa, seinen ersten Rechner mit GUI, 1984 startete die Serie Macintosh, die sich bis heute durch einen besonders hohen Bedienkomfort von der Konkurrenz absetzt. Bereits damals entstand die Desktop Metapher, die sich als Standard etabliert hat. Alle, für den User zugänglichen Elemente werden durch Icons dargestellt, die in Fenstern angeordnet sind. Fenster lassen sich samt ihres Inhaltes auf dem Bildschirm verschieben sowie aus- oder einblenden. Aktionen führt der User typischerweise mit Hilfe von Menüs aus. Das charakteristischste Element einer GUI ist jedoch die Maus bzw. ihre Representation auf dem Bildschirm in Form des typischen Mauszeigers, durch den der Benutzer erst in Interaktion mit der GUI treten kann.
3.2 Usability
Während sich herkömmliche Computersysteme nur durch speziell ausgebildete Experten bedienen ließen, machten es die GUIs einer weitaus größeren Zielgruppe möglich, ihre Arbeit mit Hilfe des Computers zu verrichten. Heute ist der Computer ein Alltagsgerät, das von jedem bedient werden kann. Die Benutzung eines Computers ist auch nicht mehr unbedingt mit Arbeit verbunden, immer mehr Menschen nutzen sie für private Tätigkeiten oder zur reinen Unterhaltung. "Daraus ist ein neuer Qualitätsaspekt an Software entstanden, der die Benutzungsfreundlichkeit repräsentiert: Usability." [Hardt]
Doch ist Usability kein eindimensionales Merkmal einer Benutzerschnittstelle. Es ist vielmehr eine Unterteilung in fünf Eigenschaften [Nielsen]:
Learnability: Die Software sollte einfach zu erlernen sein. Dies bezieht Handbücher, Online-Hilfe sowie Schulungen mit ein. Aber auch die Einhaltung von Standards ist von Bedeutung.
Efficiency: Die Software sollte effizient zu Nutzen sein. Wichtige Funktionen sollten beispielsweise schnell erreichbar sein und mit wenig Aufwand ausgeführt werden können.
Memorability: Der User sollte sich an die Funktionen der Software leicht erinnern können und diese wieder finden.
Errors: Die Software sollte den User vor Fehlern bewahren. Insbesondere sollten alle Aktionen durch den Benutzer rückgängig gemacht werden können.
Satisfaction: Der Benutzer sollte die Benutzung der Software als angenehm empfinden und subjektiv zufrieden sein.
3.3 Usability Engineering (UE)
Eine Benutzeroberfläche zu erstellen, die all diesen Kriterien optimal genügt ist, alles andere als trivial. Usability Engineering (UE), ein Teilgebiet der Mensch-Maschine-Interaktion, ist eine Wissenschaft, die sich u.a. mit der systematischen Erstellung benutzbarer Bedienkonzepte befasst. Natürlich gibt es innerhalb der UE mehrere solche Ansätze. Zumeist werden in verschiedenen Phasen die Benutzeroberflächen durch Prototypen Modelliert. Dabei handelt es sich um eine Repräsentation der GUI, ohne dass die entsprechende Funktionalität vorliegt. Diese zunächst sehr groben Abbildungen werden von Phase zu Phase verfeinert und präzisiert. Verschiedene Formen von Tests (z.B. Usabilty Tests) bestätigen die Usability der zu entwerfenden Benutzeroberfläche oder aber zeigen Probleme auf.
3.3.1 UE Tests
UE kennt verschiedenste Formen von Tests, von denen unterschiedlich verlässliche Ergebnisse erwartet werden. Typischerweise gestalten sich die verlässlicheren Test deutlich aufwändiger, somit teurer und werden daher meist auf recht weit fortgeschrittene Ausarbeitungen der Prototypen oder gar nur auf das Endprodukt angewendet.
User Studies, also das Testen mit einer relevanten Anzahl an Testkandidaten, ist sehr zeitaufwändig. Da die Qualität einer solche Studie nur durch eine sorgfältige Vorbereitung und ein sensibles Auswerten der Ergebnisse gewährleistet bleibt, muss mit einem Zeitaufwand in der Größenordnung von Wochen oder Monaten gerechnet werden. Eine besondere Schwierigkeit stellt hierbei auch das finden der geeigneten Testkandidaten dar, da diese keinesfalls mit dem Projekt vertraut sein dürfen. Auch sollte der Anteil an Softwareentwicklern oder Usability Experten unter den Testkandidaten der realen Verteilung in der Zielgruppe entsprechen. Somit scheiden Bekannte oder insbesondere Kollegen für diese Art der Tests zumeist aus. Die gewonnenen Erkenntnisse haben jedoch eine entsprechend hohe Aussagekraft.
Eine Andere Form von Tests innerhalb des Usability Engineerings stellen Heuristic Evaluationen dar. Hierbei wird das User Interface von Usability Experten untersucht. Diese prüfen den Prototypen anhand von Usability Guidelines. "Usability Guidelines haben die besondere Eigenschaft allgemein gültig zu sein und sollten daher in jedem GUI Einzug erhalten." [Hardt]
4. Usability in XP
Nun stellt sich die Frage, ob das systematische Erstellen von benutzbaren User Interfaces mit den Methoden des Extreme Programmings vereinbar ist.
In den Zielen des XP ist Usability nicht aufgeführt. Auch sonst findet man in den Praktiken, Werten und Prinzipien keine explizite Erwähnung eines Bestrebens nach Usability.
4.1 Code Qualität und Usability
Wie bereits beschrieben, stellt XP die Qualität als oberste Maxime in den Mittelpunkt aller Tätigkeiten. Doch besteht zwischen Codequalität und Benutzbarkeit einer Software kaum ein Zusammenhang. Zwar ist eine Software nur dann benutzbar, wenn sie fehlerfrei funktioniert. Dies ist selbstverständlich auch ein wesentliches Merkmal für die Qualität des Codes. Doch Usability in unserem Sinne setzt das fehlerfreie Funktionieren als Grundbedingung voraus. Ist diese Bedingung nicht erfüllt, wird jede Software unbenutzbar, unabhängig von der GUI oder den Usability Engineering Methoden. Eine hohe Code Qualität impliziert also keineswegs die Benutzbarkeit einer Software.
4.2 Usability durch den Kunden
XP gibt dem Kunden viel Freiheit, auf den Fortgang eines Software Projektes Einfluss zu nehmen. Es ist davon auszugehen, dass jeder Kunde an einem hohen Maß an Benutzbarkeit seiner Software interessiert ist, und somit entsprechend seine Anforderungen (User Stories) formuliert und seine Akzeptanz Tests darauf hin abstimmt. Ginge man jedoch davon aus, dass es dem Kunden obliegt, die Software benutzbar zu gestalten, würde man statt der in der Fragestellung verlangten Vereinbarung zwischen zwischen XP und UE eine explizite Trennung herstellen. Weiter müsste man sich fragen, woher der Kunde wissen soll, wie ein Programm benutzbar zu gestalten ist, wenn dies schon die Softwareentwickler scheinbar nicht wissen. Weiter müsste man sich überlegen, wie der Kunde seine Anforderungen an die Benutzbarkeit formalisieren kann, bzw. ob der Aufwand dieser Formalisierung nicht gegen fundamentale Prinzipien von XP verstößt.
4.2 Testings: Eine Gemeinsamkeit von XP und UE?
Als Gemeinsamkeit zwischen XP und UE fällt jedoch die starke Bedeutung von Testings auf. Es liegt der Gedanke nahe, in das Test-Modell der Software aus XP die aus der UE bekannten Usability Tests einzubeziehen. Doch laufen alle Tests des Extreme Programmings automatisiert ab. Die Usability Tests hingegen kennen keinerlei Automatisierung. Da UE immer den Menschen mit einbezieht, ist ein Automatisieren dieser Test kaum vorstellbar.
Es ist somit festzustellen, dass reines Extreme Programming kaum mit den Methoden des Usability Engineering zu vereinbaren ist.
5. Ausblicke
In [Hardt] wir eine Methodik beschrieben, wie ein zumindest ein Teilbereich der Usability Guidelines durch automatisierte Tests geprüft werden kann. Category-Specific Guidelines sind Usability Heuristiken, die speziell für Grafische User Interfaces gelten. Die Ober