sažetak
Knjiga je ispričani algoritam za provođenje procesa razvoja od ideje do implementacije pomoću agilnih tehnika. Proces je postavljen u korake iu svakom koraku su naznačene metode za korak procesa. Autor ističe da većina metoda nije originalna, ne pretendirajući na to da je originalna. Ali dobar stil pisanja i donekle cjelovitost postupka čine knjigu vrlo korisnom.
Ključna tehnika mapiranja korisničkih priča jest strukturiranje ideja i izvedbi dok se korisnik kreće kroz proces.
U isto vrijeme, proces se može opisati na različite načine. Možete graditi korake dok postižete ključnu vrijednost ili jednostavno možete zamisliti radni dan korisnika kako prolazi korištenjem sustava. Autor se fokusira na činjenicu da procese treba ocrtati, izgovoriti u obliku korisničke priče na mapi procesa, po čemu smo i dobili naziv mapa korisničke priče.
Kome treba
Za IT analitičare i voditelje projekata. Obavezno pročitati. Laka i ugodna za čitanje, knjiga je srednje veličine.
Pregledajte
U svom najjednostavnijem obliku, to je kako to funkcionira.
Posjetitelj dolazi u kafić, bira jela, naručuje, prima hranu, jede i plaća.
Možemo napisati zahtjeve za ono što želimo od sustava u svakoj fazi.
Sustav bi trebao prikazati popis jela, svako jelo imati sastav, težinu i cijenu te se moći dodati u košaricu. Zašto smo sigurni u ove zahtjeve? To nije opisano u "standardnom" opisu zahtjeva i to stvara rizike.
Izvođači koji ne razumiju zašto je to potrebno obično rade krivo. Izvođači koji nisu uključeni u proces stvaranja ideje nisu uključeni u rezultat. Agile kaže, fokusirajmo se prvenstveno ne na sustav, nego na ljude, na potrošače, njihove zadatke i ciljeve.
Stvaramo persone, dajemo im detalje za empatiju i počinjemo pričati priče s njihove strane.
Uredski zaposlenik Zakhar otišao je na ručak i želi nešto brzo prezalogajiti. Što mu treba? Ideja je da on vjerojatno želi poslovni ručak. Druga ideja je da on želi da sustav zapamti njegove preferencije jer je na dijeti. Još jedna ideja. Želi da mu odmah donesu kavu jer je navikao piti kavu prije ručka.
A postoji i poslovni (organizacijski karakter je karakter koji zastupa interese organizacije). Poduzeća žele povećati prosječni ček, povećati učestalost kupnje i povećati profit. Ideja je - ponudimo neobična jela neke kuhinje. Još jedna ideja – uvedimo 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 sustav prepozna kako bih mogao dobiti jelovnik prema svojim preferencijama. Kao konobar želim da me sustav obavijesti kada treba prići stolu kako bi klijent bio zadovoljan brzom uslugom. I tako dalje.
Deseci priča. Sljedeće je određivanje prioriteta i zaostatak? Jeff ističe probleme koji se pojavljuju: zaglavljivanje u sitnim detaljima i gubitak konceptualnog razumijevanja, plus davanje prioriteta funkcionalnosti stvara raščupanu sliku zbog nedosljednosti s ciljevima.
Put autora: Nije nam prioritet funkcionalnost, već rezultat = ono što korisnik dobiva na kraju.
Očigledna neočita točka: sesiju određivanja prioriteta ne provodi cijeli tim, jer je neučinkovit, već tri osobe. Prvi je odgovoran za poslovanje, drugi za korisničko iskustvo, a treći za implementaciju.
Odaberimo minimum za rješavanje problema jednog korisnika (minimalno održivo rješenje).
Detaljno opisujemo ideje prvog prioriteta korištenjem korisničkih priča, skica dizajna, ograničenja i poslovnih pravila na karti korisničkih priča govoreći i raspravljajući s timom što je ljudima i dionicima potrebno u svakom koraku procesa. Preostale ideje ostavljamo neispitane u gomili prilika.
Proces je napisan na karticama s lijeva na desno, s idejama na karticama ispod koraka procesa. Imperativ je da se put kroz cijelu priču raspravi zajedno s članovima tima kako bi se osiguralo međusobno razumijevanje.
Razrada na ovaj način stvara cjelovitost u skladu s procesima.
Primljene ideje potrebno je testirati. Nečlan tima stavi kapu osobe i živi dan osobe u svojoj glavi, rješavajući njen problem. Moguće je da on ne vidi razvoj događaja, ponovno stvara kartice, a tim otkriva alternative za sebe.
Zatim slijedi detaljizacija za procjenu. Za to su dovoljne tri osobe. Odgovoran za korisničko iskustvo, developer, tester s omiljenim pitanjem: “Što ako...”.
U svakoj fazi, rasprava slijedi procesnu mapu korisničke povijesti, koja omogućuje vođenje korisnikovog zadatka na umu kako bi se stvorilo koherentno razumijevanje.
Je li dokumentacija potrebna po mišljenju autora? Da, treba mi. Ali kao bilješke koje vam omogućuju da zapamtite što ste dogovorili. Ponovno uključivanje autsajdera zahtijeva raspravu.
Autor ne ulazi u temu dostatnosti dokumentacije, fokusirajući se na potrebu rasprave. (Da, potrebna je dokumentacija, ma kako to tvrdili ljudi koji se ne razumiju duboko u agile). Također, razrada samo dijela mogućnosti može dovesti do potrebe za potpunom preradom cijelog sustava. Autor ukazuje na rizik pretjerane elaboracije u slučaju kada je ideja pogrešna.
Kako bi se uklonili rizici, potrebno je brzo dobiti povratnu informaciju o proizvodu koji se stvara kako bi se smanjila šteta od stvaranja “pogrešnog” proizvoda. Napravili smo skicu ideje - validirali je s korisnikom, skicirali prototipove sučelja - validirali s korisnikom itd. (Odvojeno, postoji malo informacija o tome kako potvrditi prototipove programa). Ciljevi izrade softvera, osobito u početnoj fazi, su učenje kroz dobivanje brze povratne informacije, stoga su prvi proizvod koji se stvara skice koje mogu dokazati ili opovrgnuti hipotezu. (Autor se oslanja na rad Erica Riesa “Startup using Lean methodology”).
Karta priče pomaže poboljšati komunikaciju kada se implementacija provodi u više timova. Što bi trebalo biti na karti? Što vam je potrebno za nastavak razgovora. Ne samo korisnička priča (tko, što, zašto), već ideje, činjenice, skice sučelja, itd...
Podijelivši kartice na povijesnoj karti u nekoliko vodoravnih linija, možete podijeliti rad na izdanja - istaknuti minimum, sloj povećanja funkcionalnosti i lukove.
Pričamo priče na mapi procesa.
Zaposlenik je došao na ručak.
Što on želi? Brzine usluge. Tako da ga ručak već čeka na stolu ili barem na pladnju. Ups - promašen korak: zaposlenik je htio jesti. Ulogirao se i odabrao opciju poslovnog ručka. Vidio je sadržaj kalorija i nutritivan sadržaj koji mu pomažu na dijeti i ne dobivaju na težini. Vidio je slike jela kako bi odlučio hoće li jesti na tom mjestu ili ne.
Dalje, hoće li otići na ručak i večeru? Ili će možda ručak biti dostavljen u njegov ured? Zatim je korak u procesu odabir mjesta za jelo. Želi vidjeti kada će mu biti isporučeno i koliko će koštati, kako bi mogao izabrati gdje će potrošiti svoje vrijeme i energiju - sići dolje ili otići na posao. Želi vidjeti koliko je kafić zauzet kako se ne bi gurao u redovima.
Zatim je u kafić došla djelatnica. Želi vidjeti svoj pladanj kako bi ga mogao uzeti i otići ravno na večeru. Kafić želi primati novac kako bi zaradio na usluzi. Zaposlenik želi izgubiti najmanje vremena na nagodbe s kafićem, kako ne bi beskorisno gubio dragocjeno vrijeme. Kako to učiniti? Plaćanje unaprijed ili obrnuto nakon usluge na daljinu. Ili platite na licu mjesta putem kioska. Što je najvažnije u vezi s tim? Koliko je ljudi spremno platiti ručak bankovnom karticom? Koliko bi ljudi vjerovalo ovoj kantini da pohrani broj svoje kartice za ponovna plaćanja? Bez terenskog istraživanja nejasno je, potrebno je testiranje.
U svakom koraku procesa morate nekako osigurati funkcionalnost, za to trebate uzeti neku osobu kao osnovu i izabrati što je njemu važnije (ista tri selektora). Pratio priču do kraja = napravio održivo rješenje.
Slijedi detaljiziranje. Klijent želi vidjeti koliko je kafić zauzet, kako se ne bi gurao u redovima. Što on točno želi?
Pogledajte prognozu koliko će ljudi biti za 15 minuta kad on stigne
Pogledajte prosječno vrijeme usluge u kafiću i njegovu dinamiku pola sata unaprijed
Pogledajte stanje i dinamiku popunjenosti stolova
Što ako sustav predviđanja daje nejasan rezultat ili prestane raditi?
Kroz video pogledajte redove u kafiću, kao i popunjenost stolova. Hmm, zašto to ne učiniti prvo?!
Autor ističe malu vježbu za vježbanje: pokušajte zamisliti što radite ujutro nakon buđenja. Jedna kartica = jedna akcija. Povećajte kartice (umjesto mljevenja kave, popijte okrepljujuće piće) kako biste uklonili pojedinačne detalje, ne fokusirajući se na način implementacije, već na cilj.
Kome je ova knjiga namijenjena: IT analitičarima i voditeljima projekata. Obavezno pročitati.
Apps
Rasprava i donošenje odluka učinkoviti su u grupama od 3 do 5 ljudi.
Na prvu karticu napišite što treba razviti, na drugu - ispravite ono što ste učinili u prvoj, na treću - ispravite ono što je učinjeno u prvoj i drugoj.
Pripremite priče poput kolača – ne tako da napišete recept, već tako da saznate za koga, za koju priliku i za koliko ljudi je torta namijenjena. Ako raščlanimo prodaju, onda to ne bi bila proizvodnja kolača, krema i sl., već proizvodnja sitnih gotovih kolača.
Razvoj softvera je sličan snimanju filma, kada trebate pažljivo razviti i dotjerati 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 usredotočiti se na učenje i ne očajavati u slučaju negativnog rezultata.
Komunicirajte izravno s korisnikom, osjetite se u njegovoj koži. Usredotočite se na neke probleme.
Detaljiziranje i razvijanje priče za evaluaciju je najmučniji dio scruma, neka rasprave budu stand-up u akvarij modu (3-4 osobe raspravljaju na ploči, ako netko želi sudjelovati, on nekoga zamijeni).
Izvor: www.habr.com