Projektanci UX pracujący o jeden Sprint do przodu

13

Nasi projektanci UX zwykle mają historię w Sprint X, którą programiści zaimplementują w Sprint X + 1 (Projektanci UX i deweloperzy / testerzy są w jednym zespole). Myślę, że ma to sens, ponieważ jeśli nie masz makiet ekranu i jasnych specyfikacji, nie możesz tak naprawdę oszacować pracy podczas planowania sprintu.

Jednak w Scrumie powinieneś mieć tylko historie użytkowników, które zapewniają wartość dla użytkownika. W naszym przypadku historie projektowania UX nie zapewniają takiej wartości (bardziej przypominają czynności związane z pielęgnowaniem zaległości). Zwykle trenerzy Scrum nie zalecają posiadania pełnych specyfikacji przed rozpoczęciem sprintu, co jest dla mnie trudne do zrozumienia.

Czy widzisz jakieś wady naszego podejścia? Wygląda na to, że działa dla nas, ale jest nieco sprzeczne z zasadami Scruma.

Eugene
źródło
3
Dlaczego projekt UX nie zapewnia wartości dla użytkownika? Zakładając, że nadal będziesz przeszukiwać i nadal używasz projektantów UX, nie widzę, że istnieje alternatywa, a jeśli nie masz alternatywy, w jaki sposób mogą wystąpić wady?
Michael Shaw,
Ponieważ makieta ekranu i lista wymagań interfejsu użytkownika nie zapewniają bezpośredniej wartości dla użytkownika. Zapewniają one wartość dopiero po zaimplementowaniu w historii następnego sprintu.
Eugene
Problem może polegać na tym, że nie masz projektantów lub inżynierów UX, masz grafików. Używają tylko Photoshopa, prawda? Nie masz CSS JS, XAML, czy konstruktora interfejsów, ani żadnych dodatkowych narzędzi technicznych? Więc nie masz projektantów. Potrzebujesz prawdziwych projektantów. Wtedy nie będziesz miał tego zamieszania.
RibaldEddie
Nie. Mamy zarówno projektantów interakcji z użytkownikiem, jak i grafików. Oba pracują o jeden sprint przed rozwojem
Eugene
10
W jaki sposób interakcja z bazą klientów przy użyciu makiet i prototypów nie przynosi wartości użytkownikowi? Wartość nie jest zdefiniowana jako kod wysyłki. Namacalność jest bardzo dobra, ale nie jest niezbędna z punktu widzenia wartości.
BobDalgleish

Odpowiedzi:

15

Jednak w Scrumie powinieneś mieć tylko historie użytkowników, które zapewniają wartość dla użytkownika.

Wartość nie jest mierzona tylko w wierszach kodu wysyłki.

Wydaje się, że sugerujesz, że dobrze zaprojektowany interfejs użytkownika nie zapewnia żadnej wartości. Oczywiście, że tak. Oczywiście dla użytkownika końcowego jest wartość, ale dla zespołu programistów, który jest w pełni uzasadnionym interesariuszem, ma również wartość. Jeśli nie masz narzędzi i materiałów do wykonania swojej pracy, nie możesz dostarczyć wartości końcowej użytkownikowi.

Nie rozłączaj się z dogmatami Scrum. Scrum ma na celu zwiększenie wydajności. Jeśli wykonanie historii UX jeden sprint przed wdrożeniem interfejsu użytkownika pomaga dostarczyć lepsze oprogramowanie, zrób to.

