Nasz zespół scrumowy składa się ze zwykłych ról scrumowych. Nie mamy projektanta interfejsu użytkownika / interfejsu użytkownika, a programiści współpracują z interfejsem użytkownika z właścicielem produktu. Tu leży problem. Za każdym razem, gdy mamy tworzyć zaległości i nie definiujemy dokładnego projektu interfejsu użytkownika / UX przed rozpoczęciem sprintu, kończymy zbyt dużo czasu podczas sprintu, próbując sfinalizować projekt interfejsu użytkownika / UX.

Dotyczy to dokładnie analizy i architektury funkcji. Czy uważasz, że każdy możliwy szczegół dotyczący funkcji powinien zostać przekazany deweloperom przed rozpoczęciem sprintu, czy powinien to być zadanie w ramach funkcji? Doświadczyliśmy tego i powoduje to pewne niezdefiniowane funkcje, które nie mają żadnych kryteriów.

Po pierwsze: spójrz na tę miłą rozmowę , którą Florian Haas wygłosił na FROSCON (GER). Chodzi o praktyczną niemożność robienia scrum w ogóle.

Dobre wieści : Ponieważ scrum jest niemożliwe do wykonania, jesteś wolny, aby robić, co chcesz.

Zła wiadomość : nie mów, że Scrum.

To uwalnia cię od pytania: »Czy robię scrum, prawda?« (Odpowiedź: nie, nie robisz ) i możesz przejść do praktycznych pytań życiowych.

Nie mamy projektanta interfejsu użytkownika / interfejsu użytkownika, a programiści współpracują z interfejsem użytkownika z właścicielem produktu

To nie jest rzadka sytuacja. Ale scrum AFAIR jest przeciwny specjalizacji: każdy powinien mieć ten sam zestaw umiejętności i mógł pracować zamiennie.

Za każdym razem, gdy mamy zamiar utworzyć zaległości i nie określamy dokładnego projektu interfejsu użytkownika / UX przed początkiem wiosny, kończymy zbyt dużo czasu podczas sprintu, próbując sfinalizować projekt interfejsu użytkownika / interfejsu użytkownika.

Tak, teraz ta sytuacja jest zbyt dobra. Pracowałem w zespole, w którym mieliśmy do czynienia z bardzo szerokimi zaległościami, takimi jak »Jako użytkownik chcę zobaczyć informacje x « i to było to. Następnie przedmiot wylądował na tablicy sprintu. Jeden deweloper wziął to. Rozwiązałem to. Po jego wdrożeniu odbyła się pierwsza wzajemna ocena, podczas której rozpoczęła się dyskusja na temat tego, jak powinien wyglądać interfejs użytkownika.

Potem nadeszła faza kontroli jakości i dyskusja rozpoczęła się od nowa.

Po sprincie zrobiliśmy to, co scrum wymaga przeglądu, w którym projekt został rozerwany przez PO . Niestety nasz klient nie dotarł do recenzji, więc w tym momencie nie widział oprogramowania.

Ale potem cykl zaczął się od nowa, dopóki PO nie był zadowolony.

A potem przyszedł klient ...

Z tej historii wojennej widać, że ten (szczególny rodzaj) proces jest piekielnie nieskuteczny.

To, co zadziałało dla nas w końcu, to wyrzucenie scrum za burtę.

Ale to nie jest rozwiązanie twojego pytania;)

Czy uważasz, że każdy możliwy szczegół dotyczący funkcji powinien zostać przekazany deweloperom przed rozpoczęciem sprintu, czy powinien to być zadanie w ramach funkcji?

Rozwiązaniem tego problemu wiązałoby mocno feedbackloops pomiędzy a) samego klienta i PO , tak że kryteria są stosunkowo ciasno sformułowane. b) Ciasna pętla sprzężenia zwrotnego między drużyną scrum i PO, aby zminimalizować szansę zjechania z drogi.

Łamałbym niektóre (więcej) zasad scrum, aby zdefiniować jeden backlogitem: »działający manekin«. Który może być szybko sprawdzony przez PO i klienta, aby zminimalizować czas programowania poświęcony na prosty przedmiot.

