You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

Inleiding

Het is de opdracht om een HR-portaal te ontwikkelen, het hoofddoel van het portaal is werkplaatsbezetting op te slaan, op basis opgeslagen gegevens wordt het declaratieformulier automatisch ingevuld. Daarnaast komen de mogelijkheden om verlofaanvragen te doen en handmatig te declaraties door te geven. Een van de inhoudelijke uitdagingen is kennis op doen van front-end technologie, het framework dat wij gaan gebruiken om het portaal te realiseren is Vue. Het is een framework dat is ontwikkeld door middel van JavaScript, van beide heb ik geen kennis bij aanvang van het project. Het is nodig om onderzoek te doen naar front-end technologie om mijn kennis uit te breiden op dit gebied. Voor het project heb ik twee leerdoelen, de eerste is dat ik de stappen ga visualiseren die mogelijk nodig zijn om een bepaalde functionaliteit te realiseren voordat ik begin met coderen. Zo heb ik een beter beeld van de nodige stappen zodat ik overzicht kan houden over het geheel. Mijn andere leerdoel is dat ik ervoor wil zorgen dat er zo min mogelijk misverstanden zijn bij op te leveren producten, als er misverstanden zijn doordat verschillende personen aan een taak gaan werken kan het voorkomen dat er onduidelijkheden zijn die niet worden besproken. Hierdoor gaat er tijd verloren als het blijkt dat er onderling misverstand is en de implementaties van elkaar afwijken. In het kort samengevat ga ik werken aan mijn vaardigheden om nieuwe onderwerpen te leren en groepscommunicatie vaardigheden.


Deelproduct: Toevoegen van werkplekken

Criteria

Criteria waarop er wordt beoordeeld zijn: User Interface (UI) en code kwaliteit. Als richtlijn worden de volgende criteria voor de UI aangehouden (Telvak, 2019)

  • Typography.

  • Style conformity.

  • The functionality use. .

  • Check the spelling.

Voor code kwaliteit worden de volgende criteria aangehouden: 

  • Dont Repeat Yourself (DRY) (Karanth, 2016)
  • Clean Code (Summary of “Clean Code” by Robert C. Martin, z.d.)

Oordeel

User Interface

De UI voldoet aan de grotendeels criteria Typograpy want, de text is duidelijk leesbaar t.o.v. de achtergrond, verder is het zichtbaar wat de hoofdzaak is van de pagina. Er zijn meer dan twee fonts gebruikt, om de kwaliteit te verbeteren moet ik de styling van de pagina aanpassen zodat er niet meer dan twee fonts worden gebruikt. De criteria Style Conformity voldoet grotendeels want, de wireframe en de uiteindelijke implementatie verschillen van elkaar. Om de User Experience (UX) te verbeteren heb ik het mogelijk gemaakt om de capaciteit te verhogen of te verlagen door middel van een druk op de knop, dit dekt de criteria The functionality use af. Anders had de gebruiker zelf de waarde moeten invullen. De input velden en opmaak komen wel overeen. Een ander verbeterpunt is de lege ruimte, hiervoor moet ik de opmaak aanpassen zodat er geen lege vlakken meer zijn. En als laatst is de spelling correct en voldoet de laatste criteria ook.

 Code kwaliteit

Het principe DRY waarborg ik door de v-for functionaliteit van Vue toe te passen. Hierdoor wordt er voor iedere werkplek de soort automatisch weergegeven. Als ik deze functionaliteit niet zou gebruiken zou ik handmatig een lijst moeten schrijven van alle werkplaats soorten (FIGUUR).

De code voldoet aan de volgende clean code principes: "Be consistent, If you do something a certain way, do all similar things in the same way", "use searchable names", "Functions do one thing", "Don't comment out code. Just remove". De code voldoet niet aan de Test principes uit de clean code principes.

 Eindoordeel

Als ik het product een cijfer zou geven op dit moment dan, geef ik een 6.5. De UI voldoet grotendeels aan de criteria die hiervoor gelden. De code kwaliteit is beoordeeld op basis van de principes die van toepassing zijn op de code, en voldoet de code aan een aantal principes. Na het verbeteren van de opmerkingen dan, is het mogelijk om van het cijfer een voldoende een goed te maken.

Oordel eindproduct

n.v.t. op het tussentijdse verslag.


Evaluatie gehanteerde projectmethode

