planlægning til fremlæggelsen om XP

1. Planlægning
1.  identificering af stories 
2. estimering
3. metafor
4. release plan+ iterationsplan
2. Forløb
1. standup meeting
2. pair programming
3. Spikes
4. Test First
5. logbog + opsummering
3. Teknisk
1. version control
2. Database

1.1 nemt at gå til og sætte sig ind i kundens tanker er udfordrende.
1.2 de fleste user stories er blevet fejlvurderet f.x. alt med CRUD+DB var overvurderet.
GUI var undervurderet pga. at mange stoires var overvurderet, kunne vi holde  takten (velocity 10 points / dag) selv om vi kun var 3.
Det er ekstremt svært at vurdere spikes, og hvor lang tid man skal bruge på den.  F.eks. den med events, og observer pattern.
1.3 ift. release: kunden var alt for utålmodig pga. opgaver var ikke realistiske.


2.2 det var nemt at holde dem, vi fik overholdt med henhold til standup meeting.
- pga. gruppens lave antal, var det ikke specielt givende, vi kunne alligevel snakke sammen når som helst.
- points er svære at holde styr på - ellers ser vi pointen i  at bruge dem.
2.3 Det var godt når opgaverne var svært, pga. sparringen. Men hvis det var trivielle opgaver var det mindre effektivt.

2.4 Vi vurderede at de trivielle metoder eks. CRUD, ikke behøvede test-first. Men hvis opgaverne var mere komplekse opgaver, så skulle man bruge mere tid på at sætte testen op og tænke over hvad man præcis skal teste.

2.5 Det virkede som ekstra arbejde. Ellers var det let nok at skrive den og dokumentere.

09-09-2015 observer pattern og events spike

I dag blev Hamun sent på den og det endte med at han ikke nåede standup mødet.
I dag gik Anna og Lau i gang med et spike, for at kunne simulere en notifikation fra admin klienten.
Formålet var at Admin/Aktionarius skulle sende en notifikation om hvornår en ændring blev lavet i Admin/Aktionarius' klient.
Denne spike blev sat til ½-1. Dette tog dog noget længere tid en forventet. Da der blev brugt lidt mere tid på den. Der blev lavet et andet helt seperat projekt til dette formål.

Til standup mødet, snakkede vi om at vi overvurderede vi nogle tasks fra i går og dette endte med at vi er foran tiden.

Hamun har nogle computer problemer, så han kunne ikke hjælpe, så meget i dag.

Anna mener at hvis vi ikke fokuserede så meget på at skulle vise noget og lave en simulering, så ville havde vi mere tid til faktisk at lave auktions systemmet.

Vi nåede dog at blive færdig med spiket, og simuleringen blev implementeret i det relle system.

Igennem tasksene, så vurderede vi at den godt kunne splittes mere op, eksempelvis det at lave dummy dataer/indsætte dem i databasen, blev splittet op i 2 forskellige.

08-09-2015

I standup mødet snakkede vi om hvor meget vi havde lavet.
Vi er stadigvæk lidt bagefter, men vi er i gang med at indhente det. Dette er fordi vi ikke har 2 ekstra medlemmer, så man kunne få lavet lidt mere. I dag skal Lau gå i gang med timestamp, timer og interval beregningen lavet.
Hamun og Anna går i gang med start og næste knappen.
Lige nu så er problemet at det kræver undersøgelse på hvordan serveren skal opstilles, og der skal undersøges på opserver pattern, da den hjælper med send notifikation tasken.

Hamun stødte i nogle problemer med den lokale database, derfor endte Hamun, med at ikke kunne arbejde og lave tests.

Men Anna og Lau fik nået at lavet dem vi skulle lave for i dag.

Hamun nåede dog lige at teste de fleste ready for test ting.

Forkølelse

Hej. Jeg har fået mig en forkølelse i weekenden og bliver hjemme idag. Jeg forventer at være frisk til imorgen. Mvh Christoffer


