eAuteurs:

Docenten

1. Inleiding

Voor het OOSE-project zijn de klassen opgesplitst in verschillende groepen opgesplitst. Ik maak deel van het team Smalltalk. Onze opdracht is vanuit het bedrijf Regterschot Racing opgedragen. Regterschot Racing wilt een dashboard ontwikkeld hebben waarmee ze het live tracken van data kunnen weergeven, op een door ons gemaakte website. De sensoren worden door het embedded team van Regterschot Racing uitgelezen en doorgestuurd naar ons. Dit wordt gedaan met behulp van een broker. Door hier direct de data uit te lezen kunnen we de data live op de website te kunnen weergeven. Naast dat de data live zichtbaar moet kunnen zijn moet de website ook veilig en betrouwbaar zijn. Vanuit Regterschot Racing kwam al snel met een eis die ze graag zouden willen zien, en dat is dat de data 20 keer per seconden moest worden geupdate. Maar als dit niet haalbaar was door performance problemen wouden ze het zo snel mogelijk kunnen zien op de website.

In dit document zal ik me bezighouden met mijn voortgang samen met competenties te laten zien en hoe ik gegroeid ben als Software Engineer. Verder zal er in dit document beschreven worden welke vaardigheden en kennis ik al beheers en welke ik heb verkregen tijdens het project. Hiernaast heb ik een tweetal leerdoelen opgezet voor tijdens het project. Deze leerdoelen heb ik gekozen zodat ik mij bewust bezig ben met mij verder te ontwikkelen als persoon.

Mijn eerste leerdoel gaat over dat ik mij meer wil laten hoor tijdens gespreken en tijdens het werk. In eerdere projecten liep ik altijd wat meer op de achtergrond en liet ik weinig tot niks van mij horen. Dit gaf een wat minder prettige werkomgeving omdat ik niet wist waar mensen mee bezig waren en andere wisten niet waar ik mee bezig was. Dit heeft ook veel temaken met mijn persoonlijkheid, als iemand die erg terughoudend is was ik liever rustig op mezelf bezig en vraag ik minder snel om hulp. Voor mijn tweede leerdoel merkte ik tijdens vorige project dat gesprekken met opdrachtgever weinig tot geen voorbereiding deden. Dit zorgde vaak voor veel stress en onodige moeilijkheden. Hierdoor wil ik tijdens dit project gesprekken en demo's beter voorbereiden zodat we niet ineens voor verassingen komen te staan. Naast dat dit fijn is voor opdrachtgever geeft dit veel meer rust en stabilisatie aan de groep.

IN dit document zal ik ingaan op de volgende hoofdstukken. Als eerste zal ik het hebben over de kwaliteit van de deelproducten die we hebben gemaakt. In het tussentijdse zal ik kijken naar het plan van aanpak, het SRS en SDD en als laatste een stukje naar de code wat we tot dan hebben gemaakt. Hierna zal ik kijken naar de projectmethoden, welke we hebben gebruikt en hoe het ging. In het volgende hoofdstuk rollen zal ik beschrijven welke rollen ik heb gehad in dit project en hoe ik ze heb uitgevoerd. In het hoofdstuk competenties zal ik een aantal door school gestelde competenties uitwerken. In het tussentijdse verslag zal ik er 2 uitwerken en dan nog 2 aan het eind. Dan ga ik in het hoofdstuk van leerdoelen nog is dieper in op mijn leerdoelen, ik zal dan uitleggen waarom ik mijn leerdoelen heb gehaald of juist niet. Als laatste zal ik een eindoordeel geven over het project, hier zal ik kijken naar het geheel van het project en mijn oordeel geven of ik het goed vind of slecht en wat er beter kan voor volgende projecten.

Tijdens het project kwam ik geen grote uitdagingen tegen. Het eerste opstakel wat mogelijk voor problemen kon zorgen was de frontend framework die wij hadden gekozen. Dit was AngularJS, nu heb ik al wel evaring met angular dus dat zal wel goed maar de rest van mijn groepje had er nog nooit mee gewerkt. Het kon dus zijn dat ze tegen problemen aan gingen lopen waar ik ook geen antwoord op wist. Gelukkig was er erg veel documentatie van het framework zodat veel van de vragen die we hadden ook een duidelijk antwoord hadden. Dan hebben we voor het data ophalen voor de website een API gemaakt. Dit hebben we gedaan door middel van de kennis die we hebben opgedaan tijdens DEA toe te passen en zo gemakkelijk een nette API op hebben gezet.

