TDP003 Projekt: Egna datormiljön

Reflektionsdokument

Individuell skriftlig reflektion

Att genomföra ett projekt och nå ett lyckat resultat betyder inte nödvändigtvis att allt gick bra på vägen. En del saker blev säkert fel. Andra saker tog onödigt lång tid. Några saker var ni osams om hur ni skulle lösa. Planeringen visade sig allt för optimistisk och du gjorde ofta vad som kändes rätt för stunden istället, och större delen av arbetet hamnade i sista veckan. Allt det där är helt okej.

Men du kommer att göra fler projekt. I de ska du inte göra om samma misstag (men kanske andra misstag). Då gäller det att komma ihåg vad du gjorde, hur du gjorde, vad resultatet blev, hur lång tid det tog, om det var tillräckligt bra eller borde gjorts bättre, om det var onödigt och tiden kunde använts bättre till något annat, hur du med allt i färskt minne tror du borde gjort istället. Och sist men inte minst svara på VARFÖR för alla punkter ovan. Varför gjorde du som du gjorde, varför tog det lång tid, varför var det inte bra nog, varför kunde tiden använts bättre, varför skulle du göra på annat sätt?

Lät det negativt? Blev mycket du gjorde rätt och bra? Då gäller det att komma ihåg vad du gjorde, hur du gjorde, hur bra resultatet blev, hur kort tid det tog, att du hade god nytta av resultatet, varför det var väl spenderad tid, hur du kunde ha gjort och varför det varit sämre. Naturligtvis med svar på VARFÖR allt blev så bra.

Målet med reflektionen är att kunna läsa den när allt är glömt och ändå förstå vilka bra och dåliga saker som gjordes, och kunna dra lärdom av det. Du skriver för dig själv, för att i nästa projekt göra allt snabbare med högre kvalité. Men att skriva för sig själv kan vara svårt - i skrivande stund vet du ju allt och glömmer lätt skriva ned det. Det är inte förrän du senare läser som du undrar varför du inte skrev ned mer motiv och bakgrund. Därför kan du istället tänka dig att du skriver för dem som går kursen nästa år, och vill ge dem så mycket information och så många välmotiverade tips som möjligt. (Din reflektion kommer enbart att läsas av kurspersonal om inte Du ger den till någon annan, men tänk att den skall vara läsvärd även för en oinsatt.)

Observera till slut att reflektionsdokumentet inte är en kursvärdering, utan en slags självvärdering av ditt egna arbete och samarbete. Det är alltså vad du gjort och inte gjort, och vad du själv kan lära av det som dokumenteras.

Har du synpunkter om kursen är mycket välkommmen att skriva en kursreflektion eller vad vi kan kalla det, men skriv då ett eget dokument med det. Även kursen kan säkerligen bli både bättre och sämre, och du sitter i bästa position att tala om det.

Inlämning

Varje person skriver ett eget reflektionsdokument individuellt. Reflektionsdokumentet lämnas in via e-post till er assistent. Skicka från er LiU-mail och med ämne TDP003: Reflektionsdokument.

Krav på din individuella reflektion

Genom hela kursen har du fört dagbok om vad du gjort. Låt den ligga till grund för reflektionen. Har du en bra dagbok behöver du bara sammanställa det bästa ur den till ett snyggt dokument.
Inled med att beskriva hur du och din kompis arbetat, vad har du bidragit med och vad bidrog kompisen med.
Varje sak du tar upp skall förklara hur och varför det gjordes, vad resultatet blev och varför det blev så, vad du tror kan bli bättre eller kunde blivit sämre.
Det skall finnas både positiva och negativa erfarenheter.
Det skall ingå erfarenheter av den teknik ni använt.
Det skall ingå erfarenheter av hur det är att samarbeta.
Försök hitta erfarenheter som du har nytta av i nästa projekt.
Du skall relatera minst tre erfarenheter till vad som skrivs i Code Complete. Använd korrekta källhänvisningar i harvard-stil.
Avsluta med några tankar om hur du tycker projektet som helhet gick. Är du nöjd med resultatet? Är du nöjd med det du lärt dig?

Riktlinjer för din individuella reflektion

Det skall finnas information om författare, datum, dokumentversion, projektnamn, kurs och totalt antal sidor (dessa saker är bra att ha med i en dokumentmall, t.ex. i sidhuvud/sidfot på varje sida).
Inlämning sker som pdf med höga krav på språk och tydlig layout. Korrekturläs. Använd flera rubriknivåer. Sätt tydliga relevanta rubriker. Använd bilder och figurer för att förtydliga eller exemplifiera det som beskrivs i text. Numrera figurer och tabeller och hänvisa i texten så bilden ingår i den röda tråden. Formatera konsekvent kod, filnamn, eller andra typer av nyckelord med en annan font. Infoga innehållsförteckning om det är motiverat utifrån sidantalet, färre än fem sidor behöver sällan förteckning, det är lätt hitta ändå.

