Är kravhantering fortfarande relevant?

Är kravhantering irrelevant kunskap i den agila era som nu råder? För vissa räcker det med att beskriva sitt problem i en enda mening för att teamet ska kunna ta fram och realisera en lösning i mjukvara.

Är kravhantering fortfarande relevant?

Är kravhantering fortfarande relevant? 3716 2372 C.A.G
Inget alibi för att slippa dokumentera krav

Många är de som använt det agila arbetssättet som ett alibi för att ”slippa” dokumentera sina krav och lösningar genom att hänvisa till det agila manifestets värden.

– ”Working software over comprehensive documentation.”

Men manifestets värden talar inte om att välja bort dokumentation av krav och lösningar, utan pekar enbart ut det faktum att fungerande mjukvara värderas högre än djuplodande dokumentation. Det är först när du visat att mjukvaran fungerar och löser ett av användarens problem som du faktisk gjort ett framsteg. Inte när du beskrivit lösningen, som du tror kommer att lösa användarens problem. Därför ska du sträva efter att få återkoppling så fort som möjligt baserat på fungerande mjukvara.

I den agila världen ersätts delar av dokumentationen  med kommunikation. Man brukar säga att priset man får betala för att vara flexibel och agil är kostnaden för ökad kommunikation, som sker öga mot öga.

– ”The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Men detta innebär inte per automatik att du kan välja bort att nedteckna vissa nivåer av krav. Du behöver förstå  kontexten i vilken du befinner dig för att kunna identifiera en i sammanhanget god nivå för detaljering och formalisering av kraven.

Agila användarberättelser mer än en mening

En användarberättelse består inte av en, utan av tre komponenter. Dessa måste samexistera med varandra för att användarberättelsen ska vara komplett.  De flesta tänker enbart på användarberättelseformatet när de hör termen användarberättelse, men då missar de två av tre komponenter. På engelska brukar man referera till användarberättelsens tre komponenter som 3C: card, confirmation och conversation.

1. Card – Kort
Kortet representerar användarberättelseformatet, vilket ofta skrivs på framsidan av just ett kort (eller post-it), som sedan vandrar över scrum-tavlan under sprintens gång.

-”Som en <användare> vill jag <mål>så att jag kan <värde>.”

Men vad är kortet egentligen? Kortet representerar inget nytt, utan är en omskrivning av det vi tidigare kallat användarkrav; ett högnivåkrav som fokuserar på användarens behov.

2. Confirmation – Bekräftelse
Varje högnivåkrav (läs användarkrav) med god kvalitet skall ha ett eller flera acceptansvillkor kopplade till sig. Dessa villkor fungerar dels som förtydligande av vad som avses med användarberättelsen och dels som en uppsättning villkor som skall uppfyllas för att implementationen av användarberättelsen skall godkännas av kunden/användaren. Inget nytt här heller.

3. Conversation – Konversation
Den tredje delen av en användarberättelse är konversationen. Konversationen är tänkt att ersätta behovet av att formellt dokumentera system- och komponentkrav. Konversationen är alltså tänkt att ersätta två abstraktionsnivåer för krav som traditionellt varit föremål för mycket detaljerad dokumentation. Tanken bakom detta är att hanteringen av krav på dessa nivåer ska gå från att ha varit både långsam och tidskrävande, till att bli snabb, flexibel och effektiv.

Graden av formalisering beror på flera faktorer

Att enbart använda konversationen som ett medel för att identifiera och implementera system- och komponentkrav kan i många fall var otillräckligt. Behovet av att dokumentera kraven beror på flera faktorer och självklart skiljer sig behovet mellan olika organisationer och domäner.

Du och din organisation behöver ta ett medvetet beslut om vilka nivåer och typer av krav som skall dokumenteras och vilka som ej ska dokumenteras. Strategin du bör följa är dock klar enligt de agila värdena och principerna: ”Less is more”. Du bör med andra ord minimera formalisering och dokumentation av kraven för att bibehålla maximal flexibilitet och förmåga att möta förändringar.

Kravspecifikationer  inte alltid nödvändiga

Du kan faktiskt skriva krav utan att skriva krav. Ja du läste rätt! Hur konstigt det än låter. Låt mig förklara. Redan i sin bok ”Extreeme programming explained – embracing change” beskriver Kent Beck under principen ”Mutual benefit” att det är eftersträvansvärt att söka efter ”win-win-win”-situationer, som hjälper dig, dina medarbetare och kunden både nu och i framtiden. Exekverbara kravspecifikationer är ett exempel på en ”win-win-win”-situation. Istället för att skriva ner dina krav i en kravspecifikation formulerar du dem som exekverbara testfall. Dessa typer av testfall är fullt läsbara av någon som inte har kunskap inom programmering eller scriptspråk. Ett exempel på detta är Gherkin-notationen som avvänds i bland annat ramverket Cucumber.

”Feature: search Wikipedia

Scenario: direct search article

Given Enter search term ’User Story’
When Do search
Then Single result is shown for ’User Story'”

Vinsterna med detta angreppssätt är flera:

  • Win – du slipper skriva och underhålla en kravspecifikcation
  • Win- varje gång testfallet exekveras och går igenom vet du att kravet är uppfyllt
  • Win- det krävs ingen teknisk kunskap för att kunna läsa och förstå kravet/testfallet

Ett annat alternativ till formella kravspecifikationer är att använda wiki-sidor. Efter genomförd konversation sammanställer du resultatet på wiki-sidan i form av text, grafik och bilder som sammanfattar vad ni kommit fram till.

Kunskap om kravhantering mer relevant än någonsin

Kunskap inom kravhantering är mer relevant än någonsin samtidigt som målgruppen för denna kunskap har växt. I den agila kontexten behöver alla som ingår i diskussionen ha rätt förutsättningar för detta. Konsekvensen är att hela teamet och produktägare behöver ha en gedigen kunskap inom hantverksdelen av kravhantering för att under konversationen ha förmåga att bryta ner användarkrav till system- och komponentkrav.

Slutsatser

För att lyckas med ditt kravarbete inom teamet behöver du

  • Analysera kontexten och identifiera en strategi för formell dokumentation av krav
  • Identifiera alternativa approacher för att dokumentera kraven med ”win-win-win” i åtankte
  • Säkerställa att teamet har rätt kunskap och förmågor för att bryta ner användarkrav till system- och komponentkrav
Dax att kompetensutveckla

Om du vill utveckla din eller din personals kunskap och förmågor inom kravhantering rekommenderar vi att du tittar närmare på vår kravutbildning, som utgör den grundläggande nivån i IREBs certifieringsprogram. Information om utbildningen hittar du här.

 

Kontaktperson

Johan Meivert

+46 70 532 71 90

johan.meivert@cag.se

    X
    X