2. Kwaliteitsoordeel deelproducten

2.1. Plan Van Aanpak (PVA)

Het PVA vind ik uiteindelijk wel voldoende. De opstart van het project ging nogal stroef. Dit kwam doordat we elkaar nog niet zo goed kende en we de rollen verdeling nog niet zo goed hadden. Tijdens het assessment van het PVA kwamen er een aantal tekortheden aan het ligt. Zoals dat de urgentie miste in de inleiding waardoor het niet duidelijk was waarom de opdrachtgever juist nu ermee wou beginnen. Verder was er onduidelijkheid wat er nou bedoeld werd over de softwarehandleiding, nadat we ons zelf hebben gehoord klikte het dat de handleiding en Software Design Document hetzelfde zijn in principe. Dit soort fouten horen eigenlijk niet te kunnen, wij hebben de nodige documenten gekregen waar dit al in staat en daar hebben we in dit geval compleet overheen gelezen. Voor volgende projecten ga ik dit ook zeker meenemen dat alles wat we maken qua documentatie ook gecontroleerd wordt op de geleverde documenten zodat we dit soort simpele dingen gemakkelijk kunnen afvangen en voorkomen.

Wat ik wel vind is dat we ondanks de moeilijk start wel een stevig plan van aanpak hebben kunnen opzetten op de genoemde fouten na dan. In hoofdstuk 6 hebben wij aangegeven wat wij gaan opleveren na het einde van dit project, hierin vind ik wel dat we de eisen iets strakker hadden kunnen maken. Bijvoorbeeld bij “software/eindeproduct” zeggen wij dat er via Bitbucket een versiebeheer wordt toegepast, maar niet wat de regels daaraan zijn. Hierdoor kunnen mensen misschien inzien dat er 2 branches zijn en daarop werken met ze allen. Nou is dit niet de bedoeling, en zou er eerder van maken: Er wordt via Bitbucket versiebeheer bijgehouden doormiddel van bij elke issue dat je oppakt een nieuwe branch maakt. Dit is een stuk overzichtelijker en duidelijker wat waarop staat en kan je makkelijker terugkijken in de branch als er iets misgaat.

Er zijn zeker genoeg verbeterpunten om het nog netter te maken maar voor de opdrachtgever is dit een prima plan van aanpak. De verbeterpunten die ik nu nog zo zie gaan vooral de afspraken met de developer groep zodat iedereen op een lijn zitten.

2.2. SRS

Het SRS is naar mijn mening in een voldoende staat om mee te kunnen werken in de komende sprints. Aangezien wij tijdens elke nieuwe usecase het SRS en SDD zullen updaten naar wat we erbij maken.

De introductie is duidelijk je weet waarover het gaat, en het gaat duidelijk over onze applicatie. Daarnaast is goed te zien wie de applicatie gaat gebruiken en wat de applicatie moet doen.
We hadden voor functionaliteit niet veel restricties gekregen en laat het bedrijf ons daar erg los in hierdoor hebben wij er vrijwel geen product functies in het SRS staan maar die komen er later bij als we gaan brainstormen over extra functies.

Het domeinmodel heeft een net glossary die je laat zien wat de concepten zijn die we hebben gevonden en wat ze inhouden.

De gemaakte usecases die tot nu toe bekend zijn, zijn uitgewerkt met behulp van het fully dressed formaat en ieder deel is duidelijk verwoord. Ze hebben allemaal actors, stakeholders, brief description, pre- en postcondities. Met hierbij een mainflow en eventueel een alternatieve flow.

De beschrijving van main flow mag nog wel wat algemener vind ik. Nu zeg je al dat er een button komt maar de opdrachtgever kan ook zeggen dat het om een andere interactie gaat waardoor je geen button meer voor nodig hebt.

De requirements zijn netjes opgesteld met behulp van FURPS+ dit zorgt ervoor dat je in een oogopslag kan zien wat er is en onder welke kopjes deze requirements vallen.  

De sketches die gemaakt zijn voor de applicatie zien er netjes en duidelijk uit. Als iemand van buitenaf ernaar zou kijken weet die exact hoe de applicatie eruit moet komen te zien.