Bryan Oakley
źródło
2
„Pracujące oprogramowanie jest podstawową miarą postępu.”, Nie UX. UX jest nic nie warte, jeśli nie działa oprogramowanie. Miałbyś rację, gdybyś zalecał posiadanie UX w tym samym czasie lub później z rzeczywistą funkcją, ale tak nie jest, więc ta odpowiedź jest całkowicie błędna.
Sklivvz
3
@Sklivvz: Chyba musimy się zgodzić. Chociaż prawdą jest, że działające oprogramowanie jest podstawową miarą postępu, nie jest to jedyna miara. Część zespołu musi zostać wykonana z góry, zanim zespół będzie mógł zacząć kodować. UX nie jest czymś, na co można się po prostu przyczepić.
Bryan Oakley
4
@BryanOakley Zgadzam się, że należy przemyśleć całą pracę z góry, nie tylko ux. Jednak o wartości tej pracy decydują zainteresowane strony. Jeśli praca nad systemem jest wykonywana o jeden sprint naprzód, pętla sprzężenia została właśnie przedłużona o co najmniej jeden sprint. Sugerowałbym, że jest to niepotrzebne ryzyko. UX nie różni się od projektu, architektury, projektu bazy danych lub formatu raportu. Można to wszystko zrobić w jednym sprincie, z elementami rejestru zaległości produktu, które są tworzone jako pionowe segmenty funkcjonalności.
Derek Davidson PST CST
Można to zrobić w jednym sprincie, ale nie wiedząc, jakie będzie doświadczenie użytkownika, jak możesz zaplanować resztę pracy? Jeśli nie znasz szczegółowego projektu oprogramowania, nadal możesz zaplanować pracę. Ale jeśli nawet nie wiesz, jak będzie wyglądał ekran i funkcjonalność, jak możesz cokolwiek zaplanować?
Eugene
1
Pracując stopniowo, jak zwykle zwinny sposób. Programiści produkują prototyp we współpracy w czasie rzeczywistym z projektantem ux lub na podstawie własnych pomysłów na temat ux; gdy prototyp działa, projektant sprawdza go i podaje listę zmian. Historia nie wymaga szczegółowego planowania; wszystko czego potrzebuje to oszacowanie wielkości (i niektórzy nawet kwestionują to).
Jules
13

Główne wady to:

  1. Jesteś podszewką: jeśli twoi projektanci się spóźniają, twoi programiści pozostają bez pracy; jeśli twoi programiści się spóźnią, projektant w końcu będzie pracował z więcej niż jedną iteracją wcześniej. To nie jest stabilna sytuacja - nie jest zrównoważona .

  2. Twoi projektanci pracują z góry, płacisz za historie, które mogą, ale nie muszą być opracowane. Nawet jeśli zdarza się to rzadko, nadal wyrzucasz pieniądze.

  3. Twoi projektanci UX podejmują decyzje z wyprzedzeniem bez angażowania programistów. Brakuje przydatnych informacji i zwiększa ryzyko, że projekty są całkowicie błędne lub nierealne. Jest to dość powszechne, ponieważ projektowanie UX nie jest ćwiczeniem „abstrakcyjnym” - musi być wykonane na podstawie cech aplikacji (w tym tego, co jest wykonalne / wskazane do zrobienia lub nie technicznie)

  4. Wykluczenie lub osłabienie programistów nie jest zrównoważonym sposobem prowadzenia projektu.

  5. Projektanci nie dostarczają wartości: oznacza to, że trudno, jeśli nie niemożliwe, prawidłowe ustalenie priorytetów ich pracy. Zazwyczaj prace programistów są traktowane priorytetowo przy użyciu różnych problemów, wartości, wykonalności w następnym sprincie, nakładu pracy. Wiele historii czasowych jest negocjowanych i zmienianych, aby dopasować je lub z powodu użytecznej dyskusji: jeśli którykolwiek z tych zmian zmienia interfejs użytkownika (i można założyć, że tak jest, jeśli nie jest to tylko szczegół implementacji), co robisz z historią? Nie możesz już w to grać.

  6. Zakładasz, że historia, która może zmieścić się w jednej iteracji dla projektantów, pasuje do jednej iteracji dla programistów: jak możesz podzielić historie, aby to założenie było prawidłowe?

