...

Het werken in een groepje op school via scrum werkt goed, als iedereen er is. In een groep kan er makkelijk een vraag worden gesteld en gelijk beantwoord, waardoor je sneller verder kan werken met waar je mee bezig was.
Door daily standups kan je horen wat andere teamgenoten gaan doen op een dag en hoe lang dat nog gaat duren . Hierdoor Tijdens het project hebben we ook bijna elke ochtend een daily standup gehouden. De uitzonderingen hierop waren de begin van de sprints, waarbij er nog geen nieuwe taken waren. Door de daily standups kun je eventueel hulp aanbieden als ze te lang bezig zijn met een taak. Dit hoort allemaal bij de scrum-methode.
De bedoeling van scrum is dat je via iteratief werken (zie figuur 1), langzaam op een optimaal product komt. Voordat een sprint start, is het de bedoeling dat er een backlog wordt gemaakt waar alle mogelijke taken in voort komen. Een paar van deze 
taken worden vervolgens in de sprint planning uitgekozen en gaan mee de sprint sprintbacklog in. Tijdens deze sprint werkt elk individueel teamlid aan een taak, totdat dit klaar is om gereviewed te worden. Als team hebben wij afgesproken om twee
leden te laten reviewen, voordat een taak naar done gaat. Na de sprint houden wij een sprint review met onze opdrachtgever, om hem te vertellen wat we gedaan hebben en wat hij nog zou willen zien. De eerste keer ging deze review nog
redelijk traag en wisten we nog niet goed wat we wilden vertellen. Hierdoor hebben we de afspraak gemaakt om de review 3 dagen van te voren al uit te werken, zodat Regterschot Racing snel en duidelijk kan zien wat er gedaan is.

Na de review zal er ook nog een retrospective plaatsvinden, waarin de groep elkaar feedback geeft en terugblikt naar de afgelopen sprint. Door IPV's in te vullen, kan er handig feedback naar voren komen op een anonieme en ook professionele
manier. Deze IPV's worden meestal via de GEIN methode ingevuld, zoals we dit hebben geleerd bij de professional skills lessen.

Rollen

Hier wordt een definitieve reflectie gegeven op de uitvoering van mijn rol gedurende het hele project. Bij een aantal sprints had ik meerdere rollen, deze extra rollen zullen ook toegelicht worden bij correcte sprint.

Rol sprint 1

In sprint 1 was ik scrum master, dit betekende dat ik overzicht moest houden op de taken en wat er gebeurd moet worden voor de eerste sprint.
Zelf merkte ik al snel dat ik als scrum master vaak de leiding kreeg over beslissingen buiten wat een scrum master moet doen. Als scrum master heb je namelijk de taak om te begeleiden, maar dat werd al snel leiden. De leiding nemen is niet iets wat ik graag wil doen, dus dit vond ik wel jammer.

Zelf had ik hierbij wel het gevoel dat ik als scrum master niet goed genoeg was. Bij het begeleiden van mensen, werd mijn advies bijna tot helemaal niet opgevolgd. Dit kwam meestal omdat andere teamleden een andere visie hebben over hoe ze bepaalde acties moeten uitvoeren. Dit leidde vaak tot een discussie, wat niet mijn bedoeling was. In het IPV is wel gezegd dat ik een goede scrum master was en kreeg ik twee plussen voor het bezig zijn met het maken van afspraken. Dit verbaasde mij wel een beetje, aangezien ik dus zelf vond dat ik niet goed genoeg was als scrum master.

Naast het feit dat ik scrum master was, was ik vooral bezig met het reviewen van taken en het verbeteren van werk. Ik heb zelf in de eerste sprint nog niet veel uitgevoerd voor mijn eigen taken. Dit vond ik ook jammer, want zelf wilde ik ook bezig gaan met het schrijven van een verslag, maar iedereen was al bezig met een verslag en ik moest daardoor het SDD en SRS opzetten, waardoor ik alsnog wel nuttig bezig was, maar niet veel deed aan onderzoeken.

Rol sprint 2

In sprint 2 was ik niet specifiek een rol aangewezen. In deze sprint was ik in het begin vooral bezig met het coderen van de login-functie en het opzetten van het systeem. Vaak kwamen vragen over de code mijn kant opgestuurd, aangezien ik het systeem had opgezet en het voor andere mensen uit de projectgroep nog vaak niet werkten. 