2.3. SDD

Ik vind dat we voor het SDD net een voldoende hebben gedaan. Er zijn nog een aantal dingen waar ik me toch wel aan stoor, waaronder dat de comments nog altijd blijven staan ook al zijn mensen klaar met het kopje.

De inleiding is duidelijk en niet te omslachtig, de terminologie is duidelijk aangegeven en wat ze betekenen voor mensen die niet bekend zijn met de termen. Met het deployment diagram had ik zelf nog wat punten die ik niet had gedaan, zoals dat er een extra punt is gezet voor de rest api is naar mijn mening niet van belang. Aangezien de application server de API is en dat zou betekenen dat het er 2 keer in zou moeten staan.

Het class diagram is tot nu toe vrij klein, dit komt omdat we nog weinig functionaliteit hebben en daarom alleen de hoognodige klassen hebben opgenomen. In de komende sprints gaan we meer en meer functionaliteit toevoegen en dit zal het diagram ook uitbreiden.

2.4. Code fragment

Ik ga hier kijken naar een stuk code die ik van onze bitbucket af heb gehaald

Specefiek kijk ik naar dit stuk

public class TabDAO {

    GraphService graphService;
    @Inject
    public void setGraphService(GraphService graphService) {
        this.graphService = graphService;
    }

    private DatabaseConnection databaseConnection;
    @Inject
    public void setDatabaseConnection(DatabaseConnection databaseConnection) {
        this.databaseConnection = databaseConnection;
    }

    public ArrayList<TabsDTO> getUserTabs(String token) throws NoUserFoundException {
        ArrayList<TabsDTO> tabs = new ArrayList<TabsDTO>();
        try {
            PreparedStatement getTabs = databaseConnection.getConnection().prepareStatement("SELECT tabName, TabId FROM Tab Where userToken = ?");
            getTabs.setString(1, token);
            ResultSet getTabsResult = getTabs.executeQuery();
            while(getTabsResult.next()) {
                TabsDTO tabsDTO = new TabsDTO();
                tabsDTO.setId(getTabsResult.getInt("tabId"));
                tabsDTO.setName(getTabsResult.getString("tabName"));
                tabsDTO.setGraphsDTO(graphService.getAll(getTabsResult.getInt("tabId")));
                tabs.add(tabsDTO);
            }
        } catch (SQLException e) {
            throw new DatabaseExceptions(e);
        }
        
        return tabs;
    }

}

Kijkend naar de Clean Code principles, hier een opsomming van. Voldoet de code er tot zo ver aan. Ik gebruik hier geen dependencies maar het is wel volgens lower camelCase geschreven, er is geen onnodig commentaar en als functie heeft het maar een doel.

De code voldoet daarom ook de kwaliteitseisen in het PvA. Het maakt gebruik van SOLID via de Single Responsibility Principle, deze class heeft een taak en dat is dat de data van de tabbladen worden opgehaald. Het voldoet ook aan onze Definition of Done. Er is gecontroleerd of het is uitgewerkt in het SRS en SDD en of deze documenten overeenkomen. De code horen bij de usecase view data. Er zijn nog geen testen voor geschreven omdat we de nuttalk nog niet hebben gehad, zodra wij deze nuttalk hebben gehad zal deze class de nodige unit testen krijgen. Daarnaast hebben we het nog niet met Jenkins gekoppeld omdat wij als groep het nog niet werkend hebben gekregen. Komende sprint gaan we dat wel doen zodat alle code smells en bugs eruit worden gehaald.

Ik geef de code een goede voldoende.

2.5. Onderzoeksverslag

De onderzoeksverslagen die zijn gemaakt zijn competent opgesteld. We hadden al snel gezien welke software we zouden gaan gebruiken. Hierdoor kwam het onderzoek soms een beetje biased over wat niet zou mogen. Uiteindelijk was iedereen tevreden over de uitslag, ook de Erik onze opdrachtgever was tevreden met wat hij zag. Ik heb zelf meegewerkt aan het data visualisatie onderzoek. We hebben meerdere API's bekeken maar uiteindelijk was Google Charts het meeste uitgebreide voor wat wij wouden gaan doen.

