Bazując na własnym doświadczeniu, stworzyliśmy w Usability LAB i RST Software Masters listę 10 reguł, które pomogą podczas włączania do procesu scrumowego i zespołu developerskiego UX designera. Czas na dokończenie wątku i prezentację drugiej część listy.

Jeżeli interesuje Cię pierwsza część artykułu, zapraszamy do lektury wpisu: O czym warto pamiętać włączając UX-a do zespołu scrumowego cz. 1.

Ux in Scrum - RST Software Masters Blog

 

6. Sprinty muszą być zaplanowane również pod kątem prac UX.

Zespół scrumowy dba o to, by historie na dany sprint były dobrze opisane, miały precyzyjnie określone kryteria akceptacji, nie powodowały blokad czy niepotrzebnych zależności, nie były zbyt obszerne, wreszcie żeby były do zrealizowania w ramach planowanego sprintu.

Takie samo podejście powinno towarzyszyć planowaniu prac UX-owych. Tymczasem przy moim pierwszym projekcie w scrumie spotkałem się z tym, że moje zadania były wrzucone do jednego sprintu jako 2 historie: „Przepływ i makieta aplikacji mobilnej” oraz “Przepływ i makieta aplikacji webowej”. Wszystko ok pod warunkiem, że planujemy sprinty minimum 2-miesięczne :).

 

7. UX designer pomaga tworzyć backlog, a potem realizuje ustalone MVP.

Aby backlog był odpowiednio przygotowany, UX designer musi brać aktywny udział w jego tworzeniu, bo przecież on wie najlepiej, jakie prace będzie musiał wykonać i na ile historii najlepiej je podzielić.

 

Udział w tworzeniu backlogu i określeniu MVP ma też “dyscyplinować” designera.

Nie czarujmy się – UX-owcy (a wiem to po sobie) mają tendencję do wymyślania rozwiązań idealnych, dopracowanych, optymalnych. Często z całym inwentarzem dodatkowych funkcjonalności czy “wisienek na torcie”.

Ważne jest, by koncentrować się na tym, co jest potrzebne w bieżącym i nadchodzącym sprincie, a nie dopiero w wersji 7.0. produktu. UX designer jest trochę jak dziecko w sklepie ze słodyczami – potrzebuje, by ktoś go kontrolował. Dobrze ułożony backlog i PO czuwający nad tym, co ma być dostarczone w najbliższym czasie, powinny spełnić to zadanie.

 

8. UX designer potrzebuje informacji zwrotnej od developerów.

UX designer nie jest osobą techniczną. I nie musi być, pamiętaj o tym. Dlatego tak ważne jest, by proponowane przez niego rozwiązania były omawiane (np. na etapie refinementu), zanim pójdą do wdrożenia. Inaczej może się okazać, że funkcjonalności przedstawione na makietach są niewykonalne techniczne lub bardzo drogie w implementacji.

Może się też zwyczajnie zdarzyć, że nie dysponując wiedzą, którą mają developerzy, UX-owiec na nowo wynalazł koło lub wytoczył działo, by ustrzelić komara. By uniknąć takich sytuacji, niezbędny jest feedback od osób, które mają dane rozwiązanie wytwarzać.

 

UX Designer in Scrum Team - RST Software Masters

 

9. Zmiany to rzecz normalna, ale trzeba je wspólnie akceptować i planować.

Projektowanie UX to proces przebiegający w iteracjach. Poprawki, optymalizacje czy zmiany wymagań są nieuniknione, trzeba taki stan rzeczy zaakceptować. Tym bardziej, jeżeli UX designer ma dostarczać rozwiązania ze sprintu na sprint, nie tworząc makiety od A do Z przed procesem developerskim.

Zespół developerski musi mieć tego świadomość i podchodzić do tego ze zrozumieniem, z kolei UX-owiec musi pamiętać, że zmiany nie zrobią się same z siebie – wpierw trzeba je w ogóle zakomunikować i przegadać z zespołem oraz PO. 


Dobrą praktyką w naszym zespole okazało się„zamrażanie” makiety przewidzianej do wdrożenia w nadchodzącym sprincie.

Oznaczało to, że widoki zaakceptowane na refinemencie, a potem wciągnięte do historii podczas planowania sprintu, nie powinny już ulegać zmianom w tym samym sprincie, zwłaszcza gdy zostały już wzięte na warsztat przez developerów.

Nie mówimy oczywiście o sytuacji, gdy coś wymaga ewidentnie zmiany w trakcie pracy. Jeśli jednak wpadamy na pomysł, który zoptymalizuje coś, zmieni, ulepszy, poprawi, musimy to otwarcie komunikować zespołowi – i ustalać, czy możemy to zmienić w tym sprincie, czy może wciągamy to dopiero do następnego lub w ogóle zostawiamy na dalszy etap rozwoju produktu.

 

10. UX też może testować i odbierać prace.

Niemałym zaskoczeniem dla zespołu deweloperskiego bywa, gdy UX designer prosi o link do podglądu ich pracy, po czym przesyła listę uwag i proponowanych zmian lub poprawek. Jak to? Przecież mają już w zespole testera, który się tym zajmuje. 

Pamiętaj jednak, że UX-owiec sprawdza wdrożenie na zgodność z makietami (często również z layoutami graficznymi), na poprawność mechaniki poszczególnych funkcjonalności – jednym słowem, sprawdza rozwijany produkt pod kątem user experience.


Idealnie, jeżeli w projekcie przeznaczony jest czas na testy z użytkownikami

Wtedy feedback jest pełniejszy i – co ważniejsze – z najlepszego źródła. Traktuj tę dodatkową parę rąk i oczu chętnych do testowania tego, co za chwilę będzie oglądał klient, a potem użytkownicy końcowi, jako dodatkową przewagę Twojego zespołu nad innymi, pozbawionymi udziału UX-owca, nie jako uciążliwą niedogodność.

 

 

Czy powyższe rady wyczerpują temat włączenia UX designera do zespołu scrumowego? Pewnie nie. Bardzo możliwe, że kolejne projekty, w których wezmę udział, przyniosą dalszą wiedzę i pomysły na dobre praktyki. Szczerze jednak wierzę, że pamięć o tym, co spisane powyżej, ułatwi organizowanie prac w zespołach wzbogaconych o UX-a, przede wszystkim zaś pozwoli uniknąć uczenia się na własnych błędach 🙂

 

Jeżeli interesuje Cię pierwsza część artykułu, zapraszamy do lektury wpisu: O czym warto pamiętać włączając UX-a do zespołu scrumowego cz. 1.

Poznaj nas bliżej.

 

Udostępnij
Czy ten artykuł był pomocny?
Tak2
Nie1