DevOps je pogosto opredeljen kot procesi, operacije, metodologije, orodja in kultura, ki obkrožajo razvoj programske opreme in sistemov podjetja.

Toda inženiring ne deluje v vakuumu. Načrti, ideje, modeli in koncepti prihajajo od strokovnjakov za oblikovanje izdelkov, ki se odločajo za postavitve, tokove in interaktivnost. To so neinženirski posamezniki in ekipe, ki si delijo cilje in želene rezultate DevOpsa.

DevOps je približno toliko več od tega, kako se razvijalci povezujejo z IT, kako se upravlja infrastruktura in kako je mogoče izboljšati okvire. Gre za prepoznavanje, koliko ekip je resnično vključenih v proces razvoja programske opreme, kako prepletene so njihove vloge in delo, ter za iskanje boljših načinov, kako zagotoviti, da so vsi za mizo.

Razvijalci in inženirski arhitekti želijo sodelovati, ko produkt in kreativne skupine oblikujejo programsko opremo ali sistem. Kje pa je to v trenutni definiciji DevOps? Skupine za izdelke, uporabniške izkušnje in ustvarjalce želijo ostati vključene v inženirske procese, vendar jih toliko metodologij izključuje. To so stari silosi, ki jih moramo razbiti.

Vaše stranke vidijo samo vašo uporabniško izkušnjo (UX). Ne vidijo, koliko razvijalcev ste imeli, ali če ste bili okretni ali vitki. Pojma nimajo, katera orodja DevOps se uporabljajo. UX vašega podjetja je izdelek in vas lahko naredi ali zlomi. Sprašujejo se, kdo je zgradil ta kos smeti. Ali boste s toliko konkurence in ljudmi, ki bodo z veseljem odstranili aplikacijo ali zapustili spletno mesto, dobili drugo priložnost s stranko, ki vas je zapustila?

Agile redko trenira na UX ali dela s strokovnjaki za UX

Številnim inženirskim skupinam se pogosto zdi, da je UX zasenčen in da je z njim težko sodelovati. UX ni videti vitko in številni okusi Agile izključujejo podrobnosti o tem, kako delati z UX. Nekateri pristopi Agile izrecno nakazujejo, da je lastnik izdelka, ki opisuje funkcijo, »dovolj dober«.

SAFe Agile se zmoti in se odloči, da je najboljši način za reševanje silosiranja UX njihova popolna izključitev. SAFe 'pooblašča agilne ekipe', da naredijo svoj 'Lean UX'. Kot več podjetij razume vrednost vključevanja UX strokovnjaki in celoten postopek UX, SAFe gre v napačno smer.

Odsotnost razlage UX-a in njihovih postopkov pri usposabljanju in knjigah Agile je vodila ekipe po vsem svetu, da izključijo ali zmanjšajo sodelovanje specializiranih oblikovalcev izdelkov.

• Ko si napačno predstavljate, da UX samo riše polja na straneh, lahko preprosto domnevate, da lahko to delo opravim. Tako kot mnogi avdicijci American Idol so prepričani, da so najboljši pevec na planetu vodje izdelkov in inženirji samo ocenjujejo, da so pri UX odlični. To običajno pomeni, da verjamejo, da so odlični pri postavljanju zaslonov. Toda, ko ta članek pojasnjuje, kaj v resnici gre za delo UX, boste videli, kako strokovnjak za UX razvijalca, ki izdeluje žične okvirje, ne bi videl kot nekoga, ki bi mu morali dodeliti naloge UX.
• Knjige o Scrumu predlagajo, naj v primeru, da bo strokovnjak za UX ozko grlo, za izvajanje svojega dela usposobi vloge, ki niso UX. Tovrstne odločitve se redko predlagajo glede drugih vlog pri razvoju programske opreme; nihče ne bi želel, da kodiranje izvede neizšolan ali neizkušen razvijalec, tudi po bootcampu ali branju knjige o programiranju. Nikoli ne bi predlagali, da mora razvijalec, če postane ozko grlo, usposobiti vodjo projekta za nekaj kodiranja.
• Najem menedžerjev, ki napačno menijo, da je UX umetniško delo (UI), najemajo umetnike, ki opravljajo UX delo. Med stopnjami UX in UI ni izobraževalnega prekrivanja. Naravni talenti se pogosto ne prekrivajo; nekdo velik v UX je lahko slab umetnik in obratno. Najem za »UX / UI« vam pogosto prinese odličnega umetnika z minimalno uporabniško izkušnjo, strokovnim znanjem, postopkom ali izobrazbo.

