Get best of the week

5 Regeln für die Integration von UX in Agile und Scrum

Eine Übersetzung des Artikels wurde vor dem Start des Agile Project Manager im IT- Kurs vorbereitet .



Als ich gerade meine Karriere begann, kam die Software in Kartons. Wenn Ihnen das komisch vorkommt, wissen Sie, dass mein Vater als Kind Lochkarten mit nach Hause gebracht hat, auf denen in den 1970er Jahren Programme aufgenommen wurden. Eine solche Software hatte einen Endzustand. Nach 20 Jahren schien es schon lächerlich. Heute schaffen wir Systeme, die endlos verbessert werden können. Dies wirft die Frage auf: "Wann endet die Arbeit?" - und diese Frage ist schwer zu beantworten. Wir suchen nach der Antwort auf diese Frage, weil sie uns hilft, andere, noch wichtigere Fragen zu beantworten. Bekommt das Team seinen Preis oder wird es gemeldet? Wird das Team etwas Neues machen? Wird der Stakeholder davon profitieren?

Entwicklungsteams, die Scrum (oder eine andere Variante der Agile-Methodik) verwenden, haben eine klare Vorstellung davon, wann die Entwicklung endet. Oft bedeutet dies "eine Reihe von Mindestkriterien, die ein Produkt / eine Dienstleistung erfüllen muss, um die Anforderungen des Unternehmens zu erfüllen." Infolgedessen kommt es auf eine Liste von Funktionen an, die vom Stakeholder (oder Product Owner) genehmigt wird und zum Zeitpunkt des Abschlusses des Projekts vollständig implementiert werden muss. Die Entwickler nennen es "funktioniert wie beabsichtigt".

"Arbeiten wie beabsichtigt" bedeutet jedoch nur, dass die Software das tut, was sie von ihr will. Leider reicht das manchmal nicht aus. Tatsächlich ist dies nur der Beginn eines Gesprächs, das wir kontinuierlich mit unseren Benutzern und Kunden führen. Es ist die kontinuierliche Verbesserung unserer Systeme, um eine bessere Erfahrung zu bieten, die ihnen einen echten Wert verleiht.

Wie können wir also "Herunterfahren" für ein Team definieren? Wann startet ein Team ein neues Projekt? Das Fehlen eines ROI ist ein guter Anfang, aber woher wissen wir, dass es keine Amortisation gibt? Die Antwort erhalten Sie von den Kunden. Wir schauen uns ihr Verhalten an. Wir hören auf ihre Bedürfnisse, bewerten, ob unsere Systeme diese Bedürfnisse erfüllen, und überlegen, was wir tun können, um diesen sich ständig ändernden Anforderungen gerecht zu werden. Wir nennen diese Metriken die Ergebnisse.

Und diese Ergebnisse können nicht vorhergesagt werden, genauso wie es unmöglich ist, menschliches Verhalten vorherzusagen. Für gute Ergebnisse müssen sich die Teammitglieder aktiv mit Kunden auseinandersetzen, um Änderungen in ihrem Verhalten, die Gründe für ihr Auftreten und die Möglichkeiten zu erkennen, die Kundenbedürfnisse in Zukunft besser zu erfüllen. Die gute Nachricht ist, dass Ihr Unternehmen höchstwahrscheinlich bereits Mitarbeiter beschäftigt, die in diesen Aspekten besonders gut sind - Designer. Trotz der Tatsache, dass Designer heute in fast jedem Unternehmen präsent sind, besetzen die meisten von ihnen nicht genügend Positionen, um die Annahme großer Entscheidungen zu beeinflussen. Tatsächlich bleiben viele von ihnen für agile Entwicklungsprozesse aus dem Weg, die auf Programmierer und Produktmanager zugeschnitten sind.

Die Integration von Designern in den agilen Entwicklungsprozess ist für viele Unternehmen ein ständiges Problem. Dank fast 20 Jahren Erfahrung im Entwerfen, Verwalten und Beraten von Produktteams habe ich die folgenden 5 Regeln festgelegt, die ein Team befolgen muss, um sicherzustellen, dass User Experience (UX) erfolgreich in seinen agilen Prozess integriert wird:

1. Für jedes Team ein eigener Designer Teams

Es kann keine Kompromisse geben. Ohne den „eigenen“ Designer im Scrum-Team haben Sie einfach ein Entwicklungsteam, das ohne einen Designer nicht die angemessene Qualität der Benutzererfahrung bieten kann.

2. Arbeitsstunden im Team mit Kunden

Diese Regel habe ich von Jared Spool gelerntWer eine Studie durchgeführt hat, die belegt, dass Teams, die alle 6 Wochen mindestens 2 Mannstunden verbringen, mit Kunden kommunizieren (z. B. Supportanrufe erhalten, mit Benutzern sprechen, Leute beobachten usw.), entwickeln sich erfolgreicher Produkte.

3. Die Arbeit des Designers ist der erste Punkt des

Rückstands. Kurz gesagt: Behalten Sie einen einzelnen Rückstand bei. Entwicklung, Qualitätskontrolle, Design, Forschungsarbeit - all dies sollte in einem Rückstand liegen, der vom gesamten Team, das diese Arbeit ausführt, priorisiert wird. Sobald die Arbeit in zwei Rückstände aufgeteilt ist, wählt das Team einen von ihnen aus und beschließt, ihn als den „Hauptbestandteil“ zu behandeln, und der zweite wird ihn einfach in den Rückstand legen.

4. Ergebnisse als Priorisierungs Filter für Backlog

Ich schrieb eine Menge über die Ergebnisse (und Josh Seyden hat ein ganzes Buch darüber geschrieben ), aber das einzige, was ich im Zusammenhang mit dem heutigen Thema beachten möchte, ist, dass jedes Backlog-Element den Endzielfilter des Teams durchlaufen muss. Fragen Sie sich: "Wird diese Arbeit helfen, das Ziel zu erreichen?" Wenn die Antwort Nein lautet, lassen Sie diesen Artikel fallen.

5. Funktionsübergreifendes Training

Benutzererfahrung und Design enthalten viele interessante Dinge, die es wert sind, erkundet zu werden. Solche Veranstaltungen können von Designern (oder Analysten) durchgeführt werden, müssen jedoch vom gesamten Team geübt und besucht werden. Je mehr ein Team gemeinsam lernen kann, desto weniger Zeit wird benötigt, um das gewonnene Wissen zu teilen, und desto mehr wird entschieden, wo es angewendet werden soll (was für das Team ein produktiveres Gesprächsthema ist).

Der iterative retrospektive Charakter von Scrum eignet sich gut für UX- und Designaktivitäten. Die Integration von Kundenerkenntnissen in den Arbeitsprozess erfolgt direkt aus dem Agile Manifest (Arbeit mit Kunden usw.). UX und Design bringen uns dem agilen Ziel der Kundenorientierung und besseren Kundenzufriedenheit näher. Befolgen Sie diese 5 Regeln, um Design und agile Entwicklung zu kombinieren.


.

More articles:


All Articles