De projectmethode zoals omschreven in het plan van aanpak ". . . Aan de hand van Scrum wordt iedere sprint een iets groter product opgeleverd, . . . Dit betekend dat het HR Portaal wat JDI Smart Web applications voor ogen heeft incrementeel tot stand zal komen. Alhoewel er vanaf het begin van het project door het team gekeken wordt naar de globale requirements, wordt bij elke individuele sprint echt vastgelegd welke use cases er na de desbetreffende sprint af moeten zijn. . . . Voordat het ontwikkelteam begint met de incrementele sprints, zal in de eerste week nog een globaal overzicht van het project worden gevormd aan de hand van overlegmomenten en doormiddel van dit Plan van Aanpak. Om dit project goed via Scrum te kunnen uitvoeren, zijn een aantal vaste momenten van belang. Ten eerste zal het ontwikkelteam dagelijks tussen 9:00 en 9:15 een daily standup houden. . . . kan er ook nog gekozen worden om een mid-daily standup te houden. Dit is hetzelfde als de daily standup, maar dan om te checken of iedereen die ochtend goed aan de slag is geweest en om een planning te maken voor de rest van de dag. Of er ook ruimte en belang is voor een mid-daily standup zal tijdens de eerste sprint duidelijk worden. Naast de daily standups zullen er tussen de sprints ook sprint planning en sprint retrospective ceremonies plaatsvinden. . . . Denk hierbij bijvoorbeeld aan het selecteren van de use cases die in de volgende sprint worden opgepakt. Ten slotte wordt er na iedere sprint ook een sprint review gehouden, . . . " Zoals omschreven houden we iedere morgen een daily standup, en is er in de eerste week een beeld gevormd van het op te leveren product. Na het overleg hebben we een vragenlijst doorlopen met de opdrachtgever om er zeker van te zijn dat er geen onduidelijkheden zijn. In de eerste week zijn we erachter gekomen dat het houden van een mid-daily standup niet nodig is op het moment, als iemand ergens mee klaar is geeft die persoon het aan en vertelt diegene aan welke taak de persoon gaat werken. Op het moment van schrijven is er een retrospective gehouden, tijdens de retrospective heb ik feedback ontvangen en ben op basis hiervan een leerdoel gaan formuleren §7.1. Een verbeterpunt voor het werken met de projectmethode is het vaststellen van de use cases die worden uitgewerkt in de nieuwe sprint. Het is namelijk voorgekomen dat er twee use cases zijn gekozen om aan te werken. Nadat de use cases zijn vastgesteld zijn er aan andere use cases gewerkt. Denk hierbij aan het maken van schermontwerpen van alle use cases of het domeinmodel compleet maken.

Beschrijving rollen

Onderdeel is niet af voor het TT verslag

Onderdeel 5) Project rollen

A) ideaal vs. praktijk

B) Leerproces omschrijven rondom de rol; Wat kan beter; Wat wil je leren in je rol


C) Situatiebeschrijving STARRT; Overal waar situatie staat. maak een STARRT formulier, dus volgens Sjir worden het er wel ongeveer 6 bij het eindverslag (smile)

Starrt mag in tabelvorm maar de voorkeur gaat uit naar een lopend verhaal.



Competenties

Onderdeel niet af voor het TT verslag

Onderdeel 6) Competenties

Verwijs naar factsheet. met een link naar het materiaal. Ook hier zijn situatie beschrijvingen ook van toepassing om je ontwikkeling aan te geven.


Leerdoelen

Leerdoel: Visualiseren

Uit de eerste retrospective blijkt dat ik bij onduidelijkheid de neiging heb om eerst hulp te zoeken bij andere groepsleden. Hier is mij aangeraden om eerst het probleem en de nodige stappen te visualiseren voordat ik ga beginnen aan een implementatie. Het leerdoel staat in verband met een aantal gedragscompetenties (Overzicht van de traditionele gedragscompetenties, z.d.)

  • Schriftelijke uitdrukkingsvaardigheid
  • Samenwerken
  • Plannen en organiseren
  • Creativiteit
  • Leervermogen
  • Probleemanalyse
  • Stressbestendigheid

Door te kijken naar een visualisatie, krijg je meer inzicht waar kansen liggen voor verbetering (Processen visualiseren in Process Advisor - Power Automate, 2022). Bij het visualiseren word je gedwongen om keuzes te maken tussen hoofd- en bijzaken, hierdoor wordt de boodschap compact. Kun je het niet simpel visualiseren? Dan betekend het dat het onderwerp nog onduidelijk is. Bij het bespreken van een visualisatie dan spreekt een beeld meer dan een woord, het zorgt ervoor dat hetgeen dat wordt besproken duidelijk is voor andere. (morresMarketing, 2018)

