15 listopada 2021 | Olka Fiszbak-Biernat
#3 Design jako jedyne źródło prawdy – Design w Scrumie: 7 grzechów głównych
Design w Scrumie
1. Wstęp
W wielu Zespołach zwinnych nadal obowiązuje model pracy, gdzie stworzenie makiet hi-fidelity jest koniecznym krokiem przed rozpoczęciem implementacji nowych rozwiązań.
Czy jest to model zgodny z duchem Agile? Czy makieta musi powstać, aby programiści mogli rozpocząć swoją pracę? Tradycyjna odpowiedź brzmi: to zależy! Od czego? Odpowiedź na te pytanie znajdziesz poniżej.
2. Co daje tworzenie szczegółowych makiet hi-fidelity?
Korzenie myślenia o makiecie, jako podstawie do prac programistycznych sięgają podejścia kaskadowego. Ukoronowaniem fazy designu jest w nim zaakceptowany przez przedstawicieli biznesu, szczegółowy projekt interfejsu obrazujący ostateczne UI produktu.
Tworzenie szczegółowych makiet może mieć duży sens, także w pracy zespołów zwinnych. Dzięki projektom hi-fidelity:
- mamy pewność, że zarówno zespół jak i interesariusze rozumieją planowane rozwiązania dokładnie w ten sam sposób
- możemy bardziej precyzyjnie wyestymować czasochłonności prac programistycznych
- makiety możemy poddać weryfikacji ze strony zewnętrznych zespołów (np. prawników)
- a także wykorzystać je, aby przetestować słuszność rozwiązań jeszcze przed ich implementacją
Problem polega na tym, że pracując w z wykorzystaniem frameworków zwinnych zbyt często powielamy znany z kaskady schemat wymagania – design – akceptacja – implementacja, gdzie nadal projekt UI traktowany jest jako etap obowiązkowy, źródło prawdy, bez którego niemożliwe jest rozpoczęcie prac nad kodem.
3. Makieta jako jedyne źródło prawdy: minusy
Traktowanie makiety jako jedynego źródła prawdy, bez którego nie jest możliwa implementacja rozwiązań ogranicza elastyczność zespołów deweloperskich. Może też prowadzić do niepożądanych, z perspektywy zwinnej, sytuacji.
Projekt UI traktowany przez wiele zespołów jako etap obowiązkowy, bez którego niemożliwe jest rozpoczęcie prac nad kodem.
Wprowadzanie zmian, będące podstawą podejścia zwinnego, jest trudniejsze i czasochłonne.
Jeśli makiety traktujemy jak Świętą Księgę, a każda najmniejsza zmiana koncepcji musi być wprowadzona w projekty (a często też zaakceptowana przez przedstawicieli biznesu), to możemy być pewni, że start implementacji zostanie opóźniony.
Stres związany z niedomykaniem zadań na czas może pociągnąć za sobą niechęć Zespołu do sugerowania nowych, lepszych rozwiązań. W efekcie jedna z głównych wartości, którą znamy z Manifestu Agile, czyli reagowanie na zmiany ponad realizację założonego planu zostaje zachwiana.
Pomysły na rozwiązania generowane są jedynie przez Designerów, bez cennej perspektywy technicznej
Korzystanie z makiet i prototypów jako głównego fundamentu dla pracy deweloperów może wpłynąć na „rozleniwienie” Zespołu. Skoro i tak jako deweloperzy nie możemy zrobić nic bez przypieczętowania pomysłów makietą to może niech każdy zajmie się tym co potrafi najlepiej: designerzy generowaniem pomysłów i projektowaniem interfejsów, a programiści kodowaniem.
Z takiego podziału krótka już droga do znanej z kaskady pracy w silosach i tworzenia rozwiązań jedynie przez projektantów. Takie podejście zawęża w znaczący sposób możliwości rozwoju produktu, a rolę dewelopera sprowadza do „klepacza kodu”.
Istnieje ryzyko, że pracując w oparciu o Scruma tak naprawdę nadal uprawiamy nieefektywną kaskadę
Jeśli pracujemy w Zespole gdzie implementację rozwiązań zawsze musi poprzedzić stworzenie projektu hi-fidelity, po którym następuje oficjalny hand-off gotowych rozwiązań do programistów, to możliwe, że wcale nie pracujemy w zwinnym Scrumie, a wpadliśmy pułapkę fazy designu i tzw. Water-Scrum-Falla.
Wariacji na temat takiego modelu jest kilka:
- zakłada znaną z kaskady kilkutygodniową (lub nawet kilkumiesięczną!) pracę zespołu designerów nad UX i UI produktu. Makiety i prototypy są iterowane, a po uzyskaniu akceptu ze strony biznesu trafiają do zespołu deweloperów gdzie zaczyna się praca w Scrumie
- w innym, pozornie zwinnym modelu projektanci pracują w osobnych sprintach projektowych, które toczą się 2-3 tygodnie przed właściwym, wdrożeniowym sprintem scrumowym. Sprint projektowy, koronowany jest akceptacją ze strony klienta. Dopiero po niej następuje przekazanie prototypów i szczegółowej dokumentacji do zespołu developerów, omówienie zaprojektowanych rozwiązań i praca nad ich implementacją w ramach sprintu właściwego.
Modeli jest więcej, ale wszystkie brzmią jak kaskada i prowadzą do znanych z kaskady problemów takich jak wolniejsze tempo prac czy wspomniana już mniejsza elastyczność Zespołu i utrudnione wprowadzanie zmian w trakcie implementacji.
4.Kiedy warto stosować makiety hi-fidelity?
Jak mam nadzieję zauważyliście, nie chcę demonizować tworzenia szczegółowych projektów UI w podejściu zwinnym. Makiety hi-fidelity są tu nadal bardzo przydatnym narzędziem, ale powinniśmy korzystać z nich w umiejętny sposób.
W jakich sytuacjach stosować makiety hi-fidelity?
- Korzystaj z makiet hi-fi dla potwierdzenia, że cały zespół rozumie planowane rozwiązania w ten sam sposób. W tym przypadku pracę nad makietami powinna poprzedzać dyskusja, w której będzie uczestniczył cały Zespół. Dzięki temu finalne rozwiązania będą czerpać z doświadczenia i wiedzy wszystkich jego członków.
- Makiety hi-fidelity wykorzystuj jako punkt wyjścia do dyskusji. Bywają sytuacje, w których rozwiązania nad którymi pracujemy są zupełnie nowe, albo są tak skomplikowane i dotykają tak abstrakcyjnych problemów, że bez graficznego projektu interfejsu trudno jest w ogóle rozpocząć dyskusję z Zespołem czy biznesem. Wystarczającym punktem startowym mogą być szkicowe wireframy, ale czasem potrzebujemy czegoś bardziej namacalnego – wtedy makieta hi-fi (którą poddamy później iteracjom) jest dobrym rozwiązaniem.
- Makiety hi-fi są świetne w testowaniu założeń. Mogą być wykorzystane w testach użyteczności, a także w eksperymentach na etapie Product Discovery. Wykorzystanie makiet hi-fi będzie tańsze niż zaimplementowanie modułu i poddanie go testom, ale ze względu na ograniczoną interaktywność może też dać mniej wiarygodne rezultaty.
- Korzystaj z makiet hi-fi jeśli potrzebujesz weryfikacji rozwiązań od strony prawnej. W niektórych branżach na ostateczny kształt produktu duży wpływ mają przepisy prawne. W takim wypadku wykorzystanie makiet, które zweryfikuje np. zespół prawników będzie bezpieczniejsze niż sprawdzanie czy rozwiązania są zgodne z przepisami już „na produkcji”.
5.W jaki sposób zastąpić tworzenie makiet hi-fidelity?
Pamiętajmy o tym, że powyższe przypadki zwykle nie obejmują pracy nad wszystkimi modułami naszego produktu. Nie zawsze więc projekt hi-fi musi powstać. Jak możemy go zastąpić?
- Zaaranżujmy dyskusję na temat rozwiązań, w której weźmie udział cały Zespół (np. w ramach refinementu). Spróbujmy opisać planowane wdrożenia czy zmiany słowami, skorzystajmy ze szkiców lo-fi, które będą rysować nie tylko designerzy, ale też inni członkowie Zespołu. Ten sposób sprawdza się szczególnie przy produktach, które mają za sobą już kilka pierwszych sprintów i już wiemy „czym to się to je”.
- Skorzystajmy z makiet lo-fidelity. Czasem mogą być one bardzo schematycznym szkicem powstałym np. podczas wspomnianego wyżej spotkania, czasem są owocem pracy projektanta. W obu przypadkach stworzenie projektu lo-fi jest zdecydowanie szybsze niż praca nad makietą hi-fi. Jednocześnie wireframy pozwalają w większym niż dyskusja stopniu zweryfikować czy cały zespół oraz ewentualni interesariusze dobrze się rozumieją.
- Przeprowadźmy UX Review zaimplementowanych rozwiązań. Jeśli po wspomnianej w pierwszym punkcie dyskusji od razu następuje implementacja, warto, aby po wdrożeniu rozwiązań Designer sprawdził czy odzwierciedlają one założenia z dyskusji i są spójne z obowiązującym UX produktu. Wynikiem UX Review mogą być sugestie ewentualnych ulepszeń.
6.Takeaways
Co warto zapamiętać?
- Projekt hi-fidelity nie jest konieczny do rozpoczęcia pracy nad implementacją planowanych rozwiązań
- Istnieją sytuacje, kiedy makieta hi-fi jest przydatnym narzędziem, jednak zwykle nie obejmują one całego zakresu prac nad produktem
- Wykorzystywanie makiet hi-fi jako jedynego źródła prawdy może wpędzić nasz Zespół w modele pracy niebezpiecznie zbliżone do podejścia kaskadowego
- Wykorzystywanie makiet hi-fi jako jedynego źródła prawdy może ograniczyć wpływ programistów na kształt produktu i w znaczący sposób zawęzić możliwości jego rozwoju
- Makietę hi-fi często może zastąpić dyskusja, naszkicowanie rozwiązań w postaci makiet lo-fi, a także UX Review