Dit onderzoek bevat alle benodigde hoofdstukken. Inleiding, deelvragen en hoofdvraag, resultaten en conclusie. In de inleiding geven wij de achtergrond naar waarom wij het onderzoek gaan doen. Hieruit komen de hoofdvragen en bijbehorende deelvragen uit voort en deze vragen geven wij duidelijk antwoord. Uiteindelijk geven wij van elke API een lijst met voor- en nadelen die wij waren tegengekomen. Waaruit wij weer een uiteindelijke beslissing hebben gemaakt voor de uiteindelijke API.

Ik vind dit een prima onderzoek omdat het langs alle belangrijke vragen gaat en duidelijk antwoord geeft op de hoofdvraag.

3. Eindproduct

Voor ons product was documentatie en de mogelijkheid tot uitbreidbaarheid van hoogste prioriteit. We hebben uiteindelijk een werkende website met bijbehorende API gemaakt en daarbij de nodige documentatie over welke keuzes we hebben gemaakt en hoe we het uiteindelijk hebben opgezet.

Voor de documentatie vind ik dat we een redelijk goed product hebben weten op te zetten. Het is verre van perfect maar we hebben het wel zo gemaakt dat als een volgend groepje de documentatie krijgt, ze er zeker mee verder moeten kunnen. Ik vind wel dat we een aantal steken hebben laten liggen hierin. Bijvoorbeeld i.p.v het coderen en dan documenteren was niet de juiste volgorde. We hadden eerst zoveel mogelijk van het SRS en SDD moeten maken voordat we ook maar gingen denken aan code schrijven. Bijvoorbeeld als we eerst alle UML hadden gemaakt, dan hadden we dit via astah direct om kunnen zetten naar code en hadden we alleen nog de logica moeten implementeren. Dit had heel veel tijd gescheelt met het maken van de API. Maar verder zullen deze documenten de volgende groepen genoeg ondersteuning brengen zodat ze de applicatie kunnen uitbreiden.

Het frontend is naar mijn mening prima. De website heeft een gebruiksvriendelijke interface. Alleen duurt het laden van de applicatie erg lang maar dat heeft meer met de huidige server te maken waar de data wordt opgehaald. Als die een sterkere server erachter heeft draaien dan zal de performance ook zeker grote verbeteringen geven. Verder was de eis vanuit Regterschot dat de live data 20 keer seconden op de site geupdate moest worden. Dit hebben we alleen niet kunnen testen omdat het draaien van een broker lokaal erg intensief was. Ik ben daarom ook van mening dat we dit mogelijk anders hadden kunnen oplossen. Maar omdat we dit te laat hadden ingezien hebben we moeten roeien met de riemen die we hadden. Dus we hebben wel live data op de applicatie maar helaas is het wel zeer ondermaats van wat Regterschot in eerste instantie zou willen.

De backend zit erg sterk in elkaar. Tijdens het project heb ik mijn server opgezet om voor iedereen te kunnen testen. Dit was gedaan zodat iedereen ten allertijde dezelfde database en data had en niet ineens voor rare veranderingen komen te staan. Dit had zo zijn voor en nadelen maar in het algemeen werkte het zeer prettig. Doordat we de UML niet eerst hebben gemaakt hadden we veel conflicts met naamconventies. De conflicts zijn uiteindelijk wel opgelost, maar het kostte veel meer tijd dan nodig was als we eerst alle UML hadden gemaakt.

4. Evaluatie projectmethoden

In dit project wordt gebruikt gemaakt van SCRUM. Het werkt zeer fijn. Ik heb vorig project met RUP gewerkt maar ben van mening dat het manier van werken met SCRUM toch beter bij mij past. Aangezien je telkens een nieuwe stukje maakt in plaats van dat je alles 1 voor 1 maakt, zoals eerst documenten en dan home pagina etc.

Eerst wat pluspunten. Tijdens de sprints hebben wij usecases uitgewerkt, gekeken wat is beter kan en wat er mis ging en in volgende sprints dit opgepakt en meegenomen. Via de sprintreviews hebben we van de opdrachtgever goed vond en wat hij anders zou willen zien. Tijdens de retrospectives zijn we te weten gekomen wat er in de groep speelde en wat er beter kon, zodat we dit konden oppakken om zo beter als team te kunnen werken.