tl; dr

Jaki powinien być wkład zespołu scrum?

Wystarczająca ilość informacji, aby spełnić specyfikacje w jak najkrótszym czasie.

Poza tematem:

Nie robimy już scrumów. Nie dokonujemy szacunków. Trzymaliśmy tablicę sprintu. Nie bierzemy sprintu. Rozwijamy funkcje / naprawiamy błędy i wypuszczamy jak najszybciej. Kiedy nowe funkcje są wdrażane, idą JAK NAJSZYBCIEJ na publiczny serwer, na którym możemy omówić dalsze projekty z klientami tak ściśle, jak to możliwe.

Kanoniczna odpowiedź brzmi: „rób to, co działa dla ciebie”.

Scrum jest jedną z metodologii zwinnej. Jest wyraźnie zaprojektowany, aby zmieniać i dostosowywać się do twojego zespołu i twojego projektu. Twoim celem powinno być:

Osoby i interakcje między procesami i narzędziami
Oprogramowanie robocze nad obszerną dokumentacją
Współpraca z klientami w trakcie negocjacji umów
Reagowanie na zmianę w wyniku wykonania planu ( manifest Agile )

To nie jest pytanie, co Twój zespół powinien zacząć od opowiadania, To pytanie, jaki wkład pozwala Twojemu zespołowi na zaspokojenie określonej potrzeby biznesowej.

Z mojego osobistego doświadczenia wynika, że ​​zależy to od celu biznesowego. Niektóre historie już zawierają badania UI / UX i pełne projekty, i to jest w porządku. Niektóre historie mają niejasne wymagania, ponieważ firma potrzebuje tylko rozwiązania problemu. To też OK.

Oczywiście są też inne czynniki. Na przykład, czy twoi projektanci są częścią zespołu programistów, marketingu, rozwoju produktu itp. Wiele czynników. Po prostu rób to, co jest potrzebne, aby zadowolić firmę, bądź elastyczny i upewnij się, że omawiasz te rzeczy podczas retrospekcji, w razie potrzeby dostosowując proces.

Mam podobne odpowiedzi od programistów. Problem z ich punktu widzenia polegał na tym, że obawiali się, jak długo może zająć implementacja części UX. Jeśli zgodzą się spróbować dostarczyć N historii w sprincie, ale niektóre z nich trwają znacznie dłużej, niż się spodziewano ze względu na przechodzenie tam i z powrotem na UX, to czuli, że odbiło się to na nich źle.

Pracowało dla nas:

1. Ktoś współpracuje z właścicielem produktu, aby tworzyć makiety ekranów, które mają zostać opracowane. Zostają one przejrzane podczas zwykłego procesu udoskonalania historii, zanim historia zostanie wciągnięta w sprint, który daje wszystkim szansę na uczciwą dyskusję.
2. Nie próbuj finalizować projektu przed kodowaniem, po prostu weź go tam, a następnie porozmawiaj o tym, co wymaga zmiany. Koszty wprowadzenia zmiany są wówczas jaśniejsze, co pomaga właścicielowi / klientowi produktu zdecydować, czy warto.
3. Zaufanie między właścicielem / klientami produktu a programistami. W końcu wszyscy starają się dostarczyć rzeczy do klienta. PO nie może jęczeć, że drużyna nie dostarczy wszystkiego od sprintu. Twórcy nie mogą celowo przeszkadzać, ponieważ martwią się, że nie dostarczą.
4. Ćwiczyć. Właśnie lepiej oszacowaliśmy rozmiary historii i jesteśmy w stanie wykryć prawdopodobne problemy.

Tl; DR: Nie definiuj w pełni UX przed kodowaniem. Poczekaj, aż użytkownicy go zobaczą i baw się nim.

Czy uważasz, że każdy możliwy szczegół dotyczący funkcji powinien zostać przekazany deweloperom przed rozpoczęciem sprintu, czy powinien to być zadanie w ramach funkcji?