Na een tijdje ben ik gestopt met het maken van de logincode en ben ik begonnen met persoonlijke taken, zoals het verslag opzetten en de angular workshop doornemen. Hierdoor was mijn rol vooral stil in de groep.

Rol sprint 3

Na het bekijken van mijn feedback in sprint 2, zag ik dat veel mensen hadden opgemerkt dat ik wat minder aan het woord was en wat minder de leiding nam. Dit gebeurde omdat ik niet meer scrummaster was. Daarom had ik besloten om toch wat meer “de leiding” te pakken. Hiermee bedoel ik niet zo zeer dat ik zei wat iedereen moest doen, maar meer iedereen aan wilde sturen wat ze kunnen doen en wat er nog gedaan moest worden. Ik had het gevoel dat dit nodig was, aangezien er veel tijd in de vorige sprint verloren ging aan afleidingen en het verkeerd handelen van taken.

Competenties

In dit hoofdstuk leg ik uit welke beslissingen ik heb genomen die hebben gezorgd voor een actieve bijdragen van dit project. Hierbij wordt gekeken naar welke overwegingen ik heb gemaakt en of deze beslissingen juist waren.

Competentie OOSE P-03: Onderzoek relevante technologiekeuzes.

Ik heb onderzoek gedaan naar het hashen van een wachtwoord. Hierdoor heb ik gezorgd dat de login functie veiliger is. Sommige tools om wachtwoorden te hashen zijn niet goed om toe te passen op de applicatie.
Door hier onderzoek naar te doen heb ik ervoor gezorgd dat Regterschot Racing een veilige manier heeft gekregen om in te loggen en het wachtwoord op te slaan. Deze implementatie was ook makkelijk toe te passen, aangezien
andere groepsleden al hebben gewerkt met deze tool. Dit was dus een goede implementatiekeuze geweest. Zie factsheet P-03.

Competentie OOSE P-04: Het documenteren en ontwerpen van de software, met behulp van UML-diagrammen.

Voor de login functie heb ik de system sequence diagram opgesteld en de normale sequence diagram gemaakt. Deze sequence diagrammen dienen als uitleg van de code.

Leerdoelen

Voor dit project bedenk ik een aantal leerdoelen waar ik mij aan wil houden. In dit hoofdstuk behandel ik de opgestelde leerdoelen en situatiebeschrijvingen. Als laatst laat ik mijn kernkwadranten zien voor dit project.

Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

Dit leerdoel heb ik gekozen, omdat in het vorig I-Project ik te weinig bezig was aan ontwerpen van bijvoorbeeld code.
Hierdoor moest mijn code vaak verbeterd worden, waardoor er te veel tijd verloren ging. Ik zou dit doel graag willen halen, zodat dit minder tijd verspilt voor mij 
en de groep.

Dit leerdoel kan ik bereiken door:

• Meer te werken aan het technisch ontwerp, zodat ik van tevoren een duidelijke visie heb op wat ik wil coderen. 
• De opdracht beter doorlezen en verdelen in sub-taken, zodat er een overzicht is van de taken. 
• Regelmatig anderen mijn code laten reviewen, zodat latere fouten op tijd gezien kunnen worden. 

Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.

Dit leerdoel heeft te maken met het realisme kernkwadrant. Dit leerdoel heb ik gekozen, aangezien ik vaak dingen alleen op mijn manier doe en niet op iemand anders manier. Dit maakt het werk meestal wel realistisch, maar niet ideaal.

Om dit leerdoel te halen heb ik een aantal stappen bedacht die ik kan doorlopen.

• Regelmatig vragen voor een 2e blik op mijn werk, wanneer ik denk klaar te zijn met mijn taak.
• Zorgen voor een goed overleg als meningen verschillen, hierbij vragen stellen zoals: "Waarom vind je dit?" of "Hoe sta jij hierin?".
• Als er iets is wat we allemaal moeten doen, dan kan ik vragen hoe een ander dit heeft aangepakt en deze aanpak kan ik dan eventueel opnemen in mijn werk, als dit goed beargumenteerd is.

Sprint 1

Situatiebeschrijvingen sprint 1

Situatie 1: Eerder weggaan