Tisti, ki gledajo zgolj na dno, bi radi zmanjšali proračun tako, da bi UX naloge dajali posameznikom, ki jim morda primanjkuje izobrazbe, izkušenj, znanja, spretnosti ali naravnih talentov. Toda to je kratkovidno in lahko privede do slabe produktivnosti, učinkovitosti, kulture, izdelkov in zadovoljstva kupcev.

Konec leta 2018 je podjetje za poslovno svetovanje McKinsey & Company objavilo „ Poslovna vrednost oblikovanja , «Poročilo o raziskavah, ki so jih opravili z več kot 300 podjetji.

Ugotovili so, da 'je dizajn edini način, da lahko podjetja izstopajo iz množice.' Kaj imajo tekmovalci tesne sklope funkcij, kaj jih ločuje? Oblikovanje je včasih mišljeno le kot estetika ali tisto, zaradi česar je to videti kot naša blagovna znamka. Toda če se uporablja skupaj z »UX«, pomeni arhitekturo funkcij in odločitve o zaslonih, korakih, pretokih, postavitvah, procesih, organizaciji in menijih.

UX je del nenehnega izboljševanja, ki si vedno prizadeva za boljše razumevanje uporabnikov ter izbiro in oblikovanje funkcij in izdelkov, ki najbolj ustrezajo njihovim potrebam, reševanje njihovih bolečih točk in jim prinaša pomembne inovacije.

McKinsey je tudi poročal, da 'morajo podjetja oblikovanje sprejemati celostno in zgodaj v procesu, namesto da bi ga razumeli kot majhno orodje, ki se kasneje prilega.' Skupine, ki domnevajo, da je pozornost do uporabniške izkušnje nekaj, kar je mogoče po izdaji izdelka zmanjšati, izključiti ali narediti, sprejemajo napačen pristop.

McKinsey je zbral kvantitativne podatke in ugotovil, da so podjetja, ki so sprejela oblikovanje UX, v petletnem obdobju ustvarila 32% več prihodkov in 56% več donosov delničarjev. Razglasitev vašega podjetja za 'uporabniško usmerjeno' ni dovolj. Sprehoditi se morate tako, da vključite izvajalce in procese UX od načrtovanja in portfelja do razvoja in zagotavljanja kakovosti.

Procesi za razvoj programske opreme z UX in brez njega

Če vaše podjetje v postopek načrtovanja in razvoja programske opreme ne vključuje strokovnjakov za UX, je vaš postopek najverjetneje videti na spodnji sliki.

Proces oblikovanja in razvoja programske opreme brez strokovnjakov za UX.

Stranka, vodja izdelkov, izvršni direktor ali nekdo z vizijo pove inženiringu, kaj želi. Inženirstvo ga zgradi, preizkusi in prenese na uprizoritveni ali produkcijski strežnik. Oseba z vizijo jo potem vidi in, ne bi vedeli, ni srečna. Želijo si nekaj drugačnega ali so si premislili.

Nato se mora inženirstvo vrniti na začetek, ugotoviti, kaj ta oseba zdaj želi, zgraditi, preizkusiti in prekrižati prste, da je to čar.

Proces oblikovanja in razvoja programske opreme z vključenim UX.

Če imate v ekipi strokovnjake za UX, je postopek povsem drugačen. Ta oseba z vizijo pride na UX z idejami, podatki in točkami za bolečino strank. UX skozi naloge kroži skozi naloge, usmerjene v uporabnika, in nato te koncepte preizkusi, preden inženiring napiše vrstico kode. To zagotavlja, da je izdelek ali funkcija, ki jo razmišljamo o izdelavi, prava izvedba prave ideje za naše ciljne stranke.

Testiranje lahko razkrije nekaj napak, kar UX-u omogoča ponovitev in pogosto ponovno testiranje. Po postopku UX imate na voljo popolnoma preverjen dizajn, pripravljen za inženiring.

