skrevet af Tobiasz Topczewski, Emil Qvistgaard, Christian Gadgaard
Intro
Velkommen til vores blog indlæg! Vi er en gruppe i SKP (skolepraktik) der har arbejdet med et projekt. Det projekt endte tidligere end forventet på grund af nogle problemer, men nu skriver vi denne blog indlæg for at forhåbentlig give jer et indblik i vores projekt. I kan måske endda lære noget fra vores oplevelse og de ting vi selv har lært fra projektet.
Hvem er vi?
Først og fremmest en lille introduktion om hvem vi er – vi er 3 programmøre fra SKP (skolepraktik) på AarhusTech, hvor vi bliver udannet som programmør. Vi kommer fra forskellige steder i vores uddannelse, som betyder, at vi ikke havde mødt hinanden, før projektet og derfor har forskellige niveauer af erfaring. Det betyder at allerede før projektet, havde vi noget arbejde der skulle udføres. Kort fortalt har vores instruktør tildelt et projekt vi skulle udarbejde. Detaljerne af dette projekt kan findes i den næste sektion.
Hvad var projektet
Vores projekt var at lave et el simulations værktøj til de elever der deltager i DM i fagene. Simulationen skulle indeholde et 9 volts batteri, en modstand og 4 LEDer. Med de komponenter skulle eleverne kunne opstille den mest effektive måde at få de 4 LEDer til at lyse på. Vi fik også et simulationsværktøj vi kunne arbejde ud fra og modificere så det passede til vores projekt.
Hvad sket der med projektet
Vi startede ud med at kigge på den simulation der inspirerede projektet. Den hedder PhET og er udviklet af elever på University of Colorado. Det gav os et godt udgangspunkt på opgaven og gjorde at vi hurtig kunne komme i gang. Da det ikke var os som havde lavet den, skulle den rettes til. Den kom allerede med et 9 volts batteri, ledninger, en modstand hvor man kan ændre modstanden og en lyspære. Den kom også med en andre ting så man kunne se hvad der skete hvis man satte det i et el-kredsløb. Så vi skulle bare slette de ting vi ikke havde brug for og ændre pæren til en led. Vi fandt ud af at der var 29000 filer i projektet og 24 dependencies. Men på trods af det fik vi hurtig slettet det vi ikke havde brug for og ændret pærens billede til en led. Det er her det går ned af bakke, for vi skulle ændre pæren så den opførte sig som en LED i stedet for. Der fandt vi ud af at vi skulle bruge noget der hedder MatLab for at skifte pæren opførsel.
Efter vi fandt ud af at vi skulle bruge MatLab, gik vi i gang med at kigge på andre løsninger til projektet. Den første løsning vi kom på, var at lave det fra bunden, så vi selv havde styr på hvordan systemet fungerede. Det gik også godt i starten og vi lavede sådan at vi kunne flytte elementer rundt på skærmen. Men vi løb ind i problemer med at forbinde komponenter til hinanden. Det prøvede vi på at løse ved at se, om der var andre der har lavet noget lignede det vi skal lave og hvordan de har lavet det. Der fandt vi nogle andre el simulations projekter. De brugte også MatLab til at forbinde og beregne simulationen. Efter det konkluderede vi, at vi ikke havde den nødvendige viden omkring MatLab og kunne derfor ikke lave projektet inden for den deadline vi havde fået.
Start overblik/planlægning
I starten af vores opgave havde vi ikke det bedste overblik over opgaven, da vi ikke have snakket med kunden endnu. Men vi havde fået lidt oplysninger omkring opgaven, blandt andet at vi skulle bruge simulationen fra PhET. Så vi gik i gang med at kigge koden og de dependencies igennem som den brugte. Efter vi havde kigget lidt af koden igennem og kunden havde tid til at komme forbi, havde vi omkring den samme erfaring med simulationen. Det gjorde at vi havde begge vores perspektiver at gå ud fra både fra vores synspunkt som programmører og kunden. Efter det kunne kunden fortælle hans krav til opgaven og vi stille opklarende spørgsmål til opgaven. Efter det første møde kunne vi udarbejde en plan for hvordan vi vil udføre opgaven. Det er vigtigt at have et godt overblik over opgaven før man begynder at lave en opgave. Hvis man ikke har et godt overblik, kan man hurtigt komme på afveje og blive forvirret over opgaven.
Kundemøder
Kundemøder er vigtige for at planlægge hvad man skal lave og for at vise kunden hvor langt man er med opgaven. Men før et kundemøde er det godt at have et overblik over hvad man vil vise og snakke om til mødet. Så vi afholdt typisk et møde en time før kundemødet hvor vi diskuterede i gruppen, hvad vi vil snakke om.
Til kundemødet startede vi med at vise hvor langt vi var kommet med opgaven. Det gjorde vi ved at vise en prototype af vores projekt. Efter det snakkede vi om det var sådan, kunden vil have det og om der var nogle ændringer der skulle fortages. Det næste vi snakkede om, var kundens forventninger til næste møde og hvornår næste møde skulle afholdes. Vi har holdt løbende kundemøde omkring hver uge igennem helle opgaven. Det behøves ikke at være hver uge, men det er også afhængig af hvornår kunden har tid. Det er også her vi begik nogle fejl.
Vi holdt os til kundemøder omkring hver uge, uanset hvad det var vi skulle lave. Det gjorde at vi ikke altid nåde det vi skulle lave til næste kundemøde. Vi afholdte møder hver uge, fordi vi havde lidt af en urealistisk tankegang til af de ting vi skulle lave og det var der kunden havde tid. Det kan være svært at give et realistisk tidsestimat for hvornår man er klar til næste kundemøde, men så må man lave et gæt. Det er også noget man bliver bedre til efterhånden som man får mere erfaring.
Urealistisk tankegang /reality check
Efterhånden som vi har haft mange kundemøder, kunne vi godt se, at vi blev ved med at sætte mål som er svært at opnå. Selvfølgelig blev vi bedre til at sætte realistiske forventninger, og til at estimere hvor meget tid vi har brug for. Men det var ikke nok!
Med vores færdigheder, var vi kun i stand til at ’gætte’ hvordan projektet kørte frem. For hver deadline vi satte for projektet, havde vi også en målpind som krævet at vi tilfældigt finder guld. Det er det som vi internt kalder ”Magisk Tænkning”. Det var f.eks. at finde en linje i eksisterende kode, som gør det muligt at udskifte billede, eller at implementere en feature vi ikke 100% forstår.
Til sidst gik det op for os, at vi ikke har nok tid til at stole på mirakler. Vores sidste kundemøde handlede om at afklare om vi skal holde fast i vores håb for at finde den rigtig løsning i løbet af det næste måned, eller give op på projektet og bruge vores tid på noget mere fornuftig. Det var en hård samtale, og vi var ikke alle sammen klar til at efterlade et halvt færdigt produkt, men vi blev enig om at det er alt for risikabelt.
Fail fast
En af de ting man hører i branchen, er at ‘fail fast’. Det vil sige at man skal afprøve tingene så hurtig man kan, for at se om det kan lade sige gøre. Tankegangen er at man hurtigt kan se hvad der virker og hvad der ikke virker. Det sparer tid for os og for kunden.
I vores tilfælde var det noget vi tænkte over til vores sidste kundemøde. Hvad nu hvis vi fortsat med at arbejde på projektet, og det ikke lykkedes? Så ville vi havde fejlet langsomt, mens slutresultatet ville havde været det samme – et halvfærdigt produkt.
Prototyping / proof of concept
Noget vi kunne have gjort bedere i projektet var at have nogle prototyper. Prototyper eller ’proof of concept’ kunne være noget visuelt eller få en feature til at virke, så kunden kunne se hvad det var vi var i gang med. Det vil også give et beder overblik over hvor vi var i processen. Men i vores opgave var vi lidt over det hele og hoppede fra ting til ting og derfor havde aldrig rigtig noget nyt at vise når der var kundemøder.
Motivation
Motivation kan være svært at holde oppe hele tiden i et projekt, specielt hvis man ikke kan få det til at gøre som man vil. Motivation var også noget der gik fra op og ned i vores projekt.
I starten af vores projekt var vi meget motiveret. Det så lidt svært ud og virkede lidt uoverskueligt, men vi fik hurtig slettet de ting vi skulle og fik pæren skiftet til en led. Efter det var vi meget motiveret og det føltes som om vi kunne klare alting. Men efter det, brugte vi lang tid på at få pæren til at opføre sig som en led og jo længer tid det tog faldt vores motivation mere og mere. Efter vi droppede den første simulation og gik over til at lave det fra bunden fik vi en del motivation tilbage. Nu kunne vi lave det som vi ville og have kontrol over alting selv. Den motivation, vi havde fået igennem starten af det nye projekt faldt, da vi ikke kunne finde ud af hvordan vi skulle forbinde komponenterne igen.
Tips til at holde motivationen oppe i et projekt
Nogle tips til at holde motivationen oppe i et projekt. Have nogle små delopgaver så man kan se at det går frem af med opgaven.
- Skriv de delopgaver ned, det giver også et bedre overblik og status på opgaven. Husk at strege ting over på listen så man kan se hvor lang man er kommet med opgaven.
- Lav opgaven i en gruppe så i kan snakke om opgaven og hjælpe hinanden.
- Gå nogle ture og kom væk fra projektet en gang i mellem.
Være ærlig over jer selv om hvordan det går med projektet og lad vær med at sætte for store mål, det er fint at udfordre sig selv, men en for stor udfordring kan gøre det svært at fortsætte med projektet hvis man ikke kan se en løsning til det.
Konklusion
Vi nåede desværre ikke det vi skulle lave inden for den deadline, men vi har fået en masse erfaring ud af at forsøge at lave denne opgave. Nogle ting vi har lært at overføre til andre projekter i fremtiden, er at undersøge opgaven mere grundigt og gå efter princippet fail fast, så vi hurtigere kan se hvad der virker og ikke virker.
Vi har lært at holde kundemøder. Det er første gang vi har prøvet det. Der har vi også lærte, er at det er vigtigt at have realistiske deadlines til næste møde og have en prototype klar til at vise kunden.
Vi har lært at det kan være farligt at have et urealistisk syn og magisk syn på opgaven. For man kan ikke altid finde nogle der har lavet det man har brug for på internettet.
Til Slut
Vi håber at I har kunne få noget ud af vores erfaring med at lave en opgave for en kunde og har fået lidt mere forståelse for hvad der virker og ikke virker.
