Patton Jeff. Kohandatud lood. Paindliku tarkvaraarenduse kunst

Kokkuvõte

Raamat on räägitud algoritm arendusprotsessi läbiviimiseks ideest kuni rakendamiseni agile tehnikaid kasutades. Protsess jaotatakse sammudeks ja igas sammus antakse meetodid protsessi etapi jaoks. Autor märgib, et enamus meetodeid ei ole originaalsed, ilma pretensioonita originaalsusele. Kuid hea esitlusstiil ja teatud terviklikkus protsessis muudavad raamatu väga kasulikuks.

Kasutajate lugude kaardi peamine tehnika on ideede struktureerimine ja esitlemine protsessi läbimise käigus.

Protsessi võib esitada erinevalt. Sammud võib üles ehitada, keskendudes võtmeväärtusele, või lihtsalt tuua kasutajate tööpäeva, nagu see toimub süsteemi kasutamise käigus. Autor rõhutab, et protsessid tuleb esitada, rääkida kasutaja looga protsessikaardil, mis on andnud nime kasutajate lugude kaart.

Kellele see on vajalik

IT-analüütikutele ja projektijuhtidele. Kohustuslik lugemine. Kergesti loetav ja meeldiv, raamat on mõõdukalt suur.

Keeldumine

Lihtsamas vormis, kuidas see töötab.

Külastaja tuleb kohvikusse, valib toidud, teeb tellimuse, saab toidu, sööb, maksab.

Saame kirjutada nõuded, mida me süsteemilt igas etapis ootame.

Süsteem peaks kuvama roogade nimekirja, iga roa koostisosad, kaal ja hind ning olema võimalus lisada korvi. Miks me nende nõuete osas kindlad oleme? "Standardses" nõuete kirjelduses seda ei kirjeldata ja see tekitab riske.

Täitjad, kes ei mõista, miks see vajalik on, teevad tavaliselt mitte seda, mida on vaja. Täitjad, kes ei ole kaasatud idee loomise protsessi, ei ole kaasatud ka tulemusesse. Agile ütleb, et keskendume kõigepealt mitte süsteemile, vaid inimestele, tarbijatele, nende ülesannetele ja eesmärkidele.

Loome isiksused, et suurendada empaatiat, anname neile detaile ja isikute vaatenurgast hakkame esitama lugusid.

Kantseleit Zahhar läks lõunale ja soovib kiiret snäki. Mida tal on vaja? Idee on – tõenäoliselt soovib ta ärilõunat. Veel üks idee: ta soovib, et süsteem mäletaks tema eelistusi, kuna ta on dieedil. Veel üks idee. Ta soovib, et talle tuuakse kohvi kohe, kuna ta on harjunud jooma kohvi enne lõunat.

Kas on veel äri (orgsonaž — tegelane, kes esindab mingit organisatsiooni). Äri soovib suurendada keskmist tšeki, suurendada ostude sagedust, suurendada kasumit. Idee on – pakkuda ebatavalisi roogasid mõnest köögist. Veel üks idee – võtame kasutusele hommikusöögid.

Ideesid on võimalik ja vajalik konkretiseerida, ümber kujundada ja vormistada kasutajaloona. Nagu ärikeskuse töötajana Zahhar, soovin, et süsteem tunneks mind ära, et saaksin menüü, mis arvestab minu eelistustega. Nagu kelner, soovin, et süsteem peaks mind teavitama, kui peaksin lauda minema, et klient oleks rahul kiire teenindusega. Ja nii edasi.

Kümneid lugusid. Edasi prioriseerimine ja tagavara? Jeff osutab tekkinud probleemidele: detailidesse kinni jäämine ja kontseptuaalse arusaama kaotamine koos funktsionaalsuse prioriseerimisega loob katkise pildi eesmärkide mitteühtivuse tõttu.

Autori tee: Prioriseerime mitte funktsionaalsuse, vaid tulemuse = selle, mida kasutaja lõpuks saab.

