Smidig utvikling

"Hei, Amigo!"

"Hei, Bilaabo!"

"I dag skal jeg fortelle deg om hvordan programmer vanligvis utvikles."

"På 1900-tallet, da moderne IT var i sin spede begynnelse, så det ut til at alle trodde at programmering var som konstruksjon eller produksjon."

"Ting gikk vanligvis omtrent slik:"

" Kunden ville forklare hvilken type program han trengte - hva det skal gjøre og hvordan det skal gjøre det."

" Forretningsanalytikere ville lytte til ham og lage en komplett liste over programkrav basert på det han sa."

"Deretter ville prosjektledere dele disse kravene inn i oppgaver, og ville også bestemme hvilken programmerer som ville gjøre hvilken oppgave og i hvilken rekkefølge."

"Så kom programmererne på jobb. Noen ganger jobbet de flere år(!)."

"Da de var ferdige, ble programmet gitt til testere."

" Testerne ville gå gjennom hvert av programmets krav for å bekrefte at de ble implementert og at programmet fungerte som det skulle."

"Hvis noe gikk galt, ville testerne logge feilene og sende dem til programmererne."

"Så ville programmererne fikse feilene og sende det fikse programmet tilbake til testerne. Og syklusen ville gjenta seg."

"Da hovedfeilene ble fikset, ble programmet gitt til kunden."

— Var det egentlig sånn det gikk?

"Vel, selvfølgelig, jeg har forenklet mye, men det er ganske nær hvordan ting ble gjort."

"Og et prosjekt kan virkelig ta et og et halvt til to år å fullføre?"

"Noen ganger, hvis utviklingen av et prosjekt var veldig lang, delte de det opp i separate utgivelser. Hver 3.–6. måned måtte utviklere lage en spesifikk del av programmets funksjonalitet, teste den, fikse alle feilene og vise den til kunde."

"For det første slik at han kunne dele inntrykkene sine. Og for det andre, og enda viktigere, slik at han ville fortsette å betale for programmets utvikling."

"Fortsett å betale?"

"Den gang tok utviklingen ofte 2-3 ganger lengre tid enn planlagt. Og fordi programmerere ofte fikk timelønn, ble programmet 2-3 ganger dyrere. Dessuten ble fordelene også redusert. Tross alt, det kunden ønsker i dag for $100 000 er kanskje ikke nødvendig på 3 år - spesielt til tre ganger prisen."

"Vet kundene ofte nektet å betale?"

"Jepp. De begynte senere å legge til straffer i kontrakten, men dette forbedret ikke situasjonen. Programvareutviklingen trakk seg utover. Og ingen kunne gjøre noe med det selv om de ville."

"Men hvorfor?"

"Vel, for det første er for lite kjent i planleggingsfasen. Oftere enn ikke, i begynnelsen, var det ingen som kunne forutse problemene som programmererne ville møte."

"Men erfarne programmerere burde ha vært i stand til å forutse alt, ikke sant?"

"Kan du se at programmering er et unikt yrke."

"En vanlig arbeider utfører ofte den samme jobben om og om igjen. Urmakere lager klokker, kokker lager mat, lærere underviser, leger behandler, osv."

"Hver av disse fagpersonene gjør stort sett det samme dag ut og dag inn. Som et resultat begynner de å bli bedre og bedre i jobbene sine."

"I programmering er tilnærmingen annerledes. Så snart en programmerer står overfor den samme oppgaven hver dag, skriver han en funksjon, modul eller program for å utføre den, og kommer aldri tilbake til den igjen."

"Hver programmerer løser vanligvis hver oppgave en gang i livet."

"Noe som forskere eller designingeniører som finner opp ting."

"Ah. Vel, hva er den viktigste rollen i et prosjekt?"

"Hmm, hvordan skal jeg svare på det. Det er lett å si hvilken som er den viktigste, men å identifisere den minst viktige er vanskelig."

" Den primære jobben til en tester ( Quality A surance  , QA )  er å overvåke et programs status og rapportere feil umiddelbart. Jo mer og tidligere en tester finner feil, jo mer kan det fikses.  En god tester påvirker produktkvaliteten mer enn en god programmerer gjør det ."

"Hvorfor kan ikke programmerere teste sine egne programmer. Tross alt, vet de ikke bedre enn testere hva som fungerer og ikke fungerer?"