Actie 1: tekenen en toelichten

Voordat ik ga beginnen aan een taak, ga ik als eerst op papier een schets maken van het domein. Als ik merk dat bij het maken van de schets onduidelijkheden zijn dan, ga ik de onduidelijkheden uittekenen op een apart vel. Als het probleem is uitgetekend dan ga ik de taak toelichten aan een groepsgenoot. Als de groepsgenoot aangeeft dat het duidelijk is wat er moet gebeuren en hoe het moet gebeuren dan, ga ik pas beginnen aan de te maken implementatie.

Actie 2:  Uitzoeken voor hulpverzoek

Als ik merk dat er onduidelijkheden zijn bij het visualiseren dan, ga ik op internet zoeken naar een soortgelijke oplossing. Dat ga ik maximaal dertig minuten doen, als het blijkt dat het nog onduidelijk is dan vraag ik een groepsgenoot met ervaring om hulp.

Leerdoel: Voorkomen miscommunicatie.

Uit ervaring weet ik dat bij het werken in groepsverband miscommunicatie kan ontstaan tijdens het overleg, en daardoor personen de taak afwijkend van elkaar gaan implementeren. Om dit voorkomen ga ik twee actiepunten opstellen waar ik aan ga werken om miscommunicatie te voorkomen. Het leerdoel staat in verband met de volgende gedragscompetenties (Overzicht van de traditionele gedragscompetenties, z.d.)

  • Luisteren
  • Mondelinge presentatie
  • Groepsgericht leiderschap
  • Voortgangscontrole
  • Durf

Miscommunicatie ontstaat wanneer de ontvanger de boodschap anders interpreteert dan de zender bedoeld, zowel verbale als non-verbale communicatie speler hierbij een rol (Wikipedia-bijdragers, 2021) Een andere manier waardoor miscommunicatie ontstaat is dat er wordt ingevuld voor een ander. Hierdoor maak je een aanname wat de andere persoon bedoelt, door door te vragen en samen te vatten kan dit worden voorkomen (Kiefmann, 2019)

 Actie 1:

De vaardigheid Luisteren, Samenvatten, Doorvragen (LSD) toepassen als ik het idee heb dat er enigszins onduidelijkheid heerst in het gesprek. Dit kan ik merken aan de non-verbale communicatie, denk hierbij aan een groepslid die fronst nadat er is wordt gevraagd of diegene het snapt.

Actie 2:

Als tweede actie ga ik voorstellen om documenten op te stellen als er meerdere groepsleden aan een deelproduct werken. Dit ga ik doen aan het begin van een sprint als de taken worden vastgesteld. De documenten gaan dienen als schakel om ervoor te zorgen dat er geen aannames gemaakt worden.


Conclusie

Tussentijdse verslag

Op het moment ben ik tevreden met het resultaat dat tot nu toe is opgeleverd. Zo hebben we de eerste sprint op een paar kleine taken na de sprint geheel afgerond, hiervan hebben we geleerd dat taken ruimer geschat mogen worden. En passen dit nu toe op de tweede sprint. Op het moment van schrijven zitten we nog in de tweede sprint en ziet het ernaar uit dat we de sprint gaan halen. Ik heb een aantal inhoudelijke uitdagingen getackeld, zo ben ik gaan leren hoe JavaScript werkt en wat de mogelijkheden ervan zijn. Op het moment ben ik nog lang geen expert op dit gebied maar, ik heb wel grote stappen gezet met het leren en toepassen van nieuwe onderwerpen. Tevens valt dit goed samen met het leerdoel visualiseren en helpt het leerdoel met het tackelen van de inhoudelijke uitdaging.

Eindverslag



Literatuurlijst

Starrt formulieren

verbeter na feedback tobias

