Agil utveckling

"Hej, Amigo!"

"Hej, Bilaabo!"

"Idag ska jag berätta om hur program brukar utvecklas."

"På 1900-talet, när modern IT var i sin linda, verkade alla tro att programmering var som konstruktion eller tillverkning."

"Det gick vanligtvis ungefär så här:"

" Kunden skulle förklara vilken typ av program han behövde - vad det ska göra och hur det ska göra det."

" Affärsanalytiker skulle lyssna på honom och göra en komplett lista över programkrav baserat på vad han sa."

"Då skulle projektledare dela upp dessa krav i uppgifter och skulle också bestämma vilken programmerare som skulle göra vilken uppgift och i vilken ordning."

"Då skulle programmerarna börja jobba. Ibland jobbade de flera år(!)."

"När de var klara gavs programmet till testare."

"Testarna skulle gå igenom vart och ett av programmets krav för att verifiera att de implementerades och att programmet fungerade som det var tänkt. "

"Om något gick fel skulle testarna logga felen och skicka dem till programmerarna."

"Då skulle programmerarna fixa buggarna och skicka tillbaka det fixade programmet till testarna. Och cykeln skulle upprepas."

"När de huvudsakliga buggarna fixades gavs programmet till kunden."

"Det var verkligen så det gick?"

— Jo, det är klart, jag har förenklat mycket, men det är ganska nära hur saker och ting gjordes.

"Och ett projekt kan verkligen ta ett och ett halvt till två år att slutföra?"

"Ibland om ett projekts utveckling var riktigt lång, delade de upp det i separata utgåvor. Var 3-6 månad måste utvecklare skapa en specifik del av programmets funktionalitet, testa det, fixa alla dess buggar och visa det för kund."

"För det första så att han kunde dela med sig av sina intryck. Och för det andra, och ännu viktigare, så att han skulle fortsätta att betala för programmets utveckling."

"Fortsätt betala?"

"Då tog utvecklingen ofta 2-3 gånger längre tid än planerat. Och eftersom programmerare ofta fick timlön blev programmet 2-3 gånger dyrare. Dessutom minskade fördelarna också. Trots allt vad kunden vill ha idag för $100 000 kanske inte behövs på 3 år - speciellt till tre gånger priset."

"Vejrade kunderna ofta att betala?"

"Japp. De började senare lägga till straffavgifter i kontraktet, men det här förbättrade inte situationen. Mjukvaruutvecklingen drog ut på tiden. Och ingen kunde göra något åt ​​det även om de ville."

"Men varför?"

"Tja, för det första är för lite känt under planeringsstadiet. Oftare än inte, i början, kunde ingen förutse de problem som programmerarna skulle ställas inför."

"Men erfarna programmerare borde ha kunnat förutse allt, eller hur?"

"Kan du se att programmering är ett unikt yrke."

"En vanlig arbetare utför ofta samma jobb om och om igen. Urmakare gör klockor, kockar lagar mat, lärare undervisar, läkare behandlar, etc."

"Var och en av dessa proffs gör i princip samma sak dag ut och dag in. Som ett resultat börjar de bli bättre och bättre på sina jobb."

"Inom programmering är tillvägagångssättet annorlunda. Så fort en programmerare står inför samma uppgift varje dag, skriver han en funktion, modul eller ett program för att utföra det, och kommer aldrig tillbaka till det igen."

"Varje programmerare löser vanligtvis varje uppgift en gång under sin livstid."

"Något som vetenskapsmän eller designingenjörer som uppfinner saker."

"Ah. Ja, vilken är den viktigaste rollen i ett projekt?"

"Hmm, hur ska jag svara på det. Det är lätt att säga vilken som är viktigast, men att identifiera den minst viktiga är svårt."

" En testares primära uppgift ( Quality A surance  , QA )  är att övervaka ett programs status och rapportera buggar omedelbart. Ju mer och tidigare en testare hittar buggar, desto mer kan det åtgärdas.  En bra testare påverkar produktkvaliteten mer än en bra programmerare gör det ."

"Varför kan inte programmerare testa sina egna program. När allt kommer omkring, vet de inte bättre än testare vad som fungerar och inte fungerar?"

