Digitaal samenwerken en coachen
Praktijkvoorbeeld uit Project I van de opleiding Toegepaste Informatica
In deze blogpost lichten we toe hoe in Project I van de opleiding Toegepaste Informatica werd omgegaan met de omschakeling naar volledig online onderwijs tijdens de lockdownperiode. In Project I werken de studenten in een team aan het digitaliseren van een spel. Dit jaar was dit het bordspel Alhambra. Samenwerking en communicatie zijn de competenties waar heel hard wordt op ingezet binnen dit project, naast het effectief in staat zijn iets te realiseren op een kwalitatieve manier (process als puur technisch).
Rol van de coaches
Technical coaches:
Het doel van de technical coaches in het project is om de studenten op verschillende aspecten technisch te ondersteunen. Elke docent(e) heeft een aantal zaken waarin hij of zij kan ondersteunen. De studenten weten wie wanneer aanwezig is tijdens de projectdagen en -weken. Ze moeten zelf gaan plannen wanneer ze welke vragen aan wie stellen. Nu moest het allemaal online…
Er werd gewerkt met Teams Kanalen. Voor elk onderwerp was er een kanaal voorzien waar de studenten hun vragen konden stellen. De studenten moesten in staat zijn om in het juiste kanaal de vraag te stellen. Als ze in het verkeerde kanaal de vraag stelden, werden ze door de docenten, of andere studenten, geholpen om uit te vissen wat het juiste kanaal wel zou zijn.
Tijdens de coachingsmomenten kregen ze antwoord van de coaches die op dat moment online waren. Telkens een coach een vraag op zich nam, werd het ‘duimpje omhoog’ aangeklikt, zodat niet alle coaches naar dezelfde vragen moesten kijken.
Studenten hielpen ook elkaar. Dit was reeds het geval in de voorgaande jaren, maar bleef toen vaak beperkt tot vriendengroepen. Doordat ze nu vragen stelden in de Teams, stonden ze meer met al hun medestudenten in contact en werden meer studenten betrokken bij een aantal discussies. Zo kwamen ze vaak samen tot een antwoord zonder dat een docent moest tussenkomen, behalve met een ‘hartje’-icoon… .
Voor vragen die vaak terug kwamen, werd een ‘FAQ’ gemaakt. Hiervoor werd de wiki-applicatie gebruikt van Office365 en toegevoegd aan het kanaal.
Tot slot werden een hele reeks korte instructiefilmpjes gemaakt rond hoe ze bepaalde zaken technisch moeten aanpakken – wat we voorgaande jaren in klassikale infosessies deden – en moesten de studenten voor de aanvang van het project een ‘online cursus’ afwerken over hoe ze moeten werken met een ‘version control system’ (git genaamd). Vragen over git werden niet beantwoord als ze de cursus niet hadden doorlopen.
Groepscoaches:
De groepscoach volgt de groepswerking en -dynamiek op, kijkt na of ze op schema zitten, waar er tekorten zijn, of er binnen de groep conflicten zijn en of iedereen zich aan de afspraken houdt, … . De groepscoaches plannen zelf een aantal gesprekken in met groepen, waar de groepswerking wordt besproken. Technische problemen komen tijdens deze gesprekken niet(!) aan bod.
Ook dit verliep dit jaar volledig via Teams. Hier misten de coaches wel het zicht op hoe de groep zich onderling gedraagt, iets wat ze normaal goed kunnen observeren tijdens de projectdagen. De coaches dienden meer voort te gaan op de inbreng van de studenten zelf, naast de opvolging via de feedbackdocumenten (zie volgende punt)
Opvolging van de studenten
- De code wordt continu opgevolgd naar codekwaliteit. De studenten zien ook terwijl ze aan het typen zijn of ze zondigen tegen bepaalde regels. Daarnaast is er een dashboard waarop de studenten en lectoren dit kunnen opvolgen. We weten wie wanneer welke code heeft toegevoegd, gewijzigd of verwijderd. Dit is een standaard systeem in IT (version control), maar hier hebben de lectoren heel wat statistieken bij.
- De studenten moeten elkaars werk beoordelen (in-team). Elk stukje code moet goedgekeurd worden door minstens twee andere leden van de groep voor het op de finale versie komt. De bedoeling is dat de studenten minstens dagelijks, liefst meer, nakijken of er nieuwe stukken code zijn om na te kijken. Hoe korter de cyclus van nieuwe code-review, hoe vlugger problemen worden gevonden en hoe kleiner de impact.
Er is een gemeenschappelijke verantwoordelijkheid. Niemand kan/mag ooit zeggen: “dit is niet mijn code”, want er moet goedkeuring zijn van anderen en iedereen moet alle code van de anderen begrijpen en kunnen aanpassen. De lectoren volgen dit op en het wordt getest op het individueel mondeling examen in juni. - Elke projectdag starten de studenten met een Daily Standup. Ze overlopen hoe de vorige projectdag was, wat er wel/niet is gelukt, of er problemen zijn en wat de planning is voor de volgende dag. Dit moesten ze dit jaar opnemen in een video en indienen voor 11u00. Dergelijke daily standup is een kort gesprek om de voortgang te bespreken en duurt normaal 1-2min/persoon max, dus in dit geval, bij teams van 4-6 personen, duurden de filmpjes ongeveer 5-10min.
- Het project is ingedeeld in 5 timeboxes (sprints). Op het einde van elke sprint moeten de studenten 3 feedback-documenten indienen in LEHO:
- reflectieverslag/introspect: hoe sta ik in de groep? Heb ik het goed gedaan of had ik andere dingen beter kunnen doen? (individueel, telkens via een andere vooropgestelde methodiek en laatste vrij formaat)
- peer assessement: hoe staan anderen, volgens mij, in de groep? In welke mate dragen ze bij? (individueel, WebPA, en laatste vrij formaat)
- sprint retrospect: in groep terugkijken over de afgelopen periode en daaruit een aantal actiepunten halen. (in groep, telkens via andere methodiek)
- Er waren 4 ‘code review’ momenten via Teams. De studenten krijgen dan de kans om te laten zien hoe ver het staat. Twee lectoren gaan dan door de code, helpen ze verder en beantwoorden vragen die de groepen hebben.
Andere relevante blogposts
Virtuele community in je cursus aanmaken
Voor meer informatie rond de specifieke aanpak van dit opleidingsonderdeel kan je terecht bij kurt.sys@howest.be