Sklivvz
źródło
Komentarze były w dużej mierze nie na temat, więc zostały usunięte.
ChrisF
1
Mówisz „Twoi projektanci UX podejmują decyzje ... bez angażowania programistów”. Skąd wiesz? To, że pracują jeden sprint do przodu, nie oznacza, że ​​nie współpracują z programistami. Być może programiści są ich interesariuszami. To samo dotyczy punktu 4 - zakładasz, że programiści są wykluczeni, ale niekoniecznie tak jest. Jeśli chodzi o „Projektanci nie dostarczają wartości”, nie mogłem się nie zgodzić. Nie widzisz żadnej wartości w odpowiednio zaprojektowanym UX? Chociaż myślę, że poruszasz pewne kwestie warte dyskusji, robisz wiele założeń, które mogą nie być prawdziwe.
Bryan Oakley
@bry albo działają na UX, albo nie. Z pewnością udział w procesie ux kwalifikuje się jako „praca” nad historią. Jeśli chodzi o twoją ocenę wartości ... Nie dodają wartości, jeśli pracują z góry, ponieważ nie produkują niczego, co można by wdrożyć. Jeśli coś nigdy nie dociera do klienta, nie ma dla niego żadnej wartości.
Sklivvz
re: „udział w procesie ux kwalifikuje się jako„ praca nad historią ”. Niekoniecznie. Ludzie cały czas przychodzą i zadają mi pytania, co nie znaczy, że pracuję nad ich historiami.
Bryan Oakley
2
@BryanOakley z pewnością, ale problemy nadal występują: porównaj „odesłanie” projektu, ponieważ jego wykonanie jest nierealne, a poprawne wykonanie go za pierwszym razem, ponieważ jest on wykonywany, gdy programista pracuje nad nim. Co więcej, istnieją problemy, które są wykrywane tylko podczas implementacji, a na tym etapie projektant robi następną historię ...
Sklivvz
6

Podoba mi się z dwóch powodów:

  1. wydaje się, że działa dla ciebie; ciężko kłócić się o sukces!
  2. zespół UX bierze historię i wcześnie rozpoczyna rozmowę - a rozmowy są rodzajem opowieści
Steven A. Lowe
źródło
4

Podstawowym wymaganiem Scrum jest to, aby zespół scrum posiadał wszystkie umiejętności potrzebne do stworzenia potencjalnie wydawanego produktu. W opisywanej sytuacji tak się nie dzieje.

Zespół UX nie produkuje potencjalnie wydawanego produktu, a zespół scrum nie jest w stanie wytworzyć pionowych segmentów funkcjonalności, ponieważ nie ma wszystkich wymaganych umiejętności. To są dysfunkcje.

Sklivvz napisał doskonały post na temat problemów, do których mogą prowadzić powyższe dysfunkcje. Podsumowując, nie sądzę, że ćwiczysz Scrum.

Ale nie ma w tym absolutnie nic złego. Jeśli odkryłeś sposób pracy, który zapewnia wartość dla was wszystkich i wszyscy jesteście z tego zadowoleni, róbcie to dalej. Moją jedyną radą byłoby częste sprawdzanie i dostosowywanie się.

Należy jednak pamiętać, że jeśli Twoim celem jest dostarczanie oprogramowania za pomocą Scrum, musisz zająć się zidentyfikowanymi dysfunkcjami.

Derek Davidson PST CST
źródło
Jak powiedziałem w moim oryginalnym poście: „Projektanci UX i deweloperzy / testerzy są w jednym zespole”
Eugene
2
@Eugene W jakim sensie należą do tego samego zespołu? Powiedziałbym, że jeśli pracują jeden sprint naprzód, nie należą do tego samego zespołu. Nawiasem mówiąc, Scrum jest również jasny, że nie rozpoznaje „podgrup”, więc ponownie powiem, że twoja sytuacja nie wygląda jak Scrum. Na pewno nie tak, jak ja to wiem.
Derek Davidson PST CST
Resztę wykonują o jeden sprint do przodu. Reszta zespołu zazwyczaj przynajmniej dokonuje przeglądu swojej pracy, a czasem pomaga w samym projekcie.
Eugene
4

