Human Centered Design vs. Agile Entwicklung: Adaptive Balance

Unter www.agilegovleaders.org finden Sie agile Regierungsnachrichten, Fallstudien, Videos, Schulungen und mehr.

Überall in der Welt der Informationstechnologie gibt es ein Spannungsverhältnis zwischen Human Centered Design (HCD) und Agile-Methoden. Beide Methoden stimmen in ihrem Fokus auf den Endbenutzer und auf eine konsistente Iteration überein. Agile Praktiker glauben jedoch, dass Design und Entwicklung zur gleichen Zeit beginnen und gleichzeitig ablaufen, während HCD-Designer häufig an eine dedizierte Discovery-Phase glauben, die dem Beginn der Entwicklung vorausgeht. Im Bereich der Bürgerprogrammplanung oder des öffentlichen Auftragswesens kann diese Spannung durch strenge Beschaffungsvorschriften verstärkt werden, die eine strengere Rechenschaftspflicht und Ressourcenplanung erfordern als beispielsweise die Welt der Start-ups.

Einige Teams versuchen, eine separate Design- und Entwicklungsphase zu erstellen, in der die Benutzerrecherche zu originalgetreuen Designs führt, die dann einem Agile-Entwicklungsteam zur Implementierung vorgelegt werden. Aber eine so starke Kluft zwischen Design und Entwicklung ähnelt in verdächtiger Weise einem Waterfall-Modell. Wasserfallmethoden, die eine klare Phasentrennung betonen, sind riskant und führen zu sehr geringen Erfolgsraten. Agile Methoden zielen darauf ab, Ineffizienzen im Waterfall-Modell zu reduzieren oder zu beseitigen, indem die Zusammenarbeit verbessert und die Teammitglieder während des gesamten Produktentwicklungszyklus ausgerichtet werden.

Um die ideale Beziehung zwischen agilen Methoden und Human Centered Design besser zu verstehen, beginnen wir mit klaren Definitionen.

Was ist Human Centered Design?

Obwohl es andere Erklärungen für HCD gibt, stellt der British Government Digital Service (GDS) dies klar:

Der Entwurfsprozess muss damit beginnen, die tatsächlichen Benutzeranforderungen zu identifizieren und darüber nachzudenken. Wir sollten uns an diesen orientieren - nicht an der Art und Weise, wie der „offizielle Prozess“ derzeit abläuft. Wir müssen diese Anforderungen gründlich verstehen - Daten abfragen, nicht nur Annahmen treffen - und wir sollten uns daran erinnern, dass die Benutzer nicht immer die Anforderungen erfüllen, die sie benötigen.

- Gov.UK Design Principles

Was ist agil?

Agile lässt sich am besten in den Grundsätzen des Agile Manifests ausdrücken:

Wir sind zu Wert gekommen ...
Individuen und Interaktionen über Prozesse und Werkzeuge
Arbeitssoftware über umfangreiche Dokumentation
Zusammenarbeit der Kunden bei Vertragsverhandlungen
Reagieren, um nach einem Plan umzuschalten

Beachten Sie, dass das Wort "Kunde" so interpretiert werden sollte, dass es die Endbenutzer einschließt, und dass ein wirklich agiler Prozess echte Benutzer während des gesamten Entwicklungszyklus einbezieht. In Bezug auf Regierungsaufträge müssen die Sponsoren und Administratoren der Agentur ebenfalls als echte Benutzer betrachtet werden, aber die Administration ist ein notwendiger Diener des Kunden. Da der Endbenutzer normalerweise nicht in einer Regierungsvertragssituation zahlt, ist es allzu einfach, für den zahlenden Kunden und nicht für den tatsächlichen Endbenutzer mit dem Bauen zu beginnen. Dies ist ein grundlegender Fehler.

In welcher Beziehung steht HCD zu Agile?

Der Hauptunterschied zwischen HCD und Agile besteht darin, wie und wann verschiedene Mitarbeiterrollen auf ein Projekt angewendet werden. Dies ist in den folgenden Diagrammen dargestellt, die die mögliche Besetzung von Designern und Entwicklern über den Lebenszyklus eines Projekts in jedem der beiden Ansätze zeigen.

