...
Ik heb nog niet veel ontworpen in de 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.
Dit leerdoel was in de tweede en derde sprint 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.
In de vierde sprint heb ik er aan gedacht om eerst te beginnen aan het maken van alle diagrammen en de beschrijvingen hiervan (zie bijlage
Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.
...
Burndown charts
Situatiebeschrijvingen
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.
Situatie: Diagrams van tevoren maken
Ik had als taak gekozen om de tab aanmaak functie te maken. De vorige keren dat ik een functie ging maken, begon ik met de code en ging ik daarna pas de diagrammen maken. Dit resulteerde in een slordige en onduidelijke login functie, die ik meerdere malen moest verbeteren. Ik begon een branch aan te maken en wilde net gaan coderen, totdat het besef in mij kwam dat ik niet echt goed wist waar ik moest beginnen. Ik besloot mijn code af te sluiten en te beginnen aan het maken van de diagrammen. Door deze diagrammen te maken, kon ik richtlijnen creëren die mij zouden helpen bij het maken van de code. Ik had eerst het SRS gedeelte gemaakt en gevraagd aan Bram en Jasper gevraagd of wat ik had gemaakt, goed was. Na een korte reviewen, was het enige deel feedback dat er nog een paar spellingsfouten inzaten. Deze had ik eruit gehaald en ben toen begonnen aan het sequence diagram. Dit bleek wat moeilijker te zijn dan dat ik had gedacht, omdat er te moeilijk over nadacht. Ik had Wijnand om hulp gevraagd en die gaf wat uitleg over zijn sequence diagram, waardoor ik wist hoe ik mijn sequence diagram kon maken. Nadat ik deze diagrammen afhad met beschrijving erbij, liet ik deze weer reviewen door twee groepsleden. Dit werd nog een keer goedgekeurd en ik ben toen begonnen met coderen. Ondanks de sequence diagram, heb ik nog er nog wel vanaf geweken. De aanpassingen die ik had gemaakt aan de code, heb ik vervolgens ook weer aangepast aan de sequence diagram. De sequence diagram zorgde er wel voor dat het coderen sneller ging, omdat ik wist waar ik naartoe wilde werken. Door een structuur in het codingsproces te krijgen, kan er dus duidelijkheid komen in wat en hoe je gaat coderen. Voor de volgende keer zou ik wel graag willen dat mijn sequence diagram wat beter is en dat het niet aangepast hoeft te worden.
Voorbeelen van unittests
...