Projektanci UX pracujący o jeden Sprint do przodu

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.

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.

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?

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

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.

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.

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ść.

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.

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.