Če si nekdo na poti premisli, se ta pogovori z UX, namesto da bi ga dal kot zahtevo za spremembo razvijalcem. UX med svojim postopkom izvaja interference in nič ne pošlje inženiringu, ne da bi UX sodeloval pri načrtovanju, odločanju in testiranju na resničnih ali arhetipskih kupcih.

Spremembe misli v tem trenutku niso katastrofe, saj so stroški, da si nekdo premisli, v tem trenutku minimalni. Projektom niso bili predloženi načrti, niso se začeli in nimajo kaj obnoviti. UX ponavlja svoje zasnove in lahko preizkusi uporabnike, da zagotovi, da se ideje dobro in močno ujemajo z bazo strank. Spremembe časa zgorevanja misli, vendar je splošni vpliv na proračun majhen.

UX ima formalni postopek

Uporabniško usmerjeno načrtovanje (UCD) je formaliziran postopek, ki vključuje naloge, ki strokovnjake za UX usmerjajo k raziskovanju, oblikovanju, prototipu, testiranju na resničnih ali arhetipskih uporabnikih in nato ponovitev na podlagi spoznanj iz testiranja.

Najprej se osredotočimo na nekaj teh področij zahteve in zgodnje razprave o lastnostih in projektih. Ko UX prvič dobi zahteve in druge informacije o projektu, je pomembno, da začnete sodelovati takoj. UX NE sme pozneje izvedeti, da so zasnovali nekaj, česar ni mogoče zgraditi.

Začnite tako, da pripeljete delavce ali menedžerje UX, ko se vodje izdelkov ali projektov odločajo o lastnostih in določanju prednostnih nalog. Projekt, ki za uporabnika nima nobene vrednosti, je mogoče odstraniti, s čimer prihranite neizmeren čas in denar. Tukaj pride v poštev čim večja količina nedokončanega dela. Izdelki in inženiring bi morali podpirati UX, kadar ustvarijo manj dela za Engineering, tako da zmanjšajo ali odstranijo funkcije ali celotne projekte. Vendar pa imajo projekti prepogosto ego in soigralci pogosto izključijo UX iz teh zgodnjih pogovorov, tako da se projekt financira.

Raziskave je pomemben del tega, kar počne UX. Brez vključevanja uporabnikov ni usmerjen na uporabnika. Statistični podatki in kvantitativni podatki so odlični, vendar ne moremo nadomestiti anketiranja uporabnikov, njihovega globokega razumevanja in pridobivanja kvalitativnih podatkov. UX želi vedeti, zakaj in ne samo kaj.

Raziskave UX usmerjajo tudi soigralce na isto stran z združevanjem vseh okoli oseb, arhetipov ciljnih kupcev. Na podlagi razgovorov z uporabniki združimo to, kar se naučimo, in vse zberemo na 6 ali manj oseb. Kaj jih motivira? Kaj naj rabijo? Kje so priložnosti za naše podjetje, izdelek ali storitev?

Najboljša uporaba oseb bi bila, če bi jih vključili povsod. Izdelek predstavlja funkcije, ki temeljijo na osebnostih (in dobrih podatkih). UX modeli temeljijo na osebnostih. Preizkusi kakovosti, medtem ko si predstavljajo, da so te osebe. Trženje lahko doda njihove demografske in druge podrobnosti, vendar bi tudi oni morali razmisliti, kako glas blagovne znamke, družbeni mediji in oglaševanje govorijo osebam.

Persone pomagajo delavcem, ki niso člani UX, da se rešijo: 'No, tako mi je všeč' ali 'Generalnemu direktorju je to všeč.' Načrtujemo za te ciljne kupce in če vi ali izvršni direktor ne ustrezate osebnostim, potem UX ne vpliva na ego ali osebne želje. UX mora ostati osredotočen na kupca.

Informacijska arhitektura je povezan s hierarhijami, strukturo in taksonomijami. To je lahko navigacija po spletnem mestu ali pa način kategorizacije izdelkov v zbirki podatkov e-trgovine. Želimo zagotoviti, da bodo kupci zlahka našli izdelke po kategorijah, metapodatkih in filtrih.

Oblika interakcije , včasih imenovano tudi oblikovanje izkušenj, je tisto, na kar večina ljudi pomisli, ko si predstavlja UX. To so žični okvirji in prototipi, načrti načrtov in konceptov. Ti bi prikazali tokove procesov, postavitve, menije, interakcije, poti, izbire in še veliko več.