Deze situatie heeft te maken met mijn tweede leerdoel. De groep wilde vroeg weggaan van school, waar ik het niet mee eens was. Ik ging snel in discussie en beargumenteerde waarom ik vond dat we langer moesten blijven. Mijn rol was het beredeneren waarom mijn groep langer zou moeten blijven en begrijpen waarom ze eerder weg wilden gaan. Ik was voor deze sprint ook scrummaster, dus wilde mijn taak ook goed uitoefenen. Mijn doel was om ze te overtuigen om langer te blijven. Ik moest ook rekening houden dat ik niet in een lange discussie zou raken, want een van mijn leerdoelen was om meer aan te nemen van anderen. Helaas brak dit toch uit tot een kleine discussie, aangezien de groep vond dat ze al productief genoeg hadden gewerkt. Toen ik duidelijk had gemaakt dat ik de tijd te vroeg vond en dat ik vond dat hier duidelijkere afspraken voor moesten komen, was de groep het daar wel mee eens, maar ze gingen als nog weg. Ik bleef wel en bedacht alvast een afspraak die we konden maken, om een vaste tijd te blijven aanhouden, waarop we weggingen. Achteraf had ik mijn standpunt beter vast kunnen houden en zeggen dat ze het echt niet konden maken om te gaan, waardoor we in de tijd dat ze zouden blijven, we de afspraak hadden kunnen maken voor de vaste tijd. Ik had voor nu gekozen om ze dan maar te laten gaan, om zo de rust te bewaren en de volgende dag het rustig te bespreken.

Voor de volgende keer had ik wat netter mijn standpunt kunnen verwoorden. Ik had het gevoel dat ik het misschien niet goed had uitgelegd waarom ik vond dat ze langer moesten blijven en waarom dit handig was. Het was wel goed dat ik mijn eigen mening had getoond en opkwam voor het werkproces, maar dit had ik dus beter kunnen verwoorden. De volgende dag hadden we wel de afspraak gemaakt dat we minimaal tot 4 uur blijven, ook al was de minimale productiviteit van die dag bereikt.

Situatie 2: Te veel moeten reviewen

In de eerste sprint waren er veel taken nog op het eind die gereviewd moesten worden. Dit zorgde voor een verkeerde burndown chart. Uiteindelijk heb ik veel gereviewd, maar daardoor kwam ik niet toe aan mijn eigen bijdrage. Ik wilde ervoor zorgen dat ik niet al het werk van iedereen elke keer moet reviewen, want zo doe ik zelf niet iets anders, behalve reviewen. Ik om dit proberen te veranderen, het plan van aanpak erbij gehaald en gezegd dat er minimaal twee groepsleden de review moeten doen. Hierbij heb ik ook netjes aangegeven via de GEIN feedbackmethode dat ik op had gemerkt dat ik voor al het reviewen deed. Nadat ik dit had aangegeven, begonnen meer groepsleden te reviewen, waardoor ik kon beginnen aan het opzetten van het SRS, SDD en de code.

Ik ben tevreden dat de groep heeft geluisterd naar mijn feedback en gelijk zorgde dat het reviewen sneller verliep. Dit valt overeen met de compenties over onderzoeken en het bewaken van de kwaliteit.Als ik de enige zou zijn die reviewt, dan zou ik fouten over het hoofd kunnen zien, wat erg jammer zou zijn.

Conclusie leerdoelen sprint 1

Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

Ik heb nog niet veel ontworpen deze eerste sprint, waardoor ik geen tijd heb besteed aan dit leerdoel. Er is ook niet veel code die gemaakt moest worden deze sprint.
De opdrachten van het JIRA bord waren ook nog niet helemaal goed verdeeld, waardoor ik veel werk kwijt was op een sub-taak, dat eigenlijk meerdere taken konden zijn.
Mijn conclusie is dus dat ik dit leerdoel moet meenemen voor de volgende sprint, zodat ik er goed aan kan werken.

Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.

Ik heb dit leerdoel niet gehaald afgelopen sprint. Ik viel nog te vaak in discussies. Het is niet gek dat ik dit nog niet heb gehaald, aangezien dit pas de eerste sprint is en vooruitgang gaat in stapjes. In het IPV rapport van sprint 1 is te zien dat ik dit nog niet heb gehaald door te kijken naar de feedback. Voor de volgende sprint moet ik dus een scherper beeld hebben op dit leerdoel en zorgen dat ik het niet uit het oog verlies.