HCD schlägt eine Ermittlungsphase mit eingeschränkter oder keiner Beteiligung der Entwickler vor:

Während Agile einen reibungslosen und kontinuierlichen Prozess erfordert, bei dem Entwickler und Designer ständig zusammenarbeiten:

Die britische GDS scheint auf hybride, vermittelnde Weise zu arbeiten. Es hebt diese Schlüsselpunkte hervor:

  • Eine neue Art, Dinge zu tun: „In kleinen Blöcken bauen und testen und schnell daran arbeiten, einen Service zu verbessern. Die Teams werden herausfinden, wie sie die Bedürfnisse der Benutzer am besten erfüllen können, indem sie regelmäßig Code veröffentlichen und agil arbeiten.
  • Benutzer sind während des gesamten Entwurfs und der Entwicklung involviert.
  • Phasenweise Entwicklung: Erstellen Sie in Zusammenarbeit mit Benutzern ab dem ersten Tag wichtige Leistungsindikatoren (KPIs) in Ihrer Ermittlungs- und Alpha-Phase. Anschließend können Sie Aktualisierungen und Verbesserungen schnell in der Entwicklungsumgebung veröffentlichen und die Auswirkungen Ihrer Änderungen messen.

Dieses Hybridmodell ist unten abgebildet:

Was sind die Implikationen dieser Ansätze?

Agile Prozesse gelten allgemein als erfolgreicher als Waterfall-Ansätze. Agilität aus Sicht des Human Centered Design zu betrachten, wirft einige subtile Fragen auf:

  • Wie erstellen wir funktionierende Software, ohne zuerst ein Design zu haben?
  • Bedeutet ein iterativer Prozess, dass sich das Design in der ersten und letzten Iteration gleichermaßen ändert?
  • Verändert sich das Gleichgewicht der Talente während des Produktentwicklungszyklus?
  • Verschwenden Sie nicht viel Zeit, wenn Sie Ihre Arbeit ständig ändern?

Wir behaupten, dass die folgenden Vorgehensweisen es HCD und Agile ermöglichen, effektiv zusammenzuarbeiten:

  • Eine rücksichtslose Iteration, die der vorherigen Codierung keinen Wert beimisst, verhindert, dass die frühe Codierung ein Projekt von den Benutzeranforderungen abwendet.
  • Benutzerforschung ist immer erforderlich - und je innovativer Ihr Projekt ist, desto höher sollte der Prozentsatz der Arbeit sein, die für die Benutzerforschung aufgewendet wird.
  • Ein ideales Team verfügt über ausgewogene Fähigkeiten.
  • Agile Methoden unterstützen und ergänzen Human Centered Design, sofern zwischen den Ingenieuren und Designern gegenseitiger Respekt und ein ausreichendes gemeinsames Verständnis besteht.
  • Teams sollten reibungslos und flexibel arbeiten.
  • Jedes Teammitglied muss flexibel auf die sich ändernden Anforderungen an das gesamte Team reagieren können, während sich das Projekt entwickelt.
  • Messen Sie die Produktivität anhand des Werts und nicht anhand des Volumens. Das gesamte Team muss lernen, dass eine Abkehr von einer aktuellen Implementierung als Reaktion auf etwas, das entdeckt wurde, eine Verbesserung darstellt.

Lassen Sie uns nun jede dieser Ideen untersuchen, um sie besser zu verstehen.

Iterativer Prozess

Durch einen iterativen Prozess kann Code Hand in Hand mit dem Entwurfsprozess entwickelt werden, insbesondere wenn die frühen Prototypen als Wegwerfskizzen gelten. In Design-Sessions werden im Idealfall Entwickler, die Personen, die die Services nutzen, und Designer, die Experten für das Einbeziehen von Benutzern und das Interpretieren von qualitativem Feedback sind, anwesend sein. Während der Entwicklung der Software überprüfen die Designer die Änderungen regelmäßig und das gesamte Team nimmt an der Validierung des Dienstes mit echten Benutzern teil.