Wat RUP wel beter deed was dat je eerst volledige focust op documentatie zodat je niet direct bezig zou zijn met coderen. Dit gebeurde namelijk wel in de sprints, mensen begonnen massaal met coderen en vergaten een beetje dat er ook nog documentatie moest komen. Dan moet je nadat de hand alles aan het eind nog maken, dit geeft ook veel stress en is makkelijk te voorkomen. Bij RUP ben je de eerste 2 weken bezig met de documentatie zodat je eigenlijk al exact weet wat je gaat maken en niet voor verrassingen komt te staan.

5. Rollen

In mijn vorige project hebben ik gewerkt met RUP. Hierin had ik de rol van het bewaken van de Unit Testen, hierdoor moest ik weer even opfrissen welke rollen er ook als weer waren in de SCRUM methodiek. Scrum master ben ik nog niet geweest omdat we dit per sprint een iemand is. Ik ben in de laatste sprint aan de beurt en zal er dan ook meer over kunnen vertellen.

5.1. Tussentijds

In een van de eerste gesprekken die we hadden we de opdrachtgever kwam al gauw naar voren dat hij liever alle communicatie via een persoon wou laten lopen zodat er geen informatie misloopt. Deze rol heb ik op mij genomen en zal dit ook blijven doen de sprint lang. Dit geeft ook meer kansen om mijn leerdoel van betere en heldere communicatie te versterken. Verder ben ik een teamlid geweest dat goed van zich laat horen zodat als er iets in mij opkomt, soms geeft dit nieuwe ideeën soms ook niet. Ik werk altijd graag op mezelf en ga andere niet snel storen. Mijn valkuil hierin is wel dat andere gauw overzicht kwijt zijn van waar ik nou mee bezig ben, hiervoor wil ik vaak tijdens de pauze met een beetje smalltalk laten weten hoe ik ervoor sta en waar ik mogelijk tegen aan ben gelopen.

5.2. Eindproduct

Tijdens het project was ik aangewezen door zowel het team als de opdrachtgever om als tussenpersoon te spelen. Als de opdrachtgever vragen zou hebben dan stuurde hij dat naar mij toe maar ook andersom, wanneer het team vragen had voor de opdrachtgever. Doordat dit vrij snel geregeld was, was het contact zeer duidelijk en direct aangezien we niet hoefde te zoeken naar wie wat had gevraagd. Verder ben ik vooral bezig geweest met testen maken aangezien dat bij het tussentijdse naar voren kwam als iets waar nog veel gedaan moest worden. Hierdoor hadden groepsgenoten die er wat moeite mee hadden een opstapje om toch goede testen to kunnen maken.

Voor volgende projecten wil ik de DSU beter oppakken zodat we niet achter gaan lopen op schema, en sneller bij mensen mee kunnen helpen als ze erg lang op een issue vast komen te zitten. Daarnaast wil ik ook bij volgende projecten 1 iemand aangewezen krijgen die de primaire communicatie doet naar de opdrachtgever. Dit werkte erg goed en opdrachtgever gaf ook aan dat die dit erg prettig vond werken.

6. Competenties

OOSE P-04. De student ontwerpt de software van een systeem en documenteert deze onder andere met behulp van UML diagrammen en decision templates in een  Software Design Specification (SDD)

Voor de design decisions heb ik meegeholpen met het maken van de database (Hoofdstuk 5.1). Omdat de meeste groepsgenoten net van de propedeuse afkwamen, en hun nog niet echt met databases hadden gewerkt heb ik voorstel gedaan om mee te helpen. Hierdoor was er minstens een iemand die ook ISE heeft gedaan en tips kon geven of eventueel makkelijk constraints kon aanpassen. Hierbij heb ik me dus vooral bezig gehouden met de connecties tussen tabellen (Foreign en primary keys). Uiteindelijk heb ik de rest bijgeleerd hoe je makkelijk de keys kan toevoegen en aanpassen zonder al te veel code. Dit zorgde ervoor dat wanneer er keys veranderd moesten worden dat dat een stuk makkelijker ging. Ik heb hierwel bij geleerd hoe ik beter mijn mening moet overbrengen omdat personen uit mijn groep vrij standvast waren over het koppelen van keys met code, in plaats van de tooling die we hadden gekregen.

Ik zou het zeker nog een keer willen doen maar dan ga ik eerst uitleggen waarom ik iets zeg en niet mijn wil proberen door te drukken. Dit gaf voor wat frustratie bij andere omdat ze niet wiste wat ik bedoelde.

