Resumé
Bogen er en fortælling om algoritmen til at gennemføre udviklingsprocessen fra idé til implementering ved hjælp af agile teknikker. Processen er opdelt i trin, og for hvert trin angives metoderne til trin i processen. Forfatteren bemærker, at størstedelen af metoderne ikke er originale, og han gør ikke krav på originalitet. Men den gode skrivestil og den visse sammenhæng i processen gør bogen meget nyttig.
Den nøglemetode, der anvendes i brugerhistoriekort, er strukturering af idéer og opgaver under brugernes gennemgang af processen.
Processen kan beskrives på forskellige måder. Man kan opbygge trinene i takt med, at den nøgleværdi nås, eller man kan simpelthen tage og fremstille en arbejdsdag for brugerne, som den udfolder sig ved brug af systemet. Forfatteren fokuserer på, at processerne skal beskrives og fremlægges som brugerhistorier på proceskortet, hvilket har givet navn til brugerhistoriekortet.
Hvem har brug for dette
For IT-analytikere og projektledere. Skal læses. Den er let at læse og behagelig, og bogen er af gennemsnitlig størrelse.
Anmeldelse
I sin enkleste form, sådan fungerer det.
Besøgende kommer ind i caféen, vælger retter, afgiver ordre, får mad, spiser, betaler.
Man kan skrive krav til, hvad vi ønsker fra systemet på hvert trin.
Systemet skal vise en liste over retter, hver ret skal have ingredienser, vægt og pris samt muligheden for at tilføje til kurven. Hvorfor er vi sikre på disse krav? I en 'standard' beskrivelse af kravene er dette ikke beskrevet, og det skaber risici.
Udførere, der ikke forstår, hvorfor dette er nødvendigt, laver normalt ikke det, der er nødvendigt. Udførere, der ikke er involveret i ideens skabelsesproces, er heller ikke involveret i resultatet. Agile siger, lad os fokusere først og fremmest ikke på systemet, men på mennesker, på forbrugerne, deres opgaver og mål.
Vi laver personas, giver dem detaljer for empati, og fra personernes synspunkt begynder vi at fremlægge historier.
Kontormedarbejderen Zachar gik til frokost og ønsker at spise hurtigt. Hvad har han brug for? Ideen er, at han sandsynligvis ønsker en business lunch. En anden idé er, at han ønsker, at systemet skal huske hans præferencer, da han er på diæt. Endnu en idé. Han ønsker, at kaffen straks bliver bragt til ham, fordi han er vant til at drikke kaffe før frokost.
Der er også en forretning (orgkarakter — en karakter, der repræsenterer interessene for en given organisation). Forretningen ønsker at øge den gennemsnitlige købsværdi, øge købsfrekvensen og øge fortjenesten. Ideen er — lad os tilbyde usædvanlige retter fra en bestemt cuisine. Endnu en idé — lad os introducere morgenmad.
Ideer kan og bør konkretiseres, omdannes og præsenteres som user stories. Som medarbejder i forretningscentret Zachar vil jeg, at systemet genkender mig, så jeg kan modtage en menu, der tager højde for mine præferencer. Som servitør vil jeg, at systemet varsler mig, når jeg skal tage mig af bordet, så kunden er tilfreds med den hurtige service. Og så videre.
Dutzinder af historier. Hvad med prioritering og backlog? Jeff påpeger de opstående problemer: fastlåsning i små detaljer og tab af konceptuel forståelse plus prioritering af funktionalitet skaber et brudt billede på grund af manglende sammenhæng med målene.
Forfatterens vej: Vi prioriterer ikke funktionalitet, men resultat = det, som brugeren får i sidste ende.
Et åbenlyst men ikke åbenlyst punkt: prioriteringsmødet holdes ikke af hele teamet, da det er ineffektivt, men af tre personer. Den første har ansvar for forretningen, den anden for brugeroplevelsen, og den tredje for implementeringen.
Lad os definere minimumskravet for at løse en brugeropgave (minimum levedygtigt produkt).
Lad os detaljere ideerne for den første prioritet ved hjælp af user stories, designskitser, begrænsninger og forretningsregler på kortet over brugerhistorier ved at fortælle og diskutere med teamet, hvad der er behov for af personaer og interessenter på hvert trin i processen. De øvrige idéer lader vi være i backloggen af muligheder.
Processen skrives i form af kort fra venstre mod højre, og idéerne på kortene placeres under procestrinnene. Det er afgørende, at hele historien drøftes med teammedlemmerne for at opnå gensidig forståelse.
Denne tilgang skaber en helhed i overensstemmelse med processerne.
De indsamlede idéer skal valideres. En ikke-tilknyttet medlem ifører sig persona-hatten og lever en dag i personaens sko, mens de løser opgaven. Der er mulighed for, at de ikke ser de tidligere anstrengelser og skaber kortene forfra, mens teamet opdager alternativer.
Derefter sker der en detaljeringsfase for vurderingen. Dette kræver blot tre personer. Den ansvarlige for brugeroplevelsen, udvikleren og testeren med det yndlingsspørgsmål: “Hvad hvis…”.
I hver fase diskuteres processen ud fra brugerrejse kortet, hvilket gør det muligt at skabe en helhedsforståelse af brugerens opgave.
Er dokumentation nødvendig ifølge forfatteren? Ja, det er den. Men som noter, der hjælper med at huske, hvad man er blevet enige om. Involvering af personer udefra kræver igen diskussion.
Forfatteren går ikke i dybden med emnet omkring dokumentationens tilstrækkelighed, men lægger vægt på nødvendigheden af diskussioner. (Ja, dokumentation er nødvendig, uanset hvad dem der ikke forstår agile siger). Behandling af kun en del af mulighederne kan også føre til behovet for en total ombygning af hele systemet. Forfatteren påpeger risikoen for overbehandling, hvis man ikke rammer idéen.
For at mindske risikoen er det nødvendigt hurtigt at få feedback på det udviklede produkt for at minimere skaden ved at skabe et “forkert” produkt. Man skitserer en idé – validerer hos brugeren, skitserer brugergrænseflader – validerer hos brugeren osv. (Der gives lidt særskilt information om, hvordan man skal validere prototyper). Målet med softwareudvikling, især i den indledende fase, er at lære gennem hurtig feedback, hvorfor det første skabte produkt er skitser, som kan bevise eller afkræfte hypotesen. (Forfatteren bygger på Eric Ries' arbejde “The Lean Startup”).
Brugerrejsen kortet hjælper med at etablere kommunikation, hvis implementeringen gennemføres af flere teams. Hvad skal være på kortet? Det, der er nødvendigt for at støtte samtalen. Ikke kun user stories (hvem, hvad, hvorfor), men også idéer, fakta, skitser af grænseflader osv.
Ved at dele kortene på brugerrejsen op i flere vandrette linjer kan arbejdet opdeles i udgivelser — fremhæve det absolut minimale, niveauet for funktionalitet og pyntene.
Vi gennemgår historierne på proceskortet.
Medarbejderen kom til frokost.
Hvad ønsker han? Hastigheden af servicen. At hans frokost allerede venter på bordet eller i det mindste på en bakke. Oups — en overset skridt: medarbejderen besluttede at spise. Han loggede ind i systemet og valgte en business-lunch mulighed. Han så kalorieindholdet og den ernæringsmæssige værdi for at følge sin diæt og ikke tage på. Han så billeder af retterne for at beslutte, om han vil spise der eller ej.
Vil han så gå for at få sin frokost og spise? Eller vil de måske levere frokosten til kontoret? Så er næste skridt i processen at vælge spisested. Han vil gerne se, hvornår det bliver leveret, og hvor meget det vil koste, så han kan vælge, hvor han vil bruge tid og kræfter — på at gå ned eller arbejde. Han vil gerne se fyldningen af caféen for ikke at stå i kø.
Dernæst kom medarbejderen til caféen. Han ønsker at se sin bakke, så han kan tage den og straks gå hen og spise. Caféen vil gerne tage imod penge for at tjene på servicen. Medarbejderen ønsker at bruge minium tid på betalingerne ved caféen for ikke at spilde sin dyrebare tid. Hvordan gør man det? Betaler på forhånd eller efter servicen på afstand. Eller betale i øjeblikket via en kiosk. Hvad er det vigtigste? Hvor mange mennesker er villige til at betale for frokosten med betalingskort? Hvor mange vil stole på at gemme kortnummeret til gentagne betalinger i denne kantine? Uden feltundersøgelse er det uklart, det kræver testning.
I hvert skridt af processen er det nødvendigt at sikre funktionaliteten, for dette skal man tage udgangspunkt i en persona og vælge, hvad der er vigtigst for ham (den berømte trio af vælgere). Gennemgå historien til slut = har skabt en levedygtig løsning.
Dernæst kommer detaljeringen. Kunden ønsker at se fyldningen af caféen for ikke at stå i kø. Hvad vil han konkret se?
Se prognosen for, hvor mange mennesker der vil være om 15 minutter, når han kommer derhen.
Se den gennemsnitlige betjeningstid i caféen og dens dynamik en halv time frem.
Se situationen og dynamikken i optagelsen af bordene.
Hvad hvis prognosesystemet giver et uforståeligt resultat eller stopper med at fungere?
Se køen i caféen via video, samt optagelse af bordene. Hmm, hvorfor ikke gøre dette som det første?!
Forfatteren peger på en lille øvelse til at træne praksis: prøv at forestille dig, hvad du gør om morgenen efter at være vågnet. Et kort = en handling. Sammenlæg kortene (i stedet for at male kaffe – drik en opkvikkende drik), for at fjerne individuelle detaljer, og fokuser på målet, ikke metoden.
For hvem er denne bog – for IT-analytikere og projektledere. Uundgåeligt at læse.
Applikationer
Diskussion og beslutningstagning er effektiv i grupper på 3 til 5 personer.
Skriv på det første kort, hvad der skal udvikles, på det andet – hvad der skal rettes fra det første, på det tredje – hvad der skal rettes fra det første og andet.
Forbered historier som kager – ikke ved at skrive opskriften, men ved at finde ud af, hvem kagen er til, ved hvilken lejlighed, og til hvor mange personer. Hvis man opdeler implementeringen, så ikke i fremstilling af bunde, flødeskum osv., men i fremstilling af små færdige kager.
Softwareudvikling minder om at lave en film, hvor man nøje skal udvikle og forfine manuskriptet, organisere scenen, skuespillerne osv. før optagelserne starter.
Der vil altid være mangel på ressourcer.
20% af indsatsen giver mærkbare resultater, 60% giver ubestemte resultater, 20% af indsatsen er skadelig – derfor er det vigtigt at fokusere på læring og ikke miste modet ved negative resultater.
Kommuniker direkte med brugeren, sæt dig i deres sted. Fokuser på nogle problemer.
Detaljering og udvikling af historien til evaluering er den mest tidskrævende del af scrum, så gør diskussionerne stående i akvarietilstand (3-4 personer diskuterer ved tavlen; hvis nogen ønsker at deltage, så skifter de med en af de diskuterende).
Kilde: habr.com