Je innovativer Ihr Projekt ist, desto höher sollte der Prozentsatz der Arbeit sein, die für die Benutzerforschung aufgewendet wird.

Einige Herausforderungen, wie z. B. die Beschleunigung der Leistung einer Softwarekomponente mit hohem Bedarf, erfordern nur ein geringes User Experience Design und können dennoch beeindruckende Ergebnisse liefern. Das ultimative Benutzererlebnis kann in einem solchen Fall direkt verbessert werden, vor allem durch Codierung und sehr wenig Design. Viel häufiger erfordern Probleme jedoch eine sorgfältige Untersuchung der tatsächlichen Bedürfnisse des Benutzers. Dies gilt insbesondere für den Aufbau eines innovativen oder störenden neuen Dienstes. Es gibt daher ein Spektrum, das von sehr disruptiven Projekten mit unerforschten Benutzeranforderungen bis hin zu Problemen reicht, bei denen die Benutzerinteraktion gut verstanden wird. Benutzerzentrierte Forschung kann Bedürfnisse in unerforschtem Gebiet entdecken. Je innovativer ein Projekt ist, desto mehr Prozent unserer Gesamtenergie müssen wir für das Lernen und die Validierung unserer Annahmen aufwenden.

Ein ausgeglichenes Team sollte ungefähr die gleiche Anzahl an Anwendern haben wie Softwareentwickler.

In der modernen agilen Praxis ist man versucht zu sagen, dass jeder im Team dem Benutzer zugewandt ist. Der agile Pionier Kent Beck hat jedoch zum Ausdruck gebracht, dass die Anzahl der "kundenorientierten" Mitarbeiter - dh Produktmanager, Qualitätssicherungsingenieure und User Experience-Designer - in etwa der Anzahl der Entwickler von Software entsprechen sollte.

In der kommerziellen Industrie gibt es oft eine Tendenz, zu viele Programmierer zu haben, vielleicht weil es einen Sinn gibt, in dem es einfacher ist, zu messen und an das zu glauben, was Programmierer tun. Mehr Codezeilen führen jedoch nicht direkt zu einem Produkt, das die Benutzeranforderungen und Geschäftsziele besser erfüllt. Der einzige Maßstab für die Produktivität ist die Zufriedenheit der Benutzer. Es ist wichtiger, Produkte zu entwickeln, die die Bedürfnisse der Kunden effektiv erfüllen, als energisch das Falsche zu tun.

Die britische GDS sagt, dass es keine strengen Regeln für die Teamzusammensetzung gibt, sondern dass die Fähigkeiten ausgewogen sein müssen:

„Es gibt keine festen Regeln für die Rollen oder die Teamstruktur, die zur Erfüllung dieser Funktionen erforderlich sind, aber ein Kernteam besteht wahrscheinlich aus:

  • ein Servicemanager (der „Product Owner“)
  • wahrscheinlich von einem Produktmanager unterstützt
  • unterstützt von einem oder mehreren digitalen Performance-Analysten
  • ein Zustellungsmanager
  • ein technologischer Vorsprung
  • ein oder mehrere Designer
  • ein oder mehrere Benutzerforscher
  • ein oder mehrere Entwickler
  • einen oder mehrere Inhaltsdesigner
  • die Unterstützung eines technischen Architekten
  • die Unterstützung einiger Web-Ops-Experten

In einigen kleineren Teams, zu denen einige Leute mit vielen Hüten gehören, arbeitet der Programmierer möglicherweise auch mit benutzerzentriertem Design. Es geht darum, die für Aktivitäten aufgewendete Energie mehr auszugleichen als einen absoluten Personalbestand auszugleichen, der häufig von Führungskräften kontrolliert wird, die nicht die Freiheit haben, Menschen so flüssig wie möglich zu bewegen.

Agile Methoden unterstützen und ergänzen Human Centered Design, sofern zwischen den Ingenieuren und den UX-Designern gegenseitiger Respekt besteht.