Prototipi UX so kot ožičeni okvirji. So interaktivni digitalni vzorci, ki jih je mogoče klikniti. Ni nam treba pisati kode; imamo programsko opremo, ki nam pomaga, da jih hitro ustvarimo. Podjetja, ki iščejo bolj realistične prototipe, uporabljajo Axure, saj ima pogojno logiko, spremenljivke, mobilne poteze s povlečenjem, vlečenjem in spuščanjem ter vse vrste sprožilcev dogodkov. Lahko izdelate prototip za skoraj vse vrste naprav.

Prototip UX se izvaja za:

• Možganska nevihta
• Sodelujte
• Ponovno
• Raziščite rešitve
• Predlagaj vlagateljem (za zagonska podjetja)
• Preizkusite prototip, da preverite, ali se rešitev dobro poveže s ciljno skupino.
• Ponudite interaktivni model razvijalcem ali drugim soigralcem, ki je pogosto boljši od strani dokumentacije (in brez modela, ki ga je mogoče klikniti).

Zdaj gre za uporabniško testiranje , imenovano tudi testiranje uporabnosti, ki se zgodi med postopkom UX in preden inženiring napiše vrstico kode. Preizkusiti morate koncepte in zasnove, da se prepričate, da sta ideja in izvedba fantastična za ciljne stranke.

Uporabniško testiranje bo razkrilo vse pomanjkljivosti in dalo UX-u možnost ponovitve idej, kar je trenutno poceni, saj za inženiring ni treba graditi ali obnavljati ničesar.

Obstaja 5 ključnih razlogov, da UX izvaja teste pred dostavo v inženiring:

1. Najboljša uporaba časa in virov inženiringa. Če želite, da udeleženci testiranja vidijo končni izdelek, ki so ga ustvarili inženirji, ga morate zgraditi in preizkusiti na napake. Če testiranje UX prinese potrebne spremembe, bi morali razvijalci znova zgraditi in QA ponovno preizkusiti. Če bi testiranje UX pokazalo večji neuspeh koncepta, bi to lahko pomenilo, da je bil čas inženiringa popolnoma zapravljen, saj to ni koda, ki bo končala kjer koli. Koncept bi bilo treba premisliti, preoblikovati in sveže preizkusiti.
2. Ponavljajte se v zakulisju. Ko ga podjetja samo izdelujejo, samo pošiljajo, ponovijo in znova gradijo in pošiljajo, to pomeni, da stranke vidijo različne različice. Ogledajo si delo, ki poteka, in opazujejo, kako izdelujejo klobase. To je pogosto frustrirajoča in zmedena izkušnja, ki zahteva, da stranke nenehno preučujejo sistem, ki se razvija. Bolje je, da v postopku UX ponovite zakulisje in s testerji jasno, da gre za prototip ali predstavitveno različico.
3. Spremljanje in merjenje. Če je nov koncept objavljen v živo, raziskovalci UX nimajo dobrega načina, da bi ga ljudje gledali, ga spraševali in dobili vrsto povratnih informacij, ki jih mora uporabnik UX ugotoviti, ali je nekaj pripravljeno ali potrebuje še eno ponovitev. UX vedno želi vedeti, zakaj, kvalitativno in ne samo kaj ali koliko. Kako uporabniki porabljajo, pretvarjajo, vključujejo itd.? Izogibanje pravilnemu testiranju UX otežuje diagnosticiranje in odpravljanje težav ali bolečih točk strank.
4. UX testiranje se obrestuje. UX testiranje ni velik strošek. Nekatera neodvisna orodja za testiranje zahtevajo manj kot 100 USD na udeleženca testiranja, nekatera zahtevajo najmanj letno obveznost v višini tisoč dolarjev. Glede na celoten proračun podjetja za postopek razvoja programske opreme in pomembnost povratnih informacij o zgodnjem testiranju to niso veliki stroški. Krogi uporabniškega testiranja skoraj vedno stanejo manj in se premikajo hitreje, kot da programerji gradijo nekaj, kar bomo morda morali razveljaviti ali znova zgraditi.
5. Uporabniško testiranje rešuje argumente. Če vaše podjetje strokovnjakom za UX ne dovoli, da sprejmejo končno odločitev o tem, kako je zasnovan izdelek, boste morda ugotovili, da je UX v navzkrižju z izdelkom, inženiringom ali deležnikom, če obstajajo različne ideje o tem, kaj bi bilo treba zgraditi in spustiti stranko. Ali kaj, če ima UX dve močni ideji in se sprašujeta, katera je boljša povezava s strankami? Rešitev tukaj je testiranje uporabnikov.