Ilmselge, kuid mitte silmatorkav punkt: prioriseerimise sessioon ei toimu kogu meeskonnaga, kuna see on ebaefektiivne, vaid kolme inimesega. Esimene vastutab äri eest, teine kasutajakogemuse eest ja kolmas teostuse eest.

Määratleme minimaalse kasutaja ülesande lahendamiseks (minimaalne elujõuline lahendus).

Täpistame esimese prioriteedi ideid kasutaja loo, kujunduse visandite, piirangute ja ärireeglite abil kasutaja lugude kaardil, rääkides ja arutades meeskonnaga, mida igal sammul protsessi jooksul personadele ja huvirühmadele on vaja. Ülejäänud ideed jäävad tackleerimata, võimaluste tagavara.

Protsess esitatakse kaartide kujul vasakult paremale, kus ideed on kaartidel protsessi sammude all. Oluline on kogu loo läbimise teed koos meeskonna töötajatega läbi rääkida, et saavutada vastastikune arusaamine.

Selline lähenemine loob vastavuse protsesside terviklikkuse.

Saadud ideed tuleb kontrollida. Mitte meeskonna liige paneb selga isiku mütsi ja elab isiku peades päev, lahendades tema ülesande. On võimalik, et ta ei näe varasemaid lahendusi, luues kaarte uuesti, ja meeskond avastab endale alternatiive.

Seejärel toimub detailsus hindamiseks. Selleks piisab kolmest inimesest. Kasutajakogemuse spetsialist, arendaja, testija, kes küsib oma lemmikküsimust: “Aga mis siis, kui…”.

Igal etapil käib arutelu kasutaja loo protsessikaardi üle, mis võimaldab, hoides meeles kasutaja ülesannet, luua arusaamise terviklikkuse.

Kas autor peab dokumentatsiooni vajalikuks? Jah, see on vajalik. Kuid märkmete kujul, mis aitavad meeles pidada, milles kokku lepiti. Väline inimese kaasamine nõuab taas arutelu.