Gegenseitiger Respekt erfordert ein gemeinsames Vokabular und ein Verständnis für die Ausbildung, die Arbeitsmethoden und die Motivation der einzelnen Teammitglieder.

Wenn Ingenieure den Kunden gegenüber respektieren, bedeutet dies, dass sie fleißig und kreativ Code schreiben, damit die Designer Hypothesen testen und Ideen so früh wie möglich im Projekt ausprobieren können. Sie müssen nicht nur das endgültige Ziel berücksichtigen, sondern auch, wie etwas Testbares erstellt werden kann, das die Designer so früh wie möglich im Projekt bewerten und verwenden können.

In der Vergangenheit bestand die Tendenz, dass Code nach dem Schreiben die Projektrichtung dominiert, da Code nur schwer zu ändern ist. Entwickler müssen jedoch bereit sein, Code und Prototypen wegzuwerfen, um das Projekt in eine Richtung zu entwickeln, die den Benutzern einen Mehrwert bringt. Sie müssen ihr Ego unter Wasser lassen und dürfen anfänglichen Ideen nicht sklavisch folgen, auch wenn sie im Code verankert und scheinbar sehr wertvoll sind.

Anwender müssen Ingenieure respektieren, indem sie kreativ Kompromisse eingehen, da das Produkt, das im ersten und ersten Sprint verfügbar ist, eindeutig begrenzt sein wird. Sie sollten die Kreativität einsetzen, um umsetzbare Lösungen zu finden, die in einem frühen Stadium des Prozesses mit den Benutzern sinnvoll getestet werden können.

Teams sollten reibungslos und flexibel arbeiten

Die Manager sollten das natürliche Auf und Ab verschiedener Arten von Arbeitskräften in verschiedenen Phasen des Projekts respektieren, um Turbulenzen und Ineffizienzen zu verringern, indem sie Talente auf natürliche Weise ankurbeln und abbauen.

In einer idealen agilen Welt wird Software kontinuierlich und reibungslos produziert. Es gibt keine Todesmärsche, keine dramatischen Veröffentlichungszeitpunkte und keine Fristen. Jeder Projektzyklus, sei es eine einfache zweiwöchige Iteration oder ein riesiges mehrjähriges Projekt, wird sanft hoch- und heruntergefahren, damit es reibungslos in das Projekt fließt Nächster.

Dieses Ideal wird jedoch, insbesondere in der Regierung, selten erreicht, da der Akquisitionsprozess dazu neigt, Akquisitionen in Stücke zu treiben. Die Federal Acquisitions Regulation (FAR) priorisiert Fairness gegenüber Convenience. Ziel ist es, einen unvoreingenommenen Wettbewerb zu fördern, der notwendigerweise einen gewissen formalen Prozess erfordert und den Programmmanager dazu zwingt, die Arbeit in großen "Stücken" zu blockieren.

Es liegt jedoch in der Verantwortung des Teams und insbesondere der Führungskraft, einen reibungslosen Anstieg und Abbau der Ressourcen anzustreben.

Während sich das Projekt weiterentwickelt, müssen die Teammitglieder flexibel auf die sich ändernden Anforderungen an das Team reagieren.

In einer perfekten Welt kann ein Manager die Teamzusammensetzung reibungslos neu organisieren, um sie an veränderte Anforderungen anzupassen. Regierungsverträge geben Programmmanagern selten diese Möglichkeit. Das Team kann helfen, ein ideal reibungsloses Projekt zu erreichen, indem es die Rollen leicht verschiebt. In einem gut geführten, sich ständig weiterentwickelnden Projekt kann dies bedeuten, dass die Benutzerbasis erweitert wird oder neue Features in Betracht gezogen werden. Manchmal wird in den letzten Sprints genauso viel benutzerzentrierte Designarbeit geleistet wie in den ersten, oder es wird in den ersten Sprints genauso viel programmiert wie in den letzten. Wenn dieses Ideal jedoch nicht erreicht wird, kann sich das Team so weit wie möglich anpassen, indem es sich gegenseitig unterstützt, um den aktuellen Anforderungen gerecht zu werden. Falls erforderlich, kann jedes Mitglied an Funktionen teilnehmen, die nicht seiner typischen Rolle entsprechen.