UX lahko prototipira koncepte. Najbolje je, da konkurenco zvedete na najboljši dve zasnovi, še posebej, če že najdete kompromise med idejami in člani ekipe. To pomeni, da ne preizkušamo, kaj želi UX v primerjavi s tem, kaj je všeč izdelkom, v primerjavi s tem, kar je všeč vodji inženiringa, v primerjavi s tem, kar misli mojster scrum-a, kot dobra ideja v primerjavi s tem, kaj je všeč življenjskemu partnerju direktorja.

Uporabniško testiranje omogoča strankam, da spregovorijo in vam pomaga najti pravo smer za funkcije ali izdelek. Argumente reši tako, da ekipam zagotovi trde kvantitativne in kvalitativne podatke, ki vsem povedo, katera ideja bo verjetno prinesla največ zadovoljstva strank.

Zasnova ni usmerjena na uporabnika, ne da bi ga vključili. To pomeni, da raje raziskujemo in preizkušamo z resničnimi ali arhetipskimi strankami, ne pa da ugibamo, domnevamo ali 'samo pošiljamo'. Zagotoviti moramo, da je bilo to, kar smo 'samo poslali', preverjeno s pomočjo uporabniškega testiranja in je odlična izvedba odlične ideje.

Kaj se zgodi, ko je UX zaobljen ali zmanjšan?

