Softwareudviklingsmetoder

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.

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

• Fuldstændig og konsekvent dokumentation på hvert trin
• Brugervenlighed
• Stabile krav
• Budgetter og deadlines er foruddefinerede

Ulemper:

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

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

Denne metode er afhængig af kommunikation, så der er et stort antal møder:

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

Fordele:

• 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

Ulemper:

• 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

Fordele:

• Brugervenlighed
• Synlighed (hjælper med at lokalisere flaskehalse, forenkler forståelsen)
• Høj teaminvolvering i selve processen
• Meget fleksibel udvikling

Ulemper:

• En ustabil opgaveliste
• Svært at anvende til langsigtede projekter
• Mangel på hårde deadlines

Et sidste ord om softwareudviklingsmetoder

Folk, der besidder eller stræber efter lederstillinger, skal forstå softwareudviklingsmetoder grundigt, men alle skal i det mindste forstå det grundlæggende. Metoder er en integreret del af udviklingsprocessen og bruges ikke kun i IT-sfæren. Tak fordi du tog dig tid til at læse min artikel. Jeg håber, det var nyttigt for dig. Jeg forsøgte kun at beskrive nøglepunkterne så let tilgængeligt og kortfattet som muligt. Som følge heraf er denne artikel ikke udtømmende. Jeg ville være glad for at høre din mening om det og besvare dine spørgsmål. Alt det bedste!