Agil udvikling

"Hej, Amigo!"

"Hej, Bilaabo!"

"I dag vil jeg fortælle dig om, hvordan programmer normalt udvikles."

"I det 20. århundrede, da moderne IT var i sin vorden, syntes alle at tro, at programmering var som konstruktion eller fremstilling."

"Tingene gik normalt sådan her:"

" Kunden ville forklare den type program, han havde brug for - hvad det skulle gøre, og hvordan det skulle gøre det."

" Forretningsanalytikere ville lytte til ham og lave en komplet liste over programkrav baseret på, hvad han sagde."

"Så ville projektledere opdele disse krav i opgaver og ville også bestemme, hvilken programmør der ville udføre hvilken opgave og i hvilken rækkefølge."

"Så kom programmørerne i gang. Nogle gange arbejdede de i flere år(!)."

"Da de var færdige, blev programmet givet til testere."

" Testerne ville gennemgå hvert af programmets krav for at verificere, at de blev implementeret, og at programmet fungerede, som det skulle."

"Hvis noget gik galt, ville testerne logge fejlene og sende dem til programmørerne."

"Så ville programmørerne rette fejlene og sende det rettede program tilbage til testerne. Og cyklussen ville gentage sig."

"Da de vigtigste fejl blev rettet, blev programmet givet til kunden."

"Sådan gik det egentlig?"

"Jamen, selvfølgelig har jeg forenklet meget, men det er ret tæt på, hvordan tingene blev gjort."

"Og et projekt kunne virkelig tage halvandet til to år at gennemføre?"

"Nogle gange, hvis et projekts udvikling var virkelig lang, ville de opdele det i separate udgivelser. Hver 3.-6. måned skulle udviklere oprette en specifik del af programmets funktionalitet, teste det, rette alle dets fejl og vise det til kunde."

"Først for at han kunne dele sine indtryk. Og for det andet, og endnu vigtigere, så han ville blive ved med at betale for programmets udvikling."

"Bliv ved med at betale?"

"Dengang tog udviklingen ofte 2-3 gange længere tid end planlagt. Og fordi programmører ofte fik timelønnet, blev programmet 2-3 gange dyrere. Desuden blev fordelene også reduceret. Trods alt, hvad kunden ønsker i dag for 100.000 $ er det måske ikke nødvendigt om 3 år - især til tre gange prisen."

"Nægtede kunderne ofte at betale?"

"Jep. De begyndte senere at tilføje bøder til kontrakten, men det forbedrede ikke situationen. Softwareudviklingen trak ud og ved. Og ingen kunne gøre noget ved det, selvom de ville."

"Men hvorfor?"

"Tja, for det første er for lidt kendt i planlægningsfasen. Oftere end ikke, i begyndelsen var der ingen, der kunne forudsige de problemer, som programmørerne ville stå over for."

"Men erfarne programmører burde have været i stand til at forudse alt, ikke?"

"Kan du se, at programmering er et unikt erhverv."

"En almindelig arbejder udfører ofte det samme arbejde igen og igen. Urmagere laver ure, kokke laver mad, lærere underviser, læger behandler osv."

"Hver af disse fagfolk gør stort set det samme dag ud og dag ind. Som følge heraf begynder de at blive bedre og bedre til deres job."

"I programmering er tilgangen anderledes. Så snart en programmør står over for den samme opgave hver dag, skriver han en funktion, et modul eller et program for at udføre det, og kommer aldrig tilbage til det igen."

"Hver programmør løser normalt hver opgave én gang i hans eller hendes levetid."

"Noget som videnskabsmænd eller designingeniører, der opfinder ting."

"Ah. Nå, hvad er den vigtigste rolle i et projekt?"

"Hmm, hvordan skal jeg svare på det. Det er nemt at sige, hvad der er det vigtigste, men at identificere det mindst vigtige er svært."

" En testers primære opgave ( Quality A surance  , QA )  er at overvåge et programs status og rapportere fejl omgående. Jo mere og tidligere en tester finder fejl, jo mere kan det rettes.  En god tester påvirker produktkvaliteten mere end en god programmør gør ."

"Hvorfor kan programmører ikke teste deres egne programmer. Ved de trods alt ikke bedre end testere, hvad der virker og ikke virker?"

