Agilní inženýrství použitelnosti - Agile usability engineering - Wikipedia
 | The neutralita tohoto článku je sporný. (prosinec 2013) (Zjistěte, jak a kdy odstranit tuto zprávu šablony) |
Agilní inženýrství použitelnosti je metoda vytvořená kombinací agilní vývoj softwaru a inženýrství použitelnosti praktik.[1] Agilní inženýrství použitelnosti se pokouší aplikovat principy rychlého a iterativního vývoje na oblast uživatelské rozhraní design.
Rané implementace inženýrství použitelnosti v systému Windows design zaměřený na uživatele vstoupil do profesionální praxe v polovině 80. let. Rané implementace agilního vývoje softwaru se vyvinuly v polovině 90. let. Teprve v posledních několika letech interakce člověk-počítač komunita zaznamenala široké přijetí agilního inženýrství použitelnosti.[1]
Dějiny
Když metody jako extrémní programování a testovaný vývoj byly představeny Kent Beck Aby bylo možné pracovat s agilním prostředím, muselo se inženýrství použitelnosti stát lehkým. Jednotlivci jako Kent Beck pomohli utvářet metodologie agilního inženýrství použitelnosti prací na projekty tak jako Komplexní kompenzační systém Chrysler. Takové časově řízené projekty pomohly jednotlivcům zažít a porozumět nejlepším metodikám procvičování při práci v agilním prostředí.
Časný příklad inženýrství použitelnosti v agilním vývojovém prostředí softwaru lze nalézt v práci Larry Constantine a Lucy Lockwoodová, která navrhla informace o učebně pro obyvatele prohlížeče systém řízení. Během tohoto procesu návrhářský tým pracoval přímo se vzdělávacím týmem, který sloužil jako oba experti na předmět a reprezentativní koneční uživatelé rozvíjet počáteční roli uživatele modely a soupis případů úkolů. Tento proces napodobuje participativní design. S tímto materiálem byly makety iterativně navrženy tak, aby dosáhly požadovaného cíle „přísného cíle návrhu umožňujícího okamžité a produktivní použití systému na základě jednostránkového tutoriálu“.[2]
Následující tabulka zobrazuje rozdíly a podobnosti procesů s nízkou hmotností ve srovnání s procesy s vysokou hmotností, jak navrhuje Thomas Memmel.[1]
| Těžké procesy | Lehké procesy |
|---|---|
| Podrobné, aktuální dokumentace a modely | Kartové a ručně kreslené abstraktní modely Cestovat nalehko Spíše komunikujte než dokumentujte |
| Vysoce věrné prototypy | Abstraktní prototypy, používejte nejjednodušší nástroje |
| Vyvíjejte a ověřujte koncepty pomocí zpětné vazby od uživatelů Opakovat | Odvaha Návrh spíše pro potřeby (úkoly uživatele) než očekávání uživatelů Načtěte design spíše z modelů než nepřetržitou zpětnou vazbu od uživatelů |
| Časově náročné hodnocení použitelnosti, workshopy s intenzivní integrací zúčastněných stran | Rychlé kontroly použitelnosti Není třeba hodnotit, zda mají modely pravdu |
Metody
Mnoho projektů, které se používají v procesu agilního vývoje softwaru, může těžit z agilního inženýrství použitelnosti. Jakýkoli projekt, který nelze použít modely a zástupci budou mít problémy v agilním inženýrském prostředí použitelnosti, protože projekty musí být co nejlehčí.
Během fáze inženýrství použitelnosti v agilním vývoji uživatelé pracují s produktem nebo službou za účelem poskytování zpětné vazby, hlášení problémů a nových požadavků vývojářům. Proces se provádí interaktivně se zaměřením nejprve na základní funkčnost a později na pokročilejší funkce. Jak proces postupuje do pokročilých fází, s produktem nebo službou pracuje více uživatelů.[3] Řešení se rychle aplikují na základě závažnosti. Fáze končí a milník.
Paul McInerney a Frank Maurer podali a případová studie což potvrzuje Návrh uživatelského rozhraní postupy vyžadované úpravy; zejména s cílem přizpůsobit iterativní vývoj. Byl však vyvozen závěr, že výsledný Návrhy uživatelského rozhraní rozhodně nejsou horší než to, co by se stalo se standardním přístupem v těžké váze.[4]
Základní postupy v agilní modelování jak je popsáno v Scott Ambler, pomůže popsat zaměření v agilním inženýrství použitelnosti. Mezi hlavní postupy patří ověřování, týmová práce, jednoduchost, motivace, produktivita, dokumentace a iterativní a přírůstkové.[5]
Upravený agilní vývojový proces s nástroji použitelnosti zahrnutými byl vyvinut a představen v CHI ‘08 Rozšířené abstrakty o lidských faktorech ve výpočetních systémech. Nástroje použitelnosti zahrnují rozšířené jednotkové testy pro vyhodnocení použitelnosti, extrémní personas rozšířit typické extrémní programování uživatelský příběh, uživatelské studie k rozšíření konceptu extrémního programování u zákazníka, expertní hodnocení použitelnosti k řešení ad hoc problémy a testy použitelnosti k řešení problémů zástupců zákazníků na místě.[6]
Problémy
Kvůli snaze začlenit tradiční metody inženýrství použitelnosti do agilního prostředí se objevilo mnoho problémů. Bez komplexních zdrojů praktici se pokusili následovat vzorce ostatních, kteří byli dříve úspěšní.[7] Tabulka 2 představuje tabulku Problémy, příznaky a možná řešení vyvinutou Lynn Miller a Desirée Sy a uvedenou v CHI ‘09 Rozšířené abstrakty o lidských faktorech ve výpočetních systémech.
Následující tabulka je souhrnem hlavních problémů, se kterými se setkávají odborníci na uživatelské zkušenosti při provádění agilního UCD.[7]
| Problém | Příznaky | Možné řešení |
|---|---|---|
| Nedostatek času na návrh | • Vývojáři čekající na návrhy • Pokles kvality designu • Designy nebyly ověřeny u zákazníků | • Samostatné a paralelní stopy UX Design / Developer[8][9][10][11][12] • Rozsah aktivit UX musí být malý, přírůstkový[8][9] • RITE formativní testování použitelnosti [13][14] • Rychlý kontextový design[15] • "Designové studio"[16] • Design chunking[8] • Spojte různé aktivity UX do jedné relace[17] • Přiveďte uživatele (a data) k vám[17] • Odlehčit proces shromažďování požadavků[8][9][10][11][18] [8][9][10][11][18] |
| Sprinty jsou příliš krátké | • Návrhy nelze dokončit včas • Není čas na testování použitelnosti • Není čas na navázání kontaktu se zákazníkem | • Samostatné a paralelní stopy UX Design / Developer [8][9][10][11][12] • Rozsah aktivit UX musí být malý, přírůstkový[8][9] • RITE formativní testování použitelnosti[13][14] • Rychlý kontextový design[15] • "Designové studio"[16] • Design chunking[8] • Spojte různé aktivity UX do jedné relace[17] • Přiveďte uživatele (a data) k vám[17] • Odlehčit proces shromažďování požadavků[8][9][10][11][18] |
| Nedostatek zpětné vazby od uživatelů | • Zpětná vazba není dostatečně brzy • Žádné údaje, podle kterých je třeba jednat - vládnou názory • Produkt není ověřen | • Samostatné a paralelní stopy UX Design / Developer[8][9][10][11][12] • Rozsah aktivit UX musí být malý, přírůstkový[8][9] • RITE formativní testování použitelnosti[13][14] • Rychlý kontextový design[15] • "Designové studio"[16] • Design chunking[8] • Spojte různé aktivity UX do jedné relace[17] • Přiveďte uživatele (a data) k vám[17] • Odlehčit proces shromažďování požadavků[8][9][10][11][18] |
| Slabý agilní „zákazník“[16] | • Koncoví uživatelé a klienti se nezúčastní • Nelze získat buy-in od zbytku týmu • Jsou přijímána neinformovaná rozhodnutí | • Osoba UX může působit jako agilní role zákazníka[19] • Každý člověk UX pracuje v jednom scrum týmu[19] • Vyberte si, se kterými skrumážovými týmy budete rozumně pracovat[18] • Ověřené návrhy jsou předány vývojářům k implementaci[8][9] • UX se účastní plánování cyklu,[9] přináší odpovídající zpětnou vazbu od uživatelů[8] • Pokud něco nevyjde, nepřijdou žádné funkce[18] |
| UX není na plný úvazek v jednom agilním týmu | • UX čas strávený na mnoha schůzkách místo na designech a iteracích • Demoralizováno poklesem kvality UX | • Osoba UX může působit jako agilní role zákazníka[19] • Každý člověk UX pracuje na jednom scrum týmu[19] • Vyberte si, se kterými scrum týmy budete rozumně pracovat[18] • Ověřené návrhy jsou předány vývojářům k implementaci[8][9] • UX se účastní plánování cyklu,[9] přináší odpovídající zpětnou vazbu od uživatelů[8] • Pokud něco nevyjde, nepřijdou žádné funkce[18] |
| Žádné plánování sprintu / cyklu | • Velký počet nevyřízených funkcí / chyb • Zpětná vazba k prioritizaci byla ignorována • Žádná kontrola nad načasováním návrhů | • Osoba UX může působit jako agilní role zákazníka[19] • Každý člověk UX pracuje na jednom scrum týmu[19] • Vyberte si, se kterými skrumážovými týmy budete rozumně pracovat[18] • Ověřené návrhy jsou předány vývojářům k implementaci[8][9] • UX se účastní plánování cyklu,[9] přináší odpovídající zpětnou vazbu od uživatelů[8] • Pokud něco nevyjde, nepřijdou žádné funkce[18] |
| Zpětná vazba uživatelů je ignorována | • Sada funkcí je odlita do kamene • Není čas zapracovat změny • Není povoleno žádné opětovné uspořádání funkcí | • Osoba UX může působit jako agilní role zákazníka[19] • Každý člověk UX pracuje v jednom scrum týmu[19] • Vyberte si, se kterými scrum týmy budete rozumně pracovat[18] • Ověřené návrhy jsou předány vývojářům k implementaci[8][9] • UX se účastní plánování cyklu,[9] přináší odpovídající zpětnou vazbu od uživatelů[8] • Pokud něco nevyjde, nepřijdou žádné funkce[18] |
| Chybí „velký obrázek“ | • Žádná sdílená vize ani konečný cíl • Přílišné zaměření na detaily • Je těžké stanovit prioritu / rozhodovat o návrhu | • Přesvědčte agilní tým, aby si osvojil Cycle Zero[8][9][10][11][20] [8][9][10][11][18] • Zvažte designové cíle z různých úrovní podrobností (produkt, vydání, funkce, designový blok[12] |
| Špatná komunikace | • Nepochopené designy • Agilní tým nekupuje návrhy • Důležité informace jsou ztraceny | • Zahrnout vývojáře do procesu návrhu[8][9] • Použitelnost zahrnuta v kritériích přijetí[8][9] • Denní kontakt pro kontrolu pokroku[8][9] • Designové karty pro stand-up meetingy[8] • Vydávací karty pro hlášení použitelnosti[8] • Dokumenty jsou pro návrhářský tým[8] |
| Tým není umístěn společně | • Žádný smysl pro tým - nedostatek důvěry • Jazykové a / nebo časové bariéry • Nedostatečná komunikace | • Nástroje pro práci na dálku (telefonické a webové náhrady)[11][18] • Společné vyhledání pro plánování cyklu[11][18] |
| Problémy se závislostí | • Vyžadování příspěvků od neagilních týmů (např. Odhlášení z marketingu, právníci) | • Vedoucí skrumáže nebo facilitátor se silnými přesvědčovacími schopnostmi může věci rychle posouvat.[18] |
Reference
- ^ A b C Memmel, T (2006). Agilní inženýrství použitelnosti. Citováno 4. listopadu 2013 z http://www.interaction-design.org/encyclopedia/agile_usability_engineering.html
- ^ Constantine, L. L., Lockwood, L. A. D. (2002). Inženýrství zaměřené na využití pro webové aplikace. Software IEEE, 19 (2), 42-50. doi:10.1109/52.991331
- ^ Stober, T., Hansmann, U. (2010). Agilní vývoj softwaru: Osvědčené postupy pro velké projekty vývoje softwaru. (str. 3.7.2). Berlin, Heidelberg: Springer-Verlag.
- ^ McInerney, P. & Maurer, F. (2005, listopad). UCD v agilních projektech: Dream team nebo odd pair ?. Interakce ACM, 12 (6), 19-23. doi :: 10.1145 / 1096554.1096556
- ^ Ambler, Scott W., (2002). Agilní modelování: efektivní postupy pro extrémní programování a jednotný proces. dostupný z http://common.books24x7.com/toc.aspx?bookid=3755
- ^ Wolkerstorfer, P., Manfred T. a kol. Sondování agilního procesu použitelnosti. CHI ‘08 extended abstracts on human factors in computing systems, 5. dubna 2008, New York, NY. doi:10.1145/1358628.1358648
- ^ A b Sy, D., Miller, L. (2009). Agilní uživatelská zkušenost SIG. CHI '08 rozšířené abstrakty o lidských faktorech ve výpočetních systémech, 751-2754. doi:10.1145/1520340.1520398
- ^ A b C d E F G h i j k l m n Ó p q r s t u proti w X y z aa ab ac Sy, D. Přizpůsobení vyšetřování použitelnosti pro agilní design zaměřený na uživatele. Journal of Usability Studies 2, 3 (2007), 112--132
- ^ A b C d E F G h i j k l m n Ó p q r s t u proti w Miller, L., Případová studie vstupu zákazníků pro úspěšný produkt, Sborník z konference Agile Development, s. 225-234, 24. – 29. Července 2005. doi:10.1109 / ADC.2005.16
- ^ A b C d E F G h i Federoff, M., Villamor, C., Miller, L., Patton, J., Rosenstein, A., Baxter, K., Kelkar, K., Extreme usability: adapting research approach for agile development, CHI '08 extended abstracts o lidských faktorech ve výpočetních systémech, 5. – 10. dubna 2008, Florencie, Itálie. doi:10.1145/1358628.1358666
- ^ A b C d E F G h i j k Sy, D., Miller, L., Optimalizace agilního designu zaměřeného na uživatele, CHI '08 rozšířené abstrakty o lidských faktorech ve výpočetních systémech, 5. – 10. Dubna 2008, Florencie, Itálie. doi:10.1145/1358628.1358951
- ^ A b C d Patton, J. Dvanáct nových osvědčených postupů pro přidání práce UX do agilního vývoje. 3. října 2008: „Archivovaná kopie“. Archivovány od originál dne 2013-09-14. Citováno 2013-12-14.CS1 maint: archivovaná kopie jako titul (odkaz)
- ^ A b C Medlock, M., Terrano, M., Wixon, D. Použití metody RITE ke zdokonalení produktů: definice a případová studie. Sborník UPA 2002.
- ^ A b C Schrag, J. Použití formativního testování použitelnosti jako nástroje pro návrh rychlého uživatelského rozhraní. Sborník UPA 2006.
- ^ A b C Holtzblatt, K., Wendell, J. B. a Wood, S. (2005) Rapid Contextual Design. Morgan Kaufmann / Elsevier.
- ^ A b C d Ungar, J., White, J., Agile user centered design: enter the design studio - a case study, CHI '08 extended abstracts on Human Factors in computing systems, 5. – 10. Dubna 2008, Florencie, Itálie. doi:10.1145/1358628.1358650
- ^ A b C d E F Sy, D. Formativní vyšetřování použitelnosti pro otevřené úkoly. Sborník UPA 2006.
- ^ A b C d E F G h i j k l m n Ó p Sy, D., Miller, L., Informal SIG: Optimizing Agile UCD, CHI 2007
- ^ A b C d E F G h Miller, L. Interaction Designers and Agile Development: A Partnership. Sborník UPA 2006.
- ^ Sharp, H., Biddle, R., Gray P., Miller, L., Patton J., Agile development: opportunity or fad ?, CHI '06 rozšířené souhrny o lidských faktorech ve výpočetních systémech, 22. – 27. Dubna 2006, Montréal, Québec, Kanada. doi:10.1145/1125451.1125461