Idag har företag som tur är förstått att man ska jobba agilt i digitala utvecklingsprojekt istället för med vattenfallsmodellen, som var vanligt förut. Agil webbutveckling betyder att man anpassar sig till förändrade krav under projektets gång. Den stora nackdelen med vattenfallsmodellen var ju bland annat att de krav man ställde i början av projektet kanske visar sig vara helt fel i slutet av projektet, vilket gör att man får en slutprodukt som inte stämmer överens med det man vill ha. Att göra förändringar sent i ett webbprojekt blir ofta dyrt och medför att tidsplanen blir förskjuten, alltså är det mycket bättre och mer kostnadseffektivt att göra förändringar under projektets gång. Scrum har visat sig vara den mest framgångsrika och populära agila processen.
När man arbetar i Scrum-projekt så har man en product backlog som ofta innehåller mängder med user stories (i mitt senaste projekt där jag agerade Business Analyst hade vi en backlog på över 900 user stories). För att få bra översikt i ett sådant stort projekt, så delade vi upp backloggen i Realese 1, 2, 3, vilket gjorde allt mer greppbart. Nedan är en bild på Scrum-processen (klicka för att förstora).
Något förenklat, så har vi alltså en backlog med massa user stories. Product Owner väljer sen i samråd med Scrum teamet ut vilka user stories utvecklingsteamet ska bygga i kommande sprint. Utvecklingsteamet strukturerar upp arbetet mellan sig och går in i Sprintutvecklingsfasen (vanligtvis utvecklar man i 2-3 veckor i stöten) Under sprinten görs även tester för att sist i sprinten dema funktionaliteten för verksamheten som då godkänner eller kommer med synpunkter på lösningen. Sen börjar allt om igen där man väljer vilka nya user stories som ska byggas i nästa sprint i en iterativ process.
Men åter till kravprocessen. User stories tar man fram som Business Analyst eller Product Owner genom workshops/möten med verksamheten. Först tar man fram epics (övergripande user stories) som man sen bryter ner till user stories. På varje user story skapar man upp acceptance criterias för att tydliggöra för Utvecklingsteamet/testare vad dom ska byggas i sprinten.
När jag har arbetat med att ta fram krav har jag gjort detta enligt följande steg:
1) Workshops/möten med verksamheten för att förstå och ta fram krav. Kraven kommer i detta läge att vara i epics för att få en övergripande bild av hur verksamheten vill ha det.
2) Verksamheten, Business Analyst och Product owner definierar användarroller
3) Business Analyst skriver ner user stories under varje epics
4) Business Analyst synkar user stories per epics med verksamheten
5) Business Analyst skriver ner acceptance criteria på varje user story, som ska vara med i de 3 närmsta sprintarna
6) Business Analyst synkar acceptance criteria med Product owner och utvecklingsteamet för de 3 närmsta sprintarna
7) Utvecklingsteamet bryter ner varje user story i tasks, för att specificera för sig själva hur man ska bygga lösningen samt dela upp arbetet under sprinten.
User stories och acceptance criterias är ett snabbt och effektivt sätt att hantera kravställning utan att behöva skapa formella kravspecifikationer (som få orkar läsa och som ofta blir ett tungt arbete med att sen hålla dessa specar uppdaterade) Det som ersätter specen blir alltså user stories och acceptance criterias.
User stories har blivit en av de mest använda metoderna när det kommer till att kravställa digitala lösningar. En user story är en kort beskrivning av vad en användare vill uppnå. Det finns flera olika sätt att skriva user stories, jag använder alltid denna modellen:
As a <Type of user> I want to <Goal> so that <Reason>
Där:
<Type of user> vem bygger vi för, vem är användaren?
<Goal> Vad ska vi bygga?
<Reason> Vad är anledningen till att bygga detta?
(För mig är <Reason> delen ej nödvändig att ta med (denna tar jag bara med om skälet till att man ska bygga funktionen är luddig)
Exempel: As a Visitor I want to Add products to a wishlist so that I can go back and view them later
Acceptance criterias är påståenden som ska underlätta för utvecklarna och testare.
Dessa påståenden används ofta som ett "definition of done" för att säkerställa att user storyn har blivit korrekt implementerad. Ett acceptance criteria kan antingen vara "pass" eller "fail" (antingen godkänt eller icke godkänt).
Även för Acceptance criterias finns det flera sätt att skriva på. Jag skriver ofta enligt nedan modell:
Verify that <intent>
Exempel på acceptance criterias för wishlist user storyn:
Vanligtvis, för att inte säga alltid, bryter man upp kraven i funktionella krav som beskriver hur systemet interagerar med användarna.
Till exempel ”as an editor I want to be able to upload pdf document”
Där icke funktionella krav är av teknisk karaktär (jag brukar alltid säga ”tekniska krav”) och handlar om systemet. Till exempel prestanda, säkerhet, tillgänglighetskrav och så vidare. Om vi tar exemplet pdf-dokument ovan, så skulle ett icke funktionellt krav kunna vara
”The system shall not take more than X sec to upload a pdf document”
Jag brukar ha för vana att skriva funktionella krav som user stories, och icke funktionella krav brukar jag speca ner i ett tekniskt dokument. Men man kan skriva båda dessa kravtyper som user stories.
När det kommer till ärendehanteringssystem använder jag om möjligt Jira eller nåt liknande (icke funktionella krav lägger jag då i Confluence), men det finns flertalet bra verktyg på marknaden.
Det här var övergripande hur jag brukar arbeta när det kommer till kravhantering i agila webbprojekt och det har visat sig fungera väldigt bra. Så har ni ett projekt där ni till exempel ska byta webbplattform från ett CMS till ett annat, så skulle jag ta in en bra kravställare/Business Analyst och köra enligt Scrum-processen. Det funkar!