Sprint 2

Situatiebeschrijvingen sprint 2

Situatie 1: Discussie login review

In sprint 2 was er een discussie begonnen over hoe de loginfunctie veranderd moest worden. Dit gebeurde na het reviewen van mijn taak. Wijnand en Bram waren mijn stukje code aan het reviewen en zagen dat er een aantal aanpassingen gedaan konden worden. In dit geval ontving ik dus feedback en gaven Bram en Wijnand hun feedback. Ik had verwacht dat ik mijn code nog wel wat had moeten aanpassen, want ik zal best een paar dingen over het hoofd hebben gezien. Ik kreeg mijn feedback terug en besloot de aanpassingen die zij hadden toegelicht te implementeren, zodat ik klaar zou zijn met het maken van de login. Mijn frustratie over het maken van deze loginfunctie lag hoog, want ik zat al boven de geschatte tijd in en wilde graag bezig zijn met andere competenties. Na het verbeteren had ik aangegeven dat mijn stukje code verbeterd was en weer klaar was om gereviewed te worden. Dit keer verliep het alleen anders. Veel van wat ik net moest veranderen aan mijn code, moest weer op een andere manier gedaan worden dan bij de vorige review was aangegeven. Dit ging vooral over het geven van tokens en het hashen van een wachtwoord. Ik was hier boos om geworden, omdat ik weer tijd had besteed aan een stukje code, om vervolgens te horen dat het weer anders moest. Aangezien ik deze sprint al vaker problemen had gehad met de loginfunctie, besloot ik dat ik wilde stoppen met het maken van deze code, aangezien ik er niet meer onderuit kwam. Dit deed ik alleen op een best wel boze manier en dit had ik anders kunnen aanpakken. Als ik mijn frustratie had uitgelegd en gevraag om een oplossing, dan was dat een betere optie geweest, dan het werk verschuiven naar iemand anders. Ik dacht dat door mijn werk naar iemand anders te verschuiven, er een teamlid zou zijn die er meer van wist en het dus sneller af zou maken. De groep had aangegeven in het IPV dat dit wel anders gehandeld had kunnen worden, waarbij ik het ook mee-eens ben. Ik had niet boos moeten worden en naar oplossingen moeten zoeken.

Situatie 2: Password hashing

 Conclusie leerdoelen sprint 2

Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

...

Voor de eerste paar sprints hadden we de IPV's met een korte versie ingevuld die alleen wat zeggen over de projectbijdrage, zie bijlage IPV rapport sprint 1. We hadden besloten om een keer de wat langere versie te kiezen, zodat we meer gedetailleerd feedback konden geven. Dit bleek effectief te zijn, aangezien iedereen wist waar de problemen precies lagen. Er werd ook meer feedback gegeven, wat ook nuttig is, zie bijlage IPV rapport sprint 3.

Voor elke sprint hebben we een andere scrummaster gekozen. Deze scrummaster begeleidt het team door het proces heen en houdt overzicht over de taken. Aangezien we vijf sprints hebben, komt dus bijna iedereen aan bod. Alleen Martin was geen scrummaster, omdat hij de chef de mission was, dat betekent dat hij de product begeleider moet blijven informeren over de stand van zaken.

Na mijn idee hebben we al de scrum regels de laatste paar sprint goed toegepast. De sprintplanning ging steeds beter, omdat we doorhadden hoe we dit goed konden doen. We gaven de taken specifieke namen, zodat het duidelijker is wat ze inhouden. Het aantal uren per sprint werd ook beter ingeschat, dit is te zien door te kijken naar de burndown chart per sprint, zie bijlage burndown charts. Hoewel de eerste drie sprints nog niet goed verliepen, kwam dit vooral door de slechte toepassing van de sprintplanning. Tijdens sprint 4 bleek dat de broker meer tijd zou kosten dan orgineel ingeschat, waardoor we de sprint net niet hadden gehaald. De rest van de taken tijdens sprint 4 waren wel goed ingeschat en daarom vind ik het toch een verbetering.

Image Added+

Figuur 1: Scrum procesverloop (HAN University of Applied Sciences [HAN], z.d.)

Rollen