"En god programmerer er rett og slett ikke i stand til å være en god tester. En programmerer vet hvordan programmet fungerer veldig bra, så han eller hun bruker det alltid på en bestemt måte. I motsetning til vanlige brukere som bruker programmet slik de vil. "

"I tillegg tester ikke testerne det som ikke fungerer ennå. Testeren tester funksjonaliteten eller deler av programmet som programmereren sier allerede fungerer nesten perfekt."

"Og når testeren finner tonnevis av feil i den funksjonaliteten, og programmereren fikser dem, så kommer produktet faktisk nærmere perfeksjon."

" Den primære oppgaven til en programmerer ( programvareutvikler ,  utvikler ,  SDE ) er å implementere ny funksjonalitet. Eller, forenklet sagt, å utføre oppgavene som er tildelt ham eller henne. Når programmerere blir tildelt  oppgaver  med nye funksjoner , utfører de dem. Når de blir tildelt feil, fikser de feil."

"Men noen ganger er det mer utfordrende oppgaver, for eksempel å komme opp med arkitekturen for programmet eller deler av det. Jo bedre foreslått arkitektur, jo lettere blir det å få ting gjort i fremtiden."

"Problemet er at arkitekturen må velges helt i begynnelsen, men det er ikke før du er midt i utviklingen at det er klart om du har valgt riktig arkitektur."

"I tillegg, hvis arkitekturen er vellykket og programmet blir bra, vil kunden sannsynligvis ønske å bruke det som grunnlag for nye versjoner av programmet."

"Her er hva jeg kommer til."

"Uansett hvilken arkitektur du velger, vil det alltid være en haug med endringer, tillegg og nye funksjoner som arkitekturen ikke tar hensyn til."

"Her er et godt eksempel."

"En kunde ber deg bygge en 5-etasjers bygning, så du designer en arkitektur og bygger huset."

"Så ber kunden om å legge til en ny historie, og så en til, og så videre."

"Men første etasjes vegger var ikke designet for så mye vekt, og det var heller ikke fundamentet. Så alt må gjøres om."

"Men etter at den 5-etasjers bygningen er ferdig, hva om kunden umiddelbart bestemmer seg for at han vil ha en 50-etasjers bygning?"

"Det ville være lettere å rive den eksisterende strukturen og bygge opp alt fra bunnen av ..."

"Men jeg har ett råd til deg angående arkitektur."

"En applikasjons arkitektur må først og fremst være fleksibel, noe som betyr at du ikke trenger å starte fra bunnen av hvis du bestemmer deg for å gjøre om halvparten av applikasjonen. Denne typen arkitektur kalles vanligvis fleksibel og modulær . "

" Prosjektlederens primære jobb er å ta beslutninger. Prosjektlederen er den som ser helheten og tar beslutninger basert på det perspektivet."

"Anta at det under utviklingen blir klart at en bestemt oppgave ikke blir fullført som planlagt. Prosjektlederen kan da:"

" a)  prøv å forhandle med kunden for å endre oppgaven"

" b)  avsette mer tid til oppgaven"

" c)  få inn mer erfarne programmerere fra andre prosjekter."

"Og det er mange andre muligheter."

"Hvert alternativ krever at du ofrer noe, og lederens jobb er å minimere de totale tapene fra disse ofrene. "

"Anta for eksempel at konkurrenter stjeler hovedprogrammereren ved å tilby ham dobbelt så mye penger."

"Prosjektlederen kan:"

" a)  ikke gjør noe. Programmereren vil forlate, og prosjektet vil sannsynligvis falle bak og pådra seg straff."

" b)  doble lønnen hans. Da vil alle andre på laget også ha høyninger. Hvis du gir dem alle mer penger, vil kostnadene til prosjektet øke og det kan bli ulønnsomt."

" c)  et annet alternativ som du tenker på."

"Jeg skjønner."

"Med en dårlig prosjektleder forlenger et godt team vanligvis et prosjekt, men ikke alltid."

"En god leder med et team av gjennomsnittlige programmerere vil nesten alltid fullføre et prosjekt raskere enn en dårlig leder med et team av utmerkede programmerere."

"Jeg skjønner."

"Ok, la oss ta en liten pause, så fortsetter vi."