"En bra programmerare är helt enkelt oförmögen att vara en bra testare. En programmerare vet hur programmet fungerar riktigt bra, så han eller hon använder det alltid på ett visst sätt. Till skillnad från vanliga användare som använder programmet hur de vill. "

"Dessutom testar inte testare det som inte fungerar ännu. Testaren testar funktionaliteten eller delar av programmet som programmeraren säger redan fungerar nästan perfekt."

"Och när testaren hittar massor av buggar i den funktionen, och programmeraren fixar dem, kommer produkten faktiskt närmare perfektion."

" Den primära uppgiften för en programmerare ( programvaruutvecklare  , utvecklare  ,  SDE ) är att implementera ny funktionalitet. Eller, förenklat, att utföra de uppgifter som tilldelats honom eller henne. När programmerare tilldelas  uppgifter med nya funktioner , de utför dem. När de tilldelas buggar fixar de buggar."

"Men ibland finns det mer utmanande uppgifter, till exempel att komma på arkitekturen för programmet eller delar av det. Ju bättre den föreslagna arkitekturen är, desto lättare blir det att få saker gjorda i framtiden."

"Problemet är att arkitekturen måste väljas redan i början, men det är inte förrän man är mitt uppe i utvecklingen som det är klart om man valt rätt arkitektur."

"Dessutom, om arkitekturen är framgångsrik och programmet blir bra, kommer kunden förmodligen att vilja använda det som grund för nya versioner av programmet."

"Det här är vad jag menar."

"Oavsett vilken arkitektur du väljer kommer det alltid att finnas en massa ändringar, tillägg och nya funktioner som arkitekturen inte tar hänsyn till."

"Här är ett bra exempel."

"En kund ber dig bygga en 5-våningsbyggnad, så du designar en arkitektur och bygger huset."

"Då ber kunden att få lägga till en berättelse till, och sedan en till och så vidare."

"Men första våningens väggar var inte konstruerade för så mycket vikt, och det var inte grunden heller. Så allt måste göras om."

"Men efter att byggnaden med 5 våningar är klar, tänk om kunden omedelbart bestämmer sig för att han vill ha en byggnad på 50 våningar?"

"Det skulle vara lättare att riva den befintliga strukturen och bygga om allt från grunden..."

"Men jag har ett råd till dig angående arkitektur."

"En applikations arkitektur måste först och främst vara flexibel, vilket innebär att du inte behöver börja om från början om du bestämmer dig för att göra om hälften av applikationen. Den här typen av arkitektur brukar kallas flexibel och modulär . "

" Projektledarens primära uppgift är att fatta beslut. Projektledaren är den som ser helheten och fattar beslut utifrån det perspektivet."

"Anta att det under utvecklingen blir tydligt att en viss uppgift inte kommer att slutföras som planerat. Projektledaren kan då:"

" a)  försök att förhandla med kunden för att ändra uppgiften"

" b)  avsätta mer tid till uppgiften"

" c)  ta in mer erfarna programmerare från andra projekt."

"Och det finns många andra möjligheter."

"Varje alternativ kräver att du offra något, och chefens jobb är att minimera de totala förlusterna från dessa uppoffringar. "

"Anta till exempel att konkurrenter stjäl den ledande programmeraren genom att erbjuda honom dubbelt så mycket pengar."

"Projektledaren kan:"

" a)  gör ingenting. Programmeraren kommer att lämna och projektet kommer sannolikt att hamna på efterkälken och drabbas av straff."

" b)  dubbla hans lön. Då kommer alla andra i laget också att vilja ha höjningar. Om du ger dem alla mer pengar kommer projektets kostnader att öka och det kan bli olönsamt."

" c)  något annat alternativ som du tänker på."

"Jag förstår."

"Med en dålig projektledare förlänger ett bra team vanligtvis ett projekt, men inte alltid."

"En bra chef med ett team av genomsnittliga programmerare kommer nästan alltid att slutföra ett projekt snabbare än en dålig chef med ett team av utmärkta programmerare."

"Jag förstår."

"Okej, låt oss ta en kort paus, så fortsätter vi."