Autor ei süvene dokumentatsiooni piisavuse teemasse, vaid keskendub peamiselt arutelude vajadusele. (Jah, dokumentatsioon on vajalik, hoolimata sellest, mida räägivad inimesed, kes ei mõista agile'i sügavust). Samuti võib ainult osa võimaluste töötlemine viia kogu süsteemi täieliku ümbertegemise vajaduseni. Autor osutab ülemäärase töötlemise riskile, kui idee ei osutu õigeks.

Riskide vähendamiseks on oluline kiiresti saada tagasisidet arendatava toote kohta, et vähendada 'vale' toote loomise kahju. Koostasime idee visandi — valideerisime kasutajaga, prototüüpide visandid — valideerisime kasutajaga jne. (Erinevalt näidatakse ka, kuidas valideerida tarkvara prototüüpe). Tarkvara loomise eesmärgid, eriti varases etapis, on õppimine kiire tagasiside saamise kaudu, seega on esialgne loodud toode visandid, mis saavad tõestada või ümber lükata hüpoteesi. (Autor toetub Eric Rieši tööle 'Lean metodoloogiaga käivitus').

Loo kaart aitab luua suhtlust, kui teostamine toimub mitme meeskonna kaudu. Mida peaks kaardil olema? Kõik, mis toetab vestlust. Mitte ainult kasutajalugu (kes, mida, miks), vaid ka ideed, faktid, liidese kavandid jne.

Jagades loo kaardil kaarte mitmeks horisontaalseks jooniseks, saab ülesanded jagada väljalasetele — tõsta esile minimaalne vajadus, funktsionaalsuse lisakiht ja effektid.

Räägime lugusid protsessikaardil.

Töötaja tuli lõunale.

Mida ta tahab? Teeninduse kiirusest. Et tema lõuna ootaks teda juba laual või vähemalt kandikul. Oops — vahele jäänud samm: töötaja soovis süüa. Ta sisenes süsteemi ja valis ärilõuna variandi. Ta nägi kaloreid ja toiteväärtuse vastavust, et järgida dieeti ja mitte juurde võtta. Ta nägi roogade pilte, et otsustada, kas ta söögikohas söömise üle otsustaks.

Järgmine samm on lõuna saamine. Kas talle tuuakse lõuna kontorisse? Siis peab ta valima, kus süüa. Ta tahab näha, millal tellimus kohale toodatakse ja kui palju see maksma läheb, et valida, kuhu oma aeg ja energia investeerida — kas minna alla või jääda tööle. Ta tahab näha kohvikute koormust, et mitte seista järjekordades.

Seejärel jõuab töötaja kohvikusse. Ta tahab näha oma tray’t, et seda võtta ja kohe lõunale minna. Kohvik tahab raha vastu võtta, et teenimisest kasu saada. Töötaja soovib kulutada kohvikus arveldamiseks võimalikult vähe aega, et mitte raisata oma väärtuslikku aega. Kuidas seda teha? Maksta ette või pärast teenindust eemalt. Või maksta otse kioski kaudu. Mis neist on peamine? Kui palju inimesi on valmis pangakaardiga lõunat maksma? Kui palju inimesi usaldab oma kaardi numbri säilitamist selle kohviku korduvateks makseteks? Ilma välitöödena ei ole see selge, vajame testimist.

Protsessi igas etapis tuleb mingil moel tagada funktsionaalsus, selleks tuleb valida mõni isik ja määrata, mis on tema jaoks oluline (see sama kolmik, kes valib). Kui ajalugu on lõpule viidud, on saavutatud elujõuline lahendus.

Edasi liigume detailide juurde. Klient soovib näha kohviku koormust, et mitte järjekordades tõuklemiseks jääda. Mida täpselt ta soovib?

Vaadata prognoosi, kui palju inimesi tuleb 15 minuti pärast, kui ta sinna läheb.

Vaadata keskmist teenindusaega kohvikus ja selle dünaamikat poole tunni võrra ette.

Vaadata olukorda ja laua hõivamise dünaamikat.

Aga mis siis, kui prognoosisüsteem annab arusaamatu tulemuse või lõpetab töötamise?

Vaadata kohvikus järjekordi videopildi kaudu, samuti laude hõivatust. Hmm, miks mitte teha seda esmajärjekorras?!

Autor toob välja väikese harjutuse praktika harjutamiseks: proovige kujutada ette, mida teete hommikul pärast ärkamist. Üks kaart = üks tegevus. Suurendage kaarte (asemel kohvi jahvatamine — jooge energiat andvat jooki), et eemaldada individuaalsed detailid, keskendudes mitte rakendamise viisile, vaid eesmärgile.

See raamat on mõeldud IT-analüütikutele ja projektijuhitele. Kohustuslik lugemine.

Rakendused

Arutelud ja otsuste tegemine on efektiivsed 3-5 liikmelistes gruppides.

Kirjuta esimeses kaardis, mida arendama peab, teises — kohandada seda, mida esimeses tehti, kolmandas — parandada seda, mis on tehtud esimeses ja teises.

Valmistage lood nagu kookide, mitte retseptide põhjal, vaid uurides, kellele, mis puhuks ja kui paljudele inimesele kook on vajalik. Kui teete rakenduse osi, siis mitte koogipõhjade, kreemide jms valmistamise põhjal, vaid väikevalmistatud kookide tegemise põhjal.

Tarkvaraarendus sarnaneb filmi loomisega, kus tuleb hoolikalt välja töötada ja lihvida stsenaariumit, korraldada stseene, näitlejaid jne enne filmimise alustamist.

Ressursse on alati puudu.

20% pingutustest toovad märkimisväärse tulemuse, 60% toovad segadust, 20% pingutustest on kahjulikud — seetõttu on oluline keskenduda õppimisele ja mitte alla anda negatiivse tulemuse korral.

Suhelge otse kasutajatega, tunnetage, kuidas nad tunnevad. Keskenduge teatud probleemidele.

Ajaloo detailimine ja töötlemine hindamiseks on scrum'i kõige tülikam osa; tehke arutelud akvaariumi režiimis, kus arutavad 3-4 inimest (kui keegi soovib osaleda, asendab ta kedagi).

Allikas: habr.com