abstrakt
Bogen er en fortalt algoritme til at udføre udviklingsprocessen fra idé til implementering ved hjælp af agile teknikker. Processen er opbygget i trin og ved hvert trin er metoderne til procestrinnet angivet. Forfatteren påpeger, at de fleste af metoderne ikke er originale, uden at hævde at være originale. Men den gode skrivestil og en vis integritet i processen gør bogen meget brugbar.
En nøgleteknik til kortlægning af brugerhistorier er at strukturere ideer og forestillinger, efterhånden som brugeren bevæger sig gennem processen.
Samtidig kan processen beskrives på forskellige måder. Du kan bygge trin, efterhånden som du opnår en nøgleværdi, eller du kan blot tage og forestille dig brugernes arbejdsdag, mens den går igennem ved hjælp af systemet. Forfatteren fokuserer på, at processer skal skitseres, talt i form af en brugerhistorie på et proceskort, hvilket er det, der har givet os navnet user story map.
Hvem har brug for det
Til IT-analytikere og projektledere. Et must at læse. Nem og fornøjelig at læse, bogen er mellemstor.
tilbagekaldelse
I sin enkleste form fungerer det sådan.
En besøgende kommer til en cafe, vælger retter, bestiller, modtager mad, spiser og betaler.
Vi kan skrive krav til, hvad vi ønsker af systemet på hvert trin.
Systemet skal vise en liste over retter, hver ret har en sammensætning, vægt og pris og kunne lægges i indkøbskurven. Hvorfor er vi sikre på disse krav? Dette er ikke beskrevet i "standard" kravbeskrivelsen, og det skaber risici.
Udøvere, der ikke forstår, hvorfor dette er nødvendigt, gør normalt det forkerte. Udøvere, der ikke er involveret i processen med at skabe en idé, er ikke involveret i resultatet. Agile siger, lad os primært ikke fokusere på systemet, men på mennesker, på forbrugerne, deres opgaver og mål.
Vi skaber personas, giver dem detaljer for empati og begynder at fortælle historier fra personas side.
Kontormedarbejder Zakhar gik til frokost og vil have en hurtig snack. Hvad har han brug for? Tanken er, at han nok vil have en forretningsfrokost. En anden idé er, at han vil have systemet til at huske hans præferencer, fordi han er på diæt. En anden idé. Han vil have kaffe bragt til ham med det samme, fordi han er vant til at drikke kaffe før frokost.
Og der er også en virksomhed (en organisatorisk karakter er en karakter, der repræsenterer en organisations interesser). Virksomheder ønsker at øge den gennemsnitlige check, øge hyppigheden af køb og øge fortjenesten. Ideen er - lad os tilbyde usædvanlige retter af et eller andet køkken. En anden idé - lad os introducere morgenmad.
Idéer kan og bør konkretiseres, transformeres og præsenteres i form af en brugerhistorie. Som ansat i Zakhar Business Center ønsker jeg, at systemet genkender mig, så jeg kan modtage en menu baseret på mine præferencer. Som tjener ønsker jeg, at systemet giver mig besked, hvornår jeg skal henvende mig til bordet, så kunden bliver tilfreds med hurtig betjening. Og så videre.
Dusinvis af historier. Næste er prioritering og efterslæb? Jeff påpeger de problemer, der opstår: at blive hængende i små detaljer og miste begrebsforståelse, plus prioritering af funktionalitet skaber et ujævnt billede på grund af inkonsekvens med mål.
Forfatterens vej: Vi prioriterer ikke funktionaliteten, men resultatet = hvad brugeren får i sidste ende.
En åbenlys ikke-oplagt pointe: prioriteringssessionen udføres ikke af hele teamet, fordi den er ineffektiv, men af tre personer. Den første er ansvarlig for forretning, den anden for brugeroplevelse og den tredje for implementering.
Lad os vælge minimum for at løse et brugerproblem (minimum levedygtig løsning).
Vi detaljerer de første prioriterede ideer ved hjælp af brugerhistorier, designskitser, begrænsninger og forretningsregler på brugerhistoriekortet ved at fortælle og diskutere med teamet, hvad folk og interessenter har brug for i hvert trin af processen. Vi efterlader de resterende ideer uundersøgte i efterslæbet af muligheder.
Processen er skrevet på kort fra venstre mod højre, med ideer på kort under procestrinene. Det er bydende nødvendigt, at vejen gennem hele historien diskuteres sammen med teammedlemmerne for at sikre gensidig forståelse.
Uddybning på denne måde skaber integritet i overensstemmelse med processer.
De modtagne ideer skal testes. Et ikke-teammedlem tager personens hat på og lever personens dag i hovedet og løser hans problem. Det er muligt, at han ikke ser udviklingen, skaber kort igen, og holdet opdager alternativer for sig selv.
Så er der detaljer til evaluering. Tre personer er nok til dette. Ansvarlig for brugeroplevelse, udvikler, tester med et yndlingsspørgsmål: "Hvad nu hvis...".
På hvert trin følger diskussionen et proceskort over brugerens historie, som gør det muligt at holde brugerens opgave for øje for at skabe en sammenhængende forståelse.
Er dokumentation nødvendig efter forfatterens mening? Ja, jeg har brug for det. Men som noter, der giver dig mulighed for at huske, hvad du aftalte. At inddrage en outsider igen kræver diskussion.
Forfatteren går ikke i dybden med spørgsmålet om tilstrækkelig dokumentation og fokuserer på behovet for diskussion. (Ja, dokumentation er nødvendig, uanset hvordan folk, der ikke har en dyb forståelse af agile, hævder det). Desuden kan uddybning af kun en del af mulighederne føre til behovet for en fuldstændig omarbejdning af hele systemet. Forfatteren påpeger risikoen for overdreven uddybning i sagen, når ideen er forkert.
For at eliminere risici er det nødvendigt hurtigt at modtage feedback på produktet, der oprettes, for at minimere skaden ved at skabe det "forkerte" produkt. Vi lavede en skitse af ideen - validerede den med brugeren, skitserede interfaceprototyper - validerede den med brugeren osv. (Separat er der lidt information om, hvordan man validerer programprototyper). Målene med at skabe software, især i den indledende fase, er læring gennem at modtage hurtig feedback; derfor er det første produkt, der skabes, skitser, der er i stand til at bevise eller modbevise en hypotese. (Forfatteren er afhængig af Eric Ries' arbejde "Startup using Lean methodology").
Et historiekort hjælper med at forbedre kommunikationen, når implementeringen udføres på tværs af flere teams. Hvad skal være på kortet? Hvad du skal bruge for at holde samtalen i gang. Ikke kun en brugerhistorie (hvem, hvad, hvorfor), men ideer, fakta, grænsefladeskitser osv...
Ved at opdele kortene på historiekortet i flere vandrette linjer, kan du opdele værket i udgivelser - fremhæve det absolutte minimum, et lag af stigende funktionalitet og sløjfer.
Vi fortæller historier på proceskortet.
En medarbejder kom til frokost.
Hvad vil han have? Servicehastigheder. Så hans frokost allerede venter på ham på bordet eller i det mindste på en bakke. Ups - et misset skridt: medarbejderen ville spise. Han loggede ind og valgte forretningsfrokost. Han så kalorieindholdet og næringsindholdet for at hjælpe ham med at diæte og ikke tage på i vægt. Han så billeder af retten for at beslutte, om han ville spise det sted eller ej.
Dernæst, vil han gå og spise frokost og aftensmad? Eller måske bliver frokosten leveret til hans kontor? Derefter er processens trin at vælge et sted at spise. Han vil gerne se, hvornår det bliver leveret til ham, og hvor meget det vil koste, så han kan vælge, hvor han vil bruge sin tid og energi – at gå nedenunder eller på arbejde. Han vil gerne se, hvor travlt der er på cafeen for ikke at skubbe i kø.
Så kom medarbejderen på cafeen. Han vil gerne se sin bakke, så han kan tage den og gå direkte til middag. Cafeen vil gerne tage imod penge for at tjene penge på service. Medarbejderen ønsker at miste et minimum af tid på afregninger med cafeen, for ikke at spilde kostbar tid ubrugeligt. Hvordan gør man det? Betal forud eller omvendt efter fjernbetjening. Eller betal på stedet ved hjælp af en kiosk. Hvad er det vigtigste ved dette? Hvor mange mennesker er villige til at betale for frokost med et bankkort? Hvor mange mennesker ville stole på, at denne kantine gemmer deres kortnummer til gentagne betalinger? Uden feltforskning er det uklart, test er nødvendigt.
På hvert trin i processen skal du på en eller anden måde levere funktionalitet; for dette skal du tage en person som grundlag og vælge, hvad der er vigtigere for ham (de samme tre vælgere). Fulgte historien til ende = lavet en holdbar løsning.
Dernæst kommer detaljeringen. Kunden vil gerne se, hvor travlt cafeen er, for ikke at skubbe i kø. Hvad vil han helt præcist?
Se prognosen for, hvor mange mennesker der vil være om 15 minutter, når han når dertil
Se den gennemsnitlige servicetid på en cafe og dens dynamik en halv time i forvejen
Se situationen og dynamikken for bordbelægning
Hvad hvis prognosesystemet giver et uklart resultat eller holder op med at virke?
Se gennem video køerne i cafeen, samt belægningen af borde. Hmm, hvorfor ikke gøre det først?!
Forfatteren påpeger en lille øvelse at øve sig på: prøv at forestille dig, hvad du laver om morgenen efter at være vågnet. Et kort = en handling. Forstør kortene (i stedet for at male kaffe, drik en forfriskende drink) for at fjerne individuelle detaljer, ikke fokus på implementeringsmetoden, men på målet.
Hvem er denne bog til: IT-analytikere og projektledere. Et must at læse.
Apps
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 - ret hvad du gjorde i det første, på det tredje - ret hvad der blev gjort i det første og andet.
Forbered historier som kager - ikke ved at skrive en opskrift, men ved at finde ud af hvem, til hvilken lejlighed, og hvor mange mennesker kagen er til. Hvis vi opdeler salget, så ville det ikke være til produktion af kager, fløde osv., men til produktion af små færdige kager.
Softwareudvikling svarer til at lave en film, hvor du skal omhyggeligt udvikle og polere manuskriptet, organisere scenen, skuespillere osv. før optagelserne begynder.
Der vil altid være mangel på ressourcer.
20% af indsatsen giver håndgribelige resultater, 60% giver uforståelige resultater, 20% af indsatsen er skadelig - derfor er det vigtigt at fokusere på læring og ikke fortvivle i tilfælde af et negativt resultat.
Kommuniker direkte med brugeren, mærk dig selv i hans sko. Fokuser på nogle problemer.
At detaljere og udvikle historien til evaluering er den mest kedelige del af scrum, få diskussionerne til at stå op i akvarietilstand (3-4 personer diskuterer i bestyrelsen, hvis nogen vil deltage, erstatter han nogen).
Kilde: www.habr.com