Kto zajmuje się UX w projekcie scrum?

OK. Powiedzmy, że pracujesz nad projektem podręcznika scrum. Scrum Master współpracuje z właścicielem produktu. Następnego sprint UI jest ciężki - w momencie rozpoczęcia budowy twoi kodery ekrany, naprawdę chcesz mieć jakiś pomysł, co oni będą wyglądać.

Kto i kiedy wykonuje szkielet? Właściciel produktu? Ktoś wspiera właściciela produktu? Mistrz Scrum? Jeśli masz eksperta od UX, czy pracują oni razem z programistami po rozpoczęciu sprintu, czy też dostarczają szkielety i makiety z góry, które stoją obok twoich kart opowieści i ograniczeń, aby poprowadzić i poinformować o pracy, którą wykonują programiści?

Widzę, jestem pewien, że potrzebujemy pomocy UX, ale nie jestem pewien, gdzie ją zastosować ...

EDYCJA: Pozwól mi przeformułować pytanie.

Jak zapewnić spójne, wysokiej jakości wrażenia użytkownika w zwinnym projekcie?

Projektant interakcji

UX! = UI Potrzebujesz doświadczonego projektanta interakcji, aby zapewnić dobrą obsługę, w przeciwieństwie do powszechnego przekonania, że nie jest programistą. Wszystkim z was, programiści, którzy myślą, że mogą używać UX (w tym mnie), powiem to. Osiągnięcie dobrego poziomu projektowania interakcji wymaga co najmniej tyle samo czasu, co dobrego programowania. Ile czasu spędziłeś na projektowaniu interakcji?

W początkowej fazie projektanci interakcji mają obowiązek:

1. Wydobywanie rzeczywistych celów rozwiązania od właściciela produktu
2. Zdefiniuj osoby, które będą korzystać z rozwiązania.
3. Napisz scenariusze, które są opowieściami o tym, jak zostanie zastosowane rozwiązanie.
4. Skompiluj dokument projektowy, który pozostawia mało miejsca na dwuznaczności z punktu widzenia UX

Podczas projektu zadaniem projektantów interakcji jest upewnienie się, że przestrzegane są te wytyczne i rozwiązać wszelkie dodatkowe problemy, które pojawią się (i będą).

Jestem pewien, że wielu programistów zajmie się tym podejściem, ponieważ wszyscy uważają, że są wyjątkiem, który może zaprojektować „wspaniałe” interfejsy, prawdopodobnie nie jesteś. Z drugiej strony dobry stosunek interakcji projektant - programista jest często bardzo miły dla programisty, ponieważ nie muszą oni walczyć z „głupią specyfikacją”. Niestety, z mojego doświadczenia trudno znaleźć dobrych projektantów interakcji, ale są tam.

Jak zawsze bardzo polecam książki Alana Coopersa na ten temat („O twarzy” i „Więźniowie prowadzą azyl”)

Proponuję zorganizować pracę faceta UX w taki sam sposób jak reszta zespołu. Powinien być uważany za równego członka zespołu, uczestniczyć w awansach i ściśle komunikować się z programistami.

Najlepiej byłoby, gdyby makiety wykonano co najmniej jeden sprint z wyprzedzeniem, ale w przypadku mniejszych funkcji warto rozważyć utworzenie makiet jako podzadania opowieści zaplanowanej na bieżącą iterację.

Jak zawsze w przypadku zwinności, kieruj się zdrowym rozsądkiem, eksperymentuj z różnymi podejściami i trzymaj się tego, który działa dobrze w danej sytuacji.

Moim zdaniem jest to jakoś szczególny przypadek, który należy traktować w specjalny sposób. Scrummaster na pewno nie weźmie w tym udziału - to wcale nie jest jego rola. Zespół jest zwykle grupą programistów i większość z nich nie ma doświadczenia z UX i zmusi ich to do zmarnowania czasu. Zatrudnisz eksperta UX, a ekspert nie będzie częścią zespołu - zespół powinien być funkcjonalny, a ekspert UX prawdopodobnie nie będzie programistą. Również ekspert UX nie będzie w projekcie przez cały czas jego trwania. Ekspert UX będzie współpracował z właścicielem produktu o jeden sprint do przodu, aby przygotować makiety i makiety do nadchodzących historii użytkowników, aby zespół wiedział, co trzeba będzie zrobić w kolejnym sprincie - makiety będą dostępne podczas spotkania planistycznego.

Edytować:

Przeprowadziłem dodatkowe badania, ponieważ wiedziałem, że gdzieś o tym czytałem, i wreszcie znalazłem je w książce Successful with Agile: Software Development using Scrum autorstwa Mike'a Cohna . Mike dokładnie omawia rolę projektanta UX w zespole. Jego początkowy opis jest podobny do mojego i uważa, że ​​to naturalne przesunięcie, gdy firma zmienia metodę rozwoju z wodospadu na Scrum, ale później stwierdza, że ​​nie jest to zalecany sposób. Powodem jest to, że jeśli projektanci UX nie są częścią zespołu, mogą myśleć o sobie jako o osobnym zespole i nie muszą dzielić zaangażowania zespołu programistów.