Tijdens de eerste retrospective is mij verteld dat het opvalt dat, ik bij het leren van het Vue de te maken onderdelen als een groot geheel zie, en hierdoor neig het overzicht te verliezen. Om hieraan te werken kies ik ervoor om hier een van de leerdoelen van te maken. Omschrijving leerdoel. Het is mijn taak om het mogelijk te maken om een werkplek toe te voegen aan een bedrijfslocatie. Hiervoor ben ik een stappenplan gaan uittekenen d.m.v. Miro, het is nog niet duidelijk voor mij hoe data wordt doorgegeven aan onderliggende componenten, hiervoor ga ik voorbeelden opzoeken en de implementatie daarop uitwerken. Door een stappenplan te maken (FIGUUR) heb ik meer overzicht wat er moet gebeuren, om dit te testen heb ik overleg gehad met een groepsgenoot en hij gaf aan dat het duidelijk is wat er moet gebeuren. Zodoende ben ik stapsgewijs de implementatie gaan uitwerken. Door op deze manier te werken hou ik overzicht van de te maken onderdelen en kan ik op een logische manier de code opbouwen. Anders komt het voor dat ik bij het leren van nieuwe stof van alles ga proberen, logischerwijs loop ik dan vast en dan raak ik dus sneller het overzicht kwijt. Dus ik merk dat op deze manier werken mij zeker helpt om nieuwe onderwerpen te leren en toe te passen. Het kost tevens wel meer tijd om een heel stappenplan te maken van alle onderdelen. Met als conclusie dat ik geen stappenplannen ga maken voor onderdelen waar ik voldoende kennis over heb, omdat het meer tijd kost en tijd is kostbaar.



vragenkanaal discord

groepslid gaf een dat er veel vragen worden gesteld aan hem, met als reden dat hij meer dan een paar jaar ervaring heeft over front end technologie. Daarom is het gemakkelijk om hem te vragen om mee te kijken als ik of iemand anders vastloopt. Het is aan de taak om ervoor te zorgen dat er een andere manier komt van vragen stellen zodat de vraag beantwoord wordt, maar op een tijd dat het uitkomt. Om hiervoor te zorgen wordt er gebrainstormd met als resultaat dat we een vragenkanaal aanmaken in Discord. De afspraak is dat als iemand langer dan 10 minuten vastloopt een bericht stuurt in het kanaal. Met als bedoeling dat er binnen een uur hulp wordt aangeboden. Dit zou ervoor zorgen dat iedereen hulp krijgt, en andere groepsleden de tijd krijgen om eerst hun werk af te maken zodat ze niet uit hun concentratie worden gehaald. Een week na de retrospective ben ik gaan overleggen met het groepslid over het verloop van de nieuwe aanpak. Ik heb namelijk een aantal vragen gesteld in het kanaal, hierbij gaf hij aan dat dit fijner werkt omdat hij dan beter in zijn concentratie kan blijven. Met als resultaat zowel ik als het andere groepslid tevreden zijn over de nieuwe aanpak van vragen stellen. Ik ga deze manier van werken ook voorstellen in vervolgprojecten zodat iedereen de ruimte krijgt om af te maken waar ze mee bezig zijn.


Opstellen van API documentatie

Tijdens het coderen van de verlof aanvragen kwam ik erachter dat de gegevens die de backend nodig heeft anders zijn dan de gegevens uit de wireframes. Hierdoor is het nodig om een van de implemtaties aan te passen. Na overleg is besloten om de backend aan te passen zodat het overeenkomt met de gegevens uit de wireframes. Om te voorkomen dat er zulke misverstanden zich voordoen ben ik een voorbeeld API documentatie gaan uitwerken. Zodat er vooraf afspraken worden vastgelegd over de nodige data om misverstanden te voorkomen en dus tijd te besparen. Na het toelichten van de documentatie waren de groepsgenoten het ermee eens om het op deze manier aan te pakken. Dit heeft gewerkt omdat er nu voor alle endpoints documentatie beschikbaar is en er misverstanden zijn voorkomen. Ik ga bij volgende projecten waarin een API nodig is ook deze documentatie opstellen met ook de reden dat er zo overzicht blijft en er geen misverstanden ontstaan.


Wat was de situatie?

Wat was je taak?

  • Wat was je rol?
  • Wat wilde je bereiken?
  • Wat werd er van je verwacht/Wat verwachtte je van jezelf in deze situatie?

Hoe heb je het aangepakt en waarom?

    • Hoe pakte je het aan?
    • Waarom heb je het zo aangepakt? Onderbouw dit antwoord met theoretische concepten die je opleiding heeft aangereikt of die je zelf hebt opgezocht.

Heeft het gewerkt en waarom?

  • Heeft het gewerkt?
  • Waarom wel/waarom niet?

Wat heb je ervan geleerd?

  • Hoe vond je dat je het hebt gedaan?
  • Was je tevreden met de resultaten?
  • Wat is de essentie van wat je geleerd hebt?
  • Wat zou je de volgende keer eventueel anders of beter doen?
  • Kun je wat je hebt geleerd ook toepassen in andere situaties?




  • No labels