Mówiąc prosto, jeśli właściciel produktu nie jest w stanie dostarczyć projektu interfejsu użytkownika / interfejsu użytkownika przed sprintem, opracowanie interfejsu użytkownika powinno być historią , a nie zadaniem.

Twoje elementy sprintu nie zawsze muszą działać poprawnie, a sam zespół może być „kim” w historii. Możesz mieć historię, taką jak: „Jako członek zespołu programistów potrzebujemy makiet interfejsu użytkownika, aby móc wdrożyć interfejs użytkownika”. Następnie szacujesz, ile czasu zajmie Twój zespół, aby dostarczyć makiety, a to staje się jedną z pierwszych historii, nad którymi pracujesz.

Nie musisz przeliterować interfejsu użytkownika, wystarczy zaakceptować żądanie funkcjonalne (historię) i zdobyć je, wiedząc, że musisz pomyśleć o interfejsie użytkownika. Po wskazaniu przez klienta interfejsu użytkownika pojawia się problem.

Teraz, gdy wiesz, że interfejs użytkownika będzie cię kosztował trochę czasu, powinieneś być w stanie lepiej zaplanować. Następnym razem, gdy podejmiesz się zadania obejmującego pracę z interfejsem użytkownika, przypiszesz mu dodatkowe punkty historii.

Jeśli jesteś scrumem, każdy może być projektantem UI / UX.

Interfejs użytkownika / interfejs użytkownika nie powinien być powtórką. Powinien być dostarczalny. Powinien zostać zatwierdzony przez właściciela produktu. Powinien pojawić się, nawet jeśli tylko jako gif, podczas dostarczania.

To nie znaczy, że nie może się zmienić. To coś często się zmienia. To także coś, o czym chcesz wcześnie wyrazić opinię. Nie pozwól, aby kod sterował projektem interfejsu użytkownika. Pozwól klientowi to prowadzić. Odpychaj tylko wtedy, gdy klient prosi o magię. W przeciwnym razie po prostu poinformuj ich o ilości pracy, o którą proszą i ile to będzie kosztować.

Jedyny sfinalizowany interfejs użytkownika / UX dotyczy martwego oprogramowania.

Z twojego komentarza:

„Powinien zostać zatwierdzony przez właściciela produktu.” Właśnie tam pojawia się problem. Proces zatwierdzania zajmuje dużo czasu i spędzamy dni zamiast kilku godzin, które początkowo szacowano. - Rashid

Wyeliminuj wszystko, co niepotrzebnie cię spowalnia.

Masz pomysł Poinformuj właściciela produktu. Powinny siedzieć obok ciebie.

Nienawidzą tego? Pójść dalej. Kocham to? Zrób to. Nie rozumiesz tego? Pokazac im.

Krótkie częste nieplanowane spotkania. Rozmowa. Doodle na tablicy lub papierze. Makiety w programie do malowania za pomocą zrzutów ekranu. Szybka komunikacja, zatwierdzanie, wdrażanie i przegląd pomysłów.

Jeśli właściciela produktu nie ma w pobliżu, złap wygodnego człowieka i zapytaj go. Cokolwiek trzeba, aby rozpocząć iterację. Jak najszybciej zapisz właściciela produktu.

Nie spędzaj ani sekundy na upiększaniu. Przejdź do sedna. Utrzymuj swoje pomysły małe i przyrostowe, a będziesz mógł je wykonać, zanim ktokolwiek poprosi o wycenę.

Z mojego doświadczenia:

• Zbyt mało wstępnych analiz powoduje nieefektywny rozwój od początku do końca
• Zbyt duża analiza z góry powoduje paraliż analizy (Sprint nigdy się nie uruchamia)

Co robimy:

• Zdefiniuj niektóre kryteria „ Gotowy do rozwoju ”
• W przypadku historii UX może to być „mamy szkielet, który jest dobrze zrozumiany przez zespół”

Podczas planowania sprintu:

