Poslovni analitik v agilnem svetu Prenova spletne strani Uvedba podpore za mobilne naprave Ineor d.o.o.
O meni poslovni analitik izkušnje s tehnologijo (programiranje, razhroščevanje, inštalacije, administracija,...) večinoma klasični waterfall projekti CBAP potrditev tega, kar znam in počnem zadnje leto delo na agilnih projektih
Projekt 1: Prenova prenova obstoječe spletne stran podpora za mobilne naprave Pomemben produkt, ki je eden glavnih virov prihodov za naročnika!
Cilji projekta nov izgled podpora za mobilne naprave (responsive design) orodje za dinamično upravljanje vsebin na straneh novo zaledje integracija z zunanjim CRM orodjem analitično spremljanje uporabe spletne strani SEO optimizacije nemoten prehod iz starih na nove strani (povezave!)
Ključni deležniki vodja projekta/produktni vodja na strani naročnika skrbniki za vsebine skrbniki za SEO in analitiko skrbniki za infrastrukturo razvojna ekipa za zaledni sistem razvojna ekipa za spletne strani (mi)
Ustroj projekta mednarodna ekipa (Avstrija, Malta, Slovenija) zastavljen agilno - scrum metodologija uporabniške zgodbe so bile napisane (Jira), usklajene z izgledom strani, zaledjem in potrjene model uporabniškega vmesnika je bil izdelan v obliki slik in tokov in je služil kot dopolnilo uporabniškim zgodbam razvoj je že bil v teku, ko sem se pridružil
Struktura uporabniške zgodbe kot uporabnik kriteriji sprejemljivosti (acceptance criteria) komentarji v sami zgodbi, podani tekom projekta, ki še podrobneje definirajo funkcionalnosti in pravila
Stanje scrum je ostal samo zastavljen, šprinti so ostajali odprti odvisnosti od ostalih elementov rešitve in ključnih vsebinskih strokovnjakov, ki niso bili vedno na voljo zaledje še ni bilo polno funkcionalno in stabilno odstopanje definiranih funkcionalnosti uporabniškega vmesnika (frontend) in nastajajoče funkcionalnosti zaledja (backend) klasični projektni konstrukt: kratki roki in pritiski za čimprejšnje dokončanje, ne glede na vse težave naša ekipa ni bila najbolj usklajena in homogena
Pristop prerez stanja (kje smo?) določitev prioritet (večji sklopi) ostale naloge - prioretizacija je arbitrarna - razporejanje nalog po principu, kdo je prost in po zahtevnosti uvedba tekočega razvojnega toka, brez motenj (v duhu kanbana) manjše stvari med večjimi sklopi za razbitje monotonosti in za hitrejši prikaz vmesnih rezultatov ultimativni cilj: nihče ni nezaseden v nobenem trenutku zahtevnost naloge prilagojena razvijalcu
Vodenje vodja projekta / produktni vodja s strani naročnika globalna slika, funkcionalnosti, rokovnik, eskalacije, usklajevanje z naše strani: tehnični vodja vsebinski vodja
Spremembe... tok novih zahtev je bil neusahljiv nekatere so bile samostojne in neodvisne veliko jih je obstoječ razvoj in že končano implementacijo vrnilo na začetek Primeri: Zahteva se je sklicevala na obstoječo funkcionalnost stare strani, ki ni bila 1:1 prenosljiva na novo stran Nekatere nove funkcionalnosti niso bile ustrezno opredeljene (samo okvirno) Veliko ad-hoc sprememb izgleda zaradi praktičnosti, spremembe v toku procesa, regulativnih spremembe tekom projekta, itd.
Upravljanje s spremembami #1 narava sprememb: ali so spremembe nujne? ali obstaja alternativna rešitev, ki je sprejemljiva do naslednje faze? ali je sprejemljivo podaljšanje roka zaradi spremembe? z rešitvami proti spremembam, ko naročnik še ne zna artikulirati zahteve predvidevanje rešitve že vnaprej pokrivanje potencialnih variant zahteve fleksibilna rešitev (parametrizirana)
Upravljanje s spremembami #2 ozaveščanje avtorjev zahtev, da se z njihovimi novimi zahtevami odmika tudi želeni rok za produkcijo spremembe zaledja/uporaba dodatnih zunanjih rešitev: sprotno odpravljanje neskladnosti zahtev in delovanja zaledja prikazovanje prirejenih rezultatov zaledja za namene vizualizacije, če zaledje še ni vračalo potrebnih podatkov postopno dodajanje zunanjih rešitev glede na pomembnost za produkt kot celoto ko so bile na voljo. sponzorji so bili sprotno obveščeni o zamudah in razlogih zanj
Prednosti Manj kontekstnega preskakovanja pri posameznikih -> privarčevan čas Manjko stresa zaradi lovljenja zastavljenega roka, še posebej zaradi vmesnih sprememb ali večje kompleksnosti, kot je bilo pričakovano Vsi smo bili enakomerno zasedeni, backlog ni bil omejen s šprintnim intervalom Fokus je na celovitem zaključku naloge in ne na lovljenju roka (kakovost vs. kvantiteta => v duhu pomembnosti produkta za naročnika)
Slabosti pri kompleksnejših sklopih rešitve trpi prenos znanja, posledično je težje zapolniti vrzeli, če nekdo odmanjka roki izvedbe so težje določljivi uporabniške zgodbe komentarji sčasoma postanejo obsežni in nepregledni ni vseh podrobnosti jih je potrebno reševati ad-hoc. Izvedljivo, če so ljudje ob danem trenutku na voljo za dodatne informacije / odločitve
Projekt 2: Mobilna verzija strani izgradnja spletne strani za mobilne naprave z enako funkcionalnostjo, kot jo že ima klasična spletna stran Produkt srednje prioritete Gre za širitev prodajnega kanala
Cilji projekta omogočiti uporabo spletne strani tudi na mobilnih napravah razširiti krog uporabnikov povečati promet
Ključni deležniki projektni vodja na strani naročnika/sponzor produktni vodja na strani naročnika razvojna ekipa za spletno stran projektni vodja poslovni analitik razvojniki testerji razvojna ekipa za zaledje
Ustroj projekta funkcionalnosti so bile znane s klasične strani dokumentacija obstoječih funkcionalnosti je bila pomanjkljiva ali pa je ni bilo design mobilnih strani je bil narejen 80% potrebno je bilo napisati uporabniške zgodbe predizvedbena faza bolj v duhu klasičnega projektnega pristopa - poslovna analiza pred izvedbo izvedba zastavljena agilno - scrum
Pristop #1 bolj podoben japonskemu industrijskemu kanbanu (specifikacija je ločena od izvedbe) => posledica lekcije enega prejšnjega projekta identifikacija vseh funkcionalnosti, potrebnih za izvedbo pred izvedbo: funkcionalnosti klasične strani funkcionalnosti strani za mobilne naprave gap analiza med obema specifične funkcionalnosti, ki so doma samo na mobilnih napravah
Pristop #2 zapis uporabniških zgodb. Struktura: koraki rezultat (uspešen, neuspešen) pravila variante dopolnitev manjkajočega design-a glede na klasično stran in našo oceno, kaj je za uporabnika najbolje pregled in potrditev uporabniških zgodb razdelitev uporabniških zgodb po šprintih pregled in potrditev uporabniških zgodb razdelitev uporabniških zgodb po šprintih
Pristop #3 občasno izpopolnjevanje uporabniških zgodb (fine tuning) sinhronizacija s 20% preostalega designa (in sprememb) pisanje testnih scenarijev in primerov na podlagi uporabniških zgodb
Spremembe po potrditvi strogo nadzorovane vsaka sprememba zahteva ponoven pregled in potrditev (ali zavrnitev) vendar (!) nove funkcionalnosti in spremembe obstoječih se odvijajo neprekinjeno naprej na klasični strani potrebna je sinhronizacija z mobilno stranjo proces še ni najbolje pokrit (in s tem kontroliran)
Prednosti uporabniške zgodbe so bile pisane tako, da so lahko ponovno uporabljive izredno malo neznank za izvedbo se lahko uporabi scrum znan je rok izvedbe posameznega šprinta in celote hitra izvedba
Slabosti neusklajevanje sprememb klasične strani z bodočo mobilno prehitra izvedba :)
Odprto več projektov v nadaljevanju, ki bodo še izpopolnjevali funkcionalnosti obeh strani kako ažurirati izhodiščne uporabniške zgodbe skupaj s pravili, da bodo vpleteni imeli uporabno referenčno dokumentacijo? uporabniške zgodbe ponovno uporabljive pri drugih produktih z enakimi funkcionalnostmi vzdrževanje le-teh Izboljšave
Lekcije agilni pristop z definicijami as-you-go ni najbolj primeren za tovrstne projekte razpoložljivost in dostopnost ključnih deležnikov ostaja ključ do hitrejše izvedbe sorodnost produktov kliče po strukturi definicij (uporabniških zgodb), ki so ponovno uporabljive pri več produktih in primerno vzdrževanje le-teh spletne strani: za vsako novo funkcionalnost ali element obvezno vprašanje: kako bo to izgledalo na vsaj 5-10 najbolj uporabljenih napravah (OS, resolucije, brskalniki, pokončni/ležeči način) kakovostna in uigrana ekipa je ključnega pomena!
Debata!