Integration von HCD in den Entwicklungsprozess
Hinweis: Der Inhalt dieses Abschnitts ist nicht prüfungsrelevant, ist aber als Vertiefung hilfreich.
Seit dem Einzug der agilen Entwicklung in die Projekte wird immer wieder diskutiert ob agile Entwicklung das eine richtige Vorgehen ist und alle anderen Vorgehensweisen falsch sind.
Innerhalb dieser Diskussion ist der Begriff “klassisch” entstanden:
- es gibt klar formulierte Ziele im Projekt, sprich “SMART”: Specific, measurable, accepted, realistic, timely.
- das Projekt kann mit Meilensteinen und klar voneinander abgegrenzten Phasen versehen werden.
Agile Ansätze (z.B. Scrum) basieren auf der Annahme, dass moderne Softwareprojekte zu komplex sind, um durchgängig in dieser Weise planbar zu sein.
Der Stärker agiler Ansätze entfaltet sich, wenn sich mit hoher Dynamik Projektparameter wie Ziele, Umfeldung und Erwartungen an die Lösung verändern.
Projekttyp
Eher klassisch präferieren:
- Invesitions- oder Organisationsprojekt
Eher agil präferieren:
- (Software-)Entwicklungsprojekt
Ziele
Eher klassisch präferieren:
- konstanter Projektverlauf, “SMART” planbar
Eher agil präferieren:
- Unscharf
- Vision
- häufige Änderungen in Zielen und Anforderungen sind zu erwarten
Auftraggeber
Eher klassisch präferieren:
- Auftraggeber begleitet das gesamte Projekt bis zum Abschluss
- bleibt klar in den Zielvorstellungen
- ist eher den “klassischen Ansätzen” aufgeschlossen
- fordert methodisches Vorgehen nach Plan
Eher agil präferieren
- Auftraggeber kann im Projektverlauf wechseln
- Änderungen von Prioritäten und Zielvorstellungen
Team
Eher klassisch präferieren:
- braucht klare Führung; räumlich verteilt, virtuell, eher groß
Eher agil präferieren:
- eher kleine, selbstorganisierte Teams
Externe Dienstleister
Eher klassisch präferieren:
- Viele Dienstleister mit vielen Abhängigkeiten untereinander
- brauchen klar definierte Arbeitspakete
Eher agil präferieren:
- geringe Abhängigkeiten untereinander
- Vertragskontext lässt agiles Vorgehen zu
Stakeholder
Eher klassisch präferieren:
- viele Stakeholder
- festgelegte Business Requirements
- Termine müssen gehalten werden und sind wichtiger als der Leistungsumfang
- Aktivitäten von Stakeholddern hängen vom Termin ab
Eher agil präferieren:
- wenige Stakeholder
- Qualität wichtiger als Termin
- Aktivitäten der Stakeholder weitgehend unbeeinflusst vom Projekt
Dokumentation
Eher klassisch präferieren:
- rechtliche Anforderungen erfordern hohe Dokumentationsqualität
- zukünftige Weiterentwicklung und Pflegen haben hohen Stellenwert
Eher agil präferieren:
- Es existieren keine Zwänge (Normen, Gesetze)
- für zukünftige Zwecke weniger wichtig
Unabhängig davon, ob ein Projekt eher klassisch oder eher agil durchgeführt wird, gibt es naturgemäß Bedarf für Änderungen, sobald Projektergebnisse evaluiert werden, insbesondere bei UIs durch Usability Tests mit Benutzern.
Darum sollten in jedem Fall explizit Ressourcen für Iterationen eingeplant werden. So können Überarbeitungen aufgrund erkannter Probleme an Projektergebnissen vorgenommen werden.
Iteratives Vorgehen ist einer der Grundsätze menschzentrierter Gestaltung.
Lean UX
Lean UX geht davon aus: Wenn es schon viele Informationen über den Nutzungskontext gibt und klare Annahmen zur Lösung existieren, kann man den Aufwand für Benutzerforschung reduzieren.
Statt umfangreicher Studien reicht es oft, Annahmen mit kleinen und schnellen Usability-Tests zu überprüfen.
Agile Entwicklung nach Lean UX folgt den Prinzipien nutzerzentrierten Designs. Trotzdem gibt es ähnliche Chancen und Risiken wie bei klassischen Methoden.
Stellen Teams in einem Lean-UX-Projekt fest, dass Nutzer ihre Annahmen nicht bestätigen, müssen sie mehr über den Nutzungskontext herausfinden. Dafür eignen sich zum Beispiel Interviews oder Beobachtungen.
Die gewonnenen Erkenntnisse helfen, Lösungen zu verbessern oder neue Ideen zu entwickeln.
Diese werden dann wieder mit schnellen Usability-Tests überprüft.
Im CPUX-UR-Curriculum („User Requirements Engineering“) und im Praxisbuch „Praxiswissen User Requirements“ wird genau erklärt, wie nutzerzentriertes Design in verschiedene Methoden integriert werden kann.
Hybride Vorgehensweisen
Mittlerweile gibt es Methoden, die Elemente aus klassischer und agiler Entwicklung kombinieren. Sie nutzen die Vorteile beider Ansätze.
Ein bekanntes Beispiel ist Disciplined Agile Delivery (DAD), ein Modell für große Unternehmen und umfangreiche Projekte (Amber & Lines, 2012).
DAD beginnt mit einer „Inception Phase“. In dieser frühen Phase des Projekts werden zentrale Fragen geklärt, damit die Entwicklung in die richtige Richtung startet.
Dazu gehört auch eine erste Nutzungskontextanalyse mit zukünftigen Nutzern. So können bereits zu Beginn wichtige Erkenntnisse für die spätere Entwicklung gewonnen werden.