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.
Odpowiedzi:
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.
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.
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;)
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
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.
źródło
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ć:
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.
źródło
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:
Tl; DR: Nie definiuj w pełni UX przed kodowaniem. Poczekaj, aż użytkownicy go zobaczą i baw się nim.
źródło
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.
źródło
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.
źródło
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:
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ę.
źródło
Z mojego doświadczenia:
Co robimy:
Podczas planowania sprintu:
Ten system pozwala nam poświęcić większość każdego Sprintu na wykonanie, tzn. Pracujemy znacznie wydajniej.
źródło
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.
źródło
Nie jestem pewien, czy przestrzegasz zwinnych zasad, ale oto, jak należy sobie z tym poradzić.
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.
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ń.
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.
źródło