Annotaasje
It boek is in ferteld algoritme foar it útfieren fan it ûntwikkelingsproses fan idee oant ymplemintaasje mei agile techniken. It proses wurdt yn stappen útlein en by elke stap wurde de metoaden foar de prosesstap oanjûn. De skriuwer wiist derop dat de measte metoaden net orizjineel binne, sûnder beweare dat se orizjineel binne. Mar de goede skriuwstyl en wat yntegriteit fan it proses meitsje it boek tige brûkber.
In wichtige technyk fan mapping fan brûkersferhalen is om ideeën en prestaasjes te strukturearjen as de brûker troch it proses beweecht.
Tagelyk kin it proses op ferskate wizen beskreaun wurde. Jo kinne stappen bouwe as jo in kaaiwearde berikke, of jo kinne gewoan de wurkdei fan 'e brûkers nimme en foarstelle as it giet troch it brûken fan it systeem. De skriuwer rjochtet him op it feit dat prosessen sketst wurde moatte, sprutsen yn 'e foarm fan in brûkersferhaal op in proseskaart, dat is wat ús de namme user story map joech.
Wa hat it nedich
Foar IT-analisten en projektmanagers. In must read. Maklik en noflik om te lêzen, it boek is middelgrutte.
Tebekwurd
Yn syn ienfâldichste foarm, dit is hoe't it wurket.
In besiker komt nei in kafee, kiest gerjochten, pleatst in bestelling, krijt iten, yt en betellet.
Wy kinne yn elke poadium easken skriuwe foar wat wy wolle fan it systeem.
It systeem moat in list mei gerjochten sjen litte, elk skûtel hat in gearstalling, gewicht en priis en kin tafoegje oan winkelkarre. Wêrom binne wy betrouwen yn dizze easken? Dit wurdt net beskreaun yn 'e "standert" beskriuwing fan easken en dit soarget foar risiko's.
Artysten dy't net begripe wêrom't dat nedich is, dogge meastal it ferkearde ding. Utfierders dy't net belutsen binne by it proses fan it meitsjen fan in idee binne net belutsen by it resultaat. Agile seit, lit ús ús yn it foarste plak net rjochtsje op it systeem, mar op minsken, op konsuminten, har taken en doelen.
Wy meitsje personas, jouwe se details foar empasy, en begjinne ferhalen te fertellen fan 'e kant fan' e persona.
Kantoormeiwurker Zakhar gie nei lunch en wol in flugge snack hawwe. Wat hat er nedich? It idee is dat hy wierskynlik in saaklike lunch wol. In oar idee is dat hy wol dat it systeem syn foarkarren ûnthâldt, om't hy op in dieet is. In oar idee. De kofje wol er fuortdaliks by him bringe, want hy is wend om foar de middei kofje te drinken.
En der is ek in bedriuw (in organisatoarysk karakter is in karakter dat de belangen fan in organisaasje fertsjintwurdiget). Bedriuwen wolle de gemiddelde kontrôle ferheegje, de frekwinsje fan oankeapen ferheegje en winsten ferheegje. It idee is - litte wy ûngewoane gerjochten fan guon keuken oanbiede. In oar idee - lit ús moarnsbrochje yntrodusearje.
Ideeën kinne en moatte konkretisearre, omfoarme en presintearre wurde yn 'e foarm fan in brûkersferhaal. As meiwurker fan it Zakhar Business Center wol ik dat it systeem my erkent, sadat ik in menu kin ûntfange op basis fan myn foarkar. As ober wol ik dat it systeem my ynformearret wannear't ik oan 'e tafel moat, sadat de kliïnt tefreden is mei snelle tsjinst. Ensafuorthinne.
Tsientallen ferhalen. Folgjende is prioritearring en efterstân? Jeff wiist op 'e problemen dy't ûntsteane: yn lytse details ferdwine en konseptueel begryp ferlieze, plus it prioritearjen fan funksjonaliteit soarget foar in raffelich byld troch inkonsistinsje mei doelen.
It paad fan de auteur: Wy prioritearje net de funksjonaliteit, mar it resultaat = wat de brûker op it lêst krijt.
In dúdlik net foar de hân lizzend punt: de prioriteitssesje wurdt net útfierd troch it hiele team, om't it net effektyf is, mar troch trije minsken. De earste is ferantwurdlik foar bedriuw, de twadde foar brûkersûnderfining en de tredde foar ymplemintaasje.
Lit ús it minimum selektearje foar it oplossen fan ien brûkerprobleem (minimum libbensfetbere oplossing).
Wy detailje de ideeën mei earste prioriteit mei brûkersferhalen, ûntwerpsketsen, beheiningen en saaklike regels op 'e kaart fan brûkersferhalen troch te fertellen en te besprekken mei it team wat minsken en belanghawwenden nedich binne by elke stap fan it proses. Wy litte de oerbleaune ideeën net ûndersocht yn 'e efterstân fan kânsen.
It proses is skreaun op kaarten fan links nei rjochts, mei ideeën op kaarten ûnder de prosesstappen. It is needsaaklik dat it paad troch it hiele ferhaal tegearre mei de teamleden besprutsen wurdt om ûnderling begryp te garandearjen.
Utwurking op dizze manier soarget foar yntegriteit yn oerienstimming mei prosessen.
De ûntfongen ideeën moatte wurde hifke. In net-teamlid set de hoed fan 'e persoan op en libbet de dei fan 'e persoan yn syn holle, en lost syn probleem op. It is mooglik dat hy net sjocht de ûntwikkelingen, it meitsjen fan kaarten wer, en it team ûntdekt alternativen foar himsels.
Dan is d'r detaillearring foar evaluaasje. Trije minsken binne hjir genôch foar. Ferantwurdlik foar brûkersûnderfining, ûntwikkelder, tester mei in favorite fraach: "Wat as ...".
Yn elke poadium folget de diskusje in proseskaart fan 'e skiednis fan' e brûker, wêrtroch't de taak fan 'e brûker yn 't ferstân hâldt om in gearhingjend begryp te meitsjen.
Is dokumintaasje nedich neffens de auteur? Ja, ik haw it nedich. Mar as notysjes wêrmei jo te ûnthâlden wat jo ôfpraat op. It belûken fan in bûtensteander freget wer oerlis.
De skriuwer net ferdjipje yn it ûnderwerp fan genôch dokumintaasje, rjochte op de needsaak foar diskusje. (Ja, dokumintaasje is nedich, nettsjinsteande hoe't minsken dy't gjin djip begryp hawwe fan agile it ek beweare). Ek útwurking fan mar in part fan 'e mooglikheden kin liede ta de needsaak foar in folsleine rework fan it hiele systeem. De skriuwer wiist op it risiko fan tefolle útwurking yn it gefal as it idee ferkeard is.
Om risiko's te eliminearjen, is it nedich om fluch feedback te ûntfangen oer it produkt dat makke wurdt om de skea fan it meitsjen fan it "ferkearde" produkt te minimalisearjen. Wy makken in skets fan it idee - validearre it mei de brûker, sketste ynterfaceprototypes - validearre it mei de brûker, ensfh. (Apart is d'r in bytsje ynformaasje oer hoe't jo programmaprototypen kinne falidearje). De doelen fan it meitsjen fan software, foaral yn 'e earste faze, binne learen troch rappe feedback te ûntfangen; dêrtroch is it earste produkt makke sketsen dy't in hypoteze kinne bewize of wjerlizze. (De skriuwer fertrout op it wurk fan Eric Ries "Opstarten mei Lean-metodology").
In ferhaalkaart helpt kommunikaasje te ferbetterjen as ymplemintaasje wurdt útfierd oer meardere teams. Wat moat op de kaart stean? Wat jo nedich hawwe om it petear te hâlden. Net allinich in brûkersferhaal (wa, wat, wêrom), mar ideeën, feiten, ynterface sketsen, ensfh ...
Troch de kaarten op 'e skiedniskaart te dielen yn ferskate horizontale rigels, kinne jo it wurk diele yn releases - markearje it minimum, in laach fan tanimmende funksjonaliteit en bôgen.
Wy fertelle ferhalen op de proseskaart.
In meiwurker kaam foar it middeisiten.
Wat wol hy? Service snelheden. Dat syn lunch al op 'e tafel of alteast op in dienblad stiet te wachtsjen. Oeps - in miste stap: de meiwurker woe ite. Hy oanmelde en selektearre de saaklike lunch opsje. Hy seach de kalorie-ynhâld en fiedingsynhâld om him te helpen by it dieet en net gewicht te krijen. Hy seach foto's fan it gerjocht om te besluten oft er op dat plak ite soe of net.
Folgjende, sil hy gean om lunch en diner? Of miskien lunch wurdt levere oan syn kantoar? Dan is de stap fan it proses it kiezen fan in plak om te iten. Hy wol sjen wannear't it by him besoarge wurdt en hoefolle it kostet, sadat hy kin kieze wêr't hy syn tiid en enerzjy trochbringe sil - nei ûnderen of nei it wurk. Hy wol sjen hoe drok it kafee is om net yn de wachtrijen te skodzjen.
Doe kaam de meiwurker nei it kafee. Hy wol syn bakje sjen, sadat er it nimme kin en direkt nei iten gean. It kafee wol jild oannimme om jild te meitsjen op tsjinst. De meiwurker wol in minimum tiid ferlieze oan betellingen oan it kafee, om kostbere tiid net nutteloos te fergrieme. Hoe it te dwaan? Betelje foarôf of oarsom nei tsjinst op ôfstân. Of betelje op it plak mei in kiosk. Wat is it wichtichste ding oer dit? Hoefolle minsken binne ree om te beteljen foar lunch mei in bankkaart? Hoefolle minsken soene dizze kantine fertrouwe om har kaartnûmer op te slaan foar werhelle betellingen? Sûnder fjildûndersyk is it ûndúdlik, testen is nedich.
By elke stap fan it proses moatte jo op syn minst ien of oare manier funksjonaliteit leverje, dêrfoar moatte jo ien persoan as basis nimme en kieze wat foar him wichtiger is (deselde trije selectors). It ferhaal folge oant it ein = in libbensfetbere oplossing makke.
Folgjende komt de detaillearring. De klant wol sjen hoe drok it kafee is, om net yn de wachtrijen te skodzjen. Wat wol er krekt?
Sjoch de prognose fan hoefolle minsken d'r oer 15 minuten sille wêze as hy dêr komt
Besjoch de gemiddelde tsjinsttiid yn in kafee en syn dynamyk in heal oere fan tefoaren
Sjoch de situaasje en tafel besettingsdynamyk
Wat as it prognosesysteem in ûndúdlik resultaat jout of ophâldt mei wurkjen?
Sjoch fia fideo de wachtrijen yn it kafee, lykas de besetting fan tafels. Hmm, wêrom net earst dwaan?!
De skriuwer wiist op in lytse oefening om te oefenjen: besykje jo foar te stellen wat jo moarns nei it wekkerjen dogge. Ien kaart = ien aksje. Fergrutsje de kaarten (ynstee fan it slypjen fan kofje, drink in stimulearjend drankje) om yndividuele details te ferwiderjen, rjochte net op 'e metoade fan útfiering, mar op it doel.
Foar wa is dit boek: IT-analisten en projektmanagers. In must read.
apps
Diskusje en beslútfoarming binne effektyf yn groepen fan 3 oant 5 minsken.
Skriuw op 'e earste kaart wat moat wurde ûntwikkele, op' e twadde - korrigearje wat jo dien hawwe yn 'e earste, op' e tredde - korrigearje wat yn 'e earste en twadde dien is.
Meitsje ferhalen as gebak - net troch in resept út te skriuwen, mar troch út te finen foar wa, foar hokker gelegenheid, en foar hoefolle minsken de taart is. As wy de ferkeap ôfbrekke, dan soe it net wêze yn 'e produksje fan koeken, crème, ensfh., Mar yn' e produksje fan lytse klearmakke koeken.
Softwareûntwikkeling is fergelykber mei it meitsjen fan in film, as jo it skript soarchfâldich ûntwikkelje en polearje moatte, it toaniel, akteurs, ensfh., foardat it filmjen begjint.
Der sil altyd in tekoart oan middels wêze.
20% fan ynspanningen produsearje taastbere resultaten, 60% jouwe ûnbegryplike resultaten, 20% fan ynspanningen binne skealik - dêrom is it wichtich om te fokusjen op learen en net te wanhopich yn gefal fan in negatyf resultaat.
Kommunisearje direkt mei de brûker, fiel josels yn syn skuon. Fokus op guon problemen.
Detaillearjen en ûntwikkeljen fan it ferhaal foar evaluaasje is it meast drege diel fan scrum, meitsje de diskusjes stand-up yn aquarium modus (3-4 minsken beprate oan it bestjoer, as immen wol meidwaan, hy ferfangt immen).
Boarne: www.habr.com