napomena
Knjiga je narirani algoritam za provođenje procesa razvoja od ideje do implementacije koristeći agilne tehnike. Proces je prikazan u koracima i na svakom koraku su naznačene metode za korak procesa. Autor ističe da većina metoda nije originalna, a da ne tvrdi da je originalna. Ali dobar stil pisanja i određeni integritet procesa čine knjigu veoma korisnom.
Ključna tehnika mapiranja korisničkih priča je strukturiranje ideja i performansi dok se korisnik kreće kroz proces.
Istovremeno, proces se može opisati na različite načine. Možete graditi korake dok postignete ključnu vrijednost ili možete jednostavno uzeti i zamisliti radni dan korisnika kako prolazi kroz sistem. Autor se fokusira na činjenicu da procese treba ocrtati, izgovoriti u obliku korisničke priče na mapi procesa, što nam je dalo naziv mapa priča korisnika.
Kome treba
Za IT analitičare i projekt menadžere. Obavezno pročitati. Laka i prijatna za čitanje, knjiga je srednje veličine.
Povratna informacija
U svom najjednostavnijem obliku, ovako funkcionira.
Posjetilac dolazi u kafić, bira jela, naručuje, prima hranu, jede i plaća.
Možemo napisati zahtjeve za ono što želimo od sistema u svakoj fazi.
Sistem treba da prikaže listu jela, svako jelo ima sastav, težinu i cenu i može se dodati u korpu. Zašto smo sigurni u ove zahtjeve? Ovo nije opisano u “standardnom” opisu zahtjeva i to stvara rizike.
Izvođači koji ne razumiju zašto je to potrebno obično rade pogrešnu stvar. Izvođači koji nisu uključeni u proces kreiranja ideje nisu uključeni u rezultat. Agile kaže, fokusirajmo se prvenstveno ne na sistem, već na ljude, na potrošače, njihove zadatke i ciljeve.
Kreiramo persone, dajemo im detalje za empatiju i počinjemo pričati priče sa strane ličnosti.
Zaposlenik ureda Zakhar otišao je na ručak i želi na brzinu da nešto ugrize. Šta mu treba? Ideja je da vjerovatno želi poslovni ručak. Druga ideja je da želi da sistem zapamti njegove preferencije, jer je na dijeti. Druga ideja. Želi da mu odmah donesu kafu jer je navikao da pije kafu pre ručka.
A tu je i biznis (organizacioni karakter je karakter koji zastupa interese organizacije). Preduzeća žele povećati prosječan ček, povećati učestalost kupovine i povećati profit. Ideja je - ponudimo neobična jela neke kuhinje. Još jedna ideja - hajde da predstavimo doručak.
Ideje se mogu i trebaju konkretizirati, transformirati i prezentirati u obliku korisničke priče. Kao zaposlenik Poslovnog centra Zakhar, želim da me sistem prepozna kako bih mogao dobiti meni na osnovu mojih preferencija. Kao konobar, želim da me sistem obavijesti kada da priđem stolu kako bi klijent bio zadovoljan brzom uslugom. I tako dalje.
Desetine priča. Sljedeće je određivanje prioriteta i zaostatak? Jeff ukazuje na probleme koji se javljaju: zaglavljivanje u malim detaljima i gubljenje konceptualnog razumijevanja, plus davanje prioriteta funkcionalnosti stvara izoštrenu sliku zbog nedosljednosti s ciljevima.
Put autora: Prioritet ne postavljamo funkcionalnosti, već rezultat = ono što korisnik na kraju dobije.
Očigledna neočigledna stvar: sesiju određivanja prioriteta ne provodi cijeli tim, jer je neefikasna, već troje ljudi. Prvi je odgovoran za poslovanje, drugi za korisničko iskustvo, a treći za implementaciju.
Odaberimo minimum za rješavanje jednog korisničkog problema (minimalno održivo rješenje).
Ideje prvog prioriteta detaljno opisujemo koristeći korisničke priče, skice dizajna, ograničenja i poslovna pravila na karti korisničkih priča govoreći i razgovarajući s timom šta je ljudima i dionicima potrebno u svakom koraku procesa. Preostale ideje ostavljamo neispitanim u zaostatku mogućnosti.
Proces je napisan na karticama s lijeva na desno, sa idejama na karticama ispod koraka procesa. Imperativ je da se o putu kroz cijelu priču razgovara zajedno sa članovima tima kako bi se osiguralo međusobno razumijevanje.
Razrada na ovaj način stvara integritet u skladu sa procesima.
Primljene ideje treba testirati. Nečlan tima stavlja šešir osobi i živi dan te osobe u njenoj glavi, rješavajući njen problem. Moguće je da on ne vidi razvoj događaja, ponovo stvara karte, a tim otkriva alternative za sebe.
Zatim slijede detalji za evaluaciju. Za ovo su dovoljne tri osobe. Odgovoran za korisničko iskustvo, programer, tester sa omiljenim pitanjem: “Šta ako...”.
U svakoj fazi, diskusija prati mapu procesa istorije korisnika, koja omogućava da se korisnikov zadatak ima na umu kako bi se stvorilo koherentno razumijevanje.
Da li je po mišljenju autora dokumentacija neophodna? Da, treba mi. Ali kao bilješke koje vam omogućavaju da zapamtite ono o čemu ste se dogovorili. Ponovno uključivanje autsajdera zahtijeva diskusiju.
Autor se ne bavi temom dovoljnosti dokumentacije, fokusirajući se na potrebu rasprave. (Da, dokumentacija je potrebna, ma kako to tvrdili ljudi koji nemaju duboko razumijevanje agilnosti). Takođe, razrada samo dijela mogućnosti može dovesti do potrebe za kompletnom preradom cijelog sistema. Autor ukazuje na rizik od preterane razrade u slučaju kada je ideja pogrešna.
Kako bi se eliminirali rizici, potrebno je brzo dobiti povratnu informaciju o proizvodu koji se kreira kako bi se minimizirala šteta od stvaranja „pogrešnog“ proizvoda. Napravili smo skicu ideje - potvrdili je sa korisnikom, skicirali prototipove interfejsa - potvrdili je sa korisnikom itd. (Odvojeno, postoji malo informacija o tome kako provjeriti prototipove programa). Ciljevi kreiranja softvera, posebno u početnoj fazi, su učenje kroz dobijanje brze povratne informacije, shodno tome, prvi kreirani proizvod su skice koje mogu dokazati ili opovrgnuti hipotezu. (Autor se oslanja na rad Erica Riesa “Startup koristeći Lean metodologiju”).
Mapa priče pomaže u poboljšanju komunikacije kada se implementacija provodi u više timova. Šta bi trebalo biti na mapi? Šta vam je potrebno da nastavite razgovor. Ne samo korisnička priča (ko, šta, zašto), već ideje, činjenice, skice interfejsa, itd...
Podjelom karata na karti historije u nekoliko horizontalnih linija, možete podijeliti rad na izdanja - istaknite goli minimum, sloj sve veće funkcionalnosti i lukove.
Pričamo priče na mapi procesa.
Došao je zaposlenik na ručak.
šta on hoće? Servisne brzine. Tako da ga ručak već čeka na stolu ili barem na poslužavniku. Ups - promašen korak: zaposlenik je htio jesti. Prijavio se i odabrao opciju poslovnog ručka. Vidio je sadržaj kalorija i nutritivne vrijednosti kako bi mu pomogao da se drži prehrane i ne dobije na težini. Vidio je slike jela da bi odlučio da li će jesti na tom mjestu ili ne.
Dalje, hoće li otići po ručak i večeru? Ili će možda ručak biti dostavljen u njegovu kancelariju? Zatim korak procesa je odabir mjesta za jelo. Želi da vidi kada će mu biti isporučeno i koliko će koštati, kako bi mogao da bira gde će potrošiti svoje vreme i energiju - sići dole ili na posao. Želi da vidi koliko je kafić zauzet da se ne bi gurao u redovima.
Zatim je u kafić došao zaposlenik. Želi da vidi svoj poslužavnik kako bi ga mogao uzeti i otići pravo na večeru. Kafić želi da primi novac da zaradi na usluzi. Zaposleni želi da izgubi minimum vremena na obračunima sa kafićem, kako ne bi beskorisno gubio dragocjeno vrijeme. Kako uraditi? Plaćanje unaprijed ili obrnuto nakon servisa na daljinu. Ili platite na licu mjesta koristeći kiosk. Šta je u ovome najvažnije? Koliko ljudi je spremno da plati ručak bankovnom karticom? Koliko bi ljudi vjerovalo ovoj kantini da pohrani broj njihove kartice za ponovljena plaćanja? Bez terenskog istraživanja nejasno je, potrebno je testiranje.
U svakom koraku procesa morate na neki način obezbijediti funkcionalnost, za to morate uzeti neku osobu kao osnovu i izabrati šta mu je važnije (ista tri selektora). Pratio priču do kraja = napravio održivo rješenje.
Slijede detalji. Klijent želi da vidi koliko je kafić zauzet, kako se ne bi gurao u redovima. Šta on tačno želi?
Pogledajte prognozu koliko će ljudi biti za 15 minuta kada stigne
Pogledajte prosječno vrijeme usluge u kafiću i njegovu dinamiku pola sata unaprijed
Pogledajte situaciju i dinamiku popunjenosti stolova
Šta ako sistem predviđanja daje nejasan rezultat ili prestane da radi?
Kroz video pogledajte redove u kafiću, kao i popunjenost stolova. Hmm, zašto to prvo ne uradite?!
Autor ističe malu vježbu za vježbanje: pokušajte zamisliti šta radite ujutro nakon buđenja. Jedna karta = jedna akcija. Povećajte karte (umjesto mljevenja kafe, popijte okrepljujući napitak) da biste uklonili pojedinačne detalje, fokusirajući se ne na način implementacije, već na cilj.
Kome je ova knjiga namijenjena: IT analitičarima i projekt menadžerima. Obavezno pročitati.
aplikacije
Diskusija i donošenje odluka su efikasni u grupama od 3 do 5 osoba.
Na prvoj kartici napišite šta treba razviti, na drugoj - ispravite ono što ste uradili na prvoj, na trećoj - ispravite šta ste uradili na prvoj i drugoj.
Priče pripremajte kao kolače - ne tako što ćete napisati recept, već tako što ćete saznati kome, za koju priliku i za koliko ljudi je torta. Ako raščlanimo prodaju, onda to ne bi bilo na proizvodnju kolača, krema i sl., već na proizvodnju malih gotovih kolača.
Razvoj softvera je sličan snimanju filma, kada trebate pažljivo razviti i ispolirati scenarij, organizirati scenu, glumce itd. prije početka snimanja.
Uvijek će nedostajati resursa.
20% napora daje opipljive rezultate, 60% daje neshvatljive rezultate, 20% napora je štetno - zato je važno fokusirati se na učenje i ne očajavati u slučaju negativnog rezultata.
Komunicirajte direktno s korisnikom, osjetite se u njegovoj koži. Fokusirajte se na neke probleme.
Detaliziranje i razvijanje priče za evaluaciju je najmučniji dio scrum-a, neka se diskusije odvijaju u akvarijumskom režimu (3-4 osobe diskutuju na tabli, ako neko želi da učestvuje, on nekoga zamjenjuje).
izvor: www.habr.com