hvorfor maser vi om given, when, then (smidig2010)

Download Hvorfor maser vi om given, when, then (smidig2010)

If you can't read please download the document

Upload: bjorn-nordlund

Post on 24-Jul-2015

538 views

Category:

Technology


4 download

TRANSCRIPT

Hvorfor maser vi om Given(Gitt), When(Nr), Then(S skal)?

Bjrn Nordlund (NETS)

Hei, jeg heter Bjrn og kommer fra NETS som er det som fr het BBS.

For en sjelden gangs skyld startet jeg for litt siden i et prosjekt der kravene ikke var skrevet p forhnd. Man hadde kun en ide/et konsept som man nsket lage.

Det er desverre ikke hverdagskost i vr bransje.

Vi skal lage en elektronisk distribusjonslsning 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 vr produkteier.

Jeg er veldig fornyd med at vi har ftt til stories denne gang, og har lyst til si litt om hva som jeg synes er best med den mten drive produktet fremover p.

Systemet skal trekke ut en liste over faste kunder som ikke har handlet siste 13 mneder og sende det p xml format til printsystemet

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 svrt tungvint og krevde koordinering mellom vr leveranse og deres var jeg litt skeptisk. Og jeg ville vite litt mer om hva de nsket.

Hvorfor?

S jeg spurte hvorfor.

Systemet skal trekke ut en liste over faste kunder som ikke har handlet siste 13 mneder og sende det p xml format til printsystemet

Slik at kundeansvarlig kan f en en liste i onlinesystemet.

Da sa produkteier at de hadde sendt en annen sak til folka p printsystemet om lage en liste fra xml'en vr 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.

Hva om vi lager en online rapport?

Siden vi i vrt 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 vre 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 mtte i arkivet.

Og sant nok, noen lister var plagt ligge i arkivet, men absolutt ikke alle og ikke denne.

Men vi vet fortsatt ikke nok

Men jeg flte fortsatt ikke at jeg skjnte hva de ville ha.

Hvorfor?

S jeg spurte hvorfor en gang til, hva bruker dere listen til?

Systemet skal trekke ut en liste over faste kunder som ikke har handlet siste 13 mneder 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

Vi bruker den til flge opp kunder som vi er i ferd med miste..

Aha!

Ok, da forstr jeg litt mer..

Som kundeansvarlig nsker jeg sende et godt tilbud til kunder som vi holder p misteSlik at vi opprettholder et godt kunde/leverandr forhold

La oss prve formulere dette som en historie!

Gitt at en person tidligere har handlet hos ossNr det er gtt 13 mneder siden siste handelS skal personen f en mail med et godt tilbud

Og gi et par eksempler p hvordan dette skal vre i noen forskjellige scenarier. Frst et normal scenarie...

Gitt at en person tidligere har handlet hos ossOg at personen har krysset av for ikke motta tilbud fra ossNr det er gtt 13 mneder siden siste handelS skal vi ikke sende mail til kunden

Og deretter en annen forretningsregler der kunden kan reservere seg...

Hva om vi lser det med sende en mail automatisk fra en mal?

Basert p dette s kom teamet opp med et forslag om vi ikke kunne automatisere hele jobben?

Ok, men jeg har behov for endre malen av og til!

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 mtte ogs ha mulighet til endre brevet til kunden..

Som en kundeansvarlignsker jeg kunne endre tilbudsbrev malenSlik at kunden alltid fr oppdaterte tilbud fra oss

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.

Det er mange fordeler med presentere krav som stories og scenarier

Felles sprk

Testbare krav

Avslrer krav som ikke er reelle

Lettere prioritere utfra nytte og bruk

Sporbarhet

Context

Her er noen av de fordelene som man fr oppramset.

Prio: se hvilke krav som er mest nyttige prioritere (kanskje vi kan klare oss med et script i frste omgang for kundebrevene, og bygge en mer robust lsning hvis vi fr behovet?)

Sporbarhet: Lettere bevise fremgang - frer til kt tillig og mindre kontrollorganer som styringsgruppe, timefring, burndowns, estimater, prosjektledere, testere etc..

Context: Det gir en kt forstelse om contexten brukeren har

Men viktigst (synes jeg)!

Men jeg synes den aller viktigste rsaken er denne

Frihet til vre kreative og finne de beste lsningene!

Vi som systemutviklere har masse gode ideer til hvordan man kan lse ting.

Vi har lrt oss til vre forsiktige med dette fordi vi har erfart hvor farlig det er nr utviklere lser problemer som ikke eksisterer.

Men s lenge vi er sikre p at vi jobber med ekte problemlsning s m vi ikke vre redde for bruke vr kreativitet og erfaring.

Et brukereksempel sier ikke hvordan!

Det er viktig at et brukeksempel ikke legger for mange fringer om hvordan det skal lses. Vi som systemutviklere br gjre systemdesign og arkitektur.

Det sier hva man nsker oppn!

Vi br styre kunden i uttrykke hva man nsker oppn.

Det trenger ikke engang vre systemet dere lager som skal gjre det!

Av og til er det ikke engang sikkert vi skal lse dette selv, av og til skal vi ikke lse det i det hele tatt. Kanskje excel arket de bruker i dag er godt nok, og akkurat det de nsker? Hvorfor utvikle en ny lsning som er lik eller drligere?

Til slutt

S dette er grunnene til at jeg nsker at kundene og produkteiere beskriver bruken og hva de vil oppn og ikke legger for mye fringer p hvordan vi skal lse det.... Selv om de gjerne m vre med i den fasen og, bare ikke i kravene...

Denne formen for kravstilling er like viktig som tidligereSett av tid

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 br gjres mens utvikling er i gang s m man regne med bruke minst like lang tid som man fr har gjort.

Kravene er uformelle, men de m fortsatt dekke hele systemet

Det er viktig ikke det for overordnet, men dekke alle krav p denne mten.

Krav skal kunne endres underveis

Og selvflgelig er det viktig gjre dette iterativt, og faktisk gi kunden mulighet til endre krav, ikke bare si det..

Krav kan diskuteres, bruk god tid og ta med alle stakeholdere

(stakeholder stories)

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, markedsfrere, kunder etc..

Alle krav kan dekkes p denne mten

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..

Det finnes unntak fra denne regelen

Men jo vi gjr nok det...

Men ikke la for mye g inn i ikke-funksjonelle krav. Ta noen runder og forsk f det til vre en story med noe man nsker oppn..

Men vi trenger ikke lage kunstige historier som:Som en it-direktrnsker jeg at alle bruker oracleSlik at jeg fr optimert lisensavtalen vr..

Bare definer slike krav utenfor, disse kravene er selvsagt ikke bra, men de finnes....

Som en produkteiernsker jeg sporbarhet mellom krav og lsningSlik at jeg blir trygg p at lsningen gjr det den skal

Her er et eksempel p et krav som kan defineres som en story og br vre en story..

Vi diskuterte behovet for testere i vr lsning. Produkteier mtte 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 mtte g god for lsningen. Produkteier kunne for eksempel gjre dette, gitt at han var trygg p at lsningen faktisk gjorde det den skulle.

Easyb

Lim inn rapporten..

Vi har derfor valgt bdd rammeverket easyb til dokumentere sammenhengen mellom krav og test. Vi valgte denne forelpig fordi den virker enklest og ikke gjr mer enn det vi mener er absolutt ndvendig for f en viss sporbarhet og gi denne tryggheten... Jeg diskuterer gjerne med andre om easyb er rette valg....