Versions Compared

Old Version 40

changes.mady.by.user Connor Newton

Saved on

compared with

New Version 41

changes.mady.by.user Connor Newton

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: STARR formulieren op de juiste plek

...

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 aanhouden van de uit te werken use cases tijdens de nieuwe sprints. Het is namelijk voorgekomen dat er twee use cases zijn vastgesteld in de eerste sprint. Het doel van scrum is ook om dan alleen de use cases te werken die zijn vastgesteld. Tijdens de eerste sprint is het namelijk voorgekomen dat er aan taken zijn gewerkt die niet op de planning staan. Daardoor was er een database schema opgesteld voor het hele domein en niet voor de onderdelen uit de use case, hetzelfde geldt voor het domeinmodel en de schermontwerpen. Wat hiervan het gevolg kan zijn is dat er wijzigingen komen in de implementatie en daardoor kan er tijd verloren gaan door overbodig werk. Om dit te voorkomen is er tijdens de tweede retrospective afgesproken dat er in de rest van de sprints aan de gekozen use cases gaan werken. Met als doel overbodig werk te besparen en doelgericht te werk kunnen gaan.

Wat werkt wel

Wat werkt niet

Beschrijving rollen

Voor het project heb ik de rol kwaliteitsmanager op me genomen. Zoals omschreven in het plan van aanpak "Eindverantwoordelijke voor de kwaliteit van het project. Belangrijke rol bij de code reviews.". In de functie-omschrijving van een kwaliteitsmanager (https://nl.indeed.com/personeel/functiebeschrijving/kwaliteitsmanager) staat dat de kwaliteitsmanager de bedrijfsprocessen gaat monitoren die invloed hebben op de kwaliteit van een product. Hierbij hoort het uitvoeren van kwaliteitsanalyses en het voorzien van kwaliteitsverbeteringen aan de implementatie. Ik wil er tijdens dit project achter komen hoe de rol kwaliteitsmanager invloed heeft op de uiteindelijke implementatie. Om dit doel te behalen heb ik het leerdoel dat te lezen is in §6.2 opgesteld. De situatiebeschrijving ... beschrijft hoe ik aan mijn leerdoel heb gewerkt en tevens komt hier mijn rol als kwaliteitsmanager naar voor. Het opstellen van deze documentatie heeft een positief effect op de verdere werkzaamheden. Wat verbeterd kan worden is dat de API documentatie niet mee is genomen tijdens het reviewen. Met als gevolg dat er van enkele endpoints geen documentatie beschikbaar is. Wat ik de volgende keer anders ga doen is ervoor zorgen dat de documentatie onderdeel wordt van de taak. Door het als verplicht onderdeel op te nemen is het nodig dat er een review komt. Door ervoor te zorgen dat er een review komt vinden de groepsleden mogelijke fouten en of gebrekken in de documentatie.

Tijdens dit project heb ik geleerd dat, een kwaliteitsmanager stevig in zijn schoenen moet staan. Want het is nodig om aan te geven dat onderdelen niet voldoen aan de eisen, daarnaast is het ook nodig om daarop te anticiperen en daardoor een ander teleur moet stellen omdat er werk aangepast moet worden of extra werkzaamheden toewijzen om aan de eisen te voldoen. Ik merk dat een kwaliteitsmanager de conflicthanteringsstijlen (https://www.icm.nl/extra/5-conflictstijlen-thomas-kilmann-omgaan-conflicten/) doordrukken, samenwerken en compromis sluiten toe moet passen. Doordrukken omdat het nodig is om met deze rol op te komen voor de kwaliteit en daarom andere erop aan spreken, ook als er andere groepsgenoten het er niet mee eens zijn. De stijl compromis sluiten en samenwerken hangen sterk samen met doordrukken omdat het beter werkt om als team tot een oplossing te komen, in plaats van een oplossing door te drukken. Uit de volgende bron (https://www.ag5.com/nl/samenwerken-binnen-een-team-tips/) blijkt dat het nodig is om met elkaar in overleg te gaan over de kwaliteit en elkaar daarop aanspreken, want als dit niet wordt gedaan lever je zelden het best mogelijke resultaat.

Deze rol is voor mij weggelegd maar niet op het lijf geschreven. Ik heb een groot belang bij kwaliteit van producten, hierdoor houd ik me graag bezig met procesverbetering. Hetgeen dat ik minder vind aan de rol is dat het nodig is om volhardend te zijn in discussies met name de stijl doordrukken toepassen. Soms vermijd ik een discussie ten goede van de groepsband, hier ga ik een leerdoel van maken voor de volgende keer als ik kwaliteitsmanager wordt.

STARR 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 werkt omdat er nu API 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.

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.)

  • Probleemanalyse - door te visualiseren breng je een probleem in kaart door het te analyseren.

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.

SMARTER, alle letters afgaan

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.

SMARTER, alle letters afgaan

Leerdoel: Voorkomen miscommunicatie.

STARR werken met Pull requests

Uitkomst eerste retrospective dat het de bedoeling is om gehele functionaliteit aan te leveren in een pull request, hieruit begreep ik dus dat het de bedoeling was om de gehele functionaliteit op te leveren van een use case. Wat ik vanaf toen heb gedaan is het werk committen naar de bijhorende branche en na het afronden van een use case er een pull request van maken. Hierdoor had ik dus maar één pull request. Tijdens de tweede retrospective kreeg ik de vraag hoe het komt dat ik maar een pull request heb, en heb toen het bovenstaande toegelicht. De situatie die hierdoor is onstaan is dat groepsgenoten wachten op functionaliteit die al af is, maar niet in de develop branche staat. Daardoor moesten andere groepsgenoten mijn werk over zetten van mijn branche naar hun branches. Nadat er is verhelderd waar het probleem ligt ben ik gaan werken met pull requests in plaats van commits naar de branche. Het is dus zo dat als er een bepaald onderdeel klaar is dat, ik een pull request maak in plaats van alleen een losse commit. Na dit twee weken te hebben geprobeerd, heb ik de feedback gekregen dat mijn code nu toegankelijker is voor de groepsgenoten en dat het beoordelen van de onderdelen nu makkelijker gaat, omdat er nu losse delen worden toegevoegd in plaats van hele uitwerkingen. Wat ik hiervan heb geleerd is dat branches per feature nodig zijn, en niet complete use cases hoeven te bevatten. Daarnaast merk ik dat er minder code conflicten zijn bij het opleveren van kleine functionaliteit ten opzien van complete use cases. Voor de rest van mijn loopbaan weet ik nu het belang van pull request maken.

STARR Opstellen gespreksagenda kennismaking

Voor het eerste gesprek met de opdrachtgever was het nodig om te verdiepen in de opdracht, hieruit volgen een aantal vragen. Om de opdrachtgever te laten weten waar hij aan toe is heb ik voorgesteld een gespreksagenda te maken met daarin de onderwerpen die aan bod komen met de tijd de we hebben per onderdeel om het gesprek optimaal te benutten. Door tijden erbij te zetten kunnen we ervoor waken dat er niet te lang over een onderwerp wordt gesproken. Door de vragen en de agenda aan te leveren weet de opdrachtgever waar hij aan toe is en wat er wordt verwacht. Het resultaat is dat, de opdrachtgever bij aanvang van het gesprek aangeeft dat wij de eerste groep zijn die een gespreksagenda toe stuurt. Hij gaf aan dat hij hier zeer content mee is. Wat ik hieruit meeneem is dat ik bij volgende kennismakingsgesprekken met een opdrachtgever een gespreksagenda ga opstellen, omdat dit als professioneel wordt ervaren en zo weten beide partijen wat er besproken wordt. Wat ik volgende keer anders zou doen is bij de vragenlijst enkele vragen toevoegen die andere vragen tegenspreken. Als er dan in het gesprek blijkt dat de juiste en onjuiste vraag beide goed zijn, dan weet ik dat het nodig is om door te vragen omdat er dan toch onduidelijkheden zijn.


Wat werkt wel


Wat werkt niet

Beschrijving rollen

Voor het project heb ik de rol kwaliteitsmanager op me genomen. Zoals omschreven in het plan van aanpak "Eindverantwoordelijke voor de kwaliteit van het project. Belangrijke rol bij de code reviews.". In de functie-omschrijving van een kwaliteitsmanager (https://nl.indeed.com/personeel/functiebeschrijving/kwaliteitsmanager) staat dat de kwaliteitsmanager de bedrijfsprocessen gaat monitoren die invloed hebben op de kwaliteit van een product. Hierbij hoort het uitvoeren van kwaliteitsanalyses en het voorzien van kwaliteitsverbeteringen aan de implementatie. Ik wil er tijdens dit project achter komen hoe de rol kwaliteitsmanager invloed heeft op de uiteindelijke implementatie. Om dit doel te behalen heb ik het leerdoel dat te lezen is in §6.2 opgesteld. De situatiebeschrijving ... beschrijft hoe ik aan mijn leerdoel heb gewerkt en tevens komt hier mijn rol als kwaliteitsmanager naar voor. Het opstellen van deze documentatie heeft een positief effect op de verdere werkzaamheden. Wat verbeterd kan worden is dat de API documentatie niet mee is genomen tijdens het reviewen. Met als gevolg dat er van enkele endpoints geen documentatie beschikbaar is. Wat ik de volgende keer anders ga doen is ervoor zorgen dat de documentatie onderdeel wordt van de taak. Door het als verplicht onderdeel op te nemen is het nodig dat er een review komt. Door ervoor te zorgen dat er een review komt vinden de groepsleden mogelijke fouten en of gebrekken in de documentatie.

Tijdens dit project heb ik geleerd dat, een kwaliteitsmanager stevig in zijn schoenen moet staan. Want het is nodig om aan te geven dat onderdelen niet voldoen aan de eisen, daarnaast is het ook nodig om daarop te anticiperen en daardoor een ander teleur moet stellen omdat er werk aangepast moet worden of extra werkzaamheden toewijzen om aan de eisen te voldoen. Ik merk dat een kwaliteitsmanager de conflicthanteringsstijlen (https://www.icm.nl/extra/5-conflictstijlen-thomas-kilmann-omgaan-conflicten/) doordrukken, samenwerken en compromis sluiten toe moet passen. Doordrukken omdat het nodig is om met deze rol op te komen voor de kwaliteit en daarom andere erop aan spreken, ook als er andere groepsgenoten het er niet mee eens zijn. De stijl compromis sluiten en samenwerken hangen sterk samen met doordrukken omdat het beter werkt om als team tot een oplossing te komen, in plaats van een oplossing door te drukken. Uit de volgende bron (https://www.ag5.com/nl/samenwerken-binnen-een-team-tips/) blijkt dat het nodig is om met elkaar in overleg te gaan over de kwaliteit en elkaar daarop aanspreken, want als dit niet wordt gedaan lever je zelden het best mogelijke resultaat.

Deze rol is voor mij weggelegd maar niet op het lijf geschreven. Ik heb een groot belang bij kwaliteit van producten, hierdoor houd ik me graag bezig met procesverbetering. Hetgeen dat ik minder vind aan de rol is dat het nodig is om volhardend te zijn in discussies met name de stijl doordrukken toepassen. Soms vermijd ik een discussie ten goede van de groepsband, hier ga ik een leerdoel van maken voor de volgende keer als ik kwaliteitsmanager wordt.



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 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.)

  • Durf - Het is nodig om een discussie aan te durven gaan als het nodig is en niet een discussie vermijden.

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.

MOET NOG VEEL SMARTER

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. Meer beschouwing rondom leerdoelen

Eindverslag

Ik ben zeer tevreden met het resultaat dat we opleveren aan de opdrachtgever. In hoofdstuk 3 heb ik toelichting gegeven op het eindproduct en hieruit blijkt dat het doel van het hele project is behaald, het is niet meer nodig om meerdere spreadsheets bij te houden. Tijdens de retrospectives hebben we ons als groep kunnen ontwikkelen en ik ook als persoon door de feedback rondes. Hierdoor ben ik op het leerdoel gekomen om te gaan visualiseren, door dit te gaan doen had ik minder moeite om nieuwe onderdelen op te pakken met het front end framework.

De rol als kwaliteitsmanager heeft me persoonlijke inzichten gegeven door terug te reflecteren met het conflicthanteringsmodel. Zo weet ik nu meer over mijn kwaliteiten en waar mogelijkheden liggen om door te ontwikkelen als persoon. Ik heb geleerd dat het niet goed is om discussies te mijden ten behoeve van de kwaliteit.

Zoals omschreven in de inleiding is het leren van front end een van mijn doelen in het project mede uit persoonlijke interesse, het doel is behaald omdat ik nu basis kennis heb over het programmeren in JavaScript en pagina's kan maken met het Vue framework.

Leerdoelen

Literatuurlijst

Starrt formulieren

verbeteren na feedback

...

  • Probleemanalyse - door te visualiseren breng je een probleem in kaart door het te analyseren.

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.

SMARTER, alle letters afgaan

verbeteren na feedback

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.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.

Image Added

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.

SMARTER, alle letters afgaan

STARR 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.


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.)

  • Durf - Het is nodig om een discussie aan te durven gaan als het nodig is en niet een discussie vermijden.

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.

MOET NOG VEEL SMARTER

STARR conflicthantering front-end werkplek toevoegen

Ik heb de taak op me genomen om het mogelijk te maken om werkplekken toe te voegen. Tijdens het uitwerken merkte ik op dat er naast een naam voor de werkplek, er ook een soort nodig is om de werkplek aan te koppelen. (FIGUUR) Op basis van de toelichting van de opdrachtgever leek het me overbodig om een soort toe te kennen, omdat de opdrachtgever aangeeft dat hun bijvoorbeeld een algemene werkplek hebben en een focuswerkplek. Dus mij lijkt het dubbelop om een ruimte zo te noemen en dan ook nog aan te geven dat het een van de soorten hetzelfde is. Dit heb ik aangegeven aan de personen die bezig zijn met de backend van dit onderdeel, hieruit kreeg ik de reactie dat het handig is om te hebben. Hier was ik het niet geheel mee eens maar heb het voor lief genomen. Om de situatie terug te koppelen maak ik gebruik van een conflicthanteringsmodel (https://www.icm.nl/extra/5-conflictstijlen-thomas-kilmann-omgaan-conflicten/) Wat ik heb gedaan is de stijl vermijden en toegeven toepassen. Door de stijl vermijden en toegeven toe te passen is er tijd gewonnen, en een mogelijk discussie vermeden. Ik was er bang voor dat ik bij de stijl doordrukken een discussie zou ontstaan doordat de andere groepsgenoten aangaven dat, ze over dit onderwerp meermaals hebben besproken. Als ik terug kijk op deze situatie besluit ik dat, de volgende keer als er een zelfde soort situatie is een middenweg voor te stellen en dus de stijl compromis sluiten toepassen. Met als compromis het besluit bij de opdrachtgever neer te leggen. Op die manier kan er ook geen onderlinge discussie ontstaan over wat de opdrachtgever mogelijk wilt. Daardoor hoeft er ook geen conflict vermeden te worden en krijgt de opdrachtgever de implementatie zoals gewenst.

Image Added

(https://www.icm.nl/extra/5-conflictstijlen-thomas-kilmann-omgaan-conflicten/)

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.

STARR 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 werkt omdat er nu API 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.

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. Meer beschouwing rondom leerdoelen

Eindverslag

Ik ben zeer tevreden met het resultaat dat we opleveren aan de opdrachtgever. In hoofdstuk 3 heb ik toelichting gegeven op het eindproduct en hieruit blijkt dat het doel van het hele project is behaald, het is niet meer nodig om meerdere spreadsheets bij te houden. Tijdens de retrospectives hebben we ons als groep kunnen ontwikkelen en ik ook als persoon door de feedback rondes. Hierdoor ben ik op het leerdoel gekomen om te gaan visualiseren, door dit te gaan doen had ik minder moeite om nieuwe onderdelen op te pakken met het front end framework.

De rol als kwaliteitsmanager heeft me persoonlijke inzichten gegeven door terug te reflecteren met het conflicthanteringsmodel. Zo weet ik nu meer over mijn kwaliteiten en waar mogelijkheden liggen om door te ontwikkelen als persoon. Ik heb geleerd dat het niet goed is om discussies te mijden ten behoeve van de kwaliteit.

Zoals omschreven in de inleiding is het leren van front end een van mijn doelen in het project mede uit persoonlijke interesse, het doel is behaald omdat ik nu basis kennis heb over het programmeren in JavaScript en pagina's kan maken met het Vue framework.


Leerdoelen




Literatuurlijst


Starrt formulieren

Image Removed

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.

werken met Pull requests

Uitkomst eerste retrospective dat het de bedoeling is om gehele functionaliteit aan te leveren in een pull request, hieruit begreep ik dus dat het de bedoeling was om de gehele functionaliteit op te leveren van een use case. Wat ik vanaf toen heb gedaan is het werk committen naar de bijhorende branche en na het afronden van een use case er een pull request van maken. Hierdoor had ik dus maar één pull request. Tijdens de tweede retrospective kreeg ik de vraag hoe het komt dat ik maar een pull request heb, en heb toen het bovenstaande toegelicht. De situatie die hierdoor is onstaan is dat groepsgenoten wachten op functionaliteit die al af is, maar niet in de develop branche staat. Daardoor moesten andere groepsgenoten mijn werk over zetten van mijn branche naar hun branches. Nadat er is verhelderd waar het probleem ligt ben ik gaan werken met pull requests in plaats van commits naar de branche. Het is dus zo dat als er een bepaald onderdeel klaar is dat, ik een pull request maak in plaats van alleen een losse commit. Na dit twee weken te hebben geprobeerd, heb ik de feedback gekregen dat mijn code nu toegankelijker is voor de groepsgenoten en dat het beoordelen van de onderdelen nu makkelijker gaat, omdat er nu losse delen worden toegevoegd in plaats van hele uitwerkingen. Wat ik hiervan heb geleerd is dat branches per feature nodig zijn, en niet complete use cases hoeven te bevatten. Daarnaast merk ik dat er minder code conflicten zijn bij het opleveren van kleine functionaliteit ten opzien van complete use cases. Voor de rest van mijn loopbaan weet ik nu het belang van pull request maken.

Opstellen gespreksagenda kennismaking

Voor het eerste gesprek met de opdrachtgever was het nodig om te verdiepen in de opdracht, hieruit volgen een aantal vragen. Om de opdrachtgever te laten weten waar hij aan toe is heb ik voorgesteld een gespreksagenda te maken met daarin de onderwerpen die aan bod komen met de tijd de we hebben per onderdeel om het gesprek optimaal te benutten. Door tijden erbij te zetten kunnen we ervoor waken dat er niet te lang over een onderwerp wordt gesproken. Door de vragen en de agenda aan te leveren weet de opdrachtgever waar hij aan toe is en wat er wordt verwacht. Het resultaat is dat, de opdrachtgever bij aanvang van het gesprek aangeeft dat wij de eerste groep zijn die een gespreksagenda toe stuurt. Hij gaf aan dat hij hier zeer content mee is. Wat ik hieruit meeneem is dat ik bij volgende kennismakingsgesprekken met een opdrachtgever een gespreksagenda ga opstellen, omdat dit als professioneel wordt ervaren en zo weten beide partijen wat er besproken wordt. Wat ik volgende keer anders zou doen is bij de vragenlijst enkele vragen toevoegen die andere vragen tegenspreken. Als er dan in het gesprek blijkt dat de juiste en onjuiste vraag beide goed zijn, dan weet ik dat het nodig is om door te vragen omdat er dan toch onduidelijkheden zijn.

conflicthantering front-end werkplek toevoegen

Ik heb de taak op me genomen om het mogelijk te maken om werkplekken toe te voegen. Tijdens het uitwerken merkte ik op dat er naast een naam voor de werkplek, er ook een soort nodig is om de werkplek aan te koppelen. (FIGUUR) Op basis van de toelichting van de opdrachtgever leek het me overbodig om een soort toe te kennen, omdat de opdrachtgever aangeeft dat hun bijvoorbeeld een algemene werkplek hebben en een focuswerkplek. Dus mij lijkt het dubbelop om een ruimte zo te noemen en dan ook nog aan te geven dat het een van de soorten hetzelfde is. Dit heb ik aangegeven aan de personen die bezig zijn met de backend van dit onderdeel, hieruit kreeg ik de reactie dat het handig is om te hebben. Hier was ik het niet geheel mee eens maar heb het voor lief genomen. Om de situatie terug te koppelen maak ik gebruik van een conflicthanteringsmodel (https://www.icm.nl/extra/5-conflictstijlen-thomas-kilmann-omgaan-conflicten/) Wat ik heb gedaan is de stijl vermijden en toegeven toepassen. Door de stijl vermijden en toegeven toe te passen is er tijd gewonnen, en een mogelijk discussie vermeden. Ik was er bang voor dat ik bij de stijl doordrukken een discussie zou ontstaan doordat de andere groepsgenoten aangaven dat, ze over dit onderwerp meermaals hebben besproken. Als ik terug kijk op deze situatie besluit ik dat, de volgende keer als er een zelfde soort situatie is een middenweg voor te stellen en dus de stijl compromis sluiten toepassen. Met als compromis het besluit bij de opdrachtgever neer te leggen. Op die manier kan er ook geen onderlinge discussie ontstaan over wat de opdrachtgever mogelijk wilt. Daardoor hoeft er ook geen conflict vermeden te worden en krijgt de opdrachtgever de implementatie zoals gewenst.

Image Removed

...



Wat was de situatie?

Wat was je taak?

...