Före 2000-talet gjordes mjukvaruutveckling mestadels i en vattenfallsstrategi. Detta innebar att ett mjukvaruprojekt skulle levereras efter att ha gått igenom några långa steg som analys, utveckling och QA, bara för att nämna några. Detta ledde till långsamma programutvecklingscykler och följaktligen fattades felaktiga beslut i de tidiga stadierna av livscykeln, vilket ledde till dålig eller olämplig programvara.
Numera utvecklas de flesta stora projekt på ett agilt sätt, med hjälp av filosofier som SCRUM eller Extreme Programming. Dessa metoder främjar snabb mjukvaruutveckling, vanligtvis genom att förkorta cyklerna och genom att skicka ofta.
Ändå är vissa branscher fortfarande beroende av Waterfall för att leverera programvara, eftersom det fortfarande är det bästa tillvägagångssättet för deras mål. Ta Aerospace, till exempel. Om du ska starta en satellit med viss kod ombord kommer du inte att kunna distribuera en uppdatering till den om den inbyggda uppdateringsprogramvaran är trasig.
Detta var också en av anledningarna till att Waterfall var så populärt. Leveransprogramvara var dyrare jämfört med hur det görs idag, eftersom det vanligtvis innebar magnetisering av en kassett, diskett eller bränning av en CD innan programvaran skickades över hela världen för att installeras på datorer som aldrig skulle få en anslutning under sin livstid.
Jag har deltagit i många projekt och hjälpt fler team att skicka programvara än jag skulle vilja komma ihåg. Jag hade turen att arbeta med företag som levererar bra programvara och andra som kämpar för att hålla takten på kvalitet, schema och budget. Jag har märkt att nyckeln till att leverera bra, förutsägbar programvara inte ligger i den metod som du använder, eftersom vissa gjorde det bra i Agile medan andra behärskade det i Waterfall. Nyckeln till framgång låg på deras utvecklingsprocesser, och vissa hade inte en skriftlig. Deras produktteam följde bara en uppsättning uppgifter för att leverera nya saker på ett repetitivt sätt, så att de kunde kontrollera var saker fungerade och förbättra de som inte var det.
Dessa processer skilde sig från team till team, och antalet steg för att få en funktion gjort var vanligtvis inte detsamma. Men alla dessa processer hade gemensamma drag för hur deras team närmade sig utvecklingscykeln. Det här är vad de inte gjorde.
Det är lätt att bli upphetsad med en ny idé och alla vill ha en omedelbar del av handlingen. Att motstå denna frestelse är svårt och ofta nyckeln till att få saker gjorda snabbare. Detta är ibland svårt att förstå, särskilt om du är i de första åren av din mjukvaruutvecklingskarriär.
Om du tänker noga kan en funktion som tog en halv dag att definiera och ett par dagar att designa lätt ta en vecka att implementera. Detta följer den naturliga ordningen där saker är lättare sagt än gjort.
Stora team spenderar tid på att analysera ett problem och definiera ett tillvägagångssätt för att nå en lösning. Det finns en balans på hur mycket du ska spendera i tankefasen, och detta kan bero på produktens kritik och kostnaden för att skicka en ny version. Men bra team spenderar alltid tid på att utforma en lösning innan de börjar implementera en ny funktion eller fixar ett fel.
Vi har alla varit där. Produktägaren säger att en funktion inte är relevant längre, du går igenom koden för att ta bort den, och några veckor senare ber någon att lägga till funktionen tillbaka. Vi vet aldrig när koden som är värdelös nu kommer att behövas igen, och att kommentera eller lämna den där verkar som en bra idé. Död eller kommenterad kod kan inte skada, eller hur? Dessutom, om vi lämnar koden där, sparar vi tid genom att ta bort behovet av att förstå om det finns andra beroenden från den.
Tyvärr skapar gammal eller kommenterad kod det som ofta kallas Teknisk skuld. I framtiden kommer andra utvecklare att snubbla på den döda koden och det kommer att sakta ner dem. Filer blir större, koden blir svårare att läsa och kaos löser sig.
Det finns ett bättre alternativ för att undvika att eliminera en fungerande funktion utan att lagra koden någonstans. Med modern versionshanteringsprogramvara (dvs. git) det är väldigt enkelt att identifiera när och vilka ändringar som gjordes, och hämta den gamla koden om det behövs. Det finns en bra anledning till att verktyg som git markerar hur många rader kod som raderades i varje commit. Att ta bort kod är lika viktigt som att lägga till en ny.
Ingen talar om detta på college eller universitet, och ingen talar om det i de många programutvecklingskurserna där ute. Men människor som använder sig till produktion lär sig regelbundet detta så snart de börjar arbeta med sitt första projekt, och de hör det ofta på det hårda sättet...
När saker går surt i produktionen kommer någons telefon att ringa. Och jag slår vad om att det är svårare för den personen att samla projektteamet och fixa allt under helgen än på en vardag. Vissa människor gillar till och med att komma ur nätet på helgerna, och lycka till att nå dem.
Det är lättare att förklara för en produktägare varför det inte finns några distributioner på fredagar eller före helgdagar, än att åtgärda ett problem utan ett funktionellt utvecklingsteam när det händer. Och tro mig, det spelar ingen roll hur många tester du gör innan du skickar koden. Om du distribuerar ofta kommer problem att drabba fläkten när koden är live.
Jag ser att många team försummar testautomatisering. Ibland för att det finns manuell QA, andra eftersom det helt enkelt inte finns något schema för att utveckla tester.
Automatiserade tester garanterar att saker och ting körs OK när de distribueras, och säkerställer också att nya funktioner inte bryter gammal kod. Du kan tyckas komma undan utan automatiserade tester när kodbasen är liten. i alla fall, koden åldras inte bra, och Farbror Bob Skrev en hel bok för att förstärka denna mening.
Om du inte utvecklar automatiska tester under tiden kommer ändringar att bli svårare att göra, människor kommer att ha problem med att gå med i ditt projekt när det växer, nya funktioner blir svårare och svårare att distribuera och i slutändan kommer det att finnas så många buggar i produktionen att din felrapport kommer att växa snabbare än du kan distribuera korrigeringar.
Se alltid till att automatiserade tester görs från de tidiga stadierna av utvecklingsarbetet. Och om du frågar ”hur mycket är tillräckligt”, känn dig fri att kontrollera min artikel om ämnet.
Mycket har hänt sedan de första tillvägagångssätten för kontinuerlig integration i slutet av 90-talet (se Kent Becks berömda Extrem programmeringsbok, bland andra publikationer från den tiden). Men det finns fortfarande många team som inte använder detta tillvägagångssätt från dag ett och slutar med manuella distributionsprocesser.
Vägen för en funktion eller patch att gå från en kodrepo till produktion bör vara en väldefinierad och automatiserad process. Förutom att undvika mänskliga fel ger det självförtroende för teamet att distribuera ofta, vilket gör att produktägare kan få regelbunden feedback om i vilken riktning produkten går, vilket också förbättrar dess chanser att lyckas.
En del av detta var redan täckt när vi gick igenom varför automatiserade tester är viktiga, men det var bara en mindre del av QA-processen. Automatiserade tester för sig se bara till att koden testas upp till en viss täckning och inget mer.
En bra QA-process säkerställer att koden verifierades och är giltig. Dessa kallas ofta verifierings- och valideringsstegen i QA-förfarandet.
För att detta ska kunna implementeras på rätt sätt måste vi se till att personen som skriver koden inte är den som verifierar eller validerar den. Genom att göra det på detta sätt undviks tunnelsynseffekten, som hindrar människor från att upptäcka sina egna misstag. Helst bör verifiering (t.ex. kodgranskning) göras av en annan utvecklare och validering (t.ex. funktionsdemo) av produktägaren.
Ett av de stora genombrotten i Agilt manifest var att sätta ”Människor över processer”. Detta är faktiskt nyckeln till att säkerställa att vi får den fulla potentialen hos varje medlem i utvecklingsteamet. Men att sätta människor över processer betyder inte att det inte borde finnas processer alls. Vissa människor säger att de inte har processer men efter att ha spenderat lite tid på att arbeta tillsammans har de säkert ett sätt att göra saker. Detta definieras genom att kombinera personliga erfarenheter och utvecklas på varje iteration tills det stabiliseras. Det är den naturliga processen för en grupp att samla mycket kunskap om vad som fungerar och vad som inte fungerar för dem.
När du hämtar en process från ett annat team tar du faktiskt grepp om vad de har lärt sig. Processer existerar eftersom människor identifierar vilka steg eller uppgifter som fungerar bäst och i vilken ordning. Av denna anledning är processer kunskap. Plus att alla bra processer utvecklas och förändras när behoven förändras. Men om du ska utforma utvecklingsprocessen för ditt team eller projekt är det bästa sättet att börja med att definiera vad du redan gör nu, och sedan korscheck med den här listan och se om du har alla punkter täckta.
Här, på Imaginärt moln, vi har alltid detta i åtanke när vi bygger en webb- eller mobilapp för våra kunder. Om du utvecklar en av dessa digitala produkter hjälper vi dig gärna! Skicka oss en rad här!
Hittade den här artikeln användbar? Du kanske gillar dessa också!
VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
