Kokkuvõte
Raamat on jutustatud algoritm arendusprotsessi viimiseks ideest rakendamiseni, kasutades agile tehnikaid. Protsess jaguneb etappideks ja igas etapis on toodud meetodid protsessi sammu jaoks. Autor märgib, et suurem osa meetodeid ei ole originaalsed, mitte neid originaalsusele pretendeerides. Kuid hea esitlusstiil ja teatav protsessi terviklikkus teevad raamatust väga kasuliku.
Võtmetehnika kasutajate lugude kaardil on ideede ja eesmärkide struktureerimine protsessi käigus.
Protsessi läbiviimine võib olla välja toodud erinevalt. Saame etapid korraldada vastavalt saavutatud võtmeväärtusele või lihtsalt esitada kasutajate tööpäeva, nagu see toimub süsteemi kasutamise korral. Autor keskendub sellele, et protsesse tuleb väljendada, rääkida kasutaja loona protsessikaardil, mis andis oma nime kasutajate lugude kaardile.
Kellele see vajalik on
IT-analüütikutele ja projektijuhtidele. Kohustuslik lugemine. Lugemine on lihtne ja meeldiv, raamat on mõõdukalt pikk.
Tühistamine
Kõige lihtsamal kujul, kuidas see töötab.
Külastaja tuleb kohvikusse, valib roogasid, teeb tellimuse, saab toidu, sööb ja maksab.
Igal etapis on võimalik kirjutada nõudeid, mida me süsteemilt soovime.
Süsteem peab näitama roogade nimekirja, kus igal roogil on koostisosad, kaal ja hind, ning võimalus lisada see ostukorvi. Miks me oleme nende nõuete osas kindlad? "Standardse" nõudluse kirjelduses pole seda käsitletud ja see tekitab riske.
Täideviijad, kes ei mõista, miks see vajalik on, teevad tavaliselt seda, mida vaja ei ole. Täideviijad, kes ei ole seotud idee loomise protsessiga, ei ole seotud ka tulemusega. Agile ütleb, et keskenduge eelkõige mitte süsteemile, vaid inimestele, kasutajatele, nende ülesannetele ja eesmärkidele.
Loome isiksusi, et kaastunde loomiseks anda neile detaile ja isiksustest lähtudes hakkame lugusid rääkima.
Kantselei töötaja Zahhar läks lõunale ja soovib kiiresti eine nautida. Mida tal on vaja? Idee — võib-olla tahab ta äri lõunat. Veel üks idee — ta tahab, et süsteem mäletaks tema eelistusi, kuna ta on dieedil. Veel üks idee — ta soovib, et talle tuuakse kohe kohvi, kuna ta on harjunud kohvi jooma enne lõunat.
Kas on veel ärimudeli (orgsonaž — tegelane, kes esindab mingi organisatsiooni huve)? Äri soovib suurendada keskmist ostusummat, ostu sagedust ja kasumit. Idee — pakkuda ebatavalisi roogasid mingist köögist. Üks idee — mis siis, kui võtame kasutusele hommikusöögid.
Ideid saab ja tuleb konkreetselt määratleda, transformeerida ja vormistada kasutaja loo kujul. Nagu ärikeskuse töötaja Zahhar, tahan, et süsteem tunneks mind ära, et saaksin menüü, mis arvestab minu eelistustega. Nagu teenindaja, tahan, et süsteem teavitaks mind, millal minna lauda, et klient oleks rahul kiire teenindusega. Ja nii edasi.
Kümneid lugusid. Edasi prioriseerimine ja backlog? Jeff osutab tekkivatele probleemidele: detailidesse kinni jäämine ja kontseptuaalse arusaamise kaotus, pluss funktsionaalsuse prioriseerimine, loob katkendliku pildi, kuna see ei vasta eesmärkidele.
Autori tee: prioriseerime mitte funktsionaalsuse, vaid tulemuse = selle, mida kasutaja lõpuks saab.
Ilmselgelt mitte-ilmselge punkt: prioriseerimise sessiooni ei viibi kogu meeskond, kuna see on ebaefektiivne, vaid kolm inimest. Esiteks vastutab ärivajaduste eest, teine kasutajakogemuse eest ja kolmas elluviimise eest.
Määratleme miinimumi ühe kasutaja ülesande lahendamiseks (minimaalne elujõuline lahendus).
Täpistame esimese prioriteedi ideed kasutaja loo, disainijooniste, piirangute ja ärireeglite abil kasutajakogemuse kaardil, rääkides ja arutades meeskonnaga, mida isikud ja sidusrühmad igal protsessi sammul vajavad. Ülejäänud ideed jätame me ei arutamata, backlog'i võimaluste nimekirja.
Protsess kirjutatakse kaardikeste vormis vasakult paremale, ning ideed kaartidel on protsessi sammude all. Koos meeskonna liikmetega peab olema kindlasti arutelu kogu loo kulgemisest, et luua üksteisemõistmine.
Selle viisi kohandamine loob protsesside kooskõla terviklikkuse.
Saadud ideid tuleb kontrollida. Kellelegi meeskonnast ei pane isik persona peakatet ja veedab päeva tema peas, lahendades tema ülesande. Võimalik valik, et ta ei näe olemasolevaid töötulemusi, luues kaarte uuesti, kui meeskond avab endale alternatiive.
Seejärast toimub detailimine hindamise jaoks. Selleks piisab kolmest inimesest. Vastutav kasutajakogemuse eest, arendaja, testija, kelle lemmikküsimus on: “Ent mis siis, kui…”.
Igal etapil arutatakse kasutaja loo protsessikaarti, mis võimaldab, hoides meeles kasutaja ülesande, luua arusaamade järjepidevust.
Kas autori arvates on dokumentatsioon vajalik? Jah, see on vajalik. Kuid nagu märkmed, mis aitavad meeles pidada, milles kokku lepiti. Inimese kaasamine nõuab taas arutelu.
Autor ei süvene dokumentatsiooni piisavusse, keskendudes pigem arutelude vajadusele. (Jah, dokumentatsioon on vajalik, sõltumata sellest, mida väidavad inimesed, kes ei mõista agiilset lähenemist sügavalt). Samuti võib osade võimaluste detailne käsitlemine viia kogu süsteemi täieliku ümbertegemiseni. Autor toob esile liigse töötlemise riski, kui idee ei osutunud õigeks.
Ohtude vähendamiseks on vajalik kiiresti saada tagasisidet loodava toote kohta, et minimeerida “vale” toote loomise kahju. Koostati ideekavand — valideeriti kasutajalt, prototüüpide esialgne visand — valideeriti kasutajalt jne. (Eraldi mainitakse, kuidas valideerida programmide prototüüpe). Tarkvara loomise eesmärgid, eriti algfaasis — õppimine kiirest tagasisidest, seega on esialgne loodud toode visandid, mis suudavad tõestada või ümber lükata hüpoteesi. (Autor tugineb Eric Riesi tööle “Lean Startup”).
Loo kaart aitab luua suhtlust, kui rakendust tagavad mitmed meeskonnad. Mida peaks kaardil olema? Kõike, mis on vajalik vestluse toetamiseks. Mitte ainult kasutaja lugu (kes, mis, miks), vaid ka ideed, faktid, liidese visandid jne.
Jagades loo kaardi kaardid mitmeks horisontaalseks jooniseks, saab tööd jagada väljaanneteks — eristada minimaalset, funktsionaalsuse lisakihti ja “linti”.
Räägime lugusid protsessi kaardil.
Töötaja tuli lõunale.
Mida ta soovib? Teeninduse kiirus. Et tema lõunasöök ootaks teda laual või vähemalt taletti. Oops — üks samm jäi vahele: töötaja tahtis süüa. Ta sisenes süsteemi ja valis ärilõuna variandi. Ta nägi kalorsust ja vastavust toiteväärtusele, et järgida dieeti ja mitte paksuks minna. Ta nägi roogade pilte, et otsustada, kas ta sööb selles kohas või mitte.
Kas siis ta läheb lõunat sööma? Või tuuakse talle lõunasöök kontorisse? Siis on järgmine samm toidu koha valimine. Ta tahab näha, millal toit talle kohale toimetatakse ja kui palju see maksab, et otsustada, kuhu aega ja energiat kulutada — allapoole minnes või tööl olles. Ta tahab näha kohviku koormust, et mitte järjekordades seisma jääda.
Seejärel tuli töötaja kohvikusse. Ta tahab näha oma taldrikut, et võtta see ja otse lõunat sööma minna. Kohvik tahab raha vastu võtta, et teenida teenindusest. Töötaja tahab, et ta kulutaks kohvikus arveldamiseks võimalikult vähe aega, et mitte raisata oma väärtuslikku aega. Kuidas seda teha? Maksta ette või vastupidi, pärast teenindust eemalt. Või maksta hetkel kioski kaudu. Mis on sellest kõige olulisem? Kui palju inimesi on valmis maksma pangakaardiga lõuna eest? Kui palju inimesi usaldab kaardi numbri salvestamist selle söökla korduvateks makseteks? Ilma välja uuringuta pole selge, testimist on vaja.
Iga protsessi sammu korral tuleb kuidagi funktsionaalsust tagada, selleks tuleb võtta mingi isik ja valida, mis on talle olulisem (just see kolmik, kes valib). Kui lugu on lõpuni jõudnud = on loodud elujõuline lahendus.
Seejärel toimub detailide välja selgitamine. Klient tahab näha kohviku koormust, et mitte järjekordades seisma jääda. Mida täpselt ta tahab?
Vaadata prognoosi, kui palju inimesi on 15 minuti pärast, kui ta sinna läheneb.
Vaadata keskmist teenindusaega kohvikus ja selle dünaamikat poole tunni võrra ette.
Vaadata olukorda ja laudade hõivamise dünaamikat.
Aga mis siis, kui prognoosisüsteem annab arusaamatuid tulemusi või lõpetab töötamise?
Vaadata kohvikus järjekordi videote kaudu ning samuti laudade hõivatust. Hmm, miks mitte seda kõigepealt teha?!
Autor toob välja väikese harjutuse praktika arendamiseks: proovige ette kujutada, mida teete hommikul pärast ärkamist. Üks kaart = üks tegevus. Lihtsustage kaarte (kohvi valmistamise asemel - jooge elustav jook), et eemaldada individuaalsed detailid, keskendudes mitte teostusviisile, vaid eesmärgile.
Kellele see raamat on - IT-analüütikutele ja projektijuhtidele. Kohustuslik lugemine.
Rakendused
Arutelud ja otsuste vastuvõtmine on tõhusad gruppides, kus on 3 kuni 5 inimest.
Kirjutage esimesel kaardil, mida tuleb arendada, teisel — parandage seda, mis on esimesel tehtud, kolmandal — parandage seda, mis on tehtud esimesel ja teisel.
Valmistage lugusid nagu koogid - mitte retsepti välja kirjutades, vaid teada saades, kellele, mis põhjusega, mitu inimest kook on. Kui jagada teostus osi, siis mitte koogi valmistamiseks, kreemi jne, vaid väikeste valmis kookide valmistamiseks.
Tarkvara arendamine on sarnane filmi loomisele, kus on vajalik hoolikalt ette valmistada ja lihvida stsenaariumi, korraldada stseene, näitlejaid jne enne filmimist.
Resource'id on alati puudujäägis.
20% pingutustest annab käegakatsutava tulemuse, 60% toob ebamugavusi, 20% pingutustest on kahjulikud — seetõttu on oluline keskenduda õppimisele ja mitte meelt heita negatiivsete tulemustega.
Suhelge kasutajaga otse, tundke end tema olukorras. Keskenduge teatud probleemidele.
Ajaloo detailimine ja töötlemine hindamiseks on scrum'i kõige vaevarikkam osa, tehke arutelud seisvateks akvaariumi režiimis (seinaraamatu juures arutavad 3-4 inimest, kui keegi soovib osaleda, asendab ta kedagi).
Allikas: habr.com