Messen Sie die Produktivität anhand des Werts und nicht anhand des Volumens.

Da die Produktivität an der Qualität des Benutzererlebnisses gemessen wird, müssen Designer überprüfbare Funktionen und Entwickler einen Weg finden, diese Funktionen bereitzustellen, damit sie von echten Benutzern so früh wie möglich im Projekt erlebt und validiert werden können. Designer müssen Annahmen testen und validieren, bevor die vollständige Funktionalität bereitgestellt wird.

Eine Reihe von Fallstricken kann zu einem schlecht laufenden HCD / Agile-Projekt führen. Beispielsweise stellen Entwickler manchmal zu Beginn des Projekts keine testbaren Funktionen bereit - entweder weil sie technischen Problemen und der Architektur eine höhere Priorität einräumen, oder weil sie sich einfach nicht vorstellen können, wie sie frühzeitig testbare Funktionen erstellen können. Dieses Problem wird durch die rote Linie in der folgenden Grafik dargestellt. Es ist ein grundsätzlicher Fehler, weil es den Designern nichts gibt, was sie mit den Benutzern testen könnten. Dies verhindert, dass das Design wiederholt wird. Es liegt in der Verantwortung der Entwickler, ihre ganze Kreativität einzusetzen, um stattdessen die grüne Linie zu produzieren. Dies bietet den Benutzern so schnell wie möglich einen hohen Wert an testbarer Funktionalität.

Die magentafarbene Linie repräsentiert die Wasserfallentwicklung. Bis zum Ende des Projekts wird kein Benutzerfeedback eingeholt. Die magentafarbene Linie erreicht möglicherweise nicht ganz den Punkt „Ablösbares Produkt“, da viele Waterfall-Projekte überhaupt nichts veröffentlichen. Wenn es dann zu spät ist, wird das Wissen über die tatsächlichen Bedürfnisse des Benutzers drastisch offensichtlicher, so wie das Verständnis eines Studenten für Physik in den 20 Minuten nach einer Abschlussprüfung drastisch zunimmt.

Das gesamte Team muss darauf vorbereitet sein, dass eine Verlagerung von der ursprünglichen Absicht zu etwas erforderlich sein kann, das sich als noch besser herausgestellt hat.

Das obige Diagramm lässt es so aussehen, als ob überprüfbare Funktionalität und Weisheit im Laufe der Zeit nahtlos zusammenwachsen. Im Allgemeinen stimmt dies, aber das Team muss bereit sein, drastische Probleme oder unerwartete Gelegenheiten zu lösen. Zum Beispiel kann das Team in der Mitte des Projekts feststellen, dass eine weitaus großartigere Gelegenheit besteht. Es kann Mut erfordern, ein solches Ereignis zu erkennen und zu validieren, das wir als „Transformations-Pivot“ bezeichnen. Sie müssen zugeben, dass ein Großteil Ihrer bisher geleisteten Arbeit nur wertvoll ist, um Ihnen beizubringen, dass Ihr aktueller Pfad korrigiert werden muss. Trotzdem ist es nur effektiv, sofort im besten Interesse des Benutzers zu arbeiten.

Befolgen Sie die obigen Vorschläge, und halten Sie die Benutzer an erster Stelle. So können agile Teams auch in schwierigen Regierungsprojekten zusammenarbeiten, um die Grundsätze agiler Methoden und des Human Centered Design erfolgreich miteinander zu verbinden.

Über AGL:

Agile Government Leadership ist eine Gruppe von agilen Fachleuten, die Regierungserfahrung und -perspektive aus Bund, Ländern, Gemeinden und der Industrie einbringen. Auf unserer Website finden Sie kostenlose Ressourcen, Neuigkeiten, Schulungen, Fallstudien und mehr: www.agilegovleaders.org