Bedömningspukter och vanliga brister för din individuella reflektion

Här kommer feedback på rapporterna i gemensam form. Samtidigt skriver jag ned konkreta specifikationer på vad jag vill se.

Varje punkt nedan är kopplad listan på krav ovan. Här kommer en lista med förslag på saker som är bra att tänka igenom (utvärdera) vid erfarenhetsdokumentation och reflektion.

Hur påverkar arbetssättet eller tekniken:

möjligheten att dela upp arbetet på olika personer?
möjligheten att dela upp arbetet efter kompetens?
total tidsåtgång att lösa problemet?
möjligheten att arbeta effektivt?
kvalitén på lösningen?
möjligheten för utomstående att snabbt anamma strukturen?

Några har skrivit på ett sätt som försöker få allt som gjorts att verka bra och dölja att ni inte alls gjort så som ni bör. Tänk på att målet är att göra fel och lära av det, så var ärliga med hur ni gjort och hur det gick. Att arbeta på fel sätt eller ineffektivt eller vad det nu kan vara tycker jag är helt okej om ni kan se bristerna i det och komma fram till bättre metoder. Att försköna något ni inte är helt nöjda med tycker jag däremot är helt fel. Bättre erkänna att "det var dumt" och vara efterklok inför nästa försök. Ni behöver inte försvara vad ni gjort och inte gjort i denna kurs, utan är här för att lära.

Undvik att ta med obearbetad rådata från dagboken. Enstaka citat är okej. Om rådata är viktigt, lägg som bilaga till dokumentet.
Det som brukar saknas är konkreta klargöranden om hur arbetet fördelats, t.ex. "vi har inte planerat vem som skall göra vad, utan tagit det som det kommer" eller "vi har fördelat veckans uppgifter under ett snabbt möte varje måndag". Därpå önskas egna tankar om fördelar och nackdelar ni upplevt med ert arbetssätt, och därpå jämförelse med vad som sägs i litteraturen.

Jag vill se en fördel och en nackdel med hur ni arbetat.
De flesta lyckas få med vad ni gjorde, och att det gick "bra". Men varför gick det bra, och vilka fördelar och nackdelar ser ni i vad och hur ni gjorde? Det krävs lite eftertanke och efterklokhet för att lyfta "Vi använde Emacs och gedit och det var bra." till något som är en erfarenhet. Jämför med "Vi använde Emacs och upplevde att det var ett suveränt verktyg att indentera pythonkod. Vi skulle definitivt välja Emacs igen om vi skall skriva python, men tycker att firebug fungerade bättre för att debugga html tack vare att taggar där kan minimeras". Det krävs konkreta exempel för att motivera vad ni upplevt och kunna ha nytta av dessa tankar senare.

Oavsett hur ni gjorde och hur det gick är det viktigt att analysera varför problem (inte) tillstötte. Hade ni tur eller otur med vilka problem som kunde ha tillstött?

Jag vill se minst fyra konkret dokumenterade erfarenheter totalt.
En positiv erfarenhet karakteriseras av att det ni gjorde fungerade bra och ni inte tycker att ni kunde gjort på något alternativt sätt som blivit bättre. En negativ erfarenhet karakteriseras omvänt av att ni gjorde på ett sätt som inte alls fungerade och resultatet blev antingen dåligt eller tog för lång tid eller både och, där ni efterklokt ser att ni borde gjort på ett annat sätt.

Några har fastnat antingen i att allting gick bra hela vägen och inga problem tillstötte. Det tror jag inte på, något litet problem som kunde lösts bättre har ni allt haft. Varför använde ni inte t.ex. SVN? Var det besvärligt att hålla reda på olika versioner i Dropbox, och att kopiera därifrån?

Andra har fastnat i att ta upp alla problem som tillstött. Ingenting verkar ha gjorts på ett sätt man tycker fungerat bra och givit bra resultat. Jag vill se åtminstone något där ni känner att ni prickade rätt.

Några av de fördelar och nackdelar ni identifierat i andra erfarenheter är positiva, andra är negativa. Jag vill se minst en positiv och en negativ erfarenhet, konkret dokumenterad.
Ni har under projektet kommit i kontakt med många tekniker och verktyg. Förvånansvärt få har skrivit vad ni upplever bra och dåligt med olika teknik och verktyg. Jag menar konkreta saker som "Emacs är suveränt för att vi kunde öppna alla filtyper" och "CSS var jobbigt att se vilka taggar som påverkades".