Siden Christoffer er syg. Så startede vi vores stand-up mødet med at sige hvad vi skal lave i dag.
Vi blev enige om at Anna skulle lave review testene for det Hamun og Lau lavede i går.
Derefter skulle Lau og Hamun gå i gang med insert medlem i database og find medlem.
Det eneste problemer vi havde i dag var at GUI'en var lidt grim, og at man skulle umiddelbart snakke med kunden om GUI'en er i orden.

Udover dette så skulle vi indsætte medlemmer fra en excel fil. Dette blev vi alle 3 enige om at det var ikke nødvendigt på nuværende tidspunkt. Da der var andre tasks der var vigtigere.

Efter dette skulle Hamun og Anna skrive koden til startknappen. Og Lau lavede Timer til Start Auktion.

Anna syntes at det var svært at uddelegere tasks for hele dagen. Det er bedre at tage det løbende.

04-09-2015

Til standup mødet snakkede om hvad vi skal lave i dag.
Hvilket var opret database og kunstværk.
Vi satte estimering på de forskellige tasks, og fordelte opgaverne.

Hamun og Lau var en gruppe, som lavede databasen og brugte entity framework til at oprette
forbindelsen. Til det blev der lavet tests for opret, find og delete kunstværk.

Anna og Christoffer lavede skitse for hvordan auktionen skal se ud. Men kun den del hvor auktionen begynder og bliver oprettet.

Databasen blev testet og godkendt. Dermed blev 5 story points done.
Opret og Find kunstværk også er lavet, men ikke godkendt. De går til henholdsvis 1 og 2 storypoints.
Skitsen er færdig og godkendt og dermed er 1 story point færdig.
Opret auktion og find auktion blev også færdig og mangler at blive testet. Disse giver henholdsvis 1 og 2 story points.

Dette giver i alt 11 story points færdig. Hvis vi tager testsene med. Ellers er der kun 6 story points.
Så vi afviger os lidt. Dette skyldes at skitsen tog lidt tid, hvor Anna og Christoffer skulle snakke med Hamun og Lau, om det kunne godkendes. Der skulle have afsat noget mere tid til skitsen.

Vi har arbejdet med pair programming hvilket har fungeret godt, hvor man sparede sammen med hinanden. Vi har brugt GIT til at have collective ownership, så vi har set hinandens kode.
Vi lavede test first, for opret og find kunstværk og auktion, men det syntes vi ikke var nødvendig, da vi tjekkede på databasen om det blev oprettet.

Følgende billede viser vores process.

Kodestandard

Kodestandard

Al kode skrives på engelsk.

Sammensatte navne på variabler og metoder og properies efter CamelCase (f.eks. CalculateTotalSum())

Navne på klasse skal være præcise og sigende.

Navne på variabler skal være sigende, men kan forkortes hvis der skal laves mange af dem (f.eks. Customer cust)

Over hver klasse og hver metode skrives en note med hvem der har lavet den (f.eks. //Lau )

Metoder skrives med signatur, bracket-start, kode, bracket-slut alle på hver sin linje.

Bliver en metode kompleks skriver man lige en kommentar med beskrivelse af hvad metoden gør.

Lav linjeskift hvor det giver mening for at give overblik i koden.

Rækkefølge inden for klasser:

1. Lister, Variabler, Properties (ingen bestemt rækkefølge – de skal bare være i toppen af klassen)

2. Constructor

3. Metoder

03-09-2015

Vi fik lavet story kortene færdige. Satte estimater på dem, og lavede accept kriterierne.
En ting vi fik notis om, som der skal undgås er at vi ikke skal tænke på hvad vi skal arbejde først.
Vi skal tænke på hvad kunden vil ha først.
Gå efter det og de ting der er afhængige af den story laves som dummy data, og hen ad vejen.

Vi fik også udført tavlen med følgende ting: