Design zaměřený na člověka vs. agilní vývoj: adaptivní rovnováha

„Vyvažování“ (CC BY-NC 2.0) od Pieter v Marion

Najděte agilní vládní zprávy, případové studie, videa, školení a další na adrese www.agilegovleaders.org.

Ve světě informačních technologií existuje napětí mezi designem Human Centered Design (HCD) a Agile. Obě metodiky se shodují ve svém zaměření na koncového uživatele a na důslednou iteraci. Agilní odborníci se však domnívají, že design a vývoj začínají současně a postupují současně, zatímco designéři HCD často věří ve vyhrazenou fázi objevu, která předchází začátku vývoje. V oblasti občanského programování nebo vládních kontraktů může být toto napětí zvýšeno přísnými předpisy o zadávání veřejných zakázek, které vyžadují přísnější odpovědnost a plánování zdrojů než například svět začínajících podniků.

Některé týmy se pokoušejí vytvořit samostatnou fázi návrhu a vývoje, ve které se výzkum uživatelů promítne do plně věrných návrhů, které jsou poté implementovány agilnímu vývojovému týmu. Ale taková silná propast mezi designem a vývojem vypadá podezřele podobně jako Waterfallův model. Metody vodopádu, které zdůrazňují jasné oddělení fází, jsou riskantní a vedou k velmi nízké míře úspěšnosti. Agilní metodiky se snaží omezit nebo eliminovat neefektivitu v modelu Waterfall zvýšením spolupráce a udržením souladu členů týmu v celém cyklu vývoje produktu.

Abychom lépe porozuměli ideálnímu vztahu mezi agilními metodami a designem zaměřeným na člověka, začněme jasnými definicemi.

Co je design zaměřený na člověka?

Ačkoli existují jiná vysvětlení HCD, britská vláda Digital Service (GDS) to objasňuje dobře:

Proces návrhu musí začít identifikací a přemýšlením o skutečných potřebách uživatelů. Měli bychom je navrhnout kolem nich - ne asi tak, jak je v současné době „oficiální proces“. Musíme těmto potřebám důkladně porozumět - vyslýchat data, nejen vytvářet předpoklady - a měli bychom si uvědomit, že to, co uživatelé požadují, není vždy to, co potřebují.

- Zásady návrhu Gov.UK

Co je agilní?

Agilita je nejlépe vyjádřena v principech Agilního manifestu:

Přišli jsme si ocenit ...
Jednotlivci a interakce přes procesy a nástroje
Pracovní software přes komplexní dokumentaci
Spolupráce se zákazníky při sjednávání smlouvy
Reakce na změnu nad plánem

Všimněte si, že slovo „zákazník“ by mělo být vykládáno tak, že zahrnuje konečné uživatele, a skutečný agilní proces bude zahrnovat skutečné uživatele v průběhu vývojového cyklu. Z hlediska vládních smluv musí být sponzoři a administrátoři agentury považováni také za skutečné uživatele, ale správa je nezbytným služebníkem zákazníka. Vzhledem k tomu, že koncový uživatel obvykle neplatí ve vládní smluvní situaci, je příliš snadné začít s budováním platebního klienta a nikoli skutečného koncového uživatele; to je zásadní chyba.

Jaký je vztah HCD k Agile?

Hlavní rozdíl mezi HCD a agilností spočívá v tom, jak a kdy jsou různé role zaměstnanců aplikovány na projekt. To je znázorněno v diagramech níže, které ukazují možné personální obsazení designérů a vývojářů během životního cyklu projektu v každém z těchto dvou přístupů.

HCD navrhuje fázi objevu s omezeným nebo žádným zapojením vývojáře:

Zatímco Agile konkrétně požaduje hladký a nepřetržitý proces s vývojáři a designéry, kteří neustále spolupracují:

Zdá se, že britský GDS pracuje hybridně, prostředně. Zdůrazňuje tyto klíčové body:

  • Nový způsob, jak dělat věci: „Vytváření a testování malých kousků, rychle pracovat na vylepšení služby. Týmy budou pracovat na tom, jak nejlépe vyhovět potřebám uživatelů, pravidelně uvolňovat kód a pracovat agilním způsobem.
  • Uživatelé jsou zapojeni do celého designu a vývoje.
  • Postupný vývoj: Ve spolupráci s uživateli od prvního dne stanovte klíčové ukazatele výkonu (KPI) ve vašem objevu a ve fázích alfa. Poté přejděte k rychlému uvolňování aktualizací a vylepšení vývojového prostředí a změřte dopad vašich změn.

Tento hybridní model je zobrazen níže:

Jaké jsou důsledky těchto přístupů?

Agilní procesy jsou obecně považovány za úspěšnější než přístupy Waterfall. S ohledem na agilnost z pohledu designu zaměřeného na člověka vyvolává některé jemné otázky:

  • Jak vytvoříme pracovní software bez předchozího návrhu?
  • Znamená iterační proces, že se design v první a poslední iteraci mění stejně?
  • Mění se rovnováha talentů během cyklu vývoje produktu?
  • Pokud neustále měníte, co děláte, neztrácí to spoustu času?

Tvrdíme, že následující postupy umožňují efektivní spolupráci HCD a Agile:

  • Bezohledná iterace, která nepřevádí žádnou hodnotu na předchozí kódování, brání časnému kódování v překročení projektu od potřeb uživatelů.
  • Uživatelský výzkum je vždy vyžadován - a čím inovativnější je váš projekt, tím vyšší by mělo být procento práce věnované výzkumu uživatelů.
  • Ideální tým má vyváženou sadu dovedností.
  • Agilní metody podporují a doplňují design zaměřený na člověka, pokud existuje vzájemný respekt a dostatečné společné porozumění mezi inženýry a designéry.
  • Týmy by měly pracovat hladce a pružně.
  • Každý člen týmu musí být flexibilní při podpoře měnících se požadavků na tým jako celek v průběhu vývoje projektu.
  • Měřte produktivitu hodnotou, nikoli objemem. Tým jako celek musí být připraven se naučit, že posun od současné implementace v reakci na něco, co bylo objeveno, je změna k lepšímu.

Nyní pojďme prozkoumat každou z těchto myšlenek, abychom je lépe pochopili.

Iterativní proces

Iterační proces umožňuje, aby byl kód vyvíjen ruku v ruce s procesem navrhování, zejména pokud jsou počáteční prototypy považovány za jednorázové náčrtky. Designové sezení budou v ideálním případě zahrnovat vývojáře, lidi, kteří budou služby využívat, a designéry, kteří jsou odborníky na zapojení uživatelů a interpretaci kvalitativní zpětné vazby. Jak se software vyvíjí, designéři pravidelně kontrolují změny a celý tým se podílí na ověřování služby u skutečných uživatelů.

Čím inovativnější je váš projekt, tím vyšší by mělo být procento práce věnované výzkumu uživatelů.

Některé výzvy, jako například zrychlení výkonu softwarové komponenty s vysokou poptávkou, vyžadují malý design uživatelského prostředí, ale mohou přinést výsledky s vysokým dopadem. V takovém případě lze přímo zlepšit dokonalou uživatelskou zkušenost, především pomocí kódování a velmi malého designu. Mnohem častěji však problémy vyžadují pečlivý průzkum toho, jaké jsou skutečné potřeby uživatele. To platí zejména při budování inovativní nebo rušivé nové služby. Existuje tedy spektrum, které vychází z vysoce rušivých projektů s neprozkoumanými potřebami uživatelů, k problémům, ve kterých je dobře pochopena interakce uživatele. Výzkum zaměřený na uživatele může odhalit potřeby v neprobádaném území. Čím radikálnější je inovace projektu, tím vyšší procento naší celkové energie musí být vynaloženo na učení a ověření našich předpokladů.

Vyvážený tým by měl mít přibližně stejný počet lidí, kterým čelí uživatelé, jako softwaroví inženýři.

V moderní agilní praxi je v pokušení říci, že každý v týmu se orientuje na uživatele. Agilní průkopník Kent Beck však vyjádřil, že počet lidí „orientovaných na zákazníka“ - tj. Produktových manažerů, techniků zajišťujících kvalitu a návrhářů uživatelských zkušeností - by měl být přibližně stejný jako počet vyvíjejících se softwarových inženýrů.

