Strona główna » User experience

Agile UX od podstaw

26 czerwca 2012 napisała Ewa [ 5 odpowiedzi ] Drukuj wpis

Coraz częściej termin „agile” pojawia się w ogłoszeniach o pracę w polskiej branży UX. Częściowo jest to spowodowane tym, że firmy przestawiają się na zwinną produkcję oprogramowania. W większej mierze jednak, jak wynika z moich obserwacji, jest to efekt dojrzewania firm do UX. Z roku na rok rośnie liczba projektantów interakcji zatrudnianych in-house (pod różnymi nazwami stanowisk). Taka osoba nierzadko trafia do otoczenia, gdzie metodyki agile stosuje się już od pewnego czasu, ale gdzie user experience jest wciąż dojść tajemniczą dziedziną. Jak się odnaleźć w takich warunkach i włączyć projektowanie w rytm zwinnej produkcji?

Co to jest agile software development?

Standardowa procedura tworzenia oprogramowania składa się z kilku etapów: analiza, projektowanie, kodowanie, testowanie. Następują one jeden po drugim i są względnie zamknięte. Taki model bywa potocznie określany mianem waterfalla (od ang. waterfall). Praca UX skupia się na dwóch pierwszych fazach – organizujemy badania, opracowujemy koncepcję projektu, tworzymy architekturę informacji, makiety i prototypy, testujemy je z użytkownikami, poprawiamy. Następnie wraz z dokumentacją wręczamy grafikowi i deweloperom lub klientowi, który sobie to już wdraża na własną rękę. Taki proces może się jeszcze sprawdzać w przypadku krótkich i względnie prostych projektów. Jednak wraz ze wzrostem złożoności, rośnie niebezpieczeństwo rozminięcia się efektu końcowego z założonym. Przede wszystkim ryzykujemy:

  • rozminięcie się z potrzebami użytkowników końcowych (jeśli zbyt rzadko testujemy),
  • rozminięcie się z możliwościami technicznymi wdrożenia (jeśli nie rozmawiamy z deweloperami).

Odpowiedzią na te i pokrewne niebezpieczeństwa mają być zwinne metodyki wytwarzania oprogramowania, zwane po pół-polsku agile’owymi. W uproszczeniu opierają się one na zespołach produkcyjnych, które samodzielnie organizują swoją pracę w modelu iteracyjnym (przyrostowym), tak, by co 2-4 tygodnie dostarczyć gotowe, działające oprogramowanie. Istotę tego podejście odzwierciedla tzw. Agile Manifesto, które deklaruje:

Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkładamy:

  • Ludzi i interakcje ponad procesy i narzędzia.
  • Działające oprogramowanie ponad obszerną dokumentację.
  • Współpracę z klientem ponad formalne ustalenia.
  • Reagowanie na zmiany ponad podążanie za planem.

Doceniamy to, co wymieniono po prawej stronie, jednak bardziej cenimy to, co po lewej.

Waterfall vs. Agile

Waterfall vs. Agile

Warto też wspomnieć, że „agile” nie jest jedną metodyką tworzenia oprogramowania, ale grupą metodyk zwinnych, do których należy między innymi, najlepiej mi znany, Scrum.

Niezależnie od tego, którą metodykę zwinną stosuje firma czy zespół, specjalista UX musi się zmagać z uniwersalnymi wyzwaniami agile UX:

  1. Trudno jest z uzyskać i utrzymać dłuższą wizję projektu w środowisku, gdzie decyzje o tym, jakie funkcjonalności będą tworzone, podejmowane są nieomalże z tygodnia na tydzień.
  2. Fragmentaryczność projektowania utrudnia zachowanie spójności w obrębie całego systemu. Sytuacja komplikuje się jeszcze bardziej, jeśli mamy do czynienia z większą liczbą programów oferowanych przez firmę jako części pewnej linii produktowej.

I wreszcie:

  1. Jak zmieścić całe projektowanie i badania w dwutygodniową iterację?

Przygotowania i iteracja 0