Lite förslag på teknik och verktyg för vilka ni kan skriva ned fördelar och nackdelar ni upplevt: HTML5, CSS3, Python, Emacs, PyCharm, Terminalen, Flask, Jinja, Git, Latex, Google Docs, DropBox, Google Calendar, Mockingbird, Gimp, Git, Eclipse.

Har tekniken ifråga underlättat något i hur strukturen av projektet ser ut, eller hur ni kunnat arbeta tillsammans? Vad sägs i litteraturen om tekniken ni fråga?

Jag vill se minst två viktiga tekniska erfarenheter, med konkret svar på vad som var bra eller dåligt.
Alla har haft ett (mer eller mindre definierat) arbetssätt och de flesta har samarbetat med någon. De flesta har även skrivit något "okej" om samarbetet.

Några har inte tagit upp vad som var positivt och vad som var negativt med de sätt att arbeta som ni provat, vad ni personligen tyckte. Varför tycker ni ert sätt var bra eller dåligt?

Har ni gjort olika prototyper för att sedan välja en väg framåt? Har ni parprogrammerat något? Har ni programmerat enskilt? Har ni planerat vem som gör vad? Har ni tagit dagen som den kommer? Oavsett vilket arbetssätt och samarbete ni haft finns fördelar och nackdelar.

Jag vill se minst en erfarenheter av arbetssätt eller samarbete med konkreta tankar om fördelar och nackdelar.
Några av de fördelar och nackdelar ni identifierat i andra erfarenheter är av sådant slag att ni kan dra nytta av lärdomarna i nästa projekt. Antingen göra på samma sätt igen, eller se till att göra på ett bättre sätt.

När ni hittar erfarenheter av detta slag, ta med dem i sammanfattningen av era viktigaste lärdomar.

Jag vill se minst två erfarenheter som kan tillämpas på alla projekt.
Det vanligaste misstaget vid källhänvisningar är att ni inte berättar vad källan tyckte, utan bara säger att ni gjorde "på liknande sätt". Slutresultatet är att läsaren varken får veta vad källan tyckte, hur ni gjorde eller vad ni upplevt. Ni måste skriva ut vad källan tycker, t.ex. "svn är bra för det tillåter ett team att samarbeta och enkelt dela kod mellan sig" (Arvidsson, TDP003-2014). Då kan ni klart och tydligt jämföra med vad ni upplevt. Kanske får ni anledning att fundera på om ni gjorde på rätt sätt.

Flera saknar helt referenslista, och några har inte skrivit källhänvisningen på korrekt Harvard-stil med sidnummer.

Till minst tre olika erfarenheter vill jag se att ni jämför med vad korrekt citerad källa tycker.
De flesta har skrivit ned någon sammanfattande tanke om vad ni tycker om slutresultatet, och vad ni tror ni kommer göra annorlunda eller ta med till kommande projekt.

Det som ibland vore intressant är mer självanalys som berättar hur du tror projektet kunde blivit mer givande för dig.

Jag vill se en kort sammanfattning av de viktigaste lärdomarna.
Vanligaste bristen är att totalt antal sidor inte framgår. Det är av stor vikt när skrivare krånglar att kunna se hur många sidor det borde kommit ut.

Ibland är numrering i innehållsförteckning fel.

Några rapporter är lite väl korta. Jag vill se minst tre sidor.
De flesta har skrivit riktigt bra, men det finns trots allt några vanliga misstag:
- Användning av slang/talspråk: simpla, simpelt, koll, kolla, la, våran, vårat, fixa, snacka.
- Överdriven användning av fyllnadsord: nog, viss, ju, väl, kanske. Ta bort alla sådana ord, de gör bara att du framstår osäker på din sak, medan du egentligen vet vad du tycker och står för det. Du kan alltid byta åsikt om ett år eller två.
- Användning av ordet "man". Skriv istället exakt vem du menar, eller skriv om så du varken pekar ut "mänskligheten i allmänhet" eller någon annan. Jämför "Arvidsson säger att ni ska undvika 'man'" med "man säger att man ska undvika 'man'". Jämför även "Man kan använda Emacs för att skriva bra kod." med "Emacs kan användas för att skriva bra kod." Prova byta ut alla "man" mot "mänskligheten i allmänhet" så ser du var det passar bra med "man" och var det passar illa.
- Konstiga meningar eller konstig ordföljd. Detta är följden av bristande korrekturläsning.
- Långa meningar. Skriv korta enkla meningar. En tanke - en mening.
- Någon hade bristande "röd tråd" och någon annan upprepade sig en del.
- Wall of text. Se till att ha talande kapitelindelning.
Jag vill se korrekt akademiskt språk med bra flyt.

Sidansvarig: Pontus Haglund
Senast uppdaterad: 2023-10-20