Verder heb ik het maken van de Tab CRUD (Hoofdstuk 4.4 Tab CRUD) op mij genomen. Dit was vooral omdat ik in eerste instantie veel bezig was geweest met de tabs weergeven op de webapplicatie. En aangezien ik dat dan gemakkelijk mee heb kunnen nemen is dat ook gebeurd.

OOSE P-05. De student implementeert een gedistribueerd systeem, evalueert het ontwerp en de realisatie daarvan en zorgt voor traceerbaarheid daartussen en naar de functionele en niet-functionele eisen.

Van Regterschot hadden we te horen gekregen dat ze alleen de hoog nodige security nodig hadden zodat de data veilig is. Om dit te kunnen doen heb ik een JWT token geimplementeerd die ervoor zorgt dat niemand bij de data kan komen van Regterschot behalve de mensen die kunnen inloggen in de website. De geimplementeerde token word gemaakt op de door ons gemaakte API. Wanneer de gebruiker inlogt, word er een geëncrypteerde token gestuurd (Lijn 12+15) die wanneer de gebruiker data opvraagd gestuurd wordt naar de API zodat die kan kijken of de gebruiker daadwerkelijk iemand van het systeem is.

Dit was vrij lastig omdat groepsgenoten het eerst anders wouden doen. Dit kostte veel tijd en gaf veel stress omdat het een van de weinige vaste eisen waren die Regterschot hadden gesteld. Voor volgende projecten ga ik dan ook met de groep overleggen welke methoden we zullen gaan gebruiken zodat we niet weken vast zitten op iets wat veel makkelijk opgelost had kunnen worden.

OOSE P-07. De student bewaakt continu de kwaliteit van de software en het proces door o.a. reviews en gestructureerd testen en stuurt waar nodig bij.

Bij het PVA heb ik veel nagekeken op spelling omdat ik niet hele grote en uitgebreiden stukken ervoor heb gemaakt. Ik had vooral in hoofdstuk 3.4 Resultaat en 10 risico's nog opmerkingen kunnen plaatsen en spelfouten uit kunnen halen. Hierdoor werd het geheel beter leesbaar en zorgde ervoor dat andere teamleden verder konden gaan met andere taken. Volgende keer zou het een beter idee zijn om documentatie te schrijven met behulp van word of een andere simpele spellings checker. Omdat je ergens druk bezig mee bent zie je sneller kleine spelfouten over het hoofd en dit is makkelijk te voorkomen. Ik denk dat ik hiermee in volgende projecten als iemand kan overkomen die goed de tijd neemt voor het reviewen van producten, en zo een mooi product kan achterlaten.

OOSE P-03. De student onderzoekt voor het project relevant (technologie)keuzes en rapporteert hierover gestructureerd.

Ik heb een onderzoek gaan naar Data visualisatie en welke API wij gaan gebruiken om de data uit de sensoren te kunnen weergeven. Ik heb hierbij erg streng gekeken naar de eisen die de opdrachtgever heeft gesteld en die zijn beschreven in het PvA. Ik heb ene paar prototypes gemaakt en de voor- en nadelen onderbouwd en afgewogen. Mijn startpunt begon echt bij 0, ik had hiervoor nog geen ervaringen op gedaan met grafieken en de API's die het zouden kunnen doen. Hierdoor begon het zeer algemeen met wat er weergegeven moest worden. Daarna kwam het naar voren dat de opdrachtgever ook de data in realtime op de pagina wilt kunnen zien.

Uiteindelijk zijn we dus tot de conclusie gekomen dat de Google Charts API het beste was voor de doelstelling van Regterschot. Het deed alles wat Regterschot van ons vroeg en het had ook nog duidelijke documentatie om het te implementeren.
Aan het einde kwam mijn team wel nog dat ik vaak wat te kortaf schrijf, hierdoor leek het alsof ik niet altijd even goed bezig was. Dus voor volgende onderzoeken zal ik proberen meer uitgebreid te schrijven zodat dit niet meer zo opvalt.

OOSE P-08. De student kan zich zelfstandig verder verdiepen in de beroepstaak.