"En god programmør er simpelthen ikke i stand til at være en god tester. En programmør ved, hvordan programmet fungerer rigtig godt, så han eller hun bruger det altid på en bestemt måde. I modsætning til almindelige brugere, der bruger programmet, som de vil. "

"Derudover tester testere ikke, hvad der ikke virker endnu. Testeren tester funktionaliteten eller dele af programmet, som programmøren siger allerede fungerer næsten perfekt."

"Og når testeren finder tonsvis af fejl i den funktionalitet, og programmøren retter dem, så kommer produktet faktisk tættere på perfektion."

" Den primære opgave for en programmør ( softwareudvikler ingeniør, udvikler , SDE  )  er at  implementere ny funktionalitet. Eller sagt mere enkelt at udføre de opgaver, der er tildelt ham eller hende. Når programmører tildeles opgaver med nye funktioner  , udfører de dem. Når de får tildelt fejl, retter de fejl."

"Men nogle gange er der mere udfordrende opgaver, for eksempel at komme med arkitekturen til programmet eller dele af det. Jo bedre den foreslåede arkitektur er, jo lettere bliver det at få tingene gjort i fremtiden."

"Problemet er, at arkitekturen skal vælges helt i starten, men det er først, når man er midt i udviklingen, at det står klart, om man har valgt den rigtige arkitektur."

"Derudover, hvis arkitekturen er vellykket, og programmet bliver godt, så vil kunden formentlig gerne bruge det som grundlag for nye versioner af programmet."

"Her er, hvad jeg kommer til."

"Uanset hvilken arkitektur du vælger, vil der altid være en masse ændringer, tilføjelser og nye funktioner, som arkitekturen ikke tager højde for."

"Her er et godt eksempel."

"En kunde beder dig bygge en 5-etagers bygning, så du designer en arkitektur og bygger huset."

"Så beder kunden om at tilføje endnu en historie, og så endnu en, og så videre."

"Men første sals vægge var ikke designet til så meget vægt, og det var fundamentet heller ikke. Så alt skal laves om."

"Men når den 5-etagers bygning er færdig, hvad nu hvis kunden straks beslutter, at han vil have en 50-etagers bygning?"

"Det ville være nemmere at rive den eksisterende struktur ned og genopbygge alt fra bunden..."

"Men jeg har et råd til dig angående arkitektur."

"En applikations arkitektur skal først og fremmest være fleksibel, hvilket betyder, at du ikke skal starte fra bunden, hvis du beslutter dig for at lave halvdelen af ​​applikationen om. Denne type arkitektur kaldes normalt fleksibel og modulær . "

" Projektlederens primære opgave er at træffe beslutninger. Projektlederen er den, der ser det store billede og træffer beslutninger ud fra det perspektiv."

"Antag, at det under udviklingen bliver klart, at en bestemt opgave ikke bliver løst som planlagt. Projektlederen kan derefter:"

" a)  prøv at forhandle med kunden om at ændre opgaven"

" b)  afsætte mere tid til opgaven"

" c)  anbring mere erfarne programmører fra andre projekter."

"Og der er mange andre muligheder."

"Hver mulighed kræver, at du ofrer noget, og lederens opgave er at minimere de samlede tab fra disse ofre. "

"Antag for eksempel, at konkurrenter stjæler den førende programmør ved at tilbyde ham dobbelt så mange penge."

"Projektlederen kan:"

" a)  gør ingenting. Programmøren vil forlade, og projektet vil sandsynligvis komme bagud og pådrage sig sanktioner."

" b)  fordoble hans løn. Så vil alle andre på holdet også have lønforhøjelser. Hvis du giver dem alle flere penge, så vil projektets omkostninger stige, og det kan blive urentabelt."

" c)  en anden mulighed, som du tænker på."

"Jeg ser."

"Med en dårlig projektleder forlænger et godt team normalt et projekt, men ikke altid."

"En god leder med et team af gennemsnitlige programmører vil næsten altid fuldføre et projekt hurtigere end en dårlig leder med et team af fremragende programmører."

"Jeg ser."

"Okay, lad os holde en kort pause, og så fortsætter vi."