Før 2000'erne blev softwareudvikling for det meste udført i en vandfaldstilgang. Dette betød, at et softwareprojekt ville blive sendt efter at have gennemgået et par lange faser såsom analyse, udvikling og QA, bare for at nævne nogle få. Dette førte til langsomme softwareudviklingscyklusser, og følgelig blev der truffet forkerte beslutninger i de tidlige stadier af livscyklussen, hvilket førte til dårlig eller uegnet software.
I dag udvikles de fleste store projekter på en agil måde ved hjælp af filosofier som SCRUM eller Extreme Programming. Disse metoder fremmer hurtig softwareudvikling, normalt ved at forkorte cyklusserne og ved ofte at sende.
Ikke desto mindre er nogle brancher stadig afhængige af Waterfall til at levere software, da det stadig er den bedste tilgang til deres mål. Tag f.eks. Aerospace. Hvis du vil lancere en satellit med en vis indbygget kode, kan du ikke installere en opdatering til den, hvis den indbyggede opdateringssoftware er ødelagt.
Dette var også en af grundene til, at vandfaldet var så populært. Forsendelsessoftware var dyrere sammenlignet med, hvordan det gøres i dag, da det normalt involverede magnetisering af en kassette, diskett eller brænding af en cd, før softwaren blev sendt over hele verden for at blive installeret på computere, der aldrig ville få forbindelse i løbet af deres levetid.
Jeg har deltaget i mange projekter og hjulpet flere teams med at sende software, end jeg gerne vil huske. Jeg var heldig at arbejde med virksomheder, der leverer fantastisk software, og andre, der kæmper for at holde tempoet med kvalitet, tidsplan og budget. Jeg har bemærket, at nøglen til at levere fantastisk, forudsigelig software ikke ligger i den metode, du bruger, da nogle gjorde det godt i Agile, mens andre mestrede det i Waterfall. Nøglen til succes var på deres udviklingsprocesser, og nogle havde ikke en skriftlig. Deres produktteam fulgte bare et sæt opgaver for at levere nye ting på en gentagen måde, så de kunne kontrollere, hvor tingene fungerede, og forbedre dem, der ikke fungerede.
Disse processer var forskellige fra team til team, og antallet af trin for at få en funktion udført var normalt ikke det samme. Men alle disse processer havde fælles træk ved, hvordan deres teams nærmede sig udviklingscyklussen. Dette er, hvad de ikke gjorde.
Det er let at blive begejstret for en ny idé, og alle ønsker et øjeblikkeligt stykke af handlingen. At modstå denne fristelse er svært og ofte nøglen til at få tingene gjort hurtigere. Dette er undertiden vanskeligt at forstå, især hvis du er i de første år af din softwareudviklingskarriere.
Hvis du tænker nøje, kan en funktion, der tog en halv dag at definere og et par dage at designe, let tage en uge at implementere. Dette følger den naturlige rækkefølge, hvor tingene er lettere sagt end gjort.
Store teams bruger tid på at analysere et problem og definere en tilgang til at nå en løsning. Der er en balance på, hvor meget du skal bruge i tankefasen, og dette kan afhænge af produktets kritik og omkostningerne ved at sende en ny version. Men gode teams bruger altid tid på at designe en løsning, før de begynder at implementere en ny funktion eller rette en fejl.
Vi har alle været der. Produktejeren siger, at en funktion ikke længere er relevant, du gennemgår koden for at fjerne den, og et par uger senere beder nogen om at tilføje funktionen tilbage. Vi ved aldrig, hvornår den kode, der er ubrugelig nu, vil være nødvendig igen, og at kommentere eller lade den være der virker som en god idé. Død eller kommenteret kode kan ikke skade, ikke? Desuden, hvis vi efterlader koden der, sparer vi tid ved at fjerne behovet for at forstå, om der er andre afhængigheder fra den.
Desværre skaber gammel eller kommenteret kode det, der ofte kaldes Teknisk gæld. I fremtiden vil andre udviklere snuble over den døde kode, og det vil bremse dem. Filer bliver større, koden bliver sværere at læse, og kaos sætter sig.
Der er et bedre alternativ til at undgå at fjerne en fungerende funktion uden at gemme koden et eller andet sted. Med moderne versionskontrolsoftware (dvs. git) det er meget let at identificere, hvornår og hvilke ændringer der blev foretaget, og hente den gamle kode, hvis det er nødvendigt. Der er en god grund til, at værktøjer som git fremhæver, hvor mange kodelinjer der blev slettet i hver commit. Fjernelse af kode er lige så vigtigt som at tilføje en ny.
Ingen taler om dette på college eller universitet, og ingen taler om det i de mange softwareudviklingskurser derude. Men folk, der indsætter sig i produktion, lærer regelmæssigt dette, så snart de begynder at arbejde på deres første projekt, og de hører det ofte på den hårde måde...
Når tingene går surt i produktionen, ringer en persons telefon. Og jeg vedder på, at det er sværere for den person at samle projektteamet og ordne alt i løbet af weekenden end på en hverdag. Nogle mennesker kan endda lide at komme af nettet i weekenden, og held og lykke med at nå dem.
Det er lettere at forklare en produktejer, hvorfor der ikke er nogen udrulninger på fredage eller før helligdage, end at løse et problem uden et funktionelt udviklingsteam, når det sker. Og tro mig, det betyder ikke noget, hvor mange tests du laver, før du sender koden. Hvis du implementerer ofte, vil problemer ramme ventilatoren, når koden er live.
Jeg ser, at mange teams forsømmer testautomatisering. Nogle gange fordi der er manuel QA, andre fordi der simpelthen ikke er nogen tidsplan for at udvikle tests.
Automatiserede tests garanterer, at tingene kører OK, når de implementeres, og sikrer også, at nye funktioner ikke ødelægger gammel kode. Du kan synes at slippe væk uden automatiserede tests, når kodebasen er lille. Koden ældes dog ikke godt, og Onkel Bob skrev en hel bog for at forstærke denne sætning.
Hvis du ikke udvikler automatiserede tests undervejs, vil ændringer være sværere at foretage, folk vil have problemer med at deltage i dit projekt, efterhånden som det vokser, nye funktioner bliver sværere og sværere at implementere, og i sidste ende vil der være så mange fejl i produktionen, at din fejlrapport vokser hurtigere, end du kan implementere programrettelser.
Sørg altid for, at automatiserede tests udføres fra de tidlige stadier af udviklingsindsatsen. Og hvis du spørger „hvor meget er nok“, er du velkommen til at kontrollere min artikel om emnet.
Der er sket meget siden de første tilgange til kontinuerlig integration i slutningen af 90'erne (se Kent Becks berømte Ekstrem programmeringsbog, blandt andre publikationer fra den tid). Men der er stadig mange teams, der ikke anvender denne tilgang fra dag ét og ender med at have manuelle implementeringsprocesser.
Vejen for en funktion eller patch at gå fra en koderepo til produktion skal være en veldefineret og automatiseret proces. Udover at undgå menneskelige fejl giver det naturligvis teamet tillid til at implementere ofte, hvilket giver produktejere mulighed for regelmæssig feedback om den retning, produktet går i, hvilket også forbedrer dets chancer for succes.
En del af dette var allerede dækket, da vi gennemgik, hvorfor automatiserede tests er vigtige, men det var kun en mindre del af QA-processen. Automatiserede tests for sig bare sørg for, at koden testes op til en bestemt dækning og intet mere.
En god QA-proces sikrer, at koden blev verificeret og er gyldig. Disse kaldes ofte verifikations- og valideringsstadierne i QA-proceduren.
For at dette kan implementeres på den rigtige måde, er vi nødt til at sikre, at den person, der skriver koden, ikke er den, der verificerer eller validerer den. Ved at gøre det på denne måde undgås tunnelsynseffekten, der forhindrer folk i at opdage deres egne fejl. Ideelt set bør verifikation (f.eks. kodegennemgang) udføres af en anden udvikler og validering (f.eks. funktionsdemo) af produktejeren.
Et af de store gennembrud i Agile manifest var at sætte „Mennesker over processer“. Dette er faktisk nøglen til at sikre, at vi får det fulde potentiale for hvert eneste medlem af udviklingsteamet. Men at sætte mennesker over processer betyder ikke, at der slet ikke skal være processer. Nogle mennesker siger, at de ikke har processer, men efter at have brugt lidt tid på at arbejde sammen, har de helt sikkert en måde at gøre tingene på. Dette defineres ved at kombinere personlige oplevelser og udvikler sig ved hver iteration, indtil det stabiliserer sig. Det er en gruppes naturlige proces at samle en masse viden om, hvad der fungerer, og hvad der ikke fungerer for dem.
Når du henter en proces fra et andet team, tager du faktisk fat på, hvad de har lært. Processer eksisterer, fordi folk identificerer, hvilke trin eller opgaver der fungerer bedst og i hvilken rækkefølge. Af denne grund er processer viden. Plus alle gode processer udvikler sig, og ændrer sig efterhånden som behovene ændrer sig. Men hvis du skal designe udviklingsprocessen for dit team eller projekt, er den bedste måde at starte med at definere, hvad du allerede gør nu, og derefter krydse med denne liste og se, om du har alle punkter dækket.
Her, på Imaginær sky, vi har altid dette i tankerne, når vi bygger en web- eller mobilapp til vores kunder. Hvis du udvikler et af disse digitale produkter, hjælper vi dig gerne! Send os en linje her!
Fandt du denne artikel nyttig? Du kan måske også lide disse!
CEO @ Imaginary Cloud og medforfatter af bogen Product Design Process. Jeg nyder mad, vin og Krav Maga (ikke nødvendigvis i denne rækkefølge).
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