MIjn team had mij aangewezen om het dashboard te gaan maken. Nou had ik al wel wat gewerkt met Angular maar lang niet genoeg. Ik was begonnen met een korte introductie te maken van hoe angular in elkaar zit en nadat ik er enigs sinds bekend mee was ben ik begonnen aan het realiseren van het dashboard zelf.

Het dashboard moest bestaan uit verschillende grafieken waarin de data van de raceauto te zien was. Zodat de crew van de auto in een oogopslag kon zien wat er aan de hand was en of het nodig was om in te grijpen. Mijn doel was dus om de grafieken makkelijk in een overzicht te krijgen en dat je ze ook naar eigen smaak kon aanpassen en nieuwe kon toevoegen.

Ik heb gekeken naar verschillende manier om tabbladen op een webpagina toe te kunnen voegen zodat je als crew lid zelf de nodigen grafieken kan toevoegen op een tabblad en zo het overzicht makkelijker kan houden.

7. Leerdoelen

In eerdere projecten liep ik altijd wat meer op de achtergrond en liet ik weinig tot niks van mij horen. Dit gaf een wat minder prettige werkomgeving omdat ik niet wist waar mensen mee bezig waren en andere wisten niet waar ik mee bezig was. Dit heeft ook veel temaken met mijn persoonlijkheid, als iemand die erg terughoudend is was ik liever rustig op mezelf bezig en vraag ik minder snel om hulp.

In het begin van het project gingen al vrij vlot te werk met het kijken naar mogelijke oplossing voor de opdracht dat we hadden gekregen. Tijdens vorige projecten was ik altijd erg terughoudend maar tijdens dit project probeerde ik me zoveel mogelijk te mengen in het gesprek. Doordat ik eerder al ervaring heb opgedaan met angular waren we toen tot de conclusie gekomen om angular te gebruiken. Meeste groepsgenoten waren er nogal onzeker over omdat het iets was wat ze nog niet kende. Maar ik heb duidelijk de voor en nadelen kunnen overbrengen wat ervoor zorgde dat ze het toch wilde proberen.

Ik heb hiervan geleerd dat ik zelf niet zo onzeker moet zijn en als ik een idee heb, of het nou goed of slecht is toch in de groep te gooien zodat andere misschien nog ideeën hebben die er bij passen.

Acties: 

• Ik ga mij opzetten als gespreksleider tijdens de gesprekken met de product owner. Hierdoor wil ik mijn gespreksvaardigheden bijwerken en verbeteren. 
• Voor dat de retrospective van het einde van de eerste sprint begint, ga ik minimaal 2 tips bedenken voor mijn project genoten. Hierdoor kom ik voorbereider over en zal dit ook makkelijker gaan voor mij.
  
• Tijdens de tweede sprint ben ik vaker bij mensen geweest als ze vragen hadden zodat ze sneller weer verder konden. Zo wisten mensen waar ik mee bezig was maar wist ik ook waar hun mee bezig waren.

Tijdens het ISE-project hadden we vaak de gesprekken die we hadden met de productowner niet goed voorbereidt. Daarnaast hadden we bijna geen gesprekken behalve de verplichte sprint reviews. Daarom wil ik tijdens dit project de productowner wat meer betrekken bij het project. Zo kunnen we tussentijds ook feedback krijgen en misschien zelfs nieuwe wensen in kaart brengen.

Met het eerste gesprek dat wij hadden met Erik had ik een agenda gemaakt. Dit had ik gedaan om ervoor te zorgen dat wij geen dingen over het hoofd zouden zien en zodat Erik zich goed kon voorbereiden op de vragen die wij hadden. Samen met Jasper hadden wij dus een agenda gemaakt met een aantal bulletpoints waarover wij als groep nog vragen hadden. Het resultaat hiervan is dat Erik zich goed kon voorbereiden en ook een extra persoon erbij kon halen die er wat meer intern van af wist.

We zullen dit zeker vaker doen zodat de gesprekken die we gaan voeren goed verlopen en zodat we niets vergeten te vragen.

• Minimaal 1 keer in de week de productowner erbij pakken om de laatste functionaliteit te kunnen laten zien, zodat hij ook meer enthousiast wordt van het product.
• Als de gesprekken niet lukken om wat voor reden dan ook, stuur ik een korte heads-up met hoever we zijn en waar we momenteel mee bezig zijn.  

8. Conclusie

Tussentijds