Skype je pred kratkim napovedal, da je njegova prenova leta 2017, katere namen je bil bolj podoben Snapchatu, neuspešna. Uporabniki niso želeli, potrebovali ali všečkali novih funkcij. Odziv je bil dovolj velik, da je Skype leta 2018 sporočil, da bodo Skype ponovno preoblikovali. ( https://devops.icu/skypes-coming-redesign-of-their-last-redesign/ )

Skypeova prenova 2017

Strokovnjaki za UX bi že v mnogih korakih vedeli, da so te funkcije verjetno nezaželene ali ne. Raziskave s ciljnimi uporabniki bi lahko hitro pokazale, da ne želijo, da Skype postane Snapchat. Ubijanje projekta ali vrtenje v tej zgodnji točki bi lahko Skypeu prihranilo milijone dolarjev ter slabo tiskanje in odtujenost strank.

Tudi če bi raziskavo UX zaobšli, bi testiranje prototipa UX na uporabnikih jasno pokazalo, da stranke ne želijo, da bi Skype šel v to smer. Ker se UX še vedno premika skozi svoj postopek, inženiring še ni napisal vrstice kode. To bi lahko prihranilo ogromno časa, denarja in človeških virov, proslavilo preprostost in delovnega inženiringa ni bilo treba opraviti.

Agilen UX postopek

Ne pozabite na načela agilnega manifesta. Vaša najvišja prioriteta je zadovoljstvo strank z izdelavo dragocene programske opreme. Dajte (UX) delavcem okolje in podporo, ki jo potrebujejo, zaupajte jim, da bodo delo opravili. Povečajte obseg dela ne Končano. Nenehna pozornost do dobrega dizajna povečuje okretnost.

Projekti, ki se premikajo naprej, morajo UX dobiti ogromno vzletno-pristajalno stezo, da se lahko začnejo ustrezne raziskave, načrtovanje in testiranje. Ne vabite UX-a na svoj začetni sestanek in jih presenetite z zahtevo, da je treba končne žične okvire dostaviti v nekaj dneh. To ni UX.

Ne glejte na to kot na Big Design Up Front (BDUF), kar je izraz, s katerim se bodo ljudje stiskali in izjavili, da je to nekaj, od česar moramo pobegniti. Kadar je projekt ali funkcija velika ali nova, mora UX krožiti skozi večino, če ne celo vse, na uporabnika osredotočenega postopka oblikovanja. Za UX je najmanjši možni del večje funkcije uporabnikov potek dela ali postopek. Če načrtujemo in preizkusimo kaj manjšega, tvegamo, da ne bomo dobili velike slike prave uporabniške izkušnje.

Če na primer načrtujemo tok, kjer se uporabniki registrirajo in kupujejo, ne moremo samo oblikovati polj za izbiro gesla in jih predati inženiringu. Če bi UX deloval v majhnih kosih, kdaj bi bil preizkušen celoten postopek? Ne moremo vedeti uporabnikove reakcije na celoten tok, ne da bi preizkusili celoten tok… kar pomeni, da mora biti celoten tok zasnovan, preden gre na testiranje uporabnosti.

Kjer so funkcije, zgodbe ali popravki majhni, lahko izvajalci UX izvedejo del uporabniško usmerjenega postopka oblikovanja in hitreje delajo. UX bo vedno šel čim hitreje, toda odličen strokovnjak za UX bo naredil vse, da se izogne ​​žrtvovanju kakovosti opravljenega dela. V hitri in dobri bitki bo UX vedno izbral dobro kot hitro ... in tudi vi bi morali.

Proračuni in roki so tisto, kar UX-u preprečuje hitre povratne informacije in ponavljanje. Izvajalci UX vedno želijo povratne informacije in priložnost za izboljšanje izdelka, da bi oblikovali tisto, kar resnično deluje za stranke. Vključitev uporabnikov UX že pri upravljanju in načrtovanju portfelja omogoča UX, da oceni čas in proračun, ki jih bodo potrebovali; to pozneje ne bi smelo biti presenečenje ali vzrok za konflikt.

UX praktik je del agilne ekipe

Vdelajte svojega UX Designerja v ekipo Agile. Povabite jih, naj sprostijo načrtovanje, stand-up, retro in vsak sestanek, na katerem bi lahko razpravljali o UX. Dovolite UX-u, da oceni svoj čas med načrtovanjem izdaje, tako da ne bo presenečenj glede potrebnih časovnih opravil UX. Ne odločajte se brez njih. Če je vaš soigralec UX zamudil sestanek, počakajte, da jih najdete osebno, prek klepeta, e-pošte ali katerega koli drugega načina, ki ga uporablja vaše podjetje.

Dodelite vprašanja, nejasnosti ali napake svojemu soigralcu UX v sistemu JIRA ali katerem koli drugem sistemu za sledenje napakam, ki ga uporabljate. Prepričajte se, da so težave z UX v istem sistemu kot druge izdaje; ne puščajte težav z UX na plošči Trello, če za vse drugo uporabljate VersionOne.

Če je bila UX dolga vzletno-pristajalna steza, če je bila potrebna za to funkcijo ali izdelek, je najboljša praksa, da je UX 2 ali več Sprintov pred inženiringom. UX lahko sprinta skupaj z vami. Pridobite veliko tehnoloških zgodb ali popravite tehnološki dolg. Če so ustvarjalni in ciklični postopki UX-a pozni ali zahtevajo več sprintov, so lahko razvijalci zares gibčni. Namesto da čakajo na UX, lahko preidejo na nekakšno slabo obesno sadje, ki mu je izdelek ali inženiring dal prednost.

Razmislite tudi o financiranju, dodeljevanju in zaposlovanju. Odvisno od velikosti projekta enemu UX oblikovalcu dodelite največ 3 projekte. Če imate ločene strokovne raziskovalce UX, ki opravljajo tudi testiranja in analize, dodelite enega raziskovalca največ 3 UX oblikovalcem. Če je vaš izvajalec UX tisto, kar imenujemo T-oblika, kar pomeni, da je tudi usposobljena in odlična na področju raziskav, preizkušanja in drugih pod-posebnosti UX, potem poskrbite, da ne bo slučajno ozko grlo, ker bo dodeljena preveč projektom.

Merjenje rezultatov

Brez zadovoljstva strank morda ne bi imeli kupcev. Z meritvami zadovoljstva kupcev lahko ugotovite, kako je izboljšanje vaših procesov z integracijo UX pozitivno spremenilo.

• Manj pritožb
• Boljše ocene aplikacij
• Višje ocene aplikacij
• Manj vstopnic za podporo
• Manj klicev v klicni center
• Bolj pozitivna semantika socialnih objav
• Več namestitev aplikacij, manj odstranitev
• Povišanje AOV (povprečna vrednost naročila)
• Višja stopnja pretvorbe

Cilji in rezultati programa DevOps so merljivi.

Izmerite lahko tudi želene cilje DevOps, na primer čas do prodaje in čas med popravki. Kako dolgo trajajo zgodbe, projekti in epi, da pridejo na trg pred in po vaši revoluciji UX? Ocene časa razvijalcev bodo verjetno bolj natančne, ko bodo dokončali modele UX, na katerih bodo temeljile njihove ocene v primerjavi z zgodbami ali karkoli že počnete zdaj.

Če UX ponuja načrte in se jim sledi, upamo, da bo inženiring imel manj dela z zmanjšanjem presenetljivih sprememb in ponovne gradnje. Boljša zasnova UX prej, manj popravkov kasneje.

Agile UX je naložba, ki več kot plača sama

Številni vodje projektov vidijo UX kot proračunsko vrstico, ki jo je mogoče odstraniti ali zmanjšati, zato se vodje zaposlovanja navdušijo nad idejo, da naloge UX kombinirajo z drugo vlogo. Vse več podjetij pa se uči, da ni nadomestila za vlaganje v pravi UX postopek, ki ga izvajajo usposobljeni in izkušeni UX strokovnjaki.

Eric Ries, avtor knjige Vitki zagon , vpraša: 'Kaj pa, če bi se znašli pri gradnji nečesa, česar nihče ni hotel? V tem primeru je bilo vseeno, če smo to storili pravočasno in po proračunu? « Tudi če vaša organizacija ne uporablja metodologije Lean, opozorilo še vedno velja. Želeni rezultati DevOps odmevajo, ko želimo ustvariti pravo stvar za kupca, izboljšati zadovoljstvo strank in razviti funkcije z visoko vrednostjo za kupca.

Poznavanje stranke, vključevanje stranke v postopek in oblikovanje njenih resničnih potreb in želja je na koncu pomembnejše od časovnih rokov, proračunov, okvirov in orodij. Zaupajte, da če boste ustvarili prave izvedbe pravih idej, bo prihodek tam.

Razumevanje osnov

Kaj sta zasnova UX in UI?

UX zasnova je postopek, s katerim se procesni postopek in izvedba funkcije ali izdelka konceptualizira, oblikuje in postavi. Poudarek je na enostavnosti učenja in uporabe, obravnavanju potreb strank in dostopnosti. Uporabniški vmesnik se osredotoča na vizualno oblikovanje, blagovno znamko, tipografijo, ikone in drugo estetiko.

Kaj je Agile UX?

Agile UX združuje razvoj programske opreme Agile skupaj z izdelkom in zasnovo interakcij, ki so jo izvedli strokovnjaki za UX. V ekipo Agile vključuje strokovnjaka za UX in zahteva razumevanje in vrednotenje vloge UX. To pomeni dodelitev časa in proračuna za celoten postopek UX, vključno z raziskavami in testiranjem.

Kaj je Lean UX?

Lean UX uporablja hitre cikle izdelave, merjenja in učenja, da se ponovi na zasnove izdelkov. Lean UX poudarja potrebo po raziskavah, preizkušanju in sodelovanju v procesu razvoja programske opreme, namenjene izdaji MVP, najmanj izvedljivega izdelka. Izdelek z manj funkcijami je mogoče uporabiti hitreje.

Lean UX vs Agile UX: Kakšna je razlika?

Lean in Agile sta namenjena hitrim razvojnim ciklom, ki bodo ustvarili najboljši izdelek za potrebe kupca. Medtem ko se morajo izvajalci UX lotevati vsakega nekoliko drugače, oba zahtevata, da UX gradi, testira in se uči s hitrimi povratnimi informacijami in ponovitvami za potrditev izdelka, preden začne inženiring kodirati.

Kaj je Agile release train?

Agile release train (ART) je večfunkcionalna skupina skupin, namenjenih ustvarjanju rešitev, ki koristijo končnim uporabnikom. Vlak ciklira z opredelitvijo funkcionalnosti, implementacije, uvajanja in sprostitve za zagotavljanje rešitev. ART je konstrukt SAFe Agile podjetja Scaled Agile Framework Inc.