Szerintem az Agile egy szoftver-fejlesztési módszertan, nem pedig szoftver-tervezési. Ezt figyelembe véve remekül lehet integrálni a UX-es tervezési folyamatokat az agilis fejlesztéssel, ahogy ezt tettem is jópárszor.
Most mutatnék 4+1 kapcsolódási pontot, hogyan érdemes őket összerakni.
Az Agile ultrarövid története
Az Agile alapköve az Agile Manifesto, amit 17 programozó írt alá másfél évtizede. Legelterjedtebb módszertana a Scrum, amit két programozó mutatott be közülük 20 évvel ezelőtt egy programozó-konferencián.
Az Agile arról szól, mik az ideális szervezeti körülményei egy fejlesztőcsapatnak: nagy hangsúlyt fektet
- a gondolkodás szabadságára,
- az emberek közti kapcsolatra,
- az egyeztetésekre és a
- belátható időegységekre.
A Cooper-féle tervezési folyamat rövid története
Alan Cooper a Visual Basic feltalálója. Későbbi éveiben rájött, a számítógépeket azért utálják az emberek, mert a programok készítésekor nem veszik figyelembe őket – holott valójában minden programnak csak a felhasználás ad értelmet.
Cooper azon kezdett el gondolkozni, hogyan lehet módszeresen olyan programokat előállítani, amelyek jobbá teszik az emberek életét. Ezt a folyamatot – amit Kim Goodwin tökéletesített – tekinthetjük a UX tervezés alapfolyamatának.
Ennek a neve Goal-Directed Design Process.
Kép forrása: Alan Cooper et al: About Face 3 (egy gyors összefoglaló itt)
Ennek a folyamatnak közeli rokona az összes hivatalos UX-folyamat, bár sokat köszönhetünk az ipari terméktervezésnek is, ne menjünk bele tyúk-tojás dilemmákba.
A legtöbb cég UX folyamata ezek egyéni variánsa, a FIBA-é pl. konkrétan így nézett ki az én időmben:
FIBA design folyamat 2014. Írásbeli engedéllyel közölve
Miről és miről nem szólnak ezek a folyamatok?
A Cooper-folyamat nem szól fejlesztésről: egy tisztán tervezési folyamat, amelynek
- alapja a felhasználói igények,
- ebből állítja elő azokat a követelményeket, amelynek a végterméknek meg kell felelnie, és
- biztosít egy olyan feedback-mechanizmust, amely kideríti, a felhasználó igényei kielégültek-e (sic).
Az Agile és a Scrum nem szól tervezésről, és főként nem szól felhasználókról: a Scrum arról szól, a fejlesztésnek milyen napi folyamatai vannak. A user szó az Agile Manifesto hitvallásában egyszer, az aktuális Scrum Guide-ban egyszer sem* fordul elő.
A Scrum arról szól, hogy időben könnyen becsülhető, rövid idő alatt megoldható követelményeket fejlesztünk ciklusokban, majd várunk egy külső visszajelzésre.
A kettő integrálása egyszerű: csinálja mindkettő azt, amiben jó: a designerek tervezzenek, a fejlesztők fejlesszenek.
1. kapcsolódási pont: a product owner
A Scrum rendszerében minden igény a product ownertől jön. Senki nem születik product ownernek, és nincsenek több éves product owner képzések: ez egy egyszerű szerep.
A felhasználói igényeket a UX képviseli. Világos, hogy valamilyen szempontból a product owner szerepet kell megvalósítania, vagy legalábbis azt kiegészítenie.
A gyakorlatban ez vagy úgy zajlik, hogy a UX-es játssza a PO-t (esetleg fordítva, bár ezzel óvatosan: a UX egy szakma, többéves, diplomás képzésekkel), vagy a PO és a UX szorosan együttműködnek.
2. kapcsolódási pont: a product backlog
A backlog a hátralévő követelmények listája, egyfajta ToDo lista. Alapvetően kétféle van belőle:
- a teljes termékre vonatkozó product backlog, illetve
- az aktuális ciklusra “bevállalt” követelmények listája, a sprint backlog.
Egy Scrum ciklus (a neve: sprint) hossza 1-3 hét, rendszerint két hét körül van.
Fontos, hogy a sprint backlog-jába csak olyan elemek kerülhetnek bele, amelyről megbecsülhető, mennyi idő alatt lesznek készen, hisz mindent be kell tudni fejezni 2 hét alatt.
Ezzel két baj van:
- ezt végleges képernyő- és folyamattervek nélkül nem lehet megbecsülni.
- a Cooper-folyamatot követve két hét alatt örülünk, ha a kutatási időpontokat leegyeztetjük, nemhogy több generációnyi prototípust leteszteljünk, és még ez után kéne gyorsan lefejleszteni.
Az én véleményem az, hogy a tervezésnek semmi keresnivalója a fejlesztési sprintben:
- ütemezése a kutatási ütemezésen múlik
- jelentős időt emészt fel (a sprint felét is akár)
- a kutatási eredmények új követelményeket szülnek
- egy követelmény lehet 1 nap de lehet 3 hónap fejlesztési időt követel
A két feladat időskálája teljesen eltérő
Mondok egy egyszerű példát:
A UX-es kinyitja egy webshop statisztikáit, és rájön, az emberek azért nem vásárolnak, mert túl lassú az oldal.
Megírja az alábbi egymondatos specifikációt (user story-t):
Mint Google keresőből jövő potenciális vásárló, szeretném ha a termék adatlapja 1 másodpercen belül betöltődne, különben nyomok egy visszát és megveszem a következő linken.
(As a potential customer coming from Google search, I want the product pages to load within 1 second so that I don’t turn back to go to the next site in my search results)
Ez laza 3-4 hónap tetszőleges fejlesztőcsapatnak. Előállítási ideje UX szempontból ellenben fél óra. Jobbak esetleg linkelhetnek egy megfelelő cikket ennek alátámasztására, vagy futtathatnak valamilyen tesztet.
Mondok egy másikat:
“Több hónap kutakodás után végre rájöttünk, mi okozza a sok lefordulást. Nagyobbá tennéd ezt a gombot légyszives?”
(ezt hívjuk a 300 millió dolláros gomb esetének)
Fejlesztési idő: fél óra. Kutatási idő: hetek.
Szóval a végeredmény: a fejlesztés dolgozzon azon, amivel a UX már végzett, avagy:
Build the (product) backlog, not the sprint!
3. kapcsolódási pont: a grooming meeting
Egészen a legutóbbi időkig a Scrum módszertanban minden ciklushoz alapvetően két megbeszélés tartozott:
- a planning meeting, amin elmondták, mit kéne lefejleszteni a következő két hétben, és megegyeztek, ebből mi fér bele és
- a review meeting, ahol megmutatták, ebből mi lett kész.
A probléma az volt, hogy a planning meetingen általában kiderült, a követelmények nem eléggé tiszták ahhoz, hogy tudjuk, egyáltalán meg lehet-e oldani őket két hét alatt, illetve ha a product owner így is gondolta, itt merültek fel a váratlan technikai akadályok.
Erre találták ki a grooming meetinget, amely abban egyezik meg,
- mik azok a követelmények, amiket ha holnap kéne elkezdeni, tudnánk, mit kell vele csinálni,
- illetve mi kell ahhoz, hogy a követelmények ilyenek legyenek.
Ez egy UX-esnek csodálatos terep: itt elmondhatja,
- milyen felhasználói igények vannak,
- azok milyen követelmények mellett tudnának teljesülni
- miközben visszajelzést kap arról, mi az amit le lehet fejleszteni.
4. kapcsolódási pont: a sprint review / testing day
A sprint review-t arra találták ki, hogy bemutassák az elkészült megoldások használatát a product ownernek, ezzel az “elfogadja” vagy “visszautasítja” a sprintet – bár utóbbi nagy gorombaságnak számít, és formális következménye nincs igazán.
Szerencsés esetben a sprint review egy olyan usability teszt-szerűség, ahol a product owner megpróbálja a követelményeket végignyomogatni a rendszeren. Ezzel rendszerint az a baj, hogy a product owner túl közel van a tűzhöz, a felhasználóval ellentétben valamelyest ismeri annak belső felépítését, tudja hogy „kéne” működnie.
Szerencsétlenebb esetben a programozó nyomogatja végig a rendszer új komponenseit, és imádkozik közben, hogy ne fagyjon le – ami néha nem sikerül.
Valójában a sprint review célja feedback szerzése az eddig elkészült munkáról: ehhez pedig a UX-es nagyonis ért.
Szóval a javaslat: ezt a napot töltsük közösen felhasználói tesztekkel, hogy megtudjuk, az elkészült rendszer hogy viselkedik a felhasználók kezében.
+1 A kávégép
Én, ha tehetem, a fejlesztőkkel ülök együtt: a folyamatosan csepegtetett információ a felhasználókról közelebb hozza őket, mert bár igyekszünk mindenkit kivinni kutatásra, azért minden kutatási alkalomra nem vihetünk ki mindenkit.
S persze van sok kis egyértelműsítő kérdés, elsőre megoldhatónak tűnő, de közelről nehéz technikai probléma, lefedetlen esetek, stb. Ha nem ülsz fizikailag a fejlesztőtől néhány méterre, lehet hogy hoz olyan tervezési döntéseket, amiről nem is fogsz tudni.
Összegzés
Ezen 4+1 szabály betartásával az a tapasztalat, hogy lehet „szabványosan” vezetett UX-et működtetni „szabványosan” vezetett Scrum mellett. Ezt csináltam több szervezetnél több éven keresztül.
Óvva intenék mindenkit ugyanakkor attól, hogy a UX-et meg ne próbálja beszuszakolni a scrum team sprintjébe:
- A UX a követelményeket dolgozza ki, azaz azt mondja meg, mik legyenek a user story-k
- Bármennyire is gyorsan dolgozik a UX, napokkal hátráltatja a sprintet a kidolgozás
- Kidolgozott UX tervek hiányában a fejlesztés ideje nem lesz becsülhető, így sprintbe se rakható
- Sokkal gyorsabb már a tervezési ciklusok végén feedbacket szerezni, mint csak a sprint végén.
A UX-es nem fejlesztő, teljesen felesleges frusztrációt okoznak:
- a sprinten belüli határidők („áll a team, rád várunk!”),
- a kutatásoktól független követelményrendszer („mint felhasználó, szeretnék reklámot” és társai),
- az egyiterációs, esetleg ellenőrizetlen dizájn („vagy bejön vagy nem„)
- az ebből következő kényszerű változtatások („de hisz azt mondtad, úgy jó lesz, mi lefejlesztettük, te vagy a UX-es„)
Szóval hagyjuk élni egymást, és hagyjuk egymást úgy dolgozni, ahogy célszerű, és így mindkét folyamatból kihozhatjuk a maximumot.
Kérdések és válaszok (melléklet)
Nem lesz ettől az egész waterfall-szerű?
Nem. Sok agilis fejlesztőcsapat ma is a követelmények részeként kapja a drótvázakat, dizájnokat. A UX mindössze a “tudományos” módszertana annak, hogyan jussunk el “jó” követelményekig. Az egymásraépülés a UX-ben pedig valójában nem teljesen lineáris, ellenben szükségszerű.
Nem a fejlesztőcsapat joga eldönteni, mi a legegyszerűbb célravezető megoldás?
Műszakilag igen, pszichológiailag nem. Attól még hogy parancssoros megoldásokat egyszerűbb lenne fejleszteni és rövidebbre is becsülhető, a felhasználók által ténylegesen minimálisan használható termék szinte mindig bonyolultabb mint ahogy azt elsőre elképzeljük.
A baj az, hogy a minimálisan megfelelő dizájnt kitalálni is napok kérdése, annak leellenőrzése, hogy ez tényleg minimálisan használható-e alsó hangon néhány óra.
Nem elég kitalálni a dizájnt a sprint elején?
Hiába rajzolja fel valaki egy planning meetingen a táblára az ötlete drótvázát, hivatalos szakmai véleményt mondani egy UX-es ott helyben nem tud, ha bármilyen nézőpontot kifejez, akkor és ott valószínűleg a társas nyomásnak tesz eleget.
Ha ellenőrzött dizájnt akarunk csak lefejleszteni, az nem egy meetingen fog megszületni, annak van egy ellenőrzési folyamata, amely csak külső szereplők bevonásával lehetséges.
De akkor hogyan szervezzük a UX munkáját?
A kutatás-fejlesztés teljes időigénye kiszámíthatatlan. Szerintem a Scrum kivette a kiszámítható dolgokat (a fejlesztést), berakta őket a sprintbe, a nem kiszámíthatóakat (a kutatást), pedig a kapun kívülre, a Product Owner kezébe rakta.
Hogy hány iteráció alatt jut el egy UX terv fejleszthető szintre – nem tudni. Jó kutatási alapokkal, gyakorlott tervezővel a várható idő rövidebb, de a bizonytalansági faktor óriási.
A folyamatábrákon nem látszik jól, de minden UX fázis akár 4-8 iterációt is magába foglalhat.
A MÁV jegyvásárló automatája például már rég túl van a 12. iterációján és még mindig prototípus fázisban van. De ha azt nézzük, hogy az iteráció néhány óra, esetleg 1-2 nap, más megvilágításba kerül.
Az én esetemben legtöbbször kanban pipeline-t alkalmaztunk a munkára. Számomra ugyanis sokkal nagyobb kérdés, hogy:
- Az egyes problémák melyik fázisukban vannak épp
- Hány problémával foglalkozunk tényleg adott időszakban párhuzamosan
Akkor a dizájnról nem is lehet megmondani, mennyi idő?
Önmagában egy fázis egy iterációja becsülhető:
- a kutatások időtartama adott (de nem feltétlenül lesz több új válaszunk mint új kérdésünk)
- a prototipus építés időigénye technológiától és a prototípus részletességétől függően adott (1-2 órától 1-2 napig terjed)
- jól definiált prototípus/drótvázak esetén a vizuális dizájn ideje adott (szinte sose fogadják el az első iterációt)
- a specifikálás a képernyők komplexitásának ismeretében jól becsülhető (ha a megvalósíthatóság ismert)
(A concept fázis nagy kivétel: szinte csak az biztos, hogy aludni kell rá)
Míg a fejlesztésben ritka egy iteráció teljes visszadobása, a dizájnban ez mindennapos. Tehát nem az a baj, hogy nem tudjuk, mennyi idő egy iteráció: nem tudjuk, hány iteráció alatt jutunk értelmes megoldásra.
Épp ezért a dizájn néha egyben legyárt akár 12-15 változatot is, amely gyorsítja a folyamatot ahhoz képest, ha egyetlen változattal iterálna, de nem oldja meg az iterációk szükségességét.
Sajnos az első vagy a maximum N. iteráció elfogadása nem opció, a tesztek elég egyértelműen megmondják valamiről, ha az nem működik.
Akkor a UX-es csak ezekkel az iterált fázisokkal tölti az idejét?
A UX-re rengeteg szervezési munka hárul: míg a Scrum papíron „hermetikusan” elzárja a fejlesztést, a dizájn ezt nem teheti meg:
- a kutatások szervezése macera,
- a belső egyeztetéseké még inkább (az egyes fázisiterációk előtt/után sokszor meeting van!)
- ha valamelyik menedzsernek kipattan az isteni szikra a fejéből, jobb azonnal reagálni
Míg a fejlesztés elvonulhat 2 hétre, ennyi idő alatt hatalmas károkat okoz, ha a megrendelő beleéli magát egy rossz ötletbe.
Ha ilyeneket írsz az Agile-ról, nem érted az Agile-t!
Szeretném ha megkülönböztetnénk az „értem az Agile-t” és a „hiszek az Agile mindenhatóságában„-t.
Néha nehéz megérteni, ha 15 prototípus építésére és tesztelésére van mondjuk idő egy sprintben, lehet, fél óra alatt találok egy megoldást, lehet két hét alatt találok 15-öt ami nem működik.
Gyakran máshol bevált megoldások nem működnek. Tudtad például, hogy a gov.uk-n kerülik a select boxokokat?
A UX emberekkel dolgozik, a célja hogy az embereknek teremtsen jobb világot. Az emberek pedig megbecsülhetetlenek és kiszámíthatatlanok.
* A Scrum user kifejezés – amely csak egyszer fordul elő – nem a lefejlesztett terméket használó, hanem a módszetant alkalmazó embereket jelöli.