Hier wordt een definitieve reflectie gegeven op de uitvoering van mijn rol gedurende het hele project. Bij een aantal sprints had ik meerdere rollen, deze extra rollen zullen ook toegelicht worden bij correcte sprint.

Rol sprint 1

In sprint 1 was ik scrum master, dit betekende dat ik overzicht moest houden op de taken en wat er gebeurd moet worden voor de eerste sprint.
Zelf merkte ik al snel dat ik als scrum master vaak de leiding kreeg over beslissingen buiten wat een scrum master moet doen. Als scrum master heb je namelijk de taak om te begeleiden, maar dat werd al snel leiden. De leiding nemen is niet iets wat ik graag wil doen, dus dit vond ik wel jammer.

Zelf had ik hierbij wel het gevoel dat ik als scrum master niet goed genoeg was. Bij het begeleiden van mensen, werd mijn advies bijna tot helemaal niet opgevolgd. Dit kwam meestal omdat andere teamleden een andere visie hebben over hoe ze bepaalde acties moeten uitvoeren. Dit leidde vaak tot een discussie, wat niet mijn bedoeling was. In het IPV is wel gezegd dat ik een goede scrum master was en kreeg ik twee plussen voor het bezig zijn met het maken van afspraken. Dit verbaasde mij wel een beetje, aangezien ik dus zelf vond dat ik niet goed genoeg was als scrum master.

Naast het feit dat ik scrum master was, was ik vooral bezig met het reviewen van taken en het verbeteren van werk. Ik heb zelf in de eerste sprint nog niet veel uitgevoerd voor mijn eigen taken. Dit vond ik ook jammer, want zelf wilde ik ook bezig gaan met het schrijven van een verslag, maar iedereen was al bezig met een verslag en ik moest daardoor het SDD en SRS opzetten, waardoor ik alsnog wel nuttig bezig was, maar niet veel deed aan onderzoeken.

Rol sprint 2

In sprint 2 was ik niet specifiek een rol aangewezen. In deze sprint was ik in het begin vooral bezig met het coderen van de login-functie en het opzetten van het systeem. Vaak kwamen vragen over de code mijn kant opgestuurd, aangezien ik het systeem had opgezet en het voor andere mensen uit de projectgroep nog vaak niet werkten. 

Na een tijdje ben ik gestopt met het maken van de logincode en ben ik begonnen met persoonlijke taken, zoals het verslag opzetten en de angular workshop doornemen. Hierdoor was mijn rol vooral stil in de groep.

Rol sprint 3

Na het bekijken van mijn feedback in sprint 2, zag ik dat veel mensen hadden opgemerkt dat ik wat minder aan het woord was en wat minder de leiding nam. Dit gebeurde omdat ik niet meer scrummaster was. Daarom had ik besloten om toch wat meer “de leiding” te pakken. Hiermee bedoel ik niet zo zeer dat ik zei wat iedereen moest doen, maar meer iedereen aan wilde sturen wat ze kunnen doen en wat er nog gedaan moest worden. Ik had het gevoel dat dit nodig was, aangezien er veel tijd in de vorige sprint verloren ging aan afleidingen en het verkeerd handelen van taken.

Competenties

In dit hoofdstuk leg ik uit welke beslissingen ik heb genomen die hebben gezorgd voor een actieve bijdragen van dit project. Hierbij wordt gekeken naar welke overwegingen ik heb gemaakt en of deze beslissingen juist waren.

Competentie OOSE P-03: Onderzoek relevante technologiekeuzes.

Ik heb onderzoek gedaan naar het hashen van een wachtwoord. Hierdoor heb ik gezorgd dat de login functie veiliger is. Sommige tools om wachtwoorden te hashen zijn niet goed om toe te passen op de applicatie.
Door hier onderzoek naar te doen heb ik ervoor gezorgd dat Regterschot Racing een veilige manier heeft gekregen om in te loggen en het wachtwoord op te slaan. Deze implementatie was ook makkelijk toe te passen, aangezien
andere groepsleden al hebben gewerkt met deze tool. Dit was dus een goede implementatiekeuze geweest. Zie factsheet P-03.

Competentie OOSE P-04: Het documenteren en ontwerpen van de software, met behulp van UML-diagrammen.

Voor de login functie heb ik de system sequence diagram opgesteld en de normale sequence diagram gemaakt. Deze sequence diagrammen dienen als uitleg van de code.

Leerdoelen

