Ogólnie rzecz biorąc, czy lepiej jest wykonać wszystkie części funkcjonalne, czy najpierw uruchomić interfejs użytkownika - czy też połączenie obu?

47

Ogólnie rzecz biorąc, czy lepiej jest wykonać wszystkie części funkcjonalne, czy najpierw uruchomić interfejs użytkownika - czy też połączenie obu?

Zakładając, że pracujesz nad czymś dużym, czy ogólnie przyjętą praktyką jest sprawienie, aby wszystkie funkcjonalne obiekty BLOB do gromadzenia danych działały przed dowolnym interfejsem użytkownika, aby wszystkie interfejsy działały pojedynczo podczas pracy, czy coś w środku?

Wszyscy wiemy, jak podzielić pracę na części możliwe do zarządzania, ale ostatecznie pytanie brzmi, czy interfejs użytkownika jest zawarty w elementach zarządzalnych, jak sądzę.

W tym przykładzie rozważ aplikację GUI z jednym oknem głównym, ale kilkoma kartami w różnych dokach, aby oddzielić różne składniki danych. Każda pojedyncza zakładka ma za sobą stosunkowo złożony zestaw ruchomych części z perspektywy jednostek funkcjonalnych.

Przykładowa aplikacja w tym konkretnym pytaniu znajduje się tutaj wraz z towarzyszącym blogiem i oryginalnym produktem komercyjnym .

RobotHumans
źródło

Odpowiedzi:

85

Wśród wielu użytkowników biznesowych i klientów istnieje ogólna koncepcja, że ​​kiedy wygląda na kompletną, jest prawie kompletna. Jak zapewne wiesz, jest to dalekie od prawdy. Można go ładnie wyglądać, ale bez zaplecza, a niektórzy użytkownicy uważają, że poprawienie wyglądu to 80% pracy, a nie 20% ( lub inne 80% ).

Niezliczeni programiści mogą opowiedzieć o tym horrory - wykonanie makiety stron wykonanych w programie Microsoft Word przy użyciu zrzutów ekranu z innego narzędzia, a klient mówi „tak, prawie już to zrobiłeś?”

Musisz go przyspieszyć, aby wszystkie części zostały wykonane po zakończeniu. Próba wykonania najpierw całego backendu, a następnie całego frontonu spowoduje, że użytkownik końcowy pomyśli, że nic nie robisz, i zapyta, dlaczego otrzymujesz zapłatę, gdy nie ma nic do pokazania. Z drugiej strony, front-end pierwszy, a zobaczysz, że użytkownik końcowy wprowadza drobne zmiany i pochłania cały nasz czas.

Najgorszy przypadek z „pierwszym i drugim” jest, gdy przejdziesz do drugiej części, okaże się, że w ogóle nie pasuje do projektu.

Zatem zbuduj oba. Pokaż postępy w interfejsie, spraw, aby zaplecze działało z tym, co budujesz. W wielu przypadkach dobrym pomysłem jest dostarczanie przyrostowych kompilacji i upewnianie się, że robisz to, czego chce klient (staje się to zwinne). Zbyt długi czas bez „widocznych postępów” może zaszkodzić relacjom z klientem (dotyczy to zarówno przypadków „wszystko wygląda na zrobione wcześnie”, jak i „nic się nie robi do samego końca” - klientowi trudno jest napisać framework lub testy jednostkowe lub czyszczenie danych jako postęp).

Joel napisał o tym w The Iceberg Secret, Revealed :

Ważny wniosek drugi. Jeśli pokażesz programatorowi ekran z interfejsem użytkownika, który jest w 100% piękny, pomyślą, że program jest prawie gotowy.

Ludzie, którzy nie są programistami, patrzą tylko na ekran i widzą niektóre piksele. A jeśli piksele wyglądają tak, jakby tworzyły program, który coś robi, myślą „o rany, o ile trudniej byłoby sprawić, żeby faktycznie działało?”