V komerčním průmyslu je často tendence mít příliš mnoho programátorů, snad proto, že existuje smysl, ve kterém je snazší měřit a věřit v to, co programátoři dělají. Více řádků kódu se však nepřevádí přímo do produktu, který lépe odpovídá potřebám uživatelů a obchodním cílům. Jediným měřítkem produktivity, na kterém záleží, je spokojenost uživatelů. Vytváření produktů, které účinně vyhovují potřebám zákazníků, je důležitější, než dělat energeticky špatně.

Britská GDS říká, že neexistuje složitá pravidla pro složení týmu, ale naznačuje, že soubor dovedností musí být vyvážený:

„Neexistuje žádné tvrdé a rychlé pravidlo o rolích nebo struktuře týmu, které jsou potřebné k plnění těchto funkcí, ale hlavní tým bude pravděpodobně sestávat z:

  • správce služeb („vlastník produktu“)
  • pravděpodobně podporován produktovým manažerem
  • podporován jedním nebo více analytiky digitálního výkonu
  • manažer dodávky
  • tech lead
  • jeden nebo více návrhářů
  • jeden nebo více uživatelských výzkumníků
  • jeden nebo více vývojářů
  • jeden nebo více návrhářů obsahu
  • podpora technického architekta
  • podpora některých odborných znalostí webu

V některých menších týmech, které mohou zahrnovat některé lidi, kteří nosí mnoho klobouků, může programátor také vytvářet design zaměřený na uživatele. Jde o to vyvážit energii vynakládanou na činnosti více než vyvážit absolutní počet zaměstnanců, který je často řízen vedoucími pracovníky, kteří nemají svobodu pohybu osob tak plynule, jak by bylo optimální.

Agilní metody podporují a doplňují Human Centered Design, pokud existuje vzájemný respekt mezi inženýry a UX designéry.

Vzájemná úcta vyžaduje společnou slovní zásobu a porozumění školení, pracovních metod a motivace každého člena týmu.

Pro inženýry respektovat lidi orientované na zákazníka znamená, že pilně a kreativně píšou kód, aby designéři mohli testovat hypotézy a vyzkoušet si nápady co nejdříve v projektu. Musí vzít v úvahu nejen konečný cíl, ale také to, jak vyrobit něco, co by bylo možné otestovat, aby návrháři mohli hodnotit a používat co nejdříve v projektu.

V minulosti existovala tendence umožňovat kódu ovládat směr projektu, jakmile byl napsán, protože kód je tak obtížné změnit. Vývojáři však musí být ochotni zahodit kód a prototypy kvůli vývoji projektu ve směru, který přináší hodnotu pro uživatele. Musí ponořit svá ega a nesmí otrocky sledovat počáteční myšlenky, i když jsou ztělesněny v kódu a zdánlivě velmi cenné.

Uživatelé, kterým čelí lidé, musí respektovat inženýry tím, že kreativně kompromitují s tím, že produkt, který je k dispozici v prvním a raném sprintu, bude zřejmě omezen. Měli by použít kreativitu k nalezení implementovatelných řešení, která mohou být užitečně testována s uživateli na začátku procesu.

Týmy by měly pracovat hladce a pružně

Manažeři by měli respektovat přirozené odlivy a toky různých typů práce v různých fázích projektu, snižovat turbulence a neefektivitu poskytováním přirozeného zvyšování a snižování talentu.

V ideálním agilním světě je software vyráběn nepřetržitě a hladce. Neexistují žádné pochody smrti, žádné dramatické body uvolnění a žádné termíny. Každý cyklus projektu, ať už je to jednoduchá dvoutýdenní iterace nebo velký víceletý projekt, je jemně zvyšován a zvyšován tak, aby plynule plynul do další.

Tento ideál je však zřídka dosažen, zejména ve vládě, protože akviziční proces vede k získání akvizic na kousky. Federální nařízení o akvizicích (FAR) upřednostňuje spravedlivost před pohodlím. Jeho cílem je podpora nestranné soutěže, která nutně vyžaduje určité množství formálního procesu, nutí programového manažera k blokování práce na velké „kousky“.

Přesto je úkolem týmu - a zejména výkonných - snažit se o plynulé zvyšování a snižování zdrojů.