Voor dit project bedenk ik een aantal leerdoelen waar ik mij aan wil houden. In dit hoofdstuk behandel ik de opgestelde leerdoelen en situatiebeschrijvingen. Als laatst laat ik mijn kernkwadranten zien voor dit project.

Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

Dit leerdoel heb ik gekozen, omdat in het vorig I-Project ik te weinig bezig was aan ontwerpen van bijvoorbeeld code.
Hierdoor moest mijn code vaak verbeterd worden, waardoor er te veel tijd verloren ging. Ik zou dit doel graag willen halen, zodat dit minder tijd verspilt voor mij 
en de groep.

Dit leerdoel kan ik bereiken door:

• Meer te werken aan het technisch ontwerp, zodat ik van tevoren een duidelijke visie heb op wat ik wil coderen. 
• De opdracht beter doorlezen en verdelen in sub-taken, zodat er een overzicht is van de taken. 
• Regelmatig anderen mijn code laten reviewen, zodat latere fouten op tijd gezien kunnen worden. 

Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.

Dit leerdoel heeft te maken met het realisme kernkwadrant. Dit leerdoel heb ik gekozen, aangezien ik vaak dingen alleen op mijn manier doe en niet op iemand anders manier. Dit maakt het werk meestal wel realistisch, maar niet ideaal.

Om dit leerdoel te halen heb ik een aantal stappen bedacht die ik kan doorlopen.

• Regelmatig vragen voor een 2e blik op mijn werk, wanneer ik denk klaar te zijn met mijn taak.
• Zorgen voor een goed overleg als meningen verschillen, hierbij vragen stellen zoals: "Waarom vind je dit?" of "Hoe sta jij hierin?".
• Als er iets is wat we allemaal moeten doen, dan kan ik vragen hoe een ander dit heeft aangepakt en deze aanpak kan ik dan eventueel opnemen in mijn werk, als dit goed beargumenteerd is.

Sprint 1

Conclusie leerdoelen sprint 1

Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

Ik heb nog niet veel ontworpen deze eerste sprint, waardoor ik geen tijd heb besteed aan dit leerdoel. Er is ook niet veel code die gemaakt moest worden deze sprint.
De opdrachten van het JIRA bord waren ook nog niet helemaal goed verdeeld, waardoor ik veel werk kwijt was op een sub-taak, dat eigenlijk meerdere taken konden zijn.
Mijn conclusie is dus dat ik dit leerdoel moet meenemen voor de volgende sprint, zodat ik er goed aan kan werken.

Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.

Ik heb dit leerdoel niet gehaald afgelopen sprint. Ik viel nog te vaak in discussies. Het is niet gek dat ik dit nog niet heb gehaald, aangezien dit pas de eerste sprint is en vooruitgang gaat in stapjes. In het IPV rapport van sprint 1 is te zien dat ik dit nog niet heb gehaald door te kijken naar de feedback. Voor de volgende sprint moet ik dus een scherper beeld hebben op dit leerdoel en zorgen dat ik het niet uit het oog verlies.

Sprint 2

Situatiebeschrijving sprint 2

Situatie : Discussie login review

In sprint 2 was er een discussie begonnen over hoe de loginfunctie veranderd moest worden. Dit gebeurde na het reviewen van mijn taak. Wijnand en Bram waren mijn stukje code aan het reviewen en zagen dat er een aantal aanpassingen gedaan konden worden. In dit geval ontving ik dus feedback en gaven Bram en Wijnand hun feedback. Ik had verwacht dat ik mijn code nog wel wat had moeten aanpassen, want ik zal best een paar dingen over het hoofd hebben gezien. Ik kreeg mijn feedback terug en besloot de aanpassingen die zij hadden toegelicht te implementeren, zodat ik klaar zou zijn met het maken van de login. Mijn frustratie over het maken van deze loginfunctie lag hoog, want ik zat al boven de geschatte tijd in en wilde graag bezig zijn met andere competenties. Na het verbeteren had ik aangegeven dat mijn stukje code verbeterd was en weer klaar was om gereviewed te worden. Dit keer verliep het alleen anders. Veel van wat ik net moest veranderen aan mijn code, moest weer op een andere manier gedaan worden dan bij de vorige review was aangegeven. Dit ging vooral over het geven van tokens en het hashen van een wachtwoord. Ik was hier boos om geworden, omdat ik weer tijd had besteed aan een stukje code, om vervolgens te horen dat het weer anders moest. Aangezien ik deze sprint al vaker problemen had gehad met de loginfunctie, besloot ik dat ik wilde stoppen met het maken van deze code, aangezien ik er niet meer onderuit kwam. Dit deed ik alleen op een best wel boze manier en dit had ik anders kunnen aanpakken. Als ik mijn frustratie had uitgelegd en gevraag om een oplossing, dan was dat een betere optie geweest, dan het werk verschuiven naar iemand anders. Ik dacht dat door mijn werk naar iemand anders te verschuiven, er een teamlid zou zijn die er meer van wist en het dus sneller af zou maken. De groep had aangegeven in het IPV dat dit wel anders gehandeld had kunnen worden, waarbij ik het ook mee-eens ben. Ik had niet boos moeten worden en naar oplossingen moeten zoeken.

 Conclusie leerdoelen sprint 2

Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