Duże ryzyko polega na tym, że jeśli najpierw wyśmiejesz interfejs użytkownika, prawdopodobnie po to, aby porozmawiać z klientem, wszyscy będą myśleć, że prawie skończyłeś. A potem, kiedy spędzisz kolejny rok pracując „pod przykryciem”, że tak powiem, nikt tak naprawdę nie zobaczy tego, co robisz, i będą myśleć, że to nic.

Jest to powtórzone w poście na blogu. Nie zmieniaj wersji demonstracyjnej w Gotową, która ma ten pomocny wykres:

Jak to zrobiono z tym, jak to wygląda

Zauważ tutaj, że dwie opcje ogólnie odzwierciedlają „załatwienie interfejsu użytkownika” (a następnie oczekuje się, że wkrótce skończysz) i „załatwienie zaplecza” (a wtedy klient martwi się, że nie dotrzymasz terminu).

Jak „zrobione” coś wygląda, powinno pasować do tego, jak „zrobione” jest coś.

Każdy programista doświadczył tego wiele razy w swojej karierze. Ale narzędzia do publikowania na komputerze powodują ten sam ból głowy dla pisarzy technicznych - jeśli pokażesz komuś szorstki szkic, który jest idealnie sformatowany i sformatowany, widzą, że jest to więcej zrobione niż chcesz. Potrzebujemy dopasowania między tym, gdzie jesteśmy, a tym, gdzie inni nas postrzegają.

W tym artykule poruszono także ważną kwestię na temat rodzaju informacji zwrotnych otrzymywanych przy różnych poziomach zaawansowania interfejsu użytkownika. Jeśli masz coś, co wygląda na ukończone, bardziej prawdopodobne jest uzyskanie opinii na temat „czy możesz zmienić czcionkę” niż „ten układ nie działa - istnieje zbyt wiele zakładek”.


Dla tych, którzy walczą z tym w świecie Java Swing, istnieje wygląd i styl nazywany Napkin, który sprawia, że ​​interfejs użytkownika nie wygląda na kompletny (nawet jeśli tak jest).

Kluczem tutaj jest sprawienie, aby nie wyglądało na zrobione. Ukończenie interfejsu użytkownika jest sygnałem dla wielu użytkowników biznesowych, że aplikacja jest kompletna (nawet jeśli jest to tylko kilka statycznych stron bez logiki lub coś wbudowanego w narzędzie do tworzenia interfejsów).


Dalsza lektura (i linki z artykułu):


źródło
7
Wygląda na to, że proponujesz jakąś zwinną metodologię ... :)
Alexander
7
@Alexander Agile pomaga w tym przypadku, ale nie jest niezbędny. Wodospad może mieć kamienie milowe (możliwe do dostarczenia), a klienci mogą być bardzo rozczarowani widokiem „wygląda na zrobione, dlaczego są jeszcze 3 kamienie milowe, które trwają tak długo?” FWIW, miałem przypadki, w których użytkownik biznesowy myślał, że to zrobiono z powodu zrzutu ekranu + farby ms w projekcie technicznym (sklep z wodospadem) wyglądał dobrze.
3
W przypadku, gdy nie widzi odpowiedź eksperta do tego filmu, to jest tutaj: youtu.be/B7MIJP90biM
ragol
3
Projektuję interfejsy użytkownika przez większą część mojej kariery programistycznej i NIGDY nie miałem klienta zakładającego, że prototypowy interfejs użytkownika oznaczał, że oprogramowanie zostało „prawie gotowe”. Wydaje mi się, że prezenterzy interfejsów szkieletowych nie wykonują dobrej roboty, wyjaśniając schematy z góry, jeśli klienci są w jakiś sposób zdezorientowani, że projekt jest prawie gotowy.
Graham
2
+1 za serwetki L&F. To na pewno będzie w mojej przyszłości. :)
Kathy
27