Jak se projekt vyvíjí, členové týmu musí být flexibilní při podpoře měnících se požadavků na tým.

V perfektním světě je manažer schopen plynule reorganizovat složení týmu tak, aby odpovídalo měnícím se potřebám. Vládní kontrakt zřídka dává programovým manažerům tuto schopnost. Tým může pomoci při získání ideálně hladkého projektu lehkým posunutím rolí. V dobře fungujícím, neustále se vyvíjejícím projektu, který by mohl znamenat rozšíření jeho uživatelské základny nebo uvažování o nových sadách funkcí. Někdy se v posledních sprintech odehrává stejně velké množství uživatelsky zaměřené projekční práce, jako u dřívějších, nebo tolik programování v prvních sprintech jako u těch druhých. Pokud se však tento ideál nedosáhne, tým se může stále co nejvíce přizpůsobit tím, že si navzájem pomáhají v souvislosti s momentálními potřebami, přičemž se každý člen může účastnit funkcí, které nejsou jejich obvyklou úlohou, je-li to nutné.

Měřte produktivitu hodnotou, nikoli objemem.

Protože produktivita je měřena kvalitou uživatelské zkušenosti, návrháři potřebují testovatelnou funkčnost a vývojáři musí najít způsob, jak tuto funkcionalitu dodat, aby ji mohli skuteční uživatelé zažít a ověřit co nejdříve v projektu. Návrháři musí před dodáním úplné funkčnosti otestovat a ověřit předpoklady.

Řada úskalí může vést ke špatně vedenému projektu HCD / Agile. Například vývojáři někdy nevyprodukují testovatelné funkce na začátku projektu - buď proto, že dávají technickým problémům a architektuře vyšší prioritu, nebo si prostě nedokážou představit, jak vyrobit časně testovatelné funkce. Tento problém představuje červená čára v grafu níže. Jedná se o zásadní chybu, protože návrhářům nedává nic, co by mohli vyzkoušet s uživateli. Zabraňuje opakování návrhu. Vývojáři odpovídají za to, že místo toho využijí veškerou svou kreativitu k vytvoření zelené linie. To poskytuje uživatelům vysokou hodnotu testovatelných funkcí co nejdříve.

Purpurová čára představuje vývoj vodopádu. Do konce projektu není získávána zpětná vazba od uživatelů. Purpurová linie nemusí úplně dosáhnout bodu „uvolnitelného produktu“, protože mnoho projektů Waterfall vůbec nic neuvolní. Poté, když je příliš pozdě, poznání skutečných potřeb uživatele se drasticky projeví, stejně jako chápání fyziky studentem prudce stoupá do 20 minut po závěrečné zkoušce.

Tým jako celek musí být připraven se naučit, že může být vyžadován posun od původního záměru a směrem k něčemu, co bylo zjištěno, že je ještě lepší.

Výše uvedený diagram umožňuje vypadat jako testovatelná funkčnost a moudrost se plynule zvyšuje ruku v ruce v čase. Obecně je to pravda, ale tým musí být připraven vykonat drastické problémy nebo neočekávané příležitosti. Například se tým může v polovině projektu dozvědět, že existuje mnohem úžasnější příležitost. Může vyžadovat odvahu rozpoznat a potvrdit takový výskyt, který nazýváme „transformační pivot“. Vyžaduje, abyste připustili, že velká část práce, kterou jste doposud udělali, je užitečná pouze při učení, že vaše aktuální cesta potřebuje opravu. Jedinou účinnou věcí je však okamžitě začít pracovat v nejlepším zájmu uživatele.

Sledováním výše uvedených doporučení a udržováním uživatelů na prvním místě mohou agilní týmy spolupracovat - dokonce i v obtížných vládních projektech - na úspěšném sloučení principů agilních metod a designu zaměřeného na člověka.

O společnosti AGL:

Agilní vládní vedení je skupina agilních profesionálů, kteří přinášejí vládní zkušenosti a perspektivy ze strany federálních, místních, státních a průmyslových. Můžete navštívit naše webové stránky, kde najdete bezplatné zdroje, zprávy, školení, případové studie a další: www.agilegovleaders.org