Dit leerdoel is nog steeds niet gelukt. Ik ben te vroeg begonnen aan het maken van de loginfunctie. Als ik dit wel had gedaan, had dit veel tijd gekost, waardoor ik echt wil opletten dat ik dit goed ga doen. Voor de volgende sprint/code functie, wil ik eerst het SRS maken. Dit ga ik proberen te onthouden door mijn tijd meer te besteden aan het reviewen van het SRS en SDD, zodat ik de prioriteit van deze documenten goed begrijp. Na het SRS ga ik de bijbehorende sequence diagrams maken en laat ik zorgen dat deze zo snel mogelijk gereviewd zijn. Voordat ik ga werken aan de functionaliteit, laat ik mijn sequence diagrams door twee teamleden reviewen, zodat ik zeker weet dat wat ik heb gemaakt, ook echt de bedoeling is van de opdracht.

Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.

Ook dit punt was dus nog niet goed. Helaas kwam er een discussie nadat mijn groepsleden mij feedback hadden gegeven. Dit wil ik graag verbeteren, door te zorgen dat ik bij frustraties een paar tellen wacht, voordat ik reageer op een antwoord. Ook zal ik proberen mijn frustratie wat meer weg te lachen. Hiermee bedoel ik dat ik mijn frustratie wat minder serieus moet nemen en moet kijken naar wat ik fout doe om deze frustratie te krijgen. Vooral wil ik hiermee zorgen dat ik niet meer boos wordt om deze voorgevallen.

Sprint 3

 Conclusie leerdoelen sprint 3

Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.

Sprint 4

 Conclusie leerdoelen sprint 4

Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.

...

Sprint 5

 Conclusie leerdoelen sprint 5

Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.

Kernkwadranten

Een kernkwadrant laat in een oogopslag wat iemand zijn: valkuil, uitdaging, allergie en kernkwaliteit is. 

...

1. Praktijkbureau AIM. (2022). Toelichting plan van aanpak. In Onderwijs Online. HAN University of Applied Sciences. Geraadpleegd op 2 november 2022, van https://han.onderwijsonline.nl/elearning/lesson/Kqe86W3D
2. HAN University of Applied Sciences [HAN]. (z.d.). Les 5 wk_5_OOSE_Methode en planning_2022-2023_stud [Presentatieslides; Website]. OnderwijsOnline. https://han.onderwijsonline.nl/elearning/lesson/pNWX2Z9y

Bijlagen

IPV rapport sprint 1

...

IPV rapport sprint 2

IPV rapport sprint 3

Burndown charts

Image Added

Het projectverslag moet je zien als een tentamen dat je succesvol gemaakt hebt: een toets waarmee jij laat zien wat je van het project geleerd en begrepen hebt. Het verslag geeft een afdoende beeld van het werk dat je gedaan hebt in het project (in termen van kwantiteit en kwaliteit), en maakt je deskundigheid ten aanzien van het project (en in de verdiepende semesters: het profiel waarin je gaat afstuderen) voldoende inzichtelijk. Je maakt een selectie van hoogte- (of diepte)punten waarmee je je deskundigheid kunt tonen. Die beoordeel je kritisch, en zo laat je zien wat je geleerd en begrepen hebt. Het projectverslag is, (net als straks het afstudeer- en stageverslag) het startpunt van je individuele beoordeling. 

...