Jak radzić sobie z projektowaniem interfejsu użytkownika i obsługą odpowiednich funkcji w programowaniu Agile?

W procesie programowania zwinnego zwykle główny nacisk kładziony jest na historie użytkowników, ale czasami jedno wymaganie może obejmować kilka historii użytkowników.

Na przykład klient może zażądać strony wyszukiwania dla wszystkich użytkowników na forum, a dla każdego użytkownika może wystąpić kilka działań, takich jak zablokowanie użytkownika, usunięcie użytkownika, zresetowanie hasła itp.

Możemy podzielić tę funkcję na co najmniej 4 historie użytkowników:

1. Wyszukaj użytkowników
2. Zablokuj użytkownika
3. Usuń użytkownika
4. Zresetuj hasło

W jaki sposób projektant interfejsu użytkownika wdrożyłby taki interfejs użytkownika? Czy powinien on / ona pracować nad pierwszą historią użytkownika, a następnie zacząć zwiększać liczbę funkcji interfejsu użytkownika? Myślę jednak, że ostateczny interfejs użytkownika zostanie zawalony!

Jeśli zdecyduje się pracować nad całą funkcją (wyszukiwanie + akcje), co jeśli akcje będą miały niski priorytet i zostaną wdrożone kilka iteracji po wykonaniu funkcji wyszukiwania?

Weź to iteracyjnie. Pracujesz bezpośrednio z użytkownikami, prawda? Więc tak naprawdę nigdy nie powinno być bałaganu.

Najpierw wykonaj stronę wyszukiwania. Ty i użytkownicy powinniście pamiętać, że będą chcieli wykonywać działania na wynikach. Czy użytkownicy to lubią? OK, masz wyszukiwanie.

Teraz dodaj „Zmień hasło” (lub cokolwiek, co będzie miało wyższy priorytet). Ups, musimy nieco zmienić stronę wyszukiwania - cóż, zmiana często jest częścią gry. Czy użytkownikom podobają się wyniki? Dobry.

Teraz dodaj następny element, a następny ...

Podejście zwinne mówi, że zawsze masz informacje zwrotne, więc powinieneś być dobry.

To powiedziawszy, nie ma prawdziwego powodu, dla którego możesz nie być w stanie zaatakować 2 z tych historii w tej samej iteracji (dodanie użytkownika usuń ORAZ użytkownika banowania) Kluczem jest zawsze współpraca z klientem, aby upewnić się, że jest odpowiedni.

Często (zawsze?) Kończy się na tym, że użytkownicy myślą o czymś innym, co chcą zrobić z tego ekranu wyszukiwania, po wykonaniu i zaimplementowaniu oryginalnego „projektu”. Tak czy inaczej, w pewnym momencie skończysz to modyfikować . Po prostu podejdź do całości z tymi oczekiwaniami i powinieneś być dobry.

Czuję, że dużo to mówię. Zwinność nie oznacza, że ​​musisz zakładać żaluzje, aby ignorować przyszłość i projektować się w kącie. Zwinność polega na tym, jak dostarczasz funkcjonalność, i ma niewiele wspólnego z tym, jak projektujesz funkcjonalność.

Innymi słowy, przy tworzeniu projektu możesz patrzeć w przyszłość tak daleko, jak chcesz, o ile nie opóźni to dostarczenia funkcjonalności w krótkim okresie.

W tym konkretnym przykładzie oznacza to, że projektujesz interfejs użytkownika w taki sposób, aby później łatwo było dodawać akcje. Jeśli jednak praca nad poprawnym zaprojektowaniem akcji opóźni dostarczenie podstawowego wyszukiwania użytkownika przez iterację, lepiej najpierw wykonać projekt bez akcji, zakładając, że wyszukiwanie bez żadnych działań ma wartość dla klienta.

Pytanie, które należy sobie zadać, brzmi: „Czy prace projektowe opóźniają moją pierwszą dostawę?” Przez większość czasu odpowiedź będzie przecząca. W każdym razie musisz wykonać projekt, wszystko co zmieniasz, to kryteria projektowe.

Pierwszą historią użytkownika może być konstrukcja całego interfejsu - nie muszą oni projektować tylko jednego elementu. To konstrukcja jako całość dodaje wartości biznesowej.

Biorąc to pod uwagę, widzę tu co najmniej dwie różne funkcje: możliwość wyszukiwania użytkowników i zdolność wykonywania funkcji na jednym lub kilku użytkownikach. Projektant może rozwiązać każdy z nich w sposób wyszukany, jeśli ma to większy sens.

Pamiętaj: celem jest dostarczanie wysokiej jakości oprogramowania, a nie ślepe przestrzeganie jakiejś metodologii. Zadaj sobie pytanie, czy rozbicie projektu na części pomaga, czy utrudnia ten cel. Nie ma policji scrum, tylko zadowoleni lub niezadowoleni klienci.

Miałem okazję odbyć staż w fabryce programowania Agile / Extreme. Używali kart opowieści do napędzania iteracyjnego procesu rozwoju. Każda karta opowieści kierowała implementacją lub zmianą. Kluczem była interakcja użytkownika. Jak z powodzeniem zaprojektować interfejs przeznaczony dla użytkownika bez interakcji z użytkownikiem oprogramowania?

Możliwym scenariuszem jest rozpoczęcie od interakcji użytkownika, aby zdecydować, czego chce najpierw użytkownik. Następnie, iteracyjnie, projektuj interfejs użytkownika na podstawie rosnącej informacji zwrotnej, priorytetu użytkownika i tego, co użytkownik musi mieć.

Historie użytkowników służą do określania sposobu interakcji użytkownika, na jakim poziomie iw jaki sposób. Są to jednak tylko przybliżenia do czasu interakcji z użytkownikiem. Jeśli istnieje wielu użytkowników, którzy wszyscy chcieliby czegoś konkretnego, mała ankieta wśród ludzi może być w celu zdefiniowania pewnego poziomu odniesienia dla interfejsu użytkownika.