Ich versuche, ein UX-Team von etwa 14 UX-Designern in eine Software-Engineering-Organisation von etwa 100 Entwicklern zu integrieren. Eine der vielen Herausforderungen, die ich zu lösen versuche, ist der Umgang mit Dingen wie Usability-Tests. Ich arbeite hier mit vielen Annahmen (bitte korrigieren Sie mich, wenn dies schlechte Annahmen sind):
Die Arbeit des UX-Teams sollte als User Stories im Backlog stehen. Klarstellung – im Moment gibt es einen Design-Rückstand und dann einen Konstruktions-Rückstand. Wir sind also kein „Full Stack“.
Eine User Story sollte in einem Sprint abgeschlossen werden können.
Also hier meine Frage:
Macht es Sinn, eine User Story für einen Usability-Test zu schreiben? Es scheint nicht benutzerorientiert zu sein. Zum Beispiel: "Als Benutzer möchte ich, dass die Anwendung auf ihre Benutzerfreundlichkeit getestet wird, damit wir Probleme erkennen und beheben können." Was? Das ist Unsinn. Wie sollen wir solche Aufgaben in unser Backlog integrieren?
Die Durchführung eines Usability-Tests dauert in der Regel mehr als 4 Wochen. Wir müssen die Teilnehmer rekrutieren (sehr enge demografische Gruppe), den Test planen, den Test durchführen und dann über den Test berichten. Das alles schaffst du nicht in einem 2-Wochen-Sprint. Was jetzt? Wie schreibe ich eine Geschichte für etwas Kleineres als den vollständigen Usability-Test? Eine Geschichte nur für das Schreiben des Testplans, dann eine andere Geschichte für die Rekrutierung der Teilnehmer? Das scheint die Definition einer User Story wirklich zu sprengen.
Ihre Frage ist über die Integration in ein Scrum-Team betitelt, aber es hört sich so an, als wären Sie nicht so organisiert, wie es ein typisches Scrum-Team wäre
Typischerweise sind Ihre UX-Designer Teammitglieder, sie entwickeln Software, genau wie Ihre Programmierer.
Sie sollten keine User Storys für UX-Aufgaben erstellen. User Stories sollten die INVEST-Kriterien erfüllen . UX-Aufgaben würden wahrscheinlich gegen Folgendes verstoßen:
Stattdessen sollten Sie einen UX-Designer in Ihre Engineering-Teams einbetten und die UX-Aufgaben in Ihre Definition of Done integrieren.
Ihr Team (das heißt Programmierer und UX) übernimmt die Verantwortung für die Erledigung aller UX-Arbeiten. Selbstorganisierende Teams bedeutet, dass, wenn der einzelne UX-Typ zu viel Arbeit zu erledigen hat, die anderen Teammitglieder auch helfen sollten. Das bedeutet, dass sie zusammenarbeiten müssen, um die Aufgaben zu erledigen.
Was Ihren zweiten Punkt betrifft, so hört es sich so an, als würden Sie einen Wasserfallprozess auf Ihre UX-Tests anwenden. Dies wird die Geschwindigkeit begrenzen, mit der Sie Software freigeben können. In Scrum sollte jeder Sprint potenziell auslieferbare Software liefern. Wenn Sie keine UX-Tests durchgeführt haben, sollten Sie nicht veröffentlichen. Sie sollten versuchen, Ihre UX-Arbeit in ausreichend kleine Abschnitte zu unterteilen und eng mit Entwicklern zusammenarbeiten, um UX für neu erstellte Funktionen zu erstellen.
Sie haben nicht wirklich genug Details über die Art der Arbeit gegeben, die das UX-Team leistet, daher ist es schwierig, mehr Ratschläge zu geben als die Anwendung von Standard-Scrum-Praktiken.
Der beste Ort, um diese Anforderung zu erfüllen, wäre die Definition of Done Ihres Teams. Eine Prozessrichtlinie zur Qualitätssicherung.
Sprechen Sie mit Ihrem Team darüber, wie Sie die Usability im Sprint-Zyklus am besten testen können. Ich bin mir sicher, dass sie viele interessante Ideen haben werden, und eine Definition-of-Done-Richtlinie gehört am besten dem Team. Einige Vorschläge könnten sein;
Pair devs with UX
Have UX reviews
Get an end user to UAT
Sie werden feststellen, dass dieser Ansatz bedeutet, dass ein vollständiger Usability-Test am Ende eines festgelegten Zeitraums weniger schmerzhaft ist.
Es hört sich auch so an, als würden Ihre Usability-Tests lange dauern. Darf ich vorschlagen, dass Sie sich Steve Krugs neues Buch Rocket Science Made Easy ansehen http://www.amazon.com/gp/aw/d/0321657292/ref=redir_mdp_mobile/184-1692377-5775040
Wenn Sie alle 2 bis 4 Wochen Software veröffentlichen, können Sie den Usability-Test an einem tatsächlich veröffentlichten Produkt außerhalb des Sprints durchführen, aber so schnell wie das Feature fertig ist. Sie erhalten Feedback und das geht zurück in den Rückstand. Bis Sie das Feedback erhalten, konnten Sie ein funktionierendes Produkt veröffentlichen.
Wenn Sie das alles in einem Sprint schaffen, tun Sie es auf jeden Fall. Wenn dies nicht der Fall ist, führen Sie die Tests außerhalb des Sprints durch, aber versuchen Sie nicht, das Scrum-Team die ganze Arbeit zur Vorbereitung der Tests erledigen zu lassen.
Einige kleine Tests, wie z. B. die Verwendung der Funktionen durch tatsächliche Benutzer, bevor sie überhaupt eingecheckt sind, sind ideal. Wenn Sie ein paar Endbenutzer auf Abruf haben, denen Sie einige Ihrer Arbeiten zeigen können, können Sie in sehr kurzer Zeit sehr schnell Feedback geben.
Stellen Sie einfach sicher, dass die Zeit zwischen der Veröffentlichung des Produkts (auch wenn es sich um eine Beta oder einen Release Candidate handelt) und dem Erhalt Ihres Feedbacks so kurz wie möglich ist. Sonst kommt die Rückmeldung zu spät und die Nachbearbeitung wird viel teurer.
Aus eigener Erfahrung empfehle ich:
Usability in die Akzeptanzkriterien einbeziehen. Wenn es fehlschlägt, muss man die Geschichte wiederholen. Im selben Sprint oder im nächsten Sprint – wann immer es Zeit und Priorität gibt
Du musst deine Anstrengung reduzieren. Rekrutieren Sie die Teilnehmer immer mit einem 2-Wochen-Timing (abhängig von der Sprintlänge). Kümmern Sie sich nicht darum, was Sie ihnen zeigen.
Überprüfen Sie einen Tag vorher, was fertig ist und funktioniert, und zeigen Sie es ihnen. Erstellen Sie eine Art Standardtestplan, um Zeit zu sparen.
Laden Sie Programmierer oder Produktmanager als Beobachter zu Ihren Tests ein oder filmen Sie diese. Nach dem Test kurz besprechen und eine Powerpoint-Präsentation zusammenstellen, um sie am nächsten Tag dem Entwicklerteam zu zeigen. Zeigen Sie ggf. das Video.
Sprechen Sie mit dem Entwicklerteam über Ihre Empfehlungen und das war's! Es wird kein 10-Pager mehr benötigt, es wird über den Mund transportiert, von Angesicht zu Angesicht.
Es ist eher ein Testen von Teilen der Software. Nach einiger Zeit kann es sinnvoll sein, alle zusammen in einem klassischen Usability-Test zu testen.
Auch hier kann ich den Ucd UX Blog vom Autodesk UX Team empfehlen. Sie haben gute Tipps für effizientes Recruiting, aber ich kann sie gerade nicht finden.
Verloren im Agilen Land