Istnieją tutaj dwa problemy, jeden dotyczący projektowania zorientowanego na użytkownika, a drugi dotyczący wyrównania sprintu.

Po pierwsze : Historie użytkowników powinny być dostosowane do potrzeb użytkowników, a nie tylko zaległości. Historie UX muszą mieć wyraźną wartość dla użytkowników. Nie wymaga to pełnej specyfikacji i krótkiej instrukcji, takiej jak,

„Użytkownicy będą mieli łatwiejszy dostęp do aktywności na koncie na jednej stronie niż podzieleni na wiele stron”

jest podatny i dostosowujący się do różnych wdrożeń, a jednocześnie nadal jasno określa wartość dla użytkownika (łatwiejszy dostęp do aktywności na koncie).

Po drugie : wyrównanie sprintu. UX projektuje funkcje w sprincie X, które programiści wdrażają wiosną X + 1. W praktyce dzieje się tak w wielu sklepach i czasem może być bardziej jak implementacja w sprincie X + 2 lub X + 3. Dzięki ciasnej nitce i doświadczonemu zespołowi ta konfiguracja może działać. Wyzwanie staje się wyzwaniem, jeśli masz nowy zespół lub nowych członków, którzy nie są zaznajomieni z zestawami umiejętności, preferencjami, nawykami, stylami pracy i tendencjami innych członków zespołu. Jeśli pracujesz razem krócej niż 6 miesięcy, może to stanowić problem.

Cofnij się o krok i ponownie oceń. Pozytywne jest to, że projektanci i programiści UX pracują obok siebie, co jest dobrodziejstwem. Zacznij od upewnienia się, że Twoje historie mają wyraźną wartość dla użytkowników.

atimba
źródło
2

Jednym z możliwych problemów, jakie widzę, jest to, że w Scrumie zakres sprintu N + 1 jest zwykle określany tuż przed jego rozpoczęciem. Jak więc zrobić UX dla historii sprintu N + 1 w sprincie N, zanim będziesz wiedział, które historie będą w zasięgu. Jeśli zdecydujesz się naprawić zakres sprintu N + 1 na początku sprintu N, tracisz pewną elastyczność.

Frank Bakker
źródło
1

Jednak w Scrumie powinieneś mieć tylko historie użytkowników, które zapewniają wartość dla użytkownika. W naszym przypadku historie projektowania UX nie zapewniają takiej wartości (bardziej przypominają czynności związane z pielęgnowaniem zaległości).

Z mojego punktu widzenia zapewniają dużą wartość dla swojego użytkownika. Chodzi o to, że ich użytkownik nie jest końcowym użytkownikiem firmy, ich użytkownik to zespół programistów, który wdroży tę funkcję w sprincie X + 1.

mverardo
źródło
1

Utkniesz w religii tego procesu i po drodze widzę, że scrum / agile jest niewłaściwie wykorzystywany, a użytkownicy błędnie oznakowani. Scrum nie jest uniwersalnym narzędziem, jest środkiem do celu.

Myślę, że twoja grupa błędnie oznaczyła, kim są Twoi użytkownicy i planują dla niewłaściwych odbiorców.

Grupa UX wykorzystuje scrum w klasyczny sposób, wartość użytkownika i sprawne dostosowanie do danych wejściowych od niektórych magicznych użytkowników końcowych. To oni mają użytkowników. Twoja grupa niewłaściwie wykorzystuje scrum, ponieważ po prostu wypełniasz mechanikę, aby istniejący projekt działał, nie wymaga nic zwinnego, a scrum pełni rolę śledzenia zarządzania.

Dlatego wydaje ci się, że jest to dla ciebie złe, tak naprawdę nie potrzebujesz ani nie zyskujesz na scrumie w żaden sposób, ponieważ jesteś w grupie serwisowej, a twoja praca płynie do przodu od ludzi z UX, którzy już wykonali części zwinne / scrumowe.

Nie ma w tym nic złego, po prostu obowiązuje inny proces niż ci powiedziano.

Patrick Hughes
źródło