• Wszelkie historie, które nie są gotowe do rozwoju, są wyrzucane (byłyby zbyt uciążliwe dla zespołu i wróciłyby do dalszej analizy)
• Wszelkie historie graniczne są deklarowane jako „Wysokie ryzyko” i podejmowane na początku sprintu
• Dobrze zrozumiane historie są szacowane i dozwolone w sprincie

Ten system pozwala nam poświęcić większość każdego Sprintu na wykonanie, tzn. Pracujemy znacznie wydajniej.

Każde zadanie w twoim scrumie musi zawierać oszacowanie całkowitej pracy i możliwego do zweryfikowania wyniku.

Jeśli włożę zadanie do scrum „zaimplementuj funkcję X z interfejsem użytkownika, z którego zadowolony jest menedżer produktu”, to da to wynik, który da się zweryfikować, ale oczywiście niemożliwe jest oszacowanie nakładu pracy. Dlatego tego zadania nie można rozsądnie postawić w kłótni.

Teraz umieszczam zadanie w twoim scrumie „zaprojektuj interfejs użytkownika dla funkcji X”. Można to oszacować, a wynik można zweryfikować. To jest ok zadanie w scrum. Kiedy zadanie jest wykonane, wykonałeś je.

Teraz, gdy zadanie zostanie wykonane, kierownik produktu może powiedzieć, że nie podoba mu się wynik. W porządku. W scrumie było zadanie, wykonałeś je i to jest twoja praca. Może umieścić kolejne zadanie w kolejnym scrumie. Może z nieco większym ukierunkowaniem, jakiego rodzaju interfejsu użytkownika chciałby. To jego praca. Ustawianie zadań dających przydatne wyniki. Czasami jest ciężko i wykonuje się pracę, która okazuje się bezużyteczna. Dlatego nazywają to „zwinnym”; wykonywane są zadania, które okazują się bezużyteczne, a następnie zmieniasz kierunek na lepszy.

Ponadto projektowanie UX, szczególnie dobry projekt UX, jest pracą na pełen etat dla kogoś, kto ćwiczył projektowanie UX. Wielu dobrych programistów może wykonać zadowalającą pracę, tworząc UX, ale nie zrobią tego tak dobrze i tak opłacalnie, jak dobry projektant UX (gdyby mogli, stworzyliby projekty UX i nie opracowaliby oprogramowania). Nie posiadanie projektanta UX jest więc nieskuteczne - znowu problem dla właściciela produktu.

Nie jestem pewien, czy przestrzegasz zwinnych zasad, ale oto, jak należy sobie z tym poradzić.

nie definiujemy dokładnego projektu interfejsu użytkownika / interfejsu użytkownika przed rozpoczęciem sprintu

W tym momencie celem nie jest być idealnym. Uzyskaj jak najwięcej danych wejściowych dla wymagań, aby programiści mogli zbudować coś, co odpowiada temu, o co proszono, tak blisko, jak to możliwe. Nie rób kilku poprawek ani nie próbuj projektować rzeczy, o które nie prosiłeś. Będziesz marnować swój czas.

kończymy zbyt dużo czasu podczas sprintu, próbując sfinalizować projekt UI / UX.

Pracuj nad sposobem, aby określić, kiedy rzeczy są zrobione. Mam wrażenie, że ktoś nadal wykonuje wiele ocen interfejsu użytkownika / interfejsu użytkownika. Zbyt wiele osób ma opinie na temat UX / UI, a klient nie ma poparcia dla swoich założeń.

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

Tego rodzaju rzeczy mogą trwać wiecznie. To nie jest wada Scruma. Ktoś wtrąca się w wymagania podczas sprintu. Wróć do decydowania o tym, czego chce klient, określ, ile zajmie, i pracuj z nim, aby ustalić priorytety. Jeśli uważają, że to potrwa zbyt długo, zapytaj ich, czego się pozbyć.

Istnieje firma, która projektuje logo za stałą opłatą. Ograniczają liczbę próśb o zmianę, ponieważ wiedzą, że niektórzy klienci zabiją ich na śmierć z tysiąca cięć wszystkimi ich zmianami. Zatrzymaj go lub naładuj więcej. To się nazywa biznes.