abstrakt
Boken är en berättad algoritm för att genomföra utvecklingsprocessen från idé till implementering med hjälp av agila tekniker. Processen är upplagd i steg och vid varje steg anges metoderna för processsteget. Författaren påpekar att de flesta av metoderna inte är original, utan att göra anspråk på att vara original. Men den goda skrivstilen och en del integritet i processen gör boken väldigt användbar.
En nyckelteknik för kartläggning av användarberättelser är att strukturera idéer och prestationer när användaren rör sig genom processen.
Samtidigt kan processen beskrivas på olika sätt. Du kan bygga steg när du uppnår ett nyckelvärde, eller så kan du helt enkelt ta och föreställa dig användarnas arbetsdag när den går genom att använda systemet. Författaren fokuserar på att processer behöver beskrivas, talas i form av en användarberättelse på en processkarta, vilket är det som gav oss namnet user story map.
Vem behöver det
För IT-analytiker och projektledare. Ett måste att läsa. Lätt och trevlig att läsa, boken är medelstor.
återkallande
I sin enklaste form fungerar det så här.
En besökare kommer till ett café, väljer rätter, lägger en beställning, tar emot mat, äter och betalar.
Vi kan skriva krav på vad vi vill ha av systemet i varje led.
Systemet ska visa en lista över rätter, varje rätt har en sammansättning, vikt och pris och kan läggas i varukorgen. Varför är vi säkra på dessa krav? Detta beskrivs inte i den ”standardiserade” kravbeskrivningen och det skapar risker.
Artister som inte förstår varför detta är nödvändigt gör oftast fel. Utövare som inte är involverade i processen att skapa en idé är inte involverade i resultatet. Agile säger, låt oss i första hand inte fokusera på systemet, utan på människor, på konsumenter, deras uppgifter och mål.
Vi skapar personas, ger dem detaljer för empati och börjar berätta historier från personens sida.
Kontorsanställde Zakhar gick på lunch och vill ha ett snabbt mellanmål. Vad behöver han? Tanken är att han förmodligen vill ha en affärslunch. En annan idé är att han vill att systemet ska komma ihåg hans preferenser, eftersom han går på diet. En annan idé. Han vill ha kaffe med sig direkt eftersom han är van vid att dricka kaffe innan lunch.
Och det finns också en verksamhet (en organisatorisk karaktär är en karaktär som representerar en organisations intressen). Företag vill öka den genomsnittliga kontrollen, öka frekvensen av inköp och öka vinsten. Tanken är - låt oss erbjuda ovanliga rätter av något kök. En annan idé - låt oss presentera frukost.
Idéer kan och bör konkretiseras, transformeras och presenteras i form av en användarberättelse. Som anställd på Zakhar Business Center vill jag att systemet ska känna igen mig så att jag kan få en meny baserad på mina preferenser. Som servitör vill jag att systemet meddelar mig när jag ska närma mig bordet så att kunden blir nöjd med snabb service. Och så vidare.
Dussintals berättelser. Nästa är prioritering och eftersläpning? Jeff påpekar problemen som uppstår: att fastna i små detaljer och förlora konceptuell förståelse, plus att prioritera funktionalitet skapar en ojämn bild på grund av inkonsekvens med mål.
Författarens väg: Vi prioriterar inte funktionaliteten, utan resultatet = vad användaren får i slutändan.
En uppenbar icke-uppenbar poäng: prioriteringssessionen genomförs inte av hela teamet, eftersom det är ineffektivt, utan av tre personer. Den första är ansvarig för verksamheten, den andra för användarupplevelsen och den tredje för implementeringen.
Låt oss välja ett minimum för att lösa ett användarproblem (minsta möjliga lösning).
Vi beskriver de första prioriterade idéerna med hjälp av användarberättelser, designskisser, begränsningar och affärsregler på kartan över användarberättelser genom att berätta och diskutera med teamet vad människor och intressenter behöver i varje steg i processen. Vi lämnar de återstående idéerna ogranskade i eftersläpningen av möjligheter.
Processen skrivs på kort från vänster till höger, med idéer på kort under processtegen. Det är absolut nödvändigt att vägen genom hela historien diskuteras tillsammans med teammedlemmarna för att säkerställa ömsesidig förståelse.
Utarbetning på detta sätt skapar integritet i överensstämmelse med processer.
De inkomna idéerna måste testas. En icke-teammedlem tar på sig personens hatt och lever personens dag i hans huvud och löser hans problem. Det är möjligt att han inte ser utvecklingen, skapar kort igen, och laget upptäcker alternativ för sig själva.
Sedan finns det detaljer för utvärdering. Tre personer räcker för detta. Ansvarig för användarupplevelse, utvecklare, testare med en favoritfråga: ”Tänk om...”.
I varje steg följer diskussionen en processkarta över användarens historia, vilket gör det möjligt att hålla användarens uppgift i åtanke för att skapa en sammanhängande förståelse.
Är dokumentation nödvändig enligt författarens uppfattning? Ja, jag behöver det. Men som anteckningar som låter dig komma ihåg vad du kommit överens om. Att involvera en utomstående igen kräver diskussion.
Författaren fördjupar sig inte i ämnet tillräcklig dokumentation, utan fokuserar på behovet av diskussion. (Ja, dokumentation behövs, oavsett hur folk som inte har en djup förståelse för agilt hävdar det). Dessutom kan utarbetning av endast en del av kapaciteten leda till behovet av en fullständig omarbetning av hela systemet. Författaren påpekar risken för alltför omfattande bearbetning i fallet när idén är fel.
För att eliminera risker är det nödvändigt att snabbt få feedback på produkten som skapas för att minimera skadorna av att skapa "fel" produkt. Vi gjorde en skiss av idén - validerade den med användaren, skissade gränssnittsprototyper - validerade den med användaren osv. (Separat finns det lite information om hur man validerar programprototyper). Målen med att skapa mjukvara, särskilt i det inledande skedet, är att lära sig genom att få snabb feedback; följaktligen är den första produkten som skapas skisser som kan bevisa eller motbevisa en hypotes. (Författaren förlitar sig på Eric Ries arbete "Startup using Lean methodology").
En berättelsekarta hjälper till att förbättra kommunikationen när implementeringen genomförs i flera team. Vad ska stå på kartan? Vad du behöver för att hålla igång konversationen. Inte bara en användarberättelse (vem, vad, varför), utan idéer, fakta, gränssnittsskisser, etc...
Genom att dela upp korten på historiekartan i flera horisontella linjer kan du dela upp arbetet i releaser - lyft fram det absoluta minimumet, lagret av ökande funktionalitet och pilbågar.
Vi berättar historier på processkartan.
En anställd kom på lunch.
Vad vill han? Servicehastigheter. Så att hans lunch redan väntar på honom på bordet eller åtminstone på en bricka. Oj - ett missat steg: den anställde ville äta. Han loggade in och valde alternativet affärslunch. Han såg kaloriinnehållet och näringsinnehållet för att hjälpa honom att banta och inte gå upp i vikt. Han såg bilder på maträtten för att avgöra om han skulle äta på det stället eller inte.
Nästa, kommer han att gå och äta lunch och middag? Eller kanske lunchen levereras till hans kontor? Sedan är steget i processen att välja en plats att äta. Han vill se när det kommer att levereras till honom och hur mycket det kommer att kosta, så han kan välja var han ska lägga sin tid och energi – att gå ner eller gå till jobbet. Han vill se hur hektiskt caféet är för att inte tränga i köer.
Sedan kom den anställde till kaféet. Han vill se sin bricka så att han kan ta den och gå direkt till middagen. Caféet vill ta emot pengar för att tjäna pengar på service. Den anställde vill förlora ett minimum av tid på uppgörelser med kaféet, för att inte slösa dyrbar tid i onödan. Hur man gör det? Betala i förskott eller vice versa efter service på distans. Eller betala på plats med hjälp av en kiosk. Vad är det viktigaste med detta? Hur många är villiga att betala för lunch med bankkort? Hur många skulle lita på att denna matsal lagrar sitt kortnummer för upprepade betalningar? Utan fältforskning är det oklart, tester behövs.
I varje steg i processen måste du på något sätt tillhandahålla funktionalitet; för detta måste du ta någon person som grund och välja vad som är viktigare för honom (samma tre väljare). Följde historien till slutet = gjorde en hållbar lösning.
Därefter kommer detaljeringen. Kunden vill se hur hektiskt caféet är, för att inte tränga i köer. Vad exakt vill han?
Se prognosen på hur många det kommer att vara om 15 minuter när han kommer dit
Se den genomsnittliga servicetiden på ett café och dess dynamik en halvtimme i förväg
Se situationen och dynamiken för bordsbeläggning
Vad händer om prognossystemet ger ett oklart resultat eller slutar fungera?
Se via video köerna i kaféet, samt beläggningen av bord. Hmm, varför inte göra det först?!
Författaren pekar ut en liten övning att öva på: försök föreställa dig vad du gör på morgonen efter att du har vaknat. Ett kort = en åtgärd. Förstora korten (istället för att mala kaffe, drick en uppiggande drink) för att ta bort individuella detaljer, inte fokusera på implementeringsmetoden utan på målet.
Vem är den här boken för: IT-analytiker och projektledare. Ett måste att läsa.
Appar
Diskussion och beslutsfattande är effektivt i grupper om 3 till 5 personer.
Skriv på det första kortet vad som behöver utvecklas, på det andra - korrigera det du gjorde i det första, på det tredje - korrigera det som gjordes i det första och andra.
Förbered historier som tårtor - inte genom att skriva ut ett recept, utan genom att ta reda på vem, för vilket tillfälle och hur många personer kakan är till för. Om vi bryter ner försäljningen så skulle det inte vara till produktion av kakor, grädde etc., utan till produktion av små färdiga kakor.
Mjukvaruutveckling liknar att göra en film, då man måste noggrant utveckla och putsa manus, organisera scenen, skådespelare etc. innan inspelningen börjar.
Det kommer alltid att råda brist på resurser.
20 % av ansträngningarna ger påtagliga resultat, 60 % ger obegripliga resultat, 20 % av ansträngningarna är skadliga - det är därför det är viktigt att fokusera på lärande och inte misströsta vid ett negativt resultat.
Kommunicera direkt med användaren, känn dig själv i hans skor. Fokusera på några problem.
Att detaljera och utveckla berättelsen för utvärdering är den mest trista delen av scrum, få diskussionerna att stå upp i akvarieläge (3-4 personer diskuterar i styrelsen, om någon vill delta så ersätter han någon).
Källa: will.com