To zależy: potrzebujesz ciasnej pętli sprzężenia zwrotnego wokół najważniejszej funkcji

Jeśli rdzeniem tego, co robisz, ryzykowną i przerażającą częścią, jest jakiś silnik wewnętrzny, uruchom rdzeń, powiedzmy konsolę lub testując jednostkę. Na przykład parser protokołu nie potrzebuje interfejsu użytkownika, aby wiedzieć, czy działa poprawnie.

Jeśli twoja fajna rzecz wymaga jakiejkolwiek interaktywności - interaktywności musisz stale rozwiązywać problemy, wyrzucać i odkrywać na nowo - to podejście z interfejsem użytkownika jest kluczowe. Na przykład chcę zbudować aplikację, aby umożliwić użytkownikom interakcję z wizualizacją danych. Najważniejszą rzeczą, którą muszę zrozumieć, jest to, czy wizualizacja jest znacząca, więc prawdopodobnie wyrzucę pół tuzina podejść, zanim zdecyduję się na jedno. Zrobię to wszystko przed napisaniem pojedynczego testu jednostkowego.

Pomiędzy nimi jest niewyraźna szara strefa, w której można wybrać najlepszą kombinację najlepszego sposobu interakcji i weryfikacji kodu (testy automatyczne? Interfejs użytkownika do eksperymentów?). Osobiście popełniłem obie skrajności i wszystko pomiędzy nimi, a wybór właściwego miejsca dla tego spektrum jest jedną z najtrudniejszych rzeczy, o których muszę zdecydować i jest w 100% zależny od rodzaju rzeczy, które buduję.

Doug T.
źródło
2
Oznacza to, że z góry identyfikujemy i zajmujemy się najbardziej ryzykownymi i najważniejszymi komponentami, aby zmniejszyć ryzyko przekroczeń i / lub awarii. Niezależnie od tego, czy są to elementy interfejsu użytkownika, logika biznesowa itp., Lub najprawdopodobniej niektóre kombinacje różnych składników.
Alexander
1
To naprawdę brzmi, jakbyś mówił mi o prototypowaniu, ponieważ jeśli nadal wyrzucasz projekty, to właśnie powinieneś iterować - nie rzeczywisty kod.
Aaronaught
8

W środowisku zwinnym możesz słyszeć dyskusje o „chodzących szkieletach” lub „cienkich pionowych plasterkach”. Chodzi o to, że ponieważ ważne jest, aby działające oprogramowanie było ważne dla użytkownika, tworzysz oprogramowanie w działający sposób, kawałek po kawałku.

W przykładowej aplikacji, o której wspomniałeś, zaczynasz od okna i być może jednej karty i sprawiasz, że wszystko działa w jakiś sposób od przodu do tyłu. Z biegiem czasu dodawalibyśmy funkcjonalność, a zatem zakładki dla poszczególnych przypadków, dzięki czemu każda funkcja działała podczas jej tworzenia. Jest to część tego, co dają częste pokazy klientów: możliwość pokazania czegoś nowego i natychmiastowe otrzymanie informacji zwrotnej na ten temat.

Krótko mówiąc, tak, praca interfejsu użytkownika jest absolutnie nieodłączną częścią jednostki pracy funkcjonalnej, jeśli masz interfejs użytkownika.

Zacznij od czegoś, co działa, i powtarzaj jego funkcjonalność, aby dostarczyć pełne oprogramowanie.