Ik ben van mening dat ik en de groep erg sterk zijn begonnen met het project. Helaas hadden wij nog niet echt een vast idee wat we gingen maken waardoor bijna alles maar half af was. Hierdoor hebben we weinig functionaliteiten echt goed kunnen laten zien aan de opdrachtgever. We kregen daarom ook van ons processbegeleider te horen dat we betere DSU (Daily Stand Ups). We moeten tijdens de DSU strenger gaan kijken wat er nog gedaan moet worden en hoeveel tijd het gaat kosten. Om hier een beter inzicht in te krijgen zullen we het JIRA bord met alle taken erbij betrekken tijdens de DSU. Hierdoor kunnen we elkaar erop drukken dat alles optijd af moet komen en wanneer we eventueel meer bij moeten springen als iemand te erg achterloopt.

Daarnaast wil ik meer variatie werk gaan doen. Momenteel ben ik zo goed als alleen maar frontend aan het doen maar wil ook meer backend en documentatie gaan maken anders kom ik straks niet aan mijn competenties. Als ik dit ga doen zal ik op mijn eindverslag ook beter kunnen laten zien dat ik gegroeid ben niet alleen als groepsgenoot maar ook als programmeur.

Eind

We hebben het project redelijk goed doorlopen als groep. Doordat we in de eerste paar weken veel fouten hebben gemaakt zijn we erg achter gaan lopen. Dit hebben we in het tweede deel van het project recht moeten trekken. Dit ging op sommige plekken goed en lukte dat ook goed maar op andere punten ging dat juist wat minder. De groep had in het begin een te gezellige dynamiek. Er werd te laks gewerkt. Na de tussentijdse beoordeling hebben we ons goed kunnen herpakken en zijn we langer gaan blijven en beter bezig gegaan met de opdrachten. Al was de sfeer in de groep niet altijd even leuk. Op het ene moment was het gezellig maar op andere momenten als mensen het niet met elkaar eens waren of aan het discussiëren waren kon het nog hard gaan.

In het begin van het project begonnen met zeer laks doordat we de opdracht onderschatten. Dit in combinatie met dat we net uit een schoolsetting komen en vaak smiddags vroeg klaar waren, waren we zeer snel geneigd om vroeg weg tegaan. Na de eerste sprint werden we nogal hard op de feiten gedrukt aangezien we bijna niks afhadden gekregen. Hierna zijn we al wel vaker langer gebleven om meer te kunnen doen. Om mijn leerdoelen te kunnen halen had ik mijzelf genomineerd om het vaste aanspreekpunt te zijn naar de opdrachtgever. Dit zorgde ervoor dat ik altijd wist wat er speelde en waar we nog antwoord op moeste krijgen van de opdrachtgever.

Met het reflecteren over het gehele project zie ik het uiteindelijk toch wel anders. Ik zag in dat ik met de compleet verkeerde mindset in het project was gestapt waardoor mijn werk ook achter ging lopen. Dit gecombineerd met de verkeerde aanpak van het project zorgde uiteindelijk voor frustratie bij sommige. In een volgend project wil ik de volledige les stof toepassen in plaats van de minimale toepassing wat we hier hebben gedaan. In het tweede deel van het project ben ik wat minder op de voorgrond gaan staan, hierdoor konden andere mensen ook bijvoorbeeld de sprint review laten zien aan de opdrachtgever. Tevens ben ik ook begonnen mijn mindset van een schoolsetting meer naar daadwerkelijk werken om gaan zetten. Bijvoorbeeld langer blijven, meer gericht communiceren en minder afgeleid worden tijdens werken tijden. Daar heb ik vele stappen kunnen zetten als groepslid. Voor volgende projecten ga ik dit ook zeker meenemen. Op het gebied van developer ben ik ook sterk gegroeid. Door middel van verschillende mensen je code te laten nakijken krijg je steeds nieuwe feedback en leer je meer en meer van je fouten. Dan met behulp van sonarcube heb ik geleerd wat "Best practice" is voor vele verschillende code problemen. Dit heeft mij zeer veel dingen bij gebracht en heeft mij geholpen met goede stappen te zetten richting een echte developer.

9. Bronnenlijst

9.1. Opnames gesprek Regterschot

Opname van het eerste gesprek met Erik Regterschot op 4 November 2022

AUD-20221108-WA0000.m4a

9.2. Factsheet