Følg disse nøgletrin for at starte et vellykket softwareudviklingsprojekt

Oftere end ikke fanger starten af ​​et projekt dig uforberedt. Du er muligvis på projektteamet fra dag ét, men tidsplanen er stram, og der er ikke nok tid til forberedelse. Endnu værre, du overser måske nogle trin, og det kan komme tilbage for at hjemsøge dig senere.

Projektet starter, men efter et par måneder ender du på et mørkt sted. De irriterende ting, der fik dig frustreret under dine tidligere opgaver, er tilbage.

Hvis det lyder alt for velkendt, er denne artikel noget for dig. Følg disse retningslinjer, når du starter et projekt, og sæt dig op til succes.

Opret klare kommunikationsveje

Fra første dag skal du sørge for, at rollerne er veldefinerede, og at alle ved, hvem der håndterer hvad. Folk vil anmode om adgang til eksterne systemer, bede om afklaringer eller signalere nødsituationer. Uanset scenariet skal du sørge for, at de nøglekontaktpersoner let identificeres. Opbevar disse oplysninger på et velkendt sted og gør dem tilgængelige for alle.

Definer bedste praksis og konventioner

Når projektet starter, skal du ikke starte kodningen med det samme. Hvis du gør det, bliver din codebase oftere end ikke et sammenfiltret rod, som ingen vil røre ved eller vedligeholde.

Tag dig tid til at vurdere dine tidligere erfaringer og identificere, hvad der gik godt, og hvad der ikke gik. Det hjælper dig med at definere, hvordan du ønsker, at ting skal ske for dette nye initiativ. Involver hele holdet i øvelsen, og sørg for at du lytter til, hvad de siger.

Slutresultatet skal være en liste over konventioner og bedste praksis valideret af hele holdet. Følg disse konventioner, og du vil udvikle en meget mere velorganiseret og sammenhængende løsning.

Opret en meningsfuld definition af udført

Hvor mange gange fandt du ud af lige før demoen, at du ikke kan fremvise en funktion, fordi der mangler noget? Jeg ved det for ofte.

Udviklere har tendens til at overveje, at en funktion udføres, når den fungerer på deres lokale maskine. Imidlertid involverer en komplet softwareudviklingscyklus meget mere end det.

Funktionen fungerer muligvis kun på din lokale maskine, så du er nødt til at teste den i mindst et andet miljø. Derefter skal du bede dine jævnaldrende om at gennemgå dit arbejde. Dette sikrer, at acceptkriterierne og kvalitetsstandarderne overholdes.

Det næste trin er at tilføje implementeringstrinnene, så du kan frigive funktionen til demomiljøet. Du bør sætte disse trin sammen i definitionen af ​​udført sammen med ethvert andet relevant trin.

Derefter skal du sørge for, at dit team bruger definitionen af ​​udført som en tjekliste, inden de udfører en opgave. Dette giver dig meget mere tillid til, at en løst billet er, hvad du forventer at være.

Vælg et passende kontinuerligt integrationssystem

Kontinuerlig integration er afgørende for hvert projekt. Du vil være sikker på, at du kan frigive de nye udviklinger med minimal indsats. Heldigvis er der en bred vifte af muligheder på markedet, hvor Jenkins og TeamCity er to af dem. Der er dog et par meget vigtige faktorer, der skal tages i betragtning, når du foretager dette valg.

En af dem er holdets præference, og den anden er prisen på værktøjet. Det er altid klogere at bruge et kontinuerligt integrationsværktøj, som dit team har brugt før. Det betyder, at alle er fortrolige med værktøjet, og at du ikke behøver at lægge ekstra kræfter på at lære et nyt system.

Overse dog ikke prisfaktoren. Hvis dit valgte værktøj er pebret, er projektsponsorerne muligvis ikke villige til at betale for det. Vi ved alle, at dette sker, men det er ikke verdens ende.

Der er masser af kraftfulde kontinuerlige integrationsværktøjer, der er gratis. Tag dig tid til at teste dem, og vælg den bedst egnede til dig.

Vælg dine værktøjer og applikationer

En ting, du vil undgå, er at bruge for mange forskellige værktøjer til at opnå det samme formål. Lad os forestille os, at dit team skal udvikle en REST API.

En af dine mindre erfarne teammedlemmer, John, har brug for hjælp til at teste et slutpunkt til oprettelse af brugere. Han beder Alex om hjælp, som er ivrig efter at hjælpe, indtil hun indser, at John bruger SOAP UI til at teste sine slutpunkter.

Alex, en stor fan af Postman, bruger et par minutter på at forstå, hvordan man bruger værktøjet, men uden for meget succes. Hun giver op efter et par forsøg, så de beslutter at nå ud til George, den mest erfarne fyr på holdet.

George er dog en old-school programmør. Han kan lide at gøre alt fra kommandolinjen, så han beder John omskrive sine API-opkald for at teste dem med cURL. Det er ikke en ideel situation for nogen.

Vi ved, at udviklere elsker at have friheden til at vælge deres egne værktøjer, men det er ikke altid optimalt at arbejde på den måde. På lang sigt vil teamet have mere fordel af at bruge det samme værktøjssæt. Prøv at undgå denne slags situation ved at vælge specifikke værktøjer til hvert formål.

