Hvordan gennemfører vi kravanalysen?

Hvordan ser planlægningsprocessen ud?

Kravanalysen indgår i planlægningsprocessen, som igen bør være som følger:

1. A projekt vision, der beskriver den endelige produkt der skal oprettes.
2. En generel handlingsplan eller idé, der beskriver, hvad der skal gøres for at nå vores mål.
3. Liste over grundlæggende opgaver, der bestemmer stadierne i arbejdet med projektet.
4. Tidsplanlægning, hvor vi definerer, hvad og hvornår der skal leveres.
5. Detaljeret planlægning af individuelle opgaver skabt i fase tre.

Kravanalysen dækker de første tre punkter i planlægningsprocessen.

Projektets vision

På dette tidspunkt bør vi stille os selv nogle grundlæggende spørgsmål:

1. Hvad ønsker vi at gøre?

På dette tidspunkt er vi sikkert allerede klar over, hvad vi stræber efter, og projektideen er for længst præsenteret og gennemtænkt, men det er værd at tænke dybere over det. Måske vil vi opdage nye spørgsmål, som er værd at forklare. Følgende spørgsmål kan være nyttige her:

• Hvilket problem skal dette projekt løse?
• Hvem bliver dens slutbruger?
• Er vi ved at skabe en grænseflade til brugerne? Er der planer om at skabe den i fremtiden? Er der taget stilling til, hvilken type brugerflade vi vil skabe (desktop eller mobil)? Er vi interesserede i RWD?
• Findes der lignende applikationer? Hvad er deres fordele og ulemper?
• Er der lavet nogle indledende designs eller mockups af projektet endnu?
• Er projektet afhængigt af eksterne applikationer? Har de, eller kender vi deres begrænsninger?
• Ved vi noget om den forventede ydelse og sikkerhedsniveauet?

2. Hvad er kravene?

Nu er det tid til at opstille en liste over krav til projektet. Ud over de funktionelle krav specificerer vi dem, der ikke er relateret til funktionaliteter: brugervenlighed, reaktionsevne, hastighed, ydeevne og sikkerhed.

Lad os tjekke, om hvert af kravene opfylder følgende kriterier:

• er komplet - vi har det fulde billede,
• er korrekt - sandfærdig og forventet,
• er gennemførlig - gennemførlig og andre krav ophæver det ikke,
• er nødvendig - den er nødvendig for, at systemet kan fungere, eller kræves af kunden,
• er utvetydig - læsbar og umulig at misforstå,
• er verificerbar - efter implementering er det gennem observation og test muligt at afgøre, om dette krav er opfyldt eller ej.

3. Hvad er det endelige mål?

Det er værd at skabe en simpel visualisering af projektets funktion her. Intet hjælper så meget til at forstå projektets idé som at tegne et grundlæggende flow eller blot skrive på tavlen i punktform, hvad der skal ske. I tilfælde af en applikation med en brugergrænseflade er den ideelle situation at have selv de simpleste mockups.

4. Hvad er prioriteterne?

Ligesom når man bygger et hus, skal IT-projekter starte helt fra bunden og derefter vende sig mod det, man har mest brug for. I begyndelsen er det derfor nødvendigt på basis af listen over krav at specificere en liste over alle mulige funktioner, som et givet projekt skal udføre, og derefter blive enige om, hvilke af dem der har højeste prioritet og skal udføres så hurtigt som muligt, og hvilke der er af "nice-to-have"-typen.

Resultatet af hele projektvisualiseringsfasen bør være et generelt billede af, hvordan projektet skal fungere, hvad enten det er gennem mockups eller det tegnede flow af aktiviteter. Vi bør også modtage en liste over alle mulige funktioner, som et givet projekt skal opfylde, og også vide, hvilken prioritet hver af dem har.

Projektvisualisering er et vigtigt øjeblik under kravanalysen. Den hjælper med at få en grundig forståelse af problemets kerne, og jo bedre materialet er til at illustrere problemet, jo mere effektivt bliver de næste faser af planlægningen.

Handlingsplan

På dette stadie bestemmer vi allerede, hvordan vi forestiller os, at projektet skal fungere som helhed. Det er godt at have et par ideer til implementering, tænke og diskutere hver af dem og fremhæve deres svagheder og styrker. Det er også værd at tegne en valgt idé i detaljer her, hvis ikke alle.

I denne fase er det også tid til at overveje rent teknologiske spørgsmål, ikke kun hvilket sprog eller hvilken ramme projektet skal skrives i, men også hvilke yderligere værktøjer vi får brug for, for eksempel om vi beslutter at bruge AWS stak eller måske noget andet. Hvis vi tøver mellem nogle teknologier eller ikke aner, hvad vi skal bruge, så er det værd at flytte en sådan beslutning i tid og uddelegere den til en forskningsopgave. Det kan vi selvfølgelig kun gøre, hvis den videre planlægning ikke blokeres af den slags forskning. Ellers kan vi trygt knytte dem til opgaverne i sprint.

Vigtigste opgaver

Når vi har fastlagt projektplanen, fortsætter vi med at definere hovedopgaverne, som derefter vil blive diskuteret i detaljer og nedbrudt i mindre opgaver af udviklingsgruppen. hold når du planlægger et nyt sprint. Det er vigtigt at beskrive hver opgave så præcist som muligt.

Sammenfatning

Som tidligere nævnt vil kravanalyseprocessen variere afhængigt af projektets kompleksitet. Der er lettere og sværere problemer, og der er også dem, der allerede er blevet løst af nogen, og helt nye problemer, som du skal stoppe op ved i længere tid. Uanset hvad er der nogle vigtige tips at huske på:

• Kommunikation. Dette er den vigtigste komponent i ethvert projekts livscyklus; alt skal være klart defineret og forklaret.
• Forstå hurtigt problemet. Det er dejligt at få skrevet projektdokumentation, men lad os huske, at den skal være så kortfattet som muligt og ikke fylde tusind sider. Hvert medlem af udviklingsteam skal have adgang til den og skal hurtigt kunne forstå projektets vision.
• Enkelhed frem for alt. Lad os forsøge at gøre det, vi planlægger, så enkelt som muligt, vælge enklere løsninger, der let kan udvikles i fremtiden, eller opgive dem, når behovet opstår.
• Du får ikke brug for den. I betragtning af, at vi i programmeringen styres af YAGNI-princippet, har vi det her i baghovedet og accelererer ikke for meget.
• Ændringer. Lad os ikke være bange for dem; før eller siden får ethvert projekt brug for dem. Lad os heller ikke bilde os selv ind, at det, vi planlægger i dag, vil fungere for evigt. Samtidig skal vi ikke behandle ændringer som noget dårligt og uønsket. Ændringer bør være ensbetydende med forbedringer, og det er det, vi ønsker: at projektet er det bedste.
• Tid. Lad os ikke lade planlægningen tage for lang tid og trække ud i det uendelige. Hvis vi har et problem, der blokerer os, så lad os lede efter løsninger udenfor eller vælge den nemmeste løsning.

Ovenstående aspekter er altid værd at huske på, når man analyserer kravene, og så vil det køre glat og være grundlaget for et velplanlagt projekt.

Læs mere om det:

• Hvad er den bedste projektledelsesmetode til softwareudvikling?
• Codests gode praksis for at bygge software. Vores tilgang til kunderejsen
• En hurtig guide til at opbygge og udvikle din egen markedsplads. Hvad er værd at vide?