4. Systemet skal trekke ut en liste over faste kunder som ikke har handlet siste 13 måneder og sende det på
xml format til printsystemet
Slik at kundeansvarlig kan få en en liste i
onlinesystemet.
8. Systemet skal trekke ut en liste over faste kunder som ikke har handlet siste 13 måneder og sende det på
xml format til printsystemet
Slik at kundeansvarlig kan få en printet liste over disse kundene
Slik at kundeansvarlig kan sende en hyggelig
mail med et godt tilbud til disse kundene
10. Som kundeansvarlig
Ønsker jeg å sende et godt tilbud til kunder som
vi holder på å miste
Slik at vi opprettholder et godt kunde/leverandør
forhold
11. Gitt at en person tidligere har handlet hos oss
Når det er gått 13 måneder siden siste handel
Så skal personen få en mail med et godt tilbud
12. Gitt at en person tidligere har handlet hos oss
Og at personen har krysset av for ikke å motta
tilbud fra oss
Når det er gått 13 måneder siden siste handel
Så skal vi ikke sende mail til kunden
13. Hva om vi løser det med å sende en mail
automatisk fra en mal?
14. Ok, men jeg har behov for å endre malen av og til!
15. Som en kundeansvarlig
Ønsker jeg å kunne endre tilbudsbrev malen
Slik at kunden alltid får oppdaterte tilbud fra oss
16. Det er mange fordeler med å presentere krav som
stories og scenarier
● Felles språk
● Testbare krav
● Avslører krav som ikke er reelle
● Lettere å prioritere utfra nytte og bruk
● Sporbarhet
● Context
Hei, jeg heter Bjørn og kommer fra NETS som er det som før het BBS.
For en sjelden gangs skyld startet jeg for litt siden i et prosjekt der kravene ikke var skrevet på forhånd. Man hadde kun en ide/et konsept som man ønsket å lage.
Det er desverre ikke hverdagskost i vår bransje.
Vi skal lage en elektronisk distribusjonsløsning der du kan motta all posten din elektronisk. Nets share er navnet nå tror jeg, og vi skal ha noen piloter fra q1 neste år.
Vi startet opp pent og pyntelig med tre deltidsutviklere, produkteier og en scrummaster. Vi satt oss ned sammen og begynte å snakke om kravene, hva vi skulle lage og hvordan
Denne presentasjonen er egentligen samling av argumenter for å skrive stories, og for å skrive eksempler på given when then format. For å vise poenget med dette for vår produkteier.
Jeg er veldig fornøyd med at vi har fått til stories denne gang, og har lyst til å si litt om hva som jeg synes er best med den måten å drive produktet fremover på.
Ok, jeg starter med litt eksempler for å illustrere poengene. Disse er hentet fra tidligere prosjekter, og i tillegg lettere anonymisert for å passe, men de er basert på virkelige hendelser.
Dette var et forvaltningsoppdrag som typisk ganske upersonlig blir overlevert fra forretningssiden til oss utviklere via et saksbehandlingssystem.
Ok tenkte jeg, det kan vi vel få til, men siden jeg visste av erfaring at integrasjon med printssystemet var svært tungvint og krevde koordinering mellom vår leveranse og deres var jeg litt skeptisk. Og jeg ville vite litt mer om hva de ønsket.
Så jeg spurte hvorfor.
Da sa produkteier at de hadde sendt en annen sak til folka på printsystemet om å lage en liste fra xml'en vår som skulle legges som en pdf i det elektroniske arkivet. Og en tredje sak til portalgjengen om å vise denne listen fra arkivet under lister i et eksisterende skjermbilde de hadde andre lister.
Siden vi i vårt system allerede hadde noen online skjermbilder de var vant til å bruke i andre sammenhenger så spurte jeg om ikke vi bare kunne få generert opp rapporten i et av våre skjermbilder, evt linke det inn fra det vanlige liste skjermbildet de var vant med å bruke, så slapp vi hele runddansen om printsystemet?
Joa, det hadde de ikke tenkt på, de trodde lister måtte i arkivet.
Og sant nok, noen lister var pålagt å ligge i arkivet, men absolutt ikke alle og ikke denne.
Men jeg følte fortsatt ikke at jeg skjønte hva de ville ha.
Så jeg spurte hvorfor en gang til, hva bruker dere listen til?
Vi bruker den til å følge opp kunder som vi er i ferd med å miste..
Ok, da forstår jeg litt mer..
La oss prøve å formulere dette som en historie!
Og gi et par eksempler på hvordan dette skal være i noen forskjellige scenarier. Først et normal scenarie...
Og deretter en annen forretningsregler der kunden kan reservere seg...
Basert på dette så kom teamet opp med et forslag om vi ikke kunne automatisere hele jobben?
Produkteier ble litt engstelig, men også veldig interessert. Og etter noen runder fant vi ut at så lenge det var godt testet kunne de gå med på det, men de måtte også ha mulighet til å endre brevet til kunden..
Så vi kom opp med en ny historie for dette, med en ny funksjonalitet.
Alt i alt ble det nok like mye jobb å implementere dette som å implementere og koordinere 3 avdelinger for å få ut den gamle lista, men for forretningssiden ble det mindre jobb, og vi fikk automatisert en rutine jobb..
Ok, dette var et eksempel med rot i virkeligheten for å illustrere noen av grunnene til at vi vil ha historier som sier hva man ønsker å oppnå, og hvem som ønsker det.
Her er noen av de fordelene som man får oppramset.
Prio: se hvilke krav som er mest nyttige – prioritere (kanskje vi kan klare oss med et script i første omgang for kundebrevene, og bygge en mer robust løsning hvis vi får behovet?)
Sporbarhet: Lettere å «bevise fremgang» - fører til økt tillig og mindre «kontrollorganer» som styringsgruppe, timeføring, burndowns, estimater, prosjektledere, testere etc..
Context: Det gir en økt forståelse om contexten brukeren har
Men jeg synes den aller viktigste årsaken er denne
Vi som systemutviklere har masse gode ideer til hvordan man kan løse ting.
Vi har lært oss til å være forsiktige med dette fordi vi har erfart hvor farlig det er når utviklere løser problemer som ikke eksisterer.
Men så lenge vi er sikre på at vi jobber med ekte problemløsning så må vi ikke være redde for å bruke vår kreativitet og erfaring.
Det er viktig at et brukeksempel ikke legger for mange føringer om hvordan det skal løses. Vi som systemutviklere bør gjøre systemdesign og arkitektur.
Vi bør styre kunden i å uttrykke hva man ønsker å oppnå.
Av og til er det ikke engang sikkert vi skal løse dette selv, av og til skal vi ikke løse det i det hele tatt. Kanskje excel arket de bruker i dag er godt nok, og akkurat det de ønsker? Hvorfor utvikle en ny løsning som er lik eller dårligere?
Så dette er grunnene til at jeg ønsker at kundene og produkteiere beskriver bruken og hva de vil oppnå og ikke legger for mye føringer på hvordan vi skal løse det.... Selv om de gjerne må være med i den fasen og, bare ikke i kravene...
Til slutt vil jeg bare gi noen erfaringer fra dette..
Å lage user stories er kanskje morsommere og mer uformellt, men det må ikke undervurderes. Selv om det bør gjøres mens utvikling er i gang så må man regne med å bruke minst like lang tid som man før har gjort.
Det er viktig å ikke det for overordnet, men å dekke alle krav på denne måten.
Og selvfølgelig er det viktig å gjøre dette iterativt, og faktisk gi kunden mulighet til å endre krav, ikke bare si det..
Vi har også brukt mye tid på å samle alle stakeholders i å diskutere og jobbe med storiene og komme med eksempler. Det er ikke bare en kunde, alle stakholders må med. Som for eksempel drift, vakt, forretningseiere, markedsførere, kunder etc..
Og alle krav kan defineres med stories og eksempler.
Dvs alle krav kan defineres som funksjonelle krav, vi trenger ikke et dokument med ikke-funksjonelle krav..
Men – jo – vi gjør nok det...
Men ikke la for mye gå inn i ikke-funksjonelle krav. Ta noen runder og forsøk å få det til å være en story med noe man ønsker å oppnå..
Men vi trenger ikke lage kunstige historier som:
Som en it-direktør
Ønsker jeg at alle bruker oracle
Slik at jeg får optimert lisensavtalen vår..
Bare definer slike krav utenfor, disse kravene er selvsagt ikke bra, men de finnes....
Her er et eksempel på et krav som kan defineres som en story og bør være en story..
Vi diskuterte behovet for testere i vår løsning. Produkteier måtte ha en form for trygghet og mente at det var bestemt at vi skulle bruke testere. Vi fant vel ut at dette ikke var et krav, men at noen andre enn utviklere måtte gå god for løsningen.
Produkteier kunne for eksempel gjøre dette, gitt at han var trygg på at løsningen faktisk gjorde det den skulle.
Vi har derfor valgt bdd rammeverket easyb til å dokumentere sammenhengen mellom krav og test. Vi valgte denne foreløpig fordi den virker enklest og ikke gjør mer enn det vi mener er absolutt nødvendig for å få en viss sporbarhet og gi denne tryggheten... Jeg diskuterer gjerne med andre om easyb er rette valg....