Vær ikke for stiv, lyt til dit teams præferencer, men tag et klart valg. Sørg også for at forklare for alle, hvorfor dette er vigtigt, og få buy-in fra dine jævnaldrende. Når alt kommer til alt, vil du ikke være en kontrolfreak.

Brug versionskontrolsystemer klogt

Versionskontrolsystemer er et must for ethvert softwareprojekt. Du kan ikke udvikle en softwareløsning sammen uden at bruge en. Det er dog ikke nok at vælge et versionskontrolsystem og kommunikere valget til dit team.

Du skal bruge lidt tid på at definere den måde, du ønsker, at systemet skal bruges til dit nye projekt. Et godt udgangspunkt er at sammenligne de eksisterende arbejdsgange og beslutte, hvad der er bedst til din brugssag.

Dernæst skal du validere arbejdsgangen med dit team. Hvis feedbacken er positiv, er chancerne for, at versionskontrolsystemet vil blive brugt som beregnet.

Undgå at have flere dokumentstyringssystemer

En af de mest frustrerende ting er, når du har brug for at finde et stykke information, og du ikke ved, hvor du skal lede efter det. Dette sker normalt, fordi der er for mange steder, hvor det kan være. Det skulle ikke være så kompliceret!

Når din DevOps-fyr vil finde IP til QA-serveren, skal han se på et enkelt sted. For at få dette til at ske skal du vælge et godt dokumentstyringssystem og holde dig til det.

Hold det organiseret og konfronter alle, der forsøger at gemme oplysninger uden for systemet. Alle vil se fordelene i det lange løb, selv de mennesker der bliver råbt på.

Definer de miljøer, der kræves til din løsning

Vi ved alle, at udviklere, testere og virksomheder ikke skal bruge det samme miljø. Men dette aspekt overses normalt i den indledende fase af et projekt.

Du bør begynde at overveje, hvilke miljøer der er nødvendige for dine projekter tidligt. At få godkendelse og konfigurere dem kan tage et stykke tid, så det er bedre at starte så hurtigt som muligt.

Som en retningslinje skal du have mindst fire miljøer: udvikling, brugeraccepteringstest (UAT), iscenesættelse og produktion.

Udviklingsmiljø

Udviklingsmiljøet vil være sandkassen for udviklingsteamet. Derfor er det ikke stabilt på alle tidspunkter, og du kan forvente inkonsekvenser i data.

Miljø til test af brugeraccept

UAT er beregnet til accept af brugerne, så det er her forretningsfolk udfører deres test.

Iscenesættelses- og produktionsmiljøer

Endelig kommer iscenesættelsen og produktionen hånd i hånd, og de skal spejle hinanden. Dette vil sikre, at de operationer, der køres på iscenesættelse, får de samme resultater på produktionen.

Men hvert projekt er forskelligt. Du har muligvis brug for flere miljøer end ovenstående, ellers kan du ikke have dem alle på grund af de høje omkostninger.

Uanset hvad der er tilfældet, skal du sørge for at overveje systemlandskabet på forhånd og definere, hvad du har brug for, så du kan levere projektet.

Forbered kodebase og projektstruktur

En velorganiseret codebase vil komme langt. Begynd at tage et par proaktive skridt tidligt, så dit projekt ikke snart bliver til en stor mudderkugle.

Du skal definere hovedmodulerne i projektet, kodebasestruktur, filnavngivningskonventioner, emballeringsregler osv.

Gør det så intuitivt som muligt, så det er let for alle at finde de ting, de leder efter. Se også tilbage på lektionen fra tidligere projekter, og sørg for at du ikke gentager de samme fejl.

Opret et dokument til lokal projektopsætning

Selvom du starter med et meget lille hold, er chancerne for, at du ikke vil være den eneste på projekterne. Når nye mennesker er ved at slutte sig til, vil du gøre deres liv så let og muligt og hjælpe dem med at komme op i fart på ingen tid. Dette skal starte med den lokale projektopsætning.

Jeg har set for mange tilfælde, hvor den nye fyr skal bruge en hel uge på at få projektet til at køre på sin maskine. Dette sker normalt, når installationsdokumentationen var dårligt skrevet, ufuldstændig eller manglede helt.

For at undgå dette skal du starte med et dokument, der definerer alle de nødvendige trin til projektopsætningen. Sørg derefter for at teste det på egen hånd og forfine det.

Bed derefter dine jævnaldrende om at gennemgå installationstrinnene og inkorporere deres feedback. Du ender med en kortfattet, let at følge installationsvejledning, der hurtigt får alle i gang.

Afslutter

En ting mere. Behandl ikke dette dokument, da det er skrevet i sten. Gennemgå det fra tid til anden, og glem ikke at medtage nye nødvendige trin, når systemet udvikler sig. Dit team vil takke dig for det.

Dette er et par vigtige ting, du kan gøre for at oprette dit næste projekt til succes. Hvad vil du føje til denne liste? Lad dine tanker være nedenfor.