Keith B.
źródło
+1 Zawsze niezbędny jest przedmiot do wysyłki.
JensG
@Jens: „Zawsze niezbędny jest element, który można wysłać”, to kanarek. W najlepszym razie powiedzenie to dotyczy tylko niewielkiej liczby aplikacji. W prawdziwym świecie aplikacje, które wykonują tylko część wymaganej pracy, nie są w najmniejszym stopniu przydatne.
Dunk
To twoje doświadczenia. Mam inne. Duże, rzeczywiste projekty z dużą ilością kamieni milowych i prawdziwymi klientami.
JensG
1
@Dunk: Aplikacja, która nie wykonuje żadnej części zadania, jest mniej użyteczna niż aplikacja, która wykonuje część zadania. Nie mówię jednak o aplikacji „gotowej”; Mówię o kolejności, w jakiej należy zbudować aplikację. Moje doświadczenie jest zgodne z JensG: zawsze jestem w stanie wyciąć wersję beta na podstawie tego, co pokazałeś w tym tygodniu i wysłać ją do klientów, co sprawia, że ​​klienci są znacznie szczęśliwsi.
Keith B,
To jedyna odpowiedź, z którą mogę się identyfikować. Inni nawet nie wydają się rozważać możliwości, że dobry rozwój produktu nie rozpadnie się na „interfejs użytkownika” i „zaplecze”. Jest to pytanie, które zadałby tylko początkujący programista lub kierownik projektu, a nie takie, na które doświadczony programista lub kierownik działu zarządzania powinien rychło udzielić odpowiedzi. Sam pomysł pytania, które należy „zrobić najpierw”, śmierdzi wodospadem.
Aaronaught
3

Polecam połączenie zarówno funkcjonalności, jak i interfejsu użytkownika (i jak najszybszego uzyskania opinii lub doświadczenia w testowaniu).

BTW, czy nie jest to sposób, w jaki opracowuje się większość dużych programów GUI? Spójrz na przykład na przeglądarkę Firefox : z jednej wersji do następnej ewoluowały zarówno funkcjonalność, jak i interfejs użytkownika.

Basile Starynkevitch
źródło
2

W dużych (internetowych PHP) aplikacjach, nad którymi pracuję, staram się najpierw wprowadzić klasy i metody, które zwracają wartości pozorowane . Ma to na celu ustanowienie pseudo-kontraktu, którego inni deweloperzy mogą użyć do implementacji interfejsu użytkownika.

Drugą zaletą tej metody jest to, że możemy doskonalić umowę / interfejs, gdy zmieniają się wymagania interfejsu użytkownika (i zawsze się zmieniają), nawet zanim cały kod zostanie napisany i dostarczony.

dotancohen
źródło
To jest coś, co próbuję zrobić. Ponieważ mój konkretny projekt jest wdrażany jako ogromna powłoka interfejsu użytkownika, a każdy moduł gromadzący punkty danych jest wtyczką, każda wtyczka odpowiada za zarządzanie własnymi komponentami interfejsu użytkownika. W ten sposób nie jest wymagana „umowa” dla danej osoby / grupy osób. Zakładamy, że ta sama grupa osób będzie pracować nad danym plug-inem od początku do końca. Jest to część powodu, dla którego projektuję go takim, jakim jestem. Alternatywnie, w przypadku innych projektów jest to doskonała rada. Więc głosujcie ode mnie, ponieważ przydadzą się innym.
RobotHumans
2

To, co zwykle robię, to zacząć od gównianego interfejsu użytkownika : coś, co po prostu zrzuca zmienne dane na ekran. Bez czcionek, bez wyrównania, przez długi czas nic graficznego. Wystarczy „Welcome user x” i przyciski o nazwie „load pic” itp. Co jest w tym dobrego, dowiesz się, czy coś w backendie jest uszkodzone.

W miarę rozwoju może się okazać, że więcej rzeczy będzie musiało trwać lub mniej. Ale na pewnym etapie zdecydujesz, że backend jest prawie gotowy. Teraz masz interfejs użytkownika, który zawiera wszystkie potrzebne załączniki, i możesz spędzić dużo czasu na robieniu wszystkich graficznych rzeczy.

Uważaj jednak, nie jest to niezawodne. Potrzebujesz trochę dalekowzroczności, aby zobaczyć pewne problemy. Na przykład może być konieczne zbadanie składników interfejsu użytkownika, aby wyświetlać dane w rozsądny sposób.