Rozpoczęcie każdego projektu wymaga pewnej porcji przygotowań, także w przypadku agile. Zespół deweloperski potrzebuje czasu by dobrać odpowiednie osoby, zorganizować się, określić posiadane zasoby, przygotować środowisko produkcyjne i testowe, itp. To jest też czas, kiedy UX może (i powinien) przeprowadzić wstępne badania, na podstawie których będzie mógł określić potrzeby użytkowników (np. z wykorzystaniem obserwacji). Czas jaki mamy do dyspozycji na tym etapie zwykle nie przekracza paru tygodni, badania muszą być więc przemyślane i odpowiednio zaplanowane, by uzyskać odpowiedzi na najważniejsze pytania. Powinniśmy dzięki temu zbudować solidne persony, które będą nam towarzyszyć i kierować prace przez cały czas trwania projektu.

Na tym wstępnym etapie budowany jest też tzw. product backlog, czyli rejestr planowanych funkcjonalności. Będzie się rozwijał i zmieniał z czasem. Na dalszych etapach z puli backlogu będą wybierane funkcjonalności do zbudowania w danej iteracji. UX designer już na wstępie powinien pomóc w jego tworzeniu. Wymaga to pewnego projektowania z wyprzedzeniem, ale w ograniczonym zakresie. Projektujemy tylko tyle, ile jest potrzebne by zespół deweloperski wiedział, co będzie do zrobienia, mógł rozplanować i zacząć pracę pełną parą. Szczegóły będą weryfikowane i dopracowywane już w konkretnych iteracjach.

Dokumentacja i standardy

Metodyki zwinne stawiają na bezpośrednią, bieżącą współpracę i komunikację. Agile to ciągła zmienność i krótkie ramy czasowe. Jeśli chcemy w tym środowisku tworzyć projekty o dobrym user experience trzeba iść na kompromis. Jednak kompromisem w żadnym wypadku nie powinna być obniżona jakość UX! Jedyną ofiarą zwinności jest dokumentacja.

Bill Buxton powiedział kiedyś:

„Koncepcja prototypowania low-fidelity i high-fidelity jest głupia. Moim zdaniem jest tylko dobra-fidelity i zła-fidelity”.

Im dłużej pracuję w zwinnym otoczeniu, tym bardziej się z tym stwierdzeniem zgadzam. Szkicowanie, żółte karteczki, rozmowy w zespole i adnotacje na marginesie zupełnie wystarczają w codziennej praktyce. Balsamiq zupełnie zastąpił mi Axure i sprawdza się znakomicie. Jeśli mamy do dyspozycji już opracowane i udokumentowane standardy interakcji i wyglądu aplikacji w firmie (tzw. interaction standards lub visual standards), tym bardziej możemy się ograniczyć do szkiców.

Podobnie w przypadku testów z użytkownikami. Badania powinny być prowadzone profesjonalnie i poprawnie metodologicznie, ale odpuszczamy sobie tworzenie rozległych raportów. Wyniki omawiamy na bieżąco, wynotowując najważniejsze punkty do poprawy, tak, by od razu przełożyć to na konkretne zadania dla zespołu wdrożeniowego.

UX w rozkroku

Jak na co dzień wygląda praca UX w środowisku agile’owym? Jak zmieścić całe projektowanie i testowanie w rytm parutygodniowych iteracji?

Można powiedzieć, że UX designer jest rozciągnięty między 3 iteracje:

  • przygotowuje projekty na nadchodzącą iterację (Iteracja N+1),
  • konsultuje projekty wdrażane w bieżącej iteracji (Iteracja N),
  • testuje z użytkownikami to, co zostało stworzone w poprzedniej iteracji (Iteracja N-1).

W większych firmach mogą być specjalnie powołane zespoły zajmujące się tylko organizacją badań z użytkownikami. Tak czy inaczej, projektant musi mieć do nich dostęp, by wyciągnąć z nich wnioski.

