Ved mange interviews vil du sikkert blive spurgt om metoder. Dette er ikke det vigtigste eller sværeste spørgsmål, men det ville være rart at have et snydeark. I denne artikel vil vi forsøge at formidle, hvad en udviklingsmetodologi er og sammenligne dem. En softwareudviklingsmetodologi er en proces, der bruges til at udvikle et bestemt produkt, det vil sige, det er en måde at organisere udvikling af et team af udviklere. Der er mange forskellige udviklingsmodeller, som hver definerer sin egen tilgang. Det kan ikke siges, at nogen af dem skal bruges til ethvert projekt. Den rigtige tilgang afhænger helt af situationen. Jeg agter at overveje tre af dem mere detaljeret.
Fordele:
Jeg vil forsøge kort at forklare essensen af metodikken ved hjælp af simple ord, men der er meget terminologi. Jeg tror, det vigtigste er at forstå essensen. Du vil huske terminologien med erfaring. Al udvikling er opdelt i spurter (ofte 2-3 uger). Der er et efterslæb(opgaveliste) for hele udviklingsperioden og for hver enkelt sprint. Hver opgave har sit eget historiepunkt (sværhedsgrad). Hver deltager i processen har en rolle:
Vandfald
Vandfaldsmetoden er en af de ældste og involverer en strengt sekventiel implementering: hver fase skal afsluttes, før den næste begynder. Med andre ord betyder en overgang til næste etape, at arbejdet i den foregående fase er 100 % færdigt. Billedet viser, hvordan det fungerer: Først analyserer vi problemet (dokumenterer opgaver, diskuterer udfordringer), derefter designer vi (projektets struktur tager form på dette stadium), og derefter koder og tester vi. Det er ikke tilladt at vende tilbage til tidligere stadier. Denne tilgang anbefales til små projekter, hvor kravene er kendt på forhånd og næppe vil ændre sig.
- Fuldstændig og konsekvent dokumentation på hvert trin
- Brugervenlighed
- Stabile krav
- Budgetter og deadlines er foruddefinerede
- En stor mængde dokumentation
- Ikke særlig fleksibel
- Klienten kan ikke se en demoversion af produktet
- Ingen mulighed for at gå tilbage
Scrum
Scrum er en softwareudviklingsmetodologi, der deler hele processen op i iterationer. I slutningen af hver interaktion er teamet klar til at levere en demoversion af produktet. Billedet viser, at teamet fortsætter gennem alle udviklingsstadier parallelt, hvilket gør det muligt at have en færdig del af projektet i slutningen af hver iteration.
- Scrum-teamet består af de professionelle (udviklere, testere, designere), der arbejder på et projekt.
- Scrum masteren er den person, der sørger for, at principperne for scrum respekteres.
- Produktejeren er kunden.
- Stand-up – Dette er et kort møde, der afholdes hver dag, hvor alle teammedlemmer deltager. Hver deltager svarer på 3 spørgsmål: Hvad gjorde jeg? Hvad vil jeg gøre? Og hvilke blokeringsproblemer er der?
- Planlægningsmøde – Dette møde afholdes i begyndelsen af spurten. De opgaver, der skal udføres i næste sprint, identificeres på dette møde.
- Retrospektiv - Dette møde afholdes i slutningen af spurten, og dets formål er at identificere, hvad der blev gjort godt, og hvad der kunne forbedres.
- Kunden kan se resultater under udviklingsprocessen
- Daglig overvågning af udviklingsprocessen
- Evne til at foretage justeringer under udvikling
- Etableret kommunikation med alle teammedlemmer
- En lille mængde dokumentation
- Svært at vurdere arbejdskraft og andre omkostninger, der kræves til udvikling
- Svært at identificere flaskehalse før udviklingen starter
- Behovet for at involvere alle i andre teammedlemmers arbejde.
Kanban
Kanban er en metode, der bygger på at visualisere fremskridtene med at løse teamets opgaver. Hovedideen er at reducere antallet af opgaver, der i øjeblikket udføres (i kolonnen "I gang"). I scrum er teamet fokuseret på at gennemføre spurter med succes. I Kanban indtager opgaven den fremtrædende position. Dette er godt for projekter i vedligeholdelsesfasen, hvor den grundlæggende funktionalitet allerede er implementeret, og minimale forbedringer og fejlrettelser er tilbage. I Kanban tildeles opgaver individuelt. En opgave gennemgår alle stadier på tavlen uafhængigt af andre opgaver, og når den er afsluttet, kan den vises for kunden. En Kanban-tavle består af kolonner, som hver repræsenterer en separat udviklingsproces. Nogle kolonner (f.eks. "I gang" ) begrænse antallet af opgaver, de kan varetage. Dette er med til hurtigt og nemt at finde problemområder i opgavefordelingen. Billedet viser et eksempel på netop sådan en tavle. Antallet af kolonner og deres navne kan variere. Jeg vil præsentere de mest almindelige:
- To Do – Listen over opgaver, der skal udføres
- Igangværende – Opgaver, der arbejdes på i øjeblikket
- Kodegennemgang – Opgaver, der er udført og sendt til gennemgang
- I test – Opgaver klar til test
- Udført – Færdige opgaver
- Brugervenlighed
- Synlighed (hjælper med at lokalisere flaskehalse, forenkler forståelsen)
- Høj teaminvolvering i selve processen
- Meget fleksibel udvikling
- En ustabil opgaveliste
- Svært at anvende til langsigtede projekter
- Mangel på hårde deadlines
GO TO FULL VERSION