Carlos
źródło
A gdzie klient bierze udział w twojej metodyce? Pamiętaj, że zazwyczaj twój klient ma bardzo ogólne pojęcie o tym, czego chce. Od Ciebie zależy, jak „wyciągnąć z nich” dokładnie to, czego chcą, abyś mógł je zbudować. Twoja metodologia właśnie zbudowała to, co Twoim zdaniem chce klient, ale rzadko będzie to, czego tak naprawdę chce klient. Więc zmarnowałeś mnóstwo czasu na kodowanie czegoś, czego klient nie chce.
Dunk
Ach, moi „klienci” siedzą obok mnie, a ja mam doświadczenie w tej dziedzinie, które daje mi całkiem niezłe wyobrażenie o tym, czego się chce. Zasadniczo jesteśmy zawsze blisko produktu końcowego, jeśli chodzi o interfejs użytkownika, i zawsze mogę uzyskać informację zwrotną. Nie zastanawiałem się nad problemem związanym z długą pętlą sprzężenia zwrotnego. Wydaje mi się, że znajomość domeny jest kluczem.
Carlos
0

Jeśli korzystasz z dobrego kamienia milowego i systemu śledzenia problemów, możesz uniknąć niektórych z tych problemów, ponieważ na pierwszy rzut oka kierownictwo może zobaczyć, jak produktywny jesteś. Zobaczysz, że w 80% ukończyłeś backend i że interfejs użytkownika jest kolejnym kamieniem milowym; będą mogli zobaczyć, że masz zestaw interfejsów użytkownika i zadań zaplecza do ukończenia dla określonego kamienia milowego funkcji. Ale wszystko zaczyna się od wymagań projektu, a odpowiedź Douga T. podnosi kilka dobrych punktów na temat tego aspektu projektowania systemu.

Derek
źródło
0

Pomyśl z punktu widzenia użytkowników / klientów. System oprogramowania to zbiór funkcji, które dają tym użytkownikom / klientom pewną wartość. Oczywiście każda z tych funkcji ma i interfejs użytkownika, backend i kilka innych rzeczy.

Zbuduj swój system zawsze według funkcji i spróbuj podzielić na bardzo małe funkcje. W ten sposób zawsze będziesz mieć coś więcej do zaoferowania swoim klientom, pamiętaj, że w rozwoju oprogramowania nie chodzi o kompilację wersji 1.0, ale o przejście do wersji 1.0.1 do 1.0.2 i tak dalej ...

AlfredoCasado
źródło
0

To zależy. Jak dobrze zdefiniowane są twoje wymagania? Jaka część systemu ma interfejs użytkownika?

Z mojego doświadczenia wynika, że ​​większość klientów nie wie, czego chcą, dopóki nie zobaczą czegoś przed sobą. Więc zwykle dostarczam niektóre szkielety kluczowych aspektów interfejsu użytkownika lub dostarczam większość interfejsu użytkownika (nie działa). Pozwala to klientowi zmienić zdanie na temat funkcji / funkcji bez większego wpływu, ponieważ projekt bazy danych i struktura kodu jest wciąż w fazie projektowania - łatwo jest zmienić projekt. Łatwiej / szybciej jest zmienić projekt wcześniej w projekcie niż później.

Zwinny mówi, że najpierw powinieneś pracować nad najtrudniejszymi przedmiotami i najważniejszymi. Szybko zawieść . Więc kiedy klient zobaczy interfejs użytkownika, skupiam się na budowaniu małych komponentów, które są w pełni funkcjonalne. Najpierw najważniejsze i najtrudniejsze do wdrożenia, abyś jak najszybciej wiedział, czy napotkasz jakieś przeszkody.

Następnie masz sprinty i masz stałą komunikację z klientem, rozwijając jednocześnie interfejs użytkownika i aspekty funkcjonalne.

Daveo
źródło