Słyszałam też opowieści o zespołach, które wykonują cały ten proces w obrębie jednej iteracji – mówił o tym między innymi Petr Douša na Polish IA Summit. UX z zespołem przygotowuje projekt, który następnie jest wdrażany. Prowadzone są błyskawiczne testy użyteczności, w których trakcie identyfikowane są problemy poprawiane w następnym kroku. Większe testy z użytkownikami końcowymi organizowane są raz na parę tygodni i w ich trakcie identyfikowane są dalsze rzeczy do poprawy. Osobiście jednak w takim układzie nie miałam jeszcze okazji pracować. Chętnie posłucham, jeśli ktoś z czytelników ma takie doświadczenie i będzie chciał się nim podzielić.

 

Tworzenie oprogramowania w metodykach zwinnych może się wydawać na pierwszy rzut oka chaotyczne, powierzchowne i stresujące. Na drugi rzut oka także :) Ale w tym szaleństwie jest metoda. Parafrazując Winstona Churchilla: Agile jest najgorszym sposobem tworzenia oprogramowania, ale nic lepszego nie wymyślono.

Projektant user experience w środowisku agile’owym powinien być zwinny w metodach i rytmie pracy. Jednak jakość tworzonego user experience nie powinna na tym ucierpieć. Słowo „agile” nie jest wymówką na fuszerkę projektową czy pomijanie badań i testów. Samo projektowanie nadal powinno być dokładnie przemyślane i ugruntowane w solidnych podstawach wyprowadzonych z badań, wiedzy i doświadczenia projektanta.

Autorka

Ewa Sobula

www: http://www.linkedin.com/pub/ewa-sobula/30/407/694
UX designer w Sabre Airline Solutions. Umiejętności badawcze i analityczne rozwijała na socjologii, by lepiej rozumieć użytkowników. Równolegle uczyła się tworzenia serwisów internetowych, by poznać technologiczne możliwości i ograniczenia. Teraz z przyjemnością łączy te kompetencje projektując i badając serwisy. Czytaj więcej
Tagi: , , ,
  • http://www.facebook.com/michal.kokocinski Michał Kokociński

    Od 2 lat pracuję w Scrumie jako UX. Faktycznie muszę przyznać, że duże nowe projekty wymagają dużo więcej „zwinności” od UXa niż projekty w fazie utrzymania. Przez 1,5 roku utrzymywaliśmy ogromną usługę, zespół był scrumowy, iteracje 2 tygodniowe i przyznam że szło nam bardzo zwinnie, ale jak piszesz badania były z wyprzedzeniem (n-1), projektowanie było w obecnej iteracji (n) a testowanie w następnej (n+1). Bywało czasami też tak że wszystko odbywało się na 3 iteracje przed dewelopmentem, ale w formie mocno szkicowej, a kiedy wchodzili deweloperzy UX po prostu szkicował na bieżąco siedząc obok deweloperów z flipchartem. I tak pracuje mi się najlepiej ponieważ nawet deweloperzy :) uczą się bardzo szybko zwracać uwagę na najmniejsze szczegóły z pola UX. 

  • http://mariusz.cc Mariusz

    Od 2008. roku pracuję jako UX designer w systemie agile, od 2009 w systemie Kanban software development. Bardzo dużo pomaga znajomość metodologii Lean Startup. :)

  • http://www.facebook.com/tkwadrat Tomasz Tomaszewski

    Bardzo ciekawy wpis, pokazujący tajniki pracy UXa w zwinnych przedsięwzięciach. Brawo! 

    Aczkolwiek daleki byłbym od stwierdzenia że agile to jedyne słuszne metodyki prowadzenia projektów. Mają swoje wady i zalety, jak wszystko. Podobnie jak wykonywanie projektu aplikacji po stronie wytwórcy oprogramowania, in-house (do czego praktykowany w firmach Scrum właściwie obliguje). 

  • http://www.facebook.com/olesku Oleś Kuc

    „Projetowanie”? ;) fajny artykuł, dzięki!

  • abbey

    Nice post!