abstrakt
Boken er en fortalt algoritme for å gjennomføre utviklingsprosessen fra idé til implementering ved hjelp av smidige teknikker. Prosessen er lagt opp i trinn og ved hvert trinn angis metodene for prosesstrinnet. Forfatteren påpeker at de fleste metodene ikke er originale, uten å påstå at de er originale. Men den gode skrivestilen og en viss integritet i prosessen gjør boken veldig nyttig.
En nøkkelteknikk for kartlegging av brukerhistorier er å strukturere ideer og forestillinger mens brukeren beveger seg gjennom prosessen.
Samtidig kan prosessen beskrives på ulike måter. Du kan bygge trinn etter hvert som du oppnår en nøkkelverdi, eller du kan ganske enkelt ta og forestille deg brukernes arbeidsdag mens den går gjennom ved bruk av systemet. Forfatteren fokuserer på det faktum at prosesser må skisseres, talt i form av en brukerhistorie på et prosesskart, som er det som ga oss navnet brukerhistoriekart.
Hvem trenger det
For IT-analytikere og prosjektledere. En må lese. Enkel og hyggelig å lese, boken er middels stor.
tilbakekalling
I sin enkleste form fungerer det slik.
En besøkende kommer til en kafé, velger retter, legger inn en bestilling, mottar mat, spiser og betaler.
Vi kan skrive krav til hva vi ønsker av systemet på hvert trinn.
Systemet skal vise en liste over retter, hver rett har en sammensetning, vekt og pris og kan legges i handlekurven. Hvorfor er vi sikre på disse kravene? Dette er ikke beskrevet i "standard" kravbeskrivelsen og dette skaper risiko.
Utøvere som ikke forstår hvorfor dette er nødvendig, gjør vanligvis feil. Utøvere som ikke er involvert i prosessen med å lage en idé er ikke involvert i resultatet. Agile sier, la oss først og fremst fokusere ikke på systemet, men på mennesker, på forbrukere, deres oppgaver og mål.
Vi skaper personas, gir dem detaljer for empati, og begynner å fortelle historier fra personens side.
Kontormedarbeider Zakhar gikk til lunsj og vil ha en rask matbit. Hva trenger han? Tanken er at han sannsynligvis vil ha en forretningslunsj. En annen idé er at han vil at systemet skal huske preferansene hans, fordi han er på diett. En annen idé. Han vil ha kaffe med en gang fordi han er vant til å drikke kaffe før lunsj.
Og det er også en virksomhet (en organisasjonskarakter er en karakter som representerer interessene til en organisasjon). Bedrifter ønsker å øke den gjennomsnittlige sjekken, øke frekvensen av kjøp og øke fortjenesten. Tanken er - la oss tilby uvanlige retter av noe kjøkken. En annen idé - la oss introdusere frokost.
Ideer kan og bør konkretiseres, transformeres og presenteres i form av en brukerhistorie. Som ansatt i Zakhar Business Center vil jeg at systemet skal gjenkjenne meg slik at jeg kan motta en meny basert på mine preferanser. Som servitør vil jeg at systemet skal varsle meg når jeg skal nærme meg bordet slik at klienten blir fornøyd med rask service. Og så videre.
Dusinvis av historier. Neste er prioritering og etterslep? Jeff påpeker problemene som oppstår: å bli fast i små detaljer og miste konseptuell forståelse, pluss prioritering av funksjonalitet skaper et fillete bilde på grunn av inkonsekvens med mål.
Forfatterens vei: Vi prioriterer ikke funksjonaliteten, men resultatet = hva brukeren får til slutt.
Et åpenbart ikke-opplagt poeng: prioriteringsøkten gjennomføres ikke av hele teamet, fordi den er ineffektiv, men av tre personer. Den første er ansvarlig for virksomheten, den andre for brukeropplevelse og den tredje for implementering.
La oss velge minimum for å løse ett brukerproblem (minimum mulig løsning).
Vi detaljerer de første prioriterte ideene ved å bruke brukerhistorier, designskisser, begrensninger og forretningsregler på brukerhistoriekartet ved å fortelle og diskutere med teamet hva folk og interessenter trenger i hvert trinn i prosessen. Vi lar de gjenværende ideene være ugranskede i etterslepet av muligheter.
Prosessen er skrevet på kort fra venstre til høyre, med ideer på kort under prosesstrinnene. Det er viktig at veien gjennom hele historien diskuteres sammen med teammedlemmene for å sikre gjensidig forståelse.
Utdyping på denne måten skaper integritet i samsvar med prosesser.
Ideene som mottas må testes. Et ikke-teammedlem tar på personens hatt og lever personens dag i hodet og løser problemet hans. Det er mulig at han ikke ser utviklingen, skaper kort igjen, og teamet oppdager alternativer for seg selv.
Deretter er det detaljering for evaluering. Tre personer er nok til dette. Ansvarlig for brukeropplevelse, utvikler, tester med et favorittspørsmål: "Hva om...".
På hvert trinn følger diskusjonen et prosesskart over brukerens historie, som gjør det mulig å holde brukerens oppgave i tankene for å skape en sammenhengende forståelse.
Er dokumentasjon nødvendig etter forfatterens oppfatning? Ja, jeg trenger det. Men som notater som lar deg huske hva du ble enige om. Å involvere en utenforstående igjen krever diskusjon.
Forfatteren fordyper seg ikke i temaet tilstrekkelig med dokumentasjon, med fokus på behovet for diskusjon. (Ja, dokumentasjon er nødvendig, uansett hvordan folk som ikke har en dyp forståelse av smidig hevder det). Dessuten kan utdyping av bare en del av egenskapene føre til behov for en fullstendig omarbeiding av hele systemet. Forfatteren påpeker risikoen for overdreven utdypning i saken når ideen er feil.
For å eliminere risiko er det nødvendig å raskt få tilbakemelding på produktet som lages for å minimere skaden ved å lage "feil" produkt. Vi laget en skisse av ideen - validerte den med brukeren, skisserte grensesnittprototyper - validerte den med brukeren osv. (Separat er det litt informasjon om hvordan man validerer programprototyper). Målene med å lage programvare, spesielt i det innledende stadiet, er å lære gjennom å motta rask tilbakemelding; følgelig er det første produktet som lages skisser som er i stand til å bevise eller avkrefte en hypotese. (Forfatteren er avhengig av arbeidet til Eric Ries "Startup using Lean methodology").
Et historiekart bidrar til å forbedre kommunikasjonen når implementeringen utføres på tvers av flere team. Hva skal stå på kartet? Hva du trenger for å holde samtalen i gang. Ikke bare en brukerhistorie (hvem, hva, hvorfor), men ideer, fakta, grensesnittskisser, etc...
Ved å dele opp kortene på historiekartet i flere horisontale linjer, kan du dele opp arbeidet i utgivelser – fremhev det minste minimum, et lag med økende funksjonalitet og buer.
Vi forteller historier på prosesskartet.
En ansatt kom til lunsj.
Hva er det han vil? Tjenestehastigheter. Slik at lunsjen hans allerede venter på ham på bordet eller i det minste på et brett. Oops - et savnet skritt: den ansatte ville spise. Han logget på og valgte alternativet for forretningslunsj. Han så kaloriinnholdet og næringsinnholdet for å hjelpe ham med diett og ikke gå opp i vekt. Han så bilder av retten for å bestemme om han ville spise på det stedet eller ikke.
Deretter går han og spiser lunsj og middag? Eller kanskje lunsjen blir levert til kontoret hans? Deretter er trinnet i prosessen å velge et sted å spise. Han vil se når det skal leveres til ham og hvor mye det vil koste, slik at han kan velge hvor han skal bruke tiden og kreftene - gå ned eller på jobb. Han vil se hvor travelt det er på kafeen for ikke å dytte i kø.
Så kom den ansatte til kafeen. Han vil se brettet sitt så han kan ta det og gå rett til middag. Kafeen ønsker å ta imot penger for å tjene penger på service. Den ansatte ønsker å tape et minimum av tid på oppgjør med kafeen, for ikke å kaste bort dyrebar tid ubrukelig. Hvordan gjøre det? Betal på forhånd eller omvendt etter ekstern service. Eller betal på stedet ved hjelp av en kiosk. Hva er det viktigste med dette? Hvor mange er villige til å betale for lunsj med bankkort? Hvor mange vil stole på at denne kantinen lagrer kortnummeret sitt for gjentatte betalinger? Uten feltforskning er det uklart, testing er nødvendig.
På hvert trinn i prosessen må du på en eller annen måte gi funksjonalitet; for dette må du ta en person som grunnlag og velge det som er viktigere for ham (de samme tre velgerne). Fulgte historien til slutten = laget en levedyktig løsning.
Deretter kommer detaljene. Oppdragsgiver ønsker å se hvor travelt det er på kafeen, for ikke å dytte i kø. Hva vil han egentlig?
Se prognosen for hvor mange mennesker det vil være om 15 minutter når han kommer dit
Se gjennomsnittlig servicetid på en kafé og dens dynamikk en halvtime i forveien
Se situasjonen og dynamikken for bordbelegg
Hva om prognosesystemet gir et uklart resultat eller slutter å virke?
Se gjennom video køene i kafeen, samt belegget på bordene. Hmm, hvorfor ikke gjøre det først?!
Forfatteren trekker frem en liten øvelse å øve på: prøv å se for deg hva du gjør om morgenen etter at du har våknet. Ett kort = en handling. Forstørr kortene (i stedet for å male kaffe, drikk en forfriskende drink) for å fjerne individuelle detaljer, ikke fokus på implementeringsmetoden, men på målet.
Hvem er denne boken for: IT-analytikere og prosjektledere. En må lese.
Apps
Diskusjon og beslutningstaking er effektive i grupper på 3 til 5 personer.
Skriv på det første kortet hva som må utvikles, på det andre - korriger det du gjorde i det første, på det tredje - korriger det som ble gjort i det første og andre.
Forbered historier som kaker – ikke ved å skrive ut en oppskrift, men ved å finne ut hvem, til hvilken anledning, og hvor mange personer kaken er til. Hvis vi bryter ned salget, så ville det ikke vært til produksjon av kaker, krem osv., men til produksjon av små ferdigkaker.
Programvareutvikling ligner på å lage en film, når du må nøye utvikle og polere manuset, organisere scenen, skuespillere osv. før filmingen begynner.
Det vil alltid være mangel på ressurser.
20 % av innsatsen gir håndgripelige resultater, 60 % gir uforståelige resultater, 20 % av innsatsen er skadelig - det er derfor det er viktig å fokusere på læring og ikke fortvile i tilfelle et negativt resultat.
Kommuniser direkte med brukeren, kjenn deg selv i hans sko. Fokuser på noen problemer.
Detaljering og utvikling av historien for evaluering er den mest triste delen av scrum, få diskusjonene til å stå opp i akvariemodus (3-4 personer diskuterer i styret, hvis noen vil delta, erstatter han noen).
Kilde: www.habr.com