...
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.
Miscommunicatie 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.
Wat was de situatie?
Wat was je taak?
...