Mimo to odpowiedź @Adama Byrtka wygląda jak poprawna. Spraw, by UX stał się częścią zespołu i pozwól mu współpracować z programistami w zakresie obecnie wdrażanych historii użytkowników. Facet z UX nie będzie musiał cały czas, więc będzie również współpracował z właścicielem produktu lub klientem, aby przygotować makiety i szkielety na nadchodzący jeden lub dwa sprinty.

Jestem subskrybentem alertu Jakoba Nielsena (głównie z powodu jego krytyki irytujących praktyk projektowania stron internetowych) i przypominam sobie, że ostatnio czytałem kilka artykułów na ten temat (chociaż nie mam najmniejszego pojęcia o całym zwinnym procesie rozwoju), być może byłyby to jakiegokolwiek zastosowania dla ciebie:

• Projekty Agile User Experience
• Zwinne projekty rozwojowe i użyteczność

W przypadku „podręcznika Scrum”:

Po pierwsze, Scrum Masters nie współpracują z Właścicielami Produktów - cóż, w żadnym sensie poza tym, że cały zespół, w tym SM i PO współpracują przy budowie systemu.

Po drugie, zespoły Scrumowe powinny być jednorodne z członkami zespołu funkcjonalnego. Więc nie miałbyś „UX Guy”.

Ponadto prawdopodobnie nie zbudowałbyś UX a Sprint przed kodem funkcjonalnym. Funkcje są dostarczane całkowicie w ramach jednego Sprintu. Jeśli interfejs użytkownika związany z funkcją jest zbyt skomplikowany, aby dostarczać go wraz z kodem funkcjonalnym w jednym sprincie, wówczas cała funkcja jest podzielona na coś, co można zrobić, łącznie z elementami UX, w jednym sprincie.

Kto robi UX przy projekcie wodospadu? Kto opracowuje mainframe w projekcie XP?

Metodologia projektu nie ma znaczenia. Każdy projekt technologiczny wymaga pewnych wyspecjalizowanych ról. Czasami projekt może uciec bez w pełni licencjonowanego i powiązanego „projektanta interakcji” (cokolwiek to oznacza). Czasami potrzebujesz kogoś, kto się specjalizuje. To samo można powiedzieć o każdej innej roli.

Tak więc na drugie pytanie, w jaki sposób zapewniasz wysoką jakość obsługi dzięki zwinnemu. Udało nam się to w ostatnim projekcie scrum, w który byłem zaangażowany, angażując analityka biznesowego i klienta wcześnie i często. Ponadto mieliśmy programistę, który miał szczególnie dobre oko do UX. Miał tendencję do drobnych poprawek do interfejsów użytkownika, nad którymi pracowali deweloperzy po dokonaniu zmian.

Nie zapewnialiśmy idealnego UX na koniec każdego sprintu. Dema ogólnie ujawniały problem lub dwa z perspektywy UX. Ale naprawiliśmy je na następny sprint (jeśli były tego warte dla klienta) i do czasu, gdy weszliśmy do produkcji, mieliśmy bardzo solidny UX.

Jeśli przez UX masz na myśli projektanta interfejsu użytkownika, są one po prostu kolejną rolą lub zasobem dla zespołu. Projekt interfejsu użytkownika, jak każdy projekt, przecina projekt. Istnieje rozsądna ilość prac związanych z architekturą / projektowaniem, które należy wykonać z góry, i jest pewna ilość, którą można wykonać w miarę postępów.

Należy zauważyć, że zadania projektowania interfejsu użytkownika często nie mieszczą się w tym samym zakresie, co sprint programistyczny. Podczas projektowania komponentu interfejsu użytkownika jego wdrożenie może wymagać wielu sprintów.

W praktyce wydaje mi się, że projektanci UI / UX potrzebują rozsądnego czasu realizacji, aby poradzić sobie z aspektami, które muszą być spójne w całym rozwiązaniu. Lubię myśleć o tym jak o architekturze oprogramowania. Przed wdrożeniem często można wykonać projekt konkretnego komponentu, ale zwykle stwierdzam, że gdy projektanci rozpoczną pracę, mogą znacznie przyspieszyć wdrożenie. Późniejsze sprinty są zwykle dobrym miejscem do wdrażania / eksplorowania wyglądu i dotyku, a także uzyskiwania informacji zwrotnych dotyczących użyteczności, gdy rozwiązanie zaczyna nabierać kształtu. Wyniki tych późniejszych ćwiczeń są uwzględniane w planowaniu następnego sprintu.